兼容内核漫谈 适合想将Windows上的程序移植到其它平台上的朋友研究查看

漫谈兼容内核之六:二进制映像的类型识别

[b][size=4][align=center]漫谈兼容内核之六:二进制映像的类型识别[/align][/size][/b]
[align=center][i]毛德操[/i][/align]

    除了某些嵌入式系统之外，一般而言操作系统都有个在创建(或转化成)新进程时如何装入目标程序的二进制映像并启动其运行的问题。由于在计算机技术的发展历史中并没有形成某种单一的、为所有操作系统和编译/连接工具所共同遵循的标准，这个装入/启动的过程就不可避免地呈现出多样性。而且，即使是同一种操作系统，也会在其发展的过程中采用多种不同的目标映像格式和装入机理。而动态连接库技术的出现，则又使这个过程进一步地复杂化了，因为此时需要装入的不仅是目标程序的映像，还有动态连接库的映像，并且还要解决目标程序与具体库函数的动态连接问题。至于这个过程的重要性，那是不言而喻的，要不然操作系统就要么实际上不能做“有用功”，要么失去了通用性和灵活性。
    以Linux应用软件为例，就既有a.out格式，又有ELF格式，又支持动态连接库。我在“情景分析”一书中只讲了a.out映像的装入和启动，是因为a.out相对比较简单，否则篇幅太大。读者也许会问，既然有了更复杂、功能更强的ELF格式，为什么还要保留a.out格式呢？这当然是为了向后兼容，一种技术一旦被广泛采用以后就不会很快消失。与Linux相比，Windows采用的格式就更多了，因为它还需要支持DOS时代的应用软件。
    兼容内核既要支持Linux和Windows两种操作系统的应用软件，这个问题当然就更复杂、难度更大了。幸而Wine已经在我们之前以它的方式解决了这个问题，使我们至少有了可以借鉴的榜样。
    在讲述Wine的软件映像的装入/启动过程之前，我们先考察一下，为了兼容Windows软件，Wine需要支持那一些映像格式，以及如何识别一个映像所属的格式和类型。为此，我们看一下Wine的一段代码，这段代码在dlls/kernel/module.c中，是在用户空间执行的。
    这是一个名为MODULE_GetBinaryType()的函数，其作用是辨认一个已打开文件所属的映像格式并进而判定其类型，已定义的类型有：

[code]enum binary_type
{
    BINARY_UNKNOWN,
    BINARY_PE_EXE,
    BINARY_PE_DLL,
    BINARY_WIN16,
    BINARY_OS216,
    BINARY_DOS,
    BINARY_UNIX_EXE,
    BINARY_UNIX_LIB
};[/code]

    除BINARY_UNKNOWN表示无法辨认/判定以外，这里定义了7种映像类型。其中BINARY_PE_EXE和BINARY_PE_DLL是Windows的32位“PE格式”映像，前者为目标应用程序，后者为动态连接库DLL。注意前者是“有源”的主体，可以成为一个进程；而后者是“无源”的库程序，不能独立成为一个进程。BINARY_WIN16和BINARY_OS216则为16位Windows应用；后者实际上是OS/2操作系统的应用程序，但是因为微软和IBM曾经紧密合作，所以Windows也支持OS/2的应用程序。再往下BINARY_DOS显然是DOS的应用软件，但是DOS上的可执行程序有.exe和.com两种，这里并未加以区分，其原因留待以后再说。最后是BINARY_UNIX_EXE和BINARY_UNIX_LIB，Linux是Unix的继承者，所以也适用于Linux的应用程序和动态连接库。
    下面可以看代码了，我们分段阅读。

