51 min read

> Where you are: Part II, Chapter 9 of 40. Chapter 8 taught you to coax data from a hard drive that has failed mechanically — platters, heads, the clean room, the donor PCB. This chapter confronts a storage medium that breaks the most comforting...

In This Chapter

Exercises Quiz Case Study 01 Case Study 02 Key Takeaways Further Reading

Chapter 9: SSD and Flash Recovery — The Unique Challenges of Solid-State Storage

Where you are: Part II, Chapter 9 of 40. Chapter 8 taught you to coax data from a hard drive that has failed mechanically — platters, heads, the clean room, the donor PCB. This chapter confronts a storage medium that breaks the most comforting assumption in our trade. On a hard drive, deleted is not destroyed: the data waits, patiently, until something overwrites it. On a solid-state drive, the drive itself can become the thing that overwrites it — quietly, autonomously, within seconds of a deletion, with no help from the operating system and no way for you to stop it. This is the chapter where you learn when recovery is realistic, when it is impossible, and how to tell the difference before you bill a client for work that cannot succeed.

Learning paths: 💾 Data Recovery lives here — SSDs, USB sticks, and SD cards are now the majority of what walks through a recovery shop's door, and the economics of chip-off recovery are unforgiving if you misjudge a case. 🔍 Forensic Examiner: read every word of the forensic-integrity section — SSD non-determinism is the single biggest threat to the "the hash proves the image is unchanged" argument you will ever defend on the stand. 🛡️ Incident Response should understand TRIM's effect on what artifacts survive an attacker's cleanup. 📜 Legal/eDiscovery: "the deleted data is unrecoverable because the drive erased it" is a finding you will have to explain to a judge — learn why it is true.

Why an SSD is not a small hard drive

A client walks in with a 1 TB laptop drive. They emptied the Recycle Bin three days ago, then realized the folder of their late father's scanned letters went with it. On a hard drive, you would be quietly confident. You would image the drive (the original is sacred), mount the copy read-only, walk the NTFS Master File Table for entries whose in-use flag is cleared but whose $DATA runs still point at intact clusters, and — where the MFT entry itself was reused — carve the unallocated space for document and image signatures. Three days is nothing. The data is almost certainly there.

Then you notice the drive is an NVMe SSD. Your confidence should evaporate.

Here is what most likely happened in those three days, without anyone touching the machine. When the Recycle Bin was emptied, Windows did not just clear the file's pointer the way it would on a hard drive. It also sent the drive a TRIM command — a message that says, in effect, "the logical blocks that held those letters are no longer in use; do with them as you like." The SSD's controller took that as permission. It marked the physical NAND pages holding the scans as stale, dropped them from its internal address map, and — on its own schedule, powered but idle, with the laptop sitting closed in a drawer — its garbage collector erased the NAND blocks to make them ready for future writes. The scans are not waiting to be overwritten. They have already been electrically erased. There is no magnetic remanence to chase, no overwritten-once-but-faintly-readable myth to invoke. The charge that encoded those bits has been drained to a uniform state. The data is gone in a way that hard-drive data is almost never gone.

This is the central, disorienting fact of solid-state recovery, and it inverts the foundational theme of this entire book. On magnetic media, deletion removes a pointer and leaves the data; recovery is the rule and permanent loss is the exception you engineer with overwriting or destruction. On flash media governed by TRIM, deletion can trigger destruction, and permanent loss becomes the default you must rule out before you promise anything. Technology changed. The principle behind recovery — find the data that deletion left behind — did not change, but the amount of data that deletion leaves behind collapsed toward zero. Knowing precisely when it collapses, and when it does not, is the professional skill this chapter teaches.

Why This Matters. A recovery technician who runs the same playbook on an SSD as on an HDD will, sooner or later, accept a job, image the drive, run PhotoRec, recover nothing but zeros, and have to explain to a grieving client why three days were "too late" when on a hard drive three months would have been fine. The difference is not luck. It is TRIM, garbage collection, and the Flash Translation Layer — three mechanisms invisible to the operating system and to most software tools. You cannot reason about SSD recovery from the file-system layer alone. You have to understand what the controller is doing underneath it.

NAND flash from the cell up

To understand why an SSD behaves so differently, start with the physical medium. Chapter 3 introduced the anatomy; here we use it to reason about recoverability. (For the structural reference — page sizes, block sizes, OOB layout — see Appendix G — File-System and Media Reference.)

A hard drive stores a bit as a region of magnetic orientation on a spinning platter. You can rewrite that region in place as many times as you like; you can flip one bit without touching its neighbors; and the mapping from a logical sector number to a physical location on the platter is essentially fixed (give or take a small pool of remapped bad sectors). None of those three properties holds for NAND flash.

NAND stores a bit as electrical charge trapped on a floating gate (or in a charge-trap layer) inside a transistor. Reading a cell means sensing whether its threshold voltage is above or below a reference — for multi-level cells, sensing which of several voltage bands the charge falls into. The cells are organized into a strict hierarchy, and the granularity of operations at each level is what makes flash strange:

SSD package
├─ Controller  (embedded CPU + FTL firmware + ECC engine + AES engine)
│     └─ DRAM cache  (holds the hot part of the logical→physical map)
│
├─ Channel 0 ──► NAND die 0 ──► plane 0 / plane 1
│                                  └─ block ──► page ──► cell
├─ Channel 1 ──► NAND die 1 ──► ...
├─ Channel 2 ──► NAND die 2 ──► ...     (parallelism = speed)
└─ Channel N ──► NAND die N ──► ...

cell    : one transistor.   SLC = 1 bit · MLC = 2 · TLC = 3 · QLC = 4
page    : smallest READ / PROGRAM (write) unit.  ~4 KB – 16 KB of data
          + a "spare"/OOB region (~hundreds of bytes – ~2 KB) for ECC + metadata
block   : smallest ERASE unit.  ~128 – 1024+ pages  (≈ 512 KB – 16 MB)
plane / die / channel : units of parallelism the controller stripes across

The cell type matters for recovery because it determines endurance and error rate. A single-level cell (SLC) stores one bit and tolerates roughly 100,000 program/erase (P/E) cycles. A multi-level cell (MLC) stores two bits at maybe 3,000–10,000 cycles. Triple-level (TLC) stores three bits at perhaps 1,000–3,000 cycles, and quad-level (QLC) stores four bits and may survive only a few hundred to ~1,000 cycles. Every additional bit per cell crams more voltage bands into the same physical window, which means smaller margins, more read errors, heavier error-correction requirements, and — critically for chip-off recovery later in this chapter — a raw NAND dump that is far noisier and harder to reconstruct. The cheap consumer drives and memory cards you will see most often are TLC and QLC. They are the least forgiving to recover from at the physical level.

Read at a page, erase at a block: the asymmetry that explains everything

Two facts about NAND, taken together, force everything else:

  1. You write (program) at page granularity, but you erase at block granularity. A page might be 16 KB; a block might be 256 of those pages, 4 MB. You can program an individual page, but you cannot erase one. To "erase" a page you must erase its entire 4 MB block.

  2. You cannot reprogram a page in place. Flash programming can only push a cell from the erased state toward the programmed state. To put new data into a page that already holds data, the page must first be erased — and you cannot erase one page, only its whole block.

Put those together and the consequence is profound. When the operating system says "overwrite logical block 5,000,012 with this new content," the SSD cannot simply write to wherever block 5,000,012 lived before. That physical page is occupied and cannot be rewritten without erasing 4 MB of neighbors. So the controller does something the OS never sees: it writes the new content to a fresh, already-erased page somewhere else, and it updates an internal map so that "logical block 5,000,012" now points to the new physical location. The old physical page — still holding the previous contents — is marked stale, to be erased later in bulk.

