A fuzz testing device and method based on thread-concurrent binary relation coverage

Abstract

This invention relates to a fuzzing device and method based on thread-concurrent binary relation coverage. The fuzzing device includes: an instrumentation module for inserting thread number retrieval functions and basic block number retrieval functions before each basic block in the target program, and establishing thread spaces in shared memory; a coverage calculation module for extracting the basic block numbers and their corresponding thread numbers covered by the current execution of the target program from shared memory, and calculating the binary tuple coverage of the current execution; and a coverage evaluation module for comparing the set of binary tuples covered by the current execution with all existing sets of binary tuples to determine whether to store the set of binary tuples covered by the current execution in the seed sequence. This device enhances the ability to reach critical paths, boundary conditions, and combinations of critical states, improving exploration efficiency and the ability to trigger concurrent defects with controllable testing costs.

Description

Technical Field

[0001] This invention belongs to the field of concurrent testing technology, specifically relating to a fuzzy testing device and method based on thread concurrency binary relation coverage. Background Technology

[0002] In concurrent multithreaded programs, the nondeterminism introduced by thread scheduling order and thread interleaving methods constitutes one of the important technical roots of concurrency failures. Because the same target program may form different execution trajectories and shared state evolution processes under different scheduling and interleaving sequences, concurrency defects often exhibit engineering characteristics such as "low probability of triggering, unstable reproduction, and high localization costs." Related research indicates that by explicitly exposing, controlling, and searching for the nondeterminism of thread scheduling and interleaving, it is possible to discover and reproduce hard-to-catch concurrency errors, which reflects the high sensitivity of concurrency errors to interleaving sequences and the difficulty of reproduction. In complex system software (such as operating system kernels, databases, and runtime libraries), if concurrency defects are coupled with resource management, object lifecycle, and other mechanisms, they may further induce memory safety-related failures and bring security risks. Therefore, how to systematically improve the triggering and exposure capabilities of concurrency defects at a controllable testing cost has become a key technical problem that urgently needs to be solved.

[0003] From the perspective of existing research and engineering practice, detection and testing technologies for concurrent defects typically involve different paths: one type of approach improves defect reproduction and discovery capabilities by systematically controlling and searching thread scheduling and asynchronous events; another type emphasizes scalable automated test execution, typically represented by coverage-guided gray-box fuzzing frameworks. These frameworks collect coverage feedback through compile-time instrumentation and continuously generate test cases that can trigger "new internal states" using input mutation and feedback filtering mechanisms, thereby expanding the scope of exploration in the program's state space. However, in concurrent scenarios, traditional fuzzing usually relies mainly on input changes to indirectly induce execution differences and lacks the ability to specifically characterize and effectively guide concurrent interleaved behaviors. Therefore, it is difficult to stably cover the key triggering conditions and critical windows upon which concurrent defects depend within limited resources.

[0004] Furthermore, in coverage-guided fuzzing processes, the generation, selection, and retention of diverse input seeds heavily rely on the seed evaluation metrics and scheduling strategies of the tool. As fuzzing progresses, the number of candidate inputs grows rapidly. Effectively selecting the "most promising" inputs for subsequent mutations is considered a key factor affecting testing efficiency and defect discovery capabilities. Related research has systematically analyzed and empirically evaluated seed selection practices and their impact on defect discovery, further pointing out from the perspective of scheduling strategies that input selection / scheduling has a significant impact on coverage expansion and defect discovery. In this context, if evaluation metrics overemphasize immediate coverage gain or if strategy parameters are improperly set, misjudgments of the true value of seeds can easily occur in practice: some seeds that do not show significant coverage gain at the current stage but play a crucial guiding role in subsequent exploration are discarded prematurely, thereby weakening the diversity of the seed pool and the continuity of exploration. This leads to insufficient exploration of certain code regions and key state combinations, reducing the probability of defect triggering and overall detection effectiveness.

[0005] Therefore, the technical problems solved by this invention include: for concurrent multithreaded programs, under the premise of controllable testing costs, how to improve the coverage and effectiveness of the testing process from the perspective of input space exploration and seed management, addressing the testing blind spots and low trigger rates caused by the lack of effective guidance on concurrency-related behaviors in existing concurrent fuzzing, which mainly relies on input variation; and further, how to more accurately evaluate, retain, and utilize high-value input seeds, addressing the problem that the seed evaluation and retention mechanism in existing fuzzing is prone to value misjudgment, causing seeds that play a key guiding role in subsequent exploration to be discarded prematurely, thereby weakening input diversity and exploration depth. Summary of the Invention

[0006] To address the aforementioned problems in the existing technology, this invention provides a fuzz testing device and method based on thread-concurrent binary relation coverage. The technical problem to be solved by this invention is achieved through the following technical solution: This invention provides a fuzz testing device based on thread-concurrent binary relation coverage, comprising: The instrumentation module is used to insert thread number retrieval functions and basic block number retrieval functions before each basic block in the target program, and to create thread space in shared memory for each thread based on the basic blocks contained in each thread and the number of basic blocks. The coverage calculation module is used to extract the basic block number and its corresponding thread number covered by the current execution of the target program from the shared memory, and calculate the tuple coverage of the current execution by comparing the thread number and the basic block number between two basic blocks, so as to obtain the set of tuples covered by the current execution. The coverage evaluation module compares the set of tuples covered in this execution with all existing sets of tuples. Based on the total number of tuples in the set and whether the set of tuples covered in this execution is the same as all existing sets of tuples, it determines whether to store the set of tuples covered in this execution into the seed sequence.

[0007] In one embodiment of the present invention, the thread space is used to store the basic blocks contained in each thread and the number of basic blocks, and the number of basic blocks is stored in the last block of the thread space.

[0008] In one embodiment of the present invention, the calculation of the tuple coverage rate of the current execution by comparing the thread number and the basic block sequence number between two basic blocks includes: When the two basic blocks belong to the same thread number, the coverage of the tuple formed by the two basic blocks is 0. When the thread numbers of the two basic blocks are different and the sequence numbers of the two basic blocks are the same, the sequence number of any one of the basic blocks is recorded as the coverage of the tuple formed by the two basic blocks. When the two basic blocks belong to different thread numbers and the two basic blocks have different sequence numbers, the sequence numbers of the two basic blocks are XORed to obtain the coverage of the tuple formed by the two basic blocks.

[0009] In one embodiment of the present invention, the evaluation formula for the binary coverage rate is:

[0010] in, Indicates by and The binary tuple formed Representing basic blocks i , Representing basic blocks j , Representing basic blocks i The thread number to which it belongs. Representing basic blocks j The thread number to which it belongs. Representing basic blocks i The serial number, Representing basic blocks j The serial number.

[0011] In one embodiment of the present invention, the coverage evaluation module is specifically used for: Record the total number of pairs in the set of pairs covered by this execution; When the total number of the pairs is different from the number of pairs in the existing set of pairs, the set of pairs covered by this execution is stored in the seed sequence. When the total number of the two tuples is the same as the number of two tuples in the existing set of two tuples, and the set of two tuples covered by the current execution is different from the existing set of two tuples, the set of two tuples covered by the current execution is stored in the seed sequence. If the total number of the tuples is the same as the number of tuples in the existing set of tuples, and the set of tuples covered by this execution is the same as the existing set of tuples, then the set of tuples covered by this execution is discarded.

[0012] In one embodiment of the present invention, it further includes: The seed pool module is used to store the initial seed input as well as high-value input seeds retained during iterative execution; The seed selection module is used to select a seed from the seed pool as the parent input for this round of mutation; The mutation module is used to perform mutation operations on the seed to generate a set of test cases; The test execution module is used to input test cases into the instrumented target program for execution. During the execution process, the thread number acquisition function and the basic block number acquisition function are used to obtain the basic block number and its corresponding thread number. The basic blocks of different threads are stored in shared memory by thread number, and the number of basic blocks is stored in each thread space. The security detection module is used to perform security checks during or after test execution. If an abnormal situation occurs or the security detector outputs error information, the corresponding test case will be saved as an abnormal sample and an error report will be output. The seed selection module is used to select test cases based on the coverage assessment results, add the test cases that meet the conditions to the seed pool, and complete the closed-loop update.

