A code heterogenization processing method, apparatus, device and medium

Abstract

The application relates to the computer technical field and discloses a code isomerization processing method, device, equipment and medium, wherein the method comprises the following steps: acquiring source code to be compiled; receiving a user-configured isomerization strategy parameter, wherein the isomerization strategy parameter comprises a specified target function and an isomerization operator applied to the target function; converting the source code into an original intermediate representation; performing differential reconstruction on a function unit corresponding to the target function in the original intermediate representation by using the isomerization operator to generate a reconstructed intermediate representation; performing isomerization evaluation on the reconstructed intermediate representation and the original intermediate representation; and compiling the reconstructed intermediate representation into an executable file of a target platform based on an evaluation result. The technical scheme provided by the application can realize automatic and diversified compilation of software.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and medium for code heterogeneity processing. Background Technology

[0002] Mimicry defense relies on functionally equivalent heterogeneous multi-executor architectures to reduce the common attack surface. Heterogeneous multi-core processors provide a natural heterogeneous foundation at the hardware level. However, if each core runs the same binary, the control flow and data flow of all executables are completely identical. Attackers can reuse a single vulnerability payload to breach all executables, completely negating the advantage of hardware heterogeneity. In existing software heterogeneity solutions, the cost of manual heterogeneous development and iteration increases linearly with the number of executables. Automated heterogeneity can only achieve coarse-grained spatial randomization, which cannot change the program control flow topology and lacks a quantifiable variability assessment mechanism. At the same time, the multi-executor synchronization requirements of mimicry defense are easily deleted by general-purpose compilers, and the cross-architecture adaptation cost is extremely high. Existing general-purpose compilers cannot support the automated software heterogeneity and synchronization point processing requirements in mimicry defense scenarios, becoming the core bottleneck restricting its implementation.

[0003] Therefore, how to solve the problem of the lack of deep control flow transformation and quantitative evaluation mechanism in existing software heterogeneity technology, and the inability of general compilers to automatically handle the mimicry defense cross-architecture synchronization logic, which makes it difficult to achieve high reliability software heterogeneity in heterogeneous multi-core systems at low cost, is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] This application provides a code heterogeneity processing method, apparatus, device, and medium, which solves the technical problems of existing software heterogeneity technologies lacking deep control flow transformation and quantitative evaluation mechanisms, and the inability of general compilers to automatically handle mimicry defense cross-architecture synchronization logic, making it difficult to achieve high-reliability software heterogeneity at low cost in heterogeneous multi-core systems. It achieves the technical effect of realizing automated and diversified compilation of software.

[0005] To achieve the above objectives, the main technical solutions adopted in this application include: In a first aspect, embodiments of this application provide a code heterogeneity processing method, the method comprising: Obtain the source code to be compiled; Receive heterogeneity strategy parameters configured by the user, wherein the heterogeneity strategy parameters include a specified objective function and a heterogeneity operator applied to the objective function; The source code is converted into a raw intermediate representation. The function units in the raw intermediate representation that correspond to the target function are reconstructed using the heterogeneity operator to generate a reconstructed intermediate representation. The reconstructed intermediate representation and the original intermediate representation are subjected to heterogeneity evaluation, and the reconstructed intermediate representation is compiled into an executable file for the target platform based on the evaluation results.

[0006] In one implementation, the heterogeneity operator includes one or more combinations of control flow flattening, invalid control flow, instruction substitution, base block splitting, string obfuscation, null instruction insertion, and function copying.

[0007] In one implementation, the heterogeneity strategy parameters further include strength parameters set for each heterogeneity operator, the strength parameters including the number of iterations, trigger probability percentage, number of cuts, or number of copies.

[0008] In one implementation, converting the source code into a raw intermediate representation includes: The source code is front-end compiled by a compiler to convert the synchronization marks in the source code into an intermediate representation instruction sequence, thereby obtaining the original intermediate representation containing the intermediate representation instruction sequence.

[0009] In one implementation, the step of performing differential reconstruction on the function units corresponding to the objective function in the original intermediate representation using the heterogeneity operator to generate a reconstructed intermediate representation includes: The intermediate representation instruction sequence is identified in the original intermediate representation, and the intermediate representation instruction sequence is added as a synchronization control point to the reconstruction whitelist; Read the intensity parameter configured for the objective function in the heterogeneity strategy parameters, and use the heterogeneity operator to perform differential reconstruction on the instructions in the original intermediate representation except for the reconstruction whitelist according to the transformation intensity determined by the intensity parameter, so as to generate the reconstructed intermediate representation.

[0010] In one implementation, the step of using the heterogeneity operator to perform differential reconstruction on the instructions in the original intermediate representation other than the reconstruction whitelist according to the transformation intensity determined by the intensity parameter, and generating the reconstructed intermediate representation, includes: Traverse the function units in the original intermediate representation and match the function units with the target function to filter out the target function units to be heterogeneous; Obtain multiple heterogeneous operators configured in the objective function unit, and determine the predetermined execution order of each heterogeneous operator; According to the predetermined execution order, each of the heterogeneous operators is called sequentially to transform the instructions in the target function unit, and the transformation intensity is controlled according to the intensity parameter during the execution process to generate the reconstructed intermediate representation.

[0011] In one implementation, the step of performing a heterogeneous evaluation on the reconstructed intermediate representation and the original intermediate representation, and compiling the reconstructed intermediate representation into an executable file for the target platform based on the evaluation results, includes: Determine a first similarity index to characterize the reconstructed intermediate representation and the original intermediate representation at the intermediate representation structure level; Determine a second similarity index to characterize the reconstructed intermediate representation and the original intermediate representation at the compiled binary code level; If the first similarity index is less than the first preset threshold and the second similarity index is less than the second preset threshold, the reconstructed intermediate representation is compiled into an executable file for the target platform.

[0012] Secondly, embodiments of this application provide a code heterogeneity processing apparatus, the apparatus comprising: The code acquisition unit is used to acquire the source code to be compiled. A policy receiving unit is used to receive heterogeneous policy parameters configured by the user, wherein the heterogeneous policy parameters include a specified objective function and a heterogeneous operator applied to the objective function; The differential reconstruction unit is used to convert the source code into an original intermediate representation, and to perform differential reconstruction on the function units in the original intermediate representation that correspond to the target function using the heterogeneity operator to generate a reconstructed intermediate representation; An evaluation compilation unit is used to perform heterogeneous evaluation on the reconstructed intermediate representation and the original intermediate representation, and compile the reconstructed intermediate representation into an executable file for the target platform based on the evaluation results.

[0013] Thirdly, embodiments of this application provide a computer device, including: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes these computer instructions to perform the code heterogeneity processing method described above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the code heterogeneity processing method described above.

