> For the complete documentation index, see [llms.txt](https://riteshs4hu.gitbook.io/infosec-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://riteshs4hu.gitbook.io/infosec-notes/android-appsec/rooting/android-verified-boot.md).

# Android Verified Boot

**Android Verified Boot (AVB)** is a security system that checks if each Android partition has been modified before the OS boots.

Think of it like:

> **A security guard who checks each Android partition and only allows trusted images to boot.**

AVB ensures:

* No tampered boot image
* No modified system image
* No malware embedded in the boot partition
* No fake firmware
* No unauthorized custom ROM without the user knowing

AVB replaced the older dm-verity and became mandatory on Android 8+.

***

### **Core Idea of AVB**

During boot:

1. The **bootloader** loads `vbmeta.img`
2. `vbmeta` contains cryptographic signatures for other partitions
3. The bootloader compares signatures
4. If anything is modified → boot **fails** or boots in **red** state

So everything is chained:

**vbmeta → checks → boot → checks → system → checks → vendor → checks → dtbo** (etc.)

This is called the **AVB chain of trust**.

### WHY does AVB exist?

To protect users from:

* Rootkits
* Persistent malware
* Modified boot images
* Fake ROMs
* Attacks that replace system files with malicious ones

It ensures **the OS running is exactly what the manufacturer shipped.**

### AVB RELATED FILES (VERY IMPORTANT)

AVB involves several files.

#### **`vbmeta.img`**

This is the **heart** of AVB.

It contains signatures for:

* boot.img
* system.img
* vendor.img
* dtbo.img
* recovery.img
* product.img
* system\_ext.img

Think of `vbmeta.img` as:

> **The main list of what partitions are allowed to boot.**

If vbmeta is modified → AVB fails → bootloader shows RED / refuses boot.

#### **`vbmeta_system.img`**

Some devices (like Xiaomi, OnePlus, Samsung) split signature areas.

`vbmeta_system` verifies:

* system
* system\_ext
* product
* odm

#### **`vbmeta_vendor.img`**

This verifies:

* vendor partition
* vendor\_boot
* dtbo
* odm partition

#### **`boot.img`**

Contains:

* Kernel
* ramdisk
* init
* Magisk patch (if rooted)

AVB verifies boot.img signature using vbmeta.

#### **`vendor_boot.img`**

Used on modern Android for:

* vendor kernel ramdisk
* GPU/multi-display drivers
* HALs

Also verified by vbmeta.

#### **`dtbo.img`**

DTBO = **Device Tree Blob Overlay**

Stores information like:

* screen panel
* touch drivers
* hardware configs

AVB verifies dtbo before the kernel loads it.

#### **`system.img`, `vendor.img`, `product.img`, `odm.img`**

These contain the OS itself:

* `/system` → core OS files
* `/vendor` → OEM drivers
* `/product` → Google/MIUI apps
* `/odm` → device-specific components

AVB verifies them to ensure no modification.

### What happens if any file is modified?

#### If AVB enabled:

* Bootloader detects a mismatch
* The device **refuses to boot** or shows a **red warning**
* The corrupted OS is blocked

#### If the bootloader is unlocked:

* Boot state becomes **orange**, but AVB still checks signatures

#### If vbmeta is patched to disable AVB:

* Device boots even with modified partitions
* The boota  state becomes **red**
* System integrity checks disabled

***

### Summary Table

| File                   | Purpose                        | Verified by AVB? |
| ---------------------- | ------------------------------ | ---------------- |
| **vbmeta.img**         | Root AVB metadata + signatures | Yes              |
| **vbmeta\_system.img** | System-related signatures      | Yes              |
| **vbmeta\_vendor.img** | Vendor signatures              | Yes              |
| **boot.img**           | Kernel + ramdisk               | Yes              |
| **vendor\_boot.img**   | Vendor kernel ramdisk          | Yes              |
| **dtbo.img**           | Hardware config                | Yes              |
| **system.img**         | Main OS files                  | Yes              |
| **vendor.img**         | Drivers & HAL                  | Yes              |
| **product.img**        | Google/OEM apps                | Yes              |
| **odm.img**            | Device-specific pieces         | Yes              |

***

### What happens when you disable AVB?

When you disable AVB (by patching vbmeta):

* You can flash custom boot.img
* You can modify the system/vendor
* You can root the device
* You can mount the system RW
* You can install a custom recovery
* But OS integrity is not checked
* The boot state becomes **red**
* BUT your personal data **remains encrypted.** AVB does NOT affect encryption.