Monitoring tools give you the capability
to observe the program??™s reactions. All that is left is to provide interesting inputs to
the program being tested. As mentioned previously, fuzzing tools are designed for
exactly this purpose, the rapid generation of input cases designed to induce errors in a
program. Because the number of inputs that can be supplied to a program is infinite, the
last thing you want to do is attempt to generate all of your input test cases by hand. It is
entirely possible to build an automated fuzzer to step through every possible input
sequence in a brute-force manner and attempt to generate errors with each new input
value. Unfortunately, most of those input cases would be utterly useless and the amount
of time required to stumble across some useful ones would be prohibitive. The real challenge
of fuzzer development is building them in such a way that they generate interesting
input in an intelligent, efficient manner. An additional problem is that it is very
difficult to develop a generic fuzzer. To reach the many possible code paths for a given
program, a fuzzer usually needs to be somewhat ???protocol aware.??? For example, a fuzzer
built with the goal of overflowing query parameters in an HTTP request is unlikely to
contain sufficient protocol knowledge to also fuzz fields in an SSH key exchange.
Pages:
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628