A decompilation method and system based on a large language model

Abstract

The application relates to a decompilation method and system based on a large language model, which comprises the following steps: performing reverse assembly on a target binary to obtain assembly code and a control flow graph, generating decompiled source code through a large language model, recompiling the decompiled source code to obtain recompiled binary, and automatically generating a differential test input by taking the target binary as an executable oracle, performing differential comparison on the target binary and the recompiled binary under the same differential test input to obtain deviation information, inputting the deviation information as feedback into the large language model to perform directional correction and iteration until semantic equivalence is achieved. The application verifies and performs directional correction on the decompiled source code by taking the target binary as an objective truth value, so that the decompiled source code converges to semantic equivalence with the target binary.

Description

Technical Field

[0001] This application relates to the field of computer program decompilation technology, and in particular to a decompilation method and system based on a large language model. Background Technology

[0002] Binary decompilation is used to recover the high-level language representation of a program in the absence of source code, and is commonly used in scenarios such as security auditing, vulnerability analysis, and legacy system maintenance. In recent years, Large Language Models (LLMs) have been introduced into binary decompilation to generate more readable decompiled source code from the assembly code obtained from disassembly.

[0003] However, existing decompilation methods based on large language models generate decompiled source code from the input binary in one go during the inference stage. Because they lack a verification step that treats the original binary as an objective truth value, they cannot determine whether the generated decompiled source code is semantically equivalent to the original program in terms of execution behavior. As a result, the inherent illusions of large language models are difficult to detect, and semantic deviations in the decompiled source code are difficult to locate. Ultimately, the deviations between the decompiled results and the original program's behavior cannot be corrected. Even if some methods introduce fixed preset inputs or fixed iteration rounds for processing, they are still difficult to converge to a result that is semantically equivalent to the original program because the verification benchmark is not the executable behavior of the original binary and there is a lack of targeted correction for deviations.

[0004] Therefore, there is a need for a decompilation method based on a large language model that can objectively verify the decompiled results using the original binary data as the executable truth value, and iteratively correct the deviation information obtained from the verification to semantic equivalence. Summary of the Invention

[0005] To address the problems of existing decompilation methods based on large language models (LLMs) that generate decompiled source code in one go during the inference stage, lack a verification step using the original binary code as an objective truth value, and result in the inability to detect and correct semantic deviations between the decompiled results and the original program, this application provides a decompilation method and related apparatus based on large language models (LLMs).

[0006] Firstly, this application provides a decompilation method based on a large language model, employing the following technical solution: A decompilation method based on a large language model includes the following steps: S1. Disassembling the target binary to obtain assembly code and a control flow graph; S2. Generating decompiled source code based on the assembly code and control flow graph using the large language model; S3. Recompiling the decompiled source code to obtain a recompiled binary, and automatically generating differential test input using the target binary as an executable oracle; S4. Running the target binary and the recompiled binary respectively under the same differential test input, performing differential comparison on the running behavior to obtain deviation information representing semantic deviation; S5. Injecting the deviation information as feedback into the large language model to perform targeted correction on the decompiled source code, and repeating S3 to S5 until the deviation information satisfies the semantic equivalence convergence condition.

[0007] By adopting the above technical solution, using the target binary as an executable oracle, differential test input is automatically generated after recompilation, and differential comparison is performed between the target binary and the recompiled binary. This allows the decompiled source code generated by the large language model to be verified for fidelity based on the objective running behavior of the original binary, exposing semantic deviations in the decompiled source code without relying on manually written test cases. Furthermore, the deviation information is injected into the large language model as feedback for targeted correction and iteration, so that the decompilation result approaches and converges to semantic equivalence with the target binary round by round. Thus, the semantic fidelity of the decompiled source code can still be improved even with compilation optimization and information loss.

[0008] Optionally, S4 also includes the following operations: performing an isolability determination on the function to be verified in the target binary to obtain an isolability determination result; in response to the isolability determination result being isolable, performing a differential comparison on the function to be verified; in response to the isolability determination result being non-isolated, promoting the function to be verified in the target binary and the recompiled binary to a unified intermediate representation (IR), performing a semantic equivalence check on the unified intermediate representation by basic blocks, identifying basic blocks that fail the semantic equivalence check as deviated blocks, and the deviance information including the identifier of the deviated block.

[0009] By adopting the above technical solution, the flow is split between black-box difference and intermediate representation level semantic equivalence check according to the function's isolation, so that functions that cannot be isolated can still complete the fidelity check and locate the semantic deviation to the specific basic block, providing a scope for targeted correction.

