关于用于冷发动机逆向分析的文本提取的初步想法
最编程
2024-03-25 22:39:37
...
【直播预告】国产数据库，一半都是花架子？”
最近在分析一款比较冷门的引擎。
首先无脑尝试GARbro，可以打开，但有加密：
可以发现貌似是叫ShiinaRio的引擎，google一下，发现没有任何有用资料。
用010editor打开随便一个压缩包：
标识为WARC 1.7，再尝试google一下，还是没有资料。
GARbro的源码里面倒是有WARC 1.0的解包封包源码，有一定的参考价值。
下面用IDA打开，搜索关键字符串WARC，可以发现：
可以发现该字符串只再一个地方被引用，转到引用地区，发现该代码区域IDA无法解析：
尝试创建函数，提示：
有点奇怪，转用OD打开并转到该地址：
可以发现在该地址前面有用je跳了一个字节，太诡异了，如果在该地址不跳那整个程序不就崩了吗？除非通过非常巧妙的构造才可以继续执行，另外注意到其上面有一个xor edi,edi，这句清零不是会把ZF标志位置1导致je必定跳转吗，怀疑是为了混淆IDA添加的，所以打开010editor
将该结构的代码nop掉，同时注意的也有7501?这样的，也同样nop掉，备份一下再用IDA打开：
便可以创建函数并反汇编成C语言了。当然这样之后改文件就无法正常运行，但我们仅用它来做静态分析还是可以的。
当然有可以用angr或用IDA的脚步来自动化处理这种混淆。
然后继续尝试动态分析，用OD打开，但发现运行就会崩溃，故尝试用x32dbg。（习惯问题，不得不说总体而已x32dbg更优秀一点，但x32dbg的堆栈没有OD的api参数提示，个人特别不习惯，而且x32dbg的自动字符串提示没有OD好。）
发现此处出现异常，显然，eax为0，而又把eax当作地址使用，出现异常。一个是用异常反调试。
转到IDA的导入函数，果然发现SetUnhandledExceptionFilter，随手还发现了IsDebuggerPresent，当然该api的战力只有5。
基于异常的反调试技术就是用SetUnhandledExceptionFilter设置异常处理函数然后主动触发异常，当然x32dbg的反反调试技术也很强大，比OD要好不少，有一个ScyllaHide插件可以解决这个问题。
然后转到IDA中调用WARC 1.7字符串的地方，跟踪一下，可以发现有循环异或等代码，且用eax、esi等寄存器作为CreateFile、ReadFile等API的地址调用，怀疑是解压算法，找到调用该函数的位置：
可以发现为该函数传入了两个字符串，一个是压缩文件名，另外一个是该压缩文件中的一个文件名。
不停的运行，发现会传入不同的字符串，然后进入游戏后点开始游戏，变会发现：
显然，应该是开始尝试解压第一章的文本。
（另外，发现如果一开始禁用断点，进入游戏后再启用断点程序就会崩溃，不知道为什么。）
所以我们可以分析以上的解密算法来得到文本，理论上这样是可行的，但特别麻烦。
我们也可以找到内存中解压后的文本，这样dump就比较方便。
找到游戏第一章的一句台词：
日语游戏一般都是shift-jis编码的：
在x32dbg中搜索该文本，发现找不到，主要是因为x32dbg貌似只能搜索一段内存。
但我们可以用CE，CE也是一个功能十分强大的工具，附加后搜索该字节串：
可以发现有几个地址，但有的只是显示文本的地址，我们要找到文本文件中的地址，但也很容易，一个一个找就可以了，主要要在x32dbg中搜索地址，因为CE不支持内存dump。可以找到如下内容：
选择pro01_01往下区域的内存导出就可以了：
当然该方法还不能自动化，封包问题也没有解决，不少地方还需要完善。等有时间在搞吧。