二进制菜鸟之PE文件结构

最新推荐文章于 2022-07-20 11:13:57 发布

Blood_Pupil

最新推荐文章于 2022-07-20 11:13:57 发布

阅读量1.8k

点赞数 4

分类专栏：二进制文章标签： PE 二进制可执行文件重定位表逆向

本文链接：https://blog.csdn.net/blood_pupil/article/details/99702622

版权

二进制专栏收录该内容

3 篇文章 1 订阅

订阅专栏

所谓PE文件就是可执行文件在硬盘中存储是的文件表示，Windows中可执行文件的文件表示的发展途径为com->LE(Linerar executable)->PE(Portable Executable File Formate)。在程序运行的时候PE文件中的部分内容被载入内存（各种节），这些内容提供了程序运行所需的所有信息，下图展示了PE文件到内存的映射：

文章目录

PE文件结构
IMAGE_DOS_HEADER
DOS Stub
IMAGE_NT_HEADERS
IMAGE_FILE_HEADER
IMAGE_OPTIONAL_HEADER32

IMAGE_SECTION_HEADER

功能数据介绍
导入表
导出表
资源
重定位表
总结

PE文件结构

下图展示了PE文件的总体结构，在下面小节中将对各个结构进行详细的说明。
PE文件结构

IMAGE_DOS_HEADER

DOS部分是为了兼容DOS系统程序，此部分包括Header和stub两部分，前者是对DOS程序的描述，后者包含了DOS可执行程序，Header头部如下所示：

IMAGE_DOS_HEADER STRUCT
   e_magic		WORD    ;DOS可执行文件标记
   e_cblp       WORD	
   e_cp         WORD
   e_crlc       WORD
   e_cparhdr    WORD
   e_minalloc   WORD
   e_maxalloc   WORD
   e_ss         WORD   ;代码的初始化堆栈段基址
   e_sp         WORD   ;代码的堆栈段偏移指针
   e_csum       WORD
   e_ip         WORD   ;DOS代码段偏移指针
   e_cs         WORD   ;DOS代码段基址
   e_lfarlc     WORD
   e_ovno       WORD   ;DOS文件头部到此为此，下述字段为了对其他可执行文件进行扩充，DOS系统对下述字段不解释
   e_res        WORD
   e_oemid      WORD
   e_oeminfo    WORD
   e_res2       WORD
   e_lfanew     DWORD  ;指向PE文件头部（或者LE，LX其他可执行文件头部）
IMAGE_DOS_HEADER ENDS

通过Lord PE工具可以查看程序的IMAGE_DOS_HEADER信息：

DOM可执行文件的识别标志为MZ

DOS Stub

DOS系统下可执行的代码，默认情况下这段代码只会简单的显示一个“This program cannot be run in DOS mode”然后就退出了，具体代码如下图黄框所示（Study PE工具截图）

DOS_STUB 上述黄框中部分机器码内容如下：

0E                PUSH    cs
1F                POP     ds
BA0E00            MOV     dx,  0x000E    ;串地址（即This program cannot.....的地址）
B409              MOV     ah, 0x09       ;显示字符串
CD21              INT     0x21           ;中断调用
B8014C            MOV     ax,0x4c01      ;带返回码结束，返回码为1
CD21              INT     0x21

可以使用链接器（link.exe）的/stud参数在链接时指定其他的DOM程序来代替上述提示程序

IMAGE_NT_HEADERS

IMAGE_NT_HEADERS是正式的PE文件头，本部分以8字节为单位对其，详细结构如下所示：

IMAGE_NT_HEADERS STRUCT
   Signature		DWORD                    ;PE文件标识
   FileHeader       IMAGE_FILE_HEADER
   OptionalHeader   IMAGE_OPTIONAL_HEADER32  
IMAGE_NT_HEADERS ENDS

其中Signature的值为0x00004550也就是PE\0\0
IMAGE_NT_HEADERS

IMAGE_FILE_HEADER

