File checking method, file signing method, device, equipment and storage medium

Abstract

This application discloses a file verification method, a file signing method, an apparatus, a device, and a storage medium. The verification method includes: decrypting a private signature in a file to be verified using a public key to obtain a first entry point offset value and a first code segment digest value of the file to be verified; extracting a second entry point offset value from the file header of the file to be verified, and calculating a second code segment digest value of the code segment of the file to be verified; and verifying the file to be verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value. This scheme achieves dual verification of the integrity and consistency of the executable file by jointly signing the code segment digest value and the entry point offset value, and by cross-comparing the corresponding verification parameters obtained from the private signature inside the file with those from the file header and code segment during the verification phase.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a file verification method, a file signing method, an apparatus, a device, and a storage medium. Background Technology

[0002] With the continuous evolution of operating system security mechanisms and software distribution systems, file integrity verification has become an important technical means to ensure the reliable operation of software.

[0003] Existing technologies verify the integrity and source trustworthiness of files during storage and distribution by digitally signing them, thereby preventing malicious tampering or program forgery. However, in practical applications, file verification based on digital signatures still has significant technical limitations and cannot meet the comprehensive requirements of file authenticity and execution security in high-security operating environments. Traditional verification methods generally rely on the trustworthiness of the local root certificate chain. When the local root certificate is maliciously replaced or contaminated, even if the digital signature verification process executes normally, it may still produce incorrect verification results, thus weakening the overall security protection capability. Summary of the Invention

[0004] This application provides a file verification method, file signing method, apparatus, device, and storage medium, which solves the problems in existing technologies where executable file verification processes rely on a single signature result, are easily forged or bypassed, and are difficult to effectively detect file tampering. This solution can effectively prevent forgery attacks implemented through file splicing, code replacement, etc., improving the security and reliability of file verification. It is suitable for software distribution, program startup verification, and file integrity protection scenarios in high-security operating environments.

[0005] Firstly, this application provides a document verification method, including: The private signature in the file to be verified is decrypted using the public key to obtain the first entry point offset and the first code segment digest value of the file to be verified. Extract the second entry point offset value from the file header of the file to be verified, and calculate the second code segment digest value of the code segment of the file to be verified. The file to be verified is verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value.

[0006] Secondly, this application provides a document signing method, including: Obtain the file to be signed, and extract the code segment from the file to be signed to obtain the first code segment; The digest value of the first code segment is calculated from the first code segment; Obtain the first entry point offset value of the file to be signed, and combine the first code segment digest value and the first entry point offset value to obtain the original signature data; The original signature data is encrypted using a private key to obtain a private signature, and a verification file is generated based on the private signature and the file to be signed.

[0007] Thirdly, this application provides a document verification device, comprising: The signature decryption module is used to decrypt the private signature in the file to be verified using the public key, and obtain the first entry point offset value and the first code segment digest value of the file to be verified. The second offset extraction module is used to extract the second entry point offset value at the file header of the file to be verified. The second digest calculation module is used to calculate the second code segment digest value of the code segment of the file to be verified. The file verification module is used to verify the file to be verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value.

[0008] Fourthly, this application provides a document signing device, comprising: The first code extraction module is used to obtain the file to be signed and extract the code segment of the file to be signed to obtain the first code segment. The first digest calculation module is used to calculate the digest value of the first code segment. The signature combination module is used to obtain the first entry point offset value of the file to be signed, and combine the first code segment digest value and the first entry point offset value to obtain the original signature data. The file generation module is used to encrypt the original signature data using a private key to obtain a private signature, and to generate a verification file based on the private signature and the file to be signed.

[0009] Fifthly, this application provides a document verification device, comprising: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the file verification method as described in the first aspect.

[0010] In a sixth aspect, this application provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the file verification method as described in the first aspect.

[0011] In this application, a file verification mechanism based on private signature parsing and consistency comparison of key parameters of the execution file is constructed to reliably verify the integrity and legitimacy of the file to be verified. Upon receiving the file to be verified on the client side, the private signature embedded in the file is first parsed. A pre-set public key is used to decrypt the private signature, thereby obtaining the first entry point offset value and the first code segment digest value bound to the file, which serve as the verification benchmark information generated during the original file signature stage. After decrypting the private signature, the second entry point offset value corresponding to the current file is extracted from the file header of the file to be verified, and a hash calculation is performed on the code segment of the file to be verified to obtain the second code segment digest value, reflecting the actual structure and content characteristics of the file in its current state. Subsequently, the decrypted first entry point offset value and first code segment digest value are comprehensively compared with the second entry point offset value and second code segment digest value extracted and calculated in real time. The file to be verified is then judged based on the comparison results. Through the above verification process, dual verification of the file entry point consistency and code segment integrity is achieved, effectively identifying illegal tampering behavior that occurs during file distribution, storage, or loading. This scheme improves the accuracy and security of file verification results through the collaborative verification design of signature data and key file structural parameters. It is suitable for client program startup verification, software distribution integrity verification, and terminal operating environments with high security requirements. Attached Figure Description

[0012] Figure 1 This is a flowchart of a file verification method provided in an embodiment of this application; Figure 2 This is a flowchart of a private signature decryption method provided in an embodiment of this application; Figure 3 This is a flowchart of a memory consistency verification method provided in an embodiment of this application; Figure 4 This is a flowchart of a memory address relocation method provided in an embodiment of this application; Figure 5 This is a flowchart of a document signing method provided in an embodiment of this application; Figure 6 This is a flowchart illustrating the steps of a document signing and verification method provided in an embodiment of this application; Figure 7 This is a structural block diagram of a document verification device provided in an embodiment of this application; Figure 8 This is a structural block diagram of a document signing device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a document verification device provided in an embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as being processed sequentially, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. A process can be terminated when its operation is completed, but it may also have additional steps not included in the drawings. A process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0015] Currently, with the continuous evolution of operating system security mechanisms and the ongoing expansion of software distribution, the integrity and trustworthiness of executable files during installation, updates, and operation have become key factors in ensuring system security and stable operation. Whether in terminal devices, server systems, or enterprise applications and critical infrastructure environments, preventing executable files from being maliciously tampered with, forged, or hijacked is one of the core technical issues in software security systems.

[0016] In current technological practices, the verification of executable file integrity typically relies on digital signature mechanisms. Verifying the file's signature information confirms whether the file's origin and content have been altered. This method provides a certain level of security during file distribution and storage, and is therefore widely used in operating system program loading, application installation, and software updates. However, with the continuous evolution of attack methods, verification methods relying solely on traditional digital signatures have gradually revealed significant technical limitations in real-world environments, failing to cover the complex security risks faced by executable files during loading and execution. On one hand, existing digital signature verifications mostly target static files on disk, with the verification process usually occurring before or in the early stages of file loading. Once the file passes verification and is loaded into memory, if a malicious program tampers with the code or data segments in memory during subsequent execution, traditional verification mechanisms typically cannot continuously or re-verify the loaded memory image, creating a security blind spot where memory tampering is difficult to detect in a timely manner. This problem is particularly prominent in high-privilege processes, long-running services, and applications with dynamic loading capabilities. On the other hand, existing technologies generally rely on local root certificate chains to establish a foundation of trust. However, in complex operating environments or compromised systems, the trustworthiness of local root certificates is not always reliable. When root certificates are maliciously replaced, tampered with, or forged, even if the digital signature verification process executes normally according to established rules, it may produce verification results inconsistent with the actual security state, thereby weakening the protection capabilities of the entire file verification system.

[0017] Furthermore, traditional digital signature verification schemes typically integrate verification logic in plaintext within the client or system loading process, lacking effective protection for the verification process itself. Once attackers analyze the verification process, they can circumvent integrity verification through injection, hooking, or bypassing of the verification logic, rendering the verification mechanism ineffective. This risk is particularly pronounced in highly adversarial operating environments. Existing executable file digital signature verification schemes are inadequate in areas such as integrity checks during memory execution, root certificate trust assurance, and security protection of the verification process itself, failing to meet the requirements of high-security operating environments for full lifecycle integrity verification of executable files. Therefore, there is an urgent need for an improved file verification technology that can cover both file loading and execution phases, reduce reliance on local trust, and provide security protection for the verification process itself, thereby enhancing the overall system security and reliability.

