RU2491623C1 - System and method of verifying trusted files - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: file is received for verification and the identifier of the received file is compared with identifiers contained in a list of trusted file identifiers. The identifier of the received file is verified to determine if it an identifier of a trusted key file, if the identifier of the received file is not contained in the list of trusted file identifiers. A packet of trusted file identifiers associated with the identifier of the received file is formed if the identifier of the received file was defined as an identifier of a trusted key file. The formed packet of trusted file identifiers is added to the list of trusted file identifiers.

EFFECT: faster antivirus verification of files on a disc.

33 cl, 5 dwg

Description

Technical field

This invention relates to proxy file verification systems for anti-virus scanning and, more particularly, to systems that use caching of a list of trusted files to reduce scan time.

State of the art

With the development of computer technology, the number of various software (hereinafter - the software) used by users is increasing at an even faster pace. In addition to safe software that performs legitimate actions and functions, for example, an email client, image editor, etc., there is also malware that interferes with proper operation or harms safe software. Malicious software includes various viruses, trojans, worms, etc. Such malware infects users' computers, which leads to the malfunctioning of these computers and the safe software installed on these computers. For example, it is possible to block access to folders, steal confidential user data, seize control of computer data for further malicious actions directly to these computers or other computers that are on the same network with them.

In this regard, anti-virus protection tools are constantly being developed and improved. There are many different programs and methods for checking files for malware on a computer disk. One such way of checking files is to check at the request of the user. During this scan, the antivirus scans files using various methods, such as checking against signature databases, behavioral analysis, etc. Currently, the main disadvantages of on-demand verification, i.e. “On demand scanning” (hereinafter referred to as ODS scanning) is a long time of scanning the files on the disk itself and a large load on the disk during scanning.

There are many different ways to optimize file verification, for example, based on the use of so-called whitelists and blacklists, or based on tracking the fact of file modification, for example, through timestamps.

So, in the application US 1009083852 A1, an invention is described in which, to optimize ODS data verification, the system transmits a data structure (for example, a catalog of hash values of files) to the white and black list server and at the same time indicates the time of the last successful communication with the server (i.e. e. the last successful data validation). A server with white and black lists only checks for new or changed data after the last successful connection. After that, the system receives information on the sent data, which is new or changed data, and determines whether the data is trusted or malicious. With this approach of data verification, the described invention needs to constantly make server requests for verified data.

The second variant of verification optimization is described in US Pat. No. 7,591,019 B1, in which the system stores the checksum of the file when checking the file, and this information is stored in a special table. Upon subsequent verification of the file, the previous checksum is checked against the current amount. If the checksum has not been changed, the file is not checked. If the checksum has been changed, this means that the file has been modified and should be re-checked for malicious code. A feature of this invention is the preliminary accumulation of checksums and periodic verification of files, because with a long absence of verification, it is possible to change a large number of files, which will lead to a long scan. It can also be noted that the accumulation of checksums of the file occurs during the verification itself and the checksum of the file will be added to the table, provided that the file with this sum will be pre-checked.

An analysis of the prior art and the possibilities that arise when combining them in one system allows you to get a new result, namely a system to reduce the time of anti-virus scanning of files on disk by preliminary checking files for proxy and caching the list of trusted files.

SUMMARY OF THE INVENTION

The present invention is intended to optimize the scanning of files on disk for their power of attorney during anti-virus scanning. Optimization of file verification by proxy is achieved by reducing the time of the verification itself.

The technical result of this invention is to optimize (reduce the time) anti-virus scan of files on disk, which is achieved by excluding from this scan files whose identifiers are in the data cache.

A system for replenishing the list of trusted files in the data cache, which includes: a) a data cache designed to store a list of identifiers of trusted files and provide the specified list to the file analysis module; b) an information service designed to determine whether a file belongs to trusted key files using the received identifier of the specified file from the file analysis module and, if the file is a trusted key file, transfer the package of identifiers of trusted files associated with this trusted key file to the file analysis module ; c) a file analysis module intended for:

- search among files in the file system for those files whose identifiers are not in the specified data cache list,

- transfer of at least one file identifier from the found files to the information service,

- adding packages of identifiers of trusted files received from the information service in response to the transmitted identifier in the list of identifiers of trusted files stored in the data cache.

In a particular embodiment, the system also contains an anti-virus scanner that interacts with the data cache and is intended for anti-virus scanning of file system files, during which it detects and transfers files whose identifiers are not in the specified data cache list to the file analysis module.

In another particular embodiment of the system, the file analysis module is an anti-virus scanner and is intended for anti-virus scanning of file system files, during which it uses a list of trusted files stored in the data cache.

In yet another particular embodiment of the system, the file identifier, at least, is the file itself, the file hash value, file metadata, identifiers assigned by the file system to each file, or a combination of these entities.

In another particular embodiment of the system, the identifier assigned by the file system is at least the NTFS identifier for the NTFS file system.

In another particular embodiment of the system, the file analysis module searches for key files in the file system, the identifiers of which are not in the list of identifiers of trusted data cache files, and transfers the identifiers of the found key files to the information service.

In another particular embodiment of the system, the file analysis module verifies that the list of trusted file identifiers stored in the data cache matches the file system file identifiers.

