Method for translating binary code, electronic device, storage medium and software product

Abstract

The invention provides a binary code translation method which comprises the following steps: disassembling a first binary code based on a first instruction set architecture to obtain a disassembled code; recovering a symbol in the disassembly code to obtain a first assembly code based on the first instruction set architecture; decomposing the first assembly code into a plurality of assembly code snippets; translating each of the plurality of assembly code snippets to obtain an assembly code snippet based on a second instruction set architecture; connecting the translated assembly code snippets based on the second instruction set architecture to obtain a second assembly code based on the second instruction set architecture; the second assembly code is assembled to obtain a second binary code based on the second instruction set architecture, and the first instruction set architecture is different from the second instruction set architecture. The invention further provides an electronic device, a computer readable storage medium and a computer program product.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202511916198.2 (22) Application Date 2025.12.18 (30) Priority Data 63 / 738,531 2024.12.24 US (71) Applicant Hong Kong University of Science and Technology Address Clear Water Bay, Kowloon, Hong Kong, China (72) Inventors Wang Shuai Liu Zhibo (74) Patent Agency Beijing Tianhao United Intellectual Property Agency Co., Ltd. 11112 Patent Attorney Zhang Na Gu Libo (51) Int.Cl. G06F 8 / 53 (2018.01) G06N 5 / 04 (2023.01) (54) Invention Title: Binary Code Translation Method, Electronic Device, Storage Medium, and Software Product (57) 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. Claims 2 pages, Description 11 pages, Drawings 8 pages, CN 122285018 A 2026.06.26 CN 1 22 28 50 18 A 1. 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 a plurality of assembly code segments; translating each of the plurality of 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. 2. The method according to claim 1, wherein decomposing the first assembly code into a plurality of assembly code segments comprises: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, decompose the first assembly code into multiple assembly code segments with a static single assignment format. 3. The method according to claim 2, wherein 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 includes: for each of the multiple assembly code segments, identifying the mapping relationship of operands between the pre-translation assembly code segment and the translated assembly code segment; modifying the translated assembly code segments based on the second instruction set architecture to ensure the consistency of the operands; concatenating the modified assembly code segments based on the second instruction set architecture to obtain the second assembly code. 4. The method according to claim 1, wherein translating each of the plurality of assembly code segments to obtain an assembly code segment based on the second instruction set architecture comprises: querying a large language model to translate the assembly code segment from the first instruction set architecture to the 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 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. 5. The method of claim 4, wherein checking the validity of the translated assembly code segment based on the second instruction set architecture comprises: performing symbolic execution on the assembly code segment of 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; in response to the symbolic representation of the assembly code segment before translation and the symbolic representation of the translated assembly code segment being equivalent, determining that the validity check passes; in response to the symbolic representation of the assembly code segment before translation and the symbolic representation of the translated assembly code segment being not equivalent, determining that the validity check fails. 6. The method of any one of claims 2 to 5, wherein the operands include immediate values, registers, and tags. 7. The method of 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...The processor implements 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, which, when executed by a processor, causes the processor to implement the binary code translation method according to any one of claims 1 to 7. 10. A computer program product comprising a computer program, which, when executed by a processor, causes the processor to implement the binary code translation method according to any one of claims 1 to 7. Claims 2 / 2 Page 3 CN 122285018 A Binary Code Translation Method, Electronic Device, Storage Medium and Software Product Technical Field

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

[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 mature software ecosystem support, making it difficult to promote among a wide range of users.

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

[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 always choose a dynamic translation paradigm and translate the binary code at runtime. However, this again introduces runtime overhead issues, as well as portability and scalability problems. Summary of the Invention

[0005] Embodiments of this application provide a binary code translation method, electronic device, computer-readable storage medium, and 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, including: disassembling a first binary code based on a first instruction set architecture to obtain disassembled code; recovering symbols in the disassembled code to obtain a first assembly code based on the first instruction set architecture; and decomposing the first assembly code into multiple assembly code fragments;Each of the plurality of assembly code segments is translated to obtain an assembly code segment based on a second instruction set architecture; the translated assembly code segments based on the second instruction set architecture are concatenated to obtain a second assembly code based on the second instruction set architecture; and the second assembly code is assembled to obtain a 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 a plurality of 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 result, decomposing the first assembly code into a plurality of 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 an embodiment of this application, translating each of the plurality of assembly code segments to obtain an assembly code segment based on a second instruction set architecture includes: querying a large language model to translate the assembly code segment from the first instruction set architecture to the 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 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 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.

[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 implements a binary code translation method according to embodiments of this application.

[0014] Embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, and 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 computing program product, which includes a computer program, and when the computer program is executed by a processor, the processor implements a binary code translation method according to embodiments of this application.

[0016] According to the binary code translation method of embodiments 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.

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

[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 by this application will be described in detail below with reference to the accompanying drawings.

[0019] Example embodiments will be described more fully below with reference to the accompanying drawings; however, these example 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 to make this application thorough and complete, and to enable those skilled in the art to fully understand the scope of this application.

[0020] Without conflict, the various embodiments of this application and the features in the embodiments may be combined with each other.

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

[0022] The terminology used herein is only for describing particular embodiments and is not intended to limit this 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, they specify the presence of the said feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0023] Unless otherwise defined, 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 common dictionaries should be interpreted as having the 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 defined herein.

[0024] Traditional simulation-based software migration methods are unsuitable for the needs of modern CPU manufacturers due to their huge runtime overhead. Some ARM architecture 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 CPUs with ARM architecture to reduce runtime overhead. To address this, manufacturers using ARM architecture have developed binary software migration methods based on dynamic translation, known as 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...Due to the complex language features of optimization and high-level programming languages, modern binary software contains a large number of indirect jumps, making it difficult to statically determine the jump target. Therefore, this approach inevitably introduces additional performance overhead. Studies have shown that this additional overhead can reach 20% to 30%, limiting the user's ability to fully utilize hardware performance and slowing down the development of new hardware ecosystems.

[0026] Furthermore, there must exist a dynamic binary translator framework so that the migrated binary software can run, which further reduces the portability of the binary software, because without a compatible translator framework, the migrated binary software cannot be transferred to other devices. In addition, implementing a translation system requires a lot of expertise and engineering work, which makes it challenging to extend the translation system to other architectures and platforms. Currently, commercial binary translators such as Rosetta 2 and ExaGear can only run in closed hardware and software ecosystems, thus limiting the universality of these binary translators for general-purpose ARM processors and Linux-like systems.

[0027] Therefore, there is still a need to propose a binary translator that can span ARM processors from different vendors 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 symbology algorithm, which can recover symbols from binary code and convert uncompileable disassembled code into a recompileable functional format. Based on the symbology of the 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 reuse, thereby reducing the cost of building and scaling binary translators and software migration tools. Furthermore, this application also proposes an automatic translation rule learning method that can automatically extract and verify translation rules from a general large language model (LLM).

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

[0030] As shown in Figure 1, the binary code translation method according to an embodiment 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 first assembly code based on the first instruction set architecture.

[0033] FIG2 shows an example of the symbolization process according to an embodiment of the present application.

[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 compiled binary code only contains offset addresses that exist in constant form (e.g., 0x10a0 shown in FIG2). These offset addresses are indistinguishable from constant immediate values, thus posing a challenge to recompiling the disassembled code. As shown on the left side of FIG2, during compilation, the memory layout will be changed so that data is located at different addresses, so the old offset address (e.g., 0x10a0) will point to the wrong data, i.e., 0xdead shown in FIG2.

[0035] Symbolization technology is used to recover lost symbols in disassembled code. As shown on the right side of Figure 2, by restoring specific offset addresses (e.g., 0x10a0) to symbol labels that the compiler can recognize (i.e., “.label:” shown in Figure 2), the compiler can ensure that the corresponding offset addresses and data in the newly generated code (i.e., the lower right side of Figure 2) still maintain the proper 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 method of each operand in the first assembly code; based on the identification results, decomposing the first assembly code into multiple assembly code segments with a static single assignment format.

[0038] Figure 3 shows an example of the process of decomposing the first assembly code into multiple assembly code segments according to an embodiment of this application.

[0039] In the example of Figure 3, the symbolic first assembly code is decomposed into four assembly code snippets. The dashed lines indicate the boundaries of the decomposed snippets, and the content after "#" is a comment explaining the reason for the split at this point. The left side of the figure shows the assembly code, and the right side shows the registers and memory accessed by each of the split assembly code snippets.

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

[0041] It should be recognized that, according to embodiments of this application, each segmented fragment is formatted in the form of static single assignment (SSA). In this format, each variable or register is assigned 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 changing the semantics of the original software.

[0042] Figure 4 shows an example of pseudocode for performing assembly code segmentation according to embodiments of this application.

[0043] For ease of understanding, Figure 4 provides a pseudocode representation of the decomposition algorithm. Starting with symbolic assembly code, the segmentation process is guided by the core principles of SSA to reduce complexity. Linear sweep assembly instructions (lines 6 and 13 in the algorithm code shown in Figure 4) are linearly swept, and the variables assigned by each instruction are tracked. Whenever a previously assigned variable is overwritten (line 7 in the algorithm code shown in Figure 4), the preceding assembly instruction is split into a code segment and the record is reset (lines 8 to 10 in the algorithm code shown in Figure 4). 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 an embodiment of this application, translating each of the multiple assembly code segments to obtain an assembly code segment based on the second instruction set architecture (i.e., step S140) includes: querying a large language model (LLM) to translate the assembly code segment from the first instruction set architecture to the 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 feeding back 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 feeding back the created translation rules to the LLM.

[0046] Figure 5 illustrates 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.

[0047] As shown in Figure 5, the first instruction set architecture is x86-64 instruction set architecture, and the second instruction set architecture is AArch64 instruction set architecture. 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 represents the number of least significant bits at the end of the source operand (the second operand)”.Perform a count and return the result to the target operand (the first operand)...". The translated instructions of the AArch64 instruction set architecture can be obtained by querying the LLM, as shown in the code snippet below Figure 5.

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

[0049] The correctness (or validity) of the translation can be semantically verified by symbolic execution, and the translation can be proven to be correct (or valid) by judging whether the symbolic expressions of the code snippets before and after translation are equivalent.

[0050] Semantic verification of the translation results aims to ensure that the translated code is semantically equivalent to the original code. If two code segments exhibit the same input-output behavior, that is, for the same input, the two code segments always have the same output, they can be considered semantically equivalent. Variables involved in the 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 accessed.

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

[0052] Figure 6 shows an example of the symbolic representation of a code segment obtained by symbolic execution according to an embodiment of this application.

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

[0054] Figure 6 shows an example of the symbolic execution results. In Figure 6, 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 a valid mapping between registers that satisfies 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 can be considered semantically equivalent; otherwise, if none of the possible mappings satisfy the condition, they are considered not equivalent.

[0055] Figure 7 shows examples of correctly translated and incorrectly translated code.

[0056] As shown in Figure 7, the x86-64 instruction movq specifically means: loading a 64-bit value from the memory address (indicated by the label ".LCd0") into the rcx register. As shown in the upper part of Figure 7, 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). By semantically verifying the translation result, the incorrect translation can be identified, and error information can be fed back to the LLM for retranslation. Alternatively, if the semantic verification passes, the translation can be considered correct, and the translated operands can be parameterized to create translation rules, which are then fed back to the LLM.

[0057] Specifically, the parameterization process refers to the fact that for code segments with similar structures, although the operands may differ, they typically produce translation results with the same instruction sequence. Therefore, specific operands (e.g., registers and immediate values) can be abstracted as parameters, and then a general code segment framework can be extracted. This allows for the reuse of validated translation rules (page 6 / 11, CN 122285018 A) for code snippets of multiple similar first instruction set architectures (e.g., x86-64 instruction set architecture) without repeated LLM queries. On the other hand, parameterized translation rules are context-independent, ensuring functional consistency during reassembly.

[0058] Figure 8 illustrates an example of the iterative LLM query operation flow for translating assembly code according to an embodiment of this application.

[0059] As shown in Figure 8, an example of how a reference translation can be obtained for an assembly code snippet of a first instruction set architecture (e.g., x86-64 instruction set architecture) by querying a database. On the other hand, the LLM translates assembly code snippets of the first instruction set architecture...The section provides an explanation, and then translates the code based on the explanation and the example of the reference translation. The translation result is iterated through the process of compilation, verification and correction, and finally a verified translated code segment is obtained. The translated code segment is parameterized to extract parameterization rules, and the parameterization rules, as well as the original code segment, symbol verification results and mapping relationships are stored in the rule database.

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

[0061] According to the embodiments of this application, connecting the translated assembly code segments based on the second instruction set architecture to obtain the 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 the consistency of operands; and connecting the modified assembly code segments based on the second instruction set architecture to obtain the second assembly code.

[0062] Figure 9 illustrates an example of the operand mapping between assembly code segments before and after translation according to an embodiment of this application.

[0063] Referring to Figure 9, the upper part of Figure 9 shows the corresponding x86-64 and AArch64 code segments and the verified register mapping, while the lower part of Figure 9 shows an example of parameterized abstraction of the relevant registers and operands.

[0064] It should be understood that register edx is shown in the x86-64 code segment, and register w2 is shown in the AArch64 code segment, while the register mapping shows 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 all 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 all 64 bits of the register, while w2 points to the lower 32 bits. Here, only the mapping relationship between physical registers is shown, so the mapping between rdx and x2 shown can also represent the mapping between edx and w2 in the code snippet.

[0065] As shown in Figure 9, the translation shown above is semantically correct and has been verified. Specific operands are replaced with unique parameter identifiers. In the example of Figure 9, 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> etc. Based on semantic verificationThe mapping relationships generated in the process produce parameter identifiers, which can store parameterized rules, original code snippets, symbol verification results, and mapping relationships in the rule database.

[0066] After translating all code snippets, instantiation (concretization) is required based on the generated rules (whether the rules come from the database or are generated through parameterized LLM output), that is, the reverse process of parameterization, before the instantiated code snippets can be concretized 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 a first instruction set architecture (e.g., x86-64 instruction set architecture), register instantiation requires a consistent mapping between the various translated code snippets; that is, a register of a specific first instruction set architecture must always be mapped to the same register of a second instruction set architecture.

[0067] 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 specification 7 / 11 pages 10 CN 122285018 A includes the AArch64 instruction set architecture.

[0068] According to an embodiment 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] Since AArch64 provides more general-purpose registers than x86-64, it does not cause register conflicts. The remaining AArch64 registers that do not correspond to 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 a second binary code based on the second instruction set architecture.

[0071] FIG10 shows a schematic flowchart of a binary code translation method according to an embodiment of the present application.

[0072] As shown in FIG10, the binary code translation method according to an embodiment of the present application includes the following process:

[0073] Binary symbolization of the disassembled code of a given target binary software (e.g., binary software of x86-64 instruction set architecture), and the symbols defined in the original software are restored to the assembly code using a symbolization algorithm, that is, the process from "x86-64 binary code" to "x86-64 assembly code" shown in FIG9. This process allows the symbolized assembly code to be recompiled into a functional binary file.

[0074] Code decomposition of the restored symbolic assembly code is decomposed into code fragments. Each code fragment is formatted in SSA form.In this format, each variable or register is allocated 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 changing the semantics of the original software.

[0075] Modular static binary translation is not feasible under current technical conditions to translate and verify a general program completely. 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 specification 8 / 11 pages 11 CN 122285018 A During the translation process, pairs of translated code segments and original code segments can be retained. Specific immediate values, labels, and register names in the code segments are parameterized so that translation rules can be applied to various variants of the code segments. These code segment pairs can be stored in a database for further reuse, making the translation process a data-driven process. As more and more results accumulate in the database, the translation process will become more and more efficient.

[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 fragments are reconnected 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 device.

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

[0080] As shown in Figure 11, the binary code translation method according to an embodiment of this application can convert assembly code into a recompilable format by recovering symbols in the disassembled code, which helps to achieve static binary translation. Static binary translation enables cross-architecture software migration before software use, thereby significantly reducing runtime overhead. Therefore, the binary code translation method of this application embodiment solves the challenge of developing a static binary translation system, and greatly reduces the runtime overhead of migrating software. 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] Reduced overhead: By statically translating the binary software before use, runtime translation overhead is eliminated. Therefore, using…The software migrated using the binary code translation method according to the embodiments of this application exhibits significantly lower runtime overhead and executes almost as efficiently as native software.

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

[0084] Enhanced Scalability The learning of automatic translation rules greatly 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 can adapt to different operating systems and processors from different vendors. In addition, the modularity of the translation process enhances the ability to handle and debug errors.

[0085] FIG12 shows a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0086] Referring to FIG12, an embodiment of this application also provides an electronic device, which includes a memory 1202 and a processor 1201. The memory 1202 stores a computer program. When the computer program is executed by the processor 1201, the processor 1201 implements 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 realize information interaction 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 interaction 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] The embodiments of this application also provide a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, the processor implements the binary code translation method according to the 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] The embodiments of this application also provide a computer program product, which includes a computer program. When the computer program is executed by a processor, the processor implements the binary code translation method according to the 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, and suitable combinations thereof.