[0010] Optionally, after the deviation block is determined, the following operations are performed on the deviation block: based on the definition and usage relationship of each variable in the unified intermediate representation, backtrack to generate the upstream basic block of the input consumed by the deviation block, and obtain the data dependency closure of the deviation block; use the data dependency closure as the minimum re-decompile range when performing targeted correction on the decompiled source code.

[0011] By adopting the above technical solution, the scope of targeted correction is extended from the syntactic difference block to the upstream block closure that generates its input, avoiding invalid iterations caused by only correcting the downstream block while the root cause lies in the upstream, thus improving convergence efficiency.

[0012] Optionally, after the deviation block is determined, the following operations are also included: converting the semantic equivalence check result of the deviation block into a structured correction hint, which contains a description of the difference between the expected computational semantics of the corresponding basic block of the target binary and the actual computational semantics of the corresponding basic block of the recompiled binary; and injecting the structured correction hint along with the deviation information into the large language model.

[0013] By adopting the above technical solution, block-level semantic differences are expressed as a structured description of the differences between expected and actual semantics, enabling large language models to obtain a basis for correcting specific computational deviations, rather than simply being informed of errors, thus improving the targeted nature of the correction.

[0014] Optionally, for non-convergent blocks in the deviation block that still do not satisfy the semantic equivalence convergence condition after directional correction, a candidate transformation iteration is performed. The candidate transformation iteration includes: determining candidate compiler optimization transformations for interpreting the non-convergent blocks from a pre-set inverse mapping library; generating candidate decompiled source code for the non-convergent blocks according to the inverse transformation constraints corresponding to the candidate compiler optimization transformations; applying the candidate compiler optimization transformations forward to the candidate decompiled source code to obtain a forward verification result; adopting the candidate decompiled source code in response to the forward verification result reproducing the assembly mode corresponding to the non-convergent block; and re-determining the candidate compiler optimization transformations from the inverse mapping library and repeating the candidate transformation iteration in response to the forward verification result failing to reproduce the assembly mode corresponding to the non-convergent block.

[0015] By adopting the above technical solution, the compiler optimization transformation of repeatedly non-converging hard blocks is determined by reverse hypothesis and forward verification, and the large language model is re-decompiled by inverse transformation constraints, so that the processing of hard blocks is transformed from blind regeneration to verifiable approximation, thereby improving the convergence of the closed loop on highly optimized code.

[0016] Optionally, the inverse mapping library stores the corresponding high-level language constructs and the assembly modes generated after the high-level language constructs are transformed by the compiler optimization set according to the preset compiler optimization set, and uses the compiler type and optimization level as the index of the inverse mapping library; the compiler optimization set includes at least one of loop vectorization, loop unrolling, strength reduction, function inlining, common subexpression elimination and tail call optimization.

[0017] By adopting the above technical solution, the inverse mapping library is constructed as a set of high-level construction and assembly mode pairs indexed by compiler type and optimization level, providing an implementable basis for the generation of inverse transformation constraints and supporting the full disclosure of the library construction method in the specification.

[0018] Optionally, in response to the non-convergent block still not being adopted after the candidate transformation iteration reaches the preset iteration condition, the candidate decompiled source code with the smallest semantic deviation is selected from each candidate decompiled source code corresponding to the non-convergent block as the final decompiled source code of the non-convergent block, and the semantically equivalent input domain of the final decompiled source code is given; the semantically equivalent input domain is the set of differential test inputs that have been verified to make the target binary and the recompiled binary behavior equivalent.

[0019] By adopting the above technical solution, when a difficult block cannot converge in form, the candidate source code with the smallest semantic deviation and its input domain, which is equivalent to the verified behavior, are output, so that the closed loop has a definite termination condition, and the quantitative validity boundary of the block result is given by the input domain.

[0020] Optionally, automatically generating differential test inputs includes generating differential test inputs covering multiple execution paths through fuzzing.

[0021] By adopting the above technical solution, fuzz testing expands the coverage of differential test input on the execution path, thereby increasing the probability of triggering semantic deviation.

[0022] Optionally, the automatic generation of differential test inputs also includes differential test inputs that cover specific execution paths through symbolic execution solution.

[0023] By adopting the above technical solution, symbolic execution is used to generate differential test inputs for paths that are difficult to reach randomly, thus supplementing the coverage of deep paths.

[0024] Optionally, when performing differential alignment, the instruction-level alignment results of the target binary and the recompiled binary are also used to help locate semantic deviations.

[0025] By adopting the above technical solution, instruction-level alignment provides supplementary clues for deviation localization, which is corroborated by basic block-level semantic equivalence checks.

