Vulnerability mining method and device and electronic equipment

Abstract

The invention provides a vulnerability mining method and device and electronic equipment, and relates to the technical field of computers. The method comprises the following steps: respectively carrying out program instrumentation processing on a plurality of target key functions of a to-be-mined drive program; controlling a user mode program to call a driving interface of the to-be-mined driving program, executing the multiple target key functions, skipping to a preset collection function based on instrumentation codes in the target key functions, and collecting execution traces of the target key functions based on the preset collection function; presuming attributes of input parameters of the driving interface according to actual parameters in the execution trace; presuming a cross drive interface according to the call stack in the execution trace; and generating a test case based on the attribute of the driving interface input parameter and the cross driving interface, and performing a fuzzy test on the to-be-mined driving program based on the test case to obtain a vulnerability mining report, so that a potential driving interface can be found to enhance the vulnerability mining effectiveness.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a vulnerability mining method, device and electronic device. Background Art

[0002] Fuzz testing technology is of great practical value in aspects such as software vulnerability mining. When applying fuzz testing technology, researchers usually need to analyze the input parameter format of the program under test, so as to guide the fuzzer to generate legal test cases according to this format, in order to comprehensively explore the code of the program under test and mine potential vulnerabilities.

[0003] In order to perform effective fuzz testing on a driver program, it is necessary to analyze the input format of the driver program. However, the input interface of the driver program is a system call, and the parameter types received cover handles, pointers, strings, constants, integers, etc. These parameters can be combined into complex structures, and then form diverse input parameter formats. At present, the input parameter format of the driver program when a user-mode program interacts with the driver program simply is mainly determined by the static correspondence relationship between the preset device object, driver interface and specific function. In the case where many operating systems allow drivers to register with each other, it is very likely to miss potential driver interfaces, reduce the effectiveness of the obtained driver program input parameter format, and further reduce the effectiveness of vulnerability mining. Summary of the Invention

[0004] Aiming at the problems existing in the prior art, the present invention provides a vulnerability mining method, device and electronic device.

[0005] The present invention provides a vulnerability mining method, including: Performing program instrumentation processing on multiple target key functions of the driver program to be mined respectively; Controlling a user-mode program to call the driver interface of the driver program to be mined, execute multiple target key functions, jump to a preset collection function based on the instrumentation code in the target key functions, and collect the execution traces of the target key functions based on the preset collection function; Deducing the attributes of the input parameters of the driver interface according to the actual parameters in the execution traces; deducing cross-driver interfaces according to the call stacks in the execution traces; Generating test cases based on the attributes of the input parameters of the driver interface and the cross-driver interfaces, and performing fuzz testing on the driver program to be mined based on the test cases to obtain a vulnerability mining report.

[0006] According to the vulnerability mining method provided by the present invention, deducing cross-driver interfaces according to the call stacks in the execution traces includes: Determining function address information according to the call stacks in the execution traces; Cross - compare the function address information with the driver memory address to determine the upper - layer calling function corresponding to the target key function, and obtain the corresponding cross - driver interface.

[0007] According to a vulnerability mining method provided by the present invention, before inferring the cross - driver interface based on the call stack in the execution trace, the method further includes: Determine the thread information in the execution trace; Based on the thread information, obtain at least two execution traces corresponding to the same thread for cross - comparison, and determine the call stack of the target key function.

[0008] According to a vulnerability mining method provided by the present invention, controlling a user - mode program to call the driver interface of the driver to be mined and execute multiple target key functions includes: Based on the functions of the driver to be mined, determine at least two user - mode programs; Control the user - mode program to execute multiple target key functions and execute different target key functions.

[0009] According to a vulnerability mining method provided by the present invention, inferring the attributes of the input parameters of the driver interface based on the actual parameters of the target key function includes: Determine the input parameter type of the driver interface according to the actual input parameter values of the pre - divided fields in the execution trace; infer the input structure of the driver interface in the execution trace based on preset heuristic rules and the actual parameters; Based on the input parameter type of the driver interface and the input structure of the driver interface, infer the attributes of the input parameters of the driver interface.