That indirection is not an optimization the controller could skip. It is the only way to make flash behave like a rewritable disk at all. And it is the reason an SSD is, from the recovery and forensics point of view, a small computer running its own opaque operating system between you and the bits — not a passive platter that hands back whatever was written to a given location.

Why This Matters. The HDD mental model — "logical sector N is always physical location N, and reading it gives me whatever was last written there" — is false for SSDs at the physical level. The controller decides where data physically lives, when old copies are erased, and what a read of a "deleted" block returns. Recovery and forensics both depend on understanding that you are negotiating with the controller, not reading the medium directly. Strip the controller away (chip-off) and you face the raw, scrambled, interleaved, error-laden NAND with none of the controller's bookkeeping to make sense of it.

The Flash Translation Layer: the controller's secret bookkeeping

The "internal map" mentioned above has a name: the Flash Translation Layer, or FTL. It is firmware running on the controller, and its central job is to translate the Logical Block Addresses (LBAs) the host operating system uses into the Physical Block Addresses (PBAs) — specific die, block, and page — where the data actually sits in NAND. Everything that makes flash usable as a disk, and everything that makes it hard to recover, is the FTL doing its job.

   HOST VIEW (what the OS / file system sees)        PHYSICAL NAND (where bits live)
   ────────────────────────────────────────         ──────────────────────────────
   LBA 0x000000  ───────────────────────────────►   Die 0 · Block 0x0A2 · Page 0x05
   LBA 0x000001  ───────────────────────────────►   Die 1 · Block 0x0A2 · Page 0x05
   LBA 0x000002  ───────────────────────────────►   Die 0 · Block 0x1F7 · Page 0x11  (current)
                                                      └ old copy of LBA 2 still in
                                                        Die 0 · Block 0x0A2 · Page 0x07  [STALE]
   LBA 0x000003  ───────────────────────────────►   Die 2 · Block 0x33C · Page 0x00
   ...
   (this table — the L2P map — is itself stored in NAND and cached in DRAM)

Three things about this table drive every recovery decision you will make:

First, the map decouples logical order from physical order completely. Two LBAs that are adjacent to the operating system can live on opposite ends of the chip, on different dies, programmed months apart. A file the file system believes is contiguous may be physically scattered across dozens of blocks. When the controller is alive and serving reads, none of this matters — you ask for LBA 5,000,012 and get the current contents, in order. When the controller is dead and you have only a raw NAND dump, this scattering is the central problem of reconstruction.

Second, the map is the single point of failure. The L2P table lives in NAND (a copy is rebuilt into DRAM at power-up). If the blocks holding the map are corrupted — by a firmware bug, a power fault during an update, or wear — the controller may fail to mount the drive even though every byte of your data is intact in the NAND. The drive reports zero capacity, or refuses to be recognized, or drops into a read-only "panic" mode. The data is fine; the index to the data is broken. This is a common and recoverable controller-level failure, and it is the SSD analog of a corrupted partition table on an HDD — except you cannot just fix it with a hex editor, because the table format is proprietary and undocumented per controller family.

Third, the map's churn leaves ghosts. Because rewriting an LBA writes a fresh physical page and marks the old one stale (rather than erasing it immediately), older versions of data linger in stale pages until garbage collection gets to them. On a drive with plenty of free space and light write activity, those ghosts can persist for a long time. This is occasionally a recovery opportunity — and, for the forensic examiner, occasionally the source of a recovered prior version of a document that the suspect believed was overwritten.

Wear leveling: spreading writes, scattering history

NAND cells wear out — each P/E cycle degrades the oxide that traps charge, and after enough cycles a cell can no longer reliably hold a value. If the controller always wrote new data to the same physical blocks (the ones mapped to frequently changed LBAs, like a file-system journal or a swap file), those blocks would wear out in months while the rest of the chip sat pristine. Wear leveling prevents that by deliberately spreading writes across the whole chip.

Dynamic wear leveling distributes incoming writes to the least-worn free blocks. It only touches blocks that are already free, so it evens out wear among the "hot" data. Static wear leveling goes further: it periodically relocates cold, rarely changed data (your operating-system files, that archive you never touch) off low-wear blocks so those blocks can be returned to the free pool and put to work. The controller is, in effect, constantly shuffling your data around the chip to keep wear uniform.

For recovery, two implications follow. The benign one: wear leveling is why a single logical file's history can be physically scattered, and why old copies persist — the ghosts mentioned above. The dangerous one: static wear leveling means the controller will move and re-erase data you never asked it to touch, purely to balance wear. Powered on and idle, an SSD is not inert. It is housekeeping.

Garbage collection: the drive that erases itself

Stale pages — those marked invalid when their LBA was rewritten or trimmed — are scattered through blocks that also contain valid pages. The controller cannot erase a block to reclaim its stale pages without first preserving the valid pages it shares space with. Garbage collection (GC) is the process that does this: it selects a block with many stale pages, copies the still-valid pages out to a fresh block (updating the L2P map), and then erases the original block, returning it to the free pool.

The crucial property of garbage collection, the one that makes SSD forensics genuinely hard, is that it runs autonomously. The controller does GC in the background whenever the drive is powered and not too busy serving host I/O — even when the host is sending no commands at all. You can connect an SSD to a write blocker that perfectly prevents every host write, leave it sitting on the bench, and the controller can still be erasing blocks of stale data the entire time, because GC is internal to the drive and does not require — or even notice — host involvement.

BEFORE GC                          AFTER GC
Block 0x0A2                        Block 0x0A2  ── ERASED, returned to free pool
  Page 00  [valid  LBA 100]   ─┐     (the stale pages 02,03,05,07 are gone forever)
  Page 01  [valid  LBA 101]   ─┤
  Page 02  [STALE  old LBA 2] ─┼─►  Block 0x4E0 (fresh)
  Page 03  [STALE  old LBA 9] ─┤      Page 00 [LBA 100]   (valid pages relocated)
  Page 04  [valid  LBA 102]   ─┤      Page 01 [LBA 101]
  Page 05  [STALE  old LBA 5] ─┘      Page 02 [LBA 102]
  Page 06  [valid  LBA 103]            Page 03 [LBA 103]
  Page 07  [STALE  old LBA 2]          (the STALE contents are NOT copied — erased)

This single behavior is why so much of this chapter is about timing and triage. The recoverable ghosts of deleted data have a clock on them, and the clock is the controller's own GC scheduler, which you cannot read, predict, or pause.

War Story. A junior technician received a client's SSD with an accidentally deleted project folder. Wanting to "see if it even mounts" before going through the formality of imaging, they plugged it into their running Windows workstation. It mounted fine. Windows, seeing an NTFS volume with free space the file system considered unused, did exactly what modern Windows does on mount and during its idle maintenance: it issued TRIM for the unallocated ranges. By the time the technician got around to imaging the drive an hour later — properly, on a write blocker this time — the folder PhotoRec would have carved cleanly an hour earlier came back as zeros. Nothing the technician did after that mattered. On a hard drive, "let me just check if it mounts" is harmless. On an SSD, mounting it read/write on a live OS can be the act that destroys the data. The original is sacred, and on flash it is sacred and fragile: image first, every time, no exceptions, no "quick peeks."

TRIM: the command that makes data disappear

We have met TRIM twice now; it is time to define it precisely, because the single most important question in any SSD recovery is has TRIM run against the data you want? — and the second most important is can it still run before you finish?

