资源泄露检测《续》

﹏ヽ暗。殇╰゛Y 2022-01-15 09:11 216阅读 0赞

上次做了一个内存泄露检测的工具，可以在系统退出的时候检测是否发生内存泄露，并打印出泄露内存处的函数调用堆栈，该工具对于发现的泄露的程序确实能够快速的定位到泄露发生的函数调用位置，但是人总是懒惰的动物，使用了几次后发现用起来实在是有点不爽，不爽点主要有：

1、  每次申请内存的时候都记录了调用堆栈，这个时候有多次分配内存操作用来保存文件名、函数名、行号等信息，但是这些信息用起来却非常的少，因为发生内存泄露的可能性还是比较低的，这样使用该工具后程序的性能大打折扣，对于数据库这样的软件来说，非常影响测试的效率。

2、  源代码的控制并不在测试部门，因此如果要进行内存泄露的测试，则每次拿到源代码之后，都需要修改代码，而且修改起来比较繁琐，比如要初始化，记录内存指针和大小，释放的时候要从链表中将其删除，选择合适的位置将泄露的内存打印出来。第一次还很新鲜，第二次开始嫌麻烦了，还出了点错，第三次则决定将这个方法放弃了，这实在太麻烦了，而且程序里面还不一定会有问题。

上述理由应该足够支持我对内存泄露检测工具进行优化了，期望达到的效果就是在对程序改动尽可能小的情况下，可以配置的对程序内存泄露问题进行检测。

第一想法肯定就是用钩子截获内存分配和释放函数，这样在内存分配完后将指针和大小记录下来，释放的时候则将其删除掉，最后剩下的就是有内存泄露的地方了。接下来就是研究如何截获程序内的函数了， Windows 下面提供了专门的 hook 函数，但是只能截获消息，程序内的函数调用并没有消息的通信，这个方法基本上被否定了，在《编程高手箴言》中，有讲述 Windows 上 C 的挂钩，这里截取其中部分文字说明下。

*在Windows* *中，所有编译出来的程序都有一个Import* *。Import* *中有一个JMP* *表，所有的函数调用时，先会跳到Import* *表中，再通过JMP* *跳到对应的执行函数。所以如果要挂钩的话，只需要把JMP* *的地址换成要挂钩的函数的地址即可。别人调用函数时就会JMP* *到挂钩的函数处。*

OK ，实践一下看看 Windows 下面函数调用到底是怎么回事吧，写个简单的程序。

\#include <stdlib.h>

\#include <stdio.h>

void test1()

printf("call test1\\n");

return;

void test2()

printf("call test2\\n");

return;

void

main()

test1();

在 test1 的调用处设置一个断点，调试到此处，查看一下汇编代码：

call @ILT+10(test) (0040100f)

对 test1 的调用是 call 了一个 @ILT+10 ， ILT 的意思就是 Incremental Link Table （只在 Debug 版本下才有） ，即 test1 函数对应的是 ILT 偏移 10 处的 JMP 指令，即 call 跳转到地址 0040100f  处， OK ，按 F11 跟进去看看是什么情况吧。

0040100F jmp test1 (00401020)

00401014 jmp test2 (00401070)

在地址 0040100f  处果然有一个 JMP 指令，它是跳转到 00401020 处，另外 test2 函数的 JMP 指令也在这里哦。看看 00401020 内存是什么吧，按 F11 继续跟进，发现我们终于来到了 test1 函数定义的地方了，首先肯定还是一些函数调用最基本的压栈操作什么的，这里就不细说了，对我们 hook 并没有什么用处。

