Method for detecting similar vulnerabilities in firmware based on large model

Abstract

The invention provides a method for detecting similar vulnerabilities in firmware based on a large model. The invention provides the method for detecting the similar vulnerabilities in the firmware based on the large model. The invention provides a method for detecting similar vulnerabilities in firmware based on a large model, aiming at the problems of high false alarm rate, high manual checking cost and the like generally existing in the practical application of a binary code similarity detection technology based on deep learning due to the black box characteristic of a deep learning model. According to the method, the data dependency relationship of the variables in the key statement is analyzed, and the core instruction for triggering the vulnerability is filtered out, so that the accuracy of vulnerability semantic comparison is improved. The method comprises the steps of extracting potential vulnerability trigger statements and semantic features of known vulnerabilities, performing semantic matching on potential vulnerability signatures and known vulnerability signatures, and realizing positioning of similar vulnerabilities and tracing of vulnerability causes. According to the method, true positive samples can be accurately discriminated, vulnerability cause analysis is synchronously generated, and the complexity of manual verification is remarkably reduced.

Description

Technical Field

[0001] This invention relates to binary code similarity detection technology, and more specifically, to a firmware similarity vulnerability detection method based on a large model, which aims to accurately identify true positive samples and simultaneously generate vulnerability cause analysis, significantly reducing the complexity of manual verification. Background Technology

[0002] The Internet of Things (IoT) has deeply penetrated all aspects of human production and life. While devices such as routers and network cameras bring convenience, they also pose significant security risks. The embedded software (firmware) of IoT devices harbors vulnerabilities that pose a serious threat to personal privacy, property security, and public safety.

[0003] The main reasons for firmware vulnerabilities in IoT devices include the following: First, the lag in open-source component management mechanisms. Manufacturers often focus on feature implementation while neglecting timely updates and maintenance of components. A Synopsys report points out that 91% of projects contain component versions that are at least 10 versions behind the current version. Second, the widespread reuse of open-source code. Due to the similarity in functionality between IoT devices from different manufacturers and models, developers can significantly shorten the development cycle by reusing open-source code. In the IoT industry, 50% of the code in the codebase comes from open-source code. Third, IoT developers often cause security problems due to similar oversights during the development process.

[0004] Currently, Binary Code Similarity Detection (BCSD) technology has been widely used in research addressing the aforementioned problems. This technology infers the existence of potential vulnerabilities in the target binary code by measuring the semantic similarity between unknown binary code and known vulnerable binary code.

[0005] Current BCSD techniques largely focus on function-level changes, neglecting the core characteristics of the vulnerability itself. Research by FirmRec shows that vulnerabilities are typically caused by code reuse or similar flawed code logic. Although deep neural networks use pre-training techniques like Safe to extract and compare semantic features of binary code, the lack of interpretability of neural networks makes it impossible to verify whether they have truly learned the vulnerability semantics. In patch detection tasks, minor code changes easily lead to false positives; while when detecting similar vulnerable code logic, large code changes easily result in false negatives.

[0006] BCSD technology, which compares the similarity of binary code using neural networks, avoids the aforementioned problems. However, the differences between binary code and the optimization levels of different architectures are significant. Yan Yintong, Zheng Jianyun, and others adopted a method based on LLVM (Low Level Virtual Machine) Intermediate Representation (IR) to alleviate the problem of instruction differences caused by compiling the same source function code on different architectures. The XLIR scheme constructs a mapping relationship between function source code and binary code based on LLVM IR, effectively alleviating the difficulty of cross-language similarity comparison. Yu Zeping et al. and He Haojie et al. proposed introducing basic block or instruction attributes into the Control Flow Graph (CFG) to enrich the semantic representation of functions. However, function-level vulnerability similarity detection schemes do not focus on the core features of vulnerabilities, leading to false negatives in the detection of similar vulnerabilities. Summary of the Invention

[0007] This invention proposes a firmware similarity vulnerability detection method based on a large model. This method analyzes the data dependencies of variables in key statements to filter out the core instructions that trigger vulnerabilities, thereby improving the accuracy of vulnerability semantic comparison. This invention can quickly detect vulnerabilities similar to known vulnerabilities from massive amounts of code and interpret these vulnerabilities, effectively reducing the false positive rate of binary code similarity comparison and alleviating the difficulty of manual verification.

