Rebuilding a Corrupted Partition Table From a Raw eMMC Dump

🔒 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	Expert
Risk to data	High (write operations are irreversible)
Time estimate	2–8 hours (longer with chip-off)
Storage type	eMMC (raw NAND behind an eMMC controller)
Device state	Powered device in ISP/EDL/BROM mode, or a desoldered chip in a reader; unencrypted or key material available
Key tools	eMMC programmer/box (UFi, Easy-JTAG, Medusa), or edl/mtkclient; hex editor; TestDisk/gdisk; boardview/service docs

Recovering data from a device whose partition table has been damaged — but whose underlying flash is still readable — is one of the more forgiving jobs in physical recovery, provided the storage is not encrypted or you legitimately hold the keys. The partition table is only a small map at the front (and back) of the storage; the actual file-system data usually survives intact. This article describes how to acquire a full, byte-for-byte raw image of an eMMC device, then reconstruct or repair a corrupted GUID Partition Table (GPT) so the partitions — and the file systems inside them — can be mounted, imaged, and carved. It is written for eMMC specifically; UFS uses different low-level access but the partition-table logic is identical.

Overview

eMMC storage presents a logical block device to the host. On virtually all modern Android phones, tablets, feature phones, IoT boards and Chromebooks that block device is partitioned with GPT. GPT is deliberately redundant: it keeps a primary header + partition-entry array at the start of the disk and a backup copy at the very end. Corruption typically hits one copy (a botched flash, an interrupted `fastboot flash gpt`, a bad `dd`, bit-rot, or a controller glitch) while the other survives. Even when both copies are gone, the partitions themselves still occupy the same LBA ranges, so their contents can be carved by file-system signature.

The workflow is always the same:

Acquire a complete raw image of the eMMC user area (and, when relevant, the boot/GPP hardware partitions) without writing to the device.
Diagnose what is actually wrong with the table using a hex editor and GPT-aware tools.
Reconstruct the table from the surviving backup, from a known-good reference layout for that exact model, or by carving.
Verify by mounting/imaging the resulting partitions read-only.

The golden rule: do all analysis and rebuilding on a copy of the image, never on the live chip. The only irreversible actions are writes back to the eMMC.

Applies to

Brands / models: Any device using eMMC storage — most budget and mid-range Android phones and tablets through roughly the mid-2010s, many current entry-level phones, feature phones (KaiOS/MTK), single-board computers, Chromebooks, automotive/IoT modules. Flagships from ~2019 onward generally use UFS instead; the table logic here still applies but acquisition differs.
SoC / access path: Qualcomm (EDL / Firehose), MediaTek (BROM / Preloader), Unisoc/Spreadtrum, Rockchip, Allwinner, etc. Access method depends on the SoC, not the flash.
Storage: eMMC 4.x/5.x (JEDEC). The user data area holds the GPT; the chip also exposes Boot Area 1/2, GPP1–4 and RPMB hardware partitions selected via `EXT_CSD[179]` (PARTITION_CONFIG).
OS & encryption: Realistically usable when data is unencrypted, uses legacy FDE with a known/empty password, or where you hold the keys. Modern FBE (Android 10+) and metadata encryption (mandatory on devices launched with Android 11+) make the raw dump ciphertext — see Risk to data and Success rate and limitations.
Required device state: The eMMC controller must be alive enough to answer standard MMC read commands (ISP/EDL/BROM), or the chip must be removable for a reader/chip-off read.

Risk to data

