WO2021036322A1

WO2021036322A1 - Method and apparatus for preventing dynamic link library file hijacking, and computer device

Info

Publication number: WO2021036322A1
Application number: PCT/CN2020/088014
Authority: WO
Inventors: 芦永胜
Original assignee: 深圳壹账通智能科技有限公司
Priority date: 2019-08-30
Filing date: 2020-04-30
Publication date: 2021-03-04
Also published as: CN110688661A

Abstract

Disclosed in the present application are a method and apparatus for preventing dynamic link library (DLL) file hijacking, and a computer device. The method comprises: before starting up an application for the first time, creating a drive corresponding to the application; determining whether a copy request from an external first DLL file for a specified directory of the application is received; if yes, extracting first name of the first DLL file from the copy request; reading a preset whitelist by means of the drive, and determining whether the first name exists in the whitelist; if yes, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result; and performing corresponding processing on the copy request according to the verification result. The present application can effectively prevent hijacking of a DLL file in an application. Moreover, the verification and signing of the first DLL file are performed by the drive, thereby effectively improving the application startup rate.

Description

Method, device and computer equipment for preventing dynamic link library file hijacking

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on August 30, 2019, the application number is 201910817923.9, and the invention title is "Methods, Apparatus and Computer Equipment for Preventing the Hijacking of Dynamic Link Library Files", the entire content of which is approved The reference is incorporated in this application.

Technical field

This application relates to the field of computer security technology, and in particular to a method, device and computer equipment for preventing hijacking of dynamic link library files.

Background technique

DLL (Dynamic Link Library, dynamic link library) file hijacking is generally to hijack system DLL files necessary for applications such as usp1.dll, ws2_32.dll, lpk.dll, etc. It is mainly based on the loading sequence of the DLL search path. The specified directory in the application corresponding to the above loading sequence is released and a DLL file with the same name is released. The DLL file with the same name is usually a Trojan virus with the same name as any system DLL file, which makes the application into a malicious DLL loading. Device. If the DLL file with the same name is not checked and killed in time, it will preemptively load the DLL file with the same name disguised by a Trojan virus when the application is started, which will eventually cause the application to be destroyed and the system where the application is located is infected by the virus.

The inventor found that the existing way to prevent DLL file hijacking is generally to verify all DLL files that need to be loaded when the application is started, and then perform the application after checking and killing all DLL files that fail the verification. The normal start of the program. If there are dozens of DLL files that need to be loaded to start the application, the application needs to verify these dozens of DLL files every time it starts. The verification process is tedious and time-consuming, which makes the application start-up. The time is greatly increased, and the user experience is not good.

technical problem

The main purpose of this application is to provide a method, device and computer equipment for preventing hijacking of dynamic link library files, which are suitable for the field of blockchain technology and aim to solve the cumbersome and complicated verification process in the existing methods of preventing DLL file hijacking. It takes a long time, which greatly increases the startup time of the application, and is a technical problem that the user experience is not good.

Technical solutions

This application proposes a method for preventing the hijacking of a dynamic link library file. The method includes the steps of: before starting the application for the first time, creating a driver corresponding to the application; judging whether an external first DLL file pair is received A copy request issued by a designated directory of the application program, wherein the copy request is in the form of an I/O request; if the copy request is received, the first name of the first DLL file is extracted from the copy request Read the preset white list by the driver, and determine whether the first name exists in the white list, wherein a plurality of designated names are stored in the white list; if the white list exists in the With the first name, the first DLL file is verified and signed according to the first preset rule to obtain the corresponding verification result; according to the verification result, the copy request is processed correspondingly.

This application also provides a device for preventing hijacking of dynamic link library files, including: a creation module for creating a driver corresponding to the application before starting the application for the first time; a first judgment module for judging whether Receive a copy request from an external first DLL file to the specified directory of the application program, wherein the copy request is in the form of an I/O request; the extraction module is used to extract the copy request if the copy request is received The first name of the first DLL file; the second judgment module is used to read the preset white list through the driver and judge whether the first name exists in the white list, wherein the white list is stored There are multiple designated names; the verification module is used to verify and sign the first DLL file according to the first preset rule if the first name exists in the whitelist to obtain the corresponding verification result ; The first processing module is configured to perform corresponding processing on the copy request according to the verification result.

The present application also provides a computer device, which includes: one or more processors; a memory; one or more computer programs, wherein the one or more computer programs are stored in the memory and configured to be The one or more processors execute, the one or more computer programs are configured to execute a method for preventing the hijacking of a dynamic link library file, wherein the method for preventing the hijacking of a dynamic link library file includes the following steps: Before starting the application program, create a driver corresponding to the application program; determine whether a copy request from the external first DLL file to the specified directory of the application program is received, wherein the form of the copy request is I/ O request; if the copy request is received, extract the first name of the first DLL file from the copy request; read the preset white list through the driver, and determine whether the white list exists The first name, wherein a plurality of designated names are stored in the white list; if the first name exists in the white list, verify and sign the first DLL file according to a first preset rule , Obtain the corresponding verification result; according to the verification result, perform corresponding processing on the copy request.

The present application also provides a computer-readable storage medium having a computer program stored on the computer-readable storage medium, and when the computer program is executed by a processor, a method for preventing the hijacking of a dynamic link library file is implemented, wherein the preventing The method of dynamic link library file hijacking includes the following steps: before starting the application for the first time, creating a driver corresponding to the application; judging whether an external first DLL file is sent to the specified directory of the application A copy request, where the copy request is in the form of an I/O request; if the copy request is received, the first name of the first DLL file is extracted from the copy request; the preset is read by the driver And determine whether the first name exists in the white list, wherein multiple designated names are stored in the white list; if the first name exists in the white list, follow the first preset Suppose that rules are used to verify and sign the first DLL file to obtain a corresponding verification result; according to the verification result, the copy request is processed correspondingly.

Beneficial effect

The method, device, computer equipment and storage medium for preventing the hijacking of dynamic link library files provided in this application have the following beneficial effects:

The method, device, computer equipment, and storage medium for preventing the hijacking of dynamic link library files provided in this application effectively improve the processing efficiency of copy requests, simplify the processing flow of verifying signatures, and effectively prevent the application program from being hijacked. The DLL file appears to be hijacked, which improves the security and stability of the application, and also effectively improves the startup rate of the application.

Description of the drawings

FIG. 1 is a schematic flowchart of a method for preventing hijacking of a dynamic link library file according to an embodiment of the present application;

FIG. 2 is a schematic structural diagram of a device for preventing hijacking of dynamic link library files according to an embodiment of the present application;

Fig. 3 is a schematic structural diagram of a computer device according to an embodiment of the present application.

The best mode of the present invention

1, the method for preventing the hijacking of a dynamic link library file according to an embodiment of the present application includes:

S1: Before starting the application for the first time, create a driver corresponding to the application;

S2: Determine whether a copy request from an external first DLL (Dynamic Link Library) file to the specified directory of the application program is received, wherein the form of the copy request is an I/O request;

S3: If the copy request is received, extract the first name of the first DLL file from the copy request;

S4: Read a preset white list through the driver, and determine whether the first name exists in the white list, where a plurality of designated names are stored in the white list;

S5: If the first name exists in the whitelist, verify and sign the first DLL file according to the first preset rule to obtain a corresponding verification result;

S6: Perform corresponding processing on the copy request according to the verification result.

As described in the above steps S1 and S2, the execution subject of the embodiment of the present application is a device for preventing hijacking of dynamic link library files, which may specifically be a Windows file system with a driver installed. This embodiment completes the verification of the first DLL file by creating a driver corresponding to the application, and does not require the application to verify all the DLL files that need to be loaded during startup, which improves the startup rate of the application. Specifically, after the installation of the above-mentioned application program is completed and before the application program is started for the first time, a driver corresponding to the application program is first created. The above-mentioned driver is a filter driver, and the corresponding driver can be created at the same time during the installation of the above-mentioned application program. , Or create the corresponding driver in any time period before the application program is installed successfully and start for the first time, so that after the driver is created, the driver can be used to perform anti-hijacking processing for the first external DLL file . When receiving a copy request from the external first DLL file to the designated directory of the application program, the first name corresponding to the first DLL file in the copy request is extracted. Wherein, the copy request mentioned above may refer to the first DLL file used to cover, add, modify, or replace the DLL file in the application program, and the form of the copy request is I/O (input/output , Input/output) request. In addition, when a user sends an I/O request, the I/O request is generally packaged into IRP (I/O Request Package, input output request package) information, and then sent to the Windows file system for processing. In this embodiment, when a copy request in the form of an I/O request is received, because there may be a Trojan horse virus intrusion or hijacking of the DLL file in the application, the IPR corresponding to the I/O request will not be directly The information is released directly, but the first DLL file corresponding to the I/O request will be verified, and the verification process first needs to obtain the first name of the first DLL file. Specifically, the IPR information corresponding to the I/O request is intercepted first to obtain the IRP information, and then the IPR information is parsed to obtain the first name corresponding to the first DLL file.

As described in the above steps S3 and S4, after the first name is obtained, the pre-configured white list is read through the driver to determine whether the first name exists in the white list, and the specified directory can be an application The directory where the program is currently loaded, that is, the installation directory of the application, or the system directory, and so on. A plurality of designated names are stored in the whitelist, and these designated names are the names corresponding to the DLL files that need to be verified and signed by the application program. Specifically, a matching result can be obtained by matching the name of the first DLL file with all specified names in the whitelist, and it can be determined whether the first name exists in the whitelist according to the matching result. Further, if the aforementioned first name does not exist in the whitelist, it indicates that the first DLL file is a resource that is not needed by the application, such as a windows system DLL file forged by a virus and Trojan horse, and the driver will directly refuse to process the aforementioned copy Request, that is, return a rejection message to the IPR information to prohibit copying the first DLL file into the specified directory, thereby effectively preventing the application from being damaged. In another embodiment, the first DLL file with the risk of DLL hijacking can also be detected and killed. Specifically, the information of the first DLL file is first uploaded to the server, and then the first DLL file is uploaded through the server. Checking and killing ensures that the original file resources in the application will not be modified, curbs the proliferation of DLL files with the risk of DLL hijacking, and effectively prevents the application from being damaged by resources from unknown sources.

As described in the above steps S5 and S6, if the first name exists in the white list, it indicates that the first DLL file is a resource required by the application, but the first DLL file needs to be further verified and signed. To detect the legitimacy of the first DLL file, that is, verify and sign the first DLL file according to the first preset rule to obtain the verification result, and perform corresponding processing on the copy request according to the verification result. Wherein, the above-mentioned first preset rule refers to adopting a corresponding verification signature method according to the data source of the first DLL file. In addition, the above verification result includes the first DLL file passing the verification and the first DLL file not passing the verification. The step of performing corresponding processing on the copy request according to the verification result may specifically include: when the verification result is the first The verification of a DLL file can prove that the copy request is a normal file processing operation, and that the first DLL file is a resource required by the application program. For example, the first DLL file is a file generated during the application program upgrade process. Or the above-mentioned first DLL file is a file generated during the testing process of the developer testing the application program, then the above-mentioned copy request is allowed to be processed, so as to complete the update or test processing of the application program. When the verification result is that the first DLL file fails the verification, it can be proved that the copy request is an abnormal file processing operation, that is, the first DLL file is not a resource required by the application. For example, the first DLL file may be a Trojan horse. Viruses or files used for DLL hijacking will refuse to process the above copy request to avoid DLL hijacking caused by copying the first DLL file into the designated directory of the application. In this embodiment, only when the first DLL file exists in the whitelist, will the first DLL file be verified and signed, so there is no need to verify and sign DLL files that are not in the whitelist, which effectively improves The processing efficiency of the copy request simplifies the processing flow of verifying the signature. And only when the first DLL file passes the verification signature, can the copy request be processed, which effectively prevents the DLL file in the application from being hijacked, and improves the security and stability of the application. In addition, the verification and signature processing of the first DLL file is carried out by the driver, that is, it is completed before the application is started, so there is no need for the application to verify and sign every internal DLL file when it is started, which is effective Improved the startup rate of applications.