[0008] The objective of this invention is achieved through the following technical solution: Step 1, Data Processing Stage: Using the decompiler provided by Ghidra, the AST structure of each binary function is decompiled. Due to the characteristics of the Ghidra framework, the obtained AST structure is independent of the processor architecture. Then, a data dependency analysis algorithm is used to slice the binary file and construct Servlet and Feature. Step 2, Data Normalization Stage: To extract semantic information from Servlet, its information needs to be normalized. Based on the characteristics of the Ghidra decompiler, offset information is automatically added when naming variables. The variable name and its offset need to be separated into two independent tokens. Global variables, user-defined functions, and large numbers that appear infrequently are replaced with uniform characters. When processing numbers, a unified format is required, such as replacing two's complement with negative numbers and ASCII code representation with characters. Step 3, Semantic Extraction Stage: After Servlet normalization, each token is treated as a word, and each parameter slice of the callee function in KeyStatistic is treated as a sentence. Pre-training is performed using Word2vec to obtain the word embedding for each token. Based on the token's word embedding, each word in the Servlet is converted into a vector and input into the neural network. The output of each LSTM layer is used as the input to the Attention mechanism. That is, the Self-attention method is used, where the output vector of the LSTM is used as the input to the Attention mechanism. i The semantic vector O is obtained as input to the Attention mechanism. i Then, a fully connected layer is used to fuse these outputs to obtain the semantic vector V of Silence. Simultaneously, by designing specific prompts combined with Feature content, the large model is guided to identify vulnerabilities and analyze their causes. Step 4, Model Training Phase: Binary files with different architectures generated by compiling the same function source code using different compilers and optimization levels are defined as similar samples. Correspondingly, simulacrum extracted from two similar binary files are defined as similar pairs, while dissimilar simulacrum are obtained through random sampling. The two simulacrum are processed by a bidirectional LSTM network with shared weights to generate semantic vectors V, and their similarity is calculated using cosine distance. Next, the cross-entropy algorithm is used to calculate the loss value between this similarity result and the label. Finally, the Adam (Adaptive Moment Estimation) optimizer is used for parameter optimization, combined with stochastic gradient descent for iterative updates until model training is complete. Step 5, Vulnerability Detection Phase: Use a common similarity comparison model to perform semantic similarity analysis on code snippets, and at the same time use a large-scale model to detect vulnerabilities and output detailed vulnerability information. Attached Figure Description

[0009] Figure 1 This section lists the relevant functions before and after the CVE-2023-39471 vulnerability was patched. Figure 2 Similar vulnerabilities exist across different devices; Figure 3 The implementation process of the example described in this invention; Figure 4 This is a diagram illustrating the training process of the model in this invention. Specific implementation

[0010] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments, and do not constitute a limitation of the present invention. All other implementation methods obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the protection scope of the present invention.

