CN110688661A - Method and device for preventing dynamic link library file hijacking and computer equipment - Google Patents
Method and device for preventing dynamic link library file hijacking and computer equipment Download PDFInfo
- Publication number
- CN110688661A CN110688661A CN201910817923.9A CN201910817923A CN110688661A CN 110688661 A CN110688661 A CN 110688661A CN 201910817923 A CN201910817923 A CN 201910817923A CN 110688661 A CN110688661 A CN 110688661A
- Authority
- CN
- China
- Prior art keywords
- application program
- dll file
- driver
- file
- running
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- Storage Device Security (AREA)
Abstract
The application discloses a method, a device and computer equipment for preventing dynamic link library file hijacking, wherein the method comprises the following steps: before the application program is started for the first time, creating a drive corresponding to the application program; judging whether a copy request sent by an external first DLL file to a specified directory of an application program is received; if yes, extracting a first name of the first DLL file from the copying request; reading a preset white list through driving, and judging whether a first name exists in the white list or not; if so, 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 method and the device can effectively prevent the DLL file in the application program from being hijacked. In addition, the verification signature processing of the first DLL file is performed by a driver, so that the starting rate of the application program is effectively improved.
Description
Technical Field
The application relates to the technical field of computer security, in particular to a method and a device for preventing dynamic link library file hijacking and computer equipment.
Background
The hijacking of a DLL (Dynamic Link Library) file is generally to hijack system DLL files necessary for application programs such as usp1.dll, ws2_32.DLL and lpk.dll, and mainly to release a same-name DLL file, which is usually a trojan virus with the same name as any system DLL file, from a specified directory in the application program corresponding to a loading sequence according to the loading sequence of a DLL search path mode, so that the application program becomes a loader of a malicious DLL. If the homonymous DLL file is not checked and killed in time, the homonymous DLL file disguised by Trojan horse virus can be loaded in advance when the application program is started, and the application program is damaged finally, so that the system where the application program is located is infected by the virus.
The existing method for preventing the DLL file from being hijacked generally comprises the steps of checking and signing all DLL files needing to be loaded when an application program is started, and normally starting the application program after checking and killing all DLL files which cannot pass through the checked and signed files. If dozens of DLL files which need to be loaded when the application program is started exist, the application program needs to check and sign the dozens of DLL files when the application program is started every time, the sign checking process is complicated and long in consumed time, the starting time of the application program is greatly prolonged, and the use experience of a user is not good.
Disclosure of Invention
The application mainly aims to provide a method, a device and computer equipment for preventing dynamic link library files from being hijacked, and aims to solve the technical problems that the signature verification process in the existing mode for preventing DLL files from being hijacked is complicated and consumes long time, so that the starting time of an application program is greatly increased, and the use experience of a user is not good.
The application provides a method for preventing dynamic link library file hijacking, which comprises the following steps:
before the application program is started for the first time, creating a driver corresponding to the application program;
judging whether a copy request sent by an external first DLL file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request;
if the copy request is received, extracting a first name of the first DLL file from the copy request;
reading a preset white list through the driver, and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list;
if the first name exists in the white list, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result;
and correspondingly processing the copy request according to the verification result.
Optionally, 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 includes:
receiving appointed names which are input by a user and respectively correspond to a plurality of appointed DLL files;
inputting all the specified names into a pre-created first list;
and encrypting the first list to obtain the white list.
Optionally, the step of performing a verification signature on the first DLL file according to a first preset rule to obtain a verification result includes:
acquiring a resource source of the first DLL file, and judging 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, judging whether the first DLL file contains a corresponding agency signature certificate;
if the first DLL file contains the authority signature certificate, acquiring a certificate revocation list of the latest version of the certification authority corresponding to the authority signature certificate;
judging whether the certificate revocation list contains the agency signature certificate or not;
if the certificate revocation list does not contain the first certificate, determining that the first DLL file passes verification;
if the first certificate is contained in the certificate revocation list, the first DLL file is determined not to be verified.
Optionally, after the step of obtaining the resource source of the first DLL file and determining whether the first DLL file is a resource published by a third party, the method includes:
if the first DLL file is not a resource released by a third party, extracting a first digital signature of the first DLL file;
calling a public key prestored in the driver to decrypt the first digital signature to obtain a first hash value;
performing hash calculation on the text 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, judging that the first DLL file passes the verification;
and if the first hash value is different from the second hash value, judging that the first DLL file does not pass the verification.
Optionally, after the step of performing corresponding processing on the copy request according to the check result, the method includes:
running the application program;
acquiring running data generated by the application program in the running process, and evaluating the running data according to a second preset rule to obtain a corresponding evaluation result, wherein the evaluation result comprises that the driver is compatible with the application program or that the driver is incompatible with the application program;
and correspondingly processing the drive or the application program according to the evaluation result.
Optionally, the step of obtaining the running data generated by the application program in the running process, and evaluating the running data according to a second preset rule to obtain a corresponding evaluation result includes:
acquiring an operation log generated in the operation process of the application program;
judging whether the running log has error data and/or abnormal data or not;
if yes, judging that the driver is not compatible with the application program;
and if not, judging that the driver is compatible with the application program.
Optionally, the step of obtaining the running data generated by the application program in the running process, and evaluating the running data according to a second preset rule to obtain a corresponding evaluation result includes:
acquiring the PID of all running processes corresponding to the application program;
judging whether the PID of a designated running process changes within a first preset time period, wherein the designated running process is one or more running processes in all the running processes;
if yes, judging that the driver is not compatible with the application program;
and if not, judging that the driver is compatible with the application program.
The present application further provides a device for preventing dynamic link library file hijacking, including:
the creating module is used for creating a driver corresponding to the application program before the application program is started for the first time;
the first judging module is used for judging whether a copy request sent by an external first DLL file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request;
the extracting module is used for extracting the first name of the first DLL file if the copying request is received;
the second judgment module is used for reading a preset white list through the driver and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list;
the verification module is used for verifying and signing the first DLL file according to a first preset rule if the first name exists in the white list, and obtaining a corresponding verification result;
and the first processing module is used for carrying out corresponding processing on the copy request according to the verification result.
The present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.
The present application also provides a computer-readable storage medium having stored thereon a computer program which, when being executed by a processor, carries out the steps of the above-mentioned method.
The method, the device, the computer equipment and the storage medium for preventing the file hijacking of the dynamic link library have the following beneficial effects:
according to the method, the device, the computer equipment and the storage medium for preventing the file hijacking of the dynamic link library, before the application program is started for the first time, a driver corresponding to the application program is established; judging whether a copy request sent by an external first DLL file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request; if the copy request is received, extracting a first name of the first DLL file from the copy request; reading a preset white list through the driver, and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list; if the first name exists in the white list, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result; and correspondingly processing the copy request according to the verification result. According to the method and the device, the first DLL file is checked and signed only when the first DLL file exists in the white list, so that the DLL file which is not in the white list does not need to be checked and signed, the processing efficiency of the copy request is effectively improved, and the processing flow of checking and signing is simplified. And only after the first DLL file passes the verification signature, the copy request is allowed to be processed, so that the condition that the DLL file in the application program is hijacked is effectively prevented, and the safety and stability of the application program are improved. In addition, the verification and signature processing of the first DLL file is performed by a driver, namely, the verification and signature processing is completed before the application program is started, so that the verification and signature of each internal DLL file during the starting of the application program are not needed, and the starting rate of the application program is effectively improved.
Drawings
FIG. 1 is a flowchart illustrating a method for preventing hijacking of a dynamic link library file according to an embodiment of the present application;
FIG. 2 is a block diagram illustrating an apparatus for preventing hijacking of a dynamic link library file 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 implementation, functional features and advantages of the objectives of the present application will be further explained with reference to the accompanying drawings.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
It should be noted that all directional indicators (such as upper, lower, left, right, front and rear … …) in the embodiments of the present application are only used to explain the relative position relationship between the components, the movement situation, etc. in a specific posture (as shown in the drawings), and if the specific posture is changed, the directional indicator is changed accordingly, and the connection may be a direct connection or an indirect connection.
Referring to fig. 1, a method for preventing dynamic link library file hijacking according to an embodiment of the present application includes:
s1: before the application program is started for the first time, creating a driver corresponding to the application program;
s2: judging whether a copy request sent by a first external DLL (dynamic link library) file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request;
s3: if the copy request is received, extracting a first name of the first DLL file from the copy request;
s4: reading a preset white list through the driver, and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list;
s5: if the first name exists in the white list, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result;
s6: and correspondingly processing the copy request according to the verification result.
As described in the foregoing steps S1 and S2, the execution subject of the embodiment of the present application is a device for preventing the dynamic link library file from being hijacked, and specifically, the execution subject may be a Windows file system installed with a driver. In the embodiment, the verification of the first DLL file is completed by creating the driver corresponding to the application program, and the verification of all DLL files needing to be loaded is not required when the application program is started, so that the starting speed of the application program is improved. Specifically, after the installation of the application program is completed and before the application program is started for the first time, a driver corresponding to the application program is created first, where the driver is a filter driver, and the corresponding drivers may be created simultaneously in the installation process of the application program, or may be created within an arbitrary time period before the application program is successfully installed and started for the first time, so that after the creation of the driver is completed, the anti-hijack processing for the external first DLL file may be performed through the driver. When a copy request of an external first DLL file in the appointed directory of the application program is received, a first name corresponding to the first DLL file in the copy request is extracted. The copy request may refer to that the first DLL file is used to perform processes such as overwriting, adding, modifying or replacing the DLL file in the application program, and the copy request is in the form of an input/output (I/O) request generated by a user operation. In addition, when a user issues an I/O Request, the I/O Request is generally packaged into IRP (I/O 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, since there may be a situation that a trojan virus intrudes or hijacks a DLL file in an application program, IPR information corresponding to the I/O request is not directly released, but a first DLL file corresponding to the I/O request is subjected to a signature verification process, and the signature verification process first needs to obtain a first name of the first DLL file. Specifically, the first name corresponding to the first DLL file is obtained by intercepting IPR information corresponding to the I/O request to obtain the IRP information, and then analyzing the IPR information.
After the first name is obtained, the driver reads the preconfigured white list to determine whether the first name exists in the white list, as described in steps S3 and S4, where the specified directory may be a directory currently loaded by the application, that is, an installation directory of the application, or a system directory, and so on. The white list stores a plurality of designated names, and the designated names are respectively corresponding to DLL files which need to be checked and signed by the application program. Specifically, the name of the first DLL file may be matched with all specified names in the white list to obtain a matching result, and whether the first name exists in the white list may be obtained according to the matching result. Further, if the first name does not exist in the white list, it indicates that the first DLL file is a resource that is not needed by the application program, for example, a windows system DLL file forged by a virus trojan horse, the driver directly rejects processing the copy request, that is, returns a reject message to the IPR information to prohibit copying the first DLL file into the specified directory, so that the application program can be effectively prevented from being damaged. In another embodiment, the first DLL file with the DLL hijacking risk can be further subjected to checking and killing processing, specifically, the information of the first DLL file is uploaded to a server, and then the first DLL file is checked and killed through the server, so that original file resources in the application program cannot be modified, the diffusion of the DLL file with the DLL hijacking risk is restrained, and the application program is effectively prevented from being damaged by resources with unknown sources.
As described in the foregoing 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 program, but the first DLL file is further subjected to signature verification processing to detect the validity of the first DLL file, that is, the first DLL file is subjected to signature verification according to a first preset rule to obtain a verification result, and the copy request is subjected to corresponding processing according to the verification result. The first preset rule is to adopt a corresponding verification signature mode according to the data source of the first DLL file. In addition, the checking result includes that the first DLL file passes the checking and the first DLL file fails the checking, and the step of performing corresponding processing on the copy request according to the checking result may specifically include: and when the verification result shows that the first DLL file passes the verification, the copy request can be proved to be normal file processing operation, and the first DLL file is a resource required by the application program, for example, the first DLL file is a file generated in the application program upgrading process, or a file generated in the testing process of testing the application program by a developer when the first DLL file is used, the copy request is allowed to be processed, so that the updating or testing process of the application program is completed. And when the verification result shows that the first DLL file does not pass the verification, the copying request can be proved to be abnormal file processing operation, namely the first DLL file is not a resource required by the application program, for example, the first DLL file can be a Trojan virus or a file for DLL hijacking, the copying request is refused to be processed, and the phenomenon that the DLL hijacking is caused by copying the first DLL file into a specified directory of the application program is avoided. According to the embodiment, the first DLL file is subjected to signature verification processing only when the first DLL file exists in the white list, so that the DLL file which is not in the white list does not need to be subjected to signature verification, the processing efficiency of the copy request is effectively improved, and the processing flow of signature verification is simplified. And only when the first DLL file passes the verification signature, the copy request is allowed to be processed, so that the condition that the DLL file in the application program is hijacked is effectively prevented, and the safety and stability of the application program are improved. In addition, the verification and signature processing of the first DLL file is performed by a driver, namely, the verification and signature processing is completed before the application program is started, so that the verification and signature of each internal DLL file during the starting of the application program are not needed, and the starting rate of the application program is effectively improved.
Further, in an embodiment of the present application, before the step S4, the method includes:
s400: receiving appointed names which are input by a user and respectively correspond to a plurality of appointed DLL files;
s401: inputting all the specified names into a pre-created first list;
s402: and encrypting the first list to obtain the white list.
As described in the foregoing steps S400 to S402, before the step of reading the preset white list through the driver and determining whether the first name exists in the white list, the method further includes a step of creating the white list, which may specifically include: and receiving the appointed names corresponding to a plurality of appointed DLL files input by a user, wherein the appointed DLL files are resources required by the application program. Then all the appointed names are input into the pre-created first list, and the first list is further encrypted to form the encrypted white list. In addition, after the first list is encrypted to obtain the white list, the corresponding key is sent to the driver, and the driver needs to decrypt the encrypted white list by virtue of the key to read data of all the specified names in the white list. In the embodiment, the driver including the corresponding secret key is set to have the authority to read the white list, so that the white list can be effectively prevented from being tampered, and the situation that the subsequent verification signature processing has problems due to the fact that the white list is tampered is effectively avoided.
Further, in an embodiment of the present application, the step S5 includes:
s500: acquiring a resource source of the first DLL file, and judging 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, judging whether the first DLL file contains a corresponding agency signature certificate;
s502: if the first DLL file contains the authority signature certificate, acquiring a certificate revocation list of the latest version of the certification authority corresponding to the authority signature certificate;
s503: judging whether the certificate revocation list contains the agency signature certificate or not;
s504: if the certificate revocation list does not contain the first certificate, determining that the first DLL file passes verification;
s505: if the first certificate is contained in the certificate revocation list, the first DLL file is determined not to be verified.
As described in the foregoing steps S500 to S505, when the first name of the first DLL file exists in the white list, a corresponding verification signature method needs to be adopted according to the resource source of the first DLL file, and a corresponding verification result is obtained. When the first DLL file is a third-party resource, the third-party resource is digitally signed in other ways, and the third-party resource cannot be signed for the second time by research personnel, so the Windows file system needs to uniformly manage the verification and signature processing of the first DLL file. Specifically, a resource source of a first DLL file is obtained first, and whether the first DLL file is a resource released by a third party is judged, wherein the resource source of the first DLL file can be determined by judging whether a secondary signature exists in the first DLL file, if so, the first DLL file is not a resource released by the third party, and if not, the first DLL file is a resource released by the third party. When the first DLL file is a resource issued by a third party, further judging whether the first DLL file contains a corresponding agency signature certificate, for example, the first DLL file is a resource digitally signed by using a microsoft certificate, and the agency signature certificate is a microsoft certificate; if the first DLL file contains the above-mentioned authority-signed certificate, the validity thereof needs to be recognized by judging the validity of the authority-signed certificate. Specifically, a Certificate Revocation List (CRL) of the latest version of the certificate authority corresponding to the certificate of authority signature is obtained, whether the certificate revocation list includes the certificate of authority signature is judged, if the certificate revocation list does not include the certificate of authority signature, it is indicated that the certificate of authority signature is still in the validity period, it can be determined that the first DLL file passes the verification, and then the copy request of the first DLL file is allowed to be processed. If the authority signature certificate is contained, the authority signature certificate is in the expiration date, namely the first DLL file corresponding to the authority signature certificate is an illegal third-party resource, the first DLL file can be judged not to pass the verification, then the copying request of the first DLL file can be refused to be processed, the condition that the DLL is hijacked due to the fact that the first DLL file is copied into the appointed directory of the application program is avoided, and the safety and the stability of the application program are effectively guaranteed. In another embodiment, if the first DLL file of the published resource belonging to the third party does not contain the authority signature certificate, it indicates that the first DLL file is an illegal third party resource, and at this time, the copy request of the first DLL file is directly refused to be processed, so that DLL hijacking caused by copying the first DLL file into the specified directory of the application program is effectively prevented, and the security and stability of the application program are ensured.
Further, in an embodiment of the present application, after the step S500, the method includes:
s506: if the first DLL file is not a resource released by a third party, extracting a first digital signature of the first DLL file;
s507: calling a public key prestored in the driver to decrypt the first digital signature to obtain a first hash value;
s508: performing hash calculation on the text content of the first DLL file to obtain a second hash value;
s509: judging 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, judging that the first DLL file passes the verification;
s511: and if the first hash value is different from the second hash value, judging that the first DLL file does not pass the verification.
As described in steps S506 to S511 above, if the first DLL file is not the resource published by the third party, another signature verification method different from that used when the first DLL file is the resource published by the third party needs to be used. When the first DLL file is not a resource issued by a third party, but a resource issued by a developer for encryption, the resource cannot be ensured to be completely safe, and the first DLL file may be tampered, so that the first DLL file also needs to be checked and signed to verify the validity of the DLL. Specifically, when the first DLL file is not a resource issued by a third party, first extracting a first digital signature of the first DLL file from a resource segment of the first DLL file, and then decrypting the first digital signature by using a public key prestored in the driver to obtain a first hash value, where the first DLL file is obtained by a developer after signing, and the signing process specifically includes: the method comprises the steps of carrying out Hash operation on a first DLL file by utilizing a Hash algorithm to obtain a digital fingerprint, then generating a public key and a private key pair by utilizing an elliptic curve digital signature algorithm, then encrypting the digital fingerprint by utilizing a private key to obtain a first digital signature, finally writing the first digital signature into a resource section of the first DLL file, and storing the public key into a driver. And after the first hash value is obtained, performing hash calculation on the text content of the first DLL file to obtain a second hash value. And comparing the first hash value with the second hash value to judge 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, the verification of the first digital signature is successful, the first DLL file is legal and has not been tampered, and therefore the first DLL file is judged to be verified, and then the processing of the copy request of the first DLL file is allowed. If the first hash value is different from the second hash value, the verification of the first digital signature is failed, the first DLL file is illegal, for example, the first DLL file is tampered, the first DLL file is judged not to be verified, then the copying request of the first DLL file is refused to be processed, the situation that the first DLL file is copied into the appointed directory of the application program to cause DLL hijacking is avoided, and the safety and the stability of the application program are effectively guaranteed.
Further, in an embodiment of the present application, after the step S6, the method includes:
s600: running the application program;
s601: acquiring running data generated by the application program in the running process, and evaluating the running data according to a second preset rule to obtain a corresponding evaluation result, wherein the evaluation result comprises that the driver is compatible with the application program or that the driver is incompatible with the application program;
s602: and correspondingly processing the drive or the application program according to the evaluation result.
As described in steps S600 to S602, installing the driver corresponding to the application may be regarded as an upgrade process for the application, but such an upgrade process may have a risk of a bug or an error, for example, an incompatibility between the driver and the application may occur. If the installed driver is not compatible with the application program, the normal operation or some normal functions of the application program may be affected, so that the embodiment further needs to verify the compatibility between the two, and prevent the normal operation of the application program from being interfered. Specifically, after the copy request is processed, the application program is firstly run, then the running data generated by the application program in the running process is obtained, and the obtained running data is evaluated according to a second preset rule, so as to obtain a corresponding evaluation result. The evaluating the obtained operation data according to the second preset rule may include multiple evaluating methods, for example, the evaluating may be performed by analyzing an operation log of the application program; evaluating can also be carried out by analyzing the process marker of the running process corresponding to the application program; the evaluation can also be performed by analyzing database data of the application, wherein the database data comprises user data, and/or default data, and/or configuration files and the like. In addition, the evaluation result comprises that the driver and the application program are compatible and the driver and the application program are incompatible. And when the evaluation result shows that the driver is compatible with the application program, the driver installation is indicated not to influence the normal operation of the application program, and the subsequent processing is not performed on the application program or the driver. In another embodiment, when the evaluation result indicates that the driver is incompatible with the application program, it is further required to analyze compatibility information of the driver incompatible with the application program according to the operating data, and then perform maintenance processing on the application program according to the compatibility information, or directly perform replacement processing on the driver, so as to solve the problem of incompatibility. In the embodiment, the corresponding evaluation result is obtained by evaluating the compatibility verification of the created driver and the application program, so that the corresponding processing of the application program or the driver according to the evaluation result is facilitated, and the normal operation of the application program can be effectively ensured.
Further, in an embodiment of the present application, the operation data includes an operation log, and the step S601 includes:
s6010: acquiring an operation log generated in the operation process of the application program;
s6011: judging whether the running log has error data and/or abnormal data or not;
s6012: if yes, judging that the driver is not compatible with the application program;
s6013: and if not, judging that the driver is compatible with the application program.
As described in the foregoing steps S6010 to S6013, the operation data may be an operation log, and when the application program is in an operation state, a corresponding operation log may be generated, where the operation log may specifically be a log of a current operation environment CPU, a memory, and an operating system status of the application program. The embodiment first obtains an operation log generated in the operation process of the application program, wherein the operation log is stored in a file form. And then further judging whether the running log generates error data and/or abnormal data, if the error data and/or the abnormal data are generated in the running log, the problem that the application program subjected to the upgrading processing of the installed driver is unstable is shown, errors and abnormalities exist, and the application program cannot normally run, so that the driver and the application program are judged to be incompatible, namely the evaluation result is that the driver and the application program are incompatible. And if no error data and/or abnormal data are generated in the operation log, indicating that the application program subjected to the upgrade processing of the installation driver can normally operate, and further judging that the driver is compatible with the application program, namely, the evaluation result is that the driver is compatible with the application program. The embodiment can intelligently detect the running condition of the application program subjected to the upgrade processing of the installation driver by judging whether error data and/or abnormal data exist in the running log generated after the application program runs, and further can quickly obtain a corresponding evaluation result according to the running condition.
Further, in an embodiment of the present application, the running data includes a process identifier of a running process, and the step S601 includes:
s6014: acquiring PIDs (process identifiers) of all running processes corresponding to the application program;
s6015: judging whether the PID of a designated running process changes within a first preset time period, wherein the designated running process is one or more running processes in all the running processes;
s6016: if yes, judging that the driver is not compatible with the application program;
s6017: and if not, judging that the driver is compatible with the application program.
As described in steps S6014 to S6017, the running application is composed of a plurality of running processes, and the operating system where the application is located allocates a plurality of corresponding process identifiers PID (process unique identification numbers) to the processes. When some specified running processes are changed, for example, the specified running processes disappear or the process identifier PID of the specified running processes is changed, it can be determined that the specified running processes are crashed, and it can be further determined that the application program corresponding to the specified running processes has a problem or a fault. In this embodiment, the running data may be running process PIDs, and when the application program is in a running state, the process identifier PIDs of all running processes corresponding to the application program are first obtained. Then, it is determined whether a PID of a designated running process changes within a first preset time, where the designated running process is one or more running processes among all the running processes, for example, some resident processes among all the running processes. If the PID of the specified running process changes, that is, the PID of the resident process changes, for example, disappears, it may indicate that the application program is abnormal and the application program cannot run normally, so it may be determined that the driver is incompatible with the application program, that is, the evaluation result is that the driver is incompatible with the application program. The first preset time may be set according to actual requirements, for example, may be set to 5 minutes, and is not particularly limited herein. And if the PID of the running process is not changed, the application program subjected to the upgrading processing of the installed driver can still run normally, and then the driver and the application program can be judged to be compatible, namely the evaluation result is that the driver and the application program are compatible. According to the embodiment, whether the process marker PID of the running process corresponding to the application program changes in the preset time period can be judged, so that the running condition of the application program subjected to the upgrading processing of the installation driver can be intelligently detected, and a corresponding evaluation result can be rapidly obtained according to the running condition.
Referring to fig. 2, an embodiment of the present application further provides an apparatus for preventing dynamic link library file hijacking, including:
the creating module 1 is used for creating a driver corresponding to the application program before the application program is started for the first time;
a first judging module 2, configured to judge whether a copy request issued by a first external DLL (dynamic link library) file to a specified directory of the application program is received, where the copy request is in the form of an I/O request;
the extracting module 3 is configured to extract the first name of the first DLL file if the copy request is received;
the second judging module 4 is configured to read a preset white list through the driver, and judge whether the first name exists in the white list, where a plurality of designated names are stored in the white list;
the verification module 5 is configured to, if the first name exists in the white list, perform verification signature on the first DLL file according to a first preset rule to obtain a corresponding verification result;
and the first processing module 6 is configured to perform corresponding processing on the copy request according to the check result.
In this embodiment, the implementation processes of the functions and actions of the creating module, the first determining module, the extracting module, the second determining module, the verifying module and the first processing module in the apparatus for preventing dynamic link library file hijacking are specifically described in the implementation processes corresponding to steps S1-S6 in the method for preventing dynamic link library file hijacking, and are not described herein again.
Further, in an embodiment of the present application, the apparatus for preventing dynamic link library file hijacking includes:
the receiving module is used for receiving the appointed names which are respectively corresponding to the appointed DLL files and input by a user;
the input module is used for inputting all the specified names into a pre-created first list;
and the encryption module is used for encrypting the first list to obtain the white list.
In this embodiment, the implementation processes of the functions and actions of the receiving module, the input module, and the encryption module in the apparatus for preventing dynamic link library file hijacking are specifically described in the implementation processes corresponding to steps S400 to S402 in the method for preventing dynamic link library file hijacking, and are not described herein again.
Further, in an embodiment of the present application, the verification module includes:
the first obtaining unit is used for obtaining a resource source of the first DLL file and judging whether the first DLL file is a resource issued by a third party;
the first judging unit is used for judging whether the first DLL file contains a corresponding agency signature certificate or not if the first DLL file is a resource issued by a third party;
a second obtaining unit, configured to obtain a certificate revocation list of a latest version of a certificate authority corresponding to the authority signature certificate if the first DLL file includes the authority signature certificate;
a second determination unit, configured to determine whether the certificate revocation list includes the authority signature certificate;
a first determination unit, configured to determine that the first DLL file passes verification if the certificate revocation list does not include the first certificate;
and the second judging unit is used for judging that the first DLL file is not verified if the certificate revocation list contains the first certificate.
In this embodiment, the implementation processes of the functions and actions of the first obtaining unit, the first determining unit, the second obtaining unit, the second determining unit, the first determining unit and the second determining unit included in the check module of the apparatus for preventing dynamic link library file hijacking are specifically described in the implementation processes corresponding to steps S500 to S505 in the method for preventing dynamic link library file hijacking, and are not described herein again.
Further, in an embodiment of the present application, the verification module includes:
the extracting unit is used for extracting a first digital signature of the first DLL file if the first DLL file is not a resource issued by a third party;
the calling unit is used for calling a public key prestored in the driver to decrypt the first digital signature to obtain a first hash value;
the calculation unit is used for carrying out hash calculation on the text content of the first DLL file to obtain a second hash value;
a third judging unit, configured to judge whether the first hash value is the same as the second hash value;
a third determination unit, configured to determine that the first DLL file passes verification if the first hash value is the same as the second hash value;
and the fourth judging unit is used for judging that the first DLL file does not pass the verification if the first hash value is different from the second hash value.
In this embodiment, the implementation processes of the functions and actions of the extracting unit, the calling unit, the calculating unit, the third determining unit and the fourth determining unit included in the checking module of the apparatus for preventing dynamic link library file hijacking are specifically described in the implementation processes corresponding to steps S506 to S511 in the method for preventing dynamic link library file hijacking, and are not described herein again.
Further, in an embodiment of the present application, an apparatus for preventing dynamic link library file hijacking includes:
the running module is used for running the application program;
the evaluation module is used for acquiring running data generated by the application program in the running process and evaluating the running data according to a second preset rule to obtain a corresponding evaluation result, wherein the evaluation result comprises that the driver is compatible with the application program or the driver is incompatible with the application program;
and the second processing module is used for carrying out corresponding processing on the drive or the application program according to the evaluation result.
In this embodiment, the implementation processes of the functions and actions of the operation module, the evaluation module and the second processing module in the apparatus for preventing dynamic link library file hijacking are specifically described in the implementation processes corresponding to steps S600 to S602 in the method for preventing dynamic link library file hijacking, and are not described herein again.
Further, in an embodiment of the present application, the operation data includes an operation log, and the evaluation module includes:
a third obtaining unit, configured to obtain an operation log generated in an operation process of the application program;
the fourth judging unit is used for judging whether the running log has error data and/or abnormal data;
a fifth determining unit, configured to determine that the driver is incompatible with the application program if the driver is not compatible with the application program;
and a sixth judging unit, configured to judge that the driver is compatible with the application program if not.
In this embodiment, the evaluation module included in the apparatus for preventing dynamic link library file hijacking
The implementation processes of the functions and actions of the third obtaining unit, the fourth determining unit, the fifth determining unit and the sixth determining unit are specifically described in the implementation processes corresponding to steps S6010-S6013 in the above method for preventing dynamic link library file hijacking, and are not described herein again.
Further, in an embodiment of the present application, the running data includes a process marker of a running process, and the evaluation module includes:
a fourth obtaining unit, configured to obtain PIDs (process identifiers) of all running processes corresponding to the application;
a fifth judging unit, configured to judge whether a PID of a specified running process changes within a first preset time period, where the specified running process is one or more running processes among all the running processes;
a seventh determining unit, configured to determine that the driver is incompatible with the application program if the driver is not compatible with the application program;
an eighth determining unit, configured to determine that the driver is compatible with the application program if not.
In this embodiment, the implementation processes of the functions and actions of the fourth obtaining unit, the fifth determining unit, the seventh determining unit and the eighth determining unit included in the evaluating module in the apparatus for preventing hijacking of a dynamic link library file are specifically described in the implementation processes corresponding to steps S6014-S6017 in the method for preventing hijacking of a dynamic link library file, and are not described herein again.
Referring to fig. 3, a computer device, which may be a server and whose internal structure may be as shown in fig. 3, is also provided in the embodiment of the present application. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is designed to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile 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 an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for copying the data such as the request and the white list. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement the method for preventing hijacking of a dynamic link library file as shown in any of the above exemplary embodiments.
The processor executes the steps of the method for preventing the file hijacking of the dynamic link library:
before the application program is started for the first time, creating a driver corresponding to the application program;
judging whether a copy request sent by an external first DLL file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request;
if the copy request is received, extracting a first name of the first DLL file from the copy request;
reading a preset white list through the driver, and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list;
if the first name exists in the white list, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result;
and correspondingly processing the copy request according to the verification result.
Those skilled in the art will appreciate that the structure shown in fig. 3 is only a block diagram of a part of the structure related to the present application, and does not constitute a limitation to the apparatus and the computer device to which the present application is applied.
An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, which, when executed by one or more processors, causes the one or more processors to implement the steps in the above-mentioned method embodiment for preventing hijacking of a dynamic link library file.
When executed by a processor, a computer program realizes a method for preventing dynamic link library files from being hijacked, and specifically comprises the following steps:
before the application program is started for the first time, creating a driver corresponding to the application program;
judging whether a copy request sent by an external first DLL file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request;
if the copy request is received, extracting a first name of the first DLL file from the copy request;
reading a preset white list through the driver, and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list;
if the first name exists in the white list, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result;
and correspondingly processing the copy request according to the verification result.
To sum up, according to the method, the apparatus, and the computer device for preventing hijacking of a dynamic link library file provided in the embodiment of the present application, before the application is started for the first time, a driver corresponding to the application is created; judging whether a copy request sent by an external first DLL file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request; if the copy request is received, extracting a first name of the first DLL file from the copy request; reading a preset white list through the driver, and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list; if the first name exists in the white list, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result; and correspondingly processing the copy request according to the verification result. According to the method and the device, the first DLL file is checked and signed only when the first DLL file exists in the white list, so that the DLL file which is not in the white list does not need to be checked and signed, the processing efficiency of the copy request is effectively improved, and the processing flow of checking and signing is simplified. And only after the first DLL file passes the verification signature, the copy request is allowed to be processed, so that the condition that the DLL file in the application program is hijacked is effectively prevented, and the safety and stability of the application program are improved. In addition, the verification and signature processing of the first DLL file is performed by a driver, namely, the verification and signature processing is completed before the application program is started, so that the verification and signature of each internal DLL file during the starting of the application program are not needed, and the starting rate of the application program is effectively improved.
It will be understood by those skilled in the art that all or part of the processes of the methods of the above embodiments may be implemented by hardware associated with instructions of a computer program, which may be stored on a non-volatile computer-readable storage medium, and when executed, may include processes of the above embodiments of the methods. Any reference to memory, storage, database, or other medium provided herein and used in the examples may include non-volatile and/or volatile memory. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), double-rate SDRAM (SSRSDRAM), Enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, apparatus, article, or method. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, apparatus, article, or method that includes the element.
The above description is only a preferred embodiment of the present application, and not intended to limit the scope of the present application, and all modifications of equivalent structures and equivalent processes, which are made by the contents of the specification and the drawings of the present application, or which are directly or indirectly applied to other related technical fields, are also included in the scope of the present application.
Claims (10)
1. A method for preventing dynamic link library file hijacking is characterized by comprising the following steps:
before the application program is started for the first time, creating a driver corresponding to the application program;
judging whether a copy request sent by an external first DLL file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request;
if the copy request is received, extracting a first name of the first DLL file from the copy request;
reading a preset white list through the driver, and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list;
if the first name exists in the white list, verifying and signing the first DLL file according to a first preset rule to obtain a corresponding verification result;
and correspondingly processing the copy request according to the verification result.
2. The method as claimed in claim 1, wherein the step of reading a preset white list by the driver and determining whether the first name exists in the white list comprises:
receiving appointed names which are input by a user and respectively correspond to a plurality of appointed DLL files;
inputting all the specified names into a pre-created first list;
and encrypting the first list to obtain the white list.
3. The method for preventing hijacking of a dynamic link library file as claimed in claim 1, wherein said step of verifying said first DLL file according to a first preset rule to obtain a verification result comprises:
acquiring a resource source of the first DLL file, and judging 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, judging whether the first DLL file contains a corresponding agency signature certificate;
if the first DLL file contains the authority signature certificate, acquiring a certificate revocation list of the latest version of the certification authority corresponding to the authority signature certificate;
judging whether the certificate revocation list contains the agency signature certificate or not;
if the certificate revocation list does not contain the first certificate, determining that the first DLL file passes verification;
if the first certificate is contained in the certificate revocation list, the first DLL file is determined not to be verified.
4. The method for preventing hijacking of a dynamic link library file as claimed in claim 3, wherein said step of obtaining a resource source of said first DLL file and determining whether said first DLL file is a resource published by a third party, comprises:
if the first DLL file is not a resource released by a third party, extracting a first digital signature of the first DLL file;
calling a public key prestored in the driver to decrypt the first digital signature to obtain a first hash value;
performing hash calculation on the text 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, judging that the first DLL file passes the verification;
and if the first hash value is different from the second hash value, judging that the first DLL file does not pass the verification.
5. The method for preventing hijacking of files in a dynamic link library according to claim 1, wherein said step of performing corresponding processing to said copy request according to said checking result comprises:
running the application program;
acquiring running data generated by the application program in the running process, and evaluating the running data according to a second preset rule to obtain a corresponding evaluation result, wherein the evaluation result comprises that the driver is compatible with the application program or that the driver is incompatible with the application program;
and correspondingly processing the drive or the application program according to the evaluation result.
6. The method for preventing hijacking of files in a dynamic link library according to claim 5, wherein the running data includes a running log, the step of obtaining the running data generated by the application program in the running process and evaluating the running data according to a second preset rule to obtain a corresponding evaluation result comprises:
acquiring an operation log generated in the operation process of the application program;
judging whether the running log has error data and/or abnormal data or not;
if yes, judging that the driver is not compatible with the application program;
and if not, judging that the driver is compatible with the application program.
7. The method for preventing hijacking of files in a dynamic link library according to claim 5, wherein the running data includes a process marker of a running process, and the step of obtaining the running data generated by the application program in the running process and evaluating the running data according to a second preset rule to obtain a corresponding evaluation result comprises:
acquiring the PID of all running processes corresponding to the application program;
judging whether the PID of a designated running process changes within a first preset time period, wherein the designated running process is one or more running processes in all the running processes;
if yes, judging that the driver is not compatible with the application program;
and if not, judging that the driver is compatible with the application program.
8. An apparatus for preventing hijacking of dynamically linked library files, comprising:
the creating module is used for creating a driver corresponding to the application program before the application program is started for the first time;
the first judging module is used for judging whether a copy request sent by an external first DLL file to a specified directory of the application program is received, wherein the copy request is in the form of an I/O request;
the extracting module is used for extracting the first name of the first DLL file if the copying request is received;
the second judgment module is used for reading a preset white list through the driver and judging whether the first name exists in the white list or not, wherein a plurality of specified names are stored in the white list;
the verification module is used for verifying and signing the first DLL file according to a first preset rule if the first name exists in the white list, and obtaining a corresponding verification result;
and the first processing module is used for carrying out corresponding processing on the copy request according to the verification result.
9. A computer device comprising a memory and a processor, the memory having stored therein a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method according to any one of claims 1 to 7.
10. A storage medium having a computer program stored thereon, the computer program, when being executed by a processor, realizing the steps of the method of any one of claims 1 to 7.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910817923.9A CN110688661A (en) | 2019-08-30 | 2019-08-30 | Method and device for preventing dynamic link library file hijacking and computer equipment |
| PCT/CN2020/088014 WO2021036322A1 (en) | 2019-08-30 | 2020-04-30 | Method and apparatus for preventing dynamic link library file hijacking, and computer device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910817923.9A CN110688661A (en) | 2019-08-30 | 2019-08-30 | Method and device for preventing dynamic link library file hijacking and computer equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110688661A true CN110688661A (en) | 2020-01-14 |
Family
ID=69107719
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910817923.9A Pending CN110688661A (en) | 2019-08-30 | 2019-08-30 | Method and device for preventing dynamic link library file hijacking and computer equipment |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN110688661A (en) |
| WO (1) | WO2021036322A1 (en) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110928609A (en) * | 2020-01-20 | 2020-03-27 | 武汉斗鱼鱼乐网络科技有限公司 | Method, device and medium for marking equipment and computer equipment |
| CN111159707A (en) * | 2020-04-07 | 2020-05-15 | 北京安博通科技股份有限公司 | Malicious DLL injection detection method and device |
| CN111368299A (en) * | 2020-03-02 | 2020-07-03 | 西安四叶草信息技术有限公司 | Dynamic link library file hijacking detection method, device and storage medium |
| CN112257058A (en) * | 2020-10-12 | 2021-01-22 | 麒麟软件有限公司 | Trusted computing verification method and system for operating system |
| WO2021036322A1 (en) * | 2019-08-30 | 2021-03-04 | 深圳壹账通智能科技有限公司 | Method and apparatus for preventing dynamic link library file hijacking, and computer device |
| CN112637146A (en) * | 2020-12-09 | 2021-04-09 | 恒生电子股份有限公司 | Method and device for preventing injection, electronic equipment and computer readable storage medium |
| CN113760393A (en) * | 2021-09-22 | 2021-12-07 | 杭州安恒信息技术股份有限公司 | Protection method, device, equipment and medium for dynamic link library |
| CN115118516A (en) * | 2022-07-18 | 2022-09-27 | 浪潮卓数大数据产业发展有限公司 | Method, system and medium for integrated resource management |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102855274B (en) * | 2012-07-17 | 2015-12-09 | 北京奇虎科技有限公司 | The method and apparatus that a kind of suspicious process detects |
| CN103778375B (en) * | 2012-10-24 | 2017-11-17 | 腾讯科技（深圳）有限公司 | The apparatus and method for preventing user equipment from loading illegal dynamic link library file |
| US11416603B2 (en) * | 2018-11-16 | 2022-08-16 | Intel Corporation | Methods, systems, articles of manufacture and apparatus to detect process hijacking |
| CN110688661A (en) * | 2019-08-30 | 2020-01-14 | 深圳壹账通智能科技有限公司 | Method and device for preventing dynamic link library file hijacking and computer equipment |
-
2019
- 2019-08-30 CN CN201910817923.9A patent/CN110688661A/en active Pending
-
2020
- 2020-04-30 WO PCT/CN2020/088014 patent/WO2021036322A1/en active Application Filing
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021036322A1 (en) * | 2019-08-30 | 2021-03-04 | 深圳壹账通智能科技有限公司 | Method and apparatus for preventing dynamic link library file hijacking, and computer device |
| CN110928609A (en) * | 2020-01-20 | 2020-03-27 | 武汉斗鱼鱼乐网络科技有限公司 | Method, device and medium for marking equipment and computer equipment |
| CN110928609B (en) * | 2020-01-20 | 2020-06-16 | 武汉斗鱼鱼乐网络科技有限公司 | Method, device and medium for marking equipment and computer equipment |
| CN111368299A (en) * | 2020-03-02 | 2020-07-03 | 西安四叶草信息技术有限公司 | Dynamic link library file hijacking detection method, device and storage medium |
| CN111159707A (en) * | 2020-04-07 | 2020-05-15 | 北京安博通科技股份有限公司 | Malicious DLL injection detection method and device |
| CN112257058A (en) * | 2020-10-12 | 2021-01-22 | 麒麟软件有限公司 | Trusted computing verification method and system for operating system |
| CN112637146A (en) * | 2020-12-09 | 2021-04-09 | 恒生电子股份有限公司 | Method and device for preventing injection, electronic equipment and computer readable storage medium |
| CN113760393A (en) * | 2021-09-22 | 2021-12-07 | 杭州安恒信息技术股份有限公司 | Protection method, device, equipment and medium for dynamic link library |
| CN115118516A (en) * | 2022-07-18 | 2022-09-27 | 浪潮卓数大数据产业发展有限公司 | Method, system and medium for integrated resource management |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021036322A1 (en) | 2021-03-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110688661A (en) | Method and device for preventing dynamic link library file hijacking and computer equipment | |
| EP2863303B1 (en) | Method for confirming correction program, confirming program for confirming correction program, and information processing apparatus | |
| US8443354B1 (en) | Detecting new or modified portions of code | |
| US8375458B2 (en) | System and method for authenticating code executing on computer system | |
| EP1998269A1 (en) | Program execution control system, execution control method, execution control computer program | |
| CN113646761A (en) | Providing application security, authentication and feature analysis to applications | |
| JP4844102B2 (en) | Subprogram and information processing apparatus for executing the subprogram | |
| KR100693919B1 (en) | Confirmation method of software and apparatus for executing software | |
| CN110224855B (en) | Registration method and device of micro service instance, computer equipment and storage medium | |
| JP2005182789A (en) | Method and system for ensuring that software update may be installed or run only on specific device or class of devices | |
| EP1262859A2 (en) | Information processing apparatus and method for executing software input from outside | |
| CN113541966A (en) | Authority management method, device, electronic equipment and storage medium | |
| RU2357287C2 (en) | Safe identification of executable file for logical object determining confidence | |
| US11392693B2 (en) | Validity confirmation equipment | |
| CN116956240A (en) | Bypass Google safe net authentication method and related components | |
| CN116707758A (en) | Authentication method, equipment and server of trusted computing equipment | |
| CN112364340B (en) | Authority management method, device, equipment and computer readable storage medium | |
| EP3889814B1 (en) | Update device and update method | |
| US20230114009A1 (en) | Information Processing Apparatus and Program Starting Method | |
| CN111492617B (en) | Method and verification device for verifying digital certificates | |
| JP2009116391A (en) | Security policy setting device cooperating with safety level evaluation and a program and method thereof | |
| JP2018005613A (en) | Update method, program, information processing apparatus, and update data generation apparatus | |
| CN117527439A (en) | Digital certificate verification method, device, equipment and medium based on embedded certificate | |
| CN114721693A (en) | Microprocessor, BIOS firmware updating method, computer equipment and storage medium | |
| CN115982698A (en) | Data security detection method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |