Virus interception method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a virus interception method and device, electronic equipment and a storage medium. The method comprises the steps of starting a target drive program in an operating system in response to a starting instruction of the operating system; acquiring a rule set by the target driver, wherein the rule set comprises a plurality of virus rules; in the process of loading the starting drive program, obtaining first program information of the starting drive program by the target drive program; the target driving program performs virus identification on the starting driving program based on the first program information of the starting driving program and the rule set to obtain a virus identification result; and if the virus identification result indicates that the starting drive program is the virus, intercepting the starting drive program. By the adoption of the method, virus detection can be carried out before the starting drive program is started, interception is carried out when it is detected and confirmed that the starting drive program is the virus program, and therefore the safety of an operating system is improved.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and more specifically, to a virus interception method, apparatus, electronic device, and storage medium. Background Art

[0002] As anti-virus software becomes more powerful in combating malicious virus software, virus software makers are increasingly inclined to create viruses that can hide themselves to bypass anti-virus software detection, such as Rootkit viruses. Specifically, Rootkit viruses usually have strong resistance, and their startup sequence is usually relatively high. After startup, Rootkit viruses usually use registered file filtering and registry filtering to hide themselves and prevent anti-virus software from detecting and killing them. Moreover, after startup, Rootkit viruses usually record the accounts and passwords of different applications or web pages, etc. Once the recorded accounts and passwords are maliciously used, it will cause immeasurable losses to users. Summary of the Invention

[0003] In view of this, embodiments of the present application propose a virus interception method, apparatus, electronic device, and storage medium, which can intercept before a virus program starts, avoid the leakage of account passwords of applications or web pages, etc. caused by the virus program, and thus improve the security of the operating system.

[0004] In a first aspect, an embodiment of the present application provides a virus interception method, the method including: starting a target driver in the operating system in response to a startup instruction of the operating system; obtaining a rule set by the target driver, the rule set including multiple virus rules; obtaining first program information of the startup driver by the target driver during the process of loading and starting the driver; performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result; and intercepting the startup driver if the virus identification result indicates that the startup driver is a virus.

[0005] Second aspect, embodiments of the present application provide a virus interception device, which includes: a program startup module, a rule set acquisition module, a program information acquisition module, a virus recognition module, and a program interception module. The program startup module is configured to start a target driver in the operating system in response to a startup instruction of the operating system; the rule set acquisition module is configured to acquire a rule set by using the target driver, and the rule set includes multiple virus rules; the program information acquisition module is configured to acquire first program information of the startup driver from the target driver during the process of loading and starting the driver; the virus recognition module is configured to perform virus recognition on the startup driver by using the target driver based on the first program information of the startup driver and the rule set to obtain a virus recognition result; the program interception module is configured to intercept the startup driver when the virus recognition result indicates that the startup driver is a virus.

[0006] In an implementable manner, the first program information of the startup driver includes the program registry path, program file path, and program certificate hash of the startup driver; the virus recognition module is further configured to use the target driver to respectively match the registry path, program file path, and program certificate hash of the startup driver with the virus rules in the rule set; if there is at least one virus rule in the rule set that matches the program registry path, program file path, and program certificate hash, determine that the virus recognition result is a recognition result indicating that the startup driver is a virus; if there is no virus rule in the rule set that matches each of the program registry path, program file path, and program certificate hash, determine that the virus recognition result is a recognition result indicating that the startup driver is not a virus.

[0007] In an implementable manner, the device further includes a public key acquisition module and a signature verification module. The public key acquisition module is configured to acquire a public key for verifying the signature information of the rule set by using the target driver; the signature verification module is configured to use the target driver to verify the signature information by using the public key to obtain a signature verification result; the virus recognition module is further configured to, when the signature verification result indicates that the verification passes, perform virus recognition on the startup driver by using the target driver based on the first program information of the startup driver and the rule set to obtain a virus recognition result.

[0008] In an implementable manner, the device further includes a program startup module. The virus recognition module is further configured to, when the type of the startup driver is a non-dependent driver type, use the target driver to perform virus recognition on the startup driver based on the first program information of the startup driver and the rule set, so as to obtain a virus recognition result; wherein, a startup driver belonging to the non-dependent driver type needs to depend on other drivers to start; the program startup module is further configured to, when the type of the startup driver is a dependent driver type, or the virus recognition result of the startup driver belonging to the non-dependent driver type indicates that the startup driver is not a virus, start the startup driver; wherein, a driver belonging to the dependent driver type does not need to depend on other drivers to start

[0009] In an implementable manner, the device further includes a function registration module, an information writing module, a program scanning module, an exception recognition module, and a prompt information generation module. The function registration module is used to register a boot callback function; the information writing module is used to, when the operating system starts successfully, call the boot callback function to write the first program information of the startup driver into a target file; the program scanning module is used to perform a driver scan using a target application program at the application layer to obtain second program information of the started startup driver; the exception recognition module is used to perform exception recognition on the started startup driver according to the first program information of the started startup driver read from the target file and the second program information of the started startup driver, so as to obtain an exception recognition result; the prompt information generation module is used to generate an exception prompt information when the exception recognition result indicates that the started startup driver is abnormal

[0010] In an implementable manner, the first program information includes a program registry path, a program file path, and a program certificate hash, and the second program information includes a reference registry path, a reference file path, and a reference certificate hash; the exception recognition module is further configured to, if it is determined that the started startup driver meets a first condition according to the first program information of the started startup driver read from the target file and the second program information of the started startup driver, determine that the exception recognition result is an identification result indicating that the started startup driver is abnormal; wherein, the first condition includes at least one of the following: the program registry path of the started startup driver is inconsistent with the reference registry path, the program file path of the started startup driver is inconsistent with the reference file path, the program certificate hash of the started startup driver is inconsistent with the reference certificate hash, and the driver file obtained according to the program file path of the started startup driver is inconsistent with the driver file obtained according to the reference file path

[0011] In an implementable manner, the program information acquisition module is further configured to register a program callback function for the startup driver to be loaded; during the process of loading the startup driver, the target driver calls the program callback function to obtain the first program information of the startup driver.

[0012] In an implementable manner, the rule set acquisition module includes a reading sub-module and a rule set acquisition sub-module. The reading sub-module is configured to read the value of the abnormal startup flag bit in the registry of the operating system when the target driver confirms that the startup mode of the operating system is the preset startup mode; the rule set acquisition sub-module is configured to, when the value of the abnormal startup flag bit indicates a preset value, the target driver obtains the rule set pre-stored in the registry of the operating system; the preset value represents that no abnormal startup has occurred.

[0013] In an implementable manner, the device further includes: an accumulation module, a restart module, and a program startup module. The accumulation module is configured to, when the value of the abnormal startup flag bit is the preset value, accumulate the value of the abnormal startup flag bit in the registry based on a specified value, and store the update time of the value of the abnormal startup flag bit; the restart module is configured to restart the operating system when the operating system fails to start; the reading sub-module is further configured to, during the restart process of the operating system, re-read the value of the abnormal startup flag bit in the registry of the operating system; the accumulation module is further configured to, when it is determined according to the re-read value of the abnormal startup flag bit that the restart count of the operating system has not reached the preset count and the duration between the stored update time is greater than the preset duration, accumulate the value of the abnormal startup flag bit in the registry based on a specified value, and store the update time of the value of the abnormal startup flag bit; the program startup module is configured to, when it is determined according to the re-read value of the abnormal startup flag bit that the restart count of the operating system has not reached the preset count, determine that the duration between the stored update time does not exceed the preset duration, or, when it is determined according to the re-read value of the abnormal startup flag bit that the restart count of the operating system has reached the preset count, start the startup driver.

[0014] In an implementable manner, the device further includes a reset module, configured to reset the value of the abnormal startup flag bit in the registry to the preset value when the operating system starts successfully.

[0015] In a third aspect, an embodiment of the present application provides an electronic device, including a processor and a memory; one or more programs are stored in the memory and configured to be executed by the processor to implement the above method.

[0016] Fourthly, an embodiment of the present application provides a computer-readable storage medium, in which program code is stored. When the program code is run by a processor, the above-mentioned method is executed.

[0017] Fifthly, an embodiment of the present application provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device obtains the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned method.

[0018] A virus interception method, device, electronic device and storage medium provided by an embodiment of the present application. The method includes: starting a target driver in an operating system in response to a startup instruction of the operating system; obtaining a rule set by the target driver, the rule set including multiple virus rules; during the process of loading and starting the driver, obtaining first program information of the startup driver by the target driver; performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result; if the virus identification result indicates that the startup driver is a virus, intercept the startup driver. By adopting the above method, since the target driver is loaded by the operating system before other startup drivers, the target driver can perform virus detection before the startup driver starts and intercept it when it is detected and confirmed to be a virus program, ensuring that account passwords in application programs or web pages will not be recorded by virus programs, thereby effectively improving the security of the operating system. Description of the Drawings

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those skilled in the art, without creative efforts, other drawings can be obtained according to these drawings.

[0020] Figure 1 Shows a schematic flowchart of a virus interception method provided by an embodiment of the present application;

[0021] Figure 2 Shows a schematic diagram of a rule set proposed by an embodiment of the present application;

[0022] Figure 3 Shows another schematic flowchart of a virus interception method proposed by an embodiment of the present application;

[0023] Figure 4 Shows yet another schematic flowchart of a virus interception method proposed by an embodiment of the present application;

[0024] Figure 5 Shows a flowchart of a virus interception method proposed in an embodiment of the present application;

[0025] Figure 6 Shows a schematic diagram of the startup sequence of each component in an operating system proposed in an embodiment of the present application;

[0026] Figure 7 Shows another flowchart of a virus interception method provided in an embodiment of the present application;

[0027] Figure 8 Shows yet another flowchart of a virus interception method proposed in an embodiment of the present application;

[0028] Figure 9 Shows a schematic diagram of a virus detection result obtained by using a target application program for virus detection provided in an embodiment of the present application;

[0029] Figure 10 Shows a schematic diagram of another virus detection result obtained by using a target application program for virus detection provided in an embodiment of the present application;

[0030] Figure 11 Shows a schematic diagram of a driver priority table provided in an embodiment of the present application;

[0031] Figure 12 Shows a schematic diagram of yet another virus detection result obtained by using a target application program for virus detection provided in an embodiment of the present application;

[0032] Figure 13 Shows a schematic diagram of yet another virus detection result obtained by using a target application program for virus detection provided in an embodiment of the present application;

[0033] Figure 14 Shows a schematic diagram of yet another virus detection result obtained by using a target application program for virus detection provided in an embodiment of the present application;

[0034] Figure 15 Shows a connection block diagram of a virus interception device proposed in an embodiment of the present application;

[0035] Figure 16 Shows a structural block diagram of an electronic device for executing the method according to an embodiment of the present application. Detailed implementation manners

[0036] Example embodiments will now be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more complete and comprehensive, and will fully convey the concept of the example embodiments to those skilled in the art.

[0037] In addition, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of the embodiments of this application. However, those skilled in the art will realize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, devices, steps, etc. may be used. In other cases, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of this application.

[0038] The block diagrams shown in the drawings are only functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0039] The flowcharts shown in the drawings are only illustrative and do not necessarily include all the content and operations / steps, nor do they necessarily need to be executed in the order described. For example, some operations / steps can be decomposed, while some operations / steps can be combined or partially combined, so the actual execution order may change according to the actual situation.

[0040] It should be noted that: "a plurality of" as mentioned herein means two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after.

[0041] In addition, it should be noted that in the embodiments of this application, the acquisition of the attributes of the subscription node and the distribution node both require the permission or consent of the affiliated user, and the collection, use, processing, and storage of the above attributes need to comply with the regulations of the region where they are located.

[0042] Hereinafter, the terms related to this application will be explained.

[0043] An operating system, (English: Operating System, abbreviation: OS) is a set of interrelated system software programs that manage and control computer operations, utilize and run hardware and software resources, and provide public services to organize user interactions. Among them, the types of operating systems can be, but are not limited to, Windows operating system, Linux operating system, Unix operating system, and Mac operating system, etc.

[0044] Application layer: Also known as User Mode. This is the upper layer of the operating system and where most user-level application programs run. At this level, application programs can access a predefined set of operating system services and perform tasks through the system call interface (API). These tasks usually include file management, device management, memory management, and user interface, etc. At the application layer, program access to hardware is strictly restricted to prevent malicious software or incorrect operations from damaging the system.

[0045] Driver layer: Also known as Kernel Mode. This is the lower layer of the operating system and where core components of the operating system (such as the kernel, device drivers, etc.) run. In kernel mode, code can directly access hardware and memory, which means that code running at this level has higher privileges, and their errors may cause the system to crash and lead to data loss.

[0046] Virus program: The virus programs in this solution include Rootkit viruses. Among them, Rootkit viruses specifically refer to Rootkit drivers. Rootkit viruses run in kernel mode and have extremely high system privileges; due to their early startup time and extremely high system privileges, they have extremely strong resistance and can completely hide themselves and other user-mode application programs to bypass the detection of antivirus software. Usually, Rootkit viruses are part of a set of malicious software. They can record passwords and keystrokes, access a large amount of confidential data and upload private files; or hijack the user's network traffic and maliciously pop up advertisements to generate revenue.

[0047] The startup driver is a type of driver with the highest startup priority in the operating system, such as the Boot driver in the Windows operating system. Among them, the Boot driver is a type of driver with the highest startup priority among the drivers of the Windows operating system. Many system components such as the file system are Boot drivers. Due to the early startup order, the vast majority of Rootkit virus programs in the Windows operating system are Boot drivers.

[0048] Target driver: Among them, the target driver can be any driver that can intercept viruses and can be started before the Boot driver is started. Exemplarily, the target driver can be an ELAM driver, that is, Early Launch Antimalware, an anti-malware program launched at the initial stage of startup. It should be understood that the target driver is a general term for a class of drivers. Its characteristic is that it can be pre-loaded before all drivers and application programs are started. In this embodiment, the target driver mainly completes some inspection, verification, and interception tasks, such as checking whether the startup driver is a Rootkit virus program. If so, the Rootkit virus program is intercepted so that it cannot be started.

[0049] A virus interception method provided by an embodiment of the present application can be used in scenarios for virus detection of electronic devices (such as user terminals or servers, etc.). Among them, if the electronic device is a user terminal, the user terminal includes but is not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. The virus interception method provided by the present application, during the startup process of the operating system, before starting the startup driver, first start the target driver. The target driver obtains a rule set, and the rule set includes multiple virus rules; during the process of loading the startup driver, the target driver obtains the first program information of the startup driver; the target driver performs virus identification on the startup driver based on the first program information of the startup driver and the rule set to obtain a virus identification result; if the virus identification result indicates that the startup driver is a virus, the startup driver is intercepted. By adopting the above method, because the target driver is loaded by the operating system before other startup drivers, the target driver can perform virus detection before the startup driver is started and intercept it when it is detected and confirmed to be a virus program, ensuring that account passwords in application programs or web pages will not be recorded by virus programs, thereby effectively improving the security of the operating system. At the same time, the above method also avoids the situation where virus programs maliciously display advertisements after startup, thereby improving the user experience of using the operating system. In addition, because the target driver is automatically started every time the system starts and the user is unaware during the entire interception process, the above virus interception process will not bring additional operation costs.

[0050] The following will specifically describe each embodiment of the present application with reference to the drawings.

[0051] As Figure 1 shown, an embodiment of the present application provides a virus interception method. This method can be applied to an electronic device, and the specific process of this method is as follows:

[0052] Step S110: Respond to the startup instruction of the operating system to start the anti-malware target driver in the operating system.

[0053] Among them, the startup instruction of the above operating system can be generated in response to the user's power-on operation or restart operation of the electronic device, or can be generated based on a preset rule in the electronic device, such as a timing startup rule, a preset restart rule, etc., and no specific limitation is made here.

[0054] It should be noted that during the startup process of the operating system, the target driver is specifically started in the initial stage of the operating system startup, and the target driver is started before the boot driver. Specifically, if the target startup driver is an anti-malware ELAM driver, the startup type of the ELAM driver is SERVICE_BOOT_START, indicating that the driver is loaded by the loader and starts with the initialization of the kernel.

[0055] Step S120: Obtain a rule set from the target driver, where the rule set includes multiple virus rules.

[0056] Among them, the virus rules stored in the rule set can include, but are not limited to, one or more of a virus registry path, a virus file path, and a virus digital signature (such as a virus certificate hash), etc. Among them, the virus digital signature can include an expired digital signature used by the virus, the virus registry path refers to the registry path used by the virus, and the virus file path refers to the file path used by the virus. The above viruses can include Rootkit viruses, and in addition, can also include Trojan program viruses, backdoor programs, and ransomware viruses, etc.

