Vulnerability detection system and method for real-time operating system devices

Abstract

This invention provides a vulnerability detection system and method for real-time operating system devices. Combining binary semantic analysis of device firmware, this method tracks the flow of user data input and processing during device operation, based on the restoration of semantic information about key functions of external services within the firmware. This allows for data flow reconstruction of each task within the firmware, and the pruning of firmware code based on data flow dependencies. Finally, instruction simulation and vulnerability detection are performed within the pruned code slices. This method avoids complex and inefficient full-system device simulation, directly slicing the various key service codes running on the device and conducting targeted testing, significantly improving testing efficiency and the number of actual vulnerabilities discovered.

Description

Technical Field

[0001] The present invention relates to the technical field of computer network space security, and in particular to a vulnerability detection system and method for real-time operating system devices. Background Art

[0002] Real-time operating systems (RTOS) have become a major category of embedded systems. They are widely used to support tasks requiring real-time responses, from small devices like printers, switches, and routers to large industrial control equipment. For a long time, RTOSs were often run in specialized environments isolated from attackers, and their security was often overlooked. However, with the rapid adoption of IoT devices, a large number of RTOS-enabled devices have become exposed to public networks. Due to the lack of effective security mechanisms, these RTOS devices are extremely vulnerable to various attacks.

[0003] Patent document CN112182588A discloses a threat intelligence-based operating system vulnerability analysis and detection method and system. The method of the present invention includes updating a security vulnerability information database based on security vulnerability information provided by a vulnerability information publishing platform; combining the product and version information installed and used by the detected operating system, and comparing it with the security vulnerability information recorded in the security vulnerability information database to analyze the security risks of the detected operating system.

[0004] Regarding the aforementioned related technologies, the inventors believe that the monolithic design of real-time operating systems (RTOSs), which often combine the operating system kernel and various task services into a single executable file, often results in insufficient efficiency and analytical capabilities when analyzing security issues in RTOS devices. Therefore, a technical solution is needed to address these technical issues. Summary of the Invention

[0005] In view of the defects in the prior art, the purpose of the present invention is to provide a vulnerability detection system and method for real-time operating system devices.

[0006] According to the present invention, a vulnerability detection system for real-time operating system devices includes a basic information extraction module, a static analysis module and a dynamic analysis module;

[0007] The basic information extraction module performs preliminary analysis on the real-time operating system device firmware and separates and extracts key data, including extraction of the device's operating environment, static data extraction, and code data extraction;

[0008] The static analysis module parses the code data of the real-time operating system device, recovers the function semantics therein, and performs data flow dependency analysis and extraction on the key codes of the external services;

[0009] The dynamic analysis module simulates execution and fuzz testing of the extracted key service codes, and analyzes and verifies potential security issues discovered.

[0010] Preferably, the basic information extraction module includes operating environment extraction, static data extraction and code data extraction;

[0011] The runtime extraction uses statistical methods to analyze the device code contained in the firmware to obtain the CPU architecture information of the device; the absolute address reference information contained in the data reference instructions in the code is used to infer the actual loading base address of the image of the device at runtime;

[0012] The static data extraction refers to pattern matching and extraction of HTML, JS, XML code data in the firmware and configuration file data by visible character extraction and file format feature regular matching, and syntax tree parsing of the extracted code data to obtain the name feature string of the specific service parameter;

[0013] The code data extraction refers to parsing the corresponding architecture bytecode contained in the firmware after determining the CPU architecture information and judging whether it conforms to the code data logic, and then circumventing and extracting the actual code data running on the real-time operating system device.

[0014] Preferably, the static analysis module includes function semantic analysis, risk data flow analysis and risk code extraction;

[0015] The function semantic analysis includes a method of introducing function semantics based on static data recovery data and a method of restoring security risk function semantics based on simulated execution, statically scanning the code data, extracting functions in the code and analyzing the semantic information expressed by the functions;

