Function name recovery method and electronic equipment

Abstract

The embodiment of the invention discloses a function name recovery method and electronic equipment, and is suitable for the technical field of software security, and the function name recovery method comprises the following steps: obtaining a target binary file; generating a target pseudo code corresponding to the target binary file; structural information of a target function is extracted from the target pseudo code, the structural information is used for describing the function, a basic block in the function and a variable in the function, and the target function is any function in the target pseudo code; based on the structure information of the target function, a first pseudo code in the target pseudo code is converted into a three-address code, and the first pseudo code is related to the target function; determining first feature information related to a control flow of the target function based on the three-address code; and generating a function name of the target function based on the first feature information. According to the embodiment of the invention, the function name of each function in the software program can be accurately recovered, so that the software security is guaranteed.

Description

Technical Field

[0001] The present application relates to the field of software security technology, and in particular to a function name recovery method and electronic device. Background Art

[0002] Binary reverse engineering is a technique that analyzes software binary files (machine code) to understand software behavior and logic. Binary reverse engineering is widely used in various fields, including software security, malware analysis, vulnerability detection, and legacy system maintenance. Because accurate function names can help quickly locate potential security risks, such as identifying critical and dangerous functions, recovering function names is a crucial task in binary reverse engineering.

[0003] In related technologies, since software programs usually remove or obfuscate symbolic information in binary files during the process of compiling from source code to binary files, such as removing function names and / or variable information, it is difficult to recover the function names in the source code, and it is impossible to discover the dangers in the software through the function names, making it difficult to ensure software security. Summary of the Invention

[0004] In view of this, the embodiments of the present application provide a function name recovery method, an electronic device, a computer-readable storage medium, a chip system, and a computer program product, which can accurately recover the function name of each function in the software program, thereby ensuring software security.

[0005] In a first aspect, embodiments of the present application provide a method for recovering function names. This method can be applied to electronic devices, such as terminals or servers. The terminal can be a tablet computer, an in-vehicle device, an augmented reality (AR) / virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), or the like. The server can be a network server, a cloud server, or the like. Embodiments of the present application do not limit this.

[0006] The function name recovery method may include: first, the electronic device obtains a target binary file. Then, the electronic device generates a target pseudocode corresponding to the target binary file. Thereafter, the electronic device extracts structural information of the target function from the target pseudocode. Next, the electronic device converts a first pseudocode in the target pseudocode into a three-address code based on the structural information of the target function. Finally, the electronic device determines first characteristic information related to the control flow of the target function based on the three-address code, and generates a function name of the target function based on the first characteristic information.

[0007] The structural information is used to describe functions, basic blocks within functions, and variables within functions. The target function (also referred to as the first function) is any function in the target pseudocode. It should be noted that the target pseudocode may include one function or multiple functions. If the target pseudocode includes multiple functions, the electronic device may extract the structural information of each function and generate a function name for each function based on the structural information.

[0008] The first pseudocode is related to the target function, that is, the first pseudocode is a part of the target pseudocode.

[0009] Optionally, the target binary file is a binary file from which symbol information has been removed. In this application, a binary file refers to a file that carries the machine code of a program. Binary file formats may include object file formats (.o files), shared object file formats (.so files), executable file formats (.exe files), and so on. It will be appreciated that the embodiments of this application do not specifically limit the file format of the target binary file.

[0010] In the embodiments of the present application, on the one hand, the structural information of the function can accurately describe the characteristics of the function, accurately extract the rich and comprehensive structural information of each function, such as function information, basic block information in the function, and variable information in the function, and generate the function name of the function based on the structural information of the function, which helps to improve the accuracy of function name recovery. On the other hand, when the function name is accurately recovered, the key dangerous function can be filtered and directly located according to the function name, which helps to ensure software security. On the other hand, only the first pseudocode related to the function structure needs to be converted into a three-address code, which can avoid converting the pseudocode unrelated to the function structure and improve the conversion efficiency.

[0011] Optionally, the first feature information related to the control flow may include features represented by a control flow graph (CFG), or may include one or more of the following: features represented by a function call graph (CG), features represented by a data flow graph (DFG), and features represented by a program dependency graph (PDG).

[0012] It is understandable that the electronic device can adopt the solutions disclosed in the relevant technology to convert the three-address code into a control flow graph, a function call graph, a data flow graph, a program dependency graph, etc., which will not be elaborated here.

[0013] It should be pointed out that extracting function features from multiple dimensions can make the extracted features comprehensive and enriched, which helps to further improve the accuracy of function name recovery.

[0014] In a first possible implementation manner of the first aspect, the structural information of the target function may include function information, basic block information in the target function, and variable information in the target function.

[0015] In this case, the electronic device extracts the structural information of the target function from the target pseudocode, which may include: first, the electronic device traverses the target pseudocode, and when accessing the first operation instruction, extracts the function information of the target function from the first operation instruction. Then, the electronic device determines M basic blocks and basic block information of each basic block from the target function based on each instruction in the target function, where M is an integer greater than 0. Thereafter, the electronic device traverses the first basic block and extracts variable information from the first instruction in the first basic block. The first basic block is any basic block among the M basic blocks, and the first instruction is any instruction in the first basic block. Finally, the electronic device generates an intermediate file, which is used to record the function information, basic block information, and variable information of the target function.

[0016] The first operation instruction is an instruction in the target pseudocode that defines the target function, and the function information includes the first entry address of the function. The first entry address can also be called the entry address of the function or the first address of the function. It can be understood that the target pseudocode is composed of instructions, and the instructions in the pseudocode can also be called pseudocode instructions. Each instruction in the pseudocode corresponds to an operation, such as an AND operation, an OR operation, etc., so the instructions in the pseudocode can also be called operation instructions.

[0017] Basic block information includes the basic block's second entry address, the basic block's forward node, and the basic block's backward node. The second entry address can also be referred to as the basic block's entry address or the basic block's first address. It should be noted that for any basic block, the forward node is the pseudo-code instruction (P-Code instruction) that jumps to the basic block, and the backward node is the P-Code instruction to which the basic block needs to jump.

[0018] The first entry address and the second entry address in the intermediate file correspond to the first pseudocode. The first entry address is the storage address of the first pseudocode instruction in the function, and the second entry address is the storage address of the first pseudocode instruction in the basic block. The electronic device can access each pseudocode instruction in the function based on the first entry address and the second entry address.

[0019] In the embodiment of the present application, since the pseudocode has a specific syntax, the electronic device can extract function information, basic block information in the function, and variable information in the function from the target code in combination with the syntax of the pseudocode. It should be pointed out that since the pseudocode is essentially an unordered code, extracting the structural information of each function from the pseudocode can achieve orderly classification of the unordered pseudocode. In addition, classifying and dividing the pseudocode layer by layer according to multiple levels such as functions, basic blocks in functions, instructions in basic blocks, variables, etc., helps to accurately extract the semantic structure of each function, thereby ensuring the accuracy of function name recovery.

[0020] Optionally, the function information may further include: the name of the function (referred to as the function name), the type of the function's return value, the size of the function's return value, etc.

[0021] Optionally, the basic block information may further include an index of the basic block, where the basic block index is a unique identifier of the basic block, and each basic block has an index. For example, the index of the first basic block in a function may be 0, and the index of the next basic block may be 1.

[0022] In a second possible implementation manner of the first aspect, the variable information includes one or more of the following: a name of the variable, a storage type of the variable, and a size of the variable.

[0023] The storage type of a variable can indicate where the variable is stored. For example, a register type means the variable is stored in a register, a memory type means the variable is stored in memory, and a stack type means the variable is stored on the stack.

[0024] In a third possible implementation of the first aspect, the language format of the three-address code is a low-level virtual machine intermediate representation (LLVM IR). In this case, the electronic device converts the first pseudocode in the target pseudocode into the three-address code based on the structural information of the target function, which may include: first, the electronic device generates an initial variable table corresponding to the target function, where the variable table is used to record the value changes of each variable in the target function during program execution. Then, based on the intermediate file, the electronic device traverses the first pseudocode and, for the second instruction in the first pseudocode, converts the second instruction into an LLVM IR instruction based on the operation type and / or variable table corresponding to the second instruction.

[0025] Among them, the second instruction is any instruction in the first pseudocode, and the operation types include: first operation type, second operation type, third operation type, and fourth operation type. The first operation type is used to obtain input variables, the second operation type is used to update output variables, the third operation type is used to merge multiple branches, and the fourth operation type is an operation type other than the first operation type, the second operation type, and the third operation type.

[0026] It's important to note that any function can be associated with a variable table, which records the changes in the values ​​of variables within that function as the program runs. This variable table can include global variables, local variables, temporary variables, and more. Optionally, the initial variable table corresponding to the function can be empty by default.

[0027] In the embodiments of the present application, firstly, since LLVM IR is an intermediate representation that is independent of the specific hardware platform, it converts the P-Code code from a high-level language into a more standardized low-level representation, which can obtain a unified representation that is independent of the platform and language, and is convenient for analysis and optimization. Moreover, by first converting the intermediate file into an LLVM IR file, cross-platform optimization and analysis can be performed with the help of the powerful functions of LLVM, and the control flow graph generation process can be simplified, making analysis and optimization more efficient and universal. Secondly, by converting the pseudo-code instructions of various operation types described in the intermediate file into corresponding LLVM IR instructions, it can be ensured that each pseudo-code instruction involved in the function is converted into an LLVM IR instruction, that is, it is possible to achieve comprehensive and accurate conversion of the instructions involved in the function. This helps to fully and accurately extract the feature information of the function, thereby improving the accuracy of function name recovery. Third, because different types of variables have different storage locations, uses, scopes, and lifecycles, and as the program runs, the values ​​of the variables in each function will change, this application uses the function's variable table to describe the real-time changes of each variable in the function, which can ensure the accuracy of the generated LLVM IR instructions. For example, if a variable is not recorded in the variable table when it is updated, it means that there is a problem with the use of the variable. Therefore, based on the real-time updated variable table, the accuracy of the generated LLVM IR instructions can be guaranteed.

[0028] In a fourth possible implementation of the first aspect, the electronic device converting the second instruction into an LLVM IR instruction based on the operation type and / or variable table corresponding to the second instruction may include: first, if the operation type of the second instruction is the first operation type, the electronic device obtaining the storage type of the input variable from the second instruction. Then, the electronic device may generate an LLVM IR instruction corresponding to the second instruction based on the storage type of the input variable and the variable table.

[0029] The storage type may include register type, memory type, and stack type.

[0030] If the input variable's storage type is a register type, the LLVM IR instruction is used to load the value into the input variable. If the input variable's storage type is a memory type, the LLVM IR instruction is used to retrieve the value of the input variable. If the input variable's storage type is a stack type, the LLVM IR instruction is used to retrieve the value of the input variable from the variable table.

[0031] In an embodiment of the present application, the electronic device can convert the second instruction into a corresponding LLVM IR instruction based on the operation type of the instruction, and in the process of instruction conversion, it can convert the second instruction into an LLVM IR instruction in a targeted manner based on the storage type of the input variable, thereby improving the accuracy of instruction conversion and further improving the efficiency of function name recovery.

[0032] In a fifth possible implementation of the first aspect, after the electronic device generates an LLVM IR instruction corresponding to the second instruction based on the storage type and variable table of the input variable, it may also add first variable information of the input variable to the variable table, where the first variable information includes the variable name of the input variable, the address of the input variable, and the value of the input variable.

[0033] In the embodiment of the present application, when the electronic device obtains an input variable, it promptly adds the variable information of the input variable to the variable table, so that the real-time changes of each variable are always recorded in the variable table.

[0034] Optionally, when an input variable is a register type, during the process of generating an LLVM IR instruction, if the electronic device detects that the input variable does not exist in the current variable table, a first prompt message may be generated, where the first prompt message is used to indicate that the input variable is undefined or that there is a syntax error in the use of the input variable. In other words, in this application, the variable table can be used to check whether the source code has syntax errors.

[0035] In a sixth possible implementation of the first aspect, the electronic device converting the second instruction into an LLVM IR instruction based on the operation type and / or variable table corresponding to the second instruction may include: first, if the operation type of the second instruction is the second operation type, obtaining the storage type of the output variable from the second instruction. Then, the electronic device generates an LLVM IR instruction corresponding to the second instruction based on the storage type of the output variable.

[0036] If the storage type of the output variable is a register type, the LLVM IR instruction includes a first LLVM IR instruction and a second LLVM IR instruction. The first LLVM IR instruction is used to convert the data type of the output variable to the first data type, and the second LLVM IR instruction is used to store the output variable of the first data type, where the first data type is the data type corresponding to the output variable. If the storage type of the output variable is a memory type or a stack type, the LLVM IR instruction is an instruction for storing the output variable.

[0037] In an embodiment of the present application, the electronic device can convert the second instruction into a corresponding LLVM IR instruction based on the operation type of the instruction. In the process of instruction conversion, the second instruction can also be converted into an LLVM IR instruction in a targeted manner based on the storage type of the output variable, which can improve the accuracy of instruction conversion and further improve the efficiency of function name recovery.

[0038] In a seventh possible implementation of the first aspect, after the electronic device generates an LLVM IR instruction corresponding to the second instruction according to the storage type of the output variable, the electronic device may also add second variable information of the output variable to the variable table, where the second variable information includes the variable name of the output variable, the address of the output variable, and the value of the output variable.

[0039] In the embodiment of the present application, the electronic device promptly adds the latest variable information of the output variable to the variable table, so that the real-time changes of each variable are always recorded in the variable table.

[0040] In an eighth possible implementation of the first aspect, the electronic device converts the second instruction into an LLVM IR instruction according to the operation type and / or variable table corresponding to the second instruction, including: first, if the operation type of the second instruction is the third operation type, obtaining N input variables included in the second instruction, where N is an integer greater than 1. Then, the electronic device determines the forward basic block of the second basic block based on the intermediate file, where the second basic block is the basic block to which the second instruction belongs, and the forward basic block is the basic block that jumps to the second basic block. Thereafter, the electronic device obtains the latest value of the first input variable from the first forward basic block, where the first forward basic block is a forward basic block containing the first input variable, and the first input variable is any input variable in the second instruction. Finally, the electronic device generates an LLVM IR instruction based on the values ​​of each input variable obtained.

[0041] In the embodiment of the present application, when the operation type of the second instruction is the third operation type, the electronic device can accurately and effectively convert the second instruction in the pseudocode into an LLVM IR instruction. During the instruction conversion process, the second instruction is converted into an LLVM IR instruction in a targeted manner based on the instruction operation type, which can improve the accuracy of instruction conversion and further improve the efficiency of function name recovery.

[0042] In a ninth possible implementation of the first aspect, the electronic device converts the second instruction into an LLVM IR instruction according to the operation type and / or variable table corresponding to the second instruction, including: if the operation type corresponding to the second instruction is a fourth operation type, then based on a preset first correspondence, converting the second instruction into an LLVM IR instruction, wherein the first correspondence is a correspondence between the instruction of the pseudocode and the LLVM IR instruction.

