Command line argument adaptive directed fuzzing method, device, equipment and medium

Abstract

The application provides a command line parameter adaptive directed fuzzing test method, device, equipment and medium, relates to the software security test technical field, and the method aims at the problems that the existing directed gray box fuzzing test tool is caused by the manual static configuration of the command line parameter in the complex software, the target is unreachable, the coverage efficiency is low, and the expansibility is poor. For the first time, a large language model and a retrieval enhancement generation technology are introduced into the parameter decision link: a function-target point mapping table, a target-execution condition mapping table and a function summary table are constructed through static analysis, the number of targets that can be statically covered by each candidate parameter combination is quantified in units of functions, and a priority queue is formed according to the sorting; in the fuzzing test process, the parameter configuration is dynamically switched according to the real-time target coverage progress, so that long-time stagnation in low-efficiency parameters is avoided; when the queue is exhausted, the feedback and iteration module re-counts the un-covered targets, and a large model is called to generate a new round of high-targeted parameter list combined with the latest execution condition.

Description

Technical Field

[0001] This invention relates to the field of software security testing technology, specifically to a method, apparatus, equipment, and medium for adaptive directional fuzzy testing of command-line parameters. Background Technology

[0002] As software complexity increases, ensuring system security and stability becomes paramount. In the field of software security testing, targeted fuzzing has become a key method for verifying static analysis results, reproducing known vulnerabilities, and evaluating the effectiveness of patches. Its basic idea is to use a given code location in the program as the target, automatically generating input to trigger a specific code path. Typically, these code locations involve known or suspected vulnerabilities, allowing testing to focus on high-risk areas. Using static analysis techniques, these code locations are mapped to a control flow graph, calculating the distance from each node in the control flow graph to the target, and instrumenting this distance into the program's basic blocks. This allows for easy calculation of the distance between the input and the target during dynamic execution. This distance information guides targeted fuzzing, enabling it to gradually generate inputs that trigger vulnerabilities in the target code region. Currently, targeted fuzzing is mainly applied in three scenarios: Static detection report verification: verifying the accuracy and effectiveness of static detection by providing code locations in the static detection report; Vulnerability reproduction: automatically generating inputs close to the known vulnerability's location to trigger and analyze vulnerability behavior under different environments. Patch testing: By using a given patch location as the target, the target area is thoroughly tested to ensure that the patch eliminates the vulnerability without introducing new problems.

[0003] However, most existing technologies focus on path guidance and input mutation, paying insufficient attention to the role of command-line parameters. In many practical software applications, command-line parameters directly determine the program's execution path and the activation mode of functional modules. If the parameters are set improperly, even if the input content itself is highly exploratory, it may still fail to reach the target location. Current mainstream targeted fuzzing tools often rely on manual pre-setting of command-line parameters before testing. This method is effective for programs with simple structures, but for software with numerous options and complex semantics, manual setting is both difficult and error-prone. Once the parameter configuration does not match the target path, the testing process will remain on paths unrelated to the target for a long time, resulting in low testing efficiency or even failure to cover the target code. Existing technologies lack a mechanism to dynamically update parameter configurations based on target coverage during fuzzing, failing to effectively mitigate the impact of manual setting errors, and therefore exhibiting significant limitations in targeted vulnerability verification scenarios for complex programs.

