It, more or less, has a separate "Fuzzing Template" system which it uses to generate the brute force test cases. It was never meant to rise to the complexity of Sulley's fuzzing system. I wanted an in between complexity for the dumbest fuzzing and something completely flexible like Sulley and Peach. To solve that 80% problem of, "OK, I just grabbed an HTTP request, let's turn it into a quick and dirty fuzzing template." and from that, "And make sure it runs really fast on a single machine". In the time boxed assessment world you rarely have time to do all that you would like so this seemed to be a reasonable solution.
The beauty of the "fuzzing engine" I built is that there is nothing to it really. You put in "scriptlets", which are really just small bits of Python that generate lists or sequences, and it combines all of them. My goal was to just write up a lot of the common HTTP fuzzing scenarios (integer sequences, alphabetical sequences, demonstrate common encoding and other scenarios giving you a simple list of things you can copy/paste/modify into a template. And then it runs, logging it all into a SQLite database.
I will put it up at http://github.com/bitexploder soon (a week? Maybe two?).
The beauty of the "fuzzing engine" I built is that there is nothing to it really. You put in "scriptlets", which are really just small bits of Python that generate lists or sequences, and it combines all of them. My goal was to just write up a lot of the common HTTP fuzzing scenarios (integer sequences, alphabetical sequences, demonstrate common encoding and other scenarios giving you a simple list of things you can copy/paste/modify into a template. And then it runs, logging it all into a SQLite database.