jazzer VS American Fuzzy Lop

Check out Jazzer, the code intelligence blog, and search for custom sanitizers for Java etc. https://github.com/CodeIntelligenceTesting/jazzer

Input Generation: The tester uses a fuzzing tool such as CI Fuzz or Jazzer to generate random or unexpected inputs to the software application.

Fuzzing is a testing technique where random values are generated as inputs to find unexpected behavior such as crashes and security issues. Previously we looked at the new Golang release 1.18 which includes native fuzzing and our Core Technology blog series contained a post that compares symbolic execution to different other testing techniques, including fuzzing. Today, we will dive into the Java world and check out the most popular Java fuzzing solution: Jazzer.

Coverage-guided fuzzer for Java

$ git clone https://github.com/CodeIntelligenceTesting/jazzer $ cd jazzer $ ./bazelisk-linux-amd64 run //:jazzer Starting local Bazel server and connecting to it... INFO: Analyzed target //:jazzer (79 packages loaded, 1410 targets configured). INFO: Found 1 target... Target //:jazzer up-to-date: bazel-bin/jazzer INFO: Elapsed time: 43.920s, Critical Path: 7.21s INFO: 83 processes: 4 internal, 79 linux-sandbox. INFO: Build completed successfully, 83 total actions INFO: Build completed successfully, 83 total actions driver/jazzer_driver: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory

One of the authors of Jazzer here. Feel free to ask any questions regarding Jazzer (https://github.com/CodeIntelligenceTesting/jazzer) or how to integrate Java/JVM projects into OSS-Fuzz.

There's some efforts to guide test generation for property based testing to make the instruction pointer explore as large a space as possible.

This effort is more mature in the fuzzing community. See eg American Fuzzy Lop https://github.com/google/AFL

What you're describing, just generating random input to test a program, is sometimes called "blind fuzzing" but the state-of-the-art is far beyond that. Maybe try reading through the documentation of e.g. https://github.com/google/AFL to see what a fuzzer does and why just producing random input isn't even scratching the surface.

for general riscv I used to use this https://github.com/google/AFL I dont know if it supports x64 tho.

Ex ( AFL, WinAFL, HonggFuzz, LibFuzzer, Jazzer )

I wrote this little fuzz test target in order to fuzz it with afl (under ASan and UBSan):

afl, which is trivial to apply to this program:

I made my own version of a TCL interpreter (well, a very TCL like langauge) derived from "picol" available at https://github.com/howerj/pickle. There are many different re-implementations and derivatives of this interpreter but they all seem very "crashy", this one has been significantly hardened by using a fuzzer on it which ran for months called American Fuzzy Lop https://lcamtuf.coredump.cx/afl/ . It is also more suitable for embedded use whilst still not having arbitrary restrictions like many other implementations.

On Linux afl is a very powerful bug-finding tool, and it's a great companion when doing code review. Composes well with ASan and UBSan.

b-, https://lcamtuf.coredump.cx/afl/