Virus protection method and system, computer program product and implementation method

Abstract

The invention provides a virus protection method and system, a computer program product and an implementation method, and relates to the technical field of communication. The virus protection method comprises the following steps: generating a white list based on a first directory and a second directory; allowing or forbidding running of processes in the computer equipment based on the white list; wherein the first directory is at least used for storing system executable files, and the second directory is at least used for storing user executable files.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a virus protection method, system, computer program product, and virus protection implementation method. Background Art

[0002] Malicious programs may include some programs written by malicious users or attackers with the intention of attacking computer devices. Antivirus software can prevent the running of malicious processes. Antivirus software can establish a virus library and detect running application processes based on the rules of the virus library. If a malicious process is found, it will try to clear or isolate it.

[0003] However, the establishment of the virus database depends on the virus samples it obtains. Due to the continuous evolution and emergence of malicious programs, it is difficult for the virus database to cover all the latest malicious programs. In order to solve this problem, antivirus software needs to continuously update the virus database to adapt to new security threats. Summary of the invention

[0004] One or more embodiments of the present specification provide a virus protection method, including: generating a whitelist based on a first directory and a second directory; allowing or prohibiting the running of a process in the computer device based on the whitelist; wherein the first directory is at least used to store system executable files, and the second directory is at least used to store user executable files.

[0005] According to the method described in some embodiments of the present specification, allowing or prohibiting the running of a process based on the whitelist includes: scanning the executing process, and allowing or prohibiting the running of the process based on the process name of the executing process and the whitelist.

[0006] According to the method described in some embodiments of the present specification, allowing or prohibiting the running of a process based on the process name of the executing process and the whitelist includes: determining the non-kernel process in the executing process; judging whether the process name of the executing non-kernel process is consistent with the process name in the whitelist, and if not, prohibiting the running of the executing non-kernel process.

[0007] According to the method described in some embodiments of the present specification, generating a whitelist based on the first directory and the second directory includes: when the computer device is started, generating a first part of the whitelist based on the first directory; when the computer device is started and / or after starting, generating a second part of the whitelist based on the second directory.

[0008] According to the method described in some embodiments of the present specification, when the computer device is started, the first part of the whitelist is generated based on the first directory, including: generating the first part of the whitelist based on the first directory through a first preset process; when the computer device is started and / or after starting, the second part of the whitelist is generated based on the second directory, including: generating the second part of the whitelist based on the second directory through a second preset process, and the second preset process is executed at preset time intervals.

[0009] According to the method described in some embodiments of this specification, the allowing or prohibiting the running of the process based on the whitelist is also implemented by the second preset process.

[0010] According to the method described in some embodiments of this specification, the computer device is based on a Linux system, and the second directory is located in a hidden partition of a hard disk of the computer device.

[0011] One or more embodiments of the present specification provide a computer program product, including computer codes. When at least part of the computer codes is executed by a processor, the above method can be implemented.

[0012] One or more embodiments of the present specification provide a virus protection system for a computer device, including: a whitelist module, used to generate a whitelist based on a first directory and a second directory; an execution module, used to allow or prohibit the running of a process based on the whitelist; wherein the first directory is at least used to store system executable files, and the second directory is at least used to store user executable files.

[0013] One or more embodiments of the present specification provide a method for implementing virus protection for a computer device, comprising: setting a preinstalled operating system file, wherein the preinstalled operating system file is generated based on the kernel and file system of the operating system, so that when the computer device is started, the kernel and file system of the operating system in the preinstalled operating system file are loaded into the memory of the computer device for execution through the boot program in the preinstalled operating system file; setting a preset process; the preset process is used to generate a whitelist based on a first directory and a second directory, and to allow or prohibit the execution of the process based on the whitelist; wherein the first directory is at least used to store system executable files, and the second directory is at least used to store user executable files.

[0014] According to the implementation method described in some embodiments of this specification, the second directory is located in a hidden partition or the second directory is a hidden directory, and the implementation method also includes: setting a customized running program, the customized running program includes the path information of the second directory, and the customized running program is used to start the executable file of the second directory when executed.

[0015] According to the implementation method described in some embodiments of this specification, the customized running program is also used to add the dynamic link library file directory located in the hidden partition to the dynamic link library environment variable when executed, and the dynamic link library environment variable is used to specify the search path of the dynamic link library.

[0016] According to the implementation method described in some embodiments of the present specification, it also includes: configuring the system command related to the file system to: when the output data of the system command related to the file system includes file-related information of the hidden partition and / or hidden directory, delete the file-related information of the hidden partition or hidden directory in the output data; or, when the input data of the system command related to the file system includes file-related information of the hidden partition or hidden directory, delete the file-related information of the hidden partition and / or hidden directory in the input data and then execute; the file-related information includes the storage path and / or file name of the file under the hidden partition and / or hidden directory.

[0017] According to some embodiments of the present specification, the implementation method further includes: re-implementing the system command through a script to achieve hiding of the second directory.

[0018] According to the implementation method described in some embodiments of the present specification, the re-implementing of the system command through a script to achieve the hiding of the second directory includes: writing the script so that the script accepts the same parameters as the system command, and when calling the system command, checking whether the path in the input data or output data of the system command involves the second directory, and if so, deleting the path related to the second directory or returning an empty result.

[0019] According to the implementation method described in some embodiments of this specification, the script is configured to: when the code of the script includes file-related information of the hidden partition and / or hidden directory, the file-related information of the hidden partition in the code is represented in ciphertext. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] This specification will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. The same numbers in the drawings represent the same structures or steps.

