某游戏资源包格式分析（PKH）

声明：本分类下的文章仅用于学习研究，不提供解压工具和实际代码，也请谨慎转载

大概去年这个时候见到的这款游戏，游戏大厅的效果很棒，就有分析一下的想法了，当时记得游戏的主程序加了强壳，简单的看了下图片包，写了个提取png图片的工具。工作一直忙，时间有限也就作罢了。

前段时间忽然想起这个游戏来，发现发布了新版本，连运营的公司变了，主程序竟然没加壳，个人觉得游戏风格感觉也不如以前好了，不知道是现在的团队不如原来的团队实力强了，还是公司决策不如原来的公司。

自己没有记笔记的习惯，分析过程大都没有记下来，现在记得的也只有结果了，在此写下了免得啥都忘了，权且当笔记了。

文件头部分：

文件头第一部分
00000000h: 50 4B 48 00 00 00 00 00 04 00 00 00 30 00 00 00 ; PKH.........0...
00000010h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000020h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CC CC ; ..............烫

文件头第二部分
00000030h: EF AF 14 3B 03 0A 00 00 00 00 00 00 14 3F EF EE ; 锆.;.........?镱
00000040h: 50 02 00 00 03 0A 00 00 F3 52 15 CB 15 03 00 00 ; P.......驲.?...
00000050h: 53 0C 00 00 EB 01 6D E3 7F 01 00 00 68 0F 00 00 ; S...?m?...h...

00-07字节 8字节文件魔数（PKH）
08-0B字节 4字节文件数目

0C-2F字节貌似是文件说明等(不影响资源解包，未分析)

30-C文件数目各个文件的大小等信息，每个文件占12个字节

注：前四个：应该是文件唯一标识，类似文件名，具体怎么使用尚未分析；
中四个：本文件大小；
后四个：本文件在资源包里的偏移（加上文件头偏移才是真正的偏移）

文件内容部分：

文件内容依次排开，首位相接，也没有进行压缩。以上面的文件头为例：

该资源包中含有4个文件，

第一个文件：
文件标识是 0x3B14AFEF (EF AF 14 3B)；
文件大小是 0x00000A03 (03 0A 00 00)；
相对偏移是 0x00000000 (00 00 00 00)；
实际偏移是 0x0 + 文件头偏移(0x30 + 0xC0x4 = 60H)=0x60；

第二个文件：
文件标识是 0xEEEF3F14 (14 3F EF EE)；
文件大小是 0x00000250 (50 02 00 00)；
相对偏移是 0x00000A03 (03 0A 00 00)；
实际偏移是 0xA03 + 文件头偏移(0x30 + 0xC0x4 = 60H)=0xA63；

第三个文件：
第四个文件：（略）

验证计算：

文件1

A03 + 文件头偏移（30H+C4=60H） = A63：

文件2
A63 + 250H = CB3

文件3
CB3 + 315H = FC8

文件4
FC8 + 17F = 1147H

该文件大小正好是 0x1147字节，提取出来的文件也说明分析是正确的。

关于这个资源包，有一个地方还没有解决，就是文件名。因为在资源包里没有保存文件名，猜测上面提到的文件标识应该是用来唯一标示一个文件的，类似文件名的作用。具体怎么用的，还有待分析。

这个游戏比较有意思的地方是整个游戏大厅和所有的游戏除了大厅启动的时候，主程序做了一些初始化等工作，其他的都是用 lua脚本来驱动的，包括资源加载。整个大厅所有的 exe + dll 加起来都很瘦小。游戏中使用了大量的脚本，游戏就全是用脚本来处理的了。当然开发人员也对 lua 脚本做了简单的加密。渲染方面我看起来更像是借鉴了HGE来搞得（都是个人观点）。

以前就发现这个游戏有一个缺点（我认为是缺点），一年过去了，仍然存在，就是游戏更新这一块，因为目前的更新机制是，如果资源包里很小的一个图片做了更新，客户端要把整个资源包重新下载一遍，感觉这里处理的不好。另外目前游戏的可玩性还不是很高，休闲游戏做的太网游话了也不知道好不好，总感觉太富丽堂皇了。希望这个游戏能坚持下去，拭目以待吧。