Cross-language function randomization method and system based on assembly representation and electronic equipment

Abstract

The invention relates to the technical field of computers, in particular to a cross-language function randomization method and system based on assembly characterization and electronic device.The method comprises the steps that the current compiling process of a multi-language program is obtained; based on a preset standardization strategy, carrying out standardization processing on the current compiling process of the current multi-language program to obtain a unified assembly-level intermediate representation; based on the unified assembly-level intermediate representation, function boundary and pointer reference information is collected on the assembly language level, and assembly-level metadata is obtained; and performing static binary rewriting on the executable file based on the assembly-level metadata, and generating the randomized variant, thereby solving the problem of low architecture compatibility and language compatibility in related technologies, and improving the capability of resisting cross-language attacks using mixed language characteristics.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a cross-language function randomization method and system based on assembly representation and electronic equipment. BACKGROUND

[0002] Memory corruption vulnerabilities have been a serious threat to computer systems for decades and continue to evolve with the arms race of the network. With the popularity of smartphones and Internet of Things (IoT) devices, these attacks have now expanded from traditional x86 architectures to ARM architectures, bringing persistent memory security threats to mobile computing, industrial control systems, and other fields.

[0003] In related technologies, fine-grained code randomization techniques are usually used to achieve based on compile-time metadata collection, which accurately collects instruction boundaries and pointer information required for randomization during the compilation process, and can be applied to more complex real-world applications.

[0004] However, the related technology has the problem of architecture compatibility, that is, the existing compiler-assisted randomization is designed for x86-64 architecture, and lacks features for ARM architecture, and the problem of language compatibility, that is, the existing compiler-assisted randomization is usually tightly coupled with a specific compiler, making it difficult to maintain compatibility when the compiler version is updated, and lacks portability between various high-level languages, making it vulnerable to new cross-language attacks, which needs to be solved. SUMMARY

[0005] The present application provides a cross-language function randomization method and system based on assembly representation to solve the problem of low architecture and language compatibility in related technologies and improve the ability to resist cross-language attacks that exploit mixed language features.

[0006] The first aspect of the present application provides a cross-language function randomization method based on assembly representation, comprising the following steps: obtaining the current compilation process of a multi-language program; based on a preset standardization strategy, standardizing the current compilation process of the current multi-language program to obtain a unified assembly-level intermediate representation; based on the unified assembly-level intermediate representation, collecting function boundary and pointer reference information at the assembly language level to obtain assembly-level metadata; based on the assembly-level metadata, performing static binary rewriting on the executable file to generate a randomized variant.

[0007] Further, in some embodiments, the preset standardization strategy includes at least one of a modification-free standardization strategy, a standardization strategy based on preset compilation options, and a standardization strategy based on backend code extension.

[0008] Further, in some embodiments, the collecting function boundary and pointer reference information at assembly language level based on the unified assembly-level intermediate representation to obtain assembly-level metadata collection comprises: identifying function labels, symbolic expressions, relocation types of the symbolic expressions and relocation types of each pointer in the assembly code based on the unified assembly-level intermediate representation; and obtaining the assembly-level metadata collection according to the function labels, the symbolic expressions, the relocation types of the symbolic expressions and the relocation types of each pointer.

[0009] Further, in some embodiments, the relocation types comprise first to seventh addressing modes, wherein the first addressing mode is absolute addressing; the second addressing mode is PC-based relative addressing; the third addressing mode is Page(PC)-based relative addressing; the fourth addressing mode is GOT-based relative addressing; the fifth addressing mode is Page(GOT)-based relative addressing; the sixth addressing mode is symbol-based relative addressing; and the seventh addressing mode is TLS-based relative addressing.

[0010] Further, in some embodiments, the performing static binary rewriting on the executable file based on the assembly-level metadata to generate a randomized variant comprises: reading function boundary information in the assembly-level metadata, and dividing the executable file according to the function boundary information to obtain a plurality of function code blocks, and performing randomization processing on the plurality of function code blocks based on a preset random number generator, and recombining code segments according to a new order after processing; locating all pointers in the executable file according to pointer position information in the assembly-level metadata, and determining a target encoding mode and a target addressing mode of each pointer in the binary file based on the relocation type of each pointer, and repairing the randomized pointer based on a preset pointer repair formula according to the target encoding mode and the target addressing mode, to obtain the randomized variant.