[0015] The technical solutions provided by one or more embodiments of this application provide a multi-language compatible original input foundation for heterogeneous reconstruction by acquiring the source code to be compiled; by receiving heterogeneous strategy parameters configured by the user, the precise delineation of the target function and the flexible configuration of heterogeneous operators are achieved, realizing quantitative control of on-demand differentiated reconstruction and avoiding performance loss caused by full obfuscation; by converting the source code into a raw intermediate representation and calling the heterogeneous operators to perform differentiated reconstruction of the target function units, deep variation of the code control flow topology and instruction timing is achieved, generating a reconstructed intermediate representation with highly heterogeneous characteristics; by evaluating the heterogeneity quantification index of the reconstructed intermediate representation, the correctness and heterogeneity of the reconstructed code are ensured to meet the standards, and based on the evaluation results, it is decided whether to compile the reconstructed intermediate representation into an executable file for the target platform, so that the heterogeneity of the final output executable file can be quantitatively controlled, thereby significantly improving the software's anti-attack capability in the mimicry defense scenario while ensuring the stability of program operation. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a code heterogeneity processing method provided in this application embodiment; Figure 2 A flowchart for converting source code into a raw intermediate representation is provided for embodiments of this application; Figure 3 A flowchart for generating the reconstructed intermediate representation provided in this application embodiment; Figure 4 A flowchart of step S533 provided in the embodiments of this application; Figure 5 A flowchart of step S7 provided in an embodiment of this application; Figure 6 This is a diagram of a heterogeneous multi-core microcontroller architecture provided in Embodiment 1 of this application; Figure 7 This is a schematic diagram of the graphical user interface provided in Embodiment 1 of this application; Figure 8 A block diagram of a code heterogeneity processing apparatus provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] Mimicry defense theory, as a core research direction in the field of intrinsic security, relies on the fundamental premise of constructing a heterogeneous multi-executor operating environment with functional equivalence. This involves reducing the common attack surface through the inherent differences between different executables, preventing attackers from simultaneously breaching all executables with a single attack payload, thereby significantly increasing the cost of attacks. Currently, heterogeneous multi-core processor systems are the core hardware carrier supporting the implementation of mimicry defense. By integrating processor cores with different instruction set architectures and microarchitectures such as ARM, MIPS, and RISC-V, they naturally achieve hardware-level heterogeneity, providing the basic execution environment for mimicry defense.

[0020] However, relying solely on hardware heterogeneity cannot fully leverage the security advantages of mimicry defense: if software running on different processor cores is an identical binary copy, then the control flow logic, data flow structure, and triggering conditions for potential hidden functions of all executables are completely identical. Attackers only need to exploit vulnerabilities in a specific version of the software and construct attack payloads, which can then be directly reused across all executables, completely negating the attack surface differences caused by hardware heterogeneity. Therefore, further enhancing software heterogeneity while ensuring functional equivalence is a necessary requirement for unlocking the security potential of heterogeneous multi-core systems. The compiler, as the core tool linking source code and binary executables, is the optimal technical path to achieve automated heterogeneous software compilation.

[0021] Currently, software heterogeneity technologies are mainly divided into two paths: manual heterogeneity and automated heterogeneity. However, both paths have significant drawbacks that make them difficult to meet engineering implementation requirements. Manual heterogeneity requires multiple R&D teams to develop multiple functionally equivalent software versions in parallel. The R&D cost increases linearly with the number of executables, and subsequent feature iterations require simultaneous modifications by multiple teams, which easily leads to inconsistencies and makes large-scale promotion impractical. Existing automated heterogeneity technologies (such as Address Space Layout Randomization (ASLR)) can only achieve coarse-grained spatial randomization of heap, stack, and shared library base addresses. They cannot change the program's control flow topology (such as branch judgment order and loop unrolling logic) or adjust the timing of instruction execution. Attackers can complete cross-executor attacks simply by adjusting the offset of the vulnerability exploit, failing to provide sufficient heterogeneity. More importantly, existing automated heterogeneity technologies lack quantifiable variability analysis and measurement mechanisms. Developers cannot intuitively assess whether the heterogeneous software meets functional equivalence requirements or whether the degree of heterogeneity reaches the security threshold, further limiting its application in high-security scenarios.

[0022] In addition to the need for software heterogeneity, heterogeneous multi-core systems designed for mimicry defense also have unique synchronization requirements: during the parallel operation of multiple execution units, state synchronization is needed to support result adjudication, fault cleaning, and state rollback processes. That is, when an execution unit fails, it needs to roll back to a previous synchronization point and re-execute. The efficiency and correctness of this process directly determine the availability and reliability of the system. Current conventional synchronization solutions rely on manually inserting synchronization keywords (such as synchronization barriers and checkpoint markers) into the source code. However, general-purpose compilers do not recognize this type of business-specific synchronization logic: on the one hand, the compiler may misjudge synchronization keywords as redundant code and optimize and delete them, disrupting the state consistency of the execution units; on the other hand, the context storage rules and register mapping logic of processor cores with different instruction set architectures are completely different. If developers rely on manually inserting synchronization points, adaptation code needs to be written separately for each architecture, significantly increasing development costs and easily introducing cross-architecture state inconsistencies. Existing general-purpose compilers completely lack the ability to automatically identify and handle synchronization points specific to this mimicry defense scenario, and cannot adapt to the operational requirements of heterogeneous multi-core systems.

[0023] In summary, the lack of deep control flow transformation and quantitative evaluation mechanisms in existing software heterogeneity technologies, as well as the inability of general-purpose compilers to automatically handle mimicry defense cross-architecture synchronization logic, makes it difficult to achieve high-reliability software heterogeneity at low cost in heterogeneous multi-core systems. These are the technical problems that urgently need to be solved.

[0024] According to an embodiment of this application, a code heterogeneity processing method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] This embodiment provides a method for handling code heterogeneity. Figure 1 A flowchart of a code heterogeneity processing method provided in this application embodiment is shown below. Figure 1 As shown, the process includes the following steps: Step S1: Obtain the source code to be compiled.

[0026] Specifically, it receives source code to be compiled from the user or an external build system. The source code to be compiled is usually a program file written in a high-level programming language (such as C, C++, Rust, etc.).

[0027] Step S3: Receive the heterogeneity strategy parameters configured by the user. The heterogeneity strategy parameters include the specified objective function and the heterogeneity operators applied to the objective function.

[0028] Specifically, after acquiring and parsing the source code to be compiled, a human-computer interaction interface or configuration file parsing module is provided to receive heterogeneity strategy parameters configured by the user. These heterogeneity strategy parameters are the core configuration set controlling the entire heterogeneity reconstruction process.

