FrameShift: Dynamic Relation Discovery in Fuzzing

• FrameShift is a dynamic fuzzing technique that automatically identifies relation fields in structured inputs to preserve payload structure during mutations.
• It uses a two-phase approach—candidate detection and insertion-point discovery—to update metadata while keeping execution coverage intact.
• Experimental evaluations report up to 50% increased coverage and consistent performance boosts across diverse real-world targets.

FrameShift is a lightweight, purely dynamic technique for coverage-guided fuzzers that automatically discovers relation fields in structured inputs and preserves those relations during mutation, thereby learning to resize inputs without breaking them. It targets the common failure mode in which mutations to size or offset metadata invalidate the payload layout and cause malformed inputs to be rejected early by the target program. Implemented in AFL++ and LibAFL, FrameShift uses only standard coverage feedback, requires no additional instrumentation, and was evaluated over 12+ CPU-years on 16 real-world targets, where it improved fuzzer performance in each configuration and sometimes increased coverage by more than 50% (Green et al., 7 Jul 2025).

1. Problem formulation and motivation

Coverage-guided fuzzers maintain a corpus of “interesting” inputs, mutate those inputs, execute the target, and retain any testcase that reaches new coverage. This workflow is highly effective on unstructured byte streams, but it degrades on structured binary formats in which metadata fields encode the sizes or offsets of later regions. In such formats, mutating a size or offset field without updating the region it describes produces what FrameShift calls a frameshift mutation: the input becomes malformed, fails early validation, and coverage collapses back to an earlier point. The same problem arises when insertions or deletions alter payload length without repairing the corresponding metadata (Green et al., 7 Jul 2025).

The technique is motivated by two observations. First, if mutating bytes at offset $p$ causes a large loss of the original coverage, those bytes are candidates for being a size or offset field. Second, if a compensating insertion or deletion of exactly the same amount restores coverage, the pair of edits constitutes evidence for a true metadata-to-payload relation. FrameShift operationalizes these observations in a way that is intended to be simple, fast, and compatible with ordinary coverage-guided fuzzing pipelines (Green et al., 7 Jul 2025).

The central objective is therefore not grammar inference in the general sense, but targeted recovery of structural relations that matter for resizing operations. In the terminology of the paper, these are relation fields: metadata whose semantic role is to describe the extent or position of a payload span. By preserving those relations during mutation, FrameShift aims to reduce time spent on malformed inputs and increase the fraction of executions that penetrate deeper into the target.

2. Formal model of relation fields and coverage restoration

FrameShift defines coverage as a function $F(I)$ over an input $I$, where the profile may be, for example, a set of edges hit under the chosen instrumentation. Using this representation, the paper formalizes destructive and restorative mutations in terms of coverage loss and recovery (Green et al., 7 Jul 2025).

A destructive mutant $I^{-}$ is one for which coverage drops by at least a fraction $T_{loss}$:

$$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$

A restorative mutant $I^{+}$ of $I^{-}$ is one that regains at least a fraction $T_{restore}$ of the lost coverage:

$$| F(I^{+}) \cap (F(I) \setminus F(I^{-})) | \ge T_{restore} \cdot |F(I) \setminus F(I^{-})|.$$

The object learned by the system is a 5-tuple

$F(I)$0

which means that the $F(I)$1-byte integer at offset $F(I)$2, with endianness $F(I)$3, equals the length of the payload span from $F(I)$4 (inclusive) to $F(I)$5 (exclusive). The paper further requires that mutating the field without touching that span is destructive, whereas changing it together with an insertion or deletion in $F(I)$6 of exactly the same size is restorative. In set notation, FrameShift seeks to identify

$F(I)$7

This formulation is deliberately operational. It does not attempt to prove semantic equivalence of parses; instead, it uses observed coverage behavior to infer a structural relation that is useful to the fuzzer. The method therefore depends on the target’s validation and parsing logic being sufficiently reflected in coverage changes.

3. Relation discovery and safe resizing workflow

