The Mobile Data Recovery Decision Tree

🔒 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.

The Mobile Data Recovery Decision Tree is a structured triage reference that guides a technician from an intake device — in whatever physical and lock state it arrives — to the most promising and lawful data-recovery path, or to an honest determination that the data is permanently unrecoverable. Because modern smartphones bind user data to hardware-backed encryption keys, the correct method depends far less on "which tool is most powerful" than on three upfront variables: the device's lock state (BFU vs AFU), its chipset/SoC and encryption model, and the nature of the failure (logical, storage, or board-level). This article organizes those variables into decision matrices so you can rule methods in or out before opening the device or quoting the customer.

Overview

Every recovery job resolves along four intersecting axes. Identify each one at intake, because a "no" on any of them often ends the decision tree regardless of skill or equipment:

Authorization — Do you have documented proof that the customer owns the device or is authorized to access it? This gate comes first. Bypassing anti-theft locks (Google Factory Reset Protection (FRP), Apple Activation Lock) on a device the customer cannot prove they own is unlawful and outside the scope of legitimate recovery. See Ethics and Chain of Custody in Data Recovery.
Lock state — Is the device Before First Unlock (BFU) or After First Unlock (AFU)? On modern devices this single variable determines whether the file-system keys are even resident in memory.
Encryption model — Android File-Based Encryption (FBE) vs legacy Full-Disk Encryption (FDE); Apple Data Protection with the Secure Enclave Processor (SEP). Encryption is the reason raw NAND dumps are usually worthless on current hardware.
Failure mode — Logical (accidental deletion, corruption, working device), electrical/board-level (dead device, liquid/physical damage), or storage-media failure (eMMC/UFS wear or corruption).

A recurring, unwelcome truth runs through the whole tree: on a device with encryption enabled, physically reading the flash without the original CPU and the user credential yields ciphertext you cannot decrypt. The decision tree is largely an exercise in determining whether a usable key can be brought together with the data.

Master decision matrix: state, storage, encryption

Use this table to establish the ceiling of what is theoretically recoverable before choosing a method. "FFS" = Full File System.

Scenario	Device state	What is accessible	Practical ceiling
Working device, credential known/removable	AFU or unlocked	CE + DE storage (all user data)	Logical or FFS extraction; often a simple backup solves it
Working device, credential unknown, AFU	AFU	CE keys resident in RAM/keyring	Method-dependent FFS if an exploit exists for the SoC; keep it powered and unlocked
Powered but never unlocked since boot	BFU	DE storage only; CE data encrypted at rest	Minimal user data; expect metadata, not content
Powered off / rebooted, credential unknown	BFU	Ciphertext only until first unlock	Effectively unrecoverable without the credential
Factory reset performed, modern device	n/a	Encryption keys destroyed at reset	Permanently unrecoverable — no "undelete"
Dead/damaged board, encryption enabled	Depends on repair	Ciphertext on flash	Requires CPU+RAM+flash kept together; chip-off alone fails

Reading the ceiling. On Android, encryption is effectively binary: an AFU acquisition (or a known unlock code) unlocks Credential Encrypted (CE) storage and yields essentially a Full File System, while a BFU device exposes only Device Encrypted (DE) storage — enough for some system artifacts but little user content. On Apple hardware, the SEP gates Data Protection classes; on iOS 16 and later, SEP hardening prevents key derivation after a DFU-mode boot if a passcode was ever set, so a BFU iPhone is a near-total wall.

BFU vs AFU: the state that decides everything

	BFU (Before First Unlock)	AFU (After First Unlock)
Definition	Device booted but not unlocked since power-on	Device unlocked at least once since boot
Key material	CE / Data-Protection keys not derived; not in RAM	Class/CE keys decrypted and cached in memory (vold keyring / SEP)
User data	Largely inaccessible ciphertext	Most user data readable (~95% of an FFS on iOS)
Field priority	Little to preserve; document and assess	Preserve state: do not power off, do not let it lock out

Field handling of an AFU device. If a lawful, authorized job arrives as a live AFU device, the state itself is the asset. Keep it charged, prevent it from rebooting, and be aware of time-based defenses: iOS 18 introduced an inactivity reboot that forces the device from AFU back to BFU after 72 hours (168 hours in iOS 18.0, tightened to 72 in 18.1). Android devices vary but can wipe or lock after failed-attempt thresholds. There is no legitimate way to indefinitely suspend these protections; plan the recovery within the window.

Failure-mode branch: pick the physical method