[0016] Risk data flow analysis refers to the process of analyzing the impact of data replication, assignment, interception, and transformation operations on other data variables for service data input introduced by the data introduction function, and extracting the affected variable set and corresponding code snippet set from the code data;

[0017] The risk code extraction refers to the process of separating and extracting code fragments related to the risk data flow from the original firmware code data, excluding the influence of other codes that are not related to the current risk data flow.

[0018] Preferably, the dynamic analysis module includes simulation execution, fuzz testing and security analysis verification;

[0019] The simulation execution refers to the process of simulating the code and data of the device runtime using the Unicorn simulation framework based on the CPU architecture information and basic operating environment information determined by extracting the basic information of the firmware;

[0020] Fuzz testing refers to state simulation based on simulated execution, accessing automated service data generation and simulated execution program state and execution state detection at the upper layer, and automated large-scale analysis of the impact of different data inputs on the program, locating potential security risks in real-time operating system devices and providing verification input that can trigger problems;

[0021] The security analysis verification refers to the process of applying symbolic execution technology to recover the code information lost in risky code extraction for the security risks and corresponding inputs discovered by fuzz testing, and ultimately confirming whether the corresponding security risks can be triggered in the actual code data.

[0022] Preferably, whether a specific function in the firmware code is related to obtaining service parameters is determined by parsing the parameter names in the static resource file and comparing them with corresponding parameter references of the same name in the code.

[0023] Preferably, the functions are functions that can cause memory corruption, including memory copy, memory move, and format string function functions.

[0024] Preferably, the extraction of code snippets includes code extraction between functions and code extraction within a function.

[0025] Preferably, code extraction between functions is completed by analyzing the program slices of the data flow graph, and for the security risk function calls that can ultimately be affected by specific input parameters, a function call graph from the data input position to all calling security risk function positions is constructed, and the function call graph is extracted from the code data.

[0026] Preferably, code extraction within a function is completed by analyzing and trimming the code blocks within the function. For the data dependency process of a specific input parameter within the function, there is a corresponding code block. By modifying the jump instructions between the code blocks to jump to the code blocks on the data dependency path, the execution of irrelevant code blocks is shielded to complete the code trimming and extraction within the function; for specific data, a trimmed firmware code snippet data is obtained.

[0027] The present invention also provides a vulnerability detection method for real-time operating system devices, which uses the vulnerability detection system for real-time operating system devices described above, and comprises the following steps:

[0028] Step S1: Obtain device firmware through official website download or hardware extraction;

[0029] Step S2: decompress the firmware and determine the device image based on the file size and format;

[0030] Step S3: Parse the basic information of the firmware and use statistical methods to analyze the device code contained in the firmware to obtain the CPU architecture information of the device; use the absolute address reference information contained in the data reference instructions in the code to infer the actual loading base address of the image at runtime;

[0031] Step S4: Scan the image and extract key information, including static resource data and program code data;

[0032] Step S5: Parse the static resource data to extract the service front-end parameter names that may be used in the code, which are used for subsequent analysis and recovery of function semantic information related to device services;

[0033] Step S6: Use the determined CPU architecture and loading base address information to completely scan the program code data, extract all functions in the firmware code, call graph program control flow information between functions, and extract the completed code data information;

[0034] Step S7: Based on the analysis results of the static resource data and the execution flow characteristics of the function, the function that reads the service input data is marked as a data import function;

[0035] Step S8: Using a simulated execution method, based on the set function execution characteristics, functions that cause security issues such as memory corruption are marked as security risk functions;

[0036] Step S9: Perform data dependency analysis on the risk data introduced by the data introduction function to form a data flow graph for the input data in the program;

[0037] Step S10: Analyze and extract the corresponding code snippets for the data flow graph;

[0038] Step S11: simulate the execution of the code snippet and insert code at the location of the corresponding security risk function. When the program simulation reaches this location, check whether the program memory before and after the security risk function is executed is damaged. If so, report a risk alert; otherwise, exit the program simulation execution;

