by devseed, 本贴论坛和我的博客同时发布

之前发的Galgame汉化中的逆向系列，大多是结合具体游戏来谈谈分析思路与汉化方法。大多数主机游戏可执行文件都是魔改的ELF文件（比如说psv，ps4系统内核就是由FreeBSD修改而来的），不同于以x86架构为主的pc平台，主机平台架构可谓是百花齐放：psp，ps2是mips架构，ps3是powerpc架构，ps4是x86架构，psv是arm架构，switch是arm64架构。ps4的x86架构修改方法和pc版类似，powerpc架构的汇编暂时还没研究，mips架构汇编相关的分析，今后有时间可能会更新教程。由于arm指令一般情况下都是4字节定长（还有2字节的thumb指令），mov，ldw等指令的立即数有范围限制，寻址方式多为相对于PC的偏移寻址，这与x86里立即数可以直接写VA地址（如FF 15系列长跳转指令、b8系列的mov）有很大区别。因此这篇作为《galgame汉化中的逆向》系列教程的补充，来聊聊ELF结构、如何对ELF修改、Arm汇编寻址方法以及如何修改Arm汇编中字符串的指针。

一般来说主机游戏剧本、字库等都在资源文件（封包文件）中，可执行文件中只有少量的系统文本。这部分通常也不需要汉化比原字符长（因为系统文本一般没有太多含义，且汉语本身就比较简洁），因此直接替换二进制字符就行了。但是对于一些特列，即字库或剧本整体封在了可执行文件中，就要增加区段和用汇编修改指针把字符串重定向到新增区段中了。如psv、switch版的Gnosia，和psv、ps3版的WhiteAlbum2，修改eboot方法详见PSV版WA2汉化移植。

为了更直观地说明原理和看到运行结果，本篇教程将不以具体游戏为例，而是用arm版helloword程序，讲解一下修改arm、arm64 ELF的方法。理论上适用于psv、swich、android平台的可执行文件或动态库，根据不同平台可能需要再转换为其对应的魔改ELF格式。

本篇教程需要的工具：

参考网站：

https://www.mztn.org/dragon/arm6405str.html

http://armconverter.com/

安装脚本如下：

最简单的hello world程序代码：

交叉编译命令行：

运行命令行：

Linux系统的可执行文件和动态库为ELF格式，与windows的pe类似。里面的几个重要结构为：ELF header、Section Header Table‘、Program Header Table。关于section和segment关系如下

ELF文件的段结构就是由段表决定的。
编译器、链接器和装载器都是依靠段表来定位和访问各个段的属性的。
段表在ELF文件中的位置由ELF文件头的“e_shoff”成员决定的。

常用readelf来查看elf结构，objdump来查看反汇编，命令行如下：

关于添加新区段，可以自己手动修改ELF文件头对应的索引增加区段，可以参见android so手动增加区段。我以前也写过windowsPE增加区段的轮子simpledpack，这次就不再自己造轮子了，直接用lief解析ELF了。这个库逻辑挺清晰的：

lief.ELF.parse(path)-> LIEF::ELF::Binary，解析elf，

lief.ELF.Section(name, type)，创建新section

a. 添加区段并patch例子：

b. 扩容区段例子：

c. sym替换（类似于IAThook）

32位的arm通常是通过当前PC寄存器找到内存偏移表地址，再通过表中偏移计算出最终地址，相当于两次对内存寻址找到最终地址。通常用add pc, Rd或adr Rd, offset，之后ldr Rd来获得最终地址。内存偏移表通常在一个函数的结尾处（BLX LR函数返回后），每项存储4字节偏移。

thumb指令为2字节定长，在psv的eboot和android的so里面会经常出现这种指令集。

这种情况下内存偏移表存储的是相对于add Rd, pc的偏移，即value_addr-pc-4，下面通过实例来分析：

可见ida里面机器码为文件中的字节顺序，指令转义为了ldr伪指令；而objdump中机器码为小端整数，指令转换成直接对应汇编的样子，因此学习arm汇编看objdump比较直观。

