Binary code translation method, electronic device, storage medium and software product

Abstract

This application provides a binary code translation method, comprising: disassembling first binary code based on a first instruction set architecture to obtain disassembled code; recovering symbols in the disassembled code to obtain first assembly code based on the first instruction set architecture; decomposing the first assembly code into multiple assembly code segments; translating each of the multiple assembly code segments to obtain an assembly code segment based on a second instruction set architecture; concatenating the translated assembly code segments based on the second instruction set architecture to obtain second assembly code based on the second instruction set architecture; and assembling the second assembly code to obtain second binary code based on the second instruction set architecture, wherein the first instruction set architecture is different from the second instruction set architecture. This application also provides an electronic device, a computer-readable storage medium, and a computer program product.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a binary code translation method, an electronic device, a computer-readable storage medium, and a computer software product. Background Technology

[0002] Competition among central processing units (CPUs) with different architectures in the personal computer market is becoming increasingly fierce. Most software development in the past has focused on the traditional x86-64 instruction set architecture (ISA), and new hardware architectures lack a mature software ecosystem to support them, making it difficult to promote them among a wide range of users.

[0003] Cross-architecture emulators can run software on different architectures, but they incur significant runtime overhead, making it difficult to meet the efficiency requirements of software porting to new hardware architectures. To address this, Dynamic Binary Translators have been proposed to help processor manufacturers migrate binary code from legacy architectures to new architectures, thereby enhancing software support on new architectures.

[0004] However, due to the complexity of binary code, some translation processes are difficult to complete without analyzing the runtime state of the binary program. Therefore, current translation tools often choose a dynamic translation paradigm, translating the binary code at runtime. However, this again introduces runtime overhead issues, as well as problems with portability and scalability. Summary of the Invention

[0005] Embodiments of this application provide a binary code translation method, an electronic device, a computer-readable storage medium, and a computer software product, which at least solve the problem of runtime overhead during binary code translation.

[0006] Embodiments of this application provide a binary code translation method, comprising: disassembling first binary code based on a first instruction set architecture to obtain disassembled code; recovering symbols in the disassembled code to obtain first assembly code based on the first instruction set architecture; decomposing the first assembly code into multiple assembly code segments; translating each of the multiple assembly code segments to obtain an assembly code segment based on a second instruction set architecture; concatenating the translated assembly code segments based on the second instruction set architecture to obtain second assembly code based on the second instruction set architecture; and assembling the second assembly code to obtain second binary code based on the second instruction set architecture, wherein the first instruction set architecture is different from the second instruction set architecture.

[0007] According to an embodiment of this application, decomposing the first assembly code into multiple assembly code segments includes: performing data flow analysis on the first assembly code to identify the definition and usage of each operand in the first assembly code; and based on the identification results, decomposing the first assembly code into multiple assembly code segments with a static single assignment format.

[0008] According to an embodiment of this application, linking the translated assembly code segments based on the second instruction set architecture to obtain second assembly code based on the second instruction set architecture includes: for each of the plurality of assembly code segments, identifying the mapping relationship of operands between the assembly code segment before translation and the assembly code segment after translation; modifying the translated assembly code segments based on the second instruction set architecture to ensure the consistency of the operands; and linking the modified assembly code segments based on the second instruction set architecture to obtain the second assembly code.

[0009] According to embodiments of this application, translating each of the plurality of assembly code fragments to obtain an assembly code fragment based on a second instruction set architecture includes: querying a large language model to translate the assembly code fragment from the first instruction set architecture to the second instruction set architecture; checking the validity of the translated assembly code fragment based on the second instruction set architecture; if the validity check fails, determining a translation error and feeding back the error information to the large language model for retranslation; if the validity check passes, determining that the translation is correct, parameterizing the translated operands to create translation rules, and feeding back the translation rules to the large language model.

