reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
@@ -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 内不做动态调试
|
||||
- 设备密钥不可提取时记录用途与保护机制，不硬挖（红线）；结论按本表分级标注
|
||||
@@ -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]] 证据分级标注；设备密钥类结论区分「提取成功/不可提取+用途/推测」三档
|
||||
Reference in New Issue
Block a user