现在知道函数调用的基本方式了： call  然后 JMP ，要挂钩的话，我们只需要修改 ILT 中 jmp 的地址即可，例如上面，如果要 hook 函数 test1 使得其跳转到 test2 中去，只需要将 jmp 后面的地址修改为 test2 的地址即可。但是要注意的是，这块内存可不是随随便便就可以让你改的，不然不小心写错内存地址， Windows 就惨了，但是 Windows 也不是那么绝情啊，提供了函数来让一个 WriteProcessMemory 的函数来让你写 EXE 的内存，也就是说你很清楚自己在做什么了。另外有点要说明一下，在 debug 下，当把断点设置到 test1() 调用处的时候， watch 一下 test1 ，发现其值是 00401020 ，也就是函数定义的位置，但是如果我们将 test1 打印出来的话，却发现是 0040100F ，也就是 test1 在 ILT 中的位置，这个刚开始走了不少弯路才发现。

写个简单的程序试下我们的想法是否能够行得通吧。

void hookfunc()

LPBYTE lpByte1;

LPBYTE lpByte2;

DWORD dwAddr1;

lpByte1 = (LPBYTE)test1;  //Get old function JMP Addr

lpByte1 = (LPBYTE)&lpByte1\[1\];

lpByte2 = (LPBYTE)test2;  //Get new function JMP Addr

lpByte2 = (LPBYTE)&lpByte2\[1\];  //get new and old function's addr

memcpy(&dwAddr1, lpByte2, sizeof(DWORD));

WriteProcessMemory(GetCurrentProcess(), lpByte1, &dwAddr1,sizeof(DWORD), NULL);

这个程序首先获得 test1 和 test2 函数的地址，也就是 ILT 中的内存地址， JMP 指令占用了一个字节，后面 JMP 的地址是一个 DWORD ，所以先跳过 JMP 的一个字节，将指针指向 JMP 后面的地址，将 test2 函数的地址拷贝出来，用 WriteProcessMemory 函数将 test2 的 JMP 地址写入到 test1 的 JMP 地址中，调试运行下吧，很不幸，程序挂了。上面的想法似乎哪里出问题了？还是继续跟踪一下吧，在 test1 的调用处设置断点，跟踪到 ILT 中，发现：

00401005 jmp test1+4Bh (0040107b) 0040100A jmp test2 (00401080)

JMP 指令和 test2 处的还是不同，后面的地址并不是我们预想的 test2 的地址，理论上此处应该是 00401070 才符合我们的想法，看来上面的想法还是有问题，不如把 JMP 的值打印出来看看吧，分别打印 test1 和 test2 后面 JMP 的地址发现，一个是 0X26 一个是 0X71 ，这个肯定不会是函数的绝对地址了，看来跳转的是一个相对地址，真是笨啊，居然把汇编的知识给忘了，点击右键打开 Code Bytes ，再来看看吧：

00401005 E9 26 00 00 00 jmp test1 (00401030)

这条 JMP 指令的 16 进制形式为 E9 26 00 00 00 ，而 E9 是远距离跳转，即此处的跳转到的地址为： 00401005 + 5 （本条指令的长度） \+ 26 = 00401030 ，而 00401030 是 test1 函数的真实的地址。现在疑团都解开了，按照这个逻辑，我们上面修改过后，实际跳转的位置就应该是 00401005 + 5 + 71 = 0040107B  这个并不是 test2 函数的真实地址。所以上面的程序还要做下改动，即计算出 JMP test1 和 JMP test2 两条指令内存地址的偏移，调整之后应该是：

00401005 + 5 +  （ 0040100A - 00401005 ） \+ 71 = 00401080

而 00401080 就是 test2 函数的真实地址。因此上面 dwAddr1 的值应该按照上面的公式计算出一个偏移量，即 71 +  （ 0040100A - 00401005 ） = 76

再试一下，是不是发现调用 test1 ，打印出来的却是 call test2

Hook 函数 test1 成功了！