[0026] Optionally, the iterative budget for performing targeted corrections on the decompiled source code is dynamically adjusted based on the block-level semantic distance from the deviated block.

[0027] By adopting the above technical solution, the iteration budget is dynamically allocated based on the block-level semantic distance, replacing the fixed iteration upper limit, so that the convergence process matches the correction difficulty of each block.

[0028] Secondly, this application provides a decompilation system based on a large language model, which adopts the following technical solution: A decompilation system based on a large language model includes: a disassembly module configured to disassemble a target binary to obtain assembly code and a control flow graph; a generation module configured to generate decompiled source code based on the assembly code and control flow graph using the large language model; a recompilation module configured to recompile the decompiled source code to obtain a recompiled binary, and automatically generate differential test input using the target binary as an executable oracle; a differential comparison module configured to run the target binary and the recompiled binary separately under the same differential test input, perform differential comparison on the running behavior, and obtain deviation information representing semantic deviation; and a correction control module configured to inject the deviation information as feedback into the large language model, perform targeted correction on the decompiled source code, and trigger the recompilation module, differential comparison module, and correction control module to be executed repeatedly until the deviation information satisfies the semantic equivalence convergence condition.

[0029] By adopting the above technical solution, each module takes the behavior difference between the target binary and the recompiled binary as the core of the differential comparison module, and forms a closed loop with the feedback trigger of the correction control module, so that the system can perform fidelity verification and targeted correction on the decompiled source code without relying on manual test cases.

[0030] Thirdly, the computer device provided in this application adopts the following technical solution: A computer device comprising: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to: Perform the above-described decompilation method based on a large language model.

[0031] Fourthly, the computer-readable storage medium provided in this application adopts the following technical solution: A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above.

[0032] The storage medium stores at least one instruction, at least one program, a code set, or an instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the following: Such as the decompilation method based on the large language model mentioned above.

[0033] In summary, this application includes at least one of the following beneficial technical effects: 1. Using the target binary as an executable oracle, differential comparison is performed on the recompiled binary, and the deviation information is fed back to the large language model for targeted iterative correction. This allows the decompiled source code to complete fidelity verification based on the objective running behavior of the original binary without manual test cases and converge to semantic equivalence, thereby improving the semantic fidelity of the decompilation results.

[0034] 2. Based on the function's isolationability, the process is split between black-box difference and intermediate representation-level semantic equivalence checks, allowing functions that cannot be isolated to still be verified. Deviations are located to basic blocks, the minimum scope of recompiling is defined by data dependency closures, and structured semantic difference hints guide corrections, improving the targeting of root cause localization and correction.

[0035] 3. For repeatedly non-convergent hard blocks, determine their compiler optimization transformation by using reverse hypothesis and forward verification, and recompile them with inverse mapping library constraints. If they still do not converge, output the candidate source code with the smallest semantic deviation and its input domain that is equivalent to the verified behavior, so that the closed loop has both convergence and quantization validity boundary on highly optimized code. Attached Figure Description

[0036] Figure 1 A general flowchart of the decompilation method based on a large language model provided for embodiments of this application; Figure 2 A sub-flowchart for differential alignment and isolability decomposition provided in the embodiments of this application; Figure 3 A sub-flowchart of the candidate transformation iteration for non-convergent blocks provided in this application embodiment; Figure 4 This is a structural block diagram of a decompilation system based on a large language model, provided for an embodiment of this application.

[0037] Explanation of reference numerals in the attached figures: 100. Decompilation system; 110. Disassembler module; 120. Generation module; 130. Recompile module; 140. Differential comparison module; 150. Correction control module. Detailed Implementation

[0038] This application provides a decompilation method based on a large language model. After generating decompiled source code using the large language model, the method uses the original target binary itself as an executable oracle. It objectively verifies the generated decompiled source code through recompilation and automatic differential execution, and feeds back the deviation information obtained from the verification to the large language model for targeted correction, iterating until the decompiled source code and the target binary are semantically equivalent.

[0039] To facilitate understanding, some terms are explained below.

[0040] The target binary refers to the binary program whose source code is to be recovered, such as an executable file obtained by compiling C language source code with an O2 optimization level.

[0041] An executable oracle is an executable program that can produce a definite output for a given input, thereby serving as the truth value of behavior; in this application, it is the target binary itself.

[0042] Semantic equivalence means that two programs produce the same observable behavior under the same input.

[0043] As a baseline scenario for the subsequent explanations, let's take a function in a target binary that sums an integer array element by element as an example. This function is optimized for loop vectorization at compile time. The following will combine... Figure 1-3 Each step is explained in detail.

