Reverse de-signed binary code analysis method based on library function matching

Abstract

The invention discloses a de-signed binary code reverse analysis method based on library function matching. The method comprises the following steps of: obtaining de-signed binary codes and a candidate library file list thereof in the embedded equipment, and extracting a library function and information of each object file of each candidate library file; performing matching operation on each object file in sequence to establish a library function matching table; and acquiring addresses for calling other library functions in each library function, performing consistency comparison with the addresses of the successfully matched library functions, and confirming the calling relationship of the library functions, thereby determining the function of the de-signed binary code in the embedded equipment. According to the method, the library function in the de-signed binary code can be accurately identified, the calling relation is checked, and the method is suitable for component analysis and traceability of scenes such as computer programs, embedded firmware and DSP programs so as to accurately identify the function of the de-signed binary code in embedded equipment.

Description

TECHNICAL FIELD

[0001] The present application relates to a code reverse analysis method, and relates to the technical field of computer software and program analysis, in particular to a de-symbol binary code reverse analysis method based on library function matching. BACKGROUND

[0002] With the wide use of third-party libraries and open source components in computer programs, embedded firmware, digital signal processor (DSP) programs and general software, component identification, compliance audit and security traceability for binary programs of published or in-production devices have become a common requirement in engineering practice. In real scenarios, the program to be analyzed is usually optimized at the release level and stripped of symbols, missing symbol tables, debugging information and source-level annotations, retaining only machine code and necessary relocation and loading information. At the same time, differences in compiler versions, optimization levels, linking scripts and library versions will cause significant changes in code layout, immediate number values and call addressing modes, increasing the difficulty of library function identification.

[0003] The existing technologies mainly have the following ideas:

[0004] Symbol and metadata-based identification: directly locate the library function by reading the symbol table, segment table or comment area in the target file / executable file. This method is simple to implement, but it generally fails on de-symbolized releases.

[0005] Byte signature-based matching: the typical approach is to extract fixed byte sequences or feature "fingerprints" from library functions in advance, and search in the target binary. This method is sensitive to compilers, optimization levels, position-independent code (PIC / PIE) and immediate number fields of relocation backfill, and is easily mismatched due to address constants and jump distance changes, or produces high false positives on short sequences.

[0006] Hash-based function-level comparison: calculate the hash of the function machine code as a whole or in blocks, and compare it with the library-side hash library. This method relies on the consistency of stable byte areas, and once the function contains address and offset-related instruction operands or fragments rewritten by the linker, the overall hash is unstable; similar functions across versions and optimizations are also easily misjudged.

[0007] Structured matching based on control flow or call graph: through disassembly, extracting control flow graph or call relationship graph, and then graph matching or graph isomorphism approximation. This method is more robust in theory, but has high computational complexity and strong dependence on disassembly quality; on embedded and digital signal processor (DSP) program architecture, due to the characteristics of instruction set, composite instructions, in-line and tail call expansion, etc., the graph recovery itself is easily affected by noise, leading to unstable matching.

[0008] Learning method based on semantic or vectorized representation: similarity retrieval is achieved through feature extraction and representation learning of functions. This type of method needs sufficient data covering multiple architectures and multiple compilation options for training, and the generalization ability and interpretability on unpopular or special instruction sets are still limited; at the same time, higher requirements for computing resources and model maintenance are put forward in engineering landing.

[0009] In summary, the existing solutions generally have the following common problems: first, the relocation-related bytes filled by the linker are not explicitly modeled, leading to the use of unstable bytes and semantically stable bytes for matching, thereby introducing unnecessary difference amplification; second, there is a lack of processing mechanism for the differences in relocation type-coverage length-backfill strategy in different compilation tool chains and different library implementations, making it difficult to establish comparable stable features between object files and finished binaries; third, there is a lack of systematic cross-verification of inter-function call relationships, and pure reliance on local similarity can easily lead to false matching and string library phenomenon in large programs or multiple libraries coexist; fourth, the cost of structured graph matching and large model methods is high on the engineering side, making it difficult to balance speed and accuracy in batch firmware and image scanning tasks, and thus unable to infer the accurate functions of the de-symbolized binary code. SUMMARY

[0010] To solve the problems in the background art, the present application provides a de-symbolized binary code reverse analysis method based on library function matching. The present application relates to static analysis and reverse engineering of binary code, especially for de-symbolized executable files, and can be used for software component analysis, security audit and traceability. The method obtains stable and traceable matching results by masking the relocation position of the library function body, extracting and comparing segments using isomorphic windows in the program binary, and performing hash comparison, combined with library offset strategy and call and jump relationship consistency verification, without relying on symbol information.

