A method for protecting designated paths and files from tampering

Abstract

The present application belongs to the technical field of computer data security, and particularly relates to a method for protecting specified paths and files from tampering, which comprises the following steps: registering a relevant main function code callback routine in a Windows file system filtering driver framework, and constructing an interception layer for intercepting I / O requests; constructing an access control list with PID and file object path as key values in a kernel non-paging memory; synchronously extracting PID and target file complete path in the callback routine, and judging according to system processes, exemption lists, and protection paths / types, and rejecting the request if it does not meet the conditions; and achieving dynamic management of strategies by establishing a control channel. The present application solves the problem of strategy failure caused by volume path changes by hiding file persistent volume IDs in the system; adopts hierarchical data structures and concurrent synchronization mechanisms to ensure efficient queries and little impact on disk IO performance; and supports multi-dimensional fine control with the help of multi-layer control switches and scenario-based templates.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computer data security, and specifically relates to a method for protecting specified paths and files from tampering. BACKGROUND

[0002] In the Windows operating system, the integrity of key files (such as system core components, security configuration files, and business core data files) directly determines the system stability and data security. File tampering caused by malicious programs or misoperations may cause system crashes, data leaks, or even the implantation of persistent backdoors, resulting in serious security risks.

[0003] In the Windows system environment, the integrity of key files is the core foundation of system stability and data security. File tampering caused by malicious programs or human error may cause system crashes, abnormal functions, or even the implantation of persistent backdoors, resulting in data leaks or illegal control of the system. However, existing file protection solutions have significant technical shortcomings: first, the adaptability of protection strategies is insufficient, relying on device paths that are susceptible to mounting order or hardware connection as volume identifiers, resulting in invalid strategies due to path changes; second, the strategy query efficiency is low, using linear structure to store protection paths and white lists, and when the number of objects increases, path matching and process verification consume a significant amount of time, affecting system I / O performance; third, the protection mechanism lacks flexibility, lacking the ability to fine-tune strategy switches by path, white list, or file type, making it difficult to adapt to diverse scenarios; fourth, the interaction efficiency between the kernel and user states is insufficient, strategy operations rely on multiple I / O interactions and event notification responses lag, making it impossible to provide real-time feedback on interception behavior; fifth, the data structure design does not align with the characteristics of the Windows directory hierarchy, resulting in complex path resolution and matching logic and a high risk of false positives.

[0004] The essence of the above problems lies in the fact that existing solutions fail to address the three underlying technical pain points of volume identifier uniqueness, storage structure and directory hierarchy adaptability, and strategy control refinement, resulting in inadequate protection stability, execution efficiency, and dynamic adaptability. SUMMARY

[0005] The purpose of the present application is to provide a method for protecting specified paths and files from tampering, to solve the problems of poor adaptability, inefficient query, rigid control, and poor interaction in existing file protection solutions.

[0006] To solve the above technical problems, the technical solution adopted by the present application is as follows:

[0007] A method for protecting specified paths and files from tampering, which completes access control decisions before data is written to physical storage through the following steps:

[0008] Step S1, Interception Layer Deployment: Register at least the major function code callback routines containing IRP_MJ_WRITE and IRP_MJ_SET_INFORMATION in the Windows File System Filter Driver Framework, build an interception layer loaded on the target file system driver device object for intercepting I / O requests;

[0009] Step S2, Policy Data Structure Construction: Build an access control list for real-time query in the kernel non-paging memory, which is at least keyed by process identifier PID and file object path;

[0010] Step S3, Real-time Decision and Execution: Synchronously execute in the callback routine of the interception layer:

[0011] Step S301, Extract the PID of the process to which the thread initiating the current I / O request belongs and the complete device object path of the target file;

[0012] Step S302, Query the access control list, first judge whether the PID is a system process, if so, release; if not, judge whether the process is in the exemption list, if so, release; if not in the exemption list, judge whether the target file path is in the protection path or the extension of the target file is a protected file type; if any of the above conditions is met, set the status block IoStatus of this I / O request to STATUS_ACCESS_DENIED and complete the request, preventing data from passing down to the lower layer driver;

[0013] Step S4, Dynamic Policy Update Channel: Establish a control channel based on IRP_MJ_DEVICE_CONTROL between user mode and kernel mode, and realize dynamic management of the access control list through pre-defined control codes, including policy adding, deleting and modifying operations.

[0014] According to the above technical solution, the construction and query of the access control list are implemented using the following hierarchical data structure:

[0015] First-level path index: a multi-branch tree with a volume device object as the root, the multi-branch tree contains node branches representing protected paths and node branches representing exempted paths, which are distinguished by the policy type attribute stored in the node memory; the tree node contains a UNICODE_STRING type path name for path matching and a Boolean identifier for sub-tree protection;

[0016] Second-level file type list: a linked list storing protected file extensions.

[0017] Specifically, the read operation (query) of the policy tree uses a shared lock, and the write operation (add, delete, and modify) uses an exclusive lock to ensure concurrent safety. The lock mechanism is implemented through a kernel-level synchronization object (such as ERESOURCE) to avoid data competition or structure damage when multiple threads access concurrently.

[0018] According to the above technical solution, in step S3, the judgment on the target file path supports two modes of precise path matching and subtree matching; when the policy is configured as subtree matching, if the target file path is a prefix matching of the protected directory path, it is determined to be within the protection range.

[0019] According to the above technical solution, the method further comprises dynamic adaptation to volume mounting events:

[0020] In the InstanceSetup callback routine, the GUID of the newly mounted volume is obtained through the FltGetVolumeGuidName function, and then the system hidden file under the volume root directory is opened and the original volume ID is read; whether there is a corresponding volume node in the current protection policy data structure is found through the original volume ID; if there is, the volume ID and device path information of the node are updated.

[0021] According to the above technical solution, the control channel allows the user mode program to independently enable or disable the protection sub-policy for the path, process, and file type; the kernel decision logic first checks the state of the global switch variable corresponding to the sub-policy before executing the query; the switch is a Boolean variable stored in the device extension or global memory; the decision flow first checks the total switch, and if it is on, it checks each sub-switch in sequence.

[0022] According to the above technical solution, when step S3 determines to intercept, the method further comprises an asynchronous event notification mechanism: inserting the metadata of the current interception event into a kernel-level first-in-first-out queue protected by a spin lock; the user mode program asynchronously reads the interception event record from the queue through another dedicated IOCTL of the control channel.

[0023] Specifically, the queue is designed as a fixed-size circular buffer. When the queue is full, according to the configuration, the oldest event or the current event can be discarded. The kernel maintains a reference count for each suspended user mode read IRP, and when the user mode process abnormally exits, the driver completes these IRPs and releases related resources in the device cleanup routine, preventing memory leakage.

[0024] According to the above technical solution, the access control list has a persistence capability: when the system starts, the driver reads and constructs the data structure in memory from the protected configuration file; when the system is shut down or the policy is changed, the current policy data in memory is atomically written back to the configuration file.

[0025] According to the above technical solution, it also includes a semantic conflict detection and resolution mechanism for the strategy:

[0026] When a request to add or modify a policy is received through the dynamic policy update channel, the following steps are performed before updating the access control list:

[0027] Parse the policy rules in the request into formal logical expressions;

[0028] Formal logical expressions are Boolean expressions composed of path patterns, process identifiers, and file extensions as atomic conditions, combined using logical AND, logical OR, and logical NOT operators; the policy logic set is the set of Boolean expressions corresponding to all valid policies in the current access control list.

[0029] Identify and label logical conflicts, which include at least complete coverage conflicts, partial overlap conflicts, and direct mutual exclusion conflicts.

[0030] Conflict resolution suggestions are generated based on predefined priority rules. The priority rules include at least the fact that specific path strategies take precedence over wildcard path strategies.

[0031] Only after verifying that the conflict has been resolved should the access control list be updated.

[0032] According to the above technical solution, an enhanced verification triggering mechanism is also included:

[0033] Configure enhanced verification identifiers for specific protected targets in access control lists or their associated data structures;

[0034] In the real-time decision-making and execution of step S3, after querying the access control list, if it is determined that the current I / O request should be allowed, then further check whether the target file or the initiating process is associated with an enhanced verification identifier.

[0035] If an enhanced verification identifier is associated, the corresponding enhanced verification sub-process will be executed.

[0036] If the verification result of the enhanced verification sub-process is not passed, the pass decision is overwritten, and the status block of this I / O request is set to STATUS_ACCESS_DENIED.

[0037] Based on the above technical solution, the enhanced verification sub-process includes file content verification:

[0038] The enhanced verification identifier is the file content verification identifier;

[0039] When the file content verification subprocess is triggered, the SHA-256 cryptographic hash algorithm is used to calculate the cryptographic hash value of the target file or the data to be written.

[0040] The calculated hash value is compared with a pre-stored trusted hash value benchmark library;

[0041] If the comparison is inconsistent, the verification result of the enhanced verification sub-process is not passed;

[0042] The file content verification identifier and the trusted hash value benchmark library are configured and managed through a dynamic strategy update channel.

