File verification method and device, electronic equipment, computer readable storage medium and computer program product

Abstract

The application provides a file verification method and device, electronic equipment, computer readable storage medium and computer program product, and relates to the technical field of computer security. The method comprises the following steps: querying a first file list in a first cache based on a target file identifier of a target file carried by a file operation request, the first file list in the first cache comprising file identifiers of files that pass security verification; in the case that the target file identifier is queried from the first file list in the first cache, performing an operation requested by the file operation request on the target file; obtaining a first cache duration of the target file identifier; in the case that the first cache duration is greater than a duration threshold, performing first security verification on the target file to obtain a first verification result; and updating the first cache based on the first verification result. The application can effectively balance the contradiction between file security and computer performance consumption.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a document verification method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] In today's digital age, computers have become indispensable tools in people's lives and work. With the rapid development of the internet, cybersecurity issues have become increasingly prominent, with various malicious software, viruses, and hacker attacks emerging one after another, posing serious threats to users' information and property security. Against this backdrop, security software has emerged to provide comprehensive security protection for users' computer systems.

[0003] In related technologies, security software generally adopts an "absolute security" approach, which means scanning and killing all software in the system. While this approach theoretically provides a high level of security, it inevitably sacrifices performance, especially in environments with limited resources. Summary of the Invention

[0004] This application provides a file verification method, apparatus, electronic device, computer-readable storage medium, and computer program product that can effectively balance the contradiction between file security and computer performance.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides a document verification method, including:

[0007] Based on the target file identifier carried in the file operation request, query the first file list in the first cache, wherein the first file list in the first cache includes the file identifiers of files that have passed security verification;

[0008] If the target file identifier is found by querying the first file list in the first cache, the operation requested by the file operation request is performed on the target file;

[0009] Obtain the first cache duration of the target file identifier, wherein the first cache duration is the duration for which the target file identifier is stored in the first file list;

[0010] If the first cache duration exceeds the duration threshold, the target file undergoes a first security verification to obtain a first verification result;

[0011] The first cache is updated based on the first verification result.

[0012] This application provides a document verification device, including:

[0013] The query module is used to query the first file list in the first cache based on the target file identifier of the target file carried in the file operation request, wherein the first file list in the first cache includes the file identifier of the file that has passed the security verification;

[0014] The processing module is configured to perform the operation requested by the file operation request on the target file when the target file identifier is found from the first file list in the first cache;

[0015] The acquisition module is used to acquire the first cache duration of the target file identifier, wherein the first cache duration is the duration for which the target file identifier is stored in the first file list;

[0016] The verification module is used to perform a first security verification on the target file when the first cache duration exceeds the duration threshold, and obtain a first verification result;

[0017] The update module is used to update the first cache based on the first verification result.

[0018] In the above scheme, when the file operation request is an installation request and the file identifier is not found from the first file list, the update module is further configured to perform a first security verification on the target file, and if the target file passes the first security verification, add the target file identifier to the first file list in the first cache; the processing module is further configured to perform the operation requested by the installation request on the target file in response to receiving the installation request for the target file again.

[0019] This application provides an electronic device, including:

[0020] Memory is used to store executable instructions or computer programs.

[0021] The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the file verification method provided in the embodiments of this application.

[0022] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implements the file verification method provided in this application.

[0023] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the file verification method provided in this application.

[0024] The embodiments of this application have the following beneficial effects:

[0025] Upon receiving a file operation request, the system first queries the first file list in the first cache based on the target file identifier. This quickly determines whether the file has passed security verification, avoiding the time and resource consumption caused by repeated verification. When the target file identifier is found in the first cache, the corresponding operation for the file operation request can be executed directly, ensuring the smoothness and consistency of file operations. Subsequently, the first cache duration of the target file identifier is obtained and compared with a duration threshold. If the threshold is exceeded, security verification is re-performed, which can promptly detect files whose security has changed, thus ensuring continuous monitoring of the security of files in the file list. Afterward, by setting a duration threshold and performing security verification on target files whose cache duration exceeds the threshold, the system ensures continuous security monitoring of files in the file list while reducing performance consumption. Finally, the first cache is updated based on the verification results, ensuring the accuracy and timeliness of the first cache. This achieves a good balance between performance consumption and file security, providing users with a safe and reliable file operation environment while efficiently processing file operations, significantly improving the user experience. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the architecture of the document verification system 100 provided in this application embodiment;

[0027] Figure 2 This is a schematic diagram of the structure of the electronic device 500 provided in the embodiments of this application;

[0028] Figure 3 This is a schematic diagram of the document verification method provided in the embodiments of this application;

[0029] Figure 4 This is a flowchart illustrating the document verification method provided in an embodiment of this application;

[0030] Figure 5 This is a flowchart illustrating the document verification method provided in an embodiment of this application;

[0031] Figure 6 This is a flowchart illustrating the document verification method provided in an embodiment of this application;

[0032] Figure 7 This is a flowchart illustrating the document verification method provided in an embodiment of this application;

[0033] Figure 8 This is a flowchart illustrating the document verification method provided in an embodiment of this application;

[0034] Figure 9This is an architecture diagram of the security engine of the security management software provided in the embodiments of this application;

[0035] Figure 10 This is a schematic diagram of large files not collected by VDC according to an embodiment of this application;

[0036] Figure 11 This is a schematic diagram illustrating different functions for allocating memory space provided in the embodiments of this application;

[0037] Figure 12 This is a schematic diagram illustrating the maximum length of data read each time by the local antivirus engine provided in this application embodiment;

[0038] Figure 13 This is a flowchart illustrating the specific processing steps of the document verification method provided in this application embodiment;

[0039] Figure 14 This is an architecture diagram of accessing persistent caching in the boot scenario provided in this application embodiment;

[0040] Figure 15 This is a flowchart of the MD5 and signature verification access to persistent cache provided in the embodiments of this application. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0042] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0043] It is understood that in the embodiments of this application, data such as user information are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0044] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0045] In the following description, the terms “first, second, ...” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first, second, ...” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0046] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0047] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0048] 1) Message-Digest Algorithm 5 (MD5): MD5 is a widely used cryptographic hash function that produces a 128-bit (16-byte) hash value. It is typically used to ensure the integrity of information transmission. In the security field, MD5 is used to verify that a file has not been tampered with.

[0049] 2) Signature Verification: Signature verification refers to using digital signatures to verify the authenticity and integrity of data or files. Signature verification is a core technology in information security, used to identify whether data has been tampered with during transmission.

[0050] 3) Persistent caching: Persistent caching refers to storing data or files on a persistent storage device so that the data can still be quickly accessed and recovered even after the computer restarts or loses power.

[0051] 4) Non-persistent cache: Non-persistent cache is a temporary storage mechanism in a computer used to quickly store and access data in a short period of time, such as storing it in random access memory (RAM). The data is not permanently saved and will be lost once certain conditions are met (such as when the computer is turned off).

[0052] 5) Asynchronous cloud check: This is a security check technology that allows security check tasks to be sent asynchronously to a cloud server for processing. After the server completes the processing, it returns the results, reducing the pressure on the local system.

[0053] 6) Cloud antivirus engine: refers to a security engine that relies on the cloud for virus scanning and removal, also known as the first antivirus engine below, used to enhance the detection capabilities of local security applications on the terminal.

[0054] 7) Local antivirus: This is a security engine used locally on the terminal to process and analyze security threats.

[0055] 8) Security Engine: The security engine is the core component of security software responsible for analyzing, detecting and enforcing security policies. Security engines typically include functions such as malware scanning, real-time detection, and threat detection.

[0056] 9) Virus Detection Center (VDC): A VDC is an organization or system specifically designed to detect the presence of viruses and other malicious software in computer systems, networks, files, or devices.

[0057] 10) Cloud Antivirus Engine: A cloud antivirus engine is a security detection engine that relies on cloud computing technology. It can process large amounts of data in the cloud and provide real-time security services and threat analysis.

[0058] In related technologies, most security software adopts an "absolute security" approach. While this approach theoretically provides a high level of security, it inevitably sacrifices the user's computer performance, especially in environments with limited resources.

[0059] Based on this, embodiments of this application provide a file verification method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can effectively balance the contradiction between file security and computer performance. The file verification method provided in these embodiments can be implemented by a terminal alone, or by a server and a terminal working together. This will be described below.

[0060] The file verification method provided in this application can be applied to various scenarios that require file security verification, such as the following scenarios:

[0061] 1) In everyday security scenarios, such as when users browse web pages, process documents, and watch videos on their computers, the terminal can use the above file verification methods to perform security verification on relevant files on the local terminal in order to protect the terminal and data security in real time and prevent viruses and malicious software from intruding.

[0062] 2) In online shopping scenarios, for example, when users shop online, the terminal can use the above-mentioned document verification methods to verify the security of relevant documents and operating environment required for online transactions, so as to ensure transaction security and prevent the leakage of personal information and the loss of funds;

[0063] 3) Terminal optimization scenarios: For example, when users use a terminal, as the usage time increases, the terminal may experience problems such as slow operation and insufficient disk space. The above file verification methods can reduce the space occupation of file security verification resources, thereby improving the terminal's response speed.

[0064] 4) Software download and installation scenarios, such as when users download and install software from the Internet, in order to ensure that the downloaded software is safe and reliable, the terminal can use the above file verification methods to verify the security of the downloaded software, so as to avoid installing malicious software and thus protect the security of the terminal.

[0065] In some embodiments, after receiving a file operation request, when the terminal determines that security verification of the target file corresponding to the target file identifier carried in the file operation request is required, it can use the terminal's local antivirus engine to perform security verification on the target file, or it can choose to upload the target file to a server and use a cloud antivirus engine to perform security verification on the target file, thereby obtaining the corresponding security verification result. For example, in a file processing scenario, when a user performs modification operations on the content of a target file through the terminal, the terminal can directly use its local antivirus engine to perform security verification on the target file, or it can upload the target file to a server and use a cloud antivirus engine to perform security verification on the target file, thereby ensuring the security of the terminal.

[0066] For example, see Figure 1 , Figure 1 This is a schematic diagram of the architecture of the file verification system 100 provided in this application embodiment. To support a file verification application, such as... Figure 1 As shown, the file verification system 100 includes: server 200, network 300, terminal 400 and database 600. Terminal 400 is connected to server 200 through network 300 and is also connected to database 600. Network 300 can be a local area network or a wide area network, or a combination of both.

[0067] In some embodiments, after receiving a file operation request, the terminal 400 queries a first file list in the database 600 based on the target file identifier carried in the file operation request. If the target file identifier is found in the first file list in the database 600, the terminal 400 executes the operation requested in the file operation request on the target file. Then, the terminal 400 obtains a first cache duration for the target file identifier from the database 600 and determines a corresponding duration threshold. If the first cache duration is greater than the duration threshold, the terminal 400 transmits the target file corresponding to the target file identifier to the server 200 via the network 300 for a first security verification and obtains a first verification result. Afterward, the server 200 transmits the first verification result to the terminal 400 via the network 300, and the terminal 400 updates the content of the database 600 based on the first verification result.

[0068] Example, Figure 1 The server 200 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal 400 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, in-vehicle terminal, etc., but is not limited to these. The terminal 400 and server 200 can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0069] The structure of the electronic device provided in the embodiments of this application will be further described below. Taking the electronic device as a terminal as an example, see... Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device 500 provided in the embodiments of this application. Figure 2 The illustrated electronic device 500 includes at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. The various components in the electronic device 500 are coupled together via a bus system 540. It is understood that the bus system 540 is used to implement communication between these components. In addition to a data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 540.

