Introduction to Android Verified Boot 2.0

Android Verified Boot (AVB) 2.0 is a critical security feature designed to prevent malicious modifications to the operating system and device firmware. It ensures the integrity of the boot process from the hardware root of trust all the way to the loaded system. Building upon its predecessor, AVB 2.0 introduces enhanced rollback protection, a more flexible metadata format, and improved error handling, making it a formidable challenge for those attempting unauthorized system alterations or simply seeking to understand its inner workings. For custom ROM developers, security researchers, and advanced users, comprehending AVB 2.0 isn’t just academic; it’s essential for safely modifying or analyzing Android devices.

This deep dive will trace the AVB 2.0 verification process, dissecting each stage of the boot chain. We’ll explore the key components like the VBMeta image, hash trees, and cryptographic signatures, and provide practical steps for inspecting AVB configurations using standard tools. By the end, you’ll have a comprehensive understanding of how AVB 2.0 safeguards Android devices and how to approach its ‘reverse engineering’ aspects.

Understanding AVB 2.0 Core Concepts

The Hardware Root of Trust

At the foundation of AVB 2.0 lies the hardware root of trust, typically a Read-Only Memory (ROM) embedded within the device’s System-on-Chip (SoC). This immutable code is the first instruction executed upon power-on. It contains a public key or a hash of a public key, which is used to verify the authenticity of the subsequent bootloader. This initial trust anchor is paramount, as any compromise at this stage would undermine the entire verification chain.

VBMeta Image: The Central Hub

The vbmeta.img partition is the cornerstone of AVB 2.0. Unlike previous versions, AVB 2.0 centralizes all verification metadata into this single, signed image. The vbmeta.img contains:

• Cryptographic descriptors for various partitions (e.g., boot, system, vendor), including their expected hashes or a pointer to their respective hash trees.
• Chained partition descriptors, which allow other vbmeta images (e.g., within vendor_boot on some devices) to be verified and subsequently used to verify their own set of partitions.
• Rollback protection indices (anti-rollback counters) to prevent downgrading to older, potentially vulnerable software versions.
• Public keys used to verify the signatures of the descriptors.

The integrity of vbmeta.img itself is verified by the bootloader using keys embedded in the bootloader or fused into the hardware.

Hash Trees and dm-verity

For larger partitions like system and vendor, directly hashing the entire partition is inefficient. AVB 2.0 leverages hash trees (Merkle trees) in conjunction with dm-verity, a device-mapper target in the Linux kernel. Each block of a verified partition has its hash stored in a tree structure. The root hash of this tree is what’s signed and stored in vbmeta.img. During runtime, dm-verity verifies data blocks on-the-fly as they are accessed, ensuring real-time integrity without requiring the entire partition to be hashed upfront. If a block’s hash doesn’t match, dm-verity prevents access, typically leading to a device reboot or a specific error message.

Rollback Protection

AVB 2.0 implements robust rollback protection using anti-rollback counters. These counters are stored in hardware (e.g., eFuses or Replay Protected Memory Blocks – RPMB) and also within the vbmeta.img. During an update, the counters in vbmeta.img are incremented. The bootloader compares the counter in the incoming vbmeta.img with the hardware-stored counter. If the incoming counter is lower, indicating an attempt to downgrade, the boot process is halted. This prevents attackers from installing older software versions with known vulnerabilities.

Tracing the Android Boot Chain with AVB 2.0

Stage 1: Hardware Boot ROM & Primary Bootloader (PBL)

The journey begins with the SoC’s immutable Boot ROM. This ROM code initializes the basic hardware and loads the Primary Bootloader (PBL) from internal flash (eMMC/UFS). The Boot ROM verifies the PBL’s signature against its embedded public key. If verification fails, the device typically becomes inoperable (bricked) or enters a recovery mode.

Stage 2: Secondary Bootloader (SBL/ABL/LK)

Once the PBL is verified and loaded, it takes over, often referred to as the Secondary Bootloader (SBL), Android Bootloader (ABL), or Little Kernel (LK). This stage is where AVB 2.0 truly kicks in. The SBL performs the following critical steps:

1. Loads the vbmeta.img partition into memory.
2. Verifies the signature of vbmeta.img using keys embedded within the bootloader or fused into the device. If the bootloader is unlocked (e.g., via fastboot flashing unlock), it might switch to a different verification mode, potentially allowing unsigned vbmeta or issuing a warning.
3. Reads the descriptors within the verified vbmeta.img.
4. Locates and loads the boot.img (containing the kernel and ramdisk).
5. Verifies the boot.img against its hash or signature descriptor found in vbmeta.img.
6. Checks the anti-rollback counters. If the counters in vbmeta.img are lower than the hardware-stored counters, the boot process is aborted.

Upon successful verification, the SBL passes control to the kernel.

Stage 3: Kernel & dm-verity Activation

The verified kernel starts up and initializes. A crucial part of this initialization is setting up dm-verity for read-only partitions like system, vendor, and product. The kernel uses the hash tree root hashes and other parameters provided by vbmeta.img to configure dm-verity. From this point onwards, any attempt to read a tampered block from these partitions will be detected and blocked by dm-verity, ensuring the integrity of the running Android system.

Practical Reverse Engineering & Inspection

Extracting VBMeta and Partition Information

To inspect AVB 2.0, you first need access to the firmware or the device itself. If you have a full firmware package, you can often find vbmeta.img directly. If on-device, and the bootloader is unlocked, you might be able to extract it using dd via adb shell or through fastboot. Assuming you have vbmeta.img:

# On device (requires root and unlocked bootloader, replace 'mmcblk0pXX' with actual partition)adb shellsu dd if=/dev/block/by-name/vbmeta of=/sdcard/vbmeta.imgadb pull /sdcard/vbmeta.img .# From a firmware ZIP (example for Qualcomm)unzip firmware.zip -d firmware_extractcd firmware_extractmv vbmeta.img .

Inspecting VBMeta with avbtool

The Android Open Source Project (AOSP) provides a utility called avbtool, which is indispensable for working with AVB. You can typically find it in the AOSP source tree under platform/external/avb or compile it yourself. With vbmeta.img extracted, you can inspect its contents:

avbtool info_image --image vbmeta.img

The output will reveal critical information:

• **Rollback Index**: The current anti-rollback counter.
• **Public Key Hash**: The hash of the public key used to sign this vbmeta.img.
• **Hash Descriptors**: Details for partitions like boot, dtbo, etc., showing their expected hash or hash tree root and size.
• **Chained Partition Descriptors**: If the vbmeta.img relies on other vbmeta images (e.g., vbmeta_vendor.img), it will show details on how those are chained and verified.

Example partial output:

...Image size: 104448 bytesOriginal image size: 104448 bytesVBMeta data size: 104000 bytesAuthentication data size: 448 bytesHash algorithm: SHA256Signature algorithm: RSA4096Rollback Index: 1Public key: RSA4096 with exponent 65537, 4096 bitsPublic key metadata: 0 bytesAuxiliary data size: 0 bytesChained partitions:   - name: vbmeta_system     hash_algorithm: sha256     image_size: 104448     rollback_index: 1     partition_name: vbmeta_system     public_key_metadata_size: 0     public_key_offset: 0     public_key_size: 0Hash descriptors:   - hash_algorithm: sha256     image_size: 67108864     partition_name: boot     salt: 0x...     digest: 0x...   - hash_algorithm: sha256     image_size: 8388608     partition_name: dtbo     salt: 0x...     digest: 0x...

This output tells us that vbmeta.img verifies boot and dtbo directly via hash descriptors and also chains to vbmeta_system.img, which would then verify system-related partitions.

Analyzing dm-verity Descriptors

While avbtool info_image provides the root hash for `dm-verity` enabled partitions, the full `dm-verity` table includes details like the hash algorithm, salt, and block size. These are internally used by the kernel to construct the `dm-verity` device. When a custom ROM modifies system partitions, for example, the `dm-verity` root hash will change. To boot such a system, the `vbmeta.img` would need to be re-signed with the new root hashes and (crucially) with the OEM’s signing key or a custom key that the bootloader is configured to trust (usually via OEM unlocking).

Common AVB States and Customization Considerations

Locked vs. Unlocked Bootloaders

A locked bootloader strictly enforces AVB 2.0 verification using OEM-provided keys. Any modification to verified partitions will result in a boot failure, often presenting a stark red screen or a message indicating a corrupt device. When the bootloader is OEM unlocked, the device typically allows booting unsigned or custom-signed images. However, it usually displays a persistent warning (e.g., an