[0043] In an embodiment of the present application, during the instruction conversion process, the electronic device combines the operation type of the instruction to specifically convert the second instruction into an LLVM IR instruction, which can improve the accuracy of the instruction conversion and further improve the efficiency of function name recovery.

[0044] In a tenth possible implementation of the first aspect, the electronic device generates a function name of a target function based on the first feature information, including: first, the electronic device inputs the first feature information into a first model to obtain multiple candidate function names of the target function; then, the electronic device inputs the multiple candidate function names, the first feature information, and the three-address code into a second model to obtain the function name of the target function.

[0045] Among them, the first model is a generative model and the second model is a large language model.

[0046] In the embodiment of the present application, since the generative model can process various complex data types, such as text, images, audio, etc., and can learn the potential representation of the data and adapt to different tasks, in addition, the generative model usually has a strong generalization ability and can perform well even in scenarios outside the training data. Therefore, when the first model is a generative model, the accuracy of the multiple candidate function names obtained can be guaranteed. In addition, since the large prediction model is a natural language processing model based on deep learning, it can learn and understand the grammar and semantics of natural language. Therefore, using a large language model to optimize the multiple candidate function names output by the first model helps to further improve the accuracy of function name recovery.

[0047] In an eleventh possible implementation manner of the first aspect, the electronic device generates a target pseudo code corresponding to the target binary file, including: generating a high-level pseudo code corresponding to the target binary file, where the target pseudo code is a high-level pseudo code.

[0048] In the embodiment of the present application, since the high-level pseudocode focuses more on the source code itself and not the underlying architecture, and the low-level pseudocode contains a large amount of information related to the underlying architecture, and this information related to the underlying architecture has nothing to do with the function itself, therefore, using high-level pseudocode for function name recovery can avoid excessive irrelevant interference information, help reduce the amount of data processing, and improve the efficiency of function name recovery.

[0049] In a second aspect, an embodiment of the present application provides a function name recovery device, comprising: Input unit, used to obtain the target binary file; A processing unit is used to generate a target pseudocode corresponding to a target binary file; extract structural information of a target function from the target pseudocode, the structural information being used to describe a function, a basic block in a function, and a variable in a function, wherein the target function is any function in the target pseudocode; based on the structural information of the target function, convert a first pseudocode in the target pseudocode into a three-address code, wherein the first pseudocode is related to the target function; based on the three-address code, determine first characteristic information related to a control flow of the target function; and based on the first characteristic information, generate a function name of the target function.

[0050] As an embodiment of the present application, the function name recovery device can implement any method of the first aspect described above.

[0051] In a third aspect, an embodiment of the present application provides an electronic device, which includes a memory and a processor. The memory stores a computer program that can be run on the processor. When the processor executes the computer program, it implements any method as described in the first aspect above.

[0052] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the method of any one of the above-mentioned first aspects.

[0053] In a fifth aspect, embodiments of the present application provide a chip system, comprising a processor coupled to a memory, the processor executing a computer program stored in the memory to implement any of the methods described in the first aspect. The chip system may be a single chip or a chip module consisting of multiple chips.

[0054] In a sixth aspect, an embodiment of the present application provides a computer program product, which, when executed on an electronic device, enables the electronic device to execute any one of the methods of the first aspect.

[0055] It can be understood that the beneficial effects of the second to sixth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 A schematic diagram of the source code provided for the embodiments of the present application; Figure 2 A schematic diagram of the assembly code corresponding to a binary file without removing the static symbol table provided in an embodiment of the present application; Figure 3 A schematic diagram of the assembly code corresponding to a binary file with the static symbol table removed provided in an embodiment of the present application; Figure 4 A schematic diagram of the effect of function name recovery provided in an embodiment of the present application; Figure 5 A flowchart of a method for restoring a function name provided in an embodiment of the present application; Figure 6 A schematic diagram of the process of extracting structural information of a function provided in an embodiment of the present application; Figure 7 A schematic diagram of the process from binary file to intermediate file provided in an embodiment of the present application; Figure 8 A schematic diagram of the variable portion of the intermediate file provided in an embodiment of the present application; Figure 9 A schematic diagram of a function in the function part of the intermediate file provided in an embodiment of the present application; Figure 10 A schematic diagram of the visual structure of the intermediate file provided in the embodiment of the present application; Figure 11 A schematic diagram of a visual structure of a function provided in an embodiment of the present application; Figure 12 A schematic diagram of the instruction conversion process provided in an embodiment of the present application; Figure 13 A schematic diagram of the conversion process of a branch merge instruction provided in an embodiment of the present application; Figure 14 A diagram for directly converting P-Code code into LLVM IR file; Figure 15 A schematic diagram of converting the intermediate file to the LLVM IR file; Figure 16 A schematic diagram of a control flow graph provided in an embodiment of the present application; Figure 17 A schematic diagram of a process for training a function name generation model provided in an embodiment of the present application; Figure 18 A schematic diagram of the process of optimizing function names provided in an embodiment of the present application; Figure 19A flowchart of another method for restoring function names provided in an embodiment of the present application; Figure 20 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0057] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0058] The following describes some concepts that may be involved in the embodiments of this application: (1) Multiple: Unless otherwise specified, in the embodiments of this application, multiple refers to two or more.

[0059] (2) Assembly language, machine language, high-level programming language: In the embodiments of this application, a high-level programming language (hereinafter referred to as a high-level language) is a programming language for human users, which has a high level of abstraction and is closer to human natural language. High-level languages ​​may include C, C++, Python, PHP, Java, etc.

[0060] Machine language is the lowest-level language understood and executed by a computer's central processing unit (CPU). It is a binary code directly recognized by computer hardware. It consists of multiple instruction codes (also called machine instructions), each composed of 0s and 1s, corresponding to a basic operation of the computer hardware.

[0061] Assembly language is a low-level, machine-oriented programming language that can be used in electronic computers, microprocessors, microcontrollers, or other programmable devices. In assembly language, mnemonics replace the opcodes of machine instructions, and symbols or labels replace the addresses of instructions or operands. Therefore, assembly language is also called a symbolic language. During the assembly process, assembly language is converted into machine language. The same assembly code (also called an assembly instruction set) corresponds to different machine codes (also called machine instruction sets) on different devices.

[0062] In general, machine language corresponds directly to binary instructions and is difficult to understand and remember. Assembly language uses mnemonics and is efficient but lacks versatility. High-level languages ​​are easy to write and have good portability.

[0063] While assembly instructions are easier to read and write than binary machine instructions, they are still not as close to natural language as high-level languages. Therefore, in practical applications, a high-level language is usually used to generate source code, which is then translated into machine language using a special program.

[0064] In the embodiments of the present application, program codes programmed in a high-level language may be referred to as source code, source code in a machine language format may be referred to as machine code, and source code in an assembly language format may be referred to as assembly code.

[0065] (3) Program compilation, assembly, disassembly, and decompilation: In the embodiments of this application, program compilation is the process of converting source code written in a high-level programming language (such as C, C++, Java, Python, etc.) into machine code. Machine code is binary machine language code, that is, machine code is binary code. Compiled machine code can be directly executed by a computer, while source code requires a compiler to convert it into machine code before it can be run.

[0066] Files that carry machine code are called binary files. Binary file formats include object file format (.o file), shared object file format (.so file), executable file format (.exe file), and so on.

[0067] When the compilation environment is different, the multiple machine codes compiled from the same source code will be different. The compilation environment is related to the compiler type, operating system, and operating system architecture.

[0068] Assembly refers to the process of translating assembly language into machine language.

[0069] Disassembly is the process of converting binary machine code into assembly language code for easier understanding and analysis. In practice, disassembly tools such as IDA-Pro and Ghidra can be used to disassemble binary machine code.

[0070] Decompilation is the process of converting binary machine code into high-level language code. The goal is to restore the high-level logic and structure of the program, making it easier for humans to understand. In practice, decompilation tools such as IDA-Pro and Ghidra can be used to decompile binary machine code.

[0071] In practical applications, disassembly and decompilation are often used in combination. Disassembly can help analyze the low-level structure and control flow of a program, while decompilation can help analyze the high-level logic and data structure of a program.

[0072] (4) Program debugging: In the embodiments of this application, program debugging is the process of finding errors in a compiled program before it is actually run. The purpose is to detect whether the program can run normally and to identify potential problems. By debugging a program, the robustness of the program can be improved and the probability of program crashes can be reduced. In other words, program debugging is an important means of improving program quality. Program debugging can correct syntax errors and logical errors in the program.

[0073] (5) Binary Reverse Engineering: In the embodiments of this application, binary reverse engineering is the technique of reverse engineering binary files (e.g., executable files, library files, firmware, etc.) to understand the internal structure, functions, and behavior of the files. Binary reverse engineering is widely used in various fields, including software security, malware analysis, vulnerability detection, and legacy system maintenance.

[0074] Binary reverse analysis is performed using binary reverse analysis tools. Binary reverse analysis tools are used to convert binary programs (machine code) into assembly language assembler programs (assembly code) to facilitate analysis of the program's execution logic.

[0075] Commonly used binary reverse analysis tools include the Interactive DisAssembler Professional (IDA-Pro) and the Ghidra Reverse Engineering Framework. The latter can be referred to as Ghidra.

[0076] (6) Static Symbol Table, Dynamic Symbol Table, and Debug Information: In the embodiments of this application, the static symbol table and the dynamic symbol table are two different symbol tables. The symbol table is used to record symbolic information such as function names and variable names.

[0077] The static symbol table is created at compile time, typically during the program's compilation phase (especially during syntax and semantic analysis). It contains all statically defined symbols in the program (such as global variables, functions, classes, constants, and so on). The static symbol table remains unchanged throughout the program's lifecycle. It primarily manages metadata for all static symbols in the source code (such as the type, scope, and address of functions and global variables). Its purpose is to support syntax and semantic analysis during compilation, as well as symbolic linking when generating executable files.

[0078] The dynamic symbol table is created and maintained during program execution, typically during program execution. It stores symbols related to the program's execution environment (such as dynamic libraries, function calls, and local variables). The dynamic symbol table is typically managed dynamically by the operating system or the program's runtime system (such as the linker or loader). The dynamic symbol table is primarily used to manage symbols during program execution, particularly those related to dynamic linking, shared libraries, and function calls. Its purpose is to provide symbol lookup and mapping capabilities for dynamic linking and loading during program execution.

[0079] Debug information refers to additional data stored in binary files (such as executable or object files) after a program is compiled to support debugging. This information contains metadata that aids in debugging and analyzing the program. This information can include function names, variable names, data structures, source file names, and line numbers. Debug information can help developers track down problems in the source code during development and debugging. While debug information typically does not directly affect program execution, it provides debugging tools with a mapping from source code to machine code. For example, debug information can map a line of binary machine code to the source code line.

[0080] (7) Stripping technology: In computer programming, Strip is a commonly used tool or technology to remove debugging information and symbol tables from binary files, thereby reducing the file size.

[0081] After using Strip to remove the symbol table, the program's internal implementation (such as function names and variable names) is more difficult to analyze by reverse engineering tools, helping to protect the program code. In addition, since unnecessary data is removed from the program code after Stripping, the program's loading speed and execution efficiency may be slightly improved.

[0082] (8) Symbol table stripping: In the embodiments of the present application, symbol table stripping refers to removing the symbol table information in the compiled program during the software development process. For example, Strip can be used to remove the symbol table information in the program.

[0083] (9) Symbol table obfuscation: In the present application, symbol table obfuscation refers to modifying or hiding the symbol table information in the program to make the code difficult to reverse engineer. By obfuscating the symbol table, the code can be made difficult to understand and analyze, thereby achieving the purpose of protecting the program.

[0084] Symbol table obfuscation methods primarily include symbol removal and symbol renaming. Symbol removal involves using tools like Strip to remove symbol table information from a program. Symbol renaming involves replacing the original names with meaningless or random characters, renaming symbols such as function and variable names within a program to make it difficult for reverse engineers to understand the code's functionality through the names.

[0085] (10) Critical and dangerous functions: In the embodiments of the present application, critical and dangerous functions generally refer to functions that may cause security issues in programming. If these functions are used improperly, they may cause serious security vulnerabilities or data leakage.

[0086] (11) Pseudocode: In the embodiments of this application, pseudocode may also be referred to as intermediate representation code or P-Code. P-Code is an abstract intermediate representation code used in the reverse engineering process. The function of P-Code is to convert the underlying machine code into an abstract code that is easier to understand. It makes reverse engineering more efficient and concise, and can help analysts better understand the high-level logic and behavior of the program.

[0087] The P-Code may include a high-level pseudocode (High P-Code) and a low-level pseudocode (Low P-Code).

[0088] High P-Code is closer to high-level language representation and is a high-level intermediate representation. High P-Code is typically used to represent the high-level structure and logic of a program. It contains information such as function calls and control flow, and is close to the abstraction of the source code. Because High P-Code is closer to the source code, it typically retains more details related to program behavior and semantics, such as function parameters, local variables, and conditional statements. High P-Code can help analysts understand the logic of decompiled code.

[0089] Low P-Code is closer to the underlying representation; it's a low-level intermediate representation. Low P-Code is closer to the execution details of machine instructions and assembly code. It loses some of the abstract information found in high-level languages ​​and focuses more on the control and operation of low-level instructions. Low P-Code focuses more on the control flow and data flow of the program, and its representation is closer to actual machine or assembly instructions rather than high-level language constructs. Low P-Code is primarily used to more accurately restore the underlying behavior of a program, especially when the program is based on machine code or assembly code, as Low P-Code provides a more direct mapping of low-level instructions.

[0090] In practice, binary reverse engineering tools, such as Ghidra, can be used to convert binary machine code (machine instruction set) into P-Code (P-Code instruction set). Each P-Code instruction in the P-Code instruction set corresponds to a P-Code operation. P-Code operations are the basic unit of P-Code, and each P-Code operation represents an atomic operation. P-Code may involve 63 atomic operations, covering basic arithmetic operations, logical operations, comparison operations, memory operations, control flow operations, and architecture-specific operations.

[0091] Specifically, in P-Code, the program's execution logic is represented by various types of nodes. These nodes represent the basic operations performed within the program. Each P-Code node typically corresponds to an operation instruction (P-Code instruction) or a higher-level logical operation. Common node types in P-Code include: Assignment Nodes, Arithmetic Operation Nodes, Logical Operation Nodes, Comparison Nodes, Control Flow Nodes, Function Call Nodes, Memory Access Nodes, Constant Load Nodes, Stack Operation Nodes, Branch Nodes, and Exception Handling Nodes. Assignment Nodes represent the assignment of a value to a variable or memory location. Arithmetic Operation Nodes represent basic arithmetic operations such as addition, subtraction, multiplication, and division. Logic operation nodes represent logical operations such as AND, OR, XOR, and NOT. Comparison nodes are used to perform comparison operations, typically producing Boolean results. Control flow nodes represent control flow instructions in a program, such as jumps and conditional jumps. Function call nodes represent function calls in a program, which typically involve jumps to other functions or subroutines. Memory access nodes represent read or write operations on memory locations, which are typically used to access data in arrays, structure fields, the stack, or the heap. Constant load nodes represent loading constant values ​​into registers or memory locations. Branch nodes represent conditional jumps in a program, typically based on the results of a previous comparison or calculation. Exception handling nodes indicate handling exceptions or specific control flows in a program, such as handling specific errors or signals.

