|
标 题:
【原创】使用IDA PRO+OllyDbg+PEview 追踪windows API 动态链接库函数的调用过程。
作 者: shayi 时 间: 2015-02-12,05:19:54 链 接: http://bbs.pediy.com/showthread.php?t=197829 使用IDA PRO+OllyDbg+PEview 追踪windows API 动态链接库函数的调用过程。 （本文同步更新至我的51blog上，我最初是在那里发布的，由于引用该处的图片，因此带有水印，该贴原始出处如下： http://shayi1983.blog.51cto.com/4681835/1613615 ） 首先用文本编辑器写一个C++源程序名为StackFrame.cpp ，代码如下：
代码:
#include "stdio.h"
long add(long a, long b)
{
long x = a, y = b;
return (x + y);
}
int main(int argc, char* argv[])
{
long a = 1, b = 2;
printf("%d\n", add(a, b));
return 0;
}
回顾上述源码，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等工具结合起来应用，交叉验证的例子不胜枚举，通过熟练使用这些工具，不仅能提高逆向工程的效率与准确度，更重要的是，我们对处理器指令集体系结构，操作系统内存管理，以及动态链接的机制，编译器，链接器的运行原理等等系统底层机理的认识又提升了一个档次。 最后，限于个人知识水平有限，文中若有错误以及误导之处，还请提出指正，不胜感激。 有任何问题，看法，也欢迎提出讨论。 *转载请注明来自看雪论坛@PEdiy.com |
| 共 8 位会员 感谢 shayi 发表的文章： |
dolphinzhu (2015-03-03),
hbcld (2015-02-27),
hrpirip (2015-02-26),
Lnairan (2015-02-25),
springkang[DFCG (2015-03-14),
学gg (2015-02-23),
雪衫 (2015-03-04),
马来 (2015-06-07)
|
初级会员
|
写的很清楚哦。
| ||
  |
| lihuakx |
| 查看公开信息 |
| 查找 lihuakx 发表的帖子 |
| 查找 lihuakx 发表的所有主题 |
普通会员
|
补充一下,前面在查看绝大部分使用静态链接的程序中,整个函数的调用拓扑,非常凌乱,我们甚至找不到main函数与最终的DLL函数入口
下面这张来自于 IDA PRO 的函数递归调用图,把范围缩小到了我们追踪的从main()到 EnterCriticalSection() 的整个过程,验证了前面在StackFrame的代码节中的查找工作:  | ||
| shayi |
| 查看公开信息 |
| 查找 shayi 发表的帖子 |
| 查找 shayi 发表的所有主题 |
| 查看 shayi 发表的精华帖 |
|
普通会员
|
下面这张图是用于生成上图的函数调用设置:  | ||
| shayi |
| 查看公开信息 |
| 查找 shayi 发表的帖子 |
| 查找 shayi 发表的所有主题 |
| 查看 shayi 发表的精华帖 |
|
普通会员
|
不错 。。。。。。。。。。。。。。。。。。。。
| ||
|
|
| yingyue |
| 查看公开信息 |
| 查找 yingyue 发表的帖子 |
| 查找 yingyue 发表的所有主题 |
2101
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
