📚 课程目录第4章升级包结构与签名机制

4. 升级包结构与签名机制

Android OTA升级并不是简单地把新系统文件覆盖到设备上，而是一套围绕“包结构、签名校验、防回滚、安全启动”构建的完整信任链。理解这套机制，是后续做升级失败回滚、故障恢复和降级策略设计的基础。本章从OTA包格式入手，逐层拆解payload.bin、update.zip、签名校验、防回滚与安全启动之间的关系。

一、OTA包的两大形态：完整包与增量包

Android OTA包本质上是一个ZIP容器，通常命名为update.zip。根据内容差异，分为完整包（Full OTA）和增量包（Incremental OTA）。完整包包含目标版本的全部镜像，体积大但升级路径简单；增量包只包含从源版本到目标版本的差异数据，体积小、下载快，但对源版本一致性要求极高，一旦设备当前分区与预期源版本不匹配，校验就会失败。

在A/B无缝升级架构中，OTA包不再由recovery解压执行，而是由update_engine守护进程直接读取payload并写入非活动槽位（slot B），因此包结构也演变为以payload.bin为核心。

二、update.zip内部结构与payload.bin

一个典型的A/B OTA包解压后包含以下关键文件：

payload.bin：真正的升级数据，包含各分区镜像或差分操作。
payload_properties.txt：记录payload的哈希、大小、元数据签名等。
META-INF/com/android/metadata：描述设备、版本、时间戳、post-build等约束。
care_map.pb：标记需要校验的dm-verity数据块范围。
META-INF/CERT.RSA、CERT.SF、MANIFEST.MF：ZIP层签名文件。

payload.bin采用名为update_engine payload的格式，头部是PayloadHeader，随后是若干InstallOperation。每个操作描述对某个分区的某段数据做REPLACE、REPLACE_BZ、REPLACE_XZ、SOURCE_COPY、SOURCE_BSDIFF、BROTLI_BSDIFF或ZERO等处理。增量包正是通过BSDIFF差分算法，把旧分区数据与新分区数据之间的差异压缩进payload。

PayloadHeader {
  magic: "CrAU"
  version: 2
  manifest_len: ...
  metadata_signature_len: ...
}
PartitionUpdate {
  partition_name: "system"
  new_partition_info: { size, hash }
  operations: [ InstallOperation ... ]
}

三、签名校验：从ZIP签名到payload元数据签名

OTA包存在两层签名。第一层是ZIP容器签名，位于META-INF/，用于验证包内文件未被篡改；第二层是payload元数据签名，payload_properties.txt中的哈希与PayloadHeader里的metadata_signature共同保证payload本身可信。设备端update_engine会先用内置的公钥验证元数据签名，再逐块校验payload数据哈希，最后对写入的分区做dm-verity校验。

签名校验的核心逻辑：私钥签名 → 公钥验签 → 哈希比对 → 分区校验。任何一层不通过，升级立即中止，且不会切换活动槽位。

四、防回滚机制与安全启动的协同

防回滚（Anti-Rollback）通过回滚索引（rollback_index）实现。每个版本在构建时被赋予一个单调递增的索引值，写入vbmeta结构并参与AVB（Android Verified Boot）签名。设备在avb_verify阶段读取当前存储的回滚索引，若发现待启动镜像的索引低于已记录值，则拒绝启动，从而阻止攻击者刷入存在已知漏洞的旧版本。

安全启动（Verified Boot）则保证从BootROM → bootloader → boot → system的每一级都经过签名验证。防回滚是安全启动在“版本维度”上的延伸：不仅要求镜像签名合法，还要求版本不能倒退。二者结合，构成升级包可信、可验证、不可降级的完整防线。

五、典型场景：一次增量OTA的校验过程

假设设备当前运行版本V1，回滚索引为5，收到V2增量包，回滚索引为6。升级流程如下：

系统下载update.zip，校验ZIP签名与payload_properties.txt中的哈希。
update_engine读取payload.bin头部，用内置公钥验证metadata_signature。
检查metadata中的设备型号、当前build指纹是否与设备匹配。
逐条执行InstallOperation，将差分结果写入slot B的system、vendor等分区。
写入完成后，校验新分区哈希，并更新slot B的vbmeta，其中rollback_index=6。
设置slot B为活动槽，重启。bootloader验证vbmeta签名，确认6 ≥ 5，允许启动。

若此时有人尝试刷入回滚索引为4的V0包，bootloader在AVB阶段会发现4 < 5，直接拒绝启动并进入恢复模式，这就是防回滚的实际效果。

六、常见误区与复盘要点

误区	正确理解
只要ZIP签名通过就能升级	ZIP签名只保护容器，payload元数据签名和分区哈希才是升级数据可信的关键。
增量包可以跨版本随意刷	增量包绑定源版本哈希，源分区不一致会直接校验失败，必须使用对应基线包。
防回滚可以靠应用层绕过	回滚索引写入vbmeta并由bootloader校验，应用层无法篡改。
解锁bootloader后防回滚失效	解锁可关闭验证，但会清除用户数据并触发警告，量产设备默认锁定。

排障提示：若升级卡在“payload verification failed”，优先检查源版本build指纹是否与metadata一致；若卡在“rollback index mismatch”，说明目标包回滚索引低于设备当前值，需要获取更高索引的包，而不是强行降级。

掌握OTA包结构与签名机制后，就能理解为什么升级失败时设备往往仍能回到原槽位运行，也能明白降级为何在安全启动设备上如此困难。这些正是后续回滚与故障恢复策略设计的出发点。