破坏力依然不可小视 缓冲区溢出攻防

由于前面的分析已经证明不可能在我们构造的字符串中放上一条“jmp esp”，并修改返回地址指向它，所以第二个难题就是到哪去找“jmp esp”指令了。你可能认为进程自身是首选，因为exe文件具有固定的装入地址，只要它包含这条指令，那么指令的地址就是确定的。但我不得不遗憾的告诉你，又错了。虽然exe的装入地址不会变，但这个地址一般较低，因而找到的“jmp esp”的地址的高字节肯定是0，它不是stubcode，我们没办法对它进行异或处理。如果你看过拙作《nt环境下进程隐藏的实现》，你肯定知道基本上每个进程都会加载kernel32.dll，且它的装入地址在同一操作系统平台上是固定的。而另一个重要事实是它的装入地址足够高，能够满足不含0字节这一要求。所以我们应该到kernel32.dll中去找。但是非常不幸，在我的winxp + sp1系统中，偌大的一个kernel32.dll，竟然没有一个“jmp esp”指令的藏身之地（我没有在其他系统上作过尝试，各位读者如有兴趣可以自己试一下）。我只好退而求其次，到user32.dll中去找了，它在系统中拥有仅次于kernel32.dll的地位。最终，我在地址0x77D437DB处发现了“jmp esp”的身影。

第三个问题是如何在stubcode中调用API。《进程隐藏》一文中对此也有讨论，但情况与现在有一些不同，因为stubcode中没有现成的输入表，所以我们需要自己制作一个小的“输入表”作为stubcode的参数写到UNC字符串中，stubcode还需要其他一些参数，我把这些参数统称为stubparam。而把stubstubcode、stubparam、stubcode以及其它数据合起来构成的UNC字符串称为stub。当然，对stubparam也需要做异或处理以避免在其中出现非法字符。

stubcode中也不能有直接寻址指令，原因很明显，解决办法也很简单（不让用就不用了:)），我就不再多说了。