SSD Hardware Encryption and Data Recovery

Several competitors market encryption bypass capabilities that don't match hardware engineering. The AES-256 Media Encryption Key on a Phison E12 or Silicon Motion SM2262EN lives inside the controller die and never traverses the host bus, the DRAM, or the NAND interface in plaintext. No proprietary software can extract that key from raw NAND. Recovery requires reviving the original controller through board-level microsoldering, not bypassing the cipher.

AES-256 has a key space of 2^256. Brute-force attacks are mathematically impossible. The difference between extracting a BitLocker metadata clear key, a known Microsoft architectural feature, and brute-forcing an active Media Encryption Key is the difference between a recoverable software state and an unrecoverable hardware failure. "Proprietary programming" cannot break AES-256. When a company markets bypass capability, the engineering reality is usually either factory diagnostic key retrieval on a partially functional controller, or a software-level edge case that doesn't apply to hardware-encrypted NAND.

We don't claim to bypass AES-256. We diagnose the electrical failure with a FLIR thermal camera, replace the shorted PMIC or decoupling capacitor with a Hakko FM-2032 on an FM-203 base, and revive the original controller. When the controller boots, the Hardware Unique Key unwraps the Media Encryption Key, the AES engine initializes, and imaging through PC-3000 Portable III returns plaintext. SATA board repair: $450–$600. NVMe: $600–$900. No data, no fee.

SSD hardware encryption uses a layered key hierarchy. The Media Encryption Key (MEK) encrypts all NAND data and is stored inside the controller chip; it never leaves that silicon. When a user password is set, a Key Encryption Key (KEK) wraps the MEK. Which key lives where determines whether recovery is possible after controller failure.

Media Encryption Key (MEK)

The AES-256 key used to encrypt and decrypt all data on the NAND. Stored in a secure region of the controller chip or in a protected area of the NAND that only the original controller can access. Unique per drive; no two SSDs share the same MEK.

Key Encryption Key (KEK)

When a user password is set (via ATA Security, OPAL, or OS-level encryption in hardware mode), the MEK is wrapped with the KEK derived from the password. The wrapped MEK is stored on the drive. Without the correct password, the MEK cannot be unwrapped and data remains encrypted.

Self-Encrypting Drive (SED)

An SSD that complies with the TCG OPAL specification for hardware encryption management. OPAL provides a standardized interface for setting user authentication, defining encryption ranges, and managing the key hierarchy. Samsung, Micron/Crucial, and Intel enterprise SSDs commonly support OPAL 2.0.

Always-On Encryption (No User Password)

Drives that encrypt all data by default without user authentication. The MEK is accessible to the controller without a password. Data is protected from raw NAND reads (chip-off) but not from normal host access through the controller.

How Is the MEK Generated and Stored Inside the Controller?

The MEK is generated once, at first power-on after manufacturing, by a hardware random number generator (TRNG) integrated into the controller die. The 256-bit output is written into a key-storage region that is electrically isolated from the host interface. On most modern NVMe controllers, that region is a dedicated OTP (one-time programmable) block or an internal key vault fused into controller silicon, depending on the manufacturer. In both architectures the key never traverses the SATA or PCIe bus, never appears in any externally readable register, and cannot be exported through any documented vendor command. The host sees only plaintext on read and writes plaintext on write; the encryption is performed inline by the controller as data crosses between the host interface and the NAND channels.

The Hardware Unique Key (HUK) is a separate per-die secret fused into the controller at wafer test. The HUK is used to wrap (encrypt) the MEK before any persistent storage of key material, so even if the wrapped MEK is later read out of a firmware module, it remains an unintelligible blob unless unwrapped by the original HUK inside the original controller silicon. Destroying the controller package destroys the HUK, which destroys the ability to unwrap the MEK, which destroys the ability to decrypt any NAND block on that drive. There is no off-controller fallback by design.

How Does PC-3000 SSD Access Encrypted Drives Without Bypassing AES-256?

PC-3000 SSD doesn't crack or bypass AES-256. It uses Factory/Technological mode to inject a volatile Microcode Loader into the controller's SRAM. This loader bypasses corrupted on-NAND firmware, disables background garbage collection, provides direct access to the System Area, and reconstructs a virtual translator in host RAM. Once stable communication is established, read commands pass through the hardware AES engine and the drive outputs plaintext, making encryption transparent to the recovery workflow.