[0070] The processor 510 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0071] User interface 530 includes one or more output devices 531 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0072] The memory 550 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 550 may optionally include one or more storage devices physically located away from the processor 510.

[0073] The memory 550 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 550 described in this application embodiment is intended to include any suitable type of memory.

[0074] In some embodiments, memory 550 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0075] Operating system 551 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0076] The network communication module 552 is used to reach other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0077] Presentation module 553 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 (e.g., a display screen, a speaker, etc.) associated with user interface 530;

[0078] The input processing module 554 is used to detect and translate one or more user inputs or interactions from one or more input devices 532.

[0079] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A file verification device 555 stored in memory 550 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a query module 5551, a processing module 5552, an acquisition module 5553, a verification module 5554, an update module 5555, a creation module 5556, and an initialization module 5557. These modules are logically connected and can therefore be arbitrarily combined or further separated according to the functions implemented. It should be noted that... Figure 2 For ease of explanation, all the above modules are shown at once, but this should not be interpreted as excluding the implementation of the document verification device 555, which may only include the query module 5551, processing module 5552, acquisition module 5553, verification module 5554, and update module 5555. The functions of each module will be described below.

[0080] The document verification method provided in this application will be specifically described below with reference to the exemplary application and implementation of the terminal provided in the embodiments of this application.

[0081] See Figure 3 , Figure 3 This is a schematic diagram of the document verification method provided in the embodiments of this application, such as... Figure 3As shown, the file verification method in this application includes a first cache located at the application layer and a second cache located at the driver layer. The first cache includes a first sub-cache and a second sub-cache. The first sub-cache includes a first sub-file list, a first cache duration, and a registry. The first sub-file list stores file identifiers of files that have passed security verification by a first antivirus engine. The first antivirus engine is an antivirus engine located on the terminal that performs security verification based on a local virus rule base. The first cache duration stores the storage duration of files that have passed security verification by the first antivirus engine. The registry stores the second file list in the second cache after the terminal is shut down. The second sub-cache includes a second sub-file list and a first cache duration. The second sub-file list stores file identifiers of files that have passed security verification by a second antivirus engine. The second antivirus engine is an antivirus engine located on the server that performs security verification based on a cloud virus rule base. The first cache duration stores the storage duration of files that have passed security verification by the second antivirus engine. The second cache includes a second file list. After the terminal boots up, the second file list is initialized based on the file list stored in the registry in the first sub-cache. After the first sub-file list in the first sub-cache and the second sub-file list in the second sub-cache are updated, the second file list is synchronously updated according to the updated data. Furthermore, the second cache corresponds to the terminal driver. (This will be combined with...) Figure 3 The various structures shown in the diagram illustrate the subsequent steps.

[0082] See Figure 4 , Figure 4 This is a flowchart illustrating the document verification method provided in this application embodiment, which will be combined with... Figure 4 The steps shown are explained.

[0083] It should be noted that, Figure 4 The method illustrated can be executed by various forms of computer programs running on the terminal. These can be dedicated clients for file verification (e.g., antivirus software), scripts, and applets, or clients that integrate software modules for file verification, such as management software (for managing data and optimizing the system) or driver management software (for upgrading or removing drivers). Therefore, the client-side examples used below should not be considered as limiting the embodiments of this application. Furthermore, for ease of description, no specific distinction will be made between the terminal and the client running on it below.

[0084] In step 101, based on the target file identifier of the target file carried in the file operation request, the first file list in the first cache is queried.

[0085] Here, the first list of files in the first cache includes the file identifiers of files that have passed security verification.

[0086] It should be noted that a file operation request refers to an instruction or request issued by a terminal or application to a terminal to perform a specific operation on a file. For example, it can be an instruction or request to create, read, write, modify, or delete a file. The file identifier of the target file carried in the file operation request can be the file name, path, unique identifier, etc., used to specify the specific file to be operated on. In addition, the file operation request can also carry information such as the type of file operation (e.g., create, read) and the parameters of the operation (e.g., the data content to be written).

[0087] As an example, taking the instruction to modify a file as an example, the user submits a file operation request to modify the target file on the terminal. The terminal receives the file operation request to modify the target file and queries the first file list in the first cache (database) according to the target file identifier of the target file carried in the file operation request to confirm the security of the target file. The first file list stores the file identifiers of files that have passed security verification.

[0088] In some embodiments, the first cache is a cache of an application in the terminal. Before performing the query of the first file list in the first cache in step 101, the following processes may also be performed: querying the second file list in the second cache, wherein the second cache is a cache of a driver in the terminal; if a target file identifier is found from the second file list, performing the operation requested by the file operation request on the target file; if no target file identifier is found from the second file list, proceeding to the step of querying the first file list in the first cache. Thus, when a file operation request is received, the system first queries the second file list in the second cache. If the target file identifier is found in the second cache, it means that the relevant information of the target file is already in the driver cache, and the operation can be performed directly on the target file without having to search for it in other caches or storage devices, greatly reducing the time overhead of searching for the file and improving the response speed of file operations. If the target file identifier is not found in the second cache, the system then queries the first file list in the first cache. By analyzing the query mechanism, the characteristics of different caches can be fully utilized, prioritizing the search in caches where data can be accessed faster, further optimizing the file query process and improving the overall efficiency of file operations. In addition, the second cache is the driver cache, and its data volume is relatively small and more targeted. By querying the second cache first, it is possible to quickly determine whether a file operation can be performed in many cases, avoiding unnecessary queries to the first cache, thereby reducing the consumption of computer resources.

[0089] As an example, taking image processing software for processing image files as an example, firstly, the user clicks the "Open" button in the image processing software (such as Paint) and selects an image file named "landscape.jpg". At this time, the image processing software sends a file operation request to the terminal to read "landscape.jpg". The current file operation request carries the target file identifier information of the target file "landscape.jpg" (for example, the full path information of the file "C:\Users\Documents\Photos\landscape.jpg"). Next, after receiving the file operation request, the terminal first queries the second file list in the driver cache (i.e., the second cache) in the terminal. If the target file identifier is found in the second file list, the read operation is performed on the target file "landscape.jpg". If the target file identifier is not found in the second file list, the query is performed in the application cache.

[0090] In some embodiments, the first cache is a persistent cache implemented based on a database, and the second cache is a non-persistent cache. See [link to documentation]. Figure 5 , Figure 5 This is a flowchart illustrating the document verification method provided in an embodiment of this application, as shown below. Figure 5 As shown, during execution Figure 4 Before step 101 shown, you can also perform... Figure 5 Steps 106 to 108 shown will combine Figure 5 The steps shown are explained.

[0091] It should be noted that the first cache is a caching mechanism that uses a database to store data. It has the characteristic of persistence, meaning that the stored data will not be lost due to the terminal being closed, restarted, or crashed. Moreover, there is no time limit for the stored data; it will be stored in the database for a long time until it is explicitly deleted or updated. The second cache is a caching mechanism that does not have the characteristic of persistence. It usually stores data in memory. That is, when the terminal is closed, restarted, or crashed, the stored data will be cleared. Furthermore, the stored data has a time limit; it will be automatically deleted after a certain storage time has elapsed.

[0092] In step 106, in response to a power-on command for the terminal, the file identifiers included in the registry in the first cache are added to the second file list initialized in the second cache.

[0093] Here, the registry is used to store the list of second files in the second cache before the terminal was last shut down.

[0094] As an example, let's consider a personal computer running Windows. The computer has a first cache based on a database and a non-persistent second cache. The registry in the first cache stores a list of second files from the second cache before the last shutdown. When the user presses the power button, a startup command is issued. The first cache is a persistent cache based on a database; even if the computer is shut down, the data stored there will not be lost. Suppose that the user opened the Word document "Project Plan.docx", the Excel spreadsheet "Sales Data.xlsx", and the PDF file "Contract Template.pdf" during the last use of the computer. During use, the file identifiers (e.g., the full file paths) of these files are retained. The file identifiers (including filenames) are stored in the second file list of the second cache. When the user shuts down the computer, the information in the second file list in the second cache is uploaded and saved to the registry of the first cache. During the boot process, the computer initializes the second cache. Since the second cache is a non-persistent cache, the contents of the second file list are empty each time the computer boots up. The computer creates a new second file list for the second cache. In response to the boot operation command, the computer adds the file identifiers contained in the registry of the first cache to the new second file list in the second cache. For example, the file identifiers of "Project Plan.docx", "Sales Data.xlsx" and "Contract Template.pdf" are read from the registry in sequence and added to the second file list of the second cache.

[0095] In step 107, a second security verification is performed on each verified file corresponding to the file identifier in the second file list in the second cache to obtain a second verification result.

[0096] Here, the types of verified files include files that have passed the first security verification and pending files that have passed the first security verification but have not obtained the first verification result.

[0097] It should be noted that a file that passes the first security verification indicates that the file is secure, while a pending file that fails to obtain the first verification result indicates that the security of the file is unknown.

[0098] Following the example above, after the second file list of the second cache is initialized based on the file identifier in the registry, the computer will perform a second security verification on each verified file in the second file list. The second security verification can be performed automatically when the computer is idle, or it can be triggered by the security software at a preset time interval. No specific limitation is made here.

[0099] In step 108, if the second verification result indicates that the verification file has failed the second security verification, the file identifier of the verified file is removed from the second file list in the second cache, and the verified file is masked.

[0100] Continuing with the above example, if "Project Plan.docx" fails the second security verification, the file identifier of "Project Plan.docx" will be removed from the second file list, and the "Project Plan.docx" file will be moved to the quarantine area, prohibiting users from accessing and running the file.

[0101] In summary, the second cache is a non-persistent cache, which is cleared after the terminal is shut down. The first cache, on the other hand, is a persistent cache based on a database. It uses the registry in the first cache to store the list of second files in the second cache before the terminal was last shut down. When the terminal is powered on, the registry information in the first cache is synchronized to the second cache, thereby achieving persistent storage of information in the second cache and ensuring the continuity of file operations. In addition, the second file list in the second cache is subjected to secondary security verification, and the file identifiers corresponding to files with threats are removed from the second file list, thus providing more reliable security protection.

[0102] In some embodiments, when the target file identifier is found in the first or second cache, and the file operation request includes multiple read operation requests for the target file, the following processing can also be performed: allocate a read lock for each read operation request; based on the read lock allocated for each read operation request, concurrently execute the read operations corresponding to the multiple read operation requests on the target file, and release the read lock after the read operations are completed. Thus, concurrent execution of read operations can significantly shorten the target file reading time, thereby improving data processing speed. Furthermore, multiple read operations can be performed in parallel in different threads or processes, reducing resource idle time and improving terminal throughput. In addition, allocating a read lock for each read operation ensures data consistency and integrity when multiple read operations are performed simultaneously.

[0103] It should be noted that a read lock refers to locking the shared data that a read operation request needs to read. It is a synchronization mechanism that allows multiple threads to concurrently read the shared data but prohibits write operations on the shared data. Allocating a read lock for each read operation request means that the thread containing the read operation request acquires the read lock from the shared data, and then multiple read operation requests can use the read lock to concurrently access the shared data.

[0104] As an example, suppose the read operations for target file 1 include read operation 1, read operation 2, and read operation 3. A read lock is added to target file 1 for which read operations need to be performed. First, a thread is allocated for each read operation, where read operation 1 corresponds to thread 1, read operation 2 corresponds to thread 2, and read operation 3 corresponds to thread 3. Next, each thread acquires a read lock from target file 1. The threads coordinate the execution order of the three read operations using the read lock, ensuring that each read operation can correctly read the required data in the event of concurrent read operations. Finally, the read lock is released after the read operation is completed.

