此文可以作为分析文件格式的参考。
" c" J9 ~- G! O d, h
: @! u; y: f6 t2 d3 H/ c9 l原文2 l9 X" z! b1 u5 g
http://vivimice.blog.163.com/blog/static/161001200952035527294/6 @% U5 o: v/ a, P+ b0 ]2 D
7 w9 r) A. N6 m" @0 J- b美国某知名2D小游戏公司最近出了一个很好玩的小游戏,非常热门啊,最近水木和88的PCGame板都在讨论这个。玩了一下发现确实不错,尤其是音乐,做得很不错,颇有味道。于是想把它给扒出来。 ~9 D5 G7 b4 ?3 E
& ?- m, ^( o: C 自己观察了一下,发现游戏目录下的sounds文件夹只有一些RIFF格式的音效,没有音乐。倒是游戏可执行文件的下面有一个main.pak文件,体积庞大。估计就是在这个文件里面。: p" p2 r- E5 _7 m w" v
0 T$ R8 n) i. ]0 X9 J; F& G- [
去该公司的开发者论坛上转了一圈,得知这个文件格式尚未公开。网上能够找到的资源提取程序都不能读取这个文件。估计是比较新的打包格式。干脆自己人肉解解看,或许能够成功。. r1 {5 {- [) m; S
, w; q+ c7 [( |$ J- w: R' y& Z3 R: {
\1 s$ C! D1 x1 I4 l
用UE打开这个文件,初步瞄了一眼,发现内容比较乱,用PNG、MP3等等常见文件的文件头搜索了一下,没有找到。文件内容比较紧凑,没有发现成段的连续同内容字节。这说明文件可能经过压缩。如果真是经过压缩的话,那么直接啃文件是基本上啃不动的,因为压缩算法实在是太多了,而且特征比较难找。于是想想换一条路试试看:如果这个文件是经过压缩的,那么程序在运行的时候肯定要将整个文件进行解压缩(因为压缩文件缺乏直接随机读写的能力),将解出来的资源放在内存里面,在内存里面找也许可以找到有价值的内容。+ V2 E: z+ B {' E- b; R1 x# ~
' p0 Q; m2 d+ y z5 m; z4 j
首先将程序启动,在资源全部加载完毕以后马上使用工具将程序运行时的内存完全dump到文件中,接下来开始分析,结果却只找到了一副PNG图。文件经过压缩的可能性变小了。
! y- {0 ]% e6 D, l3 P, C
/ t2 t3 e7 s& s* B7 v9 X6 d0 v3 q( e: h. D% q9 D0 e+ u
既然文件没有经过压缩,但是缺又缺乏常规文件的特征(文件头的地方一般比较稀疏),到底该怎么办呢?无聊之中无意将编辑模式切换到了纯文本模式,这个无意的操作却让我发现了一些蛛丝马迹。
2 b. ?. w0 e$ ^' b) b$ _) H2 `5 w 文本模式下,这个文件仍然是乱码,但是却发现文件头部有很多行的开头都一模一样。这种打包的文件,内容组织上一般都比较像文件系统,前面是子文件的入口列表,后面是子文件的具体数据。这些开头一模一样的行,可能说明这些是具有相同路径前缀的子文件。, N1 }. h% H# ?- ?
1 Y4 j1 O' q% i 不过路径名都是乱码,说明这些路径名被加密过了。首先想到的最常用也是最古老的加密方式就是XOR。尽管不知道XOR的密钥是什么,但是可以通过穷举的方式来尝试。可以长度为1的密钥开始尝试,如果不成功再尝试不同长度的。幸运的是,我找到了1个长度为1的密钥,它可以让这些乱码变成一串有意义的全大写的单词,尽管路径的分隔符是管道符,而不是反斜杠。 |; s# b) |; K( v
0 P9 B. j4 L" M: T- B# \ L: S/ T7 s8 i& L# H6 q
在这个之后,文件的内容看起来有意义多了。但是这个时候我使用常见资源的文件头进行搜索,仍然找不到匹配。这可能说明文件仍存在另外一层加密(要不就是根本就没有这些资源文件)。我想尽了办法,也没能找到这些文件的入口在哪里。
( j8 ^, c$ Q! v" O# V' J. V& R 忽然我想到前面XOR出来的文件名都是大写,这也许并不是程序员确定的原本文件名,原本文件名如果是小写的话,那么说明打包的时候把所有的小写字符变成了大写字符。而PNG的文件头是"\x80PNG",结果被我找到了"\xA0png"的若干个匹配,在这若干个匹配的后面,可以找到"ihdr"继以"iend"的匹配,而在正常的PNG中,应该是"IHDR"继以"IEND"。这起码说明了存在如下的映射:"\x80A-Z"到"\xA0a-z",即上述区间的所有字节被加上了0x20,也就是左移了5位。% o& a% g" I1 [4 ~
" B/ U% |, G; R) v* f1 Q 在我准备编写针对这个算法的还原程序之前,我发现的另外一个现象,让我陷入了混乱。我在这个文件里面发现了OGG文件的文件头,OGG的文件头"OggS"如果按照上面的推测,应该被编码成为"o\x87\x87s"("g"的十六进制表示为0x67),但是文件中的实际编码是"oGGs",也就是说对于所有的小写字符而言,他们被减去了0x20,也就是右移了5位。这说明编码的时候针对不同的字节范围进行了不同的移位。8 M0 P7 Y( N' E* V* _
9 H1 w$ j3 ?2 j! ~
3 R! I; J! u+ i+ B
最后经过大量的比对,我终于找到了实际位移的算法,终于可以将main.pak还原到了被加密之前的样子。下面的工作就是将这个打包的文件解包成为单独的文件。8 {3 {1 N' N x# m4 v
/ b: i6 N- P k; u* O7 f4 |* r* S
( S# T( l; T& i7 O8 g 相比于上面猜测加密的过程来说,解包的过程太简单了,基本上猜测再实验一下就可以知道打包的格式:2 _# f1 p6 H+ p& Y/ `
. C5 ]. Y) Q5 b
; F; ?% s$ C+ s" J5 I& ?文件头:
& |% p; W* F& d5 F% o4 D4 w! U Addr Length Type Description
/ I6 {/ M: l7 K4 J, C& m3 X 0x0000 9 byte [] 未知
( D# z. p- ~2 t" o' c! ^# ]! e
8 e. D" z% X' J w0 Y9 {- L9 U8 v+ c6 e1 k+ ^
然后接下来是文件入口的定义:
" A: g" T: F7 @0 t/ `/ u$ t2 R" ? 0x0000 1 byte 接下来的字符串的长度(假定为N) 6 A6 K5 m4 z1 _
0x0001 N char [] 文件的相对路径,例如:foo/bar/sound.ogg
: \5 }5 i: U. k 0x0001+N 4 long 文件的长度
1 @" N1 z& v- c2 ~ 0x0005+N 8 byte [] 未知
$ K; i, n( ~7 e 0x000d+N 1 byte 终结符
5 o3 |0 j0 Q7 d; Z- ^/ f8 N) P- r) K' C8 s* z
4 ]2 c0 C p# o1 a9 p, ~' c+ X如果上述终结符为0x00的表示接下来的内容仍然是文件入口,如果是0x80则表示从下面开始是文件的数据。各个文件的数据之间没有分隔。放置的顺序就是按照文件入口的顺序来确定。
3 y. D- Y" I- V' u
4 H/ B% [, R6 r, o8 U1 `0 K; I! g) @) {& i5 I
最后写了一个java小程序来将算法实现了一下,然后成功将这个文件解包。音乐那是相当不错啊,我已经整理出了一个mp3格式的专辑,这下不用玩游戏也可以享受了。 |