DRM 安全研究

读完本文，你将获得： 分清 cenc:pssh、mspr:pro、PRO、PRH、WRMHEADER 和 License，避免把六个对象叫成同一个“DRM 数据” 看懂 PlayReady 从 KID、内容密钥到客户端证书和许可证绑定的完整控制面 理解 SL150、SL2000、SL3000 的真实边界，以及为什么安全等级不等于分辨率等级 理解 AES-CTR/CBCS、密钥轮换、Root/Leaf License、Secure Stop 和输出保护分别解决什么问题 用 Shaka Packager、Bento4、GPAC、Shaka Player 和 dash.js 搭建只处理自有测试内容的分析环境 从攻击面而不是宣传页评估 PlayReady：哪些边界稳，哪些风险只是被推到了 TEE、OEM 和 License Server 〇、摘要：我最初把那段 Base64 当成了许可证 笔者第一次认真拆 PlayReady，是在 DASH MPD 里盯着这样一个节点： 1 2 3 4 <ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95"> <cenc:pssh>AAA...</cenc:pssh> </ContentProtection> 第一反应很自然：这一大段 Base64 应该就是 License，里面也许还藏着内容密钥。 解开第一层，得到一个 ISO BMFF pssh box；继续取出 Data，得到 PlayReady Object；按小端字段再拆一层，遇到 0x0001 记录；最后用 UTF-16LE 解码，才看见一段 WRMHEADER XML。里面有 KID、算法和 License URL，唯独没有内容密钥。 ...

读完本文，你将获得： 看清 Chrome/Chromium、Cromite/Bromite、EME、Widevine CDM 和平台 DRM 到底是谁管谁 按版本、补丁、GN 参数和 Ninja 目标复现 Cromite/Bromite 的构建过程 弄明白为什么 “official build” 与 “Chrome codecs” 都不等于 Widevine 跟着六次碰壁，看网络抓流、MSE 截获、UA 伪装和视频 remux 分别死在哪一层 从 MSL、License、设备能力、CENC、CDM 和安全输出六条链评估 Netflix 的防护 〇、摘要：这条路线死在了编译之前 事情的起点很简单。 Chrome 的 Widevine CDM 是一个黑盒，直接改 Chrome 又太重。Cromite 和 Bromite 恰好站在中间：它们是 Chromium 分叉，源码在手里，补丁在手里，GN 参数也在手里。笔者最初把路线排得很顺：编译浏览器 → 打开 proprietary codecs → 伪装 Chrome 能力 → 截获 Fetch/MSE 分片 → FFmpeg 合成视频。 每一步单独看都很合理，连起来却犯了一个致命错误：🧑‍🔬 笔者把”能改浏览器”误当成了”能控制 DRM 信任链”。 第一盆冷水来得比预想中快。还没等 Chromium 开始吃满 CPU，Cromite FAQ 里一句很短的回答就把路线从中间截断了：Does Cromite support DRM media? No. ...

读完本文，你将获得： 明确区分 Chrome 沙箱、V8 字节码、商业 VMProtect 壳与本文讨论的 VM-based Protection 理解 Chrome 原生媒体模块中 VMP 的核心目标：不是让代码不可执行，而是让关键语义不可稳定观测 掌握一套分析 VMP 保护的工程框架：入口边界、调度器、编码状态、完整性校验、明文输出边界 经历从"grep AES S-box"到"差分边界建模"的认知转变过程——以及中间踩过的每一个坑 看清 VMP 的真实安全边界：它能显著提高密钥提取成本，但无法让合法播放后的明文数据凭空消失 〇、摘要 本文讨论的 VMP 指 VM-based Protection / 虚拟机化保护，不是 Chrome 浏览器自身的沙箱机制，也不特指商业产品 VMProtect。它是一类代码保护方法：将原始算法提升为自定义字节码、解释器调度、编码状态和完整性校验的组合，使攻击者很难从静态反编译、内存扫描或常规断点中恢复关键语义。 Chrome 生态里，最适合观察这类保护的位置不是普通网页 JavaScript，而是高价值原生模块，例如桌面端 Widevine CDM 这类承载 DRM 密钥处理和媒体解密的组件。它们处在 Chrome 的 EME/Mojo/CDM 调用链上，既要在用户可控机器上运行，又要尽可能保护 license、content key、白盒表和解密状态。 本文的核心结论是： VMP 的核心不是“藏代码”，而是“抹除可观测性”：标准 AES 表、key schedule、硬件 AES 指令、稳定函数边界都会被替换成 VM 调度、动态表、编码状态和热路径变换。 Chrome 场景下的 VMP 是多边界协同：浏览器进程模型、Mojo IPC、CDM utility 进程、沙箱、完整性校验和白盒数据路径共同构成防护面。 密钥保护和明文保护不是一回事：VMP 可以让 content key 难以提取，但合法播放路径最终仍会产生解码后的明文帧，这是 DRM 工程无法回避的语义边界。 正确的分析方法不是一上来硬反 VM：更有效的路线是先刻画输入/输出边界，再用 perf、堆快照、IPC 观察、完整性安全的断点和差分实验定位“语义转移点”。 换句话说，现代 VMP 的价值在于把攻击者从”搜一个表、hook 一个函数、dump 一个 key”的线性流程，拖入”恢复 VM 指令集、还原状态编码、绕过完整性校验、证明数据流语义”的系统工程。 ...

