青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 14,  comments - 57,  trackbacks - 0
   繼續(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文件都用一個獨(dú)立對象來管理,所有的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é)就不逐個分析了,我是寫了一個單獨(dú)的命令行工具
來測試的。

二、查詢過程

查詢函數(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ù)稍微有點(diǎn)長,分幾個部分來分析吧:

首先,驗證下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下斷點(diǎn)來得到的,為什么不是在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ù))。
剩下的,就是看看單獨(dú)內(nèi)部文件的解壓方式了,
在fread的緩沖區(qū)上設(shè)置內(nèi)存斷點(diǎn),就可以找到解壓函數(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)部文件名,相信這難不倒各位了。

posted on 2010-07-16 20:47 feixuwu 閱讀(4835) 評論(11)  編輯 收藏 引用 所屬分類: 逆向工程

FeedBack:
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-16 22:20 | yafare
hook他的lua.dll加載腳本的函數(shù),文件名以及腳本緩沖區(qū)都可以在堆棧找到。這樣更簡單一些  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-16 22:47 | feixuwu
@yafare
恩,不過這個只對lua有效,打包lua文件一般用luaL_loadBuffer加載。
而且hook了luaL_loadbuffer是得不到文件名的,對除script以外的資源也無效。  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-16 23:39 | yafare
@feixuwu

之前弄過劍俠世界的腳本,在luaL_loadBuffer斷下之后,文件名是在堆棧里面可以找到的,當(dāng)時dump了他的一套腳本,可以用來搞外掛了
  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-17 00:14 | feixuwu
@yafare
int luaL_loadbuffer (lua_State *L,
const char *buff,
size_t sz,
const char *name);
打包文件加載是從內(nèi)存中加載的,理論上來說是可以沒有文件名的。不過也可能是為了方便調(diào)試,主動將最后一個name設(shè)置為文件名了。
外掛其實有更簡單的辦法,結(jié)合協(xié)程可以做一個單獨(dú)的AI腳本,可以做得比較靈活。逆向資源最初是想做游戲卻沒有資源。。。  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-17 10:32 | yafare
@feixuwu
沒試過協(xié)程,hook了他lua腳本里面的一個timer,在那里面搞的外掛邏輯
  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-17 11:36 | feixuwu
@yafare
yafare是常在cloud的blog發(fā)言的那位?  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-17 14:46 | yafare
@feixuwu
Cloud是啥?
  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-21 19:44 | suiniannian
很強(qiáng)很厲害。  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-21 20:46 | suiniannian
你的文章很有用。
關(guān)于索引數(shù)據(jù),結(jié)合你的理解我有兩種猜測:
1. 索引數(shù)據(jù)構(gòu)成是:
[哈希數(shù)值(Uint32)] + [文件偏移(Uint32)]+[解壓后文件長度] + 2byte(文件在pak中的數(shù)據(jù)長度)+2byte(0000代表此文件在pak中沒壓縮,0020代表有壓縮)。

2.用最后1byte就可以分別文件有沒有壓縮,所以也有可能是這樣:
[哈希數(shù)值(Uint32)] + [文件偏移(Uint32)]+[解壓后文件長度] + 3byte(文件在pak中的數(shù)據(jù)長度)+1byte(00代表此文件在pak中沒壓縮,0x20代表有壓縮)。  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)[未登錄]
2013-04-26 16:38 | albert
感覺就像做夢~瀏覽完了,就是天書~看懂了,就快升天了,自己搞定,就又回到地面了~等完全透析,就進(jìn)入地獄~  回復(fù)  更多評論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2013-08-19 18:23 | 得一帥
PAK文件介紹
  PAK文件是使用在劍網(wǎng)1,2,3,劍俠世界中的用來存放資源和相關(guān)游戲客戶端文件的壓縮文件格式。

PAK文件格式結(jié)構(gòu)
  PAK文件格式被組織為一個線性的數(shù)據(jù)流,它是由一個XPackFileHeader頭部開始,接著就是文件數(shù)據(jù)區(qū)里面每個子文件的數(shù)據(jù)內(nèi)容,緊接其后的就是XPackIndexInfo信息,每個文件對應(yīng)一個XPackIndexInfo,具體分布請看圖1:
XPackFileHeader
File_Data_1
File_Data_2
File_Data_3
.......
File_Data_N
N * XPackIndexInfo
  



















                圖1

