一段 UTF-16 XML 凭什么管住 4K?PlayReady 的套娃式架构

读完本文,你将获得: 分清 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,唯独没有内容密钥。 ...

August 24, 2026 · 12 min · 2451 words · +5

有了 PSSH 还是拿不到 Key,从 L3 到 L1 有多远

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

August 22, 2026 · 27 min · 5667 words · +5
CC BY-NC-SA 4.0 © 2026 +5 · Repost with attribution, non-commercial only
All research is for academic and security purposes only. No functional exploit code or keys provided. For takedown requests contact overkazaf@gmail.com.
本站总访问量 次  ·  访客数 人