照例，是用HEDIT打开一个PKX文件来看。
开头是一句话，这个文件格式是一个叫做ZERO的程序员创建的，仰视ZERO三秒！接下来继续。
从MOTIONDATA这个文件夹来看，这里面都是动画动作相关的数据。在HEDIT里面，可以看到PKX里面有很多动作的名字。然后，跳过这些动作名字，可以看到熟悉的"DFX"三个字母，那些都是TGL文件。
取得DFX的OFS，在前面的表里查找，不过令人失望，里面找不到。
拉到文件尾，很多包裹文件都把文件列表放在文件尾。这时，我们看到了以字母顺序排列的动作表。从第一个名字向上找，找到一个DFX，就是TGL文件，我们按照TGL文件格式往下推导，结束点正好在第一个名字前面。所以我们可以得到文件列表数据接口的起点，就是名字的第一个字节开始。
我继续往下找到第二个名字，计算下两个名字的距离是284字节。根据名字长度没有标记来判断，这个文件列表是固定长度的数据结构。
继续，根据文件头上那个表的第一个元素的名字猜测，他的数据在第一个DFX文件处。我找到第一个元素的文件列表中的数据，对比他的DFX文件数据的OFS和LENGTH，发现它的OFS和LENTH保存在文件列表数据结构的第0x104位置。从那里开始，顺序存储着64位的Ofs和32位的原始大小，以及32位的压缩后大小。当然这只是猜测。
接下来，我计算了下尾部的所有文件列表数据的长度，除以单个列表数据结构长度，得到了一个文件数目。然后，回到头部，来寻找这个数据。
很显然，肯定有这个数据的。最终我在 ofs为0x108的地方找到了，是一个32位的整数。而他前面，是64位的包文件总长度。用这两个，加上文件列表的数据结构长度，就可以定位到文件列表的位置了。
好了，有了以上数据，PKX文件就可以解开了。不过仍然还有很多数据是未知含义的，不过这不影响我们解开PKX文件。下面是文件格式的整体描述：
@packinfo(0x100) {
int64 = packsize
int32 = filecount
int32 = 0
int32 = 2
} * 1
@filedata {}
@infotable(packsize-filecount*284) {
char[10] = name
@filepos(+0x104) {
int64 = offset
int32 = originsize
int32 = compresssize
}
} * filecount
这次挺简单的，就没工具了。最后再说下，解出来的是TGL文件。