[0043] Specifically, the trusted hash value benchmark library is injected into the kernel driver by an authorized process through a control channel in one time or incrementally under the system security state. The version backtracking and incremental updating of the benchmark library are supported, and the updating process adopts encrypted transmission and digital signature verification to ensure the integrity and credibility of the benchmark library.

[0044] Compared with the prior art, the present application has the following beneficial effects:

[0045] The present application stores the volume ID persistently by creating and maintaining a system hidden file in the protected volume root directory, and reads this file to match the strategy when the volume is remounted, solving the problem of strategy invalidation caused by volume device path change, and realizing the continuous effectiveness of the strategy.

[0046] In terms of query efficiency, the present application uses hierarchical data structure and concurrent synchronization mechanism, so that the path matching time consumption is only related to the target path depth, and is independent of the total number of strategies, the time consumption of single I / O request strategy judgment is extremely short, the system disk IO performance is slightly affected, and the problem of low query efficiency of traditional linear storage structure is overcome.

[0047] In terms of control flexibility, the present application supports fine strategy control in multiple dimensions such as path, process and file type through multi-level stacked control switches and scenario-based rule templates, can dynamically adapt to various application scenarios such as software installation and system update, and can complete strategy switching without restarting the driver.

[0048] To realize the interaction real-time performance, the present application constructs a control channel based on IRP, so that the strategy updating and interception event notification can be completed within milliseconds, ensuring that the administrator can realize real-time perception of file security state, and solving the problem of communication delay between kernel mode and user mode. BRIEF DESCRIPTION OF DRAWINGS

[0049] Figure 1 The present application is a file protection method flow chart. DETAILED DESCRIPTION

[0050] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] Example 1

[0052] like Figure 1 As shown, a method for protecting specified paths and files from tampering completes access control decisions before data is written to physical storage through the following steps:

[0053] Step S1, Interception layer deployment: Register a main function code callback routine containing at least IRP_MJ_WRITE and IRP_MJ_SET_INFORMATION in the Windows file system filter driver framework, and build an interception layer loaded on the target file system driver device object to intercept I / O requests.

[0054] Step S2, Policy Data Structure Construction: Construct an access control list for real-time querying in the kernel's non-paged memory, with at least the process identifier (PID) and file object path as key-value pairs;

[0055] Step S3, Real-time Decision Making and Execution: Executed synchronously in the callback routine of the interception layer:

[0056] Step S301: Extract the PID of the process to which the thread that initiated the current I / O request belongs and the complete device object path of the target file;

[0057] Step S302: Query the access control list. First, determine whether the PID is a system process. If so, allow the process. If not, determine whether the process is in the exemption list. If so, allow the process. If not in the exemption list, determine whether the target file path is in a protected path or whether the target file extension is a protected file type. If any of the above conditions are met, set the status block IoStatus of this I / O request to STATUS_ACCESS_DENIED and complete the request, preventing data from being passed to the lower-level driver.

[0058] Step S4, Dynamic Policy Update Channel: Establish a control channel based on IRP_MJ_DEVICE_CONTROL between user space and kernel space. Dynamic management of access control lists is achieved through predefined control codes, including adding, deleting, and modifying policies.

[0059] The application stores the volume ID persistently by creating and maintaining a system hidden file in the protected volume directory, and reads the file to match the policy when the volume is remounted, thereby solving the problem of policy invalidation caused by changes in the volume device path, and realizing the continuous effectiveness of the policy.

[0060] In terms of query efficiency, the application uses a hierarchical data structure and a concurrent synchronization mechanism, so that the time consumption of path matching is only related to the depth of the target path, and is independent of the total number of policies, the time consumption of policy judgment for a single I / O request is extremely short, the system disk IO performance is slightly affected, and the problem of low query efficiency of the traditional linear storage structure is overcome.

[0061] In terms of control flexibility, the application uses a multi-level stacked control switch and a scenario-based rule template to support fine policy control in multiple dimensions such as path, process and file type, and can dynamically adapt to various application scenarios such as software installation and system update, and can complete policy switching without restarting the driver.

[0062] To realize the real-time interaction, the application constructs a control channel based on IRP, so that policy updating and interception event notification can be completed within milliseconds, ensuring that administrators can realize real-time perception of file security status, and solving the problem of communication delay between the kernel mode and the user mode.

[0063] Embodiment two

[0064] This embodiment is a further detailed description of embodiment one, and in this embodiment, a file integrity protection method based on a Windows kernel mode driver and hierarchical policy management is provided, and the specific implementation process is as follows:

[0065] Step one: Constructing the kernel-level file filtering framework. In the system storage stack, a filter driver is constructed above the file system driver based on the Windows Minifilter framework. In the driver entry routine, the following key operations are completed in turn: registering the pre-operation callback functions for core I / O request packets (IRPs) such as file creation (IRP_MJ_CREATE), write operation (IRP_MJ_WRITE), and setting information (IRP_MJ_SET_INFORMATION), to realize synchronous interception of potential tampering behavior. At the same time, the volume mounting notification callback (InstanceSetup) and the device control distribution routine (DriverDispatchDeviceControl) are registered. Subsequently, a device object and its corresponding user-mode accessible symbolic link are created, and the device object is configured in DO_BUFFERED_IO mode to ensure the safety and stability of data transmission between the user mode and the kernel mode. In the driver initialization stage, the memory required for policy storage structure, I / O request context, and event queue is pre-allocated in the kernel non-paged pool, and synchronization objects such as spin lock and event are initialized to lay the foundation for stable operation in a high-concurrency environment.

[0066] Step two: Designing a policy storage system adapted to the characteristics of the Windows file system hierarchy. To efficiently manage protection policies, a composite storage structure composed of a multi-way tree and a one-way linked list is designed and constructed. The multi-way tree accurately maps the volume-directory hierarchy of Windows, including root nodes, volume nodes, and directory nodes, for unified management of protected paths and whitelist paths, and logical differentiation is achieved through node attributes or storage in different branches of the same tree structure. The root node manages all volume node linked lists; the volume node is associated with the physical volume and stores the unique GUID identifier of the volume, the current device path, and the reference of the original volume ID backup file; the directory node stores the directory name of each level of the protected path or the whitelist path, and contains the recursive protection flag of the subdirectory. The one-way linked list is used to store the set of protected file extensions. The construction of this storage structure follows the principle of dynamic on-demand creation: when a new protection target is added, the corresponding volume node and directory node are matched or created layer by layer from the root node, forming a policy tree isomorphic to the file system directory tree. The design of this tree structure makes the time cost of path matching proportional to the depth of the target path, and independent of the total number of policies, thereby realizing efficient matching. At the same time, node hash collision detection and periodic lazy garbage collection mechanisms are introduced to ensure the robustness and memory usage efficiency of the storage structure.

[0067] Step three: Realize the dynamic adaptation mechanism based on the file identification hidden in the volume root directory. When the InstanceSetup callback is triggered by the new volume mounting, the drive obtains the GUID of the volume through the FltGetVolumeGuidName function. Then, the pre-created system hidden file under the volume root directory (the file is created when the volume is first included in protection) is searched and the original volume ID stored therein is read. The drive locates the corresponding volume node in the policy multi-branch tree by taking the original volume ID as the key index. If the matching is successful, the current device path and other information of the volume node are updated; if the matching is not successful, a new volume node is created and initialized, and a new original volume ID backup file is written. This mechanism ensures that the protection policy can be accurately bound to the target physical storage device through the unique original volume ID.

[0068] Step four: Deploy a fine and layered policy control switch system. In order to realize the flexibility and scene adaptability of protection, a four-level layered control switch system is designed, and all switch states are stored in the Boolean variables in the device extension or global memory of the drive. The first level is the global total switch, which controls the enablement and disablement of the entire drive interception function. On the premise that it is turned on, the second level path protection switch, the third level whitelist verification switch and the fourth level file extension name filter switch can be independently turned on and off. In the I / O request processing flow, the total switch is first checked; if it is turned on, the sub-switches are checked in sequence, and only the policy dimension corresponding to the enabled sub-switch is verified. For example, if only the path protection switch is enabled, only the target path is protected, and the process whitelist and file extension name are not checked. The user state management tool can adjust the state of any switch in real time through the dedicated device control code (IOCTL), realizing dynamic policy switching without restarting.

[0069] Further, the method in the application also automatically restores the original policy configuration through the integrated scene-based rule template adaptation mechanism. Specifically, the drive preloads multiple rule templates for typical scenes (such as software installation, system update). The user state management tool can manually or automatically enable the corresponding rule template according to the current system activity characteristics (such as the msiexec.exe process is active and accompanied by high-frequency read and write of the C:\Windows\Installer directory). The template includes a set of temporarily adjusted switch state sets and / or temporary policy rules (such as temporarily closing the path protection switch of the C:\Program Files\Temp directory). All temporary rules are attached with a time-limited label (which can be dynamically adjusted, such as 10 minutes of automatic expiration) and an audit trace identifier, and all dynamic adjustment operations are recorded in the kernel audit log; after the scene ends (such as the installation process exits) or the temporary policy expires, the original policy configuration is automatically restored, ensuring the consistency of the protection state.