[0039] Step S12: Connect the above steps to the existing hybrid fuzz testing framework to perform automated risk data generation and program status detection, analyze the risk data input that causes memory corruption program security issues, and conduct large-scale automated inspections of code security risks in real-time operating systems.

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

[0041] 1. The present invention can effectively analyze potential security risks of embedded real-time operating system devices, solving problems that other solutions cannot analyze or have poor results;

[0042] 2. This invention innovatively proposes a series of semantic recovery methods, specifically designed to recover program semantics based on the characteristics of real-time operating systems, laying the foundation for subsequent accurate and efficient data flow extraction and analysis.

[0043] 3. The present invention conducts targeted extraction of code snippets involved in risky data flows of user data in system services, efficiently implements fuzz testing on specific code snippets, and discovers potential security risks in the code;

[0044] 4. The present invention can be further extended to other non-real-time operating system equipment environments to achieve a wider range of application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0046] Figure 1 The structure and flow chart of the vulnerability detection method for real-time operating system devices of the present invention. DETAILED DESCRIPTION

[0047] The present invention will be described in detail below with reference to specific embodiments. The following examples 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 skilled in the art, several changes and improvements can be made without departing from the scope of the present invention. These all fall within the scope of protection of the present invention.

[0048] To address the shortcomings of existing technologies, the present invention proposes a vulnerability detection system and method for real-time operating system devices. This method combines binary semantic analysis of device firmware. Based on the semantic information of key functions of external services in the firmware, it tracks the flow of user data input and processing during device operation, thereby reconstructing the data flow of each task in the firmware. The firmware code is then pruned based on data flow dependencies, and instruction simulation and vulnerability detection are finally performed within the pruned code slices. This method allows security researchers to avoid complex and inefficient full-system device simulations, directly slicing various key service codes running on the device and conducting targeted testing, thereby greatly improving testing efficiency and the number of actual vulnerabilities discovered.

[0049] The present invention provides a structure diagram of a vulnerability detection method for real-time operating system devices. Figure 1As shown. The vulnerability detection method for real-time operating system devices of the present invention is composed of multiple modules. The modules are divided into three categories according to their specific functions: basic information extraction module, static analysis module and dynamic analysis module. The modules exchange data through message channels to work together. The basic information extraction module parses the firmware of the real-time operating system device, extracts the message data required by each part and hands it over to the static analysis module for static analysis at the firmware code level. The static analysis extracts key code data by determining the risk data flow of key services and hands it over to the dynamic analysis module for input generation and vulnerability detection.

[0050] The modules in the vulnerability detection method for real-time operating system devices include:

[0051] The basic information extraction module performs preliminary analysis of the real-time operating system device firmware and separates and extracts key data, including the extraction of the device's operating environment, static data extraction, and code data extraction; the operating environment extraction uses statistical methods to analyze the device code contained in the firmware to obtain the device's CPU architecture information; the absolute address reference information contained in the data reference instructions in the code is used to infer the actual image loading base address of the device at runtime; static data extraction refers to pattern matching and extraction of HTML, JS, XML code data, and configuration file data in the firmware through visible character extraction and file format feature regular matching, and performs syntax tree parsing on the extracted code data to obtain the name feature string of specific service parameters; code data extraction refers to parsing the corresponding architecture bytecode contained in the firmware after determining the CPU architecture information and judging whether it conforms to the code data logic, thereby locating and extracting the actual code data running on the real-time operating system device.

[0052] The static analysis module parses the code data of the real-time operating system device, recovers the function semantics therein, and performs data flow dependency analysis and extraction on the key code of the external service; the processes included in the static analysis module are function semantic analysis, risk data flow analysis and risk code extraction. Function semantic analysis includes a method of recovering the function semantics of data introduction based on static data and a method of recovering the security risk function semantics based on simulated execution. It can statically scan the code data, extract functions in the code and analyze the semantic information expressed by the functions; risk data flow analysis refers to the process of analyzing the impact of service data input introduced by the data introduction function on other data variables through data copying, assignment, interception, and transformation operations, and extracting the affected variable set and the corresponding code snippet set from the code data; risk code extraction refers to the process of separating and extracting code snippets related to the risk data flow from the original firmware code data, which can exclude other code influences that are not related to the current risk data flow.

