re-drm

DRM 分析（PlayReady / Widevine / 许可证流程）

何时使用 / 何时不用

• 边界（继承 [[re-cracking]]）：仅限自有内容保护方案 / 授权测试 / CTF·研究环境；禁止未授权内容解密与商业 DRM 绕过
• 用：分析 DRM 系统（Widevine / PlayReady / FairPlay）的组件结构、许可证挑战/响应流程
• 用：理解播放器/CDM（内容解密模块）如何管理密钥与解密内容（授权研究）
• 用：DRM 漏洞/弱点研究（密钥提取、解密流程绕过等，限授权环境）并负责任披露
• 用：CENC 加密媒体（MP4/CMAF）的 PSSH 与加密方案识别
• 不用：普通内容保护理解/协议逆向（那是 [[re-protocol]] 域）
• 不用：样本没有 DRM 只是普通加密（[[re-crypto-*]] 系列）
• 不用：制作盗版工具 / 提取密钥用于盗版分发（明确禁止，见授权边界）
• 授权边界（必读）：本技能仅限授权研究——自有设备、自有内容、实验室环境、已获书面许可的安全研究。禁止：提取/分发用于盗版的内容密钥、发布可用密钥提取工具、绕过 DRM 获取未授权内容。DRM 分析涉及反规避法律（如 DMCA 1201 类）与平台 ToS，分析以漏洞研究 + 防御视角产出，发现走负责任披露（厂商安全团队/漏洞奖励计划），敏感细节（密钥材料）不写入公开报告。

工具准备

静态分析（CDM 反编译 / 抓包分析）免沙箱；运行 CDM 与抓许可证流量属动态执行，在受控环境（[[re-analyze/platform-tips]] 最高原则）内进行。所有工具先验证再使用。

反编译工作台（[[re-ghidra]]）—— CDM/解密器分析

• [[re-ghidra]]（默认）：导入 CDM 二进制（Widevine CDM 是带导出表的 ELF so）与播放器二进制
• [[re-ida]]：备选；验证: 导入 libwidevinecdm.so 后能反编译 Initialize/CreateSession 类导出
• CDM 获取（自有环境）：Chrome 的 Widevine CDM 在 ~/.config/google-chrome/WidevineCdm/（Linux）/ %LOCALAPPDATA%\Google\Chrome\User Data\WidevineCdm（Windows）/ ~/Library/...（macOS）；Edge 的 PlayReady 同理

网络捕获（[[re-netcap]]）—— 许可证挑战/响应

• tshark/wireshark/mitmproxy 安装见 [[re-netcap]]「工具准备」
• 验证: tshark --version；mitmdump --version
• HTTPS 解密按 [[re-netcap]] 步骤 4（mitmproxy CA 装入受控环境）

protobuf 解析（Widevine 侧）

• pip install protobuf（或 grpcio-tools）；验证: python3 -c "import google.protobuf; print(google.protobuf.__version__)"
• 用途: 许可证挑战/响应是 protobuf，按字段号解析（字段表见 [[layout]]）

CDM 分析辅助工具（Widevine L3 设备，研究用途）

• 无独立发行版包：Widevine L3 CDM（软件实现）的分析工具来自社区研究（GitHub 检索 Widevine L3 相关研究仓库，如 pywidevine），安装 pip install pywidevine（只用于自有设备授权研究）
• 验证: python3 -c "import pywidevine; print(pywidevine.__version__)"
• 用途与边界：只分析自有设备/自有内容；密钥材料不出现在报告中（见坑 3）

操作手順

順番に実施します。各ステップの成果物（コンポーネント一覧、ライセンスフローのメモ、CDM 構造のメモ）には、証拠のパスと sha256 を記録し（[[re-triage]] を参照）、レポートで引用できるようにします。すべてのステップは、許可された範囲内の管理環境で実施します（許可範囲については「使用するタイミング」を参照）。

1. DRM コンポーネントの識別（CDM / 復号器）：

   • プレーヤー／ブラウザー側：EME API（requestMediaKeySystemAccess("com.widevine.alpha") / "com.microsoft.playready"）→ DRM の種類と CDM のパスを特定します
   • CDM コンポーネント：libwidevinecdm.so（Chrome に内蔵；接尾辞はアーキテクチャを示します——-arm/-arm64/-x86/-x64 は CPU アーキテクチャであり、セキュリティレベルではありません。L1/L3 はデバイスの TEE の信頼ルートによって決まり、TEE のない ARM デバイスでも L3 ソフトウェア実装が動作します。落とし穴 1 を参照）；PlayReady コンポーネントは Edge/Windows のシステムコンポーネント；FairPlay は Apple 側（[[re-ios]] 領域）
   • CDM のエクスポート関数（C ABI）：Initialize、CreateSession（CreateSessionAndGenerateRequest）、UpdateSession（ライセンス応答の処理）、CloseSession、RemoveSession、Decrypt、SetServerCertificate——エクスポートテーブルは [[layout]] を参照
   • 記録：DRM の種類、CDM のパスとバージョン、ファイルの sha256（バージョンの基準点。落とし穴 4 を参照）

2. CENC/PSSH の識別（メディア側）：

   # 在 MP4/CMAF 里找 pssh box（可脚本遍历 ISO BMFF box 链）
   grep -oba 'pssh' sample.mp4 | head
   

   • PSSH ボックス：size(4) + 'pssh'(4) + version/flags(4) + SystemID(16) + [v1 にのみ KID 数+KIDs] + DataSize(4) + Data（フィールド表は [[layout]] を参照）
   • SystemID による DRM の判別：Widevine edef8ba9-79d6-4ace-a3c8-27dcd51d21ed；PlayReady 9a04f079-9840-4286-ab92-e65be0885f95；FairPlay 94ce86fb-07ff-4f43-adb8-93d2fa968ca2
   • DASH 側の同等要素：ContentProtection schemeIdUri="urn:uuid:EDEF8BA9-..." + base64 <cenc:pssh>；暗号化方式のフィールド（cenc/cbc1/cbcs）によって、その後の復号分析の進め方が決まります
   • 成果物：PSSH リスト（SystemID → DRM の種類 → 初期データ）。Python の解析例は [[examples]] を参照

3. ライセンスフローの復元（チャレンジ／応答）：

   # 受控环境内播放一段自有内容，mitmproxy/tshark 捕获许可证请求
   tshark -r license.pcap -Y 'http.request' -T fields -e http.host -e http.request.uri | head
   # 典型流程：初始化 → license challenge（POST，含设备指纹/证书）→ license response（含密钥材料）
   

   • Widevine：ライセンス要求／応答は protobuf（SignedMessage でラップされています。フィールド表は [[layout]] を参照）；PlayReady：SOAP/XML（AcquireLicense、名前空間 http://schemas.microsoft.com/DRM/2007/03/protocols）；コンテンツのメタデータには通常、ライセンス URL が含まれます（PSSH ボックス／マニフェストのフィールド）
   • 復元する内容：チャレンジに含まれるもの（デバイス証明書／非対称鍵の公開鍵／セッション ID）→ サーバーによるデバイスの検証方法 → 応答に格納されているもの（コンテンツ鍵 CEK の暗号文 + 権限ポリシー）
   • 成果物：ライセンスフロー図（要求元 → チャレンジ → 応答 → 鍵の復号）+ 各ステップの形式とフィールドのメモ

4. 復号器の実装分析（鍵管理）：

   • CDM の静的分析（[[re-ghidra]]）：エクスポート関数の復元（Initialize、CreateSession、UpdateSession（ライセンス応答の処理）、Decrypt）→ 鍵の保存先と復号経路を特定します
   • 鍵の階層（落とし穴 2 を参照）：デバイス鍵（device key。L3 ソフトウェア鍵は CDM 内／永続化ストレージに保存）→ ライセンス応答を復号してコンテンツ鍵（CEK）を取得 → CEK でメディアを復号；「どのステップでどの鍵が復号されるか」を分析します
   • 復号アルゴリズムの識別：AES-CBC / AES-CTR など（[[re-crypto-id]] の定数テーブルによるフィンガープリント手法）、CENC（Common Encryption）のサンプル形式（cenc/cbc1/cbcs 方式）
   • 成果物：鍵チェーン図（各階層の鍵の取得元と保護方式）+ 復号の呼び出し経路

5. 脆弱性／弱点の特定（許可を得た調査）：

   • よくある調査対象：L3 デバイス鍵の抽出（CDM のメモリ／永続化ストレージからのソフトウェア鍵の抽出）、ライセンス応答の検証漏れ、ロールバック防止（CDM バージョンチェック）の回避、復号前の完全性検証の欠如
   • 方法：静的分析で特定（鍵の復号／読み込み関数）→ 動的観察（管理環境内でブレークポイント／計装を用いて鍵素材の流れを確認）→ 境界の検証（どの条件下で何を復号できるか）
   • 発見後は責任ある開示を行います：再現条件と影響評価を記録し、ベンダーのセキュリティチーム／脆弱性報奨金プログラムに報告します。PoC の詳細は公開しません
   • 成果物：発見事項の一覧（条件／影響／開示状況）

