1. 课程导入
Android Verified Boot（AVB）是 Android 平台用于保证系统启动链路完整性与真实性的安全机制。它从设备上电的第一段可执行代码开始，逐级校验后续镜像的签名与哈希，确保设备只运行由可信厂商签名的系统软件。AVB 的目标不是“防止所有攻击”，而是把启动过程从“默认信任”转变为“可验证信任”：一旦关键分区被篡改，设备要么拒绝启动，要么以明确的可信状态降级启动，并把状态传递给上层系统与用户。
理解 AVB 需要抓住三个关键词：信任根、验证链、状态传递。信任根通常固化在硬件或只读区域中，无法被普通软件修改；验证链把信任从 BootROM 逐级传递到 boot、init_boot、vendor_boot、system、vendor 等分区；状态传递则通过 Android 的启动状态（绿、黄、橙、红）以及 dm-verity、AVB 元数据等机制，让系统知道当前运行环境是否可信。
一、AVB 在 Android 安全体系中的位置
Android 安全体系可以粗略分为启动前安全、启动时安全与运行时安全。AVB 位于启动时安全的核心位置，与硬件信任根、TEE、Keymaster、dm-verity、SELinux、应用沙箱等共同构成纵深防御。它解决的是“系统镜像是否被篡改”的问题，而 SELinux 解决“进程能访问什么”，应用沙箱解决“应用之间如何隔离”，Keymaster 解决“密钥如何被安全保存与使用”。
核心定位：AVB 是 Android 启动链的“完整性闸门”。没有 AVB，攻击者可以通过修改 system 分区植入持久化后门；有了 AVB，篡改会被签名校验或哈希树校验发现，设备可以拒绝启动或进入明确的不可信状态。
二、发展历程：从 dm-verity 到 AVB 2.0
Android 的启动完整性校验并非一开始就是 AVB。早期 Android 4.4 引入了 dm-verity，用于对 system 等只读分区做块级哈希树校验，解决“运行时读取时校验”的问题。Android 6.0 引入 Verified Boot 1.0，主要对 boot 与 system 分区做签名校验。Android 7.0 开始引入 AVB 1.0，Android 8.0 正式推出 AVB 2.0，并逐步成为 Android 兼容性要求的一部分。AVB 2.0 的关键改进包括：统一的 vbmeta 元数据、支持链式分区描述符、支持 hashtree 与 hash 描述符、支持回滚保护、支持启动状态颜色，以及与 fastboot 刷写流程的深度整合。
| 阶段 | 代表机制 | 主要能力 | 局限 |
|---|---|---|---|
| Android 4.4 | dm-verity | 块级哈希树校验，运行时读取校验 | 不覆盖启动前镜像签名 |
| Android 6.0 | Verified Boot 1.0 | boot/system 签名校验 | 元数据分散，扩展性有限 |
| Android 7.0 | AVB 1.0 | 统一镜像格式与校验流程 | 功能与兼容性仍在演进 |
| Android 8.0+ | AVB 2.0 | vbmeta、描述符、回滚保护、启动状态 | 配置复杂，依赖厂商正确实现 |
三、AVB 的核心原理与验证流程
AVB 的验证流程可以概括为“从信任根出发，逐级校验，最终决定启动状态”。设备上电后，BootROM 校验并加载 bootloader；bootloader 读取 vbmeta 分区，使用内置公钥验证 vbmeta 的签名；vbmeta 中包含对 boot、init_boot、vendor_boot、system、vendor 等分区的描述符，bootloader 根据描述符校验对应镜像的哈希或 hashtree；如果所有校验通过，设备进入绿色状态；如果设备解锁，则进入橙色状态；如果校验失败，则进入红色状态并可能拒绝启动。
上图展示了 AVB 的典型验证链：硬件信任根提供初始信任，bootloader 验证 vbmeta，vbmeta 再描述并约束各个分区，最终形成启动状态。实际设备中，vbmeta 可能包含多个描述符，分区也可能采用 hashtree 或 hash 两种校验方式。hashtree 适合大分区，支持运行时按块校验；hash 适合小分区，启动时一次性校验。
四、典型场景与常见误区
在真实项目中，AVB 最常见的场景包括：新设备首次烧录、OTA 升级、fastboot 刷写、设备解锁与重新上锁、以及启动失败排障。例如，OTA 升级时，系统需要更新 vbmeta 与分区镜像，并保证回滚索引不降低；如果回滚索引被错误降低，设备可能拒绝启动。fastboot 刷写时，如果只刷了 boot 而没有刷 vbmeta，可能导致校验失败。
常见误区：“解锁 bootloader 后 AVB 就失效了。”实际上，解锁只是改变启动状态与校验策略，AVB 仍然会校验并报告状态。另一个误区是“AVB 能防止所有篡改”。AVB 主要保护启动链完整性，不能替代 SELinux、应用沙箱、密钥管理或运行时防护。
五、学习目标与整体课程框架
本课程将围绕 AVB 的工程实现展开，目标是让学习者能够理解 AVB 的信任模型、掌握 vbmeta 与描述符的配置方法、熟悉签名与校验流程、能够使用 avbtool 与 fastboot 进行实操，并具备启动失败排障能力。整体课程分为五个模块：基础概念与安全定位、镜像格式与元数据、签名与密钥管理、启动流程与状态机、工程实践与排障。
- 基础概念：AVB 定义、发展历程、与 dm-verity 的关系、启动状态颜色。
- 镜像与元数据：vbmeta 结构、描述符类型、hashtree 与 hash、回滚索引。
- 签名与密钥：公钥私钥、签名算法、密钥轮换、自定义密钥与测试密钥。
- 启动流程：BootROM、bootloader、vbmeta、分区校验、状态传递。
- 工程实践：avbtool 命令、fastboot 刷写、OTA 集成、常见故障与排障。
# 查看设备 AVB 状态（示例）
adb shell getprop ro.boot.verifiedbootstate
adb shell getprop ro.boot.veritymode
adb shell getprop ro.boot.vbmeta.device_state
# 查看 vbmeta 信息（示例）
avbtool info_image --image vbmeta.img
# 校验镜像（示例）
avbtool verify_image --image boot.img --key public_key.bin