Firmware and eMMC

  • Firmware: Low-level software stored and running inside a device to control the hardware.
  • eMMC(embedded MultiMediaCard): NAND Embedded storage device that combines Flash and Flash Controller in one package
  • In a typical embedded device, firmware is stored in a non-volatile storage device such as eMMC, and when the power is turned on, the SoC reads and executes the bootloader, kernel, and root file system from the storage device.
    • In other words, firmware is software that defines how the device will operate, and eMMC can be seen as a physical storage medium that stores the firmware.
  • In systems such as routers, smartphones, IoT devices, and embedded Linux devices, understanding firmware and eMMC structure is very important for reversing, forensics, and vulnerability analysis.

Firmware

Firmware is software that controls the operation of a device between the hardware and the operating system.

General software runs on top of the operating system, but firmware is usually stored on a non-volatile storage device such as Flash, eMMC, or SPI Flash inside the device and is executed first when the device boots.

Firmware performs roles such as hardware initialization, booting, device control, operating system loading, and settings management.

For example, when you turn on the router, CPU does not immediately run the Linux kernel, but Boot ROM or boot loader is executed first, and then the kernel and root file system are loaded.

The bootloader, kernel, file system, and configuration data used in this process can be broadly referred to as firmware.

Firmware Components

Firmware may appear to be a single file, but internally it is often divided into multiple components.

A typical embedded Linux firmware includes the following components:

  • Bootloader
  • Kernel
  • Device Tree
  • Root Filesystem
  • config file
  • application binary
  • driver or kernel module
  • recovery image
  • Update metadata

For example, if there is a firmware image, the internal structure may appear roughly as follows.

firmware.bin
    - header
    - bootloader
    - kernel
    - device tree blob
    - rootfs
    - config
    - checksum
    - signature

When analyzing firmware, you must check whether the file is a simple binary, an image with several regions attached, or contains a compressed file system.

Bootloader

Bootloader is a program that runs first before executing the operating system kernel.

When the device is turned on, CPU executes Boot ROM according to the designated boot path, and Boot ROM reads the next stage bootloader from storage devices such as eMMC, SPI Flash, and NAND Flash.

Bootloader usually performs the following roles:

  • Reset CPU
  • Reset DRAM
  • Reset storage device
  • Load kernel image
  • Load Device Tree
  • Passing kernel boot arguments
  • Enter recovery mode
  • Firmware update processing

U-Boot is widely used in embedded Linux equipment.

U-Boot loads the kernel into memory, passes the necessary booting arguments to the kernel, and then jumps to the kernel execution address.

The approximate boot flow can be seen as follows.

Power On
    -> Boot ROM
    -> Bootloader
    -> Kernel
    -> Root Filesystem
    -> Init Process
    -> User Application

In other words, the bootloader plays a role in connecting the initial execution flow between the hardware and the operating system.

Kernel

Kernel is a core part of the operating system.

The kernel included in the firmware manages CPU, memory, file system, network, processes, device drivers, etc.

Linux Kernel is often used in embedded equipment.

The kernel does not operate independently and must know the hardware information of the device.

At this time, Device Tree is used together.

Device Tree

Device Tree is a data structure that informs the kernel of the hardware configuration of an embedded system.

When the kernel runs, it needs to know which devices are connected to which addresses, which interrupts to use, and which drivers to match.

If this information is embedded directly in the code, the kernel must be modified separately for each board, so hardware information is managed separately through Device Tree.

Device Tree is usually created from a DTS file, and when compiled, it takes the form DTB.

.dts -> .dtb

It is usually included in firmware in the form of dtb or device tree blob.

From a reversing perspective, you can see what hardware is connected to the device by looking at the Device Tree.

For example, you can check information such as UART, GPIO, I2C, SPI, eMMC, Ethernet, and Wi-Fi chips.

Root Filesystem

Root Filesystem is a file system based on / in Linux systems.

Firmware includes not only the kernel, but also files that run in actual user space.

The following directories exist in a typical Root Filesystem.

/bin
/sbin
/etc
/lib
/usr
/var
/www
/tmp

Root Filesystem is very important in firmware analysis.

This is because web server files, configuration files, default accounts, init scripts, executable binaries, authentication logic, and API endpoints are usually contained within the Root Filesystem.

For example, if you analyze the router firmware, you can find the administrator page source code in /www, and basic settings or service execution scripts in /etc.

Firmware Images

A firmware image is a binary file that is installed or updated on a device.

