A library function matching-based de-symbol binary code reverse analysis method

Abstract

The application discloses a kind of based on library function matching's desymbolic binary code reverse analysis method.Method includes: obtaining desymbolic binary code in embedded device and its candidate library file list, extract the library function and its information of each object file of each candidate library file;Matching operation is successively carried out to each object file to establish library function matching table;The address of other library functions is called in each library function, then consistent comparison is carried out with the address of the library function matched successfully, confirms the call relationship of library function, to determine the function of desymbolic binary code in embedded device.The method of the application can accurately identify the library function in desymbolic binary code and check call relationship, suitable for component analysis and tracing in computer program, embedded firmware, DSP program and other scenes, to accurately identify the function of desymbolic binary code in embedded device.

Description

Technical Field

[0001] This invention relates to a code reverse engineering method, which falls under the field of computer software and program analysis technology, and specifically to a designed binary code reverse engineering method based on library function matching. Background Technology

[0002] With the widespread use of third-party libraries and open-source components in computer programs, embedded firmware, digital signal processor (DSP) programs, and general-purpose software, component identification, compliance auditing, and security tracing of binary programs in released or production devices have become common requirements in engineering practice. In real-world scenarios, programs to be analyzed typically undergo release-level optimization and symbol stripping, resulting in the loss of symbol tables, debugging information, and source-level comments, retaining only machine code and necessary relocation and loading information. Furthermore, differences in compiler versions, optimization levels, linker scripts, and library versions can significantly alter code layout, immediate value retrieval, and call addressing methods, increasing the difficulty of library function identification.

[0003] Existing technologies mainly fall into the following categories:

[0004] Symbol and metadata-based identification: This method directly locates library functions by reading the symbol table, segment table, or comment section of the object file / executable file. While simple to implement, this approach generally fails on distributions that do not support symbolic representation.

[0005] Byte signature-based matching typically involves pre-extracting a fixed byte sequence or characteristic "fingerprint" for library functions and then searching within the target binary. This method is sensitive to compilers, optimization levels, position-independent code (PIC / PIE), and immediate numeric fields used for relocation backfilling. It is highly susceptible to mismatches due to changes in address constants and jump distances, or to generating a high false positive rate on short sequences.

[0006] Hash-based function-level comparison: This method calculates the hash of the function's machine code as a whole or in blocks, and then compares it with a library-side hash database. This type of method relies on the consistency of stable byte regions. Once the function contains instruction operands related to addresses or offsets, or fragments that have been modified by the linker, the overall hash becomes unstable; similar functions across versions or optimizations are also prone to misjudgment.

[0007] Structured matching based on control flow or call graphs: This method involves disassembling and extracting the control flow graph or call graph, followed by graph matching or graph isomorphism approximation. While theoretically more robust, this method is computationally complex and highly dependent on disassembly quality. Furthermore, in embedded systems and digital signal processor (DSP) architectures, graph reconstruction is susceptible to noise due to instruction set characteristics, compound instructions, inlining, and tail call expansion, leading to unstable matching.

[0008] Learning methods based on semantic or vectorized representations achieve similarity retrieval by extracting features and learning representations from functions. These methods require sufficient data covering multiple architectures and compilation options for training, and their generalization ability and interpretability on less common or specialized instruction sets remain limited. Furthermore, their practical application places higher demands on computational resources and model maintenance.

[0009] In summary, existing solutions generally suffer from the following common problems: First, they lack explicit modeling of relocation-related bytes backfilled by the linker, leading to the use of unstable bytes alongside semantically stable bytes for matching, thus introducing unnecessary amplification of differences. Second, they lack mechanisms for handling differences in relocation type, coverage length, and backfilling strategies across different compiler toolchains and library implementations, making it difficult to establish comparable stable features between object files and finished binary code. Third, they lack systematic cross-verification of function call relationships, relying solely on local similarity, which can easily lead to mismatches and library cross-referencing in large programs or when multiple libraries coexist. Fourth, structured graph matching and large model methods are costly on the engineering side, making it difficult to balance speed and accuracy in batch firmware and image scanning tasks, and consequently, unable to infer the accurate functionality of the de-symbolized binary code. Summary of the Invention

[0010] To address the problems existing in the background technology, this invention provides a method for reverse analysis of desymbolized binary code based on library function matching. This invention relates to static analysis and reverse engineering of binary code, particularly for desymbolized executable files, and can be used for software component analysis, security auditing, and source tracing. The method, without relying on symbol information, masks the relocation locations of library function bodies, extracts comparison segments in the program binary using isomorphic windows and performs hash comparisons, and combines library offset strategies with call and jump relationships for consistency verification, thereby obtaining stable and traceable matching results.

[0011] The technical solution adopted in this invention is:

[0012] The present invention provides a designed binary code reverse analysis method based on library function matching, comprising:

[0013] Step S10: Obtain the designed binary code and its candidate library file list from the embedded device. The candidate library file list includes several candidate library files, and each candidate library file includes several object files. Each object file has its own name. Extract one or more library functions and their information from each object file.

[0014] Step S20: Perform matching operations on each object file of each candidate library file in the candidate library file list in turn to build a library function matching table.

[0015] Step S30: Based on the library function matching table, obtain the address of each library function that calls other library functions. Then, compare the address of the library function that was successfully matched in the matching operation of step S20 with the address of the library function that calls other library functions to confirm the calling relationship of the library functions. This determines the function of the de-signed binary code in the embedded device. The identified de-signed binary code can be modified and optimized to better control the current embedded device.

[0016] In step S10, the information for each library function includes the name of the library function, the binary code of the library function, and the offset address of the library function in the object file.

[0017] The specific steps of S20 are as follows:

[0018] Step S21: For each object file of each candidate library file in the candidate library file list, extract the original bytecode of the instruction segment and the relocation table in the object file, and determine the length of each relocation entry in the original bytecode.

[0019] Step S22: Generate a binary mask segment based on the original bytecode of the instruction segment and the relocation table in the object file, and determine the mask segment and comparison segment of the binary mask segment; extract each comparison segment in the binary mask segment and concatenate them into a comparison segment sequence, and obtain the hash feature value of the comparison segment sequence.

[0020] Step S23: Based on the binary mask segment and the masking segment therein, extract the code sequence to be matched from the designed binary code and obtain the hash feature value of the code sequence to be matched.

[0021] Step S24: Compare the hash feature value of the comparison segment sequence with the hash feature value of the code sequence to be matched, thereby determining the successfully matched object file and its library function, and finally establishing the library function matching table;

[0022] In step S21, each relocation entry in the relocation table includes an offset address, a relocation type, and a target symbol name. The length of the relocation entry in the original bytecode is determined based on the relocation type in the relocation entry.

[0023] In step S22, each byte in the original bytecode of the instruction segment in the object file is associated with its own relocation entry. Starting from the first byte of the original bytecode of the instruction segment in the object file, the process is traversed. According to the relocation table of the object file, a byte segment in the original bytecode, starting from the offset address of the current relocation entry, with a length equal to the length of the current relocation entry in the original bytecode, is used as a mask segment. This process continues until several mask segments are determined according to each relocation entry. The byte segments between each mask segment are used as comparison segments, and the original bytecode divided into mask segments and comparison segments is used as a binary mask segment.

[0024] In step S23, starting from the first byte of the desymbolized binary code, a window of the same length as the binary mask segment is slid sequentially at a preset step size. Each slide extracts the code in the desymbolized binary code within the current window, and deletes the code segments in the extracted code that are in the same position as several mask segments in the current binary mask segment, thereby obtaining the code to be matched, and finally forming the sequence of code to be matched.

[0025] In step S24, the hash feature value of the comparison segment sequence is compared with the hash feature value of the code sequence to be matched. Several object files with the same hash feature value are obtained as successfully matched object files, and the address and name of the successfully matched object files are recorded. For each library function of the successfully matched object file, the address of the successfully matched object file and the offset address of the library function in the object file are added to obtain the address of the successfully matched library function. The address of the successfully matched library function, the name of the library function, the code segment content of the deleted code segment in the de-symbol binary code, its position in the de-symbol binary code, and the relocation type are put into the library function matching table. The target symbol name of the mask segment corresponding to the deleted code segment is also put into the library function matching table to establish the final library function matching table.