[0010] According to a vulnerability mining method provided by the present invention, before generating a test case based on the attributes of the input parameters of the driver interface and the cross - driver interface, the method further includes: Collect the constraint information of the input parameters of the driver interface from the program module of the driver to be mined based on symbolic execution analysis; Generating a test case based on the attributes of the input parameters of the driver interface and the cross - driver interface includes: Generate a test case based on the attributes of the input parameters of the driver interface, the cross - driver interface, and the constraint information of the input parameters of the driver interface.

[0011] According to a vulnerability mining method provided by the present invention, the program module is a binary file; The collecting the constraint information of the input parameters of the driver interface from the program module of the driver to be mined based on symbolic execution analysis includes: Collect constraint information of the driver interface input parameters from the binary file by performing analysis in combination with the actual input parameter values and the symbols.

[0012] The present invention also provides a vulnerability mining device, including: A key function instrumentation module, configured to perform program instrumentation processing on multiple target key functions of the driver program to be mined respectively; An execution trace collection module, configured to control a user-mode program to call the driver interface of the driver program to be mined, execute multiple target key functions, jump to a preset collection function based on the instrumentation code in the target key functions, and collect the execution traces of the target key functions based on the preset collection function; An execution trace processing module, configured to deduce the attributes of the driver interface input parameters according to the actual parameters in the execution traces; deduce the cross-driver interface according to the call stack in the execution traces; A vulnerability mining module, configured to generate test cases based on the attributes of the driver interface input parameters and the cross-driver interface, and perform fuzz testing on the driver program to be mined based on the test cases to obtain a vulnerability mining report.

[0013] The present invention also 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 vulnerability mining method described in any one of the above is implemented.

[0014] 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, the vulnerability mining method described in any one of the above is implemented.

[0015] The vulnerability mining method, device, and electronic device provided by the present invention perform program instrumentation processing on multiple target key functions of the driver program to be mined respectively, so that they jump to a preset collection function during execution, control a user-mode program to call the driver interface of the driver program to be mined, and then call multiple target key functions, jump to a preset collection function based on the instrumentation code in the target key functions, and collect the execution traces of the target key functions based on the preset collection function; deduce the attributes of the driver interface input parameters according to the actual parameters in the execution traces; deduce the cross-driver interface according to the call stack in the execution traces, and generate side erosion force by combining the attributes of the driver interface input parameters and the cross-driver interface, which can increase the effectiveness of the generated test cases by combining potential driver interfaces and increase the effectiveness of vulnerability mining for the driver program. Description of the Drawings

[0016] 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 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, without creative efforts, other drawings can also be obtained based on these drawings.

[0017] Figure 1 It is one of the flow diagrams of the vulnerability mining method provided by the present invention.

[0018] Figure 2 It is another flow diagram of the vulnerability mining method provided by the present invention.

[0019] Figure 3 It is the third flow diagram of the vulnerability mining method provided by the present invention.

[0020] Figure 4 It is the structural diagram of the prototype system implemented based on the vulnerability mining method provided by the present invention.

[0021] Figure 5 It is the structural diagram of the vulnerability mining device provided by the present invention.

[0022] Figure 6 It is the structural diagram of the electronic device provided by the present invention. Detailed implementation manners

[0023] To make the objectives, technical solutions and advantages of the present invention clearer, the following will clearly and completely describe the technical solutions in the present invention with reference to the 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 without creative efforts based on the embodiments in the present invention belong to the scope of protection of the present invention.

[0024] Each device is usually managed by a specific driver. However, many current operating systems allow drivers to register devices with each other or call functions, enabling other drivers to recognize and use these devices, making the specific driver part of other drivers that use the device. This results in the possibility that the opened device path and the function handling the request may belong to different drivers respectively. This interdependent cross-relationship increases the complexity and diversity of driver behavior and brings new driver interfaces. For example, in the Windows system, when a user-mode program calls a driver through input / output control (I / O Control), the Windows system sends the request to the corresponding driver A based on the device path. Driver A passes the request to driver B, and the function of driver B actually processes the request. However, the current method of determining the input parameter format of a driver by the static correspondence between preset device objects, driver interfaces, and specific functions cannot determine this potential driver interface.

