PE文件格式详解（一）――基础知识 什么是PE文件格式： 我们知道所有文件都是一些连续（当然实际存储在磁盘上的时候不一定是连续的）的数据组织起来的，不同类型的文件肯定组织形式也各不相同；PE文件格式便是一种文件组织形式，它是32位Wind ow系统中的可执行文件EXE以及动态连接库文件DLL的组织形式。为什么我们双击一个EXE文件之后它就会被Window运行，而我们双击一个DOC文件就会被Word打开并显示其中的内容；这说明文件中肯定除了存在那些文件的主体内容（比如EXE文件中的代码，数据等，DOC文件中的文件内容等）之外还存在其他一些重要的信息。这些信息是给文件的使用者看的，比如说EXE文件的使用者就是Window，而DOC文件的使用者就是Word。Window可以根据这些信息知道把文件加载到地址空间的那个位置，知道从哪个地址开始执行；加载到内存后如何修正一些指令中的地址等等。那么PE文件中的这些重要信息都是由谁加入的呢？是由编译器和连接器完成的，针对不同的编译器和连接器通常会提供不同的选项让我们在编译和 联结生成PE文件的时候对其中的那些Window需要的信息进行设定；当然也可以按照默认的方式编译连接生成Window中默认的信息。例如：WindowNT默认的程序加载基址是0x40000；你可以在用VC连接生成EXE文件的时候使用选项更改这个地址值。在不同的操作系统中可执行文件的格式是不同的，比如在Linux上就有一种流行的ELF格式；当然它是由在Linux上的编译器和连接器生成的，
所以编译器、连接器是针对不同的CPU架构和不同的操作系统而涉及出来的。在嵌入式领域中我们经常提到交叉编译器一词，它的作用就是在一种平台下编译出能在另一个平台下运行的程序；例如，我们可以使用交叉编译器在跑Linux的X86机器上编译出能在Arm上运行的程序。 程序是如何运行起来的： 一个程序从编写出来到运行一共需要那些工具，他们都对程序作了些什么呢？里面都涉及哪些知识需要学习呢？先说工具：编辑器－》编译器－》连接器－》加载器；首先我们使用编辑器编辑源文件；然后使用编译器编译程目标文件OBJ，这里面涉及到编译原理的知识；连接器把OBJ文件和其他一些库文件和资源文件连接起来生成EXE文件，这里面涉及到不同的连接器的知识，连接器根据OS的需要生成EXE文件保存着磁盘上；当我们运行EXE文件的时候有W indow的加载器负责把EXE文件加载到线性地址空间，加载的时候便是根据上一节中说到的PE文件格式中的哪些重要信息。然后生成一个进程，如果进程中涉及到多个线程还要生成一个主线程；此后进程便开始运行；这里面涉及的东西很多，包括：PE文件格式的内容；内存管理（CPU内存管理的硬件环境以及在此基础上的OS内存管理方式）；模块，进程，线程的知识；只有把这些都弄清楚之后才能比较清楚的了解这整个过程。下面就让我们先来学习PE文件格式吧。
PE可选头部 PE可执行文件中接下来的224个字节组成了PE可选头部。虽然它的名字是“可选头部”，但是请确信：这个头部并非“可选”，而是“必需”的。OPTHDROFFSET宏可以获得指向可选头部的指针： PEFILE.H #define OPTHDROFFSET(a) ((LPVOID)((BYTE *)a + \ ((PIMAGE_DOS_HEADER)a)->e_lfanew + \ SIZE_OF_NT_SIGNATURE + \ sizeof(IMAGE_FILE_HEADER))) 可选头部包含了很多关于可执行映像的重要信息，例如初始的堆栈大小、程序入口点的位置、首选基地址、操作系统版本、段对齐的信息等等。IMAGE_OPTIONAL_HEADER结构如下： WINNT.H typedef struct _IMAGE_OPTIONAL_HEADER { // // 标准域 // USHORT Magic; UCHAR MajorLinkerVersion; UCHAR MinorLinkerVersion; ULONG SizeOfCode; ULONG SizeOfInitializedData; ULONG SizeOfUninitializedData; ULONG AddressOfEntryPoint; ULONG BaseOfCode; ULONG BaseOfData; // // NT附加域 // ULONG ImageBase; ULONG SectionAlignment;
ULONG FileAlignment; USHORT MajorOperatingSystemVersion; USHORT MinorOperatingSystemVersion; USHORT MajorImageVersion; USHORT MinorImageVersion; USHORT MajorSubsystemVersion; USHORT MinorSubsystemVersion; ULONG Reserved1; ULONG SizeOfImage; ULONG SizeOfHeaders; ULONG CheckSum; USHORT Subsystem; USHORT DllCharacteristics; ULONG SizeOfStackReserve; ULONG SizeOfStackCommit; ULONG SizeOfHeapReserve; ULONG SizeOfHeapCommit; ULONG LoaderFlags; ULONG NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; } IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER; 如你所见，这个结构中所列出的域实在是冗长得过分。为了不让你对所有这些域感到厌烦，我会仅仅讨论有用的——就是说，对于探究PE文件格式而言有用的。 标准域 首先，请注意这个结构被划分为“标准域”和“NT附加域”。所谓标准域，就是和UNIX可执行文件的COFF 格式所公共的部分。虽然标准域保留了COFF中定义的名字，但是Windows NT仍然将它们用作了不同的目的——尽管换个名字更好一些。 ·Magic。我不知道这个域是干什么的，对于示例程序EXEVIEW.EXE示例程序而言，这个值是0x010B
2009-06-08 11:38:40 https://www.doczj.com/doc/f47711433.html, 来源：黑客防线 一直以来都在学习PE文件结构，从不敢轻视，但是即使如此还是发现自己在这方面有所不足，于是便想到了用纯手工方式打造一个完整的可执行的PE文件。在这期间我也查了大量资料，但是这些资料都有一个通病就是不... 一直以来都在学习PE文件结构，从不敢轻视，但是即使如此还是发现自己在这方面有所不足，于是便想到了用纯手工方式打造一个完整的可执行的PE文件。在这期间我也查了大量资料，但是这些资料都有一个通病就是不完整，看雪得那个只翻译了一部分，加解密技术内幕介绍的更是笼统，而且是打造一个只有180字节的PE文件，是高手们茶余饭后的怡情小游戏。 鉴于此，心想为什么不自己摸索着手工打造一个完整些的呢？一是加强一下自己对于PE文件的了解，二是写出一篇参考性比较强的文章，给有志于在此发展的朋友们铺一铺路，也算是干了一件利国利民的好事。 对于手工打造PE文件，我个人认为至少要分为三篇文章来阐述，每篇相对独立，合起来形成一个相对的体系。第一篇文章（也就是本文）用来介绍怎样用手工打造一个最典型、最简单的PE文件，而后两篇文章的问世还要引用潘爱民先生的一句话“还需要时日与机缘”。 本文介绍的PE文件手工编辑方式，是本着以下三个原则所写的，望读者注意： 1、完整性：对于手工打造PE文件所不需注意的字段也进行了必要的介绍，因此整文可能显得非常臃肿。 2、典型性：完全按照典型的PE文件结构构造，因此对于某些不常见的PE文件结构有一定差距。 3、易学性：对于字段之间的逻辑关系进行了比较细致的介绍，因此对于一部分底子比较好的读者来说可能显得有些啰嗦。 为了方便各位阅读与查阅，我将文章分成了三各部分，以便各位读者各取所需，不用把宝贵的精力浪费在查找上。 1、PE文件整体信息，提供了一个剖析PE文件的图表，以便于读者对于PE文件有一个整体的了解，并监督自己的工作进度。 2、对于重点字段的介绍，以及字段之间的逻辑关系，建议首先从这里开始看。 3、手工构造PE文件字段清单，此清单包含构造一个完整PE文件的每一个字节，跟着这个清单走就可以构造一个PE文件。 对于第一次手工打造PE文件的朋友们来说，你们可以以“一、整体性息”为大纲，并参考第三部分一块一块的慢慢打造，如果有不懂的地方就去看第二部分。 选读：为什么要手工打造PE文件？ 我们知道，往往从一个系统可执行文件结构上，就可以看整个操作系统的一些特性。也就是说PE里有Windows操作系统结构与运行机理的影子。由此可见，PE文件必然是一个非常庞杂且逻辑复杂的结构，那么为什么我们还要“自取其辱”来手工制造一个PE文件呢？这就要从PE文件的重要性说起了。 我们现今组成Windows大家庭的主要成员就是PE文件了，里面包括EXE、DLL、OCX、SYS等一切最有价值的文件都是PE文件格式，出于对版权的考虑或对某种技术的渴求，任何一种与Windows系统相关的行为最终都要归集到这里--PE文件。 特别是对于想学习加壳、破解、搞虚拟机的朋友们来说，熟知PE文件结构更是必不可少的基本功！ 但也正是由于PE文件的复杂性，我们才要采取一些特别的办法来攻克它，其中手工打造PE文件就是一条捷径。 你可以想像一下，如果你都可以手工打造PE文件的话，那么对于PE文件的了解更是
三年前，我曾经写了一个手工打造可执行程序的文章，可是因为时间关系，我的那篇文章还是有很多模糊的地方，我一直惦记着什么时候再写一篇完美的，没想到一等就等了三年。因为各种原因直到三年后的今天我终于完成了它。现在把它分享给大家，希望大家批评指正。 我们这里将不依赖任何编译器，仅仅使用一个十六进制编辑器逐个字节的手工编写一个可执行程序。以这种方式讲解PE结构，通过这个过程读者可以学习PE结构中的PE头、节表以及导入表相关方面的知识。为了简单而又令所有学习程序开发的人感到亲切，我们将完成一个Hello World! 程序。功能仅仅是运行后弹出一个消息框，消息框的内容是Hello World！。 首先了解一下Win32可执行程序的大体结构，就是通常所说的PE结构。 如图1所示PE结构示意图： 图1 标准PE结构图 由图中可以看出PE结构分为几个部分： MS-DOS MZ 头部：所有PE文件必须以一个简单的DOS MZ 头开始。有了它，一旦程序在DOS下执行，DOS就能识别出这是有效的执行体，然后运行紧随MZ header 之后的DOS程序。以此达到对Dos系统的兼容。（通常情况DOS MZ header总共占用64byte）。 MS-DOS 实模式残余程序：实际上是个有效的EXE，在不支持PE文件格式的操作系统中，它将简单显
示一个错误提示，大多数情况下它是由汇编编译器自动生成。通常，它简单调用中断21h，服务9来显示字符串"This program cannot run in DOS mode"。（在我们写的程序中，他不是必须的，可以不予以实现，但是要保留其大小，大小为112byte，为了简洁，可以使用00来填充。） PE文件标志：是PE文件结构的起始标志。（长度4byte， Windows程序此值必须为0x50450000） PE文件头：是PE相关结构 IMAGE_NT_HEADERS 的简称，其中包含了许多PE装载器用到的重要域。执行体在支持PE文件结构的操作系统中执行时，PE装载器将从DOS MZ header中找到PE header的起始偏移量，跳过了MS-DOS 实模式残余程序，直接定位到真正的文件头PE header，长度20byte。 PE文件可选头：虽然它的名字是“可选头部”，但是请确信：这个头部并非“可选”，而是“必需”的。(长度 224byte )。 各段头部：又称节头部，一个Windows NT的应用程序典型地拥有9个预定义段（节），它们是“.text”、“.bss”、“.rdata”、“.data”、“.rsrc”、“.edata”、“.idata”、“.pdata”和“.debug”。一些应用程序不需要所有的这些段，同样还有些应用程序为了自己特殊的需要而定义了更多的段。(每个段头部占40byte，我们这里也不需要所有的段，仅需3个段。） 通常我们是将PE整个结构分成四个部分，把MS-DOS MZ 头部和MS-DOS 实模式残余程序作为第一部分，可以称他为DOS部分，而PE文件标志、PE文件头、PE文件可选头三个部分作为第二部分，称之为PE头部分，因为这部分才是Windows下真正需要的部分，所以从PE文件标志开始才是真正的PE部分。各段头部是第三部分，称之为节表。它详细描述了PE文件中各个节的详细信息。最后就是各个节的实体部分了，称为节数据。 以上仅仅是对PE结构各部分的大体讲解。接下来再手写这个Hello World!程序过程中，我将详细介绍每个部分的含义。 首先准备一下工具，一个十六进制编辑器足以。我们这里使用VC++ 6.0所携带的十六进制编辑器，您也可以使用如WinHex等十六进制编辑工具。 打开VC，选择文件，新建菜单项，然后选择一个二进制文件，单击确定。一切就绪了，下面就开始手写可执行程序，如图2所示：
pe文件格式:PE文件格式(1) 疯狂代码 https://www.doczj.com/doc/f47711433.html,/ ?:http:/https://www.doczj.com/doc/f47711433.html,/Waigua/Article60255.html 介绍说明:希望本文能够对初级入门CRACKER有定帮助翻译存在疏漏或者不准确希望来信指出感谢您指导！感谢看雪为我们提供这个交流平台让我们技术和时俱进！！ 前言: PE("portableexecutable")文件格式是针对MSwindowsNT,windows95and win32s可执行 2进制代码(DLLsandprograms)在windowsNT内,驱动也是这个格式也可以用于对象文件和库 这个格式是Microsoft设计并在1993经过TIS(toolerfacestandard)委员会 (Microsoft,Intel,Borland,Watcom,IBM等)标准化了它基于在UNIX和VMS上运行对象文件和可执行文件COFF"commonobjectfileformat"格式 win32SDK包括个头文件
《PE文件剖析实验》报告 学院：计算机学院 日期： 2016年 4 月 25 日
目录 1. 实验目的 (2) 2. 实验过程 (2) 3. 实现结果 (2) 4. 遇到的问题及感想收获 (5)
1. 实验目的 熟悉各种PE编辑查看工具，详细了解PE文件格式，为后续计算机病毒学习打下基础，学会分析PE文件文件头、引入表、引出表以及资源表。 2. 实验过程 PE文件被称为可移植的执行体，是Portable Execute的简称，常见的EXE、DLL、OCX、SYS、COM等文件都是PE文件。 本次实验将综合运用Peview和LordPE，自由选择一款EXE文件或DLL文件，对其展开分析，找出文件的PE标志，入口地址、基址，节表个数及列出节表、输出表、输入表等信息。 3. 实现结果 ●自由选择一款EXE文件或DLL文件，对其展开分析，各项结果截图如下：●文件的PE标志
●入口地址 ●基址 ●节表个数及列出节表
●输出表 ●输入表
4. 遇到的问题及感想收获 本次实验时对PE文件格式进行分析，对PE文件有了一个大致的了解，如什么是PE文件的文件头，什么是区段，什么是数据目录。由于现阶段大都的病毒都是PE病毒，所以了解它们可以更好地知道PE病毒是如何感染PE文件的。不仅如此，对PE文件的修改加壳等操作也证实了PE文件并不是不可编辑的，也可以让我们更好地了解PE文件的内部结构。 这次实验主要使用了LoadPE和Peview软件对PE文件进行查看，提高了我们对PE文件结构的认识，帮助了我们吸收理论课上所学的知识，如基址与相对虚拟地址及其查看方法，PE文件首部，区段的含义等。这对我们以后的学习有很大的帮助，达到了预期的实验目的。 通过本次课程设计，我深刻认识到要掌握知识，不仅仅是要把书上的基本知识学好而且还要不断进行实践，将所学的跟实践操作结合起来才能更好地巩固所学，才能提高自己的实践能力。
PE文件格式分析及修改(图) PE 的意思是 Portable Executable（可移植的执行体）。它是 Win32环境自身所带的执行文件格式。它的一些特性继承自Unix的Coff(common object file format)文件格式。“Portable Executable”（可移植的执行体）意味着此文件格式是跨Win32平台的；即使Windows运行在非Intel的CPU上，任何win32平台的PE装载器都能识别和使用该文件格式。 PE文件在文件系统中，与存贮在磁盘上的其它文件一样，都是二进制数据，对于操作系统来讲，可以认为是特定信息的一个载体，如果要让计算机系统执行某程序，则程序文件的载体必须符合某种特定的格式。要分析特定信息载体的格式，要求分析人员有数据分析、编码分析的能力。在Win32系统中，PE 文件可以认为.exe、.dll、.sys 、.scr类型的文件，这些文件在磁盘上存贮的格式都是有一定规律的。 一、PE格式基础 下表列出了PE的总体结构 一个完整的PE文件，前五项是必定要有的，如果缺少或者数据出错，系统会拒绝执行该文件如下图
DOS MZ header部分是DOS时代遗留的产物，是PE文件的一个遗传基因，一个Win32程序如果在DOS 下也是可以执行，只是提示：“This program cannot be run in DOS mode.”然后就结束执行，提示执行者，这个程序要在Win32系统下执行。 DOS stub 部分是DOS插桩代码，是DOS下的16位程序代码，只是为了显示上面的提示数据。这段代码是编译器在程序编译过程中自动添加的。 PE header 是真正的Win32程序的格式头部，其中包括了PE格式的各种信息，指导系统如何装载和执行此程序代码。 Section table部分是PE代码和数据的结构数据，指示装载系统代码段在哪里，数据段在哪里等。对于不同的PE文件，设计者可能要求该文件包括不同的数据的Section。所以有一个Section Table 作为索引。Section多少可以根据实际情况而不同。但至少要有一个Section。如果一个程序连代码都没有，那么他也不能称为可执行代码。在Section Table后，Section数目的多少是不定的。 二、程序的装入 当我们在explorer.exe（资源管理器）中双击某文件，执行一个可执行程序，系统会根据文件扩展名启动一个程序装载器，称之为Loader。Loader会首先检查DOS MZ Header，如果存在，就继续寻找PE header，如果这两项都不存在，就认为是DOS 16位代码，如果只存在DOS MZ Header，而其中又指示
一、PE文件结构 PE文件被称为可移植的执行体是Portable Execute的全称，常见的EXE、DLL、OCX、SYS、COM都是PE文件，PE文件是微软Windows操作系统上的程序文件（可能是间接被执行，如DLL），Portable 是指对于不同的Windows版本和不同的CPU类型上PE文件的格式是一样的，当然CPU不一样了，CPU指令的二进制编码是不一样的。只是文件中各种东西的布局是一样的。 在下面关于结构的定义中，WORD 表示变量大小为2个字节，DWORD表示变量大小是4个字节。 1.1 PE文件的结构 PE文件有着固定的结构，分为五个部分，如下： 1：DOS MZ Header(DOS文件头) 一个IMAGE_DOS_HEADER结构，大小为64字节。 2：DOS Stub(DOS加载模块) 没有固定大小。 3：PE Header(PE文件头）一个IMAGE_NT_HEADERS结构，大小为248字节。 4：Section Table(节表）一个IMAGE_SECTION_HEADER结构数组，数组大小依据节而定，如果PE文件有5个节，则数组大小为5。 5：Sections(节或段）没有固定大小，可以有多个节。 1.2 DOS文件头和DOS加载模块 PE文件的一二部分完全是为了程序能在DOS运行下时给出一个提示。 IMAGE_DOS_HEADER结构的定义如下： Typedef struct IMAGE_DOS_HEADER{ WORD e_magic; // 魔术数字 WORD e_cblp; // 文件最后页的字节数 WORD e_cp; // 文件页数 WORD e_crlc; // 重定义元素个数 WORD e_cparhdr; // 头部尺寸，以段落为单位 WORD e_minalloc; // 所需的最小附加段 WORD e_maxalloc; // 所需的最大附加段 WORD e_ss; // 初始的SS值(相对偏移量) WORD e_sp; // 初始的SP值 WORD e_csum; // 校验和 WORD e_ip; // 初始的IP值 WORD e_cs; // 初始的CS值(相对偏移量) WORD e_lfarlc; // 重分配表文件地址 WORD e_ovno; // 覆盖号 WORD e_res[4]; // 保留字 WORD e_oemid; // OEM标识符(相对e_oeminfo) WORD e_oeminfo; // OEM信息 WORD e_res2[10]; // 保留字 LONG e_lfanew; // 新exe头部的文件地址 } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
PE文件格式分析实验 使用工具LordPE/PEview、winhex 选择一个exe或者DLL文件 阶段一：（本次实验） 1.DOS头部查看、对应DOS头结构进行数据逐项分析 2.PE头部查看、对应PE头结构进行数据逐项分析 3.Exe文件和DLL文件均是PE格式，他们的区别在哪里？ 4.Section表结构的查看（是否可以增加一个新的section表？对齐边界是多少？） 5.PE文件section查看、对应section 块表结构进行数据分析 6.VA、RVA、RA计算 7.问题：你查看的PE文件DOS、PE头部的空隙是多大？ 8.问题：你查看的PE文件在那个section的空隙最大/最小？ 9.问题：如果手工增加一个section，要修改哪些字段，请手工试验。（提高：你的新块表 增加是否引起原文件的对齐位置的改变？） 10.问题（提高）：一个section的属性字节如何设置，请在上一个问题基础上实验。 本次实验要求对照以上要求，自行选择文件进行分析，撰写报告。 阶段二：（后一阶段的工作） 1.资源查看、修改 2.编写PE文件分析程序 3.编写PE病毒程序 附录1PE格式详细讲解（一） 前几天发了一个PE信息查看器的小工具，本来想用那个获取邀请码的，可是觉得几率不是太大，于是再献上一篇教程，既是为了自己能获得邀请码，也是帮助那些想学习PE格式的人，让知识来源于网络再回归网络。 N年没写文章了，不知道句子还能不能写通顺，最近正在看《软件加密技术内幕》，刚看完PE结构那部分内容，所以想起来写篇教程作为读书笔记，既可加强记忆又可帮助别人，何乐而不为呢。 好了，废话少说好戏正式上场，PE是英文Portable Executable（可移植的执行体）的缩写，从缩写可以看出它是跨平台的，即使在非intel的CPU上也能正常运行的。它是 Win32环境自身所带的执行体文件格式。其实不光是EXE文件是PE格式，其它的一些重要文件，例如动态链接库文件(DLL),驱动文件(SYS)等也是PE格式的，所以学好PE格式是非常重要的，以下我把这类文件统称为PE文件。学习PE文件结构不仅可以使我们知道可执行文件是怎样运行的，也可以使我们了解一下windows操作系统的一些工作机制，精通PE是成为计算机高手的必经之路。 其实说白了PE文件格式就是一种文件组织的方式，里面对一些重要信息的存放做了一些规定，比如文件要运行，我们就得先知道入口地址，可是我们从哪去得到入口地址呢，我们必须把保存有入口地址信息
PE文件结构详解（三）PE导出表 上篇文章PE文件结构详解（二）可执行文件头的结尾出现了一个大数组，这个数组中的每一项都是一个特定的结构，通过函数获取数组中的项可以用RtlImageDirectoryEntryToData函数，DataDirectory中的每一项都可以用这个函数获取，函数原型如下： PVOID NTAPI RtlImageDirectoryEntryToData(PVOID Base, BOOLEAN MappedAsImage, USHORT Directory, PULONG Size); Base：模块基地址。 MappedAsImage：是否映射为映象。 Directory：数据目录项的索引。 Size：对应数据目录项的大小，比如Directory为0，则表示导出表的大小。 返回值表示数据目录项的起始地址。 这次来看看第一项：导出表。 导出表是用来描述模块中的导出函数的结构，如果一个模块导出了函数，那么这个函数会被记录在导出表中，这样通过GetProcAddress函数就能动态获取到函数的地址。函数导出的方式有两种，一种是按名字导出，一种是按序号导出。这两种导出方式在导出表中的描述方式也不相同。模块的导出函数可以通过Dependency walker工具来查看：
上图中红框位置显示的就是模块的导出函数，有时候显示的导出函数名字中有一些符号，像 ??0CP2PDownloadUIInterface@@QAE@ABV0@@Z，这种是导出了C++的函数名，编译器将名字进行了修饰。 下面看一下导出表的定义吧： 结构还算比较简单，具体每一项的含义如下： Characteristics：现在没有用到，一般为0。 TimeDateStamp：导出表生成的时间戳，由连接器生成。 MajorVersion，MinorVersion：看名字是版本，实际貌似没有用，都是0。
PE文件结构详解 1 摘要 Windows NT 3.1引入了一种名为PE文件格式的新可执行文件格式。PE文件格式的规范包含在了MSDN的CD中（Specs and Strategy, Specifications, Windows NT File Format Specifications），但是它非常之晦涩。 然而这一的文档并未提供足够的信息，所以开发者们无法很好地弄懂PE格式。本文旨在解决这一问题，它会对整个的PE文件格式作一个十分彻底的解释，另外，本文中还带有对所有必需结构的描述以及示范如何使用这些信息的源码示例。 为了获得PE文件中所包含的重要信息，我编写了一个名为PEFILE.DLL的动态链接库，本文中所有出现的源码示例亦均摘自于此。这个DLL和它的源代码都作为PEFile示例程序的一部分包含在了CD中（译注：示例程序请在MSDN中寻找，本站恕不提供），你可以在你自己的应用程序中使用这个DLL；同样，你亦可以依你所愿地使用并构建它的源码。在本文末尾，你会找到PEFILE.DLL的函数导出列表和一个如何使用它们的说明。我觉得你会发现这些函数会让你从容应付PE文件格式的。 2 介绍 Windows操作系统家族最近增加的Windows NT为开发环境和应用程序本身带来了很大的改变，这之中一个最为重大的当属PE文件格式了。新的PE文件格式主要来自于UNIX操作系统所通用的COFF规范，同时为了保证与旧版本MS-DOS及Windows操作系统的兼容，PE文件格式也保留了MS-DOS中那熟悉的MZ头部。 在本文之中，PE文件格式是以自顶而下的顺序解释的。在你从头开始研究文件内容的过程之中，本文会详细讨论PE文件的每一个组成部分。 很多解决PE文件格式的工作和直接观看数据有关。例如，要弄懂导入地址名称表是如何构成的，我就得同时查看.idata段头部、导入映像数据目录、可选头部以及当前的.idata段实体，而EXEVIEW.EXE就是查看这些信息的最佳示例。 在针对PE文件的有关编程中，你可能用到以下一些数据结构： IMAGE_DOS_HEADER IMAGE_IMPORT_DESCRIPTOR IMAGE_NT_HEADERS IMAGE_SECTION_HEADER IMAGE_OPTIONAL_HEADER IMAGE_DA TA_DIRECTORY IMAGE_FILE_HEADER 3 PE文件结构图
PE文件格式详解(上) Windows NT 3.1引入了一种名为PE文件格式的新可执行文件格式。PE文件格式的规范包含在了MSDN的CD 中（Specs and Strategy, Specifications, Windows NT File Format Specifications），但是它非常之晦涩。 然而这一的文档并未提供足够的信息，所以开发者们无法很好地弄懂PE格式。本文旨在解决这一问题，它会对整个的PE文件格式作一个十分彻底的解释，另外，本文中还带有对所有必需结构的描述以及示范如何使用这些信息的源码示例。 为了获得PE文件中所包含的重要信息，我编写了一个名为PEFILE.DLL的动态链接库，本文中所有出现的源码示例亦均摘自于此。这个DLL和它的源代码都作为PEFile示例程序的一部分包含在了CD中（译注：示例程序请在MSDN 中寻找，本站恕不提供），你可以在你自己的应用程序中使用这个DLL；同样，你亦可以依你所愿地使用并构建它的源码。在本文末尾，你会找到PEFILE.DLL的函数导出列表和一个如何使用它们的说明。我觉得你会发现这些函数会让你从容应付PE文件格式的。
介绍 Windows操作系统家族最近增加的Windows NT为开发环 境和应用程序本身带来了很大的改变，这之中一个最为重大的当属PE文件格式了。新的PE文件格式主要来自于UNIX 操作系统所通用的COFF规范，同时为了保证与旧版本 MS-DOS及Windows操作系统的兼容，PE文件格式也保留了MS-DOS中那熟悉的MZ头部。 在本文之中，PE文件格式是以自顶而下的顺序解释的。在你从头开始研究文件内容的过程之中，本文会详细讨论 PE文件的每一个组成部分。 许多单独的文件成分定义都来自于Microsoft Win32 SDK开发包中的WINNT.H文件，在这个文件中你会发现用来描述文件头部和数据目录等各种成分的结构类型定义。但是，在WINNT.H中缺少对PE文件结构足够的定义，在这 种情况下，我定义了自己的结构来存取文件数据。你会在PEFILE.DLL工程的PEFILE.H中找到这些结构的定义，整套的PEFILE.H开发文件包含在PEFile示例程序之中。
PE文件结构详解（六）重定位 前面两篇PE文件结构详解（四）PE导入表和PE文件结构详解（五）延迟导入表介绍了PE文件中比较常用的两种导入方式，不知道大家有没有注意到，在调用导入函数时系统生成的代码是像下面这样的： 在这里，IE的iexplorer.exe导入了Kernel32.dll的GetCommandLineA函数，可以看到这是个间接call，00401004这个地址的内存里保存了目的地址，根据图中显示的符号信息可知，00401004这个地址是存在于iexplorer.exe模块中的，实际上也就是一项IAT的地址。这个是IE6的exe中的例子，当然在dll 中如果导入其他dll中的函数，结果也是一样的。这样就有一个问题，代码里call 的地址是一个模块内的地址，而且是一个VA，那么如果模块基地址发生了变化，这个地址岂不是就无效了？这个问题如何解决？ 答案是：Windows使用重定位机制保证以上代码无论模块加载到哪个基址都能正确被调用。听起来很神奇，是怎么做到的呢？其实原理并不很复杂，这个过程分三步： 1.编译的时候由编译器识别出哪些项使用了模块内的直接VA，比如push一个全局变量、函数地址，这些指令的操作数在模块加载的时候就需要被重定位。 2.链接器生成PE文件的时候将编译器识别的重定位的项纪录在一张表里，这张表就是重定位表，保存在DataDirectory中，序号是 IMAGE_DIRECTORY_ENTRY_BASERELOC。 3.PE文件加载时，PE 加载器分析重定位表，将其中每一项按照现在的模块基址进行重定位。 以上三步，前两部涉及到了编译和链接的知识，跟本文的关系不大，我们直接看第三步，这一步符合本系列的特征。 在查看重定位表的定义前，我们先了解一下他的存储方式，有助于后面的理解。按照常规思路，每个重定位项应该是一个DWORD，里面保存需要重定位的RVA，这样只需要简单操作便能找到需要重定位的项。然而，Windows并没有这样设计，原因是这样存放太占用空间了，试想一下，加入一个文件有n个重定位项，那么就需要占用4*n个字节。所以Windows采用了分组的方式，按照重定位项所在的页面分组，每组保存一个页面其实地址的RVA，页内的每项重定位项使用一个WORD 保存重定位项在页内的偏移，这样就大大缩小了重定位表的大小。
offset 0123456789A B C D E F 00000000 00000010 00000020 00000030 000000400000005000000060000000700000008000000090000000A0 000000B0 000000C0 Maj orL ink erV ers ion Min orL ink erV ers ion 000000D0 Signature IMAGE_FILE_HEADER DOS stub M S -D o s 部首 IMAGE_FILE_HEADER IMAGE_OPTIONAL_HEADER32 IMAGE_FILE_HEADER NumberOfSymbols SizeOfO ptional Header
Characte ristics Magic SizeOfCode e_lfanew Signature Machine NumberOf Sections TimeDataStamp PointerTpSymbo lTable e_oemid e_oemin fo e_res2 e_ss e_sp e_csum e_ip e_cs e_lfarl c e_ovno e_res PE文件结构DOS"MZ"HEADER
e_magic e_cblp e_cp e_crlc e_cparh dr e_minal loc e_maxal loc 000000E0 000000F0 00000100 00000110 00000120 00000130 00000140 00000150 IMAGE_OPTIONAL_HEADER32 DataDirectory( PE文件头 IMAGE_NT_HEADERS IMAGE_OPTIONAL_HEADER32 DataDirectory IMAGE_DIRECTORY_ENTRY_BASERELOC IMAGE_DIRECTORY_ENTRY_DEBUG
ISSN 1009-3044 Computer Knowledge and Technology V ol.5 No.9, March 2009 系统软件与软件工程2379 电脑知识与技术 PE文件格式分析 李卓远, 鲜 明 （国防科大 电子科学与工程学院, 湖南 长沙 410073） 摘要：主要分析了PE(Portable Executable)文件格式，重点探讨了PE文件中的输入表、输出表以及资源段的格式，还探究了在微软全新的．Net平台上对PE文件的扩展。 关键词：PE文件格式；段；PE扩展 中图分类号：TP311.12 文献标识码：A 文章编号：1009-3044(2009)09-2379-03 Analysis of PE File Format LI Zhuo-yuan, XIAN Ming ( Dept. of Electronic Science&Technology, NUDT, Changsha 410073, China) Abstract: This paper analyzes the PE(Portable Executable)? le format. We explores the import table, export table and resource section of PE ? le and also discusses the extensions to PE ? le format in .Net platform. Key words : PE(Portable Executable)File Format; Sections; Extensions to PE 1 引言 PE文件格式是Win32平台上（包括 Windows9x/NT/2000/XP/2003/Vista/CE）主流的可执行文件格式，是Portable Executable File Format（可移植的执行体）简写。它衍生于早期建立在VAX/VMS上的COFF（Common Object File Format）文件格式。对PE格式和COFF文件的主要描述存放在winnt.h文件中，它是PE文件定义的最终决定者。 EXE和DLL文件是PE文件格式的两种主要文件，它们的区别完全是语义上的，二者使用完全相同的PE格式。用IMAGE_FILE_HEADER中的Characteristics字段的第13位来标识出这个文件到底是EXE还是DLL。 64位的Windows只对PE格式作了一些简单的修饰，新格式叫做PE32+，并未加入新的结构，只简单的将以前的32位字段扩展为64位。图1是PE文件的基本结构图。 2 PE的基本概念 文件偏移地址是指当PE文件存贮在磁盘上时，某个数据的位置相对于头文件的偏移量，称为文件偏移地址（File Offset）或物理地址（RAW Offset）。文件偏移地址从PE文件的第一个字节开始计数，起始值为0。 虚拟地址是指当PE文件装入内存时，各数据在内存中的位置。当PE文件通过Windows加载器被装入内存后，内存中的版本被称作模块（Module）。映射文件的起始地址被称为模块句柄（hModule），可以通过模块句柄访问内存中其他的数据结构。这个初始内存地址就称为基地址（ImageBase）。基地址的值是由PE文件本身设定的。按照默认设置，Visual C++建立的EXE文件基地址是00400000h，DLL文件基地址是10000000h。 相对虚拟地址（RVA）只是内存中的一个简单的相对于PE文件装入地址的偏移位置，它是一个“相对”地址，或称“偏移量”。因为尽管PE文件有一个首选的装入地址，但是并非一定会装入指定的位置，在这种情况下需要根据实际的装入位置重新定位，这就需要各部分相对于基地址的偏移量。图2显示了PE文件在装入前后的相对位置变化。 虚拟地址（VA）=基地址（ImageBase）+ 相对虚拟地址（RVA） 3 MS-DOS头部 3.1 DOS MZ header 每个PE文件都由一个DOS头开始的，DOS头包括两部分：“DOS MZ header”和“DOS stub”。PE文件的第一个字节起始于一个传统的MS_DOS头部，被称作IMAGE_DOS_HEADER，其结构如下： typedef struct _IMAGE_DOS_HEADER { WORD e_magic; WORD e_cblp; WORD e_cp; WORD e_crlc; WORD e_cparhdr; WORD e_minalloc; WORD e_maxalloc; WORD e_ss; WORD e_sp; WORD e_csum; WORD e_ip; WORD e_cs; WORD e_lfarlc; WORD e_ovno; WORD e_res[4]; WORD e_oemid; WORD e_oeminfo; WORD e_res2[10]; LONG e_lfanew; } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;此结构中，有两个字段比较重要，分别是e_magic和e_lfanew字段，e_magic被设置为5A4Dh，在winnt.h中定义为IMAGE_DOS_SIGNATURE，它的ASCⅡ值为“MZ”。 3.2 DOS stub DOS stub实际上是一个有效的EXE，在不支持PE文件格式的操作系统中，它简单显示一个错误提示“This program cannot be run in MS-DOS mode”。程序员也可以根据自己的意图写出完整的DOS代码。 图1 PE文件的框架结构图2 PE文件磁盘与内存映像结构图