Widevine

读完本文，你将获得： 看清 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 当前生产环境的完整安全策略。前两者可以由公开文档和实验字节支持；第三者还包含服务端风控、密钥托管、撤销策略和设备分级，不能仅凭客户端逆向完整证明。 ...

读完本文，你将获得： 从硬件寄存器层面理解 ARM EL0→EL3 四层特权的切换机制和攻击面 掌握 TEE 安全研究的核心漏洞模式：共享内存越界、SMC 参数注入、Trustlet 逻辑漏洞 通过四条真实攻击链（Quarkslab / Project Zero / 360 Alpha Lab）学习完整的提权方法论 理解为什么攻破 TrustZone 意味着攻破 Widevine L1 / 支付安全 / 生物识别的信任根基 〇、摘要 在前文中，笔者梳理了 Quarkslab 十年来的白盒密码与 DRM 攻防研究。当白盒密码学防护升级到第三代（密钥从不以可观测形式存在）时，攻击者被迫转向更底层——攻击 TEE 本身。本文正是这条路线的技术深潜。 🧑‍🔬 笔者以四条公开的真实攻击链为骨架，逐层拆解 ARM TrustZone 的每一个异常等级（EL0 → S-EL0 → S-EL1 → EL3），在每一层回答三个问题： 硬件层面发生了什么？——寄存器、页表、内存保护域的切换机制 漏洞长什么样？——该层最常见的漏洞模式，配合真实 CVE 讲解 攻击者怎么穿透到下一层？——具体的利用技术和代码级细节 核心案例： 攻击链 团队 年份 路线 最终效果 Samsung TrustZone Quarkslab 2019 S-EL0 → S-EL1 → EL3 Secure Monitor 代码执行 Boot Chain 4 CVE Quarkslab 2024 USB → Bootloader → EL3 Secure World 全内存泄露 Wideshears 360 Alpha Lab 2021 S-EL0 → SFS Widevine L1 DRM 密钥提取 QSEE Widevine Project Zero 2017 S-EL0 → 任意写 QSEE 代码执行 本文不是入门科普——笔者假设读者已经读过前文中关于 Quarkslab 的研究综述，并对逆向工程、ARM 汇编有基本了解。 ...

读完本文，你将获得： 一张完整的白盒密码攻击工具地图：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 生产目标不构成阻碍。 ...