CN115577347B - Driver protection method and device - Google Patents

Abstract

The present disclosure relates to the field of computer technology, and in particular to a driver protection method and device. The method includes: determining the key information of the driver after the driver of the hardware device is loaded into the memory; determining the first thread information, the second Second thread information and third thread information; start the first thread, the second thread and the third thread; according to the key information, the first thread information, the second thread information and the Third thread information, the first thread to the second thread, the second thread to the third thread and the driver, and the third thread to the first thread and the driver The program is guarded. The embodiment of the present disclosure protects the driver program in a circular manner through the first thread, the second thread and the third thread, preventing the driver program from being hijacked, thereby improving the security of the driver program.

Description

Driver protection method and device

technical field

The present disclosure relates to the field of computer technology, in particular to a driver protection method and device.

Background technique

A computer usually includes hardware devices such as a graphics card, a sound card, and a network card. The operating system communicates with the hardware device through a driver program. For example, the operating system communicates with the graphics card through a graphics card driver program. During the use of computers, drivers of hardware devices are often hijacked. For example, some functions in the drivers are often hooked or patched, so that user data is tampered with or destroyed, affecting user use. Therefore, need badly a kind of method that can prevent the driver program of hardware device from being hijacked.

Contents of the invention

In view of this, the present disclosure proposes a driver protection method and device.

According to one aspect of the present disclosure, a driver protection method is provided, the method includes: after the driver of the hardware device is loaded into the memory, determining the key information of the driver, the key information includes the driver At least one of the callback function table information, callback function information and dispatch function table information; determine the first thread information, the second thread information and the third thread information, the first thread information includes the first thread corresponding to the first thread The address, length and hash value of the code, the second thread information includes the address, length and hash value of the second code corresponding to the second thread, and the third thread information includes the third code corresponding to the third thread address, length and hash value; start the first thread, the second thread and the third thread; according to the key information, the first thread information, the second thread information and the first thread information Three thread information, the first thread to the second thread, the second thread to the third thread and the driver, and the third thread to the first thread and the driver To guard.

In a possible implementation manner, according to the key information, the first thread information, the second thread information, and the third thread information, the first thread performs an operation on the second thread, The second thread guards the third thread and the driver, and the third thread guards the first thread and the driver, including: the first thread according to the second thread information, and guard the second thread; the second thread guards the driver's callback function table, dispatch function table, and the third thread according to the key information and the third thread information ; The third thread guards the callback function of the driver and the first thread according to the key information and the first thread information.

In a possible implementation manner, the first thread guarding the second thread according to the second thread information includes: the first thread according to the address and length in the second thread information , calculate the hash value of the second code; in the case that the hash value of the second code is the same as the hash value in the second thread information, the first thread checks the second thread Whether to exit; in the case that the second thread does not exit, after the first thread sleeps for a preset period of time, it starts to execute again from the following steps: the first thread executes according to the address in the second thread information and length, calculating the hash value of the second code.

In a possible implementation manner, the first thread guards the second thread according to the second thread information, and further includes: comparing the hash value of the second code with the second thread When the hash values in the information are different, the first thread repairs the second code according to the drive image, the address and the length in the second thread information, and the drive image is the original drive on the hard disk. A backup of the program in memory.

In a possible implementation manner, the first thread guards the second thread according to the second thread information, and further includes: when the second thread exits, the first thread The second thread is restarted.

In a possible implementation manner, the second thread guards the driver's callback function table, dispatch function table, and the third thread according to the key information and the third thread information, including : the second thread guards the callback function table and the dispatch function table of the driver according to the callback function table information and the dispatch function table information in the key information; the second thread guards the callback function table and the dispatch function table according to the third thread information, guarding the third thread.

In a possible implementation manner, the callback function table information includes the address, length and hash value of the driver's callback function table, and the dispatch function table information includes the address of the driver's dispatch function table , length and hash value; the second thread guards the callback function table and dispatch function table of the driver according to the callback function table information and dispatch function table information in the key information, including: the first The second thread calculates the hash value of the callback function table of the driver according to the address and the length in the callback function table information; in the hash value of the callback function table of the driver and the callback function table information In the case of different hash values, the second thread repairs the callback function table of the driver according to the driver image, the address and the length in the callback function table information; the second thread repairs the callback function table according to the Address and length in the dispatch function table information, calculate the hash value of the dispatch function table of the driver; the hash value of the dispatch function table of the driver is different from the hash value in the dispatch function table information In the case of , the second thread repairs the dispatch function table of the driver according to the driver image, the address and the length in the dispatch function table information.

In a possible implementation manner, the third thread guards the callback function of the driver and the first thread according to the key information and the first thread information, including: the third thread The thread guards the callback function of the driver according to the callback function information in the key information; the third thread guards the first thread according to the first thread information.

In a possible implementation manner, the callback function information includes addresses, lengths, and hash values of all callback functions of the driver; the third thread, according to the callback function information in the key information, The callback function of the driver is guarded, including: for any callback function of the driver, the third thread calculates the hash value of the callback function according to the address and length of the callback function in the callback function information ; When the hash value of the callback function is different from the reference hash value, the second thread assigns the callback function to the callback function according to the address and length of the callback function in the driver image and the callback function table information The code is repaired, and the reference hash value is the hash value of the callback function in the callback function information.

In a possible implementation manner, the method further includes: the interrupt service of the driver program guards the first thread.

In a possible implementation manner, the interrupt service of the driver program guarding the first thread includes: before the interrupt service of the driver program performs interrupt processing, the interrupt service according to the first thread Address and length in the information, calculate the hash value of the first code; in the case that the hash value of the first code is the same as the hash value in the first thread information, the interrupt service check Whether the first thread exits; if the first thread does not exit, the interrupt service executes the interrupt processing.

In a possible implementation manner, the method further includes: firmware of the hardware device guards the interrupt service.

In a possible implementation manner, the key information further includes the interrupt processing function information corresponding to the interrupt service, and the interrupt processing function information includes the address, length and hash value of the interrupt processing function corresponding to the interrupt service The firmware of the hardware device guards the interrupt service, including: the firmware calculates the hash value of the interrupt processing function according to the address and length in the interrupt processing function information; In the case where the hash value is the same as the hash value in the interrupt handling function information, after the firmware sleeps for a preset period of time, it starts to execute again from the following steps: The address and the length are used to calculate the hash value of the interrupt processing function.

In a possible implementation manner, the firmware of the hardware device guards the interrupt service, including: when the hash value of the interrupt processing function is different from the hash value in the interrupt processing function information Next, the firmware controls the hardware device to stop sending interrupt requests to stop the interrupt service; the firmware repairs the interrupt processing function according to the address and length in the driver image and the interrupt processing function information; After the repair is completed, the firmware controls the hardware device to resume sending the interrupt request, so as to restore the interrupt service.

In a possible implementation manner, determining the key information of the driver includes: after the driver is loaded into the memory, checking whether the driver is modified during the loading process; The key information of the driver is determined without being modified during the process.

In a possible implementation manner, the checking whether the driver is modified during the loading process includes: after the driver is loaded into the memory, checking the driver, the checking includes At least one of hash verification and certificate signature verification; if the verification is passed, align and relocate the driver; judge whether the driver is loaded during the loading process according to the driver image Revise.

In a possible implementation manner, the determining whether the driver program is modified during the loading process according to the driver image includes: separately calculating a hash value of the driver image and a hash value of the driver program; If the hash value of the driver image is the same as the hash value of the driver, it is determined that the driver has not been modified during the loading process.

In a possible implementation manner, determining the key information of the driver includes: in the case that the driver is modified during the loading process, repairing the driver according to the driver image; After the repair is complete, identify key information about the driver in question.

In a possible implementation manner, the method further includes: registering the callback function of the driver program through a self-defined callback registration function after determining the callback function information.

In a possible implementation manner, the method further includes: storing the key information, the first thread information, the second thread information, and the third thread information in a preset storage area, The storage area is a storage area that only allows writing once.

According to another aspect of the present disclosure, a driver protection device is provided, the device comprising: a first information determining module, configured to determine key information of the driver after the driver of the hardware device is loaded into the memory, The key information includes at least one of callback function table information, callback function information and dispatch function table information of the driver; the second information determination module is used to determine the first thread information, the second thread information and the third thread information. Thread information, the first thread information includes the address, length and hash value of the first code corresponding to the first thread, and the second thread information includes the address, length and hash value of the second code corresponding to the second thread , the third thread information includes the address, length and hash value of the third code corresponding to the third thread; a thread starting module, configured to start the first thread, the second thread and the third thread; The first guard module, according to the key information, the first thread information, the second thread information, and the third thread information, the first thread to the second thread, the second thread to the second thread The third thread and the driver, and the third thread guards the first thread and the driver.

In a possible implementation manner, the first guard module includes: a first guard submodule, the first thread guards the second thread according to the second thread information; the second guard submodule module, the second thread guards the callback function table, dispatch function table and the third thread of the driver according to the key information and the third thread information; the third guard sub-module, the The third thread guards the callback function of the driver and the first thread according to the key information and the first thread information.

In a possible implementation manner, the first guard submodule is configured to: the first thread calculates the hash value of the second code according to the address and length in the second thread information; When the hash value of the second code is the same as the hash value in the second thread information, the first thread checks whether the second thread exits; if the second thread does not exit Next, after the first thread sleeps for a preset period of time, it restarts execution from the following steps: the first thread calculates the hash value of the second code according to the address and length in the second thread information.

In a possible implementation manner, the first guard submodule is further configured to: when the hash value of the second code is different from the hash value in the second thread information, the The first thread repairs the second code according to the driver image, the address and the length in the information of the second thread, and the driver image is the backup of the original driver program on the hard disk in memory.

In a possible implementation manner, the first guard submodule is further configured to: when the second thread exits, the first thread restarts the second thread.

In a possible implementation manner, the second guard submodule is configured to: the second thread executes the callback function of the driver according to the callback function table information and the dispatch function table information in the key information. The table and the dispatch function table are guarded; the second thread guards the third thread according to the information of the third thread.

In a possible implementation manner, the callback function table information includes the address, length and hash value of the driver's callback function table, and the dispatch function table information includes the address of the driver's dispatch function table , length and hash value; the second thread guards the callback function table and dispatch function table of the driver according to the callback function table information and dispatch function table information in the key information, including: the first The second thread calculates the hash value of the callback function table of the driver according to the address and the length in the callback function table information; in the hash value of the callback function table of the driver and the callback function table information In the case of different hash values, the second thread repairs the callback function table of the driver according to the driver image, the address and the length in the callback function table information; the second thread repairs the callback function table according to the Address and length in the dispatch function table information, calculate the hash value of the dispatch function table of the driver; the hash value of the dispatch function table of the driver is different from the hash value in the dispatch function table information In the case of , the second thread repairs the dispatch function table of the driver according to the driver image, the address and the length in the dispatch function table information.

