Data recovery from TRIMmed SSDs

Question

Assuming a given SSD supports TRIM, and is on a physical bus that supports sending that command, and the connected computer is running an OS that is aware of TRIM:

If the drive is formatted, or has had its files erased, will the data be unrecoverable after the drive's firmware has performed its full garbage collection cycle? For example, 24 hours after the fact?

I know that TRIM was initially introduced to flag blocks for later erasure to speed up writes to the underlying flash memory. However, I'm wondering if this erasure means that the data is actually unreadable, even when a user is able to put the drive in factory access mode, or has access to the physical flash chips. I've read that the data is zeroed-out (DZAT) or some other deterministic value (DRAT) when accessed sector-by-sector through the typical SAS/SATA interface, for example when using the dd command in Linux, but that only covers blocks mapped by the FTL and of course does not necessarily mean the physical memory is erased.

Are fully TRIMmed blocks truly, completely erased, or only presented as such to the OS?

Answer 1

If you want to use regular drive electronics, the answer is, there's absolutely no way to recover the erased data blocks from flash storage like SSDs, USB sticks, SD cards, etc.

See https://www.silicon-power.com/blog/index.php/guides/nand-flash-memory-technology-basics/ for some info on how flash memory storage works.

The tricky part of securely erasing an SSD comes from knowing that the data blocks you want to erase, have actually been erased, and are not just in the garbage collection queue, or in the reserve space area, or in some other special SSD controller area of storage.

There is also the possibility of some data still in blocks that are left over on the bad block list, that the drive is unable to erase any more times and has remapped those addresses to still working areas.

Something a lot of people seem to ignore, is that the SSD controller is continuously trying to maximise the number of erased data blocks. This is to maximise the drive performance. If the OS tells the drive to delete and TRIM (or UNMAP) all of the usable data areas then, giving the drive has long enough to complete the task, it should also cycle through the reserved space too. If the drive has zero remapped or bad blocks, then 100% of your data is unrecoverable, even by data recovery businesses.

Answer 2

In many common cases, files on an ssd drive are encrypted nowadays, and very often each file has its own encryption key. When the file is deleted, the encryption key is thrown away. So in the best case, you might be able to recover the encrypted data, but you can’t decrypt it, so it is useless. In this situation you’d need to be able to recover the deleted directory entry first.

The next bit is a bit complicated. Say you bought a 1TB SSD drive. There are 250 million logical blocks numbered 0 to 249,999,999. The computer can only read/write data using logical block numbers. That’s the lowest level for the computer, below the level of the file system.

The SSD controller maps logical to physical blocks. Physical blocks are the actual hardware level. Your 1TB SSD might have say 260 million physical blocks. The mapping logical to physically changes all the time, mostly because the SSD hardware can only write to physical blocks that are zeroed. So you write to logical block 7 which is currently mapped to physical block 113. But the controller cannot write to block 113 because it is not zeroed! The controller has set aside some area of zeroed blocks, say 200 to 231. So the data is written to zeroed physical block 200, logical block 7 is remapped from 113 to 200, and physical block 113 is “unused”.

The old data is still inside physical block 113 - but there is just no way to access it! All access has to go through a logical block, but there is no logical block mapped to physical block 113, so there is no way to read it.

So that’s why you can’t read the originals of blocks that were overridden. Now come deleted files: If you delete a file with logical blocks 100 to 145, then the computer issues a TRIM command for logical blocks 100 to 145. This removes the mapping of the logical blocks, and their physical blocks they were mapped to get marked as “unmapped” just as if they had been overwritten. The computer cannot read the physical blocks anymore, because no logical blocks are mapped there.

(Why is this done? Performance of an SSD drive depends on the number of unused physical blocks. That’s quite important for write operations. It’s ten times more important for TLC / QLC drives using pseudo-SLC. In the example, there are just 40 GB unused physical blocks. Without TRIM, once a file is written, the physical blocks stay “used” forever even if you delete half your files. )