Introduction to Android Verified Boot 2.0 (AVB2)

Android Verified Boot 2.0 (AVB2) is a critical security feature designed to prevent malicious modifications to the operating system from being loaded during the boot process. It establishes a complete chain of trust from the hardware root of trust up to the system partition, ensuring the integrity of all loaded code. For security researchers and enthusiasts, understanding and reverse engineering AVB2 is paramount for identifying potential vulnerabilities, customizing device firmware, or simply gaining deeper insight into Android’s robust security model. This guide provides an expert-level walkthrough of AVB2 analysis, from dissecting `vbmeta.img` to observing the effects of tampering.

Understanding AVB2 Fundamentals

AVB2 operates on the principle of a ‘chain of trust’. Each stage of the boot process verifies the integrity and authenticity of the next stage before handing over control. This chain starts from a hardware-backed immutable root of trust (usually in the SoC’s boot ROM) and extends through the bootloader, `vbmeta.img`, and ultimately to all verified partitions.

Key Components of AVB2:

• Root of Trust (RoT): A hardware-protected public key embedded during manufacturing, used to verify the bootloader.
• Bootloader: The initial software that loads after the RoT, responsible for verifying the `vbmeta.img`.
• vbmeta.img: A critical image containing hash descriptors and signing information for all other partitions (e.g., `boot`, `system`, `vendor`). It holds the hashes of other partitions, along with a signature verifiable by the bootloader’s embedded public key.
• Partition Hashes: Cryptographic hashes of individual partitions are stored within `vbmeta.img`.
• Rollback Protection: AVB2 incorporates a mechanism to prevent an attacker from downgrading a device to an older, potentially vulnerable software version by tracking software versions within the fuse or Replay Protected Memory Blocks (RPMB).

The verification process involves the bootloader reading the `vbmeta.img`, verifying its signature against the RoT’s public key, and then using the verified hashes within `vbmeta.img` to check the integrity of other partitions. If any verification fails, the device may enter a locked state, display a warning, or refuse to boot entirely.

Lab Setup: Tools and Environment

To effectively reverse engineer and interact with AVB2, you’ll need a specific set of tools and a controlled environment:

Prerequisites:

• Android Device: A device with an unlockable bootloader (e.g., Google Pixel series) is highly recommended for experimentation.
• Linux Environment: A Linux distribution (Ubuntu, Debian, Fedora) provides the best compatibility for most Android development tools.
• Android SDK Platform Tools: Essential for `adb` and `fastboot`.
• avbtool: The official Android Verified Boot tool. This can usually be found within the Android Open Source Project (AOSP) source tree or compiled from source.
• Hex Editor: For low-level inspection and modification (e.g., hexedit, bless, 010 Editor).
• Disassembler/Decompiler: (Optional, for deeper bootloader analysis) Ghidra or IDA Pro.
• Python 3: For scripting and potentially running `avbtool` wrappers.

Installation Commands (Example for Ubuntu):

# Install Android SDK Platform Tools (if not already installed)sudo apt update sudo apt install android-tools-adb android-tools-fastboot# Clone AOSP platform/system/extras for avbtool (or download precompiled)git clone https://android.googlesource.com/platform/system/extrascd platform/system/extras/fastboot/libavb# Compile avbtool (requires protobuf-compiler, etc.)# This step can be complex, often easier to get a precompiled version from AOSP build or custom ROM build environment.

Extracting and Analyzing `vbmeta.img`

The `vbmeta.img` is the central piece of AVB2. We’ll start by extracting it from a device or factory image.

Step 1: Obtain `vbmeta.img`

If your device has an unlocked bootloader, you can pull it directly:

adb reboot bootloaderfastboot flash --slot=all vbmeta vbmeta.img # Flash a dummy vbmeta for testing, then pull the original.fastboot rebootfastboot --skip-secondary # For some devices with A/B partitioningfastboot fetch vbmeta vbmeta.img # This command might not work on all devices. Alternatively, extract from factory image.

More reliably, download the factory image for your device from the official source (e.g., Google’s developer site for Pixel devices). Unzip the factory image, and you’ll find `vbmeta.img` within the extracted contents (often inside a `.zip` file within the main `.zip`).

Step 2: Inspect `vbmeta.img` with `avbtool`

The `avbtool` is your primary utility for interacting with AVB2 images. It allows inspection, signing, and verification.

avbtool info_image --image vbmeta.img

This command will output detailed information about the `vbmeta.img`, including the public key hash, partition descriptors, and their associated hashes. Pay close attention to the `Hash Descriptor` entries; these list the partitions (e.g., `boot`, `system`) and their corresponding expected hashes and sizes.

# Example Output Snippet:  Image Size: 409600 bytes  Original Image Size: 409600 bytes  Header Block: 4096 bytes  Authentication Block: 30720 bytes  Auxiliary Block: 374784 bytes  Algorithm: SHA256_RSA4096  Rollback Index: 0  Rollback Index Location: 0  Public Key Hash: 4e6a8e178129a67e... (This is crucial)  Hash Descriptors:    - partition_name: boot      hash: 0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b      image_size: 134217728    - partition_name: system      hash: ...

Simulating Tampering: Breaking the Verification Chain

Let’s demonstrate how modifying a partition breaks the AVB2 chain. We’ll modify `boot.img`, which is verified by `vbmeta.img`.

Step 1: Extract `boot.img`

Obtain `boot.img` from your factory image or device.

fastboot fetch boot boot.img # Or extract from factory image zip

Step 2: Modify `boot.img`

For a subtle, non-breaking change, we can modify a few bytes that don’t immediately crash the kernel or ramdisk. Using a hex editor, open `boot.img` and change a few bytes (e.g., in the kernel string table or a less critical section of the ramdisk). For this example, let’s assume we modify a few bytes at offset `0x1000`.

hexedit boot.img# Make a small, arbitrary change, then save and exit.

Step 3: Attempt to Flash and Boot

Flash the modified `boot.img` to your device and try to boot.

fastboot flash boot_a modified_boot.img # For A/B devices, flash to active slotfastboot reboot

Upon reboot, the bootloader will calculate the hash of the modified `boot.img`. This hash will not match the hash recorded in `vbmeta.img`. As a result, AVB2 verification will fail. Depending on the device and its AVB2 configuration (e.g., `dm-verity` modes), you might observe:

• A
  
  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 →