Fuzzy testing method and device for virtual equipment

Abstract

The invention provides a virtual device fuzz testing method and device, and the method comprises the steps: extracting the dependence information of a virtual device from an operating system drive program through a static analysis method; generating a behavior model of the virtual device based on the dependency information; and based on the behavior model, performing a fuzzy test on the virtual device. According to the method, the dependency information of the virtual equipment is extracted through static analysis, the equipment behavior model is generated by utilizing the dependency information, and automatic fuzzy testing is performed on the virtual equipment in combination with a fuzzy testing technology of dependency perception, so that the input space of the virtual equipment is fully explored from multiple dimensions, and hidden security problems in virtual equipment code implementation are mined; and an attacker is prevented from attacking the virtual machine monitor by using the vulnerability.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a virtual device fuzz testing method and apparatus. Background Art

[0002] Virtualization applications have penetrated into all aspects of production and life. As one of the key software for virtualization, the security of the virtual machine monitor has attracted much attention. Due to the complexity of the virtual machine monitor and its characteristics exposed on the attack surface, it has become a major target of security attacks.

[0003] Software fuzz testing is one of the most effective methods for discovering software security vulnerabilities at present. Early software fuzz testing techniques adopted black-box testing methods. Based on black-box fuzz testing tools, security researchers have also proposed grey-box fuzz testing tools. Grey-box fuzz testing tools utilize genetic algorithms to mutate and select randomly generated test cases, which can effectively improve the code coverage rate of the program under test and discover security vulnerabilities in the program under test. Therefore, security researchers have also applied grey-box fuzz testing tools to the fuzz testing of virtual devices.

[0004] However, existing virtual device fuzz testing methods are difficult to automatically extract complex dependencies inside and between messages, resulting in limited test coverage. Also, due to the particularity of bus-hidden devices, the difficulty of fuzz testing is relatively high. Moreover, current virtual device fuzz testing tools mostly rely on manual or semi-automatic methods to extract dependencies from specifications or source codes (such as Nyx-Spec and ViDeZZo), or extract them through program execution traces (such as MundoFuzz). These methods are difficult to be extended to more extensive scenarios. At the same time, the way of randomly generating input data lacks pertinence and cannot deeply explore the code space. Summary of the Invention

[0005] The present invention provides a virtual device fuzz testing method and apparatus to solve the defects of the complexity of dependency relationships, the particularity of bus-hidden devices, and the limitations of existing methods in the prior art. By automatically extracting the behavior model of virtual devices, the coverage rate and vulnerability discovery efficiency of virtual device fuzz testing are improved, and security testing in complex interaction scenarios is supported.

[0006] The present invention provides a virtual device fuzz testing method, including the following steps: Using static analysis methods, extract the dependency information of virtual devices from the operating system driver program; Based on the dependency information, generate the behavior model of the virtual device; Based on the behavior model, perform fuzz testing on the virtual device.

[0007] According to the virtual device fuzz testing method provided by the present invention, before extracting the dependency information of the virtual device, it is determined whether the virtual device is a bus-hidden device; If the virtual device is a bus-hidden device, the dependency information includes inter-message dependency, intra-message dependency, and state dependency; Correspondingly, the method of extracting the dependency information of the virtual device from the operating system driver by using the static analysis method specifically includes: Using the static analysis method to extract the inter-message dependency, intra-message dependency, and state dependency of the virtual device from the operating system driver; Among them, the inter-message dependency is obtained based on the analysis of the control flow graph and call graph of the driver; the intra-message dependency is extracted based on the constraint conditions and relationships between fields within a single message in the driver; the state dependency is obtained by analyzing a specific function preset in the virtual device driver based on the interaction between the bus driver and the virtual device driver.

[0008] According to the virtual device fuzz testing method provided by the present invention, if the virtual device is a non-bus-hidden device, the dependency information includes inter-message dependency and intra-message dependency; Correspondingly, the method of extracting the dependency information of the virtual device from the operating system driver by using the static analysis method specifically includes: Using the static analysis method to extract the inter-message dependency and intra-message dependency of the virtual device from the operating system driver.

[0009] According to the virtual device fuzz testing method provided by the present invention, if the virtual device is a bus-hidden device, the behavior model of the virtual device includes an inter-message dependency graph, an intra-message dependency graph, and a state dependency graph; Correspondingly, generating the behavior model of the virtual device based on the dependency information specifically includes: Analyzing the control flow graph and call graph of the driver to obtain the execution order of each message; based on the execution order of each message, generating an inter-message dependency graph; Adopting the static taint analysis method to extract the constraint conditions and relationships between fields within a single message from the driver, and using an expression tree to represent the calculation rules of the values of the fields within a single message, generating an intra-message dependency graph; Obtaining the interaction information between the bus driver and the device driver, based on the interaction information and the analysis results of the preset specific function, dividing the states of the virtual device, recording the transition rules and dependency information of the virtual device in different states, and generating a state dependency graph.

[0010] According to the virtual device fuzz testing method provided by the present invention, if the virtual device is a non-bus hidden device, the behavior model of the virtual device includes an inter-message dependency graph and an intra-message dependency graph; Correspondingly, generating the behavior model of the virtual device based on the dependency information specifically includes: Analyze the control flow graph and call graph of the driver to obtain the execution order of each message; based on the execution order of each message, generate an inter-message dependency graph; Adopt the static taint analysis method to extract the constraint conditions and inter-field relationships of the internal fields of a single message from the driver, and use an expression tree to represent the calculation rules of the internal field values of a single message, generating an intra-message dependency graph.

[0011] According to the virtual device fuzz testing method provided by the present invention, performing fuzz testing on the virtual device based on the behavior model specifically includes: Generate a basic test case based on the behavior model of the virtual device; Mutate the basic test case to obtain a mutated test case; Perform fuzz testing on the virtual device based on the basic test case and the mutated test case to obtain a fuzz testing result.

[0012] According to the virtual device fuzz testing method provided by the present invention, if the virtual device is a bus hidden device, generating a basic test case based on the behavior model specifically includes: Generate test inputs at the message level based on the inter-message dependency graph and the intra-message dependency graph, where the test inputs at the message level are single virtual device messages, and the single virtual device message includes an IO message and a DMA message. The IO message generates an address and size field randomly and generates a written value based on an expression tree, and the expression tree is obtained according to the intra-message dependency analysis and is used to describe the calculation rules of the field values, and the expression tree is used to ensure that the generated field values of the IO message conform to the intra-message field constraint conditions and inter-field relationships; the DMA message generates a DMA buffer and fills the content of the DMA buffer according to the inter-message dependency, combined with the intra-message dependency information, and the intra-message dependency is used to ensure that the field content of the DMA message meets the requirements of the virtual device for DMA operations; Based on the intra-message dependency graph, by analyzing the control flow graph and call graph of the driver, randomly select one or more control flow paths to generate test inputs at the sequence level that cover the function call sequence; Generate test inputs at the state level according to the state dependency graph. The test inputs at the state level are message sequences that cover the complete semantics and state transitions of the virtual device, span multiple functions, and conform to the corresponding state constraints, and are used to verify whether the behavior of the virtual device in different states is correct.