PC-3000 Portable III injects the volatile Microcode Loader into the controller's SRAM during power-on. The loader replaces the corrupted firmware overlay with a temporary diagnostic image. It disables background garbage collection so the FTL doesn't remap blocks during imaging, and it exposes the System Area modules where the wrapped MEK blob and the translator tables live.

For Phison PS5012 and PS5016 controllers, entering Safe Mode requires shorting specific test points on the PCB during power-up. The PC-3000 Phison utility then uploads the LDR through the ROM bootstrap interface. For Silicon Motion SM2262EN and SM2263XT controllers, ROM pin bridging forces the controller to accept an external volatile microcode loader instead of loading damaged firmware from NAND. In both cases, the AES engine and the wrapped MEK blob remain physically intact inside the controller silicon; the recovery path provides a clean firmware environment that preserves the decryption chain.

After the LDR establishes stable communication, PC-3000 rebuilds a virtual FTL in host RAM by reading the mapping tables from the System Area. The controller's hardware AES engine remains active; every read command passes through it, decrypting ciphertext on the NAND into plaintext before the data reaches the PC-3000 imaging buffer. The encryption is transparent to the recovery operator because the original controller is doing the decryption with its original MEK. SATA firmware reconstruction runs $600–$900; NVMe runs $900–$1,200.

Why Is the NAND Itself Only Ciphertext?

Every byte the host writes is encrypted with AES-256 (XTS mode on most NVMe controllers, ECB or CBC variants on older SATA designs) before it lands in a NAND page. The Flash Translation Layer, the wear-leveling metadata, the L2P (logical-to-physical) mapping table, and the user-visible LBA range are all stored as ciphertext keyed by the MEK. Firmware modules in the System Area are typically also encrypted, though some controllers use a separate firmware-encryption key distinct from the user MEK. The net effect is that a NAND die desoldered from a self-encrypting SSD contains no plaintext anywhere: every page is high-entropy ciphertext that is statistically indistinguishable from random data.

This is the structural reason chip-off recovery fails on a self-encrypting drive. Chip-off reads NAND pages with a programmer such as the PC-3000 Flash Reader; it returns the raw cells exactly as written. On an unencrypted controller, those raw pages still need ECC correction, descrambling, and FTL reconstruction, but the underlying user data is plaintext and recoverable. On a self-encrypting drive, the same chip-off read returns ciphertext, and no amount of off-controller post- processing can decrypt it. The decryption operation is mathematically bound to the MEK inside the original controller; without that controller alive on a working PCB, the ciphertext is unrecoverable.

Why Board-Level Repair Is the Only Path for Self-Encrypting SSDs

Because the MEK cannot leave the controller and the NAND holds only ciphertext, every recovery from a dead self-encrypting drive has to keep the original controller die alive long enough to image the user data through its own AES engine. That is a board-level repair problem, not a software problem. The recovery sequence is microsoldering work on the PCB to restore power delivery (replacing failed PMIC capacitors, blown rail-decoupling components, or shorted DC-DC inductors using a Hakko FM-2032 on an FM-203 or FX-951 base, Atten 862 hot air rework, and a Zhuo Mao precision BGA station for controller-package work), followed by attaching the repaired board to a PC-3000 SSD on a Portable III chassis to enter the vendor- specific diagnostic mode, stabilize the firmware, and stream the decrypted user area out through the controller's native data path. Imaging through the live controller is the only step that converts the ciphertext on the NAND back into the files the customer is asking for. No chip-off bench, no third-party decryption tool, and no controller transplant can substitute for that path.

Which Controller Families Implement Always-On Hardware AES?

The following NVMe controller families ship with hardware AES-256 enabled by default, regardless of whether the user activates OPAL or BitLocker eDrive. On these drives the NAND is ciphertext from the first write, and recovery requires reviving the original controller:

• Phison PS5012 (E12), PS5013 (E13T), PS5016 (E16), PS5018 (E18), PS5019 (E19T) NVMe controllers, used across Kingston KC3000, Corsair MP510/MP600, PNY XLR8, Sabrent Rocket and Rocket 4 Plus, Crucial P2, Inland Performance, and many OEM-branded SSDs. PC-3000 SSD supports board-level recovery on E13T, E16, and E19T (E12 support is limited to Toshiba/Kioxia NAND); the E18 module is firmware repair only. SATA board repair: $450–$600. NVMe: $600–$900.
• Silicon Motion SM2262, SM2262EN, SM2263, SM2263EN, SM2267XT, SM2269XT NVMe controllers, with the EN-suffix variants explicitly documented by ACELab as shipping with encryption enabled. These are the silicon under HP EX950/EX900, ADATA XPG SX8200 Pro, Kingston KC2500, Crucial P1, and a number of OEM NVMe drives. PC-3000 SSD has full recovery support on the Silicon Motion family through the Portable III chassis.
• Samsung in-house controllers (Polaris on 960 EVO/PRO, Phoenix on 970 EVO/PRO/EVO Plus, Elpis on 980 PRO, Pablo on 980 non-Pro, Pascal on 990 PRO). These ship with AES-256 always-on. Per the ACELab PC-3000 SSD supported list (v3.8.10), modern Samsung in-house controllers are not on the supported list. Rossmann does not currently offer in-lab recovery for Samsung Polaris, Phoenix, Pablo, Elpis, or Pascal controllers. If a 970 EVO, 980 PRO, or 990 PRO arrives with a dead controller, see the separate Samsung SSD page for the current intake policy.
• Maxio MAP1602 / MAP1602A NVMe controllers, used on a range of value-segment PCIe 4.0 drives. These implement always-on AES. Rossmann does not currently offer in-lab recovery for Maxio MAP1602. Intake on these drives is limited to evaluation and consultation; no destructive attempts are made.

For an explanation of why chip-off on these families returns only encrypted blocks, see the dedicated section on why chip-off fails on self-encrypting SSDs. For the controller-specific recovery procedures we run on the supported families, see the Phison architecture page and the flagship SSD data recovery page.

An encrypted SSD whose firmware has panicked rarely reports its real identity to the host. The controller drops into a protective ROM mode and announces a generic factory string, a tiny diagnostic-mode capacity, or nothing at all. These interface-level markers are the first piece of evidence that the AES engine and the wrapped Media Encryption Key are still alive inside the controller, and that the recovery path is firmware repair or board-level rework rather than chip-off.

In all five rows the cryptographic chain is intact. The wrapped MEK lives in the system-area partition or the controller's on-die OTP region; the Hardware Unique Key fused into the silicon is untouched; the AES engine wakes the moment firmware initialization completes. Chip-off in any of these conditions destroys a recoverable case, because the moment the NAND is desoldered the HUK becomes unreachable and the wrapped MEK becomes mathematically inert. Board repair or firmware reconstruction through the original controller is the path that preserves the decryption chain: SATA board repair at $450–$600, NVMe at $600–$900, firmware reconstruction at $600–$900 (SATA) or $900–$1,200 (NVMe). For the full SSD service map, see ssd data recovery. For the contrast case of unencrypted legacy drives where chip-off remains viable, see chip-off NAND recovery.

When a hardware-encrypted SSD fails, the MEK is trapped inside the dead or malfunctioning controller. Replacing the controller destroys the key association. Component-level microsoldering to repair the power delivery circuit is the mandatory prerequisite for decryption: it revives the original controller, restores MEK access, & enables the AES engine to decrypt NAND reads during imaging.

1. 01

   Diagnose the failure point

   Using FLIR thermal imaging and multimeter probing, we identify whether the failure is in the controller itself, the PMIC (Power Management IC), voltage regulators, decoupling capacitors, or the NAND interface. Many "dead controller" symptoms are actually failed passives on the power delivery circuit that prevent the controller from booting.

2. 02

   Component-level repair

   Using Hakko FM-2032 microsoldering irons and Atten 862 hot air rework, we replace failed voltage regulators, capacitors, resistors, or rework BGA connections on the controller. The goal is to restore power delivery and signal integrity so the controller boots its firmware and initializes the AES engine with the original MEK.

3. 03

   Firmware stabilization and imaging

   Once the controller boots, PC-3000 communicates with it via vendor-specific commands to stabilize the firmware and image the drive. Because the original controller is running, all reads pass through the AES decryption engine. The imaged data is plaintext, ready for file system analysis.

