COFF文件格式

1、COFF 文件格式簡(jiǎn)介COFF：Common Object COFF (通用對(duì)象文件格式)是一種很流行的對(duì)象文件格式(注 意：這里不說(shuō)它是“目標(biāo)”文件，是為了和編譯器產(chǎn)生的目標(biāo)文件( *.o/*.obj )相區(qū)別， 因?yàn)檫@種格式不只用于目標(biāo)文件，庫(kù)文件、可執(zhí)行文件也經(jīng)常是這種格式)。 VC 所產(chǎn)生的 目標(biāo)文件( *.obj )就是這種格式。 其它的編譯器，如 GC(C GNU Compiler Collection)、ICL ( Intel C/C+ Compiler)、 VectorC ，也使用這種格式的目標(biāo)文件。不僅僅是C/C+ ，很多其它語(yǔ)言也使用這種格式的對(duì)象文件。 統(tǒng)一格式的目標(biāo)文件

2、為混合語(yǔ)言編程帶 來(lái)了極大的方便。當(dāng)然，并 不是只 有這一 種對(duì) 象文件 格式。常用格式的還有 OMF-對(duì)象模 型文 件 ( Object Module File) 以 及 ELF- 可 執(zhí) 行 及 連 接 文 件 格 式(Executable and Linking Format)。 OMF 是一大群 IT 巨頭在 n 年制定的一種格式，在 Windows 平臺(tái)上很常見。大家喜歡的 Borland 公司現(xiàn)在使用的目標(biāo)文件就是這種 格式。 MS和 Intel 在 n 年前用的也是這種格式，現(xiàn)在都改投異側(cè)，用 COFF 格式了。 ELF 格式在非 Windows 平臺(tái)上使用得比較多，在 Wind

3、ows 平臺(tái)基本上沒見過(guò)。做為程序員， 很有必要認(rèn)識(shí)一下這些你經(jīng)常打交道的家伙！不過(guò)這次讓我介紹 COFF 先！ 在 COFF 文件格式中，偏移COFF文件格式整體結(jié)構(gòu)圖Optional HeaderSection HeaderSection DataRelocation DirectivesLine NumbersSymbol TableString Table1.文件頭()2.可選頭(Optional Header)3.段落頭(Section Header)4.段落數(shù)據(jù)(Section Data)5.重定位表(Relocation Directives)6.行號(hào)表(Line Numbers

4、)7.符號(hào)表(Symbol Table)8.字符串表(String Table)文件的結(jié)構(gòu)大體上就是這樣了。長(zhǎng)得是丑了 點(diǎn)，不過(guò)還算它的設(shè)計(jì)者有點(diǎn)遠(yuǎn)見。可擴(kuò)充性設(shè) 計(jì)得不錯(cuò)，以致于沿用至今。了解了文件的整體 結(jié)構(gòu)，現(xiàn)在讓我們來(lái)逐個(gè)段落分析它。 COFF文件一共有 8 種數(shù)據(jù)，自上而下分別為：COFF 文件頭/typedef struct _IMAGE_ WORD Machine;WORD NumberOfSections;DWORD TimeDateStamp;/section/ 一般是此文檔生成的時(shí)間DWORD PointerToSymbolTable;/symbol tableDWORD

5、NumberOfSymbols; /symbol表的文件偏移地址表個(gè)數(shù)WORDSizeOfOptionalHeader;/0no used inobjCharacteristics; /0 no used in obj file IMAGE_, *PIMAGE_;節(jié)（節(jié)目錄 節(jié)數(shù)據(jù)）各個(gè)段的內(nèi)容和重定位信息頭（這個(gè)重定位信息頭不一定每個(gè)段都有，貌似只有 .text 才有，這個(gè)不太確定），此部分的偏移地址是由 section 頭指定的。typedef struct _IMAGE_SECTION_HEADER BYTE NameIMAGE_SIZEOF_SHORT_NAME;union DWORD

6、 PhysicalAddress;DWORD VirtualSize; Misc;/no used in obj fileDWORDVirtualAddress;DWORDSizeOfRawData;/ 大小DWORDPointerToRawData;/ 偏移DWORDPointerToRelocations;/relocations頭 文件偏移DWORDPointerToLinenumbers;/WORDNumberOfRelocations;/recolations個(gè)數(shù)WORDNumberOfLinenumbers; /DWORD Characteristics;/section屬性 IM

7、AGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;重定位表既然有表，那么就會(huì)有記錄。重定位表中的每一條記錄就是一條重定位信息。這個(gè)記錄 的結(jié)構(gòu)很簡(jiǎn)單，如下：typedef struct unsigned long ulAddr; /定位偏移unsigned long ulSymbol; /符號(hào)unsigned short usType; / RELOC;有夠簡(jiǎn)單吧，一共只三個(gè)成員！ 文段，起始位置為 0x010 ， ulAddr 且信息的長(zhǎng)度要看你的代碼的類型，定位類型ulAddr 是要定位的內(nèi)容在段內(nèi)偏移。比如：一個(gè)正 的值為 0x05 ，那你的定位信息就

8、要寫在 0x15 處。而 32 位的代碼要寫 4 個(gè)字節(jié)， 16 位的就只要字 2 個(gè)字 節(jié)。ulSymbol 是符號(hào)索引，它指向符號(hào)表中的一個(gè)記錄。注意，這里是索引，不是偏移！ 它只是符號(hào)表中的一個(gè)記錄的記錄號(hào)。這個(gè)成員指明了重定位信息所對(duì)映的符號(hào)。 usType 是重定位類型的標(biāo)識(shí)。 32 位代碼中，通常只用兩種定位方式。一是絕對(duì)定位，二 是相對(duì)定位。其代碼如下： 值 名稱 說(shuō)明6 RELOC_ADDR32 32 位絕對(duì)定位。20 RELOC_REL32 32 位相對(duì)定位。 對(duì)于不同的處理器，這些值也不盡相同。這里給出的是 i386 平臺(tái)上最常用的兩個(gè)種 定位方式的標(biāo)識(shí)。其定位方式如下：絕

9、對(duì)定位 在絕對(duì)定位方式下，你要給出符號(hào)的絕對(duì)地址（注意，有時(shí)候這里可能不是地址，而 是值，對(duì)于常量來(lái)說(shuō)，你不用給出它的地值，只用給出它的值）。當(dāng)然，這個(gè)地址也不是現(xiàn) 成的，你要用符號(hào)的相對(duì)地址它所在段的相對(duì)地址來(lái)得到它的絕對(duì)地址。公式：符號(hào)絕對(duì)地址段偏移符號(hào)偏移 這些偏移量你要分別從段落頭和符號(hào)表中得到。當(dāng)段落要重定位時(shí)，當(dāng)然還要先重定 位段落，才能定位其中的符號(hào)。相對(duì)定位 相對(duì)定位要復(fù)雜一些。它所要的地址信息是相對(duì)于當(dāng)前位置的偏移，這個(gè)當(dāng)前位置就 是 ulAddr 所指向的這個(gè)偏移的絕對(duì)地址后四個(gè)字節(jié) （ 32 位代碼是四個(gè)字節(jié)， 16 位是兩個(gè) 字節(jié)）的位置。也就是用定位偏移當(dāng)前段偏移機(jī)器

10、字長(zhǎng) 8公式：當(dāng)前地址定位偏移當(dāng)前段偏移機(jī)器字長(zhǎng) 8有了當(dāng)前地址， 相對(duì)地址就好計(jì)算了。 只要用符號(hào)的絕對(duì)地址減去當(dāng)前地址就可以了。 公式：相對(duì)地址符號(hào)絕對(duì)地址 - 當(dāng)前地址計(jì)算好了地址， 把它寫到 ulAddr 所指向的位置， 就一切 OK！你已經(jīng)完成了重定位的 工作了。行號(hào)表行號(hào)表在調(diào)試時(shí)很有用。 它把可執(zhí)行的二進(jìn)制代碼與源代碼的行號(hào)之間建立了對(duì)映關(guān)系。 這 樣，當(dāng)程序執(zhí)行不正確時(shí)（其實(shí)正確的也可以 J ），我們就可以根據(jù)當(dāng)前執(zhí)行代碼的位置得 知出錯(cuò)源代碼的行號(hào)，再加以修改。如果沒有它的話，鬼才知道是哪一行出了毛??！它的格式也很簡(jiǎn)單。只有兩個(gè)成員，如下：typedef struct uns

11、igned long ulAddrORSymbol; /代碼地址或符號(hào)索引unsigned short usLineNo; /行號(hào) LINENO;讓我們先看第二個(gè)成員， usLineNo 。這是一個(gè)從 1 開始計(jì)數(shù)的計(jì)數(shù)器，它代表源代碼的行 號(hào)。第一個(gè)成員 ulAddrORSymbol 在行號(hào)大于 0 時(shí)，代表源代碼的地址；而當(dāng)行號(hào)為 0 時(shí)，它就成了行號(hào)所對(duì)映的符號(hào)在符號(hào)表中的索引。下面讓我們來(lái)看看符號(hào)表吧！符號(hào)表符號(hào)表是對(duì)象文件中用來(lái)保存符號(hào)信息的一張表， 也是 COFF 文件中最為復(fù)雜的一張表。 所 cName 符號(hào)名稱，和前面所有的名稱一樣，它也是 8 個(gè)字節(jié)，但不同的是它在一個(gè)聯(lián)合體

12、 中。和它占相同的存儲(chǔ)空間的還有 ulZero 和 ulOffset 這兩個(gè)成員。如果符號(hào)的名稱只 有8個(gè)字符，那很好，可以直接放到這個(gè) cName 中；可是，如果名稱的長(zhǎng)度大于 8個(gè)字節(jié)， 這里就放不下了，只好放到字符串表中。這時(shí)候， ulZero 的值就會(huì)為 0 ，而在 ulOffset 中會(huì)給出我們所用的符號(hào)的名稱在字符串表中的偏移。有段落使用到的符號(hào)都在這個(gè)表里。 typedef struct union char cName8; /struct unsigned long ulZero; /unsigned long ulOffset; / e; e;unsigned long ul

13、Value; / short iSection;/unsigned short usType; / unsigned char usClass; / unsigned char usNumAux; / SYMENT;它也是由很多條記錄組成， 每條記錄都以如下結(jié)構(gòu)保存：符號(hào)名稱字符串表標(biāo)識(shí)字符串偏移符號(hào)值 符號(hào)所在段 符號(hào)類型 符號(hào)存儲(chǔ)類型 符號(hào)附加記錄數(shù)一個(gè)符號(hào)有了名稱不夠，它還要有值！ ulValue 就是這個(gè)符號(hào)所代表的值。iSection 成員指出了這個(gè)符號(hào)所在的段落。 如果它的值為 0 ，那么這個(gè)符號(hào)就是一個(gè)外部 符號(hào)，要從其它的 COFF 文件中解析（連接多個(gè)目標(biāo)文件就是要解析這種符

14、號(hào)）。當(dāng)它的值 為-1 時(shí)，說(shuō)明這個(gè)符號(hào)的值是一個(gè)常量，不是它在段落中的偏移。而當(dāng)它的值為-2 時(shí)，這個(gè)符號(hào)只是一個(gè)調(diào)試符號(hào)，只有在調(diào)試時(shí)才會(huì)用到它。當(dāng)它大于 0 時(shí)，才是符號(hào)所在段的 索引值。usType 是符號(hào)的類型標(biāo)識(shí)。它用來(lái)說(shuō)明這個(gè)符號(hào)的類型，是函數(shù)？整型？還是其它什么。 這個(gè)標(biāo)識(shí)是兩個(gè)字節(jié)。 字節(jié)的低四位是基本標(biāo)識(shí)， 它指出了符號(hào)的基本類型， 如整型， 字符， 結(jié)構(gòu)，聯(lián)合等。高四位指出了符號(hào)的高級(jí)類型，如指針（ 0001b ），函數(shù)（ 0010b ），數(shù)組 （0011b ），無(wú)類型 （0000b ）等。現(xiàn)在的編譯器， 通常不使用基本類型， 只使用高級(jí)類型。 所以，符號(hào)的基本類型通常被

15、設(shè)為 0。高字節(jié)通常未用。usClass 是符號(hào)的存儲(chǔ)類型標(biāo)識(shí)。它指明了符號(hào)的存儲(chǔ)方式。其值與意義見下表：值 名稱 說(shuō)明NULL 0 無(wú)存儲(chǔ)類型。AUTOMATIC 1 自動(dòng)類型。通常是在棧中分配的變量。EXTERNAL 2 外部符號(hào)。當(dāng)為外部符號(hào)時(shí)， iSection 的值應(yīng)該為 0 ，如果不為 0，則 ulValue 為符號(hào)在段中的偏移。STATIC 3 靜態(tài)類型。 ulValue 為符號(hào)在段中的偏移。如果偏移為 0 ，那么這個(gè)符號(hào)代 表段名。REGISTER 4 寄存器變量。MEMBER_OF_STRUCT 8 結(jié)構(gòu)成員。 ulValue 值為該符號(hào)在結(jié)構(gòu)中的順序。 STRUCT_TAG

16、 10 結(jié)構(gòu)標(biāo)識(shí)符。MEMBER_OF_UNION 11 聯(lián)合成員。 ulValue 值為該符號(hào)在聯(lián)合中的順序。 UNION_TAG 12 聯(lián)合標(biāo)識(shí)符。TYPE_DEFINITION 13 類型定義。FUNCTION 101 函數(shù)名。FILE 102 文件名。最后一個(gè)成員 usNumAux 是附加記錄的數(shù)量。附加記錄是用來(lái)描述符號(hào)的一些附加信息， 為了便于保存， 這些附加記錄通常選擇成為一條符號(hào)信息記錄的整數(shù)倍 （多數(shù)為 1 ）。所以， 如果這個(gè)成員的值為 1 ，那么就表示在當(dāng)前符號(hào)信息記錄后附加了一條記錄，用來(lái)保存附加信息。附加信息的結(jié)構(gòu)是與符號(hào)的類型以及存儲(chǔ)類型相關(guān)的。 不同的類型的符號(hào)，

17、 其附加信息 （如 果有的話）的結(jié)構(gòu)也不同。如果你不在意這些內(nèi)容，也可以把它們乎略。當(dāng)段的類型為 FILE 時(shí)，附加信息就是一個(gè)字符串，它是目標(biāo)文件對(duì)應(yīng)源文件的名稱。其它 類型在介紹 PE 時(shí)再進(jìn)行詳細(xì)討論。字符串表不用多說(shuō)， 瞎子也能看出這個(gè)表是用來(lái)保存字符串的。 它緊接在符號(hào)表后。 至于為什么要保 存字符串，前面已經(jīng)說(shuō)過(guò)了。這里就不再多說(shuō)了，只說(shuō)說(shuō)字符串的保存格式。字符串表是所有節(jié)中最簡(jiǎn)單一節(jié)。如下圖：0 4字符串表長(zhǎng)度 字符串 10 字符串 n0 字符串表的前四個(gè)字節(jié)是字符串表的長(zhǎng)度，以字節(jié)為單位。其后就是以 0 結(jié)尾的字符串（ C 風(fēng)格字符串）。 要注意的是，字符串表的長(zhǎng)度不僅僅是字符串的長(zhǎng)度（這個(gè)長(zhǎng)度要包