跟踪Native API函数调用.docVIP

跟踪Native?API函数调用 ?????????????????????????????????????? 跟踪Native API函数调用 序言 我们来研究一样非常有用的东西。我甚至要说，在某些情况下，离了它是寸步难行的，而且它能让我们对Windows的内部机制有个很好的认识。是的，本文的题目已经是不新鲜的已经被讲滥了的东西了。在这方面有众多的文章甚至是专著，作者也都是著名的专家，像Jeferry Ritcher, Matt Petriek, Sven Schreiber, Mark Russinovich等等。 是的，值得注意的是这些内容都是针对Windows NT产品线的，对9x来说就不成了。 为了更有效地掌握文章的内容，您应该具有以下知识： ??? * C语言??? * 使用Windows NT? 2K/XP/2K3操作系统??? * 了解进程，线程和Windows NT系统的基本结构。??? * 知道x86处理器如何在保护模式下工作??? * DDK（我们这里用的是DDK 2K Build 2195）??? * SoftIce. 我用的是DriverStudio v2.7。一定要安装完整的Studio版，而不要用那种分离出来的Ice，否则会有兼容性问题。然而这个问题在论坛上讨论了不是一两次了。 我们有什么？ 就我从Ritcher写的书和文章（我为什么要把Ritcher搬出来说事儿呢？对，因为它的书和文章都翻译成了俄语且广泛流行，更重要的是他的方法是比较标准的）里学到的来看，作者从事于直接在用户模式下拦截API函数的处理与研究。对我们的意义何在呢？ 这里有个对比： 方法1： 直接修改进程的import/export table，将原始函数的指针改为指向我们的stub函数。 优点： 1. 实现起来非常简单（因此在Jeferry Ritcher的“Programming Applications for Microsoft Windows”一书中对其进行了详尽的讲解）。此方法保证了进程地址空间不会受到破坏。 2. 出现问题的时候只会宕掉试验用的进程，不会使整个系统崩溃。 缺点： 1. 必须用某些方法向其它进程的地址空间中注入自己的代码（设置全局HOOK (SetWindowsHookEx())，通过注册标加载DLL，直接向进程地址空间注入代码 (WriteProcessMemory(), CreateRemoteThread()…)）。 2. 不能对任意进程进行此种操作，因为Win NT为系统中所有的对象都赋予了一个security descriptor，这个security descripter定义了一个对象能否拥有另一对象以及拥有的程度。 3. 如果被拦截的系统函数A本身基于另一个系统函数B而进程突然直接调用了B，这时该怎么办？这时又得找到函数B并对其进行拦截。 4. 所跟踪到的函数调用情况只是针对于“被处理过”的进程，而不是所有的进程。 方法2： 修改包含所要跟踪的函数的那部分库代码（splicing法，例如在函数起始部分注入指向我们处理程序的机器指令Jmp 0xXXXXXXXX）。?优点： 不要需要修改进程模块的import表！在Win9X中此法可以跟踪到所有进程对系统库函数的调用。 缺点： 1. 有让系统宕掉的危险，因为在修改库代码的时候可能会发生上下文的切换，如果修改尚未完成而被修改的函数被另一个进程或线程调用的话，则发生异常的可能性非常大，而可能更坏的是，系统会挂起或者是发生BSOD。如果此函数的拦截代码位于非调用进程的进程上下文中，也会有同样的问题。?2. 要实现这种方法必须修改库代码的segments，而这些segments却有着“ReadExecute”属性，但修改还是可以的。 最后还有一种办法——特别是用在Windows的调试机制中（Debug API）。讲到这里，我想大家都能明白。顺便说一句，在wasm.ru有相当多的文章是讲前面这些拦截方法的。特别值得注意的是90210/HI-TECH的文章，所有这些方法在那篇文章里都有。 现在我们假设我们需要监视所有的进程来取得某些资源使用情况和对这些资源的操作（创建/打开/读取/写入某个文件、注册表、修改某个进程页的保护属性等等）。准备好了么？现在请再看一下前面的内容并告诉我，借助于前面讲的方法这可能实现吗？当然，在读者当中一定会有乐观主义者认为是可以的，但这说起来容易做起来难。但是有一种办法更为简单，最主要的是它更为有效。 ?????????????????????????????????????????????????????????? NATIVE API 我们知道，Windows 2000的设计理念是它不止能运行Win32应用