[0004] In existing targeted gray-box fuzzing techniques, a strategy based on input priority management has been proposed to improve testing efficiency on large-scale target sets. Its core mechanism includes: designing a novel multi-distance metric whose accuracy does not decrease with the number of targets, and combining it with a dynamic target ranking mechanism to automatically remove fully explored targets, avoiding resource waste. Simultaneously, it introduces an intelligent queue pruning algorithm that can smoothly switch between exploration and exploitation, thereby efficiently scheduling seed input among thousands of targets and significantly improving coverage efficiency for important targets. Experiments show that in multiple multi-target tests based on memory disinfectant tags, this method exhibits higher coverage than traditional targeted gray-box fuzzing tools and can trigger suspected vulnerabilities marked with disinfectant faster. Furthermore, current innovations address the practical challenges of large-scale target sets by proposing an iterative priority focusing mechanism: dynamically selecting a set of "key targets" for attention by carefully considering the vulnerability patterns and test adequacy of target points. This mechanism supports optimization in exploration-exploitation scheduling, seed selection, and byte scheduling strategies, enabling fuzzing to concentrate resources more effectively and respond quickly to key targets. Experiments have demonstrated that this method triggers vulnerabilities significantly faster in multiple program tests and successfully discovered several new vulnerabilities (including those assigned CVE numbers). CVE (Common Vulnerabilities and Exposures) are security vulnerability entries with standardized numbers from international vulnerability databases, used to standardize and share known vulnerability information. Each CVE entry includes a vulnerability description, affected software versions, and reference links, facilitating vulnerability tracking and management for security researchers, vendors, and users.

[0005] The main innovations of the two aforementioned approaches in the field of directed gray-box fuzzing lie in dynamic target management and input priority scheduling. By improving distance metrics, target elimination strategies, and focused target fine-tuning, they significantly enhance adaptability to complex target sets. However, these techniques still assume static configuration and pre-setting of command-line parameters during testing, failing to guide or dynamically optimize parameter configuration from the perspective of parameter semantics or execution paths. This limitation can lead to test paths failing to cover targets when dealing with complex programs with numerous command-line options and intricate semantics, thus reducing overall efficiency.

[0006] In summary, existing technical solutions rely on manual configuration of command-line parameters: current targeted fuzzing tools require manual specification of command-line parameters before testing. While this is acceptable for simple programs, in complex software with a vast and semantically complex parameter space, researchers find it difficult to set parameters accurately. Incorrect configuration can lead to unreachable targets: if command-line parameters are set improperly, the program execution path may be completely unrelated to the target code, rendering targeted fuzzing ineffective and wasting computational resources. There is a lack of dynamic adaptation mechanisms: most existing methods fix parameter configurations once before testing, lacking a mechanism for dynamic adjustment based on target coverage during testing, making it difficult to cope with complex and changing execution environments. Semantic information cannot be used to optimize parameters: traditional targeted fuzzing is mainly based on control flow distance or path heuristics, ignoring the relationship between command-line parameters and program semantics, and failing to combine the context of the target function for intelligent reasoning. Furthermore, scalability is insufficient: when faced with a large number of target points (such as multiple suspected vulnerability locations), there is a lack of effective parameter scheduling strategies, easily leading to situations where some target points remain unreachable for extended periods.

[0007] In view of the above, this application is hereby submitted. Summary of the Invention

[0008] This invention provides a command-line parameter adaptive directional fuzzy testing method, apparatus, device, and medium, which can at least partially improve the above-mentioned problems.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] An adaptive directional fuzzing method for command-line arguments, comprising:

[0011] S1. Obtain the program to be tested, perform static analysis on the program to be tested, locate all given target points, identify the function code to which they belong, and obtain the function-target mapping table, the target point-execution condition table, and the function-function summary table.

[0012] S2 combines a large language model and RAG technology to generate candidate parameter combinations from the parameter manual, function-target mapping table, target point-execution condition table and function-function summary table, resulting in a priority queue of candidate parameter combinations.

[0013] S3 performs fuzzing preprocessing on the priority queue of candidate parameter combinations, generating a PoC for the target vulnerability;

[0014] S4: After traversing the current list of candidate parameter combinations, calculate the coverage of all target points, filter out those that are still not covered, update the function-target mapping table based on the uncovered cases, and perform a new round of fuzz test iterations based on the updated function-target mapping table until all target points are covered, and obtain the final test results.

[0015] The present invention also provides a command-line parameter adaptive directional fuzzy testing device, which includes:

[0016] The static analysis unit is used to acquire the program to be tested, perform static analysis on the program to be tested, locate all given target points, identify the function code to which they belong, and obtain the function-target mapping table, the target point-execution condition table, and the function-function summary table.