[0011] The technical scheme adopted by the present application is:

[0012] The de-symbolized binary code reverse analysis method based on library function matching of the present application comprises:

[0013] Step S10: Obtain the disassembled binary code in the embedded device and a candidate library file list thereof, the candidate library file list including a plurality of candidate library files, each candidate library file including a plurality of object files, each object file having a respective name, and extracting one or more library functions and information thereof from each object file.

[0014] Step S20: Perform a matching operation on each object file of each candidate library file in the candidate library file list in sequence to establish a library function matching table.

[0015] Step S30: Obtain addresses of calling other library functions in each library function based on the library function matching table, and then compare the addresses matched successfully in the matching operation of step S20 with the addresses of calling other library functions in the library functions for consistency to confirm the calling relationship of the library functions, thereby determining the function of the disassembled binary code in the embedded device, and modifying and optimizing the recognized disassembled binary code to better control the current embedded device.

[0016] In step S10, the information of 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] Step S20 is specifically as follows:

[0018] Step S21: For each object file of each candidate library file in the candidate library file list, extract the original byte code 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 byte code.

[0019] Step S22: Generate a binary mask segment according to the original byte code of the instruction segment and the relocation table in the object file, and determine the mask segment and the comparison segment of the binary mask segment; extract each comparison segment in the binary mask segment and sequentially splice them into a comparison segment sequence to obtain a hash feature value of the comparison segment sequence.

[0020] Step S23: Extract a to-be-matched code sequence from the disassembled binary code according to the binary mask segment and the mask segment therein, and obtain a hash feature value of the to-be-matched code sequence.

[0021] Step S24: Compare the hash feature value of the comparison segment sequence with the hash feature value of the to-be-matched code sequence to determine the object file and the library function matched successfully, and finally establish a 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, and the length of the relocation entry in the original byte code is determined based on the relocation type in the relocation entry.

[0023] In the step S22, each byte in the original byte code of the instruction segment in the object file is associated with a respective relocation entry, and starting from the first byte of the original byte code of the instruction segment in the object file, according to the relocation table of the object file, a byte segment with a length of the length of the current relocation entry in the original byte code is determined as a shield segment starting from the offset address of the current relocation entry, and until a plurality of shield segments are determined according to each relocation entry, the byte segment between each shield segment is taken as a comparison segment, and the original byte code divided into the shield segment and the comparison segment is taken as a binary mask segment.

[0024] In the step S23, starting from the first byte in the de-symbolized binary code, a window with a length equal to the binary mask segment is slid by a preset step length, each time the code in the current window in the de-symbolized binary code is extracted, and the code segment in the extracted code with the same position as the shield segment in the current binary mask segment is deleted, and then the to-be-matched code is obtained, and finally a to-be-matched code sequence is formed.

[0025] In the step S24, the hash feature values of the comparison segment sequence and the hash feature values of the to-be-matched code sequence are compared, a plurality of object files with the same hash feature values are obtained as the matching successful object files, and the addresses and names of the matching successful object files are recorded, for each library function of the matching successful object files, the address of the matching successful object file and the offset address of the library function in the object file are added to obtain the address of the library function matching success, the address of each library function matching success, the name of the library function, the code segment content of the deleted code segment in the de-symbolized binary code, the position in the de-symbolized binary code, and the relocation type are put into the library function matching table, and the target symbol name of the shield segment corresponding to the deleted code segment is put into the library function matching table, and a final library function matching table is established.

[0026] In the step S30, in the library function matching table, the relocation entry with the relocation type of function call is obtained as a call relocation entry, and the address of each library function calling other library functions in the call relocation entry is obtained by adding the code segment content of the deleted code segment and the offset address of each library function in the call relocation entry; the address of the library function matching success and the address of each library function calling other library functions are compared for consistency, and it is determined whether they are the same, if they are the same, it is determined that the matching successful library function has a called address and they are consistent, and the calling relationship of the library function can be confirmed through the called address, and it is determined that the cross verification of the library function calling relationship is successful; otherwise, it is marked as verification failure.

[0027] The electronic device of the present application comprises a memory and a processor coupled to each other, wherein the memory stores program data, and the processor calls the program data to execute the method as described above.

[0028] The computer readable storage medium of the present application stores program data, which is executed by a processor to implement the method described above.