[0026] In step S30, in the library function matching table, relocation entries with function call relocation type are obtained as call relocation entries. The code segment content of the deleted code segment and the offset address of each library function in the call relocation entry are accumulated to obtain the address of each library function calling other library functions in the call relocation entry. The address of the successfully matched library function is compared with the address of each library function calling other library functions to determine whether they are the same. If they are the same, it is determined that the successfully matched library function has a called address and the two are consistent. The call relationship of the library function can be confirmed through the called address, and the cross-validation of the library function call relationship is determined to be successful. Otherwise, it is marked as verification failure.

[0027] The electronic device of the present invention includes: a memory and a processor coupled to each other, wherein the memory stores program data, and the processor invokes the program data to execute the method described above.

[0028] The present invention provides a computer-readable storage medium having program data stored thereon, which, when executed by a processor, implements the method described above.

[0029] The method of this invention first reads the designed binary program to be analyzed; obtains candidate library files from the development environment or compilation toolchain, and extracts all object files and the library function information contained therein; parses the original bytecode of the instruction segment and the relocation table of each object file, and determines the byte length covered by each relocation entry according to the relocation type; generates a mask segment of the same length as the original bytecode based on the relocation information, marks the bytes covered by the relocation entries as the mask segment, and the rest as the comparison segment; extracts the comparison segment sequence and calculates its hash feature value; slides a window of the same length as the mask segment in the program to be analyzed, and extracts the code sequence to be matched and calculates its hash value according to the mask segment ignoring the mask segment position, and compares it with the hash value of the comparison segment of the object file; if the match is successful, records the library function name, matching address, ignored code segment content, position, relocation type, and target symbol name; further, for function call class relocation entries, the address of the called function is reversed by combining the ignored code segment content with the library offset strategy, and cross-validated with the already matched library function address to ensure the consistency of the call relationship.

[0030] This invention effectively overcomes interference from compiler optimizations, linking strategies, and address changes by masking unstable bytes related to relocation and performing matching solely based on stable comparison segments. Furthermore, cross-validation through call relationships further improves the reliability of the matching results. This invention's method explicitly uses relocation entries to determine the coverage range of unstable bytes on the object file side; masks corresponding positions in the program to be analyzed on the matching side, constructing features solely based on stable comparison segments; and combines library call addressing strategies to verify the consistency of called function addresses after matching. The method maintains good robustness across optimization, version, and location conditions, while possessing practical computational efficiency and traceability. It is applicable to computer programs, embedded firmware, digital signal processor (DSP) programs, and general designed binary engineering analysis scenarios.

[0031] The beneficial effects of this invention are:

[0032] 1. High robustness and accuracy: By explicitly identifying and masking unstable bytes through relocation information, hash matching is performed only based on semantically stable comparison segments, which significantly reduces false and missed matches caused by factors such as compiler optimization, linking strategies, and library version differences, and improves the recognition accuracy across versions and optimization levels.

[0033] 2. High efficiency and scalability: The method adopts a sliding window and hash comparison mechanism, which avoids complex disassembly and control flow analysis, resulting in high computational efficiency and making it suitable for large-scale binary programs and batch firmware scanning scenarios. At the same time, the method does not depend on a specific architecture or instruction set and can be extended to a variety of hardware platforms and embedded systems.

[0034] 3. Cross-validation of call relationships: Based on the matching, the function call class relocation information is further utilized, and the address of the called function is reversed by combining the library offset strategy. The consistency of the result with the already matched result is verified, which effectively avoids the problem of incorrect matching or missing matching, and improves the credibility and traceability of the result.

[0035] 4. Strong engineering applicability: The method does not require symbol information, debugging data or training models, and operates directly based on binary bytecode and relocation table, making it suitable for common unsymbolized release programs in actual engineering. At the same time, it supports multiple library offset modes (no offset, fixed offset, range mapping, etc.) to adapt to different compilation environments and linking strategies.

[0036] 5. Wide applicability: It can be applied to various binary analysis scenarios such as computer programs, embedded firmware, and digital signal processor (DSP) programs. It supports practical needs such as software component analysis, security auditing, vulnerability tracing, and compliance inspection, and has high practical value and promising prospects for promotion.

[0037] In summary, this invention achieves efficient, accurate, and reliable library function identification and verification in designed binary programs, providing strong technical support for binary analysis in embedded devices. Attached Figure Description

[0038] Figure 1 This is a schematic flowchart of the method of the present invention;

[0039] Figure 2 This is a schematic diagram illustrating the relocation that occurs after the binary code of the library function is linked into the program in the method of this invention;

