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

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

一、路徑名哈希

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

二、查詢過程

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

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

這個(gè)函數(shù)稍微有點(diǎn)長,分幾個(gè)部分來分析吧:

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



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

接著前面的sub_100108B0 來看吧

這一段是保存查詢到的數(shù)據(jù)到對(duì)象里。分析到這里,我只知道16個(gè)索引數(shù)據(jù)前4個(gè)字節(jié)是hash值,那么剩下的12個(gè)字節(jié)呢,
剩下的數(shù)據(jù)基本可以確定是:文件偏移、文件長度。我是個(gè)懶人,接下來的分析我是通過在fseek、fread下斷點(diǎn)來得到的,為什么不是在SetFilePointer和ReadFile呢,
這是根據(jù)前面的分析得到的,因?yàn)閜ak文件管理對(duì)象使用的是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
這個(gè)函數(shù)不算太長,一開始我也想逆向成C語言,后來看到如此多的分支就放棄了,轉(zhuǎn)而用了一個(gè)偷懶的辦法解決了:
從匯編代碼可知這個(gè)函數(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)可以寫出一個(gè)pak文件的解壓包了,但是,我們還是沒有還原真實(shí)的文件名,
下面是我解壓的script.pak的文件的部分內(nèi)容:

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

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

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

之前弄過劍俠世界的腳本,在luaL_loadBuffer斷下之后,文件名是在堆棧里面可以找到的,當(dāng)時(shí)dump了他的一套腳本,可以用來搞外掛了
  回復(fù)  更多評(píng)論
  
# 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)試,主動(dòng)將最后一個(gè)name設(shè)置為文件名了。
外掛其實(shí)有更簡(jiǎn)單的辦法,結(jié)合協(xié)程可以做一個(gè)單獨(dú)的AI腳本,可以做得比較靈活。逆向資源最初是想做游戲卻沒有資源。。。  回復(fù)  更多評(píng)論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-17 10:32 | yafare
@feixuwu
沒試過協(xié)程,hook了他lua腳本里面的一個(gè)timer,在那里面搞的外掛邏輯
  回復(fù)  更多評(píng)論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-17 11:36 | feixuwu
@yafare
yafare是常在cloud的blog發(fā)言的那位?  回復(fù)  更多評(píng)論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-17 14:46 | yafare
@feixuwu
Cloud是啥?
  回復(fù)  更多評(píng)論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-21 19:44 | suiniannian
很強(qiáng)很厲害。  回復(fù)  更多評(píng)論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2010-07-21 20:46 | suiniannian
你的文章很有用。
關(guān)于索引數(shù)據(jù),結(jié)合你的理解我有兩種猜測(cè):
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ù)  更多評(píng)論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)[未登錄]
2013-04-26 16:38 | albert
感覺就像做夢(mèng)~瀏覽完了,就是天書~看懂了,就快升天了,自己搞定,就又回到地面了~等完全透析,就進(jìn)入地獄~  回復(fù)  更多評(píng)論
  
# re: 劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(二)
2013-08-19 18:23 | 得一帥
PAK文件介紹
  PAK文件是使用在劍網(wǎng)1,2,3,劍俠世界中的用來存放資源和相關(guān)游戲客戶端文件的壓縮文件格式。

