XCREAM一些视频是可以下载的，另一些是只能流媒体观看，而且下载的视频也只能下载三次，所以既有现实需要又可以钻研网络安全，就来看看怎么个事。

DRM 全称 Digital Rights Management，也就是常见的视频加密，视频加密是什么呢？俗话说就是厂商不让你下载到视频，这时候有人要出来反对了：凡是网页上能看到的元素，理论上都能找到办法下载出来。

这话不假，所以我说厂商不让你下载到视频，实际上说的是不让你下载到“真实的”视频，视频文件在传输过程中就是加密的，只有真实播放的时候才通过通信拿到密钥，然后一帧帧的解密出来，这个过程是实时的，因此你也是找不到办法看到真正的视频的。

目前主流浏览器的 DRM：

各个公司的攻防难度各不相同，不过我们今天只讨论Widevine，因为许多流媒体平台比如Netflix，Amazon，Spotify都用的是这个技术进行加密，很巧的是XCREAM和FANTA，DMM这些平台也归属其中。从大方面来说，Widevine也是最普及的，所以学会了破解一个往往是其他的也就能破解了。（不过也不是想要什么就有什么的）

因此我们需要了解一些必要的前置知识。

Widevine

概论

Windevine的典型结构包含 4个核心组件：

Widevine 依赖于 W3C 标准的 EME (Encrypted Media Extensions)。EME 提供了一套 API，让网页中的 <video> 标签能够与底层的 DRM 模块进行通信，而无需暴露视频的真实解密密钥。

也就是说，DRM模块本身是一个很底层的东西，往往是在硬件层或者类硬件层的，这就让一般的破解非常的困难，因为攻破硬件层的防守是很难的东西，用户或者黑客其实并不存在那里的权限。而EME又让浏览器和DRM能够进行安全的通信，这就像一条隔绝外物的管道，外面的人很难看到里面发生了什么，而其中的解密加密视频的密钥就在管道内传输，实现DRM的目的。

安全级别

然而，因为一些客观条件的限制，比如视频总有在浏览器中观看的要求，而不是单独下一个软件来看，所谓的相对安全也就昭然若揭了。这里Widevine分为三个安全等级：

• Widevine L1这是最安全的级别，也是绝大多数旗舰智能手机、平板和智能电视追求的标准。
  • 实现方式： 所有的加密解密和视频处理都在 TEE（可信执行环境） 中完成。这意味着视频数据在 SoC（芯片）内部的一个隔离区域处理，操作系统的普通权限（即使是 Root）也无法访问到原始的解码流。
  • 画质支持： 只有达到 L1 级别的设备，流媒体服务商才会授权播放 HD（1080P）、4K 或 HDR 内容。
  • 要求： 硬件必须支持，且需要经过 Google 的认证。
• Widevine L2L2 处于一个比较尴尬的中间位置，在实际应用中并不多见。
  • 实现方式： 解密操作在 TEE 中执行，但随后的视频处理（如渲染、解码）可能是在普通的系统内存或受保护程度较低的环境中进行的。
  • 画质支持： 通常只能获得比 L3 高一点、但低于 L1 的权限（或者某些厂商直接将其视同 L3）。
• Widevine L3这是最基础的级别，主要依靠软件层面实现。
  • 实现方式： 没有任何硬件级别的 TEE 保护，所有的加解密都在普通的软件层完成。对于黑客或开发者来说，通过逆向工程或内存抓取提取出视频流的门槛相对较低。
  • 画质支持： 为了防止高清资源泄露，Netflix 等平台通常会将 L3 设备限制在 SD 画质（通常是 480P）。
  • 常见场景： 被 Root 过的安卓手机、未经过 Google 认证的廉价平板、以及大多数桌面浏览器的 Chrome 插件。

所以，一般的你我想搞到 Netfilx 4k 这种资源基本是不可能的，而且网络上也不会有人分享 L1 的密钥。因为谷歌对设备完整性都是有验证的，因为 Widevine 的核心是一套基于证书的信任链。而 Google 维护着一个 CRL (Certificate Revocation List)。

如果某个机型的 L1 秘钥泄露，比如黑客通过硬件漏洞提取了某款平板的 L1 根密钥，并将其发到了论坛上。Google 一旦确认，可以直接在云端吊销该机型或该批次的证书。那么所有同型号设备在下次连接流媒体服务器申请授权时，服务器会发现其证书已失效，从而拒绝 L1 授权，设备会自动降级到 L3（软解）。

并且现在安卓系统也通过 Play Integrity API（以前叫 SafetyNet）实时监控设备的安全性。当解锁 Bootloader 或 Root 手机时，TEE（可信执行环境）的完整性会被破坏。很多厂商的底层设计是：只要检测到 Bootloader 已解锁，TEE 就不再信任当前系统，拒绝调用 L1 密钥，这就触发了预设的安全防御机制，高清视频也不能看了。

