深入理解PE文件格式：Win32可移植可执行文件探索

95 浏览量更新于2024-07-14 收藏 598KB PDF 举报

"这篇文章是关于Win32可移植可执行（PE）文件格式的深入探讨，由Matt Pietrek撰写，并在1994年的微软系统期刊上发表。文章介绍了PE文件格式的重要细节，该格式是微软为其Win32平台如Windows NT和Win32s设计的。" Win32 Portable Executable (PE) 文件格式是微软操作系统中的核心组件，用于存储编译后的程序代码和数据。这种文件格式是Win32 API的基础，它允许应用程序在不同的Windows系统上运行，因此称为“可移植”。PE文件格式不仅包含程序的机器码，还包含了运行时所需的元数据，如导入和导出函数、资源、符号表等。在PE文件中，有几个关键部分组成： 1. **DOS头**：虽然现在大多数Windows系统不再依赖MS-DOS，但PE文件仍保留了一个简化的DOS头，以便在不支持PE格式的DOS环境下进行简单的识别和处理。 2. **PE签名**：紧随DOS头之后的是PE签名（"PE\0\0"），标识这是一个PE文件。 3. **COFF（Common Object File Format）头**：这部分提供了关于文件的基本信息，如目标体系结构、文件类型（可执行文件、动态链接库等）以及节（section）的布局。 4. **PE头**：PE头包含了更详细的元数据，如程序入口点、基地址、节表、加载配置信息等。PE头分为两部分：文件头和可选头。 - **文件头**（File Header）提供了文件的基本属性，如是否为可执行文件、目标处理器类型、文件大小等。 - **可选头**（Optional Header）提供了运行时的信息，如映像基地址、子系统类型、DLL特性、数据目录等。 5. **节表**：PE文件由多个节组成，每个节包含特定类型的代码或数据。例如，".text"节通常包含已编译的代码，而".data"节则存储全局变量和初始化数据。 6. **数据目录**：数据目录列出了一些重要的结构，如导入表（Import Table）、导出表（Export Table）、资源表（Resource Table）、异常处理表（Exception Table）等。这些表格指示了程序如何与其他模块交互和使用系统资源。 7. **节体**：每个节的实际内容，包括代码、数据、资源和其他元数据。理解PE文件格式对于调试、逆向工程、软件安全分析以及系统编程都至关重要。通过研究PE文件，程序员和系统工程师可以更好地了解程序的内部工作原理，如何与操作系统交互，以及如何优化和调整程序以提高性能和兼容性。此外，对PE格式的深入理解也有助于识别和防止恶意软件，因为许多病毒和木马都会利用PE文件格式的特性来隐藏其行为。

This is in marked contrast to the situation in 16-bit Windows. The 16-bit NE file loader reads in portions of the file and creates completely different data structures to represent the module

in memory. When a code or data segment needs to be loaded, the loader has to allocate a new segment from the global heap, find where the raw data is stored in the executable file, seek

to that location, read in the raw data, and apply any applicable fixups. In addition, each 16-bit module is responsible for remembering all the selectors it's currently using, whether the

segment has been discarded, and so on.

For Win32, all the memory used by the module for code, data, resources, import tables, export tables, and other required module data structures is in one contiguous block of memory. All

you need to know in this situation is where the loader mapped the file into memory. You can easily find all the various pieces of the module by following pointers that are stored as part of

the image.

Another idea you should be acquainted with is the Relative Virtual Address (RVA). Many fields in PE files are specified in terms of RVAs. An RVA is simply the offset of some item, relative to

where the file is memory-mapped. For example, let's say the loader maps a PE file into memory starting at address 0x10000 in the virtual address space. If a certain table in the image starts

at address 0x10464, then the table's RVA is 0x464.

To convert an RVA into a usable pointer, simply add the RVA to the base address of the module. The base address is the starting address of a memory-mapped EXE or DLL and is an

important concept in Win32. For the sake of convenience, Windows NT and Windows 95 uses the base address of a module as the module's instance handle (HINSTANCE). In Win32, calling

the base address of a module an HINSTANCE is somewhat confusing, because the term "instance handle" comes from 16-bit Windows. Each copy of an application in 16-bit Windows gets

its own separate data segment (and an associated global handle) that distinguishes it from other copies of the application, hence the term instance handle. In Win32, applications don't

need to be distinguished from one another because they don't share the same address space. Still, the term HINSTANCE persists to keep continuity between 16-bit Windows and Win32.

