In their 2018 paper "Solid state drive forensics: Where do we stand?", Vieyra et al. discuss recovering deleted data from SSDs.

For their experiments, they wrote large amounts of text to twelve SSDs, then shift-deleted the files, and tried to recover data using X-Ways Forensics.

This graph shows how much data they were able to recover:

Percentage of recovered data

Here, I assume that drives 7 (75 % recovered) and 11 (100 % recovered) don't implement TRIM correctly.

Reading the paper, the authors seem to offer no implicit or explicit explanation on why they were able to recover any data from those SSDs.

One conjecture I can come up with for those sub-percent data recoveries: Some pages in the SSD are faulty from the beginning, meaning writing to other pages in the same block works fine, but the block cannot be erased due to the faulty pages inside it. Making the page read-only after the first write.
On the other hand, the SSD's FTL would probably copy those pages to a different block consisting of healthy pages, marking the original block as bad and hiding it from the OS.

What are possible explanations for the authors being able to recover small percentages of deleted data from SSDs?

1 Answer 1


TRIM isn't a security measure; it's an optimization. Writing over already used flash is often more expensive than writing over unused flash, and TRIM is designed to reset the flash such that writing it is faster and more efficient. It's goal isn't specifically to destroy the data from the disk.

The most likely explanation for this situation is that a small amount of data ended up in the OS journal as part of writing the data to disk and it wasn't overwritten. It's also possible that one or more blocks weren't fully cleared because the OS reused them right away before TRIM was issued. The OS isn't obligated to send TRIM at all, for example, since it's just an optimization.

If you want to make sure that data on the disk is inaccessible to an attacker, then you must encrypt the disk. You should do this in software, because in general the standards for disk encryption (e.g., OPAL) don't sufficiently describe the cryptographic techniques to be used to ensure that the data is properly secured, and there are many examples where the encryption used in hardware or firmware is insecure.

  • Thanks for your answer! Regarding data being in the NTFS journal: I thought only metadata goes into the journal, not file content. Regarding the OS reusing blocks: Trying to better understand that scenario, let's say LBA #123 is 512 bytes in size and contains parts of the file that is deleted: 1. The user deletes the file. 2. Immediately afterwards, Windows decides it wants to write data to LBA #123. 3. Windows writes only a few bytes to that LBA #123, leaving some bytes of the deleted file available. Is this what you meant? Thanks again! Commented Oct 19, 2022 at 13:09
  • Whether actual data is journaled depends on the operating system and configuration. And yes, that's what I meant about reusing blocks.
    – bk2204
    Commented Oct 19, 2022 at 22:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .