林登布鲁克的冒险解包器

shane007

林登布鲁克的冒险 Adventures of Natalie Brooks  解包器
3 M  \2 [- d8 `. d: O" h" x要配合QuickBMS使用。
! r0 G+ o$ R* w: G
-----------------------------------------------------------------
2009.1.11 第1次更新

5 o- m" o( W  v3 S4 d2 k+ v我大致看了一下，觉得肥牛分析的还有些问题。
+ Y0 A. [% T; h  T+ Y* Q$ c我先纠正第1个问题。文件的结构应该是这样的:
$ |' ?& w4 C. T0 [2 }+ J字体文件名长度 4bytse
" ^% k% D" c6 B; o8 T  f2 q字体文件名 nbytes
4 \* A+ e& y) d& l7 U$ r字体高度 4bytse
" H5 x" C. f' w4 J: w, a, s/ I) M字体数 4bytse
7 \& p0 }& g4 o字模数据 字体数X24 bytes
+ C% Y1 m  {; x5 }8 Q) V+ }7 |尾部未知数据 nbytes

肥牛可能只分析了1个字体文件，正好那个文件的字体高度是0x18. 所以误认为那是每条记录的字节数。其实再看看其他文件，应该会发现那是字体高度的可能性最大。
( d% D' [& w- O0 o& M( c
& w% C& b" l, I$ H" U) p------------------------------------------------------------------
2009.1.11 第2次更新
肥牛说字符是按照ASCII码的顺序排列。我不知道是怎样看出来的？
据我观察字符并不是按照ASCII码的顺序排列。
( v: J7 H% a' b
首先，我们估计在每条记录的24个字节中，有4个字节记录了这个字符的编码。
( C/ c" x& X* A我们知道A这个字幕，ascii码和utf-8是0x41,utf-16码是0x41 0x00.
如果A-Z按顺序排列的话，我们会在字体定义文件中发现等间距(24byts)的
6 r/ n% {: }2 y  Q2 x0x41,0x42....这样的数据。但是实际上文件中并没有发现，
$ g9 k% B$ u3 K9 ^4 T所以字符应该不是按照ASCII码的顺序排列。

另外，肥牛说索引文件会长度由26K变成了1M以上。
我不知道肥牛是如何算出来的，每条记录24bytes，汉字算它9000个字。
' z4 ?  s$ O  U$ d3 o" ~. x算下来也就216K左右。远小于1M。

shane007

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

shane007

引用第14楼肥牛于2010-01-12 19:04发表的  :
正在从VERYCD上下载这个游戏，打算试试。

0 h/ J( `- P9 _( P要是下不动的话可以从论坛ftp下

肥牛

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

shane007

对了，对于这个游戏，估计你只是想分析一下，不是真的要汉化吧。
不知道你最近有没有时间，如果有时间的话想请你帮忙制作【福尔摩斯：觉醒汉化项目】的工具。
4 }2 M$ `, X! g. `# H8 w* e分析基本都完成了，文件的结构和这个游戏很相似。
; H5 ]; x! W! c9 r如有兴趣的话可以检索【福尔摩斯：觉醒汉化项目】。
需要制作一个图片字库和字库定义文件。

shane007

引用第11楼肥牛于2010-01-11 21:57发表的  :
的确，我也是刚刚发现，我竟然把0x16算成是24了，真是个低级错误。可能就是因为开始对24这个长度先入为主吧。
, A8 |0 O+ o# X) {  {; A3 ^6 m
另外，那个工具，点到33以上才会有反应。ABCD的确是连续出现的，65是A，66是B，67是C。俄文字母大写的A出现在第1040，我不知道在英文的WINDOWS系统中，俄文大写字母的ASCII码应该是多少？
, N; `0 G4 S- z- j$ u; U. M序号是1040，那么在索引文件中的起始位置应该是
6 V5 a8 d  ?. N(1040-33)*24+0x33A = 0x61A2  ;                                          33为第一个字符!的序号， 0x33A是该字符的起始位置
  K  L, P7 p) L$ M# \& S; K0 Z( I.......

, Z! g5 k: F3 ~: W8 E  ~我算了一下，1040转换为16进制是0x410，utf-16 的10 04 对应的字符正好是俄文大写字母A。
所以可以确定，你说的字符排列顺序是对的，是按utf-16编码顺序来排列的。

所以汉化应该是可行的，其实文件大一点应该也没关系，多占一点内存而已，应该不会出问题。

肥牛

的确，我也是刚刚发现，我竟然把0x16算成是24了，真是个低级错误。可能就是因为开始对24这个长度先入为主吧。
5 T. k( L. K+ M& }
另外，那个工具，点到33以上才会有反应。ABCD的确是连续出现的，65是A，66是B，67是C。俄文字母大写的A出现在第1040，我不知道在英文的WINDOWS系统中，俄文大写字母的ASCII码应该是多少？
2 v8 o7 r9 a0 j. M* a序号是1040，那么在索引文件中的起始位置应该是
! Q( T+ z# D! a  F6 j(1040-33)*24+0x33A = 0x61A2  ;                                          33为第一个字符!的序号， 0x33A是该字符的起始位置

查看这个文件，可以看到0x61A2前面有很长的空白填充。 如果我们有证据显示俄文的A序号是1040，那就麻烦了。那样就说明我们的汉字确实需要按照这个规律向后排列。
3 N$ d" ~9 r& Z+ o
不管怎样，通过这个游戏的分析，又学到一些新东西。应该对将来的汉化分析工作有帮助。

shane007

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

第1个字节是0x16, 也就是10进制22 而不是24，所以是font_game_menu_buttons的字符串长度。
我想这是肥牛犯的一个低级错误。
我在顶楼说了，每个字符的记录的长度的确是24个字节，这个24是定死的。
+ w" @& C1 h- f2 `, h/ L( P6 j在定义文件中并不出现，肥牛认为是记录的长度的那个字节，应该是字符的高度。

8 X- T8 `. X8 ~7 ]6 @: N肥牛你的那个工具好像没法用. 点箭头没反应啊？
" D: D6 C5 p3 b' l! }" j/ W我想知道，如果是按ascii字符的顺序，ABCD。。。应该是连续定义的吧？
能指出定义在哪吗？
还有最关键的一点，如何判断是按单字节ascii顺序定义的还是按双字节utf-16顺序定义的？
, t% {0 N+ l" m1 f) e从文件内容来看是不容易判断得出的。
不知道这个游戏有没有俄文版的。

shane007

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

! m$ \" {# h% _7 w你的意思我明白了。
. @% f! Y6 W% R! @你是说在字体索引文件里包含了所有的码位。
; _% W4 n# ~. p% a* I- u7 u我的疑惑是，如果是这样的话，码位的数量在定义文件头部有定义，
但是起始码和终止码在何处定义的呢？

shane007

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

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