VrankenFuzz – a multi-sensor, multi-generator mutational fuzz testing engine

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.

3 thoughts on “VrankenFuzz – a multi-sensor, multi-generator mutational fuzz testing engine

  1. 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?

    1. 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.

  2. 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. šŸ˜‰

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.