File tamper-proofing system

Abstract

The application relates to the technical field of information security, and discloses a file tamper-proofing system. The system comprises a first module and a second module arranged in an operating system kernel layer. The first module is used for: in response to monitoring a file modification request initiated by a process, acquiring relevant information of the process and preliminarily determining whether to intercept the request, if it is preliminarily determined to intercept the request, intercepting the request and transmitting the relevant information to the second module; the second module is used for: receiving the relevant information, determining a feature vector based on the relevant information, determining an anomaly detection model corresponding to the relevant information from a model library, inputting the feature vector into the anomaly detection model, determining an anomaly score of the process based on an output result of the anomaly detection model, and determining a conclusion according to the anomaly score; the first module is further used for: if the conclusion is that the process is a normal process, the request is passed; and if the conclusion is that the process is a malicious process, the operation of the process is terminated. The application can prevent files from being maliciously tampered with.

Description

Technical Field

[0001] This application relates to the field of information security technology, specifically to a file anti-tampering system. Background Technology

[0002] With the deepening of digital transformation, critical files in operating systems (such as system configuration files, executable programs, and database files) have become primary targets for attackers. If attackers exploit vulnerabilities, privilege escalation, or social engineering techniques to tamper with these files, it can lead to serious consequences such as system crashes, data breaches, or even backdoor implants. How to effectively prevent malicious file tampering is a problem that needs to be solved. Summary of the Invention

[0003] In view of the above problems, this application provides a file anti-tampering system to solve the problem that the prior art cannot effectively prevent files from being tampered with.

[0004] According to one aspect of the embodiments of this application, a file anti-tampering system is provided, the system comprising: a first module and a second module deployed at the kernel layer of an operating system; wherein, the first module is configured to: in response to detecting a file modification request initiated by a process, obtain relevant information of the process, preliminarily determine whether to intercept the request based on the relevant information, and if it is preliminarily determined to intercept the request, intercept the request and transmit the relevant information to the second module, wherein the relevant information includes the process's identity information, behavior information, operation object information, and call stack information; the second module is configured to: receive the relevant information, determine a feature vector based on the relevant information, determine an anomaly detection model corresponding to the relevant information from a model library, input the feature vector into the anomaly detection model, determine the anomaly score of the process based on the output result of the anomaly detection model, and determine a conclusion based on the anomaly score, wherein the conclusion includes the process being a normal process and the process being a malicious process; the first module is further configured to: if the conclusion is that the process is a normal process, then approve the request; if the conclusion is that the process is a malicious process, then terminate the operation of the process.

[0005] In an optional embodiment, the system further includes a third module; wherein the second module is further configured to: transmit the conclusion to the third module; the third module is configured to: verify the watermark information of the file and obtain a verification result, wherein the file has multiple layers of watermark information pre-embedded, and the verification result includes verification passed and verification failed; the first module is specifically configured to: if the conclusion is that the process is a normal process and the verification result is verification passed, then the request is approved; if the conclusion is that the process is a malicious process and the verification result is verification passed, then the request is blocked; if the conclusion is that the process is a malicious process and the verification result is verification failed, then the operation of the process is terminated; if the conclusion is that the process is a normal process and the verification result is verification failed, then the operation of the process is terminated.

[0006] In one optional approach, the multi-layered watermark information includes file-level watermark, structure-level watermark, and content-level watermark. The file-level watermark is determined by calculating the hash value of the file. The structure-level watermark is determined by extracting the structured features of the file's format and performing a hash operation on the structured features. The content-level watermark is determined by calculating the semantic hash value of the file using a locality-sensitive hashing algorithm or a perceptual hashing algorithm.

[0007] In an optional manner, the third module is further configured to: if the first module approves the request and the request has been completed, obtain the content of the modified file, and update the multi-layer watermark information of the modified file based on the content of the modified file.

[0008] In an optional manner, the conclusion further includes that the process is a suspicious process, and the first module is further specifically used to: when the conclusion is that the process is a suspicious process and the verification result is that the verification is passed, then the request is approved; when the conclusion is that the process is a suspicious process and the verification result is that the verification is not passed, then the operation of the process is terminated.

[0009] In an optional manner, the conclusion further includes that the process is a suspicious process. The second module is also used to record all operation information of each process within a preset time period. If the conclusion is that the process is a suspicious process, then it is determined whether the process meets any one of the first, second, third, and fourth conditions. If the process meets any one of the first to fourth conditions, then the conclusion is updated to that the process is a malicious process. The first condition is: the number of operations performed by the process within the preset time period exceeds a preset number threshold; the second condition is: the files requested to be modified by the process are distributed across multiple top-level directories; the third condition is: the operation type of the process switches between multiple types multiple times; and the fourth condition is: the file names of the files requested to be modified by the process are named in an ascending numerical pattern.

