COFF格式介绍

wuye_chinaunix

COFF格式
         COFF – 通用对象文件格式（Common Object File Format），是一种很流行的对象文件格式（注意：这里不说它是“目标”文件，是为了和编译器产生的目标文件（*.o/*.obj）相区别，因为这种格式不只用于目标文件，库文件、可执行文件也经常是这种格式）。大家可能会经常使用VC吧？它所产生的目标文件（*.obj）就是这种格式。其它的编译器，如GCC（GNU Compiler Collection）、ICL（Intel C/C++ Compiler）、VectorC，也使用这种格式的目标文件。不仅仅是C/C++，很多其它语言也使用这种格式的对象文件。统一格式的目标文件为混合语言编程带来了极大的方便。
         当然，并不是只有这一种对象文件格式。常用格式的还有OMF-对象模型文件（Object Module File）以及ELF-可执行及连接文件格式（Executable and Linking Format）。OMF是一大群IT巨头在n年制定的一种格式，在Windows平台上很常见。大家喜欢的Borland公司现在使用的目标文件就是这种格式。MS和Intel在n年前用的也是这种格式，现在都改投异侧，用COFF格式了。ELF格式在非Windows平台上使用得比较多，在 Windows平台基本上没见过。做为程序员，很有必要认识一下这些你经常打交道的家伙！不过这次让我介绍COFF先！
        COFF的文件结构
         让我们先来看一下COFF文件的整体结构，看看它到底长得什么样！
         其中，除了段落头可以有多个节（因为可以有多个段落）以外，其它的所有类型的节最多只能有一个。
         文件头：顾名思义，它就是COFF文件的头，它用来保存COFF文件的基本信息，如文件标识，各个表的位置等等。
         可选头：再顾名思义，它也是一个头，还是可选的，而且可有可无。在目标文件中，基本上都没有这个头；但在其它的文件中（如：可执行文件）这个段用来保存在文件头中没有描述到的信息。
         段落头：又顾……（不顾了，再顾有人要打我了J），这个头（怎么这么多的头啊？！）是用来描述段落信息的，每个段落都有一个段落头来描述。段落的数目在文件头中会指出。
         段落数据：这通常是COFF文件中最大的数据段，每个段落真正的数据就保存在这个位置。至于怎么区分这些数据是哪个段落的，不要问我，去问段落头。
         重定位表：这个表通常只存在于目标文件中，它用来描述COFF文件中符号的重定位信息。至于为什么要重定位，请回家看看你的操作系统的书籍。
         符号表：这个表用来保存COFF文件中所用到的所有符号的信息，连接多个COFF文件时，这个表帮助我们重定位符号。调试程序时也要用到它。
         字符串表：不用我说，大家也知道它用来保存字符串的。可是字符串保存给谁看呢？不知道了吧！？问我啊！J符号表是以记录的形式来描述符号信息的，但它只为符号名称留置了8个字符的空间，早期的小程序还将就能行，可在现在的程序中，一个符号名动不动就数十个字符，8个字符怎么能够？没办法，只好把这些名称存在字符串表中。而符号表中只记录这些字符串的位置。
         文件的结构大体上就是这样了。长得是丑了点，不过还算它的设计者有点远见。可扩充性设计得不错，以致于沿用至今。了解了文件的整体结构，现在让我们来逐个段落分析它。
        文件头
         文件头，自然是从文件的0偏移处开始，它的结构很简单。用C的结构描述如下：
    typedef struct {
    unsigned short usMagic;   // 魔法数字
    unsigned short usNumSec;   // 段落（Section）数
    unsigned long ulTime;   // 时间戳
    unsigned long ulSymbolOffset;   // 符号表偏移
    unsigned long ulNumSymbol;   // 符号数
    unsigned short usOptHdrSZ;   // 可选头长度
    unsigned short usFlags;   // 文件标记
    } FILEHDR;
         结构中usMagic成员是一个魔法数字（Magic Number），在I386平台上的COFF文件中它的值为0x014c。如果COFF文件头中魔法数字不为0x014c，那就不用看了，这不是一个 I386平台的COFF文件。其实这就是一个平台标识。
         第二个成员usNumSec是一个无符号短整型，它用来描述段落的数量。段落头（Section Header）的数目就是它。
         ulTime成员是一个时间戳，它用来描述COFF文件的建立时间。当COFF文件为一个可执行文件时，这个时间戳经常用来当做一个加密用的比对标识。
         ulSymbolOffset是符号表在文件中的偏移量，这是一个绝对偏移量，要从文件头开始计数。在COFF文件的其它节中，也存在这种偏移量，它们都是绝对偏移量。
         ulNumSymbol成员给出了符号表中符号记录的数量。
         usOptHdrSZ是可选头的长度，通常它为0。而可选头的类型也是从这个长度得知的，针对不同的长度，我们就要选择不同的处理方式。
         usFlag是COFF文件的属性标记，它标识了COFF文件的类型，COFF文件中所保存的数据等等信息。
         其值如下：
    File Header
    Optional Header
    Section Header 1
    ......
    Section Header n
    Section Data
    Relocation Directives
    Line Numbers
    Symbol Table
    String Table
        如左图：
    COFF文件一共有8种数据，自上而下分别为：
    1. 文件头（File Header）
    2. 可选头（Optional Header）
    3. 段落头（Section Header）
    4. 段落数据（Section Data）
    5. 重定位表（Relocation Directives）
    6. 行号表（Line Numbers）
    7. 符号表（Symbol Table）
    8. 字符串表（String Table）
    值     名称     说明
    0x0001     F_RELFLG     无重定位信息标记。这个标记指出COFF文件中没有重定位信息。通常在目标文件中这个标记们为0，在可执行文件中为1。
    0x0002     F_EXEC     可执行标记。这个标记指出 COFF 文件中所有符号已经解析， COFF 文件应该被认为是可执行文件。
    0x0004     F_LNNO     文件中所有行号已经被去掉。
    0x0008     F_LSYMS     文件中的符号信息已经被去掉。
    0x0100     F_AR32WR     些标记指出文件是 32 位的 Little-Endian COFF 文件。
         注：Little-Endian，记不得它的中文名称了。它是指数据的排列方式。比如：十六进制的0x1234以Little-Endian方式在内存中的顺序为0x34 0x12。与之相反的是Big-Endian，这种方式下，在内存中的顺序是0x12 0x34。
    这个表的内容并不全面，但在目标文件中，常用的也就只有这些。其它的标记我将在以后介绍PE格式时给出。
    可选头
         可选头接在文件头的后面，也就是从COFF文件的0x0014偏移处开始。长度可以为0。不同长度的可选头，其结构也不同。标准的可选头长度为24或28 字节，通常是28啦。这里我就只介绍长度为28的可选头。（因为这种头的长度是自定义的，不同的人定义的结果就不一样，我只能选一种最常用的头来介绍，别的我也不知道）
    这种头的结构如下：
    typedef struct {
    unsigned short usMagic;   // 魔法数字
    unsigned short usVersion;   // 版本标识
    unsigned long ulTextSize;   // 正文（text）段大小
    unsigned long ulInitDataSZ;   // 已初始化数据段大小
    unsigned long ulUninitDataSZ;   // 未初始化数据段大小
    unsigned long ulEntry;   // 入口点
    unsigned long ulTextBase;   // 正文段基址
    unsigned long ulDataBase;   // 数据段基址（在PE32中才有）
    } OPTHDR;
         第一个成员usMagic还是魔法数字，不过这回它的值应该为0x010b或0x0107。当值为0x010b时，说明COFF文件是一个一般的可执行文件；当值为，0x0107时，COFF则为一个ROM镜像文件。
         usVersion是COFF文件的版本，ulTextSize是这个可执行COFF的正文段长度，ulInitDataSZ和ulUninitDataSZ分别为已初始化数据段和未初始化数据段的长度。
         ulEntry是程序的入口点，也就是COFF载入内存时正文段的位置（EIP寄存器的值），当COFF文件是一个动态库时，入口点也就是动态库的入口函数。
         ulTextBase是正文段的基址。
         ulDataBase是数据段基址。
         其实在这些成员中，只要注意usMagic和ulEntry就可以了。
        段落头
         段落头紧跟在可选头的后面（如果可选头的长度为0，那么它就是紧跟在文件头后）。它的长度为36个字节，如下：
    typedef struct {
    char           cName[8];   // 段名
    unsigned long ulVSize;   // 虚拟大小
    unsigned long ulVAddr;   // 虚拟地址
    unsigned long ulSize;   // 段长度
    unsigned long ulSecOffset;   // 段数据偏移
    unsigned long ulRelOffset;   // 段重定位表偏移
    unsigned long ulLNOffset;   // 行号表偏移
    unsigned short ulNumRel;   // 重定位表长度
    unsigned short ulNumLN;   // 行号表长度
    unsigned long ulFlags;   // 段标识
    } SECHDR;
         这个头可是个重要的头头，我们要用到的最终信息就由它来描述。一个COFF文件可以不要其它的节，但文件头和段落头这两节是必不可少的。
         cName用来保存段名，常用的段名有.text，.data，.comment，.bss等。.text段是正文段，通常也就是代码段；.data是数据段，在这个数据段中所保存的数据是初始化过的数据；.bss段也可以用来保存数据，不过这里的数据是未初始化的，这个段也是一个空段；.comment 段，看名字也知道，它是注释段，用来保存一些编译信息，算是对COFF文件的注释。
         ulVSize是段数据载入内存时的大小。只在可执行文件中有效，在目标文件中总为0。如果它的长度大于段的实际长度，则多的部分将用0来填充。
         ulVAddr是段数据载入或连接时的虚拟地址。对于可执行文件来说，这个地址是相对于它的地址空间而言。当可执行文件被载入内存时，这个地址就是段中数据的第一个字节的位置。而对于目标文件而言，这只是重定位时，段数据当前位置的一个偏移量。为了计算方便，便定位的计算简化，它通常设为0。
         ulSize这才是段中数据的实际长度，也就是段数据的长度，在读取段数据时就由它来确定要读多少字节。
         ulSecOffset是段数据在COFF文件中的偏移量。
         ulRelOffset是该段的重定位信息的偏移量。它指向了重定位表的一个记录。
         ulLNOffset是该段的行号表的偏移量。它指向的是行号表中的一个记录。
         ulNumRel是重定位信息的记录数。从ulRelOffset指向的记录开始，到第ulNumRel个记录为止，都是该段的重定位信息。
         ulNumLN和ulNumRel相似。不过它是行号信息的记录数。
         ulFlags是该段的属性标识。其值如下表：
    值     名称     说明
    0x0020     STYP_TEXT     正文段标识，说明该段是代码。
    0x0040     STYP_DATA     数据段标识，有些标识的段将用来保存已初始化数据。
    0x0080     STYP_BSS     有这个标识段也是用来保存数据，不过这里的数据是未初始化数据。
         注意，在BSS段中，ulVSize、ulVAddr、ulSize、ulSecOffset、ulRelOffset、ulLNOffset、 ulNumRel、ulNumLN的值都为0。（上表只是部分值，其它值在PE格式中介绍，后同）
        段数据
         “人”如其名，这里是保存各个段的数据的位置。不同类型的段，数据的内容、结构也不尽相同。但在目标文件中，这些数据都是原始数据（Raw Data）。不存在什么特别的格式。
        重定位表
         这个表所保存的是各个段的重定位信息。这是一张很大的表，因为所有段的重定位信息都在这个表里。各个段落头记录了自己的重定位信息的偏移和数量。要用到重定位信息时就到这个表里来读。当然，你也可以把整个重定位表看成多个重定位表，每个段落都有一个自己的重定位表。这个表只在目标文件中有，可执行文件中是不存在这个表的。
         既然有表，那么就会有记录。重定位表中的每一条记录就是一条重定位信息。这个记录的结构很简单，如下：
    typedef struct {
    unsigned long ulAddr;   // 定位偏移
    unsigned long ulSymbol;   // 符号
    unsigned short usType;   // 定位类型
    } RELOC;
         有够简单吧，一共只三个成员！ulAddr是要定位的内容在段内偏移。比如：一个正文段，起始位置为0x010，ulAddr的值为0x05，那你的定位信息就要写在0x15处。而且信息的长度要看你的代码的类型，32位的代码要写4个字节，16位的就只要字2个字节。
         ulSymbol是符号索引，它指向符号表中的一个记录。注意，这里是索引，不是偏移！它只是符号表中的一个记录的记录号。这个成员指明了重定位信息所对映的符号。
    usType是重定位类型的标识。32位代码中，通常只用两种定位方式。一是绝对定位，二是相对定位。其代码如下：
    值     名称     说明
    6     RELOC_ADDR32     32位绝对定位。
    20     RELOC_REL32     32位相对定位。
         对于不同的处理器，这些值也不尽相同。这里给出的是i386平台上最常用的两个种定位方式的标识。
         其定位方式如下：
        绝对定位
         在绝对定位方式下，你要给出符号的绝对地址（注意，有时候这里可能不是地址，而是值，对于常量来说，你不用给出它的地值，只用给出它的值）。当然，这个地址也不是现成的，你要用符号的相对地址＋它所在段的相对地址来得到它的绝对地址。
        公式：符号绝对地址＝段偏移＋符号偏移
         这些偏移量你要分别从段落头和符号表中得到。当段落要重定位时，当然还要先重定位段落，才能定位其中的符号。
        相对定位
         相对定位要复杂一些。它所要的地址信息是相对于当前位置的偏移，这个当前位置就是ulAddr所指向的这个偏移的绝对地址后四个字节（32位代码是四个字节，16位是两个字节）的位置。也就是用定位偏移＋当前段偏移＋机器字长÷8
        公式：当前地址＝定位偏移＋当前段偏移＋机器字长÷8
         有了当前地址，相对地址就好计算了。只要用符号的绝对地址减去当前地址就可以了。
        公式：相对地址＝符号绝对地址-当前地址
         计算好了地址，把它写到ulAddr所指向的位置，就一切OK！你已经完成了重定位的工作了。
        行号表
         行号表在调试时很有用。它把可执行的二进制代码与源代码的行号之间建立了对映关系。这样，当程序执行不正确时（其实正确的也可以J），我们就可以根据当前执行代码的位置得知出错源代码的行号，再加以修改。如果没有它的话，鬼才知道是哪一行出了毛病！
         它的格式也很简单。只有两个成员，如下：
    typedef struct {
         unsigned long ulAddrORSymbol;   // 代码地址或符号索引
         unsigned short usLineNo;   // 行号
    } LINENO;
         让我们先看第二个成员，usLineNo。这是一个从1开始计数的计数器，它代表源代码的行号。第一个成员ulAddrORSymbol在行号大于0时，代表源代码的地址；而当行号为0时，它就成了行号所对映的符号在符号表中的索引。下面让我们来看看符号表吧！
        符号表
         符号表是对象文件中用来保存符号信息的一张表，也是COFF文件中最为复杂的一张表。所有段落使用到的符号都在这个表里。它也是由很多条记录组成，每条记录都以如下结构保存：
    typedef struct {
    union {
        char cName[8];             // 符号名称
        struct {
          unsigned long ulZero;    // 字符串表标识
          unsigned long ulOffset; // 字符串偏移
        } e;
    } e;
    unsigned long ulValue;     // 符号值
    short iSection;             // 符号所在段
    unsigned short usType;    // 符号类型
    unsigned char usClass;      // 符号存储类型
    unsigned char usNumAux;    // 符号附加记录数
    } SYMENT;
         cName符号名称，和前面所有的名称一样，它也是8个字节，但不同的是它在一个联合体中。和它占相同的存储空间的还有ulZero和ulOffset这两个成员。如果符号的名称只有8个字符，那很好，可以直接放到这个cName中；可是，如果名称的长度大于8个字节，这里就放不下了，只好放到字符串表中。这时候，ulZero的值就会为0，而在ulOffset中会给出我们所用的符号的名称在字符串表中的偏移。
         一个符号有了名称不够，它还要有值！ulValue就是这个符号所代表的值。
         iSection成员指出了这个符号所在的段落。如果它的值为0，那么这个符号就是一个外部符号，要从其它的COFF文件中解析（连接多个目标文件就是要解析这种符号）。当它的值为-1时，说明这个符号的值是一个常量，不是它在段落中的偏移。而当它的值为-2时，这个符号只是一个调试符号，只有在调试时才会用到它。当它大于0时，才是符号所在段的索引值。
         usType是符号的类型标识。它用来说明这个符号的类型，是函数？整型？还是其它什么。这个标识是两个字节。
         低字节的低四位是基本标识，它指出了符号的基本类型，如整型，字符，结构，联合等。高四位指出了符号的高级类型，如指针（0001b），函数（0010b），数组（0011b），无类型（0000b）等。现在的编译器，通常不使用基本类型，只使用高级类型。所以，符号的基本类型通常被设为0。
    高字节通常未用。
         usClass是符号的存储类型标识。它指明了符号的存储方式。
         其值与意义见下表：
    值     名称     说明
    NULL     0     无存储类型。
    AUTOMATIC     1     自动类型。通常是在栈中分配的变量。
    EXTERNAL     2     外部符号。当为外部符号时，iSection的值应该为0，如果不为0，则ulValue为符号在段中的偏移。
    STATIC     3     静态类型。ulValue为符号在段中的偏移。如果偏移为0，那么这个符号代表段名。
    REGISTER     4     寄存器变量。
    MEMBER_OF_STRUCT     8     结构成员。ulValue值为该符号在结构中的顺序。
    STRUCT_TAG     10     结构标识符。
    MEMBER_OF_UNION     11     联合成员。ulValue值为该符号在联合中的顺序。
    UNION_TAG     12     联合标识符。
    TYPE_DEFINITION     13     类型定义。
    FUNCTION     101     函数名。
    FILE     102     文件名。
         最后一个成员usNumAux是附加记录的数量。附加记录是用来描述符号的一些附加信息，为了便于保存，这些附加记录通常选择成为一条符号信息记录的整数倍（多数为1）。所以，如果这个成员的值为1，那么就表示在当前符号信息记录后附加了一条记录，用来保存附加信息。
         附加信息的结构是与符号的类型以及存储类型相关的。不同的类型的符号，其附加信息（如果有的话）的结构也不同。如果你不在意这些内容，也可以把它们乎略。
          当段的类型为FILE时，附加信息就是一个字符串，它是目标文件对应源文件的名称。其它类型在介绍PE时再进行详细讨论。
        字符串表
         不用多说，瞎子也能看出这个表是用来保存字符串的。它紧接在符号表后。至于为什么要保存字符串，前面已经说过了。这里就不再多说了，只说说字符串的保存格式。
          字符串表是所有节中最简单一节。如下图：
    0                              4                        
    字符串表长度     字符串1\0
    ....     字符串n\0
         字符串表的前四个字节是字符串表的长度，以字节为单位。其后就是以0结尾的字符串（C风格字符串）。要注意的是，字符串表的长度不仅仅是字符串的长度（这个长度要包括每个字符串后的‘\0’）的总合，它还包括这个长度域的四个字节。符号表中ulOffset成员所指出的偏移就是从字符串表起始处的偏移。比如：指像每一个字符串的符号，ulOffset的值总为4。
         下面给出的代码，是从字符串表中读取字符串的典型C代码。
    int iStrlen,iCur=4;                 // iStrLen是字符串表的长度，iCur是当前字符串偏移
    char *str;                           // 字符串表
    read(fn, &iStrlen, 4);               // 得到字符串表长度
    str = (char *)malloc(iStrlen);       // 为字符串表分配空间
    while (iCur<iStrlen )                // 读字符串表，直到全部读入内存
         iCur+=read(fn, str+iCur, iStrlen- iCur);
    iCur=4;                              // 把当前字符串偏移指到每一个字符串
    while (iCur<iStrlen ) {              // 显示每一个字符串
         printf("String offset 0x%04X : %s\n", iCur, str + iCur);
         iCur+=(strlen(str+iCur)+1);    // 计算偏移时不要忘了计算‘\0’字符所占的1个字节！
    }
    free(str);                           // 释放字符串表空间
         直到这里，整个COFF的结构已经全部介绍完了。很多了解PE格式的朋友一定会奇怪，好像少了很多内容！？是的，标准的COFF文件只有这么多的东西。但 MS为了和DOS的可执行文件兼容，以及对可执行文件功能的扩展，在COFF格式中加了很多它自己的标准。让我差点就认不出COFF了。但了解了COFF 文件以后，再来学习PE文件的格式，那就很简单了。
         想了解PE文件的格式？网上有很多它的资料，我将在本文的基础上再写几篇文章，分别介绍PE，OMF以及ELF的格式。
         现在大家可以自己动手，写一个COFF文件解析器或是一个简单的连接程序了！
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/17474/showart_1316751.html