reverse-skills-max: initial public release (restored, redacted, hardened)

vendor-new/rev-skills/.claude/skills/re-tee/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: re-tee
+description: >
+  TEE/TrustZone 逆向：OP-TEE 架构、可信应用（Trusted App）、secure storage、SMC 接口与设备密钥。
+  触发词：TEE、TrustZone、OP-TEE、可信应用、Trusted App、secure world、SMC、安全存储、secure storage、设备密钥
+capabilities: [tee-analysis]
+---
+
+# TEE / TrustZone 逆向（OP-TEE / Trusted App / secure storage）
+
+## 何时使用 / 何时不用
+
+- 用：TrustZone/OP-TEE 类 TEE 分析——可信应用（Trusted App）逆向、命令分发表还原、secure storage（安全存储/设备密钥）对象与数据流
+- 用：设备密钥/信任根方向——DRM 硬件信任根（[[re-drm]] 的 L1 类）、设备密钥提取与保护机制（授权研究）
+- 用：TEE 接口面——SMC 调用、主机侧 TEE 驱动 ioctl、client 库调用序列还原
+- 用：固件安全评估——评估目标设备 TEE 实现的接口暴露面、存储保护强度与信任根边界
+- 不用：普通 App 层（走 [[re-mobile]]）；Windows 内核/驱动（走 [[re-kernel]]，TEE 侧是 Linux/ARM 域）
+- 不用：纯固件提取解包（先走 [[re-fw-extract]]，本技能在其后分析 TEE 组件）
+- 不用：目标只是普通加密数据（走 [[re-crypto-*]] 系列，无 TEE 组件时不必进本技能）
+- 不用：仅需判定「设备是否用了 TEE」（无镜像、无调用面可分析）——特征级证据即可，不进深度流程
+- 不用：EL2 hypervisor/虚拟化域（走 [[re-hypervisor]]，TEE 是 EL1/EL3 域）
+- 注意：**secure world 内动态调试通常不可行**（见坑 3）——默认静态分析 + 主机侧观察；主机侧动态执行按 [[re-analyze/platform-tips]] 最高原则在沙箱内进行
+
+## 工具准备
+
+静态分析（镜像解析/反编译）免沙箱；主机侧动态（跑 client、hook ioctl）按 [[re-analyze/platform-tips]] 最高原则进沙箱；secure world 内动态不做（见坑 3），默认以静态 + 主机侧观察为主。
+
+### 反编译工作台（[[re-ghidra]] / [[re-ida]]，ARM64）
+
+- [[re-ghidra]]（默认）：导入 TEE OS 镜像与 TA（.ta 需先切掉签名头，见步骤 2 与坑 5）
+- [[re-ida]]：备选；两者均需 ARM64 支持
+- 验证: 能反编译 ARM64 代码，定位 `smc` 指令调用点与 `TA_InvokeCommandEntryPoint` 类分发表
+
+### 固件提取工具链（[[re-fw-extract]]）
+
+- binwalk/unblob、magic 扫描、字节序判断——从 bootrom/启动链/设备固件中定位并提取 TEE OS 与 TA 镜像
+- 验证: `binwalk --version`（安装命令见 [[re-fw-extract]]「工具准备」）
+
+### python3（二进制解析/脚本）
+
+- Linux: `apt install python3` / `dnf install python3` / `pacman -S python`；macOS: 自带；Windows: 官方安装器或 `choco install python`
+- 验证: `python3 --version`
+- 用途: 签名头/ELF 载荷切分解析、结构字段标注、解密还原脚本（衔接 [[re-crypto-decrypt]]）
+
+### 参考实现（OP-TEE 官方开源，理解结构用）
+
+- 官方仓库 optee_os / optee_client / optee_examples（与 qemu 仿真环境）提供 TEE 结构与调用序列的权威参照——分析目标与 OP-TEE 差异时按官方源码核对，不凭经验值
+- qemu 仿真环境可跑通 client → TA 全链路调用，用于对照调用序列与参数布局；仿真与真机的差异（真实驱动/中断/存储介质）以真机为准
+
+### frida / 主机侧观察（[[re-frida]]）
+
+- 主机侧动态：hook client 库调用序列与 ioctl 参数（frida 安装与沙箱原则见 [[re-frida]]，动态执行默认沙箱）
+- 验证: `frida --version`
+
+## 操作步骤
+
+按顺序执行，每步产物（镜像定位、头结构标注、命令号表）记录证据路径 + sha256（见 [[re-triage]]），供报告引用。
+
+1. **架构定位（world 划分 / SMC / TEE OS 入口）**：
+   - TrustZone 划分 normal world（普通世界，NS）与 secure world（安全世界，S）；ARMv8-A 中 TEE OS 通常运行在 secure EL1，可信应用在 secure EL0，EL3 监控层（monitor）承载安全监控固件（如 ATF BL31 类启动固件，泛化）
+   - **SMC 指令**是 normal world 进入 secure world 的通道：AArch64 为 `smc #imm`（AArch32 为 `smc`），从 EL1/EL2 执行即陷入 EL3 监控层，监控层再分发给 TEE OS；反编译中搜 `smc` 指令即调用面落点
+   - SMC 参数约定（SMCCC）：功能号在 w0（含服务/调用约定标识位），参数在 w1-w7（SMC32）或 x1-x17（SMC64，**SMCCC ≥1.2 才扩到 x1-x17；1.0/1.1 仅 x1-x7**），返回值从 w0 起——标注调用点按约定表读寄存器，不按普通 ABI 猜（见坑 4）
+   - 特征侦查：版本字符串、导出 API 字符串表、SMC 功能号常量表先 grep 定位——字符串表往往直接给出 TEE OS 类型与版本，比逐个反编译快
+   - 定位 TEE OS 加载入口：bootrom → 启动固件 → TEE OS 镜像（镜像头 magic、加载/验签代码）——沿启动链搜 TEE 镜像特征（镜像头魔数、版本字符串、导出 API 字符串表）；TEE OS 也可内嵌于设备固件分区（[[re-fw-extract]] 提取后定位）
+   - 产物：world/EL 划分图 + TEE OS 镜像位置与加载入口
+
+2. **OP-TEE 结构（core 与 TA 分离、.ta 格式）**：
+   - core（可信 OS 内核，secure world 侧系统服务）与 TA（可信应用，secure world 用户态）分离；core 向 TA 提供 `TEE_*` 内部 API（密码学、secure storage、时间等），TA 依赖该 API 实现业务逻辑——分析 TA 前先确认 core/TA 边界（谁提供 API、谁调用 API）
+   - **.ta 文件格式**（REE 文件系统 TA）：文件 = 签名头 + ELF 载荷。签名头（`struct shdr`，官方 core/include/signed_hdr.h）：magic（`0x4f545348` = "OTSH"）、img_type、img_size、algo、hash_size、sig_size，其后跟 hash 与签名；img_type 取值：0 明文签名 TA / 1 bootstrap TA（带 UUID+版本子头）/ 2 加密 TA / 3 子密钥链式头；加密变体（img_type=2）后跟 `shdr_encrypted_ta` 子头（enc_algo、flags、iv_size、tag_size + iv + tag），密文为 AES-GCM
+   - 解析流程：文件头 magic 定位签名头 → 按 img_size 切出 ELF 载荷 → [[re-format-elf]] 解析节表/段 → 标注 `ta_head`（UUID、版本、flags 等；UUID 即 TA 接口标识，与主机侧调用的 UUID 对应）
+   - 扩展名不作依据：部分设备以 .tos/.trusted 类扩展名分发 TEE OS/TA——一律按 magic 判断格式，不按扩展名选解析器
+   - 产物：签名头字段标注 + 切出的 ELF 载荷 + ta_head/UUID 记录
+
+3. **TA 分析（入口 / 命令分发 / secure storage）**：
+   - 入口链：`TA_CreateEntryPoint`（初始化）→ `TA_OpenSessionEntryPoint`（会话建立）→ `TA_InvokeCommandEntryPoint`（命令分发，按 cmd_id switch）——**命令分发表就是 TA 的对外接口目录**，逐分支标注命令号与行为
+   - 参数模型：invoke 携带参数类型描述与最多 4 个 `TEE_Param`（value 标量对 / memref 内存引用两类）；memref 指向共享内存，是输入输出主通道——每个命令分支标注参数类型与结构
+   - 会话生命周期：OpenSession/CloseSession 与命令调用的配对是还原对象（谁建会话、什么时机、带什么初始参数）——会话建立参数常含初始化密钥材料
+   - 命令号枚举：switch 分支逐一编号（含非法命令/默认分支）；与主机侧调用面（步骤 4）对照，确认哪些命令真实可达、哪些是内部使用——可达命令是接口面/攻击面主体，标注优先级
+   - **secure storage 对象操作**：定位 `TEE_*` 存储 API 调用点（对象创建/打开/读/写/定位/删除类），还原对象 ID（常由 UUID + 对象名/索引派生）与数据流；secure storage 密文最终落盘于普通世界文件系统（经 tee-supplicant）或硬件存储（RPMB 类，硬件侧见 [[re-hw-chip]]）——找到密文文件的解密路径即找到对象数据
+   - 落盘形态：REE 文件系统侧通常为索引文件 + 数据块文件组合（对象目录映射）——按索引找对象、按块定位密文，再还原对象内容
+   - 产物：命令号→行为表 + 参数结构标注 + secure storage 对象清单
+
+4. **主机侧调用面（ioctl / client 库，两头夹逼）**：
+   - Linux 侧 TEE 子系统：`/dev/tee0`（客户端 libteec 使用）上的 `TEE_IOC_*` ioctl（打开会话、invoke、关闭会话、共享内存分配/注册类）；`/dev/teepriv0` 归 tee-supplicant（特权守护进程）使用，不做客户端调用——别把 teepriv0 当「私密会话」通道（见 [[gotchas]]）
+   - 用户态 client 库调用序列（GlobalPlatform TEE Client API）：`TEEC_InitializeContext` → `TEEC_OpenSession`（带 UUID 与参数）→ `TEEC_InvokeCommand`（带命令号与 TEEC_Operation）→ `TEEC_CloseSession` → `TEEC_FinalizeContext`
+   - **夹逼法**：主机侧读 ioctl 参数（UUID、命令号、参数布局、共享内存内容）→ TA 侧分发表（步骤 3）对号入座——两侧都标注后，TA 输入输出格式即可闭合；一侧缺失时从另一侧反推（见坑 2）
+   - 动态观察（沙箱内）：frida hook client 库调用与 ioctl 参数（[[re-frida]]），记录会话打开、命令调用序列与缓冲区内容
+   - 日志侧：`dmesg` 中 tee 驱动与 OP-TEE 初始化日志（驱动版本、中断号、supplicant 状态）辅助指纹与版本判定
+   - 补充观察：tee-supplicant 进程行为（落盘/外设访问）——secure storage 数据流的 REE 侧落点
+   - 产物：主机侧调用序列 + TA 接口对照表（UUID/命令号/参数布局一一对应）
+
+5. **厂商差异处理（自定义 TEE，泛化）**：
+   - 自定义 TEE 的差异点：SMC 功能号体系、TA 镜像格式（头结构/签名/加密方式）、secure storage 布局、导出 API 命名与语义——均可能与 OP-TEE 不同
+   - 思路：先指纹识别 TEE 类型（镜像头特征、字符串/导出 API 特征、SMC 功能号模式）→ 确认是 OP-TEE 系还是自定义实现 → 按通用流程（架构定位 → 格式解析 → 接口枚举 → 调用面夹逼）逐层套用，OP-TEE 细节只作参考模板不当默认值
+   - 差异处理：结构对不上的地方先怀疑"自定义扩展"（新增字段/重排/魔数不同），记录差异点而非强行套用；拿不到格式文档时用「字段长度 + 常见值（UUID/版本/尺寸）」反推布局（[[re-proto-rev]] 思路）
+   - 反推对照：命令号与行为的对应可用「返回码 + 输出缓冲区内容」逐条比对确认——错误码语义往往暴露参数校验顺序与权限边界
+   - 产物：TEE 类型指纹 + 差异点清单
+
+## 跨域联合
+
+- [[re-fw-extract]]：TEE OS/TA 镜像提取与解包前置（bootrom/启动链/固件分区）
+- [[re-binary-core]]：镜像反编译底座（[[re-format-elf]] 解析 TA ELF、[[re-ghidra]]/[[re-ida]] 工作台）
+- [[re-kernel]]：主机侧 TEE 驱动分析（ioctl 分发、驱动加载，Linux 内核侧）
+- [[re-mobile]]：移动端 TEE 集成面（App 内 TEE 调用、DRM 集成，与主机侧调用面衔接）
+- [[re-hw-chip]]：secure storage 硬件侧（RPMB 类存储、信任根、物理防护机制）
+- [[re-frida]]：主机侧动态观察（client 库/ioctl 插桩，沙箱原则）
+- [[re-drm]]：设备密钥/硬件信任根方向（DRM L1 类信任根在 TEE 内）
+- [[re-crypto-decrypt]]：加密 TA 载荷/secure storage 密文的解密还原
+- [[re-sandbox]] / [[re-analyze/platform-tips]]：主机侧动态执行隔离最高原则
+
+## 常见坑与陷阱
+
+- **TA 是签名（+加密）镜像，直接分析会失败**：现象——拿到 .ta 直接丢进反编译器，导入失败或全是乱码；原因——.ta = 签名头 + ELF 载荷（加密变体还是 AES-GCM 密文），文件头不是 ELF 头；对策——先按签名头 magic（如 "OTSH"）定位并切出载荷（步骤 2），加密变体先还原解密流程（[[re-crypto-decrypt]]）拿到明文 ELF 再分析；验签/解密流程本身也是分析对象（信任根/密钥在 core 侧）
+- **secure world 代码拿不到时用主机侧反推**：现象——TEE OS/TA 固件提取不到（SoC 内部 ROM/受保护存储），secure world 动态无从下手；原因——TEE OS 常内置或受保护，不随用户区固件分发；对策——主机侧 ioctl（`TEE_IOC_*`）调用面 + client 库调用序列记录 UUID/命令号/参数布局（步骤 4），结合返回行为反推 TA 接口与内部逻辑，静态证据不足时以调用面证据为主
+- **secure world 防 dump/监测机制**：现象——附加调试无效、内存 dump 出不来或内容异常、运行行为与静态分析不符；原因——TEE 侧有反调试与完整性保护（调试口熔断、安全监测、防转储机制，泛化）；对策——不做 secure world 内动态调试，以静态 + 主机侧观察为主；行为差异记录为「TEE 侧监测触发」证据并标注置信度，不强行归因
+- **SMC 参数约定错误导致误读**：现象——把 SMC 调用点当普通函数调用，按普通 ABI 猜寄存器参数，反推的接口结构全错；原因——SMC 遵循 SMCCC 约定（功能号 w0，参数 w1-w7 / x1-x17，其中 SMC64 的 x1-x17 自 SMCCC 1.2 起；返回值从 w0 起），与普通 ABI 不同，错位解读整条数据流错乱；对策——先按公开调用约定建表（功能号编码、参数寄存器布局、返回约定），再标注反编译中的 `smc` 调用点，参数含义以约定表为准不靠猜（见 [[gotchas]] 调用约定组）
+- **把签名头/ta_head 当 ELF 头解析**：现象——按 ELF 头解析 .ta 失败（e_ident 对不上）、或把 ta_head 的 UUID 当字符串表；原因——.ta 文件头是签名头（ELF 头在载荷内），ta_head 是 ELF 内部首段结构而非文件头；对策——先按签名头字段（magic/img_size）切出 ELF 载荷再走 [[re-format-elf]]；Ghidra/IDA 导入前先用脚本剥离签名头（步骤 2 产物存档）
+- **自定义 TEE 套用 OP-TEE 细节**：现象——按 OP-TEE 的头结构/命令模型分析自定义 TEE，字段全错位、接口对不上；原因——自定义 TEE 的格式与约定不同（镜像头、SMC 功能号、存储布局各异）；对策——先做 TEE 类型指纹（步骤 5），确认体系后再选分析模板；差异按「字段长度 + 常见值（UUID/版本/尺寸）反推布局」处理（[[re-proto-rev]] 思路），OP-TEE 结构仅作参考
+- **UUID 对不上别硬凑**：现象——主机侧调用的 UUID 在 TA 分发表里找不到；原因——固件包内多个 TA 版本并存、或 TA 镜像版本与系统不匹配（UUID 是接口标识，版本演进会换 UUID）；对策——按固件包内 TA 清单/目录核对版本，逐个候选 TA 匹配 UUID 与命令号
+- **secure storage 密文找不到就当没数据**：现象——REE 文件系统侧找不到 secure storage 密文；原因——存储介质在 RPMB/硬件侧，或落盘路径与默认不同（tee-supplicant 配置）；对策——先确认存储介质与 supplicant 配置（REE FS vs RPMB），RPMB 侧转 [[re-hw-chip]] 思路，不以「找不到」下无数据结论
+- 决策分支（镜像形态/接口面/证据分级）见 [[decision-tree]]；格式与调用约定边界见 [[gotchas]]

