PE文件导入表的代码注入

PE文件导入表的代码注入

http://blog.csdn.net/xieqidong/article/details/2391338

试想一下，如果通过修改导入表，能把PE格式文件中的函数入口点，重定向到自己的程序中来，是不是很酷！这样，在自己在程序中，可以过滤掉对某些函数的调用，或者，设置自己的处理程序，Professional Portable Executable (PE) Protector也就是这样做的。另外，某些rootkit也使用了此方法把恶意代码嵌入到正常程序中。在逆向工程的概念里，均称为API重定向技术，让我们一起进入这个神奇的世界吧。

1、导入表简介

PE文件由MS-DOS头、NT头、节头、节映像组成，如图1所示。MS-DOS头在从DOS至现今Windows的所有微软可执行文件中都存在；NT头的概念抽象自Unix系统的可执行与链接文件格式（ELF）。实际上，PE格式可以说是Linux可执行与链接格式（ELF）的兄弟，PE格式头由PE签名、通用对象文件格式（COFF）头、PE最优化头、节头组成。

图1：PE文件格式结构

NT头的定义可在Visual C++的<winnt.h>头文件中找到，也可使用DbgHelp.dll中的ImageNtHeader()函数得到相关信息，另外，还可以使用DOS头来获取NT头，因为DOS头的最后位置e_lfanew，代表了NT头的偏移量。

typedef struct _IMAGE_NT_HEADERS {

DWORD Signature;

IMAGE_FILE_HEADER FileHeader;

IMAGE_OPTIONAL_HEADER OptionalHeader;

} IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS;

在PE最优化头中，有一些数据目录指明了当前进程虚拟内存中，主信息表的相对位置及大小，这些表可保存资源、导入、导出、重定位、调试、线程本地存储及COM运行时的有关信息。没有导入表的PE可执行文件是不可能存在的，这张表包含了DLL名及函数名，这些都是程序通过虚拟地址调用它们时所必不可少的；控制台可执行文件中没有资源表，然而，对图形用户界面的Windows可执行文件来说，资源表却是至关重要的部分；当某个动态链接库导出了它的函数，此时就需要导出表了，在OLE Active-X容器中也同样；而.NET虚拟机缺少了COM+运行时头则不能被执行。PE格式的详细说明见表1：

数据目录

0 Export Table（导出表）

1 Import Table（导入表）

2 Resource Table（资源表）

3 Exception Table（异常表）

4 Certificate File（凭证文件）

5 Relocation Table（重定位表）

6 Debug Data（调试数据）

7 Architecture Data（架构数据）

8 Global Ptr（全局指针）

9 Thread Local Storage Table（线程本地存储表）

10 Load Config Table（加载配置表）

11 Bound Import Table（边界导入表）

12 Import Address Table（导入地址表）

13 Delay Import Descriptor（延误导入描述符）

14 COM+ Runtime Header（COM+运行时头）

15 Reserved（保留）

表1：数据目录

// <winnt.h>

#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16

//可选头格式

typedef struct _IMAGE_OPTIONAL_HEADER {

...

IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];

} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;

//目录项

#define IMAGE_DIRECTORY_ENTRY_EXPORT 0 //导出目录

#define IMAGE_DIRECTORY_ENTRY_IMPORT 1 //导入目录

#define IMAGE_DIRECTORY_ENTRY_RESOURCE 2 //资源目录

#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5 //基重定位表

#define IMAGE_DIRECTORY_ENTRY_DEBUG 6 //调试目录

#define IMAGE_DIRECTORY_ENTRY_TLS 9 //TLS目录

可通过简单的几行代码获得导入表的位置及大小，知道了导入表的位置后，就可知道DLL名及函数名了，这将在后面进行讨论。

PIMAGE_NT_HEADERS pimage_nt_headers = ImageNtHeader(pImageBase);

DWORD it_voffset = pimage_nt_headers->OptionalHeader.

DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress;

PIMAGE_DOS_HEADER pimage_dos_header = PIMAGE_DOS_HEADER(pImageBase);

PIMAGE_NT_HEADERS pimage_nt_headers = (PIMAGE_NT_HEADERS)

(pImageBase + pimage_dos_header->e_lfanew);