[0070] The mechanism has high compatibility and controllability with the integration of existing solutions. Administrators can enable or disable the function globally by adding new dynamic policies. All temporary policy rules are marked as dynamically generated attributes, supporting manual intervention or deletion through user-level tools. Dynamic adjustment logs are synchronized to the user state through an extended audit interface, ensuring that administrators have complete operation traceability capabilities, and achieving an organic combination of static rules and dynamic adaptation.

[0071] Step five: Establish an efficient and atomic kernel and user state bidirectional interaction channel. A complete device control code (IOCTL) interface is designed to encapsulate all policy management operations. User state management tools can complete policy addition, deletion, modification, query, or switch control through a single I / O call using the DeviceIoControl function. Data transmission uses a unified encapsulated buffer structure to ensure efficiency and security. For policy query requests, the kernel state serializes the multi-way tree and linked list structure into linear data and returns it at once, greatly reducing context switching overhead. At the same time, to achieve real-time event notification, an asynchronous communication mechanism based on the IRP suspend-wakeup model is designed: the user state thread sends an IRP to be processed to wait for an event; when the kernel intercepts illegal operations, it immediately fills in the event details (timestamp, process PID / path, target file path, operation type) into the buffer of the IRP and completes it, and the user state thread is immediately awakened to handle the event. This mechanism avoids polling overhead and ensures millisecond-level event notification delay.

[0072] Further, to solve the semantic conflict problem under complex policy configuration, a policy integration verification module is added between the user state policy configuration tool and the kernel state policy tree update operation, a semantic conflict detection and resolution engine is constructed to ensure the internal consistency and execution certainty of the policy set. The core function of this engine is to convert policy rules from natural language description to formal logical expression, identify potential conflicts through semantic analysis, and provide intelligent resolution schemes.

[0073] The conflict detection process adopts a three-step method of offline analysis, logical comparison, and conflict definition. First, when the user adds or modifies a policy through the management tool (such as adding a wildcard path C:\AppData\.conf and setting an exclusion path C:\AppData\Temp\), the engine first parses the policy rule into an abstract syntax tree (AST), and then converts it into an expression based on first-order predicate logic, clearly defining the scope, matching conditions, and execution actions of the rule. Then, the new policy expression is compared with the logical expressions of the existing policy set, simulating the rule execution results under different path, process, and file type combinations. Finally, based on the comparison results, the conflict type is accurately defined, including complete coverage conflict (new rule makes existing rule completely ineffective), partial overlap conflict (rule scope intersection leads to ambiguous execution results), direct mutual exclusion conflict (rule execution actions are opposite under the same conditions), and priority inversion conflict (specific rule priority is lower than wildcard rule).

[0074] The conflict resolution mechanism follows the principle of user-led and intelligent assistance. When a conflict is detected, the engine does not directly reject policy updates, but generates a structured conflict report that clearly presents the associated relationships of conflicting rules, conflict scenario examples, and potential impacts. At the same time, based on the pre-set priority matrix (which can be customized), it provides resolution suggestions, such as specific path rules with higher priority than wildcard path rules, operation rules with higher priority than permission rules, and later configuration rules with higher priority than earlier configuration rules. The administrator can choose to adopt the system's suggestions or manually adjust the rule priority and modify the rule scope. After the resolution is completed, the engine performs a second verification on the adjusted policy set, confirms that there is no conflict, and then submits it to the kernel driver through the DeviceIoControl interface to update the multi-branch tree structure.

[0075] The integration of this engine does not change the existing interaction architecture, only adding a verification link before policy submission. By extending the interface of the policy configuration tool, the conflict detection and resolution functions are realized, and the kernel-level policy storage and execution logic remains unchanged. This not only improves the efficiency of policy management in complex scenarios, but also avoids the problem of protection failure or false interception caused by policy conflicts.

[0076] Step six: Perform multi-layer progressive, content-aware real-time policy judgment logic. When the monitored I / O request reaches the filter driver, the following judgment chain is executed in order:

[0077] System process exemption: First, determine if the initiating process is a system critical process (such as the System process with PID 4). If so, it is directly released.

[0078] White list check: If the white list switch is enabled, the image file path of the initiating process is obtained, the process image information is obtained through the disclosed kernel API such as PsGetProcessImageFileName or IoQueryFileDosDeviceName, and quick matching is performed in the white list branch of the policy tree. If the matching is successful, all related operations of the process are released.

[0079] Protection path matching: If the path protection switch is enabled, the complete device path of the target file is parsed. After locating the corresponding volume node in the policy tree, directory level matching is performed. If the protected directory node is matched, and the recursive protection flag is true or there is a more accurate child node matching under it, the path protection is triggered.

