IoT device security analysis system and method based on cross-platform simulation

Abstract

The present invention provides a cross-platform simulated IoT device security analysis system and method, which can be used to analyze and simulate IoT device security issues of different platforms and architectures. First, the input device firmware is unpacked and its architecture is parsed. For Linux-based embedded systems, a static analysis method of shared keyword-aware taint detection is used to track user input between the front-end and the back-end, and the possible security vulnerabilities of the output system are visualized. Based on the output results, the system automatically selects the full system mode or user mode to dynamically simulate the binary files involved in the security vulnerabilities; for RTOS-based embedded systems, the base address relocation and function semantic recovery methods are used to locate the security vulnerabilities of the output files, and the binary files involved are simulated in fragments based on the output results. Finally, the corresponding vulnerabilities are mined and verified under different system and architecture environments.

Description

Technical Field

[0001] The present invention relates to the technical field of network security, and in particular to a cross-platform simulated IoT device security analysis system and method. Background Art

[0002] With the advent of the IoT era, IoT terminal devices have been rapidly developed and widely used. At the same time, security attacks on IoT devices are also increasing year by year. Therefore, security analysis and simulated vulnerability mining and verification of IoT devices will provide an important basis for the security construction of IoT device systems and even the entire IoT. By adopting automated security analysis methods for IoT devices, the efficiency of product security testing can be greatly improved, making it easier for developers to conduct risk assessment and security reinforcement of devices at the first time. Through simulation, technicians can quickly locate system security vulnerabilities and trigger logic, and fully ensure the effectiveness of product equipment security testing.

[0003] A patent document with publication number CN110768944A discloses an IOT device protection system and method based on FPGA technology. Through the configuration of FPGA hardware resources, external application end data traffic or IOT device data traffic is obtained; the obtained data traffic is preliminarily filtered; the filtered data traffic is analyzed, and the communication behavior is parsed and monitored, so as to achieve effective control of IOT device behavior and data traffic and real-time data traffic monitoring and analysis.

[0004] Regarding the above-mentioned related technologies, the inventor believes that IoT devices and malware run on various operating systems and CPU architectures at the same time. Existing tools do not support multi-system or multi-architecture analysis operations, which requires technicians to spend a lot of time and energy to build various virtual environments, greatly reducing the analysis efficiency. In addition, most security analysis tools are completely separated from device firmware simulation technology, which leads to a completely fragmented analysis experience for IoT devices and malicious code. Therefore, it is necessary to propose a technical solution to improve the above technical problems. Summary of the invention

[0005] In view of the defects in the prior art, the purpose of the present invention is to provide a cross-platform simulated IoT device security analysis system and method.

[0006] A cross-platform simulated IoT device security analysis system provided by the present invention includes analysis routes based on different system platform architectures. The analysis routes are divided into embedded Linux system environment analysis simulation and RTOS system environment analysis simulation according to specific functions. For the input device firmware system architecture, the system automatically selects the analysis route and performs security analysis and dynamic simulation on it.

[0007] The embedded Linux system environment analysis simulation completes the unpacking of user input device firmware, system architecture analysis, static security analysis, analysis result display, automatic simulation based on the analysis results, and vulnerability mining and verification;

[0008] The RTOS system environment analysis simulation completes the unpacking of user input device firmware, system architecture analysis, base address relocation, function semantic recovery, analysis result display, fragmented simulation based on the analysis results, and vulnerability mining and verification.

[0009] Preferably, the Linux system environment analysis route includes a user interaction module, a firmware unpacking module, a static security analysis module, an analysis result display module and an automated simulation module;

[0010] The user interaction module provides an input device firmware interface;

[0011] The firmware unpacking and analysis module unpacks and analyzes the firmware of the user input device, and automatically identifies the type of embedded system to which it belongs;

[0012] The static security analysis module takes the unpacked Linux embedded device file system as input, uses the static analysis method of shared keyword-aware taint detection, tracks user input between the front-end and back-end, and automatically analyzes the security vulnerabilities in the system;