Before TRIM existed, the SSD controller faced an information gap. The file system knows when a file is deleted — it clears the pointer and marks the clusters free. But that freeing happens entirely inside the file-system metadata; from the drive's point of view, nothing was written. The controller had no way to know those LBAs were now garbage from the host's perspective. It only learned an LBA was obsolete when the host eventually overwrote it with something new. Until then, the controller had to assume every LBA the host had ever written still held data worth preserving through every garbage-collection cycle. On a nearly full drive this was catastrophic for performance: the controller would dutifully copy "valid" pages during GC that the OS had abandoned long ago, doing enormous useless work and burning endurance.

TRIM (the ATA command; the SCSI equivalent is UNMAP, the NVMe equivalent is Deallocate) closes that gap. When a file is deleted or a volume is formatted, a TRIM-aware operating system proactively tells the drive: "these LBA ranges are no longer in use." The controller now knows it may treat the corresponding physical pages as stale immediately — it can drop them from the L2P map and reclaim them at the next convenient GC pass, without ever copying them again.

What does a read of a trimmed LBA return? The ATA standard defines determinism flags the drive advertises:

  • Non-deterministic TRIM — a read of a trimmed-but-not-yet-erased LBA may return the old data, zeros, or anything, and may differ between reads. This is the recovery-friendly case: the data may still be physically present until GC erases it.
  • DRAT — Deterministic Read After TRIM — reads return a consistent value, but the standard does not require it to be zero.
  • RZAT — Deterministic Read Zero After TRIM (sometimes written DZAT) — reads of trimmed LBAs return zeros, immediately and forever. The controller does not even need to wait for the physical erase; it drops the mapping, and any read of that LBA returns zeros because there is no mapping to follow. This is the recovery-hostile case, and it is the default behavior of most modern consumer and enterprise SSDs.

So the destruction sequence for a deleted file on a modern RZAT drive is:

t0  File deleted in NTFS  →  MFT entry's in-use flag cleared, clusters marked free
t0  OS issues TRIM for those LBA ranges          (Windows does this synchronously-ish)
t0+ Controller drops those LBAs from the L2P map  →  reads now return 0x00 (RZAT)
        ── from this instant, software recovery returns ZEROS, even before any erase ──
t?  Garbage collection erases the underlying NAND blocks  →  charge physically drained
        ── from this instant the data is gone at the silicon level; chip-off finds zeros ──

Notice that on an RZAT drive, the data is effectively unrecoverable by any normal software tool the instant the mapping is dropped — long before the physical erase. The controller will not hand you the old physical page; as far as any host-side tool can tell, the LBA is zeros. Chip-off can sometimes reach the still-present-but-unmapped physical page in the window before GC, which is one of the few scenarios where chip-off can beat software on a single drive — but that window is the controller's to close, not yours.

Here is what that looks like in the raw. A JPEG that the file system has deleted but TRIM has not yet processed still carries its signature and its data:

Offset      00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F   ASCII
0x0000_0000 FF D8 FF E0 00 10 4A 46  49 46 00 01 01 00 00 01   ......JFIF......
0x0000_0010 00 01 00 00 FF DB 00 43  00 08 06 06 07 06 05 08   .......C........
0x0000_0020 07 07 07 09 09 08 0A 0C  14 0D 0C 0B 0B 0C 19 12   ................
            ^^ FF D8 = JPEG SOI · FF E0 + "JFIF" = APP0  →  carvable, recoverable

The same logical range, after TRIM has run on an RZAT drive, is not "deleted file with cleared pointer." It is nothing:

Offset      00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F   ASCII
0x0000_0000 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
*                                                              (identical lines elided)
0x0010_0000 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
            ^^ no SOI, no signature, no slack, no fragments — the controller returns zeros

There is no clever tool that turns the second dump back into the first. A file carver scanning the second image finds no FF D8 to latch onto because there is no FF D8 to find. This is not a limitation of your software; it is the absence of the data.

Limitation. When a TRIM command has been processed against an LBA range on a Deterministic-Read-Zero-After-TRIM drive — which is most modern SSDs — the data in that range is gone. No software tool recovers it, because the controller returns zeros and the underlying NAND is erased on the GC schedule. Chip-off does not help once GC has run; before GC it might reach an unmapped physical copy, but you cannot know whether GC has run, and you cannot stop it. The honest professional answer is: recovery from a trimmed range on an RZAT SSD is not possible. Say so plainly, early, before the client pays for chip-off that will return a drive full of zeros.

When TRIM has NOT run: the recovery window

TRIM is the destroyer, so the entire art of optimistic SSD recovery is identifying the situations where TRIM did not fire, or could not. When the file system marked clusters free but no effective TRIM reached the controller, the SSD behaves much more like a hard drive: the controller still holds the old physical pages, a normal read of those LBAs still returns the old contents, and your familiar logical-recovery and carving techniques from Chapter 6 and Chapter 7 work. Recovery is genuinely possible in these cases:

  • Immediately after deletion, before the OS issues TRIM. There is a brief window — and if the machine was powered off right after the deletion, before the OS flushed its TRIM, the window stays open. This is the single most common save: the user realizes their mistake within seconds, you tell them to shut the machine down now (hard power-off, not a clean shutdown that may flush queued TRIM and run maintenance), and you image before powering it back into an OS.
  • TRIM disabled at the OS. TRIM can be turned off (deliberately, or by misconfiguration). On Windows, fsutil behavior query DisableDeleteNotify will tell you. If it is disabled, the drive never learned the LBAs were free, and the data persists like on an HDD.
  • External and USB-bridged SSDs. Many USB-to-SATA bridge chips — especially older ones — do not pass TRIM/UNMAP through to the drive at all. A portable SSD in a cheap enclosure, or a bare SSD the user connected through a USB adapter, may never have received a single TRIM in its life. (Newer enclosures using the UASP protocol can pass UNMAP, so this is not guaranteed — but it is common enough to always check.)
  • Hardware RAID members. Historically, many hardware RAID controllers and older software-RAID implementations did not pass TRIM to member drives. An SSD pulled from such an array may hold deleted data indefinitely. (See Chapter 10 — RAID Recovery for the array-level picture.)
  • Older operating systems. TRIM support arrived in Windows 7 (2009). Windows XP and Vista never issued it. A legacy system, or a drive that lived its life under an OS without TRIM, will have intact deleted data. On Linux, TRIM is only issued if the file system is mounted with the discard option or the periodic fstrim.timer is enabled — neither is universal. On macOS, TRIM is on by default for Apple's own SSDs but requires sudo trimforce enable for third-party drives.
  • File systems and configurations that do not issue TRIM for the relevant operation. Some operations and some file systems simply do not trim. Most importantly for the recovery shop:
  • SD cards, microSD cards, and camera media. Cameras, drones, dashcams, and most embedded devices use FAT32 or exFAT and do not issue TRIM. The card's own controller rarely implements aggressive autonomous erase. This is why memory-card recovery — including the kind that saves a wedding photographer's day — remains highly viable when laptop-SSD recovery of the same deleted files would be hopeless.

Try This. Build two practice images and feel the difference yourself (see Appendix J — Practice Images and Lab Setup). On a spare TRIM-enabled SSD, copy a folder of photos, delete them, wait a few minutes idle, then image the drive and run PhotoRec — count what you recover. Repeat the exact same steps on an SD card in a USB reader. The SD card will give you nearly everything; the SSD may give you nothing. Same files, same file system, same deletion — the only variable is who issued TRIM. That contrast is the whole chapter in one experiment.

Checking TRIM status before you waste your time

