The attached document describes a new fuzz testing engine I have been busy with. As a power user of fuzzing libraries I’ve noticed some shortcomings (in my view) of the existing offers, and decided to scratch my own itch. Enjoy! PDF LINK.
- Comment
- Reblog
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Guido Vranken 
This sounds like a great fuzzing framework – very extensible! I’ve been looking for a fuzzer that can find inputs that hit unique *combinations* of code blocks instead of just ones that hit new/unique code blocks (and in the existing fuzzers I’ve looked at, this functionality isn’t easy to change). From the paper, it sounds like your fuzzer could be used for this purpose with a modified PCsensor and/or Unique Processor?
Hi Andrew, first of all thank you for reading my paper!
I’ve actually experimented with this, but the problem is that it blows up very quickly.
Imagine a program that takes 26 bytes of of input.
If byte 0 is an even number, A() is called.
If byte 1 is an even number, B() is called.
…
…
If byte 25 is an even number, Z() is called.
2**26 = 67108864 different combinations. In other words almost every random input will get stored in the corpus, and eventually you’ll end up with over 1.5 GB (2**26*26) of corpus data.
Actually standard code coverage is PC Sensor + Unique Processor: PC sensor sends every branch that it hits to the Unique Processor, and that emits the number of unique branches. Eg. to think of it in C++ code, it’s if ( std::set::size() > prevSize ) addToCorpus.
To do it in VrankenFuzz you need to record all code coverage in a std::set, and put this in a std::set<std::set>. Then send the size() of this to a Highest processor.
Only by scoping the sensor very tightly (by enabling it before a certain block that you know will not lead to a corpus blowup, and disabling it after) this approach could be make sense.
That definitely makes sense. I think my use-case is bounded enough to where corpus blowup wouldn’t be an issue, though. Thus far, I’ve created a test fixture that works somewhat similarly to PCSensor / Unique Processor but in a much, much uglier way lol I’m using gcov’s __gcov_reset() and __gcov_dump() functions around some relatively simple input/output processing code, hashing the .gcda file that results, and then using the hash as the indicator of input value uniqueness (storing them in a list to compare against future hash values). It’d be much nicer to leverage PCSensor and work off of the parsed control flow information without having to write hundreds of lines of codes myself. š