Fuzzing, Harness Design and Coverage-Guided Testing — DedSec Project

Purpose: Learn fuzzing as a software-assurance discipline: expose parsers and state machines to diverse inputs, detect failures early, minimize them, and turn them into regression tests.

Learning objectives

• Distinguish mutation, generation, coverage-guided, property-based, and stateful fuzzing.
• Design a small deterministic harness around code you own.
• Understand corpus quality, coverage feedback, sanitizers, timeouts, and crash deduplication.
• Minimize failing inputs and fix root causes.
• Reason about why harness quality often matters more than raw execution count.

What fuzzing actually does

Fuzzing explores an input space automatically. The central engineering problem is not “generate random bytes”; it is making generated inputs reach meaningful code while preserving enough variation to find broken assumptions.

A high-quality harness isolates the target, makes runs deterministic, resets state, imposes resource limits, and exposes relevant input directly to the parser or component under test.

Fuzzing models

Mutation-based

Start with valid or semi-valid seed inputs and mutate bytes/tokens/fields. This is effective when the format has structure and seeds get the fuzzer past early parsing gates.

Generation-based

Generate inputs from a grammar or model. This can reach deep semantic states but requires more knowledge of the protocol or format.

Coverage-guided

Use instrumentation feedback to retain inputs that execute new control-flow edges or regions. The fuzzer gradually builds a corpus that reaches more code.

Property-based

Generate structured values and assert invariants. Examples: serialization round trips, parser never crashes, output length is bounded, unauthorized transitions never succeed.

Stateful/protocol fuzzing

Explore sequences of messages or API calls rather than one input. Reset/reproducibility become more difficult but state-machine bugs become reachable.

Harness design

A harness should:

• accept bytes or a structured test value;
• invoke the narrow target directly where possible;
• avoid unrelated networking/UI/database setup;
• avoid nondeterministic timestamps/randomness unless controlled;
• clean state between executions;
• return quickly;
• classify normal rejection as success, not crash.

Fuzz a parser function, not an entire production deployment.

Corpus design

A seed corpus should be small but diverse. Include minimum valid input, typical valid input, boundary sizes, optional fields, nested structures, Unicode where relevant, and historically problematic examples from fixed bugs.

A huge corpus slows startup and can duplicate coverage. Measure what seeds contribute.

Coverage is a guide, not a goal

More coverage does not automatically equal better security testing. A harness can achieve high line coverage while never varying the security-critical state. Conversely, a focused property test may find an authorization flaw with modest code coverage.

Use coverage to discover unexplored paths, then reason about whether those paths represent trust boundaries.

Sanitizers

Memory and undefined-behavior sanitizers make native fuzzing far more informative. They detect invalid accesses, lifetime errors, integer/undefined operations, and similar failures close to the source.

Sanitizer overhead is acceptable in a dedicated testing build. Reproduce important failures in a controlled debug environment and confirm the root cause.

Timeouts and hangs

A hang may indicate an infinite loop, pathological algorithmic complexity, deadlock, or enormous resource request. Capture the smallest input that triggers it and distinguish CPU-bound from blocked I/O or synchronization.

Availability bugs can be security-relevant when untrusted input can trigger disproportionate work.

Crash deduplication

Thousands of failing inputs may map to one underlying bug. Deduplicate by sanitizer signature, top stack frames, faulting location, or root-cause analysis. Do not report every generated input as a separate vulnerability.

Minimization

A minimized reproducer is easier to understand and keep as a regression. Reduction algorithms remove bytes/fields while preserving the failure. For structured inputs, grammar-aware minimization may produce much clearer results than byte deletion.

Differential fuzzing

Feed equivalent input to two implementations and compare outputs. Useful targets include URL parsers, JSON libraries, archive decoders, image parsers, protocol implementations, and cryptographic libraries where exact semantics are defined.

Security interest is highest when disagreement occurs across a trust boundary, such as proxy versus backend interpretation.

Metamorphic testing

Sometimes there is no simple expected output, but you know relationships that should hold. Examples:

• parsing then serializing then parsing should preserve meaning;
• reordering irrelevant fields should not change authorization;
• case normalization should not change identity unexpectedly;
• adding harmless whitespace should not bypass validation;
• a denied action should remain denied after retry.

These relationships are powerful fuzzing oracles.

Safe Python micro-fuzzer

For a parser you wrote, a small standard-library mutator can teach the loop:

import os, random

def mutate(data: bytes) -> bytes:
    b = bytearray(data or b"A")
    for _ in range(random.randint(1, 4)):
        i = random.randrange(len(b))
        b[i] ^= 1 << random.randrange(8)
    return bytes(b)

seed = b"name=alice&role=user"
for _ in range(1000):
    sample = mutate(seed)
    # call YOUR local parser here inside try/except

Do not aim arbitrary generated traffic at remote systems. The lab should call a local function or localhost-only service you control.

Fuzzing authorization logic

Fuzzing is not only for memory safety. Represent a small authorization policy as structured objects: subject, action, resource, tenant, role, ownership. Generate combinations and assert that policy invariants hold.

This often finds “missing combination” bugs that example-based tests miss.

CI integration

Keep a fast regression corpus in normal CI and run longer fuzzing jobs separately. Store minimized crashers with tests when safe. Track time-to-first-failure and coverage trends, but focus on fixed root causes rather than vanity metrics.

Guided study workflow

Before you begin

Complete Modules 36, 40, 52, 65, and 66.

Practice task

Write a small parser or reuse one you own. Build a deterministic harness, seed corpus, timeout, and invariant. Run a bounded local fuzz session. Fix one harmless bug or document why no failure occurred.

Evidence to keep

Harness code, corpus rationale, coverage/paths if available, minimized failing input, root-cause note, and regression test.

Common mistakes to avoid

• fuzzing production endpoints;
• treating random bytes as sufficient strategy;
• keeping non-deterministic state;
• counting duplicate crashes as separate bugs;
• chasing coverage without security invariants.

Mastery check

Explain how harness design affects reachable code and how a minimized input becomes a durable regression test.

Continue with

Modules 69, 71, 78, 84, and 85.