jevkostream.scm VS AFLplusplus

I tried sketching one out in Python: https://github.com/jevko/parsejevko.py ; one in C: https://github.com/jevko/parsejevko.c ; one in Java: https://github.com/jevko/parsejevko.java ; one in Scheme: https://github.com/jevko/jevkostream.scm (that's a streaming parser stub, more fleshed out one in JS is here: https://github.com/jevko/jevkostream.js ); and there are some implementations of Jevko formats and other related things in the GitHub organization: https://github.com/jevko

It could be cool to see some explanation of CFG representations or GIMPLE/LLVM here. GCC/Clang can print those out as text, or just compile to that code and not go lower if you ask them to. There are some interesting things you can do with bytecode, like Rellic, AFL++, or optview2. It seems a bit reductive imo to go straight from high-level code to disassembly without at all examining any layers in between. Especially if we use something like Polygeist or CIR.

Honestly, I wouldn't bother writing your own fuzzer, and just use one of the existing solutions, like afl++. Contrary to popular belief, good fuzzers do not just generate random bytes; the way they generate data depends on a genetic algorithm based on the code paths taken by the program. AFL++ can also fuzz regular binaries that weren't instrumented, but according to the documentation it is much less effective.

Be outside the loop? At least that's how they do it in their example https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.persistent_mode.md

I use fuzzers, as every programmer should, and do not commit unless my compiler can be fuzzed for at least 24 hours without any crashes (if I were selling the software, I'd increase that period). I use AFL++ in LTO mode and comby-decomposer with a crappy script I made to collect crash test cases. I am also interested in afl-compiler-fuzzer, but have not yet tried it. Later, I'd like to try my hand at making a test generator that reaches codegen more often (no compile errors in the random source code). I use afl-tmin to minimize test cases, but the result is always illegible without manual work, and usually has extra junk the minimizer is incapable of deleting. Something like C-Reduce would be useful here.

1: https://github.com/ArkScript-lang/Ark 2: https://github.com/AFLplusplus/AFLplusplus

Frelatage is a coverage-based Python fuzzing library which can be used to fuzz python code. The development of Frelatage was inspired by various other fuzzers, including AFL/AFL++, Atheris and PyFuzzer.The main purpose of the project is to take advantage of the best features of these fuzzers and gather them together into a new tool in order to efficiently fuzz python applications.

I personally have not gone over any books over the topic so I cannot recommend books. However, there is a popular fuzzer known as AFL++ that specifies its technical workings and has a tutorial on its usage in the documentation. You can find it here. I found using the tool helped me gain a good understanding of the topic.

With AFL++ you can even determine exactly where the fork happens:

https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...