[0017] The parameter combination unit is used to combine the large language model and RAG technology to generate candidate parameter combinations from the parameter manual, function-target mapping table, target point-execution condition table and function-function summary table, and obtain a candidate parameter combination priority queue.

[0018] The fuzzing unit is used for fuzzing preprocessing that dynamically schedules the priority queue of candidate parameter combinations to generate a Proof of Concept (PoC) for the target vulnerability.

[0019] The feedback unit is used to count the coverage of all target points after traversing the current list of candidate parameter combinations, filter out those that are still not covered, update the function-target mapping table according to the coverage situation, and perform a new round of fuzz test iterations based on the updated function-target mapping table until all target points are covered and the final test result is obtained.

[0020] The present invention also provides a command-line parameter adaptive orientation fuzzy testing device, which includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the command-line parameter adaptive orientation fuzzy testing method as described above.

[0021] The present invention also provides a readable storage medium storing a computer program that can be executed by the processor of the device in which the storage medium is located, to implement the command-line parameter adaptive directional fuzzy testing method as described in any of the above.

[0022] In summary, the proposed adaptive directional fuzzing method for command-line arguments revolves around the crucial variable of "command-line arguments," a variable long overlooked in directional fuzzing. It proposes an end-to-end adaptive solution: using the target-function-execution condition triple extracted from static analysis as the "anchor point," it replaces manual experience with large-scale model and knowledge base reasoning, transforming the fuzzy matching of parameter semantics into a quantifiable, sortable, and iterative optimization problem for the first time. Through a queue mechanism prioritizing the method with the most target coverage and a dynamic scheduling strategy of "switching upon timeout," it synchronously incorporates the command-line space and input space into a feedback loop, achieving the co-evolution of parameter configuration and path exploration. In simple terms, the architecture starts with the target and program input. The static analysis module generates a function-target mapping table, a function-function summary table, and a target-execution condition table, driving the operation of the parameter combination generation module. Simultaneously, this module utilizes dynamic selection to generate a priority queue for candidate parameter combinations. The fuzzing and dynamic scheduling modules test based on the input candidate parameters, generating a Proof of Concept (PoC) for the target vulnerability. The feedback and iteration module continuously optimizes the uncovered target set and returns new data to the static analysis module to facilitate further analysis and testing.

[0023] Compared with existing technologies, this method has the following advantages: 1. Introduction of a large model and RAG (Retrieval-Augmented Generation) to generate a candidate parameter list: By obtaining the function of the target point through static analysis and combining a large model with RAG technology, a candidate parameter list is automatically generated, avoiding reliance on human experience and significantly reducing the configuration error rate. 2. Priority sorting mechanism: Candidate parameters are sorted according to the number of targets they can statically cover, so that the testing process prioritizes parameter combinations with larger coverage, thereby improving target coverage efficiency in the early stages. 3. Dynamic parameter update strategy: During fuzz testing, parameter configuration is dynamically switched according to the target coverage progress and time threshold, ensuring that the test always moves towards uncovered targets, effectively alleviating the problem of "long-term stagnation". 4. Target feedback-driven iterative optimization: After all candidate parameters have been traversed, the system will regenerate the target point-function mapping table based on the currently uncovered target points and call the large model to generate a new candidate parameter list, forming a closed loop of continuous optimization. 5. Improve the scalability and robustness of complex software: This method can still automatically schedule parameter configuration in multi-objective and large-scale scenarios, improve the stability and coverage of targeted fuzz testing, and reduce the cost of manual intervention. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the command-line parameter adaptive directional fuzzy testing method provided in the first embodiment of the present invention;

[0025] Figure 2 This is a schematic diagram of the flowchart framework of the command-line parameter adaptive directional fuzzy testing method provided in the embodiment of the present invention;

[0026] Figure 3 This is a schematic diagram of the static analysis module provided in an embodiment of the present invention;

[0027] Figure 4 This is a schematic diagram of the parameter combination generation module provided in an embodiment of the present invention;

[0028] Figure 5 This is a schematic diagram of the fuzz testing and dynamic scheduling module provided in an embodiment of the present invention;

