Malicious firmware vulnerability utilization detection system based on sandbox behavior analysis

Abstract

The invention relates to the technical field of malicious software protection, in particular to a malicious firmware vulnerability utilization detection system based on sandbox behavior analysis, which comprises a protocol analysis constraint establishment module for loading to-be-detected firmware according to a sandbox environment, configuring a register address range of a virtual network card and a virtual USB controller, generating a virtual peripheral protocol analysis tree, and establishing a virtual peripheral protocol analysis result; and traversing leaf nodes in the virtual peripheral protocol parse tree. According to the method, in combination with interrupt time sequence discrete analysis, the hidden interrupt hooking behavior can be recognized from the microscopic time dimension by continuously recording the instruction execution clock cycle number corresponding to the target interrupt vector and calculating the time-consuming window and the dispersion value, and the limitation that a traditional sandbox only pays attention to the function level is overcome; malicious codes hidden in a bottom layer are pulled out by using the time sequence side channel characteristics, so that the detection success rate and the false alarm suppression capability aiming at unknown vulnerability utilization and persistent attacks of firmware are improved, and the deep security threat of embedded equipment is perceived.

Description

Technical Field

[0001] This invention relates to the field of malware protection technology, and in particular to a malicious firmware vulnerability exploitation detection system based on sandbox behavior analysis. Background Technology

[0002] Malware protection technology is a technology for identifying, blocking, and analyzing malicious code in computer systems, network architectures, and embedded devices. It is used to prevent various network security threats, including viruses, worms, Trojans, ransomware, and low-level firmware attacks.

[0003] Current technologies for addressing embedded firmware security threats primarily rely on general-purpose computer system simulation or static matching based on known signature libraries. However, due to the difficulty in accurately replicating the unique peripheral protocol constraints and hardware interrupt timing of target devices, the firmware under test often experiences blocking, crashes, or fails to trigger specific hardware-related code paths when running in a sandbox due to environmental incompatibility. This results in a lack of effective detection data. Furthermore, traditional dynamic monitoring methods are mostly passive observation methods, recording only high-level behaviors such as file operations or network connections. When facing attacks triggered by specific hardware states or malicious programs that reside by modifying interrupt vector tables, they often fail due to the lack of monitoring at the micro-instruction execution level. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a malicious firmware vulnerability exploitation detection system based on sandbox behavior analysis.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a malicious firmware vulnerability exploitation detection system based on sandbox behavior analysis includes: The protocol parsing constraint establishment module loads the firmware to be tested according to the sandbox environment, configures the register address range of the virtual network card and the virtual USB controller, generates a virtual peripheral protocol parsing tree, traverses the leaf nodes in the virtual peripheral protocol parsing tree, extracts the register read and write permission bits and the maximum transmission unit value of the data packet, sets the boundary threshold for buffer writing, and generates a set of peripheral communication compliance constraints. The peripheral boundary anomaly feedback module intercepts the configuration parameters and data load written by the firmware to the virtual peripheral based on the peripheral communication compliance constraint set, determines and generates a boundary overflow simulation feedback signal, injects the boundary overflow simulation feedback signal into the firmware running process, triggers the firmware to enter the anomaly handling process, and records the generated anomaly stimulus response instruction sequence. The firmware response branch monitoring module extracts conditional jump instructions and function call instructions from the abnormal stimulus response instruction sequence, generates a firmware branch jump path graph, counts the number of jumps to undefined memory regions and the number of nodes trapped in infinite loops in the firmware branch jump path graph, compares the path difference of the normal reset process, and generates a driver vulnerability detection behavior fingerprint. The interrupt timing discrete analysis module continuously records the number of instruction execution clock cycles corresponding to the target interrupt vector number based on the suspicious operation stage marked by the driver vulnerability detection behavior fingerprint, generates an interrupt service execution time window, calculates and generates an interrupt hook timing discrete value based on the interrupt service execution time window, identifies interrupt hook behavior and triggers firmware integrity verification based on the interrupt hook timing discrete value.

[0006] Preferably, the step of obtaining the peripheral communication compliance constraint set is as follows: Load the firmware to be tested according to the sandbox environment, configure the virtual network card register address range, configure the virtual USB controller register address range, read the field name and bit width at the byte offset position according to the header format of the firmware peripheral communication protocol, define the parsing length mark and effective payload start offset according to the load length, extract the name and length of fixed fields, extract the start and end marks and scaling rules of variable length field structures, and form a virtual peripheral protocol parsing tree. Based on the virtual peripheral protocol parsing tree, the leaf nodes of the virtual peripheral protocol parsing tree are traversed, the target register is located according to the register address recorded in the leaf node, the permission flag is read and the read and write bits are distinguished, the maximum transmittable length of the payload length field on all leaf node paths is calculated as the maximum transmission unit value of the data packet, the boundary threshold for writing to the buffer is determined based on the maximum transmission unit value of the data packet, and the illegal instruction code set is screened according to the firmware instruction set encoding range, forming the register read and write permission bits, the maximum transmission unit value of the data packet, the boundary threshold for writing to the buffer and the illegal instruction code set; Based on the register read / write permission bits, the maximum data packet transmission unit value, the buffer write boundary threshold, and the illegal instruction code set, a rejection condition for read and write bit mismatch requests is established, a truncation condition for requests exceeding the maximum data packet transmission unit value is established, a blocking condition for write positions exceeding the buffer write boundary threshold is established, and an interruption condition for hitting the illegal instruction code set is established, thereby generating a peripheral communication compliance constraint set.

