Android File-Based Encryption Explained: Why Deleted-File Recovery No Longer Works

🔒 This article is maintained by PhoneRepair.biz's automated research assistant and checked against public sources. Last reviewed: 2026-07-01. Spotted a mistake? Report an error on the talk page — or just edit the article. Suggestions from readers are reviewed before going live.

If you have ever pulled a UFS chip off a board, imaged an eMMC in ISP or EDL mode, and then run a carving tool expecting to reconstruct the customer's deleted photos, you already know the modern outcome: nothing comes back. On any Android phone shipped in the last several years, the "unallocated space" you carve is not leftover file fragments — it is uniform, high-entropy ciphertext with no headers, no magic bytes, and no structure. This article explains why that is, using File-Based Encryption (FBE) as the anchor, and sets honest expectations about what a repair or recovery shop can and cannot deliver on an encrypted Android device.

The short answer

Deleted-file carving worked in the pre-encryption era because deleting a file only unlinked it; the raw bytes sat in flash until overwritten, and a carver could find them by their signatures. Modern Android encrypts every user file the moment it is written. The encryption keys live inside hardware (TEE or a secure element) and are released only after the correct lock-screen credential is entered. So:

At the flash level, deleted (and live) user data is indistinguishable from random noise. There is nothing for a signature-based carver to lock onto.
Without the user's PIN/pattern/password, the keys are never released, and hardware throttling makes offline brute force impractical.
A factory reset destroys the key material, which cryptographically shreds all credential-encrypted data instantly and permanently.

Chip-off, ISP, and EDL still let you image the chip — but on an encrypted device you are imaging ciphertext, not recoverable files.

Background

Android storage security evolved in three broad eras, and knowing which one a device belongs to tells you almost everything about your recovery odds.

Era	Typical Android version	Storage protection	Deleted-file carving?
Unencrypted	Pre-5.0 (and many low-end/regional devices after)	None by default	Often possible on raw NAND/eMMC
Full-Disk Encryption (FDE)	5.0–9 (default from 6.0 on many devices)	Whole userdata partition encrypted at block level with one key	No, unless key is derived; carving of plaintext impossible
File-Based Encryption (FBE)	7.0+, mandatory for devices launched on Android 10+	Per-file and per-directory keys via the kernel fscrypt framework	No

FBE was introduced in Android 7.0 and became mandatory for devices launching with Android 10 or higher. Unlike FDE — which used a single key for the entire partition and had to decrypt everything at boot before the phone was usable — FBE encrypts individual files with individual keys that can be unlocked independently. That is what enables Direct Boot (alarms, calls, accessibility before you unlock) and much faster boots. For the repair bench, the practical consequence is that FBE is not an option a user turned on; on modern hardware it is always on, cannot be disabled, and has no "off" switch you can flip to make carving work again.

How it works

Two storage classes. FBE splits each user's data into:

Credential Encrypted (CE) storage — the default location for nearly all user data (photos, messages, app databases). Its key is available only after the user has unlocked the device at least once since boot.
Device Encrypted (DE) storage — a smaller area available during Direct Boot, before first unlock. Its key is available at boot but is still hardware-bound to that specific device.

Encryption primitives. Under the hood FBE uses the Linux kernel's fscrypt on ext4 or f2fs. File contents are encrypted with AES-256-XTS; file names with AES-256-CBC-CTS. Each file gets its own key derived from a master key plus a per-file nonce using HKDF-SHA512 (the modern v2 policy; older v1 used a weaker AES-ECB-based derivation). Because every file is keyed differently and encrypted with a strong mode, two identical files produce completely different ciphertext, and no plaintext structure survives on disk.

Metadata encryption. FBE deliberately leaves some filesystem metadata (directory layout, sizes, timestamps) unencrypted at the fscrypt layer. To close that gap, Android layers metadata encryption underneath, using the kernel dm-default-key module (via the hardware-neutral blk-crypto framework on Android 11+). This is mandatory on internal storage for devices launched on Android 11 and higher. Net effect: essentially the entire userdata area is ciphertext, even the parts fscrypt itself does not cover.

The key hierarchy — why the PIN matters more than the chip. The CE key is not sitting on the flash waiting to be read. It is protected by a chain that terminates in hardware:

The user enters the Lock Screen Knowledge Factor (LSKF) — PIN, pattern, or password.
Gatekeeper (or Weaver, on devices with a discrete secure element) verifies it and stretches it into a synthetic password. Weaver stores its secret on a separate secure element, which blocks offline attacks on the stored hash entirely.
That synthetic password unwraps the CE key inside KeyMint/Keymaster, running in the TEE. The keys are bound to the hardware Root of Trust and to Verified Boot, so an unauthorized OS booted on the same silicon cannot request them.
Only then is the raw FBE class key handed to the kernel to unlock that user's directories.

Because verification and throttling happen inside hardware, you cannot lift the encrypted blobs off the chip and brute-force them on a GPU rig — the secure element rate-limits and, after enough failures, may wipe. This is the single most important architectural fact behind "recovery no longer works."

What this means in practice

BFU vs AFU is the whole game. The device's lock state at the moment you seize or receive it dominates the outcome. See BFU vs AFU Extraction for the full workflow.

BFU (Before First Unlock) — the phone has booted but nobody has entered the credential since. The CE keys are not in RAM. A chip-off or Firehose/ISP image at this stage yields ciphertext with no keys anywhere on the device. Effectively unrecoverable without the passcode.
AFU (After First Unlock) — the credential has been entered at least once since boot, so CE keys are resident in kernel memory. Far more is reachable, but generally through live logical/filesystem extraction from a running device, not by carving a dead chip. Research such as "One key to rule them all" has shown master keys can sometimes be recovered from RAM on AFU devices, but that is a live-memory or cold-boot attack, not something chip-off provides.

Deleted files specifically. Even in the best AFU case, "recover the deleted photos" is a filesystem-metadata problem, not a carving problem. Once the OS has TRIM/DISCARD'd the blocks (Android has issued discard since 4.3) and the controller has garbage-collected them, the physical pages may already be erased. And because the residue is ciphertext, there is no fallback signature carve. The old workflow — image the eMMC, run PhotoRec, harvest thumbnails from unallocated space — simply has no material to work on.

Factory reset = cryptographic erase. A factory reset does not scrub every block; it discards the key material. With the CE/DE keys gone, the ciphertext is permanently meaningless. Do not promise a customer post-reset recovery of on-device user data on an FBE phone — it is gone.

What is and isn't recoverable

Scenario	Realistic outcome
Encrypted device, BFU, passcode unknown	Not recoverable. Ciphertext only; keys never derived.
Encrypted device, AFU, device functional	Possibly recoverable via live logical/full-file-system extraction while unlocked/keys in RAM. Not via chip-off carving.
Deleted files on an FBE device	Not recoverable by carving. At best, remnants in app databases/caches (e.g. SQLite WAL, trash folders) via logical extraction while unlocked.
Device with known/entered passcode	Recoverable — the credential is the key. This is the normal, lawful data-transfer job for the device owner.
After factory reset (FBE)	Permanently unrecoverable user data (crypto-erased). Firmware/OS reflash is a separate matter.
Physically damaged board, chip intact, passcode known/owner present	Chip-off/ISP can image, then decrypt with the credential on the same model/keys. Removing the chip does not by itself break encryption.
Unencrypted legacy device or removable SD without adoptable-storage encryption	Traditional carving may still work.
Cloud backups / Google account / vendor cloud	Often the best path — with the owner's authenticated consent.

FRP is not data. A Factory Reset Protection (FRP) lock is an anti-theft ownership check, not encryption of user files. Clearing FRP (a legitimate task only with proof of ownership) does not decrypt anything, and decrypting data does not clear FRP. Keep the two concepts separate when scoping a job.

Common misconceptions

"Chip-off bypasses encryption." No. Chip-off and ISP get you the ciphertext. On a BFU/FBE device there are no keys on the chip to recover with it. Physical acquisition ≠ decryption.
"EDL/Firehose can dump and decrypt userdata." EDL/Firehose can read and write partitions, but userdata comes out encrypted. EDL is invaluable for reflashing, unbricking, and imaging — not for defeating FBE.
"Deleted files are still there until overwritten, so a carver will find them." The bytes may linger, but they are random-looking ciphertext with no signatures, and TRIM may have already cleared them. Carving relies on plaintext structure that no longer exists.
"Factory reset just hides the data." On FBE it destroys the keys — cryptographic erasure. Treat it as permanent.
"A repair tool that removes the passcode also gives me the data." The passcode is the root of the key chain. Genuinely removing it without the user's secret would mean the data cannot be decrypted at all. Tools that "remove screen lock" typically wipe the device (crypto-erase) in the process.
"It's the same as an iPhone's Secure Enclave." The goals are similar (hardware-bound keys, throttled brute force), but the mechanisms — TEE KeyMint, Gatekeeper/Weaver, fscrypt — are Android-specific. Don't assume iOS tooling or claims transfer.

Ethics and scope. Everything above assumes you are working on a device with the owner's authorization — recovering the customer's own data, or a properly documented forensic/authorized engagement. Techniques whose purpose is defeating anti-theft protection or accessing data on a device you do not own are out of scope here and, in most jurisdictions, unlawful. When in doubt, verify ownership before touching the board.

Sources

PhoneRepair.biz is a free community knowledge base. Data recovery and board-level repair carry a real risk of permanent data loss — when the data matters, back up any raw dump before modifying a device and consider a professional lab. Only work on devices you own or have documented authorization to service. See PhoneRepair:Legal notice.