In another particular embodiment of the system, if there is no file identifier among the file system file identifiers, this identifier will be removed from the list of trusted file identifiers.

In another particular embodiment of the system, before adding the package of identifiers of trusted files to the list of identifiers of trusted files, the file analysis module checks the identifiers from the specified package for their presence among file identifiers of the file system.

In yet another particular embodiment of the system, the identifier from the package of identifiers of trusted files will not be added to the list of identifiers of trusted files if the specified identifier is not among the identifiers of file system files.

In another particular embodiment of the system, during the installation of the software on the disk, the file analysis module determines the key file from the specified installed software, the identifier of which is not contained in the list of identifiers of trusted data cache files, and transfers the identifier of the found key file to the information service.

In another particular embodiment of the system, the file analysis module searches for files whose identifiers are not in the list of identifiers of trusted data cache files among file system files:

- in the background;

- during file verification;

- during the installation of new software.

In another particular embodiment of the system, the trusted file is a secure file that is known to the information service.

In another particular embodiment of the system, the key file is a software file with which files belonging to this software are identified.

In another particular embodiment of the system, the key file is at least one of the following file types: executable file, installation file, and archive file.

In another particular embodiment of the system, the key file is a file with one of the following names: “setup” and “autorun”.

In another particular embodiment of the system, the key file is a file signed by an electronic digital signature of the software manufacturer.

In another private embodiment of the system, the key file is a file containing the software manufacturer’s license agreement.

In another particular embodiment of the system, the information service can be located both on the user's computer and on the remote server.

In yet another particular embodiment of the system, an information service, if the file is not a trusted key file, but is a trusted file, then it transfers only the identifier of the specified file to the file analysis module.

In another private embodiment of the system, an information service, if the file identifier is not an identifier of a trusted key file, but is an identifier of a trusted file, it generates a package of identifiers of trusted key files that are associated with the specified identifier of the trusted file and sends the specified package to the file analysis module ; the file analysis module searches for file identifiers from the received package of identifiers of trusted key files in the file system; and if at least one of the specified identifiers is found in the file analysis module, the file analysis module requests the package of identifiers of trusted files associated with the found identifier from the information service for the subsequent addition of this package to the list of identifiers of trusted files stored in the data cache.

A method for updating the list of trusted files in the data cache, which contains the steps of: a) receiving a file for verification, b) comparing the identifier of the received file with identifiers contained in the list of identifiers of trusted files, c) checking if the identifier of the received file is the identifier of the trusted key file, if the identifier of the received file is not contained in the list of identifiers of trusted files, d) form a package of identifiers of trusted files associated with the identifier of the received file If the identifier of the received file was defined as the identifier of the trusted key file, e) add the generated package of identifiers of trusted files to the list of identifiers of trusted files.

In a particular embodiment of the method, further verification of the received file is completed if the identifier of the received file is contained in the list of trusted file identifiers.

In another particular embodiment of the method, it is checked whether the identifier of the received file is the identifier of the trusted file, if the specified identifier has not been defined as the identifier of the trusted key file.

In another particular embodiment of the method, the identifier of the received file is added to the list of identifiers of trusted files, if the specified identifier has been defined as the identifier of the trusted file.

In another particular embodiment of the method, the file identifier, at least, is the file itself, the file hash value, file metadata, identifiers assigned by the file system to each file, or a combination of these entities.

In yet another particular embodiment of the method, the identifier assigned by the file system is at least an NTFS identifier for an NTFS file system.

In another particular embodiment of the method, the trusted file is a secure file and is contained in the “white lists” of anti-virus companies.

In yet another particular embodiment of the method, the key file is a software file with which files belonging to the software are identified.

In another particular embodiment of the method, the key file is at least one of the following file types: executable file, installation file, and archive file.

In another particular embodiment of the method, the key files are files with the names: “setup” and “autorun”.

In another particular embodiment of the method, the key file is a file signed by an electronic digital signature of the software manufacturer.

In another particular embodiment of the method, the key file is a file containing the software manufacturer’s license agreement.

Brief description of the attached drawings

The accompanying drawings, which are included to provide an additional understanding of the invention and form part of this description, show embodiments of the invention and, together with the description, serve to explain the principles of the invention.

The claimed invention is illustrated by the following drawings, in which:

Figure 1 is a diagram of the use of the file system for anti-virus scanning.

Figure 2 illustrates a diagram of a system for optimizing anti-virus scanning of files on a disk.

Figure 3 illustrates a method by which it is possible to implement a system for optimizing anti-virus scanning of files on a disk.

Figure 4 illustrates a particular embodiment of a file analysis module and a file verification system for a power of attorney.

Figure 5 shows a computer system for which the described invention can be used.

Description of Embodiments

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence described in the description is nothing more than the specific details provided to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined only in the scope of the attached claims.

Figure 1 presents a diagram of the use of the file system for anti-virus scanning. The file system contains various files, for example, executable files, system files, text files, etc. All files for the claimed invention are divided into the following file types:

a) 101 - trusted files, i.e. These are files that are safe files and known files for the claimed system, i.e. files that are contained in the “white lists” of anti-virus companies;

