AVB源码学习（一）：AVB2.0工作原理及编译配置

TrustZone_Hcoco

已于 2023-08-16 21:47:07 修改

阅读量3.9k

点赞数 5

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

于 2022-11-23 21:39:03 首次发布

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

版权

AVB 专栏收录该内容

22 篇文章 83 订阅

订阅专栏

参考资料

感谢前辈的blog，安全相关的资料可太少了，很详细很卓越
https://blog.csdn.net/jackone12347/article/details/116241676

前言

在这个AVB源码系列学习之前，还是重新看一下这个AVB到底是什么？AVB是为什么诞生？

1、设备中的系统分区，可以通过fastboot和烧录工具进行替换掉，替换成功后，可以正常开机，这种能接受么？
2、在设备运行过程中，破坏或者篡改一部分数据，系统能知道被篡改了么？
3、google发布了security patch安全补丁版本，明确告知某个版本有缺陷，OEM厂商仍然使用有缺陷的版本 或者被攻击者使用了有缺陷的版本，系统能检查的出来么？
4、boot镜像的head头和内容被篡改了，系统能检查的出来么？
5、uboot被替换，或者system被替换，系统能检查的出来其中有一个被替换过么？

这些问题，可统归为系统安全相关的问题，从Android O版本开始，google就设计出了AVB，用来解决这些问题。

其实AVB校验的设计难点，主要是在uboot中的AVB校验，因为uboot要校验vbmeta和boot分区要校验公钥，以及lock上锁逻辑、防回滚逻辑、启动状态的逻辑，以及这些逻辑的内容存储在分区中还是RPMB中等等。
（这里不一定是uboot去校验avb，这是与系统的启动流程。）

下面开始android AVB2.0（一）工作原理及编译配置

android AVB2.0（一）工作原理及编译配置

android AVB2.0介绍，本篇主要介绍AVB2.0的概述和工作原理、配置和编译。有关AVB2.0的其他子系统的介绍，请查看android AVB2.0学习总结。

AVB2.0概述

什么是AVB？

先看一段google官方的定义：
“Verified boot is the process of assuring the end user of the integrity of the software running on a device. It typically starts with a read-only portion of the device firmware which loads code and executes it only after cryptographically verifying that the code is authentic and doesn’t have any known security flaws. AVB is one implementation of verified boot.”

AVB是确保终端用户运行的设备安全的一整套流程。
通常从设备固件的只读部分启动，使用加密的方式验证代码是真实的，且没有任何已知的安全缺陷后才执行它。AVB是验证启动的一种实现。

AVB是android的一个非常重要的安全功能，主要是防止启动镜像被篡改，提高系统整体的抗攻击的能力，在启动的过程实现一整套的校验链，确保各个启动阶段是安全启动的。

AVB在系统启动的哪些阶段工作？

AVB一般在bootloader阶段和INIT的第一阶段工作。

AVB在这两个阶段做了哪些事情？

AVB主要在Bootloader中校验vbmeta/vbmeta_system/boot/vendor_boot等分区，在init的第一阶段校验vbmeta/system/vendor等分区。

AVB工作原理大概是怎样的？

1、在bootloader或者UEFI中对vbmeta分区做校验，
2、通过vbmeta中的descriptor描述符信息，去校验boot/vendor_boot等分区，同时获取系统中的device_status(locked or unlocked 即上锁或者未上锁)、boot_status(启动状态)、vbmeta中的加密的digest/加密算法/vbmeta大小等信息，append到kernel cmdline中；
3、然后启动kernel,kernel加载ramdisk运行init进程，进入init第一阶段，进行system/vendor分区的安全校验，会利用kernel cmdline中的值，跳过boot分区的校验；同时，因为system/vendor分区比较大，对大分区会执行hashtree的数据处理，将root digest等信息通过ioctl存到kernel中，后面访问数据时文件系统会执行dm-verity校验，执行运行时动态安全校验。

AVB对分区的处理是怎样的？

知道了其工作原理后，那google是如何设计框架的，对系统分区做了哪些设计呢？