Further, in an embodiment of the present application, before the above step S4, the method includes:

S400: Receive designated names corresponding to multiple designated DLL files input by the user;

S401: Input all the specified names into the pre-created first list;

S402: Perform encryption processing on the first list to obtain the white list.

As described in the above steps S400 to S402, before the step of reading the preset white list by the above driver and determining whether the first name exists in the white list, the step of creating a white list may also be included, which may specifically include: receiving user input The multiple designated DLL files corresponding to the designated names respectively, and the above designated DLL files are resources required by the application. Then input all the aforementioned designated names into the aforementioned pre-created first list, and further encrypt the first list to form the aforementioned encrypted white list. In addition, after encrypting the first list to obtain the white list, the corresponding secret key will be sent to the above-mentioned driver, and the driver needs to decrypt the encrypted white list with the secret key to read all the white lists in the white list. Specify the name of the data. In this embodiment, only the driver that contains the corresponding secret key has the permission to read the white list, which can effectively prevent the white list from being tampered with, and effectively avoid subsequent problems in the verification and signature processing caused by the tampering of the white list. Happening.

Further, in an embodiment of the present application, the above step S5 includes:

S500: Obtain the resource source of the first DLL file, and determine whether the first DLL file is a resource issued by a third party;

S501: If the first DLL file is a resource issued by a third party, determine whether the first DLL file contains a corresponding agency signature certificate;

S502: If the first DLL file contains the agency signature certificate, obtain the latest version of the certificate revocation list of the certification agency corresponding to the agency signature certificate;

S503: Determine whether the certificate revocation list contains the institution-signed certificate;

S504: If the first certificate is not included in the certificate revocation list, determine that the first DLL file passes the verification;

S505: If the first certificate is included in the certificate revocation list, determine that the first DLL file fails the verification.

As described in the above steps S500 to S505, when the first name of the first DLL file exists in the whitelist, it is also necessary to adopt the corresponding verification signature method according to the resource source of the first DLL file, and obtain the corresponding verification result. When the first DLL file is a third-party resource, because the third-party resource is digitally signed by other means, and the developer cannot sign it a second time, the Windows file system needs to verify the first DLL file The signature processing is managed in a unified manner. Specifically, first obtain the resource source of the first DLL file, and determine whether the above-mentioned first DLL file is a resource issued by a third party. Among them, the resource of the first DLL file can be determined by determining whether the first DLL file has a secondary signature. Source, if there is a secondary signature, it is determined that the first DLL file is not a resource issued by a third party, and if there is no secondary signature, it is determined that the first DLL file is a resource issued by a third party. When the first DLL file is a resource issued by a third party, it is further judged whether the first DLL file contains a corresponding agency signature certificate. For example, the first DLL file is a resource digitally signed with a Microsoft certificate, and the agency signature certificate is Microsoft certificate; if the first DLL file contains the above-mentioned agency signature certificate, it is necessary to identify its legitimacy by judging the validity of the agency signature certificate. Specifically, obtain the latest version of the certificate revocation list (CRL) of the certification authority corresponding to the above-mentioned agency signature certificate, and determine whether the above-mentioned agency signature certificate is included in the certificate revocation list, and if the above-mentioned agency signature certificate is not included, it indicates that the agency If the signature certificate is still in the validity period, it can be determined that the first DLL file passes the verification, and then the copy request for the first DLL file will be allowed to be processed. And if the above-mentioned agency signature certificate is included, it indicates that the agency signature certificate has expired, that is, the first DLL file corresponding to the agency signature certificate is an illegal third-party resource, and it can be determined that the first DLL file has not passed the verification. It will refuse to process the copy request of the first DLL file mentioned above, avoid the situation of DLL hijacking caused by copying the first DLL file into the designated directory of the application program, and effectively ensure the safety and stability of the application program. In another embodiment, if the first DLL file belonging to a third-party publishing resource does not contain an agency signature certificate, it indicates that the first DLL file is an illegal third-party resource. In this case, the first DLL file will be directly rejected and processed. A copy request of a DLL file effectively prevents the copying of the first DLL file into the designated directory of the application program from causing DLL hijacking, which ensures the safety and stability of the application program.

Further, in an embodiment of the present application, after the above step S500, the method includes:

S506: If the first DLL file is not a resource issued by a third party, extract the first digital signature of the first DLL file;

S507: Invoke the pre-stored public key in the driver to decrypt the first digital signature to obtain the first hash value;

S508: Perform a hash calculation on the body content of the first DLL file to obtain a second hash value;

S509: Determine whether the first hash value is the same as the second hash value;

S510: If the first hash value is the same as the second hash value, determine that the first DLL file passes the verification;

S511: If the first hash value is not the same as the second hash value, determine that the first DLL file fails the verification.