[0007] Preferably, the step of obtaining the boundary overflow simulated feedback signal is as follows: Based on the peripheral communication compliance constraint set, a virtual peripheral write path is attached, and the configuration parameter fields, data load length, request address, target register and write offset are recorded. The data load length is compared with the boundary threshold, and the existence status of the request address in the illegal instruction code set is retrieved to obtain the data violation judgment result. Based on the data violation determination result, the error category code, violation field index, excessive length difference and hit instruction code in the error status code are filled in, the interrupt vector number and trigger priority are set, it is encapsulated as an interrupt request carrying the error status code, and a boundary overflow simulation feedback signal is generated.

[0008] Preferably, the step of obtaining the abnormal stimulus response command sequence is as follows: Based on the boundary overflow simulation feedback signal, the interrupt entry point of the firmware running process is injected, the abnormal handling process start flag is detected, the instruction opcode and target address are recorded one by one, the register status values ​​before and after the instruction are associated, and the abnormal stimulus response instruction sequence is arranged in chronological order.

[0009] Preferably, the steps for obtaining the firmware branch jump path graph are as follows: Based on the abnormal stimulus response instruction sequence, conditional jump instructions and function call instructions are filtered, the start address and target address of each instruction are read, the return address field of the function call instruction is extracted, basic blocks are divided according to the control transfer boundary, each basic block is marked with a unique identifier and connected with directed edges, duplicate and isolated nodes are removed, and a firmware branch jump path graph is generated.

[0010] Preferably, the step of obtaining the driver vulnerability detection behavior fingerprint is as follows: Calculate the path difference degree based on the firmware branch jump path diagram; Based on the path difference degree, according to the node connection relationship of the firmware branch jump path graph, the number of jumps to undefined memory regions is identified, the number of nodes trapped in infinite loops is calculated, and combined with the path difference degree to generate a driver vulnerability detection behavior fingerprint.

[0011] Preferably, the step of obtaining the interrupt service execution time window is as follows: Based on the suspicious operation phase marked by the driver vulnerability detection behavior fingerprint, real-time monitoring of the firmware interrupt service routine is initiated, the target interrupt vector number is located and the start and end times of each interrupt trigger are captured, the number of instruction execution clock cycles for a single execution is calculated, and the interrupt service execution time window is generated by arranging them in chronological order.

[0012] Preferably, the step of obtaining the timing dispersion value of the interrupt hook is as follows: Based on the interrupt service execution time window, outliers are removed while maintaining time continuity. The average number of clock cycles is calculated, and the interrupt vector number and sampling time period corresponding to the average value are marked to obtain the average number of clock cycles. Calculate the interrupt hook timing dispersion value based on the average number of clock cycles. Based on the interrupt hook timing dispersion value, the interrupt hook behavior is identified and firmware integrity verification is triggered.

[0013] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, a virtualized environment adapted to the firmware under test is constructed, and the address ranges of the virtual network card and USB controller registers are configured. A virtual peripheral protocol parsing tree is generated, and a buffer write boundary threshold is set. A high-fit peripheral communication compliance constraint set is established. Simulation of the firmware's underlying interaction behavior is achieved without dependence on physical hardware. Based on this constraint set, firmware write parameters are intercepted, and boundary overflow simulation feedback signals are injected. This proactively triggers the firmware to enter an exception handling process and records the response instruction sequence. Furthermore, a branch path graph is constructed by extracting jump and call instructions, and the number of jumps to undefined memory regions and infinite loop nodes are statistically analyzed. The differences are compared with the normal reset process to generate driver... Dynamic vulnerability fingerprinting, which combines proactive incentives with path differential analysis, effectively addresses the challenge of static analysis covering dynamic execution logic. It identifies advanced attack methods such as control flow hijacking and abnormal privilege escalation. Furthermore, by combining interrupt timing discrete analysis and continuously recording the number of clock cycles corresponding to the instruction execution of the target interrupt vector and calculating the time window and discreteness value, it can identify hidden interrupt hooking behavior from a micro-time dimension. This overcomes the limitations of traditional sandboxes that only focus on the functional level. By utilizing timing side-channel characteristics, it can uncover malicious code lurking at the underlying level, improve the detection success rate and false alarm suppression capability against unknown firmware vulnerability exploits and persistent attacks, and achieve the perception of deep security threats to embedded devices. Attached Figure Description

[0014] Figure 1 This is a system flowchart of the present invention. Detailed Implementation

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