但是现在却出现了另外一个问题，如果要调用真实的 test1 函数怎么办呢？现在我们在 ILT 中已经没有 test1 的 JMP 指令了，一种办法是再创建一个空的函数，把这个函数在 ILT 中的 JMP 指令修改为 JMP test1 去，调用那个空的函数就等于是调用了真实的 test1 了，另外一种办法就是把 JMP test2 修改成 JMP test1 ，即交换 test1 和 test2 的调用。第二种办法似乎更加合适点，因为我们有理由这么假设， test2 函数是一个钩子函数，我们一般情况下肯定不会直接来调用 test2 ，而是通过 hook 的方式来调用到 test2 的，所以，把 test1 和 test2 在 ILT 中的指令交换之后，显式的调用 test1 的话就会跳转到 test2 函数，显式的调用 test2 函数的话则跳转到 test1 函数。另外还有一种办法就是记录下 test1 的绝对地址，自己通过汇编代码来直接调用，这个相对来说就麻烦多了，没有试验。

另外有一点要说的就是，对于 Windows 的 API 函数， debug 下也并不会产生类似的 JMP 指令，而是直接通过 CALL 指令跳转到该 API 函数的地址，在《编程高手箴言》中对这种情况进行了处理，其方法是通过申请一个全局变量，使得其仍然按照 JMP 的方式来调用，然后修改 JMP 的地址就可以了。

至此我们已经实现了挂接本地进程内部函数，从根本上解决了内存泄露程序优化的最大障碍。接下来考虑另外一个问题，我们是否直接提供源代码，给一个初始化的函数，将所有这些代码加入到工程中去，然后调用初始化函数来 hook ？相比于最开始的版本需要对所有内存分配、释放代码都做改动，这个已经进步了很多，但是似乎还不是那么的透明，能否做得再方便一点呢？能不能做出动态链接库的形式，然后隐式的调用初始化函数？这样用户只需要在程序编译的时候加载 .lib 文件即可。这里需要提一下 \#pragma 指令的一个用法：

\#pragma comment(linker,”/include:…

pragma comment 指令将一个注释记录放入一个对象文件或可执行文件中，最常用的就是 \#pragma comment(lib,”ws2\_32.lib”) 这个指令告诉编译器将 ws2\_32.lib 库文件链接到目标文件中。而 linker 的作用则是将一个链接选项放入目标文件中， /include 则可以强制包含某个对象。因此我们可以在 DLL 中创建一个用来初始化的类，并声明一个该类的全局对象，例如 \_\_declspec(dllexport) ResourceLeakDetector rld;  将 rld 对象导出，在 rld.h 的头文件中，加上一条 pragma 指令： \#pragma comment(linker, "/include:\_\_imp\_?rld@@3VResourceLeakDetector@@A")  用来强制包含 rld 对象，后面的 @ 符合是因为我们是用 c++ 方式导出的，而 \_\_imp\_ 的意思则是使用导入对象的一个前缀。为了方便用户使用，我们另外在 rld.h 头文件中再加入一个： \#pragma comment(lib, "rld.lib")

至此我们要使用内存泄露检测程序只需要在工程中加入 rld.h ，然后随便在哪个文件里面将 rld.h include 尽量就可以了。

最后就是调用堆栈的效率问题，因为我们在内存泄露情况发生很少的前提下，每次函数调用的时候都获取调用堆栈并将文件名、函数名解析出来保存是很耗资源的事情，一个比较合理的方法就是只获取函数的偏移地址，而不去解析其文件名、函数名。在最后有泄露发生的地方再根据偏移地址来解析文件名、函数名。

最后出来的内存泄露检测程序在运行效率上比原始的版本提升了很多，而且使用起来也不是那么的复杂了：）。

另外，对于路径中包含中文名的话，以前显示会截断字符，究其原因是很多机器上安装的DbgHelp.dll版本太老，没有提供解析路径为宽字符的函数，从windows网站下载了最新的Debug工具库之后，该问题也已经解决。关于Vista下无法获得调用堆栈的问题也随之解决了。

转载于:https://blog.51cto.com/happytest/62791