[0013] Another embodiment of the present invention provides a fuzz testing method based on thread-concurrent binary relation coverage. The method is implemented by the fuzz testing apparatus based on thread-concurrent binary relation coverage as described in the above embodiments, and includes the following steps: Using the thread number acquisition function and the basic block number acquisition function, the basic block number and its corresponding thread number are obtained during the execution of the target program. The basic blocks of different threads and their corresponding thread numbers are stored in shared memory by thread number, and the number of basic blocks is stored in each thread space. Extract the basic block number and its corresponding thread number covered by the current execution of the target program from the shared memory, and calculate the tuple coverage rate of the current execution by comparing the thread number and basic block number between two basic blocks to obtain the set of tuples covered by the current execution. The set of tuples covered by this execution is compared with all existing sets of tuples. Based on the total number of tuples in the set and whether the set of tuples covered by this execution is the same as all existing sets of tuples, it is determined whether to store the set of tuples covered by this execution into the seed sequence.

[0014] In one embodiment of the present invention, the step further includes: Import the initial seed input into the seed pool; Select a seed from the seed pool as the parent input for this round of mutation; Perform a mutation operation on the seed to generate one or more test cases, resulting in a test case set; The test cases are input into the instrumented target program for execution. During the execution process, the sequence number of the basic block traversed and its corresponding thread number are obtained and stored separately for each thread. Security checks are performed during or after the test execution. If any abnormal situation occurs or the security detector outputs error information, the corresponding test case is saved as an abnormal sample and an error report is output. High-value input seeds retained during iterative execution are stored in the seed sequence to update the seed pool.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: In this invention, the instrumentation module inserts a thread number retrieval function and a basic block sequence number retrieval function before the basic block, and establishes a thread space for each thread. In the coverage calculation module, the coverage of binary pairs is calculated based on the basic block sequence number and the thread number. In the coverage evaluation module, the binary pair set is compared to determine whether to retain the binary pair set covered in this execution. This fuzzing device is an improvement for input space exploration, and the seed evaluation mechanism has been optimized. It can more accurately identify and retain input seeds that have key guiding value for subsequent exploration, reduce the probability of key seeds being incorrectly eliminated, maintain the diversity of the seed pool and the continuity of exploration, and solve the problem that the existing coverage-oriented seed evaluation and retention mechanism is prone to key seed underreporting and erroneous discarding, which weakens the depth and coverage completeness of subsequent exploration. This enhances the ability to reach critical paths, boundary conditions and key state combinations, and improves exploration efficiency and concurrent defect triggering capability under controllable testing costs. Attached Figure Description

[0016] Figure 1 A schematic diagram of the structure of a fuzzy testing device based on thread-concurrent binary relation coverage provided in an embodiment of the present invention; Figure 2 A schematic diagram of another fuzzy testing device based on thread concurrency binary relation coverage provided in an embodiment of the present invention; Figure 3A schematic diagram of shared memory provided in an embodiment of the present invention; Figure 4 A schematic diagram of a coverage evaluation module based on binary tuples provided in an embodiment of the present invention; Figure 5 Exemplary illustrations provided for embodiments of the present invention; Figure 6 A comparison diagram of the original edge coverage and the coverage rate based on tuples provided for embodiments of the present invention; Figure 7 The experimental results of the basic block coverage test provided in the embodiments of the present invention are shown in the figure. Figure 8 The experimental results of the binary coverage test provided in the embodiment of the present invention are shown in the figure. Detailed Implementation

[0017] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0018] Example 1 Coverage-guided fuzzing techniques, exemplified by Alternating Flask (AFL), typically use coverage information (such as edge coverage) as the primary feedback signal and whether new coverage is generated as a crucial criterion for retaining input seeds and allowing them to continue mutation in the seed pool. Under this mechanism, seed value is largely simplified to its immediate contribution to coverage increment. However, in actual testing, especially with complex or concurrent multi-threaded programs, many input seeds, while not showing significant coverage gain in the current round, can construct specific program states, satisfy specific preconditions, or guide subsequent mutations into deeper logical branches and boundary conditions. These are considered "potentially high-value seeds" that play a crucial supporting role in subsequent exploration. For example, if the first seed covers path A and another covers path B, but a third seed simultaneously covers both paths A and B, although it covers the paths covered by the previous two seeds, has stronger concurrency, and has greater potential to explore deeper levels of program execution, it will be incorrectly considered covered by AFL because it only covers previously covered paths. Therefore, it is discarded, missing input for deeper exploration.

