Stack backtracking and communication-based driver loading process acquisition method and system

Abstract

The application discloses a kind of based on stack backtracking and communication's drive loading process acquisition method and system, this method first loads minifilter framework, and obtains the drive loading state of system by minifilter framework;When system loading drive is completed, all system drive loading threads are traversed in minifilter framework, and apc is inserted, and the track of each drive loading thread is backtracked;When there is the track of target drive loading thread in NtLoadDriver function, then it is judged whether the process corresponding to target drive loading thread is service process;When the corresponding process is service process, target drive loading process is found by alpc between relationship and win api access.The application can effectively acquire drive loading process, and has the characteristics that compatibility is good, and search is accurate.

Description

Technical Field

[0001] This invention relates to the field of computer network security, and in particular to a method and system for obtaining driver loading processes based on stack backtracking and communication. Background Technology

[0002] As the internet continues to develop, malicious software is also emerging in an endless stream, which seriously threatens the security of users' host systems. Many malicious applications use the method of loading drivers to carry out intrusive access operations, and ordinary user-level protection is difficult to achieve the purpose of file security protection.

[0003] Existing methods typically detect driver loading by checking the driver signature and MD5 checksum, but this cannot guarantee that the driver is not faulty. Therefore, it is crucial to determine the driver loading process. Summary of the Invention

[0004] Based on this, embodiments of this application provide a method and system for obtaining driver loading processes based on stack backtracking and communication, which can effectively obtain driver loading processes.

[0005] Firstly, a method for obtaining the driver loading process based on stack backtracking and communication is provided, the method including:

[0006] Load the minifilter framework and obtain the system's driver loading status through the minifilter framework;

[0007] When the system finishes loading the driver, all driver loading threads of the system are traversed in the minifilter framework and APC is inserted. The stack traces the journey of each driver loading thread.

[0008] If there is a process trace of the target driver loading thread in the NtLoadDriver function, then determine whether the process corresponding to the target driver loading thread is a service process.

[0009] When the corresponding process is a service process, the target driver loading process is found through the relationships between ALPCs and Win API access.

[0010] Optionally, the driver loading status of the system is obtained through the minifilter framework, including:

[0011] The function to obtain the system driver loading information is the NtLoadDriver function.

[0012] Optionally, after determining whether the process corresponding to the target driver loading thread is a service process, the method further includes:

[0013] If the corresponding process is not a service process, then it is determined that the process is not the target driver loading process.

[0014] Optionally, loading the minifilter framework and obtaining the system's driver loading status through the minifilter framework includes:

[0015] When the system loads the driver and the driver loading process is in a waiting state, the filter in minifilter waits for the system to finish loading the driver.

[0016] Secondly, a driver loading process acquisition system based on stack backtracking and communication is provided, the system comprising:

[0017] The acquisition module is used to load the minifilter framework and obtain the system's driver loading status through the minifilter framework.

[0018] The backtracking module is used to traverse all driver loading threads in the system within the minifilter framework when the system has finished loading the driver, and insert APCs and backtrack the stack trace of each driver loading thread.

[0019] The judgment module is used to determine whether the process corresponding to the target driver loading thread is a service process when there is a process trajectory of the target driver loading thread in the NtLoadDriver function; when the corresponding process is a service process, the target driver loading process is found through the relationship between ALPCs and Win API access.

[0020] Optionally, in the acquisition module:

[0021] The function to obtain the system driver loading information is the NtLoadDriver function.

[0022] Optionally, the confirmation module is further configured to:

[0023] If the corresponding process is not a service process, then it is determined that the process is not the target driver loading process.

[0024] Optionally, the acquisition module is specifically used for:

[0025] When the system loads the driver and the driver loading process is in a waiting state, the filter in minifilter waits for the system to finish loading the driver.

