Timeline for Publishing anti-forensic hard drive firmware
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 22, 2022 at 22:45 | answer | added | David Siegel | timeline score: 2 | |
| Mar 22, 2022 at 22:13 | history | edited | forest |
edited tags
|
|
| Feb 21, 2021 at 0:39 | comment | added | forest | @paulj The question gives an example of the intent: Alice published this because it was a cool proof-of-concept she had made, and Bob installed it to prevent thieves from copying his hard drive. | |
| Feb 16, 2021 at 15:38 | comment | added | paulj | Would intent come into play? e.g. I am have the right in US to have lock-picking tools, rakes and bumps. However, 2am in the morning while standing outside a hardware store, which a van, and carts ...? | |
| Feb 15, 2021 at 0:46 | comment | added | forest | @Clockwork-Muse Sure, and I'm not dissing encryption or encouraging anything less. The actual implementation of such anti-forensic firmware and whether or not it is practical is out-of-scope (there have been various PoCs from time to time, including one that used an iPod Classic hard drive!). Since I asked this question on Law.SE, I figured I would only need to provide the most basic description of the system, not a more full "production ready" description that goes into all the edge cases. | |
| Feb 15, 2021 at 0:44 | comment | added | forest | @grovkin And every detection method could be subverted by swapping the platters, but in practice, no one does that. Whether or not it's effective or impossible to subvert doesn't really matter. | |
| Feb 15, 2021 at 0:40 | comment | added | grovkin | the trivial detection method you propose is easily subverted by randomizing the order of reads, but i realize that's a cat-n-mouse game. | |
| Feb 15, 2021 at 0:34 | comment | added | Clockwork-Muse |
If a thief (or the law) is compelling you to provide a password, both will be equally as displeased when the drive destructs. Encryption prevents any files leaking, while this needs some read threshold, allowing at least some files to be read. Note that, since reads are normally nondestructive, there may be more reads on a system than you realize. For instance, the OS indexing the drive for faster searching. Depending on what data the drive contains, it might not be unlikely that a grep (search file contents) is performed.
|
|
| Feb 14, 2021 at 23:56 | comment | added | forest | @Clockwork-Muse It's not particularly difficult to detect cloning in place while minimizing false positives. For example, if the drive is powered up and n sectors are read sequentially without any seeks, then it's being cloned. If instead it gets lots of random reads and some writes, then it knows that everything is fine even if later it does get sequential read requests. As for encryption, it only helps if you don't reveal the password. A thief might force you to give up the password. Likewise in law, there are instances where you can be compelled to reveal your password. | |
| Feb 14, 2021 at 23:53 | comment | added | Clockwork-Muse | Note that, from the source drive's perspective, it doesn't know about the write-blocking, just that it's received read commands. Creating such firmware is problematic from that, since you'd need to be careful what a "copy threshold" would be set at (you couldn't duplicate your drive, for example). From an evidentiary perspective, turning over such a drive (as opposed to having it seized) likely would constitute destruction of evidence (a separate crime). Also, the better way to prevent unwanted copying is to encrypt the drive, which many drives do natively (and is managed by the OS) | |
| Feb 14, 2021 at 3:19 | history | asked | forest | CC BY-SA 4.0 |