Automatic simulation method and device for Internet of Things equipment firmware
By updating the knowledge base for symbolic execution and analytical modeling, the problem of insufficient model fidelity and richness in IoT device firmware simulation methods is solved, thereby improving simulation accuracy and vulnerability detection efficiency, and reducing false positives and false negatives.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-23
- Publication Date
- 2026-03-10
AI Technical Summary
Existing firmware simulation methods for IoT devices cannot simultaneously ensure both model fidelity and richness, resulting in high false positive and false negative rates for vulnerability detection.
By executing the target firmware in a simulation environment through symbolic execution, an analysis and modeling knowledge base is generated. Based on the control flow information of the symbol and the data characteristics between the symbol lifecycle, the data register is identified, the path is selected for execution, and the modeling knowledge base is updated when an unknown peripheral is encountered, thereby improving the modeling fidelity and richness.
This improves the accuracy and efficiency of firmware emulation, reduces false positives and false negatives in vulnerability detection, and achieves more efficient vulnerability detection.
Smart Images
Figure CN121637515A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application belongs to the technical field of computers, and more particularly, relates to a method and device for automatically simulating firmware of an Internet of Things (IoT) device. BACKGROUND
[0002] Due to the diversity and particularity of the hardware architecture and operating system of IoT devices, traditional software vulnerability detection techniques are difficult to apply directly. First, IoT devices widely use diversified microcontroller units (MCUs), such as the ARM Cortex-M series, each of which has different peripheral interfaces and memory mapping methods, which greatly increases the difficulty of simulating device behavior (for example, the register configurations and operation methods of GPIO, I2C, SPI, and other peripheral interfaces on different MCUs are different). Second, IoT firmware needs to frequently interact with various peripherals such as sensors and communication modules. These interactions involve complex read-write operations and interrupt handling, and are highly dependent on hardware states, making it difficult to implement pure software simulation. Third, IoT devices are usually limited in computing power and storage space, which also limits the direct operation of complex vulnerability detection tools on the devices.
[0003] To overcome the above difficulties, researchers have proposed a firmware hosting (Firmware Hosting, i.e., firmware simulation) scheme: extracting firmware from the target hardware and executing it in a virtual environment. Firmware simulation makes it possible to test and analyze without hardware, significantly reducing the dependence of security detection on physical devices, and can be combined with symbolic execution, taint analysis, and other techniques for comprehensive evaluation.
[0004] The key to firmware simulation is how to accurately model and simulate the interaction between firmware and peripherals, including peripheral register read-write, interrupt handling, and other behaviors. Firmware simulation schemes based on peripheral feedback simulation models have become a research hotspot in recent years. Current schemes that create models based on pattern matching quickly verify the effectiveness of simulation models in breaking away from hardware dependence, but because the models are based on human assumptions, the simulation of complex peripherals is prone to errors or false positives and false negatives, resulting in low fidelity. Some methods combine symbolic execution techniques to explore paths and use symbolic constraint information to enrich the model, but these works strictly execute partial effective paths and obtain high-fidelity models for individual paths, ignoring the richness of the model, resulting in low richness.
[0005] Therefore, existing firmware simulation methods cannot simultaneously consider the fidelity and richness of the model, leading to many false positives and false negatives in vulnerability detection. SUMMARY
[0006] In view of the defects of the prior art, the purpose of the present application is to provide an Internet of Things device firmware automatic simulation method and device, aiming to solve the problem that the existing firmware simulation method cannot simultaneously consider the fidelity and richness of the model, thereby causing a high false positive rate and false negative rate of vulnerability detection.
[0007] To achieve the above-mentioned purpose, in a first aspect, the present application provides an Internet of Things device firmware automatic simulation method, comprising: The target firmware is executed in a simulation environment through symbolic execution, an analysis modeling knowledge base is generated, in the execution process, data registers are identified based on the data characteristics between the control flow information of symbols and the life cycle of symbols, and the execution is performed based on the life cycle of the symbols; The following process is repeated until a preset ending condition is reached to complete the execution: The read value of the simulation peripheral device is assigned based on the analysis modeling knowledge base; In the assignment process, if an unknown peripheral device that is not modeled is encountered, the execution path is reproduced to the unknown peripheral device access point based on the current analysis modeling knowledge base and the input file triggering the unknown peripheral device, and symbolic execution is started for exploration to update the analysis modeling knowledge base.
[0008] The present application executes the target firmware in a simulation environment through symbolic execution, identifies data registers based on the data characteristics between the control flow information of symbols and the life cycle of symbols in the simulation process, can accurately and efficiently use fuzzy test data during testing, improves the modeling fidelity and richness, and performs execution based on the life cycle of the symbols. This mechanism can generate temporary rules of multiple effective paths under the influence of specific peripherals, efficiently promote multi-path exploration. When the simulation execution guides multiple paths to enter the main task loop of the firmware, the corresponding knowledge of all effective paths can be collected for use in the vulnerability detection stage. Through continuous execution of the simulation test assignment process and updating of the analysis modeling knowledge base process, the analysis modeling knowledge base can be continuously iterated and improved for the continuous execution of the fuzzy test. Overall, the accuracy and efficiency of firmware simulation are improved, and the false positives and false negatives of vulnerability detection based on the firmware simulation environment are reduced.
[0009] According to the Internet of Things device firmware automatic simulation method provided by the present application, the data characteristics of the data registers are identified based on the control flow information of the symbols and the life cycle of the symbols, comprising: When the firmware execution enters a certain interrupt service program, if the symbol is created in response to a peripheral read operation, and the corresponding peripheral register of the symbol appears in the condition register of the branch judgment outside the interrupt program, the peripheral register of the symbol is determined as a data register; In the interrupt service program, if the symbol created for the peripheral read operation is written into a global variable address or a certain address of a block started by symbol (BSS) segment, the peripheral register corresponding to the symbol is determined as a data register; In the multi-path exploration condition, if the symbol in the condition register of the branch judgment is solved as a plurality of different specific values at a plurality of different branch path points, the peripheral register corresponding to the symbol is determined as a data register.
[0010] According to the method for automatically simulating the firmware of the Internet of Things device provided in the application, the execution path is selected based on the life cycle of the symbol, and the method comprises the following steps: In the life cycle of a certain symbol, if a plurality of execution branches are derived based on the symbol, the life cycle end information is synchronized to all other execution branches determined by the symbol at the end of the life cycle of the symbol; The execution path is selected based on the life cycle end information.
[0011] According to the method for automatically simulating the firmware of the Internet of Things device provided in the application, the read value of the simulation peripheral is assigned based on the analysis modeling knowledge base, and the method comprises the following steps: When the accessed peripheral is a data register that has been identified, a test input value is provided for the data register by using an external security test tool; When the peripheral has a plurality of paths, the path selection and the assignment to the peripheral are performed according to the data flow information in the analysis modeling knowledge base.
[0012] According to the method for automatically simulating the firmware of the Internet of Things device provided in the application, the method further comprises the following steps: In the process of assigning the read value of the simulation peripheral based on the analysis modeling knowledge base, the data flow information in the analysis modeling knowledge base is used to trigger the interrupt on demand.
[0013] The application can efficiently guide the program to trigger the interrupt on demand, accurately select the execution path for the vulnerability detection, and reduce the false positives and false negatives of the vulnerability detection based on the firmware simulation environment, by means of efficient initial modeling and additional data flow information.
[0014] In the second aspect, the application provides a device for automatically simulating the firmware of the Internet of Things, which comprises: The execution module is configured to execute the target firmware in the simulation environment through the symbol execution, generate the analysis modeling knowledge base, identify the data register based on the control flow information of the symbol and the data characteristics between the life cycles of the symbols during the execution, and select the execution path based on the life cycle of the symbol; The updating module is configured to repeatedly execute the following process until the preset end condition is reached, so as to complete the execution: The readings of the simulation peripherals are assigned based on the analytical modeling knowledge base; During the assignment process, if an unknown peripheral that has not been modeled is encountered, the execution path is reproduced to the access point of the unknown peripheral based on the current analysis and modeling knowledge base and the input file that triggers the unknown peripheral, and symbolic execution is started to explore in order to update the analysis and modeling knowledge base.
[0015] Thirdly, this application provides an electronic device, comprising: at least one memory for storing a program; and at least one processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to execute the IoT device firmware automated simulation method described in the first aspect or any possible implementation thereof.
[0016] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the IoT device firmware automated simulation method described in the first aspect or any possible implementation of the first aspect.
[0017] Fifthly, this application provides a computer program product that, when run on a processor, causes the processor to execute the IoT device firmware automated simulation method described in the first aspect or any possible implementation of the first aspect.
[0018] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.
[0019] Overall, the technical solutions conceived in this application have the following beneficial effects compared with the prior art: This application executes the target firmware in a simulation environment through symbolic execution. During simulation, data registers are identified based on the control flow information and data characteristics between symbol lifecycles. This allows for accurate and efficient use of fuzz test data during testing, improving modeling fidelity and richness. The mechanism selects execution paths based on symbol lifecycles, generating temporary rules for multiple valid paths under the influence of specific peripherals, efficiently advancing multi-path exploration. When simulation execution guides multiple paths into the firmware's main task loop, knowledge corresponding to all valid paths is collected for use in the vulnerability detection phase. By continuously executing the simulation test assignment process and updating the analysis and modeling knowledge base, the knowledge base can be iteratively improved for continued fuzz testing. Overall, this improves the accuracy and efficiency of firmware simulation while reducing false positives and false negatives in vulnerability detection based on the firmware simulation environment. Attached Figure Description
[0020] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 This is one of the flowcharts illustrating the automated firmware simulation method for IoT devices provided in this application embodiment; Figure 2 This is the second flowchart illustrating the automated firmware simulation method for IoT devices provided in this application embodiment; Figure 3 This is a system architecture diagram provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the automated firmware simulation device for IoT devices provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0023] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.
[0024] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0025] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.
[0026] First, let's introduce the following content: Firmware is specific software embedded in hardware devices (such as microcontrollers (MCUs) and system-on-a-chip (SoCs)) to control hardware behavior. Its typical execution architecture consists of an initialization phase and a main task loop. After initialization, the firmware enters a continuous running state, processing input signals through polling or interrupt-driven mechanisms and interacting with external peripherals (such as sensors, actuators, and communication modules).
[0027] An interrupt is a hardware- or software-triggered control flow transfer mechanism that allows the CPU to suspend the execution of the current main program and handle urgent or asynchronous events. When an interrupt signal is triggered, the processor saves the current context and jumps to a predefined interrupt service routine. After processing, it restores the context and returns to the main program breakpoint to continue execution. In embedded systems, interrupts are an important means for firmware to obtain real-time data from peripherals. Peripherals use interrupts to notify the CPU that data is ready, thereby achieving efficient I / O communication.
[0028] Firmware security auditing in environments lacking physical hardware (microcomputers and peripherals) typically requires the use of full-system emulation techniques (such as QEMU). The core challenge lies in the fact that firmware execution frequently involves reading and writing specific memory-mapped addresses (MMIO). If the emulator cannot provide logically correct response data, the firmware often enters an infinite loop or crashes.
[0029] Symbolic execution is a static / dynamic program analysis technique used to automatically explore program execution paths. Unlike traditional concrete execution which uses fixed values, symbolic execution defines peripheral inputs as symbolic variables. When the execution flow reaches a conditional branch statement (such as `if (x>1)`), the symbolic execution engine checks whether this symbolic variable is constrained. If both outcomes are feasible, the engine forks two execution paths and maintains corresponding path constraints for each. By solving the path constraints (typically using an SMT solver such as Z3), symbolic execution can generate specific input values that trigger a particular path. Theoretically, this technique can traverse all reachable branches in the firmware, thereby systematically uncovering deep logic vulnerabilities.
[0030] Furthermore, to perform vulnerability detection, specific data must be input into the firmware using technical means (such as fuzzing). This data must satisfy logical constraints to ensure the program continues to execute (Path Constraint), and also attempt to trigger abnormal paths to detect potential security vulnerabilities such as buffer overflows and logical errors.
[0031] Next, combined Figures 1-3 The automated simulation method for IoT device firmware provided in the embodiments of this application is introduced.
[0032] Figure 1This is one of the flowcharts illustrating the automated firmware simulation method for IoT devices provided in this application embodiment, such as... Figure 1 As shown, the method includes the following steps: Step S1: Execute the target firmware in the simulation environment through symbolic execution to generate an analysis and modeling knowledge base. During the execution process, identify the data register based on the control flow information of the symbol and the data characteristics between the symbol lifecycle, and select the execution path based on the symbol lifecycle. Step S2: Repeat the following process until the preset termination condition is met to complete the execution: The readings of the simulation peripherals are assigned based on the analytical modeling knowledge base; During the assignment process, if an unknown peripheral that has not been modeled is encountered, the execution path is reproduced to the access point of the unknown peripheral based on the current analysis and modeling knowledge base and the input file that triggers the unknown peripheral, and symbolic execution is started to explore in order to update the analysis and modeling knowledge base.
[0033] This application accumulates knowledge from constraint solving during firmware execution exploration, and builds and continuously improves an analysis and modeling knowledge base to support efficient execution in the vulnerability detection phase. The analysis and modeling knowledge base contains all the information accumulated from simulation and can be referred to as a model.
[0034] Optionally, the preset termination condition can be the achievement of a preset execution time. In one embodiment of this application, the process is repeated 5 times, with each repetition lasting 24 hours.
[0035] Optionally, this application proposes a rule knowledge base design and utilization based on multiple valid paths, including the design of single-path information and the storage of multi-path information.
[0036] The design of single-path information includes: symbolic execution allows the solver to obtain a set of symbolic assignments to guide the program to a specific reachable point; when there are path branches or in a specific context, peripheral feedback values may require specific solution values to ensure path reachability. Rules are recorded as needed.
[0037] When a symbol needs to retrieve a specific value at a particular Program Counter (PC) location, the rule is saved in the format "peripheral address_feedback read PC_solved value". When a symbol needs to retrieve a specific value in a specific context (such as a function call stack or a specific state), the rule is upgraded to the format "peripheral address_feedback read PC_context hash value_solved value". Upgrades are primarily performed at program branch points to ensure the specificity and accuracy of the rules.
[0038] The storage of multi-path information includes: when a symbol can lead to multiple valid paths at a branch, not only are multiple solution values leading to different paths retained, but also data access information (such as global variable access) and interruption information that may be affected by the corresponding solution value are recorded simultaneously.
[0039] Optionally, the analytical modeling knowledge base can be used to guide fuzzing to be performed on known valid paths. When encountering some peripherals that need to be given values, specific values will be given instead of symbols. The resulting model is richer than the previous work on a single valid path. In the subsequent fuzzing process, values can be given more accurately to explore each valid path.
[0040] The automated firmware simulation method for IoT devices provided in this application executes the target firmware in a simulation environment through symbolic execution. During the simulation process, based on the control flow information of the symbols and the data feature identification registers between the symbol lifecycles, fuzzy testing data can be accurately and efficiently used during testing, improving modeling fidelity and richness. The method selects execution paths based on the symbol lifecycle, and this mechanism can generate temporary rules for multiple effective paths under the influence of specific peripherals, efficiently advancing multi-path exploration. When the simulation execution guides multiple paths into the firmware's main task loop, knowledge corresponding to all effective paths can be collected for use in the vulnerability detection phase. By continuously executing the simulation test assignment process and updating the analysis and modeling knowledge base, the analysis and modeling knowledge base can be continuously iterated and improved for continued fuzzy testing. Overall, this improves the accuracy and efficiency of firmware simulation while reducing false positives and false negatives in vulnerability detection based on the firmware simulation environment.
[0041] In some embodiments, the symbol-based control flow information and symbol lifetime data feature identification data register in step S1 includes: When the firmware executes and enters a certain interrupt service routine, if a symbol created in response to a peripheral read operation subsequently appears in the condition register of the branch judgment outside of the interrupt routine, the peripheral register that generated the symbol will be determined as a data register. In an interrupt service routine, if a symbol created for a peripheral read operation is written to a global variable address or a specific address in the BSS segment, the peripheral register corresponding to the symbol will be identified as a data register. Under multi-path exploration conditions, if the symbol in the condition register of the branch judgment is solved into multiple different specific values at multiple different branch path points, then the peripheral register corresponding to the symbol is determined to be a data register.
[0042] Identifying peripheral data registers is crucial for vulnerability detection using simulation models. Data registers typically serve as key data input nodes for fuzzing. Accurately identifying data registers during simulation allows for the accurate and efficient use of fuzzing data during testing, thereby improving vulnerability detection efficiency. This application proposes the following identification criteria: 1a. Interrupt-Branch Condition Association: When the firmware executes and enters an interrupt service routine (ISR), if a symbolic value is created in response to a peripheral read operation, and subsequently appears in the condition register for branch judgment outside of the interrupt routine, then the peripheral register that generated the symbol is likely to be a data register.
[0043] 2a, Interrupt-Global / BSS Segment Association: In an interrupt service routine, if a symbol created for a peripheral read operation is written to a global variable address or a specific address in the BSS segment, the corresponding peripheral register may be a data register.
[0044] 3a. Multi-path-multi-value solving association: Under multi-path exploration conditions, if the symbol in the condition register of the branch judgment is solved into multiple different specific values at multiple different branch path points, the corresponding peripheral register may be a data register.
[0045] Accurate identification of data registers is part of improving model accuracy. Exploring in a multi-path environment can discover as many data registers as possible compared to single-path exploration, which is part of improving model richness. Discovering data registers as early as possible eliminates the need for further re-identification during fuzzing. Each data register is a data consumption point in fuzzing, and the more consumption points there are, the higher the efficiency of fuzzing.
[0046] In some embodiments, the symbol-based lifecycle selection path in step S1 is performed, including: If multiple execution branches are derived from a symbol during its lifetime, the lifetime end information is synchronized with all other execution branches determined by that symbol when the lifetime of that symbol ends. The execution path is selected based on the lifecycle end information.
[0047] Based on the proposition that reachable paths are not unique, this application aims to efficiently explore multiple reachable paths and generate a knowledge base for the corresponding paths, thereby simultaneously improving the fidelity and richness of the peripheral feedback simulation model. This application utilizes symbolic execution technology to obtain control flow information, but abandons the traditional approach of guiding exploration with invalid paths. Instead, it proposes a multi-path scheduling strategy based on breadth-first search (BFS) and combined with "symbol lifetime".
[0048] Specifically, the lifetime of a symbol is defined as follows: when a symbol is created due to peripheral feedback (read operation), its lifetime begins, and when all registers no longer store the symbol or its derived expressions during execution, it is considered to have ended. If the symbol is stored at a global variable address or a specific memory address, it can also be considered to have ended (the peripheral corresponding to the symbol will be handled separately).
[0049] If multiple execution branches are derived from a symbol within its lifetime, the scheduler will synchronize the "lifecycle ended" information to all other branches determined by that symbol when the lifetime of that symbol ends. This mechanism can generate temporary rules for multiple valid paths under the influence of specific peripherals, efficiently promoting multi-path exploration. When the simulation execution guides multiple paths to enter the firmware's main task loop, the system can collect the knowledge corresponding to all valid paths for use in the vulnerability detection phase.
[0050] For example, if a path has never accessed a data register, fuzzing along that path would be meaningless, so such paths would be filtered out to improve overall exploration efficiency.
[0051] Optionally, the collection of information on data flow and data features can also be based on the lifecycle units of symbols, which can improve modeling efficiency and richness.
[0052] In some embodiments, assigning values to the simulation peripherals based on the analysis and modeling knowledge base in step S2 includes: When accessing an external device's authenticated data register, use an external security testing tool to provide test input values for the data register. When there are multiple peripherals, the path selection and peripheral assignment are performed based on the data flow information in the analysis and modeling knowledge base.
[0053] Alternatively, external security testing tools may include fuzz testers, etc.
[0054] Figure 2 This is a second flowchart illustrating the automated firmware simulation method for IoT devices provided in this application embodiment, as shown below. Figure 2As shown, in one embodiment of this application, the method usage process is divided into three stages: 1b, Initial Modeling Phase: Dynamic analysis of the firmware is performed using selective symbolic execution (SMA). When the firmware performs peripheral register read operations, the read values are symbolized to advance the simulation. This process coordinates with various functional modules to perform initial modeling, generating a preliminary analysis and modeling knowledge base.
[0055] 2b. Simulation Testing Phase: Peripheral read values are directly assigned according to the analysis and modeling knowledge base. When accessing an identifiable data register, a fuzzer provides test input values. When multiple peripherals exist, precise path selection and assignment are performed based on context (e.g., whether the address of the last accessed global variable matches a certain rule's data flow information). If an unknown peripheral not yet modeled is encountered, an enhanced modeling request is triggered.
[0056] 3b, Enhanced Modeling Phase: Based on the current analysis and modeling knowledge base and the fuzzy test input file that triggers the unknown peripheral, reproduce the execution path to the access point of the unknown peripheral, and restart symbolic execution for exploration, thereby iteratively improving the analysis and modeling knowledge base.
[0057] In some embodiments, the method further includes: During the process of assigning values to the simulation peripherals based on the analysis and modeling knowledge base, the data flow information based on the analysis and modeling knowledge base triggers interrupts as needed.
[0058] By leveraging the additional data flow information in the analytical modeling knowledge base, interrupts can be triggered on demand, rather than through passive polling. For example, when the main program accesses a global variable, and the data flow information of a rule in the knowledge base (which applies to a certain interrupt) matches the address of the currently accessed global variable, the system can proactively trigger the relevant interrupt to simulate more realistic pre-interrupt verification behavior.
[0059] In interrupt routines, when specific peripheral feedback values are required to guide the path, a more accurate path selection can be made based on the data access information of the corresponding path.
[0060] like Figure 2 As shown, interrupt triggering is also triggered on demand based on the data flow information in the analysis and modeling knowledge base. For example, if the main program accesses a specific global variable and that variable is associated with an interrupt rule, the interrupt will be triggered actively.
[0061] Figure 3 This is a system architecture diagram provided in the embodiments of this application, such as... Figure 3 As shown, in one embodiment of this application, the system framework of this application is as follows: Figure 1As shown, the system mainly comprises a simulation modeling module and a simulation testing module. The simulation modeling module is implemented based on a symbolic execution engine. After firmware startup, by symbolizing peripheral read values, it drives the firmware to execute in an environment without real peripherals. This module works collaboratively with a multi-path exploration scheduler (combined with symbolic lifecycle), a data register discriminator, a multi-path rule learner, an interrupt module, and a loop detection module to complete automated modeling and generate a modeling knowledge base. The simulation testing module is implemented based on a general-purpose binary dynamic decoding tool and is responsible for firmware security testing. This module utilizes the knowledge base generated by the modeling module to achieve more efficient interrupt triggering and more accurate, context-matched test path selection, thereby guiding efficient fuzz testing.
[0062] The following describes the automated simulation device for IoT device firmware provided in this application. The automated simulation device for IoT device firmware described below can be referred to in correspondence with the automated simulation method for IoT device firmware described above.
[0063] Figure 4 This is a schematic diagram of the structure of the automated firmware simulation device for IoT devices provided in the embodiments of this application, as shown below. Figure 4 As shown, the device 400 includes: The execution module 410 is used to execute the target firmware in a simulation environment through symbolic execution, generate an analysis and modeling knowledge base, identify the data register based on the control flow information of the symbol and the data characteristics between the symbol lifecycle, and select the path for execution based on the symbol lifecycle. Update module 420 is used to repeatedly execute the following process until a preset termination condition is met to complete the execution: The readings of the simulation peripherals are assigned based on the analytical modeling knowledge base; During the assignment process, if an unknown peripheral that has not been modeled is encountered, the execution path is reproduced to the access point of the unknown peripheral based on the current analysis and modeling knowledge base and the input file that triggers the unknown peripheral, and symbolic execution is started to explore in order to update the analysis and modeling knowledge base.
[0064] It should be understood that the above-described device is used to execute the methods in the above embodiments. The implementation principle and technical effect of the corresponding program modules in the device are similar to those described in the above methods. The working process of the device can be referred to the corresponding process in the above methods, and will not be repeated here.
[0065] Based on the methods in the above embodiments, Figure 5 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 5As shown in the illustration, this application provides an electronic device that may include a processor 510, a communications interface 520, a memory 530, and a communication bus 540. The processor 510, communications interface 520, and memory 530 communicate with each other via the communication bus 540. The processor 510 can call logical instructions stored in the memory 530 to execute the automated firmware simulation method for IoT devices described in the above embodiment.
[0066] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the automated simulation method for IoT device firmware described in the various embodiments of this application.
[0067] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program. When the computer program runs on a processor, it causes the processor to execute the IoT device firmware automated simulation method in the above embodiments.
[0068] Based on the methods in the above embodiments, this application provides a computer program product that, when running on a processor, causes the processor to execute the IoT device firmware automated simulation method in the above embodiments.
[0069] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.
[0070] The method steps in this application embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.
[0071] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).
[0072] It is understood that the various numerical designations used in the embodiments of this application are merely for the convenience of description and are not intended to limit the scope of the embodiments of this application.
[0073] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. An Internet of Things device firmware automated emulation method, characterized by, The method comprises the following steps: performing target firmware in a simulation environment through symbolic execution, generating an analysis modeling knowledge base, identifying data registers based on data characteristics between symbolic control flow information and symbol life cycle, and performing execution based on the life cycle of the symbol; repeating the following process until a preset ending condition is reached to complete the execution: assigning values to read values of simulation peripherals based on the analysis modeling knowledge base; in the assignment process, if an unknown peripheral that has not been modeled is encountered, based on the current analysis modeling knowledge base and the input file that triggers the unknown peripheral, the execution path is reproduced to the unknown peripheral access point, and symbolic execution is started for exploration to update the analysis modeling knowledge base.
2. The IoT device firmware automated emulation method of claim 1, wherein, The data register identification based on the data characteristics between the symbolic control flow information and the symbol life cycle comprises: when the firmware execution enters a certain interrupt service program, if the symbol created in response to the peripheral read operation appears in the condition register of the branch judgment outside the interrupt program, the peripheral register corresponding to the symbol is determined as a data register; in the interrupt service program, if the symbol created for the peripheral read operation is written to a global variable address or a certain specific address in the BSS segment, the peripheral register corresponding to the symbol is determined as a data register; under the condition of multi-path exploration, if the symbol in the condition register of the branch judgment is solved as a plurality of different specific values at a plurality of different branch path points, the peripheral register corresponding to the symbol is determined as a data register.
3. The IoT device firmware automation emulation method of claim 1, wherein, The execution based on the life cycle of the symbol comprises: if a plurality of execution branches are derived based on the symbol within the life cycle of the symbol, the life cycle end information is synchronized to all other execution branches determined by the symbol at the end of the life cycle of the symbol; the path is selected and executed based on the life cycle end information.
4. The IoT device firmware automation emulation method of claim 1, wherein, The assignment of values to read values of simulation peripherals based on the analysis modeling knowledge base comprises: when the accessed peripheral is a data register that has been identified, an external security test tool is used to provide test input values for the data register; when the peripheral has multiple paths, path selection and peripheral assignment are performed according to the data flow information in the analysis modeling knowledge base.
5. The IoT device firmware automation emulation method of claim 1, wherein, The method further comprises: in the process of assigning values to read values of simulation peripherals based on the analysis modeling knowledge base, triggering an interrupt based on the data flow information in the analysis modeling knowledge base as needed.
6. An Internet of Things device firmware automation emulation apparatus, characterized by, The method comprises the following steps: an execution module for performing target firmware in a simulation environment through symbolic execution, generating an analysis modeling knowledge base, identifying data registers based on data characteristics between symbolic control flow information and symbol life cycle, and performing execution based on the life cycle of the symbol; an update module for repeating the following process until a preset ending condition is reached to complete the execution: assigning values to read values of simulation peripherals based on the analysis modeling knowledge base; in the assignment process, if an unknown peripheral that has not been modeled is encountered, based on the current analysis modeling knowledge base and the input file that triggers the unknown peripheral, the execution path is reproduced to the unknown peripheral access point, and symbolic execution is started for exploration to update the analysis modeling knowledge base.
7. An electronic device, comprising: The method comprises the following steps: at least one memory for storing a computer program; at least one processor for executing the program stored in the memory, the processor being configured to perform the method for automated simulation of firmware of an internet of things device according to any one of claims 1 to 5 when the program stored in the memory is executed.
8. A computer-readable storage medium storing a computer program, the computer-readable storage medium comprising: A computer program product, comprising a computer readable medium storing the program, wherein the program is configured to make a processor execute the method for automated simulation of firmware of an internet of things device according to any one of claims 1 to 5 when the program is executed on the processor.
9. A computer program product, characterised in that, A computer program product, comprising a computer readable medium storing the program, wherein the program is configured to make a processor execute the method for automated simulation of firmware of an internet of things device according to any one of claims 1 to 5 when the program is executed on the processor.