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.

Modules

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

  1. Creates a process-lifetime StdMapObserver ("response_map") shared between feedback and executor.
  2. Builds MaxMapFeedback + CrashFeedback, then StdState (in-memory corpus + on-disk crash corpus under <out>/crashes).
  3. Constructs NexsizNetworkExecutor that owns the same observer instance (LibAFL 0.15 requirement).
  4. Loads every non-empty file from the seed directory as BytesInput; inserts a default NEXSIZ\r\n seed if the corpus would otherwise be empty.
  5. Wraps NexsizHierarchicalMutator (protocol-aware) inside a StdMutationalStage.
  6. Runs fuzz_loop / fuzz_loop_for honouring -x / -R.

Current limitations

  • Single-core only — multi-worker LLMP is temporarily disabled. If workers > 1 the 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).