6. レポート（コンプライアンス）：

   • レポートの構成：許可範囲の宣言 → コンポーネント一覧（CDM のバージョン／ハッシュ）→ ライセンスフロー図 → 復号器／鍵管理の構造 → 発見事項と開示計画 → 防御策の提案
   • コンプライアンス上の要点：鍵素材や実行可能な抽出ツールを含めないこと；ToS／法的な境界に関する宣言（DMCA 1201 類の回避防止条項）；結論は脆弱性調査／防御の観点から記述します
   • 成果物：レポートの保管記録（sha256）

分野横断連携

• [[re-ghidra]]：CDM とプレーヤーの逆コンパイルワークベンチ（構造の注釈付け／スクリプトによる分析）
• [[re-netcap]]：ライセンスのチャレンジ／応答の取得（mitmproxy による HTTPS の復号、[[re-protocol]] の第 1 ステップと連携）
• [[re-protocol]]：ライセンスプロトコルの復元（challenge/response の構造、protobuf/SOAP の解析）
• [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]]：暗号化アルゴリズムの識別、鍵素材の特定、暗号文の復元
• [[re-android-native]] / [[re-ios]]：モバイル端末の CDM（Android 側の Widevine 統合、FairPlay／Apple 側）——デバイス側 DRM の発展領域
• [[re-sandbox]] / [[re-analyze/platform-tips]]：動的実行（自社コンテンツの再生／パケット取得）における、管理環境の最優先原則

常见坑与陷阱

• L1/L3 等级差异（硬件 vs 软件）：现象——同一个 Widevine CDM 相关样本，在 A 设备能分析的密钥结构/流程在 B 设备完全对不上，或按 L3 思路分析 L1 目标处处碰壁；原因——安全级别不同：L1 密钥在 TEE（可信执行环境）硬件中保护，L3 是纯软件 CDM 可提取可分析；架构标识：libwidevinecdm.so 的后缀标注的是架构（-arm/-arm64/-x86/-x64）而非安全等级——L1/L3 取决于设备 TEE 信任根（带 TEE 的 ARM 设备才是 L1，无 TEE 的 ARM 设备同样跑 L3，x86 平台一般只有 L3）；PlayReady 同样分硬件信任根与软件实现；对策——先确认目标安全级别（设备能力/厂商文档），L3 才能做软件层密钥提取分析，L1 分析走 TEE/信任根方向（硬件安全）；结论严格标注级别，不跨级别套用
• 密钥分层（设备 / 内容）：现象——费劲拿到一个"密钥"，拿去解媒体内容却解不开；原因——DRM 是分层密钥体系：设备密钥（device key）解密许可证响应 → 得到内容密钥（CEK），CEK 才用于解密媒体；拿到的是中间某一层，或 CEK 还被权限策略（输出保护等）约束；对策——先完整还原许可证流程（步骤 3：challenge 里的设备公钥/证书、response 里的 CEK 密文），再进解密器分析（步骤 4）确认每一层"哪来的、解什么"；按密钥链图核对拿到的密钥属于哪一层，缺哪层补哪层
• 法律与 ToS 边界（仅研究）：现象——研究产物（提取脚本、密钥材料）被用于盗版分发，研究者承担法律后果（DMCA 1201 类反规避责任、平台 ToS 违约）；原因——DRM 分析产物天然可用作盗版工具，密钥提取与绕过行为可能直接违反反规避法律；对策——严格限定自有设备/自有内容/书面授权实验室；报告只写"机制如何工作"与"如何防御"，不写可复现的密钥提取步骤、不附密钥材料；发现走负责任披露（厂商漏洞奖励）；拿不准的边界先查授权文件再动
• DRM 更新频繁（结论过期）：现象——CDM 更新后提取/分析手段全部失效，密钥轮换后旧结论作废；原因——CDM 定期更新并轮换密钥、加固反提取（加壳/混淆/密钥在内存生命周期短）；对策——记录 CDM 精确版本 + 文件 sha256 + 分析时间（步骤 1）；分析方法（流程还原、结构分析、分层建模）跨版本复用，具体密钥/偏移/签名不跨版本复用；分析结论按"结构/流程"组织而非"某个密钥值"
• PSSH 版本混用：现象——按 v0 布局解析 v1 PSSH 后字段全错位；原因——version 字段为 1 时 KID 列表插在 SystemID 与 DataSize 之间；对策——解析先读 version（第 8 字节），v1 跳过 4+N×16 字节 KID 区再读 DataSize（[[layout]] 字段表）
• challenge 与 response 都经 SignedMessage 包裹：现象——直接按 LicenseRequest 解析响应失败；原因——Widevine 所有消息外层都是 SignedMessage（type 字段区分：0=license request 1=license 2=error），内层消息按 type 选 protobuf；对策——先解外层 SignedMessage 看 type，再按 type 选内层 schema（[[layout]] 字段表）