AFLplusplus VS syzkaller

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

https://arxiv.org/abs/2402.09171 :

> This paper describes Meta's TestGen-LLM tool, which uses LLMs to automatically improve existing human-written tests. TestGen-LLM verifies that its generated test classes successfully clear a set of filters that assure measurable improvement over the original test suite, thereby eliminating problems due to LLM hallucination. [...] We believe this is the first report on industrial scale deployment of LLM-generated code backed by such assurances of code improvement.

Coverage-guided unit test improvement might [with LLMs] be efficient too.

https://github.com/topics/coverage-guided-fuzzing :

- e.g. Google/syzkaller is a coverage-guided syscall fuzzer: https://github.com/google/syzkaller

- Gitlab CI supports coverage-guided fuzzing: https://docs.gitlab.com/ee/user/application_security/coverag...

- oss-fuzz, osv

Additional ways to improve tests:

Hypothesis and pynguin generate tests from type annotations.

There are various tools to generate type annotations for Python code;

> pytype (Google) [1], PyAnnotate (Dropbox) [2], and MonkeyType (Instagram) [3] all do dynamic / runtime PEP-484 type annotation type inference [4] to generate type annotations. https://news.ycombinator.com/item?id=39139198

icontract-hypothesis generates tests from icontract DbC Design by Contract type, value, and invariance constraints specified as precondition and postcondition @decorators:

https://google.github.io/clusterfuzz/setting-up-fuzzing/libf...

> OSS-Fuzz runs CloudFuzz[Lite?] for many open source repos and feeds OSV OpenSSF Vulnerability Format: https://github.com/google/osv#current-data-sources

.

Google/syzkaller https://github.com/google/syzkaller :

>> syzkaller is an unsupervised coverage-guided kernel fuzzer. Supported OSes: Akaros, FreeBSD, Fuchsia, gVisor, Linux, NetBSD, OpenBSD, Windows

.

ghidra-patchdiff-correlator:

The key to modern fuzzing is feedback, usually some kind of coverage testing of the program under test. This allows the fuzzer to be much smarter about how it finds new code paths, and makes fuzzing find bugs a lot quicker.

Google have a project to do fuzzing on Linux system calls using coverage feedback: https://github.com/google/syzkaller

Utilities that try to exercise ("fuzz") an interface with the intent of discovering bugs are called "fuzzers". The tool that comes to mind is syzkaller.

It's true that USB is probably a less desirable attack surface than modems, because it actually requires the user to physically connect their device to a malicious device, but I wouldn't discount it as impractical and unlikely to happen in the wild. There's a reason some of the more famous malware and spyware used to spread/attack over USB. Google actually does USB driver fuzzing and the amount of potentially devastating vulnerabilities is staggering.