[0021] Figure 1 It is a flowchart of a virus protection implementation method according to some embodiments of this specification.

[0022] Figure 2 It is a flowchart of the virus protection method shown in some embodiments of this specification.

[0023] Figure 3It is a flowchart of generating a whitelist according to the virus protection method shown in some embodiments of this specification.

[0024] Figure 4 It is a flowchart of allowing or prohibiting the running of a process according to the virus protection method shown in some embodiments of this specification.

[0025] Figure 5 It is a flowchart of process name judgment according to the virus protection method shown in some embodiments of this specification.

[0026] Figure 6 It is a specific flow chart of the virus protection method shown in some embodiments of this specification.

[0027] Figure 7 It is an exemplary block diagram of a virus protection system according to some embodiments of the present specification. DETAILED DESCRIPTION

[0028] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the embodiments will be described in detail below with reference to the accompanying drawings. Obviously, the contents described below are some examples or embodiments of this specification. For ordinary technicians in this field, without paying creative work, the technical solutions or means disclosed in this specification can also be applied to other scenarios based on these technical contents.

[0029] It should be understood that the "system", "device", "unit" and / or "module" used in this specification is a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

[0030] Unless otherwise specified, technical terms used in this specification to describe components, elements, etc. do not refer to the singular, but may also include the plural. Generally speaking, terms such as "include", "comprise", etc. only indicate that the steps, elements, or components that have been clearly identified are included, and these steps, elements, and components do not constitute an exclusive list, such as the method or device described may also include other steps or components.

[0031] Flowcharts are used in this specification to illustrate the operation steps performed by the device or system of the relevant embodiments, but unless otherwise specified, the order used to describe these steps should not be understood as a limitation on the order in which the steps are performed. A person of ordinary skill in the art can adjust the order in which these steps are performed based on the knowledge and information conveyed by the embodiments of this specification, and the adjustment includes but is not limited to swapping the order, merging multiple steps, and splitting a certain step.

[0032] The viruses mentioned in this manual, unless otherwise specified, refer to viruses in a broad sense, which may also be called malicious programs or malicious codes, which may include computer codes that are installed and run on user computers or other terminals without explicit prompts to users or without user permission, posing threats or potential threats to networks or systems, and infringing on the legitimate rights and interests of users.

[0033] Viruses or malicious programs may include some programs written by malicious users or attackers with the intention of attacking computer devices. Specifically, they may include traditional viruses that can replicate themselves and infect other programs, worms that can replicate themselves and automatically spread through the network, Trojans that disguise themselves as legitimate programs to deceive users into performing malicious tasks, and logic bombs that are triggered under specific conditions and perform malicious operations.

[0034] Methods for installing malicious programs on computer devices may include: scanning the target system, finding and exploiting known vulnerabilities, such as SQL injection, buffer overflow, etc., to obtain system access permissions and then install malware; using deceptive means (such as sending phishing emails containing malicious attachments) to trick users into performing malicious operations and thus installing malware; obtaining administrator accounts and passwords through brute force or dictionary attacks, obtaining system access permissions, and installing malware; spreading malware to the target system through other infected systems or networks, etc.

[0035] In some related embodiments, the anti-virus software can be used to prevent the running of malicious processes such as viruses. The anti-virus software can establish a virus library and detect the running application process based on the rules of the virus library. If a malicious process is found, it will try to clear or isolate it. In some embodiments, the anti-virus software can monitor and scan system files, processes and network traffic in real time, and compare the running application process with the feature code in the virus library. When the application process matches the feature code in the virus library, it is considered that the process is a malicious process, and clearing or isolation measures are taken.

[0036] However, the establishment of the virus database depends on the virus samples it obtains. Due to the continuous evolution and emergence of malicious programs, it is difficult for the virus database to cover all the latest malicious programs. In order to solve this problem, antivirus software needs to continuously update the virus database to adapt to new security threats.

[0037] In some related embodiments, the operating system of a computer device, such as an embedded operating system on a server, may be illegally invaded by a malicious program. For example, an illegal background program may be injected into the operating system and run permanently, causing damage to the system. Based on this, one or more embodiments of this specification provide a virus protection method, so that the device does not rely on a virus library that needs to be updated regularly to detect and kill malicious programs, but blocks malicious processes by allowing known reliable programs to run and blocking other programs except reliable programs from running.

[0038] Figure 1 1 is a flowchart of a method for implementing virus protection for a computer device according to some embodiments of this specification. Figure 1 As shown, a virus protection implementation method for a computer device provided by one or more embodiments of this specification may include the following steps.

[0039] Step 100: Set a preinstalled operating system file, which is generated based on the kernel and file system of the operating system, so that when the computer device is started, the operating system (for example, including its kernel and file system) in the preinstalled operating system file is loaded into the memory of the computer device for execution through the boot program in the preinstalled operating system file.

[0040] In one or more embodiments of the present specification, in step 100, the preinstalled operating system file may be in an image file format, specifically an ISO image, or a GHO image, an IMG image, or other images such as VHD, DMG, and WIM. Taking the preinstalled operating system file in the ISO image format as an example, in some embodiments, the preinstalled operating system file may include a boot program, an operating system kernel, and an operating system file system, and the optional preinstalled operating system file may further include some customized tools or customized software.

[0041] Among them, the bootloader is one of the first programs to run when the computer system starts. The bootloader can load the operating system kernel into the memory during the computer startup process and hand over control to the operating system. The bootloader can be a key component in the computer startup process. It is used to initialize hardware devices, test hardware status, and prepare for the loading of the operating system. In some embodiments, the kernel and file system of the operating system in the pre-installed operating system file in ISO image format are loaded into the memory of the device through the bootloader.