[0053] The dynamic analysis module simulates the execution and fuzz testing of the extracted key service codes, and analyzes and verifies the potential security issues found; simulated execution refers to the process of simulating the code and data of the device during operation using the Unicorn simulation framework based on the CPU architecture information, basic operating environment and other information determined by the extraction of basic firmware information; fuzz testing refers to the state simulation based on simulated execution, which accesses the automated service data generation and simulated execution program state and execution state detection at the upper layer, thereby automating the large-scale analysis of the impact of different data inputs on the program, and can locate potential security risks in real-time operating system devices and provide verification input that can trigger the problem; security analysis verification refers to the process of applying symbolic execution technology to recover the code information that may be lost in the risk code extraction for the security risks and corresponding inputs found by fuzz testing, and finally confirming whether the corresponding security risks can be triggered in the actual code data.

[0054] Regarding the method of using simulated execution to restore the semantics of security risk functions, security risk functions in this method generally refer to functions that can cause memory corruption, such as common memory copy, memory move, and format string functions. Representative functions include memcpy, strcpy, sprintf, etc. Based on this feature, the following analysis process can be performed on the function to be analyzed:

[0055] a) For certain security risk functions, such as memcpy, strcpy, and sprintf, prepare corresponding parameter sets. This includes the specific changes to these parameter sets after the function executes. For example, for the memory copy function memcpy(dst, src, len), the data in the source src parameter before the copy will create a copy of the specified length at the destination address dst after the copy, based on the copy length len. This characteristic can be used as a criterion for determining whether the function is a memcpy function. Therefore, setting the parameter ("aaaaa","123",3) based on the execution characteristics of the memcpy function will result in the corresponding output being ("123aa","123",3). [("aaaaa","123",3), ("123aa","123",3)] is referred to as the characteristic parameter set for memcpy.

[0056] b) Completely extract the code of the function to be analyzed and the code of the sub-functions called by the function.

[0057] c) Based on the parameter groups prepared in a), arrange the relevant parameters for calling the function in sequence and try to simulate the execution of the function.

[0058] d) If the simulation execution of a function fails or times out, the function is deemed to be unable to determine the semantics and exits.

[0059] e) If the simulation is successfully executed, determine whether the parameters arranged after execution meet the expected output of the parameter group. If so, it is considered that the function expresses the semantics of the corresponding function and exit.

[0060] f) If the simulation is successfully executed, but the parameters after execution do not meet the expected output, the current set of characteristic parameters is considered to be unsuitable for the function, and the next set of characteristic parameter groups is tried.

[0061] g) Repeat c), d), e), and f) until the analysis of the function is exited or all characteristic parameter groups are traversed, and try to restore the semantics of all functions in the firmware code one by one according to this process.

[0062] Regarding data dependency analysis methods, service operation is often accompanied by data transmission and replication. After the service data is read in through the data import function, it is often affected by the specific logic of the program during execution and affects the values of multiple other variables. The data affected by the input data will further iteratively affect other data. Other variables affected by the input data and all variables affected by the iteration are called dependent variables, and the process of data iteration is called data dependency. Therefore, the data dependency analysis method is the process of iteratively summarizing all dependent variables for specific service input data. By analyzing the data dependency process, the data flow graph corresponding to the input data is obtained, that is, a graph consisting of the set of all variables that the specific input data can ultimately affect and the set of dependent paths.

[0063] The code snippet extraction method introduces a data flow diagram derived from data dependency analysis, extracting the path of the data-dependent process. This path actually has a one-to-one correspondence with the corresponding program code. Therefore, code unrelated to the data-dependent process of interest is removed from the firmware code, while code related to the data-dependent process is retained. This allows for further analysis of whether the input data of interest may cause security issues. Considering both efficiency and data targeting, code snippet extraction is divided into two levels: code extraction between functions and code extraction within functions.