In a possible implementation manner, the third guard submodule is configured to: the third thread guards the callback function of the driver according to the callback function information in the key information; The three threads guard the first thread according to the first thread information.

In a possible implementation manner, the callback function information includes addresses, lengths, and hash values of all callback functions of the driver; the third thread, according to the callback function information in the key information, The callback function of the driver is guarded, including: for any callback function of the driver, the third thread calculates the hash value of the callback function according to the address and length of the callback function in the callback function information ; When the hash value of the callback function is different from the reference hash value, the second thread assigns the callback function to the callback function according to the address and length of the callback function in the driver image and the callback function table information The code is repaired, and the reference hash value is the hash value of the callback function in the callback function information.

In a possible implementation manner, the device further includes: a second guard module, where the interrupt service of the driver program guards the first thread.

In a possible implementation manner, the second guard module includes: a first calculation submodule, before the interrupt service of the driver executes interrupt processing, the interrupt service address and length, calculating the hash value of the first code; the first checking submodule, when the hash value of the first code is the same as the hash value in the first thread information, the The interrupt service checks whether the first thread exits; the submodule is executed, and if the first thread does not exit, the interrupt service executes the interrupt processing.

In a possible implementation manner, the apparatus further includes: a third guard module, where firmware of the hardware device guards the interrupt service.

In a possible implementation manner, the key information further includes the interrupt processing function information corresponding to the interrupt service, and the interrupt processing function information includes the address, length and hash value of the interrupt processing function corresponding to the interrupt service The third guardian module includes: a second computing submodule, the firmware calculates the hash value of the interrupt processing function according to the address and length in the interrupt processing function information; the dormancy submodule, in the In the case where the hash value of the interrupt processing function is the same as the hash value in the interrupt processing function information, after the firmware sleeps for a preset period of time, it starts to execute again from the following steps: the firmware executes according to the interrupt processing function The address and length in the information are used to calculate the hash value of the interrupt processing function.

In a possible implementation manner, the third guard module includes: an interrupt service stop submodule, and when the hash value of the interrupt processing function is different from the hash value in the interrupt processing function information , the firmware controls the hardware device to stop sending interrupt requests, so as to stop the interrupt service; the repair submodule, the firmware executes the interrupt processing function according to the drive image, the address and the length in the interrupt processing function information Repairing: the interrupt service recovery sub-module, after the repair is completed, the firmware controls the hardware device to resume sending the interrupt request, so as to resume the interrupt service.

In a possible implementation manner, the first information determining module includes: a second checking submodule, after the driver is loaded into the memory, checks whether the driver is modified during the loading process; the information determining The submodule determines the key information of the driver under the condition that the driver is not modified during the loading process.

In a possible implementation manner, the second checking submodule is configured to: verify the driver after the driver is loaded into the memory, and the verification includes hash verification, certificate At least one of signature verification; if the verification is passed, align and relocate the driver; judge whether the driver is modified during the loading process according to the driver image.

In a possible implementation manner, the determining whether the driver program is modified during the loading process according to the driver image includes: separately calculating a hash value of the driver image and a hash value of the driver program; If the hash value of the driver image is the same as the hash value of the driver, it is determined that the driver has not been modified during the loading process.

In a possible implementation manner, the information determination submodule is configured to: repair the driver according to the driver image when the driver is modified during the loading process; Once complete, identify the key information for the driver in question.

In a possible implementation manner, the device further includes: a registration module, configured to register the callback function of the driver through a self-defined callback registration function after determining the callback function information.

In a possible implementation manner, the device further includes: a storage module, configured to store the key information, the first thread information, the second thread information, and the third thread information in a preset A storage area is provided, and the storage area is a storage area that only allows writing once.

The driver protection method of the embodiment of the present disclosure can determine the key information of the driver after the driver of the hardware device is loaded into the memory, and determine the first thread information, the second thread information, and the third thread information, and then start the first thread, the second thread and the third thread, after the startup is successful, according to the key information, the first thread information, the second thread information and the third thread information, the first thread to the second thread, the second thread to the third thread and the driver The program and the third thread guard the first thread and the driver, so that the driver can be guarded in a circular manner through the first thread, the second thread and the third thread, so as to prevent the driver from being hijacked and improve the driver performance. program security.

Other features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the accompanying drawings.

Description of drawings

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate exemplary embodiments, features, and aspects of the disclosure and, together with the specification, serve to explain the principles of the disclosure.

FIG. 1 shows a flowchart of a driver protection method according to an embodiment of the present disclosure.

Fig. 2 shows a schematic diagram of a driver protection method according to an embodiment of the present disclosure.

Fig. 3 shows a schematic diagram of a first thread daemon process according to an embodiment of the present disclosure.

Fig. 4 shows a schematic diagram of a second thread daemon process according to an embodiment of the present disclosure.

Fig. 5 shows a schematic diagram of a third thread daemon process according to an embodiment of the present disclosure.

FIG. 6 shows a schematic diagram of an interrupt service daemon process according to an embodiment of the present disclosure.

FIG. 7 shows a schematic diagram of a firmware daemon process according to an embodiment of the present disclosure.

Fig. 8 shows a schematic diagram of a driver protection method according to an embodiment of the present disclosure.

FIG. 9 shows a block diagram of a driver guard according to an embodiment of the present disclosure.

Detailed ways

Various exemplary embodiments, features, and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numbers in the figures indicate functionally identical or similar elements. While various aspects of the embodiments are shown in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

The word "exemplary" is used exclusively herein to mean "serving as an example, embodiment, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as superior or better than other embodiments.

In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following specific implementation manners. It will be understood by those skilled in the art that the present disclosure may be practiced without some of the specific details. In some instances, methods, means, components and circuits that are well known to those skilled in the art have not been described in detail so as to obscure the gist of the present disclosure.

The driver protection method of the embodiment of the present disclosure can be used to protect the driver of the hardware device, so as to prevent the driver from being hijacked. The driver protection method of the embodiments of the present disclosure can be applied to electronic devices, and the electronic devices include hardware devices such as graphics cards, network cards, and sound cards. The electronic equipment may be, for example, a terminal equipment, a server, and the like. The present disclosure does not limit specific types of electronic devices and hardware devices. In addition, the present disclosure does not limit the type of the operating system carried by the electronic device.

FIG. 1 shows a flowchart of a driver protection method according to an embodiment of the present disclosure. As shown in Figure 1, the driver protection method includes:

Step S110, after the driver of the hardware device is loaded into the memory, determine the key information of the driver, the key information includes at least one of the driver's callback function table information, callback function information, and dispatch function table information kind;

Step S120, determine the first thread information, the second thread information and the third thread information, the first thread information includes the address, length and hash value of the first code corresponding to the first thread, the second thread information includes The address, length and hash value of the second code corresponding to the second thread, and the third thread information includes the address, length and hash value of the third code corresponding to the third thread;

Step S130, starting the first thread, the second thread and the third thread;

Step S140, according to the key information, the first thread information, the second thread information and the third thread information, the first thread to the second thread, the second thread to the A third thread and the driver, and the third thread guards the first thread and the driver.

In a possible implementation manner, after the electronic device is powered on and started, the operating system obtains the driver program of the hardware device from the hard disk, and loads the driver program into the memory. The memory here refers only to the computer's system memory.

In a possible implementation, after the operating system loads the driver of the hardware device into the memory, the driver starts to run, and in step S110, the key information of the driver can be determined, and the key information can include the callback function of the driver At least one of table information, callback function information, and dispatch function table information.

In a possible implementation manner, the callback function table is a list of all callback functions in the driver program. For example, assuming that there are 20 callback functions in the driver program, then the callback function table is a list formed by the function names of the 20 callback functions. The callback function table information may include the name, address, length, hash value (Hash) and the like of the callback function table.

In a possible implementation manner, the callback function information may include the function name, address, length, hash value, etc. of each callback function in the driver. For example, assuming that there are 20 callback functions in the driver program, which are respectively callback function 1, callback function 2, ..., callback function 20, then the callback function information may include the function name, address, length and hash value of callback function 1 , the function name, address, length and hash value of the callback function 2, ..., the function name, address, length and hash value of the callback function 20.

In a possible implementation manner, the dispatch function table is a list of all dispatch functions in the driver program. For example, assuming that there are 30 dispatch functions in the driver program, then the dispatch function table is a list formed by the function names of the 30 dispatch functions. The dispatch function table information may include the name, address, length, hash value, etc. of the dispatch function table.

It should be noted that, in addition to the above-mentioned callback function table information, callback function information, and dispatch function table information, the key information of the driver program may also include other information, and those skilled in the art may determine the specific content of the key information of the driver program according to the actual situation. setting, the disclosure does not limit this.

In a possible implementation manner, after the key information of the driver is determined, step S120 may be executed to determine the first thread information, the second thread information and the third thread information. Wherein, the first thread information may include the address of the first code corresponding to the first thread (for example, starting address, etc.), length and hash value, and the second thread information may include the address of the second code corresponding to the second thread (for example, start address, etc.), length and hash value, the third thread information may include the address (such as start address, etc.), length and hash value of the third code corresponding to the third thread. The first thread, the second thread and the third thread can be regarded as the daemon process of the driver. In one example, the code of the first thread, the second thread and the third thread may be integrated into the code of the driver.

In a possible implementation manner, after the first thread information, the second thread information, and the third thread information are determined, step S130 may be executed to start the first thread, the second thread, and the third thread. In one example, the first thread, the second thread, and the third thread can be started by a driver.

In a possible implementation, after starting the first thread, the second thread, and the third thread, step S140 may be executed, and according to the key information, the first thread information, the second thread information, and the third thread information, the first thread The second thread is guarded, the second thread is guarded against the third thread and the driver, and the third thread is guarded against the first thread and the driver.

Wherein, the second thread and the third thread can respectively guard different contents of the driver. For example, the second thread guards the callback function table and dispatch function table of the driver, and the third thread guards the callback function of the driver; or, the second thread guards the callback function of the driver, and the third thread guards the driver's callback function. The callback function table and the dispatch function table of the program are guarded; or, the second thread guards the callback function table and the callback function, and the third thread guards the driver's dispatch function table.

It should be noted that those skilled in the art can determine the specific content of the driver programs guarded by the second thread and the third thread respectively according to the actual situation, which is not specifically limited in the present disclosure.

In a possible implementation, when the first thread guards the second thread, it can check whether the second thread is hijacked (such as being hooked or patched), and if the second thread is hijacked, then according to the second thread Thread information, repair the second code corresponding to the second thread; if the second thread is not hijacked, check whether the second thread exits, if the second thread has exited, restart the second thread; if the second thread is not Exit, the first thread sleeps for a preset period of time (such as 15ms, 20ms, etc.), and then starts to execute the next guard.