[0016] Please see Figure 1 This invention provides a technical solution: a malicious firmware vulnerability exploitation detection system based on sandbox behavior analysis, comprising: The protocol parsing constraint establishment module loads the firmware to be tested according to the sandbox environment, configures the register address range of the virtual network card and virtual USB controller, generates a virtual peripheral protocol parsing tree, traverses the leaf nodes in the virtual peripheral protocol parsing tree, extracts the register read and write permission bits and the maximum transmission unit value of the data packet, sets the boundary threshold for buffer writing, and generates a set of peripheral communication compliance constraints. The peripheral boundary anomaly feedback module intercepts the configuration parameters and data load written by the firmware to the virtual peripheral based on the peripheral communication compliance constraint set, determines and generates a boundary overflow simulation feedback signal, injects the boundary overflow simulation feedback signal into the firmware running process, triggers the firmware to enter the anomaly handling process, and records the generated anomaly stimulus response instruction sequence. The firmware response branch monitoring module extracts conditional jump instructions and function call instructions from the abnormal stimulus response instruction sequence, generates a firmware branch jump path graph, counts the number of jumps to undefined memory regions and the number of nodes trapped in infinite loops in the firmware branch jump path graph, compares the path difference with the normal reset process, and generates a driver vulnerability detection behavior fingerprint. The interrupt timing discrete analysis module continuously records the number of instruction execution clock cycles corresponding to the target interrupt vector number based on the suspicious operation phase marked by the driver vulnerability detection behavior fingerprint, generates an interrupt service execution time window, calculates and generates an interrupt hook timing discrete value based on the interrupt hook timing discrete value, identifies interrupt hook behavior based on the interrupt hook timing discrete value, and triggers firmware integrity verification.

[0017] The steps for obtaining the peripheral communication compliance constraint set are as follows: Load the firmware to be tested according to the sandbox environment, configure the virtual network card register address range, configure the virtual USB controller register address range, read the field name and bit width at the byte offset position according to the header format of the firmware peripheral communication protocol, define the parsing length mark and effective payload start offset according to the load length, extract the name and length of fixed fields, extract the start and end marks and scaling rules of variable length field structures, and form a virtual peripheral protocol parsing tree. Based on the virtual peripheral protocol parse tree, traverse the leaf nodes of the virtual peripheral protocol parse tree, locate the target register according to the register address recorded in the leaf node, read the permission flag and distinguish between read and write bits, calculate the maximum transmittable length of the payload length field on all leaf node paths as the maximum transmission unit value of the data packet, determine the boundary threshold for buffer writing based on the maximum transmission unit value of the data packet, and filter out the illegal instruction code set according to the firmware instruction set encoding range to form the register read / write permission bits, the maximum transmission unit value of the data packet, the boundary threshold for buffer writing and the illegal instruction code set; Based on register read / write permission bits, the maximum transmission unit value of data packets, the boundary threshold for buffer writes, and the set of illegal instruction codes, a rejection condition is established for read and write bit mismatch requests, a truncation condition is established for requests exceeding the maximum transmission unit value of data packets, a blocking condition is established for write positions exceeding the boundary threshold for buffer writes, and an interruption condition is established for hitting the set of illegal instruction codes, thereby generating a set of peripheral communication compliance constraints.

[0018] Specifically, the firmware to be tested is loaded into the sandbox environment. The firmware image is initialized in QEMU or a similar full-system simulation environment, and an independent memory space is allocated. The binary code and data segments of the firmware are mapped to the virtual memory starting address 0x08000000. The register interaction area of ​​the virtual network card is set, and the 4KB space from physical address 0x40000000 to 0x40000FFF is marked as the network card control register group. The register address range of the virtual USB controller is defined, and the 4KB space from physical address 0x40001000 to 0x40001FFF is divided into USB status and command registers. The firmware communication protocol specification is read or the header definition is obtained through reverse engineering, and the data packet is offset from the starting byte. The protocol magic number (4 bytes wide) is read at position 0x00, and the command word (2 bytes wide) is read at offset position 0x04. The length marker is parsed according to the payload length definition, locating the 2-byte length field at offset position 0x06. Its value is used as the basis for subsequent payload reading. The payload start offset is set to the header end position, i.e., byte 0x08. The names and lengths of fixed fields are extracted; for example, the 4 bytes at offset 0x08 are defined as "Device ID," and the 4 bytes at offset 0x0C are defined as "Session Token." The start and end markers and scaling rules of variable-length field structures are extracted. String structures ending with 0xFF are identified, or the "Type-Length-Value" TLV format is used, where the value of the "Length" byte is read. And will follow closely behind Each byte is assigned to the content of this field. A tree-like data structure is used to organize the above parsing rules, with the protocol root as the vertex, each level of protocol header as a branch, and specific fields defined as leaf nodes, forming a virtual peripheral protocol parsing tree.

[0019] Based on the virtual peripheral protocol parse tree, initialize the traversal pointer, and use a depth-first search algorithm to traverse each leaf node of the virtual peripheral protocol parse tree. Accumulate the relative offset address of the register recorded in the leaf node with the base address to locate the specific 32-bit target register address, for example, 0x40000010. Read the access control attributes in the register definition, checking the 0th and 1st bits of the attribute byte. If the 0th bit is 1, it is marked as readable; if the 1st bit is 1, it is marked as writable, thus distinguishing between read and write bits. Calculate the maximum transmittable length of the payload length field across all leaf node paths. Accumulate the fixed field length and the maximum allowed length of the variable field in all branches of the protocol tree, and select the maximum value among all accumulated values ​​as the maximum transmission unit (MTU) value for the data packet. For example, if the calculated maximum value is 1518 bytes, determine the buffer write boundary threshold based on the MTU value. The boundary threshold calculation formula is set as follows: ,in, The boundary threshold for writing to the buffer. The maximum transmission unit value obtained from the aforementioned calculation (e.g., 1518 bytes). For safety redundancy, the value is taken as a multiple of the CPU architecture word length, such as 16 bytes, to accommodate possible alignment padding. Illegal instruction code sets are filtered out based on the firmware instruction set encoding range. The firmware operating architecture is identified as ARMv7 or MIPS32. The encoding range of legal instruction opcodes is determined, for example, 0x00000000 to 0xEFFFFFFF. Reserved instruction areas, undefined instruction codes, and privileged instruction codes (in user mode) are extracted. A hash table-like illegal instruction code set is constructed, forming register read / write permission bits, maximum data packet transmission unit value, buffer write boundary threshold, and illegal instruction code set.