DWORD it_voffset = pimage_nt_headers->OptionalHeader.

DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress;

2、导入描述符概览

通过导入表的导入目录项，可获知文件映像内部导入表的位置，且对每个导入的DLL、导入描述符，都有一个相应的容器，其包含了首个thunk（转换程序）地址、原始首个thunk的地址，还有指向DLL名的指针。FirstThunk指向首个thunk的位置，这些thunk在程序运行时，由Windows的PE加载器初始化，如图5所示。OriginalFirstThunk指向这些thunk的第一个存储位置，对每个函数而言，这也是提供Hint（提示）数据地址及函数名数据之处，见图4。在本例中，OriginalFirstThunk不存在，而FirstThunk则指向了提示数据及函数名数据位置之处，见图3。

IMAGE_IMPORT_DESCRIPTOR结构代表了导入描述符，以下是其定义：

typedef struct _IMAGE_IMPORT_DESCRIPTOR {

DWORD OriginalFirstThunk;

DWORD TimeDateStamp;

DWORD ForwarderChain;

DWORD Name;

DWORD FirstThunk;

} IMAGE_IMPORT_DESCRIPTOR, *PIMAGE_IMPORT_DESCRIPTOR;

OriginalFirstThunk指向第一个thunk（IMAGE_THUNK_DATA），thunk中保存了提示数据地址及函数名。

TimeDateStamp包含了绑定的时间日期戳，如果它为0，表示在导入的DLL没有任何绑定。在将来，会设为0xFFFFFFFF以表明有绑定。

ForwarderChain指向API的第一个转发链，设为0xFFFFFFFF表示没有转发。

Name指明了DLL名的相对虚拟地址。

FirstThunk包含了由IMAGE_THUNK_DATA定义的首个thunk数组的虚拟地址，而thunk由加载器用函数虚拟地址初始化。如果OrignalFirstThunk不存在，它指向了第一个thunk、提示（Hint）thunk及函数名。

typedef struct _IMAGE_IMPORT_BY_NAME {

WORD Hint;

BYTE Name[1];

} IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;

typedef struct _IMAGE_THUNK_DATA {

union {

PDWORD Function;

PIMAGE_IMPORT_BY_NAME AddressOfData;

} u1;

} IMAGE_THUNK_DATA, *PIMAGE_THUNK_DATA;

图2：导入表一览

图3：带有Orignal First Thunk的导入表视图

这两张导入表（图2、3）清楚地说明了带有及不带Orignal First Thunk时的区别。

图4：被PE加载器覆写后的导入表

可用Dependency Walker，见图5，来查看导入表的所有信息，另外，还有一个小工具Import Table viewer，见图6，也可用来查看此类信息。

图5：Dependency Walker——Visual Studio自带的工具

图6：Import Table viewer

另外，也可利用下面这段代码，在自己的程序中显示导入DLL及导入函数（只适用于控制台模式的程序）。

PCHAR pThunk;

PCHAR pHintName;

DWORD dwAPIaddress;

PCHAR pDllName;

PCHAR pAPIName;

//----------------------------------------

DWORD dwImportDirectory= RVA2Offset(pImageBase, pimage_nt_headers->

OptionalHeader.

DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);

//----------------------------------------

PIMAGE_IMPORT_DESCRIPTOR pimage_import_descriptor=

(PIMAGE_IMPORT_DESCRIPTOR) (pImageBase+dwImportDirectory);

//----------------------------------------

while(pimage_import_descriptor->Name!=0)

