Vulnerability Detection Method and Device, Computer Readable Medium, and Electronic Device

Abstract

The present disclosure provides a vulnerability detection method and apparatus, a computer-readable medium, and an electronic device, relating to the technical field of data security. The method includes: obtaining firmware code data corresponding to an Internet of Things device to be detected, and parsing the firmware code data to determine a test entry position; extracting device context information from the Internet of Things device through the test entry position; creating a cross-architecture simulation firmware according to the device context information, where the cross-architecture simulation firmware is used to simulate the operating environment of the Internet of Things device under different compilation architectures; performing vulnerability detection on the cross-architecture simulation firmware to generate a vulnerability detection report. The present disclosure can effectively improve the efficiency of vulnerability mining for Internet of Things device firmware, improve the accuracy of detected vulnerabilities, and can simulate Internet of Things devices under various compilation architectures through the cross-architecture simulation firmware, improving the compatibility of vulnerability detection for Internet of Things devices.

Description

Background Art

[0002] With the continuous improvement of people's living standards, Internet of Things (IoT) devices in various fields such as smart cameras and smart wearable devices are becoming increasingly popular among people. However, as the weakest link in IoT security, IoT terminals are more vulnerable to attacks. To ensure IoT security, it is necessary to detect vulnerabilities in IoT device firmware.

[0003] Currently, in related IoT device firmware vulnerability detection solutions, either rely on physical IoT devices, but large-scale parallel testing requires a considerable number of real hardware devices, with low automation and low vulnerability mining efficiency; or achieve automated analysis through software-based complete system simulation. However, due to the fragmentation problem of the IoT ecosystem (there are many types of operating systems and the system architectures are not unified), it is difficult to have a unified and efficient dynamic automated analysis method, with low compatibility and low accuracy of the detected vulnerabilities. Summary of the Invention

[0004] The purpose of the present disclosure is to provide a vulnerability detection method, a vulnerability detection device, a computer-readable medium, and an electronic device, thereby at least to a certain extent improving the vulnerability mining efficiency of IoT device firmware, enhancing the accuracy of the detected vulnerabilities, and implementing a vulnerability detection solution with high compatibility.

[0005] According to the first aspect of the present disclosure, there is provided a vulnerability detection method, including:

[0006] Obtain firmware code data corresponding to the IoT device to be detected, and parse the firmware code data to determine the test entry position;

[0007] Extract device context information from the IoT device through the test entry position;

[0008] Create a cross-architecture simulation firmware according to the device context information, where the cross-architecture simulation firmware is used to simulate the operating environment of the IoT device under different compilation architectures;

[0009] Perform vulnerability detection on the cross-architecture simulation firmware to generate a vulnerability detection report.

[0010] According to the second aspect of the present disclosure, there is provided a vulnerability detection device, including:

[0011] A firmware code parsing module, configured to obtain firmware code data corresponding to the IoT device to be detected, and parse the firmware code data to determine the test entry position;

[0012] A context information dump module, configured to extract device context information from the Internet of Things device through the test entry position;

[0013] An emulation environment creation module, configured to create a cross-architecture emulation firmware according to the device context information, where the cross-architecture emulation firmware is used to simulate the operating environment of the Internet of Things device under different compilation architectures;

[0014] A vulnerability detection module, configured to perform vulnerability detection on the cross-architecture emulation firmware and generate a vulnerability detection report.

[0015] According to a third aspect of the present disclosure, there is provided a computer-readable medium having a computer program stored thereon, and when the computer program is executed by a processor, the above method is implemented.

[0016] According to a fourth aspect of the present disclosure, there is provided an electronic device, characterized by including:

[0017] A processor; and

[0018] A memory, configured to store one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement the above method.

[0019] The vulnerability detection method provided by an embodiment of the present disclosure can parse the firmware code data corresponding to the Internet of Things device to be detected, determine the test entry position, then extract the device context information from the Internet of Things device through the test entry position, and create a cross-architecture emulation firmware for simulating the operating environment of the Internet of Things device under different compilation architectures according to the device context information. Finally, vulnerability detection is performed on the cross-architecture emulation firmware to generate a vulnerability detection report. On the one hand, risk analysis is performed on the firmware code data to determine the most vulnerable part as the test entry position, and vulnerability detection is performed based on the test entry position, which can effectively improve the efficiency of vulnerability detection and the detection rate of vulnerabilities; on the other hand, extracting device context information from the Internet of Things device and constructing a cross-architecture emulation firmware according to the device context information can ensure that the cross-architecture emulation firmware completely simulates the operating environment of the real Internet of Things device and improve the accuracy of the detected vulnerabilities; on the other hand, the cross-architecture emulation firmware can simulate the operating environment of the Internet of Things device under different compilation architectures, effectively improve the compatibility of the emulation process, can perform vulnerability detection on different types of Internet of Things devices, and the cross-architecture emulation firmware can test multiple Internet of Things devices in parallel, effectively improving the throughput of vulnerability detection and the efficiency of vulnerability detection.

[0020] It should be understood that the above general description and subsequent detailed description are only exemplary and explanatory, and cannot limit the present disclosure. Description of the Drawings

[0021] The accompanying drawings herein are incorporated into and form a part of this specification, showing embodiments consistent with the present disclosure, and are used together with the specification to explain the principles of the present disclosure. Obviously, the accompanying drawings in the following description are only some embodiments of the present disclosure, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts. In the drawings:

[0022] Figure 1 A schematic diagram showing an exemplary system architecture to which embodiments of the present disclosure can be applied;

[0023] Figure 2 A schematic flowchart showing a vulnerability in a related technology based on the analysis of the version of an introduced open-source tool;

[0024] Figure 3 A schematic flowchart showing a process of analyzing vulnerabilities by firmware reverse engineering and debugging in a related technology;

[0025] Figure 4 A schematic flowchart showing a process of mining firmware backdoors and protocol vulnerabilities based on an application in a related technology;

[0026] Figure 5 A schematic flowchart showing a process of automatically dynamically analyzing vulnerabilities based on a Linux-like embedded firmware in a related technology;

[0027] Figure 6 A schematic flowchart showing a process of a vulnerability detection method in an exemplary embodiment of the present disclosure;

[0028] Figure 7 A schematic flowchart showing a process of determining a test entry position in an exemplary embodiment of the present disclosure;

