/ Hacking

Building a Feedback Driven Fuzzer - Dev Log 4 : GUI is Here

Note: If you haven't read previous posts about the fuzzer, I recommend you read them here

Hi There,
It has been a while since I posted about my fuzzer, I was a little busy with other stuff but I did have some time to make a GUI for the fuzzer.

Before I start here's a gif for the GUI in action.

FuzzerGui

Since the fuzzer is written in Qt the GUI was made as a ui file in Qt creator as usual.

The GUI shows some manadotry options like the input directory, working directory and output directory there are also some other useful features to fine tune the fuzzing.

A very useful feature is "limit the number of concurrent processes". As explained in Previous Posts the fuzzer uses Qts singal and slot system, so the idea is that the fuzzer is using a timer to spawn new processes this means that the fuzzer runs as many processes as it can which can be a problem sometimes, for example, if the application takes time to run what will happen is that the fuzzer will keep running processes and the old processes are still running this will overload the system and that's what an option to limit the number of concurrent processes.

Another useful fearure is "Enable Time Out" which works with the applications that doesn't quit automatically for example most GUI applications, so this option simply quits the application after some time as you specify in "ms", This is not the optimum solution and you should find a way to fuzz the application and let it exit in a normal way but this is just a quick and dirty way if the other ways is not applicable. this feature shouldn't used normally since you can find another way for example some applications like vlc has the --play-and-exit option which is useful when fuzzing, also for some applications you can call functions directly from application DLLs like mentioned in this amazing blog post from ZDI Read It Here.

Also the GUI gives you some information about the fuzzing session like the elasped time, how many basic blocks were covered by the applicationm the number of iterations done, number of crashes and the number of input samples (new sample means new discovered block(s))

See you later in another post, next I will add a crash analysis feature to log uniq crashes only also I need to add a feature to perform dry runs before the actual fuzzing to fill initial coverage, make sure all the test cases introduce new blocks, and allow the user to choose the modules he needs to include in coverage calculations, until then see you later guys.

To keep up with new updates, you can follow me on twitter fady_othman

Buy Me a Coffee at ko-fi.com
Building a Feedback Driven Fuzzer - Dev Log 4 : GUI is Here
Share this

Subscribe to Fady's Technical Blog