DragaliaLost速览

西歪祖传底层套件

Crackify检测越狱/root

ConeShell隐藏global-metadata.dat

 coneshell_extract_metadata.php

(ConeShell推测命名来源见重拾cdb结尾)

[CriWare Key Logger]Key: 2967411924141 hex: 000002B2 E7889CAD

10/11 无责任更新:按照反馈,CRI v2.98更新了加密方法(向后兼容的更新)。本人不负责解密算法研究。

manifest加密了,解密后大概是个标准AssetBundle

主数据库依然是cdb ver2(0xDA7A 0x0002)

dragalia_lost.7z(ida db + manifest)

我甚至没打开游戏里面,反正也不会有时间玩的,卸载了

重拾cdb

结果自己到头来还是不死心啊

还是去翻腾cdb了,记录下目前进度


9/7

拿出dll跟踪调试看了一阵,发现文件解密只涉及到开头几十行,然后文件内容就已经出来了。所以感觉比想象的稍微容易一些

首先开头有一串变换,变换完后出来一个pem公钥,然后拿着公钥对0x3c开始0x100字节内容进行解密(签名验证),得到内容比对0x2c开始0x10字节

这个没搞懂干啥的,验证文件有效?

然后进行aes解密?目前逻辑还没看懂,已经验证文件头0x8开始0x20长度数据会影响解密结果,0x4 – 0x7和 0x28 – 0x2a数据用途不明,目前看来没有意义,或者可能是后期操作有关。如果弄完密钥对文件0x13c开始到结尾的数据进行解密,就完成了

然后解密完数据直接lz4解压就可以了,虽然目前卡在aes找不出密钥

而且这些是cdb ver2的,ver3按照ios程序汇编diff看是在某一步多了对某个值的位mask操作,暂时先不看


9/8

打开ios 160和167比对后看到,cdb3对第一个初始化函数的参数(原inputPtr+8)进行了变换,而且某个参数(iv?)从+4变成了+20。本想自己提前变换写回文件结果抄完失败了,然后意识到这些部分都是有重叠,所以还是得自己搞出来才行。

但是解密前那两个初始化又是巨复杂子函数,甚至我都不知道内存里面哪个是有效密钥,挨个试都出不来结果。

于是又卡关了,gg。我好苦啊,真正牛逼的都不来帮一下,就我一个鶸在这里倒腾(人家为啥要帮你(错乱))


9/8晚(9/9凌晨)

今晚依然绝赞研究,本来想到昨晚尝试失败,今天也看不懂子函数,还得苟好一阵

然后想到我能不能改dll里面的流程?因为0x4的数据和0x8的数据有重叠,能想到的就是扔到证书验证那里。于是改dll把公钥验证步骤的jnz给noop掉,然后把那个0x4的偏移改到0x3c签名区,最后在外面递进去之前把该做的新版本的变换做好。

结果扔进去后还是失败,ショック。

于是ida复制了一波流程扔进去覆盖昨晚的手抄,F5、F10、F10……然后突然成功了!?

于是复活,等一个cdb ver4


9/22 后记

这次目前好像是稳了,cy暂时没搞什么新动作。经常google关键词也看不到其他有什么研究的,全网唯一拆解?

然后是一些细节,首先是关于那个公钥验证的,后来想了想,这个部分存在的目的是防止客户端加载假冒db,虽然细节想了想好像还是有问题,真正按照路径解密再加密回去覆盖数据段(0x13c~)不就可以了吗,或者可能还有其他我没研究透的验证(后面那么大一块呢)

第二个其实是次日就搞了更新,因为当时成功的过程是因为重新从ida复制了变换代码,所以后来又换回原始dll,变换完放回结果后把ver改回2,倒也确实能用,这就让我有另一个疑惑,0x4开头的数据按代码是读了8字节,但只有4-7影响结果,8-b并没有反应,而且还是密钥部分了(8-17),而按照复制结果来看那两部分并不相同,这又是另一个疑点。不过目前没有需求也就这样咸鱼了


9/27

绝了.jpg