繼續未完成的內容，聲明
本文僅用于學習研究，不提供解壓工具和實際代碼。
由于時間倉促，劍3資源格式分析(僅用于學習和技術研究)（一）
大部分只是貼出了分析的結果，并沒有詳細的分析過程，比如：如何知道那是一個pak文件處理對象，
如何根據虛表偏移獲取實際函數地址等等，這就需要讀者對c++對象在內存中的layout有一定基礎。
開始正文了～～，先整理下前面的分析結果：
1、劍3是通過package.ini 來管理pak文件的，最多可配置key從 0-32（0x20）的32個文件。
2、每個pak文件都用一個獨立對象來管理，所有的pak對象指針存儲在一個數組里（這個后面會用到）。
3、pak文件格式：[pak標記(Uint32)] + [文件數目(Uint32)]+[索引數據偏移(Uint32)]+未知內容。另外，每個文件的索引數據是16個字節。
一、路徑名哈希
劍3的pak的內部文件是通過hash值來查找的，這樣有利于加快查詢速度。這就需要有一個函數通過傳入 路徑名返回hash值。
這個函數居然是導出的。。。g_FileNameHash
這個函數代碼比較少，可以逆向出來用C重寫，也可以直接使用引擎函數(LoadLibrary，GetProceAddress來使用)。
熟悉劍俠系列的朋友會發現，這個函數從新劍俠情緣（可能歷史更久）開始就沒有變過（確實沒必要變），具體細節就不逐個分析了，我是寫了一個單獨的命令行工具
來測試的。
二、查詢過程
查詢函數在sub_10010E00
里，也就是(0x10010E00)的位置，我是通過簡單分析g_IsFileExist 得知這個函數功能的。下面
來分析這個函數過程：
從前文可知，pak文件對象是存儲在一個數組的這個數組是類似 KPakFile* m_szPakFile[0x21];
前面0x20個存儲的都是KPakFile對象指針，最后一個存儲的是數組長度。
這個搜索結構比較簡單，就是遍歷所有的KPakFile對象，逐個查詢，找到了就返回。想知道具體怎么查詢的嗎，
接下來要看sub_100108B0了。
這個函數稍微有點長，分幾個部分來分析吧：
首先，驗證下Hash值是否是0，如果是0，肯定是錯了：）
然后接著開始根據這個hash值進行查找了，經過分析，我發現這個函數其實是一個二分查找，代碼貼出來如下 sub_10010320
：
從上面的代碼還是比較容易可以知道，每個文件的16個索引數據中，前4個字節是hash值，這個函數返回的是這個文件是pak包的第幾個。
接著前面的sub_100108B0
來看吧
這一段是保存查詢到的數據到對象里。分析到這里，我只知道16個索引數據前4個字節是hash值，那么剩下的12個字節呢，
剩下的數據基本可以確定是：文件偏移、文件長度。我是個懶人，接下來的分析我是通過在fseek、fread下斷點來得到的，為什么不是在SetFilePointer和ReadFile呢，
這是根據前面的分析得到的，因為pak文件管理對象使用的是C標準庫函數。
根據fread和fseek的結果，可以得到如下結果：
索引數據構成是:
[哈希數值(Uint32)] + [文件偏移(Uint32)]+[未知數據(Uint32)] + 2(文件長度)+2（未知數據）。
剩下的，就是看看單獨內部文件的解壓方式了，
在fread的緩沖區上設置內存斷點，就可以找到解壓函數了：
sub_10018020
這個函數不算太長，一開始我也想逆向成C語言，后來看到如此多的分支就放棄了，轉而用了一個偷懶的辦法解決了：
從匯編代碼可知這個函數的原型：
typedef int (*PUNPACK_FUN)(void* psrcData, int nSrcLen, void* pDstData, int* pDstLen);
直接加載劍3的dll，設置函數地址：
PUNPACK_FUN pEngineUnpack = (PUNPACK_FUN)((unsigned int)hEngineModule + 0x18020);
hEngineModule
是引擎dll的基址，大家看到了吧，dll的函數即使不導出，我們也是可以調用的：）
三、尾聲
到這里，已經可以寫出一個pak文件的解壓包了，但是，我們還是沒有還原真實的文件名，
下面是我解壓的script.pak的文件的部分內容：
終于看到大俠們的簽名了。當然，對著一堆hash值為名字的文件，閱讀起來確實很困難，
那么有辦法還原真實的文件名嗎，辦法還是有一些的，可以通過各種辦法改寫g_OpenFileInPak記錄參數名，來獲取游戲中用到的pak內部文件名，相信這難不倒各位了。
posted on 2010-07-16 20:47
feixuwu 閱讀(4811)
評論(11) 編輯 收藏 引用 所屬分類:
逆向工程