AVB数据解析：Android verified boot 2.0 vbmeta 数据结构解析

TrustZone_Hcoco

已于 2023-08-22 15:03:29 修改

阅读量2.2k

点赞数

分类专栏： # AVB 文章标签： android AVB vbmeta

于 2023-03-01 21:39:36 首次发布

本文链接：https://blog.csdn.net/weixin_45264425/article/details/129289969

版权

AVB 专栏收录该内容

22 篇文章 66 订阅

订阅专栏

前言

验证启动（Verified Boot）是Android一个重要的安全功能，主要是为了访问启动镜像被篡改，提高系统的抗攻击能力，简单描述做法就是在启动过程中增加一条校验链。或者也可以说是信任链：

ROM code-->BootLoader-->boot image--> System 分区和 vendor 分区

由于 ROM code 和 BootLoader 通常都是由设备厂商 OEM 提供，而各家实际做法和研发能力不尽相同，为了让设备厂商更方便的引入 Verified boot 功能，Google 在 Android O上推出了一个统一的验证启动框架 Android verified boot 2.0，好处是既保证了基于该框架开发的verified boot 功能能够满足 CDD 要求，也保留了各家 OEM 定制启动校验流程的弹性。

这个弹性体现在哪里？来看看：

由于 ROM code 校验 BootLoader 的功能通常与 IC的设计相关，所以 AVB 2.0 关注的重点在 BootLoader 之后的校验流程。

BootLoader 之后系统启动所涉及的关键镜像通常包括 boot.img，system.img，Android O 的 treble Project 还引入了 dtbo 和 vendor.img。

这些 image 挨个校验可以说费时费力，而 AVB 2.0 的做法事实上十分简单，引入一个新的分区：vbmeta.img（verified boot metadata），

然后把所有需要校验的内容在编译时就计算好打包到这个分区，那么启动过程中 BootLoader 只需要校验 vbmeta.img，就能确认 vbmeta 内的数据是否可信。

再用 vbmeta 中的数据去比对 bootimg，dtbo，system,img，vendor.img 即可。

至于 OEM 是还需要放什么其他东西到 vbmeta 中，则可以由 OEM 自由定制，可以说保留了很好的客制化空间。

于是整个信任链的建立可以分为两个部分：自研的（bootrom + loader）+ 开源的AVB（boot、vendor、system。。。）

之前我们对于这个AVB的方案也有些了解，对于流程之类的也写了一部分的blog，但是对于镜像的本身没有研究过，在进行一些校验失败的场景，肯定是在所难免的需要看一下镜像的自身结构，说不定有帮助。

除了最基本的验证启动之外，AVB 2.0 还提供防止回滚的功能和对AB分区备份的支持，AVB 2.0 的详细文档可以参考：Android Verified Boot 2.0

无论是验证启动还是防止回滚，vbmeta 都是很重要的数据结构，下面对最简单的 vbmeta struct 做一个分析说明。

vbmeta struct 的结构图

在这里插入图片描述

以上 vbmeta 所包含的数据可以分成两个大的Block：

紫色色块部分为 Authentication data block 和其他为 Auxiliary data block。

当 BOARD_AVB_ALGORITHM 定义为 SHA256_RSA2048 时，默认编译出的 vbmeta.img 通常为 4KB。vbmeta.img 组成如下：

在这里插入图片描述

其中 Header 的固定长度为 0x100 个字节，Authentication data 和 Auxiliary data 的长度存储在 Header 中。

下面展开瞅瞅

一、Header 解析

可以copy一份header的数据结构体看一下：https://android.googlesource.com/platform/external/avb/+/master/libavb/avb_vbmeta_image.h

用 UE 打开 vbmeta.img，前 0x100 个字节信息如下：

在这里插入图片描述
根据 struct AvbVBMetaImageHeader，上图中的 Header 信息解析如下：

0x0 - 0x3 magic[AVB_MAGIC_LEN] magic字符串，固定为 AVB0
0x4 - 0x7 required_libavb_version_major libavb 大版本号 0x1
0x8 - 0xb required_libavb_version_minor libavb 小版本号 0x0
0xc - 0x13 authentication_data_block_size 如果选用 SHA256_RSA2048算法，则 authentication data size 固定为 0x140
0x14 - 0x1B auxiliary_data_block_size 根据 make_vbmeta_image 不同参数，长度不同，上图为 0x4C0
0x1C - 0x1F algorithm_type 由AvbAlgorithmType定义, 0x1 表示AVB_ALGORITHM_TYPE_SHA256_RSA2048
0x20 - 0x27 hash_offset hash data 在 authentication data 中的位置，通常为 0x0，hash data的具体说明会在 Authentication data 的解析中加以说明
0x28 - 0x2F hash_size hash data 的大小，使用SHA256算法时 Hash data 固定为 0x20 个字节，即 256 bits
0x30 - 0x37 signature_offset signature data 在 authentication data 中的位置，signature data紧跟在 Hash data 后面，所以 offset 在 hash 算法为 SHA256时，固定为 0x20
0x38 - 0x3F signature_size signature data 的大小，在签名算法使用 RSA2048 时，固定为 0x100个字节，即 2048 bits
0x40 - 0x47 public_key_offset 签名算法对应的公钥存储在 Auxiliary data block 中的位置，上图为 0x298
0x48 - 0x4F public_key_size 签名算法对应的公钥长度，使用RSA2048 作为签名算法时，该长度固定为 0x208， public key 部分会在 Auxiliary data block 的解析中加以说明
0x50 - 0x57 public_key_metadata_offset public key metadata 在 auxiliary data block 中的存储位置
0x58 - 0x5F public_key_metadata_size public key metadata 的大小，为 0x0 表示没有 public key metadata 数据
0x60 - 0x67 descriptors_offset descriptor 在 Auxiliary data block 中的位置，默认固定为 0x0，descriptor 的具体含义会在 Auxiliary data block 的解析中加以说明
0x68 - 0x6F descriptors_size descriptor 的长度，取决于 make_vbmeta_image 时的参数 —include_descriptor_from_image
0x70 - 0x77 rollback_index 供rollback protection 功能使用，由 make_vbmeta_image 时的参数 —rollback_index 指定，上图中为 0x0，即未对回滚保护做支持
0x78 - 0x7F reserved0[4] 16字节对齐使用，固定为四个 0x0
0x80 - 0xAF release_string[AVB_RELEASE_STRING_SIZE] avbtool 的 release 信息，48个字节，一般为 avbtool 1.0.0 xxxxx
0xB0 - 0xFF reserved[80] padding数据，保证 Header长度为 x100，内容必须全部填 0x0

二、Authentication data block 解析

Authentication data block 用于校验 vbmeta.img 的合法性和完整性，包含两部分内容：Hash data 和 signature data。

通过分析avbtool 的 Python 脚本，即可了解 hash data 和 signature data 的生成过程。

1-Hash data 的生成

hash data 是对 vbmeta 的 header 和 auxiliary data block 的 hash 计算，所以是先生成了 auxiliary data block，然后生成的 authentication data block，使用的算法由 header 中的 algorithm_type 指定，本文使用 SHA256，计算出的 hash data 长度为 0x20。截取 avbtool 的脚本代码如下：

 # Calculate the hash.
 ha = hashlib.new(alg.hash_name)
 ha.update(header_data_blob)
 ha.update(aux_data_blob)
 binary_hash.extend(ha.digest())

2-signature data 的生成

signature data 是对上文计算出的 hash data 做 padding 之后的签名，使用的算法同样由 header 中的 algorithm_type 指定，本文使用 RSA2048，计算出的 signature data 长度为 0x100。截取 avbtool 的脚本代码如下：

 # Calculate the signature.
 padding_and_hash = str(bytearray(alg.padding)) + binary_hash
 binary_signature.extend(raw_sign(signing_helper,
                                  signing_helper_with_files,
                                  algorithm_name,
                                  alg.signature_num_bytes, key_path,
                                  padding_and_hash))