[0026] The technical solution provided in this application first loads a minifilter framework and obtains the system's driver loading status through the minifilter framework. When the system finishes loading the driver, all system driver loading threads are traversed in the minifilter framework, and APCs are inserted. The stack trace of each driver loading thread is then traced back. When the NtLoadDriver function contains the trace of the target driver loading thread, it is determined whether the process corresponding to the target driver loading thread is a service process. If the corresponding process is a service process, the target driver loading process is found through the relationship between APCs and Win API access. It can be seen that this invention can effectively obtain the driver loading process and has the characteristics of good compatibility and accurate search. Attached Figure Description

[0027] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0028] Figure 1 A flowchart illustrating the steps of a method for obtaining a driver loading process based on stack backtracking and communication, provided in this application embodiment;

[0029] Figure 2 This is a flowchart of the driver loading process acquisition in one optional embodiment of this application;

[0030] Figure 3 This is a flowchart of the driver loading process acquisition, which is an optional embodiment of this application. Detailed Implementation

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

[0032] In the description of this invention, the terms “comprising,” “having,” and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are expressly listed, but may also include other steps or units that are not expressly listed but are inherent to these processes, methods, products, or apparatuses, or steps or units added based on further optimizations of the inventive concept.

[0033] During driver loading, the EDR (Electronic Data Recorder) checks the integrity of the received data by performing a hash operation on the received data using MD5 checksum. However, MD5 checksums cannot guarantee 100% driver integrity; therefore, determining the driver loading process is also crucial. Currently, various network solutions require secondary development, but this approach is unsuitable given today's increasing focus on network security. Please refer to [reference needed]. Figure 1 The diagram illustrates a flowchart of a method for obtaining a driver loading process based on stack backtracking and communication, as provided in an embodiment of this application. This method may include the following steps:

[0034] Step 101: Load the minifilter framework and obtain the system's driver loading status through the minifilter framework.

[0035] In this embodiment, the program function for obtaining the system driver loading is the NtLoadDriver function. The minifilter framework is a filter manager.

[0036] Specifically, when the system loads the driver and the driver loading process is in a waiting state, the filter in minifilter waits for the system to finish loading the driver.

[0037] Step 102: When the system finishes loading the driver, iterate through all the system's driver loading threads in the minifilter framework and insert APCs. The stack traces the journey of each driver loading thread.

[0038] Among them, apc (Alternative PHP Cache) can be a PHP intermediate code that can cache opcode.

[0039] Step 103: When there is a process trace of the target driver loading thread in the NtLoadDriver function, determine whether the process corresponding to the target driver loading thread is a service process.

[0040] Step 104: When the corresponding process is a service process, the target driver loading process is found through the relationship between ALPCs and Win API access.

[0041] In an optional embodiment of this application, such as Figure 2 Driver loading is handled by the system process, but it's unclear which process notifies the system process to load the driver. When driver loading is intercepted in the module callback or minifitter, it's already within the system process context. The relationship can be found through stack backtracking.

[0042] Specifically, after filtering through the minifilter and finding that the system is loading the driver, the driver loading process is still in a waiting state, waiting for the system to finish loading the driver. The minifilter iterates through all threads, inserts an APC, and uses stack traces to trace the thread's execution path. Since the driver loading process calls NtLoadDriver but the driver loading is not complete and is in a waiting state, the thread loading the driver must be located between the beginning and end of the NtLoadDriver API. When the backtracking reaches a thread that is exactly inside the NtLoadDriver function, the driver loading process can be identified. If the found process is not service.exe, it is basically confirmed. If it is service.exe, and the driver loading process is not service.exe, the following operations need to be performed.

[0043] Once the driver loading process is identified, if it's service.exe, it's also necessary to determine which process notified Service.exe to load the driver. The relationship then becomes as follows: Figure 3 As shown. At this point, the actual driver loading process is also in a waiting state. Therefore, it is necessary to find the actual loading process through the relationship between ALPCs and WinAPI access.

[0044] This application also provides a driver loading process acquisition system based on stack backtracking and communication. The system includes:

[0045] The module is used to load the minifilter framework and obtain the system's driver loading status through the minifilter framework.

