Fuzzing methods, apparatus and computer equipment for real-time operating systems

Abstract

This application relates to a fuzzing method, apparatus, computer device, storage medium, and computer program product for real-time operating systems. The method involves creating a simulator based on the real-time operating system to be tested, determining key test points, running the real-time operating system under test through the simulator, obtaining the memory state during the operation of the real-time operating system, executing a target test task based on the key test points, obtaining the execution results, and generating test results for the real-time operating system under test based on the memory state and execution results. Since this embodiment is a fuzzing test based on virtual hardware, i.e., a simulator, to perform full-system simulation of the real-time operating system under test, compared to traditional techniques that test the real-time operating system on real hardware, it can effectively reduce the testing difficulty and improve testing efficiency.

Description

Technical Field

[0001] This application relates to the field of system testing technology, and in particular to a fuzz testing method, apparatus, computer equipment, storage medium, and computer program product for a real-time operating system. Background Technology

[0002] With the development of IoT technology, various Real-Time Operating Systems (RTOS) have emerged. For example, many devices such as new energy vehicles, routers, switches, and printers run RTOS to handle various tasks requiring high real-time performance. Due to the trend of the Internet of Things, a large number of RTOSs have been intentionally or unintentionally exposed to the internet environment, making them accessible externally. However, their security has not been effectively tested, leading to frequent security incidents. The fact that various attacks targeting printers, switches, and new energy vehicles in recent years have all involved the security of RTOS demonstrates its harmfulness.

[0003] In traditional technologies, security testing of real-time operating systems and their various tasks in the industrial sector is primarily conducted on real hardware. This increases the difficulty of testing, as the hardware must be properly debugged to ensure full functionality before security testing. It also increases the difficulty of debugging, as the real-time running state of the program and the state when errors occur cannot be captured in real time, making it impossible to obtain the hardware (such as registers and memory) state and the program's call stack at any given moment. This makes debugging abnormal program behavior and business logic relatively difficult. Furthermore, this type of testing method is inefficient. Sending and receiving message data through special hardware communication channels (such as Bluetooth, WiFi, NFC (Near Field Communication)) is limited by the channel communication logic and data transmission capabilities. The pre-testing stages, such as establishing channel connections before testing the security of business logic, also consume a significant amount of testing time.

[0004] Therefore, traditional methods of testing real-time operating systems on real hardware are characterized by high testing difficulty and low efficiency. Summary of the Invention

[0005] Therefore, it is necessary to address the technical problems of high testing difficulty and low efficiency in testing real-time operating systems on real hardware by providing a fuzz testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product for real-time operating systems.

[0006] Firstly, this application provides a fuzzing method for a real-time operating system. The method includes:

[0007] Create a simulator based on the real-time operating system to be tested, and determine the key test points;

[0008] The real-time operating system under test is run through the simulator to obtain the memory status during the operation of the real-time operating system under test.

[0009] Execute the target test task based on the aforementioned key test points and obtain the execution results;

[0010] The test results of the real-time operating system under test are generated based on the memory state and the execution results.

[0011] In one embodiment, determining the key test points includes: identifying corresponding function information based on the real-time operating system to be tested; generating a function call relationship graph corresponding to the target test task based on the function information; determining the test start point and test end point of the target test task based on the function call relationship graph and preset test data; and using the test start point and the test end point as the key test points.

[0012] In one embodiment, the function information includes a function name and a function body; generating a function call graph corresponding to the target test task based on the function information includes: identifying various types of tasks based on the function name and function body, and determining a set of upper-level tasks based on the various types of tasks; identifying the function set of the target test task based on the function name and function body, and generating an upper-level call graph for each function in the function set using control flow analysis; and generating the function call graph corresponding to the target test task based on the upper-level call graph and the set of upper-level tasks.

[0013] In one embodiment, determining the start and end points of the target test task based on the function call graph and preset test data includes: locating the memory location where the test data is written and the function it belongs to by tracing, based on the function call graph and preset test data, and determining the located memory location and function as the test start point; identifying loop jump points and task exit points through the function call graph, and determining the test end point based on the loop jump points and the task exit points.

[0014] In one embodiment, the step of executing the target test task based on the test key points and obtaining the execution result includes: loading the test data generation and writing logic and fuzzing processing logic corresponding to the target test task at the test start point, and loading the fuzzing processing logic at the test end point; when the real-time operating system under test reaches the test start point, generating and filling the test data according to the generation and writing logic, and entering the fuzzing processing logic; when the real-time operating system under test reaches the test end point, executing the fuzzing processing logic and obtaining the execution result.

[0015] In one embodiment, the step of running the real-time operating system under test through the simulator and obtaining the memory state during the operation of the real-time operating system under test includes: obtaining a configured memory monitoring policy; running the memory monitoring policy during the operation of the real-time operating system under test in the simulator and obtaining the running results; and determining the memory state during the operation of the real-time operating system under test based on the running results.

[0016] In one embodiment, creating a simulator based on the real-time operating system to be tested includes: identifying corresponding function information and external devices used by the real-time operating system to be tested; determining the starting point of the real-time operating system to be tested and the load address of each program segment based on the function information; mapping the program segments to a pre-allocated first virtual memory space based on the load address of the program segments; initializing the pre-allocated second virtual memory space of the external device as a virtual device; and generating a simulator based on the load address of each program segment, the mapped first virtual memory space, the virtual device, and the starting point of the real-time operating system to be tested.

[0017] Secondly, this application also provides a fuzz testing device for a real-time operating system. The device includes:

[0018] The simulator creation module is used to create a simulator based on the real-time operating system to be tested and to determine the key points of the test.