Rossmann's foundation in board-level repair applies directly to encrypted SSD recovery. Most data recovery labs handle firmware-level work but not component-level soldering. When the failure is electrical rather than logical, those labs cannot proceed. We can, because board-level repair is what this shop was built on.

The workflow runs under a no-fix-no-fee guarantee: free evaluation on arrival, firm quote before any work begins, and no charge if the controller cannot be revived and data cannot be imaged. Honest limit: when the original controller is physically destroyed (cracked die, burned silicon) on an SED or always-on encrypted drive, the Hardware Unique Key fused into that controller is lost; the wrapped Media Encryption Key can no longer be unwrapped, permanently severing the decryption chain. Chip-off will yield ciphertext with no path to decryption. We state this up front after evaluation rather than running up a bill on a job we cannot complete.

The data recovery industry pivoted with the arrival of always-on hardware AES-256. For modern NVMe and SATA solid-state drives implementing TCG OPAL 2.0, ATA Security, BitLocker eDrive hardware mode, Apple T2 or M-series Secure Enclave, or sitting behind Microsoft Pluton as the host root of trust, chip-off NAND extraction is cryptographically impossible. The only path to recovered data is microsoldering on the existing controller.

The Media Encryption Key Is Fused to the Silicon

Modern SSD controllers generate the Media Encryption Key inside their secure boundary using an on-die True Random Number Generator. The MEK is held in controller SRAM or a logically isolated secure enclave, wrapped by a Key Encryption Key, and bound to a Hardware Unique Key fused into the silicon during semiconductor fabrication. The HUK is never exposed on the PCIe or SATA bus, never written to NAND in plaintext, and never readable by the host operating system. Every page written to NAND is transformed to AES-256 ciphertext before it leaves the controller; every page read passes through the same AES engine in the opposite direction.

Therefore, desoldering the NAND packages and reading them on a programmer yields high-entropy ciphertext with no decryption path. A theoretical attacker could attempt to decap the controller die and probe the fuse bank for the HUK, but modern secure silicon ships with active anti-tamper meshes and zeroization circuitry that destroy the volatile key state the moment package integrity is compromised. Commercial data recovery labs do not extract silicon-fused HUK material; the design intent of the fabricator is that no one does.

Encryption Schemes That Bind the Key to the Controller Silicon

The same cryptographic constraint applies regardless of whether the user actively configured a password. The following encryption topologies all keep the active MEK or its wrapping key inside silicon that must remain functional for any decryption to occur:

• TCG OPAL 2.0. Industry standard for Self-Encrypting Drives. The MEK lives in the SSD controller; user PINs unwrap a KEK that releases it at runtime.
• ATA Security (Class 0 always-on). The factory-generated MEK is active without user configuration. Password lockout, where present, wraps the MEK with a KEK derived from the password.
• BitLocker eDrive hardware mode. The Microsoft IEEE 1667 protocol offloads encryption to the SSD controller's AES engine. The BitLocker recovery key authenticates the controller; it does not itself decrypt NAND data.
• Apple T2 and M-series Secure Enclave. AES keys are bound to a hardware UID inside the SoC. The NAND packages are soldered to the logic board and have no independent cryptographic identity.
• Microsoft Pluton. A CPU-integrated security processor shipping in AMD Ryzen 6000 / 7000 / 8000 / 9000 / Ryzen AI, Intel Core Ultra 200V Series and Core Ultra Series 3, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series. When Pluton acts as the BitLocker root of trust on a hardware-mode volume, it stores the wrapping key. The MEK still lives only in the SSD controller. Pluton being intact does not help if the SSD controller is dead.

Why the Controller Usually Survives the Failure

A drive that drops off the PCIe or SATA bus typically presents as a "dead controller" to the host, but the controller silicon is usually intact. The failure point is almost always in the surrounding power delivery network: a shorted Power Management IC stepping down 3.3V to the 0.9V to 1.2V controller core rail or the 1.8V / 2.5V / 3.3V NAND rails, a blown low-dropout regulator feeding the DRAM cache, a fractured multi-layer ceramic capacitor pulling a rail to ground, BGA solder cracking under thermal cycling, or ESD damage to the PCIe PHY transceiver pads. In each of these cases the controller die, the HUK fuse bank, and the wrapped MEK blob are physically intact. Restoring the power and signal environment lets the original controller boot, initialize its AES engine with the original MEK, and decrypt reads transparently during imaging.

