企业官网建设流程全解析

TEESimulator配置深度解析：config.json Profile体系与补丁级别迷你语言完整参考

【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator

如果你正在使用TEESimulator这个 Android 硬件级密钥认证（Key Attestation）软件模拟模块，那么最重要的配置文件就是位于/data/adb/teesim/目录下的 config.json。本文带你完整看懂 TEESimulator 配置文件的Profile 体系、每个字段的作用，以及用来管理安全补丁级别的"迷你语言"（mini-language）——读完这篇指南，你可以不重启设备、实时完成全部配置。

一、TEESimulator 是什么？配置文件放在哪？

TEESimulator 是一个运行在 Root 环境（Magisk / KernelSU / APatch）下的模块：它把 AOSP 官方参考实现的 KeyMint 可信应用（kmr-ta）嵌入真实的 keystore 守护进程内部，为你指定的应用签发由用户 keybox 签名的认证证书，而其他所有应用的密钥仍留在真实硬件中。

整个配置只涉及一个目录和几个文件：

所有路径常量都定义在 Const.kt 中，其中DATA_DIR = /data/adb/teesim是守护进程唯一拥有的配置状态目录。

💡 守护进程会监听配置变化并热更新——编辑config.json后无需重启，配置会立即重新解析并推送到 keystore（参见 ConfigStore.kt 中的watch()方法）。

二、config.json 顶层结构：version 与 profiles

官方默认配置见 config.default.json，结构如下：

{ "version": 1, "profiles": { "default": { "keybox": "keybox.xml", "mode": "patch", "patchLevel": { "system": "today", "vendor": "YYYY-MM-05", "boot": "YYYY-MM-05" }, "osVersion": "", "brand": "", "device": "", "product": "", "manufacturer": "", "model": "", "serial": "", "imei": "", "meid": "", "imei2": "", "apps": ["com.google.android.gms", "com.android.vending"] } } }

• version：目前只接受1，其他值会直接校验失败；
• profiles：一个"命名 Profile 映射表"，每个 Profile 是一组完整配置包：keybox、运行模式、补丁/系统版本、设备身份值、目标应用列表。

核心规则：每个被目标化的应用只能属于恰好一个 Profile。同一个包名出现在两个 Profile 中会报ConfigException，防止路由冲突（见 ConfigStore.kt 的seenApps去重逻辑）。

三、Profile 字段逐项详解

3.1keybox：签名证书链（必填）

相对/data/adb/teesim/的 keybox 文件路径。它必须包含RSA + ECDSA（P-256）两把私钥，各带 PEM 证书链。不同 Profile 可以指向不同 keybox，从而实现"不同应用用不同证书签名"。

3.2mode：patch 还是 generation？

即使配置为patch，当对应安全级别的硬件不可用时，路由层仍会自动降级到generation（见 Resolver.kt 的注释说明）。

3.3apps：目标应用的三种写法

这是 TEESimulator 配置中最灵活的部分，apps[]支持三种写法（正则校验见 ConfigStore.kt）：

1. 纯包名：com.google.android.gms，指向主用户（user 0）下安装的应用；
2. 包名@用户号：com.foo@10，指向工作资料或副用户里的同一个应用——不同用户是 keystore 眼中不同的调用方，可分别归属不同 Profile；
3. uid:N（高级写法）：直接指定调用方 uid，适合 sharedUserId 应用或包名未知场景。

还有一个隐藏开关autoIncludeNewApps: true：让该 Profile 自动覆盖"首次运行之后新安装的所有用户应用"。全配置中最多只能有一个Profile 开启它，基准快照保存在known_packages.json里，保证已有应用不会被悄悄圈进来（实现见 Scope.kt 与 Const.kt）。

3.4 设备身份字段：brand/model/imei…

这些字段（brand、device、product、manufacturer、model、serial、imei、imei2、meid）遵循统一的"覆写 → 采集回退 → 省略"三级策略：