[0011] Further, in some embodiments, after obtaining the randomized variant, the method further comprises: removing a metadata section in the randomized variant.

[0012] Further, in some embodiments, the preset pointer repair formula is:

[0013] {Base+Δb}+{(Pointer*Step)+(-Δb+Δt)}={Target+Δt};

[0014] Wherein, Base is a base address, Pointer*Step is a pointer step, Target is a target, and Ab is a change amount of the base after randomization, and At is a change amount of the target after randomization.

[0015] The cross-language function randomization method based on assembly representation provided by the embodiment of the application solves the problems of low architecture compatibility and low language compatibility in the related art by formulating a standardized compilation process, standardizing the cross-code cross-platform data, collecting metadata, and performing static binary rewriting on the generated file to output the finally processed file, thereby improving the ability to resist cross-language attacks using mixed language characteristics.

[0016] The second embodiment of the application provides a cross-language function randomization system based on assembly representation, and the system comprises: an acquisition module configured to acquire a current compilation process of a multi-language program; a first processing module configured to perform standardized processing on the current compilation process of the current multi-language program based on a preset standardized strategy to obtain a unified assembly-level intermediate representation; a second processing module configured to collect function boundary and pointer reference information at an assembly language level based on the unified assembly-level intermediate representation to obtain assembly-level metadata; and a generation module configured to perform static binary rewriting on the executable file based on the assembly-level metadata to generate a randomized variant.

[0017] Further, in some embodiments, the preset standardized strategy comprises at least one of a modification-free standardized strategy, a standardized strategy based on a preset compilation option, and a standardized strategy based on a backend code extension.

[0018] Further, in some embodiments, the second processing module is specifically configured to: identify a function label, a symbol expression, a relocation type of the symbol expression, and a relocation type of each pointer in the assembly code based on the unified assembly-level intermediate representation; and obtain the assembly-level metadata collection according to the function label, the symbol expression, the relocation type of the symbol expression, and the relocation type of each pointer.

[0019] Further, in some embodiments, the relocation type comprises a first to seventh addressing mode, wherein the first addressing mode is absolute addressing, the second addressing mode is PC-based relative addressing, the third addressing mode is Page(PC)-based relative addressing, the fourth addressing mode is GOT-based relative addressing, the fifth addressing mode is Page(GOT)-based relative addressing, the sixth addressing mode is symbol-based relative addressing, and the seventh addressing mode is TLS-based relative addressing.

[0020] Further, in some embodiments, the second processing module is further configured to read function boundary information in the assembly-level metadata, divide the executable file into a plurality of function code blocks according to the function boundary information, perform randomization processing on the plurality of function code blocks based on a preset random number generator, and reorganize code segments in a new order after processing; locate all pointers in the executable file according to pointer position information in the assembly-level metadata, determine a target encoding mode and a target addressing mode of each pointer in the binary file based on a repositioning type of the pointer, and repair the randomized pointer based on a preset pointer repair formula according to the target encoding mode and the target addressing mode, to obtain the randomized variant.

[0021] Further, in some embodiments, after obtaining the randomized variant, the second processing module is further configured to remove a metadata section in the randomized variant.

[0022] Further, in some embodiments, the preset pointer repair formula is:

[0023] {Base+Δb}+{(Pointer*Step)+(-Δb+Δt)}={Target+Δt};

[0024] wherein Base is a base address, Pointer*Step is a pointer step, Target is a target, Δb is a change amount of the base address after randomization, and Δt is a change amount of the target after randomization.

[0025] According to the cross-language function randomization system based on assembly representation provided in the embodiments of the present application, a standardized compiling process is formulated to standardize the cross-code cross-platform data, collect metadata, and perform static binary rewriting on the generated file, and output the file after processing, thereby solving the problem of low architecture compatibility and language compatibility in the related art, and improving the ability to resist cross-language attacks using mixed language characteristics.

[0026] In a third aspect, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor executes the program to implement the cross-language function randomization method based on assembly representation as described in the above embodiments.

[0027] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program executable by a processor to implement the cross-language function randomization method based on assembly representation as described in the above embodiments.

[0028] Thus, the present application has the following beneficial effects:

[0029] (1) The present application has cross-language compatibility: through the compilation of standardized strategies and assembly-level metadata collection, it realizes the compatibility support for multiple programming languages such as C / C++, Fortran, Rust, Cangjie, etc., and provides unified function-level randomization protection for multi-language programs.

[0030] (2) The present application supports ARM64 architecture: the system sorts out seven addressing modes and their pointer encoding characteristics under ARM64 architecture, and realizes accurate pointer repair of ARM64 programs.

[0031] (3) The present application has the advantage of low performance overhead: it realizes function-level code randomization, with an average runtime overhead of only 0.51%, and provides sufficient entropy value to resist code reuse attacks.

[0032] (4) The present application has the ability to protect against cross-language attacks: through the equivalent randomization of all functions in multi-language programs, it effectively prevents attackers from constructing cross-language attack chains using unprotected language modules BRIEF DESCRIPTION OF DRAWINGS

[0033] The above and / or additional aspects and advantages of the present application will become apparent and more readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings, in which:

[0034] Figure 1 A flowchart of a cross-language function randomization method based on assembly representation provided according to an embodiment of the present application;

[0035] Figure 2 A metadata collection scheme based on assembly language provided according to one specific embodiment of the present application;

[0036] Figure 3 An addressing mode and a typical example diagram provided according to one specific embodiment of the present application;

[0037] Figure 4 An ARM64 pointer repair diagram provided according to one specific embodiment of the present application;

[0038] Figure 5 A design framework diagram of a cross-language function randomization method based on assembly representation provided according to one specific embodiment of the present application;

[0039] Figure 6 A block diagram of a cross-language function randomization system based on assembly representation provided according to an embodiment of the present application;

[0040] Figure 7 A structural diagram of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0041] The following describes embodiments of the present invention in detail, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present invention, and are not to be construed as limiting the present invention.

[0042] The following describes, with reference to the accompanying drawings, a cross-language function randomization method, system, and electronic device based on assembly representation according to an embodiment of the present invention. In response to the low architectural compatibility and language compatibility issues mentioned in the background art, the present invention provides a cross-language function randomization method based on assembly representation. By formulating a standardized compilation process, cross-code and cross-platform data is compiled in a standardized manner, metadata is collected, and static binary rewriting is performed on the generated files, and the final processed files are output. This solves the low architectural compatibility and language compatibility issues in related technologies and improves the ability to resist cross-language attacks that exploit mixed language features.

[0043] Specifically, Figure 1 The flowchart is a cross-language function randomization method based on assembly representation according to an embodiment of the present invention.

[0044] like Figure 1 As shown, the cross-language function randomization method based on assembly representation includes the following steps:.

[0045] In step S101 , the current compilation process of the multi-language program is obtained.

[0046] Among them, a multilingual program refers to a program written in a mixture of two or more programming languages, with different modules or components implemented in different languages; the current compilation process refers to the complete process of converting source code into an executable program or target code.

[0047] For example, for large-scale software systems, the high performance of C / C++ and the rich third-party libraries of Python can be combined to improve software development efficiency. At the same time, the source code of different languages ​​needs to be compiled into target files separately, and language compilation is completed through tools such as Java Native Interface, Python C API, GCC, and LLVM.

[0048] In step S102 , based on a preset standardization strategy, the current compilation process of the current multi-language program is standardized to obtain a unified assembly-level intermediate representation.

[0049] In some embodiments, the preset standardization strategy includes at least one of a modification-free standardization strategy, a preset compilation option-based standardization strategy, and a backend code extension-based standardization strategy.

[0050] Specifically, for compilers such as GCC and Fortran that natively support outputting assembly code, the modification-free standardization strategy is adopted, and the original compilation process is retained; for compilers such as LLVM and Cangjie, the preset compilation option-based standardization strategy is adopted, and the "-fno-integrated-as" compilation option is added to enable the system assembler to replace the built-in code generation component; for special cases such as Rust and LLVM with link-time optimization enabled, the backend code extension-based standardization strategy is adopted, and the backend code is extended to output AT&T-style assembly code and call the GNU GAS assembler; finally, the GNU GAS is used as a general-purpose assembler to collect metadata in the assembly phase and obtain a unified assembly-level intermediate representation.

[0051] For example, for a C language module (module_c.c), a compiler that supports outputting assembly (such as Clang) is used. A specific compilation option "-fno-integrated-as" is added during compilation. This option instructs the LLVM compiler to first output an AT&T-style assembly file (module_c.s) compatible with the GNU GAS assembler before generating the object code, and then calls the external GNU GAS assembler modified by the present application to generate the object file (module_c.o). In this way, the compilation process is standardized to "source code -> assembly code -> object file". For a Rust language module (module_rust.rs), a Rust compiler (rustc) integrated with the backend code extension of the present application is used. The extension modifies the backend code generation logic of the Rust compiler, so that when processing each code generation unit, it does not directly generate an object file, but first outputs an AT&T-style assembly file (module_rust_partN.s), and then calls the external GNU GAS assembler modified by the present application to generate the corresponding object file (module_rust_partN.o). Whether the source language is C or Rust, the compilation process has a unified GNU GAS assembler processing link, laying the foundation for collecting metadata at the assembly level in the next step.

[0052] In step S103, based on the unified assembly-level intermediate representation, function boundary and pointer reference information are collected at the assembly language level to obtain assembly-level metadata; and based on the assembly-level metadata, the executable file is statically rewritten in binary to generate a randomized variant.

[0053] wherein the function boundary refers to the start and end positions of the function body code in memory and the context switching rules when calling the function, the pointer reference information describes the pointing relationship of the pointer variable in the program, the assembly-level metadata refers to the additional information embedded in the assembly language or the object code (binary), and the static binary rewriting refers to modifying, optimizing or function enhancing the binary executable file directly without accessing the source code.

[0054] Specifically, the function boundary includes parameter passing and stack frame layout, the pointer reference information includes object type, life cycle and access permission, the assembly-level metadata includes type information and symbol table, and is closer to the underlying hardware architecture and directly related to the memory layout and execution logic of the machine code, and the static binary rewriting modifies the binary file without running the program, for example, by modifying instructions, data segments or metadata to generate a new executable file.

[0055] In some embodiments, based on the unified assembly-level intermediate representation, the function boundary and the pointer reference information are collected at the assembly language level to obtain the assembly-level metadata collection, including: based on the unified assembly-level intermediate representation, identifying function labels, symbol expressions, relocation types of symbol expressions and relocation types of each pointer in the assembly code; and obtaining the assembly-level metadata collection according to the function labels, the symbol expressions, the relocation types of the symbol expressions and the relocation types of each pointer.

[0056] For example, the function labels are identified from the assembly file, the label type is determined by parsing the “.type” pseudo-instruction, and the corresponding virtual address is recorded, all symbol expressions in the assembly file are collected, the virtual address, the relocation type and the related modifier are recorded by parsing the AT&T style addressing expression, the relocation type of each pointer is recorded according to the characteristics of the ARM64 architecture, which is used as an index to determine the pointer encoding and addressing mode, based on the ARM64 ABI specification and the ARM64 instruction manual, the mask operation and the instruction offset corresponding to each relocation type are determined, the 124 relocation types defined in the ARM64 ABI are summarized into seven addressing modes: absolute addressing, PC relative addressing, Page(PC) relative addressing, GOT relative addressing, Page(GOT) relative addressing, symbol relative addressing and TLS relative addressing, then the GNU GOLD linker is modified to merge the metadata from each object file in the static linking stage and handle pointer changes during linking, such as GOT optimization, TLS optimization and chip bug fixes, finally the collected metadata is serialized and stored in a special section of the final executable file.

[0057] Further, in some embodiments, the relocation types include first to seventh addressing modes, wherein the first addressing mode is absolute addressing, the second addressing mode is PC-based relative addressing, the third addressing mode is Page(PC)-based relative addressing, the fourth addressing mode is GOT-based relative addressing, the fifth addressing mode is Page(GOT)-based relative addressing, the sixth addressing mode is symbol-based relative addressing, and the seventh addressing mode is TLS-based relative addressing.