Because the recoverability of deleted data on an SSD hinges on TRIM, your first diagnostic step — before imaging, before quoting a price, before promising anything — is to determine whether TRIM was in play. You do this without writing to the evidence: query the drive's capabilities and the host's configuration, never trim it yourself.

On Linux, ask the drive what it supports and what it returns after TRIM:

# What does the SATA SSD advertise? Model + TRIM support + post-TRIM read behaviour.
sudo hdparm -I /dev/sda | grep -iE 'model|trim'
#   Model Number:       Samsung SSD 870 EVO 1TB
#        *    Data Set Management TRIM supported (limit 8 blocks)
#        *    Deterministic read ZEROs after TRIM      <-- RZAT: trimmed ranges read as 0x00

# Discard granularity per block device (a DISC-GRAN of 0 means no TRIM passthrough)
lsblk --discard
#   NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
#   sda           0      512B       2G         0

# NVMe: post-deallocate behaviour lives in the namespace DLFEAT field
sudo nvme id-ns /dev/nvme0n1 | grep -i dlfeat
#   dlfeat  : 0x9    # bit0 = read 0x00 after deallocate; bit3 = deallocate supported

# (NEVER run this on evidence — it is the destruction, not the diagnosis)
# sudo fstrim -v /mnt/case

On Windows, the most useful single query is whether the OS was issuing TRIM at all:

# 0 = delete-notification ENABLED (TRIM is ON);  1 = DISABLED (TRIM off -> data may persist)
fsutil behavior query DisableDeleteNotify
#   NTFS DisableDeleteNotify = 0   (Enabled)
#   ReFS DisableDeleteNotify = 0   (Enabled)

# Media type, health, and how much endurance has been used
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, @{n='GB';e={[int]($_.Size/1GB)}}
Get-PhysicalDisk | Get-StorageReliabilityCounter | Select-Object Wear, ReadErrorsTotal, Temperature

# Optimize-Volume -ReTrim forces a TRIM pass and is DESTRUCTIVE to recoverable data.
# It is listed here only so you recognize it and NEVER run it against evidence:
#   Optimize-Volume -DriveLetter C -ReTrim     # <-- do NOT run on a case drive

And in both worlds, read the drive's wear and health from SMART, which tells you both how much life is left and — via total bytes written — how much rewriting (and therefore how much GC and overwriting) the drive has done:

sudo smartctl -a /dev/sda | grep -iE 'Wear|Reallocated|Life|Total_LBAs|Percent|Available_Spare'
# SATA SSD (vendor IDs vary):
#   177 Wear_Leveling_Count   ... 095 ... 005      # ~5% of rated cycles used
#   241 Total_LBAs_Written    ... value -> bytes written over the drive's life
#   005 Reallocated_Sector_Ct ... grown defects
# NVMe:  sudo smartctl -a /dev/nvme0
#   Percentage Used:          4%
#   Data Units Written:       21,544,991 [11.0 TB]
#   Available Spare:          100%

Tool Tip. Run these reads through a hardware write blocker (Chapter 14 covers selection). A write blocker stops host writes — it does not stop the controller's internal GC, but it does guarantee that your diagnostic commands cannot accidentally modify the evidence, and it keeps the OS from auto-mounting and trimming the volume the way the War Story's workstation did. For the full command catalog, see Appendix H — Command-Line Reference.

Recovery technique: getting data back when TRIM hasn't won

Suppose your diagnostics are encouraging — the drive came through a non-TRIM USB bridge, or TRIM was disabled, or it is an SD card, or the user pulled power within seconds. The controller is alive and the deleted data is plausibly still mapped. Now SSD recovery looks much like HDD recovery, with three flash-specific disciplines layered on top.

Image first — and image fast. The original is sacred, but on flash the original is also a ticking clock. Unlike an HDD, where you can take your time imaging because nothing changes on its own, an SSD's controller may be running GC and static wear leveling the entire time it is powered. So you minimize the powered window: connect through a write blocker, image with dcfldd or ewfacquire straight through to a forensic container, verify the hash, and power down. Do not browse the live volume. Do not "just check." Every minute the drive is powered is a minute the controller can spend erasing the very pages you are trying to save. (Imaging mechanics, write-blocking, and hashing are owned by Chapter 14 — Forensic Acquisition; apply them here with the speed caveat.)

Triage the image before you commit hours to it. Once you have a copy, a thirty-second scan tells you whether carving is even worth attempting. The fingerprint of an RZAT drive that has been heavily trimmed is a sea of all-zero blocks in what should be unallocated, data-bearing space. Measuring that proportion up front sets expectations honestly — for you and for the client — before you burn an afternoon carving zeros:

#!/usr/bin/env python3
"""trim_triage.py - estimate how much of an acquired SSD image TRIM wiped.

Illustrative only; run against a forensic IMAGE, never a live original.
A high proportion of all-zero blocks is the fingerprint of Deterministic-
Read-Zero-After-TRIM (RZAT): it warns you that carving yield will be low
BEFORE you spend hours carving (or quote a client for a doomed chip-off)."""

import sys
import math
from collections import Counter

BLOCK = 4096  # one NAND-page-sized read unit

def shannon_entropy(buf: bytes) -> float:
    """Bits of entropy per byte: ~0.0 (uniform) .. 8.0 (random)."""
    if not buf:
        return 0.0
    n = len(buf)
    return -sum((c / n) * math.log2(c / n) for c in Counter(buf).values())

def main(path: str) -> None:
    total = zero_blocks = high_entropy = 0
    with open(path, "rb") as image:
        while True:
            block = image.read(BLOCK)
            if not block:
                break
            total += 1
            if block.count(0) == len(block):
                zero_blocks += 1            # all 0x00 -> TRIM / RZAT footprint
            elif shannon_entropy(block) > 7.5:
                high_entropy += 1           # near-random -> encrypted/compressed
    if total == 0:
        print("empty image")
        return
    zpct = zero_blocks / total
    print(f"blocks scanned : {total:,} x {BLOCK} B")
    print(f"all-zero       : {zero_blocks:,} ({zpct:6.2%})   <- TRIM / RZAT footprint")
    print(f"high-entropy   : {high_entropy:,} ({high_entropy / total:6.2%})   <- encrypted/compressed")
    verdict = ("heavy zeroing -- TRIM almost certainly active; carve yield will be low"
               if zpct > 0.40 else
               "substantial non-zero data survives -- carving is worth attempting")
    print(f"verdict        : {verdict}")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("usage: trim_triage.py <image.dd>")
    main(sys.argv[1])

Run against the unrecoverable laptop image from the worked example below, it quantifies exactly why the carvers came back empty:

$ python3 trim_triage.py /cases/laptop_nvme.dd
blocks scanned : 244,190,646 x 4096 B
all-zero       : 190,468,704 ( 78.00%)   <- TRIM / RZAT footprint
high-entropy   : 9,767,625 (  4.00%)   <- encrypted/compressed
verdict        : heavy zeroing -- TRIM almost certainly active; carve yield will be low

That single number — 78% of the drive reading as zeros — is the difference between a hopeful client conversation and an honest one. It is not proof on its own (a genuinely empty drive also reads as zeros), but combined with the TRIM-status diagnostics above it tells you, in seconds, which kind of case you are in. (A reusable, hardened version lives in Appendix B — Python Forensics Toolkit.)

Then work the copy with logical recovery, then carving. With a clean image in hand, the methods are the ones you already know. Walk the file-system metadata for deleted entries that still reference live data — for NTFS, MFT records with the in-use flag cleared whose $DATA attribute runs point at clusters the controller will still hand back (Chapter 6). Where the metadata is gone, fall back to signature-based carving across the unallocated and slack space (Chapter 7), matching headers and footers from Appendix A — File-Signatures Reference. The key realization is that on a non-trimmed SSD, "unallocated space" still contains data, exactly as it would on an HDD, because no TRIM told the controller to drop those mappings.