[0020] Based on register read / write permission bits, the maximum transmission unit (MTU) value of data packets, the buffer write boundary threshold, and the illegal instruction code set, access control logic is configured to establish rejection conditions for read and write bit mismatch requests. When a write operation request for a specific register address is received, the permission table is queried. If the write permission bit for that address is marked as 0, a rejection response signal is generated. A truncation condition is established for data packets exceeding the MTU value. During the data packet reassembly phase, the cumulative length is monitored in real time. If the currently received data length... Greater than If this happens, receiving will be forcibly stopped and subsequent data will be discarded. This represents the number of bytes of data currently buffered. To set the maximum transfer unit value, establish a blocking condition for write positions that exceed the buffer write boundary threshold. Monitor the movement trajectory of the memory write pointer, calculate the difference between the current write address and the buffer start address, and if this difference is greater than the previously calculated value... If the write operation is immediately frozen and the memory region is locked, an interrupt condition is established for hitting the illegal instruction code set. During the instruction prefetching phase, the opcode of the current instruction is compared. If the opcode exists in the hash table of the illegal instruction code set, a hardware exception interrupt signal is triggered, and a peripheral communication compliance constraint set is generated.

[0021] The steps for obtaining the boundary overflow simulation feedback signal are as follows: Based on the peripheral communication compliance constraint set, the virtual peripheral write path is attached, the configuration parameter fields, data payload length, request address, target register and write offset are recorded, the data payload length is compared with the boundary threshold, the existence status of the request address in the illegal instruction code set is retrieved, and the data violation judgment result is obtained. Based on the data violation determination results, the error category code, violation field index, excessively long difference, and hit instruction code are filled into the error status code. The interrupt vector number and trigger priority are set, and it is encapsulated as an interrupt request carrying the error status code to generate a boundary overflow simulation feedback signal.

[0022] Specifically, based on the peripheral communication compliance constraint set, and utilizing the memory access callback mechanism of the sandbox environment, a write interception function targeting the virtual peripheral address space is registered in the virtual CPU's memory management unit. When the firmware program attempts to execute a write instruction to the virtual peripheral region with a physical address range of 0x40000000 to 0x40001FFF, the CPU's execution pipeline is paused and the current write context is captured. Configuration parameter fields are extracted from the operands of the write instruction, and the data payload length is parsed from the header definition of the data buffer. For example, the length value is obtained by reading two bytes at offset 0x04. Simultaneously, it records the source address and destination register address of the write request, as well as the write offset relative to the base address, and calls the pre-generated buffer to write the boundary threshold. The extracted data payload length With boundary threshold Perform a numerical comparison, if If it is, it is determined to be a buffer overflow attempt, for example when Captured when set to 1534 bytes When the length is 1600 bytes, the length violation status is marked as true. At the same time, the content of the memory segment pointed to by the requested address is extracted and hash-matched with the set of illegal instruction codes. Specifically, the hash value of the instruction sequence at the requested address is calculated. and in the illegal instruction hash table Search within, if If the result is not found, it is determined to be a malicious code injection attempt. Based on the above length comparison results and instruction matching results, a data structure containing a violation type bitmask, violation value details and the context of the time of occurrence is constructed to obtain the data violation judgment result.

[0023] Based on the data violation determination results, the firmware's exception feedback mechanism is instantiated and configured. First, the bitmask in the data violation determination results is parsed. If the mask indicates a buffer overflow error, the error category code is set to 0x01; if it indicates a command violation, it is set to 0x02. The position index of the specific field causing the violation in the communication protocol is located; for example, if the third field is faulty, the index value is recorded as 0x03. The excessive length difference is then calculated. The calculation formula is: ,in For very long differences, The actual length of the data payload that was attempted to be written. The maximum transmission unit (MTU) value defined in the preceding steps is used. If the result is negative, it is set to zero. For example, subtracting the MTU value of 1518 bytes from the actual length of 1600 bytes yields a difference of 82 bytes. This difference is filled into the reserved high-order area of ​​the error status register. If an illegal instruction is hit, the 32-bit binary code of the instruction is directly filled into the low-order area of ​​the status register. The virtual processor's interrupt vector table is consulted, and an external interrupt vector number not occupied by the system kernel is selected. For example, vector number [vector number missing in original text]. Set its interrupt trigger priority To ensure that the feedback signal can preempt the current task, the 32-bit status word containing the error category code, field index, long difference, and instruction code is written into the status register of the virtual interrupt controller. A level trigger signal is sent to the IRQ pin of the virtual CPU, which is encapsulated as an interrupt request carrying an error status code, and a boundary overflow simulation feedback signal is generated.