具体过程

我们可以把 Widevine DRM 的整个工作流程分为 四个核心阶段。我们可以想象成可以成一个“寄送带锁的保险箱”的过程：视频是保险箱里的贵重物品，平台有钥匙，而浏览器需要向平台安全地申请这把钥匙。

服务器端的准备（内容加密与打包）

在视频可以被用户播放之前，流媒体平台（如 XCREAM）需要在后台做好准备：

1. 分片与加密：原始的 MP4 视频会被丢进“打包器”（Packager，例如 Google 的 Shaka Packager）。打包器将视频切分成几秒钟一个的片段，并使用 AES-128 对称加密算法把视频流锁死。
2. 生成“锁孔”信息 (PSSH)：加密完成后，打包器会生成一段包含密钥 ID（KID）和 DRM 系统信息的元数据，称为 PSSH (Protection System Specific Header)。
3. 生成索引文件：平台将 PSSH 写入视频的索引文件（通常是 DASH 协议的 .mpd 文件，或 HLS 协议的 .m3u8 文件）。此时，加密好的视频分片就可以放在普通的 CDN 上供人下载了，因为没有密钥，谁下载了都没用。

客户端触发（解析与请求生成）

用户浏览器里点击“播放”按钮：

1. 下载索引：网页里的 HTML5 播放器（一段 JavaScript 代码）首先下载 .mpd 或 .m3u8 索引文件。
2. 发现加密：播放器解析文件时发现了 PSSH 数据，意识到这是一个受 Widevine 保护的视频。
3. 唤醒 CDM：播放器通过浏览器的 EME API，把 PSSH 数据递给浏览器底层的黑盒 CDM (内容解密模块)。
4. 生成加密质询：CDM 拿到 PSSH 后，结合当前设备的安全证书，生成一份高度加密的“许可证请求”。这个请求只有 Widevine 认证的服务器才能看懂。

网络交互（获取许可证）

这是验证你“有没有权限”的关键环节，因为我们想下载视频到本地，那我们本身也得先买了这个视频才有后续。

1. 发送请求：网页播放器拿到 CDM 生成的 Challenge，附带上你的用户登录状态（Token/Cookies），通过 HTTP POST 请求发送给平台的 License Server。
2. 权限校验：服务器首先检查你的账号状态：你买了这个视频吗？会员过期了吗？如果没问题，继续下一步。
3. 解开质询与生成密钥：服务器解开 Challenge，提取里面的信息，并从自己的数据库中找出对应这个视频的 真实解密密钥 (Content Key)。
4. 非对称加密返回：为了防止密钥在传输过程中被黑客抓包窃取，服务器会用你设备 CDM 的公钥，把真实的 Content Key 重新加密一次，封装成一个 License Response，返回给网页播放器。

本地解密与播放（黑盒内渲染）

到了这一步，网络交互结束，纯靠本地设备工作：

1. 移交许可证：网页播放器把服务器返回的 License Response 原封不动地通过 EME API 喂给底层的 CDM。
2. 黑盒解密：CDM 在其内部的安全环境中（对于 L3 来说是经过代码混淆的软件内存中），用自己的私钥解开 License，终于拿到了真实的明文 AES 密钥 (Content Key)。
3. 流媒体解密播放：与此同时，网页播放器正源源不断地从 CDN 下载加密的视频分片，并把它们塞给 CDM。CDM 使用刚刚拿到的 AES 密钥，在内存中实时解密这些视频流，并直接将其送入显卡渲染到屏幕上。

破解思路

由上述步骤，我们可以注意到，对于 Widevine L3 而言，最脆弱的环节就在第四阶段的第 2 步。因为在 L3 级别下，CDM 必须在电脑的普通内存（而不是硬件安全区 TEE）中运算解密。

这个地方就像是两个水管的接口，是很容易出事的。

首先，在接口处我们完全可以偷梁换柱的偷换水管，让服务器以为是一个正常的浏览器在发送请求，因为服务器验证的东西就只有环境和CDM，所以如果我们有一个环境，再加上一个CDM，就可以模拟出恶意的环境，直接得到真实的key后，我们就可以自己打开保险箱拿出来视频了。

另一个思路是，当那个真实的明文 AES 密钥被解出来的一瞬间，它就暴露在了内存里。那么一个粘附于浏览器的插件就可以做到劫持这个请求，直接得到key，这个方法连模拟都不需要，但是CDM还是需要的，因为毕竟浏览器自己内置的CDM是不会让我们自由使用的。

因此只要我们能拿到一个CDM、抓到license服务器请求url，即可构造解密请求报文，获得解密key。需要注意的是CDM作为播放器的预置模块，没有任何下载渠道，且官方会实时监测滥用情况，CDM解密太频繁会被吊销。而且解密和CDM的构造是两个困难，之后把切片的视频一个个拼接也是困难。

