Internet of Things firmware test method, device and equipment and medium

Abstract

The invention discloses an Internet of Things firmware testing method, device and equipment and a medium. The method comprises the steps that when a target firmware starting instruction is received, target firmware is loaded, a target pointer, pointing to a direct memory access (DMA) memory area, of the target firmware is detected, and the target pointer comprises a source address pointer and a destination address pointer; when it is detected that the target firmware points to a target pointer of the DMA memory area, determining a target DMA transmission descriptor according to the target pointer and constructing a target DMA input channel; obtaining a pointing value of a destination address pointer according to the target DMA transmission descriptor; storing a pointing value according to the destination address pointer through the target DMA input channel, and running the target firmware according to the pointing value; and monitoring the running process of the target firmware, and generating a test result according to a running result. According to the method, the problem that DMA input cannot be simulated by an existing firmware hosting technology is solved, and the types of the simulatable embedded devices and the code coverage range of firmware testing are expanded, so that the security of the embedded devices is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer network space security, and particularly to an Internet of Things (IoT) firmware testing method, device, equipment, and medium. Background Art

[0002] With the rapid development of the Internet of Things (IoT), the number of embedded devices has increased sharply. However, due to the generally simple firmware design and resource constraints of embedded devices, the firmware is vulnerable to attacks, resulting in a large number of security vulnerabilities. In particular, a large amount of user privacy data is stored in embedded devices, and its potential security vulnerabilities may lead to serious privacy leaks.

[0003] In existing research on the security of embedded devices, dynamic firmware analysis has become the mainstream method in the academic community due to its high efficiency and low false alarm rate. To achieve dynamic analysis of firmware, it is necessary to actually execute the firmware program. However, the firmware depends on real hardware peripherals during execution, which poses challenges such as cumbersome manual analysis and poor applicability for existing firmware emulation technologies.

[0004] For this reason, the Firmware Re-hosting method has been proposed, which allows the firmware to run in a virtualized environment, thus reducing the dependence on real hardware. However, existing firmware hosting technologies cannot emulate the input of direct memory access (DMA), which greatly limits the types of emulable embedded devices and the coverage of firmware code. Summary of the Invention

[0005] The present invention provides an Internet of Things firmware testing method, device, equipment, and medium to solve the problem that existing firmware hosting technologies cannot emulate the input of direct memory access (DMA), which greatly limits the types of emulable embedded devices and the coverage of firmware code.

[0006] In a first aspect, an embodiment of the present invention provides an Internet of Things firmware testing method, which includes:

[0007] When receiving a target firmware startup instruction, loading the target firmware and detecting a target pointer of the target firmware pointing to a direct memory access (DMA) memory area, where the target pointer includes a source address pointer and a destination address pointer;

[0008] When detecting the target pointer of the target firmware pointing to the DMA memory area, determining a target DMA transfer descriptor according to the target pointer and constructing a target DMA input channel;

[0009] Obtain the pointing value of the destination address pointer according to the target DMA transfer descriptor;

[0010] Store the pointing value according to the destination address pointer through the target DMA input channel, and run the target firmware according to the pointing value;

[0011] Monitor the running process of the target firmware, and generate a test result according to the running result.

[0012] In a second aspect, an embodiment of the present invention provides an Internet of Things firmware testing device, and the device includes:

[0013] A target pointer detection module, configured to load a target firmware and detect a target pointer of the target firmware pointing to a direct memory access (DMA) memory area when receiving a target firmware start instruction, where the target pointer includes a source address pointer and a destination address pointer;

[0014] A descriptor and channel determination module, configured to determine a target DMA transfer descriptor according to the target pointer and construct a target DMA input channel when detecting the target pointer of the target firmware pointing to the DMA memory area;

[0015] A pointing value determination module, configured to obtain the pointing value of the destination address pointer according to the target DMA transfer descriptor;

[0016] A firmware running module, configured to store the pointing value according to the destination address pointer through the target DMA input channel, and run the target firmware according to the pointing value;

[0017] A test result generation module, configured to monitor the running process of the target firmware, and generate a test result according to the running result.

[0018] In a third aspect, an embodiment of the present invention provides an electronic device, and the electronic device includes:

[0019] At least one processor;

[0020] And a memory communicatively connected to the at least one processor;

[0021] Wherein, the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the Internet of Things firmware testing method according to any embodiment of the present invention.

[0022] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, and the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to execute the Internet of Things firmware testing method according to any embodiment of the present invention when executed.

