A Parallel Fuzzy Testing Method and System Based on Dynamic Adjustment of Mutation Strategy

Abstract

The embodiments of this disclosure provide a parallel fuzz testing method and system based on dynamic adjustment of mutation strategies. The system adopts a master-slave architecture, including a scheduling node and multiple test nodes. The method includes: initializing and training multiple mutation strategies; assigning initial weights and priorities to each mutation strategy according to the execution effect of the strategy on the target program; the scheduling node allocating parallel test tasks among multiple test nodes according to the initial weights and priorities, and receiving test instance feedback; during the parallel execution of test tasks, the scheduling node dynamically adjusts the strategy weights and task allocation according to the test instance feedback; and evaluating the differences of test cases generated by each test node, extracting new valid samples, and synchronizing the valid samples to all test nodes after deduplication.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of software security testing, and more specifically, to a parallel fuzzing method and system based on dynamic adjustment of mutation strategies. Background Technology

[0002] Fuzzing, as a dynamic and automated vulnerability discovery technique, has been widely applied in various security assessment scenarios by fuzzing, randomly generating, and mutating program input. However, traditional fuzzing is often limited by the efficiency of single-instance operation. In recent years, parallel fuzzing techniques for large-scale targets have emerged, hoping to accelerate vulnerability discovery through multi-instance collaboration. However, in practical applications, they face serious problems of redundant sample generation and overlapping test paths. For example, if multiple fuzzing instances do not effectively coordinate mutation operations and sample libraries, they are very likely to repeatedly test the same paths, wasting resources and lowering the overall test output. In addition, current systems often only implement static load balancing across multiple instances, lacking dynamic mutation strategy feedback and control mechanisms, and cannot adapt to different program structures and input semantic changes. Test results cannot be shared and enhanced across instances. For example, some non-duplicate valid samples may cause new path coverage or even crashes in local instances, but because the test instances run in isolation, these high-value samples cannot be propagated to other instances for further in-depth testing, thus missing deeper paths or use cases.

[0003] Therefore, improving the differentiation and collaboration among multiple test instances, and reducing policy overlap and coverage decline from the source, has become an urgent problem to be solved for the practical deployment of parallel fuzz testing technology. Summary of the Invention

[0004] The embodiments described herein provide a parallel fuzzing method, system, apparatus, and computer-readable storage medium storing a computer program based on dynamic adjustment of mutation strategies. The aim is to dynamically evaluate the quality of mutation strategies, adjust strategy segmentation and combination behaviors in real time based on feedback information, and achieve cross-instance synchronous sharing of effective samples, thereby improving the overall coverage depth and vulnerability access efficiency of the system.

[0005] According to a first aspect of this disclosure, a parallel fuzzing method based on dynamic adjustment of mutation strategies is provided, suitable for execution in a parallel fuzzing system based on dynamic adjustment of mutation strategies. The system adopts a master-slave architecture, including a scheduling node and multiple test nodes. The method includes: initializing and training multiple mutation strategies; assigning initial weights and priorities to each mutation strategy based on the execution effect of the strategy on the target program; the scheduling node allocating parallel test tasks among multiple test nodes according to the initial weights and priorities, and receiving test instance feedback; during the parallel execution of test tasks, the scheduling node dynamically adjusts the strategy weights and task allocation according to the test instance feedback; and evaluating the differences of test cases generated by each test node, extracting new valid samples, and synchronizing the valid samples to all test nodes after deduplication.

[0006] In some embodiments of this disclosure, initial training is performed on multiple mutation strategies. Based on the execution effect of the strategies on the target program, initial weights and priorities are assigned to each mutation strategy, including: generating multiple mutation strategies, such as bit flipping, magic number byte injection, and structure-aware mutation; initial training is performed on multiple mutation strategies, and the new path generation capability, crash triggering frequency, and execution speed of each mutation strategy during the execution of the target program are evaluated. Based on the evaluation results, an initial weight is assigned to each mutation strategy; a dynamic exponential decay mechanism is used to adjust the initial weights of each mutation strategy, and the best-performing strategy is selected to enter the actual scheduling stage first.

[0007] In some embodiments of this disclosure, the initial weight calculation formula is as follows:

[0008]

[0009] Among them, P path P represents the score indicating the ability to generate new paths. crash The score representing the frequency of crash triggering, P speed The score represents the execution efficiency, where α, β, and γ are the weight coefficients for each dimension, and the Total Weight Factor is the total weight factor for all strategies.

