Introduction to Android Verified Boot and Image Integrity

The integrity of the Android boot process is paramount for device security. Android Verified Boot (AVB), introduced with Android 7.0 and significantly enhanced in later versions, plays a critical role in ensuring that all executed code from the bootloader to the system image originates from a trusted source. This mechanism prevents tampering and unauthorized modifications, safeguarding user data and device functionality.

This lab delves into the practical aspects of reverse engineering an Android boot image, specifically focusing on how AVB metadata and signatures are embedded and structured. By understanding these components, security researchers and developers can verify the integrity of their device firmware, analyze potential vulnerabilities, or even prepare custom signed images for development purposes on unlocked bootloaders.

Prerequisites for the Lab

To follow along with this lab, you will need a Linux environment (Ubuntu/Debian recommended) and the following tools:

• adb (Android Debug Bridge): For interacting with Android devices.
• dd: A command-line utility for converting and copying files.
• hexdump or xxd: For viewing binary data in hexadecimal.
• strings: For extracting printable strings from binary files.
• avbtool: The official Android Verified Boot tool. This can be built from AOSP sources or found within pre-built Android SDK platform tools.
• abootimg: A tool for working with Android boot images (optional, but helpful for legacy images).
• Basic understanding of Linux command-line operations.

Installing avbtool

If avbtool is not readily available, you can build it from AOSP or find pre-compiled binaries in Android platform-tools if you have a recent SDK installation.

# Example of finding avbtool (path might vary)find ~/Android/Sdk/platform-tools -name avbtool

Understanding Android Boot Image Structure and AVB

A typical Android boot image (boot.img) historically contained a kernel, a ramdisk, and a boot header. With AVB, an additional `AvbFooter` and often a `vbmeta.img` are appended or referenced. The `vbmeta.img` itself contains descriptors (hash, signature, chain partition) and the actual signature that verifies the integrity of other partitions (like boot, system, vendor, dtbo).

Key Components:

• Boot Header: Metadata about the kernel and ramdisk.
• Kernel: The Linux kernel image.
• Ramdisk: An initial filesystem image used during the early boot process.
• AVB Footer (`AvbFooter`): A fixed-size structure appended to the end of a verified partition, pointing to the `vbmeta.img`’s location and size.
• VBMeta Image (`vbmeta.img`): Contains hash descriptors for other partitions, chain partition descriptors (for chained verification), and the overall signature for the `vbmeta.img` itself.

Lab Setup: Obtaining a Boot Image

For this lab, we’ll need a boot.img. You can obtain one by extracting it from your device or by downloading official factory images for your specific device model.

Method 1: Extracting from a Device (Rooted or TWRP)

If your device is rooted or has a custom recovery like TWRP, you can pull the boot partition directly:

adb shellsu # Or enter TWRP shell modedd if=/dev/block/by-name/boot of=/sdcard/boot.imgexitexitadb pull /sdcard/boot.img .

Method 2: Downloading Factory Images

Google Pixel devices, for example, offer factory images on their developer website. Download the appropriate ZIP file, extract it, and locate the `boot.img` inside.

# Example for a Pixel device (paths vary)unzip sailfish-opm8.170623.011-factory-e8e64c6d.zipcd sailfish-opm8.170623.011/image-sailfish-opm8.170623.011.zipunzip image-sailfish-opm8.170623.011.zipcp boot.img ~/avb_lab/

Step 1: Initial Boot Image Inspection

First, let’s get some basic information about our `boot.img`.

file boot.imghexdump -C boot.img | head -n 10

You’ll likely see output indicating