[0023] In the technical solution of the embodiment of the present invention, when a target firmware start instruction is received, the target firmware is loaded and a target pointer pointing to a direct memory access (DMA) memory area in the target firmware is detected. The target pointer includes a source address pointer and a destination address pointer. When it is detected that the target pointer in the target firmware points to the DMA memory area, a target DMA transfer descriptor is determined according to the target pointer and a target DMA input channel is constructed. A pointing value of the destination address pointer is obtained according to the target DMA transfer descriptor. The pointing value is stored through the target DMA input channel according to the destination address pointer, and the target firmware is run according to the pointing value. The running process of the target firmware is monitored, and a test result is generated according to the running result. By determining the target DMA transfer descriptor and constructing the target DMA input channel when the target pointer is detected, obtaining the pointing value of the destination address pointer according to the target DMA transfer descriptor and using the pointing value to run the target firmware, and generating the test result according to the running result of the target firmware, the problem that the existing firmware hosting technology cannot simulate the input of DMA is solved, the types of embedded devices that can be simulated and the code coverage of firmware testing are expanded, thereby improving the security of the embedded device.

[0024] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present invention, nor is it used to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0026] Figure 1 It is a flowchart of an Internet of Things firmware testing method provided by an embodiment of the present invention;

[0027] Figure 2 It is a schematic architecture diagram of an Internet of Things firmware testing method provided by an embodiment of the present invention;

[0028] Figure 3 It is a schematic structural diagram of an Internet of Things firmware testing device provided by an embodiment of the present invention;

[0029] Figure 4 It shows a schematic structural diagram of an electronic device that can be used to implement the embodiments of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0030] To enable those skilled in the art to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0031] It should be noted that the terms "target", "original", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances, so that the embodiments of the present invention described here can be implemented in an order other than those illustrated or described here. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0032] It should be noted that in order to perform dynamic analysis of the firmware, it is necessary to actually execute the firmware program. In order to reduce the dependence of the firmware on real hardware, a firmware hosting method is proposed, which allows the firmware to run in a virtualized environment. However, the existing firmware hosting technology cannot simulate the input of direct memory access (DMA), which greatly limits the types of emulable embedded devices and the coverage of firmware code.

[0033] Based on this, the embodiments of the present invention provide an Internet of Things firmware testing method. Figure 1 The figure is a flowchart of an Internet of Things firmware testing method provided by the embodiments of the present invention. The embodiments of the present invention are applicable to testing firmware, especially in scenarios where direct memory access input needs to be processed during firmware testing. This method can be executed by an Internet of Things firmware testing device, which can be implemented in the form of software and / or hardware. Optionally, it can be implemented by an electronic device, and the electronic device is preferably a mobile terminal, a desktop computer, a laptop computer, a server, etc.

[0034] As Figure 1 shown, the Internet of Things firmware testing method provided by the embodiments of the present invention may specifically include:

[0035] S101. When receiving a target firmware startup instruction, load the target firmware and detect a target pointer of the target firmware pointing to a direct memory access (DMA) memory area, where the target pointer includes a source address pointer and a destination address pointer.

[0036] Among them, the target firmware can be understood as the firmware with test requirements, which can be the firmware binary file in ELF format. The target firmware startup instruction can be understood as the instruction to start running the firmware, which can be the instruction triggered by the client, or the instruction issued by timing or automatically triggering the preset conditions. The direct memory access (DMA) memory area can be understood as the area specifically set aside in the memory area mapped by memory mapped input / output (MMIO) for storing the data transmitted by DMA. The source address pointer can be understood as the pointer pointing to the source data address of the DMA transmission, and the destination address pointer can be understood as the pointer pointing to the destination data address of the DMA transmission.

[0037] In this embodiment, when the target firmware startup instruction is received, virtualization technology simulators such as QEMU and 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, by monitoring the memory access operations of the target firmware in real time, it is detected whether there is a target pointer pointing to the direct memory access (DMA) memory area during the running process of the target firmware, that is, whether the target firmware attempts to access the logic related to DMA input.

[0038] It can be understood that a hook mechanism can be inserted into the memory access function of the virtualization technology simulator so that specific memory access operations can be captured during the running process of the target firmware, enhancing the control of the memory access process. Exemplarily, if the virtualization technology simulator is QEMU, the specific implementation method can be that during the QEMU simulation run, every time memory access occurs, the unassigned_mem_write or unassigned_mem_read function will be called. These functions were originally used to process the read and write operations of unallocated memory. Conditions for accessing the DMA pointer and the MMIO memory area are added to the above functions. When the target firmware attempts to access the DMA memory area or the MMIO memory area, the access behavior can be detected, and the memory access process can be taken over through the hook mechanism. After the takeover, the control right is handed over to the corresponding module for processing.

[0039] S102. When the target pointer pointing to the DMA memory area of the target firmware is detected, determine the target DMA transfer descriptor according to the target pointer and construct the target DMA input channel.

[0040] Among them, the target DMA transfer descriptor can be understood as the DMA transfer descriptor corresponding to the target pointer, which is a data structure for describing the detailed information of the DMA transfer. It can include the source address pointer, the destination address pointer, the transfer length (that is, the size of the data to be transferred), the transfer mode (such as memory to memory, memory to peripheral, etc.), the interrupt flag (that is, whether to trigger an interrupt after the transfer is completed), and other configuration information (such as data width, transfer direction, etc.).

