Pulling the UFS Chip Off a Dead Android Phone Usually Won't Decrypt Your Data

Written and maintained by the Desert Data Recovery lab team. · Updated September 13, 2026

We already wrote about why a smashed phone is an encryption problem, about iPhones and the Secure Enclave, and about what chip-off is. Those pages say the storage is paired to the processor. This one is the Android case people keep getting backwards: a dead Samsung, Pixel, or OnePlus, and the assumption that desoldering the UFS is the rescue. It is not. We do not have a modern Android UFS / FBE chip-off in the public case log. We will not invent one.

File-Based Encryption is not an optional checkbox

Older flash — many USB sticks, SD cards, some feature phones and voice recorders — wrote data a lab could later reconstruct from a raw chip dump. Wear leveling and LDPC still had to be reversed, but the payload on the NAND was not wrapped in a per-device hardware key. That is the world the “just read the UFS” advice comes from. The public log has an Olympus voice recorder that was exactly that job: dead electronics, intact eMMC, no File-Based Encryption. A current Android phone is a different machine.

Modern Android encrypts userdata with File-Based Encryption (FBE). Each file (and its metadata) is wrapped with keys the OS only releases after a normal boot — and, for the credential-encrypted class, after the lock-screen PIN, pattern, or password. Those file keys are not sitting in plaintext next to your photos. They are wrapped again by keys that only that phone’s Trusted Execution Environment can use.

FBE has been the default path for new Android devices for years. It is not a setting most owners turned on. You do not have to buy a “secure enterprise phone.” A current Pixel, Galaxy, or mid-range Android already encrypts this way. The related post on always-on AES laptop NVMe is the same class of wall on a different device: physical access to the media is not access to the key. That post is the drive controller. This one is the phone’s TEE.

TEE keys do not come off with the package

The Trusted Execution Environment is a locked-down corner of the processor — usually ARM TrustZone — isolated from the Android you see. Some phones add a discrete security chip on top of that (Pixel Titan / StrongBox, Samsung Knox-class silicon). In plain language: the SoC, and sometimes a second chip next to it, hold wrapping keys that were generated on that hardware and never exported.

What that means for a chip-off:

• The UFS holds ciphertext. A programmer can dump pages. Those pages are still FBE-wrapped files, not a mountable photo folder.
• The wrapping keys stay in the TEE. They are device-unique. They are not a file in a spare UFS block waiting for a reader. If they were, the encryption would be theater.
• The lock screen is part of the key for a lot of what you care about. Credential-encrypted data does not unwrap because someone powered the board. It unwraps when that original TEE accepts the credential it was bound to.

That is the same geometry we already describe for Apple T2 / Apple Silicon and for the Secure Enclave on an iPhone: the flash and the security silicon are a matched pair. Move the flash, lose the pair.

Why a classic UFS chip-off — or a donor-board dump — is ciphertext

Chip-off means: desolder the UFS, put it on a reader, pull a raw dump, then try to rebuild a file system. That path assumes the bytes on the package are something a reconstruction tool can turn back into files once the flash translation layer is reversed.

FBE plus TEE wrapping breaks the assumption. Bypass the phone and you have:

• Encrypted file contents and filenames — FBE wraps both. A “clean” dump can still be unreadable names over unreadable bytes.
• No key on the flash — the media encryption keys are wrapped by hardware that did not travel with the package.
• The same wall on a donor board. Dropping that UFS onto a “same model” motherboard, or imaging it through a donor’s UFS controller, does not import the original TEE’s wrapping keys. You have moved the ciphertext. You have not moved the lock.

So the dump can be complete and still be useless. That is not a tooling gap we pretend we can close by heating harder. It is the phone doing what it was designed to do.

Older full-disk encryption — carefully, without overclaiming

Before FBE, some Androids used full-disk encryption (FDE): one volume key over the userdata partition. On a few of those older devices the key derivation was more software-shaped, and a raw dump could theoretically become a key-recovery problem rather than a pairing problem.

That sentence is the most we will say. FDE-era phones were not all the same. Some already hardware-wrapped the volume key. Some did not. We will not publish a year cutoff, a model list, or a “these are easy” chart. We will not claim a dump of your old Galaxy will decrypt because a forum post mentioned FDE. If you still have a genuinely old, unencrypted, or weakly bound device, evaluation is how we tell you. The typical dead Android that arrives now is FBE with TEE-backed keys. Treat it that way until a technician says otherwise.

What people should not do

Do not factory-reset, wipe, or flash a factory image. A reset on modern Android is a crypto-erase: the TEE destroys the wrapping keys. The UFS may still be full of bits. Those bits are no longer your files. “Repair firmware” downloads and unauthorized flash tools are the same class of mistake — they provision an empty phone. They do not decrypt yours.

Do not DIY chip-off. Hot-air videos, “reball the UFS,” and backyard IR stations are how pads lift, packages crack, and the PMIC next to the SoC gets cooked. You cannot undo a destroyed board. You also cannot undo a dump that was never going to be plaintext.

Do not swap the UFS onto a donor board or drop a look-alike SoC onto yours. The keys are bound to the original silicon. A same-model motherboard from eBay does not inherit them. The transplant is a write to the only paired set that still had a chance — and it is how we get boards that no longer have an original TEE or an intact layout.

Do not keep charging or power-cycling a dead or wet phone. Two or three attempts tell you it is not coming back. After that you are stressing the power rails and the security silicon that may still be the recovery path. Rice is not a treatment. A hair dryer is not a lab.

Do not send a loose UFS in a bag and keep the board. The chip is not the job. The paired board is the job.

What a lab actually needs — not a loose chip

We do not start a modern Android by lifting the UFS. The first questions are board-level, on purpose:

• Original board context. The SoC, the TEE / security chip, and the UFS as they were paired. If a component transplant is even in the conversation later, it is because that original set is still the path — not because a donor inherits the keys.
• Whether the board can be brought up. Power rails, PMIC, connectors, corrosion, a crushed processor vs. a dead charge port. Those are repair questions. A phone that can boot far enough for the original TEE to accept a credential is a different job from a shattered secure chip.
• Encryption and lock state. FBE with a known PIN, FBE with a lost credential, a phone that never gets far enough to ask, or a wipe that already killed the keys. We will tell you which one you have. We do not guess from a photo of the glass.

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 paired hardware is still the path, and whether the data is sitting behind a lock nobody can open without the TEE and the credential. If the original security silicon is gone and the userdata is FBE, chip-off does not become the backup plan. The backup plan was a backup — Google Photos, a cable backup, another device already signed in.

We don’t advertise a success rate on this. FBE is working as designed. An honest lab tells you when the board path is closed, not that a dump will “probably decode.”

What to do right now

Do not lift the UFS. Do not flash the phone. Do not buy a “NAND programmer” kit because a video used one on a USB stick.

1. Stop powering it. Leave it off. Extra charge cycles are not a diagnosis after the board has already gone dark.
2. Leave it intact. If you already opened it, stop there. Do not pull the UFS. Do not swap ICs. Label the phone.
3. Write down the lock-screen credential if you know it — PIN, pattern, or password. A repaired Android still needs it. If you do not know it, say so. Do not guess-lock the device into a wipe.
4. Note what you have: make and model, whether this died after a drop, liquid, or an update, and whether anyone already reset or flashed it. Photograph the board if it is already open. Photos are not a diagnosis.
5. Check the backup you already have before paying for a board repair — Google Photos, a computer backup, another phone signed into the same account. There is no reason to recover files you already have.
6. Get the original phone evaluated. Send the device, not a chip in an anti-static bag. The technician on your case will tell you whether this looks like a board we can still bring up, a pairing wall, or keys that are already gone. Free evaluation, no data, no fee.

If you are mailing it in, pack the phone so the board cannot flex — how to ship a failed drive safely is the same idea. For the wider phone picture, start with broken & smashed phones. iPhone-specific recovery is the iPhone page. Chip-off as a technique is still the chip-off page — this post is when that technique is the wrong first move on Android.