The Microsoldering and Imaging Workflow

Board-level recovery on an encrypted SSD runs at an ESD-controlled bench, not in a laminar-flow environment, because solid-state silicon is hermetically packaged and immune to airborne particulate. The workflow our Austin, TX lab uses on hardware-encrypted SSDs is:

1. Thermal localization. Inject a current-limited supply into the suspect rail and use a FLIR thermal camera to identify the component dissipating heat. This finds shorted PMICs, decoupling caps, and regulators in seconds without prolonged power application.
2. Component-level rework. Replace shorted SMD passives and small ICs with a Hakko FM-2032 micro-soldering iron on an FM-203 base (an FX-951 base is interchangeable). For larger QFN PMICs and voltage regulators, use the Atten 862 hot-air rework station for temperature-controlled reflow.
3. BGA reflow when required. When the controller or a NAND package needs reflow or transplantation to an electrically identical donor PCB, the Zhuo Mao precision BGA rework station runs the pre-heat, soak, reflow, and cool profile required for high-density packages without damaging adjacent silicon.
4. Post-repair imaging through the original controller. Once the drive enumerates, interface it with the PC-3000 Portable III for vendor-specific firmware stabilization, FTL reconstruction in Technological Mode if the volatile mapping was lost, and full logical imaging. Because the original controller is running, every read passes through the AES engine and the imaged data is plaintext.

Board-level pricing for SATA encrypted drives starts at $450–$600; NVMe starts at $600–$900. A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers.

Repairing the original controller is the only recovery path when hardware encryption is in play, which is why every encrypted-drive case routes through our microsoldering bench rather than a chip-off rig. For the full controller family matrix, supported diagnostic interfaces, and firm tier pricing, see our ssd data recovery service overview.

Apple T2 and M-series chips implement hardware encryption through a Secure Enclave coprocessor. The AES keys are fused into the Secure Enclave silicon, and the NAND storage is soldered directly to the logic board. There are no removable drives to send to another lab; recovery requires repairing the logic board so the Secure Enclave can serve the decryption keys.

On a MacBook with a T2 or M-series chip, the SSD controller is integrated into the Apple silicon. The NAND chips are soldered to the logic board and communicate with the SoC through a proprietary bus. The Secure Enclave generates and stores the volume encryption keys.

If the MacBook logic board fails, the Secure Enclave keys are inaccessible. Desoldering the NAND yields AES-256 ciphertext with no path to decryption.

Recovery requires repairing the logic board so the T2 or M-series chip boots and the Secure Enclave can serve the decryption keys. This is T2/M-series data recovery at the board level: identifying which power rail, capacitor, or IC failure prevents the SoC from initializing, repairing it, and imaging the drive through the running system.

Encrypted SSD recovery falls into the circuit board repair or firmware recovery tier. SATA SSD board repair: $450–$600. NVMe board repair: $600–$900. Firmware recovery (if controller boots but firmware is corrupted): SATA $600–$900, NVMe $900–$1,200.

If board repair requires a donor drive for component harvesting, the donor cost is additional. A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers.

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

TCG OPAL 2.0 is an industry specification that standardizes how hardware encryption is managed on Self-Encrypting Drives. OPAL defines user authentication, locking ranges, and the key hierarchy that protects data on the NAND. When an OPAL drive's controller dies, the authentication layer adds complexity to recovery beyond basic Class 0 always-on encryption.

Always-On Encryption (ATA Security Class 0)

The SSD encrypts all data by default using a factory-generated MEK. No user authentication is required. The controller decrypts reads transparently. Data is protected from raw NAND extraction (chip-off) but accessible to anyone who can boot the controller. Most consumer SSDs from Samsung, WD, Kingston, & Crucial ship in Class 0 mode.

TCG OPAL 2.0 Authentication

Full OPAL with user authentication, locking ranges, & admin/user password separation. The MEK is wrapped with a KEK derived from the user's credentials. Booting the controller alone isn't enough; the correct password or recovery key must also be supplied. Enterprise SSDs from Samsung (PM9A3, PM893), Micron (7450 PRO), & Intel/Solidigm commonly ship with Class 2 capability.

MEK/KEK Hierarchy

