2023-01-10   

在很早很早之前，就流传着一套copyrightDRM的算法，是通过R1,encryptR,copyright三个参数通过js函数计算出最终的Key。而这三个参数都是直接可以在H5player._manage.global里轻松找到的，所以基本上等于形同虚设。

后来优酷更新了js，把其中最关键的R1参数隐藏了，encryptR,copyright两个参数在请求报文中还是以明文的形式存在，直接过滤m3u8关键字就可以抓到这条报文。但因为缺少了一个参数，于是乎自研DRM一时间无法从网页获取了（也可能是我太菜了）。

但就在大约半年前，优酷又进行了一次更新，更新了什么我不清楚，但对于破解来说，基本上算是反向更新了，因为密钥暴露的更加明显了。正如我之前的一篇文章，可以直接在控制台获取到最终的Key了。

而且就在刚刚，我神奇的发现，其实R1就静静地躺在控制台最明显的地方，改名为_pwd1,。于是乎我就在想，既然存在于控制台，那就一定有相关的js函数进行操作，三个参数是相互关联的，所以必定每次都会改变，然后我就开始了漫长的寻找道路。

一开始，我的想法是R1和encryptR,copyright两个参数一样，是通过请求报文从服务端传递给本地的，然而我查看了每一条报文，最终确定并非通过网络传输的，那一定就是本地生成的。

然后通过网页端设置断点，逐渐确定_pwd1赋值的语句（因为我太菜了，花了俩小时）

最终确定了是在index.js中完成了对_pwd1的赋值

图中第一行是对R1的赋值，第二行是对R1进行加密，生成encryptR1

而且_sce_lgtcaygl，sce_r_skjhfnck这两个函数也很明显，调试过程中可以发现会直接跳转至done_aes-secret.js，直接调用即可。

那么问题来了，解密的原理是什么呢？有过优酷解析经验的，其实看到encryptR1就应该有些眼熟，因为在请求mtop.youku.play.ups.appinfo.get的时候，其中biz_params中有个参数就是encryptR_client，经过比对，确认该参数就是上文中的encryptR1。

至此，自研加密的原理基本就明晰了，先是本地随机生成R1字符串，然后根据加密算法生成encryptR1字符串，通过携带encryptR1字符串请求视频M3U8链接，在返回的报文中携带与R1相匹配的encryptR,copyright两个参数，最后本地通过三个参数计算出中的Key。

如果是自用，其实我之前的文章已经给出了本地获取最终Key的JS标签了，比较简单。

而这个原理，可以用来批量获取，更适合写成接口的形式。

Q.E.D. 麒麟阁欢迎各路英雄加入QQ群(904712074)，进行技术指导、业务交流、经验分享、共同致富、意见反馈等。