[0013] The analysis result display module visualizes the system security vulnerabilities analyzed in the static security analysis module, including the involved dangerous binary files, dangerous functions and parameters, and dangerous function execution paths;

[0014] Based on the analysis results, the automated simulation module automatically selects two modes, user mode or full system mode, to simulate the dangerous binary files involved, restore their services or systems, and perform vulnerability mining and verification.

[0015] Preferably, the RTOS system environment analysis route includes a user interaction module, a firmware unpacking analysis module, a base address relocation module, a function semantic recovery module, an analysis result display module and a fragmentation simulation module;

[0016] The user interaction module provides an input device firmware interface;

[0017] The firmware unpacking and analysis module unpacks and analyzes the firmware of the user input device, and automatically identifies the type of embedded system to which it belongs;

[0018] The base address relocation module takes the binary file in the unpacked device firmware file system as input and automatically relocates its loading base address;

[0019] The function semantic recovery module locates and semantically recovers the tainted function contained in the resolved binary file according to its base address;

[0020] The analysis result display module visualizes the execution result of the function semantic recovery module, including the base address of the binary file that can be parsed, the location and type of the tainted function contained in such binary file;

[0021] The fragmentation simulation module performs fragmentation simulation execution on the relevant program fragments in the binary file involved based on the base address relocation result and the function semantic recovery result, restores part of its services, and performs vulnerability mining and verification.

[0022] The present invention also provides a cross-platform simulated IoT device security analysis method, the method applies the cross-platform simulated IoT device security analysis system mentioned above, and the method comprises the following steps:

[0023] Step S1: Obtain the IoT device firmware input by the user and automatically unpack it; use the binwalk open source tool set to retrieve the unpacking log keyword information after unpacking to automatically identify the corresponding embedded operating system type;

[0024] Step S2: the analysis interface automatically matches the corresponding system environment analysis route according to the identified embedded system type;

[0025] Step S3: Based on the static analysis results, the binary files with problems are automatically located.

[0026] Preferably, step S1 comprises the following steps:

[0027] Step S1.1: If it is a Linux system environment, perform static security analysis on its file system, and automatically select user state or full system state simulation based on the analysis results to reproduce the environment with security issues for vulnerability mining and verification;

[0028] Step S1.2: If it is an RTOS system environment, relocate the base address of its binary file, restore the function semantics of the relocated binary file, locate the program fragments with security risks, and use the fragmentation simulation method to restore part of its service environment for vulnerability mining and verification.

[0029] Preferably, the step S1.1 comprises the following steps:

[0030] Step S1.1.1: Identify front-end files and back-end programs from the unpacked firmware file system based on file types, where HTML, JavaScript, and XML types are front-end files, and executable binary files and libraries are back-end files;

[0031] Step 1.1.2: Analyze the front-end files and use typical patterns to extract potential keywords input by users;

[0032] Step S1.1.3: Identify the boundary binary files in the backend, and the backend calls different processing functions according to the user input keywords;

[0033] Step S1.1.4: Locate user input points by passing shared keywords between programs; use sensitive input taint analysis to track the use of untrusted data.

[0034] Preferably, in the step S1.2, the base address of the binary file is relocated in the RTOS system environment, and the memory address of the nearby code is derived by using the memory address jump table of the switch case statement block in the C language, and the loading address of the file is obtained by using the offset of the code and the memory address.

[0035] Preferably, the function semantics recovery of binary files in the RTOS system environment is implemented based on the CFGFast code block scanning in Angr, adding the recognition of the switch statement jump table, and recovering the control flow by converting the code into an intermediate language and retrieving the jump information of the basic block.

[0036] Preferably, the fragmentation simulation method in the RTOS system environment uses the Unicorn engine to simulate the execution of program fragments that have been located to have security issues, and restore part of its service environment.

[0037] Preferably, step S3 comprises the following steps:

[0038] Step S3.1: By default, the full system mode based on the FirmAE framework is used to simulate the device firmware. If successful, it proceeds to step S3.4. If it fails, it proceeds to step S3.2.