Once the state/encryption ceiling is understood, the failure mode selects the physical approach. Order of preference is generally least-invasive first.

Method	When to use	Invasiveness	Key limitation
Logical / backup	Working device, access available	None	Only what the OS exposes; excludes app sandboxes without FFS
EDL / Download / DFU	Live SoC, low-level read supported	None (software)	Increasingly gated by signed/authenticated loaders on current devices
JTAG	Test-access port available, board intact	Low	Slow; rare on modern UFS; yields ciphertext if encrypted
ISP	Test pads accessible, storage healthy	Medium	Requires correct pinout; ciphertext if encrypted
Chip-Off	Board unrepairable, storage intact	High (destructive)	Raw dump only; useless alone on FBE/FDE devices
Board repair / CPU-flash transplant	Damaged board, encryption enabled	Very high	Must move CPU+RAM+flash together to keep the crypto chain

EDL / Firehose reality check. Qualcomm Emergency Download (EDL) and MediaTek Download modes historically enabled low-level raw reads via a Sahara-loaded Firehose programmer (community tooling such as bkerler/edl and mtkclient). On current-generation hardware, OEMs increasingly require authenticated/signed EDL programmers and disable diagnostic interfaces, so these methods are no longer broadly available — and even when they work, they return ciphertext on an encrypted device.

Storage-media specifics. JTAG uses the board's test access port without desoldering; ISP reads the eMMC/UFS directly via PCB test pads (faster than JTAG on UFS); chip-off physically removes the BGA package (BGA153/BGA254/BGA297 for UFS 3.x/4.0) and reads it in an offline programmer. Chip-off after-care commonly requires cleaning and reballing the BGA. Critically, none of these recover plaintext from an FBE/FDE device without the original SoC and credential.

Apple vs Android quick-reference

	Apple (iOS)	Android
Encryption	Data Protection classes gated by SEP	FBE (Android 10+ mandatory); legacy FDE on older devices
Boot-ROM exploit	checkm8: A5–A11 (iPhone 4S–X), unpatchable	Per-SoC (e.g. some MediaTek BootROM); varies widely
checkm8 caveat	FFS only if no passcode or passcode known; A12+ not exploitable via checkm8	n/a
SEP hardening	iOS 16+ blocks key derivation after DFU boot if a passcode was ever set	TEE-derived keys; DE/CE split
BFU outcome	Near-total wall on modern iOS	DE-only; little user content

Note that even a successful checkm8 extraction on eligible hardware does not, by itself, decrypt content protected by passcode-derived keys — the credential is still required for the protected classes.

What is permanently unrecoverable

Be honest with customers up front. The following are not recoverable by any legitimate technique, and no tool or service changes this:

Post-factory-reset data on a modern encrypted device. The reset destroys the key material; the underlying flash contents become cryptographically inaccessible. There is no "undelete."
BFU user data without the credential on current Android and iOS — the keys are simply not present.
Content protected by SEP/TEE-derived keys when the passcode/PIN is unknown and the hardware has no applicable exploit (e.g. iPhone A12+ in BFU).
Raw flash dumps from an encrypted device read via chip-off/ISP/JTAG without the original CPU — you hold ciphertext with no path to the key.

Equally important: FRP / Activation Lock is not a data problem. These anti-theft locks sit above the data layer and are an ownership-verification gate, not an encryption barrier you "recover" past. Removing them is only appropriate with verified ownership, and doing so does not resurrect data destroyed by a reset.

How to use this reference

Walk the tree top-down at intake:

Confirm authorization in writing. No documented ownership → stop. This governs everything downstream.
Determine lock state. Is it live and AFU/unlocked, or BFU/off? If AFU and authorized, preserve that state immediately (charge, prevent reboot/lockout) before anything else.
Identify SoC and encryption model. Apple A-series and iOS version, or Android SoC and FBE/FDE. Use the Apple-vs-Android table to find the ceiling.
Classify the failure mode. Logical, board-level, or storage-media — then pick the least-invasive method from the failure-mode branch that can actually reach a usable key.
Sanity-check against "permanently unrecoverable." If the scenario matches that list, quote no false hope; document why and advise on backups/iCloud/Google account cloud copies as alternatives.
Verify model-specific details before touching the board. Test-point locations, pinouts, and BGA layouts vary by model — verify against boardview/service documentation; never work from assumed coordinates.

Treat every branch as a gate, not a suggestion: the tree is designed to fail fast and honestly so you neither over-promise nor damage a device chasing data that the mathematics of encryption has already placed out of reach.

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.