Parallelized fuzzing method and system based on target point task division
By adopting a parallel fuzzing method based on target point task partitioning, the task conflict problem in parallel fuzzing is solved, enabling more comprehensive software vulnerability detection and resource optimization, and improving detection efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HANGZHOU DIANZI UNIV
- Filing Date
- 2021-12-27
- Publication Date
- 2026-07-21
AI Technical Summary
Parallelized fuzz testing suffers from task conflicts, including testing being limited to a specific part of the software and the generation of duplicate test cases, leading to a waste of test resources.
The parallel fuzzing method based on target point task partitioning obtains software vulnerability points through static analysis, constructs a target point set, and partitions tasks according to the basic block distance and function call relationship graph, so that each fuzzing instance has a different seed queue and resolves task conflicts.
It improves the efficiency of software vulnerability detection, ensures that each fuzz test instance covers different code areas, reduces redundant testing, and improves the efficiency of computing resource utilization and system flexibility.
Smart Images
Figure CN114328213B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software automated security testing technology, and relates to a parallelized fuzzy testing method and system based on target point task partitioning. Background Technology
[0002] Software security testing is crucial for ensuring software quality. To improve the efficiency of software security testing, parallel fuzzing methods can be used. However, this technique suffers from task conflict, primarily due to two reasons: 1. Because the seed selection strategies of various instances are similar, testing will target similar code sections, limiting the testing to a specific part of the software. 2. Multiple instances using the same seed mutation strategy to mutate seeds in similar seed queues will generate many duplicate test cases, wasting testing resources.
[0003] To address the task conflict problem in parallelized fuzzing, existing solutions mainly fall into two categories: seed selection strategy diversification and seed mutation strategy diversification.
[0004] 1. Resolving Task Conflicts Through Diversified Seed Selection Strategies. The core idea of the PAFL framework is to statically and equally divide the bitmap and allocate it to various fuzzing instances. Each instance tests the corresponding part of the software based on its assigned bitmap portion, resolving task conflicts in the parallel fuzzing process through differences in seed selection strategies. This method specifically addresses the task conflict issues encountered by the AFLfast and Fairfuzz fuzzing frameworks during parallelization. However, the equal bitmap partitioning method may lead to uneven task allocation. CN113590281A proposes a distributed parallel fuzzing method and system based on dynamic centralized scheduling. In this method, seeds generated by each fuzzing instance are centrally managed, constructing a global seed queue. Seeds are prioritized based on their depth, the number of fuzzing rounds, and the number of mutations (for specific implementation, refer to AFL's `calculate_score()` function). Then, the master node uses a request-allocation approach, retrieving the highest-priority seed from the global seed queue for each fuzzing instance requesting a seed. This allows each fuzzing instance to mutate and test different seeds, achieving diversity in seed selection strategies. This method can effectively solve the task conflict problem in the parallel fuzzing process and has good universality. However, it requires additional computing resources for seed evaluation and management, and the frequent information interaction between the master node and the fuzzing instance will affect the overall testing efficiency.
[0005] 2. Resolving Task Conflicts Through Seed Mutation Strategy Diversification. CN110147310A proposes a parallel fuzzing scheduling method and apparatus based on mutation strategies. In this method, the mutation strategy set in the fuzzer AFL is statically allocated (see the `fuzz_one()` function of AFL for details), assigning different mutation strategies to different parallel test instances. This diversifies the seed mutation strategies among instances, thereby reducing the generation of duplicate test cases and partially resolving the task conflict problem. Although this method reduces the generation of a large number of duplicate test cases through seed mutation strategy diversification, the similarity of seed selection strategies among instances still leads to the locality problem in software testing.
[0006] In summary, to address the task conflict problem in parallel fuzzing, this invention proposes a parallel fuzzing method based on target point task partitioning, using the directional fuzzing framework aflgo as a foundation. The method determines the target point to which a seed belongs based on the basic block information it can cover during testing, generating different seed queues for different fuzzing instances to partition tasks. This allows each instance to test different parts of the software, resolving task conflict issues and improving overall software vulnerability detection efficiency. Summary of the Invention
[0007] One objective of this invention is to address the aforementioned problems by proposing a parallelized fuzzing method based on target point task partitioning. The fuzz tester in this invention is developed based on the AFLGO framework, and a target point-based task partitioning method is added to AFLGO's parallelization model to resolve the task conflict problem that previously existed during parallelization.
[0008] First, a static analysis program is used to identify potential vulnerabilities in the software. These vulnerabilities are then used as a set of target points and inserted into the software. After compilation, the function call graph and control flow graph of the software are obtained. Any line of code is represented as a basic block, and the distance from all basic block code in the software to each target point is calculated. Then, the basic blocks are classified according to their distance information, with each basic block belonging to a target point.
[0009] Before parallel fuzzing begins, each fuzzing instance is assigned a set of sub-target points. During testing, the seed is assigned to a target point based on the basic block information it can cover, meaning the fuzzing instance corresponding to that target point mutates it. If a vulnerability is discovered, the master node analyzes the error stack information to determine if the vulnerability was caused by code at a specific target point. If so, that target point is marked as complete, and the corresponding computing resources are redirected to testing other incomplete target points.
[0010] The above method mainly includes four stages: static code analysis stage, instrumentation compilation stage, parallel fuzzing stage, and target vulnerability judgment stage.
[0011] The static code analysis phase specifically involves using the code defect static analysis tool cppcheck to detect code blocks with memory leaks, mismatched memory allocation and release, and buffer overflow issues, and then constructing a target point set.
[0012] The instrumentation compilation stage specifically includes the following steps:
[0013] 2-1. Instrumentation compilation builds function call relationship diagrams (CG diagram) and control flow diagrams (CFGs diagram); using aflgo's existing instrumentation compilation scripts, the target point set information obtained in the static analysis phase is injected into the program through instrumentation during the compilation process; generating CG and CFG diagrams for the next step of assigning basic blocks and calculating their distances;
[0014] 2-2. Calculate the basic block affiliation and its distance: Based on the CG map and CFGs map, calculate the distance from each basic block in the software to each target point. If the distance from a basic block to target point A is less than the distance to other target points, then the basic block belongs to target point A. Then, write the name of each basic block, its affiliated target point information, and the basic block distance information into the distance.cfg.txt file.
[0015] 2-3. Instrumentation and compilation to generate executable file: Read the information in the distance.cfg.txt file, insert this information during software recompilation, generate executable file, so that when the software runs and triggers the basic block, it can obtain the target point information to which it belongs.
[0016] The parallel fuzz testing phase specifically includes the following steps:
[0017] 3-1. Read the target point task set: Each fuzzing instance reads the target point file corresponding to its instance name in the specified directory, which records the target point information that each instance is responsible for testing; when the target point file corresponding to a fuzzing instance is empty, the test ends; a fuzzing instance refers to the fuzzing process after the fuzzer is started.
[0018] 3-2. Seed Selection: When selecting seeds, the fuzz test instance will determine whether the seed belongs to the target point it is responsible for based on some basic block information covered during the seed test. If so, it will be added to the seed queue for mutation testing; otherwise, it will not be added.
[0019] 3-3. Mutation Test: Each fuzz test instance will perform mutation tests on the seeds in its respective seed queue in turn. After a round of testing is completed, if a vulnerability is found during the testing process, proceed to step 3-4; otherwise, proceed to step 3-1.
[0020] 3-4. Vulnerability Storage: If a vulnerability is discovered during testing, it is stored in the crashes directory as a vulnerability file, and the master node automatically performs the target vulnerability assessment; return to step 3-1.
[0021] The target vulnerability assessment phase specifically includes the following steps:
[0022] 4-1. Vulnerability Collection: The master node will periodically check the crashes directory of each fuzz test. If a new vulnerable file is found, proceed to step 4-2. Otherwise, it will sleep for SL seconds (SL is the set value) and then perform vulnerability collection again.
[0023] 4-2. Vulnerability Information Generation: The master node will reproduce the vulnerability based on the collected vulnerability files and generate the error stack information corresponding to the vulnerability using the asan framework;
[0024] 4-3. Vulnerability and target point information comparison: Compare the error stack information of the vulnerability with the location information of each target point to determine whether the vulnerability exists in the code of a certain target point. If so, go to step 4-4; otherwise, return to step 4-1.
[0025] 4-4. Update the target point set and perform node resource scheduling; remove the target points that have been confirmed to have vulnerabilities from the entire target point set. If the entire target point set is empty, the test ends; otherwise, reallocate the target points to each instance, update the target point file corresponding to each fuzz test instance, and return to step 4-1.
[0026] Furthermore, the specific process of step 2-2 is as follows:
[0027] 1) Based on the CFGs graph, calculate the distance between any basic block bb and each function call point in this function, denoted by dis_block[i], where i represents the function call point, i = 1, 2...n, and n is the total number of function call points;
[0028] 2) Based on the CG graph, calculate the distance between each function call point and each target point function, denoted by dis_func[i][j], where j represents the target point function, j = 1, 2...m, and m is the total number of target point functions. Then, based on dis_func[i][j], solve for the shortest distance between each function call point, denoted by dis_min_func[i], and the corresponding target point information is represented by block_to_target[i].
[0029] 3) Based on the distance between basic blocks and the shortest function distance, the basic block distance dis of bb can be calculated. The calculation formula is: dis = Min(dis_block[i] + α * dis_min_func[i]); and the target point to which bb belongs is denoted as target, target = block_to_target[ii], where ii is the function call point from which dis is solved;
[0030] 4) Write the basic information bbinfo of each calculated basic block into the distance.cfg.txt file. The basic information bbinfo includes the name of the basic block, the information of the target point to which it belongs, and the distance information of the basic block.
[0031] Furthermore, step 3-2 is described in detail below:
[0032] 1) First, iterate through the basic block information in basicInfoAll, read the target and dis, and increment 1 at the target position in the targetNum queue to indicate that the current basic block belongs to the target. The targetNum queue records the number of basic blocks owned by each target point. Then, add the dis value of the basic block to the target position in the targetDis queue. The targetDis queue is used to record the total distance of the basic blocks owned by each target point.
[0033] 2) Select the target point with the most basic blocks from the targetNum queue. If multiple target points have the same number of basic blocks, select the target point with the smallest sum of distances to the basic blocks from the targetNum queue. This target point is the target point to which the seed belongs, denoted as seedtarget.
[0034] 3) If seedtarget is responsible for the set of sub-target points t in this instance c If the mutation is detected, it will be added to the seed queue of this instance for mutation testing; otherwise, it will not be added.
[0035] Furthermore, the specific process of step 4-3 is as follows: obtain the location information of the line of code that indicates the existence of the vulnerability in the error stack information, compare it with the location information of each target point in the target point set, and if the information comparison is successful, it can be proved that there is a vulnerability at a certain target point.
[0036] Furthermore, the specific process of step 4-4 is as follows: the master node removes the target points that have been confirmed to have vulnerabilities from the entire target point set T. If the entire target point set T is empty, the test ends; otherwise, based on the task load balancing principle, the target points in T are reassigned to each instance, and then the target point files corresponding to each fuzzing instance are updated by save().
[0037] Another objective of this invention is to provide a parallelized fuzzing system based on target point task partitioning, including a static analysis module, an instrumentation compilation module, a parallelized fuzzing module, and a target point vulnerability judgment module;
[0038] The static analysis module uses the open-source cppcheck static analysis tool to perform static analysis on the software, find all possible locations of vulnerabilities in the software, and generate a set of target points based on the locations of potential vulnerabilities.
[0039] The instrumentation compilation module is used to instrument and compile the software under test. It improves upon the aflgo compilation script, generating CG and CFG diagrams through instrumentation compilation. Then, it calculates the distance from each basic block in the software to each target point, selects the closest target point as the assigned target point of the basic block, and records this information in the distance.cfg.txt file.
[0040] The parallel fuzzing module is used to perform parallel fuzzing tests on the software under test. Each fuzzing instance reads target point information from its corresponding target point file, then selects seeds, and only performs mutation tests on seeds belonging to the target points it is responsible for, thereby resolving task conflicts between fuzzing instances.
[0041] The target vulnerability assessment module is used to determine whether a vulnerability exists in the target code. It uses the asan framework to generate error stack information corresponding to the vulnerability, then compares the vulnerability's error stack information with the location information of each target point to determine if the vulnerability exists in the code of that target point. If so, the target point is marked as complete, and computing resources are allocated to test other target points of the software.
[0042] This invention employs a parallel fuzzing method based on target point task partitioning. Seeds are automatically partitioned according to their associated target points, so that each fuzzing instance has a different seed queue. This solves the task conflict problem in the parallel fuzzing process and can effectively improve the overall testing efficiency.
[0043] Compared to the existing PAFL parallel fuzzing framework, the parallel fuzzing method based on target point task partitioning proposed in this invention provides a more granular task partitioning specifically for the aflgo parallel model. This results in a more detailed and balanced task allocation for each fuzzing instance, better resolving task conflicts during execution. Furthermore, the target point vulnerability assessment mechanism proposed in this invention addresses the problem inherent in aflgo where, after discovering a vulnerability, it couldn't determine whether the vulnerability was located at the target point code, leading to a situation where exploration of the target point couldn't be stopped even after completion. Now, through the target point vulnerability assessment mechanism, the computing node resources corresponding to the already explored target point region can be released, allowing it to explore other target point regions, thereby improving system flexibility and computing resource utilization efficiency. Therefore, this invention can improve the overall testing efficiency of the aflgo parallel model.
[0044] Using the method of this invention, the efficiency of software vulnerability detection can be improved. Within the same testing time, the code in the software can be explored more comprehensively, and more software vulnerabilities can be discovered. Attached Figure Description
[0045] Figure 1 This is an overall flowchart of the present invention;
[0046] Figure 2 for Figure 1 Flowchart of the interpolation compilation stage.
[0047] Figure 3 for Figure 2 Flowchart of basic block ownership and distance calculation.
[0048] Figure 4 for Figure 1 Flowchart of the parallel fuzzing testing phase.
[0049] Figure 5 for Figure 1 Flowchart of the target vulnerability assessment phase. Detailed Implementation
[0050] The technical solutions of the present invention will now be fully described with reference to the accompanying drawings in the embodiments of the present invention.
[0051] like Figure 1As shown, the parallel fuzzing method based on target point task partitioning consists of four stages: static code analysis, instrumentation and compilation, parallel fuzzing, and target point vulnerability assessment.
[0052] The static code analysis phase specifically involves using a static code defect checking tool like cppcheck to perform static analysis on the software, detecting code blocks that may have issues such as memory leaks, mismatched memory allocation and deallocation, and buffer overflows, and constructing a target point set. This target point set (the set of code lines that may have the above-mentioned problems) is represented by a basic block (filename, line number) where each target point (any line of code) is represented.
[0053] Instrumentation during the compilation phase, such as Figure 2 As shown, it includes the following steps:
[0054] 2-1. Instrumentation Compilation to Build Function Call Graphs and Control Flow Graphs: Utilizing AFLGO's existing instrumentation compilation scripts, the target point set information obtained during the static code analysis phase is injected into the program through instrumentation during the compilation process. This generates a function call graph (CG) and a control flow graph (CFGs), which respectively describe the call relationships between various functions in the software and the relationships between basic blocks within each function. These are used for the next step of assigning basic blocks and calculating their distances.
[0055] 2-2. Calculate the basic block ownership and its distance:
[0056] The method for calculating the affiliation of a basic block (bb) and its distances is described using a basic block (bb) in the software: First, based on the CFGs graph, calculate the inter-block distance from the basic block (bb) to each function call point within the function, denoted by dis_block[i], where i represents the function call point, i = 1, 2...n (n is the total number of function call points). Second, based on the CG graph, calculate the inter-function distance from each function call point to each target function, denoted by dis_func[i][j], where j represents the target function, j = 1, 2...m (m is the total number of target functions). Then, based on dis_func[i][j], solve for the shortest inter-function distance between each function call point, denoted by dis_min_func[i], while the corresponding target point information is represented by block_to_target[i]. Finally, based on the inter-block distances and the shortest inter-function distances, calculate the basic block distance (dis) of the basic block (bb), using the formula: dis = Min(dis_block[i] + α * dis_min_func[i]). The target point to which bb belongs is denoted as target, target = block_to_target[ii], where ii is the function call point for solving dis.
[0057] Once the target point information and distance of each basic block have been calculated, the basic information bbinfo(bb, target, dis) of these basic blocks is written into the distance.cfg.txt file.
[0058] The target point function is the function containing the target point.
[0059] The pseudocode for basic block ownership and distance calculation is as follows:
[0060]
[0061]
[0062] like Figure 3 As shown, in this embodiment, a basic block `basicA` in the software is used to describe the allocation of the basic block and the calculation method of its distance: First, based on the CFGs graph, the distance between basic block `basicA` and each function call point in the current function `Mian` is calculated. The distance between basic block `basicA` and function call point `F1()` is 1 (calculated by subtracting row numbers), while the distance to function call point `F2()` is 3. Second, based on the CG graph, the shortest inter-function distance from each function call point to each target point function is calculated, such as... Figure 1 As shown, the interval between function call point F1() and target point function 1 is 1, therefore the inter-function distance is 1. There is no path to target point function 2, therefore the inter-function distance is infinite. Thus, the shortest inter-function distance for function call point F1() is 1, corresponding to target point function 1. The shortest inter-function distance for function call point F2() can be calculated in this way. Finally, based on the basic block distance and the shortest inter-function distance, the basic block distance is calculated using the formula: Min(basic block distance i + α * shortest inter-function distance i), (i = 1, 2...n, where n is the number of function call points). Therefore, the basic block distance of basicA is 11, belonging to target point 1.
[0063] 2-3 Instrumentation and compilation to generate executable file: When re-instrumenting and compiling the software, the information in the distance.cfg.txt file is read and instrumented into the software to generate an executable file, so that when the software runs and triggers the basic block, it can obtain the target point information target and distance information dis to which it belongs.
[0064] Parallelizing the fuzzing phase, such as Figure 4 As shown, the specific steps include:
[0065] Assume the parallelism of the parallelized fuzzing is N, and there are a total of N parallel fuzzing instances, named S. k(k = 1, 2... N). Assume the set of target points is T, and the target points in T are divided into N equal parts, denoted as t for each sub-target point set. c (c = 1, 2...N).
[0066] 3-1. Read the target point task set: The target points in the target point set T will be divided into N sub-target point sets according to the principle of average distribution, and assigned to each fuzzy test instance. The sub-target point set information t will be transferred to the target point set. c Store the corresponding sub-target point files in the / tasks / XXX directory. The sub-target point file name is equal to the fuzz test instance name, i.e., S. k (k = 1, 2... N).
[0067] Before each round of fuzz testing begins, each fuzz test instance S... k Each instance will read the target point file corresponding to its instance name in the / tasks / XXX directory, which records the set of sub-target points t that each instance is responsible for testing. c Information. The test ends when the target point file corresponding to a fuzz test instance is empty.
[0068] The fuzz test instance refers to the fuzz test process after the fuzz tester is started.
[0069] 3-2. Seed Selection: When selecting a seed, the fuzzy testing instance uses the basic information set `basicInfoAll` of the basic blocks covered during the seed test to determine whether the seed belongs to the target point it is responsible for. The method is as follows: based on the basic information of all the basic blocks covered by the seed, select the target point with the most basic blocks. If multiple target points have the same number of basic blocks, select the target point with the smallest sum of distances between their respective basic blocks. This determines which target point the seed belongs to. If the target point to which the seed belongs is within this instance S... k The set of sub-target points t under their responsibility c If the mutation is detected, it will be added to the seed queue of this instance for mutation testing; otherwise, it will not be added.
[0070] In this embodiment, the basic block information in `basicInfoAll` is traversed first. The `target` and `dis` values are read, and a 1 is incremented at the `target` position in the `targetNum` queue, indicating that the current basic block belongs to `target`. The `targetNum` queue records the number of basic blocks owned by each target point. The `dis` value of the basic block is added to the `target` position in the `targetDis` queue, which records the total sum of distances between the basic blocks owned by each target point. Next, the target point with the most basic blocks is selected from the `targetNum` queue. If multiple target points have the same number of basic blocks, the target point with the smallest sum of distances between its owned basic blocks is selected from the `targetNum` queue. This target point is the seed target point, denoted as `seedtarget`. If `seedtarget` is responsible for the set of sub-target points `t` in this instance... c If a seed is selected, it is added to the seed queue of this instance for mutation testing; otherwise, it is not added. The pseudocode for the seed selection process is as follows:
[0071]
[0072] 3-3. Mutation Testing: Each fuzzing instance performs mutation testing on the seeds in its respective seed queue in turn. The energy allocation during the seed mutation process depends on the number of basic blocks in the basic blocks covered by the seed that belong to the same target point as the seed, and the sum of the distances between these basic blocks. After a round of testing is completed, if a vulnerability is found during the testing process, proceed to step 3-4; otherwise, proceed to step 3-1.
[0073] 3-4. Vulnerability Storage: If a vulnerability is discovered during testing, it is stored in the crashes directory of this instance as a vulnerability file. The master node automatically determines the vulnerability at the target point. Afterward, return to step 3-1.
[0074] In the target vulnerability assessment phase, such as Figure 5 As shown, the specific steps include:
[0075] 4-1. Vulnerability Gathering: The master node will periodically check the crashes directory of each fuzzing instance. If a new vulnerable file is found, proceed to step 4-2. Otherwise, it will sleep for SL seconds (SL is an empirical value, with a default value of 60) and then perform vulnerability gathering again.
[0076] 4-2. Vulnerability Information Generation: The master node will reproduce the vulnerability based on the collected vulnerability files. With the help of the asan framework, it can generate the error stack information corresponding to the vulnerability.
[0077] 4-3. Vulnerability and Target Information Comparison: Obtain the location of the line of code in the error stack information that indicates the existence of the vulnerability, and compare it with the target point set t. c The location information of each target point is compared. If the information is successfully compared, it can be proven that there is a vulnerability at a certain target point. The target point is stored in the completeTargetList set of completed exploration target points and the process is moved to step 4-4. Otherwise, the process is moved back to step 4-1.
[0078] 4-4. Update the target point set and perform node resource scheduling: The master node removes the target points for which vulnerabilities have been confirmed from the entire target point set T. If the entire target point set T is empty, the test ends; otherwise, based on the task load balancing principle, the target points in T are reassigned to each instance, and then the target point files corresponding to each fuzzing instance are updated using save(), returning to step 4-1. The pseudocode for this process is as follows:
[0079]
[0080] In summary, this invention presents a parallelized fuzzing method based on target point task partitioning. It determines seed ownership based on the basic block information covered by the seed, ensuring different fuzzing instances have different seed queues responsible for testing different regions of the code in the program. This resolves the task conflict problem inherent in AFLGO parallelized fuzzing. Furthermore, by incorporating a target point vulnerability assessment mechanism, it improves the flexibility and computational resource utilization efficiency of the AFLGO parallelized fuzzing system. Therefore, this invention can enhance the overall testing efficiency of the AFLGO parallelized model.
[0081] To verify the effectiveness of the method of this invention, experiments were conducted. Two control groups were used: the unoptimized native aflgo framework (aflgo-old) and the aflgo framework improved based on the PAFL method (aflgo-pafl). The experimental group used the method of this invention to optimize the native aflgo framework (aflgo-new). The parallelism of both the control and experimental groups was 4. The experimental test set used two testing software programs integrated into the LAVA-M and UNIFUZZ platforms, as well as the open-source software libxml2. To ensure the accuracy of the experimental data, each experiment was repeated three times, and the results were averaged. The final experimental data results are shown in the table below.
[0082]
[0083] / *The improvement ratio (1:3) refers to the performance improvement of aflgo-new compared to aflgo-old, and the improvement ratio (2:3) refers to the performance improvement of aflgo-new compared to aflgo-pafl.* /
[0084]
[0085]
[0086] The experimental data shows that, although there are some differences in performance due to the characteristics of various testing software, overall, the method of this invention improves the overall performance compared to the native AFLGO framework and the AFLGO framework improved based on the PAFL method. Therefore, the method of this invention can effectively solve the task conflict problem of AFLGO in parallel mode and improve the efficiency of software vulnerability detection.
[0087] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. All equivalent changes and modifications made within the scope of the present invention are within the scope of protection of the present invention.
Claims
1. A parallelized fuzz testing method based on target point task partitioning, characterized in that: It includes four stages: static code analysis, instrumentation and compilation, parallel fuzzing, and target vulnerability identification. First, the static analysis program is used to identify potential vulnerabilities in the software and then instrument them into the software as a set of target vulnerabilities. After compilation, the function call graph and control flow graph of the software are obtained. Any line of code is represented as a basic block. The distance from all basic block code in the software to each target point is calculated. Then, the basic blocks are classified according to their distance information, and each basic block belongs to a target point. Before the parallel fuzzing starts, each fuzzing instance is assigned a set of sub-target points. During the test, the target point to which the seed belongs is determined based on the basic block information that the seed can cover during the test. That is, the fuzzing instance corresponding to the target point mutates it. If a vulnerability is found, the master node analyzes the error stack information corresponding to the vulnerability to determine whether the vulnerability is caused by the code at a certain target point. If so, the target point is marked as completed, and the corresponding computing resources are transferred to test other uncompleted target points. The instrumentation compilation stage specifically includes the following steps: 2-1. Instrumentation compilation constructs function call relationship graph (CG) and control flow graph (CFGs); using the existing instrumentation compilation script of aflgo, the target point set information obtained in the static analysis stage is injected into the program through instrumentation during the compilation process; generating CG and CFGs graphs for the next step of assigning basic blocks and calculating their distances; 2-2. Calculate the basic block affiliation and its distance: Based on the CG map and CFGs map, calculate the distance from each basic block in the software to each target point. If the distance from a basic block to target point A is less than the distance to other target points, then the basic block belongs to target point A. Then, write the name of each basic block, its affiliated target point information, and the basic block distance information into the distance.cfg.txt file. The specific process of step 2-2 is as follows: 1) Based on the CFGs graph, calculate the distance between any basic block bb and each function call point in the function containing the basic block, denoted by dis_block[i], where i represents the function call point, i = 1,2...n, and n is the total number of function call points; 2) Based on the CG graph, calculate the distance between each function call point and each target function, denoted by dis_func[i][j], where j represents the target function, j = 1, 2...m, and m is the total number of target functions. Then, based on dis_func[i][j], solve for the shortest distance between each function call point, denoted by dis_min_func[i], and the corresponding target point information is represented by block_to_target[i]. 3) Based on the distance between basic blocks and the distance between the shortest functions, calculate the basic block distance dis of bb. The calculation formula is: dis = Min(dis_block[i] + α) dis_min_func[i]); and the target point to which bb belongs is denoted as target, target = block_to_target[ii], where ii is the function call point for solving dis; 4) Write the basic information bbinfo of each calculated basic block into the distance.cfg.txt file. The basic information bbinfo includes the name of the basic block, the information of the target point to which it belongs, and the distance information of the basic block. 2-3. Instrumentation compilation to generate executable file: Read the information in the distance.cfg.txt file, insert this information during software recompilation, generate executable file, so that when the software runs and triggers the basic block, it can obtain the target point information target and distance information dis to which it belongs; The parallel fuzz testing phase specifically includes the following steps: 3-1. Read the target point task set: Each fuzzing instance reads the target point file corresponding to its instance name in the specified directory, which records the target point information that each instance is responsible for testing; when the target point file corresponding to a fuzzing instance is empty, the test ends; a fuzzing instance refers to the fuzzing process after the fuzzer is started. 3-2. Seed Selection: When selecting seeds, the fuzz test instance will determine whether the seed belongs to the target point it is responsible for based on some basic block information covered during the seed test. If so, it will be added to the seed queue for mutation testing; otherwise, it will not be added. The specific process of step 3-2 is as follows: 1) First, iterate through the basic information of the basic blocks covered during the seed test run in the basicInfoAll set, read the target point information target and distance information dis, increment 1 at the target position in the targetNum queue, indicating that the current basic block belongs to the target. The targetNum queue records the number of basic blocks owned by each target point. Add the dis value of the basic block to the target position in the targetDis queue. The targetDis queue is used to record the total sum of distances of the basic blocks owned by each target point. 2) Select the target point with the most basic blocks from the targetNum queue. If multiple target points have the same number of basic blocks, select the target point with the smallest sum of distances to the basic blocks from the targetNum queue. This target point is the target point to which the seed belongs, denoted as seedtarget. 3) If seedtarget is in the set t of the sub-target points it is responsible for c If the mutation is detected, it is added to the seed queue for mutation testing; otherwise, it is not added. 3-3. Mutation Test: Each fuzz test instance will perform mutation tests on the seeds in its respective seed queue in turn. After a round of testing is completed, if a vulnerability is found during the testing process, proceed to step 3-4; otherwise, proceed to step 3-1. 3-4. Vulnerability Storage: If a vulnerability is discovered during testing, it is stored in the crashes directory as a vulnerability file, and the master node automatically performs the target vulnerability assessment; return to step 3-1.
2. The parallelized fuzz testing method based on target point task partitioning as described in claim 1, characterized in that: The static code analysis phase specifically involves using the code defect static analysis tool cppcheck to detect code blocks with memory leaks, mismatched memory allocation and release, and buffer overflow issues, and then constructing a target point set.
3. The parallelized fuzz testing method based on target point task partitioning as described in claim 1, characterized in that: The target vulnerability assessment phase specifically includes the following steps: 4-1. Vulnerability Collection: The master node will periodically check the crashes directory of each fuzz test. If a new vulnerable file is found, proceed to step 4-2. Otherwise, it will sleep for SL seconds (SL is a set value) and then perform vulnerability collection again. 4-2. Vulnerability Information Generation: The master node will reproduce the vulnerability based on the collected vulnerability files and generate the corresponding error stack information using the asan framework; 4-3. Vulnerability and target point information comparison: Compare the error stack information of the vulnerability with the location information of each target point to determine whether the vulnerability exists in the code of a certain target point. If so, go to step 4-4; otherwise, return to step 4-1. 4-4. Update the target point set and perform node resource scheduling; remove the target points that have been confirmed to have vulnerabilities from the entire target point set. If the entire target point set is empty, the test ends; otherwise, reallocate the target points to each instance, update the target point file corresponding to each fuzz test instance, and return to step 4-1.
4. The parallelized fuzz testing method based on target point task partitioning as described in claim 3, characterized in that: The specific process of step 4-3 is as follows: obtain the location information of the line of code that indicates the existence of the vulnerability in the error stack information, compare it with the location information of each target point in the target point set, and if the information comparison is successful, it proves that there is a vulnerability at the corresponding target point.
5. The parallelized fuzz testing method based on target point task partitioning as described in claim 3, characterized in that: The specific process of step 4-4 is as follows: The master node removes the target points that have been confirmed to have vulnerabilities from the entire target point set T. If the entire target point set T is empty, the test ends; otherwise, based on the task load balancing principle, the target points in T are reassigned to each instance, and then the target point files corresponding to each fuzz test instance are updated by save().
6. A parallelized fuzz testing system based on target point task partitioning, used to execute the method as described in any one of claims 1 to 5, characterized in that: It includes a static analysis module, an instrumentation compilation module, a parallelized fuzzing module, and a target point vulnerability assessment module; The static analysis module uses the open-source cppcheck static analysis tool to perform static analysis on the software, find all possible locations of vulnerabilities in the software, and generate a set of target points based on the locations of potential vulnerabilities. The instrumentation compilation module is used to instrument the software under test. It is based on the AFLGO compilation script and is improved to generate function call relationship diagrams and control flow diagrams through instrumentation compilation. Then, it calculates the distance from each basic block in the software to each target point, selects the target point with the closest distance as the target point of the basic block, and records it in the distance.cfg.txt file. The parallel fuzzing module is used to perform parallel fuzzing tests on the software under test. Each fuzzing instance reads target point information from its corresponding target point file, selects a seed, and performs mutation tests on the seed belonging to the target point it is responsible for. The target vulnerability assessment module is used to determine whether a vulnerability exists in the target code. It generates error stack information corresponding to the vulnerability using the asan framework, and then compares the error stack information of the vulnerability with the location information of each target point to determine whether the vulnerability exists in the code of a certain target point. If so, the target point is marked as completed, and computing resources are allocated to test other target points of the software.