honggfuzz

Ages old (~2014 IIRC) defer implementation for gcc and for clang: https://github.com/google/honggfuzz/blob/c549b4c31815e170d3b...

Played around with coverage-guided fuzzing using honggfuzz and Intel BTS/PT a while back. Didn't have much time to fine-tune, but it seemed solid. It'd need a couple of months to properly dial in and see real results. The coverage was increasing, and aligning with the symbol tables, it was hitting the right parts of the kernel. Harness: https://github.com/google/honggfuzz/tree/master/examples/lin...

Hamming distance (and popcnt) is also used in gradient descent scenarios. Eg. here's part of fuzzing engine code, where it tries to produce an input which matches some form of variable check inside the fuzzed code: https://github.com/google/honggfuzz/blob/1f09e3bfb0785d9b311... register uint8_t v = ((sizeof(Arg1) * 8) - __builtin_popcount(Arg1 ^ Arg2)); uint8_t prev = ATOMIC_GET(globalCovFeedback->bbMapCmp[pos]); if (prev < v) { ...

A real world example of use: https://github.com/google/honggfuzz/blob/075756bea8d1f08eb19... I think it's a bit better than ld -b binary ... cause it doesn't depend on the static linker generating symbols, which feels a bit like a non-standard/non-portable feature. But, who knows, maybe the vast majority of ld variants actually implement it.

Code: https://github.com/google/honggfuzz/commit/2310ab5f6954cbe4ebaca25ca0a52c72bd4103c5 Including contents of a text-file as a string in C is not that easy, esp. if it's not surrounded by quotes. One cannot simply write static const char str[] = #include "file" ; and static const char str[] = " #include "file" "; will not work either. If you know of a better (cleaner/shorter/less-hacky) way of doing this, and w/o external scripts/bins like `xxd -i` please let me know.

The clang code requires -fblocks/-lBlocksRuntime too, and I was a bit quicker :) https://github.com/google/honggfuzz/commit/a9db9ddc2e24d157a...

I'm not sure if it's required (to know the exit code). inputs, both valid and invalid, will activate various paths in djpeg/libjpeg, and that's the basic goal here. In case you'd like to test persistent fuzzing (should be faster due to a few factors), you can try modifying https://github.com/google/honggfuzz/blob/master/examples/lib... - it will probably take creating main() func which will read data in the AFL_LOOP() loop and call LLVMFuzzerTestOneInput with that input.

Since people are listing fuzzers, there are also the commercial alternatives: Peach Fuzzer (www.peachfuzzer.com/) and Synopsys Defensics (https://goo.gl/wroKI8‎). While my experience is not that recent, these two seem to dominate the network protocol fuzzing domain, whereas some of the open alternatives listed here appear to have become superior in general purpose 'parser' fuzzing. That said, played with honggfuzz recently and it really shows promise, especially if you have access to the source code (https://github.com/google/honggfuzz).

I wonder if this is in any way inspired by this - https://github.com/google/honggfuzz/blob/master/common.h ? I use there defer for both gcc/clang, countof(arr) -> ARRAYSIZE(array) In any case, yeah, going through gcc/clang internals, and through C11 standards gives people some ways to speed-up and clena-up their implementations a bit.

You can try https://github.com/google/honggfuzz - The basic idea is pretty much the same as with afl-fuzz - maximization of code coverage (more or less). Some old write-up on the technique can be found here: https://github.com/google/honggfuzz/blob/wiki/AttachingToPid.... You can attach to a process (-p pid) and then feed it with an external, initial input (from pcap, or hand-crafted). Honggfuzz will modify it to maximize code coverage in the network server. I got pretty decent results with e.g. apache (in must be executed with -X, so it doesn't fork/daemonize).