Method and apparatus for multi-peripheral register interaction protocol-aware firmware fuzzing

Abstract

The application discloses a kind of multi-peripheral register interaction protocol perception's firmware fuzz testing method and equipment, it is related to firmware test technical field, method includes: in the process of carrying out fuzzy test to firmware, determine the multiple execution rounds of the firmware that triggers new code coverage;Multiple execution rounds each corresponding peripheral register access sequence is obtained;According to multiple peripheral register access sequence, frequent co-occurrence input stream sub-sequence is mined, wherein each input stream corresponds to a peripheral register;Select target sub-sequence in frequent co-occurrence input stream sub-sequence, simultaneously carry out variation to multiple input streams in target sub-sequence;Based on the input stream after variation, execute firmware, carry out fuzzy test to firmware.The application improves the code coverage of firmware fuzzy test while guaranteeing the efficiency of fuzzy test, and then increases the possibility of discovering more crashes and potential security vulnerabilities.

Description

Technical Field

[0001] This invention relates to the field of firmware testing technology, and in particular to a firmware fuzzy testing method and device that is aware of multi-peripheral register interaction protocol. Background Technology

[0002] Embedded systems are widely used in safety-critical scenarios such as aerospace, serving as core components of critical infrastructure and safety-critical equipment for space applications. Their firmware operating environment is highly hardware-dependent and typically deployed in environments with limited computing resources. Many embedded firmware programs run on stripped-down lightweight operating systems or bare-metal environments, rather than fully functional general-purpose operating systems. This difference makes it difficult to directly apply many security mechanisms mature in general-purpose systems, significantly increasing security risks. Once vulnerabilities in the firmware are exploited by attackers, they can lead to serious personal and property losses. Therefore, utilizing automated testing methods during the development and testing phase to promptly identify and address vulnerabilities in embedded firmware will effectively reduce security risks during the operational phase of embedded systems.

[0003] Fuzzing is a common automated testing method that effectively discovers potential vulnerabilities by generating mutated inputs and monitoring abnormal program behavior. However, firmware fuzzing needs to consider factors such as hardware interaction, and coupled with the aforementioned issues in the embedded system operating environment, general-purpose fuzzing tools that rely on numerous system calls are difficult to apply to embedded environments, significantly increasing the difficulty of embedded firmware fuzzing. To address these issues, automated firmware remanufacturing has become a common approach, enabling firmware running on different hardware platforms to run in a general-purpose simulator, thus making firmware fuzzing possible. In recent years, some work has emerged that adapts traditional fuzzing file input paradigms to fit structured firmware inputs by dividing the input into multiple independent input streams, each corresponding to a peripheral register access context or peripheral register. This input representation more closely resembles how firmware consumes peripheral input data during execution. Building on this, firmware fuzzers such as Hoedur use mutation operators such as deleting values, inserting values, modifying values, applying offsets to values, flipping specific locations, randomly swapping values, copying a segment of values ​​from other input streams, and using values ​​from a dictionary to mutate a single input stream during the mutation phase. In each round of fuzzing test loop, they switch between random selection and selection methods based on Thompson sampling with a certain probability, select an input stream as the mutation target, and then perform mutation.

[0004] However, the existing firmware fuzzers mentioned above only perform mutation operations on a single input stream, without considering the interaction relationships between multiple input streams, i.e., without considering the interaction protocols between multiple peripheral registers. For example... Figure 1As shown, some code blocks in the firmware require the combined effects of the values ​​of multiple peripheral registers to be triggered. If an unrelated single input stream is selected for mutation each time, such code blocks are difficult to trigger. This results in the fuzzer lacking an understanding of the interaction protocol between multiple peripheral registers, affecting the code coverage capability of the firmware fuzzer and limiting the number of vulnerabilities that the fuzzer can discover.

[0005] Therefore, a firmware fuzzing method is needed that can be aware of the interaction protocol between multiple peripheral registers. During the fuzzing process, firmware execution records that trigger new code overlays are dynamically collected, the history of firmware access to peripheral registers is analyzed, frequently co-occurring peripheral register subsequences are extracted, and the peripheral register input values ​​are co-mutated to improve the ability to explore deep code blocks that require multiple peripheral inputs to be triggered simultaneously. Summary of the Invention

[0006] This invention aims to address the shortcomings of existing technologies, specifically providing a firmware fuzzy testing method and device for multi-peripheral register interaction protocol awareness, as detailed below: 1) In a first aspect, the present invention provides a firmware fuzzy testing method for multi-peripheral register interaction protocol awareness, the specific technical solution of which is as follows: During the fuzzing process of the firmware, multiple execution rounds of the firmware that trigger new code overwriting are identified; Obtain the peripheral register access sequence corresponding to each of the multiple execution rounds; Based on multiple peripheral register access sequences, frequently co-occurring input stream subsequences are mined, where each input stream corresponds to a peripheral register; Select a target subsequence from the frequently co-occurring input stream subsequences, and simultaneously mutate multiple input streams in the target subsequence; Firmware is executed based on the mutated input stream, and fuzz testing is performed on the firmware.

[0007] The beneficial effects of the firmware fuzz testing method with multi-peripheral register interaction protocol awareness provided by this invention are as follows: Compared to existing firmware fuzzers that randomly select a single input stream for mutation in each fuzzing cycle and fail to consider the interaction protocols between multiple peripheral registers, this technical solution identifies multiple execution cycles that trigger new code coverage, obtains the access sequences of multiple peripheral registers corresponding to these execution cycles, and mines frequently co-occurring input stream subsequences to perceive the implicit cooperative interaction relationships between multiple peripheral registers. Based on this, a target subsequence is selected, and mutation operations are simultaneously applied to multiple input streams within it, ensuring that the mutated input streams meet the conditions for triggering code blocks that require the combined action of multiple peripheral register values. This effectively explores deep code regions that are difficult to cover with existing technologies. This multi-stream cooperative mutation approach avoids exhaustive probing of multiple peripheral register input combinations, focusing mutation operations on input stream combinations that have been proven to have a cooperative effect in execution history. While maintaining fuzzing efficiency, it improves the code coverage of firmware fuzzing, thereby increasing the likelihood of discovering more crashes and potential security vulnerabilities.

[0008] Based on the above scheme, the firmware fuzzy testing method of the present invention with multi-peripheral register interaction protocol awareness can be further improved as follows.

[0009] Furthermore, the peripheral register access sequences corresponding to each of the multiple execution rounds are obtained, including: In each execution round of fuzz testing of the firmware, the input stream access sequence formed by the firmware accessing peripheral registers is recorded; a sliding window is used to maintain the input stream access sequence. When the number of execution rounds that successfully trigger new code coverage reaches a preset threshold, multiple peripheral register access sequences are obtained based on the input stream access sequence recorded in the most recent execution round.

[0010] The beneficial effects of adopting the above-mentioned further scheme are as follows: By recording the input stream access sequences formed by the firmware accessing peripheral registers in each execution round of firmware fuzzing, and maintaining these input stream access sequences using a sliding window, when the number of execution rounds that successfully trigger new code coverage reaches a preset threshold, multiple peripheral register access sequences are obtained based on the input stream access sequences recorded in the most recent execution round. This ensures that the dataset relied upon for subsequent mining maintains a high degree of relevance to the latest exploration direction, while avoiding state explosion and infinite growth in computational overhead caused by retaining all historical sequences. The first-in-first-out characteristic of the sliding window ensures that only access sequences that have recently successfully broadened the code coverage boundary are included in the analysis, thereby improving the timeliness and accuracy of extracting frequently co-occurring input stream subsequences from these sequences, and providing a real-time, efficient, and structured data foundation for multi-stream collaborative mutation strategies.

[0011] Furthermore, based on multiple peripheral register access sequences, frequently co-occurring input flow subsequences are mined, including: modeling multiple peripheral register access sequences as a transaction database, wherein each peripheral register access sequence corresponds to a transaction in the transaction database, and the transaction contains the input context corresponding to the peripheral register accessed in the corresponding execution round; scanning the transaction database using a frequent pattern tree algorithm to mine input flow subsequences with support greater than or equal to the minimum support as frequently co-occurring input flow subsequences, wherein the support represents the proportion of transactions containing input flow subsequences in the transaction database.

[0012] The beneficial effects of adopting the above-mentioned further scheme are as follows: By modeling multiple peripheral register access sequences as a transaction database, the peripheral register access history in each execution round that triggers new code coverage is structured into transactions that can be mined for frequent patterns. The input context contained in each transaction accurately reflects the set of peripheral registers that are commonly accessed in that round. By using the frequent pattern tree algorithm to scan the transaction database, only two complete scans are needed to mine the input flow subsequences with support greater than or equal to the minimum support, without generating a large number of candidate options, avoiding the high computational overhead of the Apriori algorithm, and ensuring the execution efficiency of fuzzing. The frequently co-occurring input flow subsequences obtained reveal the implicit cooperative access patterns between multiple peripheral registers, providing a statistically based candidate set of peripheral register combinations for subsequent multi-flow cooperative mutation strategies, enabling mutation operations to focus on peripheral register groups that have been proven to have interactive relationships by execution history.

[0013] Furthermore, a target subsequence is selected from frequently co-occurring input stream subsequences, and multiple input streams in the target subsequence are simultaneously mutated. This includes: in each round of fuzz testing, determining whether to enable a multi-stream mutation strategy with a preset probability; when the multi-stream mutation strategy is enabled, each input stream subsequence in the frequently co-occurring input stream subsequences is modeled as an arm of a multi-armed gambling machine, and a confidence upper bound algorithm is used to select a target subsequence from the frequently co-occurring input stream subsequences, and mutation operations are simultaneously applied to all input streams in the target subsequence; when the multi-stream mutation strategy is not enabled, a single input stream mutation strategy is used to select a single input stream for mutation; after the mutation operation is performed, firmware is executed based on the mutated input stream. When the multi-stream mutation strategy is enabled and the mutated input stream triggers new code overwriting, a positive reward is assigned to the arm corresponding to the input stream subsequence selected in this mutation, otherwise a negative reward is assigned, and the reward estimate in the confidence upper bound algorithm is updated.

[0014] The beneficial effects of adopting the above-mentioned further scheme are as follows: By enabling a multi-stream mutation strategy with a preset probability in each round of fuzzing, and modeling frequently co-occurring input stream subsequences as the arms of a multi-armed gambling machine, the target subsequence is selected using a confidence upper bound algorithm, achieving intelligent scheduling of cooperative mutation opportunities for multiple input streams. The confidence upper bound algorithm automatically balances the utilization of historical high-yield sequences with the exploration of insufficiently tried sequences when selecting the target subsequence, avoiding the risk of getting trapped in local optima or missing better sequences. Simultaneously applying mutation operations to all input streams in the target subsequence allows the input data corresponding to multiple peripheral registers to change collaboratively, satisfying the constraints of code blocks that require the combined action of multiple peripheral inputs to trigger. By assigning positive or negative rewards to the corresponding arms based on whether new code coverage is triggered and updating the reward estimate, the confidence upper bound algorithm's value assessment of each input stream subsequence becomes increasingly accurate as fuzzing continues, guiding the mutation strategy to continuously evolve towards improving code coverage.

