PE文件结构-(转贴)-收藏

PE文件结构(转贴)收藏PE文件结构PE文件格式被组织为一个线性的数据流，它由一个MS-DOS头部开始，接着是一个是模式的程序残余以及一个PE文件标志，这之后紧接着PE文件头和可选头部。这些之后是所有的段头部，段头部之后跟随着所有的段实体。文件的结束处是一些其它的区域，其中是一些混杂的信息，包括重分配信息、符号表信息、行号信息以及字串表数据。从MS-DOS文件头结构开始，我将按照PE文件格式各成分的出现顺序依次对其进行讨论，并且讨论的大部分是以示例代码为基础来示范如何获得文件的信息的。所有的源码均摘自PEFILE.DLL模块的PEFILE.C文件。这些示例都利用了WindowsNT最酷的特色之一——内存映射文件，这一特色允许用户使用一个简单的指针来存取文件中所包含的数据，因此所有的示例都使用了内存映射文件来存取PE文件中的数据。注意：请查阅本文末尾关于如何使用PEFILE.DLL的那一段。MS-DOS头部/实模式头部如上所述，PE文件格式的第一个组成部分是MS-DOS头部。在PE文件格式中，它并非一个新概念，因为它与MS-DOS2.0以来就已有的MS-DOS头部是完全一样的。保留这个相同结构的最主要原因是，当你尝试在Windows3.1以下或MS-DOS2.0以上的系统下装载一个文件的时候，操作系统能够读取这个文件并明白它是和当前系统不相兼容的。换句话说，当你在MS-DOS6.0下运行一个WindowsNT可执行文件时，你会得到这样一条消息：“ThisprogramcannotberuninDOSmode.”如果MS-DOS头部不是作为PE文件格式的第一部分的话，操作系统装载文件的时候就会失败，并提供一些完全没用的信息，例如：“Thenamespecifiedisnotrecognizedasaninternalorexternalcommand,operableprogramorbatchfile.”MS-DOS头部占据了PE文件的头64个字节，描述它内容的结构如下：//WINNT.Htypedefstruct_IMAGE_DOS_HEADER{//DOS的.EXE头部USHORTe_magic;//魔术数字USHORTe_cblp;//文件最后页的字节数USHORTe_cp;//文件页数USHORTe_crlc;//重定义元素个数USHORTe_cparhdr;//头部尺寸，以段落为单位USHORTe_minalloc;//所需的最小附加段USHORTe_maxalloc;//所需的最大附加段USHORTe_ss;//初始的SS值（相对偏移量）USHORTe_sp;//初始的SP值USHORTe_csum;//校验和USHORTe_ip;//初始的IP值USHORTe_cs;//初始的CS值（相对偏移量）USHORTe_lfarlc;//重分配表文件地址USHORTe_ovno;//覆盖号USHORTe_res[4];//保留字USHORTe_oemid;//OEM标识符（相对e_oeminfo）USHORTe_oeminfo;//OEM信息USHORTe_res2[10];//保留字LONGe_lfanew;//新exe头部的文件地址}IMAGE_DOS_HEADER,*PIMAGE_DOS_HEADER;第一个域e_magic，被称为魔术数字，它被用于表示一个MS-DOS兼容的文件类型。所有MS-DOS兼容的可执行文件都将这个值设为0x5A4D，表示ASCII字符MZ。MS-DOS头部之所以有的时候被称为MZ头部，就是这个缘故。还有许多其它的域对于MS-DOS操作系统来说都有用，但是对于WindowsNT来说，这个结构中只有一个有用的域——最后一个域e_lfnew，一个4字节的文件偏移量，PE文件头部就是由它定位的。对于WindowsNT的PE文件来说，PE文件头部是紧跟在MS-DOS头部和实模式程序残余之后的。实模式残余程序实模式残余程序是一个在装载时能够被MS-DOS运行的实际程序。对于一个MS-DOS的可执行映像文件，应用程序就是从这里执行的。对于Windows、OS/2、WindowsNT这些操作系统来说，MS-DOS残余程序就代替了主程序的位置被放在这里。这种残余程序通常什么也不做，而只是输出一行文本，例如：“ThisprogramrequiresMicrosoftWindowsv3.1orgreater.”当然，用户可以在此放入任何的残余程序，这就意味着你可能经常看到像这样的东西：“Youcan''trunaWindowsNTapplicationonOS/2,it''ssimplynotpossible.”当为Windows3.1构建一个应用程序的时候，链接器将向你的可执行文件中链接一个名为WINSTUB.EXE的默认残余程序。你可以用一个基于MS-DOS的有效程序取代WINSTUB，并且用STUB模块定义语句指示链接器，这样就能够取代链接器的默认行为。为WindowsNT开发的应用程序可以通过使用-STUB:链接器选项来实现。PE文件头部与标志PE文件头部是由MS-DOS头部的e_lfanew域定位的，这个域只是给出了文件的偏移量，所以要确定PE头部的实际内存映射地址，就需要添加文件的内存映射基地址。例如，以下的宏是包含在PEFILE.H源文件之中的：//PEFILE.H#defineNTSIGNATURE(a)((LPVOID)((BYTE*)a+\((PIMAGE_DOS_HEADER)a)-e_lfanew))在处理PE文件信息的时候，我发现文件之中有些位置需要经常查阅。既然这些位置仅仅是对文件的偏移量，那么用宏来实现这些定位就比较容易，因为它们较之函数有更好的表现。请注意这个宏所获得的是PE文件标志，而并非PE文件头部的偏移量。那是由于自Windows与OS/2的可执行文件开始，.EXE文件都被赋予了目标操作系统的标志。对于WindowsNT的PE文件格式而言，这一标志在PE文件头部结构之前。在Windows和OS/2的某些版本中，这一标志是文件头的第一个字。同样，对于PE文件格式，WindowsNT使用了一个DWORD值。以上的宏返回了文件标志的偏移量，而不管它是哪种类型的可执行文件。所以，文件头部是在DWORD标志之后，还是在WORD标志处，是由这个标志是否WindowsNT文件标志所决定的。要解决这个问题，我编写了ImageFileType函数（如下），它返回了映像文件的类型：//PEFILE.CDWORDWINAPIImageFileType(LPVOIDlpFile){/*首先出现的是DOS文件标志*/if(*(USHORT*)lpFile==IMAGE_DOS_SIGNATURE){/*由DOS头部决定PE文件头部的位置*/if(LOWORD(*(DWORD*)NTSIGNATURE(lpFile))==IMAGE_OS2_SIGNATURE||LOWORD(*(DWORD*)NTSIGNATURE(lpFile))==IMAGE_OS2_SIGNATURE_LE)return(DWORD)LOWORD(*(DWORD*)NTSIGNATURE(lpFile));elseif(*(DWORD*)NTSIGNATURE(lpFile)==IMAGE_NT_SIGNATURE)returnIMAGE_NT_SIGNATURE;elsereturnIMAGE_DOS_SIGNATURE;}else/*不明文件种类*/return0;}以上列出的代码立即告诉了你NTSIGNATURE宏有多么有用。对于比较不同文件类型并且返回一个适当的文件种类来说，这个宏就会使这两件事变得非常简单。WINNT.H之中定义的四种不同文件类型有：//WINNT.H#defineIMAGE_DOS_SIGNATURE0x5A4D//MZ#defineIMAGE_OS2_SIGNATURE0x454E//NE#defineIMAGE_OS2_SIGNATURE_LE0x454C//LE#defineIMAGE_NT_SIGNATURE0x00004550//PE00首先，Windows的可执行文件类型没有出现在这一列表中，这一点看起来很奇怪。但是，在稍微研究一下之后，就能得到原因了：除了操作系统版本规范的不同之外，Windows的可执行文件和OS/2的可执行文件实在没有什么区别。这两个操作系统拥有相同的可执行文件结构。现在把我们的注意力转向WindowsNTPE文件格式，我们会发现只要我们得到了文件标志的位置，PE文件之后就会有4个字节相跟随。下一个宏标识了PE文件的头部：//PEFILE.C#definePEFHDROFFSET(a)((LPVOID)((BYTE*)a+\((PIMAGE_DOS_HEADER)a)-e_lfanew+\SIZE_OF_NT_SIGNATURE))这个宏与上一个宏的唯一不同是这个宏加入了一个常量SIZE_OF_NT_SIGNATURE。不幸的是，这个常量并未定义在WINNT.H之中，于是我将它定义在了PEFILE.H中，它是一个DWORD的大小。既然我们知道了PE文件头的位置，那么就可以检查头部的数据了。我们只需要把这个位置赋值给一个结构，如下：PIMAGE_FILE_HEADERpfh;pfh=(PIMAGE_FILE_HEADER)PEFHDROFFSET(lpFile);在这个例子中，lpFile表示一个指向可执行文件内存映像基地址的指针，这就显出了内存映射文件的好处：不需要执行文件的I/O，只需使用指针pfh就能存取文件中的信息。PE文件头结构被定义为：//WINNT.Htypedefstruct_IMAGE_FILE_HEADER{USHORTMachine;USHORTNumberOfSections;ULONGTimeDateStamp;ULONGPointerToSymbolTable;ULONGNumberOfSymbols;USHORTSizeOfOptionalHeader;USHORTCharacteristics;}IMAGE_FILE_HEADER,*PIMAGE_FILE_HEADER;#defineIMAGE_SIZEOF_FILE_HEADER20请注意这个文件头部的大小已经定义在这个包含文件之中了，这样一来，想要得到这个结构的大小就很方便了。但是我觉得对结构本身使用sizeof运算符（译注：原文为“function”）更简单一些，因为这样的话我就不必记住这个常量的名字IMAGE_SIZEOF_FILE_HEADER，而只需要记住结构IMAGE_FILE_HEADER的名字就可以了。另一方面，记住所有结构的名字已经够有挑战性的了，尤其在是这些结构只有WINNT.H中才有的情况下。PE文件中的信息基本上是一些高级信息，这些信息是被操作系统或者应用程序用来决定如何处理这个文件的。第一个域是用来表示这个可执行文件被构建的目标机器种类，例如DEC(R)Alpha、MIPSR4000、Intel(R)x86或一些其它处理器。系统使用这一信息来在读取这个文件的其它数据之前决定如何处理它。Characteristics域表示了文件的一些特征。比如对于一个可执行文件而言，分离调试文件是如何操作的。调试器通常使用的方法是将调试信息从PE文件中分离，并保存到一个调试文件（.DBG）中。要这么做的话，调试器需要了解是否要在一个单独的文件中寻找调试信息，以及这个文件是否已经将调试信息分离了。我们可以通过深入可执行文件并寻找调试信息的方法来完成这一工作。要使调试器不在文件中查找的话，就需要用到IMAGE_FILE_DEBUG_STRIPPED这个特征，它表示文件的调试信息是否已经被分离了。这样一来，调试器可以通过快速查看PE文件的头部的方法来决定文件中是否存在着调试信息。WINNT.H定义了若干其它表示文件头信息的标记，就和以上的例子差不多。我把研究这