[0018] To address the problems of existing executable file verification processes relying on a single signature result, limited verification dimensions, and difficulty in accurately identifying file tampering, this embodiment provides a file verification method for clients. By introducing a verification mechanism based on private signature parsing and consistency comparison of key file structural parameters, a file integrity verification system with multi-parameter joint verification capabilities is constructed, enabling reliable determination of the authenticity and consistency of the file to be verified. This method uses the file to be verified obtained from the client side as the verification object. During the verification process, the pre-embedded private signature in the file to be verified is first parsed. A pre-set public key is used to decrypt the private signature, thereby obtaining the first entry point offset value and the first code segment digest value bound to the file to be verified, which serve as the original verification benchmark information generated during the signing stage. Through the above steps, a correspondence between signature data and key file structural parameters is established. After decrypting the private signature, the second entry point offset value corresponding to the current file is further extracted from the file header of the file to be verified, and the code segment of the file to be verified is hashed to obtain the second code segment digest value, which reflects the actual entry position and code segment content characteristics of the file in the current state. Subsequently, the decrypted first entry point offset value and first code segment digest value are comprehensively compared with the real-time extracted and calculated second entry point offset value and second code segment digest value. Based on the comparison results, the file to be verified is judged, thus completing a complete verification closed loop from signature parsing to consistency verification. Through the above verification process, joint verification of file entry point consistency and code segment integrity is achieved, effectively avoiding the security risks caused by relying solely on a single signature result, and improving the ability to identify abnormal behaviors such as file tampering, splicing, or replacement. This solution significantly enhances the accuracy and security of client-side file verification through the collaborative design of multi-dimensional verification parameters, possesses good versatility and scalability, and is suitable for application scenarios such as program startup verification, software distribution integrity verification, and terminal operating environments with high security requirements.

[0019] Figure 1 A flowchart of a file verification method provided in an embodiment of this application is given. (Reference) Figure 1 The specific methods for verifying this file include: S110. Use the public key to decrypt the private signature in the file to be verified, and obtain the first entry point offset value and the first code segment digest value of the file to be verified.

[0020] In some embodiments, the file to be verified may be an executable file that requires integrity and legality verification. The private signature may be signature information formed by encrypting the verification data based on a private key during the file generation or distribution stage. The public key may be a verification key paired with the private key. The first entry point offset value may be an offset parameter written in the signing stage and used to identify the file entry position. The first code segment digest value may be a digest feature value calculated from the file code segment content during the signing stage. After entering the file verification process, the private signature carried in the file to be verified is decrypted using the public key. The first entry point offset value and the first code segment digest value are parsed from the decryption result and used as the benchmark data for subsequent file consistency verification.

[0021] In one embodiment, the method of decrypting a private signature using a public key can be: calling an asymmetric encryption decryption algorithm to perform a decryption operation on the private signature data to obtain the original verification data containing the first entry point offset value and the first code segment digest value.

[0022] In one embodiment, the method for obtaining the first entry point offset value and the first code segment digest value may be: according to a preset data encapsulation format, the decrypted original verification data is parsed, and the entry point offset field and the code segment digest field are extracted and stored respectively to obtain the first entry point offset value and the first code segment digest value.

[0023] In one embodiment, before decrypting the private signature using the public key, the method further includes: verifying the integrity of the private signature, such as verifying whether the decryption result conforms to the expected data length or structural rules, in order to avoid misjudgment of verification due to signature tampering or decryption failure.

[0024] Optionally, Figure 2 A flowchart of a private signature decryption method provided in an embodiment of this application is given. (Reference) Figure 2 The private signature decryption method specifically includes: S1101. Receive the file to be verified and perform digital signature verification on the file to be verified.

[0025] For example, the file to be verified can be an executable file or object file that requires integrity and source trust verification. The digital signature can be verification information generated based on an asymmetric encryption mechanism during the file publication or distribution stage, used to prove the integrity of the file content and the legitimate identity of the signer. At the beginning of the file verification process, the file to be verified is first received, and the digital signature carried by the file is verified to initially confirm that the file has not been tampered with during transmission or storage, and that the signature source conforms to the expected trust policy.

[0026] In one embodiment, the file to be verified can be received by reading from local storage, downloading from the network, or importing from external media, and a preliminary check on the file format and basic integrity can be performed after receiving the file.

[0027] In one embodiment, digital signature verification can be performed by parsing the digital signature data in the file to be verified, obtaining the corresponding signature certificate or public key information, and verifying the signature result using a standard digital signature verification algorithm.

[0028] In one embodiment, digital signature verification can be performed by checking the validity period, trust chain, and revocation status of the signature certificate while verifying the validity of the signature, so as to ensure that the signature verification result meets the system security policy requirements.

[0029] In one embodiment, digital signature verification may include verification methods based on operating system code signing systems, general digital signature verification methods based on X.509 certificate systems, digital signature verification methods based on national cryptographic systems, verification methods based on application-level signature encapsulation, and verification methods based on package-level or container-level signatures. Among these methods, the verification method based on the operating system code signing system can use the Authenticode mechanism of the Windows platform to verify the signature in executable files or dynamic link libraries, verifying the signature certificate chain, certificate validity period, and revocation status to confirm the legality and integrity of the file source; the general digital signature verification method based on the X.509 certificate system verifies digital signatures generated using algorithms such as RSA and ECDSA, confirming that the file has not been tampered with by verifying the consistency between the certificate chain and the signature value; the digital signature verification method based on the national cryptographic system can use the SM2 digital signature algorithm and the SM3 digest algorithm to verify the signature of executable files or data files that conform to the national cryptographic standards to meet specific compliance or industry requirements; the verification method based on application-level signature encapsulation verifies custom signature data appended by the application system to the end of the file, the header of the file, or an independent signature area, verifying the signature value through a pre-set public key or certificate to achieve file integrity verification independent of the operating system; and the verification method based on package-level or container-level signatures can verify the signature of manifest files in installation packages, compressed packages, or image files, indirectly confirming the integrity of the internal file set by verifying the signature results of the manifest content.

[0030] S1102. If the digital signature verification passes, extract the private signature from the file to be verified.

[0031] For example, a successful digital signature verification indicates that the outer digital signature verification result of the file to be verified is valid. The private signature can be the signature payload formed by the signer encrypting the internal verification data using a private key during the file generation stage. After confirming that the digital signature verification result is successful, the internal verification stage begins, where the private signature data is extracted from the file to be verified, providing input for subsequent public key-based decryption and consistency verification.

[0032] In one embodiment, the private signature can be extracted by locating the private signature data at a specified offset position or in the additional data area of ​​the file to be verified according to a preset file structure or encapsulation format, and reading it completely to obtain the private signature.

[0033] In one embodiment, the method for extracting a private signature may be: parsing the extended header field or custom segment information in the file to be verified, determining the area where the private signature is located by the segment identifier or type identifier, and extracting the corresponding private signature.

[0034] In one embodiment, the method for extracting a private signature may be to perform a legality check on the length, format, or verification mark of the private signature data during the extraction process to ensure that the extracted private signature is not truncated, misaligned, or abnormal, thereby avoiding interference with the subsequent decryption and verification process.

[0035] S1103. Use the public key to decrypt the private signature to obtain the first entry point offset value and the first code segment digest value of the file to be verified.

[0036] For example, the public key can be a verification key paired with the private key used in the signing phase; the private signature can be a signature payload formed by encrypting internal verification data during the file generation phase; the first entry point offset value can be an offset parameter used to identify the actual entry position of the file; and the first code segment digest value can be a digest feature value calculated from the file code segment content during the signing phase. After successfully extracting the private signature data, the public key is used to decrypt the private signature, and the first entry point offset value and the first code segment digest value are parsed from the decryption result as benchmark data for subsequent file structure consistency and code integrity verification.