[0041] In this embodiment, when the target pointer pointing to the DMA memory area is detected in the target firmware, the source address pointer and the destination address pointer are combined into a DMA buffer, and the DMA buffer configuration information (such as the source address pointer, the destination address pointer, the transfer mode, etc.) is written into the target DMA transfer descriptor to avoid simulation crashes caused by lack of hardware support. And a target DMA input channel is dynamically created according to 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 should be noted that the DMA transfer is a continuous memory read and write process. However, due to the lack of physical hardware support, only the starting address of the buffer can be determined, but the specific data transfer length and the ending address of the buffer are unknown. Therefore, this process can be implemented through a heuristic DMA input channel algorithm. The specific implementation process can be to dynamically create and close the target DMA input channel according to the currently identified target pointer by using the DMA input channel algorithm, and provide the expected data input to the address pointed to by the destination address pointer.

[0043] S103. Obtain the pointing value of the destination address pointer according to the target DMA transfer descriptor.

[0044] In this embodiment, the destination address pointer accessed by the target firmware is set as a symbolic variable to be solved. According to the information in the target DMA transfer descriptor and the relevant information in the memory, dynamic symbolic execution is used to generate an execution path that meets specific constraint conditions. The path with the highest priority is selected from the execution paths through a path selection algorithm, an intelligent algorithm, a large language model, etc. The priority can be determined according to the path length, covered branch conditions, etc. Then, further constraint solving is performed on the symbolic variable to be solved in the selected path, so as to obtain the pointing value of the destination address pointer.

[0045] It should be noted that the pointing value of the destination address pointer will affect the subsequent running state and execution logic of the target firmware. Therefore, when selecting a path, it is possible to consider accessing as much DMA-related logic in the target firmware as possible in the initial stage to discover potential firmware vulnerabilities and maintain 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 pointing value according to the destination address pointer through the target DMA input channel, and run the target firmware according to the pointing value.

[0047] In this embodiment, a fuzz testing tool (such as AFL, etc.) can be used to store the pointing 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 pointing value through the target DMA input channel, and thus continue to run according to the received pointing value to complete the subsequent execution logic.

[0048] S105. Monitor the running process of the target firmware and generate a test result according to the running result.

[0049] In this embodiment, the running condition of the target firmware is monitored through a fuzz testing tool, and potential vulnerabilities and errors are found according to the running result, so as to generate a test result, covering aspects such as firmware stability, path coverage rate, vulnerability discovery, etc. The test result may include the simulation success rate of the target firmware, path coverage rate data, the number of crash triggers, etc.

[0050] It should be noted that the relevant control can be triggered by the client according to the requirement to generate a test result, or the test result can be generated regularly, such as generating a test result every 24 hours.

[0051] An Internet of Things firmware testing method provided by an embodiment of the present invention includes: when receiving a target firmware startup instruction, loading the target firmware and detecting a target pointer of the target firmware pointing to a direct memory access (DMA) memory area, where the target pointer includes a source address pointer and a destination address pointer; when detecting the target pointer of the target firmware pointing to the DMA memory area, determining a target DMA transfer descriptor according to the target pointer and constructing a target DMA input channel; obtaining the pointing value of the destination address pointer according to the target DMA transfer descriptor; storing the pointing value according to the destination address pointer through the target DMA input channel and running the target firmware according to the pointing value; monitoring the running process of the target firmware and generating a test result according to the running result. By determining the target DMA transfer descriptor and constructing the target DMA input channel when detecting the target pointer, obtaining the pointing value of the destination address pointer by the target DMA transfer descriptor and using the pointing value to run the target firmware, and generating a test result according to the running result of the target firmware, the problem that the existing firmware hosting technology cannot simulate DMA input is solved, the type of embeddable devices that can be simulated and the code coverage range of firmware testing are expanded, thereby improving the security of embeddable devices.

[0052] As a first alternative embodiment of this embodiment, before receiving the target firmware startup instruction, it further includes:

[0053] a1) Determining the attribute information of the target firmware through automated static analysis, and configuring the memory area mapped by the memory mapped input / output (MMIO) according to the attribute information, where the attribute information includes: the size of the random access memory required by the target firmware, the memory address mapping range, and the start address information.

[0054] Among them, the memory area mapped by memory-mapped input / output (MMIO) can be understood as the area that maps the registers of a peripheral device to the memory address space and is used for the control and data interaction of an embedded device.

[0055] In this embodiment, a target firmware is analyzed by a static analysis tool such as IDA Pro to obtain the attribute information of the target firmware. According to the 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. Exemplarily, the memory range mapped by the peripheral registers 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 area mapped by MMIO, and the configuration is performed in the virtualization technology simulator according to the address range of the memory area mapped by MMIO.

[0056] Through the above technical solution of this embodiment, by configuring the memory area mapped by MMIO according to the attribute information of the target firmware, it is ensured that the target firmware runs correctly in the simulation environment without actual hardware, providing strong support for testing embedded devices in a virtualization environment.

[0057] As the second alternative embodiment of this embodiment, before receiving the target firmware startup instruction, it further includes:

[0058] a2) By using a hook function placed in the memory area mapped by memory-mapped input / output (MMIO) to capture and take over the access operation of the target firmware to the memory area mapped by the MMIO.

[0059] Among them, a hook function can be understood as a special callback function used to execute custom logic when a specific event occurs.

[0060] In this embodiment, a hook function is pre-placed in the memory area mapped by MMIO to specify all MMIO accesses within the range of the memory area, so as to capture the operation of the target firmware accessing the memory area mapped by MMIO. When it is captured that the target firmware reads and writes to the memory area mapped by MMIO, that is, when attempting to call the peripheral logic, the above memory access process is taken over by the hook function, and a fuzz testing tool can be called to provide specific inputs for the target firmware to maintain the continuous operation of the entire simulation process, or the control right after takeover can be handed over to the corresponding module for processing. For example, when the target firmware accesses the logic related to DMA input, the DMA process can be simulated by dynamically generating a DMA transfer descriptor, so as to ensure that the target firmware can execute smoothly and avoid simulation crashes caused by lack of hardware support.

[0061] In the above technical solution of this embodiment, by means of a hook function placed in the memory area mapped by MMIO, the access operation of the target firmware to the memory area is captured and taken over, so that the complex behavior of the Internet of Things firmware can be simulated without actual hardware peripherals. Especially in the processing of DMA input, the accuracy and stability of the simulation are improved.

[0062] As the third alternative embodiment of this embodiment, on the basis of the above embodiment, the pointing value of the destination address pointer obtained 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] Among them, a basic block can be understood as a continuous instruction sequence in the firmware, where there are no jump instructions (except for the last instruction of the basic block), and it is used as the basic unit of the firmware execution path. The current basic block address information can be understood as the information used to determine the position of the basic block currently executed by the target firmware. The context information can be understood as the information associated with the running state of the current target firmware, which may include the current register information and memory information, etc.

[0065] In this embodiment, the current basic block address information and context information dynamically synchronized by the virtualization technology simulator are obtained.

[0066] b3) Determine the target code segment combination according to the current basic block address information, context information, and target DMA transfer descriptor.

[0067] Among them, the target code segment combination can be understood as the code path that the target firmware is to execute in the current state.

[0068] In this embodiment, according to the current basic block address information, context information, and target DMA transfer descriptor, the destination address pointer is recorded as a symbolic value to be solved through a binary analysis tool (such as Angr) based on symbolic execution and simulation execution, and then the exploration of the code segment combination is carried out. By sorting all the explored code segment combinations according to the priority, the code segment combination with the highest priority is selected as the target code segment combination.

[0069] As one implementation method, this alternative embodiment can further specify the determination of the target code segment combination according to the current basic block address information, context information, and target DMA transfer descriptor as the following content:

[0070] b31) Reconstruct the image of the target firmware according to the current basic block address information, context information, and target DMA transfer descriptor to realize the simulation execution of the target firmware.

[0071] In this embodiment, the target firmware is converted into an intermediate language (IR) according to the current basic block address information, context information, and target DMA transfer descriptor to achieve image reconstruction of the target firmware. And through static analysis, operations such as program block division (i.e., dividing each basic block) and dependency analysis can be performed on the reconstructed image to determine each basic block, the dependency relationship between basic blocks, the current basic block, and the symbolic value to be solved (i.e., the destination address pointer).

[0072] b32) Explore the next basic block forward 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 the preset number of branch jumps is reached or an exception return is encountered, at least one candidate code segment combination is generated according to the basic blocks in each combination sequence.

[0073] Among them, the candidate code segment combination can be understood as a code segment combination that can reflect the possible execution paths of the target firmware during operation.

[0074] It should be noted that each combination 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 the address and / or content of the current basic block are saved to the corresponding combination sequence. And through forward exploration by analyzing the instruction sequence of the current basic block, etc., the feasible next basic block is determined. The next basic block is used as the new current basic block and the new current basic block is saved to the corresponding combination sequence. And continue to explore forward from the new current basic block to determine the new next basic block. Repeat the above steps until the preset number of branch jumps (such as 5 times), an exception (such as program crash, illegal memory access, etc.) is encountered, or there is no next basic block, then stop the exploration operation, and generate candidate code segment combinations according to the basic blocks in each combination sequence.

[0076] Exemplarily, the combination sequences 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 respectively represented as basic block 1 → basic block 2 → basic block 3 and basic block 1 → basic block 2 → basic block 4.

[0077] b33) Select a candidate code segment combination as the target code segment combination from all candidate code segment combinations according to the priority.

[0078] In this embodiment, according to the priority policy (such as the number of basic blocks in the candidate code segment combination, the number of branch conditions, whether to include or avoid specific destination addresses, and the number of times of accessing DMA-related logic, etc.), the candidate code segment combination with the highest priority is selected from all candidate code segment combinations as the target code segment combination.