[0010] In an optional embodiment, the second module is further configured to: determine that the process is a normal process when the anomaly score is less than a first threshold; determine that the process is a suspicious process when the anomaly score is greater than or equal to the first threshold and less than a second threshold, or when an anomaly detection model corresponding to the relevant information cannot be determined from the model library; and determine that the process is a malicious process when the anomaly score is greater than or equal to the second threshold.

[0011] In one alternative approach, the anomaly detection model is an isolated forest model, which contains multiple isolated trees. The second module is specifically used to: input the feature vector into the isolated forest model, obtain the output of each isolated tree, determine the average value of the output of all isolated trees, and normalize the average value to the anomaly score.

[0012] In an optional embodiment, the system further includes a fourth module; the first module is further configured to: transmit the relevant information to the fourth module; the second module is further configured to: transmit the conclusion to the fourth module; the fourth module is configured to: generate and store a process management strategy based on the relevant information and the conclusion; the first module is specifically configured to: preliminarily determine whether to intercept the request based on the relevant information and the process management strategy stored in the fourth module.

[0013] In an alternative embodiment, the system further includes a fifth module; the first module is further configured to: transmit the relevant information to the fifth module; the second module is further configured to: transmit the conclusion to the fifth module; and the fifth module is configured to: receive and store the relevant information and the conclusion.

[0014] In this embodiment, by deploying a first module at the operating system kernel layer, forced interception of file modification requests is achieved, effectively preventing malicious processes from exploiting privilege escalation or system vulnerabilities to bypass traditional permission verification mechanisms, thus ensuring file security from the source. Simultaneously, by deploying a second module, an anomaly detection model is used to determine anomaly scores, which can then accurately identify process behavior attributes based on these scores, effectively distinguishing between normal, malicious, and suspicious processes. This behavior-based detection mechanism does not rely on pre-set signatures, thus effectively identifying unknown malicious programs, zero-day attacks, and tampering behaviors using legitimate processes. It compensates for the shortcomings of traditional security protection methods, achieving real-time blocking and prevention of file tampering risks, thereby avoiding malicious file modification.

[0015] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0016] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A schematic diagram of the document anti-tampering system provided in an embodiment of this application is shown; Figure 2 This application illustrates a document anti-tampering system according to another embodiment; Figure 3 This application illustrates a document anti-tampering system according to yet another embodiment; Figure 4 This application illustrates a document anti-tampering system according to yet another embodiment. Detailed Implementation

[0017] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0018] In current operating systems, many processes involve modifying files within the operating system during execution.

[0019] In related technologies, to ensure file security, when a process initiates modification of a file, the operating system verifies whether the process has the necessary permissions. If the process does not have the required permissions, modification is prohibited. However, some malicious processes may exploit system vulnerabilities to bypass the operating system's permission verification or modification settings, thereby directly modifying files without authorization and compromising file security.

[0020] Alternatively, some technologies use signature-based antivirus software to identify malicious processes and prevent them from tampering with files. However, this method can only identify known malicious programs and cannot effectively defend against tampering and zero-day attacks performed by legitimate processes (such as system tools and script interpreters).

[0021] Other technologies use integrity verification tools such as Tripwire for periodic scanning, which can detect malicious file tampering. However, this method is essentially a post-event audit and cannot block attacks in real time. Furthermore, high-frequency scanning consumes a lot of system resources.

[0022] If a forced interception module can be deployed at the kernel level of the operating system to ensure that no process (including the process with the highest privileges) can modify protected files without authorization, the risk of illegal tampering caused by privilege escalation vulnerabilities can be solved at the root, the defects of traditional permission verification mechanisms that are easy to bypass can be made up for, and the real-time blocking of unknown threats and abuse of legitimate processes can be achieved, thereby providing more proactive and reliable security protection for critical system files.

[0023] Based on this, this application proposes a file anti-tampering system. A first module is deployed at the operating system kernel layer, and a second module is deployed in user space or a highly secure Trusted Execution Environment (TEE). The TEE is a secure area built within the CPU through hardware isolation, used to securely execute sensitive code and data under an untrusted operating system or hypervisor. It uses the chip as the root of trust, providing confidentiality, integrity, and availability guarantees, ensuring that even if the system is compromised, plaintext information within the enclave cannot be stolen. The first module responds to a detected file modification request from a process by obtaining relevant information about the process and initially determining whether to intercept the request. If it initially determines to intercept the request, it intercepts the request and transmits the relevant information to the second module. Upon receiving the relevant information, the second module determines a conclusion based on the information and an anomaly detection model. If the conclusion is that the process is normal, the first module allows the request; if the conclusion is that the process is malicious, the first module terminates the process's operation, thereby preventing malicious file tampering. The file anti-tampering system provided in this application will be described in detail below with reference to the accompanying drawings.