[0040] Figure 3 This is a schematic diagram illustrating the generation of binary mask segments and comparison segment sequences from the original bytecode in a specific embodiment of the present invention;

[0041] Figure 4 This is a schematic diagram illustrating the comparison segment hash matching between the binary mask segment and the designed binary code in a specific embodiment of the present invention.

[0042] Figure 5 This is a flowchart of the matching and cross-validation process based on relocation information in the method of this invention. Detailed Implementation

[0043] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0044] like Figure 1 As shown, the designed binary code reverse analysis method based on library function matching of the present invention is as follows:

[0045] First, obtain the de-signed binary code and its candidate library file list from the embedded device. De-signed binary code is binary code that has had its symbol information removed. Embedded devices include microcontroller hardware, digital signal processors (DSPs), etc. The candidate library file list consists of various candidate library files related to the de-signed binary code, obtained directly from the program development environment or compilation toolchain. The candidate library file list includes several candidate library files. ,in, For the first One candidate library file, The number of candidate library files; each candidate library file includes several object files, each with its own name, and a list of object files. ,in, For the first The first candidate library file One object file, For the first The number of object files in each candidate library file; extract one or more library functions and their information from each object file, and a list of library functions. ,in, For the first The first candidate library file The first object file Library functions, For the first The first candidate library file The number of library functions in each object file; information for each library function includes the name of the library function. binary code of library functions Offset address of library function in object file , , and The first The first candidate library file The first object file The name, binary code, and in the first library function The offset address in the object file.

[0046] like Figure 2As shown, in specific implementation, this invention builds the source code program in the code debugger CCS (Code Composer Studio) and links standard library rts55x.lib, chip library dsplib.lib, system library, etc. to call various library functions. The source program is compiled to obtain an object file (.obj), and then the linker is linked into the program to generate the program's binary code test.out, which is then burned into the TI DSK5510 digital signal processor development board. The byte sequence test.bin is exported from the onboard Flash / ROM of the DSK5510 development board as the de-signed binary code via the Joint Test Action Group (JTAG) / USB. It can be seen that the library function binary code undergoes relocation after being linked into the program, resulting in changes to the binary code.

[0047] Then, obtain the candidate library files that may be used from the program development environment or the corresponding compilation toolchain, and build a list of candidate library files. Extract all object files (.obj) contained in each candidate library file. Taking the standard library rts55x.lib as an example, use the ar55 extraction tool to obtain all object files. In this embodiment, three library files are selected. The candidate libraries are the standard library rts55x.lib, the chip library dsplib.lib, and the system library. Obtaining the object files from the standard library rts55x.lib yields a list of object files O1, including 293 object files such as acos.obj. , For the i-th object file.

[0048] Then for each object file Extract information from one or more library functions, including at least: the library function name, the library function's binary code, and the library function's offset address in the object file. This embodiment uses the ofd55 parsing tool to export and parse the Extensible Markup Language (XML) of all object files within the library file. For example, to obtain Library function information, Contains only one library function Library function name Library function binary code (Excerpt from raw bytecode) Offset address of library function in object file .

[0049] After constructing the candidate library file list, the raw bytecode of the instruction segment in each object file of each candidate library file in the candidate library file list is extracted first. and relocation table , For the first The first candidate library file The raw bytecode of the instruction segment of an object file; relocation table ,in, For the first The first candidate library file The first object file Each relocation entry For the first The first candidate library file The number of relocation entries in each object file is determined; and the length of each relocation entry in the relocation table in the original bytecode is determined; each relocation entry in the relocation table includes an offset address. Relocation type and target symbol name Offset address For relocation entries in the original bytecode The corresponding position in the middle; relocation type This includes code jumps, function calls, absolute address references; target symbol names. The function name corresponding to the relocation entry; the length of the relocation entry in the original bytecode is determined based on the relocation type in the relocation entry. Specifically, based on the relocation type The architecture of the binary code can be found in the chip programming manual by looking up a table based on the relocation type. corresponding size; , and The first The first candidate library file The first object file The offset address, relocation type, and target symbol name of each relocation entry; For the first The first candidate library file The first object file Each relocation entry in the original bytecode The length in.

