（PS)かまいたちの夜•特別篇 汉化笔记 七

7.           ike格式分析

分析解压算法的过程其实都差不多，一般是先下一个cd-rom访问断点，然后是内存访问断点。或者是反过来，已知明文位置的情况，下一个内存写入断点。

 

Sce.pac中有不少段有ike的签名，指明这个数据被压缩过。

 

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

 

00000000   9D 89 69 6B 65 00 75 53  87 A3 00 52 A0 FF FF 4A   ‰ike.uS‡£.R ÿÿJ

00000010   01 52 01 55 01 5C 01 56  02 E9 02 69 03 1A FF FF   .R.U./.V.é.i..ÿÿ

00000020   04 FE 04 A9 05 95 06 B0  07 EE 07 E5 09 13 0B C3   .þ.©.•.°.î.å...Ã

00000030   FF FF 0B C2 0C 1F 0E E1  0E 5E 0F B7 0F 20 10 89   ÿÿ.Â...á.^.·. .‰

00000040   10 0F FF FF 11 F3 11 BD  12 D8 13 80 14 56 16 1F   ..ÿÿ.ó.½.Ø.€.V..

00000050   17 04 18 A7 FF FF 18 15  1A FD 1A C2 1B D4 1B A6   ...§ÿÿ...ý.Â.Ô.¦

00000060   1C 7B 1D 8D 1E 91 FF FF  1F 8F 20 39 21 38 22 69   .{..‘ÿÿ. 9!8"i

00000070   23 56 24 46 25 34 26 1D  FF FF 27 CB 28 3D 29 74   #V$F%4&.ÿÿ'Ë(=)t

00000080   2A 8B 2B 9B 2C 09 2D 91  2D A5 FF FF 2E 8B 2F 8B   *‹+›,.-‘-¥ÿÿ.‹/‹

00000090   30 9B 31 91 32 5F 33 5E  34 86 35 65 FF FF 36 71   0›1‘2_3^4†5eÿÿ6q

000000A0   36 AF 36 DE 37 C6 38 B3  39 B1 3A AA 3B B4 FF FF   6¯6Þ7Æ8³9±:ª;´ÿÿ

000000B0   3C 86 3D C0 3E 18 3F EE  3F 75 40 4A 41 24 42 AF   <†=À>.?î?u@JA$B¯

000000C0   FF FF 43 48 44 6A 45 58  46 7B 47 24 48 09 49 44   ÿÿCHDjEXF{G$H.ID

000000D0   4A 86 FF FF 4B 64 4C 89  4D 80 4E 7D 4F 9C 4F 2C   J†ÿÿKdL‰M€N}OœO,

000000E0   51 68 52 54 FF FF 53 5D  54 42 55 6A 56 86 57 DE   QhRTÿÿS]TBUjV†WÞ

000000F0   58 BD 59 37 5A 51 FF FF  5B A9 5B 0E 5C 9E 5D DB   X½Y7ZQÿÿ[©[./ž]Û

00000100   5E E3 5F BF 61 1B 62 2C  FF FF 63 01 64 DA 64 90   ^ã_¿a.b,ÿÿc.dÚd

00000110   66 97 67 9C 68 B7 69 C4  6A AE FF FF 6C 8D 6D 2D   f—gœh·iÄj®ÿÿlm-

00000120   6E 6C 6F 98 70 98 71 94  72 46 73 EC FF FF 73 A3   nlo˜p˜q”rFsìÿÿs£

00000130   74 BA 75 E6 76 97 77 B8  77 1A 78 E4 78 D2 FF FF   tºuæv—w¸w.xäxÒÿÿ

00000140   7A D1 7B 58 7D 95 7E 6F  7F 8F 80 98 81 93 82 BF   zÑ{X}•~o€˜“‚¿

00000150   E3 FF 83 7F 84 FE CB 85  26 87 56 89 55 8A 2D 8B   ãÿƒ„þË…&‡V‰UŠ-‹

00000160   FF F1 48 8C 32 8D 0E 8E  68 8F 12 90 3D 12 92 56   ÿñHŒ2.Žh.=.’V

00000170   FF FF 93 56 94 94 94 9A  94 85 95 60 96 BF 97 53   ÿÿ“V”””š”…•`–¿—S

00000180   01 00 FF BF 0A 00 23 1E  0F 34 08 00 0E 36 7B 69   ..ÿ¿..#..4...6{i

00000190   5F 7E 00 8F 7F EE 0C ED  30 14 00 45 C8 00 79 01   _~.î.í0..EÈ.y.

000001A0   C4 FB F6 04 F9 09 3C 00  01 FC FF FF 05 4D 01 0C   Äûö.ù.<..üÿÿ.M..

000001B0   32 00 00 82 E6 82 A4 82  E2 82 AD 8A FF C7 6F 82   2..‚悤‚â‚­ŠÿÇo‚

000001C0   A6 82 BD 83 7B 81 5B 83  51 83 8A C5 FF FF 82 C8   ¦‚½ƒ{[ƒQƒŠÅÿÿ‚È

000001D0   82 F1 82 C6 82 A9 98 5B  82 CC 83 8C 83 58 1F FB   ‚ñ‚Æ‚©˜[‚̃ŒƒX.û

 

这是sce16，首字节不是4c（4c是用来判断LZS），且2-4是ike的情况下，该数据就是ike格式文件。

之后读取0B处1 word：A052，A052确认是解压后大小的末2bytes。06-0a的数据含义不明，没有看到程序访问过。

 

之后的数据就是压缩数据，2byte flag，根据flag来读取后面的数据，具体的编码参考ike_unpack.txt。

 

一般来说，发现很整齐的FFFF，之后跟16bytes，基本就确认是一个LZSS的变种了。

 

Idb中函数ikeUnpack。

签名判断的部分在函数ReadFile中。

 

现在可以解压IKE格式的文件后，整个sce.pac都可以查看了。

 

这里再提两句，解压代码比较容易测试，因为压缩的脚本数量有限，使用解压代码解压后和内存中解压出来的数据比较一下即可。

 

压缩代码我只是试着拿了几个脚本文件，先压缩再解压看看是不是一样，虽然也能发现不少问题，调着调着都正确，觉得差不多了，也就不去管它了。

但是我最后导入图片的时候出现问题，这时候回头检查代码还真是痛苦，里面很多调试代码已经不太清楚含义了。

当然最后还是回想了起来，找到问题所在，最大的重复输出只能是0x110，我在循环中使用了<=，于是最大输出变成了0x111。这个问题在脚本文件中一直测试不出来是因为脚本文件没有大量的重复字节，但是图片就有。

 

现在想想还是应该一开始就先设计好一个能覆盖所有编码的测试文件。只要这个文件的压缩解压能过，就没有问题了。