[0029] Figure 8 A schematic flowchart showing a process of extracting device context information in an exemplary embodiment of the present disclosure;

[0030] Figure 9 A schematic flowchart showing a process of creating a cross-architecture simulation firmware in an exemplary embodiment of the present disclosure;

[0031] Figure 10 A schematic flowchart showing a process of implementing vulnerability detection in an exemplary embodiment of the present disclosure;

[0032] Figure 11 A schematic diagram showing the composition of a vulnerability detection device in an exemplary embodiment of the present disclosure;

[0033] Figure 12 A schematic diagram showing an electronic device to which embodiments of the present disclosure can be applied. Detailed Implementation Modes

[0034] Example embodiments will now be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments.

[0035] In addition, the accompanying drawings are only schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repeated description will be omitted. Some of the block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0036] Figure 1 A schematic diagram of a system architecture showing an exemplary application environment to which the vulnerability detection method and apparatus according to embodiments of the present disclosure can be applied is shown.

[0037] As Figure 1 shown, the system architecture 100 may include one or more of the terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc. The terminal devices 101, 102, 103 may be various electronic devices with the ability to detect vulnerabilities and running a CPU (Central Processing Unit) simulation engine, including but not limited to desktop computers, portable computers, smartphones, and tablet computers, etc. It should be understood that Figure 1 the numbers of terminal devices, networks, and servers in

[0038] The vulnerability detection method provided by the embodiments of the present disclosure is generally executed in the terminal devices 101, 102, and 103. Correspondingly, the vulnerability detection device is generally disposed in the terminal devices 101, 102, and 103. However, those skilled in the art can easily understand that the vulnerability detection method provided by the embodiments of the present disclosure can also be executed by the server 105. Correspondingly, the vulnerability detection device can also be disposed in the server 105. No special limitation is made in this exemplary embodiment.

[0039] In related art one, a vulnerability mining solution based on the analysis of the introduced open-source tool versions is generally adopted. The introduction of open-source tools and SDKs (Software Development Kits) in software engineering is one of the main reasons for software security problems and vulnerabilities. Currently, mainstream commercial open-source compliance governance software adopts the Figure 2 scheme in Figure 2 As shown, in step S210, the IOT firmware is parsed to obtain the file system; in step S220, the notice file and version file in the file system are analyzed through a script to obtain the version numbers of the open-source components where they are located; in step S230, version matching and vulnerability determination are performed based on a locally built vulnerability database (for example, a vulnerability database can be established by crawling vulnerability information in recent years based on the National Information Security Vulnerability Sharing Platform CNVD and the National Information Security Vulnerability Database CNNVD).

[0040] In related art two, a method of firmware reverse engineering and debugging analysis is generally adopted, which is often used in the case of unconventional firmware formats. Some upstream suppliers often encrypt and shell-protect the firmware provided to downstream solution purchasers. In this scenario, it is impossible to control the security problems introduced by the IOT firmware. The IOT firmware provided by the upstream supplier is analyzed and debugged reversely to further identify and mine security vulnerabilities. As shown in Figure 3 In step S310, a common format firmware can be unpacked through relevant analysis tools; in step S320, for firmware with an uncommon format or protected by encryption and shelling, decryption and shelling operations need to be performed on it. Through steps S310 and S320, data such as the executable file, script, library file, binary program, and source code of the IOT firmware can be obtained. In step S330, the key function flow of common IOT operating systems can be obtained through reverse analysis. Generally, vulnerability mining and risk point detection can be performed through static code analysis technology based on symbolic execution; in step S340, relying on manual and expert experience, in-depth auditing and debugging of the assembly-level code are performed to obtain vulnerability-related information.

[0041] In related art three, generally, the method of mining IOT firmware backdoors and protocol vulnerabilities based on IOT application programs is adopted. The official application programs of IOT devices have rich application programming interfaces (APIs) in controlling and managing IOT devices, containing rich information about IOT devices, and can at least include the parsing of special protocols, key management functions (command execution and information collection), and backdoor functions. Refer to Figure 4 As shown, in step S410, through the application analysis of the IOT application program, traverse the UI components of the IOT application program and correspond to their respective functions one by one; in step S420, identify the protocol domain and function fields and pass them to the pollution source. For example, the pollution source can be a string, a system API, user input, etc.; in step S430, the researcher's goal is to detect memory corruption in the IOT device, so various fields of the protocol can be mutated and message assembly can be performed; in step S440, meaningful test messages (valid messages) are made in the IOT social mobile application through program logic, which is essentially a protocol-guided way of fuzzing, rather than explicitly performing code static analysis and auditing through reverse engineering; in step S450, obtain the feedback and response after sending the message in step S440 through wireless communication methods such as WIFI and Bluetooth, and implement crash monitoring. For example, detect whether the connection is disconnected, whether the protocol stack crashes, whether an error code is returned, etc. Through the status detection and log analysis of the IOT device, specific vulnerability details information can be obtained.

[0042] In related art four, generally, the automated dynamic analysis technology based on Linux-like embedded firmware is adopted, mainly relying on software-based complete system simulation and detection kernels to achieve the scalability required for automatically analyzing firmware binary files, and implementing automated methods to evaluate the prevalence of newly discovered security vulnerabilities in a large number of embedded device firmware images. Refer to Figure 5As shown, in step S510, firmware image files can be crawled from the FTP server and the WEB site, and at the same time, crawling rules can be set. For example, a whitelist of file extensions (img / chk / bin / stk / zip / tar / sys / rar / pkg / rmt, etc.) can be set to filter out upgrade packages and useless packages, etc.; in step S520, the ELF header file is read to determine the architecture information and file type of the firmware image file, and binwalk API is used for decompression. At the same time, a blacklist (such as PE32 for Windows / ELF for Linux / binaries for Macintosh, etc.) is set, and third-party tool libraries (such as jefferson / sasquatch) are used to extract JFFS32 / SquashFS file types; in step S530, the IOT firmware is simulated for execution, mainly focusing on several architecture types, such as MIPS (big endian, little endian), ARM (little endian), the simulation tool QEMU, etc.; in step S540, automatic analysis is performed through simulation, such as using POC and EXP of the Metasploit framework for vulnerability detection. In addition, debugging and simulated attacks can be achieved by combining IDA Pro code execution for dynamic tracking.

