Dumping eMMC and NAND Flash
Smaller devices keep firmware in SPI flash, but anything running full embedded Linux usually uses eMMC or raw NAND, with gigabytes of storage. The extraction logic is the same as a flash dump: if the processor can read it, so can you. Here is how to pull an eMMC image and what changes versus SPI flash.
Why eMMC Changes the Picture
eMMC is an entire managed flash subsystem in one package, presenting itself as a standard MMC block device. That is good news for extraction: you do not need a special flash protocol, just a way to talk MMC. The image is larger and the package is usually BGA, but the principle is unchanged.
Step 1: Reach the Device
The cleanest read is in-system, wiring to the eMMC test points so Linux on a reader enumerates it. Confirm it appears as a block device:
dmesg | grep mmc0
mmc0: new HS200 MMC card at address 0001 mmcblk0: mmc0:0001 Q2J55L 14.7 GiB mmcblk0: p1 p2 p3 p4
Step 2: Read and Verify
With the device visible, dump it block by block, then read again and compare hashes so a flaky connection does not give you a corrupt image:
dd if=/dev/mmcblk0 of=emmc.bin bs=4M sha256sum emmc.bin
3760+0 records in 3760+0 records out 15762194432 bytes (16 GB) copied, 642 s, 24.5 MB/s b91d... emmc.bin
Three Ways to Read eMMC
Depending on how accessible the chip is:
After the Dump
From here it is the same firmware analysis as any other image: identify the partitions, mount or carve the filesystems, and hunt for secrets and weak services. The defense is also the same: encrypt data at rest and keep keys in a secure element, so a full eMMC dump yields ciphertext rather than secrets.
Where This Fits
eMMC and NAND extraction is the entry point to a product security assessment on Linux-class devices. That work is the kind of work we do at Berkner Tech.