之前经过较多的研究，对于QCAT6, QXDM, QUTS, PCAT等都有了自己成熟的解除限制思路。然而随着QCAT6的进一步停止维护，大部分日志出现QCAT6无法解析的情况，不得不升级QCAT7。 QCAT7的总体破解思路和QCAT6类似，虽然是64位的程序，但是主要的破解点却没有改变。照猫画虎以后， QCAT7轻轻松松的就可以运行了。但是却遇到一个新的障碍，QCAT7对于日志进行了芯片级的license限制，而且license限制的校验放到了QUTS里面，由于对于这部分新加入的功能不熟悉，短时间内无法迅速破解这个限制。具体的现象如下所示，打开一个别人发的log，会出现对应的芯片平台没有License的情况。
000.png (18.33 KB, 下载次数: 0)
下载附件
2023-12-13 21:32 上传
用010 editor打开日志文件，发现高通确实在新的文件格式hdf里面做了手脚。 如下可以看到文件头中多了好多信息，包括了芯片的平台型号和RSA KEY
0.png (74.87 KB, 下载次数: 0)
下载附件
2023-12-13 21:33 上传
1.png (78.6 KB, 下载次数: 0)
下载附件
2023-12-13 21:34 上传
这个key的作用到底只是校验芯片的license呢，还是解密日志的其他内容呢。 庆幸的是，经过好多天的对比验证，发现这个key只是用来校验芯片license的，并不会对后面的所有日志进行加密解密，也就是hdf里面的日志主体内容仍然是明文方式。
那么应该怎么去掉这部分校验呢。 尝试把所有的key部分删掉或者设置为全零都宣告失败。
经过仔细对比老日志的hdf头和新日志的hdf头，发现老日志的文件头要短的多。以老文件头为模板，后面拼接日志主体，或许是可行的。
找到一个老日志的hdf头，经过反复研究，发现这个头的长度是0x1e7. 并且唯一比较关键的可变值是在0xB7开始的两个字节，例如下图中的 49 06,是按照LSB方式排列的，倒过来是0x0649, 代表了当前这个sector后面跟的log packet的个数。 这个个数必须要和后面的个数保持一致，（这个是需要动态变化的，其他部分都是静态的）。
2.png (32.03 KB, 下载次数: 0)
下载附件
2023-12-13 21:38 上传
另外的规律是带芯片License加密的文件头，真正的有用日志是从0x5F1这个地址开始的。如下图所示的BA 00 00 30， 那么我们形成新的解密文件的时候就需要从这里开始真正读取新的日志。
3.png (81.22 KB, 下载次数: 0)
下载附件
2023-12-13 21:41 上传
hdf文件还有一个特性就是每隔0x100000是一个主要单元，我称为sector, 每个sector的起始位置必须是0x100000的整数倍，也就是说在你新生成的解密文件时也必须遵从这个规律，而且对于加入License限制的hdf而言，只有第一个sector是受影响的，其他内容不受影响。 如下是0x100000和0x200000附近的字节流，可以看到每个sector都有一个子头，这个字头的第0xC和0xD字节代表的是接下来紧跟着的log packet的数目。
4.png (77.9 KB, 下载次数: 0)
下载附件
2023-12-13 21:44 上传
5.png (44.8 KB, 下载次数: 0)
下载附件
2023-12-13 21:44 上传
采用如上的思路开始编写解密程序，解密程序按照上述的主体算法工作之后，生成的hdf文件用QCAT7打开之后，发现一切OK。License的解密规避成功。
6.png (97.96 KB, 下载次数: 0)
下载附件
2023-12-13 21:47 上传
