林登布鲁克的冒险解包器

shane007

林登布鲁克的冒险 Adventures of Natalie Brooks  解包器
要配合QuickBMS使用。
* X: n* W7 L/ C% N5 A6 T& }
-----------------------------------------------------------------
2009.1.11 第1次更新
. g! i" A5 A2 Y: l- F( X
我大致看了一下，觉得肥牛分析的还有些问题。
& Y2 A+ Q: ^3 F+ j我先纠正第1个问题。文件的结构应该是这样的:
7 y! c4 o/ W' r/ c; F. ^字体文件名长度 4bytse
) p: A4 ]+ D/ \5 p" A$ \2 m字体文件名 nbytes
字体高度 4bytse
字体数 4bytse
字模数据 字体数X24 bytes
尾部未知数据 nbytes
/ W. B- A7 N' s+ K0 R
肥牛可能只分析了1个字体文件，正好那个文件的字体高度是0x18. 所以误认为那是每条记录的字节数。其实再看看其他文件，应该会发现那是字体高度的可能性最大。
9 ~/ G. ?# g: h. T
------------------------------------------------------------------
- H. ~; L1 W0 l+ r1 A) A% ]2009.1.11 第2次更新
' G! \4 ]! K7 w$ k肥牛说字符是按照ASCII码的顺序排列。我不知道是怎样看出来的？
3 W$ ]4 Q3 j. v' U) l据我观察字符并不是按照ASCII码的顺序排列。

7 y% q! m7 ~8 `2 H4 _: z首先，我们估计在每条记录的24个字节中，有4个字节记录了这个字符的编码。
我们知道A这个字幕，ascii码和utf-8是0x41,utf-16码是0x41 0x00.
6 n) I! v4 ^: N- F7 i! n如果A-Z按顺序排列的话，我们会在字体定义文件中发现等间距(24byts)的
1 v2 U2 T( o! ]! O& d4 `0x41,0x42....这样的数据。但是实际上文件中并没有发现，
所以字符应该不是按照ASCII码的顺序排列。

/ k4 T  w  w( H7 ~) Y另外，肥牛说索引文件会长度由26K变成了1M以上。
; Z; Y, h* b" q$ u5 n我不知道肥牛是如何算出来的，每条记录24bytes，汉字算它9000个字。
* w' c# e/ H  G+ z! E( y2 d算下来也就216K左右。远小于1M。

shane007

顶上来，此游戏下载
https://www.chinaavg.com/read.php?tid=19777

肥牛

没看到楼顶这个帖子，从网上搜了一个解包器，估计跟楼顶的这个一样。

  g, k! ], ^9 P8 `' s: v解包Localization后，会出现三个目录， xml、texture、font
其中，texture目录中的保存的是PNG格式的字库图片，font目录中保存的是字库的索引文件，xml中就是可翻译的字符串了。

$ g' q/ \% A: T/ i7 H" oPNG的图片就不用说了，我们经常遇见。下面说说font目录中的字库索引文件。(解包后的东西在家里的电脑上，现在凭印象写这个东西，有什么不对的晚上回去以后再更正。)
在font目录中，简单看了一下，文件的第一个字节表示每个字符由几个字节组成。比如0B就是11个字节，16就是24个字节。以24个字节的为例，文件头部有对应的图片文件名，然后是表示此索引包含多少个字符。后面就是每个字的数据内容了。字符是按照ASCII码的顺序排列。每个字符占24个字节，左、上、右、下各占4字节，然后是8个字节的0X00。如果此ASCII码的字符在字库中没有，那么它对应的24个字节全为0X00（好像就是为了占位）。
; D  \9 Y# Y; U$ ]
9 d+ X) F$ G, {" o7 N/ l& S疑问：
, a6 B2 J' {' F8 ^4 C/ h1、索引文件末尾的几个字节不知道是做什么用的。
7 J: [. |* e& m6 D: n0 @' V4 V: x2、按照我的想法，将汉字的双字节作为ASCII码，依照顺序写入索引文件。同时修改索引文件头部表示字符数的部分。这样却导致进入游戏后文字都不显示了。不知道是什么原因。
3 z) T9 o- L) x+ T! E' N9 T% N3、在字库的图片中，我看到了俄文。在字库的索引文件中找到对应的位置，发现与该俄文的ASCII码对应不上。不知道这个对应关系的话，汉字的索引就不知道怎么加进去。以汉字双字节的方式写入索引文件，只按二级字库就是几千个。导致索引文件长度由26K变成了1M以上。而xml目录中保存的文件是UTF8格式的，汉字将占三个字节。如果真的是按照UTF8的编码写入，那这个索引文件就太大了。所以，如果能知道俄文的索引对照关系，也许这个文件就解决了。

shane007

2009.1.11 第1次更新

shane007

2009.1.11 第2次更新

肥牛

好吧，既然007不相信我的分析，那我就用实例来说明吧。
以font目录中的font_game_menu_buttons为例，用16进制工具打开它，我们就能看到：
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
. c1 p: z" {* O1 M2 M, B1 f5 f. m
00000000   16 00 00 00 66 6F 6E 74  5F 67 61 6D 65 5F 6D 65   ....font_game_me
( U. [/ X% ~# p! `4 T* E00000010   6E 75 5F 62 75 74 74 6F  6E 73 21 00 00 00 50 04   nu_buttons!...P.
00000020   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
6 P6 j3 E' j# Q8 k7 u; E00000030   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