IMAGE_FILE_HEADER STRUCT
   Machine                WORD     ;运行平台
   NumberOfSections       WORD     ;文件的节数
   TimeDateStamp          DWORD    ;文件创建日期和时间
   PointerToSymbolTable   DWORD    ;符号表指针（调试用）
   NumberOfSymbols        DWORD    ;符号表中的符号数量（调试用）
   SizeOfOptionalHeader   WORD     ;IMAGE_OPTIONAN_HEADER32结构的长度
   Characteristics        WORD     ;文件属性
IMAGE_FILE_HEADER ENDS

下图是Lord PE软件载入某执行文件后上述结构体的值：
IMAGE_FILE_HEADER

Machine：表示运行平台
TimeDateStamp：自1969年12月31日下午4点到文件创建时的秒数
SizeOfOptionalHeader：这个值为00e0h
Characteristics：这个字段16位（WORD），每一位描述着不同的文件属性

IMAGE_OPTIONAL_HEADER32

此结构体本意是让开发者能够在PE文件头中使用自定义数据，这个结构体弥补了IMAGE_FILE_HEADER不能够充分描述PE文件属性的不足

IMAGE_OPTIONAL_HEADER32 STRUCT:
   Magic                         WORD                       ;
   MajorLinkerVersion            BYTE                       ;连接器版本号
   MinorLinkerVersion            BYTE                       ;
   SizeOfCode                    DWORD                      ;所有包含代码的节的总大小
   SizeOfInitializedData         DWORD                      ;所有包含已初始化数据的节的总大小
   SizeOfUninitializedData       DWORD                      ;所有包含未初始化数据的节的总大小
   AddressOfEntryPoint           DWORD                      ;程序执行的入口偏移虚拟地址（RVA）
   BaseOfCode                    DWORD                      ;代码节的起始偏移虚拟地址（RVA）
   BaseOfData                    DWORD                      ;数据节的起始偏移虚拟地址（RVA）
   ImageBase                     DWORD                      ;程序建议装载地址
   SectionAlignment              DWORD                      ;内存中的节的对齐粒度
   FileAlignment                 DWORD                      ;文件中的节的对其粒度
   MajorOperatingSystemVersion   WORD                       ;操作系统的主版本号
   MinorOperatingSystemVersion   WORD                       ;操作系统中副版本号
   MajorImageVersion             WORD                       ;可运行于操作系统的最小版本号
   MinorImageVersion             WORD                       ;
   MajorSubsystemVersion         WORD                       ;可运行于操作系统的最小子版本号
   MinorSubsystemVersion         WORD                       ;
   Win32VersionValue             DWORD                      ;未用
   SizeOfImage                   DWORD                      ;内存中整个PE映像的尺寸
   SizeOfHeaders                 DWORD                      ;所有头+节表的大小
   CheckSum                      WORD                       ;
   Subsystem                     WORD                       ;文件的子系统
   DllCharacteristics            DWORD                      ;
   SizeOfStackReserve            DWORD                      ;初始化时堆栈大小
   SizeOfStackCommit             DWORD                      ;初始化时实际提交的堆栈大小
   SizeOfHeapReserve             DWORD                      ;初始化时保留的堆的大小
   SizeOfHeapCommit              DWORD                      ;初始化时实际提交的堆的大小
   LoaderFlags                   DWORD                      ;未用
   NumberOfRvaAndSizes           DWORD                      ;下面的数据目录结构的数量
   DataDirectory                 IMAGE_DATA_DIRECTORY 16 dup;
IMAGE_OPTIONAL_HEADER32 ENDS

下图展示了某程序的IMAGE_OPTIONAL_HEADER32 ：

