Static firmware vulnerability verification method and device

Abstract

The application discloses a static firmware vulnerability verification method and device, comprising: obtaining firmware binary code; identifying potential vulnerabilities of the firmware binary code to obtain a vulnerability sink point; performing reverse backtracking analysis from the vulnerability sink point as a starting point to obtain an effective data flow path set; verifying the effective data flow path set to obtain a vulnerability proof. The application can efficiently and accurately find and verify vulnerabilities in large firmware binary files, significantly reduces the analysis cost and false positive rate, and provides a solid foundation for vulnerability repair.

Description

Technical Field

[0001] This invention relates to the field of IoT firmware security technology, specifically to a static firmware vulnerability verification method and apparatus. Background Technology

[0002] With the widespread adoption of Internet of Things (IoT) devices, firmware security has become a critical issue. Vulnerabilities in firmware, especially taint-type vulnerabilities such as command injection, can lead to remote control of devices, posing a serious security threat. Existing firmware vulnerability analysis techniques are mainly divided into two categories: dynamic analysis and static analysis. Dynamic analysis discovers vulnerabilities by executing firmware, which is highly accurate, but is limited by the low success rate of firmware emulation and insufficient code coverage.

[0003] Static analysis techniques, which do not require running firmware and offer broader coverage, face significant challenges. Traditional methods often employ forward data flow analysis from the user input source to the point where potentially vulnerable functions converge. This approach requires exploring all possible program paths through which input data might flow, leading to an explosion of analysis paths and extremely high computational costs. To achieve scalability, existing tools use techniques such as Binary Dependency Graphs (BDGs) to strictly limit the analysis scope to a few "boundary binary files" related to network interfaces. This results in a high false negative rate, where many real-world vulnerabilities are missed. Furthermore, traditional taint tracking techniques can only mark whether data is tainted, but cannot distinguish the specific composition and type of tainted values. Even after safe type conversions such as string to integer, input values ​​are still marked as tainted, generating numerous false positives. Therefore, there is an urgent need for a technical solution that can efficiently and accurately verify firmware vulnerabilities and generate exploitable proofs. Summary of the Invention

[0004] The technical problem solved by this invention is to provide a method for efficiently and accurately verifying command injection vulnerabilities in firmware by starting from the vulnerability entry point and reverse tracing back the data source and processing process. This method aims to overcome the problems of high false positives, high false negatives and low analysis efficiency caused by traditional forward analysis, and is committed to automatically generating real vulnerability proofs with clear exploitation paths.

[0005] To achieve the above objectives, a first aspect of the present invention discloses a static firmware vulnerability verification method, the method comprising: S1. Obtain firmware binary code; S2. Identify potential vulnerabilities in the firmware binary code to obtain vulnerability entry points; S3. Starting from the vulnerability entry point, perform reverse backtracking analysis to obtain a set of valid data flow paths; the set of valid data flow paths includes several valid data flow paths, and each valid data flow path contains a data source; S4. Verify the set of valid data flow paths to obtain a vulnerability proof.

[0006] As an optional implementation, in the first aspect of the present invention, the step of identifying potential vulnerabilities in the firmware binary code to obtain vulnerability ingress points includes: S21. Locate high-risk function calls from the firmware binary code to obtain high-risk functions; the high-risk functions are system command execution functions such as system() and execve(); the high-risk functions refer to functions that directly or indirectly receive external input (such as user-controllable data) and perform critical operations (command execution, file reading and writing, network transmission, etc.). If the input is not strictly verified, it may be used by attackers to inject malicious code, manipulate device behavior, or leak sensitive information. S22. Use the call points of the high-risk functions as vulnerability import points.

[0007] As an optional implementation, in the first aspect of the present invention, the step of performing reverse backtracking analysis starting from the vulnerability ingress point to obtain a set of valid data flow paths includes: S31. Create a core data flow analysis engine; the core data flow analysis engine is used to track the data flow path of function values; S32. Determine the function where the vulnerability's ingress point is located as the initial function; S33. According to the program call graph, starting from the initial function, backtrack the caller functions layer by layer upwards, and use the core data flow analysis engine to find the program paths directly related to the vulnerability entry point to obtain a set of data flow paths; the directly related program paths represent the program paths that directly participate in the generation, transmission, modification or use of the vulnerability entry point data. S34. The validity of the data flow path set is identified to obtain a valid data flow path set.

[0008] As an optional implementation, in the first aspect of the present invention, the creation of the core data flow analysis engine includes... S311. Create a variable value range for modeling variables in the program; the variable value range includes bit vectors (integers, fixed-length strings) and TOP(T) values; the variables in the program include registers, memory units, and other variables; S312. During the data flow analysis process, a rich expression is constructed for each value flowing into the vulnerability ingress point; the rich expression contains the specific content of the variable value, records all source value dependencies of the variable value and all operations applied on the propagation path (such as string concatenation, function calls, etc.). S313. Parse the rich expression to obtain the composition of the input value. For example, for the expression... It can be determined The value is derived from an integer and will not lead to command injection. The source value is not restricted, which poses a risk of injection.

[0009] As an optional implementation, in the first aspect of the present invention, based on the program call graph, starting from the initial function, the caller functions are traced back layer by layer upwards. Using the core data flow analysis engine, program paths directly related to the vulnerability entry point are found to obtain a set of data flow paths, including: S331. Locate the parent function that calls the initial function to obtain the set of calling functions; S332. Determine whether the set of called functions is an empty set; If the set of called functions is empty, the method flow ends; If the set of called functions is not empty, then proceed to step S333; S333. Select any function from the set of called functions; S334. Based on the program's call graph, backtrack upwards for any of the called functions to the upper-level functions directly related to the merging point to obtain the second-level set of called functions; S335. Determine whether the second-level call function set is an empty set, and obtain the first determination result; If the first judgment result is yes, then the core data flow analysis engine is used to record and add the obtained data flow path to the data flow path set; If the first judgment result is negative, then continue to backtrack upwards to the upper-level function according to steps S334 to S335. The termination condition for backtracking the data flow path is that at any stage of the reverse backtracking analysis, if the analysis engine determines that the data flow comes from an unusable variable, the obtained data flow path is added to the data flow path set. The unusable variable refers to a variable whose data flow can reach the vulnerability ingress point, but due to the variable's own attributes, value constraints, source restrictions, etc., the attacker cannot trigger the vulnerability or achieve malicious behavior by manipulating this variable.

[0010] As an optional implementation, in the first aspect of the present invention, the method further includes: optimizing the data flow path using an inter-function analysis optimization strategy during the data flow reverse backtracking analysis process; the inter-function analysis optimization strategy includes: S3361. During the reverse backtracking analysis, when a function call is encountered, the calling convention and function prototype of the called function are restored. S3362. Based on the calling convention and function prototype, perform the following two judgments at each calling point: Check if any pointers to the currently tracked value or variable were passed as arguments to the called function, and obtain the second result. The third judgment result is obtained by determining whether any value returned by the called function is ultimately used by the import point in some form; If both the second and third judgment results are negative, it is determined that the function call has no impact on the data flow being analyzed, and the analysis of the internal logic of the called function is skipped to reduce analysis time; otherwise, the internal logic of the called function is analyzed in reverse backtracking.