b) 102 - unknown files, i.e. These are files that are unknown to the declared system (i.e. files that are not contained in the list of trusted files) and can be both safe and malicious files;

c) 103 - trusted key files, i.e. these are files that were identified from trusted files 101. In this case, the key file may be a file that can be quickly identified on the user's PC and by which other software files or the entire software package can be identified. Typically, a key file will be placed together with files that it can identify, for example, in the same root directory. Most likely, the key file will be any executable file ([file name]. Exe), installation file ([file name] .msi), archive file ([file name] .rar). Another example of key files may be files with the most common names, for example, setup, autorun. Also, the key file is any permanent (unchangeable) file from the package of files, for example, a file containing the software manufacturer’s license agreement or an electronic digital signature of the software manufacturer.

d) 104 - unknown trusted key files (hereinafter - unknown key files), i.e. these files are 103 files, but only unknown to the claimed invention.

In one embodiment, the claimed invention, when interacting with files, will generate the hash values of the files, and further analysis will occur with the generated values of the specified hash sums.

In the particular case of the claimed invention can analyze the file by file metadata. File metadata is file information that allows you to identify a given file, for example, file name, file size, file format, file version, etc. It is also possible to analyze the totality of several types of metadata.

Figure 2 illustrates a diagram of a system for optimizing anti-virus scanning of files on a disk.

Within the framework of this scheme, a private version of the implementation of the anti-virus scan optimization system is considered. However, the present invention is not limited to this application. Also, this optimization system is also suitable for checking files for a power of attorney when using other technologies, for example, OAS (on access scanning - access check), HIPS (Host-based Intrusion Prevention System - intrusion prevention system), WL (whitelisting - clean lists) .

The optimization system of the anti-virus scan in one of the implementation options consists of the following modules:

data cache 230, which is designed to store a list of unique identifiers for trusted files and interacts with the file analysis module 240. As a unique identifier for the file and, therefore, as a list of unique identifiers, any information can be used to accurately identify this file for example, the file itself, the hash value of the file, file metadata, identifiers assigned by the file system to each file, for example, NTFS identifiers. Next, a particular embodiment will be described in which the hash value (hereinafter referred to as the hash) of the file and, therefore, the list of hashes of trusted files will be used as a unique identifier;

information service 220, which analyzes the unique identifiers (hereinafter, hashes) of files for their power of attorney (security) and belonging to key files, searches for hashes of trusted files 101 associated with the hash of a trusted key file 103, generates packets of hashes of trusted files 225 and provides data trusted hashes packages 225 to file analysis module 240;

a file analysis module 240, which analyzes the files represented in the file system 100, makes the necessary requests for the analyzed files 102 and 104 to the information service 220, and replenishes the data cache 230 with new packages of hashes of trusted files 225.

In the particular case of the implementation of the presented system, an anti-virus scanner 210 is possible that controls the process of scanning files from the file system 100 and sends requests for unknown files 102 and / or 104 to the file analysis module 240, and also interacts with the data cache 230.

In yet another embodiment of the presented system, it is possible to combine the file analysis module 240 and the anti-virus scanner 210 into a single module. In this case, a single module will perform the functions of modules 210 and 240.

Next, we consider an implementation option for anti-virus file scanning.

During the anti-virus scan of the files presented in the file system 100 of the computer, the anti-virus scanner 210 is launched. During operation, the anti-virus scanner 210 sends a request for information about the files being scanned to the data cache 230. The data cache 230, containing a list of hashes of trusted files, responds to the requested files, according to this list, to the anti-virus scanner 210. Before requesting files to be scanned into the data cache 230, the anti-virus scanner 210 generates hashes of all the files being scanned. Then, the anti-virus scanner 210 compares the received hashes of the scanned files with information (ie, hashes) from the list of trusted file hashes provided by the data cache 230. Generating hashes of the scanned files and comparing them is possible both in turn and all at once.

In the event that the hash of the checked file matches any hash from the list of hashes of trusted files, then the checked file is a trusted file 101 and is not subjected to further verification. If the hash of the checked file was not found in the list of hashes of trusted files, then this file is an unknown file 102. Antivirus scanner 210 blocks the execution of this unknown file 102 until the scan is completed and a decision is made on this file 102. Then, the antivirus scanner 210 sends a request for analysis of this unknown file 102 to the file analysis module 240. As a request from the anti-virus scanner 210, not the unknown file 102 itself may be sent, but the unique identifier of the unknown file 102, for example, a hash file but.

In the particular case, the anti-virus scanner 210 can scan files in the file system 100 for any file identifiers, for example, file metadata, identifiers assigned by the file system to each file, for example, NTFS identifiers. In this case, the data cache 230 should also store lists of file identifiers against which the files are checked.