[0019] Because existing coverage evaluation metrics and seed retention strategies focus on short-term coverage increments (e.g., edge coverage), the aforementioned potentially high-value seeds are often misjudged as low-value or redundant seeds and discarded prematurely, resulting in "false positives / false negatives." This phenomenon directly weakens the diversity and representativeness of the seed pool, leaving subsequent mutation exploration without the necessary input precursors and state construction foundation. Consequently, it leads to insufficient exploration of certain code regions, key state combinations, and special boundary conditions, reducing the probability of triggering hidden defects (including concurrency defects and their derived anomalies) and the overall testing performance.

[0020] This embodiment improves upon existing coverage-guided gray-box fuzzing tools, providing a fuzzing device based on thread-concurrent binary relation coverage, which is implemented in C++.

[0021] Please see Figure 1 and Figure 2 , Figure 1 This is a schematic diagram of the structure of a fuzzy testing device based on thread-concurrent binary relation coverage provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of another fuzzy testing device based on thread-concurrent binary relation coverage provided in an embodiment of the present invention.

[0022] This embodiment of the fuzzy testing device based on thread-concurrent binary relation coverage includes an instrumentation module, a coverage calculation module, and a coverage evaluation module.

[0023] The instrumentation module is used to insert thread number retrieval functions and basic block number retrieval functions before each basic block in the target program, and to create thread space in shared memory for each thread based on the basic blocks contained in each thread and the number of basic blocks.

[0024] The coverage calculation module is used to extract the basic block number and its corresponding thread number covered by the current execution of the target program from the shared memory, and calculate the tuple coverage of the current execution by comparing the thread number and the basic block number between two basic blocks, thus obtaining the set of tuples covered by the current execution.

[0025] The coverage evaluation module compares the set of tuples covered in this execution with all existing sets of tuples. Based on the total number of tuples in the set and whether the set of tuples covered in this execution is the same as all existing sets of tuples, it determines whether to store the set of tuples covered in this execution into the seed sequence.

[0026] Please see Figure 3 , Figure 3 This is a schematic diagram of shared memory provided in an embodiment of the present invention.

[0027] In one specific implementation, the instrumentation module of this embodiment instrumentes thread-sensitive basic blocks, such as... Figure 3 As shown, thread-sensitive instrumentation is performed on basic blocks A, B, and C in thread 1 and basic blocks D and E in thread 2. Taking basic block A as an example, a function to obtain the thread number and the basic block number is inserted before A. This way, when the program under test is executed, the information of basic block A, such as the ID of thread 1 and basic block A (i.e., the basic block number), can be stored in shared memory. This allows the basic block and its associated thread number to be recorded. Then, in subsequent coverage evaluation and calculation, this recorded information is used to change the edge coverage of the original basic blocks into a binary tuple coverage, thereby reducing false positives and false negatives in the seed.

[0028] Furthermore, in the shared memory storage section, this embodiment changes the shared memory structure from the original bitmap to a long one-dimensional array. A fixed-length space is allocated to each thread within the shared memory to form a thread space. Then, for each thread, the number of basic blocks it contains and the number of basic blocks it contains are stored. For example, for thread 2, the starting address of this thread can be easily calculated as 2 * (allocated space), thus achieving efficient storage. In addition, this embodiment stores the number of basic blocks contained in each thread in the last block of the thread space, so that when this information is accessed later, the number of basic blocks traversed by each thread can be obtained, thereby calculating the subsequent tuple coverage and making comparisons.

[0029] In one specific implementation, this embodiment selects tuple coverage as the coverage evaluation algorithm. The evaluation formula for tuple coverage is:

[0030] in, Indicates by and The binary tuple formed Representing basic blocks i , Representing basic blocks j , Representing basic blocks i The thread number to which it belongs. Representing basic blocks j The thread number to which it belongs. Representing basic blocks i The sequence number is the basic block. i ID, Representing basic blocks j The sequence number is the basic block. j ID.

[0031] Specifically, when evaluating the coverage of a seed's tuples, the thread IDs of the two basic blocks are first compared. When the thread IDs of the two basic blocks are the same, they belong to the same thread, and the coverage of the tuple formed by the two basic blocks is 0. This is because the two basic blocks belong to the same thread, and the execution order within a thread is fixed and sequential; therefore, the two basic blocks have no practical value.

[0032] When two basic blocks belong to different thread numbers, the sequence numbers of the two basic blocks are compared.

[0033] When two basic blocks belong to different thread numbers but have the same sequence number, meaning that different threads are calling two identical basic blocks, since the sequence numbers of the two basic blocks are the same, it is only necessary to record one of the IDs as the coverage of the tuple. That is, the sequence number of any basic block is recorded as the coverage of the tuple composed of the two basic blocks.

[0034] When two basic blocks belong to different thread numbers and have different sequence numbers, and the two basic blocks are neither from the same thread nor the same basic block, the XOR operation on the sequence numbers of the two basic blocks yields the coverage of the tuple formed by the two basic blocks.

[0035] Please see Figure 4 , Figure 4 This is a schematic diagram of a coverage evaluation module based on binary tuples provided in an embodiment of the present invention.

[0036] After calculating the coverage of the pairs in this execution, the set of pairs obtained in this execution is compared with the existing set of pairs.

[0037] In one specific implementation, the total number of pairs in the set of pairs covered by this execution is first recorded.

[0038] When the total number of pairs is different from the number of pairs in the existing set of pairs, the two sets can be considered different, and the set of pairs covered in this execution can be directly stored in the seed sequence.

[0039] When the total number of pairs is the same as the number of pairs in the existing pair set, and the pair set covered by this execution is different from the existing pair set, the pair set covered by this execution is a brand new set that has never appeared before. It is considered a valuable cover and worth further exploration. Therefore, the pair set covered by this execution is stored in the seed sequence for subsequent mutation exploration.

[0040] If the total number of pairs is the same as the number of pairs in the existing set of pairs, and the set of pairs covered by this execution is the same as the existing set of pairs, it means that the execution situation of this program has already occurred before, and this seed is considered useless. Therefore, the set of pairs covered by this execution is discarded.

[0041] Please see again Figure 2 The fuzzy testing device based on thread-concurrent binary relation coverage in this embodiment also includes: a seed pool module, a seed selection module, a mutation module, a test execution module, a security detection module, and a seed screening module.

[0042] The seed pool module is used to store the initial seed input and the high-value input seeds retained during the iteration process, which serve as the basis for subsequent mutation to generate test cases.

[0043] The seed selection module is used to select a seed from the seed pool as the parent input for this round of mutation. This selection process can be scheduled based on information such as the seed's coverage contribution and execution efficiency in historical iterations.

[0044] The mutation module is used to perform mutation operations on the seed, generating one or more test cases to obtain a test case set. It can include deterministic mutations (such as flipping, replacing, or arithmetically perturbing bytes / bits according to fixed rules) and random mutations (randomly combining and superimposing multiple mutation operators), and can splice different seed fragments to generate new input structures when needed.

[0045] The test execution module is used to input test cases into the instrumented target program for execution. During execution, it uses thread number acquisition functions and basic block number acquisition functions to obtain the basic block number and its corresponding thread number. Then, it stores the basic blocks of different threads in shared memory, using the thread number as a separator. At the same time, it stores the number of basic blocks in each thread space, thereby completing the tracking and coverage information collection of the execution behavior. In addition, it uses execution optimization mechanisms to improve throughput (such as reuse initialization and fast forking of execution instances).

[0046] The security detection module is used to perform security checks during or after test execution. If an abnormal situation such as crash, abnormal exit, or timeout occurs, or if the security detector (such as Sanitizer) outputs error information, the corresponding test case will be saved as an abnormal sample and an error report will be output to characterize potential security vulnerability clues.

[0047] The seed selection module is used to select test cases based on the coverage assessment results, add the test cases that meet the conditions to the seed pool, update the contents of the seed pool, and complete the closed-loop update.