• 填了值：用你的值；
• 没填：回退到守护进程启动时从真实 TEE 采集的值（Harvester 采集并冻结到harvested.json）；
• 两者都没有：该字段不出现在认证信息中。

⚠️信任根（root of trust）故意不可配置：verified-boot 密钥、状态、device-locked 标志在首次采集后被冻结，因为它们参与 KeyMint 密钥加密密钥的派生——改动会导致已存密钥无法解密。

四、补丁级别迷你语言（Mini-Language）完整参考

patchLevel下的system/vendor/boot三个值接受一套迷你语言，由守护进程对照真实设备解析成 KeyMint 要求的整数编码（YYYYMM或YYYYMMDD）。解析核心是 DeviceProps.kt 中的resolvePatch()函数。

4.1 关键字速查表

4.2 一个聪明细节：永不超前于日历

模板YYYY-MM-05（出厂默认值）有个隐患：每月 1–4 号，"本月 5 号"还是未来日期，而没有任何真实设备会携带未来补丁级别。因此解析器会逐月回退，直到模板指向的日期不晚于今天——例如 2026-09-01 这天，YYYY-MM-05会解析为2026-08-05而非2026-09-05。这让默认配置"自我维护"，永远不会超前于日历（实现见 DeviceProps.kt 的substituteDateTemplates()）。

osVersion字段也支持类似表达：留空=复用采集值、system_property=读ro.build.version.release、或直接写"16"/"16.0.0"/160000（编码规则：主版本×10000+次版本×100+修订）。

4.3 WebUI 快捷选项

在 WebUI 中编辑补丁字段时，输入框下方会提供system_property/today/no（以及 vendor/boot 专属的YYYY-MM-05）快捷芯片，点击即填，省去手打（见 field.js 的patchWidget）。

五、配置如何生效：从 JSON 到 keystore

理解数据流有助于排查问题，完整管道定义在 app/README.md：

1. ConfigStore解析并校验config.json，校验失败时保留上一份可用配置，绝不带病运行；
2. Resolver把校验后的 Profile + 冻结的采集记录 + 时钟，解析成推送给原生拦截库的完整配置消息——迷你语言、Scope 目标解析、设备 ID 回退都在这一步完成（Resolver.kt）；
3. Injector / Control将配置经本地 socket 推入 keystore 进程；
4. 推送提交后ReAttest会为"被圈入之前就已存在"的旧密钥重新签发证书链，实现自愈。

任何配置错误（keybox 缺失、mode 非法、应用归属冲突）都会以清晰的错误信息抛出，例如：

profile 'default' has no keybox profile 'x' has invalid mode 'auto' (patch | generation) app entry 'com.foo' appears in both profile 'a' and 'b'

六、新手配置四步走

1. 刷入模块并重启（需 Android 10+、64 位、Root）；
2. 将你自己的硬件级keybox.xml放到/data/adb/teesim/keybox.xml——没放 keybox 时拦截器完全空转，模块无害；
3. 编辑/data/adb/teesim/config.json（或用 KernelSU/APatch 的 WebUI）：建 Profile、指定 keybox、在apps中列出目标应用；
4. 保存。守护进程检测到变化即热更新，无需重启。

如需紧急退出拦截：杀掉 keystore 守护进程即可得到无拦截的干净进程。

七、总结

• 一个 Profile = keybox + 模式 + 补丁/系统版本 + 设备身份 + 应用名单，应用与 Profile 一对一；
• 补丁级别的迷你语言让常用值"免维护"：today、YYYY-MM-05自动跟随日历且永不超前；
• 信任根不可配、配置热更新、校验失败保持旧配置——三者共同保证 TEESimulator 的配置系统"配置错误时是惰性而非危险"；
• 想深入实现，重点阅读 app/README.md、ConfigStore.kt、Resolver.kt 与 DeviceProps.kt 四个文件。

掌握这套 Profile 体系与迷你语言后，你就可以为每个目标应用定制独立的签名身份与补丁画像，这正是 TEESimulator 配置文件设计的精髓所在。

【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator