检测问题

      检测问题现在，你已经熟悉了本地化模糊测试的基本方法，下面你需要进一步了解当目标程序中发生感

兴趣的异常行为时，如何来识别所发生的问题，这在很多时候 都是显而易见的。

例如，程序可能会崩溃，并输出段错误或者其它一些严重的信号消息。然而，由于我们的最终目标是实现自

动化，因此不能依赖于用户手工识别错 误。为了实现自动化，我们需要一种可靠的、可编程的方法。至少

存在两种比较好的方法来实现此目的。

最简单的一种方法是检查应用程序的返回代码。在现代的 UNIX和Linux系统中，如果一个应用程序因为一

个未处理的信号而终止，那么shell的返回代码将等于128加上该信号数字。例如，一个段错误将导 致shell

接收十进制数为139的返回代码，这是因为SIGSEGV的值等于11。如果应用程序因为一个非法指令而终止，

那么shell将接收一个值为 132的返回代码，因为SIGILL的值为4。这其中的逻辑很简单：如果shell关于应用

程序的返回代码是132或者139，那么就标志着一个可能的错 误。你可能也会考虑到异常中断信号。由于在

新版本的glibc中所介绍的更加严格的堆检查，使得SIGABRT更加引人注意。异常中断是这样一个信号，它

可以在进程中产生以终止进程的执行并输出核心信息。尽管在特殊情况下进程可能在堆破坏处发生中断，但

是有很多巧妙的方法可以将其进行扩展。如果你使用攻击 性的sehll脚本来执行模糊测试，那么使用shell的

返回代码将会变得有意义。然而，例如你正在使用一个用C或其它语言编写的适当的模糊器，那么可能 就要

使用wait或者waitpid函数了。在这种方式下进行模糊测试的一般方法是，在前面是由fork和一个execve函

数构成的子进程，后面跟着 wait或者waitpid函数构成的父进程。当使用正确时，就可以通过使用wait或者

waitpid来检查所返回的状态，从而很简便的确定子进程是否 崩溃。

下一章将介绍从本地化模糊测试工具  iFUZZ中所简化的一个代码片段，以说明该方法的使用。如果你关注

于捕获可能被应用程序处理的信号（没有被前面 所讲的方法所发现），那么除了钩住signal程序之外，至少

还有一种可选的方法。你将要使用系统的调试API连接到该进程，并且在信号处理器被激活之 前，截获它所

接收的信号。对大多数的UNIX操作系统而言，你将会使用到ptrace。通常的方法是一个fork和一个ptrace

还有execve构成 父进程，后面跟着waitpid和ptrace构成的子进程，形成一个循环，以持续不断的监视进程

的执行情况，截获并分析可能产生的信号。每当 waitpid在子进程中返回时，就意味着程序已经接收到了一

个信号，或者程序已经终止运行。此时，必须要检查由waitpid所返回的状态，以确定到底 发生了什么事

件。同时，必须要显式的告知应用程序继续执行，并且在大多数情况下都传递信号。该操作也可以使用

ptrace来完成。在SPIKEfile和 notSPIKEfile中的实现可以作为此通用方法的一个参考。这两种工具被用来

实现文件的模糊测试，将在第12章文件格式模糊测试：UNIX平台上的 自动化测试中对它们做详细的介绍。

下一章提供了一个代码片段用以说明该方法。在大多数情况下，ptrace方法对于本地化模糊测试而言是足够

的。很少的 setuid UNIX应用程序为象SIGSEGV和SIGILL等的信号大量的使用信号处理器。同样，一旦你开

始使用ptrace，那么就意味着这些代码没有必要在不 同的操作系统和体系架构中具有兼容性。可以考虑一

下如果你正在创建一个不需修改就可以运行在不同平台上的应用程序的情形。在下一章中，提出了一个简单

的命 令行模糊器的实现，它被设计为只在具有C编译器的UNIX系统中进行编译和运行。该工具也包含一个

针对getenv钩子函数的共享库模糊器。