码迷,mamicode.com
首页 > Windows程序 > 详细

一个Win32API Trace Tool的设计与实现

时间:2014-09-14 11:13:27      阅读:402      评论:0      收藏:0      [点我收藏+]

标签:des   style   blog   http   color   io   使用   ar   strong   

用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 [__imp__GetProcessHeap@0 (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 [__imp__HeapAlloc@12 (1D2000h)] __imp__GetProcessHeap@0: 001D2008 B9 14 E1 76 ; kernel32.dll!_GetProcessHeapStub@0 (76E114B9h) __imp__HeapAlloc@12: 001D2000 46 E0 55 77 ; ntdll.dll!_RtlAllocateHeap@12 (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如下:

// x86
VOID 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,还没有经过太多测试,有兴趣的朋友可以测试一下。感谢阅读。

一个Win32API Trace Tool的设计与实现

标签:des   style   blog   http   color   io   使用   ar   strong   

原文地址:http://www.cnblogs.com/youlin/p/win32api_trace_tool.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!