[0029] Specifically, the heterogeneity strategy parameters explicitly specify the target functions that need to be differentiated and refactored. Users can select one or more target functions from the set of functions corresponding to the source code to be compiled by means of function name, symbol table index, or specific code tags.

[0030] Meanwhile, the heterogeneity strategy parameters also specify the heterogeneity operators applied to the target function. Users can select one or more heterogeneity operators (such as control flow flattening, invalid control flow, instruction substitution, basic block splitting, string obfuscation, null instruction insertion, and function copying) from the pre-configured heterogeneity operator pool according to the security requirements of the mimicry defense scenario, and bind them to the corresponding target function.

[0031] In a preferred embodiment, the heterogeneity operator includes one or more combinations of control flow flattening, invalid control flow, instruction substitution, base block splitting, string obfuscation, empty instruction insertion, and function copying.

[0032] According to its design principle, the heterogeneity operator acts on different levels of the original intermediate representation to achieve a deep-level differentiated reconstruction of the objective function unit. Specifically: Heterogeneity operators operating at the instruction sequence level include instruction substitution, string obfuscation, and null instruction insertion. Instruction substitution replaces binary operation instructions in the intermediate representation with functionally equivalent complex instruction sequences. For example, addition instructions can be randomly selected from multiple equivalent schemes: a=b-(-c), a=-(-b+(-c)), or a multi-step sequence can be constructed by introducing a random constant r such as a=b+r; a=a+c; a=ar. Subtraction and bitwise operations also have similar sets of equivalent schemes. The strength parameter of this operator is the number of iterations (a positive integer, controlling the number of repetitions for traversal and replacement). String obfuscation operators are used to encrypt or split string constants within the target function unit; null instruction insertion operators are used to insert null operation instructions (such as NOP instructions) that do not affect the program's execution logic into the instruction gaps within the target function unit. For example, for each instruction, the insertion of 1 to 5 null operation instructions is determined based on the trigger probability percentage (ranging from 0 to 100%, with a default of 30%) to increase code size and instruction distribution diversity.

[0033] Heterogeneity operators operating at the control flow graph level include control flow flattening, invalid control flow, and basic block cutting. Among them, the control flow flattening operator eliminates the branching hierarchy of the original control flow by incorporating all basic blocks within a function into a flattened structure centered on switch-dispatch. The specific execution steps are as follows: Traverse all basic blocks of the target function unit (skip the function if there is an exception handling basic block), and store all basic blocks except the entry basic block into the sequence; create a switch state variable and its randomized initial value in the entry basic block, and create two new basic blocks: the main loop entry block and the loop end block; create a switch instruction in the loop entry block, assign a randomized perturbation conditional branch (Case) label to each basic block in the sequence, and move the basic block body into the corresponding conditional branch (Case) branch; traverse each basic block, for blocks ending with an unconditional jump, replace the jump target with the corresponding conditional branch (Case) label and update the state variable; for blocks ending with a conditional branch, map the branch condition to a select instruction, and update the state variable by selecting the labels of the two target branches based on the select result; finally, call the stack repair function to handle Phi nodes and cross-basic block references caused by changes in control flow. This operator does not have a strength parameter; it only uses the function name to identify the scope of action.

[0034] The invalid control flow operator creates dead code paths in the control flow graph that do not affect semantics by creating copies of basic blocks and inserting always-true conditional branches. The specific execution steps are as follows: Collect all basic blocks of the target function unit; randomly select some basic blocks as processing targets based on the trigger probability percentage (ranging from 0 to 100%, default 30%); for each selected basic block, split it into two basic blocks after a non-Phi instruction; copy the latter basic block to create a differentiated copy, and insert random equivalent transformations into the copy's instructions to differentiate it from the original block; create a always-true conditional comparison instruction in the former basic block, using this condition to create a conditional branch so that if the condition is true, it enters the original block, and if false, it enters the copy block; the copy block ends and jumps back to the original block; finally, replace the always-true condition with a complex opaque predicate expression. The strength parameters of this operator include the trigger probability percentage (controlling the proportion of selected basic blocks) and the number of iterations (controlling the number of repetitions applied to the entire function).

[0035] In addition, the function copy operator involves both function call relationships and control flow transformations. It is used to generate multiple functionally equivalent copies of the target function unit (the number of copies ranges from 2 to 4), create a wrapper function to take over the original name, and generate random numbers in the wrapper function by a runtime random function and modulo the number of copies. It then randomly selects which copy to call using a switch-case structure.

[0036] In the actual compilation process, users can configure one or more combinations of the above heterogeneous operators in the heterogeneous strategy parameters, and call these heterogeneous operators sequentially in a predetermined execution order to transform the target function unit, thereby generating a reconstructed intermediate representation with different control flow topology and instruction timing.

[0037] It should be noted that the aforementioned heterogeneity operators (including control flow flattening, invalid control flow, instruction substitution, basic block splitting, string obfuscation, null instruction insertion, and function copying) are all implemented based on compiler transformation techniques known in the art (e.g., based on the mature transformation mechanism provided in the open-source project Obfuscator-LLVM). This embodiment does not modify the underlying transformation algorithms within the aforementioned heterogeneity operators themselves. Instead, it uses heterogeneity strategy parameters and strength parameters to uniformly schedule and quantize the scope, execution order, and transformation intensity of each known heterogeneity operator, thereby achieving the expected differentiated reconstruction effect.

[0038] In a preferred embodiment, the heterogeneity strategy parameters further include strength parameters set for each heterogeneity operator, including the number of iterations, trigger probability percentage, number of cuts, or number of copies.

[0039] To achieve fine-grained control over the differential reconstruction process of the objective function units, corresponding intensity parameters are independently configured for each heterogeneity operator through heterogeneity strategy parameters. The specific meanings and functions of each intensity parameter are as follows: The loop count, a positive integer, controls the number of iterations in which the corresponding heterogeneous operator performs transformation operations on the target function unit. For example, in an instruction substitution operator, the loop count determines the number of iterations in which instructions are traversed and replaced; in an invalid control flow operator, the loop count determines the number of iterations applied to the entire function. The larger the loop count, the deeper the code obfuscation.

[0040] The trigger probability percentage ranges from 0 to 100% and is used to control the proportion of the corresponding heterogeneous operator selected during transformation. For example, in the invalid control flow operator, the trigger probability percentage controls the proportion of basic blocks selected for inserting spurious control flow; in the null instruction insertion operator, the trigger probability percentage controls the proportion of instructions selected for inserting null operation instructions. In the function copy operator, the trigger probability percentage also controls the proportion of function units selected for copying and random call reconstruction.

[0041] The number of cuts ranges from 2 to 10 and is specifically applied to the basic block cutting operator. This index controls the number of parts into which the original basic block within the objective function unit is divided. By randomly selecting multiple cutting positions, the number of basic blocks and the complexity of jump relationships are increased.

