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

大概去年这个时候见到的这款游戏，游戏大厅的效果很棒 ，就有分析一下的想法了，当时记得游戏的主程序加了强壳
，简单的看了下图片包，写了个提取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来搞得（都是个人观点）。

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