ISP Data Recovery for Beginners: Reading eMMC via Test Points

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

Recovery at a glance
Difficulty	Advanced (micro-soldering + protocol knowledge)
Risk to data	High — soldering, over-voltage and any write/erase are irreversible
Time estimate	1–4 hours (longer for first-time pinouts)
Storage type	eMMC / eMCP (managed NAND); the same idea extends to UFS with different tooling
Device state	Powered-off, board physically accessible; can work even when the SoC is dead as long as the eMMC survives
Key tools	eMMC programmer (Easy JTAG Plus, Medusa Pro, UFi Box, eMMC Pro), microsoldering station, microscope, multimeter

ISP (In-System Programming) data recovery is a chip-preserving technique in which you solder fine wires directly to the test points that break out an eMMC (or eMCP) chip's data bus on a phone or tablet motherboard, then read the raw flash with an eMMC programmer — without removing the chip. It sits between the non-invasive EDL/Firehose method and destructive chip-off: less risky than lifting a BGA, but far more demanding than a software read. This article is a beginner-oriented procedure that emphasises doing it safely and, just as importantly, being honest about what modern encryption makes unrecoverable.

Overview

An eMMC device is managed NAND: a flash die plus an integrated controller that speaks the JEDEC eMMC protocol over a simple synchronous bus. ISP taps that bus at the board level. The controller still does the wear-levelling, ECC and bad-block management, so you get a clean logical image (user area plus boot and RPMB partitions) exactly as the phone's SoC would see it — but you bypass the SoC, the bootloader, USB, and any locked download mode entirely.

Because the read is done through the eMMC's own controller, ISP is the method of choice when:

the device will not boot or enter EDL mode / download mode (dead SoC, corrupt bootloader, damaged USB/PMIC),
the storage is not strongly encrypted (many feature phones, IoT/embedded boards, dashcams, older or unencrypted Android, some Chromebooks), or
you need a forensic image while keeping the chip on the board for continued examination.

ISP reads flash and only flash. It cannot read RAM, the TEE, or any key material that never lands on the eMMC. Keep that limitation in mind throughout — it is the single most misunderstood point about this technique.

Applies to

Storage type: eMMC 4.x / 5.0 / 5.1 and eMCP (eMMC + LPDDR in one package). The same concept applies to UFS, but UFS uses high-speed differential MIPI M-PHY lanes and requires a UFS-capable programmer and much cleaner harnessing; treat UFS ISP as a separate, harder discipline.
Brands / models: Chip-agnostic. Common on Samsung, Xiaomi, Vivo, Oppo/Realme, Tecno, Honor/Huawei, plus embedded/IoT boards. Test-point locations vary by model — always verify against a boardview/schematic or a known-good pinout for that exact PCB revision.
SoC: Any, including MediaTek, Unisoc, Qualcomm and Exynos, because ISP does not talk to the SoC. (If the SoC is alive and the device is Qualcomm, an EDL/Firehose read is usually safer and easier — try that first.)
OS & encryption: Android, KaiOS, embedded Linux/RTOS. Encryption is the deciding factor for whether the dump is useful — see Risk to data and Success rate and limitations.
Required device state: Powered off; battery/power removed; board accessible and clean. The eMMC must be electrically healthy — ISP cannot fix a physically dead flash die.

Risk to data

Reading an eMMC via ISP is non-destructive to the stored data when done correctly — you are only clocking data out. The danger is in the physical and electrical process, and there are several genuine points of no return:

Over-voltage on VCCQ (irreversible, kills the chip). VCCQ (the I/O rail) is typically 1.8 V. Feeding it 3.3 V, or swapping VCC/VCCQ, can instantly destroy the eMMC and any hope of recovery. Measure before you power anything.
Any write, erase, format, or "repair" command (irreversible). The moment you issue a write — reformatting a corrupt partition, "fixing" the RPMB, re-partitioning — the original bytes are gone. Image first, work on the copy. Treat the on-board chip as read-only until you have a verified dump.
Solder/pad damage (can be terminal). Test points are tiny; excessive heat or force lifts the pad or tears a trace, which can turn a recoverable device into a chip-off job — or a total loss.
Shorting adjacent points (can damage the board/PMIC). A slipped probe or bridged solder joint across live rails can cascade into other failures.

