Fuzzy testing method and device for closed source operating system

Abstract

The invention belongs to the technical field of operating system security, and particularly discloses a fuzzy testing method and device for a closed source operating system, and the method comprises the steps: for a task in a target task set, in the process of executing a test case, when a TCG of virtualization software QEMU performs code translation on a translation block TB, performing code translation on the translation block TB by the TCG of the virtualization software QEMU; inserting the target intermediate code into the intermediate code translated by the TCG, wherein the target intermediate code is used for instruction tracking or vulnerability detection; and when the intermediate code is executed, obtaining test information of the closed source operating system through the target intermediate code. According to the method, the target intermediate code is inserted, so that when the intermediate code corresponding to the TB is executed, the target intermediate code is utilized to perform instruction tracking or vulnerability detection to obtain the test information, and the execution mode of the QEMU is switched into a hardware virtualization KVM mode for tasks except the target task set; fuzzy testing can be efficiently carried out on the closed source operating system.

Description

Technical Field

[0001] The present application belongs to the field of operating system security technology, and more specifically, to a fuzz testing method and device for a closed-source operating system. Background Art

[0002] Among the many existing memory vulnerability detection tools, instruction tracing (coverage) and vulnerability detection (sanitizer) codes are usually inserted into the executable binary product during the source code compilation process. When the program is running, this binary product will run these inserted codes when reading and writing memory to implement instruction tracing and memory vulnerability detection. However, there is no way to do this for many closed-source operating systems: First, the source code of closed-source operating systems (such as microkernel operating systems and vehicle network real-time operating systems) is not public, and the security R&D personnel and security assessors of third-party organizations cannot implement this method that requires source code. Second, even if some existing technologies that can track virtual machine instructions are used, because the existing technologies will monitor the operation of all instructions in the system, including a large number of instruction sequences that are not concerned in the test, the existing tools will cause efficiency to slow down and waste resources. Summary of the invention

[0003] In view of the defects of the prior art, the purpose of this application is to achieve efficient fuzz testing for closed-source operating systems.

[0004] To achieve the above objectives, in a first aspect, the present application provides a fuzz testing method for a closed-source operating system, comprising: For the tasks in the target task set, during the execution of the test case, when the software simulation function module TCG of the virtualization software QEMU performs code translation on the translation block TB, the target intermediate code is inserted into the intermediate code translated by the software simulation function module TCG, and the intermediate code corresponding to the translation block TB is obtained. The target intermediate code is used for instruction tracing or vulnerability detection; When the intermediate code corresponding to the translation block TB is executed, the test information of the closed source operating system is obtained through the target intermediate code; Among them, the tasks in the target task set are the test objects of the test cases.

[0005] In a possible implementation, when the target intermediate code is used for instruction tracing, inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG includes: The target intermediate code is inserted at the beginning of the intermediate code translated by the software simulation function module TCG.

[0006] In a possible implementation, when the intermediate code corresponding to the translation block TB is executed, the test information of the closed-source operating system is obtained through the target intermediate code, including: Based on the starting address of the previous translation block TB and the starting address of the current translation block TB, determine whether the edge between the two translation blocks TB already exists in the edge set; If the edge between two translation blocks TB does not exist in the edge set, it is determined that a new edge cover is found; The edge set is used to store discovered edges, each element in the set is a unique identifier of an edge, and each element consists of the starting address of the source TB and the starting address of the target TB.

[0007] In a possible implementation, before inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG, the method further includes: Based on the target cache and the start address and code length of the translation block TB, determine whether the translation block TB has been translated; If the translation block TB has not been translated, it is determined that a new block coverage is found, and the starting address and code length of the translation block TB are recorded in the target cache to mark the translation block TB as having been translated; The target cache is used to store the starting address and code length of the translated translation block TB.

[0008] In a possible implementation, when the target intermediate code is used for vulnerability detection, the target intermediate code is inserted into the intermediate code translated by the software simulation function module TCG, including: The target intermediate code is inserted into the intermediate code corresponding to a specific function of the translation block TB, where the specific function is a function including a memory access operation.

[0009] In a possible implementation, when the intermediate code corresponding to the translation block TB is executed, the test information of the closed-source operating system is obtained through the target intermediate code, including: Read the parameters and return values ​​of a specific function call and update the contents of the shadow memory; Among them, the content in the shadow memory is used to verify the legality of the memory access operation. If the memory access operation is an illegal operation, the virtualization software QEMU is interrupted.

[0010] In a possible implementation, the method further includes: Before the operating system executes task scheduling each time, it is determined whether the scheduled task is a task in the target task set. If the scheduled task is a task in the target task set, the software simulation function module TCG of the virtualization software QEMU is determined to run the scheduled task. Otherwise, the kernel-based virtual machine KVM of the virtualization software QEMU is determined to run the scheduled task.

[0011] Specifically, the target code can be inserted before each operating system executes the task scheduling process. The target code is used to determine whether the scheduled task is a task in the target task set. If the scheduled task is a task in the target task set, QEMU's TCG mode is put into operation. If the scheduled task is not a task in the target task set, QEMU's KVM mode is put into operation.

[0012] In a second aspect, the present application provides a fuzzy testing device for a closed-source operating system, comprising: The code insertion module is used for inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG of the virtualization software QEMU when executing the test case for the tasks in the target task set, and obtaining the intermediate code corresponding to the translation block TB, and the target intermediate code is used for instruction tracing or vulnerability detection; A test information acquisition module, used to acquire test information of the closed source operating system through the target intermediate code when the intermediate code corresponding to the translation block TB is executed; Among them, the tasks in the target task set are the test objects of the test cases.

[0013] In a third aspect, the present application provides an electronic device comprising: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0014] In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0015] In general, the above technical solutions conceived by this application have the following beneficial effects compared with the prior art: (1) The TCG module in QEMU can translate the code of any architecture (such as a closed-source operating system) into code suitable for the current system and execute it, so as to realize the execution of code in different architectures in a single system. Furthermore, during the execution of test cases, if the software simulation function module TCG of the virtualization software QEMU translates the code of the translation block TB, the target intermediate code can be inserted into the intermediate code translated by the software simulation function module TCG. Then, when the intermediate code corresponding to the translation block TB is executed, the target intermediate code can be used for instruction tracing or vulnerability detection to obtain the test information of the operating system (such as running status information, crash information, etc.). There is no need to rely on the source code of the operating system, and vulnerability detection can be performed at the binary product level.

[0016] (2) It is applicable to macro kernel operating systems, as well as micro kernel operating systems and real-time operating systems.

[0017] (3) Compared with pure software simulation solutions, fuzz testing can be performed efficiently by using the virtualization software QEMU to run tasks in the target task set.

[0018] (4) Ability to integrate different vulnerability detection tools (Sanitizer) into a virtual machine framework. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a flowchart of a fuzzy testing method for a closed-source operating system provided in an embodiment of the present application; Figure 2 is a schematic diagram of a fuzzy testing framework provided in an embodiment of the present application; Figure 3 It is a schematic diagram of the process of executing code translation by the TCG module provided in the embodiment of the present application; Figure 4 It is a flowchart of the TCG module provided in the embodiment of the present application executing virtual machine instructions; Figure 5 It is a schematic diagram of the vulnerability detection process provided by the embodiment of the present application; Figure 6 is a schematic diagram of the working principle of the acceleration module provided in an embodiment of the present application; Figure 7 It is a structural schematic diagram of a fuzzy testing device for a closed-source operating system provided in an embodiment of the present application; Figure 8 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0021] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0022] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more than two. For example, multiple processing units refer to two or more processing units, etc.; multiple elements refer to two or more elements, etc.

[0023] First, the technical terms involved in the embodiments of the present application are introduced.

[0024] (1) Fuzz Testing: Fuzz Testing is an automated software testing technology that is mainly used to discover security vulnerabilities and defects in programs. In the field of operating system security, fuzz testing is widely used to detect the security of kernels, drivers, and other system components. The basic principle of fuzz testing is to detect potential security vulnerabilities and stability issues in the system by inputting abnormal, randomly generated data (called fuzzy data) into the system.

[0025] (2) Monolithic Kernel Operating System: A monolithic kernel operating system is a traditional operating system design in which all core functions of the operating system, such as process management, memory management, file system, device drivers, and network stack, run in a single kernel space and directly call the same kernel address space.

[0026] (3) Microkernel operating system: The microkernel operating system adopts a more streamlined design approach. It only retains the most basic system services, such as process and thread management, communication, etc., in the kernel. Other non-core services, such as file systems, device drivers, and network stacks, run as separate processes in user space. Microkernel operating systems can specifically be real-time operating systems.

[0027] (4) Coverage information refers to a metric that measures the execution of test cases on program source code during software testing. It describes the percentage of statements, branches, paths or conditions in the code that are accessed and executed during test execution, and is used to evaluate the comprehensiveness and effectiveness of the test. Coverage information can be used to improve software quality, ensure code integrity and discover potential defects. Block Coverage and Edge Coverage are two common code coverage metrics that are used to measure the execution of test cases on program code.

[0028] (5) Block Coverage: Block coverage refers to the proportion of basic blocks covered by test cases during program execution. A basic block is a continuous section of code without any jumps (such as conditional statements, loops, etc.). Once the block is entered, it will be executed sequentially. The advantage of block coverage is that it is simple to understand and can quickly evaluate the coverage of the code by test cases.

[0029] (6) Edge Coverage: Edge coverage focuses on the edges in the program control flow graph. In the control flow graph, an edge represents the transfer of control flow from one basic block to another. Edge coverage provides more fine-grained coverage information because it considers all possible control flow paths in the program. By ensuring that the test cases cover all edges, the logic and behavior of the program can be more fully verified, especially in the presence of conditional branches and loops.

[0030] (7) QEMU (Quick Emulator) is an open source virtualization software widely used in the field of operating system security. It can simulate a variety of hardware platforms and support virtualization of multiple operating systems. Through QEMU, researchers can simulate attacks in a virtual environment and test the security of operating systems and applications without causing damage to the real system.

[0031] (8) The QEMU TCG (Tiny Code Generator) module is a part of QEMU that implements software emulation. TCG allows QEMU to run virtual machines without hardware virtualization support. It mainly converts the instructions of the target architecture into the instructions of the host architecture through dynamic translation, thereby achieving support for different CPU architectures.

[0032] (9) TB (Translation Block): TB is a basic execution unit in QEMU TCG. It refers to a continuous sequence of target architecture instructions that are translated into host architecture instructions when executed. TB usually corresponds to a basic block of the target CPU, that is, a continuous sequence of instructions without branches (except for possible jumps at the end of the block). QEMU TCG splits the target code into multiple TBs and then translates and executes them one by one.

[0033] (10) Shadow Memory is a technology used for program analysis and debugging, mainly used to track and manage memory usage in programs. It records and monitors the program's read and write operations on memory by creating a "shadow" memory area corresponding to the actual memory.

[0034] (11) Syzkaller is a tool for automating the discovery and testing of kernel vulnerabilities. It aims to discover security vulnerabilities and defects in the kernel through fuzzing technology.

[0035] (12) Kernel-based Virtual Machine (KVM) is a hardware virtualization module in the Linux kernel that allows Linux to become a hypervisor and directly manage the creation, running, and stopping of virtual machines.

[0036] The embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application.

[0037] Figure 1 is a flow chart of a fuzzy testing method for a closed-source operating system provided in an embodiment of the present application, such as Figure 1 As shown, the method includes the following steps S101 and S102.

[0038] Step S101, for the tasks in the target task set, in the process of executing the test case, when the software simulation function module TCG of the virtualization software QEMU performs code translation on the translation block TB, the target intermediate code is inserted into the intermediate code translated by the software simulation function module TCG, and the intermediate code corresponding to the translation block TB is obtained, and the target intermediate code is used for instruction tracing or vulnerability detection; Step S102, when the intermediate code corresponding to the translation block TB is executed, the test information of the closed source operating system is obtained through the target intermediate code; Among them, the tasks in the target task set are the test objects of the test cases.

[0039] It can be understood that the TCG module in QEMU can translate the code of any architecture (such as a closed-source operating system) into code suitable for the current system and execute it, so as to realize the execution of code in different architectures in a single system. Furthermore, in the process of executing test cases, if the software simulation function module TCG of the virtualization software QEMU performs code translation on the translation block TB, the target intermediate code can be inserted into the intermediate code translated by the software simulation function module TCG. Then, when the intermediate code corresponding to the translation block TB is executed, the target intermediate code can be used for instruction tracing or vulnerability detection to obtain the test information of the closed-source operating system (such as running status information, crash information, etc.). For tasks outside the target task set, the execution mode of QEMU can be switched to the hardware virtualization KVM mode to realize efficient fuzz testing of the closed-source operating system.

