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

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>
            亚洲级视频在线观看免费1级| 欧美在线视频日韩| 永久免费精品影视网站| 国产精品欧美一区二区三区奶水 | 欧美日韩伊人| 欧美日韩免费观看一区三区 | 精品成人国产在线观看男人呻吟| 国产欧美一区二区三区沐欲| 国产日韩欧美亚洲一区| 国产综合色在线| 91久久精品国产| 亚洲最新在线| 欧美一级在线亚洲天堂| 久久婷婷久久| 亚洲精品国产品国语在线app| 夜夜嗨一区二区三区| 亚洲欧美成人一区二区三区| 久久精品免费| 欧美巨乳在线| 国产亚洲精品7777| 99国内精品久久| 久久久91精品| 亚洲乱码日产精品bd| 亚洲欧美日韩国产一区二区三区 | 一区二区免费看| 欧美亚洲视频一区二区| 欧美1区2区视频| 一本大道久久a久久精品综合| 欧美亚洲尤物久久| 欧美日韩国产色站一区二区三区| 国产欧美高清| 在线视频你懂得一区| 久久综合导航| 亚洲欧美成人综合| 欧美日韩色综合| 亚洲国内精品| 久久综合成人精品亚洲另类欧美| 亚洲午夜视频| 欧美日韩国产系列| 亚洲精品看片| 男女激情久久| 久久久精彩视频| 国产日韩精品一区二区三区| 宅男精品视频| 亚洲精品一区二区三区婷婷月 | 欧美国产日韩xxxxx| 亚洲国产欧美一区二区三区同亚洲 | 欧美伦理影院| 在线观看日韩av| 久久本道综合色狠狠五月| 亚洲精选在线| 欧美福利影院| 亚洲美女在线看| 欧美激情偷拍| 免费久久99精品国产自在现线| 国产视频亚洲| 久久精品国产综合| 欧美一级欧美一级在线播放| 国产精品视频yy9299一区| 中文精品视频| 一本久道久久久| 国产精品二区在线观看| 亚洲四色影视在线观看| 亚洲精品你懂的| 欧美大香线蕉线伊人久久国产精品| 精品动漫一区二区| 久热这里只精品99re8久| 久久国产精品久久久| 精品不卡一区| 亚洲国产日韩在线| 欧美日韩午夜在线| 一本久道久久综合婷婷鲸鱼| 日韩一区二区电影网| 国产精品swag| 久久久国产精品一区二区三区| 欧美在线影院| 亚洲国产成人精品久久久国产成人一区| 噜噜爱69成人精品| 欧美黑人国产人伦爽爽爽| 一区二区三区精品国产| 亚洲一级黄色av| 狠狠综合久久av一区二区小说| 欧美电影在线免费观看网站 | 国产主播一区二区三区四区| 老司机午夜免费精品视频| 男女精品网站| 亚洲在线视频观看| 欧美一区二区在线| 亚洲精品免费在线播放| 中文精品视频一区二区在线观看| 国产精品综合色区在线观看| 欧美凹凸一区二区三区视频| 欧美日韩另类综合| 久久精品一区二区三区四区| 欧美成人a视频| 午夜精品三级视频福利| 久久美女性网| 亚洲一区二区三区777| 久久精品国产久精国产思思| 99精品热6080yy久久 | 久久精品国产99精品国产亚洲性色 | 欧美久久久久久久久| 亚洲综合另类| 久久久久久久综合| 亚洲手机视频| 免费观看久久久4p| 欧美自拍偷拍| 欧美日韩国产在线播放网站| 久久综合久久综合久久综合| 欧美吻胸吃奶大尺度电影| 久久在线观看视频| 国产精品久久久久久妇女6080| 欧美大片免费观看| 国产欧美日韩精品一区| 亚洲精品视频在线观看免费| 国内精品久久久| 亚洲一区二区三区免费观看| 亚洲人成77777在线观看网| 欧美在线视频免费播放| 亚洲一区二区三区中文字幕| 麻豆精品精品国产自在97香蕉| 小辣椒精品导航| 欧美视频免费| 91久久午夜| 亚洲国产一区二区三区高清| 欧美一区影院| 欧美一区二区三区免费在线看| 欧美日韩在线看| 亚洲人人精品| 亚洲美女在线视频| 美女爽到呻吟久久久久| 久久综合狠狠综合久久综青草| 国产日韩在线看| 校园春色国产精品| 久久国产精品一区二区三区| 欧美性淫爽ww久久久久无| 亚洲美女视频| 在线视频中文亚洲| 欧美日韩天堂| 亚洲女与黑人做爰| 久久精品国产99国产精品澳门| 国产精品视频免费观看www| 亚洲视频在线看| 久久丁香综合五月国产三级网站| 国产日韩欧美在线| 久久久999精品免费| 免费高清在线一区| 亚洲人成欧美中文字幕| 欧美精品videossex性护士| 亚洲精品女人| 日韩一级黄色大片| 欧美日韩国产三级| 亚洲欧美视频| 欧美成人精品1314www| 亚洲精品国产精品国自产在线| 欧美激情综合五月色丁香小说 | 久久久久久香蕉网| 欧美电影资源| 亚洲视频欧洲视频| 国产日韩亚洲欧美综合| 久久精品亚洲一区二区三区浴池| 欧美jjzz| 午夜精品久久| 在线日韩欧美| 欧美日韩综合视频网址| 午夜精品久久久久久久久久久久久 | 欧美激情1区2区3区| 日韩午夜三级在线| 国产精品日韩欧美综合| 久久av一区二区三区亚洲| 亚洲第一天堂无码专区| 中文一区在线| 精品91免费| 国产精品久久久久影院亚瑟| 久久久久九九九| aa国产精品| 免费欧美日韩| 久久国产日韩| 亚洲色在线视频| 国内精品久久久久影院优| 欧美另类视频在线| 久久精品亚洲乱码伦伦中文 | 中日韩午夜理伦电影免费| 久久免费黄色| 亚洲无限av看| 亚洲国产一区视频| 国内偷自视频区视频综合| 欧美日韩精品免费在线观看视频| 久久aⅴ国产欧美74aaa| 正在播放欧美一区| 欧美激情一区二区三区在线| 久久er99精品| 亚洲综合色噜噜狠狠| 亚洲人屁股眼子交8| 精品91在线| 国外视频精品毛片| 国产欧美va欧美va香蕉在| 国产精品伦一区| 欧美肉体xxxx裸体137大胆| 国产综合久久久久久鬼色|