有一个需要注意的地方是，hash data 和 signature data 的总长加在一起为0x120，但header 中的 authentication data block size 却为 0x140，这是因为 image 对齐需要，0x120 不能被 64 整除，所以用 0x0 填充到长度为 0x140。

三、Auxiliary data block 解析

Auxiliary data block 的内容则十分丰富，总得来说分为两个大类：AvbDescriptor 和 RSA public key。

1-AvbDescriptor 的生成

根据 avbtool make_vbmeta_image 命令支持的参数，OEM 可以自由的定制一些需要打包到 vbmeta.img 的数据，这样一段一段的二进制数据都按照AvbDescriptor 的数据结构打包进 auxiliary data block。AvbDescriptor 按照不同的 tag 分为以下几种：

typedef enum {
        AVB_DESCRIPTOR_TAG_PROPERTY,
        AVB_DESCRIPTOR_TAG_HASHTREE,
        AVB_DESCRIPTOR_TAG_HASH,
        AVB_DESCRIPTOR_TAG_KERNEL_CMDLINE,
        AVB_DESCRIPTOR_TAG_CHAIN_PARTITION,
} AvbDescriptorTag;

最常用的参数 —include_descriptor_from_image 可以将 boot.img，dtbo，recovery.img，system.img，vendor.img 的 descriptor 打包到 Auxiliary data block 中。

这些 descriptors 在 BootLoader 确认 vbmeta.img 的合法性和完整性后，可以直接被用来校验 boot.img，dtbo，recovery.img，system.img，vendor.img。

RSA public key的生成

除了这些 descriptor 之外，auxiliary data block 中还有一个重要的信息，就是 RSA public key。这个 public key 将被用来校验 authentication data block 中的 signature data。

在 avbtool make_vbmeta_image 时，必须用–key参数来指定生成 signature data 的 RSA private key，AOSP external/avb/test/data 目录下有各种供测试使用 RSA private key，格式为 PEM。avbtool 会根据 RSA private key 提取 public key 并加上 RSA key 的 header 打包进 auxiliary data block。

可以通过avbtool extract_public_key --key [priv_key_path] --output [outpubk_path] 来查看生成的 public key 信息。

其中 RSA key header 格式如下：

typedef struct AvbRSAPublicKeyHeader {
         uint32_t key_num_bits;
         uint32_t n0inv;
} AVB_ATTR_PACKED AvbRSAPublicKeyHeader;

前文中所描述 header 中的 public key size 为 0x208，即 0x8 个字节的 AvbRSAPublicKeyHeader 长度，加上 0x200个字节即 2048位的 public key 长度。

以上就是 vbmeta 除 padding 填充 0x0 之外，主要的数据信息。

以上就是全部内容，关于vbmeta镜像，如果是你想了解其校验的过程、以及镜像生成的过程，可以看一下源码，结合这个专栏其他的文章食用更佳。

感谢前辈的优秀blog，供给我们学习。

参考链接：
https://www.jianshu.com/p/a2542426bdde

TrustZone_Hcoco

关注

0
点赞
踩
14

收藏

觉得还不错? 一键收藏
打赏
0
评论
AVB数据解析：Android verified boot 2.0 vbmeta 数据结构解析

验证启动（Verified Boot）是Android一个重要的安全功能，主要是为了访问启动镜像被篡改，提高系统的抗攻击能力，简单描述做法就是在启动过程中增加一条校验链。，而各家实际做法和研发能力不尽相同，为了让设备厂商更方便的引入 Verified boot 功能，，好处是既保证了基于该框架开发的verified boot 功能能够满足 CDD 要求，也保留了各家 OEM 定制启动校验流程的弹性。这个弹性体现在哪里？
复制链接

扫一扫