[0043] Among the firmware vulnerability mining solutions mentioned in the above four related technologies, they have good effects on conventional format firmware (firmware format), but due to the fragmentation problem of the Internet of Things ecosystem (there are many types of operating systems and the CPU architectures are not unified), it is difficult to have a unified and efficient dynamic automation analysis method; static analysis is mainly based on semantic similarity (static code feature model based on known vulnerabilities), and has good detection effects for problems with highly similar known vulnerabilities and vulnerability causes, but for complex calls and new vulnerability models, the detection rate of this method is relatively low; code coverage-guided fuzz testing is difficult to execute on real devices because only a small part of the firmware constitutes vulnerable code, and most of the mined code is not vulnerable, and the firmware initialization process involves a large amount of hardware interaction logic, but even if there are vulnerabilities in this part of the code, they cannot be remotely exploited; static analysis has better scalability than dynamic analysis because it does not require access to physical devices, but static analysis overly relies on manual experience and expert knowledge, is inefficient, and requires abstracting and modeling the essence of vulnerabilities during the automation implementation process, with too high time costs; dynamic solutions cannot guarantee coverage of all program states, and for complex code logics that are triggered, dynamic debugging and analysis methods cannot discover hidden vulnerability problems; for the Internet of Things firmware vulnerability mining solution based on the simulation environment, since accurate testing of Internet of Things firmware requires real devices, large-scale parallel testing requires a considerable amount of real hardware. The simulation-based solution is computationally resource-intensive and uses a simulation environment that is different from the actual device operating environment. In addition, due to the hardware dependence of device firmware, the simulation sometimes crashes when encountered, and it is difficult to confirm the validity of the crash due to the lack of hardware.

[0044] Based on one or more problems in the related art, in this exemplary embodiment, a vulnerability detection method is first provided. Taking the server executing this method as an example, the vulnerability detection method of the exemplary embodiment of the present disclosure will be specifically described below.

[0045] Figure 6 The flowchart of a vulnerability detection method in this exemplary embodiment is shown, including the following steps S610 to step S620:

[0046] In step S610, obtain the firmware code data corresponding to the Internet of Things device to be detected, and parse the firmware code data to determine the test entry position.

[0047] In an exemplary embodiment, the Internet of Things refers to the real-time collection of any objects or processes that need to be monitored, connected, and interacted through various information sensors, radio frequency identification technologies, global positioning systems, infrared sensors, laser scanners, and other devices and technologies. The sound, light, heat, electricity, mechanics, chemistry, biology, location, and other required information of the objects or processes are collected. Through various possible network accesses, the ubiquitous connection between things and things, and between things and people is realized, and the intelligent perception, identification, and management of items and processes are realized. The Internet of Things is an information carrier based on the Internet, traditional telecommunications networks, etc., enabling all ordinary physical objects that can be independently addressed to form an interconnected network.

[0048] For example, the Internet of Things devices can be smart home devices such as smart refrigerators and smart speakers that are connected to the Internet of Things, or they can be smart transportation devices such as smart cars, smart surveillance cameras, and smart public transportation platforms that are connected to the Internet of Things. This exemplary embodiment does not make special limitations on this.

[0049] Firmware is an important component in the structure of Internet of Things devices. Specifically, it refers to the "driver program" stored inside the Internet of Things devices. Through the firmware, the operating system can perform specific machine operation actions according to the standard device drivers.

[0050] Firmware code data refers to the binary code program written into the EPROM (erasable programmable read-only memory) or EEPROM (electrically erasable programmable read-only memory) of the Internet of Things device. By parsing the firmware code data, defects in the system security policy of the Internet of Things device firmware, that is, vulnerabilities, can be found in advance, so as to repair the vulnerabilities of the Internet of Things device firmware and ensure the use safety of the Internet of Things device.

[0051] The test entry position refers to the functional functions in the firmware code data that are more vulnerable to attacks. For example, the test entry position can be a functional function that operates on the memory space more frequently, or a functional function that is called more frequently. Of course, it can also be a functional function that is more vulnerable to attacks determined by other means. This exemplary embodiment does not make any special restrictions on the type of functional function corresponding to the test entry position.

[0052] By parsing the firmware code data, multiple functional functions in the firmware code data that are more vulnerable to attacks are found, and these multiple functional functions are used as the test entry positions during subsequent vulnerability detection, which can effectively improve the detection rate of vulnerabilities, and it is not necessary to cover all the firmware code data during the test process, effectively improving the detection efficiency of vulnerabilities.

[0053] In step S620, device context information is extracted from the IoT device through the test entry position.

[0054] In an exemplary embodiment, device context information refers to the data that can characterize the current execution environment of the functional function at the test entry position extracted from the IoT device. For example, the device context information can be a set of register states, a set of memory segments, or architecture information, etc. corresponding to the functional function at the test entry position, or it can be combined information composed of a set of register states, a set of memory segments, and architecture information. Of course, the device context information can also be other types of data that can characterize the current execution environment of the functional function at the test entry position. This exemplary embodiment does not make any special restrictions on this.

[0055] After determining the test entry position in the IoT device, the corresponding device context information can be extracted from the test entry position, and simulation can be achieved through the device context information, which can accurately simulate the real operating environment of the IoT device in the form of system simulation, effectively ensuring the detection rate and accuracy of vulnerabilities.

[0056] In step S630, a cross-architecture simulation firmware is created according to the device context information, and the cross-architecture simulation firmware is used to simulate the operating environment of the IoT device under different compilation architectures.

[0057] In an exemplary embodiment, the cross-architecture simulation firmware refers to a simulation firmware that simulates the CPU in a pure software manner to achieve the simulation of the operating environment of the IoT device under different compilation architectures. For example, the CPU emulator can be set according to the architecture information of the IoT device to be detected, and the extracted device context information can be migrated to the set CPU emulator, and then the cross-architecture simulation firmware for simulating the real operating environment of the IoT device to be detected can be obtained.

[0058] The architecture information of the cross - architecture simulation firmware and the internal execution environment data are consistent with those of real IoT devices, effectively ensuring the detection rate and accuracy of vulnerabilities. At the same time, since the cross - architecture simulation firmware can simulate the operating environments of IoT devices under different compilation architectures, multiple types of IoT devices can be tested in parallel through the cross - architecture simulation firmware, effectively improving the throughput of vulnerability detection and further enhancing the vulnerability detection efficiency.