The update file provided by the manufacturer is also a firmware image, and the binary dump extracted from the device’s internal storage device can also be viewed as a firmware image.

Firmware images usually take one of the following forms:

  • Raw binary image
  • compressed image
  • Image with multiple partitions combined
  • File system image
  • encrypted image
  • signed image
  • Vendor-specific format

For example, simple firmware may have a kernel and file system attached as shown below.

[ header ][ kernel ][ rootfs ]

On more complex devices, multiple partition images may be contained within a single update file.

[ boot ][ recovery ][ system ][ vendor ][ userdata ]

In firmware analysis, you must first check the magic value, header, compression method, and file system format of the file.

Firmware Analysis

Firmware analysis is the process of analyzing the structure and operation inside the firmware image.

It usually proceeds in the following order:

  1. Obtain firmware image
  2. Check file format
  3. Compress or unpack
  4. File system extraction
  5. Configuration file analysis
  6. Executable binary analysis
  7. Understand service operation structure
  8. Vulnerability Analysis

Elements frequently checked in firmware analysis are as follows.

  • Basic account information
  • Hardcoded password
  • API Key
  • SSH Key
  • Authentication bypass logic
  • web management page
  • init script
  • network service
  • SUID binary
  • old library
  • Vulnerable CGI binary

For example, if there are paths such as /etc/passwd, /etc/shadow, /etc/init.d, /www, /bin, and /sbin inside the firmware, those files are often checked first.

Because firmware contains the actual operating logic of the device, analyzing the firmware provides a relatively clear picture of the device’s attack surface.

Firmware Updates

Firmware update is the process of replacing the firmware image inside the device with a new version.

Updates are performed for feature improvements, bug fixes, security patches, etc.

However, the firmware update process itself can be a significant security attack surface.

For example, if the device does not verify the signature of the update file, an attacker can install modified firmware.

Alternatively, if encryption is present but integrity verification is weak, the firmware can be modified, repackaged, and loaded onto the device.

A secure firmware update usually requires the following elements:

  • Signature Verification
  • Integrity Verification
  • Version Verification
  • Rollback Prevention
  • recovery partition
  • Restore processing when update fails

In particular, in devices equipped with Secure Boot, it is verified whether the codes executed during the booting phase are trustworthy.

Boot ROM verifies the first bootloader, which verifies the kernel, which verifies the next component, and so on, and so on.

This is called Chain of Trust.

eMMC

eMMC(embedded MultiMediaCard) is a non-volatile storage device widely used in embedded devices.

eMMC is a form that combines NAND Flash and Flash Controller into one package.

Since general NAND Flash only provides storage cells, an external controller or software must be responsible for processing such as bad block management, ECC, and wear leveling.

On the other hand, since eMMC contains a controller inside, this management is handled inside eMMC.

In other words, from the host’s perspective, eMMC can be used like a relatively simple block device.

Configuration of eMMC

eMMC largely consists of the following elements.

  • NAND Flash
  • Flash Controller
  • MMC Interface
  • Boot Partition
  • User Area
  • RPMB
  • General Purpose Partition

NAND Flash is an area that stores actual data, and the Flash Controller plays a role in managing NAND Flash.

The host does not directly access NAND inside eMMC, but communicates with the eMMC Controller through the MMC protocol.

The approximate structure can be seen as follows.

Host SoC
    -> MMC Controller
        -> eMMC Interface
            -> eMMC Controller
                -> NAND Flash

In other words, eMMC is not simply a NAND chip, but a package that includes a storage device controller.

eMMC and NAND Flash

When understanding eMMC, it is important to understand the difference from Raw NAND.

Raw NAND means NAND Flash itself.

If Raw NAND is used, the system must directly handle bad block management, ECC, wear leveling, address conversion, etc.

On the other hand, eMMC’s internal controller is responsible for this processing.

  • Raw NAND: The host must directly handle NAND management.
  • eMMC: The eMMC internal controller handles NAND management.

So eMMC can simplify storage device implementation in embedded systems.

However, because the internal operation is abstracted by the controller, it is difficult to directly check the exact placement of the physical NAND level or the wear leveling status from the outside.

eMMC and SD Card

eMMC is a MMC series in name, and its operation method is also similar to SD Card.

However, the purpose of use and physical form are different.

SD Card is a removable storage device, and eMMC is an embedded storage device that is usually soldered on the board.

  • SD Card: Removable storage device
  • eMMC: Embedded storage device mounted on the board

eMMC is often soldered to PCB in the form of a BGA package.