[0011] The firmware similarity vulnerability detection method based on a large model described in this embodiment of the invention includes the following steps: 1) Data Processing Stage: In the IoT device environment, vulnerabilities often arise from the improper use of specific functions. The statements that call these functions are defined as key statements. To simplify the scope of the experiment, this paper focuses on the scenario where the function call statements listed in Table 1 are used as key statements. The key statement signature (KeyStatementSignature, KS) is used to comprehensively describe the information of potential vulnerability points, and its expression is shown in formula (1). (1) Here, VulType indicates the type of vulnerability the statement may cause. For example, a statement calling the `system` function may lead to a command injection vulnerability, while a statement calling the `strcpy` function may lead to a buffer overflow vulnerability. `CallName` is the name of the function called by the critical statement, i.e., the callee. Depending on the callee in the critical statement, VulType has three possible values, as shown in Table 1. By performing dependency analysis on the parameters of the callee in the critical statement, a dependency chain can be obtained. Further analysis of the constants and function call sequences in the dependency chain allows for the extraction of a feature set. Table 1. Operation Code Types Buffer overflow SO Command Injection CI Arbitrary file write A / W strcpy,strcat,gets,sprintf,snprintf,vsprintf,memcpy,memmove system,popen,execl,execle,execv,execvp,execvpe fopen,open Validation mainly contains code snippets and logical information related to the cause of the vulnerability. The core of its construction process is to perform data dependency analysis on the relevant variables in KeyStatement. Due to different vulnerability types, the methods for constructing Validation also differ. Taking Stack Overflow (SO) type vulnerabilities as an example, its analysis focuses on two dimensions: buffer capacity and data source. Taking a typical strcpy function call scenario as an example, triggering a buffer overflow requires the following two core conditions to be met: (1) the data of the second parameter (target string) of the function comes from external input; (2) the allocated space of the first parameter (target buffer) of the function is less than the actual data length of the second parameter. Based on the above conditions, a differentiated strategy needs to be implemented when constructing slices: for the first parameter of the strcpy function, it is necessary to focus on analyzing its memory space allocation mechanism and accurately calculate the buffer capacity threshold; for the second parameter, it is necessary to construct a data flow tracing model, analyze the library function call chain involved in its processing logic (such as strlen, memcpy, etc.), and combine string operation semantic analysis to constrain the key factors of its value (such as formatted strings, dynamic concatenation logic, etc.). In existing related work, when using code similarity comparison models to compare the similarity of code snippets, strings with low frequency of occurrence are often normalized, which ignores the semantics of the strings themselves. Figure 2 In line 7 of (a), the string "downloadServerip" was used to obtain user input. Figure 2 (b) Line 7 uses the firmwareServerip when it receives user input. Furthermore, Figure 2 (a) line 14 and Figure 2 The strings used in line 8 of (b) also differ, but they are semantically similar. The large model has the ability to understand the semantic information of strings; this string information is then passed to the large model to determine if potential vulnerabilities exist. Specifically, features such as strings and function calls are extracted from the Servlet, and appropriate hints are added. The large model is then queried during the CallName function call process to determine the similarity between these features and known vulnerability features, as well as the reasons for the vulnerabilities. This paper designs a Feature field for vulnerability signatures, which is mainly used to store the characteristic information of the vulnerability. Under different system architectures, compilers, and optimization levels, the binary code generated by compiling the source code of the same function can differ. To eliminate the impact of these differences, SimVul uses the decompiler provided by Ghidra to obtain the AST structure decompiled for each binary function. Due to the characteristics of the Ghidra framework, the obtained AST structure is independent of the processor architecture. Furthermore, Ghidra performs a series of optimizations during the PCODE IR stage of the decompilation process, which helps to mitigate the impact of compiler and optimization levels on the binary file. Based on the Ghidra framework, this paper implements the following algorithm in the form of a Ghidra script. The algorithm starts with a KeyStatement and analyzes the parameters during function calls. The initial FuncInfo is the caller object of the KeyStatement function, and var is the variable corresponding to the callee function parameter. The algorithm flow is as follows: In line 4 of Algorithm 1, `getSameToken` is used to analyze all variables with the same name in the current function; in line 7, the `get_ref_Token` function is used to analyze the reference situation of each variable with the same name; recursive analysis is performed according to the different usage scenarios of the referenced variables. These scenarios mainly include function calls, function references, and ordinary variables. Algorithm 1: Cross-Function Variable Reference Analysis Algorithm 1 Slience = [];FuncDeep=0;RefDeep=0;CallDeep=0 2 def Sliencer(FuncInfo, var) 3 if Slience.length()>MaxTokenNum: return 4 getSameToken(chroot,var) 5 for sametoken in func_same_token: 6 Slience.add(sametoken) 7 refs,StatementType=get_ref_Token(sametoken) 8 for ref in refs: 9 if StatementType is CallFunc and CallDeep <CallDeepMax 10 CallDeepMax+=1 11 Sliencer(CallFuncInfo,ref_CallParam_n) 12 if StatementType is CurrentFuncParam and FuncDeep<FuncDeepMAX: 13 FuncDeep += 1 14 for refFunc in GetRefFunc(FuncInfo): 15 Sliencer(refFunc,ref_CallParam_n) 16 if StatementType is Var and RefDeep<RefDeepMax: 17 Sliencer(Funcinfo,ref) In the variable aliasing analysis process, to obtain more comprehensive information about the constants associated with the variables, the algorithm adopts a strategy of analyzing each variable with the same name. Although this method may introduce a small amount of irrelevant information, it can ensure that key constant information is not overlooked to the greatest extent possible. When performing variable analysis, appropriate analysis strategies should be adopted for different usage scenarios of the variables, and reasonable depth limits should be set to balance the completeness and efficiency of the analysis. Specific rules are as follows: When a variable is used as a parameter in a function call, the target function object must first be located (corresponding to CallFuncInfo in line 11 of Algorithm 1). After determining the parameter position of the variable in the function call, the corresponding parameter is analyzed inside the called function; if the variable is a parameter of the current function, the function reference relationship needs to be analyzed. The reference to the current function is obtained through the GetRefFunc function in line 14 of Algorithm 1, and the corresponding variable to be analyzed in the reference statement is determined based on the variable's position in the parameter list (line 15 of Algorithm 1); when a variable participates in statement operations as a regular variable, it is analyzed directly. To avoid the analysis process getting bogged down in infinite recursion or irrelevant details, the following depth limits are set for different analysis types: CallDeep records the analysis depth of function calls. Setting CallDeepMax to 1 follows the principle of in-depth manual analysis and avoids getting bogged down in minor function implementations; FuncDeep limits the number of levels of upward tracing of function references. Based on experience, it is usually set to 3 levels to cover the main reference relationships; RefDeep controls the number of times variables are passed through functions. Setting it to 2 times can effectively reduce the interference of irrelevant variables while ensuring the analysis of key reference chains. Besides code logic, another point to consider in Safeness is the size of variable space. Ghidra's decompilation engine analyzes the type and size of variables when identifying them, and can determine the space size based on the variable's comparison with other variables. For example... Figure 1 In line 2 of (a), Ghidra directly analyzes the buffer space size as 0x84. By extracting constants, strings, and external function calls from the Servlet, we can obtain the Feature, such as in Figure 1In the code snippet (a), the Feature will contain information such as / tmp / config.xml, ui_get_input_value, downloadServerip, and 0x84. This contains the semantic features of the current function and can be well understood by the large model. 2) Data Normalization Stage: Based on the characteristics of the Ghidra decompiler, offset information is automatically added when naming variables (e.g., 78 in local_78 represents the offset of the variable relative to the stack base address register). Since the spatial offset of a variable is an important basis for analyzing similarity, it is necessary to separate the variable name and its offset to form two independent tokens (e.g., split local_78 into local and 78). For infrequently occurring global variables, user-defined functions, and large numbers, a unified identifier is used for replacement: global variables are uniformly replaced with GLOBAL, user-defined functions with FUNC, and large numbers with IMM. Formatting information that may be contained in the string (such as formatting parameters in the printf function) is particularly important for analyzing command injection vulnerabilities. Therefore, it is necessary to extract the formatting information from the string; if no formatting information is found, it is uniformly replaced with STR. When processing numbers, since numbers have many representations, they need to be standardized to a single format: negative numbers, such as -1, may be obtained as -1 or 0xffffffff, which can be standardized to the form -1; number system conversion, the commonly encountered representation methods are decimal and hexadecimal, which can be standardized to decimal; characters may be recognized as numbers by decompilers, such as the character '\r' which may be obtained as 0xd from a decompiler, so visible characters need to be converted to characters. 3) Semantic extraction stage: After Slience normalization, each token is treated as a word, and each parameter slice of the callee function in KeyStatmen is treated as a sentence. Word2vec is used for pre-training to finally obtain the word embedding of each token. like Figure 3As shown in S1, during semantic extraction, although the LSTM output vector oi contains the complete sequence semantics, its attention to all statements is "averaged," failing to actively distinguish which statements in the sequence are key information (such as the core triggering conditions in a vulnerability description or key operation statements in a code snippet). Therefore, an Attention mechanism is needed to "weight and filter" the LSTM output, highlighting the semantic contribution of important statements. SimVul uses Self-attention to process the LSTM output. After processing by the Attention mechanism, the resulting semantic vector Oi is no longer a simple copy of the LSTM output, but a weighted representation that strengthens the semantics of important statements and weakens secondary information (the higher the weight, the greater the impact of the corresponding statement on the overall semantics). After obtaining the semantic vector Oi processed by Attention at each position, the model integrates these vectors through a fully connected layer. To extract the semantics of important statements, SimVul uses the output of each LSTM layer as the input to the Attention mechanism. Specifically, it employs a Self-attention method, using the LSTM output vector oi as the input to the Attention mechanism to obtain the semantic vector Oi. Then, a fully connected layer fuses these outputs to obtain the semantic vector V of Silence. 4) Model Training Phase: To enable the model to effectively extract semantic information from Silence, it needs to be trained. The specific training process is as follows: Figure 4 As shown. The core function of this model is to extract semantic information from Silence, and then use it for Silence similarity comparison, as well as to realize the similarity judgment of code logic information. Therefore, during the training set construction phase, this paper treats all external function calls as KeyStatements and performs a unified analysis on all parameters of the called function (callee). The dataset construction rules are as follows: binary files of different architectures generated by compiling the same function source code with different compilers and optimization levels are defined as similar samples; correspondingly, servics extracted from two similar binary files are defined as similar pairs, while dissimilar servics are obtained through random sampling. The model training process is as follows: First, two Sense objects are processed by a bidirectional LSTM network with shared weights to generate semantic vectors V, and their similarity is calculated using cosine distance. Second, the cross-entropy algorithm is used to calculate the loss value between the similarity result and the label. Finally, the Adam (Adaptive Moment Estimation) optimizer is used to optimize the parameters, and the stochastic gradient descent algorithm is used for iterative updates until the model training is completed. 5) Vulnerability Detection Phase: Experimental results show that large-scale embedded models perform poorly in code similarity comparison tasks, presumably because they struggle to accurately understand the actual functionality of code snippets. In contrast, smaller models exhibit superior performance in code similarity differentiation. Therefore, this paper employs a standard similarity comparison model for semantic similarity analysis of code snippets, while utilizing a large-scale model for vulnerability detection and outputting detailed vulnerability information. Large-scale models require sufficient known information to support semantic understanding. This paper proposes that large-scale models need three key inputs to understand code snippets: (1) an existing vulnerability information database; (2) the unknown code snippet to be analyzed; and (3) prompts to guide the thinking direction. like Figure 3 As shown in S3, the vulnerability detection process first requires building a vulnerability database based on publicly available vulnerability information. Specific steps include: manually analyzing the vulnerability principles, locating the binary file containing the vulnerability, marking the vulnerability trigger point, using the SimVul tool to extract the vulnerability signature (VS) based on the marking information, and storing it in the vulnerability database. For the analysis of unknown binary files, the first step is to locate critical statements through dangerous function calls and generate a critical statement signature (KS) using the same method as for vulnerability signature extraction. Then, the KS is compared with vulnerability signatures (VS) in the vulnerability database that have the same call names (CallName) based on their similarity, and KS with high similarity are selected. Finally, a large-scale model is used to confirm the vulnerabilities of the selected KS, and detailed vulnerability information is output. Based on the above process, by comparing the similarity between KS and VS, and combining the known vulnerability information recorded in VS with the characteristics of the unknown code fragments contained in KS, the following example of guiding prompts is designed: "It is known that a certain type of vulnerability exists in {VS features}. Through similarity analysis, it is found that {KS features} is similar to it. Please determine whether {KS features} has the same type of vulnerability. If so, please analyze the cause of the vulnerability." Finally, the authenticity of vulnerabilities in unknown binary files is verified by manually reviewing the vulnerability reports generated by large models. This paper proposes a firmware similarity vulnerability detection method based on a large model, addressing the common problems of high false positive rates and high manual verification costs in the practical application of deep learning-based binary code similarity detection techniques. This method improves the accuracy of vulnerability semantic comparison by analyzing the data dependencies of variables in key statements to filter out the core instructions that trigger the vulnerability. This invention can quickly detect vulnerabilities similar to known vulnerabilities from massive amounts of code and interpret them, effectively reducing the false positive rate of binary code similarity comparison and alleviating the difficulty of manual verification.