[0010] In some embodiments of this disclosure, during the parallel execution of test tasks, the scheduling node dynamically adjusts the policy weights and task allocation based on test instance feedback, including:

[0011] The execution process of fuzz testing on the target program is divided into multiple stages, including the initial exploration stage, the deep coverage stage, the vulnerability discovery stage, and the stability verification stage, and the task objectives of each stage are set. Corresponding mutation strategies and their weights are assigned according to the task objectives of each stage. Switching conditions between different testing stages are defined, including time thresholds, coverage saturation, the number of specific types of vulnerabilities discovered, and the stability of the input queue. Testing stages are selected according to the switching conditions. Within each stage, the strategy weights or priorities are adjusted based on the strategy performance feedback from the test instances.

[0012] In some embodiments of this disclosure, adjusting the strategy weights or priorities based on the strategy performance feedback from test instances at each stage includes: continuously monitoring the execution results of each mutated strategy and evaluating its performance in path generation, crash triggering, and execution speed; evaluating the performance of the current strategy combination using a sliding window model, and allocating the weight of each strategy using proportional scheduling or strategy elimination based on the evaluation results of the strategy performance; and adjusting the strategy combination of the current stage at the end of each sliding window update cycle based on the strategy weight update status.

[0013] In some embodiments of this disclosure, the process of evaluating the differences of test cases generated by each test node, extracting new valid samples, and synchronizing the valid samples to all test nodes after deduplication includes: periodically executing sample synchronization tasks by setting up a periodic synchronization thread to collect test cases generated by multiple test nodes; selecting new valid samples based on the path differences and code coverage improvement of different test instances; comparing the extracted valid samples with the central deduplication library to remove duplicates, and then broadcasting them to all test nodes.

[0014] In some embodiments of this disclosure, after the extracted valid sample is compared with the central deduplication library for deduplication, it is broadcast to all test nodes. This includes: comparing the path and coverage of the valid sample with the existing samples stored in the central deduplication library using a unique identifier to determine whether the current sample has been covered or merged by samples generated by other nodes; if the new valid sample has not been covered or merged, the sample is distributed to each test node through a distributed message queue or broadcast mechanism to continue executing the test task.

[0015] According to a second aspect of this disclosure, a parallel fuzzing system based on dynamic adjustment of mutation strategies is provided, comprising: a scheduling node and multiple test nodes. The scheduling node has a built-in scheduling engine, scheduling model, and feedback data interface for parallel scheduling of fuzzing tasks, allocation of mutation strategies to each test node, real-time monitoring of the execution status of each test node, collection of feedback information, and dynamic adjustment of the allocation of test strategies based on the feedback information. The multiple test nodes have built-in data receiving and feedback interfaces and execution engines for executing fuzzing tasks according to the mutation strategies allocated by the scheduling node, generating test cases, and feeding back the execution results to the scheduling node.

[0016] In some embodiments of this disclosure, the scheduling engine is responsible for scheduling different test tasks and adjusting the execution strategy based on feedback; the scheduling model is responsible for defining the selection of scheduling strategies and algorithms, including a strategy scheduling algorithm library, model parameters, and external interface standard encapsulation; the feedback interface is used to receive feedback data transmitted from each test node, so that the scheduling engine can dynamically adjust the strategy weight of each test case based on the feedback data.

[0017] In some embodiments of this disclosure, the execution engine supports user customization of the instrumentation fuzzy engine according to their needs. The handle portion of the execution engine interfaces with the scheduling control instructions and is responsible for transmitting the control instructions issued by the scheduling engine to the specific execution tasks.

[0018] The parallel fuzz testing method and system based on dynamic adjustment of mutation strategy according to embodiments of this disclosure, by introducing multi-instance parallel testing and optimizing the scheduling mutation strategy, maximizes the testing effect and efficiency of each instance. During the testing process, the testing strategy and resource allocation can be optimized and adjusted based on the feedback information of the test results, ensuring the dynamic adaptability of the testing process. By evaluating the differences of test cases generated by each test node, new and uncovered valid samples can be effectively extracted, avoiding redundant path testing, thereby expanding the test coverage. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. It should be understood that the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure, wherein:

[0020] Figure 1 This is an exemplary structural diagram of a parallel fuzz testing system based on a mutation strategy for dynamic adjustment according to an embodiment of the present disclosure;

[0021] Figure 2 This is an exemplary flowchart of a parallel fuzzing method based on a mutation strategy for dynamic adjustment according to an embodiment of the present disclosure.