[0057] Among them, the above rule set can be uploaded by the user in advance, or can be sent down by the target application program in the application layer, such as sent down by the virus scanning program in the application layer and then stored in the kernel or memory of the operating system.

[0058] It should be understood that if the rule set is sent down by the target application program in the application layer, the target application program in the application layer can also update the rule set in the application layer after detecting new virus rules or receiving virus rules input by the user, and send down the updated rule set again.

[0059] In an implementable manner, the rule set is stored in the registry. The registry is an important database in Microsoft Windows, which is used to store system and application setting information, etc. It should be noted that the registry is essentially a database. In this database, all system and application initialization information is integrated; it includes descriptions of hardware devices, associated application programs and document files, window display methods, network connection parameters, and even network sharing settings related to computer security, etc.

[0060] Exemplarily, if the target startup driver is the ELAM driver, and the rule set read by the ELAM driver is stored in the HKLM\ELAM directory of the registry, then the above step S120 may be for the target driver to obtain the rule set in the HKLM\ELAM directory of the registry.

[0061] Step S130: During the process of loading the startup driver, the target driver obtains the first program information of the startup driver.

[0062] Among them, loading the startup driver means loading the executable file and its dependent libraries of the startup driver into memory. The startup driver needs to be loaded first before it can be started. After the startup driver is loaded, it is convenient for the target driver to obtain the first program information of the startup driver.

[0063] The first program information of the startup driver may include, but is not limited to, one or more of the program registry path, program file path, program certificate hash, and program file of the startup driver.

[0064] Among them, the program registry path refers to the value or item of the startup driver in the registry. The program file path refers to the path for locating the program file of the startup driver. The program certificate hash value is the hash value obtained by performing a hash calculation on the key information in the certificate using the digital signature technology of the hash algorithm, and is used to verify the integrity and authenticity of the certificate.

[0065] There are various ways for the target driver to obtain the first program information of the startup driver. Specifically, it can be obtained based on the registry, or the program callback function of the startup driver can be registered to obtain it. It should be understood that the above ways of obtaining the first program information of the startup driver are only illustrative, and there can be more ways of obtaining, which are not specifically limited here.

[0066] If the program callback function of the startup driver is registered to obtain the first program information of the startup driver, then the above step S130 may specifically be: registering the program callback function for the startup driver to be loaded; during the process of loading the startup driver, the target driver calls the program callback function to obtain the first program information of the startup driver.

[0067] Among them, when registering a program callback function, the function prototype of the callback function can be defined first. Specifically, the callback function has a clearly defined function prototype, and the address of the callback function (that is, the address of the program information for starting the driver) needs to be provided during registration. Then, an event handling mechanism is created. The event handling mechanism is responsible for managing the association between all callback functions and events, and calling the corresponding callback function when an event occurs (in this embodiment, the event here refers to loading and starting the driver). Finally, registering the address of the callback function into the event handling mechanism completes the registration of the program callback function.

[0068] Step S140: The target driver performs virus identification on the startup driver based on the first program information of the startup driver and the rule set, and obtains a virus identification result.

[0069] The above virus identification result includes an identification result indicating that the startup driver is a virus program, or an identification result indicating that the startup driver is not a virus program.

[0070] Considering that there are multiple types of information included in the first program information, when there is a piece of information that matches the virus rule, it indicates that the startup driver to which the first program information belongs may be a virus. Therefore, the identification process in step S140 above can specifically be to compare the first program information of the startup driver with the virus rules in the rule set. If there is information in the first program information of the startup driver that is the same as the virus rules in the rule set, a virus identification result indicating that the startup driver is a virus program is obtained. If there is information in the first program information of the startup driver that is the same as the virus rules in the rule set, a virus identification result indicating that the startup driver is not a virus program is obtained.

[0071] In this implementation manner, if the first program information of the startup driver includes the program registry path, program file path, and program certificate hash of the startup driver, step S150 above can specifically be: The target driver matches the registry path, program file path, and program certificate hash of the startup driver with the virus rules in the rule set respectively. If there is a virus rule in the rule set that matches at least one of the program registry path, program file path, and program certificate hash, it is determined that the virus identification result is an identification result indicating that the startup driver is a virus. If there is no virus rule in the rule set that matches each of the program registry path, program file path, and program certificate hash, it is determined that the virus identification result is an identification result indicating that the startup driver is not a virus.

[0072] Step S150: If the virus identification result indicates that the startup driver is a virus, intercept the startup driver.

[0073] The method of intercepting the startup driver may be to modify the entry program code (entry function) of the startup driver so that it cannot be started. It may also be to adjust the permissions of the startup driver so that it cannot be started. It should be understood that the above interception methods are only illustrative, and there may be more interception methods, which will not be described one by one here.

[0074] It should be understood that if the virus identification result indicates that the startup driver program is not a virus program, the startup driver program is started.

[0075] It should be noted that if there are multiple startup driver programs, the virus detection process for each startup driver program can be performed according to the aforementioned steps S130 - S150 .

[0076] By adopting the above-mentioned virus interception method, it is possible to identify the loaded startup driver program according to the virus rules in the existing rule set at the initial stage of program startup, and intercept the startup driver program when the startup driver program is identified as a virus program, thereby intercepting the virus program at the startup stage of the operating system, preventing the startup driver program from starting, thereby avoiding information leakage or malicious advertising caused by the virus program after it is started, and achieving the purpose of improving the security of the operating system application process and the user experience in the process of using the operating system.

[0077] Considering that when the rule set is stored in the registry directory, the operating system or target driver cannot directly read and write the rule set for self-protection. This may cause the rule set to be tampered with by third-party software, resulting in any startup driver being blocked, leading to adverse consequences.

[0078] Therefore, in order to ensure the accuracy of the virus rules obtained from the rule set and avoid the virus rules in the rule set being maliciously tampered with, which causes the startup driver to be mistakenly identified as a virus program, before obtaining the rule set, the rule set should be verified, and if the verification result indicates that the rule set has not been maliciously tampered with, the subsequent steps are executed. Specifically, in one possible implementation of the present application, the above step S140 may include:

[0079] Step S140a: The target driver obtains a public key for verifying the signature information of the rule set.

[0080] Among them, the public key can be stored at a specified address or in a file, or encoded in specified program code, such as program code in the kernel or driver code of the target driver. It can be set according to actual needs. Exemplarily, if the public key is encoded in the driver code of the target driver, the above step S140a may be to obtain the public key for verifying the signature information of the rule set from the driver code of the target driver.

[0081] Step S140b: The target driver uses the public key to verify the signature information to obtain a verification result.

[0082] Among them, the verification result is used to indicate that the verification passes or fails.

[0083] Step S140c: If the verification result indicates that the verification passes, the target driver performs virus identification on the startup driver based on the first program information for starting the driver and the rule set to obtain a virus identification result.

[0084] In an exemplary application, the above rule set is sent from the application layer and stored in the directory of the registry. Therefore, before sending it, the application layer can sign and encrypt each virus rule in the rule set, so that before obtaining the rule set, the steps such as S140a - 140c described above can be executed, so as to realize prior signature and decryption of the rule set. When the signature and decryption are successful, the virus rules in the rule set are obtained to execute the above virus detection and interception steps. Among them, the algorithms for the above signature and encryption can use the RSA encryption algorithm. Before the application layer sends the rule set, first calculate its SHA256 hash value, and then use the RSA private key to perform signature calculation on this hash value, and store the obtained signature information in the rule set. And the public key corresponding to the signature private key used for signature calculation is hard - coded in the driver code of the target driver, so that when the target driver performs verification, it first uses the CNG cryptographic primitive function provided by Microsoft (CNG, Cryptography Next Generation, next - generation encryption technology) to obtain the public key, and then uses this public key to verify the signature information. If the verification passes, the subsequent virus identification operation is performed.

[0085] As Figure 2 shown, it shows a schematic diagram of a rule set including multiple virus rules and the signature information obtained by signing multiple virus rules using the RSA encryption algorithm. Among them, the multiple virus rules include virus rule 1, virus rule 2, etc. The type of each virus rule can be any one of registry path, file path, certificate hash, etc. Figure 2 shows that the type of the virus rule is certificate hash, and the virus rule specifically includes rule data length, certificate hash, trust level, hash value, etc.

[0086] By adopting the above S140a - S140c, malicious tampering of the rule set can be avoided, thereby ensuring the accuracy of the virus rules included in the rule set, and further ensuring the accuracy of the virus recognition results obtained by subsequently performing virus recognition on the startup driver based on the virus rules in the rule set.

[0087] Furthermore, considering that for a dependent startup driver, since other startup drivers (non - dependent startup drivers) need to be started depending on the startup of this dependent startup driver, if such a startup driver (dependent startup driver) is intercepted, it may cause the operating system to fail to start. Therefore, the above step S140 can be: if the type of the startup driver is a non - dependent driver type, the target driver performs virus recognition on the startup driver based on the first program information of the startup driver and the rule set to obtain a virus recognition result; among them, the startup driver belonging to the non - dependent driver type needs to depend on the startup of other drivers.

[0088] The method further includes: if the type of the startup driver is a dependent driver type, or the virus recognition result of the startup driver belonging to the non - dependent driver type indicates that the startup driver is not a virus, start the startup driver; among them, the driver belonging to the dependent driver type does not need to depend on other drivers to start.

[0089] By adopting the above process, on the basis of ensuring that the operating system can start normally, the security performance after the operating system starts can be effectively improved.

[0090] Please refer to Figure 3 , in an implementable manner, to enable the operating system to also identify and locate possible abnormal programs during the usage stage after booting, the method further includes:

[0091] Step S160: Register a boot callback function.

[0092] Among them, the boot callback function refers to the callback function executed by the operating system after the boot is completed.

[0093] When registering the boot callback function, the function prototype of the callback function can be defined first: the callback function should have a clearly defined function prototype, and the address of the callback function needs to be provided during registration. Then, create an event handling mechanism: the event handling mechanism is responsible for managing the association between all callback functions and events, and calls the corresponding callback function when an event occurs (in this embodiment, the event here refers to the successful startup of the operating system). Finally, register the address of the callback function into the event handling mechanism to achieve the registration of the boot callback function.

[0094] Step S170: If the operating system starts successfully, call the boot callback function to write the first program information of the startup driver into the target file.

[0095] Among them, the target file can be any file that can be read by a program in the application layer, and no specific limitation is made here, and it can be set according to actual needs.

[0096] Step S180: The target application program in the application layer scans the startup driver to obtain the second program information of the started startup driver.

[0097] Among them, the target application program in the application layer can be any application program that can scan the startup driver, such as: a virus killing program or a virus detection program, etc. The started startup driver can refer to the startup driver started during the operating system startup phase, or it can also refer to the startup driver started in the application layer. In this embodiment, the started startup driver refers to the startup driver started during the operating system startup phase.

[0098] Step S190: Based on the first program information of the started startup driver read from the target file and the second program information of the started startup driver, perform anomaly identification on the started startup driver to obtain an anomaly identification result.

[0099] Among them, at least part of the information categories included in the first program information are the same as the information categories included in the second program information. For example, the first program information may include one or more of a program registry path, a program file path, and a program certificate hash, etc., and the second program information may also include one or more of a reference registry path, a reference file path, and a reference certificate hash, etc.

[0100] When performing anomaly identification on the started startup driver based on the first program information and the second program information, the information of the same type in the first program information and the second program information of the startup driver can be compared, or the files obtained based on the information of the same type can be compared to obtain an anomaly identification result. Among them, when the comparison results are consistent, the anomaly identification result is that there is no anomaly; if the comparison results are inconsistent, the anomaly identification result is that there is an anomaly.

[0101] Exemplarily, if the first program information includes a program registry path, a program file path, and a program certificate hash, and the second program information includes a reference registry path, a reference file path, and a reference certificate hash, then the above step S190 may be: If it is determined, based on the first program information of the started startup driver read from the target file and the second program information of the started startup driver, that the started startup driver meets the first condition, determine that the abnormal recognition result is a recognition result indicating that the started startup driver is abnormal.

[0102] Wherein, the first condition includes at least one of the following:

[0103] The program registry path of the started startup driver is inconsistent with the reference registry path, the program file path of the started startup driver is inconsistent with the reference file path, the program certificate hash of the started startup driver is inconsistent with the reference certificate hash, and the driver file obtained according to the program file path of the started startup driver is inconsistent with the driver file obtained according to the reference file path.

[0104] It should be noted that when the program registry path of the startup driver is inconsistent with the reference registry path, the program file path of the started startup driver is inconsistent with the reference file path, the program certificate hash of the started startup driver is inconsistent with the reference certificate hash, or the driver file obtained according to the program file path of the started startup driver is inconsistent with the driver file obtained according to the reference file path, it indicates that after the startup driver is started, it may have been disguised by a Rootkit virus during startup, resulting in the second program information of the startup driver obtained by the target application program at the application layer being different from the first program information of the startup driver.

[0105] Step S200: If the abnormal recognition result indicates that the started startup driver is abnormal, generate an abnormal prompt message.

[0106] Among them, the first program information and the second program information can be carried in the exception prompt message. By carrying the first program information and the second program information in the exception prompt message, the management personnel can detect and determine whether the startup driver program is a virus program according to the first program information and the second program information. It should be understood that when determining that the startup driver program is a virus program, the management personnel can also write the registry path, file path, certificate hash, etc. including the startup driver program into the rule set through the target application program in the application layer or any application program that can read and write the rule set to update the rule set. The application layer can also distribute the updated rule set so that when the electronic device is started next time, it can intercept virus programs more accurately, thereby further improving the accuracy of virus program interception and the security of the operating system.

[0107] Please refer to Figure 4 As shown, an embodiment of the present application further provides a virus interception method, which can be applied to an electronic device. The method includes:

[0108] Step S210: Respond to the startup instruction of the operating system to start the target driver in the operating system.

[0109] Determine whether the startup mode of the operating system confirmed by the target driver is a preset startup mode; if the target driver confirms that the startup mode of the operating system is other than the secure startup mode, then execute step S220: Read the value of the abnormal startup flag bit in the registry of the operating system.

[0110] Among them, the secure startup mode standard is a security standard developed by members of the terminal device industry to help ensure that the device only starts with software trusted by the original equipment manufacturer. The operating system usually does not load any startup drivers in the secure startup mode.

[0111] Confirm whether the value of the abnormal startup flag bit is a preset value; if the value of the abnormal startup flag bit indicates a preset value, execute step S230: Obtain the rule set pre-stored in the registry of the operating system by the target driver.

[0112] Among them, the preset value represents that no abnormality occurred during the startup process of the operating system. The preset value can be any value such as -1, 0, 1, etc. In an implementable manner, the above abnormality may refer to that the device deploying the operating system has not had a blue screen, that is, the operating system was normally started after the last virus detection and interception.

[0113] Step S240: Accumulate the value of the abnormal startup flag bit in the registry based on the specified value, and store the update time of the value of the abnormal startup flag bit.

[0114] Among them, the above specified value can be -2, -1, 1, 2, etc., as long as the values of the abnormal startup flag bits before and after the update are different. There is no specific limitation in this embodiment, and it can be set according to actual needs.

[0115] Step S250: During the process of loading the startup driver, the target driver obtains the first program information of the startup driver.

[0116] Step S260: The target driver performs virus recognition on the startup driver based on the first program information of the startup driver and the rule set to obtain a virus recognition result.

[0117] Step S270: If the virus recognition result indicates that the startup driver is a virus, intercept the startup driver.

[0118] For the specific descriptions of the above steps S250 - S270, reference can be made to the specific descriptions of steps S130 - S150 above, and there is no specific limitation here.

[0119] Step S280: If the operating system fails to start, restart the operating system.

[0120] Step S290: During the restart process of the operating system, re - read the value of the abnormal startup flag bit in the registry of the operating system.

[0121] At this time, the value of the abnormal startup flag bit read from the registry of the operating system is the value obtained by accumulating the value of the abnormal startup flag bit in the registry based on the specified value in the previous step S240.

[0122] If it is determined according to the re - read value of the abnormal startup flag bit that the restart times of the operating system have not reached the preset times, and the duration between the restart moment and the stored update moment is greater than the preset duration, then return to execute step S230.

[0123] Among them, the above preset times can be, but are not limited to, 3 times, 5 times, 7 times, etc., and can be set according to actual needs. The above preset duration can be 24 hours, 36 hours, 48 hours, 72 hours, etc., and can be set according to actual needs.

