ISC4DGF: Enhancing Directed Grey-box Fuzzing with LLM-Driven Initial Seed Corpus Generation

Pre-trained Large Language Models (LLMs) are advanced neural networks with billions of parameters. These models are trained on large amounts of text data using an autoregressive method, where the model learns to predict the next word in a sequence based on the previous context. This extensive training allows LLMs to act as one-shot or even zero-shot learners [32], enabling them to perform a wide variety of tasks with little or no additional training.

LLMs are typically used for specific tasks through either fine-tuning [36] or prompting [29]. Fine-tuning involves further training the model on a task-specific dataset, which adjusts its internal weights to enhance performance for that task. However, this approach can be challenging due to the potential lack of suitable datasets, and as LLMs grow in size [24], the cost and complexity of fine-tuning also increase. Alternatively, prompting enables the LLM to perform tasks without altering its weights. The process involves providing the model with a detailed description of the task, sometimes including a few examples to illustrate how to solve it. By utilizing the model’s existing knowledge, users can guide its performance through a technique known as prompt engineering [29], where different input instructions are tested to identify the most effective prompts.

Fuzz testing is a important technique for improving software security. The main idea is to provide the target program with a large number of varied inputs as test cases, which helps expose software vulnerabilities by triggering exceptions. Developers can then identify and fix these vulnerabilities earlier, reducing the cost of later repairs.

Fuzzer test case generation methods are typically divided into generation-based and mutation-based approaches. Generation-based fuzzers, such as QuickFuzz [18], Gandalf [28], and CodeAlchemist [19], generate test cases based on the input format specifications of the program being tested. In contrast, mutation-based fuzzers, like AFL [1], libFuzzer [38], AFLGo [10], and Beacon [22], start with an initial set of seed inputs and create new test cases by modifying these seeds.

American Fuzzy Lop (AFL) [1], one of the most popular coverage-guided grey-box fuzzers, uses lightweight code instrumentation to collect coverage data during fuzzing. Feeding this coverage information back into the mutation algorithm helps guide the fuzzer to explore new code paths in the target program. While coverage-guided fuzzers like AFL excel at discovering a broad range of vulnerabilities by exploring as much of the program’s code as possible, they are not specifically optimized for targeting particular vulnerabilities. Directed grey-box fuzzers are designed to focus the fuzzing process on specific areas of the code that are more likely to contain known or suspected vulnerabilities. Instead of spreading resources across the entire codebase, directed fuzzers concentrate on reaching and testing specific targets more efficiently. AFLGo [10], the first directed grey-box fuzzer, introduced the concept of targeting specific vulnerabilities within coverage-guided grey-box fuzz testing. By employing a heuristic distance algorithm based on static analysis, AFLGo measures the proximity between seeds and test targets. Prioritizing seeds that are closer to the target allows the fuzzer to trigger specific vulnerabilities more quickly.

ISC4DGF enhances the fuzzing process by using a refinement LLM to optimize user inputs and a generation LLM to produce and select targeted initial seed inputs. ISC4DGF begins by receiving relevant user input, including project details, driver source code, CVE information, and CVE corresponding patches. Since user input may be lengthy, redundant, or partially irrelevant, we utilize a large, state-of-the-art LLM to refine these prompts into a concise and informative form. ISC4DGF then feeds the optimized prompts into the generation LLM, which scores and ranks the generated results, selecting the most suitable candidates as the initial seed corpus. The original seed set provided by the fuzzer is replaced with the optimized seed set generated by the LLM. The fuzzer is then executed until it either identifies the specified bug or the testing period ends. Crash reports generated during this process are used to analyze and validate the capabilities of ISC4DGF.

The following section provides a detailed introduction to the first of the two main steps in ISC4DGF, which involves refining and extracting user input from a given template through the refinement LLM to generate prompts suitable for directed fuzzing. The focus of ISC4DGF is on selecting an appropriate initial seed corpus to enable efficient exploration during directed fuzzing, ultimately discovering the unique target specified by the user. Therefore, we consider user input that describes both the general context of the program under test (PUT) and the specifics of the target vulnerability. User input specifically includes project introduction, driver source code, CVE details, and the CVE corresponding patch.