[0059] In step S640, vulnerability detection is performed on the cross - architecture simulation firmware to generate a vulnerability detection report.

[0060] In an exemplary embodiment, vulnerability detection can be performed on the constructed cross - architecture simulation firmware. For example, multiple test cases can be constructed, and the cross - architecture simulation firmware can be fuzz - tested through the test cases. After a system crash occurs, record the function position where the crash occurs, that is, the vulnerability position in the firmware of the IoT device to be detected, and record the test cases used to cause the crash. Finally, a vulnerability detection report is generated and provided to the user to facilitate the user's further analysis of the vulnerability and the way to fix the vulnerability, effectively ensuring the security of the IoT device.

[0061] The following details steps S610 to S640.

[0062] In an exemplary embodiment, in step S610, it can be achieved through Figure 7 the steps in Figure 7 to parse the firmware code data. As shown in

[0063] Step S710, determine the functional functions in the firmware code data and determine the complexity corresponding to the functional functions;

[0064] Step S720, group the functional functions according to the complexity to obtain multiple functional function groups;

[0065] Step S730, determine the target functional functions in each functional function group whose probability of being attacked is greater than or equal to a preset threshold, and use the target functional functions as the test entry positions.

[0066] Among them, a functional function refers to a function in an IoT device used to implement a specific function or action, and complexity is data that measures the importance of a functional function in an IoT device. Specifically, for a functional function, the higher the complexity, the more complex the function logic can be represented, and at the same time, the greater the probability of the function having a vulnerability.

[0067] Specifically, the reference relationship of the functional function can be obtained. Further, the number of times the functional function is referenced can be determined according to the reference relationship. Then, the complexity corresponding to the functional function can be determined according to the logic control flow graph corresponding to the functional function and the number of times the functional function is referenced. Among them, the firmware code data can be analyzed by a preset code analysis tool to obtain the logic control flow graph corresponding to the functional function and the reference relationship of the functional function.

[0068] For example, the complexity corresponding to the functional function can be determined by the relational expression (1):

[0069] V(G) = E - N + 2 + C (1)

[0070] Among them, G can represent the functional function, V(G) can represent the complexity corresponding to the functional function, E can represent the number of edges in the logic control flow graph corresponding to the functional function (i.e., the sequential structure part of the functional function in the firmware code data), N can represent the number of nodes in the logic control flow graph corresponding to the functional function, and C can represent the number of times the functional function is referenced.

[0071] In order not to miss any vulnerabilities in the functional functions with low complexity, the functional functions in the firmware code data can be grouped according to the complexity of the functional functions. The functional functions with the same complexity are used as a functional function group. Optionally, multiple functional function groups can be constituted into a functional function group list, where a single element of the functional function group list is multiple functional functions with the same complexity.

[0072] After obtaining the functional function group list, the target functional functions that are more vulnerable to attacks in each functional function group can be determined. Specifically, the vulnerability characteristic index algorithm can be used to sort each functional function group in the functional function group list, and calculate the attack possibility corresponding to each functional function in the functional function group, and the functional functions in each functional function group whose attack possibility is greater than or equal to the preset threshold are used as the target functional functions.

[0073] Specifically, the function sensitivity corresponding to the functional function in the functional function group can be determined, the number of memory operations of the functional function can be obtained, and the attack possibility of the functional function can be determined according to the function sensitivity and the number of memory operations.

[0074] Among them, the function sensitivity refers to the degree of influence (global influence index) used to measure the functional function in implementing a specific action or function. The number of memory operations refers to the number of read and write operations on the memory space during the operation of the functional function. The sum value of the function sensitivity and the number of memory operations can be used as the attack possibility of the functional function, or the weighted average value of the function sensitivity and the number of memory operations can be used as the attack possibility of the functional function. This example embodiment does not make special limitations on this.

[0075] Furthermore, when it is determined that the attack possibility of a function is greater than or equal to a preset threshold, the function can be used as a target function; when it is determined that the attack possibility of a function is greater than or equal to a preset threshold, the function is not used as a test entry position. Among them, the preset threshold can be custom-set according to different calculation methods of the attack possibility and actual application scenarios, and this exemplary embodiment does not make special limitations on this.

[0076] Grouping function functions by complexity to obtain function groups with the same complexity can effectively avoid the problem of missing vulnerabilities in low-complexity function functions. At the same time, screening target function functions from each function group through the attack possibility of function functions and using the target function functions as the test entry positions finally used for fuzz testing can effectively reduce the problem of large test volume caused by comprehensively covering firmware code data, and effectively improve the vulnerability detection efficiency while ensuring the vulnerability detection rate.

[0077] In related technologies, when analyzing Internet of Things devices, it is often impossible to access the inside of the device for more detailed security analysis. For example, in Internet of Things devices such as routers and CPEs, only a WEB management configuration interface is provided for users to facilitate configuration and initialization work. In this case, it is impossible to access the process and port information of the current Internet of Things device.

[0078] In an exemplary embodiment, in step S620, it is possible to Figure 8 The steps in extract device context information from the Internet of Things device through the test entry position. Refer to Figure 8 shown, specifically including:

[0079] Step S810, obtaining the command parser of the Internet of Things device;

[0080] Step S820, building a debug port of the Internet of Things device based on the command parser to extract device context information at the test entry position in the Internet of Things device through the debug port.

[0081] Among them, the command parser (Command Interpreter) refers to a tool in the Internet of Things device for executing system commands, similar to the cmd.exe debug tool under the DOS system. In the computer field, the command parser is also called the computer shell layer (i.e., shell, shell, relative to the kernel).

[0082] After obtaining the command parser of the Internet of Things device, a remote debugging port can be called or constructed in the Internet of Things device, and device context information can be extracted at the test entry position in the Internet of Things device through this debugging port. For example, after obtaining the command parser of the Internet of Things device, send the statically linked remote debugging service gdbserver to the Internet of Things device through the network, then specify the debugging port on the Internet of Things device side through the remote debugging service gdbserver, connect to the remote debugging port of the test end through the debugging tool gdb, and then run to the test entry position to start preparing to dump the device context information.

