PE文件学习笔记(一):DOS头与PE头解析

在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头相对于文件的偏移量
};

我们查看下面所示unins000.exe文件的结构信息:
PE文件学习笔记(一):DOS头与PE头解析_第1张图片

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;
};

根据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 可执行文件
};

我们依旧来看unins000.exe的文件信息:
这里写图片描述

首先四字节是NT第一个签名成员“PE\0\0”。接着便是2字节的CPU平台信息:014C,即X86平台(其它平台可见下图):
PE文件学习笔记(一):DOS头与PE头解析_第2张图片
我们可以查看一下其它的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位来看的,属性值也是多个属性的组合(或运算)。每一位的信息如下:
PE文件学习笔记(一):DOS头与PE头解析_第3张图片

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
};

继续接着标准PE头来分析:
PE文件学习笔记(一):DOS头与PE头解析_第4张图片

第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(前面所有成员固定占用大小)

官方对于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)。

你可能感兴趣的:(COFF,PE/ELF)