13f78：4825 ldr r0, [pc, #148]为访问内存偏移表内容指令，偏移表地址13f78h+4+#148(94h)=14010h，即把偏移表存储的偏移34BF0h载入r0；偏移表里的内容为.text:00014010 F0 4B 03 00，是相对于13f7c: 4478 add r0, pc的偏移；13f7c:4478 add r0, pc，最终地址为34BF0h+13F7Ch+4=48B70h。

arm 4字节ldr，adr伪指令转换为add register, pc [#offset]。机器码的存储格式如下：

同样有内存偏移表，但此偏移表存储的偏移值为相对于偏移表地址的偏移。下面为编译的hello_arm中_start函数的反汇编内容：

658:f8df a024 ldr.w sl, [pc, #36]为加载内存偏移表内容指令，658h+#36(24h)+4=680h为内存偏移表地址，加载内存偏移表存储的偏移值1092ch到s1寄存器；65c:a308 add r3, pc, #32，紧接着将r3载入内存偏移表地址，即65ch+#32(20h)+4=680h。65e:449a add sl, r3得到最终地址1092ch+680h=10fach，因此这里内存偏移表内存储的偏移是最终地址相对于内存偏移表地址的偏移。

由于arm汇编是用PC和内存偏移表进行寻址，所以修改ldr的最终读取的地址仅需要修改内存偏移表中的偏移。

修改arm汇编字符串地址的测试用例如下：用lief增加区段，内容为"hooked str hello world!\n"，capstone反汇编解析ldr的内存偏移表地址，修改内存偏移表内的值改为新增加区段的字符串相对偏移（注意偏移值是相对于add pc处的，脚本里统一用VA相减表示）

运行patch脚本后，qemu测试hook成功！

arm64和arm同样是定长指令和相对于PC的寻址，只不过arm64没有内存偏移表了，用adrp @page和add|ldr @pageoff来寻址。

ADRP指令是以页为单位的大范围的地址读取指令，P为page, pageoff为page offset，这里填写的地址是最终地址的页基址，汇编会自动把opcode转换成相对于pc页基址的地址。

符号扩展一个21位的offset（immhi+immlo）。向左移动12位，将PC的值的低12位清零，然后把这两者相加，结果写入到Xd寄存器，用来得到一块含有label的4KB对齐内存区域的base地址（也就是说label所在的地址，一定落在这个4KB的内存区域里，指令助记符里Page也就是这个意思）， 可用来寻址 +/- 4GB的范围（2^33次幂）。

下面是几种指令的机器码比较：

下面代码说明了，adrp的机器码immhi+immlo存储的是相对于当前页面的页偏移0x22000，但是反汇编后显示的则是目标的VA，即adrp x0, #0x25000(当此指令在0x3000处时候，cs.disasm(code, 0x3000))。

adrp @page 找到目标页地址，add @pageoff加上页内偏移。如果用ida的keypatch修改，需要去掉@page，@pageoff后缀，手动来计算目标页地址和页内偏移才行。ida和objdump的反汇编代码如下：

下面的python脚本说明了如何用capstone进行反汇编，如何手动求目标页地址和页内偏移，以及之后用keystone进行汇编更新adrp @page和add @pageoff指令。

运行patch脚本后，qemu测试成功！

这篇教程虽然难度不高，本来以为很快就能写完了，但是写了好久。很多东西叙述起来很麻烦，我尽量结合实例清晰和有条理性地讲述，不知不觉中写了好多东西。目前关于主机系列的汉化教程非常少，以往很多的教程也都随着论坛的关闭等无法访问了。同样，比起x86的汇编的修改，arm64 elf之类的分析也不多。我系统地做《galgame汉化中的逆向》系列是想总结一下汉化方法，结合我自身对一些问题的思考和理解，以使汉化逆向这门技术今后能更好地传承下去。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课