[0042] It should be noted that, in some embodiments, the device automatically runs the boot program in the preinstalled operating system file based on the boot instruction. In other words, the device runs the boot program in the preinstalled operating system file when it starts. The aforementioned running of the boot program in the preinstalled operating system file is configured as a regular, default running mode implemented when the device starts, rather than a single, accidental running mode implemented based on a temporary startup or system recovery command.

[0043] In some embodiments, the kernel of the operating system running when the device starts up is the kernel of the operating system in a preinstalled operating system file, such as the kernel of the operating system in a preinstalled operating system file in an image file format, rather than running related files (system files) of the kernel of the operating system directly stored on the hard disk.

[0044] In some embodiments, the operating system that can be run on the device may only include the operating system provided by the preinstalled operating system file, and does not have other operating systems such as operating systems stored in the hard disk.

[0045] It should be noted that the aforementioned operating system stored in the hard disk refers to the basic software of the computer, which may include multiple executable files, and although the pre-installed operating system files are also stored in the hard disk in some embodiments, the pre-installed operating system files are files of a specific format. In some embodiments, the pre-installed operating system files can be understood as a storage or backup form of the operating system, and the pre-installed operating system files may include the data and settings of the aforementioned operating system, but need to be mounted or decompressed before use (for example, the kernel and file system in the pre-installed operating system files are loaded into the memory through the boot program in the pre-installed operating system files).

[0046] In one or more embodiments of the present specification, in step 100, the kernel and file system of the operating system in the preinstalled operating system file, or the kernel and file system of the operating system and some customized tools and / or customized software are loaded into the memory of the device through the boot program and run in the memory of the device. Based on this, the operating system will be restored from the preinstalled operating system file each time the device is started. Since the operating system exists in the preinstalled operating system file such as the ISO file, after the system is restarted, all operations on the operating system, such as operations on the kernel, operations on the file system, or operations on customized tools / customized software, will be reset, thereby preventing the storage and operation of malicious programs.

[0047] In some embodiments, a malicious program can modify a file system related file in the hard disk to achieve the purpose of destruction, stealing data, occupying system and network resources, encrypting the target victim's files and locking them. Exemplarily, a malicious program can achieve illegal access to the system and data theft by replacing or tampering with files, injecting malicious code, etc. When the device restarts, the replaced or tampered files and injected malicious code will be saved to the hard disk. In one or more embodiments of this specification, even if the currently running operating system is attacked by a malicious program, the replaced or tampered files and injected malicious code cannot be retained. When the device restarts, the boot program still loads the kernel and file system of the operating system that have not been replaced or tampered with and injected with malicious code from the pre-installed operating system file into the memory for operation.

[0048] Step 200: Set a preset process; the preset process is used to generate a whitelist based on the first directory and the second directory, and allow or prohibit the running of the process based on the whitelist; wherein the first directory is at least used to store system executable files, and the second directory is at least used to store user executable files.

[0049] In one or more embodiments of the present specification, in step 200, in the initial state of an operating system such as a customized operating system, the first directory includes system executable files, so the files in the first directory are trusted files; the second directory may include environment variables, customized programs provided to users by developers, and user executable files such as user-trusted programs installed by users, so the files in the second directory can also be considered to be trusted files. In some embodiments, a whitelist is generated based on the first directory and the second directory to ensure that the executable files involved in the whitelist are all trusted programs. In some embodiments, by allowing the running of processes that match the whitelist and prohibiting the running of processes that do not match the whitelist, the effect of blocking malicious processes without affecting the running of trusted files can be achieved.

[0050] In some embodiments, the first directory may be a part of the operating system in the preinstalled operating system file. Since the preinstalled operating system file loads the operating system into the memory for execution through the boot program, the executable files in the first directory can be executed in the memory, and the modification of the files in the first directory, such as deleting a certain executable file in the first directory, or installing a malicious program in the first directory, will not be saved, that is, the result of the modification operation will not be stored in the hard disk, and a replacement preinstalled operating system file will not be generated based on the modification operation. When the device is started next time, the device still loads the operating system from the original preinstalled operating system file provided by the developer into the memory for execution. At this time, the system executable files included in the first directory are still the original executable files in the preinstalled operating system file provided by the developer. In other words, even if a malicious program such as a virus is installed in the first directory, or even if the malicious program has damaged the data in the first directory, the effect equivalent to deleting the malicious program and restoring the system can be obtained by restarting the computer device.

[0051] In some embodiments, the second directory can be located in a hidden partition, or the second directory can be a hidden directory, so malicious programs cannot be installed in the second directory or modify files in the second directory without obtaining the path information of the second directory. The path information of the second directory is accessible to the user (for example, it can be obtained through materials such as instructions provided by the developer) or settable (for example, the user can set the path of the second directory through an API provided by the developer). The user can install the executable files he needs and trusts in the second directory based on the path of the second directory, or store the data he needs in the second directory. Therefore, the executable files in the second directory can be added to the whitelist as trusted programs. For more information on generating a whitelist through a preset process, see . Figure 2 The relevant description will not be repeated here.

[0052] In some embodiments, taking the Linux system as an example, the first directory may include a / bin directory, and the second directory may include a PATH environment variable directory.

[0053] See also Figure 1 As shown, Figure 1 The dotted box in FIG. 3 shows step 300, which may be omitted in some embodiments. Step 300 includes setting a customized running program, the customized running program includes the path information of the second directory, and the customized running program is used to start the executable file running in the second directory when executed.

