Library fuzzy collaborative testing method and system based on static analysis and large language model
By combining static analysis with a large language model, a highly matched driver and initial seed are generated, solving the problems of driver-seed separation and illusion in existing library fuzzing, and achieving efficient vulnerability discovery and a low false positive rate.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG UNIV
- Filing Date
- 2026-04-13
- Publication Date
- 2026-07-10
AI Technical Summary
Existing library fuzzing methods lack coordination in generating drivers and initial seeds, resulting in generated seeds failing parameter checks or internal logic verification of the target function, failing to trigger deep code paths, and large language models being prone to illusions without precise context guidance, leading to high false positive rates and low coverage.
Metadata is extracted through static analysis and cross-file function call graphs are constructed to generate sliced code. A driver program is generated by combining a large language model and iterative self-healing is performed. Input parameter types and path constraints are identified, a highly matching initial seed is generated, and fuzz testing is conducted to identify potential vulnerabilities.
It significantly improves the accuracy and efficiency of fuzz testing, reduces the false positive rate, can discover vulnerabilities hidden behind complex logic, and improves code coverage and vulnerability discovery capabilities.
Smart Images
Figure CN122365510A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software security and automated testing technology, and particularly relates to a library fuzzy collaborative testing method and system based on static analysis and large language models. Background Technology
[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.
[0003] As software supply chains become increasingly complex, libraries have become core building blocks of modern software systems, making their security paramount. A vulnerability in one library can impact numerous downstream applications, posing widespread security risks. Fuzzing, as a highly efficient automated vulnerability discovery technique, has been widely applied to the security testing of software libraries. Unlike fuzzing for standalone applications, library fuzzing requires generating two crucial initial input components for a specific target function: a driver and an initial seed. The driver is responsible for correctly invoking the target function and passing the input data, while the initial seed serves as the starting point for the fuzzing engine to mutate the input, directly affecting the depth of test path coverage and vulnerability discovery capabilities.
[0004] Currently, various methods have attempted to automate the generation of the aforementioned input components. However, most methods treat driver generation and initial seed generation as two independent, uninterrupted tasks. When generating the seed, the system often does not consider the specific context or data flow constraints of the objective function set in the driver. Due to this lack of coordination, the generated seed often fails the parameter checks or internal logic verifications of the objective function, leading to rejection by the target program in the initial stage of fuzzing. While existing LLM-assisted seed generation methods can generate inputs that conform to the specified format, their lack of understanding of the objective function's path constraints makes it difficult for the generated seed to trigger deep code paths, thus failing to discover vulnerabilities hidden behind complex logic. Summary of the Invention
[0005] To address at least one of the technical problems mentioned above, this invention provides a library fuzzy collaborative testing method and system based on static analysis and large language models, which significantly improves the accuracy and efficiency of software library fuzzy testing.
[0006] To achieve the above objectives, the present invention adopts the following technical solution: The first aspect of this invention provides a library fuzzy collaborative testing method based on static analysis and a large language model, comprising the following steps: Static analysis is performed on the target software library to extract the library's metadata information, construct a cross-file function call graph, and perform code slicing on the target functions in the library to generate sliced code for constructing the call context and forward sliced code for extracting data flow constraints. Based on the extracted metadata and code slices, a prompt word containing the calling context is constructed, and an initial template for the driver is generated using a large language model. The validity of the driver is verified by compilation. If the compilation fails, the large language model is used in conjunction with the compilation error information to perform iterative self-repair until a compilable driver is generated. Based on the forward slice code of the objective function and the generated driver information, the input parameter types and path constraints are identified; a large language model is used to generate script code for constructing seeds, and the script code is executed to generate an initial seed corpus; the validity of the generated seeds is verified, and cooperative seeds that can trigger the normal operation of the driver are selected. The generated drivers and co-prototype seeds are continuously fuzzed, and crash information is monitored and collected to identify potential security vulnerabilities.
[0007] Furthermore, the static analysis of the target software library includes: Traverse the source code files of the target software library, extract the metadata and complete definition source code of the functions, and obtain the compilation commands required to compile the software library; Extract document information from the target software library, segment and vectorize it, and construct a knowledge vector library for retrieval enhancement generation; Based on function symbols and call relationships, a cross-file directed function call graph is constructed for the entire library to support cross-file slicing; Code slicing is performed on the target function in the library, including target function slicing and forward data flow slicing.
[0008] Furthermore, when constructing the sliced code for the target function, the program is sliced using intermediate representations, with functions in the library as the target, including: Determine the entry point of the target function based on the function call graph; Starting from the entry point, trace all dependencies that affect the call to the target function based on data flow analysis; The extracted IR slices are mapped back to source code snippets, and the necessary header files are added to generate slice code that preserves the calling semantics.
[0009] Furthermore, the specific steps for forward data stream slicing are as follows: Starting from the call point of the target function, perform forward slicing across files for the function parameters, trace the data flow of the parameters inside the function and in its sub-calls, and extract the code snippets involving branch judgment and data usage as forward slice code.
[0010] Furthermore, the driver initial template generation process includes using prompt word engineering techniques to embed the definition of the objective function, the sliced code, and the retrieved relevant document knowledge into the prompt word template, instructing the large language model to use thought chain reasoning to complete the missing logic in the sliced code and generate the driver initial template.
[0011] Furthermore, the iterative self-correction process utilizing a large language model combined with compilation error information includes: If compilation fails, the compiler error message is extracted, and it is input into the large language model's repair agent along with the original code and repair strategy prompts. The repaired code is then generated and the compilation is attempted again until the compilation succeeds or the preset retry limit is reached.
[0012] A second aspect of the present invention provides a library fuzzy collaborative testing system based on static analysis and a large language model, comprising: The static information extraction module is used to perform static analysis on the target software library, extract the library's metadata information, construct a cross-file function call graph, and perform code slicing on the target functions in the library to generate sliced code for constructing the call context and forward sliced code for extracting data flow constraints. The driver generation module is used to construct prompt words containing the calling context based on the extracted metadata information and sliced code, and generate an initial driver template using a large language model; the validity of the driver is verified by compilation, and if the compilation fails, the large language model is used in combination with the compilation error information to perform iterative self-repair until a compilable driver is generated; The collaborative seed generation module is used to identify input parameter types and path constraints based on the forward slice code of the objective function and the generated driver information; it uses a large language model to generate script code for constructing seeds, executes the script code to generate an initial seed corpus; and it verifies the validity of the generated seeds and selects collaborative seeds that can trigger the normal operation of the driver. The fuzzing module is used to continuously fuzz the generated drivers and co-seeds, monitor and collect crash information to identify potential security vulnerabilities.
[0013] A third aspect of the present invention provides a computer-readable storage medium.
[0014] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the library fuzzy collaborative testing method based on static analysis and large language models as described above.
[0015] A fourth aspect of the present invention provides a computer device.
[0016] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps in the library fuzzy collaborative testing method based on static analysis and large language models as described above.
[0017] A fifth aspect of the present invention provides a program product, which is a computer program product comprising a computer program that, when executed by a processor, implements the steps in the library fuzzy collaborative testing method based on static analysis and large language models as described above.
[0018] Compared with the prior art, the beneficial effects of the present invention are: This invention abandons the traditional model of independent driver and seed generation, treating seed generation as a downstream task of driver generation. By sharing the static analysis context, the generated seeds are highly matched with the driver program in format and logic, avoiding the "early rejection" phenomenon caused by input mismatch and improving the effectiveness of fuzz testing. Simultaneously, this invention utilizes precisely sliced code extracted from static analysis as context input to the model. This "static analysis-guided" approach provides the model with a realistic code basis, effectively reducing illusion problems such as function misuse and parameter errors, and lowering the false positive rate of generated code.
[0019] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0020] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.
[0021] Figure 1 This is a flowchart of the library fuzzy collaborative testing method based on static analysis and large language model provided in the embodiments of the present invention; Figure 2 This is a detailed flowchart of the static information extraction and analysis steps provided in the embodiments of the present invention; Figure 3 This is a detailed flowchart of the driver generation and self-repair steps provided in the embodiments of the present invention; Figure 4 This is a detailed flowchart of the collaborative seed generation and verification steps provided in the embodiments of the present invention; Figure 5 This is an architecture diagram of a library fuzzy collaborative testing system based on static analysis and a large language model, provided in an embodiment of the present invention. Detailed Implementation
[0022] The present invention will be further described below with reference to the accompanying drawings and embodiments.
[0023] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.
[0024] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.
[0025] Although there are some input generation methods for library fuzzing, existing technologies still face many serious challenges in practical applications, mainly in the following aspects: (1) Limitations of traditional methods: low efficiency and path explosion. Early automated driver generation tools mainly synthesized drivers by analyzing existing consumer code or API dependencies. However, these methods mainly focus on the public API interfaces of libraries and often fail to cover deep functions within the libraries, resulting in limited test coverage. In terms of seed generation, although traditional symbolic execution techniques can generate high-quality input, they face problems such as path explosion and complex constraint solving, making them difficult to apply to large-scale and complex libraries. Methods based on machine learning and deep learning rely on large sample sets, but effective input samples for specific library functions are often difficult to obtain.
[0026] (2) The "illusion" and unavailability of existing Large Language Model (LLM) methods: In recent years, Large Language Models (LLMs) have been introduced into library fuzzing due to their powerful code generation capabilities. However, LLMs are prone to "illusions" when lacking precise contextual guidance. Specifically, the generated driver may call non-existent functions, use incorrect parameter types, or omit necessary resource initialization and release steps. This deviation in understanding function behavior not only leads to driver compilation failures but also generates a large number of false positives during fuzzing, meaning that the crash is caused by logical errors in the driver itself rather than library vulnerabilities.
[0027] (3) The separation of driver generation and seed generation processes (lack of coordination): This is one of the most significant drawbacks of existing technologies. Most current methods treat driver generation and initial seed generation as two independent, non-interfering tasks, which leads to some shortcomings in the fuzzing process: a) Lack of constraints: When generating seeds, the system often does not consider the data flow constraints of the specific context or objective function set in the driver.
[0028] b) Early rejection: Due to a lack of coordination, the generated seeds often fail to pass the parameter checks or internal logic verification of the objective function, resulting in rejection by the target program in the initial stage of fuzzing.
[0029] c) Shallow exploration: Although existing LLM-assisted seed generation methods can generate inputs that conform to the format, due to a lack of understanding of the target function path constraints, the generated seeds are difficult to trigger deep code paths, resulting in the inability to discover vulnerabilities hidden behind complex logic.
[0030] (4) Lack of full-function-level coverage support: Existing library fuzzing input generation methods mainly focus on the API level, limiting the number of testable functions. For a large number of non-API functions within the library, due to the lack of public calling documentation or examples, existing tools often cannot generate effective drivers, making these functions test blind spots. Although some works have attempted to perform full-function fuzzing, they rely on iterative compilation error fixing to infer variable constraints, which is inefficient and difficult to guarantee accuracy.
[0031] In summary, existing library fuzzing techniques suffer from significant shortcomings in accuracy (high false positive rate), coverage (difficulty in covering internal functions and deep paths), and synergy (driver and seed mismatch). Therefore, there is an urgent need for a technical solution that can deeply integrate the precision of static program analysis with the generation capabilities of large language models, and collaboratively generate highly matched driver programs and initial seeds to address these issues and improve the coverage and detection effectiveness of software library fuzzing.
[0032] This invention combines static program slicing technology with the generation capabilities of large language models to automatically and collaboratively generate high-quality fuzz test drivers (Harness) and initial seeds that are highly adapted to the drivers. This solves the problems of driver and seed separation, low code coverage, and the tendency of large language models to produce illusions in existing technologies, and significantly improves the efficiency of software library fuzz testing and vulnerability discovery capabilities.
[0033] Example 1 like Figure 1 As shown, this embodiment provides a library fuzzy collaborative testing method based on static analysis and a large language model, including the following steps: Step 1: Static Information Extraction and Analysis: Perform static analysis on the target software library, extract the library's metadata information, construct a cross-file function call graph, and perform code slicing on the target functions in the library to generate sliced code for constructing the call context and forward sliced code for extracting data flow constraints.
[0034] This step aims to extract precise function call patterns and data flow information from the target library, providing semantic guidance for the subsequent generation of a Large Language Model (LLM). For example... Figure 2 As shown, the specific steps include the following: Step 101: Traverse the source code files of the target software library, extract the metadata and complete definition source code of the functions, and obtain the compilation commands required to compile the software library; In this embodiment, code analysis tools can be used to extract function metadata, which includes function symbols, function signatures, parameter lists, and the path to the source file to which it belongs. Collect the compilation commands (such as compiler flags and link library dependencies) required to compile the library for subsequent building of the executable environment.
[0035] Step 102: Extract the document information of the target software library, perform segmentation and vectorization processing, and construct a knowledge vector library for retrieval enhancement generation; In this embodiment, the document information of the target software library is segmented by type and converted into vector representation using an embedding model, which is then stored in a vector database to construct a knowledge base for retrieving augmented generation (RAG).
[0036] Step 103: Based on function symbols and call relationships, construct a cross-file directed function call graph for the entire library to support cross-file slicing; In this embodiment, the directed function call graph of the entire library represents functions as nodes and call relationships as edges. This graph is used to support program slicing across files, ensuring the integrity of the slices.
[0037] Step 104: Perform code slicing on the target function in the library, including target function slicing and forward data flow slicing; Specifically, target function slicing: For each target function in the library, slicing is performed at the intermediate representation (IR) level using the compiler front-end (such as Clang / LLVM), specifically including: First, determine the entry point of the target function based on the function call graph; Then, starting from the entry point, all dependencies affecting the target function call are traced based on data flow analysis, including variable definitions, assignments, computation logic, and parameter passing operations.
[0038] Finally, the extracted IR slices are mapped back to the source code fragments, and the necessary header files are added to generate "slice code" that preserves the calling semantics.
[0039] Specifically, the steps for forward data stream slicing are as follows: To guide seed generation, starting from the call point of the target function, a forward slice is performed across files based on the function's input parameters. This traces the data flow of parameters within the function and its sub-calling functions, extracting code snippets involving branching decisions (such as if conditions and switch statements) and data usage to generate "forward slice code." This code reveals the constraints required to trigger deep paths.
[0040] This invention breaks away from the limitations of traditional methods that only focus on the API level, supporting testing of functions within a library through full function slicing. Furthermore, by introducing forward data flow slicing to guide seed generation, the initial seed can satisfy complex path constraints within functions, allowing for the exploration of deep code logic in the early stages of fuzzing, significantly improving code coverage and vulnerability discovery capabilities.
[0041] Step 2: Based on the extracted metadata information and sliced code, construct prompt words containing the calling context, and use the large language model to generate the initial template of the driver; verify the validity of the driver by compilation. If the compilation fails, use the large language model in combination with the compilation error information to perform iterative self-repair until a compilable driver is generated. This step utilizes the precise context provided by static analysis to eliminate the illusion of an LLM and introduces a self-healing mechanism to ensure the generated driver is executable. For example... Figure 3 As shown, it specifically includes: Step 201: Based on the extracted metadata information and slice code, construct a prompt word that includes the calling context; In this embodiment, the constructed prompt words include: Character setting: LLM is set as a fuzz testing expert.
[0042] Task Instructions: Based on the provided code slices, complete the missing logic to generate a complete and compilable C / C++ driver program.
[0043] Contextual input: the definition of the embedded objective function, the slice code generated in step 1, and relevant document information retrieved from the knowledge base via RAG.
[0044] Mind chain guidance: Instruct the model to think step by step, first identify the required variables and initialization conditions, then call the target function, and finally release resources.
[0045] Step 202: Input the constructed prompt words into the large language model to generate the initial template for the driver program; In this embodiment, the definition of the target function, the extracted slice code, and the relevant document knowledge retrieved through RAG are embedded into a preset prompt word template using prompt word engineering technology. The large language model is instructed to use thought chain reasoning to complete the missing logic in the slice code and generate driver code containing complete resource initialization, function calls, and resource release. Step 203: Verify the validity of the driver by compiling. If the compilation fails, use the large language model combined with the compilation error information to perform iterative self-repair until a compilable driver is generated. In this embodiment, if compilation fails, the compiler error message is extracted and input into the large language model's repair agent along with the original code and repair strategy prompts. The repaired code is then generated and compilation is attempted again until compilation succeeds or the preset maximum number of retries is reached.
[0046] Specific repair strategies include: adjusting header file reference order, removing duplicate definitions, adding missing library links, and correcting undefined symbols. The "repair-compile" process is repeated until compilation succeeds or the preset retry limit is reached. If it ultimately fails, the driver is discarded and the next loop begins.
[0047] This invention introduces a self-healing mechanism based on compilation feedback, which can automatically correct syntax and linking errors in LLM-generated code and generate a compileable and executable test environment without manual intervention, significantly reducing the manpower costs for security researchers.
[0048] Step 3: Based on the forward slice code of the objective function and the generated driver information, identify the input parameter types and path constraints; use the large language model to generate script code for constructing seeds, execute the script code to generate the initial seed corpus; verify the validity of the generated seeds, and select the cooperative seeds that can trigger the normal operation of the driver. This step treats seed generation as a downstream collaborative task of the driver, ensuring a high degree of matching between the seed and the driver program. For example... Figure 4 As shown, the specific steps include the following: Step 301: Analyze the types of input parameters required by the driver and classify them into ordinary data types or complex data types; In this embodiment, common data types include integer (int), floating-point (float), character (char), and boolean.
[0049] Complex data types, such as JSON, XML, image formats (JPEG, PNG), PDF, and structures, typically require specific library functions for construction.
[0050] Step 302: Construct seed generation prompts to indicate the data flow path constraints within the large language model analysis function, and generate a Python script that can construct input data that satisfies the constraints; The construction in this embodiment includes prompts for driver code, target function definition, and the forward slice code; The driver code provides the interface context that the seed needs to satisfy; the target function definition and forward slice code provide the data flow path constraint code inside the function. Specifically, it instructs the data flow path constraints within the large language model analysis function to generate a Python script capable of constructing input data that satisfies the constraints, including: The LLM program is instructed to write a Python script. This script should, based on the parameter types, call the appropriate Python library (such as a json library, struct library, or image processing library) to construct input data that satisfies the above constraints and write the data to a file. The LLM program executes this prompt to obtain the seed generation script (Python code).
[0051] Step 303: Execute the Python script to write the generated input data to a file as a candidate seed; Step 304: Run the candidate seeds using the generated driver, and keep the seeds that enable the driver to run normally and exit without errors as cooperative seeds; Specifically, each candidate seed is run using the generated driver, and the program's exit status is monitored. If the program runs normally and exits without errors, the seed is marked as a valid seed and added to the initial seed corpus; if it causes the driver to crash (not the target library to crash) or reports an error, the seed is removed. If all seeds are invalid, the task is either regenerated or discarded.
[0052] The method of this invention does not depend on a specific library structure or predefined configuration, and can be widely applied to various C / C++ open source libraries. Furthermore, seed generation is implemented through intermediate scripts (Python), which can flexibly support the input construction of various complex data structures.
[0053] Step 4: Perform continuous fuzz testing on the generated driver and co-seed, monitor and collect crash information to identify potential security vulnerabilities; Based on the method proposed in this invention, evaluations were conducted on a benchmark set containing known vulnerabilities. Results show that the driver and seed generated by this invention work together to achieve significantly better vulnerability coverage than existing fuzzing tools. Furthermore, thanks to the precise guidance of static analysis, the method of this invention has the lowest false positive rate. In tests against real-world open-source libraries, this invention discovered 33 previously unknown vulnerabilities, including stack overflow, integer overflow, double-free, and null pointer reference vulnerabilities. Of these, 26 have been confirmed and fixed by developers and have received 8 CNVD numbers, demonstrating the effectiveness and practical value of this invention in actual vulnerability discovery.
[0054] Example 2 like Figure 5 As shown, this embodiment provides a library fuzzy collaborative testing system based on static analysis and a large language model, including: The static information extraction module is used to perform static analysis on the target software library, extract the library's metadata information, construct a cross-file function call graph, and perform code slicing on the target functions in the library to generate sliced code for constructing the call context and forward sliced code for extracting data flow constraints. The driver generation module is used to construct prompt words containing the calling context based on the extracted metadata information and sliced code, and generate an initial driver template using a large language model; the validity of the driver is verified by compilation, and if the compilation fails, the large language model is used in combination with the compilation error information to perform iterative self-repair until a compilable driver is generated; The collaborative seed generation module is used to identify input parameter types and path constraints based on the forward slice code of the objective function and the generated driver information; it uses a large language model to generate script code for constructing seeds, executes the script code to generate an initial seed corpus; and it verifies the validity of the generated seeds and selects collaborative seeds that can trigger the normal operation of the driver. The fuzzing module is used to continuously fuzz the generated drivers and co-seeds, monitor and collect crash information to identify potential security vulnerabilities.
[0055] It should be noted that the specific implementation of the library fuzzy collaborative testing system based on static analysis and large language model in this embodiment of the invention is similar to the specific implementation of the library fuzzy collaborative testing method based on static analysis and large language model in this embodiment of the invention. For details, please refer to the description in the method section. To reduce redundancy, it will not be repeated here.
[0056] Example 3 This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the library fuzzy collaborative testing method based on static analysis and large language models as described above.
[0057] Example 4 This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the library fuzzy collaborative testing method based on static analysis and large language model as described above.
[0058] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.
[0059] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0060] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0061] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0062] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.
[0063] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A library fuzzy collaborative testing method based on static analysis and large language models, characterized in that, Includes the following steps: Static analysis is performed on the target software library to extract the library's metadata information, construct a cross-file function call graph, and perform code slicing on the target functions in the library to generate sliced code for constructing the call context and forward sliced code for extracting data flow constraints. Based on the extracted metadata information and sliced code, prompt words containing the calling context are constructed, and the initial template of the driver is generated using a large language model; The validity of the driver is verified by compilation. If the compilation fails, the large language model is used in combination with the compilation error information to perform iterative self-repair until a compilable driver is generated. Based on the forward slice code of the objective function and the generated driver information, the input parameter types and path constraints are identified; a large language model is used to generate script code for constructing seeds, and the script code is executed to generate an initial seed corpus; the validity of the generated seeds is verified, and cooperative seeds that can trigger the normal operation of the driver are selected. The generated drivers and co-prototype seeds are continuously fuzzed, and crash information is monitored and collected to identify potential security vulnerabilities.
2. The library fuzzy collaborative testing method based on static analysis and large language model as described in claim 1, characterized in that, The static analysis of the target software library includes: Traverse the source code files of the target software library, extract the metadata and complete definition source code of the functions, and obtain the compilation commands required to compile the software library; Extract document information from the target software library, segment and vectorize it, and construct a knowledge vector library for retrieval enhancement generation; Based on function symbols and call relationships, a cross-file directed function call graph is constructed for the entire library to support cross-file slicing; Code slicing is performed on the target function in the library, including target function slicing and forward data flow slicing.
3. The library fuzzy collaborative testing method based on static analysis and large language model as described in claim 1, characterized in that, When constructing the sliced code for the target function, the function in the library is used as the target, and the program is sliced using an intermediate representation, including: Determine the entry point of the target function based on the function call graph; Starting from the entry point, trace all dependencies that affect the call to the target function based on data flow analysis; The extracted IR slices are mapped back to source code snippets, and the necessary header files are added to generate slice code that preserves the calling semantics.
4. The library fuzzy collaborative testing method based on static analysis and large language model as described in claim 1, characterized in that, The specific steps for forward data stream slicing are as follows: Starting from the call point of the target function, perform forward slicing across files for the function parameters, trace the data flow of the parameters inside the function and in its sub-calls, and extract the code snippets involving branch judgment and data usage as forward slice code.
5. The library fuzzy collaborative testing method based on static analysis and large language model as described in claim 1, characterized in that, The driver initial template generation process includes using prompt word engineering techniques to embed the definition of the target function, the sliced code, and relevant document knowledge retrieved into the prompt word template, instructing the large language model to use thought chain reasoning to complete the missing logic in the sliced code and generate the driver initial template.
6. The library fuzzy collaborative testing method based on static analysis and large language model as described in claim 1, characterized in that, The process of iterative self-correction using a large language model combined with compilation error information includes: If compilation fails, the compiler error message is extracted, and it is input into the large language model's repair agent along with the original code and repair strategy prompts. The repaired code is then generated and the compilation is attempted again until the compilation succeeds or the preset retry limit is reached.
7. A library fuzzy collaborative testing system based on static analysis and large language models, characterized in that, include: The static information extraction module is used to perform static analysis on the target software library, extract the library's metadata information, construct a cross-file function call graph, and perform code slicing on the target functions in the library to generate sliced code for constructing the call context and forward sliced code for extracting data flow constraints. The driver generation module is used to construct prompt words containing the calling context based on the extracted metadata information and sliced code, and to generate the initial template of the driver using a large language model; The validity of the driver is verified by compilation. If the compilation fails, the large language model is used in combination with the compilation error information to perform iterative self-repair until a compilable driver is generated. The collaborative seed generation module is used to identify input parameter types and path constraints based on the forward slice code of the objective function and the generated driver information; it uses a large language model to generate script code for constructing seeds, executes the script code to generate an initial seed corpus; and it verifies the validity of the generated seeds and selects collaborative seeds that can trigger the normal operation of the driver. The fuzzing module is used to continuously fuzz the generated drivers and co-seeds, monitor and collect crash information to identify potential security vulnerabilities.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps in the library fuzzy collaborative testing method based on static analysis and large language model as described in any one of claims 1-6.
9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the library fuzzy collaborative testing method based on static analysis and large language model as described in any one of claims 1-6.
10. A program product, said program product being a computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps in the library fuzzy collaborative testing method based on static analysis and large language model as described in any one of claims 1-6.