[0079] For the above technical solution of this embodiment, by gradually exploring the basic blocks of the program and saving each current basic block, candidate code segment combinations are generated. By determining the target code segment combination from the candidate code segment combinations according to the priority policy, the accuracy of simulating DMA operations is improved, which provides strong support for providing DMA inputs that meet the expectations of the target firmware subsequently, thereby improving the efficiency, comprehensiveness, and accuracy of firmware testing.

[0080] As one implementation manner, this optional embodiment may further specify the selecting of a candidate code segment combination as the target code segment combination from all candidate code segment combinations according to the priority as follows:

[0081] b331) When there are more than one candidate code segment combinations, determine the priority ranking of the candidate code segment combinations through a path ranking 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 through a path ranking model. Exemplarily, the path ranking model may be a machine learning model, such as a large language model. The specific process of determining the priority ranking may be to submit all candidate code segment combinations to the machine learning model for analysis. The machine learning model will select several preferred paths according to the given prompt words. The content of the prompt words may be "Please analyze the content of each of the following program basic blocks, generate different candidate code segment combinations by combining different basic blocks, and sort them according to the amount of program information contained in these candidate code segment combinations". The machine learning model will finally evaluate the amount of program information contained in each candidate code segment combination and perform priority ranking according to the evaluation results.

[0083] It can be understood that when using a pre-trained machine learning model to evaluate the potential value of candidate code segment combinations and predict which candidate code segment combinations may uncover uncovered logic or potential vulnerabilities, the candidate code segment combinations with higher addresses can be preferentially selected because the code segment combinations with higher addresses are usually located in the deeper logic of the target firmware.

[0084] b332) Determine the target code segment combination according to the priority ranking.

[0085] In this embodiment, determining the target code segment combination according to the result of the priority sorting may be to select the candidate code segment combination with the highest priority as the target code segment combination, or to determine the target code segment combination according to the preset rules based on the priority sorting.

[0086] In the above technical solution of this embodiment, the priority sorting of the candidate code segment combinations is determined through the path sorting model, so as to determine the target code segment combination according to the priority sorting, improve the code coverage rate, exclude the candidate code segment combinations that may cause the dead state, and be able to explore more potential execution logics, thereby improving the comprehensiveness, efficiency and vulnerability discovery ability of the firmware test.

[0087] c3) Determine the pointing value of the destination address pointer in the target code segment combination according to the constraint conditions.

[0088] In this embodiment, according to the constraint conditions in the target code segment combination, a constraint solver (such as z3) can be used to perform constraint solving on the symbol values to be solved in the target code segment combination, and obtain the specific values corresponding to the symbol values to be solved, that is, the pointing value (expected value) of the destination address pointer in the target code segment combination.

[0089] In the above technical solution of this embodiment, the expected execution path of the target firmware is deduced according to the current basic block address information, context information and the target DMA transfer descriptor, that is, the target code segment combination is determined, realizing the effective simulation of the Internet of Things firmware; determining the pointing value of the destination address pointer in the target code segment combination according to the constraint conditions realizes providing an expected DMA input for the target during the fuzz testing of the target firmware, guiding the simulation process hosted by the firmware, so that more potential firmware code logics can be explored through the given DMA input.

[0090] As the fourth optional embodiment of this embodiment, on the basis of the above embodiment, it further includes:

[0091] a4) When the transmission task is completed or a new DMA input channel is detected to be constructed, close the target DMA input channel and use the new DMA input channel as the target DMA input channel.

[0092] In this embodiment, one implementation may be that when it is detected that the transmission task is completed through a status flag or an interruption, etc., the target DMA input channel is closed, resources are released, and when a new DMA input channel is constructed, the new DMA input channel is used as the target DMA input channel; another implementation may be that when it is detected that the destination address pointer jumps, it is considered that a new DMA input channel is constructed. At this time, the target DMA input channel can be closed, and the new DMA input channel is used as the target DMA input channel, so that subsequent DMA operations can be performed through the new channel.

[0093] In the above technical solution of this embodiment, by closing the target DMA input channel and using the new DMA input channel as the target DMA input channel when the transmission task is completed or it is detected that a new DMA input channel is constructed, the flexibility and efficiency of the DMA operation are ensured, and the resource utilization rate is improved.

[0094] To better understand an Internet of Things firmware testing method provided by an embodiment of the present invention, a specific example is given here.

[0095] Figure 2 It is a schematic architecture diagram of an Internet of Things firmware testing method provided by an embodiment of the present invention. As Figure 2 shown, the firmware image of the target firmware is sent to the QEMU instruction set simulation module. The QEMU instruction set simulation module can simulate the architecture instructions of peripherals such as the ARM-CortexM, and before the start of the entire simulation process, the address range of the MMIO area of the target firmware is obtained through a static analysis tool, so as to perform configuration in the QEMU instruction set simulation module. At the same time, by modifying the memory.c file in the source code of the QEMU instruction set simulation module, a hook function is inserted into the memory access function of the QEMU instruction set simulation module, so that specific memory operations can be captured during the firmware simulation process, enhancing the control over the memory access process.

