Coverage-Guided Fuzzing with Dynamic Instrumentation Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing coverage-guided fuzzing techniques face high instrumentation overhead, leading to decreased program vulnerability detection performance after instrumentation code removal, and are limited to specific programming languages like C/C++.
Innovation Solution
A method that calculates dormant coverage and updates instrumentation code based on this coverage, allowing for efficient fuzzing across various programming languages, including Java, by adding or removing instrumentation code dynamically.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If instrumentation code is inserted for coverage measurement, then coverage tracking capability is improved, but execution time increases by 2-10 times
Solution Approach 1:
The instrumentation code is dynamically managed through a coverage map that tracks which coverage points have been visited. The system selectively enables or disables instrumentation code based on whether the corresponding coverage point has been executed, transitioning the fuzzer from instrumented to non-instrumented mode for visited points while maintaining instrumentation for unvisited points.
Solution Approach 2:
Instead of uniformly applying instrumentation throughout the program, the system applies instrumentation locally only at unvisited coverage points. The coverage map enables selective instrumentation where needed, avoiding the overhead of instrumenting entire code paths that have already been explored.
2Productivity
If instrumentation code is removed after single execution to reduce overhead, then execution efficiency is improved, but program vulnerability detecting performance degrades
Solution Approach 1:
The system continuously monitors coverage point execution status and uses this feedback to dynamically adjust instrumentation. When a coverage point is visited, the system records this information in the coverage map and subsequently disables instrumentation for that point, while maintaining instrumentation for unvisited points. This feedback mechanism ensures that instrumentation is removed only when coverage is achieved, not prematurely.
Solution Approach 2:
The coverage map is pre-computed based on the program's control flow graph before fuzzing begins. This preliminary analysis identifies all potential coverage points and their relationships, enabling the system to make informed decisions about when to add or remove instrumentation code during the fuzzing process without compromising vulnerability detection.
3Reliability
If coverage-guided fuzzing is designed for C/C++ languages, then fuzzing effectiveness for these languages is improved, but applicability to other programming languages such as Java is limited
Solution Approach 1:
The system employs a language-agnostic control flow graph representation that can model the execution structure of programs written in different programming languages. The coverage map and instrumentation mechanisms are designed to work with the fundamental control flow concepts that exist across multiple languages, enabling the same fuzzing engine to effectively analyze C/C++, Java, and other languages with different memory management and execution models.
Data Source
AI summary
The present disclosure relates to coverage-guided software fuzzing. A method includes performing a coverage-guided fuzzing test by using an instrumentation code inserted into points of a program under test, the method including: calculating an executed coverage according to which the instrumentation code is executed while inputting a test input value into an execution of the program under test; calculating a dormant coverage indicating each point having instrumentation code that has not been executed within a range of a reference number of times of the points, wherein the reference numbers of times are determined with regard to the respective points while determining whether the instrumentation code has been executed by the execution of the program under test on the test input value; and updating the program under test by adding or removing the instrumentation code on the basis of the dormant.