刷机相关的Android的安全

本blog初看比较杂乱，对于不熟悉的人来说需要看的网址较多，这里主要是我的调试总结，原理和流程在每个小节都有贴地址，要熟悉肯定是要一个一个去看的（自己再写原理流程误读可能更多，官网有相关内容以官网为准，------没错我懒！）。

Android安全内容非常多，可以登录https://source.android.com/security查看。这里以刷机的角度去看相关的安全措施。日志里可以看到设备从上电开机就有保护手段了，这里依次简述secure boot、verify boot、dm-verity、SELinux，看它们如何保证设备刷机烧录镜像、所有运行的程序都是OEM自己的。

1、secure boot

2、verify boot

3、dm-verity

4、SELinux

1、secure boot

原理https://blog.csdn.net/blue_rush/article/details/55047082

实现步骤https://blog.csdn.net/tq501501/article/details/94719382

以硬件验证MP大部分镜像，和aboot的镜像emmc_appsboot.mbn。如果看到secure boot：yes请不要随意刷aboot了。利用aboot的修改破解需谨慎，刷错的话，设备会挂掉而且无法挽回的哦。硬件加密对于设备安全是质的提升，看到上面原理和实现步骤，OEM应该保护好自己的签名。目前这种情况只有硬件短接，QFIL刷原签名的版本能恢复。

2、verify boot

这个验证在aboot中，验证vbmeta公钥，并立即验证boot和dtbo的hash，进入kernel后，挂载时dm-verity验证比较大的分区system和vendor。

原理https://source.android.com/security/verifiedboot/verified-boot

流程和各种验证状态还是看官网https://source.android.com/security/verifiedboot/boot-flow，这里不补充了。

以前调试研究步骤：

unlock：orange状态1.1、vbmeta.img镜像验证system vendor dtbo boot 分区。 替换vbmeta.img后，系统起不来。日志[  107.567167] device-mapper: verity-fec: 259:5: FEC: recursion too deep1.2、system和vendor 在adb disable-verity并修改后，再adb enable-verity无法启动2.1、替换dtbo和boot能够起来2.2、替换vendor后起不来，关闭dm-verity后起来fastboot --disable-verity --disable-verification flash vbmeta D:\download\hon450-fastboot-214.02.00.0001E\AP\vbmeta.img分析：vbmeta.img与vendor system分区hash校验不对。替换的dtbo与boot为未替换密钥的dtbo与boot并且为lockLock：green状态1、替换boot与dtbo正常启动2、替换使用device/honeywell/common/security/verity.pk8密钥编译的vbmetaimage后未启动。[1170] avb_vbmeta_image.c[1170] :[1170] 226[1170] : ERROR: [1180] Hash does not match![1180] avb_slot_verify.c[1180] :[1180] 539[1180] : ERROR: [1180] vbmeta_a[1180] : Error verifying vbmeta image: [1190] HASH_MISMATCH[1190][1190] ERROR: Device State Locked, AvbSlotVerify returned ERROR_VERIFICATION[1200] ERROR: Unable to find any bootable slot[1200] No bootable slots found enter fastboot mode[1210] VB2: boot state: red(3)[1210] Boot State is : 3[1220] Your device is corrupt. It can't be trusted and will not boot.3、替换原dtbo与boot，依然无法启动，日志同上4、擦除devinfo(目的是解锁)后启动，日志Error verifying vbmeta image:依然存在5、锁住后替换原vbmetaimagefastboot --disable-verity --disable-verification flash vbmeta D:\download\*\AP\vbmeta.img 依然无法启动fastboot  flash vbmeta D:\download\*\AP\vbmeta.img 正常启动分析：替换的dtbo与boot为未替换密钥的dtbo与boot，替换的vbmeta签名不对，换原dtbo与boot无影响，擦除devinfo后解锁设备，不验证vbmeta，锁住后，关闭dm-verity替换原vbmeta依然不启动是hash值不对。擦除devinfo后，解决开机跳转EIO问题。

O我是参照Verified Boot | 罗明貌的博客来设置，P有些不同，下面是P使用的总结：

--------------------------------------------------------------LK Replace the verification key.                                               //aboot里面替换验证密钥，同时AVB的签名需要改为自己的密钥verity.pem1、Extract the private key from the pk8 certificate  //pk8证书生成私钥openssl pkcs8 -inform DER -nocrypt -in verity.pk8 -out verity.pem2、Private key to binary file                                                   //私钥转二进制文件avbtool extract_public_key --key verity.pem --output verity.bin3、Convert binary file contents into header file array         //二进制文件转头文件，工具bin2CHeader制作参考https://blog.csdn.net/morixinguan/article/details/53700698./bin2CHeader verity.bin OEMPublicKey.h4、copy and replacecp -f OEMPublicKey.h $(ANDROID_BUILD_TOP)/bootable/bootloader/lk/platform/msm_shared/avb/OEMPublicKey.h5、replace AVB keyBOARD_AVB_ALGORITHM := SHA256_RSA2048BOARD_AVB_KEY_PATH := device/***/common/security/verity.pem--------------------------------------------------------------User use or replace key.                                                           //使用和替换//如何输入用户密钥(以支持其它密钥签名的镜像，实例就是GSI测试刷入google镜像)Original key fileexternal/avb/test/data/testkey_rsa4096.pemdevice/***/common/security/sourcekey_rsa4096.binLK command eg：fastboot flash avb_custom_key sourcekey_rsa4096.binfastboot erase avb_custom_key--------------------------------------------------------------Reference website                                                        //相关网站AVB2.0:https://source.android.com/security/verifiedboothttps://android.googlesource.com/platform/external/avb/+/master/README.mdhttps://blog.csdn.net/rikeyone/article/details/80606147Signature, encryption, certificate:https://www.cnblogs.com/Caersi/p/6720789.htmlhttps://www.jianshu.com/p/15b1d935a44bbin2CHeader:https://blog.csdn.net/morixinguan/article/details/53700698