读完本文，你将获得： 分清 MPD、PSSH、WidevinePsshData、KID、CK 和 License，不再把一段 Base64 当成内容密钥 看懂 moov/trak/stsd/sinf/tenc 与 moof/traf/saiz/saio/senc/mdat 的完整层级和引用关系 分清 CMAF Header、Segment、Fragment 与 Chunk，理解低延迟发布、ABR 切换和 CENC 元数据如何落到同一条时间轴 看懂客户端为什么不能直接访问 Widevine License Service，以及合作方 License Proxy 真正承担什么职责 对照 Chrome 与 Android 双泳道通信图，理解 EME/Mojo/CDM 与 MediaDrm/AIDL HAL/OEMCrypto 两条接入路径 严格区分 Widevine L1/L2/L3、Android 五级安全枚举、分辨率授权和 HDCP 输出策略 理解 Provisioning、设备身份、License 个性化、续租、离线授权、密钥轮换和撤销之间的关系 对照十类主流 OTT 应用，理解 Widevine 在订阅、租购、离线、直播和 UHD 场景中到底负责哪一段 用固定版本 Shaka Packager 对自有媒体做 CENC 实验，并用 Bento4、GPAC 与 PSSH parser 交叉检查结果 从攻击面而不是产品宣传评估 Widevine：L1 把风险压到了哪里，License Server 又可能怎样把整条链主动放空 阅读路线不必从头走到尾： ...

读完本文，你将获得： 一个常被忽略的问题的答案：既然已经有 HTTPS，Netflix 为什么还要在里面再套一层自研的 MSL 加密信道？ MSL 消息的字节级结构：header envelope、encrypted envelope、payload chunk 三层是怎么嵌套的，encrypt-then-MAC 到底对哪段 bytes 签名 CBOR integer key 编码的真实字节，以及为什么 bytes 写成 text、headerdata 内联成 map 会让服务端直接 502 一套不依赖“协议很复杂所以安全”的评估框架：MSL 能保护什么、哪些属性取决于部署配置，以及攻击者会转向哪些边界 〇、摘要 本文记录笔者对 Netflix Message Security Layer (MSL) 的一次协议逆向。 和前几篇 Widevine / FairPlay 文章不同，这次的目标不是攻破某个白盒 AES，而是把一个真实商业客户端的应用层加密协议，拆成能对着字节解释、能复现、能被服务端接受或拒绝的结构。产出是两个最小实现： nfmsl.py：单文件 Python 研究客户端，每一层中间结构都能打印，用来做字段 diff 和错误二分； Android MslClient：用真机 MediaDrm / CryptoSession 复现 Android 侧的 MSL 加密签名链路。 真正的突破点不是拿到某个密钥，而是把下面这些东西对齐到服务端能接受的 wire format： MSL 消息的三层信封结构，以及 encrypt-then-MAC 中「签名签的是密文而非明文」这一点； CBOR integer key 编码里 bytes/text、内联 map/加密 envelope 的字节差异； MasterToken 与 UserIdToken 通过 mtserialnumber 建立的字段级绑定； ASYMMETRIC_WRAPPED 与 WIDEVINE 两类 Key Exchange 的密钥归属差异； licensedManifest 把 Manifest 与 Widevine license challenge 合并进同一个 payload 的结构。 本文同时区分三个容易混淆的对象：Netflix 开源 MSL 框架的能力、本文观测到的 Netflix 客户端协议实例、Netflix 当前生产环境的完整安全策略。前两者可以由公开文档和实验字节支持；第三者还包含服务端风控、密钥托管、撤销策略和设备分级，不能仅凭客户端逆向完整证明。 ...