AddressOfEntryPoint：指出文件被执行时的入口地址，这是一个虚拟偏移地址（RVA）
ImageBase：指出程序有限装入的地址，也就是在文件执行时，WIndows优先将程序装入到ImageBase指定的地址中，如果执行地址已被占用，此时文件将会被装入其他地址
1. EXE文件装入内存的基址为0x00400000，DLL文件转入内存的基址为0x10000000，可以通过链接器（link.exe）的/base:address选项自定义优先转入的地址。
2. EXE文件装入内存时常能如愿的加载到ImageBase指定的地址，因为每个EXE文件都有独立的虚拟地址空间，这也是EXE文件的IMAGE_FILE_HEADER结构的IMAGE_FILE_RELOCS_STRIPPED为常为1的原因；而DLL文件常常不能加载到指定内存，因为一个EXE通常会加载多个DLL，为此只有先加载的DLL才能遂愿，大部分的都不遂愿，这也是DLL文件的IMAGE_FILE_HEADER结构的IMAGE_FILE_RELOCS_STRIPPED为常为0的原因。
3. 需要重定位的程序往往会比不需要重定位的程序慢的多，因为不需要重定位的程序在生成机器码时相对地址可以事先计算好，而需要重定位的程序不能这样做只有在程序转入运行时才能计算地址。
SectionAlignment和FileAlignment
由于硬盘文件存储时存储的基本单位可能会与内存存储时基本的存储单位不同而导致节偏移的情况，为此：
文件偏移地址=虚拟内存地址-装载基址-节偏移=RVA（相对虚拟内存偏移地址）-节偏移
Subsystem：此字段指定程序使用的界面子系统，这个字段决定程序如何建立初始界面
可以通过链接器（link.exe）的/subsystem:xxx选项指定这个字段的值。
下图是Lord PE工具所能识别的子系统列表：
DataDirectory：最重要字段之一，由16个（NumberOfRvaAndSizes字段的值）IMAGE_DATA_DIRECTORY结构组成
PE文件再装入内存后的页属性而被归类到不同的节中，但是这些处于不同节中的数据还可以按照用途被分类为导出表、导入表、资源、重定位表等数据块，这16个IMAGE_DATA_DIRECTORY就是用来定义多种不同用途的数据块的。也就是说节是按照页属性划分的，而DataDirectory是按照功能用途来划分的，但DataDirectory所指向的数据还是位与节中。
IMAGE_DATA_DIRECTORY结构如下：

IMAGE_DATA_DIRECTORY STRUCT
	VirtualAddress DWORD     ;数据的起始RVA
	isize          DWORD     ;数据块的长度
IMAGE_DATA_DIRECTORY ENDS

下图展示了这16个IMAGE_DATA_DIRECTORY结构的用途：
下图是通过Lord PE软件查看的某个EXE文件的DataDirectory列表：
DataDirectory_Lord

IMAGE_SECTION_HEADER

在PE文件装入时Windows装载器在装载DOS部分、PE文件头部分和节表部分时不进行任何处理，而在装载节的时候会根据节的属性做不同的处理，一般需要处理以下几个方面内容：

内存页的属性：与节对应的内存页的属性也要按照节的属性来设置，所以同属于一个模块的内存页中，从不同节映射过来的内存页的属性也是不同的。
节的偏移地址：节在磁盘中的对其单位是IMAGE_OPTIONAL_HEADER32结构中FileAlignment指定的，而在内存中对其单位是SectionAlignment字段指定的，二者可能不同。因为内存页的属性是对应于节属性设置的，而Windows系统对内存属性的设定单位为页，为此节的最小对其单位对应于Windows系统内存页的大小，而在磁盘中为了减小文件存储时所占用的空间从而降低了其磁盘中的对齐单位。
节的尺寸
在节由磁盘转入内存的过程中主要有两个原因影响节的尺寸，其一就是上面提到的由于对齐方式不同可能需要填充从而导致节的尺寸变大，其次就是对于包含未初始化数据的节在磁盘中存储时其尺寸为0，载入内从后Windows装载器根据额外信息将这些节装载到指定内存地址并开辟指定的空间。
不进行映射的节
有些节包含的数据仅在装载时使用，比如像包含重定向数据的节（.reloc），这些节在装载完成后就没有装入到内存中的价值了，为此这些节仅存在与磁盘文件中而不会被映射到内存页