[0029] The method of the present application first reads the de-symbolized binary program to be analyzed; obtains the candidate library file from the development environment or the compilation tool chain, and extracts all object files and the library function information contained therein; parses the instruction segment original bytecode and the relocation table of each object file, determines the byte length covered by each relocation entry according to the relocation type; generates a mask segment equal in length to the original bytecode based on the relocation information, marks the bytes covered by the relocation entries as a shield segment, and the rest as a comparison segment; extracts the comparison segment sequence and calculates its hash feature value; slides a window equal in length to the mask segment in the program to be analyzed, ignores the shield segment position according to the mask segment, extracts the code sequence to be matched and calculates the hash value, and compares it with the hash value of the comparison segment of the object file; if the matching is successful, the library function name, the matching address, the ignored code segment content, the position, the relocation type and the target symbol name are recorded; further, for function call type relocation entries, the called function address is deduced through the ignored code segment content combined with the library offset strategy, and cross verification is performed with the matched library function address to ensure the consistency of the call relationship.

[0030] The present application effectively overcomes the interference caused by compiler optimization, linking strategy and address change by shielding the unstable bytes related to relocation and only matching based on stable comparison segments; at the same time, the reliability of the matching result is further improved through cross verification of the call relationship. The method of the present application can explicitly determine the coverage range of non-stable bytes based on relocation entries on the object file side; shield the corresponding position in the program to be analyzed on the matching side, and only construct features based on stable comparison segments; and after the matching is completed, the called function address is verified for consistency in combination with the call addressing strategy of the library.

[0031] The present application has the following advantages:

[0032] 1. High robustness and accuracy: by explicitly identifying and shielding non-stable bytes through relocation information, only performing hash matching based on semantically stable comparison segments, significantly reducing false positives and false negatives caused by factors such as compiler optimization, linking strategy, library version difference, etc., and improving the identification accuracy across versions and optimization levels.

[0033] 2. High efficiency and scalability: The method uses a sliding window and hash comparison mechanism to avoid complex disassembly and control flow analysis, which is highly efficient and suitable for large-scale binary program and batch firmware scanning scenarios. At the same time, the method does not depend on specific architecture or instruction set and can be extended to various hardware platforms and embedded systems.

[0034] 3. Cross-validation of call relationship: Based on the matching, the method further uses function call class relocation information and library offset strategy to reverse the called function address and perform consistency verification with the matched results, effectively avoiding false matching or missing matching problems and improving the reliability and traceability of the results.

[0035] 4. Strong engineering practicability: The method does not require symbol information, debugging data or training model, but directly operates based on binary bytecode and relocation table, which is suitable for common symbol-free release programs in actual engineering. At the same time, the method supports various library offset modes (no offset, fixed offset, interval mapping, etc.) and adapts to different compilation environments and linking strategies.

[0036] 5. Wide applicability: The method can be applied to various binary analysis scenarios such as computer programs, embedded firmware, digital signal processor (DSP) programs, etc., and supports software component analysis, security audit, vulnerability tracing, compliance check and other actual needs, which has high practical value and promotion prospect.

[0037] In summary, the method of the present application realizes efficient, accurate and reliable library function recognition and verification in symbol-free binary programs, providing strong technical support for binary analysis in embedded devices. BRIEF DESCRIPTION OF DRAWINGS

[0038] Figure 1 is a flowchart of the method of the present application;

[0039] Figure 2 is a schematic diagram of the relocation of the binary code of the library function in the method of the present application after being linked into the program;

[0040] Figure 3 is a schematic diagram of generating a binary mask segment and a comparison segment sequence from the original bytecode in the specific embodiment of the present application;

[0041] Figure 4 is a schematic diagram of the hash matching of the binary mask segment and the comparison segment of the symbol-free binary code in the specific embodiment of the present application.

[0042] Figure 5 is a flowchart of the matching and cross-validation based on relocation information in the method of the present application. DETAILED DESCRIPTION

[0043] The present application 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 function's memory address 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 de-signed 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. 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 that calls other library functions based on the library function matching table. 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, thereby determining the function of the designed binary code in the embedded device.

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: 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.

4. The method for reverse analysis of designed binary code based on library function matching according to claim 3, 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.

5. The method for reverse analysis of designed binary code based on library function matching according to claim 3, 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.

6. The method for reverse analysis of designed binary code based on library function matching according to claim 3, 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.

7. The method for reverse analysis of designed binary code based on library function matching according to claim 6, 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.

8. The method for reverse analysis of designed binary code based on library function matching according to claim 7, characterized in that: 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.

9. 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-8.

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

Images