[0039] Step S3.2: Use auxiliary scripts to automatically retrieve specific service file information in the FirmAE simulation log file, and locate the problematic binary file in combination with the static security analysis results;

[0040] Step S3.3: For the located problematic binary files, emulate such specific binary files using Qemu user mode;

[0041] Step S3.4: Verify whether the simulation is successful by checking the port opening or the web front-end page, and perform vulnerability mining and verification on the IoT device in the current successfully simulated environment.

[0042] Compared with the prior art, the present invention has the following beneficial effects:

[0043] 1. The present invention provides a cross-platform simulated IoT device security analysis system and method, which can be used to analyze and simulate IoT device security issues on different platforms and architectures;

[0044] 2. The present invention unpacks the input device firmware, analyzes its architecture, and adopts a static analysis method of shared keyword-aware taint detection for Linux-based embedded systems to track user input between the front-end and the back-end, visualize the possible security vulnerabilities of the output system, and based on the output results, the system automatically selects the full system mode or the user mode to dynamically simulate the security vulnerability binary files involved;

[0045] 3. The present invention uses base address relocation and function semantic recovery methods to locate the security vulnerabilities of output files for RTOS-based embedded systems, and performs fragmentation simulation on the binary files involved based on the output results;

[0046] 4. Finally, the present invention mines and verifies the corresponding vulnerabilities in different system and architecture environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0048] Figure 1 This is a structural diagram of the IoT device security analysis system simulated across platforms of the present invention;

[0049] Figure 2 This is a flow chart of the IoT device security analysis method for cross-platform simulation of the present invention. DETAILED DESCRIPTION

[0050] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0051] The present invention proposes a cross-platform simulated IoT device security analysis system and method, which ensures that automated security analysis can be performed on different types of IoT devices with multiple systems and multiple architectures, and can simulate the security vulnerability environment on this basis, thereby improving the efficiency and accuracy of IoT device vulnerability mining.

[0052] The present invention provides a structure diagram of a cross-platform simulated IoT device security analysis system. Figure 1The cross-platform simulated IoT device security analysis system of the present invention is composed of analysis routes based on different system platform architectures. The analysis routes can be divided into two categories according to specific functions: Linux system environment analysis simulation and RTOS system environment analysis simulation. For the input device firmware system architecture, the system automatically selects the analysis route and performs security analysis and dynamic simulation on it.

[0053] The Linux system environment analysis route in the cross-platform simulated IoT device security analysis system includes: a user interaction module that provides an input device firmware interface; a firmware unpacking analysis module that unpacks and analyzes the user input device firmware and automatically identifies the type of embedded system to which it belongs; a static security analysis module that takes the unpacked Linux embedded device file system as input, uses a static analysis method of shared keyword-aware taint detection to track user input between the front-end and back-end, and automatically parses possible security vulnerabilities in the system; an analysis result display module that visualizes the system security vulnerabilities parsed in the static security analysis module, including the involved dangerous binary files, dangerous functions and parameters, dangerous function execution paths, etc.; an automated simulation module that automatically selects user mode or full system mode to simulate the involved dangerous binary files based on the analysis results, restores their services or systems, and then performs vulnerability mining and verification on them.

[0054] The RTOS system environment analysis route in the cross-platform simulated IoT device security analysis system includes: a user interaction module that provides an input device firmware interface; a firmware unpacking analysis module that unpacks and analyzes the user input device firmware and automatically identifies the type of embedded system to which it belongs; a base address relocation module that takes the binary file in the unpacked device firmware file system as input and automatically relocates its loading base address; a function semantic recovery module that locates and semantically recovers the tainted functions contained in the parsed binary file based on its base address; an analysis result display module that visualizes the execution results of the function semantic recovery module, including the resolvable binary file base address, the location and type of tainted functions contained in such binary files, etc.; a fragmentation simulation module that performs fragmented simulation execution on the relevant program fragments in the binary file involved based on the base address relocation results and function semantic recovery results, recovers some of its services, and then conducts vulnerability mining and verification on it.