• •

  Project introduction: Provides an overview of the PUT’s functionality, enhancing the LLM’s comprehension of the program.

• •

  Driver source code: Ensures that the generated seeds conform to the expected format, as non-compliant seeds may lead to ineffective or inefficient fuzzing.

• •

  CVE details: Specifies a clear target for seed generation, including key information such as CVE numbers, descriptions, and vulnerability types.

• •

  CVE corresponding patch: Improves the specificity of seed generation by leveraging detailed information from the vulnerability patch, enhancing the LLM’s understanding of the specific vulnerability.

Unlike traditional fuzzers that require input in a specific format, ISC4DGF can directly interpret natural language descriptions or code examples provided by the user. The four types of input in ISC4DGF are manually specified by the user and may include some redundant or irrelevant information. Consequently, using these inputs directly as prompts for generating LLM outputs may not be effective. To address this, ISC4DGF employs a refinement process where the refinement LLM prunes and optimizes the user-provided prompts to generate higher-quality inputs, thereby enabling more effective LLM-based fuzz testing.

We use the prompt: ”Please summarize the above information concisely to describe the functionality of the test project, the usage of the fuzz driver, and the details of the vulnerability.” ISC4DGF first generates an initial candidate prompt using greedy sampling with a temperature of 0, enabling the refinement LLM to produce a reliable solution with high confidence. This approach has been widely applied in other fields, such as program synthesis [13]. Following this, ISC4DGF continues to sample at a higher temperature to generate more diverse prompts, similar to methods used in previous studies [13, 43]. High-temperature sampling generates different prompts, each offering a unique summary of the user input. Prompts are continuously added to the candidate list until the required number of candidates is reached.

Since LLMs are fundamentally based on text processing and generation, their core function is to understand and generate natural language text. However, many fuzz testing programs require inputs that are not purely text-based; for instance, libpng requires input in PNG format, and poppler requires input in PDF format. The solution proposed by ISC4DGF is to use a generation LLM to produce Python code that generates the required input format. The prompt used is: ”Generate Python code so that the running result of the code is $\langle format\rangle$ file as a test case that may trigger $\langle CVE\rangle$ in $\langle PUT\rangle$.” This approach results in an initial seed corpus in a valid input format compatible with the PUT.

ISC4DGF feeds candidate prompts into the generation LLM to create multiple Python scripts that may generate initial seeds capable of triggering the specified CVE. The sorting and selection of these candidate prompts depend on several factors, including the compilability of the script, the compliance of the seed type, and the size of the generated seeds. Since LLM-generated code is based on pattern recognition and large-scale training data, it may not always perfectly align with the specific environment or requirements. Several issues may arise with this generation method, potentially rendering the generated code unusable. Firstly, the generated code might contain syntax or logical errors because LLMs rely on language patterns without actual compilation or execution. Secondly, the code might lack necessary dependencies or library references, leading to execution failures even if the syntax is correct. Additionally, the code may not adhere to specific programming standards or formatting requirements.

To ensure that the generated code is functional, we manually run the LLM-generated code and select only those scripts that compile successfully and meet the format requirements of the PUT as the initial seeds. This process guarantees the validity and executability of the initial seeds. Moreover, it is important to note that LLM-generated seed code may sometimes be too large, exceeding the maximum seed size that the fuzzer can handle. Oversized seeds not only affect the fuzzer’s execution efficiency but may also prevent the fuzzer from processing these seeds correctly or even cause it to crash. Therefore, during the seed selection process, we screen out and exclude these oversized seeds to ensure that the fuzzer operates effectively while optimizing performance.

