**********************************
案例一: 使用IDA PRO+OllyDbg+PEview 追踪windows API 动态链接库函数的调用过程。
首先用文本编辑器写一个C++源程序名为StackFrame.cpp ,代码如下:
1
|
<span style='font-family: "微软雅黑", "Microsoft YaHei"; font-size: 20px;'>#include "stdio.h"<br><br>long add(long a, long b)<br>{<br> long x = a, y = b;<br> return (x + y);<br>}<br><br>int main(int argc, char* argv[])<br>{<br> long a = 1, b = 2;<br> <br> printf("%d\n", add(a, b));<br><br> return 0;<br>}<br></span>
|
使用visual C++ IDE 对该源文件执行编译,汇编,链接一系列的操作后,最终生成的二进制可执行文件(PE格式)名为StackFrame.exe
回顾上述源码,main函数调用了标准C库函数printf打印信息,我们想要知道,
visual C++ 编译器是如何实现printf库函数的,并且StackFrame.exe采用的是静态链接还是动态链接,如果是后者,那么printf又调用了哪些位于动态链接库中的windows API函数?抑或是“动静”兼用?
要解答这些疑问,首先使用IDA PRO打开StackFrame.exe ,它会自动查找程序入口点,这是由编译器自动生成的启动代码,用于初始化我们编写的main函数执行前的环境,以及执行main函数退出后的收尾工作。
一般而言,只要反汇编的对象不是经过加壳或者插入了模糊代码,IDA PRO可以轻松识别程序入口点与main函数,这里为了简化分析流程,我们直接进入main函数的反汇编代码段,如下所示:
我们通过上面一系列的IDA PRO截图可以看到,地址 0x00404063处的call指令想要调用EnterCriticalSection函数,后者的地址尝试以call的操作数0x0040A018给出,但是这个地址处的值,即EnterCriticalSection函数的最终地址,需要操作系统加载器加载StackFrame.exe文件时才能确定,因此我们对磁盘上的文件反汇编时,无法确定动态链接库中函数的地址。
下面以PEview工具查看StackFrame.exe在磁盘上的“真实”面貌(而不是由IDA PRO “模拟”的运行时地址空间面貌)
之所以要先使用PEview工具,是因为后面的动态调试中,会与此处的信息对比,来加深理解程序在磁盘上与在内存中的异同。
使用PEview工具打开StackFrame.exe ,我们的重点是定位到PE文件中的导入表,因为无论是操作系统加载器,反汇编器,还是动态调试器,都依赖该表来解析导入的动态链接库与其中的函数。
我们尝试在原始PE文件中,计算并找出call ds:EnterCriticalSection 指令对应的字节序列,其实这没有想象中困难,而且在这里提出计算方法的原因是,后面会用同样的计算手法来判断Ollydbg中追踪到的EnterCriticalSection函数的实际地址,
该地址究竟属于kernel32.dll还是ntdll.dll?(因为有时Ollydbg给出的信息并不十分准确)届时会用到下面的计算方法。
首先,回到IDA PRO,打开StackFrame.exe的程序段窗口,如下所示:
前面指出,地址 0x00404063处的call指令想要调用EnterCriticalSection函数,因此计算 404063 - 401000 = 3063 , 3063 + 400 = 3463
3463这个值就是该指令字节码在StackFrame.exe的位置,下面验证:
接下来,使用Ollydbg打开StackFrame.exe进行动态调试,我们的目标在于定位EnterCriticalSection函数的入口处,并且单步跟进,查看其中的机器码,然后使用PEview工具,以上面的计算方法,验证Ollydbg给出的该函数所属的动态链接库文件信息是否准确,如下截图所示:
上面验证了StackFrame.exe 在运行时调用的共享库函数,与它在磁盘文件上的导入表中描述的行为一致。
最后,我们验证EnterCriticalSection这个 windows API函确实位于ntdll.dll这个动态链接库中,作为本案例的结尾。
首先,可以访问微软MSDN站点,查找关于EnterCriticalSection函数的信息:
https://msdn.microsoft.com/zh-cn/library/windows/desktop/ms682608(v=vs.85).aspx
最后总结一下:
stack.exe使用“部分”静态链接,其中多数的代码为库代码,
这包含由“编译器库”添加的,处理程序初始化的启动代码与程序退出善后的结束代码,
以及程序中调用的库函数,如printf等函数的代码。
由于 printf 函数需要在屏幕打印信息,涉及更底层的系统I/O操作,因此它需要调用封装这些系统功能的 windows API 函数,
除了windows API 函数所在的DLL(kernel32.dll,ntdll.dll)作为动态链接库在运行时加载以外,
所有其它被调用函数的二进制目标代码都被链接器复制一份副本,然后链接到最终的可执行文件stack.exe中,
因此,stack.exe包含的库代码数量远多于程序员自行编写的代码数量。
使用静态链接的程序,很容易通过IDA PRO的全局函数调用拓扑图识别出来,如下所示:
上面只是抛砖引玉,类似的将IDA PRO,Ollydbg,PEview,甚至WinHex,PEiD等工具结合起来应用,交叉验证的例子不胜枚举,通过熟练使用这些工具,不仅能提高逆向工程的效率与准确度,更重要的是,我们对处理器指令集体系结构,操作系统内存管理,以及动态链接的机制,编译器,链接器的运行原理等等系统底层机理的认识又提升了一个档次。
最后,限于个人知识水平有限,文中若有错误以及误导之处,还请提出指正,不胜感激。
本文出自 “自由,平等,共享,互助” 博客,请务必保留此出处http://shayi1983.blog.51cto.com/4681835/1613615