[0022] It should be noted that the elements in the attached diagram are schematic and not drawn to scale. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are also within the scope of protection of this disclosure.

[0024] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this subject matter pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having meanings consistent with their meanings in the context of the specification and in the relevant art, and shall not be interpreted in an idealized or overly formal form unless otherwise explicitly defined herein. Furthermore, terms such as “first” and “second” are used only to distinguish one component (or part of a component) from another component (or another part of a component).

[0025] This disclosure proposes a parallel fuzzing method and system based on dynamic adjustment of mutation strategy. It adopts a master-slave architecture to control multiple test nodes to work collaboratively, and dynamically adjusts the mutation strategy through a feedback mechanism to ensure that new paths can be explored and program crashes can be triggered as much as possible during fuzzing. By synchronizing test samples with incremental value to all test instances, it ensures that new test cases can be shared among test nodes, reducing redundant testing.

[0026] Figure 1 This is an exemplary structural diagram of a parallel fuzzing testing system dynamically adjusted based on a mutation strategy, according to embodiments of this disclosure. (Refer to...) Figure 1As shown, the system adopts a master-slave architecture, including a scheduling node (master node) and multiple test nodes (slave nodes). The scheduling node has a built-in scheduling engine, scheduling model, and feedback data interface for parallel scheduling of fuzzing tasks. It distributes mutation strategies to each test node, monitors the execution status of each test node in real time, collects feedback information, and dynamically adjusts the allocation of test strategies based on the feedback. The scheduling engine is responsible for scheduling different test tasks, supporting multi-threaded or distributed scheduling. It can process multiple mutation strategies in parallel and adjust the execution strategy based on feedback. The scheduling engine can reasonably allocate tasks based on the resource status of each test node (such as CPU utilization, memory usage, etc.) to avoid unbalanced load between nodes and ensure the efficiency of the overall testing process. The scheduling model is responsible for defining the selection of scheduling strategies and algorithms, including a strategy scheduling algorithm library, model parameters, and standard encapsulation of external interfaces. The strategy scheduling algorithm library provides various scheduling strategy algorithms, including traditional random scheduling, priority-based scheduling, and intelligent optimization algorithms (such as genetic algorithms and simulated annealing). Model parameters include the execution weight, scheduling frequency, and crash trigger threshold for each strategy. The scheduling model can optimize model parameters based on the operating environment, target program characteristics, and historical feedback data. To ensure compatibility with external systems, the scheduling model uses standardized interfaces to interact with external modules (such as external data sources, third-party tools, etc.). Encapsulating these interfaces helps the system integrate with other testing tools or external platforms.

[0027] During testing, each test node generates feedback data, including crash information, new paths, and execution status, which is transmitted to the scheduling node via a high-speed parallel channel. The feedback interface receives this data from each test node, allowing the scheduling engine to dynamically adjust the strategy weights of each test case based on the feedback. For example, if a strategy triggers a program crash or discovers a new path, its weight is increased, causing it to be executed more frequently in subsequent tests. The feedback interface can also remotely package and push relevant information, log files, and test reports generated during the test, enabling slave nodes to quickly transmit test execution results to the master node.

[0028] Multiple test nodes are responsible for executing specific fuzzing tasks in parallel. They execute test tasks based on the strategies assigned by the scheduler node, generate test cases, and feed the execution results back to the scheduler node. Each test node has built-in data receiving and feedback interfaces and an execution engine. Each test node handles an independent task and coordinates with other nodes through the feedback interface channel. The execution engine supports user-customized instrumentation of the fuzzing engine according to requirements; common instrumentation tools include AFL and Honggfuzz. Instrumentation tools allow for dynamic modification of the target program, tracing program paths, and introducing mutation operations. The handle portion of the execution engine is tightly integrated with the scheduling control instructions, responsible for transmitting control instructions issued by the scheduler engine to specific execution tasks. Through these control instructions, the execution engine can flexibly adjust the execution of different strategies, ensuring the real-time nature and flexibility of scheduling. The execution engine updates its strategies in real time based on feedback data while executing test tasks.

[0029] Version updates to the target program may lead to changes in its functionality or input format. To ensure the fuzzing system can adapt to these updates and changes, and regenerate valid input conforming to the new format, the system can intelligently adjust the corpus generation method by analyzing changes in the target program's behavior and interface to accommodate new input requirements. By retaining valid seeds discovered in older fuzzing versions, the system ensures these seeds are used for regression testing in newer versions. For discovered vulnerabilities, the system verifies whether they have been fixed in the new version or whether they have introduced regression issues. Regression testing verifies whether old seeds remain valid, ensuring the new version of the program has not introduced new problems. When the target program changes only slightly, the existing corpus can be updated incrementally instead of regenerating the entire corpus.

