Binary code similarity detection method and system based on unified intermediate language representation
By constructing a unified intermediate language representation and semantic flow graph, the problems of system bloat and semantic distortion in cross-platform binary code detection are solved, and high-precision similarity detection is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHONGQING UNIV OF POSTS & TELECOMM
- Filing Date
- 2026-01-26
- Publication Date
- 2026-05-15
AI Technical Summary
Existing binary code similarity detection methods suffer from problems such as bloated system architecture, high maintenance costs, semantic distortion, and difficulty in expansion when performing cross-platform detection. Furthermore, different intermediate language representations cannot be effectively compared at the same semantic level.
By constructing a unified intermediate language representation, including obtaining the architecture and compiler information of the binary file, generating the intermediate language representation using a fine-tuned large language model, applying optimization transformations, mapping to semantic atoms, constructing a semantic flow graph, and using a graph embedding model to calculate similarity.
It achieves accuracy and robustness in binary code detection across architectures and compilers, strips away syntactic detail interference, and improves detection precision and stability.
Smart Images
Figure CN122046355A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer security technology, specifically to a binary code similarity detection method and system based on a unified intermediate language representation. Background Technology
[0002] Traditional binary code similarity detection methods mainly rely on manually designed features, such as statistical features based on assembly instruction sequences, structural features of control flow graphs, or topological features of function call graphs. Deep learning-based methods, by learning high-level representations of the code, automatically extract features, significantly improving detection capabilities.
[0003] In existing technologies, some research attempts to convert binary or assembly code from different architectures into intermediate languages. By stripping away the differences caused by hardware instruction sets, this approach focuses on the core logic and intent of the code, providing a foundation for cross-platform similarity detection. However, existing methods face the following main problems when using intermediate languages to handle more complex real-world scenarios such as cross-compiler and cross-optimization levels:
[0004] 1. Existing methods generally rely on converting binary code into a specific type of intermediate language for analysis. However, each intermediate language requires the establishment of an independent analysis and detection pipeline, which not only makes the system architecture bloated and complex but also increases maintenance costs. More seriously, existing detection methods are often deeply tied to specific disassemblers, resulting in independent analysis pipelines that are difficult to extend, making it impossible to effectively compare intermediate representations from different sources at the same semantic level.
[0005] 2. Different intermediate languages exhibit significant differences in instruction sets, operand representations, and control flow modeling mechanisms, making direct mapping prone to semantic distortion. Furthermore, different compilers optimize intermediate languages differently, leading to intermediate language representations derived from binary code compiled across compilers and optimization levels that may present entirely different control flow structures and data dependencies. Moreover, the abstraction process for a unified representation is complex. Achieving an effective unified representation requires a careful balance between semantic granularity and semantic integrity. Overly coarse semantic representations lose crucial semantic information, while overly fine semantic representations cannot effectively resist syntactic variations. Summary of the Invention
[0006] In view of this, this application discloses a binary code similarity detection method and system based on a unified intermediate language representation to solve the above problems; including:
[0007] A binary code similarity detection method based on a unified intermediate language representation includes:
[0008] S1. Obtain the binary file to be tested. and Extract the following information: architecture information and Compiler information and The binary function to be detected and It converts architecture information, compiler information, and machine code of assembly code into a sequence of assembly instructions. and ;
[0009] S2. Construct the prompt word based on the architecture information, compiler information, and assembly code. and ;Will and Input a finely tuned large language model to generate intermediate language representations. and ;
[0010] S3, Intermediate Language Representation and By applying a uniform optimization transformation, a unified intermediate language representation is obtained. and ;
[0011] S4. Intermediate language representation and The process involves unifying variable names and mapping intermediate language instructions to semantic atoms, resulting in a set of semantic atoms. and Construct a semantic flow graph and ;
[0012] S5. Employ a graph embedding model to integrate semantic flow graphs. and Mapping to vector representation and ,calculate and similarity ;
[0013] A binary code similarity detection system based on a unified intermediate language representation is used to execute the aforementioned binary code similarity detection method based on a unified intermediate language representation, comprising: a preprocessing module, a conversion module, a unified optimization module, a unified representation module, and a detection module;
[0014] Furthermore, the preprocessing module receives and processes the input binary file, extracts various low-level assembly instructions required to generate the intermediate language representation, the conversion module converts the low-level assembly instructions into a unified high-level intermediate language, the unified optimization module normalizes the high-level intermediate language to eliminate syntactic and structural variations introduced by different compiler optimization levels, the unified representation module abstracts the normalized intermediate language into a robust graph structure representation, and the detection module quantizes the graph structure representation into numerical vectors and calculates the output similarity.
[0015] The beneficial effects of this application include:
[0016] This application discloses a binary code similarity detection method based on a unified intermediate language representation. By using a finely tuned language model, assembly code of different architectures is mapped to its native, high-order, architecture-independent compiler intermediate representation to solve the problem of syntax incompatibility between different instruction sets and achieve alignment of code of different architectures at a unified semantic level.
[0017] By using unified and optimized semantic normalization, the transformations that only change the code syntax without changing the functionality brought about by different optimization levels are removed, so that the features learned by the model remain stable for compiler optimizations, and the accuracy of cross-optimization level detection is significantly improved.
[0018] By unifying and abstracting the two intermediate language representations into a set of semantic atoms and a semantic flow graph, and performing feature learning and similarity calculation on the basis of the normalized semantic flow graph, the model can focus on the functional intent of the code rather than the underlying syntactic details. This reduces cross-compiler code differences and achieves semantic-level fusion, greatly improving the accuracy and robustness of binary code similarity detection in dealing with complex variations in the real world. Attached Figure Description
[0019] Figure 1 This is a schematic diagram of a binary code similarity detection method based on a unified intermediate language representation in an embodiment of this application;
[0020] Figure 2 This is a schematic diagram illustrating supervised fine-tuning in an embodiment of this application;
[0021] Figure 3 This is a schematic diagram of the binary code similarity detection system in the embodiments of this application;
[0022] Figure 4 This is a schematic diagram of the preprocessing module in an embodiment of this application;
[0023] Figure 5 This is a schematic diagram of the conversion module in an embodiment of this application;
[0024] Figure 6This is a schematic diagram of the unified optimization module in an embodiment of this application;
[0025] Figure 7 This is a schematic diagram of the unified representation module in the embodiments of this application;
[0026] Figure 8 This is a schematic diagram of the detection module in an embodiment of this application. Detailed Implementation
[0027] To make the objectives, technical solutions, features, and advantages of this application clearer and to enable those skilled in the art to better understand the technical solutions of this application, the following detailed description of this application is provided in conjunction with the accompanying drawings and embodiments.
[0028] Example 1:
[0029] This embodiment includes a binary code similarity detection method based on a unified intermediate language representation, such as... Figure 1 As shown, it includes:
[0030] S1. Obtain the binary file to be tested. and Extract the following information: architecture information and Compiler information and The binary function to be detected and It converts architecture information, compiler information, and machine code of assembly code into a sequence of assembly instructions. and .
[0031] Specifically, for binary files and Extract instruction set architecture information from fields such as the e_machine field in ELF format or the Machine field in a PE file. and For example, x86-64, ARM, MIPS, etc. Compiler information is extracted by analyzing specific sections of the binary file (e.g., the .comment section of an ELF file). and (e.g., GCC 11.3, Clang 15.0, etc.). By analyzing symbol tables (e.g., the .symtab section of ELF) and identifying function entry points in code sections (.text sections), the binary function names and addresses contained within are determined, thus locating the specific function to be detected. and The code boundaries of the target function are delineated using disassembly algorithms such as linear scanning or recursive descent, and the machine code of the corresponding region is converted into a sequence of assembly instructions. and .
[0032] The process of extracting architectural information can be represented as:
[0033]
[0034] in, Indicates from binary file Extract header fields The function, Decode the architecture identifier function.
[0035] The compiler information extraction process can be represented as:
[0036]
[0037] in, Return binary file Middle Section Content, This is the compiler's feature extraction function.
[0038] Function location and boundary partitioning can be represented as:
[0039]
[0040] During disassembly, the instruction decoding function is defined as follows:
[0041]
[0042] in, Represents a binary byte sequence. Represents the architectural space. Represents the instruction sequence space.
[0043] The assembly instruction sequence generation process is represented as follows:
[0044]
[0045] in, From binary file positioning range Extract the raw bytes.
[0046] The extracted architecture, compiler information, and assembly code together form the basic input for subsequent steps, aiming to provide sufficient context for the large language model to improve the accuracy and semantic consistency of intermediate language generation.
[0047] S2. Construct the prompt word based on the architecture information, compiler information, and assembly code. and ;Will and Input a finely tuned large language model Generate the corresponding intermediate language representation and .
[0048] The build prompt and The construction process is as follows:
[0049]
[0050] in, This is a preset prompt template function.
[0051] The finely tuned large language model The model is trained to understand the semantics of assembly instructions and can generate syntactically correct and semantically equivalent high-level intermediate language representations based on the input program information and context. The model will output the corresponding intermediate language representations. and Text prompt When the compiler information is Clang, the model will output intermediate language in LLVM IR format, with text prompts. When the compiler information is GCC, the model will output intermediate language in GIMPLE format. This process achieves semantic mapping from diverse low-level assembly syntax to a unified high-level intermediate representation, effectively solving the problem of inconsistent initial representations across architectures and compilers. The generation process can be represented as follows:
[0052]
[0053] S3, Intermediate Language Representation and A uniform optimization transformation is applied to eliminate the syntactic differences introduced by the optimization level, resulting in a uniformly optimized intermediate language representation. and .
[0054] Specifically, for intermediate language representation and Apply a set of predefined, standardized compiler optimization transformation sequences. These optimizations preserve semantics, but their direction is "normalization" rather than "performance optimization." Their goal is to eliminate syntactic differences that do not affect functionality, resulting from different optimization levels (O1, O2, Os, etc.) in the original compilation process. Typical normalization optimizations include, but are not limited to: function inlining, loop unrolling, constant propagation, common subexpression elimination, dead code elimination, loop invariant hoisting, and tail call optimization.
[0055] In this embodiment, the optimized transformation formula is:
[0056]
[0057] After a unified optimization process, an optimized intermediate language representation with more stable and consistent syntax and structure is obtained. and S3 significantly improves the consistency of intermediate representations of the same functional code under different optimization options by eliminating syntactic and structural variations introduced by different compiler optimization levels to restore the core logical skeleton of the code.
[0058] S4. Optimized intermediate language representation and The process involves unifying variable names and mapping intermediate language instructions to semantic atoms, resulting in a set of semantic atoms. and Construct a semantic flow graph and .include:
[0059] S41, Traversal All variables in the list are standardized in their naming; the variables iterated over include: temporary variables, function parameters, and local variables;
[0060] In this embodiment, the standardization of variable naming involves renaming variables to %v1, %v2, %p1, etc., according to their scope and order of appearance. This process can be represented as:
[0061]
[0062] in, It is a predefined variable renaming pattern.
[0063] S42. Define a finite, closed set of semantic atoms. Each semantic atom represents a basic program operation intent that is independent of the underlying hardware and specific syntax.
[0064] In this embodiment, the defined finitely closed semantic atoms include:
[0065] Arithmetic operation atoms: ARITH_ADD (arithmetic addition), ARITH_SUB (arithmetic subtraction), ARITH_MUL (arithmetic multiplication), ARITH_DIV (arithmetic division), ARITH_SHL (logical left shift);
[0066] Bitwise operation atoms: BIT_AND (bitwise AND), BIT_OR (bitwise OR), BIT_XOR (bitwise XOR);
[0067] Atomic memory operations: MEM_LOAD (memory read), MEM_STORE (memory write);
[0068] Control flow atoms: CF_BR_COND (conditional branch), CF_BR_UNCOND (unconditional branch), CF_RET (function return);
[0069] Special operation atoms: PHI (phi node), CALL_FUNC (function call), COMPARE (comparison).
[0070] S43. Based on the semantic atom sequences obtained from the mapping and their contextual relationships in the intermediate representation, construct a directed semantic flow graph. .include:
[0071] S431, through a deterministic mapping function This maps intermediate language statements to semantic atoms.
[0072] For example, LLVM IR's `add` and GIMPLE's `PLUS_EXPR` are mapped to `ARITH_ADD`, LLVM IR's `icmpslt` and GIMPLE's `LT_EXPR` are mapped to `COMPARE`, and LLVM IR's `br i1` and GIMPLE's `COND_EXPR` are mapped to `CF_BR_COND`, etc. This mapping process strips away the specific type and value of the operands, retaining only the operation category. This is represented as:
[0073]
[0074] in, It is the opcode of the statement. It is its context (such as pointer operations involving memory atoms).
[0075] S432, from Extract control flow graph (CFG) information and definition - initialize an empty graph using the Def-Use Chain information. ,in .
[0076] S433, Generate atomic operation nodes; including:
[0077] Step 1: Traverse the sequence of semantic atoms and create a corresponding graph node for each semantic atom. .
[0078] atomic sequence Each It is the output of the AtomMap function, along with its corresponding original intermediate language statement. Contextual information, such as the basic block it belongs to, the operand abstraction category, and the node's attributes. from It is obtained from its associated context information, mainly including: semantic atomic type, abstract category of operand, such as "constant", "variable", "memory address", and the identifier of the basic block in which it is located.
[0079] Step 2: Analyze the control flow atoms in the control flow graph and semantic atom sequence, identify high-level control structures, and create a control structure node for each identified high-level control structure. .
[0080] The advanced control structures, such as natural loops and if-else branches, take the example of recognizing an if-then-else structure guided by a conditional branch atom, and create an IF_ELSE_NODE node whose attributes contain an abstract representation of the condition variable.
[0081] S434. Construct a directed edge structure between nodes; the edge structure includes: control flow edges, data flow edges, and containment edges.
[0082] The control flow edges are established by creating directed edges between atomic nodes based on the input control flow graph information. The type of directed edges is determined by the semantics of the branch atoms, including:
[0083] NEXT: Indicates sequential execution, connecting atomic nodes within the same basic block or at the unconditional jump target;
[0084] TRUE / FALSE: Connect the starting atomic node of the target block when the condition is true or false, respectively;
[0085] LOOP: Connects the atomic node at the end of the loop body to the beginning of the loop, marking the loop back edge.
[0086] The data flow edges, based on the input definition-use chain information, establish directed edges between atomic nodes that define a value (Definition) and atomic nodes that use the value (Use). The edge type is DEF_USE. Data flow edges are used to characterize the data dependencies in the program, serving as the core embodiment of functional semantics.
[0087] The included edges are directed edges established between the control structure node and all atomic nodes or other structure nodes contained within the control structure node. The edge type is CONTAINS. Containing edges are used to construct the hierarchical structure of the graph, explicitly expressing the containment relationship between high-level logic blocks and low-level atomic operations.
[0088] S435. Construct a semantic flow graph based on semantic atom sequences and definitions, using chain information; the formula is as follows:
[0089]
[0090] in, Indicates the first The semantic atom sequence corresponding to each function and Indicates from The extracted control flow and definition - using chain information, It is the union of the graph nodes corresponding to semantic atoms and the control structure nodes. This represents the union of control flow edges, data flow edges, and containing edges. It is a node attribute annotation function.
[0091] Furthermore, the semantic flow graph generated by S4 and It serves as the direct input for subsequent graph embeddings. This graph structure encodes both the program's execution logic and data processing logic through unified semantic atomic nodes, explicit data dependency edges, and high-level control structure nodes. As a robust and structured semantic representation that extracts the core logic of the program from syntactic details, this semantic flow graph is a multi-level, multi-relational graph structure that can simultaneously capture control flow, data flow, and high-level semantic structures, thereby resisting syntactic disturbances caused by different compilers and optimization levels.
[0092] S5. Employ a graph embedding model to integrate semantic flow graphs. and Mapping to vector representation and ,calculate and similarity .
[0093] Specifically, a pre-trained graph embedding model is used. semantic flow graph and Each is mapped to a low-dimensional vector representation of a fixed dimension. and , The embedding process, used to capture the structural information and node semantics of a graph, is represented as follows: In this embodiment, cosine similarity is used as the similarity score. The calculation formula is:
[0094]
[0095] The final similarity score In other words, it quantitatively reflects the degree of similarity between two input binary functions in terms of deep semantics. The higher the score, the greater the possibility that the code is of the same origin or functionally equivalent.
[0096] The method designed in this application transforms heterogeneous binary inputs into a unified intermediate representation, then normalizes the semantic graph, and finally converts it into a complete process of comparable numerical vectors. This systematically solves the challenges brought by cross-architecture, cross-compiler, and cross-optimization levels, and improves the accuracy and robustness of binary code similarity detection.
[0097] Example 2:
[0098] This embodiment includes a binary code similarity detection method based on a unified intermediate language representation. The difference from Embodiment 1 is that, in this embodiment, to ensure the large language model fine-tuned in step S2... It possesses the ability to accurately generate intermediate language representations from heterogeneous assembly instruction sequences from multiple sources. This is achieved through supervised fine-tuning on a training set based on diverse compilers. The fine-tuning process is as follows: Figure 2 As shown.
[0099] The construction process of the training set based on diversified compilation includes:
[0100] Step 1: Collect source code;
[0101] Collect or build large-scale, high-quality collections of C / C++ open-source project source code. .
[0102] Step 2: Compile the source code in various ways based on different configuration combinations; the configuration variables considered in this embodiment include:
[0103] Instruction set architecture ;
[0104] compiler ;
[0105] Optimization level ;
[0106] By iterating through the combinations, a total of There are several compilation configurations. During compilation in each configuration, the compilation toolchain is configured to store key intermediate files during the compilation process, including the final executable (binary file) and intermediate language files. Specifically, when using the Clang compiler, the intermediate language is an LLVM IR file; when using the GCC compiler, the intermediate language is a GIMPLE representation file.
[0107] Step 3: Based on the executable files obtained from the diverse compilations and their corresponding intermediate language files, construct function mapping pairs; including:
[0108] Extracting assembly functions from binary files: Parse the binary file to obtain its architecture information, compiler information, function names, and function addresses. Based on the function symbol table and code section information (such as .text), precisely delineate the boundaries of each function and disassemble the machine code corresponding to the function body into a sequence of assembly instructions. .
[0109] Extracting IR functions from intermediate language files: Parse the intermediate language file (LLVM IR or GIMPLE), locate the function with the same name, and extract its corresponding intermediate language function body. .this It is a standardized representation that removes contextual dependencies such as specific compilation units and global variables, and contains only the core logic of the function.
[0110] Constructing alignment mappings: Using function names extracted from the binary file as unique alignment keys, construct assembly instruction functions. With intermediate language functions One-to-one mapping relationship between This mapping ensures semantic consistency between assembly functions and intermediate language functions in the fine-tuning data.
[0111] Step 4: Construct a fine-tuning dataset based on function mapping pairs In the fine-tuning dataset, each sample is a tuple. ,in These are text instructions used to guide the model in code generation. It is the intermediate language function generated by the expected model.
[0112] The This is the corresponding prompt text constructed based on each assembly function. A well-designed Prompt aims to provide the model with sufficient context to understand from which "environment" the "code" is generated. The Prompt template used in this embodiment is as follows:
[0113] Translate the following assembly code (compiled for {arch}architecture by {compiler}) into {target_format}:{assembly_code}
[0114] Where {arch} and {compiler} are information extracted from the binary file header, {target_format} is the target intermediate language determined by {compiler}, and {assembly_code} is... The text representation. This information together constitutes all the context needed for model generation.
[0115] The intermediate language function output format is specified according to the compiler type: if the compiler from which the sample originates is Clang, the target output is a function definition in LLVM IR format; if the compiler from which the sample originates is GCC, the target output is a function representation in GIMPLE format.
[0116] Furthermore, the model is fine-tuned using a fine-tuning dataset, including:
[0117] Choose large language models that perform well in code understanding and generation tasks (such as Code Llama, StarCoder, Qwen-Coder series, etc.) as the base model. .
[0118] Using fine-tuned datasets right Conduct supervised fine-tuning training.
[0119] The goal of fine-tuning is to minimize the model's performance in a given context. The negative log-likelihood loss is calculated based on the generated intermediate language sequence under certain conditions. The loss function is:
[0120]
[0121] in, Represents the loss function. This indicates the prompt text. This represents an intermediate language function. This indicates fine-tuning the dataset. This represents the model parameters. Through this process, the model... It has been fine-tuned to have cross-architecture, cross-compiler, and cross-optimization level assembly-intermediate language translation capabilities. .
[0122] Based on the above supervised fine-tuning training, the fine-tuned model The ability to understand "the intended function of a piece of assembly code under a specific architecture and compiler environment" and to "translate" or "restore" it into a unified, high-level intermediate representation (LLVM IR or GIMPLE) decoupled from specific low-level details lays a crucial foundation for subsequent semantic analysis and comparison.
[0123] This fine-tuning process is the core prerequisite for the method of this application to achieve cross-architecture, cross-compiler, and cross-optimization level binary code similarity detection. It enables the model to have the key ability to extract a unified high-level semantic representation from heterogeneous, low-level assembly instructions.
[0124] Example 3:
[0125] This embodiment includes a binary code similarity detection system based on a unified intermediate language representation, used to execute the aforementioned binary code similarity detection method based on a unified intermediate language representation, such as... Figure 3 As shown, it includes: a preprocessing module, a conversion module, a unified optimization module, a unified representation module, and a detection module. The preprocessing module receives and processes the input binary file, extracting various low-level assembly instructions required to generate the intermediate language representation. The conversion module converts the low-level assembly instructions into a unified high-level intermediate language. The unified optimization module normalizes the high-level intermediate language, eliminating syntactic and structural variations introduced by different compiler optimization levels. The unified representation module abstracts the normalized intermediate language into a robust graph structure representation. The detection module quantizes the graph structure representation into numerical vectors and calculates the output similarity.
[0126] In this embodiment:
[0127] The preprocessing module, such as Figure 4 As shown, it includes:
[0128] The architecture information extraction unit extracts instruction set architecture information by parsing the header of a binary file, such as the header information in ELF or PE format.
[0129] The compiler information extraction unit extracts the compiler information that generated the file by analyzing specific sections in the binary file, such as the .comment section.
[0130] The function information extraction unit determines the function names and addresses contained in the binary file by analyzing the symbol table and code sections.
[0131] The function boundary partitioning unit, based on function address information, accurately partitions the code boundaries of the target function using disassembly algorithms such as linear scanning or recursive descent.
[0132] The assembly code generation unit uses a disassembler to convert the bounded function machine code into a sequence of assembly instructions.
[0133] The conversion module, such as Figure 5 As shown, it includes:
[0134] The Prompt building unit combines the architecture information, compiler information, and assembly instruction sequences extracted by the preprocessing module into a structured text prompt based on a predefined template.
[0135] The model fine-tuning unit uses assembly-intermediate language pairs extracted from source code compiled with multiple configurations to perform supervised fine-tuning on the basic large language model, enabling it to learn the mapping rules from assembly instructions to intermediate language.
[0136] The IR transformation unit takes the text prompts generated by the Prompt building unit and inputs them into a finely tuned large language model, which then generates a corresponding intermediate language representation that is decoupled from the underlying architecture and compiler.
[0137] The unified optimization module, such as Figure 6 As shown, it includes:
[0138] The LLVM IR Unified Optimization Unit applies a set of predefined, semantically preserved normalized optimization transformations to the LLVM IR intermediate representation generated by the Clang compiler chain.
[0139] The GIMPLE unified optimization unit applies a set of predefined, semantically preserving normalization optimization transformations to the GIMPLE intermediate representation generated by the GCC compiler chain. Both optimization units share the same goal: to obtain a normalized intermediate representation with more stable syntax and structure while maintaining functional semantics.
[0140] The unified representation module, such as Figure 7 As shown, it includes:
[0141] The variable name unification unit traverses the normalized intermediate representations and renames all variables to a set of standardized, meaningless identifiers to eliminate the differences caused by the randomness of variable naming.
[0142] The semantic atom mapping unit maps each intermediate language instruction to a predefined, more abstract "semantic atom," thereby stripping away specific grammatical details and extracting the core operational intent.
[0143] The semantic flow graph construction unit analyzes the control flow and data flow dependencies of the semantic atom sequence obtained by mapping, and constructs a multi-level directed semantic flow graph containing atomic nodes, control structure nodes, data flow nodes, control flow edges, data flow edges, and containment edges.
[0144] The detection module, such as Figure 8 As shown, it includes:
[0145] The vector embedding unit uses a pre-trained graph neural network model to map the semantic flow graph generated by the unified representation module into a fixed-dimensional low-dimensional vector representation.
[0146] The similarity calculation unit calculates the similarity score (such as cosine similarity) between two graph embedding vectors. This score is the result of measuring the similarity between the two input binary functions in deep semantics.
[0147] Finally, it should be noted that the above description only depicts some embodiments of this application. For those skilled in the art, various changes, modifications, substitutions, and variations can be conceived of these embodiments without departing from the principles and spirit of this application. The scope of protection of this application is defined by the appended claims and their equivalents, and all the above-mentioned behaviors should be covered within the scope of protection of this application.
Claims
1. A binary code similarity detection method based on a unified intermediate language representation, characterized in that, include: S1. Obtain the binary file to be tested. and Extract the following information: architecture information and Compiler information and The binary function to be detected and It converts architecture information, compiler information, and machine code of assembly code into a sequence of assembly instructions. and ; S2. Construct the prompt word based on the architecture information, compiler information, and assembly code. and ;Will and Input a finely tuned large language model to generate intermediate language representations. and ; S3, Intermediate Language Representation and By applying a uniform optimization transformation, a unified intermediate language representation is obtained. and ; S4. Intermediate language representation and The process involves unifying variable names and mapping intermediate language instructions to semantic atoms, resulting in a set of semantic atoms. and Construct a semantic flow graph and ; S5. Employ a graph embedding model to integrate semantic flow graphs. and Mapping to vector representation and ,calculate and similarity .
2. The binary code similarity detection method based on a unified intermediate language representation according to claim 1, characterized in that, The fine-tuned large language model was obtained through supervised fine-tuning based on a training set with diverse compilation methods. The fine-tuning included: Step 1: Collect source code; Step 2: Compile the source code in various ways based on different configuration combinations; Step 3: Construct function mapping pairs based on the executable files obtained from the diverse compilations and their corresponding intermediate language files; Step 4: Construct a fine-tuning dataset based on function mappings; each sample in the fine-tuning dataset is a tuple. ,in, Indicates text instructions. This represents an intermediate language function.
3. The binary code similarity detection method based on a unified intermediate language representation according to claim 2, characterized in that, The source code is compiled in a variety of ways based on different configuration combinations, including different instruction set architectures, different compilers, and different optimization levels.
4. The binary code similarity detection method based on a unified intermediate language representation according to claim 2, characterized in that, The supervised fine-tuning aims to minimize the model's performance under given conditions. The negative log-likelihood loss of the target intermediate language sequence generated under the given conditions.
5. The binary code similarity detection method based on a unified intermediate language representation according to claim 1, characterized in that, The construction of semantic flow graph and ,include: S41, Traversal Standardize the naming of all variables in the system; S42. Define a finite, closed set of semantic atoms. Each semantic atom represents a basic program operation intent that is independent of the underlying hardware and specific syntax; S43. Based on the semantic atom sequences obtained from the mapping and their contextual relationships in the intermediate representation, construct a directed semantic flow graph. .
6. The binary code similarity detection method based on a unified intermediate language representation according to claim 5, characterized in that, Semantic atoms include: Arithmetic operation atoms: arithmetic addition, arithmetic subtraction, arithmetic multiplication, arithmetic division, logical left shift; Bitwise operation atoms: bitwise AND, bitwise OR, bitwise XOR; Atomic memory operations: memory read, memory write; Control flow atoms: conditional branch, unconditional branch, function return; Special operation atoms: phi node, function call, comparison.
7. The binary code similarity detection method based on a unified intermediate language representation according to claim 5, characterized in that, The construction of the directed semantic flow graph ,include: S431. Map intermediate language statements into semantic atoms using a deterministic mapping function; S432, from Extract control flow graph information and definitions - use chain information to initialize an empty graph; S433, Generate atomic operation nodes; including: Step 1: Traverse the sequence of semantic atoms and create a corresponding graph node for each semantic atom; Step 2: Analyze the control flow atoms in the control flow graph and semantic atom sequence, identify high-level control structures, and create a control structure node for each high-level control structure; S434. Construct the directed edge structure between nodes; S435. Construct a semantic flow graph using chain information based on semantic atomic sequences and definitions.
8. The binary code similarity detection method based on a unified intermediate language representation according to claim 7, characterized in that, The directed edge structure between the nodes includes: Control flow edges are established between atomic nodes based on the input control flow graph information. Data flow edges are established between atomic nodes that define a value and atomic nodes that use that value, based on the definition of the input and using chain information. An edge is established between a control structure node and all atomic nodes or other structure nodes contained within the control structure node.
9. The binary code similarity detection method based on a unified intermediate language representation according to claim 1, characterized in that, The calculation and similarity The cosine similarity is used as the similarity score.
10. A binary code similarity detection system based on a unified intermediate language representation, characterized in that, The binary code similarity detection method based on a unified intermediate language representation as described in any one of claims 1 to 9 comprises: a preprocessing module, a conversion module, a unified optimization module, a unified representation module, and a detection module; the preprocessing module receives and processes binary files, extracts various low-level assembly instructions required to generate the intermediate language representation, the conversion module converts the low-level assembly instructions into a unified high-level intermediate language, the unified optimization module normalizes the high-level intermediate language to eliminate syntactic and structural variations introduced by different compiler optimization levels, the unified representation module abstracts the normalized intermediate language into a robust graph structure representation, and the detection module quantizes the graph structure representation into a numerical vector and calculates the output similarity.