金盾播放器研究

灵感主要来源B站这个视频
3a5K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2T1K9h3I4A6j5X3W2D9K9g2)9J5k6h3y4G2L8g2)9J5c8Y4k6A6k6r3g2G2i4K6u0r3b7W2j5I4P5W2W2K9g2#2W2p5c8h3y4@1i4K6u0r3
我这里就大致做个视频内容总结
通过hook readfile api 可以顺藤摸瓜找到播放视频的循环
然后找到解密循环

因为这部分没被vmp 所以放到ida里是这样的

但是路过在往上层找调用的话 就会啊发现好像被vmp了

从这个播放循环中可以找到两个重要的call 一个是读文件 一个是解密
放到x32dbg里 看看内存就可以发现 readfile读到的内容被放在一个buffer 并且解密之后的结果覆盖了这个buffer
所以视频里的方法就是直接dump解密好的内容

个人发现

我那ida仔细研究了这个解密的模块

虽说我对解密算法方面不精通 但把这段代码喂给ai就能知道 这是一个AES解密算法

再看前面的代码就能知道 算法是每16位就用AES解密一次

然后再到x32dbg里找到这个函数传进来的key
把这个key放到ce里去 查一下内存 然后惊奇的发现密钥就在之前buffer上面的16个字节里

整体的提取思路就是通过AES每16字节解密加密文件中的内容
拿python写个解密程序大概是这样

尚未解决

这部分播放循环是没被vmp的所以解决起来很简单
但是在播放视频前的密钥处理阶段被vmp了
所以这里就只是分析一下流程


在开始播放之前 也就是让你输入密码之前 金盾会读取一系列的信息
先是从文件的最尾部都四个字节 也就是int 这里是小端 大概是这样

理论上来说这4个字节应该是用于索引文件本身的附加信息 应该等于上面日志里第二次读取的大小
但细心的人会发现并不是0x00 11 0B E4并不等于7156
所以我研究了一下 发现这个值是 0x00 11 0B E4 = 0x10eff0 + 7156
我不知道为啥这里偏偏要绕个弯 还是0x10eff0有啥特殊含义 如果有大佬知道希望解答一下

读取完文件最后这些有规律的字节又读取了4字节的文件

这会没有绕弯 这四个字节正好就是接下来要读的72575个字节
因为这些字节在密钥获取之前就有了所以和原视频的解码关系不大
那这70个M的内容是啥 我这里大胆猜测 也该和金盾的一些功能的设置有关系 比如 水印 定时跳出验证框 以及不同的验证方式 这也是目前还没弄清楚的内容

最后就是启动图片 和存储在DRMsoft的密钥有关的读取
这些部分的代码都是被VMP过的 目前没什么好的办法 大佬可以提供一点思路我再去研究研究

源码我放在github上
47cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6D9N6h3g2Q4x3X3c8V1K9g2)9J5c8V1#2S2M7%4c8p5k6h3u0#2k6$3g2J5

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！