[0024] Figure 1 The illustration shows a schematic diagram of a file anti-tampering system provided in an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the file anti-tampering system. Figure 1 As shown, the file anti-tampering system 10 includes a first module 110 and a second module 120. The first module 110 is deployed in the kernel layer of the operating system of the file anti-tampering system 10, and the second module 120 is deployed in a TEE. The first module 110 is a kernel-mode forced interception module, and the second module 120 is a dynamic behavior fingerprint engine module.

[0025] Specifically, when the first module 110 detects a process initiating a file modification request, it immediately suspends the process, obtains its identity information, behavior information, operation object, and call stack, and performs a preliminary interception judgment based on this. If the preliminary judgment determines that no interception is needed, the process is allowed to proceed directly; if the preliminary judgment determines that interception is necessary, the request is blocked and the relevant information is transmitted to the second module 120, while a unique identifier (i.e., request identifier) ​​is assigned to the request. Subsequently, the first module marks the process control block's state as interruptible sleep and adds it to the waiting queue, actively yielding the CPU by calling the scheduling function. At this time, the process enters a suspended state, no longer occupies CPU time, and the file operation process is also suspended.

[0026] The first module 110 can make a preliminary interception determination by checking whether the process has recently performed any modification operations on the file (e.g., within a preset time period from the current moment). If it is confirmed that the process has recently been authorized to modify the file, the first module 110 determines that there is no need to intercept the process and allows it to proceed directly; otherwise, it determines that the request needs to be intercepted.

[0027] After receiving process-related information sent by the first module 110, the second module 120 determines a feature vector based on the relevant information, selects an anomaly detection model corresponding to the relevant information from the model library, inputs the feature vector into the anomaly detection model, determines the anomaly score of the process based on the output of the anomaly detection model, and determines a conclusion based on the anomaly score. This conclusion includes whether the process is normal, malicious, or suspicious.

[0028] The model library includes multiple pre-trained anomaly detection models, each corresponding to a specific process. These models can be Isolation Forest, Random Forest, Support Vector Machine (SVM), K-Nearest Neighbors (KNN), autoencoder, or other machine learning models suitable for anomaly detection. Isolation Forest is an ensemble learning algorithm specifically designed for anomaly detection. Its core assumption is that outliers are more easily isolated in the feature space (i.e., they can be separated with fewer random partitions). This section uses Isolation Forest as an example to illustrate the concept. Before using an Isolation Forest model, it must be trained.

[0029] First, we introduce the training process of the isolated forest model required to build the model library. Taking the training of an isolated forest model for a single process as an example: First, randomly select ψ (e.g., 256) samples from the labeled normal sample set of that process to construct an isolated tree; then, randomly select a feature dimension, and randomly select a split value between the maximum and minimum values ​​of that feature. Samples with feature values ​​less than the split value are assigned to the left subtree, and samples with feature values ​​greater than or equal to the split value are assigned to the right subtree; this process is executed recursively until the tree reaches a preset depth limit (e.g., depth 8) or the leaf node contains only one sample. By repeating the above process T times (e.g., T=100), an isolated forest model containing T isolated trees can be constructed.