可以使用fastboot flashing unlock来解锁设备，然后该设备可以刷入其它签名的boot.img，注意解锁和锁定都会恢复出厂。android上层开发者选项还有oem unlock控制栏，其作用是来控制是否允许输入fastboot flashing unlock来解锁，小米和华为有通过lisence控制该选项。

深入下，如果设备没有开启RPMB，设备锁状态的信息将存在devinfo分区中，其结构见devinfo.h文件。

struct device_info{unsigned char magic[DEVICE_MAGIC_SIZE];bool is_unlocked;bool is_tampered;bool is_unlock_critical;bool charger_screen_enabled;char display_panel[MAX_PANEL_ID_LEN];char bootloader_version[MAX_VERSION_LEN];char radio_version[MAX_VERSION_LEN];bool verity_mode; // 1 = enforcing, 0 = logginguint64_t rollback_index[MAX_VB_PARTITIONS];uint32_t user_public_key_length;uint8_t user_public_key[MAX_USER_KEY_SIZE];};

下图是读取的devinfo分区的bin文件

设备锁定状态is_unlocked在第17位字节，hexedit可修改该字节，通过QFIL或fastboot刷入devinfo分区来解锁设备，这种骚操作可以跳过恢复出厂（开启了RPMB将不能修改，可加打印输出rpmb存储的devinfo结构体数据）。提示下，release版本应该关闭fastboot和紧急下载。

如果secure boot 是enable，AVB>=2.0; 设备的相关信息会存储到emmc的安全区域（RPMB区域），其功能与devinfo一样，能够存储设备状态信息、rollback回滚信息、avb的key，但是设备全擦也清除不了RPMB内数据，无法再使用上述方法去破解。avb的key的写入方式fastboot flash avb_custom_key sourcekey_rsa4096.bin, 作用是增加自己的key，可以刷这个key的boot镜像。如果使用自己key的boot镜像，设备锁定状态开机状态是黄。

如果要刷镜像调试，QFIL刷与出厂一致的secure boot签名的特定aboot即可，特定aboot的修改参考如下：

void read_device_info(device_info *dev)write_device_info(info);}
+               info->is_unlocked = 1;
+               write_device_info(info);memcpy(dev, info, sizeof(device_info));free(info);}

3、dm-verity

dm-verity功能实现在kernel中，hash树在vbmeta中，启动到kernel在挂载system/vendor时同步验证，所以验证耗时可忽略。具体实现见官网 https://source.android.com/security/verifiedboot/dm-verity

要使用verify boot和dm-verity安全功能，编译时只需要开启相关配置，如果深入还需要使用avbtool工具

https://android.googlesource.com/platform/external/avb/+/master/README.md#Using-avbtool

本想举例，发现官网上都有，build/make/core/Makefile里面也有，查看编译输出更直观，下面是编译输出的。

添加hash

avbtool add_hash_footer --image /tmp/tmpDSOYl_ --partition_size 67108864 --partition_name boot --salt 035d39c3a91730f4b0ae97452d28798e502b696247b56758d4062956720e492d

添加hash树

avbtool add_hashtree_footer --partition_size 2820669440 --partition_name system --image /media/sdd/home/dongyi/source_code/***/out/target/product/***/obj/PACKAGING/target_files_intermediates/***/IMAGES/system.img --key external/avb/test/data/testkey_rsa2048.pem --algorithm SHA256_RSA2048 --salt 035d39c3a91730f4b0ae97452d28798e502b696247b56758d4062956720e492d --prop com.android.build.system.security_patch:2019-11-05 --rollback_index 0 --setup_as_rootfs_from_kernel

证书取公钥

avbtool extract_public_key --key external/avb/test/data/testkey_rsa2048.pem --output /tmp/avbpubkey-46XJqd/system.avbpubkey

制作vbmeta镜像

avbtool make_vbmeta_image --output /media/sdd/home/dongyi/source_code/***/out/target/product/***/obj/PACKAGING/target_files_intermediates/***/IMAGES/vbmeta.img --key device/honeywell/common/security/verity.pem --algorithm SHA256_RSA2048 --include_descriptors_from_image /media/sdd/home/dongyi/source_code/***/out/target/product/***/obj/PACKAGING/target_files_intermediates/***/IMAGES/vendor.img --include_descriptors_from_image /media/sdd/home/dongyi/source_code/***/out/target/product/**/obj/PACKAGING/target_files_intermediates/***/IMAGES/boot.img --chain_partition system:2:/tmp/avbpubkey-46XJqd/system.avbpubkey --include_descriptors_from_image /media/sdd/home/dongyi/source_code/***/out/target/product/***/obj/PACKAGING/target_files_intermediates/***/IMAGES/dtbo.img --padding_size 4096

