林登布鲁克的冒险解包器

shane007

林登布鲁克的冒险 Adventures of Natalie Brooks  解包器
& z! u, w1 k. s+ m7 V$ c要配合QuickBMS使用。
  Z5 i+ _' o) H
/ I8 ?5 ~) S3 U-----------------------------------------------------------------
2009.1.11 第1次更新
5 V+ w' F  \+ ^' Z& y/ @2 J
我大致看了一下，觉得肥牛分析的还有些问题。
我先纠正第1个问题。文件的结构应该是这样的:
字体文件名长度 4bytse
字体文件名 nbytes
2 I7 P6 u$ L# O, q' X/ c字体高度 4bytse
字体数 4bytse
& F7 ]% S" I$ B! e2 _/ r  @' S字模数据 字体数X24 bytes
尾部未知数据 nbytes
1 I0 S. q" z; W+ O1 m% n; @: L
% b' P& H! g6 ?& E肥牛可能只分析了1个字体文件，正好那个文件的字体高度是0x18. 所以误认为那是每条记录的字节数。其实再看看其他文件，应该会发现那是字体高度的可能性最大。
( j" l8 O1 B" f  m+ F, o
------------------------------------------------------------------
% N" N0 ~+ |* V. s+ N7 a0 S2 Z2009.1.11 第2次更新
肥牛说字符是按照ASCII码的顺序排列。我不知道是怎样看出来的？
7 J% j2 o: b0 F5 c- p: `据我观察字符并不是按照ASCII码的顺序排列。

+ v* |) ~0 E$ r- ]1 [5 R; r$ `  f- I' Y首先，我们估计在每条记录的24个字节中，有4个字节记录了这个字符的编码。
# }1 }/ M  [% D3 ^' D我们知道A这个字幕，ascii码和utf-8是0x41,utf-16码是0x41 0x00.
如果A-Z按顺序排列的话，我们会在字体定义文件中发现等间距(24byts)的
% L# l: k% o* h9 g0x41,0x42....这样的数据。但是实际上文件中并没有发现，
. u0 j2 d- W5 J' G所以字符应该不是按照ASCII码的顺序排列。
4 K9 G' F% H$ j- F; i3 _( Q! E
  u9 j/ N! `* x另外，肥牛说索引文件会长度由26K变成了1M以上。
我不知道肥牛是如何算出来的，每条记录24bytes，汉字算它9000个字。
算下来也就216K左右。远小于1M。

shane007

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

shane007

引用第14楼肥牛于2010-01-12 19:04发表的  :
' u- V, L* ]( a: b3 D正在从VERYCD上下载这个游戏，打算试试。

) `8 z5 j7 C+ t( |. M8 n. _) q要是下不动的话可以从论坛ftp下

肥牛

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

shane007

对了，对于这个游戏，估计你只是想分析一下，不是真的要汉化吧。
0 _( @9 x" f) M$ R: ?6 z不知道你最近有没有时间，如果有时间的话想请你帮忙制作【福尔摩斯：觉醒汉化项目】的工具。
分析基本都完成了，文件的结构和这个游戏很相似。
+ B& G8 x7 v6 \" R2 Z如有兴趣的话可以检索【福尔摩斯：觉醒汉化项目】。
需要制作一个图片字库和字库定义文件。

shane007

引用第11楼肥牛于2010-01-11 21:57发表的  :
# h0 s- O+ V( ^) A) _0 ^的确，我也是刚刚发现，我竟然把0x16算成是24了，真是个低级错误。可能就是因为开始对24这个长度先入为主吧。

另外，那个工具，点到33以上才会有反应。ABCD的确是连续出现的，65是A，66是B，67是C。俄文字母大写的A出现在第1040，我不知道在英文的WINDOWS系统中，俄文大写字母的ASCII码应该是多少？
7 e) w  s: `/ v& |序号是1040，那么在索引文件中的起始位置应该是
(1040-33)*24+0x33A = 0x61A2  ;                                          33为第一个字符!的序号， 0x33A是该字符的起始位置
" W3 I6 D0 K2 _& V.......

我算了一下，1040转换为16进制是0x410，utf-16 的10 04 对应的字符正好是俄文大写字母A。
. `( X: h$ _4 N0 U* @2 T5 z2 z所以可以确定，你说的字符排列顺序是对的，是按utf-16编码顺序来排列的。
) b$ e+ U( Y5 g- Y& G
所以汉化应该是可行的，其实文件大一点应该也没关系，多占一点内存而已，应该不会出问题。

肥牛

的确，我也是刚刚发现，我竟然把0x16算成是24了，真是个低级错误。可能就是因为开始对24这个长度先入为主吧。
* y" H% Z. Z  g% ]
另外，那个工具，点到33以上才会有反应。ABCD的确是连续出现的，65是A，66是B，67是C。俄文字母大写的A出现在第1040，我不知道在英文的WINDOWS系统中，俄文大写字母的ASCII码应该是多少？
序号是1040，那么在索引文件中的起始位置应该是
" N0 A% o; U. U; z(1040-33)*24+0x33A = 0x61A2  ;                                          33为第一个字符!的序号， 0x33A是该字符的起始位置
6 y- \, ~# y( g4 O- Y% g8 J
0 l1 [3 v. s, \! M3 N, u7 h. x3 N0 T查看这个文件，可以看到0x61A2前面有很长的空白填充。 如果我们有证据显示俄文的A序号是1040，那就麻烦了。那样就说明我们的汉字确实需要按照这个规律向后排列。

不管怎样，通过这个游戏的分析，又学到一些新东西。应该对将来的汉化分析工作有帮助。

shane007

下面针对肥牛5楼的说明来说一下，
, F& a& L( B/ K2 Z! R
第1个字节是0x16, 也就是10进制22 而不是24，所以是font_game_menu_buttons的字符串长度。
我想这是肥牛犯的一个低级错误。
我在顶楼说了，每个字符的记录的长度的确是24个字节，这个24是定死的。
在定义文件中并不出现，肥牛认为是记录的长度的那个字节，应该是字符的高度。
% l0 M9 r, A: E, a/ b# {
( A( X1 M4 C$ D8 j0 I6 e肥牛你的那个工具好像没法用. 点箭头没反应啊？
我想知道，如果是按ascii字符的顺序，ABCD。。。应该是连续定义的吧？
! L$ o! q2 M9 d; V能指出定义在哪吗？
还有最关键的一点，如何判断是按单字节ascii顺序定义的还是按双字节utf-16顺序定义的？
从文件内容来看是不容易判断得出的。
0 k: I! X$ Z. r- M9 v不知道这个游戏有没有俄文版的。

shane007

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

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

shane007

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

1 [4 j4 V9 J/ ~: E! C$ F* K* h  V先回答这个，我用的也是这个版本。文件大小一样。