[0105] In some embodiments, when the target file identifier is found in the first or second cache, and the file operation request includes multiple write operation requests for the target file, the following processing can also be performed: If there are currently no file operation requests being executed for the target file, identify at least one write operation request to be executed, allocate a write lock for the pending write operation request, execute the write operation corresponding to the pending write operation request on the target file based on the write lock, and release the write lock after the write operation is completed. Thus, by allocating a write lock for the write operation, write operations are only processed when there are currently no file operation requests being executed for the target file, avoiding mutual interference between concurrent write operations. This ensures that each write operation is executed in a stable and interference-free environment, improving the success rate and reliability of write operations. Furthermore, allocating a write lock after identifying the pending write operation request allows multiple write operations to be executed sequentially in a certain order, helping to ensure the logical correctness of the write operations and avoiding errors caused by disordered operation order.

[0106] It should be noted that a write lock refers to locking the shared data that a write operation request needs to modify. This ensures that only one write operation can modify the shared data at any given time, blocking other read and write operations until the current write operation releases the lock. Allocating a write lock to a pending write operation request means that the thread containing the write operation request acquires the write lock from the shared data to prevent other threads from accessing the shared data. Only after the thread completes the write operation and releases the write lock can other threads continue to acquire read or write locks to access the shared data.

[0107] As an example, suppose the current file operation requests for target file 2 include read operation 1, write operation 2, and write operation 3. A write lock is added to target file 2 for which a read operation needs to be performed. Assuming the operation to be performed is write operation 2, if read operation 1 or write operation 3 is currently being performed on the target file, then after the currently executing operation completes and the corresponding read lock or write lock is released, a thread M is allocated for write operation 2. Thread M acquires the write lock from target file 2 and can exclusively access target file 2, using the write lock to perform write operation 2 alone. After completing write operation 2, the write lock is released. If there is no currently executing operation on the target file, then a thread M is directly allocated for write operation 2. Thread M acquires the write lock from target file 2 and can exclusively access target file 2, using the write lock to perform write operation 2 alone. After completing write operation 2, the write lock is released.

[0108] In some embodiments, before performing step 101 above, the following processing may also be performed: querying the application's directory on the terminal for a second specific file that meets preset conditions; using the signature and installation path of the second specific file as the file identifier of the second specific file; and adding the file identifier of the second specific file to a first file list; wherein the preset conditions include at least one of the following: the size of the second specific file is greater than a size threshold; the second specific file has a digital signature signed by a trusted organization; the second specific file has a fixed installation path; and the number of active users of the second specific file is greater than a quantity threshold. In this way, the identifier of the second specific file that meets the preset conditions is directly stored in the first file list. When the second specific file performs file operations, it can be directly allowed to run without security verification, thereby reducing the impact of security verification on computer performance.

[0109] As an example, assuming that file 1 meets the preset conditions, the signature and installation path of file 1 are used as the file identifier of file 1, and the file identifier of file 1 is added to the first file list. The preset conditions may include at least one of the following: the size of file 1 is greater than the size threshold (for example, the size threshold is 30MB, and the size of file 1 exceeds 30MB), the second specific file has a digital signature signed by a trusted organization (for example, the digital signature of file 1 is the digital signature corresponding to an official trusted organization), the second specific file has a fixed installation path (for example, the installation path of file 1 is relatively fixed), and the number of active users of the second specific file is greater than the number threshold (for example, the number of active users of file 1 reaches 1 million).

[0110] In some embodiments, before performing step 101 above, the following processing may also be performed: for files in the directory of the terminal's application, delete the file corresponding to the file identifier in the first file list, and treat the remaining file as a third specific file; perform a sixth security verification on the third specific file whose file size is greater than the size threshold through the second antivirus engine, and add the file identifier of the third specific file that passes the sixth security verification to the first file list.

[0111] In this way, large files in the terminal's application directory are uploaded to the server for security verification by the second antivirus engine. Files that pass the security verification are added to the first file list, thus achieving automated security verification for large files. When performing file operations on large files, and the file identifier of the large file is stored in the first file list, the operation can be directly allowed without security verification, which can effectively reduce the impact of security verification on large file operations.

[0112] As an example, suppose the terminal application's directory contains files 1, 2, 3, and 4. File 1, which is in the first file list, is deleted. Files 2, 3, and 4 are designated as third specific files. File 2 has a size of 50MB, file 3 has a size of 45MB, and file 4 has a size of 10MB. The capacity threshold is 30MB. Files larger than the capacity threshold are then filtered out. Files 2 and 3 are uploaded to the server and undergo a sixth security verification through a second antivirus engine. The file identifier of file 2, which passes the sixth security verification, is added to the first file list.

[0113] In some embodiments, the first cache includes a first sub-cache of a first antivirus engine located in the terminal, and a second sub-cache of a second antivirus engine located in the server. The first sub-cache stores a first sub-file list from the first file list, and the second cache stores a second sub-file list from the first file list. See [link to documentation]. Figure 6 , Figure 6 This is a flowchart illustrating the document verification method provided in an embodiment of this application, as shown below. Figure 6 As shown, Figure 4 In step 101 shown, querying the list of first files in the first cache can be done through... Figure 4 Steps 1011 to 1014 shown will combine Figure 6 The steps shown are explained.

[0114] In step 1011, the target file identifier is queried from the first sub-file list.

[0115] As an example, suppose the terminal receives a file operation request, which carries the target file identifier (e.g., the full path and file name of the target file "Project Planning Document.docx"); firstly, it queries the target file identifier "Project Planning Document.docx" from the first sub-file list in the first sub-cache of the first antivirus engine in the terminal.

[0116] In step 1012, if the target file identifier is found from the first sub-file list, a query result is generated to find the target file identifier from the first sub-file list.

[0117] Following the example above, if the target file identifier of the file "Project Planning Document.docx" is found in the first sub-file list in the first sub-cache of the terminal, then the query result of finding the target file identifier from the first sub-file list is generated.

[0118] In step 1013, if the target file identifier is not found in the first sub-file list, the target file identifier is searched from the second sub-file list.

[0119] Continuing with the example above, if the target file identifier of the "Project Planning Document.docx" file is not found in the first sub-file list in the first sub-cache of the server, then the target file identifier of the "Project Planning Document.docx" file is searched in the second sub-file list in the second sub-cache of the second antivirus engine on the server.

[0120] In step 1014, if the target file identifier is found from the second sub-file list, a query result is generated that retrieves the target file identifier from the second sub-file list.

[0121] Following the example above, if the target file identifier of the file "Project Planning Document.docx" is found in the second sub-file list in the second sub-cache of the server, then the query result of finding the target file identifier from the second sub-file list is generated.

[0122] In summary, the first sub-cachment is associated with the first antivirus engine on the terminal, and the second sub-cachment is associated with the second antivirus engine on the server. The two antivirus engines can provide virus protection from different levels, offering dual protection. The first antivirus engine on the terminal can perform fast queries locally, while the second antivirus engine on the server performs more comprehensive queries based on a large amount of data.

[0123] In some embodiments, if the target file identifier is not found from the second sub-file list, see [link to relevant documentation]. Figure 7 , Figure 7 This is a flowchart illustrating the document verification method provided in an embodiment of this application, as shown below. Figure 7 As shown, during execution Figure 6After step 1014 shown, you can also execute... Figure 7 Steps 1015 to 1019 shown will combine Figure 7 The steps shown are explained.

[0124] In step 1015, the target file is subjected to a third security verification by the second antivirus engine to obtain the third verification result.

[0125] As an example, suppose a user initiates a file operation request for a file named "game_patch.exe", and no corresponding file identifier is found in either the first or second sub-file list. Therefore, a third security verification of the file is triggered by the second antivirus engine on the server. The second antivirus engine on the server first identifies the file type and determines the corresponding virus detection rule base based on the file type. Then, the second antivirus engine compares the file signature of "game_patch.exe" with the corresponding virus detection rule base stored on the server, and determines the third verification result of the third security verification based on the comparison result.

[0126] In step 1016, if the third verification result indicates that the target file has not passed the third security verification, the operation requested by the file operation request is intercepted.

[0127] As an example, suppose the third verification result indicates that the target file has failed the third security verification. This means that the target file has security vulnerabilities and needs to be moved to an isolation area to prevent users from accessing and running the file. It also means that the operations requested by file operation requests related to the target file should be intercepted.

[0128] In step 1017, if the third verification result indicates that the target file has passed the third security verification, the target file identifier is added to the second sub-file list, and the target file is subjected to a fourth security verification through the first antivirus engine to obtain the fourth verification result.

[0129] It should be noted that the virus rule base used in the fourth security verification is different from that used in the third security verification. The two use different antivirus engines, but their security verification methods are similar, both matching the file content with the virus rule base.

[0130] As an example, assuming the third verification result indicates that the target file has passed the third security verification, the file identifier corresponding to the target file is added to the second sub-file list in the second sub-cachment. Then, the first antivirus engine performs a fourth security verification on the target file. The first antivirus engine first identifies the file type of the target file and determines the corresponding virus detection rule base based on the file type. Subsequently, the first antivirus engine compares the file signature of the target file with the corresponding virus detection rule base stored locally, and determines the fourth verification result of the fourth security verification based on the comparison result.

[0131] In some embodiments, step 1017 described above can be implemented as follows: determining a preset read length that matches the input / output performance of the terminal; using a first antivirus engine, sequentially reading data from the target file according to the preset read length, and performing a third security verification based on the data read each time to obtain a third verification result. Thus, since different terminals have different input / output (I / O) performance, determining a preset read length that matches the terminal's I / O performance allows file reading operations to better adapt to the terminal hardware, thereby improving the overall file processing speed.

[0132] As an example, suppose the first antivirus engine reads 4096 bytes of data each time it performs third security verification on the target file, and the preset read length that matches the terminal I / O performance is 512 kilobytes (KB). Then the first antivirus engine reads the data in the target file according to the preset read length of 512 kilobytes (KB).

[0133] In some embodiments, the third security verification is implemented based on a virus rule base. The following processes can be performed on the virus rule base: obtaining the usage frequency of virus rules in the virus rule base; and deleting virus rules with usage frequencies below a usage frequency threshold from the virus rule base. In this way, deleting infrequently used rules can effectively reduce the size of the virus rule base, allowing antivirus software to complete the rule matching process faster when scanning files, thereby improving scanning efficiency and reducing user waiting time. Furthermore, with a smaller rule base, the antivirus software's demand for computer resources during operation will also decrease accordingly, effectively reducing computer resource consumption and allowing the computer to maintain good performance while ensuring security.

[0134] As an example, suppose virus rule base A includes virus rule 1, virus rule 2, virus rule 3, and virus rule 4. Based on historical security verification data, virus rule 1 is used 10 times / day, virus rule 2 is used 3 times / day, virus rule 3 is used 5 times / day, and virus rule 4 is used 20 times / day. Assuming the frequency threshold is 10 times / day, then virus rules with a usage frequency less than the frequency threshold will be deleted from the virus rule base, that is, virus rule 2 and virus rule 3 will be deleted from the virus rule base.

[0135] In some embodiments, before executing step 1017, the following processing may also be performed: in response to multiple initialization operations of the first antivirus engine, determining the target memory space required by the first antivirus engine to perform the multiple initialization operations, and performing the multiple initialization operations based on the target memory space, wherein the target memory space is the maximum value among the historical memory spaces requested multiple times in the initialization operations; in response to the completion of the initialization of the first antivirus engine, releasing the requested target memory space. Thus, by centrally requesting the target memory space, memory resources can be utilized more rationally, and this solution only requests the target memory space once, reducing the number of memory allocations, thereby reducing the computer's memory management overhead and helping to improve the overall performance of the computer.

