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

posts - 14,  comments - 57,  trackbacks - 0
   繼續(xù)未完成的內(nèi)容,聲明本文僅用于學(xué)習(xí)研究,不提供解壓工具和實(shí)際代碼
由于時間倉促,劍3資源格式分析(僅用于學(xué)習(xí)和技術(shù)研究)(一) 大部分只是貼出了分析的結(jié)果,并沒有詳細(xì)的分析過程,比如:如何知道那是一個pak文件處理對象,
如何根據(jù)虛表偏移獲取實(shí)際函數(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ù)從新劍俠情緣(可能歷史更久)開始就沒有變過(確實(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)長,分幾個部分來分析吧:

首先,驗(yàn)證下Hash值是否是0,如果是0,肯定是錯了:)
然后接著開始根據(jù)這個hash值進(jìn)行查找了,經(jīng)過分析,我發(fā)現(xiàn)這個函數(shù)其實(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ù)前面的分析得到的,因?yàn)閜ak文件管理對象使用的是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文件的解壓包了,但是,我們還是沒有還原真實(shí)的文件名,
下面是我解壓的script.pak的文件的部分內(nèi)容:

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

posted on 2010-07-16 20:47 feixuwu 閱讀(4806) 評論(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è)置為文件名了。
外掛其實(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; //校驗(yàn)和(根據(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是壓縮后的實(shí)際大小。最高字節(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ù)  更多評論
  
<2013年8月>
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

文章轉(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>
            一本久久a久久免费精品不卡| 亚洲欧洲在线看| 亚洲网站在线| 日韩一级视频免费观看在线| 欧美日韩123| 亚洲欧美日韩精品久久亚洲区| 午夜免费电影一区在线观看| 国产综合精品| 欧美国产一区二区三区激情无套| 欧美国产91| 亚洲男女毛片无遮挡| 久久国产精品亚洲va麻豆| 一区二区三区在线免费观看| 亚洲黄色高清| 国产精品色午夜在线观看| 久久久久久久欧美精品| 欧美大片在线影院| 欧美一区二区成人| 免费在线观看成人av| 午夜精品www| 六十路精品视频| 亚洲一区二区三区精品在线观看| 亚洲欧美日韩精品| 亚洲裸体在线观看| 亚洲欧美视频一区| 亚洲狼人精品一区二区三区| 欧美一区二区三区精品电影| 999亚洲国产精| 久久国内精品视频| 亚洲在线观看免费| 你懂的视频欧美| 久久久精彩视频| 国产精品福利在线观看| 欧美国产成人精品| 国产一区二三区| 这里只有精品丝袜| 日韩天堂av| 美国十次了思思久久精品导航| 性色av一区二区三区在线观看| 欧美成人精品一区| 美腿丝袜亚洲色图| 欧美激情91| 久久久久国产精品午夜一区| 亚洲网站视频福利| 欧美成人免费在线视频| 久久免费午夜影院| 国产日韩av一区二区| 妖精成人www高清在线观看| 亚洲精品黄色| 久久综合九色综合欧美狠狠| 久久久久久一区二区| 国产免费观看久久| 亚洲女爱视频在线| 午夜精品影院在线观看| 国产精品黄页免费高清在线观看| 亚洲欧洲一区二区在线观看| 亚洲国产综合91精品麻豆| 久久激情中文| 狂野欧美性猛交xxxx巴西| 国产一区二区中文字幕免费看| 亚洲欧美在线aaa| 性8sex亚洲区入口| 国产欧美日韩视频一区二区| 亚洲欧美日韩视频二区| 久久精品成人欧美大片古装| 国产日本欧美一区二区三区| 性欧美精品高清| 久久综合九色欧美综合狠狠| 精品1区2区| 欧美成人蜜桃| 亚洲精品资源美女情侣酒店| 亚洲一区在线看| 国产女主播在线一区二区| 欧美在线观看一二区| 老司机免费视频久久| 亚洲日本一区二区三区| 欧美日韩成人综合在线一区二区 | 亚洲伊人观看| 欧美色精品天天在线观看视频| 一区二区三区你懂的| 久久大香伊蕉在人线观看热2| 国产亚洲精品成人av久久ww| 久久免费国产精品1| 亚洲国产视频一区二区| 亚洲一区久久久| 精品51国产黑色丝袜高跟鞋| 欧美成人性网| 亚洲欧美久久久| 欧美a级在线| 亚洲欧美成人| 1024亚洲| 国产精品网站在线观看| 久久精品国产亚洲一区二区| 亚洲欧洲在线一区| 欧美一区二区视频在线观看| 在线成人激情| 欧美无乱码久久久免费午夜一区| 午夜影院日韩| 亚洲精品少妇网址| 久久久久久综合| 中文精品视频一区二区在线观看| 国产午夜精品视频| 欧美精品亚洲精品| 久久超碰97人人做人人爱| 亚洲人成在线影院| 久久深夜福利免费观看| 亚洲午夜精品一区二区三区他趣 | 欧美精品一区二| 国产精品嫩草99av在线| 久久大逼视频| av成人天堂| 亚洲国产第一| 久久一区二区三区av| 亚洲丝袜av一区| 亚洲国产天堂久久综合| 国产欧美日韩一区| 欧美视频福利| 欧美激情国产日韩精品一区18| 亚洲欧美在线免费观看| 亚洲免费高清视频| 亚洲国产精品视频一区| 久久综合九色综合网站| 欧美一区二区三区另类| 亚洲一区视频| 99精品国产在热久久| 亚洲国产精品视频| 极品尤物一区二区三区| 国产亚洲一区二区三区在线观看 | 久久久综合精品| 午夜欧美大尺度福利影院在线看| 一区二区三区精品在线 | 久久午夜精品一区二区| 久久国产精品一区二区三区四区| 亚洲一区二区三区欧美| 亚洲美女视频在线免费观看| 亚洲韩国精品一区| 亚洲人午夜精品免费| 在线观看av不卡| 136国产福利精品导航| 精品91免费| 亚洲高清成人| 亚洲另类在线一区| 夜久久久久久| 亚洲综合大片69999| 亚洲一区在线免费观看| 西西人体一区二区| 欧美中在线观看| 久久精品日韩欧美| 老鸭窝毛片一区二区三区 | 一本一道久久综合狠狠老精东影业| 亚洲精选一区| 亚洲视频一区在线| 欧美一区1区三区3区公司| 久久成人18免费网站| 狂野欧美激情性xxxx欧美| 欧美成人一区二区三区在线观看| 欧美福利视频| 亚洲激情女人| 亚洲免费观看| 欧美亚洲综合在线| 久久视频国产精品免费视频在线| 欧美ab在线视频| 国产精品xxx在线观看www| 国产亚洲欧洲997久久综合| 影音先锋久久精品| 亚洲精品中文字幕在线| 亚洲欧美制服另类日韩| 久久影音先锋| 亚洲另类视频| 欧美在线播放视频| 欧美精品福利视频| 国产日韩精品电影| 亚洲经典三级| 先锋影音国产一区| 欧美激情麻豆| 亚洲一区二区三区视频| 快she精品国产999| 欧美午夜宅男影院| 亚洲福利国产精品| 亚欧成人精品| 亚洲精品1区2区| 欧美一区网站| 欧美午夜精品久久久久免费视 | 亚洲人成免费| 欧美亚洲一区二区在线观看| 开心色5月久久精品| 99天天综合性| 老司机一区二区| 国产精品免费区二区三区观看| 亚洲国产欧美一区二区三区丁香婷| 亚洲综合丁香| 亚洲欧洲中文日韩久久av乱码| 小黄鸭精品密入口导航| 欧美三级日韩三级国产三级| 伊甸园精品99久久久久久| 欧美中文字幕在线| 正在播放亚洲一区| 欧美大片免费看| 亚洲经典三级| 欧美顶级少妇做爰|