用VC编程也有不短的时间了，对kernel32、advapi32、user32、gdi32等动态库里的API多数都已经很熟悉了。API是操作系统提供给应用程序的一组服务，很久以前就想要做个小工具，用来跟踪应用程序对API的调用，对于分析程序的行为、功能的实现原理以及Bug的定位都会有很大的帮助。可是长久以来，都没有付诸实际行动。最近，为了定位一个有趣的Bug，终于动手把这个设想实现出来。
PE文件动态链接的细节原理就是：在代码中调用API时，按__stdcall调用约定传参，然后call Import Table中对应的Entry，Import Table中对应的Entry其实是一个绝对地址。这个才是API的真正地址，是在PE文件被加载时由系统加载器填写的。例如：
;x86 code LPVOID lpMem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 8);
001D1001 8B 35 08 20 1D 00 mov esi,dword ptr [[email protected] (1D2008h)]
001D1007 6A 08 push 8
001D1009 6A 08 push 8
001D100B FF D6 call esi
001D100D 50 push eax
001D100E FF 15 00 20 1D 00 call dword ptr [[email protected] (1D2000h)]
[email protected]:
001D2008 B9 14 E1 76 ; [email protected] (76E114B9h)
[email protected]:
001D2000 46 E0 55 77 ; [email protected] (7755E046h)
;x64 code
LPVOID lpMem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 8);
000000013F141006 FF 15 04 10 00 00 call qword ptr [__imp_GetProcessHeap (13F142010h)]
000000013F14100C BA 08 00 00 00 mov edx,8
000000013F141011 48 8B C8 mov rcx,rax
000000013F141014 44 8B C2 mov r8d,edx
000000013F141017 FF 15 E3 0F 00 00 call qword ptr [__imp_HeapAlloc (13F142000h)]
000000013F14101D 48 8B D8 mov rbx,rax
__imp_GetProcessHeap:
000000013F142010 20 1A 25 77 00 00 00 00 ; kernel32.dll!GetProcessHeapStub (0000000077251A20h)
__imp_HeapAlloc:
000000013F142000 60 33 3A 77 00 00 00 00 ; ntdll.dll!RtlAllocateHeap (00000000773A3360h)
Hook Import Table的原理就是把Hook Import Table中指定API的地址替换成我们自己实现的Stub函数的地址，在Stub函数中做一些我们想要的处理和调用原始的API。预期目标是想要通过Hook Import Table来实现对API调用的跟踪，要求能够获得“哪个模块调用了哪个模块中的哪个API”，传递的参数和返回值。
整体设计思路：做一个HookApi.dll，在被加载时从一个XML文件读取要进行Hook的模块和API列表，为每一个要Hook的API生成一个Stub函数，Stub函数的功能是调用原始API并将参数和返回值输出到Log文件，最后将Import Table中的API地址替换为相应的Stub函数地址即完成Hook。
接下来详细说明各部分的设计：
一，XML列表格式
<hook logmax="1024">
<library name="HookTest.exe">
<import dll="kernel32.dll">
<api name="HeapAlloc" args="3" />
<api name="HeapFree" args="3" />
</import>
<import dll="user32.dll">
<api name="DestroyWindow" args="1" />
</import>
</library>
<library name="gdiplus.dll">
<import dll="gdi32.dll">
<api name="Ellipse" args="5" />
<api name="Pie" args="9" />
<api name="Chord" args="9" />
<api name="Arc" args="9" />
</import>
</library>
</hook>
根节点“hook”的“logmax”属性指定Log文件的Max Size，以MB为单位，取值范围32~32768。“library”为要被Hook Import的调用者模块，“import”则是包含被调用API的模块，“api”的“args”属性指定API的参数个数。
二，Log Function的设计
Log Function被设计用来记录API调用、传递的参数和返回值。在生成的每个API的Stub函数中都会调用Log Function，所以为了尽可能减小对性能的影响，使用FileMapping来将Log写到文件，Log Function接收的参数不包含任何模块、函数名称字符串，而是依赖于XML列表的索引值。x86和x64版本的Log Function的prototype如下：
// x86VOID WINAPI LogOut32(DWORD dwLibIdx, DWORD dwDllIdx, DWORD dwApiIdx, DWORD dwArgCnt, DWORD dwRetVal, LPVOID lpArgs);// x64 VOID WINAPI LogOut64(UINT64 uLibIdxDllIdx, UINT64 uApiIdxArgCnt, UINT64 uRetVal, LPVOID lpArgs);
输出的每条Log记录的格式为（伪代码）：
struct LogRecord
{
DWORD dwLibIdx; // 调用者模块索引
DWORD dwDllIdx; // API所在模块索引
DWORD dwApiIdx; // API索引
DWORD dwArgCnt; // 参数个数
PVOID aryArgs[dwArgCnt]; // 参数列表，是否存在取决于参数个数，在x86平台每个参数大小为4字节，x64平台为8字节。
DWORD dwRetVal; // 返回值
};
跟踪完成后，使用另一个工具“Log2Text.exe”来将Log文件转化为txt格式。FileMapping的最大文件大小从XML文件的“logmax”指定，每次映射到内存中的View大小为8MB，当检测到使用过半时向后移动4MB重新映射。使用CriticalSection做多线程同步。
三，Stub Function的汇编代码
这里的Stub Function主要是想要实现一段通用的代码，可以在运行时根据XML中的参数信息为每个要Hook的API动态的生成。经过几次修改后确定下来，思路是：x86平台，将栈上的参数按照原始顺序再次压栈，然后调用真正的API，将原始参数地址、返回值和模块、API索引等信息传递给Log Function，然后返回同时清理栈；x64平台，首先备份传参寄存器，如果栈上还有参数，按原始顺序再次压栈，调用真正API，将栈上备份参数地址、返回值和模块、API索引等信息传递给Log Function，返回。也就是说从传参与栈的角度看，Stub函数等价于一个与API prototype一致的C函数。具体代码如下：
x86 code;------------------------------------------------; 参数压栈，如果有的话
mov ecx,0x12345678 ; 参数个数，根据XML动态写入
cmp ecx,0
je l01_02
mov eax,ecx
l01_01: push dword [esp + eax * 4]
loop l01_01
;------------------------------------------------
; 调用真正的API
l01_02: call 0x12345678 ; API的相对地址，动态写入
push eax ; 备份返回值
;------------------------------------------------
; 调用Log Function
lea ecx,[esp + 8]
push ecx ; 指向参数列表的指针
push eax ; API返回值
push 0x12345678 ; ArgCnt，根据XML动态写入
push 0x12345678 ; ApiIdx，根据XML动态写入
push 0x12345678 ; DllIdx，根据XML动态写入
push 0x12345678 ; LibIdx，根据XML动态写入
call 0x12345678 ; Log Function相对地址，动态写入
;------------------------------------------------
; 恢复返回值，返回并清理栈
pop eax
ret 0x1234 ; 栈上参数大小，根据XML动态写入
x64 code;------------------------------------------------; 备份传参寄存器到栈上的预留空间
push rbp
mov rbp,rsp
mov [rbp + 40],r9
mov [rbp + 32],r8
mov [rbp + 24],rdx
mov [rbp + 16],rcx
;------------------------------------------------
; 栈上参数压栈，如果有的话
mov rcx,0x12345678 ; 参数个数，根据XML动态写入
cmp rcx,4
jle l01_02
sub rcx,4
l01_01: push qword [rbp + rcx * 8 + 40]
loop l01_01
l01_02: mov rcx,[rbp + 16]
;------------------------------------------------
; 调用真正API
sub rsp,20h
mov rax,0x123456789abcdef ; API地址，动态写入
call rax
mov rsp,rbp
push rax ; 备份返回值
;------------------------------------------------
; 调用Log Function
lea r9,[rbp + 16] ; 指向参数列表的指针
mov r8,rax ; API返回值
mov rdx,0x123456789abcdef ; ApiIdx | (ArgCnt << 32)得到的一个UINT64，根据XML生成并动态写入
mov rcx,0x123456789abcdef ; LibIdx | (DllIdx << 32)得到的一个UINT64，根据XML生成并动态写入
sub rsp,20h
mov rax,0x123456789abcdef ; Log Function地址，动态写入
call rax
;------------------------------------------------
; 恢复返回值并返回
mov rax,[rbp - 8]
mov rsp,rbp
pop rbp
ret
以上汇编代码中类似于“0x12345678”只是用来占位而已，没有实际意义。其中调用Log Function的代码与上节中的prototype相对应。在实行Hook时，有专门的代码为每个Stub分配可执行虚拟内存、填写需要动态写入的值，再将Import Table中对应的Entry指向Stub函数。
这种设计要求XML中指定的参数个数必须精确。在设计Stub函数时，如果不需要跟踪返回值，可以在调用真正API之前，通过Log Function输出参数列表等信息，然后直接jmp到API地址，避免参数再次压栈，提高性能也同时避免了因为XML中错误的参数个数造成的栈破坏。
四，Log2Text转换工具
此工具的作用是根据XML列表，将Log文件转化成可以直接阅读的txt文件，为了优化性能同样使用FileMapping，txt文件最大大小同样取决于“logmax”。输出的txt文本格式如下：
HookTest.exe : kernel32.dll : HeapAlloc ( 0x005c0000, 0x00000008, 0x00000004 ) : 0x00614350 HookTest.exe : kernel32.dll : HeapFree ( 0x005c0000, 0x00000000, 0x00614350 ) : 0x00000001 HookTest.exe : kernel32.dll : HeapAlloc ( 0x005c0000, 0x00000008, 0x00000008 ) : 0x00614350 HookTest.exe : kernel32.dll : HeapFree ( 0x005c0000, 0x00000000, 0x00614350 ) : 0x00000001 HookTest.exe : kernel32.dll : HeapAlloc ( 0x005c0000, 0x00000008, 0x0000000c ) : 0x00615838 HookTest.exe : kernel32.dll : HeapFree ( 0x005c0000, 0x00000000, 0x00615838 ) : 0x00000001 HookTest.exe : kernel32.dll : HeapAlloc ( 0x005c0000, 0x00000008, 0x00000010 ) : 0x00615838 HookTest.exe : kernel32.dll : HeapFree ( 0x005c0000, 0x00000000, 0x00615838 ) : 0x00000001 HookTest.exe : kernel32.dll : HeapAlloc ( 0x005c0000, 0x00000008, 0x00000014 ) : 0x00613768 HookTest.exe : kernel32.dll : HeapFree ( 0x005c0000, 0x00000000, 0x00613768 ) : 0x00000001 HookTest.exe : kernel32.dll : HeapAlloc ( 0x005c0000, 0x00000008, 0x00000018 ) : 0x00613768 HookTest.exe : kernel32.dll : HeapFree ( 0x005c0000, 0x00000000, 0x00613768 ) : 0x00000001
依次是：“调用者模块名称 : 包含API的模块名称 : API名称 ( 参数列表 ) : 返回值”，对于void函数也会取到返回值，就是当时eax/rax的值，没有任何意义。其实也可以把函数的返回地址一起由Log文件输出，可以更精确地跟踪到模块中调用API的代码位置。
此工具目前只实现了Import Table的Hook，基本上也可以按照同样思路Hook Export Table来应对GetProcAddress或者用户自己实现类似函数。inline Hook可算是终极手法，但是想要做成一个普适型工具好像不是很可行。实现这个工具的目的，只是为了辅助我们宏观上大致定位一下我们感兴趣的位置，在下调试断点时可以更明确，更深入的跟踪分析还是需要自己去调试。
上述可执行文件已上传至我的百度云：http://pan.baidu.com/s/1nNB0y，还没有经过太多测试，有兴趣的朋友可以测试一下。感谢阅读。