[0136] As an example, suppose we know from the historical initialization data of the first antivirus engine that function A needs to be executed 41 times, allocating 4 megabytes (MB) of memory space each time, and releasing the memory space after each function execution. Function B needs to be executed 132 times, allocating 260 kilobytes (KB) of memory space each time. Therefore, during the initialization process of the first antivirus engine, we can directly allocate 4 megabytes (MB) of memory and not release it after each function execution. The memory space will only be released after all functions have been executed, thus effectively avoiding the performance problems caused by repeated allocation and release.

[0137] In step 1018, if the fourth verification result indicates that the target file has not passed the fourth security verification, the operation requested by the file operation request is intercepted.

[0138] It should be noted that the specific implementation of step 1018 is similar to that of step 1016. For details, please refer to the implementation of step 1016. It will not be repeated here.

[0139] In step 1019, if the fourth verification result indicates that the target file has passed the fourth security verification, the target file identifier of the target file is added to the first sub-file list.

[0140] As an example, assuming the fourth verification result indicates that the target file has passed the fourth security verification, the file identifier corresponding to the target file is added to the first sub-file list in the first sub-cache.

[0141] In summary, a dual security protection system is formed by using a second antivirus engine for third security verification and a first antivirus engine for fourth security verification. Different antivirus engines employ different detection algorithms, virus databases, and analysis strategies, enabling comprehensive detection of target files from multiple perspectives and significantly increasing the probability of discovering potential threats. After a target file passes security verification, its file identifier is added to both the second and first sub-file lists. When the same file operation request occurs again, the terminal can directly retrieve the file identifier from the cache, improving query efficiency and reducing redundant security verification operations. If a target file fails the third or fourth security verification, the terminal will immediately intercept the requested file operation, protecting the secure and stable operation of the terminal device server.

[0142] In step 102, if the target file identifier is found from the first file list in the first cache, the operation requested by the file operation request is performed on the target file.

[0143] As an example, suppose the file operation request is to perform a read operation on the target file "scenery.jpg". If the target file identifier is found in the first file list in the first cache, then the read operation is performed on the target file "scenery.jpg".

[0144] In some embodiments, if the file identifier is not found in the first file list in the first cache, the following processes can also be performed: perform a fifth security verification on the target file; if the target file fails the fifth security verification, perform a masking process on the target file; if the target file passes the fifth security verification, perform a second mapping process on the file content of the target file to obtain the target file identifier, and add the target file identifier to the first file list in the first cache. Thus, after the target file passes the fifth security verification, its file content is processed by a second mapping process to obtain the target file identifier, and this identifier is added to the first file list in the first cache. The next time there is an operation request for that file, the terminal can directly and quickly retrieve the file identifier from the cache without performing a complex file search and verification process again, greatly improving the response speed of file operations. Furthermore, by caching the file identifier, the repeated processing and verification of file content is reduced, lowering the processing burden on the terminal. Therefore, the terminal does not need to perform complete security verification and content analysis on the file every time; it can directly use the identifier information in the cache for quick judgment, thereby saving terminal resources and improving the overall performance of the terminal.

[0145] As an example, assuming the target file's file identifier is an MD5 hash and a digital signature, a fifth security verification is performed on the target file. If the target file fails the fifth security verification, it indicates that the target file has a security vulnerability and needs to be moved to an isolation area, prohibiting users from accessing and running the target file. If the target file passes the fifth security verification, mapping processing is performed based on the target file's content to calculate the target file's MD5 hash and digital signature, and the target file's MD5 hash and digital signature are added to the first file list in the first cache.

[0146] In some embodiments, if the file operation request is an installation request and no file identifier is found in the first file list, the following processing can also be performed: Perform a first security verification on the target file; if the target file passes the first security verification, add the target file identifier to the first file list in the first cache; in response to receiving another installation request for the target file, perform the operation requested in the installation request on the target file. Thus, for a target file that has already passed the first security verification, after its identifier is added to the first file list, when an installation request for that file is received again, there is no need to perform the complete security verification process again, saving redundant verification steps. The terminal can respond to the installation request for the target file more quickly, accelerating the file installation process.

[0147] As an example, suppose the file operation request is an installation request for a target file, and the target file identifier is not found in the first file list. Before executing the security request for the target file, the target file needs to be verified for security. If the target file passes the first security verification, the target file identifier is added to the first file list. When the installation request for the target file is received again, the installation operation requested by the installation request for the target file can be executed directly.

[0148] In step 103, the first cache duration of the target file identifier is obtained.

[0149] Here, the first cache duration is the duration for which the target file identifier is stored in the first file list.

[0150] It should be noted that the first cache duration of the target file identifier can be directly stored in the first cache, and the first cache duration of the target file identifier can be obtained by directly reading from the first cache; alternatively, the timestamp of the target file identifier added to the first cache can be stored in the first cache, and the first cache duration of the target file identifier can be obtained by calculating the difference between the current timestamp and the timestamp added to the first cache. No specific limitation is made here.

[0151] As an example, let's take storing the first cache duration of the target file identifier directly into the first cache. When the first cache duration of the target file identifier is added to the first cache, it is set to zero. The first cache duration will increase with the storage duration of the target file identifier in the first file list. Assuming that the storage duration of the target file identifier in the first file list is 3 days, the obtained first cache duration of the target file identifier is also 3 days. Let's take storing the timestamp of the target file identifier added to the first cache into the first cache as an example. Assuming that the timestamp of the target file identifier added to the first cache is March 20, 10:15, and the timestamp of obtaining the first cache duration of the target file identifier is March 22, 10:15, then the first cache duration of the target file identifier can be calculated to be 2 days.

[0152] In step 104, if the first cache duration is greater than the duration threshold, the target file is subjected to a first security verification to obtain a first verification result.

[0153] As an example, assuming the first cache duration of the target file is 2 days and the duration threshold is 1 day, the target file is subjected to a first security verification to obtain the corresponding first verification result. The first security verification can be performed automatically when the terminal is idle, or it can be triggered by security software at a preset time interval. No specific limitation is made here.

[0154] In step 105, the first cache is updated based on the first verification result.

[0155] In some embodiments, see Figure 8 , Figure 8 This is a flowchart illustrating the document verification method provided in an embodiment of this application, as shown below. Figure 8 As shown, Figure 4 Step 105 shown can be achieved through... Figure 8 The implementation of step 1051 or step 1052 shown will be combined with Figure 8 The steps shown are explained.

[0156] In step 1051, if the first verification result indicates that the target file has passed the first security verification, the first cache duration is reset to zero.

[0157] As an example, assuming that "Project Plan.docx" passes the first security verification, the first cache duration corresponding to the identifier of the "Project Plan.docx" file is set to zero. This is equivalent to using the file identifier as the newly stored identifier, so that the cache duration reflects the time since the file corresponding to the file identifier last passed the security verification.

[0158] In step 1052, if the first verification result indicates that the target file has failed the first security verification, the target file identifier is removed from the first file list.

[0159] As an example, if the "Project Plan.docx" file fails the first security verification, the file identifier of the "Project Plan.docx" file will be removed from the first file list.

[0160] In summary, when a target file passes the first security verification, the first cache duration is reset to zero. The terminal will then recalculate the security cache time for the target file to ensure continuous security monitoring. Resetting the cache duration to zero prompts the terminal to re-verify the file's security when the cache duration reaches the preset time, promptly detecting changes in file security and ensuring the terminal remains in a secure state. If a target file fails the first security verification, its identifier is removed from the first file list to prevent the terminal from mistakenly treating it as a secure file, thus effectively protecting terminal security.

[0161] In some embodiments, the first cache is a persistent cache implemented based on a database, and the second cache is a non-persistent cache. After executing step 105, the following processing can also be performed: determining the incremental file list of the first file list before the first cache update relative to the updated first file list; adding the file identifiers in the incremental file list to the second file list, wherein the initial second file list in the second cache is obtained after the terminal is powered on, based on the registry update in the first cache, and the registry stores the second file list in the second cache before the terminal was last powered off. In this way, by using the difference between the first file list before and after the first cache update as the incremental file list, the changes that occur in the first file list during the update process can be accurately captured, and the file identifiers corresponding to these changes can be added to the second file list, which helps to maintain data consistency between the first file list and the second file list; in addition, by using incremental updates, only the changed parts need to be updated when updating the second file list, which can effectively improve the speed of data synchronization and updates, reduce user waiting time, and thus improve the user experience.

[0162] As an example, suppose the first file list before the first cache update includes file identifier 1, file identifier 2, and file identifier 3, and the first file list after the first cache update includes file identifier 1, file identifier 2, file identifier 3, and file identifier 4. By comparing the first file list before and after the update, we can obtain the incremental file list as file identifier 4. The second file list includes file identifier 1, file identifier 2, and file identifier 3. By adding the file identifiers from the incremental file list to the second file list, we can obtain the updated second file list as file identifier 1, file identifier 2, file identifier 3, and file identifier 4.

[0163] In some embodiments, performing the file operation request on the target file requires obtaining the target path information of the target file. Before performing the file operation request on the target file, the following processing may also be performed: receiving a path acquisition request for the target file from any process in the terminal, wherein the path acquisition request carries the target file identifier of the target file; querying a hash list in a second cache based on the target file identifier, wherein the hash list is used to store the file identifier and path information of verified files, and the query is implemented based on matching rules, which first match the target file identifier with the file identifiers in the hash list according to length, and then match the file identifiers with the same length as the target file identifier with the target file identifier according to characters; if the target path information matching the target file identifier is found in the hash list, responding to the path acquisition request based on the target path information matching the target file identifier; if the target path information matching the target file identifier is not found in the hash list, performing a first mapping process on the target file identifier to obtain the target path information matching the target file identifier, adding the target file identifier and the target path information corresponding to the target file identifier to the hash list, and responding to the path acquisition request based on the target path information matching the target file identifier. Thus, by querying the target file identifier based on matching rules in the hash chain of the second cache, the computer can quickly locate the path of the target file among a large amount of verified file information, reducing query time and improving the efficiency of the computer's response to the path acquisition request of the process. In addition, by storing the file identifier of the verified file in the hash table, subsequent requests can directly obtain the target path information from the hash chain, without having to repeat the complex path lookup operation, which greatly reduces the overhead of repeated queries and improves the overall query efficiency.

[0164] As an example, assume that a user uses office software A to edit the target file "Project X Proposal.docx". At this time, office software A, as a process, needs to obtain the storage path of the target document to perform operations such as saving and reading. Software A sends a path acquisition request to the terminal, where the request carries the target file identifier of the target file "Project X Proposal.docx", for example, a unique character string "PRJ_X_PROPOSAL_DOCX"; after receiving the path acquisition request, the terminal queries the target file identifier from the hash linked list in the second cache, where the hash linked list stores the file identifiers of previously verified files and corresponding path information; then, the terminal matches the target file identifier "PRJ_X_PROPOSAL_DOCX" with all the file identifiers in the hash linked list by length. For example, the hash linked list includes three file identifiers: "REPORT_2024_01_DOCX", "PRJ_Y_PROPOSAL_DOCX", and "PRESENTATION_2024_01_PPTX". Through length matching, it can be obtained that "PRJ_Y_PROPOSAL_DOCX" has the same length as the target file identifier "PRJ_X_PROPOSAL_DOCX". Then, character matching is performed between the length-matched "PRJ_Y_PROPOSAL_DOCX" and the target file identifier "PRJ_X_PROPOSAL_DOCX", so as to obtain that there is no file identifier matching the target file identifier "PRJ_X_PROPOSAL_DOCX" in the hash linked list. In this case, a first mapping process is performed on the target file identifier to obtain the target path information matched by the target file identifier, and the path acquisition request is responded to according to the obtained target path information, where the first mapping process may be obtained through processing according to a preset rule; if there is a file identifier "PRJ_X_PROPOSAL_DOCX" in the hash linked list, the target path information of the target file can be directly obtained as "D:\Projects\Project X\Proposal.docx" according to the mapping relationship of the hash linked list, and the path acquisition request is responded to according to the obtained target path information.

