Is ProtoCrash a coverage-guided or a blind fuzzer? Coverage-guided: it uses AFL-style edge coverage with hit-count bucketing and only promotes inputs that reach new coverage into the corpus.

What protocols does it support out of the box? HTTP, DNS, SMTP, and custom binary protocols defined via a JSON grammar; standard protocols use scapy/dpkt.

How do I fuzz a custom binary protocol? Define a grammar (typed fields, fixed magic, computed length, allowed command values, payload) in protocol.json and run protocrash fuzz --protocol binary --grammar protocol.json.

Does it need the target’s source or instrumentation for coverage? Coverage tracking expects a coverage-instrumented target (compile with -fprofile-arcs -ftest-coverage) and the --coverage flag; without instrumentation you lose the coverage feedback signal.

How does distributed fuzzing scale? Master-worker: one coordinator, N workers sharing corpus via filesystem with cross-worker crash dedup. Repository-reported throughput is ~50k/180k/350k exec/sec at 1/4/8 workers (~87.5% efficiency); measurement conditions are not documented (independent reproduction required).

Can I run workers across multiple machines? Yes: start protocrash coordinator start --port 6666 and connect workers with --distributed --coordinator host:port --worker-id N.

What mutation strategies are available? Bit/byte flips, arithmetic, interesting values, block operations (delete/insert/duplicate), dictionary injection, cross-over splicing, and structure-aware grammar mutation, all weightable via mutations.yaml.

How are crashes detected? Signal monitoring (SIGSEGV, SIGABRT, SIGILL, SIGFPE), hang/timeout detection, exit-code analysis, and optional ASan/MSan integration for memory errors.

How does it avoid drowning me in duplicate crashes? analyze buckets crashes by signal and stack signature and deduplicates across workers; the documented example reduces 127 crashes to 5 unique buckets.

Can it tell me which crashes are exploitable? analyze --exploitability classifies severity; the exact heuristics behind the classification are not published (calibrate accordingly).

How do I get a minimal reproducer? analyze --minimize reduces a crash input to a minimal reproducing case; you can loop it over each unique bucket.

What report formats are supported? Text, JSON (for automation/CI), and HTML with charts, via protocrash report or analyze --report.

How do I integrate it into CI? Run protocrash fuzz --max-time N --max-execs M, then fail the job if the crashes/ directory is non-empty and upload it as an artifact; a JSON report supports automated parsing.

What are the runtime requirements? Python 3.11+, Linux recommended for best coverage support (Windows is partial), and a target application to fuzz.

How do I deliver input to network services versus binaries? The target can be a binary path, tcp://host:port, udp://host:port, or an http:// URL; the executor delivers via stdin, network, or file depending on the target.

How do I improve results when no crashes are found? Increase timeout, add seed inputs, supply a dictionary for better mutations, and confirm the target is actually reachable/vulnerable.

How do I speed up a slow campaign? Lower the timeout, use --workers for multi-core, minimize the corpus, and prefer faster mutation strategies.

How do I manage a growing corpus? protocrash corpus minimize removes redundant inputs, corpus merge combines corpora, and corpus stats/validate inspect and check them.

How is the fuzzer itself kept safe when running untrusted targets? The architecture calls for sandboxing (namespaces/containers), restricted network/filesystem access, and CPU/memory/FD/process limits plus hang timeouts; the strength of this isolation is asserted but not independently evaluated.

What is ProtoCrash inspired by, and how does it differ? It draws on AFL and LibFuzzer (coverage-guided mutation) and Boofuzz (protocol-structure fuzzing), differing by being pure Python with an integrated triage/exploitability/reporting pipeline and built-in distributed workers.