A system call checking method and system based on a checking table
By generating a verification table and automatically comparing file paths and content hash values, the problem of low efficiency in file set verification in existing technologies is solved, achieving efficient and accurate file integrity verification, and meeting the needs of modern software development.
Patent Information
- Application Number
- CN202511548464.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-28
- Publication Date
- 2026-01-02
- Estimated Expiration
- 2045-10-28
AI Technical Summary
Existing technologies rely on manual operations for verifying file sets, which is inefficient and prone to errors, making it difficult to achieve efficient and accurate automated integrity verification, thus compromising data reliability.
By generating a verification table, the system automatically obtains the file path and content hash value, performs an existence and content consistency comparison, generates verification results, and encapsulates the results into a standardized application programming interface.
It achieves efficient and accurate automated verification of file sets, improves data credibility and operational efficiency, reduces the occurrence of human error, and adapts to the fast pace of modern software development.
Smart Images

Figure CN121009067B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] Embodiments of the present application relate to the field of software development, and in particular, to a system call verification method and system based on a verification table. BACKGROUND
[0002] In modern computer software engineering practice, a project or system is usually composed of hundreds or thousands of files, which are distributed in a complex directory structure. With the iteration of the project, the release of the version, and the collaboration of the team members, it is a crucial task to ensure the integrity of the file set, that is, all expected files exist and the content is not tampered with. Especially in key links such as software release, version archiving, system deployment or security audit, accurate control of the file set state is the basis for ensuring software quality and security.
[0003] Currently, the verification method of the file set mainly depends on manual operation or basic function tools; for example, according to a file list to check the file name, size and modification date one by one, which is not only extremely cumbersome and time-consuming, but also prone to human errors such as omission and misjudgment when facing a large number of files and deeply nested directories. The low efficiency and insufficient reliability of this method make it difficult to adapt to the fast-paced software development cycle.
[0004] Therefore, the prior art generally lacks a means to efficiently and accurately verify the integrity of the entire file set systematically and automatically, which makes it difficult to effectively guarantee data reliability and poses a great challenge to software configuration management. SUMMARY
[0005] Embodiments of the present application provide a system call verification method and system based on a verification table to at least solve the problem of low verification accuracy in related technologies.
[0006] According to an embodiment of the present application, a system call verification method based on a verification table is provided, comprising:
[0007] Obtaining a reference verification table, the reference verification table containing a plurality of reference records, each reference record including at least a reference file path and a reference content hash value of a file corresponding to the reference file path;
[0008] Obtaining a plurality of current file paths currently existing in a target directory structure to form a current file path set;
[0009] Comparing the current file path set with the plurality of reference file paths contained in the reference verification table for existence to determine a first path set with inconsistent file existence states;
[0010] The present application has the advantages of high accuracy, high efficiency, and high reliability.obtaining a current file corresponding to the matching file path based on each matching file path existing in the current file path set and the reference file path, and calculating a current content hash value of the current file;
[0011] comparing the current content hash value with the reference content hash value corresponding to the matching file path recorded in the reference check table to determine a second path set with inconsistent file content;
[0012] generating a check result based on the first path set and the second path set.
[0013] In an exemplary embodiment, before the reference check table is obtained, the method further comprises:
[0014] recursively traversing all files under the target directory structure to obtain a plurality of reference file paths in response to a check table generation instruction;
[0015] obtaining file content corresponding to each reference file path and calculating a reference content hash value;
[0016] combining the reference file path and the reference content hash value corresponding thereto into the reference record, and forming the reference check table based on all generated reference records.
[0017] In an exemplary embodiment, the method further comprises:
[0018] encapsulating the generation of the check result and the verification function as a standardized application programming interface.
[0019] In an exemplary embodiment, the method further comprises:
[0020] aggregating all first path sets and the second path set;
[0021] assigning different abnormal weights to different types of path sets according to a preset weight model;
[0022] calculating a structure entropy value based on the abnormal weight and the number of each type of path.
[0023] In an exemplary embodiment, the method further comprises:
[0024] comparing the structure entropy value with a preset entropy threshold value;
[0025] generating an abnormal event report if the structure entropy value is greater than the entropy threshold value.
[0026] According to another embodiment of the present application, a system call check system based on a check table is provided, comprising:
[0027] reference data collection module, configured to acquire a reference check table, the reference check table containing a plurality of reference records, each of the reference records including at least a reference file path and a reference content hash value of a file corresponding to the reference file path;
[0028] set formation module, configured to acquire a plurality of current file paths currently existing in a target directory structure, and form a current file path set;
[0029] first set module, configured to perform existence comparison between the current file path set and a plurality of reference file paths contained in the reference check table, to determine a first path set of file existence state inconsistency;
[0030] hash value module, configured to acquire a current file corresponding to each matched file path existing in both the current file path set and the reference file path, and calculate a current content hash value of the current file;
[0031] second set module, configured to perform consistency comparison between the current content hash value and the reference content hash value recorded in the reference check table and corresponding to the matched file path, to determine a second path set of file content inconsistency;
[0032] result module, configured to generate a check result based on the first path set and the second path set.
[0033] In an example embodiment, the method further includes:
[0034] traversal module, configured to, before the acquiring of the reference check table, recursively traverse all files under the target directory structure in response to a check table generation instruction, to acquire a plurality of reference file paths;
[0035] reference hash module, configured to acquire file content corresponding to each of the reference file paths, and calculate the reference content hash value;
[0036] reference check module, configured to combine the reference file path and the reference content hash value corresponding thereto into the reference record, and form the reference check table based on all generated reference records.
[0037] In an example embodiment, the method further includes:
[0038] packaging module, configured to package the generation of the check result and the verification function into a standardized application program interface.
[0039] According to still another embodiment of the present application, there is also provided a computer readable storage medium having stored therein a computer program, wherein the computer program is arranged to perform the steps of any of the method embodiments described above when executed by a processor.
[0040] According to still another embodiment of the present application, there is also provided an electronic device comprising a memory having stored therein a computer program and a processor arranged to execute the computer program to perform the steps of any of the method embodiments described above.
[0041] The present application can solve the problem of low verification accuracy and improve the verification accuracy by centralizing and structurally managing the dispersed file attribute information (path, hash value, metadata), automatically generating a verification table, and automatically comparing the verification table with the current file system state (existence comparison and content integrity comparison). BRIEF DESCRIPTION OF DRAWINGS
[0042] Figure 1 is a flow chart of a system call verification method based on a verification table according to an embodiment of the present application;
[0043] Figure 2 is a structural block diagram of a system call verification system based on a verification table according to an embodiment of the present application. DETAILED DESCRIPTION
[0044] The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments of the present application.
[0045] Hereinafter, the terms "first", "second", and the like are used only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first", "second", and the like can explicitly or implicitly include one or more of the features. In the description of the present application, unless otherwise specified, the meaning of "a plurality of" is two or more.
[0046] In addition, in the present application, the orientation terms such as "up", "down", "left", "right", and the like can include but not limited to the orientation defined by the relative position of the components in the drawings. It should be understood that these directional terms can be relative concepts, which are used for relative description and clarification, and can be changed accordingly according to the change of the position of the components in the drawings.
[0047] In the present application, unless specifically defined and limited otherwise, the term "connected" shall be construed broadly, for example, "connected" can be a fixed connection, or a detachable connection, or an integral connection; can be a direct connection, or an indirect connection through an intermediate medium. In addition, the term "coupled" can be an electrical connection mode that realizes signal transmission.
[0048] As used herein, "about," "approximately," or "around" includes the recited value and the average value within an acceptable range of deviation from the specific value, wherein the acceptable range of deviation is determined by a person of ordinary skill in the art considering the measurement being discussed and the error related to the measurement of the specific quantity (i.e., the limitation of the measurement system).
[0049] "Check table", refers to a data file organized in CSV format, used to record the metadata information of multiple target files, including but not limited to file storage path, creation timestamp, file size and MD5 hash value generated based on file content.
[0050] The core use of the check table is to realize the centralized management and integrity check of file attributes. By structurally summarizing the file attribute information originally distributed in the deep directory structure, quick review, consistency comparison and content integrity verification of all file states in a single table are realized, thereby significantly reducing the complexity of file management, improving data reliability and operation efficiency.
[0051] The generation of the check table can rely on manual operation or simple script tool assistance, which is tedious, time-consuming and prone to human error. Specifically, manual creation of the check table requires the following steps: first, the operator needs to traverse the target directory layer by layer in the file system, and manually record the storage path of each file; then, the attribute information of each file needs to be viewed in turn, the creation time and file size are extracted, and these data are entered into the spreadsheet one by one; finally, the command line tool (such as md5sum) needs to be called to calculate the MD5 hash value of each file separately, and the result needs to be manually copied and pasted to the corresponding position of the table.
[0052] This process has significant defects: first, when faced with a large number of files or deep directory structures, the workload of manual traversal and entry grows exponentially, and the efficiency is extremely low; second, manual operation cannot avoid problems such as missing files, incorrect path filling, or copying incorrect check values, which leads to incomplete or distorted check table data, seriously affecting the reliability of the check table as a basis for data integrity; third, once the file set is added, deleted or updated, the entire check table needs to be manually rebuilt, which has high maintenance cost and is not scalable and sustainable.
[0053] Therefore, the artificial method of creating the check table is not only complicated and labor-intensive, but also difficult to guarantee the accuracy and consistency of the data, and cannot meet the basic requirements of modern data management for efficiency, automation and reliability.
[0054] To this end, the application provides a system call check method based on a check table, which can automatically generate a check table and automatically check the generated check table, so as to meet the requirements of high efficiency and high reliability of modern data management.
[0055] The generation of the check table includes the following steps:
[0056] Step S101, in response to a check table generation instruction, recursively traversing all files under the target directory structure to obtain a plurality of reference file paths;
[0057] In this embodiment, according to the root directory path specified by the user, a file system access interface is called to recursively traverse all subdirectories and files under the path to generate a complete file path list. This process supports filtering of specific file types to meet the data collection needs in different application scenarios.
[0058] Specifically, the system receives a check table generation instruction triggered externally or internally, which contains at least one key parameter: the root path of the target directory structure (root_path), which defines the file range to be covered by this operation. In addition, the instruction can also include some optional configuration parameters, such as the specified file name for outputting the check table, the rule set for filtering files, etc. After receiving the instruction, the system initializes the necessary internal data structures, such as a list for temporarily storing the file paths to be processed and a collection for storing the final generated check records. In order to ensure the robustness of the processing process, the system will first verify whether the specified root path exists and is readable. If the path is invalid, the process is terminated and an error message is returned.
[0059] Suppose a development team has completed the development of a software version named "Phoenix v1.0", and all final deliverables are organized and stored under the D:\Releases\Phoenix_v1.0\ directory on the server; later, an operation and maintenance engineer needs to create a verification baseline for this version to check against when deploying to the production environment later; at this time, the engineer triggers the generation operation through a command-line tool or a graphical interface, enters the root path as D:\Releases\Phoenix_v1.0\, and specifies the generated verification table file name as phoenix_v1.0_checksum.csv; after the system background receives this request, it first checks whether the D:\Releases\Phoenix_v1.0\ directory exists; after confirming that it exists, the system creates an empty list in memory, such as file_records_list, for storing structured information extracted from each file later; at the same time, it may parse some global configurations, such as determining the hash algorithm as MD5, or loading a global ignore file list (such as the rules defined in.gitignore), which are part of the initialization; this startup process ensures that all subsequent operations are performed in a valid and expected context, avoiding invalid calculations due to input errors or environmental problems
[0060] Step S102, based on each of the reference file paths, obtaining the corresponding file content and calculating the reference content hash value;
[0061] In this embodiment, based on the obtained file path list, attribute collection operations are performed on each file in turn; for example, metadata information of each file is read through system API, including file absolute path, creation time, file size, and file last modification timestamp; at the same time, an encryption hash algorithm module (MD5 algorithm) is called to calculate the MD5 hash value of the file content; to improve processing efficiency and ensure data consistency, all collected attribute information and calculated MD5 values are temporarily stored in the memory cache area to form a structured temporary data set.
[0062] Among them, the extraction of metadata includes obtaining a series of metadata describing the external characteristics of the file by calling the file system API provided by the operating system.
[0063] Step S103, combining the reference file path and the reference content hash value corresponding thereto into the reference record, and forming the reference verification table based on all generated reference records.
[0064] In this embodiment, after the information collection and hash calculation of all files are completed, the temporary data set in the cache is organized into a table format according to a predefined field order (such as file path, creation time, file size, MD5 value), and written into a specified output file in CSV (Comma-Separated Values) format. The generated check table can be directly opened and parsed by general spreadsheet software, realizing centralized display of file attributes, and also providing for subsequent verification.
[0065] On the basis of generating the check table, the application further automatically checks the file integrity and consistency of the check table to verify whether the target file set has file loss, addition or content tampering in the subsequent use, transmission or storage process; specifically including the following steps:
[0066] Step S11, a reference check table is obtained, the reference check table contains a plurality of reference records, and each reference record includes at least a reference file path and a reference content hash value of a file corresponding to the reference file path;
[0067] In this embodiment, the "check table" data generated in the history is read, and the file path list recorded therein and the hash value of the file content corresponding to the path are extracted, so as to facilitate subsequent comparison and judgment.
[0068] Specifically, by reading the CSV file line by line, the title line is skipped, and each line of data is parsed into a structured record object, and then the records are loaded into a hash table (or dictionary) data structure with the file path as the key and the object containing the hash value and other metadata as the value.
[0069] Step S12, a plurality of current file paths currently existing in the target directory structure are obtained to form a current file path set;
[0070] In this embodiment, the system takes the target directory root path specified in the verification instruction as the starting point, recursively traverses, and applies the same filtering rules as when generating the check table. The purpose of this is to ensure that the verification range and the reference range are strictly equal, avoiding false positives due to inconsistent ranges.
[0071] Specifically, according to the root path information in the check table or the user-specified path, the actual file directory in the current file system is recursively traversed to obtain a list of currently existing file paths (i.e., the current file path set).
[0072] For example, the system traverses the C:\WebApp\Phoenix\ directory on the production server, and it is assumed that some accidents have occurred during deployment:
[0073] 1. PluginA.dll file failed to copy successfully.
[0074] 2. A debug tool, DebugHelper.exe, that should not exist was mistakenly copied over.
[0075] 3. configs\main.xml file was manually modified by system administrator after deployment to adapt to production environment.
[0076] After applying the filter rule, the system traverses the generated current file path set to: ['C:\WebApp\Phoenix\PhoenixApp.exe', 'C:\WebApp\Phoenix\Core.dll', 'C:\WebApp\Phoenix\configs\main.xml', 'C:\WebApp\Phoenix\DebugHelper.exe']
[0077] Step S13, compare the current file path set with the reference file paths contained in the reference check table to determine the first path set with inconsistent file existence status;
[0078] In this embodiment, the two lists are compared to identify missing files in the current system (i.e. present in the original check table but not present in the current directory) and newly added files (i.e. present in the current directory but not recorded in the original check table); all inconsistent items are marked as "file list abnormal" and their paths and abnormal markers are cached to the check error queue.
[0079] Specifically, efficient set operations are used to perform this comparison, which specifically includes:
[0080] Identify missing files: the system takes all file paths in the reference check table (reference_paths) as a set and the generated current file path set (current_paths) as another set, then calculates the difference set reference_paths - current_paths, the result is all files that exist in the benchmark but cannot be found in the current system, these files are marked as "missing" (MISSING).
[0081] Identify added files: calculate the difference set current_paths - reference_paths, the result is all files that exist in the current system but are not recorded in the benchmark, these files are marked as "added" (ADDED).
[0082] After all the identified inconsistencies (including file paths and inconsistency types) are added to a temporary verification difference queue (i.e., the first path collection) and wait for final summary.
[0083] Step S14, based on each matching file path existing in the current file path set and the reference file path, the current file corresponding to the matching file path is obtained, and the current content hash value of the current file is calculated;
[0084] In this embodiment, after comparing consistency, integrity needs to be compared to avoid data tampering; Specifically, for the files (i.e., the paths are consistent and the files exist) in the current file path list that match the verification table record, the key attributes are compared one by one, and the key attributes include the content hash value and the like.
[0085] Step S15, the current content hash value is compared with the reference content hash value recorded in the reference verification table corresponding to the matching file path to determine the second path set of inconsistent file contents;
[0086] In this embodiment, the focus of consistency comparison is to verify whether the file content has changed: the current file content MD5 hash value can be calculated, and the original MD5 value of the corresponding record in the verification table is compared; If the two are inconsistent, it is determined that the file content has been modified or damaged, marked as
content integrity exception
[0087] The system first determines the file range that needs to be verified, and then for each file path in the intersection, the system performs the following operations:
[0088] 1. Read the actual file corresponding to the path in the current system;
[0089] 2. The content hash value of the current file is calculated by using the same hash algorithm (such as MD5) as when generating the reference verification table, and the current_hash is obtained;
[0090] 3. According to the file path, the reference hash reference_hash is found from the loaded memory hash table reference_data_map;
[0091] 4、Compare the current_hash and reference_hash. If the two strings are identical, it proves that the file content has not been changed, and the verification is passed. If the two strings are not identical, it indicates that the file content has been modified or damaged, and the file path is marked as "content integrity exception" (MODIFIED), and is added to the difference queue as a difference record together with the expected hash value and the actually calculated hash value.
[0092] Step S16, generating a verification result based on the first path set and the second path set.
[0093] In this embodiment, after the verification process is completed, the error information in the cache is summarized and analyzed. If the error queue is empty, a "verification passed" result is output, indicating that the file set is complete and the content has not been changed. If there is any abnormal record, the verification error queue is output to the CSV format verification error list for user review.
[0094] Specifically, after all the comparison processes are completed, the system checks the final "verification difference queue".
[0095] If the queue is empty: This indicates that the current file set is completely consistent with the reference benchmark, and there is no missing, added or modified content. At this time, the system outputs a clear success status information, such as "verification passed, file set complete and consistent".
[0096] If the queue is not empty: This indicates that one or more differences are detected; at this time, the system formats all the difference information in the queue into a detailed, human-readable report; in order to facilitate automated processing and archiving, the report is preferably also in CSV format, which clearly lists the path of each problem file, the type of difference (MISSING, ADDED, MODIFIED), and for content modification, it also provides the expected hash value and the actual hash value for in-depth investigation. This report provides precise diagnostic information for operation and maintenance personnel, enabling them to quickly locate problems and take corrective measures.
[0097] It should be noted that, in order to improve the universality and integrability of the technical solution, facilitate unified calling in different project engineering, and further encapsulate the generation and verification functions of the verification table as a standardized application program interface.
[0098] In an optional embodiment, in order to further detect changes in the data structure, the method further comprises:
[0099] Step S17, aggregating all the first path set and the second path set;
[0100] Step S18, different abnormal weights are assigned to different types of path sets according to a preset weight model;
[0101] Step S19, structural entropy is calculated based on the abnormal weights and the number of each type of path.
[0102] In the embodiment, the structural entropy is used to quantify the degree of disorder or disorder of the current file integrity structure compared with the initial state. If there is no change, the structural entropy is 0, indicating that it is in the most ordered state. The occurrence of any abnormal state will increase the structural entropy of the system.
[0103] Specifically, the structural entropy is calculated based on a preset weight model. The model assigns different deviation weights (w) to different types of abnormal states. These weights reflect the threat degree of different types of abnormal time to the system integrity. Generally speaking, the modification of the core file content is the most serious, followed by the deletion of the file, and finally the increase of the file. These weight values can be configured by the system administrator according to the risk preference of the specific application scenario. For example:
[0104] The weight of file content change (modification)
[0105] The weight of file deletion (deletion)
[0106] The weight of file increase (increase)
[0107] The calculation formula of the structural entropy is defined as the weighted sum of all abnormal events: .
[0108] For this, the administrator can make a stability judgment of the file structure according to the preset entropy threshold. For example, if the calculated structural entropy is lower than the threshold, it can be considered that the system is in an acceptable stable state. On the contrary, if it exceeds the threshold, it indicates that the system may have suffered serious changes that need immediate attention, thereby triggering an alarm or further review process.
[0109] After the checksum and structural entropy are calculated, the system generates a report of abnormal events:
[0110] For example:
[0111] 1. Event type (DELETED, ADDED, MODIFIED);
[0112] 2. File path;
[0113] 3. For MODIFIED events, the baseline content identifier and the current content identifier should also be included for tracing and analysis.
[0114] 4. Other attributes of the file, such as size, modification time, etc.
[0115] The top of the report can also contain summary information of this check, such as the check time, scanned root directory, total number of files, total number of deviation events, and calculated structural entropy value, and the like.
[0116] From the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and necessary general hardware platforms, and of course can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, and the computer software product is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk), and includes a plurality of instructions for causing a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present application.
[0117] In the present embodiment, a system call verification system based on a verification table is also provided, which is used to implement the above embodiments and preferred embodiments, and will not be described again. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware, or a combination of software and hardware is also possible and is contemplated.
[0118] Figure 2 is a structural block diagram of a system call verification system based on a verification table according to an embodiment of the present application, as shown in Figure 2 , the system includes:
[0119] a reference data acquisition module for acquiring a reference verification table, the reference verification table containing a plurality of reference records, each of the reference records including at least a reference file path and a reference content hash value of a file corresponding to the reference file path;
[0120] a set forming module for acquiring a plurality of current file paths currently existing in a target directory structure, and forming a current file path set;
[0121] a first set module for performing existence comparison between the current file path set and the plurality of reference file paths contained in the reference verification table, to determine a first path set with inconsistent file existence states;
[0122] a hash value module configured to obtain a current file corresponding to each matched file path existing in both the current file path set and the reference file path, and to calculate a current content hash value of the current file;
[0123] a second set module configured to compare the current content hash value with a reference content hash value corresponding to the matched file path recorded in the reference check table, to determine a second path set in which the file content is inconsistent;
[0124] a result module configured to generate a check result based on the first path set and the second path set.
[0125] In an optional embodiment, the method further comprises:
[0126] a traversal module configured to recursively traverse all files under the target directory structure to obtain a plurality of reference file paths in response to a check table generation instruction before the reference check table is obtained;
[0127] a reference hash module configured to obtain a file content corresponding to each reference file path and to calculate a reference content hash value;
[0128] a reference check module configured to combine the reference file path and the reference content hash value corresponding thereto into a reference record, and to form the reference check table based on all generated reference records.
[0129] In an optional embodiment, the method further comprises:
[0130] a packaging module configured to package the generation of the check result and the inspection function into a standardized application program interface.
[0131] It should be noted that each of the above modules can be implemented by software or hardware, and for the latter, the following implementation manners can be used, but are not limited thereto: all of the above modules are located in the same processor; or each of the above modules is located in a different processor in any combination.
[0132] Embodiments of the present application also provide a computer readable storage medium having a computer program stored therein, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.
[0133] In an example embodiment, the computer readable storage medium described above can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.
[0134] Embodiments of the present application also provide an electronic device including a memory and a processor, the memory storing a computer program, and the processor configured to execute the computer program to perform the steps in any of the method embodiments described above.
[0135] In an example embodiment, the electronic device described above can further include a transmission device connected to the processor and an input and output device connected to the processor.
[0136] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.
[0137] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative, such as the division of modules or units, which is only a logical function division, and actual implementation can have another division manner, such as combining or integrating multiple units or components into another device, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0138] The units described as separate components can or can not be physically separated, and the components shown as units can be one physical unit or multiple physical units, that is, they can be located in one place or distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.
[0139] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.
[0140] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application essentially or say the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The software product is stored in a storage medium, including a plurality of instructions to make a device (which can be a single-chip microcomputer, a chip, etc.) or a processor execute all or part of the steps of the various embodiments of the present application method. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.
[0141] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any change or replacement within the technical scope disclosed in the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims
1. A method of checking system calls based on a check table, characterized by, The method comprises: obtaining a reference check table, the reference check table comprising a plurality of reference records, each reference record comprising at least a reference file path and a reference content hash value of a file corresponding to the reference file path; obtaining a plurality of current file paths currently existing in a target directory structure to form a current file path set; performing existence comparison between the current file path set and the plurality of reference file paths contained in the reference check table to determine a first path set of files with inconsistent existence states; based on each matching file path existing in both the current file path set and the reference file path set, obtaining a current file corresponding to the matching file path and calculating a current content hash value of the current file; performing consistency comparison between the current content hash value and the reference content hash value recorded in the reference check table and corresponding to the matching file path to determine a second path set of files with inconsistent contents; generating a check result based on the first path set and the second path set.
2. The method of claim 1, wherein, Before the step of obtaining the reference check table, the method further comprises: in response to a check table generation instruction, recursively traversing all files under the target directory structure to obtain a plurality of reference file paths; based on each reference file path, obtaining the corresponding file content and calculating the reference content hash value; combining the reference file path and the corresponding reference content hash value into the reference record, and forming the reference check table based on all generated reference records.
3. The method of claim 1, wherein, The method further comprises: encapsulating the generation of the check result and the verification function into a standardized application programming interface.
4. The method of claim 1, wherein, The method further comprises: aggregating all first path sets and second path sets; assigning different abnormal weights to different types of path sets according to a preset weight model; calculating a structure entropy value based on the abnormal weights and the number of each type of path.
5. The method of claim 4, wherein, The method further comprises: comparing the structure entropy value with a preset entropy threshold value; if the structure entropy value is greater than the entropy threshold value, generating an abnormal event report.
6. A checksum system for system calls based on a checksum table, characterized in that The method comprises: a reference data acquisition module for obtaining a reference check table, the reference check table comprising a plurality of reference records, each reference record comprising at least a reference file path and a reference content hash value of a file corresponding to the reference file path; a set forming module for obtaining a plurality of current file paths currently existing in a target directory structure to form a current file path set; a first set module for performing existence comparison between the current file path set and the plurality of reference file paths contained in the reference check table to determine a first path set of files with inconsistent existence states; a hash value module for, based on each matching file path existing in both the current file path set and the reference file path set, obtaining a current file corresponding to the matching file path and calculating a current content hash value of the current file; The second set module is configured to compare the current content hash value with the reference content hash value recorded in the reference check table and corresponding to the matched file path, to determine a second path set in which the file contents are inconsistent. The result module is configured to generate a check result based on the first path set and the second path set.
7. The system of claim 6, wherein, Further comprising: The traversal module is configured to recursively traverse all files under the target directory structure to obtain a plurality of reference file paths in response to a check table generation instruction before the reference check table is obtained. The reference hash module is configured to obtain the file content corresponding to each reference file path and calculate the reference content hash value based on the file content. The reference check module is configured to combine the reference file path and the reference content hash value corresponding thereto into the reference record, and form the reference check table based on all generated reference records.
8. The system of claim 6, wherein, Further comprising: The packaging module is configured to package the generation of the check result and the verification function into a standardized application program interface.
9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, wherein the computer program is configured to execute the method in any one of claims 1 to 5 when running. 10.An electronic device comprising a memory and a processor, the electronic device characterized by, The memory stores a computer program, and the processor is configured to execute the computer program to execute the method in any one of claims 1 to 5.
Citation Information
Patent Citations
Method, device and equipment for detecting process camouflage and storage medium
CN116881911A
Data consistency verification method and device, computer equipment, storage medium and computer program product
CN119576903A