[0040] In a possible implementation, when the target intermediate code is used for instruction tracing, the above-mentioned inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG includes: The target intermediate code is inserted at the beginning of the intermediate code translated by the software simulation function module TCG.

[0041] In a possible implementation, when the intermediate code corresponding to the translation block TB is executed, the test information of the closed-source operating system is obtained through the target intermediate code, including: Based on the starting address of the previous translation block TB and the starting address of the current translation block TB, determine whether the edge between the two translation blocks TB already exists in the edge set; If the edge between two translation blocks TB does not exist in the edge set, it is determined that a new edge coverage is found (appears); The edge set is used to store discovered edges, each element in the set is a unique identifier of an edge, and each element consists of the starting address of the source TB and the starting address of the target TB.

[0042] Specifically, a set is used to store the discovered edges, and each element in the set is a unique identifier of an Edge, consisting of the starting address of the source TB and the starting address of the target TB.

[0043] Whenever a TB is executed, the control flow transfers (such as conditional jumps, function calls, etc.) in the TB are checked based on the start address of the previous TB and the start address of the current TB. For each control flow transfer, the edge between the source basic block and the target basic block is calculated based on the start address of the previous TB and the start address of the current TB, and it is checked whether the edge already exists in the edge set.

[0044] If a new edge is found (i.e., the edge is not in the set of recorded edges), it is added to the set.

[0045] After each TB is executed, the starting address of the current TB is recorded so that it can be determined whether a new edge is found when the next TB is executed.

[0046] It is understandable that the above-mentioned closed-source operating system test information may include: the running status information of the closed-source operating system. Accordingly, in the case of a new Edge Coverage, the event of the new Edge Coverage appearing may be recorded as the running status information of the closed-source operating system.

[0047] In a possible implementation, before inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG, the following is further included: Based on the target cache and the start address and code length of the translation block TB, determine whether the translation block TB has been translated; If the translation block TB has not been translated, it is determined that a new block coverage is found (appears), and the starting address and code length of the translation block TB are recorded in the target cache to mark the translation block TB as having been translated; The target cache is used to store the starting address and code length of the translated translation block TB.

[0048] Specifically, a cache is maintained to store information about translated TBs (including the starting address and code length of the TB); whenever a TB needs to be translated, QEMU extracts its starting address and length, and then searches for it in the cache; if a TB with the same starting address and code length is found, then the TB is considered to have been translated; if not found, then the TB is considered to have not been translated.

[0049] It is understandable that the above-mentioned closed-source operating system test information may include: the running status information of the closed-source operating system. Accordingly, in the case of a new Block Coverage, the event of the new Block Coverage appearing may be recorded as the running status information of the closed-source operating system.

[0050] In a possible implementation, when the target intermediate code is used for vulnerability detection, the above-mentioned inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG includes: The target intermediate code is inserted into the intermediate code corresponding to a specific function of the translation block TB, where the specific function is a function including a memory access operation.

[0051] In a possible implementation, when the intermediate code corresponding to the translation block TB is executed, the test information of the closed-source operating system is obtained through the target intermediate code, including: Read the parameters and return values ​​of a specific function call and update the contents of the shadow memory; Among them, the content in the shadow memory is used to verify the legality of the memory access operation. If the memory access operation is an illegal operation, the virtualization software QEMU is interrupted.

[0052] It is understandable that the above-mentioned closed-source operating system test information may include: closed-source operating system crash information. Accordingly, when it is found that the memory access operation is an illegal operation, the virtualization software QEMU is interrupted and enters an abnormal (panic) state, so that the fuzz testing tool can obtain the crash information.

[0053] In a possible implementation, the method further includes: Before the operating system executes task scheduling each time, it is determined whether the scheduled task is a task in the target task set. If the scheduled task is a task in the target task set, the software simulation function module TCG of the virtualization software QEMU is determined to run the scheduled task. Otherwise, the kernel-based virtual machine KVM of the virtualization software QEMU is determined to run the scheduled task.

[0054] The fuzz testing method for closed-source operating systems provided by this application is described below with reference to several examples.

[0055] The fuzz testing framework in this application refers to a collection of fuzz testing tools, virtual machines and their related instruction tracing and vulnerability detection tools.

[0056] Here is an explanation of the fuzz testing framework. Figure 2 As shown, the fuzz testing framework is mainly divided into two aspects: the first is the fuzz testing tool, and the other is the virtual machine and its instruction tracing and vulnerability detection technology.