[0058] Among them, the absolute addressing refers to directly using the fixed memory address explicitly given in the instruction to read or write data, the PC-based relative addressing refers to calculating the target memory address by adding an offset to the current instruction address (PC value), the Page(PC)-based relative addressing refers to the memory addressing technology combining the paging mechanism (Paging) and the program counter (PC) in the computer system, the GOT-based relative addressing refers to realizing the position-independent access to external symbols by combining the global offset table (GOT) and the program counter (PC), the Page(GOT)-based relative addressing refers to reducing the address translation overhead by placing the GOT table item and the current instruction in the same virtual page and utilizing the intra-page locality, the symbol-based relative addressing refers to accessing the program elements by the symbol name (such as the function name or the variable name) rather than the direct memory address at the time of compiling, linking or running, and the TLS-based relative addressing refers to the addressing mode for accessing the data in the thread local storage in the multi-thread environment.

[0059] For example, Figure 2 The schematic diagram of the metadata collection scheme based on the assembly language provided according to one specific embodiment of the present application is as follows, Figure 2As shown, in the assembly phase, the modified GNU GAS is used to parse the AT&T style assembly file. For function boundary identification, the function entry is determined by identifying the label in the assembly code, such as "F1:" in line 8, and then combining the type declaration pseudo-instruction, such as ".type F1, %function" in line 7. The start virtual address (VA) and section information of the function are recorded to form the function metadata (FunInfo). The start VAs of two adjacent functions can define the boundary of a function; for pointer reference information collection, the symbolic expression in the instruction is parsed, such as the instructions in lines 14-15 contain symbolic expressions pointing to ".LC1" with different modifiers (:pg_hi21 and :lo12). The modified GAS will record the virtual address (VA), section information of the instruction containing these expressions, and the key relocation type (inferred from the modifier information). This relocation type information is the key basis for subsequent pointer repair. These information form the pointer metadata (PointerInfo). For the ARM64 architecture, special attention is paid to the relocation types because they imply the encoding method of the pointer (how to embed the pointer into the instruction through masking and offset operations) and the addressing mode (how to dereference to the virtual address), Figure 3 The addressing modes and typical example diagrams provided according to one specific embodiment of the present application are as shown in Figure 3 As shown, the present application classifies the 124 relocation types defined in the ARM64 ABI into seven basic addressing modes (absolute addressing, PC relative addressing, Page(PC) relative addressing, GOT relative addressing, Page(GOT) relative addressing, symbolic relative addressing, and TLS relative addressing) according to their dereference base.

[0060] In the linking phase, the modified GNU GOLD is used to perform metadata merging, merge the FunInfo and PointerInfo metadata from each object file, and update the VA from the object file internal offset to the virtual address of the final executable file. The effects of the linker behavior on the pointer are handled, such as GOT optimization, TLS optimization, and ARM64 specific chip bug repair. The final metadata is serialized (for example, using Protobuf) and stored in the dedicated section (such as.rand) of the executable file.

[0061] Further, in some embodiments, based on the assembly-level metadata, the executable file is statically binary rewritten to generate the randomized variant, including: reading function boundary information in the assembly-level metadata, and dividing the executable file according to the function boundary information to obtain a plurality of function code blocks, and based on a preset random number generator, the plurality of function code blocks are randomized and the code segments are reorganized according to the new order after processing; according to the pointer position information in the assembly-level metadata, all pointers in the executable file are located, and based on the relocation type of each pointer, the target encoding mode and the target addressing mode of each pointer in the binary file are determined, and based on a preset pointer repair formula, the randomized pointer is repaired according to the target encoding mode and the target addressing mode, to obtain the randomized variant.

[0062] In some embodiments, the preset pointer repair formula is:

[0063] {Base+Db}+{(Pointer*Step)+(-Db+Dt)}={Target+Dt};

[0064] Wherein, Base is the base address, Pointer*Step is the pointer step, Target is the target, Db is the change amount of the base after randomization, and Dt is the change amount of the target after randomization.

