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

隨筆-90  評(píng)論-947  文章-0  trackbacks-0

前幾天公司里一個(gè)項(xiàng)目要做 MUI 支持,于是要生成一堆 XXX.dll.mui 的文件。如果這些 MUI DLL 的工程手動(dòng)去建立、維護(hù)的話,那就太!@#@!#!了。當(dāng)時(shí)是另外一個(gè)同事去做這方面的工作的,后來他給了個(gè)工具,按照它定義的簡(jiǎn)單格式來書寫多語言字符串,這個(gè)工具會(huì)從一個(gè)已經(jīng)設(shè)定好的 DLL 項(xiàng)目出發(fā),更改 RC 文件里的字符串,然后調(diào)用 VS 的 IDE 來生成 DLL。再然后調(diào)用 MUIRCT.exe 來生成 MUI 文件。

這可以節(jié)省很多時(shí)間。但是,由于是調(diào)用 VS IDE 來編譯的,一個(gè)帶有近百個(gè) Project 的 Solution 編譯起來并不快,需要一到兩分鐘。這讓我有了另辟蹊徑的念頭。

何不自己來“編譯”生成 DLL 呢?

不錯(cuò),后來我就往這個(gè)方向琢磨了。之前曾寫過一個(gè)修改 PE 文件版本號(hào)的小工具,所以現(xiàn)在對(duì)于 PE 的資源格式有點(diǎn)并不那么恐懼了。但是,往細(xì)處做下去,問題就來了。現(xiàn)在網(wǎng)上的關(guān)于 PE 格式的文章,對(duì) NTHeader 解釋得很詳細(xì),而資源段往往只講到資源目錄、資源項(xiàng),具體各項(xiàng)的存儲(chǔ)結(jié)構(gòu)卻沒有詳細(xì)說明了。

這里,關(guān)于 PE 頭等就不多說了,請(qǐng)參考網(wǎng)上的文章,特別是 http://bbs.pediy.com/showthread.php?threadid=21932。本文將著眼于資源段。

首先來看一下幾個(gè)數(shù)據(jù)結(jié)構(gòu)(這些內(nèi)容好多文章也有提及):

typedef struct _IMAGE_RESOURCE_DIRECTORY {
    DWORD   Characteristics;
    DWORD   TimeDateStamp;
    WORD    MajorVersion;
    WORD    MinorVersion;
    WORD    NumberOfNamedEntries;
    WORD    NumberOfIdEntries;
} IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;

這是資源目錄,共 16 字節(jié),其中最后兩個(gè) WORD 加起來是緊跟在后面的子項(xiàng)的數(shù)目。

typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {
    union {
        struct {
            DWORD NameOffset:31;
            DWORD NameIsString:1;
        };
        DWORD   Name;
        WORD    Id;
    };
    union {
        DWORD   OffsetToData;
        struct {
            DWORD   OffsetToDirectory:31;
            DWORD   DataIsDirectory:1;
        };
    };
} IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;

這個(gè)就是緊跟在目錄后面的資源目錄項(xiàng),共 8 字節(jié)。其中第一個(gè)成員為數(shù)據(jù)成員,最高位 1 表示數(shù)據(jù)是字符串,剩下 31 位是字符串的偏移;否則就是數(shù)值。第二個(gè)成員最高位為 1 表示下一層仍然是目錄,后 31 位指向另一個(gè) IMAGE_RESOURCE_DIRECTORY 結(jié)構(gòu);否則整個(gè)成員指向一個(gè) IMAGE_RESOURCE_DATA_ENTRY 結(jié)構(gòu)(這個(gè)馬上會(huì)講到)。需要注意的是,這里的兩個(gè) Offset 都表示從資源段開頭到目標(biāo)位置的偏移。

最后來看 IMAGE_RESOURCE_DATA_ENTRY:

typedef struct _IMAGE_RESOURCE_DATA_ENTRY {
    DWORD   OffsetToData;
    DWORD   Size;
    DWORD   CodePage;
    DWORD   Reserved;
} IMAGE_RESOURCE_DATA_ENTRY, *PIMAGE_RESOURCE_DATA_ENTRY;