FrameShift adds a relation-discovery stage that runs once on every newly discovered corpus input. The stage first records the baseline coverage $F(I)$8, then performs candidate detection. For each potential field size $F(I)$9, each endianness $I$0, and each position $I$1 in the input, it decodes the integer value $I$2 at $I$3, skips the case if $I$4, mutates the field by adding a large delta $I$5, and measures coverage. If the mutated input satisfies the destructive criterion, the tuple $I$6 is recorded as a candidate relation field (Green et al., 7 Jul 2025).

The second phase is insertion-point discovery. For each candidate $I$7, the algorithm constructs

$I$8

For each $I$9, it computes $I^{-}$0. If $I^{-}$1, it tries inserting or removing $I^{-}$2 bytes at index $I^{-}$3 to produce a candidate restorative mutant $I^{-}$4. If the restorative threshold is met, the relation

$I^{-}$5

is confirmed and stored with the queue entry (Green et al., 7 Jul 2025).

Once a set of relations $I^{-}$6 is attached to a queue entry $I^{-}$7, the mutators are redefined at a higher level. During havoc or splice, if a planned mutation inserts into, removes from, or replaces a relation field at $I^{-}$8, FrameShift updates the positions $I^{-}$9, $T_{loss}$0, and $T_{loss}$1 for all affected relations and then rewrites the integer at $T_{loss}$2 so that it equals $T_{loss}$3 again. The paper describes this as using OnInsert and OnRemove routines to keep the metadata synchronized with the shifted payload (Green et al., 7 Jul 2025).

The worst-case cost of relation discovery is $T_{loss}$4 trial runs for input length $T_{loss}$5, but the implementation prunes the search heavily by restricting $T_{loss}$6 to $T_{loss}$7, skipping values $T_{loss}$8, and testing only a small set of starting points. In practice, the paper reports analysis on the order of $T_{loss}$9–$$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$0 target executions per input, running in milliseconds to a few hundred milliseconds. It also states that there is no soundness guarantee: false positives are possible if, for example, a non-length field and a coincidental insertion restore coverage, although the $$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$1 and $$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$2 thresholds are intended to keep such cases rare (Green et al., 7 Jul 2025).

4. Implementations and experimental results

FrameShift was implemented in two state-of-the-art fuzzers. In AFL++(FS), approximately 600 lines of C were added. The implementation introduces a new stage after “queue cycle” that runs relation discovery on new inputs, serializes relations alongside the testcase, and instruments havoc and splice to invoke the update routines before execve. The paper reports that adding FrameShift increased AFL++’s own analysis time by approximately 5–10%. In LibAFL(FS), approximately 1,600 lines of Rust were added, including a new corpus entry type $$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$3, a modular stage for the same two-phase analysis, and integration with existing coverage feedback and the Atheris Python adaptor; overhead is described as comparable to AFL++’s (Green et al., 7 Jul 2025).

The evaluation used 16 real-world targets, including all binary formats from FuzzBench plus JSON, XML, ms-tpm-20-ref, and qpdf. Baselines were AFL, AFL++, LibAFL, WEIZZ, and NestFuzz. The experimental setup comprised 10 trials of 48 hours each on Google Cloud C3 systems with Intel Sapphire Rapids processors, in both seeded and empty-corpus modes, for a total of at least 12 CPU-years. The primary metrics were edge coverage after 48 hours and average-score, defined as percent of the best (Green et al., 7 Jul 2025).

Aspect	Reported result	Context
Benchmarks led by FrameShift variants	10/16	AFL++(FS), LibAFL(FS)
Average-score improvement	+7 points	vs. AFL++ on empty corpus
Average-score improvement	+1.6 points	vs. LibAFL on seeded corpus
Statistically significant boosts	7 benchmarks	$$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$4 coverage gain
Maximum reported increase	more than 50%	some benchmark/configuration pairs
Worst-case loss	5.5% coverage loss	extremely large-corpus/text formats

The paper identifies libjpeg, lcms, bloaty, ms-tpm-20-ref, woff2, libpcap, and openssl as benchmarks with statistically significant coverage boosts of at least 3%. It also reports that worst-case overhead manifested as a 5.5% coverage loss on extremely large-corpus or text formats, attributed to analysis time. The overall empirical result is that FrameShift improved the performance of the fuzzer in each configuration tested, even though the magnitude of improvement was target-dependent (Green et al., 7 Jul 2025).