{

pThunk= pImageBase+pimage_import_descriptor->FirstThunk;

pHintName= pImageBase;

if(pimage_import_descriptor->OriginalFirstThunk!=0)

{

pHintName+= RVA2Offset(pImageBase,

pimage_import_descriptor->OriginalFirstThunk);

}

else

{

pHintName+= RVA2Offset(pImageBase, pimage_import_descriptor->FirstThunk);

}

pDllName= pImageBase + RVA2Offset(pImageBase,pimage_import_descriptor->Name);

printf(" DLL Name: %s First Thunk: 0x%x", pDllName,

pimage_import_descriptor->FirstThunk);

PIMAGE_THUNK_DATA pimage_thunk_data= (PIMAGE_THUNK_DATA) pHintName;

while(pimage_thunk_data->u1.AddressOfData!=0)

{

dwAPIaddress= pimage_thunk_data->u1.AddressOfData;

if((dwAPIaddress&0x80000000)==0x80000000)

{

dwAPIaddress&= 0x7FFFFFFF;

printf("Proccess: 0x%x", dwAPIaddress);

}

else

{

pAPIName= pImageBase+RVA2Offset(pImageBase, dwAPIaddress)+2;

printf("Proccess: %s", pAPIName);

}

pThunk+= 4;

pHintName+= 4;

pimage_thunk_data++;

}

pimage_import_descriptor++;

}

3、API重定向技术

在了解了导入表的所有基础知识后，现在就要来看看重定向方法了，其算法非常简单，在当前进程的虚拟内存内部创建一个额外的虚拟空间，并生成相应指令通过JMP重定向到原始函数位置。在这里，可使用绝对跳转或相对跳转，在使用绝对跳转时要非常小心，不能像图7中那么简单地进行，应首先把虚拟地址存到EAX中，接着由JMP EAX跳转。

图7：绝对跳转指令的API重定向

当然了，也可以使用相对跳转，下面的代码就是这样做的，但要清楚，不能对所有DLL模块都进行API重定向，比如，拿“计算器”CALC.EXE来说，MSVCRT.DLL的某些thunk在运行时初始化期间，是从CALC.EXE代码节内部访问的，因此，重定向的话则不能正常工作。

_it_fixup_1:

push ebp

mov ebp,esp

add esp,-14h

push PAGE_READWRITE

push MEM_COMMIT

push 01D000h

push 0

call _jmp_VirtualAlloc

//NewITaddress=VirtualAlloc(NULL, 0x01D000,

// MEM_COMMIT, PAGE_READWRITE);

mov [ebp-04h],eax

mov ebx,[ebp+0ch]

test ebx,ebx

jz _it_fixup_1_end

mov esi,[ebp+08h]

add ebx,esi // dwImageBase + dwImportVirtualAddress

_it_fixup_1_get_lib_address_loop:

mov eax,[ebx+0ch] // image_import_descriptor.Name

test eax,eax

jz _it_fixup_1_end

mov ecx,[ebx+10h] // image_import_descriptor.FirstThunk

add ecx,esi

mov [ebp-08h],ecx // dwThunk

mov ecx,[ebx] // image_import_descriptor.Characteristics

test ecx,ecx

jnz _it_fixup_1_table

mov ecx,[ebx+10h]

_it_fixup_1_table:

add ecx,esi

mov [ebp-0ch],ecx // dwHintName

add eax,esi // image_import_descriptor.Name

// + dwImageBase = ModuleName

push eax // lpLibFileName

mov [ebp-10h],eax

call _jmp_LoadLibrary // LoadLibrary(lpLibFileName);

test eax,eax

jz _it_fixup_1_end

mov edi,eax

_it_fixup_1_get_proc_address_loop:

mov ecx,[ebp-0ch] // dwHintName

mov edx,[ecx] // image_thunk_data.Ordinal

test edx,edx

jz _it_fixup_1_next_module

test edx,080000000h //是否按顺序导入

jz _it_fixup_1_by_name

and edx,07FFFFFFFh //取得顺序

jmp _it_fixup_1_get_addr

_it_fixup_1_by_name:

add edx,esi // image_thunk_data.Ordinal +

// dwImageBase = OrdinalName

inc edx

inc edx // OrdinalName.Name

_it_fixup_1_get_addr:

push edx // lpProcName

push edi // hModule

call _jmp_GetProcAddress // GetProcAddress(hModule,

// lpProcName);

mov [ebp-14h],eax //_p_dwAPIaddress

//=========================================================

// 重定向引擎

push edi

push esi

push ebx

mov ebx,[ebp-10h]

push ebx

call _char_upper

mov esi,[ebp-10h]

mov edi,[ebp+010h]

_it_fixup_1_check_dll_redirected:

push edi

call __strlen

add esp, 4

mov ebx,eax

mov ecx,eax

push edi