好在在互联网上，其实存在一些成熟的开源解密工具框架比如非常有名的 pywidevine，它是用 Python 编写的与 Widevine 接口交互的工具。也就是用Python模拟一个浏览器壳子，只要里面放上CDM核心就能用。

至于CDM，在网上是有一些人分享真实的L3的CDM文件的，而且因为使用的人比较少，而且使用的也不频繁，因此被黑名单的速度远远没有想的那么快，在这里提供老资历论坛VideoHelp里面的链接，即取即用，不过不保证有效性，毕竟用的人越多反而死的越快。

https://forum.videohelp.com/threads/417425-Real-Device-L3-Cdms

不过归根到底，这些CDM的来源基本都是从旧版 Android 设备提取：利用存在漏洞的旧款 Android 手机（如 Android 7/8/9），通过 Root 权限后用wvdumper的工具即可提取：https://github.com/wvdumper/dumper

操作方法是：

• 安卓安装frida，运行
• 电脑连接adb调试
• 电脑运行dump_keys.py
• 手机浏览器随便播放一个drm视频，例如https://bitmovin.com/demos/drm，为的是能让手机的CDM运行起来。抓到CDM之后是可以复制的，是后缀名为.wvd的文件，这个文件很重要，不过获取方式展示不在这里展开了。

除了获取真实的CDM文件，目前最新的方式是远程CDM，也就是搭建API，接受PSSH内部运算后在返回key，因为CDM是见光死的，这样可以有效防止封杀。

另外，也有使用模拟器创建CDM的方法，这里不详细展开，链接如下，有兴趣可以自己查看：

https://forum.videohelp.com/threads/408031-Dumping-Your-own-L3-CDM-with-Android-Studio

必备工具

除了上面已经提到的一些链接，还有更多的开源工具在破解中重要性非常高，我们将一一介绍，本文这里只会贴github仓库，功能，不会提供安装方式，如有疑问请直接把工具名字和github仓库贴给任意一大模型，附上你的操作系统，自会给出解答。

前置类

• Chrome / Edge / Firefox浏览器（PC）

除了safari是完全不兼容Widevine，其他三家基本都是使用Widevine。Chrome自不必说，Edge虽然有PlayReady，但是也支持Widevine，并且因为Widevine更广泛使用所以默认也是用Widevine更多。而Firefox则是内置了CDM这个chrome的黑盒，所以也是没问题的。

• FFmpeg

https://github.com/FFmpeg/FFmpeg

破解后下载下来的往往是音频和视频分离的两个文件，FFmpeg起到混流，片段合并和格式转换的作用，后文的软件也是使用其处理。

• MKVToolNix

https://github.com/mbunkus/mkvtoolnix

MKV 只是一个“容器”，里面可以装视频流、多条音频流、多国字幕流。MKVToolNix 的作用是在不改变画质（不重编码）的前提下，随意拆解或组装这个盒子。

在解密完成后，需要把解密出的视频流和音频流合并。虽然 FFmpeg 也能做，但 mkvmerge（MKVToolNix 的核心组件）在处理 MKV 封装时有两个巨大优势：

1. 容错率极高：对于一些时间戳不整齐、编码略有偏差的流，mkvmerge 的封装成功率比 FFmpeg 高得多，不容易出现音画不同步的情况。
2. 原生支持：N_m3u8DL-RE 的开发者非常推崇这个工具。如果你的系统里装了它，下载器会自动调用它来生成最终的视频文件。

• N_m3u8DL-RE（主下载器）

https://github.com/nilaoda/N_m3u8DL-RE

现代流媒体网站播放视频时，并不是直接传给你一个巨大的 .mp4 文件，而是把视频切成成千上万个几秒钟长的小碎片（.ts 或 .m4s 文件）。

RE 的核心工作流程如下：

1. 解析地图：读取你给它的 MPD 或 m3u8 索引文件，弄清楚视频有多少个分片，分别在哪。
2. 多线程下载：同时开启几十个通道下载这些碎片，速度远超浏览器自带的下载器。
3. 实时解密 (核心功能)：如果你通过拿到了解密密钥（Key），RE 会在下载碎片的瞬间将其还原成明文。
4. 自动拼装：下载并解密完成后，它会自动调用 FFmpeg 或 mkvmerge，把成千上万个碎片合并成一个完整的、可以直接播放的视频文件。

• dash-mpd-cli（辅下载器）

https://github.com/emarsden/dash-mpd-cli

不像 RE 那样兼容 HLS 或 MSS，这个下载器把所有的精力都花在了 DASH (.mpd) 上。对于一些结构极其复杂、非标准的 MPD 文件（比如带有嵌套 BaseURL 或复杂时间偏移的索引），它往往比 RE 表现得更稳定。同样支持通过 --key 参数进行 Widevine/CENC 解密，且解密逻辑非常纯粹。