[0057] The fuzz testing tool is responsible for generating test inputs. For a specific system, it is necessary to implement some strategies for generating test inputs for a specific real-time operating system, and is responsible for sending test cases to the test case executor to complete the test. When the test is completed, the fuzz testing tool collects the system's operating status and crash information (if a crash occurs) from the virtual machine, and records this information in a book for the next test case generation.

[0058] The following is an exemplary description of the fuzz testing tool.

[0059] In order to adapt to the microkernel operating system, this application upgrades the coverage information collected by the fuzz testing tool. Because in a microkernel system, the code of interest may run in user space, so in addition to recording the address information corresponding to the coverage, the process number corresponding to the coverage is also recorded, and the complete coverage information of the kernel and key services is obtained by querying the memory mapping information.

[0060] The following is an exemplary description of instruction tracing in a virtual machine.

[0061] In the virtual machine test mode, in order to collect system coverage information, this application can add instruction tracing function to the existing virtual machine. This tool can collect coverage information through the virtual machine software itself when the client system does not have the ability to collect coverage information. The method and process of coverage collection can be referred to Figure 3 and Figure 4 . Figure 3 , Figure 4 The part outside the dotted box is the workflow of the widely used open source software QEMU TCG module, and the part inside the dotted box is the new process added by this application. The TCG module in QEMU can translate the code of any architecture into the code adapted to the current system and execute it, so as to realize the execution of codes in different architectures in a single system. Figure 3 and Figure 4 The code translation and execution processes of the QEMU TCG module and the modifications made to them by this application are respectively shown.