vendor-new/rev-skills/.claude/skills/re-tee/references/decision-tree.md

@@ -0,0 +1,85 @@
+# TEE/TrustZone 逆向决策树与证据分级
+
+## 场景决策树（入口 → 分支）
+
+### 1. 目标形态分支（第一级）
+
+```
+能拿到什么
+├─ TA 镜像（.ta）→ 签名头解析 → ELF 载荷 → [[re-format-elf]] + 反编译
+├─ TEE OS 镜像（core）→ 反编译，定位 TEE_* 内部 API 与 smc 分发
+├─ 固件分区内嵌（bootrom/启动链）→ 先 [[re-fw-extract]] 提取再定位
+└─ 都拿不到（SoC 内部 ROM/受保护）→ 主机侧调用面反推（分支 4）
+```
+
+### 2. 镜像格式分支（第二级）
+
+```
+.ta 文件头
+├─ magic "OTSH"（0x4f545348）→ OP-TEE 系签名头
+│  ├─ img_type=0 → 明文签名 TA：切出 ELF 直接分析
+│  ├─ img_type=1 → bootstrap TA：子头含 UUID+版本，其后载荷
+│  ├─ img_type=2 → 加密 TA：AES-GCM 密文，先还原解密流程（[[re-crypto-decrypt]]）
+│  └─ img_type=3 → 子密钥链式头（新版本）
+├─ 其他魔数 → 自定义 TEE：按「字段长度 + 常见值」反推布局（[[re-proto-rev]]）
+└─ 直接是 ELF → 无签名头的裸 TA/测试构建，直接分析
+```
+
+### 3. 接口面分支（第三级，两头夹逼）
+
+```
+接口面
+├─ secure world 侧：TA_InvokeCommandEntryPoint 命令分发表
+│  └─ 逐 cmd_id 标注行为与参数类型（value/memref）
+├─ 主机侧用户态：client 库调用（TEEC_OpenSession/InvokeCommand）
+│  └─ 记录 UUID、命令号、TEEC_Operation 参数布局
+├─ 主机侧内核态：/dev/tee0 ioctl（TEE_IOC_OPEN_SESSION/INVOKE/CLOSE_SESSION）
+└─ 两侧对号入座 → 闭合：每个命令分支 = UUID + cmd_id + 参数布局 + 行为
+```
+
+### 4. 数据目标分支（第四级）
+
+```
+要什么
+├─ 设备密钥/信任根 → DRM 方向（[[re-drm]]）确认 TEE 角色；密钥在 core/TA 内
+│  └─ 不可提取时记录用途与保护机制（红线：不硬挖）
+├─ secure storage 对象 → 定位落盘密文（REE 文件系统经 tee-supplicant / RPMB）
+│  └─ 找解密路径（对象 ID 派生 + 加密流程）还原明文
+├─ 命令接口目录 → 分发表还原（步骤 3）
+└─ 调用序列（谁在何时调什么）→ 主机侧 hook（[[re-frida]]）记录
+```
+
+### 5. 拿不到 secure world 分支（第五级）
+
+```
+TEE OS/TA 不可得
+├─ 主机侧 ioctl/client 调用面完整记录（UUID/命令号/参数）
+├─ 返回行为观察（成功/失败码/输出缓冲区）反推内部逻辑
+└─ 结论分级降级：以调用面证据为主，内部实现标注「推测」
+```
+
+## 证据分级表
+
+| 级别 | 证据形态 | 示例 | 用途 |
+|---|---|---|---|
+| A 强 | 两侧夹逼闭合 | 主机侧 ioctl 参数与 TA 分发表逐条对应，明文/密文链路打通 | 可下接口与数据流结论 |
+| B 中 | 单侧完整 | 只有完整主机侧调用面，或只有静态分发表（未动态确认） | 可下「疑似」，标注缺另一侧 |
+| C 弱 | 特征级 | 镜像头魔数、UUID、字符串特征确认 TEE 类型 | 只支持「TEE 类型判定」 |
+| 反证 | 良性解释 | 调用的命令属正常业务路径，无越权/异常 | 记录并存档 |
+
+- 设备密钥结论分级：提取成功（A）→ 确认不可提取+用途（B）→ 仅推测在 TEE 内（C），不把推测当提取结果
+- 行为差异（与静态不符）记录为「TEE 侧监测触发」证据，标注置信度
+
+## 实现教训（内化）
+
+- 先指纹后套模板：TEE 类型（OP-TEE 系 vs 自定义）决定一切格式假设，别拿 OP-TEE 细节当默认值
+- SMC 按约定表读不靠猜：先建 SMCCC 表（w0 功能号、参数寄存器、返回值）再标注调用点
+- 夹逼法两侧都要有落点：UUID、命令号、参数布局三个维度对号入座才闭合
+- 加密 TA 的解密流程本身是分析对象：密钥/信任根在 core 侧，解密逻辑还原即取证
+- secure storage 先找落盘再找解密：tee-supplicant 写入的 REE 文件与 RPMB 分区都是目标
+- 签名头剥离脚本化：切载荷（img_size 偏移）写脚本存档，可复现
+
+## 使用注意
+
+- 主机侧动态（client/ioctl hook）在沙箱内（[[re-sandbox]]，[[re-analyze/platform-tips]] 最高原则）；secure world 内不做动态调试
+- 设备密钥不可提取时记录用途与保护机制，不硬挖（红线）；结论按本表分级标注