push esi

repe cmps

jz _it_fixup_1_do_normal_it_0

pop esi

pop edi

add edi,ebx

cmp byte ptr [edi],0

jnz _it_fixup_1_check_dll_redirected

mov ecx,[ebp-08h]

mov eax,[ebp-014h]

mov [ecx],eax

jmp _it_fixup_1_do_normal_it_1

_it_fixup_1_do_normal_it_0:

pop esi

pop edi

mov edi,[ebp-04h]

mov byte ptr [edi], 0e9h // JMP指令

mov eax,[ebp-14h]

sub eax, edi

sub eax, 05h

mov [edi+1],eax //相对JMP值

mov word ptr [edi+05], 0c08bh

mov ecx,[ebp-08h]

mov [ecx],edi // -> Thunk

add dword ptr [ebp-04h],07h

_it_fixup_1_do_normal_it_1:

pop ebx

pop esi

pop edi

//===================================================

add dword ptr [ebp-08h],004h // dwThunk => next dwThunk

add dword ptr [ebp-0ch],004h // dwHintName =>

// next dwHintName

jmp _it_fixup_1_get_proc_address_loop

_it_fixup_1_next_module:

add ebx,014h // sizeof(IMAGE_IMPORT_DESCRIPTOR)

jmp _it_fixup_1_get_lib_address_loop

_it_fixup_1_end:

mov esp,ebp

pop ebp

ret 0ch

说点题外话，千万不要认为这样就可以绕过Professional EXE Protector了，这个软件中有一套自己的x86指令生成引擎用于创建重定向代码，有时，这个引擎还带有一个扰乱变形引擎，以使它复杂到难以跟踪分析。

在工作原理上，上述代码依照了下列算法：

1、创建一个单独的空间以存储由VirtualAlloc()生成的指令。

2、通过LoadLibrary()和GerProcAddress()找到函数的虚拟地址。

3、检查DLL名是否匹配有效DLL列表。在本例中，识别出KERNEL32.DLL、USER32.DLL、GDI32.DLL、ADVAPI32.DLL、SHELL32.DLL为可重定向的有效DLL名。

4、如果DLL名有效，转到重定向部分；否则，用原始函数虚拟地址初始化thunk。

5、为重定向API，生成JMP（0xE9）指令并计算函数的相对地址以确定相对跳转。

6、把生成的指令存储在单独的空间中，并把thunk引用为这些指令的首地址。

7、对其他函数及DLL重复以上步骤。

如果对CALC.EXE执行了以上步骤，并以OllyDbg进行跟踪，将会看到类似以下的代码：

008E0000 - E9 E6F8177C JMP SHELL32.ShellAboutW

008E0005 8BC0 MOV EAX,EAX

008E0007 - E9 0F764F77 JMP ADVAPI32.RegOpenKeyExA

008E000C 8BC0 MOV EAX,EAX

008E000E - E9 70784F77 JMP ADVAPI32.RegQueryValueExA

008E0013 8BC0 MOV EAX,EAX

008E0015 - E9 D66B4F77 JMP ADVAPI32.RegCloseKey

008E001A 8BC0 MOV EAX,EAX

008E001C - E9 08B5F27B JMP kernel32.GetModuleHandleA

008E0021 8BC0 MOV EAX,EAX

008E0023 - E9 4F1DF27B JMP kernel32.LoadLibraryA

008E0028 8BC0 MOV EAX,EAX

008E002A - E9 F9ABF27B JMP kernel32.GetProcAddress

008E002F 8BC0 MOV EAX,EAX

008E0031 - E9 1AE4F77B JMP kernel32.LocalCompact

008E0036 8BC0 MOV EAX,EAX

008E0038 - E9 F0FEF27B JMP kernel32.GlobalAlloc

008E003D 8BC0 MOV EAX,EAX

008E003F - E9 EBFDF27B JMP kernel32.GlobalFree

008E0044 8BC0 MOV EAX,EAX

008E0046 - E9 7E25F37B JMP kernel32.GlobalReAlloc

008E004B 8BC0 MOV EAX,EAX

008E004D - E9 07A8F27B JMP kernel32.lstrcmpW

008E0052 8BC0 MOV EAX,EAX