[0029] Figure 6 This is a schematic diagram of the module of the command line parameter adaptive directional fuzzy testing device provided in the second embodiment of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0031] refer to Figure 1 , Figure 2 As shown, the first embodiment of the present invention discloses a command-line parameter adaptive oriented fuzzing method, which can be executed by a command-line parameter adaptive oriented fuzzing testing device (hereinafter referred to as the testing device), specifically, by one or more processors within the testing device, to implement the following method:

[0032] S1. Obtain the program to be tested, perform static analysis on the program to be tested, locate all given target points, identify the function code to which they belong, and obtain the function-target mapping table, the target point-execution condition table, and the function-function summary table.

[0033] Please see Figure 3 Specifically, step S1 further includes: obtaining the program to be tested, constructing a control flow graph within the function based on the program to be tested, and generating the control flow graph;

[0034] Traverse the control flow graph, query the target node to locate all given target points, extract the target points, and map them to obtain a function-target mapping table, wherein the function-target mapping table is used to record the set of target points corresponding to each function;

[0035] Extract the function code from the program to be tested to obtain a function-function code table. Input the function-function code table and the function-target mapping table into a preset large language model to obtain a target point-execution condition table. The target point-execution condition table contains the conditions required to trigger the target point.

[0036] The function-function code table is input into a preset large language model to obtain a function-function summary table, wherein the key of the function-function summary table is the function name containing the target, and the value is the content summary interpretation generated by the large model based on the function code.

[0037] In this embodiment, during the static analysis of the program under test (the static analysis process includes control flow graph (CFG) construction, target point extraction, and function mapping), the program under test is first acquired, and a control flow graph within each function is constructed to generate the control flow graph. Next, the control flow graph is traversed to query target nodes to locate all given target points (e.g., vulnerability points or high-risk lines of code), and these target points are extracted and mapped to obtain a function-target mapping table. This table records the set of target points corresponding to each function, which is used to generate a list of candidate parameter combinations on a function-by-function basis. Subsequently, the function code in the program under test is extracted to obtain a function-function code table. This table and the function-target mapping table are input into a preset large language model to obtain a target point-execution condition table. This table contains the conditions required to trigger the target point, such as parameter types or possible semantic hints (preconditions that should be met in the input). Finally, the function-function code table is input into the pre-defined large language model to obtain a function-function summary table. The key of this table is the function name containing the target, and the value is a summary explanation generated by the large language model based on the function code. This summary guides the large language model in generating a list of candidate parameter combinations that can trigger the function's functionality. Through this series of steps, precise target location and function-level aggregation are achieved, providing foundational data for subsequent generation of candidate parameter combinations at the function level. Simultaneously, it integrates scattered vulnerability points along the function dimension, reducing the number of subsequent large model calls and saving processing costs.

[0038] Among them, CFG (Control Flow Graph) is a commonly used data structure in static program analysis to represent the execution flow of a program. CFG consists of nodes and edges. Nodes represent basic blocks (continuous instruction sequences without jumps), and edges represent possible transition paths in program execution. CFG allows analysis of a program's logical structure, function call relationships, and path coverage, and is a crucial foundation for calculating target distance and path priority in oriented fuzzing.

[0039] S2 combines a large language model and RAG technology to generate candidate parameter combinations from the parameter manual, function-target mapping table, target point-execution condition table and function-function summary table, resulting in a priority queue of candidate parameter combinations.

[0040] Please see Figure 4Specifically, step S2 further includes: based on the function-target mapping table, sorting according to the number of target points that each candidate parameter combination can statically cover, and generating a priority function queue;

[0041] Based on the function queue, a summary of each function in the function queue is obtained through a function summary table mapping;

[0042] The parameter manual is integrated into the knowledge base through vector embedding, and the knowledge base is retrieved using RAG technology to infer and generate the final parameter combination.