[0015] 2) Secondly, the present invention also provides a firmware fuzzy testing system with multi-peripheral register interaction protocol awareness, the specific technical solution of which is as follows: The system includes a determination module, an acquisition module, a mining module, a mutation module, and a fuzzing module. The determination module is used to determine multiple execution rounds of the firmware that trigger new code coverage during fuzzing. The acquisition module is used to acquire the peripheral register access sequences corresponding to each of the multiple execution rounds. The mining module is used to mine frequently co-occurring input stream subsequences based on the multiple peripheral register access sequences, where each input stream corresponds to one peripheral register. The mutation module is used to select target subsequences from the frequently co-occurring input stream subsequences and mutate multiple input streams in the target subsequence simultaneously. The fuzzing module is used to execute the firmware based on the mutated input streams and perform fuzzing on the firmware.

[0016] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor, so as to enable the electronic device to implement any of the above-mentioned firmware fuzzy testing methods for awareness of multiple peripheral register interaction protocols.

[0017] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the firmware fuzzy testing method for sensing any of the above-mentioned multiple peripheral register interaction protocols.

[0018] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is an example of a code block that cannot be triggered in existing technologies; Figure 2 This is one of the flowcharts of a firmware fuzz testing method with multi-peripheral register interaction protocol awareness according to an embodiment of the present invention; Figure 3 This is a second flowchart illustrating a firmware fuzzy testing method with multi-peripheral register interaction protocol awareness according to an embodiment of the present invention. Figure 4 Example of the process of building an FP-Tree; Figure 5 Here is an example of mining frequent itemsets from an FP-Tree; Figure 6 This is a flowchart illustrating a firmware fuzzy testing system with multi-peripheral register interaction protocol awareness according to an embodiment of the present invention. Detailed Implementation

[0020] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0021] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0022] like Figure 2 As shown in the figure, a firmware fuzz testing method for multi-peripheral register interaction protocol awareness according to an embodiment of the present invention includes the following steps: S1. During the fuzzing process of the firmware, determine the multiple execution rounds of the firmware that trigger new code overwriting. The specific implementation process is as follows: S10. Initiate fuzzing of the firmware, generating and maintaining a set to record execution rounds that trigger new code coverage. This set is initialized to an empty set upon startup. Fuzzing is a cyclical process. In each execution round, the fuzzer generates or mutates a set of test inputs and injects them as stimulus data into the firmware's runtime environment to drive firmware execution. The test input is a set of continuous byte data. In the existing multi-stream input paradigm, this byte data is logically divided into multiple independent input streams, each corresponding to and serving a peripheral register access context or a specific peripheral register. The firmware execution process is essentially the process of consuming the data carried by these input streams according to its internally preset logic.

[0023] S11. In an execution round, after the firmware finishes execution, it is necessary to capture and determine whether this round of execution triggered new code coverage. Code coverage is a core metric for measuring the extent of fuzzing exploration; it reflects which code blocks or branches of the firmware have been executed by the test input. In the context of fuzzing tools, a lightweight instrumentation technique is typically used to collect code coverage information. Specifically, when the firmware's binary code is loaded, some stub code is pre-inserted to record control flow transfers. When the firmware executes and triggers these stub codes, a coverage bitmap is generated. Each bit or each counting unit in the bitmap corresponds to the hit status or hit count of a basic block, edge, or branch in the firmware image. After an execution round ends, the fuzzer reads the coverage bitmap generated in this round and compares it with a global coverage bitmap that maintains the cumulative maximum coverage reached by all execution rounds up to the present. If the current round of the overlay bitmap records some bits that have not appeared in the global overlay bitmap, or if the count unit in some global overlay bitmap is updated to a higher hit count after this round of execution, then it can be determined that the execution round has triggered new code overlay.

[0024] S12. When it is determined that an execution round has triggered new code coverage, the identifier information of that execution round, along with the specific information of the new coverage discovered in that execution round, is added to the set in step S10 to record and identify these execution rounds with special value. This set can be maintained using a first-in-first-out queue or a sliding window-like data structure to limit its size and focus on the most recent fuzzing history. Specifically, a preset threshold can be set, for example, 50. When the number of execution rounds that have triggered new code coverage recorded in the set reaches this preset threshold, if a new execution round that has triggered new code coverage needs to be added, the oldest execution round is removed from the set, and then the new execution round is added, thus keeping the number of rounds in the set constant at the preset threshold. Through this dynamic maintenance and updating method, at any point in the fuzzing process, the set determines multiple execution rounds of the firmware that have triggered new code coverage for subsequent analysis in the current stage. These multiple execution rounds represent the most recent batch of execution instances that have successfully broadened code coverage over time. They provide valuable analytical samples for capturing the latest dynamics of firmware behavior, especially for mining multi-peripheral register interaction protocols.

[0025] Fuzzing is an automated software testing method. This method continuously inputs a large amount of randomly generated or rule-based variational unexpected data into the target program (firmware in this technical solution), and monitors in real time whether the program exhibits abnormal behavior during operation, such as crashes or unresponsiveness, thereby discovering potential security vulnerabilities or functional defects. In the field of embedded firmware, which interacts closely with hardware, directly applying general-purpose fuzzing tools is challenging. Therefore, this technical solution relies on automatic firmware remanufacturing technology, enabling the firmware to execute and undergo fuzzing testing in a simulator.

[0026] Code coverage is a software testing metric used to quantify the extent to which the source code or binary code of a target program is actually executed during testing. In the context of this technical solution, it specifically refers to which basic blocks, control flow paths, or branches of the firmware's binary code are touched by test inputs in each execution round of fuzzing. Obtaining code coverage information is the cornerstone of implementing feedback-driven fuzzing, enabling the fuzzer to identify which test inputs lead to new, unexplored program states, thus preserving these inputs and performing more targeted mutations.

[0027] In this context, an execution round refers to a complete and independent minimum test unit within a fuzzing loop. An execution round includes the following processes: the fuzzer generates or mutates a new set of test inputs according to a certain strategy; this set of test inputs is sent to the simulator to execute the firmware; the firmware runs until it terminates, reaches a preset timeout limit, or triggers an exception; the fuzzer collects and analyzes the metadata generated in this execution round, such as code coverage information and hardware access traces; finally, based on the analysis results, the fuzzer updates its internal state and strategy to prepare for the next execution round.

[0028] New code coverage refers to a firmware execution in an execution round, driven by the test data input in that round, covering code regions that had not been touched by any previous execution rounds. This concept is achieved by comparing the coverage bitmap generated in this round with the global coverage bitmap. New code coverage is considered triggered when a new basic block is hit, or when a basic block on an existing path is hit with a new combination of hits. An execution round that triggers new code coverage signifies that the test input in that round has successfully explored a completely new state space within the firmware, providing invaluable guidance for fuzz testing to delve deeper into logical regions.

[0029] S2. Obtain the peripheral register access sequence corresponding to each of the multiple execution rounds, specifically including: S20. In each execution round of fuzz testing of the firmware, record the input stream access sequence formed by the firmware accessing peripheral registers. The specific implementation process is as follows: S200. At the beginning of each execution round, a data structure needs to be initialized to store the access trajectory of this execution round. This data structure will be used to record the input stream access sequence formed by the firmware accessing peripheral registers. The input stream access sequence is an ordered list, and each element represents a data consumption behavior of the firmware on the peripheral registers.

[0030] S201. During firmware execution, instrumentation code or hook functions that interact with the simulator environment capture every peripheral register read operation in real time. When the firmware executes an instruction involving reading a peripheral register value, the simulator intercepts this operation and obtains an input context corresponding to that register. An input context is a set of information containing attributes such as the address of the corresponding peripheral register and the type of input value expected by that register. This input context is essentially a logical identifier for a specific input stream in the fuzzing input data.

[0031] S202. The input context obtained in the above interception operation is appended to the initialized data structure sequentially according to the time sequence of the interception. In this way, as the firmware instructions are executed one by one, each read access to a peripheral register is transformed into an input context record, which is then concatenated to form a complete input stream access sequence at the end of an execution round. This sequence fully depicts how the firmware, according to its internal control flow logic, sequentially and selectively requests data from various peripheral registers during this execution round.

[0032] S21. A sliding window is used to maintain the input stream access sequence. When the number of execution rounds that successfully trigger new code coverage reaches a preset threshold, multiple peripheral register access sequences are obtained based on the input stream access sequence recorded in the most recent execution round. The specific implementation process is as follows: S210. Maintain a global sliding window. This sliding window is a logical container with a fixed size, used to store the input stream access sequences corresponding to the most recent execution rounds that were determined to have triggered new code overriding. The size of the sliding window is defined by a preset threshold, for example, the preset threshold can be set to 50. The sliding window is managed according to the first-in, first-out (FIFO) principle.

[0033] S211. After each execution round, when the determination mechanism described in step S1 identifies that a new code overwrite has been triggered in this execution round, the input stream access sequence generated in step S20 for this execution round is placed into the aforementioned sliding window. The placement process requires judgment. If the number of existing input stream access sequences in the current sliding window has not yet reached a preset threshold, the new input stream access sequence is directly added. If the number of existing input stream access sequences in the current sliding window is already equal to the preset threshold, a removal operation is first performed to delete the earliest (i.e., the first input stream access sequence to enter the window) from the sliding window, and then the new input stream access sequence representing the execution status of this round is added to the sliding window. Through this continuous placement and removal operation, the sliding window always maintains a batch of input stream access sequences that are closest to the current fuzzing stage in the time dimension, and their total number does not exceed the preset threshold.

[0034] S212. When the frequent sequence mining function needs to be used during fuzzing, all input stream access sequences maintained in the current sliding window are directly read. This set of read input stream access sequences constitutes the multiple peripheral register access sequences required in step S3. This set of sequences is not randomly generated by the firmware, but is strictly selected. Each sequence has independently led to the discovery of an unexplored code region. Therefore, this set of sequences contains strong causal information, reflecting which peripheral registers are always accessed in combination, thereby triggering those hidden, conditionally demanding firmware logics.

[0035] In embedded systems, peripheral registers are data interfaces for various hardware peripherals outside the central processing unit (CPU) core. In a hardware-dependent firmware environment, the firmware does not directly manipulate the physical hardware. Instead, it obtains peripheral status information, receives external input data, or sends control commands to peripherals by reading and writing these registers mapped to specific memory addresses or input / output ports. In firmware remanufacturing scenarios, fuzzing input is not passed to the program as file parameters. Instead, the behavior of peripheral registers is simulated through a simulator, feeding the input data to the operation point when the firmware reads a particular peripheral register.

[0036] The input stream access sequence is a time-ordered list of records. It records the sequential accesses of firmware code to all peripheral registers during a complete firmware execution cycle. Each atomic item in the sequence is not a specific numerical value, but an input context that indicates which type of access was performed to the peripheral register represented by which input stream. This sequence strings together originally discrete register access events into a behavioral trajectory reflecting the firmware's input consumption patterns.

[0037] The input context is a descriptor used to uniquely identify the context of a peripheral register access. An input context contains at least two pieces of information: the address of the peripheral register, used to distinguish different hardware peripheral interfaces; and the type of the input value corresponding to that peripheral register, used to specify the data format or semantics. In the multi-stream fuzzing paradigm, the entire test input generated by the fuzzer is divided into multiple independent input streams, each bound to a specific input context. Therefore, through the input context, the fuzzer can determine which segment of data in which input stream the current firmware read operation corresponds to.

[0038] The sliding window is a dynamic data management technique oriented towards data flow. It sets a fixed-size window that is always anchored to the latest endpoint of the data flow. As new data items arrive, the window slides forward, older data items are removed, and new data items are moved in, thus maintaining a constant and up-to-date number of data items within the window. In this technical solution, the sliding window is used to manage the input flow access sequence corresponding to the execution rounds that trigger new code coverage, ensuring that the data used for data mining and analysis is both timely, reflecting the latest exploration direction of fuzzing, and avoids the unlimited growth of computational and storage overhead caused by retaining all historical data.

[0039] In this context, the peripheral register access sequence and the input stream access sequence are physically represented by the same data structure: a list of input contexts ordered by access sequence. However, their usage differs within the technical context. The input stream access sequence focuses on describing the trajectory record generated in a single execution round. The peripheral register access sequence, on the other hand, is an individual unit within the input data set of the mining algorithm in step S3, following the completion of step S21. It emphasizes that this sequence exists as raw material for analyzing the collaborative interaction patterns between multiple peripheral registers.

[0040] S3. Based on multiple peripheral register access sequences, mine frequently co-occurring input stream subsequences, where each input stream corresponds to a peripheral register, specifically including: S30. Model multiple peripheral register access sequences as a transaction database, where each peripheral register access sequence corresponds to a transaction in the transaction database. The transaction is contained in the input context corresponding to the peripheral register accessed in the corresponding execution round. The specific implementation process is as follows: S300: Obtain multiple peripheral register access sequences obtained after filtering in step S21. These multiple peripheral register access sequences constitute a set of sequences, and each peripheral register access sequence corresponds to a firmware execution round that triggers new code overwriting.

[0041] S301. Create a corresponding data structure for each peripheral register access sequence. In the context of frequent itemset mining, this data structure is called a transaction. The process of creating a transaction involves extracting all input contexts recorded in the peripheral register access sequence, removing redundant input contexts that may exist due to the firmware repeatedly reading the same register in the same execution round, and then using the deduplicated set of input contexts as the set of items contained in the transaction. Here, an input context is an item, which contains information such as the address of the peripheral register and the type of the input value. After this transformation, each peripheral register access sequence is abstracted into a transaction. This transaction no longer cares about the order in which the input contexts are accessed, but only about which input contexts are accessed in the same execution round.

[0042] S302. All transactions derived from peripheral register access sequences are aggregated to form the transaction database D. Formally, the transaction database D is a collection of multiple transactions, where each transaction is a subset of the global item set I. The global item set I is the set of all possible input contexts, where an item represents a specific input context. A transaction represents the set of all input contexts actually accessed in a given execution round. The size of the transaction database, i.e., the total number of transactions it contains, is equal to the number of peripheral register access sequences maintained within the sliding window in step S21. Once the transaction database D is constructed, the fuzzer possesses structured data for subsequent frequent pattern mining calculations.

[0043] S31. The frequent pattern tree algorithm is used to scan the transaction database and mine the input flow subsequences with support greater than or equal to the minimum support as frequently co-occurring input flow subsequences. Here, support represents the proportion of transactions containing input flow subsequences in the transaction database. The specific implementation process is as follows: S310. Set the minimum support threshold. Minimum support is a percentage parameter used to define how frequently an input flow subsequence needs to appear to be considered a frequently co-occurring input flow subsequence. The formal definition of support is: for an input flow subsequence... , , Support on transactional database D The calculation method is to divide the number of transactions containing X by the total number of all transactions in the transaction database D.

[0044] S311. The first stage of executing the frequent pattern tree algorithm involves constructing the frequent pattern tree data structure. The frequent pattern tree consists of three parts: an item header table, a prefix tree, and a node list. The construction process requires two complete scans of the transaction database D. During the first scan of transaction database D, the number of times each single input context in the global item set I appears in all transactions of transaction database D is counted, i.e., the support count of each single item. Single items with support counts lower than the minimum count calculated based on the minimum support threshold are deleted. The remaining single items are sorted according to their support counts from high to low, forming a header list, which is the item header table. During the second scan of transaction database D, each transaction in the transaction database is read in one by one. For each transaction, the items in the transaction are sorted according to the fixed order in the item header table. The sorted item sequence is then inserted one by one into a prefix tree. When inserting a transaction, the tree extends downwards from the root node along the sorted item order. If the node corresponding to the current item already exists as a child node of the current item, increment the count of that child node by 1; otherwise, create a new child node and initialize its count to 1. Simultaneously, each item in the item header table maintains a linked list of nodes, linking the newly created node to the end of the linked list of the corresponding item. Repeat this insertion process until all transactions in the transaction database D have been inserted into the prefix tree, at which point the frequent pattern tree construction is complete.

[0045] S312. The second stage of the frequent pattern tree algorithm involves mining all input flow subsequences with support greater than or equal to the minimum support from the constructed frequent pattern tree. The mining process is recursive, starting from the bottom of the item head list (the most frequent single item with the lowest support) and proceeding upwards. For each item in the item head list, all nodes corresponding to that item in the frequent pattern tree are found along the node list of that item. From each such node, the process traces upwards to the root node; the set of items along each tracing path constitutes a conditional pattern base for that item. The count of each node in the conditional pattern base is set to the count of the corresponding leaf node. All conditional pattern bases are summarized, and nodes with counts below a threshold are deleted, resulting in the conditional frequent pattern tree for that item. Then, the mining method is recursively called on this conditional frequent pattern tree to obtain all frequent item sets containing that item.

[0046] To illustrate this mining process, assume that after scanning the transaction database D, conditional pattern bases related to a certain item d are mined. After summarizing these conditional pattern bases and deleting other items with support counts lower than the required number, the remaining items are: item a appears twice, item b appears three times, and item c appears twice. Then, the frequent 2-itemsets formed by item d and these items can be represented as {a:2, d:2}, {b:3, d:3}, and {c:2, d:2}. In these notations, each of the letters a, b, c, and d represents an item, i.e., an input context, used to identify a specific peripheral register and its input value type. The number after the colon represents the support count, i.e., the total number of transactions in the entire transaction database D that simultaneously contain all items in that item set. The items and their counts within a set of curly braces represent a mined frequent itemset, which in the context of this technical solution is a frequently co-occurring input flow subsequence. Taking {b:3, d:3} as an example, it indicates that the input context corresponding to item b and the input context corresponding to item d both appeared three times in the peripheral register access sequence of all execution rounds that triggered new code overriding. This reveals that the peripheral registers represented by these two input contexts have a cooperative access relationship during firmware execution.

[0047] After obtaining these frequent 2-itemsets, the recursive process continues. The algorithm combines these 2-itemsets to find frequent itemsets containing more items. Through recursive merging, based on the above conditional pattern base, frequent 3-itemsets can be further obtained, such as {a:2, b:2, d:2}, {a:2, c:2, d:2}, and {b:2, c:2, d:2}. Taking the curly braces {a:2, b:2, d:2} as an example, it indicates that the three input contexts, item a, item b, and item d, appear twice in all transactions of the entire transaction database D. The recursive merging continues until no longer itemsets that meet the minimum support threshold can be generated. The longest frequent itemset that can ultimately be obtained from this conditional pattern base is {a:2, b:2, c:2, d:2}, which indicates that the four input contexts appear twice in all transactions.

[0048] All input flow subsequences mined through the above recursive process that satisfy the condition of support greater than or equal to minimum support, regardless of whether they contain 2, 3 or more items, are uniformly included in the set of frequently co-occurring input flow subsequences.

[0049] S313. Output the set of all frequently co-occurring input flow subsequences mined, as the candidate set for the multi-flow mutation strategy in step S4. In practical implementation, to avoid excessive computational resources consumed by frequent sequence mining operations, thus affecting the overall throughput efficiency of fuzzing, the mining process can be executed in parallel in the background using a multi-threaded approach, with a set execution frequency. For example, after the first 50 fuzzing rounds where new coverage is discovered, a frequent sequence mining operation can be triggered every 100 fuzzing rounds where new coverage is discovered.

[0050] The transaction database, typically denoted by D, is a fundamental concept in the field of frequent itemset mining. It is a collection of multiple transactions. In this technical solution, the transaction database D is obtained by modeling and transforming multiple peripheral register access sequences. Each transaction corresponds to one peripheral register access sequence, and the items within a transaction are the input contexts recorded in that access sequence. The transaction database provides a structured data foundation for mining combined access patterns of peripheral registers.

[0051] In this context, a transaction is a record in the transaction database D, which is a subset of the global project set I. In this technical solution, a transaction corresponds to one execution round that triggers new code overwriting. The content of a transaction consists of the input context corresponding to all peripheral registers accessed by the firmware in that round. A transaction expresses the information that during an execution process that causes the firmware to enter a new code region, a specific set of peripheral registers was accessed.

[0052] In this context, an item is the smallest unit of data in frequent itemset mining, typically denoted by the symbol i. In this technical solution, an item represents an input context. The global itemset I is the set of all possible input contexts. Each transaction consists of several items.

[0053] Support is a metric that measures how frequently a set of items appears in a transaction database D. For an input stream subsequence X, its support is defined as the percentage of transactions in the transaction database D that contain X, out of the total number of transactions in D. The formula for calculating support reflects the prevalence of the input stream subsequence across all execution rounds included in the statistics. The support value can be used to determine whether a set of peripheral registers are frequently accessed.

[0054] The support count is an integer value directly calculated during the support calculation process. It represents the total number of transactions in the transaction database D that contain a specific itemset. In the representation of the mining results from the frequent pattern tree algorithm, the number after the colon within the curly braces is the support count. For example, in {b:3, d:3}, the number 3 is the support count for the itemset {b, d}. The support count divided by the total number of transactions in the transaction database D gives the percentage value of support.

[0055] Frequently co-occurring input flow subsequences are those that satisfy the minimum support threshold condition. In the context of this technical solution, such sequences reveal the cooperative interaction relationships between a set of peripheral registers. If a set of input contexts co-occurs in multiple execution rounds that trigger new code coverage with a frequency exceeding the minimum support, it can be considered that the peripheral registers corresponding to these input contexts logically cooperate, and their data needs to coordinate with each other to guide the firmware to execute deeper logic.