[0025] To address the problems in the prior art, the following describes the vulnerability mining method, apparatus, and electronic device of the present invention in conjunction with Figures 1 - 6 a description of the vulnerability mining method, apparatus, and electronic device of the present invention.

[0026] Figure 1 is one of the flow diagrams of the vulnerability mining method provided by the present invention. As Figure 1 shown, the method includes: Step 101: Perform program instrumentation processing on multiple target key functions of the driver to be mined.

[0027] Program instrumentation means writing instrumentation code at specific positions in a function without changing the original logic of the function, for subsequent performance monitoring, debugging, or function verification. Instrumentation code refers to the code inserted into the target key function for jumping to a preset collection function during execution. A target key function refers to the function after the instrumentation code is written.

[0028] Exemplarily, instrumentation code can be written at the starting position of the entry function of the driver interface to obtain a target key function of the driver interface; or instrumentation code can be written at the starting position of the exit function of the driver interface to obtain a target key function of the driver interface, etc.

[0029] Step 102: Control the user-mode program to call the driver interface of the driver to be mined, execute the multiple target key functions, jump to the preset collection function based on the instrumentation code in the target key functions, and collect the execution traces of the target key functions based on the preset collection function.

[0030] The driver interface can also be referred to as the driver program interface, device driver interface, driver control interface, etc. It refers to the functions or methods provided by the driver program that can be called by other programs such as the operating system kernel and user-mode programs. The device here can be a hardware device or a virtual device. Further, the virtual device can be a network device or a pipe device, etc. The target key function refers to the key function among multiple key functions that corresponds to the request received by the driver interface.

[0031] The preset collection function refers to the function that collects the information generated during the execution of the target key function. Those skilled in the art can set the corresponding collection function according to actual needs, and this embodiment does not make further limitations in this regard. Exemplarily, the method of instruction replacement can be used to achieve that when the target key function is executed, it jumps to the preset collection function.

[0032] The execution trace refers to the record of a series of execution information generated by the target key function during the operation of the driver program. Exemplarily, the execution trace can include function call information, input parameters, process information, call stack, etc. The program module of the driver program can be a source program file or a binary file, etc.

[0033] The driver interface input parameter refers to the input data received by the driver interface when it is called according to the parameter specification of the interface. The constraint condition refers to the specific condition that the driver interface input parameter needs to meet when the driver program runs normally.

[0034] Exemplarily, the operating system can send a click input to the relevant program to control the relevant program to send a click input request to the driver interface, so as to control the driver interface to call the target key function corresponding to the click input request to execute the stub code to jump to the preset collection function, collect relevant information such as the execution time, input parameters, and return value of the target key function, and obtain the execution trace of the target key function.

[0035] Step 103: Deduce the attribute of the driver interface input parameter according to the actual parameter in the execution trace; deduce the cross-driver interface according to the call stack in the execution trace.

[0036] The attribute of the driver interface input parameter can include information such as the device name, call number, and driver interface input parameter type. Among them, the device name can also be referred to as the device path, and the call number can be the call number of the driver interface.

[0037] Exemplarily, the preset collection function collects the execution trace of the target key function in the hard disk driver interface corresponding to the hard disk device object of the operating system, obtains the call stack of the execution trace to determine the function that the target key function calls the universal serial bus device driver interface, and deduces the attribute of the driver interface input parameter based on the hard disk driver interface and the universal serial bus device driver interface.

[0038] The cross-driver interface refers to the driver interface of other driver programs called internally by a driver program, compared with the driver interface of the driver program itself. The cross-driver interface can also be called a new driver interface.

[0039] Step 104: Generate test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface, and perform fuzz testing on the driver program to be mined based on the test cases to obtain a vulnerability mining report.

[0040] Exemplarily, a driver interface description template can be constructed based on the attributes of the input parameters of the driver interface and the cross-driver interface. Use a fuzzer to generate and mutate test cases that more conform to the attribute description of the input parameters of the driver interface in the driver interface description template. Send the test cases to the driver program for execution through the operating system to achieve code coverage collection and memory access violation detection of the driver program, so as to mine potential security vulnerabilities. Among them, the fuzzer can be a coverage-guided grey-box fuzzer, and code coverage collection is achieved through hardware characteristics; the detection of memory access violations of the driver program can be achieved by means of code instrumentation.

