TEESimulator工作原理总览拦截器如何注入keystore守护进程接管KeyMint流量【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulatorTEESimulator是一个针对 Android 硬件密钥证明Key Attestation的软件模拟模块它把 AOSP 官方的参考版 KeyMint 可信应用kmr-ta注入到系统的 keystore 守护进程中让指定 App 的密钥走软件 TEE而其余所有密钥仍由真实硬件处理。本文将用通俗的方式完整讲清 TEESimulator 拦截器注入 keystore 守护进程、接管 KeyMint 流量的工作原理。整体架构一个大脑 一个注射器 一个拦截器 一个加密引擎先记住四个角色后面的内容都围绕它们展开 角色所在目录职责控制守护进程app/大脑开机收割真实设备参数、解析配置、驱动注入、通过控制 socket 推送配置注入器injectinjector/独立二进制用 ptrace 把拦截器 .so 装进正在运行的 keystore 进程拦截器hook 库keymint/、keystore/注入后常驻的流量开关决定每个请求是模拟还是转发软件 TEERust TArust/teesim-km/真正的加密引擎生成密钥、执行运算、用 keybox 签署证明链一句话概括分工守护进程负责配置与调度拦截器负责路由Rust TA 负责算。三者之间通过一个 root 专属的 Unix socket 通信见 common/control.h拦截器本身从不读任何文件——它是纯粹的密码与路由引擎。启动时序收割 → 注入 → 推送配置开机后模块的 service.sh 会拉起 Kotlin 编写的控制守护进程然后执行三步流水线第 1 步收割Harvest设备真实身份守护进程先生成一个一次性牺牲硬件密钥从它的证明证书中读出设备的真实参数——verified-boot 状态、补丁级别、OS 版本、安全等级源码Harvester.kt。其中 verified-boot 值会被冻结因为它们是 KeyMint 派生密钥加密密钥KEK的输入一旦变化之前存的密钥将永远无法解密。第 2 步注入Inject拦截器Injector.kt 找到守护进程的 PIDAndroid 12 是keystore210/11 是keystore运行打包好的inject二进制执行inject pid lib.so entry。注入器循环监视 PID——keystore 守护进程会不定期重启每次重启都会丢掉我们的库注入器就重新打一针。第 3 步推送Push配置控制通道common/control.cpp把解析好的配置文件集合推给拦截器调用teesim_cfg_begin→ 逐条teesim_cfg_add_profile→teesim_cfg_commitcommit 时原子切换路由表切换瞬间之前的配置仍在服务。改配置即时生效无需重启 。注入器如何把 .so 装进系统进程这是整个项目最硬核的部分详见 injector/README.md。两个难点两种解法在别人的进程里调函数inject用ptrace附加到 keystore 进程改写寄存器让目标进程替我们执行函数调用返回地址被刻意指向一块可读不可执行的内存页——函数一返回就触发SIGSEGV这个受控的崩溃正是把控制权交还给我们的信号。绕过受限的加载器命名空间系统进程拒绝dlopen任何/data下的路径。inject的解法是让目标进程自己创建一个匿名 Unix socket再通过SCM_RIGHTS把文件描述符传过去最后用android_dlopen_ext(fd)从 fd 直接加载 ELF——完全跳过路径检查。加载成功后注入器在目标进程中调用库的entry()并退出守护进程继续若无其事地跑着只是身上多了我们的钩子。Android 12PLT 钩住 AIBinder_transactAndroid 12 起keystore2通过 Binder 与 KeyMint HAL 通信。最直觉的做法是在 keystore2 解析 KeyMint 服务时换掉 binder——但来不及了keystore2在开机时就缓存了 KeyMint 代理而那时我们还没被注入。所以 TEESimulator 选择拦截流量本身keymint/README.md、keymint_hook.cpp用 LSPlt 对AIBinder_transact做 PLT 钩子——所有出站的 Binder 调用都从这一个 NDK 函数经过钩子检查两件事目标 binder 的类描述符是不是IKeyMintDevice身份验证以及事务码是否在模拟清单里generateKey、begin、deleteKey等命中后把原请求的参数区搬到一个指向本地 binder 的新 parcel 上重新派发——本地设备是一个TeesimKeyMintDevice每个方法自己决定模拟还是转发没命中的调用直接走保存的原始函数real_transact对调用方完全透明。一个巧妙的细节转发到真实 HAL 时会再次经过AIBinder_transact若不处理就是无限递归。代码用一个线程局部标志tls_forwarding打断循环——正在转发的线程直接放行其他线程的 KeyMint 流量照常拦截。Android 10/11钩住 libbinder 的 ioctl旧版keystore守护进程暴露的是IKeystoreService接口详见 keystore/README.md。拦截点选在服务端对libbinder.so的ioctl做 PLT 钩子监视驱动送来的每一个BR_TRANSACTION——不管对方调用的是哪个服务方法我们都能看到属于keystore目标服务的交易其目标句柄被改写成指向本地桩事务码0xdeadbeef桩把手递给进程内处理器keystore_router.cpp目标 App 的请求由软件 TA 回答非目标请求报不是我的原样重放到真实服务。对目标 App密钥根本不接触真实 Keymaster处理器自己生成密钥对attestKey时把密钥连同 App 的 challenge 导入参考 TA由 TA 发出keybox 签名的证明链——和真实 TEE 的生成方式一致因此证书在构造上就是自洽的。模拟还是转发Profile 与两种模式配置被组织成配置档Profile一命名 bundle包含 keybox、运行模式、补丁/OS 级别、可选设备身份值以及一组目标 App格式见 README.md 与 module/config.default.json。每个目标 App 只属于一个配置档Generation 模式密钥完全在软件 TA 中铸造keybox 直接签署全新证明。TA 发出的密钥 blob 带有路由标记TEESIMkm前缀见 rust/teesim-km/src/ops.rs后续对它的begin/deleteKey等操作因此能认主无需跨调用跟踪句柄。Patch 模式默认generateKey先转发给真实 HAL——密钥确实是硬件的——然后只重签证明叶子把 root of trust 修补为 locked/Verified用 keybox 重新签名rust/teesim-km/src/resign.rs。密钥 blob 原封不动检测点更少。未列入任何配置档的 App 对模块完全透明密钥直达真实硬件没加载 keybox 时拦截器是纯粹的 no-op——配置错误只会让模块不动作而不是制造危险。关键文件索引想深入了解去看控制守护进程全流程app/README.md注入器 ptrace 细节injector/README.md、injector/utils.cppAndroid 12 拦截器keymint/README.md、keymint/keymint_router.cppAndroid 10/11 拦截器keystore/README.md、keystore/binder_interceptor.cpp软件 TA 与 keybox 签名rust/teesim-km/README.md、rust/teesim-km/src/attest.rs控制通道协议common/control.h小结TEESimulator 的核心思路可以浓缩为一句话不换服务只改流量。守护进程在 keystore 进程内装下一个路由开关开关把目标 App 的 KeyMint 请求送进进程内的参考 TA其余请求原路放行。理解这条主线——收割真值、ptrace 注入、PLT 钩子、按 App 路由、keybox 签名——你就掌握了这个项目的全部工作原理。【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
TEESimulator工作原理总览：拦截器如何注入keystore守护进程接管KeyMint流量
TEESimulator工作原理总览拦截器如何注入keystore守护进程接管KeyMint流量【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulatorTEESimulator是一个针对 Android 硬件密钥证明Key Attestation的软件模拟模块它把 AOSP 官方的参考版 KeyMint 可信应用kmr-ta注入到系统的 keystore 守护进程中让指定 App 的密钥走软件 TEE而其余所有密钥仍由真实硬件处理。本文将用通俗的方式完整讲清 TEESimulator 拦截器注入 keystore 守护进程、接管 KeyMint 流量的工作原理。整体架构一个大脑 一个注射器 一个拦截器 一个加密引擎先记住四个角色后面的内容都围绕它们展开 角色所在目录职责控制守护进程app/大脑开机收割真实设备参数、解析配置、驱动注入、通过控制 socket 推送配置注入器injectinjector/独立二进制用 ptrace 把拦截器 .so 装进正在运行的 keystore 进程拦截器hook 库keymint/、keystore/注入后常驻的流量开关决定每个请求是模拟还是转发软件 TEERust TArust/teesim-km/真正的加密引擎生成密钥、执行运算、用 keybox 签署证明链一句话概括分工守护进程负责配置与调度拦截器负责路由Rust TA 负责算。三者之间通过一个 root 专属的 Unix socket 通信见 common/control.h拦截器本身从不读任何文件——它是纯粹的密码与路由引擎。启动时序收割 → 注入 → 推送配置开机后模块的 service.sh 会拉起 Kotlin 编写的控制守护进程然后执行三步流水线第 1 步收割Harvest设备真实身份守护进程先生成一个一次性牺牲硬件密钥从它的证明证书中读出设备的真实参数——verified-boot 状态、补丁级别、OS 版本、安全等级源码Harvester.kt。其中 verified-boot 值会被冻结因为它们是 KeyMint 派生密钥加密密钥KEK的输入一旦变化之前存的密钥将永远无法解密。第 2 步注入Inject拦截器Injector.kt 找到守护进程的 PIDAndroid 12 是keystore210/11 是keystore运行打包好的inject二进制执行inject pid lib.so entry。注入器循环监视 PID——keystore 守护进程会不定期重启每次重启都会丢掉我们的库注入器就重新打一针。第 3 步推送Push配置控制通道common/control.cpp把解析好的配置文件集合推给拦截器调用teesim_cfg_begin→ 逐条teesim_cfg_add_profile→teesim_cfg_commitcommit 时原子切换路由表切换瞬间之前的配置仍在服务。改配置即时生效无需重启 。注入器如何把 .so 装进系统进程这是整个项目最硬核的部分详见 injector/README.md。两个难点两种解法在别人的进程里调函数inject用ptrace附加到 keystore 进程改写寄存器让目标进程替我们执行函数调用返回地址被刻意指向一块可读不可执行的内存页——函数一返回就触发SIGSEGV这个受控的崩溃正是把控制权交还给我们的信号。绕过受限的加载器命名空间系统进程拒绝dlopen任何/data下的路径。inject的解法是让目标进程自己创建一个匿名 Unix socket再通过SCM_RIGHTS把文件描述符传过去最后用android_dlopen_ext(fd)从 fd 直接加载 ELF——完全跳过路径检查。加载成功后注入器在目标进程中调用库的entry()并退出守护进程继续若无其事地跑着只是身上多了我们的钩子。Android 12PLT 钩住 AIBinder_transactAndroid 12 起keystore2通过 Binder 与 KeyMint HAL 通信。最直觉的做法是在 keystore2 解析 KeyMint 服务时换掉 binder——但来不及了keystore2在开机时就缓存了 KeyMint 代理而那时我们还没被注入。所以 TEESimulator 选择拦截流量本身keymint/README.md、keymint_hook.cpp用 LSPlt 对AIBinder_transact做 PLT 钩子——所有出站的 Binder 调用都从这一个 NDK 函数经过钩子检查两件事目标 binder 的类描述符是不是IKeyMintDevice身份验证以及事务码是否在模拟清单里generateKey、begin、deleteKey等命中后把原请求的参数区搬到一个指向本地 binder 的新 parcel 上重新派发——本地设备是一个TeesimKeyMintDevice每个方法自己决定模拟还是转发没命中的调用直接走保存的原始函数real_transact对调用方完全透明。一个巧妙的细节转发到真实 HAL 时会再次经过AIBinder_transact若不处理就是无限递归。代码用一个线程局部标志tls_forwarding打断循环——正在转发的线程直接放行其他线程的 KeyMint 流量照常拦截。Android 10/11钩住 libbinder 的 ioctl旧版keystore守护进程暴露的是IKeystoreService接口详见 keystore/README.md。拦截点选在服务端对libbinder.so的ioctl做 PLT 钩子监视驱动送来的每一个BR_TRANSACTION——不管对方调用的是哪个服务方法我们都能看到属于keystore目标服务的交易其目标句柄被改写成指向本地桩事务码0xdeadbeef桩把手递给进程内处理器keystore_router.cpp目标 App 的请求由软件 TA 回答非目标请求报不是我的原样重放到真实服务。对目标 App密钥根本不接触真实 Keymaster处理器自己生成密钥对attestKey时把密钥连同 App 的 challenge 导入参考 TA由 TA 发出keybox 签名的证明链——和真实 TEE 的生成方式一致因此证书在构造上就是自洽的。模拟还是转发Profile 与两种模式配置被组织成配置档Profile一命名 bundle包含 keybox、运行模式、补丁/OS 级别、可选设备身份值以及一组目标 App格式见 README.md 与 module/config.default.json。每个目标 App 只属于一个配置档Generation 模式密钥完全在软件 TA 中铸造keybox 直接签署全新证明。TA 发出的密钥 blob 带有路由标记TEESIMkm前缀见 rust/teesim-km/src/ops.rs后续对它的begin/deleteKey等操作因此能认主无需跨调用跟踪句柄。Patch 模式默认generateKey先转发给真实 HAL——密钥确实是硬件的——然后只重签证明叶子把 root of trust 修补为 locked/Verified用 keybox 重新签名rust/teesim-km/src/resign.rs。密钥 blob 原封不动检测点更少。未列入任何配置档的 App 对模块完全透明密钥直达真实硬件没加载 keybox 时拦截器是纯粹的 no-op——配置错误只会让模块不动作而不是制造危险。关键文件索引想深入了解去看控制守护进程全流程app/README.md注入器 ptrace 细节injector/README.md、injector/utils.cppAndroid 12 拦截器keymint/README.md、keymint/keymint_router.cppAndroid 10/11 拦截器keystore/README.md、keystore/binder_interceptor.cpp软件 TA 与 keybox 签名rust/teesim-km/README.md、rust/teesim-km/src/attest.rs控制通道协议common/control.h小结TEESimulator 的核心思路可以浓缩为一句话不换服务只改流量。守护进程在 keystore 进程内装下一个路由开关开关把目标 App 的 KeyMint 请求送进进程内的参考 TA其余请求原路放行。理解这条主线——收割真值、ptrace 注入、PLT 钩子、按 App 路由、keybox 签名——你就掌握了这个项目的全部工作原理。【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考