[0054] In one or more embodiments of the present specification, in step 300, as described above, since the second directory is located in a hidden partition or the second directory is a hidden directory, accessing the second directory and running the executable file in the second directory both depend on the path information of the second directory. Therefore, a customized running program can be set up, and the customized running program includes the path information of the second directory. The user can access the second directory and run the executable file in the second directory based on the known path information of the second directory based on the customized running program.

[0055] In one or more embodiments of this specification, the customized operation program is also used to add the dynamic link library file directory under the hidden partition to the dynamic link library environment variable when executing, and the dynamic link library environment variable is used to specify the search path of the dynamic link library. Based on this, when the customized operation program is running the program, it can first search for the dynamic link library file under the hidden partition based on the dynamic link library file directory, and then search for the default path. If the customized operation program finds the required library file, the program run by the customized operation program can run normally. This setting method can be used to specify the dynamic library under the non-system default path.

[0056] In some embodiments, taking Linux system as an example, the dynamic link library file directory can be the / lib directory, and the dynamic link library environment variable can be the LD_LIBRARY_PATH environment variable. In some embodiments, the / lib directory in the hidden partition can be temporarily added to the LD_LIBRARY_PATH environment variable by customizing the running program.

[0057] One or more optional embodiments of the present specification provide a virus protection implementation method for a computer device, and may further include configuring a system command related to the file system to: when the output data of the system command related to the file system includes file-related information of a hidden partition and / or a hidden directory (e.g., a second directory), delete the file-related information of the hidden partition and / or the hidden directory in the output data, wherein the file-related information includes the storage path and / or file name of the file under the hidden partition and / or the hidden directory.

[0058] In some embodiments, during customization of the file system, a specific directory such as the second directory may be hidden by modifying the implementation of system commands related to the file system, that is, deleting file-related information of the second directory involved in the output data of the system command.

[0059] Exemplarily, in some embodiments, the system commands related to the file system may include one or more system commands that involve the file system when executed, such as searching / listing directory contents and files that meet the conditions, displaying information related to the file system such as resource information, etc. Exemplarily, in a Linux system or a Unix system, the system commands related to the file system may include ls (listing directory contents), ps (displaying current processes), df (displaying disk space usage), find (finding files in a directory tree), top (displaying system processes and resource usage), mount (mounting a file system), etc., wherein the system commands themselves may be used to view system status, processes, disk usage, find files, and monitor system performance. These system commands will not cause damage to the system when used normally. However, if a malicious user or attacker uses these commands to perform improper operations, such as deleting key files (through malicious programs), tampering with system configurations, or executing malicious scripts, it may cause damage to the system.

[0060] In one or more embodiments of the present specification, the file-related information of the hidden partition and / or hidden directory, such as the second directory, is deleted from the output data of the system command to achieve the hiding of the second directory. Exemplarily, taking the find command as an example, the output of the find command may be a list of one or more file names that meet the conditions set in the find command. In some embodiments, the malicious program may use the find command to search for all files with the extension .txt and output the paths of these files. In one or more embodiments of the present specification, the find command is configured to delete the data related to the hidden partition and / or hidden directory from its output data, such as deleting the .txt file located in the second directory before outputting.

[0061] Continuing with the previous example, the find command may include: find / second directory / -type f -name "*.txt".

[0062] In some embodiments, the output data of executing the aforementioned find command may include: / second directory / file1.txt, / second directory / subdir / file2.txt, / second directory / anotherdir / file3.txt, wherein, since file1.txt, file2.txt, and file3.txt are located in a hidden second directory, the find command is configured to delete the file-related information (such as the file name and the path corresponding to the file) of file1.txt, file2.txt, and file3.txt before outputting, or it may not output anything.

[0063] A virus protection implementation method for a computer device provided by one or more optional embodiments of the present specification may also include configuring a system command related to the file system as follows: when the input data of the system command related to the file system includes file-related information of a hidden partition or a hidden directory, the command is executed after deleting the file-related information of the hidden partition and / or the hidden directory in the input data, and the file-related information includes the storage path and / or file name of the file under the hidden partition and / or the hidden directory.

[0064] In some embodiments, in the customization of the file system, a specific directory such as the second directory can be hidden by modifying the system command related to the file system, that is, the file related information of the second directory involved in the input data of the system command is deleted before executing the system command.

[0065] In one or more embodiments of the present specification, the system command can be re-implemented through a script to achieve the hiding of the second directory. In some further embodiments, it can specifically include: writing a script so that the script accepts the same parameters as the system command, and when calling the system command, checking whether the path in the input data or output data of the system command involves the second directory, and if so, deleting the path involving the second directory or returning an empty result. It should be noted that in the one or more embodiments, the script performs the above-mentioned processing on, for example, the original system command A of the operating system to obtain the system command B re-implemented by the script corresponding to the original system command A. When the user wants to call the system command A, the operating system runs the system command B re-implemented by the script instead of the original system command A, thereby filtering the input data and output data of the original system command A of the operating system, thereby further achieving the hiding of the second directory.

[0066] For example, in some embodiments, in the customization of the file system, a shell script may be written to simulate the behavior of these commands to hide a specific directory such as the second directory. For example, taking the find command as an example, a shell script may be written that accepts the same parameters as find and deletes the relevant information of the hidden partition and / or hidden directory such as the second directory or returns an empty result when outputting data.