[0030] After receiving the relevant information about the process, the second module 120 first parses it, extracting key information such as the request identifier, process identifier (i.e., the process's identity information), operation type, target file path, and timestamp. Then, it calls the same feature extractor as in the training phase to calculate the feature vector of the current process; if missing feature values ​​are encountered (e.g., the "file owner" is unknown due to the file not existing), the median from training is used to fill in the gaps. Finally, the feature vector is Z-score standardized using the standardized parameters stored in the model corresponding to the process.

[0031] Subsequently, the second module 120 searches the model library for a matching isolated forest model based on the process identifier. If the process is determined to be a new process and there is no corresponding model in the model library, it enters cold start mode. In this mode, the second module 120 initially identifies the process as a suspicious process and reports this conclusion and reason (i.e., the model library lacks a corresponding model) to the first module 110, so that the first module 110 can output this conclusion and reason. At the same time, the system asynchronously starts a fast learning mechanism for the process: allowing the next 200 operations to proceed and collecting feature vectors; once the data reaches 200, a temporary isolated forest model (with parameters adjusted to 20 trees and a depth of 6) is immediately trained for subsequent judgment; at the same time, data continues to accumulate, and after reaching 5000, it is trained and replaced with the formal model.

[0032] If the second module 120 finds a matching isolated forest model in the model library based on the process identifier, then the feature vector is input into the isolated forest model. Each isolated tree returns a path length h(x) (the number of edges traversed from the root node to the leaf node). Then, the average of the path lengths output by all T trees is taken and normalized to an anomaly score using the following formula (1). .

[0033] (1) in, It is the expected average path length when the number of training samples is n (approximately 2H(n-1)-2(n-1) / n, where H is the harmonic number). The range is [0,1]. The closer to 1, the more abnormal (and the more likely to be isolated); The closer it is to 0, the more it conforms to normal behavioral patterns.

[0034] After determining the outlier score, the second module 120 determines a conclusion based on the relationship between the outlier score and preset first and second thresholds. Specifically, if the outlier score... If the score is less than the first threshold, the process is determined to be a normal process; when the score is abnormal... When the score is greater than or equal to the first threshold and less than the second threshold, the process is determined to be a suspicious process; when the score is abnormal... If the threshold is greater than or equal to the second threshold, the process is determined to be a malicious process. The first threshold is less than the second threshold. The first and second thresholds can be determined as needed; for example, the first threshold could be 0.3 and the second threshold 0.7; or the first threshold could be 0.4 and the second threshold 0.8.

[0035] If the second module 120 determines that the process is a normal process, the first module 110 will approve the process's request based on this conclusion; if the conclusion is that the process is a malicious process, the first module 110 will terminate the process's operation.

[0036] In this embodiment, by deploying a first module at the operating system kernel layer, forced interception of file modification requests is achieved, effectively preventing malicious processes from exploiting privilege escalation or system vulnerabilities to bypass traditional permission verification mechanisms, thus ensuring file security from the source. Simultaneously, by deploying a second module, an anomaly detection model is used to determine anomaly scores, which can then accurately identify process behavior attributes based on these scores, effectively distinguishing between normal, malicious, and suspicious processes. This behavior-based detection mechanism does not rely on pre-set signatures, thus effectively identifying unknown malicious programs, zero-day attacks, and tampering behaviors using legitimate processes. It compensates for the shortcomings of traditional security protection methods, achieving real-time blocking and prevention of file tampering risks, thereby avoiding malicious file modification.

[0037] To further prevent file tampering, in some embodiments, the file anti-tampering system 10 also includes a third module. The third module will be described below with reference to the accompanying drawings. Figure 2 Another embodiment of the document anti-tampering system provided in this application is illustrated. For example... Figure 2 As shown, the file anti-tampering system 10 also includes a third module 130.

[0038] The third module 130 can be a multi-level semantic watermarking module. Specifically, multi-level watermarks are pre-embedded in the file through the third module 130 so that when the file is accessed, the integrity of the watermark is verified to detect whether the file has been illegally tampered with, thereby preventing the file from being tampered with.

[0039] Specifically, multi-level semantic watermarking includes three layers of watermarking: the first to the third layers are file-level watermarking, structure-level watermarking, and content-level watermarking, respectively. The file-level watermark is determined by calculating the file's hash value; the structure-level watermark is determined by extracting the file's structural features (such as ELF section order, PDF object tree, and JSON key order) and performing hash operations on these features; and the content-level watermark is determined by calculating the file's semantic hash value using Locality Sensitive Hash (LSH) or perceptual hashing algorithms (such as pHash, TLSH, and simhash).

[0040] The following describes how to embed multi-level watermarks into files that need protection using the third module 130. When a new file is created in the protected directory or when the system enables anti-tamper protection for a file for the first time, three watermarks are calculated for the file and embedded into it. Specifically, when the first module 110 detects a file opening operation or a file creation operation with a creation flag, it notifies the third module 130 to generate a watermark for the file. The third module 130 reads the contents of the file and then generates three watermarks based on the read contents. The third module 130 opens the file in read-only mode, uses memory mapping technology to obtain its complete binary content, and uses a block hashing method for very large files; at the same time, it records the file's metadata information, including the inode number, file size, modification timestamp, owner user identifier, and group identifier. The first watermark L1 can be generated using the following formula (2).

[0041] L1=SHA256(file_content)(2) Here, file_content is the content of the file read.

[0042] The second-level structural watermark depends on the file type. Therefore, when determining the second-level structural watermark, the third module 130 needs to first determine the file extension. Specifically, the corresponding structure extractor can be called to determine the file extension. For ELF files, the name, type, size, and offset of each section in the Section Header Table are extracted, and the hash value is calculated after sorting by section name; the order and value of necessary items (DT_NEEDED, DT_SONAME, etc.) of the dynamic section (.dynamic) are extracted. For PE files, the order of DLL names and function names in the Import Table, the order of function names in the Export Table, and the type and ID order of the Resource Directory structure are extracted. For PDF files, the object number and generation number are parsed, the numbers of key objects (such as / Root, / Info, / Pages) are extracted, and when ignoring incrementally updated parts (appended objects), the structural features of the XRef table of the latest revision are taken, and the hash value is calculated after normalizing and sorting the keys of the object dictionary. For JSON / XML files, the file is parsed into a DOM tree, then the keys are sorted (key normalization), whitespace and comments are removed, and then the hash value is calculated. For plain text files (unstructured format), line endings are standardized to LF (Unix style), and leading / trailing whitespace lines are optionally ignored, then the hash value is calculated. For files of unknown type, the first watermark is directly used as the second watermark.

[0043] The purpose of the third-layer watermark is to perceive the "semantics" of the file content rather than the precise bits. Therefore, locality-sensitive hashing or perceptual hashing algorithms are used to determine the third-layer watermark.

[0044] For text files, the third layer of watermarking can be determined using either the Trend Micro Locality Sensitive Hash (TLSH) algorithm or the simhash algorithm. Specifically, the TLSH algorithm generates a hash value of approximately 70 characters. The difference score (diff) between two TLSH hashes effectively reflects the similarity of the text; generally, a difference score less than 50 indicates high content consistency, while a score greater than 200 signifies significant content changes. The simhash algorithm segments the text, calculates word frequency weights, and outputs a 64-bit fingerprint. A Hamming distance less than 3 is considered similar, and greater than 10 is considered different.

[0045] For image files, a third-layer watermark can be generated using the Perceptual Hash (pHash) algorithm. Specifically, the image is first scaled to 32×32 pixels and converted to grayscale. Then, the Discrete Cosine Transform (DCT) is calculated, extracting the low-frequency coefficients from the top-left 8×8 area. A 64-bit hash value is generated by comparing each coefficient with the mean. If the Hamming distance between the perceptual hash values ​​of two images is less than 10, they are considered visually similar.

[0046] For binary files (such as database files and archive files), since these files lack natural semantics, the fuzzy hashing algorithm (ssdeep) can be used to determine the third layer of watermarking. It calculates the watermark by dividing the content into blocks, enabling it to detect whether parts of the file's content have been replaced.

[0047] After determining the three watermarks, embed the three watermarks into the file, and package the three watermark values ​​and related information into structured metadata (JSON format), which is then centrally stored in the database for subsequent watermark verification.

[0048] After determining the conclusion, the second module 120 transmits the conclusion to the third module 130. The third module 130 verifies the watermark information of the file and obtains a verification result, which includes verification pass and verification fail. If the conclusion is that the process is a normal process and the verification result is verification pass, the first module 110 allows the process to proceed upon request. If the conclusion is that the process is a malicious process and the verification result is verification pass, the first module 110 continues to intercept the request. If the conclusion is that the process is a malicious process and the verification result is verification fail, the first module 110 terminates the process operation. If the conclusion is that the process is a normal process and the verification result is verification fail, the first module 110 terminates the process operation. If the conclusion is that the process is a suspicious process and the verification result is verification pass, the first module 110 allows the process to proceed upon request. If the conclusion is that the process is a suspicious process and the verification result is verification fail, the first module 110 terminates the process operation.

[0049] for Figure 2 The provided file anti-tampering system 10 employs a dual verification mechanism through the coordinated efforts of the first module 110 (real-time interception), the second module 120 (process trust determination), and the third module 130 (multi-level watermark verification). This mechanism effectively intercepts access requests from malicious processes while ensuring that legitimate processes can access untampered files. It also accurately identifies illegal file tampering and promptly terminates abnormal operations, thereby ensuring business continuity while achieving secure file management and enhancing the system's security capabilities.

[0050] In this application, preferably, if a normal process modifies a file, the third module 130 updates the watermark for the modified file in a timely manner. Specifically, if the first module 110 approves the request and the request has been completed (i.e., the file modification has been finished), the third module 130 obtains the content of the modified file and updates the multi-layer watermark information of the modified file based on the content of the modified file. That is, the first-layer file-level watermark, the second-layer structure-level watermark, and the third-layer content-level watermark are recalculated according to the aforementioned watermark generation method. Then, the newly generated three-layer watermark information is updated and stored in the database using file locks or database transactions, while retaining a copy of the old watermark (which can store the most recent N versions for audit rollback detection), adding a version number field, an update timestamp, and a file size, and re-signing it using a private key. Through the above method, the real-time synchronization of watermark information with the current state of the file is ensured, thereby avoiding false alarms caused by normal business updates of legitimate processes, and achieving the goal of ensuring file security without affecting the normal business operation of the system.

[0051] In other embodiments, if the same process performs a large number of operations within a preset time period (exceeding a preset threshold), the files requested by the process are distributed across multiple top-level directories, the process switches between multiple operation types multiple times, or the file names of the files requested by the process are named in an ascending numerical pattern (typical behavior of ransomware), it indicates that the behavior of the process matches the characteristics of a malicious process. Therefore, it is necessary to immediately intercept and terminate the operation to prevent the files from being tampered with.

[0052] Based on this, a first condition, a second condition, a third condition, and a fourth condition are preset. The first condition is: the number of operations performed by the process within a preset time period exceeds a preset threshold. The second condition is: the files requested by the process to be modified are distributed across multiple top-level directories. The third condition is: the operation type of the process switches between multiple types multiple times. The fourth condition is: the file names of the files requested by the process to be modified are named in an ascending numerical pattern.

[0053] The second module 120 records all operation information of each process within a preset time period. If the conclusion determined by the anomaly detection model is that the process is a suspicious process, it is determined whether the process meets any one of the first, second, third and fourth conditions. If the process meets any one of the first to fourth conditions, the conclusion is updated to that the process is a malicious process.

[0054] By combining the generalized detection capabilities of machine learning models with the precise judgment advantages of specific behavioral rules, the limitations of single detection methods can be overcome. This avoids false positives that may arise from relying solely on anomaly detection models, while ensuring the rapid and accurate identification and interception of malicious processes with obvious characteristics (such as high-strength encryption and wide-coverage tampering), thereby timely blocking malicious processes and enhancing the system's proactive defense capabilities.

[0055] Figure 3 This application illustrates a document anti-tampering system according to yet another embodiment. For example... Figure 3 As shown, the file anti-tampering system 10 also includes a fourth module 140. The fourth module 140 can be a policy control module. Specifically, after obtaining relevant process information, the first module 110 transmits this information to the fourth module 140. After determining a conclusion based on the anomaly detection model, the second module 120 also transmits the conclusion to the fourth module 140. Based on the relevant information and the conclusion, the fourth module 140 generates and stores a process management policy. The first module 110 preliminarily determines whether to intercept the request based on the relevant information and the process management policy stored in the fourth module 140. Specifically, the first module 110 uses the obtained process-related information (such as process name, path, hash value, etc.) as an index to perform a matching query in the policy library stored in the fourth module 140. If the process is found to be marked as malicious, the first module 110 directly determines to block the request without requiring in-depth analysis by the second module 120, thus achieving a rapid response. If the process is found to be marked as normal, the first module 110 initially determines to allow the request. If no relevant policy record is found, the first module 110 directs the request to the second module 120 for anomaly detection and analysis. After the conclusion is generated, the fourth module 140 updates the policy library to quickly determine subsequent requests from the process.

[0056] The fourth module 140 is the decision-making center of the file anti-tampering system 10. Located in user space, it receives behavioral analysis results from the second module and watermark integrity verification results from the third module. Combining these with predefined security policy rules, it generates the final access control decision (allow or deny operation) and sends the decision instruction to the first module 110 for execution via Netlink. Simultaneously, the fourth module 140 maintains the decision cache, manages policy configurations, and records audit logs.

[0057] By using the above methods, we can not only effectively avoid wasting computing resources caused by repeatedly calling the anomaly detection model for known processes and reduce system overhead, but also quickly intercept known malicious processes or allow known normal processes, thereby improving the response speed of file access control and the overall operating efficiency of the system.

[0058] Figure 4This application illustrates a document anti-tampering system according to yet another embodiment. For example... Figure 4 As shown, the file anti-tampering system 10 also includes a fifth module 150. This fifth module 150 can be a log auditing module. Specifically, the first module 110 also transmits relevant information to the fifth module 150. The second module 120 also transmits conclusions to the fifth module 150. The fifth module 150 receives and stores the relevant information and conclusions to form a complete operation audit log, providing relevant data support for subsequent security incident tracing, forensic analysis, and system behavior auditing. This ensures that file access behaviors and judgment results in the system are traceable, thereby improving the system's traceability and security compliance capabilities.

[0059] Module 5 (150) is the global recording and traceability center of the file anti-tampering system. It is responsible for collecting, standardizing, storing, querying, and forwarding audit events from all other modules (Module 1 (110), Module 2 (120), Module 3 (130), and Module 4 (140), providing security operations personnel with complete operation tracing, anomaly alarms, and compliance audit capabilities.

[0060] Audit events generated by Module 110, Module 220, Module 330, and Module 4140 are imported into a lock-free queue via UDP shared memory. After being retrieved by the event receiver, the events are filtered by a formatter and a filter. Qualified events are simultaneously written to a local JSON Lines file, sent to an SQLite index, forwarded to ELK, and triggered by the alarm engine. The entire process is asynchronous and non-blocking, ensuring high performance and low interference.

[0061] In summary, this application achieves a closed loop of "pre-interception - in-process analysis - post-interception auditing" through a three-layer architecture. The first module 110 ensures that even processes with the highest system privileges cannot bypass the protection, addressing the core shortcomings of user-space solutions. Furthermore, the second module 120, based on machine learning, accurately learns the behavioral baseline of legitimate processes, distinguishing between normal editing and malicious operations. Compared to traditional blacklist / whitelist solutions, the false positive rate is reduced by over 90%, balancing security and business availability. By embedding multi-layered watermarks into files, this progressive watermarking system balances strong integrity and robustness, solving the pain point of traditional hash verification's inability to distinguish between legitimate modifications and malicious tampering, enabling the identification of malicious encryption, content tampering, and format corruption. The first module 110 possesses multiple protection mechanisms against uninstallation, tampering, and bypassing, with end-to-end encrypted two-way authentication. Policies, models, and logs all implement integrity protection, ensuring that the protection system itself is not rendered ineffective by malicious attacks.

[0062] Furthermore, the first module 110 is deployed at the operating system kernel level. Through system call table hooks or kernel function hooking techniques, it intercepts all system calls related to opening, writing, renaming, and deleting protected files. This module acts as the first line of defense, forcibly intercepting and suspending all modification requests. This module possesses kernel-level self-protection capabilities, including but not limited to: preventing the module itself from being unloaded (e.g., intercepting system calls such as rmmod and delete_module); preventing the restoration of core kernel hooks (e.g., through read-only protection of kernel code segments and periodic verification of hook integrity); and preventing processes with root or kernel-mode privileges from modifying protected files without authorization from the policy control unit.

[0063] The second module 120 resides in user space or a highly secure Trusted Execution Environment (TEE). This module receives process-related information (including but not limited to process PID, process path, command-line arguments, parent process chain, system call sequence, and operation file path) uploaded by the first module. It uses a machine learning algorithm (Isolation Forest) to build a dynamic normal behavior model for each process (especially critical service processes). During runtime, the second module 120 compares the current operational characteristics with the model and calculates anomaly scores. If the anomaly score is below a threshold, a "allow" decision is directly generated, allowing the process to proceed; if it is above the threshold, it is determined to be abnormal behavior, triggering a deep inspection process.

[0064] Module 130 is responsible for embedding and maintaining three layers of watermark information in the protected file. File-level watermarking: A cryptographic signature is generated based on a strong hash of the file content (such as SHA-256) and metadata (such as inode number, file size, timestamp, etc.), serving as the file's unique "fingerprint" for quickly verifying the overall integrity of the file. Structure-level watermarking: Robust watermarks are embedded in insensitive areas of the file structure (such as padding, comment sections, and the data directory reserved area of ​​PE files) for specific file formats (such as ELF, PE, PDF, JPEG, etc.). This watermark can resist attacks such as format conversion and partial modification. Content-level watermarking: Based on a semantic fingerprint-based perceptual hashing algorithm (such as pHash), perceptual features of the file content are extracted. Even if the file content undergoes minor changes (such as typo correction in text or image compression), the similarity of the perceptual hashes can be calculated to determine whether the core semantics have been maliciously tampered with. This module embeds the three layers of watermarks synchronously when the file is created, and updates these three layers of watermarks synchronously each time a legitimate process updates the file after Module 140 issues an "allow" decision.

[0065] Module 4, 140, acts as the decision center, integrating the judgment results of Module 2, 120, and the verification results of Module 3, 130. Module 4, 140 executes the following logic: If Module 2, 120 determines the process to be "normal" and the watermark verification passes, it generates an "allow" decision. If Module 2, 120 determines the process to be "abnormal" but the watermark verification passes, it may be a false alarm or a rare legitimate operation; therefore, it enters the audit process and temporarily suspends the request, awaiting administrator confirmation or further analysis. If Module 2, 120 determines the process to be "abnormal" and any level of watermark verification fails, it directly generates a "reject" decision to terminate the process operation via Module 1, 110. If Module 2, 120 determines the process to be "normal" but the watermark verification fails (in rare cases, such as when the watermark is bypassed), it is determined to be an advanced bypass attack, generating a "reject" decision to terminate the process operation via Module 1, 110, and triggering a global alarm. After the decision instruction is sent to Module 1, 110, it performs either allow or terminate operations on the suspended request.

[0066] The fifth module 150 is responsible for recording audit logs throughout the entire system lifecycle, including but not limited to: all intercepted events, process context information, abnormal behavior fingerprint scores, watermark verification results, policy decisions, and administrator operations.

[0067] In the several embodiments provided in this application, any function, if implemented as a software functional module / unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or other electronic device) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0068] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0069] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In claims enumerating several means, several units or modules of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