Claims

1. A firmware similarity vulnerability detection method based on a large model, characterized in that, The method extracts the semantic features of potential vulnerability trigger statements and known vulnerabilities, and performs semantic matching between the signatures of potential and known vulnerabilities to locate similar vulnerabilities and trace their causes; it includes the following steps: Step 1, Data Processing Stage: Using the decompiler provided by Ghidra, the AST structure of each binary function is decompiled. Due to the characteristics of the Ghidra framework, the obtained AST structure is independent of the processor architecture. Then, a data dependency analysis algorithm is used to slice the binary file and construct the Servlet and Feature. Step 2, Data Normalization Stage: To extract semantic information from Servlet, its information needs to be normalized. Based on the characteristics of the Ghidra decompiler, offset information is automatically added when naming variables. The variable name and its offset need to be separated to form two independent tokens. Global variables, user-defined functions, and large numbers that appear infrequently are replaced with uniform characters. When processing numbers, they need to be standardized to a single format, such as replacing two's complement with negative numbers and ASCII code representation with characters. Step 3, Semantic Extraction Stage: After Servlet normalization, each token is treated as a word, and each parameter slice of the callee function in KeyStatistic is treated as a sentence. Pre-training is performed using Word2vec to obtain the word embedding for each token. Based on the token's word embedding, each word in the Servlet is converted into a vector and input into the neural network. The output of each LSTM layer is used as the input to the Attention mechanism; that is, the Self-attention method is used to process the LSTM output vector. i The semantic vector O is obtained as input to the Attention mechanism. i Then, a fully connected layer is used to fuse these outputs to obtain the semantic vector V of Silence; at the same time, by designing specific prompt words and combining them with Feature content, the large model is guided to identify vulnerabilities and analyze their causes. Step 4, Model Training Phase: Binary files with different architectures generated by compiling the same function source code using different compilers and optimization levels are defined as similar samples. Correspondingly, sliences extracted from two similar binary files are defined as similar pairs, while dissimilar sliences are obtained through random sampling. Two sliences are processed by a bidirectional LSTM network with shared weights to generate semantic vectors V, and their similarity is calculated using cosine distance. Next, the cross-entropy algorithm is used to calculate the loss value between the similarity result and the label. Finally, the Adam (Adaptive Moment Estimation) optimizer is used for parameter optimization, combined with stochastic gradient descent for iterative updates until model training is complete. Step 5, Vulnerability Detection Phase: Use a common similarity comparison model to perform semantic similarity analysis on code snippets, and at the same time use a large-scale model to perform vulnerability detection and output detailed vulnerability information.