[0067] In some embodiments, the find command is a command line tool for finding files and directories. Exemplarily, the input parameters of the find command may include a directory that specifies the find command to start searching, which may be a path or multiple paths. Exemplarily, the input parameters of the find command may include search conditions, such as the attributes of the file or directory to be found, which may be one or more of the name, type, size, and time. Exemplarily, the input data of the find directory may also include operations performed on the search results, such as printing, deleting, moving, executing commands, etc. In some embodiments, the output data of the find command may be a list of found files and directories, which may involve relevant information of hidden directories. In order to prevent the output data from involving relevant information of hidden directories, in some embodiments, taking the find command as an example, a shell script may be written that receives the same parameters as find, but checks whether the input path parameters include hidden directories before calling the find instruction to perform the search. If so, the path may be deleted (i.e., the search is no longer performed on the path) or an empty result is returned. Exemplarily, a shell script may be written, which accepts the same parameters as the find command, but uses the sed command to delete the path involving the hidden directory, such as the second directory, from the parameter list before calling the find command, and then calls the system's find command and passes the modified parameters. Since the input parameters of the system's find command do not contain the path involving the hidden directory, such as the second directory, after modification, the output data thereof will not involve the relevant information of the hidden directory, such as the second directory. In some embodiments, when the user uses the shell script to re-implement the find command, the user inputs the search conditions, such as searching for all files under the A directory, the B directory, and the second directory (i.e., the original input parameters input by the user, where the user may include an illegal user or a malicious program provided by an attacker, etc.), wherein the second directory is a hidden directory, then when the shell script is run, the second directory in the search conditions is first deleted, and then the A directory and the B directory (i.e., the modified input parameters) in the search conditions are passed to the system's find command, and after the system's find command is executed, all files under the A directory and all files under the B directory are output, and no files under the second directory, i.e., the hidden directory, are output. In one or more embodiments of the present specification, when the user uses the shell script to re-implement the find command, the search conditions entered by the user may all involve hidden directories, for example, only searching all files under the second directory and its subdirectories. At this time, the shell script can pass empty input parameters (i.e., the modified input parameters) to the system's find command and the system's find command returns an empty result, or the shell script directly returns an empty result.

[0068] Based on the above settings, malicious programs cannot obtain files in the hidden partition, such as trusted files in the second directory, through system commands. Therefore, they cannot damage trusted files in the hidden directory, nor can they tamper with or steal user data.

[0069] In one or more embodiments of the present specification, a script, such as the aforementioned shell script, is configured to: when the script code includes file-related information of a hidden partition and / or a hidden directory, the file-related information of the hidden partition in the code is represented in ciphertext.

[0070] In some embodiments, the script may involve information related to a hidden directory or information related to a file located in the hidden directory (e.g., a user executable file in the second directory), and some scripts may be opened to view the code or instructions contained therein. To avoid leakage of information about hidden directories or hidden files in the script code, file-related information related to the second directory or files in the second directory in the script code may be represented in ciphertext, such as in binary form, to prevent the file-related information from being directly readable.

[0071] Figure 2 It is a flowchart of the virus protection method shown in some embodiments of this specification. Figure 2 The process shown can be implemented by the virus protection system 900, see Figure 2 As shown, a virus protection method for a computer device provided by one or more embodiments of this specification may include the following steps.

[0072] Step 500: Generate a whitelist based on the first directory and the second directory.

[0073] Step 600: Allow or prohibit the execution of a process in a computer device based on the whitelist.

[0074] In one or more embodiments of this specification, see Figure 3 As shown, step 500 may be implemented by the whitelist module 910 , and step 500 may include step 520 and step 540 .

[0075] In one or more embodiments of the present specification, step 520 includes generating a first part of a whitelist based on a first directory when the computer device is started. In some embodiments, the first directory may include system executable files provided by a developer of an operating system of the computer device. In some embodiments, the first directory may also include command line tools and / or software provided by the developer. Since the files in the first directory are provided by the developer and malicious programs cannot be installed in the first directory when the computer device is started, the executable files in the first directory can be considered as trusted files and added to the whitelist.

[0076] In some embodiments, the whitelist may include file names of executable files in the first directory.

[0077] In some embodiments, the device may generate a first portion of the whitelist based on the first directory through a first preset process.

[0078] In one or more embodiments of the present specification, step 540 includes generating a second part of a whitelist based on a second directory when and / or after the computer device is started. In some embodiments, the second directory includes user executable files installed by the user. Exemplarily, the second directory can be a hidden directory or located under a hidden partition, and the user obtains the path information of the second directory based on the information provided by the developer of the operating system of the computer device, and stores the user executable files trusted by the user under the second directory according to the path information. Because the second directory is hidden, malicious programs cannot be installed or self-copied to the second directory in the absence of the path information of the second directory, so the executable files in the second directory can be regarded as trusted files and added to the whitelist. In some embodiments, the second directory may also include command line tools and / or software provided by the developer. In some embodiments, the second directory may also include trusted non-executable files, for example, the second directory may also include trusted files such as configuration files and environment variables.

[0079] In some embodiments, the second directory may be one directory or multiple directories. In some embodiments, the second directory may also include one or more subdirectories.

[0080] In some embodiments, the whitelist may include file names of executable files in the second directory.

[0081] In some embodiments, the device may generate the second part of the whitelist based on the second directory through a second preset process, and the second preset process is executed at preset time intervals.

[0082] In some embodiments, the first preset process and the second preset process may be the same process or two different processes.

[0083] In one or more embodiments of this specification, see Figure 4 As shown, step 600 may be implemented by execution module 920 , and step 600 may include step 620 and step 640 .