而绝对跳转时的代码如下：

008E0000 - B8 EBF8A57C MOV EAX,7CA5F8EBh

//SHELL32.ShellAboutW的地址

008E0005 FFE0 JMP EAX

下面，就要用重定向技术来改变某个API的功能了，在本例中，将把CALC.EXE的ShellAbout()对话框重定向到“Hello World!”消息框，且只需对前述代码作稍许改动：

...

//==============================================================

push edi

push esi

push ebx

mov ebx,[ebp-10h]

push ebx

call _char_upper

mov esi,[ebp-10h]

mov edi,[ebp+010h] // [ebp+_p_szShell32]

_it_fixup_1_check_dll_redirected:

push edi

call __strlen

add esp, 4

mov ebx,eax

mov ecx,eax

push edi

push esi

repe cmps // byte ptr [edi], byte ptr [esi]

jz _it_fixup_1_check_func_name

jmp _it_fixup_1_no_check_func_name

_it_fixup_1_check_func_name:

mov edi,[ebp+014h] // [ebp+_p_szShellAbout]

push edi

call __strlen

add esp, 4

mov ecx,eax

mov esi,[ebp-18h]

mov edi,[ebp+014h] // [ebp+_p_szShellAbout]

repe cmps //byte ptr [edi], byte ptr [esi]

jz _it_fixup_1_do_normal_it_0

_it_fixup_1_no_check_func_name:

pop esi

pop edi

add edi,ebx

cmp byte ptr [edi],0

jnz _it_fixup_1_check_dll_redirected

mov ecx,[ebp-08h]

mov eax,[ebp-014h]

mov [ecx],eax

jmp _it_fixup_1_do_normal_it_1

_it_fixup_1_do_normal_it_0:

pop esi

pop edi

mov ecx,[ebp-08h]

mov edi,[ebp+18h]

mov [ecx],edi //把新函数的地址存到thunk中

_it_fixup_1_do_normal_it_1:

pop ebx

pop esi

pop edi

//==============================================================

...

先检查DLL是否为“Shell32.dll”，再检查函数名是否为“ShellAboutW”，如果这两个条件为true，把ShellAbout()的thunk重定向到新的函数。

新的函数只是一个简单的消息框：

_ShellAbout_NewCode:

_local_0:

pushad //把寄存器上下文保存在堆栈中

call _local_1

_local_1:

pop ebp

sub ebp,offset _local_1 //得到基ebp

push MB_OK | MB_ICONINFORMATION

lea eax,[ebp+_p_szCaption]

push eax

lea eax,[ebp+_p_szText]

push eax

push NULL

call _jmp_MessageBox

// MessageBox(NULL, szText, szCaption, MB_OK | MB_ICONINFORMATION) ;

popad //从堆栈中恢复第一个寄存器上下文

ret 10h

当想要用一个新的函数取代某个API时，应考虑以下两个重点部分：

一是不要因丢失堆栈点而破坏了堆栈内存（Stack memory），因此，最终必需以ADD ESP,xxx或RET xxx恢复原始堆栈点。

二是通过PUSHAD、POPAD，尽量保证除了EAX之外的大多数线程寄存器的安全。

大家可以看到，代码中也使用了PUSHAD及POPAD回收线程寄存器，对本例来说，ShellAbout()有4个DWORD成员，因此当返回时，堆栈点增长了0x10。

重定向ShellAbout()之后，点击计算器（CALC.EXE）“帮助”菜单中的“关于计算器”，就可看到结果了。

图8：“关于计算器”被重定向到一个消息框

4、保护防止逆向工程

要使用复杂的API重定向技术来重新构造一个导入表简直是难上加难，有时，像Import REConstructor这样的工具（图10）在重建导入表时也会被搞糊涂，尤其是当重定向是通过多态代码映像来实现时。在逆向工程界，Import REConstructor是一个非常有名的工具，它会挂起目标进程以捕捉导入表信息。如果是像简单的JMP这样实现的重定向，使用此工具当然可以被重建，不过，如果加密了函数名并在内存中与多态变形代码进行绑定，它就不能得到正确的导入表了。Native Security Engine 6就是这样的一个打包器，它有一个x86代码生成器外加一个扰乱变形引擎，两者都有助于实现一个复杂的重定向结构。