[0037] In one embodiment, the private signature can be decrypted by calling a preset asymmetric encryption and decryption algorithm to perform decryption operations on the private signature data, thereby obtaining an original verification data block containing a first entry point offset value and a first code segment digest value.

[0038] In one embodiment, the method for obtaining the first entry point offset value and the first code segment digest value may be: parsing the fields of the decrypted data according to a predefined data encapsulation format, and extracting and storing the first entry point offset value and the first code segment digest value into the verification context respectively.

[0039] In one embodiment, before decryption using the public key, the method further includes: verifying the integrity and legality of the decryption result, such as verifying whether the data length, field order, or verification identifier conforms to expected rules, in order to prevent verification anomalies caused by corrupted or forged signature data.

[0040] S120. Extract the second entry point offset value at the file header of the file to be verified, and calculate the second code segment digest value of the code segment of the file to be verified.

[0041] In some embodiments, the file to be verified can be an executable file or a target file that requires integrity and legality verification. The file header can be a header area describing the file structure and loading information. The second entry point offset value can be the relative offset address of the entry point recorded in the file header. The code segment can be a target segment in the file used to store executable instructions. The second code segment digest value can be a verification feature value obtained by performing a digest calculation on the code segment content. The algorithm used for digest calculation can be a message digest algorithm, a cryptographic hash algorithm, or a keyed integrity verification algorithm. After entering the file verification process, the file header information is extracted from the file to be verified, the second entry point offset value is parsed to obtain the second entry point offset value, and a digest calculation is performed on the code segment content of the file based on this to generate the second code segment digest value, which serves as an important basis for subsequent consistency verification.

[0042] In one embodiment, the second entry point offset value can be extracted by parsing the file header structure of the file to be verified, reading the relative offset address of the entry point from the entry point field, and using the offset address as the second entry point offset value.

[0043] In one embodiment, the method for calculating the second code segment digest value may be: locating the start position and length of the code segment in the file according to the file format definition, performing a preset digest algorithm operation on the code segment data, and obtaining the corresponding second code segment digest value.

[0044] In one embodiment, the hash algorithm can be MD5, SHA-1, SHA-256 / SHA-512, SHA-3, SM3, BLAKE2 / BLAKE3, CRC32 / CRC64, and HMAC-SHA256, etc. MD5 performs an MD5 operation on code segment data to obtain a 128-bit hash value, suitable for scenarios sensitive to performance overhead and prioritizing fast consistency verification; SHA-1 performs an SHA-1 operation on code segment data to obtain a 160-bit hash value, serving as a lower-cost hash verification scheme; SHA-256 / SHA-512 performs an SHA-2 operation on code segment data to obtain a 256-bit or 512-bit hash value, possessing higher collision resistance and suitable for file verification scenarios with higher requirements for anti-forgery capabilities; SH... A-3 is a hash algorithm based on the Keccak structure and can be used as an alternative hash scheme under certain compliance or security policy requirements; SM3 is a Chinese national cryptographic hash algorithm that generates a 256-bit digest value for code segment data and is suitable for scenarios that need to meet specific compliance or domestic cryptographic system requirements; BLAKE2 / BLAKE3 has better throughput performance while ensuring strong security and is suitable for scenarios that are sensitive to digest calculation performance but still require high integrity protection; CRC32 / CRC64: Cyclic Redundancy Check algorithm, mainly used for transmission error detection or lightweight consistency check, with low computational overhead but weak security strength; HMAC-SHA256 calculates message authentication codes based on shared keys for code segment data and is used in scenarios that need to verify that "the data has not been tampered with" and at the same time verify "the source is trustworthy".

[0045] In some embodiments, based on the risk level of the distribution link of the file to be verified, the performance budget, and the compliance requirements, any of the above-mentioned digest algorithms can be selected to operate on the code segment data to obtain a second code segment digest value, and then the consistency comparison is performed with the first code segment digest value obtained by decrypting the private signature.

[0046] In one embodiment, the second code segment digest value can be calculated by: standardizing the code segment data before performing digest calculation, for example, removing padding bytes or alignment bytes, and then generating a digest value based on the standardized code segment data to obtain the second code segment digest value, so as to improve the stability and consistency of the verification results.

[0047] S130. Verify the file to be verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value.

[0048] In some embodiments, the first entry point offset value can be an entry point offset parameter obtained by decrypting the private signature using a public key; the second entry point offset value can be an entry point offset parameter directly parsed from the header of the file to be verified; the first code segment digest value can be a code segment digest feature generated during the signing stage and encapsulated with the private signature; and the second code segment digest value can be a digest feature recalculated during the verification stage to obtain the current code segment content of the file to be verified. After obtaining the above entry point offset value and code segment digest value, integrity and legality verification are performed on the file to be verified based on a multi-parameter consistency verification strategy to determine whether the file content has been tampered with or replaced.

[0049] In one embodiment, the method for verifying the file to be verified may be: comparing whether the first entry point offset value and the second entry point offset value are consistent, so as to verify the matching relationship between the signature data and the current file structure and prevent bypassing the verification by replacing the entry point or splicing other legitimate file content.

[0050] In one embodiment, the method for verifying the file to be verified may be: comparing whether the first code segment digest value and the second code segment digest value are consistent, so as to confirm that the code segment content of the file to be verified has not been modified after the signature is generated, thereby realizing the verification of the integrity of the executable instructions.

[0051] In one embodiment, the verification of the file to be verified can be performed as follows: if the entry point offset value and the code segment digest value are consistent, the file to be verified is determined to pass the verification; if any comparison result is inconsistent, the file to be verified is determined to fail the verification, and a processing mechanism such as refusing to load, blocking execution, or abnormal alarm is triggered.

[0052] Optionally, Figure 3 A flowchart of a memory consistency verification method provided in an embodiment of this application is given. (Reference) Figure 3 The memory consistency verification method specifically includes: S1301. If the first entry point offset value is consistent with the second entry point offset value and the first code segment digest value is consistent with the second code segment digest value, execute the file to be verified to load the file to be verified into the execution memory space managed by the system.

[0053] For example, the first entry point offset value and the first code segment digest value can be verification benchmark parameters obtained by decrypting the private signature using a public key. The second entry point offset value and the second code segment digest value can be current file parameters directly parsed and calculated from the file to be verified during the verification phase. The execution memory space can be a process loading memory region uniformly managed by the operating system or runtime environment, used to hold the code segment and runtime data of the executable file. After completing the entry point offset value consistency verification and the code segment digest consistency verification, if the two sets of entry point offset values ​​are consistent and the two sets of code segment digest values ​​are consistent, it is determined that the structure and content of the file to be verified have not been tampered with, thereby allowing the loading operation of the file to be verified to be executed.

[0054] In one embodiment, the method of executing and loading the file to be verified may be: calling the program loading interface provided by the operating system to map the file to be verified to the execution memory space managed by the system, and completing the program entry point location based on the entry point offset value to start the execution process corresponding to the file.

[0055] In one embodiment, the method of executing and loading the file to be verified can be as follows: before loading it into the execution memory space, the file is relocated and its memory layout is initialized so that the code segment, data segment and runtime dependencies meet the requirements of the current system environment, and then the execution is started from the entry point.

[0056] In one embodiment, the method of executing and loading the file to be verified may further include: recording the file verification pass status and loading time information during the loading process for use in auditing, anomaly tracing, or subsequent security policy judgment, thereby improving the system's controllability over the executable file's execution process while ensuring security.

[0057] S1302. Load the file to be verified into the process's private first verification memory space.

[0058] For example, the first verification memory space can be a private memory region allocated by the operating system to the current process. This region holds the memory image of the file to be verified without affecting the system's global execution environment. "Process-private" means that this memory space is only visible to the current verification process and cannot be directly accessed by other processes. The loading module can be a functional component used for file mapping, memory allocation, and access permission settings. After completing the basic verification process for the file to be verified, the file is loaded into the process-private first verification memory space so that the file content can be further parsed, verified, or prepared for execution in an isolated environment.

[0059] In one embodiment, the file to be verified can be loaded into the first verification memory space by mapping the file to be verified to the process's private address space through a memory mapping mechanism, and setting read-only or restricted execution permissions for the mapped area to prevent accidental modification during the verification phase.

[0060] In one embodiment, the file to be verified can be loaded into the first verification memory space by copying only the necessary segments of the file to the verification memory space during the loading process, thereby reducing memory usage and reducing the potential attack surface.

[0061] In one embodiment, before loading the file to be verified into the first verification memory space, the method further includes: performing access integrity checks or memory layout verification on the data in the verification memory space after loading is completed, to ensure that the loading result is consistent with the expected file structure, thereby providing a reliable basis for subsequent memory-level verification or execution decisions.

[0062] S1303. Perform memory consistency verification on the file to be verified based on the execution memory space and the first verification memory space.

[0063] For example, the execution memory space can be a memory region loaded by the operating system and used for the actual execution of the program, the first verification memory space can be a process-private verification memory region isolated from the execution environment, the memory consistency verification can be a verification process used to determine whether the contents of the same file are consistent in different memory images, and the consistency verification module can be a functional component used to perform memory comparison and result determination. After the file to be verified is loaded into the execution memory space and the first verification memory space respectively, the consistency verification of the file content is performed based on these two memory images to confirm that the file has not undergone memory-level tampering or abnormal modification during loading, relocation, or runtime preparation.

[0064] In one embodiment, the memory consistency verification method may be: extracting the corresponding code segment or key data segment from the execution memory space and the first verification memory space respectively, calculating the memory digest value of the extraction result, and determining the content consistency of the two memory images by comparing whether the digest values ​​are consistent.

[0065] In one embodiment, the memory consistency verification method may be: according to a preset memory address mapping relationship, compare the corresponding memory pages in the execution memory space and the first verification memory space page by page to detect whether there are byte-level differences, thereby improving the granularity of consistency verification.

[0066] In one embodiment, the memory consistency verification method may further include: ignoring relocation addresses, runtime padding fields, or other non-deterministic memory regions during the comparison process, and only performing consistency verification on deterministic code instruction regions and key control data, so as to avoid misjudgment due to differences in normal loading.

[0067] Optionally, Figure 4 A flowchart of a memory address relocation method provided in an embodiment of this application is given. (Reference) Figure 4 The memory address relocation method specifically includes: S13031. Read the execution memory space to obtain the base address of the file to be verified.

[0068] For example, the execution memory space can be the actual running memory region allocated by the operating system for the file to be verified during the program loading phase. The base address can be the starting address of this memory region in the process's virtual address space, used as a reference benchmark for subsequent address calculation, relocation processing, and memory consistency verification. In the memory consistency verification process, the memory mapping information of the execution memory space is read to determine the base address of the file to be verified in the current process, providing a unified address benchmark for subsequent content location and comparison operations based on memory offsets.

[0069] In one embodiment, the base address can be read by querying the process memory mapping table or the list of loaded modules maintained by the operating system, and obtaining the starting address of the file to be verified as the base address from the corresponding module mapping record.

[0070] In one embodiment, the base address can be read by parsing the module description structure generated by the program loader during the loading process, extracting the image base address field from it, and obtaining the corresponding base address in the execution memory space.

[0071] In one embodiment, after reading the base address, the method further includes: verifying the legality of the base address, for example, confirming that the address falls within the process's private address space and matches the expected load size, so as to avoid subsequent verification deviations due to abnormal mapping or address tampering.

[0072] S13032. Relocate the address in the first verification memory space according to the base address to obtain the second verification memory space.

[0073] For example, the base address can be the actual starting address of the file to be verified in the execution memory space. The first verification memory space can be a process-private initial memory image used for verification purposes. Relocation can be a process of correcting the addresses of content in memory that involves address references based on the actual load address. The second verification memory space can be a verification memory image obtained after address relocation, which is consistent with the address system of the execution memory space. After obtaining the base address corresponding to the execution memory space, the relevant addresses in the first verification memory space are relocated based on the base address to generate the second verification memory space, so that the verification memory image is consistent with the actual execution memory image at the address level.

[0074] In one embodiment, the relocation can be performed by parsing the relocation information table corresponding to the file to be verified in the first verification memory space, correcting the memory content involving absolute or relative addresses according to the relocation entries recorded therein, and generating a second verification memory space that has completed the relocation.

[0075] In one embodiment, the relocation can be performed by: performing a uniform address offset correction on the code segment and related data segment in the first verification memory space, adjusting the address reference under the original assumed base address to the actual running address starting from the base address, and obtaining the second verification memory space after address correction, thereby eliminating the impact of the difference in loading base address.

[0076] In one embodiment, the relocation process may include: correcting only the deterministic address regions that need to participate in consistency verification during the relocation process, and performing an integrity check on the relocation result to obtain a second verification memory space, so as to ensure that the second verification memory space is comparable to the execution memory space in terms of address structure and content layout.

[0077] S13033. Perform memory consistency verification on the file to be verified based on the execution memory space and the second verification memory space.

[0078] For example, the execution memory space can be the actual running memory image allocated by the operating system for the file to be verified, and the second verification memory space can be a verification memory image obtained after address relocation that is consistent with the address system of the execution memory space. Memory consistency verification can be a verification process used to determine whether the two memory images are consistent at the critical content level. After generating the second verification memory space, memory consistency verification is performed on the file to be verified based on the execution memory space and the second verification memory space to confirm that the file has not undergone memory-level tampering or abnormal modification during loading, relocation, and runtime preparation.

[0079] In one embodiment, the memory consistency verification method may be as follows: extract the corresponding code segment or other preset key memory region from the execution memory space and the second verification memory space respectively, calculate the memory digest value of the extracted content, and compare whether the digest results are consistent in order to determine the consistency of the two memory images.

[0080] In one embodiment, memory consistency verification can be performed by comparing the corresponding memory pages or blocks in the execution memory space and the second verification memory space page by page or block by block according to a unified address mapping relationship, thereby detecting whether there are byte-level differences and improving the accuracy of consistency verification.

[0081] In one embodiment, the memory consistency verification method may further include: excluding relocation tables, runtime padding areas or other non-deterministic memory regions during the comparison process, and performing consistency verification only on deterministic code instruction regions and critical control data, so as to avoid interference from normal loading differences on the verification results.

[0082] Optionally, the step of performing memory consistency verification on the file to be verified based on the execution memory space and the second verification memory space includes: A hash calculation is performed on the code segment of the file to be verified in the execution memory space to obtain a first hash value.

[0083] For example, the execution memory space can be the actual running memory region allocated by the operating system for the file to be verified, the code segment can be a deterministic memory region in memory where the file to be verified stores executable instructions, and the first hash value can be a fixed-length verification feature generated after performing a hash operation on the code segment content, used to characterize the integrity status of the code content in the current execution memory. During the memory consistency verification process, the code segment data corresponding to the file to be verified is located and read from the execution memory space, and a hash calculation is performed on the code segment to obtain the first hash value, which provides a basis for subsequent comparison with the verification memory space or historical benchmark data.

[0084] In one embodiment, the method for performing hash calculation in memory space may be as follows: based on the starting address and length information of the code segment in the execution memory space, sequentially read the memory data of the code segment, and perform a preset hash algorithm operation on the read data to generate the corresponding first hash value.

[0085] In one embodiment, the method for performing hash calculations in memory space can be as follows: before reading code segment data, the memory region is aligned or non-instruction padding bytes are filtered out, and then a hash operation is performed based on the standardized code segment data to generate the corresponding first hash value, thereby improving the consistency of hash results under different operating environments.

[0086] In one embodiment, the method of performing hash calculations on memory space may include: during the hash calculation process, combining code segment access permissions and memory protection status, marking or alerting memory pages that are abnormally writable or modified, thereby enhancing the ability to detect runtime tampering while generating the first hash value.

[0087] A hash calculation is performed on the code segment of the file to be verified in the second verification memory space to obtain a second hash value.

[0088] For example, the second verification memory space can be a verification memory image obtained after address relocation, whose address system is consistent with the execution memory space. The code segment can be the executable instruction area corresponding to the file to be verified in the verification memory image. The second hash value can be a verification feature value generated after performing a hash operation on the code segment content, used to characterize the integrity status of the code content in the verification memory space. In the memory consistency verification process, the system locates and reads the code segment data corresponding to the file to be verified from the second verification memory space through the hash calculation module, performs a hash calculation on the code segment to obtain the second hash value, which can be used as the verification basis for consistency comparison with the calculation result of the execution memory space.

[0089] In one embodiment, the hash calculation of the verification memory space can be performed by sequentially reading the corresponding memory data according to the starting address and length information of the code segment in the second verification memory space, and performing a preset hash algorithm operation on the read data to generate a second hash value.

[0090] In one embodiment, the method for performing hash calculation on the verification memory space can be as follows: before performing hash calculation, perform standardization processing on the code segment data in the verification memory space, such as filtering out alignment padding bytes or non-deterministic content, and then generate a second hash value based on the standardized data to improve the comparability with the result of performing memory space calculation.

[0091] In one embodiment, the method for verifying the hash calculation of the memory space can be: checking the memory page attributes in the verification memory space during the hash calculation process to confirm that the code segment is in a read-only or restricted modification state, thereby enhancing the ability to detect abnormal memory behavior while generating a second hash value.

[0092] The file to be verified is subjected to memory consistency verification based on the first hash value and the second hash value.

[0093] For example, the first hash value can be a verification feature obtained by hashing the code segment of the file to be verified in the execution memory space, and the second hash value can be a verification feature obtained by hashing the corresponding code segment in the second verification memory space. Memory consistency verification can be a verification process that determines the file's runtime security by comparing the consistency of code segment content under different memory images. After obtaining the first hash value and the second hash value, the two are compared, and memory consistency verification is performed on the file to be verified based on the comparison result to determine whether there is any memory-level tampering or abnormal modification behavior in the file during the loading, relocation, and runtime preparation stages.

[0094] In one embodiment, the memory consistency check can be performed by determining that the code segment content in the execution memory space and the verification memory space is consistent if the first hash value and the second hash value are completely identical, thereby confirming that the file to be checked has passed the memory consistency check.

[0095] In one embodiment, the memory consistency verification method may be: if the first hash value and the second hash value are inconsistent, it is determined that there is a difference in the code segments in the two memory images, and the file to be verified is marked as having failed to perform memory verification, so as to trigger subsequent processing such as blocking execution, abnormal alarm or security audit.

[0096] In one embodiment, the memory consistency verification process may further include: when the hash value comparison fails, recording the memory region identifier where the difference occurred, the verification time point, and the runtime environment information for subsequent problem tracing and security analysis, thereby enhancing system protection capabilities while improving operational auditability.

[0097] Optionally, Figure 5 A flowchart of a file signing method provided in an embodiment of this application is given. (Reference) Figure 5 The specific methods for signing this file include: S210. Obtain the file to be signed, and extract the code segment of the file to be signed to obtain the first code segment.

[0098] For example, the file to be signed can be an executable file or object file that needs to generate integrity and source verification information. The code segment can be a deterministic data area in the file used to store executable instructions. The first code segment can be a set of code data extracted from the file to be signed and used for subsequent digest calculation and signature generation. At the beginning of the signing process, the file to be signed is first obtained, the file structure of the file to be signed is parsed, and the corresponding code segment data is extracted from it to form the first code segment, which provides the basic input for subsequent code segment digest calculation and signature data encapsulation.

[0099] In one embodiment, the first code segment can be extracted by parsing the file header information according to the format specification of the file to be signed, determining the starting offset and length of the code segment in the file, and reading the first code segment within that range.

[0100] In one embodiment, the first code segment can be extracted by: after parsing the file structure, extracting only the deterministic code instruction region that participates in the signature verification, excluding non-deterministic content such as relocation tables, padding areas, or debugging information, thereby obtaining the first code segment to improve the stability of the signature result under different loading environments.

[0101] In one embodiment, before extracting the first code segment, the process may include performing an integrity check or boundary check on the code segment data during the extraction process to ensure that the range of data read is consistent with the file structure definition, thereby avoiding the problem of inconsistent signature data due to abnormal segment information.

[0102] S220. Calculate the first code segment to obtain the first code segment digest value.

[0103] For example, the first code segment can be a set of code data extracted from the file to be signed, used to represent the core execution logic of the program. The digest value of the first code segment can be a fixed-length feature value obtained by performing a digest calculation on the code data, used to uniquely represent the content state of the first code segment. After obtaining the first code segment, a calculation process is performed on the first code segment to generate the corresponding digest value of the first code segment, which serves as the key basis for subsequent signature data generation and integrity verification.

[0104] In one embodiment, the method for calculating the digest value of the first code segment may be: performing a preset hash digest algorithm operation on the first code segment data to map the variable-length code data into a fixed-length digest result, thereby generating the digest value of the first code segment.

[0105] In one embodiment, before calculating the digest value of the first code segment, the method further includes: standardizing the first code segment data, such as unifying the byte order, removing padding bytes, or aligning data, thereby improving the consistency of the digest results under different environments or different file construction conditions.

[0106] In one embodiment, the method of calculating the digest value of the first code segment may further include: recording the digest algorithm identifier and parameter information used during the digest calculation process, and storing or encapsulating them together with the digest value of the first code segment, so as to accurately reproduce the digest calculation process in the subsequent verification stage and avoid verification failure caused by algorithm mismatch.

[0107] S230. Obtain the first entry point offset value of the file to be signed, and combine the first code segment digest value and the first entry point offset value to obtain the original signature data.

[0108] For example, the first entry point offset value can be an entry address offset parameter used to locate the program's starting position when the file to be signed is loaded or executed; the first code segment digest value can be an integrity feature value calculated from the first code segment; and the original signature data can be a data payload that encapsulates the aforementioned key verification parameters according to a preset format and is used for subsequent encryption or signing processing. After obtaining the first code segment digest value, the file header or related structural information of the file to be signed is further parsed to obtain the corresponding first entry point offset value. This entry point offset value is then combined with the first code segment digest value to generate private signature data representing both the file structure and code content characteristics.

[0109] In one embodiment, the first entry point offset value can be obtained by parsing the file header structure of the file to be signed, reading the relative offset value of the entry address from the entry point field, and using it as the first entry point offset value.

[0110] In one embodiment, the original signature data can be generated by concatenating the first entry point offset value and the first code segment digest value to form a private signature according to a preset data encapsulation order, so as to ensure that the signature data can be correctly parsed during the verification stage.

[0111] In one embodiment, after the original signature data is generated, the method further includes: introducing a length identifier, a verification mark, or version information to structurally encapsulate the combined private signature data, thereby improving the compatibility and scalability of the private signature under different version files or different verification strategies.

[0112] S240. Encrypt the original signature data using the private key to obtain a private signature, and generate a verification file based on the private signature and the file to be signed.

[0113] For example, the original signature data can be structured verification data obtained by combining the first code segment digest value and the first entry point offset value. The private key can be an asymmetric encryption key configured in pair with the public key, used to perform encryption processing on the original signature data. The private signature can be a signature payload formed by encryption with the private key, used to decrypt and recover the original verification data using the public key during the verification phase. The file to be verified can be a target file generated by embedding the private signature on the file to be signed. After generating the original signature data, the original signature data is encrypted using the private key to obtain the corresponding private signature, and the private signature is combined with the file to be signed to generate the file to be verified containing internal verification information.