[0096] During the entire simulation process, all MMIO accesses within a specified memory range can be specified through Hooks. When the target firmware accesses the MMIO memory area, the AFL fuzzing engine can be called to provide specific inputs (i.e., test case inputs) to maintain the continuous operation of the entire simulation process. When the firmware program accesses the logic related to DMA inputs, the control of the simulation process can be handed over to the DMA input channel controller for processing. 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. At the same time, a virtual DMA controller is defined in the DMA input channel controller, including a DMA pointer, a DMA buffer, and a DMA transfer descriptor (i.e., a DMA I / O descriptor), etc. The status of the DMA controller is monitored in real-time. Once the target firmware attempts to activate the DMA controller (i.e., attempts to access the DMA-related memory area), a DMA transfer descriptor is dynamically generated through the Hook control set in the memory, and a DMA input channel is dynamically created based on information such as the source address, destination address, and transfer length read by the target firmware.

[0097] The specific process can be that the virtual DMA controller in the DMA input channel controller combines a source address pointer and a destination address pointer within the DMA memory area into a DMA buffer, writes the DMA buffer configuration information into the DMA transfer descriptor, and creates a new DMA input channel to simulate the execution of this DMA transfer. Then, based on the heuristics of the DMA input channel algorithm, the DMA input channel is dynamically created or closed according to the currently identified pointer within the DMA memory area, and the expected data input is provided to the target address.

[0098] Each time the firmware program calls the 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 large model-guided path selection algorithm and a global symbolic variable (symbolic value) management unit. At the same time, the information in the DMA transfer descriptor is sent to the dynamic symbolic execution engine. During the firmware test, a shared memory area 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 image of the target firmware. The Angr dynamic symbolic execution engine solves the pointed value of the expected state 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 encountering branch conditions, all states marked as active are recorded and saved. To prevent state explosion during symbolic execution, the exploration range is strictly limited to 5 branch jumps. Once the range limit is reached or an abnormal return is encountered, the algorithm selects a path (target code segment combination) from all possible branches (candidate code segment combinations) according to the priority and uses the constraint solver to perform constraint solving on the relevant symbolic values to obtain the specific value corresponding to the symbolic value (i.e., the pointed value of the destination address pointer), and then sends the pointed value as the DMA input data to the AFL fuzzing engine.

[0099] For multiple possible path branches, the optimal path can be selected by a pre-trained machine learning model, such as a large language model. First, all candidate code segment combinations (code basic blocks) are submitted to the large language model for analysis. The model helps select several preferred candidate code segment combinations according to the given context prompt words. The content of the prompt words is: "Please analyze the content of each of the following program basic blocks, generate different candidate code segment combinations based on different basic blocks, and sort them according to the amount of program information contained in these candidate code segment combinations." Finally, the large language model selects the target code segment combination from the filtered candidate code segment combinations according to the priority and performs further constraint solving on the relevant symbolic values. This process meets the requirement of improving code coverage and excludes those candidate code segment combinations that may lead to dead-end states.

[0100] In addition, when using a pre-trained large language model to evaluate the potential value of a path and predict which paths may uncover uncovered logic or potential vulnerabilities, candidate code segment combinations with higher addresses are preferentially selected because code segment combinations with higher addresses are usually located in the deep logic of the program.

[0101] When the AFL fuzzing engine receives DMA input data, it uses the received DMA input data as a test case and inputs it into the QEMU instruction set simulation module. After receiving the test case 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 The figure is a schematic structural diagram of an Internet of Things firmware testing device provided by an embodiment of the present invention. As Figure 3 shown, the device includes: a target pointer detection module 31, a descriptor and channel determination module 32, a pointing value determination module 33, a firmware running module 34, and a test result generation module 35, where

[0103] The target pointer detection module 31 is configured to load the target firmware and detect a target pointer of the target firmware pointing to a direct memory access (DMA) memory area when receiving a target firmware startup instruction, where the target pointer includes a source address pointer and a destination address pointer;

[0104] The descriptor and channel determination module 32 is configured to determine a target DMA transfer descriptor and construct a target DMA input channel according to the target pointer when detecting the target pointer of the target firmware pointing to the DMA memory area;

[0105] The pointing value determination module 33 is configured to obtain the pointing value of the destination address pointer according to the target DMA transfer descriptor;

[0106] The firmware running module 34 is configured to store the pointing value according to the destination address pointer through the target DMA input channel and run the target firmware according to the pointing value;

[0107] The test result generation module 35 is configured to monitor the running process of the target firmware and generate a test result according to the running result.

[0108] An Internet of Things firmware testing device provided by an embodiment of the present invention, when receiving a target firmware startup instruction, loads the target firmware and detects a target pointer of the target firmware pointing to a direct memory access (DMA) memory area, where the target pointer includes a source address pointer and a destination address pointer; when detecting the target pointer of the target firmware pointing to the DMA memory area, determines a target DMA transfer descriptor according to the target pointer and constructs a target DMA input channel; obtains the pointing value of the destination address pointer according to the target DMA transfer descriptor; stores the pointing value according to the destination address pointer through the target DMA input channel, and runs the target firmware according to the pointing value; monitors the running process of the target firmware, and generates a test result according to the running result. This method determines the target DMA transfer descriptor and constructs the target DMA input channel when detecting the target pointer, the target DMA transfer descriptor obtains the pointing value of the destination address pointer and uses the pointing value to run the target firmware, and generates a test result according to the running result of the target firmware, solving the problem that the existing firmware hosting technology cannot simulate DMA input, expanding the types of embeddable devices that can be simulated and the code coverage of firmware testing, thereby improving the security of embeddable devices.