In a particular case, the antivirus scanner 210 may not generate a hash of the requested files upon request for scanned files in the data cache 230. In this case, the anti-virus scanner 210 will compare these files by checking the file data with another list of trusted files, which is also stored in the data cache. An example of such a list of trusted files is the list of NTFS trusted file identifiers for the NTFS file system. In this case, the anti-virus scanner 210 will compare the NTFS identifiers of the scanned files with the NTFS identifiers from the list of NTFS identifiers of trusted files. In the case when the NTFS identifiers of the scanned files are in this list, the scanned files are skipped during further scanning. In the case when the scanned files did not appear in this list, a request is sent to analyze the file data to the information service 220. The list of NTFS-identifiers of trusted files can be filled, for example, when filling out the list of hashes of trusted files, i.e. when new hashes of trusted files fall into the list of hashes of trusted files, then NTFS-identifiers of data of trusted files will be added to the list of NTFS-identifiers of trusted files. The list of trusted files is populated according to the method described in FIG. 4.

In this embodiment, the file analysis module 240, upon receipt of a request for an unknown file 102, processes this request and generates a request for the specified unknown file 102 to information service 220. Information service 220 checks this unknown file 102 for its security, for example, the presence of this file 102 in the “white lists” database, which is used by the information service 220. In the event that an unknown file 102 was not in the “white lists” database, the information service 220 stops analyzing this unknown File 102, and corresponds to the file analysis module 240 that the unknown file 102 is not in the "white list". Then, the file analysis module 240 responds to the anti-virus scanner 210 that the unknown file 102 has not been determined and is potentially dangerous. In this case, the anti-virus scanner 210 starts scanning this unknown file 102 by all means available to it, for example, searching for signature databases, heuristic analysis, behavioral analysis, etc.

In a particular case, the information service 220, in addition to responding to the file analysis module 240 about the absence of an unknown file 102 in the white list database, can make a response request for this unknown file 102 for subsequent independent analysis of this file 102. The information service 220 sets the module as a request file analysis 240 a number of questions for further analysis, for example, where the file was received from, when the file was installed, etc. Another way to analyze this unknown file 102 is to check against the “black lists” database, which is also a tool of the information service 220. Also, as methods of analyzing the unsafe unknown file 102, the information service 220 can apply the technologies described in the patents for utility model RU 91203 G06F 21/00 and RU 101224 G06F 15/00.

In the case where the unknown file 102 is a safe file, i.e. is in the white list database, then this file 102 becomes a trusted file 101, and the information service 220 analyzes this trusted file 101. When analyzing this trusted file 101, the information service 220 determines whether this file 101 is a trusted key file 103 or not . An example of determining a file as a trusted key file is to search the database of key files, which is contained in the information service 220.

If the information service 220 determines that this trusted file 101 is a trusted key file 103, then the information service 220 selects all trusted files 101 associated with this trusted key file 103. For example, the selection of all trusted files 101 is performed using the database of related files , which is contained in the information service 220. Then, the information service 220 generates a hash packet 225 from all found trusted files 101 and transmits this hash packet 225 to the file analysis module 240. After receiving a trusted file hash package 225, the data analysis module 240 adds the specified package 225 to the list of trusted file hashes stored in the data cache 230. The data cache 230 stores a list of trusted file hashes to further provide the specified hashes from this list to check the file system for trust, for example, during anti-virus scanning.

If the trusted file 101 is not a known trusted key file 103, then only the hash of the given trusted file 101 will be added to the data cache 230.

In the particular case when the trusted file 101 is not a trusted key file 103, the information service 220 searches for the belonging of this trusted file 101 to any trusted key file 103 or to several trusted key files 103. If this trusted file 101 belongs to to any one or more trusted key files 103, the information service 220 will send a request to the file analysis module 240 to search for data of the detected trusted key files 103 in the file system item 100. In a preferred embodiment, the request will be sent while the hash of the given trusted file 101 is transferred to the list of hashes of the trusted files. When searching for trusted key files 103 that were sent from the information service 220, the file analysis module 240 may limit the search itself, for example, by setting the boundaries of this search to the directory in which the unknown file 102 was located. If the file analysis module 240 finds which Any trusted key file 103 from the requested trusted key files 103 in the file system 100 will then send a response to the information service 220 in the form of information about the found trusted key file 103. In this case, the information service 220 will search for trusted files 101 associated with this trusted key file 103. In the event that none of the proposed trusted key files 103 is found in the file system 100, the file analysis module 240 will inform the information service 220 about the absence of data of trusted key files 103 in the file system 100. Then the information service 220 will not search for trusted files 101 associated with this trusted key file 103, but will finish working with these trusted key files 103.

In a particular case, as an answer to a request for an unknown file 102, information service 220 can only transmit a sign, for example, expressed as a flag (a separate bit). This flag will inform the file analysis module 240 that the requested file 102 is a trusted key file 103, and a hash package of trusted files 225 is generated associated with this trusted key file 103. If necessary, this package 225 file analysis module 240 will send a second request to the information service 220.

In a preferred embodiment, the system does not have an anti-virus scanner 210. In this case, the file analysis module 240 has the following functions: searching for unknown files 102 and 104 in the file system 100, generating requests for unknown files 102 and 104 to the information service 220, analyzing the received packets hashes of trusted files 225 from information service 220 and transferring packets of hashes of trusted files 225 to data cache 230. It is also possible to combine modules 210 and 240 into a single module and in this case a single module will serve as a wallpaper represented modules.

The file analysis module 240, when interacting with the information service 220, makes a request for the unknown file 102 and receives a response from the information service 220 in the form:

1) the hash of the trusted file 101, if the unknown file 102 is a trusted file 101,

2) a hash package of trusted files 225 associated with this unknown file 102, if the unknown file 102 is a trusted key file 103,

3) only information about the most unknown file 102.

The answer will depend on whether the unknown file 102 is a trusted file 101, a trusted key file 103, or an unknown file 102.

In the particular case, the file analysis module 240 can preliminarily determine whether the unknown file 102, received from the anti-virus scanner 210 or found independently, is an unknown key file 104 or not. In this case, the file analysis module 240 will only make requests to the information service 220 for the unknown key files 104. Then the information service 220 will determine whether the unknown key file 104 is a trusted key file 103. In the event that the requested unknown key file 104 is a trusted key file 103, then the information service 220 will search for all trusted files 101 associated with this trusted key file 103 and generate a package of hashes of trusted files 225. The generated hehe package information service 220 will direct it to the trusted files 225 to the file analysis module 240, which in turn will add the specified package 225 to the list of trusted file hashes stored in the data cache 230. In the event that the requested unknown key file 104 is not a trusted key file 103, then the information service 220 will inform about this result, the file analysis module 240 and finish the work.

Also, in one embodiment, the file analysis module 240, after receiving from the information service 220 a package of hashes of trusted files 225, conducts a preliminary search of each file hash from the received package of hashes of trusted files 225 for its presence in the file system 100. For this, the file analysis module 240 generates the hash of each file from the file system 100. In the case when the hash of the file from the received packet 225 was found among the hashes of the files of the file system 100, then this hash of the file is added to the list of hashes of trusted files that finds It is located in the data cache 230. In the event that a file hash from the received packet 225 was not found, this hash is not added to the list of hashes of trusted files and is deleted.

In a particular case, the file analysis module 240 searches for unknown key files 104 in the file system 100 in order to prefill the data cache 230 with trusted files 101. In a preferred embodiment, the search is performed in the background and when the anti-virus scanner 210 does not work and is in standby mode. In this case, the file analysis module 240 searches the file system 100 for installed new software. After determining the key files in the new software, the file analysis module 240 checks the hashes of the found key files in the list of trusted file hashes from the data cache 230. If the hashes of the key file data are already in the list of trusted file hashes, the file analysis module 240 skips them. If the hashes of these key files are not in the list of hashes of trusted files, then these key files are unknown key files 104. After that, the file analysis module 240 queries at least one of the found unknown key files 104 to the information service 220. Information service 220 examines the received hash of the unknown key file 104. If it is determined that this hash belongs to the trusted key file 103, then a package of trusted file hashes 225 will be generated associated with the requested hash ohm Then this packet 225 will be transferred to the data cache 230, namely to the list of hashes of trusted files. In the event that a hash packet 225 was transferred to the file analysis module 240, then the module 240 will first check the hashes of the received hash packet of trusted files 225 for files with these hashes in the file system 100. In the event that these hashes were found, then the file analysis module 240 transfers the hash data to the data cache 230. In the event that no hash data was found, the file analysis module 240 removes the hash data from the hashed packet of trusted files 225.

In a particular case, the file analysis module 240 checks the hashes of the received package of hashes of trusted files 225 for files with these hashes not throughout the file system 100, but at the most probable locations, for example, C: / Program Files.

In one embodiment, the file analysis module 240 performs the function of checking the validity of lists of hashes of trusted files in the data cache 230, i.e. for the presence of files with these hashes in the file system 100, because files could be deleted. The search for files can be carried out both throughout the file system 100, and only along the path (address) along which the file was originally detected.

In yet another embodiment, the file analysis module 240 monitors file operations (during user operation), for example, installing software, modifying existing files, deleting files, etc., while module 240 records changes to the file system. After the user has finished work, the file analysis module 240 makes the corresponding changes in the data cache 230. If the changes were made to existing files, then these files became unknown files 102. In this case, the module 240 will make a request for these files to the information service 220 and according to the answer, it will correct the entries for these files in the data cache 230. If the answer is yes, i.e. the files are trusted files 101, then the module 240 will add the hashes of the data files 101 to the data cache 230. If the answer is no, i.e. the files are unknown files 102, then the module 240 will transmit these files 102 to the anti-virus scanner 210 for further analysis. If the software was installed, the module 240 will identify key files 103 or 104 from this software and analyze the files. It is also possible that the module 240 will not wait for the end of the user's work, but in parallel will work with him.

In one embodiment, the file analysis module 240 will not make requests to the information service 240 for the analyzed files to obtain a package of hashes of trusted files 225, but will analyze it on its own. This analysis is possible when installing new software on the user's computer. Any software consists of one or many files, which, when installing the software, are copied to the user's computer. As a rule, this software is provided in a compressed (packaged) form, for example, by the software installer. Moreover, this software installer must be a certified (signed) container. A certified container is a container that is signed by the software manufacturer. An example of a software manufacturer’s signature is an electronic digital signature of a software developer. In this case, the file analysis module 240 marks all files of this software as trusted files 101 and sends the hashes of these files to the list of trusted file hashes, which is in the data cache 230. With this implementation, the module 240 will subsequently have to verify the validity of this digital signature. Module 240 may verify the validity of the software, in particular the digital signature, by making a request to the information service 220, or independently determine the authenticity of the digital signature. In the case of self-determination of authenticity, module 240 may be guided, for example, by a list of valid digital signatures that may be stored on a user's computer.