[0070] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A document anti-tampering system, characterized in that, The system includes: a first module and a second module deployed at the operating system kernel layer; wherein... The first module is configured to: in response to detecting a file modification request initiated by a process, obtain relevant information about the process; preliminarily determine whether to intercept the request based on the relevant information; if it is preliminarily determined to intercept the request, then intercept the request and transmit the relevant information to the second module, wherein the relevant information includes the process's identity information, behavior information, operation object information, and call stack information; The second module is used to: receive the relevant information, determine a feature vector based on the relevant information, determine an anomaly detection model corresponding to the relevant information from the model library, input the feature vector into the anomaly detection model, determine the anomaly score of the process based on the output of the anomaly detection model, and determine a conclusion based on the anomaly score, wherein the conclusion includes whether the process is a normal process or a malicious process; The first module is further configured to: if the conclusion is that the process is a normal process, then proceed with the request; if the conclusion is that the process is a malicious process, then terminate the operation of the process.

2. The system according to claim 1, characterized in that, The system also includes a third module; wherein The second module is also used to: transmit the conclusion to the third module; The third module is used to: verify the watermark information of the file and obtain a verification result, wherein the file has multiple layers of watermark information embedded in it, and the verification result includes verification passed and verification failed; The first module is specifically used to: if the conclusion is that the process is a normal process and the verification result is that the verification is passed, then the request is approved; if the conclusion is that the process is a malicious process and the verification result is that the verification is passed, then the request is blocked; if the conclusion is that the process is a malicious process and the verification result is that the verification is failed, then the operation of the process is terminated; if the conclusion is that the process is a normal process and the verification result is that the verification is failed, then the operation of the process is terminated.

