Source-linked AI summary
AIJon: Automated Generation of Annotations for Fuzzing
Jayakrishna Menon Vadayath, Hulin Wang, Moritz Schloegel, Jie Hu, Wil Gibbs, Tiffany Bao, Adam Doupé, Ruoyu "Fish" Wang, Yan Shoshitaishvili
TL;DR
Coverage-guided fuzzing can miss inputs that exercise interesting program states without discovering new code paths. AIJON uses LLMs to generate IJON-style annotations and evaluates them at scale; on Magma, annotation-based fuzzing does not consistently outperform AFL++.
Problem
Coverage-guided fuzzing can overlook inputs that are interesting without revealing new behavior, limiting exploration of programs with complex state machines.
Source: §1 · p. 1, §2.1 · p. 2Method
AIJON uses LLMs to automatically generate IJON-style annotations, replicating IJON experiments and evaluating annotation-based fuzzing on Magma.
Source: §1 · pp. 1–2Results
Annotation-based fuzzing did not strictly outperform AFL++ on Magma, triggering bugs faster in 16 cases but slowing fuzzing for 18 vulnerabilities.
Source: §1 · p. 2, §6 · p. 12Takeaways & Limitations
LLMs can generate annotations comparable to human-generated ones without significant performance degradation.
Source: §1 · p. 2, §8 · p. 13The evaluation uses a selected subset of Magma binaries with artificially injected vulnerabilities, so observations may not hold for other program domains.
Source: §6 · p. 12
Abstract
from arXiv · showhide
Modern fuzzers use code coverage as feedback to guide their exploration which has proven to be an effective strategy for driving exploration. However, this strategy overlooks inputs that may be interesting to the target program even without uncovering new code paths. Fortunately, prior research has shown that annotations generated by human domain experts can provide additional feedback, guiding the fuzzer towards interesting parts of the program. In this paper, we replicate experiments presented in IJON and extend them to real-world vulnerability detection at scale. To mitigate the scalability challenge, imposed by the need for human domain expertise, we propose utilizing LLMs to automatically generate annotations. We demonstrate the applicability of LLMs for this purpose and observe that LLMs can generate annotations that perform comparably to human-generated annotations. Motivated by this finding, we design AIJON, a system that leverages LLMs to automatically generate IJON-style annotations. We evaluate AIJON on the Magma benchmark and surprisingly observe that annotation-based fuzzing does not perform strictly better than AFL++. We conduct several experiments to identify the cause of our results and identify key insights regarding the impact of annotations on fuzzing campaigns, including their effect on the energy distribution of the fuzzer. Notably, we observe that LLMs can generate annotations that achieve comparable results to human generated ones, thus opening the door for future research to perform further studies on the impact of annotations at scale.
1 Introduction
AIJON uses LLMs to generate IJON-style annotations, addressing the human-expertise bottleneck that had limited large-scale studies. The paper finds mixed results on Magma and examines how annotations affect fuzzing, while showing LLM-generated annotations can perform comparably to human-generated ones.
1 Introduction
- Coverage-guided fuzzers can overlook inputs that are interesting without exposing new code paths, while IJON annotations add feedback based on expert-identified program states.The need for human expertise had left annotations without a large-scale study of their usefulness for finding bugs.Source: §1 · p. 1
- LLM-generated annotations performed comparably to IJON-author annotations in the Super Mario Bros. experiment.The study used LLM-generated annotations to guide the fuzzer toward completing levels.Source: §1 · p. 2
- On Magma, annotation-based fuzzing was not strictly better than AFL++: it triggered bugs faster in 16 cases but slowed fuzzing for 18 vulnerabilities.Further experiments found that human-generated annotations performed similarly and that annotation interference in multi-target settings can contribute to performance degradation.Source: §1 · p. 2
- Even when annotations target a single vulnerability, fuzzing performance does not improve significantly across all vulnerabilities.The experiment compared both AIJON-generated and human-generated annotations.Source: §1 · p. 2
- Annotations can shift fuzzing energy toward particular program regions, sometimes spending it on states after a vulnerability has already been discovered.For TIF012, the vulnerability was reached almost 64 million times by the end of 24 hours, up from 4 million before it was triggered; most of this energy was spent afterward.Source: §1 · p. 2
- AIJON applies LLMs to generate IJON-style annotations for real-world vulnerability detection at scale, enabling evaluation without relying on human domain experts.The evaluation uses the Magma benchmark suite.Source: §1 · p. 2
2 Background
Coverage feedback can miss progress through program states, while IJON annotations expose additional state information to guide fuzzing. LLMs offer a way to automate annotation generation, and the preliminary Super Mario Bros. comparison reports performance comparable to human annotations.
2.1 IJON
- Coverage alone can miss subtle state transitions needed to reach deeper program logic, because it may not distinguish progress toward a goal from an unproductive input.In the maze example, standard coverage offers no gradient between the starting position and a near-miss at the goal.Source: §2.1 · p. 2
- IJON lets developers expose internal variables through annotations, turning state progress such as maze coordinates into additional feedback for the fuzzer.IJON includes primitives for tracking monotonic progress, comparisons, and distances.Source: §2.1 · pp. 2–3
2.2 Large Language Models for Code Comprehension/Generation
- LLMs' code-comprehension and generation capabilities offer a route to automate annotations, while the Super Mario Bros. table reports comparable performance to IJON-author annotations.The table compares median solve times and their ratio for LLM-generated versus IJON-author annotations.Source: §2.2 · p. 3, Table 1 · p. 3
3 Preliminary Study
The preliminary study tests whether an LLM can generate IJON-style annotations for Super Mario Bros. and finds performance comparable to annotations inserted by IJON's authors.
3 Preliminary Study
- Prior IJON work showed that manual annotations helped fuzzers complete Super Mario Bros. levels faster than vanilla AFL, but required developer expertise to choose annotation sites and variables.The preliminary study uses LLMs to address that scalability constraint.Source: §3 · p. 3
- The authors prompted ChatGPT gpt-4.1 with the program code, applied its annotations, and ran the published IJON version for three 8-hour trials across 28 levels.Crashes were found in 18 levels, and median solve times were compared across those levels.Source: §3 · pp. 3–4
- LLM-generated annotations performed comparably to the manually inserted annotations used in IJON for Super Mario Bros.The experiment evaluated whether annotations guided the fuzzer toward completing game levels.Source: §3 · p. 4
4 AIJON: Scaling IJON Annotation using LLMs
AIJON uses LLMs to automate IJON-style annotation generation, using externally supplied target locations and a staged workflow to prepare annotated programs for fuzzing.
4 AIJON: Scaling IJON Annotation using LLMs
- AIJON automates the generation of IJON-style annotations with LLMs to reduce the manual effort required for large-scale vulnerability detection.The system is designed to generate annotations for target programs.Source: §4 · p. 4
4.1 Design Considerations
- AIJON does not identify optimal annotation locations; it relies on an external Function Report of high-interest locations and indexes functions to fit LLM context windows.The report can come from different external analyses and formats, including static-analysis output or patch files.Source: §4.1 · p. 4
- AIJON's prompt supplies IJON primitives, function source code, and the Function Report; a planner-critic approach generates and refines annotations.The prompt asks the LLM to analyze relevant code and devise a high-level plan for reaching the report's goal.Source: §4.1 · pp. 4–5
4.2 Workflow
- AIJON retrieves functions listed in the Function Report, asks a generator LLM for annotations, then has a critic remove redundant or syntactically incorrect ones.Static checks filter annotations that could introduce syntax errors or side effects, such as annotations that invoke functions.Source: §4.2 · p. 5
- After applying annotations, AIJON compiles the program and retries LLM review on compilation errors up to a bounded number of attempts, then fuzzes with IJON and vanilla AFL++ instances sharing test cases.The instances share interesting test cases using AFL++'s native synchronization mechanism.Source: §4.2 · p. 6
5 Evaluation of Annotations
The evaluation examines whether AIJON and IJON annotations provide useful feedback for guiding fuzzing, across Magma vulnerabilities and the SQL012 case study.
5 Evaluation of Annotations
- AIJON generated valid IJON-style annotations for 71 of 72 vulnerabilities, a 98.6% success rate.In the one failure, it did not produce valid annotations within the maximum attempt limit.Source: §5 · p. 7
5.1 Large-Scale Experiment on Magma
- AFL++ triggered 38 vulnerabilities in 24 hours versus AIJON’s 34; AIJON was faster on 16 shared detections, with a 37.82% average speedup, but missed four AFL++ detections.The results show a trade-off: AIJON sped up some triggers but found fewer vulnerabilities overall.Source: Table 3 · p. 7, §5.1 · p. 7, Figure 3 · p. 8
5.2 Dissecting the Performance Results
- The follow-up experiments tested whether AIJON’s mixed results arose from low-quality LLM annotations or interference among annotations for multiple vulnerabilities in one program.These were the two proposed explanations for AIJON’s negative performance in the large-scale evaluation.Source: §5.2 · p. 8
5.3 H1: Manually Generated Annotations
- With manually generated annotations, IJON triggered 37 vulnerabilities, missed three detected by AFL++, and found two that AFL++ missed.For the 35 vulnerabilities triggered by both configurations, IJON was faster on 14, with a 34.34% average speedup; its survival-time results remained mixed, suggesting LLM annotation quality was not the primary cause.Source: §5.3 · pp. 8–9, Table 4 · p. 9, Figure 5 · p. 9
5.3.1 Analysis of IJON on Magma
- Annotations changed how fuzzing energy was distributed, creating contention among targets that could delay or prevent other vulnerability triggers.AFL++ triggered 19 of 34 shared vulnerabilities faster than IJON, including nine by more than an hour. XML003 was reached nearly 7 million times by AFL++ versus nearly 400,000 by IJON, while IJON favored XML012; IJON also reached TIF012 nearly 64 million times after first triggering it at 4 million reaches. In another example, IJON allocated over 1 billion reaches to SSL016 versus AFL++’s nearly 18 million, leaving fewer reaches for SSL009.Source: §5.3.1 · p. 10
5.4 Single Goal Annotation
- Single-goal annotations were not consistently better: AIJON-SG triggered SQL003 and SQL013, while IJON-SG triggered SQL003 but missed SQL013.IJON-SG increased SQL015’s average reach count by nearly 100 million, reducing its survival time; SQL003 and SQL013 were triggered in fewer than half of the 10 trials, indicating potential randomness. For SQL020, one 8,350-second outlier skewed the average survival time.Source: §5.4 · p. 11
- For SQL012, IJON-SG had a lower reaching count than IJON despite saving multiple inputs that reached the vulnerable location.The authors could not find subsequent inputs generated directly by mutating those saved inputs, suggesting they were not favored for further mutation.Source: §5.4 · pp. 11–12
- Across 10 trials, 2,978 of 2,995 corpus inputs reaching SQL012 produced the same annotated value.IJON_SET provides new feedback only when the annotated variable changes.Source: §5.4 · p. 12
- IJON_SET provides no additional feedback when the annotated variable’s value does not change across inputs.The annotation can recognize new inputs only when they generate new values for that variable.Source: §5.4 · p. 12
6 Discussion
AIJON’s annotation effects vary across vulnerabilities: some improve while others degrade against AFL++. LLM-generated annotations perform comparably to manual annotations, but multi-target energy effects and evaluation scope qualify the findings.
6 Discussion
- Annotation effects varied across vulnerabilities: some survival times fell, while others worsened relative to baseline AFL++.The authors attribute some degradation to annotations’ implicit effects in a multi-target setting.Source: §6 · p. 12
- In multi-target campaigns, annotations can shift energy toward some code regions and degrade performance for certain vulnerabilities.The authors note that annotating a single vulnerability can mitigate the energy-distribution difference, but may not scale to large codebases with many target locations.Source: §6 · p. 12
- LLM-generated annotations achieved survival-time performance comparable to manually generated annotations on Magma.The authors present this as a practical way to generate annotations without the overhead of manual generation.Source: §6 · p. 12
- The evaluation uses a subset of Magma programs with artificially injected vulnerabilities, so findings may not hold in other program domains.The paper notes that the benchmark bugs are based on real-world examples.Source: §6 · p. 12
- MAGMA_LOG statements served as proxies for preliminary static analysis, selecting ideal annotation locations that static analysis may not always identify.Finding suitable locations or improving static analysis was outside the paper’s goal.Source: §6 · p. 13
- Experiments were repeated 10 times against the same AFL++ version, while automated and manual annotations may differ on untested targets or scenarios.The authors assess impact using detected unique vulnerabilities and survival times.Source: §6 · p. 13
7 Related Work
The related-work discussion covers automated vulnerability detection, fuzzing improvements, directed fuzzing, annotations, and LLM-based code generation.
7 Related Work
- Static analysis has been used to detect potential vulnerabilities in source code and binary executables.Source: §7 · p. 13
- Prior fuzzing improvements include seed selection, mutation strategies, coverage weighting, search-space limits, symbolic execution, and grammars.Source: §7 · p. 13
- Directed fuzzing has found vulnerabilities in specific application parts, with separate work prioritizing targets.Source: §7 · p. 13
- Related approaches patch crashes to expose more bugs and use annotations as a bespoke sanitizer for business-logic flaws [41].Source: §7 · p. 13
- LLM security research includes harness generation and automated vulnerability patching.Source: §7 · p. 13
8 Conclusion
The conclusion presents AIJON as an LLM-based approach to generating IJON-style fuzzing annotations and evaluates it on Magma. Results vary against AFL++, while LLM-generated annotations perform similarly to human-generated ones.
8 Conclusion
- AIJON automatically generates IJON-style annotations with LLMs, and its performance varies across vulnerabilities compared with baseline AFL++.Source: §8 · p. 13
- Experiments identify implicit effects of IJON annotations in multi-target fuzzing as a source of negative performance impacts.Source: §8 · p. 13
- LLM-generated annotations perform similarly to human-generated annotations when comparing vulnerability survival times on Magma.Source: §8 · p. 13
9 Ethical Considerations
The ethical discussion frames the work as a replication study focused on vulnerability finding using Magma’s artificially injected bugs. Experiments were isolated locally, and no new bugs were found.
9 Ethical Considerations
- The study is a replication focused on vulnerability finding, with potential stakeholders including maintainers of affected projects.Source: §9 · p. 13
- Experiments used Magma benchmarks with artificially injected vulnerabilities and ran locally in isolated environments.Source: §9 · p. 13
- No new bugs were found, and the authors judged the benefits of studying annotations to outweigh potential risks.Source: §9 · p. 13
A.1 Prompt for Annotation Insertion
The annotation-generation prompt asks an experienced C/C++ developer to instrument Super Mario Bros. so a fuzzer can complete exactly one level. It directs the model to identify useful variables and annotation locations from the function’s source code.
A.1 Prompt for Annotation Insertion
- The appendix provides the prompt used to generate the annotations and includes an IJON annotation cheat sheet and usage example.Source: §A.1 · p. 17
- The prompt targets completion of exactly one level, defined as Mario reaching the map’s rightmost point.It also asks the fuzzer to recognize unique y-coordinate values.Source: §A.1 · p. 17
- The model is asked to read the supplied function, identify key variables and annotation locations, and help the fuzzer complete a level.Source: §A.1 · p. 17
A.2 Additional Results
The appendix adds a Magma comparison table and supplies annotation-generation prompts, IJON macro references, and illustrative code. The Magma prompt focuses instrumentation on vulnerability conditions while requiring the original program semantics to remain intact.
A.2 Additional Results
- Table 7 compares AFL, IJON, and Single bug IJON by mean inputs until the first bug trigger on Magma.The supplied caption identifies the table’s scope but provides no cell values.Source: Table 7 · p. 17, §A.2 · p. 17
- The IJON reference lists macros for state changes, unique or changing values, optimization, and distance toward integer or string targets.Source: §A.2 · p. 18
- The examples show state tags making subsequent edges context-sensitive, with state reverted before leaving the branch.Other examples illustrate feedback for bit matching, approaching a numeric target, matching a string prefix, and maximizing or minimizing values.Source: §A.2 · p. 19
- The Magma prompt directs instrumentation toward MAGMA_LOG vulnerability conditions while preserving program semantics and avoiding redundant branch annotations.It also restricts edits to inserted IJON instrumentation and cautions against function calls in annotation arguments.Source: §A.2 · p. 20