The main goal of ISC4DGF is to achieve directed fuzzing, specifically by efficiently reproducing known vulnerabilities. Directed fuzzing plays a critical role in vulnerability research, as it allows researchers to focus on specific areas of interest, increasing the likelihood of identifying critical issues in software systems. To evaluate ISC4DGF’s performance in this regard, we conducted a comparative analysis with AFLGo[10], a state-of-the-art directed fuzzer known for its precision and effectiveness. In our evaluation, we ran each fuzzer 10 times under identical conditions and measured the average time required to successfully reproduce the marked vulnerabilities in the Magma benchmark suite, which is widely recognized for its challenging and diverse set of real-world vulnerabilities. The results of this comparison are summarized in Table 3, which lists the time required by each evaluated fuzzer to trigger different targets.

Compared to the directed fuzzer AFLGo, ISC4DGF demonstrated a marked enhancement, with a p-value of less than 0.05. On average, ISC4DGF outperformed AFLGo by a factor of 31.35x, reflecting a substantial enhancement in its directed fuzzing capabilities. A key factor contributing to ISC4DGF’s superior performance is its efficient approach to targeting specific vulnerabilities. AFLGo relies on additional static analysis to calculate distance metrics. According to our experiments, this process incurs considerable overhead, with each PUT requiring at least one hour of analysis time. In contrast, ISC4DGF achieves similar or better results with a much lower computational cost. While static analysis is crucial for AFLGo’s targeting mechanism, it involves a significant time investment. This can become a bottleneck, especially in large-scale or time-sensitive testing scenarios.

In contrast, ISC4DGF leverages a more streamlined process, where the time cost associated with generating and refining prompts is negligible. This efficiency not only reduces the overall testing time but also allows for more iterations and broader exploration within the same timeframe, thereby increasing the likelihood of uncovering vulnerabilities. This comparison highlights how the design of the initial seed corpus can effectively enhance directed fuzzing capabilities, enabling ISC4DGF, which is built on the coverage-guided AFL, to outperform even established directed fuzzers like AFLGo.

Compared to non-directed fuzzers, specifically coverage-guided greybox fuzzers, ISC4DGF demonstrated a clear advantage by detecting 6 additional bugs and achieving an average speed improvement of over 37.05 times. This performance boost underscores the effectiveness of ISC4DGF in generating high-quality initial seeds that guide the fuzzing process more efficiently. While ISC4DGF’s performance may be less pronounced in certain cases, such as Fairfuzz’s PNG003, TIF007, and Entropic’s PNG003 and XML017, it’s important to note that the time to trigger these targets was relatively short (less than 1000 seconds). We consider these results acceptable within the context of randomized fuzzing scenarios. On targets requiring deeper exploration, such as TIF014 and PDF010, ISC4DGF’s performance was notably superior. In these cases, where traditional fuzzers might struggle due to the need for extensive exploration to reach deeply buried code segments, ISC4DGF’s ability leads to better results due to efficiently guide the fuzzing process and focus on critical areas.

Overall, ISC4DGF demonstrated an average performance improvement of 35.63 times compared to existing popular fuzzers on the Magma dataset, detecting 7 additional bugs. Notably, ISC4DGF was the only fuzzer capable of triggering PNG001 within 24 hours, confirming that it not only enhances the efficiency of vulnerability detection but also has the ability to uncover vulnerabilities that other fuzzers might miss.

In fuzz testing, reaching a target does not guarantee that the target vulnerability will be successfully triggered. A fuzzer may reach the target code segment multiple times, but if the input or state does not satisfy the conditions needed to trigger the vulnerability, the issue will remain unexposed. In such cases, while the fuzzer’s path exploration capabilities are validated, its actual efficiency in detecting vulnerabilities may be limited. To address this, we analyzed the number of times different fuzzers reached the designated target before successfully triggering the vulnerability. This analysis allowed us to assess whether ISC4DGF’s initial seed set could trigger target vulnerabilities more quickly with fewer target reaches. If a fuzzer failed to trigger the target vulnerability within the specified time, we recorded the number of times it reached the target after 24 hours of execution. The results of our analysis are summarized in Table 4.