There is no undo. If the data is high-value and you are inexperienced, stop and hand the board to a specialist before you power it.

Tools and materials required

Programmer / reader (one of):

Easy JTAG Plus (Z3X), Medusa Pro, UFi Box, or eMMC Pro — all provide selectable I/O voltage, halt/reset-core control, and eMMC read/dump functions.

Hardware:

Temperature-controlled soldering station with a fine (0.2 mm class) tip; hot-air rework station (for a practice/donor board only).
0.1–0.3 mm enamelled/jumper wire (magnet wire) for the taps.
Stereo microscope or at least a 10× loupe.
Multimeter with continuity/diode mode — non-negotiable for verifying pins and voltages.
ISP soldering fixture / PCB holder; optional ISP clip adapters where a known adapter exists for the model.
ISP-voltage adapter — needed when VCC and VCCQ require different voltages (6-wire setups).

Consumables:

Good no-clean flux, quality leaded or SAC solder, IPA 99 %, UV-cure or Kapton to tack wires down, fibreglass pen.

Reference material:

Boardview / schematic for the exact model, or a trusted published test-point pinout. Never work off a similar-but-different revision.

Prerequisites and safety

Work on your own device or with documented, informed consent. See Legal and consent note.
Practise on a scrap board of the same model first. The standard way to learn a pinout is to remove the eMMC from an identical donor board and fingerprint the pads — never learn on the exhibit.
ESD-safe bench, grounded strap, clean flux residue as you go.
Photograph the board before and after; document every wire colour → signal mapping.
Confirm the device is fully de-powered and the battery disconnected before soldering.
Have the programmer's I/O voltage set low / correct before connecting power to the chip.

Step-by-step procedure

Test-point coordinates are model-specific. The steps below describe the general, repeatable method; get the actual pad locations from a boardview or a verified pinout for your exact PCB. Do not trust coordinates you cannot confirm.

Identify the minimum signal set. For a basic 1-bit-mode read you need six lines: CLK, CMD, DAT0, VCC (core, commonly ~2.85–3.3 V), VCCQ (I/O, commonly 1.8 V), and GND. DAT0 is sufficient because every eMMC host supports 1-bit mode during init. RST_n is sometimes wired to a test point and can help; DS and DAT1–7 are not needed for a slow, reliable read.
Fingerprint the pads on a donor board. On an identical scrap board, hot-air off the eMMC. With the multimeter in continuity mode, probe from each known BGA ball to nearby test points to map which pad is CLK/CMD/DAT0/VCC/VCCQ/GND. Record it. This map now applies to your exhibit's matching PCB revision.
Confirm voltages on a live donor (not the exhibit). Power a working board and measure VCC-to-GND and VCCQ-to-GND. Note both. If VCC = VCCQ you can use a 5-wire scheme; if they differ (the common case, e.g. VCC ≈ 2.85 V, VCCQ = 1.8 V) you need 6 wires and the ISP-voltage adapter so each rail gets the right voltage.
Prepare the exhibit. Clean the target pads with flux and a fibreglass pen. Pre-tin lightly if the pads are bare.
Solder the taps. Attach 0.1–0.3 mm wire to CLK, CMD, DAT0, VCC, VCCQ and GND. Keep leads short and equal-ish; tack them down (Kapton/UV glue) so they cannot move and short. Inspect under the microscope for bridges.
Prevent SoC bus contention. If the board's SoC could power up and drive the same bus, the read will fail or corrupt. Use the programmer's "halt core" / hold-in-reset feature, and/or keep the SoC unpowered by feeding power only to the eMMC rails through the ISP adapter. On many boards, powering just VCC/VCCQ at the chip leaves the CPU dormant.
Wire to the programmer. Connect CLK, CMD, DAT0 to the box's eMMC I/O, GND to ground, and VCC/VCCQ to the box's programmable supplies (through the voltage adapter if required). Set the box's I/O voltage to match VCCQ (usually 1.8 V) before applying power.
Power up at low speed and detect the chip. In the box software (Easy JTAG, Medusa, UFi, etc.), select eMMC / ISP mode, use a conservative clock, and run detect. A successful init reports the CID/EXT_CSD, manufacturer, and capacity. If nothing detects, drop the clock, re-check GND and VCCQ, and re-inspect joints.
Read the full image (read-only). Dump the User Area (and, if relevant, Boot1/Boot2 and RPMB) to a raw image file. Do not issue any write/erase. Verify the reported size matches the chip's rated capacity.
Re-read to confirm integrity. Take a second full read and compare hashes (see next section). Only then power down and remove the wires.