[0084] In one or more embodiments of the present specification, step 620 includes scanning the executing process. In some embodiments, scanning the executing process may include traversing all active processes and collecting relevant information of the active processes, such as the process name.

[0085] In one or more embodiments of the present specification, step 640 includes allowing or prohibiting the running of the process based on the process name of the executing process and the whitelist. In some embodiments, step 640 screens and controls the scanned process according to the security policy. Exemplarily, the security policy may include: the processes involved in the whitelist are trusted processes, and the processes not involved in the whitelist are risky processes. Further, the security policy may also include: allowing trusted processes to run and prohibiting all risky processes from running.

[0086] In one or more embodiments of this specification, see Figure 5 As shown, step 640 may include step 642 and step 644 .

[0087] In one or more embodiments of the specification, step 642 includes determining non-kernel processes in the executing process. In some embodiments, kernel processes are excluded from all processes to determine non-kernel processes in the executing process, and subsequent step 644 is performed on the non-kernel processes.

[0088] In some embodiments, taking the Linux system as an example, the parent process of the process can be checked to confirm whether the executing process is a kernel process. For example, the relationship between the executing process and process No. 0 (idle process) and / or process No. 2 (kthreadd process) can be checked to determine whether the executing process is a kernel process, wherein process No. 2 can be created by process No. 0 in the kernel_thread mode, process No. 2 is responsible for the creation of subsequent kernel processes, responsible for the management and scheduling of kernel processes, process No. 0 and process No. 2 are kernel processes, and the child process of process No. 2 is also a kernel process, so the executing process related to process No. 0 or process No. 2, or the child process whose parent process is process No. 2 is a kernel process. In some embodiments, the non-kernel process can be determined by excluding the kernel process. Compared with process No. 0 and process No. 2, in some embodiments, process No. 1 (init process or systemd process) can be a user process, and its child process is also a user process. In other embodiments, taking the Linux system as an example, the kernel process can also be viewed through commands or tools such as top, ps, and htop.

[0089] In one or more embodiments of the present specification, step 644 includes determining whether the process name of the executing non-kernel process is consistent with the process name in the whitelist, and if not, prohibiting the execution of the executing non-kernel process.

[0090] In some embodiments, as described above, the whitelist includes the file names of safe executable files in a first directory generated when the computer device is started (the first part of the whitelist) and the file names of safe executable files in a second directory generated when the computer device is started and / or after starting (the second part of the whitelist). The file names of the executing non-kernel processes obtained by matching the scan are recorded in the whitelist. If the file name of the executing non-kernel process is recorded in the whitelist, the non-kernel process is considered to be trusted by the user and the non-kernel process is allowed to run. If the file name of the executing non-kernel process is not recorded in the whitelist, the non-kernel process is considered to be risky and the non-kernel process is prohibited from running.

[0091] In some embodiments, allowing or prohibiting the running of a process based on a whitelist may also be implemented by the aforementioned second preset process.

[0092] In some embodiments, the computer device is based on a Linux system, and the second directory is located in a hidden partition of a hard disk of the computer device.

[0093] Figure 6 is a schematic diagram of a specific process of the virus protection method shown in some embodiments of this specification, Figure 6 The process shown may include Figures 3 to 5 For the steps shown, see Figure 6 As shown, the specific process of the virus protection method in some embodiments of the present specification may include: the computer device is started, and the boot program in the pre-installed operating system file (such as an image file) loads the operating system (including the kernel and file system of the operating system) in the pre-installed operating system file into the memory for execution. At this time, the executable files in the first directory are all trusted programs provided by the developer of the operating system of the computer device (that is, malicious programs have not yet invaded at this time), and the process name of the trusted program provided by the developer in the first directory is added to the first part of the whitelist through the first preset process. The first part of the whitelist will not be updated before the computer device is restarted.

[0094] A malicious program may be installed in the first directory after the computer device is started. However, at this time, the first part of the whitelist has been established and will not be updated before the computer device is restarted. Therefore, the processes involved in the whitelist are trustworthy, and the operation of malicious programs can be prohibited based on the whitelist.

[0095] Exemplarily, when the computer device is started, the operating system in the pre-installed operating system file in the image format is loaded into the memory for execution, and the aforementioned first preset process generates a whitelist based on the first directory of the operating system, and the whitelist may include the file names of the executable files a1, a2, and a3 in the first directory. In some embodiments, after the device is started, the malicious program e1 is installed in the first directory, and the second preset process scans the executing processes, determines that the executing non-kernel processes are a2, a3, and e1, and determines whether the process name of the executing non-kernel process is consistent with the process name in the whitelist. The judgment result is that the process names a2 and a3 are consistent with the process names in the whitelist, and the process name e1 is inconsistent with the process name in the whitelist. Based on this, the running of process e1 is prohibited.

[0096] In some embodiments, the malicious program e1 destroys the executable files in the first directory, for example, tampers with or deletes the executable file a3 in the first directory. When the computer device is restarted, the operating system (including the first directory) in the pre-installed operating system file in the image format is loaded into the memory for operation. Since the operation of the malicious program e1 cannot modify the pre-installed operating system file, the system is restored, and the files in the first directory are in the initial state when the developer provides the operating system. That is, there is no malicious program e1 installed before the restart, and the executable file a3 in the first directory has not been tampered with or deleted. At this time, a whitelist is generated based on the first directory of the operating system, and the whitelist is still reliable.