[0010] According to embodiments of this application, checking the validity of the translated assembly code segment based on the second instruction set architecture includes: performing symbolic execution on the assembly code segment with a static single assignment format that does not contain program branches to obtain a symbolic representation of the program state; checking whether the symbolic representation of the assembly code segment before translation and the symbolic representation of the translated assembly code segment are equivalent; determining that the validity check passes in response to the fact that the symbolic representation of the assembly code segment before translation and the symbolic representation of the translated assembly code segment are equivalent; and determining that the validity check fails in response to the fact that the symbolic representation of the assembly code segment before translation and the symbolic representation of the translated assembly code segment are not equivalent.

[0011] According to embodiments of this application, the operands include immediate values, registers, and tags.

[0012] According to an embodiment of this application, the first instruction set architecture includes the x86-64 instruction set architecture, and the second instruction set architecture includes the AArch64 instruction set architecture.

[0013] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to implement a binary code translation method according to embodiments of this application.

[0014] Embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the processor implements a binary code translation method according to embodiments of this application.

[0015] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, causes the processor to implement a binary code translation method according to embodiments of this application.

[0016] According to the binary code translation method of this application, before deployment, by converting binary code into portable native code that can be directly executed on the target hardware, runtime overhead can be significantly reduced. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain the application and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art through the description of detailed exemplary embodiments with reference to the accompanying drawings, in which: Figure 1 A flowchart of a binary code translation method according to an embodiment of this application is shown; Figure 2 An example of a symbolization process according to an embodiment of this application is shown; Figure 3 An example of a process for decomposing a first assembly code into multiple assembly code fragments according to an embodiment of this application is shown; Figure 4 An example of pseudocode for performing assembly code segmentation according to an embodiment of this application is shown; Figure 5 An example of translating x86-64 instruction set architecture assembly instructions into AArch64 instruction set architecture assembly instructions according to an embodiment of this application is shown; Figure 6 An example of symbolic representation of a code fragment obtained by symbolic execution according to an embodiment of this application is shown; Figure 7 Examples of code with correct and incorrect translations are shown; Figure 8An example of the operation flow for iteratively querying an LLM to translate assembly code according to an embodiment of this application is shown; Figure 9 An example is shown of the mapping relationship between operands between assembly code segments before and after translation according to an embodiment of this application; Figure 10 A flowchart illustrating a binary code translation method according to an embodiment of this application is shown; Figure 11 A comparative diagram is shown between the binary code translation method according to an embodiment of this application and a binary code translation method of related technologies; Figure 12 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions of this application, the binary code translation method, electronic device, computer-readable storage medium, and computer software product provided in this application will be described in detail below with reference to the accompanying drawings.

[0019] Exemplary embodiments will be described more fully below with reference to the accompanying drawings; however, these exemplary embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will enable those skilled in the art to fully understand the scope of this application.

[0020] Where there is no conflict, the various embodiments of this application and the features thereof may be combined with each other.

[0021] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0022] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms “a” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated features, integrals, steps, operations, elements, and / or components is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded.

[0023] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0024] Traditional simulation-based software migration methods are unsuitable for the needs of modern CPU manufacturers due to their significant runtime overhead. Some ARM-based CPU manufacturers have adopted binary code translation technology to translate binary code running on the x86-64 architecture into corresponding ARM architecture code, allowing software to run directly on ARM-based CPUs and reducing runtime overhead. To this end, manufacturers using ARM-based architectures have developed dynamic translation-based binary software migration methods, called dynamic binary translators. For example, Apple's Rosetta 2 and Huawei's ExaGear have significantly reduced runtime overhead and have been successfully integrated into their respective hardware products.

[0025] Dynamic binary translators also face challenges due to the unpredictability of binary software. These dynamic binary translators rely on runtime information that occurs dynamically during program execution to guide the translation process. For example, due to compiler optimizations and the complex language features of high-level programming languages, modern binary software contains numerous indirect jumps, making it difficult to statically determine the jump target. Therefore, this approach inevitably introduces additional performance overhead. Research indicates that this overhead can reach 20% to 30%, limiting users' ability to fully utilize hardware performance and slowing the development of new hardware ecosystems.

