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

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>
            国产亚洲精品久久久久动| 久久在线精品| 国产综合香蕉五月婷在线| 欧美日韩在线精品| 欧美深夜影院| 国产精品系列在线| 国产伊人精品| 亚洲欧洲一区二区三区在线观看 | 久久久久久高潮国产精品视| 久久精品一区二区三区中文字幕| 另类欧美日韩国产在线| 最新国产の精品合集bt伙计| 亚洲国产午夜| 亚洲综合首页| 99v久久综合狠狠综合久久| 亚洲乱码国产乱码精品精| 中文精品99久久国产香蕉| 欧美一区二区视频观看视频| 久久综合久久综合久久| 亚洲国产精品va在线看黑人| 在线亚洲激情| 久久婷婷人人澡人人喊人人爽| 欧美高清在线精品一区| 国产精品一国产精品k频道56| 激情视频一区二区三区| 在线一区亚洲| 麻豆9191精品国产| 在线精品视频一区二区| 男人的天堂亚洲在线| 欧美四级电影网站| 在线看国产一区| 亚洲欧美清纯在线制服| 欧美成人伊人久久综合网| 亚洲图片欧美一区| 免费成人高清视频| 国产日韩视频一区二区三区| 亚洲麻豆视频| 久久全国免费视频| 在线综合亚洲| 欧美久久一区| 亚洲国产精品久久久| 久久se精品一区精品二区| 日韩视频欧美视频| 欧美国产日本| 91久久国产综合久久| 久久久久国产精品一区| 一区二区三区国产盗摄| 免费观看在线综合| 在线欧美影院| 久久综合999| 欧美一级视频| 国产日韩在线一区二区三区| 亚洲制服丝袜在线| 日韩小视频在线观看专区| 久久综合福利| 韩国av一区| 久久精品在线视频| 欧美一区二区三区久久精品| 国产精品视频午夜| 午夜亚洲一区| 欧美一区在线直播| 国产亚洲福利| 久久久久久高潮国产精品视| 亚洲在线观看| 欧美激情亚洲| 日韩天天综合| 亚洲精品一区二区三区蜜桃久| 奶水喷射视频一区| 洋洋av久久久久久久一区| 亚洲日产国产精品| 欧美日韩一区二区在线播放| 一本色道久久99精品综合| 亚洲麻豆国产自偷在线| 欧美日韩成人精品| 亚洲欧美韩国| 久久国产88| 亚洲人永久免费| 一本在线高清不卡dvd| 国产精品日本| 国产欧美日韩综合精品二区| 欧美在线播放| 狂野欧美一区| 亚洲无毛电影| 欧美在线免费一级片| 最新国产成人在线观看| 一本大道av伊人久久综合| 国产精品一区在线观看| 蜜桃av久久久亚洲精品| 国产精品成av人在线视午夜片| 欧美破处大片在线视频| 亚洲一区二区不卡免费| 亚洲欧美日韩国产另类专区| 在线播放日韩专区| 亚洲精品少妇| 国产日韩一区二区三区在线| 亚洲夫妻自拍| 国产精品嫩草久久久久| 美女精品视频一区| 国产精品久久久久久久电影| 麻豆精品网站| 国产精品入口日韩视频大尺度| 裸体一区二区三区| 欧美天天视频| 欧美成人一品| 国产拍揄自揄精品视频麻豆| 亚洲国产综合视频在线观看| 国产午夜一区二区三区| 亚洲精品少妇30p| 在线观看精品一区| 亚洲免费在线视频| 中文在线资源观看网站视频免费不卡| 亚洲一区二区三区成人在线视频精品| 在线国产日韩| 欧美伊人久久久久久午夜久久久久 | 欧美成人一品| 国产拍揄自揄精品视频麻豆| 亚洲乱码久久| 亚洲精品少妇30p| 久久精品天堂| 亚洲欧美日韩专区| 欧美日韩国产另类不卡| 欧美韩国日本一区| 一色屋精品亚洲香蕉网站| 香港久久久电影| 午夜一区在线| 国产精品久久7| 亚洲美女区一区| 亚洲国产另类久久久精品极度| 性欧美xxxx视频在线观看| 亚洲一级在线| 国产精品www色诱视频| 亚洲精品综合精品自拍| 亚洲卡通欧美制服中文| 你懂的视频一区二区| 欧美二区视频| 亚洲黄色有码视频| 欧美成人一区在线| 亚洲欧洲日产国产综合网| 亚洲国产视频一区| 欧美xxxx在线观看| 亚洲激情小视频| 一区二区三区精品国产| 欧美日韩免费区域视频在线观看| 亚洲人体影院| 一本高清dvd不卡在线观看| 欧美大片专区| 亚洲人永久免费| 亚洲综合第一页| 国产欧美三级| 久久久久久久久久久久久9999| 久久久亚洲国产美女国产盗摄| 国产精品99久久99久久久二8 | 免费在线播放第一区高清av| 欧美激情视频一区二区三区免费| 亚洲高清不卡av| 欧美激情国产日韩| 一区二区三区欧美视频| 性色av一区二区三区| 国产亚洲欧美日韩美女| 久久亚洲二区| 亚洲精品乱码久久久久久按摩观| 99视频一区二区| 国产精品日韩一区二区| 久久久国产一区二区三区| 亚洲黄色免费| 校园激情久久| 亚洲国产精品日韩| 欧美日韩一区二区免费视频| 一本到高清视频免费精品| 久久精品国产在热久久| 亚洲激情六月丁香| 国产精品入口福利| 久久亚洲图片| 亚洲色图综合久久| 免费av成人在线| 日韩一级二级三级| 国产亚洲精品美女| 欧美精品观看| 欧美资源在线观看| 亚洲精品国产日韩| 久久色中文字幕| 亚洲永久在线观看| 亚洲欧洲日夜超级视频| 国产日韩欧美在线| 欧美成人官网二区| 欧美亚洲网站| 一区二区三区四区五区视频| 蜜桃av一区| 欧美在线亚洲综合一区| 一区二区三区回区在观看免费视频| 国产手机视频一区二区| 欧美日韩精品不卡| 久久综合中文字幕| 午夜精品久久久久| 亚洲视频高清| 亚洲精品人人| 亚洲第一福利视频| 免费一级欧美片在线播放| 久久xxxx| 亚洲综合色视频|