SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-drm

re-drm

Data & analytics

View repository

Updated 10-15 21:34

About this skill

DRM analysis (PlayReady / Widevine / license flow)

When to use / when not to use

  • Boundary (inherits [[re-cracking]]): only own content protection schemes / authorized testing / CTF·research environments; unauthorized content decryption and commercial DRM bypass are prohibited
  • Use: analyze the component structure and license challenge/response flow of DRM systems (Widevine / PlayReady / FairPlay)
  • Use: understand how players/CDMs (Content Decryption Modules) manage keys and decrypt content (authorized research)
  • Use: DRM vulnerability/weakness research (key extraction, decryption flow bypass, etc.,authorized environments only) and responsible disclosure
  • Use: identification of PSSH and encryption schemes for CENC encrypted media (MP4/CMAF)
  • Do not use: ordinary content protection understanding/protocol reverse engineering (that is the [[re-protocol]] domain)
  • Do not use: samples without DRM that are just ordinary encryption ([[re-crypto-*]] series)
  • Do not use: creating piracy tools / extracting keys for pirated distribution (explicitly prohibited, see authorization boundary）
  • Authorization boundary (required reading): This skill is limited to authorized research—own devices, own content, laboratory environments, security research with written permission. Prohibited: extracting/distributing content keys for piracy, publishing usable key extraction tools, bypassing DRM to obtain unauthorized content. DRM analysis involves anti-circumvention laws (such as DMCA 1201-type) and platform ToS; analysis outputs from a vulnerability research + defensive perspective, findings go through responsible disclosure (vendor security teams/bug bounty programs), and sensitive details (key material) are not written into public reports.

Tool preparation

Static analysis (CDM decompilation / packet capture analysis) requires no sandbox; running the CDM and capturing license traffic is dynamic execution and should be performed in a controlled environment ([[re-analyze/platform-tips]] highest principle). Validate all tools before use.

Decompilation workbench ([[re-ghidra]]) — CDM/decryptor analysis

  • [[re-ghidra]] (default): import CDM binaries (Widevine CDM is an ELF so with an export table) and player binaries
  • [[re-ida]]: alternative; validation: after importing libwidevinecdm.so, it can decompile Initialize/CreateSession class exports
  • CDM acquisition (own environment): Chrome's Widevine CDM is in ~/.config/google-chrome/WidevineCdm/（Linux）/ %LOCALAPPDATA%\Google\Chrome\User Data\WidevineCdm（Windows）/ ~/Library/...(macOS); the same applies to Edge's PlayReady

Network capture ([[re-netcap]]) — license challenge/response

  • For tshark/wireshark/mitmproxy installation, see [[re-netcap]] "Tool preparation"
  • Validation: tshark --version；mitmdump --version
  • For HTTPS decryption, follow [[re-netcap]] step 4 (install the mitmproxy CA into the controlled environment)

protobuf parsing (Widevine side)

  • pip install protobuf(or grpcio-tools); validation: python3 -c "import google.protobuf; print(google.protobuf.__version__)"
  • Purpose: license challenge/response are protobuf; parse by field number (see [[layout]] for the field table)

CDM analysis auxiliary tools (Widevine L3 devices, for research purposes)

  • No standalone distribution package: analysis tools for Widevine L3 CDM (software implementation) come from community research (search GitHub for Widevine L3 related research repositories, such as pywidevine), install pip install pywidevine(only for authorized research on own devices)
  • Validation: python3 -c "import pywidevine; print(pywidevine.__version__)"
  • Purpose and boundary: only analyze own devices/own content; key material must not appear in reports (see pitfall 3)

Procedure

Execute in order; for each step's artifacts (component inventory, license flow notes, CDM structure notes), record the evidence path + sha256 (see [[re-triage]]) for citation in the report.All steps are performed within the authorized scope and a controlled environment(for authorization boundaries see "When to Use").

  1. DRM component identification (CDM / decryptor)：

    • Player/browser side: EME API (requestMediaKeySystemAccess("com.widevine.alpha") / "com.microsoft.playready") → locate DRM type and CDM path
    • CDM component:libwidevinecdm.so(built into Chrome;the suffix indicates the architecture——-arm/-arm64/-x86/-x64 is the CPU architecture rather than a security level; L1/L3 depends on the device TEE root of trust, and ARM devices without a TEE also run the L3 software implementation, see Pitfall 1); the PlayReady component is in Edge/Windows system components; FairPlay is on the Apple side (the [[re-ios]] domain)
    • CDM exported functions (C ABI):Initialize、CreateSession（CreateSessionAndGenerateRequest）、UpdateSession(handles license response),CloseSession、RemoveSession、Decrypt、SetServerCertificate——for the export table see [[layout]]
    • Record: DRM type, CDM path and version, file sha256 (version anchor, Pitfall 4)

  2. CENC/PSSH identification (media side)：

    # 在 MP4/CMAF 里找 pssh box（可脚本遍历 ISO BMFF box 链）
grep -oba 'pssh' sample.mp4 | head
    • PSSH box：size(4) + 'pssh'(4) + version/flags(4) + SystemID(16) + [v1 才有 KID 数+KIDs] + DataSize(4) + Data(for the field table see [[layout]])
    • SystemID to determine DRM: Widevine edef8ba9-79d6-4ace-a3c8-27dcd51d21ed；PlayReady 9a04f079-9840-4286-ab92-e65be0885f95；FairPlay 94ce86fb-07ff-4f43-adb8-93d2fa968ca2
    • DASH-side equivalent:ContentProtection schemeIdUri="urn:uuid:EDEF8BA9-..." + base64 <cenc:pssh>; the encryption scheme field (cenc/cbc1/cbcs) determines the direction of subsequent decryption analysis
    • Artifact: PSSH list (SystemID → DRM type → initial data); for a Python parsing example see [[examples]]

  3. License flow reconstruction (challenge / response)：

    # 受控环境内播放一段自有内容，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: the license request/response is protobuf (wrapped in SignedMessage; for the field table see [[layout]]); PlayReady: SOAP/XML (AcquireLicense, namespace http://schemas.microsoft.com/DRM/2007/03/protocols); the content metadata usually carries the license URL (PSSH box / manifest field)
    • Reconstruction: what is in the challenge (device certificate/asymmetric key public key/session ID) → how the server verifies the device → what is encapsulated in the response (ciphertext of the content encryption key CEK + rights policy)
    • Artifact: license flow diagram (initiator → challenge → response → key decrypted) + notes on the format and fields of each step

  4. Decryptor implementation analysis (key management)：

    • CDM static ([[re-ghidra]]): export function reconstruction (Initialize、CreateSession、UpdateSession(handles license response),Decrypt) → find the key storage and decryption path
    • Key layering (see Pitfall 2): device key (device key; the L3 software key is stored inside the CDM/persistent storage) → decrypt the license response to obtain the content key (CEK) → the CEK decrypts the media; analyze "which step decrypts which key"
    • Decryption algorithm identification: AES-CBC / AES-CTR etc. ([[re-crypto-id]] constant table fingerprinting approach), CENC (Common Encryption) sample format (cenc/cbc1/cbcs schemes)
    • Artifact: key chain diagram (source and protection method of each layer's key) + decryption call path

  5. Vulnerability / weakness localization (authorized research)：

    • Common research surfaces: L3 device key extraction (extracting the software key from CDM memory/persistent storage), missing license response validation, anti-rollback (CDM version check) bypass, missing integrity verification before decryption
    • Method: static localization (key decryption/loading functions) → dynamic observation (breakpoints/instrumentation within a controlled environment to observe the flow of key material) → verify boundaries (what can be decrypted under what conditions)
    • Responsible disclosure after discovery: Document reproduction conditions and impact assessment, submit to the vendor's security team/bug bounty program; do not publicly disclose PoC details
    • Artifacts: findings list (conditions/impact/disclosure status)

  6. Report (compliance)：

    • Report structure: scope of authorization statement → component inventory (CDM version/hash) → license flow diagram → decryptor/key management structure → findings and disclosure plan → defensive recommendations
    • Compliance points: do not include key material or usable extraction tools; ToS/legal boundary statement (DMCA 1201-type anti-circumvention clauses); conclusions expressed from a vulnerability research/defensive perspective
    • Artifacts: report archive (sha256)

Cross-domain combination

  • [[re-ghidra]]: CDM and player decompilation workbench (structure annotation / scripted analysis)
  • [[re-netcap]]: license challenge/response capture (mitmproxy decrypting HTTPS, linked with [[re-protocol]] step 1)
  • [[re-protocol]]: license protocol recovery (challenge/response structure, protobuf/SOAP parsing)
  • [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]]: cryptographic algorithm identification, key material location, ciphertext recovery
  • [[re-android-native]] / [[re-ios]]: mobile CDM (Android-side Widevine integration, FairPlay/Apple side) — an extension of device-side DRM
  • [[re-sandbox]] / [[re-analyze/platform-tips]]: dynamic execution (playing own content/packet capture) in a controlled environment, highest principle

Common pitfalls and traps

  • L1/L3 level differences (hardware vs software): Symptom — for the same Widevine CDM-related sample, the key structure/flow that can be analyzed on device A completely fails to match on device B, or analyzing an L1 target with an L3 mindset hits walls everywhere; Cause — different security levels: L1 keys are protected in TEE (Trusted Execution Environment) hardware, L3 is a pure software CDM that can be extracted and analyzed; architecture identifier:libwidevinecdm.so the suffix of which marks thearchitecture（-arm/-arm64/-x86/-x64) rather than security level — L1/L3 depends on the device TEE root of trust (only ARM devices with TEE are L1, ARM devices without TEE also run L3, x86 platforms generally only have L3); PlayReady likewise distinguishes hardware root of trust and software implementation; Countermeasure — first confirm the target security level (device capability/vendor documentation), only L3 allows software-layer key extraction analysis, L1 analysis goes in the TEE/root-of-trust direction (hardware security); strictly label the level in conclusions, do not apply across levels
  • Key layering (device / content): Symptom — after much effort you obtain a "key", but it fails to decrypt the media content; Cause — DRM is a layered key system: device key decrypts the license response → yields the content key (CEK), and the CEK is what is used to decrypt the media; what you obtained is some intermediate layer, or the CEK is still constrained by rights policies (output protection, etc.); Countermeasure — first fully recover the license flow (step 3: device public key/certificate in the challenge, CEK ciphertext in the response), then proceed to decryptor analysis (step 4) to confirm for each layer "where it comes from, what it decrypts"; check against the key chain diagram which layer the obtained key belongs to, and fill in whichever layer is missing
  • Legal and ToS boundaries (research only): Phenomenon—research outputs (extraction scripts, key material) are used for piracy distribution, and the researcher bears the legal consequences (DMCA 1201-type anti-circumvention liability, platform ToS breach); Cause—DRM analysis outputs are naturally usable as piracy tools, and key extraction and bypass activities may directly violate anti-circumvention laws; Countermeasures—strictly limit to own devices/own content/written authorization laboratory; reports should only describe "how the mechanism works" and "how to defend against it," not reproducible key extraction steps, and not attach key material; findings go through responsible disclosure (vendor bug bounty); for uncertain boundaries, check the authorization documents before acting
  • DRM updates are frequent (conclusions become outdated): Phenomenon—after a CDM update, extraction/analysis methods all become ineffective, and after key rotation, old conclusions become invalid; Cause—the CDM periodically updates and rotates keys, and hardens against extraction (packing/obfuscation/short in-memory key lifetime); Countermeasures—record the exact CDM version + file sha256 + analysis time (step 1); analysis methods (process reconstruction, structure analysis, layered modeling) are reusable across versions, but specific keys/offsets/signatures are not reusable across versions; organize analysis conclusions by "structure/process" rather than by "a certain key value"
  • Mixed use of PSSH versions: Phenomenon—after parsing a v1 PSSH according to the v0 layout, all fields are misaligned; Cause—when the version field is 1, the KID list is inserted between SystemID and DataSize; Countermeasures—when parsing, first read version (the 8th byte); for v1, skip the 4+N×16-byte KID region before reading DataSize ([[layout]] field table)
  • Both challenge and response are wrapped in SignedMessage: Phenomenon—parsing the response directly as a LicenseRequest fails; Cause—all Widevine messages are wrapped in an outer SignedMessage (distinguished by the type field: 0=license request, 1=license, 2=error), and the inner message selects the protobuf by type; Countermeasures—first decode the outer SignedMessage to see the type, then select the inner schema by type ([[layout]] field table)