Reading is safe; writing is not. Acquisition over ISP/EDL/BROM or in a reader is read-only if you keep it read-only. Every recovery decision that could destroy data happens when you write back.
Point of no return #1 — writing a wrong table. Flashing a reconstructed GPT that has incorrect start/end LBAs can make the controller (or a later `mkfs`/TRIM) treat live partition space as free. On eMMC with TRIM/discard enabled, blocks marked free can be physically erased by the controller and are then gone. Always keep your original raw image.
Point of no return #2 — any format/erase/re-partition on the live chip. `mmc erase`, `fastboot -w`, factory reset, or a "repartition" in a box tool destroys data irreversibly.
Encryption is a hard wall, not a corruption. If userdata is FBE/metadata-encrypted and you do not have the keys, no amount of table rebuilding recovers readable files. The class keys live in the SoC's TEE/Keymaster/StrongBox and are hardware-bound — they are not in the flash you dumped.
Chip-off is destructive to the assembly. Desoldering risks the pads/board and the chip itself; do it only when ISP/in-system access is impossible.

Before touching the write button, you must have a verified, hashed, off-device copy of the full raw image.

Tools and materials required

Acquisition hardware / software (pick per situation):
- ISP / in-system, controller alive: an eMMC service box — UFi Box, Easy-JTAG Plus, Medusa Pro, or similar — with jumper wires and a stable bench PSU. These speak the MMC protocol over CLK/CMD/DAT test points.
- Qualcomm live: bkerler/edl (or the newer edl-ng) with the correct Firehose loader for that SoC/OEM.
- MediaTek live: bkerler/mtkclient (BROM/Preloader).
- Chip removed: a socket/reader (e.g. an RT-BGA169-01 socket for 169-ball packages) on a box, or PC-3000 Flash for raw-NAND/controller-dead cases (ECC/descrambling).
Micro-soldering (ISP/chip-off): hot-air station, microscope, flux, low-temp solder, 0.1 mm enameled wire, BGA reball stencils/kit.
Analysis software: a good hex editor (HxD, 010 Editor, wxHexEditor), gdisk/sgdisk, TestDisk, losetup/kpartx (Linux), and file-system tools (`e2fsck`, `fsck.f2fs`, `mount -o ro,loop`).
Reference data: boardview / service schematic for the model (for test points), and a known-good partition layout for the exact model+firmware (an `rawprogram*.xml`/`partition.xml`, a `gpt_main.bin`, or a healthy donor's `sgdisk --backup`).
A separate destination drive with capacity ≥ the eMMC, for the image and all working copies.

Prerequisites and safety

Confirm you are authorized to access this device's data (see Legal and consent note).
Work on ESD-safe matting; use a bench PSU with current limiting so a short trips the supply rather than cooking a track.
Identify the exact model, SoC and eMMC part number before acquisition — loaders, pinouts and reference layouts are model-specific.
Establish device state: is it encrypted, and if so is it in BFU (Before First Unlock — nothing decryptable) or AFU (After First Unlock — some keys resident in RAM, which does not help a powered-off flash dump)? For a cold flash dump you must assume BFU-equivalent: only ciphertext is present.
Verify the target's true LBA size (`EXT_CSD` sector count) so you know where the backup GPT should live.
Have a documented plan and keep a log; forensic defensibility and your own sanity both depend on it.

Step-by-step procedure

Identify and document. Record model, SoC, eMMC vendor/part, and reported capacity. Look up the correct access path (EDL / BROM / ISP) and, if going ISP, locate the CLK, CMD, DAT0 (DAT0–DAT7 if the box needs them), VCC, VCCQ and GND test points. Test-point locations vary by model — verify them against the boardview/service docs; never guess coordinates. The pads are usually near the eMMC BGA under the RF/CPU shield.
Prepare a write-safe acquisition. Whatever path you use, treat this as read-only. Do not let any tool "auto-repair", "fix GPT", or "format".
Acquire the full raw image.
- Qualcomm/EDL (controller alive): enter EDL (USB PID 9008 via edl cable/test point), then dump everything, e.g.:
  edl --loader=<firehose_for_this_soc>.elf rl BACKUPS --genxml
  or a raw whole-device read edl rl dumps --genxml. The `--genxml` output records the layout the device thought it had — invaluable for rebuilding.
- MediaTek/BROM: enter BROM (often Vol± + insert cable), then a full flash read:
  python mtk rf flash.bin
  and, if needed, hardware partitions: python mtk r preloader preloader.bin --parttype=boot1.
- ISP box (UFi/Easy-JTAG/Medusa): solder jumpers to CLK/CMD/DAT0/VCC/VCCQ/GND per the tool's pinout, check for shorts with a multimeter, power the board (or let the box power the chip), scan the eMMC, then Read full user area to a `.bin`. Also read Boot1/Boot2/GPP if the layout uses them.
- Chip-off / reader: desolder, clean, reball, seat in the socket, read the full user area. If the controller is dead, drop to raw-NAND reading (PC-3000 Flash) with the correct ECC/XOR — a different, harder workflow.
Hash and duplicate. Compute a hash (e.g. `sha256sum flash.bin`) and copy the image to your working drive. From here on, operate only on copies.
Diagnose the damage. Run gdisk -l flash.bin or sgdisk --verify flash.bin and open the image in a hex editor:
- LBA 0 should hold a Protective MBR (type `0xEE` spanning the disk).
- LBA 1 should begin with the ASCII signature EFI PART (primary GPT header). The header stores CRC32s of itself and of the partition array, the current/backup header LBAs, and the partition-array start (usually LBA 2).
- The primary partition entry array normally occupies LBA 2–33 (128 entries × 128 bytes = 16 384 bytes = 32 sectors at 512 B).
- The backup header lives in the last LBA of the device and the backup array in the 32 sectors before it (the last 33 sectors total). Note whether primary, backup, or both are damaged.
Choose a rebuild strategy:
- (a) One copy survives — the easy case. If the backup is intact but the primary is trashed (or vice-versa), rebuild the damaged copy from the good one. In gdisk's recovery/transformation menu (`r`): use "load backup partition table into memory" / "rebuild main GPT from backup" (or the reverse), verify (`v`), then write. `sgdisk` equivalents exist (e.g. rebuild main header from backup). This is the highest-success path and is what GPT redundancy is designed for.
- (b) Both copies gone, but layout is known. Recreate the table from the model's reference layout — the EDL/mtkclient `--genxml`/`rawprogram.xml`, an OEM `gpt_main.bin`, or a donor's `sgdisk --backup`. Recreate each partition at its exact start/end LBA with the correct name and type GUID using `sgdisk`. Matching the original start LBAs exactly is essential — an off-by-a-few table will corrupt every file system.
- (c) No layout available — carve. Run TestDisk against the image (it reads raw/dd images directly): let it deep-scan for file-system signatures (ext4/f2fs superblocks, FAT/exFAT boot sectors) and reconstruct partition boundaries from what it finds, then write a fresh GPT. Cross-check discovered starts against known eMMC alignment (partitions are typically 4 KiB/erase-block aligned).
Apply — first to the copy, only later to the chip. Write the rebuilt table into your image copy first and prove it mounts (next section). Only if a client needs the device itself booting/working do you write the corrected GPT back — and only after confirming TRIM won't erase live blocks and that your original image is safely archived. On EDL that is edl w gpt_both0.bin-style writes with a correct table; on a box, "Write GPT / Restore partition table". Double-check you are targeting the user area, not a boot/GPP partition.

Verifying the result

Re-verify the table: sgdisk --verify flash.bin should report no problems; gdisk -l should list every expected partition with sane sizes.
Expose the partitions from the image (Linux): losetup -f -P --read-only flash.bin (or `kpartx -a -r`), giving `/dev/loopXpN` for each partition.
'Mount read-only and check file systems: `mount -o ro /dev/loopXpN /mnt/...`; run `e2fsck -n` / `fsck.f2fs` in check-only mode. Successful mounts of userdata/system/cache with expected directory trees confirm the boundaries are right.
If a partition is encrypted it will fail to mount and look like high-entropy noise even with a perfect table — that is expected, not a table error.
Image the good partitions individually (`dd`/`ddrescue` from the loop devices) for downstream carving, then hand off/report.

Success rate and limitations

What rebuilds well: On unencrypted eMMC, GPT repair from a surviving backup (case a) succeeds the large majority of the time — the data was never touched. Even full carving (case c) commonly recovers FAT/exFAT internal storage, ext4 system partitions, and media.

What is NOT recoverable by this technique:

FBE-encrypted user files (Android 10+). Each file's contents/names are encrypted with class keys derived from a hardware-bound key in the TEE and the user's credential. A cold flash dump yields ciphertext; rebuilding the table does not decrypt it.
Metadata-encrypted volumes (mandatory on devices launched with Android 11+). The whole userdata file system is wrapped with a key (`dm-default-key`) whose protector lives in the /metadata partition and is sealed to Keymaster/StrongBox. If the metadata partition is wiped or its key blob is lost, userdata is cryptographically gone — no table trick recovers it. This is a genuine, permanent loss, not a bug in your process.
Legacy FDE is only recoverable if you have the credential (or it's the default-encrypted "empty password" case) and the footer/keys are intact.
FRP / anti-theft is orthogonal to data. Reconstructing a partition table neither removes nor is needed to remove Factory Reset Protection, and this article does not cover bypassing anti-theft on devices you don't own. FRP being present tells you nothing about whether the data is encrypted.
Chip-level failures: if the eMMC controller is dead and raw-NAND ECC/descrambling can't be resolved, or NAND cells have physically failed, the dump itself is incomplete — table rebuilding can't restore missing bytes.
TRIM already fired: if free blocks were discarded before you imaged, that data may already be zeroed by the controller.

Be honest with clients: a clean table on encrypted userdata means "the map is fixed but the treasure is still locked."

Common pitfalls and troubleshooting

Writing before you have a verified image. The single most common catastrophic mistake. Hash and archive first.
Wrong sector size / capacity. If your tool assumes 512 B but the layout math is off, the "last LBA" you compute for the backup header will be wrong. Confirm the true sector count from EXT_CSD.
Repairing the live chip instead of the copy. Let a box tool "auto-fix GPT" on the device and you may overwrite the one good copy. Always work the image.
Off-by-N partition starts. In carve/known-layout rebuilds, mis-aligned starts make file systems fail `fsck` or mount as garbage. Re-check against alignment and reference XML.
Confusing hardware partitions with GPT partitions. eMMC Boot1/Boot2/GPP/RPMB are selected via EXT_CSD PARTITION_CONFIG and are not in the GPT. Don't try to "add" them to the table; read them separately if needed. RPMB is authenticated and not freely readable.
Interpreting encryption as corruption. High-entropy userdata that won't mount is usually encryption, not a broken table. Verify by checking whether other partitions (system, vendor) mount cleanly.
ISP contact problems. Intermittent reads, wrong capacity, or CRC errors usually mean cold solder joints, a missing VCCQ, insufficient current, or a still-running SoC fighting the box — isolate/hold the CPU in reset per the tool's guidance, and re-check joints under the scope.
Loader/PID mismatch (EDL/BROM). Wrong Firehose loader or missing VCOM drivers = no read. Match the loader to the exact SoC/OEM.

Legal and consent note

Only image and modify storage on devices you own or are explicitly authorized to service, with documented consent from the data owner. Data-recovery and forensic work is subject to computer-misuse, privacy and data-protection law; unauthorized access to someone else's device data is illegal in most jurisdictions. This procedure is intended for legitimate recovery, repair and lawful forensic contexts. It does not cover — and PhoneRepair.biz does not endorse — defeating anti-theft protections (FRP, Activation Lock) or accessing data on devices that are not yours. When in doubt, get written authorization and, for legal/forensic matters, preserve chain of custody and hashes.

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.