Code similarity detection method based on execution semantics

Abstract

The invention discloses a code similarity detection method based on execution semantics, which adopts an end-to-end simulation execution mechanism to guide a model to model an instruction through a dynamic execution behavior of the instruction so as to deeply understand and analyze semantic connotation of codes and extract representation with execution semantic features; carrying out disassembling and control flow diagram construction on the binary program by utilizing a reverse analysis tool, and carrying out statistics and standardization processing on assembly instructions in the basic blocks so as to screen out key instructions with semantic representativeness; simulating an execution process of the instruction by adopting a Transform model, analyzing and capturing a semantic behavior of the instruction in a specific context, and further generating an instruction embedding representation with execution semantic information; and finally, modeling structure information of nodes in the control flow graph by means of a graph matching neural network, fusing execution semantics among basic blocks, constructing a function-level representation, and realizing accurate similarity measurement through a cosine distance.

Description

Technical Field

[0001] The present invention belongs to the field of artificial intelligence technology, and specifically relates to a code similarity detection method based on execution semantics. Background Art

[0002] In today's rapidly evolving information technology era, software development has evolved from simple coding to a more complex and systematic process. With the rise of open source culture, developers have easy access to a vast array of open source resources. The widespread use of open source components and third-party libraries has significantly accelerated development, but it has also increased the difficulty of maintaining code quality control. Against this backdrop, binary code similarity detection (BCSD) technology has become particularly important. BCSD technology can be applied to a variety of tasks, such as vulnerability detection, malware classification, and code plagiarism detection. With the rapid development of artificial intelligence (AI) technology, AI-based binary code similarity detection (BCSD) methods have emerged. These methods typically embed target binary code (e.g., functions) into a vector space and compare them by calculating the similarity between vectors. However, most of these methods draw on natural language processing (NLP) techniques and treat assembly code as if it were human language, ignoring the core semantics of code and its execution effects. Although existing learning-based methods have made significant progress in static code analysis, they are disconnected from the execution semantics of programs. This makes it difficult for models to accurately capture the true semantics of code when faced with complex code structures or obfuscated code.

[0003] In the prior art, Chinese patent application No. 2017103754254 discloses a deep learning-based binary code similarity detection method. This method extracts static features of binary code (such as opcode sequences and function call relationships) and uses a deep learning model to calculate similarity. While this method has certain advantages in static feature extraction, it fails to consider the dynamic execution semantics of the code, which may limit the detection effect when facing obfuscated or optimized code.

[0004] Chinese patent application No. 2022107899893 proposes a method for detecting binary code similarity based on graph neural networks. This method constructs a function-level control flow graph (CFG) and uses a graph neural network (GNN) for feature extraction. Ultimately, the similarity of the code is determined by calculating the similarity of the graph embedding vectors. While this method has certain advantages in analyzing control flow graphs, it still relies on static analysis techniques and fails to fully capture the dynamic execution semantics of the code.

[0005] Chinese patent application No. 2023101238406 discloses a binary code similarity detection method based on semantic enhancement. This method enhances the representation of code semantics by combining static features and dynamic execution traces. While this method incorporates dynamic execution information to a certain extent, its dynamic analysis relies on a limited number of execution paths and fails to fully cover the execution semantics of the code.

[0006] Chinese patent application No. 2024104950365 proposes a binary code similarity detection method based on multimodal fusion. This method improves detection accuracy by fusing static code features (such as control flow graphs and opcode sequences) with dynamic features (such as execution traces). While this method is innovative in its multimodal feature fusion, its dynamic feature extraction still relies on a limited number of execution paths and fails to fully capture the execution semantics of the code.

[0007] Chinese patent application No. 2024113965764 discloses a detection method: calling a control flow graph conversion module to convert the code to be detected into a control flow graph, encoding the topological structure of the control flow graph to obtain a node feature vector; then constructing a graph edit distance calculation model; using a model loss function to train the graph edit distance calculation model, calling the trained graph edit distance calculation model to simultaneously predict the graph edit distance and node matching confidence matrix between two control flow graphs, where the graph edit distance serves as a quantitative indicator of code similarity, and the node matching confidence matrix can generate a graph edit path. This method achieves code similarity detection through graph edit distance and graph matching technology, but it still relies on static control flow graph analysis and fails to fully capture the dynamic execution semantics of the code. As a result, the detection effect may be affected when facing complex code structures or obfuscated code.

[0008] Chinese patent application No. 2024113798988 discloses a method for detecting similarity between binary codes across different architectures. This method disassembles two binary code files to extract corresponding binary code function information. This information is then fed into a pre-trained multimodal cross-architecture binary code similarity detection model based on a twin network architecture, which then outputs similarity detection results. While this method achieves cross-architecture code similarity detection through a twin network architecture, it still relies on static code features and fails to fully consider the execution semantics of the code, limiting its accuracy and robustness in complex scenarios.

[0009] While these existing technologies have made some progress in static code analysis or limited dynamic analysis, they fail to fully capture the dynamic execution semantics of the code, which limits the accuracy and robustness of code similarity detection. To address this issue, the present invention proposes a code similarity detection method based on execution semantics. This method simulates the execution process of assembly code end-to-end, enabling the model to deeply extract the execution semantic features of the code, providing strong technical support for the field of code similarity detection. A search revealed no similar patent documents. Summary of the Invention

[0010] The purpose of this invention is to provide a code similarity detection method based on execution semantics to overcome the limitations of traditional code similarity detection methods. By simulating the execution process of assembly code end-to-end, this invention can deeply understand the dynamic behavior characteristics of the code and accurately capture the actual runtime performance of functions, thereby effectively improving the accuracy and robustness of code similarity detection.

[0011] The technical solution of the present invention is: a code similarity detection method based on execution semantics, comprising the following steps:

[0012] Step 1: Preprocess the assembly instructions of the code segment, filter out the instructions that frequently appear in different programs through statistical analysis, and standardize the retained instructions to improve the efficiency of model training;

[0013] Step 2: Use the Transformer model to simulate the execution of instructions. The model input is the instruction and its corresponding execution environment (such as the current register state). The model output is the state change after the instruction is executed. Through large-scale training, the model can learn the execution semantics of the instruction and obtain instruction modeling based on execution behavior.

[0014] Step 3: We construct a control flow graph (CFG) to represent the structural information of the input function, sum the instruction embeddings within each basic block, generate a comprehensive basic block embedding, and use GMN to learn the overall structure of the control flow graph to generate a function-level graph embedding.

[0015] Step 4: Calculate the similarity score of the two input functions based on the model. The score is compared based on the graph embedding of the two and the final code similarity result is output.

[0016] Step 5: Test the vulnerability detection capability of the present invention.

[0017] Furthermore, step 1 specifically includes first parsing a large-scale assembly code corpus and counting the frequency of occurrence of various instructions; traversing each instruction in the corpus through a script, recording the number of occurrences of each instruction, and generating a frequency distribution table; based on the statistical results, defining instructions with an occurrence frequency exceeding 5% of the total number of instructions in the corpus as high-frequency instructions, and removing instructions below this threshold from the corpus; the purpose of this step is to reduce the interference of noise data while retaining representative instruction patterns;

[0018] When processing the function pairs to be compared, low-frequency instructions are first removed. Specifically, for each function, its instruction sequence is traversed and all instructions that do not meet the frequency threshold are removed. This operation not only reduces the complexity of subsequent processing but also ensures that the analysis focuses on high-frequency instructions, which often represent the core logic of the program. Next, the retained instructions are normalized. During the normalization process, all instructions are reformatted into a unified two-operand form. The purpose of this step is to eliminate the diversity of instruction formats, making the subsequent similarity analysis more consistent and accurate.

[0019] For three-operand instructions, decompose them into multiple two-operand instructions that can produce the same execution effect. For example, the execution effect of the three-operand instruction [imul,al,bl,16] is to multiply the value in register bl by the immediate value 16 and store the result in register al; disassemble it into the following equivalent two-operand instructions: [mov,al,bl]

[0020] and [imul,bl,16]`; this decomposition ensures that the semantics of the instruction remain unchanged while meeting the format requirements of the double operand; for single-operand instructions, they are adapted to the double operand format by padding the operand with zeros, for example, the single-operand instruction `[inc,eax]`

[0021] will be converted to `[inc,eax,0]`, where `0` serves as a placeholder operand. This processing ensures the formal consistency of all instructions, facilitating subsequent analysis and comparison. Through the above steps, we not only simplify the instruction set but also ensure the uniformity of the instruction format, laying a solid foundation for subsequent function similarity analysis.

[0022] Furthermore, the step 2 is specifically to use the Transformer model to simulate the execution of the assembly instruction; the input of the model consists of two parts: the embedding vector of the assembly instruction and the embedding representation of the execution environment; the embedding vector of the assembly instruction is generated by decomposing the instruction into opcodes and operands and then using the pre-trained Word2Vec model; the execution environment is represented in the form of an array representing the register state and further embedded into a high-dimensional vector; the output of the model is a one-dimensional array, which represents the semantic features and register state changes after the instruction is executed; during the training process, the model processes one basic block in the control flow graph CFG each time; for each instruction, the model receives the current instruction and its corresponding execution environment state, and generates an updated register array to reflect the state change caused by the instruction execution; this updated state will be used as the input of the next instruction, thereby realizing automatic regression processing of continuous instructions;

[0023] To enhance the generalization ability of the model, it is first trained using real assembly code sequences so that it can observe and learn actual instruction patterns and execution behaviors. At the same time, to prevent overfitting and improve the robustness of the model, instructions are enhanced by randomly replacing opcodes and operands to generate diverse training data containing uncommon and complex instructions. In addition, in each round of training, the execution environment array is initialized with random values to ensure that the model can adapt to different initial states. For a large number of immediate values in the assembly code, modular operations are used to limit them to a controllable range, thereby ensuring the stability and accuracy of the model. The model's loss function uses CrossEntropyLoss, and the optimizer selects AdamW. The initial learning rate is 0.001, and a learning rate decay strategy is adopted to reduce the learning rate by 20% every 10 rounds. If the learning rate is lower than 0.00001, the training is terminated, and the results of the last round are saved as the final performance.

[0024] Furthermore, the step 3 is specifically as follows: first, convert the code to be compared into a control flow graph, where each node in the graph represents a basic block and each edge represents a control flow; define the graph in the form of G = (V, E), where V is a set of basic blocks and EE is a set of control flow edges; each basic block contains a set of consecutive assembly instructions and has no branch or jump instructions; next, use the pre-trained Transformer model in step 2 to encode all instructions in each basic block; specifically, for each instruction in the basic block, the model generates its corresponding embedding vector, which captures the semantic information of the instruction; then, average the embedding vectors of all instructions in the basic block to generate the overall embedding vector of the basic block as the semantic representation of the basic block. This process can be formally expressed as:

[0025]

[0026] Among them, B represents a basic block, I i represents the i-th instruction in the basic block, n is the number of instructions in the basic block, Transformer(I i ) is the embedding vector of the i-th instruction; after obtaining the embedding vectors of all basic blocks, the control flow graph of the function is encoded using a graph matching neural network; the goal of the graph matching neural network is to calculate the similarity between two control flow graphs; for this purpose, a loss function based on contrastive loss is defined as follows:

[0027] Loss=Max(0,γ-t(1-d(G1,G2)))

[0028]

[0029] where t∈{-1,+1} is the label of the function pair, d(G1,G2) is the Euclidean distance between the graph embedding vectors, represents the graph embedding vector of G1; γ is a hyperparameter set to 0.75; for similar pairs, this loss function will make the distance d(G1, G2) less than 1-γ; for dissimilar pairs, it will encourage the distance d(G1, G2) to be greater than 1+γ.

[0030] Furthermore, step 4 is specifically as follows: after obtaining the graph embedding representations G1 and G2 of the two functions, the Euclidean distance is used as a measure of function similarity; the calculation formula of the Euclidean distance is as follows:

[0031]

[0032] Among them, G 1i and G 2i Denote the i-th dimension eigenvalues of the graph embedding vectors G1 and G2, respectively, and n is the dimension of the embedding vector. To determine whether two functions are similar, a threshold θ = 0.5 is set. When the Euclidean distance d(G1, G2) between the two graph embedding vectors is less than 0.5, the model determines that the pair of functions are similar. Conversely, when the Euclidean distance d(G1, G2) is greater than or equal to 0.5, the model outputs that the two functions are dissimilar. This judgment rule can be formally expressed as:

[0033]

[0034] Through the above method, the semantic similarity between two functions can be efficiently measured, and accurate similarity judgment can be made based on a predefined threshold.

[0035] Furthermore, after step 4, a vulnerability detection capability test is performed.

[0036] The code similarity detection method based on execution semantics of the present invention overcomes the limitations of traditional methods in code similarity detection. By simulating the execution process of assembly code end-to-end, the present invention can deeply analyze the dynamic behavior characteristics of the code and accurately capture the performance of the function during actual runtime, thereby effectively improving the accuracy and robustness of code similarity detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings in the embodiments. The following drawings are only drawings in the embodiments of the present invention.

[0038] Figure 1 It is a business process diagram of the present invention;

[0039] Figure 2 This is the specific training process of the instruction embedding model of this embodiment;

[0040] Figure 3 is a structural diagram of the detection system of this embodiment;

[0041] Figure 4 This is a structural diagram of the GMN network provided in this embodiment;

[0042] Figure 5 This is a comparison chart of the vulnerability detection performance of the method provided in this embodiment and other methods. DETAILED DESCRIPTION

[0043] In order to make the objectives, technical solutions and advantages of the present invention more clear and understandable, the present invention is further described in detail below with reference to the accompanying drawings and embodiments.

[0044] Example: See Figure 1 ,A code similarity detection method based on execution semantics,

[0045] Step 1: Preprocess the assembly instructions of the code segment, filter out the instructions that frequently appear in different programs through statistical analysis, and standardize the retained instructions to improve the efficiency of model training;

[0046] Step 2: Use the Transformer model to simulate the execution of instructions. The model input is the instruction and its corresponding execution environment (such as the current register state). The model output is the state change after the instruction is executed. Through large-scale training, the model can learn the execution semantics of the instruction and obtain instruction modeling based on execution behavior.

[0047] Step 3: We construct a control flow graph (CFG) to represent the structural information of the input function, sum the instruction embeddings within each basic block, generate a comprehensive basic block embedding, and use GMN to learn the overall structure of the control flow graph to generate a function-level graph embedding.

[0048] Step 4: Calculate the similarity score of the two input functions based on the model. The score is compared based on the graph embedding of the two and the final code similarity result is output.

[0049] Step 5: Test the vulnerability detection capability of the present invention.

[0050] Specifically, we used the Cisco dataset released by Marcelli et al. in 2022. This dataset contains seven popular open source projects compiled for three different architectures (x86, ARM, etc.), with 32-bit and 64-bit versions available, covering five different optimization levels (such as O0, O1, O2, O3, and Os). By performing a sampling statistical analysis of the entire dataset, we extracted 200,000 functions from various binary files in the dataset, totaling 23.04 million instructions. Based on this data, we counted the instructions that frequently appear in different programs and screened out high-frequency instructions, as shown in Table 1.

[0051]

[0052]

[0053] Table 1 Frequency of use of various instructions (partial)

[0054] The specific steps are:

[0055] In the embodiment, step 1 includes the following operations: first, input the original binary function and extract its control flow graph (CFG) and assembly code information using the disassembly tool IDA. Then, based on the corpus statistics shown in Table 1, remove low-frequency instructions appearing in the function to reduce the interference of noise data and retain representative instruction patterns. Then, standardize the retained instructions and reformat all instructions into a unified two-operand form. For a three-operand instruction, such as [imul, al, bl, 16], its execution effect is to multiply the value in register bl by the immediate value 16 and store the result in register al. We disassemble it into equivalent two-operand instructions [mov, al, bl] and [imul, bl, 16]. For a single-operand instruction, such as [inc, eax], it is converted to [inc, eax, 0] by padding the operand with zeros to ensure the formal consistency of all instructions. Through the above steps, we achieve preprocessing of binary functions, ensure the uniformity of instruction formats, and lay a solid foundation for subsequent similarity analysis.

[0056] In an embodiment, step 2 includes: Figure 2 As shown in Figure 1, the Transformer model is used to simulate the execution of assembly instructions. The input of the model consists of two parts: the embedding vector of the assembly instruction and the embedding representation of the execution environment. First, the execution environment array is defined to represent the register state and memory state when the instruction is executed. The execution environment array is in the form of:

[0057] Env=[AH,AL,…,Memory,CallCount,ImmediateValues,OpResults]

[0058] Among them, the register state (such as AH, AL, R8, XMM0, etc.) stores the value of the current register, the memory state records the information of interaction with the memory, the call count (Call Count) counts the number of times the CALL instruction is executed, the immediate value (ImmediateValues) stores the immediate value in the instruction, and the operation result (OpResults) is used to handle overflow and underflow problems. Then, the opcode and operand of the assembly instruction are input into the encoding layer of the Transformer model together with the execution environment array for processing to generate the embedding vector of the instruction and the embedding representation of the execution environment. During the training process, the model processes a basic block in the control flow graph each time, generates an updated register array for each instruction, reflects the state changes caused by the execution of the instruction, and uses the updated state as the input of the next instruction to realize automatic regression processing of continuous instructions. The true label YT is generated by executing the function Exec, and the cross entropy loss function is used to calculate the difference between the model prediction result and the true label:

[0059]

[0060] During training, instruction embeddings in the model's encoding layer are updated via backpropagation, enabling them to capture features highly relevant to the programming task. To enhance the model's generalization and mitigate the risk of overfitting, data augmentation strategies are employed, including random replacement of opcodes and operands, initialization of the execution environment array with random values, and modulo operations on immediate values (e.g., modulo 256).

[0061] In an embodiment, step 3 includes, first, converting the code to be compared into a control flow graph, where each node in the graph represents a basic block and each edge represents a control flow. The graph is defined in the form of G = (V, E), where V is a set of basic blocks and E is a set of edges of the control flow. Each basic block contains a set of consecutive assembly instructions and has no branch or jump instructions. Next, all instructions in each basic block are encoded using the pre-trained Transformer model in step 2. Specifically, for each instruction in the basic block, the model generates its corresponding embedding vector, which captures the semantic information of the instruction. Then, the embedding vectors of all instructions in the basic block are averaged to generate the overall embedding vector of the basic block as the semantic representation of the basic block. This process can be formally expressed as:

[0062]

[0063] Among them, B represents a basic block, I i represents the i-th instruction in the basic block, n is the number of instructions in the basic block, Transformer(I i ) is the embedding vector of the i-th instruction. Figure 3 As shown in , after obtaining the embedding vectors of all basic blocks, the control flow graph of the function is encoded using a graph matching neural network. The goal of the graph matching neural network is to calculate the similarity between two control flow graphs, such as Figure 4 To this end, we define a loss function based on contrast loss, which is as follows:

[0064] Loss=Max(0,γ-t(1-d(G1,G2)))

[0065]

[0066] where t∈{-1,+1} is the label of the function pair, d(G1,G2) is the Euclidean distance between the graph embedding vectors, represents the graph embedding vector of G1. γ is a hyperparameter, which we set to 0.75. For similar pairs, this loss function will make the distance d(G1, G2) less than 1-γ; for dissimilar pairs, it will encourage the distance d(G1, G2) to be greater than 1+γ.

[0067] In an embodiment, step 4 includes, specifically, after obtaining the graph embedding representations G1 and G2 of the two functions, we use the Euclidean distance as a measure of function similarity. The calculation formula of the Euclidean distance is as follows:

[0068]

[0069] Among them, G 1i and G 2iDenote the i-th dimension eigenvalues of the graph embedding vectors G1 and G2, respectively, and n is the dimension of the embedding vector. To determine whether two functions are similar, we set a threshold θ = 0.5. When the Euclidean distance d(G1, G2) between two graph embedding vectors is less than 0.5, the model determines that the pair of functions are similar; conversely, when the Euclidean distance d(G1, G2) is greater than or equal to 0.5, the model outputs that the two functions are dissimilar. This judgment rule can be formally expressed as:

[0070]

[0071] Through the above method, we can efficiently measure the semantic similarity between two functions and make accurate similarity judgments based on predefined thresholds.

[0072] In the embodiment, step 5 includes: we selected five representative CVE instances from the known vulnerability database, including CVE-2016-2182, CVE-2016-2176, CVE-2016-2180, CVE-2019-1563 and CVE-2022-3006, covering vulnerabilities of different years, types and severity levels. In order to make the vulnerability detection task more challenging and also make it closer to the actual application scenario, we also applied a common open source software obfuscator llvm-Obfuscator to compile the code using four obfuscation schemes, and finally compared the code similarity detection method proposed in the present invention with the existing Trex and GMN methods. The experimental results are as follows: Figure 5 As shown in the results, our method outperforms the comparison methods in all five CVE vulnerability detection tasks. Our method's advantages lie in its stronger semantic capture, cross-architecture adaptability, and anti-obfuscation capabilities, enabling it to effectively handle complex instruction patterns and binary code from different architectures. Experimental results demonstrate the significant practicality and advancement of our method in vulnerability detection tasks, providing a powerful tool for binary code security analysis.

[0073] The above description is merely a preferred embodiment of the present invention and does not constitute any form of limitation to the present invention. Any simple modification, equivalent change and modification made to the above embodiment based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A code similarity detection method based on execution semantics, used in the field of binary code similarity detection, characterized by: The following steps are involved: Step 1: Preprocess the assembly instructions of the code segment, filter out the instructions that frequently appear in different programs through statistical analysis, and standardize the retained instructions to improve the efficiency of model training; Step 2: Use the Transformer model to simulate the execution of instructions. The model input is the instruction and its corresponding execution environment, such as the current register state. The model output is the state change after the instruction is executed. Through large-scale training, the model can learn the execution semantics of the instruction and obtain instruction modeling based on execution behavior. Step 3: Construct a control flow graph (CFG) to represent the input function structure, sum the instruction embeddings within each basic block, generate a comprehensive basic block embedding, and use GMN to learn the overall structure of the control flow graph to generate a function-level graph embedding. Step 4: Calculate the similarity score of the two input functions based on the model. The score is compared based on the graph embedding of the two and the final code similarity result is output.

2. The code similarity detection method based on execution semantics according to claim 1, characterized in that: Specifically, step 1 includes first parsing a large-scale assembly code corpus and counting the frequency of occurrence of various instructions; traversing each instruction in the corpus through a script, recording the number of occurrences of each instruction, and generating a frequency distribution table; based on the statistical results, defining instructions whose occurrence frequency exceeds 5% of the total number of instructions in the corpus as high-frequency instructions, and removing instructions below this threshold from the corpus; When processing the function pairs to be compared, low-frequency instructions are first removed. Specifically, for each function, its instruction sequence is traversed and all instructions that do not meet the frequency threshold are removed. Next, the remaining instructions are normalized. During the normalization process, all instructions are reformatted into a unified two-operand form. For three-operand instructions, they are decomposed into multiple two-operand instructions that can produce the same execution effect; for single-operand instructions, they are adapted to the two-operand format by filling zero operands.

3. The code similarity detection method based on execution semantics according to claim 1, characterized in that: Specifically, step 2 is to use the Transformer model to simulate the execution of assembly instructions; the input of the model consists of two parts: the embedding vector of the assembly instruction and the embedding representation of the execution environment; the embedding vector of the assembly instruction is generated by decomposing the instruction into opcodes and operands and then using the pre-trained Word2Vec model; the execution environment is represented in the form of an array representing the register state and further embedded into a high-dimensional vector; the output of the model is a one-dimensional array, which represents the semantic features and register state changes after the instruction is executed; during the training process, the model processes one basic block in the control flow graph CFG each time; for each instruction, the model receives the current instruction and its corresponding execution environment state, and generates an updated register array to reflect the state change caused by the instruction execution; this updated state will be used as the input of the next instruction, thereby realizing automatic regression processing of consecutive instructions; To enhance the generalization ability of the model, it is first trained using real assembly code sequences so that it can observe and learn actual instruction patterns and execution behaviors. At the same time, to prevent overfitting and improve the robustness of the model, instructions are enhanced by randomly replacing opcodes and operands to generate diverse training data containing uncommon and complex instructions. In addition, in each round of training, the execution environment array is initialized with random values to ensure that the model can adapt to different initial states. For a large number of immediate values in the assembly code, modular operations are used to limit them to a controllable range, thereby ensuring the stability and accuracy of the model. The model's loss function uses CrossEntropyLoss, and the optimizer selects AdamW. The initial learning rate is 0.001, and a learning rate decay strategy is adopted to reduce the learning rate by 20% every 10 rounds. If the learning rate is lower than 0.00001, the training is terminated, and the results of the last round are saved as the final performance.

4. The code similarity detection method based on execution semantics according to claim 1, characterized in that: Specifically, step 3 is as follows: first, convert the code to be compared into a control flow graph, where each node in the graph represents a basic block and each edge represents a control flow; define the graph in the form of G = (V, E), where V is a set of basic blocks and EE is a set of control flow edges; each basic block contains a set of consecutive assembly instructions without branch or jump instructions; next, use the pre-trained Transformer model in step 2 to encode all instructions in each basic block; specifically, for each instruction in the basic block, the model generates its corresponding embedding vector, which captures the semantic information of the instruction; then, average the embedding vectors of all instructions in the basic block to generate the overall embedding vector of the basic block as the semantic representation of the basic block. This process can be formally expressed as: Among them, B represents a basic block, I i represents the i-th instruction in the basic block, n is the number of instructions in the basic block, Transformer(I i ) is the embedding vector of the i-th instruction; after obtaining the embedding vectors of all basic blocks, the control flow graph of the function is encoded using a graph matching neural network; for this purpose, a loss function based on contrastive loss is defined as follows: Loss=Max(0,γ-t(1-d(G1,G2))) where t∈{-1,+1} is the label of the function pair, d(G1,G2) is the Euclidean distance between the graph embedding vectors, represents the graph embedding vector of G1; γ is a hyperparameter set to 0.75; for similar pairs, this loss function will make the distance d(G1, G2) less than 1-γ; for dissimilar pairs, it will encourage the distance d(G1, G2) to be greater than 1+γ.

5. The code similarity detection method based on execution semantics according to claim 1, characterized in that: Specifically, step 4 is to obtain the graph embedding representations G1 and G2 of the two functions and then use the Euclidean distance as a measure of function similarity. The calculation formula of the Euclidean distance is as follows: Among them, G 1i and G 2i Denote the i-th dimension eigenvalues of the graph embedding vectors G1 and G2, respectively, and n is the dimension of the embedding vector. To determine whether two functions are similar, a threshold θ = 0.5 is set. When the Euclidean distance d(G1, G2) between the two graph embedding vectors is less than 0.5, the model determines that the pair of functions are similar. Conversely, when the Euclidean distance d(G1, G2) is greater than or equal to 0.5, the model outputs that the two functions are dissimilar. This judgment rule can be formally expressed as: Through the above method, the semantic similarity between two functions can be efficiently measured, and accurate similarity judgment can be made based on a predefined threshold.

6. The code similarity detection method based on execution semantics according to claim 1, characterized in that: After step 4, a vulnerability detection capability test is performed.

Images