Introduction to Android Verified Boot 2.0 (AVB 2.0)

Android Verified Boot (AVB) 2.0 is a critical security feature designed to ensure the integrity of the software running on Android devices, from the bootloader all the way up to the system partition. Its primary goal is to prevent a device from booting if it detects tampering with the device’s software. This “chain of trust” mechanism ensures that every stage of the boot process verifies the next stage before execution. AVB 2.0 enhances its predecessor by introducing features like rollback protection, which prevents an attacker from flashing an older, potentially vulnerable version of Android, and the ability to verify multiple partitions efficiently through a `vbmeta` image.

For anyone involved in Android development, custom ROMs, or kernel modifications, understanding AVB 2.0 is paramount. Bypassing or managing AVB correctly is often a prerequisite for successfully flashing custom software. Incorrect handling can lead to boot loops, bricked devices, or being unable to boot into your modified system. This is where `avbtool` comes into play.

Understanding `avbtool`: The Core Utility

`avbtool` is a command-line utility provided within the Android Open Source Project (AOSP) that facilitates the creation, signing, and verification of AVB metadata. It is the primary interface for interacting with the Android Verified Boot system from a development perspective. Whether you’re an OEM preparing device images, a custom ROM developer creating new builds, or a security researcher analyzing the boot process, `avbtool` is indispensable. It can be found in the `prebuilts/avb/` directory within the AOSP source tree or compiled from source.

Key `avbtool` Commands and Concepts

`avbtool` works by embedding cryptographic metadata into images or creating a standalone `vbmeta.img` file. This metadata includes hashes of partitions, public keys, and flags that dictate the verification process.

1. `make_vbmeta_image`: Creating the Root of Trust

The `vbmeta.img` is the centerpiece of AVB 2.0. It acts as the root of trust, containing the hashes or descriptors for other verified partitions (like `boot.img`, `system.img`, `vendor.img`, `dtbo.img`). When the device boots, the bootloader verifies the `vbmeta.img` using a hardcoded public key. If `vbmeta.img` is valid, it then uses the public keys embedded within it to verify the other partitions.

Generating a `vbmeta.img` with `avbtool` involves specifying a private key for signing, an algorithm, and any desired flags or chained partitions.

avbtool make_vbmeta_image 
  --output vbmeta.img 
  --signer_key rsa4096_key.pem 
  --signer_algorithm SHA256_RSA4096 
  --padding_size 4096 
  --rollback_index 0 
  --set_hashtree_disabled_flag 
  --set_verity_disabled_flag 
  --set_rollback_index_location 0

In this example:

• `–output vbmeta.img`: Specifies the output filename.
• `–signer_key rsa4096_key.pem`: The private key used to sign the `vbmeta` image itself.
• `–signer_algorithm SHA256_RSA4096`: The cryptographic algorithm used for signing.
• `–padding_size`: Adds padding for future expansion.
• `–rollback_index 0`: Essential for rollback protection. Prevents flashing older `vbmeta` images.
• `–set_hashtree_disabled_flag` and `–set_verity_disabled_flag`: Crucial for custom ROMs, as they disable cryptographic verification of filesystem integrity.

2. `add_hash_footer`: Protecting Individual Partitions

For partitions like `boot.img` or `dtbo.img`, `avbtool` can embed a hash footer directly into the image. This footer contains the cryptographic hash of the partition’s content. The bootloader then verifies this hash against the stored public key or a chained descriptor in `vbmeta.img`.

avbtool add_hash_footer 
  --image boot.img 
  --partition_name boot 
  --partition_size $(stat -c %s boot.img) 
  --hash_algorithm sha256 
  --output boot_signed.img

This command takes an existing `boot.img`, calculates its SHA256 hash, and appends it as a footer. The `–partition_size` is vital as it tells AVB the actual usable size of the partition content before the footer.

3. `add_chained_partition`: Linking Partitions Securely

While `add_hash_footer` embeds metadata, `add_chained_partition` is used with `make_vbmeta_image` to create descriptors within `vbmeta.img` that point to other partitions. This means the `vbmeta.img` itself doesn’t contain the full hash of the `boot.img`, but rather a descriptor that includes the public key used to verify the `boot.img`’s embedded hash footer.

