by devseed, 本贴论坛和我的博客同时发布
上期链接：Galgame汉化中的逆向（四）_IDA静态分析psv游戏

之前我们谈论的基本上都是静态汉化。所谓静态汉化，即分析文件结构、二进制脚本opcode，然后进行静态封包等方法。与类似于静态编译的语言类似，在运行前数据类型等已经确定完成，程序运行时按照既定的逻辑执行，静态汉化显示的是我们提前准备好的汉化文本。大部分的主机游戏汉化都是静态汉化，因为权限等问题，主机几乎不可能动态调试（即使有，gdbserver等用起来也挺费劲，也可能有兼容性问题调试失败）。再加上在主机上hook也很麻烦，测试极不方便，所以大部分主机游戏汉化以静态汉化为主，有模拟器的可能会结合一些动态调试辅助分析（不过别指望模拟器的调试有多好用了...）。

静态汉化是基础，对于常见文件结构、二进制脚本、算法等有了一定了解后，我们才能更好地找到关键位置dump、文本注入点等，因此我之前的汉化教程都是以静态汉化为主。与静态汉化相对的是动态汉化，往往不需要进行复杂的文件分析和二进制脚本分析，通常也不用考虑封包问题。动态汉化中，文本显示是程序运行时动态注入和替换的，重点是找到：

目前关于动态汉化的分析帖相对来说比较少，下面我们就以Majirov3引擎为例，来谈谈如何进行动态分析、如何进行动态汉化、以及如何解决一些动态汉化中出现的问题。

动态汉化的第一步，动态dump封包中已经解密完成的二进制脚本，从中提取文本和对应的偏移。那么如何去找呢？通常可以在游戏运行时候去搜索内存中的特定文本，找出最像是二进制脚本的那部分（可能有多个搜索结果，但有些并不是源头，类似于用CE去搜索会有多个数值匹配），然后下硬件访问断点，看是哪些代码生成的。

但是这个方法有个问题，解密文本的位置可能是malloc动态生成的缓冲区，重启调试器后位置会改变，导致断点失效。这时候我们可以考虑hook文件访问的API，如fopen,CreateFile等，来顺藤摸瓜找到读取封包和解密文本的位置。有可能没有动态链接msvcrt.dll，而是静态链接到exe里了，导致导入表没有此函数。一般ida可以识别出这些静态链接的C库函数，如下：

之后我们可以对这些函数进行hook，此游戏用的都是c库函数进行文件读取。代码如下：

之后我们可以查看日志，在进入章节的时候，看看是哪些函数调用了文件API。

fread的读取数据的大小可能和二进制文件的结构相关，比如说第一个fread先在scenario.arc文件开头读取了0x1c大小，我们可以推测文件头的大小是0x1c。用同样的方法，可以顺便把封包结构分析出来了，包括封包内的每个子项(mjo)数据结构。下图为scenario.arc在开头和0x114dfb位置的内容，观察发现在utf-8或sjis下没有有意义字符串，可以断定mjo是加密或压缩的

majiroV3封包文件结构总结如下：

当然了，这个封包结构很简单，直接静态黑箱分析也完全能猜出来，上面只是为了演示一下动态分析的一些思路。分析封包文件结构不是必须的，但是可以帮助我们更好的找到解密文本的位置。之后，定位到fopen，scenario.arc后的fread，在缓冲区下写入断点（此地址就是之前所说的每次都会变的malloc地址），即可定位到解密文本的内容。

或者通过日志0x440cd6 fread(0x80f3b0, 0x10, 0x1, 0x4ca198) offset=0x114dfb的返回地址0x440cd6，找到准备读取每一个mjo的函数，即sub_440AB0。这个引擎定位还是比较容易的，有日语错误信息辅助定位，默认显示乱码，需要把IDA的Cstyle default-8bit encoding改成Shift-jis编码。