In the particular case of the implementation, the anti-virus scanner 210, in parallel with checking unknown files 102, may make a request to analyze unknown files 102 to information service 220 in order to check only this file 102 without analyzing whether this unknown file 102 is a key file. In this case, the information service 220 will only respond to the requested unknown file 102.

Figure 3 illustrates a method by which it is possible to implement a system for optimizing anti-virus scanning of files on a disk.

The presented system starts operating while checking the software files in the file system 100. At step 300, the anti-virus scanner 210 starts checking files in the file system 100. At step 305, the anti-virus scanner 210 starts to scan all files in the file system 100. During the check at step 307 antivirus scanner 210 generates a hash of each file being scanned. The generated hash of the scanned file is compared with the list of hashed files of trusted files stored in the data cache 230. If at step 310 the hash of the checked file was found in the data cache 230, then the scanned file is a trusted file 101. The antivirus scanner 210 at step 305 starts analyzing the next file . If, at step 310, the hash of the checked file was not found in the list of hashes of trusted files, then the anti-virus scanner 210 determines that the checked file is an unknown file 102. At step 315, the hash of the unknown file 102 is transferred to the information service 220 using the file analysis module 240, when this execution of this unknown file 102 is blocked until the verification is completed and a decision is made on this file 102. At step 320, the information service 220 checks the received hash of the unknown file 102 for its presence in the database white lists ". If the hash of the unknown file 102 was not found, the analysis of the hash of the unknown file 102 is interrupted and a notification is sent to the anti-virus scanner 210 through the file analysis module 240 that this file is unknown to the information service 220. In turn, the anti-virus scanner 210 starts checking at step 325 given unknown file 102 for security by other means, for example, an emulator. After this check, the anti-virus scanner 210 makes a decision on this unknown file 102 and at step 305 proceeds to scan the next file. If at step 320 the hash of an unknown file 102 was found in the white list database of the information service 210, then the file becomes a trusted file 101, and this file 101 is transferred to step 330 for subsequent analysis. At step 330, it is determined whether the given trusted file 101 for any batch of files is a trusted key file 103 or not. A file package is a collection of files that are associated with a trusted key file 103.

If the trusted file 101 is not a trusted key file 103, then this file is transferred to step 335. At step 335, the information service 220 makes a decision to search for trusted key files 103 with which this trusted file 101 can be associated. The decision on this search is made according to preset file verification settings. When implementing the presented system, presetting is possible both in automatic mode and with the help of the user. It is also possible to replace the preset selection with one of the decisions made. In this case, this system will work only on one of the solutions, depending on the implemented solution.

If a decision was made to search for key files 103, then this file 101 is processed at step 340. At step 340, all known key files 103 that can be associated with this trusted file 101 are searched. At step 345, information about that the requested unknown file 102 is a trusted file 101. In the event that trusted key files 103 associated with the requested file were found, data hashes of trusted key files 103 are transmitted for subsequent search for key file data files 103 in the file system 100. At step 350, the anti-virus scanner 210 searches for the found trusted key files 103. In different implementations, a different search option is possible, for example, search the entire file system 100, or search only the directory in which the requested trusted file 101, or search for trusted key files 103 in the most possible locations, for example, C: / Program Files, etc.

If at step 350 the transmitted hashes of the known key files 103 were not found, then at step 355 only the hash of the verified file 101 is added to the list of trusted file hashes in the data cache 230. If any hash of the transmitted hashes of the trusted key files 103 was found in the file system 100, then this hash is passed to step 360 for further work with this hash of the trusted key file 103.

If at step 335 the anti-virus scanner 210 decided not to search for trusted key files 103 associated with the trusted file 101, then steps 340, 345, and 350 are skipped. For example, this solution is due to the fact that the information service 220 knows for sure that this file is not associated with any trusted key file 103 or, conversely, is associated with too many trusted key files 103. In this case, the information service 220 transfers to the anti-virus scanner 210 informs that the requested unknown file 102 is a trusted file 101, and at step 355, the hash of this file is added to the list of hashes of trusted files in the data cache 230. Then, work with this file 101 and anti-virus ner 210 returns to step 305 where the next file.

If at step 330 the trusted file 101 was determined to be a trusted key file 103, then this trusted file 101 is a trusted key file 103, and the method proceeds to step 360. At step 360, the information service 220 searches for trusted files 101 associated with this trusted key file 103. For example, a search can be performed on the basis of the “white lists”. After that, at step 365, a hash packet of all found trusted files 101 associated with this trusted key file 103 is generated. At step 370, the generated hash package of trusted files 101 is transferred to the list of trusted file hashes, which is located in the data cache 230. When files are subsequently located in file system 100 with these hashes, these files will be excluded from further verification. Then, the anti-virus scanner 210 returns to step 305, where it proceeds to the next file or exits if all requested files for scanning from the file system 100 have been scanned.