[0030] The performance of mutation strategies also changes with program versions. The system can evaluate the performance of each mutation strategy based on the behavior of the new version and dynamically adjust its weight. For example, if a mutation strategy is no longer effective in a new version, its weight will be reduced. Conversely, if a mutation strategy produces good testing results for new features or protocols, its weight will be automatically increased.

[0031] Instrumentation tools can be compatible with different versions of the target program or provide updated instrumentation methods. As the target program is updated, new vulnerability types or defect patterns may be introduced. The system can extend with new types of crash analysis modules or memory error detectors, record the historical status of vulnerabilities (such as discovery time, remediation status, regression testing, etc.), and generate independent vulnerability reports for each version. By simultaneously performing fuzz testing on the old and new versions of the program and comparing their behavioral differences under the same input, it can help discover errors or behavioral deviations that the new version of the program may introduce, forming a complete closed-loop system capable of self-iteration and upgrade.

[0032] In a parallel fuzz testing system based on a mutation strategy for dynamic adjustment, ensuring the stability and fault tolerance of each test node is crucial for maintaining the continuity of the overall testing process, especially when node failures may occur during testing. According to one embodiment of this disclosure, each test node periodically sends a heartbeat signal to the central scheduler. This signal includes the current execution status (e.g., "I'm still running"), the ID of the currently executing test case, and recent crash information, indicating the node's status and operational condition. If the scheduler does not receive a heartbeat signal from a node within a preset time, it considers that the node to have failed or disconnected. This mechanism can promptly detect node failures and prevent the testing process from being interrupted.

[0033] Each test node deploys a daemon process responsible for monitoring the main fuzzing test process. The daemon checks if the process is still running and periodically assesses node anomalies by checking CPU and memory usage. When a test process exhibits abnormal resource usage (e.g., excessive CPU or memory consumption, or process unresponsiveness), the daemon reports this to the scheduler, potentially triggering a fault recovery mechanism. When a process terminates abnormally, the daemon detects this and initiates appropriate recovery measures. Node logs record various information during test execution, including errors, exceptions, and crashes. The scheduler or operations personnel can monitor node logs in real time to analyze for errors or crashes. Automated tools can be used to analyze logs and quickly identify problems. For example, rules can be used to detect crashes or abnormal errors and promptly notify administrators. The daemon process deployed on each test node monitors and automatically restarts processes when they crash or terminate, reducing test downtime caused by node crashes. If the daemon process cannot recover a failed node (e.g., due to node operating system issues), the scheduler can send a remote restart command. The operating system must support remote restart, typically applicable to container or virtual machine environments.

[0034] Fuzzing tasks are typically distributed via a shared queue. Tasks can include test case generation, mutation processing, or target program execution. If a node fails, its unfinished tasks are returned to the queue, and other healthy nodes take over, ensuring an uninterrupted workflow. Generated test cases, discovered crash information, coverage data, etc., are stored in shared storage (such as a distributed file system or database). If a node fails, other nodes can recover from the latest state without losing generated test cases or discovered vulnerabilities.

[0035] The scheduler maintains a pool of backup nodes. When a node failure is detected, the scheduler can immediately activate a backup node to take over the work of the failed node, or reassign the task to other nodes with lower load. Each test case is executed in an independent sandbox environment (such as a container or virtual machine), thus isolating potential crashes or malicious behavior within the sandbox and preventing them from affecting the entire node or scheduler system. Even if a test case causes a crash, it will only affect the current sandbox and will not affect other test cases or nodes.

[0036] During fuzzing, strict CPU, memory, and time limits are set for each process to prevent certain test cases from consuming excessive resources and causing node crashes. For example, container technology can be used to set resource limits for each test case. By monitoring the resource usage of test nodes in real time, the monitoring tool will automatically terminate the process when abnormal resource usage is detected, preventing nodes from failing due to resource exhaustion and recording all anomalies for subsequent analysis. Detailed records are kept of all node failures, crashes, and restart events, generating log reports. These reports help operations personnel understand and analyze the causes of failures in a timely manner. The system can automatically generate fault reports and send them to relevant personnel for quick problem location and resolution. For example, a regular report generation mechanism can be set up, ensuring that the report content includes key information such as node health status, cause of crash, and number of restarts.