這個(gè)結(jié)構(gòu)是資源數(shù)據(jù)項(xiàng),也就是資源樹的葉子,共 16 字節(jié)。其中第一個(gè)成員 OffsetToData 指向具體的數(shù)據(jù),這個(gè)偏移是個(gè) RVA,跟前面兩個(gè)不一樣。Size 表示具體數(shù)據(jù)的總字節(jié)數(shù)。后兩個(gè)成員可以為 0,CodePage 不建議使用。

PE 文件中的資源就是通過這三個(gè)結(jié)構(gòu)表示的,它們都在 WinNT.h 中定義。通常會(huì)有 3 層結(jié)構(gòu),第一層表示資源類型,第二層表示 ID,第三層標(biāo)識(shí)語言。

以上所說的是我能查到的資料里能夠提到的最大程度的內(nèi)容了。但是具體的數(shù)據(jù)如何存儲(chǔ),卻幾乎沒有文章提及。于是,花了一兩天時(shí)間來慢慢的看、加上試驗(yàn),我認(rèn)為我對(duì)字符串資源的格式基本清楚了。(下面內(nèi)容是我自己分析得出,其正確性我并不保證)。

我們先來看一個(gè)具體的例子。這是一個(gè)資源 DLL,用 Resource Hacker 查看如圖:

image

image

 

其資源段數(shù)據(jù)如下:

image

我用桔色框起來的是資源目錄,用粉色框起來的是資源目錄項(xiàng),用淺綠色框起來的是資源數(shù)據(jù)項(xiàng)。

先看第一行,這是第一層目錄,最后兩個(gè) WORD 是 0x0000 和 0x0001,表示后面“命名”的目錄項(xiàng)有 0 個(gè),使用 ID 的目錄項(xiàng)有 1 個(gè)。第二行開頭的 8 字節(jié)就是這個(gè)目錄項(xiàng),DWORD 0x00000006 表示資源類型是 6,也就是字串表,后面的地址是 0x80000018,最高位為 1,表示指向的仍然是一個(gè)目錄,其偏移是 0x00000018,也就是 0218h 處。

0218h 處這個(gè)資源目錄是第二層了。最后仍然是 0 和 1,于是我們來看 0228h 處的目錄項(xiàng)。第一個(gè) DWORD 是 1,這個(gè)跟 ID 有關(guān),稍候討論。他的第二個(gè) DWORD 是 0x80000030,仍然指向目錄。

0230 處的目錄是第三層目錄。注意到最后是 0 和 2,下面將有連續(xù)兩個(gè)目錄項(xiàng)。第一個(gè)目錄項(xiàng)值為 0x00000409(1033,英語(美國)),偏移地址 0x00000050,最高位 0,表示指向的是數(shù)據(jù)項(xiàng),而不是目錄了。第二個(gè)目錄項(xiàng)值為 0x00000804(2052,中文(中國)),偏移地址 0x0000009C。

這三層結(jié)構(gòu)和 Resource Hacker 中顯示的是一一對(duì)應(yīng)的。

我們先來看英語的那個(gè)數(shù)據(jù)項(xiàng),OffsetToData 是 0x00001060(RVA),Size 是 0x0000003C。這個(gè) DLL 文件的資源段的 VirtualAddress 是 1000h,1060h-1000h+200h = 260h,我們來看 260h 處(其實(shí)就是緊接著的地方)。我第一次看這段數(shù)據(jù)的時(shí)候也很奇怪,為什么前面空了 2 個(gè)字節(jié),后面有多出好多字節(jié)。于是我改它的 ID,試了好些次,終于找到規(guī)律了。資源目錄第二層的 ID(下文稱 ResID)和最終的字符串 ID(下文稱 StrID)有這么一個(gè)對(duì)應(yīng)關(guān)系:ResID = StrID / 16 + 1。StrID 0 到 15 所對(duì)應(yīng)的 ResID 都是 1, StrID 16 到 31 對(duì)應(yīng) ResID 2,……。反過來說,資源目錄中的 ResID 不能完全表達(dá) StrID 的信息。所以,在 260h 開始的 3Ch 個(gè)字節(jié)的數(shù)據(jù)塊里,其實(shí)要存儲(chǔ) 16 個(gè)字符串,其 StrID 分別是 0,1,2,……,15。這 16 個(gè)字符串是連續(xù)存儲(chǔ)的,結(jié)構(gòu)是:字符串長(zhǎng)度(WORD)+字符串內(nèi)容(不含結(jié)束符 0)。那些空位就由一個(gè) WORD 0 來填充(也可理解為長(zhǎng)度為 0 的字符串)。我在圖中用紅褐色的豎線劃出了這 16 個(gè)字符串的界限。后面那個(gè)中文的也是如此,就不重復(fù)說了。