[0109] Further, the device further includes a configuration module, which can specifically be used for:

[0110] Before receiving the target firmware startup instruction, determines the attribute information of the target firmware through automated static analysis, and configures the memory area mapped by the memory mapped input / output (MMIO) according to the attribute information, where the attribute information includes: the size of the random access memory required by the target firmware, the memory address mapping range, and the start address information.

[0111] Further, the device further includes a takeover module, which can specifically be used for:

[0112] Before receiving the target firmware startup instruction, captures and takes over the access operation of the target firmware to the memory area mapped by the MMIO through a hook function placed in the memory area mapped by the memory mapped input / output (MMIO).

[0113] Further, the pointing value determination module 33 can specifically include:

[0114] An information acquisition unit, used to acquire the current basic block address information and context information;

[0115] A target code segment combination determination unit, used to determine a target code segment combination according to the current basic block address information, context information, and target DMA transfer descriptor;

[0116] A constraint solving unit, used to determine the pointing value of the destination address pointer in the target code segment combination according to the constraint conditions.

[0117] Furthermore, the target code segment combination determination unit may specifically include:

[0118] An image reconstruction subunit, configured to perform image reconstruction on the target firmware according to the current basic block address information, context information, and target DMA transfer descriptor to implement simulated execution of the target firmware;

[0119] A candidate code segment combination generation subunit, configured to explore the next basic block forward starting 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. When the preset branch jump count is reached or an exception return is encountered, at least one candidate code segment combination is generated according to the basic blocks in each combination sequence;

[0120] A target code segment combination selection subunit, configured to select a candidate code segment combination from all candidate code segment combinations as the target code segment combination according to the priority.

[0121] Furthermore, the target code segment combination selection subunit may specifically be used for:

[0122] When there are more than one candidate code segment combination, determining the priority sorting of the candidate code segment combinations through a path sorting model;

[0123] Determining the target code segment combination according to the priority sorting.

[0124] Furthermore, the device further includes a channel closing module, which may specifically be used for:

[0125] When the transmission task is completed or a new DMA input channel is detected to be constructed, closing the target DMA input channel and using the new DMA input channel as the target DMA input channel.

[0126] The Internet of Things firmware testing device provided by the embodiments of the present invention can execute the Internet of Things firmware testing method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects for executing the method.

[0127] Figure 4FIG. 0 shows a schematic structural diagram of an electronic device 40 that can be used to implement embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as, for example, 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, for example, personal digital processors, cellular phones, smart phones, wearable devices (such as 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 present invention described and / or claimed herein.

[0128] As Figure 4 shown, the electronic device 40 includes at least one processor 41, and a memory communicatively connected to the at least one processor 41, such as a read-only memory (ROM) 42, a random access memory (RAM) 43, etc. The memory stores a computer program executable by the at least one processor. The processor 41 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 42 or the computer program loaded from the storage unit 48 into the random access memory (RAM) 43. In the RAM 43, various programs and data required for the operation of the electronic device 40 can also be stored. The processor 41, the ROM 42, and the RAM 43 are connected to each other via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0129] A plurality of components in the electronic device 40 are connected to the I / O interface 45, including: an input unit 46, such as a keyboard, a mouse, etc.; an output unit 47, such as various types of displays, speakers, etc.; a storage unit 48, such as a magnetic disk, an optical disk, etc.; and a communication unit 49, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 49 allows the electronic device 40 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0130] The processor 41 can be various general-purpose and / or special-purpose processing components having processing and computing capabilities. Some examples of the processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The processor 41 executes the various methods and processes described above, such as the Internet of Things firmware testing method.

[0131] In some embodiments, an Internet of Things firmware testing method, for example, can be implemented as a computer program tangibly embodied in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 40 via the ROM 42 and / or the communication unit 49. When the computer program is loaded into the RAM 43 and executed by the processor 41, one or more steps of the Internet of Things firmware testing method described above can be performed. Alternatively, in other embodiments, the processor 41 can be configured to execute the Internet of Things firmware testing method by any other suitable means (e.g., by means of firmware).