[0044] S1. Disassemble the target binary to obtain assembly code and a control flow graph. For example, disassembling a target binary containing the array summation function described above will yield the assembly instruction sequence of the function and a control flow graph describing the jump relationships between the basic blocks within the function. The assembly code and control flow graph serve as input for the subsequent generation of decompiled source code from the large language model.

[0045] S2. Generate decompiled source code from the assembly code and control flow graph using a large language model. The large language model takes the above assembly instruction sequence and control flow graph as input and outputs the high-level language decompiled source code corresponding to the array summation function. Since the large language model may introduce content that is inconsistent with the original function's behavior during the generation process, the generated decompiled source code needs to be objectively verified against the target binary in subsequent steps to determine whether it is semantically equivalent to the original function.

[0046] S3. Recompile the decompiled source code to obtain the recompiled binary, and use the target binary as the executable oracle to automatically generate differential test input.

[0047] Since the target binary itself is the executable truth of the original program, it can be used as an executable oracle without obtaining the original source code or manually writing test cases. Specifically, the decompiled source code generated by S2 is recompiled with the same compilation configuration as the target binary to obtain a recompiled binary corresponding to the functionality of the target binary; at the same time, a set of differential test inputs is automatically generated based on the input space of the target binary.

[0048] For example, for the array summation function mentioned above, the automatically generated set of difference test inputs includes a regular array [3,7,2], an empty array [], and an array containing negative values ​​[-1,5,-4], respectively covering the cases of regular values, boundary values, and mixed sign values. The generated difference test inputs are used to drive the target binary and the recompiled binary to run in subsequent steps.

[0049] By automatically generating differential test inputs using the target binary as an executable oracle, the verification of decompiled source code does not rely on manually written test cases, and the verification benchmark is the objective running behavior of the original program.

[0050] In some embodiments, automatically generating differential test inputs includes generating differential test inputs covering multiple execution paths through fuzzing. For example, for the array summation function mentioned above, fuzzing automatically generates array inputs of different lengths and value distributions by varying the array length and element values, thereby reaching different branches and boundary conditions within the function. Compared to a fixed, preset small amount of input, the input generated by fuzzing has broader coverage of execution paths, helping to increase the probability of triggering semantic deviations.

[0051] In some embodiments, automatically generating differential test inputs also includes differential test inputs that cover specific execution paths through symbolic execution. For example, for branches in a function that are only entered when array elements satisfy specific numerical relationships, fuzzing is difficult to reliably reach through random mutation, while symbolic execution directly constructs array inputs that can enter the branch by constraining the path conditions of that branch. Thus, the inputs solved by symbolic execution compensate for the insufficient coverage of deep paths in fuzzing.

[0052] S4. Run the target binary and the recompiled binary respectively under the same differential test input, perform differential comparison on the running behavior, and obtain deviation information representing semantic deviation.

[0053] Deviation information characterizes the semantic deviation of the recompiled binary from the target binary in terms of runtime behavior. Specifically, for each automatically generated differential test input, the target binary and the recompiled binary are input separately, and their respective runtime behaviors are collected and compared: if they are consistent, there is no deviation for that input; if they are inconsistent, the input and the corresponding behavioral difference are recorded as deviation information.

[0054] For example, for an array summation function, with the input array [3,7,2], the output of the target binary is 12, while the output of the recompiled binary obtained by recompiling the decompiled source code is 10. Since they are inconsistent, this difference in input and output is recorded as deviation information. With an empty input array [], both outputs are 0, indicating no deviation. When the behavior of both is consistent under all differential test inputs, the decompiled source code and the target binary are considered semantically equivalent, satisfying the convergence condition.

[0055] By performing black-box behavior differential analysis on the recompiled binary based on the original binary's execution behavior, the illusion of inconsistency with the original program's behavior introduced when generating decompiled source code from a large language model can be exposed as observable deviation information.

[0056] In some embodiments, the instruction-level alignment results of the target binary and the recompiled binary are also used to assist in locating semantic deviations during differential alignment. For example, when the deviation information of the array summation function already indicates that the two outputs are inconsistent, aligning the instruction sequences of the target binary and the recompiled binary can further indicate the instruction segments where behavioral differences occur, providing supplementary clues for locating the deviations. This instruction-level alignment corroborates subsequent semantic equivalence checks based on basic blocks.

[0057] In some embodiments, S4 further includes the following operations: performing an isolability determination on the function to be verified in the target binary to obtain an isolability determination result; in response to the isolability determination result being isolable, performing a differential alignment on the function to be verified; in response to the isolability determination result being non-isolated, promoting the function to be verified in the target binary and the recompiled binary to a unified intermediate representation (IR), performing a semantic equivalence check on the unified intermediate representation by basic blocks, and identifying basic blocks that fail the semantic equivalence check as deviated blocks, with the deviance information including the identifier of the deviated block. The above operations are described one by one below.