[0097] In some embodiments, when the computer device is started or after the computer device is started, the second part of the whitelist is generated based on the second directory through the second preset process. At this time, the whitelist is established, which includes the first part that will not be updated during the current operation phase of the computer device and the second part that is updated at preset intervals based on the aforementioned second preset process, and the running of the process can be allowed or prohibited according to the whitelist.

[0098] Continuing with the previous example, the whitelist may include the file names of the executable files a1, a2, and a3 in the first directory, and the file names of the executable files b1, b2, and b3 in the second directory. In some embodiments, after the device is started, the malicious program e1 is installed in the first directory, and the malicious program e2 attempts to be installed in the second directory, but as mentioned above, since the second directory is a hidden directory, the malicious program lacks the path information of the second directory, so the installation of the malicious program e2 fails. In some embodiments, the second preset process scans the executing process, determines that the executing non-kernel process is a2, a3, b1, b2, and e1, and determines whether the process name of the executing non-kernel process is consistent with the process name in the whitelist. The judgment result is that the process name a2, a3, b1, and b2 are consistent with the process name in the whitelist, and the process name e1 is inconsistent with the process name in the whitelist. Based on this, the running of processes a2, a3, b1, and b2 is allowed, and the running of process e1 is prohibited.

[0099] In some further embodiments, the user installs the trusted executable file b4 to the second directory based on the path information obtained from the developer of the operating system, and runs the executable file b4 through the aforementioned customized running program. At this time, the second preset process is executed every preset time, so the second preset process generates the second part of the whitelist again based on the second directory. At this time, the whitelist is established, which includes the file names of the executable files a1, a2, and a3 in the first directory, and the file names of the executable files b1, b2, b3, and b4 in the second directory. In some embodiments, the second preset process scans the executing process, determines that the executing non-kernel process is a2, a3, b1, b2, and b4, and determines whether the process name of the executing non-kernel process is consistent with the process name in the whitelist. The judgment result is that the process names a2, a3, b1, b2, and b4 are all consistent with the process names in the whitelist. Based on this, the running of processes a2, a3, b1, b2, and b4 is allowed.

[0100] Based on the above specific process, one or more virus protection methods provided in this specification can establish a reliable whitelist, prohibit malicious programs from running based on the whitelist, allow programs trusted by users to run, do not affect the installation of normal user executable files, prevent the installation of malicious programs, and restore the system by restarting after the malicious program damages the system.

[0101] Figure 7 is an exemplary block diagram of a virus protection system according to some embodiments of this specification. Figure 7As shown, in some embodiments, the virus protection system 900 may include: a whitelist module 910 for generating a whitelist based on a first directory and a second directory, and an execution module 920 for allowing or prohibiting the running of a process based on the whitelist, wherein the first directory is at least used to store system executable files, and the second directory is at least used to store user executable files.

[0102] For more information about each module, see Figure 1 to Figure 6 The relevant description of will not be repeated here. It should be understood that Figure 7 The system and its modules shown can be implemented in various ways. For example, in some embodiments, the system and its modules can be implemented by hardware, software, or a combination of software and hardware. Among them, the hardware part can be implemented using dedicated logic; the software part can be stored in a memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated design hardware. Those skilled in the art will understand that the above methods and systems can be implemented using computer executable instructions and / or control codes contained in a processor, such as a disk, CD or DVD-ROM, etc., and such codes are provided in a carrier medium or a memory of a programmable device. The system and its modules of this specification can not only be implemented by hardware circuits such as ultra-large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but can also be implemented by software executed by various types of processors, and can also be implemented by a combination of the above hardware circuits and software (e.g., firmware).

[0103] It should be noted that the above description of the system and its modules is only for convenience of description and does not limit this specification to the scope of the embodiments. It is understandable that for those skilled in the art, after understanding the principle of the system, it is possible to arbitrarily combine the modules without deviating from this principle to form a subsystem connected to other modules. Or some modules may be split to obtain more modules or multiple units under the module. Such variations are all within the scope of the disclosure of this specification.

[0104] In one or more embodiments of this specification, a computer program product is also provided, including computer instructions or computer codes, which can implement the above-mentioned virus protection method when at least part of the computer instructions or computer codes are executed by a processor. In some embodiments, the computer program product may only involve computer instructions or computer codes, which may be carried by a storage medium or a processing device. In other embodiments, the computer program product may also be a storage medium or a processing device containing the aforementioned computer instructions or computer codes. The processing device may include one or more processors, and a storage medium.

[0105] In some embodiments, the processor may be a combination of one or more of the following processors: a central processing unit (CPU), an application specific integrated circuit (ASIC), an application specific instruction set processor (ASIP), a graphics processing unit (GPU), a physical processing unit (PPU), a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic device (PLD), a programmable logic controller (PLC), a reduced instruction set computer (RISC), and a microprocessor.