PE文件所有节的属性均被定义在节表中，节表由一些列（IMAGE_NT_HEADERS.FileHeader.NumberOfSecitons字段指定节表长度）的IMAGE_SECTION_HEADER结构组成，这些结构的排列顺序与他们所描述节的排列顺序一致，节表起始地址位于距离PE文件头（不是文件头）00f8h偏移的位置，IMAGE_SECTION_HEADER结构如下所示：

IMAGE_SCETION_HEADER STRUCT
	Name1 db IMAGE_SIZEOF_SHORT_NAME dup(?)        ;8个字节的节区名称
	union Misc
		PhysicalAddress              dd	           ;
		VirtualSize                  dd            ;节的尺寸
	ends
	VirtualAddress                   dd            ;节区的RVA
	SizeofRawData                    dd            ;在文件中对齐后的尺寸
	PointerToRawData                 dd            ;在文件中的偏移
	PointerToRelocations             dd            ;在OBJ文件中使用
	PoninterToLinenumbers            dd            ;行号表的位置（供调试用）
	NumberOfRelocations              dw            ;在OBJ文件中使用
	NumberOfLinenumbers              dw            ;行号表中行号的数量
	Characteristics                  dd            ;节的属性
IMAGE_SCETION_HEADER ENDS

上面有些字段是供COFF格式的OBJ文件使用的，对于可执行文件来说不代表任何意义

Name1：此字段由8个字节组成，用于定义节的名称，不要求以0结束，节的名称仅为标识不具有特殊意义
VirtualAddress：指定节被装入内存后的偏移地址（RVA）
VirtualSize：代表节在没有进行对齐处理前的实际的大小
PointerToRawData：指定节在磁盘文件中所处的位置，是相对于文件头的偏移量
SizeOfRawData：指出节在磁盘文件中所占空间的大小
Characteristics：节的属性标志字段，其不同数据位代表着不同的属性
下表展示了不同的位所表示的不同属性：
下图展示了某EXE文件.rdada节的属性：
下图是某程序的节表：

功能数据介绍

前面已经提及过节是按照数据属性进行的分类，DataDirectory是按照数据功能进行的分类。本节中介绍导入表，导出表，资源，重定位表四个重要的DataDirectory。

导入表

导入表中保存了导入函数的相关信息（导入函数名，其驻留的DLL），所谓导入函数就是代码中调用了这些函数而这些函数并没有在本代码中定义而是从一个或多个DLL中导入进来的函数。当PE文件位与磁盘上时无法得知导入函数会位与内存的哪个位置，只有PE文件被装入内存时，Windows转载器才会将DLL装入并将导入函数的指令与函数实际所处的地址联系起来，这就是动态链接的概念。
导入表由一系列的IMAGE_IMPORT_DESCRIPTOR结构组成，这个结构与导入的DLL文件一一对应，最后需要一个内容全为0的IMAGE_IMPORT_DESCRIPTOR结构作为结束

IMAGE_IMPORT_DESCRIPTOR STRUCT
	union
		Characteristics       dd         
		OriginalFirstThunk    dd
	ends
	TimeDateStamp             dd
	ForwarderChain            dd
	Name1                     dd       ;指向DLL文件名称的RVA
	FirstThunk                dd               
IMAGE_IMPORT_DESCRIPTOR ENDS

OriginalFirstThunk和FirstThunk字段含义均指向一个包含一系列IMAGE_THUNK_DATA结构的数据，每个IMAGE_THUNK_DATA结构对应于一个导入函数信息，数组最后由一个全0的IMAGE_THUNK_DATA结构收尾，此结构（双字大小）具体如下：

IMAGE_THUNK_DATA STRUCT
	union u1
		ForwarderString   dd
		Function          dd
		Ordinal           dd
		AddressOfData     dd
	ends
IMAGE_THUNK_DATA ENDS

由于上述结构采用union结构所以其实其就是一个双字类型，当这个双字表示了函数的导入方式：