[0058] Isolability is used to determine whether the function to be verified can be constructed with its own input and its output collected independently. For example, the array summation function mentioned above only depends on its input parameters, does not access the global state, and has no side effects, so it is an isolable function and can be directly subjected to black-box difference comparison. However, for a function that reads and writes to the global counter or depends on external input and output during execution, it is impossible to construct its own input and collect its output stably, so it is a non-isolated function.

[0059] For non-isolated functions, since black-box difference analysis is insufficient to isolate execution and can only determine overall behavior consistency without pinpointing deviations, the function in both the target binary and the recompiled binary is elevated to a unified intermediate representation. Semantic equivalence checks are then performed on these intermediate representations at the basic block level, and the basic blocks that fail the check are identified as deviation blocks. For example, a function that reads and writes to the global counter during execution is considered non-isolated because its overall output cannot be stably captured. Elevating it to an intermediate representation and comparing it at the basic block level allows us to determine which basic block's computational semantics are inconsistent with the original function.

[0060] By splitting the flow between black-box differential and intermediate representation-level semantic equivalence checks based on isolation, functions that depend on global state or have side effects and cannot be executed in isolation can still complete fidelity checks and locate semantic deviations to specific basic blocks. Black-box differential and basic block-level semantic equivalence checks complement each other and jointly support the verification of decompiled results.

[0061] In some embodiments, after the deviation block is determined, the following operations are performed on the deviation block: based on the definition and usage relationship of each variable in the unified intermediate representation, the upstream basic block of the input consumed by the deviation block is generated backtracking to obtain the data dependency closure of the deviation block; the data dependency closure is used as the minimum re-decompile range when performing targeted correction on the decompiled source code.

[0062] The behavioral differences exhibited by deviation blocks may not necessarily stem from the deviation block itself, but rather from the upstream basic blocks that provide input to it. For example, in a vectorized loop code segment, if the accumulated result output by a certain basic block is incorrect, the root cause might lie in the upstream basic block responsible for initializing the accumulated variable. If only the deviation block itself is recomputed and corrected, but the deviations in the upstream variable definitions are not corrected, the corrected deviation block will still consume incorrect input, leading to repeated iterations and non-convergence.

[0063] Therefore, based on the definition and usage relationships of variables in the intermediate representation, the upstream basic blocks that consume the input are generated by backtracking from the deviation block. These upstream basic blocks and the deviation block together form a data dependency closure, which is used as the minimum re-decompilation range when performing targeted correction on the decompiled source code. Thus, the targeted correction covers the root cause of the deviation, avoiding invalid iterations caused by only correcting downstream blocks, and improving convergence efficiency.

[0064] In some embodiments, after the deviation block is determined, the semantic equivalence check result of the deviation block is converted into a structured correction hint. The structured correction hint contains a description of the difference between the expected computational semantics of the corresponding basic block of the target binary and the actual computational semantics of the corresponding basic block of the recompiled binary. The structured correction hint is injected into the large language model along with the deviation information.

[0065] When providing feedback to a large language model, simply informing it that a certain deviation block contains an error makes it difficult for the model to determine the specific nature of the error. Therefore, the semantic equivalence check results of the deviation block are converted into structured correction hints. These hints provide both the expected computational semantics of the target binary corresponding basic block and the actual computational semantics of the recompiled binary corresponding basic block, describing the differences between the two. For example, for the aforementioned accumulation deviation, the structured correction hints could indicate that the expected summation was for all array elements, but the last element was actually omitted. Thus, the large language model obtains a basis for correction targeting specific computational deviations, providing more targeted correction compared to simply being informed of an error.

[0066] S5. Inject the deviation information as feedback into the large language model, perform targeted correction on the decompiled source code, and repeat S3 to S5 until the deviation information satisfies the semantic equivalence convergence condition.

[0067] Targeted correction refers to making targeted modifications to the deviation-related parts of the decompiled source code based on the deviation information. The semantic equivalence convergence condition requires that the target binary and the recompiled binary exhibit consistent behavior under all differential test inputs. Specifically, the deviation information obtained in S4 is injected as feedback into the large language model, which then performs targeted correction on the decompiled source code. The corrected decompiled source code is then subjected to the recompilation and differential test input generation processes of S3, and the differential comparison process of S4, again to obtain a new round of deviation information. This process is repeated until the deviation information satisfies the semantic equivalence convergence condition.