[0083] Among them, the device context information may include the context information corresponding to each test entry position. Specifically, the device context information may include any one or a combination of a register state set, a memory segment set, and device architecture information.

[0084] Optionally, since the command parser of the Internet of Things device is generally protected and the debugging port cannot be directly established or constructed, in this embodiment, the command parser of the Internet of Things device can be obtained through one or a combination of the following methods: obtaining the command parser of the Internet of Things device based on the remote login service provided in the Internet of Things device, obtaining the command parser of the Internet of Things device based on the universal asynchronous receiver / transmitter of the Internet of Things device, and obtaining the command parser of the Internet of Things device based on the method of firmware update for the Internet of Things device.

[0085] Among them, the remote login service refers to a service that allows users to remotely operate the Internet of Things device through the network. For example, the remote login service can be a telnet service or an ssh service, and this exemplary embodiment does not make special limitations on this. If the Internet of Things device provides a telnet service or an ssh service at startup, the command parser (shell) of the Internet of Things device can be directly obtained through the telnet service or the ssh service.

[0086] If the Internet of Things device under the current firmware version does not provide a remote login service, the firmware to be upgraded corresponding to the Internet of Things device can be extracted, and the startup script rcS can be modified in the firmware to be upgraded so that the Internet of Things device provides a telnet or ssh service when starting up. Then, the firmware to be upgraded is repackaged, and the modified firmware is updated to the Internet of Things device. Then, the Internet of Things device can provide a telnet service or an ssh service when starting up, and thus the command parser of the Internet of Things device can be obtained.

[0087] If the Internet of Things device does not provide a Telnet service or an SSH service at startup, hardware analysis can be performed on the Internet of Things device to find the Universal Asynchronous Receiver / Transmitter (UART) interface in the Internet of Things device, and then appropriate baud rates can be set for the RXD, TXD, and GND pins to obtain the command parser of the Internet of Things device.

[0088] In an exemplary embodiment, step S630 can be implemented by Figure 9 the steps in Figure 9 to create cross-architecture simulation firmware according to the device context information. As shown in

[0089] Step S910, obtain the architecture information corresponding to the Internet of Things device, where the architecture information includes an instruction set, a word length, and an endianness;

[0090] Step S920, configure a preset analog simulation engine according to the architecture information, and migrate the device context information to the configured analog simulation engine to obtain the cross-architecture simulation firmware corresponding to the Internet of Things device.

[0091] Among them, the system architecture refers to the computer system structure, or the computer architecture, which is the highest-level concept of a system in its environment. The system architecture can determine the connection between the hardware and software of a computer. The architecture information is the relevant data used when implementing the system architecture. For example, the architecture information can include information such as an instruction set, a word length, and an endianness. Of course, this is only an illustrative example here, and the architecture information can also be other system architecture information. This exemplary embodiment is not limited thereto.

[0092] The simulation engine refers to a simulator used to simulate the architecture information and operating environment of Internet of Things devices. For example, the simulation engine can be a CPU emulator (or CPU simulator). Optionally, the simulation engine can be Unicorn Engine. Among them, the CPU emulator is a tool that simulates a real CPU in a pure software manner, so as to achieve running instructions with different instruction sets on one architecture. The input of the CPU emulator is binary code or fragmented binary code. Before using the CPU emulator, it is necessary to set the context state in the execution environment and specify the architecture information. The CPU emulator creates and maintains a virtual stack and memory segments, then decodes the binary code into multiple instructions according to the specified instruction set and endianness information, and reads and interprets each instruction after the formal execution, and updates the context state after each instruction is executed. Due to the diversity of architectures and instructions, the implementation of the CPU emulator is very complex and cumbersome. The simulation tool QEMU has implemented a pure CPU emulator, and Unicorn Engine (supporting multiple architectures) retains the CPU emulator part of QEMU and removes the simulation of other devices, providing a Python interface binding.

[0093] Specifically, the device context information can be migrated to Unicorn Engine based on the Unicorn Engine API. For example, the register group can be written through reg_write, the stack space can be allocated through mem_map, and the memory can be written through mem_write, and finally the import of the device context information of the Internet of Things device is realized, and the migration of the entry point state from the physical device to the CPU simulator is completed.

[0094] Using a simulation engine such as Unicorn Engine for multi-architecture CPU simulation can enable vulnerability testing to be separated from real Internet of Things device debugging, make binary programs under different compilation architectures run, perform some fuzzing operations, and can simulate small segments of instructions or a single function. Specifically, the simulation engine can be configured through the architecture information, and the device context information can be migrated to the configured simulation engine to obtain the cross-architecture simulation firmware corresponding to the Internet of Things device, so that the obtained cross-architecture simulation firmware can simulate Internet of Things devices under different compilation architectures, improve the compatibility of the simulation of Internet of Things devices, and build a cross-architecture simulation firmware through the simulation engine, which can perform large-scale parallel testing and further improve the vulnerability detection efficiency.

[0095] In an exemplary embodiment, in step S640, it can be achieved through Figure 10 the steps of performing vulnerability detection on the cross-architecture simulation firmware. As shown in Figure 10 it specifically may include:

[0096] Step S1010: Obtain pre-generated test cases;

[0097] Step S1020: Perform fuzz testing on the cross-architecture simulation firmware based on the test cases, and generate a vulnerability detection report;

[0098] A test case refers to a description of the test tasks for a specific software product, and is a document reflecting test plans, methods, techniques, and strategies. The content of a test case can include test objectives, test environments, input data, test steps, expected results, test scripts, etc., and finally form a document. Simply put, a test case can be a set of test inputs, execution conditions, and expected results prepared for a specific goal, used to verify whether a specific software requirement is met.

[0099] A vulnerability detection report refers to the test records or crash logs generated during the fuzz testing process of the cross-architecture simulation firmware. For example, a vulnerability detection report can include the target test cases that caused crashes, can also include the target test entry positions corresponding to the target test cases. Of course, it can also include the states of memory and registers when a crash occurs, etc. This exemplary embodiment does not make special limitations on the detailed content in the vulnerability detection report.

[0100] Optionally, the data can be customized according to the input test cases, and test cases can be generated based on the customized data of the test cases; or preset initial test cases can be obtained, and the initial test cases can be mutated to generate test cases. This exemplary embodiment does not make special limitations on the generation methods of test cases.