最高位为1，表明以序号方式导入，双字其余低位就表示者函数的序号
最高位为0，表示以函数名方式导入，此时双字的值是一个RVA，其指向一个用来定义导入函数名称的IMAGE_IMPORT_BY_NAME结构，此结构的定义如下：

IMAGE_IMPORT_BY_NAME STRUCT
	Hint            dw           ;表示函数序号，此字段可选
	Name1           db			 ;定义了导入函数的名称字符串，以0结尾的字符串
IMAGE_IMPORT_BY_NAME ENDS

下图展示了装入内存前PE文件中的导入表，此表表示从Kernel32.dll导入四个函数（前三个以函数名方式导入，最后那个以序号方式导入）：

下图展示了装载进内存后上述导入表的状况：
内存中的导入表导入内存后FirstThunk指向的那个数组中的每个双字均被替换为真正的函数地址，OriginalFirstThunk与FirstThunk对照使用可以由地址得知函数名称，也可以由函数名或者序号查询函数在内存中的地址。
之前说个IMAGE_IMPORT_DESCRIPTOR结构与DLL文件一一对应，这些结构中FirstThunk指向的地址数组在内存中是被排列在一起的，这一内存块称之为导入地址表（Import Address Table，IAT），导入表中第一个IMAGE_IMPORT_DESCRIPTOR结构的FirstThunk字段指向了IAT的起始地址，除此之外DataDirectory结构中第13项IMAGE_DATA_DIRECTORY 结构也指向了IAT的起始地址。

导出表

除了导入表还有导出表，导入表指的是程序运行时要从DLL中导入的函数信息，而导出表则表示着DLL文件中函数的导出信息，主要用于修正IAT，导出表包含了函数的名称、序号以及入口地址等信息。EXE文件一般不存在导出表，大部分的DLL文件都包含导出表，通过导出表可以看DLL中包含那些函数。下图展示了一个DLL文件的导入与导出函数信息：
导入导出
导出表中为每个导出函数定义了导出序号，但是函数名的定义是可选的，导出表只有一个IMAGE_EXPORT_DIRECTORY结构，此结构定义如下：

IMAGE_EXPORT_DIRECTORY STRUCT
	Characteristics               DWORD           ;未使用，总是为0
	TimeDateStamp                 DWORD           ;文件的创建时间
	MajorVersion                  WORD            ;未使用，总是为0
	MinorVersion                  WORD            ;未使用，总是为0
	nName                         DWORD           ;指向文件名的RVA
	nBase                         DWORD           ;导出函数的起始序号
	NumberOfFunctions             DWORD           ;导出函数的总数
	NumberOfNames                 DWORD           ;有名称的导出函数总数
	AddressOfFunctions            DWORD           ;指向导出函数地址表的RVA
	AddressofNames                DWORD           ;指向函数名地址表的RVA
	AddressOfNameOrdinals         DWORD           ;指向函数名序号表的RVA
IMAGE_EXPORT_DIRECTORY ENDS

下图展示了导出表及相关数据的结构及关系（nBase:x）：
不明白的是函数的入口RVA在载入内存之前的磁盘文件中就存在了，为什么？RVA不是内存中才有的概念吗？难道是.text是第一个段所以其前面的头部载入时不会发生相对偏移？

资源

资源结构

PE文件中的资源如上图所示按目录结构组织，所有的目录结构及资源数据都几种的放在一个资源数据块中
这个数据块的RVA由IMAGE_OPTIONAL_HEADER32.DataDirectory.Resource.VitrualAddress指定，而这个起始地址也对应着上图中的更目录首地址，依此就可以一层层的访问资源
需要注意的是尽管资源一般情况下在**.rsrc**节中但并非必然，为此不可以通过这个节来对资源进行访问

接下来对资源涉及到的几种数据结构进行介绍，首先介绍IMAGE_RESOURCE_DIRECTORY，此结构包含了本目录的各种属性信息，具体结构如下：