我们已经找到了二进制脚本读取的函数，稍微分析一下不难找到文本解密函数sub_478E70。虽然用了SSE指令集优化，但是不难分析的，典型的xor加密，ida伪代码可读性已经很强了。本节以动态dump讲解为主，此处就不再详细分析解密函数了。

关于具体的dump点，可以在sub_440AB0的末尾进行hook，返回值eax为mjo_struct指针，同时储存在[4DC350]全局变量中。下面为此函数返回处的反汇编代码：

根据sub_440AB0反汇编伪代码（见上节）中的sub_478E70(*((__m128i **)context + 0x29), *((_DWORD *)context + 0x24))解密函数，可以得出下面结论：

有了这些信息，我们可以写dump解密文本函数了，如下：

dump完后，查看一下，二进制脚本已经解密。至于提取剧本，简单观察大概是这样的结构40 08 [size 2] text 00，匹配这种结构即可，当然也可以直接检测sjis编码提取，详见我写的binary_text.py。

动态汉化的好处是我们不用去费半天劲逆向封包算法、不用再去分析二进制指令opcode。

但是同样动态汉化也有一些问题：

因此，选择文件hook点的位置，原则上越接近原始位置(读取二进制文本的位置)越好 。直接搜索显示在屏幕上的文本，得到的搜索结果可能有多个，分别修改一下看看对游戏产生什么影响。同时也要兼顾能否找到当前文本在脚本中的偏移来进行定位，在查找到文本缓存的周围（如堆栈中的指针，寄存器，或者反汇编指令里引用的全局变量）来找找有没有标识当前文本在二进制脚本中位置的指针。下面的反汇编为本游戏的一些显示文本位置：

根据测试a. showtext_screen这个位置最适合作为动态hook替换文本的位置，显示内容最接近实际显示的，而且修改后的字符串也会被记录到游戏backlog里，可供回看文本。其他的hook点有些会调用多次、有些文本不全、有些会显示过多字符（如人名，这些会作为语音标识，但不会显示在对话中）。对于显示函数的hook，总结如下：

写个脚本hook验证一下：

frida -l winterpolaris_hook.js -f Polaris_chs.exe >1.txt将脚本注入游戏，由于控制台无法显示sjis字符，因此将输出内容重定向到文件中，然后用sjis编码查看。得到的内容如下：

对照我们用binary_text.py提取的文本， 偏移（当前位置指针-解密缓冲区基址）正好是文件中的偏移，至此这个游戏动态汉化的理论研究已经完成，之后就是用c和内联汇编写程序实践了。下面是我们用于翻译的文本格式，白点列用于原文，黑点列用于译文，每行是●|num|addr|size●的索引格式，详见binary_text.h

其实有时候如果我们实在找不到文本标识的偏移，也可以强行把游戏从从头到尾过一遍，把每句输出的文本提取出来。汉化的时候，再用hashmap或Longest Common Subsequencedp计算当前文本与文本数据库中的相似度，选取相似度最高的匹配用于替换。

以上，我们谈了谈如何进行动态汉化的相关分析，方便起见都是用的frida进行hook。但是frida属于测试环境，不可能要求每个人电脑上都有这个环境，而且也可能有python版本冲突等问题。需要用尽可能少的依赖制作汉化，因此就要结合C与内联汇编来写汉化程序了。在制作汉化程序之前，来科普一下汉化游戏常用的hook方法。

即把相应函数的导入表的地址（FirstThunk）替换成我们的函数，实现hook。关于IAT结构和导入表相关内容，可以参考我之前写的文章SimpleDpack。下面是IAT hook的代码，兼容64位，详见我的github， win_hook,c

IAThook只适用于动态链接外部DLL的函数，对于exe内部的函数，就需要Inline hook了，操作如下：

不过我们不用再自己解析函数开头处的机器码了，直接用微软的detours的Inline hook即可。细节上和上述可能有些区别，不过原理都是一样的。detours用法如下：

上述hook代码编译成的载体是DLL，我们还需要把此DLL注入目标到exe中，接管某些函数改变其功能。

有三种常用方法：

