Sulley also comes with other tools that are very useful such as process monitoring tools which allow you to start/monitor/restart a program as well as logging a memory dump of the process that crashed and the fuzz file that caused it to crash. On top of that it can also chain single fuzz tests to fuzz deep into a protocol. These extras can safely be ignored if you manage to knock over the process initially but if you need their support you have it.

I guess in the end your choice of tool comes down to how much resistance the target program puts up weighed against how much you want to kill it via a fuzzer as opposed to getting into a code audit/RE session.

I do agree with nnp that frameworks sometimes offer fuzzing features that are required. However, after having talked to some guys who have found impressive number of security holes I’ve learned most holes were found with very simple fuzzing scripts or through source code audits.

Not to be biased, but like pdp, I’m in love with simple tools that do something specific.

And 15 mins is the most it would take. After that you just map out your protocol in block form and you magically have a much more powerful fuzzer because of all that ‘bloat’. Of course if its you’re first time fuzzing anything you might wonder about ‘block based fuzzing’ or whatever but there’s the same learning curve with what you have, just less of a pay off at the end.

I agree that Peach is over complex. It was after using Peach for the first time that I wrote something quite similar to your script, but I wouldn’t be so quick to write off all fuzzing frameworks because of it. There are plenty out there that are easy to understand for beginners yet offer the power a more advanced user might need (Sulley is a perfect example)

many tools out there just try to be too clever, including peach, tools should not be clever. I think that we are clever enough to figure it out on our own. What tools should do is to automate the boring stuff. In my case, repetition is quite boring. so you should really take this tool from that prospective.

on your last note, well, I love simplicity. I believe that simple is better and more affective. If I can find a problem, like fuzzing technology, which is extremely bloated and I can simplify it to the extend where it does the same but in a minimalistic way, then I considered it as an accomplishment. it is as simple as that. :)

so, although you might not use this fuzzer, I believe that there are tones of people who will use it and will find it very interesting and better suited for the job then peach. They might even use some of the concepts to construct their own fuzzers. There is nothing better then custom tools!

Now I’m not saying fuzzers need to be huge behemoths of applications. Obviously experience has shown that often a simple script with a clear aim can find bugs quickly but if you want things like crash detection, logging, monitoring etc then all that bloat is necessary. Fuzzing can have a steep learning curve for a reason, to do it properly is a skill. Sure at the moment any idiot can still fuzz a couple of bugs in some obscure application but to do it properly isn’t a 5 minute quick hack.

What you have there is pretty much what most hackers had themselves a couple of years ago. I’m not saying it’s not useful, just that it’s not as much of an original idea as you might think.

The only reason I bothered to reply is that I’m kind of surprised as most of the stuff found here is usually pretty cool and off the beaten track ;)