[0068] For example, following the aforementioned array summation function, in the first round, because the decompiled source code omitted the accumulation of the last element, the recompiled binary output of input [3,7,2] is 10, which is inconsistent with the target binary output of 12. This deviation information is fed back to the large language model. Based on this, the large language model corrects the accumulation logic in the decompiled source code, recompiles and re-differentiates, and the output of input [3,7,2] is now 12. Moreover, the two behaviors are consistent under other differential test inputs. The deviation information meets the convergence condition, and the iteration ends.

[0069] During the iteration process, each round of feedback causes the decompiled source code to approach the target binary semantic equivalence in a direction. The process terminates when the behavior of all differential test inputs in a certain round is consistent, satisfying the convergence condition. By using deviation information as closed-loop feedback for targeted correction and iteration, the decompiled source code can still approach and converge to the target binary semantic equivalence round by round, even with compilation optimization and information loss.

[0070] In some embodiments, the iterative budget for performing targeted corrections on the decompiled source code is dynamically adjusted based on the block-level semantic distance of the deviating blocks. The block-level semantic distance measures the degree of deviation between the actual computational semantics and the expected computational semantics of a deviating block. Instead of applying a uniform fixed iteration cap to all deviating blocks, the iterative budget is dynamically allocated based on the block-level semantic distance of each deviating block: more iteration budget is allocated to deviating blocks with larger semantic distances, and less iteration budget is allocated to deviating blocks with smaller semantic distances. Thus, the allocation of the iterative budget matches the correction difficulty of each deviating block, avoiding wasted iterations on easily convergent blocks or premature termination on difficult-to-converge blocks.

[0071] In some embodiments, for non-convergent blocks in the deviation block that still do not satisfy the semantic equivalence convergence condition after directional correction, a candidate transformation iteration is performed. The candidate transformation iteration includes: determining candidate compiler optimization transformations for interpreting the non-convergent block from a pre-set inverse mapping library; generating candidate decompiled source code for the non-convergent block according to the inverse transformation constraints corresponding to the candidate compiler optimization transformations; applying the candidate compiler optimization transformations forward to the candidate decompiled source code to obtain a forward verification result; adopting the candidate decompiled source code in response to the forward verification result reproducing the assembly mode corresponding to the non-convergent block; and re-determining the candidate compiler optimization transformations from the inverse mapping library and repeating the candidate transformation iteration in response to the forward verification result failing to reproduce the assembly mode corresponding to the non-convergent block. The candidate transformation iteration is explained below in conjunction with the causes of non-convergent blocks.

[0072] After some basic blocks undergo high compiler optimization, their assembly code differs significantly in form from any unoptimized high-level language construct, making it difficult for large language models to converge even after repeated modifications. For example, the loop-vectorized code segment in the aforementioned array summation function is implemented as a vector instruction that processes multiple array elements at once, which differs significantly from the naive loop source code that accumulates elements one by one. When large language models repeatedly regenerate based on black-box deviations, they tend to oscillate on this block without convergence.

[0073] For such non-convergent blocks, the candidate transformation iteration does not blindly regenerate. Instead, it first determines a candidate compiler optimization transformation from the inverse mapping library to interpret the assembly pattern of the non-convergent block, for example, assuming that the assembly pattern is generated by loop vectorization. Then, it guides the large language model to generate candidate decompiled source code according to the inverse transformation constraints corresponding to the transformation, that is, it generates a naive loop source code that may produce the assembly pattern after applying loop vectorization. Subsequently, the same candidate compiler optimization transformation is applied forward to the candidate decompiled source code to check whether it reproduces the assembly pattern corresponding to the non-convergent block.

[0074] If the assembly pattern is reproduced after applying the forward hypothesis, the hypothesis is confirmed and the candidate decompiled source code is adopted; if it is not reproduced, the hypothesis is rejected, a new candidate compiler optimization transformation is determined from the inverse mapping library, and the above process is repeated. By combining reverse hypothesis with forward verification, the processing of difficult blocks is transformed from blind regeneration to evidence-based and verifiable approximation; compared with repeatedly regenerating difficult blocks with a fixed number of iterations, this mechanism improves the convergence of the closed loop on highly optimized code.

[0075] In some embodiments, the inverse mapping library stores the corresponding relationships between high-level language constructs and the assembly modes generated after the high-level language constructs are transformed by the compiler optimization set for a preset compiler optimization set, and uses the compiler type and optimization level as the index of the inverse mapping library; the compiler optimization set includes at least one of loop vectorization, loop unrolling, strength reduction, function inlining, common subexpression elimination and tail call optimization.