[0013] According to the virtual device fuzz testing method provided by the present invention, the mutation of the basic test cases specifically includes: For test inputs at the message level, modify the field values or message structure in a single virtual device message, recalculate the field values based on the dependencies within the message to meet the new constraint conditions, or modify the field content while maintaining the buffer structure to generate mutated test inputs for the message level. For test inputs at the sequence level, perform combinatorial adjustment on the message sequence, and generate a new message sequence based on the dependencies between messages to ensure that the sequence order conforms to the device specification, and generate mutated test inputs for the sequence level. For test inputs at the state level, combine the state dependency information, restrict the compilation operations at the message level and sequence level, and regenerate valid inputs that meet the constraints in the current state.

[0014] According to the virtual device fuzz testing method provided by the present invention, if the virtual device is a non-bus-hidden device, the generation of basic test cases based on the behavior model specifically includes: Generate test inputs at the message level based on the inter-message dependency graph and the intra-message dependency graph. Among them, the test inputs at the message level are single virtual device messages, and the single virtual device messages include IO messages and DMA messages. The IO messages generate random address and size fields, and generate the written values based on the expression tree. The expression tree is obtained according to the analysis of the intra-message dependencies and is used to describe the calculation rules of the field values. The expression tree is used to ensure that the field values of the generated IO messages conform to the intra-message field constraint conditions and the relationships between fields; the DMA messages generate a DMA buffer and fill the content of the DMA buffer according to the inter-message dependencies, combined with the intra-message dependency information. The intra-message dependencies are used to ensure that the field content of the DMA messages meets the requirements of the virtual device for DMA operations. Based on the intra-message dependency graph, randomly select one or more control flow paths by analyzing the control flow graph and call graph of the driver, and generate test inputs at the sequence level that cover the function call sequence.

[0015] According to the virtual device fuzz testing method provided by the present invention, the mutation of the basic test cases specifically includes: For test inputs at the message level, modify the field values or message structure in a single virtual device message, recalculate the field values based on the dependencies within the message to meet the new constraints, or modify the field content while maintaining the buffer structure to generate mutant test inputs for the message level; For test inputs at the sequence level, perform combinatorial adjustments on the message sequence and generate a new message sequence based on the dependencies between messages to ensure that the sequence order complies with the device specifications, thereby generating mutant test inputs for the sequence level.

[0016] According to the virtual device fuzz testing method provided by the present invention, based on the basic test cases and the mutant test cases, performing fuzz testing on the virtual device specifically includes: Running the basic test cases and the mutant test cases in a virtualized environment through a specific virtual machine monitor to explore the code space of the virtual device; During the testing process, provide dependency information for the test inputs by initializing the device behavior model; Generate and load a message sequence, run the interaction of the virtual device, and record the test results.

[0017] According to the virtual device fuzz testing method provided by the present invention, after performing fuzz testing on the virtual device based on the basic test cases and the mutant test cases and obtaining the fuzz testing results, the method further includes: Run the basic test cases and the mutant test cases, and capture the abnormal behaviors of the virtual device, where the abnormal behaviors include memory leaks, crash signals, and undefined behaviors; Capture the memory problems of the virtual device, and simultaneously monitor potential vulnerabilities of the closed-source device through crash signals; For the abnormal results captured during the fuzz testing process, optimize the test case generation strategy through analysis and feedback, further adjust the device behavior model, and generate more targeted test cases to improve the code coverage rate and the vulnerability mining efficiency.

[0018] According to the virtual device fuzz testing method provided by the present invention, the optimization of the test case generation strategy through analysis and feedback specifically includes: Collect the code coverage information of the virtual device during the testing process through instrumentation technology and feedback it to the fuzz testing engine to optimize the generation strategy of subsequent test cases through the fuzz testing engine.

[0019] The present invention also provides a virtual device fuzz testing apparatus, including the following modules: A dependency information acquisition module, configured to extract the dependency information of the virtual device from the operating system driver using a static analysis method; A behavior model generation module, configured to generate a behavior model of the virtual device based on the dependency information; A fuzz testing module, configured to perform fuzz testing on the virtual device based on the behavior model.

[0020] The present invention further provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the virtual device fuzz testing method described in any one of the above is implemented.

[0021] The present invention further provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the virtual device fuzz testing method described in any one of the above is implemented.

[0022] The present invention further provides a computer program product, including a computer program. When the computer program is executed by a processor, the virtual device fuzz testing method described in any one of the above is implemented.

[0023] The virtual device fuzz testing method and device provided by the present invention use a static analysis method to extract the dependency information of the virtual device from the operating system driver; generate a behavior model of the virtual device based on the dependency information; and perform fuzz testing on the virtual device based on the behavior model. The present invention extracts the dependency information of the virtual device through static analysis, generates a device behavior model using the dependency information, and combines the dependency-aware fuzz testing technology to perform automated fuzz testing on the virtual device, fully exploring the input space of the virtual device from multiple dimensions, mining hidden security problems in the virtual device code implementation, and preventing attackers from launching attacks on the virtual machine monitor using vulnerabilities. Description of the Drawings

[0024] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0025] Figure 1 is one of the flow diagrams of the virtual device fuzz testing method provided by the present invention.

[0026] Figure 2 is the second flow diagram of the virtual device fuzz testing method provided by the present invention.

[0027] Figure 3 is the flow diagram for constructing the message dependency graph provided by the present invention.

[0028] Figure 4 It is a schematic diagram of the construction process of the in-message dependency graph provided by the present invention.

[0029] Figure 5 It is a schematic diagram of the construction process of the state dependency graph provided by the present invention.

[0030] Figure 6 It is a schematic diagram of the structure of the virtual device fuzz testing device provided by the present invention.

[0031] Figure 7 It is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed implementation manners

[0032] To make the objectives, technical solutions and advantages of the present invention clearer, the technical solutions in the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present invention without making creative efforts shall fall within the protection scope of the present invention.