3. The system according to claim 2, characterized in that, The multi-layered watermark information includes file-level watermarks, structure-level watermarks, and content-level watermarks. The file-level watermark is determined by calculating the hash value of the file. The structure-level watermark is determined by extracting the structured features of the file format and performing a hash operation on the structured features. The content-level watermark is determined by calculating the semantic hash value of the file using a locality-sensitive hashing algorithm or a perceptual hashing algorithm.

4. The system according to claim 2, characterized in that, The third module is further configured to: if the first module approves the request and the request has been completed, obtain the content of the modified file, and update the multi-layer watermark information of the modified file based on the content of the modified file.

5. The system according to claim 2, characterized in that, The conclusion also includes that the process is a suspicious process. The first module is further specifically used to: when the conclusion is that the process is a suspicious process and the verification result is that the verification is passed, then the request is approved; when the conclusion is that the process is a suspicious process and the verification result is that the verification is not passed, then the operation of the process is terminated.

6. The system according to claim 2, characterized in that, The conclusion also includes that the process is a suspicious process. The second module is further used to record all operation information of each process within a preset time period. If the conclusion is that the process is a suspicious process, then it is determined whether the process meets any one of the first, second, third, and fourth conditions. If the process meets any one of the first to fourth conditions, then the conclusion is updated to that the process is a malicious process. The first condition is: the number of operations performed by the process within the preset time period exceeds a preset threshold. The second condition is that the files requested for modification by the process are distributed across multiple top-level directories; The third condition is that the operation type of the process switches between multiple types multiple times; The fourth condition is that the file name of the file that the process requests to modify is named in an incrementing numerical pattern.