Therefore, general users cannot easily separate it, and for analysis, methods such as ISP, JTAG, and chip off can be used.

eMMC Partition

eMMC internally provides several partition areas.

Representative areas are as follows:

  • User Area
  • Boot Partition 1
  • Boot Partition 2
  • RPMB
  • General Purpose Partition

User Area is a general data storage area.

Partitions such as the operating system’s rootfs, system, vendor, and userdata are usually stored in this area.

Boot Partition is a small area that can be used to store the bootloader.

When booting, the SoC can read the initial bootloader from the boot partition of eMMC.

RPMB stands for Replay Protected Memory Block and is a protected storage area to prevent replay attacks.

RPMB can be used for secure data storage and operates on the premise of authenticated access.

For example, data related to keys, counters, security status, and integrity can be stored in RPMB.

General Purpose Partition is a general purpose partition area that can be configured separately as needed.

User Area

User Area is the most commonly used data storage area in eMMC.

In Linux, the eMMC User Area is usually recognized as a block device.

For example, it may appear in the following form:

/dev/mmcblk0

If there are multiple partitions within it, it will appear as follows.

/dev/mmcblk0p1
/dev/mmcblk0p2
/dev/mmcblk0p3

Each partition can contain file systems such as boot, rootfs, system, vendor, and userdata.

In embedded device analysis, the file system can be analyzed by dumping the entire /dev/mmcblk0 or only a specific partition.

Boot Partition

eMMC’s Boot Partition is a dedicated area used for booting.

It can usually be exposed in the following form:

/dev/mmcblk0boot0
/dev/mmcblk0boot1

The boot partition can store the initial boot loader or boot-related data.

In some systems, Boot ROM reads the boot loader from the eMMC Boot Partition, and the boot loader loads the kernel or other partitions in the User Area.

The approximate flow is as follows.

Boot ROM
    -> eMMC Boot Partition
    -> First Stage Bootloader
    -> Second Stage Bootloader
    -> Kernel
    -> Root Filesystem

Boot Partition may have protection settings applied differently from the general User Area, and may be set to read-only.

Therefore, when analyzing equipment, you must check not only the User Area but also the Boot Partition.

RPMB

RPMB(Replay Protected Memory Block) is a secure storage area inside eMMC.

RPMB is not simply an area to store data, but has a structure that prevents replay attacks using authentication and counters.

A replay attack is an attack that returns the system state to the past by re-recording previously valid data.

For example, if a device stores security counters or lock states, an attacker could try to bypass the lock states by rewriting old dumps.

RPMB uses Write Counter and authentication mechanism to prevent such attacks.

RPMB can usually be used to store the following data:

  • security counter
  • Key related data
  • device status
  • Integrity Verification Information
  • TEE related data

From a reversing or forensics perspective, RPMB is an area that is difficult to simply dump and modify like a regular partition.

Therefore, when analyzing the entire eMMC structure, the existence and use of RPMB must be considered together.

Wear Leveling

NAND Flash has a limit on the number of writes for each block.

If writes continue to occur only in a specific block, that block may expire first.

Wear Leveling is a technique to extend the lifespan of NAND Flash by distributing write operations to multiple blocks.

In eMMC, the internal controller handles wear leveling.

From the host’s perspective, it appears as if data is being written to the same logical address, but in reality, it may be written to a different physical block inside NAND.

In other words, eMMC internally maps between logical addresses and physical addresses.

For this reason, when analyzing eMMC, the seemingly logical data arrangement and the actual internal arrangement of NAND may differ.

Bad Block Management

NAND Flash may have defective blocks during the manufacturing or use process.

When using Raw NAND, the system must directly manage bad blocks.

On the other hand, in eMMC, the internal controller performs bad block management.

When a bad block occurs, the controller does not use the block and replaces it with a spare block.

The host is not directly aware of this process and approaches it like a normal block device.

In other words, eMMC hides and abstracts the complex characteristics of NAND Flash internally.

ECC

ECC(Error Correction Code) is a technique for detecting and recovering bit errors that may occur in NAND Flash.

NAND Due to the storage characteristics of Flash, bit errors may occur as time passes or the number of uses increases.

eMMC internally uses ECC to correct these errors.

The host usually does not directly perform ECC calculation and recovery, but receives the results processed by the eMMC Controller in block units.

Thanks to this structure, eMMC is easier to handle than Raw NAND, but the internal error correction process is difficult to observe in detail from the outside.

Example eMMC Partition Layout