[0080] File type check: If the file extension protection switch is enabled, the target file extension is extracted, and matching is performed in the protected extension list.

[0081] Only when the request process is a non-system process, and is not passed through the white list check, and (hit the protection path or the protected file type), the drive side will intercept the I / O request, and return STATUS_ACCESS_DENIED.

[0082] Further, according to the above method of the present application, in order to improve the ability to resist advanced stealth threats, an enhanced check layer can be added on the basis of real-time decision logic. The layer is enabled or disabled through an independent control switch, and contains the following optional functions: containing file content fuzzy hash matching and process trust chain verification two core functions, forming a multi-layer defense system of basic check and deep check.

[0083] The file content fuzzy hash matching function focuses on the integrity protection of key executable files. The administrator can specify to enable the function for key file types such as.exe,.dll,.sys, etc. through the newly added content verification switch. When such files are attempted to be modified, replaced, or created, the driver automatically triggers the content verification process after completing the basic verification: for write operations, the driver reads the key blocks of the file to be written in memory (such as the DOS header, PE header, optional header, and first 1024 bytes of the code segment of the PE file); for creation or replacement operations, the driver reads the corresponding blocks of the target file on the disk; then the context-triggered hash algorithm (such as ssdeep or TLSH) is used to calculate the fuzzy hash value of the blocks, which has high sensitivity to small modifications of files and low false positive rate to format tweaks. The driver compares the calculated hash value with the trusted file fingerprint library maintained in the kernel mode. The fingerprint library can be pre-delivered through a secure encryption channel or automatically learned and generated by the system when it is first deployed and in a secure state, and then stored in an encrypted manner; if the hash value does not match, even if the basic verification (path, process, extension) passes, the operation will be intercepted, and a high-priority alarm event will be generated, indicating a content integrity anomaly.

[0084] The process trust chain verification function is used to prevent the risk of hijacking or disguising of whitelisted processes. When a whitelisted process initiates a sensitive operation (such as modifying a system core file), if the trust chain verification switch is enabled, the enhanced verification module will start the process tracing process: by querying the parent process ID in the process environment block (PEB), it traverses the complete creation chain (Parent Process Chain) of the process, and traces back to the system trusted root process (such as wininit.exe, services.exe, csrss.exe); at the same time, it checks whether the process has abnormal traces such as remote thread injection and code segment memory modification. If the process creation chain is broken, there are unknown intermediate processes or suspicious injection traces, even if the image path of the process is in the whitelist, its operation will be downgraded (such as only allowing read operations) or triggering alarm interception, ensuring that the whitelist mechanism is not misused.

[0085] The integration of this enhanced verification mechanism with existing solutions has high flexibility and scalability. The newly added content verification switch and trust chain verification switch are included in the existing control switch system, supporting independent enable or disable; the trusted file fingerprint library is updated and maintained through an extended configuration synchronization interface, supporting incremental update and version rollback; the overhead of hash calculation and process tracing during verification is strictly controlled within milliseconds, and through pre-caching hash values and optimizing process chain query algorithms, the impact on system performance is not more than 2%, achieving a balance between security and performance.

[0086] Step seven: Implement a reliable kernel event queue and notification management mechanism. To cope with high concurrency interception scenarios and ensure that events are not lost, a fixed-capacity circular event queue protected by a spin lock is maintained in the kernel. Each time an interception occurs, the driver encapsulates the event data into a node and attempts to insert it into the queue. When the queue is full, the oldest event or the current event can be discarded according to the configuration, preventing memory exhaustion. After the user-mode event listener IRP is awakened and takes the event, the corresponding node space is released. In addition, a heartbeat and timeout mechanism is added to manage user-mode abnormal exit scenarios, preventing resource leaks caused by permanently hanging IRPs.

[0087] Step eight: Integrate policy persistence and systematic fault-tolerant recovery mechanism. When the system starts, the driver loads the policy and switch state from the encrypted configuration file that has been verified by digital signature, automatically reconstructing the kernel storage structure. When the system shuts down or the driver is unloaded, the current policy is synchronized back to the configuration file using atomic operations. Fault-tolerant mechanisms are in place throughout: in the I / O processing path, validity checks are performed on critical pointers to avoid null pointer dereferencing; in policy tree operations, locks are used to ensure concurrency safety and rollback cleanup after potentially failing operations such as memory allocation; regular consistency checks and repairs of the storage structure are performed. At the same time, the driver provides self-monitoring and log reporting functions to facilitate the diagnosis of problems in complex environments.

[0088] Embodiment three

[0089] This embodiment is a further refinement of Embodiment One. This embodiment is used to protect.exe,.dll,.sys type files in the C:\Windows\System32 directory and its subdirectories of the Windows system, exempting the svchost.exe process (PID=1234) from modification operations, and supporting administrators to dynamically add protected paths and file extensions through user-mode tools; including the following steps:

[0090] Driver installation and initialization: Install the file filtering driver, and when the driver starts, read the encrypted configuration file to automatically build a multi-branch tree (create a system disk volume node under the root node, a \Windows\System32 directory node under the volume node, and set the subdirectory protection flag to enabled), a file extension list (store.exe,.dll,.sys), enable the total switch, path protection switch, file extension protection switch, and whitelist switch, and add the process path of svchost.exe to the whitelist.

[0091] Volume device adaptation: When the system disk volume device changes its device path due to hardware connection adjustment, the InstanceSetup callback function is triggered, the original volume ID is read from the system hidden file under the volume root directory, the volume node in the multi-branch tree is matched, the current volume ID and device path information of the node are automatically updated, and the protection policy continues to take effect.

[0092] Interception process: the malicious program (PID=5678) attempts to modify C:\Windows\System32\notepad.exe, triggering the IRP_MJ_WRITE callback function; the kernel state acquires PID=5678 (non-system process), traverses the whitelist node and does not find a match; the target file path is extracted, and the \Windows\System32 directory node (subdirectory protection identification enabled) in the multi-branch tree is matched, and it is determined to be a protected path; the file extension.exe is extracted, and the extension list is matched, and it is determined to be a protected file type; because the path hit or extension hit logic is met, the IO request state is set to STATUS_ACCESS_DENIED, and the file modification is prevented.

[0093] Event notification: after intercepting the event, the kernel state creates an event node and adds it to the event queue; the user state event listening thread is awakened, receives event data (timestamp, PID=5678, target path C:\Windows\System32\notepad.exe, WRITE operation), and displays it to the administrator through a visual interface.

[0094] Policy update: the administrator adds D:\Data as a protected path through the user state tool, and the tool encapsulates the path data as D-D:\Data format and sends it to the kernel state through the ADD_DIRECTORY control code; the kernel state parses the data, converts it into a device path, and creates a \Data directory node under the corresponding volume node, and the policy takes effect immediately without the need to restart the drive.

[0095] The technical effects of the present application are:

[0096] Protection stability: after changing the volume device path, the protection policy is updated within 10ms, without interruption; no blue screen or memory leak occurs for 96 consecutive hours, and no policy data is lost.

[0097] Interception accuracy: 100% of unauthorized process modification operations on target files in the protected path are intercepted, and normal modification operations of the whitelist process svchost.exe are smoothly released without false interception.

[0098] Performance impact: the policy judgment time of a single IO request is ≤0.8ms, and the system disk IO performance decreases by ≤3%, without affecting the normal operation of the system.

[0099] Real-time interaction: the policy update operation response time is ≤10ms, and the interception event notification delay is ≤5ms, and the administrator can real-time monitor the file security state.

[0100] It should be noted that, in the present document, relational terms such as first and second and the like can be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprising", "including", "containing", or any other similar terms are intended to be non-exclusive and non-limiting, such that a process, method, article, or apparatus that comprises, includes, or contains a list of elements is not required to include only those elements on the list, but can include other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0101] Finally, it should be noted that the above-described embodiments are merely possible examples of implementing the present application, and thus do not limit the present application. Accordingly, numerous modifications and variations are possible in the light of the above teachings without departing from the spirit and scope of the application, and it should be understood that all modifications and variations fall within the scope of the application.

Claims

1. A method for protecting specified paths and files from tampering, characterized in that: Access control decisions are made before data is written to physical storage using the following steps: Step S1, Interception layer deployment: Register a main function code callback routine containing at least IRP_MJ_WRITE and IRP_MJ_SET_INFORMATION in the Windows file system filter driver framework, and build an interception layer loaded on the target file system driver device object to intercept I / O requests. Step S2, Policy Data Structure Construction: Construct an access control list for real-time querying in the kernel's non-paged memory, with at least the process identifier (PID) and file object path as key-value pairs; Step S3, Real-time Decision Making and Execution: Executed synchronously in the callback routine of the interception layer: Step S301: Extract the PID of the process to which the thread that initiated the current I / O request belongs and the complete device object path of the target file; Step S302: Query the access control list. First, determine whether the PID is a system process. If so, allow the process. If not, determine whether the process is in the exemption list. If so, allow the process. If not in the exemption list, determine whether the target file path is in a protected path or whether the target file extension is a protected file type. If any of the above conditions are met, set the status block IoStatus of this I / O request to STATUS_ACCESS_DENIED and complete the request, preventing data from being passed to the lower-level driver. Step S4, Dynamic Policy Update Channel: Establish a control channel based on IRP_MJ_DEVICE_CONTROL between user space and kernel space. Dynamic management of access control lists is achieved through predefined control codes, including adding, deleting, and modifying policies.

2. The method for protecting a specified path and file from tampering according to claim 1, characterized in that: The construction and querying of access control lists are implemented using the following hierarchical data structure: First-level path index: A multi-branch tree rooted at the volume device object. The multi-branch tree contains node branches representing protected paths and node branches representing exempted paths, which are distinguished by the policy type attribute stored within the node; tree nodes contain a UNICODE_STRING type path name for path matching and a boolean flag for subtree protection. Second-level file type list: A linked list that stores protected file extensions.

3. The method for protecting a specified path and file from tampering according to claim 1, characterized in that: In step S3, the determination of the target file path supports two modes: exact path matching and subtree matching. When the policy is configured to subtree matching, if the target file path is a prefix match of the protected directory path, it is determined to be within the protection range.

4. The method for protecting a specified path and file from tampering according to claim 1, characterized in that: The method also includes dynamic adaptation to volume mount events: In the InstanceSetup callback routine, the GUID of the newly mounted volume is obtained through the FltGetVolumeGuidName function. Then, the system hidden file in the root directory of the volume is opened and the original volume ID is read. The original volume ID is used to check whether there is a corresponding volume node in the current protection policy data structure. If so, update the volume ID and device path information for that node.

5. A method for protecting a specified path and file from tampering according to claim 1, characterized in that: The control channel allows user-mode programs to independently enable or disable protection sub-policies for paths, processes, and file types. Before executing a query, the kernel decision logic first checks the state of the global switch variable for the corresponding sub-policy. The switch is a Boolean variable stored in the driver device extension or global memory. The decision process first checks the master switch, and if it is enabled, it checks each sub-switch in sequence.

6. A method for protecting a specified path and file from tampering according to claim 1, characterized in that: When step S3 determines that an interception has occurred, the method also includes an asynchronous event notification mechanism: inserting the metadata of this interception event into a kernel-mode first-in-first-out queue protected by a spinlock; User-space programs asynchronously read intercepted event records from this queue via another dedicated IOCTL for the control channel.

7. A method for protecting a specified path and file from tampering according to claim 1, characterized in that: Access control lists have persistence capabilities: when the system starts, the driver reads from the protected configuration file and builds the data structure in memory; when the system shuts down or the policy changes, the current policy data in memory is atomically written back to the configuration file.

8. A method for protecting a specified path and file from tampering according to claim 1, characterized in that: It also includes a semantic conflict detection and resolution mechanism for the strategy: When a request to add or modify a policy is received through the dynamic policy update channel, the following steps are performed before updating the access control list: Parse the policy rules in the request into formal logical expressions; Formal logical expressions are Boolean expressions composed of path patterns, process identifiers, and file extensions as atomic conditions, combined using logical AND, logical OR, and logical NOT operators; the policy logic set is the set of Boolean expressions corresponding to all valid policies in the current access control list. Identify and label logical conflicts, which include at least complete coverage conflicts, partial overlap conflicts, and direct mutual exclusion conflicts. Conflict resolution suggestions are generated based on predefined priority rules. The priority rules include at least the fact that specific path strategies take precedence over wildcard path strategies. Only after verifying that the conflict has been resolved should the access control list be updated.

9. A method for protecting a specified path and file from tampering according to claim 1, characterized in that: It also includes an enhanced verification triggering mechanism: Configure enhanced verification identifiers for specific protected targets in access control lists or their associated data structures; In the real-time decision-making and execution of step S3, after querying the access control list, if it is determined that the current I / O request should be allowed, then further check whether the target file or the initiating process is associated with an enhanced verification identifier. If an enhanced verification identifier is associated, the corresponding enhanced verification sub-process will be executed. If the verification result of the enhanced verification sub-process is not passed, the pass decision is overwritten, and the status block of this I / O request is set to STATUS_ACCESS_DENIED.

10. A method for protecting a specified path and file from tampering according to claim 9, characterized in that: The enhanced verification sub-process includes file content verification: The enhanced verification identifier is the file content verification identifier; When the file content verification subprocess is triggered, calculate the cryptographic hash value of the target file or the data to be written. The calculated hash value is compared with a pre-stored trusted hash value benchmark library; If the comparison is inconsistent, the verification result of the enhanced verification sub-process will be "fail". The file content verification identifier and trusted hash value benchmark library are configured and managed through a dynamic policy update channel.

Images