[0095] In the hardware implementation, the division between the 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 in cooperation.

[0096] Some or all physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or temporary 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 technology for storing information (such as computer-readable instructions, data structures, program modules or other data). Computer storage media includes, but is not limited to, random access memory (RAM, more specifically such as 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; 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] Exemplary embodiments have been disclosed herein, and although specific terminology has been used, it is used and should be interpreted only in a general illustrative sense and is not intended for limiting purposes. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or descriptions in conjunction with particular embodiments may be used alone, unless otherwise expressly indicated.The elements, features, characteristics, and / or components described may be used in combination with other embodiments. 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. Instruction Manual 11 / 11 Page 14 CN 122285018 A Figure 1 Instruction Manual Figure 1 / 8 Page 15 CN 122285018 A Figure 2 Figure 3 Instruction Manual Figure 2 / 8 Page 16 CN 122285018 A Figure 4 Instruction Manual Figure 3 / 8 Page 17 CN 122285018 A Figure 5 Figure 6 Instruction Manual Figure 4 / 8 Page 18 CN 122285018 A Figure 7 Figure 8 Instruction Manual Figure 5 / 8 Page 19 CN 122285018 A Figure 9 Instruction Manual Figure 6 / 8 Page 20 CN 122285018 A Figure 10 Instruction Manual Figure 7 / 8 Page 21 CN 122285018 A Figure 11 Figure 12 Instruction Manual Figure 8 / 8 Page 22 CN 122285018 A Abstract The present application provides a binary code translation method, including: 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; splitting the first assembly code into a plurality of assembly code snippets; translating each of the plurality of assembly code snippets respectively to obtain assembly code snippets based on a second instruction setarchitecture; concatenating the translated assembly code snippets 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. The present application also provides an electronic device, a computer-readable storage medium, and a computer program product.

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