[0042] The copy number ranges from 2 to 4 and is specifically applied to function copy operators. This metric controls the number of functionally equivalent copies generated by copying the target function unit. By creating a wrapper function and randomly selecting which copy to call at runtime, heterogeneity at the function call level is achieved.

[0043] In actual execution, each heterogeneous operator strictly performs the transformation according to the transformation intensity determined by the intensity parameters configured in the heterogeneous strategy parameters, thereby generating reconstructed intermediate representations with different control flow topologies and instruction timings.

[0044] Step S5: Convert the source code into the original intermediate representation. For the function units in the original intermediate representation that correspond to the target function, use the heterogeneity operator to perform differential reconstruction to generate the reconstructed intermediate representation.

[0045] Specifically, after obtaining the source code to be compiled, it is first analyzed by the compiler frontend and converted into a raw intermediate representation (such as LLVM IR) independent of the underlying hardware platform. Then, the heterogeneity strategy parameters are parsed to accurately locate the function unit in the raw intermediate representation corresponding to the target function. For this function unit, the heterogeneity operators specified in the heterogeneity strategy parameters are called sequentially according to a predetermined execution order to perform differential reconstruction. During this process, each heterogeneity operator performs transformations strictly according to the transformation intensity determined by the strength parameters configured in the heterogeneity strategy parameters (such as the number of loops, trigger probability percentage, number of cuts, or number of copies), thereby changing the control flow topology and instruction timing of the function unit, ultimately generating a reconstructed intermediate representation with highly heterogeneous characteristics. This reconstructed intermediate representation, while maintaining complete equivalence to the original functionality of the target function, achieves deep mutation of the code structure, providing a data foundation for subsequent compilation and quantitative evaluation.

[0046] Step S7: Perform heterogeneity evaluation on the reconstructed intermediate representation and the original intermediate representation, and compile the reconstructed intermediate representation into an executable file for the target platform based on the evaluation results.

[0047] To verify the effectiveness of the differentiated refactoring and ensure the correctness of the program, a rigorous heterogeneity evaluation is performed after generating the intermediate refactoring representation. Specifically, the functional equivalence of the refactored intermediate representation and the original intermediate representation is first verified to ensure that the code transformed by each heterogeneity operator is completely consistent with the objective function in terms of execution logic and output results. Based on the confirmation of functional equivalence, quantitative indicators of the refactored intermediate representation are further extracted and calculated to evaluate its degree of heterogeneity. These quantitative indicators may include code volume expansion rate, the rate of change of the number of nodes and edges in the control flow graph (CFG), and the complexity of instruction execution paths.

[0048] The calculated quantitative indicators are compared with preset evaluation thresholds. If the reconstructed intermediate representation meets the preset evaluation requirements (i.e., the degree of heterogeneity reaches the expected level and the functionality remains equivalent), the differentiated reconstruction is deemed valid. Subsequently, the compiler backend of the target platform is invoked to perform backend processing such as instruction selection, register allocation, and code generation on the qualified reconstructed intermediate representation, and finally compile and output an executable file suitable for the target platform. If the evaluation fails, an exception log can be recorded or a re-transformation mechanism can be triggered to ensure that the final generated executable file has both high heterogeneity security features and reliable runtime stability.

[0049] This embodiment provides a code heterogeneity processing method. By acquiring the source code to be compiled, it provides a multi-language compatible original input foundation for heterogeneous reconstruction. By receiving user-configured heterogeneity strategy parameters, it achieves precise targeting of the target function and flexible configuration of heterogeneity operators, realizing quantitative control of on-demand differentiated reconstruction and avoiding performance loss caused by full obfuscation. By converting the source code into a raw intermediate representation and calling the heterogeneity operator to perform differentiated reconstruction of the target function unit, it achieves deep variation of the code control flow topology and instruction timing, generating a reconstructed intermediate representation with highly heterogeneous characteristics. By evaluating the reconstructed intermediate representation with heterogeneity quantification indicators, it ensures that the correctness and heterogeneity of the reconstructed code meet the standards, and decides whether to compile the reconstructed intermediate representation into an executable file for the target platform based on the evaluation results. This allows for quantitative control of the heterogeneity of the final output executable file, thereby significantly improving the software's anti-attack capability in mimicry defense scenarios while ensuring program stability.

[0050] Figure 2 The flowchart provided for converting source code into a raw intermediate representation, as described in this application embodiment, may include the following steps: Step S511: Compile the source code using the compiler front-end, convert the synchronization marks in the source code into an intermediate representation instruction sequence, and obtain the original intermediate representation containing the intermediate representation instruction sequence.