[0092] In addition, the P-Code code abstracts operands and registers into variable nodes, which are divided into: register, memory, stack, constant, and unique intermediate variable according to storage location and function.

[0093] (12) Basic Block: In the embodiments of the present application, a basic block is a sequence of statements executed sequentially in a program, wherein the basic block has only one entry and one exit, the entry being the first statement and the exit being the last statement.

[0094] A basic block can be considered the smallest, independent processing unit in a program. Within this unit, instructions are executed linearly without any jumps (except at the end of the basic block). The beginning of a basic block is typically the target of a control flow instruction, while the end is the point where the control flow changes. Control flow instructions, such as branch instructions, jump instructions, return instructions, call instructions, and loop instructions, are instructions that can change the order of program execution. Control flow instructions must specify a target address, that is, where to jump to continue execution.

[0095] Each function in a program can be composed of one or more basic blocks. The start of a function marks the beginning of the first basic block, while control flow instructions within the function (such as conditional branches and loops) cause the end of a basic block and the beginning of a new basic block. Therefore, a function can be viewed as a collection of basic blocks, which are interconnected by control flow instructions.

[0096] (13) Low Level Virtual Machine (LLVM): In the embodiments of this application, LLVM is a powerful and flexible compiler framework that is widely used in compiler development, program optimization, static analysis, and language implementation. It provides cross-platform compilation support, has a modular design and powerful optimization capabilities, and can effectively generate efficient target code. With LLVM, developers can focus more on the design and implementation of programming languages ​​without having to develop compilation tools for each hardware platform.

[0097] LLVM uses a low-level abstract language called an Intermediate Representation (IR) at the core of the compilation process. LLVM IR is a hardware-independent intermediate representation that converts P-Code from a high-level language into a more standardized low-level representation. This provides a unified representation that is platform- and language-independent, facilitating analysis and optimization.

[0098] (14) Control Flow Graph (CFG): In the embodiments of the present application, a control flow graph is an abstract representation of a program, representing all paths that will be traversed during the execution of the program. The control flow graph uses a graph to represent the possible execution flows of all basic blocks within the program, and also reflects the real-time execution process of the program. The control flow graph consists of nodes and edges. Nodes represent basic blocks, and edges represent the paths of control flow, that is, the paths from one basic block to another.

[0099] (15) Three-Address Code (TAC): In the embodiments of this application, TAC is an intermediate language. Each TAC instruction can be decomposed into four tuples: operator, operand 1, operand 2, and result. Operand 1, operand 2, and result are variables. Because each TAC instruction contains three variables, it is called TAC. It should be noted that each instruction in TAC has only one operation, and the processing process is simple.

[0100] Binary reverse engineering is a technique that analyzes software binary files (machine code) to understand the behavior and logic of software. Binary reverse engineering is widely used in various fields, including software security, malware analysis, vulnerability detection, and legacy system maintenance.

[0101] Recovering function names is a crucial task in binary reverse engineering. Function names often reflect their functionality and purpose. Recovering these names can help understand the behavior and logical structure of a software program. They can also help quickly locate specific functional modules or code segments, improving reverse engineering efficiency. In security analysis and vulnerability research, accurate function names can help quickly identify potential security risks and critical functions.

[0102] In related technologies, source code written in a high-level language is typically compiled into a binary file (machine code) that can be understood by a machine. In practical applications, when compiling the source code of a software program (such as closed-source software) into a binary file, symbol information within the binary file is often removed or obfuscated. This removes unnecessary data, improving program loading speed and execution efficiency, while also protecting the security of the source code. For example, during the process of compiling source code into a binary file, the Strip tool can be used to remove symbolic information from the source code. Specifically, one or more of the static symbol table, dynamic symbol table, and debugging information can be removed.

[0103] The following combination Figures 1 to 3 , taking the removal of static symbol tables as an example, this paper explains the difference between binary files obtained by removing symbol information and those obtained by not removing symbol information. Figure 1 A schematic diagram of the source code provided for an embodiment of the present application. Figure 2 A schematic diagram of the assembly code corresponding to a binary file without removing the static symbol table provided in an embodiment of the present application. Figure 3A schematic diagram of the assembly code corresponding to a binary file with the static symbol table removed provided in an embodiment of the present application. It is understandable that since the binary machine language presented by the binary file is not easy to read, the assembly code corresponding to the binary file is used for example description.

[0104] It should be noted that in the embodiments of the present application, a bold font is used to display important content. It is understandable that the embodiments of the present application do not specifically limit how to display important content. For example, in some application scenarios, underlining can be used to distinguish and display important content parts. Specifically, a wavy underline can be used to display important content parts. In other application scenarios, color can also be used to distinguish and display important content parts. Specifically, bright colors can be used to display important content parts.

[0105] like Figure 1 As shown, the source code is the definition code of the CRYPTO_control function, and the CRYPTO_encrypt function and the CRYPTO_decrypt function are called in the CRYPTO_control function.

[0106] It should be pointed out that the static symbol table is used to record the symbols defined and referenced in the program (such as global variable names, function names). For example, Figure 1 , the following symbols can be recorded in the static symbol table: CRYPTO_control, CRYPTO_encrypt and CRYPTO_decrypt.

[0107] like Figure 2 As shown, while the symbol information is retained in the binary file, after disassembling the binary file using a disassembly tool, the function name of each function, namely CRYPTO_control, CRYPTO_encrypt, and CRYPTO_decrypt, is fully presented. The assembly code clearly reflects the logic of the source code.

[0108] like Figure 3 As shown, when the binary file does not retain symbol information, after disassembling the binary file using a disassembly tool, the function name of each function is replaced by a symbol without semantic information. Specifically, FUN_00101209 is used to replace the function name of the CRYPTO_control function, FUN_00101270 is used to replace the function name of the CRYPTO_encrypt function, and FUN_00101359 is used to replace the function name of the CRYPTO_decrypt function. Figure 3 The assembly code shown makes it difficult for users to quickly understand the logic of the source code, and it is also impossible to filter and directly locate some key dangerous functions based on function names.

[0109] from Figures 1 to 3 It can be found that when the symbol information of the compiled binary file is removed, the function names in the source code cannot be restored from the assembly code obtained by decompiling the binary file, and it is impossible to filter and directly locate the key dangerous functions based on the function names.

[0110] To recover the function names in the source code from a binary file, one option is for the electronic device to directly call a binary reverse analysis tool, such as IDA-Pro or Ghidra, and have the binary reverse analysis tool analyze the function names in the source code corresponding to the binary file. However, the function names generated directly using a binary reverse analysis tool are less accurate. Taking Ghidra as an example, if function 1 is defined in a .so file, and the .so file records the function name and function address of function 1, and the function address of function 1 in the .so file is address 1. If function 1 is called in a .o file, and the function address of function 1 in the .o file is address 2, in this case, since address 1 and address 2 are often different, if the function name of function 1 in the .so file is removed, the .o file will not be able to call function 1, Ghidra will not be able to track the relevant information of function 1, and will not be able to recover the function name of function 1, resulting in low accuracy in function name recovery.

[0111] In order to solve the problem of recovering the function name of the source code from a binary file with symbol information removed, in this application, the binary file is first converted into P-Code code; then the structural information of the function is extracted from the P-Code code, and then combined with the structural information of the function, an intermediate file for recording the structure of the function in the P-Code code is generated; then, based on the intermediate file, the P-Code instructions of various operation types related to the function structure are converted into LLVM IR instructions, thereby obtaining an LLVM IR file; finally, the control flow graph of the function is generated based on the LLVM IR file, and the function name of the function is generated based on the control flow graph.

[0112] Optionally, the P-Code instructions of various operation types related to the function structure may involve operation types including but not limited to: obtaining input variables, updating output variables, branch merging, and regular types. Regular types are operation types other than obtaining input variables, updating output variables, and branch merging. Each P-Code instruction corresponds to a P-Code operation, and each P-Code operation corresponds to an operation type. It should be pointed out that the P-Code operation is the basic unit in the P-Code code, and each P-Code operation represents an atomic operation. There may be 63 types of atomic operations involved in the P-Code code, covering basic arithmetic operations, logical operations, comparison operations, memory operations, control flow operations, and architecture-specific operations.

[0113] As an example, the instruction corresponding to obtaining the input variable may be a load instruction, the instruction corresponding to updating the output variable may be a store instruction, and the instruction corresponding to branch merging may be a MULTIEQUAL instruction.

[0114] It should be pointed out that converting the P-Code instructions of various operation types described in the intermediate file into corresponding LLVMIR instructions can ensure that each P-Code instruction involved in the function is converted into an LLVM IR instruction, which means that a comprehensive and accurate conversion of the instructions involved in the function can be achieved.

[0115] Optionally, the P-Code obtained from the binary file can include high-level pseudocode and low-level pseudocode. The electronic device can use the high-level pseudocode for analysis. Specifically, it can extract the function's structural information from the high-level pseudocode. It should be noted that since the high-level pseudocode focuses more on the source code itself and not the underlying architecture, while the low-level pseudocode contains a large amount of information related to the underlying architecture, and this information related to the underlying architecture is unrelated to the function itself, using the high-level pseudocode for function name recovery can avoid excessive irrelevant interference information, help reduce the amount of data processing, and improve the efficiency of function name recovery.

[0116] Combine Figure 4 , Figure 4 A schematic diagram of the effect of function name recovery provided in an embodiment of the present application. Figure 4 (a) shows the assembly code corresponding to the target binary file. Figure 4 (b) shows the assembly code obtained after restoring the function names of the target binary file. It should be noted that, for the sake of ease of description, the embodiment of the present application may refer to the binary file with symbol information removed as the target binary file.

[0117] like Figure 4As shown in (a), in the assembly code corresponding to the target binary file, the function name is unknown, or the function name is replaced by a symbol with an unknown meaning.

[0118] like Figure 4 As shown in (b) of the figure, after restoring the function names in the target binary, the function names in the resulting assembly code are also restored. In this case, the user can combine the assembly code with the accurate function names to accurately determine whether there are critical dangerous functions in the source code and locate them.

[0119] Combine Figure 4 It can be found that the function name recovery method provided by this application can accurately restore the function name of each function in the software program, which helps to discover the dangers in the software through the function name, thereby ensuring the security of the software.

[0120] The embodiments of the present application have at least the following beneficial effects: 1. The function's structural information can accurately describe the function's characteristics and accurately extract rich and comprehensive structural information of each function, such as function information, basic block information in the function, and variable information in the function. It also generates the function's name based on the function's structural information, which helps improve the accuracy of function name recovery.

[0121] 2. Since LLVM IR is an intermediate representation that is independent of the specific hardware platform, it converts P-Code code from a high-level language into a more standardized low-level representation, which can obtain a unified representation that is independent of the platform and language, making it easier to analyze and optimize. By first converting the intermediate file into an LLVM IR file, you can use the powerful functions of LLVM to perform cross-platform optimization and analysis, and simplify the generation process of the control flow graph, making analysis and optimization more efficient and universal.

[0122] 3. When the function name is accurately restored, key dangerous functions can be filtered and directly located based on the function name, which helps to ensure software security.

[0123] 4. Since the intermediate file only records the P-Code code part related to the function structure, generating the LLVM IR file corresponding to the P-Code code based on the intermediate file can avoid converting the P-Code code part that is not related to the function structure into LLVM IR instructions. In other words, this application can avoid converting redundant instructions in the P-Code code, which helps to improve the efficiency of function name recovery.

[0124] 5. Converting the P-Code instructions of various operation types described in the intermediate file into corresponding LLVM IR instructions can ensure that each P-Code instruction involved in the function is converted into an LLVM IR instruction. In other words, it is possible to achieve comprehensive and accurate conversion of the instructions involved in the function. This helps to fully and accurately extract the feature information of the function, thereby improving the accuracy of function name recovery.

[0125] 6. Since high-level pseudocode focuses more on the source code itself and not the underlying architecture, low-level pseudocode contains a large amount of information related to the underlying architecture, and this information related to the underlying architecture has nothing to do with the function itself, therefore, using high-level pseudocode for function name recovery can avoid excessive irrelevant interference information, help reduce data processing volume, and improve function name recovery efficiency.

[0126] The following describes the usage scenarios of the embodiments of this application: The embodiments of the present application may be applicable to scenarios where function names in software programs are restored.

[0127] The function name recovery method provided in the embodiments of the present application can be applied to electronic devices, such as terminals or servers. The terminals can be tablet computers, in-vehicle devices, augmented reality / virtual reality devices, laptop computers, ultra-mobile personal computers, and the like. The servers can be network servers, cloud servers, and the like. The embodiments of the present application are not limited thereto.

[0128] Figure 5 A flow chart of a method for restoring a function name provided in an embodiment of the present application is shown as follows: Figure 5 As shown, the function name recovery method may include the following steps 501 to 507. It is understood that the above function name recovery method may include all steps 501 to 507, or may include only some of them. It is understood that the steps in the function name recovery method may be combined arbitrarily if they do not conflict.

[0129] Step 501: The electronic device generates a target pseudo code for the target binary file based on the target binary file.

[0130] The target pseudocode is the pseudocode corresponding to the target binary file. Pseudocode can also be called P-Code. P-Code is a set of P-Code instructions, referred to as the P-Code instruction set.

[0131] Optionally, the target binary file is a binary file with symbol information removed. In this application, a binary file refers to a file that carries the machine code of a program.

[0132] In some scenarios, binary files may also be referred to as machine code files or simply machine code. Machine code is a collection of machine instructions, also known as a machine instruction set. Binary file formats may include object file formats (.o files), shared object file formats (.so files), and executable file formats (.exe files). It is understood that the embodiments of this application do not specifically limit the file format of target binary files.

[0133] P-Code can include high-level pseudocode (High P-Code) and low-level pseudocode (Low P-Code). High P-Code and Low P-Code essentially correspond to the logic of the same program.

[0134] High-P-Code is closer to the source code and typically retains more details related to program behavior and semantics. In other words, High-P-Code focuses more on the source code itself and less on the underlying architecture. Low-P-Code, on the other hand, focuses more on the control and operation of low-level instructions. In other words, Low-P-Code contains a lot of information about the underlying architecture.

[0135] Considering that Low-P-Code contains a large amount of information related to the underlying architecture, which is irrelevant to the function to be recovered in this application, in order to avoid excessive irrelevant interference information, High-P-Code can be used for function name recovery in this application. In other words, the target pseudocode is usually high-level pseudocode.