[0033] The present invention will be specifically described below in conjunction with the accompanying drawings of the specification. The specific operation methods in the method embodiments can also be applied to the device embodiments or system embodiments. In the description of the present invention, unless otherwise specified, "at least one" includes one or more. "Multiple" means two or more. For example, at least one of A, B, and C includes: A alone, B alone, A and B existing simultaneously, A and C existing simultaneously, B and C existing simultaneously, and A, B, and C existing simultaneously. In the present invention, " / " means "or". For example, A / B may represent A or B; herein, "and / or" is only a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0034] In practical applications, with the advent of the information age, virtualization applications have penetrated into all aspects of production and life. Especially with the rapid development of cloud platforms, people are increasingly concerned about the security of virtualization. The virtual machine monitor is one of the key software in virtualization and is the core software abstraction layer between the virtual machine and the underlying hardware, and its security has also attracted much attention. The complexity of the virtual machine monitor and its characteristics exposed on the attack surface make it the main target of security attacks. For example, an attacker may use maliciously constructed virtual device messages to trigger code execution vulnerabilities, information leakage vulnerabilities, or virtual machine escape vulnerabilities in the virtual machine monitor.

[0035] Software fuzz testing is one of the most effective methods for discovering software security vulnerabilities at present and is adopted by a large number of software development companies and security technology companies. Software fuzz testing is a technology that tests software by inputting data randomly generated by a fuzz testing tool into the software program. Early software fuzz testing technologies adopted the black-box testing method, that is, without any feedback mechanism, relying solely on the crash of the program under test to judge the effectiveness of the test cases generated by the fuzz testing tool. Later, researchers proposed code sanitizers such as AddressSanitizer, which can detect more program memory safety violations in addition to program crashes, and thus provide feedback on the test cases generated by the fuzz testing tool more effectively. At the same time, based on black-box fuzz testing tools, security researchers have also proposed grey-box fuzz testing tools. Specifically, grey-box fuzz testing tools instrument the software program at the source code level, so that the code coverage of the software program under test can be obtained during the testing process, and then the code coverage is used to guide the fuzz testing tool to mutate the randomly generated seeds. Grey-box fuzz testing tools use this genetic algorithm to mutate and select the randomly generated test cases, which can effectively improve the code coverage of the program under test and discover security vulnerabilities in the program under test.

[0036] Due to the simplicity and ease of use of grey-box fuzz testing tools, they are more popular among security researchers. Recently, security researchers have also applied this kind of tool to the fuzz testing of virtual devices. However, the fuzz testing of virtual devices still faces the following challenges: (1) Complexity of dependency relationships: Virtual device messages have a structured nature, and not only need to meet the field constraints within the message, but also need to follow the sequential dependencies between messages. Current fuzz testing methods are difficult to automatically extract these complex dependency relationships, resulting in limited test coverage.

[0037] (2) Particularity of bus-hidden devices: The interfaces of some virtual devices (such as virtio devices or virtual USB devices) are hidden behind the corresponding buses and cannot be directly accessed. Testing these devices requires indirect interaction through the bus, and the state dependencies of the devices (such as different constraint conditions in the initialization phase and the transmission phase) are usually not clearly recorded in the specification, increasing the difficulty of fuzz testing.

[0038] (3) Limitations of current methods: Current virtual device fuzz testing tools mostly rely on manual or semi-automatic methods to extract dependency relationships from specifications or source codes (such as Nyx-Spec and ViDeZZo), or extract them through program execution traces (such as MundoFuzz). These methods are difficult to scale to more extensive scenarios. At the same time, the way of randomly generating input data lacks pertinence and cannot deeply explore the code space.

[0039] To solve the above problems, the present invention designs and implements a virtual device fuzz testing scheme based on automatically generating a device behavior model. By statically analyzing to extract the dependency information of the virtual device, and using this information to generate a device behavior model, it can be used to perform automated fuzz testing on the virtual device, discover hidden security problems in the virtual device code implementation, and prevent attackers from launching attacks on the virtual machine monitor using vulnerabilities.

[0040] In some specific implementation manners of the present invention, as Figure 1 shown, this scheme provides a virtual device fuzz testing method, including the following steps: Step 100: Use a static analysis method to extract the dependency information of the virtual device from the operating system driver program; Step 200: Generate a behavior model of the virtual device based on the dependency information; Step 300: Perform fuzz testing on the virtual device based on the behavior model.

[0041] It should be noted that existing fuzz testing schemes cannot automatically extract complex intra-message and inter-message dependency relationships, resulting in limited test coverage; and usually rely on manual or semi-automatic methods to extract dependency relationships from specifications or source codes, which is rather cumbersome to operate. Moreover, the method of randomly generating input data lacks pertinence, cannot deeply explore the code space, and is difficult to be extended to more extensive scenarios. Therefore, existing virtual device fuzz testing faces challenges such as the complexity of dependency relationships, the particularity of bus-hidden devices, and the limitations of existing methods.

[0042] Therefore, the present invention obtains the dependency information of the virtual device, generates a behavior model of the virtual device according to the dependency information, and performs fuzz testing on the virtual device, which can not only significantly improve the code coverage rate, but also discover more potential vulnerabilities in complex virtualization scenarios, and is of great significance for enhancing the security of the virtual machine monitor.

[0043] Specifically, aiming at the defects of the prior art, the present invention provides a virtual device fuzz testing scheme based on a device behavior model. This scheme automatically extracts the behavior model of the virtual device, and combines with dependency-aware fuzz testing technology to fully explore the input space of the virtual device from multiple dimensions, and effectively discovers the security problems of the virtual device. The specific goal is to provide a method to extract inter-message dependencies, intra-message dependencies, and state dependency information of the virtual device from the operating system driver program, improve the coverage rate and vulnerability discovery efficiency of virtual device fuzz testing, and at the same time adapt to closed-source virtual devices and bus-hidden devices, and support security testing in complex interaction scenarios.

[0044] The above steps will be described in detail below through specific embodiments.

[0045] In some possible embodiments of the present invention, before extracting the dependency information of the virtual device, it is determined whether the virtual device is a bus-hidden device; If the virtual device is a bus-hidden device, the dependency information includes inter-message dependency, intra-message dependency, and state dependency; Correspondingly, the method for extracting the dependency information of the virtual device from the operating system driver by using the static analysis method specifically includes: Using the static analysis method, extract the inter-message dependency, intra-message dependency, and state dependency of the virtual device from the operating system driver; Among them, the inter-message dependency is obtained based on the analysis of the control flow graph and call graph of the driver; the intra-message dependency is extracted based on the constraint conditions and relationships between fields within a single message in the driver; the state dependency is obtained by analyzing a specific function preset in the virtual device driver based on the interaction between the bus driver and the virtual device driver.

[0046] Specifically, this embodiment provides an implementation manner for extracting dependency information for a bus-hidden device. By extracting the inter-message dependency, intra-message dependency, and state dependency of the virtual device from the operating system driver, this dependency information can automatically generate a device behavior model and provide an input basis for the fuzz testing engine.