[0051] Specifically, during the compilation of source code into a raw intermediate representation (e.g., LLVM IR), the compiler automatically identifies and parses synchronization markers in the source code. After the synchronization markers are expanded during the preprocessing stage, the label address record structure contained within them (e.g., the goto*(addr) statement in C / C++) is directly converted by the compiler frontend into indirect multi-branch jump instructions in the raw intermediate representation (e.g., the indirectbr instruction in LLVM IR). At the same time, the jump target address of this jump instruction is recorded by the compiler frontend as a list of jump target addresses (e.g., represented as the indirectbr i8* %addr,[label %bb1,label %bb2,...] structure) through an address acquisition mechanism (e.g., LLVM's blockaddress mechanism).

[0052] Through the natural compilation transformation of the compiler front-end described above, the synchronization markers in the source code are completely transformed into an intermediate representation instruction sequence. This intermediate representation instruction sequence is retained in the original intermediate representation and serves as the basis for identifying synchronization control points and adding them to the refactoring whitelist during subsequent heterogeneous refactoring, thereby ensuring that the synchronization logic is not accidentally deleted or destroyed during compilation.

[0053] This embodiment performs front-end compilation of the source code using a compiler. By leveraging the compiler's automatic identification and parsing capabilities for synchronization markers, the synchronization markers and their internal tag address record structures in the source code are completely transformed into indirect multi-branch jump instructions and corresponding jump target address lists in the original intermediate representation. This allows synchronization control points to be preserved and explicitly expressed at the intermediate representation level, providing a identifiable basis for accurately identifying synchronization control points and including them in the reconstruction whitelist during subsequent heterogeneous reconstruction. This effectively prevents synchronization logic from being accidentally deleted or destroyed during compilation and subsequent differentiated reconstruction.

[0054] Figure 3 The flowchart for generating the reconstructed intermediate representation provided in this application embodiment may include the following steps: Step S531: Identify the intermediate representation instruction sequence in the original intermediate representation and add the intermediate representation instruction sequence as a synchronization control point to the reconstruction whitelist.

[0055] Specifically, after generating the original intermediate representation and before performing differential refactoring, all function units in the original intermediate representation are traversed first. For each function unit, the intermediate representation instruction sequence is searched and identified within its internal instruction sequence. As described in step S511 above, the intermediate representation instruction sequence is naturally transformed from the synchronization marks in the source code at the compiler front end. Therefore, during identification, instruction sequences with specific characteristic structures are matched (e.g., instruction combinations centered on indirect multi-branch jump instructions and associated with a list of jump target addresses).

[0056] When an intermediate representation instruction sequence is successfully identified, it is determined as a synchronization control point in the mimicry defense scenario. Subsequently, this intermediate representation instruction sequence is added to the reconstruction whitelist. This reconstruction whitelist provides protection during subsequent heterogeneous reconstruction processes, ensuring that these critical logics for multi-core state synchronization are not mistakenly deleted or corrupted by heterogeneous operators, thereby guaranteeing the correctness of state synchronization in heterogeneous multi-core systems.

[0057] Step S533: Read the intensity parameter configured for the objective function in the heterogeneity strategy parameters, and use the heterogeneity operator to perform differential reconstruction on the instructions in the original intermediate representation except for the reconstruction whitelist according to the transformation intensity determined by the intensity parameter, so as to generate the reconstructed intermediate representation.

[0058] Specifically, using heterogeneous operators configured in the target function unit, instructions in the original intermediate representation, excluding those in the reconstruction whitelist, are differentially reconstructed strictly according to the transformation intensity determined by the intensity parameters. Specifically, each heterogeneous operator operates at either the instruction sequence level or the control flow graph level according to its design: operators such as instruction substitution, empty instruction insertion, and string obfuscation traverse the instructions within the function; operators such as control flow flattening, invalid control flow, and basic block splitting change the instruction execution path by altering the organization of basic blocks or inserting new branch paths; the function copying operator involves transformations at both the function call relationship and control flow levels. During the above transformations, it is checked in real time whether the current instruction is in the reconstruction whitelist. If it is in the whitelist, it is skipped directly, ensuring that the synchronization control point is preserved in its original state. After each heterogeneous operator has been applied sequentially, the final output is the reconstructed intermediate representation after differential reconstruction.

[0059] This embodiment accurately identifies the intermediate representation instruction sequence transformed from synchronization markers in the original intermediate representation and adds it as a synchronization control point to the reconstruction whitelist. This establishes a clear protection boundary for subsequent heterogeneous reconstruction, ensuring that the key logic of multi-core state synchronization in the mimicry defense scenario is not accidentally deleted or destroyed. On this basis, the strength parameters configured for the target function are read, and each heterogeneous operator is used to perform differentiated reconstruction of the instructions in the original intermediate representation except for those in the reconstruction whitelist, strictly according to the determined transformation strength. During the reconstruction process, the synchronization control points in the whitelist are checked and skipped in real time. Thus, while achieving deep mutation of asynchronous code regions at the instruction sequence level and control flow graph level and generating a reconstruction intermediate representation with highly heterogeneous characteristics, the original semantics of the synchronization control points are completely preserved, taking into account both the code heterogeneity strength and the correctness of multi-core synchronization.

[0060] Figure 4 The flowchart for step S533 provided in the embodiments of this application may include the following steps: Step S5331: Traverse the function units in the original intermediate representation and match the function units with the target function to filter out the target function units to be heterogeneous.

[0061] Specifically, when traversing all function units in the original intermediate representation, the name attribute of the current function unit is obtained and compared with the target function identifier configured in the heterogeneity strategy parameters using a string prefix comparison. When the name attribute of the function unit matches the target function identifier, the function unit is selected as the target function unit to be heterogeneously transformed; if the function unit does not match, or does not appear in the heterogeneity strategy parameters, it is determined that the function unit does not need to be heterogeneously transformed, and it is skipped and remains unchanged. Through the above matching mechanism, the range of code that needs to be diversified is accurately located.

[0062] Step S5333: Obtain multiple heterogeneous operators configured in the objective function unit and determine the predetermined execution order of each heterogeneous operator.

[0063] Specifically, after selecting the target function unit to be heterogeneous, multiple heterogeneous operators configured for that target function unit are read from the heterogeneity strategy parameters. The predetermined execution order of each heterogeneous operator is determined by the compiler's PassManager according to the order in which the operators are registered, and this predetermined execution order is fixed. Users can indirectly control the set of operators applied to the current compilation and their actual execution order by selecting only the desired subset of heterogeneous operators in the heterogeneity strategy parameters.

[0064] Step S5335: According to the predetermined execution order, each heterogeneous operator is called sequentially to transform the instructions in the target function unit, and the transformation intensity is controlled according to the intensity parameter during the execution process to generate the reconstructed intermediate representation.

[0065] Specifically, according to the predetermined execution order, each heterogeneous operator is invoked sequentially to act on the target function unit. Each heterogeneous operator transforms the instructions within the target function unit according to its design: operators such as instruction substitution, empty instruction insertion, and string obfuscation operate at the instruction sequence level, directly traversing the instructions within the target function unit for operation; operators such as control flow flattening, invalid control flow, and basic block splitting operate at the control flow graph level, indirectly changing the instruction execution path by altering the organization of basic blocks or inserting new branch paths; and the function copying operator involves transformations at both the function call relationship and control flow levels.

[0066] During execution, the transformation intensity is strictly controlled according to the intensity parameters configured in the heterogeneity strategy parameters. The intensity parameters specifically include: probability (ranging from 0 to 100%, used to control the proportion of instructions or basic blocks selected for transformation), number of iterations (a positive integer, used to control the number of repetitions of the transformation operation), number of cuts (ranging from 2 to 10, used to control the number of parts a basic block is cut into), and number of copies (ranging from 2 to 4, used to control the number of function copies generated). After each heterogeneity operator has been applied sequentially, the final output is the reconstructed intermediate representation after differential reconstruction.

[0067] This embodiment precisely selects the target function units to be heterogeneous by traversing the function units in the original intermediate representation and performing string prefix matching between the function units and the target functions in the heterogeneity strategy parameters. At the same time, it skips non-target functions to keep them unchanged, thereby precisely limiting the scope of heterogeneous reconstruction code to the user-specified functions and avoiding the performance loss caused by full obfuscation. On this basis, multiple heterogeneous operators configured in the target function units are obtained, and the predetermined execution order of each operator is determined. The operators are called in sequence according to the predetermined execution order to perform differential transformation on the instructions at the instruction sequence level, control flow graph level, and function call level in the target function units. The transformation intensity is strictly controlled by quantitative parameters such as probability, number of loops, number of cuts, and number of copies. Finally, under the premise of maintaining functional equivalence, a highly heterogeneous reconstruction intermediate representation with different control flow topology and instruction timing is generated.

[0068] Figure 5 The flowchart for step S7 provided in the embodiments of this application may include the following steps: Step S71: Determine a first similarity index to characterize the reconstructed intermediate representation and the original intermediate representation at the intermediate representation structure level.

[0069] After generating the reconstructed intermediate representation, a structural comparison analysis is first performed between the reconstructed intermediate representation and the original intermediate representation. Specifically, the control flow graph (CFG) features of both are extracted and compared to calculate a first similarity index. The first similarity index characterizes the degree of difference between the two at the intermediate representation structural level, and its specific quantification methods include, but are not limited to: the rate of change of the number of control flow graph nodes (basic blocks), the rate of change of the number of control flow graph edges (jump relationships), and the edit distance of the control flow topology (such as the number of loops and the depth of branch nesting). The lower the value of the first similarity index, the more deeply the control flow structure of the reconstructed intermediate representation is destroyed and reconstructed from the compiler's perspective.

[0070] Step S73: Determine a second similarity metric to characterize the reconstructed intermediate representation and the original intermediate representation at the level of compiled binary code.

[0071] To assess the resistance to reverse engineering of the final generated file, the reconstructed intermediate representation and the original intermediate representation are compiled into machine code for the target platform by a compiler backend. A second similarity metric is then calculated at the binary code level. This second similarity metric characterizes the degree of difference between the two at the compiled binary code level. Specific quantification methods include, but are not limited to: byte-level edit distance of binary instruction sequences, similarity of binary instruction opcode sequences, and hash value differences of code segments (.text segments) in the binary file. A lower second similarity metric indicates lower similarity between the two executables at the machine code level from a reverse engineering analyst's perspective, making it more difficult for an attacker to simultaneously compromise all executables with a single attack payload.

[0072] In step S75, if the first similarity index is less than the first preset threshold and the second similarity index is less than the second preset threshold, the reconstructed intermediate representation is compiled into an executable file for the target platform.

[0073] Specifically, a first preset threshold and a second preset threshold are pre-configured. These two thresholds represent the minimum heterogeneity standard required to meet security requirements in a mimicry defense scenario. The calculated first similarity index is compared with the first preset threshold, and the second similarity index is compared with the second preset threshold.

[0074] When the first similarity metric is less than the first preset threshold and the second similarity metric is less than the second preset threshold, it indicates that the reconstructed intermediate representation has achieved the expected heterogeneity security gain at both the intermediate representation structure and the final binary code levels, without compromising the original functional equivalence. At this point, the heterogeneity evaluation is deemed successful, and the reconstructed intermediate representation is officially compiled into an executable file for the target platform and output. Conversely, if any metric is greater than or equal to the corresponding preset threshold, it indicates insufficient heterogeneity. A visual evaluation report can be generated, prompting the user to adjust the heterogeneity strategy parameters to trigger the next round of reconstruction and evaluation.

[0075] This embodiment extracts and compares the control flow graph features of the reconstructed intermediate representation and the original intermediate representation, calculates a first similarity index representing the degree of difference between the two at the intermediate representation structure level, thereby quantitatively evaluating the depth of control flow topology disruption and reconstruction from the compiler's perspective. Then, both are compiled into target platform machine code, and a second similarity index representing the degree of difference at the binary code level is calculated to evaluate the anti-analysis capability of the final executable file from a reverse engineering perspective. Based on this, only when the first similarity index is less than a first preset threshold and the second similarity index is less than a second preset threshold is the reconstruction result determined to have achieved the expected heterogeneous security gain at both the intermediate representation structure and the final binary code levels, and it is then compiled into an executable file for the target platform. Otherwise, an evaluation report is generated, prompting the user to adjust the heterogeneous strategy parameters to trigger a new round of reconstruction. This forms a closed-loop mechanism of "reconstruction—quantitative evaluation—feedback optimization," ensuring that the final output executable file maintains functional equivalence while possessing sufficient differentiation to resist batch breakthroughs by a single attack payload.

[0076] The specific implementation of the present invention will be described below in conjunction with specific application scenarios.

[0077] Example 1: Implementation process of multimodal compilation and heterogeneity evaluation based on LLVM architecture: Please refer to... Figure 6 This embodiment uses a heterogeneous multi-core microcontroller for industrial control as an example to illustrate the specific workflow of a multimodal compiler. This workflow covers a complete closed loop from user configuration, intermediate representation reconstruction, heterogeneous evaluation to final compilation.

[0078] Step S1001: Obtain compilation configuration and source files Before starting the compilation process, the basic runtime environment and input files must first be prepared.

[0079] Synchronization point support module pre-compilation: The source code of the synchronization point support module (written in standard C, utilizing GNU C extensions for address capture and jump recovery), which includes synchronization point macro definitions, execution state storage and recovery functions, and synchronization point check scheduling interfaces, is independently compiled into object code files. This module is independent of subsequent heterogeneous compilation processes, ensuring that the synchronization state recovery logic remains intact regardless of application changes. Specifically: The synchronization point support module defines synchronization point macros (e.g., MV_CHK_POINT). During program execution, this macro first declares a local label using __label__, obtains the address of the label using the && operator, and stores it in the platform context's recovery point record table. Subsequently, it calls the synchronization point check scheduling interface (e.g., the mvp_check_pt function) to perform state checks: If the check passes (determined by the scheduler callback function), the execution state storage function is called to save the state of the protected variables in the current context to the recovery buffer and record the current recovery point number; If the check fails, the execution state recovery function (e.g., mvp_restore) is called to restore the protected variables to the last saved state, and the execution continues by jumping to the last recovery point address recorded in the recovery point record table using the goto*(addr) instruction.

[0080] In the compilation process, the source code of the synchronization point support module is first compiled independently into object code files. During the compilation and linking phase of the application, the object code of the synchronization point support module is merged with the application code. Because the synchronization point support module is independent of the heterogeneous compilation process of the application, the synchronization state recovery logic in the synchronization point support module remains intact and is unaffected by the refactoring operation, regardless of how the intermediate representation of the application is transformed by heterogeneous operators.

[0081] Regarding the representation of synchronization points within the compiler, the indirect jump code (such as goto*(addr)) generated by the above synchronization point macros after being expanded by the preprocessor is transformed into a specific instruction structure carrying synchronization point information at the compiler front end.

[0082] Specifically, under the LLVM architecture, this code is compiled into indirectbr instructions, and its jump targets are recorded through the blockaddress mechanism. For example, the expanded code in the original intermediate representation (LLVM IR) is represented by a structure like indirectbr i8*%addr,[label%bb1,label%bb2,...], where blockaddress(@func,%bb1) ​​precisely records the address of the basic block bb1 in the function func. These indirectbr instructions and their associated blockaddress list constitute the synchronization markers in the original intermediate representation, which are identified and used by subsequent steps, ensuring the correctness and traceability of the synchronization point logic when generating the reconstructed intermediate representation and the final executable file.

[0083] Then, through a graphical user interface (such as...) Figure 7 (As shown) or receive the user's compilation configuration via command line.

[0084] Input content: The user specifies the source file (such as C language source code), the target platform (such as ARM Cortex-M3, RISC-V, etc.), and the target function name.

[0085] Configuration parsing: Parses the configuration information to determine the target function units to be processed. Function units not appearing in the configuration will be marked as remaining unchanged and will not participate in subsequent reconstruction transformations.

[0086] Step S1002: Generate the original intermediate representation The compiler front-end (such as Clang) analyzes the input source file and generates the raw intermediate representation (specifically LLVM IR in this embodiment).

[0087] Synchronization point identification: During the generation process, the synchronization point macros (such as MV_CHK_POINT) inserted in the source code of the source file are identified and converted into specific instruction structures (such as indirectbr instructions and blockaddress lists) in the intermediate representation, which serve as the basis for subsequent protection logic.

[0088] Step S1003: Reconstruct the original intermediate representation to generate a reconstructed intermediate representation. The set of heterogeneous operators is invoked to transform the original intermediate representation.

[0089] Scheduling mechanism: A synchronization-point-aware target function-level scheduling is employed. Each heterogeneous operator is implemented as an LLVMFunctionPass, and the current function name (F.getName()) is compared with the configured target function identifier in the runOnFunction callback. The transformation is performed only if the names match; otherwise, it is skipped.

[0090] Specific transformation operations: Based on the operator and strength parameters selected by the user (such as number of iterations, probability %), perform one or more of the following transformations: Control flow flattening: Incorporate basic blocks within functions into a flat structure centered around switch-dispatch, eliminating branch hierarchy.

[0091] Invalid control flow: Copy the basic block and insert a true conditional branch (opaque predicate), adding dead code paths.

[0092] Instruction substitution: Replace binary operation instructions with functionally equivalent but more complex instruction sequences (e.g., replace addition with a combination of addition and subtraction).

[0093] Basic block cutting: randomly cuts basic blocks that do not contain Phi nodes, increasing jump complexity.

[0094] Null instruction insertion: Randomly inserts NOP instructions to change the instruction distribution.

[0095] Function copy: Copies a function and randomly calls it via a wrapper function.

[0096] String obfuscation: XOR encryption of global constant strings.

[0097] Output: The intermediate representation after the above transformation is the reconstructed intermediate representation.

[0098] Step S1004: Perform heterogeneity evaluation on the reconstructed intermediate representation and the original intermediate representation. Cross-validation was performed using two integrated evaluation tools to quantitatively assess the reconstruction effect.

[0099] Intermediate representation layer evaluation: Based on the fuzzy hash algorithm, the similarity between the hash digests of the reconstructed intermediate representation and the original intermediate representation is calculated. The lower the score (range 0-100), the higher the degree of differentiation at the instruction sequence level.

[0100] Binary code layer evaluation (optional / parallel): Based on ROP Gadget analysis, the similarity percentage of the number of usable Gadgets in the binary code before and after heterogeneity is statistically analyzed to reflect the degree of difference in anti-attack capability.

[0101] Judgment logic: The evaluation result is compared with a preset threshold. If the similarity score is lower than the first threshold and the Gadget similarity is lower than the second threshold, the evaluation is deemed to have passed; otherwise, feedback is given to the user to adjust the strategy (such as increasing the operator strength or expanding the range of the objective function), and step S1003 is re-executed, such as expanding or narrowing the range of the objective function, increasing the types of heterogeneous operators, or adjusting the strength parameters of the operators.

[0102] Step S1005: Compile the reconstructed intermediate representation into an executable file for the target platform. Based on the evaluation results (i.e., after confirming that the refactored code meets the security and functional requirements), the backend compilation stage begins.

[0103] Backend processing: Call the backend compiler of the corresponding target platform (such as ARM, RISC-V, MIPS) to perform instruction selection, register allocation and code optimization for the reconstructed intermediate representation.

[0104] Link generation: Link the compiled target code with the synchronization point support module (a library file containing state recovery logic).

[0105] Final output: Generates an executable file (such as an ELF format file) suitable for the target platform, completing the entire compilation process.

[0106] Example 2: Extended Implementation Process for Supporting Multilingual Input: This example, based on Example 1, further illustrates the support capability for multilingual source files. The main difference between this example and Example 1 lies in the processing logic of the compiler front-end and the method of obtaining the original intermediate representation.

[0107] In this embodiment, the compiler front end is configured to support input from multiple programming languages, specifically C and Java.

[0108] For C language source files: the standard Clang front-end compiler is used for analysis, directly generating raw intermediate representations in LLVM format.

[0109] For Java source files: a toolchain for converting classes to IR (Intermediate Representation) is introduced. The specific processing flow is as follows: First, a Java compiler (such as Javac) is used to compile the Java source file (.java) into Java bytecode (.class file). Subsequently, the class-to-IR conversion tool is invoked to parse the Java bytecode and convert it into a raw intermediate representation conforming to the LLVM specification.

[0110] Regardless of whether the input source file is in C or Java, once it is converted to the unified raw intermediate representation (LLVMIR), the subsequent processing flow remains consistent.

[0111] Synchronization point adaptation: For Java applications, synchronization point markers can also be inserted at critical logic locations. After being converted into the raw intermediate representation, these markers also appear as specific instruction structures (such as the indirectbr instruction), thus enabling them to be recognized by subsequent function-level heterogeneous scheduling modules.

[0112] Reconstruction and compilation: Continue with the steps as in Example 1: Based on user configuration, reconstruct the objective function in the original intermediate representation to generate a reconstructed intermediate representation; then perform heterogeneous evaluation, and finally compile it into an executable file for the target platform.

[0113] Accordingly, please refer to Figure 8 A block diagram of a code heterogeneity processing apparatus provided in this application embodiment, the apparatus comprising: Code acquisition unit 101 is used to acquire the source code to be compiled; The policy receiving unit 103 is used to receive heterogeneous policy parameters configured by the user. The heterogeneous policy parameters include a specified objective function and a heterogeneous operator applied to the objective function. The differential reconstruction unit 105 is used to convert the source code into the original intermediate representation, and to perform differential reconstruction on the function units in the original intermediate representation that correspond to the target function using the heterogeneity operator to generate the reconstructed intermediate representation. The evaluation compilation unit 107 is used to perform heterogeneous evaluation on the reconstructed intermediate representation and the original intermediate representation, and compile the reconstructed intermediate representation into an executable file for the target platform based on the evaluation results.

[0114] In some alternative implementations, heterogeneity operators include one or more combinations of control flow flattening, invalid control flow, instruction substitution, base block splitting, string obfuscation, null instruction insertion, and function copying.

[0115] In some optional implementations, the heterogeneity strategy parameters also include strength parameters set for each heterogeneity operator, such as the number of iterations, the percentage of trigger probability, the number of cuts, or the number of copies.

[0116] In some optional implementations, the differential reconstruction unit 105 includes: The source code is front-end compiled by the compiler, which converts the synchronization marks in the source code into an intermediate representation instruction sequence, resulting in the original intermediate representation containing the intermediate representation instruction sequence.

[0117] In some optional implementations, the differential reconstruction unit 105 includes: Identify the intermediate representation instruction sequence in the original intermediate representation and add the intermediate representation instruction sequence as a synchronization control point to the reconstruction whitelist; Read the intensity parameters configured for the objective function in the heterogeneity strategy parameters, use the heterogeneity operator, and perform differential reconstruction on the instructions in the original intermediate representation except for the reconstruction whitelist according to the transformation intensity determined by the intensity parameters to generate the reconstructed intermediate representation.

[0118] In some optional implementations, the differential reconstruction unit 105 includes: Traverse the function units in the original intermediate representation and match the function units with the target function to filter out the target function units to be heterogeneous; Obtain multiple heterogeneous operators configured in the objective function unit, and determine the predetermined execution order of each heterogeneous operator; According to the predetermined execution order, each heterogeneous operator is called sequentially to transform the instructions in the target function unit, and the transformation intensity is controlled according to the intensity parameter during the execution process to generate the reconstructed intermediate representation.

[0119] In some alternative implementations, the evaluation compilation unit 107 includes: Determine the first similarity index used to characterize the reconstructed intermediate representation and the original intermediate representation at the intermediate representation structure level; Determine a second similarity metric to characterize the reconstructed intermediate representation and the original intermediate representation at the compiled binary code level; If the first similarity index is less than the first preset threshold and the second similarity index is less than the second preset threshold, the reconstructed intermediate representation will be compiled into an executable file for the target platform.

[0120] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0121] In this embodiment, a code heterogeneity processing device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0122] Please see Figure 9 , Figure 9 This application provides a schematic diagram of the structure of a computer device, as shown in the embodiment of the present application. Figure 9 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 9 Take a processor 10 as an example.

[0123] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GPA), or any combination thereof.

[0124] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0125] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0126] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0127] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0128] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0129] The apparatus and units described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0130] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0131] Those skilled in the art will understand that the embodiments of this application can be provided as methods or apparatus. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0132] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, and devices according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0133] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0134] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0135] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0136] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0137] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

[0138] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for processing code heterogeneity, characterized in that, The method includes: Obtain the source code to be compiled; Receive heterogeneity strategy parameters configured by the user, wherein the heterogeneity strategy parameters include a specified objective function and a heterogeneity operator applied to the objective function; The source code is converted into a raw intermediate representation. The function units in the raw intermediate representation that correspond to the target function are reconstructed using the heterogeneity operator to generate a reconstructed intermediate representation. The reconstructed intermediate representation and the original intermediate representation are subjected to heterogeneity evaluation, and the reconstructed intermediate representation is compiled into an executable file for the target platform based on the evaluation results.

2. The method according to claim 1, characterized in that, The heterogeneity operators include one or more combinations of control flow flattening, invalid control flow, instruction substitution, basic block splitting, string obfuscation, empty instruction insertion, and function copying.

3. The method according to claim 1, characterized in that, The heterogeneity strategy parameters also include strength parameters set for each heterogeneity operator, including the number of iterations, trigger probability percentage, number of cuts, or number of copies.

4. The method according to claim 1, characterized in that, The process of converting the source code into a raw intermediate representation includes: The source code is front-end compiled by a compiler to convert the synchronization marks in the source code into an intermediate representation instruction sequence, thereby obtaining the original intermediate representation containing the intermediate representation instruction sequence.

5. The method according to claim 4, characterized in that, The step of performing differential reconstruction on the function units corresponding to the objective function in the original intermediate representation using the heterogeneity operator to generate a reconstructed intermediate representation includes: The intermediate representation instruction sequence is identified in the original intermediate representation, and the intermediate representation instruction sequence is added as a synchronization control point to the reconstruction whitelist; Read the intensity parameter configured for the objective function in the heterogeneity strategy parameters, and use the heterogeneity operator to perform differential reconstruction on the instructions in the original intermediate representation except for the reconstruction whitelist according to the transformation intensity determined by the intensity parameter, so as to generate the reconstructed intermediate representation.

6. The method according to claim 5, characterized in that, The step of using the heterogeneity operator, according to the transformation intensity determined by the intensity parameter, to perform differential reconstruction on the instructions in the original intermediate representation other than the reconstruction whitelist, and generating the reconstructed intermediate representation, includes: Traverse the function units in the original intermediate representation and match the function units with the target function to filter out the target function units to be heterogeneous; Obtain multiple heterogeneous operators configured in the objective function unit, and determine the predetermined execution order of each heterogeneous operator; According to the predetermined execution order, each of the heterogeneous operators is called sequentially to transform the instructions in the target function unit, and the transformation intensity is controlled according to the intensity parameter during the execution process to generate the reconstructed intermediate representation.