The Media Encryption Key encrypts the NAND contents. The Key Encryption Key encrypts the MEK. The KEK derives from the user password or from a TPM-stored secret. Destroying any link in this chain makes the data unrecoverable. A PSID revert destroys the MEK itself, permanently erasing all data regardless of password knowledge.

PSID Revert (Factory Reset)

The Physical Security ID is printed on the drive label. A PSID revert generates a new MEK, rendering all existing NAND data permanently unreadable. This is designed for situations where the admin password is lost. It is a data-destruction operation, not a recovery tool. Running PSID revert on a drive with needed data is irreversible.

OPAL drives are harder to recover when the controller dies because the authentication layer must also be satisfied after repair. The controller must boot, accept the user's credentials, unwrap the KEK, and then decrypt reads using the MEK. If the firmware module that stores the wrapped key is corrupted, PC-3000 SSD's firmware recovery utilities ($600–$900 SATA, $900–$1,200 NVMe) can reconstruct the damaged modules while preserving the key material.

When an OPAL drive enters PC-3000 diagnostic mode, the AES engine is alive but locking ranges may stay locked. PC-3000 issues an OPAL authentication challenge; the user supplies the BitLocker recovery key or OPAL PSK; the controller verifies the KEK and unwraps the MEK. Without the correct key, data stays locked even on a functional controller.

The OPAL Authentication Flow in PC-3000

PC-3000 SSD communicates with OPAL controllers through vendor-specific diagnostic commands. When the controller boots into service mode, its AES engine initializes with the original MEK. The locking ranges remain in the locked state from the last OPAL session.

PC-3000 issues an authentication challenge to the OPAL security layer. The user supplies the 48-digit BitLocker recovery key or the OPAL Personal Security Key. The controller derives the KEK from that input, verifies it against the wrapped MEK blob, and unwraps the MEK if the credential matches.

BitLocker Hardware Mode and the Recovery Key

In BitLocker hardware mode, the recovery key unlocks the OPAL session. It doesn't itself decrypt raw NAND. The controller's AES engine performs the decryption transparently after the KEK verification succeeds. Every read command passing through the controller returns plaintext data to the PC-3000 imaging buffer.

What Happens When the Password or Recovery Key Is Lost?

If the original controller is revived through board-level repair but the user can't provide the BitLocker recovery key or OPAL PSK, the data remains locked. A functional controller with a locked OPAL range returns encrypted data just as a dead controller would. The difference is that the first case is recoverable if the key is found; the second case requires both board repair and key recovery.

Why Write-Blocking Matters During Authentication

Write-blocking during authentication prevents spurious writes from corrupting the OPAL state table. A TRIM command mid-session could alter locking range metadata, causing the controller to reject the KEK verification or remap the blocks holding the wrapped MEK. The PC-3000 bus-level interceptor keeps NAND state static.

Most intake symptoms phrased as "encrypted drive can't be read" are not cryptographic dead-ends. The AES engine inside a modern SSD controller rarely fails on its own; it is the surrounding power-delivery and firmware infrastructure that fails. Triaging an encrypted SSD requires separating four distinct failure classes before treating any of them as an encryption problem. Three of the four are recoverable through board-level repair or firmware reconstruction, and the encryption layer remains transparent to the workflow.

