Emulation

读完本文，你将获得： 一张完整的白盒密码攻击工具地图：DFA / DCA / BGE 各自的适用条件和局限 理解 SideChannelMarvels 开源武器库的设计脉络，知道何时该用哪个工具 看清白盒防护从第一代到第三代的演进路线，以及每一代被攻破的根本原因 了解为什么 TEE/TrustZone 攻击成为密码分析失效后的"下一跳" 〇、摘要 本文并非一篇逆向工程实录，而是一份技术考古报告。🧑‍🔬 笔者系统梳理了法国安全公司 Quarkslab 在白盒密码学攻击与 DRM 安全领域的完整研究脉络，试图回答一个问题：当我们使用 DFA/DCA 去攻击白盒 AES 时，这些武器从哪里来，经历了怎样的锻造过程？ 核心发现： 理论奠基（2016）：DCA 论文（CHES 2016 最佳论文）将硬件侧信道分析移植到软件白盒，从根本上证明了「隐藏白盒设计是不够的」 工具武器化（2016–2020）：围绕 SideChannelMarvels 组织，构建了 Deadpool → JeanGrey → Daredevil → Tracer → Stark 完整攻击工具链，并通过 LIEF 实现跨平台（Android → Linux）无缝迁移 TEE 实战突破（2019–2020）：三人团队在 Black Hat USA 2019 公开 Samsung TrustZone 攻击链，从 S-EL0 一路打到 EL3 代码执行——这层 TEE 正是 Widevine L1 DRM 的信任根基 新一代工具（2023–2024）：DarkPhoenix（带外部编码的 DFA）和 BlueGalaxyEnergy（首个开源 BGE 实现）将攻击能力推进到下一代白盒防护 🔬 笔者在前两篇文章中对 Widevine L3 keybox 的 DFA 提取 和 Chrome CDM 白盒 AES 的 13 次碰壁 做了亲身实战，本文则退后一步，把镜头对准这些武器背后的铸剑者。 ...

读完本文，你将获得： 理解白盒 AES 的核心弱点，以及差分故障攻击（DFA）为什么能从中提取密钥 掌握从"定位注入点 → 故障注入 → 密钥恢复"的完整 DFA 攻击方法论 了解 Widevine L3 CDM 的 keybox 结构和 provisioning 验证流程 学会用 Unicorn 仿真 + SideChannelMarvels 工具链搭建自己的白盒分析环境 〇、摘要 本文记录了对 Widevine L3 白盒 AES 实现的完整逆向工程过程，目标是实现 keybox 的离线量产。笔者在 Neodyme 团队工作的基础上，独立完成了以下突破： ROOT_KEY + derived_key 提取：通过差分故障攻击（DFA）从 CDM build 4464 的白盒 AES 中提取了两个核心密钥——文件加密密钥（加载模式 DFA, 150 faults）和 provisioning token 加密密钥（创建模式 DFA, 95 faults） d 区域明文结构还原：逆向发现了 device_key || SHA1(device_key) || 0x03 || zeros 的完整结构 gen_keybox.py：实现了纯 Python keybox 生成器，输出与模拟器原生结果字节完美匹配 Google Provisioning 验证：6 个不同 device_key 全部获得 HTTP 200 Netflix 端到端验证：licensedManifest 成功获取 2 个内容密钥 vendor_key 和 key_mask 作为编译时概念在运行时二进制中已不可恢复，但这对批量 keybox 生产目标不构成阻碍。 ...