模拟流

这些工具基本上都是用python模拟浏览器环境，再加上CDM核心去模拟合法客户端请求 license，其中很多已经发展了全自动化，一键化，缺点是往往只支持有限的欧美为主的网站，这里按时间顺序简单贴几个：

freevine:https://github.com/stabbedbybrick/freevine

devine:https://github.com/devine-dl/devine

widefrog:https://forum.videohelp.com/threads/414548-drm-free-content-batch-downloader-widefrog

unshackle:https://github.com/unshackle-dl/unshackle

这些基本上都是声称自己是单纯的流媒体下载工具，不过它们也确实都可以配置DRM，不过都是不能明说的，不然要吃DMCA。

在这里只讲半自动化的方法，原理上和手动操作很接近，不过还是省了非常多麻烦：

https://forum.videohelp.com/members/301890-A_n_g_e_l_a

https://files.videohelp.com/u/301890/hellyes6.zip

Angela的hellyesV6，运行这个还需要安装python>=3.11，以及安装uv。并使用

uv run gui.py

在打开gui后如图所示：

• 第一步：

打开需要破解的流媒体视频页面，按F12打开审查者控制台，接着点击“网络”页面，在 fliter 中先输入 mpd ，刷新视频页面（控制台不会消失），找到mpd文件，右键，点击 复制 -> 复制网址 。然后把复制到的网址填入从上到下第一个槽，即 MPD URL 中

• 第二步：

保持在当前页面不要刷新，把过滤替换为 method:POST，在出现的文件中一一查看载荷，请求载荷不为空的就是我们需要的文件，右键点击 复制 -> 以cURL格式复制，粘贴到从上到下第二个槽中。

这里如果找不到 method:POST 后的符合条件的文件，或者干脆没有文件，说明视频没有使用Widevine加密，只是Token序列化了而已，直接使用下列指令即可下载。

N_m3u8DL-RE 第一步的mpd_url --save-name 视频名字

• 第三步：

Video Name自己随便输一个，就是一会下载出来的视频名称，视频是.mkv格式。单击Get keys，会卡顿，之后下面的空缺都会填上。

• 第四步：

单击 Download Nm~RE，GUI可能会卡住，这个是因为视频可以选择清晰度下载，可以去终端里面选择一下就好。接着就会下载完成。

插件流

目前有两个插件，任选其一即可：

• https://github.com/DevLARLEY/WidevineProxy2?tab=readme-ov-file （推荐）
• https://github.com/Ingan121/Vineless

使用方法是在release页面下载.zip，然后在chrome或者edge浏览器的拓展页面开启开发者模式，接着zip拖入拓展页面安装即可。

使用非常傻瓜式，选择本地的一个CDM文件或者使用remote模式导入json文件（github页面有文件），接着打开视频就会自己弹出key和其他有关信息，如下：

直接复制粘贴到终端运行即可下载，如果key没有显示就说明没有，或者至少不是以Widevine加密的，可以转回模拟法或者继续分析。

未来展望

虽然工具越来越好用，但流媒体平台和谷歌的反制措施也达到了前所未有的强度。目前有几个非常显著的新情况：

• CDM 的“寿命”缩短：以前一个泄露的 L3 CDM 可以用大半年，现在由于谷歌和各大平台（如 Netflix、Disney+、Amazon Prime 等）引入了基于 AI 的风控特征分析，一个被公开的 CDM 往往活不过 24 小时就会被全局列入黑名单（这里指去大平台疯狂下视频的情况）。
• VMP (Verified Media Path) 的全面强制开启：这是目前 L3 破解遇到的最大麻烦。很多高级流媒体平台的 License 服务器不再只看你的 Client ID，还要验证你的“浏览器签名”（VMP）。也就是说，服务器不仅要确认你的 CDM 是合法的，还要确认这个 CDM 是真正在一个未经篡改的官方 Chrome 浏览器里运行的。如果是 Python 脚本发出的请求，即使 CDM 是对的，也会因为没有合法的 VMP 签名而被拒绝下发 Key。所以以后可能插件流会更吃香一点。

不过可以确信的是，XCREAM和DMM还有FANTA这三个费拉不堪的网站在很长一段时间还是只会用他的破 L3 来防护创作者的知识版权。这也不错，连着DLsite也算是一脉相承，钱给的不够谁给你加密。

参考资料

十分感谢国外论坛大佬们的开发和钻研，以及无所不知的大模型。

• https://forum.videohelp.com/threads/404994-Decryption-and-the-Temple-of-Doom
• https://www.freebuf.com/articles/database/375523.html
• https://developers.google.com/widevine/drm/overview?hl=zh-cn#ecosystem