7. The system according to claim 5, characterized in that, The second module is further configured to: determine that the process is a normal process when the abnormal score is less than the first threshold; determine that the process is a suspicious process when the abnormal score is greater than or equal to the first threshold and less than the second threshold or when an abnormal detection model corresponding to the relevant information cannot be determined from the model library; and determine that the process is a malicious process when the abnormal score is greater than or equal to the second threshold.

8. The system according to claim 1, characterized in that, The anomaly detection model is an isolated forest model, which contains multiple isolated trees. The second module is specifically used to: input the feature vector into the isolated forest model, obtain the output of each isolated tree, determine the average value of the output of all isolated trees, and normalize the average value to the anomaly score.

9. The system according to claim 1, characterized in that, The system also includes a fourth module; The first module is further configured to: transmit the relevant information to the fourth module; The second module is also used to: transmit the conclusion to the fourth module; The fourth module is used to: generate and store process management strategies based on the relevant information and the conclusions; The first module is specifically used to: preliminarily determine whether to intercept the request based on the relevant information and the process management strategy stored in the fourth module.

10. The system according to claim 1, characterized in that, The system also includes a fifth module; The first module is further configured to: transmit the relevant information to the fifth module; The second module is also used to: transmit the conclusion to the fifth module; The fifth module is used to receive and store the relevant information and the conclusion.

Images