[0046] The backtracking module is used to traverse all driver loading threads in the system within the minifilter framework when the system has finished loading the driver, and inserts APCs to backtrack the process trajectory of each driver loading thread through the stack trace.

[0047] The judgment module is used to determine whether the process corresponding to the target driver loading thread is a service process when there is a process trajectory of the target driver loading thread in the NtLoadDriver function.

[0048] The confirmation module is used to find the target driver loading process by using the relationships between ALPCs and accessing the Win API when the corresponding process is a service process.

[0049] In an optional embodiment of this application, the acquisition module includes:

[0050] The function to obtain the system driver loading information is the NtLoadDriver function.

[0051] In an optional embodiment of this application, the confirmation module is further configured to:

[0052] If the corresponding process is not a service process, then it is determined that the process is not the target driver loading process.

[0053] In an optional embodiment of this application, the acquisition module is specifically used for:

[0054] When the system loads the driver and the driver loading process is in a waiting state, the filter in minifilter waits for the system to finish loading the driver.

[0055] The driver loading process acquisition system based on stack backtracking and communication provided in this application embodiment is used to implement the aforementioned driver loading process acquisition method based on stack backtracking and communication. Specific limitations of the driver loading process acquisition system based on stack backtracking and communication can be found in the limitations of the driver loading process acquisition method based on stack backtracking and communication described above, and will not be repeated here. Each part of the aforementioned driver loading process acquisition system based on stack backtracking and communication can be implemented entirely or partially through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in the device in hardware form, or stored in the memory of the device in software form, so that the processor can call and execute the operations corresponding to each module.

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

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

Claims

1. A method for obtaining a driver loading process based on stack backtracking and communication, characterized in that, The method comprises: loading a minifilter framework, and acquiring a driver loading state of a system through the minifilter framework; when the system completes loading of a driver, traversing all driver loading threads of the system in the minifilter framework, and inserting an apc to stack backtrace a travel track of each of the driver loading threads; when the travel track of a target driver loading thread exists in an NtLoadDriver function, judging whether a process corresponding to the target driver loading thread is a service process; when the corresponding process is the service process, finding the target driver loading process through an alpc relationship and win api access.

2. The method of claim 1, wherein, The method for acquiring the driver loading state of the system through the minifilter framework comprises: the program function for acquiring the driver loading state of the system is an NtLoadDriver function.

3. The method of claim 1, wherein, After judging whether the process corresponding to the target driver loading thread is the service process, the method further comprises: when the corresponding process is not the service process, determining that the process is not the target driver loading process.

4. The method of claim 1, wherein, The loading of the minifilter framework and the acquiring of the driver loading state of the system through the minifilter framework comprise: after filtering the system loading driver in the minifilter, when the loading process of the driver is in a waiting state, waiting for the system to complete loading of the driver.

5. A stack backtrace and communication based driver loading process acquisition system, comprising: The system comprises: an acquiring module, configured to load a minifilter framework, and acquire a driver loading state of a system through the minifilter framework; a backtracking module, configured to, when the system completes loading of a driver, traverse all driver loading threads of the system in the minifilter framework, and insert an apc to stack backtrace a travel track of each of the driver loading threads; a judging module, configured to, when the travel track of a target driver loading thread exists in an NtLoadDriver function, judge whether a process corresponding to the target driver loading thread is a service process; a confirming module, configured to, when the corresponding process is the service process, find the target driver loading process through an alpc relationship and win api access.

6. The system of claim 5, wherein, In the acquiring module: the program function for acquiring the driver loading state of the system is an NtLoadDriver function.

7. The system of claim 5, wherein, The confirming module is further configured to: when the corresponding process is not the service process, determine that the process is not the target driver loading process.

8. The system of claim 5, wherein, The acquiring module is specifically configured to: after filtering the system loading driver in the minifilter, when the loading process of the driver is in a waiting state, wait for the system to complete loading of the driver.

Images