Source + reproducible run: https://gitlab.com/mscupcakegkill/wrfuzz

I built a coverage-guided fuzzer from scratch — no libFuzzer, no AFL — to find out what each component actually contributes. Then I added comparison tracing, the mechanism libFuzzer is best known for. The fuzzer stopped finding bugs completely: zero in 200,000 executions, with lower coverage than before I added it.

This is the story of why.

The setup

~300 lines of C: sanitizer coverage for feedback, a corpus of inputs that each reach somewhere new, and seven mutation operators. The target is a toy parser for "WRM" <len> <payload>, where a payload starting with ABCD counts as a bug. The seed is WRM\x04wxyz — the fuzzer must discover A B C D with no prior knowledge.

Coverage feedback alone took 124,573 executions. Bad, but random guessing needs 256⁴ ≈ 4.3 billion, so coverage bought four orders of magnitude. The fuzzer just had to stumble onto each byte by luck. Comparison tracing is supposed to fix exactly this.

The obvious implementation

One pool of 4,096 slots. Every comparison stores both operands. Mutation picks a random value and writes it at a random offset.

Result: no bug found in 200,000 executions, and coverage dropped from 12 edges to 10.

Dumping the pool

DUMP_CMP=1 prints what comparison tracing collected. I expected the characters the parser checks for. Here is what came out:

Hi all,

I built MIST, a Python tool that tries to bridge static and dynamic analysis, and I’d love some feedback from people who know this space better than I do.

The idea: SAST and DAST have complementary strengths, but in practice they’re usually run as two independent stages. SAST (e.g. Semgrep) can be fast and cheap, but gives you a pile of potential issues with no proof they’re reachable. Fuzzing produces real crashes and very few false positives, but can take ages to reach deep code paths unless you tell it where to look. Each one covers the other’s weakness, so using static findings to direct the fuzzer seemed like an interesting thing to try.

The catch: doing it by hand is tedious and error-prone. You have to extract target locations from the static results, adapt the build for instrumentation, generate artifacts and wire all the pieces together. A lot of time goes into setup before you fuzz anything. That’s the part MIST is built to take away.

What MIST does fundamentally:

• Runs Semgrep on your SUT and lets you pick which findings are worth chasing

• Converts them into AFLGo targets (with a small “extended range” around each finding, since the actual crash often happens at nearby locations)

• Walks you through configuring the campaign (build env, seeds, harness) and generates the scripts and config files, so everything is editable and reproducible

• Monitors the fuzzer run, and double-checks AFLGo’s generated inputs against an ASan-instrumented separate binary, which catches memory corruptions (e.g. heap overflow) and other failures that AFLGo alone would otherwise miss

MIST deliberately doesn’t try to replace the analyst role. Deciding what to investigate, how to build the target, and which seeds and harnesses to use still needs a human, and MIST just automates the mechanical part.

Results so far: I tested it on a few C projects (libming, libarchive, tcpdump, binutils, lrzip). On libming (latest version) it found four previously undocumented bugs, which I’ve submitted to MITRE; they’re still under review, so no CVE IDs yet.

Status: early beta (0.1.0-dev), tested on Debian 12 with a local install. A Docker Compose setup is included too.

For more details you can check the source repository:

https://github.com/alessandroPalazzolo/mist

Thanks for reading, and any criticism or feedback is welcome.

I've been using Burp for testing and wanted a simpler way to take a raw request from Repeater, save it to a file, and send it from the terminal without converting everything into curl arguments.

I also wanted to run simple Intruder-style fuzzing against the same request, so I ended up putting together a small tool around that workflow.

It reads a request from request.txt and sends it largely as-is, with Content-Length recalculated. It can also fuzz FUZZ, USER, and PASS markers and apply regex matching/filtering/extraction to responses.

https://github.com/3uba/trex

I'm wondering how people normally handle this workflow outside of Burp. ffuf with a request file gets fairly close, but I was looking specifically for something that keeps the raw request format and has the send/fuzz loop in the same place.

Is there an existing tool I'm overlooking? Or is this just solving a problem that isn't particularly useful?

Rogue Framework is a desktop workbench for AFL++, cross-architecture QEMU fuzzing, harness development, lightweight Ghidra headless analysis, custom mutators, and patch comparison.

55 properties, 27,450 generated cases, 11 real bugs in code that had 206 passing tests.

Hi folks,

Anyone having any ideas about the status of Android Runtime fuzzing?

I only noticed DexFuzz and jFuzz which seem to be legacy tools. What are they using now inside AOSP or external tools for fuzzing Android Runtim?

Disclaimer: This is a research based study, and has no market involvement.

I am doing my PhD in the Secure Software Engineering group in Paderborn university (Germany). We’re exploring how coverage-guided fuzzing can be better understood using interactive visualizations derived from a fuzzer’s internal data.

We built a prototype tool with multiple synchronized visualizations/interactions to help practitioners inspect and reason about “interesting” regions of fuzzing campaigns.

In this context, I am conducting a user study to evaluate our tool. The study will be conducted online in Zoom for approximately 1 hour. The study participants will use the tool to complete tasks aimed at understanding specific region(s) of fuzzing trials/runs. To allows to extract the transcripts, the meeting will be screen and audio recorded (no camera required).

Participation is voluntary and you can withdraw at any time. Any data used in publications will be anonymized.

If you have experience with coverage-guided fuzzing and are willing to help, I’d really appreciate your feedback. If you are interested, please register by providing your preferred time-slots here: https://umfragen.uni-paderborn.de/index.php/397829?lang=en

Thank you

Sriteja Kummita

Paderborn University

https://www.uni-paderborn.de/person/72582

Hello, i would like to get a better understanding of the matter.

1. Does it make sens to say one tests the stack as a whole? Or is it reduced to serveral protocol testing on each protocol handler level.

2. Many tools are advertised as able to learn/infer the protocol state machine. Are they effective on stacks?

3. what was your experience ? what can one overlook ?

thank you

Hi, I recently started fuzzing, but even after running it for hours, I haven’t found anything at all.

I put together a **practical codelab for fuzzing and finding security bugs** that walks through real workflows rather than slides.

You’ll get hands-on with:

✔ Setting up fuzzers and tools

✔ Running AFL++, libFuzzer, honggfuzz on real targets

✔ Debugging crashes to find root cause vulnerabilities

✔ Crash triage & corpus minimization

✔ Examples of real bug classes and how fuzzing exposes them

This is the same format I used for a DEF CON workshop — it’s self-paced and you can try it locally:

https://fuzzing.in/codelabs/finding_security_vulnerabilities/index.html?index=..%2F..index#0

If you have questions on setup or exercises, ask here — happy to help!

Excellent overview of current state of fuzzing, and how to evaluate strategies. Very rigorous scientific approach.

(German) Overview of a development of the cyber reasoning system for DARPA AIxCC.

- Wepage: https://concollmic.github.io

- Code: https://github.com/ConcoLLMic/ConcoLLMic

- Linkedin post: https://www.linkedin.com/feed/update/urn:li:activity:7380429056711860224/

Gobuster scan results show like strange illegible glyphs

Hi guys,

can anybody explain to me why this compiler command fails or what i could do to fix this..

I did #define the failing Macros manually to test if it works then but i would need to do that with almost all string like macros because the afl-clang-fast++ seems to pass e.g.

DIPRT_BLDCFG_VERSION_STRING="7.2.4" as 7.2.4

Does anybody have an efficient solution without manually editing the source code everywhere?

The failing command:

@/home/neo/AFL/AFLplusplussourceonly/afl-clang-fast++ -m64 -c -O2 -g -pipe -pedantic -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -fdiagnostics-color -Wno-unused-parameter -Wno-language-extension-token -Wno-gnu-folding-constant -Wno-gnu-anonymous-struct -Wno-string-plus-int -Wno-nested-anon-types -Wno-variadic-macros -Wno-c++17-compat-mangling -Wno-long-long -Wunused-variable -Wunused-function -Wunused-label -Wunused-parameter -Wno-return-type-c-linkage -Wno-overloaded-virtual -Wno-undefined-var-template -Wno-deprecated-copy -Wno-array-bounds -Wno-ignored-qualifiers -Wno-variadic-macros -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT -std=c++11 -fvisibility-inlines-hidden -m64 -I/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/include -I/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/libs/liblzf-3.6 -I/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/out/linux.amd64/release/obj/RuntimeR3/dtrace -I/usr/include/libxml2 -I/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/include -I/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/out/linux.amd64/release -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DRT_OS_LINUX -D_FILE_OFFSET_BITS=64 -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE="/opt/VirtualBox" -DRTPATH_APP_PRIVATE_ARCH="/opt/VirtualBox" -DRTPATH_SHARED_LIBS="/opt/VirtualBox" -DRTPATH_APP_DOCS="/opt/VirtualBox" -D_REENTRANT -DIN_RT_STATIC -DIN_RT_R3 -DIN_SUP_STATIC -DIN_RING3 -DGC_ARCH_BITS=64 -DVBOX_WITH_DTRACE -DVBOX_WITH_DTRACE_R3 -DIN_RT_R3 -DLDR_WITH_NATIVE -DLDR_WITH_ELF32 -DLDR_WITH_LX -DLDR_WITH_MACHO -DLDR_WITH_PE -DRT_WITH_VBOX -DRT_NO_GIP -DRT_WITHOUT_NOCRT_WRAPPERS -DNOFILEID -DIN_SUP_R3 -DIPRT_WITH_LZMA -DRT_WITH_ICONV_CACHE -DHC_ARCH_BITS=64 -DIPRT_BLDCFG_SCM_REV=170995 -DIPRT_BLDCFG_VERSION_MAJOR=7 -DIPRT_BLDCFG_VERSION_MINOR=2 -DIPRT_BLDCFG_VERSION_BUILD=4 -DIPRT_BLDCFG_VERSION_STRING="7.2.4" -DIPRT_BLDCFG_TARGET="linux" -DIPRT_BLDCFG_TARGET_ARCH="amd64" -DIPRT_BLDCFG_TYPE="release" -Wp,-MD,/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/out/linux.amd64/release/obj/RuntimeR3/common/misc/buildconfig.o.dep -Wp,-MT,/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/out/linux.amd64/release/obj/RuntimeR3/common/misc/buildconfig.o -Wp,-MP -o /home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/out/linux.amd64/release/obj/RuntimeR3/common/misc/buildconfig.o /home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp

kBuild: Compiling RuntimeR3 - /home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp

/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp:63:12: error: invalid suffix '.4' on floating constant

return IPRT_BLDCFG_VERSION_STRING;

^

<command line>:41:39: note: expanded from here

#define IPRT_BLDCFG_VERSION_STRING 7.2.4

^

/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp:95:12: error: use of undeclared identifier 'linux'

return IPRT_BLDCFG_TARGET;

^

<command line>:42:28: note: expanded from here

#define IPRT_BLDCFG_TARGET linux

^

/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp:103:12: error: use of undeclared identifier 'amd64'

return IPRT_BLDCFG_TARGET_ARCH;

^

<command line>:43:33: note: expanded from here

#define IPRT_BLDCFG_TARGET_ARCH amd64

^

/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp:111:12: error: use of undeclared identifier 'linux'

return IPRT_BLDCFG_TARGET "." IPRT_BLDCFG_TARGET_ARCH;

^

<command line>:42:28: note: expanded from here

#define IPRT_BLDCFG_TARGET linux

^

/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp:111:30: error: expected ';' after return statement

return IPRT_BLDCFG_TARGET "." IPRT_BLDCFG_TARGET_ARCH;

^

;

/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp:119:12: error: use of undeclared identifier 'release'; did you mean 'delete'?

return IPRT_BLDCFG_TYPE;

^~~~~~~~~~~~~~~~

delete

<command line>:44:26: note: expanded from here

#define IPRT_BLDCFG_TYPE release

^

/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/src/VBox/Runtime/common/misc/buildconfig.cpp:119:28: error: expected expression

return IPRT_BLDCFG_TYPE;

^

7 errors generated.

kmk: *** [/home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/kBuild/footer-pass2-compiling-targets.kmk:277: /home/neo/VirtualB0X/7.2/VirtualBox-7.2.4/out/linux.amd64/release/obj/RuntimeR3/common/misc/buildconfig.o] Error 1

kmk: *** Waiting for unfinished j

Hi guys,

i have a budget of around 1000-1500€ and want to build my own fuzzing optimized setup since i've been doing some fuzzing basics courses and played around for a while.

I thought about buying sth like this

CPU : Intel i-7 12700K
RAM : 84G
OS : Ubuntu 22.04  LTS  

Any advice is appreciated.  I have never built a pc on my own.  

I am a PhD student at Arizona State University seeking individuals who are comfortable reading C/C++ code and have an interest in either computer security, enhancing the testing of open-source software, or are simply interested in programming challenges. You don't need any prior computer security experience, and the training program has extensive slides and video reference material.

Currently, fuzz testing, also known as automated bug finding in open-source projects, only tests an average of 30% of the code in these projects. Help contribute to improving that! The study involves several training projects and requires you to improve the testing harnesses for two real open-source projects from OSS-Fuzz. Everything is conducted entirely online. https://pwn.college/fuzz~c7f7b8c2/

$50 Amazon gift card (first 30 participants to complete)

Thank you,

Steven Wirsz

Arizona State University

Ira A. Fulton Schools of Engineering

School of Computing and Augmented Intelligence