[0037] By combining the above mechanisms, the parallel fuzzing system based on dynamic adjustment through mutation strategies can respond rapidly to node failures, ensuring the continuity and stability of the testing process. These technical measures effectively reduce the impact of single-point failures on the overall testing process, ensuring the efficient execution of parallel testing.

[0038] To address the challenges of mutation strategy selection, instance redundancy, inefficient strategies, and sample fusion in existing fuzz testing methods. Figure 2 An exemplary flowchart of a parallel fuzz testing method based on a mutation strategy dynamically adjusted according to embodiments of the present disclosure is shown. Figure 2 At box S202, multiple mutation strategies are initialized and trained. Based on the execution effect of the strategies on the target program, initial weights and priorities are assigned to each mutation strategy.

[0039] Before system operation, multiple mutation strategies are generated, such as bit flipping, magic byte injection, and structure-aware mutation. These strategies are then initialized and trained, and their performance on the target program is evaluated. Evaluation dimensions include new path generation capability, crash triggering frequency, and execution efficiency. Each mutation strategy is assigned an initial weight based on the evaluation results. For example, by tracing the program execution path, it's determined whether unexecuted code paths are covered; if a strategy can trigger new code execution paths, its evaluation score is higher. The number of program crashes and their severity are recorded, and the frequency of crashes triggered by strategies is used to identify potential system defects. The execution time of each strategy is recorded, including the start and completion times of each test task. The execution efficiency of different strategies is evaluated by comparing their execution speeds.

[0040] According to one embodiment of this disclosure, a set of all available mutation strategies is maintained. The effectiveness of each mutation strategy in exploring new paths during the execution of the target program is evaluated. The frequency of strategy-triggered crashes and the efficiency of strategy execution are assessed. Based on the evaluation results, an initial weight is assigned to each mutation strategy. The initial weight calculation formula for each mutation strategy is as follows:

[0041]

[0042] Among them, P path P represents the score indicating the ability to generate new paths. crash The score representing the frequency of crash triggering, P speed The score represents execution efficiency, where α, β, and γ are the weighting coefficients for each dimension, and the Total Weight Factor is the overall weighting factor for all strategies. Strategies with higher scores receive higher weights and are therefore executed more frequently in subsequent scheduling.

[0043] To avoid long-term weight locking, even if a strategy performs well, its weight may gradually decrease over time, encouraging the system to try new strategies. A dynamic exponential decay mechanism is used to adjust the initial weights of each mutated strategy, selecting the best-performing strategy to enter the actual scheduling phase first. This decay mechanism means that even if a strategy performs well at a certain stage, its weight will gradually decrease, avoiding over-reliance on a single strategy and thus providing room for the promotion of other new strategies. After multiple rounds of pre-testing, the weights of each strategy are dynamically adjusted based on the comprehensive evaluation results and the decay mechanism. Dynamic adjustment has two key elements: the promotion of new strategies and the rollback of old strategies. If a new strategy performs well in the initial training phase, it will gradually gain a higher weight through dynamic decay and enter the next testing phase. If a strategy performs poorly for a period of time or fails to introduce new vulnerability paths, its weight will gradually decrease, and it may even be eliminated, preventing ineffective strategies from wasting testing resources.

[0044] Then in Figure 2 In frame S204, the scheduling node allocates parallel test tasks among multiple test nodes according to the initial weights and priorities, and receives test instance feedback.

[0045] When assigning tasks, the scheduling node considers factors such as the load, performance, and task complexity of each test node to ensure that each test node can handle an appropriate task. Each test node generates test cases according to the assigned mutation strategy and tests the target program. During test execution, the test nodes provide real-time feedback on the execution results to the scheduling node. The feedback information includes: the coverage of the generated test cases (such as code coverage, path coverage, etc.), the validity of the execution results (whether new vulnerabilities or errors were found), and difficulties or performance bottlenecks encountered during execution (such as excessive resource consumption, redundancy of test cases, etc.).

[0046] Subsequently Figure 2 In frame S206, during the parallel execution of test tasks, the scheduling node dynamically adjusts the strategy weights and task allocation based on the feedback from the test instances.