6 E) l/ O0 h4 k5 z) w' o第一个字节0x16表示每个字符的占位是24个字节，偏移量0x1e开始的4个字节0x0450代表这个索引表一共有这么多个字符。

) H( y5 D1 w) u+ V再跳到数据部分：
: M% ?# u  }- z2 [* Y
+ C1 F7 D% v! i5 Q! _/ aOffset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
& m* N# ^! d- ?1 n8 K2 T) H
! J1 n+ F! c/ \00000320   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00000330   00 00 00 00 00 00 00 00  00 00 6A 01 00 00 AE 00   ..........j...?
  n6 ?1 p6 w- c. U3 J7 z4 n00000340   00 00 6F 01 00 00 CF 00  00 00 00 00 00 00 00 00   ..o...?........
. m$ Z! t* `' @5 M" a# O00000350   00 00 EF 01 00 00 AE 00  00 00 F5 01 00 00 CF 00   ..?..?..?..?
00000360   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00000370   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
$ m. P  ~$ B/ L' k+ L
0x016A, 0x00AE,0x016F,0x00CF分别是左上角的横纵坐标，右下角的横纵坐标，我们看看这个范围在对应的图片中是什么：

6 ~8 W2 N6 E+ r  
$ J9 q- w! o! s从图中可以看出，这个范围对应的是字符"!"。同样，跳过8个字节的00后，0x01EF, 0x00AE, 0x01F5, 0x00CF也能对应出相应的字符。

* T$ E2 K5 G' h  J  S7 [7 Z3 x为此，我专门写了一个小工具来查看显示顺序与图片之间的关系。这个工具只能证明字符的存储是按照ASCII顺序，而不能说明是从哪个字符开始的。
/ j1 x2 ^" K$ J  
当然，这个工具中我做了一些处理。因为第一个显示的字符是"!"，所以我将它的ASCII码定为33了。
我们点击SPIN的上下箭头，调整ASCII码，就可以看到该顺序在索引中取出的是什么字符图片。

肥牛

另外，说一下汉字导致文件长度增长的问题。
并不是说我们有9000个汉字，就多了9000*24这么多个字节。因为汉字占的双字节与单字节字符是不连续的。以第一个汉字"啊"字为例，双字节是B0 A1，换成10进制就是45217，也就是说，在这个“啊”字前面，至少有45000个24个00的空占位。所以才导致这个字库的索引文件超过1M。
当然，我这样说的前提是基于索引表是连续的这个假设的前提下，如果能找到俄文字符的对应关系，可能就不会有这么大了。

肥牛

突然想到，007下载的游戏是不是跟我的版本不一样？我是从Reflexive网站上直接下载的。其中Localization文件4.60 MB (4,826,852 字节)。

shane007

引用第7楼肥牛于2010-01-11 19:42发表的  :
* }5 F8 Q6 h7 L/ c! l) l8 I突然想到，007下载的游戏是不是跟我的版本不一样？我是从Reflexive网站上直接下载的。其中Localization文件4.60 MB (4,826,852 字节)。

先回答这个，我用的也是这个版本。文件大小一样。

shane007

引用第6楼肥牛于2010-01-11 19:39发表的  :
另外，说一下汉字导致文件长度增长的问题。
并不是说我们有9000个汉字，就多了9000*24这么多个字节。因为汉字占的双字节与单字节字符是不连续的。以第一个汉字"啊"字为例，双字节是B0 A1，换成10进制就是45217，也就是说，在这个“啊”字前面，至少有45000个24个00的空占位。所以才导致这个字库的索引文件超过1M。
当然，我这样说的前提是基于索引表是连续的这个假设的前提下，如果能找到俄文字符的对应关系，可能就不会有这么大了。

你的意思我明白了。
你是说在字体索引文件里包含了所有的码位。
8 [: _$ L; @6 Y  I+ @我的疑惑是，如果是这样的话，码位的数量在定义文件头部有定义，
. a! I2 m" f! e$ K1 s但是起始码和终止码在何处定义的呢？