由于時間倉促，劍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內部文件名，相信這難不倒各位了。
]]>
一、安全保護
一般來說，很少有游戲的資源格式可以直接通過分析資源文件本身得到答案，大部分難免要靜態逆向、動態調試。無論是靜態逆向還是動態調試，首先需要知道當前exe和dll的保護情況，用peid查看，發現只有gameupdater.exe 用upx加殼了。不太明白金山為什么對客戶端沒有加殼。
其實我并不關心gameupdater.exe 是否加殼，畢竟要動態分析的目標是JX3Client.exe ，要動態調試JX3Client.exe，首先要解決啟動參數問題。
二、啟動參數
如果直接啟動JX3Client.exe，JX3Client.exe會直接退出，并啟動gameuodater.exe，然后通過gameupdater.exe啟動JX3Client.exe。這種啟動方式會影響動態調試，所以首先我需要找出JX3Client.exe的啟動參數。打開IDA逆向，轉到啟動處，匯編代碼如下：
start proc nearcall ___security_init_cookie
jmp ___tmainCRTStartup
start endp
這是一個典型的VC程序入口，在___tmainCRTStartup 里，crt會初始化全局變量、靜態變量，然后進入main,我們需要做的是直接找到main,
跟進去，會發現IDA已經幫我們找到WinMain了，直接跟進去，
關鍵代碼在WinMain的入口處：
從這個代碼片段可以知道，WinMain開始就比較了命令行參數是否是"DOTNOTSTARTGAMEBYJX3CLIENT.EXE ",如果不是，
則轉到啟動更新程序了。這個好辦，我們寫一個run.bat，內容只有一行：
JX3Client.exe DOTNOTSTARTGAMEBYJX3CLIENT.EXE
運行，果然，直接看到加載界面了。
三、PAK文件管理
在劍3里，PAK目錄下有很多PAK文件，劍3是通過package.ini 來加載和管理pak內部文件的。這個文件內容如下：
[SO3Client]
10=data_5.pak
1=ui.pak
0=update_1.pak
3=maps.pak
2=settings.pak
5=scripts.pak
4=represent.pak
7=data_2.pak
6=data_1.pak
9=data_4.pak
Path=.\pak
8=data_3.pak
基本上PAK目錄下所有的PAK文件都列出來了，其實劍3的資源文件打包方式基本上和新劍俠情緣類似（細節還是有比較大的差別）。
打開ollyDbg，帶參數啟動JX3Client.exe，在CreateFile設置斷點，可以發現，package.ini 的讀取和處理是在
Engine_Lua5.dll 的g_LoadPackageFiles 函數，熟悉新劍俠情緣資源管理方式的同學大概會猜到這個函數是做什么的，先看看函數內容吧，這個函數比較長
只能逐步的分析了，首先是打開ini文件
使用g_OpenIniFile打開前面提到的ini文件，如果打開失敗，自然直接返回了。
打開成功后，循環讀取ini配置的文件，讀取的section是SO3Client 讀取的key是0到0x20。
loc_1001119A: ; int
push 0Ah
lea ecx, [esp+1A0h+var_178]
push ecx ; char *
push ebx ; int
call ds:_itoa ; 這是根據數字生成key的代碼
mov edx, [ebp+0]
mov edx, [edx+24h]
add esp, 0Ch
push 40h
lea eax, [esp+1A0h+var_168]
push eax
mov eax, [esp+1A4h+var_184]
push offset unk_10035B8C
lea ecx, [esp+1A8h+var_178]
push ecx
push eax
mov ecx, ebp
call edx ; 讀取INI內容 readString(section, key)
test eax, eax
jz loc_1001127A
這段是通過readString("SO3Client", key)來獲取pak文件名, key就是"0"~"32"的字符串，也就是最多能配置32個Pak文件。
獲得了pak文件名后，下面就是打開和保存pak文件的索引數據了。
后面的注釋是我分析的時候加上的，IDA這個功能不錯！
首先new一個0x20字節的空間用來存儲pak對象（我自己命名的類），接著調用構造函數，創建pak對象。
創建對象后，要用這個Pak對象打開對應的pak文件了，這是我們下面的代碼：
首先通過
mov [edi+edx*4], eax
將對象保存，然后，調用這個類的成員函數打開pak文件，具體代碼在sub_10010ca0。
這段代碼的意思很明白了，打開文件，讀取0x20的文件頭，
這里做的是驗證文件格式，和一些必要的驗證。
這段是讀取pak內部文件數目，讀取索引數據，以備后面查詢使用。
到此為止，所有pak文件的管理對象都已經加載和設置完畢了。
以上內容看起來很順理成章，但是實際上凝聚了無數的失敗和重試。
后面是pak內部文件的查找和讀取了。
剩下的內容明天貼了～～～
]]>