IMAGE_RESOURCE_DIRECOTRY STRUCT
	Characteristics      dd                 ; 理论上为资源的属性，不过通常总是为0
	TimeDateStamp        dd                 ; 资源的产生时刻
	MajorVersion         dw                 ; 理论上为资源的版本，不过事实上总是为0
	MinerVersion         dw                 ;
	NumberOfNameEntries  dw                 ; 以名称命名的入口数量
	NumberOfIdEntries    dw                 ; 以ID命名的入口数量
IMAGE_RESOURCE_DIRECTORY ENDS

上述结构中后两项说明了本目录中目录项的数量，这两者相加是本目录下目录项的总和，接下来了解下IMAGE_RESOURCE_DIRECTORY_ENTRY结构：

IMAGE_RESOURCE_DIRECTORY_ENTRY STRUCT
	Name1           dd         ; 
	OffsetToData    dd         ; 
IMAGE_RESOURCE_DIRECTORY_ENTRY ENDS

Name1字段字段在不同情况下有不同的含义，具体如下所示：

资源类型：处于上图第一层目录时，31位为0时低位表示ID类型资源，系统预定义资源的ID表如下图所示，当ID值大于16时为用户自定义的ID资源
指向目录项名称的指针或者目录项ID：处于上图第二层目录。第31位为0时低位表示ID；第31位为1时，低位为指针其所指的并不是字符串（因为项目名称是Unicode编码）而是指向一个IMAGE_RESOURCE_DIR_STRING_U结构体

IMAGE_RESOURCE_DIR_STRING_U STRUCT
	Length1        dw                 ;字符串长度
	NameString     dw     dup(?)      ;dup(?)代表重复？次，因为Unicode字符串长度不固定
IMAGE_RESOURCE_DIR_STRING_U ENDSUnicode字符串

OffsetToData字段在不同情况下有不同的含义，具体如下所示：

目录项指针：处于一二层目录结构时，此项高位为1，低位指向一个IMAGE_RESOURCE_DIRECTORY结构
资源项指针：处于第三层是此项高位为0，低位指向一个IMAGE_RESOURCE_DATA_ENTRY结构

IMAGE_RESOURCE_DATA_ENTRY STRUCT
	OffsetToData            dd              ;资源数据的RVA
	Size1                   dd              ;资源数据的长度
	CodePage                dd              ;代码页，实际之中好像未被使用，总是为0
	Reserved                dd              ;保留字段
IMAGE_RESOURCE_DATA_ENTRY ENDS

需要注意的是上述结构中的指针含义均是相对于资源根目录起始地址的偏移量
下面结合Winhex与stud_PE分析下某程序的资源信息：

首先使用Stud_PE工具在DataDirectory找到Resource的RVA，如下图所示：
接下来观察更具节信息将RVA转化为磁盘中的偏移地址，转化的算法大概如下伪代码所示：

for i in 节表:
	if RVA>i.VirtualAddress and RVA < i.VirtualAddress+i.sizeOfRawData:
		文件偏移 = i.PointerToRawData+(RVA-i.VirtualAddress)

节信息如下，按上述算法资源处于.rsrc节中且资源的起始地址刚好是这个节的起始地址，为此可以判断出资源在文件中的偏移为0x000FE000
.rsc

使用WinHex打开此程序并定位到0x000FE000的位置，如下图所示：
上图中资源信息IMAGE_RESOURCE_DATA_ENTRY.CodePage并不为0与之前介绍的有出入

重定位表