[0047] It can be understood that this setting of the present invention fully considers the particularity of the bus-hidden device, combines the interaction between the bus driver and the device driver, and extracts the state dependency information by analyzing a specific function.

[0048] In some possible embodiments of the present invention, if the virtual device is a non-bus-hidden device, the dependency information includes inter-message dependency and intra-message dependency; Correspondingly, the method for extracting the dependency information of the virtual device from the operating system driver by using the static analysis method specifically includes: Using the static analysis method, extract the inter-message dependency and intra-message dependency of the virtual device from the operating system driver.

[0049] Specifically, this embodiment provides an implementation manner for extracting dependency information for a non-bus-hidden device. Compared with the bus-hidden device, the dependency information of the non-bus-hidden device includes inter-message dependency and intra-message dependency, and is also obtained by the method of extraction from the operating system driver by static methods. This dependency information can automatically generate a device behavior model and provide an input basis for the fuzz testing engine.

[0050] With the above settings in the embodiments of the present invention, the device behavior model is extracted from the open-source operating system driver through static analysis, without relying on the virtual device source code. Through the automated generation of the device behavior model, the automated adaptation of multiple virtual device types is achieved.

[0051] In some possible embodiments of the present invention, if the virtual device is a bus-hidden device, the behavior model of the virtual device includes an inter-message dependency graph, an intra-message dependency graph, and a state dependency graph; Correspondingly, generating the behavior model of the virtual device based on the dependency information specifically includes: Analyze the control flow graph and call graph of the driver to obtain the execution order of each message; based on the execution order of each message, generate an inter-message dependency graph; Adopt the static taint analysis method to extract the constraint conditions and inter-field relationships of the internal fields of a single message from the driver, and use an expression tree to represent the calculation rules of the internal field values of a single message, generating an intra-message dependency graph; Obtain the interaction information between the bus driver and the device driver, based on the interaction information and the analysis results of preset specific functions, divide the states of the virtual device, record the transition rules and dependency information of the virtual device in different states, and generate a state dependency graph.

[0052] Specifically, this embodiment provides an implementation manner of the behavior model of the bus-hidden device. The behavior model of the bus-hidden device includes an inter-message dependency graph, an intra-message dependency graph, and a state dependency graph. The generation process coverage rate of the device behavior model covers the complete operation semantics from device initialization to multi-state transition, providing the necessary dependency information support for the generation and mutation of subsequent fuzz test test cases.

[0053] In some possible embodiments of the present invention, if the virtual device is a non-bus-hidden device, the behavior model of the virtual device includes an inter-message dependency graph and an intra-message dependency graph; Correspondingly, generating the behavior model of the virtual device based on the dependency information specifically includes: Analyze the control flow graph and call graph of the driver to obtain the execution order of each message; based on the execution order of each message, generate an inter-message dependency graph; Adopt the static taint analysis method to extract the constraint conditions and inter-field relationships of the internal fields of a single message from the driver, and use an expression tree to represent the calculation rules of the internal field values of a single message, generating an intra-message dependency graph.

[0054] Specifically, this embodiment provides an implementation manner of the behavior model of the non-bus-hidden device. Compared with the bus-hidden device, the behavior model of the non-bus-hidden device includes an inter-message dependency graph and an intra-message dependency graph.

[0055] In the above settings for generating the device behavior model in the embodiments of the present invention, a static analysis tool is used to extract the behavior model of the virtual device from the open-source operating system driver. This model combines inter-message dependencies, intra-message dependencies, and state dependencies to provide comprehensive support for fuzz testing. Inter-message dependencies are extracted through the control flow graph and call graph, recording the interaction order of virtual device messages to generate an inter-message dependency graph for ensuring the correct execution order of message operations. Intra-message dependencies are extracted through static taint analysis, analyzing the field constraint conditions and relationships between fields within a single message to generate an expression tree to describe the calculation rules of field values, thereby constructing an intra-message dependency graph. State dependencies combine the interaction analysis of the bus driver and the device driver, extracting the device state transition rules by analyzing specific functions in the driver to generate a state dependency graph representing the state behavior during the life cycle of the virtual device. The generation process coverage of the device behavior model covers the complete operational semantics from device initialization to multi-state transitions, providing the necessary dependency information support for subsequent fuzz testing test case generation and mutation.

[0056] In some possible embodiments of the present invention, the fuzz testing of the virtual device based on the behavior model specifically includes: Generating a basic test case based on the behavior model of the virtual device; Mutating the basic test case to obtain a mutated test case; Based on the basic test case and the mutated test case, performing fuzz testing on the virtual device to obtain a fuzz testing result.

[0057] Specifically, this embodiment provides an implementation manner of fuzz testing a virtual device based on a behavior model. According to the behavior model of the virtual device, a basic test case for fuzz testing is obtained, and then this basic test case is mutated to obtain a mutated test case. The basic test case and the mutated test case are jointly used in the fuzz testing process of the virtual device. By generating dependency-sensitive test cases, various interaction methods of the virtual device are covered, and through dependency-aware mutation operations on the test inputs, the input space of the virtual device is explored in depth.

[0058] In some possible embodiments of the present invention, if the virtual device is a bus-hidden device, the generating of the basic test case based on the behavior model specifically includes: Generate test inputs at the message level based on the inter-message dependency graph and the intra-message dependency graph, where the test inputs at the message level are single virtual device messages, and the single virtual device message includes an IO message and a DMA message. The IO message generates the written value based on an expression tree by randomly generating the address and size fields. The expression tree is obtained according to the intra-message dependency analysis and is used to describe the calculation rules of the field values. The expression tree is used to ensure that the field values of the generated IO message comply with the intra-message field constraint conditions and the inter-field relationships. The DMA message is obtained by generating a DMA buffer and filling the content of the DMA buffer according to the inter-message dependency, in combination with the intra-message dependency information. The intra-message dependency is used to ensure that the field content of the DMA message meets the requirements of the virtual device for DMA operations. Based on the intra-message dependency graph, randomly select one or more control flow paths by analyzing the control flow graph and call graph of the driver program, and generate test inputs at the sequence level that cover the function call sequence. Generate test inputs at the state level according to the state dependency graph. The test inputs at the state level are message sequences that cover the complete semantics and state transitions of the virtual device, span multiple functions, and comply with the corresponding state constraints, and are used to verify whether the behavior of the virtual device in different states is correct.

[0059] Specifically, this embodiment provides an implementation manner for a bus-hidden device to generate basic test cases based on a behavior model. Based on the device behavior model, test cases are generated at four granularities to cover various interaction modes of the virtual device.