到現(xiàn)在為止,對(duì)于字串表的結(jié)構(gòu),應(yīng)該說差不多清楚了。于是拿程序去生成似乎不是難事了,不過要注意的是,目錄項(xiàng)必須緊跟在目錄后面,目錄項(xiàng)指向的位置可以隨意。

事實(shí)上上面這個(gè) DLL 是我用程序生成的。我現(xiàn)在做到了從內(nèi)部數(shù)據(jù)結(jié)構(gòu)到資源 DLL 這個(gè)過程的實(shí)現(xiàn)。如果這也可以被稱為“編譯”的話,現(xiàn)在是實(shí)現(xiàn)了后端。至于前端,我還沒想好原始資源格式。要想讓這個(gè)工具有點(diǎn)用處,原始資源格式必須要:1、足夠簡(jiǎn)單(至少比 RC 文件簡(jiǎn)單),并且維護(hù)方便;2、足夠存儲(chǔ)多語言字符串。這方面我希望大家能給我一些建議。

當(dāng)然,本文的主要內(nèi)容還是討論字串表的格式,這個(gè)已經(jīng)講完了,所以,over~ bow~

posted on 2009-09-23 22:57 溪流 閱讀(2337) 評(píng)論(3)  編輯 收藏 引用 所屬分類: ASM & Crack

評(píng)論:
# re: PE 文件的字串表格式分析 2009-09-24 17:44 | 凡客誠品
學(xué)到些好東西,謝謝  回復(fù)  更多評(píng)論
  
# re: PE 文件的字串表格式分析 2009-09-25 16:46 | msnegg
why not use nmake to build your vs project in command line window directly?  回復(fù)  更多評(píng)論
  
# re: PE 文件的字串表格式分析 2009-09-25 21:14 | 溪流
@msnegg

Why nmake? Why not devenv or VCBuild, or cl ?  回復(fù)  更多評(píng)論
  

