《PE文件格式详解》由会员分享，可在线阅读，更多相关《PE文件格式详解（28页珍藏版）》请在金锄头文库上搜索。
1、PE文件格式详解摘要Wi ndows NT 3. 1引入了一种名为P E文件格式的新可执行文件格式。P E文件格式的规范包含在了MS DN的C D中（S pec s a nd S t r a t e gy, S pec i f i c a t i ons, Wi ndows NT F i l e F orm a tS pec i f i c a t i ons），但是它非常之晦涩。然而这一的文档并未提供足够的信息，所以开发者们无法很好地弄懂P E格式。本文旨在解决这一问题，它会对整个的P E文件格式作一个十分彻底的解释，另外，本文中还带有对所有必需结构的描述以及示范如何使用这些信息的源码示例。
2、为了获得P E文件中所包含的重要信息，我编写了一个名为P E F I L E . DL L的动态链接库，本文中所有出现的源码示例亦均摘自于此。这个DL L和它的源代码都作为P E F i l e示例程序的一部分包含在了C D中（译注：示例程序请在MS DN中寻找，本站恕不提供），你可以在你自己的应用程序中使用这个DL L；同样，你亦可以依你所愿地使用并构建它的源码。在本文末尾，你会找到P E F I L E . DL L的函数导出列表和一个如何使用它们的说明。我觉得你会发现这些函数会让你从容应付P E文件格式的。介绍Wi ndows操作系统家族最近增加的Wi ndows NT为开发环境和应用程
3、序本身带来了很大的改变，这之中一个最为重大的当属P E文件格式了。新的P E文件格式主要来自于UNI X操作系统所通用的C OF F规范，同时为了保证与旧版本MS - DOS及Wi ndows操作系统的兼容，P E文件格式也保留了MS - DOS中那熟悉的MZ头部。在本文之中，P E文件格式是以自顶而下的顺序解释的。在你从头开始研究文件内容的过程之中，本文会详细讨论P E文件的每一个组成部分。许多单独的文件成分定义都来自于Mi c r osoft Wi n32 S DK开发包中的WI NNT . H文件，在这个文件中你会发现用来描述文件头部和数据目录等各种成分的结构类型定义。但是，在WI NN
4、T . H中缺少对P E文件结构足够的定义，在这种情况下，我定义了自己的结构来存取文件数据。你会在P E F I L E . DL L工程的P E F I L E . H中找到这些结构的定义，整套的P E F I L E . H开发文件包含在P E F i l e示例程序之中。本文配套的示例程序除了P E F I L E . DL L示例代码之外，还有一个单独的Wi n32示例应用程序，名为E XE VI E W. E XE。创建这一示例目的有二：首先，我需要测试P E F I L E . DL L的函数，并且某些情况要求我同时查看多个文件；其次，很多解决P E文件格式的工作和直接观看数据有关
5、。例如，要弄懂导入地址名称表是如何构成的，我就得同时查看. i dat a段头部、导入映像数据目录、可选头部以及当前的. i dat a段实体，而E XE VI E W. E XE就是查看这些信息的最佳示例。闲话少叙，让我们开始吧。PE文件结构P E文件格式被组织为一个线性的数据流，它由一个MS - DOS头部开始，接着是一个是模式的程序残余以及一个P E文件标志，这之后紧接着P E文件头和可选头部。这些之后是所有的段头部，段头部之后跟随着所有的段实体。文件的结束处是一些其它的区域，其中是一些混杂的信息，包括重分配信息、符号表信息、行号信息以及字串表数据。我将所有这些成分列于图1。图1.PE文
6、件映像结构从MS - DOS文件头结构开始，我将按照P E文件格式各成分的出现顺序依次对其进行讨论，并且讨论的大部分是以示例代码为基础来示范如何获得文件的信息的。所有的源码均摘自P E F I L E . DL L模块的P E F I L E . C文件。这些示例都利用了Wi ndows NT最酷的特色之一内存映射文件，这一特色允许用户使用一个简单的指针来存取文件中所包含的数据，因此所有的示例都使用了内存映射文件来存取P E文件中的数据。注意：请查阅本文末尾关于如何使用P E F I L E . DL L的那一段。MS - DO SO O O头部/实模式头部如上所述，P E文件格式的第一个组成
7、部分是MS - DOS头部。在P E文件格式中，它并非一个新概念，因为它与MS - DOS 2. 0以来就已有的MS - DOS头部是完全一样的。保留这个相同结构的最主要原因是，当你尝试在Wi ndows 3. 1以下或MS - DOS 2. 0以上的系统下装载一个文件的时候，操作系统能够读取这个文件并明白它是和当前系统不相兼容的。换句话说，当你在MS - DOS 6. 0下运行一个Wi ndows NT可执行文件时，你会得到这样一条消息：“ T hisprogra m c a nnotbe r un i n DOS m ode. ”如果MS - DOS头部不是作为P E文件格式的第一部分的话
8、，操作系统装载文件的时候就会失败，并提供一些完全没用的信息，例如：“ T he nam es pec i f i e d i s not r e c ogniz e d a s a n i nte r nal or e xte r nal c om m a nd, oper a ble progra m or bat c h f i l e . ”MS - DOS头部占据了P E文件的头64个字节，描述它内容的结构如下：/ / WI NNT . Ht ypedef s t r uct _IMAGE _DO S _HE ADE R / / DOS的. E XE头部US HOR T e _m a
9、gic ; / /魔术数字US HOR T e _cblp; / /文件最后页的字节数US HOR T e _cp; / /文件页数US HOR T e _cr l c ; / /重定义元素个数US HOR T e _cpar hdr; / /头部尺寸，以段落为单位US HOR T e _m i nal l oc; / /所需的最小附加段US HOR T e _m a xal l oc; / /所需的最大附加段US HOR T e _ss ; / /初始的S S值（相对偏移量）US HOR T e _sp; / /初始的S P值US HOR T e _cs um ; / /校验和US HOR
10、T e _ip; / /初始的I P值US HOR T e _cs ; / /初始的C S值（相对偏移量）US HOR T e _lf a r l c ; / /重分配表文件地址US HOR T e _ovno;/ /覆盖号US HOR T e _re s 4; / /保留字US HOR T e _oem i d; / / OE M标识符（相对e _oem i nfo）US HOR T e _oem i nfo; / / OE M信息US HOR T e _re s 210; / /保留字L ONG e _lf a new ; / /新e xe头部的文件地址 I MAGE _DO S _HE
11、ADE R , *PI MAGE _DOS _HE ADE R ;第一个域e _m a gic，被称为魔术数字，它被用于表示一个MS - DOS兼容的文件类型。所有MS - DOS兼容的可执行文件都将这个值设为0x5A4D，表示AS C I I字符MZ。MS - DOS头部之所以有的时候被称为MZ头部，就是这个缘故。还有许多其它的域对于MS - DOS操作系统来说都有用，但是对于Wi ndows NT来说，这个结构中只有一个有用的域最后一个域e _lf new，一个4字节的文件偏移量，P E文件头部就是由它定位的。对于Wi ndows NT的P E文件来说，P E文件头部是紧跟在MS - DO
12、S头部和实模式程序残余之后的。实模式残余程序实模式残余程序是一个在装载时能够被MS - DOS运行的实际程序。对于一个MS - DOS的可执行映像文件，应用程序就是从这里执行的。对于Wi ndows、OS / 2、Wi ndows NT这些操作系统来说，MS - DOS残余程序就代替了主程序的位置被放在这里。这种残余程序通常什么也不做，而只是输出一行文本，例如：“ T his progra m r e quir e s Mi c r osoft Wi ndows v3.1 orgre a t e r . ”当然，用户可以在此放入任何的残余程序，这就意味着你可能经常看到像这样的东西：“ You
13、c a n t r un a Wi ndows NT a ppli c a t i on on OS / 2, i t s s i m ply not poss i ble . ”当为Wi ndows 3. 1构建一个应用程序的时候，链接器将向你的可执行文件中链接一个名为WI NS T UB . E XE的默认残余程序。你可以用一个基于MS - DOS的有效程序取代WI NS T UB，并且用S T UB模块定义语句指示链接器，这样就能够取代链接器的默认行为。为Wi ndows NT开发的应用程序可以通过使用- S T UB :链接器选项来实现。PE文件头部与标志P E文件头部是由MS - D
14、OS头部的e _lf a new域定位的，这个域只是给出了文件的偏移量，所以要确定P E头部的实际内存映射地址，就需要添加文件的内存映射基地址。例如，以下的宏是包含在P E F I L E . H源文件之中的：/ / P E F I L E . H#def i ne NT S I GNAT UR E ( a ) ( ( L P VOI D) ( ( BYT E *)a + ( ( P I MAGE _DOS _HE ADE R ) a ) - e _lf a new ) )在处理P E文件信息的时候，我发现文件之中有些位置需要经常查阅。既然这些位置仅仅是对文件的偏移量，那么用宏来实现这些定位就
15、比较容易，因为它们较之函数有更好的表现。请注意这个宏所获得的是P E文件标志，而并非P E文件头部的偏移量。那是由于自Wi ndows与OS / 2的可执行文件开始，. E XE文件都被赋予了目标操作系统的标志。对于Wi ndows NT的P E文件格式而言，这一标志在P E文件头部结构之前。在Wi ndows和OS / 2的某些版本中，这一标志是文件头的第一个字。同样，对于P E文件格式，Wi ndows NT使用了一个DWOR D值。以上的宏返回了文件标志的偏移量，而不管它是哪种类型的可执行文件。所以，文件头部是在DWOR D标志之后，还是在WOR D标志处，是由这个标志是否Wi ndow
16、s NT文件标志所决定的。要解决这个问题，我编写了I m a geF i l e T ype函数（如下），它返回了映像文件的类型：/ / P E F I L E . CDWOR D WI NAP I I m a geF i l e T ype ( L P VOI D l pFi l e )/ *首先出现的是DOS文件标志*/i f ( *(US HOR T *)l pFi l e = = I MAGE _DOS _SI GNAT UR E )/ *由DOS头部决定P E文件头部的位置*/i f ( L OWOR D ( *(DWOR D *)NT S I GNAT UR E ( l pFi l e ) ) = =I MAGE _OS 2_SI GNAT UR E | |L OWOR D ( *(DWOR D *)NT S I GNAT UR E ( l pFi l e ) ) = =I MAGE _OS 2_SI GNAT UR E _LE )r e t urn ( DWOR D) L OWO R D( *(D