[0060] In a possible embodiment, for test case generation, specifically based on the device behavior model, test cases are generated at four granularities through a generator module to cover various interaction modes of the virtual device. At the message level, a single virtual device message is generated, including an IO message and a DMA message. For the IO message, the address and size fields are randomly generated, and the written value is generated in combination with the expression tree. For the DMA message, a DMA buffer is generated and the content of the buffer is filled according to the inter-field dependency. At the function level, test inputs that cover the function call sequence are generated by randomly selecting the inter-procedural control flow paths of the driver program to explore the message dependencies inside the function. At the state level, test inputs based on the state dependency graph are generated, covering message sequences that span multiple functions to ensure coverage of the complete semantics and state transitions of the device.

[0061] In some possible implementation manners of the present invention, the mutation of the basic test cases specifically includes: For test inputs at the message level, modify the field values or message structure in a single virtual device message, recalculate the field values based on the dependencies within the message to meet the new constraints, or modify the field content while maintaining the buffer structure to generate mutant test inputs at the message level; For test inputs at the sequence level, perform combinatorial adjustments on the message sequence and generate a new message sequence based on the dependencies between messages to ensure that the sequence order conforms to the device specification, generating mutant test inputs at the sequence level; For test inputs at the state level, combine the state dependency information, restrict the compilation operations at the message level and sequence level, and regenerate valid inputs that meet the constraints in the current state.

[0062] Specifically, this embodiment provides an implementation manner for a bus-hidden device to generate mutant test cases, and explores the code space of the virtual device through the mutation of three different levels of test inputs.

[0063] In a possible embodiment, for test case mutation, specifically, the device behavior model is utilized, and the mutator module performs dependency-aware mutation operations on the test inputs to deeply explore the input space of the virtual device. Message-level mutation modifies the field values or structure in a single message, such as changing the address or value of an IO message, and recalculates the value based on the dependencies within the message to meet the constraints. For DMA messages, the field content is modified while maintaining the buffer structure to detect potential problems. Sequence-level mutation performs combinatorial adjustments on the message sequence, such as inserting new messages, deleting messages, or shuffling the message order, and generates a new message sequence based on the dependencies between messages to ensure that the sequence order conforms to the device specification. State-level mutation restricts the message-level and sequence-level compilation operations by combining the state dependency information and generates valid inputs only in the current state. For example, in different states, MMIO write messages at the same offset may have different constraints, and state-level mutation will regenerate values that meet the constraints according to the state.

[0064] In some possible implementation manners of the present invention, if the virtual device is a non-bus-hidden device, generating the basic test cases based on the behavior model specifically includes: Generate test inputs at the message level based on the inter-message dependency graph and the intra-message dependency graph, where the test inputs at the message level are single virtual device messages, and the single virtual device message includes an IO message and a DMA message. The IO message generates the written value based on an expression tree by randomly generating address and size fields. The expression tree is obtained from the intra-message dependency analysis and is used to describe the calculation rules of field values. The expression tree is used to ensure that the field values of the generated IO message conform to the intra-message field constraint conditions and the relationships between fields. The DMA message is obtained by generating a DMA buffer and filling the content of the DMA buffer according to the inter-message dependency, combined with the intra-message dependency information. The intra-message dependency is used to ensure that the field content of the DMA message meets the requirements of the virtual device for DMA operations. Based on the intra-message dependency graph, randomly select one or more control flow paths by analyzing the control flow graph and call graph of the driver, and generate test inputs at the sequence level that cover the function call sequence.

[0065] Specifically, this embodiment provides an implementation manner for a non-bus-hidden device to generate basic test cases based on a behavior model. Compared with a bus-hidden device, the non-bus-hidden device generates test cases at four granularities based on the device behavior model. By generating test inputs at the message level and test inputs at the sequence level, various interaction modes of the virtual device are covered.

[0066] In some possible implementation manners of the present invention, the mutating of the basic test cases specifically includes: For the test inputs at the message level, modify the field values or message structure in a single virtual device message, recalculate the field values based on the intra-message dependency to meet the new constraint conditions, or modify the field content while maintaining the buffer structure to generate mutating test inputs at the message level. For the test inputs at the sequence level, perform combinatorial adjustment on the message sequence, and generate a new message sequence according to the inter-message dependency to ensure that the sequence order conforms to the device specification, and generate mutating test inputs at the sequence level.

[0067] Specifically, this embodiment provides an implementation manner for a non-bus-hidden device to generate mutating test cases. By mutating two different levels of test inputs, the code space of the virtual device is explored.

[0068] It should be noted that the generation methods of the test inputs at the message level and sequence level involved in the non-bus-hidden device are the same as those of the test inputs at these two levels involved in the bus-hidden device. For the introduction of the generation methods of the test inputs at the message level and sequence level, reference can be made to the above, and details will not be elaborated here.

[0069] With the above settings in the embodiments of the present invention, by simulating the main functions of virtual devices and supporting the complex interaction structures of bus-hidden devices, the complete life cycle of virtual devices from initialization to transmission is covered, achieving comprehensive support for complex interaction scenarios.

[0070] In some possible embodiments of the present invention, performing fuzz testing on the virtual device based on the basic test cases and the mutant test cases specifically includes: Running the basic test cases and the mutant test cases in a virtualized environment through a specific virtual machine monitor to explore the code space of the virtual device; During the testing process, by initializing the device behavior model, dependency information is provided for the test input; By generating and loading a message sequence, running the interaction of the virtual device and recording the test results.

[0071] Specifically, this embodiment provides an implementation manner of performing fuzz testing on a virtual device based on basic test cases and mutant test cases. By running the generated and mutant test cases, the code space of the virtual device is explored.

[0072] In possible embodiments, for the execution of test cases, it can be implemented through an executor. The executor depends on the implementation of a specific virtual machine monitor and runs in virtualization environments such as QEMU and VMware. During the testing process, the executor initializes the device behavior model through an interface to provide dependency information for the test input; generates and loads a message sequence through the interface, runs the virtual device interaction, and records the test results.

[0073] With the above settings in the embodiments of the present invention, it can be adapted to virtual machine monitors implemented in different languages, and efficient test cases can be generated without manual intervention. Therefore, it has strong generality and adaptability.

[0074] In some possible embodiments of the present invention, after performing fuzz testing on the virtual device based on the basic test cases and the mutant test cases and obtaining the fuzz testing results, the method further includes: Running the basic test cases and the mutant test cases and capturing the abnormal behaviors of the virtual device. The abnormal behaviors include memory leaks, crash signals, and undefined behaviors; Capturing the memory problems of the virtual device and simultaneously monitoring potential vulnerabilities of closed-source devices through crash signals; For the abnormal results captured during the fuzz testing process, by analyzing the feedback, optimizing the test case generation strategy, further adjusting the device behavior model, and generating more targeted test cases to improve the code coverage rate and the vulnerability mining efficiency.