[0043] Starting with the highest priority function in the function queue, obtain its function summary. Based on the knowledge base of the program manual, input it into the preset large language model. The large language model combines the summary, the command line manual knowledge base, and the target point-execution condition table to generate command line parameter configuration. Each output item is a candidate parameter combination for the corresponding function, forming a priority sequence of candidate parameter combinations. This sequence is the candidate parameter combination priority queue. The target point-execution condition table is only used during dynamic iteration.

[0044] In this embodiment, after obtaining the function-target mapping table, target point-execution condition table, and function-function summary table during the static analysis phase, the candidate parameter combination generation stage begins. First, functions are sorted according to the number of target points corresponding to each function in the function-target mapping table, forming a function queue with high to low priority. This allows functions that potentially cover more targets to be tried first within the same test time, thereby improving early target reach efficiency. Subsequently, based on this function queue, a summary of each function is obtained through the function-function summary table, providing a concise description of the function's behavior for subsequent candidate parameter combination generation. Simultaneously, the parameter manual is integrated into a knowledge base using vector embedding. RAG technology is used to search the knowledge base, and the search results, function summaries, and command-line manual knowledge base are combined to generate the candidate parameter combination. The large language model inference generates candidate parameter combinations corresponding to functions. In practice, starting with the function with the highest priority in the function queue, its summary information and relevant knowledge from the parameter manual are input into the preset large language model. The large language model outputs the candidate parameter combinations corresponding to the function and processes them sequentially according to the function queue order, ultimately forming a priority sequence of candidate parameter combinations, i.e., the candidate parameter combination priority queue. The target point-execution condition table is only called in subsequent dynamic iterations to introduce more refined conditions for uncovered targets when necessary, avoiding the reduction of the search space due to premature addition of constraints in the initial stage. This achieves automated and ordered generation of complex command line parameter spaces, reduces the workload of manual configuration, and improves the coverage efficiency of targeted fuzz testing.

[0045] The highest priority candidate parameter combination in this sequence covers the most target points, meaning it can reach more targets in a single test. Therefore, prioritizing such combinations can effectively improve testing efficiency. The core of this approach lies in utilizing the function-target point mapping table generated in step S1. Furthermore, candidate parameter combinations are generated on a function-by-function basis because within the same function, most target points can often be covered by similar parameter combinations. Additionally, after traversing the first round of candidate parameter sequences, the target coverage of each function can be obtained. For functions that have partially covered targets, the uncovered targets require more information to overcome constraints and reach them. Therefore, during dynamic iteration, the target-execution condition mapping table obtained in step S1 is used to further assist in generating more effective candidate parameter combinations.

[0046] RAG (Retrieval-Augmented Generation) is a technical framework that combines information retrieval with generative models. Its core idea is to first retrieve content related to the user's question from an external knowledge base or document collection, and then combine these retrieval results with a generative model to assist in answer generation.

[0047] S3 performs fuzzing preprocessing on the priority queue of candidate parameter combinations, generating a PoC for the target vulnerability;

[0048] Please see Figure 5 Specifically, step S3 further includes: selecting the highest-ranked candidate parameter combination as the current configuration based on the candidate parameter combination priority queue, starting fuzz testing, and recording the latest time of covering the new target;

[0049] When it is determined that the time of the latest coverage of the new target exceeds the set value, a PoC of the target vulnerability is generated, and the process is switched to the next candidate parameter combination for fuzz testing.

[0050] If it is determined that the time to cover the new target has not exceeded the set value, further path exploration and input mutation will be carried out;

[0051] Repeat the above steps until the candidate parameter list has been traversed.

[0052] In this embodiment, the dynamic scheduling fuzzing phase begins: First, the highest-priority candidate parameter combination is retrieved according to the queue order as the current configuration to start the fuzzing test, and the time of the latest coverage of the new target is continuously recorded during the test. When it is determined that the time of the latest coverage of the new target exceeds a preset threshold, the system considers that the current parameter combination's ability to further cover the target has weakened. At this time, a PoC for the target vulnerability is generated, and the system switches to the next candidate parameter combination in the queue to restart the fuzzing test. When it is determined that the time of the latest coverage of the new target has not exceeded the set value, the system continues to maintain the current parameter configuration and further conducts path exploration and input mutation in order to continue to discover new target coverage under the existing parameter environment. By repeating the above judgment and processing process until the candidate parameter combination list is completely traversed, the dynamic scheduling of parameter combinations and the reasonable allocation of test resources are realized, avoiding the test process from staying on inefficient parameter configurations for a long time, and improving the efficiency and target coverage of targeted fuzzing.