[0055] The present invention also provides a flowchart of a cross-platform simulated IoT device security analysis method as shown in Figure 2 The method comprises the following steps:

[0056] Step S1: Obtain the IoT device firmware input by the user and automatically unpack it; use the binwalk open source toolset to retrieve the unpacking log keyword information after unpacking to automatically identify the corresponding embedded operating system type.

[0057] Step S2: The analysis interface automatically matches the corresponding system environment analysis route according to the identified embedded system type.

[0058] If the firmware is identified as Linux, the unpacked file system is used as input for static security analysis using the SaTC analysis tool. The analysis process of this tool is as follows:

[0059] Step 1: From the unpacked firmware file system, identify the front-end files and back-end programs based on the file type, where HTML, JavaScript, and XML types are usually front-end files, while executable binaries and libraries are back-end files.

[0060] Step 2: Analyze the front-end files and use typical patterns to extract potential keywords entered by users.

[0061] Step 3: Identify the boundary binary files in the backend, and the backend calls different processing functions based on the user input keywords.

[0062] Step 4: From these functions, locate the user input point by passing shared keywords between programs.

[0063] Step 5: Finally, use sensitive input taint analysis to track the use of untrusted data.

[0064] If it is identified that the system environment corresponding to the firmware is RTOS, the binary file in the unpacked file system is used as input, and its corresponding loading base address is first determined, and a base address relocation method based on jump table positioning is adopted. This method is mainly implemented in two ways.

[0065] Method 1: Check the distance between multiple cases in the jump table, and use the absolute address and file offset of the case in the jump table to relocate the base address. Assume that the four non-repeated addresses obtained from the jump table are: a1, a2, a3, a4, and the distances between adjacent cases are: d1 = a2-a1, d2 = a3-a2, d3 = a4-a3. Examine the distance between each case and find a distance different from the others. Here, let's assume that d1≠d2 and d1≠d3, and then check the jump table to get the file offset of the case corresponding to a1 as addr. Then the base address is relocated to: new_addr = a1-addr, where new_addr is the relocated base address.

[0066] Method 2: The code near the jump table can be used to deduce the location where the default statement jumps and the offset of the default code, from the relocation base address. Assuming that the code near the jump table finds the memory location where the default case is located at m, and the file offset of the default code is p, then the code at the beginning of the file is mapped to the memory m1=mp, that is, the loading base address of the file is m1.

[0067] In the RTOS system environment, after the base address of the file has been relocated and analyzed, the semantic recovery module is implemented using code block scanning based on CFGFast in Angr. Preferably, the recognition of the switch statement jump table is added on the basis of the original function, and the control flow is recovered by converting the code into an intermediate language and then retrieving the jump information of the basic block.

[0068] In this embodiment, binary files are analyzed in the RTOS system environment, and the files are selected in turn and sorted from large to small according to the space they occupy. Due to the characteristics of the RTOS system itself, the main services are usually located in such larger binary files. When the base address is successfully located, the binary files ranked later will no longer be analyzed and processed.

[0069] Step S3: For the Linux system environment analysis route, based on the static analysis results, the problematic binary files will be automatically located.

[0070] The process of automated simulation in the Linux system environment is as follows:

[0071] Step S3.1: By default, the full system mode based on the FirmAE framework is used to simulate the device firmware. If successful, proceed to step S3.4; if unsuccessful, proceed to step S3.2.

[0072] Step S3.2: Use auxiliary scripts to automatically retrieve specific service file information in the FirmAE simulation log file, and locate the problematic binary file in combination with the static security analysis results.

[0073] Step S3.3: For the located problematic binary files, use Qemu user mode to simulate such specific binary files.

[0074] Step S3.4: Verify whether the simulation is successful by checking the port opening or the web front-end page, and perform vulnerability mining and verification on the IoT device in the current successfully simulated environment.