[0075] Specifically, this embodiment provides an implementation manner for anomaly detection and feedback during fuzz testing. Through anomaly detection and feedback, the abnormal behaviors of virtual devices are captured, and the test case generation strategy is optimized through analysis and feedback.

[0076] In a possible embodiment, for anomaly detection, when running test cases, the abnormal behaviors of virtual devices are captured, including memory leaks, crash signals, undefined behaviors, etc. For open-source devices, kernel security tools such as ASAN (AddressSanitizer) are used to capture memory problems; for closed-source devices, potential vulnerabilities are monitored through crash signals. For feedback collection, the captured anomaly results are collected and analyzed, and these anomaly information includes specific error types, test cases where anomalies occur, device states at the time of anomalies, etc.

[0077] Furthermore, for the captured anomaly results, the test case generation strategy is optimized through analysis and feedback, the device behavior model is further adjusted, and more targeted test cases are generated, thereby improving code coverage and vulnerability mining efficiency.

[0078] In some possible implementation manners of the present invention, the optimizing the test case generation strategy through analysis and feedback specifically includes: Collecting the code coverage information of the virtual device during the test process through instrumentation technology and feeding it back to the fuzz testing engine to optimize the generation strategy of subsequent test cases through the fuzz testing engine.

[0079] Specifically, this embodiment provides an implementation manner for optimizing the test case generation strategy through analysis and feedback.

[0080] Specifically, analyzing and feedback to optimize the test case generation strategy includes the following aspects: The first aspect is to adjust the generation strategy based on the anomaly type: For memory problems: If memory problems such as frequent memory leaks or out-of-bounds access are detected, analyze which types of test cases (such as specific message structures, specific state transition paths, etc.) are more likely to trigger these problems. In the subsequent generation of test cases, increase the generation probability of such test cases, or make more detailed adjustments to the generation range and dependency relationships of relevant field values, etc., to make it more likely to trigger memory-related vulnerabilities.

[0081] For crash signals: For test cases that cause the device to crash, analyze the code location and execution path where the crash occurs. If it is found that certain specific function call sequences or message interaction orders are more likely to trigger crashes, then when generating test cases subsequently, focus on exploring the code space near these critical paths, and generate more targeted test cases by increasing the complexity of mutation operations or adjusting the combination of message sequences, so as to deeply dig out potential vulnerabilities.

[0082] Second aspect, optimize the generation strategy according to the device status: State coverage analysis: Statistically analyze the execution status and exception occurrence rate of test cases in different states. If it is found that the coverage rate of test cases in certain states is relatively low or the number of exceptions is small, it indicates that the code space in these states may not have been fully explored. When generating test cases subsequently, increase the generation weight of test cases for these states and increase the frequency of state-level mutation operations to ensure that more test cases covering these states can be generated, thereby improving the overall state coverage rate.

[0083] State transition path optimization: Analyze the performance of test cases during the state transition process and find out the state transition paths that are prone to exceptions. When generating test cases subsequently, focus on mutating and exploring these critical paths. For example, by adjusting the timing, order, or content of message sending, simulate different state transition scenarios to detect potential security issues.

[0084] Third aspect, adjust the strategy according to the effectiveness of test cases: Evaluate the effectiveness of test cases: Evaluate the executed test cases, and analyze which test cases can effectively trigger behavior changes or exceptions in the device, and which test cases have poor effects. For effective test cases, extract their key features, such as specific field value combinations, message sequence patterns, etc.

[0085] Optimize generation parameters and algorithms: According to the characteristics of effective test cases, adjust the parameter settings and algorithm logic of the test case generator. For example, if it is found that field values within a certain specific range are more likely to trigger exceptions, then when generating test cases subsequently, tilt the generation range of this field value towards this effective interval; or optimize the algorithm of sequence-level mutation operations according to the message sequence pattern of effective test cases, so that it can generate more similar test case sequences with potential risks.

[0086] Fourth aspect, continuous iteration and optimization: Iteration process: Apply the optimized test case generation strategy to the generation and execution of a new round of test cases, collect exception feedback again and analyze it. Through continuous iteration, gradually improve the test case generation strategy so that it can generate effective test cases more accurately, and improve the efficiency and accuracy of vulnerability mining.

[0087] Dynamic adjustment: During the entire testing process, dynamically adjust the test case generation strategy based on factors such as updates to the virtual device code, newly discovered vulnerability types, and changes in the test environment. Ensure that the test cases can always keep up with the latest state of the virtual device and continuously and effectively discover potential security issues.

[0088] The above settings of the present invention, by developing an automated and general virtual device fuzz testing method to efficiently extract the message dependencies of the virtual device and adapt to the state dependencies of the bus hidden device, can not only significantly improve the code coverage rate, but also discover more potential vulnerabilities in complex virtualization scenarios, which is of great significance for enhancing the security of the virtual machine monitor.

[0089] The core of the present invention is to perform flow-sensitive, path-sensitive, and domain-sensitive static analysis, extract the inter-message, intra-message, and state dependency information of the virtual device, and generate a device behavior model. Based on the generated device behavior model, the present invention performs dependency-sensitive fuzz testing on the virtual device, including processes such as dependency-sensitive test case generation and dependency-sensitive test case mutation.

[0090] In some specific embodiments of the present invention, as Figure 2 shown, the present solution provides the specific process of the virtual device fuzz testing method. The virtual device fuzz testing method can be specifically implemented through two modules: a device behavior model generation module and a dependency-sensitive fuzz testing module. Among them, the device behavior model generation module is specifically to use static analysis technology to extract the behavior model of the virtual device from the open-source operating system driver; the dependency-sensitive fuzz testing module is specifically to perform dependency-aware fuzz testing on the virtual device based on the generated device behavior model, explore the code space of the device, and discover potential vulnerabilities.

[0091] Specifically, the main objective of the device behavior model generation module is to extract the behavior model of the virtual device from the open-source operating system driver to provide complete dependency information support for fuzz testing. Its implementation method includes two steps of driver information extraction: Step 1. Driver information extraction: Specifically, during the driver information extraction process, it is first necessary to convert the driver source code into an intermediate file format suitable for static analysis. The embodiment of the present invention adopts the LLVM bitcode format. The specific implementation method includes: replacing the compilation and linking process of the kernel, compiling multiple source files of the driver into LLVM bitcode files, and further linking them into a single file to support overall analysis; disabling the optimization option ("-O0") during the compilation process to ensure that the original code structure is retained to improve the analysis accuracy.

