Windows PE文件格式详解Word文档下载推荐.docx
《Windows PE文件格式详解Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《Windows PE文件格式详解Word文档下载推荐.docx（34页珍藏版）》请在冰点文库上搜索。
PE文件格式被组织为一个线性的数据流，它由一个MS-DOS头部开始，接着是一个是模式的程序残余以及一个PE文件标志，这之后紧接着PE文件头和可选头部。
这些之后是所有的段头部，段头部之后跟随着所有的段实体。
文件的结束处是一些其它的区域，其中是一些混杂的信息，包括重分配信息、符号表信息、行号信息以及字串表数据。
我将所有这些成分列于图1。
图1.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.H
typedefstruct_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.C
DWORDWINAPIImageFileType（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;
else
returnIMAGE_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文件头结构被定义为：
typedefstruct_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定义了若干其它表示文件头信息的标记，就和以上的例子差不多。
我把研究这些标记的事情留给读者作为练习，由你们来看看它们是不是很有趣，这些标记位于WINNT.H中的IMAGE_FILE_HEADER结构之后。
PE文件头结构中另一个有用的入口是NumberOfSections域，它表示如果你要方便地提取文件信息的话，就需要了解多少个段——更明确一点来说，有多少个段头部和多少个段实体。
每一个段头部和段实体都在文件中连续地排列着，所以要决定段头部和段实体在哪里结束的话，段的数目是必需的。
以下的函数从PE文件头中提取了段的数目：
intWINAPINumOfSections（LPVOIDlpFile）
{
/*文件头部中所表示出的段数目*/
return（int）（（PIMAGE_FILE_HEADER）
PEFHDROFFSET（lpFile））->
NumberOfSections）;
如你所见，PEFHDROFFSET以及其它宏用起来非常方便。
PE可选头部
PE可执行文件中接下来的224个字节组成了PE可选头部。
虽然它的名字是“可选头部”，但是请确信：
这个头部并非“可选”，而是“必需”的。
OPTHDROFFSET宏可以获得指向可选头部的指针：
#defineOPTHDROFFSET（a）（（LPVOID）（（BYTE*）a+\
e_lfanew+\
SIZE_OF_NT_SIGNATURE+\
sizeof（IMAGE_FILE_HEADER）））
可选头部包含了很多关于可执行映像的重要信息，例如初始的堆栈大小、程序入口点的位置、首选基地址、操作系统版本、段对齐的信息等等。
IMAGE_OPTIONAL_HEADER结构如下：
typedefstruct_IMAGE_OPTIONAL_HEADER{
//
//标准域
USHORTMagic;
UCHARMajorLinkerVersion;
UCHARMinorLinkerVersion;
ULONGSizeOfCode;
ULONGSizeOfInitializedData;
ULONGSizeOfUninitializedData;
ULONGAddressOfEntryPoint;
ULONGBaseOfCode;
ULONGBaseOfData;
//NT附加域
ULONGImageBase;
ULONGSectionAlignment;
ULONGFileAlignment;
USHORTMajorOperatingSystemVersion;
USHORTMinorOperatingSystemVersion;
USHORTMajorImageVersion;
USHORTMinorImageVersion;
USHORTMajorSubsystemVersion;
USHORTMinorSubsystemVersion;
ULONGReserved1;
ULONGSizeOfImage;
ULONGSizeOfHeaders;
ULONGCheckSum;
USHORTSubsystem;
USHORTDllCharacteristics;
ULONGSizeOfStackReserve;
ULONGSizeOfStackCommit;
ULONGSizeOfHeapReserve;
ULONGSizeOfHeapCommit;
ULONGLoaderFlags;
ULONGNumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORYDataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
}IMAGE_OPTIONAL_HEADER,*PIMAGE_OPTIONAL_HEADER;
如你所见，这个结构中所列出的域实在是冗长得过分。
为了不让你对所有这些域感到厌烦，我会仅仅讨论有用的——就是说，对于探究PE文件格式而言有用的。
标准域
首先，请注意这个结构被划分为“标准域”和“NT附加域”。
所谓标准域，就是和UNIX可执行文件的COFF格式所公共的部分。
虽然标准域保留了COFF中定义的名字，但是WindowsNT仍然将它们用作了不同的目的——尽管换个名字更好一些。
·
Magic。
我不知道这个域是干什么的，对于示例程序EXEVIEW.EXE示例程序而言，这个值是0x010B或267（译注：
0x010B为.EXE，0x0107为ROM映像，这个信息我是从eXeScope上得来的）。
MajorLinkerVersion、MinorLinkerVersion。
表示链接此映像的链接器版本。
随WindowNTbuild438配套的WindowsNTSDK包含的链接器版本是2.39（十六进制为2.27）。
SizeOfCode。
可执行代码尺寸。
SizeOfInitializedData。
已初始化的数据尺寸。
SizeOfUninitializedData。
未初始化的数据尺寸。
AddressOfEntryPoint。
在标准域中，AddressOfEntryPoint域是对PE文件格式来说最为有趣的了。
这个域表示应用程序入口点的位置。
并且，对于系统黑客来说，这个位置就是导入地址表（IAT）的末尾。
以下的函数示范了如何从可选头部获得WindowsNT可执行映像的入口点。
LPVOIDWINAPIGetModuleEntryPoint（LPVOIDlpFile）
PIMAGE_OPTIONAL_HEADERpoh;
poh=（PIMAGE_OPTIONAL_HEADER）OPTHDROFFSET（lpFile）;
if（poh!
=NULL）
return（LPVOID）poh->
AddressOfEntryPoint;
else
returnNULL;
}
BaseOfCode。
已载入映像的代码（“.text”段）的相对偏移量。
BaseOfData。
已载入映像的未初始化数据（“.bss”段）的相对偏移量。
WindowsNT附加域
添加到WindowsNTPE文件格式中的附加域为WindowsNT特定的进程行为提供了装载器的支持，以下为这些域的概述。
ImageBase。
进程映像地址空间中的首选基地址。
WindowsNT的MicrosoftWin32SDK链接器将这个值默认设为0x00400000，但是你可以使用-BASE:
linker开关改变这个值。
SectionAlignment。
从ImageBase开始，每个段都被相继的装入进程的地址空间中。
SectionAlignment则规定了装载时段能够占据的最小空间数量——就是说，段是关于SectionAlignment对齐的。
WindowsNT虚拟内存管理器规定，段对齐不能少于页尺寸（当前的x86平台是4096字节），并且必
升级会员 