Reverse Engineering Android’s Boot Process: Tracing dm-verity Verification from Init

Introduction

Android’s security architecture relies heavily on a chain of trust, ensuring that every loaded component, from the bootloader to the system partitions, is verified before execution. A cornerstone of this architecture is dm-verity, a device-mapper target that provides integrity checking for block devices. This mechanism is crucial for preventing persistent rootkits and unauthorized modifications to critical system components. This article delves into the intricate process of how dm-verity is initialized and enforced during the Android boot sequence, specifically tracing its activation from the venerable init process.

Understanding dm-verity‘s role from the perspective of init offers profound insights into Android’s system hardening strategies, particularly for system integrators, security researchers, and advanced Android developers. We will explore the configuration files, the kernel’s interaction, and practical ways to observe this critical security feature in action.

Understanding the Android Boot Process

The Android boot process is a multi-stage journey, each stage verifying the integrity of the next. It begins with the Hardware Boot ROM, which loads the primary bootloader, followed by secondary bootloaders. These bootloaders verify and load the kernel and the initial ramdisk (initrd). Once the kernel starts, it’s handed off to the init process, the very first user-space process (PID 1).

Bootloader Stages: Verify and load the kernel and ramdisk. Android Verified Boot (AVB) plays a key role here, verifying boot partitions and passing verification state to the kernel.
Kernel Startup: Initializes hardware, loads modules, and ultimately executes /init from the ramdisk.
Init Process: This is where our focus lies. init parses configuration files, mounts filesystems, starts services, and generally sets up the user-space environment. It’s during this phase that dm-verity is typically configured for system partitions.
Zygote & System Server: Subsequent stages that launch Android framework services and applications.

dm-verity: Ensuring System Integrity

dm-verity operates by maintaining a cryptographic hash tree for a block device. Each data block has a corresponding hash, which is itself part of a larger hash tree, culminating in a single root hash. This root hash is signed and typically stored within Android Verified Boot (AVB) metadata. During device startup, the bootloader verifies the root hash, and init then uses this trusted root hash to configure dm-verity.

When a block on a verity-protected partition is read, the kernel’s dm-verity module calculates its hash on-the-fly and compares it against the expected hash in the hash tree. If a mismatch occurs, it signifies tampering, and the kernel will prevent access to the corrupted data, often leading to a boot failure or immediate reboot, depending on the configured error behavior (e.g., restart, panic, ignore).

Tracing dm-verity Verification in init

The init process orchestrates the creation of dm-verity devices. This primarily happens through its interaction with the fs_mgr library, which parses the device’s fstab (filesystem table) entries.

Phase 1: fstab and init.rc Configuration

init reads configuration files like /init.rc and other .rc scripts, which often include instructions to mount filesystems. Critically, it also parses fstab files, typically located at /vendor/etc/fstab.{ro.hardware} or similar paths. These fstab entries specify how partitions should be mounted, including dm-verity specific options.

A typical fstab entry for a system partition with dm-verity might look like this:

/dev/block/by-name/system  /system  ext4  ro,barrier=1,wait,verify  wait,avb=system

/dev/block/by-name/system: The underlying block device for the system partition.
/system: The mount point.
ext4: Filesystem type.
ro,barrier=1,wait,verify: Standard mount options. The verify flag is crucial here; it tells fs_mgr to set up a dm-verity device before mounting the partition.
wait,avb=system: The avb=system option instructs fs_mgr to retrieve dm-verity metadata (like the hash tree root and size) from the AVB footer of the ‘system’ partition.

Phase 2: fs_mgr and Device Mapper Interaction

When init encounters an fstab entry with the verify option, the fs_mgr library takes over:

fs_mgr reads the AVB metadata for the specified partition. This metadata contains the root hash, the hash tree structure, and the partition size.
It then uses this information to construct a dm-verity device-mapper table. This table defines a virtual block device that sits on top of the physical partition.
The kernel’s device-mapper subsystem is instructed to create this virtual device (e.g., /dev/dm-0). Reads from /dev/dm-0 are transparently verified against the hash tree.

Conceptually, the dmsetup table command would reveal something like this for a verity-protected system partition:

0 <partition_size_in_blocks> verity 1 <physical_device> <physical_device_hash_tree> <data_block_size> <hash_block_size> <num_data_blocks> <num_hash_blocks> <hash_start_block> <alg_type> <root_hash> <salt>

Phase 3: Mounting the Verified Partition

Once the dm-verity virtual device (e.g., /dev/dm-0) is successfully created by the kernel, init proceeds to mount *this virtual device* to the target mount point (e.g., /system). From this point onward, any read or write operation attempted on /system (or other verity-protected partitions like /vendor, /product) will be transparently intercepted and verified by the kernel’s dm-verity module.

Phase 4: Error Handling and Consequences

If dm-verity detects any tampering during an I/O operation, the kernel will return an I/O error. Depending on the `dm-verity` configuration (e.g., in the AVB metadata), this can lead to:

I/O errors: The application or service attempting to read the tampered block will receive an error.
Remount as read-only: The affected partition might be automatically remounted as read-only.
Reboot to recovery: The device might be forced into recovery mode.
Bootloop/Panic: In severe cases, especially if critical system files are affected, the device may enter a bootloop or kernel panic.

Practical Steps for Observation and Verification

Observing dm-verity in action requires an ADB-enabled Android device. While direct tampering is difficult on locked devices, we can inspect its configuration.

Step 1: Inspect the fstab Configuration

Connect your Android device via ADB and inspect its fstab file. The exact path may vary but commonly found under /vendor/etc/.

adb shellcat /vendor/etc/fstab.qcom # Or fstab.pixel, fstab.{your_device}

Look for entries related to /system, /vendor, /product, and /odin (if applicable), specifically for the verify option.

Step 2: Monitor Logcat during Boot

Reboot your device and capture the boot logs to observe fs_mgr‘s activity:

adb logcat -c # Clear old logsadb rebootadb logcat | grep -E 'fs_mgr|verity'

You should see messages indicating fs_mgr parsing fstab, setting up verity devices, and mounting partitions. For example:

...I fs_mgr ( 70): verity: /dev/block/by-name/system as /system with AVB...I fs_mgr ( 70): Successfully loaded verity table for device /dev/block/by-name/system.I fs_mgr ( 70): dm-0 is for /system

Step 3: Examine Device Mapper Status (Post-Boot)

Once the device has booted, you can query the kernel’s device mapper for active verity devices.

adb shell dmsetup table

This command lists all active device-mapper targets. Look for entries with the verity target type:

dm-0: 0 <size> verity 1 <...verity parameters...>

You can also get more detailed information about a specific verity device:

adb shell dmsetup info /dev/dm-0

The output will confirm its status, type, and associated block device.

Step 4: Conceptual Tampering (Warning)

Directly tampering with a mounted dm-verity protected partition on a production device is challenging and often leads to an unbootable state. If you were to modify even a single byte on the /system partition (e.g., by flashing a custom image with a modified system.img that lacks proper signing or has been altered post-signing), the dm-verity check would fail during boot, usually before the system fully loads. This would typically result in:

A device entering recovery mode.
A bootloop with

Android Mobile Specs & Compare Directory

Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
Compare Devices Specs →