In a possible implementation, assuming that the second thread guards the driver's callback function table and dispatch function table, when the second thread guards the third thread and the driver program, it can check the driver's callback function table, Whether the dispatch function table is modified, if the driver's callback function table or dispatch function table is modified, then according to the callback function table information or dispatch function table information in the key information, the driver's callback function table or dispatch function table is repaired .

If the callback function table and the dispatch function table of the driver are not modified, the second thread can check whether the third thread is hijacked, and if the third thread is hijacked, then according to the third thread information, the third code corresponding to the third thread Make repairs. If the 3rd thread is not hijacked, then check whether the 3rd thread exits, if the 3rd thread exits, then restart the 3rd thread. If the third thread does not exit, the second thread sleeps (sleep) for a preset period of time (for example, 15ms, 20ms, etc.), and then starts to execute the next guard.

In a possible implementation, assuming that the third thread guards the callback function of the driver, when the third thread guards the first thread and the driver, it can check whether the callback function of the driver has been modified. If the driver If the callback function of the driver is modified, the callback function of the driver is repaired according to the callback function information in the key information.

If the callback function of the driver program has not been modified, the third thread can check whether the first thread is hijacked, and if the first thread is hijacked, repair the first code corresponding to the first thread according to the information of the first thread. If the first thread is not hijacked, then check whether the first thread exits, if the first thread has exited, restart the first thread. If the first thread does not exit, the third thread sleeps (sleep) for a preset period of time (for example, 15ms, 20ms, etc.), and then starts to execute the next guard.

Fig. 2 shows a schematic diagram of a driver protection method according to an embodiment of the present disclosure. As shown in Figure 2, the first thread 210 guards the second thread 220, the second thread 220 guards the dispatch function table 241 and the callback function table 242 of the third thread 230 and the driver 240, and the third thread 230 guards the third thread 230 and the dispatch function table 241 of the driver 240. A thread 210 and a callback function 243 of the driver 240 are guarded.

As shown in Figure 2, the first thread 210, the second thread 220, the third thread 230 guard the driver 240 in a circular manner, like this, in the first thread 210, the second thread 220, the third thread 230 In the case of any one or any two abnormalities (hijacked or exited), it can also be quickly recovered by running normal threads, so that the protection of the driver 240 is not easy to be destroyed, and the protection effect is improved.

For example, assuming that both the first thread 210 and the second thread 220 are abnormal and have exited, and the third thread 230 is running normally, in this case, when the third thread 230 guards the first thread 210, it will restart the first thread 210 After the first thread 210 is started, when the second thread 220 is guarded, the second thread 220 will be restarted, thereby restoring the circular guarding of the driver 240 by the first thread 210, the second thread 220, and the third thread 230.

The driver protection method of the embodiment of the present disclosure can determine the key information of the driver after the driver of the hardware device is loaded into the memory, and determine the first thread information, the second thread information, and the third thread information, and then start the first thread, the second thread and the third thread, after the startup is successful, according to the key information, the first thread information, the second thread information and the third thread information, the first thread to the second thread, the second thread to the third thread and the driver The program and the third thread guard the first thread and the driver, so that the driver can be guarded in a circular manner through the first thread, the second thread and the third thread, so as to prevent the driver from being hijacked and improve the driver performance. program security.

In a possible implementation manner, after the driver program is loaded into the memory and starts running, the driver program can back up the original driver program on the hard disk in the memory to obtain a driver image. That is to say, the driver image is an in-memory backup of the original driver on the hard disk. During the driver protection process, the driver image can be used as a reference file for driver comparison or repair.

In a possible implementation, step S110 may include: after the driver is loaded into memory, check whether the driver is modified during the loading process; case, identify key information about the driver.

In a possible implementation, after the operating system loads the driver into the memory, it can first check whether the driver has been modified during the loading process. For example, the original driver on the hard disk and the driver loaded into the memory can be Compare the program to check whether the driver is modified during the loading process, or check whether the driver is modified during the loading process by comparing the driver image with the driver loaded into the memory. In the case that the driver has not been modified during the loading process, then determine the key information of the driver.

In this way, after the driver is loaded into memory, it is possible to check whether the driver has been modified during the loading process, and determine the key information of the driver if the driver has not been modified during the loading process, thereby preventing Drivers are intercepted or corrupted during loading, improving the accuracy of critical information.

In a possible implementation manner, the checking whether the driver program is modified during the loading process may include: after the driver program is loaded into the memory, verifying the driver program, the verifying Including at least one of hash verification and certificate signature verification; in the case of passing the verification, performing alignment and relocation processing on the driver; judging whether the driver is loaded during the loading process according to the driver image modified.

In a possible implementation manner, when checking whether the driver is modified during the loading process, the driver may first be verified. Since the driver starts to run after the operating system loads the driver into the memory, the verification of the driver here can be regarded as the self-verification of the driver. The verification of the driver may include at least one of hash verification and certificate signature verification. For example, when verification includes hash verification and certificate signature verification, hash verification and certificate signature verification can be performed on the driver respectively. Pass, otherwise it can be considered that the driver verification has not passed.

Wherein, the hash verification can be, for example: calculate the hash value of the driver program loaded into the memory through a preset hash algorithm (such as Secure Hash Algorithm 256 (SHA256), etc.), and load it into the memory If the hash value of the driver is the same as the preset hash value of the driver, the hash verification is considered to pass, otherwise, the hash verification is considered to fail. The certificate signature verification can be used to verify the relevant organization, digest algorithm, encryption and decryption algorithm, etc. of the current certificate of the driver, and the certificate signature verification of the driver can be performed through the existing related technologies. It should be noted that the present disclosure does not limit the specific hash algorithm and the specific method of certificate signature verification. The driver program loaded into memory is verified by at least one of hash verification and certificate signature verification, which can prevent the driver program loaded into memory from being replaced by other malicious drivers.

In the case that the driver program verification fails, a prompt message can be sent to the user, such as "driver program verification failed", "driver program error", etc., and the user can also be prompted to deal with it, such as "please try again. Install the driver", "Please update the driver", etc. The present disclosure does not limit the specific content of the prompt information.

When the driver program is verified and passed, the driver program loaded into the memory can be aligned (aligned from the hard disk to the memory) and relocated. Import or export tables also need to be repaired if they exist for the driver.

In a possible implementation manner, after the driver program is aligned and relocated, it can be determined whether the driver program has been modified during the loading process according to the driver image. In one example, it may be determined whether the driver is modified during loading by directly comparing the driver image with the driver loaded into memory. In another example, the hash value of the driver image and the hash value of the driver program loaded into the memory can be calculated separately, and then it is determined whether the driver program has been modified during the loading process by comparing the hash values.

In a possible implementation, when judging whether the driver is modified during the loading process according to the driver image, the hash value of the driver image and the hash value of the driver loaded into the memory can be calculated respectively through a preset hash algorithm. hash value, and then determine whether the hash value of the driver image is the same as the hash value of the driver loaded into memory. If the two hash values are the same, it can be determined that the driver has not been modified during the loading process; if the two hash values are different, it can be determined that the driver has been modified during the loading process. Among them, when calculating the hash value of the driver image, the hash value of the entire driver image can be calculated, and the hash value of key areas such as the code area and data area of the driver image can also be calculated; correspondingly, the driver program loaded into the memory is calculated When the hash value is calculated, the hash value of the entire driver program can be calculated, and the hash value of key areas such as the code area and data area of the driver program can also be calculated, which is not limited in the present disclosure. In this way, it is possible to quickly judge whether the driver program has been modified during the loading process, thereby improving processing efficiency.

In a possible implementation manner, if the driver is modified during the loading process, the driver may be repaired according to the driver image, and key information of the driver may be determined after the driver is repaired. In this way, the driver program modified during the loading process can be repaired, and the key information of the driver program can be determined after the driver program is repaired, thereby improving the accuracy of the key information.

In this embodiment, when checking whether the driver is modified during the loading process, firstly, after the driver is loaded into the memory, the driver is verified, and if the verification is passed, the driver is aligned and reset. Locating processing, and then judging whether the driver is modified during the loading process according to the driver image. In this way, it is possible to quickly and accurately check whether the driver is modified during the loading process, and the processing efficiency can be improved.

In a possible implementation, when the key information of the driver includes callback function table information, when determining the key information of the driver, the callback function table in the driver can be obtained and the name of the callback function table can be determined , address, length, and calculate the hash value of the callback function table through a preset hash algorithm, and then determine the callback function table information of the driving function according to the name, address, length, and hash value of the callback function table.

In a possible implementation, when the key information of the driver includes dispatch function table information, when determining the key information of the driver, the dispatch function table in the driver can be obtained and the name of the dispatch function table can be determined , address, length, and calculate the hash value of the dispatch function table through a preset hash algorithm, and then determine the dispatch function table information of the driving function according to the name, address, length, and hash value of the dispatch function table.

In a possible implementation, when the key information of the driver includes callback function information, when determining the key information of the driver, for any callback function in the driver, the name, The address, length, and the hash value of the callback function are calculated through a preset hash algorithm, and then the callback function information of the driver is determined according to the name, address, length, and hash value of all callback functions.

In a possible implementation manner, after determining the callback function information of the driver, the callback function of the driver may be registered through a custom callback registration function. For example, when the operating system is a Windows operating system and the hardware device is a graphics card, after determining the callback function information of the graphics card driver, the callback function of the graphics card driver can be registered with the dxgkrnl graphics kernel subsystem through a self-defined callback registration function , to complete the registration of the callback function of the graphics card driver. Registering the callback function of the driver through the self-defined callback registration function can avoid the interception or destruction of malicious programs during the callback function registration process, thereby improving the security of the driver.

In a possible implementation manner, the method further includes: storing the key information, the first thread information, the second thread information, and the third thread information in a preset storage area, The storage area is a storage area that only allows writing once.

Wherein, the preset storage area is a specially set storage area (TrustZone) trusted by the driver. During normal use of the hardware device, this storage area can only be written once, but can be read multiple times. The storage area can only be rewritten when the driver is upgraded, the driver is reinstalled, or the electronic device is restarted.

In a possible implementation manner, the preset storage area may be located in the internal memory of the hardware device or integrated in the memory card of the device. For example, in the case that the hardware device is a graphics card, the preset storage area may be located in the video memory or in a built-in storage card of the graphics card. Those skilled in the art can determine the specific location of the storage area according to actual conditions, which is not limited in the present disclosure.

In a possible implementation manner, when storing the key information, first thread information, second thread information, and third thread information in a preset storage area, it can also be encrypted, thereby improving the key information, the second thread information The security of the first thread information, the second thread information and the third thread information. Wherein, the encryption algorithm used in the encryption processing can be set according to the actual situation, which is not limited in the present disclosure.

In this embodiment, writing the key information, the first thread information, the second thread information and the third thread information into the preset storage area can prevent the key information, the first thread information, the second thread information and the third thread information from being Tampered by malicious programs, so that key information, first thread information, second thread information and third thread information can be protected to improve its security.