图9：Import REConstructor

图10中列明了导入表保护的主要策略，它们中有些重定向至虚拟的Win32库，例如，分别有Kernel32、User32、AdvApi32的虚拟库，使用自己的库可防止被他人破解或安装自己的虚拟机。

图10：导入表保护

利用此方法，也可切断对外界的访问，如MoleBox就是这样，它过滤了FindFirstFile()及FindNextFile()以把TEXT及JPEG文件合并在压缩文件内部，当程序找到硬盘上的一个文件时，它将会被重定向到内存中。

5、导入表的运行时注入

在这一节，最重要的问题是，怎样注入到运行时进程的导入表中呢，其实可通过重写内存数据及从外部重定向导入表来实现。

（1）、WindowFromPoint()可获取特定点的窗口句柄，GetWindowThreadProcessId()可有助于了解此窗口句柄的进程ID及线程ID。

POINT point;

HWND hWindowUnderTheMouse = WindowFromPoint(point);

DWORD dwProcessId;

DWORD dwThreadId;

dwThreadId=GetWindowThreadProcessId(hSeekedWindow, &dwProcessId);

（2）、进程及线程句柄可由OpenProcess()及OpenThread()获得。

HANDLE hProcess = OpenProcess( PROCESS_ALL_ACCESS, FALSE,

dwProcessId );

HANDLE hThread = OpenThread( THREAD_ALL_ACCESS, FALSE,

dwThreadId);

（3）、要操纵进程内存，先要挂起主线程来冻结进程。

SuspendThread(hThread);

（4）、线程环境块（Thread Environment Block TEB）的位置可由FS:[18]获得，而使用GetThreadContext()与GetThreadSelectorEntry()则可以知道FS段的基址值。

CONTEXT Context;

LDT_ENTRY SelEntry;

Context.ContextFlags = CONTEXT_FULL | CONTEXT_DEBUG_REGISTERS;

GetThreadContext(hThread,&Context);

//计算FS的基址

GetThreadSelectorEntry(hThread, Context.SegFs, &SelEntry);

DWORD dwFSBase = ( SelEntry.HighWord.Bits.BaseHi << 24) |

(SelEntry.HighWord.Bits.BaseMid << 16) |

SelEntry.BaseLow;

（5）、线程环境块可在目标进程虚拟内存内部读取获得，线程与进程环境块的具体形式，请见图11。

PTEB pteb = new TEB;

PPEB ppeb = new PEB;

DWORD dwBytes;

ReadProcessMemory( hProcess, (LPCVOID)dwFSBase, pteb,

sizeof(TEB), &dwBytes);

ReadProcessMemory( hProcess, (LPCVOID)pteb->Peb, ppeb,

sizeof(PEB), &dwBytes);

图11：线程环境块（Thread Environment Block）及进程环境块（Process Environment Block）

（6）、当前进程内存的PE映像的映像基址可由进程环境块中信息获得。

DWORD dwImageBase = (DWORD)ppeb->ImageBaseAddress;

（7）、ReadProcessMemory()可用于读取PE文件的整个映像。

PIMAGE_DOS_HEADER pimage_dos_header = new IMAGE_DOS_HEADER;

PIMAGE_NT_HEADERS pimage_nt_headers = new IMAGE_NT_HEADERS;

ReadProcessMemory( hProcess,

(LPCVOID)dwImageBase,

pimage_dos_header,

sizeof(IMAGE_DOS_HEADER),

&dwBytes);

ReadProcessMemory( hProcess,

(LPCVOID)(dwImageBase+pimage_dos_header->

e_lfanew),

pimage_nt_headers, sizeof(IMAGE_NT_HEADERS),

&dwBytes);

PCHAR pMem = (PCHAR)GlobalAlloc(

GMEM_FIXED | GMEM_ZEROINIT,

pimage_nt_headers->

OptionalHeader.SizeOfImage);

ReadProcessMemory( hProcess,

(LPCVOID)(dwImageBase),

pMem,

pimage_nt_headers->

OptionalHeader.SizeOfImage,

&dwBytes);

