照例，是用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文件。