[0124] If it is determined that the duration between the restart moment and the stored update moment does not exceed the preset duration when it is determined according to the re - read value of the abnormal startup flag bit that the restart times of the operating system have not reached the preset times, or, if it is determined according to the re - read value of the abnormal startup flag bit that the restart times of the operating system have reached the preset times, then execute step S300: Start the startup driver.

[0125] Considering that frequent restart of the device during the user's use of the electronic device will cause great inconvenience to the user, and the above-mentioned execution steps S250 - S270 may cause the operating system to fail to start normally. Therefore, if it is determined that the number of restarts of the operating system has not reached the preset number according to the value of the abnormally started flag bit read again, and it is determined that the time duration between the current time and the stored update time does not exceed the preset time duration, or if it is determined that the number of restarts of the operating system has reached the preset number according to the value of the abnormally started flag bit read again, then at this time, the foregoing steps S250 - S270 do not need to be executed, but instead directly execute the startup driver program.

[0126] If the operating system starts successfully, then execute the step of resetting the value of the abnormally started flag bit in the registry to the preset value.

[0127] Among them, if the operating system starts successfully, it means that the operating system will not affect the normal startup of the operating system after intercepting the startup driver program identified as a virus program in the above steps S250 - S270. At this time, resetting the value of the abnormally started flag bit in the registry to the preset value can avoid misidentifying the value of the abnormally started flag bit in the registry during the next startup of the operating system.

[0128] It should also be noted that after executing the foregoing step S220, if the value of the abnormally started flag bit is not the preset value, it is necessary to execute the step of confirming whether the number of restarts of the operating system has reached the preset number according to the value of the abnormally started flag bit, and in the case of confirming that the preset number has been reached, skip the foregoing steps S230 - S270 and directly execute the step of starting the startup driver program. In the case of determining that the preset number has not been reached, it is necessary to first determine whether the time duration between the current startup time and the time stored at the last startup failure is greater than the preset time duration. If it is not greater than the preset time duration, skip the foregoing steps S230 - S270 and directly execute the step of starting the startup driver program; if it is greater than the preset time duration, execute the foregoing steps S230 - S270.

[0129] By adopting the virus interception method of the present application, it is possible to start the anti-malware target driver before starting the startup driver. The target driver obtains a rule set, which includes multiple virus rules. During the process of loading the startup driver, the target driver obtains the first program information of the startup driver. The target driver performs virus identification on the startup driver based on the first program information of the startup driver and the rule set to obtain a virus identification result. If the virus identification result indicates that the startup driver is a virus, the startup driver will be intercepted. By adopting the above method, it is possible to perform virus detection before the startup driver starts and intercept it when it is detected and confirmed to be a virus program, thereby improving the security of the operating system. In addition, since the target driver is automatically started every time the system starts and the user is unaware during the entire interception process, the above virus interception process will not bring additional operation costs. Further, by setting an abnormal startup flag bit, it is possible to avoid the problem that the key components of the operating system are misintercepted by using the rule set for rule matching, resulting in the device being unable to boot.

[0130] A virus interception method provided by the present application is applied to an electronic device, which is installed with an operating system. The operating system includes a driver layer and an application layer. As Figure 5 shown, the specific processes of the virus interception methods respectively executed in the driver layer and the application layer will be generally described below in combination with Figure 5 this.

[0131] On the application layer side, after a target application program (such as: software manager, virus killing software, etc.) used for virus scanning or detection is started, it will regularly send a rule request to the background to regularly update the full set of rules (regularly update virus rules). The full set of rules includes a large number of expired digital signatures exploited by Rootkit. At the same time, it will scan and detect the startup driver, and store the file path and registry path of the driver that is judged black after scanning and detection as incremental rules (new virus rules), so as to obtain a rule set including incremental rules and full set of rules. After that, the rule set will be sent to a specified path in the registry for storage.

[0132] The driver layer is responsible for starting the target driver with the initialization of the kernel after the operating system boots, loading the startup driver after the kernel initialization is completed, and using the target driver to read the rule set previously saved locally (the rule set in the specified path of the registry), using the program callback function of the startup driver to obtain the first program information of the startup driver, and matching the first program information with the virus rules in the rule set. The driver that matches the virus rules in the rule set will be judged black and intercepted.

[0133] The application layer is also responsible for the first program information of the startup driver program that is normally started obtained by the mobile phone driver layer and the second program information of the startup driver program scanned by the target application program, and compares the first program information of the startup driver program with the second program information to obtain a comparison result. When the comparison result indicates that the first program information is inconsistent with the second program information, it reports the difference set including the first program information and the second program information so that the management personnel can determine whether the startup driver program is a virus program based on the reported difference set.

[0134] As Figure 6 shown, taking the target driver program as the ELAM driver program as an example, in this application, it is found that the startup of the Rootkit virus occurs in the Boot driver startup stage, that is, in the early stage of the operating system startup, and it can be started after the system loader starts and the system kernel starts, and it often starts earlier than many system drivers (such as file system drivers, third-party drivers, and antivirus software, etc.). Therefore, it can obtain various system permissions fastest. Traditional antivirus software usually starts after the Boot driver program (startup driver program) is loaded, and at this time, it is no longer possible to pose a threat to Rootkit. Based on this, the embodiments of this application provide a virus interception method. This method utilizes the idea that the ELAM driver program is loaded by the system kernel before the Boot driver is loaded, so that the ELAM driver program can check each Boot driver program. After the Boot driver program is loaded, it uses the rule library and the program information of the Boot driver program to verify whether the Boot driver program is trustworthy. If it is not trustworthy, it will be intercepted. If it is trustworthy, the Boot driver program will be started. The specific execution process can refer to Figure 7 and the following description:

[0135] First, after the target driver program in the operating system starts, it is necessary to determine whether the startup mode of this operating system is the secure startup mode, and confirm whether the target driver program has caused an exception during the virus interception process based on the abnormal startup flag bit in the registry of the operating system. If it is the secure startup mode or has caused an exception, it will not execute the subsequent steps related to virus interception, but directly load and start the startup driver program.

[0136] If the startup mode of the operating system is not the secure startup mode and no exception has occurred, the target driver program needs to read the rule set sent down by the application layer and stored in advance. Among them, the rule set read by the target driver program is saved in the specified path of the registry, such as: under the HKLM\ELAM directory of the registry.

[0137] During the startup driver loading process, the target driver registers the calling program callback function IoRegisterBootDriverCallback. (Here, IoRegisterBootDriverCallback is a Linux kernel API used to register device driver callback functions during startup. This API allows the driver to perform some initialization tasks during system startup, such as device initialization, configuration, and interaction with other devices), and obtains the first program information of the startup driver by registering the above-mentioned program callback function (the first program information includes one or more of the program registry path, program file path, and program certificate hash, etc.).

[0138] During the startup driver loading process, since the types of startup drivers include dependent startup drivers and non-dependent startup drivers, and intercepting a dependent startup driver is likely to cause the system to fail to start normally. Therefore, for dependent startup drivers, virus recognition and interception are not required, but they are directly loaded and started. For non-dependent startup drivers, after they are loaded, the target driver can match the registry path, program file path, and program certificate hash of the non-dependent startup driver with the virus rules in the rule set respectively; if there is a virus rule in the rule set that matches at least one of the program registry path, program file path, and program certificate hash of the non-dependent startup driver, determine that the virus recognition result indicates that the non-dependent startup driver is a virus; at this time, the non-dependent startup driver can be intercepted for blacklisting, and its type can be set to an abnormal type. Among them, when intercepting the non-dependent startup driver for blacklisting, the entry program code of the non-dependent startup driver can be used or other operations can be adopted to prevent the non-dependent startup driver from starting normally.

[0139] Considering that it may be impossible to identify and intercept some startup driver programs that are essentially virus programs during the startup phase, the embodiments of the present application identify by obtaining the first program information of the real startup driver program and comparing it with the second program information of the startup driver program obtained by the target application program (virus scanning or identification program) in the application layer to determine whether each startup driver program may be a virus program. However, since the file system (Ntfs.sys) is not loaded during the operating system startup phase and the first program information of the startup driver program cannot be written, the program callback function can be unloaded first and then a startup callback function can be registered. After the operating system starts successfully, the first program information of the startup driver program is written to the target file by using the startup callback function for the target application program in the application layer to compare. The target application program performs abnormal identification on the started startup driver program according to the first program information of the started startup driver program read from the target file and the second program information of the started startup driver program, and obtains an abnormal identification result; if the abnormal identification result indicates that the started startup driver program is abnormal, an abnormal prompt message is generated. So that the management personnel can confirm whether the above-mentioned startup driver program is a virus program based on the abnormal prompt message. At the same time, when the management personnel determine that the startup driver program is a virus program, the information such as the registry path, file path, and certificate hash of the startup driver program can be synchronized to the rule set in the application layer, so that the application layer can issue the rule set, so as to intercept virus programs based on the issued rule set during subsequent operating system startups.

