EMMC vs UFS vs NVMe: How Phone Storage Decides Your Recovery Options

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

When a phone lands on your bench dead, water-damaged, or locked, the single most important question is often "what kind of storage is inside it?" The answer — eMMC, UFS, or NVMe — decides which physical read methods are even possible, how you have to solder, and, crucially, whether the raw bits you pull off the chip will be readable plaintext or an encrypted brick. This article explains the three storage families in plain language, how each one changes your recovery workflow, and why in 2026 the storage type is usually a smaller obstacle than the encryption sitting on top of it.

The short answer

eMMC — older/budget Android and IoT devices. Simplest to work with. Well-supported by ISP, JTAG, and chip-off. If the userdata is unencrypted (older Android, some feature phones, dashcams, some tablets), a clean chip read can give you real files.
UFS — the standard for modern Android flagships and mid-range phones. Faster, serial (not parallel like eMMC), and physically harder: chip-off and reading require UFS-capable programmers, and ISP on UFS is newer and less universal than on eMMC. Almost always encrypted.
NVMe — used by Apple (iPhones/iPads) with a custom Apple NAND + controller, and by a handful of Android devices. On iPhones the storage is tightly bound to the Secure Enclave; a raw chip read is essentially useless without the device's key hierarchy.

Bottom line: storage type tells you how to get the bits. Encryption tells you whether the bits are worth anything. On any reasonably modern phone, defeating the storage is the easy part; the keys are the wall.

Background

Phone flash memory is not a removable card. It is a BGA (Ball Grid Array) package soldered directly to the logic board, and it bundles raw NAND flash together with a controller in one package.

eMMC (embedded MultiMediaCard) wraps NAND + a simple controller speaking the MMC/SD command set over a parallel bus. It is old, cheap, slow, and extremely well understood by the repair and forensic community. It typically comes in BGA-153/169/162 packages.
UFS (Universal Flash Storage) replaced eMMC on serious devices. It uses a high-speed serial link (M-PHY / UniPro), full-duplex operation, and command queuing — much faster, but a completely different electrical and protocol animal. Data is organized into LUNs (logical units), including separate boot LUNs. Common packages are BGA-153 and BGA-254.
NVMe (Non-Volatile Memory Express) is a protocol designed for SSDs over PCIe. Apple adopted a custom NVMe implementation for iPhone storage years ago, pairing raw NAND with an Apple controller. A few Android devices have shipped NVMe as well.

Running on top of all three is encryption, and this is the part that has changed the recovery world more than any storage transition:

Android moved from whole-disk FDE (Full-Disk Encryption) to FBE (File-Based Encryption). FBE has been mandatory on devices launching with Android 10 and later. Keys are derived from the user credential and a hardware secret held in the TEE (Keymaster/KeyMint) or a dedicated secure element (StrongBox, Titan M, Samsung eSE with Weaver).
iOS encrypts everything, with per-file class keys wrapped by keys fused into the SEP and the device UID. The distinction between BFU (Before First Unlock) and AFU (After First Unlock) governs which keys are even present in memory.

How it works

There are five hardware/logical read paths. Which are available depends on the storage type and the state of the board.

Method	What it is	eMMC	UFS	NVMe (Apple)
EDL / Firehose (Qualcomm), BROM (MediaTek)	Boot the SoC into a factory download mode and push a signed loader that can read partitions over USB	Common	Common	N/A (Apple SoC)
ISP (In-System Programming)	Solder directly to storage test pads and talk to the chip in place, board powered	Mature, well-mapped	Supported but newer; needs UFS-capable box/adapter	Rare/impractical
JTAG	Use the CPU's debug interface to read memory	Where TAP exposed	Largely superseded by ISP/EDL	N/A
Chip-Off	Desolder the BGA package and read it in a dedicated programmer	Standard	Needs UFS reader; harder	Possible but keys still missing
Software / agent	ADB backup, MTP, vendor tools, forensic agents	Depends	Depends	Depends (iTunes/AFC, checkm8-era tooling on old models)

The workflow logic goes roughly like this:

Does it power/boot at all? If yes, prefer the least invasive path — software extraction, then EDL/BROM, then ISP. Desoldering a working board is a last resort.
Identify the storage. Read the package markings, check a boardview/service schematic, or identify via the SoC. This tells you whether your eMMC box is enough or you need a UFS-capable programmer (UFI, EasyJTAG Plus, Medusa, NuProg-E, etc.).
Get the bits. ISP or chip-off for a physically dead board; EDL Firehose / MediaTek BROM if the SoC still responds. On Qualcomm, a signed Firehose programmer can read arbitrary partitions, including the encrypted userdata image.
Now deal with encryption. This is the step that decides success. A raw UFS/NVMe image of a modern phone is ciphertext until the key hierarchy is reconstructed — which usually requires the SoC/SEP/TEE to still function and, in most cases, the user passcode.