（8）、查找DLL名及thunk值确定目标以便对它进行重定向，在本例中，DLL名是Shell32.dll，而thunk是ShellAbout()的虚拟地址。

HMODULE hModule = LoadLibrary("Shell32.dll");

DWORD dwShellAbout= (DWORD)GetProcAddress(hModule, "ShellAboutW");

DWORD dwRedirectMem = (DWORD)VirtualAllocEx(

hProcess,

NULL,

0x01D000,

MEM_COMMIT,

PAGE_EXECUTE_READWRITE);

RedirectAPI(pMem, dwShellAbout, dwRedirectMem);

...

int RedirectAPI(PCHAR pMem, DWORD API_voffset,

DWORD NEW_voffset)

{

PCHAR pThunk;

PCHAR pHintName;

DWORD dwAPIaddress;

PCHAR pDllName;

DWORD dwImportDirectory;

DWORD dwAPI;

PCHAR pImageBase = pMem;

//----------------------------------------

PIMAGE_IMPORT_DESCRIPTOR pimage_import_descriptor;

PIMAGE_THUNK_DATA pimage_thunk_data;

//----------------------------------------

PIMAGE_DOS_HEADER pimage_dos_header;

PIMAGE_NT_HEADERS pimage_nt_headers;

pimage_dos_header = PIMAGE_DOS_HEADER(pImageBase);

pimage_nt_headers = (PIMAGE_NT_HEADERS)

(pImageBase+pimage_dos_header-> e_lfanew);

//----------------------------------------

dwImportDirectory=pimage_nt_headers->OptionalHeader

.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]

.VirtualAddress;

if(dwImportDirectory==0)

{

return -1;

}

//----------------------------------------

pimage_import_descriptor=(PIMAGE_IMPORT_DESCRIPTOR)

(pImageBase+dwImportDirectory);

//----------------------------------------

while(pimage_import_descriptor->Name!=0)

{

pThunk=pImageBase+pimage_import_descriptor->

FirstThunk;

pHintName=pImageBase;

if(pimage_import_descriptor->OriginalFirstThunk!=0)

{

pHintName+=pimage_import_descriptor->

OriginalFirstThunk;

}

else

{

pHintName+=pimage_import_descriptor->FirstThunk;

}

pDllName=pImageBase+pimage_import_descriptor->Name;

StrUpper(pDllName);

if(strcmp(pDllName,"SHELL32.DLL")==0)

{

pimage_thunk_data=PIMAGE_THUNK_DATA(pHintName);

while(pimage_thunk_data->u1.AddressOfData!=0)

{

//----------------------------------------

memcpy(&dwAPI, pThunk, 4);

if(dwAPI==API_voffset)

{

memcpy(pThunk, &NEW_voffset, 4);

return 0;

}

//----------------------------------------

pThunk+=4;

pHintName+=4;

pimage_thunk_data++;

}

pimage_import_descriptor++;

}

//----------------------------------------

return -1;

}

（9）、重定向中的额外内存由VirtualProtectEx()分配，在此只是生成代码，并把它写到新的空间中。

DWORD dwRedirectMem = (DWORD)VirtualAllocEx(

hProcess,

NULL,

0x01D000,

MEM_COMMIT,

PAGE_EXECUTE_READWRITE);

...

PCHAR pLdr;

DWORD Ldr_rsize;

GetLdrCode(pLdr, Ldr_rsize);

WriteProcessMemory( hProcess,

(LPVOID)(dwRedirectMem),

pLdr,

Ldr_rsize,

&dwBytes);

（10）、额外的内存中是加载代码，它显示一个消息框。

void GetLdrCode(PCHAR &pLdr, DWORD &rsize)

{

HMODULE hModule;

DWORD dwMessageBox;

PCHAR ch_temp;

DWORD dwCodeSize;

ch_temp=(PCHAR)DWORD(ReturnToBytePtr(DynLoader,

DYN_LOADER_START_MAGIC))+4;

dwCodeSize=DWORD(ReturnToBytePtr(DynLoader,

DYN_LOADER_END_MAGIC))-DWORD(ch_temp);

rsize= dwCodeSize;

pLdr = (PCHAR)GlobalAlloc(GMEM_FIXED | GMEM_ZEROINIT, dwCodeSize);

memcpy(pLdr, ch_temp, dwCodeSize);

ch_temp=(PCHAR)ReturnToBytePtr(pLdr,

DYN_LOADER_START_DATA1);

hModule = LoadLibrary("User32.dll");

dwMessageBox= (DWORD)GetProcAddress(hModule, "MessageBoxA");

memcpy(ch_temp+4, &dwMessageBox, 4);

}

