A fuzzer feeds a program inputs its author may not have expected: mutated files, odd encodings, boundary values, or combinations of fields. Generating inputs is the easy half. The harness also needs a clear sign that something went wrong and a way to save the exact input that triggered it.
That sign is the oracle. It might be a crash, timeout, sanitizer finding, violated invariant, or disagreement between two implementations. Pick the check before starting a long run. Without it, a fuzzer can produce millions of cases and leave the tester guessing which behavior mattered.
Start with a small target you control, such as a file parser or library call. Keep a handful of valid seeds. Set a time or execution budget. Coverage feedback can help the fuzzer reach new code, but high coverage says nothing by itself about correctness.
When a failure appears, save the input, build identifier, runtime settings, and harness version. Reduce the input while preserving the failure, then run it again from a clean state. A small, repeatable case is much easier for someone else to diagnose than a crash buried in a huge corpus.
A crash is a finding to investigate. Its impact depends on where the input comes from, what the process can access, and whether an attacker can reach the code. Reproduce first, then work out severity and follow the project’s disclosure policy.
OWASP’s fuzzing overview describes the basic technique. The research page’s diagram shows the loop: seed, mutate, run, check, save, and triage.