读取PE文件的导入表
http://blog.csdn.net/zang141588761/article/details/50401203
Image: PE格式镜像文件，这通常就是我们的exe，dll文件。
下面我们定义一些地址相关的概念，因为PE文件位于磁盘上，同时文件又可以被映射到虚拟内存中，在运行PE文件时它也被系统的Loader加载到内存中。所以这里就有了三个空间，如果我们不做一个清楚的说明，在后面我们很容易混淆。
（1）磁盘空间：这里我们使用的地址叫做文件地址（距离文件头部的偏移）。在PE头的相关属性名称中，文件中的数据称为原始数据 （rawData），文件中的数据使用的对齐称为 FileAlignment。
（2）虚拟内存空间：在这里的地址称为虚拟地址（Virtual Address）。同时PE文件的数据装载/映射到内存中后又分以下两种情况：
（a）PE文件的内存视图，即PE文件被映射到内存（MapViewOfFile）：
BaseAddress：内存映射文件的基础地址，从这里看过去，就和从编辑器打开看到的文件内容完全一致。
内存映射通常是处理大文件的一种有效方式。映射后我们在内存中看到的内容就是磁盘文件的一个视图。
因此我们吧PE文件映射到内存以后，通过某个数据的RVA，调用 ImageRvaToVa 可得到某个数据的VA，再减去映射文件的起始地址，就是文件地址。
(b) 进程空间，即在被调度之前，被loader装载到内存的时刻（例如双击执行一个exe）。
这里和前者的视图方式不同，属于一种地址映射关系，文件中的节内容根据NT文件头的信息被加载到进程空间的相应位置。
ImageBase：映射到进程空间的基础地址。
RVA：相对ImageOfBase的偏移。它加上ImageBase就是进程空间的VA。
在PE文件中的DataEntry，Section表中的VirutalAddress基本都属于RVA。
下面介绍以下这个函数：ImageRvaToVa：（注意这个函数要求XP和win2000系统以上，在VC6自带的SDK中没有。。。）
PVOID ImageRvaToVa(
PIMAGE_NT_HEADERS NtHeaders,
PVOID Base,
ULONG Rva,
PIMAGE_SECTION_HEADER* LastRvaSection
);
这个函数在（2）.（a）即内存映射文件后使用，它把RVA根据NT头的信息，换算成内存映射文件中的实际VA。看起来不是在进程空间使用的，因为在进程空间中，ImageBase + Rva 就是VA了，装载后NT头等信息也不再重要了。最后一个参数是可选的，或许是因为如果调用方主动提供，此 API 可提高一定效率（可以直接在节中的地址信息去判断）。第二个参数也可以提供一个假的地址给这个函数，这个函数也能计算。即这个函数不去校验Base是否是一个有效地址，因此实际上我们可以读取出NtHeader的信息后，用一个假地址传给这个函数，再把结果减去这个假地址，即可换算出文件地址。
好了，下面介绍下导入表的定位，这方面的资料和文章在看雪论坛的文集里面有很多。我再这里只做一个比较简洁的介绍。导入表本质上就是位于某个节中的一些数据，这些数据主要是一些C字符串（以0字符为结尾的dll和函数名称）以及一些指针（RVA地址），所以我们主要是需要了解如何定位到导入表，从而打印出导入表的信息。
首先导入表的RVA地址，就在optional Header的DataDirectory的第二个元素中。通过它我们定位到导入表。
导入表类似一个二级索引。一级是一个模块目录（IMAGE_IMPORT_DESCRIPTOR数组，这里把目录理解为一个以全0字节为结束的数组），它的每个元素代表了一个DLL。二级是导入地址表IAT（即 IMAGE_THUNK_DATA 数组，一个指针数组），每个元素指向一个 IMAGE_IMPORT_BY_NAME结构（该结构含有一个函数序号和一个函数名称字符串）。
总结一下，我们的定位过程：
（1）通过 NtHeaders.OptionalHeader.DataDirectory[1].VirtualBase --> 定位到导入表(IID Table)。
（2）遍历每个 IID，直到遇到全0为止。
通过 IID.Name -> 定位到 DLL 名字。
通过 IID.OriginalFirstThunk 或者 FirstThunk -> 定位到IAT ( image_thunk_data32[] )；
遍历指针目录，知道遇到NULL为止。
通过 thunk_data.AddressOfData -> 定位到一个 IMAGE_IMPORT_BY_NAME 的地址，再根据它寻址到真正的函数序号和函数名称。
为什么存在二级指针呢，这是很容易解释的。所以我们需要一个DLL目录，由于DLL名称的长度和函数个数不固定，所以向下扩展了一级，而每个函数的函数名称又是不固定的，所以又要向下扩展一级，这样要找到真正的函数名称必须经过这样两级定向。
因此这个二级索引的导入表就是这样的定位方式（每个数组都是一个高地址方向半开口的样子， C字符串也是这样的字符数组），如下图所示（注意每个数组的元素的size是固定的，但由于数组是半开口，所以数组本身属于size不固定）：
特点就是，每次遇到长度无法预测的成员，就用指针把它从元素中扩展出去（用一个指针指向它），这样我们就保证每个数组的元素都是固定的size，这样它才能成为线性表结构（满足用指针的加减或者[]操作符进行元素读取）。例如DLL的名称是可变长度的，因此它被扔到元素定义的外面去，在元素中保留为一个指针。每个DLL的函数目录也是可变长度的（函数个数是不确定的），因此它在元素中也是一个指针。而函数目录中函数信息又被扔出去，用指针指向它。
下面看一下相关代码，很短，通过上面的讲解，下面的代码就很明了，很简单了：
// ImageRvaToVa.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <stdio.h>
#include <windows.h>
#include <Dbghelp.h> //ImageRvaToVa
int main(int argc, char* argv[])
{
int i, j;
HANDLE hFile = CreateFile(
"E:\\RfCard.exe", //PE文件名
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
if(hFile == INVALID_HANDLE_VALUE)
{
printf("Create File Failed.\n");
return 0;
}
HANDLE hFileMapping = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
if (hFileMapping == NULL || hFileMapping == INVALID_HANDLE_VALUE)
{
printf("Could not create file mapping object (%d).\n", GetLastError());
return 0;
}
LPBYTE lpBaseAddress = (LPBYTE)MapViewOfFile(hFileMapping, // handle to map object
FILE_MAP_READ, 0, 0, 0);
if (lpBaseAddress == NULL)
{
printf("Could not map view of file (%d).\n", GetLastError());
return 0;
}
PIMAGE_DOS_HEADER pDosHeader = (PIMAGE_DOS_HEADER)lpBaseAddress;
PIMAGE_NT_HEADERS pNtHeaders = (PIMAGE_NT_HEADERS)(lpBaseAddress + pDosHeader->e_lfanew);
//导入表的rva：0x2a000;
DWORD Rva_import_table = pNtHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress;
if(Rva_import_table == 0)
{
printf("no import table!");
goto UNMAP_AND_EXIT;
}
//这个虽然是内存地址，但是减去文件开头的地址，就是文件地址了
//这个地址可以直接从里面读取你想要的东西了
PIMAGE_IMPORT_DESCRIPTOR pImportTable = (PIMAGE_IMPORT_DESCRIPTOR)ImageRvaToVa(
pNtHeaders,
lpBaseAddress,
Rva_import_table,
NULL
);
//减去内存映射的首地址，就是文件地址了。。（很简单吧）
printf("FileAddress Of ImportTable: %p\n", ((DWORD)pImportTable - (DWORD)lpBaseAddress));
//现在来到了导入表的面前：IMAGE_IMPORT_DESCRIPTOR 数组（以0元素为终止）
//定义表示数组结尾的null元素！
IMAGE_IMPORT_DESCRIPTOR null_iid;
IMAGE_THUNK_DATA null_thunk;
memset(&null_iid, 0, sizeof(null_iid));
memset(&null_thunk, 0, sizeof(null_thunk));
//每个元素代表了一个引入的DLL。
for(i=0; memcmp(pImportTable + i, &null_iid, sizeof(null_iid))!=0; i++)
{
//LPCSTR: 就是 const char*
LPCSTR szDllName = (LPCSTR)ImageRvaToVa(
pNtHeaders, lpBaseAddress,
pImportTable[i].Name, //DLL名称的RVA
NULL);
//拿到了DLL的名字
printf("-----------------------------------------\n");
printf("[%d]: %s\n", i, szDllName);
printf("-----------------------------------------\n");
//现在去看看从该DLL中引入了哪些函数
//我们来到该DLL的 IMAGE_TRUNK_DATA 数组（IAT：导入地址表）前面
PIMAGE_THUNK_DATA32 pThunk = (PIMAGE_THUNK_DATA32)ImageRvaToVa(
pNtHeaders, lpBaseAddress,
pImportTable[i].OriginalFirstThunk, //【注意】这里使用的是OriginalFirstThunk
NULL);
for(j=0; memcmp(pThunk+j, &null_thunk, sizeof(null_thunk))!=0; j++)
{
//这里通过RVA的最高位判断函数的导入方式，
//如果最高位为1，按序号导入，否则按名称导入
if(pThunk[j].u1.AddressOfData & IMAGE_ORDINAL_FLAG32)
{
printf("\t [%d] \t %ld \t 按序号导入\n", j, pThunk[j].u1.AddressOfData & 0xffff);
}
else
{
//按名称导入，我们再次定向到函数序号和名称
//注意其地址不能直接用，因为仍然是RVA！
PIMAGE_IMPORT_BY_NAME pFuncName = (PIMAGE_IMPORT_BY_NAME)ImageRvaToVa(
pNtHeaders, lpBaseAddress,
pThunk[j].u1.AddressOfData,
NULL);
printf("\t [%d] \t %ld \t %s\n", j, pFuncName->Hint, pFuncName->Name);
}
}
}
UNMAP_AND_EXIT:
//关闭文件，句柄。。
UnmapViewOfFile(lpBaseAddress);
CloseHandle(hFileMapping);
CloseHandle(hFile);
getchar();
return 0;
}
【注意】在上面的代码中我标示为高亮红色字体的部分，我使用的是 OriginalFirstThunk ，对于没有事先绑定的PE文件来说，OriginalFirstThunk 和 FirstThunk 是并行的内容相同的数组。但是对于已经经过绑定的PE文件来说， FirstThunk 数组中的元素会被设置成真正的函数地址（VA）！因此如果这时用 FirstThunk 数组尝试获取函数名称是得不到的。所以上面的代码应该使用 OriginalFirstThunk ，这样无论对于绑定还是未绑定的PE文件，都能够定向到相应的函数名称。
【注意】：
（1）请在项目属性中的链接选项中，添加 Dbghelp.lib;
（2）上面对PE文件的名称采用了硬编码，如果为了灵活期间，可以从命令行获取PE文件的路径。
下面是我用某个PE文件所产生的输出：
FileAddress Of ImportTable: 00028000
-----------------------------------------
[0]: USER32.dll
-----------------------------------------
[0] 198 EndDialog
[1] 158 DialogBoxParamA
-----------------------------------------
[1]: KERNEL32.dll
-----------------------------------------
[0] 265 GetEnvironmentVariableA
[1] 27 CloseHandle
[2] 170 FlushFileBuffers
[3] 294 GetModuleHandleA
[4] 336 GetStartupInfoA
[5] 202 GetCommandLineA
[6] 372 GetVersion
[7] 125 ExitProcess
[8] 81 DebugBreak
[9] 338 GetStdHandle
[10] 735 WriteFile
[11] 429 InterlockedDecrement
[12] 501 OutputDebugStringA
[13] 318 GetProcAddress
[14] 450 LoadLibraryA
[15] 432 InterlockedIncrement
[16] 292 GetModuleFileNameA
[17] 670 TerminateProcess
[18] 247 GetCurrentProcess
[19] 685 UnhandledExceptionFilter
[20] 178 FreeEnvironmentStringsA
[21] 179 FreeEnvironmentStringsW
[22] 722 WideCharToMultiByte
[23] 262 GetEnvironmentStrings
[24] 264 GetEnvironmentStringsW
[25] 621 SetHandleCount
[26] 277 GetFileType
[27] 373 GetVersionExA
[28] 413 HeapDestroy
[29] 411 HeapCreate
[30] 415 HeapFree
[31] 703 VirtualFree
[32] 559 RtlUnwind
[33] 282 GetLastError
[34] 577 SetConsoleCtrlHandler
[35] 440 IsBadWritePtr
[36] 437 IsBadReadPtr
[37] 423 HeapValidate
[38] 191 GetCPInfo
[39] 185 GetACP
[40] 305 GetOEMCP
[41] 409 HeapAlloc
[42] 699 VirtualAlloc
[43] 418 HeapReAlloc
[44] 484 MultiByteToWideChar
[45] 447 LCMapStringA
[46] 448 LCMapStringW
[47] 339 GetStringTypeA
[48] 342 GetStringTypeW
[49] 618 SetFilePointer
[50] 636 SetStdHandle
到这里，我们基本算了解了import table。不过还需要额外解释一下的是，在iid中含有两个指向thunk数组（即IAT：导入地址表）的指针（orignal first thunk 和 first thunk），两个指针指向不同的地址，但这两个thunk数组的元素值是相同的，最终指向的是同一个地址（函数序号和名称元素）。也就是说，thunk数组在PE文件中有两份，他们的地址不同，但最终指向完全相同。画出图形的话是类似下面这样（注意最终指向相同，4个指针画出来类似一个菱形）：
IID.OrignalFirstThunk---> thunk1[] -------\
--------------------------------------------- > IMAGE_IMPORT_BY_NAME ( hint, name [] )
IID.FirstThunk-----------> thunk2[] -------/
即在上面的代码里，用 iid 的无论哪一个thunk指针最终得到的都是相同的结果。PE文件中OrignalFirstThunk是一个对thunk表的原始备份，它始终是不变的。而FirstThunk在系统装载PE以后，将会修改，把他们替换成函数的真正地址（即进行绑定），这时它们就不再是指向函数序号和名称了，而是真正的函数地址（映射到进程空间之内的），你对某个DLL函数的调用在代码中本质上是调用一个存根（因为编译器不知道导入函数的实际地址），在存根处跳转到 FirstThunk 数组指明的实际函数地址。程序一旦运行起来，导入表将不再那么关键了，重要的是实际IAT（FirstThunk）。这时OrignalFirstThunk 数组就成为了一个被替换前的原始备份，当需要重新绑定时（例如DLL版本不对）需要用到它，这是“Orignal” 的含义。First的含义是，指向的是IAT的第一个元素（thunk）。Thunk可能是新造出来的词，没有确切的解释，大概是是被加载后被系统替换掉了值，有真真假假，虚虚实实的语义，同时也有一种说法是有“预先想到”的含义（备注：在ATL中也有Thunk这个词）。
现在我们回头在看下IID和Thunk的定义，可以很好的理解那些注释，IID的OriginalFirstThunk指向的是未绑定之前的IAT（导入地址表），这个IAT表示的是应该导入该DLL的哪些名称（序号）的函数。而FirstThunk在绑定（被替换成实际函数地址）后指向的实际的函数地址。所以Thunk里面是一个union，里面的 AddressOfData 指是绑定之前它指向函数的hint和名称，Function 指的得是绑定后它就成了实际函数地址。
typedef_iid_and_thunk
假如引用的 DLL 是确定的，那么在加载时的函数绑定工作就可以事先完成，在加载时只需要核对以下DLL的时间戳是否吻合（如果不能吻合则和没有绑定一样处理，再次人工绑定），这样就可以节省程序加载的时间，随操作系统提供的一些工具比如记事本，计算器等工具都经过了事先绑定。通过 VC 提供的 Dependency 工具可以查看到你链接的 DLL 是否经过了事先绑定。如果没有绑定，那些导入的函数的地址将显示未绑定（not bound）。借助 IDE 提供的 Bind 工具可以进行预先绑定，从而减少你的程序启动时间。或者通过编程方式，用 BindImageEx 函数去绑定一个 Image 文件。
例如，如果你开发好了应用程序，在打包安装程序之前，可以用这两个命令行工具进行优化，从而加快程序启动的速度。
（1）优化DLL的首选ImageBase:
ReBase.EXE -b 10000000 *.dll
（2）事先绑定DLL：（在客户端上，系统DLL未必是有效的绑定，但是对于你自己提供的DLL，该绑定一定有效）
Bind.EXE -o -u -v 你的可执行文件.exe
经过 Rebase 和 Bind 以后，可以提高你的程序的启动速度。系统提供的DLL都经过了Rebase，这样它们在被加载时几乎总能成功加载到首选的ImageBase。系统提供的工具也基本都经过事先绑定。
IID中的ForwardChain，是函数转发器，即一个DLL文件可以导出一个假定的函数，这个函数是实际上位于另一个DLL中的函数，这样在逻辑上就成为一个“链式结构”，系统在加载时需要分析转发器，把引用的实际DLL映射到进程空间。在操作系统的 Kernel32.dll 中可以看到转发器，比如 Kernel32.dll 中的 HeapAlloc 被转发到 NTDLL 中的 RtlAllocateHeap。但转发器在实际应用中则比较少见。如果要指定一个转发器，需要在代码中使用形式如下面的语句：
#pragma comment ( linker, "/export:FuncName = DllName.SomeOtherFuncName" )
【参考资料】
关于PE文件相关的知识，主要参考：
（1）《看雪论坛五周年精华》（1~9）。
关于函数转发器部分，主要参考：
（2）《Window核心编程》第20章：DLL的高级操作技术。
使用 Rebase 命令行工具重设 DLL 的首选ImageBase：
（3）ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.WIN32COM.v10.en/tools/tools/rebase.htm
使用 Bind 命令工具进行预先绑定：
（4）ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.WIN32COM.v10.en/tools/tools/bind.htm