TRIM, DZAT, and the SSD Recovery Window

TRIM-deleted SSD data can be recovered, but only within a narrow window before garbage collection physically erases the NAND cells. Once the SSD controller completes GC on TRIMmed blocks, no recovery method exists. If the drive lost power or suffered a firmware failure before GC ran, the data may still be physically present on the NAND.

TRIM is an ATA command (DATA SET MANAGEMENT for SATA, DEALLOCATE for NVMe) that the operating system sends to the SSD controller when files are deleted. It identifies which logical block addresses no longer contain valid data so the controller can erase the underlying NAND cells during idle time.

TRIM (ATA Data Set Management)

The SATA protocol command that tells the SSD controller which LBAs are no longer in use. Supported on all modern SATA SSDs and enabled by default in Windows 7+, macOS 10.10.4+, and Linux kernel 2.6.33+.

UNMAP (SCSI/NVMe Deallocate)

The equivalent command for NVMe and SCSI-attached SSDs. Functionally identical to TRIM: it notifies the controller that specific blocks can be erased. NVMe Deallocate is part of the Dataset Management command set.

Garbage Collection (GC)

The controller's internal background process that physically erases NAND blocks marked as invalid by TRIM. GC consolidates valid pages into clean blocks and erases the stale ones. This is the step that actually destroys data; TRIM only marks it for destruction.

DisableDeleteNotify

The Windows registry flag that controls whether the OS sends TRIM commands to the drive. Setting DisableDeleteNotify = 1 via fsutil prevents the OS from issuing TRIM, preserving deleted data on the NAND until the blocks are overwritten by new writes.

SSDs need TRIM because of how NAND flash works. Unlike magnetic hard drives, an SSD cannot overwrite a cell in place. It must erase an entire block (typically 256KB to 4MB) before writing new data to any page within that block. Without TRIM, the controller does not know which pages contain deleted data, so it must read-modify-write entire blocks when new data arrives. TRIM lets the controller pre-erase blocks during idle time, which maintains write performance over the life of the drive. The cost of that performance optimization is the recovery window: every TRIM-and-GC cycle that completes before the drive arrives at our lab is a window that SSD data recovery cannot reopen.

TRIM-deleted SSD data is still recoverable when anything interrupts the gap between the TRIM command and garbage collection. TRIM marks blocks as invalid; GC physically erases them. If the drive lost power or suffered a firmware failure before GC ran, the original charge states survive on the NAND and can be read through PC-3000 SSD diagnostic mode.

1. 01

   Power loss before garbage collection

   If the SSD loses power after TRIM was issued but before GC erased the blocks, the data is physically intact. The controller marked the blocks as stale in its FTL, but the NAND cells still hold the original charge states. PC-3000 can read raw NAND pages and recover data from blocks that the controller considers invalid.

2. 02

   Firmware failure freezing the controller

   When SSD firmware corrupts, the controller stops processing commands, including garbage collection. A drive stuck in firmware safe mode (SATAFIRM S11, BSY state, or 0 bytes capacity) has not run GC since the failure. TRIMmed blocks that the OS deleted before the firmware crashed may still contain data.

3. 03

   USB enclosures blocking TRIM passthrough

   Many older USB-to-SATA bridge chips (such as the JMicron JMS539 or early ASMedia ASM1051) do not pass TRIM commands through to the drive. If the SSD was used in an external enclosure that blocks TRIM, deleted files remain on the NAND indefinitely. The controller never received the invalidation command, and standard recovery tools may work in this scenario.

4. 04

   TRIM disabled in the operating system

   If DisableDeleteNotify was set to 1 on Windows, or the discard mount option was not enabled on Linux, TRIM was never sent. Deleted data persists on the NAND until the controller overwrites those blocks with new data during normal write operations.

Disabling TRIM prevents the OS from telling the SSD to erase deleted blocks. This preserves deleted data on the NAND until the controller reuses those blocks for new writes. Disable TRIM before deleting files if you anticipate needing recovery later.

