
kesaan
游戏解包
>>
完整版
本帖最后由 kesaan 于 2012-3-10 13:50 编辑
嘛,闲话不说,下面我就首先分析一下ykc文件,也即是游戏的打包文件。游戏目录下有三个文件,其中data01.ykc打包的是游戏脚本文件、data02.ykc打包的是游戏CG和立绘,而data03.ykc则是打包了所有的语音。ykc打包文件的格式如下:其中Header是一个类似如下的结构体:struct ykcHeader{char MagicNum[16];intFETOffset;intFETSize;};其中前面16字节是固定的幻数,它的内容必须是(至少对于这两个游戏是这样)如下的数据:charMAGIC_NUM[] = {'Y', 'K', 'C', '0', '0', '1', 0, 0, 0x18, 0, 0, 0, 0, 0, 0, 0};然后后面两个数据项是File Entry Table在文件内的偏移位置和大小。这个File Entry Table就是记录每一个文件项的结构,它是由FET_Item构成的数组。每个FET_Item记录了一个文件的信息,FET_Item的结构如下所示:struct FET_Item{intname_offset;intname_length; //包括字串的NULLintfile_offset;intfile_size;intzero = 0; //必须为0};首相两个成员name_offset和name_length是定义了该文件文件名字符串在ykc文件中的储存位置和大小,注意这个大小是包括NULL的。也就是说,文件名是连同NULL一起被储存的。从我们的表中可以知道,实际上这些个文件名位于File Name Table区域中。然后两个成员file_offset跟file_size则定义了文件实际数据在ykc打包文件中的储存位置和大小,注意文件统一位于上面图中的Data区域。当然,最后一项4字节总是应该为全零。通过以上的方式我可以拿到所有的游戏资源了,但是我却在data01.ykc中还发现了yks和ykg两种类型文件:由经分析可知这就是游戏的脚本文件。其中yks对应包括了游戏的对话,如果你在做汉化的话这个文件就十分重要了。但是打开这个文件你可以发现,满屏幕的乱码。我当然不是想说其实你只要把编码换成日文编码Shift-JIS就行了,实际上我是想说,可以看出来feng这个游戏引擎和NS或者Krkr不同,他的脚本不是文本脚本而是二进制脚本,那么如果你要看到文本的话,还的对这个脚本分析一番。当然,我提取CG的目的这时已经达到了,但是既然走到这里了,我就不妨一遍把这个东西分析了吧。
我这里只分析yks脚本文件。yks结构比较简单,除了30h字节的header之外,后面全部是数据。Header的结构如下:首先,前5个字节是幻术,对应ACSII码值为YKS001,然后注意看红蓝绿黄四个区域。其中黄色区域作用未知,程序在处理黄色区域第一个DWORD的时候(前4个字节),我们设这个值为value,若value不为0,则会开辟一块大小为12*value+4大小的动态空间,作用未知(并没有读取任何数据到这里,后面的分析你可以清楚地知道这点)。
另外三个区域,则是定义了三个数据段。每个区域前一个DWORD是指的offset,后一个DWORD则是指定length。注意对于这个length还有点小把戏,对于红色区域实际上每个元素是4Byte,那么红色区域定义的数据块大小为size=length*4,同样的道理蓝色区域size=length*16,而绿色区域size=length*1。整个文件大小为文件头的30h字节加上三个数据段大小。文件大小 = 30h + Length(红)*4 + Length(蓝)*16 + Length(绿),大家可以自行验证。(你可以看到黄色区域实际上没有对应数据,那么程序根据这里分配内存的用意实在令我费解了)
这三段数据段中,红色数据段的数据是直接明文存在,但是数据类型不明。蓝色数据段被加密了,数据解密算法如下:buffer =>int*类型length =>int类型intedx = 0;for(inti = 0; i < length; i++){if(buffer[edx] == 0) buffer[edx+3] = 0;edx+=4;}绿色区域是脚本数据,这是十分重要的了。他的加密方式是每个字节直接与0xAAh异或,所以解密我们也只需要将每个字节与0xAAh异或就行了。分析出来的文本如下所示:这里的文本里还是混入了大量二进制代码,说明这个游戏引擎的确是基于二进制脚本工作的。好了,我的分析就到此结束了。我把解包程序和文本提取程序都分享了。以上。(点此下载。注意两个东西使用方法都是直接将文件拖上去就行)度娘把图吞了,有时间在传吧