That last point is why chip transplantation and chip-off so often disappoint on modern devices: the NAND holds ciphertext, but the keys live in silicon (SEP UID, TEE-held Keymaster keys, Titan M / eSE secrets) that you did not remove and cannot read out. Published research on Samsung chip-transplantation confirms that moving the flash — or even the eSE — to another board runs straight into hardware-bound key material and Weaver rate-limiting.

What this means in practice

eMMC device, no encryption (old Android <6, feature phones, many non-phone gadgets): best case. ISP or chip-off, mount the image, carve files. This is where hardware recovery still routinely returns actual user data.
UFS device, FBE (typical modern Android): you can very likely get an image via EDL/BROM/ISP/chip-off, but it is encrypted. To read it you generally need the device alive enough for the TEE to unwrap keys, plus the credential. A dead board with a healthy chip but a dead SoC frequently means unrecoverable user data, even though you "read the chip."
iPhone (NVMe + SEP): chip-off is almost never the answer. Practical extraction depends on the OS/hardware state:
- BFU — most class keys are still locked in the SEP; only a small amount of data is accessible.
- AFU — the device has been unlocked once since boot, so class keys are live in memory; far more is reachable. This is why keeping a seized/received device powered and unlocked-since-boot matters so much, and why forensic vendors sell anti-reboot "preservation" hardware.
Vendor forensic tools (Cellebrite, GrayKey/Magnet, MSAB) exploit SoC/bootrom/SEP vulnerabilities and passcode brute-force where feasible. Their capability is a moving target tied to exact model + OS patch level, and Apple's iOS inactivity-reboot (which forces devices back to BFU) has been actively eroding AFU windows.

What is and isn't recoverable

Often recoverable:

Unencrypted eMMC/UFS storage (older or non-phone devices) — via ISP or chip-off.
Logical deletions and filesystem corruption when you can already decrypt (device boots, passcode known) — normal file carving applies to the decrypted volume.
AFU iOS data on models with a working extraction path, while keys remain in memory.
Partition/firmware-level data (bootloaders, some system partitions) that isn't user-encrypted.

Usually NOT recoverable by hardware alone:

User data from a modern encrypted phone when the SoC/SEP/TEE is dead. The NAND is intact ciphertext; the keys are gone with the silicon. Chip-off gives you an encrypted blob, not files.
BFU iOS user data beyond the small "always available" set, without a working exploit for that exact model/OS.
Anything gated by a strong, unknown passcode on a device with a functioning secure element enforcing rate limits (Weaver / SEP throttling defeats brute force).

Permanently unrecoverable:

Data protected by a hardware key that was destroyed or wiped (secure element key erased on remote wipe / effaceable storage key destroyed). Once the wrapping key is gone, the ciphertext is mathematically dead.
Physically shattered NAND dies with lost pages beyond ECC recovery.

Ethics / scope: This article is about recovering data for the lawful owner of a device. Do not use these techniques to defeat activation locks, FRP, or theft-deterrent locks on devices you don't own. Note that FRP/activation-lock removal is a separate problem from data recovery — bypassing an account lock does not decrypt user data, and decrypting user data does not require defeating anti-theft locks.

Common misconceptions

"If I can read the chip, I can read the data." False on any encrypted device. Reading NAND ≠ reading plaintext. The keys are not on the chip you removed.
"Chip-off is the most powerful method, so try it first." On modern phones it's often the weakest outcome for user data and the most destructive to the board — it can strand you with an encrypted image and no live SoC to decrypt it. Prefer methods that keep the key-holding silicon alive.
"UFS can't be done in-system, only chip-off." Outdated. ISP historically targeted eMMC/eMCP, but UFS ISP adapters and UFS-capable programmers now exist and are improving — support is model-dependent, so verify against your tool's compatibility list.
"Removing the flash and transplanting it to a donor board recovers everything." Hardware-bound keys (SEP UID, TEE/Keymaster, Titan M, Samsung eSE + Weaver) defeat naïve transplantation; you didn't move the keys.
"iPhones use UFS like Android." Apple uses a custom NVMe stack, not UFS, and its encryption is bound to the SEP.
"A known passcode always saves you." Only if the secure hardware that unwraps the keys still functions. Dead SEP/TEE = no unwrap, even with the correct passcode.

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.