[0101] The customized data of the test case refers to the data obtained by the user simply modeling the protocol or input, and test cases that meet the user's needs can be automatically created based on the customized data of the test case.

[0102] The initial test case refers to multiple test cases pre-created by the user. Based on the initial test cases, multiple new test cases can be obtained through mutation. For example, the initial test cases can be mutated through a genetic algorithm to obtain new test cases.

[0103] Through the generated test cases, the input functions based on the hook module can be hijacked, the differences in various data input methods can be masked, and a unified interface can be provided to facilitate the target function to read the test cases. For example, in the test of DLink routers, by hijacking the getenv function, the common gateway interface program of the IoT device can obtain the CGI environment variables controlled by the attacker through the getenv function. To adapt to various firmware programs, the design of this solution is scalable, thus supporting users to customize the hijacking function and effectively improving the flexibility of test cases. If the field data to be tested has been imported into memory at the entry point of fuzz testing, the parameters of the function can be monitored, and if the field or the address of the field is found, this parameter can be replaced with the generated test case to implement fuzz testing in this case.

[0104] By generating test cases in a generation-based or mutation-based manner, the flexibility of test case generation can be effectively improved, the effectiveness and stability of fuzz testing can be ensured, and the detection rate and accuracy of vulnerabilities can be further improved.

[0105] Furthermore, during the fuzz testing of the cross-architecture emulated firmware with test cases, if stack data overflow is detected or an abnormal execution state is detected, it can be determined that the cross-architecture emulated firmware has a program crash. At the same time, record the target test case that causes the program crash and the target test entry position corresponding to the target test case, generate a vulnerability detection report, and use the target test entry position as the vulnerability position.

[0106] Since the memory management unit (MMU) of some IoT devices generally does not set a memory corruption check module, there will be a situation where the program does not crash although a memory overflow occurs. This situation is called silent memory corruption. To solve this problem, optionally, after a sensitive function call, this embodiment can check the stack data to see if there is an overflow. If there is an overflow, it can be considered that a program crash has occurred, that is, a vulnerability is found, and record the target test case that causes the stack data overflow at this time and the target test entry position corresponding to the target test case.

[0107] Optionally, it is also possible to monitor abnormal situations during the execution process and identify the anomalies. For example, when it is determined that the program does not execute according to the expected result of the test case, it can be determined that an abnormal execution state occurs at this time. When it is determined that an abnormal execution state occurs, it can be considered that the executed program has a crash, that is, a vulnerability is found, and record the target test case that causes the stack data overflow at this time and the target test entry position corresponding to the target test case.

[0108] The vulnerability detection method in this disclosure solves compatibility issues by enabling fuzz testing through cross-architecture simulation of the compatible Internet of Things (IoT) device environment in the firmware; through risk code annotation (preprocessing and risk analysis of the code) and subsequent enhanced virtual execution (realizing multi-architecture environment simulation through cross-architecture simulation firmware), an enhanced process simulation is achieved, effectively improving the detection rate of vulnerabilities, enhancing the accuracy and authenticity of the detected vulnerabilities, increasing the throughput of IoT device vulnerability detection, and improving vulnerability detection efficiency.

[0109] The vulnerability detection framework implemented in the embodiments of this disclosure can discover two 0-day vulnerabilities (a type of sudden vulnerability) in an IoT device in just 4 hours of operation. Compared with existing IoT firmware fuzz testing frameworks, it can more effectively discover vulnerabilities in real IoT devices, effectively improving vulnerability discovery efficiency; at the same time, the throughput of the cross-architecture simulation firmware is on average 10 times higher than that of fuzz testing based on system mode simulation, enabling it to find N-day vulnerabilities faster than fuzz testing based on system mode simulation and being able to find 0-day vulnerabilities.

[0110] In summary, in this exemplary embodiment, the firmware code data corresponding to the IoT device to be detected can be parsed to determine the test entry location, then the device context information can be extracted from the IoT device through the test entry location, and a cross-architecture simulation firmware for simulating the operating environment of the IoT device under different compilation architectures can be created based on the device context information. Finally, vulnerability detection is performed on the cross-architecture simulation firmware to generate a vulnerability detection report. On the one hand, performing risk analysis on the firmware code data to determine the most vulnerable part as the test entry location and conducting vulnerability detection based on this test entry location can effectively improve the efficiency of vulnerability detection and increase the detection rate of vulnerabilities; on the other hand, extracting device context information from the IoT device and constructing a cross-architecture simulation firmware based on the device context information can ensure that the cross-architecture simulation firmware fully simulates the operating environment of a real IoT device, improving the accuracy of the detected vulnerabilities; furthermore, the cross-architecture simulation firmware can simulate the operating environment of IoT devices under different compilation architectures, effectively enhancing the compatibility of the simulation process, enabling vulnerability detection for different types of IoT devices, and the cross-architecture simulation firmware can concurrently test multiple IoT devices, effectively increasing the throughput of vulnerability detection and improving vulnerability detection efficiency.

[0111] It should be noted that the above-mentioned drawings are only schematic illustrations of the processes included in the method according to the exemplary embodiments of this disclosure, rather than for restrictive purposes. It is easy to understand that the processes shown in the above-mentioned drawings do not indicate or limit the chronological order of these processes. Additionally, it is also easy to understand that these processes can be executed synchronously or asynchronously, for example, in multiple modules.

[0112] Further, referring toFigure 11 As shown, in the embodiment of this example, a vulnerability detection device 1100 is further provided, including a firmware code parsing module 1110, a context information dumping module 1120, a simulation environment creation module 1130, and a vulnerability detection module 1140. Among them:

[0113] The firmware code parsing module 1110 is used to obtain the firmware code data corresponding to the Internet of Things device to be detected, and parse the firmware code data to determine the test entry position;

[0114] The context information dumping module 1120 is used to extract device context information from the Internet of Things device through the test entry position;

[0115] The simulation environment creation module 1130 is used to create a cross-architecture simulation firmware according to the device context information, and the cross-architecture simulation firmware is used to simulate the operating environment of the Internet of Things device under different compilation architectures;

[0116] The vulnerability detection module 1140 is used to detect vulnerabilities in the cross-architecture simulation firmware and generate a vulnerability detection report.

[0117] In an exemplary embodiment, the firmware code parsing module 1110 may include:

[0118] A complexity determination unit, configured to determine the functional functions in the firmware code data and determine the complexity corresponding to the functional functions;

[0119] A functional function grouping unit, configured to group the functional functions according to the complexity to obtain multiple functional function groups;

[0120] A test entry position determination unit, configured to determine the target functional functions in each functional function group whose attack possibility is greater than or equal to a preset threshold, and use the target functional functions as the test entry position.

[0121] In an exemplary embodiment, the complexity determination unit may be used to:

[0122] Obtain the reference relationship of the functional functions;

[0123] Determine the complexity corresponding to the functional function according to the logic control flow graph corresponding to the functional function and the reference relationship.

[0124] In an exemplary embodiment, the test entry position determination unit may be used to:

[0125] Determine the function sensitivity corresponding to the functional functions in the functional function group, and obtain the number of memory operations of the functional functions;

[0126] Determine the attack possibility of the functional function according to the function sensitivity and the number of memory operations;

[0127] If it is determined that the attack possibility of the functional function is greater than or equal to a preset threshold, then use the functional function as the target functional function.

[0128] In an exemplary embodiment, the context information dump module 1120 can be used to:

[0129] Obtain the command parser of the IoT device;

[0130] Build a debug port of the IoT device based on the command parser, so as to extract device context information at the test entry position in the IoT device through the debug port;

[0131] Wherein, the device context information includes the context information corresponding to each test entry position, and the device context information includes any one or a combination of a register state set, a memory segment set, and device architecture information.

[0132] In an exemplary embodiment, the context information dump module 1120 can also be used to:

[0133] Based on the remote login service provided in the IoT device, obtain the command parser of the IoT device; or

[0134] Based on the universal asynchronous transceiver of the IoT device, obtain the command parser of the IoT device; or

[0135] Based on the method of firmware updating the IoT device, obtain the command parser of the IoT device.

[0136] In an exemplary embodiment, the simulation environment creation module 1130 can be used to:

[0137] Obtain the architecture information corresponding to the IoT device, where the architecture information includes an instruction set, a word length, and an endianness;

[0138] Configure a preset simulation engine according to the architecture information, and migrate the device context information to the configured simulation engine to obtain a cross-architecture simulation firmware corresponding to the IoT device.

[0139] In an exemplary embodiment, the simulation engine includes Unicorn Engine.

[0140] In an exemplary embodiment, the vulnerability detection module 1140 can be used to:

[0141] Obtain pre-generated test cases;

[0142] Perform fuzz testing on the cross-architecture simulation firmware based on the test cases, and generate a vulnerability detection report;

[0143] Wherein, the vulnerability detection report includes the target test cases that cause crashes, and the target test entry positions corresponding to the target test cases.

[0144] In an exemplary embodiment, the vulnerability detection module 1140 can be used to:

[0145] Customize data according to the input test cases, and generate test cases according to the customized data of the test cases; or

[0146] Obtain preset initial test cases, and perform mutation processing on the initial test cases to generate test cases.

[0147] In an exemplary embodiment, the vulnerability detection device 1100 may further include a crash monitoring unit, and the crash monitoring unit can be used to:

[0148] During the fuzz testing of the cross-architecture simulation firmware by the test cases, if stack data overflow or abnormal execution status is detected, it is determined that the cross-architecture simulation firmware has a program crash;

[0149] Record the target test cases that cause the program crash and the target test entry positions corresponding to the target test cases, and use the target test entry positions as vulnerability positions.

[0150] The specific details of each module in the above device have been described in detail in the implementation manner of the method part. The undisclosed detailed content can refer to the implementation manner content of the method part, and thus will not be elaborated here.

[0151] Those skilled in the art of the present disclosure can understand that various aspects of the present disclosure can be implemented as a system, a method, or a program product. Therefore, various aspects of the present disclosure can be specifically implemented in the following forms, namely: a complete hardware implementation manner, a complete software implementation manner (including firmware, microcode, etc.), or an implementation manner combining hardware and software aspects, which can be collectively referred to as "circuit", "module", or "system" here.

[0152] An exemplary embodiment of the present disclosure provides an electronic device for implementing a vulnerability detection method, which can be Figure 1 the terminal devices 101, 102, 103 or the server 105 in. The electronic device includes at least a processor and a memory. The memory is used to store executable instructions of the processor, and the processor is configured to execute the vulnerability detection method by executing the executable instructions.

[0153] Next, taking Figure 12Taking the electronic device 1200 as an example, the structure of the electronic device in the present disclosure will be described by way of example. Figure 12 The illustrated electronic device 1200 is merely an example and should not impose any limitation on the functions and scope of use of the embodiments of the present disclosure.

[0154] As Figure 12 shown, the electronic device 1200 is presented in the form of a general-purpose computing device. The components of the electronic device 1200 may include, but are not limited to: at least one processing unit 1210, at least one storage unit 1220, a bus 1230 connecting different system components (including the storage unit 1220 and the processing unit 1210), and a display unit 1240.

[0155] Among them, the storage unit 1220 stores program codes, and the program codes can be executed by the processing unit 1210, so that the processing unit 1210 executes the vulnerability detection method in this specification.

[0156] The storage unit 1220 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) 1221 and / or a cache storage unit 1222, and may further include a read-only storage unit (ROM) 1223.

[0157] The storage unit 1220 may further include a program / utilities 1224 having a set (at least one) of program modules 1225. Such program modules 1225 include, but are not limited to: an operating system, one or more application programs, other program modules, and program data. The implementation of a network environment may be included in each or some combination of these examples.

[0158] The bus 1230 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of the various bus structures.

[0159] The electronic device 1200 can also communicate with one or more external devices 1270 (such as sensor devices, Bluetooth devices, etc.), and can also communicate with one or more devices that enable a user to interact with the electronic device 1200, and / or communicate with any device that enables the electronic device 1200 to communicate with one or more other computing devices (such as routers, modems, etc.). Such communication can be carried out through the input / output (I / O) interface 1250. Moreover, the electronic device 1200 can also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through the network adapter 1260. As shown in the figure, the network adapter 1260 communicates with other modules of the electronic device 1200 through the bus 1230. It should be understood that although not shown in the figure, other hardware and / or software modules can be used in combination with the electronic device 1200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and sensor modules (such as gyroscope sensors, magnetic sensors, acceleration sensors, distance sensors, proximity light sensors, etc.).