上述代码中第5行使用了直接寻址的方式，在此应用程序装入预设的0x0040000地址时这中寻址方式直接出现在代码中没有问题，如果程序没有载入预设地址那怎么办呢？重定位就是来解决这个问题的，32位的代码中涉及直接寻址的指令都是需要重定位的，16的DOS中只有涉及段操作的指令才需要重定位，重定位信息是在编译时有编译器生成并保存在可执行文件中的。重定位具体操作如下：
重定位后地址 = 代码中出现的直接寻址地址-预装地址（0x00400000）+代码实际装入地址
上述三个操作数中预装地址已经在IMAGE_OPTIONAL_HEADER32.ImageBase字段定义了，而代码的实际装入地址也在代码装入是由Windows装载器确定，为此只需要将出现直接寻址地址的代码地址放入重定向表中就能够准确的进行代码重定向操作了。通过DataDirectory中的第六项可以定位重定位表的位置，重定位表通常保存在**.reloc**节中但是在此强调一次，通常但不是必须为此还是通过DataDirectory来寻找重定位表的位置比较靠谱。还需要说明的是重定向表一般不会再程序运行时装入内存，其仅在程序装载时辅助装载器对程序进行重定位操作。为了节约存储空间，重定位表在保存时采用了这样的存储方式即按页保存重定位代码地址，首先保存一个4字节的内存页起始地址，再保存一个此页内重定位代码的项数，最后保存所有的需要重定位操作的代码地址相对于页起始地址的偏移（页内寻址为12位，这里扩展到16位）。这样存储一个页内的所有重定位代码信息就需要4+4+2n字节，这种存储方式在内存页内重定位项数多于4时优于直接存储每个需要重定位代码的地址（4n）。按照这个逻辑关系每个内存页对应着一个重定位块这个块以IMAGE_BASE_RELOCATION开头：

IMAGE_BASE_RELOCATION STRUCT
	VirtualAddress        dd          ;页起始RVA
	SizeOfBlock           dd          ;重定位块的长度 4+4+2*n
IMAGE_BASE_RELOCATION ENDS

上面提到要把12位的页内地址扩展到16位，低12位是原来的地址，高四位也被赋予了具体的函数，如下表所示：

上述表中0和3是最为常见的情况，所有的重定位块终于一个VirtualAddress字段全0的IMAGE_BASE_RELOCATION结构，这时候问题来了，那么RVA为0的内存页中需要重定位的代码如何解决呢？为了解决这个问题所有的可执行文件的代码总是从装入地址的0x1000处开始定义，如下图所示：
1000h
下面结合Winhex与stud_PE分析下某DLL文件重定位表：

首先使用Stud_PE工具在DataDirectory找到重定位表的RVA，如下图所示：
接下来观察更具节信息将RVA转化为磁盘中的偏移地址
为此可以确定重定位表在文件中的偏移地址为0x00191000
使用WinHex打开此程序并定位到0x00191000的位置，如下图所示：

按上图划线部分可以知6个需要重定向代码的RVA为0xC6000、0xC62A8、0xC646F、0xC64B0、0xC64CC、0xC64F2。可以将这些RVA转换为文件偏移去文件中寻找相应指令的机器码，但是不可以使用OD等动态分析工具将文件载入然后去相应的RVA位置查看指令，因为载入后已经完成重定向，里面的代码是重定向后的指令。

总结

PE文件中所有数据都存储的节表中，而这些节表中的数据由于功能不同还被划分到其他的逻辑结构比如DataDirectory。
RVA及物理内存通过节来转换，但是并非所有的RVA都能成功转化为文件偏移地址

for i in 节表:
	if RVA>i.VirtualAddress and RVA < i.VirtualAddress+i.sizeOfRawData:
		文件偏移 = i.PointerToRawData+(RVA-i.VirtualAddress)

大小端是对于数据来说的，而不是指令
操作系统识别可执行文件的方法是依赖于文件头而不是文件扩展名，如果当前文件格式不符合任何已定义文件头格式则将其按照COM文件格式装入即将整个文件的数据当做代码装入执行
节是按照数据属性进行的分类，DataDirectory是按照数据功能进行的分类

Blood_Pupil

关注

4
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
二进制菜鸟之PE文件结构

所谓PE文件就是可执行文件在硬盘中存储是的文件表示，Windows中可执行文件的文件表示的发展途径为com->LE(Linerar executable)->PE(Portable Executable File Formate)。操作系统识别可执行文件的方法是依赖于文件头而不是文件扩展名，如果当前文件格式不符合任何已定义文件头格式则将其按照COM文件格式装入即将整个文件的数据当做代...
复制链接

扫一扫