TEESimulator实现揭秘用一次性证明密钥收割设备真实Verified-Boot参数的巧妙手法【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulatorTEESimulator是一个 Android rooting 模块用于绕过硬件级密钥证明Key Attestation它把 AOSP 官方参考实现的 KeyMint 可信应用TA嵌入真实的 keystore 守护进程用你自备的 keybox 为指定应用签发证书。而整套手法能成立的前提是一次精妙的参数收割harvest——用一把用完即删的一次性证明密钥读取设备真实的 Verified-Boot 参数。本文拆解这一步的实现原理、冻结机制与无 TEE 设备的兜底方案。为什么收割真实参数是核心 trick 先理解背景应用通过 AndroidKeyStore 生成硬件密钥时TEE 会在证书中写入一串设备体检报告——RootOfTrustverified-boot key、locked 状态、verified-boot 状态、vbmeta 哈希、OS 版本、system/vendor/boot 补丁级别、甚至 IMEI 等设备身份。银行应用、Play 完整性检查等验证方正是靠这些字段判断设备是否被 root、bootloader 是否解锁。如果只伪造证书链、却填一堆假的 Verified-Boot 参数稍有交叉核对比如和系统属性对比就会穿帮。TEESimulator 的思路是证书生成流程 100% 使用官方参考实现构造上自洽设备参数则全部取自真机。缺的就是怎么拿到真机参数答案是一次性证明密钥。一次性密钥三步法生成 → 解析 → 删除整个流程在 Harvester.kt 中实现核心仅三步生成通过 AndroidKeyStore 创建一个临时 ECsecp256r1密钥别名固定为TEESimulator_AttestationCheck开启签名用途与 attestation challenge并尽可能附加设备属性证明setDevicePropertiesAttestationIncluded让证书带上品牌、型号等设备身份字段。解析取出证书链的叶子证书用 BouncyCastle 解码扩展项OID1.3.6.1.4.1.11129.2.1.17KeyDescription逐字段还原出 RootOfTrust、补丁级别、OS 版本、安全等级等全部真实参数。删除deleteEntry立即销毁这把钥匙——它从头到尾只为问TEE 一次不留任何痕迹因此得名一次性。此外还会额外做一次StrongBox 探针再生成一把 StrongBox 级临时密钥探测设备是否真有 StrongBox 硬件供后续路由决策使用。证书里到底收割到了什么参数说明verifiedBootKey/verifiedBootHash32 字节的信任根解锁设备上为全零deviceLocked/verifiedBootStatebootloader 锁定状态与校验状态OS 版本 system/vendor/boot 补丁级别证书中的 OS_VERSION、各 PATCHLEVEL 标签moduleHashtag 724APEX 模块集合的指纹brand / model / serial / IMEI / MEID 等设备身份标签两个细节值得注意IMEI、MEID、序列号不在证明证书里device-properties 证明也不携带它们所以代码绕开有包名校验的TelephonyManager直接调用IPhoneSubInfobinder 的旧接口getDeviceIdForPhone从系统读取真实值。moduleHash 优先问 keystore2 自己getSupplementaryAttestationInfo的 DER 数据做 SHA-256取不到时再解析 VbMeta.kt 同款的/apex/apex-info-list.xml按 keystore2 的 DER 编码规则重建保证哈希逐字节一致。最关键的细节冻结 verifiedBoot*为什么不能每次开机都重新收割因为verifiedBootKey/Hash 参与 KeyMint 密钥加密密钥KEK的派生——值一变之前存储的所有密钥 blob 就全部无法解密。所以 Harvester.kt 的run()采取首次成功即冻结策略完整记录持久化到harvested.json之后每次重启会重新收割易变字段补丁级别、OS 版本等但 verifiedBoot* 永远沿用首次冻结值每个字段都标注来源徽章captured / required / supplement / synthesizedWebUI 中透明可见只允许修改极少数合成字段。兜底方案设备没有可用 TEE 怎么办收割失败模拟器、TEE 损坏时Harvester 不报错而是合成一套自洽的身份安全等级填 TrustedEnvironmentTEE版本按 Android 发行版映射到合理的 KeyMint/Keymaster 版本号verifiedBootHash 自己算VbMeta.kt 直接读取vbmeta分区含 AVB footer 定位、链式分区递归复刻 libavb 的calculate_vbmeta_digest算法算出真实 AVB 摘要——比读可被任意模块篡改的系统属性可靠得多verifiedBootKey 取ro.boot.vbmeta.public_key_digest最终兜底是一个固定 SHA-256 常量代码里特意注明绝不要随机化因为 KEK 稳定性压倒一切。收割结果如何喂给模拟器收割只是起点。守护进程App.kt的完整管线是Harvester收割并冻结参数ConfigStore Resolver.kt 把参数打包成bootInfodeviceLockedtrue、verifiedBootState0等连同各 profile 的 keybox 一起解析Injector用 ptrace 将拦截库注入keystore2Android 12或keystore10/11Control客户端先校验对端确实是 keystore 进程SO_PEERCRED再把配置经本地 socket 推入格式定义见 common/control.cpp目标应用的 KeyMint 交易被 keymint_router.cpp 重定向到进程内的 Rust TArust/teesim-km/参考 TA 用这些真实参数 你的 keybox 签发完整证书链其余流量原样转发到真硬件。正因为生成流程是官方的、参数是真实的证书才经得起任何字段级交叉验证 ✅相关文件速查路径职责Harvester.kt一次性密钥收割、参数解析、冻结与兜底合成VbMeta.kt从 vbmeta 分区计算 AVB 摘要Resolver.kt收割结果 → 下发给拦截库的 bootInfoApp.kt特权控制守护进程主流程app/README.md守护进程管线与 WebUI 后端详解README.md项目总览、安装与配置一句话总结TEESimulator 没有伪造任何东西的生成过程它只是诚实地先向真 TEE 问过一次——一把用后即焚的密钥换来了让模拟证书以假乱真的全部原料。【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考