TEESimulator安全与反检测设计无Keybox即惰性、递归防护与检测点消除的完整盘点【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulatorTEESimulator是一个 Android 密钥认证模拟Key Attestation Simulation项目它在真实的 keystore 守护进程内部运行一个软件版 KeyMint让指定应用拿到由用户自有 Keybox 签发的证书链而其他所有密钥仍留在真实硬件上。正因它寄生在系统安全进程里TEESimulator 反检测设计与安全设计比功能本身更值得细读——一旦留痕被识别后果不是崩溃而是被看穿。本文完整盘点它的三大防线无Keybox即惰性、递归防护与检测点消除。为什么模拟器的第一原则是失败要安全 ️TEESimulator 注入的是系统级的keystore2Android 12或keystore10/11守护进程。这类环境里的任何 bug 都有双重风险风险普通应用的后果本项目的后果功能 bug应用崩溃用户重装密钥体系损坏数据永久丢失行为异常无人在意被检测方判定环境异常所以项目的第一设计哲学写在 README.md 里没有配置时的模块是惰性的inert而不是危险的hazard。下面按三层防线逐一拆解。防线一无Keybox即惰性——不装钥匙就只是块砖 这是整套TEESimulator 安全设计中最核心的一条拦截器加载 ≠ 拦截器工作。1. Keybox 永远不随模块分发模块只带默认配置module/config.default.json私钥所在的keybox.xml必须由用户自行放入/data/adb/teesim/。没有它拦截器什么都不做——官方原话a misconfigured module is inert rather than a hazard。2. 入口即全转发状态注入库的入口函数 keymint/keymint_entry.cpp 只做三件事启动控制服务器、以未配置状态安装钩子、等待控制守护进程推送配置。在收到有效配置推送之前所有 Binder 调用原路转发真实硬件一个字节都不动。3. 配置有严格的校验门槛守护进程会验证 Keybox 必须同时包含 RSA 与 ECDSA 密钥、证书链长度 ≥ 2任何一项不满足都拒绝推送。配置错误不会半工作只会整体惰性。4. 启动竞态窗口也不破坏密钥存在一个微妙窗口keystore2 在开机后一秒内就开始用密钥而守护进程还在收割设备参数。如果此时对我们创建的密钥返回硬错误应用会把别名删掉重建——静默销毁用户所有已加密数据。keymint/keymint_router.cpp 中的WaitForDefaultTa选择阻塞至多 8 秒等待配置超时后返回HARDWARE_NOT_YET_AVAILABLE稍后再来而非密钥损坏且用静态标志保证只停一次避免拖垮 binder 线程池。 一句话先证明你能正确签名才允许你碰流量。防线二递归防护——转发不能变成死循环 ♻️拦截器需要把目标应用的请求截下来把非目标请求放过去。而放过去本身又是一次 Binder 调用——会再次穿过同一个钩子。不处理就是无限递归。TEESimulator 用三层机制保证转发绝对安全线程局部转发标志核心手段keymint/keymint_hook.cpp 中有一个thread_local布尔量tls_forwarding。路由器每次调用真实 HAL 前用 RAII 风格的ForwardGuard把它置位钩子发现标志为真就立刻直通、不再拦截。选线程局部而非全局是因为其他线程上无关的 KeyMint 流量仍须被拦截——全局标志会误伤。自有设备黑名单第二道保险本地伪装设备TeesimKeyMintDevice与真实 KeyMint 共享同一个接口描述符会被身份检查误认。项目用独立集合g_our_devices记录这是我们造的设备从源头排除。注意它用独立互斥锁热路径上的查询绝不能被设备构造时的阻塞式 IPC 卡住且锁顺序严格固定避免死锁。负缓存与非我所有回落g_local_for_proxy对不包装的 proxy 缓存nullptr如 SOFTWARE 级别避免每次调用都重新探测Android 10/11 侧的 keystore/keystore_router.cpp 则用not mine → 原样重放给真实服务的回落机制被拒交易零改动地继续走真实路径。 完整推理过程见 keymint/README.md 的Recursion guard一节。防线三检测点消除——把可被观察到的差异清零 ️反检测的本质每个与真实设备不一致的行为都是一个检测点。TEESimulator 的设计几乎处处围绕少留一个差异展开。补丁模式默认少模拟多转发module/config.default.json 的默认模式是patchgenerateKey直接转发给真实硬件密钥真正硬件背书、认证内容含真实版本与 tee-enforced 授权项目只在最后对证书叶子重签名换 Keybox 根、修正 root of trust实现于 rust/teesim-km/src/resign.rs。硬件路径没被模拟检测面自然最小。仅在硬件不可用时才退化为全量生成模式。只读系统属性绝不写入拦截器需要感知设备的 RKP远程密钥配置策略来决定是否拒绝目标应用的 attestation key 查询。keymint/keymint_hook.cpp 中注释写得很直白We only ever READ the property — a global write would be an obvious detection point.读策略、改行为但从不修改系统可见状态。注入不留痕injector/main.cpp 的注入流程处处隐藏踪迹fd 传递优先通过SCM_RIGHTS 抽象 Unix 套接字把库的 fd 送进目标进程再dlopen——抽象地址没有文件系统条目磁盘上查无此物Staging 兜底秒删fd 传递失败时把库临时拷到/data/local/tmpdlopen成功后立即删除文件内核保留已映射的 inodehide tracks不 dlclose库常驻且只导出entry一个符号keymint/exports.map其余全部隐藏既防符号冲突也缩小被dl_iterate_phdr之类手段枚举到的面。钩子范围最小化安装钩子时优先只探测主可执行文件的 PLT而不是扫描全部.so——避免动态库补丁工具对每个无关库打印 symbol not found 警告。日志噪音本身就是检测点这条优化直接来自keystore2 的 binder 客户端就链接在主程序里的事实。设备身份采一次、冻死它 root of trustverified-boot 状态、vbmeta 公钥等被刻意设为不可配置守护进程启动时用一个一次性硬件密钥收割真实值并冻结app/src/main/java/org/matrix/teesim/Harvester.kt。伪造的根信任是签名链里最容易被交叉验证戳穿的矛盾点而真实根信任 真实补丁级别 自有 Keybox 链构成的证书在结构上自洽——这正是项目 README 强调的 internally consistent by construction。如何验证这些设计在工作 ✅WebUIKernelSU/APatch 下可用可查看收割状态、注入状态与守护进程实时日志恢复路径su -c kill $(pidof keystore2)杀掉守护进程即可得到干净实例——新进程在无注入状态下启动直到模块重新注入惰性自证删掉 keybox.xml 后保存配置所有应用行为应与未装模块时完全一致这就是无Keybox即惰性的直观验收。总结三大防线一览防线核心机制防住什么无Keybox即惰性不随模块分发私钥 未配置全转发 严格校验配置错误造成的意外行为与数据破坏递归防护tls_forwarding线程局部标志 自有设备黑名单 负缓存转发引发的无限递归、并发误伤检测点消除补丁模式、只读属性、注入不留痕、冻结真实身份每个与真机不一致的可观察差异这套设计的启示在于安全不是加一个开关而是把错误状态 安全状态写进架构——惰性默认、最小干预、零留痕。对想研究 Android 密钥认证原理与反检测工程实践的开发者来说keymint/README.md 与 injector/README.md 是两篇密度极高的工程笔记值得通读。【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考