Custom ROM Development Lab: Building AVB 2.0-Compliant (or Non-Compliant) Images for Root

Introduction to Android Verified Boot 2.0

Android Verified Boot (AVB) 2.0 is a critical security feature implemented by Google in modern Android devices. Its primary goal is to ensure the integrity and authenticity of all boot-related partitions (like boot, system, vendor, dtbo, and vbmeta) from the moment the device powers on until the user space is loaded. This ‘chain of trust’ prevents tampering with the OS, protecting users from malicious software. For custom ROM developers and root enthusiasts, AVB 2.0 presents a significant challenge, as any modification to these partitions without proper signing will trigger a verification failure, preventing the device from booting or causing it to enter a recovery state.

This guide delves into two primary strategies for managing AVB 2.0 when developing custom ROMs or rooting Android devices: building AVB-compliant images with your own custom keys, and disabling AVB verification for non-compliant (rooted) images. Both approaches require an unlocked bootloader and a deep understanding of Android’s boot process.

Prerequisites and Setup

Before diving into image manipulation, ensure you have the following setup and understanding:

Knowledge Required:

Basic Linux command-line proficiency.
Understanding of Android’s partition layout.
Familiarity with fastboot and adb tools.
Experience compiling Android source code (for compliant image strategy).

Tools Required:

A Linux-based workstation (Ubuntu/Debian recommended).
Android SDK Platform-Tools (adb and fastboot).
avbtool: Android Verified Boot tool, typically found within the AOSP source tree (prebuilts/build-tools/linux-x86/bin/avbtool) or built from source.
openssl for key generation.
A target Android device with an unlocked bootloader. Unlocking the bootloader usually involves a factory reset and voids warranty, so proceed with caution.

First, ensure avbtool is accessible in your PATH, or specify its full path in commands.

# Example: Locate avbtool find /path/to/aosp/source -name "avbtool" # Add to PATH (replace with your path) export PATH=$PATH:/path/to/aosp/source/prebuilts/build-tools/linux-x86/bin

Understanding AVB 2.0 Architecture

At the heart of AVB 2.0 is the vbmeta partition. This partition acts as a central repository for metadata, including cryptographic digests (hashes) of other partitions and public keys used for verification. During boot, the bootloader reads vbmeta, verifies its signature against a stored public key (usually fused into hardware or protected by a hardware root of trust), and then uses the digests within vbmeta to verify other partitions.

The VBMeta Image

The vbmeta.img contains:

Header: Specifies AVB version, image size, and hash algorithm.
Descriptors: Metadata about partitions (e.g., boot, system), including their sizes and hash trees.
Authentication Block: Contains the signature of the vbmeta image, signed by the device manufacturer’s private key.
Public Key: The public key used to verify the authentication block.

Rollback Protection

AVB 2.0 also incorporates rollback protection, preventing an attacker from flashing older, potentially vulnerable versions of the OS. This is achieved through rollback index counters stored in protected hardware (e.g., eFuses). If a new image has a lower rollback index than the one stored, the boot will fail, even if the image is otherwise valid.

Strategy 1: Building AVB-Compliant Images with Custom Keys

This strategy involves signing your custom ROM images with your own cryptographic keys and then flashing the corresponding public key to the device’s bootloader. This effectively creates a new ‘chain of trust’ where your device trusts your custom ROM as if it were an OEM-signed image. This approach is more secure but often more complex, requiring AOSP compilation.

Generating Your Own AVB Keys

You’ll need a private key for signing and a public key certificate for flashing.

# Generate a 4096-bit RSA private key openssl genrsa -out rsa4096.pem 4096 # Extract the public key openssl rsa -in rsa4096.pem -pubout -out rsa4096.pub # Convert public key to AVB format avbtool extract_public_key --input rsa4096.pem --output rsa4096.avbpubkey

Integrating Custom Keys into AOSP Build

If you’re building AOSP, you can instruct the build system to use your keys:

Place rsa4096.pem and rsa4096.avbpubkey in a specific directory, e.g., ./build/make/target/product/security/custom.

Modify your device’s BoardConfig.mk or product definition to point to your custom keys for AVB signing. For example:

BOARD_AVB_ENABLE := true BOARD_AVB_ALGORITHM := SHA256_RSA4096 BOARD_AVB_KEY_PATH := build/make/target/product/security/custom/rsa4096.pem BOARD_AVB_VBMETA_KEY_PATH := build/make/target/product/security/custom/rsa4096.pem BOARD_AVB_VBMETA_ALGORITHM := SHA256_RSA4096

Build your AOSP images. The build system will then use your keys to sign vbmeta.img and other AVB-protected partitions.