[0065] Specifically, for function-level code randomization, function boundary information in the metadata is read to accurately divide the code segments of the binary program; for super-long functions (greater than 20KB), function pruning is performed by identifying direct jump instructions to control the maximum length of a single randomization unit; a cryptographically secure random number generator is used to shuffle the order of functions; the code segments are reconstructed while retaining the association of inline data units with corresponding functions; for pointer repair after randomization, all pointers in the binary file are located according to the pointer position information in the metadata; according to the recorded relocation type, the encoding mode and addressing mode of each pointer are determined; for each addressing mode, a preset pointer repair formula is applied to correctly encode the repaired pointer value back into the instruction according to the pointer mask operation and instruction offset information.

[0066] For example, for function-level code randomization, according to the function boundary information (FunInfo.VA) in the metadata, the code segments are accurately divided into a plurality of function code blocks, for super-long functions exceeding a preset threshold (such as 20KB), pruning is performed by identifying direct jump instructions in them to divide them into smaller units, ensuring that the length of a single randomization unit is controlled, a cryptographically secure random number generator is used to shuffle the arrangement order of these code blocks (function units and pruned units), and the code segments are reorganized according to the new order;

[0067] Figure 4 An ARM64 pointer repair schematic diagram provided according to one specific embodiment of the present application is shown in FIG. 2. As shown, for the randomized pointer repair, first, the adrp instruction and its paired add instruction located at the new address (for example, 0x37acf4) after randomization are located according to the pointer metadata (PointerInfo). Meanwhile, according to the relocation type recorded in the pointer metadata for the pointer, the encoding mode of the pointer of this type is obtained to extract it from the instruction. Second, according to the addressing mode indicated by the relocation type (the pointer in adrp is Page(PC) relative addressing, and the pointer in add is absolute addressing), the new page offset (for example, 0x875) required to be contained in the adrp instruction and the new intra-page offset (for example, 0x240) required to be contained in the add instruction are calculated. Finally, according to the encoding mode indicated by the relocation type, the newly calculated offset (0x875, 0x240) is accurately written back to the corresponding bit positions of the adrp and add instructions (at their new addresses). Figure 4

[0068] Further, in some embodiments, after obtaining the randomized variant, the method further includes: removing the metadata section in the randomized variant.

[0069] Thus, the unified function-level randomization protection of the multi-language program implementation is realized.

[0070] To enable those skilled in the art to better understand the cross-language function randomization method based on assembly representation of the embodiments of the present application, the following will be explained in reverse order with specific embodiments.

[0071] Figure 5 A design framework schematic diagram of the cross-language function randomization method based on assembly representation according to one specific embodiment of the present application is shown in FIG. 3.

[0072] As shown in FIG. 4, the source file is taken as the starting input, the default compilation process of the GCC, Fortran, etc. compiler is used, the compilation operation is performed by modifying the compilation options with the help of the LLVM, Cangjie, etc. tools, the Ruz, LLVM-LTO, etc. are used to perform the extension processing on the back-end code, so as to complete the compilation standardization. In the metadata collection part, first, the function boundary related information is collected, the pointer value information is collected, the pointer position is determined and the relocation is performed, etc. Then, the metadata of each part is merged, and the metadata is updated. In the static binary rewriting part, first, the code segment of the generated executable file is parsed, and the pointer in the file is identified. Second, the layout of the function is adjusted and rearranged, and the metadata section is deleted. Finally, the pointer related information is extracted, the pointer content is updated, the modified pointer information is written back to the file, and the processed file is finally output. Figure 5

[0073] ​​The method for cross-language function randomization based on assembly representation provided by the embodiment of the present application solves the problem of low architecture compatibility and language compatibility in the related art by formulating a standardized compilation process, standardizing the cross-code cross-platform data, collecting metadata, and performing static binary rewriting on the generated file to output the finally processed file, thereby improving the ability to resist cross-language attacks using mixed language characteristics.

[0074] Secondly, the system for cross-language function randomization based on assembly representation provided by the embodiment of the present application is described with reference to the accompanying drawings.

[0075] Figure 6 The block diagram of the system for cross-language function randomization based on assembly representation provided by the embodiment of the present application is shown.

[0076] As shown in the figure, the system for cross-language function randomization based on assembly representation includes an acquisition module 100, a first processing module 200, a second processing module 300, and a generation module 400. Figure 6 The acquisition module 100 is configured to acquire the current compilation process of a multi-language program.The first processing module 200 is configured to perform standardized processing on the current compilation process of the current multi-language program based on a preset standardized strategy to obtain a unified assembly-level intermediate representation. The second processing module 300 is configured to collect function boundary and pointer reference information at the assembly language level based on the unified assembly-level intermediate representation to obtain assembly-level metadata. The generation module 400 is configured to perform static binary rewriting on an executable file based on the assembly-level metadata to generate a randomized variant.

