Application file protection method, device, equipment, medium and program product

Through the user-state-driven detection and the trusted state processing of target process, the problem of difficult application file security is solved, and the effect of improving application file security is achieved without affecting the system performance.

CN118627114BActive Publication Date: 2025-04-01BEIJING VOLCANO ENGINE TECH CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202410740885.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-06-07
Publication Date
2025-04-01
Estimated Expiration
2044-06-07

AI Technical Summary

Technical Problem

The prior art is difficult to effectively protect application files on corporate office equipment or business equipment, resulting in threats to information security.

Method used

The user state drive detects the target event of the protected application file for the target application, determines the target process that triggers the target event, and processes the target event based on the trusted state of the target process.

Benefits of technology

This method can improve the security of application files without affecting system performance, block the operation of unauthorized target processes, and enhance the security of target applications.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118627114B_ABST
    Figure CN118627114B_ABST
Patent Text Reader

Abstract

The present disclosure relates to the field of data security technology, and discloses a protection method, device, equipment, medium and product for application files, the method comprising detecting a target event of a protected application file for a target application through a user mode driver, the protected application file being determined based on a first file attribute of the application file of the target application; in response to detecting a target event for the protected application file, determining a target process that triggers the target event; determining a trusted state of the target process; and processing the target event based on the trusted state of the target process. The method can improve the security of the application file of the target application of the client.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to the field of data security technology, and in particular to a method, device, equipment, medium and product for protecting application files. Background Art

[0002] Application files are files of applications (i.e., application software) installed on electronic devices, including program files required for application installation and data files generated by application operation. The security protection of application files is very important, especially in enterprise scenarios. If application files installed on enterprise office equipment or enterprise business equipment have security issues, it will affect the information security of the enterprise. Therefore, it is necessary to provide a protection method for application files. Summary of the invention

[0003] In view of this, the present disclosure provides a method, apparatus, device, medium and program product for protecting application files to solve the security problem of application files.

[0004] In a first aspect, the present disclosure provides a method for protecting an application file, the method comprising:

[0005] Detecting, by a user mode driver, a target event for a protected application file of the target application, wherein the protected application file is determined based on a first file attribute of the application file of the target application;

[0006] In response to detecting the target event for the protected application file, determining a target process that triggers the target event;

[0007] determining a trusted state of the target process;

[0008] The target event is processed based on the trusted state of the target process.

[0009] In a second aspect, the present disclosure provides a device for protecting an application file, the device comprising:

[0010] an event detection module, configured to detect, through a user mode driver, a target event for a protected application file of a target application, wherein the protected application file is determined based on a first file attribute of an application file of the target application;

[0011] a process determination module, configured to determine a target process that triggers the target event in response to detecting the target event for the protected application file;

[0012] A trusted state determination module, used to determine the trusted state of the target process;

[0013] An event processing module is used to process the target event based on the trusted state of the target process.

[0014] In a third aspect, the present disclosure provides an electronic device, comprising: a memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method for protecting application files of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0015] In a fourth aspect, the present disclosure provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method for protecting application files of the first aspect or any corresponding embodiment thereof.

[0016] In a fifth aspect, the present disclosure provides a computer program product, including computer instructions, which are used to enable a computer to execute the method for protecting application files of the first aspect or any corresponding embodiment thereof.

[0017] The application file protection method provided by the embodiment of the present disclosure detects the target event of the protected application file for the target application through the user state driver, wherein the protected application file is determined based on the first file attribute of the application file of the target application. Based on this, when the target event for the protected application file is detected, the target process that triggers the target event is determined, and the target event is processed based on the trusted state of the target process by determining the trusted state of the target process. This method processes the target event for the protected application file by combining the user state driver with the file attribute, which can protect the security of the application file. At the same time, the user state driver only detects the occurrence of the target event instead of detecting all events, which greatly reduces the amount of events to be processed, thereby reducing the impact on system performance. And processing the target event based on the trusted state of the target process that triggers the target event can achieve the blocking of unauthorized target processes, thereby improving the security of the application file of the target application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the related technologies, the drawings required for use in the specific embodiments or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0019] Figure 1 is a flowchart of a method for protecting application files according to an embodiment of the present disclosure;

[0020] Figure 2 is a schematic diagram of a file path according to an embodiment of the present disclosure;

[0021] Figure 3 is a schematic diagram of another file path according to an embodiment of the present disclosure;

[0022] Figure 4 is a schematic diagram of yet another file path according to an embodiment of the present disclosure;

[0023] Figure 5 is a schematic diagram of file protection during an upgrade installation process according to an embodiment of the present disclosure;

[0024] Figure 6 is a schematic diagram of file protection during uninstallation according to an embodiment of the present disclosure;

[0025] Figure 7 is a schematic diagram of updating based on configuration information according to an embodiment of the present disclosure;

[0026] Figure 8 is a schematic diagram of another file path according to an embodiment of the present disclosure;

[0027] Fig. 9 is a schematic diagram of file protection during an upgrade process according to a specific example of an embodiment of the present disclosure;

[0028] Fig.10 is a structural block diagram of a device for protecting application files according to an embodiment of the present disclosure;

[0029] Fig.11 It is a schematic diagram of the hardware structure of the electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0030] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present disclosure.

[0031] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0032] In the description of the embodiments of the present disclosure, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may also be included below.

[0033] Herein, unless explicitly stated, executing a step “in response to A” does not mean executing the step immediately after “A” but may include one or more intermediate steps.

[0034] It is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition, use, storage or deletion of the data) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0035] It is understandable that before using the technical solutions disclosed in the various embodiments of the present disclosure, the types, scopes of use, usage scenarios, etc. of the information involved in the present disclosure should be informed to relevant users and their authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations. The relevant users may include any type of right holders, such as individuals, enterprises, and groups.

[0036] For example, in response to receiving an active request from a user, a prompt message is sent to the relevant user to clearly prompt the relevant user that the operation requested to be performed will require obtaining and using the information of the relevant user, so that the relevant user can independently choose whether to provide information to software or hardware such as an electronic device, application, server or storage medium that executes the operation of the technical solution of the present disclosure based on the prompt message.

[0037] As an optional but non-limiting implementation, in response to receiving an active request from a relevant user, a prompt message is sent to the relevant user, for example, in the form of a pop-up window, in which the prompt message may be presented in text form. In addition, the pop-up window may also carry a selection control for the user to select "agree" or "disagree" to provide information to the electronic device.

[0038] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0039] Office security usually involves the security management of networks, identities, and terminals. By implementing private network networking, access control, terminal management in private networks, and information security protection, digital office can be made safer, more efficient, and easier to use. Security management at the network level can ensure that private networks such as office networks can operate safely and efficiently, thereby ensuring that business data can be safely transmitted and stored. Security management at the identity level can improve the efficiency and security of identity authentication for users accessing private networks. Security management at the terminal level can achieve unified management of terminal devices within the private network, data leakage prevention, and terminal threat protection, thereby ensuring the security of corporate data.

[0040] In actual applications, the security management of networks, identities, and terminals can achieve technical linkage in multiple technical branches such as networking strategies, network access and control, remote access, unified terminal management, terminal detection and response, enterprise data leakage prevention, and identity authentication management, making digital office simpler, more efficient, and easier to implement.

[0041] In the related art, one protection strategy for the target application's application files is to prevent the modification of the application files through file system attributes and permissions. That is, using the file system function, only objects with modification permissions are allowed to modify the protected application files, or the protected application files are completely protected.

[0042] However, in this protection strategy, since the operating system user usually has administrator privileges, he can modify his own file modification privileges, which will cause the protection of the protected application file to fail. For cleaning application tools, they usually also have the ability to modify file attributes, so they can automatically bypass the security protection of the file system. In addition, for data files in application files, there is a need for frequent changes, which inevitably involves modifying them. In this case, protection only through the file attributes of the file system will also have the problem of protection failure.

[0043] Based on this, the embodiment of the present disclosure provides a method for protecting application files, which detects a target event for a protected application file by combining a user-mode driver with a first file attribute, and processes the target event based on the trusted state of the target process that triggers the target event when the target event is detected. The method can improve the security of the application file of the target application without affecting system performance.

[0044] According to an embodiment of the present disclosure, an embodiment of a method for protecting an application file is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0045] In this embodiment, a method for protecting an application file is provided, which can be used in electronic devices such as clients, servers, etc. Figure 1 is a flowchart of a method for protecting an application file according to an embodiment of the present disclosure. Figure 1 As shown, the process includes the following steps:

[0046] Step S101 : detecting a target event for a protected application file of a target application through a user mode driver.

[0047] The protected application file is determined based on the first file attribute of the application file of the target application.

[0048] User-mode drivers are different from kernel drivers. User-mode drivers are used to process upper-level software work. User-mode drivers detect target events instead of all events of the target application, so as to reduce the number of detected events and reduce resource consumption.

[0049] During the upgrade, installation or use of the target application, multiple application files are involved, for example, application files generated during the upgrade and installation of the target application, or application files generated during use, etc. From the perspective of file function, application files can be divided into program files and data files. Program files include source program files, compiled target files, and executable programs, etc.; data files include files from which data needs to be read when the program is running, that is, the content of the data file is not necessarily the program, but the data read and written when the program is running.

[0050] The target application corresponds to multiple application files, and the application files that need to be protected are called protected application files. Which of the multiple application files belong to protected application files is determined based on the first file attribute of the application file, wherein the attribute value of the first file attribute includes protected and unprotected, etc. The setting of the attribute value of the first file attribute can be set in the configuration file of the target application, or it can be obtained by upgrading the protection level of the initially set first file attribute according to the requirements of the protection scenario, etc. Of course, the setting method of the attribute value of the first file attribute is not limited to the above, and it can also be set in other ways, and no limitation is made here. It should be noted that the file attributes of the application file may include multiple types, for example, the file attribute representing the file size, the file attribute representing the file summary, etc., and the attribute value of the first file attribute is used here to represent whether the application file is protected. For example, the attribute value of the first file attribute includes a first value and a second value, the first value indicates that the application file is not protected, and the second value indicates that the application file is protected. Among them, the first value and the second value can be 0 and 1 respectively, or false and true respectively, etc. Of course, other forms may also be used to represent the first value and the second value, and no limitation is made to the specific forms here.

[0051] For the protected application file of the target application, the user-mode driver can filter out events for the protected application file, and then detect whether the event for the protected application file is a target event, thereby realizing the detection of the target event of the protected application file.

[0052] Step S102: in response to detecting a target event for the protected application file, determining a target process that triggers the target event.

[0053] During the detection process, the user-mode driver may detect a target event for the protected application file, and the target event may be triggered by a process. After detecting the target event for the protected application file, the user-mode driver determines the target process that triggers the target event.

[0054] For example, the target application may involve multiple processes during the process of upgrading, installing, using or uninstalling. The target process can be determined by detecting events triggered by the processes.

[0055] Step S103, determining the trust status of the target process.

[0056] The trust status of the target process may be determined by the process name of the target process, or by the calling path of the target process, etc. The method for determining the trust status of the target process is not limited here, and it can be set according to actual needs.

[0057] Step S104: Process the target event based on the trusted state of the target process.

[0058] The trust status of the target process includes trusted and untrusted. If the trust status of the target process is trusted, the processing of the target event is released; correspondingly, if the trust status of the target process is untrusted, the processing of the target event by the target process is blocked.

[0059] When processing the target event, the corresponding processing after processing the target event may be involved depending on the current state of the target application. Among them, the state of the target application includes upgrade installation, use and uninstallation. The state of the target application is different, and there may be differences in the processing after processing the target event. For data files or program files, the corresponding target events may be different. For example, for data files, the target event includes clearing the attribute value of the first file attribute of the protected application file and reading the path of the protected application file; for program files, the target event includes clearing the attribute value of the first file attribute of the protected application file. Among them, clearing the attribute value of the first file attribute of the protected application file is used to make the protected application file in an unprotected state, and the trusted process can process it accordingly.

[0060] For example, during the upgrade and installation process, for program files or data files, the target event includes clearing the attribute value of the first file attribute of the protected application file. After clearing the attribute value of the first file attribute, it means that the application file can be modified as needed, that is, the program file or data file is modified accordingly, and the attribute value of the first file attribute of the program file or data file is restored after the modification is completed.

[0061] During the uninstallation process, for a program file or a data file, the target event includes clearing the attribute value of the first file attribute of the protected application file. After clearing the attribute value of the first file attribute, the program file or the data file is deleted, thereby uninstalling the target application.

[0062] The application file protection method provided in this embodiment can protect the security of the application file by processing the target event for the protected application file in a manner combining the user state driver with the first file attribute. At the same time, the user state driver only detects the occurrence of the target event instead of detecting all events, which greatly reduces the amount of events to be processed, thereby reducing the impact on system performance. And the target event is processed based on the trusted state of the target process that triggers the target event, which can block the unauthorized target process and improve the security of the application file of the target application.

[0063] In some optional implementations, the above-mentioned application file protection method further includes:

[0064] Step a1, obtaining the attribute value of the first file attribute in the application file as the protected first file and the file path of the first file.

[0065] Step a2: determining the upper-layer file of the first file based on the file path, where the upper-layer file is a file whose file level is above the first file.

[0066] Step a3, setting the first file attribute for the upper layer file to obtain a protected application file, the protected application file including the first file and the second file whose attribute value of the first file attribute in the upper layer file is protected.

[0067] As described above, the protected application file is determined based on the attribute value of the first file attribute of the application file. If the attribute value of the first file attribute is protected, the application file is a protected application file. In the actual protection process of the application file, the protected application file includes not only the first file whose attribute value of the first file attribute is protected, but also a second file determined according to the file path of the first file.

[0068] Specifically, for the application file of the target application, its first file attribute can be used to determine in the application file that the attribute value of the first file attribute is a protected first file. It should be noted that the first file is merely a description and is not limited to being a single file. That is, the first file can be an independent application file or a file bundle. If the first file is a file bundle, the attribute values ​​of the first file attributes of all files in the file bundle are protected. For example, folder 1 includes folders 11 to 13, folder 11 includes files 1 to 4, and the attribute value of the first file attribute of folder 1 is protected, then the attribute values ​​of the first file attributes of folders 11 to 13 and files 1 to 4 are all protected.

[0069] For a file set, the attribute values ​​of the first file attributes of all files in the file set are protected. By setting the attribute values ​​of the first file attributes of the entire file set, the amount of data processing caused by setting them one by one is reduced.

[0070] After the first file is determined, the file path of the first file is obtained according to the path between the first file and the root file. For example, the file path of the first file is represented as: root directory-folder 1-...-folder nn-first file.

[0071] By analyzing the file path of the first file, the upper-level files of the first file can be determined. The upper-level files are files whose file hierarchy is above the first file. The file hierarchy is related to the file path, and the closer the file is to the root directory, the higher the file hierarchy. For example, in the above example, the upper-level files of the first file include: the root directory, folder 1, ... and folder n.

[0072] Since when accessing the first file, it is necessary to access step by step according to the guidance of the file path, accordingly, whether the upper layer file is safe will also affect the security of the first file. Therefore, the first file attribute is set for the upper layer file, and the attribute value of the first file attribute is determined in the upper layer file as the protected second file. So far, the protected application file includes the first file and the second file.

[0073] The files in the upper layer files for which the first file attribute is set may be set according to actual needs, and may be a random selection of an upper layer file or all files in the upper layer files.

[0074] It should be noted that the above steps a1 to a3 can be executed after obtaining the configuration information of the target application and updating the first file attribute of the protected application file, or can be executed before enabling protection of the application file, etc. There is no limitation on the execution timing of steps a1 to a3, and it can be set according to actual needs.

[0075] For an application file whose attribute value of the first file attribute is a protected first file, the upper-layer file of the first file is determined by obtaining the file path of the first file, and the attribute value of the first file attribute of the upper-layer file is set, thereby further expanding the scope of file protection and improving the security protection of the protected application file.

[0076] Accordingly, in some optional implementations, the above step a3 includes:

[0077] Step a31, based on the path of the upper-layer file, determine the protected file path in the upper-layer file to obtain the unprotected file path in the upper-layer file.

[0078] Step a32, determining the second file corresponding to the unprotected file path in the upper layer file.

[0079] Step a33: setting the attribute value of the first file attribute of the second file to be protected.

[0080] For upper-layer files, each of them also has a corresponding path, and the protected file path is determined from the path of the upper-layer file. The protected file path includes a file path protected by the system, or a conventional file path, etc.

[0081] For file paths protected by the system, they can be distinguished by identification. If a path is protected by the system, the identification can be set to protected, otherwise it can be set to unprotected. For the identification of conventional file paths, conventional target file paths can be pre-set, and then the paths of the upper-level files can be matched with these target file paths. If they can be matched, it means that there is a conventional path in the path of the upper-level file.

[0082] For example, Figure 2 A schematic diagram of a file path is shown, where the file path is: root directory - application folder - file set (bundle) - file. In this file path, the attribute value of the first file attribute of the file set is protected. For a file set, the path of its upper-level files is: root directory - application folder, which is a conventional path. Figure 2 Under the file path shown, the protected application file includes a file set.

[0083] Figure 3 A schematic diagram of another file path is shown, the file path is: root directory - resource folder - custom folder - file set (bundle) - file. In this file path, the attribute value of the first file attribute of the file set is protected. For the file set, the path of its upper file is: root directory - resource folder - custom folder, where the root directory - resource folder is a path protected by the system. Then, the attribute value of the first file attribute of the custom folder is set to protected. Accordingly, in Figure 3 Under the file path shown, the protected application files include file sets and custom folders.

[0084] Figure 4 A schematic diagram of another file path is shown, the file path is: root directory - resource folder - custom folder - single program file. In this file path, the attribute value of the first file attribute of the single program file is protected. For a single program file, the path of its upper file is: root directory - resource folder - custom folder, where the root directory - resource folder is a path protected by the system. Then, the attribute value of the first file attribute of the custom folder is set to protected. Accordingly, in Figure 4 Under the file path shown, the protected application files include file sets and custom folders.

[0085] For the file path protected by the system, the modification of the attribute value of the first file attribute is prohibited by the system and therefore cannot be modified; for the conventional file path, since it is shared by multiple applications, if the attribute value of its first file attribute is modified, it may cause abnormalities in other applications that use the folder on this file path. Therefore, there is no need to set protection for the protected file path in the upper file, but to set the attribute value of the first file attribute for the second file on the unprotected file path in the upper file.

[0086] In some optional implementations, if the target event is to clear the attribute value of the first file attribute of the protected application file, the above step S104 includes:

[0087] Step b1: in response to the target process being in a trusted state and being an upgrade installation process for a target application, allowing the upgrade installation process to clear the attribute value of the first file attribute of the protected application file.

[0088] Step b2: the upgrade installation process modifies the protected application file.

[0089] Step b3: in response to the modification of the protected application file being completed, restoring the attribute value of the first file attribute of the protected application file to the file attribute value before clearing.

[0090] As described above, the target event is determined according to the file type of the protected application file, wherein the file type includes program files and data files.

[0091] Specifically, if the file type of the protected application file is a data file, the target event is to obtain the file path of the protected application file and / or clear the attribute value of the first file attribute of the protected application file; if the file type of the protected application file is a program file, the target event is to clear the attribute value of the first file attribute of the protected application file.

[0092] For different types of protected application files, the corresponding target events that need to be detected are not all the same, which can ensure that different types of protected application files can all receive corresponding security protection.

[0093] If the target event currently detected for the protected application file is to clear the attribute value of the first file attribute of the protected application file, the trusted state of the target process is trusted and the target process is an upgrade installation process for the target application, then the target process is released at this time, that is, the upgrade installation process is allowed to clear the attribute value of the first file attribute of the protected application file.

[0094] For the upgrade installation process, it includes an upgrade scenario and a first installation scenario. In these two scenarios, no matter whether the protected application file is a program file or a data file, the detected target event includes clearing the attribute value of the first file attribute of the protected application file. Figure 5 A schematic diagram of file protection during the upgrade installation process is shown. If the upgrade installation process is trustworthy, the upgrade installation process includes:

[0095] Step S501: allowing the upgrade installation process to clear the attribute value of the first file attribute of the protected application file.

[0096] Step S502: the upgrade installation process modifies the protected application file.

[0097] Step S503 , in response to the modification of the protected application file being completed, restoring the attribute value of the first file attribute of the protected application file to the file attribute value before clearing.

[0098] For a trusted upgrade and installation process, it is allowed to clear the attribute value of the first file attribute of the protected application file and modify the protected application file. After the modification, the first file attribute of the protected application file is restored to the file attribute value before clearing, so as to ensure that the protection of the application file will not affect the upgrade and installation of the target application.

[0099] In some optional implementations, if the target event is to clear the attribute value of the first file attribute of the protected application file, the above step S104 includes:

[0100] Step c1: in response to the trust status of the target process being trustworthy and the target process being an uninstallation process of the target application, stopping detection of the target event.

[0101] Step c2: allowing the uninstallation process to clear the attribute value of the first file attribute of the protected application file.

[0102] Step c3, deleting the protected application file.

[0103] In the uninstallation scenario, no matter the protected application file is a program file or a data file, the detected target event includes clearing the attribute value of the first file attribute of the protected application file. Figure 6 The schematic diagram of file protection during the uninstallation process is shown. In the uninstallation scenario, the target process is called the uninstallation process. If the uninstallation process is credible, the file protection process during the uninstallation process includes:

[0104] Step S601, stop detecting the target event.

[0105] Step S602: allowing the uninstall process to clear the attribute value of the first file attribute of the protected application file.

[0106] Step S603: Delete the protected application file.

[0107] For a trusted uninstallation process, the detection of the target event is stopped, the attribute value of the first file attribute of the protected application file is allowed to be cleared, and the protected application file is deleted, thereby ensuring that the protection policy for the application file does not affect the normal uninstallation of the target application.

[0108] In some optional implementations, step S104 includes:

[0109] Step d1, in response to the file type of the protected application file being a data file and the target process being a trusted user process of the target application, allowing the target process to obtain the file path of the protected application file and / or allowing the target process to clear the attribute value of the first file attribute of the protected application file.

[0110] Step d2: in response to the file type of the protected application file being a program file and the target process being a trusted user process of the target application, allowing the target process to clear the attribute value of the first file attribute of the protected application file.

[0111] In the usage scenario of the target application, the target events detected are different for different program files or data files. Accordingly, when the trust status of the target process is trustworthy, the target events allowed are also different.

[0112] Specifically, if the file type of the protected application file is a data file and the target process is a user process of the target application, the detected target event includes clearing the attribute value of the first file attribute of the protected application file and obtaining the file path of the protected application file. If the user process is credible, the user process is allowed to process the target event.

[0113] If the file type of the protected application file is a program file and the target process is a user process of the target application, the detected target event includes clearing the attribute value of the first file attribute of the protected application file. If the user process is credible, the user process is allowed to process the target event.

[0114] For trusted usage processes, corresponding target events are released for data files and program files respectively, ensuring the normal use of application software while ensuring the security of protected application files.

[0115] In some optional implementations, the above step S103 includes: determining the trusted state of the target process based on the process call chain of the target process.

[0116] The process call chain is used to represent the call path of the target process. A parent process builds a child process, which in turn builds a child-child process, which builds a child-child process, and so on. This is called a process chain. For example, process 1 builds process 2, which in turn builds process 3, which builds process 4. Then, the process call chain corresponding to process 4 can be expressed as: process 4-process 3-process 2-process 1.

[0117] After determining the process call chain of the target process, analyze it to determine the trust status of the target process. The process call chain analysis can be performed layer by layer to determine whether each parent process is a trusted process. For example, when analyzing the process call chain of process 4, it can be analyzed whether process 4 is trustworthy, and then analyze whether process 3 is trustworthy, whether process 2 is trustworthy, and whether process 1 is trustworthy. If any process is untrustworthy, the trust status of the target process is considered to be untrustworthy.

[0118] Alternatively, the source of calling the target process, that is, the starting point of the process call chain, may be traced back through the process call chain of the target process, and the trusted state of the target process may be determined by determining the trusted state of the starting point.

[0119] In some optional implementations, the above-mentioned determination of the trustworthy state of the target process based on the process call chain of the target process specifically includes:

[0120] Step e1, based on the process call chain of the target process, determine the parent process step by step.

[0121] Step e2: in response to any parent process not satisfying a preset condition, determining that the trust status of the target process is untrustworthy.

[0122] The trusted state of the target process is obtained by analyzing the process call chain of the target process. Specifically, the parent process in the process call chain is analyzed step by step to trace the target process upwards. That is, the source of the target process is determined by step-by-step analysis, thereby determining the trusted state of the target process.

[0123] If, during the tracing process, it is determined that there is any parent process that does not meet the preset conditions, the trusted state of the target process is determined to be untrustworthy. For example, for the target application, the processes it generates and the process call chains of each process can be determined by enumeration. When analyzing the process chain of the target process, the process call chain can be matched with the process call chain in the enumeration result to determine whether the parent process meets the preset conditions. Of course, other methods can also be used to determine the trusted state of the process call chain of the target process, which is not limited here and is set according to actual needs.

[0124] For the process chain of the target process, whether it is trustworthy is determined by determining the parent process step by step. This method can minimize the protection failure window in the process of determining the trustworthy status of the target process, further ensuring the security of the protected application files.

[0125] In some optional implementations, the above step e2 specifically includes:

[0126] Step e21, determining whether the process name of the parent process matches the corresponding preset process name.

[0127] Step e22, in response to the process name of any parent process not matching the corresponding preset process name, determining that the trust status of the target process is untrustworthy.

[0128] By determining the parent process of the target process step by step, the process name of each parent process is matched with the corresponding preset process name in turn, wherein the corresponding preset process name is used to represent the process name of the credible parent process.

[0129] If the process name of any parent process does not match the corresponding preset process name, the trust state of the target process is determined to be untrustworthy without waiting for all parent processes to be matched.

[0130] Determining the trusted state by means of the process name can simplify the method of determining the trusted state and improve the efficiency of determining the trusted state.

[0131] In some optional implementations, the above-mentioned application file protection method further includes:

[0132] Step f1, obtaining configuration information of a target application, where the configuration information includes a first file attribute of an application file of the target application.

[0133] Step f2: determining that the attribute value of the first file attribute in the configuration information is the protected file path of the protected application file.

[0134] Step f3: Determine whether the attribute value of the first file attribute of the protected application file corresponding to the protected file path in the application file is protected.

[0135] Step f4, in response to the attribute value of the first file attribute of the protected application file being unprotected, updating the attribute value of the first file attribute of the protected application file to protected, and updating the subscription of the user-mode driven detection event of the protected application file.

[0136] For the target application, the configuration information may be updated during the upgrade or other occasions, and the configuration information includes the first file attribute of the application file of the target application. After obtaining the configuration information, the attribute value of the first file attribute of the protected application file in the application file is updated, and accordingly, the subscription of the detection event driven by the user state is updated.

[0137] Specifically, since the configuration information includes the first file attribute of the application file of the target application, the attribute value of the first file attribute is determined in the configuration information to be the protected file path of the protected application file. Among them, the application file corresponding to the protected file path is the protected application file. It should be noted that due to the upgrade of the target application and other processing, the attribute value of the first file attribute of the protected application file corresponding to the protected file path in the application file may change. Therefore, the protected file path is used to determine whether the attribute value of the first file attribute of the corresponding protected application file is protected. If it is not protected, it is necessary to update the attribute value of the first file attribute of the protected application file to protected, and update the subscription of the detection event driven by the user state of the protected application file. This is because for unprotected application files, it is not necessary to detect the target event through the user state driver, and after the attribute value of the first file attribute is updated to protected, it is correspondingly necessary to detect the target event through the user state driver, so it is necessary to update the subscription of the detection event driven by the user state.

[0138] It should be noted that the above steps f1 to f4 can be executed before step S101, which is used to indicate that after obtaining the configuration information, the first file attribute of the protected application file needs to be updated based on the configuration information, and the protection process of the protected application file is executed after the update. Among them, the protection process for the protected application file can be timed or executed in a real-time uninterrupted loop. Therefore, if the configuration information is not obtained and the protection process for the protected application file needs to be executed, it is not necessary to execute the above steps f1 to f4, and the execution starts from step S101. Of course, if there are other situations, the corresponding execution order can also be set according to the needs, and it is not limited here.

[0139] In some optional implementations, if the target application turns on file self-protection, the first file attribute of the application file needs to be updated based on the configuration information. For example, the attribute value of the first file attribute before the update is unprotected, and the attribute value of the first file attribute after the update is protected. Accordingly, the subscription of the detection event corresponding to the application file needs to be updated to ensure the timeliness of the target event detection. If the target application does not turn on file self-protection, it means that there is no need to protect the protected application file at present. At this time, the attribute value of the first file attribute of the protected application file needs to be updated to unprotected, and the subscription of the detection event corresponding to the application file needs to be updated accordingly.

[0140] Figure 7 This is a schematic diagram of processing an update based on configuration information. The acquisition of configuration information can be triggered on a time basis. Specifically, the update process based on configuration information includes:

[0141] Step S701, timing triggering.

[0142] Step S702: Check whether the configuration information is obtained. If the configuration information is obtained, execute step S703; otherwise, end the update process.

[0143] Step S703, whether to enable file self-protection. If enabled, execute step S704, otherwise, execute step S706.

[0144] Step S704: Check the protected path.

[0145] Step S705: Check if all are protected. If all are protected, go to step S709; otherwise, go to step S708.

[0146] Step S706: Check the protected path.

[0147] Step S707, determine whether all are not protected. If all are not protected, execute step S709, otherwise execute step S708.

[0148] Step S708: update the protection attribute.

[0149] Step S709: Update the subscription of the corresponding user-mode driven detection event.

[0150] For example, every 10 seconds, a detection of whether the configuration information is obtained is triggered. If no new configuration information is obtained, the update is terminated. If it is detected that the configuration information is obtained, it is detected whether the target application turns on file self-protection. If the target application turns on file self-protection, the protected path is detected to determine whether all application files on the protected path are protected. If not all are protected, the protection attribute (i.e., the attribute value of the first file attribute) is updated and the subscription of the corresponding user-state driven detection event is updated; if all are protected, only the subscription of the corresponding user-state driven detection event is updated. If the target application does not turn on file self-protection, the protected path is detected to determine whether all application files on the protected path are unprotected. If not, the protection attribute (i.e., the attribute value of the first file attribute) is updated, the subscription of the corresponding user-state driven detection event is updated, and the attribute value of the first file attribute under protection is modified to unprotected, and the detection of the target event is stopped. If all are unprotected, the subscription of the corresponding user-state driven detection event is updated.

[0151] When the target application is set with file self-protection, the first file attribute is updated based on the acquired configuration information, and the subscription of the corresponding user-driven detection event is updated. Thus, when the configuration information is updated, the attribute value of the first file attribute of the application file is updated in time, thereby achieving timely security protection of the application file.

[0152] In some optional implementations, updating the attribute value of the first file attribute of the protected application file to protected in the above step f4 includes: if the protected application file is a file set, updating the attribute values ​​of the first file attributes of all files in the file set to protected.

[0153] The file set represents a collection of multiple files or folders. For all files in the file set, the attribute value of the first file attribute is updated to be protected.

[0154] In some optional implementations, the above-mentioned application file protection method further includes:

[0155] Step g1, obtaining the initial file path of the protected application file.

[0156] Step g2: based on the initial file path, determine the location of the newly added path node in the upper-level path node of the protected application file.

[0157] Step g3, generating a folder with a random name at the location of the newly added path node to update the initial file path to obtain the file path of the protected application file.

[0158] The file path of the protected application file can be the initial file path generated when the target application is first installed, or can be determined each time the target application is upgraded or at other times. The file path of the protected application file is changed by inserting a folder with a random name on the initial file path.

[0159] Specifically, after obtaining the initial file path of the protected application file, the position of the newly added path node is determined in the initial file path, wherein the newly added path node is located in the upper layer path node of the protected application file. Figure 8 A schematic diagram of another file path is shown, where the initial file path of the protected application file is: root directory-resource folder-custom folder-protected application file. Accordingly, the upper path of the protected application file is: root directory-resource folder-custom folder, and the root directory, resource folder, and custom folder are respectively referred to as upper path nodes of the protected application file. The position of the newly added path node is determined in these upper path nodes, and a folder with a random name is generated at the position of the newly added path node to update the initial file path, thereby obtaining the file path of the protected application file.

[0160] It should be noted that the folder with a random name means that the name of the newly generated folder is randomly generated.

[0161] The location of the newly added path node can be one or more, and there is no limitation on it here, and it can be set according to actual needs. After determining the location of the newly added path node, a folder with a random name is generated at the corresponding location, so that the file path of the protected application file is updated.

[0162] For example, Figure 8 As shown, the location of the selected new path node is between the custom folder and the protected application file. Accordingly, a folder with a random name is generated at the location of the selected new path node. So far, the updated file path of the protected application file is: root directory-resource folder-custom folder-random name folder-protected application file.

[0163] Through one or more layers of folders with random names, the file path of the protected application file is randomly hidden to avoid security issues caused by the similarity of the file path. For example, for enterprise-level target applications, when the target application is installed on different client terminals, the same file may be stored under the same file path. Then, if the file path of the protected application file can be obtained in client terminal 1, the corresponding file can also be obtained in client terminal 2 using the same path. In order to avoid security issues caused by the similarity of the file path, the randomness of the file path is improved by randomly hiding the file path.

[0164] It should be noted that the above steps g1 to g3 may be to randomize the file path after the first file attribute of the application file is updated using the configuration information, or, the file path may be randomized as needed under other actual needs. There is no limitation on the execution timing, and it can be set according to actual needs.

[0165] For protected application files, by setting a folder with a random name in its path, it is more difficult to obtain the file path, so as to minimize the investment in transformation and increase the difficulty of unauthorized processes reading the file path.

[0166] As a specific application example of the present disclosure, Fig. 9 As shown, taking the installation of the target application as an example, that is, when upgrading the application through the installation package installation program, it is necessary to allow the modification of program files and data files. Fig. 9 As shown in the figure, the process of upgrading the application through the installation package installer includes:

[0167] Step S901, setting a file attribute event.

[0168] Step S902: Whether to release the protection. If yes, go to step S903; otherwise, go to step S909.

[0169] Step S903: Is it a protected path? If yes, go to step S904; otherwise, go to step S909.

[0170] Step S904: Is it a process of operating attributes? If yes, go to step S905; otherwise, go to step S910.

[0171] Step S905, whether the parent process is an installer service. If so, execute step S906, otherwise execute step S910.

[0172] Step S906, whether the grandparent process is an installation program. If so, execute step S907, otherwise, execute step S910.

[0173] Step S907, verify the installation package signature.

[0174] Step S908, whether it is a trusted installation package. If so, proceed to step S909, otherwise, proceed to step S910.

[0175] Step S909: allowing the attribute value of the first file attribute to be cleared.

[0176] Step S910: prohibiting clearing of the attribute value of the first file attribute.

[0177] Specifically, taking the target format application installation package as an example, the application installation package has been downloaded to the client, and the software is installed offline on the client. During the execution of the installation package, the protected attributes of the program file and the data file are cancelled, and the user state driver detects the operation event. If it is not an operation of removing the protection (cancelling the first protected file attribute), it is directly released, and it is determined whether the file path of the file corresponding to the event is a protected path. If it is not protected, it is directly released. If it is protected, it is necessary to further determine whether the target process that triggers the event is credible. Specifically, first determine whether the target process is a process with an operation attribute. If not, block the event. If so, further determine whether the parent process is an installer service. If not, block the event. If so, further determine whether the grandparent process is an installation program. If not, block the event. If so, verify the installation package signature. That is, the process call chain of the target process is judged to determine whether it meets the characteristics of the installer script service-script interpreter process-process with an operation attribute. If it meets the characteristics, it is considered that the process call chain meets the corresponding characteristics. Of course, the process call chain of the target process can also be traced to determine whether it can be traced back to the installation program. If it can be traced back to the installation program, it is also considered that the process call chain meets the corresponding characteristics. After determining that the process call chain is correct, the installation package signature is verified to verify whether the installation package is a trusted installation package through the signature. If it is trusted, the attribute value of the first file attribute is allowed to be cleared, otherwise it is prohibited to clear the attribute value of the first file attribute. In the case of allowing the attribute value of the first file attribute to be cleared, the attribute value of the first file attribute is cleared, the installation program continues to overwrite the installation process, and restarts the service process.

[0178] This method protects the integrity of application files by combining the first file attribute with user-mode driven events, while reducing service access costs and avoiding system performance bottlenecks. It also simplifies the upgrade logic by automatically identifying the overwritten installation process and verifying the trusted installer or installation package through signatures, allowing it to modify program files and data files. Through the process call chain and signature verification, the trusted installer or installation package is allowed to overwrite the protected application file. The user is completely unaware of whether the file protection is turned on, and the cost of modifying the installation process access is low.

[0179] The above-mentioned application file protection method can block the modification behavior of untrusted program files, protect the integrity of the program, and ensure that the normal operation and exit of the software are not affected. For the protection of data files, it can block the access behavior of untrusted data files, protect the integrity of data, and ensure that the software's own enumeration, reading, writing, and deletion of data files are not affected. At the same time, the method is also compatible with the release of upgrade installation and uninstallation scenarios. Specifically, the program is automatically released when it is overwritten and upgraded, and the modification of program files and data files is allowed. When executing the normal uninstallation process, the program files and data files are allowed to be deleted. This method revolves around the life cycle of the application file corresponding to the target application, ensuring that the high-frequency and high-stability functions such as the startup and exit of the target application, data file modification, etc. can be used normally, and it can also ensure the stability of processes such as the first installation, overwriting upgrade, uninstallation, and self-protection switch to avoid user perception. By only detecting target events for protected application files, the occupation of system resources is reduced.

[0180] In this embodiment, a protection device for application files is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0181] This embodiment provides a protection device for application files, such as Fig.10 As shown, including:

[0182] The event detection module 1001 is used to detect a target event of a protected application file of a target application through a user mode driver, where the protected application file is determined based on a first file attribute of the application file of the target application.

[0183] The process determination module 1002 is configured to determine a target process that triggers the target event in response to detecting a target event for a protected application file.

[0184] The trusted state determination module 1003 is used to determine the trusted state of the target process.

[0185] The event processing module 1004 is used to process the target event based on the trusted state of the target process.

[0186] In some optional implementations, the protection device for the application file further includes:

[0187] The path acquisition module is used to obtain the attribute value of the first file attribute in the application file as the protected first file and the file path of the first file.

[0188] The upper-layer file determination module is used to determine the upper-layer file of the first file based on the file path, and the upper-layer file is a file whose file level is above the first file.

[0189] The first file attribute setting module is used to set the first file attribute of the upper layer file to obtain a protected application file, wherein the protected application file includes the first file and the second file whose attribute value of the first file attribute in the upper layer file is protected.

[0190] In some optional implementations, the first file attribute setting module includes:

[0191] The file path determination unit is used to determine the protected file path in the upper-layer file based on the path of the upper-layer file to obtain the unprotected file path in the upper-layer file.

[0192] The second file determining unit is used to determine the second file corresponding to the unprotected file path in the upper layer file.

[0193] The first file attribute setting unit is used to set the attribute value of the first file attribute of the second file to be protected.

[0194] In some optional implementations, if the target event is to clear the attribute value of the first file attribute of the protected application file, the event processing module 1004 includes:

[0195] The clearing permission unit is used for allowing the upgrade installation process to clear the attribute value of the first file attribute of the protected application file in response to the trust status of the target process being trustworthy and the target process being an upgrade installation process for the target application.

[0196] The file modification unit is used to modify the protected application files during the upgrade installation process.

[0197] The attribute restoring unit is used to restore the attribute value of the first file attribute of the protected application file to the file attribute value before clearing in response to the modification of the protected application file being completed.

[0198] In some optional implementations, if the target event is to clear the attribute value of the first file attribute of the protected application file, the event processing module 1004 includes:

[0199] The detection stopping unit is used to stop detecting the target event in response to the trust status of the target process being trustworthy and the target process being an uninstallation process of the target application.

[0200] The first file attribute clearing unit is used to allow the uninstallation process to clear the attribute value of the first file attribute of the protected application file.

[0201] The file deletion unit is used to delete the protected application files.

[0202] In some optional embodiments, if the file type of the protected application file is a data file, the target event includes: obtaining the file path of the protected application file and / or clearing the attribute value of the first file attribute of the protected application file; if the file type of the protected application file is a program file, the target event includes: clearing the attribute value of the first file attribute of the protected application file.

[0203] In some optional implementations, the event processing module 1004 includes:

[0204] The first processing unit is used to allow the target process to obtain the file path of the protected application file or to clear the attribute value of the first file attribute of the protected application file in response to the file type of the protected application file being a data file and the target process being a trusted user process of the target application.

[0205] The second processing unit is configured to allow the target process to clear the attribute value of the first file attribute of the protected application file in response to the file type of the protected application file being a program file and the target process being a trusted user process of the target application.

[0206] In some optional implementations, the trust state determination module 1003 includes:

[0207] The trusted state determination unit is used to determine the trusted state of the target process based on the process call chain of the target process.

[0208] In some optional implementations, the trusted state determination unit includes:

[0209] The parent process determines the child unit, which is used to determine the parent process step by step based on the process call chain of the target process.

[0210] The trusted state determination subunit is used to determine that the trusted state of the target process is untrustworthy in response to any parent process not satisfying a preset condition.

[0211] In some optional implementations, the trusted state determination subunit includes:

[0212] The process name matching subunit is used to determine whether the process name of the parent process matches the corresponding preset process name.

[0213] The untrusted state determination subunit is used to determine that the trusted state of the target process is untrusted in response to the process name of any parent process not matching the corresponding preset process name.

[0214] In some optional implementations, the protection device for the application file further includes:

[0215] The configuration information acquisition module is used to acquire the configuration information of the target application, where the configuration information includes a first file attribute of an application file of the target application.

[0216] The protected file path determination module is used to determine that the attribute value of the first file attribute in the configuration information is the protected file path of the protected application file.

[0217] The first file attribute determination module is used to determine whether the attribute value of the first file attribute of the protected application file corresponding to the protected file path in the application file is protected.

[0218] The update module is used to update the attribute value of the first file attribute of the protected application file to protected in response to the attribute value of the first file attribute of the protected application file being unprotected, and to update the subscription of the detection event driven by the user mode of the protected application file.

[0219] In some optional implementations, the update module includes:

[0220] The updating unit is used for updating the attribute values ​​of the first file attributes of all files in the file set to protected if the protected application file is a file set.

[0221] In some optional implementations, the protection device for the application file further includes:

[0222] The initial path acquisition unit is used to acquire the initial file path of the protected application file.

[0223] The path node adding unit is used to determine the position of the newly added path node in the upper path node of the protected application file based on the initial file path.

[0224] The folder generation unit is used to generate a folder with a random name at the location of the newly added path node to update the initial file path to obtain the file path of the protected application file.

[0225] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0226] The protection device for application files in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0227] The present disclosure also provides an electronic device having the above Fig.10 The protection device of the application file shown.

[0228] See also Fig.11 , Fig.11 is a schematic diagram of the structure of an electronic device provided by an optional embodiment of the present disclosure, such as Fig.11 As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig.11 A processor 10 is taken as an example.

[0229] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0230] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0231] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0232] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0233] The electronic device further comprises a communication interface 30 for the electronic device to communicate with other devices or a communication network.

[0234] The embodiments of the present disclosure also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present disclosure can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium and downloaded through a network, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0235] A part of the present disclosure may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present disclosure through the operation of the computer. Those skilled in the art should understand that the existence of computer program instructions in computer-readable media includes, but is not limited to, source files, executable files, installation package files, etc., and accordingly, the way in which computer program instructions are executed by a computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to the computer.

[0236] Although the embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A method for protecting an application file, characterized in that: The method comprises: Acquire an attribute value of a first file attribute in the application file, which is a protected first file and a file path of the first file, wherein the attribute value of the first file attribute includes protected and unprotected; Based on the file path, determining an upper-layer file of the first file, the upper-layer file being a file whose file level is above the first file; Setting a first file attribute on the upper-layer file to obtain a protected application file, wherein the protected application file includes the first file and a second file whose attribute value of the first file attribute in the upper-layer file is protected; Detecting, by a user mode driver, a target event for a protected application file of a target application, wherein the protected application file is determined based on a first file attribute of the application file of the target application; In response to detecting the target event for the protected application file, determining a target process that triggers the target event; determining a trusted state of the target process; The target event is processed based on the trusted state of the target process.

2. The method according to claim 1, characterized in that The setting of file attributes for the upper-layer file includes: Based on the path of the upper-layer file, determining a protected file path in the upper-layer file to obtain an unprotected file path in the upper-layer file; Determine the second file corresponding to the unprotected file path in the upper file; The attribute value of the first file attribute of the second file is set to protected.

3. The method according to claim 1, characterized in that: If the target event is to clear the attribute value of the first file attribute of the protected application file, the processing of the target event based on the trusted state of the target process includes: In response to the trust status of the target process being trustworthy and the target process being an upgrade installation process for the target application, allowing the upgrade installation process to clear the attribute value of the first file attribute of the protected application file; The upgrade installation process modifies the protected application file; In response to the modification of the protected application file being completed, the first file attribute of the protected application file is restored to the file attribute value before being cleared.

4. The method according to claim 1, characterized in that: If the target event is to clear the attribute value of the first file attribute of the protected application file, the processing of the target event based on the trusted state of the target process includes: In response to the trusted state of the target process being trusted and the target process being an uninstall process of the target application, stopping detection of the target event; Allowing the uninstall process to clear the attribute value of the first file attribute of the protected application file; Delete the protected application file.

5. The method according to claim 1, characterized in that If the file type of the protected application file is a data file, the target event includes: obtaining a file path of the protected application file and / or clearing an attribute value of a first file attribute of the protected application file; If the file type of the protected application file is a program file, the target event includes: clearing the attribute value of the first file attribute of the protected application file.

6. The method according to claim 5, characterized in that The processing of the target event based on the trusted state of the target process includes: In response to the file type of the protected application file being a data file and the target process being a trusted user process of the target application, allowing the target process to obtain a file path of the protected application file and / or allowing the target process to clear an attribute value of a first file attribute of the protected application file; In response to the file type of the protected application file being a program file and the target process being a trusted user process of the target application, the target process is allowed to clear an attribute value of a first file attribute of the protected application file.

7. The method according to claim 1, characterized in that The processing of the target event based on the trusted state of the target process includes: In response to the trust status of the target process being untrustworthy, blocking the target process from processing the target event.

8. The method according to claim 1, characterized in that Determining the trustworthy state of the target process includes: Based on the process call chain of the target process, a trusted state of the target process is determined.

9. The method according to claim 8, characterized in that The determining the trusted state of the target process based on the process call chain of the target process includes: Based on the process call chain of the target process, determining the parent process step by step; In response to any of the parent processes not satisfying a preset condition, determining that the trust status of the target process is untrustworthy.

10. The method according to claim 9, characterized in that In response to any of the parent processes not satisfying a preset condition, determining that the trust status of the target process is untrustworthy includes: Determining whether the process name of the parent process matches the corresponding preset process name; In response to the process name of any of the parent processes not matching the corresponding preset process name, determining that the trust status of the target process is untrustworthy.

11. The method according to any one of claims 1 to 10, characterized in that The method further comprises: Acquire configuration information of the target application, the configuration information including a first file attribute of an application file of the target application; Determine that the attribute value of the first file attribute in the configuration information is a protected file path of a protected application file; Determine whether the attribute value of the first file attribute of the protected application file corresponding to the protected file path in the application file is protected; In response to the attribute value of the first file attribute of the protected application file being unprotected, the attribute value of the first file attribute of the protected application file is updated to protected, and the subscription of the user-mode driven detection event of the protected application file is updated.

12. The method according to claim 11, characterized in that The updating the attribute value of the first file attribute of the protected application file to be protected includes: If the protected application file is a file set, the attribute values ​​of the first file attributes of all files in the file set are updated to protected.

13. The method according to claim 11, characterized in that The method further comprises: Obtaining an initial file path of the protected application file, wherein the initial file path is determined based on the configuration information; Based on the initial file path, determining the position of a newly added path node in the upper layer path node of the protected application file; A folder with a random name is generated at the location of the newly added path node to update the initial file path to obtain the file path of the protected application file.

14. A device for protecting an application file, characterized in that: The device comprises: a path acquisition module, used to acquire an attribute value of a first file attribute in the application file, which is a protected first file and a file path of the first file, wherein the attribute value of the first file attribute includes protected and unprotected; An upper-layer file determination module, used to determine an upper-layer file of the first file based on the file path, the upper-layer file being a file whose file level is above the first file; a first file attribute setting module, configured to set a first file attribute on the upper layer file to obtain a protected application file, wherein the protected application file includes the first file and a second file whose attribute value of the first file attribute in the upper layer file is protected; an event detection module, configured to detect, through a user mode driver, a target event for a protected application file of a target application, wherein the protected application file is determined based on a first file attribute of an application file of the target application; a process determination module, configured to determine a target process that triggers the target event in response to detecting the target event for the protected application file; A trusted state determination module, used to determine the trusted state of the target process; An event processing module is used to process the target event based on the trusted state of the target process.

15. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the application file protection method according to any one of claims 1 to 13 by executing the computer instructions.

16. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the application file protection method according to any one of claims 1 to 13.

17. A computer program product, characterized in that The invention comprises computer instructions, wherein the computer instructions are used to make a computer execute the application file protection method according to any one of claims 1 to 13.

Citation Information

Patent Citations

  • Operation method of package file, file processing equipment and equipment with storage function

    CN110232261A