[0075] In the Linux environment, user mode or full system mode simulation is automatically selected. By default, the original device firmware is simulated in full system mode. The success of the system simulation is verified by checking the port opening or the Web front-end page. If successful, the IoT device can be mined and verified for vulnerabilities in the current environment. If it fails, the full system mode simulation log is retrieved, and the problematic binary file is located in combination with the static security analysis results. Then, the system switches to user mode to simulate such specific binary files, and the specific services of the IoT device are mined and verified for vulnerabilities in the current environment.

[0076] For the RTOS system environment analysis route, based on the base address relocation and function semantic recovery methods, the location and information of the tainted function are automatically located, and the Unicorn engine is used to simulate the execution of the program fragments with security issues that have been located, so as to restore part of its service environment, so as to achieve the purpose of vulnerability mining and verification of binary program files in the RTOS system environment.

[0077] In this embodiment, the Unicorn engine is implemented based on Qemu, which is scalable in the actual simulation process and supports multiple architectures, including Arm, Arm64, Mips, etc., and has an independent and concise API. Due to its characteristics of simulating code execution rather than actually requiring the CPU to complete the operation, it has a low load on the system operation and can be executed concurrently by multiple threads, greatly improving the efficiency of vulnerability mining and verification.

[0078] The present invention provides a cross-platform simulated IoT device security analysis system and method, which can be used to analyze and simulate IoT device security issues on different platforms and architectures; unpack the input device firmware, parse its architecture, and use a static analysis method of shared keyword-aware taint detection for Linux-based embedded systems to track user input between the front-end and back-end, visualize the security vulnerabilities that may exist in the output system, and based on the output results, the system automatically selects the full system mode or user mode to dynamically simulate the security vulnerability binary files involved.

[0079] For an embedded system based on RTOS, the present invention adopts the methods of base address relocation and function semantic recovery to locate the security vulnerabilities of output files, and performs fragmented simulation on the binary files involved based on the output results; finally, the corresponding vulnerabilities are mined and verified under different system and architecture environments.

[0080] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0081] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A cross-platform simulated IoT device security analysis system, It is characterized in that It includes analysis routes based on different system platform architectures. The analysis routes are divided into embedded Linux system environment analysis and simulation and RTOS system environment analysis and simulation according to specific functions. For the input device firmware system architecture, the system automatically selects the analysis route and performs security analysis and dynamic simulation on it. The embedded Linux system environment analysis simulation completes the unpacking of user input device firmware, system architecture analysis, static security analysis, analysis result display, automatic simulation based on the analysis results, and vulnerability mining and verification; The RTOS system environment analysis simulation completes the unpacking of user input device firmware, system architecture analysis, base address relocation, function semantic recovery, analysis result display, fragmented simulation based on the analysis results, and vulnerability mining and verification.

2. The cross-platform simulated IoT device security analysis system according to claim 1, It is characterized in that The Linux system environment analysis route includes a user interaction module, a firmware unpacking module, a static security analysis module, an analysis result display module and an automated simulation module; The user interaction module provides an input device firmware interface; The firmware unpacking and analysis module unpacks and analyzes the firmware of the user input device, and automatically identifies the type of embedded system to which it belongs; The static security analysis module takes the unpacked Linux embedded device file system as input, uses the static analysis method of shared keyword-aware taint detection, tracks user input between the front-end and back-end, and automatically analyzes the security vulnerabilities in the system; The analysis result display module visualizes the system security vulnerabilities analyzed in the static security analysis module, including the involved dangerous binary files, dangerous functions and parameters, and dangerous function execution paths; Based on the analysis results, the automated simulation module automatically selects two modes, user mode or full system mode, to simulate the dangerous binary files involved, restore their services or systems, and perform vulnerability mining and verification.