It should be noted that the key information of the above-mentioned driver is determined, the first thread information, the second thread information and the third thread information are determined, the callback function of the driver is registered, the key information, the first thread information, the second thread Related operations such as storing the information and the information of the third thread into a preset storage area can be implemented in the initialization process of the hardware device.

In a possible implementation manner, step S140 may include: the first thread guarding the second thread according to the second thread information; the second thread guarding the second thread according to the key information and the first thread Three thread information, guarding the callback function table, the dispatch function table and the third thread of the driver; the third thread, according to the key information and the first thread information, guards the driver's The callback function and the first thread are guarded.

That is to say, the first thread can guard the second thread by using the information of the second thread as the guarding basis; the second thread can use the key information of the driver program and the third thread information as the guarding basis to call back the driver The function table, the dispatch function table and the third thread are guarded; the third thread can use the key information of the driver program and the information of the first thread as the basis for guarding, and guard the callback function of the driver program and the first thread. In this way, the processing efficiency in the driver protection process can be improved.

In a possible implementation manner, the first thread guarding the second thread according to the second thread information includes: the first thread according to the address and length in the second thread information , calculate the hash value of the second code; in the case that the hash value of the second code is the same as the hash value in the second thread information, the first thread checks the second thread Whether to exit; in the case that the second thread does not exit, after the first thread sleeps for a preset period of time, it starts to execute again from the following steps: the first thread executes according to the address in the second thread information and length, calculating the hash value of the second code.

In a possible implementation manner, when the first thread guards the second thread according to the second thread information, it may first calculate the hash value of the second code according to the address and length in the second thread information. Specifically, for example: the first thread can determine the first area where the second code is located according to the address and length in the second thread information (that is, the address and length of the second code), and then calculate the second code through a preset hash algorithm. A hash value of a second code in a zone.

Then it can be judged whether the calculated hash value of the second code is the same as the hash value in the second thread information (the original hash value of the second code). If the hash values in the information of the two threads are the same, the first thread thinks that the second thread has not been hijacked, and can check whether the second thread has exited; if the second thread has not exited, the first thread completes the guarding. After sleeping for a preset period of time (such as 15ms, 20ms, etc.), start to execute the next guard, that is, from the step "the first thread calculates the second code according to the address and length in the second thread information hash value" to start re-execution. Wherein, the specific value of the preset duration can also be other, such as 10ms, 25ms and so on. Those skilled in the art can set the specific value of the preset duration according to the actual situation, which is not limited in the present disclosure.

In this embodiment, the first thread can realize the guarding of the second thread by checking whether the second thread is hijacked or whether the second thread exits, so that when the second thread is hijacked or the second thread exits, the The second thread does fast recovery.

In a possible implementation, if the calculated hash value of the second code is different from the hash value in the second thread information, it can be considered that the second thread is hijacked (for example, hooked or beaten) Patch), the second code corresponding to the second thread needs to be repaired. In this case, the first thread can repair the second code according to the driver image and the address and length in the second thread information. Specifically, for example: the first thread may reacquire the second code from the driver image according to the address and length in the second thread information, and use the reacquired second code to repair the second code corresponding to the second thread. In this way, a hijacked second thread can be quickly repaired.

It should be noted that in the process of repairing the second code above, the memory bus can be locked (lock) to prevent other concurrent operations (such as operations such as processor instruction fetching) during the repair process, which may cause electronic equipment to malfunction. Abnormal (such as crash or blue screen, etc.), after the repair is completed, the lock of the memory bus will be automatically released.

In a possible implementation manner, when the second thread exits, the first thread restarts the second thread. After the second thread starts successfully, the first thread completes this guarding, sleeps (sleep) for a preset period of time (such as 15ms, 20ms, etc.), and then starts to execute the next guarding, that is, from the step "the first thread according to the first thread address and length in the second thread information, calculate the hash value of the second code" and start re-executing. In this way, the exited second thread can be quickly resumed.

In a possible implementation manner, the first thread may record the number of repair times of the second thread and the number of restart times of the second thread. For example, after the first thread repairs the second code corresponding to the second thread, the number of repairs of the second thread can be increased by 1; after the first thread restarts the second thread, the number of restarts of the second thread can be increased by 1. By recording the number of repair times of the second thread and the number of times of restart of the second thread, it is convenient to analyze the operation of the second thread later, so as to find weak links in the driver protection process.

Fig. 3 shows a schematic diagram of a first thread daemon process according to an embodiment of the present disclosure. In this embodiment, the second thread information is stored in a preset storage area.

As shown in Figure 3, the process that the first thread guards the second thread may include the following steps:

Step S301, acquiring second thread information from a preset storage area;

Step S302, calculating the hash value of the second code according to the address and length in the second thread information;

Step S303, judging whether the calculated hash value of the second code is the same as the hash value in the second thread information;

In the case that the calculated hash value of the second code is the same as the hash value in the second thread information, perform step S304 to check whether the second thread exits;

In the case that the second thread does not exit, execute step S305 to sleep for a preset duration; then execute the next guard, and restart execution from step S301.

In the case that the calculated hash value of the second code is not the same as the hash value in the second thread information, step S306 is performed, and the second code is processed according to the drive image and the address and length in the second thread information. Repair; then execute step S304.

In the case that the second thread exits, execute step S307 to restart the second thread; then execute step S305.

In a possible implementation, the second thread guards the driver's callback function table, dispatch function table, and the third thread according to the key information and the third thread information, including: : the second thread guards the callback function table and the dispatch function table of the driver according to the callback function table information and the dispatch function table information in the key information; the second thread guards the callback function table and the dispatch function table according to the third thread information, guarding the third thread.

That is to say, when the second thread guards the driver's callback function table, dispatch function table, and third thread, it can use the callback function table information and dispatch function table information in the key information as the basis for guarding, and the driver's callback The function table and dispatch function table are guarded, and the information of the third thread is used as a basis for guarding to guard the third thread. In this way, the processing efficiency when the second thread is guarding can be improved.

It should be noted that when the second thread guards the driver's callback function table, dispatch function table, and third thread, it can first execute the guard of the callback function table and dispatch function table, and then execute the guard of the third thread; It is also possible to execute the guarding of the third thread first, and then execute the guarding of the callback function table and the dispatching function table; or set other execution orders according to the actual situation, which is not limited in this disclosure.

In a possible implementation, the callback function table information in the key information may include the address, length and hash value of the driver's callback function table, and the dispatch function table information in the key information may include the driver's dispatch function table address, length and hash value;

The second thread guards the callback function table and the dispatch function table of the driver according to the callback function table information and the dispatch function table information in the key information, which may include: the second thread according to the callback address and length in the function table information, calculate the hash value of the callback function table of the driver; if the hash value of the callback function table of the driver is different from the hash value in the callback function table information In this case, the second thread repairs the callback function table of the driver according to the driver image, the address and the length in the callback function table information; the second thread repairs the callback function table of the driver according to the address and length, calculate the hash value of the dispatch function table of the driver; if the hash value of the dispatch function table of the driver is different from the hash value in the dispatch function table information, the The second thread repairs the dispatch function table of the driver according to the driver image, the address and the length in the dispatch function table information.

In a possible implementation, when the second thread guards the callback function table and the dispatch function table of the driver, it can first execute the guard of the callback function table, and then execute the guard of the dispatch function table, or execute The guarding of the dispatch function table is followed by the guarding of the callback function table. In the following, taking the guarding of the callback function table first and then the dispatching function table as an example, the process of guarding the callback function table and the dispatching function table of the driver program by the second thread will be exemplarily described.

In a possible implementation manner, when the second thread guards the callback function table of the driver, it may first calculate the hash value of the callback function table of the driver according to the address and length in the callback function table information. Specifically, for example: the second thread can determine the second area where the callback function table of the driver is located according to the address and length in the callback function table information, and then calculate the callback function table in the second area through a preset hash algorithm hash value.

Then it can be judged whether the calculated hash value of the callback function table of the driver is the same as the hash value in the callback function table information (the hash value of the original callback function table). If the hash value is the same as the hash value in the callback function table information, it can be considered that the callback function table of the driver has not been hijacked.

If the calculated hash value of the callback function table of the driver is different from the hash value in the callback function table information, it can be considered that the callback function table of the driver has been hijacked, and the callback function table of the driver needs to be repaired. In this case, the second thread can repair the callback function table of the driver according to the driver image and the address and length in the callback function table information. Specifically, for example: the second thread can reacquire the callback function table from the driver image according to the address and length in the callback function table information, and then determine the driver's address by item by item comparison according to the reacquired callback function table. Calls back the different items in the function table and fixes the different items.

In a possible implementation manner, when the second thread guards the dispatch function table of the driver, it may first calculate the hash value of the dispatch function table of the driver according to the address and length in the dispatch function table information. Specifically, for example: the second thread can determine the third area where the driver's dispatch function table is located according to the address and length in the dispatch function table information, and then calculate the dispatch function table in the third area through a preset hash algorithm hash value.

Then it can be judged whether the calculated hash value of the dispatch function table of the driver is the same as the hash value in the dispatch function table information (the hash value of the original dispatch function table). If the hash value is the same as the hash value in the dispatch function table information, it can be considered that the dispatch function table of the driver has not been hijacked.

If the calculated hash value of the dispatch function table of the driver is different from the hash value in the dispatch function table information, it can be considered that the dispatch function table of the driver has been hijacked, and the dispatch function table of the driver needs to be repaired. In this case, the second thread can repair the dispatch function table of the driver according to the driver image, the address and the length in the dispatch function table information. Specifically, for example: the second thread can re-acquire the dispatch function table from the driver image according to the address and length in the dispatch function table information, and then determine the driver's address by item-by-item comparison based on the re-acquired dispatch function table. Dispatch and fix up the different entries in the function table.

In this way, the second process can guard the callback function table and dispatch function table of the driver, and then indirectly realize the guard of the callback function and dispatch function of the driver.

In a possible implementation manner, the second thread guarding the third thread according to the third thread information may include: the second thread according to the address and length, calculating the hash value of the third code; in the case that the hash value of the third code is the same as the hash value in the third thread information, the second thread checks the third Whether the thread exits; in the case that the third thread does not exit, the second thread starts to execute the next guard after the preset period of dormancy.

In a possible implementation manner, when the second thread guards the third thread according to the third thread information, it may first calculate the hash value of the third code according to the address and length in the third thread information. Specifically, for example: the second thread can determine the fourth area where the third code is located according to the address and length in the information of the third thread (that is, the address and length of the third code), and then use a preset hash algorithm to calculate the fourth area. The hash value of the third code in the quad area.