[0047] The core objectives of dynamic policy reallocation include global optimization. By dynamically adjusting the execution order and weight of mutation policies at each stage, it optimizes overall test coverage, ensuring that test instances can efficiently explore and discover vulnerabilities at different stages. During execution, it avoids the continuous execution of certain policies on certain test instances, resulting in redundant test results, especially duplicate paths and invalid inputs between test instances. As testing progresses, the behavior of the program may change, and some policies may become ineffective or more effective. Dynamic policy reallocation allows the system to better adapt to these changes.

[0048] According to one embodiment of this disclosure, the execution process of fuzz testing of a target program can be divided into multiple stages, including an initial exploration stage, a deep coverage stage, a vulnerability discovery stage, and a stability verification stage, and a task objective is set for each stage. A corresponding mutation strategy and its weight are assigned according to the task objective of each stage.

[0049] For example, the primary objective of the initial exploration phase is to cover a wide range of paths and quickly collect various program input data. At this stage, mutation strategies should primarily employ exploratory approaches, triggering as many different code paths as possible to obtain as much path information as possible. Once the initial exploration phase is complete, the system enters the deep coverage phase. In this phase, the goal is to increase the depth of path coverage, delving into complex control flow paths and branches. At this point, mutation strategies should focus on activating complex paths, such as deep structural mutations and boundary condition mutations. After deep coverage, the system enters the vulnerability discovery phase, focusing on finding security vulnerabilities in the program, such as buffer overflows, null pointer references, and integer overflows. At this stage, mutation strategies are selected based on program type, known vulnerability characteristics, and other information, prioritizing mutation types that are likely to trigger vulnerabilities. The stability verification phase primarily verifies whether the vulnerabilities discovered during testing are stable and reliable, reducing redundant and ineffective mutation strategies, and focusing on verifying and reproducing the discovered vulnerabilities.

[0050] Therefore, each stage has its most suitable mutation strategy. The mapping between strategies and stages ensures that appropriate mutation strategies are selected for different stages. For example, the initial stage uses a wide range of mutation strategies, such as random mutation and fuzzy input, focusing on covering different paths and testing different input combinations. The deep coverage stage selects more precise and targeted mutation strategies, such as structural mutation, boundary condition mutation, and conditional mutation, focusing on exploring complex paths and boundary cases. The vulnerability discovery stage selects mutation strategies focused on vulnerability discovery, such as overflow mutation, integer overflow mutation, and memory access error mutation, using known vulnerability patterns for targeted testing. At each stage, strategies are prioritized to ensure that the strategy most suitable for the current stage is executed first.

[0051] To ensure the flexibility and efficiency of the fuzzing process, switching conditions can be defined between different testing phases. These conditions include time thresholds, coverage saturation, the number of vulnerabilities of a specific type discovered, and the stability of the input queue. When switching phases, the decision to switch to the next phase is made based on factors such as the test results of the current phase, the achievement of objectives, and time constraints, ensuring that each phase is activated at the appropriate time and avoiding ineffective testing.

[0052] For example, the system can be programmed to automatically switch to the deep coverage phase after running for X hours in the initial exploration phase. If no new code coverage is found within a certain period (e.g., Y minutes), the system can consider the goal of the initial exploration phase achieved and switch to the deep coverage phase. If enough vulnerabilities of a specific type are found in a certain phase (e.g., 10 buffer overflow vulnerabilities), the system can trigger a switch to the vulnerability discovery phase. If the samples in the input queue do not change significantly within a certain period, or if few new input combinations are found, the system will consider the goal of the current phase to be largely achieved and proceed to the next phase.

[0053] Within each phase, strategy weights or priorities are adjusted based on strategy performance feedback from test instances. Specifically, the execution results of each mutation strategy are continuously monitored, evaluating its performance in path generation, crash triggering, and execution speed. A sliding window model is used to evaluate the performance of the current strategy combination, and based on the evaluation results, a proportional scheduling or strategy elimination strategy is used to allocate the weight of each strategy. At the end of each test cycle, the scheduling node updates the weights of each strategy according to the latest feedback information and dynamically adjusts the proportion of strategies in the strategy pool based on performance within the window. For example, if most basic paths have been discovered in the initial exploration phase, the weights of some simple mutation strategies are reduced, while the proportion of deep mutation strategies is increased. If a certain mutation strategy is effective in the early stages of the program but may trigger many irrelevant crashes or excessive path testing in the deeper stages, the system will adjust the weight of that strategy to reduce its frequency of occurrence and ensure the effectiveness of the test.

[0054] To prevent certain strategies from being completely eliminated in the short term due to poor performance, a minimum weight threshold can be set. Even if a strategy performs poorly in a certain phase, its weight will not drop to zero, ensuring that each strategy has the opportunity to be retested in subsequent phases. If a strategy consistently fails to produce effective test results over multiple periods, it can be penalized, such as by temporarily removing it or increasing its weight decay rate. This prevents the inefficiency of certain strategies from having a long-term impact on the testing process. By reinforcing high-performing new strategies, strategy weight locking can be avoided, ensuring that the most effective strategy can be flexibly selected during testing.

[0055] Finally, in box S208, the test cases generated by each test node are evaluated for differences, new valid samples are extracted, and the valid samples are deduplicated and synchronized to all test nodes.

[0056] To avoid test instances getting bogged down in redundant test paths, test samples can be periodically synchronized to optimize test coverage and enhance the depth and breadth of test results. For example, a periodic synchronization thread can be set up to periodically execute sample synchronization tasks. The scheduling period of the synchronization thread can be set according to actual needs, such as triggering synchronization at regular intervals or after a certain number of test cases are executed. This scheduling mechanism ensures that all test instances share data at the same time, avoiding the generation of similar and redundant test cases after test instances have run independently for a long period.

[0057] Each test node generates a batch of test cases during fuzz testing. To evaluate the effectiveness and novelty of these test cases, new effective samples can be selected based on two criteria: path difference and code coverage improvement. These effective samples indicate that the test cases bring new coverage to the program and provide valuable input for subsequent in-depth exploration. Path difference refers to the degree to which the code path triggered by a test case differs from the paths triggered by previous test cases; test cases with significant path difference can be considered new utility samples. Code coverage improvement measures the improvement in code coverage compared to existing test cases; the greater the code coverage improvement, the more effective the test case. New effective samples can cover code areas in the program that have not yet been touched by other test cases.

[0058] The extracted valid samples are compared with the central deduplication database to remove duplicates, and then broadcast to all test nodes. The central deduplication database is a centralized storage place for generated test cases. A unique identifier can be used to compare the path and coverage of a valid sample with existing samples stored in the central database to determine whether the current sample has been covered or merged by samples generated by other nodes. If the new valid sample has not been covered or merged, it is distributed to each test node through a distributed message queue or broadcast mechanism to continue executing the test task.

[0059] By comparing the differences between these new samples and existing samples, duplication of existing samples is avoided. If the coverage area of ​​a new sample overlaps with that of an existing sample, the new sample is considered redundant and does not require further propagation. Unmerged samples are broadcast to all test instances, further driving in-depth exploration. Each test instance receives unique test cases from other instances, thus avoiding local duplication of tests. All test instances can synchronously update their test cases, maximizing global coverage and stimulating more unexplored code paths. After a new sample is broadcast to each test instance, each test instance continues to execute new test cases, thereby exploring new code paths. This synchronization mechanism ensures information sharing and resource sharing among test instances, not only improving test case coverage but also enabling the system to be fully explored in both breadth and depth.

[0060] In summary, the parallel fuzzing method and system based on dynamic adjustment of mutation strategies according to embodiments of this disclosure, by introducing multi-instance parallel testing and optimizing the scheduling mutation strategy, maximizes the testing effect and efficiency of each instance. During the testing process, the testing strategy and resource allocation can be optimized and adjusted based on feedback information from the test results, ensuring the dynamic adaptability of the testing process. By evaluating the differences in test cases generated at each test node, new, uncovered, and valid samples can be effectively extracted, avoiding testing of redundant paths and thus expanding the test coverage.

[0061] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatuses and methods according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0062] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, the “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

[0063] Further aspects and scope of adaptation become apparent from the description provided herein. It should be understood that various aspects of this application may be implemented individually or in combination with one or more other aspects. It should also be understood that the descriptions and specific embodiments herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0064] Several embodiments of this disclosure have been described in detail above. However, it is obvious that those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. The scope of protection of this disclosure is defined by the appended claims.

Claims