[0048] It should be noted that the specific execution process of the above-mentioned seed pool module, seed selection module, mutation module, test execution module, security detection module and seed screening module is the same as that of the existing coverage-guided gray-box fuzz testing tool AFL, and will not be described again in this embodiment.

[0049] In this embodiment, the instrumentation module inserts a thread number retrieval function and a basic block sequence number retrieval function before the basic block, and establishes a thread space for each thread. In the coverage calculation module, the coverage of binary pairs is calculated based on the basic block sequence number and the thread number. In the coverage evaluation module, the binary pair set is compared to determine whether to retain the binary pair set covered in this execution. This fuzzing device is an improvement for input space exploration, and the seed evaluation mechanism has been optimized. It can more accurately identify and retain input seeds that have key guiding value for subsequent exploration, reduce the probability of key seeds being incorrectly eliminated, maintain the diversity of the seed pool and the continuity of exploration, and solve the problem that the existing coverage-oriented seed evaluation and retention mechanism is prone to key seed underreporting and erroneous discarding, which weakens the depth and coverage completeness of subsequent exploration. This enhances the ability to reach critical paths, boundary conditions and key state combinations, improves exploration efficiency and concurrent defect triggering capability under controllable testing costs, and improves the overall detection effect.

[0050] Example 2 Based on Embodiment 1, this embodiment provides a fuzz testing method based on thread-concurrent binary relation coverage. This fuzz testing method is implemented by the fuzz testing device based on thread-concurrent binary relation coverage from Embodiment 1, and mainly includes three steps: S1. Using the thread number acquisition function and the basic block number acquisition function, obtain the basic block number and its corresponding thread number that the target program passes through during execution. Then, using the thread number as the separator, store the basic blocks of different threads and their respective thread numbers in shared memory. At the same time, store the number of basic blocks in each thread space so that the information can be extracted during subsequent binary tuple calculation. S2. Extract the basic block number and its corresponding thread number covered by the current execution of the target program from the shared memory, and calculate the tuple coverage rate of the current execution by comparing the thread number and basic block number between two basic blocks, and obtain the set of tuples covered by the current execution. S3. Compare the set of tuples covered by this execution with all existing sets of tuples. Based on the total number of tuples in the current set and whether the set of tuples covered by this execution is the same as all existing sets of tuples, determine whether to store the set of tuples covered by this execution in the seed sequence. This embodiment can reduce false negatives and false positives in the seed sequence by evaluating the set of tuples.

[0051] Furthermore, please combine Figure 2The fuzz testing method based on thread-concurrent binary relation coverage in this embodiment further includes the following steps: The initial seed input is imported into the seed pool, which is used to store a set of input seeds that can be used as the basis for subsequent mutations. Select a seed from the seed pool as the parent input for this round of mutation; Perform a mutation operation on the seed to generate one or more test cases, resulting in a test case set; The test cases are input into the instrumented target program for execution. During the execution, the thread number acquisition function and the basic block number acquisition function are used to obtain the basic block number and its corresponding thread number. The basic blocks of different threads are stored in shared memory by thread number. At the same time, the number of basic blocks is stored in each thread space, thereby completing the tracking and coverage information collection of this execution behavior. Security checks are performed during or after the test execution. If any abnormal situation occurs or the security detector outputs error information, the corresponding test case is saved as an abnormal sample and an error report is output. High-value input seeds retained during the iterative execution process are stored in the seed sequence to update the seed pool; then, the next round of seed selection and mutation testing continues, thus completing the feedback path of "coverage → seed screening → seed pool" and forming a closed-loop process of continuous iteration.

[0052] It should be noted that the overall process of the fuzzing test method based on thread concurrency binary relation coverage in this embodiment is as follows: instrumentation of the target program -> input of the initial seed -> selection of the seed for mutation -> passing the mutated seed as input to the target program for execution -> recording the execution status of the target program -> calculation of coverage -> coverage evaluation, thereby achieving the purpose of a complete concurrency detection tool driven by the generation of input.

[0053] Example 3 Based on Embodiment 1 and Embodiment 2, the technical effects of the present invention are illustrated through the following examples and experimental tests.