Read external SSDs through the same bridge that protected them — or a known non-TRIM path. If a portable SSD's deleted data survived because its USB bridge never passed TRIM, image it through that bridge (or an equivalent), not by shucking the bare drive into a TRIM-passing adapter that might trim it on connection. The path that preserved the data is the path that should acquire it.

For SD cards and monolithic media, read the card directly. A memory card connected through a plain card reader presents its FAT/exFAT volume with deleted directory entries and intact clusters, just like a non-trimmed disk. Image it and carve. This is the route by which the deleted-wedding-photos scenario from Chapter 1 is so often a happy ending when the photos lived on the camera's SD card — cameras do not trim, the card controller does not aggressively self-erase, and a reformatted-in-camera card typically leaves the prior photos fully carvable. (Contrast that with the same photographer's laptop, where the imported-then-deleted copies on a TRIM-enabled NVMe drive may be unrecoverable. Same photos, two media, two completely different prognoses — the human stakes are identical, but the physics are not.)

Recovery vs. Forensics. The same intact, non-trimmed SSD is approached two ways. The recovery engineer optimizes for speed and yield: image quickly, run the strongest carvers, return the maximum number of usable files, and accept whatever method gets the client's data back. The forensic examiner optimizes for defensibility: write-blocked acquisition, two independent hashes, contemporaneous notes, an unbroken chain of custody, and — uniquely for SSDs — explicit documentation that the medium is non-deterministic and that the image is a point-in-time snapshot of a drive that may have been altering itself. Recovery asks did I get the data back? Forensics asks can I prove this is what was on the drive, unaltered by me? On an SSD, that second question is harder than on any other medium you will handle, for reasons the forensic section below makes precise.

When the controller dies: chip-off recovery

So far we have assumed the controller is alive and talking. Often it is not. SSD controllers fail — from power surges and bad power supplies, from firmware bugs and corrupted firmware, from the L2P map being damaged, from too many failed blocks overwhelming the spare pool, from a cracked solder joint on a dropped laptop. When the controller is dead, the drive may be utterly unresponsive: not detected, zero capacity, or stuck in a vendor "safe mode." Yet in many of these cases the NAND is perfectly intact. Every byte of the user's data is still sitting in the flash chips. The problem is purely that the brain that knows how to read and assemble it is broken.

For controller-level firmware and translator faults, the specialist's first move is not chip-off at all but controller-level repair: tools like PC-3000 SSD can talk to a drive in its factory/technological mode, reload or patch the firmware, rebuild the translator, and bring the drive back to life — recovering the data in logical order without ever touching a soldering iron. This is faster, cheaper, and far less error-prone than chip-off, and it should always be attempted first when the controller is reachable at all.

When the controller is truly dead or the architecture forbids logical repair, the last resort is chip-off recovery: physically removing the NAND chips and reading them directly.

Desoldering the NAND

NAND packages come in two main physical forms. TSOP (thin small-outline package) chips have legs around the perimeter and are comparatively forgiving to remove and read. BGA (ball grid array) packages hide their connections as a grid of solder balls underneath the chip, and are far less forgiving. Removal uses a hot-air rework station and an infrared preheater to bring the whole board up to temperature so the target chip can be lifted without thermally shocking it or lifting pads. The chip is then cleaned, its balls reflowed or re-balled if BGA, and seated in an adapter for a NAND reader.

This is destructive, delicate, hardware-intensive work. It requires real equipment (rework station, preheater, microscope, the right adapters), real skill (a slipped iron lifts a pad and you have lost a die), and a clean, controlled environment. It is not something you improvise. It is also why chip-off is expensive — the labor and equipment are substantial, and the per-case risk is real.

Reading the raw dump

With the chip in an adapter, a NAND reader (or programmer) clocks out the raw contents: every page, including the spare/OOB region that holds the ECC bytes and the controller's per-page metadata. What you get is a faithful copy of the silicon — and a useless-looking mess. A raw NAND dump is not your data. It is your data after the controller put it through several transformations on the way in, none of which the reader reverses:

