SSD Data Recovery - NVMe, M.2, and SATA Drive Recovery

Rossmann publishes 5 SSD recovery pricing tiers from $200–$1,500 because the cost of a firmware rebuild doesn't change based on who is asking. Every recovery is performed in-house at our Austin lab by the same technicians who diagnose the drive, with flat-rate pricing based on the required repair rather than perceived urgency.

Most data recovery labs hide their pricing behind a phone call because their business model depends on quoting based on how desperate you sound. We publish ours because we are confident in what we charge. A firmware rebuild is a firmware rebuild whether you found us through Google or through a referral. The price does not change based on who is asking.

Every recovery listed on this page is performed in-house at our Austin lab. We do not outsource to a third-party lab. We do not broker your drive to another company. The same technicians who diagnose your SSD are the ones who repair it, image it, and verify the files. You can watch the actual work on Louis's YouTube channel, where we record live recoveries, including the failures. That level of visibility is the opposite of what large labs offer.

Rossmann Repair Group is also one of the most visible advocates for the Right to Repair movement. Louis has testified before the FTC and state legislatures to fight manufacturer restrictions that block independent repair shops from accessing the parts, tools, and documentation needed to fix your devices. That fight is not separate from what we do here. When a manufacturer designs an SSD so that only their authorized service center can access the encryption keys, that is a repair restriction. We work around it with engineering, not permission.

When you delete a file on an SSD, the operating system sends a TRIM command that marks those blocks as invalid. The controller returns zeroes to any read request for those addresses, making deleted data inaccessible through software within seconds. Physical NAND erasure follows later during garbage collection, but the controller blocks access the moment TRIM completes.

SSD recovery feasibility by failure scenario below

When you delete a file on an SSD, the operating system sends a TRIM command telling the controller which LBAs (logical block addresses) are no longer needed. The controller marks those pages as invalid in its flash translation layer (FTL). The physical NAND cells are not erased at this point.

Most modern SSDs implement DRAT or DZAT (Deterministic Read After TRIM / Deterministic Zeroes After TRIM), which means the controller immediately returns zeroes when those addresses are read through the normal interface, even though the underlying NAND cells still hold their original charge. The actual physical erasure happens later during garbage collection, asynchronously.

Once a TRIM command is fully processed, the controller intentionally blocks access to the deleted files through standard interfaces. Unless the drive suffered an immediate hardware failure before TRIM executed, the data is permanently unrecoverable through conventional software.

This is the opposite of how hard drives work. On a spinning disk, deleted files sit untouched until new data overwrites them. On a TRIMmed SSD, the data becomes inaccessible through the controller within seconds of deletion. Physical NAND erasure follows during garbage collection, but the controller will not serve the data from the moment TRIM completes.

DZAT and DLFEAT: How Controllers Block Access to TRIMmed Data

SATA SSDs that support DZAT (Deterministic read ZEROs After TRIM) immediately return zeroes to any read request targeting TRIMmed logical block addresses. NVMe SSDs use a separate mechanism: the Deallocate command paired with the DLFEAT (Deallocate Logical Block Features) field in the drive's namespace metadata. When DLFEAT reports 001b, the controller returns all zeroes for deallocated blocks.

This zeroing happens at the controller's protocol layer before garbage collection physically erases the underlying NAND cells. Even if the original voltage charges remain on the floating gates for minutes or hours after deletion, the controller refuses to serve that data through any standard interface. Software tools see only zeroes.

Drives that support deterministic zeroing (such as the Samsung 860/870 SATA families and the 980 NVMe series) make software-based undelete after TRIM or Deallocate impossible; the controller enforces the deletion at the protocol level, independent of the physical state of the NAND cells.

Not all SATA SSDs support DZAT. Older drives with DRAT (Deterministic Read After TRIM) return a fixed, consistent payload for TRIMmed addresses, which may or may not be zeroes. Budget controllers with non-deterministic TRIM may return unpredictable data patterns. DZAT is required on enterprise and NAS-optimized SATA SSDs for RAID parity consistency.

On the NVMe side, the vast majority of modern NVMe SSDs enforce deterministic zeroes (DLFEAT=001b) upon deallocation. In all deterministic cases, once TRIM or Deallocate executes, the data is inaccessible from any software perspective. The only scenario where TRIMmed data might be recoverable is when the controller died before completing the TRIM operation, leaving the NAND pages intact in their pre-TRIM state.

TRIM on Windows

Windows enables TRIM automatically on any SATA or NVMe SSD using native Microsoft drivers. The Storage Optimizer (formerly Disk Defragmenter) schedules a weekly "Retrim" pass that re-issues TRIM commands for all previously deleted blocks, ensuring the controller stays current even if the initial TRIM was missed. On a healthy Windows system, deleted data is typically logically unmapped and rendered inaccessible within seconds of deletion during normal use, and any stragglers are caught by the next weekly Retrim cycle.

TRIM on macOS