[0140] In addition, it should be noted that since the target driver program has high permissions and the operating system does not perform security verification on the interception result, the target driver program can intercept all Boot-type startup driver programs, including some necessary system components during operating system startup, such as ntfs.sys. Therefore, in order to prevent the operating system from intercepting system critical components and causing the system to fail to start, the embodiments of the present application are designed as Figure 8Logic for preventing abnormal startup (e.g., blue screen prevention logic): Specifically, when the target driver performs the aforementioned virus recognition, it first reads the value of the blue screen flag bit in the registry. If the value of the blue screen flag bit is 0, it means that the operating system has not experienced a blue screen before and started normally after the previous virus recognition and interception. At this time, increment the value of the blue screen flag bit by 1 and save the current timestamp as well. At the same time, perform the aforementioned rule set acquisition and virus recognition and interception processes. After completion, if the operating system boots normally, indicating successful startup from the operating system at this time, the value of the blue screen flag bit can be reset to 0. If the operating system fails to boot normally, the operating system restarts and returns to execute the step of first reading the value of the blue screen flag bit in the registry and reading the flag bit. At this time, the flag bit is 1. Considering that the user may cause the system to fail to start normally due to power failure or other situations, it will be judged whether the last update time of the flag bit exceeds 24 hours. If it has exceeded 24 hours, continue to increment the flag bit by 1 and return to execute the aforementioned rule set acquisition and virus recognition and interception processes. If it does not exceed 24 hours, the target driver does not execute the aforementioned rule set acquisition and virus recognition and interception processes, but directly starts the startup driver. If the operating system fails to start continuously for multiple days, resulting in the value of the blue screen flag bit being 3, then the ELAM driver will no longer execute the aforementioned rule set acquisition and virus recognition and interception processes, but directly start the startup driver.

[0141] As Figure 9 shown, an exemplary diagram of the scanning result obtained by scanning with a target application program (e.g., Tencent Computer Manager) in the application layer is shown when a certain startup driver is a Rootkit virus program with antagonism and the Rootkit virus program is not started. Figure 9 The risk location and file name of the Rootkit virus program are shown in it.

[0142] If Figure 9 the Rootkit virus program in starts and the virus interception method of the present application is not used to intercept the Figure 9 antagonistic Rootkit virus program in, then an exemplary diagram of scanning with a target application program (e.g., Tencent Computer Manager) in the application layer after the operating system starts is as shown in Figure 10As shown, it can be seen that the Rootkit virus program will rename itself to a random file name, and the scan result will prompt it as an abnormal item. This is because the Rootkit virus program registers file filtering to hide itself in order to avoid being detected by antivirus software. The target application scans the registry entry of the Rootkit virus program, but cannot scan the file corresponding to the virus. At this time, if the user chooses to handle the virus, the target application will register a startup anti-virus driver and try to set itself to the highest priority to achieve the purpose of restarting the anti-virus scan. However, by checking the corresponding driver startup priority, it can be found that the Rootkit has taken corresponding countermeasures against this behavior. Exemplarily, as Figure 11 shown, an exemplary sorting order of the driver priorities is given. Among them, NcGameGuard is the startup group corresponding to the Rootkit virus program, and TsBootClean is the startup group corresponding to the startup anti-virus driver of the target application. Since the Rootkit always maintains the highest priority, the target application cannot detect and kill it after starting the anti-virus driver. After restarting the computer and scanning again, as Figure 12 shown, it can be seen that there are still abnormal items of the Rootkit virus program, and the Rootkit virus program has changed to another random name, resulting in the inability to detect and kill the virus.

[0143] However, by adopting the foregoing method steps of the present application, after the device is restarted, by executing the foregoing method steps, after the operating system is successfully restarted, the virus program scan result obtained by scanning with the target application in the application layer no longer appears as an abnormal item, but accurately scans the virus file as shown in Figure 13 shown. This is because the target driver intercepts the startup of the Rootkit virus, making it lose all its resistance. At this time, click to detect and kill this virus, restart the computer and scan again, and then the result as shown in Figure 14 shown can be obtained, and it can be found that the virus has been successfully detected and killed.

[0144] It should be noted that the virus interception method of this embodiment can be applied not only in the Windows operating system, but also in more application methods. For example, a network-connected PE system can be made. Among them, the PE system (Preinstallation Environment) is a lightweight operating system environment based on the Windows operating system, and the Windows Preinstallation Environment (Windows PE) is a lightweight Windows operating system. When detecting and killing viruses, the target driver is booted from the USB flash drive to this PE system, and then the hard disk of the original operating system is mounted, and the files of the original operating system are scanned and killed online.

[0145] A small Linux system can also be created. Write the virus information to be detected and killed into a file, and rewrite the user's BIOS / UEFI boot area so that it can automatically boot after restart. After Linux is loaded, mount the original system hard disk during its init stage, and read the previously saved information for virus detection and killing.

[0146] It should be understood that the foregoing various application scenarios are only illustrative application scenarios. On the basis of not departing from the inventive concept of this solution, there can be more application scenarios, which will not be elaborated one by one in this embodiment.

[0147] It should be understood that although the steps in the flowcharts involved in the above embodiments are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same moment, but can be executed at different moments. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least a part of other steps or steps or stages in other steps.

[0148] Please refer to Figure 15 , the embodiment of the present application provides a virus interception device 400, which is applied to an electronic device. The virus interception device 400 includes: a program startup module 410, a rule set acquisition module 420, a program information acquisition module 430, a virus recognition module 440, and a program interception module 450. The program startup module 410 is configured to start an anti-malicious target driver in the operating system in response to a startup instruction of the operating system; the rule set acquisition module 420 is configured to use the target driver to acquire a rule set, and the rule set includes multiple virus rules; the program information acquisition module 430 is configured to, during the process of loading and starting the driver, acquire first program information of the startup driver by the target driver; the virus recognition module 440 is configured to use the target driver to perform virus recognition on the startup driver based on the first program information and the rule set of the startup driver to obtain a virus recognition result; the program interception module 450 is configured to intercept the startup driver when the virus recognition result indicates that the startup driver is a virus.

[0149] In an implementable manner, the rule set acquisition module 420 includes a reading sub-module and a rule set acquisition sub-module. The reading sub-module is configured to read the value of the abnormal startup flag bit in the registry of the operating system when the target driver confirms that the startup mode of the operating system is not the secure startup mode. The rule set acquisition sub-module is configured to, when the value of the abnormal startup flag bit indicates a preset value, obtain the rule set pre-stored in the registry of the operating system by the target driver. The preset value indicates that no abnormality occurs during the startup process of the operating system.

[0150] In an implementable manner, the device 400 further includes: an accumulation module, a restart module, and a program startup module. The accumulation module is configured to, when the value of the abnormal startup flag bit is the preset value, accumulate the value of the abnormal startup flag bit in the registry based on a specified value, and store the update time of the value of the abnormal startup flag bit. The restart module is configured to restart the operating system when the startup of the operating system fails. The reading sub-module is further configured to re-read the value of the abnormal startup flag bit in the registry of the operating system during the restart process of the operating system. The accumulation module is further configured to, when it is determined that the restart count of the operating system does not reach a preset count based on the re-read value of the abnormal startup flag bit, and the duration between the re-read value and the stored update time is greater than a preset duration, accumulate the value of the abnormal startup flag bit in the registry based on a specified value, and store the update time of the value of the abnormal startup flag bit. The program startup module is configured to, when it is determined that the restart count of the operating system does not reach a preset count based on the re-read value of the abnormal startup flag bit, determine that the duration between the re-read value and the stored update time does not exceed a preset duration, or, when it is determined that the restart count of the operating system reaches a preset count based on the re-read value of the abnormal startup flag bit, start the startup driver.