[0026] Furthermore, a dynamic binary translator framework is required for the migrated binary software to run, which further reduces the portability of the binary software, as it cannot be transferred to other devices without a compatible translator framework. Additionally, implementing a translation system requires significant expertise and engineering effort, making it challenging to scale the system to other architectures and platforms. Currently, commercial binary translators like Rosetta 2 and ExaGear operate only within closed hardware and software ecosystems, limiting their universality for general-purpose ARM processors and Linux-like systems.

[0027] Therefore, there is still a need to develop a binary translator that can work across ARM processors from different manufacturers and different Linux-based operating systems.

[0028] This application provides a method for migrating binary code from well-supported CPU architectures (e.g., x86-64) to emerging architectures (e.g., AArch64) that currently lack strong software ecosystem support. According to the method of embodiments of this application, runtime overhead can be significantly reduced by converting binary code into portable native code that can be directly executed on the target hardware before deployment. Ahead-of-time (AOT) translation is implemented through a symbolic algorithm, which recovers symbols from the binary code and converts uncompilable disassembled code into a recompileable functional format. Based on the symbolic assembly code, the assembly code is further decomposed into snippets, and these snippets are translated into the target instruction set architecture using parameterized translation rules. Translation rules can be retained for future reuse, thereby reducing the cost of building and scaling binary translators and software migration tools. Furthermore, this application proposes an automatic translation rule learning method that can automatically extract and validate translation rules from a general large language model (LLM).

[0029] Figure 1 A flowchart of a binary code translation method according to an embodiment of this application is shown.

[0030] like Figure 1 As shown, the binary code translation method according to the embodiments of this application includes the following steps S110 to S160.

[0031] In step S110, the first binary code based on the first instruction set architecture is disassembled to obtain disassembled code.

[0032] In step S120, symbols are recovered in the disassembled code to obtain the first assembly code based on the first instruction set architecture.

[0033] Figure 2 An example of a symbolization process according to an embodiment of this application is shown.

[0034] Symbolization is a key technique in the disassembly process. Because developer-defined symbols (e.g., functions, variables, labels, etc.) are discarded during compilation, the resulting binary code only contains offsets that exist as constants (e.g., ...). Figure 2 (As shown in 0x10a0). These offset addresses are indistinguishable from constant immediate values, thus posing a challenge to recompiling the disassembled code. Figure 2 As shown on the left, during compilation, the memory layout will be changed, causing data to reside at different addresses. Therefore, the old offset address (e.g., 0x10a0) will point to the wrong data. Figure 2The value shown is 0xdead.