[0019] The memory status acquisition module is used to obtain the memory status during the operation of the real-time operating system under test by running the simulator.

[0020] The test execution module is used to execute target test tasks based on the test key points and obtain execution results;

[0021] The test result generation module is used to generate test results for the real-time operating system under test based on the memory state and the execution results.

[0022] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method described in the first aspect above.

[0023] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the method described in the first aspect above.

[0024] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the method described in the first aspect above.

[0025] The aforementioned fuzzing method, apparatus, computer equipment, storage medium, and computer program product for real-time operating systems (RTOS) create a simulator based on the ROS under test, determine key test points, run the ROS under test through the simulator, obtain the memory state during the ROS's operation, execute target test tasks based on the key test points, obtain execution results, and generate test results for the ROS under test based on the memory state and execution results. Since this embodiment is a fuzzing test based on virtual hardware, i.e., a simulator, to perform full-system simulation of the ROS under test, it effectively reduces testing difficulty and improves testing efficiency compared to traditional techniques that test ROS on real hardware. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a fuzzing method for a real-time operating system in one embodiment.

[0027] Figure 2 This is a flowchart illustrating the steps of creating a simulator in one embodiment;

[0028] Figure 3 This is a flowchart illustrating the steps for determining key test points in one embodiment;

[0029] Figure 4 This is a flowchart illustrating the steps for obtaining memory status in one embodiment;

[0030] Figure 5 This is a flowchart illustrating the steps for obtaining execution results in one embodiment;

[0031] Figure 6 This is a structural block diagram of a fuzz testing device for a real-time operating system in one embodiment.

[0032] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0034] Traditional testing of real-time operating systems (RTOS) on real hardware is difficult and inefficient. Furthermore, unlike desktop systems like Windows, ROS often lack memory monitoring and anomaly detection logic, making it impossible to rely on system or hardware features for effective detection of memory anomalies and other vulnerabilities during dynamic testing. This reduces the effectiveness of current dynamic testing based on real devices.

[0035] Based on the above issues, current security analysis of real-time operating systems in industrial and academic research mainly relies on static code scanning or targeted analysis of local code. These methods lack the complete runtime context of the system and task code (different tasks share a large number of global variables during system runtime; simple static analysis cannot systematically initialize global variables or track how each task sets them), leading to a high false positive rate and affecting the accuracy of testing.

[0036] Based on this, this application provides a fuzz testing method for a real-time operating system. This embodiment uses the application of this method to a terminal as an example for illustration. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, as... Figure 1 As shown, the method may include the following steps:

[0037] Step 102: Create a simulator based on the real-time operating system to be tested and determine the key test points.

[0038] A real-time operating system (RTOS) is an operating system that can accept and process external events or data at a sufficiently fast speed. The results of this processing can then control the production process or provide a rapid response to the processing system within a specified timeframe. It can allocate all available resources to complete real-time tasks and control all real-time tasks to run in a coordinated manner, characterized by timely response and high reliability. An ROS under test refers to the ROS that will be tested. Typically, to ensure the performance of a ROS, a series of tests are conducted before it is deployed online.

[0039] An emulator can be a virtual hardware device that uses hardware virtualization technology to simulate the real-time operating system (RTOS) under test. By running the ROS under test through this virtual hardware, its memory access behavior, variable usage behavior, and other aspects can be monitored, thereby achieving the testing of the ROS. Key testing points are critical factors in the testing process that play a decisive role in the execution of the test flow. Specifically, key testing points can be the start point and the end point of the test.

[0040] In this embodiment, the terminal can simulate and create a simulator based on the source code of the real-time operating system under test or through reverse engineering, thereby obtaining virtual hardware for testing the real-time operating system. The terminal can also identify and determine key testing points based on the source code of the real-time operating system under test or through reverse engineering, thereby improving testing efficiency and accuracy.

[0041] Step 104: Run the real-time operating system under test through the simulator and obtain the memory status during the operation of the real-time operating system under test.

[0042] The memory status includes, but is not limited to, the memory access behavior and variable usage behavior during the operation of the real-time operating system under test. Specifically, after the terminal creates an emulator through the above steps, it can run the real-time operating system under test through the emulator and obtain the memory status during the operation of the real-time operating system under test. This allows for monitoring of the memory status of the real-time operating system under test, thereby overcoming the functional deficiency of traditional technologies that do not support the detection of the memory status of real-time operating systems.

[0043] Step 106: Execute the target test task based on the test key points and obtain the execution results.

[0044] The target test task refers to a test task designed to achieve a specific test objective. It embodies the test plan, methods, techniques, and strategies, and includes the test objective, test environment, input data, test steps, expected results, and test scripts. The execution result refers to the actual result obtained after executing the target test task. Typically, comparing the actual result with the expected result reveals whether the real-time operating system under test has any anomalies or problems. In this embodiment, the terminal can execute the target test task based on key test points and obtain the corresponding execution results.

[0045] Step 108: Generate test results for the real-time operating system under test based on memory status and execution results.

[0046] The test results can be evaluative results of the real-time operating system under test, output after running the system and executing the target test task. Specifically, the terminal can generate test results for the real-time operating system under test based on the memory status and execution results obtained above, thereby helping testers to discover and verify system anomalies or problems, and improving system performance.

[0047] In the aforementioned fuzzing method for real-time operating systems, the terminal creates a simulator based on the real-time operating system under test, determines key test points, runs the real-time operating system under test through the simulator, obtains the memory state during the operation of the real-time operating system under test, executes the target test task based on the key test points, obtains the execution results, and generates test results for the real-time operating system under test based on the memory state and execution results. Since this embodiment is based on virtual hardware, i.e., a simulator, to perform full-system fuzzing of the real-time operating system under test, compared to traditional techniques that test the real-time operating system on real hardware, it can effectively reduce testing difficulty and improve testing efficiency.