[0050] Then, based on the original bytecode of the instruction segment in the object file and the relocation table, a binary mask segment is generated, and the mask segment and comparison segment of the binary mask segment are determined; each comparison segment in the binary mask segment is extracted and concatenated sequentially into a comparison segment sequence, and the hash feature value of the comparison segment sequence is obtained; each byte in the original bytecode of the instruction segment in the object file is associated with its own relocation entry, and from the object file... Raw bytecode of the instruction segment Iterate starting from the first byte, according to the relocation table of the object file. Remove the current relocation entry from the original bytecode. offset address Begin by determining the length as the length of the current relocation entry in the original bytecode. The byte segments are used as mask segments, and this process continues until several mask segments are determined based on each relocation entry. The byte segments between each mask segment are then used as comparison segments, i.e., each relocation entry... offset address arrive The position is set as the mask segment, and the rest are marked as comparison segments. The original bytecode divided into mask segments and comparison segments is used as the binary mask segment. , For the first The first candidate library file A binary mask segment of an object file; from the binary mask segment Extract all comparison segments and concatenate them into a comparison segment sequence. And calculate the comparison segment sequence hash feature value .

[0051] Then, based on the binary mask segment and its masked segments, starting from the first byte of the designed binary code, a window of the same length as the binary mask segment is slid sequentially at a preset step size. Each slide extracts the code within the current window from the designed binary code, and deletes code segments that occupy positions with several masked segments in the current binary mask segment. This process yields the code to be matched, ultimately forming the sequence of codes to be matched. Then, obtain the hash feature value of the code sequence to be matched. Also, based on the relocation table information, record the code segment content of each deleted code segment. The position in the desymbolized binary code Relocation type and the target symbol name of the corresponding shielding segment .

[0052] Then, the hash feature values ​​of the comparison segment sequence and the hash feature values ​​of the code sequence to be matched are compared. Several object files with the same hash feature value are selected as the successfully matched object files. It records the address and name of the successfully matched object files, and for each library function in a successfully matched object file, it records the address of the successfully matched object file and the offset address of the library function in the object file. The address of the successfully matched library function is obtained after addition. The address and name of each successfully matched library function will be entered into the database. The code segment content of the deleted code segment in the desymbolized binary code, its position in the desymbolized binary code, and its relocation type are put into the library function matching table. The target symbol name of the mask segment corresponding to the deleted code segment is also put into the library function matching table to establish the final library function matching table.

[0053] In specific implementation, the present invention first performs a matching operation on each object file of each candidate library file in the candidate library file list in turn, as follows:

[0054] First, the raw bytecode and relocation table of the .text segment are parsed for each object file. Each relocation entry contains: For example, acos.obj has 28 relocation entries. Taking one of the relocation entries as an example, the relocation entry that acos.obj calls the _cmpd library function to... Offset address as follows: =0x27, relocation type = R_REL24, symbol name = _cmpd, the length of the relocation entry in the original bytecode. 0x3.

[0055] Then, based on the original bytecode and the relocation table, a mask segment of the same length as the original bytecode is generated: the bytes covered by all relocation entries are marked as mask segments, and the rest are comparison segments.

[0056] like Figure 3 As shown, in this embodiment, the original bytecode length of acos is 0x18f. Based on the 28 relocation entries obtained in S41, a mask segment is generated by ignoring 28 mask segments. .

[0057] Then, all comparison segments are extracted from the mask segment and concatenated to obtain the comparison segment sequence. Its length is 0x13 bits; its hash value is calculated using the CRC32 hash algorithm: 0x4DC83561.

[0058] Then, in the program to be analyzed, i.e., the desymmetric binary code test.bin, starting from the first byte, slide the window with a step size of 1 byte, with the same length as the mask segment: ignore the masked segment according to the mask, and only compare the hash feature value of the comparison segment; record the ignored code segment content (original byte value) of each masked segment. The position of this segment in the complete binary representation. Relocation type Target symbol name corresponding to the shielding segment .

[0059] Then, the hash feature value of the comparison segment sequence is calculated using the CRC32 hash algorithm: =0x4DC83561.

[0060] like Figure 4 As shown, the hash feature value of the comparison segment sequence is the same as the hash feature value of the comparison segment in the previous library function. 0x4DC83561 is recorded as a successful match, and the start and end addresses of acos in test.bin are recorded [0x276A5–0x27834]. The acos.obj file contains only one library function, acos, and the offset of acos in the code segment is 0.