1. A parallel fuzzing method based on dynamic adjustment of mutation strategy, adapted to be executed in a parallel fuzzing system based on dynamic adjustment of mutation strategy, the system adopting a master-slave architecture, comprising one scheduling node and multiple test nodes, the scheduling node being built-in with a scheduling engine, a scheduling model and a feedback data interface, for scheduling fuzzing tasks in parallel, distributing mutation strategies to each test node, monitoring the execution status of each test node in real time, collecting feedback information, and dynamically adjusting the distribution of test strategies according to the feedback information; the multiple test nodes being built-in with data receiving and feedback interfaces and an execution engine, for executing fuzzing tasks according to the mutation strategies distributed by the scheduling node, generating test cases, and feeding back the execution results to the scheduling node, the scheduling engine being responsible for scheduling different test tasks and adjusting the execution strategy according to the feedback; The scheduling model is responsible for defining the selection of scheduling strategies and algorithms, including strategy scheduling algorithm library, model parameters and external interface standard encapsulation; The feedback interface is used to receive feedback data returned from each test node, so that the scheduling engine dynamically adjusts the strategy weight of each test case according to the feedback data, and the execution engine supports user customization of the plug-in fuzzy engine according to requirements, the handle part in the execution engine is connected with the scheduling control instruction, and is responsible for transmitting the control instruction issued by the scheduling engine to the specific execution task, and the method comprises: Initializing and training multiple mutation strategies, and assigning an initial weight and priority to each mutation strategy according to the execution effect of the strategy on the target program, wherein the multiple mutation strategies include bit flipping, magic number byte injection and structure-aware mutation; the multiple mutation strategies are initialized and trained, the new path generation capability, crash triggering frequency and execution speed of each mutation strategy in the execution process of the target program are evaluated, and an initial weight is assigned to each mutation strategy according to the evaluation result; the initial weight of each mutation strategy is adjusted by using a dynamic exponential decay mechanism, and the best strategy is selected to enter the actual scheduling stage first; The scheduling node distributes parallel test tasks among the multiple test nodes according to the initial weight and priority, and receives test instance feedback; During the parallel execution of the test tasks, the scheduling node dynamically adjusts the strategy weight and task distribution according to the test instance feedback; and Differential evaluation is performed on the test cases generated by each test node, new effective samples are extracted, and the effective samples are synchronized to all test nodes after deduplication.

2. The parallel fuzzing method based on dynamic adjustment of mutation strategies according to claim 1, characterized in that, The initial weight calculation formula is: ； where P path is the score representing the new path generation capability, P crash is the score representing the crash trigger frequency, P speed is the score representing the execution efficiency, and a, b, g are the weight coefficients of each dimension, and Total Weight Factor is the total weight factor of all strategies.

3. The method of claim 1, wherein the method further comprises: During the parallel execution of the test tasks, the scheduling node dynamically adjusts the strategy weight and task distribution according to the test instance feedback, which comprises: Dividing the execution process of the target program fuzzy testing into multiple stages, including an initial exploration stage, a deep coverage stage, a vulnerability mining stage and a stability verification stage, and setting the task objectives of each stage; According to the task objectives of each stage, the corresponding mutation strategies and their weights are allocated; Defining switching conditions between different test stages, the switching conditions include time threshold, coverage saturation, number of discovered specific type vulnerabilities and stability of input queue, and the test stage is selected according to the switching conditions; and In each stage, the strategy weight or priority is adjusted according to the strategy performance of the test instance feedback.

4. The parallel fuzzing method based on dynamic adjustment of mutation strategies according to claim 3, characterized in that, The strategy weight or priority is adjusted according to the strategy performance of the test instance feedback in each stage, which comprises: Continuously monitoring the execution results of each mutation strategy, and evaluating its path generation, crash triggering and execution speed; Using a sliding window model to evaluate the performance of the current strategy combination, based on the evaluation result of the strategy performance, the weight of each strategy is allocated by using proportional scheduling or strategy elimination strategy; and At the end of each sliding window update period, the strategy combination of the current stage is adjusted according to the weight update of the strategy.

5. The method of claim 1, wherein the method further comprises: The difference evaluation is performed on the test cases generated by each test node, new effective samples are extracted, and the effective samples are synchronized to all test nodes after deduplication, including: Periodic sample synchronization tasks are performed by setting a periodic synchronization thread to collect test cases generated by multiple test nodes; New effective samples are filtered according to path difference and code coverage improvement of different test instances; and The extracted effective samples are compared with a central deduplication library after deduplication, and then broadcast to all test nodes.

6. The method of claim 5, wherein the method further comprises: The extracted effective samples are compared with a central deduplication library after deduplication, and then broadcast to all test nodes, including: The path and coverage of the effective samples and the existing samples stored in the central deduplication library are compared through unique identifiers to determine whether the current samples have been covered or merged by samples generated by other nodes; If the new effective samples are not covered or merged, the samples are distributed to each test node through a distributed message queue or a broadcast mechanism to continue the test task.

Images