2. The firmware similarity vulnerability detection method based on a large model according to claim 1, characterized in that, The data processing stage of step 1 includes: Under different system architectures, compilers, and optimization levels, the binary code generated by compiling the source code of the same function will differ. To eliminate the impact of these differences, SimVul uses the decompiler provided by Ghidra to obtain the AST structure decompilation result of each binary function. Due to the characteristics of the Ghidra framework, the obtained AST structure is independent of the processor architecture. In addition, Ghidra performs a series of optimizations during the PCODE IR stage during decompilation, which helps to mitigate the impact of compiler and optimization levels on binary files. Based on the Ghidra framework, this paper implements the following algorithm in the form of a Ghidra script. The algorithm starts with a KeyStatement and analyzes the parameters during function calls. The initial FuncInfo is the caller object of the KeyStatement function, and var is the variable corresponding to the callee function parameter. The algorithm flow is as follows: In line 4 of Algorithm 1, the getSameToken function is used to analyze all variables with the same name in the current function; in line 7, the get_ref_Token function is used to analyze the reference situation of each variable with the same name; recursive analysis is performed according to the different usage scenarios of the referenced variables; these scenarios mainly include function calls, function references and ordinary variables; Algorithm 1: Cross-Function Variable Reference Analysis Algorithm In the process of variable aliasing analysis, in order to obtain more comprehensive information about the constants related to the variables, the algorithm adopts a strategy of analyzing each variable with the same name. Although this method may introduce a small amount of irrelevant information, it can ensure that key constant information is not missed to the greatest extent. When performing variable analysis, appropriate analysis strategies should be adopted for different usage scenarios of the variables, and reasonable depth limits should be set to balance the completeness and efficiency of the analysis. The specific rules are as follows: When a variable is used as a parameter in a function call, the target function object must first be located (corresponding to CallFuncInfo in line 11 of Algorithm 1); after determining the parameter position of the variable in the function call, the corresponding parameter is analyzed inside the called function; if the variable is a parameter of the current function, the function reference relationship needs to be analyzed; the reference of the current function is obtained through the GetRefFunc function in line 14 of Algorithm 1, and the corresponding variable to be analyzed in the reference statement is determined according to the position of the variable in the parameter list (line 15 of Algorithm 1); when the variable participates in the statement operation as an ordinary variable, it is analyzed directly. To avoid the analysis process getting bogged down in infinite recursion or irrelevant details, the following depth limits are set for different analysis types: CallDeep records the analysis depth of function calls; setting CallDeepMax to 1 follows the principle of in-depth manual analysis and avoids getting bogged down in minor function implementations; FuncDeep limits the number of levels of upward tracing of function references; based on experience, it is usually set to 3 levels to cover the main reference relationships; RefDeep controls the number of times variables are passed through functions; setting it to 2 times can effectively reduce the interference of irrelevant variables while ensuring the analysis of key reference chains. Besides the code logic, another point to pay attention to in Servence is the size of the variable space; Ghidra's decompilation engine analyzes the type and size of variables when identifying them, and the space size can be determined based on the example of the variable relative to other variables; as shown in the second row of Figure 1(a), Ghidra directly analyzes that the space size of the buffer is 0x84. By extracting constants, strings, and external function calls from the Servlet, we can obtain the Feature. For example, in the code snippet in Figure 1(a), the Feature will contain information such as / tmp / config.xml, ui_get_input_value, downloadServerip, and 0x84. This contains the semantic features of the current function and can be well understood by the large model.

