An Internet of Things firmware testing method, apparatus, device and medium
By detecting and building DMA input channels in a virtualized environment, the problem that firmware hosting technology cannot simulate DMA inputs is solved, the types of emulated devices and code coverage are expanded, and the security of embedded devices is improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- INFORMATION & COMM BRANCH OF STATE GRID JIANGSU ELECTRIC POWER
- Filing Date
- 2025-03-06
- Publication Date
- 2026-06-09
Smart Images
Figure CN120179536B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer network space security technology, and in particular to an Internet of Things firmware testing method, apparatus, device and medium. Background Technology
[0002] With the rapid development of the Internet of Things (IoT), the number of embedded devices has increased dramatically. However, because the firmware design of embedded devices is usually relatively simple and resource-constrained, the firmware is vulnerable to attacks, resulting in numerous security vulnerabilities. In particular, embedded devices store a large amount of user privacy data, and potential security vulnerabilities could lead to serious privacy breaches.
[0003] In existing embedded device security research, dynamic firmware analysis has become the mainstream method in academia due to its high efficiency and low false alarm rate. To achieve dynamic firmware analysis, the firmware program needs to be actually executed. However, firmware relies on real hardware peripherals during execution, which presents challenges to existing firmware emulation techniques, such as cumbersome manual analysis and poor applicability.
[0004] To address this, firmware re-hosting was proposed, allowing firmware to run in a virtualized environment, thus reducing reliance on physical hardware. However, existing firmware re-hosting technologies cannot emulate direct memory access (DMA) inputs, significantly limiting the types of embedded devices that can be emulated and the scope of firmware code coverage. Summary of the Invention
[0005] This invention provides an IoT firmware testing method, apparatus, device, and medium to address the problem that existing firmware hosting technologies cannot simulate Direct Memory Access (DMA) inputs, which greatly limits the types of embedded devices that can be simulated and the coverage of firmware code.
[0006] In a first aspect, embodiments of the present invention provide an IoT firmware testing method, the method comprising:
[0007] Upon receiving the target firmware boot command, the target firmware is loaded and the target pointer of the target firmware pointing to the direct memory access DMA memory region is detected. The target pointer includes a source address pointer and a destination address pointer.
[0008] When a target pointer pointing to a DMA memory region is detected, the target DMA transfer descriptor is determined based on the target pointer and a target DMA input channel is constructed.
[0009] The destination address pointer is obtained based on the target DMA transfer descriptor;
[0010] The target firmware is executed based on the target DMA input channel according to the destination address pointer and the pointer value is stored.
[0011] Monitor the operation of the target firmware and generate test results based on the results.
[0012] Secondly, embodiments of the present invention provide an Internet of Things firmware testing device, the device comprising:
[0013] The target pointer detection module is used to load the target firmware and detect the target pointer that the target firmware points to the direct memory access DMA memory region when the target firmware boot instruction is received. The target pointer includes a source address pointer and a destination address pointer.
[0014] The descriptor and channel determination module is used to determine the target DMA transfer descriptor and construct the target DMA input channel based on the target pointer when the target firmware is detected to point to a target memory region.
[0015] The pointer value determination module is used to obtain the pointer value of the destination address pointer based on the target DMA transfer descriptor;
[0016] The firmware execution module is used to store the pointer value according to the destination address pointer through the target DMA input channel, and to run the target firmware according to the pointer value;
[0017] The test result generation module is used to monitor the operation process of the target firmware and generate test results based on the operation results.
[0018] Thirdly, embodiments of the present invention provide an electronic device, the electronic device comprising:
[0019] At least one processor;
[0020] and a memory communicatively connected to the at least one processor;
[0021] The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the IoT firmware testing method according to any embodiment of the present invention.
[0022] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute the IoT firmware testing method described in any embodiment of the present invention.
[0023] The technical solution of this invention, upon receiving a target firmware boot command, loads the target firmware and detects a target pointer pointing to a Direct Memory Access (DMA) memory region. This target pointer includes a source address pointer and a destination address pointer. When the target pointer is detected, a target DMA transfer descriptor is determined based on the target pointer, and a target DMA input channel is constructed. The destination address pointer's value is obtained based on the target DMA transfer descriptor. The target DMA input channel stores the value based on the destination address pointer, and the target firmware is run based on the value. The execution process of the target firmware is monitored, and test results are generated based on the execution results. This method, by determining the target DMA transfer descriptor and constructing the target DMA input channel upon detecting the target pointer, obtaining the destination address pointer's value based on the target DMA transfer descriptor, and using the value to run the target firmware, and by generating test results based on the execution results of the target firmware, solves the problem that existing firmware hosting technologies cannot simulate DMA input. It expands the types of embedded devices that can be simulated and the code coverage for firmware testing, thereby improving the security of embedded devices.
[0024] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0026] Figure 1 A flowchart illustrating an IoT firmware testing method provided in an embodiment of the present invention;
[0027] Figure 2 This is a schematic diagram of the architecture of an IoT firmware testing method provided in an embodiment of the present invention;
[0028] Figure 3 This is a schematic diagram of the structure of an IoT firmware testing device provided in an embodiment of the present invention;
[0029] Figure 4 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation
[0030] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0031] It should be noted that the terms "target," "original," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0032] It should be noted that dynamic firmware analysis requires actual execution of the firmware program. To reduce the firmware's dependence on real hardware, firmware hosting methods have been proposed, allowing firmware to run in a virtualized environment. However, existing firmware hosting technologies cannot simulate Direct Memory Access (DMA) inputs, significantly limiting the types of embedded devices that can be emulated and the scope of firmware code coverage.
[0033] Based on this, embodiments of the present invention provide an IoT firmware testing method. Figure 1 This is a flowchart of an IoT firmware testing method provided by an embodiment of the present invention. The embodiment of the present invention can be applied to testing firmware, especially in scenarios where direct memory access input needs to be processed in firmware testing. The method can be executed by an IoT firmware testing device, which can be implemented in the form of software and / or hardware, or optionally by an electronic device, preferably a mobile terminal, desktop computer, laptop computer, or server.
[0034] like Figure 1 As shown, the IoT firmware testing method provided in this embodiment of the invention may specifically include:
[0035] S101. Upon receiving the target firmware boot instruction, load the target firmware and detect the target pointer that the target firmware points to the direct memory access DMA memory region. The target pointer includes a source address pointer and a destination address pointer.
[0036] The target firmware can be understood as firmware with testing requirements, which can be a firmware binary file in ELF format. The target firmware boot command can be understood as the command to start and run the firmware; it can be a command triggered by the client, or a command issued based on pre-defined conditions, either timed or automatically. The Direct Memory Access (DMA) memory region can be understood as a specially designated area within the memory region mapped by Memory Mapped Input / Output (MMIO) for storing data transferred via DMA. The source address pointer can be understood as a pointer to the source data address of the DMA transfer, and the destination address pointer can be understood as a pointer to the destination data address of the DMA transfer.
[0037] In this embodiment, when the target firmware boot command is received, a virtualization technology simulator such as QEMU or KVM can be used to load the target firmware into the memory area mapped by MMIO and start running the target firmware. At the same time, the memory access operations of the target firmware are monitored in real time to detect whether there is a target pointer pointing to the direct memory access DMA memory area during the operation of the target firmware, that is, whether the target firmware attempts to access the logic related to DMA input.
[0038] Understandably, hook mechanisms can be inserted into the memory access functions of the virtualization emulator to capture specific memory access operations during the target firmware's execution, thereby enhancing control over the memory access process. For example, if the virtualization emulator is QEMU, the specific implementation could be that during QEMU emulation, the `unassigned_mem_write` or `unassigned_mem_read` functions are called every time memory is accessed. These functions are originally used to handle read and write operations on unallocated memory. Conditional checks for DMA pointer and MMIO memory region accesses are added to these functions. When the target firmware attempts to access the DMA or MMIO memory region, the access behavior can be detected, and the memory access process can be taken over through the hook mechanism. Control after takeover is then handed over to the corresponding module for processing.
[0039] S102. When a target pointer pointing to the DMA memory region is detected by the target firmware, the target DMA transfer descriptor is determined according to the target pointer and the target DMA input channel is constructed.
[0040] The target DMA transfer descriptor can be understood as the DMA transfer descriptor corresponding to the target pointer. It is a data structure used to describe the detailed information of the DMA transfer, which may include the source address pointer, the destination address pointer, the transfer length (i.e., the size of the data to be transferred), the transfer mode (such as memory to memory, memory to peripheral, etc.), the interrupt flag (i.e. whether an interrupt is triggered after the transfer is completed) and other configuration information (such as data width, transfer direction, etc.).
[0041] In this embodiment, when a target pointer pointing to a DMA memory region is detected in the target firmware, the source address pointer and the destination address pointer are combined into a DMA buffer. The DMA buffer configuration information (such as the source address pointer, destination address pointer, transfer mode, etc.) is written into the target DMA transfer descriptor to avoid simulation crashes due to lack of hardware support. Furthermore, a target DMA input channel is dynamically created based on the source address, destination address, transfer length, and other information read by the target firmware to simulate the execution of the current DMA transfer.
[0042] It's important to note that DMA transfer is a continuous memory read / write process. However, due to the lack of physical hardware support, only the starting address of the buffer can be determined, but the length of the data transfer and the ending address of the buffer are unknown. Therefore, this process can be implemented using a heuristic DMA input channel algorithm. Specifically, this algorithm can dynamically create and close the target DMA input channel based on the currently identified target pointer, and provide the expected data input to the address pointed to by the destination address pointer.
[0043] S103. Obtain the value pointed to by the destination address pointer based on the target DMA transfer descriptor.
[0044] In this embodiment, the destination address pointer accessed by the target firmware is set as the symbolic variable to be solved. Based on the information in the target DMA transfer descriptor and related information in memory, dynamic symbolic execution is used to generate execution paths that satisfy specific constraints. The highest priority path is selected from these execution paths using path selection algorithms, intelligent algorithms, large language models, etc. The priority can be determined based on path length, covered branch conditions, etc. Then, further constraint solving is performed on the symbolic variable to be solved in the selected path to obtain the value pointed to by the destination address pointer.
[0045] It should be noted that the value pointed to by the destination address pointer will affect the subsequent running state and execution logic of the target firmware. Therefore, when choosing a path, it is advisable to access as much DMA-related logic in the target firmware as possible in the initial stage to uncover potential firmware vulnerabilities and prevent the entire simulation process from crashing. Finally, after exploring as many possible execution paths of the target firmware as possible, the existing firmware vulnerabilities can be identified from the crash results.
[0046] S104. Store the pointer value according to the destination address pointer through the target DMA input channel, and run the target firmware according to the pointer value.
[0047] In this embodiment, a fuzzing tool (such as AFL) can be used to store the pointer value to the destination address corresponding to the destination address pointer through the target DMA input channel. That is, the target firmware can receive the expected pointer value through the target DMA input channel and continue to run according to the received pointer value to complete the subsequent execution logic.
[0048] S105. Monitor the operation process of the target firmware and generate test results based on the operation results.
[0049] In this embodiment, the target firmware is monitored using a fuzzing tool. Potential vulnerabilities and errors are discovered based on the results, thereby generating test results that cover aspects such as firmware stability, path coverage, and vulnerability discovery. The test results may include the target firmware simulation success rate, path coverage data, and the number of crash triggers.
[0050] It should be noted that test results can be generated by the client triggering relevant controls based on requirements, or they can be generated periodically, such as every 24 hours.
[0051] This invention provides an IoT firmware testing method. Upon receiving a target firmware boot command, the method loads the target firmware and detects a target pointer pointing to a Direct Memory Access (DMA) memory region. The target pointer includes a source address pointer and a destination address pointer. When the target pointer is detected, a target DMA transfer descriptor is determined based on the target pointer, and a target DMA input channel is constructed. The destination address pointer's value is obtained from the target DMA transfer descriptor. The target DMA input channel stores the value based on the destination address pointer, and the target firmware is run based on the value. The running process of the target firmware is monitored, and test results are generated based on the running results. This method solves the problem that existing firmware hosting technologies cannot simulate DMA input, expands the types of simulable embedded devices and the code coverage for firmware testing, and thus improves the security of embedded devices.
[0052] As a first optional embodiment of this example, before receiving the target firmware boot command, the method further includes:
[0053] a1) Determine the attribute information of the target firmware through automated static analysis, and configure the memory region mapped by the memory-mapped input / output (MMIO) according to the attribute information. The attribute information includes: the size of random access memory required by the target firmware, the memory address mapping range, and the starting address information.
[0054] The memory region mapped by Memory Mapped Input / Output (MMIO) can be understood as the region that maps the registers of peripheral devices to the memory address space, and is used for the control and data interaction of embedded devices.
[0055] In this embodiment, the target firmware is analyzed using static analysis tools such as IDA Pro to obtain its attribute information. Based on this attribute information, the memory layout of the target firmware is analyzed to determine the address ranges of the code area, data area, and peripheral register area. For example, the memory range mapped to the peripheral register area of the embedded device STM 32F103 MCU can be from 0x40000000 to 0x5ffffff. Then, the peripheral register addresses of the target firmware are configured in the memory region mapped to MMIO, and the configuration is performed in a virtualization simulator based on the address range of the MMIO-mapped memory region.
[0056] The above-described technical solution in this embodiment configures the memory region mapped by MMIO according to the attribute information of the target firmware, ensuring the correct operation of the target firmware in a simulated environment without actual hardware, and providing strong support for testing embedded devices in a virtualized environment.
[0057] As a second optional embodiment of this example, before receiving the target firmware boot command, the method further includes:
[0058] a2) By placing hook functions in the memory region mapped by the memory-mapped input / output (MMIO), the target firmware's access operations to the memory region mapped by the MMIO can be captured and taken over.
[0059] Hook functions can be understood as a special type of callback function, used to execute custom logic when a specific event occurs.
[0060] In this embodiment, hook functions are pre-placed in the memory region mapped by MMIO, specifying all MMIO accesses within the memory region to capture the target firmware's access to the MMIO-mapped memory region. When the target firmware is detected reading or writing to the MMIO-mapped memory region, i.e., attempting to call peripheral logic, the hook function takes over the memory access process. A fuzzing tool can be invoked to provide specific input to the target firmware to maintain the continuous operation of the simulation process. Alternatively, control can be handed over to the appropriate module for processing. For example, when the target firmware accesses logic related to DMA input, a DMA transfer descriptor can be dynamically generated to simulate the DMA process, thereby ensuring the target firmware can execute smoothly and avoiding simulation crashes due to lack of hardware support.
[0061] The above-described technical solution in this embodiment captures and takes over the target firmware's access operations to the memory region by placing hook functions in the MMIO-mapped memory region. This enables the simulation of complex IoT firmware behavior without actual hardware peripherals, especially improving the accuracy and stability of the simulation in DMA input processing.
[0062] As a third optional embodiment of this example, based on the above embodiments, the step of obtaining the destination address pointer value according to the target DMA transfer descriptor can be specified as the following steps:
[0063] a3) Obtain the current basic block address information and context information.
[0064] In this context, a basic block can be understood as a continuous sequence of instructions in the firmware, containing no jump instructions (except for the last instruction of the basic block), and serving as the basic unit of the firmware execution path. The current basic block address information can be understood as information used to determine the location of the basic block currently being executed by the target firmware. Context information can be understood as information associated with the current running state of the target firmware, which may include current register information and memory information, etc.
[0065] In this embodiment, the current basic block address information and context information are obtained by the virtualization technology simulator.
[0066] b3) Determine the target code segment combination based on the current basic block address information, context information, and target DMA transfer descriptor.
[0067] The target code segment combination can be understood as the code path that the target firmware will execute in the current state.
[0068] In this embodiment, based on the current basic block address information, context information, and target DMA transfer descriptor, the destination address pointer is recorded as the symbolic value to be solved using a binary analysis tool based on symbolic execution and simulated execution (such as Angr). Then, code segment combinations are explored. By sorting all explored code segment combinations according to priority, the code segment combination with the highest priority is selected as the target code segment combination.
[0069] As one implementation, this optional embodiment can further specify the determination of the target code segment combination based on the current basic block address information, context information, and target DMA transfer descriptor as follows:
[0070] b31) Based on the current basic block address information, context information and target DMA transfer descriptor, the target firmware is image reconstructed to realize the simulated execution of the target firmware.
[0071] In this embodiment, the target firmware is converted into intermediate language (IR) based on the current basic block address information, context information and target DMA transfer descriptor to realize the image reconstruction of the target firmware. The reconstructed image can be divided into program blocks (i.e., divided into basic blocks) and dependency analysis through static analysis to determine each basic block, the dependency relationship between basic blocks, the current basic block and the symbol value to be solved (i.e. the destination address pointer).
[0072] b32) Starting from the current basic block, explore the next basic block forward, save the current basic block to the corresponding combination sequence, and use the next basic block as the new current basic block to explore forward to determine the new next basic block, until the preset number of branch jumps is reached or an exception is encountered and returned, and generate at least one candidate code segment combination according to the basic blocks in each combination sequence.
[0073] Among them, candidate code segment combinations can be understood as code segment combinations that can reflect the possible execution paths of the target firmware at runtime.
[0074] It should be noted that each combined sequence can contain a series of basic blocks, representing a path from the firmware execution start point to the execution end point.
[0075] In this embodiment, the current basic block is determined and its address and / or content are saved to the corresponding combination sequence. By analyzing the instruction sequence of the current basic block, the system explores forward to determine the next feasible basic block. The next basic block is then used as the new current basic block and saved to the corresponding combination sequence. Starting from the new current basic block, the system continues to explore forward to determine the next basic block. The above steps are repeated until a preset number of branch jumps (e.g., 5 times) is reached, an exception is encountered (e.g., program crash, illegal memory access, etc.), or there is no next basic block. At this point, the exploration operation stops, and candidate code segment combinations are generated based on the basic blocks in each combination sequence.
[0076] For example, the combination sequence can be [basic block 1, basic block 2, basic block 3] and [basic block 1, basic block 2, basic block 4], and the corresponding candidate code segment combinations can be represented as basic block 1 → basic block 2 → basic block 3 and basic block 1 → basic block 2 → basic block 4, respectively.
[0077] b33) Select one candidate code segment combination from all candidate code segment combinations as the target code segment combination based on priority.
[0078] In this embodiment, the candidate code segment combination with the highest priority is selected as the target code segment combination from all candidate code segment combinations according to the priority strategy (such as the number of basic blocks in the candidate code segment combination, the number of branch conditions, whether a specific destination address is included or avoided, and the number of times DMA-related logic is accessed).
[0079] The above-described technical solution in this embodiment generates candidate code segment combinations by progressively exploring the basic blocks of the program and saving each current basic block. The target code segment combination is then determined from the candidate code segment combinations based on a priority strategy. This improves the accuracy of DMA operation simulation and provides strong support for providing DMA input that meets the expectations of the target firmware. As a result, the efficiency, comprehensiveness, and accuracy of firmware testing are improved.
[0080] As one implementation method, this optional embodiment can further specify the step of selecting a candidate code segment combination as the target code segment combination from all candidate code segment combinations according to priority as follows:
[0081] b331) When there is more than one candidate code segment combination, the priority order of the candidate code segment combination is determined by the path sorting model.
[0082] In this embodiment, if the candidate code segment combinations are not unique, the priority ranking of the candidate code segment combinations is determined by a path ranking model. For example, the path ranking model can be a machine learning model, such as a large language model. Specifically, the process of determining the priority ranking can involve submitting all candidate code segment combinations to the machine learning model for analysis. The machine learning model will select several preferred paths based on given prompts. The prompts could be something like, "Please analyze the content of each of the following basic program blocks, combine different basic blocks to generate different candidate code segment combinations, and rank them according to the amount of program information contained in these candidate code segment combinations." The machine learning model will ultimately evaluate the amount of program information contained in each candidate code segment combination and rank them according to the evaluation results.
[0083] Understandably, when using pre-trained machine learning models to evaluate the potential value of candidate code segment combinations and predict which candidate code segment combinations might uncover uncovered logic or potential vulnerabilities, it is advisable to prioritize candidate code segment combinations with higher addresses, as code segment combinations with higher addresses are usually located in deeper logic within the target firmware.
[0084] b332) Determine the target code segment combination based on the priority sorting.
[0085] In this embodiment, the target code segment combination is determined based on the priority ranking result. This can be done by selecting the candidate code segment combination with the highest priority as the target code segment combination, or by determining the target code segment combination based on priority ranking according to preset rules.
[0086] The above-described technical solution in this embodiment determines the priority order of the candidate code segment combinations through a path sorting model, thereby determining the target code segment combination based on the priority order. This improves code coverage, eliminates candidate code segment combinations that may lead to a dead state, and enables the exploration of more potential execution logic, thereby improving the comprehensiveness, efficiency, and vulnerability discovery capabilities of firmware testing.
[0087] c3) Determine the target address pointer's value in the target code segment combination based on the constraints.
[0088] In this embodiment, based on the constraints in the target code segment combination, the constraint solver (such as z3) can be used to solve the constraint values of the symbols to be solved in the target code segment combination to obtain the specific values corresponding to the symbols to be solved, that is, the value pointed to by the destination address pointer in the target code segment combination (expected value).
[0089] The above-described technical solution in this embodiment derives the expected execution path of the target firmware based on the current basic block address information, context information, and target DMA transfer descriptor, i.e., determines the target code segment combination, thereby achieving effective simulation of IoT firmware; and determines the target address pointer's pointing value in the target code segment combination based on constraints, thereby providing the target with expected DMA input during fuzz testing of the target firmware, guiding the firmware-managed simulation process, and enabling the exploration of more potential firmware code logic through the given DMA input.
[0090] As a fourth optional embodiment of this embodiment, based on the above embodiments, it further includes:
[0091] a4) When the transmission task is completed or a new DMA input channel is detected, the target DMA input channel is closed and the new DMA input channel is used as the target DMA input channel.
[0092] In this embodiment, one implementation is to close the target DMA input channel and release resources when the completion of the transmission task is detected by a status flag or interrupt, and use the new DMA input channel as the target DMA input channel when constructing a new DMA input channel; another implementation is to consider the construction of a new DMA input channel when a jump in the destination address pointer is detected, at which point the target DMA input channel can be closed and the new DMA input channel can be used as the target DMA input channel so that subsequent DMA operations can be performed through the new channel.
[0093] The above-described technical solution in this embodiment ensures the flexibility and efficiency of DMA operations and improves resource utilization by closing the target DMA input channel when the transmission task is completed or a new DMA input channel is detected, and using the new DMA input channel as the target DMA input channel.
[0094] To better understand the IoT firmware testing method provided in this embodiment of the invention, a specific example is given here.
[0095] Figure 2 This is a schematic diagram of the architecture of an IoT firmware testing method provided in an embodiment of the present invention. Figure 2 As shown, the firmware image of the target firmware is sent to the QEMU instruction set emulation module. The QEMU instruction set emulation module can emulate the instruction set of peripherals such as ARM-CortexM. Before the entire emulation process begins, the address range of the MMIO region of the target firmware is obtained through static analysis tools, allowing for configuration within the QEMU instruction set emulation module. Furthermore, by modifying the memory.c file in the QEMU instruction set emulation module's source code, hook functions can be inserted into the memory access functions of the QEMU instruction set emulation module to capture specific memory operations during firmware emulation, enhancing control over the memory access process.
[0096] Throughout the simulation process, all MMIO accesses within a specified memory range can be hooked. When the target firmware accesses the MMIO memory region, the AFL fuzzing engine can be invoked to provide specific inputs (i.e., test case inputs) to maintain the continuous operation of the simulation process. When the firmware accesses DMA input-related logic, control of the simulation process can be transferred to the DMA input channel controller. The DMA input channel controller includes a DMA pointer identification unit, a DMA buffer dynamic identification unit, a DMA hook management unit, and a DMA I / O stream processing unit. It also defines a virtual DMA controller, including a DMA pointer, a DMA buffer, and a DMA transfer descriptor (i.e., a DMA I / O descriptor). The DMA controller's status is monitored in real time. Once the target firmware attempts to activate the DMA controller (i.e., attempts to access the DMA-related memory region), a DMA transfer descriptor is dynamically generated through the hook control set in memory, and a DMA input channel is dynamically created based on the source address, destination address, transfer length, and other information read by the target firmware.
[0097] The specific process involves the virtual DMA controller in the DMA input channel controller combining a source address pointer and a destination address pointer within the DMA memory region into a DMA buffer, writing the DMA buffer configuration information into the DMA transfer descriptor, and creating a new DMA input channel to simulate this DMA transfer. Then, a heuristic DMA input channel algorithm dynamically creates or closes the DMA input channel based on the currently identified pointers within the DMA memory region, while simultaneously providing the expected data input to the target address.
[0098] Each time the firmware program calls DMA input, the DMA input channel controller sets the target address accessed by the program to the symbolic value to be solved and hands it over to the dynamic symbolic execution engine for processing. Angr can be used as the dynamic symbolic execution engine. The Angr dynamic symbolic execution engine contains a path selection algorithm guided by a large model and a global symbolic variable (symbolic value) management unit, and simultaneously sends the information in the DMA transfer descriptor to the dynamic symbolic execution engine. During firmware testing, a shared memory region is maintained for the Angr dynamic symbolic execution engine and the QEMU instruction set simulation module. When path selection and input solving are required, the QEMU instruction set simulation module synchronizes the current basic block address information and context to the Angr dynamic symbolic execution engine, thereby reconstructing the target firmware image. The Angr dynamic symbolic execution engine solves for the target state's pointer value by creating symbolic values and executing the path selection algorithm. Specifically, the path selection algorithm uses the dynamic symbolic execution engine to explore a certain range of basic blocks forward from the current code block. When a branch condition is encountered, all states marked as active are recorded and saved. To prevent state explosion during symbolic execution, the exploration range is strictly limited to within 5 branch jumps. Once the range limit is reached or an exception is encountered, the algorithm will select a path (target code segment combination) from all possible branches (candidate code segment combinations) according to priority, and use the constraint solver to solve the constraints on the relevant symbol values to obtain the specific value corresponding to the symbol value (i.e. the value pointed to by the destination address pointer). Then, the value pointed to is sent as DMA input data to the AFL fuzz test engine.
[0099] For multiple possible path branches, a pre-trained machine learning model, such as a large language model, can select the optimal path. First, all candidate code segment combinations (basic code blocks) are submitted to the large language model for analysis. The model selects several preferred candidate code segment combinations based on given contextual clues. The clues are: "Analyze the content of each of the following basic program blocks, generate different candidate code segment combinations based on different basic blocks, and rank these candidate code segment combinations according to the amount of program information they contain." Finally, the large language model selects the target code segment combination from the filtered candidate code segment combinations according to priority and further solves for constraints on relevant symbol values. This process meets the requirement of improving code coverage by eliminating candidate code segment combinations that may lead to a dead end state.
[0100] Furthermore, when using a pre-trained large language model to evaluate the potential value of a path and predict which paths might uncover uncovered logic or potential vulnerabilities, the combination of candidate code segments with higher addresses is given priority, because combinations of code segments with higher addresses are usually located in the deep logic of the program.
[0101] When the AFL fuzzing engine receives DMA input data, it inputs the received DMA input data as test cases into the QEMU instruction set simulation module. After receiving the test cases input by the AFL fuzzing engine, the QEMU instruction set simulation module continues to run the target firmware. The AFL fuzzing engine monitors the running results of the target firmware through the coverage feedback module and the crash detection module, generates test results, and outputs a test result report at a predetermined time or when a trigger signal is received.
[0102] Figure 3 This is a schematic diagram of the structure of an IoT firmware testing device provided in an embodiment of the present invention. Figure 3 As shown, the device includes: a target pointer detection module 31, a descriptor and channel determination module 32, a pointer value determination module 33, a firmware execution module 34, and a test result generation module 35, wherein...
[0103] The target pointer detection module 31 is used to load the target firmware and detect the target pointer that the target firmware points to the direct memory access DMA memory region when the target firmware boot instruction is received. The target pointer includes a source address pointer and a destination address pointer.
[0104] The descriptor and channel determination module 32 is used to determine the target DMA transfer descriptor and construct the target DMA input channel based on the target pointer when the target firmware is detected to point to the target memory region.
[0105] Pointer value determination module 33 is used to obtain the pointer value of the destination address pointer based on the target DMA transfer descriptor;
[0106] Firmware execution module 34 is used to store the pointer value according to the destination address pointer through the target DMA input channel, and run the target firmware according to the pointer value;
[0107] The test result generation module 35 is used to monitor the operation process of the target firmware and generate test results based on the operation results.
[0108] This invention provides an IoT firmware testing device that, upon receiving a target firmware boot command, loads the target firmware and detects a target pointer pointing to a Direct Memory Access (DMA) memory region. The target pointer includes a source address pointer and a destination address pointer. When the target pointer is detected, a target DMA transfer descriptor is determined based on the target pointer, and a target DMA input channel is constructed. The destination address pointer's value is obtained based on the target DMA transfer descriptor. The target DMA input channel stores the value based on the destination address pointer, and the target firmware is run based on the value. The running process of the target firmware is monitored, and test results are generated based on the running results. This method, by determining the target DMA transfer descriptor and constructing the target DMA input channel upon detecting the target pointer, obtaining the destination address pointer's value from the target DMA transfer descriptor, and using the value to run the target firmware, and by generating test results based on the running results of the target firmware, solves the problem that existing firmware hosting technologies cannot simulate DMA input. It expands the types of embedded devices that can be simulated and the code coverage for firmware testing, thereby improving the security of embedded devices.
[0109] Furthermore, the device also includes a configuration module, which can be used for:
[0110] Before receiving the target firmware boot command, the attribute information of the target firmware is determined through automated static analysis, and the memory region mapped by the memory-mapped input / output (MMIO) is configured according to the attribute information. The attribute information includes: the size of random access memory required by the target firmware, the memory address mapping range, and the starting address information.
[0111] Furthermore, the device also includes a pipe assembly module, which can be used specifically for:
[0112] Before receiving the target firmware boot command, a hook function is placed in the memory region mapped by the memory-mapped input / output (MMIO) to capture and take over the target firmware's access operations to the memory region mapped by the MMIO.
[0113] Furthermore, the pointer value determination module 33 may specifically include:
[0114] The information acquisition unit is used to acquire the current basic block address information and context information;
[0115] The target code segment combination determination unit is used to determine the target code segment combination based on the current basic block address information, context information and target DMA transfer descriptor;
[0116] The constraint solving unit is used to determine the target address pointer's pointer value in the target code segment combination based on the constraint conditions.
[0117] Furthermore, the target code segment combination determination unit may specifically include:
[0118] The image reconstruction subunit is used to reconstruct the target firmware image based on the current basic block address information, context information and target DMA transfer descriptor to realize the simulated execution of the target firmware;
[0119] A candidate code segment combination generation subunit is used to explore the next basic block from the current basic block, save the current basic block to the corresponding combination sequence, and use the next basic block as the new current basic block to explore forward to determine the new next basic block, until a preset number of branch jumps is reached or an exception is encountered and returned, and at least one candidate code segment combination is generated according to the basic blocks in each combination sequence.
[0120] The target code segment combination selection subunit is used to select one candidate code segment combination from all candidate code segment combinations as the target code segment combination based on priority.
[0121] Furthermore, the target code segment combination selection subunit can be specifically used for:
[0122] When there are more than one candidate code segment combination, the priority order of the candidate code segment combination is determined by the path sorting model;
[0123] The target code segment combination is determined based on the priority sorting.
[0124] Furthermore, the device also includes a channel shut-off module, which can be used specifically for:
[0125] When the transfer task is completed or a new DMA input channel is detected, the target DMA input channel is closed, and the new DMA input channel is used as the target DMA input channel.
[0126] The IoT firmware testing device provided in this embodiment of the invention can execute the IoT firmware testing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.
[0127] Figure 4A schematic diagram of an electronic device 40 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.
[0128] like Figure 4 As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 or a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded into the RAM 43 from storage unit 48. The RAM 43 may also store various programs and data required for the operation of the electronic device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.
[0129] Multiple components in electronic device 40 are connected to I / O interface 45, including: input unit 46, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0130] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as IoT firmware testing methods.
[0131] In some embodiments, the IoT firmware testing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the IoT firmware testing method described above may be performed. Alternatively, in other embodiments, processor 41 may be configured to perform the IoT firmware testing method by any other suitable means (e.g., by means of firmware).
[0132] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0133] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0134] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0135] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0136] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0137] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0138] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0139] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A method for testing IoT firmware, characterized in that, include: Upon receiving the target firmware boot command, the target firmware is loaded and the target pointer of the target firmware pointing to the direct memory access DMA memory region is detected. The target pointer includes a source address pointer and a destination address pointer. When a target pointer pointing to a DMA memory region is detected, the target DMA transfer descriptor is determined based on the target pointer and a target DMA input channel is constructed. The destination address pointer is obtained based on the target DMA transfer descriptor; The target firmware is executed based on the target DMA input channel according to the destination address pointer and the pointer value is stored. Monitor the execution process of the target firmware and generate test results based on the execution results; The step of obtaining the destination address pointer value based on the target DMA transfer descriptor includes: Obtain the current basic block address information and context information; The target code segment combination is determined based on the current basic block address information, context information, and target DMA transfer descriptor; Based on the constraints, determine the value that the destination address pointer points to in the target code segment combination; The step of determining the target code segment combination based on the current basic block address information, context information, and target DMA transfer descriptor includes: The target firmware is reconstructed based on the current basic block address information, context information, and target DMA transfer descriptor to achieve simulated execution of the target firmware; Starting from the current basic block, explore forward to the next basic block, save the current basic block to the corresponding combination sequence, and use the next basic block as the new current basic block to explore forward to determine the new next basic block, until the preset number of branch jumps is reached or an exception is encountered and returned, and generate at least one candidate code segment combination based on the basic blocks in each combination sequence; Based on priority, select one candidate code segment combination from all candidate code segment combinations as the target code segment combination.
2. The method according to claim 1, characterized in that, Before receiving the target firmware boot command, it also includes: The attribute information of the target firmware is determined by automated static analysis, and the memory region mapped by the memory-mapped input / output (MMIO) is configured according to the attribute information. The attribute information includes: the size of random access memory required by the target firmware, the memory address mapping range, and the starting address information.
3. The method according to claim 1, characterized in that, Before receiving the target firmware boot command, it also includes: By placing hook functions in the memory region mapped by the memory-mapped input / output (MMIO), the target firmware's access operations to the memory region mapped by the MMIO can be captured and taken over.
4. The method according to claim 1, characterized in that, The step of selecting a candidate code segment combination as the target code segment combination from all candidate code segment combinations based on priority includes: When there are more than one candidate code segment combination, the priority order of the candidate code segment combination is determined by the path sorting model; The target code segment combination is determined based on the priority sorting.
5. The method according to claim 1, characterized in that, Also includes: When the transfer task is completed or a new DMA input channel is detected, the target DMA input channel is closed, and the new DMA input channel is used as the target DMA input channel.
6. An IoT firmware testing device, characterized in that, include: The target pointer detection module is used to load the target firmware and detect the target pointer that the target firmware points to the direct memory access DMA memory region when the target firmware boot instruction is received. The target pointer includes a source address pointer and a destination address pointer. The descriptor and channel determination module is used to determine the target DMA transfer descriptor and construct the target DMA input channel based on the target pointer when the target firmware is detected to point to a target memory region. The pointer value determination module is used to obtain the pointer value of the destination address pointer based on the target DMA transfer descriptor; The firmware execution module is used to store the pointer value according to the destination address pointer through the target DMA input channel, and to run the target firmware according to the pointer value; The test result generation module is used to monitor the operation process of the target firmware and generate test results based on the operation results; The pointer value determination module includes: The information acquisition unit is used to acquire the current basic block address information and context information; The target code segment combination determination unit is used to determine the target code segment combination based on the current basic block address information, context information and target DMA transfer descriptor; The constraint solving unit is used to determine the target address pointer's pointer value in the target code segment combination based on the constraint conditions. The target code segment combination determination unit includes: The image reconstruction subunit is used to reconstruct the target firmware image based on the current basic block address information, context information and target DMA transfer descriptor to realize the simulated execution of the target firmware; A candidate code segment combination generation subunit is used to explore the next basic block from the current basic block, save the current basic block to the corresponding combination sequence, and use the next basic block as the new current basic block to explore forward to determine the new next basic block, until a preset number of branch jumps is reached or an exception is encountered and returned, and at least one candidate code segment combination is generated according to the basic blocks in each combination sequence. The target code segment combination selection subunit is used to select one candidate code segment combination from all candidate code segment combinations as the target code segment combination based on priority.
7. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the IoT firmware testing method according to any one of claims 1-5.
8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the IoT firmware testing method according to any one of claims 1-5.