vendor-new/rev-skills/.claude/skills/re-tee/references/gotchas.md

@@ -0,0 +1,37 @@
+# TEE/TrustZone 逆向方法论坑与边界
+
+## 镜像与格式组（最容易踩）
+
+- **签名头不是 ELF 头**：.ta 文件头是 `struct shdr`（magic "OTSH"、img_type、img_size、algo、hash_size、sig_size + hash + sig），ELF 头在载荷内——直接按 ELF 解析必然失败；先按 magic 定位、按 img_size 切载荷
+- **img_type 变体各不相同**：0 明文签名 TA / 1 bootstrap TA（子头含 UUID + ta_version）/ 2 加密 TA / 3 子密钥链式头——统一按「签名头 + 子头 + 载荷」分段解析，别假设只有一种形态
+- **加密 TA 是 AES-GCM 密文**：img_type=2 时载荷为密文，`shdr_encrypted_ta` 子头带 enc_algo/iv/tag——先还原解密流程（[[re-crypto-decrypt]]）再分析；解密密钥与信任根在 core 侧，解密逻辑本身是取证对象
+- **ta_head 在 ELF 内首段**：UUID/版本/flags 在载荷 ELF 的 ta_head 结构里，不是文件头字段——切出 ELF 后用 [[re-format-elf]] 找首段标注
+- **bootstrap TA 与普通 TA 入口不同**：bootstrap TA 走 `TA_Boot` 入口而非标准 EntryPoint 链——按 img_type 选分析模板
+
+## 调用约定组（SMC/ABI 边界）
+
+- **SMC 不是普通函数调用**：SMCCC 约定功能号在 w0（含 OEN 与 SMC32/SMC64 标识），参数在 w1-w7（SMC32）或 x1-x17（SMC64，SMCCC ≥1.2；1.0/1.1 仅 x1-x7），返回值从 w0 起——按普通 ABI 读寄存器会整条数据流错位
+- **SMC32 vs SMC64 寄存器宽度不同**：同功能号在两种约定下参数位次/宽度不同——先看功能号第 30 位（SMC64 标识）再选解析方式
+- **HVC 与 SMC 通道别混**：`hvc` / `smc` 由较低 EL 的调用者执行、作为同步异常分别进入 EL2 / EL3（`svc` 进 EL1，使能受 SCR_EL3.HCE/SMD 等控制）——反编译先分清通道再标注调用点，混标会把 hypervisor 调用误归 TEE；看到 `smc` 不能直接等价 TEE，继续按 SMCCC FID/OEN 判服务归属
+- **32/64 位 TA 混合**：AArch32 TA 与 AArch64 TA 的调用约定（TEE_Param 布局）有差异——按 ELF 架构选解析模板
+
+## 主机侧组
+
+- **/dev/teepriv0 不是「私密会话」通道**：teepriv0 归 tee-supplicant（特权守护进程）使用，客户端调用走 /dev/tee0——把 teepriv0 当客户端入口会找不到调用面
+- **ioctl 参数在结构体里**：`TEE_IOC_*` 的 UUID/命令号/参数布局在 `struct tee_ioctl_*` 请求结构里，不是裸 ioctl 参数——hook 时解析请求结构体
+- **共享内存注册是单独流程**：invoke 前常需 `TEE_IOC_SHM_REGISTER` 注册共享内存——hook 调用序列时把 shm 注册与 invoke 配对，才能还原缓冲区内容
+- **tee-supplicant 处理存储 RPC**：secure storage 落盘由 tee-supplicant 在 REE 侧执行（默认路径如 /data/tee 类目录）——找密文文件往 tee-supplicant 的行为看，别在 TA 里找文件操作
+- **client 库版本差异**：libteec 与较新的 libckteec 接口有差异（PKCS#11 方向）——按目标实际使用的库选 API 模板
+
+## 反例与边界组
+
+- **自定义 TEE 套 OP-TEE 细节**：镜像头/SMC 功能号/存储布局各异——先指纹（镜像头特征/字符串/SMC 模式）确认体系再套模板，OP-TEE 仅作参考
+- **secure world 拿不到别硬挖**：SoC 内部 ROM/受保护存储的场景，主机侧调用面 + 行为反推是唯一路径——结论降级标注「推测」，不把反推当确认
+- **设备密钥不可提取**：SE/secure world 内私钥提取通常不可能——记录用途与保护机制（授权研究），不硬挖（红线）
+- **「TEE 存在」≠「数据在 TEE 内」**：很多实现只把密钥放 TEE，业务数据明文在普通世界——先确认数据边界再定分析目标
+- **行为差异不强行归因**：secure world 有防 dump/完整性监测（泛化）——行为不符静态时记录为「TEE 侧监测触发」证据，标注置信度
+
+## 使用注意
+
+- 主机侧动态在沙箱内（[[re-sandbox]]，[[re-analyze/platform-tips]] 最高原则）；secure world 内不做动态调试
+- 结论按 [[decision-tree]] 证据分级标注；设备密钥类结论区分「提取成功/不可提取+用途/推测」三档