3. The firmware similarity vulnerability detection method based on a large model according to claim 1, characterized in that, The data normalization stage in step 2 includes: Based on the characteristics of the Ghidra decompiler, the offset information of the variable is automatically added when naming the variable (for example, 78 in local_78 indicates the offset of the variable relative to the stack base address register). Since the spatial offset of the variable is an important basis for analyzing similarity, it is necessary to separate the variable name and its offset to form two independent tokens (such as splitting local_78 into local and 78). For information such as global variables, user-defined functions, and large numbers that appear less frequently, a unified identifier is used for replacement: global variables are uniformly replaced with GLOBAL, user-defined functions are uniformly replaced with FUNC, and large numbers are uniformly replaced with IMM; formatting information that may be contained in the string (such as formatting parameters in the printf function) is particularly important for the analysis of command injection type vulnerabilities; therefore, it is necessary to extract the formatting information in the string, and if no formatting information is found, it is uniformly replaced with STR; When processing numbers, since numbers have many representations, they need to be standardized to a single format: negative numbers, such as -1, may be obtained as -1 or 0xffffffff, which can be standardized to the form -1; number system conversion, the commonly encountered representation methods are decimal and hexadecimal, which can be standardized to decimal; characters may be recognized as numbers by decompilers, such as the character '\r' which may be obtained as 0xd from a decompiler, so visible characters need to be converted to characters.

