TEESimulator 进阶使用指南多用户与工作资料下的跨应用目标Scope 与 uid 匹配机制详解【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulatorTEESimulator 是一款面向 Android 的硬件级密钥认证Key Attestation软件模拟模块它能在不修改设备 TEE 的前提下为指定的目标应用生成与真实 TEE 结构完全一致的认证证书。本文面向进阶用户深入讲解它在**多用户Multi-User与工作资料Work Profile**场景下的进阶玩法并完整拆解 Scope 的 uid 匹配机制——为什么同一个应用在不同用户下是两个不同的调用者以及如何让 TEESimulator 精准命中它们。为什么多用户场景是进阶玩家必须掌握的一课在 TEESimulator 中一个 Profile 通过apps[]数组指定目标应用。但很多人遇到过一个灵异现象明明主用户的应用被模拟成功了工作资料里的同款应用却依然走真实硬件。答案藏在 Android 的 uid 规则里调用者uid 构成示例主用户user 0的某应用appId10123user 10工作资料的同款应用10 × 100000 appId1010123user 10 的 system_server10 × 100000 10001001000也就是说同一个包名在不同 Android 用户下是不同的进程、不同的 uid、对 keystore 而言是两个完全独立的调用者。这个每用户 100000 的步长PER_USER_RANGE是理解 Scope 机制的钥匙源码中的定义位于 Packages.ktuserIdOf(uid)从 uid 反推所属用户uid / 100000uidForPackage(pkg, userId)解析某用户在某用户下的应用 uid主用户走公开 PackageManager工作资料/次级用户则通过IPackageManager的按用户重载跨用户查询daemon 以 root 运行系统会豁免跨用户权限检查一句话结论写com.android.vending只会命中主用户的 Play Store工作资料那份克隆体需要单独指名。Scope 的三种条目写法包名、pkg用户、uid 令牌TEESimulator 把apps[]的解析集中在 Scope.kt 中每个条目只可能是下面四种形态之一普通包名——com.android.vending含义是主用户user 0下安装的这个应用pkgN用户令牌——com.android.vending10含义是user 10 里的同一应用这是覆盖工作资料或次级用户的标准写法uid:N原始令牌进阶——uid:1010123直接瞄准某个调用者 uid适用于共享 uid 应用、或包名未知的场景非法条目—— 无法解析会被安全丢弃并在日志中告警。对应的校验正则定义在 schema.jsAPP_ENTRY_RE 包名 | 包名数字 | uid:数字一个值得注意的设计即使包名指向的应用尚未安装普通包名也会原样保留并下发后续安装后仍能按名字命中而 uid 只有在真实解析成功时才会下发永远不会是 -1。两级匹配机制先包名、后 uid 的路由决策配置最终通过本地 socket 推送到注入 keystore daemon 的原生拦截库。Android 12 的路由核心在 keymint_router.cpp 的ProfileForRequest中它按两级优先级决定一个请求走模拟还是转发真实硬件第一级认证应用 ID包名匹配应用发起认证请求时KeyMint 参数里带有ATTESTATION_APPLICATION_ID其中嵌入了包名。路由器用它在各 Profile 的packages[]中查找。关键细节认证应用 ID只有包名、没有用户。所以路由器会用调用者 uid 除以 100000 得到调用者所属用户再与条目的用户号比对——这正是pkgN语法的底层价值主用户的 Play Store 与工作资料的 Play Store 包名完全相同唯能区分的只有 uid 所属用户。若不做这层校验工作资料的克隆体会误命中为主用户配置的条目。第二级调用者 uid兜底匹配创建认证密钥时应用往往不带认证 ID无 challenge、无应用 ID此时第一级落空路由器退而比较 Binder 调用者 uid 与各 Profile 的uids[]。uids[]是有效 uid 集合已安装包名解析出的 uid uid:N令牌 自动包含扩展三者合并去重。 两条数组packages[]与uids[]彼此独立、长度不必相同——这是 Resolver.kt 在推送配置时明确的契约。实战给工作资料配置独立 Keybox工作资料是 TEESimulator 多用户能力最典型的应用场景企业设备中你常常希望主用户应用与工作资料克隆体使用不同的认证策略不同 keybox、不同补丁级别甚至让工作资料那份完全走真实硬件。步骤如下确认用户号在 WebUI 的 Scope 选择器中设备用户会列出如0 Owner、10 Work profile次级/工作用户由IUserManager.getUsers枚举服务不可用时回退读取/data/system/users目录指名目标用户在 Profile 的 apps 中加入com.android.vending1010即工作资料分派不同 Profile为工作资料克隆体建立独立 Profile指向另一个 keybox 文件。由于每个包/uid 只能归属一个 Profile是硬性校验规则主用户与工作资料各占一条互不冲突保存即生效daemon 监视配置变化并即时重推无需重启。日志中的贴心提示当某条目只指名了主用户、但同一应用还安装在其他用户时Scope 会主动打印提示——com.android.vending is also installed for user 10 (Work profile) — add com.android.vending10 to target that copy too避免没生效被误认为 bug。自动包含autoIncludeNewApps为什么它不吞掉工作资料开启autoIncludeNewApps后Profile 会自动收编基线之后新安装的应用 uid。多用户场景有两个安全设计基线按裸包名记录known_packages.json在首次运行时冻结当时的全部包名。由于工作资料克隆的包名与主用户相同它在基线里被视为既有应用不会被自动收编——这是刻意的安全方向防止 keybox 被应用到无人要求的地方空基线拒绝工作基线文件缺失、为空或损坏时自动包含整体跳过并告警。若把空基线当真所有包都不在基线里会成立整个设备都会被自动包含——恰好是反效果。文件写入采用临时文件 原子重命名杜绝半截写入。此外 v1 基线多用户支持之前生成只含 user 0会在下次运行时一次性补全仅并入主用户没有的包即纯粹存活于工作资料/次级用户的应用user 0 部分保持原冻结时刻不变随后升级为 v2 格式。相关逻辑全部收敛在 Scope.kt 的baselineKnownPackages。用 WebUI Scope 选择器管理多用户目标手改config.json容易出错WebUI 的 Scope 选择器scope-view.js把多用户目标管理做成了可视化列表一应用多行同一应用装在多个用户下时显示为多行——工作资料克隆体有独立 uid、独立调用者身份因此单独一行、单独勾选。点击某行写入的是该行所属用户的条目主用户为com.foouser 10 为com.foo10筛选与排序按最近请求过密钥的应用Recent默认、用户应用、系统应用、已选项筛选支持按使用频次、最近使用、名称、安装时间排序还能按用户过滤占用提示已被其他 Profile 显式占用的条目会置灰并标注归属避免配置冲突自动包含的 uid 单独标识且手动固定与自动包含互斥——一旦固定下次解析即从自动集合中移除低 uid 警告app iduid % 100000低于10000的条目system/shell 级会被标警——那是系统调用者而非普通应用误配没有意义。uid:N令牌在 UI 中仅支持手工增删普通点选永远写入包名条目——这是有意保留的高级操作边界。常见问题排查清单 ️症状原因处理工作资料应用未被模拟条目只写了裸包名仅命中主用户追加pkg用户号条目日志出现NOT INSTALLED for user N (dropped)该用户下确实没装这个包核对工作资料是否已安装克隆体日志提示also installed for user 10 — add ...10主用户条目不覆盖其他用户克隆体按提示补条目is not a valid package name, pkguser or uid:N token条目含非法字符如包名内多余的检查拼写后必须紧跟纯数字自动包含未生效且提示no package baseline yet基线尚未成功冻结如首次枚举失败等待下一次 resolve 自动重试勿手动写空文件目标 uid 告警privileged uid误把系统/shell uid 配进 apps移除该条目普通应用 app id ≥ 10000所有解析过程都有完整日志Scope[profileId]: 条目 - uid N (user M)格式排查时先看日志再改配置。小结理解 Scope 的 uid 匹配机制只需记住三件事uid 用户号 × 100000 appId跨用户克隆体是不同的调用者匹配两级进行认证请求先按包名 调用者用户匹配无应用 ID 的请求再按有效 uid 兜底pkgN与uid:N是精确制导工具WebUI Scope 选择器则是管理它们的安全入口。掌握这些后无论是企业设备的工作资料隔离策略还是多用户环境下的差异化认证配置TEESimulator 都能精确到哪一份应用副本的粒度为你服务。更多配置项keybox、补丁级别、设备身份可参考默认配置 config.default.json 与项目根目录的 README.md。【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TEESimulator 进阶使用指南：多用户与工作资料下的跨应用目标（Scope 与 uid 匹配机制详解）
TEESimulator 进阶使用指南多用户与工作资料下的跨应用目标Scope 与 uid 匹配机制详解【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulatorTEESimulator 是一款面向 Android 的硬件级密钥认证Key Attestation软件模拟模块它能在不修改设备 TEE 的前提下为指定的目标应用生成与真实 TEE 结构完全一致的认证证书。本文面向进阶用户深入讲解它在**多用户Multi-User与工作资料Work Profile**场景下的进阶玩法并完整拆解 Scope 的 uid 匹配机制——为什么同一个应用在不同用户下是两个不同的调用者以及如何让 TEESimulator 精准命中它们。为什么多用户场景是进阶玩家必须掌握的一课在 TEESimulator 中一个 Profile 通过apps[]数组指定目标应用。但很多人遇到过一个灵异现象明明主用户的应用被模拟成功了工作资料里的同款应用却依然走真实硬件。答案藏在 Android 的 uid 规则里调用者uid 构成示例主用户user 0的某应用appId10123user 10工作资料的同款应用10 × 100000 appId1010123user 10 的 system_server10 × 100000 10001001000也就是说同一个包名在不同 Android 用户下是不同的进程、不同的 uid、对 keystore 而言是两个完全独立的调用者。这个每用户 100000 的步长PER_USER_RANGE是理解 Scope 机制的钥匙源码中的定义位于 Packages.ktuserIdOf(uid)从 uid 反推所属用户uid / 100000uidForPackage(pkg, userId)解析某用户在某用户下的应用 uid主用户走公开 PackageManager工作资料/次级用户则通过IPackageManager的按用户重载跨用户查询daemon 以 root 运行系统会豁免跨用户权限检查一句话结论写com.android.vending只会命中主用户的 Play Store工作资料那份克隆体需要单独指名。Scope 的三种条目写法包名、pkg用户、uid 令牌TEESimulator 把apps[]的解析集中在 Scope.kt 中每个条目只可能是下面四种形态之一普通包名——com.android.vending含义是主用户user 0下安装的这个应用pkgN用户令牌——com.android.vending10含义是user 10 里的同一应用这是覆盖工作资料或次级用户的标准写法uid:N原始令牌进阶——uid:1010123直接瞄准某个调用者 uid适用于共享 uid 应用、或包名未知的场景非法条目—— 无法解析会被安全丢弃并在日志中告警。对应的校验正则定义在 schema.jsAPP_ENTRY_RE 包名 | 包名数字 | uid:数字一个值得注意的设计即使包名指向的应用尚未安装普通包名也会原样保留并下发后续安装后仍能按名字命中而 uid 只有在真实解析成功时才会下发永远不会是 -1。两级匹配机制先包名、后 uid 的路由决策配置最终通过本地 socket 推送到注入 keystore daemon 的原生拦截库。Android 12 的路由核心在 keymint_router.cpp 的ProfileForRequest中它按两级优先级决定一个请求走模拟还是转发真实硬件第一级认证应用 ID包名匹配应用发起认证请求时KeyMint 参数里带有ATTESTATION_APPLICATION_ID其中嵌入了包名。路由器用它在各 Profile 的packages[]中查找。关键细节认证应用 ID只有包名、没有用户。所以路由器会用调用者 uid 除以 100000 得到调用者所属用户再与条目的用户号比对——这正是pkgN语法的底层价值主用户的 Play Store 与工作资料的 Play Store 包名完全相同唯能区分的只有 uid 所属用户。若不做这层校验工作资料的克隆体会误命中为主用户配置的条目。第二级调用者 uid兜底匹配创建认证密钥时应用往往不带认证 ID无 challenge、无应用 ID此时第一级落空路由器退而比较 Binder 调用者 uid 与各 Profile 的uids[]。uids[]是有效 uid 集合已安装包名解析出的 uid uid:N令牌 自动包含扩展三者合并去重。 两条数组packages[]与uids[]彼此独立、长度不必相同——这是 Resolver.kt 在推送配置时明确的契约。实战给工作资料配置独立 Keybox工作资料是 TEESimulator 多用户能力最典型的应用场景企业设备中你常常希望主用户应用与工作资料克隆体使用不同的认证策略不同 keybox、不同补丁级别甚至让工作资料那份完全走真实硬件。步骤如下确认用户号在 WebUI 的 Scope 选择器中设备用户会列出如0 Owner、10 Work profile次级/工作用户由IUserManager.getUsers枚举服务不可用时回退读取/data/system/users目录指名目标用户在 Profile 的 apps 中加入com.android.vending1010即工作资料分派不同 Profile为工作资料克隆体建立独立 Profile指向另一个 keybox 文件。由于每个包/uid 只能归属一个 Profile是硬性校验规则主用户与工作资料各占一条互不冲突保存即生效daemon 监视配置变化并即时重推无需重启。日志中的贴心提示当某条目只指名了主用户、但同一应用还安装在其他用户时Scope 会主动打印提示——com.android.vending is also installed for user 10 (Work profile) — add com.android.vending10 to target that copy too避免没生效被误认为 bug。自动包含autoIncludeNewApps为什么它不吞掉工作资料开启autoIncludeNewApps后Profile 会自动收编基线之后新安装的应用 uid。多用户场景有两个安全设计基线按裸包名记录known_packages.json在首次运行时冻结当时的全部包名。由于工作资料克隆的包名与主用户相同它在基线里被视为既有应用不会被自动收编——这是刻意的安全方向防止 keybox 被应用到无人要求的地方空基线拒绝工作基线文件缺失、为空或损坏时自动包含整体跳过并告警。若把空基线当真所有包都不在基线里会成立整个设备都会被自动包含——恰好是反效果。文件写入采用临时文件 原子重命名杜绝半截写入。此外 v1 基线多用户支持之前生成只含 user 0会在下次运行时一次性补全仅并入主用户没有的包即纯粹存活于工作资料/次级用户的应用user 0 部分保持原冻结时刻不变随后升级为 v2 格式。相关逻辑全部收敛在 Scope.kt 的baselineKnownPackages。用 WebUI Scope 选择器管理多用户目标手改config.json容易出错WebUI 的 Scope 选择器scope-view.js把多用户目标管理做成了可视化列表一应用多行同一应用装在多个用户下时显示为多行——工作资料克隆体有独立 uid、独立调用者身份因此单独一行、单独勾选。点击某行写入的是该行所属用户的条目主用户为com.foouser 10 为com.foo10筛选与排序按最近请求过密钥的应用Recent默认、用户应用、系统应用、已选项筛选支持按使用频次、最近使用、名称、安装时间排序还能按用户过滤占用提示已被其他 Profile 显式占用的条目会置灰并标注归属避免配置冲突自动包含的 uid 单独标识且手动固定与自动包含互斥——一旦固定下次解析即从自动集合中移除低 uid 警告app iduid % 100000低于10000的条目system/shell 级会被标警——那是系统调用者而非普通应用误配没有意义。uid:N令牌在 UI 中仅支持手工增删普通点选永远写入包名条目——这是有意保留的高级操作边界。常见问题排查清单 ️症状原因处理工作资料应用未被模拟条目只写了裸包名仅命中主用户追加pkg用户号条目日志出现NOT INSTALLED for user N (dropped)该用户下确实没装这个包核对工作资料是否已安装克隆体日志提示also installed for user 10 — add ...10主用户条目不覆盖其他用户克隆体按提示补条目is not a valid package name, pkguser or uid:N token条目含非法字符如包名内多余的检查拼写后必须紧跟纯数字自动包含未生效且提示no package baseline yet基线尚未成功冻结如首次枚举失败等待下一次 resolve 自动重试勿手动写空文件目标 uid 告警privileged uid误把系统/shell uid 配进 apps移除该条目普通应用 app id ≥ 10000所有解析过程都有完整日志Scope[profileId]: 条目 - uid N (user M)格式排查时先看日志再改配置。小结理解 Scope 的 uid 匹配机制只需记住三件事uid 用户号 × 100000 appId跨用户克隆体是不同的调用者匹配两级进行认证请求先按包名 调用者用户匹配无应用 ID 的请求再按有效 uid 兜底pkgN与uid:N是精确制导工具WebUI Scope 选择器则是管理它们的安全入口。掌握这些后无论是企业设备的工作资料隔离策略还是多用户环境下的差异化认证配置TEESimulator 都能精确到哪一份应用副本的粒度为你服务。更多配置项keybox、补丁级别、设备身份可参考默认配置 config.default.json 与项目根目录的 README.md。【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考