[0165] In some embodiments, before performing the operation requested by the file operation request on the target file, the following processing may also be performed: creating a blocking directory entry for each first specific file that needs to be blocked, wherein the blocking directory entry includes the file identifier of the first specific file; in response to the file operation request of the first specific file, querying the pre-created directory entry, and if the file identifier of the first specific file is found in the blocking directory entry, refusing to respond to the file operation request corresponding to the first specific file, and blocking the first specific file. Thus, by creating blocking directory entries for the first specific files that need to be blocked, when these files initiate operation requests, the computer can quickly identify and refuse to respond, effectively preventing further operations by malicious files, thereby ensuring computer security.

[0166] It should be noted that the first specific file to be blocked can be a file that poses a security threat, such as a Trojan script; or it can be a file with access restrictions, such as a file that is only accessible to administrators. When a regular user makes an access request to the file, the access request should be refused. No specific restrictions are made here.

[0167] As an example, suppose we need to block a file named "Core Product Development Plan.docx". A block entry is created for this file, containing its unique file identifier, which we'll assume is "89abcdef12345678" generated from the file's hash value. When the terminal receives a file operation request for this file, it queries the pre-created block entry and finds the block entry with the identifier "89abcdef12345678". Because the file identifier is found in the block entry, the terminal will refuse to respond to the file operation request. Simultaneously, the terminal will block the "Core Product Development Plan.docx" file, for example, by adding it to an isolation zone and automatically withdrawing any file operation requests for it.

[0168] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario. This exemplary application describes the specific implementation process of the file verification method in a file security verification scenario.

[0169] In the uninstallation feedback of security management software, 25% of users uninstalled the software mainly because of the decline in computer performance. In order to improve the user experience, this application effectively solves the problem of computer lag that may be caused by security management software without sacrificing security.

[0170] In related technologies, most security software adopts an "absolute security" approach. While this approach theoretically provides a high level of security, it inevitably sacrifices the user's computer performance, especially in resource-constrained environments. Therefore, this application combines persistent caching with asynchronous cloud query technology to better balance security and performance. This approach effectively improves computer operating efficiency while ensuring computer security. Persistent caching reduces redundant security checks, alleviating the burden on the local computer, while asynchronous cloud query technology performs security checks in the background without consuming excessive computer resources, thus not affecting the user experience.

[0171] In the field of providing client software to users, software performance and security are considered the most critical evaluation criteria. Ensuring the stability of software operation is of paramount importance. Minimizing the impact on users' computer performance without sacrificing security is a major challenge in current technology development. Therefore, in the development of terminal security software, reasonably balancing security and computer performance is the core content of the design and implementation process.

[0172] Based on this, this application significantly improves the efficiency of security detection and reduces the consumption of terminal resources by optimizing the security engine at the technical level, without affecting the user's daily experience.

[0173] In some embodiments, see Figure 9 , Figure 9 This is an architecture diagram of the security engine of the security management software provided in the embodiments of this application, such as... Figure 9 As shown, taking the file verification method of this application implemented by security management software running on the terminal as an example, the security management software mainly includes five key parts from the bottom layer to the top layer: driver layer, policy layer, cache layer, engine layer, and background. The optimization of the security engine of the security management software in this application mainly involves four levels: driver layer, policy layer, cache layer, and engine layer. The following will explain each level in detail:

[0174] (1) Driver layer optimization: ① Driver callback: Improve the callback mechanism of the driver layer to reduce the occupation of terminal resources and improve the response speed; ② Driver cache: Enhance driver cache management to reduce the impact of repeated operations on computer performance.

[0175] (2) Strategy layer optimization: ① Filtering strategy: Adjust and optimize the filtering rules in the main defense strategy to improve filtering efficiency and reduce false blocking; ② Local rule base for file detection: Based on file signature and file path

[0176] (3) Cache layer optimization: ① Cloud antivirus engine cache: By introducing persistent caching, the local caching capability of the cloud search function is enhanced to speed up the inspection and reduce the network load; ② Local antivirus engine cache: By optimizing the local antivirus engine cache, the speed and efficiency of data processing are improved; ③ Unknown large file cache: A special caching strategy is introduced for large unknown files to improve the speed and security of file verification; ④ MD5 / signature cache: By optimizing the caching mechanism of MD5 and digital signature, the speed and security of file verification are improved; ⑤ File detection driver cache update: By updating the caching mechanism of the file detection driver, the latestness and validity of the data can be ensured.

[0177] (4) Engine layer optimization: By adding the function of uploading large sample data, threat data can be collected and analyzed more comprehensively, thereby improving the overall detection capability of the software.

[0178] The aforementioned optimization measures work together at different levels of the security engine to improve the overall security performance of the security management software while reducing the impact on the user's computer performance. Through these technical improvements, users can enjoy a faster and safer user experience.

[0179] In some embodiments, the above-mentioned different levels of optimization can be achieved through three parts: basic optimization, persistent caching, and multi-scenario access to persistent caching.

[0180] At the basic optimization level, the main aspects involved are large software whitelisting mechanisms, driver lag optimization, and local antivirus engine optimization. The large software whitelisting function allows the terminal to automatically identify and simplify security rules for large software applications, thereby reducing the burden on computer performance. Driver lag optimization, guided by existing performance metrics, optimizes the driver callback mechanism of security management software to reduce the response time of certain programs, thus reducing the impact on the terminal. Local antivirus engine optimization reduces memory usage and optimizes I / O read operations, thereby reducing the consumption of computer resources.

[0181] The large software whitelist mechanism comprises two parts: automatic terminal identification of common large software and automatic collection of large files for whitelisting. In the automatic identification of common large software, the terminal automatically identifies common large software based on specific rules. Lightweight security rules minimize the impact on large software. Common large software (such as office software and games) exhibits the following four main characteristics: ① The size of a single DLL file exceeds 30MB, making it difficult for the background to collect large files, thus affecting the cloud antivirus engine's ability to add the software to the whitelist; ② The software usually contains an official digital signature; ③ The software's installation path is relatively fixed, exhibiting a recognizable characteristic path pattern; ④ The software has a large number of installed users with high user activity. Based on these characteristics, software can be added to the whitelist based on its digital signature and path information. Software on the whitelist can be directly allowed to run, reducing the performance impact of file security scanning by the cloud antivirus engine and local antivirus engine. In the section on automatically collecting and whitelisting large files, files larger than 30 megabytes (MB) are collected to bypass the scanning restrictions of the Virus Detection Center (VDC). Large files belonging to office software are automatically added to the whitelist through the following steps: First, large files are collected based on their path characteristics, and files already in the whitelist are filtered out. Next, the filtered large files are added to a dedicated forced upload list. Finally, the large files in the forced upload list are uploaded to the server, where they undergo a security scan. Files that pass the security scan are automatically added to the whitelist. See also... Figure 10 , Figure 10 This is a schematic diagram of large files not collected by the VDC provided in the embodiments of this application, such as... Figure 10 As shown, by automatically collecting large files and adding them to the whitelist as described above, large files larger than 30MB can be collected periodically and added to the whitelist.

[0182] The key to driver stuttering optimization is to optimize the callback time of driver interfaces while ensuring driver functionality is stable, thereby reducing the impact of security management software drivers on the terminal. Driver stuttering optimization mainly includes optimization of the self-protection driver qqsysmon, the TOAccelerator driver, and the interception process method of Little Rocket.

[0183] The optimization of the self-protection driver qqsysmon includes three parts: optimization of process path acquisition logic, optimization of process linked list structure, and optimization of rule matching mechanism. These are explained in detail below.

[0184] In the process path acquisition logic optimization section, during the process startup phase, the terminal triggers a specific event or function. When process startup is detected, the driver calls a dedicated function to obtain the process's path information. For example, in the terminal, functions like PsGetProcessImageFileName can be used to obtain the executable file path of the process. The obtained process path information is stored in a specially designed cache data structure. This cache can be a hash table or an array, using the process's unique identifier (such as process ID) as the key and the process path as the value. When other components (such as security detection modules, detection modules, etc.) need to obtain the path of a process, they only need to look it up in the cache using the process ID, without having to perform a complex path acquisition operation again. When a process needs to be destroyed, the terminal triggers another event, and the driver deletes the corresponding path information from the cache based on the process ID, releasing cache space and preventing memory leaks.

[0185] In the process linked list structure optimization section, the original singly linked list structure connects each node sequentially. When searching for a process, it is necessary to traverse the list one by one from the head, with a time complexity of O(n). To improve the query speed, the driver program converts the storage structure from a singly linked list to a hash linked list. First, a hash function is defined to map a certain feature of the process (such as process ID) to a certain position in the hash table. Each slot in the hash table corresponds to a linked list. Process nodes with the same hash value are inserted into the corresponding linked list. Due to the effect of the hash function, processes can be evenly distributed in each linked list, thereby significantly shortening the length of each linked list. When querying a specific process, the slot where the process is located can be calculated through the hash function, and then the search can be performed in the corresponding linked list. The average time complexity can be reduced to O(1), significantly speeding up the process search.

[0186] In the optimization of the rule matching mechanism, the original rule matching logic was a simple string matching, comparing each character of the rule string and the target string one by one, which was inefficient. The matching mechanism in this application uses a method of first matching by length, and then comparing strings of the same length. When rule matching is required, the driver first obtains the lengths of the rule string and the target string. If the lengths are not equal, a mismatch can be directly determined, avoiding unnecessary character comparisons. For strings of equal length, a character-by-character comparison is then performed. This rule matching method can eliminate a large number of mismatches in advance, reducing the number of character comparisons and improving matching efficiency and accuracy. For example, when detecting whether a process path conforms to certain security rules, the lengths of the path strings are compared first, and only when the lengths are equal are detailed character comparisons performed.

[0187] The optimizations to the TAOAccelerator driver include two parts: improvements to the locking mechanism and optimizations to the linked list structure.

[0188] In the section on improving the locking mechanism, the locking mechanism for process control is replaced by a read-write lock instead of a non-read-write lock. The read-write lock allows multiple threads to perform read operations simultaneously, but it holds the lock exclusively when performing write operations. When multiple threads need to read shared resources, they can acquire read locks simultaneously, improving the efficiency of concurrent reading of processes. When a thread needs to write to a shared resource, it can request a write lock, at which point other threads (whether read or write threads) must wait to ensure data consistency.

[0189] In the linked list structure optimization section, the linked list structure is changed from a singly linked list to a multi-linked list. Elements can be divided into different linked lists based on a certain characteristic (such as process priority, type, etc.). For example, high-priority processes can be placed in one linked list and low-priority processes in another linked list. When searching for an element, the linked list in which the element belongs is first determined based on the element's characteristics, and then the search is performed in the corresponding linked list, which shortens the length of the linked list that needs to be searched, thereby improving the element search speed.

