繼續(xù)未完成的內(nèi)容，聲明本文僅用于學(xué)習(xí)研究，不提供解壓工具和實際代碼。
由于時間倉促，劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)（一） 大部分只是貼出了分析的結(jié)果，并沒有詳細(xì)的分析過程，比如：如何知道那是一個pak文件處理對象，
如何根據(jù)虛表偏移獲取實際函數(shù)地址等等，這就需要讀者對c++對象在內(nèi)存中的layout有一定基礎(chǔ)。
開始正文了～～，先整理下前面的分析結(jié)果：
1、劍3是通過package.ini 來管理pak文件的，最多可配置key從 0-32（0x20）的32個文件。
2、每個pak文件都用一個獨立對象來管理，所有的pak對象指針存儲在一個數(shù)組里（這個后面會用到）。
3、pak文件格式：[pak標(biāo)記(Uint32)] + [文件數(shù)目(Uint32)]+[索引數(shù)據(jù)偏移(Uint32)]+未知內(nèi)容。另外，每個文件的索引數(shù)據(jù)是16個字節(jié)。

一、路徑名哈希

  劍3的pak的內(nèi)部文件是通過hash值來查找的，這樣有利于加快查詢速度。這就需要有一個函數(shù)通過傳入 路徑名返回hash值。
這個函數(shù)居然是導(dǎo)出的。。。g_FileNameHash  這個函數(shù)代碼比較少，可以逆向出來用C重寫，也可以直接使用引擎函數(shù)(LoadLibrary，GetProceAddress來使用)。
熟悉劍俠系列的朋友會發(fā)現(xiàn)，這個函數(shù)從新劍俠情緣（可能歷史更久）開始就沒有變過（確實沒必要變），具體細(xì)節(jié)就不逐個分析了，我是寫了一個單獨的命令行工具
來測試的。

二、查詢過程

查詢函數(shù)在sub_10010E00 里，也就是(0x10010E00)的位置，我是通過簡單分析g_IsFileExist 得知這個函數(shù)功能的。下面
來分析這個函數(shù)過程：

從前文可知，pak文件對象是存儲在一個數(shù)組的這個數(shù)組是類似 KPakFile* m_szPakFile[0x21];
前面0x20個存儲的都是KPakFile對象指針，最后一個存儲的是數(shù)組長度。
這個搜索結(jié)構(gòu)比較簡單，就是遍歷所有的KPakFile對象，逐個查詢，找到了就返回。想知道具體怎么查詢的嗎，
接下來要看sub_100108B0了。

這個函數(shù)稍微有點長，分幾個部分來分析吧：

首先，驗證下Hash值是否是0，如果是0，肯定是錯了：）
然后接著開始根據(jù)這個hash值進(jìn)行查找了，經(jīng)過分析，我發(fā)現(xiàn)這個函數(shù)其實是一個二分查找，代碼貼出來如下 sub_10010320 ：



從上面的代碼還是比較容易可以知道，每個文件的16個索引數(shù)據(jù)中，前4個字節(jié)是hash值，這個函數(shù)返回的是這個文件是pak包的第幾個。

接著前面的sub_100108B0 來看吧

這一段是保存查詢到的數(shù)據(jù)到對象里。分析到這里，我只知道16個索引數(shù)據(jù)前4個字節(jié)是hash值，那么剩下的12個字節(jié)呢，
剩下的數(shù)據(jù)基本可以確定是：文件偏移、文件長度。我是個懶人，接下來的分析我是通過在fseek、fread下斷點來得到的，為什么不是在SetFilePointer和ReadFile呢，
這是根據(jù)前面的分析得到的，因為pak文件管理對象使用的是C標(biāo)準(zhǔn)庫函數(shù)。
根據(jù)fread和fseek的結(jié)果，可以得到如下結(jié)果：
索引數(shù)據(jù)構(gòu)成是:
[哈希數(shù)值(Uint32)] + [文件偏移(Uint32)]+[未知數(shù)據(jù)(Uint32)] + 2(文件長度)+2（未知數(shù)據(jù)）。
剩下的，就是看看單獨內(nèi)部文件的解壓方式了，
在fread的緩沖區(qū)上設(shè)置內(nèi)存斷點，就可以找到解壓函數(shù)了：
sub_10018020
這個函數(shù)不算太長，一開始我也想逆向成C語言，后來看到如此多的分支就放棄了，轉(zhuǎn)而用了一個偷懶的辦法解決了：
從匯編代碼可知這個函數(shù)的原型：
typedef int (*PUNPACK_FUN)(void* psrcData, int nSrcLen, void* pDstData, int* pDstLen);
直接加載劍3的dll，設(shè)置函數(shù)地址：
PUNPACK_FUN pEngineUnpack = (PUNPACK_FUN)((unsigned int)hEngineModule + 0x18020);
hEngineModule 是引擎dll的基址，大家看到了吧，dll的函數(shù)即使不導(dǎo)出，我們也是可以調(diào)用的：）

三、尾聲

到這里，已經(jīng)可以寫出一個pak文件的解壓包了，但是，我們還是沒有還原真實的文件名，
下面是我解壓的script.pak的文件的部分內(nèi)容：

 終于看到大俠們的簽名了。當(dāng)然，對著一堆hash值為名字的文件，閱讀起來確實很困難，
那么有辦法還原真實的文件名嗎，辦法還是有一些的，可以通過各種辦法改寫g_OpenFileInPak記錄參數(shù)名，來獲取游戲中用到的pak內(nèi)部文件名，相信這難不倒各位了。