[0041] The vulnerability mining method provided by the embodiments of the present invention performs program instrumentation processing on multiple target key functions of the driver program to be mined respectively, so that when they are executed, they jump to a preset collection function, control the user-mode program to call the driver interface of the driver program to be mined, and then when calling multiple target key functions, jump to the preset collection function based on the instrumentation code in the target key functions, and collect the execution traces of the target key functions based on the preset collection function; deduce the attributes of the input parameters of the driver interface according to the actual parameters in the execution traces; deduce the cross-driver interface according to the call stack in the execution traces, and generate side etching force by combining the attributes of the input parameters of the driver interface and the cross-driver interface, which can increase the effectiveness of the generated test cases by combining potential driver interfaces and increase the effectiveness of vulnerability mining for the driver program.

[0042] In one embodiment, after collecting the execution traces of the target key functions when sending instructions to the device through the driver interface call, they can be cached, and the cached execution traces are read regularly to reduce overhead and minimize the impact on the performance of the operating system on the premise of ensuring the integrity and reliability of the execution trace collection.

[0043] Based on the above embodiments, deducing the cross-driver interface according to the call stack in the execution traces includes: Determine the function address information according to the call stack in the execution traces; Perform cross-comparison between the function address information and the memory address of the driver program to determine the upper-layer calling function corresponding to the target key function, and obtain the corresponding cross-driver interface.

[0044] The function address information refers to the specific memory address information corresponding to each level of function calls in the call stack during the execution of the driver to be mined. The driver memory address refers to the memory address of the driver loaded in the system.

[0045] In this embodiment, the function address information can be cross-compared with the memory address of the driver loaded in the system to determine each upper-layer calling function corresponding to the target key function and the driver to which each upper-layer calling function belongs, so as to identify the relationship between the driver and the device and effectively discover new driver interfaces.

[0046] Exemplarily, the system can be probed through an analysis tool to actively enumerate the drivers and devices loaded in the system, and a directed graph can be constructed based on the relationship between the driver and the device. Based on this directed graph, the target key function is actively called through the driver interface to initiate an input / output control call to the device, and the execution trace of the target key function is obtained. The transfer and processing of relevant calls between different drivers are determined through the call stack of the execution trace, so as to determine the potential relationship between the driver and the device and obtain the corresponding driver interface.

[0047] To further increase the potential driver interfaces that can be identified, based on the above embodiment, before inferring the cross-driver interface according to the call stack in the execution trace, the method further includes: Determine the thread information in the execution trace; Based on the thread information, at least two execution traces corresponding to the same thread are obtained for cross-comparison to determine the call stack of the target key function.

[0048] The user-mode program can send instructions to the device by calling the target key function through the driver interface, and the operating system kernel can also send instructions to the device by calling the target key function through the driver interface. Correspondingly, the thread can be a thread of the user-mode program or a thread of the operating system kernel, etc.

[0049] The execution trace data generated by the same thread has temporal relevance. Exemplarily, when the thread first calls the first target key function of driver interface A and then calls the second target key function of driver interface B, the two call events will be arranged in chronological order in the execution trace, and cross-comparison is performed to determine whether there is a correlation or dependency between the calls of the two target key functions.

[0050] It can be understood that the execution trace also includes input driver interface parameter information, and the input driver interface parameter information can be determined synchronously when analyzing the execution trace, so as to further infer the input parameter types generated when the user-mode program or the operating system kernel interacts with the driver, and the transfer and processing of relevant calls between different drivers.

[0051] Such asFigure 2 As shown, the input / output control requests of the same thread can correspond to a device object name \Device\USB and an input / output control call number 0x220410. Obtain multiple execution traces obtained by passing the input / output control requests, and extract the input parameter information and the corresponding driver function call stacks \Driver\USBHUB3, \Driver\Wdf01000 when the driver interface is called by cross-comparing the data generated by the same thread in the execution traces. Determine UsbHub3.sys and Wdf01000.sys by analyzing the different driver programs and their associated binary files that appear in the call stack.