1. Open an elevated Command Prompt or Terminal (right-click Start, select "Terminal (Admin)").
2. Check current TRIM status: fsutil behavior query DisableDeleteNotify
3. If DisableDeleteNotify = 0, TRIM is enabled. Disable it: fsutil behavior set DisableDeleteNotify 1
4. On Windows 8+ and Server 2016+, the NTFS and ReFS modifiers target the file system stack, not the transport, so a single command covers both SATA and NVMe drives carrying that file system. If you use ReFS volumes, also run: fsutil behavior set DisableDeleteNotify ReFS 1
5. Verify: fsutil behavior query DisableDeleteNotify should now show 1.

On macOS, TRIM is enabled by default for Apple-branded SSDs and can be enabled for third-party drives via trimforce enable. There is no supported method to disable TRIM on macOS without disabling SIP. On Linux, TRIM runs only if the file system is mounted with the discard option or if fstrim is scheduled via cron/systemd timer.

The SSD controller doesn't erase NAND cells the instant it receives a TRIM command. TRIM updates the FTL mapping table & adds affected blocks to a garbage collection queue.

The controller's firmware scheduler decides when to physically erase those blocks based on idle time, free block availability, & SLC cache pressure.

1. OS sends ATA DATA SET MANAGEMENT (opcode 06h) or NVMe Dataset Management Deallocate (opcode 09h) with the affected LBA ranges.
2. Controller updates the Flash Translation Layer: affected LBAs are removed from the logical-to-physical map & the corresponding NAND pages are flagged invalid in the block validity bitmap. DZAT enforcement begins immediately; host reads to those LBAs return zeros.
3. Affected physical blocks enter the garbage collection queue inside the controller's firmware scheduler. The NAND cells still hold the original charge states at this point.
4. Firmware scheduler selects a trigger: idle time (background GC), free block count below threshold (foreground GC), or pSLC cache exhaustion. Trigger timing ranges from seconds (Samsung Elpis, Pascal, Phoenix) to hours (Silicon Motion SM2258XT on a lightly used drive).
5. Controller copies any remaining valid pages from the stale block to a clean free block, updates the FTL to point those LBAs at the new location, then applies the erase pulse (+15V to +20V Fowler-Nordheim tunneling on planar NAND). Every cell in the block resets to 0xFF. The recovery window closes.

Background GC vs. Foreground GC

Background garbage collection runs during idle periods when the host isn't sending I/O commands. The controller picks stale blocks, moves valid pages to clean blocks, & erases the originals. This is the normal mode: quiet, deferred, & often delayed by seconds to hours depending on workload.

Foreground GC is different. It triggers when the controller's free block pool drops below a firmware-defined threshold. The controller must reclaim blocks immediately to satisfy incoming writes, and it does so on the critical I/O path. This is the performance cliff users notice when an SSD slows down during large file copies. For recovery, foreground GC is worse: it erases TRIMmed blocks immediately because the controller needs that NAND space right now. SATA SSD firmware recovery runs $600–$900.

SLC Cache Exhaustion & Forced Migration

Most consumer SSDs use pseudo-SLC (pSLC) caching: the controller writes incoming data to TLC or QLC cells in SLC mode (1 bit per cell) for speed, then migrates that data to full TLC/QLC density during idle time. A 1TB QLC SSD might have 12-48GB of pSLC cache. When sustained writes fill that cache, the controller must flush pSLC pages to their native TLC/QLC format.

This flush operation triggers aggressive garbage collection. The controller needs free TLC/QLC blocks to receive the migrated data, so it erases every stale block it can find, including TRIMmed blocks that might still contain recoverable data. A nearly full SSD under heavy writes can erase TRIMmed blocks within seconds of the pSLC cache filling. A half-empty SSD with a Phison PS5012-E12 controller and plenty of free blocks might defer that erasure for hours.

Over-Provisioning & Free Block Reserves

Over-provisioning (OP) is the portion of physical NAND reserved for controller operations beyond the user-addressable namespace. Consumer SSDs typically ship with roughly 7% factory OP (for example, 512 GiB of raw NAND exposed as a 500 GB / ~465 GiB namespace). Enterprise drives ship with 28% or more. The base-10 vs base-2 capacity difference (1 TB marketed = ~931 GiB reported by Windows) is a unit conversion artifact, not OP. More OP means a larger free block pool, which means the controller has less urgency to run GC on TRIMmed blocks.

Drive fill level matters too. A nearly full consumer SSD leaves the controller with a small free-block pool, so it runs GC aggressively to maintain write performance. The same drive at half capacity has a much larger pool of available blocks. GC pressure is low, TRIMmed blocks sit in the queue longer, & the recovery window extends from minutes to hours.

