跳转至

Linux 上的 Widevine VMP:Windows 那套"劫持文件句柄骗过 CDM"的手法,搬不搬得过去?

研究背景:团队在 Windows 上用魔改 CEF 过 Widevine VMP(Verified Media Path)的办法,是 hook 系统级文件打开调用,让 widevinecdm.dll 读到的其实是官方 Google Chrome 的 chrome.exe/.sig 文件,从而让 VMP 校验"验证正版、发证给魔改程序"。现在想把这套思路搬到 Linux(Xvfb + 容器、无 GPU)的云端服务上。本文只回答一个问题:Linux 上的 VMP 到底是什么样子,这个骗术在 Linux 上还成不成立。

方法说明:每条结论标注置信度——确认(一手资料:Widevine/Google 文档、Chromium 源码与 code review、castlabs 官方文档/GitHub)、较可信(可信二手工程文章、社区报告,多处互相印证但非一手)、推测(基于已知事实的合理推断,没有直接证据)。查不到的东西,明说查不到,不装懂。

结论摘要

  • Linux 上基本没有真正生效的 VMP。 Google 授权的 CWIP 认证合作伙伴 castlabs,在自己的 GitHub 文档里原话是:"Linux Widevine CDM 不支持 VMP,因此也不需要 VMP 签名"("the Linux Widevine CDM does not support VMP, and thus does not require a VMP signature")。Kodi/inputstream.adaptive 项目独立给出了同样结论。这是本次研究里证据最扎实的一条判断。确认/较可信(castlabs 是 Google 官方签名合作方,证据接近一手;Kodi 是独立第三方交叉印证)。
  • PLATFORM_UNVERIFIED 在 Linux 上是"默认预期状态",不是报错。 同样来自 castlabs 文档的 VMP 状态对照表:在 Windows/macOS 上 PLATFORM_UNVERIFIED 意味着"大厂流媒体基本用不了";但在 Linux 上,这个状态本身就是"预期会遇到"的正常状态,不代表出错。也就是说,Linux 上所有 Chrome/Chromium 客户端,不管是不是官方原版,天生就拿不到 VMP 认证这个"及格章"。较可信。
  • Windows 那套 hook 手法在 Linux 上搬不过去,但也不需要搬。 这套手法的本质是"骗过一道校验宿主程序二进制身份是否为正版的关卡"。既然 Linux 上这道关卡本身就不存在(没有 Google 签发的 Linux .sig 文件,也没有证据表明license server 会去验证 Linux 宿主程序的身份),魔改 CEF 在 Linux 上不会因为"被识别出改过"而被单独降级——大家(不管官方 Chrome 还是魔改 CEF)一起被打入 PLATFORM_UNVERIFIED 这一档,待遇是一致的。真正决定能不能播、播多高清的,是你用的 libwidevinecdm.so 这个 CDM 二进制本身是不是没动过手脚的正版(而不是宿主浏览器程序)。推测(基于 Q1/Q2/Q4 证据链的合理推断,没有一条一手资料直接写"魔改 CEF 在 Linux 上等同于官方 Chrome",但反证也没有找到)。
  • 强制 VMP 的大厂站点在 Linux 上:不是"完全不能用",而是"普遍被限得更低"。 Netflix 官方页面明确写:Linux 上 Chrome/Firefox/Edge 最高只给 720p(Opera 例外给到 1080p),没有 4K。Amazon Prime Video 官方只给 SD(480p)。这印证了假设"license server 对 Linux 客户端单独适用更低画质策略",且明确写出原因跟 VMP 缺失直接相关(见 Q3 的 HBO Max 引用:"Widevine on a Linux browser doesn't have VMP...It's the service limiting the quality")。确认(Netflix 官方页面)+较可信(VMP 因果解释)。
  • Disney+ 是极端案例,历史上直接拒绝发证。 2019 年(Disney+ 公开上线前)Linux 浏览器访问 Disney+ 直接报 Error Code 83:"Platform verification status incompatible with security level"——这几乎可以确定就是 VMP/platform verification 失败导致的硬拒绝,不是画质降级问题。更近期(未能完整取证,时间点不明)的社区调查称现在 Disney+ 放行 Linux 但砍到 480p——这条较可信但未完整核实(原始帖子 403 拒绝抓取,只有搜索摘要)。
  • castlabs 的 VMP 签名服务(EVS)只覆盖 Windows 和 macOS,明确不提供 Linux 签名,理由就是上面那条"Linux CDM 不支持 VMP"。这是全篇除 castlabs 文档本身之外,能找到的最强的"哪些平台真的有 VMP"的间接证据——連专业的第三方签名商都放弃了 Linux。确认。
  • 文件层面缺证据的地方: 没有找到任何 reverse-engineering/strace 记录直接证明(或证伪)libwidevinecdm.so 在 Linux 运行时会不会去尝试打开某个 .sig 文件。Chromium 源码 review(codereview.chromium.org/2582463003)显示确实存在一段跨平台的、POSIX/Zygote 路径下的 "CDM host 文件校验" 代码,但这段代码在 Linux 上是否真的被启用、是否真的会去找 Google 签发的 sig 文件、没有查到确凿证据。这是本报告最大的检索缺口,建议团队自己动手 strace 一次官方 Linux Chrome 播放 DRM 内容的过程来验证。
  • 一句话给结论: Windows 上那套"劫持句柄让 CDM 读官方文件"的招数,在 Linux 上用不上,因为压根没有 VMP 这道关要过;但这不是好消息——这意味着云端 Linux 部署从起点上就会被大部分强 VMP 站点(Netflix/Amazon/Disney+等)限制在比 Windows 官方 Chrome 更低的画质/可用性档位,而且这个天花板是架构性的,不是"云端环境没配置好"能解决的,魔改与否都一样卡在这道天花板下面。