[0190] The process interception method of the Little Rocket driver is optimized by replacing the registry callback method with file I / O. The driver interacts with the process through the terminal. Specifically, the driver creates a special file or directory in the terminal, with each process to be intercepted corresponding to a directory entry. When a process needs to be intercepted, the driver writes specific identification information into the corresponding directory entry. The process itself periodically checks the status of the directory entry. When the specific identification information is detected, the process will exit automatically, avoiding frequent registry operations, reducing the impact on the computer, and improving the computer's response speed.

[0191] Local antivirus engine optimization mainly includes two aspects: memory usage optimization and I / O read optimization. For memory usage optimization, see [link to relevant documentation]. Figure 11 , Figure 11 This is a schematic diagram illustrating different functions for allocating memory space provided in the embodiments of this application, such as... Figure 11As shown, during the initialization of the local antivirus engine, memory may be repeatedly allocated and released depending on the function. For example, the function `tpktt.dll! mwmSearchForGenLib` is executed 41 times during the initialization process, allocating 4MB of memory each time and releasing it after use; the function `tpktt.dll! avbase::CTSCacheFile::CommitCache` is executed 132 times during the initialization process, allocating 260KB of memory each time and releasing it after use. To address the issue of repeatedly allocating memory, the maximum usable memory can be allocated directly the first time, and then used directly in subsequent function executions. For example, 4MB of memory can be allocated initially and reused in subsequent functions. The memory space can then be released only after the last function has finished executing, thus avoiding the performance issues caused by repeated allocation and release. In addition, to optimize memory usage, the virus rules can be categorized according to their functions by analyzing the virus database loaded by the local antivirus engine, as shown in Table 1. Table 1 is a table of attributes of different virus rules in the virus database. As shown in Table 1, by analyzing the rule database loaded by the local antivirus engine, it can be found that virus rules of webshell, Linux, Android, and Mac are basically not used in Windows systems. Therefore, virus rules that are not applicable to Windows can be optimized out, which can effectively reduce the computer's memory usage.

[0192] Table 1. Rule attributes of different viruses in the virus database

[0193]

[0194]

[0195] Regarding I / O read optimization, the local antivirus engine needs to read samples into memory for judgment when performing rule-based analysis on file content. See [link / reference]. Figure 12 , Figure 12 This is a schematic diagram illustrating the maximum length of data read each time by the local antivirus engine provided in this application embodiment, as shown below. Figure 12 It can be seen that when the local antivirus engine executes local policies on samples, the single data read length is 4096 bytes. Under normal circumstances, the optimal threshold for disk I / O read is 512KB. It can be seen that the single data read length does not maximize the performance of disk I / O. Therefore, the single data read length of the local antivirus engine is adjusted to 512KB.

[0196] The persistent caching layer mainly involves two aspects: database selection and accessing the scan results of local antivirus engines and cloud antivirus engines to the WCDB database.

[0197] When selecting a database, we primarily focused on three aspects: support for complex queries, user-friendliness, and performance. See Table 2, which compares the performance of different databases. As shown in Table 2, commonly used databases in PC clients include structured and unstructured storage. For structured storage, we selected SQLite and WCDB. SQLite is a lightweight relational database that supports complex queries, rated two stars for ease of use and four stars for performance, meaning it is relatively easy to use and performs well. WCDB is a mobile database based on SQLite, also supporting complex queries, rated five stars for both ease of use and performance, meaning it is very easy to use and performs excellently. For unstructured storage, we selected LevelDB and MMKV. LevelDB is a high-performance key-value store that does not support complex queries, but both its ease of use and performance are five stars, meaning it is very easy to use and performs extremely well. MMKV is a key-value store based on mmap memory mapping, also not supporting complex queries, but both its ease of use and performance are five stars, meaning it is user-optimized and performs well.

[0198] Table 2: Performance Comparison Table Between Different Databases

[0199]

[0200] Based on the above comparisons, both SQLite and WCDB are structured relational databases that support complex queries, but WCDB excels in ease of use and performance. LevelDB and MMKV are both unstructured key-value stores that do not support complex queries, but they also perform well in terms of ease of use and performance. Taking all these factors into consideration, WCDB, a structured storage solution, was ultimately chosen as the storage object for the persistent cache.

[0201] In some embodiments, database performance testing is conducted from two dimensions: data volume and data read / write method. For the data volume dimension, 100,000 and 1 million data volumes are selected for comparison. For the read / write method, three dimensions are compared: single-threaded read / write (1 thread for reading and writing), multiple reads and multiple writes (2 threads for reading and 2 threads for writing), and single read and single write (1 thread for reading and 1 thread for writing).

[0202] Refer to Table 3, which compares the performance of different databases and read / write methods for data volumes of 100,000 records. As shown in Table 3, for data volumes of 100,000 records, the SQLite-off mode takes 7776ms for multi-threaded writes and 8366ms for reads; the WCDB-WAL-encrypted mode takes 1068ms for multi-threaded writes (an 86.27% performance improvement) and 552ms for reads (a 93.4% performance improvement).

[0203] Table 3. Performance Comparison of Different Databases with Different Read / Write Methods at the 100,000-user Level

[0204]

[0205]

[0206] See Table 4, which compares the performance of different databases and read / write methods for 1 million data entries. As shown in Table 4, for 1 million data entries, the SQLite-off mode takes 152,762 ms to write 1 million data entries and 149,625 ms to read; the WCDB-WAL-encrypted mode takes 3,382 ms to write 1 million data entries, a performance improvement of 97.8%, and 2,167 ms to read, a performance improvement of 98.5%.

[0207] Table 4. Performance Comparison of Different Databases with Different Read / Write Methods at the 100W Level

[0208]

[0209]

[0210] In summary, using the wcdb-wal-encrypted mode in multi-threaded write scenarios can improve read performance by at least 90% and write performance by at least 85% compared to the previous sqlite-off mode.

[0211] Regarding the integration of scan results from local and cloud antivirus engines into the WCDB database, the security management software's scanning engines are divided into local and cloud antivirus engines. Both local and cloud antivirus engines have caching mechanisms. The local antivirus engine's caching is designed to prevent multiple scans of the same file within a short period, which would cause performance degradation. The local antivirus engine's cache limit is 500 entries, and the cache validity period is 10 minutes. Furthermore, it is a memory cache, which will be invalidated when the terminal or process is restarted. The cloud antivirus engine's caching is designed to prevent multiple cloud scans of the same sample within a short period, which would increase the waiting time for driver uploading (driver uploading refers to the process where, after the driver layer detects a new file, it sends the file to the application layer for security scanning). The gray sample cache validity period is 5 minutes, and the white sample cache validity period is 14 days. Therefore, both the local antivirus engine cache (memory cache) and the cloud antivirus engine cache were changed to persistent cache, using WCDB as the cache database. Here, white samples refer to application software with reliable digital signatures and passed security tests (e.g., software with a formal digital signature from a large company); gray samples refer to application software whose spread exceeds the spread threshold in a short period of time, but whose security is unknown (e.g., a software recently released by a company); unknown samples refer to niche software developed by some users (e.g., .exe script files independently created by individual users), whose security is unknown; and black samples refer to software that has not passed security verification and has security vulnerabilities.

[0212] See Figure 13 , Figure 13 This is a flowchart illustrating the specific processing steps of the document verification method provided in this application embodiment, such as... Figure 13 As shown, it will be combined Figure 13 The specific processing flow of the file verification method is explained in detail.

[0213] In step 201, file read / write / delete operations are performed.

[0214] Here, when the underlying driver detects file read / write / delete operations, step 202 is executed.

[0215] In step 202, the driver cache is queried.

[0216] Here, if the file identifier corresponding to the file is found, proceed to step 214; if the file identifier corresponding to the file is not found, proceed to step 203.

[0217] In step 203, the local antivirus engine cache is queried.

[0218] Here, if the file identifier corresponding to the file is found, proceed to step 212; if the file identifier corresponding to the file is not found, proceed to step 204.

[0219] In step 204, the cloud antivirus engine cache is queried.

[0220] Here, if the file identifier corresponding to the file is found, proceed to step 210; if the file identifier corresponding to the file is not found, proceed to step 205.

[0221] In step 205, the cloud antivirus engine performs a synchronous scan.

[0222] Here, after the cloud antivirus engine completes the synchronous scan, the scan results are obtained, and then step 206 is executed.

[0223] In step 206, the scan results are queried.

[0224] Here, if the scan result indicating file is a black sample, then step 209 is executed; if the scan result indicating file is a non-black sample, then steps 218 and 207 are executed.

[0225] In step 207, the local antivirus engine performs a synchronous scan.

[0226] Here, after the local antivirus engine completes the synchronous scan and obtains the scan results, proceed to step 208.

[0227] In step 208, the scan results are queried.

[0228] Here, if the scan result indicating file is a black sample, then proceed to step 209; if the scan result indicating file is a non-black sample, then proceed to step 218.

[0229] In step 209, the driver intercepts.

[0230] Here, driver interception includes moving the file to an isolation zone, prohibiting users from accessing and running the file, and terminating the operations requested by file operation requests related to the target file.

[0231] In step 210, file attributes are determined.

[0232] Here, if the file attribute is a white sample, then proceed to step 211; if the file attribute is a gray sample, then proceed to step 215.

[0233] In step 211, the cache duration is queried.

[0234] Here, if the cache duration exceeds 15 days, proceed to step 216; if the cache duration does not exceed 15 days, proceed to step 214.

[0235] In step 212, the cache duration is queried.

[0236] Here, if the cache duration exceeds 10 minutes, proceed to step 219; if the cache duration does not exceed 10 minutes, proceed to step 214.

[0237] In step 213, the driver cache is updated.

[0238] Here, the file identifier stored in the driver cache is updated.

[0239] In step 214, the vehicle is allowed to proceed.

[0240] Here, the driver allows the file operation in step 201 to be performed.

[0241] In step 215, the cache duration is queried.

[0242] Here, if the cache duration exceeds 12 hours, proceed to step 216; if the cache duration does not exceed 12 hours, proceed to step 214.

[0243] In step 216, the file identifier is removed from the cloud antivirus engine cache.

[0244] Here, after deleting the file identifier from the cloud antivirus engine cache, proceed to step 217.

[0245] In step 217, the cloud antivirus engine performs an asynchronous scan.

[0246] Here, after obtaining the scan results through asynchronous scanning using the cloud antivirus engine, step 218 is executed.

[0247] In step 218, the cloud antivirus engine cache is updated.

[0248] Here, after updating the cloud antivirus engine cache based on the scan results, proceed to step 214.

[0249] In step 219, the file identifier is removed from the local antivirus engine cache.

[0250] Here, after removing the file identifier from the local antivirus engine cache, proceed to step 220.

[0251] In step 220, the local antivirus engine performs an asynchronous scan.

[0252] Here, after obtaining the scan results through asynchronous scanning using the local antivirus engine, step 221 is executed.

[0253] In step 221, the local antivirus engine cache is updated.

[0254] Here, after updating the local antivirus engine cache based on the scan results, proceed to step 214.

[0255] It should be noted that in the file verification process of related technologies, the local antivirus engine cache is a memory cache, not a persistent cache, and its validity period is short (e.g., only 10 minutes) and the upper limit is small (e.g., 500 entries). The cloud antivirus engine scan has a short cache validity period for white files (e.g., 14 days) and a short cache validity period for gray files (e.g., only 5 minutes). Therefore, to address the cache time limit issues of cloud antivirus engine cache and local antivirus engine cache, this application adopts a persistent caching method for both cloud antivirus engine cache and local antivirus engine cache, which can effectively solve the above-mentioned validity period issues.

[0256] In the context of multiple scenarios involving persistent caching layers, after building the persistent cache, to ensure maximum optimization effect, the optimization targets were selected as the boot scenario, MD5 and signature verification, and installation package interception scenario in the main defense.