[0092] On this basis, relevant information about the virtual device behavior is extracted from the intermediate file by a static analysis tool, which is divided into the following three parts: Inter-message dependency extraction: By analyzing the control flow graph (CFG) and call graph (CG) of the driver, the execution order of messages is recorded and an inter-message dependency graph is generated to ensure that the interaction of virtual device messages complies with the specifications, as Figure 3 shown.

[0093] Intra-message dependency extraction: Static taint analysis is adopted to extract the constraint conditions of internal fields and the relationships between fields in a single message from the driver, and an expression tree is used to represent the calculation rules of field values, generating an intra-message dependency graph, as Figure 4 shown.

[0094] State dependency extraction: Combining the interaction between the bus driver and the device driver, by analyzing specific functions (such as probe and resume), the states of the device are divided, and the dependency information of each state is recorded to generate a state dependency graph, as Figure 5 shown.

[0095] Step 2: Generate the device behavior model: Specifically, based on the three types of extracted dependency information, a behavior model (DBM) of the virtual device is comprehensively generated. This model includes an inter-message dependency graph, an intra-message dependency graph, and a state dependency graph, providing multi-granularity dependency information support for subsequent fuzz testing.

[0096] Furthermore, the dependency-sensitive fuzz testing module specifically conducts dependency-sensitive fuzz testing on the virtual device by utilizing the device behavior model, exploring the code space of the device and discovering potential vulnerabilities. Its implementation includes two steps: Step 1: Generate and mutate test cases: Use a fuzz testing engine to generate multi-granularity test cases based on the device behavior model, including message-level generation: generating single messages (such as IO messages, DMA messages) to ensure that the field values comply with the constraints of intra-message dependencies; sequence-level generation: generating message sequences according to the inter-message dependency graph to explore the interaction relationships between messages; state-level generation: generating test cases across multiple states based on the state dependency graph to cover the complete life cycle of the device.

[0097] Step 2: Coverage feedback and anomaly detection: Collect the code coverage information of the virtual device during the test process through instrumentation technology and feedback it to the fuzz testing engine for optimizing the generation strategy of subsequent test cases. At the same time, use ASAN to capture the memory problems of the virtual device and record the crash signals to discover potential vulnerabilities.

[0098] The overall idea of the present invention is to extract the device behavior model from the operating system driver through static analysis technology, and comprehensively test the virtual device in combination with the dependency-aware fuzz testing technology. The combination of the generation of the device behavior model and the dependency-sensitive fuzz testing effectively improves the coverage rate and efficiency of virtual device vulnerability mining. On this basis, those skilled in the art can improve and adjust the present invention according to specific application requirements.

[0099] In some specific embodiments of the present invention, as Figure 6 shown, the present solution provides a virtual device fuzz testing device, including the following modules: A dependency information acquisition module 61, configured to extract the dependency information of the virtual device from the operating system driver by using a static analysis method; A behavior model generation module 62, configured to generate a behavior model of the virtual device based on the dependency information; A fuzz testing module 63, configured to perform fuzz testing on the virtual device based on the behavior model.

[0100] For the virtual device fuzz testing device provided by the embodiment of the present invention, its implementation principle and beneficial effects are similar to those of the virtual device fuzz testing method shown in the above embodiment. For the implementation principle and beneficial effects of the virtual device fuzz testing method shown in the above embodiment, reference can be made, and details will not be described herein again.

[0101] Figure 7 An example of a schematic physical structure diagram of an electronic device is shown in Figure 7 shown. The electronic device may include: a processor (processor) 710, a communication interface (Communications Interface) 720, a memory (memory) 730, and a communication bus 740. Among them, the processor 710, the communication interface 720, and the memory 730 communicate with each other through the communication bus 740. The processor 710 can call the logical instructions in the memory 730 to execute the virtual device fuzz testing method, which includes: extracting the dependency information of the virtual device from the operating system driver by using a static analysis method; generating a behavior model of the virtual device based on the dependency information; and performing fuzz testing on the virtual device based on the behavior model.

[0102] In addition, when the logical instructions in the above-mentioned memory 730 are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0103] On the other hand, the present invention also provides a computer program product. The computer program product includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the virtual device fuzz testing method provided by the above-mentioned various methods. The method includes: using a static analysis method to extract the dependency information of the virtual device from the operating system driver; generating a behavior model of the virtual device based on the dependency information; and performing fuzz testing on the virtual device based on the behavior model.

[0104] In yet another aspect, the present invention also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it is implemented to execute the virtual device fuzz testing method provided by the above-mentioned various methods. The method includes: using a static analysis method to extract the dependency information of the virtual device from the operating system driver; generating a behavior model of the virtual device based on the dependency information; and performing fuzz testing on the virtual device based on the behavior model.

[0105] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without creative labor.

[0106] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the essence of the above technical solution, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0107] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A virtual device fuzzy testing method, characterized in that: include: Using static analysis methods, virtual device dependency information is extracted from operating system drivers; Based on the dependency information, generating a behavior model of the virtual device; Based on the behavior model, fuzz testing is performed on the virtual device.

2. The virtual device fuzzy testing method according to claim 1, characterized in that: Before extracting dependency information of a virtual device, determining whether the virtual device is a bus hidden device; If the virtual device is a bus hidden device, the dependency information includes inter-message dependency, intra-message dependency and state dependency; Correspondingly, the method of extracting dependency information of virtual devices from the operating system driver using a static analysis method specifically includes: Using static analysis methods, the inter-message dependency, intra-message dependency and state dependency of virtual devices are extracted from the operating system driver. Among them, the inter-message dependency is obtained based on the analysis of the control flow graph and call graph of the driver; the intra-message dependency is extracted based on the constraints and inter-field relationships of the internal fields of a single message in the driver; the state dependency is obtained based on the interaction between the bus driver and the virtual device driver, and the analysis of specific functions preset in the virtual device driver is performed.

3. The virtual device fuzzy testing method according to claim 2, characterized in that: If the virtual device is a non-bus hidden device, the dependency information includes inter-message dependency and intra-message dependency; Correspondingly, the method of extracting dependency information of virtual devices from the operating system driver using a static analysis method specifically includes: Static analysis methods are used to extract inter-message dependencies and intra-message dependencies of virtual devices from operating system drivers.