[0114] In one embodiment, the original signature data can be encrypted by calling a preset asymmetric encryption algorithm to perform encryption operations on the original signature data, generating a private signature that can only be correctly decrypted using the corresponding public key, thereby ensuring the unforgeability of the signature data.

[0115] In one embodiment, the method for generating the file to be verified may be: writing the private signature into a preset additional area, extended header field, or file tail of the file to be signed, and recording the corresponding offset information in the file structure to generate the file to be verified, so that the private signature can be accurately located and extracted during the verification stage.

[0116] In one embodiment, after generating the file to be verified, the process may further include: performing format verification and integrity checks on the generated file to be verified after completing the private signature embedding, to confirm that the structural relationship between the private signature data and the file header and code segment is consistent, thereby avoiding file parsing errors or loading failures caused by signature embedding.

[0117] Optionally, Figure 6 A step-by-step diagram of a file signing and verification method provided in an embodiment of this application is given. (Reference) Figure 6 The specific methods for signing and verifying this file include: S301. The server generates a public-private key pair that supports asymmetric encryption and decryption.

[0118] For example, the asymmetric key pair can be a public key and a private key generated on the server side. The private key is used to encrypt the signature information to form private signature data that can only be decrypted or verified by the corresponding public key. The public key is used on the client side to perform decryption or verification operations on the signature information encrypted with the private key, thereby realizing a file verification process based on an asymmetric encryption and decryption mechanism. The private signature can be a signature data payload that characterizes the integrity and structural features of the file, obtained by combining a first code segment digest value and a first entry point offset value.

[0119] In one embodiment, the public-private key pair can be generated by generating a pair of private and public keys with a mathematical relationship on the server side based on a preset asymmetric encryption algorithm. The private key is used to encrypt private signature data, and the public key is used to decrypt or verify the corresponding encryption result to ensure that the party holding only the public key cannot deduce the content of the private key.

[0120] In one embodiment, the public-private key pair can be generated by calling a cryptographic security module or encryption library to generate a key seed based on a random number source, and by combining the key length, algorithm type and security parameter configuration to derive the corresponding private key and public key, thereby ensuring that the generated key pair meets the security strength requirements and is suitable for subsequent signature encryption and verification processes.

[0121] In one embodiment, after the public-private key pair is generated, the process may further include: performing validity or consistency verification on the generated public-private key pair to confirm that the public key can correctly decrypt or verify the signature data encrypted by the corresponding private key; and configuring secure storage or access control for the private key and distributing or embedding the public key, thereby providing a reliable key foundation for subsequent signature generation and file verification processes based on asymmetric encryption and decryption mechanisms.

[0122] S302. The server uses its private key to perform private and digital signatures on the file to be processed, thus obtaining the file to be verified.

[0123] For example, a private signature can be performed by: extracting the first code segment related to code execution from the file to be processed, and calculating the corresponding first code segment digest value based on the first code segment; wherein, the code segment can be a text segment used to carry the core execution logic, and the first code segment digest value is used to characterize the integrity status of the code segment content.

[0124] In one embodiment, after obtaining the first code segment digest value, the first entry point offset value of the executable file to be distributed can also be obtained, and the first code segment digest value and the first entry point offset value are combined to form a private signature to be encrypted. The first entry point offset value is used to characterize the relative position of the code execution start point in the executable file within the file structure. By binding the first entry point offset value with the first code segment digest value, a correspondence can be established between the private signature and the structural features of the file.

[0125] In one embodiment, the original signature data is encrypted using a private key held by the server to obtain a private signature. This private signature is then appended to a preset append area or the end of the executable file to be distributed, thereby generating a target file containing the private signature data while maintaining the original file execution logic. By introducing a first entry point offset value into the private signature, signature forgery or signature reuse attacks can be effectively avoided. For example, without the constraint of the first entry point offset value, an attacker might embed another legitimate executable file and its corresponding signature into the target file, causing the verification process to incorrectly verify the illegal code content using the legitimate signature. However, by binding the signature data to the entry point offset value, the verification phase can verify the consistency between the signature data and the current file structure based on the entry point offset value, thereby blocking the forgery path of transplanting an external legitimate signature into an illegal file and preventing the overall verification process from failing.

[0126] In one embodiment, after embedding the private signature, a third-party digital signature can be performed on the generated target file to obtain the file to be verified. For example, a code signing process based on the operating system's trust chain can be executed. Integrity checks are performed on non-code segment data (excluding core code segments) to prevent tampering of private signature data, resource segments, or other structured data during distribution or loading. By introducing import tables or system dependencies associated with standard signature processes, the target file exhibits more complex structural features during static and reverse analysis, thereby increasing the cost of reverse analysis and creating an incentive mechanism to counteract analytical behavior. This makes attackers expend more effort during analysis and more likely to expose their analytical actions.

[0127] S303. The client performs digital signature verification on the file to be verified.

[0128] For example, when an externally distributed executable file is loaded by the operating system and enters the runtime environment, the verification logic can be triggered first to perform third-party digital signature verification on the file to be verified, i.e., the executable file. The third-party digital signature verification is used to verify whether the executable file has been tampered with during distribution, storage, or loading, and to confirm that the executable file originates from a trusted signing entity.

[0129] In one embodiment, the method for performing third-party digital signature verification may be: calling the code signature verification mechanism provided by the operating system to perform integrity and trustworthiness verification on the system-level digital signature carried in the executable file; if the verification passes, allowing subsequent custom verification logic to continue to execute; if the verification fails, blocking the subsequent verification process or terminating program loading to prevent illegal or tampered executable files from entering the running state.

[0130] In one embodiment, third-party digital signature verification can be code signature verification based on the operating system's trust chain, used to at least verify the file content corresponding to non-core code segments or non-custom verification data, thereby providing a first layer of security at the system level for subsequent verification processes based on private signatures.

[0131] S304. The client uses the public key to perform private signature verification on the file to be verified.

[0132] For example, after the third-party digital signature verification passes, the verification logic continues to execute the data verification process based on the private signature. Specifically, the pre-embedded private signature can be located and read from the executable file, where the private signature is a signature payload generated based on the private key and stored along with the file.

[0133] In one embodiment, after reading the private signature data, the private signature data is decrypted using the public key paired with the private key to obtain the original signature data; wherein, the original signature data includes at least a first code segment digest value and a first entry point offset value, the first code segment digest value is used to characterize the integrity status of the text segment in the executable file, and the first entry point offset value is used to characterize the relative position of the starting position of code execution in the executable file in the file structure.

[0134] In one embodiment, the verification logic can also extract the second entry point offset value corresponding to the current executable file from the file header information of the executable file, and compare the second entry point offset value with the first entry point offset value to determine whether the entry point offset value recorded in the private signature data is consistent with the structural information of the current executable file.

[0135] In one embodiment, if the entry point offset value verification passes, the verification logic further extracts the current text segment data from the executable file and calculates the second code segment digest value based on the digest algorithm consistent with the signature stage; then, the second code segment digest value is compared with the first code segment digest value to confirm that the core code segment of the executable file has not been tampered with during distribution or loading.

[0136] Through the above steps, on the basis of passing the system-level digital signature verification, a further dual verification of the core code segment content and structural characteristics of the executable file can be completed based on the private signature, thereby improving the ability to identify forgery, tampering or signature reuse, and preventing illegal files from entering the running state through the verification process.

[0137] S305. Load the file to be verified in both the execution memory space and the verification memory space.

[0138] For example, after completing consistency comparisons based on entry point offsets and code segment digest values, if all verification results meet the preset consistency conditions, it can be preliminarily determined that the executable file has not been tampered with and is legitimate. At the same time, the fact that the executable file can be successfully loaded by the operating system and enter the running state also indicates that the executable file's file structure, dependencies, and execution environment all meet the system loading requirements.

[0139] In one embodiment, after confirming that the executable file has passed the above verification and has completed system-level loading, the verification logic can further map the executable file to a private memory space, i.e., the verification memory space, through memory mapping. The private memory space can be a memory region that is only visible to the current process and is not shared with other processes, used to host subsequent custom verification logic or critical execution code.