[0024] The steps for obtaining the abnormal stimulus response command sequence are as follows: Based on the boundary overflow simulation feedback signal, the interrupt entry point of the firmware running process is injected, the start flag of the exception handling process is detected, the instruction opcode and target address are recorded one by one, the register status values ​​before and after the instruction are associated, and the exception stimulus response instruction sequence is arranged in chronological order.

[0025] Specifically, based on the boundary overflow simulation feedback signal, an interrupt signal is injected directly into the main thread of the firmware running process through the sandbox's hardware simulation layer. This forces the CPU to save the current context and jump to the service routine entry address corresponding to the interrupt vector number. A program counter monitoring breakpoint is set in the sandbox debugger. When the value of the program counter PC equals the entry address of the interrupt service routine, it is determined that the exception handling process start flag has been triggered, and the instruction-level tracing recording mode is started. After each clock cycle, the machine code in the instruction register is read and disassembled into instruction opcodes. The target memory address corresponding to the operand is read. At the same time, through the register file snapshot interface, the current value status of general-purpose registers R0 to R15 is read to establish a mapping relationship between instructions and register status, such as recording the time. When executing the instruction LDR R0, [R1], the value of R0 after execution and the address value of R1 are associated and continuously tracked until an exception return instruction is detected or the preset instruction limit is reached, such as tracking the first 500 instructions. All captured records are organized into a linked list according to the execution timestamp, and no-operation and debugging interrupt instructions are removed. Substantive processing logic steps are retained and arranged into an exception stimulus response instruction sequence in chronological order.

[0026] The steps to obtain the firmware branch jump path diagram are as follows: Based on the sequence of abnormal stimulus response instructions, conditional jump instructions and function call instructions are filtered, the start address and target address of each instruction are read, the return address field of the function call instruction is extracted, basic blocks are divided according to the control transfer boundary, each basic block is marked with a unique identifier and connected with directed edges, duplicate and isolated nodes are removed, and a firmware branch jump path graph is generated.

[0027] Specifically, based on the sequence of exception stimulus response instructions, the disassembler analyzes the binary machine code line by line to identify the control flow transfer instructions. For ARM architecture firmware, opcodes such as B, BL, BX, and POP {PC} are prioritized; for MIPS architecture firmware, opcodes such as J, JAL, and JR are prioritized. The program counter value in memory for each selected instruction is read as the starting address. The immediate offset or register value in the instruction operands is analyzed to calculate the target address for the jump. The return address field after the function call instruction is executed is extracted; this address is usually located at the instruction following the call instruction or specified by the link register LR. Based on the distribution of control transfer instructions, the linear instruction sequence is divided into multiple basic blocks. The starting position of each basic block is set as the target address of the jump instruction or the first instruction after the previous jump instruction. The ending position of the basic block is set as the jump instruction itself or the instruction preceding the unconditional jump instruction. The calculation of each... The hash value of the instruction byte sequence contained in each basic block is used as a unique identifier to mark each basic block. The instruction execution order record is traversed, and a directed connection is established between two adjacent basic blocks. The exit of the source basic block is pointed to the entry of the target basic block, forming a preliminary directed graph structure. All nodes of the directed graph are traversed, and the in-degree and out-degree of each node are counted. Isolated nodes with an in-degree of zero and not an entry point, as well as dead code nodes with an out-degree of zero and no valid termination operation, are located. These duplicate nodes and isolated nodes that do not contribute to the control flow analysis are deleted from the adjacency list. The index of the remaining nodes is reorganized to optimize the storage space of the graph, and a firmware branch jump path graph is generated.

[0028] The steps for obtaining the fingerprint of driver vulnerability detection behavior are as follows: Based on the firmware branch jump path diagram, the path difference is calculated using the following formula: ; in, For path difference, This is the set of directed edges for the abnormal execution process. This is the set of directed edges for the normal reset process. For the edge Weights in the abnormal path graph For the edge Weights in a normal path graph, and edges The formula for calculating the weight is as follows: , For the edge The execution frequency of the edge indicates the execution frequency of the edge. The number of times it is traversed in the corresponding execution sequence. For source basic blocks The number of instructions represents the static complexity starting from the source basic block; Based on the path difference degree, according to the node connection relationship of the firmware branch jump path graph, the number of jumps to undefined memory regions is identified, the number of nodes trapped in infinite loops is calculated, and combined with the path difference degree, a driver vulnerability detection behavior fingerprint is generated.

