Synopsis
simple fuzzer is exactly what it sounds like - a simple fuzzer. don't mistake simple with a lack of fuzz capability. this fuzzer has two network modes of operation, an output mode for developing command line fuzzing scripts, as well as taking fuzzing strings from literals and building strings from sequences.
simple fuzz is built to fill a need - the need for a quickly configurable black box testing utility that doesn't require intimate knowledge of the inner workings of C or require specialized software rigs. the aim is to just provide a simple interface, clear inputs/outputs, and reusability.
features
- simple script language for creating test cases
- support for repeating strings as well as fixed strings ('sequences' vs. 'literals')
- (0.7.0alpha) support for block based fuzzing*
- variables within test cases (ex: strings to be replaced with different strings)
- tcp and udp payload transport (icmp support tbd)
- binary substitution support (see basic.a11 for more information)
- plugin support (see the included plugin.txt)
- previous packet contents inclusion
Introduction
why'd i write this? i was going to use spike for black box testing at work, but the problem with that is - how do i get the people in SQA to be able to really hammer away at my stuff? they're not software engineers and in many cases are barely competent programmers. giving them a bulky C program, based on SPIKE that might require heavy modification seemed like i would be setting myself up for maintenance nightmares, and insufficient code coverage.
but - SPIKE is very powerful, very flexible, and VERY well known. this is true but has one caveat: all the power and flexibility and large penis of SPIKE comes at the cost of a steep learning curve. it requires time to learn, and if/when a bug might surface, would require time delving into internals which I don't want to be 'the guy' for at work.
the solution: write my own, more simple fuzzing software. I'm not gonna pretend I know a whole lot about which other fuzzers exist. I saw a webpage that rattled them off like everyone had written them. maybe they have, and I'm late to the party. what I took away from most of the reading was this: all those fuzzers are very specialized. seriously. there are fuzzers which contain their own IP stacks for testing and mapping OS behavior. i certainly don't need that.
so what do i have: a pretty simple fuzzer. it is reminiscent of easy-fuzz from 2004 written by priest of the priestmasters. his layout for building a fuzzy test was pretty nice. a "script" file, with a preamble - setting some basic state and variables, followed by the "meat and potatoes" tests. since i really liked this approach, i sto^H^H^Hborrowed it for my own. naturally, since i wrote my code from scratch i was able to do things i wanted without being tied to his design decisions.