Background GC

Runs during idle time. Erases stale blocks at the controller's leisure. Deferred by seconds (Samsung) to hours (Silicon Motion on lightly used drives). The recovery window depends on how quickly the SSD reaches idle after TRIM.

Foreground GC

Triggers when free blocks drop below firmware threshold. Runs on the I/O critical path. Erases TRIMmed blocks immediately. The performance cliff (write speeds dropping from 500MB/s to 50MB/s on SATA) is the observable symptom.

pSLC Cache Flush

When the pseudo-SLC write cache fills (typically 12-48GB on a 1TB QLC SSD), the controller migrates cached pages to TLC/QLC blocks. This migration triggers block erasure to free space, which can include TRIMmed blocks that still held recoverable data.

NVMe APST & Garbage Collection Scheduling

NVMe drives support Autonomous Power State Transition (APST), which lets the host OS dictate how quickly the drive enters low-power states during idle. NVMe drives define multiple power states: PS0 (active, ~8W) down to PS3 or PS4 (deep sleep, ~0.009W). When the drive enters a non-operational power state, the NVMe specification allows it to temporarily exceed that state's power limit for background processing, including garbage collection.

NOPPME (Non-Operational Power State Permissive Mode Enable) controls this behavior. If NOPPME is disabled, the drive must respect the strict power limit of the current sleep state & defer GC until the host wakes it back to an operational state. On a laptop that pushes the NVMe drive into PS4 deep sleep within 100ms of idle, the drive can't run GC because the power budget is too low. This inadvertently extends the recovery window: the drive goes to sleep before the controller has time to erase TRIMmed blocks.

Enterprise & data center NVMe SSDs disable APST (0ms transition latency). The drive stays in PS0 at full power, ready for the next I/O command with zero latency. That means the controller runs GC without any power-state constraints, erasing TRIMmed blocks as soon as idle time appears. Consumer NVMe drives with aggressive host-configured APST profiles can preserve TRIMmed data longer if the system transitions the drive into non-operational states before GC completes. NVMe SSD firmware recovery runs $900–$1,200.

APST (Autonomous Power State Transition)

NVMe power management feature that transitions the drive between power states based on idle time. Each state has defined entry/exit latencies & power limits. PS0 is full active; PS3/PS4 are deep sleep. The host OS configures APST thresholds via the NVMe Set Features command.

NOPPME (Non-Operational Power State Permissive Mode Enable)

NVMe controller feature bit. When enabled, the controller can temporarily exceed a non-operational power state's power limit for background maintenance (GC, wear leveling). When disabled, GC is blocked until the host transitions the drive back to an operational power state.

DZAT (Deterministic Read Zero After TRIM) is a SATA specification behavior defined in IDENTIFY DEVICE Word 69, Bit 5. The controller intercepts all host reads to TRIMmed LBAs and returns absolute zeros, even before garbage collection physically erases the NAND. Recovery software sees only zeros. PC-3000 SSD bypasses this by reading raw NAND pages in diagnostic mode.

DZAT (Deterministic Zeroes After TRIM) on SATA

SATA specification behavior defined in IDENTIFY DEVICE Word 69, Bit 5. The controller returns absolute zeros for any TRIMmed LBA. Required for enterprise RAID arrays where parity calculations depend on consistent zero-fill across degraded members. Software tools see only zeros; the physical NAND charge state is unchanged until garbage collection erases the block.

DLFEAT 001b (NVMe Equivalent of DZAT)

NVMe Identify Namespace byte 33, bits 2:0. When set to 001b, the drive guarantees all reads to deallocated (TRIMmed) LBAs return all 00h bytes. This is the NVMe Dataset Management Deallocate (opcode 09h) equivalent of SATA DZAT. Modern NVMe SSDs manufactured after 2019 report DLFEAT 001b to maintain RAID parity consistency. DLFEAT 010b returns all FFh bytes; 000b means behavior is not reported.

ATA DSM-TRIM (SATA, opcode 06h) vs. NVMe Deallocate (opcode 09h)