[0062] Figure 3 In the process of executing code translation for the TCG module of QEMU, QEMU TCG translates and executes the code in units of Translation Block (TB for short). QEMU TCG translates TB into intermediate code, optimizes it and stores it in Code Cache for subsequent use. The present application has made two modifications to this step: (1) Whenever QEMU TCG performs code translation, it checks whether the TB being translated has been translated before by comparing the starting address of TB and the code length. If it has not been translated, it indicates that a new Block Coverage has appeared, and the new Block Coverage is reported and the current TB is marked as having been translated; (2) Whenever QEMU TCG performs code translation, a custom intermediate code (such as Figure 3 The intermediate code will be executed every time TB is executed.

[0063] Figure 4This is the process of QEMU's TCG module when executing virtual machine instructions. When executing instructions, it first looks for the next TB to be executed, and then looks in the Code Cache to see if the TB has been translated. If the TB is not found in the Code Cache, it executes Figure 3 The process in the code cache translates the TB; if the TB is found in the Code Cache, the translated TB can be directly executed. Since the application has modified the translation process, in the step of executing the virtual machine instruction, each execution of the translated TB will execute Figure 3 The custom intermediate code (trace_tb_start) added in the . This intermediate code performs the following operations: calculate and compare whether a new edge coverage appears according to the starting address of the TB, and if a new edge coverage appears, record the edge coverage and record the starting address of the TB so that the edge coverage can be calculated and compared when the next TB is executed.

[0064] The following is an exemplary description of vulnerability detection in a virtual machine.

[0065] In addition to this instruction tracing, this application adds a vulnerability detection function to the virtual machine hypervisor. This capability is usually integrated into the operating system, but some closed-source systems cannot enable this detection capability. This application adds this function to the virtual machine hypervisor. The vulnerability detection method and logic can be referred to Figure 5 ,The logic modifications to QEMU can be roughly divided into two parts.

[0066] The first is to insert custom intermediate code on specific function calls as in instruction tracing (corresponding to Figure 5 The upper part starting with the Translation Block node in the translation block, such as the malloc function and free function related to heap memory, inserts intermediate code (sanitizer_helper_malloc) during translation. The intermediate code performs the following operations: reads the parameters and return values ​​of the related function calls, and updates the contents of the shadow memory.

[0067] The second is to modify the qemu_ld / st_i64 / i32 code every time you access memory, and add a check for the memory access operation (corresponding to Figure 5The lower part of the code that starts with the memory access code node). In the memory access code, the content of the shadow memory is queried to detect whether the current memory access is legal. If it is not legal, the simulator (QEMU) is directly interrupted and enters the abnormal (panic) state so that the fuzz testing tool can obtain the crash information. The panic state refers to an emergency state that the operating system or program enters when encountering an unrecoverable error. It is an error handling mechanism used to deal with serious problems that may cause system instability or crash.

[0068] The following is an exemplary description of the acceleration module in the virtual machine.

[0069] In the above test logic, in order to achieve the effect of instruction tracing and vulnerability detection, it is generally necessary to use software simulation instructions (TCG mode) instead of hardware virtualization (KVM) mechanism. However, in the entire test process, especially for this kind of full-system test, generally focus on a part of the code in the whole system, such as the system kernel, key system services and drivers. As for other services running in the system, they may be very expensive (consuming a lot of processor resources), but they are not paid attention to. Based on this situation, this application designs the following Figure 6 The acceleration module shown can switch between two operating modes under certain circumstances.

[0070] Figure 6 The principle of mode switching is elaborated in detail. First, when the system executes the scheduler and finally performs the task switching operation, the process identifier (pid) of the task after the switch is completed is notified to the virtual machine through the method of inserting the intermediate code described above, so as to ensure that the virtual machine can obtain the task switching information in time; after receiving the notification, the virtual machine enters the mode switching logic; the virtual machine determines whether the current task is a task of interest. If the task is in the set of tasks of interest, it switches to TCG mode to enable the instruction tracking and vulnerability detection functions mentioned above; if the current task is not a task of interest, it directly switches to high-speed mode (KVM) to obtain maximum performance. The above-mentioned "task" refers to an execution unit in a virtual machine (VM), usually a process or thread, for example, a task can be a user program, a system daemon, etc.

[0071] In the specific switching logic, it involves the copying of various hardware and software mechanisms such as register status, memory and TLB (Translation Lookaside Buffer) status, clock status, and interrupt controller status. After completing the copying of these hardware and software status, the task is put back into the processor (TCG / KVM) for execution.

[0072] An embodiment of QNX, a real-time operating system commonly used for vehicle dashboards, is given below, including steps S201 to S204.

[0073] Step S201: Prepare a fuzz testing tool.

[0074] Use the Syzkaller tool and apply the corresponding patches to make the coverage and signal information the coverage information for different processes. At the same time, add some test cases required for testing the QNX system, and then compile and configure the corresponding parameters.

[0075] Step S202: Prepare a virtual machine tool.

[0076] In this embodiment, a corresponding patch is applied to QEMU, a function of dynamically obtaining system coverage information during system operation, vulnerability detection and corresponding acceleration modules are added to the original QEMU, and all these modules are compiled.

[0077] Step S203: Prepare the system image and the file system.

[0078] According to the QNX related documents and instructions, compile a system image that can be started by the QEMU virtual machine, and then try to use the QEMU test prepared in the second step to see if it can run normally.

[0079] Step S204: Integrate the above components.

[0080] According to the instructions in the solution, integrate the fuzz testing tool constructed in the first step, the virtual machine tool constructed in the second step, and the system image constructed in the third step to construct a complete memory vulnerability detection system.

[0081] It should be noted that a similar method can also be used to construct embodiments for other real-time operating systems, such as Linux, Fuchsia, Vxworks, AliOS, etc.

[0082] The following is a description of a fuzzy testing device for a closed-source operating system provided in the present application. The fuzzy testing device for a closed-source operating system described below and the fuzzy testing method for a closed-source operating system described above can refer to each other.

[0083] Figure 7 is a schematic diagram of the structure of a fuzzy testing device for a closed source operating system provided in an embodiment of the present application, such as Figure 7 As shown, the device includes: a code insertion module 10 and a test information acquisition module 20. Among them: The code insertion module 10 is used for inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG of the virtualization software QEMU when executing the test case for the task in the target task set, and obtaining the intermediate code corresponding to the translation block TB, wherein the target intermediate code is used for instruction tracing or vulnerability detection; The test information acquisition module 20 is used to acquire the test information of the closed source operating system through the target intermediate code when the intermediate code corresponding to the translation block TB is executed; Among them, the tasks in the target task set are the test objects of the test cases.

[0084] It can be understood that the detailed functional implementation of each of the above-mentioned units / modules can be found in the introduction of the aforementioned method embodiment, and will not be repeated here.

[0085] It should be understood that the above-mentioned device is used to execute the method in the above-mentioned embodiment. The implementation principle and technical effect of the corresponding program module in the device are similar to those described in the above-mentioned method. The working process of the device can refer to the corresponding process in the above-mentioned method, which will not be repeated here.

[0086] Based on the method in the above embodiment, an embodiment of the present application provides an electronic device, Figure 8 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application, such as Figure 8 As shown, the electronic device may include: a processor (Processor) 810, a communication interface (Communications Interface) 820, a memory (Memory) 830 and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other through the communication bus 840. The processor 810 can call the logic instructions in the memory 830 to execute the method in the above embodiment.

[0087] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application.

[0088] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0089] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0090] It is understandable that the processor in the embodiment of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0091] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0092] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