[0076] The inverse mapping library targets a set of predefined compiler optimizations. For each optimization, it stores the correspondence between the high-level language constructs and their corresponding assembly modes. For example, for loop vectorization, it stores the correspondence between the naive loop (a high-level language construct) and its vectorized instruction assembly mode. Since the same high-level language construct may produce different assembly modes under different compilers and optimization levels, using compiler type and optimization level as an index allows retrieval of the correspondence matching the compilation configuration of the target binary when determining candidate compiler optimization transformations. The library's construction provides an implementable basis for generating inverse transformation constraints in the aforementioned candidate transformation iterations.

[0077] In some embodiments, in response to the non-convergent block still not being adopted after the candidate transformation iteration reaches the preset iteration condition, the candidate decompiled source code with the smallest semantic deviation is selected from each candidate decompiled source code corresponding to the non-convergent block as the final decompiled source code of the non-convergent block, and the semantically equivalent input domain of the final decompiled source code is given; the semantically equivalent input domain is the set of differential test inputs that have been verified to make the target binary and the recompiled binary behavior equivalent.

[0078] For non-convergent blocks that fail to accept any candidate decompiled source code after candidate transformation iterations, to ensure the loop closure terminates rather than iterates indefinitely, after the candidate transformation iterations reach a preset iteration condition, the candidate decompiled source code with the smallest semantic deviation is selected as the final decompiled source code output, instead of discarding them all. Simultaneously, a semantically equivalent input domain for this final decompiled source code is provided, which is the set of inputs among the generated differential test inputs that make the target binary and the recompiled binary behave equivalently. For example, for the aforementioned vectorized code segment, if the final decompiled source code behaves identically to the target binary under most inputs and only inconsistent under a few boundary inputs, then the semantically equivalent input domain consists of those inputs that behave identically. Thus, the loop closure has a definite termination condition, and the semantically equivalent input domain provides the quantized validity boundary of the block's result within the verified range.

[0079] Combination Figure 4 As shown in the figure, this application embodiment also provides a decompilation system 100 based on a large language model. The decompilation system 100 includes a disassembly module 110, a generation module 120, a recompilation module 130, a differential comparison module 140, and a correction control module 150. The decompilation module 110 performs disassembly in step S1 of the aforementioned method to obtain assembly code and a control flow graph. The generation module 120 performs step S2, generating decompiled source code based on the assembly code and control flow graph using a large language model. The recompilation module 130 performs step S3, recompiling the decompiled source code to obtain a recompiled binary and automatically generating differential test input using the target binary as an executable oracle. The differential comparison module 140 performs step S4, running the target binary and the recompiled binary under the same differential test input and performing differential comparison on the running behavior to obtain deviation information. The correction control module 150 performs step S5, injecting the deviation information as feedback into the large language model to perform targeted correction on the decompiled source code, and triggering the recompilation module 130, the differential comparison module 140, and the correction control module 150 to execute repeatedly until the deviation information meets the semantic equivalence convergence condition. These modules work together to implement the aforementioned decompilation method based on a large language model.

[0080] This application also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the above-described decompilation method based on a large language model. This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the above-described decompilation method based on a large language model.

[0081] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A decompilation method based on a large language model, characterized in that, Includes the following steps: S1. Disassemble the target binary to obtain the assembly code and control flow graph; S2. Generate decompiled source code based on the assembly code and the control flow graph using a large language model; S3. Recompile the decompiled source code to obtain a recompiled binary, and use the target binary as the differential test input for the executable oracle. S4. Run the target binary and the recompiled binary respectively under the same differential test input, perform differential comparison on the running behavior, and obtain deviation information representing semantic deviation; S4 also includes the following operations: The isolationability of the function to be verified in the target binary is determined, and the isolationability determination result is obtained; In response to the isolability determination result being isolable, the differential comparison is performed on the function to be verified; In response to the isolation determination result being non-isolated, the target binary and the function to be verified in the recompiled binary are respectively promoted to a unified intermediate representation (IR). The unified intermediate representation is subjected to semantic equivalence checks on basic blocks. Basic blocks that fail the semantic equivalence check are identified as deviated blocks. The deviation information includes the identifier of the deviated block. S5. Inject the deviation information as feedback into the large language model, perform directional correction on the decompiled source code, and repeat steps S3 to S5 until the deviation information satisfies the semantic equivalence convergence condition; S5 further includes the following operation: for non-convergent blocks in the deviation block that still do not satisfy the semantic equivalence convergence condition after the directional correction, perform candidate transformation iteration, the candidate transformation iteration including: Determine candidate compiler optimization transformations from a pre-built inverse mapping library for interpreting the non-convergent block; According to the inverse transformation constraints corresponding to the candidate compiler optimization transformation, the candidate decompiled source code of the non-convergent block is generated; The candidate compiler optimization transformation is applied forward to the candidate decompiled source code to obtain a forward verification result; In response to the positive verification result reproducing the assembly mode corresponding to the non-converging block, the candidate decompiled source code is adopted; In response to the positive verification result failing to reproduce the assembly mode corresponding to the non-converging block, the candidate compiler optimization transformation is re-determined from the inverse mapping library and the candidate transformation iteration is repeated.