[0056] The Frequent Pattern Tree (FP-Tree) algorithm is a method for efficiently mining frequent itemsets. Its processing flow consists of two stages: the first stage constructs a frequent pattern tree, compressing and storing all frequent items in the transaction database D into this tree; the second stage, based on this frequent pattern tree, directly mines all frequent itemsets by recursively generating conditional pattern bases. The FP-Tree algorithm only requires two full scans of the transaction database D, unlike the Apriori algorithm which generates a large number of candidate itemsets, making it superior in terms of both time and space complexity.

[0057] The item header table is a component of the frequent pattern tree data structure. It is a list that records all frequent single items in the transaction database D and their occurrence counts, arranged in descending order of support count. The item header table provides the sorting criteria for items within a transaction when constructing the frequent pattern tree, and provides the entry point for traversal during the mining phase.

[0058] The node linked list is a component of the frequent pattern tree data structure. Each entry in the item header table is associated with a node linked list, which runs horizontally through the entire frequent pattern tree, connecting all nodes representing the same item. The node linked list enables the rapid location of an item within the tree during the mining phase, thus efficiently collecting the conditional pattern base for that item.

[0059] Here, the conditional pattern base refers to the set of prefix paths collected along all paths in the frequent pattern tree, using a specified item as a suffix. The method for generating the conditional pattern base for a given item is as follows: Along the node list of that item, find each node, and then trace upwards from that node to the root node. The subsequence formed by all items along this path constitutes a conditional pattern base. Summarizing all these paths and removing nodes with a support count lower than the target's support count creates the conditional frequent pattern tree for further recursive mining of that item.

[0060] S4. Select the target subsequence from the frequently co-occurring input stream subsequences, and simultaneously mutate multiple input streams in the target subsequence, specifically including: S40. In each round of fuzz testing, determine whether to enable the multi-stream mutation strategy with a preset probability. The specific implementation process is as follows: S400. At the start of the fuzzing loop, a preset probability value is set. This preset probability value is used to control the frequency of calling the multi-stream mutation strategy in each execution round. The preset probability can be set to a fixed ratio based on experience, so that the multi-stream mutation strategy and the single-input-stream mutation strategy can be used in combination for a period of time.

[0061] S401. At the start of each round of fuzz testing and entering the mutation phase, a random number generator produces a uniformly distributed random number between zero and one. The generated random number is compared to a preset probability value. If the random number's value is less than the preset probability, it is determined that a multi-stream mutation strategy is enabled for this round. If the random number's value is greater than or equal to the preset probability, it is determined that a multi-stream mutation strategy is not enabled for this round, and subsequent rounds will revert to a single-input-stream mutation strategy. This probability-based decision-making method allows the fuzzer to automatically switch between two behavioral modes: exploring the cooperative relationships between multiple input streams and fully utilizing mature mutation experience with a single stream.

[0062] S41. When the multi-stream mutation strategy is enabled, each input stream subsequence in the frequently co-occurring input stream subsequences is modeled as an arm of a multi-armed gambling machine. A confidence upper bound algorithm is used to select a target subsequence from the frequently co-occurring input stream subsequences, and mutation operations are applied to all input streams in the target subsequence simultaneously. The specific implementation process is as follows: S410. From the set of frequently co-occurring input flow subsequences output in step S31, obtain all currently available input flow subsequences. Each input flow subsequence is a set containing several input contexts. Each input flow subsequence is abstractly defined as an option; in the context of reinforcement learning, this option is modeled as an arm of a multi-armed gambling machine. When a new arm that has never been selected before appears in the set of frequently co-occurring input flow subsequences, it needs to be initialized by setting its selection count to zero and its cumulative reward value to zero.

[0063] S411. A target subsequence is selected from all arms using a confidence upper bound algorithm. The selection logic of the confidence upper bound algorithm needs to simultaneously consider the utilization of arms with good historical performance and the exploration of unknown arms with fewer historical selections. During the selection process, the algorithm scans each arm and calculates an upper bound evaluation value for each arm. The upper bound evaluation value of an arm consists of the sum of two parts: one part is the current average reward of the arm, reflecting an empirical estimate of the arm's historical performance; the other part is an exploration reward term, the size of which is related to the total number of selections and the number of times the arm itself has been selected. The fewer times an arm has been selected, the larger the exploration reward term, thus giving arms that have not been fully tried a chance to be selected. After all the upper bound evaluation values ​​of all arms have been calculated, the input flow subsequence corresponding to the arm with the largest upper bound evaluation value is selected as the target subsequence.

[0064] S412. After determining the target subsequence, apply mutation operations simultaneously to all input streams contained in the target subsequence. "Apply mutation operations simultaneously" means that in a single round of mutation, no single input stream is modified; instead, every input stream covered by the target subsequence is treated as the object of this mutation. Specific mutation operators can utilize mature operators from existing fuzzing tools that operate on a single stream. For example, operations such as deleting a segment of values, inserting a segment of values, modifying a value, applying an offset to a value, flipping a specific position, randomly swapping the positions of two values, copying a segment of values ​​from another stream, or replacing values ​​using values ​​from a dictionary can be performed on the byte content of each stream. These mutation operations are applied in parallel to all input streams associated with the target subsequence, thereby generating a set of multi-stream test inputs that can change collaboratively.

[0065] When the multi-stream mutation strategy is not enabled, the single input stream mutation strategy is used to select a single input stream for mutation. The specific implementation process is as follows: A single input stream mutation strategy is adopted, which follows the existing stream selection method of firmware fuzzers and does not specially handle the cooperative relationship of multiple streams. In practice, random selection or a selection method based on Thompson sampling can be used to determine one input stream from all available input streams as the target of this mutation. The mutation operation is applied to the selected input stream, and the available mutation operators remain consistent with those mentioned earlier, including deletion, insertion, and modification of values. The remaining input streams that were not selected in this round of fuzz testing remain unchanged and do not participate in this mutation.

[0066] S42. After performing the mutation operation, the firmware is executed based on the mutated input stream. When the multi-stream mutation strategy is enabled and the mutated input stream triggers new code overwriting, a positive reward is assigned to the arm corresponding to the input stream subsequence selected for this mutation; otherwise, a negative reward is assigned, and the reward estimate in the confidence upper bound algorithm is updated. The specific implementation process is as follows: S420: The mutated input stream generated by the multi-stream mutation strategy or single-input-stream mutation strategy in step S41 is used as the test input for this round of fuzzing and sent to the simulator to drive the firmware execution. After the firmware execution is completed, the coverage bitmap generated in this round of execution and the global coverage bitmap are compared according to the same code coverage determination method as in step S1 to determine whether new code coverage has been triggered in this round.

[0067] S421. Based on whether new code coverage is triggered, assign a corresponding reward value to the arm selected for this mutation. If this mutation uses a multi-stream mutation strategy, then the arm selected for this mutation is the arm corresponding to the target subsequence selected in step S41. When new code coverage is triggered, assign a positive reward to the corresponding arm, for example, assign a reward of +1. When new code coverage is not triggered, assign a negative reward to the corresponding arm, for example, assign a reward of zero or negative one.

[0068] S422. After assigning a reward, update the reward estimate associated with that arm in the confidence upper bound algorithm. Specifically, the update includes: increasing the number of times the arm has been selected by one, adding the cumulative reward value of the arm to the reward value assigned in this round, and then recalculating the average reward of the arm. After the update, when this arm is evaluated by the confidence upper bound algorithm in subsequent rounds, it will use the reward estimate information reflecting the latest effectiveness of this mutation. Through this continuous updating, the reward estimates of each arm maintained by the confidence upper bound algorithm will increasingly accurately reflect the true contribution of each input flow subsequence to discovering new code coverage, thereby guiding fuzz testing to select mutation targets more efficiently within a limited testing time and improving overall code coverage.

[0069] The multi-stream mutation strategy is an operational strategy used in the firmware fuzzing mutation phase. Unlike the approach of mutating only one input stream at a time, it treats multiple input streams as a cooperative group, applying mutations to all input streams within the group simultaneously in a single mutation operation. This strategy explores the impact of the interaction behavior between multiple peripheral registers on the firmware execution path by changing the input data corresponding to these registers.

[0070] The single-input-stream mutation strategy is a traditional firmware fuzzing mutation operation strategy. During each mutation, this strategy randomly or selectively selects only one input stream as the mutation target, modifies the data in that input stream, while all other input streams remain unchanged and do not participate in the mutation. This method can effectively explore the data field boundaries and logic of a single peripheral register.

[0071] The multi-armed slot machine is a mathematical model used to describe sequential decision-making problems, originating from probability theory and reinforcement learning. In this model, a decision-maker faces a row of slot machines with multiple levers, each lever being called an arm. Pulling each arm yields a reward with some unknown probability distribution. The decision-maker's goal is to maximize the cumulative total reward over a finite number of pulls by sequentially choosing which arms to pull and observing the rewards obtained. This model is widely used to formalize exploration and exploitation of balance problems.

[0072] The upper bound confidence algorithm, often abbreviated as UCB, is a classic algorithm for solving the multi-armed slot machine problem. Its core idea is that when selecting an arm to pull, instead of directly choosing the arm with the highest estimated average reward, it selects a high-probability confidence interval for the upper bound, calculates the reward upper bound for each arm, and selects the arm with the largest upper bound value. This method uses an exploration term inversely proportional to the number of times an arm is selected to ensure that each arm has a chance to be tried. As the number of trials increases and the confidence interval narrows, the algorithm becomes more inclined to utilize the truly high-yielding arms, thus theoretically minimizing the regret value.

[0073] In the multi-armed gambling machine model, an arm represents an independent option to be chosen, and each choice involves pulling an arm and obtaining a reward. In this technical solution, an arm represents a frequently co-occurring subsequence of input flows. Mapping mutation choices to arm choices allows for intelligent decision-making on mutation targets using algorithms that solve the multi-armed gambling machine problem.

[0074] Positive reward refers to a positive numerical signal given to the decision-maker by the environment after a decision, indicating that the decision has brought about the desired effect. In this technical solution, when a mutation operation based on a certain arm triggers new code overwriting in the firmware, a positive reward is assigned to that arm to strengthen the association between that arm and the good outcome.

[0075] Negative reward refers to a negative or zero numerical signal given to the decision-maker by the environment after a decision, indicating that the decision did not bring about the desired effect. In this technical solution, when a mutation operation based on a certain arm fails to trigger new code overwriting, a negative reward is assigned to that arm to reduce the tendency to continue selecting that arm in the future.

[0076] The reward estimate is a statistic maintained by the confidence upper bound algorithm for each arm, representing the expected reward value of that arm based on historical experience. It is typically represented by the arithmetic mean of all rewards received by that arm. Whenever an arm is selected and receives a new reward, the reward estimate is recalculated and updated, allowing the value judgment of the arm to be dynamically adjusted as testing progresses.

