林登布鲁克的冒险解包器

shane007

林登布鲁克的冒险 Adventures of Natalie Brooks  解包器
& E% x7 v  f1 G要配合QuickBMS使用。

, d2 K- C1 h* k2 k-----------------------------------------------------------------
; i. m: F& I* N7 B& u$ n2009.1.11 第1次更新

- Z1 P. t' |& }! g7 X6 C我大致看了一下，觉得肥牛分析的还有些问题。
我先纠正第1个问题。文件的结构应该是这样的:
- q; v4 ]2 d- f( R6 c字体文件名长度 4bytse
字体文件名 nbytes
9 T% e4 W; y: F7 \$ q字体高度 4bytse
字体数 4bytse
字模数据 字体数X24 bytes
; ^  o) I( e/ Q; c尾部未知数据 nbytes

8 C3 Y- I7 C' ^4 s8 Z  z0 S肥牛可能只分析了1个字体文件，正好那个文件的字体高度是0x18. 所以误认为那是每条记录的字节数。其实再看看其他文件，应该会发现那是字体高度的可能性最大。
! j1 ^! ~" z" x: Z, y3 G  h
' y' F6 S% }2 j* G6 T2 E------------------------------------------------------------------
  ]9 `8 k. V: [% ~0 h, d2009.1.11 第2次更新
肥牛说字符是按照ASCII码的顺序排列。我不知道是怎样看出来的？
/ x0 l( V% f3 D# I6 g; j据我观察字符并不是按照ASCII码的顺序排列。
3 L: f( W/ ?! F# i% n( |8 W
首先，我们估计在每条记录的24个字节中，有4个字节记录了这个字符的编码。
我们知道A这个字幕，ascii码和utf-8是0x41,utf-16码是0x41 0x00.
如果A-Z按顺序排列的话，我们会在字体定义文件中发现等间距(24byts)的
0x41,0x42....这样的数据。但是实际上文件中并没有发现，
所以字符应该不是按照ASCII码的顺序排列。

另外，肥牛说索引文件会长度由26K变成了1M以上。
2 @$ S# n2 ^9 e我不知道肥牛是如何算出来的，每条记录24bytes，汉字算它9000个字。
" n; v. `7 ^" k算下来也就216K左右。远小于1M。

shane007

顶上来，这个系列是有汉化可能性的

shane007

引用第14楼肥牛于2010-01-12 19:04发表的  :
* t* Y% b& b3 g- z" o+ m8 B8 s  R正在从VERYCD上下载这个游戏，打算试试。

/ s* k/ i, Z2 `( ]5 @; l要是下不动的话可以从论坛ftp下

肥牛

正在从VERYCD上下载这个游戏，打算试试。

shane007

对了，对于这个游戏，估计你只是想分析一下，不是真的要汉化吧。
不知道你最近有没有时间，如果有时间的话想请你帮忙制作【福尔摩斯：觉醒汉化项目】的工具。
( X- m% o9 Z; G4 b: l7 O: S分析基本都完成了，文件的结构和这个游戏很相似。
- v& h# u5 V3 j) ~, i8 X如有兴趣的话可以检索【福尔摩斯：觉醒汉化项目】。
需要制作一个图片字库和字库定义文件。

shane007

引用第11楼肥牛于2010-01-11 21:57发表的  :
的确，我也是刚刚发现，我竟然把0x16算成是24了，真是个低级错误。可能就是因为开始对24这个长度先入为主吧。
3 n$ L: ?$ A6 }  Z9 S0 V
8 [/ C. Q1 D( S2 e另外，那个工具，点到33以上才会有反应。ABCD的确是连续出现的，65是A，66是B，67是C。俄文字母大写的A出现在第1040，我不知道在英文的WINDOWS系统中，俄文大写字母的ASCII码应该是多少？
3 F# p9 S& t: D$ `: v: ^序号是1040，那么在索引文件中的起始位置应该是
(1040-33)*24+0x33A = 0x61A2  ;                                          33为第一个字符!的序号， 0x33A是该字符的起始位置
.......

( z# z* f7 b- p- }# h我算了一下，1040转换为16进制是0x410，utf-16 的10 04 对应的字符正好是俄文大写字母A。
所以可以确定，你说的字符排列顺序是对的，是按utf-16编码顺序来排列的。

; ]3 J* d& t1 k: D; }3 P所以汉化应该是可行的，其实文件大一点应该也没关系，多占一点内存而已，应该不会出问题。

肥牛

的确，我也是刚刚发现，我竟然把0x16算成是24了，真是个低级错误。可能就是因为开始对24这个长度先入为主吧。

6 v3 q" U: n, l" }) B2 {  g0 `另外，那个工具，点到33以上才会有反应。ABCD的确是连续出现的，65是A，66是B，67是C。俄文字母大写的A出现在第1040，我不知道在英文的WINDOWS系统中，俄文大写字母的ASCII码应该是多少？
' n8 f5 h8 B$ R2 y序号是1040，那么在索引文件中的起始位置应该是
(1040-33)*24+0x33A = 0x61A2  ;                                          33为第一个字符!的序号， 0x33A是该字符的起始位置
+ k- O2 M7 j0 K& E7 K0 z1 Q
查看这个文件，可以看到0x61A2前面有很长的空白填充。 如果我们有证据显示俄文的A序号是1040，那就麻烦了。那样就说明我们的汉字确实需要按照这个规律向后排列。

. ]( F" R5 G  h# Y不管怎样，通过这个游戏的分析，又学到一些新东西。应该对将来的汉化分析工作有帮助。

shane007

下面针对肥牛5楼的说明来说一下，

* r. @; r+ t% f5 U# O第1个字节是0x16, 也就是10进制22 而不是24，所以是font_game_menu_buttons的字符串长度。
我想这是肥牛犯的一个低级错误。
6 G5 Y7 w* y* }" T/ u- i1 ~! n! P我在顶楼说了，每个字符的记录的长度的确是24个字节，这个24是定死的。
- T! P: T3 L: x9 T在定义文件中并不出现，肥牛认为是记录的长度的那个字节，应该是字符的高度。
- I" L( z. f7 r
肥牛你的那个工具好像没法用. 点箭头没反应啊？
我想知道，如果是按ascii字符的顺序，ABCD。。。应该是连续定义的吧？
% i0 R, f" z( m, Q; Q. @. G能指出定义在哪吗？
还有最关键的一点，如何判断是按单字节ascii顺序定义的还是按双字节utf-16顺序定义的？
从文件内容来看是不容易判断得出的。
不知道这个游戏有没有俄文版的。

shane007

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

你的意思我明白了。
你是说在字体索引文件里包含了所有的码位。
我的疑惑是，如果是这样的话，码位的数量在定义文件头部有定义，
6 q% ]# ^3 C# N* u# G但是起始码和终止码在何处定义的呢？

shane007

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

0 Y  I  f! q1 h- ^6 {1 c% P先回答这个，我用的也是这个版本。文件大小一样。