Information Security 8 min read

An Introduction to Fuzz Testing and the AFL Workflow

This article explains the fundamentals of fuzz testing, describes its core concepts and step‑by‑step process, compares mutation‑based and generation‑based test case generation algorithms, and details the popular open‑source AFL tool, its workflow, mutation strategies, and practical advantages.

Continuous Delivery 2.0
Continuous Delivery 2.0
Continuous Delivery 2.0
An Introduction to Fuzz Testing and the AFL Workflow

Background: With the rapid development of information technology, many new automated testing techniques have emerged, and fuzz testing has attracted industry attention for its ability to uncover unknown and hidden defects in software.

Definition of fuzz testing: The core idea is to automatically or semi‑automatically generate random input data according to certain rules, feed it to the target program, and monitor for anomalies such as memory leaks, crashes, or unhandled exceptions, thereby discovering bugs without human intervention.

Basic fuzz‑testing steps: determine the system under test → provide input → generate test cases → feed the cases into the program → monitor the program’s behavior → output crash logs.

Test case generation algorithms: there are two main approaches. (1) Mutation‑based generation creates new cases by mutating known samples; AFL is a well‑known mutation‑based tool. (2) Generation‑based generation builds test cases from protocol or interface specifications after modeling the syntax and semantics.

Tool introduction: Numerous open‑source fuzzing tools exist, with AFL (American Fuzzy Lop) being the most widely used. Developed by Google engineer Michal Zalewski, AFL is hosted on GitHub.

Before running AFL, the target program must be instrumented during compilation to collect code‑coverage information. AFL records coverage from input samples, adjusts inputs to increase coverage, and thus raises the probability of finding vulnerabilities. The typical workflow includes:

1. Instrument the program at compile time to record coverage.

2. Seed the input queue with a set of initial files.

3. Mutate the queued files according to AFL’s strategies.

4. Keep mutated files that expand coverage and add them back to the queue.

5. Continuously repeat the cycle, logging any crashes that occur.

AFL advantages: easy deployment, simple configuration, and relatively high testing efficiency. Although the original AFL targets C/C++ programs, many forks now support other languages such as Java (e.g., Kelinci).

Mutation methods used by AFL (based on a genetic algorithm) include:

Bit flip – invert individual bits.

Arithmetic – perform integer addition/subtraction.

Interest – replace parts of the file with special content.

Dictionary – substitute or insert tokens from a user‑provided dictionary.

Havoc – combine several of the above mutations.

Splice – concatenate two files to create a new one.

AFL requires initial seed files (which may be meaningless data). It automatically discovers file formats and structures, and continues mutating until the queue is exhausted, after which the cycle repeats.

Example: Zalewski demonstrated AFL on the Linux image‑processing program djpeg, starting with the seed string "hello" and eventually generating a large number of valid JPEG images.

In summary, the article provides a concise overview of fuzz testing concepts, the AFL tool’s workflow, mutation strategies, and practical considerations, encouraging readers to continue exploring this testing technique.

Promotional note: A video course titled "Continuous Deployment Training Camp (Python Edition)" is offered at a limited‑time discount, covering building, testing, and deploying pipelines, monitoring deployments, and handling database schema changes.

Software Securitytest case generationfuzz-testingMutation TestingAFL
Continuous Delivery 2.0
Written by

Continuous Delivery 2.0

Tech and case studies on organizational management, team management, and engineering efficiency

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.