[0052] The effectiveness of execution trace analysis depends to a large extent on the quality of the execution traces. In the case where all types of interfaces of the driver cannot be fully called, only some of the called driver interfaces can be analyzed to infer the attributes of the input parameters of the driver interface.

[0053] To increase the integrity of the driver interfaces analyzed when inferring the attributes of the input parameters of the driver interface, based on any of the above embodiments, control the user-mode program to call the driver interfaces of the to-be-mined driver program and execute multiple target key functions, including: Determine at least two user-mode programs based on the functions of the to-be-mined driver program; Control the user-mode program to execute multiple target key functions and execute different target key functions.

[0054] Exemplarily, as Figure 3 shown, while performing program instrumentation processing on multiple target key functions to obtain the corresponding key functions, an automated operation module can be started in the user mode to automatically call the underlying interfaces of the operating system based on preset rules to send click, input, and other operation instructions to the windows and controls in the seed program, so that the seed program makes system calls to the operating system kernel in the kernel mode, calls the driver program code through the operating system kernel, executes the target key functions of the driver interfaces, and the execution trace collection module collects the execution traces of the target key functions based on the pre-instrumentation (program instrumentation) to obtain an execution trace file.

[0055] Send instructions to the device by calling different target key functions through the driver interface.

[0056] Among them, the seed program refers to a user-mode program related to the function of the driver program, which can be a graphical interface user-mode program. The specific preset rules can be set according to actual needs, and this embodiment does not make further limitations in this regard.

[0057] In this embodiment, by controlling multiple user-mode programs related to the functions of the driver to initiate a large number of different calls to different target key functions in the driver interface, the driver interfaces collected in the execution trace can be enriched, and the integrity of the driver interfaces analyzed when inferring the attributes of the input parameters of the driver interface can be increased.

[0058] Based on any of the above embodiments, inferring the attributes of the input parameters of the driver interface based on the actual parameters of the target key function includes: Determining the input parameter type of the driver interface according to the actual input parameter values of the pre-partitioned fields in the execution trace; inferring the input structure of the driver interface in the execution trace based on preset heuristic rules and the actual parameters; Inferring the attributes of the input parameters of the driver interface based on the input parameter type of the driver interface and the input structure of the driver interface.

[0059] The input parameters of the driver interface generally exist in the form of a structure or a complex data structure. The input parameters of the driver interface can be field-partitioned to obtain the basic units corresponding to the input parameters of the driver interface, so as to facilitate the analysis of the input parameter type of the data-driven driver interface. For example, if the value of a field is a memory address, it can be inferred that the type of the input parameter of the driver interface is a pointer type; if the value of the field is a legal Unicode character sequence, it can be inferred that the input parameter type of the driver interface is a string type, etc. The types of the input parameters of the driver interface include pointers, strings, handles, constants, integers, etc.

[0060] The preset heuristic rules can be set according to actual needs, and this embodiment does not make further limitations in this regard. In one embodiment, heuristic rules can be preset for the target driver interface input parameters based on the importance of the input parameters of the driver interface under actual working conditions.

[0061] In this embodiment, the input parameter type of the driver interface and the input structure of the driver interface can more accurately identify the boundaries of the input fields of the driver interface, and increase the effectiveness of the attributes of the inferred input parameters of the driver interface.

[0062] Based on any of the above embodiments, before generating test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface, the method further includes: Collecting constraint information of the input parameters of the driver interface from the program modules of the driver to be mined based on symbolic execution analysis; Generating test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface includes: Generating test cases based on the attributes of the input parameters of the driver interface, the cross-driver interface, and the constraint information of the input parameters of the driver interface.

[0063] In this embodiment, by collecting the constraint information of the input parameters of the driver interface, the input interface of the driver program in the real operating system can be analyzed more efficiently, so as to more effectively mine the vulnerabilities of these driver programs.

[0064] Based on any of the above embodiments, the program module is a binary file.

