In hard disks, a "quick format" does nothing to the actual data on the disk - just clears the FAT (file allocation table), which then appears as a "blank disk" to the user. Therefore, it is fairly easy to ignore the FAT and read that data. Although it is tricky to read specific data, as there are no indicators to where a particular file begins and ends. Some format commands even save a backup of the FAT table, and restoring this backup manifests as the "unformat" feature.

A long-format of a hard disk does reset most of the data, which would seem to eliminate the possibility of reading said data - except for a characteristic inherent to magnetic storage media: hysteresis. When a bit is set or cleared on a hard disk, the process is not 100.00% accurate, as the media exhibits hysteresis. So some small amount of residual magnetism remains from the previous operation, and certain software tools can be used to scan areas of the disk (many times) to read that fraction of a percent of latent magnetization and "recover" this overwritten data.

But how do today's solid-state non-volatile memories fare? Thumb drives, SSD's, NAND Flash? The only relevant information I could find about their security and vulnerability is in this Wikipedia article which states:

In addition, deleted files on SSDs can remain for an indefinite period of time before being overwritten by fresh data; erasure or shred techniques or software that work well on magnetic hard disk drives have no effect on SSDs, compromising security and forensic examination.

Wait, what? These seem to be two completely different statements - the first implying that long-formats are never done and Flash therefore is always susceptible to my first paragraph's vulnerability. This can't be, correct? As I can "long format" a thumb drive or SSD, or instruct a uC to overwrite every block of a NAND Flash. And since wear-leveling places blocks somewhat randomly, I'd assume which blocks get overwritten to be rather random as well. So perhaps not all of a file would be overwritten in time, but some of it seems highly likely.

It also states that erasure or shred techniques do not work on Flash which I find hard to believe. As long as every allocation unit were overwritten, that would make any data completely un-recoverable, correct?

How this applies to EE.SX: Imagine a NAND Flash with several crypto key pairs on it. If the chassis is opened, the device is erased, so nobody can "get" the keys. But is an "erase" enough?

That said, are nonvolatile flash memories susceptible to any type of data recovery technique? Is there any electrical field hysteresis to leverage for recovering overwritten data?

  • \$\begingroup\$ I wish it would be possible to recover the ovewritten data. It would mean we have an infinite storage space. \$\endgroup\$ – Eugene Sh. Mar 8 '16 at 20:17
  • \$\begingroup\$ @EugeneSh. Not infinite, just the possibility to store/retrieve (at considerable risk/expense & complexity) 2 or more times the stated/'normal' capacity. \$\endgroup\$ – Robherc KV5ROB Mar 8 '16 at 20:45
  • \$\begingroup\$ Actually for the point of embedded devices the story is different (since you briefly touch on the subject). If you have your fingers inside the operating system's source (whether that's actually your own micro-OS bare-metal-style, or an actual OS) you can implement any number of secure erasures on any technology, given the want to do so. Of course, the easiest instant destructibility is an intentionally breakable DRAM power path, or a HV-erasable EEPROM chip. I bet those still exist as well. \$\endgroup\$ – Asmyldof Mar 8 '16 at 20:52
  • 1
    \$\begingroup\$ The technique of recovering bits from magnetic hard drives is a misinterpretation of a single age-old report. Here's one of many who's written more about why it doesn't work: digital-forensics.sans.org/blog/2009/01/15/… \$\endgroup\$ – pipe Mar 8 '16 at 21:14
  • 1
    \$\begingroup\$ For the crypto keys issue, better choice is probably a small, low-power RAM powered by a battery. Open the case and it can be overwritten in microseconds to clear it. A button cell could supply the memory for 10 years. You don't want to just cut power as a freeze spray will quickly render the memory stables for many minutes. \$\endgroup\$ – DoxyLover Mar 8 '16 at 23:20

The problem with secure erase is that the device has a translation layer in it. On a disk, writing to cylinder X sector Y will always overwrite the same area. On an SSD, the device firmware maintains a list of blank blocks and writes to the next one available, maintaining a table mapping logical addresses to actual flash blocks. There is usually a bit more flash than the stated capacity as spares, so a complete write may not touch every block. Erasing blocks is slow, so they are not erased immediately, and maybe not erased until space is short.

Drive firmware may offer three possible solutions to this. One is TRIM: tell the drive which blocks do not have filesystem data in, and let it preemptively erase them. One is a specific "secure erase" command, which should actually erase all the blocks (but takes a long time). And one is transparent block-level encryption, where asking the drive to discard the key instantly loses all the data. However, you're hostage to how well this has been implemented and there may be bugs.

I'm not aware of techniques for recovering data from flash cells that have actually been erased. (In fact it may lose bits spontaneously, so error correction is built in).

| improve this answer | |
  • \$\begingroup\$ ECC and redundancy may stretch a little on high-reliability SSDs, where a forensic team directly accessing the actual flash may be able to restore sufficient cells using macro-ECC-like techniques to read data that was presumed lost. Given sufficient know-how. (very rare chance, I'd say, that all those odds roll out together) \$\endgroup\$ – Asmyldof Mar 8 '16 at 20:48
  • 1
    \$\begingroup\$ Generally, you use electron tunneling to "erase", which means make the node positive. You have sense amps to read the level of the bits, so if you look at them in an analog fashion, you can see the last state. Of course, there's some caveats that you need access to the debug instructions. I modeled hot-electron injection for a paper, so I had the special commands from one vender, but if want to recover some large, it'd take years. I only could read about 1000 individual gates per second. :/ \$\endgroup\$ – b degnan Mar 8 '16 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.