[0029] Specifically, the path difference calculation formula quantifies the degree of control flow deviation of the firmware under abnormal excitation by using a weighted Jaccard distance variant, introducing static complexity. With dynamic execution frequency The combination of these factors gives higher weight to path segments containing complex logic and frequently executed segments in the difference calculation, thereby capturing abnormal jump behavior triggered by vulnerabilities. The steps for obtaining parameters are as follows: traverse the instruction execution trajectory recorded during firmware operation, and count each directed edge. (i.e., from basic blocks) Jump to basic block The total number of times an event occurs in the trajectory. For example, in a sequence of 1000 instructions, if the action of jumping from address 0x08001000 to 0x08002000 occurs 50 times, then the execution frequency of that edge is... It is denoted as 50, and this parameter directly reflects the heat and loop characteristics of the code; The steps to obtain the parameters are as follows: for the directed edge... The starting basic block Perform static disassembly analysis to count the number of machine instructions contained within the basic block. This count does not distinguish between instruction types; it only counts the number of valid instructions, such as those within a basic block. Starting from entry address 0x08001000 and ending at 0x08001020, it contains eight instructions, each 4 bytes wide. It is denoted as 8, and this parameter reflects the logical complexity of the path node; Calculations based on parameters: Choose a calculation example, such as the normal reset procedure. Includes edges and Abnormal execution process Includes edges and ; For the edge (exists) and Let the number of source basic block instructions be... Frequency in normal process Frequency in abnormal processes , Calculate normal weights , Calculate the outlier weights ; For the edge (Only exists in) Let the number of source basic block instructions be... ,frequency , Calculate normal weights Abnormal weights ; For the edge (Only exists in) Let the number of source basic block instructions be... ,frequency , Calculate the outlier weights Normal weight ; Calculate the numerator (Min total sum): ; Calculate the denominator (Max sum): ; Substitute into the formula to calculate the path difference: ; The results indicate that there are significant differences in the control flow paths between the abnormal and normal processes, with a value of 0.875 close to 1. This means that the abnormal stimulus caused the firmware to execute a large number of paths that did not appear in the normal reset process or the execution frequency of the original paths changed drastically, suggesting that there may be control flow hijacking behavior caused by vulnerability exploitation.

[0030] The steps to obtain the interrupted service execution time window are as follows: Based on the suspicious operation phase marked by the driver vulnerability detection behavior fingerprint, real-time monitoring of the firmware interrupt service routine is initiated, the target interrupt vector number is located and the start and end times of each interrupt trigger are captured, the number of instruction execution clock cycles for a single execution is calculated, and the interrupt service execution time window is generated by arranging them in chronological order.

[0031] Specifically, based on the path difference, the adjacency matrix data of the firmware branch jump path graph generated in the previous steps is called. This is combined with the memory layout configuration file preset by the sandbox environment. This configuration file defines in detail the legal address ranges for the code segment, data segment, stack segment, and peripheral mapping area. For example, the code segment range is set to 0x08000000 to 0x080FFFFF. The target node addresses of all directed edges in the path graph are traversed, and each target address is compared with the legal address range. If a target address is found to fall into an undefined memory region or a memory region with non-executable attributes, for example, a jump to 0x... If the jump is within the RAM data area of ​​20000000 or the null pointer area of ​​0x00000000, it is recorded as an illegal jump and the count is accumulated. Simultaneously, a depth-first search algorithm is used to perform loop detection on the path graph to identify any closed loop structures that cannot be escaped. This involves searching for strongly connected components in the directed graph and checking if any nodes in these components lack valid exit edges pointing to the outside of the component. If such an infinite loop structure exists, the total number of nodes constituting the loop is counted. The calculated illegal jump count, the number of infinite loop nodes, and the path difference are compared with the previously calculated path difference. Numerical concatenation and standardization are performed to construct a feature vector containing three dimensions, such as vector... , representing the degree of difference, the number of illegal jumps, and the number of loop nodes, respectively, to generate a fingerprint of the driver vulnerability detection behavior.

[0032] The steps for obtaining the timing dispersion value of the interrupt hook are as follows: Based on the interrupt service execution time window, outliers are removed while maintaining time continuity. The average number of clock cycles is calculated, and the interrupt vector number and sampling time period corresponding to the average value are marked to obtain the average number of clock cycles. The interrupt hook timing dispersion value is calculated based on the average number of clock cycles. The calculation formula is as follows: ; in, This represents the timing dispersion value for interrupt hooking. The number of sampling points. The number of clock cycles for instruction execution at the i-th sampling point. This is the average number of clock cycles. The asymmetric weighting factor for the i-th sampling point is calculated using the following formula: , This is the positive bias sensitivity factor, a constant parameter used to amplify the effect when the execution time is higher than the average. Based on the timing dispersion value of the interrupt hook, the interrupt hook behavior is identified and firmware integrity verification is triggered.