[code]enum binary_type
MODULE_GetBinaryType( HANDLE hfile,  void **res_start,  void **res_end )
{
    union
    {
        struct
        {
            unsigned char magic[4];
            unsigned char ignored[12];
            unsigned short type;
        } elf;
        struct
        {
            unsigned long magic;
            unsigned long cputype;
            unsigned long cpusubtype;
            unsigned long filetype;
        } macho;
        IMAGE_DOS_HEADER mz;
    } header;

    DWORD len;

    /* Seek to the start of the file and read the header information. */
    if (SetFilePointer( hfile, 0, NULL, SEEK_SET ) == -1)
        return BINARY_UNKNOWN;
    if (!ReadFile( hfile, &header, sizeof(header), &len, NULL ) || len != sizeof(header))
        return BINARY_UNKNOWN;[/code]

    无论是Linux还是Windows，在文件系统的目录项中都没有关于文件格式/类型的说明，所以只能采取在文件的实际内容前面加上头部的方法来表明。但是，不同可执行映像的头部结构和大小又各不相同。而且，头部还可能是级连或嵌套的，即先由一级的头部进行大的分类，然后再由二级的头部作进一步的细分。所以这里定义了一个包含几种一级头部结构的Union。其中的elf当然是Linux的ELF格式映像的头部(但是a.out格式不在内，所以也并不完整)；macho大约是针对MACH操作系统的，我们并不关心；而mz是DOS以及Windows格式的一级头部，这是个相对较大的数据结构：

[code]typedef struct _IMAGE_DOS_HEADER {
    WORD  e_magic;      /* 00: MZ Header signature */
    WORD  e_cblp;       /* 02: Bytes on last page of file */
    WORD  e_cp;         /* 04: Pages in file */
    WORD  e_crlc;       /* 06: Relocations */
    WORD  e_cparhdr;    /* 08: Size of header in paragraphs */
    WORD  e_minalloc;   /* 0a: Minimum extra paragraphs needed */
    WORD  e_maxalloc;   /* 0c: Maximum extra paragraphs needed */
    WORD  e_ss;         /* 0e: Initial (relative) SS value */
    WORD  e_sp;         /* 10: Initial SP value */
    WORD  e_csum;      /* 12: Checksum */
    WORD  e_ip;         /* 14: Initial IP value */
    WORD  e_cs;         /* 16: Initial (relative) CS value */
    WORD  e_lfarlc;       /* 18: File address of relocation table */
    WORD  e_ovno;       /* 1a: Overlay number */
    WORD  e_res[4];      /* 1c: Reserved words */
    WORD  e_oemid;      /* 24: OEM identifier (for e_oeminfo) */
    WORD  e_oeminfo;    /* 26: OEM information; e_oemid specific */
    WORD  e_res2[10];    /* 28: Reserved words */
    DWORD e_lfanew;     /* 3c: Offset to extended header */
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;[/code]

    这个数据结构提供了不少信息，都是与DOS环境下的目标映像装入/启动密切相关的。例如e_ss和e_sp就说明了堆栈的位置是预定的(而不是动态分配的)，而e_ss的使用又表明目标程序是在“实模式”下运行。如此等等，这里就不详说了。不过，当微软从DOS发展到Windows和WinNT时，仍旧套用了这个数据结构作为其应用程序目标映像的一级头部，而WinNT显然是在“保护模式”下运行。所以，这里的许多字段对于Windows目标映像实际上已经不再使用。
    代码中首先通过类似于lseek()的SetFilePointer()把目标文件的读/写指针移到文件的开头，再按上述Union的大小读出，这就可以把几种头部、特别是Linux和Windows目标映像的头部都包含在内了。
    下面就来辨认识别：

[code]    if (!memcmp( header.elf.magic, "\177ELF", 4 ))
    {
        /* FIXME: we don't bother to check byte order, architecture, etc. */
        switch(header.elf.type)
        {
        case 2: return BINARY_UNIX_EXE;
        case 3: return BINARY_UNIX_LIB;
        }
        return BINARY_UNKNOWN;
    }

    ......[/code]

    先看是否Linux的ELF格式。ELF头部的数据结构定义见上，其第一个字段是4字节的标识码magic，也称为“签名”。ELF格式签名的第一个字节是八进制的‘\177’，即十六进制的‘0x7f’，然后是‘E’、‘L’、‘F’三个字符。ELF头部的type字段则进一步表明映像的性质，目前只定义了两种类型，即BINARY_UNIX_EXE和BINARY_UNIX_LIB。
    我们跳过对macho头部的辨认，往下看DOS/Windows头部的辨认。DOS头部的签名定义于include/winnt.h：

[code]#define IMAGE_DOS_SIGNATURE   0x5A4D   /* MZ   */
#define IMAGE_OS2_SIGNATURE     0x454E   /* NE   */
#define IMAGE_OS2_SIGNATURE_LE  0x454C   /* LE   */
#define IMAGE_OS2_SIGNATURE_LX  0x584C   /* LX */
#define IMAGE_VXD_SIGNATURE   0x454C   /* LE   */
#define IMAGE_NT_SIGNATURE   . 0x00004550  /* PE00 */[/code]

    数值0x5A4D实际上是‘M’、‘Z’两个字符的代码，因为Intel的CPU芯片采用“Little Ending”，所以次序是反的。注意这里只有MZ用于一级头部，其余都用于二级头部。
继续往下看代码：

[code]    /* Not ELF, try DOS */

    if (header.mz.e_magic == IMAGE_DOS_SIGNATURE)
    {
        union
        {
            IMAGE_OS2_HEADER os2;
            IMAGE_NT_HEADERS nt;
        } ext_header;

        /* We do have a DOS image so we will now try to seek into
         * the file by the amount indicated by the field
         * "Offset to extended header" and read in the
         * "magic" field information at that location.
         * This will tell us if there is more header information
         * to read or not.
         */
        if (SetFilePointer( hfile, header.mz.e_lfanew, NULL, SEEK_SET ) == -1)
            return BINARY_DOS;
        if (!ReadFile( hfile, &ext_header, sizeof(ext_header), &len, NULL ) || len < 4)
            return BINARY_DOS;

        /* Reading the magic field succeeded so we will try to determine what type it is.*/
        if (!memcmp( &ext_header.nt.Signature, "PE\0\0", 4 ))
        {
            if (len >= sizeof(ext_header.nt.FileHeader))
            {
              if (len < sizeof(ext_header.nt))  /* clear remaining part of header if missing */
                    memset( (char *)&ext_header.nt + len, 0, sizeof(ext_header.nt) - len );
              if (res_start) *res_start = (void *)ext_header.nt.OptionalHeader.ImageBase;
              if (res_end) *res_end = (void *)(ext_header.nt.OptionalHeader.ImageBase +
                     ext_header.nt.OptionalHeader.SizeOfImage);
              if (ext_header.nt.FileHeader.Characteristics & IMAGE_FILE_DLL)
                     return BINARY_PE_DLL;
              return BINARY_PE_EXE;
            }
            return BINARY_DOS;
        }[/code]

    如果一级头部的签名是“MZ”，那就是DOS一族的目标映像了，Windows是从DOS发展过来的，所以目标映像同属DOS一族。进一步的细分要根据二级头部、或曰“扩充”头部才能辨认，所以这里又定义了一个Union，即ext_header。这一次的目的是要区分Windows和OS/2映像。我们在这里只关心Windows的目标映像，所以只看IMAGE_NT_HEADERS数据结构的定义：

[code]typedef struct _IMAGE_NT_HEADERS {
  DWORD       Signature;  /* "PE"\0\0 */ /* 0x00 */
  IMAGE_FILE_HEADER    FileHeader;  /* 0x04 */
  IMAGE_OPTIONAL_HEADER  OptionalHeader; /* 0x18 */
} IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS;[/code]

    这个“头部”里面又嵌套着两个头部，它们的数据结构定义都在winnt.h中，这里就不一一列举了。不过需要说明，对于可执行映像而言，IMAGE_OPTIONAL_HEADER可不是“可选”的，反倒是十分重要的，例如里面有个字段是AddressOfEntryPoint，还有BaseOfCode和BaseOfData；此外还有个可变大小的数组DataDirectory[ ]；其重要性由此可见一斑。