[0065] It can be understood that, in combination with each of the above embodiments, by directly analyzing the binary file, the strong dependence on the source code can be eliminated, so as to analyze and mine vulnerabilities in complex scenarios such as closed source, code obfuscation, and cross-driver calls in combination with dynamic execution data (execution traces).

[0066] In one embodiment, the collecting the constraint information of the input parameters of the driver interface from the program module of the driver to be mined based on symbolic execution analysis includes: Combining the actual input parameter values and the symbolic execution analysis to collect the constraint information of the input parameters of the driver interface from the binary file.

[0067] In this embodiment, the actual input parameter values in the execution trace can provide a more specific and practical context for the symbolic execution analysis, so as to further reduce the number of paths that the symbolic execution needs to explore, etc., and increase the range of the extracted constraint information on the basis of focusing on inferring the types of parameters and the paths related to the constraints.

[0068] Figure 4 is a schematic diagram of the architecture of the data query method provided by the present invention, as Figure 4 shown. In order to specifically illustrate the functions of the vulnerability mining method provided in this embodiment, a specific example is provided below.

[0069] A prototype system implemented based on the vulnerability mining method includes a driver execution trace analysis engine, a driver and device relationship identification engine, a driver interface recovery engine, and a driver fuzzer; The driver execution trace analysis engine can obtain the corresponding key functions by performing program instrumentation processing on multiple target key functions in the system kernel and the driver program respectively, so as to achieve lightweight selective instrumentation. When the key function is called, it jumps to the preset collection function based on the instrumentation code in the target key function to collect the execution trace of the target key function; it can collect the execution trace of the target key function through the automated operation of the graphical interface program combined with the active detection of the target interface to perform the execution trace collection based on instrumentation; The driver and device relationship identification engine can obtain at least two execution traces corresponding to the same thread for cross comparison, determine the call stack of the target key function, perform call stack analysis, and determine the driver interface input parameter type according to the actual input parameter value of the pre-divided field in the execution trace; so as to determine the driver and device relationship based on the device path (also known as the device name), the driver interface call number and the driver interface input parameter type; The driver interface recovery engine performs input structure inference on the binary file of the driver based on preset heuristic rules and call stack; obtains the program module of the driver, and collects driver interface input parameter constraint information from the program module based on symbolic execution analysis; infers the attributes of the driver interface input parameters based on the driver interface input parameter type, the driver interface input structure and the driver interface input parameter constraint information, so as to generate an interface template based on the attributes of the driver interface input parameters; The driver fuzz tester (not shown in the figure) can perform coverage-guided gray-box fuzz testing on the driver based on interface template generation and mutation test cases to obtain vulnerability reports, such as crash reports; further, the driver fuzz tester can use hardware characteristics and selective instrumentation to collect code coverage and detect memory access violations for the driver during the execution of test cases, thereby exploring potential security vulnerabilities.

[0070] It is understood that although we use specific operating system kernels and insertion points in some embodiments, other kernels and insertion points can be used. Similarly, although we use specific graphical interface seed programs and automated operation means here, other types of graphical interface seed programs and automated operation means can be used. In addition, although we use specific test case generation, mutation strategies and code coverage feedback techniques in fuzz testing, other types of generation, mutation strategies and code coverage feedback techniques can be used.

[0071] The vulnerability mining device provided by the present invention is described below. The vulnerability mining device described below and the vulnerability mining method described above can be referenced to each other.

[0072] Figure 5 Schematic diagram of the structure of the vulnerability mining device provided by the present invention. Figure 5 As shown, the device comprises: A key function generation module 501 is used to perform program instrumentation processing on multiple target key functions of the driver to be mined; An execution trace collection module 502 is used to control a user-mode program to call a driver interface of the driver to be mined, execute a plurality of the target key functions, jump to a preset collection function based on the plug-in code in the target key function, and collect the execution trace of the target key function based on the preset collection function; The execution trace processing module 503 is configured to deduce the attributes of the input parameters of the driver interface according to the actual parameters in the execution trace; deduce the cross-driver interface according to the call stack in the execution trace. The vulnerability mining module 504 is configured to generate test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface, and perform fuzz testing on the driver program to be mined based on the test cases to obtain a vulnerability mining report.