Then it can be judged whether the calculated hash value of the third code is the same as the hash value in the third thread information (the original hash value of the third code). When the hash values in the information of the three threads are the same, the second thread thinks that the third thread has not been hijacked, and can check whether the third thread has exited; if the third thread has not exited, the second thread completes the guarding. After sleeping for a preset period of time (such as 15ms, 20ms, etc.), the next guard is executed, that is, the second thread re-executes the guard of the driver's callback function table, dispatch function table and the third thread.

Wherein, the specific value of the preset duration can also be other, such as 10ms, 25ms and so on. Those skilled in the art can set the specific value of the preset duration according to the actual situation, which is not limited in the present disclosure.

In this embodiment, the second thread can realize the guarding of the third thread by checking whether the third thread is hijacked or whether the third thread exits, so that when the third thread is hijacked or the third thread exits, The third thread does fast recovery.

In a possible implementation, if the calculated hash value of the third code is different from the hash value in the third thread information, it can be considered that the third thread is hijacked (for example, hooked or beaten) Patch), the third code corresponding to the third thread needs to be repaired. In this case, the second thread can repair the third code according to the driver image and the address and length in the information of the third thread. Specifically, for example: the second thread may reacquire the third code from the driver image according to the address and length in the information of the third thread, and use the reacquired third code to repair the third code corresponding to the third thread. In this way, a hijacked third thread can be quickly repaired.

In a possible implementation manner, when the third thread exits, the second thread restarts the third thread. After the third thread starts successfully, the second thread completes this guarding, sleeps for a preset period of time (such as 15ms, 20ms, etc.), and then starts to execute the next guarding. In this way, the exited third thread can be quickly resumed.

It should be noted that, in the process of repairing the third code, the callback function table of the driver, and the dispatch function table above, the memory bus can be locked (locked) to prevent other concurrent operations during the repair process (such as processing Instruction fetching and other operations), resulting in abnormal electronic equipment (such as crash or blue screen, etc.), after the repair is completed, the lock of the memory bus will be automatically released.

In a possible implementation manner, the second thread may record the number of callback function table repairs, dispatch function table repair times, third thread repair times, and third thread restart times. For example, after the second thread repairs the callback function table of the driver, the number of repairs to the callback function table can be added by 1; after the second thread repairs the dispatch function table of the driver, the number of repairs of the dispatch function table can be added by 1; After the second thread repairs the third code corresponding to the third thread, the number of repairs of the third thread can be increased by 1; after the second thread restarts the third thread, the number of restarts of the third thread can be increased by 1.

By recording the number of callback function table repairs, the number of dispatch function table repairs, the number of third thread repairs, and the number of restarts of the third thread, it is convenient to follow up on the callback function table, dispatch function table, and third thread during the running of the driver. Analyze the operation of the driver to find the weak link in the driver protection process.

Fig. 4 shows a schematic diagram of a second thread daemon process according to an embodiment of the present disclosure. In this embodiment, the third thread information and the key information of the driver are stored in a preset storage area. During the guarding process, the second thread first executes the guarding of the callback function table, and then executes the guarding of the dispatching function table and the third thread.

As shown in Figure 4, the process that the second thread guards the callback function table, the dispatch function table and the third thread may include the following steps:

Step S401, obtaining third thread information, callback function table information and dispatch function table information in key information from a preset storage area;

Step S402, calculating the hash value of the callback function table of the driver according to the address and length in the callback function table information;

Step S403, judging whether the calculated hash value of the callback function table is the same as the hash value in the callback function table information;

When the calculated hash value of the callback function table is the same as the hash value in the callback function table information, execute step S404; calculate the hash of the dispatch function table of the driver according to the address and length in the dispatch function table information Greek value;

Step S405, judging whether the calculated hash value of the dispatch function table is the same as the hash value in the dispatch function table information;

In the case that the calculated hash value of the dispatch function table is the same as the hash value in the dispatch function table information, perform step S406: calculate the hash value of the third code according to the address and length in the third thread information;

Step S407, judging whether the calculated hash value of the third code is the same as the hash value in the third thread information;

In the case that the calculated hash value of the third code is the same as the hash value in the information of the third thread, perform step S408 to check whether the third thread exits;

In the case that the third thread does not exit, execute step S409 to sleep for a preset duration; then execute the next guard, and restart execution from step S401.

In the case that the hash value of the calculated callback function table is different from the hash value in the callback function table information, step S410 is performed, and the callback function of the driver is set according to the address and length in the driver image and the callback function table information. The table is repaired, and then step S404 is performed.

In the case that the calculated hash value of the dispatch function table is different from the hash value in the dispatch function table information, execute step S411, according to the address and length in the driver image and dispatch function table information, the dispatch function of the driver The table is repaired, and then step S406 is executed.

In the case that the calculated hash value of the third code is different from the hash value in the third thread information, perform step S412, and repair the third code according to the driver image and the address and length in the third thread information ; Then execute step S408.

In the case that the third thread exits, execute step S413 to restart the third thread; then execute step S409.

In a possible implementation manner, the third thread guards the callback function of the driver and the first thread according to the key information and the first thread information, including: the third thread The thread guards the callback function of the driver according to the callback function information in the key information; the third thread guards the first thread according to the first thread information.

That is to say, when the third thread guards the callback function of the driver program and the first thread, it can use the callback function information in the key information as the basis for guarding, guard the callback function of the driver program, and use the information of the first thread as the basis for guarding. Guard basis, guard the first thread. In this way, the processing efficiency when the third thread is guarding can be improved.

It should be noted that when the third thread guards the callback function of the driver program and the first thread, it can first execute the guard of the callback function of the driver, and then execute the guard of the first thread; The guard of the thread is then executed to guard the callback function of the driver, which is not limited in this disclosure.

In a possible implementation manner, the callback function information of the driver may include addresses, lengths, and hash values of all callback functions of the driver; The callback function of the driver is guarded, including: for any callback function in the driver, the third thread calculates the hash of the callback function according to the address and length of the callback function in the callback function information value; in the case where the hash value of the callback function is different from the reference hash value, the second thread executes the callback function according to the driver image and the address and length of the callback function in the callback function table information. The code of the function is repaired, and the reference hash value is the hash value of the callback function in the callback function information.

In a possible implementation manner, the driver program may include multiple callback functions, and the third thread may guard all the callback functions in the driver program. For any callback function of the driver, when the third thread guards the callback function, it may first calculate the hash value of the callback function according to the address and length of the callback function in the callback function information. Specifically, for example: the third thread can determine the fifth area where the code of the callback function is located according to the address and length of the callback function in the callback function table information, and then calculate the code in the fifth area through a preset hash algorithm. and determine the hash value as the hash value of the callback function.

Then it can be judged whether the calculated hash value of the callback function is the same as the reference hash value (the hash value of the callback function in the callback function information), and the calculated hash value of the callback function is the same as the reference hash value In the case of , it can be considered that the callback function has not been hijacked.

If the calculated hash value of the callback function is different from the reference hash value, it can be considered that the callback function has been hijacked, and the code of the callback function needs to be repaired. In this case, the third thread may repair the code of the callback function according to the driver image and the address and length of the callback function in the callback function table information. Specifically, for example: the third thread can reacquire the code of the callback function from the drive image according to the address and length of the callback function in the callback function table information, and then re-acquire the code of the callback function according to the reacquired code Make repairs.

In this way, the third process can guard all the callback functions of the driver, thereby improving the safety of the driver.

In a possible implementation manner, the third thread guarding the first thread according to the first thread information may include: the third thread according to the address and length, calculating the hash value of the first code; in the case that the hash value of the first code is the same as the hash value in the information of the first thread, the third thread checks the first Whether the thread exits; in the case that the first thread does not exit, the third thread starts to execute the next guard after the preset period of dormancy.

In a possible implementation manner, when the third thread guards the first thread according to the first thread information, it may first calculate the hash value of the first code according to the address and length in the first thread information. Specifically, for example: the third thread can determine the sixth area where the first code is located according to the address and length in the first thread information (that is, the address and length of the first code), and then calculate the sixth area through a preset hash algorithm. A hash value of the first code in the six regions.

Then it can be judged whether the calculated hash value of the first code is the same as the hash value in the first thread information (the original hash value of the first code). If the hash values in the information of one thread are the same, the third thread thinks that the first thread has not been hijacked, and can check whether the first thread has exited; if the first thread has not exited, the third thread completes the guarding. After sleeping for a preset period of time (for example, 15ms, 20ms, etc.), the next guard is executed, that is, the third thread re-executes the callback function of the driver and the guard of the first thread.

Wherein, the specific value of the preset duration can also be other, such as 10ms, 25ms and so on. Those skilled in the art can set the specific value of the preset duration according to the actual situation, which is not limited in the present disclosure.

In this embodiment, the third thread can realize the guarding of the first thread by checking whether the first thread is hijacked and whether the first thread exits, so that when the first thread is hijacked or the first thread exits, The first thread does fast recovery.

In a possible implementation, if the calculated hash value of the first code is different from the hash value in the information of the first thread, it may be considered that the first thread is hijacked (for example, hooked or beaten) Patch), the first code corresponding to the first thread needs to be repaired. In this case, the third thread can repair the first code according to the drive image, the address and the length in the information of the first thread. Specifically, for example: the third thread may reacquire the first code from the driver image according to the address and length in the information of the first thread, and use the reacquired first code to repair the first code corresponding to the first thread. In this way, a quick fix can be made to the hijacked first thread.

In a possible implementation manner, when the first thread exits, the third thread restarts the first thread. After the first thread starts successfully, the third thread completes this guard, sleeps for a preset duration (such as 15ms, 20ms, etc.), and then starts to execute the next guard. In this way, the first thread that has exited can be quickly resumed.

It should be noted that, in the process of repairing the first code and the code of the callback function of the driver, the memory bus can be locked (lock) to prevent other concurrent operations (such as processor instruction fetching) etc.), causing abnormalities in electronic equipment (such as crash or blue screen, etc.), after the repair is completed, the lock of the memory bus will be automatically released.

In a possible implementation manner, the third thread may record the number of repairs of the callback function, the number of repairs of the first thread, and the number of restarts of the first thread. For example, after the third thread repairs the code of a callback function of the driver, the number of repairs of the callback function can be increased by 1; after the third thread repairs the first code corresponding to the first thread, the number of repairs of the first thread can be Add 1; after the third thread restarts the first thread, the restart times of the first thread can be increased by 1.

By recording the number of repairs of the callback function, the number of repairs of the first thread, and the number of restarts of the first thread, it is convenient for subsequent analysis of the callback function during the running of the driver and the running of the first thread to discover the driver protection process weak link in .

Fig. 5 shows a schematic diagram of a third thread daemon process according to an embodiment of the present disclosure. In this embodiment, the first thread information and the key information of the driver are stored in a preset storage area. During the guarding process, the third thread first executes the guarding of the callback function of the driver, and then executes the guarding of the first thread.

As shown in Figure 5, the process that the third thread guards the callback function of the driver program and the first thread may include the following steps:

Step S501, obtaining callback function information in first thread information and key information from a preset storage area;

Step S502, according to the address and length of each callback function in the callback function information, calculate the hash value of each callback function of the driver;

Step S503, judging whether the hash value of each callback function of the driver program is the same as the reference hash value;

In the case that the hash values of each callback function of the driver are the same as their reference hash values, step S504 is performed: calculating the hash value of the first code according to the address and length in the first thread information;

Step S505, judging whether the calculated hash value of the first code is the same as the hash value in the first thread information;

In the case that the calculated hash value of the first code is the same as the hash value in the first thread information, perform step S506 to check whether the first thread exits;

In the case that the first thread has not exited, execute step S507, sleep for a preset duration; then execute the next guard, and restart execution from step S501.

In each callback function of the driver program, when there is a callback function having a different hash value and the reference hash value, step S508 is performed to repair the code of the callback function whose hash value is different from the reference hash value; then perform the steps S504.

If the calculated hash value of the first code is different from the hash value in the first thread information, perform step S509 to repair the first code according to the drive image and the address and length in the first thread information ; Then execute step S506.

In the case that the first thread exits, execute step S510 to restart the first thread; then execute step S507.

In a possible implementation manner, the method further includes: the interrupt service of the driver program guards the first thread.

Wherein, the interrupt service of the driver can be used to respond to the call of the processor, and execute the interrupt processing related to the hardware device. For example, the hardware device sends an interrupt request to the processor, and after receiving the interrupt request, the processor performs interrupt arbitration and interrupt response, and then calls the interrupt service in the driver program of the hardware device to perform interrupt processing.

During the driver protection process, the protection effect can be improved by guarding the first thread through the interrupt service. For example, in the case of failure of the ring guard formed by the first thread, the second thread, and the third thread, the first thread can be restored by interrupting the service to the guard of the first thread, and then restored by the first thread, the second thread, etc. , The ring guard formed by the third thread.

In a possible implementation manner, the timing for the driver's interrupt service to guard the first thread may be set according to actual conditions, which is not limited in the present disclosure. In one example, the driver's interrupt service may execute a daemon for the first thread while handling each interrupt triggered by the hardware device. In another example, a special interrupt can be set in the hardware device to notify the interrupt service to guard the first thread.

In a possible implementation manner, the interrupt service of the driver program guarding the first thread includes: before the interrupt service of the driver program performs interrupt processing, the interrupt service according to the first thread Address and length in the information, calculate the hash value of the first code; in the case that the hash value of the first code is the same as the hash value in the first thread information, the interrupt service check Whether the first thread exits; if the first thread does not exit, the interrupt service executes the interrupt processing.

In a possible implementation, after the interrupt service of the driver program receives the interrupt processing, before executing the interrupt processing, the interrupt service of the driver program can calculate the address and length of the first code according to the address and length in the first thread information. hash value. Specifically, for example: the interrupt service can determine the sixth area where the first code is located according to the address and length in the first thread information (that is, the address and length of the first code), and then calculate the sixth area through the preset hash algorithm. The hash value of the first code in the zone.

Then it can be judged whether the calculated hash value of the first code is the same as the hash value in the first thread information (the original hash value of the first code). When the hash values in the information of one thread are the same, the interrupt service considers that the first thread has not been hijacked, and can check whether the first thread exits; if the first thread has not exited, the interrupt service can perform interrupt processing.

In this embodiment, the interrupt service can realize the guarding of the first thread by checking whether the first thread is hijacked and whether the first thread exits before executing the interrupt processing, so that when the first thread is hijacked or the first thread exits In the case of the first thread, the first thread is quickly restored; and after the execution of the guard to the first thread, the interrupt process is executed, so that the interrupt service can effectively combine the guard of the first thread with the execution of the interrupt process, and then Improve the protective effect.

In a possible implementation, if the calculated hash value of the first code is different from the hash value in the information of the first thread, it may be considered that the first thread is hijacked (for example, hooked or beaten) Patch), the first code corresponding to the first thread needs to be repaired. In this case, the interrupt service can repair the first code according to the driver image and the address and length in the first thread information. Specifically, for example: the interrupt service may reacquire the first code from the driver image according to the address and length in the first thread information, and use the reacquired first code to repair the first code corresponding to the first thread. In this way, a quick fix can be made to the hijacked first thread.

In a possible implementation manner, when the first thread exits, the interrupt service restarts the first thread. After the first thread starts successfully, the interrupt service completes the guarding, and then executes the interrupt processing.

It should be noted that, in the above-mentioned process of repairing the first code, the memory bus can be locked (lock) to prevent other concurrent operations (such as operations such as processor instruction fetching) during the repair process, resulting in failure of the electronic device. Abnormal (such as crash or blue screen, etc.), after the repair is completed, the lock of the memory bus will be automatically released.

In a possible implementation manner, the interrupt service may update the number of repairs of the first thread and the number of restarts of the first thread. For example, after the interrupt service repairs the first code corresponding to the first thread, the repair count of the first thread can be increased by 1; after the interrupt service restarts the first thread, the restart count of the first thread can be increased by 1. By updating the number of repairs of the first thread and the number of restarts of the first thread, the subsequent analysis of the operation of the first thread can be facilitated, so as to find weak links in the driver protection process.

FIG. 6 shows a schematic diagram of an interrupt service daemon process according to an embodiment of the present disclosure. In this embodiment, the first thread information is stored in a preset storage area.

As shown in Figure 6, the process of interrupt service guarding the first thread may include the following steps:

Step S601, the interrupt service of the driver program receives the interrupt processing;

Step S602, the interrupt service obtains the first thread information from a preset storage area before executing the interrupt processing;

Step S603: Calculate the hash value of the first code according to the address and length in the first thread information;

Step S604, judging whether the calculated hash value of the first code is the same as the hash value in the first thread information;

In the case that the calculated hash value of the first code is the same as the hash value in the first thread information, perform step S605 to check whether the first thread exits;

If the first thread has not exited, step S606 is executed to execute interrupt processing.

If the calculated hash value of the first code is different from the hash value in the first thread information, perform step S607, and repair the first code according to the driver image and the address and length in the first thread information ; Then execute step S605.

In the case that the first thread exits, execute step S608 to restart the first thread; then execute step S606.

In a possible implementation manner, the method further includes: firmware of the hardware device guards the interrupt service.

During the driver protection process, the interrupt service is guarded by the firmware of the hardware device, which can further improve the protection effect. For example, when the interrupt service is hijacked, the interrupt service can be restored by the firmware of the hardware device to the interrupt service, and then the first process can be restored by the interrupt service to the first process, and then further restored by the first thread. , the second thread, the ring protection that the 3rd thread constitutes, promptly recover the protection that the 1st thread carries out to the 2nd thread, the 2nd thread to the 3rd thread and the driver program, and the 3rd thread to the first thread and the driver program.

In a possible implementation manner, the key information of the driver further includes the interrupt processing function information corresponding to the interrupt service, and the interrupt processing function information includes the address, length and hash of the interrupt processing function corresponding to the interrupt service value;

The firmware of the hardware device guards the interrupt service, including: the firmware calculates the hash value of the interrupt processing function according to the address and length in the interrupt processing function information; In the case where the hash value is the same as the hash value in the interrupt handler information, after the firmware sleeps for a preset period of time, it restarts execution from the following steps: the firmware executes according to the address in the interrupt handler information and the length, and calculate the hash value of the interrupt handling function.

In a possible implementation manner, when the firmware of the hardware device guards the interrupt service, it may calculate the hash value of the interrupt processing function according to the address and length in the interrupt processing function information. Specifically, for example: the firmware can determine the seventh area where the code of the interrupt processing function is located according to the address and length in the interrupt processing function information, and then calculate the hash value of the code in the seventh area through a preset hash algorithm, And determine the hash value as the hash value of the interrupt processing function. Because the code of the interrupt processing function is located in the system memory, before the firmware calculates the hash value of the code in the seventh area, it needs to perform address conversion, that is, convert the address of the processor side into the address of the hardware device segment.

Then it can be judged whether the calculated hash value of the interrupt handling function is the same as the hash value in the interrupt handling function information, and if the calculated hash value of the interrupt handling function is the same as the hash value in the interrupt handling function information Next, the firmware can consider that the interrupt service has not been hijacked, and after the firmware sleeps for a preset period of time, it will start to execute the next round of guarding, that is, from the step "the firmware calculates the interrupt processing function according to the address and length in the interrupt processing function information. Hash value of the function" to start re-execution.

In a possible implementation, if the calculated hash value of the interrupt handling function is different from the hash value in the interrupt handling function information, the firmware may consider that the interrupt service is hijacked (for example, hooked or opened) patch). In this case, the firmware can control the hardware device to stop sending interrupt requests to stop the interrupt service, and then repair the interrupt processing function according to the address and length in the driver image and interrupt processing function information. For example, the firmware can handle the interrupt according to According to the address and length in the function information, the code of the interrupt processing function is reacquired from the driver image, and then the code of the interrupt processing function is repaired according to the reacquired code.

After the repair is completed, the firmware can control the sending of the hardware device resume interrupt request to resume the interrupt service. After the interrupt service is resumed, the first thread can be restored through the interrupt service to guard the first thread, and then the first thread can be restored to the second thread, the second thread to the third thread and the driver, and the third thread to the first thread. and driver protection.

In this way, the firmware of the hardware device can repair the interrupted service of the driver, thereby improving the security of the driver.

FIG. 7 shows a schematic diagram of a firmware daemon process according to an embodiment of the present disclosure. In this embodiment, the interrupt processing function information in the key information of the driver is stored in a preset storage area.

As shown in Figure 7, the process of the firmware guarding the interrupt service may include the following steps:

Step S701, obtaining interrupt processing function information from a preset storage area;

Step S702, calculating the hash value of the interrupt processing function according to the address and length in the interrupt processing function information;

Step S703, judging whether the calculated hash value of the interrupt handling function is the same as the hash value in the interrupt handling function information;

In the case that the calculated hash value of the interrupt handling function is the same as the hash value in the interrupt handling function information, execute step S704, sleep for a preset duration; then execute the next guard, and restart execution from step S701.

In the case where the calculated hash value of the interrupt handler is different from the hash value in the interrupt handler information, the following steps can be performed:

Step S705, controlling the hardware device to stop sending the interrupt request, so as to stop the interrupt service;

Step S706, according to the drive image, the address and length in the interrupt processing function information, the interrupt processing function is repaired;

Step S707, after the repair is completed, control the hardware device to resume sending the interrupt request, so as to restore the interrupt service;

Step S704, dormancy for a preset duration; then execute the next guard, and restart execution from step S701.