首先，google想到了这样的设计：通过增加一个独立的分区，这个分区包括了其他分区的重要校验信息；只要保证这个vbmeta的足够安全，那么vbmeta中包含的其他分区的信息也就足够安全。

其次，这些安全的信息总不能用明文吧，所以得加密。用什么加密方式比较合适呢？google采用了RSA非对称加密，对镜像数据做RSA签名，将来在启动加载镜像分区时做公钥验证签名。一级级的保证各个分区的安全性。

好了，有了这些基本内容后，我们接下就介绍vbmeta的设计细节，以及它的设计用意。

AVB细节

一、vbmeta镜像内容说明：

在整个AVB验证的过程中，需要借助于vbmeta分区，需要增加vbmeta分区和vbmeta.img镜像。

vbmeta.img镜像，编译出来的大小为4KB

可使用avbtool提供的工具查看编译出来的vbmeta.img镜像内容：

./android/external/avb/avbtool info_image --image android/out/target/product/xxx/vbmeta.img

The vbmeta image consists of three blocks:

| Header data - fixed size 256 bytes
rollback index | algorithm_type | signature offset | public_key offset

| Authentication data - variable size
hash of vbmeta.img | signature of vbmeta.img

| Auxiliary data - variable size
public key | public key metadata | descriptors of other include image

vbmeta分区描述内容及vbmeta_system.img内容：
在这里插入图片描述

Vbmeta的Descriptor的分类：

Chain Descriptor: 链式，vbmeta等分区数据少的分区。
Hash Descriptor:hash哈希，boot等小分区。
Hashtree Descriptor: dm-verity校验的大分区，像vendor

在A/B版本中的vbmeta分区描述：

在这里插入图片描述
vbmeta镜像的加解密过程简述：

