Information Security
forensics deletion flash-memory hardware
Updated Tue, 19 Jul 2022 12:00:34 GMT

Can wiped SSD data be recovered?

I was reading another post on destroying IDE drives, and how you could remove data, wipe it, or just destroy the drive. The removed data would still be there in some state, although not easily reachable without software. Wiped data is just removed data, but it has been overwritten and is essentially gone. A destroyed disk, if done well enough, will remove everything, or make it nearly impossible to recover anything. According to my understanding.

What about a solid-state drive? Can the data on one of these be recovered once deleted? It seems that this would be the way to go if you constantly dealt with and removed sensitive data, but SSDs only have so long of a life span (again, as I understand).

Can data from an SSD be recovered in any way once it is removed, even if it has not been overwritten?


Yes. If you do a normal format, the old data can be recovered. A normal format only deletes/overwrites a tiny bit of filesystem metadata, but does not overwrite all of the data itself. The data is still there. This is especially true on SSDs, due to wear levelling and other features of SSDs.

The following research paper studies erasure of data on SSDs:

One takeaway lesson is that securely erasing data on a SSD is a bit tricky. One reason is that overwriting data on a SSD doesn't work the way you'd think it does, due to wear-leveling and other features. When you ask the SSD to "overwrite" an existing sector, it doesn't actually overwrite or delete the existing data immediately. Instead, it writes the new data somewhere else and just change a pointer to point to the new version (leaving the old version laying around). The old version may eventually get erased, or it may not. As a result, even data you think you have erased, may still be present and accessible on the SSD.

Also, SSDs are a bit tricky to sanitize (erase completely), because the methods that used to work for magnetic HDDs don't necessarily work reliably on SSDs (due to the aforementioned wear levelling and other issues). Consequently, utilities that are advertised as providing "secure drive erase" functionality may not be fully secure, if applied to a SSD. For instance, the FAST paper found that, in most cases, performing a full overwrite of all of the data on the SSD twice was enough to sanitize the disk drive, but there were a few exceptional cases where some of the data still remained present. There may be other reasons not to want to perform repeated overwrites of the full drive: it is very slow, and it may reduce the subsequent lifetime of the drive.

The FAST paper also found that degaussing (a standard method used for sanitizing magnetic hard drives) is not effective at all at sanitizing SSDs.

Moreover, the FAST paper found that standard utilities for sanitizing individual files were highly unreliable on SSDs: often a large fraction of the data remained present somewhere on the drive. Therefore, you should assume there is no reliable way to securely erase individual files on a SSD; you need to sanitize the whole drive, as an entire unit.

The most reliable way to securely erase an entire SSD is to use the ATA Secure Erase command. However, this is not foolproof. The FAST paper found that most SSDs implement this correctly, but not all. In particular, 8 of the 12 SSDs they studied supported ATA Secure Erase, and 4 did not. Of the 8 that did support it, 3 had a buggy implementation. 1 buggy implementation was really bad: it reported success, but actually left the data laying around. This is atrociously bad, because there is no way that software could detect the failure to erase. 2 buggy implementations failed and left old data laying around (under certain conditions), but at least they reported failure, so if the software that sends the ATA Secure Erase command checks the result code, at least the failure could be detected.

The other possible approach is to use full disk encryption: make sure the entire filesystem on the drive is encrypted from the start (e.g., Bitlocker, Truecrypt). When you want to sanitize the drive, forget all the crypto keys and securely erase them, and then erase the drive as best as possible. This may be a workable solution, though personally I would probably want to combine it with ATA Secure Erase, too, for best security.

See also the following questions on this site:

Comments (5)

  • +2 – I have done a "secure erase" by writing random data sequentially to the whole drive, twice. If the drive recycles its spare block pool to minimize wear, this MAY work by having written every physical block at least once. But I really have no idea if every block really would get used in one pass or the other. Maybe three passes? — Jan 27, 2013 at 05:56  
  • +3 – Hi @Skaperen: SSD drives are very complex. I doubt anyone will be able to answer your question authoritatively, from first principles. Instead, I think the only way to know is to conduct experiments and look at the resulting data. For some data on how well overwriting twice works, see my answer above, the part starting with "The FAST paper found that, in most cases, performing a full overwrite of all of the data on the SSD twice was...". For data on another way to erase a SSD, see the paragraph beginning "The most reliable way to securely erase an entire SSD is...". That's all I know. — Jan 27, 2013 at 19:00  
  • +2 – Degaussing hasn't worked for silicon platter drives since the 90's, FYI. They're just too dense and not magnetic enough anymore. A hammer always works, though. — May 10, 2014 at 22:49  
  • +1 – You only need to overwrite the whole drive with random data once, as no thresholds exist for flash chips. The original data will be gone. — Feb 10, 2016 at 14:10  
  • +4 – I didn't see any mention of the TRIM command. SSD's can't write to a previously written location without first erasing it. Which also means that an SSD's wear leveling algorithm will write new data to a smaller and smaller area of the flash memory, wearing the drive out faster, unless some background process regularly runs TRIM to erase released flash memory, or the memory is erased immediately before a write. The latter has serious performance implications. — Oct 08, 2016 at 23:25