[0136] In step 501, the electronic device can invoke a binary reverse analysis tool, such as Ghidra, to first disassemble the target binary file (i.e., the machine instruction set) into assembly code, and then decompile the assembly code into P-Code. It will be appreciated that if high P-Code is used to recover function names, only high P-Code can be generated in step 501, without generating low P-Code. This saves unnecessary time and computing resources.

[0137] Step 502: The electronic device parses the target pseudo code and extracts the structural information of each function in the target pseudo code.

[0138] Similar to high-level languages ​​(such as C++), the target pseudocode (P-Code) can include functions corresponding to the source code. Each function includes one or more basic blocks, each containing a series of P-Code instructions, and each P-Code instruction corresponds to a P-Code operation. P-Code operations are the basic units of P-Code, and each P-Code operation represents an atomic operation. P-Code may involve 63 atomic operations, covering basic arithmetic operations, logical operations, comparison operations, memory operations, control flow operations, and architecture-specific operations.

[0139] The structural information of a function may include function information, basic block information in the function, and variable information in the function. Function information is used to describe the function, basic block information is used to describe the basic blocks in the function, and variable information is used to describe the variables in the function.

[0140] Function information may include, but is not limited to, the function name (referred to as the function name), the function's starting address, and the type and size of the function's return value. The function's starting address is the function's entry address, which is the storage address of the first P-Code instruction in the function.

[0141] Basic block information may include but is not limited to: the forward node information of the basic block, the backward node information of the basic block, the index of the basic block, and the first address of the basic block. The first address of the basic block is also called the entry address of the basic block. The first address of the basic block is the storage address of the first P-Code instruction in the basic block. Among them, the index of the basic block is the unique identifier of the basic block. Each basic block has an index. For example, the index of the first basic block in a function can be 0, the index of the next basic block can be 1, and so on. Since a basic block is a sequence of statements executed sequentially in a program, there is only one entry and one exit, the entry is its first statement, and the exit is its last statement. Therefore, for any basic block, the forward node of the basic block is the P-Code instruction that jumps to the basic block, and the backward node of the basic block is the P-Code instruction that the basic block needs to jump to.

[0142] For example, if function 1 includes three basic blocks, basic block 0 through basic block 2, and basic block 0 can jump to basic block 1 and basic block 1 can jump to basic block 2, then for basic block 0, there is no forward node, and the backward node is the first P-Code instruction in basic block 1. For basic block 1, the forward node is the last P-Code instruction in basic block 0, and the backward node is the first P-Code instruction in basic block 2. For basic block 2, there is no backward node, and the forward node is the last P-Code instruction in basic block 1.

[0143] It is understandable that a basic block may have no forward node or one or more forward nodes. A basic block may have no backward node or one or more backward nodes.

[0144] The variable information may include, but is not limited to, the variable storage type, variable size, and variable name. Optionally, the variable storage type involved in the variable information may include: register type, memory type, and stack type.

[0145] In an embodiment of the present application, since the P-Code code has a specific syntax, the electronic device can extract function information, basic block information in the function, and variable information in the function from the P-Code code in combination with the syntax of the P-Code code.

[0146] It's important to note that since P-Code is inherently unordered, extracting the structural information of each function from it allows for orderly classification of the unordered P-Code. Furthermore, categorizing the P-Code layer by layer, such as function, basic blocks within a function, instructions within a basic block, and variables, helps accurately extract the semantic structure of each function, thereby ensuring the accuracy of function name recovery.

[0147] The following combination Figure 6 This paper describes how to extract the structure information of a function from P-Code. Figure 6 A schematic diagram of the process of extracting structural information of a function provided in an embodiment of the present application.

[0148] In step 601, the electronic device traverses the P-Code code, and when accessing a first operation instruction, extracts function information of a first function from the first operation instruction.

[0149] The first operation instruction is an instruction in the P-Code that defines a function (which may be referred to as a definition instruction). The first function is the function defined by the first operation instruction. The first function (or target function) may be any function in the P-Code. As will be understood, the P-Code is composed of instructions, and instructions in the P-Code may also be referred to as pseudocode instructions or P-Code instructions. Each instruction in the P-Code corresponds to an operation, such as an AND operation or an OR operation, so instructions in the P-Code may also be referred to as operation instructions.

[0150] In practice, a definition symbol can be used in the P-Code code to indicate the definition of a function, wherein the definition symbol is a pre-set symbol used to indicate the definition of a function. Definition symbols generally include a start symbol and an end symbol, the start symbol indicates the start of defining the function, and the end symbol indicates the end of the definition of the function. For example, "BEGIN FUNC" can be used to indicate the start of defining a function, and "END FUNC" can be used to indicate the end of the definition of the function. For another example, "DEFINE" can be used to indicate the start of defining a function, and "END" can be used to indicate the end of the definition of the function. It can be understood that for different binary reverse analysis tools, the definition symbols may be different, and the embodiments of the present application do not limit the specific implementation of the definition symbols.

[0151] Here, the function information of the first function may include, but is not limited to: the name of the first function (referred to as the function name), the first address of the first function, the type of the return value of the first function, and the size of the return value of the first function. The first address of the first function may also be referred to as the entry address of the first function.

[0152] Here, the electronic device may determine whether the currently accessed instruction is a first operation instruction based on the definition symbol, and if it is the first operation instruction, identify the first function from the first operation instruction and obtain function information of the first function.

[0153] In step 602, the electronic device determines a basic block and basic block information of the basic block from the first function according to each P-Code instruction in the first function.

[0154] Here, each basic block in the first function may include one or more P-Code instructions.

[0155] Basic block information may include, but is not limited to, the basic block's forward node information, the basic block's backward node information, the basic block's index, and the basic block's starting address. The basic block's index is a unique identifier for the basic block, and each basic block has an index. For example, the first basic block in a function may have an index of 0, the next basic block may have an index of 1, and so on. For any basic block, the basic block's forward node is the P-Code instruction that jumps to the basic block, and the basic block's backward node is the P-Code instruction to which the basic block needs to jump.

[0156] It should be pointed out that in the P-Code code, the first address of the first basic block in a function is the entry address of the first P-Code instruction in the function. The last P-Code instruction of a basic block may or may not be a jump instruction. The jump instruction usually includes a jump symbol and the entry address of the jump target, and the jump target is the address of the first P-Code instruction of the next basic block. It can be understood that the entry address of a basic block is also the address of the first P-Code instruction in the basic block. The jump instruction is used to jump from the current position to another position for execution. The jump symbol is a symbol indicating a jump operation. As an example, the jump symbol can be "BRANCH". It should be understood that if the last P-Code instruction of a basic block is not a jump instruction, it means that this function has only one basic block, that is, there is no need to jump to other basic blocks in the function.

[0157] Here, the electronic device may identify each basic block in the first function based on the jump symbols in each P-Code instruction traversed in the first function, and obtain basic block information of the basic block.

[0158] In step 603, the electronic device traverses each P-Code instruction in the first basic block and extracts variable information of each variable in the P-Code instruction.

[0159] The first basic block is any basic block in the first function.

[0160] The variable information may include but is not limited to storage type, variable size, and variable name.

[0161] Optionally, the storage types of the variables involved in the variable information may include: register type, memory type, stack type. It should be noted that the storage types of variables in the P-Code code can be the following five types: register type, memory type, stack type, const type, and unique type. Among them, since the values ​​of const type variables (referred to as const variables) and unique type variables (referred to as unique variables) do not change, only extracting the variable information of register type variables (referred to as register variables), memory type variables (referred to as memory variables), and stack type variables (referred to as stack variables) can reduce the amount of data to be extracted, thereby improving the efficiency of function name recovery.

[0162] Here, for each basic block, the electronic device may traverse each P-Code instruction in the basic block and obtain variable information from the P-Code instruction.

[0163] from Figure 6 It can be found that by traversing the P-Code code, the electronic device can extract the structural information of each function from the P-Code code.

[0164] It should be pointed out that since the structural information of a function can accurately describe the semantic features of the function, accurately extracting the structural information of each function helps to improve the accuracy of function name recovery.

[0165] Step 503: The electronic device generates an intermediate file for recording the structural information of each function in the target pseudo code based on the structural information of each function in the target pseudo code.

[0166] The intermediate file includes the structural information of each function in the target pseudocode (P-Code). The intermediate file can be in either Extensible Markup Language (XML) or JavaScript Object Notation (JSON). It is understood that the present embodiment does not specifically limit the format of the intermediate file.

[0167] Here, the electronic device can write the structural information of each function in the P-Code code into the intermediate file. In this case, the intermediate file can intuitively reflect the structure of the P-Code code.

[0168] The following further combines Figure 7 Explain the process from binary files to intermediate files. Figure 7 A schematic diagram of the process from binary file to intermediate file provided in an embodiment of the present application.

[0169] like Figure 7 As shown, the intermediate file corresponding to the binary file can be obtained through the following steps 701 to 710.

[0170] Step 701: The electronic device obtains a binary file.

[0171] Optionally, the binary file obtained by the electronic device may be a binary file with symbol information removed.

[0172] Step 702: The electronic device converts the binary file into P-Code.

[0173] Here, the operation of converting the binary file into the P-Code code can be referred to the embodiment corresponding to step 501, which will not be described in detail here.

[0174] Step 703: The electronic device traverses the functions in the P-Code.

[0175] Here, the electronic device may refer to step 601 to access the function in the P-Code.

[0176] Step 704: When the first function is accessed, the electronic device extracts the function name, the first address, the return value type and the return value size of the first function; when the first function is not accessed, the electronic device saves the extracted structural information of each function to an intermediate file.

[0177] For any function, the structural information of the function may include function information, basic block information in the function, and variable information in the function.

[0178] The first function is the currently accessed function and can be any function in the P-Code.

[0179] Here, the first function is not accessed, indicating that all functions in the P-Code have been traversed.

[0180] The function name, first address, return value type and return value size of the function can refer to the function information in step 601. The electronic device can refer to the embodiment corresponding to step 601 to extract the function information of the function, which will not be repeated here.

[0181] Step 705: The electronic device traverses the basic blocks in the first function.

[0182] Here, the electronic device may refer to the embodiment corresponding to step 602 to access each basic block in the first function.

[0183] Step 706: If the first basic block is accessed, the electronic device extracts the index, first address, forward node and backward node of the first basic block. If the first basic block is not accessed, the electronic device returns to step 703 and traverses the next function in the P-Code code.

[0184] The first basic block is the currently accessed basic block and can be any basic block in the first function.

[0185] Here, the fact that the first basic block is not accessed indicates that all basic blocks in the first function have been traversed.

[0186] The index, first address, forward node, and backward node of the first basic block can be found in the basic block information in step 602. The electronic device can refer to the embodiment corresponding to step 602 to extract the basic block information of each basic block in the function, which will not be described in detail here.

[0187] Step 707: The electronic device traverses each P-Code instruction in the first base.

[0188] Here, the electronic device may refer to the embodiment corresponding to step 603 to access each P-Code instruction in the first basic block.

[0189] Step 708: When the P-Code instruction is accessed, the electronic device extracts the operation name, output variables, and input variables of the P-Code instruction. When the P-Code instruction is not accessed, the electronic device returns to step 705 and continues to traverse the next basic block in the first function.

[0190] Here, no P-Code instruction is accessed, indicating that all P-Code instructions in the first basic block have been traversed. The electronic device can directly extract the operation name, output variable, and input variable of the P-Code instruction from the currently accessed P-Code instruction.

[0191] Step 709: The electronic device traverses each variable in the P-Code instruction.

[0192] Step 710, when the variable is accessed, the storage type, size, and name of the variable are extracted, and the variables with storage types of stack, register, and memory are recorded. When the variable is not accessed, the electronic device returns to step 707 and continues to traverse the next P-Code instruction in the first basic block.

[0193] Here, no variables are accessed, indicating that all variables in the currently accessed P-Code instruction have been traversed. The variable storage type, size, and name can be found in the variable information in step 603. For electronic devices, refer to the embodiment corresponding to step 603 to extract the variable information for each variable in the function, which will not be detailed here.

[0194] The following combination Figures 8 to 11 , describes the structure of the intermediate file. The intermediate file can include a variable part and a function part. Figure 8 A schematic diagram of the variable portion in the intermediate file provided in an embodiment of the present application. Figure 9 A schematic diagram of a function in the function part of the intermediate file provided in an embodiment of the present application. Figure 10 A schematic diagram of the visual structure of the intermediate file provided in an embodiment of the present application. Figure 11 This is a visual structural diagram of a function provided in an embodiment of the present application.

[0195] like Figure 8As shown, lines 2 to 16 record multiple register variables in the P-Code code, and register variables are global variables. Lines 17 to 23 record the memory variables in the P-Code code. Lines 24 to 26 record the stack variables in the P-Code code. Taking line 3 as an example, line 3 describes a register variable, the name of which is "EAX" and the size is 4 bytes. It should be understood that Figure 8 The line numbers in the text are only used to distinguish the descriptions and are not specific limitations on the lines.

[0196] Combine Figure 8 As you can see, the intermediate file clearly records the information of each variable in the P-Code. The intermediate file can record the register variables, memory variables, and stack variables in the P-Code, such as the name and size of each variable.

[0197] like Figure 9 As shown, lines 1 to 39 describe a function. Line 1 describes the function's entry point and name. Line 2 describes the function's output information, and line 3 describes the function's input information. Lines 4 to 38 describe the basic blocks within the function.

[0198] Lines 5 to 37 describe the first basic block in the function, block_0. Line 6 describes the entry address of block_0, line 7 describes the index of block_0, line 8 describes the forward node of block_0, and line 9 describes the backward node of block_0.

[0199] Lines 10 to 36 describe the P-Code instructions in block_0, where lines 11 to 18 describe the first P-Code instruction, which is pcode_0, lines 19 to 26 describe the second P-Code instruction, which is pcode_1, and lines 27 to 35 describe the third P-Code instruction, which is pcode_2.

[0200] Taking pcode_0 as an example, line 12 describes the output variable information of pcode_0. Line 13 describes the operation name of pcode_0. Lines 14 to 17 describe the input variable information of pcode_0, of which lines 15 to 16 describe the information of the first input variable in pcode_0.