ISC4DGF demonstrated a significant reduction in the number of target reaches needed to trigger vulnerabilities, achieving up to 771.68x fewer target reaches compared to other fuzzers. This efficiency underscores ISC4DGF’s ability to trigger specified targets more quickly and with greater precision, validating its directed detection capabilities. To further understand ISC4DGF’s performance, we conducted an in-depth analysis of three specific experiments where it excelled: PNG003, TIF007, and XML014. In these cases, ISC4DGF managed to trigger the specified targets with fewer than 100 target reaches. Compared to other fuzzers, ISC4DGF reduced the number of target reaches by factors of 2959.4x, 1107.88x, and 23.39x, respectively. This substantial reduction highlights the effectiveness of our initial seed set, which not only guides the fuzzing process more efficiently but also contains the necessary semantic information to trigger the specified vulnerabilities. The ability of ISC4DGF to focus on relevant code paths and quickly achieve the desired outcomes clearly demonstrates its enhanced directed fuzzing capabilities. Additionally, the experiment involving PNG001 provided further insights into ISC4DGF’s effectiveness in challenging scenarios. In this case, ISC4DGF registered a significantly higher number of target reaches compared to other fuzzers because the others were unable to trigger the target vulnerability within the 24-hour testing period. In contrast, ISC4DGF persisted with a substantial number of target reaches and ultimately succeeded in triggering the vulnerability within the limited time.

ISC4DGF is built on the AFL, which is renowned for its ability to enhance vulnerability detection through coverage-guided fuzzing. AFL’s approach emphasizes maximizing code coverage, enabling the fuzzer to extensively explore the PUT, thereby increasing the likelihood of discovering unknown vulnerabilities across the software. However, ISC4DGF diverges from AFL’s philosophy by focusing less on achieving maximum code coverage and more on swiftly triggering specific targets. ISC4DGF is effective in scenarios involving known or suspected vulnerabilities, where quickly reaching the relevant code areas is more critical than exploring the entire codebase. To assess whether ISC4DGF prioritizes targeting over code coverage, we compared the code coverage and the number of target reaches achieved by ISC4DGF and AFL within a 24-hour period. Figure 2 presents our experimental results.

In Figure 2(a), we compared the code coverage achieved by ISC4DGF and AFL across various targets. As expected, ISC4DGF demonstrated lower code coverage compared to AFL, with an average reduction of 12.38%. However, this reduction in coverage is more than offset by ISC4DGF’s performance, as it achieved a 8.12x increase in target reach counts compared to AFL, as shown in Figure 2(b). This result suggests that ISC4DGF effectively concentrates its fuzzing efforts on the most relevant sections of the code, dedicating more resources to exploring these critical areas rather than spreading its efforts across the entire codebase. By prioritizing target hits over broader code coverage, ISC4DGF can trigger vulnerabilities more quickly.

Difficulties in Detecting Hard-to-find Bugs. While ISC4DGF primarily improves the speed of vulnerability detection, it can struggle to identify bugs that other fuzzers might miss. This limitation suggests that ISC4DGF’s enhancements are more focused on efficiency rather than expanding the scope of detected vulnerabilities. The increased speed is a notable advantage, especially in scenarios where time efficiency is critical. However, while ISC4DGF excels in rapidly detecting vulnerabilities, it may not always enhance the discovery of new or previously undetected bugs. Future research should explore combining ISC4DGF’s speed benefits with other techniques that improve the detection of hard-to-find vulnerabilities.

Seed Mutation in Directed Fuzzing. ISC4DGF’s current advancements have primarily focused on optimizing the initial seed corpus, which has enhanced the fuzzer’s directed capabilities, enabling it to target specific vulnerabilities more efficiently from the start. Other steps in the fuzzing process, particularly the seed mutation phase, still rely on traditional techniques that may not fully capitalize on the initial advantages provided by ISC4DGF. Future research could explore integrating LLMs into the seed mutation phase. By leveraging LLMs to generate higher-quality seeds, it may be possible to further enhance the fuzzer’s directed capabilities, leading to more effective vulnerability detection.