Web server fuzzing
Dr. Dobb’s Journal runs an article discussing the tools necessary for fuzzing (testing the system by generating random input in order to cause program failure or crash).
You are fuzzing a Web server’s capability to handle malformed POST data and discover a potentially exploitable memory corruption condition when the 50th test case you sent that crashes the service. You restart the Web daemon and retransmit your last malicious payload, but nothing happens.Was the issue a fluke? Of course not: Computers are deterministic and have no notion of randomness. The issue must rely on some combination of inputs. Perhaps an earlier packet put the Web server in a state that later allowed the 50th test to trigger the memory corruption.We can’t tell without further analysis and we can’t narrow the possibilities down without the capability of replaying the entire test set in a methodical fashion.