We already wrote about what chip-off is, about why NVMe recovery got harder, and about an SSD that vanishes from BIOS. Those pages mention encryption in passing. This one is the laptop case people keep getting backwards: a current M.2 that will not enumerate, and the assumption that desoldering the packages is the rescue. It is not. We do not have a modern always-on AES laptop NVMe in the public case log. We will not invent one.
Always-on AES is not an optional checkbox
Older flash — many USB sticks, SD cards, some early SATA SSDs — wrote data the controller could later reconstruct from a raw chip dump. Wear leveling, XOR, interleaving, and LDPC still had to be reversed, but the payload on the NAND was not wrapped in a per-drive hardware key. That is the world the “just read the chips” advice comes from.
A modern laptop NVMe is usually a different machine. The controller runs AES on what it writes as a permanent property of the drive — SED-style, always-on, whether or not you ever set a password, opened BitLocker, or saw a “self-encrypting” sticker. Every user page that lands on the NAND is ciphertext. The media encryption key lives in the controller silicon, or in storage only that controller can use, often paired with other parts on that board. It is not a file sitting in plaintext next to your documents.
That is the same class of wall we already describe for self-encrypting drives and for Apple T2 / Apple Silicon: physical access to the media is not the same as access to the key. The difference here is how common it is. You do not have to buy an “enterprise SED.” A current Dell, HP, Lenovo, or no-name 2280 in a Windows laptop is often already encrypting in hardware.
This is also not Device Encryption. BitLocker that Windows turned on at setup is an OS volume lock. Always-on drive AES is underneath that. A shop can image a healthy NVMe and still hit the 48-digit BitLocker screen. A shop can also chip-off a dead NVMe and never even get to that screen, because the dump never becomes a volume. Two locks. Two different jobs. Do not collapse them.
Why a classic chip-off dump is ciphertext
Chip-off means: desolder the NAND, put it on a reader, pull a raw dump, then try to rebuild the flash translation layer and a file system. That path assumes the bytes on the chip are something a reconstruction tool can turn back into files once the controller’s scrambling is reversed.
Always-on AES breaks the assumption. The controller is not just scrambling and mapping. It is encrypting. Bypass it and you have:
- Ciphertext pages — the user data, encrypted to a key that did not come off with the package.
- A translator that only that controller owned — FTL tables, wear-level maps, and spare-area metadata written in that controller’s format, often themselves protected.
- No key on the flash — the DEK is not waiting in a plaintext spare block for a programmer to find. If it were, the encryption would be theater.
So the dump can be “clean” and still be useless. That is not a tooling gap we pretend we can close by grinding harder. It is the drive doing what it was designed to do.
Chip-off is still a real technique. The public log has an Olympus voice recorder where dead electronics and an intact eMMC were exactly that job. USB sticks and SD / CF cards still land there. A current laptop NVMe usually does not. Same word. Different media.
Leave the stick intact and get it evaluated. We will tell you whether this looks like a controller we can still talk to, a board-level fault, or an encryption wall. Free evaluation, no data, no fee.
What people should not do
Do not DIY chip-off. Hot-air videos, “reball the NAND,” and backyard IR stations are how pads lift, packages crack, and the PMIC next to the controller gets cooked. You cannot undo a destroyed board. You also cannot undo a dump that was never going to be plaintext.
Do not grind or decap the chips because a forum said the reader needs bare die. That is not a diagnostic. It is a one-way teardown of the only media. If the data mattered enough to try this, it mattered enough to stop.
Do not swap in a donor controller or move the NAND onto an “identical” M.2. The key is bound to the original silicon. A look-alike part does not inherit it. The transplant is a write to the only board that still had a chance — and it is how we get sticks that no longer have an original controller or an intact layout.
Do not run vendor “SSD repair,” nvme format, or firmware updaters to “clear the encryption” or make the drive show up. Those tools provision empty drives. They do not decrypt yours. Same class of mistake as the SATAFIRM factory-reset tools.
Do not keep reseating the M.2 or power-cycling a vanished SSD. Two or three attempts tell you it is not coming back. After that you are stressing a controller or PMIC that may still be the recovery path. Same rule as SSD not detected.
What a lab evaluates first — not chip-off
We do not start a modern laptop NVMe by lifting packages. The first questions are board-level and controller-level, on purpose:
- Controller health. Does the original controller come up at all — a real identify, a short/generic NVMe, a ROM or safe-mode state, or nothing? A controller that still talks, even badly, is a firmware and imaging problem, not a chip-read problem. A controller that will not come up may still be a power or board problem, not dead NAND.
- Adapter and board damage. Bent M.2, a cracked edge connector, a laptop socket that took the pads with it, liquid under the shield, a PMIC or rail that never finishes the power sequence. Those are the cases where board-level work — not a heat gun on the flash — is how the original controller gets another chance. The encryption key does not move to a new board just because you want it to.
- Encryption state. Always-on drive AES, BitLocker / Device Encryption on top, a firmware lock, or a drive that simply will not enumerate. We will tell you which one you have. We do not guess the lock from a photo of the laptop lid. A BitLocker key, if you have one, unlocks a volume after the drive can be imaged. It does not convert a raw NAND dump into files.
None of that is an exploit walkthrough. We are not publishing pinouts, key-extraction steps, or a donor-swap recipe. The honest line is the evaluation: which layer failed, whether the original controller is still the path, and whether the data is sitting behind a lock nobody can open without a protector. If the original controller is gone and the NAND is always-on AES, chip-off does not become the backup plan. The backup plan was a backup.
When board-level work is the path
On these drives, recovery — when it is possible — means getting the original controller far enough along to decrypt and hand over an image. That can look like:
- A PMIC or regulator fault that never lets the controller finish boot — the disappears from BIOS case.
- A firmware panic that still enumerates as 0 bytes or a generic device — the same class as Phison ROM mode and other controller-family work, not a chip-off.
- Physical damage to the stick or the laptop adapter that has to be stabilized before anyone talks to the controller.
If the NAND itself is worn out, that is still NAND degradation. Encryption does not fix worn cells. Chip-off does not either. We will say if the flash is the limit.
We don’t advertise a success rate on this. Always-on AES is working as designed. An honest lab tells you when the controller path is closed, not that a dump will “probably decode.”
What to do right now
Do not lift the chips. Do not grind them. Do not buy a “NAND programmer” kit because a video used one on a USB stick.
- Power the laptop down. Leave it off. Extra boots are not a diagnosis after the NVMe has already vanished.
- Leave the stick intact. If you already pulled the M.2, stop there. Do not reseat it ten times. Do not move the packages. Label it.
- Note what you have: laptop make, Windows vs BitLocker recovery screen vs a BIOS that lists nothing, whether this died after a drop, liquid, a sleep/resume, or an update. Photograph the screen. Photos are not a diagnosis.
- Look for a BitLocker key only if you actually hit that screen — aka.ms/myrecoverykey from another device. That key is for the OS volume. It is not a chip-off bypass.
- Get the original stick evaluated. Send the NVMe, not a USB clone of a 0-byte identify, and not chips in a bag. The technician on your case will tell you whether this looks like a controller we can still talk to, a board that never comes up, or an encryption wall. Free evaluation, no data, no fee.
If you are mailing it in, pack the module like any other failed SSD — how to ship a failed drive safely. A padded envelope is how M.2s arrive bent. For the work itself, see SSD & NVMe recovery and laptop internals. If the drive vanished from every host, start with SSD not detected. If the only problem is that NVMe is what everyone ships now, that is the SATA-to-NVMe post. Chip-off as a technique is still the chip-off page — this post is when that technique is the wrong first move.
Always-on AES laptop NVMe — FAQ
Can you just chip-off a dead laptop NVMe and read the files?
Is this the same problem as BitLocker?
Will a donor controller or an identical spare stick work?
When does chip-off still apply?
Should I heat-gun the chips off myself, or grind the package to “just read them”?
What does a lab look at first if chip-off is not the plan?
Is there a laptop always-on AES NVMe chip-off case in the public log?
What should I do right now?
The laptop NVMe is dead and someone is offering to pull the chips. On a modern always-on AES drive that is usually the wrong job. Start with a free evaluation before anyone lifts a package.
Request free evaluation →Free evaluation · No data, no fee · Talk directly with a technician.