7. The method according to claim 1, characterized in that, The step of performing a heterogeneous evaluation on the reconstructed intermediate representation and the original intermediate representation, and compiling the reconstructed intermediate representation into an executable file for the target platform based on the evaluation results, includes: Determine a first similarity index to characterize the reconstructed intermediate representation and the original intermediate representation at the intermediate representation structure level; Determine a second similarity index to characterize the reconstructed intermediate representation and the original intermediate representation at the compiled binary code level; If the first similarity index is less than the first preset threshold and the second similarity index is less than the second preset threshold, the reconstructed intermediate representation is compiled into an executable file for the target platform.

8. A code heterogeneity processing device, characterized in that, The device includes: The code acquisition unit is used to acquire the source code to be compiled. A policy receiving unit is used to receive heterogeneous policy parameters configured by the user, wherein the heterogeneous policy parameters include a specified objective function and a heterogeneous operator applied to the objective function; The differential reconstruction unit is used to convert the source code into an original intermediate representation, and to perform differential reconstruction on the function units in the original intermediate representation that correspond to the target function using the heterogeneity operator to generate a reconstructed intermediate representation; An evaluation compilation unit is used to perform heterogeneous evaluation on the reconstructed intermediate representation and the original intermediate representation, and compile the reconstructed intermediate representation into an executable file for the target platform based on the evaluation results.

9. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the code heterogeneity processing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to execute the code heterogeneity processing method according to any one of claims 1 to 7.

Images