[0077] S5. Execute the firmware based on the mutated input stream, and perform fuzz testing on the firmware. The specific implementation process is as follows: S50. Before each execution round begins, the firmware's binary image needs to be loaded into the simulator, and the simulator environment needs to be initialized. Since embedded firmware runs in a highly hardware-dependent environment, the simulator needs to simulate the hardware peripheral behaviors expected by the firmware. Specifically, the simulator needs to configure virtual hardware resources such as memory mapping, peripheral register address space, and interrupt controllers according to the requirements of firmware remanufacturing technology. These configurations are prerequisites for the firmware to start and run normally in the simulator, ensuring that the fuzzing input data can be correctly read by the firmware through the simulated peripheral register interface.

[0078] S51. After the simulator environment is ready, the mutated input stream generated in step S42 is injected into the simulator's input buffer as test input data. In the multi-stream input fuzzy testing paradigm, the entire test input is logically divided into multiple independent input streams, each bound to a specific peripheral register access context. The injection operation requires accurately placing the data from each input stream onto the memory address or data port mapped to the corresponding peripheral register according to this binding relationship. When the firmware reads a specific peripheral register during subsequent execution, the simulator returns the data from the corresponding input stream to the firmware, thus simulating the behavior of an external device providing data to the firmware in a real hardware environment.

[0079] S52. Start the emulator and begin executing the firmware loaded onto it. During firmware execution, the emulator continuously monitors the firmware's running status. Monitoring includes, but is not limited to, whether the firmware has crashed. Crashes manifest as memory access violations, division by zero operations, illegal instruction execution, or assertion failures. If a crash is detected, the emulator immediately captures the crash scenario information, recording the register states, call stack, and the test input data that caused the crash. Simultaneously, the emulator monitors whether the firmware has entered an infinite loop or exceeded the preset maximum execution time. If the execution time exceeds the preset timeout threshold, the current execution round is forcibly terminated, and that round is marked as timed out. All exception information is recorded in a global crash database or log for vulnerability analysis after fuzzing.

[0080] S53. After firmware execution concludes, regardless of whether the result is a normal exit, a crash, or a timeout, code coverage information generated during this execution round needs to be collected. This step relies on a coverage bitmap generated by instrumentation code pre-inserted into the firmware binary code. The fuzzer reads the current round's coverage bitmap and compares it with a global coverage bitmap that maintains the maximum cumulative coverage across all historical execution rounds. This comparison yields a Boolean result indicating whether the current execution round triggered new code coverage. Triggering new code coverage means that certain code blocks or control flow edges exist in the current round's coverage bitmap that have not been hit in any previous execution rounds. This result is used as a feedback signal and written into a structured test case description record.

[0081] S54. Based on the coverage determination result of the previous step, different handling methods are adopted for the mutated input stream used in this round. If the execution of this round triggers new code coverage, this set of mutated input streams is regarded as a high-quality test case and is completely saved to a global seed queue. The test inputs in this seed queue will be selected again in future fuzzy testing rounds as the basic input for the next round of mutation operations. If the execution of this round fails to trigger new code coverage, this set of mutated input streams is usually discarded. At the same time, the coverage feedback result of this round is passed to the reward assignment and model update stage of step S42 to update the reward estimate of the corresponding arm. This update operation will affect the evaluation value of the future arm by the confidence upper bound algorithm, thereby guiding the subsequent mutation strategy to adjust in a direction that is more likely to generate new coverage.

[0082] S55. After all post-processing work is completed in this round, the fuzzing loop determines the input basis for the next round. The fuzzer selects an existing test input from the global seed queue according to a certain seed scheduling strategy as the basis for the next round of mutation. After selection, the fuzzing loop returns to step S40 to begin a new round of mutation strategy decision-making, mutation operation generation, firmware execution, and feedback updates, forming a continuous, closed-loop fuzzing process. The entire fuzzing process will continue to run for a preset total time length or a preset total number of execution rounds until the termination condition is met. Through this iterative testing loop, the fuzzer can systematically explore the firmware's state space and discover as many code regions and potential vulnerabilities as possible.

[0083] Firmware is a specific type of software embedded in hardware devices, typically stored in read-only memory or flash memory. It is responsible for providing low-level control, initialization, and runtime management of the hardware. In safety-critical embedded systems such as those used in aerospace, firmware is the core of the system's proper functioning. Fuzzing typically targets the binary executable code of this type of firmware to identify security vulnerabilities or functional defects.

[0084] An emulator is software that can simulate the behavior of a computer or hardware platform with a different architecture on a single computer. In the field of firmware fuzzing, an emulator specifically refers to a tool capable of running embedded firmware binary code. Through firmware remanufacturing technology, firmware that originally needed to run on specific physical hardware can be executed in an emulator on a general-purpose personal computer or server, making large-scale, automated fuzzing possible.

[0085] A crash refers to a serious error state that prevents a program from continuing to run normally during execution. Under fuzzing monitoring, crashes manifest as memory segmentation faults, illegal instruction exceptions, assertion failures, division by zero errors, etc. The fuzzer treats the occurrence of a crash as a direct signal for discovering potential vulnerabilities, recording relevant input and context information for security analysts to reproduce and confirm.

[0086] The seed queue is a data structure maintained by the fuzzing tool to store test inputs deemed to contribute to improved code coverage. These test inputs are called seeds. During subsequent fuzzing, the fuzzer continuously selects seeds from the seed queue and applies mutation operations to them to generate new test inputs. Through this continuous mutation based on existing valuable inputs, fuzzing can more efficiently explore the deep program logic of the firmware.

[0087] The input buffer is a memory area maintained by the simulator for each peripheral register or input stream. When a modified input stream is injected into the simulator, the data bytes in the input stream are written into the corresponding input buffer. When the firmware code performs a read operation on a peripheral register, the simulator intercepts the read request, retrieves the data from the corresponding input buffer, and returns it to the firmware, thus realizing the input of data to the firmware.

[0088] The coverage bitmap is a memory data structure generated by a fuzzing instrumentation tool during firmware execution to efficiently record code coverage information. Each bit or byte in the bitmap typically corresponds to a basic block or control flow edge in the firmware code. When the firmware execution reaches the corresponding code location, the corresponding bit is set or incremented. By comparing the coverage bitmaps generated in different execution rounds, it can be determined whether a new code coverage path has been triggered.

[0089] The technical solution of the present invention will be further described through the following embodiments. Figure 3 The flowchart of the method of this invention is shown. In order to perceive the implicit, asynchronous, and state-dependent multi-peripheral register interaction protocol, firmware execution records that trigger new code overwriting are dynamically collected during fuzzing. The history of firmware access to peripheral registers is analyzed, and frequently co-occurring peripheral register subsequences are extracted. Cooperative mutation is then performed on the input streams corresponding to the peripheral registers in the sequence. The specific content of the algorithm used to perceive the multi-peripheral register interaction protocol will be described in detail below. Specifically: Figure 3 In this context, the corpus is a dataset storing initial seed test inputs, serving as the fundamental source for generating variant inputs during fuzzing. Test inputs selected from the corpus are fed into a module where they are logically segmented into multiple independent fields according to a multi-stream input paradigm. Figure 3 The input is displayed as separate letter blocks, such as independent strings like A, B, C, D, and E under the Input field, representing different input streams. Each input stream is bound to a specific input context. This input stream data is fed into the mutation module, which is the core of this method for implementing collaborative mutation operations. At the mutation module, the process receives guidance from the set of frequent stream sequences on the right. This set of frequent stream sequences is obtained through dynamic mining. Figure 3 The example demonstrates sequences such as ACE, CD, and BD, revealing cooperative relationships between multiple input streams. The reinforcement learning-based sequence selection module employs a confidence upper bound algorithm to intelligently select a target subsequence from a set of frequent stream sequences and passes the selection result to the mutation module. The mutation module, based on the selected target subsequence, simultaneously applies mutation operations to all input streams it encompasses, generating mutated inputs. Figure 3In the process, the mutated input is represented by blackened letter blocks C and D, indicating the modified input stream fields, while the remaining letters A, B, and E remain unchanged. The mutated input is then fed into the ISA simulator, which loads and executes the firmware. During firmware execution, the ISA simulator generates coverage feedback, which is passed to a decision-making stage. When the coverage feedback indicates that the current execution round triggered new code coverage, the mutated input for that round is determined to be the input that triggered the new coverage and is added back to the corpus as a high-quality seed for subsequent testing. Simultaneously, the input stream access sequence recorded in the execution round corresponding to the input that triggered the new coverage is also used to update the reinforcement learning model. Specifically, this triggers a new round of frequent sequence mining to update the frequent stream sequence set, and assigns a positive reward to the selected arm to update the reward estimate in the confidence upper bound algorithm, forming a closed loop from execution to feedback to policy optimization.

[0090] Due to the limitations of binary and assembly code syntax rules, it is difficult to obtain the coordination patterns between multiple registers during the static analysis phase. Therefore, this method obtains frequently co-occurring peripheral register subsequences by mining the history of firmware access to peripheral registers during the dynamic execution of fuzzing. Then, based on a reinforcement learning algorithm, it selects the most suitable frequent subsequence in the current state from the frequent sequence set for mutation. The frequent sequence mining algorithm and the frequent sequence selection algorithm will be described in detail below.

[0091] The frequent sequence mining based on the FP-Tree algorithm is described as follows: During firmware execution, the test inputs used in the current fuzzing round will lead to different execution paths, thus the peripheral registers accessed in each firmware execution round will also differ. However, the rules such as the register access order specified by the protocol will exhibit regularity in multiple peripheral register access sequences. We assume that multiple peripheral registers that are always accessed in a single firmware execution have a cooperative pattern. Based on this assumption, we record the input stream access sequences formed by firmware accessing peripheral registers in each fuzzing loop and mine frequent subsequences from the historical sequences. Furthermore, as fuzzing progresses, the number of input stream access sequences will increase dramatically, leading to a state explosion problem, and only firmware execution rounds that trigger new coverage are valuable for guiding the fuzzing direction. Therefore, using a sliding window method, we mine frequent sequences only from the input stream access sequences recorded in the most recent 50 successfully triggered new coverage execution rounds. The problem of mining frequently co-occurring input stream subsequences is modeled as a frequent itemset mining problem, formally described as follows: Given a global collection of items and transaction database Among them, the project This represents an input context, containing information such as the address of the corresponding peripheral register and the type of the input value. This represents the sequence of input stream accesses formed by the firmware accessing peripheral registers in each fuzzing loop; each transaction is... A subset of the above. A collection of items. exist The support level is included The matter in The percentage of frequent itemsets, i.e., frequently co-occurring subsequences of input flows, is greater than or equal to the minimum support. The non-empty subset of.