[0257] In a boot-up scenario, persistent caching is implemented, specifically for the driver cache. The driver cache is a kernel-level cache, a memory-level cache, which is cleared when the terminal is shut down. The persistent cache, on the other hand, is an application-level cache and is unaffected by power on / off cycles. See also... Figure 14 , Figure 14 This is an architecture diagram of accessing persistent caching in the boot scenario provided in this application embodiment, such as... Figure 14 As shown, in the boot scenario, since the cache has not been established, the file list in the driver cache is empty. The files need to be transferred to the application layer for scanning, and a scan result cache needs to be established based on the scan results. Therefore, when the terminal is shut down, the driver cache before the terminal shutdown is saved to the registry of the application layer persistent cache. After the terminal is booted up, the driver cache can be updated according to the cache content in the application layer persistent cache registry.

[0258] It should be noted that because some files may be converted from gray samples to blacklists or unknown samples to blacklists, not all files entering the driver cache are safe. Therefore, to ensure the security attributes of the samples in the driver cache, the list data in the driver cache needs to be uploaded to the server for asynchronous scanning after the terminal boots up. If a file is detected as risky, it is removed from the driver cache and intercepted.

[0259] In scenarios where MD5 and signature verification are integrated into persistent caching, the public library of security management software provides interfaces for calculating file MD5 and file signatures. Each MD5 and file signature calculation requires the complete file content, generating a large amount of disk I / O, thus impacting CPU performance. See also Figure 15 , Figure 15 This is a flowchart of the MD5 and signature verification access to persistent cache provided in the embodiments of this application, such as... Figure 15As shown, after the MD5 and signature verification are integrated into the persistent cache, firstly, step 301 is executed to obtain the file's MD5 / signature. Then, step 302 is executed to check if there is an MD5 / signature in the cache. If the MD5 / signature is stored in the cache, step 304 is executed to return the MD5 / signature. If the MD5 / signature is not stored in the cache, step 303 is executed to calculate the file's MD5 / signature, and step 305 is executed to store the file's MD5 / signature in the cache and step 304 is executed to return the MD5 / signature.

[0260] In scenarios where endpoint protection's installation package interception is included in persistent caching, MMKV is introduced as a persistent cache for endpoint protection's installation package interception processing. For the same installation package, file format parsing and scanning are only performed during the first interception. After a successful scan, subsequent interceptions of that installation package do not require scanning. Here, endpoint protection refers to real-time monitoring of various activities on the endpoint, analyzing them based on pre-defined rules and behavioral patterns to determine whether the operations performed on the endpoint pose potential dangers.

[0261] This application significantly improves user experience without sacrificing security through persistent caching and asynchronous scanning technologies, a stark contrast to the "security first, absolute security" file verification philosophy of related technologies. By introducing WCDB as a persistent cache, this application integrates key scenarios such as file detection, terminal boot, MD5 and signature verification, and main protection against installation package interception into the persistent cache. This results in significant improvements in the startup speed of large software, terminal resource consumption, boot speed, and driver lag. For example, the startup time of Unity software is reduced by approximately 50%; the main protection memory usage of the security management software is reduced from 167.66M to 80.96M, a performance improvement of 51.7%; and driver lag issues are significantly reduced from 2134 times to 429 times, a performance improvement of 79.9%. Furthermore, this application significantly improves user experience without sacrificing security through persistent caching and asynchronous scanning technologies, a stark contrast to the "security first, absolute security" philosophy of security engines in related technologies.

[0262] The following description continues to illustrate the exemplary structure of the document verification device 555 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the file verification device 555 of the memory 550 may include: a query module 5551, a processing module 5552, an acquisition module 5553, a verification module 5554, and an update module 5555.

[0263] The query module 5551 is used to query the first file list in the first cache based on the target file identifier of the target file carried in the file operation request, wherein the first file list in the first cache includes the file identifiers of files that have passed security verification; the processing module 5552 is used to perform the operation requested by the file operation request on the target file if the target file identifier is found in the first file list in the first cache; the acquisition module 5553 is used to acquire the first cache duration of the target file identifier, wherein the first cache duration is the duration for which the target file identifier is stored in the first file list; the verification module 5554 is used to perform a first security verification on the target file if the first cache duration is greater than the duration threshold, and obtain a first verification result; the update module 5555 is used to update the first cache based on the first verification result.

[0264] In some embodiments, the query module 5551 is further configured to query a second file list in a second cache, wherein the second cache is a cache of the driver in the terminal; the processing module 5552 is further configured to perform the operation requested by the file operation request on the target file if the target file identifier is found from the second file list; if the target file identifier is not found from the second file list, the process proceeds to the step of querying the first file list in the first cache.

[0265] In some embodiments, the first cache is a persistent cache implemented based on a database, and the second cache is a non-persistent cache. The update module 5555 is further configured to determine the incremental file list of the first file list before the first cache is updated relative to the updated first file list; and add the file identifiers in the incremental file list to the second file list. The initial second file list in the second cache is obtained by updating the registry in the first cache after the terminal is powered on. The registry stores the second file list in the second cache before the terminal was powered off last time.

[0266] In some embodiments, the first cache is a persistent cache implemented based on a database, and the second cache is a non-persistent cache. The update module 5555 is further configured to, in response to a power-on operation command for the terminal, add the file identifiers included in the registry in the first cache to the initialized second file list in the second cache, wherein the registry is used to store the second file list in the second cache before the terminal was last powered off. The verification module 5554 is further configured to perform a second security verification on each verified file corresponding to the file identifier in the second file list in the second cache, and obtain a second verification result, wherein the types of verified files include files that have passed the first security verification and pending files that have passed the first security verification but have not obtained a first verification result. The processing module 5552 is further configured to, if the second verification result indicates that the verified file has not passed the second security verification, delete the file identifier of the verified file from the second file list in the second cache and perform a masking process on the verified file.

[0267] In some embodiments, the query module 5551 is further configured to receive a path acquisition request for a target file from any process in the terminal, wherein the path acquisition request carries a target file identifier of the target file; query a hash list in a second cache based on the target file identifier, wherein the hash list is used to store the file identifier and path information of verified files, wherein the query is implemented based on matching rules, the matching rules are used to first match the target file identifier with the file identifiers in the hash list according to length, and then match the file identifiers with the same length as the target file identifier with the target file identifier according to characters; the processing module 5552 is further configured to respond to the path acquisition request based on the target path information matched by the target file identifier when the target path information matched by the target file identifier is found from the hash list; the processing module 5552 is further configured to perform a first mapping process on the target file identifier to obtain the target path information matched by the target file identifier when the target path information matched by the target file identifier is not found from the hash list, and add the target file identifier and the target path information matched by the target file identifier to the hash list, and respond to the path acquisition request based on the target path information matched by the target file identifier.

[0268] In some embodiments, when the target file identifier is found in the first cache or the second cache, and the file operation request includes multiple read operation requests for the target file, the processing module 5552 is further configured to allocate a read lock for each read operation request; based on the read lock allocated for each read operation request, concurrently execute the read operations corresponding to the multiple read operation requests for the target file, and release the read lock after the read operations are completed.

[0269] In some embodiments, when a target file identifier is found in the first cache or the second cache, and the file operation request includes multiple write operation requests for the target file, the processing module 5552 is further configured to determine at least one write operation request to be executed among the write operation requests if there is currently no file operation request being executed for the target file, allocate a write lock for the write operation request to be executed, perform the write operation corresponding to the write operation request to be executed on the target file based on the write lock, and release the write lock after the write operation is completed.

[0270] In some embodiments, the document verification device 555 further includes a creation module 5556.

[0271] The creation module 5556 is used to create a blocking directory entry for each first specific file that needs to be blocked, wherein the blocking directory entry includes the file identifier of the first specific file; the query module 5551 is also used to query the pre-created directory entry in response to the file operation request of the first specific file, and if the file identifier of the first specific file is found in the blocking directory entry, refuse to respond to the file operation request corresponding to the first specific file and block the first specific file.

[0272] In some embodiments, the first cache includes a first sub-cache of a first antivirus engine located in the terminal, and a second sub-cache of a second antivirus engine located in the server. The first sub-cache stores a first sub-file list in the first file list, and the second sub-cache stores a second sub-file list in the first file list. The query module 5551 is further configured to query a target file identifier from the first file sub-list; if a target file identifier is found from the first sub-file list, generate a query result indicating that the target file identifier was found from the first sub-file list; if no target file identifier is found from the first sub-file list, query a target file identifier from the second sub-file list; and if a target file identifier is found from the second sub-file list, generate a query result indicating that the target file identifier was found from the second sub-file list.

[0273] In some embodiments, if the target file identifier is not found in the second sub-file list, the verification module 5554 is further configured to perform a third security verification on the target file using the second antivirus engine to obtain a third verification result; the processing module 5552 is further configured to intercept the operation requested by the file operation request if the third verification result indicates that the target file has failed the third security verification; the verification module 5554 is further configured to add the target file identifier to the second sub-file list if the third verification result indicates that the target file has passed the third security verification, and perform a fourth security verification on the target file using the first antivirus engine to obtain a fourth verification result; the processing module 5552 is further configured to intercept the operation requested by the file operation request if the fourth verification result indicates that the target file has failed the fourth security verification; and the update module 5555 is further configured to add the target file identifier of the target file to the first sub-file list if the fourth verification result indicates that the target file has passed the fourth security verification.

[0274] In some embodiments, the document verification device 555 further includes an initialization module 5557.

[0275] The initialization module 5557 is used to respond to multiple initialization operations of the first antivirus engine, determine the target memory space that the first antivirus engine needs to allocate to perform multiple initialization operations, and perform multiple initialization operations based on the target memory space, wherein the target memory space is the maximum value of the historical memory space allocated multiple times in the initialization operations; and release the allocated target memory space in response to the completion of the initialization of the first antivirus engine.

[0276] In some embodiments, the third security verification is implemented based on a virus rule base. The update module 5555 is also used to obtain the usage frequency of virus rules in the virus rule base and delete virus rules with usage frequency less than the usage frequency threshold from the virus rule base.

[0277] In some embodiments, the verification module 5554 is further configured to determine a preset read length that matches the input / output performance of the terminal; and through the first antivirus engine, sequentially read the data in the target file according to the preset read length, and perform a third security verification based on the data read each time to obtain a third verification result.

[0278] In some embodiments, the update module 5555 is further configured to: set the first cache duration to zero if the first verification result indicates that the target file has passed the first security verification; and remove the target file identifier from the first file list if the first verification result indicates that the target file has not passed the first security verification.

[0279] In some embodiments, the first file list in the first cache includes file identifiers of files that have passed security verification. The verification module 5554 is further configured to perform a fifth security verification on the target file. The processing module 5552 is further configured to perform a masking process on the target file if the target file fails the fifth security verification. The update module 5555 is further configured to perform a second mapping process on the file content of the target file if the target file passes the fifth security verification, to obtain the target file identifier of the target file, and to add the target file identifier of the target file to the first file list in the first cache.

[0280] In some embodiments, the update module 5555 is further configured to query a second specific file that meets preset conditions from the application's directory on the terminal, use the signature and installation path of the second specific file as the file identifier of the second specific file, and add the file identifier of the second specific file to the first file list; wherein the preset conditions include at least one of the following: the size of the second specific file is greater than a size threshold, the second specific file has a digital signature signed by a trusted organization, the second specific file has a fixed installation path, and the number of active users of the second specific file is greater than a quantity threshold.