[0035] Symbolization techniques are used to recover missing symbols in disassembled code, such as Figure 2 As shown on the right, by restoring a specific offset address (e.g., 0x10a0) to a symbol label that the compiler can recognize (i.e., Figure 2 As shown in the ".label:"), during the compilation process, the compiler can ensure that in the newly generated code (i.e., Figure 2 The offset address and data corresponding to the lower right side still maintain the correct mapping relationship.

[0036] In step S130, the first assembly code is decomposed into multiple assembly code segments.

[0037] According to an embodiment of this application, decomposing the first assembly code into multiple assembly code segments (i.e., step S130) includes: performing data flow analysis on the first assembly code to identify the definition and usage of each operand in the first assembly code; and based on the identification results, decomposing the first assembly code into multiple assembly code segments with a static single assignment format.

[0038] Figure 3 An example of a process for decomposing a first assembly code into multiple assembly code fragments according to an embodiment of this application is shown.

[0039] exist Figure 3 In the example, the symbolic first assembly code is broken down into four assembly code snippets. The dashed lines indicate the boundaries of the resulting snippets, and the content after "#" is a comment explaining the reason for the split. The left side of the diagram shows the assembly code, while the right side illustrates the registers and memory accessed by each of the split assembly code snippets.

[0040] like Figure 3 As shown, the reason for splitting at the first and fourth points is that this is the end of the basic code block. The reason for splitting at the second point is that there is at least one memory access in the segment. The reason for splitting at the third point is that the next instruction will write to the rbx register again.

[0041] It should be understood that, according to embodiments of this application, each segmented fragment is formatted using a static single assignment (SSA) format. In this format, each variable or register is assigned a value only once in each code segment. This ensures that the translated code segments can be easily verified and reconnected into a complete assembly code without altering the semantics of the original software.

[0042] Figure 4 An example of pseudocode for performing assembly code splitting according to an embodiment of this application is shown.

[0043] For ease of understanding, Figure 4 A pseudocode representation of the decomposition algorithm is provided. Starting with symbolic assembly code, the segmentation process is guided by the core principles of SSA to reduce complexity. Linear sweep assembly instructions ( Figure 4 (Lines 6 and 13 of the algorithm code shown), and track the variables assigned by each instruction. Whenever a previously assigned variable is overridden ( Figure 4 Line 7 of the algorithm code shown breaks down the preceding assembly instructions into a code snippet and resets the record. Figure 4 (Lines 8 to 10 in the algorithm code shown). This process continues until the end of a basic block, at which point the control flow naturally ends a code segment.

[0044] In step S140, each of the multiple assembly code segments is translated to obtain an assembly code segment based on the second instruction set architecture.

[0045] According to embodiments of this application, translating each of a plurality of assembly code segments to obtain an assembly code segment based on a second instruction set architecture (i.e., step S140) includes: querying a large language model (LLM) to translate the assembly code segment from a first instruction set architecture to a second instruction set architecture; checking the validity of the translated assembly code segment based on the second instruction set architecture; if the validity check fails, determining a translation error and reporting the error information to the LLM for retranslation; if the validity check passes, determining that the translation is correct, parameterizing the translated operands to create translation rules, and reporting the created translation rules to the LLM.

[0046] Figure 5 An example is shown of translating assembly instructions of the x86-64 instruction set architecture into assembly instructions of the AArch64 instruction set architecture according to an embodiment of this application.

[0047] like Figure 5As shown, the first instruction set architecture is x86-64, and the second instruction set architecture is AArch64. The x86-64 instruction to be translated is "tzcntq %r13, %rdx". In the x86-64 Instruction Set Architecture (ISA) manual, the instruction "tzcnt" is described as "TZCNT counts the number of bits at the least significant end of the source operand (the second operand) and returns the result to the destination operand (the first operand)...". The translated AArch64 instruction set architecture instruction can be obtained by querying the LLM, such as... Figure 5 The code snippet below is an example.

[0048] According to embodiments of this application, checking the validity of the translated assembly code segment based on the second instruction set architecture includes: performing symbolic execution on the assembly code segment with a static single assignment format that does not contain program branches to obtain a symbolic representation of the program state; checking whether the symbolic representation of the assembly code segment before translation and the symbolic representation of the translated assembly code segment are equivalent; determining that the validity check passes in response to the fact that the symbolic representation of the assembly code segment before translation and the symbolic representation of the translated assembly code segment are equivalent; and determining that the validity check fails in response to the fact that the symbolic representation of the assembly code segment before translation and the symbolic representation of the translated assembly code segment are not equivalent.

[0049] The correctness (or validity) of a translation can be semantically verified through symbolic execution. The correctness (or validity) of the translation can be proven by judging whether the symbolic expressions of the code segments before and after the translation are equivalent.

[0050] Semantic verification of the translation results aims to ensure that the translated code is semantically equivalent to the original code. Two code snippets are considered semantically equivalent if they exhibit the same input-output behavior—that is, for the same input, the two code snippets always have the same output. Variables involved in assembly code include registers and memory; that is, memory can be abstractly considered as a special variable that includes not only its own value but also the address being accessed.

[0051] To verify semantic equivalence, symbolic execution can be performed on assembly code snippets of a first instruction set architecture (e.g., x86-64) and translated assembly code snippets of a second instruction set architecture (e.g., AArch64). Initial symbols can be set for all variables involved in the code snippets, then symbolic execution is performed, and the symbolic representation of each variable is collected after execution.

[0052] Figure 6 An example of the symbolic representation of a code fragment obtained by symbolic execution according to an embodiment of this application is shown.

[0053] See Figure 6 ,exist Figure 6 The upper part shows code snippets of the x86-64 instruction set architecture and the corresponding translated code snippets of the AArch64 instruction set architecture. Figure 6 The middle section shows the (simplified) symbolic representation obtained through symbolic execution. Figure 6 The lower part shows the register mappings that satisfy the conditions obtained from the search, as well as the corresponding equivalence constraints verified by the solver.

[0054] Figure 6 An example of the symbolic execution result is shown in Figure 6 In this code, the initial symbol is marked with the suffix "_init", for example, rdx_init represents the initial symbol of the rdx register. Verifying the equivalence between two code snippets requires finding valid mappings between registers that satisfy the equivalence property. Input variables are defined as variables read by the code snippets, and output variables are defined as variables written by the code snippets. A search method is used to explore possible register mappings, and a Satisfiability Modulo Theories (SMT) constraint solver is used to check whether a given mapping satisfies equivalence. If a valid mapping is found, the two code snippets are considered semantically equivalent; otherwise, if none of the possible mappings satisfy the condition, they are considered not equivalent.

[0055] Figure 7 Examples of code with correct and incorrect translations are shown.

[0056] like Figure 7 As shown, the x86-64 instruction movq specifically means: loading a 64-bit value from the memory address (indicated by the label ".LCd0") into the register rcx. Figure 7 The upper part shows that the x86-64 instruction `movq` was incorrectly translated directly into the `mov` instruction in the AArch64 instruction set architecture (the `mov` instruction is a register assignment instruction), while the semantically correct translation should be the `ldr` instruction (the `ldr` instruction is a memory read instruction). Semantic verification of the translation result can identify the incorrect translation and report the error to the LLM for retranslation. Alternatively, if the semantic verification passes, the translation is considered correct, the translated operands are parameterized to create translation rules, and the created translation rules are reported back to the LLM.

[0057] Parameterization, specifically, refers to the process of translating code snippets with similar structures, even if their operands differ, into a single instruction sequence. Therefore, specific operands (e.g., registers and immediate values) can be abstracted as parameters, and a general code snippet framework can be extracted. This allows for the reuse of validated translation rules for code snippets across multiple similar first-instruction-set architectures (e.g., x86-64 instruction set architecture) without repeated LLM lookups. Furthermore, parameterized translation rules are context-independent, guaranteeing functional consistency during reassembly.

[0058] Figure 8 An example of the operation flow for iteratively querying an LLM to translate assembly code according to an embodiment of this application is shown.

[0059] like Figure 8 As shown, assembly code snippets of the first instruction set architecture (e.g., x86-64 instruction set architecture) can obtain reference translation examples by querying a database. On the other hand, an interpretation of the assembly code snippets of the first instruction set architecture is provided using LLM, and then translation is performed based on the interpretation and the reference translation examples. The translation results are iteratively processed through compilation, verification, and correction, ultimately yielding a verified translated code snippet. The translated code snippet is parameterized to extract parameterization rules, and the parameterized rules, along with the original code snippet, symbol verification results, and mapping relationships, are stored in a rule database.

[0060] In step S150, the translated assembly code segments based on the second instruction set architecture are linked together to obtain the second assembly code based on the second instruction set architecture.

[0061] According to an embodiment of this application, linking the translated assembly code segments based on the second instruction set architecture to obtain second assembly code based on the second instruction set architecture (i.e., step S150) includes: for each of the plurality of assembly code segments, identifying the mapping relationship of operands between the assembly code segment before translation and the assembly code segment after translation; modifying the translated assembly code segments based on the second instruction set architecture to ensure operand consistency; and linking the modified assembly code segments based on the second instruction set architecture to obtain second assembly code.

[0062] Figure 9 An example is shown of the mapping relationship between operands between assembly code segments before and after translation according to an embodiment of this application.

[0063] See Figure 9 ,exist Figure 9The upper part shows the corresponding x86-64 and AArch64 code snippets and the verified register mappings. Figure 9 The lower part shows an example of parameterized abstraction of the relevant registers and operands.

[0064] It should be recognized that the x86-64 code snippet shows register edx, and the AArch64 code snippet shows register w2, while the register mapping relationship shows the mapping between rdx and x2. This is because in the x86-64 architecture, rdx and edx point to the same physical register, the difference being that rdx represents the entire 64 bits of the register, while edx points to the lower 32 bits. Similarly, in the AArch64 architecture, x2 and w2 point to the same physical register, x2 represents the entire 64 bits of the register, while w2 points to the lower 32 bits. Here, only the mapping relationship between physical registers is shown; therefore, the mapping between rdx and x2 shown can also represent the mapping between edx and w2 in the code snippet.

[0065] like Figure 9 As shown, the translation above is semantically correct and has been verified. Replacing specific operands with unique parameter identifiers... Figure 9 In the example, the parameter identifier consists of the parameter type and the parameter ID, for example,<REG_0_64bit> ,<REG_1_64bit> ,<REG_2_32bit> ,<IMM_0> and<LAB_0> Parameter identifiers are generated based on the mapping relationships produced in semantic verification. Parameterized rules, along with the original code snippets, symbol verification results, and mapping relationships, can be stored in a rule database.

[0066] After translating all code snippets, they need to be instantiated according to the generated rules (whether the rules come from a database or generated from parameterized LLM output). This is the reverse of parameterization. Only then can the instantiated code snippets be concatenated into the complete assembly code. During this process, specific operands are re-inserted into the translated code snippets to replace, for example,...<REG_0_64bit> Such parameter identifiers. Although immediate values ​​and labels can be directly extracted from code snippets of the first instruction set architecture (e.g., x86-64 instruction set architecture), register instantiation requires a consistent mapping between translated code snippets; that is, a register of a specific first instruction set architecture must always be mapped to a register of the same second instruction set architecture.

[0067] According to embodiments of this application, the first instruction set architecture includes the x86-64 instruction set architecture, and the second instruction set architecture includes the AArch64 instruction set architecture.

[0068] According to embodiments of this application, a fixed mapping relationship can be used to define the correspondence between x86-64 registers and AArch64 registers. Table 1 shows the correspondence between x86-64 registers and AArch64 registers.

[0069] Because AArch64 provides more general-purpose registers than x86-64, it does not cause register conflicts. The remaining AArch64 registers, which do not have corresponding x86-64 registers, can be used to store temporary values ​​introduced during the translation process.

[0070] In step S160, the second assembly code is assembled to obtain the second binary code based on the second instruction set architecture.

[0071] Figure 10 A flowchart illustrating a binary code translation method according to an embodiment of this application is shown.

[0072] like Figure 10 As shown, the binary code translation method according to an embodiment of this application includes the following process:

[0073] Binary symbolization Given the disassembled code of a target binary software (e.g., binary software based on the x86-64 instruction set architecture), use a symbology algorithm to restore the symbols defined in the original software to the assembly code, i.e. Figure 9 This illustrates the process of converting "x86-64 binary code" into "x86-64 assembly code." This process allows symbolic assembly code to be recompiled into a functional binary file.

[0074] Code Breakdown The assembly code for restoring symbols is broken down into code snippets. Each snippet is formatted in SSA (Simplified Chinese Assembly Format). In this format, each variable or register is allocated only once per snippet. This ensures that the translated code snippets can be easily verified and reconnected into a complete assembly code without altering the semantics of the original software.

[0075] Modular static binary translation Complete translation and verification of a general program is not feasible under current technological conditions. In the technical solution of this application, static binary translation can be achieved as a whole by rigorously verifying the translation target program of each code segment.

[0076] Translation rule reuse During the translation process, pairs of translated code snippets and original code snippets can be preserved. Specific immediate values, labels, and register names within the code snippets are parameterized to apply translation rules to various variations of the code snippets. These code snippet pairs can be stored in a database for further reuse, making the translation process data-driven. As more results accumulate in the database, the translation process becomes increasingly efficient and effective.

[0077] Translation verification and rule learning This application also proposes a translation method that queries, extracts, verifies, and learns translation rules from an LLM, without relying on pre-written assembly code translation rules. The translation code provided by the LLM can be rigorously verified, and symbolic execution is used to eliminate erroneous translation methods.

[0078] Binary software reconstruction The translated code snippets are relinked into complete assembly code, retaining the same functionality as the original binary software. The translated assembly code can be recompiled using standard compilers (e.g., gcc and clang) to produce portable native software that can run directly on the target hardware.

[0079] Figure 11 A comparative diagram is shown between the binary code translation method according to an embodiment of this application and binary code translation methods of related technologies.

[0080] like Figure 11 As shown, the binary code translation method according to embodiments of this application converts assembly code into a recompilable format by recovering symbols in the disassembled code, thus facilitating static binary translation. Static binary translation enables cross-architecture software migration before software use, significantly reducing runtime overhead. Therefore, the binary code translation method of embodiments of this application solves the challenges of developing static binary translation systems, greatly reducing the runtime overhead of software migration. Furthermore, the binary software is translated into portable native code and can run directly on the target hardware device without requiring a translator framework.

[0081] The binary code translation method according to the embodiments of this application provides the following improvements over the dynamic binary translation method in the related art:

[0082] Reduce expenses By statically translating the binary software before use, runtime translation overhead is eliminated. Therefore, software migrated using the binary code translation method according to embodiments of this application exhibits significantly lower runtime overhead and executes almost as efficiently as native software.

[0083] Enhanced portability Software migrated using the binary code translation method according to embodiments of this application can run independently of any runtime translation framework on the target hardware. The software operates in the same way as native software compiled on hardware with the target architecture. Therefore, the migrated software is highly portable and can be transferred between various devices and platforms without requiring a translation framework.

[0084] Enhanced scalability The automatic learning of translation rules significantly reduces the engineering complexity involved in creating a binary translator, thereby minimizing the need for expert intervention. Therefore, this LLM-based static binary translation mechanism is easy to update and adaptable to different operating systems and processors from various vendors. Furthermore, the modular nature of the translation process enhances error handling and debugging capabilities.

[0085] Figure 12 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown.

[0086] See Figure 12 Embodiments of this application also provide an electronic device, which includes a memory 1202 and a processor 1201. The memory 1202 stores a computer program, which, when executed by the processor 1201, causes the processor 1201 to implement the binary code translation method according to the embodiments of this application.

[0087] The processor 1201 and the memory 1202 are connected through one or more I / O interfaces 1203, which are configured to enable information exchange between the processor 1201 and the memory 1202.

[0088] The processor 1201 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 1202 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 1203 is connected between the processor 1201 and the memory 1202, enabling information exchange between the processor 1201 and the memory 1202, including but not limited to a data bus (Bus).

[0089] In the embodiments of this application, any of the embodiments in the foregoing method embodiments are applicable to the embodiments of this electronic device, and will not be described in detail here.

[0090] Embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the processor implements a binary code translation method according to various embodiments of this application.

[0091] In the embodiments of this application, any of the embodiments in the foregoing method embodiments are applicable to the embodiments of this computer-readable storage medium, and will not be described in detail here.

[0092] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, causes the processor to implement a binary code translation method according to various embodiments of this application.

[0093] In the embodiments of this application, any of the embodiments in the foregoing method embodiments are applicable to the embodiments of this computer program product, and will not be described in detail here.

[0094] Those skilled in the art will understand that all or some of the functional modules / units disclosed above can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0095] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components. For example, a physical component may have multiple functions, or a function or step may be executed by several physical components working together.

[0096] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; read-only optical disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cartridges, magnetic tapes, disk storage or other magnetic storage; and any other media that can be used to store desired information and can be accessed by a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0097] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A binary code translation method, comprising: The first binary code based on the first instruction set architecture is disassembled to obtain disassembled code; Symbols are recovered from the disassembled code to obtain first assembly code based on the first instruction set architecture; The first assembly code is decomposed into multiple assembly code fragments; Each of the plurality of assembly code segments is translated to obtain an assembly code segment based on the second instruction set architecture; The translated assembly code fragments based on the second instruction set architecture are linked together to obtain the second assembly code based on the second instruction set architecture. as well as The second assembly code is assembled to obtain a second binary code based on the second instruction set architecture. The first instruction set architecture is different from the second instruction set architecture.

2. The method according to claim 1, wherein, Decomposing the first assembly code into multiple assembly code fragments includes: Perform data flow analysis on the first assembly code to identify the definition and usage of each operand in the first assembly code; Based on the identification results, the first assembly code is decomposed into multiple assembly code fragments with a static single assignment format.

3. The method according to claim 2, wherein, The translated assembly code snippets based on the second instruction set architecture are linked together to obtain the second assembly code based on the second instruction set architecture, including: For each of the plurality of assembly code segments, identify the mapping relationship of operands between the assembly code segment before translation and the assembly code segment after translation; The translated assembly code snippets based on the second instruction set architecture are modified to ensure the consistency of the operands; The modified assembly code fragments based on the second instruction set architecture are linked together to obtain the second assembly code.

4. The method according to claim 1, wherein, Each of the plurality of assembly code segments is translated to obtain an assembly code segment based on the second instruction set architecture, including: Query a large language model to translate assembly code snippets from the first instruction set architecture to the second instruction set architecture; Check the validity of the translated assembly code snippet based on the second instruction set architecture; If the validity check fails, a translation error is identified, and the error information is fed back to the large language model so that the translation can be performed again. If the validity check passes, the translation is determined to be correct. The operands obtained from the translation are parameterized to create translation rules, and the translation rules are fed back to the large language model.

5. The method according to claim 4, wherein, Checking the validity of the translated assembly code snippets based on the second instruction set architecture includes: Symbolic execution is performed on assembly code fragments with static single assignment format that do not contain program branches to obtain a symbolic representation of the program state; Check whether the symbolic representation of the assembly code fragment before translation is equivalent to the symbolic representation of the assembly code fragment after translation; If the symbolic representation of the assembly code segment before translation is equivalent to the symbolic representation of the assembly code segment after translation, the validity check is determined to be passed. The validity check failed because the symbolic representation of the assembly code segment before translation was not equivalent to the symbolic representation of the assembly code segment after translation.

6. The method according to any one of claims 2 to 5, wherein, The operands include immediate values, registers, and tags.

7. The method according to any one of claims 1 to 5, wherein, The first instruction set architecture includes the x86-64 instruction set architecture, and the second instruction set architecture includes the AArch64 instruction set architecture.

8. An electronic device comprising a memory and a processor, wherein, The memory stores a computer program, which, when executed by the processor, causes the processor to implement the binary code translation method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, wherein when executed by a processor, the computer program causes the processor to implement the binary code translation method according to any one of claims 1 to 7.

10. A computing program product comprising a computer program that, when executed by a processor, causes the processor to implement the binary code translation method according to any one of claims 1 to 7.

Images