Introduction to Android Verified Boot (AVB)

Android’s security model is built on layers, with the foundation being the integrity of the operating system itself. At the heart of this foundation lies Android Verified Boot (AVB), a critical security feature designed to prevent malicious code from being executed during the device startup process. AVB establishes a cryptographically verifiable chain of trust from a hardware root of trust, through the bootloader, to the kernel, and ultimately to the system partitions. This intricate chain ensures that every stage of the boot process is verified before execution, safeguarding against unauthorized modifications and ensuring the device boots into a known, secure state.

Without AVB, an attacker could potentially modify the boot image (kernel, ramdisk) or system partitions to inject persistent malware, elevate privileges, or bypass security features before the Android OS even fully loads. This article delves into the mechanisms of AVB, explores common techniques used to attempt to bypass its protections, and details Android’s sophisticated defense mechanisms.

The Android Verified Boot Chain of Trust Explained

The concept of a ‘chain of trust’ is fundamental to AVB. It ensures that each loaded component is cryptographically verified by the previously loaded component, starting from an immutable hardware root of trust.

Hardware Root of Trust

The journey begins with the hardware Root of Trust (RoT), typically a set of cryptographic keys fused into the device’s System-on-Chip (SoC) during manufacturing. This RoT is immutable and cannot be tampered with. It’s responsible for verifying the first stage of the bootloader.

Bootloader Verification

The primary bootloader (PBL) or secondary bootloader (SBL) reads the signature of the next stage bootloader (e.g., aboot/fastboot) and verifies it against the embedded hardware RoT. If the signature is valid, the bootloader is loaded. If verification fails, the device typically halts the boot process or enters a recovery mode, indicating a compromised state.

Boot Partition Integrity (boot.img)

Once the bootloader is verified, it proceeds to verify the boot.img. This image contains the kernel and ramdisk, essential components for the operating system to start. The bootloader checks the cryptographic signature embedded within the boot.img, using public keys stored securely in the bootloader or a dedicated verified boot partition. AVB 2.0 introduced a more flexible approach using AVB public key hashes, allowing for easier key updates.

System and Other Partition Verification (dm-verity)

After the kernel and ramdisk are loaded, the kernel takes over and continues the chain of trust using dm-verity (device mapper verity). dm-verity is a Linux kernel feature that transparently verifies the integrity of block devices (like /system, /vendor, /product partitions) in real-time. It uses a hash tree (Merkle tree) where the root hash is signed and stored in the AVB footer of the partition. Each block read from the partition is hashed and compared against its expected hash in the hash tree. If a mismatch occurs, indicating tampering, the device enters a state where it cannot boot normally, or corrupted data access is prevented. Android 10 and later also support fs-verity for file-level integrity checks within partitions.

Common Attack Vectors and Bypass Techniques

While AVB is robust, attackers continuously seek vulnerabilities. Here are some common conceptual attack vectors:

1. Downgrade Attacks

One prevalent attack vector involves attempting to flash an older, vulnerable version of the Android firmware. Older versions might contain known security flaws that could be exploited. AVB mitigates this with **rollback protection (anti-rollback counters)**. These counters are securely stored in a hardware-backed fuse or secure storage area (e.g., eMMC/UFS RPMB) and increment with each new security update. The bootloader compares the anti-rollback counter of the image being flashed with the stored counter. If the image’s counter is lower, the flash operation is rejected, preventing a downgrade.

# Conceptual anti-rollback check during flashing: If (image_rollback_counter < device_stored_counter) {    Reject flashing;    Log security event;}

2. Boot Image Tampering

Attackers might try to modify the boot.img (e.g., injecting a custom kernel with root privileges, modifying the ramdisk to disable security features). If the bootloader is locked, this attempt will fail because the modified boot.img will no longer match the expected cryptographic signature. AVB’s verification process will detect the mismatch and prevent booting.

# Example: avbtool output for a tampered boot image$ avbtool verify_image --image boot.imgVerification FAILED.boot.img: ERROR: Hash mismatch for 'boot' partition.

3. Bootloader Vulnerabilities and OEM Unlocking

Some devices allow