Fig. 8 shows a schematic diagram of a driver protection method according to an embodiment of the present disclosure. As shown in Figure 8, the first thread 210 guards the second thread 220, the second thread 220 guards the dispatch function table 241 and the callback function table 242 of the third thread 230 and the driver 240, and the third thread 230 guards the third thread 230 and the dispatch function table 241 of the driver 240. A thread 210 and the callback function 243 of the driver 240 are guarded, the interrupt service 250 of the hardware device is guarded for the first thread 210 , and the firmware 260 of the hardware device is guarded for the interrupt service 250 .

In this way, the driver 240 of the hardware device can be protected in an all-round and three-dimensional manner, and the possibility of the driver being hijacked can be reduced to the greatest extent, thereby improving the security of the driver, thereby protecting user data and improving user experience .

It should be noted that although the above embodiment is used as an example to describe the driver protection method, those skilled in the art can understand that the present disclosure should not be limited thereto. In fact, the user can flexibly set each step according to personal preferences and/or actual application scenarios, as long as it conforms to the technical solution of the present disclosure.

FIG. 9 shows a block diagram of a driver guard according to an embodiment of the present disclosure. As shown in Figure 9, the driver protection device includes:

The first information determination module 91 is used to determine the key information of the driver after the driver of the hardware device is loaded into the memory, and the key information includes the callback function table information, callback function information and dispatch function of the driver At least one of the table information;

The second information determination module 92 is configured to determine the first thread information, the second thread information and the third thread information, the first thread information includes the address, length and hash value of the first code corresponding to the first thread, so The second thread information includes the address, length and hash value of the second code corresponding to the second thread, and the third thread information includes the address, length and hash value of the third code corresponding to the third thread;

A thread starting module 93, configured to start the first thread, the second thread and the third thread;

The first guarding module 94, according to the key information, the first thread information, the second thread information and the third thread information, the first thread is responsible for the second thread, the second thread Daemonizing the third thread and the driver, and the third thread daemonizing the first thread and the driver.

In a possible implementation manner, the first guard module 94 includes: a first guard submodule, the first thread guards the second thread according to the second thread information; the second guard In the submodule, the second thread guards the callback function table, the dispatch function table and the third thread of the driver according to the key information and the third thread information; the third guard submodule, the The third thread guards the callback function of the driver and the first thread according to the key information and the first thread information.

In a possible implementation manner, the first guard submodule is configured to: the first thread calculates the hash value of the second code according to the address and length in the second thread information; When the hash value of the second code is the same as the hash value in the second thread information, the first thread checks whether the second thread exits; if the second thread does not exit Next, after the first thread sleeps for a preset period of time, it restarts execution from the following steps: the first thread calculates the hash value of the second code according to the address and length in the second thread information.

In a possible implementation manner, the first guard submodule is further configured to: when the hash value of the second code is different from the hash value in the second thread information, the The first thread repairs the second code according to the driver image, the address and the length in the information of the second thread, and the driver image is the backup of the original driver program on the hard disk in memory.

In a possible implementation manner, the first guard submodule is further configured to: when the second thread exits, the first thread restarts the second thread.

In a possible implementation manner, the second guard submodule is configured to: the second thread executes the callback function of the driver according to the callback function table information and the dispatch function table information in the key information. The table and the dispatch function table are guarded; the second thread guards the third thread according to the information of the third thread.

In a possible implementation manner, the callback function table information includes the address, length and hash value of the driver's callback function table, and the dispatch function table information includes the address of the driver's dispatch function table , length and hash value; the second thread guards the callback function table and dispatch function table of the driver according to the callback function table information and dispatch function table information in the key information, including: the first The second thread calculates the hash value of the callback function table of the driver according to the address and the length in the callback function table information; in the hash value of the callback function table of the driver and the callback function table information In the case of different hash values, the second thread repairs the callback function table of the driver according to the driver image, the address and the length in the callback function table information; the second thread repairs the callback function table according to the Address and length in the dispatch function table information, calculate the hash value of the dispatch function table of the driver; the hash value of the dispatch function table of the driver is different from the hash value in the dispatch function table information In the case of , the second thread repairs the dispatch function table of the driver according to the driver image, the address and the length in the dispatch function table information.

In a possible implementation manner, the third guard submodule is configured to: the third thread guards the callback function of the driver according to the callback function information in the key information; The three threads guard the first thread according to the first thread information.

In a possible implementation manner, the callback function information includes addresses, lengths, and hash values of all callback functions of the driver; the third thread, according to the callback function information in the key information, The callback function of the driver is guarded, including: for any callback function of the driver, the third thread calculates the hash value of the callback function according to the address and length of the callback function in the callback function information ; When the hash value of the callback function is different from the reference hash value, the second thread assigns the callback function to the callback function according to the address and length of the callback function in the driver image and the callback function table information The code is repaired, and the reference hash value is the hash value of the callback function in the callback function information.

In a possible implementation manner, the device further includes: a second guard module, where the interrupt service of the driver program guards the first thread.

In a possible implementation manner, the second guard module includes: a first calculation submodule, before the interrupt service of the driver executes interrupt processing, the interrupt service address and length, calculating the hash value of the first code; the first checking submodule, when the hash value of the first code is the same as the hash value in the first thread information, the The interrupt service checks whether the first thread exits; the submodule is executed, and if the first thread does not exit, the interrupt service executes the interrupt processing.

In a possible implementation manner, the apparatus further includes: a third guard module, where firmware of the hardware device guards the interrupt service.

In a possible implementation manner, the key information further includes the interrupt processing function information corresponding to the interrupt service, and the interrupt processing function information includes the address, length and hash value of the interrupt processing function corresponding to the interrupt service The third guardian module includes: a second computing submodule, the firmware calculates the hash value of the interrupt processing function according to the address and length in the interrupt processing function information; the dormancy submodule, in the In the case where the hash value of the interrupt processing function is the same as the hash value in the interrupt processing function information, after the firmware sleeps for a preset period of time, it starts to execute again from the following steps: the firmware executes according to the interrupt processing function The address and length in the information are used to calculate the hash value of the interrupt processing function.

In a possible implementation manner, the third guard module includes: an interrupt service stop submodule, and when the hash value of the interrupt processing function is different from the hash value in the interrupt processing function information , the firmware controls the hardware device to stop sending interrupt requests, so as to stop the interrupt service; the repair submodule, the firmware executes the interrupt processing function according to the drive image, the address and the length in the interrupt processing function information Repairing: the interrupt service recovery sub-module, after the repair is completed, the firmware controls the hardware device to resume sending the interrupt request, so as to resume the interrupt service.

In a possible implementation manner, the first information determination module 91 includes: a second checking submodule, after the driver is loaded into the memory, checks whether the driver is modified during the loading process; information The submodule is determined, and key information of the driver is determined when the driver is not modified during the loading process.

In a possible implementation manner, the second checking submodule is configured to: verify the driver after the driver is loaded into the memory, and the verification includes hash verification, certificate At least one of signature verification; if the verification is passed, align and relocate the driver; judge whether the driver is modified during the loading process according to the driver image.

In a possible implementation manner, the determining whether the driver program is modified during the loading process according to the driver image includes: separately calculating a hash value of the driver image and a hash value of the driver program; If the hash value of the driver image is the same as the hash value of the driver, it is determined that the driver has not been modified during the loading process.

In a possible implementation manner, the information determination submodule is configured to: repair the driver according to the driver image when the driver is modified during the loading process; Once complete, identify the key information for the driver in question.

In a possible implementation manner, the device further includes: a registration module, configured to register the callback function of the driver through a self-defined callback registration function after determining the callback function information.

In a possible implementation manner, the device further includes: a storage module, configured to store the key information, the first thread information, the second thread information, and the third thread information in a preset A storage area is provided, and the storage area is a storage area that only allows writing once.

In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the methods described in the method embodiments above, and its specific implementation can refer to the description of the method embodiments above. For brevity, here No longer.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, a portion of a program segment, or an instruction that includes one or more Executable instructions. In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks in succession may, in fact, be executed substantially concurrently, or they may sometimes be executed in the reverse order, depending upon the functionality involved. It should also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by a dedicated hardware-based system that performs the specified function or action , or may be implemented by a combination of dedicated hardware and computer instructions.

Having described various embodiments of the present disclosure above, the foregoing description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and alterations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principle of each embodiment, practical application or technical improvement in the market, or to enable other ordinary skilled in the art to understand each embodiment disclosed herein.

Claims (40)

