A method and apparatus for verifying a patch function based on a symbol offset check
By using a symbol offset verification method and apparatus, the problem of patches being installed in the wrong location is solved, ensuring the correctness of the target function location in the patch file, preventing runtime failures, improving system security, and reducing performance overhead.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- YUNHE ZHIWANG (SHANGHAI) TECHNOLOGY CO LTD
- Filing Date
- 2026-05-22
- Publication Date
- 2026-07-24
AI Technical Summary
Existing patch verification techniques cannot ensure that patches are installed at the correct target function location, leading to runtime jump exceptions, function failures, or system crashes. Furthermore, existing tools cannot detect the correctness of target function offsets.
By obtaining the symbol table information of the patch file and the target program, symbol offset comparison and binary data comparison are performed to ensure that the target function name and offset in the patch file are consistent with the actual offset in the target program, and a verification report is output to prevent incorrect installation.
It enables accurate identification of offset anomalies in the production environment, avoids runtime failures, improves system security, reduces performance overhead, and facilitates problem localization.
Smart Images
Figure CN122286745B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a patch objective function verification and apparatus based on symbol offset verification. Background Technology
[0002] As software systems become increasingly complex, patch management has become a crucial aspect of ensuring system security and stable operation. Existing patch verification technologies typically employ file-level hash verification or signature verification to ensure that patch files have not been tampered with or corrupted. However, these integrity verification methods can only verify the overall consistency of the patch files and cannot determine whether the patch has modified the correct function objects after installation.
[0003] The existing patch verification scheme has the following shortcomings: 1. Traditional hash verification only verifies file integrity and cannot detect whether a patch is installed in the correct target function location.
[0004] 2. While the pre-stored hash verification patch improves verification efficiency, it still cannot verify the correctness of the objective function offset.
[0005] 3. When the target program version is mismatched or binary consistency is not guaranteed, resulting in differences in symbol offset between the executable file and the production environment, the patch may be installed at the wrong address, causing runtime jump exceptions, functional failures, or system crashes.
[0006] 4. Existing mainstream hot patching tools (such as libcareplus) do not compare the symbol offsets of the pre-stored target functions in the patch file with the actual target functions in the target program when installing patches. When the two offsets are inconsistent, the patch may be installed at the wrong offset position, and the tool itself will not report an error, causing the patch function to be ineffective. At the same time, after the code at the wrong position is overwritten, the execution of that position at runtime may cause the process to crash or the system to malfunction. Summary of the Invention
[0007] According to a first aspect of the present invention, a patch objective function verification method based on symbol offset verification is provided, comprising the following steps: Obtain the patch file and extract the target function name to be replaced, the symbol offset of the target function in the patch file, the original function copy corresponding to the target function, and the build identifier of the patch file; Obtain the target program and parse it to extract symbol table information and the target program's build identifiers; Based on the availability of target function symbols in the target program, select the corresponding verification path: When a symbol corresponding to the target function name exists in the target program, the symbol matching path is entered. The corresponding symbol is searched in the symbol table of the target program according to the target function name, and its symbol offset is obtained as the actual offset. The symbol offset in the patch file is then compared with the actual offset. When there is no available symbol corresponding to the target function name in the target program, the binary fragment location path is entered. The symbol offset of the target function stored in the patch file is used as a reference position. A predetermined length of binary data is read from the corresponding offset position in the target program, and the read binary data is compared with the binary data at the corresponding position of the original function copy. A verification report is output based on the comparison results. The patch file is allowed to enter the subsequent installation process when all objective functions pass the verification. If any inconsistency exists, the patch execution is stopped and an alarm message is output.
[0008] Furthermore, the target program is obtained and parsed. Specifically, the target program's binary file is read. If the target program's symbol table is complete, the function name and offset of each symbol are extracted from .symtab. If .symtab has been stripped, it can be retrieved from the dynamic symbol table or additional debugging information.
[0009] Furthermore, the comparison between the symbol offsets in the patch file and the actual offsets is specifically as follows: Using the static offset within the file relative to the code segment base address as the comparison benchmark, the offset difference between the symbol offset in the patch file and the actual offset in the target program is calculated, and the offset difference is judged according to the preset tolerance. The offset difference Δ = |Symbol offset in patch file - Actual offset in target program|. The default tolerance is set to δ. If Δ ≠ δ, the offset is considered abnormal and the verification fails.
[0010] Furthermore, the default tolerance δ is 0, and the offset verification is considered successful only when the symbol offset in the patch file is completely consistent with the actual offset in the target program.
[0011] Furthermore, the default tolerance δ is a configurable parameter, and in some scenarios, the tolerance can be configured to a non-zero value.
[0012] Furthermore, the comparison between the read binary data and the corresponding binary data in the original function copy is specifically as follows: The comparison rule uses a byte-by-byte comparison. The verification is considered successful if the read binary data is completely consistent with the binary data at the corresponding position of the original function copy, and it is considered to fail if any byte is different.
[0013] Furthermore, in the symbol matching path, symbols with the same name that exist in multiple compilation units are distinguished by combining the information of the section to which they belong.
[0014] Furthermore, in the symbol matching path, for C++ programs, matching is performed based on the name-adapted symbols generated by the compiler, and the function names in the patch file and the target program are compared in the form of name-adapted symbols.
[0015] Furthermore, the verification report includes: verification path; offset in the patch file; offset in the target program; offset difference Δ; binary fragment comparison results; and individual verification conclusions.
[0016] According to a second aspect of the invention, a patch objective function verification apparatus based on sign offset verification is provided, comprising: The patch parsing module is used to obtain patch files and extract the name of the target function to be replaced, the symbol offset of the target function in the patch file, the original function copy corresponding to the target function, and the build identifier of the patch file. The program parsing module is used to obtain the target program and parse the target program to extract symbol table information and the target program's build identifier; The path selection module selects the corresponding verification path based on the availability of target function symbols in the target program: The symbol matching module is used to enter the symbol matching path when a symbol corresponding to the target function name exists in the target program. Based on the target function name, it searches for the corresponding symbol in the symbol table of the target program, obtains its symbol offset as the actual offset, and compares the symbol offset in the patch file with the actual offset. The binary positioning module is used to enter the binary fragment positioning path when there is no available symbol corresponding to the target function name in the target program. It uses the symbol offset of the target function pre-stored in the patch file as a reference position, reads binary data of a predetermined length at the corresponding offset position in the target program, and compares the read binary data with the binary data at the corresponding position of the original function copy. The conclusion output module is used to output a verification report based on the comparison results, and allow the patch file to enter the subsequent installation process when all objective functions pass the verification. If any inconsistency exists, the patch execution will be stopped and an alarm message will be output.
[0017] A patch objective function verification method based on sign offset verification according to an embodiment of the present invention has the following beneficial effects: 1. Resolve installation errors: Because the production environment may have undergone "non-standard changes" that affect hot patch installation, for example: The cold patch has been installed (the original delivery has been replaced); The version was unexpectedly changed or rolled back; The build process is not reproducible, which can lead to binary inconsistencies in the deliverables (such as changes in linking order, differences in build environment, etc.). These factors can all cause discrepancies between the binary files in the production environment and those in the pre-verification environment. Existing solutions rely solely on "assumed-to-be-consistent" binaries for sign offset verification during the pre-verification phase. This approach fails to detect static differences in the production environment, potentially leading to incorrect installations when patches are distributed.
[0018] This patent achieves true verification of the target location's correctness by directly performing a static comparison of the objective function's sign offset in the production environment. This ensures that even if the binary data in the production environment has been tampered with, replaced, or reconstructed differently, this solution can still accurately identify offset anomalies and block patch execution, thus preventing runtime failures.
[0019] 2. Enhance system security: Perform symbol-level verification before installation to detect and prevent erroneous installations that could lead to disastrous consequences, significantly reducing system risks.
[0020] 3. Reduced performance overhead: Static parsing eliminates the need to execute the target program, resulting in low overhead and high security.
[0021] 4. Facilitates problem localization: It can generate detailed comparison reports, which facilitates problem localization and auditing.
[0022] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description
[0023] Figure 1 This is a flowchart of a patch objective function verification method based on symbol offset verification according to an embodiment of the present invention.
[0024] Figure 2 This is a structural diagram of a patch objective function verification device based on symbol offset verification according to an embodiment of the present invention. Detailed Implementation
[0025] The preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings, further illustrating the present invention.
[0026] First, combine Figure 1 This paper describes a patch objective function verification method based on symbol offset verification according to an embodiment of the present invention, which is used for patch file management and has a wide range of applications.
[0027] like Figure 1 As shown, an embodiment of the present invention provides a patch objective function verification method based on symbol offset verification, which includes the following steps: like Figure 1As shown, in S1, the patch file is obtained, and the target function name to be replaced, the symbol offset of the target function in the patch file (as the "expected offset" benchmark for subsequent verification), the original function copy corresponding to the target function (i.e. the original binary code pre-stored in the patch file, used for binary fragment comparison when the target program symbol is unavailable), and the build identifier of the patch file (optional, used to assist in version consistency judgment) are extracted.
[0028] like Figure 1 As shown, in S2, the target program is obtained and parsed to extract symbol table information and the target program's build identifier. It should be noted that a binary parsing tool (such as an ELF or PE parsing library) is used to read the target program's binary file (such as ELF or PE format) and parse the following information: If the target program's symbol table is complete, extract the function name and offset of each symbol from .symtab; if .symtab has been stripped, you can fall back to the dynamic symbol table (such as .dynsym of ELF, export table of PE) or extract it from additional debugging information. Extract the build identifier of the target program (such as the build-id of ELF) to assist in version consistency judgment.
[0029] like Figure 1 As shown, in S3, the corresponding verification path is selected based on the availability of the target function symbols in the target program.
[0030] like Figure 1 As shown, in S4, when a symbol corresponding to the target function name exists in the target program, the symbol matching path is entered. Based on the target function name, the corresponding symbol is searched in the target program's symbol table, and its symbol offset is obtained as the actual offset. The symbol offset in the patch file is then compared with the actual offset. It should be noted that the following must be considered during matching: Local symbols (such as static functions) may have the same name in multiple compilation units. They can be distinguished by combining the information of the section they belong to (st_shndx, etc.). For C++ programs, the tool needs to locate functions based on the name mangling symbols generated by the compiler. Both the patch symbols and the target program symbols are precisely compared in mangled form. If no corresponding symbol is found on either side, it is considered that the patch does not match the target program, the failure is recorded and subsequent verification is terminated.
[0031] Furthermore, it should be noted that comparing the symbol offsets in the patch file with the actual offsets specifically involves: Using the static offset within the file relative to the code segment base address as the comparison benchmark, the offset difference between the symbol offset in the patch file and the actual offset in the target program is calculated, and the offset difference is judged according to the preset tolerance to ensure that the benchmarks on both sides are consistent and are not affected by runtime base address randomization (such as ASLR).
[0032] The offset difference Δ = |Symbol offset in the patch file - Actual offset in the target program|. The default tolerance is set to δ. If Δ ≠ δ, the offset is considered abnormal and the verification fails. The default tolerance δ is 0, and the offset verification is only considered successful if the symbol offset in the patch file is exactly the same as the actual offset in the target program.
[0033] Furthermore, it should be noted that the default tolerance δ is a configurable parameter. In some scenarios (such as slight offsets caused by changes in compiler alignment strategies), the tolerance δ can be configured to a non-zero value. In strict production environments, it is recommended to keep the tolerance δ = 0.
[0034] like Figure 1 As shown, in S5, when there is no available symbol corresponding to the target function name in the target program (i.e. the symbol has been stripped), the binary fragment location path is entered. Based on the symbol offset of the target function pre-stored in the patch file as a reference position, binary data of a predetermined length (the length is configurable, but cannot exceed the length of the original function, such as 32 / 64 / 128 bytes) is read from the corresponding offset position in the target program, and the read binary data is compared with the binary data at the corresponding position of the original function copy.
[0035] Furthermore, it should be noted that comparing the read binary data with the corresponding binary data in the original function copy specifically involves: The comparison rule adopts a byte-by-byte comparison. The verification is considered to pass when the read binary data is completely consistent with the binary data at the corresponding position of the original function copy. If any byte is different, the verification is considered to fail. This method is equivalent to the strict matching judgment with tolerance δ=0 in offset verification.
[0036] like Figure 1 As shown, in S6, a verification report is output based on the comparison results, and the patch file is allowed to enter the subsequent installation process when all objective functions pass the verification. If any inconsistency exists, the patch execution is stopped and an alarm message is output.
[0037] Furthermore, it should be noted that the verification report includes the following information recorded for each objective function: Verification path (symbol offset comparison / binary fragment comparison); Offset in the patch file; Offset in the target program (applicable to symbol offset comparison paths); Offset difference Δ (applicable under the sign offset comparison path); Binary fragment alignment results (applicable to the binary fragment alignment path); Single-item verification conclusion.
[0038] Report Summary: Success / Failure Count, First Failure, Overall Conclusion (Pass / Fail).
[0039] As described above, the patch target function correctness verification method based on symbol offset verification according to an embodiment of the present invention extracts the function information to be modified in the patch file before patch application and compares it with the symbol table of the target program. This ensures that the object function modified by the patch and its offset position are consistent with expectations, thereby preventing system errors or crashes caused by erroneous patch modifications. It can be used as a pre-hook call for existing hot patch installation tools (such as libcareplus) to complete the verification before the actual patch injection.
[0040] The above combined with the appendix Figure 1 A method for verifying the correctness of a patch objective function based on sign offset verification according to an embodiment of the present invention is described. Furthermore, the present invention can also be applied to an apparatus for verifying the correctness of a patch objective function based on sign offset verification.
[0041] like Figure 2 As shown, according to a second aspect of the invention, a patch objective function verification apparatus based on symbol offset verification is provided, comprising: The patch parsing module 100 is used to obtain the patch file and extract the name of the target function to be replaced, the symbol offset of the target function in the patch file, the original function copy corresponding to the target function, and the build identifier of the patch file. The program parsing module 200 is used to obtain the target program and parse the target program to extract symbol table information and the target program's build identifier; The path selection module 300 selects the corresponding verification path based on the availability of target function symbols in the target program. The symbol matching module 400 is used to enter the symbol matching path when there is a symbol in the target program that corresponds to the target function name, search for the corresponding symbol in the symbol table of the target program according to the target function name, obtain its symbol offset as the actual offset, and compare the symbol offset in the patch file with the actual offset. The binary positioning module 500 is used to enter the binary fragment positioning path when there is no available symbol corresponding to the target function name in the target program. Based on the symbol offset of the target function pre-stored in the patch file as a reference position, it reads binary data of a predetermined length at the corresponding offset position in the target program and compares the read binary data with the binary data at the corresponding position of the original function copy. The conclusion output module 600 is used to output a verification report based on the comparison results, and to allow the patch file to enter the subsequent installation process when all objective functions pass the verification. If any inconsistency exists, the patch execution will be stopped and an alarm message will be output.
[0042] The above combined with the appendix Figure 2 This paper describes a patch objective function correctness verification device based on symbol offset verification according to an embodiment of the present invention. It is an apparatus description of a patch objective function correctness verification method based on symbol offset verification. Therefore, the detailed steps and methods therein are the same and will not be repeated.
[0043] It should be noted that, in this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0044] Although the present invention has been described in detail through the preferred embodiments above, it should be understood that the above description should not be considered as a limitation of the present invention. Various modifications and substitutions to the present invention will be apparent to those skilled in the art after reading the above description. Therefore, the scope of protection of the present invention should be defined by the appended claims.
Claims
1. A method for verifying a patched objective function based on sign offset verification, characterized in that, It includes the following steps: Obtain the patch file, and extract the target function name to be replaced, the symbol offset of the target function in the patch file, the original function copy corresponding to the target function, and the build identifier of the patch file; Obtain the target program and parse the target program to extract symbol table information and the target program's build identifier; Based on the availability of target function symbols in the target program, select the corresponding verification path: When a symbol corresponding to the target function name exists in the target program, the symbol matching path is entered. The corresponding symbol is searched in the symbol table of the target program according to the target function name, and its symbol offset is obtained as the actual offset. The symbol offset in the patch file is compared with the actual offset. When there is no available symbol corresponding to the target function name in the target program, the binary fragment location path is entered. Based on the symbol offset of the target function pre-stored in the patch file as a reference position, binary data of a predetermined length is read from the corresponding offset position in the target program, and the read binary data is compared with the binary data at the corresponding position of the original function copy. A verification report is output based on the comparison results. The patch file is allowed to enter the subsequent installation process when all objective functions pass the verification. If any inconsistency exists, the patch execution is stopped and an alarm message is output.
2. The patch objective function verification method based on symbol offset verification as described in claim 1, characterized in that, Obtaining the target program and parsing the target program specifically involves: reading the binary file of the target program; if the target program's symbol table is complete, extracting the function name and offset of each symbol from .symtab. If .symtab has been stripped, you can fall back to extract it from the dynamic symbol table or additional debugging information.
3. The patch objective function verification method based on symbol offset verification as described in claim 1, characterized in that, The comparison between the symbol offset in the patch file and the actual offset specifically involves: Using the static offset within the file relative to the code segment base address as the comparison benchmark, the offset difference between the symbol offset in the patch file and the actual offset in the target program is calculated, and the offset difference is judged according to the preset tolerance. The offset difference Δ = |symbol offset in patch file - actual offset in target program|, with a default tolerance of δ. If Δ ≠ δ, the offset is considered abnormal and the verification fails.
4. The patch objective function verification method based on symbol offset verification as described in claim 3, characterized in that, The default tolerance δ is 0, and the offset verification is considered successful only when the symbol offset in the patch file is completely consistent with the actual offset in the target program.
5. The patch objective function verification method based on symbol offset verification as described in claim 3, characterized in that, The default tolerance δ is a configurable parameter, and in some scenarios, the tolerance can be configured to a non-zero value.
6. The patch objective function verification method based on symbol offset verification as described in claim 1, characterized in that, The comparison of the read binary data with the corresponding binary data at the original function copy is specifically as follows: The comparison rule adopts a byte-by-byte comparison, and the verification is deemed to pass when the read binary data is completely consistent with the binary data at the corresponding position of the original function copy, and the verification is deemed to fail if any byte is different.
7. The patch objective function verification method based on symbol offset verification as described in claim 1, characterized in that, In the symbol matching path, symbols with the same name that exist in multiple compilation units are distinguished by combining the information of the section to which they belong.
8. The patch objective function verification method based on symbol offset verification as described in claim 1, characterized in that, In the symbol matching path, for C++ programs, matching is performed based on the name-adapted symbols generated by the compiler, and the function names in the patch file and the target program are compared in the form of name-adapted symbols.
9. The patch objective function verification method based on symbol offset verification as described in claim 1, characterized in that, The verification report includes: verification path; offset in patch file; offset in target program; offset difference Δ; binary fragment comparison result; and individual verification conclusion.
10. A patch objective function verification device based on sign offset verification, characterized in that, Include: The patch parsing module is used to obtain the patch file and extract the target function name to be replaced, the symbol offset of the target function in the patch file, the original function copy corresponding to the target function, and the build identifier of the patch file. The program parsing module is used to obtain the target program and parse the target program to extract symbol table information and the target program's construction identifier; The path selection module selects the corresponding verification path based on the availability of target function symbols in the target program: The symbol matching module is used to enter the symbol matching path when there is a symbol in the target program that corresponds to the target function name, search for the corresponding symbol in the symbol table of the target program according to the target function name, obtain its symbol offset as the actual offset, and compare the symbol offset in the patch file with the actual offset. The binary positioning module is used to enter the binary fragment positioning path when there is no available symbol corresponding to the target function name in the target program. Based on the symbol offset of the target function pre-stored in the patch file as a reference position, it reads binary data of a predetermined length at the corresponding offset position in the target program and compares the read binary data with the binary data at the corresponding position of the original function copy. The conclusion output module is used to output a verification report based on the comparison results, and allow the patch file to enter the subsequent installation process when all objective functions pass the verification. If any inconsistency exists, the patch execution will be stopped and an alarm message will be output.