[0140] In one embodiment, loading the executable file into a private memory space via memory mapping can avoid direct reliance on the public image already loaded by the operating system, i.e., the execution memory space. This allows subsequent access to and analysis of code segments, data segments, or execution logic to be based on a private memory copy, thereby reducing the impact of external process injection, debugging, or memory tampering on the verification process and improving security and resistance to analysis during runtime.

[0141] Through the above processing, after verifying the legality and integrity of the file, the executable file is loaded into the private memory space, providing an independent and controllable memory operating environment for subsequent execution control, runtime verification or protection mechanisms.

[0142] S306. Perform hash calculation on the code segment of the file to be verified in the execution memory space and the verification memory space to obtain the first hash value and the second hash value.

[0143] For example, after mapping the executable file to a private memory space, the verification logic can further obtain the actual base address of the executable file in the current runtime environment by reading the loading information in the system memory. The base address is the starting memory address allocated by the operating system when loading the executable file, used as the benchmark for runtime address calculations.

[0144] In one embodiment, after obtaining the actual load base address, the verification logic performs relocation processing on the executable file image in the private memory space based on the relocation information carried in the executable file. The relocation information indicates the address reference locations in the executable file that need to be adjusted according to changes in the load base address, including but not limited to code jump addresses, function call addresses, or global data access addresses. Since executable files in a static state typically use a preset default base address as the address calculation reference, and their actual load base address may change after being loaded into memory by the operating system at runtime, it is necessary to recalculate the addresses of the executable file image in the private memory based on the actual load base address to ensure that various address references point to the correct memory locations during runtime; otherwise, it will lead to code jump exceptions or execution errors, causing the executable file to malfunction.

[0145] In one embodiment, by performing relocation processing on the executable file image in private memory, the private memory image is made consistent with the executable file actually loaded in system memory in terms of address layout and execution semantics, thereby achieving the purpose of aligning the system memory runtime state. Since the relocation process corrects address-related instructions in the code, the content of the text segment in private memory changes relative to the static file state. Therefore, the relocated text segment more accurately reflects the actual code form of the executable file during runtime.

[0146] In one embodiment, after the relocation process is completed, the verification logic extracts the relocated text segment data from the private memory space and performs a hash calculation on the text segment data based on a preset digest algorithm to obtain the corresponding second hash value; the second hash value can be saved for consistency verification, integrity monitoring or anti-tampering detection in subsequent running stages.

[0147] S307. Perform memory consistency verification based on the first hash value and the second hash value.

[0148] For example, after completing the relocation process of the private memory image and obtaining the corresponding second hash value, the verification logic can also be triggered periodically or on demand during the execution of the executable file to perform memory consistency verification on the text segment of the executable file that has been loaded into the system memory.

[0149] In one embodiment, the memory consistency verification method may be as follows: when the executable file is in the running state, directly read the text segment data corresponding to the executable file from the system memory, and calculate the first hash value on the text segment data based on the digest algorithm consistent with the signature stage and the relocation stage.

[0150] In one embodiment, a consistency comparison is performed between the first hash value and a pre-saved second hash value; if the comparison result meets the preset consistency conditions, it is determined that the executable file has not undergone illegal modification or code injection during operation; if the comparison result does not meet the consistency conditions, it is determined that the code segment of the executable file has been abnormally changed, and a preset security handling strategy is triggered.

[0151] In one embodiment, memory consistency verification can be performed via timed, event-triggered, or random triggering. This allows for continuous integrity monitoring of the core code segment of the executable file without significantly impacting normal program performance, thereby enhancing the detection capabilities against debugging injection, memory tampering, or runtime attacks. Through the aforementioned runtime hash calculation and verification comparison mechanism, continuous verification of the text segment content can be performed after the executable file is successfully loaded and run, extending file verification from the loading stage to the runtime stage, forming an integrity protection system that spans the entire lifecycle.

[0152] Based on the above embodiments, Figure 7 This is a structural block diagram of a document verification device provided in an embodiment of this application. (Reference) Figure 7 The file verification device provided in this embodiment specifically includes: a signature decryption module 11, a second offset extraction module 12, a second digest calculation module 13, and a file verification module 14.

[0153] The signature decryption module 11 is configured to decrypt the private signature in the file to be verified using a public key to obtain the first entry point offset value and the first code segment digest value of the file to be verified; the second offset extraction module 12 is configured to extract the second entry point offset value at the file header of the file to be verified; the second digest calculation module 13 is configured to calculate the second code segment digest value of the code segment of the file to be verified; and the file verification module 14 is configured to verify the file to be verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value.

[0154] Based on the above embodiments, the signature decryption module 11 includes: a file receiving unit configured to receive a file to be verified and perform digital signature verification on the file to be verified; a signature extraction unit configured to extract a private signature from the file to be verified if the digital signature verification passes; and a signature decryption unit configured to decrypt the private signature using a public key to obtain a first entry point offset value and a first code segment digest value of the file to be verified.

[0155] Based on the above embodiments, the file verification module 14 includes: a file execution unit configured to execute the file to be verified to load the file to be verified into the system-managed execution memory space when the first entry point offset value is consistent with the second entry point offset value and the first code segment digest value is consistent with the second code segment digest value; a mirror execution unit configured to load the file to be verified into the process-private first verification memory space; and a memory verification unit configured to perform memory consistency verification on the file to be verified based on the execution memory space and the first verification memory space.

[0156] Based on the above embodiments, the memory verification unit includes: an address reading subunit configured to read the execution memory space to obtain the base address of the file to be verified; an address relocation subunit configured to relocate the address in the first verification memory space according to the base address to obtain a second verification memory space; and a memory verification subunit configured to perform memory consistency verification on the file to be verified according to the execution memory space and the second verification memory space.

[0157] Based on the above embodiments, the memory verification subunit includes: a first hash component configured to perform hash calculation on the code segment of the file to be verified in the execution memory space to obtain a first hash value; a second hash component configured to perform hash calculation on the code segment of the file to be verified in the second verification memory space to obtain a second hash value; and a memory verification component configured to perform memory consistency verification on the file to be verified based on the first hash value and the second hash value.

[0158] The file verification device provided in this application embodiment, as described above, constructs a hierarchical processing architecture consisting of a signature decryption module 11, a second offset extraction module 12, a second digest calculation module 13, and a file verification module 14. This architecture achieves an end-to-end verification processing chain from signature information parsing and key offset extraction to code consistency verification. The device can collaboratively parse the signature data and code segment features in the file to be verified, and comprehensively analyze the entry point offset information and code segment digest features to complete integrity and consistency verification. This effectively identifies whether the file has been tampered with, improving the security and reliability of the file verification process. The signature decryption module 11 has signature parsing and decryption capabilities. It is used to decrypt the private signature in the file to be verified using a public key, and obtain the first entry point offset value and the first code segment digest value corresponding to the code segment from the decryption result, providing reliable signature reference information for subsequent verification. The second offset extraction module 12 is used to parse and extract the second entry point offset value from the file header structure of the file to be verified. This offset value represents the actual entry point position of the file in the current structure, which is used to reflect the file loading and execution characteristics. The second digest calculation module 13 undertakes the code segment feature calculation task. It generates the second code segment digest value by performing a preset digest algorithm operation on the code segment data of the file to be verified, so as to describe the actual state of the current file code content. The file verification module 14 is used to perform consistency verification by comprehensively considering the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value, to determine whether the signature information matches the current file structure and code content, and output the verification result accordingly. Through the collaborative processing of the above modules, the file verification device constructs a complete closed-loop process from signature decryption, structure parsing, code feature calculation to comprehensive verification and judgment. It can achieve automated verification of file integrity and authenticity without relying on external verification information, significantly improving the accuracy of file security verification and anti-counterfeiting capabilities.

[0159] Based on the above embodiments, Figure 8 This is a structural block diagram of a document signing device provided in an embodiment of this application. (Reference) Figure 8 The file signing device provided in this embodiment specifically includes: a first code extraction module 21, a first digest calculation module 22, a signature combination module 23, and a file generation module 24.