[0064] Code extraction between functions is accomplished by analyzing program slices within the data flow graph. For security risk function calls that are ultimately affected by specific input parameters, a function call graph is constructed from the data input location to all locations where the security risk function is called. This function call graph is then extracted from the code data. Code extraction between functions is accomplished by modifying call instructions that call other functions no longer on the call graph from call to nop instructions, blocking calls to unrelated functions. Further code extraction is then performed within each function on the function call graph.

[0065] Code extraction within a function is accomplished by analyzing and trimming the code blocks within the function: for the data-dependent process of a specific input parameter within the function, there is a corresponding code block. By modifying the jump instructions between code blocks to jump to the code block on the data-dependent path, the execution of irrelevant code blocks is shielded to complete the code trimming and extraction within the function.

[0066] Finally, for specific data, a trimmed firmware code snippet is obtained. This code snippet can eliminate the impact of other data processing flows on security issue analysis, while focusing on the data processing flow and avoiding the simulation difficulties of the complex data reading and writing processes of embedded device systems.

[0067] The method for performing security analysis on simulated execution involves extracting the CPU architecture and loading base address information obtained through basic information extraction, loading the code snippet data into the Unicorn simulation framework and setting the corresponding data segment, and then having the framework simulate the execution of the assembly instructions in the firmware under the corresponding architecture starting from the specified code location. Through the framework's code instrumentation function, we can add an instrumentation stub at the first instruction after the security risk function of the firmware code is executed. In the instrumentation code, we check whether the return address value in the function stack frame is corrupted to determine whether a buffer overflow memory corruption vulnerability has occurred. Therefore, after the simulation framework loads the specified fuzz test input data, it starts to simulate the execution of the firmware code from the location where the data introduction function is called. When the security risk function is successfully executed, our instrumentation code is triggered to check whether a security vulnerability is triggered. If so, a warning is returned.

[0068] The preferred embodiment of the present invention provides a process for vulnerability detection method for real-time operating system devices Figure 1 The specific process of the method is as follows:

[0069] Step 1: Obtain the device firmware through official website download, hardware extraction, etc.

[0070] Step 2: Unzip the firmware and determine the device image based on file size, format, and other information.

[0071] Step 3: parse the basic information of the firmware, use statistical methods to analyze the device code contained in the firmware, and obtain the CPU architecture information of the device; use the absolute address reference information contained in the data reference instructions in the code to infer the actual loading base address of the image at runtime.

[0072] Step 4: Scan the image and extract key information, including:

[0073] Static resource data, such as HTML, JS, XML code data, and configuration file data.

[0074] Program code data, including real-time operating system kernel code and the service code running on it.

[0075] Step 5: Parse the static resource data and extract the service front-end parameter names that may be used in the code, which will be used for subsequent analysis and recovery of function semantic information related to device services.

[0076] Step 6: Use the determined CPU architecture and loading base address information to completely scan the program code data, extract all functions in the firmware code, call graphs between functions and other program control flow information, and extract the completed code data information.

[0077] Step 7: Based on the analysis results of the static resource data and the execution flow characteristics of the function, the function that reads the service input data is marked as a data import function.

[0078] In step eight, using a simulated execution method, based on the set function execution characteristics, functions that may cause security issues such as memory corruption are marked as security risk functions.

[0079] Step nine: perform data dependency analysis on the risk data introduced by the data introduction function to form a data flow diagram for the input data in the program.

[0080] Step 10: Analyze and extract the corresponding code snippets for the data flow graph.

[0081] Step 11: simulate the execution of the code snippet and insert code at the location of the corresponding security risk function. When the program simulation reaches this location, check whether the program memory before and after the execution of the security risk function is damaged. If so, report a risk alert, otherwise exit the program simulation execution.

[0082] Step 12: Connect the above steps to the existing hybrid fuzz testing framework to perform automated risk data generation and program status detection, thereby analyzing the risk data input that may cause program security issues such as memory corruption, and based on this, conduct large-scale automated inspections of code security risks in real-time operating systems.

