注:题目来自于以下链接地址:http://www.pediy.com/kssd/
目录:第13篇 论坛活动 \ 金山杯2007逆向分析挑战赛 \ 第一阶段 \ 第二题 \ 题目 \ [第一阶段 第二题]
题目描述:
己知是一个 PE 格式 EXE 文件,其三个(section)区块的数据文件依次如下:(详见附件)
_text,_rdata,_data
1. 将 _text, _rdata, _data 合并成一个 EXE 文件,重建一个 PE 头,一些关键参数,如 EntryPoint,ImportTable 的 RVA,请自己分析文件获得。合并成功后,程序即可运行。
2. 请在第1步获得的EXE文件基础上,增加菜单。具体见图:
3. 执行菜单 Help / About 弹出如下图所示的 MessageBox 窗口:
题目分析和解答:
(一)拼接可执行文件:
首先下载题目的附件,附件中已经有三个文件,分别是 PE 文件的三个 section,可以看到三个 section 文件已经按照 0x1000 大小对齐。这样我们只需要把这三个文件依次连接在一起,接在一个正确的 PE 文件头后面就可以了。
可以先用 VC (我采用 VS2005)创建一个 Windows 窗口程序(它将提供一些主要样本,所以称这个程序为样本程序),把程序写的尽可能和题目中的程序类似,然后编译,即首先得到了一个 PE 文件头的原型,再次基础上进行修改,也就是根据题目给出的 section,适当调整 PE 文件头中的需要修改的字段。
在本题求解过程中,我严重依赖于我从前写的一个展示 PE 文件格式的应用程序,此程序最近经过我的调整和改进,它的优点是由于此程序基于扩展 TreeView 控件,因此帮助快速理解 PE 文件头的结构,其效果见以下截图:
关于此程序的更多信息,请参见我的博客文章:《[VC6] 图像文件格式数据查看器》。
BmpFileView 的可执行文件的下载链接(不敢说它是最好的,但作为帮助学习PE文件格式的辅助工具而强烈推荐):
http://files.cnblogs.com/hoodlum1980/BmpFileView_V2_Bin.zip
观察题目给出的三个 section 文件,可以给出这三个 section 的基本信息如下:
SectionName | VirtualAddress | RawDataSize | VirtualSize |
---|---|---|---|
.text | 1000h | 6000h | 5B73h |
.rdata | 7000h | 1000h | 0C6Eh |
.data | 8000h | 3000h | 4000h |
.rsrc | B000h |
其中,.rsrc 是需要在稍后插入的资源 section,将在稍后讲解。
这里需要特别注意的是,.data 的虚拟内存尺寸,必须要比文件尺寸(RawDataSize)更大一些,关于这一点我还暂时不能给出详细的解释,有待于在将来做进一步研究。如果把 .data 的 VirtualSize 设置为和 RawDataSize 一样大(3000h),则程序无法运行,会弹出一个消息框提示这不是一个有效的 Win32 程序。所以这一步我也是反复尝试是否是其他字段的问题,纠结了半天才发现原来问题卡在这个地方。
对于 PE 文件头的 IMAGE_OPTINAL_HEADER.CheckSum,Windows 看起来完全忽略这个字段的值,所以这个字段可以不用管。
明确了以上问题,现在可以把这三个 section 和文件头链接成一个新的 PE 文件了,把样本程序 pediy02.exe 和三个 section 文件放在同一个目录下,通过一个辅助的 Console 项目(pediy02_helper 项目)来完成这些工作,生成的新的 PE 文件名为 pediy02_new.exe,使用的辅助函数如下(为了简单明了起见,代码中并没有插入繁琐的检测性代码,例如申请的缓冲区大小,已经根据需要,在编码时被静态的确定了):
Code 1.1 将三个 Section 拼接成 PE 文件的 C++ 代码:
void WriteToFile(FILE *fp, void* pBuf, DWORD nSize); int CreateNewPe() { //PIMAGE_IMPORT_DESCRIPTOR pImportTable = NULL; PIMAGE_DOS_HEADER pDosHdr = NULL; PIMAGE_NT_HEADERS pNtHdrs = NULL; PIMAGE_SECTION_HEADER pSectionHdr = NULL; FILE *fp1, *fp2, *fp3; TCHAR szPath[MAX_PATH]; LPCTSTR szNames[3] = { _T("_text"), _T("_rdata"), _T("_data") }; _stprintf_s(szPath, _T("%s\\pediy02.exe"), THE_DIR); _tfopen_s(&fp1, szPath, _T("rb")); _stprintf_s(szPath, _T("%s\\pediy02_new.exe"), THE_DIR); _tfopen_s(&fp2, szPath, _T("wb")); //读取文件头部 void* buf = malloc(0xD000); fread(buf, 1, 0x1000, fp1); pDosHdr = (PIMAGE_DOS_HEADER)buf; pNtHdrs = (PIMAGE_NT_HEADERS)((DWORD)buf + pDosHdr->e_lfanew); pSectionHdr = (PIMAGE_SECTION_HEADER)((DWORD)pNtHdrs + sizeof(IMAGE_NT_HEADERS)); /* ---------------------------------------------- | section | addr | RawDataSize | VirtualSize | |---------+-------+--------------+-------------| | .text | 1000h | 6000h | 5B73h | | .rdata | 7000h | 1000h | 0C6Eh | | .data | 8000h | 3000h | 4000h | | .rsrc | B000h | 1000h | 1000h | ---------------------------------------------- */ pNtHdrs->FileHeader.NumberOfSections = 4; pNtHdrs->OptionalHeader.BaseOfCode = 0x1000; pNtHdrs->OptionalHeader.BaseOfData = 0x8000; //+1000h 的 .rsrc pNtHdrs->OptionalHeader.SizeOfCode = 0x6000; pNtHdrs->OptionalHeader.SizeOfImage = 0xD000; pNtHdrs->OptionalHeader.SizeOfInitializedData = 0x5000; pNtHdrs->OptionalHeader.SizeOfUninitializedData = 0; pNtHdrs->OptionalHeader.AddressOfEntryPoint = 0x1527; //入口点 //IMAGE_DIRECTORY_ENTRY_IMPORT 需要进一步调整, kernel32.dll, gdi32.dll, user32.dll 加上一个结尾 pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress = 0x7618; pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].Size = sizeof(IMAGE_IMPORT_DESCRIPTOR) * (3 + 1); //资源表 pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE].VirtualAddress = 0xC000; pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE].Size = 0x011C; // IMAGE_DIRECTORY_ENTRY_DEBUG 6 pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_DEBUG].VirtualAddress = 0; pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_DEBUG].Size = 0; // IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10 pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG].VirtualAddress = 0; pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG].Size = 0; //IMAGE_DIRECTORY_ENTRY_IAT 12; (import address table), IMAGE_IMPORT_DESCRIPTOR.FirstTrunk 中的最小值 //IAT 地址需要在修改后找,需要进一步调整 //IAT 的地址通常就是 .rdata 的起始地址 //Size 是 FirstTrunk 中的最大地址 - IAT 起始地址) + 8; //(其中 +4 是最后一个元素占用的空间,再 +4 是一个NULL元素,表示结尾) pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IAT].VirtualAddress = 0x7000; pNtHdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IAT].Size = 0x012C; //section_headers //.text pSectionHdr[0].VirtualAddress = 0x1000; pSectionHdr[0].SizeOfRawData = 0x6000; pSectionHdr[0].PointerToRawData = 0x1000; pSectionHdr[0].Misc.VirtualSize = 0x5B73; //.rdata pSectionHdr[1].VirtualAddress = 0x7000; pSectionHdr[1].SizeOfRawData = 0x1000; pSectionHdr[1].PointerToRawData = 0x7000; pSectionHdr[1].Misc.VirtualSize = 0x1000; //.data //.data 的虚拟内存大小(VirtualSize)必须比文件中更大,否则无法启动,现在我也不知道为什么 pSectionHdr[2].VirtualAddress = 0x8000; pSectionHdr[2].SizeOfRawData = 0x3000; pSectionHdr[2].PointerToRawData = 0x8000; pSectionHdr[2].Misc.VirtualSize = 0x4000; //【重要!】必须比 SizeofRawData 大一些 //.rsrc (resource) 因为.data 比文件中大,所以.rsrc 相应的要像高地址移动 pSectionHdr[3].VirtualAddress = 0xC000; pSectionHdr[3].SizeOfRawData = 0x1000; pSectionHdr[3].PointerToRawData = 0xB000; //文件中的地址还是紧靠.data pSectionHdr[3].Misc.VirtualSize = 0x011C; //从范本文件中得到该值 fwrite(buf, 1, 0x1000, fp2); fflush(fp2); int i; DWORD dwFileSize; for(i = 0; i < 3; i++) { _stprintf_s(szPath, _T("%s\\%s"), THE_DIR, szNames[i]); _tfopen_s(&fp3, szPath, _T("rb")); fseek(fp3, 0, SEEK_END); dwFileSize = ftell(fp3); fseek(fp3, 0, SEEK_SET); fread(buf, 1, dwFileSize, fp3); fclose(fp3); WriteToFile(fp2, buf, dwFileSize); } //从已有的范本复制 .rsrc 节 fseek(fp1, 0xB000, SEEK_SET); fread(buf, 1, 0x1000, fp1); WriteToFile(fp2, buf, 0x1000); fclose(fp1); fclose(fp2); free(buf); return 0; }
//写入文件,以 1KB 为单位 void WriteToFile(FILE *fp, void* pBuf, DWORD nSize) { //以1KB为基本单位,逐次写入 char* pos = (char*)pBuf; size_t BytesToWrite; while(nSize > 0) { BytesToWrite = min(nSize, 0x400); fwrite(pos, 1, BytesToWrite, fp); fflush(fp); nSize -= BytesToWrite; pos += BytesToWrite; } }
上面的函数已经是最终版本的函数,它已经完成了以下工作:
(1)确定 AddressOfEntryPoint 的地址。
(2)确定 DataDirectory[1]: ImportTable (导入表)的地址和尺寸。
(3)确定 DataDirectory[12]: Import Address Table (绑定导入函数地址表)的地址和尺寸。
(4)从样本程序 pediy02.exe 中插入资源 (.rsrc) section,并确定 DataDirectory[2]: resource Table (资源表)的地址和尺寸。
当然很显然上面的工作并不是一步到位完成的,下面简要介绍上面的工作是如何完成的:
(1)确定入口点地址:
该工作相对简单容易,先把 EntryPoint 设置为 .text (代码段)的起始地址:0x1000,然后生成文件后,加载到 IDA 中分析代码段的内容,就可以很容易的找到以下函数的地址(以下地址为 VA,即加上了 ImageBase 后的地址):
0x00401527: __tmainCRTStartup,是 PE 文件的实际入口点。
0x004011EC: WinMain,高级语言编程时的程序入口点。
0x004012D5: WndProc, 当前的窗口过程(稍后将会被子类化)
0x004059C4: sub_4059C4,基本等价于 MessageBoxA,很重要,称它为 ___crtMessageBoxA。
现在只要知道,在文件头中把入口地址设置到 __tmainCRTStartup 函数即可,文件头要求的是 RVA,因此在代码中设置入口点:
IMAGE_NT_HEADERS.IMAGE_OPTIONAL_HEADER.AddressOfEntryPoint = 0x1527;
这样入口点地址就确定好了。
(2)确定 DataDirectory [1] 导入表的地址和大小:
这一步也相对比较简单,导入表位于 .rdata 中(位于中部)。在此之前,必须了解导入表的结构,导入表是一个由多个 IMAGE_IMPORT_DESCRIPTOR 元素组成的数组,以 NULL 元素(内容全部是 0 )标识结尾(IMAGE_IMPORT_DESCRIPTOR 的数据结构定义参见 winnt.h)。每个元素由 5 个 DWORD 组成,其中倒数第二个 DWORD 是 Name 字段(字符串指针),它的值是一个 RVA(即相对于 ImageBase 的偏移),指向了 Dll 名字(ASCII)字符串(该字符串同样位于 .rdata 中)。
导入表的示意结构如下图所示(图中展示的是两个 Thunk 数组并行情况,因此 FirstThunk 也是字符串指针的大多数情况,图中的字符串虽然位于整齐的矩形格子之内,这只是为了图形外观,应该强调的是这些字符串的长度是不固定的,长度有长有短,所以它们在空间中的分布是参差不齐的):
上图表示了 pediy2_new.exe 的实际导入表,共导入了 3 个 DLL,每个导入 DLL 是导入表中的一个元素,在这个数组中的每个元素大小为 20 Bytes,如果引用了 3 个 DLL,则这个数组一共为 (3 + 1) * 20 = 80 Bytes (最后有一个 null terminator element)。下面是单个元素 descriptor 大小:
sizeof ( IMAGE_IMPORT_DESCRIPTOR ) = sizeof ( DWORD ) * 5 = 20 Bytes;
每个元素的 OriginalFirstTrunk 和 FirstTrunk 是两个指针,指向了两个 并行的指针数组,通常情况下(即没有在链接时事先绑定)这两个数组的内容是相同的(即两个数组的所有元素的值相同),在静态 PE 文件中,都指向相同的长度不固定的函数名称字符串(或者是被导入函数的 Ordinal)。
补充说明:在没有经过事先绑定时,OriginalFirstTrunk 和 FirstTrunk 指向的数组内容在加载之前都指向 .rdata 中的一些长度不固定的 Ascii 编码的字符串,在加载时 FirstTrunk 指向的数组被系统绑定成映射到本进程的 DLL 的实际函数地址(因此该数组称为 IAT),所以这些元素称为 Trunk (意味着其身份的可变性,这些元素在加载后其身份发生了变化),因为指向的是数组头部,所以称之为 First(IMAGE_IMPORT_DESCRIPTOR.(Original)FirstTrunk 表示某个 DLL 被本模块导入的首个函数的 Trunk 的位置,后面还有更多的函数 Trunk,以 NULL 表征结束)。OriginalFirstTrunk 在加载后保持不变(所以称为 Original),所以相当于存储着导入函数名称的一份副本。在模块被加载后,可以通过 OriginalFirstTrunk 数组了解到该模块导入了哪些函数(名称),通过 FirstTrunk 数组的内容可了解到导入函数的运行时虚拟地址。导入函数的实际地址是在加载时绑定的(无法在编译时确定),编译器可能为每个 dll 函数调用生成一个很小的函数体,称为 j_XXX, 该函数体负责 jmp 到 FirstTrunk 数组中的元素给出的运行时函数地址,也可以直接调用 IAT 元素内容指向的 VA 地址。
虽然应用程序可以通过序号导入函数,并具有极高效率,但是这样会导致看不到导入函数的名字,对程序和系统的维护造成障碍。所以除非成本太高(例如 MFC 类库的导出函数过多,且面向对象的 C++ 函数名称也很长,所以 MFC 类库的函数以 Ordinal 方式被导入),按名称导入是普遍做法,显然按名称导入,需要线性搜索模块的导出函数表,这就会消耗一定的加载时间成本。为了提高程序加载时效率,应用程序可以通过 “事先 Rebase” (将程序需要导入的模块自身建议的 ImageBase 进行精心调整,从而避免在加载时重定向) 和 “事先绑定” 提高程序在客户运行环境的加载速度,系统通过时间戳判定绑定信息是否有效,如果时间戳不一致,或者发生重定向,系统则必须再次进行加载时绑定。
OriginalFirstTrunk 和 FirstTrunk 指向的这两个指针数组位于 .rdata 的不同位置,其中 FirstTrunk 指向的数组位于 .rdata 的起始位置(稍后可以看到这就是 IAT),OriginalFirstTrunk 指向的数组位于稍微靠后的位置。两个 Trunk 在 PE 文件中的值都指向相同的 IMAGE_IMPORT_BY_NAME (由 Hint 和 函数名称字符串 组成的数据结构)。IAT 所在的页面将在加载时被临时设定为可写,绑定之后再恢复为只读。有关这部分的细节请参考我的博客文章:《读取PE文件的导入表》。
关于导入表和 IAT 的在内存空间中的位置布局,请参考本文的补充讨论(2)。
了解了导入表结构,就可以很快找到导入表的位置了,首先在 .rdata 中查找 DLL 名称字符串,可以找到如下的字符串:
FA: 0x000077AC: "KERNEL32.dll"; (这里使用的是文件地址 FA,或者说是 RVA)
找到附近指向该位置的指针,即在附近的文件内容中搜索 "AC 77 00 00" 片段,可以找到文件地址:
FA: 0x00007624: AC 77 00 00
这里就是一个 IMAGE_IMPORT_DESCRIPTOR 元素,把该地址减去 3 个 DWORD 值,即得到该元素的起始地址为 0x00007618。由于导入表元素内容非常有特点,很容易就可以判断导入表的两端边界,因此可以很快确定导入表的起始地址(RVA)和 Size 如下:
IMAGE_NT_HEADERS.IMAGE_OPTIONAL_HEADER.DataDirectory[2].VirtualAddress = 0x7618;
IMAGE_NT_HEADERS.IMAGE_OPTIONAL_HEADER.DataDirectory[2].Size = sizeof ( IMAGE_IMPORT_DESCRIPTOR ) * 4;
(3)确定 DataDirectory [12],IAT的地址和大小:
IAT 的地址比较简单,它就是所有 DLL 的 FirstTrunk 字段的最小值,通常就是 .rdata 的起始位置(那些常量字符串位于 IAT 和 ImportTable 的后面),也就是 0x7000 (可以看到这里是从 Gdi32.dll 的导入的第一个函数 DeleteObject)。
要计算 IAT 的大小,需要遍历导入表,找到导入的所有 Dll 的 FirstTrunk 的最后一个元素的位置,同时还要考虑到结尾还需要一个 NULL 指针作为结束标志,所以:
IAT.Size = max ( 所有 DLL 的 FirstTrunk 数组元素所在的地址(RVA) ) - IAT.VirtualAddress (RVA) + 8 。
有关如何遍历导入表的更多内容,请参考我的博客文章(在此就不再详细叙述了):《读取PE文件的导入表》。
本题目中所有的 Trunk 的最大地址(RVA)是 0x7124(从 USER32.dll 导入的 DispatchMessageA),可得:
DataDirectory[12].VirualAddress = 0x7000; // RVA (Relative to ImageBase )
DataDirectory[12].Size = 0x012C;
经过以上修改,可以通过 CreateNewPe 函数,生成一个可以执行的 PE 文件了。题目的前半部分要求此时完成。接下来考虑后半部分要求,为程序添加菜单和相关的命令处理函数。
(二)添加菜单 和 处理函数。
(1)添加 .rsrc section (菜单资源)
添加资源,同样通过在样本程序中实现。在样本程序中,添加题目要求一样的资源(只保留菜单,删除所有其他种类资源,这样可以使 .rsrc 最小,仅占用 1000h 大小),然后可以从样本程序中拷贝 .rsrc 段,追加到我们已经得到的 PE 文件的尾部。同时调整 PE 文件头中的相关字段。
注意:由于 .data 节在加载到虚拟内存中时被扩大了 1000h,所以位于最后的 .rsrc 的文件地址(FA)和虚拟地址(VA)将会偏差 1000h。即:
VA = FA + 1000h;
众所周知,窗口的菜单通常是在注册窗口类时指定的。因此为了添加菜单,在 IDA 中观察 WinMain 函数的代码:
Code 2.1 由 .text 提供的 WinMain 函数的汇编代码:
.text:004011EC ; int __stdcall WinMain(int,int,int,int nCmdShow) .text:004011EC WinMain proc near ; CODE XREF: start+C9p .text:004011EC .text:004011EC WndClass = WNDCLASSA ptr -50h .text:004011EC Msg = MSG ptr -28h .text:004011EC var_C = dword ptr -0Ch .text:004011EC arg_0 = dword ptr 8 .text:004011EC nCmdShow = dword ptr 14h .text:004011EC .text:004011EC push ebp .text:004011ED mov ebp, esp .text:004011EF sub esp, 50h .text:004011F2 push ebx .text:004011F3 push esi .text:004011F4 push edi .text:004011F5 mov esi, offset aPediy_com ; "pediy.com" .text:004011FA lea edi, [ebp+var_C] .text:004011FD mov ebx, [ebp+arg_0] .text:00401200 movsd ; char var_C[] = "pediy.com"; 【重要暗示!!!】 .text:00401201 movsd .text:00401202 movsw .text:00401204 mov edi, 7F00h .text:00401209 xor esi, esi .text:0040120B push edi ; lpIconName .text:0040120C push esi ; hInstance .text:0040120D mov dword_40ABAC, ebx .text:00401213 mov [ebp+WndClass.style], 3 .text:0040121A mov [ebp+WndClass.lpfnWndProc], offset sub_406B80 .text:00401221 mov [ebp+WndClass.cbClsExtra], esi .text:00401224 mov [ebp+WndClass.cbWndExtra], esi .text:00401227 mov [ebp+WndClass.hInstance], ebx .text:0040122A call ds:LoadIconA .text:00401230 push edi ; lpCursorName .text:00401231 push esi ; hInstance .text:00401232 mov [ebp+WndClass.hIcon], eax .text:00401235 call ds:LoadCursorA .text:0040123B push esi ; int .text:0040123C mov [ebp+WndClass.hCursor], eax .text:0040123F call ds:GetStockObject .text:00401245 mov [ebp+WndClass.hbrBackground], eax .text:00401248 lea eax, [ebp+var_C] .text:0040124B mov [ebp+WndClass.lpszMenuName], eax ; lpszMenuName = var_C; .text:0040124E lea eax, [ebp+WndClass] .text:00401251 mov edi, offset aPediy_com_0 ; "pediy.com" .text:00401256 push eax ; lpWndClass .text:00401257 mov [ebp+WndClass.lpszClassName], edi .text:0040125A call ds:RegisterClassA .text:00401260 test ax, ax .text:00401263 jnz short loc_401269 .text:00401265 xor eax, eax 。。。
菜单资源可以采用数字来标识,也可以采用字符串标识。如果在 VC 中添加菜单,默认为以数字标识。如果要以数字标识菜单,第一个想法是需要 hack 上面的代码。
但上面的代码实际上不需要做任何改动,因为它给了我们一个强烈暗示,上面的汇编代码翻译到 C 语言如下:
Code 2.2 将 WinMain 从汇编代码翻译到 C++ 的代码(得到 Menu Name):
int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { char var_C[] = "pediy.com"; // ---- 重要暗示!!!---- MSG msg; WNDCLASSA wndCls; //保存到全局变量 hInst = hInstance; wndCls.style = CS_HREDRAW | CS_VREDRAW; wndCls.lpfnWndProc = WndProc; wndCls.cbClsExtra = 0; wndCls.cbWndExtra = 0; wndCls.hInstance = hInst; wndCls.hIcon = LoadIconA(NULL, IDI_APPLICATION); wndCls.hCursor = LoadCursorA(NULL, IDC_ARROW); wndCls.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH); wndCls.lpszMenuName = var_C; // ---- 重要暗示!!!---- wndCls.lpszClassName = "pediy.com"; if (!RegisterClassA(&wndCls)) return FALSE; HWND hWnd = CreateWindowExA( 0, // EXStyle "pediy.com", // wndClass WS_BORDER | WS_DLGFRAME | WS_SYSMENU | WS_THICKFRAME | WS_GROUP | WS_TABSTOP,
//style CW_USEDEFAULT, // X CW_USEDEFAULT, // Y CW_USEDEFAULT, // nWidth CW_USEDEFAULT, // nHeight NULL, // hWndParent NULL, // hMenu hInst, // hInstance 0); // lParam ShowWindow(hWnd, nCmdShow); UpdateWindow(hWnd); while(GetMessageA(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return (int)msg.wParam; }
就是窗口类的菜单是由 var_C 指定的,var_C 是栈上的临时变量,内容被加载为”pediy.com“。即菜单的字符串标识是 ”pediy.com“。所以任务就简单了,在样本程序中,把菜单的 ID 改为字符串”pediy.com“,然后把编译好的样本程序的 .rsrc 追加到 PE 文件中,菜单就加好了!
补充说明:资源 ID 以字符串标识时,是不论大小写,且字符串的大写形式,以 Unicode 编码存储于 .rsrc 段中的。例如本题目,菜单的 ID 在 .rsrc 中被存储为 "PEDIY.COM"。
有关资源表的结构的更多信息,请参考我的博客文章(这里不做更多说明):《读取PE文件的资源表》。
(2)添加菜单处理函数(子类化窗口):
菜单加好以后,现在点击菜单还没有任何反应。接下来为菜单添加命令处理函数,因此观察窗口过程 WndProc 的汇编代码,可以发现:WndProc 没有为 WM_COMMAND 留出任何空隙和空间供我们插入自己的代码,即没有办法 hack 已有代码来完成这个功能。因此只能在 .text 中追加新的代码。
方法是,在 .text 尾部追加一个函数作为新的窗口过程,这个过程和在 MFC 中子类化一个控件的本质相同,也类似于通常所说的 Hook,即挂钩一个新的函数,由新的 Hook 函数添加自己的处理逻辑,然后再把控制权交回到原来的函数。
这里还需要说明另一个问题,题目要求点击菜单时弹出 MessageBox。但是在现有的导入表中可以看到,程序并没有导入 MessageBoxA 这个函数,所以如果直接调用 MessageBoxA,则需要调整导入表。这样相对的比较麻烦。这时候前面我们找到的那个非常有趣的函数(sub_4059C4: ___crtMessageBoxA)就有用了,观察那个函数,其汇编代码如下:
Code 2.3 代码段中的函数: 004059C4: ___crtMessageBoxA 的汇编代码(MessageBoxA 的动态链接版本):
.text:004059C4 sub_4059C4 proc near ; .text:004059C4 arg_0 = dword ptr 8 .text:004059C4 arg_4 = dword ptr 0Ch .text:004059C4 .text:004059C4 push ebx .text:004059C5 xor ebx, ebx .text:004059C7 cmp dword_40AB70, ebx .text:004059CD push esi .text:004059CE push edi .text:004059CF jnz short loc_405A13 .text:004059D1 push offset LibFileName ; "user32.dll" .text:004059D6 call ds:LoadLibraryA .text:004059DC mov edi, eax .text:004059DE cmp edi, ebx .text:004059E0 jz short loc_405A49 .text:004059E2 mov esi, ds:GetProcAddress .text:004059E8 push offset aMessageboxa ; "MessageBoxA" .text:004059ED push edi ; hModule .text:004059EE call esi ; GetProcAddress .text:004059F0 test eax, eax .text:004059F2 mov dword_40AB70, eax .text:004059F7 jz short loc_405A49 .text:004059F9 push offset aGetactivewindo ; "GetActiveWindow" .text:004059FE push edi ; hModule .text:004059FF call esi ; GetProcAddress .text:00405A01 push offset aGetlastactivep ; "GetLastActivePopup" .text:00405A06 push edi ; hModule .text:00405A07 mov dword_40AB74, eax .text:00405A0C call esi ; GetProcAddress .text:00405A0E mov dword_40AB78, eax .text:00405A13 .text:00405A13 loc_405A13: ; CODE XREF: sub_4059C4+Bj .text:00405A13 mov eax, dword_40AB74 .text:00405A18 test eax, eax .text:00405A1A jz short loc_405A32 .text:00405A1C call eax .text:00405A1E mov ebx, eax .text:00405A20 test ebx, ebx .text:00405A22 jz short loc_405A32 .text:00405A24 mov eax, dword_40AB78 .text:00405A29 test eax, eax .text:00405A2B jz short loc_405A32 .text:00405A2D push ebx .text:00405A2E call eax .text:00405A30 mov ebx, eax .text:00405A32 .text:00405A32 loc_405A32: ; CODE XREF: sub_4059C4+56j .text:00405A32 ; sub_4059C4+5Ej ... .text:00405A32 push [esp+0Ch+arg_4] .text:00405A36 push [esp+10h+arg_0] .text:00405A3A push dword ptr [esp+18h] .text:00405A3E push ebx .text:00405A3F call dword_40AB70 .text:00405A45 .text:00405A45 loc_405A45: ; CODE XREF: sub_4059C4+87j .text:00405A45 pop edi .text:00405A46 pop esi .text:00405A47 pop ebx .text:00405A48 retn .text:00405A49 ; .text:00405A49 .text:00405A49 loc_405A49: ; CODE XREF: sub_4059C4+1Cj .text:00405A49 ; sub_4059C4+33j .text:00405A49 xor eax, eax .text:00405A4B jmp short loc_405A45 .text:00405A4B sub_4059C4 endp
这个函数内容非常简单,内容注释就不写了,总之,这个函数的功能是动态获取 MessageBoxA 的地址并调用。原型相当于:
int ___crtMessageBoxA(const char* pText, const char* pTitle, UINT nType);
由于函数没有复原 ESP,所以是默认的 C 调用约定。这个函数和 MessageBoxA 的区别是:
(a)调用约定不同,MessageBoxA 为 __stdcall 。
(b)只比 MessageBoxA 少了第一个参数: HWND hWnd。该函数在内部获取了一个 HWND 作为 Owner 窗口弹出 MessageBox。
因此,不需要调整导入表,只需要在新的窗口过程中去调用这个函数即可完成弹出 MessageBox 的功能。
同时可以看到,MessageBox 的文本内容,在 .rdata 中并没有可供使用的现成字符串,所以需要插入常量字符串,只需要在 .rdata 的尾部插入即可,通过以下函数即可完成(注意插入新的常量字符串后,需要相应的调整 IMAGE_SECTION_HEADER.VirtualSize,以容纳新的字符串内容):
Code 2.4 向 .rdata 段尾部插入常量字符串的 C++ 代码(作为 ___crtMessageBoxA 的参数):
//在PE文件中插入常量字符串 void InsertString(LPCTSTR pFileName, int InsertPos, const char *pStr) { int BytesToWrite = strlen(pStr) + 1; FILE *fp = NULL; _tfopen_s(&fp, pFileName, _T("r+b")); fseek(fp, InsertPos, SEEK_SET); fwrite(pStr, 1, BytesToWrite, fp); fclose(fp); }
上面的 InsertString 是为了修改 PE 文件而临时写成,所以比较简单,因此其不够易用,局限性在于,1 需要手工调整 section header; 2 需要手工调整 section header 里的 VirtualSize; 3 只考虑了 ASCII 字符串。因此可以多花一定时间把它写的更加通用一点。参见本文末尾的补充部分。
为了得到新的窗口过程,在样本程序中写出新的窗口过程函数,并以 debug 选项编译(之所以采用 debug,是因为 release 优化幅度过大,其结果不利于我们利用。例如我在 release 下编译出挂钩后的结果,编译结果显示原有的窗口过程的第一个参数 hWnd 被优化掉了,因为它已经不再作为窗口过程使用,而仅仅是被新的窗口过程调用的一个普通函数,所以编译器可以按照自己的喜好对它做任何等效变换!)。
Code 2.5 为了子类化窗口,新窗口过程的 C++ 代码(用于得到其汇编代码):
BOOL ___crtMessageBoxA(const char* szText, const char* szTitle, UINT nType) { HMODULE hModule = LoadLibraryA("user32.dll"); int (__stdcall *pFunc)(HWND, LPCSTR, LPCSTR, UINT uType); pFunc = (int (__stdcall*)(HWND, LPCSTR, LPCSTR,UINT uType))
GetProcAddress(hModule, "MessageBoxA"); pFunc(NULL, szText, szTitle, nType); return TRUE; } LRESULT CALLBACK NewWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { if(message == WM_COMMAND && LOWORD(wParam) == IDM_ABOUT) { ___crtMessageBoxA( "看雪论坛.珠海金山2007逆向分析挑战赛\r\nhttp://www.pediy.com", //text "pediy", //caption MB_ICONINFORMATION); return TRUE; } return WndProc(hWnd, message, wParam, lParam); }
其中上面代码中的 ___crtMessageBoxA 函数只是对实际函数的一个简单模拟,这样产生的窗口过程的代码,只需要计算出一些偏移值即可。接下来反汇编上面的样本代码的 debug 编译结果,把 debug 版本中做简要处理,去掉 debug 版本特有的那些填充 INT3 和 ESP 校验 那些没什么用处的代码,就可以得到需要插入的汇编代码了,通过以下函数,把新的窗口过程代码插入到 PE 文件中(由于段在内存中对齐到 4KB,所以每个段的结尾基本上都有相当大的空间剩余,可以插入一些新的内容),如下所示:
Code 2.6 用于向 .text 尾部插入新的窗口过程的 C++ 代码(用于窗口子类化):
//返回插入的字节数 void InsertNewWndProc(LPCTSTR pFileName, int InsertPos) {
//int __stdcall NewWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam);
//[EBP+ 8]: hWnd //[EBP+0Ch]: nMsg //[EBP+10h]: wParam //[EBP+14h]: lParam
BYTE _code[] = { 0x55, //00: push EBP 0x8B, 0xEC, //01: mov EBP, ESP 0x81, 0xEC, 0x20, 0x00, 0x00, 0x00, //03: sub ESP, 20H 0x53, //09: push EBX 0x56, //0A: push ESI 0x57, //0B: push EDI 0x81, 0x7D, 0x0C, 0x11, 0x01, 0x00, 0x00, //0C: cmp [EBP + nMsg], WM_COMMAND 0x75, 0x2B, //13: jne _CALL_OLD_WNDPROC 0x8B, 0x45, 0x10, //15: mov EAX, [EBP + wParam] 0x25, 0xFF, 0xFF, 0x00, 0x00, //18: and EAX, 0xFFFF 0x0F, 0xB7, 0xC8, //1D: movzx ECX, AX 0x83, 0xF9, 0x68, //20: cmp ECX, 0x68 (IDM_ABOUT = 104) 0x75, 0x1B, //23: jne _CALL_OLD_WNDPROC 0x6A, 0x40, //25: push MB_ICONINFORMATION 0x68, 0x90, 0x7C, 0x40, 0x00, //27: push pTitle (0x00407C90: "pediy") 0x68, 0xA0, 0x7C, 0x40, 0x00, //2C: push pText (0x00407CA0 : "...") 0xE8, 0x00, 0x00, 0x00, 0x00, //31: call ___crtMessageBoxA (rel32,需要调整) 0x83, 0xC4, 0x0C, //36: add ESP, 0Ch 调用方复原esp 0xB8, 0x01, 0x00, 0x00, 0x00, //39: mov EAX, 1 0xEB, 0x15, //3E: jmp _RETURN //_CALL_OLD_WNDPROC: 0x8B, 0x45, 0x14, //40: mov EAX, [EBP + lParam] 0x50, //43: push EAX 0x8B, 0x4D, 0x10, //44: mov ECX, [EBP + wParam] 0x51, //47: push ECX 0x8B, 0x55, 0x0C, //48: mov EDX, [EBP + nMsg] 0x52, //4B: push EDX 0x8B, 0x45, 0x08, //4C: mov EAX, [EBP + hWnd] 0x50, //4F: push EAX 0xE8, 0x00, 0x00, 0x00, 0x00, //50: call oldWndProc (rel32,需要调整) //_RETURN: 0x5F, //55: pop EDI 0x5E, //56: pop ESI 0x5B, //57: pos EBX 0x81, 0xC4, 0x20, 0x00, 0x00, 0x00, //58: add ESP, 20h 0x5D, //5E: pop EBP, 0xC2, 0x10, 0x00 //5F: retn 10h }; union { int offset; UINT dwVal; BYTE bytes[4]; } rel32; //计算 ___crtMessageBoxA 的偏移地址 int nextAddr = InsertPos + 0x36; //注意nextAddr是文件地址,也就是 rva (没有加ImageBase) //0x59C4 是 showMsgBox 函数的 rva rel32.offset = 0x59C4 - nextAddr; _code[0x32] = rel32.bytes[0]; _code[0x33] = rel32.bytes[1]; _code[0x34] = rel32.bytes[2]; _code[0x35] = rel32.bytes[3]; //计算 oldWndProc 的偏移地址 nextAddr = InsertPos + 0x55; //0x12D5 是 WndProc 函数的rva rel32.offset = 0x12D5 - nextAddr; _code[0x51] = rel32.bytes[0]; _code[0x52] = rel32.bytes[1]; _code[0x53] = rel32.bytes[2]; _code[0x54] = rel32.bytes[3]; int BytesToWrite = sizeof(_code); FILE *fp = NULL; _tfopen_s(&fp, pFileName, _T("r+b")); fseek(fp, InsertPos, SEEK_SET); fwrite(_code, 1, BytesToWrite, fp); fclose(fp); }
在上面的代码中,_code 数组的内容是根据 NewWndProc 的 debug 版本的汇编代码的基础上,经过删减得到的,已经增加了注释。在所有相关的调整步骤完成后,可以再次反汇编目标文件,查看新插入的窗口过程是否正常,由于上面对 _code 内容的注释将和反汇编工具中看到的一样,所以这里就不再重复给出在反汇编工具中看到的“新的窗口过程”的代码了。
【注意】:插入新的函数到 .text 尾部后,可能依然需要手工更新 section header 中的 VirtualSize 。
代码中由两处偏移地址需要进行调整,分别是 ___crtMessageBoxA 和 oldWndProc 的偏移地址。showMsgBox 的前两个参数为新插入到 .rdata 尾部的两个常量字符串,其地址(VA)已经直接编入 _code 数组中了。即,通过以下方式完成插入新的窗口过程:
Code 2.7 插入 “常量字符串” 和 “新的窗口过程” 到 PE 文件的执行动作:
//[2] 向修改后的PE文件中插入常量字符串 InsertString(szPath, 0x7C80, "---OurString---"); InsertString(szPath, 0x7C90, "pediy"); InsertString(szPath, 0x7CA0, "看雪论坛.珠海金山2007逆向分析挑战赛\r\nhttp://www.pediy.com"); //[3] 插入新的窗口过程!相当于对其子类化 InsertNewWndProc(szPath, 0x6B80);
先在尾部插入一个没用的但容易识别的分隔字符串(其目的是帮助我们在 16 进制编辑器中快速定位到插入的内容):”---OurString---"。(恰好16Bytes,且 InsertString 函数对插入地址做了 16 Bytes 对齐,因此它在16进制编辑器中将占据一个整行),接下来插入两个常量字符串(作为题目要求弹出的 MessageBox 的标题和文本):
0x7C90: "pediy" // Title of MsgBox; ( 这里采用的是 “文件地址” 或者说 RVA。)
0x7CA0: "看雪论坛..珠海金山2007..." // Text of MsgBox;
注意:插入新的字符串常量后,不要忘记同步调整 .rdata 的 VirtualSize !
本文结尾补充了一个更通用的插入字符串的函数。请参考补充讨论。
新的窗口过程已经被插入到了 PE 文件中。接下来再修改 WinMain 中注册窗口类的代码,把新的窗口过程挂钩上去。窗口类的窗口过程是用 VA 提供的绝对地址,修改起来很简单,不需要计算偏移值,把对应的 VA 修改为我们插入的新的窗口过程的 VA (0x00406B80)即可。
同样的,找到 WinMain 函数中,设置窗口过程的指令:
.text:0040121A mov [ebp+WndClass.lpfnWndProc], offset OldWndProc
指令的机器码:
FA:0000121A: C7 45 B4 XX XX 40 00
来到文件地址 121A h 处,这条指令的后面 4 个字节就是窗口过程的 VA。把它修改为刚刚插入的新的窗口过程的 VA (0x 00406B80) 即可。即把 XX 位置调整为如下,即完成挂钩我们新插入的窗口过程:
FA:0000121A: C7 45 B4 80 6B 40 00
这样题目的三部分要求(文本将后两个要求合并)就全部完成了。修改后的 PE 文件运行效果如下:
【补充】对该条指令 ( .text:0040121A mov [ebp+WndClass.lpfnWndProc], offset OldWndProc ) 的机器码解读:
Prefixes | Opcode | ModR/M | SIB | Displacement | Immediate | ||||||||
Mod | Reg/Opcode | R/M | Scale | Index | Base | ||||||||
B | 11000111 | 01 | 000 | 101 | 10110100 | 略 | |||||||
H | <absent> | C7 | 45 | <absent> | B4 | 80 | 6B | 40 | 00 | ||||
+disp8 | <无意义> | [EBP] | |||||||||||
说 明 | MOV | [EBP] + disp8 | disp8 = -76 | imm32 | |||||||||
[EBP - 4Ch], | 0x00406B80 | ||||||||||||
Dest Operand, | Src Operand | ||||||||||||
r/m32, | imm32 | ||||||||||||
&WndCls = EBP - 0x50; //描述窗口类的数据结构的地址 Offset of WndCls.lpfnWndProc = 4; //结构体成员偏移 因此: EBP - 0x4C => &WndCls + 4 => &WndCls.lpfnWndProc; 翻译到高级语言: WndCls.lpfnWndProc = 0x00406B80; | imm32 立即数: 窗口过程的入口地址; VA (已包含 ImageBase); | ||||||||||||
对此 Opcode (C7)的特定说明(属于比较晦涩繁琐的细节,可忽略本单元格内容): Move imm32 to r/m32 (或 Move imm16 to r/m16). 寻址: Operand1 (destination operand): ModRM: r/m (w); Operand2 (source operand): imm8/16/32/64; |
在参考资料(5)中,C7 操作码的说明是“C7 /0”; 这里 “/0” 表示 ModR/M 字节仅仅使用 r/m (寄存机或主存)操作数。
ModR/M 字节的各个字段含义解释如下:
a). r/m = 101 (二进制), 表示 CH / BP / EBP / MM5 / XMM5 寄存器。
b). Mod = 01 (二进制),表示由 r/m 字段寻址的寄存器 + disp8 。也就是 ModR/M 字节后面将出现一个字节的 Displacement, 作为对此寄存器值的偏移量。(此字节被有符号扩展到寄存器数据尺寸后,作为对寄存器的值的修正。因此,这里 disp8 = B4h = -4C h;
c). Reg/Opcode = 000 (二进制),或者指定一个寄存器号,或者作为操作码的扩展信息,具体用途由主操作码指定。在该指令中此字段没有实际意义。在 OpCode = 7C 时,看起来我们只需要关心 R/M 的值(选择下表所在的某一行),在行内横向移动时改变的是 Reg/Opcode 字段的值,看起来似乎是无关紧要的。但实际证明,CPU 要求这个字节只能取第一列的值(也就是该字段必须为 0 )。下表为来自参考资料(5)(Intel 文档)中的 ModR/M 字节寻址表。在本指令(Opcode = C7)
中,ModR/M 只能在第一列(图中红色方框内的数据,即寻址寄存器为 AL/AX/EAX/MM0/XMM0 )中取值,如果在其他列取值将会引发运行时异常(参见如下实验)。
我做了一个实验,当改变 ModR/M 字节的值(另其在行内横向移动到第二列),例如将 0x0040121A 处的指令改为 C7 4D B4 XX XX 40 00 时,在 IDA 中可以正常解析出和修改前一样的指令, 但是运行时会提示异常,用 VS2005 调试,显示其反汇编代码,也会出现指令解释错误,如下图所示:
可以看到在 VS 反汇编器中 0040121A 处指令(原指令为 7 Bytes)无法识别,和后面三个字节(.text:00401221 mov [ebp+WndClass.cbClsExtra], esi)混淆在一起,无法正确识别原有指令(上图中红色方框中的部分),直到 00401224 处,才恢复成正常解释。
SIB 字节:
主要由 base + index 和 scale + index 寻址模式需要使用。scale 字段指定缩放因子,index 字段指定索引寄存器号。base 字段指定作为基址的寄存器号。
【一些有趣的补充】
(1)可以发现一个有趣的现象,在 EXE 类型的 Windows 程序中,传递给 WinMain 的第一个参数 hInstance 是一个 hardcode 的常数:0x0040 0000。也就是说,由于 EXE 是进程的第一个被加载的 Module,并且 linker 对 EXE 的默认 ImageBase 是 0x0040 0000,所以 EXE 自身的 Module 总是位于进程空间的 0x0040 0000 位置。
(2)在资源表中的字符串是以 Unicode 编码存储的,而导入表中的字符串,是以 ASCII 编码存储的。两者分别采用了两种编码,这意味着程序要读取 PE 文件的这两个表,肯定要做编码转换。为什么会这样的?大概原因可能是:
导入表的字符串都是 DLL 和 函数的名称,很明显它们都可以也应该以 ASCII 编码,也就是说,DLL 和 函数名称一律都是英文的(字母+数字),至今我没有听说过有谁用自己国家民族的特殊语言字符来为 DLL 和函数命名,所以导入表中的字符串都是 ASCII 编码,这对于存储和网络传输来说比较经济(我们知道,Windows 系统从 NT 开始内部已经统一采用 Unicode 字符串,在这种环境下,采用 Unicode 编码的程序比采用多字节编码的程序的运行效率更高,关于这一点 Matt Pietrek 在他的专栏曾经写过文章比较这两种编码之间的性能差异,所以在现在所处的时代应该优先采用 Unicode 编码,尽管 ASCII 编码的 C-Style / STL 字符串更为人们熟悉和惯用,但早就是时候改变习惯了)。
而资源就不一样了,资源可以由字符串来标识,完全可以用个性化的语言文字来定义,比如说用户把菜单名字取名为“我的上下文菜单”这样的名称,是完全可能也被允许的,所以资源表中的字符串一律采用 Unicode 编码。
(3)由于我的笔记本安装的是 Win7 / 64-bit 版本操作系统,所以在 IDA 中调试时居然是 64 位模式,有一些不适应。
【下载链接】本题目的附件,和文本中提到的代码的下载链接:
http://files.cnblogs.com/hoodlum1980/pediy02_Answer.zip
【参考资料】
[1]. hoodlum1980 (myself),读取文件的导入表,http://www.cnblogs.com/hoodlum1980/archive/2010/09/08/1821778.html。
[2]. hoodlum1980 (myself),读取文件的资源表,http://www.cnblogs.com/hoodlum1980/archive/2010/09/10/1822906.html。
[3]. hoodlum1980 (myself),[VC6] 图像文件格式数据查看器,http://www.cnblogs.com/hoodlum1980/archive/2010/09/05/1818308.html。
[4]. Billy Belceb,《病毒编写教程---Win32篇》,“PE文件头”章节,翻译:onlyu。
来自:看雪论坛精华6 \ 病毒木马技术 \ 病毒编写 \ Billy Belceb 病毒教程Win32篇。
[5]. Intel® 64 and IA-32 Architectures Software Developer’s Manual,Volume 2 (2A, 2B & 2C): "Instruction Set Reference, A-Z",
--> CHAPTER 2. INSTRUCTION FORMAT
\ 2.1 INSTRUCTION FORMAT FOR PROTECTED MODE, REAL-ADDRESS MODE, AND VIRTUAL-8086 MODE
\ 2.1.3 ModR/M and SIB Bytes;
--> CHAPTER 3. INSTRUCTION SET REFERENCE, A-L \ MOV-Move;
--> APPENDIX B. INSTRUCTION FORMATS AND ENCODINGS;
【本文维护历史】:
[1]. 重新制作本文中的插图:图 1 和图 2,使其更加美观,内容更加准确。2014-6。
[2]. 修订对机器码解读表格中的部分说明。2014-6-27。
另:本文中的插图(图1,图2),采用 Office 2007 - Excel 制作基础资料,在 Photoshop CS 中进一步加工得到。
【补充讨论】
讨论 1. 一个更通用一点的向 PE 文件插入常量字符串的函数。
文中使用的向 PE 插入字符串的函数过于简单,其目前主要局限在于:
(1)需要给出插入位置的文件地址。(人工计算得出)
(2)需要调整插入字符串后,受影响的 section header 中的 VirualSize 字段的值。
(3)仅仅考虑了 ASCII 字符串。
因此,我完全可以把这个函数做的更加简单易用一些,但依然建立在以下假设条件下:
(1)文件具有一个只读的 section; 且该 section 尾部有足够的空间容纳要插入的字符串。
增强易用性的函数的优点是,仅仅需要给出待修改的 PE 文件的路径,要插入的字符串,要写入的字节数就可以了,文件同时向调用方返回以下信息:只读 section 的名称,该字符串的文件地址,相对地址(RVA,不含 ImageBase)。
函数代码如下(目前并没有设置 ErrorMsg 的值,所以在目前版本中该参数目前仅占位):
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.gif)
//.text 的 section.Characters #define INCLUDE_TEXT (IMAGE_SCN_MEM_READ \ | IMAGE_SCN_CNT_CODE \ | IMAGE_SCN_MEM_EXECUTE) #define EXCLUDE_TEXT (IMAGE_SCN_MEM_WRITE | IMAGE_SCN_MEM_DISCARDABLE) //.rdata 的 section.Characters; #define INCLUDE_RDATA IMAGE_SCN_MEM_READ #define EXCLUDE_RDATA (IMAGE_SCN_MEM_EXECUTE \ | IMAGE_SCN_MEM_WRITE \ | IMAGE_SCN_MEM_DISCARDABLE \ | IMAGE_SCN_CNT_CODE) BOOL InsertStringEx(LPCTSTR pFileName, //[in]要修改的 PE 文件路径 LPVOID pStr, //[in]要插入的字符串 int nBytesToWrite, //[in]要写入的字节数(包括 null terminator) DWORD dwInclude, //[in]节属性中应该包含的属性 DWORD dwExclude, //[in]节属性中不应该包含的属性 LPTSTR pSectionName, //[out] 输出插入到了哪个section中, 要求至少为 9 chars LPDWORD pRVA, //[out]返回插入后字符串的RVA LPDWORD pFA, //[out] 返回插入的文件地址 LPTSTR pErrorMsg, //[out] 错误信息 UINT nBufSize); //更加智能的插入常量字符串,自动调整 SectionHeader.VirtualSize //假设 .rdata 段尾部具有足够的空间 BOOL InsertStringEx(LPCTSTR pFileName, //[in]要修改的PE文件路径 LPVOID pStr, //[in]要插入的字符串 int nBytesToWrite, //[in]要写入的字节数(包括 null terminator) DWORD dwInclude, //[in]节属性中应该包含的属性 DWORD dwExclude, //[in]节属性中不应该包含的属性 LPTSTR pSectionName, //[out] 输出插入到了哪个section中, 要求至少为 9 chars LPDWORD pRVA, //[out]返回插入后字符串的RVA LPDWORD pFA, //[out] 返回插入的文件地址 LPTSTR pErrorMsg, //[out] 错误信息 UINT nBufSize) { IMAGE_DOS_HEADER DosHdr; IMAGE_NT_HEADERS NtHdrs; PIMAGE_SECTION_HEADER pSectionHdrs = NULL; BOOL bRet = FALSE; int InsertPos; //需要计算 FILE *fp = NULL; errno_t nErr = _tfopen_s(&fp, pFileName, _T("r+b")); if(nErr != 0 || fp == NULL) goto _CLEANUP; fread(&DosHdr, 1, sizeof(IMAGE_DOS_HEADER), fp); fseek(fp, DosHdr.e_lfanew, SEEK_SET); fread(&NtHdrs, 1, sizeof(IMAGE_NT_HEADERS), fp); pSectionHdrs = (PIMAGE_SECTION_HEADER)malloc( sizeof(IMAGE_SECTION_HEADER) * NtHdrs.FileHeader.NumberOfSections); if(pSectionHdrs == NULL) goto _CLEANUP; fread(pSectionHdrs, sizeof(IMAGE_SECTION_HEADER), NtHdrs.FileHeader.NumberOfSections, fp); //找到只读的section int i, iSection = -1; DWORD dwChar; //section 属性 for(i = 0; i < NtHdrs.FileHeader.NumberOfSections; i++) { dwChar = pSectionHdrs[i].Characteristics; if((dwChar & dwInclude) == dwInclude && (dwChar & dwExclude) == 0) { iSection = i; break; } } //没找到符合要求的section? if(iSection < 0) goto _CLEANUP; //计算section的插入地址 PIMAGE_SECTION_HEADER p1 = pSectionHdrs + iSection; if(pSectionName != NULL) { for(i = 0; i < 8; i++) pSectionName[i] = p1->Name[i]; pSectionName[i] = 0; } //计算当前的下一个section的地址 DWORD nNextAddr0 = GetAligned(p1->PointerToRawData + p1->Misc.VirtualSize, NtHdrs.OptionalHeader.SectionAlignment); //把它对齐到 16 bytes InsertPos = p1->PointerToRawData + p1->Misc.VirtualSize; InsertPos = GetAligned(InsertPos, 0x10); //判断是否有足够插入空间 DWORD nNewSectionSize = InsertPos + nBytesToWrite - p1->PointerToRawData; DWORD nNextAddr1 = GetAligned(p1->PointerToRawData + nNewSectionSize, NtHdrs.OptionalHeader.SectionAlignment); if(nNextAddr1 > nNextAddr0) goto _CLEANUP; //设置两种地址 if(pFA != NULL) *pFA = InsertPos; if(pRVA != NULL) *pRVA = p1->VirtualAddress + (InsertPos - p1->PointerToRawData); //修改section hdr里的值 fseek(fp, DosHdr.e_lfanew + sizeof(IMAGE_NT_HEADERS) + sizeof(IMAGE_SECTION_HEADER) * iSection + 8, //sizeof(IMAGE_SECTION_HEADER.Name) SEEK_SET); fwrite(&nNewSectionSize, sizeof(DWORD), 1, fp); //插入字符串 fseek(fp, InsertPos, SEEK_SET); fwrite(pStr, 1, nBytesToWrite, fp); bRet = TRUE; _CLEANUP: if(fp != NULL) fclose(fp); if(pSectionHdrs != NULL) free(pSectionHdrs); return bRet; }
其中,代码中忘了附上 GetAligned 函数,其函数内容可能是:
UINT GetAligned(UINT nVal, UINT nAlignUnit)
{
return (nVal + nAlignUnit - 1) / nAlignUnit * nAlignUnit;
}
可以看到,增强版本函数去除了之前的三个局限。使用起来更加方便(只需要提供 PE 的路径和要插入的字符串内容就可以了),完全不再需要关心那些琐碎细节。例如:
//要追加字符串的 PE 文件路径 TCHAR szExePath[MAX_PATH]; _tcscpy_s(szExePath, MAX_PATH, _T("E:\\pediy02_Test.exe")); DWORD dwRVA, dwFA; TCHAR szSectionName[16]; char ascii_str[256]; strcpy_s(ascii_str, _ARRAYSIZE(ascii_str), "this is a MultiByte ascii string."); InsertStringEx(szExePath, ascii_str, (strlen(ascii_str) + 1) * sizeof(char),
INCLUDE_RDATA, EXCLUDE_RDATA, szSectionName, &dwRVA, &dwFA, NULL, 0); wchar_t unicode_str[256]; wcscpy_s(unicode_str, _ARRAYSIZE(unicode_str), L"that is a WideChar unicode string."); InsertStringEx(szExePath, unicode_str, (wcslen(unicode_str) + 1) * sizeof(wchar_t),
INCLUDE_RDATA, EXCLUDE_RDATA, szSectionName, &dwRVA, &dwFA, NULL, 0);
调用了该函数成功后,PE文件就已经就绪了,不再需要做其他调整。只需要手工记录下来函数返回的 RVA 地址即可,它可以用于替换掉 .code 中的常量字符串的地址,例如替换 MessageBox 的参数,就可以使得弹出的消息框显示新的内容/标题。FA (文件地址)仅仅用于确定在 16 进制编辑器中观察插入的字符串是否正常和正确。
讨论2. 导入表和 IAT 在内存中的布局。
在本文的图 1 给出了导入表的指针结构,但我希望对这些元素在内存空间(文件)中的布局和位置有一个更直观的认识,因此我写了下面这个程序,来输出位于 .rdata section 起始位置的导入表的所有元素。程序读取所有的 Import Table Descriptors, Thunks, Ascii Strings, 根据这些元素的地址进行排序,以此复现他们在内存空间中的位置/出现次序。采用的 PE 文件即为我给出的题目答案为样例。完整的程序代码如下:
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.gif)
// ImportTable.cpp // 打印出一个 PE 文件的导入表的布局分布图(在 .rdata 的头部的位置) // #include "stdafx.h" #include <stdlib.h> #include <windows.h> #include <vector> #include <algorithm> #include <functional> //#include <stdarg.h> using namespace std; enum TypesDef { T_Descriptor = 0, //descriptor; T_Thunk = 1, //trunk T_String = 2, //常量字符串 }; typedef struct tagNODE { int RVA; //RVA int RVA_End; //在自己身后的RVA(不包含在本元素中) int FA; //文件地址 int type; char name[256]; } NODE, *LPNODE; int MyComparer(const void *pA, const void *pB); bool IsSuccessive(NODE a, NODE b); DWORD RVAToFA(DWORD rva, PIMAGE_SECTION_HEADER pSectionHdrs, int NumberOfSections); int ReadAsciiString(FILE* fp, char *pBuf); int ReadInt32(FILE* fp); int ReadInt16(FILE* fp); int _tmain(int argc, _TCHAR* argv[]) { //先遍历PE文件,找出需要多少个NODE节点 BOOL bPrintGap = TRUE; vector<NODE> nodes; vector<NODE>::const_iterator pos; NODE node; TCHAR szPath[MAX_PATH]; _tcscpy_s(szPath, MAX_PATH, _T("E:\\pediy02_new.exe")); IMAGE_DOS_HEADER DosHdr; IMAGE_NT_HEADERS NtHdrs; PIMAGE_SECTION_HEADER pSectionHdrs = NULL; FILE *fp = NULL; errno_t nErr = _tfopen_s(&fp, szPath, _T("rb")); if(nErr != 0 || fp == NULL) goto _CLEANUP; fread(&DosHdr, 1, sizeof(IMAGE_DOS_HEADER), fp); fseek(fp, DosHdr.e_lfanew, SEEK_SET); fread(&NtHdrs, 1, sizeof(IMAGE_NT_HEADERS), fp); pSectionHdrs = (PIMAGE_SECTION_HEADER)malloc( sizeof(IMAGE_SECTION_HEADER) * NtHdrs.FileHeader.NumberOfSections); if(pSectionHdrs == NULL) goto _CLEANUP; fread(pSectionHdrs, sizeof(IMAGE_SECTION_HEADER), NtHdrs.FileHeader.NumberOfSections, fp); //已经读出文件头: int RVA_import_table, RVA_thunk, RVA_name, RVA_import_by_name; int FA_import_table, FA_thunk, FA_name, FA_import_by_name; int RvaArray[2]; RVA_import_table = NtHdrs.OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress; FA_import_table = RVAToFA(RVA_import_table, pSectionHdrs, NtHdrs.FileHeader.NumberOfSections); char buf[256]; int nDescriptorCount = 0; //非空元素数量 int nThunkCount = 0; //非空元素数量 int i; int Hint, BytesRead; IMAGE_IMPORT_DESCRIPTOR import_descriptor, null_descriptor; IMAGE_THUNK_DATA32 thunk_data; //IMAGE_IMPORT_BY_NAME import_by_name; memset(&null_descriptor, 0, sizeof(IMAGE_IMPORT_DESCRIPTOR)); while(TRUE) { fseek(fp, FA_import_table + sizeof(IMAGE_IMPORT_DESCRIPTOR) * nDescriptorCount, SEEK_SET); fread(&import_descriptor, sizeof(IMAGE_IMPORT_DESCRIPTOR), 1, fp); if(memcmp(&import_descriptor, &null_descriptor, sizeof(IMAGE_IMPORT_DESCRIPTOR)) == 0) { node.RVA = RVA_import_table + sizeof(IMAGE_IMPORT_DESCRIPTOR) * nDescriptorCount; node.RVA_End = node.RVA + sizeof(IMAGE_IMPORT_DESCRIPTOR); node.FA = FA_import_table + sizeof(IMAGE_IMPORT_DESCRIPTOR) * nDescriptorCount; node.type = T_Descriptor; _tcscpy_s(node.name, _ARRAYSIZE(node.name), _T(" 00000000 <null>\n") _T(" FirstTrunk: 00000000 <null>\n") _T(" OriginalFirstTrunk: 00000000 <null>\n") _T(" Name: 00000000 <null>") ); nodes.push_back(node); break; } RVA_name = import_descriptor.Name; FA_name = RVAToFA(RVA_name, pSectionHdrs, NtHdrs.FileHeader.NumberOfSections); //DLL Name 字符串节点 (没有Hint,所以Hint用 “----” 表示) fseek(fp, FA_name, SEEK_SET); BytesRead = ReadAsciiString(fp, buf); node.RVA = RVA_name; node.RVA_End = node.RVA + BytesRead; node.FA = FA_name; node.type = T_String; _stprintf_s(node.name, _ARRAYSIZE(node.name), _T("---- \"%s\""), buf); nodes.push_back(node); //descriptor节点 node.RVA = RVA_import_table + sizeof(IMAGE_IMPORT_DESCRIPTOR) * nDescriptorCount; node.RVA_End = node.RVA + sizeof(IMAGE_IMPORT_DESCRIPTOR); node.FA = FA_import_table + sizeof(IMAGE_IMPORT_DESCRIPTOR) * nDescriptorCount; node.type = T_Descriptor; _stprintf_s(node.name, _ARRAYSIZE(node.name), _T("%s\n") _T(" FirstTrunk: %08X\n") _T(" OriginalFirstTrunk: %08X\n") _T(" Name: %08X"), buf, import_descriptor.FirstThunk, import_descriptor.OriginalFirstThunk, import_descriptor.Name); nodes.push_back(node); //读取FirstTrunk & OriginaTrunk; RvaArray[0] = import_descriptor.FirstThunk; RvaArray[1] = import_descriptor.OriginalFirstThunk; for(i = 0; i < 2; i++) { RVA_thunk = RvaArray[i]; FA_thunk = RVAToFA(RVA_thunk, pSectionHdrs, NtHdrs.FileHeader.NumberOfSections); nThunkCount = 0; while(TRUE) { fseek(fp, FA_thunk + sizeof(IMAGE_THUNK_DATA32) * nThunkCount, SEEK_SET); fread(&thunk_data, sizeof(IMAGE_THUNK_DATA32), 1, fp); if(thunk_data.u1.AddressOfData == 0) { node.type = T_Thunk; node.RVA = RVA_thunk + sizeof(IMAGE_THUNK_DATA32) * nThunkCount; node.RVA_End = node.RVA + sizeof(IMAGE_THUNK_DATA32); node.FA = FA_thunk + sizeof(IMAGE_THUNK_DATA32) * nThunkCount; _tcscpy_s(node.name, _ARRAYSIZE(node.name), _T("00000000 ========[null]========")); nodes.push_back(node); break; } //按照什么方式导入? if(thunk_data.u1.AddressOfData & IMAGE_ORDINAL_FLAG32) { node.RVA = RVA_thunk + sizeof(IMAGE_THUNK_DATA32) * nThunkCount; node.FA = FA_thunk + sizeof(IMAGE_THUNK_DATA32) * nThunkCount; node.RVA_End = node.RVA + sizeof(IMAGE_THUNK_DATA32); node.type = T_Thunk; _stprintf_s(node.name, _ARRAYSIZE(node.name), _T("Ordinal: %ld"), (thunk_data.u1.Ordinal & 0x7FFFFFFF)); nodes.push_back(node); } else { RVA_import_by_name = thunk_data.u1.AddressOfData; FA_import_by_name = RVAToFA(RVA_import_by_name, pSectionHdrs, NtHdrs.FileHeader.NumberOfSections); fseek(fp, FA_import_by_name, SEEK_SET); Hint = ReadInt16(fp); BytesRead = ReadAsciiString(fp, buf); //字符串节点 if(i == 1) { //因为两个数组的内容一模一样,所以字符串只加一次就够了 node.RVA = RVA_import_by_name; node.RVA_End = node.RVA + sizeof(WORD) + BytesRead; node.FA = FA_import_by_name; node.type = T_String; _stprintf_s(node.name, _ARRAYSIZE(node.name), _T("%04X \"%s\""), Hint, buf); nodes.push_back(node); } //Trunk节点 node.RVA = RVA_thunk + sizeof(IMAGE_THUNK_DATA32) * nThunkCount; node.RVA_End = node.RVA + sizeof(IMAGE_THUNK_DATA32); node.FA = FA_thunk + sizeof(IMAGE_THUNK_DATA32) * nThunkCount; node.type = T_Thunk; _stprintf_s(node.name, _ARRAYSIZE(node.name), _T("%08X %s"), RVA_import_by_name, buf); nodes.push_back(node); } nThunkCount++; } } nDescriptorCount++; } //打印结果 sort(nodes.begin(), nodes.end(), IsSuccessive); FILE *fpLog = NULL; _tfopen_s(&fpLog, _T("D:\\ImportTable_log.txt"), _T("w")); //fpLog = stdout; int PrevRVA_End = -1; i = 0; for(pos = nodes.begin(); pos != nodes.end(); ++pos) { i++; if((i & 0xFF) == 0) fflush(fpLog); //相邻两个元素之间存在空隙? if(bPrintGap && pos->type != T_String && PrevRVA_End >= 0 && pos->RVA > PrevRVA_End) { fprintf(fpLog, "-------------------------------------\n"); fprintf(fpLog, " GAP: 0x%08X (%ld Bytes)\n", pos->RVA - PrevRVA_End, pos->RVA - PrevRVA_End); fprintf(fpLog, "-------------------------------------\n"); } PrevRVA_End = pos->RVA_End; fprintf(fpLog, "%08X: ", pos->RVA); switch(pos->type) { case T_Descriptor: fprintf(fpLog, "Descriptor: "); break; case T_Thunk: fprintf(fpLog, " Trunk: "); break; case T_String: break; } fprintf(fpLog, "%s\n", pos->name); } fclose(fpLog); _CLEANUP: nodes.clear(); if(fp == NULL) printf("Canot open PE file.\n"); else fclose(fp); if(pSectionHdrs != NULL) free(pSectionHdrs); //printf("press any key to continue...\n"); //getchar(); return 0; } // qsort 用到的比较函数,本例中没有用到 int MyComparer(const void *pA, const void *pB) { LPNODE pNode1 = (LPNODE)pA; LPNODE pNode2 = (LPNODE)pB; return (pNode1->RVA - pNode2->RVA); } //sort 用到的函数,两个元素是已经排好序的吗? bool IsSuccessive(NODE a, NODE b) { return (a.RVA < b.RVA); } DWORD RVAToFA(DWORD rva, PIMAGE_SECTION_HEADER pSectionHdrs, int NumberOfSections) { int i, iSection = -1; //查找该Rva位于那个段中 for(i = 0; i < NumberOfSections; i++) { if(rva >= pSectionHdrs[i].VirtualAddress && (rva <= pSectionHdrs[i].VirtualAddress + pSectionHdrs[i].Misc.VirtualSize)) { //该rva位于该段 iSection = i; break; } } //未找到? if(iSection < 0) return 0; //换算 return pSectionHdrs[iSection].PointerToRawData + (rva - pSectionHdrs[iSection].VirtualAddress); } //从 PE 文件中读取一个长度不固定的 Ascii 字符串到缓冲区 //返回读取的字节数(包括了 null_terminator, 即 retval = strlen(buf) + 1;) int ReadAsciiString(FILE* fp, char *pBuf) { int i = 0; while(TRUE) { fread(pBuf + i, 1, 1, fp); if(pBuf[i] == 0) break; ++i; } return i + 1; } int ReadInt32(FILE* fp) { int val; fread(&val, sizeof(DWORD), 1, fp); return val; } int ReadInt16(FILE* fp) { WORD val; fread(&val, sizeof(WORD), 1, fp); return val; }
程序产生的输出如下(其中,地址均为 RVA,所有被 Thunk 引用的字符串前面有两个字节表示的 Hint。同时,程序中给出了相邻元素之间的空隙字节数):
//FirstThunk 即为 IAT 地址,也是 .rdata 的起始地址 7000: Trunk:78A2 DeleteObject //GDI32.dll 的 FirstThunk 7004: Trunk:79A0 GetTextExtentPoint32A 7008: Trunk:7994 BeginPath ...(此处省略若干函数) 7044: Trunk:7896 RestoreDC 7048: Trunk:0000 ========[null]======== 704C: Trunk:7BA0 RtlUnwind //KERNEL32.dll 的 FirstThunk 7050: Trunk:7BAC WriteFile 7054: Trunk:7BB8 GetCPInfo ...(此处省略若干函数) 70EC: Trunk:7C5E LCMapStringW 70F0: Trunk:0000 ========[null]======== 70F4: Trunk:7878 DefWindowProcA //USER32.dll 的 FirstThunk 70F8: Trunk:786A BeginPaint 70FC: Trunk:785E EndPaint ...(此处省略若干函数) 7124: Trunk:77BA DispatchMessageA 7128: Trunk:0000 ========[null]======== -------------------------------------
GAP: 0x04EC (1260 bytes) ------------------------------------- 7618: Descriptor: KERNEL32.dll FirstTrunk: 704C OriginalFirstTrunk: 76B4 Name: 77AC 762C: Descriptor: USER32.dll FirstTrunk: 70F4 OriginalFirstTrunk: 775C Name: 788A 7640: Descriptor: GDI32.dll FirstTrunk: 7000 OriginalFirstTrunk: 7668 Name: 79B8 7654: Descriptor: <null> FirstTrunk: <null> OriginalFirstTrunk: <null> Name: <null> 7668: Trunk:78A2 DeleteObject //GDI32.dll 的 OriginalFirstThunk 766C: Trunk:79A0 GetTextExtentPoint32A 7670: Trunk:7994 BeginPath ...(此处省略若干函数) 76AC: Trunk:7896 RestoreDC 76B0: Trunk:0000 ========[null]======== 76B4: Trunk:7BA0 RtlUnwind //KERNEL32.dll 的 OriginalFirstThunk 76B8: Trunk:7BAC WriteFile 76BC: Trunk:7BB8 GetCPInfo ...(此处省略若干函数) 7754: Trunk:7C5E LCMapStringW 7758: Trunk:0000 ========[null]======== 775C: Trunk:7878 DefWindowProcA //USER32.dll 的 OriginalFirstThunk 7760: Trunk:786A BeginPaint 7764: Trunk:785E EndPaint ...(此处省略若干函数) 778C: Trunk:77BA DispatchMessageA 7790: Trunk:0000 ========[null]======== 7794: 0302 "lstrcpyA" //以下是 ascii 字符串 77A0: 0308 "lstrlenA"
77AC: ---- "KERNEL32.dll"
77BA: 0095 "DispatchMessageA"
77CE: 0282 "TranslateMessage"
77E2: 012A "GetMessageA"
77F0: 0291 "UpdateWindow"
7800: 026A "ShowWindow"
780E: 0059 "CreateWindowExA"
7820: 01F2 "RegisterClassA"
7832: 019A "LoadCursorA"
7840: 019E "LoadIconA"
784C: 01E0 "PostQuitMessage"
785E: 00BB "EndPaint"
786A: 000C "BeginPaint"
7878: 0084 "DefWindowProcA"
788A: ---- "USER32.dll"
7896: 01B9 "RestoreDC"
78A2: 0053 "DeleteObject"
... (此处省略略干字符串)
7C5E: 01C0 "LCMapStringW"
根据以上的输出,我可以大概画出导出表在加载后的镜像所在的虚拟空间(文件空间)中的元素大概分布,如下图所示。
【注意】下图对应于 VC 编译的 Release 版本的一种典型结果,如果是 Debug 版本,则元素分布可能和下图不同。
其中,Ascii Strings 部分是长度不固定的字符串,相邻的字符串之间有可能有 1 个字节的空隙(由于这个空隙太小,对于我们能够利用起来的意义不大,所以在图中没有画出字符串之间的空隙)。最主要的空隙位于 FirstThunk 和 Import descriptors 之间,可能有超过 1 KB 的空间看起来是好像空闲的(尚有待验证确认)。每个 Thunk 是 4 Bytes(大多数情况为指向 Ascii 字符串的指针,也可能为函数序号 Ordinal,例如 MFC 类库函数均以 Ordinal 导入,如果经过事先绑定,则 FirstThunk 内容为绑定后的函数地址),由 NULL 元素标识结束。每个 Import descriptor 固定 20 Bytes,由于这个尺寸有点不伦不类,所以在 16 进制编辑器中会显示的很不整齐(每个元素占据一行外加 4 Bytes,在下图中对它们采用了很理想的对齐,在 16 进制编辑器中不存在的这样的视图)。Ascii Strings 为字符串,如果是函数名称,则字符串前面有两个字节的 Hint。
PE 文件头中的 OptionalHeader.DataDirectory[1].Address 指向第一个 Import Descriptor 所在的位置,即 Import Table 的地址,Size 为所有 descriptor 的总大小(包含最后那个 NULL 元素)。DataDirectory[12].Address 指向第一个 FirstThunk 的起始位置,也就是 Import Address Table(IAT),Size 为所有 Thunk 元素的总大小(包括所有的 NULL 元素)。这里也就是系统加载时对所有导入函数的绑定后的实际地址(VA),在代码段中将通过直接跳转或者间接 call 的方式调用导入函数,IAT 元素的地址已经被 hardcode 到代码段中(散乱分布于代码段中),这意味着要增加导入函数,就需要调整代码段中的那些 hardcode 的 IAT 元素的地址,这将是一个稍显麻烦的工作。
在图中可以看到指针对于二进制文件设计的地位和意义,图中,Import Descriptors 数组和 Thunks 数组都是“元素尺寸固定”的“长度可变”数组,由 NULL 元素标识尾部。这些数组,要求元素尺寸固定,这对于规范 loader 的工作非常重要,所以凡是长度不固定的内容,就从元素中提取到后面的离散数据区(长度不固定元素集中存放的地方),在元素中保留为一个大小固定的指针。
此外,从程序的输出结果可以看到,Thunks 数组出现的顺序,和 Import Descriptor 的顺序未必一致。例如,一个 Import Descriptor 在数组中排在后面,它的 Thunks 数组可能排在前面。但 FirstThunk 和 OriginalFirstThunk 指针数组集合(将两者看作多个指针数组组成的集合)中,这些指针数组的排列顺序将是完全一致的。
从导入表元素的布局可以看到,如果通过调整 PE 文件的内容,删除元素可能比较容易,插入函数和新的 DLL 则是一件麻烦事,因为 linker 会把数组紧凑排列,不会留下插入空隙。这也就意味着如果要插入新的元素(例如增加一个已导入 DLL 的某个函数,或者增加一个新的导入 DLL 和若干函数),必然会导致现有的 IAT 发生一定变动。也就是说,比如假设之前已经有个导入函数为 MessageBoxA,该函数实际被映射到进程空间中的 VA 被存储于地址为 0x00407010 的 IAT 元素,当插入新的元素时,这个 IAT 的地址就会发生变动,从而会影响到 .text 代码段中所有对 MessageBoxA 的调用(这些调用相当于 “hardcoding" )。所以插入新的元素意味着:(1)必然需要调整现有的 IAT,并且增加新的函数名称字符串。(2)搜索所有 .text 对受影响的导入函数的调用,并通过适当偏移来修正这些 IAT 元素的地址。
BTW: 特定的,对于本题目,如果要从 User32.dll 导入 MessageBoxA 则相对的简单,可以从其导入表元素空间分布中看出这一点。对本题目,我已经手工完成了修改导入表,使其导入 MessageBoxA 函数,并在代码段中调用它。因为不需要移动现有的 IAT,所以也不需要修正代码段中的导入函数的 VA,相对的还是比较简单的(只是一些插入字符串,移动字符串,扩充 Thunks 数组,修正数组元素的值等操作为主,例如,扩充数组时,会把紧挨在其后的一个或多个 Ascii 字符串挤到 idata 数据段的尾部去,以为新的数组元素提供空间,在这里我就不详细展示这个过程了)。
-- [1]. 2014-06-15 首次补充;
-- [2]. 2014-06-19 增加 ImportTable 元素分布示意图和说明。