[0048] In one embodiment, such as Figure 2 As shown, in step 102, a simulator is created based on the real-time operating system to be tested, which may specifically include:

[0049] Step 202: Identify the corresponding function information and the external devices used based on the real-time operating system to be tested.

[0050] The function information includes, but is not limited to, the function names or function bodies in the real-time operating system under test. External devices refer to the external hardware devices that the interrupt triggering or handling logic of the real-time operating system under test depends on during its operation, such as clock interrupt devices.

[0051] In this embodiment, the terminal can identify the internal function information of the real-time operating system under test, as well as the external devices on which the system depends, based on the source code of the real-time operating system under test or through reverse engineering.

[0052] Step 204: Determine the starting point of the real-time operating system to be tested and the load address of each program segment based on the function information.

[0053] The program segments are defined based on the source code of the real-time operating system under test. The execution start point refers to the starting point at which the real-time operating system under test begins execution.

[0054] Specifically, the terminal can extract the starting point of execution from the real-time operating system under test based on the identified function information. Typically, firmware for real-time operating systems based on different architectures has corresponding methods for determining the starting point of execution. For example, the starting address of the `Reset_Handler` function can be determined as the starting point of the real-time operating system under test. Simultaneously, the terminal can also obtain the load addresses of different program segments (e.g., text segments) in the firmware of the real-time operating system under test, i.e., the placement addresses of the program segments and the offset addresses of the executable files in the storage medium.

[0055] Step 206: Map the program segment to the pre-allocated first virtual memory space according to the program segment's load address.

[0056] The first virtual memory space is a virtual memory space pre-allocated for program segments. In this embodiment, the terminal can allocate the first virtual memory space for a program segment based on its load address, and then map each different program segment to its corresponding virtual memory according to its load address, thereby realizing memory mapping for each program segment.

[0057] Step 208: Initialize the pre-allocated second virtual memory space of the external device as a virtual device.

[0058] The second virtual memory space is a virtual memory space pre-allocated for external devices. A virtual device is a software application corresponding to hardware. In this embodiment, for the external devices on which the real-time operating system under test depends, the terminal can initialize the corresponding second virtual memory space as a virtual device according to the requirements of each architecture. Thus, when the simulation execution involves the memory space corresponding to the virtual device, a corresponding interrupt will be triggered, and the processing logic of the preset value will be triggered to realize the function of the corresponding hardware.

[0059] Specifically, for the external devices that the real-time operating system under test depends on, targeted processing and simulation can be carried out according to the type of external device. While ensuring the normal operation of the system, the manual cost required to simulate the external device can be minimized, and the functional logic of the external device can be simulated as completely as possible.

[0060] For example, when a real-time operating system checks the status of an external device (such as determining whether a certain type of external device exists or is ready), the system's usage of the registers for this type of external device is characterized by continuously requesting values ​​for certain bits in the corresponding external device status register. If the constraints are not met, the loop continues until the external device status changes to a value that satisfies the constraints. In a real-world environment, these bits are set automatically when the external device completes initialization or exists, or by other systems sharing the external device. However, in a simulation, because it is difficult to perform these non-explicit state setting operations (such as when there are no corresponding instructions in the real-time operating system firmware) at precise nodes, the values ​​of the corresponding external device registers never change. If no action is taken, the system will be blocked in these operation loops. For this type of external device, the characteristics of the instruction sequence corresponding to its status checks can be analyzed, and a global search can be performed through static analysis of the firmware to find all similar operations. The values ​​that the status registers need to satisfy at each loop checkpoint can be extracted, and when the firmware reaches the corresponding location, these values ​​are filled into the status register of the corresponding external device to achieve virtual device initialization.

[0061] In some scenarios, for devices with relatively complex operational logic, simply simulating the system's commands to operate external devices cannot achieve the desired results. For example, operations on FlexSPI (a control interface) are not performed by firmware code but by the external device hardware when calling the API (Application Programming Interface). Furthermore, system operations on these external devices typically involve recording and maintaining state information. If only the behavior of the external device is simulated without maintaining its state information, system operations on the external device will fail due to a lack of historical operation records. Therefore, for such external devices, it is necessary to both simulate their behavior and maintain the state information after each operation. There are generally two approaches to simulating such external devices. The first is to directly simulate the underlying interface for operating the external device. For example, the FLEXSPI_TransferBlocking function (a blocking transfer function) of the FlexSPI peripheral can be used to perform erase and write operations on the FLASH device by reading its parameters. This approach establishes a behavior mapping layer between the API for operating the external device and the simulated external device, directly applying the results of the operations to the corresponding memory space and registers of the external device. The second method involves adding a corresponding basic external device to the framework of the first method, while adding status information maintenance and simulation of various MMIO (Memory-mapped I / O) operations for the external device. When the system firmware accesses the corresponding memory space, it triggers its MMIO operation, which simulates the status information and peripheral behavior.

[0062] In one scenario, for external devices that handle data transmission, such as FlexCAN (an embedded network architecture that extends the functionality of the CAN bus), directly simulating the system's operation command sequence will fail to trigger the corresponding network packet sending and other real data transmission operations, resulting in a lack of simulator functionality. To solve this problem, a corresponding real data stream channel (such as VCAN or other data channels) can be created and bound during the device initialization phase. When the virtual device invokes data send or receive commands, it triggers the operation of the real data channel, thereby forwarding the data through the real channel to more realistically simulate the functional logic of the system firmware.

