PE解析思路
2024-2-3 16:49:58 Author: mp.weixin.qq.com(查看原文) 阅读量:18 收藏


0x01 Headers 解析

头部分分为5部分:
◆Dos Header
◆NT Header
◆FileHeader
◆Optional Header
◆Section Header

Dos Header

Dos部分为兼容古老的DOS 16位系统,目前来说用处已经不大,整体结构在winnt.h中定义为:
typedef struct _IMAGE_DOS_HEADER { // DOS .EXE header
WORD e_magic; // Magic number
WORD e_cblp; // Bytes on last page of file
WORD e_cp; // Pages in file
WORD e_crlc; // Relocations
WORD e_cparhdr; // Size of header in paragraphs
WORD e_minalloc; // Minimum extra paragraphs needed
WORD e_maxalloc; // Maximum extra paragraphs needed
WORD e_ss; // Initial (relative) SS value
WORD e_sp; // Initial SP value
WORD e_csum; // Checksum
WORD e_ip; // Initial IP value
WORD e_cs; // Initial (relative) CS value
WORD e_lfarlc; // File address of relocation table
WORD e_ovno; // Overlay number
WORD e_res[4]; // Reserved words
WORD e_oemid; // OEM identifier (for e_oeminfo)
WORD e_oeminfo; // OEM information; e_oemid specific
WORD e_res2[10]; // Reserved words
LONG e_lfanew; // File address of new exe header
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
目前只用到两个参数,一个是e_magic,该参数为整个PE文件的开头部分,可用于区别ELF和PE。
在PE中,一般表现为0x5A4D,字符串表现为MZ

ELF文件中,表现为:

第二个使用到的参数为DOS Header中的最后一个参数e_lfanew,该参数用来指向exe文件的开始位置,也就是
第二部分Nt Header的位置从Dos Header 到 Nt Header中间空出来的部分数据可以理解为历史残留,都是一些脏数据,一般都会有这样一段话:This program cannot be run in DOS mode

Nt Header

Nt Header 结构体(winnt.h)
typedef struct _IMAGE_NT_HEADERS64 {
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER64 OptionalHeader;
} IMAGE_NT_HEADERS64, *PIMAGE_NT_HEADERS64;

typedef struct _IMAGE_NT_HEADERS {
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;

Nt Header的开头为一个Signature,该值通过宏进行定义为PE文件的固定值,不受32位或者64位影响:
#define IMAGE_NT_SIGNATURE 0x00004550 // PE

File Header

File Header 结构体(winnt.h)
typedef struct _IMAGE_FILE_HEADER {
WORD Machine;
WORD NumberOfSections;
DWORD TimeDateStamp;
DWORD PointerToSymbolTable;
DWORD NumberOfSymbols;
WORD SizeOfOptionalHeader;
WORD Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
这里用到的参数就比较多了,首先是Machine,在wint.h中定义了宏,目前常见的应该只有IMAGE_FILE_MACHINE_I38632位程序和IMAGE_FILE_MACHINE_AMD6464位程序。
#define IMAGE_FILE_MACHINE_UNKNOWN 0
#define IMAGE_FILE_MACHINE_TARGET_HOST 0x0001 // Useful for indicating we want to interact with the host and not a WoW guest.
#define IMAGE_FILE_MACHINE_I386 0x014c // Intel 386.
#define IMAGE_FILE_MACHINE_R3000 0x0162 // MIPS little-endian, 0x160 big-endian
#define IMAGE_FILE_MACHINE_R4000 0x0166 // MIPS little-endian
#define IMAGE_FILE_MACHINE_R10000 0x0168 // MIPS little-endian
#define IMAGE_FILE_MACHINE_WCEMIPSV2 0x0169 // MIPS little-endian WCE v2
#define IMAGE_FILE_MACHINE_ALPHA 0x0184 // Alpha_AXP
#define IMAGE_FILE_MACHINE_SH3 0x01a2 // SH3 little-endian
#define IMAGE_FILE_MACHINE_SH3DSP 0x01a3
#define IMAGE_FILE_MACHINE_SH3E 0x01a4 // SH3E little-endian
#define IMAGE_FILE_MACHINE_SH4 0x01a6 // SH4 little-endian
#define IMAGE_FILE_MACHINE_SH5 0x01a8 // SH5
#define IMAGE_FILE_MACHINE_ARM 0x01c0 // ARM Little-Endian
#define IMAGE_FILE_MACHINE_THUMB 0x01c2 // ARM Thumb/Thumb-2 Little-Endian
#define IMAGE_FILE_MACHINE_ARMNT 0x01c4 // ARM Thumb-2 Little-Endian
#define IMAGE_FILE_MACHINE_AM33 0x01d3
#define IMAGE_FILE_MACHINE_POWERPC 0x01F0 // IBM PowerPC Little-Endian
#define IMAGE_FILE_MACHINE_POWERPCFP 0x01f1
#define IMAGE_FILE_MACHINE_IA64 0x0200 // Intel 64
#define IMAGE_FILE_MACHINE_MIPS16 0x0266 // MIPS
#define IMAGE_FILE_MACHINE_ALPHA64 0x0284 // ALPHA64
#define IMAGE_FILE_MACHINE_MIPSFPU 0x0366 // MIPS
#define IMAGE_FILE_MACHINE_MIPSFPU16 0x0466 // MIPS
#define IMAGE_FILE_MACHINE_AXP64 IMAGE_FILE_MACHINE_ALPHA64
#define IMAGE_FILE_MACHINE_TRICORE 0x0520 // Infineon
#define IMAGE_FILE_MACHINE_CEF 0x0CEF
#define IMAGE_FILE_MACHINE_EBC 0x0EBC // EFI Byte Code
#define IMAGE_FILE_MACHINE_AMD64 0x8664 // AMD64 (K8)
#define IMAGE_FILE_MACHINE_M32R 0x9041 // M32R little-endian
#define IMAGE_FILE_MACHINE_ARM64 0xAA64 // ARM64 Little-Endian
#define IMAGE_FILE_MACHINE_CEE 0xC0EE
可用来区分Windows 下的32位程序和64位程序:
第二个是NumberOfSections,就是节的数量,关于节遍历时需要用到,还有对于节的增加和合并时需要对该参数的值进行修改。
第三个是SizeOfOptionalHeader,关于可选PE头的大小,默认情况下,32位程序该值为E0,64位程序该值为F0。
最后一个参数Characteristic可以理解为操作权限。

Optional Header

Optional Header 结构体(winnt.h)
#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16
pe32:
typedef struct _IMAGE_OPTIONAL_HEADER {
//
// Standard fields.
//

WORD Magic;
BYTE MajorLinkerVersion;
BYTE MinorLinkerVersion;
DWORD SizeOfCode;
DWORD SizeOfInitializedData;
DWORD SizeOfUninitializedData;
DWORD AddressOfEntryPoint;
DWORD BaseOfCode;
DWORD BaseOfData;

//
// NT additional fields.
//

DWORD ImageBase;
DWORD SectionAlignment;
DWORD FileAlignment;
WORD MajorOperatingSystemVersion;
WORD MinorOperatingSystemVersion;
WORD MajorImageVersion;
WORD MinorImageVersion;
WORD MajorSubsystemVersion;
WORD MinorSubsystemVersion;
DWORD Win32VersionValue;
DWORD SizeOfImage;
DWORD SizeOfHeaders;
DWORD CheckSum;
WORD Subsystem;
WORD DllCharacteristics;
DWORD SizeOfStackReserve;
DWORD SizeOfStackCommit;
DWORD SizeOfHeapReserve;
DWORD SizeOfHeapCommit;
DWORD LoaderFlags;
DWORD NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;

pe64:
typedef struct _IMAGE_OPTIONAL_HEADER64 {
WORD Magic;
BYTE MajorLinkerVersion;
BYTE MinorLinkerVersion;
DWORD SizeOfCode;
DWORD SizeOfInitializedData;
DWORD SizeOfUninitializedData;
DWORD AddressOfEntryPoint;
DWORD BaseOfCode;
ULONGLONG ImageBase;
DWORD SectionAlignment;
DWORD FileAlignment;
WORD MajorOperatingSystemVersion;
WORD MinorOperatingSystemVersion;
WORD MajorImageVersion;
WORD MinorImageVersion;
WORD MajorSubsystemVersion;
WORD MinorSubsystemVersion;
DWORD Win32VersionValue;
DWORD SizeOfImage;
DWORD SizeOfHeaders;
DWORD CheckSum;
WORD Subsystem;
WORD DllCharacteristics;
ULONGLONG SizeOfStackReserve;
ULONGLONG SizeOfStackCommit;
ULONGLONG SizeOfHeapReserve;
ULONGLONG SizeOfHeapCommit;
DWORD LoaderFlags;
DWORD NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER64, *PIMAGE_OPTIONAL_HEADER64;
通过对比可以发现在32位的Optional Header中多了一个DWORD BaseOfData。
在不做修改的情况下,OptionalHeader的长度是固定的,所以32位程序在File Header中的SizeOfOptionalHeader为0xE8,而64位程序的SizeOfOptionalHeader为0xF0,通过上图也可以看出在ImageBaseSIzeOfStackReserveSizeOfStackeCommitSizeOfHeapReserve,SizeOfHeapCommit这五个参数中,64位程序的参数长度为ULONGLONG,就是8字节QDWORD,加上少掉的一个DWORD,刚好默认情况下64位程序的OptionalHeader比32位的多0x04*5-0x04=16个字节。
在OptionalHeader的开头Magic参数会再一次显示32位和64位的区别:
在winnt.h中也定义了相关的宏:
#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b
#define IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b
所以总结之后可以得到区分32位和64位程序的方式:
◆通过OptionalHeader->Magic
◆通过FileHeader->Machine
◆通过FileHeader->SizeOfOptionalHeader
OptionalHeader中会用到的参数:
◆AddressOfEntryPoint:程序入口地址,简称为OEP
◆ImageBase:镜像基址
◆SectionAlignment:内存对齐大小
◆FileAlignment:文件对齐大小
OptionalHeader中解析到的OEP为相对偏移并且这个偏移应该是内存对齐后的偏移。
载入x32dbg查看,此时发现OEP的地址为A80233,这时候就要提到ImageBase了,可以看到在OptionalHeader中的ImageBase为0x400000,但是程序此时的ImageBase为0xA80233 - 0x10233 = 0xA70000,这个原因是OptionalHeader中解析到的ImageBase为理想状况下的,内存的地址是连续,0x40000只有一个,所以有且只有一个程序可以刚好分配到0x40000作为镜像基址,那么其他程序怎么办,这时候就会产生一个重定位的情况,这个后面会说到,总之,当程序载入内存时,相对偏移是不会变的,会发生变化的是镜像基址,当然这里指的相对偏移,是指内存对齐后的相对偏移,在PE解析中,存在着文件对齐的情况,特别是该程序中,文件对齐与内存对齐是不一致的,所以当程序从FileBuffer加载到内存成为ImageBuffer后,需要对程序进行拉伸,对齐成内存对齐,那么相应的某些本身处于文件对齐的地址,就需要通过转化,转换成内存对齐地址。
◆SizeOfImage:经过内存对齐后整个镜像大小
◆SizeOfCode:文件对齐下镜像大小
◆SizeOfHeaders: 头+节表文件对齐下的大小
◆BaseOfCode: 内存对齐下代码的开始(一般为SectionAlignment的整数倍)
◆BaseOfData:内存对齐下数据段的开始(一般为SectionAlignment的整数倍)

Section Header

SectionHeader(winnt.h):
#define IMAGE_SIZEOF_SHORT_NAME 8
#define IMAGE_SIZEOF_SECTION_HEADER 40

typedef struct _IMAGE_SECTION_HEADER {
BYTE Name[IMAGE_SIZEOF_SHORT_NAME];
union {
DWORD PhysicalAddress;
DWORD VirtualSize;
} Misc;
DWORD VirtualAddress;
DWORD SizeOfRawData;
DWORD PointerToRawData;
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORD NumberOfRelocations;
WORD NumberOfLinenumbers;
DWORD Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;

节表是整个PE文件最重要的一部分,因为只有通过他进行内存地址的转化,以及各种节都是通过节表进行索引。
◆Name:一个Char数组,用来存储节名

◆Misc:这是一个union联合体,具体的含义这里不作解释,一般表现为VirtualSize,或者直接把它当作VirtualSize也行,这里指的是每个节的未对齐大小

◆VirtualAddress:指的是内存对齐后节的开始地址,这里也是一个相对地址

◆SizeOfRawData:指的是进行文件对齐后的节大小

◆在该文件中,FileAlignment(文件对齐)的大小为0x200,所以这里RawSize就会对齐为0x200的整数倍
◆PointerToRawData:文件对齐后该节的起始地址

通过sizeofHeaders可以看到整个Header的文件对齐长度为0x400,所以第一个节的起始地址就是0x400。

◆PointerToRelocations\PointerToLinenumbers\NumberOfRelocations\NumberOfLinenumbers,暂时用不到:

◆Characteristics:为每个节的权限
这里数值的结果是通过|得到的,参考微软官方的Section Flags:

0x60000020 -> 0x20000000 | 0x40000000 | 0x00000020

  • IMAGE_SCN_MEM_EXECUTE |

    IMAGE_SCN_MEM_READ |

    IMAGE_SCN_CNT_CODE

0x40000040-> 0x40000000 | 0x00000040

  • IMAGE_SCN_MEM_READ |

    IMAGE_SCN_CNT_INITIALIZED_DATA

0xC00000040 -> 0x80000000 | 0x40000000 | 0x00000040

  • IMAGE_SCN_MEM_WRITE |

    IMAGE_SCN_MEM_READ |

    IMAGE_SCN_CNT_INITIALIZED_DATA


Data Directory 解析

Data Directory位于Optional Header,结构体(winnt.h):
typedef struct _IMAGE_DATA_DIRECTORY {
DWORD VirtualAddress;
DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
在Optional中该结构体数组数量为16个:#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16
各个表的序号:
#define IMAGE_DIRECTORY_ENTRY_EXPORT 0 // Export Directory
#define IMAGE_DIRECTORY_ENTRY_IMPORT 1 // Import Directory
#define IMAGE_DIRECTORY_ENTRY_RESOURCE 2 // Resource Directory
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3 // Exception Directory
#define IMAGE_DIRECTORY_ENTRY_SECURITY 4 // Security Directory
#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5 // Base Relocation Table
#define IMAGE_DIRECTORY_ENTRY_DEBUG 6 // Debug Directory
// IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7 // (X86 usage)
#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE 7 // Architecture Specific Data
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8 // RVA of GP
#define IMAGE_DIRECTORY_ENTRY_TLS 9 // TLS Directory
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10 // Load Configuration Directory
#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 11 // Bound Import Directory in headers
#define IMAGE_DIRECTORY_ENTRY_IAT 12 // Import Address Table
#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT 13 // Delay Load Import Descriptors
#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14 // COM Runtime descriptor
该结构体中的Size不影响对于各个表的解析,影响表的解析是VirtualAddress。

Export Directory

typedef struct _IMAGE_EXPORT_DIRECTORY {
DWORD Characteristics;
DWORD TimeDateStamp;
WORD MajorVersion;
WORD MinorVersion;
DWORD Name;
DWORD Base;
DWORD NumberOfFunctions;
DWORD NumberOfNames;
DWORD AddressOfFunctions; // RVA from base of image
DWORD AddressOfNames; // RVA from base of image
DWORD AddressOfNameOrdinals; // RVA from base of image
} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;
前面4个参数可以不用管,重点在后面的6个参数:

◆Name: 指向导出表文件名

◆Base:导出函数的起始序号

◆NumberOfFunctions:导出函数的个数

◆NumberOfNames:以函数名称导出的函数个数

◆AddressOfFunctions:导出函数的地址表,既然是地址,那么宽度就是DWORD

◆AddressOfNames:导出函数的名称表,表中存放的是函数名称字符串的首地址

◆AddressOfNameOrdinals:导出函数的序号表,表中存放的是函数的序号,宽度为Word

PE文件中函数导出有两种方式:

◆序号导出

◆函数名称导出

AddressOfFunctions指向的是一张导出函数表,而NumberOfFunctions是这张表的长度。
AddressOfNames指向的是导出函数名称表,NumberOfNames是该表的长度。
AddressOfNameOrdinals指向的是导出函数的序号表。
这里需要注意导出函数表和其余两张表的长度是不一定相同的,而AddressOfNames和AddressOfNameOrdinals指向的表的长度是一样长度。
注意Ordinals序号表中,序号为偏移值,真的序号应该是要加上导出表中的Base参数的值,作为起始序号:
例:DWORD base = 10;
NameOrdinals Table:

那么真正的序号应该为:

当导出表的DataDirectory中的VirtualAddress为0时,说明该PE文件不存在导出函数,当然这个可以人为修改,在PE解析中需要通过该VirtualAddress找到导出表存储的位置,如果该值为0,则无法找到。
函数名称表AddressOfNames和函数序号表AddressOfNameOrdinals的数量是一样的,当某个函数在导出时写了NoName不以名称导出时,那么此时导出函数序号表中也不会有该函数的函数序号。
通过函数名称找函数地址的步骤:

1.遍历函数名称表,找到对应的函数名称,将其下标作为索引1。

2.通过1得到的索引1在函数序号表中读取索引值,该值再次作为索引2。

3.通过2得到的索引2在函数地址表中读取索引值,该值即为函数地址。

通过函数序号找函数地址的步骤:

1.通过提供的序号,减去导出表结构体中的Base参数,得到的值作为索引。

2.通过索引去函数地址表中读取索引值,该值即为函数地址。

通过对比两种方式的索引可以发现,通过函数序号找函数地址的时候根本不需要用到AddressOfNameOrdinals,Ordinals是跟Names绑定的一张表,所以才会发现这两张表的成员数量是相同的。

Import Directory

typedef struct _IMAGE_IMPORT_DESCRIPTOR {
union {
DWORD Characteristics; // 0 for terminating null import descriptor
DWORD OriginalFirstThunk; // RVA to original unbound IAT (PIMAGE_THUNK_DATA)
} DUMMYUNIONNAME;
DWORD TimeDateStamp; // 0 if not bound,
// -1 if bound, and real date\time stamp
// in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new BIND)
// O.W. date/time stamp of DLL bound to (Old BIND)

DWORD ForwarderChain; // -1 if no forwarders
DWORD Name;
DWORD FirstThunk; // RVA to IAT (if bound this IAT has actual addresses)
} IMAGE_IMPORT_DESCRIPTOR;
typedef IMAGE_IMPORT_DESCRIPTOR UNALIGNED *PIMAGE_IMPORT_DESCRIPTOR;

通过DataDirectory索引到的VirtuallAddress为导入表的描述符,Name为该导入dll的名称,为偏移量,这里所有的描述符的值都可以理解为偏移,偏移到的是真正存储的位置,这里通过ForwarderChain来确定是否是最后一张导入表描述符,通过,如果该值为-1,则说明该描述符为最后一个导入表描述符。

INT 和 IAT

INT:Import Name Table,根据名称找函数。
IAT:Import Address Table,根据地址找函数。
文件加载前:
OriginalFirstThunk指向的是INT表,INT表中就会涉及到新的结构体:IMAGE_THUNK_DATA,该结构体同样是属于偏移,所以会区分32位和64位。
typedef struct _IMAGE_THUNK_DATA64 {
union {
ULONGLONG ForwarderString; // PBYTE
ULONGLONG Function; // PDWORD
ULONGLONG Ordinal;
ULONGLONG AddressOfData; // PIMAGE_IMPORT_BY_NAME
} u1;
} IMAGE_THUNK_DATA64;
typedef IMAGE_THUNK_DATA64 * PIMAGE_THUNK_DATA64;

typedef struct _IMAGE_THUNK_DATA32 {
union {
DWORD ForwarderString; // PBYTE
DWORD Function; // PDWORD
DWORD Ordinal;
DWORD AddressOfData; // PIMAGE_IMPORT_BY_NAME
} u1;
} IMAGE_THUNK_DATA32;
typedef IMAGE_THUNK_DATA32 * PIMAGE_THUNK_DATA32;

FirstThunk指向的IAT表,IAT表中的结构体跟INT表中的结构体完全相同。(ps:文件加载前)
其原因跟THUNK结构体中的类型有关,可以看到该结构体实际上内部是一个union包着4个参数,长度为DWORD,只需要看后面两个,Ordinal和AddressOfData。

◆Ordinal为序号,通过序号去查找函数位置。

◆AddressOfData为函数名称的地址,通过导入表中函数的导出名称去查找。

在程序加载前,对于每个导入表的导出函数而言,是无法知道其是否可以通过函数名称进行查找的,所以此时才有了INT和IAT。
查找IAT表有两种办法,一个是通过DataDirectory[13],第二个是通过导入表中的FirstThunk偏移找到IAT表的起始位置
文件加载后:
INT中的数据不变,IAT中的值替换成函数地址,函数地址通过INT或者IAT进行替换。
在查找时,如果文件不存在

Relocation Directory

重定位表关乎到程序能否正常运行,该表的解析很有意思。
通过Data Directory[IMAGE_DIRECTORY_ENTRY_BASERELOC]定位到第一张表的指针位置,同样需要通过RVAToRAW拿到文件中存放该表的位置。
Relocation结构体:
typedef struct _IMAGE_BASE_RELOCATION {
DWORD VirtualAddress;
DWORD SizeOfBlock;
// WORD TypeOffset[1];
} IMAGE_BASE_RELOCATION;
typedef IMAGE_BASE_RELOCATION UNALIGNED * PIMAGE_BASE_RELOCATION;
既然是表,就说明不止有这一个结构体,这里的索引也是同样的,通过当前的指针来索引下一个表的位置,最后通过结构体全0来判断该表的结束:
VirtualAddress == 0 && SizeOfBlock == 0
SizeOfBlock表明指向的Relocation结构体的实际大小,该大小是包括已知两个参数的大小:所以实际的大小应该为SizeOfBlock - 8,在32位程序中,块大小为2的12次方,也就是4096,所以只需要12位就可以遍历整个块,根据字节对齐需要,编译器对程序进行分配时不会直接分12位,而是会分16位,也就是2个字节,所以对于该2字节,低12位为偏移,高4位为填充,当高4位的值为3时,说明该地址需要被重定位,如果为其他值,则说明该2字节的值可作为填充数据处理。
this->pRelocation = (PIMAGE_BASE_RELOCATION) & (((PBYTE)lpBuffer)[this->RVAToRAW((this->pDataDirectory + 5)->VirtualAddress)]);

PIMAGE_BASE_RELOCATION pTmpRelocation = pe->pRelocation;
while (pTmpRelocation->VirtualAddress != 0 && pTmpRelocation->SizeOfBlock != 0) {
PWORD pBlock = (PWORD)(pTmpRelocation + 1);
cout << "VirtualAddr: " << pTmpRelocation->VirtualAddress << " Size: " << pTmpRelocation->SizeOfBlock;

int items = (pTmpRelocation->SizeOfBlock - 8) / 2;
cout << " Items: " << items << endl;

for (int i = 0; i < items ; i++) {
cout << "Item: " << * pBlock << " RVA: " << pTmpRelocation->VirtualAddress + ( * pBlock & 0x7F) << endl;
pBlock++;
}
cout << endl;
pTmpRelocation = (PIMAGE_BASE_RELOCATION)((PBYTE)pTmpRelocation + pTmpRelocation->SizeOfBlock);
}

打印结果:
通过这几张表的解析也可以发现PE的特点,由于程序的大小不确定,所以无法静态or动态的分配空间给各种表,所以通过自索引的方式来实现表的遍历,实现了程序的可扩展性,这确实是一种好的方式,这个结构的优点也一直延续至今。

Resource Directory

该表分成三层进行解析。
First Layer:
第一层为资源样式,最后两个参数之和决定资源数:
DWORD resourceNum = NumberOfNamedEntries + NumberOfIdEntries
typedef struct _IMAGE_RESOURCE_DIRECTORY {
DWORD Characteristics;
DWORD TimeDateStamp;
WORD MajorVersion;
WORD MinorVersion;
WORD NumberOfNamedEntries;
WORD NumberOfIdEntries;
// IMAGE_RESOURCE_DIRECTORY_ENTRY DirectoryEntries[];
} IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;
在该结构体后紧跟的就是第二层,resourceNum决定后面跟着多少个_IMAGE_RESOURCE_DIRECTORY_ENTRY
PIMAGE_RESOURCE_DIRECTORY_ENTRY = (PIMAGE_RESOURCE_DIRECTORY_ENTRY)(PIMAGE_RESOURCE_DIRECTORY + 1)
typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {
union {
struct {
DWORD NameOffset:31;
DWORD NameIsString:1;
} DUMMYSTRUCTNAME;
DWORD Name;
WORD Id;
} DUMMYUNIONNAME;
union {
DWORD OffsetToData;
struct {
DWORD OffsetToDirectory:31;
DWORD DataIsDirectory:1;
} DUMMYSTRUCTNAME2;
} DUMMYUNIONNAME2;
} IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;
该结构体为两个2联合体,第一个union中的NameIsString表示该资源是否通过字符串进行索引,该值为1时说明通过字符串进行索引,说明该资源为开发者资源,该值为0说明通过Id进行索引,说明该资源为系统资源,第二个union中的DataIsDirectory表示该数据是否是一个目录,值为1说明该数据为目录。
Windows预定义了一些资源,位于winuser.h,一般只用到前面的11个资源,预定义的资源都是通过ID进行索引。
/*
* Predefined Resource Types
*/
#define RT_CURSOR MAKEINTRESOURCE(1)
#define RT_BITMAP MAKEINTRESOURCE(2)
#define RT_ICON MAKEINTRESOURCE(3)
#define RT_MENU MAKEINTRESOURCE(4)
#define RT_DIALOG MAKEINTRESOURCE(5)
#define RT_STRING MAKEINTRESOURCE(6)
#define RT_FONTDIR MAKEINTRESOURCE(7)
#define RT_FONT MAKEINTRESOURCE(8)
#define RT_ACCELERATOR MAKEINTRESOURCE(9)
#define RT_RCDATA MAKEINTRESOURCE(10)
#define RT_MESSAGETABLE MAKEINTRESOURCE(11)

#define DIFFERENCE 11
#define RT_GROUP_CURSOR MAKEINTRESOURCE((ULONG_PTR)(RT_CURSOR) + DIFFERENCE)
#define RT_GROUP_ICON MAKEINTRESOURCE((ULONG_PTR)(RT_ICON) + DIFFERENCE)
#define RT_VERSION MAKEINTRESOURCE(16)
#define RT_DLGINCLUDE MAKEINTRESOURCE(17)
#if(WINVER >= 0x0400)
#define RT_PLUGPLAY MAKEINTRESOURCE(19)
#define RT_VXD MAKEINTRESOURCE(20)
#define RT_ANICURSOR MAKEINTRESOURCE(21)
#define RT_ANIICON MAKEINTRESOURCE(22)
#endif /* WINVER >= 0x0400 */
#define RT_HTML MAKEINTRESOURCE(23)
#ifdef RC_INVOKED
#define RT_MANIFEST 24
#define CREATEPROCESS_MANIFEST_RESOURCE_ID 1
#define ISOLATIONAWARE_MANIFEST_RESOURCE_ID 2
#define ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID 3
#define ISOLATIONPOLICY_MANIFEST_RESOURCE_ID 4
#define ISOLATIONPOLICY_BROWSER_MANIFEST_RESOURCE_ID 5
#define MINIMUM_RESERVED_MANIFEST_RESOURCE_ID 1 /* inclusive */
#define MAXIMUM_RESERVED_MANIFEST_RESOURCE_ID 16 /* inclusive */
#else /* RC_INVOKED */
#define RT_MANIFEST MAKEINTRESOURCE(24)
#define CREATEPROCESS_MANIFEST_RESOURCE_ID MAKEINTRESOURCE( 1)
#define ISOLATIONAWARE_MANIFEST_RESOURCE_ID MAKEINTRESOURCE(2)
#define ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID MAKEINTRESOURCE(3)
#define ISOLATIONPOLICY_MANIFEST_RESOURCE_ID MAKEINTRESOURCE(4)
#define ISOLATIONPOLICY_BROWSER_MANIFEST_RESOURCE_ID MAKEINTRESOURCE(5)
#define MINIMUM_RESERVED_MANIFEST_RESOURCE_ID MAKEINTRESOURCE( 1 /*inclusive*/)
#define MAXIMUM_RESERVED_MANIFEST_RESOURCE_ID MAKEINTRESOURCE(16 /*inclusive*/)
#endif /* RC_INVOKED */
#endif /* !NORESOURCE */

关于资源表的结构可以理解为资源管理器,在文件夹中即可以创建文件也可以创建文件夹,所以在解析该结构的时候可以通过递归去做解析。

参考文章

[1]PE整体结构体:https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
[2]资源表解析:https://www.cnblogs.com/iBinary/p/7712932.html

看雪ID:Gushang

https://bbs.kanxue.com/user-home-855622.htm

*本文为看雪论坛优秀文章,由 Gushang 原创,转载请注明来自看雪社区

# 往期推荐

1、区块链智能合约逆向-合约创建-调用执行流程分析

2、在Windows平台使用VS2022的MSVC编译LLVM16

3、神挡杀神——揭开世界第一手游保护nProtect的神秘面纱

4、为什么在ASLR机制下DLL文件在不同进程中加载的基址相同

5、2022QWB final RDP

6、华为杯研究生国赛 adv_lua

球分享

球点赞

球在看


文章来源: https://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458540526&idx=1&sn=906b9949aad9cf0269d1f0adf9911c95&chksm=b18d696486fae072ba1f8bd07c329b88065e83671b7df5c6c9010f217b556c12f3f6dc9713c4&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh