Introduction

In the realm of digital forensics and data recovery, extracting data from Android devices often presents significant challenges. While logical extractions via ADB or MTP are common, physical data extraction, particularly a chip-off from the eMMC (embedded MultiMediaCard) flash memory, becomes a critical last resort for heavily damaged or locked devices. However, obtaining a raw eMMC dump is only the first step. The true challenge lies in reconstructing the Android file system from this undifferentiated blob of binary data to access meaningful information. This expert-level guide details the process of analyzing a raw eMMC dump, identifying partition tables, extracting individual partitions, and mounting them for forensic analysis.

Understanding eMMC Storage and Android Partitions

eMMC is the standard flash storage solution for most Android devices, integrating both the flash memory and a flash memory controller on a single chip. It behaves much like a hard drive, providing a block-based interface to the Android operating system. Android devices typically employ a complex partitioning scheme, which varies between manufacturers and OS versions. Common partitions include:

• boot: Contains the kernel and ramdisk necessary to boot the device.
• system: The core Android operating system, including the framework, services, and system applications. (Typically ext4)
• vendor: Vendor-specific binaries and libraries (separated from system in newer Android versions). (Typically ext4)
• userdata: User-specific data, including photos, videos, contacts, app data, and settings. This is often the primary target for forensic investigations. (Typically ext4 or f2fs)
• cache: Stores frequently accessed data to speed up system operations. (Typically ext4)
• recovery: An alternative bootable partition used for system updates or factory resets.
• misc: A small partition used for various purposes, often storing boot-time flags.

Newer Android versions (e.g., Android 10+) also introduce ‘super’ partitions, which virtualize underlying physical partitions, adding another layer of complexity. However, the fundamental block-level access remains.

The Chip-Off Extraction Process (Brief Overview)

Before reconstruction, a raw eMMC dump must be acquired. This involves:

1. Device Disassembly: Carefully opening the Android device.
2. eMMC Chip Desoldering: Using a BGA rework station to safely remove the eMMC chip from the PCB.
3. Data Acquisition: Placing the desoldered eMMC chip into a specialized eMMC reader (e.g., Z3X EasyJTAG, Riff Box 2, Medusa Pro) connected to a computer. The reader then allows for a bit-for-bit raw dump of the entire memory contents, usually as a large binary file (e.g., emmc_dump.bin).

This raw dump is essentially a copy of the entire physical eMMC storage, without any file system or partition information readily accessible by standard operating systems.

Initial Analysis of the Raw eMMC Dump

Once you have the raw dump file, the first step is to perform a preliminary analysis to understand its nature. The file command is a good starting point, though it often reports raw dumps simply as ‘data’.

file emmc_dump.bin

Expected output:

emmc_dump.bin: data

Next, we can look for common strings or magic bytes that might indicate the presence of partition tables or known file system headers. Both MBR (Master Boot Record) and GPT (GUID Partition Table) are common in Android devices, with GPT being more prevalent in modern systems.

To check for MBR (signature 0x55AA at offset 0x1FE) or GPT (signature EFI PART at offset 0x200 or LBA 1), you can use hexdump:

hexdump -C emmc_dump.bin | head -n 10

Look for patterns. If you see EFI PART, it’s likely GPT. If you see the MBR boot signature 0x55AA at the end of the first 512-byte sector, it’s MBR (or a hybrid MBR/GPT setup).

Locating and Parsing Partition Tables

This is the most critical phase. Identifying the partition table allows us to carve out individual partitions.

GUID Partition Table (GPT)

Most modern Android devices use GPT. The GPT header is usually located at Logical Block Address (LBA) 1, which is offset 0x200 (512 bytes) from the start of the disk image, assuming a 512-byte sector size. The gdisk utility (GPT fdisk) is invaluable for this purpose.

sudo gdisk emmc_dump.bin

Upon running gdisk, it will attempt to read the partition table. If successful, you’ll enter an interactive prompt. Type p to print the partition table:

GPT fdisk (gdisk) version 1.0.9Partition table scan:  MBR: MBR only  BSD: not present  APM: not present  GPT: presentFound valid GPT with protective MBR; using GPT.Command (? for help): pDisk emmc_dump.bin: 30000000 sectors, 14.3 GiBLogical sector size: 512 bytesDisk identifier (GUID): 1234ABCD-5678-90EF-1234-567890ABCDEFPartition table holds up to 128 entriesMain partition table begins at LBA 2 and ends at LBA 33First usable LBA is 34, last usable LBA is 29999966Partitions:Number  Start (LBA)    End (LBA)  Size        Code  Name   1           34         208577   101.8 MiB   0700  modem   2       208578         209601   512.0 KiB   0700  sbl1   3       209602         211649   1.0 MiB     0700  rpm   4       211650         212673   512.0 KiB   0700  tz   5       212674         212797   62.0 KiB    0700  hyp   6       212798         213821   512.0 KiB   0700  pmic   ...   15     10000000     29999966   9.5 GiB     0700  userdata

From this output, note the Start (LBA) and End (LBA) for each partition. These represent the starting and ending sectors. You can quit gdisk by typing q.

Alternatively, the sgdisk utility (part of gdisk package) can non-interactively print the partition table:

sudo sgdisk -p emmc_dump.bin

Master Boot Record (MBR)

Older Android devices or specific firmware might still use MBR. You can use fdisk to list MBR partitions, though it might issue warnings about the raw image:

sudo fdisk -l emmc_dump.bin

Or, for more robust MBR analysis and recovery, especially if the MBR is corrupted, testdisk is a powerful option:

sudo testdisk emmc_dump.bin

Follow the interactive prompts to analyze and list partitions.

Extracting Individual Partitions

Once you have the start sector and size (or end sector) of the desired partition (e.g., userdata), you can use the dd command to carve it out from the raw eMMC dump.

First, calculate the number of sectors for the partition:

Number of Sectors = End (LBA) - Start (LBA) + 1

For example, if userdata starts at LBA 10000000 and ends at LBA 29999966 (from the gdisk output above):

Start_LBA = 10000000End_LBA   = 29999966Count_Sectors = 29999966 - 10000000 + 1 = 19999967 sectors

Now, use dd to extract the partition. We use bs=512 as the logical sector size is 512 bytes.

sudo dd if=emmc_dump.bin of=userdata.img bs=512 skip=10000000 count=19999967 status=progress

• if=emmc_dump.bin: Input file (your raw dump).
• of=userdata.img: Output file for the extracted partition.
• bs=512: Block size (matching sector size).
• skip=10000000: Skip the first 10,000,000 sectors from the input file.
• count=19999967: Read only 19,999,967 sectors.
• status=progress: (Optional) Shows progress during the transfer.

Repeat this process for other partitions of interest like system.img or boot.img.

Mounting and Analyzing File Systems

After extracting a partition, you can attempt to mount it to access its contents. Most Android user data partitions use ext4, while some might use f2fs. Boot and recovery partitions often contain a minimal ramdisk or fat32 partitions.

Before mounting, it’s good practice to check the file system type:

file userdata.img

If it reports Linux rev 1.0 ext4 filesystem data, you can proceed to mount it:

sudo mkdir /mnt/android_userdatasudo mount -o loop userdata.img /mnt/android_userdata

If the mounting fails due to a corrupted file system, you might need to run a file system check first:

sudo e2fsck -f -y userdata.img

For f2fs file systems:

sudo mount -t f2fs -o loop userdata.img /mnt/android_userdata

After successful mounting, you can navigate into /mnt/android_userdata and access the files as if they were on a live device. For deep forensic analysis, consider using tools like Autopsy or FTK Imager that can ingest raw disk images and provide advanced search and recovery capabilities. If the file system is heavily corrupted and cannot be mounted, tools like foremost or scalpel can be used to carve out known file types (e.g., JPEG, PDF, SQLite databases) from the raw partition image.

sudo foremost -t jpg,pdf,sqlite -i userdata.img -o /forensic_carve_output

Conclusion

Reconstructing Android file systems from raw eMMC dumps is a meticulous but essential process in advanced digital forensics and data recovery. By systematically analyzing the raw binary data, identifying partition tables, extracting individual partitions, and appropriately mounting them, investigators can gain access to critical evidence even from severely damaged or uncooperative devices. This detailed methodology empowers professionals to navigate the complexities of eMMC storage and unlock valuable data from the deepest layers of an Android device.