上节谈了一下一般pc游戏的文字编码与系统字库的调用，
但是主机游戏和部分pc游戏通常自带字库，这些字库有的是标准格式，而有的则是自定义格式。
自定义格式字库通常由两种类型：tile font， texture font。

此篇教程将以一种不同寻常格式的texture font为例，谈谈如何来分析自定义字库。

上期：Galgame汉化中的逆向（二）：系统字库与文字编码
同样，本系列教程和隔壁，贴吧发的内容完全相同。

此游戏字库很显然是font48.xtx，观看文件头xtx格式，后面的01是type。猜测再后面就是height，width，aligned height, aligned wight， offset相关的了（这里面有个坑人的地方是这游戏文件头是big endian，我看了好久才看出来）。

看到文件大小为900020h，结合数据猜测正文是0x20开始。

看着数据很规整，猜测没有压缩，但是查看纹理或者tile无论怎么看都很奇怪。
但是texture可以看出来大概几个数据块，所以很大可能是这个字库的数据流读取方式有问题，
我们需要找到这个字库读取顺序。

游戏引擎将字库纹理以正确的字节流顺序载入，然后加载到显存里，由d9d9渲染到屏幕上。
可以从文本缓冲区入手，去跟踪d3d9了。
这部分说起来比较麻烦，因为是COM接口没有函数名称，非常需要耐心（对照d3d9.h来找）。
跟踪从d3d9.Direct3DCreate9开始，找到初始化ID3DXFont，然后再看调用栈找到字库读取函数。

由于arc_unpacker的大佬已经分析过了类似的字体，跟踪过程过于冗长我们跳过跟踪这步，直接用结论来进行了。

此font48.xtx字库编码为GRAY4，每个字符为48X48，共8192个字符。 block为48字节，每个block含4个坐标。

字库读取代码

逆向出来的核心代码就是这么多，读取字库中的每一个字节，然后确定这个字节转换为图中的坐标(get_x(i, ), get_y(i,))。
但是光看估计很多人会对求坐标值的一堆位运算劝退，那么这些匪夷所思的位运算是在干什么？

这个时候静态很难看出来位运算在干什么，这时候我们就可以用打表法来看看到底字节流都到了图上的哪里去了。
打好表后规律一目了然，这也是这个字库最有意思的地方。

打表法打印字节流顺序与像素位置关系

用excel观看生产的表格，数字表示字库中的位置(i)，用不同颜色隔开相邻chunk。
图中元素每4X8个像素构成一个小chunk，然后4X4个小chunk构成了一个大chunk。
这是一种分形结构，level=2为分两次，也就是我们所说的套娃。
（怪不的位运算那么一坨乱七八糟的，所以才说禁止套娃呀#滑稽）

找到规律再检验一下，ok字库提取没问题，标准的完成版shift-jis字库。

接下来的步骤就是重建字库了，重建分3 步：

(1) 建立简体字库的png图片，
(2) 修改fontmap或者将gb2312编码映射到sjis上，生成映射后的码表（.tbl）
(3) 将png转换为该游戏字库格式

现在来详细分析一下针对此游戏的方法：

（1）建立图片这个方法太多了，要求是每个字大小48X48，图大小6144X3072。
  最简单的方法是用PIL的ImageFont打印，其中大小px要转换为pt。
（2）此游戏的fontmap我没找到，严重怀疑游戏是通过计算来得到的图中位置。
  sjis编码的范围是程序里写死的，要改动涉及到的地方太多太麻烦。
  本游戏的字库基本上是完整的sjis字库，从0x8140开始每个sjis字符包括不可打印字符都有（除了末尾的部分字符），
   因此直接把gb2312按顺序映射到sjis编码即可，新建字符顺序是sjis但字符是简体字。
(3) 这部解包和封包差不多，只要把src和dst方向对调就行（当然宽高大小之类的参数要微调一下）

由于封包和解包算法非常相似，这里不再赘述，完整的程序可以参考我的github。

e2fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6k6N6i4u0A6f1$3W2*7N6h3E0#2i4K6u0r3c8$3q4D9k6$3q4E0k6g2u0W2N6X3g2J5M7$3g2Q4x3V1j5`.

本文分析了一个比较奇怪的套娃字库，简单的演示了一下一般游戏涉及到自定义字库如何处理，

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