Verifying the result

Confirm the chip identity — CID/EXT_CSD, capacity, and manufacturer should be sane and match the device model.
Hash-verify the dump. Compute SHA-256 of the image; do a second independent read and confirm the hashes match. A stable, repeatable read is your evidence the bus was clean.
Inspect the partition layout. On Android, tools that parse GPT should show the expected partitions (boot, system/super, userdata, persist, etc.). Mount or carve the unencrypted partitions to confirm real content is present.
Sanity-check userdata. If userdata is FBE/FDE encrypted, it will read as high-entropy noise — that is expected and does not mean the read failed. It means the bytes are ciphertext (see below).

Success rate and limitations

Where ISP genuinely recovers data:

Unencrypted or weakly protected storage — many feature phones, KaiOS devices, dashcams, GPS units, IoT/embedded boards, and older/unencrypted Android.
Devices with a dead SoC / bootloader but a healthy eMMC — ISP is often the only way to reach that flash.
Forensic imaging where the chip must stay on the board.

What ISP does NOT recover:

Modern encrypted user data. Since Android 10, File-Based Encryption (FBE) is mandatory. Each file is encrypted (AES-256-XTS for contents) with keys derived from a hardware-bound key (Qualcomm TrustZone / Samsung Knox / a TEE Keystore) combined with the user's PIN/password/pattern. Those keys live in the secure element and RAM — never in the eMMC in usable form. An ISP dump is flash only, so Credential-Encrypted (CE) data comes out as ciphertext you cannot decrypt without the keys.
BFU vs AFU makes no difference to an ISP dump. The BFU (Before First Unlock) / AFU (After First Unlock) distinction matters for live-RAM key extraction, not for a flash image — ISP cannot read RAM. Even in AFU, the keys you'd need are in memory, out of reach of an eMMC read.
Older FDE (Full-Disk Encryption, pre-Android 10) is likewise unrecoverable from flash alone without the passphrase-derived key.
Apple devices. iPhones use UFS with the SEP (Secure Enclave) and hardware-entangled keys; ISP of the raw storage yields only ciphertext. This technique is not a path into modern iPhone user data.
FRP is not user data. Factory Reset Protection is an anti-theft/account lock, separate from data encryption. This article does not cover defeating FRP on devices you do not own, and clearing FRP does not decrypt anything.

Bottom line: ISP is excellent for getting the bytes off the chip, and those bytes are fully useful when the data is unencrypted. On a modern, encrypted Android phone the dump is real but the CE user data is cryptographically out of reach without the user's credential and the hardware keys.

Common pitfalls and troubleshooting

Symptom	Likely cause	Action
Chip won't detect at all	Wrong/absent GND or VCCQ; cold joint; wrong voltage	Recheck GND continuity, confirm VCCQ (usually 1.8 V), reflow joints, lower clock
Detects then drops / corrupt reads	SoC fighting for the bus	Halt/hold core in reset; power only the eMMC rails; shorten leads
Reads but wrong/tiny capacity	Bad CMD/CLK integrity or noise	Re-solder CMD/CLK, reduce clock speed, tidy grounding
Chip died after power-up	Over-voltage on VCCQ or VCC/VCCQ swapped	Nothing recoverable via ISP; verify rails on a donor next time
Pad lifted while soldering	Too much heat/force	Micro-jumper to the next via if you can trace it; otherwise escalate to chip-off
Userdata is pure noise	FBE/FDE encryption (expected)	Not a fault — see limitations; do not "repair" or write

Additional guidance: always image before touching anything writable; keep two verified copies; and if joints keep failing, use thicker anchor points and better strain relief rather than more heat.

Legal and consent note

Perform ISP recovery only on devices you own or for which you have explicit, documented authorisation from the owner. Reading another person's stored data without consent may violate computer-misuse, wiretap, privacy and data-protection laws (e.g. CFAA, UK CMA, GDPR) — and forensic examiners must additionally respect chain-of-custody and applicable warrants. Do not use these methods to defeat anti-theft protections (FRP, activation locks) on devices that are not yours. When in doubt, get written authorisation and, for casework, legal sign-off before you power 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.