1. Chrome Linux 是否携带 VMP 签名文件?文件布局对比

核心结论:Windows/macOS 有一整套 .sig 签名文件基础设施,Linux 没有——不是"没打包",而是"这套机制在 Linux 上本来就不存在"。

  • Windows:签名文件位于 C:\Program Files (x86)\Google\Chrome\Application\[VERSION]\,包括 chrome.dll.sig、chrome.exe.sig,以及 WidevineCdm\_platform_specific\winx64\ 目录下的 widevinecdm.dll.sig。CDM 库本体 widevinecdm.dll 在 WidevineCdm\_platform_specific\win_(x86|x64)\ 下。较可信(exefiles.com/fileinfo.com 等技术站点,多方口径一致)。
  • macOS:CDM 库为 libwidevinecdm.dylib + widevinecdmadapter.plugin,位于 Chrome Framework 内(/Applications/Google Chrome.app/Contents/Frameworks/Google Chrome Framework.framework/Libraries/WidevineCdm/)。Chromium 官方 code review 讨论里,工程师明确说"在 macOS 上签名文件需要放在 Framework 的 Resources 目录里"——这是一手来源(codereview.chromium.org/2582463003)。
  • Linux:CDM 库为 libwidevinecdm.so(+ 历史上还有 libwidevinecdmadapter.so),随 Chrome 一起打包在 /opt/google/chrome/WidevineCdm/ 下。没有找到任何来源提到 Linux 版 .deb/.rpm 包里存在对应的 .sig 签名文件——检索了 dpkg 内容列表相关资料、Widevine 打包相关 GitHub 仓库,均未见 .sig 文件的踪迹,只有 CDM 本体和 manifest.json。较可信(未查到即视为不存在的间接确认)——这属于"没找到反例",不是"找到了明确的空文件列表证据",严格说仍有一点点残余不确定性。
  • 原假设验证结果:VMP 历史上是 Windows/macOS 专属,Linux 没有 —— 得到多方独立交叉印证,判定为确认。 castlabs 官方 GitHub Wiki 原话:"Since the Linux Widevine CDM does not support VMP, and thus does not require a VMP signature, EVS does not provide signing of Linux binaries."(github.com/castlabs/electron-releases/wiki/VMP);castlabs 的 Widevine 认证页面把 VMP 签名服务范围写成"Windows and macOS"(castlabs.com/security/widevine-certification/);Kodi/inputstream.adaptive 项目 Wiki 独立确认:"we cannot provide this feature nor provide an official Widevine support"(指非 Android 平台,包括 Linux)(github.com/xbmc/inputstream.adaptive/wiki/Verified-Media-Path-(VMP))。三个独立信源(castlabs 官方文档两处 + Kodi 项目)口径完全一致。确认。

2. libwidevinecdm.so 在 Linux 上到底做不做 VMP 校验?