Figure 4 illustrates a particular embodiment of a file analysis module 240 and a file verification system for a power of attorney.

In special cases, the file analysis module 240 is part of the claimed system, which was described in FIG. 2. The file analysis module 240 is required to search for unknown files 102 in the background and to analyze unknown files 102 found. In the presented system, the file analysis module interacts with all modules of the given system. Also, the anti-virus scanner 240 can be excluded from the system described in FIG. 2, then the file analysis module 240 will perform functions that relate to working with an unknown file 102, namely, determining whether this file is an unknown key file 104, identifying trusted key 103 and interaction with the information service 220. Also, the file analysis module independently searches for unknown files 102 in the file system 100, adds hash packets of known files 101 to the list of trusted file hashes, located in more data 230. Another function of the file analysis module 240 is to analyze the relevance of the list of trusted files in the data cache 230, i.e. the correspondence of this list of trusted file hashes to the hashes of files from the file system 100.

Figure 4 describes the operation of the file analysis module 240 when searching for unknown key files 104 in the file system 100. Also, the file analysis module determines whether a given file 104 is a trusted key file 103 and adds all the hashes of the trusted files 101 associated with this trusted key file 103, to the list of hashes of trusted files located in the data cache 230. The search is usually carried out in the background so as not to overload the user's computer. The first step 410 is to determine the location of the search for the unknown key file 104. The search can be performed both in all directories of the file system 100 and limited to the most probable location of the key files 103 and 104, for example, in the C: \ Program Files directory. At step 415, the next file from the directories of the file system 100 for verification is selected and transmitted to step 420 each time. At step 420, a search is performed in the data cache 230 of the received file from step 415. At step 420, a check is performed by comparing the hash of the received file with the list of hashed files of trusted files located in the data cache 230. In the event that the file hash was found in this list , then this file is a trusted file 101 or 103 and is skipped, and the file analysis module 240 proceeds to step 415, where the next file is selected. If the hash of the received file was not found in the list of hashes of trusted files, then this file is determined as an unknown file 102 and is passed to step 430. Then, at step 430, the file analysis module 240 determines whether the file 102 is unknown to the key files 104. In the event that this file 102 is not an unknown key file 104, then module 240 skips it and proceeds to step 415. In the event that this file 102 is an unknown key file 104, then file analysis module 240 generates a request for this unknown the key file 104 to information service 220. Information service 220 determines whether a given unknown key file 104 is safe or not. Security is determined, for example, by searching for a file in the whitelist database. As a request, the hash of the unknown key file 104 is transmitted to the information service 220.

In the event that this unknown key file 104 is found in the white list database, then this file 104 will become a trusted key file 103 and module 240 proceeds to step 440. In the event that the unknown key file 104 is not found in the database According to the “white lists”, the work with this file 104 will stop, and the file analysis module 240 will be informed about this, which will return to step 415. This unknown key file 104 will be checked by other analysis tools, for example, signature databases, heuristic analysis.

At step 440, a search is made for all trusted files 101 associated with the found trusted key file 103. Then, at step 450, a packet of hashes 225 of the found trusted files 101 is generated. At step 460, a packet of hashes of trusted files 225 is transferred to the data cache 230. Then, the file analysis module 240 returns to step 415, where it starts analyzing the next file or stops if no more files are found for verification.

In the particular case of implementation, the package of trusted file hashes 225 is transferred to the file analysis module 240. In this case, the file analysis module 240 checks the received package of trusted file hashes 225 for the validity of the hashes of this package 225 in the file system 100. In the event that the received hashes match hashes of files from the file system 100, then the hashes will be added to the list of hashes of trusted files in the data cache 230. In the event that file hashes were not found, then the hashes are deleted.

Figure 5 shows a computer system for which the described invention can be used.

5 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented like any bus structure known in the art, which in turn contains a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26, contains basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating ROM systems 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, " the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer can be equipped with other peripheral output devices (not displayed), for example, speakers, a printer, etc. .

The personal computer 20 is capable of operating in a networked environment, using a network connection with another or several remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the creature the personal computer 20 of FIG. 5. Other devices, such as routers, network stations, peer-to-peer devices, or other network nodes may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In conclusion, it should be noted that the information given in the description are only examples describing the main inventive concept of the author, which do not limit the scope of the present invention to those examples that were mentioned earlier. The above information is primarily intended to solve a narrow problem. Over time and with the development of technological progress, such a task becomes more complicated or evolves. New tools are emerging that are able to fulfill new requirements. One skilled in the art will recognize that there may be other embodiments of the present invention consistent with the spirit and scope of the present invention.

Claims (33)