Manual Signing Images with avbtool

If you’re not compiling AOSP, you can manually sign individual images and generate a new vbmeta.img.

# Sign boot.img avbtool add_hash_footer --image boot.img --partition_name boot --partition_size $(stat -c %s boot.img) --key rsa4096.pem --algorithm SHA256_RSA4096 # Sign system.img avbtool add_hash_footer --image system.img --partition_name system --partition_size $(stat -c %s system.img) --key rsa4096.pem --algorithm SHA256_RSA4096 # Create a new vbmeta.img using signed images avbtool make_vbmeta_image 	--output vbmeta.img 	--signing_key rsa4096.pem 	--algorithm SHA256_RSA4096 	--padding_algorithm PSS 	--include_descriptors_from_image boot.img 	--include_descriptors_from_image system.img 	--include_descriptors_from_image vendor.img # (add all relevant signed partitions)

Flashing Custom Keys and Images

After generating your signed images and rsa4096.avbpubkey, you need to flash the public key to your device. This often requires a special fastboot command, usually fastboot flash avb_custom_key <key_file> or similar, which is device-specific and might not be available on all devices. Consult your device’s documentation or community forums for this critical step. Once the key is flashed, you can flash your custom images:

adb reboot bootloader # If supported, flash the custom public key fastboot flash avb_custom_key rsa4096.avbpubkey # Flash your signed vbmeta and other partitions fastboot flash vbmeta vbmeta.img fastboot flash boot boot.img fastboot flash system system.img fastboot flash vendor vendor.img fastboot reboot

If your device accepts the custom public key, it will now boot your custom ROM.

Strategy 2: Disabling AVB 2.0 for Non-Compliant Root Images

This strategy is typically used for rooting, where modifying the boot.img (e.g., with Magisk) results in a non-compliant image. Disabling AVB allows the bootloader to ignore signature mismatches on certain partitions. Be aware that this reduces your device’s security.

Method A: Using Fastboot Flags (Simplest)

Many unlocked bootloaders provide specific fastboot commands to disable AVB verification dynamically during flashing. This is often the easiest way to bypass AVB for rooting or custom ROM installation.

adb reboot bootloader fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img fastboot flash boot patched_boot.img fastboot reboot

--disable-verity: Disables dm-verity (hash tree verification for read-only partitions).
--disable-verification: Disables the overall AVB signature verification for the partition being flashed.
The vbmeta.img used here can be the stock one, a minimal dummy one, or one specifically designed by the community to disable verification. The crucial part is that these fastboot flags tell the bootloader to proceed regardless of the image’s signature.

Method B: Manually Patching vbmeta.img (More Advanced)

If your bootloader does not support the --disable-verity/--disable-verification flags directly, you might need to create a custom vbmeta.img that has verification explicitly disabled.

Extract Stock vbmeta.img: If you don’t have it, extract it from your device or factory image.
```
adb pull /dev/block/by-name/vbmeta vbmeta.img
```
Create a Disabled vbmeta.img: Use avbtool to make a new vbmeta.img with the necessary flags set. This usually means setting the AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED flag (value 1) and potentially AVB_VBMETA_IMAGE_FLAGS_ROLLBACK_INDEX_DISABLED (value 2), resulting in a flags value of 3. You’ll need a dummy private key as `avbtool` always requires a signing key, even if verification is disabled.
```
# Generate a dummy key (can be reused) openssl genrsa -out dummy_key.pem 2048 # Create the disabled vbmeta image avbtool make_vbmeta_image 	--output vbmeta_disabled.img 	--signing_key dummy_key.pem 	--algorithm SHA256_RSA2048 	--flags 3 	--chain_partition boot:1:$(avbtool get_size_of_image boot.img) 	--chain_partition system:2:$(avbtool get_size_of_image system.img) # Add more chain_partition entries for all relevant partitions
```
Note: The --chain_partition entries need to point to the correct sizes of your actual boot.img, system.img, etc. You can get these sizes using avbtool get_size_of_image <image_path>.

Flash the Disabled vbmeta:

fastboot flash vbmeta vbmeta_disabled.img

Patching boot.img for Root (Magisk Example)

Once AVB is disabled, you can proceed to root your device. The most common method involves patching the device’s boot.img with Magisk.

Extract Stock boot.img: Obtain the boot.img corresponding to your device’s exact firmware version. You can usually extract it from a factory image or by pulling it from the device:
```
adb pull /dev/block/by-name/boot boot.img
```
Patch with Magisk: Transfer boot.img to your device, install Magisk Manager, and select

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 →