标签归档:プリコネR

重拾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

 

プリコネR 1.6 与 cdb、通信加密 与 coneshell.dll

早在版本更新前的一次资源更新的时候,我这边就注意到master db的改动了,新增了一个cdb,编码不明,但应该就是用来新版本的加密版db。当时故障原因是一直以来masterdb manifest只有一行,所以我直接拆逗号,但这一次cdb在unity bundle前面,于是提取失败cron爆炸

当时改完了正规按行读取后就等着新版本了,想着肯定会大改这部分。于是 8/3 的 10002700 更完,一周后1.6就更新了

下完dmm版扔进dnspy,直接看到这么个切换cdb的代码

而当跟随这个OpenCustomVFS之后,发现他调用了一个 coneshell.dll 里面的函数,而这个dll只有一个导出入口,作用是循环输出一个数组里的函数指针

然后就是和dll战了几天,本来想研究透内部逻辑的,然后星月佬一句“你调用不就完了,linux还有wine”,于是…我就扭头去模拟调用了()

不过就算是调用,也要摸好半天各种函数。打开cdb我模拟了半天也没成功,那天我就直接睡了,后来Utaha写了个另一个版本的代码给读出来了,然后调用 sqlite3_backup_init 直接保存出来db了。

就在研究cdb的时候,我又注意到另一个事情:服务器一直在报代理失效,判定原因是返回200但无body内容。而我手动curl的却发现代理没有问题,排查了好久,最后把完整的header和body都带上,果然0长度了。也就是说1.6不仅改了db,还改了通信。那天发现到这里我就去上跑步机了,在跑步时候我就发的“我有种预感,我一会儿还会碰到一个coneshell的调用”。跑完下来继续研究发现果然,unpack里还是一个外部调用。

刚开始本想直接拆一个客户端的响应,但是一直都是unpack出错,最后Utaha给我提说是有一个初始化的函数,输入了udid和随机32B。于是发觉拆解已有响应好像还不如直接自己构造客户端容易

摸了半天之后才算摸清了各个函数的用途与参数

然后经过一通猜测body并对比已有的请求大小,构造出了一堆请求后,才终于看到服务器返回的不是错误的212字节而是492字节了,也就是说构造成功了,接下来就是扔给dll 解包了

但是当我直接扔给了 _g 的时候,他依然给我返回了-1……想了二十分钟整理了下逻辑,意识到如果是游戏正常运行的话,是pack之后等待响应然后紧跟着unpack的,这里会不会有内部状态的改变?于是在unpack之前我又调用了一次pack,这次res正确返回了解包长度,成功了!

于是美滋滋完成编译,rpm源还只有x64 wine,又去找了个一键x86 wine编译在服务器跑了一个小时才跑完。然后就直接扔上去了,于是service back online(

redive/main.php

Coneshell_call/main.cpp


后话:

我挂上了新版本cdb代码,原本猜测的是Hatsune’s Notes现有版本估计就完全死了。但是14号 10002800 更新后发现怎么还有bundle版本的db,虽然有点奇怪cy为什么还不停用传统db,不过他有我就继续用着

这几天其他几位大佬依然在缓慢地彻底研究内部逻辑,我这种不会的咸鱼只能在旁边膜了


8/22 后记2

你西歪太拼了,我这刚完成没几天,现在有了cdb ver.3了,怕是下版本实装


8/28 后记3

cy昨天更了167了,cdb ver3 online

我这种菜渣,拆是不可能拆的,这辈子也看不懂汇编的,您们谁大能收了西歪吧

prcn-ios-1.6.7.7z

等一个最终提交,这破游戏我研究也就到这了,打扰了,告辞

cy,我前天拆cdb的时候,你偷看了吧

有关redive的一些

プリンセスコネクト!Re:Dive

这一阵从土豆开始,到这次redive,逆向技能提升了不少

有了上次土豆的经验,这次一上来是准备抓网络的,结果死活进不去游戏,搞得我还以为梯子不够完备。第二天song跟我说这游戏检测root,然后我看了一眼发现他检测越狱,还是用objc检测的,笑死。flex用不了不清楚原因,随手theos编了个hook就进游戏了


进去后熟练下断点,直接下在AesManaged里,结果没触发。懵逼一阵搜到了RijndaerManaged,在这里抓到了密钥,fiddler响应一解,开了,欣喜试了个其他的,崩了

然后测试了下发现动态密钥,惊了。沿着找了一阵也没找到,于是放弃搞网络


打了一天后过不动图了,群里满是喊着”等一个科技“。然后我前几天看到过一个相关的文章,仿照着写了个hook,把atk开了个根号。出于好玩顺便试了下教程战役,结果简直笑死

hp设为5000:

hp设为1:


晚上的时候顺手dump了一波卡面,这游戏卡面真美,社保了

BaiduPCS