1. The drive does not enumerate on the SATA or PCIe bus at all. Symptom: no entry in BIOS, no /dev node on Linux, no Disk Management entry on Windows, no NVMe namespace via nvme list. Diagnostic interface: a bench power supply current-limited at 1A, multimeter probing the 3.3V input rail and each downstream regulator output (typically 1.2V controller core, 1.8V NAND I/O, 2.5V DRAM if present), and FLIR thermal localization to find shorted decoupling capacitors or a failed PMIC die. The blocker is electrical, not cryptographic. Recovery path: component-level rework using a Hakko FM-2032 on an FM-203 base for SMD passives and an Atten 862 hot-air station for QFN PMICs. The AES engine, HUK fuse bank, and wrapped MEK blob are all physically intact; restoring power delivery boots the controller and reads pass through the decryption engine as plaintext.
2. The drive enumerates but reports wrong capacity, wrong model name, or zero bytes. Symptom: hdparm -I returns garbled identity strings, nvme id-ctrl shows nonsense serial or model fields, or the LBA count reads as 0 / a tiny diagnostic-mode value (8MB, 30MB) instead of the advertised capacity. Diagnostic interface: PC-3000 SSD module identification for the controller family (Phison utility for E12 / E16 / E19T, Silicon Motion utility for SM2259 / SM2262 / SM2267 / SM2269, Marvell utility for 88SS1074 / 88SS1093). The blocker is firmware or FTL corruption: a damaged translator, lost block-allocation table, or corrupted system-area module. Recovery path: enter the controller's service mode (test-point shorting for Phison or ROM pin bridging for Silicon Motion) and rebuild the affected modules using PC-3000 SSD's reconstruction utilities at $600–$900 (SATA) or $900–$1,200 (NVMe). The AES engine and the wrapped MEK survive firmware corruption; once the FTL is rebuilt, the controller decrypts reads transparently.
3. The drive enumerates with correct identity but reads return I/O errors. Symptom: identity strings look right, the namespace is the expected size, but dd if=/dev/sdX of=/dev/null bs=1M returns immediate or partway-through read failures. Diagnostic interface: query the security layer before assuming NAND wear. Run hdparm -I /dev/sdX and read the "Security" block for ATA Security state. Run sedutil-cli --query /dev/sdX to enumerate TCG OPAL 2.0 locking ranges, admin/user PIN configuration, and lock state. Run manage-bde -status on Windows to determine whether BitLocker is running in hardware mode and which recovery key applies. If a locking range is locked, supply the BitLocker recovery key or OPAL PSK before any imaging attempt; the controller will not return plaintext until the KEK has unwrapped the MEK. When the locking range is unlocked but reads still fail, the issue is NAND-level wear or read-disturb beyond ECC correction, which routes back to PC-3000 SSD firmware recovery rather than to the encryption layer.
4. The controller silicon itself is physically destroyed. Symptom: visible cracked package, burned silicon, delamination of the controller package, exposed bond wires, or any prior decap attempt. Diagnostic interface: stereo microscope at 20x to 80x, FLIR thermal imaging to confirm no rail can be brought up without a dead short through the controller die. This is the failure class where the Hardware Unique Key fused into the controller silicon is lost: the wrapped Media Encryption Key on NAND can no longer be unwrapped because the HUK that would unwrap it no longer exists. Chip-off would yield ciphertext with no decryption path. We disclose this category at evaluation rather than billing for a recovery the physics will not support.

The encryption layer is the true blocker only in failure class four. Classes one through three preserve the HUK, the wrapped MEK, and the AES engine; the recovery workflow proceeds exactly as on an unencrypted drive once the underlying electrical or firmware fault is corrected, because the controller decrypts reads transparently the moment it boots. Free evaluation determines which class the drive belongs to before any quote is issued. Call (512) 212-9111.

Recovery software works on encrypted SSDs only when the controller is functional. A running controller decrypts reads transparently, so Disk Drill, EaseUS, PhotoRec, or R-Studio sees plaintext. When the controller is dead or stuck in a firmware fault state, software can't communicate with the drive at all.

No amount of retry logic fixes a hardware failure.

Software Works When

• The SSD is detected in BIOS & mounts (or partially mounts) in the OS, and the issue is logical: accidental deletion with TRIM disabled, corrupted partition table, formatted volume.
• The controller is running its AES engine normally, so the software's sector reads return plaintext data.
• TRIM has not already executed on the deleted blocks. Once the controller unmaps the logical addresses and garbage collection erases the NAND blocks, neither software nor a lab can recover the data.

Software Fails When

• The SSD isn't detected in BIOS (dead controller, shorted PMIC, failed voltage regulator). Software needs a functioning interface to send commands.
• The drive reports wrong capacity, wrong model name, or shows 0 bytes. These are firmware corruption symptoms that require PC-3000 SSD to repair the FTL & module tables.
• The controller is dead on an encrypted drive. Chip-off NAND extraction yields AES-256 ciphertext without the original key.

Software tools are worth trying first if the drive powers on and is recognized. They cost between $0 (PhotoRec, open source) and $90 (Disk Drill, R-Studio). If the SSD isn't detected or the controller is in a fault state, stop. Continued power cycling stresses degrading NAND cells. Send the drive for a free evaluation; board repair starts at $450–$600 for SATA and $600–$900 for NVMe.