Show threadTimo the timoMar 29

Seeing the explanation of how the path coverage instrumentation that comes with #AFLplusplus works made me realize that it would actually be not just possible but even probably feasible to build something that's just "fully compatible" with what AFL expects to receive.

It's really just a large array of byte values, the address and size are supplied by AFL, where you increase a value at a position when a given edge has been traversed.

The number any given edge gets is just every relevant BB's number xor'd with the previously seen BB's number shifted by 1.

What number do you give a BB? Uniform random numbers seem to be good enough for a start!

An open question I have is that we do compile and then run some code at compile time when compiling #rakulang code, so ideally the "same" input code (for a suitable definition of same) would get the same numbers for all BBs so that only consequential changes in behavior are considered interesting by the fuzzer ...

Timo the timoMar 29

Dipped my toes in #AFLplusplus over the weekend was a kinda nice distraction / pastime.

Got #moarvm (language runtime for #rakulang) its first fuzzing target that exercises the streaming decoder system which is what you would use when reading strings (rather than bytes) with some encoding from a streaming source like the output of a process you're running.

Was a big help to actually put rules in the Makefile to generate the different variants (one with cmplog, one with asan, one with lcov, one with just afl instrumentation) of all the .o files, but I'm not so happy with the rules I came up with.

And to add to the pain, of course there's always nmake which I don't feel like figuring out what exactly I have to do to replace the usage of addsuffix I have ...

https://github.com/MoarVM/MoarVM/pull/1996

If you want to chime in with ideas for what would be good to do with fuzzing in this context, send a comment or toot!

Giving MoarVM its own instrumentation for moarvm bytecode for path coverage would be cool for the future!

Advanced Fuzzing LeagueNov 12, 2025

LibAFL 0.15.4 has just been released 🎉

Of the 30 Contributers for this release, almost half are new faces <3

https://github.com/AFLplusplus/LibAFL/releases/tag/0.15.4

#Fuzzing #LibAFL #AFLplusplus

AddisonJun 27, 2025
Want to learn how to build your own #libafl components, but never had the right project? Try working through the interactive exercises that I released today: https://github.com/addisoncrump/parking-game-fuzzer

You'll work through building your own LibAFL components with templates, allowing you to understand them progressively through the context of trying to solve "Tokyo Parking" (AKA Thinkfun's "Rush Hour") puzzles with fuzzing.

#fuzzing #aflplusplus #puzzles #rust #rustlang
GitHub - addisoncrump/parking-game-fuzzer: Learn to LibAFL with parking-game puzzles.

Learn to LibAFL with parking-game puzzles. Contribute to addisoncrump/parking-game-fuzzer development by creating an account on GitHub.

GitHub
Advanced Fuzzing LeagueMay 30, 2025

Guess who just released #LibAFL 0.15.3?
That's right, you all did! (thank you☺️)

Highlights:

  • better forkserver
  • scriptable Lua mutations
  • SIMD performance in stable rust
  • CmpLog and RISC-V for LibAFL_Unicorn
  • TMin for LibAFL_QEMU
  • Updated Sugar for easy fuzzing

https://github.com/AFLplusplus/LibAFL/releases/tag/0.15.3

#fuzzing #AFLplusplus #LibAFL #update

Release 0.15.3 · AFLplusplus/LibAFL

Highlights New AFL++ Forkserver support in libafl_targets, new forkserver features Introduced LuaMutator, scriptable mutators SIMD performance enhancements for MapFeedback in stable rust (was nigh...

GitHub
Advanced Fuzzing LeagueMar 31, 2025

🚨 LibAFL 0.15.2 🚨

  • Rust 2024 edition
  • LibAFL_Unicorn
  • Use LibAFL rand types for other crates
  • Allow logging to StatsD
  • LibAFL_QEMU updates like binary-only ASan in Rust 🦀🦀🦀, inputs via StdIn, better snapshots

And so much more:

https://github.com/AFLplusplus/LibAFL/releases/tag/0.15.2

#LibAFL #Fuzzing #AFLplusplus

Release 0.15.2 · AFLplusplus/LibAFL

Highlights Moved to Rust 2024 edition Added LibAFL_Unicorn Added SAND: Decoupling Sanitization from Fuzzing for Low Overhead support LibAFL rand types can be used for rust's rand module, and vice ...

GitHub
stfJul 8, 2024
is there a simple way to have the target binary dump it's own test-case while running from afl-fuzz #aflplusplus #afl++ - the thing is, the target binary generates some crypto keys at the start which are used later. i thought to have persistent mode first generate the internal state, then dump the message that is basis for fuzzing and that later in processing needs those keys. but when i run afl-fuzz it complains that the input directory is empty, and when i write the file it's not picked up...
Advanced Fuzzing LeagueJan 6, 2024

Late last year we released #LibAFL 0.11.2
Highlights:

  • Unicode-preserving mutators, better mutations for text!
  • GSoC project: Nicer TUI
  • Scalability introspector
  • Improved libafl_frida
  • Extended libafl_qemu - added CmpLog and more!

Full changelog:
https://github.com/AFLplusplus/LibAFL/releases/tag/0.11.2

#fuzzing #libafl #AFLplusplus

Release 0.11.2 · AFLplusplus/LibAFL

Highlights Unicode-preserving mutators Reworked Tui (GSoC project by @ToSeven) Scalability introspector Larger libafl_frida rework, replaced capstone with yaxpeax in many places Extended libafl_qe...

GitHub
Advanced Fuzzing LeagueDec 30, 2023
If you want to play with the injection vulnerability detection feature shown at #37c3: for AFL++ read instrumentation/README.injections.md; for libafl_qemu check out the vhqemu branch and use fuzzers/qemu_launcher with "-y injections.yaml". #aflplusplus #afl #fuzzing #fuzzing-tools
Addison CrumpAug 2, 2023

Fuzz your cargo-fuzz harness with LibAFL!

I'm happy to share the fuzz runtime described in our recent FUZZING'23 report, CrabSandwich, which expands on libafl_libfuzzer to allow for Rust support. This allows Rust developers to switch away from the now-in-stasis libFuzzer to a LibAFL-based runtime which supports most common features of libFuzzer seamlessly.

Want to try it out for yourself? Simply edit your existing cargo-fuzz harnesses' Cargo.toml to change the libfuzzer-sys dependency as shown here: https://github.com/rust-fuzz/cargo-fuzz/issues/330#issuecomment-1592911175

In most cases, the entire edit is a single-line change (!). At this time, we only support Linux, but are looking for contributions to expand to Windows and macOS as well.

Happy hunting! #fuzzing #rust #libafl #AFLplusplus

LibAFL support? · Issue #330 · rust-fuzz/cargo-fuzz

Now that libfuzzer has been officially deprecated I was wondering if the maintainers of cargo-fuzz are interested to add LibAFL support to this crate directly. LibAFL is not only maintained, but is...

GitHub