SATA TRIM travels as the DATA SET MANAGEMENT command (opcode 06h) with the TRIM attribute bit set. NVMe uses opcode 09h, Dataset Management, with the Attribute-Deallocate (AD) bit set in Command Dword 11. Both commands queue a deallocation hint in the controller's FTL mapping structures; neither physically erases NAND. Physical erasure happens only during the subsequent garbage collection cycle when the controller applies the erase pulse.

DRAT (Deterministic Read After TRIM) on SATA

SATA specification behavior defined in IDENTIFY DEVICE Word 69, Bit 14. The controller returns a single consistent value for all reads to TRIMmed LBAs, though not necessarily zeros. DZAT is the stricter subset of DRAT: a DZAT drive is always DRAT, but a DRAT drive is not necessarily DZAT.

PC-3000 SSD bypasses DZAT by entering vendor-specific diagnostic mode, which reads raw NAND pages without going through the controller's host command processing layer. Recovery software like Disk Drill, R-Studio, & Recuva reads through the host interface; the controller intercepts their read commands & returns deterministic zeros. PC-3000 sends raw page read commands that skip the FTL's validity markings entirely.

Full DRAT, DZAT, and DLFEAT compliance matrix for supported controller families below

Hardware write-blockers intercept host write commands at the SATA or NVMe interface, but they cannot reach the SSD controller's internal firmware scheduler. When power is applied to a TRIMmed drive, the controller autonomously executes garbage collection on stale blocks regardless of whether the host sent a write command. The evidence is erased while the write-blocker reports zero host writes.

Write-blockers sit between the host computer and the drive's physical interface. They pass read commands through & block write commands from reaching the NAND. The SSD controller's background task scheduler lives inside the controller silicon, not on the interface bus. It wakes up the moment the drive receives power & begins reclaiming stale NAND blocks without any host instruction.

A forensic examiner who powers a TRIMmed SSD through a Tableau or WiebeTech write-blocker will see the drive enumerate normally. The write-blocker logs zero host writes. Meanwhile, inside the controller, the GC scheduler is erasing every block marked invalid by the last TRIM command. The evidence disappears silently while the interface monitor shows no activity. SATA SSD recovery starts at $200; NVMe starts at $200.

The only ways to stop this are to keep the drive completely unpowered, or to enter vendor-specific diagnostic mode before the firmware initializes its garbage collection routine. PC-3000 SSD can freeze GC by forcing supported controllers into Safe Mode or ROM Mode at power-on. In diagnostic mode the background task scheduler never starts, & raw NAND pages remain readable. Firmware recovery for SATA SSDs runs $600–$900; NVMe runs $900–$1,200.

For supported controllers, PC-3000 SSD enters diagnostic mode via vendor-specific commands that upload a microcode loader into controller RAM. This loader disables the GC scheduler & grants raw NAND page access before any background erasure can occur. The tool reads pages by Physical Block Address, bypassing the FTL's validity markings & the DZAT protocol layer that would return zeros through a normal host read. SATA firmware recovery runs $600–$900.

SATA SSD recovery: $200–$1,500. NVMe SSD recovery: $200–$2,500. The price depends on the failure type, not on whether TRIM was involved. Free evaluation, firm quote before any paid work. No data recovered means no charge.

If your SSD failed due to firmware corruption, power loss, or controller failure, the question is whether garbage collection ran before the failure stopped the controller. We determine this during the free evaluation by examining the NAND contents directly with the PC-3000. If the data survived, we image it. If GC already erased the target blocks, we report that honestly. No attempt fees.

Rush service available for an additional +$100 rush fee to move to the front of the queue. Call (512) 212-9111 for a free evaluation.

Nearly all modern SSD controller families return deterministic zeros to any host read of a TRIMmed LBA. The protocol field (SATA IDENTIFY DEVICE Word 69 bit 5 or NVMe DLFEAT) tells you what recovery software sees. The PC-3000 SSD diagnostic mode column tells you whether a lab can read past that protocol layer and reach the physical NAND before garbage collection erases it.

SATA controllers advertise DZAT through IDENTIFY DEVICE Word 69 bit 5. NVMe controllers advertise the equivalent behavior through Identify Namespace byte 33, bits 2:0 (the DLFEAT field), where 001b means deallocated reads return all 00h. The matrix below maps the controller families we see most often to their protocol encoding, ACELab PC-3000 SSD v3.8.10 support status, & the practical recovery path that remains when TRIM has already executed.

NAND flash stores data by trapping electrons in floating gate transistors. Each cell holds a charge level that encodes one or more bits (SLC = 1 bit, TLC = 3 bits, QLC = 4 bits). Erasing a cell removes the trapped electrons, resetting the cell to an empty state. This erasure is irreversible at the data level.

NAND flash has an asymmetric write/erase constraint. Writes happen at the page level (typically 4KB to 16KB). Erases happen at the block level (typically 256KB to 4MB, containing 64 to 256 pages).

You cannot erase a single page; the entire block must be erased at once. This is why garbage collection exists: the controller must consolidate all valid pages from a partially-stale block into a clean block, then erase the entire stale block.

When the OS deletes a file and sends TRIM, the controller updates its Flash Translation Layer to mark those LBAs as invalid. The physical pages still contain data at this point.

During the next garbage collection cycle, the controller reads all valid pages from blocks containing stale data, writes them to a free block, and erases the original block. After the erase completes, those NAND cells read as all-ones (0xFF). The data is gone.

Some SSD controllers implement "deterministic zeroing" per the NVMe specification: after TRIM, reads to those LBAs return all zeros even before GC runs. The actual NAND cells may still hold the original data until GC, but accessing them requires bypassing the controller with hardware tools.

ATA DSM & NVMe Deallocate Wire Protocol

SATA TRIM travels as an ATA DATA SET MANAGEMENT command (opcode 06h) with the TRIM attribute bit set in the Features register. The host transfers one or more 512-byte blocks of LBA Range Entries to the controller. Each entry is 8 bytes: a 48-bit starting LBA plus a 16-bit sector count. One 512-byte payload block holds 64 range entries; ACS-2 permits up to 8 blocks per command, capping a single DSM at 512 ranges. The drive advertises TRIM support through IDENTIFY DEVICE word 169, bit 0. DRAT and DZAT appear in IDENTIFY DEVICE word 69, bits 14 and 5 respectively.

NVMe uses opcode 09h, Dataset Management, with the Attribute-Deallocate (AD) bit set in Command Dword 11. The host transfers a Range Definition Set containing up to 256 entries. Each range descriptor is 16 bytes: a 32-bit context attribute field, a 32-bit length in logical blocks, and a 64-bit starting LBA. The controller's post-deallocate read behavior is defined by the DLFEAT field at byte offset 33 of the Identify Namespace data structure. DLFEAT bits 2:0 = 000b means not reported, 001b means deallocated reads return all 00h bytes (the NVMe equivalent of SATA DZAT), and 010b means deallocated reads return all FFh bytes.

The wire-level command does not physically erase NAND. It queues a deallocation hint in the controller's internal mapping structures. The FTL updates the logical-to-physical table so the affected LBAs no longer point at the original pages; those pages are marked invalid in the block's page validity bitmap. The NAND cells still hold their charge states until the controller selects that block for erase during the next garbage collection pass.

Recovery software reads sectors through the OS storage driver. After TRIM, the controller returns zeros for those sectors, even if the physical NAND has not been erased yet. Software cannot distinguish between a TRIMmed block and a block that was never written to. Both read as zeros.

Tools like Disk Drill, R-Studio, Recoverit, TestDisk, EaseUS Data Recovery Wizard, and Recuva all operate above the SSD controller. They send standard read commands through the SATA or NVMe interface. The controller intercepts these reads and, for TRIMmed LBAs, returns zeros before the software ever touches the NAND. The data may physically exist on the flash, but the controller refuses to expose it through normal host commands.

The PC-3000 bypasses the controller's host interface. It communicates with the controller using vendor-specific diagnostic commands that access raw NAND pages, ignoring the FTL's validity markings. If the physical cells have not been erased by GC, PC-3000 can read the original page data regardless of the controller's TRIM status table.

Match the symptom you observe to the branch below. The leaf tells you which recovery path is technically viable & which is closed. Logical software tools do not appear as leaves here because DZAT & DLFEAT 001b defeat them before they read a single byte.

Branch 1. Was a deletion, format, or TRIM command executed on a working drive?

Drive left powered on after deletion: Likely physically destroyed. Background garbage collection has applied the +15V to +20V Fowler-Nordheim erase pulse to the affected NAND blocks. No lab tool reverses a hardware erase.