As described in steps S506 to S511 above, if the first DLL file is not a resource issued by a third party, another signature verification method that is different from when the first DLL file is a resource issued by a third party needs to be adopted. When the first DLL file is not a resource released by a third party, it is a resource encrypted and released by the developer himself, but this kind of resource cannot be guaranteed to be completely safe, and there may be the possibility of the first DLL file being tampered with, so It is also necessary to perform a verification signature on the first DLL file to verify the legitimacy of the DLL. Specifically, when the first DLL file is not a resource issued by a third party, first extract the first digital signature of the first DLL file from the resource section of the first DLL file, and then use the public key pre-stored in the driver to The first digital signature is decrypted to obtain the first hash value, where the first DLL file is obtained by the research and development personnel after the signature processing, the signature processing process specifically includes: using a hash algorithm to the first DLL file Perform a hash operation to obtain a digital fingerprint, and then use the elliptic curve digital signature algorithm to generate a public key and a private key key pair, and then use the private key to encrypt the digital fingerprint and obtain the first digital signature, and finally the first digital signature Write it into the resource section of the first DLL file, and store the above public key in the drive. After the first hash value is obtained, a hash calculation is performed on the body content of the first DLL file to obtain a second hash value. Then, the first hash value and the second hash value are compared to determine whether the first hash value is the same as the second hash value. If the first hash value is the same as the above-mentioned second hash value, it indicates that the first digital signature verification is successful, and the first DLL file is legal and has not been tampered with. Therefore, it is determined that the first DLL file has passed the verification. It will be allowed to process the copy request of the first DLL file mentioned above. If the first hash value is not the same as the second hash value, it indicates that the first digital signature verification failed and the first DLL file is illegal. For example, if it has been tampered with, the first DLL file is determined If the verification is not passed, then it will refuse to process the copy request of the first DLL file to avoid the DLL hijacking caused by copying the first DLL file into the specified directory of the application program, which effectively guarantees the safety and security of the application program. stable.

Further, in an embodiment of the present application, after the above step S6, the method includes:

S600: Run the application program;

S601: Obtain the running data generated during the running of the application, and evaluate the running data according to a second preset rule to obtain a corresponding evaluation result, where the evaluation result includes the driver and the application The program is compatible or the driver is not compatible with the application program;

S602: Perform corresponding processing on the driver or the application program according to the evaluation result.

As described in the above steps S600 to S602, installing the driver corresponding to the above application can be regarded as an upgrade process for the application, but this upgrade process may have the risk of loopholes or errors, for example, the driver may appear Incompatibility with the application. If the installed driver is not compatible with the above application, it may affect the normal operation of the application or some normal functions. Therefore, this embodiment needs to further verify the compatibility between the two to avoid the normal operation of the application. Be disturbed. Specifically, after processing the copy request in this embodiment, the application program is first run, and then the operating data generated by the application program during the running process is obtained, and the obtained operating data is processed according to the second preset rule. Evaluation to get the corresponding evaluation results. Wherein, the above-mentioned evaluation of the operation data obtained according to the second preset rule may include multiple evaluation methods. For example, the evaluation may be performed by analyzing the operation log of the application; or the operation process corresponding to the application may be evaluated. The evaluation is performed by analyzing the process identifier PI of the application program; the evaluation can also be performed by analyzing the database data of the application program. The above database data includes user data, and/or default data, and/or data such as configuration files. In addition, the aforementioned evaluation result includes that the aforementioned driver is compatible with the application program and the aforementioned driver is incompatible with the application program. When the aforementioned evaluation result is that the aforementioned driver is compatible with the application program, it indicates that the installation of the driver will not affect the normal operation of the application program, and subsequent processing of the application program or the driver will not be performed. In another embodiment, when the aforementioned evaluation result is that the aforementioned driver is incompatible with the application program, it is also necessary to analyze the compatibility information of the driver and the application program based on the aforementioned operating data, and then perform the evaluation on the aforementioned application program according to the compatibility information. Maintenance treatment, or directly replace the above-mentioned driver, to solve the problem of incompatibility between the two. In this embodiment, the created driver and the application program are evaluated for compatibility verification to obtain the corresponding evaluation result, which is conducive to the subsequent corresponding processing of the application program or the driver based on the evaluation result, thereby effectively ensuring the application’s performance normal operation.

Further, in an embodiment of the present application, the operation data includes an operation log, and the above step S601 includes:

S6010: Obtain a running log generated during the running of the application program;

S6011: Determine whether there are error data and/or abnormal data in the operation log;

S6012: If yes, determine that the driver is not compatible with the application program;

S6013: If not, determine that the driver is compatible with the application program.

As described in the above steps S6010 to S6013, the above running data may be a running log. When the above application is in a running state, a corresponding running log will be generated. The above running log can specifically be the current running environment of the application, CPU and memory. , Logs of operating system status. This embodiment first obtains the running log generated during the running of the application program, where the running log is stored in the form of a file. Then further determine whether the operation log generates error data and/or abnormal data. If error data and/or abnormal data are generated in the above operation log, it indicates that the application program after installation of the driver upgrade process has unstable problems. There are also errors and exceptions, and the application cannot run normally, so it can be determined that the driver is incompatible with the application, that is, the above evaluation result is that the driver is incompatible with the application. And if no error data and/or abnormal data are generated in the above operation log, it indicates that the application program after the installation of the driver upgrade processing can still run normally, and then it can be determined that the driver is compatible with the application program, that is, the above evaluation result is that the driver and Compatible with applications. This embodiment can intelligently detect the running status of the application after the upgrade process of installing the driver by judging whether there is error data and/or abnormal data in the running log generated after the application is running, and then can quickly according to the Run conditions to get the corresponding evaluation results.

Further, in an embodiment of the present application, the running data includes the process identifier of the running process, and the above step S601 includes:

S6014: Obtain the PIDs (process identifiers) of all running processes corresponding to the application program;

S6015: Determine whether the PID of the designated running process has changed within the first preset time period, where the designated running process is one or more running processes among all the running processes;

S6016: If yes, determine that the driver is not compatible with the application program;

S6017: If not, determine that the driver is compatible with the application program.

As described in the above steps S6014 to S6017, the application program after running is composed of multiple running processes, and the operating system where the application program is located will assign multiple corresponding process identifiers (PID) to these processes. Unique identification number). When some specified running process has changed, for example, the specified running process disappears or the process identifier PID of the specified running process has changed, it can be determined that the specified running process has crashed, and then the specified running process can be determined. The application corresponding to the running process has a problem or malfunction. In this embodiment, the above-mentioned running data may be the running process PID. When the above-mentioned application program is in the running state, the process identifier PIDs of all running processes corresponding to the application program are first acquired. Then it is judged whether the PID of the designated running process has changed within the first preset time, wherein the designated running process is one or more running processes among all the running processes. For example, the designated running process is all the running processes mentioned above. Some resident processes in. If the PID of the specified running process has changed, that is, the PID of the above resident process has changed, such as disappeared, it can indicate that the application program is abnormal and the application program cannot run normally. Therefore, it can be determined that the above driver and the application The program is not compatible, that is, the above evaluation result is that the driver is not compatible with the application. In addition, the above-mentioned first preset time can be set according to actual needs, for example, it can be set to 5 minutes, which is not specifically limited here. If the PID of the running process does not change, it indicates that the application program can still run normally after the driver is installed and upgraded, and it can be determined that the driver is compatible with the application program, that is, the above evaluation result is that the driver is compatible with the application program. In this embodiment, by judging whether the process identifier PID of the running process corresponding to the application program has changed within a preset time period, it can intelligently detect the running status of the application program after the driver is installed and upgraded. According to the operation situation, the corresponding evaluation result is obtained.

2, an embodiment of the present application also provides a device for preventing hijacking of dynamic link library files, including:

The creation module 1 is used to create a driver corresponding to the application before starting the application for the first time;

The first judgment module 2 is used to judge whether a copy request from an external first DLL (Dynamic Link Library) file to the specified directory of the application program is received, wherein the form of the copy request is an I/O request;

The extraction module 3 is configured to extract the first name of the first DLL file if the copy request is received;

The second judgment module 4 is configured to read a preset white list through the driver, and determine whether the first name exists in the white list, wherein the white list stores a plurality of designated names;

The verification module 5 is configured to verify and sign the first DLL file according to a first preset rule if the first name exists in the white list, to obtain a corresponding verification result;

The first processing module 6 is configured to perform corresponding processing on the copy request according to the verification result.

In this embodiment, the implementation process of the functions and roles of the creation module, the first judgment module, the extraction module, the second judgment module, the verification module and the first processing module in the above-mentioned device for preventing the hijacking of dynamic link library files is detailed in The implementation process of corresponding steps S1-S6 in the above method for preventing the hijacking of dynamic link library files will not be repeated here.

Further, in an embodiment of the present application, the above-mentioned device for preventing hijacking of dynamic link library files includes:

The receiving module is used to receive the designated names corresponding to multiple designated DLL files input by the user;

The input module is used to input all the specified names into the pre-created first list;

The encryption module is used to perform encryption processing on the first list to obtain the white list.

In this embodiment, the implementation process of the functions and functions of the receiving module, input module, and encryption module in the device for preventing hijacking of dynamic link library files is detailed in the corresponding steps S400-S402 in the method for preventing hijacking of dynamic link library files. The realization process will not be repeated here.

Further, in an embodiment of the present application, the above-mentioned verification module includes:

The first obtaining unit is configured to obtain the resource source of the first DLL file, and determine whether the first DLL file is a resource issued by a third party;

The first determining unit is configured to determine whether the first DLL file contains a corresponding agency signature certificate if the first DLL file is a resource issued by a third party;

The second obtaining unit is configured to obtain the latest version of the certificate revocation list of the certification authority corresponding to the agency signature certificate if the first DLL file contains the agency signature certificate;

The second determining unit is configured to determine whether the certificate revocation list contains the institution-signed certificate;

The first determining unit is configured to determine that the first DLL file passes the verification if the first certificate is not included in the certificate revocation list;

The second determining unit is configured to determine that the first DLL file fails the verification if the first certificate is included in the certificate revocation list.

In this embodiment, the first acquisition unit, the first judgment unit, the second acquisition unit, the second judgment unit, the first judgment unit, and the second judgment included in the verification module in the device for preventing hijacking of dynamic link library files For the implementation process of the function and role of the unit, please refer to the implementation process of corresponding steps S500-S505 in the above method for preventing the hijacking of dynamic link library files, which will not be repeated here.

An extracting unit, configured to extract the first digital signature of the first DLL file if the first DLL file is not a resource issued by a third party;

A calling unit for calling a public key pre-stored in the driver to decrypt the first digital signature to obtain a first hash value;

A calculation unit, configured to perform a hash calculation on the text content of the first DLL file to obtain a second hash value;

The third judging unit is used to judge whether the first hash value and the second hash value are the same;

A third determining unit, configured to determine that the first DLL file passes the verification if the first hash value is the same as the second hash value;

The fourth determining unit is configured to determine that the first DLL file fails the verification if the first hash value is not the same as the second hash value.

In this embodiment, the functions and effects of the extraction unit, the calling unit, the calculation unit, the third judgment unit, the third judgment unit, and the fourth judgment unit included in the verification module in the above-mentioned device for preventing the hijacking of dynamic link library files For the specific implementation process, please refer to the implementation process of corresponding steps S506-S511 in the above method for preventing hijacking of dynamic link library files, which will not be repeated here.

