Security-Research

读完本文，你将获得： 理解 DRM 系统的四个核心问题：内容加密、设备绑定、授权下发、密钥保护 看到一个完整的、可运行的硬件 DRM 原型：从内容打包到设备授权到加密播放 理解基于 HMAC-SHA256 的密钥层级设计，以及为什么每个公式是这样的 对照 Widevine L1/L2/L3，理解「密钥是否离开芯片」这件事的实际含义 亲手对自己造的 DRM 运行 8 条攻击，看到每一条防御挡住了什么、挡不住什么 获得一张从教学原型到商业级 DRM 的加固路线图，以及与 Widevine/PlayReady 的差距对比 阅读路线： 目标 推荐章节 可以先跳过 建立 DRM 全局直觉 一～三 具体命令和代码 复现实验 四～五 加固路线和商业对比 做安全评估 六～八 密码学公式细节 评估与商业 DRM 差距 八～九 复现步骤 研究边界：本文的所有实验仅针对自有音频内容和自有硬件设备。不涉及任何商业 DRM 系统的绕过或密钥提取。代码中的根密钥是故意写死的教学值 —— 不要拿这套代码保护任何真实内容。 实验环境 项目 规格 板子 Raspberry Pi Pico 2W（RP2350A，Cortex-M33 双核 @150MHz，520KB SRAM，4MB Flash） 上位机 MacBook Pro M1，macOS Sonoma SDK pico-sdk 2.1.0 + pico-extras（cyw43 WiFi/BLE） 工具链 arm-none-eabi-gcc 13.2.1 Python 3.12 + pyserial（串口通信） 调试 picotool 2.1.0（烧录 / info / reboot） 源码文件 labs/14_drm_dongle/ ├── CMakeLists.txt └── src/ ├── main.c 固件：USB CDC 协议状态机 + licence 校验 + 会话管理 + 分块 keystream └── drm_crypto.c/h HMAC-SHA256（手写 ipad/opad，SHA-256 走 RP2350 硬件加速器） tools/drm/ ├── drm_common.py 协议与密码学的"唯一真相"（与固件逐字对齐） ├── pack_audio.py 内容方：加密 WAV + 生成 manifest + 签发 licence ├── dongle_sim.py 虚拟 dongle（纯 Python，不需要板子也能跑全流程） ├── player.py 播放器：向 dongle 要密钥 → 解密 → 校验 → 播放 ├── attack.py 8 条攻击的自动化实验台 └── parity_check.py 固件与上位机协议一致性自检 一、为什么要自己造一个 DRM Widevine、PlayReady、FairPlay —— 商业 DRM 系统的架构文档可以读上万页，但它们的代码是闭源的，协议是加密的，密钥管理深藏在 TEE 和安全芯片里。站在外面看，你能看到协议握手的流程图；站在里面看，你还是不知道一条 licence 被篡改时到底哪一步会拒绝它、拒绝的原因是什么。 ...

读完本文，你将获得： 分清 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. ...

读完本文，你将获得： 分清 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 又可能怎样把整条链主动放空 阅读路线不必从头走到尾： ...