● 加密过程
根据摘要信息生成private key(私钥），利用私钥extra生成public key(公钥)，同时利用私钥对vbmeta镜像进行签名(signature)，并将公钥和计算的hash写到vbmeta镜像的header中。
● 解密过程
先验证公钥是否平台签发的（公钥比对，防止vbmeta镜像的公钥和签名都被篡改掉），然后利用公钥进行解密签名。

在这里插入图片描述
AVB中镜像的加密和解密过程，以boot.img镜像为例

编译制作boot.img时进行签名时，先通过SHA-256算法得到一个散列值digest（十六进制长度为64），然后用带RSA算法的私钥加密这个digest，并生成签名后和公钥一起加在镜像的footer尾部上，编译时也会将这个digest存一份到vbmeta.img镜像中。

在bootloader中加载boot镜像时，先从vbmeta.img镜像分区中读出boot descriptor的digest，然后利用boot镜像中的公钥进行解密计算得到一个digest，和自己SHA-256计算得到的digest进行比较；

digest相等则说明boot.img是平台编译签名的，如果不相等，则boot.img可能是被篡改过的，boot启动失败。
最后再计算一次boot镜像内容的hash是否相等，hash不相等，启动也是失败。

在这里插入图片描述
所以这里也说保护这个vbmeta是很重要的。

私钥签名公钥验签的python脚本举例说明，这个看起来就更明白些了吧？

私钥签名
def rsa_private_sign(data):
    private_key = get_key('rsa_private_key.pem')
    signer = PKCS1_signature.new(private_key)
    digest = SHA.new()
    digest.update(data.encode("utf8"))
    sign = signer.sign(digest)
    signature = base64.b64encode(sign)
    signature = signature.decode('utf-8')
    return signature

公钥验证签名
def rsa_public_check_sign(text, sign):
    publick_key = get_key('rsa_public_key.pem')
    verifier = PKCS1_signature.new(publick_key)
    digest = SHA.new()
    digest.update(text.encode("utf8"))
    return verifier.verify(digest, base64.b64decode(sign))

调用
def test_sign():
    msg = ‘test content'
    sign = rsa_private_sign(msg)
    print(rsa_public_check_sign(msg, sign))    # True

二、AVB2.0的配置和编译

AVB2.0的配置，其实看完android/external/avb/README.md中的内容，估计就了解的差不多了，耐着点心看完。

我简单点归纳一下，主要分下面三个部分来介绍。

1、AVB的配置总开关

# Enable AVB 2.0
BOARD_AVB_ENABLE := true

2、AVB key配置介绍

BOARD_AVB_ALGORITHM := SHA256_RSA4096
BOARD_AVB_KEY_PATH

AVB使用的key的路径和加密算法类型。这个key可自己使用openssl命令生成即可，唯一需要注意的是使用-f4 4096参数，算法类型保持不变。为什么要用4096而不用2048？这个长度越长，越难被破解，vbmeta的public key验证时尽量用4096这个长度。

3、AVB编译镜像

镜像的编译主要有vbmeta.img、boot.img、system/vendor.img、recovery.img等。

我们一个个来看。

vbmeta.img镜像的编译

vbmeta.img需要配置物理分区大小为64KB，这个是google推荐的，实际上数据只有4KB左右。

因为vbmeta.img里面要保存boot/dtbo/system/vendor等分区的校验信息，所以编译时会依赖于这些镜像的编译。BOARD_AVB_KEY_PATH可自定义，如果没有定义则使用avb默认的test测试密钥。

下面是build/core/Makefile中编译vbmeta.img部分的脚本，其中BOARD_AVB_ALGORITHM和BOARD_AVB_KEY_PATH就是前面章节提到的需要自定义的算法和KEY路径了。

ifdef BUILDING_VBMETA_IMAGE
INSTALLED_VBMETAIMAGE_TARGET := $(BUILT_VBMETAIMAGE_TARGET)
$(INSTALLED_VBMETAIMAGE_TARGET): PRIVATE_AVB_VBMETA_SIGNING_ARGS := \
    --algorithm $(BOARD_AVB_ALGORITHM) --key $(**BOARD_AVB_KEY_PATH**) #key是私钥
$(INSTALLED_VBMETAIMAGE_TARGET): \
	    $(AVBTOOL) \
	    $(INSTALLED_BOOTIMAGE_TARGET) \
	    $(INSTALLED_VENDOR_BOOTIMAGE_TARGET) \
	    $(INSTALLED_SYSTEMIMAGE_TARGET) \
	    $(INSTALLED_VENDORIMAGE_TARGET) \
	    $(INSTALLED_PRODUCTIMAGE_TARGET) \
	    $(INSTALLED_SYSTEM_EXTIMAGE_TARGET) \
	    $(INSTALLED_ODMIMAGE_TARGET) \
	    $(INSTALLED_DTBOIMAGE_TARGET) \
	    $(INSTALLED_CUSTOMIMAGES_TARGET) \
	    $(INSTALLED_RECOVERYIMAGE_TARGET) \
	    $(INSTALLED_VBMETA_SYSTEMIMAGE_TARGET) \
	    $(INSTALLED_VBMETA_VENDORIMAGE_TARGET) \
	    $(BOARD_AVB_VBMETA_SYSTEM_KEY_PATH) \
	    $(BOARD_AVB_VBMETA_VENDOR_KEY_PATH) \
	    $(BOARD_AVB_KEY_PATH)
	$(build-vbmetaimage-target)

这个会调用external/avb/avbtool.py脚本的make_vbmeta_image函数，去完成对vbmeta.img镜像的处理，后面会专门拿一个章节来介绍这些脚本函数。

define build-vbmetaimage-target
  $(call pretty,"Target vbmeta image: $(INSTALLED_VBMETAIMAGE_TARGET)")
  $(hide) mkdir -p $(AVB_CHAIN_KEY_DIR)
  $(call extract-avb-chain-public-keys, $(AVB_CHAIN_KEY_DIR)) #生成公钥信息
  $(hide) $(AVBTOOL) make_vbmeta_image \
    $(INTERNAL_AVB_MAKE_VBMETA_IMAGE_ARGS) \ ##添加chain链式分区信息和avbpubkey公钥信息
    $(PRIVATE_AVB_VBMETA_SIGNING_ARGS) \  ##添加—algorithm和BOARD_AVB_KEY_PATH，在板卡mk中配置过的
    $(BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS) \ ##设置padding_size/set_hashtree_disabled_flag/rollback_index等参数
    --output $@

编译出来的vbmeta.img镜像，可用info_image命令进行查看。
命令：

	#./android/external/avb/avbtool  info_image  --image your_out_put_dir/vbmeta.img

boot镜像的编译
在boot.img镜像编译的时候，会调用add_hash_footer函数，也是调用的avbtool.py脚本的函数，是为了在boot.img镜像的尾部添加校验信息，为后面bootloader校验boot.img安全性做的功能，通过这个尾部的信息来判断当前启动的boot.img是否足够安全。

@build/core/Makefile
$(INSTALLED_BOOTIMAGE_TARGET): $(MKBOOTIMG) $(AVBTOOL) $(INTERNAL_BOOTIMAGE_FILES) $(BOARD_AVB_BOOT_KEY_PATH)
	$(call pretty,"Target boot image: $@")
	$(hide) $(MKBOOTIMG) $(INTERNAL_BOOTIMAGE_ARGS) $(INTERNAL_MKBOOTIMG_VERSION_ARGS) $(BOARD_MKBOOTIMG_ARGS) --output $@
	$(hide) $(call assert-max-image-size,$@,$(call get-hash-image-max-size,$(BOARD_BOOTIMAGE_PARTITION_SIZE)))
	$(hide) $(AVBTOOL) **add_hash_footer** \    ####主要是这个函数
	  --image $@ \
	  --partition_size $(BOARD_BOOTIMAGE_PARTITION_SIZE) \
	  --partition_name boot $(INTERNAL_AVB_BOOT_SIGNING_ARGS) \
	  $(BOARD_AVB_BOOT_ADD_HASH_FOOTER_ARGS)

编译完成后，可以使用xxd命令查看镜像中的内容，看一下就大致明白是怎么回事了。

# xxd boot.img | head
# xxd boot.img | tail

sysmte/vendor镜像的编译

system/vendor镜像处理是类似的，因为这两个镜像一般都比较大，不能采用和boot.img镜像的add_hash_footer，如果在开机的时候对system/vendor整个内容进行hash计算，会比较耗时，所以google设计采用了hashtree的方式，计算整体分区最后只保证root digest hash和salt，只校验这两个值速度就比较快了。（而且这个过程好像是在后台动态运行的，不影响流畅性。）

下面是脚本内容

@build/core/Makefile
	ifeq ($(BOARD_AVB_ENABLE),true)
	$(BUILT_SYSTEMIMAGE): $(BOARD_AVB_SYSTEM_KEY_PATH)
	endif
	$(BUILT_SYSTEMIMAGE): $(FULL_SYSTEMIMAGE_DEPS) $(INSTALLED_FILES_FILE)
		$(call build-systemimage-target,$@)
	
	$(INSTALLED_SYSTEMIMAGE_TARGET): $(BUILT_SYSTEMIMAGE)
		@echo "Install system fs image: $@"
		$(copy-file-to-target)
		$(hide) $(call assert-max-image-size,$@,$(BOARD_SYSTEMIMAGE_PARTITION_SIZE))
	
	ifeq ($(BOARD_AVB_ENABLE),true)
		PATH=$(INTERNAL_USERIMAGES_BINARY_PATHS):$$$$PATH \
	          $(AVBTOOL) add_hashtree_footer \  ###主要是这个函数了
	          --image $(3) \
	          --key $(BOARD_AVB_$(call to-upper,$(2))_KEY_PATH) \
	          --algorithm $(BOARD_AVB_$(call to-upper,$(2))_ALGORITHM) \
	          --partition_size $(BOARD_AVB_$(call to-upper,$(2))_PARTITION_SIZE) \
	          --partition_name $(2) \
	          $(INTERNAL_AVB_CUSTOMIMAGES_SIGNING_ARGS) \
	          $(BOARD_AVB_$(call to-upper,$(2))_ADD_HASHTREE_FOOTER_ARGS)
	endif

至于avbtool脚本如何处理hashtree数据，本篇就不介绍了，请自行看看这个函数。

好了朋友们，关于AVB2.0的工作原理和编译配置本篇就介绍到这里了。

三、vbmeta和vbemta_system，以及vbmeta_system和system等分区的关系。

vbmeta_system.img

android/build/make/core/board_config.mk  
BUILDING_SYSTEM_IMAGE := true
BUILDING_VBMETA_IMAGE := true

boardxx.mk 配置vbmeta_system.img的签名需要的内容

BOARD_AVB_VBMETA_SYSTEM := system system_ext product
BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 2

build/core/Makefile 制作vbmeta_system.img

define build-chained-vbmeta-image
  $(call pretty,"Target chained vbmeta image: $@")
  $(hide) $(AVBTOOL) make_vbmeta_image \
      $(INTERNAL_AVB_$(call to-upper,$(1))_SIGNING_ARGS) \
      $(BOARD_AVB_MAKE_$(call to-upper,$(1))_IMAGE_ARGS) \
      $(foreach image,$(BOARD_AVB_$(call to-upper,$(1))), \
          --include_descriptors_from_image $(call images-for-partitions,$(image))) \ ##遍历遍历BOARD_AVB_VBMETA_SYSTEM所有的分区描述符，并保存在vbmeta_system中
      --output $@
endef

ifdef BUILDING_SYSTEM_IMAGE
ifdef BOARD_AVB_VBMETA_SYSTEM
INSTALLED_VBMETA_SYSTEMIMAGE_TARGET := $(PRODUCT_OUT)/vbmeta_system.img
$(INSTALLED_VBMETA_SYSTEMIMAGE_TARGET): \
	    $(AVBTOOL) \
	    $(call images-for-partitions,$(BOARD_AVB_VBMETA_SYSTEM)) \   ##遍历BOARD_AVB_VBMETA_SYSTEM所有的分区镜像，并将这些镜像的信息存在vbmeta_system中
	    $(BOARD_AVB_VBMETA_SYSTEM_KEY_PATH)
	$(call build-chained-vbmeta-image,vbmeta_system)
endif
endif # BUILDING_SYSTEM_IMAGE

vbmeta.img

制作vbmeta.img，这里能看到有添加INSTALLED_VBMETA_SYSTEMIMAGE_TARGET这个vbmeta_system.img进来

这样vbmeta.img就包含vbmeta_system.img内容了

define build-vbmetaimage-target
  $(call pretty,"Target vbmeta image: $(INSTALLED_VBMETAIMAGE_TARGET)")
  $(hide) mkdir -p $(AVB_CHAIN_KEY_DIR)
  $(call extract-avb-chain-public-keys, $(AVB_CHAIN_KEY_DIR))  ##分离抽取私钥对应的公钥出来，公钥保存在镜像头部
  $(hide) $(AVBTOOL) make_vbmeta_image \
    $(INTERNAL_AVB_MAKE_VBMETA_IMAGE_ARGS) \
    $(PRIVATE_AVB_VBMETA_SIGNING_ARGS) \
    $(BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS) \
    --output $@
  $(hide) rm -rf $(AVB_CHAIN_KEY_DIR)
endef

ifdef BUILDING_VBMETA_IMAGE
INSTALLED_VBMETAIMAGE_TARGET := $(BUILT_VBMETAIMAGE_TARGET)
$(INSTALLED_VBMETAIMAGE_TARGET): PRIVATE_AVB_VBMETA_SIGNING_ARGS := \  ##vbmeta的key路径和算法类型
    --algorithm $(BOARD_AVB_ALGORITHM) --key $(BOARD_AVB_KEY_PATH)

$(INSTALLED_VBMETAIMAGE_TARGET): \
...
	$(INSTALLED_VBMETA_SYSTEMIMAGE_TARGET) \

vbmeta_system.img如何将这些分区镜像的数据进行存储的

现在我们来分解一下vbmeta_system.img，看下是如何将这些分区镜像的数据进行存储的。
执行

./external/avb/avbtool.py info_image --image out/xxx/vbmeta_system.img

Minimum libavb version:   1.0
Header Block:             256 bytes
Authentication Block:     320 bytes
Auxiliary Block:          2176 bytes
Public key (sha1):        cdbb77177f731920bbe0a0f94f84d9038axxxxxx
Algorithm:                SHA256_RSA2048
Rollback Index:           1633046400
Flags:                    0
Release String:           'avbtool 1.1.0'
Descriptors:
    Prop: com.android.build.system.os_version -> '11'
 
    Hashtree descriptor:
      Version of dm-verity:  1
      Image Size:            385806336 bytes
      Tree Offset:           385806336
      Tree Size:             3043328 bytes
      Data Block Size:       4096 bytes
      Hash Block Size:       4096 bytes
      FEC num roots:         2
      FEC offset:            388849664
      FEC size:              3080192 bytes
      Hash Algorithm:        sha1
      Partition Name:        product
      Salt:                  d29a6163c3bed5c9e9b4f141d163722369xxxxxx
      Root Digest:           c05e7f1987d2ec59ca3d39e7a5f9d8e070xxxxxx

vim vbmeta_system.img，然后输入%!xxd，就可以看到如下内容了：

00000000: 4156 4230 0000 0001 0000 0000 0000 0000  AVB0............
00000010: 0000 0140 0000 0000 0000 0880 0000 0001  ...@............
00000020: 0000 0000 0000 0000 0000 0000 0000 0020  ...............
00000030: 0000 0000 0000 0020 0000 0000 0000 0100  ....... ........
00000040: 0000 0000 0000 0670 0000 0000 0000 0208  .......p........
00000050: 0000 0000 0000 0878 0000 0000 0000 0000  .......x........
00000060: 0000 0000 0000 0000 0000 0000 0000 0670  ...............p
00000070: 0000 0000 6156 4f80 0000 0000 0000 0000  ....aVO.........
00000080: 6176 6274 6f6f 6c20 312e 312e 3000 0000  avbtool 1.1.0...
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
我把这里分割一下，前面256字节内容长度是固定的，用来存储vbmeta_system.img本身的内容

00000100: f471 409a 8786 ca2f 2d22 0f33 732c e431  .q@..../-".3s,.1
00000110: a164 95fb a21b e7dd 646e 8879 5a70 6943  .d......dn.yZpiC
00000120: af4a a9ca 55c2 7050 7201 10ca 8561 eb68  .J..U.pPr....a.h
00000130: 83b9 839b 0a80 42ac ee56 5855 720b f9be  ......B..VXUr...
00000140: b37b c224 2292 9f99 a903 9c19 a423 38d0  .{.$"........#8.
00000150: d495 9f22 b7fa b7ee af00 3b46 5680 3130  ..."......;FV.10
00000160: 1d1e 84d3 241b 6366 0121 c7db 60e6 ad0b  ....$.cf.!..`...
00000170: 9fa7 adbd 920e 1def 4a9b 5102 e359 2072  ........J.Q..Y r
00000180: dbac f867 42b9 5dd2 a7c5 5398 e6b9 5e3d  ...gB.]...S...^=
00000190: 770f ede6 0df0 cb89 31e0 f1ac ad3c 6540  w.......1....<e@
000001a0: f435 215d f298 d1d4 bbb4 91e9 6bc3 9174  .5!]........k..t
000001b0: 2377 dc5a 27e9 cc97 e5fb eb6f e6e6 9a13  #w.Z'......o....
000001c0: 3428 c340 6f0a 3a71 788c 76fe 2b4d 9da4  4(.@o.:qx.v.+M..
000001d0: ee5e 4ac4 7936 478a d9ef 10c6 2ffd 813c  .^J.y6G...../..<
000001e0: 90d8 68af 31be 9ca9 0b8e b840 8fb3 877d  ..h.1......@...}
000001f0: fcb1 cf2a d092 3c64 af9f 0d14 876a cdbc  ...*..<d.....j..
00000200: db84 c462 b32f cbc1 af4e 2be8 0c1b aa78  ...b./...N+....x
00000210: a359 263e f7a8 e3fe 1efb dcd7 7663 0206  .Y&>........vc..
00000220: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000230: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000240: 0000 0000 0000 0000 0000 0000 0000 0088  ................
说明：到这里是576字节 =256 +320  ，这里存的是Authentication签名和hash数据了，加密混淆了。
Header Block:             256 bytes
Authentication Block:     320 bytes

...
00000a30: 5c3b 9436 c18f fec9 d25a 6aa0 46e1 a28b  \;.6.....Zj.F...
00000a40: 2f51 6151 a336 9183 b4fb cda9 4034 4698  /QaQ.6......@4F.
00000a50: 8a1a 91df d92c 3abf 573a 4646 20f2 f0bc  .....,:.W:FF ...
00000a60: 315e 29fe 5890 325c 6697 999a 8e15 23eb  1^).X.2\f.....#.
00000a70: a947 d363 c618 bb8e d220 9f78 af71 b32e  .G.c..... .x.q..
00000a80: 0889 a1f1 7db1 30a0 e61b bd6e c8f6 33e1  ....}.0....n..3.
00000a90: dab0 bd16 41fe 076f 6e97 8b6a 33d2 d780  ....A..on..j3...
00000aa0: 036a 4de7 0582 281f ef6a a975 7ee1 4ee2  .jM...(..j.u~.N.
00000ab0: 955b 4fe6 dc03 b981 0000 0000 0000 0000  .[O.............
这些数据就是辅助数据了，存的是vbmeta_system包含的system等分区的descriptor信息了
Auxiliary Block:          2176 bytes

vbmeta镜像中包含了vbmeta_system镜像的信息

分析完了vbmeta_system.img，再回过头来看vbmeta.img，可以看到vbmeta镜像中包含了vbmeta_system镜像的信息。

$ ./external/avb/avbtool.py info_image --image out/xxx/vbmeta.img

Minimum libavb version:   1.0
Header Block:             256 bytes
Authentication Block:     576 bytes
Auxiliary Block:          3136 bytes
Public key (sha1):        6fc544ec428a010fa304a398f3a8fe62c1xxxxxx
Algorithm:                SHA256_RSA4096
Rollback Index:           0
Flags:                    0
Release String:           'avbtool 1.1.0'
Descriptors:
    Chain Partition descriptor:
      Partition Name:          vbmeta_system
      Rollback Index Location: 2
      Public key (sha1):       cdbb77177f731920bbe0a0f94f84d9038axxxxxx   ###公钥的sha1值和前面vbmeta_system Public key (sha1)值是相同的
    Prop: com.android.build.boot.fingerprint -> xxx:userdebug/test-keys'
    Prop: com.android.build.boot.os_version -> '11'
    Hash descriptor:
      Image Size:            26800128 bytes
      Hash Algorithm:        sha256
      Partition Name:        boot
      Salt:                  a55c2fa693f09b24bf261f2cae3c0290d37aad3a63a78f7ed673a2d656xxxxxx
      Digest:                f352ae2862e12e85c921394448fc47585a01ec29a77c6d8dea8c6f9e33xxxxxx
      Flags:                 0
...

一般android设备在uboot阶段加载校验vbmeta本身和校验boot/vendor_boot/dtbo等分区，在android init阶段启动的时候，不再需要校验vbmeta本身了，但是会加载vbmeta整个分区(此接口libavb静态库中有实现)，这样能读到vbmeta_system的信息。

所以，init启动AVB校验的第一个分区是system分区。
代码处理在first_stage_mount.cpp中的SetUpDmVerity函数

bool FirstStageMount::MountPartition(const Fstab::iterator& begin, bool erase_same_mounts,
                                     Fstab::iterator* end) {
...
//AVB校验
    if (!SetUpDmVerity(&(*begin))) {
        PLOG(ERROR) << "Failed to setup verity for '" << begin->mount_point << "'";
        return false;
    }

    LOG(INFO) << "MountPartition SetUpDmVerity done.";
//mount挂载
    bool mounted = (fs_mgr_do_mount_one(*begin) == 0);
...
}

SetUpDmVerity会读fstab：
会先判断fstab中是否有avb_keys=/avb/q-gsi.avbpubkey:/avb/r-gsi.avbpubkey:/avb/s-gsi.avbpubkey的flag

然后判断fstab中是否有avb=vbmeta_system的flag
如果都没有，则没有开启AVB

bool FirstStageMountVBootV2::SetUpDmVerity(FstabEntry* fstab_entry) {
    AvbHashtreeResult hashtree_result;

    // It's possible for a fstab_entry to have both avb_keys and avb flag.
    // In this case, try avb_keys first, then fallback to avb flag.
    if (!fstab_entry->avb_keys.empty()) {
        if (!InitAvbHandle()) return false;
        // Checks if hashtree should be disabled from the top-level /vbmeta.
        if (avb_handle_->status() == AvbHandleStatus::kHashtreeDisabled ||
            avb_handle_->status() == AvbHandleStatus::kVerificationDisabled) {
            LOG(ERROR) << "Top-level vbmeta is disabled, skip Hashtree setup for "
                       << fstab_entry->mount_point;
            return true;  // Returns true to mount the partition directly.
        } else {
            auto avb_standalone_handle = AvbHandle::LoadAndVerifyVbmeta(
                    *fstab_entry, preload_avb_key_blobs_[fstab_entry->avb_keys]);
            if (!avb_standalone_handle) {
                LOG(ERROR) << "Failed to load offline vbmeta for " << fstab_entry->mount_point;
                // Fallbacks to built-in hashtree if fs_mgr_flags.avb is set.
                if (!fstab_entry->fs_mgr_flags.avb) return false;
                LOG(INFO) << "Fallback to built-in hashtree for " << fstab_entry->mount_point;
                hashtree_result =
                        avb_handle_->SetUpAvbHashtree(fstab_entry, false /* wait_for_verity_dev */);
            } else {
                // Sets up hashtree via the standalone handle.
                if (IsStandaloneImageRollback(*avb_handle_, *avb_standalone_handle, *fstab_entry)) {
                    return false;
                }
                hashtree_result = avb_standalone_handle->SetUpAvbHashtree(
                        fstab_entry, false /* wait_for_verity_dev */);
            }
        }
    } else if (fstab_entry->fs_mgr_flags.avb) {
        if (!InitAvbHandle()) return false;
        hashtree_result =
                avb_handle_->SetUpAvbHashtree(fstab_entry, false /* wait_for_verity_dev */);
    } else {
        return true;  // No need AVB, returns true to mount the partition directly.
    }

那么fstab中为什么要添加avb_keys=/avb/q-gsi.avbpubkey公钥的flag呢？这种设计是要解决什么问题？

system分区的公钥和签名信息都在了vbmeta_system中了，为什么还需要在first_stage_ramdisk中保存一份avbpubkey呢？
我们看一下编译产物：

android/out/target/product/xxx/recovery/root/first_stage_ramdisk/avb/r-gsi.avbpubkey

再回过头来看一下extract-avb-chain-public-keys的定义，从定义的内容来看，应该是各partition的公钥了，形式为partition.avbpubkey

define extract-avb-chain-public-keys
  $(if $(BOARD_AVB_BOOT_KEY_PATH),\
    $(hide) $(AVBTOOL) extract_public_key --key $(BOARD_AVB_BOOT_KEY_PATH) \
      --output $(1)/boot.avbpubkey)
  $(if $(BOARD_AVB_VENDOR_BOOT_KEY_PATH),\
    $(AVBTOOL) extract_public_key --key $(BOARD_AVB_VENDOR_BOOT_KEY_PATH) \
      --output $(1)/vendor_boot.avbpubkey)
  $(if $(BOARD_AVB_SYSTEM_KEY_PATH),\
    $(hide) $(AVBTOOL) extract_public_key --key $(BOARD_AVB_SYSTEM_KEY_PATH) \
      --output $(1)/system.avbpubkey)

而我们这里是r-gsi.avbpubkey，那r-gsi表示什么？搞过XTS的应该知道是google搞的通用系统镜像，是需要烧录对应的system.img的。
所以，在fstab中配置的avb_keys=/avb/xxx.avbpubkey，应该是为了过GSI测试用的，在VTS测试时，会往data分区push google签名对应的public key。
（这个末尾这点就是说这个小尾巴的内容是为了通过谷歌测试。）

（销往海外的Android电视，若想使用Google的应用程序和服务，如YouTube、Gmail、Google Play Store等，必须通过此认证，获得Google授权。通过Google XTS TV认证测试。）