PE文件头解析大全

合集下载

PE文件结构详解 超详细 C代码

PE文件结构详解 超详细 C代码

翻译:Jason Sun(木水鱼).2004年5月10日[译注:仅供大家学习使用,您在复制或使用此文档时请保留这个文件头]Peering Inside the PE: A Tour of the Win32 Portable Executable File FormatMatt Pietrek1994 年3月Matt Pietrek 是Windows Internals (Addison-Wesley, 1993)的作者。

他就职于Nu-Mega 技术有限公司,可通过CompuServe: 71774,362联系到他。

这篇文章出自1994年3月发行的Microsoft系统期刊。

版权所有﹫1994 Miller Freeman, Inc.保留所有权利。

未经Miller Freeman同意,这篇文章的任何部分不得以任何形式被复制(除了在评论文章里以摘要引用)。

一个操作系统的可执行文件的格式在很多方面是这个操作系统的一面镜子。

虽然学习一个可执行文件格式不是大多数程序员的首要任务,但是从中你可学到大量的知识。

这篇文章中,我将给出Microsoft为他们的基于Win32的系统所设计的PE文件格式的详细说明。

可以预知在未来,PE文件格式在Microsoft的所有操作系统包括Windows 2000中都将扮演着很重要的角色。

如果你在使用Win32s或WinNT,那么你已经在使用PE文件了。

甚至你只是在Windows3.1下用Visual C++编程,你也已在使用PE文件了(Visual C++的32位DOS扩展组件使用此格式)。

简而言之,PE格式已得到普遍应用并且在不短的将来也不会取消。

现在是时间找出这种新的可执行文件格式为操作系统所带来的影响了。

我不会让你盯住无穷无尽的16进制Dumps和详细讨论页面中每个单独位的重要性。

代替的,我将介绍PE文件格式中内含的概念并且把它们和你每天都会遇到的东西联系起来。

例如,线程局部变量的概念,比如declspec(thread) int i;它使我快要发疯了,直到我明白它是怎样在可执行文件里优雅而简单的实现的。

PE格式揭秘

PE格式揭秘