读完本文，你将获得： 掌握 unidbg 仿真 Android native SO 的完整工作流：从环境搭建到签名输出 学会应对 OLLVM + VM + JIT 三层防护的实战策略：不硬逆混淆，用仿真绕过 理解字节跳动 MetaSec 签名体系（六神）的架构设计和初始化依赖链 获得一套排查"仿真器崩溃"的系统方法：自毁处理器识别、环境变量门、配置字段逆向 〇、摘要 本文记录了对抖音（Douyin）v37.5.0 libmetasec_ml.so 的完整逆向工程过程，目标是通过 unidbg 仿真提取六神签名算法。笔者在两个完整周末内完成了以下突破： 三层防护突破：识别并绕过了 OLLVM 控制流平坦化 + 自定义 VM 字节码解释器 + 运行时 JIT 代码生成的三重保护 自毁处理器中和：定位并 patch 了 3 个自毁处理器（覆盖 ~71 个调用点），防止仿真器跳转到未映射地址导致崩溃 环境变量门发现：通过 JADX 反编译发现了隐藏的环境变量 28d7fdd567361198183fa7b8e=a7，这是 Phase 2 初始化的硬性前置条件 配置 JSON 逆向：还原了 17 字段的配置 JSON 格式，其中 sdkVersion 字段必须使用 Java 层静态字段值（v06.05.40-dy）而非 native 解密值，这是整个研究的核心突破点 六神签名完整提取：X-Gorgon、X-Khronos、X-Argus、X-Ladon、X-Helios、X-Medusa 全部成功生成 难度评估：9/10——笔者遇到的最复杂的商业 Android 保护方案之一。 研究证据概览 (Research Evidence) 实验环境 项目 配置 目标应用 抖音 (Douyin) v37.5.0 (com.ss.android.ugc.aweme) 目标库 libmetasec_ml.so (3.8 MB, ELF64 ARM64) 主机 Ubuntu 22.04 LTS, x86_64, Dual Intel Xeon E5-2673 v4 (80 threads), 96GB RAM 仿真框架 unidbg + Unicorn2 后端, Java 11 (Temurin) 反编译 JADX (DEX → Java), radare2 5.8.9 (SO 静态分析) 辅助工具 Capstone (JIT 反汇编), 自定义 Java hook (指令 trace + CAS 分析) 分析周期 2026-03-27 ~ 2026-03-29 (2 个完整周末) 假设清单 ID 假设 章节 结果 H1 RegisterNatives 注册在 Object 而非 MS 类上是故意的 JNI 混淆手法 §4.2 ✓ 确认 — JADX 追踪发现 MS → i2 → Object 超类遍历逻辑 H2 Phase 2 失败源于缺少某个环境前置条件 §4.5 ✓ 确认 — JADX 发现 Os.setenv("28d7fdd567361198183fa7b8e", "a7") H3 时间戳相关的路径选择是刻意的 anti-analysis 设计 §4.6 ✓ 确认 — 两条路径功能等价，仅在调试环境中表现为非确定性 H4 配置 field[4] sdkVersion 应使用 native 解密出的 SDK 版本字符串 §4.7 ✗ 推翻 — 正确值来自 Java 静态字段 d4.a = "v06.05.40-dy" H5 JIT 中的 CAS (ldaxrh/stxrh) 循环是 anti-emulation 陷阱 §4.8 ✗ 推翻 — 单线程仿真器中 4 次迭代自然收敛 实验记录 ID 实验 步骤 结果 关键证据 E01 JNI 入口定位 RegisterNatives 日志 + JADX 追踪超类遍历 ✓ 入口 SO+0x271938, MS → i2 → Object E02 自毁处理器中和 反汇编 3 个 handler → 统一 patch adr x0, #0; ret ✓ ~71 个调用点全部中和 (0x266a38/0x266b0c/0x266be0) E03 Vtable 校验绕过 cbz → 无条件 b patch ✓ Phase 1 JNI_OnLoad 正常返回 E04 环境变量门发现 JADX 追踪 n3.a() → Os.setenv 调用 ✓ 28d7fdd567361198183fa7b8e=a7 E05 非确定性分发诊断 Phase 2 连续运行 5 次 ✗ 3/5 3 次返回 0 (成功), 2 次返回 -1 (失败) E06 时间戳固定 → 确定性分发 固定 currentTimeMillis + UUID.randomUUID ✓ Phase 2 连续 5 次 100% 返回 0 E07 配置 field[4] = native 解密值 sdkVersion = "v04.09.09.07-bugfix" ✗ VM 进入 ms_config.h:254 无限循环 E08 配置 field[4] = Java 静态字段值 sdkVersion = "v06.05.40-dy" (来自 d4.a) ✓ VM 执行 3173 条指令 → Boolean.TRUE E09 完整 17 字段配置验证 所有字段语义正确 → Phase 3 ✓ Phase 3 → true, Phase 4 → handle 0x12731000 E10 JIT CAS 循环收敛 观察 ldaxrh/stxrh 迭代次数 ✓ 4 次迭代, w20=w12=0x2000 时收敛 E11 六神签名生成 getFeatureHash(0x2000006) ✓ 6 个签名头全部输出 E12 设备注册端到端 TTEncrypt + 六神签名 → POST device_register ✓ HTTP 200, device_id_str + install_id_str 返回 E13 API 验证 Feed + Search API 请求携带六神签名 ✓ HTTP 200, 正常数据返回 一、路线总览 先用一张图说清楚整个初始化到签名输出的完整序列： ...