On Macs with a T2 chip (late 2017 through 2020, starting with the iMac Pro) or Apple Silicon (M1/M2/M3/M4), every byte written to the internal SSD is encrypted by default using AES-256 in XTS mode, with keys managed by the Secure Enclave inside the SoC. This encryption is always-on and transparent; you do not need to enable FileVault for it to be active. When files are deleted, macOS sends a standard TRIM command, and the controller handles it like any other SSD: the LBAs are marked invalid in the FTL and reads return zeroes. The Secure Enclave does not destroy any keys in response to individual file deletions.

What makes T2/M-series recovery different is not TRIM behavior; it is the always-on hardware encryption tied to the specific SoC. Because every block on the NAND is AES-256 encrypted with keys that exist only inside the Secure Enclave on that specific chip, desoldering the NAND yields only ciphertext regardless of whether TRIM has run. Chip-off is useless on these machines. The only recovery path when the logic board is dead is board-level microsoldering to get the Secure Enclave operational again so it can decrypt in place. We will not accept payment for a case we know cannot succeed.

Crypto-shredding, where the Secure Enclave destroys the volume encryption key and makes all data on the drive permanently irrecoverable, happens only during a full disk erase (Erase All Content and Settings, or a DFU restore). That operation is instant and absolute. It is distinct from per-file TRIM, which leaves the encryption keys intact.

On older Macs without a T2 chip using third-party SSDs, TRIM is not enabled by default. Users must run sudo trimforce enable to activate it. Until that command is run, deleted files persist on the NAND and standard recovery applies.

TRIM on Linux

Linux TRIM behavior depends entirely on the distribution and file system. Many distros batch TRIM commands via a weekly fstrim.timer service, creating a window where deleted data remains on the NAND before the timer executes. However, modern setups (such as Btrfs) increasingly default to asynchronous real-time discard, which unmaps blocks in the background continuously. If real-time discard is active, the data is unmapped immediately and is unrecoverable through the controller.

Write Amplification and Garbage Collection

TRIM tells the controller which blocks are free. Garbage collection is what the controller does with that information: it consolidates valid pages from partially-empty blocks into new blocks, then erases the old ones to create clean write targets. This runs continuously in the background whenever the drive is powered on and idle. Every consolidation cycle means extra writes to the NAND that the host never requested. That ratio of actual NAND writes to host writes is called write amplification. A drive with a write amplification factor of 3x wears its cells three times faster than the host workload alone would suggest. Heavy random writes, a nearly full drive, and aggressive garbage collection all push the factor higher, accelerating the path toward ECC failure and controller lockup.

The practical takeaway: if your SSD died from a hardware failure and never had the chance to run garbage collection after the crash, the metadata in the service area is likely intact, giving us a strong chance to reconstruct the FTL. If the drive was running for days in a degraded state, grinding through garbage collection cycles before it finally locked up, the controller may have already damaged the service area beyond repair. The sooner a failing drive is powered off and sent to a lab, the better.

SSD Recovery Feasibility by Failure Scenario

TRIM cannot execute on a physically dead controller. If the drive died from a hardware failure before the OS sent TRIM commands, deleted data is still on the NAND.

Hardware encryption ties the decryption key to the controller silicon. When the controller fails, desoldering the NAND yields only AES-256 ciphertext. Recovery requires board-level repair of the original controller so it can decrypt in place; chip-off extraction is not viable on encrypted drives.

The controller generates the key on first use, stores it internally, and encrypts every write transparently. When the drive functions normally, you never notice. When the drive fails, encryption determines whether chip-off recovery is even possible.

Self-Encrypting Drives and TCG Opal

Drives that comply with the TCG Opal specification store the media encryption key (MEK) internally, typically wrapped by a Key Encryption Key (KEK). On modern NVMe controllers, this KEK is cryptographically bound to unique, irreversible hardware fuses or a Physically Unclonable Function (PUF) inside the specific controller silicon that shipped with the drive. If the controller dies, simply swapping it for a matching replacement will not work because the donor IC will lack the unique hardware key required to unwrap the MEK. In these cases, chip-off recovery is also impossible, as the raw NAND contains only AES-256 ciphertext. Recovery relies entirely on our ability to perform component-level repair on the original board: fixing power rails or replacing PMICs so the original controller can power up and decrypt its own storage.

BitLocker and FileVault

BitLocker (Windows) and FileVault (macOS) add a software encryption layer on top of the drive. Recovery requires the original password, recovery key, or TPM chip. If you have the recovery key, we image the drive and decrypt offline. If the key is lost and the TPM chip is on a dead motherboard, the motherboard itself needs repair to release the key. We handle both the drive-side and board-side work.

Apple T2 and M-series

Apple solders NAND directly to the logic board and ties the encryption key to the Secure Enclave inside the T2 chip (late 2017 through 2020 Macs, starting with the iMac Pro) or the M-series SoC (2020 onward). The NAND cannot be read without the Secure Enclave on the same board. If the logic board dies, the encryption key is inaccessible unless the board is repaired at the component level. Chip-off is useless here; the raw NAND is AES-256 encrypted with a key that exists nowhere else. The only recovery path is logic board microsoldering to get the board powered on so the Secure Enclave can decrypt in place. We documented one such case where a MacBook SSD that shorted and smoked required full board-level repair before the Secure Enclave could decrypt.