數(shù)據(jù)結(jié)構(gòu)以及說明
  XPackIndexInfo
    struct XPackFileHeader
    {
     unsigned char cSignature[4]; //四個字節(jié)的文件的頭標(biāo)志,固定為字符串'PACK'
     unsigned int uCount; //數(shù)據(jù)的條目數(shù)
     unsigned int uIndexTableOffset; //索引的偏移量
     unsigned int uDataOffset; //數(shù)據(jù)的偏移量
     unsigned int uCrc32; //校驗和(根據(jù)索引表內(nèi)容數(shù)據(jù)求得)
     unsigned int uPakTime; //打包文件制作時的時間,秒為單位time()
     unsigned char cReserved[8]; //保留的字節(jié)
    };
  
  uCount:這個PAK內(nèi)一共包含文件的個數(shù)。
  uIndexTableOffset:文件信息XPackIndexInfo在文件中的偏移位置。
  uDataOffset:文件數(shù)據(jù)區(qū)在文件的偏移。
  
  
  XPackIndexInfo
    
    struct XPackIndexInfo
    {
     unsigned int uId; //子文件id
     unsigned int uOffset; //子文件在包中的偏移位置
     unsigned int uSize; //子文件的原始大小
     unsigned int uCompressSizeFlag; //子文件壓縮后的大小和壓縮方法
    };
    
    uId:是通過HASH代碼得到的HASH值,是由該文件的目錄決定的,并不是對文件內(nèi)容進(jìn)行HASH。
    uOffset:這個偏移地址是從文件開始算起的。
    uSize:并未壓縮的文件大小。
    uCompressSizeFlag:包含2個內(nèi)容,1是壓縮的標(biāo)記,2是壓縮后的實際大小。最高字節(jié)表示壓縮標(biāo)記,低的三個字節(jié)表示子文件壓縮后的大小,對于分塊壓縮的文件,包含該文件全部分塊數(shù)據(jù),頭信息數(shù)據(jù),分塊信息表等加起來的全部大小,壓縮標(biāo)記可以使用 uCompressSizeFlag & 0xF0000000 得到,大小可以 uCompressSizeFlag & 0x07FFFFFF得到。
    
    數(shù)據(jù)區(qū)是沒有數(shù)據(jù)結(jié)構(gòu)的,它只是每個文件內(nèi)容經(jīng)過壓縮后組成的一個線性的區(qū)域,其中壓縮方式有3中:
    不壓縮,壓縮標(biāo)記為0x00000000 表示這個文件的內(nèi)容沒有被壓縮,如果某文件在使用UCL壓縮后比原來還大,那么就不壓縮了
    UCL壓縮,壓縮標(biāo)記為0x20000000 表示經(jīng)過了UCL算法壓縮,uCompressSizeFlag里的大小和uSize不相同,UCL壓縮后的大小最大支持128MB。
子文件分塊壓縮,壓縮標(biāo)記為0x10000000 表示該文件數(shù)據(jù)是經(jīng)過分塊壓縮,就是文件內(nèi)容被分成了幾塊,內(nèi)容為該文件全部分塊數(shù)據(jù),頭信息數(shù)據(jù),分塊信息表組成  回復(fù)  更多評論
  
<2025年11月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

文章轉(zhuǎn)載請注明出處

常用鏈接

留言簿(11)

隨筆分類

隨筆檔案

搜索

  •  

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            久久综合九色综合网站| 亚洲视频免费看| 国产一区激情| 国产免费一区二区三区香蕉精| 欧美日韩一区二区免费在线观看| 欧美高清视频一区二区三区在线观看| 欧美大片在线看| 欧美韩日一区| 欧美性色综合| 韩国av一区二区| 亚洲精品久久久久久久久久久久| 99精品国产在热久久下载| 一本一本久久a久久精品综合妖精| 在线视频亚洲| 久久天堂成人| 亚洲精品久久| 在线视频日本亚洲性| 香蕉久久夜色精品| 欧美国产精品劲爆| 国产欧美日韩一区二区三区在线观看 | 欧美日韩高清不卡| 国产精品伊人日日| 亚洲欧洲日本在线| 欧美一区二区日韩| 亚洲电影在线看| 亚洲专区免费| 欧美电影免费网站| 国产亚洲在线| 一区二区激情视频| 久久综合九色综合网站| 中日韩在线视频| 欧美~级网站不卡| 国产精品一区二区三区四区| 亚洲人在线视频| 久久久高清一区二区三区| 亚洲精品久久久久久一区二区 | 牛牛国产精品| 国产综合久久久久久| 一区二区三区毛片| 久久深夜福利| 亚洲专区在线| 欧美日韩一区精品| 亚洲人成网站777色婷婷| 久久久国产一区二区| 日韩视频免费大全中文字幕| 久久久www成人免费精品| 国产精品中文在线| 亚洲视频1区2区| 亚洲日本欧美| 亚洲一本视频| 亚洲免费av电影| 免费观看在线综合| 亚洲精品极品| 欧美大片在线观看一区二区| 亚洲国产精品一区在线观看不卡 | 久久精品国产亚洲一区二区三区 | 欧美高清视频一二三区| 欧美在线视频二区| 国产日韩精品电影| 久久精品99国产精品酒店日本| 在线视频日韩| 国产精品自在线| 欧美在线观看一区二区| 亚洲欧美日韩国产一区二区三区| 国产精品初高中精品久久| 亚洲特色特黄| 亚洲主播在线观看| 国内精品久久久久影院色 | 欧美乱在线观看| 一本色道久久88亚洲综合88| 亚洲欧洲一级| 欧美先锋影音| 久久久精品tv| 久久久亚洲欧洲日产国码αv| 伊人激情综合| 亚洲国产精品久久久久秋霞影院 | 免费成人美女女| 麻豆成人在线| 在线视频欧美一区| 午夜精品久久久久久99热| 国产视频综合在线| 男男成人高潮片免费网站| 免费亚洲一区二区| 亚洲一级片在线看| 欧美一区二区免费观在线| 亚洲成人原创| 一本色道久久加勒比88综合| 国产精品一区二区三区乱码| 久久久青草婷婷精品综合日韩| 猫咪成人在线观看| 亚洲午夜激情免费视频| 欧美亚洲专区| 99精品免费| 欧美一级理论性理论a| 亚洲国产视频一区二区| 中国成人亚色综合网站| 在线播放日韩| 免费视频一区| 亚洲国产高清高潮精品美女| 欧美精品1区| 欧美中在线观看| 农夫在线精品视频免费观看| 亚洲欧美一区二区视频| 久久夜色精品国产欧美乱极品| 一本色道久久99精品综合| 欧美在线精品一区| 亚洲午夜电影在线观看| 久久先锋资源| 欧美一区二区在线| 欧美日韩国产影院| 免费不卡亚洲欧美| 国产精品综合| 夜夜嗨av一区二区三区网页| 亚洲风情亚aⅴ在线发布| 亚洲欧美综合一区| 亚洲在线国产日韩欧美| 欧美91精品| 毛片一区二区| 国产日韩欧美视频在线| 亚洲国产一区二区三区高清| 亚洲电影欧美电影有声小说| 欧美在线视频免费观看| 性欧美精品高清| 欧美四级剧情无删版影片| 亚洲激情偷拍| 亚洲久久视频| 免费不卡亚洲欧美| 欧美va亚洲va香蕉在线| 韩日精品中文字幕| 亚洲欧美视频在线观看| 久久成人精品视频| 国产片一区二区| 羞羞答答国产精品www一本| 欧美一区二区久久久| 国产精品入口福利| 欧美一级理论片| 蜜桃精品久久久久久久免费影院| 韩国v欧美v日本v亚洲v| 久久婷婷久久一区二区三区| 狂野欧美激情性xxxx欧美| 国内一区二区三区在线视频| 欧美在线综合| 欧美1区2区3区| 亚洲美女在线视频| 欧美午夜激情小视频| 亚洲午夜精品久久| 久久激情网站| 亚洲国产成人av| 欧美日韩精品免费在线观看视频| 日韩视频在线观看免费| 亚洲综合二区| 国产亚洲成人一区| 久久夜色精品国产欧美乱| 亚洲激情偷拍| 欧美一区三区二区在线观看| 狠狠色狠狠色综合日日五| 男女av一区三区二区色多| 一本色道综合亚洲| 久久精品人人做人人爽电影蜜月| 激情欧美丁香| 欧美日韩极品在线观看一区| 亚洲综合激情| 欧美成人首页| 夜夜嗨av一区二区三区四季av| 国产精品av一区二区| 久久av老司机精品网站导航 | 国产女精品视频网站免费| 亚洲欧美日韩在线| 欧美va天堂va视频va在线| 亚洲美女色禁图| 国产精品一区二区久激情瑜伽 | 国产精品扒开腿做爽爽爽视频| 欧美一级专区免费大片| 欧美二区在线| 亚洲欧美日韩国产成人精品影院| 一区二区自拍| 国产精品初高中精品久久| 欧美一级在线播放| 亚洲人成小说网站色在线| 欧美一区91| 亚洲美女av在线播放| 国产日韩欧美视频| 欧美日韩卡一卡二| 欧美在线一级视频| 亚洲香蕉伊综合在人在线视看| 欧美激情性爽国产精品17p| 欧美一区网站| 在线综合+亚洲+欧美中文字幕| 亚洲丰满少妇videoshd| 国产一区二区三区丝袜| 欧美日精品一区视频| 美女精品视频一区| 欧美影院视频| 亚洲男人影院| 一本大道久久精品懂色aⅴ| 亚洲国产精品嫩草影院| 狼人社综合社区| 欧美一区二区三区视频| 亚洲丝袜av一区| 99精品视频一区|