这是我在我的电脑上随便找了个exe文件,下面我将会仔细的分析一下这种文件的格式下面我依次截图,仔细分析,让你看清楚:首先4D 5A 90 这三个一般是在一起的,我们知道windows文件是从DOS兼容过来的,这三个数其实就是M Z 和一个分隔符是为了兼容以前DOS下的MZ文件好:我找了两个文件通过比较发现,从0x 00 00 00 80处开始不一样,也就是在这之前从0x 00 00 00 00到0x00 00 00 7F是相同的DOS头和DOS桩程序,其实,MZ_DOS在PE 文件中占64个字节,就是我们看到的前4行数据(每行16个字节),而在微软给我们提供的DOS头结构体中有各个部分的结构:Typedef struct _IMAGE_DOS_HEADER{USHORT e_magic; //00H魔术数字就是0x 4D 5A = MZ;USHORT e_cblp; // 02H 表示的是文件最后页(page)中的字节数;USHORT e_cb ; / 04H 文件的页数(每页大小4KB);USHORT e_crlc ; //06H重新定向的元素个数;USHORT e_parhdr //08H 头部大小,以段(paragraph)为单位;USHORT e_minalloc //0AH 所需要的最小附加段;USHORT e_maxalloc //0CH 所需要的最大附加段;USHORT e_ss //0EH 初始的ss值;USHORT e_sp //10H 初始的sp值;USHORT e_csum //12H 校验和或者0USHORT e_ip //14H 初始的IP值USHORT e_cs //16H 初始的CS值(相对偏移量)USHORT e_lfarlc //18H 重定向表文件地址USHORT e_ovno //1AH 覆盖号USHORT e_res[4] 1CH 保留字USHORT e_oemid //24H OEM标示符(for e_oeminfo)USHORT e_oeminfo //26H OEM信息USHORT e_res2[10] //28H 保留LONG e_lfanew; //3CH PE头位置//这个位置很重要,做病毒要这个东西} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER上边就是我的一个exe文件的DOS头(不包括DOS桩,紧跟在它的下面),下面是我的分析0x4D 5A 魔术字符MZ0x00 90(144字节) 文件最后一页的字节数地址为20x00 03 文件总页数用这两个计算出文件总大小(3-1)*4028+144=82000x00 00 重定向元素个数0x00 04 头部大小,以段为单位0x00 00 所需要的最小附加段0xFF FF 所需要的最大附加段0x00 00 加载时ss段寄存器的值0x00 B8 加载时sp的值0x00 00 校验和或者为00x00 00 初始IP值0x00 00 初始CS值0x00 40 重定位表文件地址0x00 00 覆盖号0x0000 0000 0000 0000保留的四个字0x00 00 OEM标识0x00 00 OEM信息0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 保留10个字0x00 00 00 D0 PE头开始的地址地址为3C上边指需要记住两处,但是别的地方最好是也记住。

PE文件解析-PE头解析-1-文件头,PE头

PE文件解析-PE头解析-1-文件头,PE头

PE⽂件解析-PE头解析-1-⽂件头,PE头PE⽂件解析-PE头解析PE头⼜叫NT头,是PE⽂件真正的头部,DOS头只是⽤来为了兼容以前的DOS系统。

PE头位于DOS Stub后⾯,以PE00作为起始标记类似于DOS头的MZDOS StubDOS Stub就是DOS头结束到PE头的开始中间的区域,基本上是垃圾区域没啥⽤,但是加壳的时候可以⽤到。

NT/PE头typedef struct _IMAGE_NT_HEADERS {DWORD Signature;//PE标志,就是PE00IMAGE_FILE_HEADER FileHeader;//⽂件头,是另⼀个⽂件的结构体IMAGE_OPTIONAL_HEADER32 OptionalHeader;//可选PE头,也叫扩展头} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;⽂件头typedef struct _IMAGE_FILE_HEADER {WORD Machine;//程序允许的CPU型号,如果为0表⽰能在任何CPU上运⾏,如果是0x14c表⽰的是386以及后续的型号WORD NumberOfSections;//⽂件中存在的区段的数量DWORD TimeDateStamp;//时间戳DWORD PointerToSymbolTable;DWORD NumberOfSymbols;WORD SizeOfOptionalHeader;//可选PE头的⼤⼩32位默认是E0,64位默认是F0WORD Characteristics;//⽂件属性,每个位有不同的含义,} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;代码解析。

PE文件头简析及输入表、输出表的分析

PE文件头简析及输入表、输出表的分析

PE文件头简析及输入表、输出表的分析2008年01月13日星期日 22:50PE文件头简析及输入表、输出表的分析前两天由于做个免杀,需要对输入表做些改变,所以又重新看了pe文件的结构尤其是输入表及输出表的一些细节方面,做个笔记,方便自己以后翻看,也给大家提个方便,呵呵!1、PE文件格式文件尾___________________________________________________________________Code View调试信息 |COFF 符号表 | 调试信息COFF 行号 |------------------------------------------------------------------.reloc |.edata | 块(Section) .data |.text |---------------------------------------------------------------------------------------------------IMAGE_SECTION_HEADER |IMAGE_SECTION_HEADER | 块表(Section Table)IMAGE_SECTION_HEADER |IMAGE_SECTION_HEADER | //对应.text块---------------------------------------------------------------------------------------------------------数据目录表 | //包含在可选映像头中,包含输出\入表信息 IMAGE_OPTIONAL_HEADER32 | 可选映像头IMAGE_FILE_HEADER | 文件映像头"PE",0,0 | pe文件标识(pe文件头包含三个部分)---------------------------------------------------------------------------------------------------------DOS stub |DOS 'MZ' HEADER | 该字段中的e_lfanew字段指向pe头 ---------------------------------------------------------------------------------------------------------文件头说明:01、输入表、输出表的位置:在pe头中可选映像头字段中数据目录表字段中,相对于pe文件标识处的偏移分别为:+80h、+78h;(其中pe文件标识的位置在DOS 'MZ' HEADER字段中的e_lfanew指出,该字段相对于文件开始的偏移为+3Ch,4个字节);02、在用例子说明时用c32asm打开,其中的偏移均为文件在磁盘上存储的物理偏移,而查看的值均为给出的各个地址的RVA,转化方法入下:查到的RVA值-VOffset(可由lordpe查看)+ROffset 得到的就是可以c32asm中的偏移2、上面对pe文件格式做了简要介绍,下面主要分析输入表和输出表:输入表篇:概念不做介绍,位置上面已经给出,呵呵输入表的结构:输入表是以一个IMAGE_IMPORT_DESCRIPTOR(IID)数组开始,一个程序要调用几个dll就会有几个IID项,即每个IID对应于一个dllIID结构:IMAGE_IMPORT_DESCRIPTOR structunion{DWORD Characteristics ; ;00hDWORD OriginalFirstThunk; // 注释1};TimeDateStamp DWORD ;04h // 时间标志,可以忽略;ForwarderChain DWORD ;08h // 正向链接索引,一般为0,当程序引用一个dll中的api,而这个api又引用其它dll中的api时用;Name DWORD ;0Ch //DLL名字的指针,以00结尾的ASCII字符的RVA地址;FirstThunk DWORD ;10h // 注释2IMAGE_IMPORT_DESCRIPTOR ends注释 1:该值为一个 IMAGE_THUNK_DATA数组的RVA,其中的每个指针都指向IMAGE_IMPORT_BY_NAME结构。

深入剖析PE文件

深入剖析PE文件

深入剖析PE文件PE文件是Win32的原生文件格式.每一个Win32可执行文件都遵循PE文件格式.对PE文件格式的了解可以加深你对Win32系统的深入理解.一、基本结构。

上图便是PE文件的基本结构。

(注意:DOS MZ Header和部分PE header的大小是不变的;DOS stub部分的大小是可变的。

)一个PE文件至少需要两个Section,一个是存放代码,一个存放数据。

NT上的PE文件基本上有9个预定义的Section。

分别是:.text, .bss, .rdata, .data, .rsrc, .edata, .idata, .pdata, 和.debug。

一些PE文件中只需要其中的一部分Section.以下是通常的分类:l 执行代码Section , 通常命名为:.text (MS) or CODE (Borland)l 数据Section, 通常命名为:.data, .rdata, 或.bss(MS) 或DATA(Borland).资源Section, 通常命名为:.edatal 输入数据Section, 通常命名为:.idatal 调试信息Section,通常命名为:.debug这些只是命名方式,便于识别。

通常与系统并无直接关系。

通常,一个PE文件在磁盘上的映像跟内存中的基本一致。

但并不是完全的拷贝。

Windows加载器会决定加载哪些部分,哪些部分不需要加载。

而且由于磁盘对齐与内存对齐的不一致,加载到内存的PE文件与磁盘上的PE文件各个部分的分布都会有差异。

当一个PE文件被加载到内存后,便是我们常说的模块(Module),其起始地址就是所谓的HModule.二、DOS头结构。

所有的PE文件都是以一个64字节的DOS头开始。

这个DOS头只是为了兼容早期的DOS操作系统。

这里不做详细讲解。

只需要了解一下其中几个有用的数据。

1. e_magic:DOS头的标识,为4Dh和5Ah。

分别为字母MZ。

pe文件简单解释

pe文件简单解释
IMAGE_FILE_AGGRESIVE_WS_TRIM = $0010; // Agressively trim working set
IMAGE_FILE_LARGE_ADDRESS_AWARE = $0020; // App can handle >2gb addresses
IMAGE_FILE_BYTES_REVERSED_LO = $0080; // Bytes of machine word are reversed.
IMAGE_FILE_MACHINE_WCEMIPSV2 = $0169; // MIPS little-endian WCE v2
IMAGE_FILE_MACHINE_ALPHA = $0184; // Alpha_AXP
IMAGE_FILE_MACHINE_SH3 = $01a2; // SH3 little-endian
IMAGE_FILE_MACHINE_SH3E = $01a4; // SH3E little-endian
IMAGE_FILE_MACHINE_SH4 = $01a6; // SH4 little-endian
IMAGE_FILE_MACHINE_SH5 = $01a8; // SH5
IMAGE_FILE_MACHINE_MIPSFPU16 = $0466; // MIPS
// IMAGE_FILE_MACHINE_AXP64 IMAGE_FILE_MACHINE_ALPHA64
IMAGE_FILE_MACHINE_AMD64 = $0500; // AMD K8
IMAGE_FILE_MACHINE_TRICORE = $0520; // Infineon
// If Image is on removable media, copy and run from the swap file.

PE文件结构解析

PE文件结构解析

PE⽂件结构解析说明:本⽂件中各种⽂件头格式截图基本都来⾃看雪的《加密与解密》;本⽂相当《加密与解密》的阅读笔记。

1.PE⽂件总体结构PE⽂件框架结构,就是exe⽂件的排版结构。

也就是说我们以⼗六进制打开⼀个.exe⽂件,开头的那些内容就是DOS头内容,下来是PE头内容,依次类推。

如果能认识到这样的内含,那么“exe开头的内容是不是就直接是我们编写的代码”(不是,开头是DOS头内容)以及“我们编写的代码被编排到了exe⽂件的哪⾥”(在.text段,.text具体地址由其相应的IMAGE_SECTION_HRADER指出)此类的问题答案就显⽽易见了。

exe⽂件从磁盘加载到内存,各部份的先后顺序是保持不变的,但由于磁盘(⼀般200H)和内存(⼀般1000H)区块的对齐⼤⼩不⼀样,所以同⼀内容在磁盘和在内存中的地址是不⼀样的。

换⾔之你在磁盘上看到⼀段内容⼀内容要到在内存中找到它--假设它是能映射到内容的部份--那么要做相应的地址转换。

(⽐如你在Ultraedit 中看到某⼏个字节⽽想在OllyDbg中找到这⼏个字节那么需要进⾏地址转换)另外要注意,PE⽂件中存放的地址值都是内存中的地址,这些地址在OllyDbg中不需要转换到其指定的位置就能找到其指向的内容;这要根据这个地址找到内容在Ultraedit的地址,需要将此RVA址转换成⽂件偏移地址。

还要注意DOS头/PE头/块表,映射到内存时属同⼀区块⽽且是第⼀区块,所以此三者上的RVA和⽂件偏移地址是相等的。

2.DOS头部2.1MS-DOS头部(IMAGE_DOS_HEADER)最后的e_lfanew即是PE⽂件的RVA地址我们在前边已经提过,对于DOS头/PE头/区块表三部分RVA和⽂件偏移地址是相等的,所以上边在⼗六进制⽂本编缉器中,直接转向e_lfanew指向的000000B0可以正好找到PE头。

2.2DOS stubDOS stub是当操作系统不⽀持PE⽂件时执⾏的部分,⼀般由编译器⾃⼰⽣成内容是输出“This program cannot be run in MS-DOS mode”等提⽰。

PE文件格式详解(一)

PE文件格式详解(一)

PE文件格式详解(一)0x00 前言PE文件是portable File Format(可移植文件)的简写,我们比较熟悉的DLL和exe文件都是PE文件。

了解PE文件格式有助于加深对操作系统的理解,掌握可执行文件的数据结构机器运行机制,对于逆向破解,加壳等安全方面方面的同学极其重要。

接下来我将通过接下来几篇详细介绍PE文件的格式。

0x01 基本概念PE文件使用的是一个平面地址空间,所有代码和数据都被合并在一起,组成一个很大的组织结构。

文件的内容分割为不同的区块(Setion,又称区段,节等),区段中包含代码数据,各个区块按照页边界来对齐,区块没有限制大小,是一个连续的结构。

每块都有他自己在内存中的属性,比如:这个块是否可读可写,或者只读等等。

认识PE文件不是作为单一内存映射文件被装入内存是很重要的,windows加载器(PE加载器)便利PE文件并决定文件的哪个部分被映射,这种映射方式是将文件较高的偏移位置映射到较高的内存地址中。

当磁盘的数据结构中寻找一些内容,那么几乎能在被装入到内存映射文件中找到相同的信息。

但是数据之间的位置可能改变,其某项的偏移地址可能区别于原始的偏移位置,不管怎么样,所表现出来的信息都允许从磁盘文件到内存偏移的转换,如下图:PS:PE文件头以下的地址无论在内存映射中还是在磁盘映射中都是一样的,当内存分页和磁盘分页一致时无需进行地址转换,只有当磁盘分页和内存分页不一样时才要进行地址转化,这点很重要,拿到PE文件是首先查看分页是否一致。

前两天一直没碰到内存和磁盘分页不一样的,所以这个点一直没发现,今天特来补上。

下面要介绍几个重要概念,分别是基地址(ImageBase),相对虚拟地址(Relative Virtual Address),文件偏移地址(File Offset)。

1)基地址定义:当PE文件通过Windows加载器被装入内存后,内存中的版本被称作模块(Module)。

映射文件的起始地址被称作模块句柄(hMoudule),可以通过模块句柄访问其他的数据结构。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

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.Htypedef 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或267(译注:0x010B为.EXE,0x0107为ROM映像,这个信息我是从eXeScope上得来的)。

·MajorLinkerVersion、MinorLinkerVersion。

表示链接此映像的链接器版本。

随Window NT build 438配套的Windows NT SDK包含的链接器版本是2.39(十六进制为2.27)。

·SizeOfCode。

可执行代码尺寸。

·SizeOfInitializedData。

已初始化的数据尺寸。

·SizeOfUninitializedData。

未初始化的数据尺寸。

·AddressOfEntryPoint。

在标准域中,AddressOfEntryPoint域是对PE文件格式来说最为有趣的了。

这个域表示应用程序入口点的位置。

并且,对于系统黑客来说,这个位置就是导入地址表(IAT)的末尾。

以下的函数示范了如何从可选头部获得Windows NT可执行映像的入口点。

PEFILE.CLPVOID WINAPI GetModuleEntryPoint(LPVOID lpFile){PIMAGE_OPTIONAL_HEADER poh;poh = (PIMAGE_OPTIONAL_HEADER)OPTHDROFFSET(lpFile);if (poh != NULL)return (LPVOID)poh->AddressOfEntryPoint;elsereturn NULL;}·BaseOfCode。

已载入映像的代码(“.text”段)的相对偏移量。

·BaseOfData。

已载入映像的未初始化数据(“.bss”段)的相对偏移量。

Windows NT附加域添加到Windows NT PE文件格式中的附加域为Windows NT特定的进程行为提供了装载器的支持,以下为这些域的概述。

·ImageBase。

进程映像地址空间中的首选基地址。

Windows NT的Microsoft Win32 SDK链接器将这个值默认设为0x00400000,但是你可以使用-BASE:linker开关改变这个值。

·SectionAlignment。

从ImageBase开始,每个段都被相继的装入进程的地址空间中。

SectionAlignment 则规定了装载时段能够占据的最小空间数量——就是说,段是关于SectionAlignment对齐的。

Windows NT虚拟内存管理器规定,段对齐不能少于页尺寸(当前的x86平台是4096字节),并且必须是成倍的页尺寸。

4096字节是x86链接器的默认值,但是它可以通过-ALIGN: linker开关来设置。

·FileAlignment。

映像文件首先装载的最小的信息块间隔。

例如,链接器将一个段实体(段的原始数据)加零扩展为文件中最接近的FileAlignment边界。

早先提及的2.39版链接器将映像文件以0x200字节的边界对齐,这个值可以被强制改为512到65535这么多。

·MajorOperatingSystemVersion。

表示Windows NT操作系统的主版本号;通常对Windows NT 1.0而言,这个值被设为1。

·MinorOperatingSystemVersion。

表示Windows NT操作系统的次版本号;通常对Windows NT 1.0而言,这个值被设为0。

·MajorImageVersion。

用来表示应用程序的主版本号;对于Microsoft Excel 4.0而言,这个值是4。

·MinorImageVersion。

用来表示应用程序的次版本号;对于Microsoft Excel 4.0而言,这个值是0。

·MajorSubsystemVersion。

表示Windows NT Win32子系统的主版本号;通常对于Windows NT 3.10而言,这个值被设为3。

·MinorSubsystemVersion。

表示Windows NT Win32子系统的次版本号;通常对于Windows NT 3.10而言,这个值被设为10。

·Reserved1。

未知目的,通常不被系统使用,并被链接器设为0。

·SizeOfImage。

表示载入的可执行映像的地址空间中要保留的地址空间大小,这个数字很大程度上受SectionAlignment的影响。

例如,考虑一个拥有固定页尺寸4096字节的系统,如果你有一个11个段的可执行文件,它的每个段都少于4096字节,并且关于65536字节边界对齐,那么SizeOfImage域将会被设为11 * 65536 = 720896(176页)。

而如果一个相同的文件关于4096字节对齐的话,那么SizeOfImage 域的结果将是11 * 4096 = 45056(11页)。

这只是个简单的例子,它说明每个段需要少于一个页面的内存。

在现实中,链接器通过个别地计算每个段的方法来决定SizeOfImage确切的值。

它首先决定每个段需要多少字节,并且最后将页面总数向上取整至最接近的SectionAlignment边界,然后总数就是每个段个别需求之和了。

·SizeOfHeaders。

这个域表示文件中有多少空间用来保存所有的文件头部,包括MS-DOS头部、PE文件头部、PE可选头部以及PE段头部。

文件中所有的段实体就开始于这个位置。

·CheckSum。

校验和是用来在装载时验证可执行文件的,它是由链接器设置并检验的。

由于创建这些校验和的算法是私有信息,所以在此不进行讨论。

·Subsystem。

用于标识该可执行文件目标子系统的域。

每个可能的子系统取值列于WINNT.H的IMAGE_OPTIONAL_HEADER结构之后。

·DllCharacteristics。

用来表示一个DLL映像是否为进程和线程的初始化及终止包含入口点的标记。

·SizeOfStackReserve、SizeOfStackCommit、SizeOfHeapReserve、SizeOfHeapCommit。

这些域控制要保留的地址空间数量,并且负责栈和默认堆的申请。

在默认情况下,栈和堆都拥有1个页面的申请值以及16个页面的保留值。

这些值可以使用链接器开关-STACKSIZE:与-HEAPSIZE:来设置。

·LoaderFlags。

告知装载器是否在装载时中止和调试,或者默认地正常运行。

·NumberOfRvaAndSizes。

这个域标识了接下来的DataDirectory数组。

请注意它被用来标识这个数组,而不是数组中的各个入口数字,这一点非常重要。

·DataDirectory。

数据目录表示文件中其它可执行信息重要组成部分的位置。

它事实上就是一个IMAGE_DATA_DIRECTORY结构的数组,位于可选头部结构的末尾。

当前的PE文件格式定义了16种可能的数据目录,这之中的11种现在在使用中。

数据目录WINNT.H之中所定义的数据目录为:WINNT.H// 目录入口// 导出目录#define IMAGE_DIRECTORY_ENTRY_EXPORT 0// 导入目录#define IMAGE_DIRECTORY_ENTRY_IMPORT 1// 资源目录#define IMAGE_DIRECTORY_ENTRY_RESOURCE 2// 异常目录#define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3// 安全目录#define IMAGE_DIRECTORY_ENTRY_SECURITY 4// 重定位基本表#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5// 调试目录#define IMAGE_DIRECTORY_ENTRY_DEBUG 6// 描述字串#define IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7// 机器值(MIPS GP)#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8// TLS目录#define IMAGE_DIRECTORY_ENTRY_TLS 9// 载入配置目录#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10基本上,每个数据目录都是一个被定义为IMAGE_DATA_DIRECTORY的结构。

相关文档
最新文档