[0053] Among them, PoC (Proof of Concept) is used to represent an instance that can verify the existence of a vulnerability. For example, for a vulnerability in a PDF reader, a PDF file that triggers the vulnerability is a proof of concept for that vulnerability.

[0054] S4: After traversing the current list of candidate parameter combinations, calculate the coverage of all target points, filter out those that are still not covered, update the function-target mapping table based on the uncovered cases, and perform a new round of fuzz test iterations based on the updated function-target mapping table until all target points are covered, and obtain the final test results.

[0055] Specifically, step S4 further includes: after traversing the current candidate parameter combination list, calculating the coverage of all target points, filtering out those that are still not covered, and feeding back to the static analysis module to update the function-target mapping table, retaining only the information of the target points that have not yet been covered;

[0056] The function priority is updated based on the updated function-target mapping table, and the large language model is called again to generate a new list of candidate parameters;

[0057] When it is determined that a function already contains a covered target point, in this round of generation, a more targeted combination of candidate parameters will be generated based on the original target point-execution condition table.

[0058] A new round of fuzz testing iterations is performed on the newly obtained candidate parameter combinations to form a closed-loop structure until all target points are covered, and the final test results are obtained.

[0059] In this embodiment, all recorded hit targets are compared item by item with the initial target list to filter out residual targets that have not yet been reached. These residual entries are written back to the static analysis module, thereby compressing the function-target mapping table into a new version that "only contains uncovered targets." This avoids redundant attempts on covered points in the next round and allows subsequent inference to focus directly on the most difficult-to-reach code segments. Based on this updated mapping table, function priorities are recalculated. If a covered target point has appeared within a function, the original target point-execution condition table is retrieved, and the fine-grained conditions required for the "remaining targets" are fed into the large language model. This allows the model to fine-tune the on / off combinations of constraints that have not yet been met when generating new candidate parameters, rather than simply repeating configurations that have been proven ineffective in the previous round. If all targets within a function are uncovered, the original summary and condition inputs are maintained to ensure the breadth of exploration of new regions. A new batch of candidate parameter combinations is generated and sent back to the dynamic scheduling engine, initiating another round of fuzzing. This forms a closed-loop structure of "static analysis → parameter generation → fuzzing → feedback → iterative regeneration," continuously improving the efficiency of exploring uncovered targets. This iteration continues until the statistics module finds that the target list has zero remaining, at which point the loop terminates, the data generated in each round is summarized, and the final test results are output. Through this backtracking-refinement mechanism, deep paths missed in the early stages due to coarse-grained parameters are gradually filled in, while avoiding wasting computational resources in covered areas, significantly improving the completeness and automation of complex multi-target scenarios. The design intent is that for uncovered target points, which are usually more difficult to reach, finer-grained information is needed to guide the generation, thereby improving the effectiveness of parameter combinations.

[0060] In summary, based on these steps, the command-line parameter adaptive directional fuzzing method has significant advantages in automating and dynamically configuring command-line parameters. It can significantly improve the target coverage and execution efficiency of directional fuzzing, reducing the uncertainty and inefficiency caused by manual intervention. It effectively solves the problem of existing directional fuzzing methods relying on manual settings and prone to configuration errors during command-line parameter configuration. Specifically, this method reduces manual dependence and lowers the configuration error rate. It extracts the function and execution conditions of the target point through static analysis and uses a large model and RAG technology to generate a candidate parameter list, replacing the traditional method of relying entirely on manual experience to set parameters. This avoids the problem of some targets being unreachable due to inaccurate manual settings, thereby improving test coverage. Secondly, it improves fuzzing efficiency. During the fuzzing phase, parameter configuration is dynamically switched according to the target point coverage. For example, when a parameter reaches the expected coverage threshold after running for a period of time, or when no new targets are found for a long time, the system automatically switches to the next candidate parameter. This mechanism avoids fuzzing from being stuck on inefficient parameter configurations for a long time, thereby improving the overall fuzzing efficiency. Finally, the system ensures continuous exploration of uncovered targets. After the candidate parameter list is exhausted, the uncovered target points are re-counted, a new function-target point mapping table is generated, and the large model is called again to generate a new candidate parameter list. This iterative mechanism ensures that fuzzing can continuously explore uncovered targets, significantly improving the adaptability and completeness of orientation testing for complex programs.