[0054] Please see Figure 5 , Figure 5 The illustration is provided for an embodiment of the present invention. Figure 5 In the example, we can see that there is actually a hidden use-after-free problem, which is the use of freed memory. If the execution order of the basic blocks is A->B->C->G, this concurrency vulnerability can be triggered. However, we can see that in this program, the input requirements for executing these basic blocks are very strict. The basic blocks A, B, D, E, and F must be satisfied simultaneously to meet the input conditions.

[0055] The following section demonstrates how the existing fuzzing tool (AFL) generates inputs for this program, and compares the results of the existing fuzzing tool with the method of this invention.

[0056] Please see Figure 6 , Figure 6 This is a comparison diagram of the original edge coverage and the coverage rate based on tuples provided in this embodiment of the invention. As can be seen from the diagram, in this example, although seed1 and seed2 each cover a portion of the edges between new basic blocks and cover some new execution scenarios, seed3 clearly covers all the execution scenarios of the previous two seeds. Therefore, seed3 has stronger concurrency and is more worthy of further exploration. However, in... Figure 6 As can be seen, in the original Covered Edges evaluation criteria, Seed1 and Seed2 are retained, but Seed3 is incorrectly discarded because it does not cover any new edges, resulting in a false positive. However, in the Covered Tuple Set of this invention, seed3 is considered a completely new seed and is retained, thus avoiding the original false positive and false negative issues.

[0057] To test the rationality and effectiveness of the technical solution of the present invention, this embodiment selected eight concurrent multi-threaded programs with very strict input requirements to evaluate the performance of the program of the present invention and the original program under relatively extreme requirements.

[0058] Please see Figure 7 , Figure 7 The figure shows the experimental results of the basic block coverage test provided in the embodiment of the present invention. Figure 7 In the diagram, Nall represents all the basic blocks of the program, Ncov represents the total number of basic blocks covered by the tool on the program, and Nmax represents the maximum number of basic blocks covered by a single seed generated by the tool. As shown in the figure, although the proposed solution (HVSAFL) has some advantages over the original tools (AFL, MOPT) in basic block coverage testing, the difference in performance improvement among the three is not significant. While the proposed tool (HVSAFL) can basically cover all basic blocks, the original tools (AFL, MOPT) can maintain coverage of over 80% in most cases. Therefore, this embodiment conducts a second experiment to evaluate the coverage of binary pairs and test the ability of the three tools to generate input portions.

[0059] Please see Figure 8 , Figure 8 The experimental results of the binary coverage test provided in the embodiment of the present invention are shown in the figure. Figure 8 In the diagram, Time represents the time taken to find the input required by the program during the test, T / O indicates that the input was not found even after the time expired, and NT represents the number of tuples covered in this test. As can be seen, the tool of this invention (HVSAFL) can cover more tuples. Since the tuples are records of program execution, it can be seen that the solution of this invention has found the specific input required to trigger concurrency errors in all programs. This means that the solution of this invention can detect more program execution situations, which means that this invention can better explore the input space of the program more completely.

[0060] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A fuzz testing device based on thread-concurrent binary relation coverage, characterized in that, include: The instrumentation module is used to insert thread number retrieval functions and basic block number retrieval functions before each basic block in the target program, and to create thread space in shared memory for each thread based on the basic blocks contained in each thread and the number of basic blocks. The coverage calculation module is used to extract the basic block number and its corresponding thread number covered by the current execution of the target program from the shared memory, and calculate the tuple coverage of the current execution by comparing the thread number and the basic block number between two basic blocks, so as to obtain the set of tuples covered by the current execution. The coverage evaluation module compares the set of tuples covered in this execution with all existing sets of tuples. Based on the total number of tuples in the set and whether the set of tuples covered in this execution is the same as all existing sets of tuples, it determines whether to store the set of tuples covered in this execution into the seed sequence.

2. The fuzz testing device based on thread-concurrent binary relation coverage according to claim 1, characterized in that, The thread space is used to store the basic blocks contained in each thread and the number of basic blocks, and the number of basic blocks is stored in the last block of the thread space.