[0061] Then, the following information is written into the library function matching table function by function: 1. Library function name 2. Addresses where library functions are successfully matched 3. Deleted code segment content 4. The location of the deleted code segment in the complete binary program. 5. Target symbol name of the corresponding shielding segment .const _cmpd. Repeat the sliding window operation steps until the entire binary code sequence has been traversed.

[0062] After establishing the final library function matching table, this invention obtains the addresses of other library functions called by each library function based on the library function matching table. Then, it compares the addresses of successfully matched library functions with the addresses of other library functions called by the library functions to confirm the calling relationship of the library functions. This determines the function of the designed binary code in the embedded device, and the identified designed binary code can be modified and optimized to better control the current embedded device.

[0063] In the library function matching table, relocation entries with the relocation type of function call are retrieved as call relocation entries. The contents of the deleted code segment and the offset address of each library function in the call relocation entry are then summed to obtain the address of each library function calling other library functions within the call relocation entry. ,in, The library function calling strategy is determined by the nature of the library. Library function calling strategies include no offset, fixed offset mode, and range mapping mode; the address that successfully matches the library function. The address of each library function that calls other library functions is compared for consistency. If they are the same, the library function that is successfully matched has a call address and the two are consistent. The call relationship of the library functions can be confirmed through the call address, and the cross-validation of the library function call relationship is determined to be successful. Otherwise, it is marked as a verification failure.

[0064] In library function call strategies, "no offset" means no offset occurs; the address of the function called in binary code is the address of that function in memory. In fixed offset mode, the address of a function call in binary code is the memory address of that function offset by a constant. ,Right now The interval mapping mode is that the address of the binary code calling the function is the memory address of that function, which may be offset by multiple different constants. It depends on the memory location range of the called binary code, i.e. ,in, and These are the start and end addresses of interval s. It is the offset address of interval s in memory.

[0065] In practical implementation, this invention reconstructs the called address (file address / encoding of the target symbol) based on the ignored code segment content of the records related to function calls in the library function matching table (i.e., entries of relocation type R_REL24), and converts it into the program runtime address using an offset strategy. Since the offset mode of the rts55x library is fixed offset and the offset amount is 0, = , .

[0066] Then, for each matched library function, the runtime address of the called library function, calculated internally, is taken and compared with the matched intervals within or across libraries. If the called address falls within the matching interval of the corresponding target library function, the cross-validation is successful. The cross-validation process is as follows: Figure 5 As shown; acos has relocation entries R_REL24 and _cmpd at offset 0x27; 3 bytes ignored from the mask position of test.bin are read and converted to runtime addresses according to the configuration. The address of the _cmpd call is calculated to be... The matching _cmpd location library function If they match, then the cross-validation of the call to _cmpd is successful.

[0067] Based on the call relationships of library functions, the usage and location of library functions in the program can be confirmed. By reviewing the input / output and functional descriptions of the called library functions, the function of the designed binary code in the embedded device can be determined. In this embodiment, a total of 49 library functions, including acos and cmpd, were matched. According to the library function documentation, the program uses calculation methods such as the inverse cosine function and string comparison. Further analysis of the function call relationships reveals the specific algorithms in the designed binary code, thus accurately identifying its function in the embedded device.

[0068] It should be noted that the parts not described in detail in the embodiments of the present invention belong to those that are common knowledge or publicly disclosed prior art to those skilled in the art. These contents are considered to be general knowledge in the industry.

[0069] Furthermore, for those skilled in the art, the steps in the embodiments described in this invention, whether all or part, can be implemented by programming instructions to corresponding hardware devices. The corresponding control program can be stored in various computer-readable media, such as, but not limited to, read-only memory, hard disks, or optical discs.

[0070] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims. The information disclosed in the background section is intended only to enhance the understanding of the overall background technology of the present invention and should not be construed as an admission or implication in any way that such information constitutes prior art known to those skilled in the art.

Claims