[0061] Please see Figure 6 As shown, a second embodiment of the present invention provides a command-line parameter adaptive directional fuzzy testing device, which includes:

[0062] Static analysis unit 101 is used to acquire the program to be tested, perform static analysis on the program to be tested, locate all given target points, identify the function code to which they belong, and obtain a function-target mapping table, a target point-execution condition table, and a function-function summary table.

[0063] The parameter combination unit 102 is used to combine the large language model and RAG technology to perform candidate parameter combination generation processing on the parameter manual, function-target mapping table, target point-execution condition table and function-function summary table to obtain a candidate parameter combination priority queue.

[0064] Fuzzing unit 103 is used for fuzzing preprocessing to dynamically schedule the priority queue of candidate parameter combinations, and to generate a PoC for the target vulnerability.

[0065] Feedback unit 104 is used to count the coverage of all target points after traversing the current candidate parameter combination list, filter out those that are still not covered, update the function-target mapping table according to the coverage, and perform a new round of fuzz test iteration based on the updated function-target mapping table until all target points are covered and the final test result is obtained.

[0066] A third embodiment of the present invention provides a command-line parameter adaptive orientation fuzzy testing device, which includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the command-line parameter adaptive orientation fuzzy testing method as described above.

[0067] A fourth embodiment of the present invention provides a readable storage medium storing a computer program that can be executed by the processor of the device in which the storage medium is located, to implement the command-line parameter adaptive directional fuzzy testing method as described in any of the above embodiments.

[0068] For example, the various devices and process steps described above can be implemented by a computer program, which can be divided into one or more units, which are stored in the memory and executed by the processor to complete the present invention.

[0069] The processor referred to can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor, a general-purpose processor, or any conventional processor.

[0070] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the present invention by running or executing the computer programs and / or modules stored in the memory and by calling the data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0071] If the unit integrated into the electronic device or printer is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0072] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0073] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A command line argument adaptive directed fuzz testing method, characterized in that, The method comprises the following steps: S1, obtaining a program to be tested, performing static analysis on the program to be tested, locating all given target points, identifying the function code to which the target points belong, obtaining a function-target mapping table, a target point-execution condition table, and a function-function summary table; S2, combining a large language model and RAG technology to perform candidate parameter combination generation processing on the parameter manual, the function-target mapping table, the target point-execution condition table, and the function-function summary table, and obtaining a candidate parameter combination priority queue; S3, performing fuzzy test preprocessing on the candidate parameter combination priority queue to generate a PoC of a target vulnerability; S4, after traversing the current candidate parameter combination list, counting the coverage of all target points, screening out those that have not been covered, updating the function-target mapping table according to the un-covered situation, and performing a new round of fuzzy test iteration based on the updated function-target mapping table until all target points are covered, and obtaining the final test result; The step S2 specifically comprises: Based on the function-target mapping table, the number of target points that can be statically covered by each candidate parameter combination is sorted to generate a function queue with priority; Based on the function queue, the summary of each function in the function queue is obtained through the function summary table mapping; Integrate the parameter manual into the knowledge base through vector embedding, and use RAG technology to search the knowledge base to generate the final parameter combination; Starting from the function with the highest priority in the function queue, obtaining the summary of the function, inputting into the preset large language model based on the knowledge base of the program manual, and the large language model generates command line parameter configuration combining the summary, command line manual knowledge base and target point-execution condition table, and each output is a candidate parameter combination of the corresponding function, forming a candidate parameter combination sequence with priority, which is the candidate parameter combination priority queue, wherein the target point-execution condition table is only used in the dynamic iteration process.