What's important for Win32 is that you can call GetModuleHandle for any DLL that your process uses to get a pointer for accessing the module's components.

The final concept that you need to know about PE files is sections. A section in a PE file is roughly equivalent to a segment or the resources in an NE file. Sections contain either code or

data. Unlike segments, sections are blocks of contiguous memory with no size constraints. Some sections contain code or data that your program declared and uses directly, while other

data sections are created for you by the linker and librarian, and contain information vital to the operating system. In some descriptions of the PE format, sections are also referred to as

objects. The term object has so many overloaded meanings that I'll stick to calling the code and data areas sections.

The PE Header

Like all other executable file formats, the PE file has a collection of fields at a known (or easy to find) location that define what the rest of the file looks like. This header contains information

such as the locations and sizes of the code and data areas, what operating system the file is intended for, the initial stack size, and other vital pieces of information that I'll discuss shortly. As

with other executable formats from Microsoft, this main header isn't at the very beginning of the file. The first few hundred bytes of the typical PE file are taken up by the MS-DOS stub. This

stub is a tiny program that prints out something to the effect of "This program cannot be run in MS-DOS mode." So if you run a Win32-based program in an environment that doesn't

support Win32, you'll get this informative error message. When the Win32 loader memory maps a PE file, the first byte of the mapped file corresponds to the first byte of the MS-DOS stub.

That's right. With every Win32-based program you start up, you get an MS-DOS-based program loaded for free!

As in other Microsoft executable formats, you find the real header by looking up its starting offset, which is stored in the MS-DOS stub header. The WINNT.H file includes a structure

definition for the MS-DOS stub header that makes it very easy to look up where the PE header starts. The e_lfanew field is a relative offset (or RVA, if you prefer) to the actual PE header. To

get a pointer to the PE header in memory, just add that field's value to the image base:

Once you have a pointer to the main PE header, the fun can begin. The main PE header is a structure of type IMAGE_NT_HEADERS, which is defined in WINNT.H. This structure is composed

of a DWORD and two substructures and is laid out as follows:

The Signature field viewed as ASCII text is "PE\0\0". If after using the e_lfanew field in the MS-DOS header, you find an NE signature here rather than a PE, you're working with a 16-bit

Windows NE file. Likewise, an LE in the signature field would indicate a Windows 3.x virtual device driver (VxD). An LX here would be the mark of a file for OS/2 2.0.

Following the PE signature DWORD in the PE header is a structure of type IMAGE_FILE_HEADER. The fields of this structure contain only the most basic information about the file. The

structure appears to be unmodified from its original COFF implementations. Besides being part of the PE header, it also appears at the very beginning of the COFF OBJs produced by the

Microsoft Win32 compilers. The fields of the IMAGE_FILE_HEADER are shown in Table 2.

Table 2. IMAGE_FILE_HEADER Fields

The CPU that this file is intended for. The following CPU IDs are defined:

0x14d Intel i860

0x14c Intel I386 (same ID used for 486 and 586)

0x162 MIPS R3000

0x166 MIPS R4000

(Virtual address 0x10464)(base address 0x10000) = RVA 0x00464

// Ignoring typecasts and pointer conversion issues for clarity...

pNTHeader = dosHeader + dosHeader>e_lfanew;

DWORD Signature;

IMAGE_FILE_HEADER FileHeader;

IMAGE_OPTIONAL_HEADER OptionalHeader;

Page

Peering Inside the PE: A Tour of the Win32 Portable Executable File Format

11/

17/

2015

https://msdn.microsoft.com/en

us/library/ms809762(d=printer).aspx

剩余16页未读，继续阅读

weixin_38678022

粉丝: 1
资源: 950

深入理解PE文件格式：Win32可移植可执行文件探索

解析Win32 PE文件：操作系统的映射与应用

Win32可移植可执行（PE）文件格式深度解析

"Ceph数据迁移之美：深度理解Peering过程

Peering Inside the PE - A Tour of the Win32 Portable Executable File Format - MSDN (1994)-计算机科学

Peering Inside the PE

探索PE文件内幕(Peering_Inside_the_PE)

ESET_Carbon-Paper-Peering-into-Turlas-second-stage-backdoor(03-30-2017).pdf

terraform-aws-vpc-peering-multi-account：Terraform模块，可通过使用多个提供程序在不同帐户中的多个VPC之间提供对等VPC

IPM - Internet Peering Maps-开源

OSP peering module-开源

最新资源