pe 文件(pe文件下载)

就是再次重复撰写pe文件的意思。 1、EXE文件是属于PE文件的一种。2、PE文件的全称是Portable Executable，意为可移植的执行体是，常见的EXE、DLL、OCX、SYS、COM都是PE文件，PE文件是微软Windows操作系统上的程序文件（可能是间接被执行，如DLL）3、一个操作系统的可执行文件格式在很多方面是这个系统的一面镜子。虽然学习一个可执行文件格式通常不是一个程序员的首要任务，但是可以从这其中学到大量的知识。4、 Microsoft 的所有基于win32系统（如winnt,win9x）的可移植可执行（PE）文件格式的详细介绍。在可预知的未来，包括Windows2000, PE文件格式在 MicroSoft 的操作系统中扮演一个重要的角色。 5、如果在使用 Win32 或 Winnt ，那么已经在使用 PE 文件了。甚至只是在 Windows3.1 下使用 Visual C++编程，使用的仍然是 PE 文件（Visual C++ 的 32 位MS-DOS扩展组件用这个格式）。简而言之，PE 格式已经普遍应用，并且在不短的将来仍是不可避免的。

一个操作系统的可执行文件格式在很多方面是这个系统的一面镜子。虽然学习一个可执行文件格式通常不是一个程序员的首要任务，但是你可以从这其中学到大量的知识。在这篇文章中，我会给出 Microsoft 的所有基于win32系统（如winnt,win9x）的可移植可执行（PE）文件格式的详细介绍。在可预知的未来，包括Windows2000, PE文件格式在 MicroSoft 的操作系统中扮演一个重要的角色。如果你在使用 Win32 或 Winnt ，那么你已经在使用 PE 文件了。甚至你只是在 Windows3.1 下使用 Visual C++编程，你使用的仍然是 PE 文件（Visual C++ 的 32 位MS-DOS扩展组件用这个格式）。简而言之，PE 格式已经普遍应用，并且在不短的将来仍是不可避免的。现在是时候找出这种新的可执行文件格式为操作系统带来的东西了。 我最后不会让你盯住无穷无尽的十六进制Dump，也不会详细讨论页面的每一个单独的位的重要性。代替的，我会向你介绍包含在 PE 文件中的概念，并且将他们和你每天都遇到的东西联系起来。比如，线程局部变量的概念，如下所述：declspec(thread) int i;我快要发疯了，直到我发现它在可执行文件中实现起来是如此的简单并且优雅。既然你们中的许多人都有使用 16 Windows 的背景，我将把 Win32 PE 文件的构造追溯到和它等价的16 位 NE 文件。除了一个不同的可执行文件格式， MicroSoft 还引入了一个用它的编译器和汇编器生成的新的目标模块格式。这个新的 OBJ 文件格式有许多和PE 文件共同的东东。我做了许多无用功去查找这个新的OBJ 文件格式的文档。所以我以自己的理解对它进行解析，并且，在这里，除了 PE 文件，我会描述它的一部分。 大家都知道，Windows NT继承了 VAX? VMS? 和 UNIX? 的传统。许多 Windows NT 的创始人在进入微软前都在这些平台上进行设计和编码。当他们开始设计 Windows NT 时，很自然的，为了最小化项目启动时间，他们会使用以前写好的并且已经测试过的工具。用这些工具生成的并且工作的可执行和 OBJ 文件格式叫做 COFF （Common Object File Format 的首字母缩写）。COFF 的相对年龄可以用八进制的域来指定。COFF 本身是一个好的起点，但是需要扩展到一个现代操作系统如 Windows 95 和 Windows NT 的需要。这个更新的结果就是（PE格式）可移植可执行文件格式。它被称为可移植的是因为在所有平台（如x86,Alpha,MIPS等等）上实现的WindowsNT 都使用相同的可执行文件格式。当然了，也有许多不同的东西如二进制代码的CPU指令。重要的是操作系统的装入器和程序设计工具不需要为任何一种CPU完全重写就能达到目的。MicroSoft 抛弃现存的32位工具和可执行文件格式的事实证实了他们想让 WindowsNT 升级并且运行的更快的决心。为16位Windows编写的虚拟设备驱动程序用一种不同的32位文件布局--LE文件格式--WindowsNT出现很早以前就存在了。比这更重要的是对 OBJ 文件的替换！在 WindowsNT 的 C编译器以前，所有的微软编译器都用 Intel 的 OMF ( Object Module Format ) 规范。就像前面提到的，MicroSoft 的 Win32编译器生成 COFF 格式的 OBJ 文件。一些微软的竞争者，如 Borland 和 Symentec ，选择放弃了 COFF 格式并坚持 Intel 的 OMF文件格式。这样的结果是制作 OBJ 和 LIB 的公司为了使用多个不同的编译器，不得不为每个不同的编译器分发这些库的不同版本（如果他们不这么做）。PE 文件格式在 winnt.h 头文件中文档化了（用最不精确的语言）!大约在 winnt.h 的中间部分标题为Image Format的一个块。在把 MS-DOS 的 MZ文件头和 NE 文件头移入新的PE文件头之前，这个块就开始于一个小栏。WINNT.H提供PE文件用到的生鲜数据结构的定义，但只有很少有助于理解这些数据结构和标志变量的注释。不管谁为PE文件格式写出这样的头文件都肯定是一个信徒无疑（突然持续地冒出Michael J. O'Leary的名字来）。描述名字，连同深嵌的结构体和宏。当你配套winnt.h进行编码时，类似下面这样的表达式并不鲜见：pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_DEBUG].VirtualAddress;为了有助于逻辑的理解这些winnt.h中的信息，阅读可移植可执行和公共对象文件格式的规格说明，这些在MSDN既看光盘中是可用的，一直包括到2001年8月。现在让我们转换到COFF格式的OBJ文件的主体上来，WINNT.H包括COFF OBJ和LIB的结构化定义和类型定义。不幸的是，我还没有找到上面提到的可执行文件格式的类似文档。既然PE文件和COFF OBJ文件是如此的相似，我决定是时间把这些文件带到重点上来，并且把它们也文档化。仅仅读过了关于PE文件的组成，你自己也想Dump一些PE文件来看这些概念。如果你用微软基于32位WINDOWS的开发工具，DUMPBIN 程序可以将PE文件和COFF OBJ/LIB文件转化为可读的形式。在所有的PEDump器中，DUMPBIN是最容易理解的。它恰好有一些很好的选项来反汇编它正解析的文件的代码块，Borland用户可以使用tdump来浏览PE文件，但tdump不能解析 COFF OBJ/LIB 文件。这不是一个重要的东西因为Borland的编译器首先就不生成 COFF 格式的OBJ文件。我写了一个PE和COFF OBJ 文件的Dump程序--PEDUMP，我想提供一些比DUMPBIN更加可理解的输出。虽然它没有反汇编器以及和LIB库文件一起工作，它在其他方面和DUMPBIN是一样的，并且加入了一些新的特性来使它值得被认同。它的源代码在任何一个MSJ电子公报版上都可以找到，所有我不打算在这里把他全部列出。作为代替，我展示一些从PEDUMP得到的示例输出来阐明我为它们描述的概念。译注：--说实话，我从这这份代码中几乎唯一学到的东西就是如何处理命令行，其它的都没学到。 表 1 PEDUMP.Cfile://--------------------/// PROGRAM: PEDUMP// FILE: PEDUMP.C// AUTHOR: Matt Pietrek - 1993file://--------------------/#include #include #include objdump.h#include exedump.h#include extrnvar.h// Global variables set here, and used in EXEDUMP.C and OBJDUMP.CBOOL fShowRelocations = FALSE;BOOL fShowRawSectionData = FALSE;BOOL fShowSymbolTable = FALSE;BOOL fShowLineNumbers = FALSE;char HelpText[] =PEDUMP - Win32/COFF .EXE/.OBJ file dumper - 1993 Matt PietreknnSyntax: PEDUMP [switches] filenamenn /A include everything in dumpn /H include hex dump of sectionsn /L include line number informationn /R show base relocationsn /S show symbol tablen;// Open up a file, memory map it, and call the appropriate dumping routinevoid DumpFile(LPSTR filename)HANDLE hFile;HANDLE hFileMapping;LPVOID lpFileBase;PIMAGE_DOS_HEADER dosHeader;hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);if ( hFile = = INVALID_HANDLE_VALUE ){ printf(Couldn't open file with CreateFile()n);return; }hFileMapping = CreateFileMapping(hFile, NULL,PAGE_READONLY, 0, 0, NULL);if ( hFileMapping = = 0 ){CloseHandle(hFile);printf(Couldn't open file mapping with CreateFileMapping()n);return;lpFileBase = MapViewOfFile(hFileMapping, FILE_MAP_READ, 0, 0, 0);if ( lpFileBase = = 0 )CloseHandle(hFileMapping);CloseHandle(hFile);printf(Couldn't map view of file with MapViewOfFile()n);return;printf(Dump of file %snn, filename);dosHeader = (PIMAGE_DOS_HEADER)lpFileBase;if ( dosHeader->e_magic = = IMAGE_DOS_SIGNATURE ){ DumpExeFile( dosHeader ); }else if ( (dosHeader->e_magic = = 0x014C) // Does it look like a i386&& (dosHeader->e_sp = = 0) ) // COFF OBJ file???// The two tests above aren't what they look like. They're// really checking for IMAGE_FILE_HEADER.Machine = = i386 (0x14C)// and IMAGE_FILE_HEADER.SizeOfOptionalHeader = = 0;DumpObjFile( (PIMAGE_FILE_HEADER)lpFileBase );elseprintf(unrecognized file formatn);UnmapViewOfFile(lpFileBase);CloseHandle(hFileMapping);CloseHandle(hFile);// process all the command line arguments and return a pointer to// the filename argument.PSTR ProcessCommandLine(int argc, char *argv[])int i;for ( i=1; i < argc; i++ )strupr(argv);// Is it a switch character?if ( (argv[0] = = '-') || (argv[0] = = '/') )if ( argv[1] = = 'A' ){ fShowRelocations = TRUE;fShowRawSectionData = TRUE;fShowSymbolTable = TRUE;fShowLineNumbers = TRUE; }else if ( argv[1] = = 'H' )fShowRawSectionData = TRUE;else if ( argv[1] = = 'L' )fShowLineNumbers = TRUE;else if ( argv[1] = = 'R' )fShowRelocations = TRUE;else if ( argv[1] = = 'S' )fShowSymbolTable = TRUE;else // Not a switch character. Must be the filename{ return argv; }int main(int argc, char *argv[])PSTR filename;if ( argc = = 1 ){ printf( HelpText );return 1; }filename = ProcessCommandLine(argc, argv);if ( filename )DumpFile( filename );return 0;}

你能把问题说 具体点吗？EXE文件是 文件名后缀是 .exe 结尾的 你所说的PE文件 是不是 文件名后缀以 .pe结尾的吗？ PE格式，是微软Win32环境可执行文件的标准格式(所谓可执行文件不光是.EXE文件,还包括.DLL/.VXD/.SYS/.VDM等)。PE 就是Portable Executable 的缩写，PE文件衍生于早期建立在VAX/VMS上的COFF(Common Object File Format)文件格式。Portable 是指对于不同的Windows版本和不同的CPU类型上PE文件的格式是一样的，当然CPU不一样了，CPU指令的二进制编码是不一样的。只是文件中各种东西的布局是一样的。 　　PE文件使用的是一个平面地址空间，所有代码和数据都合并在一起，组成一个很大的结构。主要有： 　　.text 是在编译或汇编结束时产生的一种块，它的内容全是指令代码 　　.rdata 是运行期只读数据 　　.data　是初始化的数据块 　　.idata 包含其它外来DLL的函数及数据信息，即输入表 　　.rsrc 包含模块的全部资源：如图标、菜单、位图等 还有种是PE系统是 简化了的 windows 系统
PE文件是微软专业的操作系统的一种程序文件，EXE文件是PE文件的一种。 PE文件的全称是Portable Executable，意为可移植的执行体是，常见的EXE、DLL、OCX、SYS、COM都是PE文件。PE包括Windows2000, PE文件格式在 MicroSoft 的操作系统中扮演一个重要的角色。所以PE文件是WIndows操作系统的一种重要的程序文件。

关于PE文件最重要的是，磁盘上的可执行文件和它被WINDOWS调入内存之后是非常相像的。WINDOWS载入器不必为从磁盘上载入一个文件而辛辛苦苦创建一个进程。载入器使用内存映射文件机制来把文件中相似的块映射到虚拟空间中。用一个构造式的分析模型，一个PE文件类似一个预制的屋子。它本质上开始于这样一个空间，这个空间后面有几个把它连到其余空间的机件（就是说，把它联系到它的DLL上，等等）。这对PE格式的DLL是一样容易应用的。一旦这个模块被载入，Windows 就可以有效的把它和其它内存映射文件同等对待。和16位Windows不同的是。16位NE文件的载入器读取文件的一部分并且创建完全不同的数据结构在内存中表示模块。当数据段或者代码段需要载入时，载入器必须从全局堆中新申请一个段，从可执行文件中找出生鲜数据，转到这个位置，读入这些生鲜数据，并且要进行适当的修正。除此而外，每个16位模块都有责任记住当前它使用的所有段选择器，而不管这个段是否被丢弃了，如此等等。对Win32来讲，模块所使用的所有代码，数据，资源，导入表，和其它需要的模块数据结构都在一个连续的内存块中。在这种形势下，你只需要知道载入器把可执行文件映射到了什么地方。通过作为映像的一部分的指针，你可以很容易的找到这个模块所有不同的块。 另一个你需要知道的概念是相对虚拟地址（RVA）。PE文件中的许多域都用术语RVA来指定。一个RVA只是一些项目相对于文件映射到内存的偏移。比如说，载入器把一个文件映射到虚拟地址0x10000开始的内存块。如果一个映像中的实际的表的首址是0x10464，那么它的RVA就是0x464。（虚拟地址 0x10464）－（基地址 0x10000）=RVA 0x00464为了把一个RVA转化成一个有用的指针，只需要把RVA值加到模块的基地址上即可。基地址是内存映射EXE和DLL文件的首址，在Win32中这是一个很重要的概念。为了方便起见，WindowsNT 和 Windows9x用模块的基地址作为这个模块的实例句柄（HINSTANCE）。在Win32中，把模块的基地址叫做HINSTANCE可能导致混淆，因为术语实例句柄来自16位Windows。一个程序在16位Windows中的每个拷贝得到它自己分开的数据段（和一个联系起来的全局句柄）来把它和这个程序其它的拷贝分别开来，就形成了术语实例句柄。在Win32中，每个程序不必和其它程序区别开来，因为他们不共享相同的地址空间。术语INSTANCE仍然保持16位windows和32位Windows之间的连续性。在Win32中重要的是你可以对任何DLL调用GetModuleHandle()得到一个指针去访问它的组件（译注）。 如果 dllname 为 NULL，则得到执行体自己的模块句柄。这是非常有用的，如通常编译器产生的启动代码将取得这个句柄并将它作为一个参数hInstance传给WinMain ！你最终需要理解的PE文件的概念是块（Section）。PE文件中的一个块和NE文件中的一个段或者资源等价。块可以包含代码或者数据。和段不同的是，块是内存中连续的空间，而没有尺寸限制。当你的连接器和库为你建立，并且包含对操作系统非常重要的信息的其它的数据块时，这些块包含你的程序直接声明和使用的代码或数据。在一些PE格式的描述中，块也叫做对象。术语对象有如此多的涵义，以至于只能把代码和数据叫做块。

PE教程1: PE文件格式一览 考虑到早期写的PE教程1是自己所有教程中最糟糕的一篇，此番决心彻底重写一篇以飨读者。 PE 的意思就是 Portable Executable（可移植的执行体）。它是 Win32环境自身所带的执行体文件格式。它的一些特性继承自 Unix的 Coff (common object file format)文件格式。"portable executable"（可移植的执行体）意味着此文件格式是跨win32平台的 : 即使Windows运行在非Intel的CPU上，任何win32平台的PE装载器都能识别和使用该文件格式。当然，移植到不同的CPU上PE执行体必然得有一些改变。所有 win32执行体 (除了VxD和16位的Dll)都使用PE文件格式，包括NT的内核模式驱动程序（kernel mode drivers）。因而研究PE文件格式给了我们洞悉Windows结构的良机。 本教程就让我们浏览一下 PE文件格式的概要。 DOS MZ headerDOS stubPE headerSection tableSection 1Section 2Section ...Section n 上图是 PE文件结构的总体层次分布。所有 PE文件(甚至32位的 DLLs) 必须以一个简单的 DOS MZ header 开始。我们通常对此结构没有太大兴趣。有了它，一旦程序在DOS下执行，DOS就能识别出这是有效的执行体，然后运行紧随 MZ header 之后的 DOS stub。DOS stub实际上是个有效的 EXE，在不支持 PE文件格式的操作系统中，它将简单显示一个错误提示，类似于字符串 "This program requires Windows" 或者程序员可根据自己的意图实现完整的 DOS代码。通常我们也不对 DOS stub 太感兴趣: 因为大多数情况下它是由汇编器/编译器自动生成。通常，它简单调用中断21h服务9来显示字符串"This program cannot run in DOS mode"。 紧接着 DOS stub 的是 PE header。 PE header 是PE相关结构 IMAGE_NT_HEADERS 的简称，其中包含了许多PE装载器用到的重要域。当我们更加深入研究PE文件格式后，将对这些重要域耳目能详。执行体在支持PE文件结构的操作系统中执行时，PE装载器将从 DOS MZ header 中找到 PE header 的起始偏移量。因而跳过了 DOS stub 直接定位到真正的文件头 PE header。 PE文件的真正内容划分成块，称之为sections（节）。每节是一块拥有共同属性的数据，比如代码/数据、读/写等。我们可以把PE文件想象成一逻辑磁盘，PE header 是磁盘的boot扇区，而sections就是各种文件，每种文件自然就有不同属性如只读、系统、隐藏、文档等等。 值得我们注意的是 ---- 节的划分是基于各组数据的共同属性: 而不是逻辑概念。重要的不是数据/代码是如何使用的，如果PE文件中的数据/代码拥有相同属性，它们就能被归入同一节中。不必关心节中类似于"data", "code"或其他的逻辑概念: 如果数据和代码拥有相同属性，它们就可以被归入同一个节中。（译者注：节名称仅仅是个区别不同节的符号而已，类似"data", "code"的命名只为了便于识别，惟有节的属性设置决定了节的特性和功能）如果某块数据想付为只读属性，就可以将该块数据放入置为只读的节中，当PE装载器映射节内容时，它会检查相关节属性并置对应内存块为指定属性。 如果我们将PE文件格式视为一逻辑磁盘，PE header是boot扇区而sections是各种文件，但我们仍缺乏足够信息来定位磁盘上的不同文件，譬如，什么是PE文件格式中等价于目录的东东？别急，那就是 PE header 接下来的数组结构 section table（节表）。 每个结构包含对应节的属性、文件偏移量、虚拟偏移量等。如果PE文件里有5个节，那么此结构数组内就有5个成员。因此，我们便可以把节表视为逻辑磁盘中的根目录，每个数组成员等价于根目录中目录项。 以上就是PE文件格式的物理分布，下面将总结一下装载一PE文件的主要步骤: 当PE文件被执行，PE装载器检查 DOS MZ header 里的 PE header 偏移量。如果找到，则跳转到 PE header。PE装载器检查 PE header 的有效性。如果有效，就跳转到PE header的尾部。紧跟 PE header 的是节表。PE装载器读取其中的节信息，并采用文件映射方法将这些节映射到内存，同时付上节表里指定的节属性。PE文件映射入内存后，PE装载器将处理PE文件中类似 import table（引入表）逻辑部分。上述步骤是基于本人观察后的简述，显然还有一些不够精确的地方，但基本明晰了执行体被处理的过程。 其它看这里~ http://www.pediy.com/tutorial/chap8/Chap8-1-1.htm
DLL文件即动态链接库文件，是一种可执行文件，它允许程序共享执行特殊任务所必需的代码和其他资源。Windows提供的DLL文件中包含了允许基于Windows的程序在Windows环境下操作的许多函数和资源。 DLL多数情况下是带有DLL扩展名的文件，但也可能是EXE或其他扩展名。它们向运行于Windows操作系统下的程序提供代码、数据或函数。程序可根据DLL文件中的指令打开、启用、查询、禁用和关闭驱动程序。 DLL的全称是Dynamic Link Library, 中文叫做“动态链接文件”。在Windows操作系统中, DLL对于程序执行是非常重要的, 因为程序在执行的时候, 必须链接到DLL文件, 才能够正确地运行。而有些DLL文件可以被许多程序共用。因此, 程序设计人员可以利用DLL文件, 使程序不至于太过巨大。但是当安装的程序越来越多, DLL文件也就会越来越多, 如果当你删除程序的时候, 没有用的DLL文件没有被删除的话, 久而久之就造成系统的负担了。 DLL是动态连接库。使用动态连接库的一些好处是：1.多个应用程序共享代码和数据：比如Office软件的各个组成部分有相似的外观和功能，这就是通过共享动态连接库实现的。2.在钩子程序过滤系统消息时必须使用动态连接库。3.动态连接库以一种自然的方式将一个大的应用程序划分为几个小的模块，有利于小组内部成员的分工与合作。而且，各个模块可以独立升级。如果小组中的一个成员开发了一组实用例程，他就可以把这些例程放在一个动态连接库中，让小组的其他成员使用。4.为了实现应用程序的国际化，往往需要使用动态连接库。使用动态连接库可以将针对某一国家、语言的信息存放在其中。对于不同的版本，使用不同的动态连接库。在使用AppWizard生成应用程序时，我们可以指定资源文件使用的语言，这就是通过提供不同的动态连接库实现的。VC++、C++ Builder、Delphi都可以编写DLL文件。Visual Basic 5.0以上版本也可以编写一种特殊的DLL，即ActiveX DLL。 DLL不是独立运行的程序，它是某个程序的一个部分，它只能由所属的程序调用。用户不能，也不需要打开它。