[0092] There are two classic algorithms for frequent itemset mining: the Apriori algorithm and the FP-Tree algorithm. The Apriori algorithm aims to find the most frequent K-itemset with the largest K value, using an iterative method of level-by-level search. The core idea of ​​the Apriori algorithm is to use a "generate-test" strategy to discover frequent itemsets. It follows the principle that "to generate a new K-itemset, we must first ensure that all its K-1 proper subsets are frequent; if one is not frequent, then remove it from the current candidate itemset," thus completing the process of generating K-itemsets from K-1 itemsets. It can be seen that the Apriori algorithm requires multiple scans of the transaction database. This would result in a huge input / output load, and the computation process would generate a massive candidate set. Faced with the exponentially growing number of candidate sets, the algorithm would encounter significant challenges in both time and space. The FP-Growth algorithm, also known as the FP-Tree algorithm, proposed by Han Jiawei et al., based on Frequent Pattern Trees (FP-Trees), overcomes the problems of the Apriori algorithm and significantly improves execution efficiency. The idea behind this algorithm is to scan the transaction database twice. The algorithm compresses the frequent itemsets of each transaction into an FP-Tree structure, sorted by their support in descending order. Then, it recursively calls the FP-Growth algorithm to directly generate all frequent itemsets from this FP-Tree. The entire algorithm process only requires scanning the transaction database twice. Furthermore, since it does not require generating a candidate set, the FP-Tree algorithm outperforms the Apriori algorithm in both time and space complexity. As a random mutation algorithm, fuzzing aims to cover as many branches as possible within a finite time, requiring each round of fuzzing to be as efficient as possible. Therefore, the FP-Tree algorithm was chosen for mining frequently co-occurring input flow subsequences. Based on this, a multi-threaded approach was employed to implement the frequent co-occurring input flow subsequence mining algorithm, further preventing the frequent sequence mining algorithm from dragging down the overall efficiency of fuzzing.

[0093] The following is a simplified example illustrating the FP-Tree algorithm, specifically including: 1) Construction of FP-Tree: such as Figure 4 As shown, the FP-Tree data structure mainly consists of three parts: an item header table, the FP-Tree itself, and a node list. The item header table records the frequency of all frequent one-itemsets; the FP-Tree maps the original database to a tree-like data structure in memory; each head in the node list corresponds to a frequent one-item in the item header table, allowing each item to be linked to its position in the tree via a node chain. The FP-Tree construction process is as follows: The transaction database is read in item by item. Transactions are processed and inserted into the FP-Tree. During insertion, nodes sorted earlier are considered ancestor nodes, and nodes sorted later are considered descendant nodes. If a common ancestor exists, its count is incremented; otherwise, a new node is added, and the corresponding node in the item header table is linked to the new node via a node linked list. Figure 4 The example in the image illustrates the build process, specifically: Figure 4 This fully demonstrates the frequent pattern tree (i.e., through a step-by-step evolution example) Figure 4 The construction process of the "FP-tree" data structure is described below. The initial conditions are a global item set, a transaction dataset, and a minimum number of supports. The global item set is I = {a, b, c, d, e}, the transaction dataset is D = {{a, b, c, d}, {b, c, e}, {a, b, c, e}, {b, d, e}, {a, b, c, d}}, and the minimum number of supports is 2. Each letter a, b, c, d, e represents an item, i.e., an input context, used to identify a specific peripheral register and its input value type. The transaction dataset contains five transactions: the first transaction is {a, b, c, d}, the second is {b, c, e}, the third is {a, b, c, e}, the fourth is {b, d, e}, and the fifth is {a, b, c, d}. Each transaction is the set of input contexts actually accessed by the firmware in one execution round. The construction process begins with an empty tree containing only the root node. The first step is a preliminary scan of the transaction database to count the support of all individual items, resulting in frequent one-itemsets: {a:3}, {b:5}, {c:4}, {d:3}, {e:3}. These frequent one-itemsets are arranged in descending order of support count in a header table. From left to right, the header table records item b and its count (5), item c and its count (4), item a and its count (3), item d and its count (3), and item e and its count (3). Each item in the header table maintains a node chain, which horizontally links all nodes representing the same item in subsequent tree iterations. Figure 4 (a) When inserting {a,b,c,d}, the items contained in the transaction are first sorted according to the order in the header table, resulting in b,c,a,d. Since the tree only contains the root node and has no common ancestor, new nodes b,c,a,d are created sequentially starting from the root node, forming a path of length four. The count of each new node is initialized to 1, and the node chains of items b,c,a, andd in the header table point to their respective newly created nodes. Figure 4 (b) When inserting {b,c,e}, the sorted sequence of this transaction is b,c,e. Starting from the root node and comparing downwards along the existing path, it is found that node b already exists as a child node of the root node. Therefore, a new node b is not created; instead, the count of the existing node b is increased from 1 to 2. Continuing downwards, node c also exists as a child node of node b, and its count is increased from 1 to 2. Then, item e has no existing child nodes under node c, so a new node e is created under node c, with its count initialized to 1. Simultaneously, the node chain of item e in the header table points to this newly created node e. Figure 4 (c) When inserting {a,b,c,e}, the sorted sequence of this transaction is b,c,a,e. Starting from the root node, a longest common prefix match is performed with the existing paths. It is found that nodes b, c, and a match successfully in sequence. Therefore, the count of node b is increased from 2 to 3, the count of node c is increased from 2 to 3, and the count of node a is increased from 1 to 2. Then, item e has no existing child nodes under node a, so a new node e is created under node a, with its count initialized to 1. Simultaneously, the node chain of item e in the header table links this newly created node e to the end of the linked list of existing nodes e. Figure 4 (d) When inserting {b,e,d}, the sorted sequence of this transaction is b,d,e. Starting from the root node, node b already exists under the root node, so the count of node b is increased from 3 to 4. There are no child nodes d under node b, so a new node d is created under node b, with its count initialized to 1. Then, a new node e is created under the newly created node d, with its count initialized to 1. The node chain of item e in the header table is extended again to include this new node e, and the node chain of item d points to this newly created node d. Figure 4(e) When inserting {a,b,c,d}, the sorted sequence of the transaction is b,c,a,d. Starting from the root node, the longest common prefix match is performed with the existing paths. It is found that nodes b, c, a, and d match successfully in sequence. Therefore, the count of node b is increased from 4 to 5, the count of node c is increased from 3 to 4, the count of node a is increased from 2 to 3, and the count of node d is increased from 1 to 2. After the above five insertion operations, the entire frequent pattern tree is completed. The count marked on each node in the tree reflects the number of times the path passing through that node is shared in the entire transaction database. The header table records the total count of all frequent single items, and the node chain provides a horizontal index for quickly locating each item to its position in all occurrences in the tree. This provides a complete data structure support for subsequent recursive mining of conditional pattern bases and generation of all frequently co-occurring input flow subsequences.

[0094] 2) FP-Tree mining: Based on the support of frequent 1-itemsets, the conditional pattern base of the corresponding node in the FP-Tree is searched sequentially for each element in the item header table, from lowest to highest. The conditional pattern base is defined as the FP subtree with the node to be mined as the leaf node. The count of each node in this subtree is set to the count of the leaf node, and nodes with counts lower than their support are deleted; this constitutes the conditional pattern base for that node. Then, the frequent itemset mining is recursively completed based on this conditional pattern base. Figure 4 The process of constructing a conditional schema base is illustrated. Taking item d as an example, after obtaining the conditional schema base, the frequent 2-itemsets of item d are {a:2,d:2}, {b:3,d:3}, and {c:2,d:2}. In these notations, the letters a, b, c, and d each represent an item, i.e., an input context, used to identify a specific peripheral register and its input value type. The number after the colon represents the support count, i.e., in the transaction database. The total number of transactions for all items in the item set is included in all transactions. An item set enclosed in curly braces and its count represents a mined frequent itemset, i.e., a frequently co-occurring subsequence of input flows. Recursively merging two-itemsets yields frequent three-itemsets: {a:2,b:2,d:2}, {a:2,c:2,d:2}, and {b:2,c:2,d:2}. Taking curly braces {a:2,b:2,d:2} as an example, it represents the three input contexts of item a, item b, and item d in the transaction database. The itemset appears twice in all transactions. Recursive merging continues until no longer itemsets satisfying the minimum support threshold can be generated, resulting in the largest frequent itemset being {a:2,b:2,c:2,d:2}. The final frequent itemsets are {a}, {b}, {c}, {d}, {e}, {a,b}, {a,c}, {a,d}, {b,c}, {b,d}, {b,e}, {c,d}, {c,e}, {a,b,c}, {a,b,d}, {b,c,d}, {b,c,e}, {a,b,c,d}, specifically: Figure 5 Based on the frequent pattern tree, this paper systematically demonstrates the complete process of recursively mining all frequent itemsets that satisfy the minimum support condition from the tree structure. Figure 5 The initial conditions used in this mining were labeled, including the global item set, the transaction dataset, and the minimum support count. The global item set was I={a,b,c,d,e}, the transaction dataset was D={{a,b,c,d},{b,c,e},{a,b,c,e},{b,d,e},{a,b,c,d}}, and the minimum support count was 2. Each letter represents an item, i.e., an input context. The entire mining process strictly followed a bottom-up order, starting with the single item with the lowest support count in the item header table, and processing items e, d, a, c, and b sequentially upwards. Figure 5(a) illustrates the mining process for item e. Following the node chain of item e in the item header table, three nodes e in the tree are located: one on the path root-bcae, with a node count of 1; one on the path root-bce, with a node count of 1; and another on the path root-bde, with a node count of 1. Tracing upwards, three prefix paths are obtained: one from root via b, c, and a to e; one from root via b and c to e; and one from root via b and d to e. Summarize the counts of each node in these three paths. For the first path, the count of node b is taken as the count of node e (1); the count of node c is taken as the count of node e (1); and the count of node a is taken as the count of node e (1). For the second path, the counts of node b and node c are taken as the count of node e (1); and for the third path, the counts of node b and node d are taken as the count of node e (1). Therefore, the total count of item a is 1, the total count of item b is 1 + 1 + 1 = 3, the total count of item c is 1 + 1 = 2, and the total count of item d is 1. After deleting items a and d whose counts are below the minimum support number of 2, items b and c remain. Based on these prefix items, combining item e with b yields {b:3,e:3}, and combining it with c yields {c:2,e:2}. Therefore, the frequent 2-itemsets of c are mined: {b:3,e:3} and {c:2,e:2}. Recursively merge these two frequent 2-itemsets, taking the smaller of the support counts for items b and c as 2, to obtain a frequent 3-itemset for e: {b:2, c:2, e:2}, indicating that the three input contexts appear twice in the transaction database. Since no further combination is possible, the mining of item e ends.