读完本文，你将获得： 掌握 TCP Nagle 算法对小包延迟的影响机制，以及 TCP_NODELAY 的正确使用场景 学会用双线程管线化将串行 round-trip 改造为全双工流水线（适用于任何请求-响应协议） 理解流式 ISO BMFF 解析的设计思路——边下载边解析边处理，内存与文件大小解耦 通过 DFA/DCA 实测数据认识第三代白盒 AES 的防护边界在哪里 〇、摘要 本文记录了对 Apple Music FairPlay DRM 解密管线的完整优化过程。笔者从一个「能用但极慢」的 Go 实现出发，通过六个递进的优化阶段，将单曲解密速度从 193 秒降至 3.4 秒（57x 提升），内存占用从 181 MB 降至 11 MB（94% 下降）。 核心贡献： TCP_NODELAY 消除 Nagle 延迟：诊断出原始实现慢 57 倍的根因是 TCP Nagle 算法将每个 4 字节长度头延迟 40ms，一行 setsockopt 即可修复 双线程 TCP 管线化：writer/reader 线程分离 + bounded semaphore，将串行 round-trip 变为全双工流水线 流式 ISO BMFF 解析器：边下载边解析边解密，从不在内存中持有完整 M4S——实现对任意大小文件的常量内存解密 FairPlay 白盒 AES 安全评估：通过 DFA fault injection（600 次）+ 全内存 S-box/T-table 扫描，确认 libCoreFP.so 为第三代白盒实现——传统密码分析不可用，18 MB/s 是物理上限 13 首 × 5 轮统计评测：中位吞吐 16.1 MB/s，稳定性 stdev < 0.3s Research Evidence 实验可信度声明：本文所有性能数据均在受控环境中多轮重复测量（单首 50 轮 + 批量 13 首 × 5 轮），白盒攻击实验遵循 Quarkslab SideChannelMarvels 方法论。 ...

读完本文，你将获得： 掌握从 Java 层追踪到 Native 层的 Frida 动态插桩方法论（分组 hook + 二分定位） 理解 FairPlay DRM 在 Android 上的完整解密调用链：5 个函数、4 个阶段 学会识别 in-place 解密模式（输入输出共用 buffer）——这是 sample-AES 的典型特征 获得一套可复用的"7000+ 导出函数中精确定位目标"的逆向工程流程 〇、摘要 本文记录了笔者对 Apple Music for Android（v3.6.0-beta）FairPlay DRM 实现的完整逆向分析过程。目标是理解 Apple 如何在 Android 平台上保护 ALAC 无损音频，并找到从播放流中提取明文音频数据的技术路径。 核心发现： FairPlay 解密调用链还原：从 Java 层的 FootHillDecryptionKey 追踪到 Native 层的 5 个关键函数，完整还原了「初始化 → 密钥获取 → 解密上下文创建 → 逐样本解密」的四阶段生命周期 白盒 AES 入口定位：在 libandroidappmusic.so 的 7000+ 导出函数中，通过分组 hook + 二分法定位到核心解密函数 NfcRKVnxuKZy04KWbdFu***（混淆函数名），确认其 5 个参数的语义 in-place 解密确认：解密函数的输入和输出共用同一个 buffer 指针，明文直接覆盖密文——这是 sample-AES 的典型实现模式 流式 dump 验证：通过 Frida 拦截 N 函数的调用前后，将加密/解密 buffer 分别 dump 到文件，验证了解密前后数据大小一致，且解密后为裸 ALAC 样本序列 本系列文章分为三部分： ...

读完本文，你将获得： 一张完整的白盒密码攻击工具地图：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（key blinding）为什么能抵御 DFA/DCA 等传统密码分析 掌握 LD_PRELOAD + vtable hook 拦截 C++ 虚函数的实战技巧 学会在密钥不可提取时如何转换思路，从"破解密码"转向"捕获明文" 获得 13 种攻击方法的失败原因清单——知道什么不可行，比知道什么可行更有价值 〇、摘要 本文记录了对 Chrome Linux Widevine CDM（libwidevinecdm.so 4.10.2934.0）的安全分析过程。笔者最初的目标是提取 AES 内容密钥——但在系统性尝试 13 种攻击向量后全部失败，笔者发现了一个根本性的事实：这个 CDM 使用白盒 AES + key blinding，裸密钥从不以可观测形式存在于堆内存中。 面对这一死胡同，笔者进行了范式转移——放弃密钥提取，转向流捕获。最终通过 LD_PRELOAD + C++ vtable patching 构建了完整的解密视频流捕获管线： LD_PRELOAD hook：拦截 dlopen/dlsym，在 CDM 加载瞬间获取实例指针并 patch vtable DecryptAndDecodeFrame 捕获：hook vtable slot 14，提取解密后的 YUV 明文（I420/YUV420P10） CDP 持久注入：通过 Chrome DevTools Protocol 劫持 playbackRate，支持 1x-8x 加速捕获 多分辨率段编码：自动处理 Netflix ABR 导致的分辨率切换，分段编码后拼接 端到端验证：Netflix + Shaka demo 视频成功捕获并编码为 MP4 核心贡献不在于最终的流捕获方案（概念上并不复杂），而在于 13 次失败尝试系统性地刻画了 CDM 4.10.2934 的白盒 AES 防护边界——这些"不可能"的证明本身就是有价值的安全分析。 ...

读完本文，你将获得： 理解白盒 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 生产目标不构成阻碍。 ...