[0077] Further, in some embodiments, the preset standardized strategy includes at least one of a standardized strategy without modification, a standardized strategy based on a preset compilation option, and a standardized strategy based on a backend code extension.

[0078] Further, in some embodiments, the second processing module 300 is specifically configured to identify function labels, symbolic expressions, relocation types of symbolic expressions, and relocation types of each pointer in the assembly code based on the unified assembly-level intermediate representation, and obtain assembly-level metadata collection according to the function labels, symbolic expressions, relocation types of symbolic expressions, and relocation types of each pointer.

[0079]

[0080] Further, in some embodiments, the repositioning types include first to seventh addressing modes, wherein the first addressing mode is absolute addressing; the second addressing mode is PC-based relative addressing; the third addressing mode is Page(PC)-based relative addressing; the fourth addressing mode is GOT-based relative addressing; the fifth addressing mode is Page(GOT)-based relative addressing; the sixth addressing mode is symbol-based relative addressing; and the seventh addressing mode is TLS-based relative addressing.

[0081] Further, in some embodiments, the second processing module 300 is further configured to read function boundary information in the assembly-level metadata, divide the executable file into a plurality of function code blocks according to the function boundary information, perform randomization processing on the plurality of function code blocks based on a preset random number generator, and reorganize the code segments in the new order after processing; locate all pointers in the executable file according to the pointer position information in the assembly-level metadata, determine the target encoding mode and the target addressing mode of each pointer in the binary file based on the repositioning type of each pointer, and perform repair on the randomized pointers based on the preset pointer repair formula according to the target encoding mode and the target addressing mode, to obtain the randomized variants.

[0082] Further, in some embodiments, after obtaining the randomized variants, the second processing module 300 is further configured to remove the metadata section in the randomized variants.

[0083] Further, in some embodiments, the preset pointer repair formula is:

[0084] {Base+Δb}+{(Pointer*Step)+(-Δb+Δt)}={Target+Δt};

[0085] wherein, Base is the base address, Pointer*Step is the pointer step, Target is the target, Δb is the change amount of the base address after randomization, and Δt is the change amount of the target after randomization.

[0086] It should be noted that the above explanation and description of the embodiment of the cross-language function randomization method based on assembly representation also applies to the embodiment of the cross-language function randomization system based on assembly representation, which will not be described here.

[0087] The cross-language function randomization system based on assembly representation provided by the embodiment of the present application solves the problem of low architecture compatibility and language compatibility in the related art by formulating a standardized compiling process, standardizing the compilation of cross-code cross-platform data, collecting metadata, performing static binary rewriting on the generated file, and outputting the finally processed file, thereby improving the ability to resist cross-language attacks using mixed language characteristics.

[0088] Figure 7 A structural schematic diagram of an electronic device according to an embodiment of the present application is provided. The electronic device can include:

[0089] The memory 701, the processor 702, and the computer program stored in the memory 701 and executable on the processor 702.

[0090] The processor 702 implements the cross-language function randomization method based on assembly representation provided in the above embodiments when executing the program.

[0091] Further, the electronic device further includes:

[0092] The communication interface 703 is used for communication between the memory 701 and the processor 702.

[0093] The memory 701 is used to store the computer program executable on the processor 702.

[0094] The memory 701 can include a high-speed RAM memory, and can also include a non-volatile memory, for example, at least one disk memory.

[0095] If the memory 701, the processor 702, and the communication interface 703 are independently implemented, the communication interface 703, the memory 701, and the processor 702 can be connected to each other through a bus and complete communication between each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 Only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0096] Optionally, in a specific implementation, if the memory 701, the processor 702 and the communication interface 703 are integrated on a chip, the memory 701, the processor 702 and the communication interface 703 can communicate with each other through an internal interface.

[0097] The processor 702 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention.

[0098] In addition, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, the above-mentioned cross-language function randomization method based on assembly representation is implemented.