[0132] Various embodiments of the systems and techniques described above in this document can be implemented in digital electronic circuitry, integrated circuit systems, field programmable gate arrays (FPGA), application specific integrated circuits (ASIC), application specific standard products (ASSP), systems on a chip (SOC), complex programmable logic devices (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include: being implemented in one or more computer programs executable and / or interpretable on a programmable system including at least one programmable processor, which can be a special-purpose or general-purpose programmable processor that receives data and instructions from a storage system, at least one input device, and at least one output device, and transmits the data and instructions to the storage system, the at least one input device, and the at least one output device.

[0133] The computer programs for implementing the methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that the computer programs, when executed by the processor, cause the functions / operations specified in the flowchart and / or block diagram to be implemented. The computer programs can be executed entirely on the machine, partially on the machine, as a stand-alone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0134] In the context of the present invention, a computer-readable storage medium can be a tangible medium that can contain or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. The computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, the computer-readable storage medium can be a machine-readable signal medium. More specific examples of the machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0135] To provide for 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 a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can also be used to provide for interaction with the user; for example, the 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 acoustic input, voice input, or tactile input).

[0136] The systems and techniques described herein can be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer having a graphical user interface or a web browser through which the user can interact with an implementation of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0137] A computing system may include a client and a server. The client and the server are generally far from each other and usually interact via a communication network. The client-server relationship is created by computer programs running on 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 a cloud host, which is a host product in the cloud computing service system, and solves the defects of difficult management and weak business scalability existing in traditional physical hosts and VPS services.

[0138] It should be understood that various forms of the processes shown above can be used, steps can be reordered, added or deleted. For example, the steps described in the present invention can be executed in parallel, sequentially or in a different order, as long as the desired results of the technical solution of the present invention can be achieved, and no limitation is made herein.

[0139] The above specific embodiments do not constitute a limitation on the protection scope of the present 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 principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for testing IoT firmware, characterized in that: include: When receiving a target firmware startup instruction, loading the target firmware and detecting a target pointer of the target firmware pointing to a direct memory access (DMA) memory area, the target pointer including a source address pointer and a destination address pointer; When it is detected that the target firmware points to a target pointer of a DMA memory area, a target DMA transfer descriptor is determined according to the target pointer and a target DMA input channel is constructed; Obtaining a value pointed to by a destination address pointer according to the target DMA transfer descriptor; storing the pointing value according to the destination address pointer through the target DMA input channel, and running the target firmware according to the pointing value; The running process of the target firmware is monitored, and a test result is generated according to the running result.

2. The method according to claim 1, characterized in that Before receiving the target firmware startup instruction, it also includes: The attribute information of the target firmware is determined by automated static analysis, and the memory area mapped by the memory mapping input and output MMIO is configured according to the attribute information, wherein the attribute information includes: the random access memory size 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 startup instruction, it also includes: By placing a hook function in the memory area mapped by the memory mapped input and output MMIO, the access operation of the target firmware to the memory area mapped by the MMIO is captured and taken over.

4. The method according to claim 1, characterized in that The step of obtaining the pointing value of the destination address pointer according to the target DMA transfer descriptor comprises: Get the current basic block address information and context information; Determine a target code segment combination according to the current basic block address information, context information and target DMA transfer descriptor; According to the constraint condition, the pointing value of the destination address pointer in the target code segment combination is determined.

5. The method according to claim 4, characterized in that Determining the target code segment combination according to the current basic block address information, the context information and the target DMA transfer descriptor includes: Rebuilding the target firmware image according to the current basic block address information, the context information and the target DMA transfer descriptor to implement simulated execution of the target firmware; Starting from the current basic block, exploring the next basic block forward, saving the current basic block to the corresponding combination sequence, and exploring the next basic block forward as the new current basic block to determine a new next basic block, until a preset branch jump number is reached or an exception return is encountered, generating at least one candidate code segment combination according to the basic blocks in each of the combination sequences; A candidate code segment combination is selected from all candidate code segment combinations according to the priority as the target code segment combination.

6. The method according to claim 5, characterized in that The step of selecting a candidate code segment combination from all candidate code segment combinations as a target code segment combination according to the priority level includes: When there are more than one candidate code segment combination, the priority ranking of the candidate code segment combination is determined by a path ranking model; A target code segment combination is determined according to the priority ranking.

7. The method according to claim 1, characterized in that Also includes: When the transmission task is completed or it is detected that a new DMA input channel is constructed, the target DMA input channel is closed, and the new DMA input channel is used as the target DMA input channel.

8. An IoT firmware testing device, characterized in that: include: A target pointer detection module is used to load the target firmware and detect the target pointer of the target firmware pointing to the direct memory access DMA memory area when receiving the target firmware startup instruction, wherein the target pointer includes a source address pointer and a destination address pointer; A descriptor and channel determination module, for determining a target DMA transfer descriptor and constructing a target DMA input channel according to the target pointer when detecting that the target firmware points to a target pointer of a DMA memory area; A pointing value determination module, used for obtaining a pointing value of a destination address pointer according to the target DMA transfer descriptor; A firmware running module, used for storing the pointing value according to the destination address pointer through the target DMA input channel, and running the target firmware according to the pointing value; The test result generating module is used to monitor the operation process of the target firmware and generate the test result according to the operation result.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively coupled to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the Internet of Things firmware testing method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the Internet of Things firmware testing method according to any one of claims 1 to 7 when executed.

Images