[0151] In an implementable manner, the device 400 further includes a reset module, configured to reset the value of the abnormal startup flag bit in the registry to a preset value when the startup of the operating system is successful.

[0152] In an implementable manner, the first program information of the startup driver includes the program registry path, program file path, and program certificate hash of the startup driver. The virus recognition module 440 is further configured to use the target driver to match the registry path, program file path, and program certificate hash of the startup driver with the virus rules in the rule set respectively. If there is a virus rule in the rule set that matches at least one of the program registry path, program file path, and program certificate hash, determine that the virus recognition result indicates that the startup driver is a virus. If there is no virus rule in the rule set that matches each of the program registry path, program file path, and program certificate hash, determine that the virus recognition result indicates that the startup driver is not a virus.

[0153] In an implementable manner, the device 400 further includes a public key acquisition module and a signature verification module. The public key acquisition module is configured to use a target driver to acquire a public key for verifying the signature information of the rule set. The signature verification module is configured to use the target driver to verify the signature information with the public key to obtain a signature verification result. The virus recognition module is further configured to, when the signature verification result indicates that the signature verification is passed, use the target driver to perform virus recognition on the startup driver based on the first program information of the startup driver and the rule set to obtain a virus recognition result.

[0154] In an implementable manner, the device 400 further includes a program startup module. The virus recognition module is further configured to, when the type of the startup driver is a non-dependent driver type, use the target driver to perform virus recognition on the startup driver based on the first program information of the startup driver and the rule set to obtain a virus recognition result. Among them, the startup driver belonging to the non-dependent driver type needs to rely on other drivers to start. The program startup module is further configured to, when the type of the startup driver is a dependent driver type, or the virus recognition result of the startup driver belonging to the non-dependent driver type indicates that the startup driver is not a virus, start the startup driver. Among them, the driver belonging to the dependent driver type does not need to rely on other drivers to start

[0155] In an implementable manner, the device 400 further includes an information writing module, a program scanning module, an anomaly recognition module, and a prompt information generation module. The function registration module is further configured to register a boot callback function during the process of uninstalling the program callback function of the startup driver. The information writing module is configured to, when the operating system starts successfully, call the boot callback function to write the first program information of the startup driver into a target file. The program scanning module is configured to use a target application program in the application layer to perform a driver scan to obtain the second program information of the started startup driver. The anomaly recognition module is configured to perform anomaly recognition on the started startup driver according to the first program information of the started startup driver read from the target file and the second program information of the started startup driver to obtain an anomaly recognition result. The prompt information generation module is configured to generate an anomaly prompt information when the anomaly recognition result indicates that the started startup driver is abnormal.

[0156] In one possible implementation, the first program information includes a program registry path, a program file path, and a program certificate hash, and the second program information includes a reference registry path, a reference file path, and a reference certificate hash; the anomaly recognition module is further configured to, if it is determined, according to the first program information of the started startup driver read from the target file and the second program information of the started startup driver, that the started startup driver meets the first condition, determine that the anomaly recognition result is an identification result indicating that the started startup driver is anomalous; wherein, the first condition includes at least one of the following: the program registry path of the started startup driver is inconsistent with the reference registry path, the program file path of the started startup driver is inconsistent with the reference file path, the program certificate hash of the started startup driver is inconsistent with the reference certificate hash, and the driver file obtained according to the program file path of the started startup driver is inconsistent with the driver file obtained according to the reference file path.

[0157] In one possible implementation, the program information acquisition module 430 is further configured to register a program callback function for the startup driver to be loaded; during the process of loading the startup driver, the target driver calls the program callback function to obtain the first program information of the startup driver.

[0158] Each module in the above device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor in the computer device in hardware form or independent of the processor, or can be stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules. It should be noted that the device embodiment in this application corresponds to the foregoing method embodiment, and the specific principle in the device embodiment can refer to the content in the foregoing method embodiment, which will not be elaborated here.

[0159] Next, Figure 16 an electronic device provided by this application will be described.

[0160] Please refer to Figure 16 , based on the virus interception method provided in the foregoing embodiment, another electronic device 100 provided in an embodiment of this application includes a processor 102 that can execute the foregoing method, and the electronic device can be a terminal device or a server.

[0161] The electronic device 100 further includes a memory 104. Among them, the memory 104 stores a program that can execute the content in the foregoing embodiment, and the processor 102 can execute the program stored in the memory 104.

[0162] Among them, the processor 102 may include one or more cores for processing data and a message matrix unit. The processor 102 connects various parts within the entire electronic device 100 through various interfaces and circuits, and executes various functions of the electronic device 100 and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by calling the data stored in the memory 104. Optionally, the processor 102 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 102 may integrate a combination of one or several of a central processing unit (CPU), a graphics processing unit (GPU), and a modem, etc. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the displayed content; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 102 and may be implemented separately through a communication chip.

[0163] The memory 104 may include random access memory (RAM) and may also include read-only memory. The memory 104 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for implementing at least one function, instructions for implementing the following various method embodiments, etc. The data storage area may also store data obtained by the electronic device 100 during use.

[0164] The electronic device 100 may further include a network module and a screen. The network module is used to receive and send electromagnetic waves, implement the mutual conversion between electromagnetic waves and electrical signals, so as to communicate with a communication network or other devices, such as communicate with an audio playback device. The network module may include various existing circuit components for performing these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, subscriber identity module (SIM) cards, memories, and the like. The network module can communicate with various networks such as the Internet, enterprise intranets, wireless networks or communicate with other devices through a wireless network. The above-mentioned wireless network may include a cellular phone network, a wireless local area network or a metropolitan area network. The screen can display interface content and perform data interaction, such as displaying the result of data access processing.

[0165] In some embodiments, the electronic device 100 may further include: a peripheral interface 106 and at least one peripheral device. The processor 102, the memory 104 and the peripheral interface 106 may be connected by a bus or signal lines. Each peripheral device can be connected to the peripheral interface through a bus, signal lines or a circuit board. Specifically, the peripheral devices include at least one of a radio frequency component 108, a positioning component 112, a camera 114, an audio component 116, a display screen 118, and a power supply 122, etc.

[0166] The peripheral interface 106 can be used to connect at least one peripheral device related to I / O (Input / Output) to the processor 102 and the memory 104. In some embodiments, the processor 102, the memory 104 and the peripheral interface 106 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 102, the memory 104 and the peripheral interface 106 can be implemented on a separate chip or circuit board, and the embodiments of the present application do not limit this.

[0167] The radio frequency component 108 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The radio frequency component 108 communicates with a communication network and other communication devices through electromagnetic signals. The radio frequency component 108 converts an electrical signal into an electromagnetic signal for transmission, or converts the received electromagnetic signal into an electrical signal. Optionally, the radio frequency component 108 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, and so on. The radio frequency component 108 can communicate with other terminals through at least one wireless communication protocol. The wireless communication protocol includes but is not limited to: the World Wide Web, a metropolitan area network, an intranet, various generations of mobile communication networks (2G, 3G, 4G, and 5G), a wireless local area network, and / or a WiFi (Wireless Fidelity) network. In some embodiments, the radio frequency component 108 may further include a circuit related to NFC (Near Field Communication), which is not limited in this application.

[0168] The positioning component 112 is used to locate the current geographical location of the electronic device to implement navigation or LBS (Location Based Service). The positioning component 112 may be a positioning component based on the US GPS (Global Positioning System), the Beidou system, or the Galileo system.

[0169] The camera 114 is used to capture images or videos. Optionally, the camera 114 includes a front camera and a rear camera. Generally, the front camera is disposed on the front panel of the electronic device 100, and the rear camera is disposed on the back of the electronic device 100. In some embodiments, there are at least two rear cameras, which are any one of a main camera, a depth-of-field camera, a wide-angle camera, and a telephoto camera, to implement the function of background blurring by fusing the main camera and the depth-of-field camera, panoramic shooting by fusing the main camera and the wide-angle camera, and VR (Virtual Reality) shooting function or other fusion shooting functions. In some embodiments, the camera 114 may further include a flash. The flash may be a single-color temperature flash or a two-color temperature flash. The two-color temperature flash refers to the combination of a warm light flash and a cold light flash, which can be used for light compensation under different color temperatures.