[0095] Figure 5 (b) illustrates the mining process for item d. First, using the node chain associated with item d in the item header table, two leaf nodes representing item d are quickly located in the frequent pattern tree. The first is located on the path root-bcad, and the second on the path root-bd. Tracing upwards from these two d nodes to the root node, two prefix paths are extracted. The first path passes through nodes a, c, and b to reach the root node, and the second path passes through node b to reach the root node. The set of these two paths constitutes the conditional pattern base for d. The summation yields the counts of all prefix items: item b appears 3 times, item c appears 2 times, and item a appears 2 times. Figure 5The FP subtree, highlighted by a dashed box, represents the conditional frequent pattern tree for item d. This subtree, rooted at `root`, contains items b (counted as 3), c (counted as 2), and a (counted as 2). The links between nodes are horizontally linked from the node chains corresponding to the row of item d in the item header table. Based on this subtree, item d is paired with each of these prefix items to obtain frequent 2-itemsets of d: {b:3, d:3}, {c:2, d:2}, {a:2, d:2}. The number after the colon represents the total number of transactions in the transaction database D that simultaneously contain all items within that pair. The algorithm continues recursively merging these frequent 2-itemsets, checking if a longer frequent itemset can be generated. The support counts of prefix items a, b, and c in {b:3, d:3}, {c:2, d:2}, and {a:2, d:2} are combined by taking the minimum support counts of each pair of items, resulting in frequent 3-itemsets {b:2, c:2, d:2}, {b:2, a:2, d:2}, and {c:2, a:2, d:2}. These three frequent 3-itemsets are then merged. The minimum support count of items a, b, and c remains 2, satisfying the minimum support threshold. Therefore, a frequent 4-itemset for item d is obtained: {b:2, c:2, a:2, d:2}. This indicates that the four input contexts a, b, c, and d were all accessed twice in all execution rounds that triggered new code coverage. At this point, the recursive mining of item d can no longer generate itemsets containing more items, and the mining process terminates.

[0096] Figure 5 (c) illustrates the mining process for item a. Following the node chain of item a in the item header table, node a in the tree is located on the path root-bca. This node has a count of 3. Tracing upwards, a prefix path is obtained from root through b and c to a. Therefore, the total count of item b is 3, and the total count of item c is 3. Since the counts of both items b and c are greater than the minimum support number of 2, both are retained. Based on these prefix items, items a and b are combined to obtain {a:3, b:3}, and items a and c are combined to obtain {a:3, c:3}. Therefore, the frequent 2-itemsets of a are mined: {a:3, b:3}, {a:3, c:3}. These two frequent 2-itemsets are recursively merged. The support counts of items b and c are 3, resulting in the frequent 3-itemsets of a: {a:3, b:3, c:3}, indicating that the three input contexts appear 3 times in the transaction database. Since no further combinations are possible, the mining of item a ends.

[0097] Figure 5(d) illustrates the mining process for item c. Following the node chain of item c in the item header table, we locate node c in the tree, situated on the path root-bc. This node has a count of 4. Tracing upwards, we find a prefix path from root through b to c, thus the total count of item b is 4. Since the count of item b is greater than the minimum support number 2, it is retained. Based on the prefix item, we combine item c with b to obtain {b:4, c:4}, thus mining a frequent 2-itemset of c: {b:4, c:4}. Since there is only one prefix item, b, we cannot continue recursively merging to generate a longer itemset, and the mining process for item c terminates.

[0098] Figure 5 (e) shows the mining process of item b. Tracing back up from the node b in the node chain of item b in the item header table, it is found that the prefix item set on the path from node b to the root node is empty, that is, the condition pattern base of b does not contain any other items. Therefore, item b cannot generate any frequent 2-itemsets, and the mining process ends directly.

[0099] Through the recursive mining of each item from the bottom to the top of the item head table, a comprehensive set of frequently co-occurring input stream subsequences was finally obtained, including the frequent 1-itemsets {a}, {b}, {c}, {d}, and {e} of all single items, as well as the frequent 2-itemsets, frequent 3-itemsets, and the longest frequent 4-itemsets formed by their combinations. These subsequences reveal combinations of peripheral registers that are always accessed in the execution rounds that trigger new code coverage, providing a structured candidate set for subsequent reinforcement learning-based sequence selection and multi-stream co-mutation.

[0100] The process of frequent sequence selection based on reinforcement learning is as follows: After obtaining the set of frequently co-occurring input flow subsequences, a new multi-flow mutation strategy is added to the existing multi-flow firmware fuzzing framework. In each round of fuzzing, the multi-flow mutation strategy is selected with a certain probability, and a set of frequent sequences is chosen from the frequent sequence set. All flows in the sequence are mutated simultaneously. However, the probability of obtaining new coverage after each frequent sequence mutation is unknown to the fuzzer. Therefore, whenever the fuzzer selects a frequent sequence for multi-flow mutation, it faces a balance between exploitation and exploration. Exploration refers to selecting frequent sequences that have not been mutated, while exploitation refers to selecting frequent sequences that provide greater coverage improvement after mutation. If it remains in the exploration state, the overall performance of the fuzzer will not reach its optimal state; if it focuses solely on exploiting the best frequent sequence, it will miss out on more effective but unmutated frequent sequences. The multi-armed gambler problem can effectively address this balance. Therefore, to achieve higher coverage and discover more vulnerabilities, the frequent sequence selection problem is modeled as a multi-armed gambler problem, and a confidence upper bound algorithm (i.e., the UCB1 algorithm) is used to solve this problem. Each frequent sequence in the frequent sequence set is treated as an arm of a multi-armed gambling machine. When a frequent sequence gains new coverage in a round of fuzz testing, the arm is given a positive reward; when a frequent sequence fails to gain new coverage in a round of fuzz testing, the arm is given a negative reward. After each multi-stream mutation and test case execution, the reward value and reinforcement learning model are updated. The implementation steps of the above process are as follows: 1) In each round of fuzz testing, a preset probability is used to determine whether to enable the multi-stream mutation strategy. A random number generator produces a uniformly distributed random number between zero and one, and the generated random number is compared with the preset probability value. If the random number is less than the preset probability, it is determined that the multi-stream mutation strategy is enabled for this round; if the random number is greater than or equal to the preset probability, it is determined that the multi-stream mutation strategy is not enabled for this round, and a single input stream mutation strategy will be used to select a single input stream for mutation in subsequent rounds.

[0101] 2) When the multi-stream mutation strategy is enabled, each input stream subsequence in the frequently co-occurring input stream subsequences is modeled as an arm of a multi-armed gambling machine. A confidence upper bound algorithm is used to select a target subsequence from the frequently co-occurring input stream subsequences, and mutation operations are simultaneously applied to all input streams in the target subsequence. The selection logic of the confidence upper bound algorithm takes into account both utilizing arms with good historical performance and exploring unknown arms with fewer historical selections. During the selection process, the algorithm scans each arm and calculates an upper bound evaluation value for each arm. After all upper bound evaluation values ​​for all arms have been calculated, the input stream subsequence corresponding to the arm with the largest upper bound evaluation value is selected as the target subsequence. After determining the target subsequence, mutation operations are simultaneously applied to all input streams contained in the target subsequence. Available mutation operators include deleting values, inserting values, modifying values, applying offsets to values, flipping specific locations, randomly swapping values, copying a segment of values ​​from other streams, and replacing values ​​with values ​​from a dictionary.

[0102] 3) After performing the mutation operation, the firmware is executed based on the mutated input stream. After the firmware execution is complete, the coverage bitmap generated in this round and the global coverage bitmap are compared to determine whether new code coverage was triggered in this round. When the mutated input stream triggers new code coverage, a positive reward is assigned to the arm corresponding to the input stream subsequence selected in this mutation; when the mutated input stream fails to trigger new code coverage, a negative reward is assigned to the arm corresponding to the input stream subsequence selected in this mutation. After assigning the reward, the reward estimate related to that arm in the confidence upper bound algorithm is updated. Specifically, this includes incrementing the number of times the arm has been selected by one, adding the cumulative reward value of the arm to the reward value assigned in this round, and recalculating the average reward of the arm. After the update is completed, when the arm is evaluated by the confidence upper bound algorithm in subsequent rounds, the reward estimate information reflecting the latest effectiveness of this mutation will be used.

[0103] In the fuzzing phase, frequent co-occurring input flow subsequence mining and multi-flow cooperative mutation were implemented. All related code is based on the Hoedur firmware fuzzer, which was first proposed for multi-flow input. The mining of frequent co-occurring input flow subsequences was achieved using a multi-threaded strategy based on the FP-Tree algorithm. Experiments show that the firmware execution count can reach millions to tens of millions within 24 hours. To avoid memory leaks, after the first 50 fuzzing rounds discovering new coverage, frequent sequence mining is performed every 100 fuzzing rounds discovering new coverage. Furthermore, for reinforcement learning-based frequent sequence selection, the reinforcement learning model is updated every time a multi-flow mutation strategy is used.

[0104] The technical effects of the present invention are illustrated through the following experiments: A new firmware blurr, MSFUZZ, was implemented using this method. Five 24-hour blurr tests were conducted on 20 firmware targets using this blurr. The average, maximum, minimum, and median of the final coverage obtained by MSFUZZ and Hoedur on the 20 firmware targets were statistically analyzed and compared. The results are shown in Table 1.

[0105] Table 1: As can be seen, MSFUZZ achieves improved code coverage, obtaining a basic block coverage no less than Hoedur's median on 19 real firmware targets. This indicates that the method can obtain higher code coverage with a greater probability, which helps to discover more vulnerabilities.

[0106] In addition, the average number of crashes found by MSFUZZ and Hoedur in 5 fuzz tests was statistically analyzed and compared, as shown in Table 2.

[0107] Table 2: As can be seen, MSFUZZ can detect more crashes across 6 firmware targets, and at least as many crashes as Hoedur across 19 firmware targets. These experimental results demonstrate that multi-peripheral register interaction protocol information and the reinforcement learning-based frequent sequence selection algorithm can effectively improve the code coverage and crash detection capability of the firmware blurr.

[0108] Existing firmware fuzzing methods randomly select a single input stream for mutation in each fuzzing cycle, failing to consider the implicit relationships between multiple input streams caused by the interaction protocols between multiple peripheral registers. This mutation approach, targeting only a single input stream, inherently hinders the fuzzer from exploring code blocks that require the coordinated action of multiple peripheral registers to trigger. When a branch condition within the firmware requires the values ​​of two or more peripheral registers to simultaneously satisfy specific constraints, applying mutation to only a single input stream makes it extremely difficult to simultaneously hit these constraints, resulting in such deep code remaining uncovered for extended periods and limiting the fuzzer's ability to discover vulnerabilities. The proposed firmware fuzzing method, which is aware of the multi-peripheral register interaction protocol, dynamically collects firmware execution records that trigger new code coverage during the fuzzing phase, analyzes the history of firmware access to peripheral registers, extracts frequently co-occurring peripheral register subsequences, and simultaneously applies coordinated mutation operations to the input streams corresponding to the peripheral registers in the sequence. Because this interaction is implicit, asynchronous, and state-dependent, the synergistic effect generated by this interaction is utilized in real-time and with low overhead during testing, avoiding exhaustive testing of exponential combinations and effectively ensuring the efficiency of fuzzing. This approach can fully explore code blocks in the firmware that require multiple peripheral inputs to be triggered simultaneously, allowing code regions hidden behind the joint constraints of multiple peripheral registers to be discovered. This improves the code coverage of firmware fuzzing and thus increases the likelihood of discovering more crashes and potential vulnerabilities.