Drive powered off within seconds: Recoverable through PC-3000 SSD diagnostic mode if the controller family is supported (Phison PS5012-E12, Silicon Motion SM2262EN / SM2263XT, Marvell 88SS1093, older Samsung S3C29 / S4LJ / S4LN families including MEX / S4LN045X01 via Terminal connection, Maxio MAS0902, Maxio MAS1102 at 240 GB). Modern Samsung in-house controllers (Elpis, Pascal, Phoenix, MGX) & Maxio MAP1602 require board repair only. SATA SSD recovery starts at $200; NVMe starts at $200. See firmware recovery.

Branch 2. Does the drive enumerate in BIOS or appear in Disk Management?

Enumerates but reports 0 bytes, the wrong capacity, or SATAFIRM S11: Firmware panic. The FTL has gone inconsistent mid-flush. PC-3000 SSD diagnostic ROM-mode entry & SRAM microcode loader on supported controllers; SATA firmware recovery runs $600–$900, NVMe runs $900–$1,200.

Hangs the host (BSY state, system freezes during POST): Controller bootloop. PC-3000 SSD sends vendor-specific commands to halt boot before the FTL initializes, then reads raw NAND pages. Same pricing tier as the firmware panic leaf above.

Not detected at all: Proceed to Branch 3.

Branch 3. Is the PCB electrically functional?

Short detected on a power rail: PMIC thermal latchup, dead voltage regulator, or a blown MLCC across the 3.3V, 1.8V, or 1.2V rail. Locate the failed component with a FLIR thermal camera, replace with a Hakko FM-2032 on the FM-203 base station, & revive the original controller. This step is mandatory for any AES-256 self-encrypting drive: the encryption key is fused to the silicon & chip-off produces ciphertext. Board repair runs $450–$600 for SATA & $600–$900 for NVMe. See hardware encryption barrier.

Branch 4. Is the controller silicon cracked or irreversibly dead?

Modern drive (NVMe or post-2015 SATA with AES-256 self-encryption): Unrecoverable. The Media Encryption Key is fused to the dead controller. Chip-off yields ciphertext under a key that no longer exists outside the silicon. This is the structural endpoint for modern SSD recovery.

Legacy drive (pre-2015 SATA without hardware encryption, raw USB thumb drives): Chip-off the NAND on a programmer, then manually reverse the controller's XOR scramble & ECC. See chip-off NAND recovery.

Whichever branch you land on, ship the drive powered off. Do not reconnect it to a host that might idle long enough for one more garbage-collection cycle. Our lab is at 2410 San Antonio Street, Austin, TX 78705; all SSD work is performed in-house. Evaluation is free & carries no diagnostic fee.

The over-provisioned (OP) area holds physical NAND blocks that the controller keeps outside the user-addressable LBA range. After a TRIM command, stale copies of deleted pages can end up inside the OP pool if the wear-leveling routine migrated them before erase. The pages remain readable through direct NAND access until the controller selects those OP blocks for its next erase cycle.

Factory OP, Dynamic OP, & User OP

Consumer SATA and NVMe SSDs typically ship with roughly 7% factory OP, often derived from the binary-to-decimal capacity difference (for example, 512 GiB of raw NAND exposed as a 500 GB / ~465 GiB LBA namespace). Enterprise drives ship with 28% or more, reserved to sustain steady-state random write performance under constant garbage collection pressure. Dynamic OP expands the pool whenever free-block counts fall below the controller threshold, temporarily borrowing user-addressable blocks. User OP is the portion the administrator leaves unpartitioned; the controller treats unmapped LBAs as extra free blocks.

Wear-Leveling Migration of Stale Pages

Before a block is erased, the controller copies its valid pages to a new free block so the original can be released. Static wear leveling extends this behavior to rarely-updated data: the controller periodically moves cold pages into blocks with higher erase counts to equalize wear.

When TRIM marks pages invalid shortly after a wear-leveling migration, the original source block may sit in the OP pool with its contents intact until the block allocator reaches it. A page that was logically deleted from the user LBA space can therefore persist physically inside the OP area for minutes to hours, depending on write pressure and block allocation order.

Chip-Off NAND Reachability of OP Blocks