5. Case studies and cross-language generalization

The case studies are used to show that the technique can recover structurally meaningful relations across multiple file and protocol families, and that it generalizes beyond C/C++ targets to Rust and Python (Green et al., 7 Jul 2025).

On PNG, the paper compares libpng and image-png in Rust. For libpng, FrameShift finds 9/12 size fields, skipping IHDR, cHRM, and IEND, which are fixed-length by the implementation, in 0.31 seconds and 4,705 executions. On image-png, it finds largely the same fields plus cHRM, because image-png does not validate it, in 1.7 seconds and 9,933 executions. The contrast is important because the relations learned are not properties of the file format alone; they are filtered through the semantics actually enforced by the target program (Green et al., 7 Jul 2025).

On ASN.1/DER, the paper studies openssl and pyasn1. For openssl, FrameShift identifies the outer SEQUENCE length and each inner TLV length in 0.059 seconds and 63 executions, effectively treating multi-byte length fields as 2-byte big-endian when the value remains within the same encoding width; this yields a reported 6% coverage improvement. On pyasn1, accessed through Atheris, the same relations are found in 25 milliseconds and 125 executions, with one false positive at $$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$5, which the paper states can be removed by tuning thresholds (Green et al., 7 Jul 2025).

On ELF via bloaty, FrameShift discovers the program header table offset, the section header table offset, and section-size fields for .text and .shstrtab, including an indirect relation via anchors, in 0.46 seconds and 1,571 executions. The paper also reports a “bonus” behavior: after a code splice is injected into .text, FrameShift automatically rebases the executable by updating three distinct relations, producing a still-executable ELF. On the TPM benchmark ms-tpm-20-ref, no baseline fuzzer passed the third nested size check even once in 20 CPU-days, whereas AFL++(FS) found 14 newly sized inputs passing that check and LibAFL(FS) found 8, with a reported 15% coverage gain (Green et al., 7 Jul 2025).

Target	Relations or effect	Quantitative note
libpng	9/12 size fields	0.31 s, 4,705 execs
image-png (Rust)	same fields + cHRM	1.7 s, 9,933 execs
openssl	outer SEQUENCE + inner TLV lengths	0.059 s, 63 execs
pyasn1 (Python)	same relations, one false positive	25 ms, 125 execs
bloaty	ELF offsets and section sizes	0.46 s, 1,571 execs
ms-tpm-20-ref	nested size-check penetration	+15% coverage

These examples establish that the method is driven by coverage semantics rather than by a hard-coded parser for any one format family. They also show that the same discovery mechanism can be effective for binary container formats, length-prefixed encodings, executable formats, and protocol inputs.

6. Limitations, failure modes, and extensions

The paper identifies several limitations. First, FrameShift can incur non-trivial overhead on formats that generate extremely large corpora, such as freetype2 and libxml2, or on text formats with no size fields. The authors note that future work might detect the case in which no relations are found and disable further analysis. Second, the current system does not discover variable-length integer encodings precisely, such as ASN.1 multi-byte length prefixes beyond the low-order two bytes, although the reported approximation is sufficient so long as the value stays within the same byte width (Green et al., 7 Jul 2025).

A third limitation is that some streaming or sync-recovering formats are frameshift-resistant: trimming or inserting data does not alter later parsing coverage, so the destructive/restorative pattern is not observed and no relation is learned. The paper lists Ogg Vorbis and OpenH264 as examples. Because the method is purely dynamic and anchored in coverage restoration, it is intrinsically weakest where structural violations do not produce a detectable coverage signature (Green et al., 7 Jul 2025).

The stated future directions remain consistent with this design philosophy. The paper proposes extending the double-mutant pattern to discover compressed regions such as zlib and base64, chunk-based boundaries, and candidates suggested by a learned grammar or an LLM, as well as automatically tuning the thresholds $$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$6 and $$| F(I) \setminus F(I^{-}) | \ge T_{loss} \cdot |F(I)|.$$7 per target or per coverage-feedback type. These proposals preserve the defining characteristic of FrameShift: it augments ordinary coverage-guided fuzzing by learning structural resize relations from execution behavior rather than from manual format specifications (Green et al., 7 Jul 2025).