[0160] Through the description of the above embodiments, those skilled in the art can easily understand that the exemplary embodiments described herein can be implemented by software or by a combination of software and necessary hardware. Therefore, the technical solutions according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

[0161] The exemplary embodiments of the present disclosure also provide a computer-readable storage medium, on which a program product capable of implementing the above methods of this specification is stored. In some possible embodiments, various aspects of the present disclosure can also be implemented in the form of a program product, which includes program code. When the program product runs on a terminal device, the program code is used to enable the terminal device to execute the steps according to various exemplary embodiments described in the "Exemplary Method" section of this specification.

[0162] It should be noted that the computer-readable medium shown in this disclosure can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to: an electrical connection with 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0163] In this disclosure, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. And in this disclosure, a computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, in which computer-readable program code is carried. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination of the above.

[0164] In addition, the program code for performing the operations of this disclosure can be written in any combination of one or more programming languages. The programming languages include object-oriented programming languages such as Java, C++, etc., and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, executed as an independent software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, by using an Internet service provider to connect through the Internet).

[0165] Other embodiments of the present disclosure will be readily apparent to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include known common general knowledge or conventional technical means in the technical field not disclosed in the present disclosure. The specification and examples are only to be considered as exemplary, and the true scope and spirit of the present disclosure are pointed out by the claims.

[0166] It should be understood that the present disclosure is not limited to the exact structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present disclosure is only limited by the appended claims.

Claims

1. A vulnerability detection method, characterized in that, it includes: Obtain the firmware code data corresponding to the Internet of Things device to be detected, and parse the firmware code data to determine the test entry position; Extract device context information from the Internet of Things device through the test entry position, including: obtaining the command parser of the Internet of Things device; building a debug port of the Internet of Things device based on the command parser to extract device context information at the test entry position in the Internet of Things device through the debug port; wherein, the device context information includes the context information corresponding to each test entry position, and the device context information includes any one or a combination of a register state set, a memory segment set, and device architecture information; Create a cross-architecture simulation firmware according to the device context information, and the cross-architecture simulation firmware is used to simulate the operating environment of the Internet of Things device under different compilation architectures; Perform vulnerability detection on the cross-architecture simulation firmware to generate a vulnerability detection report.

2. The method according to claim 1, characterized in that, The parsing of the firmware code data to determine the test entry position includes: Determine the functional functions in the firmware code data and determine the complexity corresponding to the functional functions; Group the functional functions according to the complexity to obtain a plurality of functional function groups; Determine the target functional functions in each functional function group whose attack possibility is greater than or equal to a preset threshold, and use the target functional functions as the test entry position.

3. The method according to claim 2, characterized in that, The determining the complexity corresponding to the functional function includes: Obtain the reference relationship of the functional function; Determine the complexity corresponding to the functional function according to the logic control flow graph corresponding to the functional function and the reference relationship.

4. The method according to claim 2, characterized in that, The determining the target functional functions in each functional function group whose attack possibility is greater than or equal to a preset threshold includes: Determine the function sensitivity corresponding to the functional functions in the functional function group and obtain the number of memory operations of the functional functions; Determine the attack possibility of the functional functions according to the function sensitivity and the number of memory operations; If it is determined that the attack possibility of the functional function is greater than or equal to a preset threshold, then use the functional function as the target functional function.

5. The method according to claim 1, characterized in that, The obtaining the command parser of the Internet of Things device includes: Based on the remote login service provided in the Internet of Things device, obtain the command parser of the Internet of Things device; or Based on the universal asynchronous receiver / transmitter of the Internet of Things device, obtain the command parser of the Internet of Things device; or Based on the method of firmware updating the Internet of Things device, obtain the command parser of the Internet of Things device.

6. The method according to claim 1, characterized in that, The creating a cross-architecture simulation firmware according to the device context information includes: Obtain the architecture information corresponding to the Internet of Things device, where the architecture information includes instruction set, word length, and endianness; Configure a preset simulation engine according to the architecture information, and migrate the device context information into the configured simulation engine to obtain a cross-architecture simulation firmware corresponding to the Internet of Things device.

7. The method according to claim 6, wherein, the simulation engine includes Unicorn Engine.

8. The method according to claim 1, wherein, the vulnerability detection of the cross-architecture simulation firmware to generate a vulnerability detection report includes: Obtain pre-generated test cases; Perform fuzz testing on the cross-architecture simulation firmware based on the test cases to generate a vulnerability detection report; wherein, the vulnerability detection report includes the target test case that causes a crash and the target test entry position corresponding to the target test case.

9. The method according to claim 8, wherein, the obtaining of the pre-generated test cases includes: Customize data according to the input test cases and generate test cases according to the customized data; or Obtain preset initial test cases and perform mutation processing on the initial test cases to generate test cases.

10. The method according to claim 8, wherein, the method further includes: During the fuzz testing of the cross-architecture simulation firmware by the test cases, if stack data overflow or abnormal execution status is detected, it is determined that the cross-architecture simulation firmware has a program crash; Record the target test case that causes the program crash and the target test entry position corresponding to the target test case, and use the target test entry position as the vulnerability position.

11. A vulnerability detection device, wherein, includes: A firmware code parsing module, configured to obtain the firmware code data corresponding to the Internet of Things device to be detected and parse the firmware code data to determine the test entry position; A context information dumping module, configured to extract device context information from the Internet of Things device through the test entry position, including: obtaining the command parser of the Internet of Things device; building a debug port of the Internet of Things device based on the command parser to extract device context information at the test entry position in the Internet of Things device through the debug port; wherein, the device context information includes the context information corresponding to each test entry position, and the device context information includes any one or a combination of a register status set, a memory segment set, and device architecture information; A simulation environment creation module, configured to create a cross-architecture simulation firmware according to the device context information, where the cross-architecture simulation firmware is used to simulate the operating environment of the Internet of Things device under different compilation architectures; A vulnerability detection module, configured to perform vulnerability detection on the cross-architecture simulation firmware to generate a vulnerability detection report.

12. A computer-readable medium, on which a computer program is stored, wherein, when the computer program is executed by a processor, it implements the method according to any one of claims 1 to 10.

13. An electronic device, characterized in that, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the method according to any one of claims 1 to 10 by executing the executable instructions.

Images