The OP area is a controller-firmware abstraction. At the NAND die level, every block carries the same physical address regardless of whether the FTL maps it into user LBA space or reserves it for OP. Powering a NAND die on an external programmer after chip-off extraction exposes every physical page, including pages the controller considered OP reserve. The FTL metadata is needed to reassemble logical files, and on self-encrypting drives the raw pages are AES-256 ciphertext that cannot be decrypted without the controller's key material.

Conditions Under Which OP Survivability Matters

OP-area survivability is load-bearing only when the drive is isolated from power before the controller completes its queued erases. Immediate power disconnection after deletion halts GC mid-sequence and freezes the OP pool in whatever state the controller left it. Firmware failure that hangs the GC scheduler produces the same freeze. Queued TRIM commands that the host sent but the controller never acknowledged (for example, pending DSM operations in the SATA NCQ queue at the moment of a hard power cut on a consumer SSD without PLP) leave the FTL in an intermediate state where the affected ranges have not yet been flagged invalid. Enterprise drives with Power Loss Protection capacitors flush pending TRIMs during an outage, which is good for data integrity and bad for recovery. Any recovery path that depends on OP survival requires the drive to arrive at the lab without a second power-on.

A TRIM command does not erase NAND. It updates the Flash Translation Layer so the controller no longer maps those LBAs to user space, then enforces Deterministic Zeroes After TRIM (DZAT) so every host read of those addresses returns zeros. Until garbage collection physically erases the block, the original charge states are still sitting in the floating gates and can be read directly off the NAND with vendor-specific diagnostic access. Once the controller issues the erase pulse, the data is gone.

The Four Physical States After TRIM

1. 01

   LBA deallocation: FTL marks pages invalid

   The OS issues an ATA DSM-TRIM (opcode 06h) or NVMe Dataset Management Deallocate (opcode 09h). The controller removes the affected LBA entries from the logical-to-physical map and flags the corresponding NAND pages as stale in the block validity bitmap. The cells themselves still hold the same charge they held before the command arrived. Recoverable through raw NAND access; not recoverable through any host-interface read.

2. 02

   DZAT masking: host reads return synthetic zeros

   On any drive that advertises DZAT (SATA IDENTIFY word 69 bit 5) or NVMe DLFEAT 001b, every host read to a TRIMmed LBA is intercepted by the controller protocol layer and answered with all-zero data, regardless of what is on the NAND. Disk Drill, R-Studio, PhotoRec, Recuva, and every other tool that reads through the host interface sees zeros at this stage. The cells are still intact at the silicon level, but the controller refuses to expose them.

3. 03

   Garbage collection pending: the recovery window

   Stale blocks sit in the controller's GC queue waiting for an idle window, a free-block threshold trip, or a low-power state. Window length is firmware dependent: Samsung Elpis, Phoenix, and Pascal controllers fire GC within seconds of idle; Phison E12 and E18 batch GC against LPM transitions, giving minutes; Silicon Motion SM2258 and SM2259 defer until free-block pressure rises, sometimes leaving stale blocks intact for hours on lightly-used drives. Anything that interrupts this stage, a power cut, a firmware panic, a controller short, freezes the NAND in a recoverable state.

4. 04

   Physical erase: cells reset to 0xFF

   The controller selects the block, copies any remaining valid pages to a fresh free block, then applies the NAND erase pulse to the original. Every cell in the block returns to the unprogrammed state and reads as 0xFF. The data is destroyed at the charge level. No lab tool, no firmware exploit, no forensic technique recovers data from a block that has been physically erased. After this step the recovery window is closed.

The Lab Path While the Window Is Open

At the Austin lab the first decision after intake is whether the drive is still powered-on stable. If it is, we keep it off and image with PC-3000 SSD in technological mode. Vendor-specific commands boot the controller from its internal Mask ROM rather than the production firmware, an SRAM loader is injected that disables background processes (GC, wear leveling, TRIM execution) and strips the DZAT protocol layer.

The tool reads pages by Physical Block Address rather than LBA. The Out-of-Band metadata that the controller wrote alongside each page (block sequence numbers, LBA tags, journal fragments) is parsed to reconstruct a virtual FTL in workstation RAM, and the user data is imaged through that virtual map without touching the native firmware.

If the drive is electrically dead, controller revival has to happen first. Modern SSDs cryptographically bind the AES-256 media encryption key to the controller silicon through fused hardware key material, so removing the NAND for an external chip-off read yields ciphertext with no decryption path. The native controller is the only AES engine that can unwrap and apply that key to its own NAND.