Further, in an embodiment of the present application, the device for preventing dynamic link library file hijacking includes:

The running module is used to run the application program;

The evaluation module is used to obtain the operating data generated during the running of the application program, and to evaluate the operating data according to a second preset rule to obtain a corresponding evaluation result, wherein the evaluation result includes the driver and The application program is compatible or the driver is incompatible with the application program;

The second processing module is configured to perform corresponding processing on the driver or the application program according to the evaluation result.

In this embodiment, the implementation process of the functions and roles of the running module, the evaluation module and the second processing module in the device for preventing hijacking of dynamic link library files is detailed in the corresponding step S600- in the method for preventing hijacking of dynamic link library files. The implementation process of S602 will not be repeated here.

Further, in an embodiment of the present application, the operation data includes an operation log, and the above evaluation module includes:

The third obtaining unit is configured to obtain the running log generated during the running of the application program;

The fourth judging unit is used to judge whether there are error data and/or abnormal data in the operation log;

The fifth determining unit is configured to determine that the driver is not compatible with the application program if it is so;

The sixth determining unit is configured to determine that the driver is compatible with the application program if not.

In this embodiment, the implementation process of the functions and functions of the third acquisition unit, the fourth judgment unit, the fifth judgment unit, and the sixth judgment unit included in the evaluation module in the above-mentioned device for preventing the hijacking of dynamic link library files is detailed in The implementation process of corresponding steps S6010-S6013 in the above method for preventing the hijacking of dynamic link library files will not be repeated here.

Further, in an embodiment of the present application, the running data includes the process identifier of the running process, and the above evaluation module includes:

The fourth acquiring unit is used to acquire PIDs (process identifiers) of all running processes corresponding to the application program;

The fifth judgment unit is used to judge whether the PID of the designated running process has changed within the first preset time period, wherein the designated running process is one or more running processes among all the running processes;

The seventh determining unit is configured to, if yes, determine that the driver is not compatible with the application program;

The eighth determining unit is configured to determine that the driver is compatible with the application program if not.

In this embodiment, the implementation process of the functions and functions of the fourth acquisition unit, the fifth judgment unit, the seventh judgment unit and the eighth judgment unit included in the evaluation module in the above-mentioned device for preventing the hijacking of dynamic link library files is detailed in The implementation process of corresponding steps S6014-S6017 in the above method for preventing the hijacking of dynamic link library files will not be repeated here.

Referring to FIG. 3, an embodiment of the present application also provides a computer device. The computer device may be a server, and its internal structure may be as shown in FIG. 3. The computer equipment includes a processor, a memory, a network interface, and a database connected through a system bus. Among them, the processor designed for the computer equipment is used to provide calculation and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer equipment is used for data such as copy requests and whitelists. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor to implement the method for preventing the hijacking of a dynamic link library file shown in any of the above exemplary embodiments; wherein, the step of the method for preventing the hijacking of a dynamic link library file is to start the Before the application, create a driver corresponding to the application; determine whether a copy request from an external first DLL file to the specified directory of the application is received, wherein the copy request is in the form of an I/O request; If the copy request is received, extract the first name of the first DLL file from the copy request; read the preset white list through the driver, and determine whether the first name exists in the white list A name, where multiple designated names are stored in the white list; if the first name exists in the white list, the first DLL file is verified and signed according to the first preset rule to obtain the corresponding According to the verification result, corresponding processing is performed on the copy request.

Those skilled in the art can understand that the structure shown in FIG. 3 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the devices and computer equipment to which the solution of the present application is applied.

An embodiment of the present application also provides a computer-readable storage medium. The storage medium is a volatile storage medium or a non-volatile storage medium, and a computer program is stored thereon. The computer program is executed by one or more processors. During execution, one or more processors are executed to implement the steps in the embodiment of the method for preventing dynamic link library file hijacking; wherein, the method for preventing dynamic link library file hijacking is specifically: when the application is started for the first time Before the program, create a driver corresponding to the application program; determine whether a copy request from an external first DLL file to the specified directory of the application program is received, wherein the copy request is in the form of an I/O request; if After receiving the copy request, extract the first name of the first DLL file from the copy request; read the preset white list through the driver, and determine whether the first name exists in the white list Name, wherein multiple designated names are stored in the white list; if the first name exists in the white list, the first DLL file is verified and signed according to the first preset rule to obtain the corresponding Verification result; according to the verification result, corresponding processing is performed on the copy request.

In summary, the method, device, and computer equipment for preventing the hijacking of dynamic link library files provided in the embodiments of the present application create a driver corresponding to the application program before starting the application program for the first time; determine whether an external device is received The copy request sent by the first DLL file to the specified directory of the application program, wherein the copy request is in the form of an I/O request; if the copy request is received, the first copy request is extracted from the copy request The first name of the DLL file; read the preset white list through the driver, and determine whether the first name exists in the white list, wherein a plurality of designated names are stored in the white list; if the If the first name exists in the whitelist, the first DLL file is verified and signed according to the first preset rule to obtain the corresponding verification result; according to the verification result, the copy request is corresponded的处理。 Treatment. In this application, only when the first DLL file exists in the whitelist, will the first DLL file be verified and signed, so there is no need to verify and sign the DLL files that are not in the whitelist, which effectively improves The processing efficiency of the copy request simplifies the processing flow of verifying the signature. And only after the first DLL file has passed the verification signature, can the copy request be processed, which effectively prevents the DLL file in the application from being hijacked, and improves the security and stability of the application. In addition, the verification and signature processing of the first DLL file is carried out by the driver, that is, it is completed before the application is started, so there is no need for the application to verify and sign every internal DLL file when it is started, which is effective Improved the startup rate of applications.