Raw NAND page 0x0000 (as read off the chip) — high entropy, no recognizable structure:
0x0000  3A 9F 2C E1 04 7B BD 55  C8 12 6E A0 F3 49 8D 21   :.,..{.U..n..I.!
0x0010  7E 0B C4 9A 55 31 EF 68  12 AB 0C D7 44 90 1F 6C   ~...U1.h....D..l
        ^^ looks like noise — this is scrambled, interleaved, ECC-laden raw flash

Reassembling the image: undoing the FTL

Turning that raw dump into a mountable file-system image means reversing, in order, everything the controller did. This is the genuinely hard, controller-specific science of flash recovery, and it is why the tools that do it cost what a car costs.

  • ECC correction. NAND is expected to return some bit errors on every read; the controller corrects them using error-correcting codes stored in the OOB region — BCH on older MLC/SLC parts, LDPC on modern TLC/QLC. You must identify the ECC scheme, locate the codewords, and apply correction. Pages with more errors than the code can fix are uncorrectable and become holes in your reconstruction.
  • De-scrambling (de-randomization). Modern controllers XOR the data with a pseudo-random sequence (a PRBS, often keyed by the page address) before writing it, to avoid pathological charge patterns that cause read disturb. The raw dump is scrambled; you must identify the scrambler and reverse it. Get the seed or polynomial wrong and you get noise.
  • De-XOR. Some controllers additionally XOR data across planes or with a key held in the service area, for performance or rudimentary protection. That layer must be undone too.
  • De-interleaving. For speed, controllers stripe a single logical run across multiple dies, planes, and channels. The raw dump from one chip is one slice of an interleaved whole; the pieces must be reassembled in the controller's striping order, which you must determine empirically.
  • Reconstructing the translation (L2P). Finally, with corrected, de-scrambled, de-interleaved pages in hand, you must rebuild the logical order from physical order — reading the per-page metadata markers the controller wrote and inferring which physical page holds which logical block, so the scattered pages line up into the linear image the file system expects.

Only after all of that do you have something an ordinary forensic suite can mount and analyze. A successful reconstruction session reads like this:

PC-3000 Flash :: project SSD_Phison_S11
[*] Physical dump   : 2 × TLC die · 16 KB page + 1872 B spare · 1024 pages/block
[*] ECC             : LDPC, 2 KB codeword — 11,318 pages corrected, 4 uncorrectable
[*] Scrambler       : Phison PRBS detected — de-randomizing ............ OK
[*] XOR             : page-address-keyed — key recovered from service area  OK
[*] Interleave      : 2-channel × 2-plane — de-interleaving ............ OK
[*] Translator      : building L2P from page headers ................... 99.97%
[*] Image assembled : 238.4 GB logical · 47 holes (uncorrectable / erased blocks)
[+] Mounting NTFS   : MFT intact · 184,221 files · 1,902 deleted entries present

Notice the 47 holes and the 4 uncorrectable pages: chip-off rarely yields a perfect image. It yields a mostly complete one, with gaps where blocks were worn, erased, or beyond ECC. For documents and photos that is often fine — a few corrupt files among thousands recovered. For a single critical database with a corrupt page in the wrong place, it may not be.

The encryption wall

There is one development that increasingly renders all of the above pointless, and you must check for it before quoting a chip-off job. Many modern SSDs are self-encrypting drives (SEDs): the controller transparently encrypts everything with AES-256 using a key the controller manages, whether or not the user ever enabled any encryption. The user sees an ordinary unencrypted-looking drive; the NAND holds nothing but ciphertext. (This is also how "instant secure erase" / crypto-erase works: the drive discards the key and every byte becomes unrecoverable noise in milliseconds — the fastest, most complete destruction in this book.)

If the drive is an SED and you do chip-off, you will dump, ECC-correct, de-scramble, de-interleave, and reassemble — and arrive at a perfect image of ciphertext that is worthless without the controller's key, which lived in the (now removed or dead) controller. Chip-off does not break encryption. For an SED, if the controller is dead and the key is unrecoverable, the data is gone regardless of how pristine the NAND is. Encrypted-device recovery and its narrow exceptions are the subject of Chapter 29 — Encrypted Device Forensics; the lesson here is simply: determine whether the drive is encrypted before you desolder anything.

Recovery vs. Forensics. Chip-off is destructive acquisition — you have altered the evidence by desoldering it, and the drive will never again function. For pure recovery, that is an acceptable cost: the client wants files, not a working drive, and you document the work for your own records. For forensics, destructive acquisition is a serious step that must be justified (no non-destructive route was available), authorized (counsel/court aware), and meticulously documented — every chip removed, every transformation applied, every assumption in the reconstruction recorded — because the defense will and should probe a reconstructed image far harder than a straightforward write-blocked one. A reassembled chip-off image is admissible, but only if you can walk a court through how raw scrambled silicon became the image you analyzed, and why your reconstruction is reliable. That is a demanding testimony to give (see Chapter 27 — Expert Testimony).

Monolithic flash: USB sticks, SD cards, and eMMC

Chip-off assumes you can separate the NAND from the controller — that they are distinct components on a board. For a large class of devices, they are not. Monolithic flash integrates the controller and the NAND die (sometimes several dies) into a single package, even a single piece of silicon. You see this in the small and the cheap: most USB thumb drives, SD and microSD cards, and many embedded storage parts. There is no NAND chip to desolder, because the NAND is not a separable chip.

Recovering a dead monolith means reading the NAND through the package, by locating the technological points — the test pads or pins inside the monolith that connect directly to the NAND's data and control lines, bypassing the dead controller. The specialist grinds or x-rays the package to find these points, micro-solders fine wires to them, and reads the raw NAND through an adapter, then performs the same ECC/de-scramble/de-interleave/translate reconstruction as a chip-off. It is even more delicate than ordinary chip-off — the points are tiny, undocumented per part, and unforgiving — and it is correspondingly expensive and uncertain.

A related, more tractable family is eMMC and UFS, the storage in phones, tablets, and many embedded systems. These often expose standardized access for service or recovery: eMMC can frequently be read via its standard interface using direct connection to its pads, and many phone boards expose JTAG or ISP (In-System Programming) test points that let you read the raw flash without desoldering anything, by connecting to test pads on the board. This is a primary technique for mobile devices and is developed in Chapter 11 — Mobile Device Recovery and forensically in Chapter 24 — Mobile Device Forensics. The same caveat as SEDs applies with a vengeance: modern phones encrypt by default and tie the key to a hardware element, so a raw eMMC/UFS dump of a locked modern phone is ciphertext.

War Story. A finance employee was suspected of walking off with a customer list, and the only lead was a no-name USB stick found in their desk that no longer enumerated on any machine. It was a monolith — controller and NAND fused in one package — with a snapped USB connector and, the lab suspected, a blown controller. There was no chip to desolder. A monolith specialist x-rayed the package to map the technological points, micro-soldered to the NAND data lines, dumped the raw flash, reversed the scrambler and ECC, rebuilt the FAT32 volume, and recovered the deleted spreadsheet — last modified two days before the employee resigned. The lesson is double-edged: the data was recoverable because a cheap thumb drive's controller does little autonomous erasing and FAT issues no TRIM — and it cost more in specialist labor than the laptop it was copied from. (This thread continues in the corporate-IP investigation that anchors Chapter 16 and Chapter 21, where the Windows USB-device-history artifacts independently prove the same stick was plugged into the suspect's workstation.)

Tools of the trade

SSD and flash recovery splits cleanly into two tool categories, matching the two failure scenarios.

For controller-alive, TRIM-not-run recovery, you use the same logical-recovery and carving tools as for hard drives, just with the speed and write-blocking discipline above: dcfldd/ewfacquire to image, then DMDE, R-Studio, testdisk/photorec, foremost/scalpel, and The Sleuth Kit (fls, icat) to recover. These are cataloged in Chapter 36 — The Forensic Toolkit and Appendix C — Tool Reference. Nothing here is SSD-specific except the judgment about whether the data is there to recover.

For controller-dead / chip-off / monolith recovery, you need the specialized flash-reconstruction platforms, which are professional, costly, and steeply technical:

  • PC-3000 Flash (ACE Lab) — the de-facto industry standard for chip-off NAND reconstruction, with an enormous database of controller profiles (the XOR/scrambler/ECC/translator parameters for thousands of controller families). Its sibling PC-3000 SSD handles controller-alive firmware repair and translator rebuilds without desoldering.
  • Flash Extractor / Soft-Center — a widely used chip-off reconstruction suite with its own controller-profile database.
  • Rusolut Visual NAND Reconstructor (VNR) — strong at the visual, manual analysis of raw dumps when no profile exists: spotting the page structure, deducing the ECC and scrambler by inspection, working out the interleave by eye.
  • NAND readers/programmers and BGA/TSOP adapters, plus a hot-air rework station, IR preheater, and microscope for the physical removal.

A diagnostic walk with these tools is methodical: identify the controller and NAND, dump raw, find and apply ECC, find and reverse the scrambler/XOR, work out the interleave, rebuild the translator, assemble, mount, and only then recover files. The reconstruction-session output shown earlier is representative of that workflow's end state.

Limitation. None of these tools is a "recover SSD" button. They are precision instruments that assist an expert in reversing a specific controller's transformations. Where the controller is unknown and no profile exists, reconstruction can take days of manual analysis and may fail. Where the drive is encrypted, they reconstruct ciphertext. Where TRIM and GC have run, they reconstruct zeros. The tool does not change the physics; it only lets a skilled operator work with what the physics left behind.

The forensic problem: an SSD that changes under your hands

Everything to this point applies to recovery and forensics alike. But solid-state storage poses a problem unique to forensics, and it strikes at the discipline's foundational claim. The whole architecture of digital evidence rests on hashing: you image the original, compute a cryptographic hash (MD5, SHA-256), and that hash proves — to a near-mathematical certainty — that your working copy is byte-for-byte identical to what you acquired, and that nothing has changed it since. "I can prove I found this and it is unaltered" is the difference between evidence and a story. On a hard drive the chain is clean: hash at acquisition, hash again later, the values match, integrity proven.