[0063] Step 210: Generate a simulator based on the load address of each program segment, the mapped first virtual memory space, the virtual device, and the starting point of the real-time operating system to be tested.

[0064] Specifically, the terminal can simulate the CPU behavior and system interrupt functions of a real-time operating system, as well as the core logic of the system, based on the load address of each program segment, the mapped first virtual memory space, the virtual device, and the running start point of the real-time operating system to be tested, thereby generating a corresponding simulator.

[0065] In the above embodiments, the terminal identifies the corresponding function information and external devices used by the real-time operating system under test. Based on the function information, it determines the starting point of the real-time operating system under test and the load addresses of each program segment. Then, it maps the program segments to a pre-allocated first virtual memory space based on their load addresses. The pre-allocated second virtual memory space for the external devices is initialized as a virtual device. Finally, based on the load addresses of each program segment, the mapped first virtual memory space, the virtual devices, and the starting point of the real-time operating system under test, a simulator is generated. This allows for the construction of virtual hardware even without corresponding hardware support, saving testing costs and reducing testing difficulty.

[0066] In one embodiment, such as Figure 3 As shown, in step 102, the key test points are determined, which may specifically include:

[0067] Step 302: Identify the corresponding function information based on the real-time operating system to be tested.

[0068] The function information includes, but is not limited to, function names or function bodies in the real-time operating system under test. Specifically, the terminal can use reverse engineering to identify the corresponding function information from the binary program of the real-time operating system under test.

[0069] Step 304: Generate a function call relationship graph corresponding to the target test task based on the function information.

[0070] The function call graph is a tree diagram of functions obtained based on the call relationships between functions during the execution of the target test task. In this embodiment, the terminal can generate a function call graph corresponding to the target test task based on the identified function information.

[0071] Specifically, based on the identified function information, such as function name and function body, and the task-related logic interfaces in the system, the terminal can further identify various tasks. This identification can be tailored to the system firmware logic; for example, the real-time operating system under test might create tasks explicitly through methods like `createTask`. Then, based on the identified tasks, the upper-level task set, or `TaskSet`, is determined.

[0072] The terminal can also identify the function set of the target test task based on the identified function names and function bodies. For example, it can use a partial string matching method, such as matching strings like "CAN" or "CanIf". Since these strings are related to the function naming strategy of the SDK (Software Development Kit) or system firmware developers, the function set (FuncSet) related to the target test task can be identified. Then, a higher-level call relationship graph can be generated for each function in the function set using control flow analysis. The terminal can further generate a function call relationship graph corresponding to the target test task based on the obtained higher-level call relationship graph and the higher-level task set.

[0073] Step 306: Based on the function call relationship diagram and the preset test data, determine the test start point and test end point of the target test task.

[0074] The test data refers to the input data set in the target test task. Specifically, based on the function call relationship diagram and the test data, the corresponding data flow relationship diagram and the type structure of each variable and parameter in the test data (such as CAN (Controller Area Network), BLE (Bluetooth Low Energy), NFC (Near Field Communication), etc.) can be obtained. The test start point refers to the starting position when the test begins, and the test end point refers to the ending position when the test ends, that is, the position where the test exits.

[0075] In this embodiment, the terminal, based on the function call graph and preset test data, can locate the memory location where the test data was written before being passed to the corresponding processing function and the function TargetMsgLoc (target message location), such as the queue receiving function QueueReceive (this function is only used for illustrative purposes). The located memory location and the function are then determined as the test start point, i.e., the data receiving point where the test data is written via interrupt and passed to the target test task.

[0076] Furthermore, the terminal can also identify loop jump points and task exit points through the aforementioned function call relationship graph, and determine the test end point based on these points. Specifically, in the firmware of the real-time operating system under test, each persistent task typically jumps to a QueueReceive class function (i.e., the receive queue function) to wait for new messages after processing a message. In this embodiment, to avoid timeouts caused by intermediate abnormal frames exiting the current task or entering a suspended state, similar loop jump points (LoopLoc) and task exit points (ExitLoc) can be identified, and the identified LoopLoc and ExitLoc can be used as test end points. Therefore, if the task does not reach LoopLoc or reaches ExitLoc for a long time, it will actively exit the current test and record the corresponding test case.

[0077] Step 308: Designate the test start point and test end point as test critical points.

[0078] Specifically, the terminal can use the test start point and test end point determined above as test key points.

[0079] In the above embodiments, the terminal identifies the corresponding function information based on the real-time operating system under test, generates a function call relationship graph corresponding to the target test task based on the function information, and then determines the test start point and test end point of the target test task based on the function call relationship graph and preset test data, using the test start point and test end point as test key points. This enables effective selection of the test start point and test end point, thereby improving the efficiency of subsequent testing of the real-time operating system under test.

[0080] In one embodiment, such as Figure 4 As shown, in step 104, the real-time operating system under test is run through a simulator to obtain the memory state during the operation of the real-time operating system under test. Specifically, this may include:

[0081] Step 402: Obtain the configured memory monitoring policy.

[0082] The memory monitoring strategy is a strategy configured based on testing needs to monitor the memory access behavior and variable usage behavior of the real-time operating system under test. Because traditional real-time operating systems lack memory protection and security detection mechanisms, various memory errors cannot be monitored in real time during testing. Therefore, in this embodiment, the terminal can obtain the configured memory monitoring strategy; for example, it can configure a corresponding memory monitoring strategy, or it can obtain a pre-configured memory monitoring strategy. Then, when the real-time operating system under test is running, the system's memory behavior can be monitored based on the configured memory monitoring strategy.

[0083] Step 404: While the real-time operating system to be tested is running in the simulator, run the memory monitoring strategy and obtain the running results.

[0084] The results can be obtained after running the memory monitoring strategy. Specifically, to monitor the memory behavior of a real-time operating system, the terminal can run the memory monitoring strategy and obtain the results while the real-time operating system under test is running in the simulator.

[0085] Step 406: Determine the memory state during the operation of the real-time operating system under test based on the running results.

[0086] The memory status can include both normal and abnormal memory states. In this embodiment, the terminal can determine the memory status during the operation of the real-time operating system under test based on the results of the memory monitoring strategy.

[0087] Specifically, taking heap memory monitoring as an example, the main issue with heap memory is whether or not there are out-of-bounds read / write operations. Therefore, during memory allocation, the value of the register storing the parameters of the heap allocation function can be modified to ensure that the actual allocated heap block size is larger than the program's requirement. Then, a memory read / write hook mechanism is used to hook the read / write operations of the extra allocated memory. If this extra allocated memory is read or written during the operation of the real-time operating system under test, it indicates an out-of-bounds read / write problem, meaning the memory state is abnormal. Conversely, if this extra allocated memory is not read or written during the operation of the real-time operating system under test, it indicates that no out-of-bounds read / write operation has occurred, meaning the memory state is normal.

[0088] In one scenario, taking stack return address monitoring as an example, static analysis can be used to extract the address corresponding to the instruction that stores the return address on the stack in the real-time operating system under test. This address can then be hooked. If this hook is triggered, a read / write hook for the memory at the return address on the stack will be added. If a read operation is performed on this memory, it will be considered a read of the return address, a normal operation, and the hook for this memory can be canceled. If a write operation is performed on this memory, it will be considered an out-of-bounds read / write operation, resulting in an abnormal state.

[0089] In one scenario, taking stack variable monitoring as an example of a memory monitoring strategy, the determination can be made using the symbolic information of the firmware of the real-time operating system under test. The stack offsets of different variables are obtained through symbolic information. When a function enters, the address of that function's stack variable is added to the global list. Then, the memory operation function is checked. If the memory copy operation is not performed on a single stack variable object in the global list, it is considered an out-of-bounds operation, i.e., an abnormal state. If the memory copy operation is performed on a single stack variable object in the global list, it is considered normal. Furthermore, since a function may have more than one exit point, it can be chosen to remove the address of a stack variable object from the global list when entering a function if the address exceeds the top of the stack.

[0090] In one scenario, taking a global variable monitoring strategy as an example, since the memory address does not change as the program runs, it is only necessary to add global variables to the analysis list based on the results of static analysis. Then, the memory operation functions are checked. If the memory copy operation is not performed on a single global variable object in the global list, it is considered an out-of-bounds operation, i.e., an abnormal state. If the memory copy operation is performed on a single global variable object in the global list, it is considered normal.

[0091] In one scenario, memory monitoring strategies can be customized according to actual needs. For example, the detection and warning of functional safety logic of the real-time operating system under test can be customized. When the system reaches the corresponding state, it can automatically pause and issue a warning, and save the stack backtrace information for testers to analyze.

[0092] In this embodiment, a corresponding memory monitoring strategy is configured by analyzing memory operation functions, memory access operations, stacks, and global variables, thereby realizing memory usage monitoring and anomaly detection based on full system simulation. This compensates for the functional defects of traditional technologies that do not support the detection of the memory status of real-time operating systems, and enables accurate early warning of errors such as memory access.

[0093] In one embodiment, such as Figure 5 As shown, in step 106, the target test task is executed based on the test key points, and the execution results are obtained. Specifically, this may include:

[0094] Step 502: At the start of the test, load the logic for generating and writing test data corresponding to the target test task and the logic for fuzzing the test data, and at the end of the test, load the logic for fuzzing the test data.

[0095] Traditional testing of real-time operating systems relies on actual hardware devices. Fuzzing the firmware of a real-time operating system requires repeated flashing of the hardware, thus affecting its lifespan. Furthermore, fuzzing the system firmware requires transmitting data over slow data transmission lines, further reducing the speed of the fuzzing process. Therefore, in this embodiment, the terminal can... Figure 2 The simulator created by the method shown and Figure 3 The method shown identifies key test points and performs fuzzy testing on the real-time operating system under test, thus eliminating reliance on hardware devices, reducing equipment wear and tear, and improving testing efficiency.

[0096] Specifically, the terminal loads the logic for generating and writing test data corresponding to the target test task and the fuzzing logic at the start of the test, and loads the fuzzing logic at the end of the test. The logic for generating and writing test data and the fuzzing logic can be pre-set related logic.

[0097] Step 504: When the real-time operating system under test reaches the test start point, test data is generated and filled according to the generation and writing logic, and the fuzz test processing logic is entered.

[0098] Specifically, when the real-time operating system under test reaches the test start point, the terminal can generate and fill test data according to the above-mentioned loading generation and writing logic, and then enter the fuzz test processing logic.

[0099] Step 506: When the real-time operating system under test reaches the end point of the test, execute the fuzz test processing logic and obtain the execution result.

[0100] Specifically, when the real-time operating system under test reaches the end point of the test, the terminal can also execute fuzz testing logic and obtain the execution results.

[0101] In this embodiment, the above steps can be used to complete the targeted and efficient testing of multiple frames of data. At the same time, it can ensure the normal operation of the system firmware when entering the test and the correct initialization of various global variables, thereby avoiding false alarms caused by other factors and further improving the testing efficiency.

[0102] Furthermore, to verify the effectiveness of the above tests, the coverage of the seeds generated by the fuzzing test can be recorded after the fuzzing test is completed. Specifically, each basic block in the firmware of the real-time operating system under test is instrumented, and the number of times each basic block is triggered by the test dataset is counted. To reduce the impact of slow system firmware startup and initialization on the coverage statistics speed, a forkserver method (a fuzzing acceleration method based on the fork function) can be used. This involves starting the forkserver at the first data input point (i.e., the test start point) to execute a fork (a system call) on the simulator process. This way, the code before the fuzzing start point only needs to run once, and each subsequent test data only executes the instruction part corresponding to the fuzzing processing logic after the start point, thereby speeding up the testing and coverage extraction.

[0103] After obtaining the coverage record, it can be visualized in reverse engineering tools, facilitating subsequent evaluation of the fuzzing effect. For example, it allows for viewing uncovered branches and generating test data that can reach those branches. Furthermore, static analysis can be used to perform weight analysis on uncovered branches (e.g., the number of dangerous functions and adjacent branches), and attempts can be made to extract possible flag strings or input format information (e.g., length control fields, checksums, etc.) from uncovered branches for use in subsequent fuzzing, further improving the efficiency of fuzzing.

[0104] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0105] Based on the same inventive concept, this application also provides a fuzzing apparatus for a real-time operating system for implementing the fuzzing method of the real-time operating system described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more embodiments of the fuzzing apparatus for a real-time operating system provided below can be found in the limitations of the fuzzing method for a real-time operating system described above, and will not be repeated here.

[0106] In one embodiment, such as Figure 6 As shown, a fuzzing device for a real-time operating system is provided, comprising: a simulator creation module 602, a memory state acquisition module 604, a test execution module 606, and a test result generation module 608, wherein:

[0107] The simulator creation module 602 is used to create a simulator based on the real-time operating system to be tested and to determine the key points of the test.

[0108] The memory status acquisition module 604 is used to obtain the memory status during the operation of the real-time operating system under test by running the real-time operating system under test through the simulator.

[0109] Test execution module 606 is used to execute target test tasks based on the test key points and obtain execution results;

[0110] The test result generation module 608 is used to generate test results for the real-time operating system under test based on the memory state and the execution results.

[0111] In one embodiment, the apparatus further includes a test key point determination module, which further includes: a function information identification unit, configured to identify corresponding function information based on the real-time operating system to be tested; a graph generation unit, configured to generate a function call relationship graph corresponding to the target test task based on the function information; and a determination unit, configured to determine the test start point and test end point of the target test task based on the function call relationship graph and preset test data; and to use the test start point and the test end point as the test key points.

[0112] In one embodiment, the function information includes a function name and a function body; the graph generation unit is further configured to: identify various types of tasks based on the function name and function body; determine a set of upper-level tasks based on the various types of tasks; identify the function set of the target test task based on the function name and function body; generate an upper-level call relationship graph for each function in the function set using control flow analysis; and generate a function call relationship graph corresponding to the target test task based on the upper-level call relationship graph and the set of upper-level tasks.

[0113] In one embodiment, the determining unit is further configured to: locate the memory location where the test data is written and the function it belongs to by tracing, based on the function call graph and preset test data, and determine the located memory location and the function it belongs to as the test start point; identify loop jump points and task exit points through the function call graph, and determine the test end point based on the loop jump points and the task exit points.

[0114] In one embodiment, the test execution module is further configured to: load the test data generation and writing logic and fuzzing processing logic corresponding to the target test task at the test start point, and load the fuzzing processing logic at the test end point; when the real-time operating system under test reaches the test start point, generate and fill the test data according to the generation and writing logic, and enter the fuzzing processing logic; when the real-time operating system under test reaches the test end point, execute the fuzzing processing logic and obtain the execution result.

[0115] In one embodiment, the memory status acquisition module is further configured to: acquire a configured memory monitoring strategy; run the memory monitoring strategy and acquire the running results during the process of the simulator running the real-time operating system to be tested; and determine the memory status during the running process of the real-time operating system to be tested based on the running results.

[0116] In one embodiment, the simulator creation module is further configured to: identify corresponding function information and external devices used based on the real-time operating system to be tested; determine the starting point of the real-time operating system to be tested and the load address of each program segment based on the function information; map the program segments to a pre-allocated first virtual memory space based on the load address of the program segments; initialize the pre-allocated second virtual memory space of the external device as a virtual device; and generate a simulator based on the load address of each program segment, the mapped first virtual memory space, the virtual device, and the starting point of the real-time operating system to be tested.

[0117] The modules in the aforementioned fuzzy testing device for a real-time operating system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can call and execute the corresponding operations of each module.

[0118] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a fuzzy testing method for a real-time operating system. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0119] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0120] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0121] Create a simulator based on the real-time operating system to be tested, and determine the key test points;

[0122] The real-time operating system under test is run through the simulator to obtain the memory status during the operation of the real-time operating system under test.

[0123] Execute the target test task based on the aforementioned key test points and obtain the execution results;

[0124] The test results of the real-time operating system under test are generated based on the memory state and the execution results.

[0125] In one embodiment, when the processor executes the computer program, it further performs the following steps: identifying corresponding function information based on the real-time operating system to be tested; generating a function call relationship graph corresponding to the target test task based on the function information; determining the test start point and test end point of the target test task based on the function call relationship graph and preset test data; and using the test start point and the test end point as the test key points.