[0011] As an optional implementation, in the first aspect of the present invention, the step of identifying the validity of the data flow path set to obtain a valid data flow path set includes: S341. Select any data flow path from the set of data flow paths; S342. Perform feature extraction on any of the data flow paths to obtain the feature vector of the data flow path; S343. Using the trained data flow path validity identification model, identify the feature vector of the data flow path to obtain the validity probability corresponding to any data flow path; If the effective probability is greater than a preset effective probability threshold, then any data flow path is added to the set of effective data flow paths; optionally, the effective probability threshold is 0.7. Otherwise, set any of the data flow paths as invalid data flow paths; S344. Traverse the set of data flow paths and perform steps S342 to S343 to identify the valid data flow paths.

[0012] As an optional implementation, in the first aspect of the present invention, feature extraction is performed on any data flow path to obtain a feature vector of the data flow path, including: S3421. Extract the structural features of any data flow path; the structural features of the data flow path include: Normalized path length The expression is: ; Operation type distribution T, k is the number of operation types; Normalized dependency depth D, where dependency depth represents the number of levels in the longest data flow dependency chain from the external data source node to the vulnerability ingress node, is used to quantify the nesting complexity of dependency relationships during data propagation. Security processing flag S, which represents a binary feature, S=1 indicates the presence of security processing, and S=0 indicates the absence of security processing; S3422. Extract the rich expression sequence features of any data flow path; S3423. Extract the semantic features of any of the data flow paths; S3424. Integrate the structural features, rich expression sequence features, and semantic features to obtain the feature vector of the data flow path.

[0013] As an optional implementation, in the first aspect of the present invention, the extraction of rich expression sequence features of any data flow path includes: S34221. Perform standard processing on the rich expression of any data flow path to obtain the first sequence feature; S34222: Perform word processing on the first sequence features to obtain the second sequence features; S34223. Encode the second sequence feature to obtain the third sequence feature; S34224. The third sequence features are subjected to embedding layer mapping processing to obtain rich expression sequence features.

[0014] As an optional implementation, in the first aspect of the present invention, the extraction of semantic features of any data stream path includes: S34231. Set initial pollution risk values; S34232. Based on the data propagation operation, the initial pollution risk value is dynamically adjusted to obtain a second pollution risk value; S34233. Normalize the second pollution risk value to obtain the semantic features of any data flow path.

