AOSP Foundations
3 min read

Android Verified Boot (AVB)

Understand the cryptographic chain of trust that guarantees the operating system has not been tampered with by malware.

If a highly sophisticated piece of malware manages to gain root privileges on an Android device, it could theoretically inject malicious code directly into the physical /system or /boot partitions. This type of advanced malware (a rootkit) would survive factory resets and be completely invisible to traditional antivirus software because it would load before the antivirus even starts.

To permanently prevent this, Google introduced Android Verified Boot (AVB).

AVB guarantees that every single byte of the operating system executed on the device is cryptographically signed and inherently trusted by the manufacturer.

The Chain of Trust

AVB works by establishing an unbroken "Chain of Trust" from the exact moment the power button is pressed. If any link in the chain is broken, the device halts and refuses to boot.

  1. Boot ROM to PBL: The immutable Boot ROM (etched securely in hardware) verifies the cryptographic signature of the Primary Bootloader (PBL) before executing it.
  2. PBL to SBL: The PBL verifies the signature of the Secondary Bootloader (XBL/ABL).
  3. ABL to Linux Kernel: The ABL verifies the signature of the boot.img (Linux Kernel).
  4. Linux Kernel to System: The Linux Kernel continuously verifies the integrity of the /system and /vendor partitions as they are accessed.

The vbmeta Partition

To manage all these signatures cleanly, modern Android devices feature a dedicated, specialized partition called vbmeta (Verified Boot Metadata).

Instead of embedding the cryptographic keys and hash values directly into every single partition, the AOSP build system generates a centralized vbmeta.img.

The vbmeta partition contains:

  • The public keys required to verify the signatures.
  • A cryptographic hash of the boot.img and init_boot.img.
  • The root hash of the system and vendor partition hash trees.

When the Android Bootloader (ABL) starts, it simply reads the vbmeta partition. If the digital signature on the vbmeta partition itself is mathematically valid, the bootloader explicitly trusts all the hashes contained within it and uses them to verify the rest of the OS.

# Security researchers can extract and verify vbmeta information using the avbtool
avbtool info_image --image vbmeta.img

Unlocking the Bootloader

When a developer "unlocks the bootloader", they are explicitly instructing the hardware to disable the AVB Chain of Trust.

# The standard command to permanently break the AVB chain for custom ROM development
fastboot flashing unlock

An unlocked bootloader will display a harsh warning message on the screen ("Your device software cannot be checked for corruption") and will willingly execute modified, unsigned kernels or custom ROMs. Because this intentionally breaks the core security model, unlocking the bootloader will permanently disable highly secure apps like Google Pay and certain banking applications.