[0083] Regarding the method of using static resource data to recover data import functions, services on real-time operating systems are similar to services on other operating systems. Their function execution often involves reading, processing, and possibly outputting service data. This data reading and processing often involves the use of data names (such as "username," "passwd," and so on). Data names can often be obtained through parameter names in static resource files. Therefore, by parsing the parameter names in the static resource files and comparing them with corresponding parameter references of the same name in the code, it is possible to determine whether a specific function in the firmware code is related to obtaining service parameters. Common sources for obtaining parameter names in static resource data include the action, name, and id attributes in HTML data, the name and value attributes in JavaScript data, the method names in XML data, and the configuration item names in configuration files. By extracting the parameter names, a set of characteristic strings can be obtained. If each call to a function is accompanied by a string from this set of characteristic strings as a call parameter and returns a data pointer, the function is considered related to data import and is marked as a data import function.

[0084] The present invention can effectively analyze potential security risks of embedded real-time operating system devices, solving problems that other solutions cannot analyze or have poor results; it innovatively proposes a series of semantic recovery methods, designs program semantic recovery methods based on the characteristics of real-time operating systems, and can lay the foundation for subsequent accurate and efficient data flow extraction and analysis; it conducts targeted extraction of code snippets involved in risky data flows of user data in system services, efficiently implements fuzz testing on specific code snippets and discovers potential security risks in the code; it can be further extended to other non-real-time operating system device environments to achieve larger application scenarios.

[0085] Those skilled in the art will appreciate that, in addition to implementing the system and its various devices, modules, and units provided by the present invention in purely computer-readable program code, it is entirely possible to implement the same functions of the system and its various devices, modules, and units provided by the present invention 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 a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; the devices, modules, and units for implementing various functions can also be considered as both software modules implementing the method and structures within the hardware component.

[0086] The above describes specific embodiments of the present invention. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art may make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. The embodiments of this application and the features in the embodiments may be combined with each other in any manner unless there is a conflict.

Claims

1. A vulnerability detection system for real-time operating system devices, characterized in that: Including basic information extraction module, static analysis module and dynamic analysis module; The basic information extraction module performs preliminary analysis on the real-time operating system device firmware and separates and extracts key data, including extraction of the device's operating environment, static data extraction, and code data extraction; The static analysis module parses the code data of the real-time operating system device, recovers the function semantics therein, and performs data flow dependency analysis and extraction on the key codes of the external services; The dynamic analysis module simulates execution and fuzz testing of the extracted key service codes, and analyzes and verifies potential security issues found; The static analysis module includes function semantic analysis, risk data flow analysis and risk code extraction; Risk data flow analysis refers to the process of analyzing the impact of data replication, assignment, interception, and transformation operations on other data variables for service data input introduced by the data introduction function, and extracting the affected variable set and corresponding code snippet set from the code data; The extraction of the code snippets includes code extraction between functions and code extraction within a function; Code extraction between functions is completed by analyzing the program slices of the data flow graph. For the security risk function calls that can ultimately be affected by specific input parameters, a function call graph from the data input location to all locations where security risk functions are called is constructed, and the function call graph is extracted from the code data.

2. The vulnerability detection system for real-time operating system devices according to claim 1, characterized in that: The basic information extraction module includes operating environment extraction, static data extraction and code data extraction; The operating environment extraction uses statistical methods to analyze the device code contained in the firmware to obtain the CPU architecture information of the device; Use the absolute address reference information contained in the data reference instructions in the code to infer the actual load base address of the image at runtime; The static data extraction refers to pattern matching and extraction of HTML, JS, XML code data in the firmware and configuration file data by visible character extraction and file format feature regular matching, and syntax tree parsing of the extracted code data to obtain the name feature string of the specific service parameter; The code data extraction refers to parsing the corresponding architecture bytecode contained in the firmware after determining the CPU architecture information and judging whether it conforms to the code data logic, and then circumventing and extracting the actual code data running on the real-time operating system device.