3. The fuzz testing device based on thread-concurrent binary relation coverage according to claim 1, characterized in that, The coverage rate of the tuples executed in this operation is calculated by comparing the thread number and the sequence number of the two basic blocks, including: When the two basic blocks belong to the same thread number, the coverage of the tuple formed by the two basic blocks is 0. When the thread numbers of the two basic blocks are different and the sequence numbers of the two basic blocks are the same, the sequence number of any one of the basic blocks is recorded as the coverage of the tuple formed by the two basic blocks. When the two basic blocks belong to different thread numbers and the two basic blocks have different sequence numbers, the sequence numbers of the two basic blocks are XORed to obtain the coverage of the tuple formed by the two basic blocks.

4. The fuzz testing device based on thread-concurrent binary relation coverage according to claim 3, characterized in that, The formula for evaluating the coverage rate of the binary tuple is: in, Indicates by and The binary tuple formed Representing basic blocks i , Representing basic blocks j , Representing basic blocks i The thread number to which it belongs. Representing basic blocks j The thread number to which it belongs. Representing basic blocks i The serial number, Representing basic blocks j The serial number.

5. The fuzz testing device based on thread-concurrent binary relation coverage according to claim 1, characterized in that, The coverage assessment module is specifically used for: Record the total number of pairs in the set of pairs covered by this execution; When the total number of the pairs is different from the number of pairs in the existing set of pairs, the set of pairs covered by this execution is stored in the seed sequence. When the total number of the two tuples is the same as the number of two tuples in the existing set of two tuples, and the set of two tuples covered by the current execution is different from the existing set of two tuples, the set of two tuples covered by the current execution is stored in the seed sequence. If the total number of the tuples is the same as the number of tuples in the existing set of tuples, and the set of tuples covered by this execution is the same as the existing set of tuples, then the set of tuples covered by this execution is discarded.

6. The fuzz testing device based on thread-concurrent binary relation coverage according to claim 1, characterized in that, Also includes: The seed pool module is used to store the initial seed input as well as high-value input seeds retained during iterative execution; The seed selection module is used to select a seed from the seed pool as the parent input for this round of mutation; The mutation module is used to perform mutation operations on the seed to generate a set of test cases; The test execution module is used to input test cases into the instrumented target program for execution. During the execution process, the thread number acquisition function and the basic block number acquisition function are used to obtain the basic block number and its corresponding thread number. The basic blocks of different threads are stored in shared memory by thread number, and the number of basic blocks is stored in each thread space. The security detection module is used to perform security checks during or after test execution. If an abnormal situation occurs or the security detector outputs error information, the corresponding test case will be saved as an abnormal sample and an error report will be output. The seed selection module is used to select test cases based on the coverage assessment results, add the test cases that meet the conditions to the seed pool, and complete the closed-loop update.

7. A fuzz testing method based on thread-concurrent binary relation coverage, characterized in that, The method is implemented by the fuzz testing apparatus based on thread-concurrency binary relation coverage as described in any one of claims 1-6, and includes the following steps: Using the thread number acquisition function and the basic block number acquisition function, the basic block number and its corresponding thread number are obtained during the execution of the target program. The basic blocks of different threads and their corresponding thread numbers are stored in shared memory by thread number, and the number of basic blocks is stored in each thread space. Extract the basic block number and its corresponding thread number covered by the current execution of the target program from the shared memory, and calculate the tuple coverage rate of the current execution by comparing the thread number and basic block number between two basic blocks to obtain the set of tuples covered by the current execution. The set of tuples covered by this execution is compared with all existing sets of tuples. Based on the total number of tuples in the set and whether the set of tuples covered by this execution is the same as all existing sets of tuples, it is determined whether to store the set of tuples covered by this execution into the seed sequence.

8. The fuzz testing method based on thread-concurrent binary relation coverage according to claim 7, characterized in that, It also includes the following steps: Import the initial seed input into the seed pool; Select a seed from the seed pool as the parent input for this round of mutation; Perform a mutation operation on the seed to generate one or more test cases, resulting in a test case set; The test cases are input into the instrumented target program for execution. During the execution process, the sequence number of the basic block traversed and its corresponding thread number are obtained and stored separately for each thread. Security checks are performed during or after the test execution. If any abnormal situation occurs or the security detector outputs error information, the corresponding test case is saved as an abnormal sample and an error report is output. High-value input seeds retained during iterative execution are stored in the seed sequence to update the seed pool.

Images