COFF文件格式

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

2、的方便。當(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和In tel在n年前用的也是這種格式，現(xiàn)在都改投異側(cè)，用COFF格式了。ELF格式在非 Windows平臺(tái)上使用得比較多，在Windows平臺(tái)基本上沒見過。做為程序員，很有必要認(rèn)識(shí)一下這些你經(jīng)常打交道的家伙！不過這次讓我介紹C

3、OFF先！在COFF文件格式中，偏移COFF文件格式整體結(jié)構(gòu)圖Opti onal HeaderSectio n HeaderSecti on Data文件的結(jié)構(gòu)大體上就是這樣了。長(zhǎng)得是丑了 點(diǎn)，不過還算它的設(shè)計(jì)者有點(diǎn)遠(yuǎn)見?？蓴U(kuò)充性設(shè) 計(jì)得不錯(cuò)，以致于沿用至今。了解了文件的整體 結(jié)構(gòu)，現(xiàn)在讓我們來逐個(gè)段落分析它。COFF文件一共有8種數(shù)據(jù)，自上而下分別為:Relocati on DirectivesLine NumbersSymbol TableStri ng Table1.文件頭（）2.可選頭（Optio nal Header)3.段落頭（Secti on Header)4.段落數(shù)據(jù)(Sect

4、ion Data)5.重定位表(Relocation Directives)6.行號(hào)表（Line Numbers)7.符號(hào)表（Symbol Table)8.字符串表(String Table)COFF文件頭typedef structM AGE_/WORD Machi ne;WORD NumberOfSectio ns;DWORD TimeDateStamp;/sect ion/ 一般是此文檔生成的時(shí)間DWORD Poi nterToSymbolTable;/symbol tableDWORD NumberOfSymbols; /symbol表的文件偏移地址表個(gè)數(shù)WORDSizeOfOptio

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

6、bj fileDWORDVirtualAddress;DWORDSizeOfRawData;/大小DWORDPoi nterToRawData;/偏移DWORDPoin terToRelocati ons;/relocati ons頭文件偏移DWORDPoin terToL inenu mbers;/WORDNumberOfRelocati ons;/recolati ons個(gè)數(shù)WORDNumberOfL inenu mbers; /DWORD Characteristics;/secti on屬性 IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;重定

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

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

9、值）。當(dāng)然，這個(gè)地址也不是現(xiàn) 成的，你要用符號(hào)的相對(duì)地址+它所在段的相對(duì)地址來得到它的絕對(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ī)器字長(zhǎng)十8公式：當(dāng)前地址=定位偏移+當(dāng)前段偏移+機(jī)器字長(zhǎng)十8有了當(dāng)前地址，相對(duì)地址就好計(jì)算了。 只要用符號(hào)的絕對(duì)地址減去當(dāng)前地址就可以了。公式：相

10、對(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 un sig ned long ulAddrORSymbol; /代碼地址或符號(hào)索引un sig ned short usLi neNo; /行號(hào) LINENO;讓我們

11、先看第二個(gè)成員，usL in eNo 。這是一個(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)表中的索引。下面讓我們來看看符號(hào)表吧！符號(hào)表符號(hào)表是對(duì)象文件中用來保存符號(hào)信息的一張表，也是COFF文件中最為復(fù)雜的一張表。所有段落使用到的符號(hào)都在這個(gè)表里。 typedef struct union char cName8; /struct un sig ned long ulZero; /un sig ned long ulOffset; / e; e;un sig ned lon

12、g ulValue; /short iSecti on; /un sig ned short usType; /un sig ned char usClass; /un sig ned char usNumAux; / SYMENT;它也是由很多條記錄組成， 每條記錄都以如下結(jié)構(gòu)保存:符號(hào)名稱字符串表標(biāo)識(shí)字符串偏移符號(hào)值符號(hào)所在段符號(hào)類型 符號(hào)存儲(chǔ)類型 符號(hào)附加記錄數(shù)cName符號(hào)名稱，和前面所有的名稱一樣，它也是 8個(gè)字節(jié)，但不同的是它在一個(gè)聯(lián)合體 中。和它占相同的存儲(chǔ)空間的還有 ulZero 和ulOffset 這兩個(gè)成員。如果符號(hào)的名稱只有8個(gè)字符，那很好，可以直接放到這個(gè) cName中

13、；可是，如果名稱的長(zhǎng)度大于 8個(gè)字節(jié)， 這里就放不下了，只好放到字符串表中。這時(shí)候，ulZero 的值就會(huì)為0 ,而在ulOffset中會(huì)給出我們所用的符號(hào)的名稱在字符串表中的偏移。一個(gè)符號(hào)有了名稱不夠，它還要有值！ulValue 就是這個(gè)符號(hào)所代表的值。iSection成員指出了這個(gè)符號(hào)所在的段落。如果它的值為0 ,那么這個(gè)符號(hào)就是一個(gè)外部符號(hào)，要從其它的 COFF文件中解析（連接多個(gè)目標(biāo)文件就是要解析這種符號(hào)）。當(dāng)它的值 為-1時(shí)，說明這個(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)所在段的索引值。u

14、sType是符號(hào)的類型標(biāo)識(shí)。它用來說明這個(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），無類型（0000b）等?，F(xiàn)在的編譯器，通常不使用基本類型， 只使用高級(jí)類型。 所以，符號(hào)的基本類型通常被設(shè)為0。高字節(jié)通常未用。usClass 是符號(hào)的存儲(chǔ)類型標(biāo)識(shí)。它指明了符號(hào)的存儲(chǔ)方式。其值與意義見下表：值名稱 說明NULL 0 無存儲(chǔ)類型。AUTOMATIC 1 自動(dòng)類型。通常是在棧中分配的變量。EXTERNAL

15、 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 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文件名。最后

16、一個(gè)成員usNumAux是附加記錄的數(shù)量。附加記錄是用來描述符號(hào)的一些附加信息，為了便于保存，這些附加記錄通常選擇成為一條符號(hào)信息記錄的整數(shù)倍（多數(shù)為1）。所以,如果這個(gè)成員的值為 1，那么就表示在當(dāng)前符號(hào)信息記錄后附加了一條記錄，用來保存附加信息。附加信息的結(jié)構(gòu)是與符號(hào)的類型以及存儲(chǔ)類型相關(guān)的。不同的類型的符號(hào)，其附加信息（如果有的話）的結(jié)構(gòu)也不同。如果你不在意這些內(nèi)容，也可以把它們乎略。當(dāng)段的類型為FILE時(shí)，附加信息就是一個(gè)字符串，它是目標(biāo)文件對(duì)應(yīng)源文件的名稱。其它 類型在介紹PE時(shí)再進(jìn)行詳細(xì)討論。字符串表不用多說，瞎子也能看出這個(gè)表是用來保存字符串的。它緊接在符號(hào)表后。 至于為什么要保存字符串，前面已經(jīng)說過了。這里就不再多說了，只說說字符串的保存格式。字符串表是所有節(jié)中最簡(jiǎn)單一節(jié)。如下圖：04字符串表長(zhǎng)度字符串10. 字符串n0字符串表的前四個(gè)字節(jié)是字符串表的長(zhǎng)度，以字節(jié)為單位。其后就是以0結(jié)尾的字符串（C風(fēng)格字符串）。要注意的是，字符串表的長(zhǎng)度不僅僅是字符串的長(zhǎng)度（這個(gè)長(zhǎng)度要包括每個(gè) 字