1. A system for replenishing the list of trusted files in the data cache, which includes:
(a) a data cache designed to store a list of identifiers of trusted files and provide the specified list to the file analysis module;
(b) an information service designed to determine whether a file belongs to trusted key files using the received identifier of the specified file from the file analysis module and, if the file is a trusted key file, transfer the package of identifiers of trusted files associated with this trusted key file to the analysis module files
(c) a file analysis module for:
- search among files in the file system for those files whose identifiers are not in the specified data cache list,
- transfer of at least one file identifier from the found files to the information service,
- adding packages of identifiers of trusted files received from the information service in response to the transmitted identifier in the list of identifiers of trusted files stored in the data cache. 2. The system according to claim 1, which contains an anti-virus scanner that interacts with the data cache and is intended for anti-virus scanning of files of the file system, during which it detects and transfers files whose identifiers are not in the specified list of data cache to the file analysis module. 3. The system of claim 1, wherein the file analysis module is an anti-virus scanner and is intended for anti-virus scanning of file system files, during which it uses a list of trusted files stored in the data cache. 4. The system according to claim 1, where at least the file itself is the file identifier, the hash value of the file, file metadata, identifiers assigned by the file system to each file, or a combination of these entities. 5. The system according to claim 4, where at least the NTFS identifier for the NTFS file system is the identifier assigned by the file system. 6. The system according to claim 1, in which the file analysis module searches for key files in the file system, the identifiers of which are not in the list of identifiers of trusted data cache files, and transfer the identifiers of the found key files to the information service. 7. The system according to claim 1, in which the file analysis module checks the list of identifiers of trusted files stored in the data cache and file system file identifiers. 8. The system according to claim 7, in which if there is no file identifier among the file system file identifiers, this identifier will be removed from the list of trusted file identifiers. 9. The system according to claim 1, in which before adding the package of identifiers of trusted files to the list of identifiers of trusted files, the file analysis module checks the identifiers from the specified package for their presence among file identifiers of the file system. 10. The system according to claim 9, in which the identifier from the package of identifiers of trusted files will not be added to the list of identifiers of trusted files in the absence of the specified identifier among the identifiers of file system files. 11. The system according to claim 1, in which during the installation of the software on the disk, the file analysis module determines the key file from the specified installed software, the identifier of which is not contained in the list of identifiers of trusted data cache files, and transfers the identifier of the found key file to the information service . 12. The system according to claim 1, in which the file analysis module searches for files whose identifiers are not in the list of identifiers of trusted data cache files among file system files:
- in the background;
- during file verification;
- during the installation of new software. 13. The system of claim 1, wherein the trusted slide is a secure file that is known to the information service. 14. The system of claim 1, wherein the key file is a software file that identifies files belonging to the software. 15. The system of claim 14, wherein the key file is at least one of the following file types: an executable file, an installation file, and an archive file. 16. The system of claim 14, wherein the key files are files with names: “setup” or “autorun”. 17. The system of claim 14, wherein the key file is a file signed by an electronic digital signature of a software manufacturer. 18. The system of claim 14, wherein the key file is a file containing a software manufacturer license agreement. 19. The system according to claim 1, in which the information service can be located both on the user's computer and on the remote server. 20. The system according to claim 1, in which the information service, if the file is not a trusted key file, but is a trusted file, then only the identifier of the specified file is transmitted to the file analysis module. 21. The system according to claim 1, in which:
- information service, if the file identifier is not the identifier of the trusted key file, but is the identifier of the trusted file, it generates a package of identifiers of trusted key files with which the specified identifier of the trusted file is associated, and sends the specified package to the file analysis module;
- the file analysis module searches for file identifiers from the received package of identifiers of trusted key files in the file system, and
if at least one of the indicated identifiers is found, the file analysis module requests a package of identifiers of trusted files associated with the identifier found from the information service for the subsequent addition of this package to the list of identifiers of trusted files stored in the data cache. 22. A method for updating the list of trusted files in the data cache, comprising the steps of:
a) receive a file for verification,
b) compare the identifier of the received file with the identifiers contained in the list of identifiers of trusted files,
c) check whether the identifier of the received file is the identifier of the trusted key file, if the identifier of the received file is not contained in the list of identifiers of trusted files,
d) form a package of identifiers of trusted files associated with the identifier of the received file, if the identifier of the received file was defined as the identifier of the trusted key file,
e) add the generated package of identifiers of trusted files to the list of identifiers of trusted files. 23. The method according to item 22, in which further verification of the received file is completed if the identifier of the received file is contained in the list of identifiers of trusted files. 24. The method according to item 22, which checks whether the identifier of the received file is the identifier of the trusted file, if the specified identifier has not been defined as the identifier of the trusted key file. 25. The method according to paragraph 24, in which add the identifier of the received file to the list of identifiers of trusted files, if the specified identifier was defined as the identifier of a trusted file. 26. The method according to item 22, where at least the file itself is the file identifier, the hash value of the file, file metadata, identifiers assigned by the file system to each file, or a combination of these entities. 27. The method of claim 26, wherein the identifier assigned by the file system is at least an NTFS identifier for an NTFS file system. 28. The method according to item 22, in which the trusted file is a secure file and is contained in the "white lists" of antivirus companies. 29. The method according to item 22, in which the key file is a software file with which to identify files belonging to this software. 30. The method according to clause 29, in which the key file is at least one of the following file types: executable file, installation file and archive file. 31. The method according to clause 29, in which the key files are files with the names: "setup" and "autorun". 32. The method according to clause 29, in which the key file is a file signed by an electronic digital signature of the software manufacturer. 33. The method according to clause 29, in which the key file is a file containing a software manufacturer license agreement.

Images