Unlike a hard drive, an SSD has no moving parts: data lives in NAND memory chips, driven by a controller that orchestrates writes, wear and error correction. This architecture makes it faster and more shock-resistant — but paradoxically more dangerous to recover, because the SSD manages its own memory and can erase data with no human action.
This chapter is for anyone who wants to understand the logic of a flash recovery before deciding. For the physics of NAND, see the matching Manual chapter; to send a device in, the SSD service.
1 · The TRIM trap — why time matters
This is the major difference from a hard drive. On an HDD, a deleted file stays physically present until it's overwritten. On an SSD, the operating system sends a TRIM command telling the controller which blocks are free; the SSD then physically erases them in the background to prepare future writes. The result: deleted data can become unrecoverable within minutes, even with no user action.
2 · Recognize the type of failure
Logical failure
Healthy, detected SSD, but deleted files, formatted partition, RAW system. Recoverable at ~90% — provided TRIM hasn't already done its work, hence the urgency.
Firmware / controller failure
SSD shown as SATAFIRM S11, 0 capacity, Busy mode, or gone after an update: the translation table (FTL) linking logical addresses to NAND pages is corrupt. The data is intact but unaddressable. ~82% success.
NAND degradation (Bit Rot)
Massive read errors, slowdowns: cells wear out electrically and ECC no longer suffices. We then read the chips by shifting the voltage thresholds. Variable prognosis.
Dead controller / dead SSD
No response, after a drop or a surge. Only chip-off (desoldering the NAND chips) can attempt a read. 50 to 70% depending on the encryption built into the controller.
3 · The laboratory process
Step 1 — Shutdown & diagnosis
Immediate cut of all writes, electronic diagnosis, identification of the controller and NAND type. We determine whether the controller is addressable or whether we'll go through the chips.
Step 2 — Controller route (Safe Mode & reverse FTL)
If the controller responds, we force it into Safe Mode via a loader in RAM, then rebuild the translation table (reverse FTL) from residual metadata — without the original firmware. This is the most reliable route when available.
Step 3 — NAND route (chip-off & reconstruction)
If the controller is dead, we desolder the chips in a BGA station, read their raw content, then reconstruct in software the interleaving, the scrambling (XOR) and the ECC specific to the controller. When cells are tired, Read Retry adjusts the voltage thresholds and soft LDPC decoding fixes the bit errors.
Step 4 — Apple case (board-level & decryption)
On MacBooks with a soldered SSD (T2, M1–M4), we first repair the power rails at component level, then read the SSD through a hardware DFU interface. Decryption is only possible if the Secure Enclave is working and the FileVault key or password is known.
Step 5 — Extraction & VeriFiles
File-system reconstruction, verification, then the VeriFiles list approved before payment. Return on a new encrypted device.
4 · Success rates by scenario
- Logical failure (TRIM not fired) — 90%
- Firmware / repairable controller — 82%
- MacBook board-level (T2 / M-series) — 80%
- NAND chip-off + reconstruction — 50 to 70%
- SSD after secure erase — around 15%
5 · The mistakes that destroy data
What you must never do to a failing SSD
- Leave the SSD powered — TRIM erases in the background.
- Secure erase or low-level format — irreversible destruction of the cells.
- The freezer — a myth: condensation short-circuits the electronics.
- Mount read-write to "save what's left" — every write overwrites still-intact pages.
- Retry a failed firmware update — risk of permanently freezing the controller.
Logical case only. If the SSD is healthy and it's a simple recent deletion, an experienced user can attempt an immediate recovery, on a cloned image — but TRIM makes this scenario far riskier than on a hard drive.