2. The decompilation method based on a large language model according to claim 1, characterized in that, After the deviation block is determined, the following operations are performed on the deviation block: Based on the definition and usage relationship of each variable in the unified intermediate representation, the upstream basic block of the input consumed by the deviation block is generated by backtracking, and the data dependency closure of the deviation block is obtained. The data dependency closure is used as the minimum re-decompile range when performing the targeted correction on the decompiled source code.

3. The decompilation method based on a large language model according to claim 1, characterized in that, After the deviation block is determined, the following operation is also included: converting the semantic equivalence check result of the deviation block into a structured correction hint, wherein the structured correction hint contains a description of the difference between the expected computational semantics of the corresponding basic block of the target binary and the actual computational semantics of the corresponding basic block of the recompiled binary; The structured correction prompts are injected into the large language model along with the deviation information.

4. The decompilation method based on a large language model according to claim 1, characterized in that, The inverse mapping library is paired and stored according to the correspondence between the high-level language construction and the assembly mode generated after the high-level language construction is transformed by the compiler optimization set, and the compiler type and optimization level are used as the index of the inverse mapping library. The compiler optimization set includes at least one of loop vectorization, loop unrolling, strength reduction, function inlining, common subexpression elimination, and tail call optimization.

5. The decompilation method based on a large language model according to claim 1, characterized in that, If the non-convergent block is still not adopted after the candidate transformation iteration reaches the preset iteration condition, the candidate decompiled source code with the smallest semantic deviation is selected from each candidate decompiled source code corresponding to the non-convergent block as the final decompiled source code of the non-convergent block, and the semantically equivalent input domain of the final decompiled source code is given. The semantically equivalent input domain is the set of differential test inputs that have been verified to make the target binary and the recompiled binary behaviorally equivalent.

6. A decompilation system based on a large language model, characterized in that, include: The disassembler module is configured to disassemble the target binary to obtain assembly code and a control flow graph. The generation module is configured to generate decompiled source code based on the assembly code and the control flow graph using a large language model. The recompiling module is configured to recompile the decompiled source code to obtain a recompiled binary, and use the target binary as the executable oracle to automatically generate differential test input; The differential comparison module is configured to run the target binary and the recompiled binary respectively under the same differential test input, perform differential comparison on the running behavior, and obtain deviation information representing semantic deviation; The differential comparison module is also configured to perform an isolability determination on the function to be verified in the target binary and obtain an isolability determination result; In response to the isolability determination result being isolable, the differential comparison is performed on the function to be verified; In response to the isolation determination result being non-isolated, the target binary and the function to be verified in the recompiled binary are respectively promoted to a unified intermediate representation (IR). The unified intermediate representation is subjected to semantic equivalence checks on basic blocks. Basic blocks that fail the semantic equivalence check are identified as deviated blocks. The deviation information includes the identifier of the deviated block. The correction control module is configured to inject the deviation information as feedback into the large language model, perform targeted correction on the decompiled source code, and trigger the recompilation module, the difference comparison module and the correction control module to be executed repeatedly until the deviation information satisfies the semantic equivalence convergence condition. The correction control module is further configured to perform candidate transformation iteration on non-convergent blocks in the deviation block that still do not satisfy the semantic equivalence convergence condition after the orientation correction. The candidate transformation iteration includes: determining candidate compiler optimization transformations from a preset inverse mapping library for interpreting the non-convergent blocks. According to the inverse transformation constraints corresponding to the candidate compiler optimization transformation, candidate decompiled source code of the non-convergent block is generated; the candidate compiler optimization transformation is applied forward to the candidate decompiled source code to obtain a forward verification result; in response to the forward verification result reproducing the assembly mode corresponding to the non-convergent block, the candidate decompiled source code is adopted; in response to the forward verification result not reproducing the assembly mode corresponding to the non-convergent block, the candidate compiler optimization transformation is re-determined from the inverse mapping library and the candidate transformation iteration is repeated.

7. A computer device comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the decompilation method based on a large language model as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the decompilation method based on a large language model as described in any one of claims 1 to 5.

Images