[0126] In one embodiment, when the processor executes a computer program, it further performs the following steps: identifying various types of tasks based on the function name and function body, and determining a set of upper-level tasks based on the various types of tasks; identifying the function set of the target test task based on the function name and function body, and generating an upper-level call relationship graph for each function in the function set using control flow analysis; and generating a function call relationship graph corresponding to the target test task based on the upper-level call relationship graph and the set of upper-level tasks.

[0127] In one embodiment, when the processor executes a computer program, it further performs the following steps: based on the function call graph and preset test data, it locates the memory location where the test data is written and the function in which it is located by tracing, and determines the located memory location and the function in which it is located as the test start point; it identifies loop jump points and task exit points through the function call graph, and determines the test end point based on the loop jump points and the task exit points.

[0128] In one embodiment, when the processor executes the computer program, it further implements the following steps: loading the generation and writing logic and fuzzing processing logic of test data corresponding to the target test task at the test start point, and loading the fuzzing processing logic at the test end point; when the real-time operating system under test reaches the test start point, generating and filling the test data according to the generation and writing logic, and entering the fuzzing processing logic; when the real-time operating system under test reaches the test end point, executing the fuzzing processing logic and obtaining the execution result.

[0129] In one embodiment, when the processor executes a computer program, it further performs the following steps: obtaining a configured memory monitoring policy; running the memory monitoring policy and obtaining the running results during the process of the simulator running the real-time operating system under test; and determining the memory state during the running of the real-time operating system under test based on the running results.

[0130] In one embodiment, when the processor executes a computer program, it further performs the following steps: identifying corresponding function information and external devices used based on the real-time operating system under test; determining the starting point of the real-time operating system under test and the load address of each program segment based on the function information; mapping the program segments to a pre-allocated first virtual memory space based on the load address of the program segments; initializing the pre-allocated second virtual memory space of the external device as a virtual device; and generating a simulator based on the load address of each program segment, the mapped first virtual memory space, the virtual device, and the starting point of the real-time operating system under test.

[0131] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0132] Create a simulator based on the real-time operating system to be tested, and determine the key test points;

[0133] The real-time operating system under test is run through the simulator to obtain the memory status during the operation of the real-time operating system under test.

[0134] Execute the target test task based on the aforementioned key test points and obtain the execution results;

[0135] The test results of the real-time operating system under test are generated based on the memory state and the execution results.

[0136] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: identifying corresponding function information based on the real-time operating system to be tested; generating a function call relationship graph corresponding to the target test task based on the function information; determining the test start point and test end point of the target test task based on the function call relationship graph and preset test data; and using the test start point and the test end point as the test key points.

[0137] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: identifying various types of tasks based on the function name and function body, and determining a set of upper-level tasks based on the various types of tasks; identifying the function set of the target test task based on the function name and function body, and generating an upper-level call relationship graph for each function in the function set using control flow analysis; and generating a function call relationship graph corresponding to the target test task based on the upper-level call relationship graph and the set of upper-level tasks.

[0138] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: based on the function call graph and preset test data, it locates the memory location where the test data is written and the function in which it is located by tracing, and determines the located memory location and the function in which it is located as the test start point; it identifies loop jump points and task exit points through the function call graph, and determines the test end point based on the loop jump points and the task exit points.

[0139] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: loading the generation and writing logic and fuzzing processing logic of test data corresponding to the target test task at the test start point, and loading the fuzzing processing logic at the test end point; when the real-time operating system under test reaches the test start point, generating and filling the test data according to the generation and writing logic, and entering the fuzzing processing logic; when the real-time operating system under test reaches the test end point, executing the fuzzing processing logic and obtaining the execution result.

[0140] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining a configured memory monitoring policy; running the memory monitoring policy and obtaining the running results during the process of the simulator running the real-time operating system under test; and determining the memory state during the running of the real-time operating system under test based on the running results.

[0141] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: identifying corresponding function information and external devices used according to the real-time operating system under test; determining the starting point of the real-time operating system under test and the load address of each program segment according to the function information; mapping the program segments to a pre-allocated first virtual memory space according to the load address of the program segments; initializing the pre-allocated second virtual memory space of the external device as a virtual device; and generating a simulator according to the load address of each program segment, the mapped first virtual memory space, the virtual device, and the starting point of the real-time operating system under test.

[0142] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0143] Create a simulator based on the real-time operating system to be tested, and determine the key test points;

[0144] The real-time operating system under test is run through the simulator to obtain the memory status during the operation of the real-time operating system under test.

[0145] Execute the target test task based on the aforementioned key test points and obtain the execution results;

[0146] The test results of the real-time operating system under test are generated based on the memory state and the execution results.

[0147] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: identifying corresponding function information based on the real-time operating system to be tested; generating a function call relationship graph corresponding to the target test task based on the function information; determining the test start point and test end point of the target test task based on the function call relationship graph and preset test data; and using the test start point and the test end point as the test key points.

[0148] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: identifying various types of tasks based on the function name and function body, and determining a set of upper-level tasks based on the various types of tasks; identifying the function set of the target test task based on the function name and function body, and generating an upper-level call relationship graph for each function in the function set using control flow analysis; and generating a function call relationship graph corresponding to the target test task based on the upper-level call relationship graph and the set of upper-level tasks.

[0149] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: based on the function call graph and preset test data, it locates the memory location where the test data is written and the function in which it is located by tracing, and determines the located memory location and the function in which it is located as the test start point; it identifies loop jump points and task exit points through the function call graph, and determines the test end point based on the loop jump points and the task exit points.

[0150] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: loading the generation and writing logic and fuzzing processing logic of test data corresponding to the target test task at the test start point, and loading the fuzzing processing logic at the test end point; when the real-time operating system under test reaches the test start point, generating and filling the test data according to the generation and writing logic, and entering the fuzzing processing logic; when the real-time operating system under test reaches the test end point, executing the fuzzing processing logic and obtaining the execution result.

[0151] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining a configured memory monitoring policy; running the memory monitoring policy and obtaining the running results during the process of the simulator running the real-time operating system under test; and determining the memory state during the running of the real-time operating system under test based on the running results.

[0152] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: identifying corresponding function information and external devices used according to the real-time operating system under test; determining the starting point of the real-time operating system under test and the load address of each program segment according to the function information; mapping the program segments to a pre-allocated first virtual memory space according to the load address of the program segments; initializing the pre-allocated second virtual memory space of the external device as a virtual device; and generating a simulator according to the load address of each program segment, the mapped first virtual memory space, the virtual device, and the starting point of the real-time operating system under test.

[0153] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0154] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0155] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0156] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A fuzz testing method for a real-time operating system, characterized in that, The method includes: Create a simulator based on the real-time operating system to be tested, and determine the key test points; The real-time operating system under test is run through the simulator to obtain the memory status during the operation of the real-time operating system under test. Execute the target test task based on the aforementioned key test points and obtain the execution results; The test results of the real-time operating system under test are generated based on the memory state and the execution results. The process of creating a simulator based on the real-time operating system to be tested includes: Identify the corresponding function information and the external devices used based on the real-time operating system under test; The starting point of the real-time operating system under test and the loading address of each program segment are determined based on the function information. The program segment is mapped to a pre-allocated first virtual memory space based on its load address; Initialize the pre-allocated second virtual memory space of the external device as a virtual device; A simulator is generated based on the load address of each program segment, the mapped first virtual memory space, the virtual device, and the starting point of the real-time operating system to be tested; The determination of key test points includes: Identify the corresponding function information based on the real-time operating system to be tested; Generate a function call relationship graph corresponding to the target test task based on the function information; Based on the function call relationship graph and the preset test data, determine the test start point and test end point of the target test task; The test start point and the test end point are designated as the test key points.

2. The method according to claim 1, characterized in that, The function information includes the function name and function body; generating the function call relationship graph corresponding to the target test task based on the function information includes: Based on the function name and function body, identify various types of tasks, and determine the upper-level task set based on the various types of tasks; Based on the function names and function bodies, identify the function set of the target test task, and generate an upper-level call relationship graph for each function in the function set using control flow analysis. The function call relationship graph corresponding to the target test task is generated based on the upper-level call relationship graph and the upper-level task set.

3. The method according to claim 1, characterized in that, The step of determining the start and end points of the target test task based on the function call graph and preset test data includes: Based on the function call graph and the preset test data, the memory location where the test data is written and the function it belongs to are located by tracing, and the located memory location and the function it belongs to are determined as the test start point; The loop jump point and task exit point are identified by the function call relationship graph, and the test end point is determined based on the loop jump point and the task exit point.

4. The method according to claim 1, characterized in that, The step of executing the target test task based on the test key points and obtaining the execution results includes: At the start point of the test, the logic for generating and writing test data corresponding to the target test task and the logic for fuzz testing are loaded, and at the end point of the test, the logic for fuzz testing is loaded. When the real-time operating system under test reaches the test start point, the test data is generated and filled according to the generation and writing logic, and then the fuzz test processing logic is entered. When the real-time operating system under test reaches the end point of the test, the fuzz test processing logic is executed, and the execution result is obtained.

5. The method according to any one of claims 1 to 4, characterized in that, The step of running the real-time operating system under test through the simulator and obtaining the memory state of the real-time operating system under test during its operation includes: Retrieve the configured memory monitoring policy; During the process of running the real-time operating system under test in the simulator, the memory monitoring strategy is executed and the results are obtained; The memory state during the operation of the real-time operating system under test is determined based on the results of the test.

6. A fuzz testing device for a real-time operating system, characterized in that, The device includes: The simulator creation module is used to create a simulator based on the real-time operating system to be tested. The test critical point determination module is used to determine the test critical points; The memory status acquisition module is used to obtain the memory status during the operation of the real-time operating system under test by running the simulator. The test execution module is used to execute target test tasks based on the test key points and obtain execution results; The test result generation module is used to generate test results for the real-time operating system under test based on the memory state and the execution results. The simulator creation module is specifically used for: identifying the corresponding function information and external devices used by the real-time operating system under test; determining the starting point of the real-time operating system under test and the load address of each program segment based on the function information; mapping the program segments to a pre-allocated first virtual memory space based on the load address of the program segments; initializing the pre-allocated second virtual memory space of the external devices as virtual devices; and generating a simulator based on the load address of each program segment, the mapped first virtual memory space, the virtual devices, and the starting point of the real-time operating system under test. The test key point determination module is specifically used for: identifying the corresponding function information based on the real-time operating system to be tested; generating a function call relationship graph corresponding to the target test task based on the function information; determining the test start point and test end point of the target test task based on the function call relationship graph and preset test data; and using the test start point and the test end point as the test key points.

7. The apparatus according to claim 6, characterized in that, The test execution module is also used for: At the start point of the test, the logic for generating and writing test data corresponding to the target test task and the logic for fuzz testing are loaded, and at the end point of the test, the logic for fuzz testing is loaded. When the real-time operating system under test reaches the test start point, the test data is generated and filled according to the generation and writing logic, and then the fuzz test processing logic is entered. When the real-time operating system under test reaches the end point of the test, the fuzz test processing logic is executed, and the execution result is obtained.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 5.

Images