radamsa VS onefuzz

Ex Radmasa

I used to use radamsa to make my own fuzzer, but it does not support regex to generate datas.

At simplest and most straight forward level fuzz testing is pretty simple to get started with. Collect some input(API calls, files, etc.), pass it to fuzzer(for example radamsa[0]), throw it at program and observe...

Ofc, depending on system collecting input and sending it to system might be bit more complicated. Hardest part is often the observing and finding that an error happens.

Not that this gets you full coverage, for more complex things like protocols something custom that takes lot more effort is probably needed.

[0] https://gitlab.com/akihe/radamsa

Learning how to is half the fun!

There's a bunch of good tutorials out there on [dumb] fuzzing (presumably where you'll start). One starting point I'd recommend is taking a binary that accepts input from stdin and making some proof-of-concepts with AFL (https://lcamtuf.coredump.cx/afl/).

If you'd rather start from a code/library perspective (and not CLI), I'd recommend libfuzzer (https://github.com/Dor1s/libfuzzer-workshop/).

There's a lot of other fuzzers, techniques, and depth to the field, but I'd recommend inch worming through (speed up as you gain more comfort). The Fuzzing Book is good to help you understand the logic behind techniques and strategies (https://www.fuzzingbook.org/)

As for some management, there's a few decent "monitoring" systems out there; personally I just SSH in and check the fuzzer manually (I leave it running in a tmux pane), but if that's not your cup of tea I've heard good things about OneFuzz (https://github.com/microsoft/onefuzz) and LuckyCat (https://github.com/fkie-cad/LuckyCAT).

Happy to answer any specifics of the sort :)

Microsoft’s OneFuzz is tackling some of these issues

https://github.com/microsoft/onefuzz

The biggest problem with fuzzing when it comes to “developer friendliness” isn’t just how to setup the fuzzer and the fact that you need to often write quite a bit of additional code to support fuzzing but that the results aren’t easily consumable.

Getting a fuzzer to cause a crash or some unhandled exception isn’t particularly difficult understanding the actual implication of such crash is where these tools “fail”.

SAST / DAST tools with all their issues such as false positives and relatively limited coverage at least provide actionable results.

Fuzzing not only requires a much higher understanding of the code itself and of its execution but the results are often useless for many developers.

Basically it doesn’t help you breach the gap between seeing a BSOD or a kernel panic and getting a working zero day.

To get a taste of our work, a few of the projects our group published recently: * Freta, a project to democratize full system memory forensics with trusted sensorsfor the cloud. * OneFuzz, a self hosted fuzzing as a service platform, used to scale fuzzing for multiple teams within Microsoft including Windows. * RESTler, the first stateful REST api fuzzer * RAFT, a self-hosted API testing orchestration engine, enabling developers to use RESTler and other api scanning & fuzzing tools in their CICD pipelines.