We inspect the PCB under restricted current with a FLIR thermal camera to locate shorted PMICs, buck converters, LDOs, or MLCCs on the 3.3V, 1.8V, and 1.2V rails, then desolder and replace the failed components with Hakko FM-2032 microsoldering irons and Atten 862 hot air, sourcing replacements from an identical donor PCB. Once the rails come back up and the controller boots, PC-3000 SSD takes over before the unstable silicon has time to fail again.

For the underlying protocol mechanics see the TRIM and DZAT physics page. For controller-by-controller garbage collection timing and the precise events that trigger physical erase, see the garbage collection data loss page.

Once garbage collection runs on a TRIMmed block, the data is gone at the electron level. The controller applies a 3.5-5 ms erase pulse that strips charge off every floating gate or charge-trap layer, leaving an erased cell physically indistinguishable from one that was never programmed. NIST SP 800-88 classifies this as Purge: sufficient against state-actor recovery.

The DZAT Contract Is a Protocol Lie Until GC Runs

DZAT (Deterministic Zeroes After TRIM) on SATA and DLFEAT 001b on NVMe are controller-level guarantees, not NAND-level facts. The instant the host issues ATA DSM-TRIM (06h) or NVMe Dataset Management Deallocate (09h), the controller drops the affected LBAs from the logical-to-physical map and starts returning all-zero data for any host read of those addresses. The charge in the NAND cells has not changed at this point. The decoupling is purely a firmware bookkeeping operation in the FTL. Software recovery tools see zeros because the controller answers their reads with zeros, not because the data is erased.

Background GC Is Where the Charge Actually Leaves

When the controller decides to reclaim a partially-invalid block, it copies the surviving valid pages into a fresh block via incremental step-pulse programming (tPROG 200-700 µs per page), updates the FTL to point the corresponding LBAs at the new physical location, then commits an erase pulse to the original block. The erase pulse is what destroys data.

On 2D planar NAND, +15V to +20V is applied to the p-well substrate while the control gate is grounded, and Fowler-Nordheim tunneling drags electrons off the floating gate through the tunnel oxide. On 3D charge-trap NAND (Samsung V-NAND, Kioxia BiCS, Micron CMOS-under-array) there is no bulk substrate to bias, so the controller uses Gate-Induced Drain Leakage to generate electron-hole pairs at the vertical channel and injects the holes into the SiN trap layer via quantum tunneling, where they recombine with the trapped electrons.

Either mechanism takes 3.5-5 ms (tBERS) on modern TLC and QLC parts and drops every cell's threshold voltage below the read reference. The block now reads 0xFF.

Chip-Off Yields 0xFF on Erased Blocks

Customers ask whether desoldering the NAND with Atten 862 hot air and reading the raw die in PC-3000 Flash recovers the data after GC. It does not, for two reasons. First, the erase pulse drains the cells; an erased cell holds no charge & emits no signal during a sense operation, so the read returns 0xFF regardless of what was there an hour earlier. Second, the OOB area on each page (LBA tag, block sequence number, journal fragment) is erased in the exact same pulse, so even pages that were copied to a new block before the erase cannot be reverse-mapped: the metadata that tied them to a logical file is gone. Wei et al. (USENIX FAST 2011, “Reliably Erasing Data from Flash-Based Solid State Drives”) measured that software overwrites leave up to 75% of data intact in over-provisioning space, but a hardware block erase destroys the data completely. That is the same physics on today's drives, scaled up to 3D stacks of 200+ layers.

Why HDD Analogies Stop Working Here

On a hard drive, an overwritten track can in theory leave residual magnetism at the track edges that magnetic force microscopy could read, which is why DoD-style multi-pass overwrites existed at all. NAND has no analog of that. Electrons are indistinguishable particles. A floating gate with zero electrons after an erase pulse is the same floating gate as one that was never programmed at the factory. There is no “edge” of the cell where prior charge persists & no “remnant” signal to demodulate. This is why NIST SP 800-88 lists a NAND block erase under Purge, the strongest sanitization tier. For controller-by-controller GC timing windows that determine how long the recovery opportunity stays open, see the TRIM and DZAT protocol depth page. For the lab workflow and pricing on drives caught before GC fires, see our SSD data recovery service.