1. A driver protection method, characterized in that the method comprises: After the driver of the hardware device is loaded into the memory, determine key information of the driver, the key information including at least one of callback function table information, callback function information, and dispatch function table information of the driver; Determine the first thread information, the second thread information and the third thread information, the first thread information includes the address, length and hash value of the first code corresponding to the first thread, and the second thread information includes the second thread information The address, length and hash value of the corresponding second code, the third thread information includes the address, length and hash value of the third code corresponding to the third thread; starting the first thread, the second thread and the third thread; According to the key information, the first thread information, the second thread information and the third thread information, the first thread to the second thread, the second thread to the third thread and the driver program, and the third thread guard the first thread and the driver program. 2. The method according to claim 1, wherein, according to the key information, the first thread information, the second thread information and the third thread information, the first thread pair The second thread, the second thread guards the third thread and the driver, and the third thread guards the first thread and the driver, including: The first thread guards the second thread according to the second thread information; The second thread guards the driver's callback function table, dispatch function table and the third thread according to the key information and the third thread information; The third thread guards the callback function of the driver and the first thread according to the key information and the first thread information. 3. The method according to claim 2, wherein the first thread guards the second thread according to the second thread information, comprising: The first thread calculates the hash value of the second code according to the address and length in the second thread information; When the hash value of the second code is the same as the hash value in the second thread information, the first thread checks whether the second thread exits; In the case that the second thread does not exit, after the first thread sleeps for a preset period of time, it starts to execute again from the following steps: the first thread calculates according to the address and length in the second thread information a hash value of the second code. 4. The method according to claim 3, wherein the first thread guards the second thread according to the second thread information, further comprising: In the case that the hash value of the second code is different from the hash value in the second thread information, the first thread assigns the second code to the second code according to the driver image, the address and the length in the second thread information The second code is repaired, and the driver image is a backup of the original driver program on the hard disk in memory. 5. The method according to claim 3, wherein the first thread guards the second thread according to the second thread information, further comprising: In case the second thread exits, the first thread restarts the second thread. 6. The method according to claim 2, characterized in that, the second thread, according to the key information and the third thread information, performs a callback function table, a dispatch function table, and the first thread of the driver program. Three threads are guarded, including: The second thread guards the callback function table and dispatch function table of the driver according to the callback function table information and dispatch function table information in the key information; The second thread guards the third thread according to the third thread information. 7. The method according to claim 6, wherein the callback function table information includes the address, length and hash value of the driver's callback function table, and the dispatch function table information includes the driver The address, length and hash value of the dispatch function table; The second thread guards the callback function table and dispatch function table of the driver according to the callback function table information and dispatch function table information in the key information, including: The second thread calculates the hash value of the callback function table of the driver according to the address and length in the callback function table information; When the hash value of the callback function table of the driver is different from the hash value in the callback function table information, the second thread according to the driver image, the address and the length in the callback function table information , repairing the callback function table of the driver; The second thread calculates the hash value of the driver's dispatch function table according to the address and length in the dispatch function table information; When the hash value of the dispatch function table of the driver is different from the hash value in the dispatch function table information, the second thread according to the driver image, the address and the length in the dispatch function table information , and repair the dispatch function table of the driver. 8. The method according to claim 2, wherein the third thread guards the callback function of the driver program and the first thread according to the key information and the first thread information, include: The third thread guards the callback function of the driver according to the callback function information in the key information; The third thread guards the first thread according to the first thread information. 9. The method according to claim 8, wherein the callback function information includes addresses, lengths and hash values of all callback functions of the driver; The third thread guards the callback function of the driver according to the callback function information in the key information, including: For any callback function of the driver, the third thread calculates the hash value of the callback function according to the address and length of the callback function in the callback function information; In the case where the hash value of the callback function is different from the reference hash value, the second thread calculates the callback function according to the driver image, the address and the length of the callback function in the callback function table information The code is repaired, and the reference hash value is the hash value of the callback function in the callback function information. 10. The method of claim 1, further comprising: The interrupt service of the driver program daemonizes the first thread. 11. The method according to claim 10, wherein the interrupt service of the driver protects the first thread, comprising: Before the interrupt service of the driver program executes the interrupt processing, the interrupt service calculates the hash value of the first code according to the address and length in the first thread information; When the hash value of the first code is the same as the hash value in the first thread information, the interrupt service checks whether the first thread exits; If the first thread does not exit, the interrupt service executes the interrupt processing. 12. The method according to claim 10, further comprising: The firmware of the hardware device guards the interrupt service. 13. The method according to claim 12, wherein the key information further includes interrupt handler information corresponding to the interrupt service, and the interrupt handler information includes an address of the interrupt handler corresponding to the interrupt service , length and hash value; The firmware of the hardware device guards the interrupt service, including: The firmware calculates the hash value of the interrupt processing function according to the address and length in the interrupt processing function information; In the case where the hash value of the interrupt processing function is the same as the hash value in the interrupt processing function information, after the firmware sleeps for a preset period of time, it starts to execute again from the following steps: the firmware according to the The address and length in the interrupt handling function information are used to calculate the hash value of the interrupt handling function. 14. The method according to claim 13, wherein the firmware of the hardware device guards the interrupt service, comprising: When the hash value of the interrupt handling function is different from the hash value in the interrupt handling function information, the firmware controls the hardware device to stop sending interrupt requests, so as to stop the interrupt service; The firmware repairs the interrupt processing function according to the drive image, the address and the length in the interrupt processing function information; After the repair is completed, the firmware controls the hardware device to resume sending the interrupt request, so as to restore the interrupt service. 15. The method according to claim 1, wherein determining the key information of the driver comprises: After the driver is loaded into the memory, check whether the driver is modified during the loading process; In the case that the driver is not modified during the loading process, key information of the driver is determined. 16. The method according to claim 15, wherein the checking whether the driver is modified during loading comprises: After the driver program is loaded into the memory, the driver program is verified, and the verification includes at least one of hash verification and certificate signature verification; If the verification is passed, the driver is aligned and relocated; According to the driver image, it is judged whether the driver is modified during the loading process. 17. The method according to claim 16, wherein the determining whether the driver is modified during the loading process according to the driver image comprises: respectively calculating the hash value of the driver image and the hash value of the driver; If the hash value of the driver image is the same as the hash value of the driver, it is determined that the driver has not been modified during the loading process. 18. The method according to claim 15, wherein determining the key information of the driver comprises: In the case that the driver is modified during the loading process, repairing the driver according to the driver image; After the driver is repaired, key information of the driver is determined. 19. The method of claim 1, further comprising: After the callback function information is determined, the callback function of the driver is registered through a self-defined callback registration function. 20. The method according to any one of claims 1-19, further comprising: The key information, the first thread information, the second thread information, and the third thread information are stored in a preset storage area, and the storage area is only allowed to be written once. 21. A driver protection device, characterized in that the device comprises: The first information determination module is used to determine the key information of the driver after the driver of the hardware device is loaded into the memory, and the key information includes the callback function table information, callback function information and dispatch function table of the driver. at least one of the information; The second information determination module is used to determine the first thread information, the second thread information and the third thread information, the first thread information includes the address, length and hash value of the first code corresponding to the first thread, the said The second thread information includes the address, length and hash value of the second code corresponding to the second thread, and the third thread information includes the address, length and hash value of the third code corresponding to the third thread; a thread starting module, configured to start the first thread, the second thread and the third thread; The first guard module, according to the key information, the first thread information, the second thread information, and the third thread information, the first thread to the second thread, the second thread to the second thread The third thread and the driver, and the third thread guards the first thread and the driver. 22. The device according to claim 21, wherein the first guard module comprises: A first guard submodule, the first thread guards the second thread according to the second thread information; The second guard submodule, the second thread guards the callback function table, dispatch function table and the third thread of the driver according to the key information and the third thread information; The third guarding sub-module, the third thread guards the callback function of the driver and the first thread according to the key information and the first thread information. 23. The device according to claim 22, wherein the first guardian submodule is configured to: The first thread calculates the hash value of the second code according to the address and length in the second thread information; When the hash value of the second code is the same as the hash value in the second thread information, the first thread checks whether the second thread exits; In the case that the second thread does not exit, after the first thread sleeps for a preset period of time, it starts to execute again from the following steps: the first thread calculates according to the address and length in the second thread information a hash value of the second code. 24. The device according to claim 23, wherein the first guardian submodule is also used for: In the case that the hash value of the second code is different from the hash value in the second thread information, the first thread assigns the second code to the second code according to the driver image, the address and the length in the second thread information The second code is repaired, and the driver image is a backup of the original driver program on the hard disk in memory. 25. The device according to claim 23, wherein the first guardian submodule is further used for: In case the second thread exits, the first thread restarts the second thread. 26. The device according to claim 22, wherein the second guardian submodule is configured to: The second thread guards the callback function table and dispatch function table of the driver according to the callback function table information and dispatch function table information in the key information; The second thread guards the third thread according to the third thread information. 27. The device according to claim 26, wherein the callback function table information includes the address, length and hash value of the driver's callback function table, and the dispatch function table information includes the driver The address, length and hash value of the dispatch function table; The second thread guards the callback function table and dispatch function table of the driver according to the callback function table information and dispatch function table information in the key information, including: The second thread calculates the hash value of the callback function table of the driver according to the address and length in the callback function table information; When the hash value of the callback function table of the driver is different from the hash value in the callback function table information, the second thread according to the driver image, the address and the length in the callback function table information , repairing the callback function table of the driver; The second thread calculates the hash value of the driver's dispatch function table according to the address and length in the dispatch function table information; When the hash value of the dispatch function table of the driver is different from the hash value in the dispatch function table information, the second thread according to the driver image, the address and the length in the dispatch function table information , and repair the dispatch function table of the driver. 28. The device according to claim 22, wherein the third guardian submodule is configured to: The third thread guards the callback function of the driver according to the callback function information in the key information; The third thread guards the first thread according to the first thread information. 29. The device according to claim 28, wherein the callback function information includes addresses, lengths and hash values of all callback functions of the driver; The third thread guards the callback function of the driver according to the callback function information in the key information, including: For any callback function of the driver, the third thread calculates the hash value of the callback function according to the address and length of the callback function in the callback function information; In the case where the hash value of the callback function is different from the reference hash value, the second thread calculates the callback function according to the driver image, the address and the length of the callback function in the callback function table information The code is repaired, and the reference hash value is the hash value of the callback function in the callback function information. 30. The device of claim 21, further comprising: The second guard module, the interrupt service of the driver guards the first thread. 31. The device according to claim 30, wherein the second guard module comprises: The first calculation submodule, before the interrupt service of the driver program executes interrupt processing, the interrupt service calculates the hash value of the first code according to the address and length in the first thread information; A first checking submodule, when the hash value of the first code is the same as the hash value in the first thread information, the interrupt service checks whether the first thread exits; Executing a sub-module, if the first thread has not exited, the interrupt service executes the interrupt processing. 32. The device of claim 30, further comprising: The third guard module, the firmware of the hardware device guards the interrupt service. 33. The device according to claim 32, wherein the key information further includes interrupt handler information corresponding to the interrupt service, and the interrupt handler information includes an address of the interrupt handler corresponding to the interrupt service , length and hash value; The third guardian module includes: The second computing submodule, the firmware calculates the hash value of the interrupt processing function according to the address and length in the interrupt processing function information; The dormancy sub-module, when the hash value of the interrupt processing function is the same as the hash value in the interrupt processing function information, after the firmware sleeps for a preset period of time, it starts to execute from the following steps again: the The firmware calculates the hash value of the interrupt processing function according to the address and length in the interrupt processing function information. 34. The device according to claim 33, wherein the third guard module comprises: The interrupt service stop submodule, when the hash value of the interrupt processing function is different from the hash value in the interrupt processing function information, the firmware controls the hardware device to stop sending interrupt requests, so as to stop the interruption of service; repair submodule, the firmware repairs the interrupt processing function according to the drive image, the address and the length in the interrupt processing function information; The interrupt service recovery submodule, after the repair is completed, the firmware controls the hardware device to resume sending the interrupt request, so as to resume the interrupt service. 35. The device according to claim 21, wherein the first information determining module comprises: The second check submodule, after the driver is loaded into the memory, checks whether the driver is modified during the loading process; The information determination submodule determines the key information of the driver under the condition that the driver is not modified during the loading process. 36. The device according to claim 35, wherein the second checking submodule is configured to: After the driver program is loaded into the memory, the driver program is verified, and the verification includes at least one of hash verification and certificate signature verification; If the verification is passed, the driver is aligned and relocated; According to the driver image, it is judged whether the driver is modified during the loading process. 37. The device according to claim 36, wherein the judging whether the driver is modified during the loading process according to the driver image comprises: respectively calculating the hash value of the driver image and the hash value of the driver; If the hash value of the driver image is the same as the hash value of the driver, it is determined that the driver has not been modified during the loading process. 38. The device according to claim 35, wherein the information determining submodule is configured to: In the case that the driver is modified during the loading process, repairing the driver according to the driver image; After the driver is repaired, key information of the driver is determined. 39. The device of claim 21, further comprising: The registration module is configured to register the callback function of the driver through a self-defined callback registration function after determining the callback function information. 40. The device according to any one of claims 21-39, further comprising: A storage module, configured to store the key information, the first thread information, the second thread information, and the third thread information in a preset storage area, and the storage area is only allowed to be written once storage area.

Images