LibAFL Path
Optional LibAFL 0.15 integration — hierarchical mutator + network executor inside a LibAFL campaign loop.
Nexsiz ships a first-class optional path that wires the protocol-aware hierarchical mutator and network executor into LibAFL 0.15. The native engine remains the default; LibAFL is activated only when the binary is built with the feature and the operator passes -L.
src/execution/libafl_runner.rs, libafl_exec.rs, libafl_mutator.rs. Feature flag: libafl (pulls libafl 0.15.4, libafl_bolts with serdeany_autoreg, serde).
Build
cargo build --release --features libafl
# or
cargo build --release --features libafl,json-model
Without the feature, -L/--libafl exits with a clear rebuild instruction. The serdeany_autoreg feature on libafl_bolts is required so observers and StdState populate the type registry; otherwise startup panics with an empty types registry.
Activation
nexsiz -h 127.0.0.1 -p 21 -m ftp -s seeds/ftp -L -v
nexsiz -h 10.0.0.5 -p 1883 -m mqtt -L -x 50000 -v
CLI: -L / --libafl. Config key: use_libafl=true. All other flags (-m, -s, -o, -r, timeout, max-execs, max-runtime) still apply.
What the runner does
- Creates a process-lifetime
StdMapObserver("response_map") shared between feedback and executor. - Builds
MaxMapFeedback+CrashFeedback, thenStdState(in-memory corpus + on-disk crash corpus under<out>/crashes). - Constructs
NexsizNetworkExecutorthat owns the same observer instance (LibAFL 0.15 requirement). - Loads every non-empty file from the seed directory as
BytesInput; inserts a defaultNEXSIZ\r\nseed if the corpus would otherwise be empty. - Wraps
NexsizHierarchicalMutator(protocol-aware) inside aStdMutationalStage. - Runs
fuzz_loop/fuzz_loop_forhonouring-x/-R.
Current limitations
- Single-core only — multi-worker LLMP is temporarily disabled. If
workers > 1the runner prints a notice and continues single-core. - Snapshot / desocket / NXS post-crash actors are native-engine features; they are not automatically available on the LibAFL path.
- Coverage feedback uses the response map observer, not the Frida/SHM or software providers.
When to use it
- You want LibAFL’s scheduling, feedback composition, and corpus management while keeping Nexsiz’s hierarchical protocol mutations.
- You already have LibAFL-based tooling and need a network-protocol executor that understands FTP/SMTP/HTTP/MQTT/etc. structure.
- For pure Nexsiz campaigns with snapshot, desocket, NXS, or live Python RPC, stay on the native engine (default path).