#effective fuzzing of file format parsers

1 messages · Page 1 of 1 (latest)

turbid grove
#

Suppose I write a parser for some mildly tricky file format. If I want to fuzz it effectively, don't I have to provide example input that's good enough to actually get into the code? In my mind, I should be providing a somewhat full-featured example of the format that the fuzzer can mutate. If you know of examples of people doing stuff like this, please point me at them. Thanks.

mellow elk
#

yes, the idea behind fuzzing is you get random input, to do anything useful you have to transform that into something more useful.

For a lexer the raw bytes are fine, but then you'd want to transform that into only valid tokens to ensure you move past the lexer since you already tested that, and again then transform into valid trees to move past the parser since that has been validated.

technically you dont need to transform it at all, but that will only get the fuzzer stuck in earlier code you dont want to fuzz any more.

zig provides a nice Smith api, to transform that data more easily. Loris has a couple of fuzzer streams you can use for examples, even the older ones are good, as the important part is how you transform the data, not the apis zig has to make it easier.