核心结论:Chromium 源码层面存在一段"跨平台"的 CDM host 文件校验代码,理论上也覆盖 Linux;但没有证据表明这段代码在 Linux 实际生产环境里真被启用过,也没有 strace/逆向证据能直接证实或证伪。

  • Chromium 官方 code review codereview.chromium.org/2582463003("media: Verify CDM Host files")是一手来源,揭示了三个平台的不同实现路径:
  • Windows:content_decryption_module_ext.h 里用 #if defined(WIN32) 处理文件描述符。
  • macOS:签名文件要放在 Chrome Framework 的 Resources 目录下。
  • Linux/ChromeOS(走 Zygote 进程):代码用 #if defined(OS_POSIX) && !defined(OS_NACL) && !defined(OS_MACOSX) 做条件编译——评审者备注这个条件实际上覆盖 Linux(因为 OS_LINUX 对 OS_CHROMEOS 也成立),文件是在 Zygote 进程 fork 出子进程之前打开的,跟其他平台"PPAPI 进程启动后、沙箱封闭前打开文件"的时机不同。
  • 这说明:架构上 Chromium 并没有把 Linux 完全排除在 CDM host 校验代码之外——这与第 1 节"Linux 没有 VMP"的结论看似有点矛盾,但更合理的解读是:这段代码是通用的文件校验机制骨架(校验"文件有没有被篡改"这个操作本身是跨平台的),但能不能真正拿到一份 Google 签发的、绑定到具体二进制的 Linux 签名文件,是完全独立的另一件事——而这件事从第 1 节的证据看,答案是"拿不到"。也就是说,骨架在,弹药没有。这个"骨架 vs 弹药"的区分是本报告的推测性调和(推测),用来解释两组看起来矛盾的证据,不是直接证据。
  • 没有找到任何 reverse-engineering 文章、strace 输出或 CDM 内部结构分析,直接证明(或证伪)libwidevinecdm.so 在 Linux 运行时会不会尝试打开某个 .sig/签名文件。 检索了"逆向 Widevine CDM"相关资料(如 widevine-l3-decryptor 项目的 wiki),内容集中在密钥提取和 VerifyCdmHost_0 这类函数名的存在性上,但没有专门跑过 Linux 环境下的系统调用追踪。明确的检索缺口——建议团队自己在 Linux 环境下对 Chrome 播放 DRM 内容的过程跑一次 strace -f -e trace=open,openat,几十分钟就能拿到确凿答案,比继续查文献可靠。

3. 大厂流媒体在 Linux Chrome 上到底能不能用、能到什么画质?

核心结论:多数服务"能用但明显降级",少数服务(Disney+ 历史上)"直接拒绝";没有一家在 Linux 上给到跟 Windows 官方 Chrome 一样的待遇,这跟第 1/2 节"Linux 没有 VMP"的结论完全自洽。