[0109] Regarding input stream selection, this invention designs a novel multi-stream mutation strategy, modeling the selection problem of frequently co-occurring input stream subsequences as a multi-armed gambling machine problem. Based on a confidence upper bound algorithm, it selects the subsequence from the set of frequent sequences that is most beneficial to improving overall coverage in the current state, and mutates all input streams in the sequence simultaneously. Existing multi-stream firmware blurrs use mutation operators that perform mutation operations on a single input stream during the mutation phase, without considering the interaction relationships between multiple input streams and lacking an understanding of the interaction protocols between multiple peripheral registers, resulting in difficulty in covering deep code. This invention adds a multi-stream input selection strategy to the existing stream selection strategy, achieving a balance between exploration and exploitation through a confidence upper bound algorithm. Exploration refers to trying frequent sequences that have not yet been sufficiently mutated, while exploitation refers to prioritizing frequent sequences that have historically performed well and have repeatedly brought new code coverage. The confidence upper bound algorithm statistically estimates the number of times each arm has been selected and the cumulative reward, allowing arms with fewer selections to also have a chance to be selected, thereby avoiding the possibility of missing potentially high-quality sequences. As fuzzing continues, the reward estimates for each arm increasingly accurately reflect the true contribution of the corresponding frequent sequences to improving code coverage. The fuzzer then becomes more inclined to select efficient sequences for mutation, pushing the overall coverage closer to the optimal effect. Experimental results also verify these beneficial effects. Comparative tests on 20 real firmware targets show that this method achieves a median basic block coverage no less than existing technologies, improves coverage on multiple firmware targets, and discovers more crashes on multiple firmware targets. This demonstrates that multi-peripheral register interaction protocol information and frequent sequence selection based on confidence upper bound algorithms can effectively improve the code coverage and vulnerability discovery capabilities of firmware fuzzing.

[0110] In the above embodiments, although the steps are numbered S1, S2, etc., they are only specific embodiments given by the present invention. Those skilled in the art can adjust the execution order of S1, S2, etc. according to the actual situation. The scheme after adjusting the order is also within the protection scope of the present invention. It can be understood that in some embodiments, some or all of the above embodiments may be included.

[0111] like Figure 6 As shown, a firmware fuzz testing system 200 with multi-peripheral register interaction protocol awareness according to an embodiment of the present invention includes a determination module 201, an acquisition module 202, a mining module 203, a mutation module 204, and a fuzz testing module 205. The determination module 201 is used to: determine multiple execution rounds of the firmware that trigger new code coverage during the fuzzing process of the firmware; The acquisition module 202 is used to: acquire the peripheral register access sequence corresponding to each of the multiple execution rounds; The mining module 203 is used to: mine frequently co-occurring input stream subsequences based on multiple peripheral register access sequences, wherein each input stream corresponds to a peripheral register; The mutation module 204 is used to: select a target subsequence from frequently co-occurring input stream subsequences, and mutate multiple input streams in the target subsequence simultaneously; The fuzzing module 205 is used to: execute firmware based on the mutated input stream and perform fuzzing tests on the firmware.

[0112] Optionally, in the above technical solution, the acquisition module 202 is specifically used to: record the input stream access sequence formed by the firmware accessing peripheral registers in each execution round of fuzz testing of the firmware; maintain the input stream access sequence using a sliding window, and when the number of execution rounds that successfully trigger new code coverage reaches a preset threshold, obtain multiple peripheral register access sequences based on the input stream access sequence recorded in the most recent execution round.

[0113] Optionally, in the above technical solution, the mining module 203 is specifically used to: model multiple peripheral register access sequences as a transaction database, wherein each peripheral register access sequence corresponds to a transaction in the transaction database, and the transaction contains the input context corresponding to the peripheral register accessed in the corresponding execution round; scan the transaction database using a frequent pattern tree algorithm to mine input flow subsequences with support greater than or equal to the minimum support as frequently co-occurring input flow subsequences, wherein the support represents the proportion of transactions containing input flow subsequences in the transaction database.

[0114] Optionally, in the above technical solution, the mutation module 204 is specifically used for: determining whether to enable the multi-stream mutation strategy in each round of fuzz testing with a preset probability; when the multi-stream mutation strategy is enabled, modeling each input stream subsequence in the frequently co-occurring input stream subsequences as an arm of a multi-armed gambling machine, selecting a target subsequence from the frequently co-occurring input stream subsequences using a confidence upper bound algorithm, and simultaneously applying mutation operations to all input streams in the target subsequence; when the multi-stream mutation strategy is not enabled, selecting a single input stream for mutation using a single input stream mutation strategy; after performing the mutation operation, executing firmware based on the mutated input stream, and when the multi-stream mutation strategy is enabled and the mutated input stream triggers new code overwriting, assigning a positive reward to the arm corresponding to the input stream subsequence selected in this mutation, otherwise assigning a negative reward, and updating the reward estimate in the confidence upper bound algorithm.

[0115] It should be noted that the beneficial effects of the firmware fuzzing system 200 with multi-peripheral register interaction protocol awareness provided in the above embodiments are the same as those of the firmware fuzzing method with multi-peripheral register interaction protocol awareness, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0116] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned firmware fuzzy testing methods for awareness of multiple peripheral register interaction protocols.

[0117] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the aforementioned firmware fuzzy testing methods for awareness of multiple peripheral register interaction protocols.

[0118] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0119] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A firmware fuzz testing method with multi-peripheral register interaction protocol awareness, characterized in that, include: During fuzz testing of the firmware, multiple execution rounds of the firmware that trigger new code overwriting are identified; Obtain the peripheral register access sequence corresponding to each of the multiple execution rounds; Based on multiple peripheral register access sequences, frequently co-occurring input stream subsequences are mined, where each input stream corresponds to a peripheral register; Select a target subsequence from the frequently co-occurring input stream subsequences, and simultaneously mutate multiple input streams in the target subsequence; The firmware is executed based on the mutated input stream, and fuzz testing is performed on the firmware. Among these methods, based on multiple peripheral register access sequences, frequently co-occurring input stream subsequences are identified, including: Multiple peripheral register access sequences are modeled as a transaction database, wherein each peripheral register access sequence corresponds to a transaction in the transaction database, and the transaction contains the input context corresponding to the peripheral register accessed in the corresponding execution round; The frequent pattern tree algorithm is used to scan the transaction database and mine the input flow subsequences with support greater than or equal to the minimum support as the frequently co-occurring input flow subsequences, wherein the support represents the proportion of transactions containing the input flow subsequences in the transaction database.

2. The firmware fuzzy testing method for multi-peripheral register interaction protocol awareness according to claim 1, characterized in that, Obtain the peripheral register access sequence corresponding to each of the multiple execution rounds, including: In each execution round of fuzz testing of the firmware, the input stream access sequence formed by the firmware accessing peripheral registers is recorded; The input stream access sequence is maintained using a sliding window. When the number of execution rounds that successfully trigger new code coverage reaches a preset threshold, multiple peripheral register access sequences are obtained based on the input stream access sequence recorded in the most recent execution round.

3. The firmware fuzzy testing method for multi-peripheral register interaction protocol awareness according to claim 2, characterized in that, Select a target subsequence from the frequently co-occurring input stream subsequences, and simultaneously mutate multiple input streams within the target subsequence, including: In each round of fuzz testing, the decision to enable the multi-stream mutation strategy is determined by a preset probability. When the multi-stream mutation strategy is enabled, each input stream subsequence in the frequently co-occurring input stream subsequences is modeled as an arm of a multi-armed gambling machine. The upper confidence bound algorithm is used to select the target subsequence from the frequently co-occurring input stream subsequences, and mutation operations are applied to all input streams in the target subsequence simultaneously. When the multi-stream mutation strategy is not enabled, a single input stream mutation strategy is used to select a single input stream for mutation. After performing the mutation operation, the firmware is executed based on the mutated input stream. When the multi-stream mutation strategy is enabled and the mutated input stream triggers new code overwriting, a positive reward is assigned to the arm corresponding to the input stream subsequence selected in this mutation; otherwise, a negative reward is assigned, and the reward estimate in the confidence upper bound algorithm is updated.

4. A firmware fuzzy testing system with multi-peripheral register interaction protocol awareness, characterized in that, It includes a determination module, an acquisition module, a mining module, a mutation module, and a fuzz testing module; The determining module is used to: determine multiple execution rounds of the firmware that trigger new code overwriting during the fuzzing process of the firmware; The acquisition module is used to: acquire the peripheral register access sequence corresponding to each of the multiple execution rounds; The mining module is used to: mine frequently co-occurring input stream subsequences based on multiple peripheral register access sequences, wherein each input stream corresponds to a peripheral register; The mutation module is used to: select a target subsequence from the frequently co-occurring input stream subsequences, and simultaneously mutate multiple input streams in the target subsequence; The fuzz testing module is used to: execute the firmware based on the mutated input stream and perform fuzz testing on the firmware; The mining module is specifically used for: Multiple peripheral register access sequences are modeled as a transaction database, wherein each peripheral register access sequence corresponds to a transaction in the transaction database, and the transaction contains the input context corresponding to the peripheral register accessed in the corresponding execution round; The frequent pattern tree algorithm is used to scan the transaction database and mine the input flow subsequences with support greater than or equal to the minimum support as the frequently co-occurring input flow subsequences, wherein the support represents the proportion of transactions containing the input flow subsequences in the transaction database.

5. A firmware fuzzy testing system with multi-peripheral register interaction protocol awareness as described in claim 4, characterized in that, The acquisition module is specifically used for: In each execution round of fuzz testing of the firmware, the input stream access sequence formed by the firmware accessing peripheral registers is recorded; The input stream access sequence is maintained using a sliding window. When the number of execution rounds that successfully trigger new code coverage reaches a preset threshold, multiple peripheral register access sequences are obtained based on the input stream access sequence recorded in the most recent execution round.

6. A firmware fuzzy testing system with multi-peripheral register interaction protocol awareness as described in claim 5, characterized in that, The mutation module is specifically used for: In each round of fuzz testing, the decision to enable the multi-stream mutation strategy is determined by a preset probability. When the multi-stream mutation strategy is enabled, each input stream subsequence in the frequently co-occurring input stream subsequence is modeled as an arm of a multi-armed gambling machine. The confidence upper bound algorithm is used to select the target subsequence from the frequently co-occurring input stream subsequence, and mutation operations are applied to all input streams in the target subsequence simultaneously. When the multi-stream mutation strategy is not enabled, a single input stream mutation strategy is used to select a single input stream for mutation. After performing the mutation operation, the firmware is executed based on the mutated input stream. When the multi-stream mutation strategy is enabled and the mutated input stream triggers new code overwriting, a positive reward is assigned to the arm corresponding to the input stream subsequence selected in this mutation; otherwise, a negative reward is assigned, and the reward estimate in the confidence upper bound algorithm is updated.

7. An electronic device, characterized in that, The invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a firmware fuzzing test method for awareness of a multi-peripheral register interaction protocol as described in any one of claims 1 to 3.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements a firmware fuzz testing method for multi-peripheral register interaction protocol awareness as described in any one of claims 1 to 3.

Images