4. The virtual device fuzzy testing method according to claim 2, characterized in that: If the virtual device is a bus hidden device, the behavior model of the virtual device includes an inter-message dependency graph, an intra-message dependency graph, and a state dependency graph; Correspondingly, generating the behavior model of the virtual device based on the dependency information specifically includes: Analyze the control flow graph and call graph of the driver to obtain the execution order of each message; generate a message dependency graph based on the execution order of each message; Using static taint analysis method, the constraints and inter-field relationships of the internal fields of a single message are extracted from the driver, and the calculation rules of the internal field values ​​of a single message are represented by expression tree to generate the message dependency graph. The interaction information between the bus driver and the device driver is obtained, and based on the interaction information and the analysis result of the preset specific function, the state of the virtual device is divided, the conversion rules and dependency information of the virtual device in different states are recorded, and a state dependency graph is generated.

5. The virtual device fuzzy testing method according to claim 3, characterized in that: If the virtual device is a non-bus hidden device, the behavior model of the virtual device includes an inter-message dependency graph and an intra-message dependency graph; Correspondingly, generating the behavior model of the virtual device based on the dependency information specifically includes: Analyze the control flow graph and call graph of the driver to obtain the execution order of each message; generate a message dependency graph based on the execution order of each message; The static taint analysis method is used to extract the constraints and inter-field relationships of the internal fields of a single message from the driver, and the expression tree is used to represent the calculation rules of the internal field values ​​of a single message to generate an intra-message dependency graph.

6. The virtual device fuzzy testing method according to any one of claims 2 to 5, characterized in that: The performing fuzz testing on the virtual device based on the behavior model specifically includes: Based on the behavior model of the virtual device, generate basic test cases; Mutating the basic test case to obtain a mutated test case; Based on the basic test case and the variant test case, a fuzzy test is performed on the virtual device to obtain a fuzzy test result.

7. The virtual device fuzzy testing method according to claim 6, characterized in that: If the virtual device is a bus hidden device, generating a basic test case based on the behavior model specifically includes: Based on the inter-message dependency graph and the intra-message dependency graph, a message-level test input is generated, wherein the message-level test input is a single virtual device message, the single virtual device message includes an IO message and a DMA message, the IO message generates a written value by randomly generating address and size fields based on an expression tree, the expression tree is obtained based on an analysis of intra-message dependencies, and is used to describe calculation rules for field values, and the expression tree is used to ensure that the generated IO message field values ​​meet the field constraints and inter-field relationships within the message; the DMA message is obtained by generating a DMA buffer, and filling the DMA buffer with content based on inter-message dependencies, combined with the intra-message dependency information, and the intra-message dependency is used to ensure that the field content of the DMA message meets the requirements of the virtual device for DMA operations; Based on the intra-message dependency graph, by analyzing the control flow graph and call graph of the driver, one or more control flow paths are randomly selected to generate sequence-level test inputs covering the function call sequence; According to the state dependency graph, a state-level test input is generated. The state-level test input is a message sequence that covers the complete semantics and state transitions of the virtual device, spans multiple functions and conforms to corresponding state constraints, and is used to verify whether the behavior of the virtual device in different states is correct.

8. The virtual device fuzzy testing method according to claim 7, characterized in that: The mutating of the basic test case specifically includes: For message-level test input, modify the field value or message structure in a single virtual device message, recalculate the field value based on the dependency within the message to meet the new constraints, or modify the field content while maintaining the buffer structure to generate message-level mutation test input; For the test input at the sequence level, the message sequence is combined and adjusted, and a new message sequence is generated based on the dependencies between messages to ensure that the sequence order complies with the device specifications, and the mutation test input at the sequence level is generated; For the state-level test input, combined with the state dependency information, the compilation operations at the message level and sequence level are restricted, and valid input that meets the constraints is regenerated in the current state.

9. The virtual device fuzzy testing method according to claim 6, characterized in that: If the virtual device is a non-bus hidden device, generating a basic test case based on the behavior model specifically includes: Based on the inter-message dependency graph and the intra-message dependency graph, a message-level test input is generated, wherein the message-level test input is a single virtual device message, the single virtual device message includes an IO message and a DMA message, the IO message generates a written value by randomly generating address and size fields based on an expression tree, the expression tree is obtained based on an analysis of intra-message dependencies, and is used to describe calculation rules for field values, and the expression tree is used to ensure that the generated IO message field values ​​meet the field constraints and inter-field relationships within the message; the DMA message is obtained by generating a DMA buffer, and filling the DMA buffer with content based on inter-message dependencies, combined with the intra-message dependency information, and the intra-message dependency is used to ensure that the field content of the DMA message meets the requirements of the virtual device for DMA operations; Based on the intra-message dependency graph, by analyzing the control flow graph and call graph of the driver, one or more control flow paths are randomly selected to generate sequence-level test inputs covering function call sequences.

10. The virtual device fuzzy testing method according to claim 9, characterized in that: The mutating of the basic test case specifically includes: For message-level test input, modify the field value or message structure in a single virtual device message, recalculate the field value based on the dependency within the message to meet the new constraints, or modify the field content while maintaining the buffer structure to generate message-level mutation test input; For the test input at the sequence level, the message sequence is combined and adjusted, and a new message sequence is generated based on the dependencies between messages to ensure that the sequence order complies with the device specifications, and to generate mutation test input at the sequence level.

11. The virtual device fuzzy testing method according to claim 8 or 10, characterized in that: The performing fuzz testing on the virtual device based on the basic test case and the variant test case specifically includes: Running the basic test case and the variant test case in a virtualized environment through a specific virtual machine monitor to explore the code space of the virtual device; During the test, the device behavior model is initialized to provide dependency information for the test input; By generating and loading message sequences, the interaction of the virtual devices is run and the test results are recorded.

12. The virtual device fuzzy testing method according to claim 11, characterized in that: Based on the basic test case and the variant test case, after performing a fuzzy test on the virtual device and obtaining a fuzzy test result, the method further includes: Running the basic test cases and the variant test cases, and capturing abnormal behaviors of the virtual device, wherein the abnormal behaviors include memory leaks, crash signals, and undefined behaviors; Capture memory issues of the virtual device and monitor potential vulnerabilities of closed-source devices through crash signals; For the abnormal results captured during the fuzz testing process, the test case generation strategy is optimized by analyzing the feedback, and the device behavior model is further adjusted to generate more targeted test cases to improve code coverage and vulnerability mining efficiency.

13. The virtual device fuzzy testing method according to claim 12, characterized in that: The optimization of the test case generation strategy by analyzing feedback specifically includes: The code coverage information of the virtual device during the test is collected through the stub technology, and fed back to the fuzz testing engine so as to optimize the generation strategy of subsequent test cases through the fuzz testing engine.

14. A virtual device fuzzy testing device, characterized in that: include: A dependency information acquisition module is used to extract dependency information of virtual devices from operating system drivers using a static analysis method; A behavior model generating module, used for generating a behavior model of the virtual device based on the dependency information; A fuzzy testing module is used to perform fuzzy testing on the virtual device based on the behavior model.

Images