2. The command-line argument adaptive directed fuzz testing method of claim 1, wherein, The step S1 specifically comprises: Obtaining a program to be tested, constructing a function internal control flow graph based on the program to be tested, and generating a control flow graph; Traversing the control flow graph, querying the target node, locating all given target points, and extracting the target points to obtain a function-target mapping table, wherein the function-target mapping table is used to record the target point set corresponding to each function; Extracting the function code in the program to be tested to obtain a function-function code table, inputting the function-function code table and the function-target mapping table into the preset large language model, and mapping to obtain a target point-execution condition table, wherein the target point-execution condition table contains the conditions required to trigger the target point; Inputting the function-function code table into the preset large language model to obtain a function-function summary table, wherein the key of the function-function summary table is the function name containing the target, and the value is the content summary explanation generated by the large model according to the function code.

3. The command-line argument adaptive directed fuzz testing method of claim 1, wherein, The step S3 specifically comprises: According to the candidate parameter combination priority queue, the highest ranked candidate parameter combination is selected as the current configuration, the fuzzy test is started, and the time when the new target is newly covered is recorded. When it is judged that the time of the latest coverage of the new target exceeds the set value, a PoC of the target vulnerability is generated, and the next candidate parameter combination is switched to for fuzz testing; When it is judged that the time of the latest coverage of the new target does not exceed the set value, path exploration and input variation are further performed; The above steps are repeated until the candidate parameter list is traversed.

4. The command-line argument adaptive directed fuzz testing method of claim 1, wherein, The step S4 is specifically: After traversing the current candidate parameter combination list, the coverage of all target points is counted, the still uncovered ones are screened out, and are fed back to the static analysis module to update the function-target mapping table, and only the information of the target points that have not been covered is kept; According to the updated function-target mapping table, the function priority is updated, and the large language model is called again to generate a new candidate parameter list; When it is judged that the target point covered is included in a function, the original target point-execution condition table is further used to generate a more targeted candidate parameter combination in the generation process of this round; A new round of fuzz testing iteration is performed on the newly obtained candidate parameter combination to form a closed loop structure until all target points are covered, and the final test result is obtained.

5. A command line argument adaptive directed fuzz testing apparatus, comprising: A command line parameter adaptive directed fuzz testing method as claimed in any one of claims 1 to 4 is implemented, comprising: A static analysis unit is configured to obtain a program to be tested, perform static analysis on the program to be tested, locate all given target points, identify the function code to which the target points belong, and obtain a function-target mapping table, a target point-execution condition table, and a function-function summary table; A parameter combination unit is configured to combine a large language model and RAG technology to generate candidate parameter combinations from a parameter manual, a function-target mapping table, a target point-execution condition table, and a function-function summary table, and obtain a candidate parameter combination priority queue; A fuzz testing unit is configured to perform dynamic scheduling fuzz testing preprocessing on the candidate parameter combination priority queue to generate a PoC of a target vulnerability; A feedback unit is configured to count the coverage of all target points after traversing the current candidate parameter combination list, screen out the still uncovered ones, update the function-target mapping table according to the uncovered condition, and perform a new round of fuzz testing iteration based on the updated function-target mapping table until all target points are covered to obtain the final test result.

6. A command line argument adaptive directed fuzzing test equipment, characterized in that, A processor, a memory, and a computer program stored in the memory and configured to be executed by the processor are included, and the processor implements the command line parameter adaptive directed fuzz testing method as claimed in any one of claims 1 to 4 when executing the computer program.

7. A readable storage medium, characterized by, A computer program is stored, and the computer program can be executed by a processor of a device in which the storage medium is located to implement the command line parameter adaptive directed fuzz testing method as claimed in any one of claims 1 to 4.

Images