...

_ShellAbout_NewCode:

_local_0:

pushad //在堆栈中保存寄存器上下文

call _local_1

_local_1:

pop ebp

sub ebp,offset _local_1 //取得ebp基址

push MB_OK | MB_ICONINFORMATION

lea eax,[ebp+_p_szCaption]

push eax

lea eax,[ebp+_p_szText]

push eax

push NULL

mov eax, [ebp+_p_MessageBox]

call eax

// MessageBox(NULL, szText, szCaption,

/ MB_OK | MB_ICONINFORMATION) ;

popad //从堆栈中恢复第一个寄存器上下文

ret 10h

...

（11）、在修改之后，可执行映像就写到内存中了，记得在写之前，不要忘了把内存设为完全访问。

VirtualProtectEx( hProcess,

(LPVOID)(dwImageBase),

pimage_nt_headers->

OptionalHeader.SizeOfImage,

PAGE_EXECUTE_READWRITE,

&OldProtect);

WriteProcessMemory( hProcess,

(LPVOID)(dwImageBase),

pMem,

pimage_nt_headers->

OptionalHeader.SizeOfImage,

&dwBytes);

VirtualProtectEx()设置页访问为PAGE_EXECUTE_READWRITE保护类型，当使用WriteProcessMemory()且可执行页中有PAGE_EXECUTE时，必须有PAGE_READWRITE访问权限。

（12）、现在，可以释放前面挂起的进程了，点击“关于”菜单，将会看到如图12所示的界面。

ResumeThread(hThread);

图12：ShellAbout() thunk的运行时注入

6、对程序的挂钩

利用此方法，可挂钩所有Windows控件并过滤API，也就是通常所说的用户级rootkit，下面就来看一下对Yahoo Messenger的挂钩是怎样实现的。

（1）、使用FindWindow()通过类名取得Yahoo Messenger的句柄。

HWND hWnd = FindWindow("YahooBuddyMain", NULL);

（2）、用前面描述的方法实现对进程的注入。

（3）、在GetDlgItemText()的导入thunk上进行注入，以过滤它的参数。

UINT GetDlgItemText( HWND hDlg,

int nIDDlgItem,

LPTSTR lpString,

int nMaxCount);

（4）、比较对话框ID、nIDDlgItem，以确定当前哪个项目在使用，找到之后，对原始GetDlgItemText()进行挂钩。

CHAR pYahooID[127];

CHAR pPassword[127];

switch(nIDDlgItem)

{

case 211: // Yahoo ID

GetDlgItemText(hDlg, nIDDlgItem, pYahooID, 127);

// ...

GetDlgItemText(hDlg, nIDDlgItem, lpString, nMaxCount);

break;

case 212: //密码

GetDlgItemText(hDlg, nIDDlgItem, pPassword, 127);

// ...

GetDlgItemText(hDlg, nIDDlgItem, lpString, nMaxCount);

break;

default:

GetDlgItemText(hDlg, nIDDlgItem, lpString, nMaxCount);

}

图13：对Yahoo Messenger的挂钩

7、结论

导入表是Windows可执行文件中非常重要的部分，相关知识可助于理解程序在运行时，是怎样请求某个API的。你也可重定向导入表到当前进程的另一个可执行内存中，通过自己的PE加载器防止别人对程序进行逆向工程，或者仅是挂钩API函数；也可从外部在运行时挂起某个进程从而修改它的导入表。更进一步来说，在理解了这个概念之后，还可以创建自己的虚拟机，在Windows或Liunx内部的一个单独环境中，运行Windows可执行文件，也就是说，甚至可以不需要Windows就能运行Windows EXE文件了。

PE文件导入表的代码注入

猜你喜欢