查看vbmeta信息

avbtool info_image --image vbmeta.img

vbmeta.img镜像结构分析可以参照https://www.jianshu.com/p/a2542426bdde。

fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img和adb disable-verity都是关闭dm-verity，实际是改变其中标志位。BC查看vbmeta.img镜像，其中下图左边是开启dm-verity，右边是关闭dm-verity。GSI中带的vbmeta.img就是关闭了dm-verity，关闭后其它分区的hash校验信息就无所谓了。

这里添加hash衍生一个问题，$OUT底下的system镜像与target-file里面的system镜像不一致，导致fastboot刷$OUT底下的system镜像无法OTA差分升级（可能只是高通平台存在该问题）。建议OTA包编译后target-file里面的system镜像替换$OUT底下的system镜像。制作OTA里面加上下面这句解决，其中BUILT_TARGET_FILES_DIR为target_file文件夹。

$(shell cp -f $(BUILT_TARGET_FILES_DIR)/IMAGES/system.img $(INSTALLED_SYSTEMIMAGE))

android Q版本新增APEX模块，该模块将支持google部分应用或者模块的快速更新（不用全包或差分包的升级），这些模块/应用的签名也保存在vbmeta中，详细参考官网网址https://source.android.com/devices/tech/ota/apex#vbmeta_signing。也就是vbmeta在启动流程中，在安全方面起到承上启下作用外，还会存储google/oem的证书密钥。换句话说存储证书密钥的功能，实现了dm-verity和应用快速更新。

前面提到过，这几个验证开启后，aboot，boot，dtbo，vbmeta，system，vendor分区都保护到了，很难破解。

4、SELinux

到dm-verity，所有需要保护的镜像都已经连起来了，应用层则需要东西限制关键文件的读写。SELinux是Linux的一个安全子系统，制定SELinux规则，在OTA升级中(recovery和update-engine可执行程序升级)只有指定类型工具才能读写数据块，保护设备安全。

SELinux的android官网概览https://source.android.com/security/selinux，可查看子链接获取更多内容。SELinux的bolg

https://blog.csdn.net/Innost/article/details/19299937#/notebooks/29547787/notes/_blank https://www.cnblogs.com/gailuo/p/5041034.html

SELinux使用https://www.jb51.net/article/128214.htm。Google源码自带相关工具或命令，例如sepolicy-analyze，audit2allow，seinfo，sediff，sesearch，ls -Z，make precompiled_sepolicy。

获取日志和规则文件adb shell dmesg | findstr avc: > tmp\avc.txtadb pull /sys/fs/selinux/policy tmp\policyadb pull /vendor/etc/selinux/precompiled_sepolicy  tmp\precompiled_sepolicy(在O之前，SELinux规则文件是放在boot.img 的根目录中，当然现在更合理)sepolicy-analyze tmp/precompiled_sepolicy dups                          查看规则sepolicy-analyze tmp/policy dups                                              查看规则cat tmp/avc.txt |audit2allow -p tmp/policy > tmp/tmp.te   根据日志生成规则设备中ls -Z查看文件selinux的类型SELinux快速调试替换关键文件，此方法适用于allow条目修改添加。如果有type新定义或修改，需要替换/sys/fs/selinux/policy，建议全刷。make precompiled_sepolicy  //高通 vendor的规则 单编
make selinux_policy_system    //google system的规则 单编
make sepolicy.recovery    //recovery的规则 单编
make selinux_policy     //单编
更多请在源码aosp/system/sepolicy文件夹中搜索LOCAL_MODULEadb root;adb remount;adb push S:\source_code\***\out\target\product\***\vendor\etc\selinux\precompiled_sepolicy /vendor/etc/selinuxneverallow处理方法，查看\system\sepolicy\public，节点或者程序缩小权限，再就是改类型。seinfo sediff sesearch工具这里不介绍了。

5、其它安全

重要事说三遍，日志里可以看到设备从上电开机就有保护手段了，按照开机流程，secure boot保护aboot、verify boot保护boot和vbmeta、dm-verity保护system和vendor、SELinux只允许OTA工具才能操作这些关键分区，这就保证刷入设备的镜像、关键分区的程序都是OEM自己的。 release版本使用上面提到的这几个安全措施，加上userdata加密、防回滚、平台签名等等，设备很难破解。
但是，对于有心破解的人来说，任何一个安全BUG，都可以归类，然后按照类别扩大漏洞，一步一步攻克。加上android的开源，任何一个漏洞，利用得当都能致命。

所以软件上安全都打开并不够，这时再来看google安全方案https://source.android.com/security/best-practices，里面包括了运营、网络、硬件等等安全建议。

相关内容网上到处都是，再有问题可以留言讨论。