[0073] Based on any of the above embodiments, the execution trace processing module 503 is specifically configured to: Determine function address information according to the call stack in the execution trace; Cross-compare the function address information with the memory address of the driver program to determine the upper-layer calling function corresponding to the target key function, and obtain the corresponding cross-driver interface.

[0074] Based on any of the above embodiments, the vulnerability mining device further includes a call stack determination module, which is configured to: Determine the thread information in the execution trace; Based on the thread information, obtain at least two execution traces corresponding to the same thread for cross-comparison, and determine the call stack of the target key function.

[0075] Based on any of the above embodiments, the execution trace collection module 502 is specifically configured to: Determine at least two user-mode programs based on the functions of the driver program to be mined; Control the user-mode programs to execute multiple target key functions and execute different target key functions.

[0076] Based on any of the above embodiments, the execution trace processing module 503 is further specifically configured to: Determine the input parameter type of the driver interface according to the actual input parameter values of the pre-partitioned fields in the execution trace; infer the input structure of the driver interface in the execution trace based on preset heuristic rules and the actual parameters; Deduce the attributes of the input parameters of the driver interface based on the input parameter type of the driver interface and the input structure of the driver interface.

[0077] Based on any of the above embodiments, the vulnerability mining device further includes a constraint information collection module, which is configured to collect the constraint information of the input parameters of the driver interface from the program modules of the driver program to be mined based on symbolic execution analysis; The vulnerability mining module 504 is specifically configured to generate test cases based on the attributes of the input parameters of the driver interface, the cross-driver interface, and the constraint information of the input parameters of the driver interface.

[0078] Based on any of the above embodiments, the program module is a binary file; the constraint information collection module is further configured to collect constraint information of the input parameters of the driver interface from the binary file in combination with the actual input parameter values and the symbolic execution analysis.

[0079] Figure 6 An exemplary structural diagram of an electronic device is shown as Figure 6 shown. The electronic device may include: a processor 610, a communication interface 620, a memory 630, and a communication bus 640. Among them, the processor 610, the communication interface 620, and the memory 630 complete mutual communication through the communication bus 640. The processor 610 can call the logical instructions in the memory 630 to execute the vulnerability mining method, which includes: performing program instrumentation processing on multiple target key functions of the driver program to be mined; controlling the user-mode program to call the driver interface of the driver program to be mined, execute the multiple target key functions, jump to a preset collection function based on the instrumentation code in the target key functions, and collect the execution traces of the target key functions based on the preset collection function; deduce the attributes of the input parameters of the driver interface according to the actual parameters in the execution traces; deduce the cross-driver interface according to the call stack in the execution traces; generate test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface, and perform fuzz testing on the driver program to be mined based on the test cases to obtain a vulnerability mining report.

[0080] In addition, when the logical instructions in the above-mentioned memory 630 can be implemented in the form of software function units and sold or used as an independent product, 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 this technical solution, can be embodied in the form of a software product. This 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 the various embodiments of the present invention. The foregoing storage medium includes: various media such as a USB flash drive, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk, or an optical disc that can store program codes.

[0081] On the other hand, the present invention also provides a computer program product, which includes a computer program. The computer program 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 vulnerability mining method provided by each of the above methods. The method includes: respectively performing program instrumentation processing on multiple target key functions of the driver to be mined; controlling a user-mode program to call the driver interface of the driver to be mined, execute the multiple target key functions, jump to a preset collection function based on the instrumentation code in the target key functions, and collect the execution traces of the target key functions based on the preset collection function; infer the attributes of the input parameters of the driver interface according to the actual parameters in the execution traces; infer the cross-driver interface according to the call stack in the execution traces; generate test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface, and perform fuzz testing on the driver to be mined based on the test cases to obtain a vulnerability mining report.

[0082] In 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 vulnerability mining method provided by each of the above methods. The method includes: respectively performing program instrumentation processing on multiple target key functions of the driver to be mined; controlling a user-mode program to call the driver interface of the driver to be mined, execute the multiple target key functions, jump to a preset collection function based on the instrumentation code in the target key functions, and collect the execution traces of the target key functions based on the preset collection function; infer the attributes of the input parameters of the driver interface according to the actual parameters in the execution traces; infer the cross-driver interface according to the call stack in the execution traces; generate test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface, and perform fuzz testing on the driver to be mined based on the test cases to obtain a vulnerability mining report.