[0201] Combine Figure 9 , Figure 9The first address (that is, the entry address of the function) shown (referred to as the diagram function) is 00101000, and the function name is "init" (see Figure 9 The return type of the function is "int" (see Figure 9 The input parameter of the function is named "ctx" and of type "EVP_PKEY_CTX" (see Figure 9 The function shown has only one basic block, block_0 (see Figure 9 4 to 38 in the .

[0202] The first address (entry address) of block_0 (the first basic block) of the function shown in the figure is "00101004", the index is 0, there is no forward node, and there is no backward node. (See Figure 9 6 to 9 in the .

[0203] There are three P-Code instructions in block_0, namely pcode_0 (see Figure 9 Lines 11 to 18 in Figure 9 19 to 26 in ) and pcode_2 (see Figure 9 27 to 35 in the .

[0204] The output variable of pcode_0 is EAX, the storage type is register type, and the size is 4 bytes (see Figure 9 The operation type of pcode_0 is CALL operation (see Figure 9 The input variable of pcode_0 is "A_00105050:8", the storage type is memory type, and the size is 8 bytes (see Figure 9 15 in the .

[0205] The output variable of pcode_1 is EAX, the storage type is register type, and the size is 4 bytes (see Figure 9 The operation type of pcode_1 is COPY operation (see Figure 9 The input variable of pcode_1 is EAX, the storage type is register type, and the size is 4 bytes (see Figure 9 23 in the .

[0206] The operation type of pcode_2 is a RETURN operation (see Figure 9 The first input variable of pcode_2 is "0x0", the storage type is constant type, and the size is 8 bytes (see Figure 9 The second input variable of pcode_2 is EAX, which is of register type and 4 bytes in size (see Figure 9 32 in the .

[0207] Understandably, Figure 9 The function shown is only an example and is not a specific limitation of the function.

[0208] from Figure 9 It can be seen that the intermediate file clearly records the structural information of each function in the P-Code code. It should be noted that electronic devices can access the P-Code instructions in a function based on the function's entry address (also called the function's first address or first entry address) recorded in the intermediate file. Electronic devices can also access the P-Code instructions in a basic block based on the entry address (also called the basic block's first address or second entry address) recorded in the intermediate file. In this way, based on the intermediate file, only the P-Code instructions related to the function can be converted into three-address code instructions, such as LLVM IR instructions. Converting P-Code instructions into three-address code instructions facilitates the extraction of the function's control flow information, which accurately describes the function's semantics. In other words, converting the P-Code instructions related to the function into three-address code instructions can accurately and effectively extract the function's semantic features.

[0209] like Figure 10 As shown, the intermediate file may include four information blocks, namely, a global information block (see Figure 10 Lines 3 and 4 in the ), memory variable information block (see Figure 10 Lines 5 and 6 in the stack variable information block (see Figure 10 7 in the function information block (see Figure 10 (Lines 8 to 17 in the data structure). The global information block records 13 register variables. The memory variable information block records 32 memory variables. The function information block records 38 functions.

[0210] Further references Figure 11 , Figure 11 This is a schematic diagram of the structure of the function numbered 17 in the intermediate file (referred to as function 17). Figure 11 As shown, the structure of function 17 may include 5 parts, namely: output part (see Figure 11 Lines 2 and 3 in ), the input section (see Figure 11 Line 4 in ), the basic block part (see Figure 11Lines 5 to 11 in the entry address section (see Figure 11 Line 12 in ), the function name part (see Figure 11 13 in the .

[0211] Figure 11 In the output section, it is described that function 17 has one output and the output type is void.

[0212] The input section describes that function 17 has 5 inputs.

[0213] The basic block section describes that function 17 has a basic block, block_0, and block_0 has five items: entry address, index, forward node, backward node, P-Code instruction (see Figure 11 Specifically, the entry address in block_0 is "00101350", the index is 0, there is no forward node and no backward node, and block_0 has 7 P-Code instructions.

[0214] The entry address part describes that the entry address of function 17 is: 00101359.

[0215] The function name part describes that the function name of function 17 is: CRYPTO_decrypt.

[0216] from Figures 8 to 11 It can be found that the intermediate file clearly describes the semantic structure of each function in the P-Code code.

[0217] In step 504 , the electronic device generates an LLVM IR file corresponding to the target pseudo code based on the intermediate file.

[0218] Here, the electronic device can traverse the intermediate file. During the traversal of the intermediate file, when accessing an entry address, such as the entry address of a function or a basic block within a function, the electronic device can access each P-Code instruction in the function based on the entry address and convert the P-Code instruction into LLVM IR instructions. In this way, the LLVM IR file corresponding to the entire P-Code code can be obtained.

[0219] It should be pointed out that since the intermediate file only records the P-Code code part related to the function structure, generating the LLVM IR file corresponding to the P-Code code based on the intermediate file can avoid converting the P-Code code part that is not related to the function structure into LLVM IR instructions. In other words, this application can avoid converting redundant instructions in the P-Code code, which helps to improve the efficiency of function name recovery.

[0220] The following combination Figure 12 This chapter explains how to generate the LLVM IR file corresponding to the P-Code code based on the intermediate file. Figure 12 The flowchart of the instruction conversion provided by the embodiment of the present application is as follows. Figure 12 As shown, the instruction conversion process may at least include the following steps 5041 to 5042.

[0221] In step 5041, the electronic device traverses each function in the intermediate file, and based on the entry address of the current function being accessed and the entry addresses of each basic block in the function, accesses each P-Code instruction in the current function.

[0222] The current function is the function currently being accessed.

[0223] Here, the function code, or function body, is stored in memory. Electronic devices can access the function from memory using the function's entry point address. Similarly, electronic devices can access each basic block within the function, or in other words, each P-Code instruction within the basic block, based on the entry point address of the basic block.

[0224] In step 5042, the electronic device determines the operation type corresponding to the first P-Code instruction in the current function, and converts the first P-Code instruction into an LLVM IR instruction based on the operation type corresponding to the first P-Code instruction to obtain an LLVM IR file corresponding to the intermediate file.

[0225] The first P-Code instruction is the currently accessed P-Code instruction.

[0226] Among them, the operation type may include but is not limited to: obtaining input variables, updating output variables, branch merging, and regular types. Regular types are operation types other than obtaining input variables, updating output variables, and branch merging. Among them, each P-Code instruction corresponds to a P-Code operation, and each P-Code operation corresponds to an operation type. It should be pointed out that the P-Code operation is the basic unit in the P-Code code, and each P-Code operation represents an atomic operation. There may be 63 types of atomic operations involved in the P-Code code, covering basic arithmetic operations, logical operations, comparison operations, memory operations, control flow operations, and architecture-specific operations.

[0227] The following describes how to convert the first P-Code instruction into an LLVMIR instruction in conjunction with the operation type of the first P-Code instruction. It is understandable that the electronic device can determine the operation type of the P-Code instruction by the operator of the P-Code instruction.

[0228] Case 1: The operation type of the first P-Code instruction is a normal type.

[0229] In scenario 1, the electronic device may convert the first P-Code instruction into an LLVM IR instruction based on a pre-set operation mapping relationship (or referred to as a first mapping relationship). The operation mapping relationship is used to describe the conversion relationship between the P-Code instruction and the LLVM IR instruction.

[0230] The following describes how to convert P-Code instructions into LLVM IR instructions in conjunction with Table 1. Table 1 is part of the operation mapping relationship provided in the embodiment of the present application.

[0231] Table 1:

[0232] In Table 1, the first column is the operation name of the P-Code operation corresponding to the P-Code instruction, the second column is the data processed by the P-Code operation, and the third column is the LLVM IR instruction corresponding to the P-Code instruction.

[0233] The following describes the contents of each row in Table 1 in order from top to bottom.

[0234] In line 1, BOOL_NEGATE negates a variable, and the return value is a Boolean. !v0 negates the variable v0. In the instruction "%negated = xor i1 %v0, true," %v0 is a variable of type i1, which represents a 1-bit integer. The xor instruction performs an exclusive-or operation on %v0 and true (1), storing the result in %negated. Thus, if %v0 is 1 (true), %negated will be 0 (false). Conversely, if %v0 is 0 (false), %negated will be 1 (true).

[0235] In line 2, INT_NEGATE indicates a bitwise negation operation on a variable. ~ v0 indicates a bitwise negation operation on variable v0. In the instruction "%negated = xor i32 %v0, -1," %v0 is a variable of type i32, which represents a 32-bit integer. The xor instruction is used to perform an exclusive OR operation on %v0 and -1. In binary representation, -1 is equivalent to a number with all bits set to 1 (for example, for a 32-bit integer, -1 is represented as 0xFFFFFFFF), so performing an exclusive OR operation with -1 achieves a bitwise negation effect. The result is stored in %negated.

[0236] In line 3, INT_2COMP indicates the inversion of a variable's two's complement, and - v0 indicates the inversion of v0. In the instruction "%negated = sub i32 0, %v0," %v0 is the variable to be inverted. The sub instruction subtracts %v0 from 0, achieving the inversion effect. The result is stored in %negated.

[0237] In line 4, FLOAT_NEG indicates a negation operation, and the return value is a floating-point number. f-v0 negates v0. In the instruction "%negated = fsub float 0.0, %v0," %v0 is the variable to be negated. The fsub instruction subtracts %v0 from 0.0, achieving the negation effect. The result is stored in %negated.

[0238] In line 5, INT_MULT indicates a multiplication operation, and v0 * v1 multiplies v0 and v1. In the instruction "%result =mul i32 %v0, %v1," %v0 and %v1 are the integer variables to be multiplied. The mul instruction multiplies %v0 and %v1. The result is stored in %result.

[0239] In line 6, INT_DIV indicates a division operation, and v0 / v1 means dividing v0 by v1. In the instruction "%result = udivi32 %v0, %v1," %v0 and %v1 are the integer variables to be divided. The udiv instruction divides %v0 by %v1. The result is stored in %result.

[0240] In line 7, INT_SDIV indicates a signed division operation, and v0 s / v1 indicates a signed division operation on v0 and v1. In the instruction "%result = sdiv i32 %v0, %v1," %v0 and %v1 are the integer variables to be divided. The sdiv instruction divides %v0 by %1, performing signed integer division. The result is stored in %result.

[0241] In line 8, INT_REM indicates the modulo operation, and v0 % v1 indicates performing the modulo operation on v0 and v1. In the instruction "%result = urem i32 %v0, %v1," %v0 and %v1 are the integer variables to be modulo-ed. The urem instruction calculates the remainder when %v0 is divided by %v1, performing an unsigned integer modulo operation. The result is stored in %result.

[0242] In line 9, INT_SREM indicates a signed integer modulo operation. v0 s% v1 indicates a signed integer modulo operation on v0 and v1. In the instruction "%result = srem i32 %v0, %v1," %v0 and %v1 are the integer variables to be modulo-ed. The srem instruction calculates the remainder when %v0 is divided by %v1, performing a signed integer modulo operation. The result is stored in %result.

[0243] It can be found from Table 1 that the electronic device can convert P-Code instructions into LLVM IR instructions based on the operation mapping relationship.

[0244] Case 2: The operation type of the first P-Code instruction is to obtain an input variable. In this case, the first P-Code instruction is an instruction to obtain an input variable, for example, a load instruction.

[0245] In case 2, the electronic device can obtain the storage type of the input variable in the first P-Code instruction, and convert the first P-Code instruction into an LLVM IR instruction based on the storage type of the input variable and the variable table corresponding to the current function.

[0246] The storage types include register type, memory type, stack type, const type, and unique type.

[0247] The variable table is used to record the real-time changes of variables in the function. The variable table can include multiple variable information, each of which can include the variable name, address, and value. It should be noted that for any function, there can be a corresponding variable table, which is used to record the changes in the values ​​of the variables in the function during the program execution. The variables recorded in the variable table can include global variables, local variables, temporary variables, etc. Optionally, the initial variable table corresponding to the function can be an empty table by default.

[0248] Because different types of variables have different storage locations, uses, scopes, and lifecycles, and the values ​​of variables in each function change as the program runs, this application uses a function's variable table to describe the real-time changes of each variable in the function, which can ensure the accuracy of the generated LLVM IR instructions. For example, if a variable is not recorded in the variable table when it is updated, it means that there is a problem with the use of the variable. Therefore, based on the real-time updated variable table, the accuracy of the generated LLVM IR instructions can be guaranteed.

[0249] (1) If the storage type of the input variable is register, the electronic device generates a first target instruction for loading the value into the register variable (i.e., the input variable) and writes the variable information of the input variable into the variable table. In this case, the first target instruction is the LLVM IR instruction corresponding to the first P-Code instruction.

[0250] It should be pointed out that when the input variable is of register type, since register type variables (also called register variables or register variables) do not have a fixed memory address, the initial value of the register variable is usually stored in a certain address in the memory. When the program runs, the value needs to be loaded into the register.

[0251] (2) If the storage type of the input variable is a memory type, the electronic device may generate a second target instruction for obtaining the value of the input variable and writing the variable information of the input variable into the variable table. In this case, the second target instruction is the LLVM IR instruction corresponding to the first P-Code instruction.

[0252] It should be noted that when the storage type of the input variable is memory type, the input variable will be assigned a fixed memory address, so the value of the input variable can be directly read from the memory address.

[0253] (3) If the storage type of the input variable is a stack type, the electronic device may generate a third target instruction for obtaining the value of the input variable from the variable table and writing the variable information of the input variable into the variable table. In this case, the third target instruction is an LLVM IR instruction corresponding to the first P-Code instruction.

[0254] It's important to note that since stack variables are typically local variables within a function, their initial values ​​are often passed from other global variables, such as registers or memory variables. Furthermore, the values ​​of input variables are retrieved from the variable table, enabling efficient transfer of variable values.

[0255] The form of LLVM IR instructions is Static Single Assignment (SSA), that is, each variable should only be assigned once (written only once). As an example, if the eax variable is written twice, then the first time 1 is written to eax, it can be expressed as eax_0 = 1, and the second time 1 is added to eax, it can be expressed as eax_1 = eax_0 + 1. In other words, when using SSA to express instructions, each variable can be assigned only once by renaming the variable. In the embodiment of the present application, the variable information is written into the variable table in a timely manner, which can ensure that the latest value of the variable can always be recorded in the variable table. In the process of variable assignment, tedious recursive value lookup can be avoided, and P-Code instructions can be quickly and accurately converted into LLVM IR instructions, thereby improving the accuracy of function name recovery.

[0256] Optionally, when the input variable is of stack type, during the process of the electronic device generating a third target instruction for obtaining the value of the input variable from the variable table, if the electronic device detects that the input variable does not exist in the current variable table, it can generate a first prompt message, and the first prompt message is used to prompt that the input variable is not defined, or that there is a syntax error in the use of the input variable.

[0257] Case 3: The operation type of the first P-Code instruction is to update the output variable. In this case, the first P-Code instruction is an instruction to update the output variable, for example, it can be a store instruction.

[0258] In scenario 3, the first P-Code instruction includes output variables to be updated and input variables for updating. The electronic device may obtain the storage type of the output variables in the first P-Code instruction and convert the first P-Code instruction into an LLVM IR instruction based on the storage type of the output variables and the variable table corresponding to the current function.

[0259] (1) If the storage type of the output variable is a register type, the electronic device generates a fourth target instruction for converting the data type of the output variable into a first data type, generates a fifth target instruction for storing the output variable of the first data type, and adds the latest variable information of the output variable to the variable table. The first data type is the data type corresponding to the output variable. In this case, the fourth target instruction and the fifth target instruction are LLVM IR instructions corresponding to the first P-Code instruction. As an example, the fourth target instruction can be bitcast i64* @"RAX" to i64**, which means converting the data type of the register variable @"RAX" to the i64** type. Among them, i64* @"RAX" means that the data type of the register variable @"RAX" is i64* type, that is, a pointer to a 64-bit integer. i64** means a pointer to i64*.

[0260] It's important to note that the storage type indicates where a variable is stored. For example, the register type indicates that the variable is stored in a register, while the memory type indicates that the variable is stored in memory. The stack type indicates that the variable is stored on the stack. The data type of a variable refers to the type of data in the variable, such as pointer type, vector type, etc.

[0261] (2) If the storage type of the output variable is a memory type, the electronic device may generate a sixth target instruction for storing the output variable and add the latest variable information of the output variable to the variable table. In this case, the sixth target instruction is the LLVM IR instruction corresponding to the first P-Code instruction.

[0262] (3) If the storage type of the output variable is a stack type, the electronic device may generate a seventh target instruction for storing the output variable and add the latest variable information of the output variable to the variable table. In this case, the seventh target instruction is the LLVM IR instruction corresponding to the first P-Code instruction.

[0263] It should be noted that memory variables are stored in memory and are global variables, so their data types generally remain unchanged. Register variables are stored in registers, and their data types may change during data updates or processing. The stack is a memory area used to store local variables, function parameters, and return addresses when a function is called. Variables on the stack are typically created when a function is called and destroyed when the function returns. Since stack variables are already in memory, electronic devices can change the type or value of these variables directly by updating the entries in the variable table without performing data type conversion operations, such as bitcast operations. Therefore, it is sufficient to directly update the variables in the corresponding variable table.

[0264] In an embodiment of the present application, during the instruction conversion process, the first P-Code instruction is converted into an LLVM IR instruction in a targeted manner in combination with the storage type of the output variable, which can improve the accuracy of the instruction conversion and further improve the efficiency of function name recovery.

[0265] Case 4: The operation type of the first P-Code instruction is a branch merge type. In this case, the first P-Code instruction is a branch merge instruction, for example, a MULTIEQUAL instruction.

[0266] Branch merging refers to the fact that a variable may have different values ​​under different control flow paths. In practical applications, in P-Code, the branch merging operator can be MULTIEQUAL, and in LLVM IR, the branch merging operator can be phi.

[0267] In the embodiments of the present application, since each variable is assigned only once in SSA form, variable version management and optimization are simpler. However, when control flow merges (for example, after an if-else branch statement), a variable may originate from multiple different paths, each of which may assign a different value to the variable. The branch merge instruction is used to handle this situation, merging the values ​​on different paths into a new variable value.

[0268] The format of the MULTIEQUAL instruction can be as follows: <output> <input1> <input2> ... <inputn>, where output is the merged variable, input1 is the variable input by the first branch path, and inputN is the variable input by the Nth branch path. N is the total number of branch paths.

[0269] The format of the phi instruction is: %result = phi <type> [ <value1> , <label1> ], [ <value2> , <label2> ], ... [ <valuen> , <labeln>]. Where label1, label2, ..., labelN are the identifiers of basic blocks. value1 represents the value assigned to the variable in the basic block indicated by label1, value2 represents the value assigned to the variable in the basic block indicated by label2, and labelN represents the value assigned to the variable in the basic block indicated by labelN.

[0270] For example, if there are two basic blocks (label1 and label2), and they both pass a value to result, and the LLVM IR is as follows: %result = phi i32 [42, %label1], [100, %label2]. In this case, if the program control flow comes from the label1 basic block, the value of result will be 42. If the program control flow comes from the label2 basic block, the value of result will be 100.

[0271] In case 4, the electronic device can Figure 13 The operation shown converts the first P-Code instruction into an LLVM IR instruction, or converts the MULTIEQUAL instruction into a phi instruction. Figure 13 The following is a schematic diagram of the conversion process of the branch merge instruction provided in the embodiment of the present application. Figure 13 As shown, converting the branch merge instruction into the LLVM IR instruction may at least include the following steps 50421 to 50424.

[0272] Step 50421: If the first P-Code instruction is a branch merge instruction, the electronic device obtains each input variable in the first P-Code instruction from the first P-Code instruction.

[0273] In step 50422, the electronic device obtains the forward node information of the first P-Code instruction, and determines the forward basic block where the forward node indicated by the forward node information is located.

[0274] The forward node information is used to indicate the forward node. The forward node information may be an identifier of the forward node. The forward node is a jump statement (or jump instruction) for jumping to the current basic block.

[0275] The forward basic block is the basic block where the forward node is located.

[0276] Here, the electronic device can obtain the forward node information of the first P-Code instruction and various information of the forward basic block based on the structural information of the P-Code code recorded in the intermediate file.

[0277] In step 50423, the electronic device obtains the latest value of each input variable from the corresponding forward basic block based on the variable name of the input variable.

[0278] Here, the electronic device may use the variable name of the input variable to search the variable table corresponding to the forward basic block for the latest value of the variable with the same variable name in the forward basic block.

[0279] In step 50424, the electronic device generates an LLVM IR instruction corresponding to the first P-Code instruction based on the latest value of each input variable.

[0280] Here, the electronic device can use the latest values ​​of each input variable in the forward basic block to combine and generate the LLVM IR instruction corresponding to the first P-Code instruction. For example, if the first P-Code instruction is a MULTIEQUAL instruction, then the LLVM IR instruction corresponding to the first P-Code instruction is a phi instruction. In this case, the electronic device can use the values ​​of each input variable and the identifier of the forward basic block to combine and generate the phi instruction.

[0281] Optionally, the electronic device may delete the first P-Code instruction before step 50424, and write the generated LLVM IR instruction at the original location of the first P-Code instruction during the execution of step 50424.

[0282] It should be noted that, through the above step 5042, the P-Code instructions of various operation types described in the intermediate file can be converted into corresponding LLVM IR instructions, which can ensure that each P-Code instruction involved in the function is converted into an LLVM IR instruction, that is, the instructions involved in the function can be fully and accurately converted. This helps to fully and accurately extract the characteristic information of the function, thereby improving the accuracy of function name recovery.

[0283] The following combination Figure 14 and Figure 15 The difference between the LLVM IR file obtained by the conversion in step 5042 and the P-Code obtained in step 501 directly converted into the LLVM IR file is described. Figure 14 A diagram for directly converting P-Code code into LLVM IR file. Figure 15 This is a diagram of converting the intermediate file to the LLVM IR file. It should be noted that Figure 14 The source code corresponding to the LLVM IR file shown in Figure 15 The LLVM IR files shown in the source code are identical.

[0284] It should be noted that in the embodiment of the present application, bold font is used to show the jump relationship between basic blocks in a function. It is understandable that the embodiment of the present application does not specifically limit how to show the jump relationship between basic blocks in a function.

[0285] In LLVM IR files, the "br" instruction can be used to indicate a jump. For example, br label %"00100712" indicates a jump to basic block 00100712, where 00100712 is the basic block identifier. In this application, the basic block identifier can be the entry address of the basic block. preds indicates a forward basic block. For example, preds=%16 indicates that the forward basic block is the basic block identified by 16. @+character indicates a global variable or function. For example, @rand() indicates a function, and @EAX indicates a global variable. %+number indicates a local variable or basic block. For example, %6 can indicate a local variable.

[0286] Because LLVM IR files are in SSA form, each variable is assigned a value only once. In LLVM IR files, numbers can be used to represent variables or basic blocks, and the numbers used to represent local variables or basic blocks are unique. In other words, after using the number 1 to represent a local variable, the number 1 will not be used again to represent other local variables or basic blocks.

[0287] Figure 14 There are 12 basic blocks in the function, namely basic block 0 (that is, the basic block marked as 0), basic block 9, basic block 11, basic block 12, basic block 14, basic block 15, basic block 16, basic block 21, basic block 22, basic block 23, basic block 24, and basic block 25. The other "%+number" represents local variables in the function. For example, %8 is a local variable. It should be pointed out that considering the length of the LLVM IR file, Figure 14 A dotted line is used to separate the first and second half of the file. Specifically, the first half is on the left side of the dotted line, and the second half is on the right side of the dotted line.

[0288] Figure 15 There are 7 basic blocks, namely basic block 001006c3, basic block 00100701, basic block 00100707, basic block 00100730, basic block 0010070d, basic block 00100712 and basic block 00100729.

[0289] Combine Figure 14 and Figure 15 It can be found that Figure 14 The P-Code code is directly converted into an LLVM IR file. In the resulting LLVM IR file, the jump relationship between the basic blocks is relatively confusing, making it difficult to describe the structural characteristics of the function. Figure 15 The LLVM IR file converted from the intermediate file has a clear and concise structure and can clearly reflect the structural and semantic features of the function. That is to say, the function name recovery method provided in the embodiment of the present application can extract a clear and concise LLVM IR file for the target binary file, and the LLVM IR file can clearly reflect the structural and semantic features of the function. That is to say, the function name recovery method provided in the embodiment of the present application can accurately extract the feature information of the function.

[0290] In step 505 , the electronic device generates a control flow graph corresponding to the LLVM IR file based on the LLVM IR file.

[0291] A control flow graph is an abstract representation of a program, representing all the paths traversed during program execution. It graphically illustrates the possible execution flows of all basic blocks within a program and reflects the real-time execution of the program. A control flow graph consists of nodes and edges. Nodes represent basic blocks, while edges represent control flow paths—that is, the paths from one basic block to another.

[0292] Here, the electronic device can adopt the solution disclosed in the relevant technology to convert the LLVM IR file into a control flow graph, which will not be described in detail here.

[0293] It's important to note that generating a control flow graph directly from an intermediate file may be compiler- or language-dependent. LLVM IR, a hardware-independent intermediate representation, converts P-Code from a high-level language into a more standardized low-level representation, resulting in a unified, platform- and language-independent representation that facilitates analysis and optimization. Furthermore, converting the intermediate file to an LLVM IR file first leverages LLVM's powerful capabilities for cross-platform optimization and analysis, simplifying the control flow graph generation process and making analysis and optimization more efficient and versatile.

[0294] See also Figure 16 , Figure 16 This is a schematic diagram of a control flow graph provided in an embodiment of the present application. Figure 16 The control flow graph shown, with Figure 4 The LLVM IR file shown corresponds to this.

[0295] like Figure 16 As shown, the control flow graph can clearly describe the jump relationship within the function, that is, it can clearly describe the structural characteristics of the function.

[0296] Step 506: The electronic device encodes the control flow graph to obtain a graph vector corresponding to the control flow graph.

[0297] The graph vector is the vector corresponding to the control flow graph. The graph vector can represent the characteristic information related to the control flow of the function.

[0298] Here, the electronic device can encode the control flow graph using methods disclosed in related art to obtain a graph vector. As an example, the electronic device can input the control flow graph into a graph encoding model to obtain a graph vector corresponding to the control flow graph. The graph encoding model is a model for converting a graph into a vector. The graph encoding model can be a graph-to-vector model (Graph2vec) or other models. It is understood that the embodiments of this application do not specifically limit the graph encoding model.

[0299] It should be pointed out that since the control flow graph clearly describes the structural characteristics of each function in the program, the graph vector also clearly describes the structural characteristics of each function in the program.

[0300] Optionally, in step 505, the electronic device may also employ a solution disclosed in related art to generate one or more of a function call graph, a data flow graph, and a program dependency graph corresponding to the LLVM IR file. In this case, the graph vector generated in step 506 may include a graph vector corresponding to the control flow graph and one or more of the following: a graph vector corresponding to the function call graph, a graph vector corresponding to the data flow graph, and a graph vector corresponding to the program dependency graph.

[0301] In step 507 , the electronic device inputs the graph vector into a pre-trained function name generation model to generate function names corresponding to each function.

[0302] The function name generation model is a pre-trained model for generating function names. The function name generation model is used to describe the relationship between graph vectors and function names, where graph vectors can describe function features.

[0303] As an example, the function name generation model can be a model obtained by training an initial model (such as a convolutional neural network (CNN) or a residual network (ResNet)) using machine learning methods based on training samples. It is understood that the embodiments of this application do not specifically limit the initial model.

[0304] The following describes the process of training the function name generation model: (1) Training method 1 First, multiple functions for training are obtained, the control flow graph corresponding to each function is converted into a graph vector, and the function name is converted into a function name vector. The function name vector is the vector corresponding to the function name.

[0305] Here, the control flow graph of the function can be converted into a graph vector in the manner of step 506, which will not be described in detail here.

[0306] The electronic device may convert the function name into a vector by using a method disclosed in the related art. For example, the function name may be converted into a vector by using a one-hot encoding method.

[0307] Then, the graph vector and function name vector corresponding to the same function are used as positive samples, and the graph vector and function name vector corresponding to different functions are used as negative samples, thereby obtaining a training sample set for training the initial function name generation model.

[0308] The training sample set includes positive samples and negative samples.

[0309] Finally, the training sample set is used to train the initial function name generation model to obtain the trained function name generation model.

[0310] Training method 1 can train a function name prediction model more accurately. However, training method 1 is more dependent on the quantity and quality of training samples and cannot accurately predict function names for a large range of function inputs.

[0311] (2) Training method 2 First, load a pre-trained model, where a pre-trained model is typically a large deep learning model trained on a large dataset. In some embodiments, the pre-trained model can be a generative model. It should be noted that since generative models can process various complex data types, such as text, images, audio, etc., and can learn the potential representation of data and adapt to different tasks, generative models usually have strong generalization capabilities and can perform well even in scenarios outside of the training data. Therefore, when the pre-trained model is a generative model, the accuracy of the generated function names can be further guaranteed.

[0312] Then, refer to training method 1 to prepare a training sample set.

[0313] Finally, the pre-trained model is fine-tuned using the training sample set.

[0314] During the training process, the pre-trained model can learn how to predict the corresponding function name based on the input graph vector (represented in text form), and finally fine-tune the function name generation model suitable for the current scenario.

[0315] The function name generation model obtained by training in training method 2 does not need to be trained with a large amount of training samples because the pre-trained model itself is a large deep learning model trained on a large data set.

[0316] It can be understood that the above-mentioned training method 1 and training method 2 are merely examples of training the function name generation model, and are not specific limitations on how to train the function name generation model.

[0317] It is understandable that when the input of the function name generation model is the graph vector of multiple functions, the output can be the function name for each function. In other words, the function name generation model can generate the function name of one function or the function names of multiple functions.

[0318] Optionally, if the electronic device uses training method 2 to train the pre-trained model to obtain a function name generation model, when using the function name generation model, the electronic device can also combine the candidate function name list obtained by the function name generation model during the function name generation process with the Large Language Model (LLM) to optimize the final function name. It should be noted that the function name generation model can combine the characteristics of the function described by the graph vector to output a candidate function name list (referred to as the candidate function name list), or it can directly output a single function name for the function.

[0319] For example, if the function name generation model outputs candidate function name list 1 for binary file 1, the electronic device can combine the LLVM IR file corresponding to binary file 1, the graph vector of the control flow graph corresponding to the LLVM IR file, and function name list 1 to generate a prompt and send the prompt to the LLM model. The LLM model can adjust function name list 1 and return the adjusted function names of each function to the electronic device. For example, the prompt sent by the electronic device to the LLM model can be: "What is the most likely function name? The candidate function names are: function name 1, function name 2, etc.; the graph vector of the control flow graph is...; the LLVM IR file is...". The response returned by the LLM model to the prompt can be: "I believe the most likely function name is function name 1." It will be understood that the above-mentioned prompt and response are merely examples, and the present embodiments do not specifically limit the content of the prompt and response.

[0320] It should be pointed out that since the LLM model is a natural language processing model based on deep learning, it can learn and understand the grammar and semantics of natural language. Therefore, using the LLM model to optimize the function names output by the function name generation model can help further improve the accuracy of function name recovery.

[0321] The following further combines Figure 17 The process of training the function name generation model in the above training method 2 is described. Figure 17 A schematic diagram of the process of training a function name generation model provided in an embodiment of the present application.

[0322] like Figure 17 As shown, the process of training the function name generation model can be: First, the electronic device can input the control flow graph corresponding to the binary file into the graph encoding model (Graph2vec), and the graph encoding model converts the control flow graph into a function representation. The operation of obtaining the control flow graph corresponding to the binary file can be seen in Figure 5 Steps 501 to 505 are not described here in detail. The above function is represented as a graph vector corresponding to the control flow graph, and the function representation can characterize the characteristics of the function.

[0323] Then, the electronic device can generate positive sample pairs (abbreviated as positive samples) and negative sample pairs (abbreviated as negative samples) based on the function representation. Specifically, the function representation (graph vector) and function name representation (function name vector) corresponding to the same function can be used as positive samples, and the function representation and function name representation corresponding to different functions can be used as negative samples. Figure 17 The positive sample pair consists of two parts: the left part is the function representation corresponding to the function, and the right part is the function name representation of the function. That is, the function representation and the function name representation come from the same function. The negative sample pair also consists of two parts: the left part is the function representation corresponding to the function, and the right part is the function name representation of other functions. That is, the function representation and the function name representation come from different functions.

[0324] Figure 17 In the example, for any sample pair, the presence or absence of padding can be used to distinguish whether the function representation and the function name representation come from the same function, or to distinguish whether the sample is a positive sample or a negative sample. Specifically, if the function representation and the function name representation come from the same function, then both the elements (circles) on the left and right sides of the sample are filled. In this case, the sample is a positive sample. If the function representation and the function name representation come from different functions, then one of the elements (circles) on the left and right sides of the sample is filled. In this case, the sample is a negative sample. It is understandable that positive samples and negative samples can also be distinguished by other methods, and the embodiments of the present application are not limited to this.

[0325] Combine Figure 17 It can be found that the function names in the positive samples (specifically, they can be represented by function names) come from the function name corpus, while the function names in the negative samples (specifically, they can be represented by function names) do not come from the function name corpus. In this case, the trained function name generation model can be made more robust.

[0326] The electronic device can then use the resulting positive and negative samples to fine-tune the generative model, or train the generative model. The generative model is the initial function name generation model, and the generative model is also known as a pre-trained model. It should be noted that pre-trained models are typically large deep learning models trained on large datasets.

[0327] Finally, after fine-tuning the generative model, the trained model (also known as the function name generation model) can be configured to take function representations (graph vectors) as input and output a list of candidate function names. Optionally, the output of the function name generation model can also be the function name.

[0328] The following further combines Figure 18 , explains how to optimize the candidate function name list based on the large language model to obtain the accurate function name when the output of the function name generation model is a candidate function name list. Figure 18 A schematic diagram of the process of optimizing function names provided in an embodiment of the present application.

[0329] like Figure 18 As shown, the process of optimizing the function name can be: First, the electronic device sends the LLVM IR file, the graph vector of the control flow graph corresponding to the LLVM IR file, and the candidate function name list to the server.

[0330] The server then generates a question statement and sends the content of the statement to the large language model.

[0331] The question may include: What is the most likely function name? Candidate function names include: Function Name 1, Function Name 2, etc. Other information includes: graph vectors, LLVM IR files. It should be understood that the present embodiment does not limit the specific content of the question.

[0332] Afterwards, the large language model determines the most likely function name based on the question sentence and sends the reply sentence containing the most likely function name to the server.

[0333] As an example, the reply statement may be: "I think the most likely function name is function name 1." It is understandable that the embodiment of the present application does not specifically limit the content of the reply statement.

[0334] It can be understood that when there is one function in the pseudocode, the server can obtain the function name of the one function, and when there are multiple functions in the pseudocode, the server can obtain the function name of each function.

[0335] Finally, the server sends the function name of each function in the pseudo code to the electronic device.

[0336] Understandably, Figure 18 In the embodiment, the server and the electronic device can be two independent devices or the same device. For example, when the function of the server is realized by the electronic device, the server and the electronic device can be the same device.

[0337] Figure 19 This is a flow chart of a method for restoring a function name provided in an embodiment of the present application. Figure 19 , this method can be applied to electronic devices.

[0338] like Figure 19 As shown, the function name recovery method may include the following steps 1601 to 1606. It is understood that the above function name recovery method may include all steps 1601 to 1606, or may include only some of them. It is understood that the steps in the function name recovery method may be arbitrarily combined if they do not conflict.

[0339] Step 1601: The electronic device obtains a target binary file.

[0340] Here, the electronic device may obtain the target binary file locally or from other electronic devices.

[0341] Optionally, the target binary file is a binary file from which symbol information has been removed. In this application, a binary file refers to a file that carries the machine code of a program. Binary file formats may include object file formats (.o files), shared object file formats (.so files), executable file formats (.exe files), and so on. It will be appreciated that the embodiments of this application do not specifically limit the file format of the target binary file.

[0342] Step 1602: The electronic device generates a target pseudo code corresponding to the target binary file.

[0343] The target pseudocode is the pseudocode corresponding to the target binary file (also called P-Code).

[0344] P-Code is a collection of P-Code instructions, referred to as P-Code instruction set.

[0345] Here, the operation of step 1602 can be seen in Figure 5 The embodiment section corresponding to step 501 in FIG.

[0346] It should be noted that the target pseudo code may include one function or multiple functions. In the case where the target pseudo code includes multiple functions, the electronic device may extract the structural information of each function and generate a function name of the function based on the structural information of each function.

[0347] In some optional implementations of the embodiments of the present application, in step 1602, the electronic device generates a target pseudocode corresponding to the target binary file, which may include: the electronic device generates a high-level pseudocode corresponding to the target binary file, and the target pseudocode is a high-level pseudocode.

[0348] In the embodiment of the present application, since the high-level pseudocode (or High P-Code) focuses more on the source code itself and does not pay attention to the underlying architecture, and the low-level pseudocode (or Low-P-Code) contains a large amount of information related to the underlying architecture, and this information related to the underlying architecture has nothing to do with the function itself, therefore, using high-level pseudocode for function name recovery can avoid excessive irrelevant interference information, help reduce the amount of data processing, and improve the efficiency of function name recovery.

[0349] Step 1603: The electronic device extracts structural information of the target function from the target pseudo code.

[0350] The structural information is used to describe the function, the basic blocks in the function, and the variables in the function. The target function is any function in the target pseudocode. The structural information of the target function can include function information, basic block information in the target function, and variable information in the target function.

[0351] Here, the operation of step 1603 can be seen in Figure 5 The embodiment section corresponding to step 502 in FIG.

[0352] In some optional implementations of the embodiments of the present application, in step 1603, the electronic device extracts structural information of the target function from the target pseudocode, which may include: First, the electronic device traverses the target pseudo code, and when accessing the first operation instruction, extracts function information of the target function from the first operation instruction.

[0353] The first operation instruction is an instruction in the target pseudocode that defines the target function, and the function information includes the first entry address of the function. The first entry address may also be called the entry address of the function or the first address of the function.

[0354] Here, the operation of electronic device to extract function information can be referred to Figure 6 The embodiment section corresponding to step 601 in FIG.

[0355] Then, the electronic device determines M basic blocks and basic block information of each basic block from the target function according to each instruction in the target function.

[0356] The basic block information includes the basic block's second entry address, the basic block's forward node, and the basic block's backward node, where M is an integer greater than 0. The second entry address can also be referred to as the basic block's entry address or the basic block's first address. It should be noted that for any basic block, the basic block's forward node is the pseudo-code instruction (P-Code instruction) that jumps to the basic block, and the basic block's backward node is the P-Code instruction to which the basic block needs to jump.

[0357] Here, the operation of the electronic device to extract the basic block information of the basic block in the function can be seen in Figure 6 The embodiment section corresponding to step 602 in FIG.

[0358] Afterwards, the electronic device traverses the first basic block and extracts variable information from the first instruction in the first basic block.

[0359] The first basic block is any basic block among the M basic blocks, and the first instruction is any instruction in the first basic block.

[0360] Here, the operation of the electronic device to extract the variable information of the variable in the function can be seen in Figure 6 The embodiment section corresponding to step 603 in FIG.

[0361] Finally, the electronic device generates an intermediate file.

[0362] The intermediate file is used to record the function information, basic block information, and variable information of the target function. The first entry address and the second entry address in the intermediate file correspond to the first pseudo code. It is understandable that the target pseudo code may include one function or multiple functions. When the target pseudo code includes multiple functions, the intermediate file generated by the electronic device may record the function information of each function, the basic block information in the function, and the variable information in the function.

[0363] Here, the contents of the intermediate file can be found Figure 8 and Figure 9 The structure of the intermediate file can be found in Figure 10 and Figure 11 For the operation of generating intermediate files by electronic devices, please refer to Figure 5 The embodiment section corresponding to step 503 in FIG.

[0364] In the embodiment of the present application, since the pseudocode has a specific syntax, the electronic device can extract function information, basic block information in the function, and variable information in the function from the target code in combination with the syntax of the pseudocode. It should be pointed out that since the pseudocode is essentially an unordered code, extracting the structural information of each function from the pseudocode can achieve orderly classification of the unordered pseudocode. In addition, classifying and dividing the pseudocode layer by layer according to multiple levels such as functions, basic blocks in functions, instructions in basic blocks, variables, etc., helps to accurately extract the semantic structure of each function, thereby ensuring the accuracy of function name recovery.

[0365] Optionally, the variable information includes one or more of the following: the variable name, the variable storage type, and the variable size. The variable storage type may indicate the variable's storage location. For example, a register type indicates that the variable is stored in a register, a memory type indicates that the variable is stored in memory, and a stack type indicates that the variable is stored in a stack.

[0366] Optionally, the language format of the three-address code is Low-Level Virtual Machine Intermediate Representation LLVM IR.

[0367] It should be pointed out that since LLVM IR is an intermediate representation that is independent of the specific hardware platform, it converts the P-Code code from a high-level language into a more standardized low-level representation, which can obtain a unified representation that is independent of the platform and language, making it easier to analyze and optimize. By first converting the intermediate file into an LLVM IR file, you can use the powerful functions of LLVM to perform cross-platform optimization and analysis, and simplify the control flow graph generation process, making analysis and optimization more efficient and universal.

[0368] Step 1604: The electronic device converts the first pseudo code in the target pseudo code into a three-address code based on the structural information of the target function.

[0369] The first pseudocode is related to the target function, that is, the first pseudocode is the part of the target pseudocode that is related to the target function.

[0370] Here, the operation of step 1604 can be seen in Figure 5 The embodiment section corresponding to step 504 in FIG.

[0371] In some optional implementations of the embodiments of the present application, the above-mentioned step 1604 may include the following steps 1 and 2.

[0372] In step 1, the electronic device generates an initial variable table corresponding to the target function. The variable table is used to record the value changes of each variable in the target function during the program execution. It should be noted that for any function, a corresponding variable table can be used to record the value changes of the variables in the function during the program execution. The variables recorded in the variable table can include global variables, local variables, temporary variables, etc. Optionally, the initial variable table corresponding to the function can be an empty table by default.

[0373] Step 2: The electronic device traverses the first pseudo code based on the intermediate file, and for the second instruction in the first pseudo code (see Figure 12 The first P-Code instruction in step 5042) converts the second instruction into an LLVM IR instruction according to the operation type and / or variable table corresponding to the second instruction.

[0374] Among them, the second instruction is any instruction in the first pseudocode, and the operation types include: first operation type, second operation type, third operation type, and fourth operation type. The first operation type is used to obtain input variables, the second operation type is used to update output variables, the third operation type is used to merge multiple branches, and the fourth operation type is an operation type other than the first operation type, the second operation type, and the third operation type.

[0375] Here, the operations of step one and step two can be found in Figure 12 The corresponding examples section.

[0376] In the embodiments of the present application, the pseudocode instructions for various operation types described in the intermediate file are converted into corresponding LLVM IR instructions. This ensures that every pseudocode instruction involved in a function is converted into LLVM IR instructions. This means that all instructions involved in the function are fully and accurately converted. This facilitates the comprehensive and accurate extraction of the function's feature information, thereby improving the accuracy of function name recovery. Furthermore, since different types of variables have different storage locations, uses, scopes, and lifecycles, and the values ​​of variables in each function change as the program runs, the present application uses a function variable table to describe the real-time changes of each variable in the function, thereby ensuring the accuracy of the generated LLVM IR instructions. For example, if a variable is not recorded in the variable table during an update, this indicates a problem with the variable's usage. Therefore, the accuracy of the generated LLVM IR instructions can be guaranteed based on the real-time updated variable table.

[0377] In some optional implementations, step 2 may include: if the operation type of the second instruction is the first operation type (or referred to as obtaining the type of the input variable), obtaining the storage type of the input variable from the second instruction; and generating an LLVM IR instruction corresponding to the second instruction based on the storage type of the input variable and the variable table. Storage types include register types (or referred to as register types), memory types (or referred to as memory types), and stack types (or referred to as stack types).

[0378] In this case, if the input variable's storage type is a register type, the LLVM IR instruction is used to load the value into the input variable. If the input variable's storage type is a memory type, the LLVM IR instruction is used to retrieve the value of the input variable. If the input variable's storage type is a stack type, the LLVM IR instruction is used to retrieve the value of the input variable from the variable table.

[0379] Here, when the operation type of the second instruction is the first operation type, the process of the electronic device converting the second instruction into an LLVMIR instruction can be referred to the embodiment section corresponding to "Case 2" in the specification.

[0380] In an embodiment of the present application, during the instruction conversion process, the second instruction is converted into an LLVM IR instruction in a targeted manner based on the storage type of the input variable, which can improve the accuracy of the instruction conversion and further improve the efficiency of function name recovery.

[0381] Optionally, after the electronic device generates the LLVM IR instruction corresponding to the second instruction based on the storage type and variable table of the input variable, it can also add the first variable information of the input variable to the variable table, where the first variable information includes the variable name of the input variable, the address of the input variable, and the value of the input variable.

[0382] In the embodiment of the present application, when the electronic device obtains an input variable, it promptly adds the variable information of the input variable to the variable table, so that the real-time changes of each variable are always recorded in the variable table.

[0383] Optionally, when an input variable is a register type, during the process of generating an LLVM IR instruction, if the electronic device detects that the input variable does not exist in the current variable table, a first prompt message may be generated, where the first prompt message is used to indicate that the input variable is undefined or that there is a syntax error in the use of the input variable. In other words, in this application, the variable table can be used to check whether the source code has syntax errors.

[0384] In some optional implementations, step 2 may include: if the operation type of the second instruction is the second operation type (or the type of updating the output variable), obtaining the storage type of the output variable from the second instruction; and generating an LLVM IR instruction corresponding to the second instruction based on the storage type of the output variable.

[0385] In this case, if the storage type of the output variable is a register type, the LLVM IR instruction includes a first LLVM IR instruction and a second LLVM IR instruction. The first LLVM IR instruction is used to convert the data type of the output variable to the first data type, and the second LLVM IR instruction is used to store the output variable of the first data type, where the first data type is the data type corresponding to the output variable. If the storage type of the output variable is a memory type or a stack type, the LLVM IR instruction is the instruction for storing the output variable.

[0386] Here, when the operation type of the second instruction is the second operation type, the process of the electronic device converting the second instruction into an LLVMIR instruction can be referred to the embodiment section corresponding to "Case 3" in the specification.

[0387] In an embodiment of the present application, during the instruction conversion process, the second instruction is converted into an LLVM IR instruction in a targeted manner in combination with the storage type of the output variable, which can improve the accuracy of the instruction conversion and further improve the efficiency of function name recovery.

[0388] Optionally, after the electronic device generates the LLVM IR instruction corresponding to the second instruction according to the storage type of the output variable, it also includes: adding the second variable information of the output variable to the variable table, the second variable information including the variable name of the output variable, the address of the output variable, and the value of the output variable.

[0389] In the embodiment of the present application, the electronic device promptly adds the latest variable information of the output variable to the variable table, so that the real-time changes of each variable are always recorded in the variable table.

[0390] In some optional implementations, the above-mentioned step 2 may include: if the operation type of the second instruction is the third operation type (or called the branch merge type), obtaining N input variables included in the second instruction; determining the forward basic block of the second basic block based on the intermediate file; obtaining the latest value of the first input variable from the first forward basic block; and generating LLVM IR instructions according to the obtained values ​​of each input variable.

[0391] The second basic block is the basic block to which the second instruction belongs, and the forward basic block is the basic block that jumps to the second basic block. N is an integer greater than 1.

[0392] The first forward basic block is a forward basic block including a first input variable, and the first input variable is any input variable in the second instruction.

[0393] Here, when the operation type of the second instruction is the third operation type, the process of the electronic device converting the second instruction into an LLVMIR instruction can be referred to the embodiment corresponding to "Case 4" in the specification.

[0394] In the embodiment of the present application, when the operation type of the second instruction is the third operation type, the electronic device can accurately and effectively convert the second instruction in the pseudocode into an LLVM IR instruction. During the instruction conversion process, the second instruction is converted into an LLVM IR instruction in a targeted manner based on the instruction operation type, which can improve the accuracy of instruction conversion and further improve the efficiency of function name recovery.

[0395] In some optional implementations, step 2 may include: if the operation type corresponding to the second instruction is a fourth operation type (or a regular type), converting the second instruction into an LLVMIR instruction based on a preset first correspondence relationship. The first correspondence relationship is a correspondence relationship between the pseudocode instruction and the LLVMIR instruction.

[0396] Here, when the operation type of the second instruction is the fourth operation type, the process of the electronic device converting the second instruction into an LLVMIR instruction can be referred to the embodiment section corresponding to "Case 1" in the specification.

[0397] In an embodiment of the present application, during the instruction conversion process, the electronic device combines the operation type of the instruction to specifically convert the second instruction into an LLVM IR instruction, which can improve the accuracy of the instruction conversion and further improve the efficiency of function name recovery.

[0398] Step 1605: The electronic device determines first characteristic information related to the control flow of the target function based on the three-address code.

[0399] The first feature information may be implemented as a graph vector.

[0400] Here, the operation of step 1605 can be seen in Figure 5 The embodiment section corresponding to steps 505 and 506 in FIG.

[0401] Step 1606: The electronic device generates a function name of the target function based on the first feature information.

[0402] In some optional implementations of the embodiments of the present application, step 1606 may include: first, the electronic device inputs the first feature information into a first model (or a function name generation model) to obtain multiple candidate function names for the target function. Then, the multiple candidate function names, the first feature information, and the three-address code are input into a second model to obtain the function name of the target function.

[0403] Among them, the first model is a generative model and the second model is a large language model.

[0404] Here, the operation of step 1606 can be seen in Figure 5 The embodiment section corresponding to step 507 in FIG.

[0405] In the embodiment of the present application, since the generative model can process various complex data types, such as text, images, audio, etc., and can learn the potential representation of the data and adapt to different tasks, in addition, the generative model usually has a strong generalization ability and can perform well even in scenarios outside the training data. Therefore, when the first model is a generative model, the accuracy of the multiple candidate function names obtained can be guaranteed. In addition, since the large prediction model is a natural language processing model based on deep learning, it can learn and understand the grammar and semantics of natural language. Therefore, using a large language model to optimize the multiple candidate function names output by the first model helps to further improve the accuracy of function name recovery.

[0406] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0407] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0408] It should also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0409] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0410] In addition, in the description of this application specification and the appended claims, the terms "first," "second," "third," etc. are used only to distinguish and describe, and should not be understood to indicate or imply relative importance. It should also be understood that although the terms "first," "second," etc. are used in the text to describe various elements in some embodiments of the present application, these elements should not be limited by these terms. These terms are simply used to distinguish one element from another.

[0411] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically stated. The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless otherwise specifically stated.

[0412] In addition, those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units in the various embodiments of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0413] The function name recovery method provided in the embodiments of the present application can be applied to electronic devices, which can be terminals or servers. The terminals can be tablet computers, vehicle-mounted devices, augmented reality (AR) / virtual reality (VR) devices, laptop computers, ultra-mobile personal computers (UMPCs), etc. The servers can be network servers, cloud servers, etc. This embodiment of the present application does not limit this.

[0414] In order to better understand the embodiments of the present application, the following takes the electronic device as an example, combined with Figure 20 The structure of the electronic device according to the embodiment of the present application is introduced.

[0415] Figure 20 FIG1 is a schematic diagram of the structure of a server provided in an embodiment of the present application. The server includes at least one processor 111 , a communication bus 112 , a memory 113 and at least one communication interface 114 .

[0416] The processor 111 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0417] The communication bus 112 may include a pathway for transmitting information between the aforementioned components.

[0418] The communication interface 114 uses any transceiver or other device for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0419] The memory 113 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may be independent and connected to the processor via a bus. The memory may also be integrated with the processor.

[0420] The memory 113 is used to store application code for executing the solution of the present application, and the execution is controlled by the processor 111. The processor 111 is used to execute the application code stored in the memory 113, thereby implementing the material matching method in the above embodiment.

[0421] As an embodiment, the processor 111 may include one or more CPUs, such as CPU 0 and CPU 1.

[0422] As an embodiment, the server may include multiple processors, such as Figure 20 The two processors 111 in the system. Each processor can be a single-core (ingle-CPU) processor or a multi-core (multi-CPU) processor.

[0423] As an embodiment, the server may further include an output device 115 and an input device 116. The output device 115 communicates with the processor 111 and can display information in various ways. For example, the output device 115 may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector.

[0424] The input device 116 communicates with the processor 111 and can accept user input in various ways. For example, the input device 116 can be a mouse, keyboard, touch screen, or sensor device.

[0425] It is understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the server. In other embodiments of the present application, the server may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The components shown in the diagram may be implemented in hardware, software, or a combination of software and hardware.

[0426] In addition, those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units in the various embodiments of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0427] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0428] An embodiment of the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device can implement the steps of the above-mentioned method embodiments when executing the computer program product.

[0429] An embodiment of the present application also provides a chip system, which includes a processor coupled to a memory. The processor executes a computer program stored in the memory to implement the steps in the above-mentioned method embodiments.

[0430] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. Computer-readable storage media may include: any entity or device that can carry computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc.

[0431] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0432] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0433] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0434] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.< / labeln> < / valuen> < / label2> < / value2> < / label1> < / value1> < / type> < / inputn> < / input2> < / input1> < / output>

Claims

1. A method for restoring a function name, characterized in that: The method comprises: Get the target binary file; Generate a target pseudo code corresponding to the target binary file; Extracting structural information of a target function from the target pseudocode, wherein the structural information is used to describe a function, a basic block in a function, and a variable in a function, wherein the target function is any function in the target pseudocode; Based on the structural information of the target function, converting a first pseudo code in the target pseudo code into a three-address code, wherein the first pseudo code is related to the target function; Based on the three address codes, determining first characteristic information related to a control flow of the target function; Based on the first feature information, a function name of the target function is generated.

2. The method for restoring a function name according to claim 1, characterized in that: The step of extracting structural information of the target function from the target pseudocode comprises: Traversing the target pseudo code, when accessing a first operation instruction, extracting function information of the target function from the first operation instruction, wherein the first operation instruction is an instruction for defining the target function, and the function information includes a first entry address of the function; According to each instruction in the target function, determine M basic blocks and basic block information of each basic block from the target function, wherein the basic block information includes a second entry address of the basic block, a forward node of the basic block, and a backward node of the basic block, wherein M is an integer greater than 0; Traversing a first basic block, extracting variable information from a first instruction in the first basic block, wherein the first basic block is any basic block among the M basic blocks, and the first instruction is any instruction in the first basic block; Generate an intermediate file, wherein the intermediate file is used to record the function information, the basic block information and the variable information of the target function, the first entry address and the second entry address in the intermediate file correspond to the first pseudo code, and the structure information includes the function information, the basic block information and the variable information.

3. The method for restoring function names according to claim 2, characterized in that: The variable information includes one or more of the following: the name of the variable, the storage type of the variable, and the size of the variable.

4. The function name recovery method according to claim 2, characterized in that: The language format of the three-address code is a low-level virtual machine intermediate representation LLVM IR; the first pseudo code in the target pseudo code is converted into the three-address code based on the structure information of the target function, including: Generate an initial variable table corresponding to the objective function, wherein the variable table is used to record the value changes of each variable in the objective function during the program running process; Based on the intermediate file, traverse the first pseudo code, and for a second instruction in the first pseudo code, convert the second instruction into an LLVM IR instruction according to an operation type corresponding to the second instruction and / or the variable table; Among them, the second instruction is any instruction in the first pseudocode, and the operation types include: a first operation type, a second operation type, a third operation type, and a fourth operation type. The first operation type is used to obtain input variables, the second operation type is used to update output variables, the third operation type is used to merge multiple branches, and the fourth operation type is an operation type other than the first operation type, the second operation type, and the third operation type.

5. The function name recovery method according to claim 4, characterized in that: The converting the second instruction into an LLVM IR instruction according to the operation type and / or the variable table corresponding to the second instruction includes: If the operation type of the second instruction is the first operation type, obtaining a storage type of the input variable from the second instruction, the storage type including a register type, a memory type, and a stack type; The LLVM IR instruction corresponding to the second instruction is generated according to the storage type of the input variable and the variable table, wherein if the storage type of the input variable is a register type, the LLVM IR instruction is an instruction for loading a value into the input variable; if the storage type of the input variable is a memory type, the LLVM IR instruction is an instruction for obtaining the value of the input variable; if the storage type of the input variable is a stack type, the LLVM IR instruction is an instruction for instructing to obtain the value of the input variable from the variable table.

6. The function name recovery method according to claim 5, characterized in that: After generating the LLVM IR instruction corresponding to the second instruction according to the storage type of the input variable and the variable table, the method further includes: The first variable information of the input variable is added to the variable table, wherein the first variable information includes the variable name of the input variable, the address of the input variable, and the value of the input variable.

7. The function name recovery method according to claim 4, characterized in that: The converting the second instruction into an LLVM IR instruction according to the operation type and / or the variable table corresponding to the second instruction includes: If the operation type of the second instruction is the second operation type, obtaining the storage type of the output variable from the second instruction; According to the storage type of the output variable, the LLVM IR instruction corresponding to the second instruction is generated, wherein if the storage type of the output variable is a register type, the LLVM IR instruction includes a first LLVM IR instruction and a second LLVM IR instruction, the first LLVM IR instruction is used to convert the data type of the output variable into a first data type, and the second LLVM IR instruction is used to store the output variable of the first data type, and the first data type is the data type corresponding to the output variable; if the storage type of the output variable is a memory type or a stack type, the LLVM IR instruction is an instruction for storing the output variable.

8. The function name recovery method according to claim 7, characterized in that: After generating the LLVM IR instruction corresponding to the second instruction according to the storage type of the output variable, the method further includes: The second variable information of the output variable is added to the variable table, wherein the second variable information includes the variable name of the output variable, the address of the output variable, and the value of the output variable.

9. The function name recovery method according to claim 4, characterized in that: The converting the second instruction into an LLVM IR instruction according to the operation type and / or the variable table corresponding to the second instruction includes: If the operation type of the second instruction is the third operation type, obtaining N input variables included in the second instruction, where N is an integer greater than 1; Determine, based on the intermediate file, a forward basic block of a second basic block, the second basic block being a basic block to which the second instruction belongs, and the forward basic block being a basic block that jumps to the second basic block; Obtaining a latest value of a first input variable from a first forward basic block, wherein the first forward basic block is a forward basic block including the first input variable, and the first input variable is any input variable in the second instruction; Generate the LLVM IR instruction according to the acquired values ​​of each input variable.

10. The method for restoring function names according to claim 4, characterized in that: The converting the second instruction into an LLVM IR instruction according to the operation type and / or the variable table corresponding to the second instruction includes: If the operation type corresponding to the second instruction is the fourth operation type, the second instruction is converted into the LLVM IR instruction based on a preset first corresponding relationship, wherein the first corresponding relationship is a corresponding relationship between the instruction of the pseudocode and the LLVM IR instruction.

11. The method for restoring a function name according to claim 1, characterized in that: The generating, based on the first feature information, a function name of the objective function includes: Inputting the first feature information into a first model to obtain a plurality of candidate function names of the objective function; The multiple candidate function names, the first feature information and the three-address code are input into a second model to obtain a function name of the target function, wherein the first model is a generative model and the second model is a large language model.

12. The method for restoring a function name according to any one of claims 1 to 11, characterized in that: The generating of the target pseudo code corresponding to the target binary file comprises: A high-level pseudo code corresponding to the target binary file is generated, the target pseudo code being the high-level pseudo code.

13. An electronic device, characterized in that: The electronic device includes a memory and a processor. The memory stores a computer program that can be run on the processor. When the processor executes the computer program, the function name recovery method according to any one of claims 1 to 12 is implemented.

14. A chip system, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that: The processor is used to execute the computer program to implement the function name recovery method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed on an electronic device, the electronic device executes the function name recovery method according to any one of claims 1 to 12.

Images