[0170] The audio component 116 may include a microphone and a speaker. The microphone is used to collect sound waves of the user and the environment, and convert the sound waves into electrical signals for input to the processor 102 for processing, or input to the radio frequency component 108 to achieve voice communication. For the purpose of stereo collection or noise reduction, there may be multiple microphones, which are respectively arranged at different parts of the electronic device 100. The microphone may also be an array microphone or an omnidirectional collection microphone. The speaker is used to convert the electrical signal from the processor 102 or the radio frequency component 108 into sound waves. The speaker may be a traditional thin film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can not only convert the electrical signal into sound waves audible to humans, but also convert the electrical signal into sound waves inaudible to humans for uses such as ranging. In some embodiments, the audio component 114 may also include a headphone jack.

[0171] The display screen 118 is used to display the UI (User Interface). The UI may include graphics, text, icons, videos, and any combination thereof. When the display screen 118 is a touch display screen, the display screen 118 also has the ability to collect touch signals on or above the surface of the display screen 118. The touch signal may be input to the processor 102 as a control signal for processing. At this time, the display screen 118 may also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 118, which is arranged on the front panel of the electronic device 100; in other embodiments, there may be at least two display screens 118, which are respectively arranged on different surfaces of the electronic device 100 or in a folded design; in still other embodiments, the display screen 118 may be a flexible display screen, which is arranged on the curved surface or the folding surface of the electronic device 100. Even, the display screen 118 may also be set to an irregular non-rectangular shape, that is, a special-shaped screen. The display screen 118 may be prepared using materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0172] The power supply 122 is used to supply power to each component in the electronic device 100. The power supply 122 may be alternating current, direct current, a disposable battery, or a rechargeable battery. When the power supply 122 includes a rechargeable battery, the rechargeable battery may be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery charged through a wired line, and a wireless rechargeable battery is a battery charged through a wireless coil. The rechargeable battery may also be used to support fast charging technology.

[0173] The embodiment of the present application further provides a structural block diagram of a computer-readable storage medium. Program code is stored in the computer-readable medium, and the program code can be called by a processor to execute the method described in the above method embodiment.

[0174] The computer-readable storage medium may be an electronic memory such as a flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, a hard disk, or a ROM. Optionally, the computer-readable storage medium includes a non-transitory computer-readable storage medium. The computer-readable storage medium has a storage space for program code for executing any method step in the above method. These program codes can be read out from or written into one or more computer program products. The program code can be compressed in an appropriate form, for example.

[0175] The embodiment of the present application further provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method described in the above various optional implementation manners.

[0176] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not intended to limit them. Although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments or perform equivalent replacements for some of the technical features. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A virus interception method, characterized in that, The method includes: Starting a target driver in the operating system in response to a startup instruction of the operating system; Obtaining a rule set by the target driver, where the rule set includes multiple virus rules; During the process of loading and starting the driver, obtaining first program information of the startup driver by the target driver; Performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result; If the virus identification result indicates that the startup driver is a virus, intercepting the startup driver.

2. The method according to claim 1, characterized in that The first program information of the startup driver includes the program registry path, program file path, and program certificate hash of the startup driver; The performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result includes: Matching the registry path, program file path, and program certificate hash of the startup driver with the virus rules in the rule set by the target driver respectively; If there is a virus rule in the rule set that matches at least one of the program registry path, program file path, and program certificate hash, determining that the virus identification result is an identification result indicating that the startup driver is a virus; If there is no virus rule in the rule set that matches each of the program registry path, program file path, and program certificate hash, determining that the virus identification result is an identification result indicating that the startup driver is not a virus.

3. The method according to claim 1, characterized in that, Before the performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result, the method further includes: Obtaining a public key for verifying the signature information of the rule set by the target driver; Verifying the signature information with the public key by the target driver to obtain a signature verification result; The performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result includes: If the signature verification result indicates that the verification passes, performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result.

4. The method according to claim 1, wherein The performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result includes: If the type of the startup driver is a non-dependent driver type, performing virus identification on the startup driver by the target driver based on the first program information of the startup driver and the rule set to obtain a virus identification result; where a startup driver belonging to the non-dependent driver type needs to rely on other drivers to start; the method further includes: If the type of the startup driver is a dependent driver type, or the virus recognition result of the startup driver belonging to the non-dependent driver type indicates that the startup driver is not a virus, start the startup driver; among them, a driver belonging to the dependent driver type does not need to depend on other drivers to start.

5. The method according to claim 1, wherein The method further includes: Register a boot callback function; If the operating system starts successfully, call the boot callback function to write the first program information of the startup driver into a target file; The target application program in the application layer performs a driver scan to obtain the second program information of the started startup driver; According to the first program information of the started startup driver read from the target file and the second program information of the started startup driver, perform anomaly recognition on the started startup driver to obtain an anomaly recognition result; If the anomaly recognition result indicates that the started startup driver is abnormal, generate an anomaly prompt message.

6. The method according to claim 5, wherein The first program information includes a program registry path, a program file path, and a program certificate hash, and the second program information includes a reference registry path, a reference file path, and a reference certificate hash; The performing anomaly recognition on the started startup driver according to the first program information of the started startup driver read from the target file and the second program information of the started startup driver to obtain an anomaly recognition result includes: If it is determined according to the first program information of the started startup driver read from the target file and the second program information of the started startup driver that the started startup driver meets the first condition, determine that the anomaly recognition result is a recognition result indicating that the started startup driver is abnormal; Among them, the first condition includes at least one of the following: The program registry path of the started startup driver is inconsistent with the reference registry path, the program file path of the started startup driver is inconsistent with the reference file path, the program certificate hash of the started startup driver is inconsistent with the reference certificate hash, and the driver file obtained according to the program file path of the started startup driver is inconsistent with the driver file obtained according to the reference file path.

7. The method according to claim 1, wherein During the process of loading the startup driver, the target driver obtains the first program information of the startup driver, including: Register a program callback function for the startup driver to be loaded; During the process of loading the startup driver, the target driver calls the program callback function to obtain the first program information of the startup driver.

8. The method according to claim 1, characterized in that The target driver obtains the rule set, including: If the target driver confirms that the startup mode of the operating system is a preset startup mode, read the value of the abnormal startup flag bit in the registry of the operating system; If the value of the abnormal startup flag bit indicates a preset value, the target driver obtains a rule set pre-stored in the registry of the operating system; the preset value represents that no abnormality occurs during the startup process of the operating system.

9. The method according to claim 8, wherein After obtaining the value of the abnormal startup flag bit in the registry of the operating system, the method further includes: If the value of the abnormal startup flag bit is the preset value, accumulate the value of the abnormal startup flag bit in the registry based on a specified value, and store the update time of the value of the abnormal startup flag bit. If the startup of the operating system fails, restart the operating system. During the restart process of the operating system, re-read the value of the abnormal startup flag bit in the registry of the operating system. If it is determined according to the re-read value of the abnormal startup flag bit that the number of restarts of the operating system has not reached the preset number of times, and the duration between the current time and the stored update time is greater than the preset duration, return to execute the step of accumulating the value of the abnormal startup flag bit in the registry based on the specified value and storing the update time of the value of the abnormal startup flag bit. If it is determined that the duration between the current time and the stored update time does not exceed the preset duration when it is determined according to the re-read value of the abnormal startup flag bit that the number of restarts of the operating system has not reached the preset number of times, or if it is determined according to the re-read value of the abnormal startup flag bit that the number of restarts of the operating system has reached the preset number of times, start the startup driver.

10. The method according to claim 9, wherein After accumulating the value of the abnormal startup flag bit in the registry based on the specified value and storing the update time of the value of the abnormal startup flag bit, the method further includes: If the startup of the operating system is successful, reset the value of the abnormal startup flag bit in the registry to the preset value.

11. A virus interception method, characterized in that, The method includes: A program startup module, configured to start a target driver in the operating system in response to a startup instruction of the operating system. A rule set acquisition module, configured to use the target driver to acquire a rule set, where the rule set includes multiple virus rules. A program information acquisition module, configured to, during the process of loading the startup driver, use the target driver to acquire first program information of the startup driver. A virus recognition module, configured to use the target driver to perform virus recognition on the startup driver based on the first program information of the startup driver and the rule set, and obtain a virus recognition result. A program interception module, configured to intercept the startup driver when the virus recognition result indicates that the startup driver is a virus.

12. An electronic device, characterized in that, Includes: One or more processors; A memory; One or more programs, where the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs are configured to execute the method according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code, and the program code can be called by a processor to execute the method according to any one of claims 1-10.

14. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1-10 are implemented.

Images