PAK文件格式結(jié)構(gòu)
  PAK文件格式被組織為一個(gè)線性的數(shù)據(jù)流,它是由一個(gè)XPackFileHeader頭部開始,接著就是文件數(shù)據(jù)區(qū)里面每個(gè)子文件的數(shù)據(jù)內(nèi)容,緊接其后的就是XPackIndexInfo信息,每個(gè)文件對(duì)應(yīng)一個(gè)XPackIndexInfo,具體分布請(qǐng)看圖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]; //四個(gè)字節(jié)的文件的頭標(biāo)志,固定為字符串'PACK'
     unsigned int uCount; //數(shù)據(jù)的條目數(shù)
     unsigned int uIndexTableOffset; //索引的偏移量
     unsigned int uDataOffset; //數(shù)據(jù)的偏移量
     unsigned int uCrc32; //校驗(yàn)和(根據(jù)索引表內(nèi)容數(shù)據(jù)求得)
     unsigned int uPakTime; //打包文件制作時(shí)的時(shí)間,秒為單位time()
     unsigned char cReserved[8]; //保留的字節(jié)
    };
  
  uCount:這個(gè)PAK內(nèi)一共包含文件的個(gè)數(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值,是由該文件的目錄決定的,并不是對(duì)文件內(nèi)容進(jìn)行HASH。
    uOffset:這個(gè)偏移地址是從文件開始算起的。
    uSize:并未壓縮的文件大小。
    uCompressSizeFlag:包含2個(gè)內(nèi)容,1是壓縮的標(biāo)記,2是壓縮后的實(shí)際大小。最高字節(jié)表示壓縮標(biāo)記,低的三個(gè)字節(jié)表示子文件壓縮后的大小,對(duì)于分塊壓縮的文件,包含該文件全部分塊數(shù)據(jù),頭信息數(shù)據(jù),分塊信息表等加起來的全部大小,壓縮標(biāo)記可以使用 uCompressSizeFlag & 0xF0000000 得到,大小可以 uCompressSizeFlag & 0x07FFFFFF得到。
    
    數(shù)據(jù)區(qū)是沒有數(shù)據(jù)結(jié)構(gòu)的,它只是每個(gè)文件內(nèi)容經(jīng)過壓縮后組成的一個(gè)線性的區(qū)域,其中壓縮方式有3中:
    不壓縮,壓縮標(biāo)記為0x00000000 表示這個(gè)文件的內(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ù)  更多評(píng)論
  
<2025年9月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

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

常用鏈接

留言簿(11)

隨筆分類

隨筆檔案

搜索

  •  

最新評(píng)論

閱讀排行榜

評(píng)論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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在线| 日韩视频一区| 国产伦精品一区二区三区| 久久久久久香蕉网| 欧美韩日一区二区| 亚洲免费视频网站| 久久av红桃一区二区小说| 亚洲高清视频一区| 99伊人成综合| 一区在线播放视频| 亚洲日本欧美天堂| 国产精品久久久久久久久久久久久久| 欧美在线关看| 欧美激情区在线播放| 午夜在线a亚洲v天堂网2018| 久久九九精品| 在线午夜精品自拍| 久久精品首页| 亚洲香蕉网站| 蜜臀av在线播放一区二区三区| 亚洲午夜在线观看| 每日更新成人在线视频| 午夜亚洲影视| 欧美激情综合色综合啪啪| 久久福利一区| 欧美三日本三级少妇三2023 | 欧美色图五月天| 久久久噜久噜久久综合| 国产精品久久久久久久久久久久久久| 男女激情视频一区| 国产精品美女主播在线观看纯欲| 欧美韩日精品| 国产真实精品久久二三区| 99精品国产高清一区二区| 亚洲第一毛片| 久久久久国产精品www| 午夜精品久久久久久久99樱桃| 免费成人在线视频网站| 久久精选视频| 国产偷久久久精品专区| 在线亚洲欧美视频| 一本色道久久88综合日韩精品| 蜜桃久久精品一区二区| 久久精品一本久久99精品| 国产精品国产三级国产专区53| 91久久香蕉国产日韩欧美9色| 亚洲国产成人porn| 久久午夜电影| 欧美激情久久久久| 亚洲成人资源网| 久久人人爽国产| 葵司免费一区二区三区四区五区| 国产区精品视频| 亚洲一区二区在| 国产精品r级在线| 一区二区免费看| 亚洲网站啪啪| 国产精品成人一区二区三区夜夜夜 | 久久久精品国产99久久精品芒果| 午夜亚洲福利在线老司机| 欧美日韩一级片在线观看| 亚洲日本理论电影| 亚洲综合欧美| 国产日韩精品一区二区浪潮av| 亚洲午夜免费福利视频| 午夜视频在线观看一区二区三区 | 精品999在线播放| 裸体一区二区三区| 亚洲缚视频在线观看| 亚洲精品欧美日韩专区| 欧美另类视频| 亚洲综合99| 老巨人导航500精品| 亚洲成人中文| 欧美性jizz18性欧美| 亚洲欧美日韩人成在线播放| 久久久精品久久久久| 亚洲国产高清高潮精品美女| 欧美黑人一区二区三区| 亚洲网站在线播放| 久久免费视频观看| 亚洲美女91| 国产免费一区二区三区香蕉精| 久久久久这里只有精品| 亚洲毛片在线| 久久精品国产亚洲一区二区| 亚洲黄色小视频| 国产精品乱人伦中文| 久久久精品性| 99re8这里有精品热视频免费 | 91久久中文| 久久精品视频一| 亚洲欧洲精品一区| 国产精品久久久久aaaa| 久久久91精品国产| 99xxxx成人网| 欧美ed2k| 欧美在线观看视频在线| 亚洲精品在线观| 国产欧美日韩视频一区二区| 免播放器亚洲一区| 午夜视频在线观看一区二区三区 | 亚洲免费影视| 亚洲人成小说网站色在线| 国产午夜精品久久| 欧美日韩国产综合在线| 久久久久成人网| 亚洲欧美卡通另类91av| 亚洲国产片色| 狂野欧美性猛交xxxx巴西| 亚洲欧洲99久久| 亚洲婷婷在线| 亚洲免费精彩视频| 蜜桃av一区二区| 欧美在线高清| 亚洲女人天堂av| 一本色道综合亚洲| 亚洲人成网站影音先锋播放| 久久综合一区二区三区| 性感少妇一区| 欧美一区二区高清在线观看| 亚洲色图综合久久| 亚洲精品日韩在线观看| 亚洲国产精品ⅴa在线观看 | 欧美日韩免费区域视频在线观看| 久久中文字幕一区| 欧美在线亚洲| 欧美一区深夜视频| 性刺激综合网| 新片速递亚洲合集欧美合集 | 女生裸体视频一区二区三区| 久久久国产亚洲精品| 欧美亚洲视频| 久久久精品久久久久| 久久久久久91香蕉国产| 久久精品国产77777蜜臀 | 亚洲欧洲美洲综合色网| 91久久国产综合久久| 亚洲激情av在线| 日韩视频在线一区二区| av成人老司机| 亚洲欧美日韩精品久久| 亚洲综合色丁香婷婷六月图片| 亚洲一级片在线观看| 亚洲欧美视频在线观看| 性做久久久久久免费观看欧美| 亚洲女性喷水在线观看一区| 午夜精品在线观看| 久久久99久久精品女同性| 媚黑女一区二区| 亚洲人成在线观看一区二区| 中文国产成人精品久久一| 亚洲亚洲精品在线观看| 欧美一区二区黄色| 免费成人av在线看| 欧美日韩国产999| 国产欧美日韩视频一区二区| 在线观看日韩欧美| 日韩亚洲综合在线| 午夜欧美精品久久久久久久| 久久这里只有| 亚洲三级免费电影| 午夜精品一区二区三区在线播放| 久久久之久亚州精品露出| 欧美第一黄网免费网站| 国产精品亚发布| 亚洲欧洲精品一区二区精品久久久| 一区二区三区成人精品| 久久精品一区二区三区四区| 亚洲国产高清一区| 亚洲尤物在线视频观看| 久久九九精品99国产精品| 欧美性天天影院| 在线观看一区视频| 午夜精品国产精品大乳美女| 久色成人在线| 中国av一区| 欧美mv日韩mv国产网站| 国产精品一区免费观看| 亚洲九九爱视频| 美日韩精品免费| 亚洲免费视频在线观看| 欧美精品一区二| …久久精品99久久香蕉国产| 亚洲综合国产| 亚洲国产导航| 久久九九国产精品| 国产日韩欧美a| 亚洲制服少妇| 99re热这里只有精品视频 | 欧美伊人久久久久久久久影院| 欧美精品免费在线| 亚洲国产日韩欧美一区二区三区|