SSDs break this in a way that became a landmark discussion in the field (Bell and Boddington's 2010 paper, Solid State Drives: The Beginning of the End for Current Practice in Digital Forensic Recovery?, named the problem). The trouble is non-determinism: because garbage collection and static wear leveling run autonomously whenever the drive is powered, the contents of the unallocated and stale regions can change after you seize the drive — even while it sits on a write blocker, because the write blocker stops host writes but not the controller's internal operations. Two images of the same SSD taken minutes apart can therefore differ, and produce different hashes, not because anyone tampered with the evidence but because the drive rearranged its own internals.

HDD                                  SSD
seizure  -> image  -> SHA-256: A     seizure  -> image  -> SHA-256: A
later    -> image  -> SHA-256: A     later    -> image  -> SHA-256: B   (!)
"identical -> integrity proven"      "different -> integrity ... explained, not disproven"
        nothing changes on its own           GC/wear-levelling changed unallocated areas

A defense attorney will seize on a hash mismatch: "Your own tools say the drive is different from what you seized. How can you ask the jury to trust any of your analysis?" The professional answer is not to hide the mismatch but to understand and explain it. The right responses, which belong in your notes and your report from the moment you recognize the drive is solid-state:

  • Acquire immediately and minimize powered time. The less time the drive spends powered, the less the controller can change. Image at the earliest opportunity, then power down.
  • Use a write blocker anyway. It cannot stop GC, but it guarantees you introduced no host writes and prevents auto-mount/auto-TRIM — narrowing the cause of any change to the drive's own internal housekeeping, which is defensible, rather than examiner error, which is not.
  • Hash the allocated, file-resident data separately. The files themselves — the ones the file system still references — do not change under GC; it is the unallocated and stale regions that drift. Per-file hashing of the live evidence remains stable and provable even when the full-drive image hash does not.
  • Document the medium's behavior in the report. State plainly that the device is an SSD, that SSDs perform autonomous internal operations that can alter unallocated areas independent of host activity, that this is an inherent property of the technology and not a sign of tampering, and that your acquisition was conducted to minimize and account for it. An examiner who explains SSD non-determinism before the cross-examiner raises it is credible; one who is surprised by it on the stand is not.

Chain of Custody. Your custody documentation for an SSD must capture when the drive was powered and for how long, because powered time is when uncontrolled internal change can occur. Record power-on at seizure, the acquisition start/end, and power-off, with timestamps — and never leave an evidence SSD sitting powered "to keep it ready." Powered-and-idle is precisely the condition under which garbage collection does its quiet damage. Powered time is now a custody fact, not just a convenience detail.

Legal Note. TRIM has a second forensic consequence beyond hashing: it can erase the very evidence in question. If a suspect deleted files and the OS trimmed them on an RZAT drive, those files may be genuinely unrecoverable — not "we did not find them" but "they cannot be recovered because the device erased them." This cuts both ways. It can defeat the prosecution's hope of recovering deleted contraband, and it can equally mean the absence of recovered files proves nothing about whether they once existed. "The evidence is insufficient to determine whether such files were present, because TRIM on this device renders deleted data unrecoverable" is a complete, professional finding. It is also a humbling one: on this medium, the deleted-equals-not-destroyed assumption that powers so much of forensics simply does not hold, and saying so is more honest than implying a recovery attempt could have succeeded.

In the child-exploitation matter that anchors this book's most consequential thread (introduced in Chapter 5 and handled throughout with clinical restraint — procedure, law, and ethics only), the suspect's laptop being an NVMe SSD reshaped the entire technical narrative. Two facts had to be explained to the court without overclaiming: first, that the full-disk image hash taken in the lab differed slightly from a verification image, which the examiner attributed — correctly and defensibly — to autonomous SSD housekeeping in unallocated space, while the file-resident evidence hashed identically both times; and second, that some deleted material in unallocated regions was unrecoverable because of TRIM, so the case had to rest on the files that were present and provably accessed (via timestamps, EXIF, and browser history covered in Chapters 20 and 18), not on speculation about what TRIM had erased. The examiner's willingness to state the limitation plainly — to distinguish "we recovered X and can prove it" from "we cannot know what TRIM destroyed" — was, in the end, what made the recovered evidence credible. Overclaiming on an SSD is how an examiner loses a case that the honest evidence would have won.

Ethics Note. Two ethical duties converge on solid-state evidence. The first is honesty about limits: never imply that a recovery attempt could have succeeded where TRIM made it impossible, and never let a hash mismatch you understand go unexplained — the temptation to quietly smooth over an SSD's awkward non-determinism is exactly the temptation to resist. The second is examiner well-being: the most consequential cases are often the most disturbing, and the clinical detachment this chapter models — procedure, law, and findings, never the content — is a protective professional skill, not coldness. Both duties are developed fully in Chapter 28 — Ethics; notice here only that the medium's technical limits and the examiner's ethical obligation meet in one sentence — say only what the evidence proves.

Worked example: two cards, two prognoses

Nothing teaches SSD recoverability like watching the same kind of deletion play out on two different media. Here are two short, concrete walk-throughs that a recovery shop sees constantly — one a save, one a hard "no."

Case A — the reformatted camera card (recoverable)

A wedding photographer reformatted a 64 GB SDXC card in the camera at the start of a shoot, then realized it still held the only copies of a prior couple's ceremony — never offloaded. The card is exFAT; the camera, like virtually all cameras, issues no TRIM, and the card's controller does not autonomously erase.

You connect the card through a plain USB card reader behind a write blocker and image it immediately:

sudo dcfldd if=/dev/sdb of=/cases/sdcard_A.dd hash=sha256 \
            hashlog=/cases/sdcard_A.sha256 bs=1M conv=noerror,sync
# 60,906 MB in / 60,906 MB out
# Total: sha256 9f1c...c4e2

An in-camera reformat of exFAT typically writes a fresh, nearly empty directory and FAT but leaves the prior photo clusters untouched. Carving the image for JPEG and camera-raw signatures finds them intact:

photorec /log /d /cases/recovered_A /cmd /cases/sdcard_A.dd partition_none,fileopt,jpg,enable,cr2,enable,search
#   ... 1,043 files recovered (jpg: 921, cr2: 122)

Spot-checking a carved file confirms a clean JPEG header (FF D8 FF E1 with an Exif APP1 marker) and, decoded, a valid image with intact EXIF — the photos are back. The card was recoverable for exactly the reasons this chapter belabored: no TRIM was ever issued, the controller did no autonomous erase, and "reformat" on this medium meant "rewrite the directory," not "erase the data." Three weeks had passed and it did not matter.

Case B — the deleted folder on a laptop NVMe (unrecoverable)

The same week, a client deletes a project folder from their laptop's 1 TB NVMe SSD, empties the Recycle Bin, and brings it in two days later. You begin, as always, by diagnosing rather than promising. fsutil behavior query DisableDeleteNotify on the (write-blocked, read-only) drive's configuration returns NTFS DisableDeleteNotify = 0 — TRIM was enabled. hdparm -I-equivalent NVMe identification shows the namespace reports read-zero-after-deallocate. The OS issued TRIM at deletion; the drive is RZAT.

You image it anyway — diligence, and the off chance of mapped survivors — and run the carvers. The unallocated space where the folder lived is zeros:

0x12_8000_0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
*
0x12_C000_0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
# photorec: 0 files recovered in the target range

There is nothing to carve because there is nothing there. You do not bill the client for a chip-off, because chip-off would reconstruct the same zeros: TRIM dropped the mappings and GC has had two days to erase the NAND. The professional act here is the conversation you have on day one — explaining, kindly and clearly, that on this device deletion plus TRIM is destruction, that no honest lab can recover it, and that the lesson (backups, and pulling power immediately next time before the OS trims) is the real takeaway. The human cost is identical to Case A — someone lost something they cared about — but the physics handed down opposite verdicts. Knowing which case you are in, fast, is the skill.

Common mistakes

  • Treating an SSD like a hard drive. Running the HDD playbook — take your time, browse the live volume, "check if it mounts," carve unallocated space expecting deleted files — on an SSD wastes the recovery window and may itself trigger the TRIM that destroys the data. The medium is not a small hard drive.
  • Powering the drive longer than necessary. Every powered minute is GC time. Examiners and technicians who leave an evidence SSD connected and idle "to be ready" are letting the controller erase stale data and drift the unallocated hash. Image fast, power down.
  • Mounting evidence read/write on a live OS. This is the War Story. A modern OS auto-mounts, sees free space, and issues TRIM. Always use a write blocker and acquire read-only; never let the case OS touch a writable evidence volume.
  • Promising chip-off as a cure-all. Chip-off does not beat TRIM-plus-GC (it finds zeros), does not beat encryption (it finds ciphertext), and is not guaranteed to succeed even on intact, unencrypted NAND (unknown controllers, uncorrectable blocks). Quoting a client for chip-off without first ruling out TRIM and encryption is how you bill for a drive full of zeros.
  • Skipping the TRIM/encryption diagnosis. The two questions that decide the whole case — was TRIM issued? and is the drive encrypted? — are cheap to answer and must be answered before any quote or any desoldering. Diagnose first, promise second.
  • Letting a hash mismatch panic you (or hiding it). On SSDs, a full-image hash mismatch from autonomous GC is expected, explainable, and not tampering. Hiding it is misconduct; being surprised by it on the stand is incompetence. Document the medium's non-determinism up front and hash file-resident evidence separately, where it remains stable.
  • Reformatting "just to test the drive." A quick format on an SSD can issue TRIM across the whole volume. Never format, write, or "test by using" an evidence or client SSD.

Limitations: knowing when to stop

This is the chapter where theme #5 — know your limitations — is not advice but arithmetic. There are situations on flash where the correct professional action is to stop, and to say so:

  • TRIM has processed the target range on an RZAT drive. The data is gone. No software recovers zeros; chip-off recovers zeros once GC has run, and you cannot know GC has not run. Stop, and tell the client the truth.
  • The drive is a self-encrypting drive and the key is unrecoverable. A perfect chip-off image of ciphertext is worthless. If the controller (which holds the key) is dead and no recovery key exists, the data is unrecoverable regardless of NAND health. (The narrow exceptions live in Chapter 29.)
  • Crypto-erase / ATA Secure Erase has run. The drive discarded its encryption key. Every byte became noise instantly. There is nothing to recover, period.
  • The NAND itself is physically destroyed or worn past ECC. Cracked dies, fire/water damage that reached the silicon, or wear that pushed too many blocks beyond ECC correction leave holes that no reconstruction fills. Partial recovery may still be worth attempting; total recovery may be impossible.
  • The controller is unknown and unprofiled, with no recoverable translator. Chip-off reconstruction without a controller profile is sometimes possible by manual analysis (Rusolut VNR territory) and sometimes simply is not, within any reasonable time or budget. There is a point where the honest estimate is "this may not be recoverable, and the attempt is open-ended and expensive."

Stopping is not failure. "Recovery from this device is not possible because TRIM and garbage collection have erased the data" and "the evidence is insufficient to reach a conclusion because the device's TRIM behavior renders deleted data unrecoverable" are correct professional findings, delivered early and clearly. The technician who knows when to stop protects clients from paying for impossible work, and the examiner who knows when to stop protects the court from conclusions the evidence cannot support.

Progressive project: account for the medium in your case file

Your simulated investigation now confronts solid-state media. Add the following to your Forensic Case File:

  1. Identify and document the medium. Record that the subject system's primary storage is an NVMe SSD (or whatever your practice image emulates), with model, capacity, and — critically — its TRIM determinism (RZAT/DRAT/non-deterministic) and whether it is self-encrypting. Capture the host's TRIM configuration (fsutil behavior query DisableDeleteNotify output or the Linux equivalent).
  2. Acquire with the SSD discipline. Note your write-blocked, minimal-powered-time acquisition, with power-on and power-off timestamps in the chain-of-custody record. Compute and record acquisition hashes.
  3. Test for and document non-determinism. If your practice image supports it, acquire twice and compare full-image hashes; whether they match or not, write a short paragraph for the report explaining SSD autonomous-operation behavior and why a full-image hash mismatch would not indicate tampering. Hash the file-resident evidence separately and note its stability.
  4. State the TRIM limitation in your findings. Add a finding that distinguishes what deleted data is recoverable from what TRIM may have rendered unrecoverable, in the plain, non-overclaiming language this chapter modeled. This paragraph will fold directly into the report you assemble in Chapter 26 and defend in Chapter 27, and it becomes part of the capstone in Chapter 38.

Summary

Solid-state storage breaks the comfortable HDD assumption that deletion only removes a pointer. Underneath the familiar logical-block interface, an SSD is a small computer running a Flash Translation Layer that maps logical addresses to physical NAND pages, because flash can only be written a page at a time and erased a whole block at a time and never rewritten in place. To make that work, the controller constantly relocates data (wear leveling) and reclaims stale pages (garbage collection) — and garbage collection runs autonomously whenever the drive is powered, with or without the host. TRIM is the command by which a modern OS tells the controller which logical blocks the file system has freed; on the Read-Zero-After-TRIM drives that dominate today, a trimmed range reads as zeros the instant the mapping is dropped, and the underlying NAND is erased on the GC schedule. When TRIM has run, the data is genuinely, permanently gone — no software, and effectively no chip-off, brings it back.

Recovery remains realistic only when TRIM did not reach the data: in the seconds before the OS trims, when TRIM is disabled, behind USB bridges and old RAID controllers that do not pass it, under legacy operating systems, and — most reliably — on the SD cards and camera media that issue no TRIM at all. There, image fast (the powered clock is ticking), then recover logically and by carving exactly as on a hard drive. When the controller is dead, controller-level firmware repair is the first resort; chip-off — desoldering the NAND, reading it raw, and reversing ECC, scrambling, XOR, interleaving, and the translator — is the expensive, expert, last resort, defeated by encryption and by TRIM-plus-GC and never guaranteed even on healthy silicon. Monolithic flash (USB sticks, SD cards) and on-board eMMC/UFS require reading through the package or via JTAG/ISP, and increasingly hit the same encryption wall. And uniquely for forensics, the SSD's autonomous self-modification undermines full-image hash stability, so you minimize powered time, write-block anyway, hash file-resident evidence separately, and document the medium's non-determinism before a cross-examiner can weaponize it. Above all, this is the chapter that teaches when to stop: on flash, "the data cannot be recovered" and "the evidence is insufficient" are not failures but the honest findings that protect clients and courts alike.

You can now: - Explain why SSD recovery differs from HDD recovery — the FTL, page-program/block-erase asymmetry, wear leveling, and garbage collection — and reason about recoverability from the controller's behavior, not just the file system. - Determine whether TRIM was in play (drive determinism flags, fsutil/hdparm/lsblk/nvme diagnostics) and decide, before quoting or promising, whether deleted data is plausibly recoverable. - Identify the non-TRIM scenarios — pre-TRIM window, disabled TRIM, USB bridges, RAID members, legacy OSes, SD/camera cards — where flash recovery succeeds, and execute an image-fast, then-recover workflow. - Describe controller-repair, chip-off, and monolith/eMMC reconstruction at the level of ECC, de-scrambling, de-interleaving, and translator rebuild — and recognize when encryption or TRIM makes them futile. - Handle SSD evidence forensically: minimize powered time, document non-determinism, hash file-resident data separately, and explain a benign full-image hash mismatch to a court. - State an honest "unrecoverable" or "insufficient" finding when the physics demands it, and know that doing so is professional, not a failure.

What's next. Chapter 10 — RAID Recovery — leaves the single device behind for the array: how data is striped, mirrored, and parity-protected across multiple disks, how to determine an unknown RAID's parameters (level, stripe size, disk order, rotation) from the data itself, and how to virtually reconstruct an array — including the recurring twist that TRIM behavior you just learned changes how an SSD-backed array fails and recovers.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.