gmg2719 发表于 2023-12-13 21:47

高通QCAT7日志解析时芯片license限制规避另类思路

注意:仅供学习使用,仅为个人爱好,不提供任何成品,而且只提供大体思路,以免产生不必要的麻烦。

之前经过较多的研究,对于QCAT6, QXDM, QUTS, PCAT等都有了自己成熟的解除限制思路。然而随着QCAT6的进一步停止维护,大部分日志出现QCAT6无法解析的情况,不得不升级QCAT7。 QCAT7的总体破解思路和QCAT6类似,虽然是64位的程序,但是主要的破解点却没有改变。照猫画虎以后, QCAT7轻轻松松的就可以运行了。但是却遇到一个新的障碍,QCAT7对于日志进行了芯片级的license限制,而且license限制的校验放到了QUTS里面,由于对于这部分新加入的功能不熟悉,短时间内无法迅速破解这个限制。具体的现象如下所示,打开一个别人发的log,会出现对应的芯片平台没有License的情况。


用010 editor打开日志文件,发现高通确实在新的文件格式hdf里面做了手脚。 如下可以看到文件头中多了好多信息,包括了芯片的平台型号和RSA KEY




这个key的作用到底只是校验芯片的license呢,还是解密日志的其他内容呢。 庆幸的是,经过好多天的对比验证,发现这个key只是用来校验芯片license的,并不会对后面的所有日志进行加密解密,也就是hdf里面的日志主体内容仍然是明文方式。
那么应该怎么去掉这部分校验呢。 尝试把所有的key部分删掉或者设置为全零都宣告失败。

经过仔细对比老日志的hdf头和新日志的hdf头,发现老日志的文件头要短的多。以老文件头为模板,后面拼接日志主体,或许是可行的。
找到一个老日志的hdf头,经过反复研究,发现这个头的长度是0x1e7. 并且唯一比较关键的可变值是在0xB7开始的两个字节,例如下图中的 49 06,是按照LSB方式排列的,倒过来是0x0649, 代表了当前这个sector后面跟的log packet的个数。 这个个数必须要和后面的个数保持一致,(这个是需要动态变化的,其他部分都是静态的)。




另外的规律是带芯片License加密的文件头,真正的有用日志是从0x5F1这个地址开始的。如下图所示的BA 00 00 30, 那么我们形成新的解密文件的时候就需要从这里开始真正读取新的日志。



hdf文件还有一个特性就是每隔0x100000是一个主要单元,我称为sector, 每个sector的起始位置必须是0x100000的整数倍,也就是说在你新生成的解密文件时也必须遵从这个规律,而且对于加入License限制的hdf而言,只有第一个sector是受影响的,其他内容不受影响。 如下是0x100000和0x200000附近的字节流,可以看到每个sector都有一个子头,这个字头的第0xC和0xD字节代表的是接下来紧跟着的log packet的数目。


采用如上的思路开始编写解密程序,解密程序按照上述的主体算法工作之后,生成的hdf文件用QCAT7打开之后,发现一切OK。License的解密规避成功。

Networktest2022 发表于 2024-5-28 17:54

感觉这个思路感觉 不对啊
去解密日记文件?那如果日记文件很多,那不是一个个来解密,会很麻烦?

是个憨憨 发表于 2023-12-13 21:56

高级,不过正规客户不是都能拿到license吗?老哥为啥要自己破解

yyzzy 发表于 2023-12-13 21:59

挺厉害的楼主

moruye 发表于 2023-12-13 23:12

sdieedu 发表于 2023-12-14 06:34

干啥的软件,好奇

baoqingzxc 发表于 2023-12-14 10:28

很厉害的思路,谢谢楼主分享!学习了!{:1_893:}

WilsonZtw 发表于 2023-12-14 11:19

能搞NR5G, 应该不缺License吧{:1_904:}

luoyin168 发表于 2023-12-14 14:18

谢谢楼主分享!学习了!

APWN 发表于 2023-12-14 15:29

强啊楼主,不过没碰过这类知识,这下又了解了一点

hackerSQL 发表于 2023-12-14 17:56

页: [1] 2 3
查看完整版本: 高通QCAT7日志解析时芯片license限制规避另类思路