只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            欧美日本一道本| 久久噜噜噜精品国产亚洲综合| 午夜天堂精品久久久久| 亚洲私人影院| 欧美一区二区视频在线观看2020| 欧美一区二区视频在线观看| 久久久亚洲综合| 欧美激情精品久久久久| 亚洲精品乱码视频| 夜夜精品视频| 午夜日韩激情| 欧美成人综合| 国产精品视频一区二区高潮| 国产亚洲一区精品| 亚洲欧洲一区二区在线播放| 亚洲一区二区三区影院| 久久综合999| 亚洲精品一区二区网址| 香蕉成人伊视频在线观看| 蜜臀久久99精品久久久久久9 | 久久aⅴ乱码一区二区三区| 久久九九久精品国产免费直播| 亚洲盗摄视频| 亚洲自拍偷拍视频| 欧美xxx成人| 国产亚洲人成网站在线观看| 亚洲免费高清视频| 欧美国产一区二区三区激情无套| 亚洲国产高清aⅴ视频| 一区二区三区你懂的| 久久久久**毛片大全| 欧美日本一道本| 精品999久久久| 午夜视频一区在线观看| 亚洲大片免费看| 久久精品视频va| 国产欧美日韩综合精品二区| 一区二区三区四区蜜桃| 欧美电影在线免费观看网站| 欧美一区二区免费观在线| 欧美日韩精品高清| 亚洲激情小视频| 久久久久久久综合| 亚洲一区区二区| 国产精品成人免费视频| 亚洲精品中文字幕女同| 蜜桃伊人久久| 久久久久九九视频| 国产亚洲欧美日韩美女| 欧美一二区视频| 亚洲天堂网在线观看| 欧美日韩精品免费观看视频完整| 亚洲欧洲一区二区三区| 亚洲第一网站免费视频| 另类尿喷潮videofree| 国产专区综合网| 久久久亚洲成人| 久久国产精品99精品国产| 国产美女精品视频| 欧美一区在线看| 欧美一区日韩一区| 黄色资源网久久资源365| 久热精品在线| 欧美成人精品福利| 一本色道久久88综合亚洲精品ⅰ | 欧美人妖另类| 日韩视频久久| 日韩一二在线观看| 国产精品久久午夜| 久久精品72免费观看| 久久精品一本| 亚洲日本欧美| 中文在线不卡| 狠狠色狠色综合曰曰| 欧美激情精品久久久久久蜜臀 | 欧美经典一区二区三区| 日韩视频一区二区三区| 亚洲三级视频| 国产麻豆日韩欧美久久| 久久综合图片| 日韩亚洲欧美高清| 午夜在线观看欧美| 在线播放日韩| 亚洲区一区二区三区| 国产精品ⅴa在线观看h| 欧美一区二区三区视频免费| 久久久水蜜桃| 宅男66日本亚洲欧美视频| 亚洲欧美日韩在线不卡| 在线看片第一页欧美| 一本大道久久精品懂色aⅴ| 国产日韩在线一区| 亚洲国产精品精华液2区45| 国产精品国产自产拍高清av王其| 久久婷婷麻豆| 欧美午夜精品久久久久久超碰| 久久久久九九九九| 欧美日韩高清不卡| 久久久精品tv| 欧美日韩在线视频一区二区| 久久久久9999亚洲精品| 欧美日韩xxxxx| 久久亚洲国产成人| 国产精品久久久久毛片大屁完整版| 免费亚洲电影在线| 国产精品爽黄69| 亚洲精品乱码久久久久久蜜桃麻豆| 国产亚洲欧美色| 一区二区高清视频| 亚洲精品在线一区二区| 欧美一区二区三区的| 一区二区三区四区蜜桃| 玖玖玖国产精品| 久久久久久免费| 国产精品进线69影院| 亚洲区在线播放| 亚洲国产一区二区三区a毛片| 欧美在线视频a| 欧美中文字幕| 国产精品自在线| 亚洲一品av免费观看| 在线亚洲一区二区| 欧美久久久久| 91久久精品久久国产性色也91| 一区二区亚洲精品国产| 欧美中文在线免费| 久久精品亚洲乱码伦伦中文 | 久久亚洲精品一区二区| 国产精品久久毛片a| 一本色道久久88综合日韩精品| 亚洲片在线观看| 久久一二三四| 久热国产精品视频| 一区在线视频| 久久久久久高潮国产精品视| 久久久av水蜜桃| 国产亚洲精品久久久久婷婷瑜伽| 宅男噜噜噜66一区二区| 亚洲一区二区三区精品在线| 欧美日韩一区成人| 日韩一二三区视频| 亚洲图片你懂的| 国产精品视频你懂的| 亚洲欧美成人一区二区三区| 欧美一区二区在线播放| 亚洲午夜小视频| 国产欧美一区二区精品婷婷| 亚洲一区二区三区高清| 亚洲欧美视频在线观看视频| 国产精品成人一区二区艾草| 亚洲小视频在线观看| 亚洲欧美日韩久久精品| 国产精品成人在线观看| 亚洲欧美日产图| 久久久蜜臀国产一区二区| 在线播放不卡| 欧美日韩精品| 亚洲欧美一区二区三区久久| 久久午夜精品一区二区| 亚洲精品国产精品久久清纯直播| 欧美极品一区二区三区| 一区二区三区久久| 久久精品视频在线观看| 亚洲国产精品一区二区尤物区| 欧美成人免费在线| 亚洲一区图片| 美日韩在线观看| 在线亚洲免费| 精品1区2区3区4区| 欧美日韩精品一区二区三区四区| 亚洲欧美成人一区二区在线电影 | 亚洲三级色网| 欧美一区二区日韩| 在线观看91久久久久久| 欧美日韩123| 久久9热精品视频| 亚洲精品资源| 久久偷窥视频| 午夜精品999| 亚洲伦理在线| 国产欧美在线| 欧美日韩视频| 免费成人美女女| 亚洲欧美在线x视频| 亚洲国产精品精华液2区45| 欧美一区二区视频网站| 9色porny自拍视频一区二区| 精品不卡一区| 国产欧美精品va在线观看| 欧美日韩高清在线| 久久综合成人精品亚洲另类欧美| 亚洲欧美日韩国产另类专区| 亚洲精品久久久久久久久| 久久综合图片| 久久久99精品免费观看不卡| 亚洲免费视频在线观看| 99re热这里只有精品视频| 伊人男人综合视频网| 国产手机视频精品| 国产精品精品视频|