服务 Linux Chrome 现状 置信度
Netflix 官方明确支持,但设了硬顶:Chrome≥117/Firefox≥111/Edge≥118 均 720p,Opera≥92 可到 1080p(例外),均无 4K。确认(help.netflix.com/en/node/23742 官方页面)
Amazon Prime Video 官方只给 SD(480p),社区有非官方插件尝试拉到 1080p,但不稳定、不官方支持。较可信
Disney+ 历史上(2019年,正式上线前)在 Linux 浏览器上直接拒绝,报 Error Code 83:"Platform verification status incompatible with security level"(phoronix.com/news/Disney-Plus-Not-On-Linux)。确认(该事件本身)。更近期社区调查称现在放行但压到 480p——较可信但未完整核实(原文 403 无法直接抓取,仅有搜索引擎摘要:LinusTechTips 论坛帖"Disney+ intentionally limits Linux browsers to 480p (confirmed by support)")。
Max / HBO Max 反馈不一:有用户在 FreeBSD+Linux 兼容层下,装上原生 Linux Widevine CDM 包后能正常播放;另有资料称 HBO/Max 使用的 DRM 加密方式"不是所有都兼容 Linux"。一条被多处转载的说法直接点出因果:"Widevine on a Linux browser doesn't have VMP...It's the service limiting the quality"。较可信,具体分辨率数字未查到,检索缺口。
Apple TV+ 网页版(tv.apple.com)理论上能打开,但多个用户反馈"因为缺少正确的 DRM 支持"播放失败或体验很差。没查到确切分辨率数字或官方 Linux 支持声明。较可信/检索缺口。
DAZN 官方支持浏览器列表里不包含 Linux(官方帮助页面本次抓取被 403 拦截,只能引用搜索摘要及独立转述站点),但 Chrome/Firefox 内核在非官方场景下"可能可以用"。较可信。
ABEMA 官方推荐环境明确只列 Windows / Mac / Android / iOS,不包含 Linux;Chrome/Chromium 内核在 Linux 上"可能能跑但完全不保证"。确认(官方支持页面所列平台范围,来自 help.abema.tv 检索结果)。
  • Netflix 历史上是否需要 UA 伪装? 是的——2014~2016 年前后,Netflix 曾要求 Linux 上的 Chrome/Chromium 伪装成 ChromeOS 或 Windows 的 User-Agent 才能播放(HTML5+Widevine 支持刚落地、Netflix 的 UA 白名单没跟上),需要装 User-Agent Switcher 之类的插件。后来 Netflix 放开了这条 UA 限制,现在 Linux 原生 Chrome 不需要伪装即可播放(受限于上表的画质天花板)。较可信(makeuseof、Mozilla Bugzilla #1317371、多个论坛帖交叉印证,无 Netflix 官方一手说明这段历史变迁的确切时间点)。
  • 是否有证据显示 license server 对 Linux 客户端单独适用更低的策略,原因直接挂钩 VMP 缺失? 有,且是本节证据链里最关键的一条:多个来源(包括与 HBO Max 讨论相关联的技术说明)直接写明"Linux 浏览器没有 VMP,这是一个能让 Windows 浏览器拿到更高画质的安全特性;是服务方在按 VMP 状态限制画质,HBO 完全可以选择给 Linux 浏览器开满分辨率"。这句话把"缺 VMP → 服务方主动降级画质"这条因果链说得很直白。较可信(非 Google/HBO 官方原文,但转述具体、逻辑自洽,与 Netflix/Amazon 官方页面给出的实际数字完全吻合)。

4. castlabs / 第三方 VMP 签名:能覆盖 Linux 吗?

核心结论:这是全篇证据质量最高的一节——castlabs 作为 Google 官方认证的 CWIP(Certified Widevine Implementation Partner),自己的产品文档明确把 Linux 排除在 VMP 能力范围之外,理由直接点名"Linux Widevine CDM 本身不支持 VMP"。

  • ECS(Electron for Content Security,castlabs 的魔改版 Electron):官方 README/Wiki 描述其平台支持为——Windows、macOS 全支持(含 VMP + 持久化 license);Linux 只有部分支持:Widevine CDM 能跑,但不支持持久化 license(persistent license),原因写得很直白:"lacks support for persistent licenses due to VMP limitations on the platform"。确认(github.com/castlabs/electron-releases、.../wiki/VMP)。
  • EVS(castlabs 的付费"即时 VMP 签名"服务):官方页面写明支持 Chromium / Electron / Firefox 三大框架,但平台只有 Windows 和 macOS,完全没有 Linux 选项。确认(castlabs.com/security/widevine-certification/)。
  • VMP 状态参照表(castlabs Wiki):PLATFORM_UNVERIFIED 在 Windows/macOS 上意味着"大厂流媒体基本用不了";在 Linux 上这条状态是"预期会遇到的",不是异常。这条信息进一步坐实"Linux 上 VMP 从设计上就不生效",而不是"临时没配置好"。确认。
  • 定价/授权条款:castlabs 官网把 VMP 签名服务描述为"low-cost"(低成本)、"instant-signing"(即时签名,对比 Google 官方 MLA 流程的漫长等待),但没有找到公开的具体价格数字,需要联系销售获取报价。检索缺口(只有营销措辞,没有价目表)。
  • 结论:castlabs 的文档是目前能找到的最强的"VMP 到底在哪些平台存在"的证据——因为它是 Google 授权的官方签名合作方,如果 Linux 上真的能签发 VMP,castlabs 作为商业公司没有理由放弃这块市场;它明确放弃,本身就是最有力的旁证。

5. Linux/容器环境下的文件句柄拦截手法对比

核心结论:Windows 那套手法的目标(骗过宿主程序身份校验)在 Linux 上没有对应的关卡要骗,所以"要不要在容器里做文件拦截"这个问题,前提本身可能不成立;但如果团队出于其他目的(例如让魔改 CEF 读取到某些别的资源路径)仍要做拦截,以下是几种技术手段的对比。

  • LD_PRELOAD:在动态链接阶段替换 libc 的 open/openat/fopen 包装函数。优点是不需要任何额外容器权限,普通无特权 Docker 容器里就能用,只是设置环境变量+提供 .so。缺点是只能拦截"经过 libc"的调用——静态链接二进制、Go 这类自己发系统调用的程序、JIT 生成的裸系统调用指令都会绕过去。确认(通用系统知识,HN 相关讨论佐证)。对 libwidevinecdm.so(一个正常动态链接的 C++ 共享库,大概率走标准 libc)这种场景,LD_PRELOAD 拦截 open/openat 大概率是可行的。
  • ptrace:通过 PTRACE_SYSCALL 逐个系统调用拦截,能拿到寄存器改参数,但每次系统调用要停两次(往返上下文切换),吞吐量差,大约每次 10~20 微秒的额外开销。更关键的是,Docker 默认 seccomp profile 是禁止 ptrace 系统调用的,必须显式加 --cap-add=SYS_PTRACE,很多场景还得配合 --security-opt seccomp=unconfined 或自定义 seccomp profile 才能用——这在标准的无特权 Docker/K8s 环境里默认不可用,需要额外授权。较可信(Docker 官方文档/社区讨论)。
  • seccomp-notify(seccomp 用户态通知,内核≥5.9):比 ptrace 更现代、开销更低的方案,内核层面拦截系统调用后转发给一个监督进程处理。查到的技术文章(2025年12月的 Outflank/Kyle Avery 关于用 seccomp-notify 做进程注入的研究)指出这种"父进程对子进程"的拦截方式不需要特殊权限,在任意 ptrace_scope 级别都能用——但这些研究聚焦的是"父进程注入子进程"这种场景,不完全等同于"给一个无特权容器里已经在跑的进程装监督者"这个具体需求,细节上是否需要 CAP_SYS_ADMIN 或特定的 user namespace 配置,没有查到直接、明确的定论。较可信(基本能力)+ 推测(容器场景下的确切权限要求)。
  • FUSE / bind-mount:用 FUSE 或 bind-mount 在文件系统层面做路径重定向,通常需要访问 /dev/fuse 设备或挂载权限,标准无特权容器默认不给,一般要加 --device /dev/fuse、--cap-add SYS_ADMIN,或者在 K8s 里用特权 Pod / 自定义 CSI 驱动。这块本次没有专门深入检索,是基于通用 Docker/FUSE 知识的推测,标记为浅层检索缺口。
  • "干脆用 bind-mount/symlink 指向官方 Chrome 文件,不用 hook"这个思路是否可行? 回到第 1/2 节的核心发现:如果 Linux 上压根没有 VMP 这道文件身份校验关卡,那这个思路的前提就不成立——不是"这个技巧在 Linux 上可行/不可行",而是"这个技巧要解决的问题在 Linux 上不存在"。团队真正需要操心的,不是"让 CDM 读到官方文件",而是"确保加载的 libwidevinecdm.so 本身是没被动过手脚的正版二进制"——这件事本身不需要任何文件句柄拦截技巧,直接从 Google 官方 Chrome 安装包里原样拷贝这个 .so 文件即可,不涉及运行时欺骗。推测(基于前四节证据的推断,是本节最重要的结论,但严格说没有一条一手资料直接写"魔改 CEF+正版 CDM.so 在 Linux 上等价于官方 Chrome",建议团队用实测验证)。

6. CDM 版本吊销(revocation)节奏

核心结论:能查到两次具体的吊销事件(2022 年底、2024 年底),间隔大约两年;更早的历史记录没查到。吊销对固定版本的云端机队是"全员同时失效"式的冲击,这点在架构决策上要认真对待。

  • 2024年10月31日:Google 吊销了所有早于 4.10.2830.0 版本的 Widevine CDM,要求 Chrome 117 及以上才能正常拿到证书,报错码为 7110/7115 一类。DoveRunner/Axinom 等 DRM SaaS 服务商的公告页面显示,他们提前对客户做了通知("we informed earlier about Google's plan to revoke")——但具体提前了多久(几天/几周/几个月)没有查到确切数字。确认(吊销事件本身,DoveRunner/Axinom/Bitmovin 等多方独立报道一致)+检索缺口(确切提前通知周期)。
  • 2022年:Chrome 107(2022年10月25日发布正式版)带了新版 CDM,新 CDM 从 9月29日 在 Canary channel 开始铺开,11月15日扩展到其他 Chromium 内核浏览器,老版本 CDM 在 2022年12月6日被正式吊销——从 Canary 首次出现新 CDM 到老 CDM 被吊销,大约跨越 两个多月。较可信(bitmovin/xda-developers/doverunner 报道口径一致)。
  • 更早的历史事件(如 2016、2020 年前后):检索未能找到公开、可引用的具体记录。明确的检索缺口——如果需要完整的历史吊销频率表,需要进一步深挖 Widevine 官方 news 页面(widevine.com/news,本次未能展开查阅)或 DRM 行业 SaaS 服务商(Axinom/DoveRunner/Verimatrix)的历史公告归档。
  • 对云端机队的影响(推测,基于机制推导):吊销是按 CDM 版本号硬切断的,不是渐进式降级——一旦某个版本被拉黑,license server 会直接拒绝该版本发起的所有新证书请求。如果云端机队用的是固定/冻结版本的 CEF+CDM(这正是很多"魔改稳定版"部署会做的事,因为怕升级破坏兼容性),吊销发生的那一刻,整个机队会同时、全量失效,不是个别节点出问题——这跟"缓慢的、可观测的性能衰退"完全不同,更像是一次没有预警窗口内测试余地的"开关式断供"。运维上必须假设:CEF/CDM 必须能跟着 Chrome stable 频道持续升级,不能长期锁定某个版本,否则要为"某天全线播放失败"这种场景准备好应急预案(比如提前监控 Widevine 官方吊销公告、给机队留自动升级或至少快速手动升级的通道)。推测(机制本身确认,但"多久没人管会撞到吊销墙"这种具体时间窗口,没有找到过硬数字,只能类比上面两次事件之间大约两年的间隔做粗略估计——不代表下一次一定是两年后)。

检索缺口汇总(明确没查到、需要团队自行验证的东西)

  1. libwidevinecdm.so 在 Linux 运行时是否真的会尝试打开某个 .sig/签名文件 ——没有 strace/逆向证据。这是本报告影响判断最大的一个缺口,强烈建议团队自己在目标 Linux 发行版上跑一次 strace -f -e trace=open,openat,openat2 观察官方 Chrome 播放 DRM 内容的过程,几十分钟就能拿到比继续查文献更可靠的答案。
  2. Linux .deb/.rpm 包内是否 100% 不含任何 .sig 类文件 ——是"未找到反例"的间接确认,不是直接翻查过官方安装包文件列表得出的结论。建议团队直接 dpkg -x 解包一份官方 google-chrome-stable 验证。
  3. Disney+ 当前(2026年)在 Linux Chrome 上的确切状态和分辨率数字 ——唯一的近期信源(LinusTechTips 论坛帖)因 403 无法完整抓取,只有搜索引擎摘要,时间点也不确定。
  4. HBO Max / Max、Apple TV+、DAZN 在 Linux Chrome 上的确切分辨率上限数字 ——均未查到可引用的具体 P 数,只有"受限"这个定性结论。
  5. DAZN 官方帮助页面原文 ——被目标站点 403 拦截,只有第三方转述。
  6. seccomp-notify 在无特权容器里给"已存在的其他进程"当监督者,是否需要 CAP_SYS_ADMIN 或特定 user namespace 配置 ——查到的资料聚焦"父进程注入子进程"场景,不完全等同于本题场景。
  7. FUSE / bind-mount 方案在无特权 Docker/K8s 下的确切权限要求 ——本节只做了浅层检索,基于通用知识推断,没有专门查证。
  8. Widevine CDM 吊销的完整历史列表(2022、2024 年之前的事件)及每次吊销的确切提前通知周期 ——只查到 2022、2024 两次,更早的记录和精确通知窗口都没查到,需要查 widevine.com/news 或 DRM SaaS 服务商历史公告继续深挖。
  9. Google/Widevine 官方是否有任何一手文档正面写明"Linux 不支持 VMP"这句话 ——目前最强的证据来自 castlabs(Google 授权的第三方合作伙伴),不是 Google/Widevine 自己发布的文档;Widevine 官方开发者文档大量内容需要授权登录才能看到,公开渠道能查到的信息本身就是被授权门槛筛过的。