The eMMC partition structure of embedded Linux equipment can appear roughly as follows.

/dev/mmcblk0
    /dev/mmcblk0p1   boot
    /dev/mmcblk0p2   kernel
    /dev/mmcblk0p3   rootfs
    /dev/mmcblk0p4   config
    /dev/mmcblk0p5   userdata

/dev/mmcblk0boot0
    bootloader

/dev/mmcblk0boot1
    backup bootloader

On smartphones or Android-based devices, there may be more partitions.

boot
recovery
system
vendor
userdata
cache
misc
metadata
vbmeta
dtbo

Each partition is used for device booting, recovery, system files, user data, integrity verification, etc.

Firmware Extraction Methods

To analyze firmware, you must first obtain a firmware image.

There are several ways to obtain firmware.

  • Download the update file from the manufacturer’s website
  • Check firmware URL from mobile app or update server
  • Extract from device internal file system
  • Dump via UART Shell
  • Access memory or storage device via JTAG
  • Direct access to eMMC using ISP method
  • Dump after detaching eMMC using chip-off method

The easiest way is to download the update file provided by the manufacturer.

However, if the update file is encrypted, signed, or contains only a few partitions, an eMMC dump of the physical device may be required.

By obtaining an eMMC dump, you can check settings, logs, user data, and actual partition status that are not included in the update file.

eMMC Dump

eMMC Dump is the process of reading the contents of an eMMC storage device and saving them as an image file.

If eMMC is recognized as /dev/mmcblk0 in Linux, the entire User Area can be saved as an image.

dd if=/dev/mmcblk0 of=emmc_user.img bs=4M

Boot Partition can be exposed as a separate device file.

dd if=/dev/mmcblk0boot0 of=boot0.img bs=4M
dd if=/dev/mmcblk0boot1 of=boot1.img bs=4M

You can also dump only specific partitions.

dd if=/dev/mmcblk0p3 of=rootfs.img bs=4M

From the image obtained in this way, the partition table, file system, boot loader, kernel, configuration files, etc. can be analyzed.

Firmware File Systems

File systems frequently encountered in firmware analysis are as follows.

  • SquashFS
  • JFFS2
  • UBIFS
  • ext2
  • ext3
  • ext4
  • cramfs
  • YAFFS2

SquashFS is widely used in routers and IoT devices.

Because SquashFS is a read-only compressed file system, it is suitable for reducing firmware size and maintaining integrity.

Data that needs to be changed, such as settings, is often stored in a separate partition.

For example, rootfs is configured as read-only with SquashFS, and areas such as /overlay or /data are set as writable partitions.

rootfs      -> read-only squashfs
overlay     -> writable jffs2/ext4
userdata    -> writable ext4

Understanding this structure allows you to determine which files the device reads from the base image and which files it modifies at runtime.

Secure Boot

Secure Boot is a security technique that verifies the integrity and reliability of code executed during the booting process.

In a typical booting process, the execution flow follows the following order: Boot ROM, Bootloader, Kernel, and Root Filesystem.

When Secure Boot is applied, each step verifies the signature of the next step.

Boot ROM
    -> verify Bootloader
        -> verify Kernel
            -> verify Root Filesystem

This structure in which trust continues step by step is called Chain of Trust.

If Secure Boot is properly applied, verification may fail during the booting process even if an attacker modifies the bootloader or kernel stored in the eMMC.

However, if Secure Boot is disabled, the verification scope applies only to some areas, or there is no rollback prevention, there may be a possibility of bypass.

Verified Boot

Verified Boot is a structure that verifies the integrity of the system partition during the booting process.

On Android devices, partitions such as vbmeta, boot, system, and vendor may be included in the verification scheme.

Verified Boot not only verifies the boot loader, but also checks whether the kernel and system partition have been tampered with.

If verification fails, the device may stop booting or enter a warning state.

If Verified Boot is applied when modifying a partition stored in eMMC, normal booting may not occur if you simply modify the file system.

Therefore, when analyzing firmware or modifying a device, it is necessary to check whether protection techniques such as Secure Boot, Verified Boot, and dm-verity are applied.

Summary

Firmware is low-level software used inside a device to control the hardware and boot the operating system.

Firmware usually includes Bootloader, Kernel, Device Tree, Root Filesystem, configuration files, and application binaries.

eMMC is an embedded storage device that combines NAND Flash and Controller into one package.

eMMC processes NAND management functions such as Wear Leveling, Bad Block Management, and ECC through the internal Controller.