4. The firmware similarity vulnerability detection method based on a large model according to claim 1, characterized in that, The semantic extraction stage of step 3 includes: After Silence normalization, each token is treated as a word, and each parameter slice of the callee function in KeyStatmen is treated as a sentence. Word2vec is used for pre-training to finally obtain the word embedding of each token. As shown in S1 of Figure 3, during semantic extraction, although the output vector oi of the LSTM contains the complete sequence semantics, its attention to all statements is "averaged," and it cannot actively distinguish which statements in the sequence are key information (such as the core triggering conditions in the vulnerability description or the key operation statements in the code snippet). Therefore, it is necessary to use the Attention mechanism to "weight and filter" the output of the LSTM to highlight the semantic contribution of important statements. SimVul uses Self-attention to process the output of the LSTM. After processing by the Attention mechanism, the resulting semantic vector Oi is no longer a simple copy of the LSTM output, but a weighted representation that strengthens the semantics of important statements and weakens secondary information (the higher the weight, the greater the impact of the corresponding statement on the overall semantics). After obtaining the semantic vector Oi processed by Attention at each position, the model integrates these vectors through a fully connected layer. To find the semantics contained in important sentences, SimVul uses the output of each LSTM layer as the input of Attention; that is, it uses the Self-attention method, taking the output vector oi of the LSTM as the input of the Attention mechanism to obtain the semantic vector Oi, and then uses a fully connected layer to fuse these outputs to obtain the semantic vector V of Slience.