1. A method for reverse analysis of designed binary code based on library function matching, characterized in that, include: Step S10: Obtain the designed binary code and its candidate library file list in the embedded device. The candidate library file list includes several candidate library files, and each candidate library file includes several object files. Extract one or more library functions and their information from each object file. The candidate library file list consists of various candidate library files related to the designed binary code obtained directly from the program development environment or compilation toolchain; Step S20: Perform matching operations on each object file of each candidate library file in the candidate library file list in turn to build a library function matching table; Step S30: Obtain the address of each library function calling other library functions based on the library function matching table, and then compare the address of the library function that was successfully matched in the matching operation of step S20 with the address of the library function calling other library functions to confirm the calling relationship of the library functions, thereby determining the function of the designed binary code in the embedded device. The specific steps of S20 are as follows: Step S21: For each object file of each candidate library file in the candidate library file list, extract the original bytecode of the instruction segment and the relocation table in the object file, and determine the length of each relocation entry in the relocation table in the original bytecode; Step S22: Generate a binary mask segment based on the original bytecode of the instruction segment and the relocation table in the object file, and determine the mask segment and comparison segment of the binary mask segment; extract each comparison segment in the binary mask segment and concatenate them into a comparison segment sequence, and obtain the hash feature value of the comparison segment sequence; Step S23: Based on the binary mask segment and the masking segment therein, extract the code sequence to be matched from the designed binary code and obtain the hash feature value of the code sequence to be matched; Step S24: Compare the hash feature value of the comparison segment sequence with the hash feature value of the code sequence to be matched, thereby determining the successfully matched object file and its library function, and finally establishing the library function matching table; In step S30, in the library function matching table, relocation entries with function call relocation type are obtained as call relocation entries. The code segment content of the deleted code segment and the offset address of each library function in the call relocation entry are accumulated to obtain the address of each library function in the call relocation entry that calls other library functions. The address of the successfully matched library function is compared with the address of each library function that calls other library functions to determine whether they are the same. If they are the same, it is determined that the successfully matched library function has a called address and the call relationship of the library functions can be confirmed through the called address.

2. The method for reverse analysis of designed binary code based on library function matching according to claim 1, characterized in that: In step S10, the information for each library function includes the name of the library function, the binary code of the library function, and the offset address of the library function in the object file.

3. The method for reverse analysis of designed binary code based on library function matching according to claim 1, characterized in that: In step S21, each relocation entry in the relocation table includes an offset address, a relocation type, and a target symbol name. The length of the relocation entry in the original bytecode is determined based on the relocation type in the relocation entry.

4. The method for reverse analysis of designed binary code based on library function matching according to claim 1, characterized in that: In step S22, each byte in the original bytecode of the instruction segment in the object file is associated with its own relocation entry. Starting from the first byte of the original bytecode of the instruction segment in the object file, the process is traversed. According to the relocation table of the object file, a byte segment in the original bytecode, starting from the offset address of the current relocation entry, with a length equal to the length of the current relocation entry in the original bytecode, is used as a mask segment. This process continues until several mask segments are determined according to each relocation entry. The byte segments between each mask segment are used as comparison segments, and the original bytecode divided into mask segments and comparison segments is used as a binary mask segment.

5. The method for reverse analysis of designed binary code based on library function matching according to claim 1, characterized in that: In step S23, starting from the first byte of the desymbolized binary code, a window of the same length as the binary mask segment is slid sequentially at a preset step size. Each slide extracts the code in the desymbolized binary code within the current window, and deletes the code segments in the extracted code that are in the same position as several mask segments in the current binary mask segment, thereby obtaining the code to be matched, and finally forming the sequence of code to be matched.

6. The method for reverse analysis of designed binary code based on library function matching according to claim 5, characterized in that: In step S24, the hash feature value of the comparison segment sequence is compared with the hash feature value of the code sequence to be matched. Several object files with the same hash feature value are obtained as successfully matched object files, and the address of the successfully matched object file is recorded. For each library function of the successfully matched object file, the address of the successfully matched object file and the offset address of the library function in the object file are added to obtain the address of the successfully matched library function. The address of each successfully matched library function, the name of the library function, the code segment content of the deleted code segment in the de-symbol binary code, its position in the de-symbol binary code, and the relocation type are put into the library function matching table. The target symbol name of the mask segment corresponding to the deleted code segment is also put into the library function matching table to establish the final library function matching table.

7. An electronic device, characterized in that, include: A memory and a processor are coupled to each other, wherein the memory stores program data, and the processor invokes the program data to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium storing program data thereon, characterized in that, When the program data is executed by the processor, it implements the method as described in any one of claims 1-6.

Images