[0099] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0100] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Thus, a feature specified as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "N" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0101] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing a custom logical function or step of a process, and the scope of the preferred embodiments of the invention includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of the invention pertain.

[0102] It should be understood that portions of the present application can be implemented in hardware, software, firmware, or combinations thereof. In the above embodiments, the N steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. As such, if implemented in hardware, and in another embodiment, any of the following technologies, known in the art, or their combinations, can be used to implement: discrete logic circuitry having logic gates for implementing logic functions on data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and the like.

[0103] Those skilled in the art can understand that all or part of the steps carried out by the above-mentioned embodiment methods can be completed by programs instructing related hardware, and the programs can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

Claims

1. A cross-language function randomization method based on assembly representation, characterized in that, The method comprises the following steps: obtaining a current compilation flow of a multilingual program; standardizing the current compilation flow of the current multilingual program based on a preset standardization strategy to obtain a unified assembly-level intermediate representation; collecting function boundary and pointer reference information at an assembly language level based on the unified assembly-level intermediate representation to obtain assembly-level metadata; performing static binary rewriting on an executable file based on the assembly-level metadata to generate a randomized variant.

2. The method of claim 1, wherein, The preset standardization strategy comprises at least one of a standardization strategy without modification, a standardization strategy based on preset compilation options, and a standardization strategy based on backend code extension.

3. The method of claim 1, wherein, The collecting, based on the unified assembly-level intermediate representation, of function boundary and pointer reference information at an assembly language level to obtain assembly-level metadata comprises: identifying, based on the unified assembly-level intermediate representation, function labels, symbolic expressions, relocation types of the symbolic expressions, and relocation types of each pointer in the assembly code; obtaining the assembly-level metadata collection according to the function labels, the symbolic expressions, the relocation types of the symbolic expressions, and the relocation types of each pointer.

4. The method of claim 3, wherein, The relocation types comprise first to seventh addressing modes, wherein the first addressing mode is absolute addressing; the second addressing mode is PC-based relative addressing; the third addressing mode is Page(PC)-based relative addressing; the fourth addressing mode is GOT-based relative addressing; the fifth addressing mode is Page(GOT)-based relative addressing; the sixth addressing mode is symbol-based relative addressing; and the seventh addressing mode is TLS-based relative addressing.

5. The method of claim 3, wherein, The performing, based on the assembly-level metadata, of static binary rewriting on an executable file to generate a randomized variant comprises: reading function boundary information in the assembly-level metadata, and dividing the executable file according to the function boundary information to obtain a plurality of function code blocks, and performing randomization processing on the plurality of function code blocks based on a preset random number generator, and recombining code segments in a new order after processing; locating all pointers in the executable file according to pointer position information in the assembly-level metadata, and determining a target encoding mode and a target addressing mode of each pointer in the binary file based on the relocation types of the pointers, and repairing the randomized pointers based on a preset pointer repair formula according to the target encoding mode and the target addressing mode to obtain the randomized variant.

6. The method of claim 5, wherein, After obtaining the randomized variant, the method further comprises: removing a metadata section in the randomized variant.

7. The method of claim 5, wherein, The preset pointer repair formula is: {Base+Δb}+{(Pointer*Step)+(-Δb+Δt)}={Target+Δt}; wherein, Base is a base address, Pointer*Step is a pointer step, Target is a target, Δb is a change amount of the base address after randomization, and Δt is a change amount of the target after randomization.

8. A cross-language function randomization system based on assembly representation, characterized in that, The system comprises: an acquisition module configured to acquire a current compilation flow of a multilingual program; a first processing module configured to perform standardized processing on the current compilation flow of the current multilingual program based on a preset standardized strategy to obtain a unified assembly-level intermediate representation; a second processing module configured to collect function boundary and pointer reference information at an assembly language level based on the unified assembly-level intermediate representation to obtain assembly-level metadata; a generation module configured to perform static binary rewriting on an executable file based on the assembly-level metadata to generate a randomized variant.

9. An electronic device, comprising: comprise: a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor executing the program to implement the assembly representation-based cross-language function randomization method according to any one of claims 1-7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the assembly representation-based cross-language function randomization method according to any one of claims 1-7.

Images