代码如下，详见我的githubinjectdll.py, win_hook,c

到此，主要问题我们都搞清楚了，现在可以愉快地编写动态汉化程序了。动态汉化程序主要包括下面几个部分：

Inlinehook处汇编环境与C语言函数的对接, 注意cdecl和stdcall，汇编调用C函数要自己保存寄存器

维护日文文本与汉化文本的对应关系，文本偏移的定位等数据。并且用二分法等算法来查找替换文本等。

这里采取的__declspec(naked)形式进行内联汇编，进行获取当前文本指针、计算在文件中的偏移、调用相应的C函数查找字符串、替换汉化文本等操作。此处为了方便使用了一些全局变量，以g_前缀开头。

此处用双向链表数据结构来存储文件名与文本项索引，g_mjos全局变量来指向索引链表，g_cur_mjo指向当前文本索引位置。当游戏加载脚本时会查询当前链表中是否已经加载过，可以避免重复加载造成的内存泄露。PFTEXTS数据结构详见我的通用汉化文本格式，binary_text.h。

由于我们用的是日文和中文对照文本，因此文件用的utf-8格式存储，动态替换汉化文本要转换为gb2312格式。

lplf->lfCharSet改为0x86即可，字体改成simhei。

当然改完后读取gb2312也可能没法正常显示，因为游戏可能对字符进行限制。未处于sjis区间的字符可能会显示成方框，也可能会被当成单字节字符显示，造成接下来运行错误。

这个游戏比较特殊，没有用cmp xx 81h等直接判断，而是用了charmap映射了当前字节数值的类型，与“是否能构成sjis字符”相关。bp TextOutA可以发现非sjis字符会被当成单字节字符。再稍微跟一下，可以看见其通过查表确定是否为sjis字符，0x4AE2E9为字符类型映射表，如下图所示。

解决方法也很简单，直接用内联汇编来替换sub_47EE00，去除sjis范围限制。当然也可以去修改映射表，但是不确定是不是其他的函数也用这个映射表，改了后可能会出现问题。

最后就是处理一些小问题了，比如说有些字符没有显示全，可能是因为字体高度不够；菜单乱码等问题，可能对应的文本是通过其他函数显示的，或是菜单文本本身是在exe里面的，此处不再赘述。

折腾了半天，现在我们的动态汉化终于成功运行了！完整代码详见我的github， winterpolaris_hook.c。

虽然难度不大，但是这篇教程写了也快一天才完成，之前搜集素材、编写程序、调试等断断续续地也用了将近一周。主要是想着如何叙述得容易理解，如何使得结构清晰有条理性。其实动态汉化更多的意义在于折腾，自己一步步地探索与改造的乐趣，就像是DIY的乐趣。下面再补充一些关于编译与调试的内容。

因为windows下没有regex.h头文件，所以一开始我是用mingw的gcc来编译的。有个问题是，无法链接msvc编译的detours.lib(很多符号找不到，报错)，也不太清楚怎么用gcc编译detours。而且gcc貌似没法声明naked函数类型？

于是就用clang了，因为-target i686-pc-windows-msvc可以兼容msvc的link， 同时语法上也接近gcc用起来会比较方便。但是这个模式就无法链接GNU的静态库了如libxxx.a。虽然强行把libregex.dll.a改名为regex.lib倒是也能识别，但是没法静态链接，会附加一大堆mingw的dll。makefile如下，里面会用到我以前写的一些文件，现在都已上传到GalgameReverse。

clang编译的时候加入-g调试信息到dll中，直接用mklink符号链接把dll链接到exe所在的路径下，vscode里面launch.jsonlldb中program填写对应的exe。在C源代码下断点，F5启动exe即可调试。launch.json如下：

不过vscode目前好像不支持内联汇编调试，那么就用x64dbg调试吧，可以读取到调试信息并显示源码行数。这里有个小技巧，我们可以打印出来Inlinehook的地址，然后再用x64dbg调试，方便定位。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！