A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing relevant hardware through a computer program. The computer program can be stored and a non-volatile computer readable storage. In the medium, when the computer program is executed, it may include the procedures of the above-mentioned method embodiments. Wherein, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and/or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not a limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

The above are only the preferred embodiments of this application, and do not limit the scope of this application. Any equivalent structure or equivalent process transformation made using the content of the specification and drawings of this application, or directly or indirectly applied to other related The technical field is equally included in the scope of patent protection of this application.

Claims

A method to prevent hijacking of dynamic link library files, including:

Before starting the application for the first time, create a driver corresponding to the application;

Judging whether a copy request sent by an external first DLL file to the specified directory of the application program is received, wherein the form of the copy request is an I/O request;

If the copy request is received, extract the first name of the first DLL file from the copy request;

Read a preset white list by the driver, and determine whether the first name exists in the white list, wherein a plurality of designated names are stored in the white list;

If the first name exists in the whitelist, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result;

According to the verification result, corresponding processing is performed on the copy request.
The method for preventing the hijacking of a dynamic link library file according to claim 1, before the step of reading a preset white list by the driver and determining whether the first name exists in the white list, the method comprises:

Receive the designated names corresponding to multiple designated DLL files input by the user;

Enter all the specified names into the pre-created first list;

Encryption processing is performed on the first list to obtain the white list.
The method for preventing the hijacking of a dynamic link library file according to claim 1, wherein the step of verifying and signing the first DLL file according to a first preset rule to obtain a verification result includes:

Acquiring the resource source of the first DLL file, and determining whether the first DLL file is a resource issued by a third party;

If the first DLL file is a resource issued by a third party, determining whether the first DLL file contains a corresponding agency signature certificate;

If the first DLL file contains the agency signature certificate, acquiring the latest version of the certificate revocation list of the certification agency corresponding to the agency signature certificate;

Judging whether the certificate revocation list contains the institution-signed certificate;

If the first certificate is not included in the certificate revocation list, determining that the first DLL file passes the verification;

If the first certificate is included in the certificate revocation list, it is determined that the first DLL file fails the verification.
According to the method for preventing the hijacking of a dynamic link library file according to claim 3, after the step of obtaining the resource source of the first DLL file and determining whether the first DLL file is a resource issued by a third party, the method comprises:

If the first DLL file is not a resource issued by a third party, extract the first digital signature of the first DLL file;

Calling the pre-stored public key in the driver to decrypt the first digital signature to obtain the first hash value;

Performing a hash calculation on the body content of the first DLL file to obtain a second hash value;

Judging whether the first hash value is the same as the second hash value;

If the first hash value is the same as the second hash value, it is determined that the first DLL file passes the verification;

If the first hash value is not the same as the second hash value, it is determined that the first DLL file fails the verification.
The method for preventing the hijacking of a dynamic link library file according to claim 1, after the step of correspondingly processing the copy request according to the verification result, the method comprises:

Run the application;

Obtain the operating data generated during the running of the application program, and evaluate the operating data according to the second preset rule to obtain the corresponding evaluation result, wherein the evaluation result includes the driver and the application program. Compatible or the driver is not compatible with the application;

According to the evaluation result, corresponding processing is performed on the driver or the application program.
The method for preventing the hijacking of a dynamic link library file according to claim 5, wherein the running data includes a running log, and the running data generated during the running of the application is obtained, and the running data is processed according to a second preset rule. The steps to run the data for evaluation and obtain the corresponding evaluation results include:

Acquiring the running log generated during the running of the application;

Determine whether there are error data and/or abnormal data in the operation log;

If it is, it is determined that the driver is not compatible with the application program;

If not, it is determined that the driver is compatible with the application program.
The method for preventing the hijacking of a dynamic link library file according to claim 5, wherein the running data includes a process identifier of a running process, and the running data generated during the running of the application program is acquired, and the running data is generated according to a second preset The steps of evaluating the operating data by rules to obtain corresponding evaluation results include:

Acquiring PIDs of all running processes corresponding to the application;

Judging whether the PID of the designated running process has changed within the first preset time period, wherein the designated running process is one or more running processes among all the running processes;

If it is, it is determined that the driver is not compatible with the application program;

If not, it is determined that the driver is compatible with the application program.
A device for preventing hijacking of dynamic link library files, including:

A creation module for creating a driver corresponding to the application before starting the application for the first time;

The first judgment module is used to judge whether a copy request from an external first DLL file to the specified directory of the application program is received, wherein the form of the copy request is an I/O request;

An extraction module, configured to extract the first name of the first DLL file if the copy request is received;

The second judgment module is configured to read a preset white list through the driver, and judge whether the first name exists in the white list, wherein a plurality of designated names are stored in the white list;

A verification module, configured to verify and sign the first DLL file according to a first preset rule if the first name exists in the white list to obtain a corresponding verification result;

The first processing module is configured to perform corresponding processing on the copy request according to the verification result.
A computer device including:

One or more processors;

Memory

One or more computer programs, wherein the one or more computer programs are stored in the memory and configured to be executed by the one or more processors, and the one or more computer programs are configured to execute A method for preventing hijacking of a dynamic link library file; wherein the method for preventing hijacking of a dynamic link library file has the following steps:

Before starting the application for the first time, create a driver corresponding to the application;

Judging whether a copy request sent by an external first DLL file to the specified directory of the application program is received, wherein the form of the copy request is an I/O request;

If the copy request is received, extract the first name of the first DLL file from the copy request;

Read a preset white list by the driver, and determine whether the first name exists in the white list, wherein a plurality of designated names are stored in the white list;

If the first name exists in the whitelist, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result;