[0033] Specifically, based on the suspicious execution phases identified by the driver vulnerability detection behavior fingerprint, and utilizing the debugging interface of the full system emulator or the introspection mechanism of the virtual machine monitor, when the firmware is detected entering an execution phase marked as high-risk, such as processing network packets of a specific format or performing complex encryption operations, the fine-grained tracing function for the interrupt controller is immediately activated. The value of the interrupt vector table offset register is read to determine the base address of the interrupt vector table. Combined with the interrupt request number of the target peripheral, the corresponding interrupt service routine entry address is calculated. An execution trap is set at the first instruction of the interrupt service routine, and an exit trap is set at the interrupt return instruction such as IRET or BX LR. When the simulated processor's program counter PC points to the entry address, the current hardware clock cycle counter value is read. When the PC points to the exit address, the clock cycle counter value is read again. Calculate the difference As the number of instruction execution clock cycles for a single interrupt service, this capture process is repeated until a number of samples meeting statistical significance requirements is collected. For example, the sampling number can be set to 100 consecutive interrupt events, or continuous monitoring can be performed until the time span reaches 500 milliseconds. All acquired samples will be recorded. The values ​​are stored in a first-in-first-out circular buffer queue according to the timestamp of capture, and the specific capture time and interrupt vector ID corresponding to each value are recorded to generate an interrupt service execution time window. Based on the interrupt service execution time window, the instruction execution clock cycle sequence stored in the buffer queue is read. An anomaly detection algorithm based on statistical distribution is used to clean the raw data, and the average value of all data within the window is calculated. and standard deviation Set the valid data determination interval as The interval is defined based on the normal distribution. The principle is to cover approximately 95% of normal data points. It iterates through the samples for each clock cycle in the queue, marking values ​​outside the specified range as noise caused by simulator jitter or nondeterministic hardware latency and discarding them. The number of remaining valid samples is then counted. ,like If the sample size falls below a preset minimum threshold (e.g., 80% of the original number), the sampling window is expanded to reacquire data to ensure statistical reliability. All retained valid clock cycles are summed and divided by the number of valid samples. The corrected average clock cycle count is obtained. This average is then mapped to the currently monitored interrupt vector number (e.g., vector number 45) using a key-value pair. The start and end timestamps of the current sampling window (e.g., 10:00:01.000 to 10:00:01.500) are appended as time context labels to obtain the average clock cycle count. An asymmetric weighting factor is introduced into the formula for the timing dispersion value of the interrupt hook. We construct a weighted standard deviation that is sensitive to positive bias. By amplifying the influence of samples whose execution time exceeds the average, we can identify minute delay features caused by malicious code hooks. Unlike regular performance jitter (which usually follows a normal distribution), malicious hooks inevitably lead to an extended execution path, resulting in a unidirectional increase in time. This can effectively improve the signal-to-noise ratio for detecting such anomalies. The steps for obtaining the parameters are as follows: Count the total number of valid samples within the preprocessed interrupt service execution time window. For example, after noise removal, retain 5 valid clock cycle samples for demonstration calculations. The value is 5, and this parameter represents the sample size for statistical analysis. The steps for obtaining the parameters are as follows: read the parameters sequentially from the time-consuming window. The number of instruction execution clock cycles per valid sampling point, with the unit of the value being clock cycles. For example, if the 5 samples collected are 1980, 1990, 2000, 2010, and 2220, this value reflects the actual overhead of a single interrupt processing. The steps to obtain the parameters are as follows: calculate all valid samples within the current window. The average value is calculated using the following formula: Based on the above 5 sample data, calculate ,Right now The cycle is 2040, and this value serves as a baseline to measure the degree of deviation in a single execution. The steps for obtaining the parameters are as follows: the positive deviation sensitivity factor is set to a constant of 10. This value is set based on the fact that different length jump instructions are injected into the interrupt program in a controlled sandbox environment. Through multiple regression tests, it was found that when... At the same time, it can amplify hooking behavior that only increases execution time by 5% to 10% to a significantly distinguishable level in the final dispersion index, while maintaining a low false alarm rate for normal jitter. Calculations based on parameters: Based on the above sample data: , , Sample set ; Calculate the first 4 samples (all less than or equal to the mean 2040, therefore...) ): Sample 1 (1980): Deviation Ratio Squared terms Weighted items ; Sample 2 (1990): Deviation Ratio Squared terms Weighted items ; Sample 3 (2000): Deviation Ratio Squared terms Weighted items ; Sample 4 (2010): Deviation Ratio Squared terms Weighted items ; Calculate the 5th sample (2220, greater than the mean 2040, triggering weight amplification): deviation ratio ; Weight ; Squared terms ; Weighted Items ; Summation and averaging: sum ; average value ; The final result is obtained by taking the root: ; This result indicates that: Calculated The value is 0.0578. This value is compared with a preset safety benchmark threshold (e.g., 0.03, which is derived from statistical data from a large number of normal firmware runs, under normal jitter). Comparing the values ​​(usually less than 0.03), since 0.0578 is significantly greater than 0.03, it indicates that the execution timing of the interrupt service routine has abnormal dispersion, mainly contributed by the positive delay (sample 2220). This suggests that the processing function corresponding to the interrupt vector is very likely to have been injected with malicious hook code, thereby triggering the firmware integrity verification process.

Claims

1. A malicious firmware exploit detection system based on sandbox behavior analysis, characterized in that, The system comprises: A protocol analysis constraint establishment module loads the to-be-detected firmware according to a sandbox environment, configures register address ranges of a virtual network card and a virtual USB controller, generates a virtual peripheral protocol analysis tree, traverses leaf nodes in the virtual peripheral protocol analysis tree, extracts register read-write permission bits and a data packet maximum transmission unit value, sets a boundary threshold for buffer writing, and generates a peripheral communication compliance constraint set; A peripheral boundary exception feedback module intercepts configuration parameters and data loads written by the firmware to a virtual peripheral according to the peripheral communication compliance constraint set, judges to generate a boundary overflow simulation feedback signal, injects the boundary overflow simulation feedback signal into a firmware running process, triggers the firmware to enter an exception handling process, and records a generated exception excitation response instruction sequence; A firmware response branch monitoring module extracts conditional jump instructions and function call instructions in the exception excitation response instruction sequence according to the exception excitation response instruction sequence, generates a firmware branch jump path graph, counts the number of jumps to undefined memory areas and the number of nodes falling into infinite loops in the firmware branch jump path graph, compares path difference degrees of a normal reset process, and generates a driving vulnerability detection behavior fingerprint; An interrupt timing discrete analysis module records the number of instruction execution clock cycles corresponding to a target interrupt vector number in a continuous manner according to a suspicious running stage marked by the driving vulnerability detection behavior fingerprint, generates an interrupt service execution time window, calculates an interrupt hook timing discrete degree value according to the interrupt service execution time window, identifies an interrupt hook behavior according to the interrupt hook timing discrete degree value, and triggers firmware integrity verification.