[0106] In some embodiments, the storage medium may include a combination of one or more of the following: a mass storage, a removable storage, a volatile read-write memory, and a read-only memory (ROM). Exemplary mass storage may include a magnetic disk, an optical disk, a solid-state hard disk, and the like. Exemplary removable storage may include a flash disk, a floppy disk, an optical disk, a memory card, a compressed hard disk, a magnetic tape, and the like. Exemplary volatile read-write memory may include a random access memory (RAM). Exemplary random access memory may include a dynamic random access memory (DRAM), a double data rate synchronous dynamic random access memory (DDRSDRAM), a static random access memory (SRAM), a thyristor random access memory (T-RAM), and a zero capacitance memory (Z-RAM), and the like. Exemplary read-only memory may include a masked read-only memory (MROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a compact disk read-only memory (CD-ROM), and a digital multifunction hard disk read-only memory, and the like.

[0107] The beneficial effects that may be brought about by the embodiments of this specification include but are not limited to: (1) there is no need to update the virus database, but the security policy of trusted files and risk files is based on allowing or prohibiting the running of processes, thereby preventing viruses; (2) by pre-installing the image file system, it is ensured that the files in the first directory are trusted system executable files provided by the developer, and at the same time, the system can be restored after being attacked by malicious programs; (3) by hiding the second directory, malicious programs cannot be installed in the second directory, ensuring that the files in the second directory are user executable files trusted by the user; (4) by customizing the running program, the user is allowed to run the user executable files in the hidden second directory; (5) the first part of the white list is not updated before the computer device is restarted, thereby preventing the running of malicious programs installed in the first directory; (6) the second part of the white list is updated at preset intervals to avoid mistakenly prohibiting newly installed user executable files trusted by the user.

[0108] It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects that may be produced may be any one or a combination of the above, or any other beneficial effects that may be obtained.

[0109] The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only for example and does not constitute a limitation of this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements and corrections to this specification. Such modifications, improvements and corrections are taught in this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

Claims

1. A virus protection method for computer equipment, characterized in that: include: generating a whitelist based on the first directory and the second directory; Allowing or prohibiting the execution of a process in the computer device based on the whitelist; The first directory is at least used to store system executable files, and the second directory is at least used to store user executable files.

2. The method according to claim 1, characterized in that The allowing or prohibiting the running of the process based on the whitelist includes: The executing processes are scanned, and the running of the processes is allowed or prohibited based on the process names of the executing processes and the whitelist.

3. The method according to claim 2, characterized in that The allowing or prohibiting the running of a process based on the process name of the executing process and the whitelist includes: determining a non-kernel process among the executing processes; It is determined whether the process name of the executing non-kernel process is consistent with the process name in the whitelist. If not, the running of the executing non-kernel process is prohibited.

4. The method according to any one of claims 1 to 3, characterized in that Generating a whitelist based on the first directory and the second directory includes: When the computer device is started, generating a first part of the whitelist based on the first directory; When and / or after the computer device is started, a second part of the whitelist is generated based on the second directory.

5. The method according to claim 4, characterized in that When the computer device is started, generating the first part of the whitelist based on the first directory includes: generating the first part of the whitelist based on the first directory through a first preset process; When the computer device is started and / or after starting, generating the second part of the whitelist based on the second directory includes: generating the second part of the whitelist based on the second directory through a second preset process, and the second preset process is executed at preset time intervals.

6. The method according to claim 5, characterized in that The allowing or prohibiting the running of the process based on the whitelist is also implemented by the second preset process.

7. The method according to claim 1, characterized in that The computer device is based on a Linux system, and the second directory is located in a hidden partition of a hard disk of the computer device.

8. A computer program product, comprising computer codes, which, when at least part of the computer codes is executed by a processor, can implement the method according to any one of claims 1 to 7.

9. A virus protection system for computer equipment, characterized in that: include: A whitelist module, used to generate a whitelist based on the first directory and the second directory; An execution module, configured to allow or prohibit the running of a process based on the whitelist; The first directory is at least used to store system executable files, and the second directory is at least used to store user executable files.

10. A method for implementing virus protection for computer equipment, characterized in that: include: Setting a preinstalled operating system file, wherein the preinstalled operating system file is generated based on the kernel and the file system of the operating system, so that when the computer device is started, the kernel and the file system of the operating system in the preinstalled operating system file are loaded into the memory of the computer device for execution through the boot program in the preinstalled operating system file; Set up preset processes; The preset process is used to generate a white list based on the first directory and the second directory, and to allow or prohibit the running of the process based on the white list; The first directory is at least used to store system executable files, and the second directory is at least used to store user executable files.

11. The implementation method according to claim 10, characterized in that: The second directory is located in a hidden partition or the second directory is a hidden directory, and the implementation method further includes: A customized running program is set, wherein the customized running program includes the path information of the second directory, and the customized running program is used to start the executable file in the second directory when executed.

12. The implementation method according to claim 11, characterized in that: When the customized running program is executed, it is also used to add the dynamic link library file directory located in the hidden partition to the dynamic link library environment variable, and the dynamic link library environment variable is used to specify the search path of the dynamic link library.

13. The implementation method according to claim 10, characterized in that: Also includes: The system command related to the file system is configured to: when the output data of the system command related to the file system includes the file related information of the hidden partition and / or the hidden directory, delete the file related information of the hidden partition or the hidden directory in the output data; or, when the input data of the system command related to the file system includes file-related information of a hidden partition or a hidden directory, the command is executed after deleting the file-related information of the hidden partition and / or the hidden directory in the input data; The file-related information includes the storage path and / or file name of the file in the hidden partition and / or hidden directory.

14. The implementation method according to claim 13, characterized in that: Also includes: The system command is re-implemented through a script to achieve hiding of the second directory.

15. The implementation method according to claim 14, characterized in that: The step of re-implementing the system command through a script to hide the second directory includes: The script is written so that it accepts the same parameters as the system command, and when the system command is called, it is checked whether the path in the input data or output data of the system command involves the second directory. If so, the path related to the second directory is deleted or an empty result is returned.

16. The implementation method according to claim 14 or 15, characterized in that: The script is configured to: when the code of the script includes the file-related information of the hidden partition and / or the hidden directory, represent the file-related information of the hidden partition in the code in cipher text.

Images