[0083] 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 may be 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. Those of ordinary skill in the art can understand and implement it without creative labor.

[0084] 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 such an 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.

[0085] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than 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 each embodiment of the present invention.

Claims

1. A vulnerability mining method, characterized in that, Including: Performing program instrumentation processing on multiple target key functions of the driver to be mined respectively; Controlling the user-mode program to call the driver interface of the driver to be mined, executing multiple target key functions, jumping to a preset collection function based on the instrumentation code in the target key functions, and collecting the execution traces of the target key functions based on the preset collection function; Deducing the attributes of the input parameters of the driver interface based on the actual parameters in the execution traces; Deducing the cross-driver interface based on the call stack in the execution traces; Generating test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface, and performing fuzz testing on the driver to be mined based on the test cases to obtain a vulnerability mining report.

2. The vulnerability mining method according to claim 1, wherein Deducing the cross-driver interface based on the call stack in the execution traces includes: Determining function address information based on the call stack in the execution traces; Performing cross-comparison between the function address information and the driver program memory address to determine the upper-layer calling function corresponding to the target key function, and obtaining the corresponding cross-driver interface.

3. The vulnerability mining method according to claim 1, characterized in that Before deducing the cross-driver interface based on the call stack in the execution traces, the method further includes: Determining the thread information in the execution traces; Obtaining at least two execution traces corresponding to the same thread based on the thread information for cross-comparison, and determining the call stack of the target key function.

4. The vulnerability mining method according to claim 1, wherein Controlling the user-mode program to call the driver interface of the driver to be mined and execute multiple target key functions includes: Determining at least two user-mode programs based on the functions of the driver to be mined; Controlling the user-mode program to execute multiple target key functions and execute different target key functions.

5. The vulnerability mining method according to claim 1, wherein The deducing the attributes of the input parameters of the driver interface based on the actual parameters of the target key functions includes: Determining the input parameter type of the driver interface according to the actual input parameter values of the pre-divided fields in the execution traces; inferring the input structure of the driver interface in the execution traces based on preset heuristic rules and the actual parameters; Deducing the attributes of the input parameters of the driver interface based on the input parameter type of the driver interface and the input structure of the driver interface.

6. The vulnerability mining method according to claim 1, wherein Before generating test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface, the method further includes: Collecting constraint information of the input parameters of the driver interface from the program modules of the driver to be mined based on symbolic execution analysis; Generating test cases based on the attributes of the input parameters of the driver interface and the cross-driver interface includes: Generating test cases based on the attributes of the input parameters of the driver interface, the cross-driver interface, and the constraint information of the input parameters of the driver interface.

7. The vulnerability mining method according to claim 6, wherein The program module is a binary file; The collecting the constraint information of the input parameters of the driver interface from the program modules of the driver to be mined based on symbolic execution analysis includes: Combining the actual input parameter values and the symbolic execution analysis to collect the constraint information of the input parameters of the driver interface from the binary file.

8. A vulnerability mining device, characterized in that, Including: A key function instrumentation module for performing program instrumentation processing on multiple target key functions of the driver to be mined respectively; An execution trace collection module, configured to control a user-mode program to call a driver interface of the to-be-mined driver, execute a plurality of the target key functions, jump to a preset collection function based on the instrumentation code in the target key functions, and collect execution traces of the target key functions based on the preset collection function; An execution trace processing module, configured to deduce the attributes of the driver interface input parameters according to the actual parameters in the execution traces; Deduce cross-driver interfaces according to the call stacks in the execution traces; A vulnerability mining module, configured to generate test cases based on the attributes of the driver interface input parameters and the cross-driver interfaces, and perform fuzz testing on the to-be-mined driver based on the test cases to obtain a vulnerability mining report.

9. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, When the processor executes the computer program, the vulnerability mining method according to any one of claims 1 to 7 is implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, the vulnerability mining method according to any one of claims 1 to 7 is implemented.

Images