avbtool make_vbmeta_image 
  --output vbmeta.img 
  --signer_key rsa4096_key.pem 
  --signer_algorithm SHA256_RSA4096 
  --add_chained_partition boot:10:boot_pubkey.pem 
  --add_chained_partition dtbo:11:dtbo_pubkey.pem

Here, `boot:10:boot_pubkey.pem` means that the `boot` partition (with rollback index 10) should be verified using the public key derived from `boot_pubkey.pem`. This `boot_pubkey.pem` would typically correspond to the private key used to sign `boot.img` with `add_hash_footer`.

4. `verify_image`: Checking AVB Status

Once an image is built, you can verify its AVB status using `avbtool` to ensure correctness.

avbtool verify_image --image vbmeta.img

This command checks the integrity and signature of the `vbmeta.img`. You can also verify partitions like `boot.img` if they contain embedded hash footers.

Practical Use Case: Custom ROMs and Kernels

When flashing custom kernels or full custom ROMs (like LineageOS), the original AVB signatures are often invalid because the `boot.img` (kernel) and other system partitions have been modified. This will trigger AVB, preventing your device from booting. To overcome this, most custom ROM communities resort to disabling or relaxing AVB verification.

Building a Custom Boot Image for AVB

If you’re building a custom kernel or modifying your `boot.img`, you’ll need to re-sign it. The challenge is that you don’t have the OEM’s private key. The common approach is to use your own keys and then flash a `vbmeta.img` that either trusts your key or disables verification.

1. Extract OEM Public Keys (Optional but useful for analysis): Use `avbtool extract_public_key –image vbmeta.img –output avb_pk.bin` from your stock `vbmeta.img`.
2. Modify your `boot.img`: Compile your custom kernel, ramdisk, etc.
3. Sign your `boot.img` with your custom key: First, generate your own RSA key pair (e.g., `openssl genrsa -out rsa4096_key.pem 4096`). Then, add a hash footer to your custom `boot.img` using your private key. This is done implicitly by `add_hash_footer` if you specify `–key`.
4. Create a new `vbmeta.img`: This is the critical step. You’ll create a `vbmeta.img` that trusts your custom `boot.img` or, more commonly, disables verification entirely.

Disabling AVB for Custom ROMs (The Common Approach)

For maximum compatibility with custom ROMs and kernels, developers often provide a `vbmeta.img` that tells the bootloader to ignore verification failures. This is typically done by setting specific flags in the `vbmeta.img`.

avbtool make_vbmeta_image 
  --output vbmeta.img 
  --padding_size 4096 
  --flag 2 
  --rollback_index 0 
  --set_hashtree_disabled_flag 
  --set_verity_disabled_flag 
  --key /dev/null 
  --algorithm NONE

Let’s break down the key flags here:

• `–flag 2`: This is `AVB_VBMETA_IMAGE_FLAGS_ROLLBACK_INDEX_DISABLED`. It tells the bootloader to ignore rollback index verification, which is crucial if you’re flashing older firmware or simply want to bypass this check.
• `–set_hashtree_disabled_flag` and `–set_verity_disabled_flag`: These flags explicitly disable `dm-verity` (device mapper verity), which is responsible for block-level verification of read-only partitions (like `system` and `vendor`). Disabling this is necessary when these partitions are modified, as is common with custom ROMs.
• `–key /dev/null` and `–algorithm NONE`: These effectively make the `vbmeta.img` unsigned or signed with a null key, signaling to the bootloader (if configured to allow it) that no cryptographic verification should be performed on the `vbmeta.img` itself. Some devices might still require a valid, though custom, key.

After generating this `vbmeta.img`, you would typically flash it using `fastboot`:

fastboot flash vbmeta vbmeta.img

It’s important to note that disabling AVB significantly reduces the security posture of your device, making it more vulnerable to malicious modifications. Always proceed with caution and understand the implications.

Conclusion

`avbtool` is an indispensable tool for anyone navigating the complexities of Android Verified Boot 2.0. By understanding its core commands and concepts, you gain the power to manage device integrity, whether you’re securing OEM firmware or enabling the flexibility required for custom Android development. While AVB’s primary goal is security, `avbtool` provides the means to adapt its behavior to suit advanced use cases like custom ROMs and kernels, albeit with a clear understanding of the security tradeoffs involved.