[0281] In some embodiments, the update module 5555 is further configured to, for files in the directory of the terminal's application, delete the file corresponding to the file identifier in the first file list, and treat the remaining file as a third specific file; perform a sixth security verification on the third specific file whose file size is greater than a volume threshold through the second antivirus engine, and add the file identifier of the third specific file that passes the sixth security verification to the first file list.

[0282] In some embodiments, when the file operation request is an installation request and no file identifier is found from the first file list, the update module 5555 is further configured to perform a first security verification on the target file, and if the target file passes the first security verification, add the target file identifier to the first file list in the first cache; the processing module 5552 is further configured to perform the operation requested by the installation request on the target file in response to receiving the installation request for the target file again.

[0283] It should be noted that the description of the apparatus in this application embodiment is similar to the description of the method embodiment above, and has similar beneficial effects as the method embodiment, therefore it will not be repeated. For any technical details not covered in the document verification apparatus provided in this application embodiment, please refer to... Figure 4 , Figure 5 , Figure 6 , Figure 7 ,or Figure 8 The meaning is understood in accordance with the description of any of the accompanying drawings.

[0284] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the document verification method described in this application.

[0285] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the file verification method provided in this application. For example, ... Figure 4 , Figure 5 , Figure 6 , Figure 7 ,or Figure 8 The document verification method is shown.

[0286] In some embodiments, the computer-readable storage medium may be a memory such as ferroelectric random access memory (FRAM), ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); or it may be a device that includes one or any combination of the above-mentioned memories.

[0287] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0288] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0289] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0290] In summary, upon receiving a file operation request, this embodiment first queries the first file list in the first cache based on the target file identifier to quickly determine whether the file has passed security verification, avoiding the time and resource consumption caused by repeated verification. When the target file identifier is found in the first cache, the operation corresponding to the file operation request can be executed directly, ensuring the smoothness and continuity of file operations. Subsequently, the first cache duration of the target file identifier is obtained and compared with a duration threshold. When the threshold is exceeded, security verification is re-performed, which can promptly detect files whose security has changed, thereby ensuring continuous detection of the security of files in the file list. Afterwards, by setting a duration threshold and performing security verification on target files whose cache duration exceeds the threshold, the performance consumption is reduced while ensuring continuous detection of the security of files in the file list. Finally, the first cache is updated based on the verification results, ensuring the accuracy and timeliness of the first cache. This allows for efficient processing of file operations while providing users with a safe and reliable file operation environment, achieving a good balance between performance consumption and file security, and significantly improving the user experience.

[0291] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A file verification method, characterized in that, The method includes: Based on the target file identifier carried in the file operation request, query the first file list in the first cache, wherein the first file list in the first cache includes the file identifiers of files that have passed security verification; If the target file identifier is found by querying the first file list in the first cache, the operation requested by the file operation request is performed on the target file; Obtain the first cache duration of the target file identifier, wherein the first cache duration is the duration for which the target file identifier is stored in the first file list; If the first cache duration exceeds the duration threshold, the target file undergoes a first security verification to obtain a first verification result; The first cache is updated based on the first verification result.

2. The method according to claim 1, characterized in that, The first cache is the cache of an application in the terminal. Before querying the first list of files in the first cache, the method further includes: Query the list of second files in the second cache, wherein the second cache is the cache of the driver in the terminal; If the target file identifier is found from the second file list, the operation requested by the file operation request is performed on the target file; If the target file identifier is not found in the second file list, the process proceeds to the step of querying the first file list in the first cache.

3. The method according to claim 2, characterized in that, The first cache is a persistent cache implemented based on a database, while the second cache is a non-persistent cache. After updating the first cache based on the first verification result, the method further includes: Determine the incremental file list relative to the updated first file list before the first cache update; The file identifiers in the incremental file list are added to the second file list. The initial second file list in the second cache is obtained by updating the registry in the first cache after the terminal is powered on. The registry stores the second file list in the second cache before the terminal was powered off last time.

4. The method according to claim 2, characterized in that, The first cache is a persistent cache implemented based on a database, while the second cache is a non-persistent cache. Before querying the first file list in the first cache based on the target file identifier carried in the file operation request, the method further includes: In response to a power-on command for the terminal, the file identifiers included in the registry in the first cache are added to the second file list initialized in the second cache, wherein the registry is used to store the second file list in the second cache before the terminal was last powered off; For each verified file corresponding to the file identifier in the second file list in the second cache, a second security verification is performed to obtain a second verification result. The types of the verified files include files that pass the first security verification and pending files that pass the first security verification but do not obtain the first verification result. If the second verification result indicates that the verified file has failed the second security verification, the file identifier of the verified file is deleted from the second file list in the second cache, and the verified file is masked.

5. The method according to claim 2, characterized in that, The method further includes: Receive a path acquisition request for the target file from any process in the terminal, wherein the path acquisition request carries the target file identifier of the target file; The query is performed based on the target file identifier to query the hash list in the second cache. The hash list is used to store the file identifier and path information of the verified file. The query is implemented based on matching rules. The matching rules are used to first match the target file identifier with the file identifier in the hash list according to length, and then match the file identifier with the same length as the target file identifier with the target file identifier according to character. If the target path information matching the target file identifier is found from the hash chain, the path acquisition request is responded to based on the target path information matching the target file identifier. If no target path information matching the target file identifier is found in the hash chain, a first mapping process is performed on the target file identifier to obtain the target path information matching the target file identifier. The target file identifier and the target path information matching the target file identifier are then added to the hash chain, and the path acquisition request is responded to based on the target path information matching the target file identifier.

6. The method according to claim 2, characterized in that, If the target file identifier is found in the first cache or the second cache, and the file operation request includes multiple read operation requests for the target file, the method further includes: Allocate a read lock for each read operation request; Based on the read lock allocated for each read operation request, read operations corresponding to the multiple read operation requests are concurrently executed on the target file, and the read lock is released after the read operation is completed; If the target file identifier is found in the first cache or the second cache, and the file operation request includes multiple write operation requests for the target file, the method further includes: If there are no file operation requests currently being executed for the target file, determine the write operation request to be executed from the at least one write operation request, allocate a write lock for the write operation request to be executed, perform the write operation corresponding to the write operation request to be executed on the target file based on the write lock, and release the write lock after the write operation is completed.

7. The method according to claim 2, characterized in that, The method further includes: Create a blocking directory entry for each first specific file that needs to be blocked, wherein the blocking directory entry includes the file identifier of the first specific file; In response to a file operation request for a first specific file, the system queries a pre-created directory entry. If the file identifier of the first specific file is found in the blocked directory entry, the system refuses to respond to the file operation request corresponding to the first specific file and blocks the first specific file.

8. The method according to claim 1, characterized in that, The first cache includes a first sub-cache of a first antivirus engine set in the terminal and a second sub-cache of a second antivirus engine set in the server. The first sub-cache stores the first sub-file list in the first file list, and the second sub-cache stores the second sub-file list in the first file list. The query for the first file list in the first cache includes: Query the target file identifier from the first sub-file list; If the target file identifier is found from the first sub-file list, a query result is generated showing that the target file identifier was found from the first sub-file list; If the target file identifier is not found in the first sub-file list, the target file identifier is retrieved from the second sub-file list; If the target file identifier is found in the second sub-file list, a query result is generated showing that the target file identifier was found in the second sub-file list.

9. The method according to claim 8, characterized in that, If the target file identifier is not found in the second sub-file list, the method further includes: The target file is subjected to a third security verification using the second antivirus engine, and a third verification result is obtained. If the third verification result indicates that the target file has failed the third security verification, the operation requested by the file operation request will be intercepted. If the third verification result indicates that the target file has passed the third security verification, the target file identifier is added to the second sub-file list, and the target file is subjected to a fourth security verification by the first antivirus engine to obtain a fourth verification result; If the fourth verification result indicates that the target file has failed the fourth security verification, the operation requested by the file operation request will be intercepted. If the fourth verification result indicates that the target file has passed the fourth security verification, the target file identifier of the target file is added to the first sub-file list.

10. The method according to claim 9, characterized in that, Before performing a third security verification on the target file using the first antivirus engine, the method further includes: In response to multiple initialization operations of the first antivirus engine, the target memory space that the first antivirus engine needs to request to execute the multiple initialization operations is determined, and the multiple initialization operations are executed based on the target memory space, wherein the target memory space is the maximum value among the historical memory spaces requested multiple times by the initialization operations; In response to the completion of the initialization of the first antivirus engine, the requested target memory space is released.

11. The method according to claim 9, characterized in that, The third security verification is based on a virus rule base. Before performing the third security verification on the target file through the first antivirus engine, the method further includes: Obtain the usage frequency of virus rules in the virus rule base; Virus rules whose usage frequency is less than the usage frequency threshold will be deleted from the virus rule database.

12. The method according to claim 9, characterized in that, The target file is subjected to a third security verification using the first antivirus engine, resulting in a third verification result, including: Determine a preset read length that matches the input / output performance of the terminal; The first antivirus engine reads the data in the target file sequentially according to the preset reading length, and performs a third security verification based on the data read each time to obtain a third verification result.

13. The method according to any one of claims 1 to 12, characterized in that, The step of updating the first cache based on the first verification result includes: If the first verification result indicates that the target file has passed the first security verification, the first cache duration is reset to zero; If the first verification result indicates that the target file has failed the first security verification, the target file identifier is removed from the first file list.

14. The method according to any one of claims 1 to 12, characterized in that, The first list of files in the first cache includes file identifiers of files that have passed security verification; If the file identifier is not found in the first file list in the first cache, the method further includes: The target file is subjected to a fifth security verification. If the target file fails the fifth security verification, the target file will be blocked. If the target file passes the fifth security verification, the file content of the target file is subjected to a second mapping process to obtain the target file identifier of the target file, and the target file identifier of the target file is added to the first file list in the first cache.

15. The method according to any one of claims 1 to 12, characterized in that, Before querying the first file list in the first cache based on the target file identifier carried in the file operation request, the method further includes: The system queries the application's directory on the terminal for a second specific file that meets preset conditions. The signature and installation path of the second specific file are used as the file identifier of the second specific file. This file identifier is then added to the first file list. The preset conditions include at least one of the following: The second specific file has a volume greater than a volume threshold, the second specific file has a digital signature signed by a trusted organization, the second specific file has a fixed installation path, and the number of active users of the second specific file is greater than a quantity threshold.

16. The method according to claim 1 or 8, characterized in that, Before querying the first file list in the first cache based on the target file identifier carried in the file operation request, the method further includes: For files in the application's directory on the terminal, delete the file corresponding to the file identifier in the first file list, and treat the remaining file as a third specific file; The second antivirus engine performs a sixth security verification on the third specific file whose file size exceeds a certain threshold, and adds the file identifier of the third specific file that passes the sixth security verification to the first file list.

17. A document verification device, characterized in that, The device includes: The query module is used to query the first file list in the first cache based on the target file identifier of the target file carried in the file operation request, wherein the first file list in the first cache includes the file identifier of the file that has passed the security verification; The processing module is configured to perform the operation requested by the file operation request on the target file when the target file identifier is found from the first file list in the first cache; The acquisition module is used to acquire the first cache duration of the target file identifier, wherein the first cache duration is the duration for which the target file identifier is stored in the first file list; The verification module is used to perform a first security verification on the target file when the first cache duration exceeds the duration threshold, and obtain a first verification result; The update module is used to update the first cache based on the first verification result.

18. An electronic device, characterized in that, include: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the file verification method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the file verification method according to any one of claims 1 to 16 is implemented.

20. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the file verification method according to any one of claims 1 to 16 is implemented.

Images