[0015] As an optional implementation, in the first aspect of the present invention, the data flow path validity identification model includes: a graph attention network structure encoding layer, a Transformer sequence encoding layer, a feature fusion layer, and a classification layer, specifically: S3431, The graph attention network structure encoding layer is used to capture path structure dependencies: The node feature mapping expression is: in, Let represent the feature vector of the i-th node in the data flow path graph. , where m is the structural feature dimension and p is the mapped dimension; The expression for calculating the attention coefficient is: , ; The expression for attention normalization is: , For nodes The set of neighbors; Node feature update ( (Multiple heads of attention) ; Final graph attention network output: ; S3432, The Transformer sequence encoding layer is used to capture rich expression semantics: The expression for calculating Query, Key, and Value is: , , , in, ; Self-attention score: , ; Attention Output and Feedforward Networks: , , , Final Transformer output ( (for sequence encoding dimensions) S3433, The expression for the feature fusion layer is: , in, , ( (for the fusion dimension) S3434, The classification layer expression is: , , ; S3435, The loss function expression of the data flow path validity identification model is: , in, Represents the L2 regularization coefficient. ; The labels are 1 = valid path, 0 = invalid path; N is the total number of samples; This represents the set of all learnable parameters of the model; The square of the L2 norm (Euclidean norm) of the learnable parameter; The true label of the sample in the i-th data flow path; This represents the model's predicted output value for the sample of the i-th data flow path.

[0016] As an optional implementation, in the first aspect of the present invention, verifying the set of valid data flow paths to obtain a vulnerability proof includes: S41. Based on the set of valid data flow paths, construct a set of data flow dependency graphs; the data flow dependency graphs include data dependency graphs that correspond one-to-one with the valid data flow paths; the data flow dependency graphs represent the data flow dependency graphs from the identified external data sources to the vulnerability entry point; the external data sources characterize the data sources of the valid data flow paths; S42. Classify the external data sources to obtain external data source category information; the external data source categories include: file operation category, network socket operation category, environment variable category, command line parameter category, and unknown source category; S43. Based on the external data source category information, process the data flow dependency graph set to obtain vulnerability proof.

[0017] As an optional implementation, in the first aspect of the present invention, the step of processing the data flow dependency graph set according to the external data source category information to obtain vulnerability proof specifically includes: S431. Select any data flow dependency graph from the set of data flow dependency graphs; S432. Perform feature extraction on any data flow dependency graph to obtain the feature vector of any data flow dependency graph; S433. Using the trained path verification model, identify the feature vector of any data flow dependency graph to obtain the vulnerability probability corresponding to the data flow dependency graph. If the vulnerability probability is greater than a preset vulnerability threshold, then the data flow path corresponding to any data flow dependency graph is identified as a high-probability vulnerability, thereby proving that there is a clear and triggerable path from a user-controllable source to the ingress point, thus completing the vulnerability verification. Otherwise, the data flow path corresponding to any of the data flow dependency graphs will be identified as a low-probability vulnerability; S434. Traverse all data flow dependency graphs in the data flow dependency graph set, and perform steps S432 to S433 to identify vulnerabilities and obtain proof of vulnerabilities.

[0018] As an optional implementation, in the first aspect of the present invention, the path verification model includes: a GCN graph encoding layer, a BiLSTM sequence encoding layer, an attention fusion layer, and a classification output layer; used to fuse graph dependency features, sequence semantic features, and multi-source attribute features to achieve accurate verification of vulnerability exploitability; S4331, The GCN graph coding layer is used to capture global features of the data flow dependency graph, including: Adjacency matrix standardization: Adjacency matrix standardization: Where A is the dependency graph adjacency matrix, I is the identity matrix (preserving self-loop features), and I is the graph node degree matrix; The first layer of the Graph Convolutional Network (GCN) encodes global features of the dependency graph: in, This provides a new representation of node features and serves as input for the second-layer GCN. Represents the normalized adjacency matrix; Represents the initial feature matrix of the node ( ), For the number of nodes, For feature dimensions; Represents the first layer weight matrix ( ), For feature dimension, For output dimensions; for Dimensional output bias vector; ReLU is the activation function: ReLU introduces non-linearity and enhances the model's expressive power; The second encoding layer of a graph convolutional network (GCN) is used to capture global features of the dependency graph: in, The final representation of node features is used for global average pooling; This is a new representation of the node features output by the first-layer GCN; Represents the normalized adjacency matrix; This represents the second-layer weight matrix. , Embedded dimensions for the graph; for The output bias vector is dimensional; tanh is the activation function that compresses the output to the [-1,1] interval, enhancing the feature representation capability. S4332, The BiLSTM sequence coding layer is used to capture semantic sequence features of data flow paths, including: Forward LSTM computation: in, The output is the current forward LSTM hidden state. The input at time t is the rich expression embedding sequence. ; This represents the hidden state of the previous time step in the forward LSTM. It should be noted that the LSTM unit processes the sequence data, learns the temporal dependencies, and captures temporal features. The LSTM's gating mechanism (forget gate, input gate, output gate) solves the gradient vanishing problem in long sequences.

[0019] Inverse LSTM computation: ; in, The hidden state of the inverse LSTM at the next time step; BiLSTM output fusion: The forward and reverse hidden states at the last time step of the sequence are concatenated as the global features of the sequence. in, This represents the hidden state at the last moment of the forward LSTM. The first hidden state of the inverse LSTM. h is the dimension of the unidirectional hidden layer of BiLSTM. The dimension of the concatenated feature vector is twice the dimension h of the unidirectional hidden layer, thus fully preserving the bidirectional contextual information of the sequence. This represents a vector concatenation operation, which merges two hidden states into a longer feature vector. The BiLSTM sequence coding layer enhances feature representation capabilities through bidirectional information fusion. S4333, the attention fusion layer includes: Feature stitching: combining global features of the graph Sequence global features Data source characteristics Path features Concatenate to form the total feature vector , , where t is the graph embedding dimension and h is the BiLSTM hidden layer dimension; it is used to provide complete multi-source feature input for the subsequent attention mechanism, strengthen key features (such as user-controllable sources and risk paths) through attention weights, and suppress interference from irrelevant features. Attention weight calculation: in, , It is a learnable weight matrix that controls feature interactions; , The bias term provides flexibility in model fitting; the intermediate layer dimension input is the total feature vector. (Including multi-source information such as graph features, sequence features, and data source features), intermediate layer Nonlinearity is introduced through the ReLU activation function; weight calculation: Map the intermediate layer to the attention weight dimension; normalize: To ensure that the weight sum is 1, highlight important features.

[0020] Attention feature output: in, This represents the attention feature output. It is the total eigenvector. It is the attention weight vector. This represents element-wise multiplication (Hadamard product). Attention weights are used to represent this. By weighting features, the contribution of key information such as user-controllable data source features and risk path features is enhanced, while the interference of irrelevant features is suppressed. In the vulnerability detection model, this layer helps the model focus on key features related to the vulnerability, improving the accuracy and interpretability of verification. It strengthens the contribution of key features (such as user-controllable data source features and risk path features) through attention weights, and suppresses the interference of irrelevant features. S4334, The classification output layer includes: Fully connected layer mapping: in, The weight matrix represents the attention features. Mapped to the hidden layer space; As a bias term, it provides a learnable translation amount to improve the model's fitting ability; the fully connected layer mapping serves as the first step of the classification output layer, laying the foundation for subsequent Dropout regularization and final vulnerability probability calculation.

[0021] Dropout regularization: Dropout() is a regularization function used to suppress model overfitting; Vulnerability Probability Output: Categorized output layer, used to calculate the final output of the probability of vulnerability existence. in, This is the classification output layer, used to calculate the final output of the probability of a vulnerability existing; Fully connected layer weight matrix; For bias terms; This is a sigmoid function that outputs the probability of a vulnerability. S4335, The loss function of the path verification model is: in, The total number of firmware code samples in the training set; For the first The true label of each sample This indicates that the sample is a vulnerability sample. This indicates that the sample is a normal sample; and These are the loss weights for vulnerable samples and normal samples, respectively, satisfying... , , The number of vulnerability samples. This represents the number of normal samples. For the model to predict the first The probability that a sample is a vulnerability sample; is the regularization coefficient, and its value range is . ; This is the set of learnable parameters for the vulnerability detection model.

[0022] Vulnerability proof generation rules: When the model outputs vulnerability probabilities If identified as a high-probability vulnerability, a vulnerability verification report is automatically generated, including data source information, a complete exploit path, key evidence, and triggering conditions; when If the vulnerability is deemed low-probability, no proof report will be generated. Optionally, a preset vulnerability assessment threshold can be used. .

[0023] Automated vulnerability verification: The final output of this invention is a verification report with a clearly defined exploit path, rather than just a potential vulnerability alert. This provides a direct and actionable basis for vulnerability remediation and verification, greatly improving the effectiveness of vulnerability disclosure.

[0024] A second aspect of this invention discloses a device for verifying vulnerabilities without static firmware, used to implement a static firmware vulnerability verification method disclosed in the first aspect of this invention. The device includes: Firmware code acquisition module, used to acquire firmware binary code; The vulnerability entry point identification module is used to identify potential vulnerabilities in the firmware binary code and obtain vulnerability entry points. The effective path filtering module is used to perform reverse backtracking analysis starting from the vulnerability ingress point to obtain a set of effective data flow paths; the set of effective data flow paths includes several effective data flow paths, and each effective data flow path contains a data source; The vulnerability proof generation module is used to verify the set of valid data flow paths and obtain vulnerability proofs.

[0025] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: (1) High efficiency and scalability: The analysis workflow from the ingress point to the source point, combined with optimization strategies, strictly limits the analysis scope to code paths directly related to potential vulnerabilities, avoiding the exploration of a large number of irrelevant paths, making it possible to conduct a comprehensive analysis of all binary files of the entire firmware, and significantly improving the analysis speed.

[0026] (2) High accuracy and low false alarm rate: By using rich expressions to accurately model the data, not only is the taint state tracked, but the complete evolution history and dependencies of the values ​​are also captured. This enables the method to accurately distinguish between the original input that truly poses a threat and the input that has been safely processed, fundamentally solving the problem of over-contamination in traditional taint analysis and significantly reducing the false alarm rate.

[0027] (3) High recall and low false negative rate: Due to its high scalability, this method can analyze any binary file in the firmware image, rather than being limited to a few boundary binary files as in existing technologies. This enables this method to discover deep vulnerabilities caused by the interaction of multiple layers of binary files, significantly reducing the false negative rate.

[0028] (4) Automated vulnerability verification: The final output of this invention is a verification report with a clear exploitation path, rather than just a potential vulnerability alert. This provides a direct and actionable basis for vulnerability remediation and verification, greatly improving the effectiveness of vulnerability disclosure. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of a static firmware vulnerability verification method disclosed in an embodiment of the present invention; Figure 2 This is a schematic diagram of a static firmware vulnerability verification device disclosed in an embodiment of the present invention. Detailed Implementation

[0030] 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 only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] Example 1 Please see Figure 1 . Figure 1This is a schematic diagram of the static firmware vulnerability verification method disclosed in an embodiment of the present invention. Figure 1 As shown in the figure, the static firmware vulnerability verification method disclosed in this embodiment of the invention includes: S1. Obtain firmware binary code; S2. Identify potential vulnerabilities in the firmware binary code to obtain vulnerability entry points; S3. Starting from the vulnerability entry point, perform reverse backtracking analysis to obtain a set of valid data flow paths; the set of valid data flow paths includes several valid data flow paths, and each valid data flow path contains a data source; S4. Verify the set of valid data flow paths to obtain a vulnerability proof.

[0032] In another optional embodiment, the process of identifying potential vulnerabilities in the firmware binary code to obtain vulnerability ingress points specifically includes: S21. Locate high-risk function calls from the firmware binary code to obtain high-risk functions; the high-risk functions are system command execution functions such as system() and execve(); the high-risk functions refer to functions that directly or indirectly receive external input (such as user-controllable data) and perform critical operations (command execution, file reading and writing, network transmission, etc.). If the input is not strictly verified, it may be used by attackers to inject malicious code, manipulate device behavior, or leak sensitive information. S22. Use the call points of the high-risk functions as vulnerability import points.

[0033] In another optional embodiment, the step of performing reverse backtracking analysis starting from the vulnerability ingress point to obtain a set of valid data flow paths includes: S31. Create a core data flow analysis engine; the core data flow analysis engine is used to track the data flow path of function values; S32. Determine the function where the vulnerability's ingress point is located as the initial function; S33. Based on the program call graph, starting from the initial function, backtrack the caller functions layer by layer upwards, and use the core data flow analysis engine to find the program path directly related to the vulnerability entry point, thereby obtaining a set of data flow paths. S34. The validity of the data flow path set is identified to obtain a valid data flow path set.

[0034] In yet another optional embodiment, the creation of the core data stream analysis engine includes S311. Create a variable value range for modeling variables in the program; the variable value range includes bit vectors (integers, fixed-length strings) and TOP(T) values; the variables in the program include registers, memory units, and other variables; S312. During the data flow analysis process, a rich expression is constructed for each value flowing into the vulnerability ingress point; the rich expression contains the specific content of the variable value, records all source value dependencies of the variable value and all operations applied on the propagation path (such as string concatenation, function calls, etc.). S313. Parse the rich expression to obtain the composition of the input value. For example, for the expression "df-d"..itoa(atoi( ).."-h". It can be determined that... The value is derived from an integer and will not lead to command injection. The source value is not restricted, which poses a risk of injection.

[0035] In another optional embodiment, based on the program call graph, starting from the initial function, the caller functions are traced back layer by layer upwards. Using the core data flow analysis engine, the program paths directly related to the vulnerability entry point are found, resulting in a set of data flow paths, including: S331. Locate the parent function that calls the initial function to obtain the set of calling functions; S332. Determine whether the set of called functions is an empty set; If the set of called functions is empty, the method flow ends; If the set of called functions is not empty, then proceed to step S333; S333. Select any function from the set of called functions; S334. Based on the program's call graph, backtrack upwards for any of the called functions to the upper-level functions directly related to the merging point to obtain the second-level set of called functions; S335. Determine whether the second-level call function set is an empty set, and obtain the first determination result; If the first judgment result is yes, then the core data flow analysis engine is used to record and add the obtained data flow path to the data flow path set; If the first judgment result is negative, then continue to backtrack upwards to the upper-level function according to the method of steps S334 to S335. The termination judgment condition for backtracking the data flow path is that at any stage of the reverse backtracking analysis, if the analysis engine determines that the data flow comes from an unusable variable, the obtained data flow path is added to the data flow path set.

[0036] Examples of tracing the termination of the data flow path include a string that has been formatted by sprintf(buf,"cal%d",year) and confirmed not to contain injectable content, or a string that is ultimately converted to an integer.

[0037] It should be noted that during the reverse backtracking analysis of the data flow, if the function contains conditional logic such as f-else, the propagation path of the data flow is different under different branches, and it is necessary to trace them separately. It should be noted that if the target variable at the vulnerability's ingress point (such as the parameter of the system function) may be generated by concatenating / assigning multiple different variables, each variable corresponds to a data flow path.

[0038] In yet another optional embodiment, the method further includes: optimizing the data flow path using an inter-function analysis optimization strategy during the data flow reverse backtracking analysis process; the inter-function analysis optimization strategy includes: S3361. During the reverse backtracking analysis, when a function call is encountered, the calling convention and function prototype of the called function are restored. S3362. Based on the calling convention and function prototype, perform the following two judgments at each calling point: Check if any pointers to the currently tracked value or variable were passed as arguments to the called function, and obtain the second result. The third judgment result is obtained by determining whether any value returned by the called function is ultimately used by the import point in some form; If both the second and third judgment results are negative, it is determined that the function call has no impact on the data flow being analyzed, and the analysis of the internal logic of the called function is skipped to reduce analysis time; otherwise, the internal logic of the called function is analyzed in reverse backtracking.

[0039] In another optional embodiment, the step of validating the set of data flow paths to obtain a set of valid data flow paths includes: S341. Select any data flow path from the set of data flow paths; S342. Perform feature extraction on any of the data flow paths to obtain the feature vector of the data flow path; S343. Using the trained data flow path validity identification model, identify the feature vector of the data flow path to obtain the validity probability corresponding to any data flow path; If the effective probability is greater than a preset effective probability threshold, then any data flow path is added to the set of effective data flow paths; optionally, the effective probability threshold is 0.7. Otherwise, set any of the data flow paths as invalid data flow paths; S344. Traverse the set of data flow paths and perform steps S342 to S343 to identify the valid data flow paths.

[0040] In another optional embodiment, feature extraction is performed on any of the data flow paths to obtain a feature vector of the data flow path, including: S3421. Extract the structural features of any data flow path; the structural features of the data flow path include: Normalized path length The expression is: ; Operation type distribution , , Number of operation types; Normalized Depth The dependency depth represents the number of levels in the longest data flow dependency chain from the external data source node to the vulnerability ingress node, and is used to quantify the nesting complexity of dependency relationships during data propagation. Safety processing mark The security processing mark Represents binary characteristics, =1 indicates that a security measure is in place. =0 indicates no security handling; S3422. Extract the rich expression sequence features of any data flow path; S3423. Extract the semantic features of any of the data flow paths; S3424. Integrate the structural features, rich expression sequence features, and semantic features to obtain the feature vector of the data flow path.

[0041] In yet another optional embodiment, the extraction of rich expression sequence features of any of the data flow paths includes: S34221. Perform standard processing on the rich expression of any data flow path to obtain the first sequence feature; Specifically: The rich expressions for each data flow path are formatted uniformly, redundant spaces are removed, operator expressions are standardized, and variable names are standardized to ensure that the rich expression structure is consistent across different paths; S34222: Perform word processing on the first sequence features to obtain the second sequence features; Specifically: the smallest semantic unit (word segmentation) is split according to "operation-variable-dependency relationship". The segmentation rule is: the split boundary is the operator (such as "concatenation", "conversion", "assignment", variable (such as "str-001" "buf-002"), and dependency identifier (such as "depends on" "derives from"). For example, the rich expression "str-001=concatenation(str-002,input data),str-001 depends on str-002 and input data" is segmented into the sequence: [str-001,=,concatenation,(,str-002,,,input data,),,,str-001,depends on,str-002,and,input data]; S34223. Encode the second sequence feature to obtain the third sequence feature; specifically: Pre-trained word vector encoding uses the Word2Vec pre-trained word vector model to map each semantic unit of the second sequence feature into a fixed-dimensional vector, thus preserving semantic associations. For rare semantic units (such as special operators) that do not appear in the pre-trained dictionary, vectors are generated using a "random initialization + fine-tuning" method to ensure that all word segments can be encoded. S34224. Perform embedding layer mapping processing on the third sequence features to obtain rich expression sequence features; specifically: The third sequence feature is input into the pre-trained embedding layer (built into the model, embedding dimension d=128, consistent with the embedding dimension of the PathValidNet model in the embodiment). The variable-length vector sequence (the number of word segments n varies with the length of the rich expression) is converted into a fixed-dimensional two-dimensional vector through matrix mapping, and finally the rich expression sequence feature of the data flow path is obtained. If the number of word segments n is less than the preset length (e.g., n<20), "zero vector padding" is used to the preset length. If n exceeds the preset length (e.g., n>50), the vector sequence of the first 50 words is truncated to avoid excessive computational overhead of the model.

[0042] It should be noted that sequence features refer to the essential attributes inherent in rich expressions arranged in the logical execution order within a data flow path. Their core function is to capture the sequential associations and semantic information of "operation-variable-dependency" during data propagation. They not only reflect the order of execution of operations and variables but also depict the dynamic evolution of data from external data sources to vulnerability entry points. Their key value lies in distinguishing between "sequence patterns with security significance" (such as "input-integer conversion-entry point," with no vulnerability risk) and "sequence patterns without security significance" (such as "input-direct concatenation-entry point," with vulnerability risk), providing core semantic basis for model selection of effective paths.

[0043] In yet another optional embodiment, extracting the semantic features of any of the data flow paths includes: S34231. Set initial pollution risk values; Specifically, during the reverse backtracking analysis, when an external data source is identified, an initial contamination risk value is set based on the data source's "user controllability" and "security attributes". The assignment rules are as follows: Data sources that are fully user-controlled and have no default security checks (such as network input or command-line arguments) are set up. ; Data sources that are partially controllable by the user or have basic security checks (such as environment variables and configuration files) should be set as follows: ; Data sources that are not under the user's control (such as system built-in variables or hardware read values) are set as follows: ; Unknown source data source, set (Adjustments may be needed based on subsequent operations); S34232. Based on the data propagation operation, the initial pollution risk value is dynamically adjusted to obtain a second pollution risk value; During data flow backtracking, each operation recorded in the rich expression (such as string concatenation, type conversion, security checks, etc.) is parsed, and the current risk value P is dynamically adjusted according to the "risk attribute" of the operation. The adjustment rule is (priority: security check operation > type conversion operation > concatenation / assignment operation): Security checks are performed (such as input filtering, length validation, and illegal character blocking): Each valid check results in... (Risk significantly reduced); There are safe type conversion operations (such as string conversion). (Integer, fixed-length format) (The risk is significantly reduced, as shown in the example where P=0.1 after integer conversion;) Risky operations (such as unvalidated string concatenation or direct assignment to import point variables): Each time a risky operation occurs, (Risk increased slightly, with a maximum of 1.0). Neutral operations exist (such as variable assignment and non-concatenation operations): Remain unchanged; S34233. Normalize the second pollution risk value to obtain the semantic features of any data flow path; The dynamically adjusted risk value may exceed the [0,1] interval, so Min-Max normalization is required to map it to the [0,1] interval. After normalization, the final semantic feature value (pollution risk level P) is obtained to ensure that the feature value range is uniform and to adapt to the input requirements of the PathValidNet model. Example: A data flow path is: network input (user-controllable, ) Unvalidated string concatenation (a risky operation) ) Directly assigning the value to the system() inlet point (risk operation, P=0.99×1.1≈1.09, after normalization P=0.95, indicating that the path has an extremely high pollution risk and is a valid risk path; Another path is: network input ( ) Integer conversion (safe operation, P = 0.9 × 0.2 = 0.18) Assigning the value to the ingress point (neutral operation, P=0.18), after normalization P=0.1, indicating that although the path is polluted, it is risk-free and is an invalid path.

[0044] In another optional embodiment, the data flow path validity identification model includes: a graph attention network structure encoding layer, a Transformer sequence encoding layer, a feature fusion layer, and a classification layer, specifically: S3431, The graph attention network structure encoding layer is used to capture path structure dependencies: The node feature mapping expression is: in, Let represent the feature vector of the i-th node in the data flow path graph. , represents the weight matrix, For structural feature dimension, The dimension after mapping; The expression for calculating the attention coefficient is: , ; The expression for attention normalization is: , For nodes The set of neighbors; Node feature update ( (Multiple heads of attention) , Final graph attention network output: ; S3432, The Transformer sequence encoding layer is used to capture rich expression semantics: The query / key / value calculation expression is: , , , ; Self-attention score: , ; Attention Output and Feedforward Networks: , , , Final Transformer output ( (for sequence encoding dimensions) S3433, The expression for the feature fusion layer is: , , ( (for the fusion dimension) S3434, The classification layer expression is: , , ; S3435, The loss function expression of the data flow path validity identification model is: , in, Represents the L2 regularization coefficient. ; The labels are 1 = valid path, 0 = invalid path; N is the total number of samples; This represents the set of all learnable parameters of the model; The square of the L2 norm (Euclidean norm) of the learnable parameter; The true label of the sample in the i-th data flow path; This represents the model's predicted output value for the sample of the i-th data flow path.

[0045] In yet another optional embodiment, the data flow path validity identification model training dataset processing procedure includes: X1. Data acquisition, specifically: Two types of data are collected to form the model training and testing datasets: one is real firmware vulnerability sample data, which extracts labeled data flow paths (labeled with valid / invalid tags) from IoT firmware vulnerability databases (such as FirmAE and CVE vulnerability databases); the other is simulated data, which constructs data flow paths under different scenarios (including scenarios with secure processing, no secure processing, complex dependencies, simple dependencies, etc.) through a firmware simulator to supplement the diversity of samples. X2. Data preprocessing, specifically: Data cleaning: Remove duplicate paths, incomplete paths (such as missing key operations or incomplete dependencies), and abnormal paths (such as path lengths exceeding reasonable limits or abnormal feature values). Use the 3σ criterion to identify and remove outlier features. Format standardization: Rich expressions are formatted uniformly to remove redundant spaces, standardize operator expressions, and standardize variable naming formats; continuous features such as path length and dependency depth are normalized using Min-Max and mapped to the [0,1] interval. Missing value imputation: For missing features in some paths (such as unclear security handling markings), the mean (continuous feature) or mode (discrete feature) of similar path features is used to imput the missing features to ensure feature integrity; X3. Feature processing, specifically: Feature selection: The mutual information method is used to calculate the correlation between each feature and the path validity label. Features with mutual information values ​​greater than the threshold (the threshold is set to 0.15) are selected and redundant features (such as the number of path nodes that are highly correlated with the path length) are removed to reduce the computational cost of the model. Feature encoding: For discrete / textual features such as operation type distribution and rich expressions, pre-trained word vectors (such as Word2Vec) are combined with one-hot encoding for joint encoding, which preserves semantic information and ensures the uniqueness of the encoding. X4. Data augmentation, specifically: To address the issue of potentially low proportion of effective path samples, two methods are employed to enhance the samples: path perturbation and feature noise addition. Path perturbation generates similar paths by adding / deleting non-critical operation nodes. Feature noise addition generates new samples by adding small Gaussian noise (mean 0, variance 0.01) to continuous features to avoid model overfitting. X5. Dataset partitioning, specifically: The processed data is divided into training, validation, and test sets in a 7:2:1 ratio. The training set is used for learning model parameters, the validation set is used for tuning model hyperparameters (such as the number of attention heads and embedding dimension), and the test set is used for evaluating model performance.

[0046] In yet another optional embodiment, verifying the set of valid data flow paths to obtain a vulnerability proof includes: S41. Based on the set of valid data flow paths, construct a set of data flow dependency graphs; the data flow dependency graphs include data dependency graphs that correspond one-to-one with the valid data flow paths; the data flow dependency graphs represent the data flow dependency graphs from the identified external data sources to the vulnerability entry point; the external data sources characterize the data sources of the valid data flow paths; S42. Classify the external data sources to obtain external data source category information; the external data source categories include: file operation class (file_ops, such as fgets), network socket operation class (network_ops), environment variable class (env_ops or persistent storage operations such as NVRAM), command line parameter class (argv), and unknown source class (unknown). S43. Based on the external data source category information, process the data flow dependency graph set to obtain vulnerability proof.

[0047] In another optional embodiment, the step of processing the data flow dependency graph set based on external data source category information to obtain vulnerability proof specifically includes: S431. Select any data flow dependency graph from the set of data flow dependency graphs; S432. Perform feature extraction on any data flow dependency graph to obtain the feature vector of any data flow dependency graph; S433. Using the trained path verification model, identify the feature vector of any data flow dependency graph to obtain the vulnerability probability corresponding to the data flow dependency graph. If the vulnerability probability is greater than a preset vulnerability threshold, then the data flow path corresponding to any data flow dependency graph is identified as a high-probability vulnerability, thereby proving that there is a clear and triggerable path from a user-controllable source to the ingress point, thus completing the vulnerability verification. Otherwise, the data flow path corresponding to any of the data flow dependency graphs will be identified as a low-probability vulnerability; S434. Traverse all data flow dependency graphs in the data flow dependency graph set, and perform steps S432 to S433 to identify vulnerabilities and obtain proof of vulnerabilities.

[0048] In yet another optional embodiment, the feature vector of the data flow dependency graph includes: Data source characteristics: Categorical encoding (one-hot encoding) User controllability U (binary feature, 1 = user controllable, 0 = uncontrollable), and trustworthiness R (normalized security level). Path characteristics: Security check missing flag M (binary feature, 1 = missing check, 0 = check present), dependency complexity (Normalized to [0,1]), injection risk score (The validity probability s output by PathValidNet); Dependency graph features: graph embedding (Global features of the dependency graph after GCN encoding) t is the graph embedding dimension; Sequence features: Rich expression embedding E (after standardization) d is the embedding dimension, which is 128, consistent with PathValidNet.

[0049] In another optional embodiment, the path verification model includes: a GCN graph encoding layer, a BiLSTM sequence encoding layer, an attention fusion layer, and a classification output layer; used to fuse graph dependency features, sequence semantic features, and multi-source attribute features to achieve accurate verification of vulnerability exploitability; S4331, The GCN graph coding layer is used to capture global features of the data flow dependency graph, including: Adjacency matrix standardization: Adjacency matrix standardization: Where A is the dependency graph adjacency matrix, I is the identity matrix (preserving self-loop features), and I is the graph node degree matrix; The first layer of the Graph Convolutional Network (GCN) encodes and captures global features of the dependency graph. in, This provides a new representation of node features and serves as input for the second-layer GCN. Represents the normalized adjacency matrix; Represents the initial feature matrix of the node ( ), For the number of nodes, For feature dimensions; Represents the first layer weight matrix ( ), For feature dimension, For output dimensions; for Dimensional output bias vector; ReLU is the activation function: ReLU introduces non-linearity and enhances the model's expressive power; The second encoding layer of a graph convolutional network (GCN) is used to capture global features of the dependency graph, including: in, The final representation of node features is used for global average pooling; This is a new representation of the node features output by the first-layer GCN; Represents the normalized adjacency matrix; This represents the second-layer weight matrix. , Embedded dimensions for the graph; for The output bias vector is dimensional; tanh is the activation function that compresses the output to the [-1,1] interval, enhancing the feature representation capability. S4332, The BiLSTM sequence coding layer is used to capture semantic sequence features of data flow paths, including: Forward LSTM computation: in, The output is the current forward LSTM hidden state. The input at time t is the rich expression embedding sequence. ; This represents the hidden state of the previous time step in the forward LSTM. It should be noted that the LSTM unit processes the sequence data, learns the temporal dependencies, and captures temporal features. The LSTM's gating mechanism (forget gate, input gate, output gate) solves the gradient vanishing problem in long sequences.

[0050] Inverse LSTM computation: in, The hidden state of the inverse LSTM at the next time step; BiLSTM output fusion: The forward and reverse hidden states at the last time step of the sequence are concatenated as the global features of the sequence. in, This represents the hidden state at the last moment of the forward LSTM. The first hidden state of the inverse LSTM. h is the dimension of the unidirectional hidden layer of BiLSTM. The dimension of the concatenated feature vector is twice the dimension h of the unidirectional hidden layer, thus fully preserving the bidirectional contextual information of the sequence. This represents a vector concatenation operation, which merges two hidden states into a longer feature vector. The BiLSTM sequence coding layer enhances feature representation capabilities through bidirectional information fusion. S4333, the attention fusion layer, used for adaptively fusing multi-source features, includes: Feature stitching: combining global features of the graph Sequence global features Data source characteristics Path features Concatenate to form the total feature vector , , where t is the graph embedding dimension and h is the BiLSTM hidden layer dimension; it is used to provide complete multi-source feature input for the subsequent attention mechanism, strengthen key features (such as user-controllable sources and risk paths) through attention weights, and suppress interference from irrelevant features. Attention weight calculation: in, , It is a learnable weight matrix that controls feature interactions; , The bias term provides flexibility in model fitting; the intermediate layer dimension input is the total feature vector. (Including multi-source information such as graph features, sequence features, and data source features), intermediate layer Nonlinearity is introduced through the ReLU activation function; weight calculation: Map the intermediate layer to the attention weight dimension; normalize: To ensure that the weight sum is 1, highlight important features.

[0051] Attention feature output: in, This represents the attention feature output. It is the total eigenvector. It is the attention weight vector. This represents element-wise multiplication (Hadamard product). Attention weights are used to represent this. By weighting features, the contribution of key information such as user-controllable data source features and risk path features is enhanced, while the interference of irrelevant features is suppressed. In the vulnerability detection model, this layer helps the model focus on key features related to the vulnerability, improving the accuracy and interpretability of verification. It strengthens the contribution of key features (such as user-controllable data source features and risk path features) through attention weights, and suppresses the interference of irrelevant features. S4334, The classification output layer, used for vulnerability probability calculation, includes: Fully connected layer mapping: in, The weight matrix represents the attention features. Mapped to the hidden layer space; As a bias term, it provides a learnable translation amount to improve the model's fitting ability; the fully connected layer mapping serves as the first step of the classification output layer, laying the foundation for subsequent Dropout regularization and final vulnerability probability calculation.

[0052] Dropout regularization: Dropout() is a regularization function used to suppress model overfitting; Vulnerability Probability Output: Categorized output layer, used to calculate the final output of the probability of vulnerability existence. in, This is the classification output layer, used to calculate the final output of the probability of a vulnerability existing; Fully connected layer weight matrix; For bias terms; This is a sigmoid function that outputs the probability of a vulnerability. S4335, The loss function of the path verification model is: in, The total number of firmware code samples in the training set; For the first The true label of each sample This indicates that the sample is a vulnerability sample. This indicates that the sample is a normal sample; and These are the loss weights for vulnerable samples and normal samples, respectively, satisfying... , , The number of vulnerability samples. This represents the number of normal samples. For the model to predict the first The probability that a sample is a vulnerability sample; is the regularization coefficient, and its value range is . ; This is the set of learnable parameters for the vulnerability detection model.

[0053] Vulnerability proof generation rules: When the model outputs vulnerability probabilities If identified as a high-probability vulnerability, a vulnerability verification report is automatically generated, including data source information, a complete exploit path, key evidence, and triggering conditions; when If the vulnerability is deemed low-probability, no proof report will be generated. Optionally, a preset vulnerability assessment threshold can be used. .

[0054] Automated vulnerability verification: The final output of this invention is a verification report with a clearly defined exploit path, rather than just a potential vulnerability alert. This provides a direct and actionable basis for vulnerability remediation and verification, greatly improving the effectiveness of vulnerability disclosure.

[0055] In yet another optional embodiment, the vulnerability verification model training dataset processing procedure includes: To address the unique characteristics of effective data flow paths and data flow dependencies on graph data, a joint processing strategy of graph data and feature data is adopted to ensure model validation accuracy. This includes: S501, Data Acquisition: Specifically, collect data source information, data flow dependency graph data, and vulnerability labeling information (high probability / low probability vulnerabilities) corresponding to valid data flow paths. Data sources include real firmware vulnerability cases and data generated from simulated vulnerability scenarios to ensure the diversity of data source categories and dependency graph complexity. S502, Data preprocessing, specifically: Graph data preprocessing: Standardize the data flow dependency graph, unify node naming rules (named in the format of "operation type-variable name-position"), and construct a unified adjacency matrix A (if node i has a dependency relationship with node j, then...). {ij}=1, otherwise {ij}=0; Align node features for dependency graphs of different sizes, and fill in missing node features (using the mean of node features within the graph) to ensure that the graph data dimension of the input model is consistent; Data source feature processing: Min-Max normalization is applied to continuous features such as data source credibility and dependency complexity; consistency checks are performed on binary features such as user controllability and missing security verification markers to remove conflicting data; one-hot encoding expansion is applied to data source category codes to ensure no priority deviation between categories; Anomaly data processing: The Isolation Forest algorithm is used to identify anomalous samples (such as samples whose data sources are uncontrollable but are marked as high-probability vulnerabilities, or samples with abnormal dependency graph structures) and remove them; for samples with missing data source categories, category information is supplemented through path tracing, and those that cannot be supplemented are removed. S503, Feature processing, specifically: Graph Feature Extraction: Initial feature extraction is performed on the dependency graph based on the GCN preprocessing module to obtain node-level features, and then global average pooling is used to obtain graph-level global features. , serving as the basis for graph features as input to the model; Sequence feature processing: The rich expression embedded in the effective data flow path is standardized in length (uniformly truncated / padded to 50 word segment lengths) and used as the input sequence feature of the BiLSTM layer; Feature fusion preprocessing: L2 normalization is performed on the data source features and path features respectively to eliminate the impact of differences in different feature dimensions; S504. Data balancing process: Since high-probability vulnerability samples are usually fewer than low-probability vulnerability samples, SMOTE (Synthetic Minority Oversampling) is used to oversample high-probability vulnerability samples and at the same time, low-probability vulnerability samples are randomly undersampled to make the ratio of the two classes in the training set tend to be 1:1, so as to avoid the model being biased towards the majority class samples. S505. Dataset partitioning: Specifically, the dataset is divided into a training set, a validation set, and a test set in a 7:2:1 ratio. The training set is used for training model parameters, the validation set is used for optimizing model hyperparameters (such as embedding dimension and BiLSTM hidden layer dimension), and the test set is used to verify the accuracy of the model's vulnerability proof.

[0056] Example 2 Please see Figure 2 . Figure 2 This is a schematic diagram of a static firmware vulnerability verification device disclosed in an embodiment of the present invention. Figure 2 As shown, an embodiment of the present invention discloses a static firmware vulnerability verification device comprising: Firmware code acquisition module 201 is used to acquire firmware binary code; The vulnerability entry point identification module 202 is used to identify potential vulnerabilities in the firmware binary code and obtain vulnerability entry points. The effective path filtering module 203 is used to perform reverse backtracking analysis starting from the vulnerability ingress point to obtain a set of effective data flow paths; the set of effective data flow paths includes several effective data flow paths, and each effective data flow path contains a data source; The vulnerability proof generation module 204 is used to verify the set of valid data flow paths to obtain vulnerability proofs.

[0057] It should be noted that this second embodiment is the product embodiment corresponding to the first embodiment, and the steps and methods included are the same as those in the first embodiment, and will not be described in detail in the second embodiment.

[0058] Example 3 This embodiment verifies the effectiveness and efficiency of the method of the present invention through experiments: The evaluation metrics are the number of analyses, the number of true vulnerabilities, the analysis time, and the average analysis time.

[0059] Number of analyses — the number of analyzable firmware binaries.

[0060] Real vulnerability count – The number of real vulnerabilities that have been verified and reported.

[0061] Analysis time — The time required to analyze all firmware for the dataset.

[0062] Average time – The average time required to analyze a single binary file of the dataset.

[0063] First, we selected the Karonte firmware dataset and the SaTC dataset. The Karonte dataset contains 49 firmware samples from four different vendors (Netgear, D-Link, TP-Link, and Tenda). The SaTC dataset was compared on additional images from Netgear, D-Link, and Tenda, containing a total of 384 binaries. For each dataset, we ran the evaluation on each binary containing a vulnerability endpoint in the firmware samples. In this evaluation, we compared it with SaTC (another static firmware analysis method) because SaTC reports vulnerabilities at a significantly higher rate than Karonte.

[0064] Table 1. Results of this invention on the Karonte dataset. Table 2 Results of this invention on the SaTC dataset The results in Tables 1 and 2 show that the method of the present invention significantly increases the number of analyzable files and verifies a large number of vulnerabilities that the SaTC method cannot analyze. It is worth noting that while increasing the number of vulnerabilities verified, the efficiency of the method in analyzing files is also much higher than that of the SaTC method, demonstrating the superiority of the present method in terms of accuracy and efficiency.

[0065] The system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0066] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0067] Finally, it should be noted that the static firmware vulnerability verification method and apparatus disclosed in the embodiments of the present invention are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A static firmware vulnerability verification method, characterized in that, The method includes: S1. Obtain firmware binary code; S2. Identify potential vulnerabilities in the firmware binary code to obtain vulnerability entry points; S3. Starting from the vulnerability entry point, perform reverse backtracking analysis to obtain a set of valid data flow paths; the set of valid data flow paths includes several valid data flow paths, and each valid data flow path contains a data source; S4. Verify the set of valid data flow paths to obtain a vulnerability proof.

2. The static firmware vulnerability verification method according to claim 1, characterized in that, The process of identifying potential vulnerabilities in the firmware binary code to obtain vulnerability ingress points includes: S21. Locate high-risk function calls from the firmware binary code to obtain the high-risk functions; S22. Use the call points of the high-risk functions as vulnerability import points.

3. The static firmware vulnerability verification method according to claim 1, characterized in that, Starting from the vulnerability ingress point, a reverse backtracking analysis is performed to obtain a set of valid data flow paths, including: S31. Create a core data flow analysis engine; the core data flow analysis engine is used to track the data flow path of function values; S32. Determine the function where the vulnerability's ingress point is located as the initial function; S33. Based on the program call graph, starting from the initial function, backtrack the caller functions layer by layer upwards, and use the core data flow analysis engine to find the program path directly related to the vulnerability entry point, thereby obtaining a set of data flow paths. S34. The validity of the data flow path set is identified to obtain a valid data flow path set.

4. The static firmware vulnerability verification method according to claim 3, characterized in that, The creation of the core data flow analysis engine includes: S311. Create a variable range; the variable range includes bit vectors and TOP values, used to model variables in the program; S312. During the data flow analysis process, a rich expression is constructed for each value flowing into the vulnerability ingress point; the rich expression contains the specific content of the variable value, records all source value dependencies of the variable value and all operations applied on the propagation path; S313. Parse the rich expression to obtain the composition of the input value.

5. The static firmware vulnerability verification method according to claim 3, characterized in that, According to the program call graph, starting from the initial function, the caller functions are traced back layer by layer upwards. Using the core data flow analysis engine, the program paths directly related to the vulnerability entry point are found, resulting in a set of data flow paths, including: S331. Locate the parent function that calls the initial function to obtain the set of calling functions; S332. Determine whether the set of called functions is an empty set; If the set of called functions is empty, the method flow ends; If the set of called functions is not empty, then proceed to step S333; S333. Select any function from the set of called functions; S334. Based on the program's call graph, backtrack upwards for any of the called functions to the upper-level functions directly related to the merging point to obtain the second-level set of called functions; S335. Determine whether the second-level call function set is an empty set, and obtain the first determination result; If the first judgment result is yes, then the core data flow analysis engine is used to record and add the obtained data flow path to the data flow path set; If the first judgment result is negative, then continue to backtrack upwards to the upper-level function according to the method of steps S334 to S335. The termination judgment condition for backtracking the data flow path is that at any stage of the reverse backtracking analysis, if the analysis engine determines that the data flow comes from an unusable variable, the obtained data flow path is added to the data flow path set.

6. The static firmware vulnerability verification method according to claim 5, characterized in that, The method further includes: during the data flow reverse backtracking analysis process, employing an inter-function analysis optimization strategy to optimize the data flow path; the inter-function analysis optimization strategy includes: S3361. During the reverse backtracking analysis, when a function call is encountered, the calling convention and function prototype of the called function are restored. S3362. Based on the calling convention and function prototype, perform the following two judgments at each calling point: Check if any pointers to the currently tracked value or variable were passed as arguments to the called function, and obtain the second result. The third judgment result is obtained by determining whether any value returned by the called function is ultimately used by the import point. If both the second and third judgment results are negative, it is determined that the function call has no impact on the data flow being analyzed, and the analysis of the internal logic of the called function is skipped to reduce analysis time; otherwise, the internal logic of the called function is analyzed in reverse backtracking.

7. The static firmware vulnerability verification method according to claim 3, characterized in that, The step of identifying the validity of the data flow path set to obtain a valid data flow path set includes: S341. Select any data flow path from the set of data flow paths; S342. Perform feature extraction on any of the data flow paths to obtain the feature vector of the data flow path; S343. Using the trained data flow path validity identification model, identify the feature vector of the data flow path to obtain the validity probability corresponding to any data flow path; If the effective probability is greater than the preset effective probability threshold, then any data flow path is added to the set of effective data flow paths; Otherwise, set any of the data flow paths as invalid data flow paths; S344. Traverse the set of data flow paths and perform steps S342 to S343 to identify the valid data flow paths.

8. The static firmware vulnerability verification method according to claim 1, characterized in that, The verification of the set of valid data flow paths to obtain vulnerability proof includes: S41. Based on the set of valid data flow paths, construct a set of data flow dependency graphs; the data flow dependency graphs include data dependency graphs that correspond one-to-one with the valid data flow paths; the data flow dependency graphs represent the data flow dependency graphs from the identified external data sources to the vulnerability entry point; the external data sources characterize the data sources of the valid data flow paths; S42. Classify the external data sources to obtain external data source category information; the external data source categories include: file operation category, network socket operation category, environment variable category, command line parameter category, and unknown source category; S43. Based on the external data source category information, process the data flow dependency graph set to obtain vulnerability proof.

9. The static firmware vulnerability verification method according to claim 8, wherein processing the data flow dependency graph set based on external data source category information to obtain vulnerability proof includes: S431. Select any data flow dependency graph from the set of data flow dependency graphs; S432. Perform feature extraction on any data flow dependency graph to obtain the feature vector of any data flow dependency graph; S433. Using the trained path verification model, identify the feature vector of any data flow dependency graph to obtain the vulnerability probability corresponding to the data flow dependency graph. If the probability of the vulnerability is greater than the preset vulnerability threshold, the data flow path corresponding to any data flow dependency graph is identified as a high-probability vulnerability, thereby proving that there is a clear and triggerable path from a user-controllable source to the ingress point, and completing the vulnerability verification. Otherwise, the data flow path corresponding to any of the data flow dependency graphs will be identified as a low-probability vulnerability; S434. Traverse all data flow dependency graphs in the data flow dependency graph set, and perform steps S432 to S433 to identify vulnerabilities and obtain proof of vulnerabilities.

10. A device for verifying vulnerabilities without static firmware, characterized in that, For implementing the static firmware vulnerability verification method as described in any one of claims 1-9, the apparatus comprises: Firmware code acquisition module, used to acquire firmware binary code; The vulnerability entry point identification module is used to identify potential vulnerabilities in the firmware binary code and obtain vulnerability entry points. The effective path filtering module is used to perform reverse backtracking analysis starting from the vulnerability ingress point to obtain a set of effective data flow paths; the set of effective data flow paths includes several effective data flow paths, and each effective data flow path contains a data source; The vulnerability proof generation module is used to verify the set of valid data flow paths and obtain vulnerability proofs.

Images