According to the verification result, corresponding processing is performed on the copy request.
9. The computer device according to claim 9, before the step of reading a preset white list through the driver and determining whether the first name exists in the white list, the method comprises:

Receive the designated names corresponding to multiple designated DLL files input by the user;

Enter all the specified names into the pre-created first list;

Encryption processing is performed on the first list to obtain the white list.
9. The computer device according to claim 9, wherein the step of verifying and signing the first DLL file according to a first preset rule to obtain a verification result comprises:

Acquiring the resource source of the first DLL file, and determining whether the first DLL file is a resource issued by a third party;

If the first DLL file is a resource issued by a third party, determining whether the first DLL file contains a corresponding agency signature certificate;

If the first DLL file contains the agency signature certificate, acquiring the latest version of the certificate revocation list of the certification agency corresponding to the agency signature certificate;

Judging whether the certificate revocation list contains the institution-signed certificate;

If the first certificate is not included in the certificate revocation list, determining that the first DLL file passes the verification;

If the first certificate is included in the certificate revocation list, it is determined that the first DLL file fails the verification.
11. The computer device according to claim 11, after the step of obtaining the resource source of the first DLL file and determining whether the first DLL file is a resource issued by a third party, comprising:

If the first DLL file is not a resource issued by a third party, extract the first digital signature of the first DLL file;

Calling the pre-stored public key in the driver to decrypt the first digital signature to obtain the first hash value;

Performing a hash calculation on the body content of the first DLL file to obtain a second hash value;

Judging whether the first hash value is the same as the second hash value;

If the first hash value is the same as the second hash value, it is determined that the first DLL file passes the verification;

If the first hash value is not the same as the second hash value, it is determined that the first DLL file fails the verification.
The computer device according to claim 9, after the step of correspondingly processing the copy request according to the verification result, the method comprises:

Run the application;

Obtain the operating data generated during the running of the application program, and evaluate the operating data according to the second preset rule to obtain the corresponding evaluation result, wherein the evaluation result includes the driver and the application program. Compatible or the driver is not compatible with the application;

According to the evaluation result, corresponding processing is performed on the driver or the application program.
The computer device according to claim 13, wherein the operation data includes an operation log, and the operation data generated during the operation of the application program is obtained, and the operation data is evaluated according to a second preset rule to obtain The steps of the corresponding evaluation results include:

Acquiring the running log generated during the running of the application;

Determine whether there are error data and/or abnormal data in the operation log;

If it is, it is determined that the driver is not compatible with the application program;

If not, it is determined that the driver is compatible with the application program.
The computer device according to claim 13, wherein the running data includes a process identifier of a running process, the acquiring running data generated during the running of the application program, and comparing the running data according to a second preset rule The steps to perform the evaluation and obtain the corresponding evaluation results include:

Acquiring PIDs of all running processes corresponding to the application;

Judging whether the PID of the designated running process has changed within the first preset time period, wherein the designated running process is one or more running processes among all the running processes;

If it is, it is determined that the driver is not compatible with the application program;

If not, it is determined that the driver is compatible with the application program.
A computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, a method for preventing the hijacking of a dynamic link library file is implemented; wherein the prevention of the dynamic link library file The method of hijacking is as follows:

Before starting the application for the first time, create a driver corresponding to the application;

Judging whether a copy request sent by an external first DLL file to the specified directory of the application program is received, wherein the form of the copy request is an I/O request;

If the copy request is received, extract the first name of the first DLL file from the copy request;

Read a preset white list by the driver, and determine whether the first name exists in the white list, wherein a plurality of designated names are stored in the white list;

If the first name exists in the whitelist, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result;

According to the verification result, corresponding processing is performed on the copy request.
The computer-readable storage medium according to claim 16, before the step of reading a preset white list by the driver and determining whether the first name exists in the white list, the method comprises:

Receive the designated names corresponding to multiple designated DLL files input by the user;

Enter all the specified names into the pre-created first list;

Encryption processing is performed on the first list to obtain the white list.
16. The computer-readable storage medium according to claim 16, wherein the step of verifying and signing the first DLL file according to a first preset rule to obtain a verification result comprises:

Acquiring the resource source of the first DLL file, and determining whether the first DLL file is a resource issued by a third party;

If the first DLL file is a resource issued by a third party, determining whether the first DLL file contains a corresponding agency signature certificate;

If the first DLL file contains the agency signature certificate, acquiring the latest version of the certificate revocation list of the certification agency corresponding to the agency signature certificate;

Judging whether the certificate revocation list contains the institution-signed certificate;

If the first certificate is not included in the certificate revocation list, determining that the first DLL file passes the verification;

If the first certificate is included in the certificate revocation list, it is determined that the first DLL file fails the verification.
The computer-readable storage medium according to claim 18, after the step of obtaining the resource source of the first DLL file and determining whether the first DLL file is a resource issued by a third party, the method comprises:

If the first DLL file is not a resource issued by a third party, extract the first digital signature of the first DLL file;

Calling the pre-stored public key in the driver to decrypt the first digital signature to obtain the first hash value;

Performing a hash calculation on the body content of the first DLL file to obtain a second hash value;

Judging whether the first hash value is the same as the second hash value;

If the first hash value is the same as the second hash value, it is determined that the first DLL file passes the verification;

If the first hash value is not the same as the second hash value, it is determined that the first DLL file fails the verification.
18. The computer-readable storage medium according to claim 18, after the step of correspondingly processing the copy request according to the verification result, the method comprises:

Run the application;

Obtain the operating data generated during the running of the application program, and evaluate the operating data according to the second preset rule to obtain the corresponding evaluation result, wherein the evaluation result includes the driver and the application program. Compatible or the driver is not compatible with the application;

According to the evaluation result, corresponding processing is performed on the driver or the application program.