5. The firmware similarity vulnerability detection method based on a large model according to claim 1, characterized in that, The model training phase in step 4 includes: To enable the model to effectively extract semantic information from Silence, it needs to be trained. The specific training process is shown in Figure 4. The core function of this model is to extract semantic information from Silence, and then use it for Silence similarity comparison and to realize the similarity judgment of code logic information. Therefore, during the training set construction phase, this paper treats all external function calls as KeyStatements and performs a unified analysis on all parameters of the called function (callee). The dataset construction rules are as follows: binary files of different architectures generated by compiling the same function source code with different compilers and different optimization levels are defined as similar samples; correspondingly, the slience extracted from two similar binary files is defined as a similar pair, while dissimilar sliences are obtained through random sampling. The model training process is as follows: First, two Sense objects are processed by a bidirectional LSTM network with shared weights to generate semantic vectors V, and their similarity is calculated using cosine distance. Second, the cross-entropy algorithm is used to calculate the loss value between the similarity result and the label. Finally, the Adam (Adaptive Moment Estimation) optimizer is used to optimize the parameters, and the stochastic gradient descent algorithm is used for iterative updates until the model training is completed.

6. The firmware similarity vulnerability detection method based on a large model according to claim 1, characterized in that, The vulnerability detection phase in step 5 includes: Experimental results show that large-scale embedded models perform poorly in code similarity comparison tasks, presumably because they struggle to accurately understand the actual functionality of code snippets. In contrast, small-scale models have better performance in code similarity differentiation. Based on this, this paper uses a common similarity comparison model for semantic similarity analysis of code snippets, while utilizing a large-scale model for vulnerability detection and outputting detailed vulnerability information. Large-scale models require sufficient known information to support semantic understanding. This paper proposes that large-scale models need three key inputs to understand code snippets: (1) an existing vulnerability information database; (2) the unknown code snippet to be analyzed; and (3) prompts to guide the thinking direction. As shown in S3 of Figure 3, the vulnerability detection process first requires building a vulnerability database based on publicly available vulnerability information. The specific steps include: manually analyzing the vulnerability principle, locating the binary file containing the vulnerability, marking the vulnerability triggering location, using the SimVul tool to extract the vulnerability signature (Vulnerable Signature, VS) based on the marking information, and storing it in the vulnerability database. For the analysis of unknown binary files, the first step is to locate critical statements through dangerous function calls and generate a critical statement signature (KS) using the same method as for extracting vulnerability signatures. Then, the KS is compared with the vulnerability database for susceptibility similarity to VSs with the same call name, and highly similar KSs are selected. Finally, a large-scale model is used to confirm the vulnerabilities of the selected KSs and output detailed vulnerability information. Based on the above process, by comparing the similarity between KS and VS, and combining the known vulnerability information recorded in VS with the characteristics of the unknown code fragments contained in KS, the following example of guiding prompts is designed: "It is known that a certain type of vulnerability exists in {VS features}. Through similarity analysis, it is found that {KS features} are similar to it. Please determine whether {KS features} have a similar vulnerability. If so, please analyze the cause of the vulnerability;" Finally, the authenticity of vulnerabilities in unknown binary files is verified by manually reviewing the vulnerability reports generated by large models.

Images