[0093] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0094] It will be easily understood by those skilled in the art that the above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A fuzz testing method for a closed source operating system, characterized in that: include: For the tasks in the target task set, during the execution of the test case, when the software simulation function module TCG of the virtualization software QEMU performs code translation on the translation block TB, the target intermediate code is inserted into the intermediate code translated by the software simulation function module TCG, and the intermediate code corresponding to the translation block TB is obtained. The target intermediate code is used for instruction tracing or vulnerability detection; When the intermediate code corresponding to the translation block TB is executed, the test information of the closed source operating system is obtained through the target intermediate code; Among them, the tasks in the target task set are the test objects of the test cases.

2. The fuzz testing method for a closed source operating system according to claim 1, characterized in that: In the case where the target intermediate code is used for instruction tracing, inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG includes: The target intermediate code is inserted at the beginning of the intermediate code translated by the software simulation function module TCG.

3. The fuzz testing method for a closed source operating system according to claim 2, characterized in that: When the intermediate code corresponding to the translation block TB is executed, the test information of the closed-source operating system is obtained through the target intermediate code, including: Based on the starting address of the previous translation block TB and the starting address of the current translation block TB, determine whether the edge between the two translation blocks TB already exists in the edge set; If the edge between two translation blocks TB does not exist in the edge set, it is determined that a new edge cover is found; The edge set is used to store discovered edges, each element in the set is a unique identifier of an edge, and each element consists of the starting address of the source TB and the starting address of the target TB.

4. The fuzzy testing method for a closed source operating system according to claim 2, characterized in that: Before inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG, it also includes: Based on the target cache and the start address and code length of the translation block TB, determine whether the translation block TB has been translated; If the translation block TB has not been translated, it is determined that a new block coverage is found, and the starting address and code length of the translation block TB are recorded in the target cache to mark the translation block TB as having been translated; The target cache is used to store the starting address and code length of the translated translation block TB.

5. The fuzz testing method for a closed source operating system according to claim 1, characterized in that: In the case where the target intermediate code is used for vulnerability detection, inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG includes: The target intermediate code is inserted into the intermediate code corresponding to a specific function of the translation block TB, where the specific function is a function including a memory access operation.

6. The fuzz testing method for a closed source operating system according to claim 5, characterized in that: When the intermediate code corresponding to the translation block TB is executed, the test information of the closed-source operating system is obtained through the target intermediate code, including: Read the parameters and return values ​​of a specific function call and update the contents of the shadow memory; Among them, the content in the shadow memory is used to verify the legality of the memory access operation. If the memory access operation is an illegal operation, the virtualization software QEMU is interrupted.

7. The fuzz testing method for a closed source operating system according to any one of claims 1 to 6, characterized in that: Also includes: Before the operating system executes task scheduling each time, it is determined whether the scheduled task is a task in the target task set. If the scheduled task is a task in the target task set, the software simulation function module TCG of the virtualization software QEMU is determined to run the scheduled task. Otherwise, the kernel-based virtual machine KVM of the virtualization software QEMU is determined to run the scheduled task.

8. A fuzzy testing device for a closed source operating system, characterized in that: include: The code insertion module is used for inserting the target intermediate code into the intermediate code translated by the software simulation function module TCG of the virtualization software QEMU when executing the test case for the tasks in the target task set, and obtaining the intermediate code corresponding to the translation block TB, and the target intermediate code is used for instruction tracing or vulnerability detection; A test information acquisition module, used to acquire test information of the closed source operating system through the target intermediate code when the intermediate code corresponding to the translation block TB is executed; Among them, the tasks in the target task set are the test objects of the test cases.

9. An electronic device, characterized in that: include: at least one memory for storing a computer program; At least one processor is used to execute the program stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program runs on a processor, the processor is caused to execute the method according to any one of claims 1 to 7.

Images