在Windows下所谓PE文件即Portable Executable,意为可移植的可执行的文件。常见的.EXE、.DLL、.OCX、.SYS、.COM都是PE文件。PE文件有一个共同特点:前两个字节为4D 5A(MZ)。如果一个文件前两个字节不是4D 5A则其肯定不是可执行文件。比如用16进制文本编辑器打开一个“.xls”文件其前两个字节为:0XD0 0XCF;打开一个“.pdf”其前两个字节为:0X25 0X50。
PE文件结构:DOS头+PE头+节表+.data/.rdata/.text。而今天我们就来具体了解一下PE文件的DOS头和PE头的结构成员与部分成员的作用。注意:一个exe文件本身是一个PE文件,但是由于包含dll库,所以一个exe文件也是许多PE文件组成的(包含多个dll)一个PE文件。
1、DOS头:共40H(64字节)
DOS头中声明用的寄存器(我们可以看到e_ss、e_sp、e_ip、e_cs还是16位的寄存器),所以在32位/64为系统中用到的只有两个成员了(第一个和最后一个):
①e_magic:判断一个文件是不是PE文件;
②e_lfanew:相对于文件首的偏移量,用于找到PE头;
具体结构如下(前面的十六进制数表示该成员相对于结构的偏移量,WORD2字节变量、DWORD4字节变量):
//注释掉的不需要重点分析
struct _IMAGE_DOS_HEADER{
0X00 WORD e_magic; //※Magic DOS signature MZ(4Dh 5Ah):MZ标记:用于标记是否是可执行文件
//0X02 WORD e_cblp; //Bytes on last page of file
//0X04 WORD e_cp; //Pages in file
//0X06 WORD e_crlc; //Relocations
//0X08 WORD e_cparhdr; //Size of header in paragraphs
//0X0A WORD e_minalloc; //Minimun extra paragraphs needs
//0X0C WORD e_maxalloc; //Maximun extra paragraphs needs
//0X0E WORD e_ss; //intial(relative)SS value
//0X10 WORD e_sp; //intial SP value
//0X12 WORD e_csum; //Checksum
//0X14 WORD e_ip; //intial IP value
//0X16 WORD e_cs; //intial(relative)CS value
//0X18 WORD e_lfarlc; //File Address of relocation table
//0X1A WORD e_ovno; //Overlay number
//0x1C WORD e_res[4]; //Reserved words
//0x24 WORD e_oemid; //OEM identifier(for e_oeminfo)
//0x26 WORD e_oeminfo; //OEM information;e_oemid specific
//0x28 WORD e_res2[10]; //Reserved words
0x3C DWORD e_lfanew; //※Offset to start of PE header:定位PE文件,PE头相对于文件的偏移量
};
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
我们查看下面所示unins000.exe文件的结构信息:
64字节(共4行)的DOS头,第一个成员2个字节是可执行文件的标志信息;最后一个成员4字节是PE头的偏移地址为00000100H,我们可以根据00000100H来获取PE头的地址。而DOS头和PE头中间的空余位置是一些垃圾值以及编译器填充的一些“is program cannot be run in DOS mode.”或“This program must be run under Win32”等信息。
2、PE头:
PE头分为标准PE头和可选PE头,其同为NT结构的成员:
//NT头
//pNTHeader = dosHeader + dosHeader->e_lfanew;
struct _IMAGE_NT_HEADERS{
0x00 DWORD Signature; //PE文件标识:ASCII的"PE\0\0"
0x04 _IMAGE_FILE_HEADER FileHeader;
0x18 _IMAGE_OPTIONAL_HEADER OptionalHeader;
};
- 1
- 2
- 3
- 4
- 5
- 6
- 7
根据DOS头的e_lfanew成员我们就可以找到NT头,NT头的第一个成员是”PE\0\0”(0X50 0X45 0X00 0X00四字节的签名,可以在上图00000100H地址处观察),后两个成员则分别是标准PE头(_IMAGE_FILE_HEADER)和可选PE头(_IMAGE_OPTIONAL_HEADER)。
(1)、_IMAGE_FILE_HEADER:
//标准PE头:最基础的文件信息,共20字节
struct _IMAGE_FILE_HEADER{
0x00 WORD Machine; //※程序执行的CPU平台:0X0:任何平台,0X14C:intel i386及后续处理器
0x02 WORD NumberOfSections; //※PE文件中区块数量
0x04 DWORD TimeDateStamp; //时间戳:连接器产生此文件的时间距1969/12/31-16:00P:00的总秒数
//0x08 DWORD PointerToSymbolTable; //COFF符号表格的偏移位置。此字段只对COFF除错信息有用
//0x0c DWORD NumberOfSymbols; //COFF符号表格中的符号个数。该值和上一个值在release版本的程序里为0
//0x10 WORD SizeOfOptionalHeader; //IMAGE_OPTIONAL_HEADER结构的大小(字节数):32位默认E0H,64位默认F0H(可修改)
0x12 WORD Characteristics; //※描述文件属性,eg:
//单属性(只有1bit为1):#define IMAGE_FILE_DLL 0x2000 //File is a DLL.
//组合属性(多个bit为1,单属性或运算):0X010F 可执行文件
};
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
我们依旧来看unins000.exe的文件信息:
首先四字节是NT第一个签名成员“PE\0\0”。接着便是2字节的CPU平台信息:014C,即X86平台(其它平台可见下图):
我们可以查看一下其它的other.exe文件,如下所示,其CPU平台信息为8664即X64:
然后是区块数量0008H即8个块;第三个成员为时间戳:56BCE029H(即十进制1455218729),转换成北京时间为2016-02-12 03:25:29(时间戳在线转换);第四个和第五个成员各占4字节且均为0;第六个成员占2字节为默认值E0H(即可选PE头的大小为224字节,other.exe中为X64默认值F0H);最后一个属性成员占2字节为“818F”,该成员是按bit位来看的,属性值也是多个属性的组合(或运算)。每一位的信息如下:
818F = 8000 | 0100 | 0080 | 0008 | 0004 | 0002 | 0001即:
IMAGE_FILE_BYTES_REVERSED_HI |
IMAGE_FILE_32BIT_MACHINE |
IMAGE_FILE_BYTES_REVERSED_LO |
IMAGE_FILE_RELOCS_STRIPPED |
IMAGE_FILE_EXECUTABLE_IMAGE |
IMAGE_FILE_LINE_NUMS_STRIPPED |
IMAGE_FILE_LOCAL_SYMS_STRIPPED
(2)、_IMAGE_OPTIONAL_HEADER:
可选PE头紧接着标准PE头,其大小在标准PE头中给出:大小为E0H即224字节。_IMAGE_OPTIONAL_HEADER结构如下所示:
//可选PE头
struct _IMAGE_OPTIONAL_HEADER{
0x00 WORD Magic; //※幻数(魔数),0x0107:ROM image,0x010B:32位PE,0X020B:64位PE
//0x02 BYTE MajorLinkerVersion; //连接器主版本号
//0x03 BYTE MinorLinkerVersion; //连接器副版本号
0x04 DWORD SizeOfCode; //所有代码段的总和大小,注意:必须是FileAlignment的整数倍,存在但没用
0x08 DWORD SizeOfInitializedData; //已经初始化数据的大小,注意:必须是FileAlignment的整数倍,存在但没用
0x0c DWORD SizeOfUninitializedData; //未经初始化数据的大小,注意:必须是FileAlignment的整数倍,存在但没用
0x10 DWORD AddressOfEntryPoint; //※程序入口地址OEP,这是一个RVA(Relative Virtual Address),通常会落在.textsection,此字段对于DLLs/EXEs都适用。
0x14 DWORD BaseOfCode; //代码段起始地址(代码基址),(代码的开始和程序无必然联系)
0x18 DWORD BaseOfData; //数据段起始地址(数据基址)
0x1c DWORD ImageBase; //※内存镜像基址(默认装入起始地址),默认为4000H
0x20 DWORD SectionAlignment; //※内存对齐:一旦映像到内存中,每一个section保证从一个「此值之倍数」的虚拟地址开始
0x24 DWORD FileAlignment; //※文件对齐:最初是200H,现在是1000H
//0x28 WORD MajorOperatingSystemVersion; //所需操作系统主版本号
//0x2a WORD MinorOperatingSystemVersion; //所需操作系统副版本号
//0x2c WORD MajorImageVersion; //自定义主版本号,使用连接器的参数设置,eg:LINK /VERSION:2.0 myobj.obj
//0x2e WORD MinorImageVersion; //自定义副版本号,使用连接器的参数设置
//0x30 WORD MajorSubsystemVersion; //所需子系统主版本号,典型数值4.0(Windows 4.0/即Windows 95)
//0x32 WORD MinorSubsystemVersion; //所需子系统副版本号
//0x34 DWORD Win32VersionValue; //总是0
0x38 DWORD SizeOfImage; //※PE文件在内存中映像总大小,sizeof(ImageBuffer),SectionAlignment的倍数
0x3c DWORD SizeOfHeaders; //※DOS头(64B)+PE标记(4B)+标准PE头(20B)+可选PE头+节表的总大小,按照文件对齐(FileAlignment的倍数)
0x40 DWORD CheckSum; //PE文件CRC校验和,判断文件是否被修改
//0x44 WORD Subsystem; //用户界面使用的子系统类型
//0x46 WORD DllCharacteristics; //总是0
0x48 DWORD SizeOfStackReserve; //默认线程初始化栈的保留大小
0x4c DWORD SizeOfStackCommit; //初始化时实际提交的线程栈大小
0x50 DWORD SizeOfHeapReserve; //默认保留给初始化的process heap的虚拟内存大小
0x54 DWORD SizeOfHeapCommit; //初始化时实际提交的process heap大小
//0x58 DWORD LoaderFlags; //总是0
0x5c DWORD NumberOfRvaAndSizes; //目录项数目:总为0X00000010H(16)
0x60 _IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];//#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16
};
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
继续接着标准PE头来分析:
第1个成员(Magic,2Byte):幻数010B,表示该文件为32位PE,其它情况如下:
第4个成员(SizeOfCode,4Byte):代码段总大小为000FF800H;
第5个成员(SizeOfInitializedData,4Byte):已初始化数据大小为00039400H;
第6个成员(SizeOfUninitializedData,4Byte):未初始化数据大小为0,即均已初始化;
第7个成员(AddressOfEntryPoint,4Byte):程序入口地址OEP=0010056CH;
第8个成员(BaseOfCode,4Byte):代码段基址 = 00001000H;
第9个成员(BaseOfData,4Byte):数据段基址 = 00101000H;
第10个成员(ImageBase,4Byte):内存镜像基址 = 00400000H,这是一个默认的值;
第11个成员(SectionAlignment,4Byte):内存对齐 = 00001000H,即4096字节;
第12个成员(FileAlignment,4Byte):文件对齐 = 00000200H,即512字节(文件对齐和内存对齐的目的是提高效率);
第20个成员(SizeOfImage,4字节):PE映像在内存中总大小 = 00145000H,是SectionAlignment的325倍(整数倍);
第21个成员(SizeOfHeaders,4字节):所有头+节表总大小 = 00000400H;
第22个成员(CheckSum,4字节):PE文件CRC校验和 = 0014173FH
第25个成员(SizeOfStackReserve,4字节):为线程初始栈保留虚拟内存的默认值 = 00100000H = 1MB;
第26个成员(SizeOfStackCommit,4字节):为线程的初始栈提交的实际虚拟内存大小 = 00004000H = 16KB;
第27个成员(SizeOfHeapReserve,4字节):为进程的初始堆保留虚拟内存的默认值 = 00100000H = 1MB;
第28个成员(SizeOfHeapCommit,4字节):为进程的初始堆提交的实际虚拟内存大小 = 00001000H = 4KB;
第30个成员(NumberOfRvaAndSizes,4字节):目录项总数默认 = 00000010H = 16个。
最后一个成员为_IMAGE_DATA_DIRECTORY的结构体数组(本次只分析DOS头和PE头基本成员,该结构体数组以后重点分析),该结构体成员如下:
struct _IMAGE_DATA_DIRECTORY{
DWORD VirtualAddress;
DWORD Size;
};
//占用16*8 = 128Byte = 80H = E0H(可选PE头默认大小) - 60H(前面所有成员固定占用大小)
- 1
- 2
- 3
- 4
- 5
官方对于Image结构的解释:https://msdn.microsoft.com/en-us/library/windows/desktop/ms680198(v=vs.85).aspx
3、几个重点的数据成员分析:
(1)、文件对齐(FileAlignment)和内存对齐(SectionAlignment):
一个PE文件加载进内存中可能大于在硬盘上的大小,并且无论是在内存中还是硬盘上,都是是分块管理(分节),一块和一块存储空间之间是空隙。在硬盘上空隙有可能小于内存中空隙;在内存中空隙较大(相较于硬盘)。而存在间隙的原因则是分块管理。
分块的一个原因是节省硬盘:比如notepad.exe,由于是早期的程序,当时硬盘容量比较小,编译器在生成可执行文件时,不仅要考虑效率问题使得内存对齐/文件对齐,还需要设计成节省硬盘空间的结构。所以这种结构遵循的对齐原则:内存对齐(1000H)和硬盘对齐(200H),对齐的补充数据(0X0000)便是间隙。硬盘的对齐值较小,补充间隙自然小,因此同一个可执行程序在内存中可能比在硬盘上大。但是现如今的硬盘空间更大,所以编译器生成的可执行程序在硬盘上与内存中对齐方式都是1000H。统一对齐为1000H的目的依旧是提高效率。
而分块的另一个目的是节省内存空间,比如同时在电脑上运行登录多个QQ账号,就需要运行多次QQ可执行程序。而代码段为只读数据需要一份即可,数据段则需要为每个账号均开辟一份,,多个QQ程序共享代码块,单独使用数据块,这样就节省了多份代码块的内存。(这些块是使用结构体来维护的,分块即创建结构体)。
(2)、镜像地址/基址ImageBase的作用:
FileBuffer是磁盘上.exe文件在内存中的一份拷贝,但是FileBuffer无法直接在内存中运行,必须经过PE loader(装载器)装载以后成为ImageBuffer。ImageBuffer是FileBuffer的”拉伸”。即”.exe–>FileBuffer–>ImageBuffer”
①.exe首地址(基址)为0
②FileBuffer首地址也为0
③ImageBuffer首地址为ImageBase
④而真正的程序入口地址是:ImageBase + AddressOfEntryPoint(OEP)
一个exe文件默认镜像地址为400000H(有可能不是,总之有一个默认值),如果一个exe文件中用到了多个dll,而dll文件作为一个PE文件,其默认镜像地址也均是400000H,操作系统不会修改exe的镜像基址。因为.exe先被加载,在.exe中才加载的dll库,由于400000已经被.exe占用,所以装载器会修改dll的镜像基址。而采用ImageBase + OEP的目的也就是:采用偏移地址的方式可以更方便地修改基址,使得任何一个dll文件基址修改后程序依旧不会出错。比如:dll和exe基址有冲突,本只需要将冲突的.dll的文件基址修改为600000H(假设是编译器为其分配的是600000H);如果不采用“基址+偏移地址”的方式,而采用绝对地址,那么要修改的就不是一个基址为600000H了,而是dll中所有的地址统一加上200000H(因为原来默认为400000H)。