2. The sandbox behavior analysis based malicious firmware exploit detection system of claim 1, wherein, The obtaining step of the peripheral communication compliance constraint set is: The to-be-detected firmware is loaded according to a sandbox environment, register address ranges of a virtual network card are configured, register address ranges of a virtual USB controller are configured, a field name and a bit width are read at a byte offset position according to a header format of a firmware peripheral communication protocol, a load length definition is parsed to obtain a parsing length marker and a payload start offset, the name and length of a fixed field are extracted, start and end markers and a telescopic rule of a variable-length field structure are extracted, and a virtual peripheral protocol analysis tree is formed; Leaf nodes of the virtual peripheral protocol analysis tree are traversed according to the virtual peripheral protocol analysis tree, a target register is located according to a register address recorded by the leaf node, permission bit flag bits are read and distinguished as read bits and write bits, a maximum transmissible length of a load length field on all leaf node paths is counted as a data packet maximum transmission unit value, a boundary threshold for buffer writing is determined according to the data packet maximum transmission unit value, an illegal instruction code set is screened out according to a firmware instruction set coding interval, and register read-write permission bits, the data packet maximum transmission unit value, the boundary threshold for buffer writing, and the illegal instruction code set are formed. According to the register read-write permission bit, the data packet maximum transmission unit value, the buffer write boundary threshold and the illegal instruction code set, a rejection condition for a read bit and a write bit mismatch request is established, a truncation condition for a length exceeding the data packet maximum transmission unit value is established, a blocking condition for a write position crossing the buffer write boundary threshold is established, an interruption condition for hitting the illegal instruction code set is established, and a peripheral communication compliance constraint set is generated.

3. The sandbox behavior analysis based malicious firmware exploit detection system of claim 1, wherein, The acquisition step of the boundary overflow simulation feedback signal is: According to the peripheral communication compliance constraint set, a virtual peripheral write path is hung, a configuration parameter field, a data load length, a request address, a target register and a write offset are recorded, the data load length is compared with the boundary threshold, the existence state of the request address in the illegal instruction code set is searched, and a data violation judgment result is obtained; According to the data violation judgment result, an error category code, a violation field index, an overlength difference and a hit instruction code in an error status code are filled, an interruption vector number and a trigger priority are set, an interruption request carrying the error status code is packaged, and a boundary overflow simulation feedback signal is generated.

4. The sandbox behavior analysis based malicious firmware exploit detection system of claim 1, wherein, The acquisition step of the abnormal excitation response instruction sequence is: According to the boundary overflow simulation feedback signal, an interruption entry of a firmware running process is injected, an abnormal processing flow start flag is detected, instruction operation codes and target addresses are recorded one by one, register state values before and after instructions are associated, and an abnormal excitation response instruction sequence is arranged in time sequence.

5. The sandbox behavior analysis based malicious firmware exploit detection system of claim 1, wherein, The acquisition step of the firmware branch jump path graph is: According to the abnormal excitation response instruction sequence, conditional jump instructions and function call instructions are screened, starting addresses and target addresses of each instruction are read, return address fields of function call instructions are extracted, basic blocks are divided according to control transfer boundaries, unique identifiers of each basic block are marked and connected with directed edges, repeated and isolated nodes are removed, and a firmware branch jump path graph is generated.

6. The sandbox behavior analysis based malicious firmware exploit detection system of claim 1, wherein, The acquisition step of the driving vulnerability detection behavior fingerprint is: According to the firmware branch jump path graph, a path difference degree is calculated; According to the path difference degree, a jump number pointing to an undefined memory region is identified according to the node connection relationship of the firmware branch jump path graph, the number of nodes falling into an infinite loop is calculated, and the path difference degree is combined to generate a driving vulnerability detection behavior fingerprint.

7. The sandbox behavior analysis based malicious firmware exploit detection system of claim 1, wherein, The acquisition step of the interruption service execution time-consuming window is: According to the suspicious running stage marked by the driving vulnerability detection behavior fingerprint, real-time monitoring of a firmware interruption service program is started, a target interruption vector number is located and the start and end times of each interruption trigger are captured, the number of instruction execution clock cycles of a single execution is calculated, the time sequence is arranged, and an interruption service execution time-consuming window is generated.

8. The sandbox behavior analysis based malicious firmware exploit detection system of claim 1, wherein, The acquisition step of the interruption hooking time sequence dispersion value is: According to the interruption service execution time-consuming window, sampling abnormal values are removed and time continuity is maintained, the average value of the total number of clock cycles is calculated, the interruption vector number and the sampling time period corresponding to the average value are marked, and the average value of the number of clock cycles is obtained; According to the average value of the number of clock cycles, the interruption hooking time sequence dispersion value is calculated; Based on the interrupt hook timing dispersion value, an interrupt hook behavior is identified and a firmware integrity verification is triggered.

Images