[0160] The first code extraction module 21 is configured to obtain a file to be signed and extract a code segment from the file to be signed to obtain a first code segment; the first digest calculation module 22 is configured to calculate a digest value for the first code segment; the signature combination module 23 is configured to obtain a first entry point offset value for the file to be signed and combine the first code segment digest value and the first entry point offset value to obtain the original signature data; and the file generation module 24 is configured to encrypt the original signature data using a private key to obtain a private signature and generate a file to be verified based on the private signature and the file to be signed.

[0161] The file signing device provided in this application embodiment, as described above, constructs a layered processing architecture consisting of a first code extraction module 21, a first digest calculation module 22, a signature combination module 23, and a file generation module 24. This architecture enables an end-to-end signature processing chain, from parsing the file to be signed and extracting code features to generating the signature and encapsulating the file. The device can generate unique and verifiable signature data based on the code segment and entry point key information of the file to be signed, and structurally combine the signature result with the original file, thereby providing a reliable security foundation for subsequent file verification. The first code extraction module 21 has file parsing and code segment positioning capabilities. It is used to obtain the file to be signed and extract the corresponding code segment data from the file structure to form the first code segment, providing the original input for code feature calculation. The first digest calculation module 22 is used to perform a preset digest algorithm operation on the first code segment to generate the first code segment digest value, which represents the feature fingerprint of the code content of the file to be signed. The signature combination module 23 undertakes the task of signature data construction. It is used to obtain the first entry point offset value corresponding to the file to be signed and combine the entry point offset value with the first code segment digest value to generate the original signature data for signing, so as to ensure that the signature result is associated with the file execution structure and code content at the same time. The file generation module 24 is used to encrypt the original signature data with a private key to generate a private signature, and generate a file to be verified based on the private signature and the file to be signed, so that the signature information and the file content form an integrated encapsulation structure. Through the collaborative processing of the above modules, the file signing device constructs a complete closed-loop process from code segment extraction, digest calculation, signature data generation to signature file output. It can improve the automation and security of the file signing process while ensuring the uniqueness and unforgeability of the signature, and provide solid support for subsequent file verification and integrity verification.

[0162] The file verification device provided in this application embodiment can be used to execute the file verification method provided in the above embodiment, and has corresponding functions and beneficial effects.

[0163] Figure 9This is a schematic diagram of the structure of a document verification device provided in an embodiment of this application, with reference to... Figure 9 The file verification device includes a processor 31, a memory 32, a communication device 33, an input device 34, and an output device 35. The number of processors 31 and the number of memories 32 in the file verification device can be one or more. The processor 31, memory 32, communication device 33, input device 34, and output device 35 of the file verification device can be connected via a bus or other means.

[0164] The memory 32, as a computer-readable storage medium, can be used to store software programs, computer executable files, and modules, such as program instructions / modules corresponding to the file verification method in any embodiment of this application (e.g., the signature decryption module 11, the second offset extraction module 12, the second digest calculation module 13, and the file verification module 14 in the file verification device). The memory 32 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory 32 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0165] The communication device 33 is used for data transmission.

[0166] The processor 31 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 32, thereby implementing the above-mentioned file verification method.

[0167] Input device 34 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the device. Output device 35 may include display devices such as a display screen.

[0168] The file verification device provided above can be used to execute the file verification method provided in the above embodiments, and has corresponding functions and beneficial effects.

[0169] This application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform a file verification method. The file verification method includes: decrypting a private signature in a file to be verified using a public key to obtain a first entry point offset value and a first code segment digest value of the file to be verified; extracting a second entry point offset value from the file header of the file to be verified, and calculating a second code segment digest value of the code segment of the file to be verified; and verifying the file to be verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value.

[0170] Storage medium—any type of memory device or storage device. The term "storage medium" is intended to include: mounting media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, etc.; non-volatile memory, such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements, etc. Storage medium may also include other types of memory or combinations thereof. Furthermore, storage medium may reside in a first computer system in which a program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term "storage medium" may include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0171] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the file verification method described above, but can also perform related operations in the file verification method provided in any embodiment of this application.

[0172] The file verification device, storage medium, and file verification equipment provided in the above embodiments can execute the file verification method provided in any embodiment of this application. For technical details not described in detail in the above embodiments, please refer to the file verification method provided in any embodiment of this application.

[0173] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application. The scope of this application is determined by the scope of the claims.

Claims

1. A file verification method, characterized in that, include: The private signature in the file to be verified is decrypted using the public key to obtain the first entry point offset and the first code segment digest value of the file to be verified. Extract the second entry point offset value from the file header of the file to be verified, and calculate the second code segment digest value of the code segment of the file to be verified. The file to be verified is verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value.

2. The file verification method according to claim 1, characterized in that, The step of using a public key to decrypt the private signature in the file to be verified, obtaining the first entry point offset value and the first code segment digest value of the file to be verified, includes: Receive the file to be verified and perform digital signature verification on the file to be verified; If the digital signature verification passes, the private signature in the file to be verified is extracted. The private signature is decrypted using the public key to obtain the first entry point offset value and the first code segment digest value of the file to be verified.

3. The file verification method according to claim 1, characterized in that, The step of verifying the file to be verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value includes: If the first entry point offset value is the same as the second entry point offset value and the first code segment digest value is the same as the second code segment digest value, the file to be verified is executed to load the file to be verified into the execution memory space managed by the system. Load the file to be verified into the process's private first verification memory space; The file to be verified is subjected to memory consistency verification based on the execution memory space and the first verification memory space.

4. The file verification method according to claim 3, characterized in that, The memory consistency check of the file to be checked based on the execution memory space and the first verification memory space includes: The base address of the file to be verified is obtained by reading the execution memory space; The addresses in the first verification memory space are relocated based on the base address to obtain the second verification memory space; The file to be verified is subjected to memory consistency verification based on the execution memory space and the second verification memory space.

5. The file verification method according to claim 4, characterized in that, The step of performing memory consistency verification on the file to be verified based on the execution memory space and the second verification memory space includes: A hash calculation is performed on the code segment of the file to be verified in the execution memory space to obtain a first hash value; A hash calculation is performed on the code segment of the file to be verified in the second verification memory space to obtain a second hash value; The file to be verified is subjected to memory consistency verification based on the first hash value and the second hash value.

6. A document signing method, characterized in that, include: Obtain the file to be signed, and extract the code segment from the file to be signed to obtain the first code segment; The digest value of the first code segment is calculated from the first code segment; Obtain the first entry point offset value of the file to be signed, and combine the first code segment digest value and the first entry point offset value to obtain the original signature data; The original signature data is encrypted using a private key to obtain a private signature, and a verification file is generated based on the private signature and the file to be signed.

7. A document verification device, characterized in that, include: The signature decryption module is used to decrypt the private signature in the file to be verified using the public key, and obtain the first entry point offset value and the first code segment digest value of the file to be verified. The second offset extraction module is used to extract the second entry point offset value at the file header of the file to be verified. The second digest calculation module is used to calculate the second code segment digest value of the code segment of the file to be verified. The file verification module is used to verify the file to be verified based on the first entry point offset value, the second entry point offset value, the first code segment digest value, and the second code segment digest value.

8. A document signing device, characterized in that, include: The first code extraction module is used to obtain the file to be signed and extract the code segment of the file to be signed to obtain the first code segment. The first digest calculation module is used to calculate the digest value of the first code segment. The signature combination module is used to obtain the first entry point offset value of the file to be signed, and combine the first code segment digest value and the first entry point offset value to obtain the original signature data. The file generation module is used to encrypt the original signature data using a private key to obtain a private signature, and to generate a verification file based on the private signature and the file to be signed.

9. A document verification device, characterized in that, include: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the file verification method as described in any one of claims 1-5.

10. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the file verification method as described in any one of claims 1-5.

Images