Recovering Data From a Phone That Will Not Turn On: A Diagnostic Flowchart

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

A phone that "will not turn on" is not a single fault — it is a family of very different failures, and the right data-recovery path depends entirely on which one you are looking at. A device may be electrically dead (bad battery, blown charge port, failed PMIC, a short on a power rail, or cracked solder under the SoC), or it may be powering internally but failing to display or boot. This reference is a diagnostic flowchart for triaging a non-powering phone and routing it to the correct extraction strategy — software imaging via a maintenance mode, hardware acquisition off the memory chip, or the honest conclusion that the data is intact but cryptographically out of reach. It assumes lawful work on a device the requester owns or is authorized to recover.

Overview

Data recovery from a dead phone is governed by three independent questions that must be answered in order:

Can the storage be reached? — Is the NAND/eMMC/UFS physically intact and electrically addressable, either through the board (a maintenance mode or test points) or off the board (chip-off)?
Can a full image be obtained? — Even with storage access, modern devices gate low-level reads behind signed loaders and secure boot.
Can the image be decrypted? — On any modern phone the raw flash is ciphertext. Without the correct keys (which depend on the device's lock state), a perfect bit-for-bit image is useless.

The central, uncomfortable truth of 2020s mobile recovery is that #1 and #2 are the easy part. A skilled micro-solderer can almost always get to the bits. Whether those bits are readable plaintext is decided by the device's encryption design and its BFU (Before First Unlock) vs AFU (After First Unlock) state — not by soldering skill. Set the customer's expectations on that basis before opening the device.

A note on scope: this article covers recovering user data from a device the requester owns or is lawfully authorized to access. It does not cover defeating anti-theft protection (Apple Activation Lock, Android FRP/Factory Reset Protection) on devices you cannot prove ownership of. FRP/Activation Lock are account-binding locks, not data locks — bypassing them does not decrypt user data and is out of scope here.

Step 1: Triage the "dead" symptom

Before any recovery decision, establish why it will not power on. Do this on a bench power supply where possible, watching current draw — never blindly plug a suspected board-short into a charger, as it can escalate localized damage and make later recovery harder.

Symptom / bench observation	Most likely cause	Recovery implication
No current draw at all on bench supply	Open circuit: dead battery, broken charge port/flex, blown fuse, or a break in the main power rail	Storage is almost certainly intact; a port/battery/rail repair often revives the device long enough to image. Good prognosis.
High, immediate current draw / dead short	Shorted rail — frequently a failed PMIC, shorted cap, or liquid-corrosion bridge	Do not keep applying power. Find and clear the short first (thermal camera, freeze spray, injection). Data usually still intact.
Small "boot" current spike then drops to zero	SoC attempts to boot then aborts — often cracked BGA solder (CPU/PMIC), bad DDR, or corrupt bootloader	Reflow/reball or maintenance-mode imaging. Storage typically fine.
Powers, backlight/haptics but no image	Display, display power (bias) rail, or display connector — device may be fully alive	Often not a "data" problem at all: the phone may still boot headless. Try a maintenance mode or external display path before invasive work.
Liquid/corrosion history, intermittent	Corrosion on rails or, worst case, on the eMMC/UFS traces or the chip itself	Clean the board first. If the storage chip or its rail is corroded, this can become genuinely unrecoverable.
Prior "hard brick" after a failed flash	Corrupt bootloader/GPT; SoC may still enter emergency mode	Frequently recoverable via EDL/BROM even when the normal boot chain is dead. Storage intact.

Rule of thumb: most "dead" phones have perfectly healthy storage. The failure is almost always in power delivery or the boot chain, not the flash. That is what makes recovery feasible — and what makes managing the encryption expectation the real conversation.

Step 2: Boot repair vs. data-first

The two goals frequently conflict. A permanent, warranty-grade repair and a fast, safe data extraction are not the same job.

Boot-repair mindset — restore the device to a working, reliable state (new port, new PMIC, proper reball). Appropriate when the customer wants the phone back and the fault is cleanly repairable.
Data-first mindset — get the data out with the minimum intervention, even if the "fix" is temporary (e.g., a fly-wire jumper or a workshop-only jig that powers the board just long enough to image). The device may never be handed back working.

For a data-first job, prefer the least invasive path that reaches the storage, and image the device the moment it is stable — every additional power cycle on a marginal board is a risk, and on an AFU device every reboot risks dropping it to BFU (see Step 5).

Step 3: Software (in-place) extraction paths

If the board can be revived enough for the SoC to enumerate over USB, you may be able to image the storage without removing any chips, using a low-level maintenance/emergency mode. These modes are OEM/SoC-specific and, on modern devices, increasingly locked down.

Platform / mode	What it is	Tooling	Current reality (2026)
Qualcomm EDL (Emergency Download, USB PID 9008)	Sahara handshake → upload a Firehose programmer that executes the actual reads/writes to eMMC/UFS	`bkerler/edl`, vendor tools; needs the correct signed Firehose `.mbn` for that model	Works well on older/mid devices. Newer Sahara "V3" targets no longer answer chip-ID queries (OEM_PK_HASH/HW_ID), and OEM-signed/authenticated loaders are required — a generic loader will not run. UFS needs the `--memory=ufs` style path.
MediaTek BROM / Preloader	Exploitable BootROM state on many MTK SoCs; can disable download-agent auth (DAA/SLA) via a BROM vulnerability, entirely in RAM	`mtkclient`	Very effective on supported chipsets: can dump `userdata`, `super`, boot, etc., and read raw eMMC/UFS. The dump is still encrypted (see Step 5). Coverage varies by SoC generation.
Fastboot / bootloader	Standard Android bootloader interface	`fastboot`	Rarely useful for data — a locked bootloader will not let you read `userdata`, and unlocking wipes it. Diagnostic value only.
Apple DFU + checkm8	BootROM exploit on A5–A11 devices; forces a trusted boot to run extraction code	Cellebrite/ElcomSoft/GrayKey-class tooling	checkm8 is unpatchable on A11 and earlier and enables Full File System extraction subject to lock state. A12+ are constrained; SEP mitigations from iPhone 8/X onward block DFU-based disk unlock. checkm8 alone does not defeat the passcode.

Critical caveat: reaching EDL/BROM/DFU proves you can read the flash. It does not mean you get plaintext. On every modern device the bytes you pull are ciphertext until the encryption question (Step 5) is answered.

Step 4: Hardware (off-device) extraction paths

When the board cannot be revived, or the SoC path is locked, acquisition moves to the memory itself. In rising order of invasiveness:

Method	How it works	Best for	Limitations
ISP (In-System Programming)	Solder fine wires to test points on the PCB and talk to the memory controller directly (e.g., eMMC clock/cmd/data lines), board otherwise unpowered or in reset	eMMC / eMCP devices; faster and less destructive than chip-off	Requires accurate test-point locations — varies by model; verify against a boardview/service schematic, never guess pinouts. UFS ISP is far harder (differential lanes, higher speed) and often impractical.
JTAG / boundary-scan	Drive the SoC's TAP pads to read memory through the CPU	Some older eMMC devices with exposed/known TAPs	Largely superseded: slow, TAP access is disabled or undocumented on most modern SoCs, and it does nothing for encryption. Increasingly a legacy technique.
Chip-off	Desolder the NAND/eMMC/UFS package and read it on a dedicated programmer/adapter	Physically destroyed boards; last resort	Destructive and skill-intensive (BGA reball/prep). You get a raw image — but on FBE/FDE devices it is ciphertext, and UFS chip-off requires the matching reader. Highest risk of the chip itself being damaged.

All three hardware paths share one property: they deliver the raw storage, not the keys. They are the right answer when the board is dead, but they do nothing to solve encryption. Choose ISP over chip-off whenever the board can host test points, and reserve chip-off for boards that cannot be powered or probed at all.

Step 5: The encryption reality check

This is where most dead-phone recoveries actually succeed or fail. A flawless physical image of a modern phone is, by default, undecryptable without the right key material.

Encryption models

FDE (Full-Disk Encryption) — older Android; a single key protects the whole userdata partition. Largely replaced by FBE.
FBE (File-Based Encryption) — Android 10+; per-file keys, with class keys tied to credential state. Some files (Device-Encrypted storage) are available at boot; most user data (Credential-Encrypted) is not, until first unlock.
Apple — per-file Data Protection classes with keys wrapped by the passcode and enforced by the SEP (Secure Enclave). The SEP rate-limits and gates passcode attempts in hardware.

BFU vs AFU — the single most important variable

BFU (Before First Unlock): the device has powered on but no one has entered the passcode since boot. The credential-derived keys are not in RAM. A physical image yields mostly ciphertext; you get only the small set of always-available data. Recovering the rest requires the passcode (or a viable brute force, itself gated by the SEP/secure hardware).
AFU (After First Unlock): the passcode has been entered at least once since boot, so decryption keys are resident in memory. Far more data is reachable. This is why keeping a marginal device alive and unlocked during recovery is so valuable — and why isolating and imaging it quickly matters.

The 72-hour clock (recent, important) Both major platforms now auto-reboot a locked, idle device back into BFU:

iOS 18.1 (October 2024) introduced an inactivity reboot after roughly 72 hours idle-locked.
Android rolled out an equivalent ~72-hour auto-restart via Google Play services / Android system updates (from around April 2025).

The practical effect: an AFU device left sitting will flush its keys and drop to BFU on its own, collapsing what is recoverable. If you have a live AFU device, do not let it idle — power-isolate and image without delay.

What is genuinely, permanently unrecoverable — say so honestly

A BFU modern device with a strong, unknown passcode and no exploit for its SoC generation: the credential-encrypted data is effectively unrecoverable. No amount of chip-off changes this — you will image ciphertext.
SEP-gated Apple devices (A12+) in BFU without a supported unlock path: you can image but not decrypt user data.
A physically destroyed or corroded storage die (not just the board): if the NAND cells or UFS/eMMC controller are gone, the data is gone.
FRP / Activation Lock: not a data problem and out of scope — clearing them (on a device you own) does not decrypt anything and does not recover user files.

Diagnostic flowchart

Read top to bottom; stop at the first branch that matches.

Phone will not turn on
        |
[1] Bench-power it. What is the current draw?
        |-- None ............... open circuit -> repair port/battery/rail -> go to [3]
        |-- Dead short ........ CLEAR THE SHORT FIRST (never keep charging) -> go to [3]
        |-- Boot spike->0 ..... SoC/BGA/DDR/bootloader fault -> reflow/reball or [3]
        |-- Alive, no image ... display/bias/connector -> may boot headless -> [3]
        |
[2] Can the board be revived enough to enumerate over USB?
        |-- Yes -> [3] Software path
        |-- No  -> [4] Hardware path
        |
[3] Software path: enter the SoC maintenance mode
        Qualcomm EDL (9008 + signed Firehose) / MediaTek BROM (mtkclient)
        / Apple DFU+checkm8 (A11-)  -> obtain image -> go to [5]
        |
[4] Hardware path (board dead / mode locked)
        ISP test points (eMMC/eMCP) preferred
        -> else JTAG (legacy) -> else Chip-off (last resort, destructive)
        -> obtain raw image -> go to [5]
        |
[5] ENCRYPTION CHECK (decides success)
        Lock state?  AFU -> keys likely present -> decrypt/parse -> DONE
                     BFU -> credential keys absent
                             |-- passcode known / supported exploit -> decrypt -> DONE
                             |-- neither -> data is ciphertext -> UNRECOVERABLE (be honest)

How to use this reference

Start at Step 1, always. Diagnose why it will not power on before deciding on any extraction method. The symptom dictates the path.
Protect the board. Suspected short? Bench supply, current-limited — do not charge it. Every needless power cycle risks the board, and every reboot risks dropping an AFU device to BFU.
Set expectations before opening. Determine platform, SoC generation, OS version, and — critically — the likely lock state (BFU/AFU) and whether the passcode is known. Communicate the encryption reality (Step 5) to the owner before invasive work, not after.
Prefer the least invasive path that reaches the data. Software mode > ISP > JTAG > chip-off. Escalate only when the previous rung is impossible.
Verify, don't fabricate. Test-point maps, firehose loader files, and pinouts are model-specific. Confirm them against boardviews/service schematics and known-good loader repositories. Never invent coordinates or pinouts.
Stay lawful. Work only on devices the requester owns or is authorized to recover. FRP/Activation Lock defeat on unowned devices is out of scope.

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.