3. The cross-platform simulated IoT device security analysis system according to claim 1, It is characterized in that The RTOS system environment analysis route includes a user interaction module, a firmware unpacking analysis module, a base address relocation module, a function semantic recovery module, an analysis result display module and a fragmentation simulation module; The user interaction module provides an input device firmware interface; The firmware unpacking and analysis module unpacks and analyzes the firmware of the user input device, and automatically identifies the type of embedded system to which it belongs; The base address relocation module takes the binary file in the unpacked device firmware file system as input and automatically relocates its loading base address; The function semantic recovery module locates and semantically recovers the tainted function contained in the resolved binary file according to its base address; The analysis result display module visualizes the execution result of the function semantic recovery module, including the base address of the binary file that can be parsed, the location and type of the tainted function contained in such binary file; The fragmentation simulation module performs fragmentation simulation execution on the relevant program fragments in the binary file involved based on the base address relocation result and the function semantic recovery result, restores part of its services, and performs vulnerability mining and verification.

4. A cross-platform simulation method for IoT device security analysis, It is characterized in that The method applies the cross-platform simulated IoT device security analysis system according to any one of claims 1 to 3, and the method comprises the following steps: Step S1: Obtain the IoT device firmware input by the user and automatically unpack it; use the binwalk open source tool set to retrieve the unpacking log keyword information after unpacking to automatically identify the corresponding embedded operating system type; Step S2: the analysis interface automatically matches the corresponding system environment analysis route according to the identified embedded system type; Step S3: Based on the static analysis results, the binary files with problems are automatically located.

5. According to the cross-platform simulated IoT device security analysis method of claim 4, It is characterized in that The step S1 comprises the following steps: Step S1.1: If it is a Linux system environment, perform static security analysis on its file system, and automatically select user state or full system state simulation based on the analysis results to reproduce the environment with security issues for vulnerability mining and verification; Step S1.2: If it is an RTOS system environment, relocate the base address of its binary file, restore the function semantics of the relocated binary file, locate the program fragments with security risks, and use the fragmentation simulation method to restore part of its service environment for vulnerability mining and verification.

6. According to the cross-platform simulated IoT device security analysis method of claim 5, It is characterized in that The step S1.1 comprises the following steps: Step S1.1.1: Identify front-end files and back-end programs from the unpacked firmware file system based on file types, where HTML, JavaScript, and XML types are front-end files, and executable binary files and libraries are back-end files; Step 1.1.2: Analyze the front-end files and use typical patterns to extract potential keywords input by users; Step S1.1.3: Identify the boundary binary files in the backend, and the backend calls different processing functions according to the user input keywords; Step S1.1.4: Locate the user input point by transferring shared keywords between programs; Use sensitive input taint analysis to track the use of untrusted data.

7. The cross-platform simulated IoT device security analysis method according to claim 5, It is characterized in that In the step S1.2, the base address of the binary file is relocated in the RTOS system environment, and the memory address of the nearby code is derived by using the memory address jump table of the switch case statement block in the C language, and the loading address of the file is obtained by using the offset of the code and the memory address.

8. The cross-platform simulated IoT device security analysis method according to claim 4, It is characterized in that The function semantics recovery of binary files in the RTOS system environment is implemented based on the scanning of CGFast code blocks in Angr, and recognition of the jump table of switch statements is added. The control flow is recovered by converting the code into an intermediate language and retrieving the jump information of the basic block.

9. The IoT device security analysis method for cross-platform simulation according to claim 4, It is characterized in that The fragmented simulation method in the RTOS system environment uses the Unicorn engine to simulate and execute program fragments that have been located to have security issues, and restore part of its service environment.

10. The cross-platform simulated IoT device security analysis method according to claim 4, It is characterized in that The step S3 comprises the following steps: Step S3.1: By default, the full system mode based on the FirmAE framework is used to simulate the device firmware. If successful, it proceeds to step S3.

4. If it fails, it proceeds to step S3.

2. Step S3.2: Use auxiliary scripts to automatically retrieve specific service file information in the FirmAE simulation log file, and locate the problematic binary file in combination with the static security analysis results; Step S3.3: For the located problematic binary files, emulate such specific binary files using Qemu user mode; Step S3.4: Verify whether the simulation is successful by checking the port opening or the web front-end page, and perform vulnerability mining and verification on the IoT device in the current successfully simulated environment.

Images