3. The vulnerability detection system for real-time operating system devices according to claim 1, characterized in that: The function semantic analysis includes a method of introducing function semantics based on static data recovery data and a method of restoring security risk function semantics based on simulated execution, statically scanning the code data, extracting functions in the code and analyzing the semantic information expressed by the functions; The risk code extraction refers to the process of separating and extracting code fragments related to the risk data flow from the original firmware code data, excluding the influence of other codes that are not related to the current risk data flow.

4. The vulnerability detection system for real-time operating system devices according to claim 1, characterized in that: The dynamic analysis module includes simulation execution, fuzz testing and security analysis verification; The simulation execution refers to the process of simulating the code and data of the device runtime using the Unicorn simulation framework based on the CPU architecture information and basic operating environment information determined by extracting the basic information of the firmware; Fuzz testing refers to state simulation based on simulated execution, accessing automated service data generation and simulated execution program state and execution state detection at the upper layer, and automated large-scale analysis of the impact of different data inputs on the program, locating potential security risks in real-time operating system devices and providing verification input that can trigger problems; The security analysis verification refers to the process of applying symbolic execution technology to recover the code information lost in risky code extraction for the security risks and corresponding inputs discovered by fuzz testing, and ultimately confirming whether the corresponding security risks can be triggered in the actual code data.

5. The vulnerability detection system for real-time operating system devices according to claim 3, characterized in that: By parsing the parameter names in the static resource file and comparing them with the corresponding parameter references of the same name in the code, it is determined whether a specific function in the firmware code is related to obtaining service parameters.

6. The vulnerability detection system for real-time operating system devices according to claim 3, characterized in that: The functions are some functions that can cause memory corruption, including memory copy, memory move, and format string function functions.

7. The vulnerability detection system for real-time operating system devices according to claim 1, characterized in that: Code extraction within a function is accomplished by analyzing and trimming the code blocks within the function. For the data-dependent process of a specific input parameter within the function, there is a corresponding code block. By modifying the jump instructions between code blocks to jump to the code blocks on the data-dependent path, the execution of irrelevant code blocks is shielded to complete code trimming and extraction within the function. For specific data, a trimmed firmware code snippet data is obtained.

8. A vulnerability detection method for real-time operating system devices, characterized in that: The method applies the vulnerability detection system for real-time operating system devices according to any one of claims 1 to 7, and the method comprises the following steps: Step S1: Obtain device firmware through official website download or hardware extraction; Step S2: decompress the firmware and determine the device image based on the file size and format; Step S3: Parse the basic information of the firmware and use statistical methods to analyze the device code contained in the firmware to obtain the CPU architecture information of the device; use the absolute address reference information contained in the data reference instructions in the code to infer the actual loading base address of the image at runtime; Step S4: Scan the image and extract key information, including static resource data and program code data; Step S5: Parse the static resource data to extract the service front-end parameter names that may be used in the code, which are used for subsequent analysis and recovery of function semantic information related to device services; Step S6: Use the determined CPU architecture and loading base address information to completely scan the program code data, extract all functions in the firmware code, call graph program control flow information between functions, and extract the completed code data information; Step S7: Based on the analysis results of the static resource data and the execution flow characteristics of the function, the function that reads the service input data is marked as a data import function; Step S8: Using a simulated execution method, based on the set function execution characteristics, functions that cause security issues such as memory corruption are marked as security risk functions; Step S9: Perform data dependency analysis on the risk data introduced by the data introduction function to form a data flow graph for the input data in the program; Step S10: Analyze and extract the corresponding code snippets for the data flow graph; Step S11: simulate the execution of the code snippet and insert code at the location of the corresponding security risk function. When the program simulation reaches this location, check whether the program memory before and after the security risk function is executed is damaged. If so, report a risk alert; otherwise, exit the program simulation execution; Step S12: Connect the above steps to the existing hybrid fuzz testing framework to perform automated risk data generation and program status detection, analyze the risk data input that causes memory corruption program security issues, and conduct large-scale automated inspections of code security risks in real-time operating systems.

Images