A binary patch existence detection method, system, device and storage medium

Abstract

This application relates to a method, system, device, and storage medium for detecting the existence of binary patches. The method includes: constructing an enhanced program dependency graph of a vulnerable version binary function, a patched version binary function, and a target binary function to be detected, wherein the nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges. Based on the differences between the enhanced program dependency graphs corresponding to the vulnerable version and the patched version, differential dependency slices are extracted and filtered to generate a feature signature set for the corresponding version. The enhanced program dependency graph of the target to be detected is matched with the two feature signature sets respectively using graph structure similarity matching to obtain a vulnerability matching score and a patch matching score. The scores are compared to determine whether the target to be detected has a patch vulnerability. This method enables high-precision and robust detection of patch existence in binary programs in source code-less scenarios.

Description

Technical Field

[0001] This application relates to the field of computer software security and program analysis technology, and in particular to a binary patch existence detection method, system, device and storage medium. Background Technology

[0002] In the current software supply chain, the reuse of third-party libraries and components is extremely common. While this improves development efficiency, it also leads to the widespread propagation of known vulnerabilities (1-Day vulnerabilities) through code reuse. Ensuring timely deployment of security patches in downstream software products is crucial for supply chain security. However, in many real-world scenarios (such as using closed-source commercial software, inheriting legacy binary components, and analyzing firmware images), source code and patch descriptions are often unavailable, rendering traditional source code-based patch detection methods ineffective.

[0003] Existing binary-level patch detection methods typically rely on syntactic similarity matching of basic blocks, control flow graphs (CFGs), or instruction sequences. These methods are heavily influenced by compiler optimizations and irrelevant code changes resulting from version evolution, making them prone to false positives or false negatives. Security patch modifications are usually localized and subtle, and their semantics are easily overwhelmed by a large amount of contextual noise. Therefore, how to accurately and robustly capture the semantic changes introduced by patches and suppress version evolution noise under pure binary conditions is a pressing technical challenge in this field.

[0004] Specifically, existing binary-level methods have the following technical drawbacks:

[0005] (1) Single semantic modeling dimension: Existing methods mainly rely on syntactic features or semantic information at the basic block level, which makes it difficult to fully capture the complex dependency changes introduced by patches, especially key semantic features such as memory access constraint modifications.

[0006] (2) Insufficient robustness across versions: When there is a large version difference between the target binary and the patch version, irrelevant changes introduced by code evolution will generate semantic noise, resulting in a significant decrease in detection accuracy.

[0007] (3) It is difficult to balance precision and recall: Expanding the matching range to improve recall will introduce false positives, while tightening the matching strategy to reduce false positives will miss real patches. Existing methods are difficult to achieve a good balance between the two.

[0008] (4) Sensitive to compiler optimization: Compiler optimization changes the syntax structure of the code, and existing methods based on syntax features are difficult to cope with differences in compiler configuration.

[0009] Therefore, there is an urgent need for a binary patch existence detection method and system that can comprehensively capture patch semantic features in source code-less scenarios, effectively suppress version evolution noise, and ensure high precision and high recall. Summary of the Invention

[0010] Therefore, it is necessary to provide a binary patch existence detection method, system, device, and storage medium that can achieve high-precision and high-robust detection of the existence of patches in binary programs in the absence of source code, in order to address the above-mentioned technical problems.

[0011] A binary patch existence detection method, the method comprising: Construct an enhanced program dependency graph for the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0012] Based on the differences between the enhancement dependency graphs corresponding to the vulnerability version and the patch version, differential dependency slices are extracted and filtered to generate vulnerability version signature sets and patch version signature sets.

[0013] The enhancement program dependency graph of the target binary function to be detected is matched with the vulnerability version signature set and the patch version signature set respectively to obtain vulnerability matching score and patch matching score.

[0014] The vulnerability matching score is compared with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function has been patched; otherwise, it is determined that a vulnerability exists.

[0015] A binary patch existence detection system, the system comprising: The dependency graph construction module is used to construct the enhanced program dependency graph of the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0016] The difference slice extraction and signature generation module is used to extract difference dependency slices based on the differences between the dependency graphs of the enhancement programs corresponding to the vulnerability version and the patch version, and to filter the difference dependency slices to generate a vulnerability version signature set and a patch version signature set.

[0017] The matching and discrimination module is used to perform graph structure similarity matching between the enhancement program dependency graph of the target binary function to be detected and the vulnerability version feature signature set and the patch version feature signature set, respectively, to obtain vulnerability matching score and patch matching score.

[0018] The patch detection module compares the vulnerability matching score with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function has been patched; otherwise, it is determined that a vulnerability exists.

[0019] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps: Construct an enhanced program dependency graph for the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0020] Based on the differences between the enhancement dependency graphs corresponding to the vulnerability version and the patch version, differential dependency slices are extracted and filtered to generate vulnerability version signature sets and patch version signature sets.

[0021] The enhancement program dependency graph of the target binary function to be detected is matched with the vulnerability version signature set and the patch version signature set respectively to obtain vulnerability matching score and patch matching score.

[0022] The vulnerability matching score is compared with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function has been patched; otherwise, it is determined that a vulnerability exists.

[0023] A computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Construct an enhanced program dependency graph for the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0024] Based on the differences between the enhancement dependency graphs corresponding to the vulnerability version and the patch version, differential dependency slices are extracted and filtered to generate vulnerability version signature sets and patch version signature sets.

[0025] The enhancement program dependency graph of the target binary function to be detected is matched with the vulnerability version signature set and the patch version signature set respectively to obtain vulnerability matching score and patch matching score.

[0026] The vulnerability matching score is compared with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function has been patched; otherwise, it is determined that a vulnerability exists.

[0027] Construct an enhanced program dependency graph for the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0028] Based on the differences between the enhancement dependency graphs corresponding to the vulnerability version and the patch version, differential dependency slices are extracted and filtered to generate vulnerability version signature sets and patch version signature sets.

[0029] The enhancement program dependency graph of the target binary function to be detected is matched with the vulnerability version signature set and the patch version signature set respectively to obtain vulnerability matching score and patch matching score.

[0030] The vulnerability matching score is compared with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function has been patched; otherwise, it is determined that a vulnerability exists.

[0031] The aforementioned binary patch existence detection method, system, device, and storage medium fundamentally solves the problem of the single-dimensional semantic modeling of traditional methods by constructing an enhanced program dependency graph containing three types of dependency edges: data, control, and memory. Data dependencies capture variable propagation paths, control dependencies characterize branch constraints, and memory dependencies model stack access order. Together, these three constitute a three-dimensional representation of patch semantics, enabling the solution to comprehensively capture deep semantic changes, including enhanced memory boundary checks and control flow logic corrections. Furthermore, the solution does not simply compare the entire graph; instead, it extracts the difference dependency slices between the vulnerability version and the patch version, using the difference nodes as seeds to propagate bidirectionally along the three types of dependency edges. This accurately aggregates the core semantic features introduced by the patch, while naturally filtering out non-semantic noise (such as register allocation changes and instruction reordering) caused by version iterations, compilation optimizations, or configuration differences, thus giving the solution excellent cross-version robustness. Furthermore, the scheme filters the extracted slices to generate feature signatures, and performs bidirectional graph matching on the augmented program dependency graph of the function to be detected with both vulnerability and patch feature signatures. The decision is made by comparing the relative magnitudes of the two matching scores. This mechanism eliminates the reliance on absolute thresholds for detection decisions, instead relying on a "competitive matching" of the semantic patterns of vulnerabilities and patches. This effectively avoids misjudgments caused by code similarity or contextual interference. While achieving high precision (accurately identifying the truly patched code), the complete dependency propagation of the difference slices ensures high recall (no missed patch features). In summary, the augmented program dependency graph is the semantic foundation for accurate extraction of difference slices, difference slices are a prerequisite for generating high-quality feature signatures, and bidirectional graph matching comparison is the decision-making loop that transforms semantic features into high-confidence judgments. Together, they achieve the technical effect of comprehensively capturing patch semantic features, effectively suppressing version evolution noise, and ensuring both high precision and high recall in source code-less scenarios. Attached Figure Description

[0032] Figure 1 This is a flowchart illustrating a binary patch existence detection method in one embodiment; Figure 2 This is a flowchart illustrating the binary program patch existence detection steps based on enhanced program dependency graph and differential slicing in one embodiment. Figure 3 This is a schematic diagram of the structure of an Enhanced Program Dependency Graph (E-PDG) in one embodiment; Figure 4 This is a structural block diagram of a binary patch existence detection system in one embodiment; Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0034] In one embodiment, such as Figure 1 As shown, a binary patch existence detection method is provided, including the following steps: Step 102: Construct an enhanced program dependency graph of the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0035] Specifically, obtain three binary functions related to the target vulnerability: the vulnerability version function (VF), the patch version function (PF), and the target function to be detected (TF).

[0036] Furthermore, the machine instructions of VF, PF, and TF are elevated to a unified intermediate representation (IR) layer, preferably using VEX IR as the intermediate representation. VEX IR (Valgrind EXpress Intermediate Representation) is an intermediate representation used to unify the semantics of different instruction set architectures (ISAs). Its core goal is to elevate machine instructions from heterogeneous architectures to a unified abstraction level, thereby supporting cross-platform and cross-architecture program analysis.

[0037] Furthermore, in VEX IR, binary programs are typically transformed in units of basic blocks, each corresponding to an IRSB (IR Super Block). An IRSB consists of a series of intermediate representation statements (IRStmt) and expressions (IRExpr), used to characterize state changes and computational semantics during program execution. IRSstmt primarily describes program state updates and control flow transfers, including register writes (Put), temporary variable assignments (WrTemp), memory write operations (Store), and conditional or unconditional jumps (Exit). IRExpr represents value retrieval and computation processes, such as register reads (Get), temporary variable reads (RdTmp), and the arithmetic and logical operations they constitute. By disassembling and IR boosting the target binary using binary analysis frameworks (such as angr or Valgrind), machine instructions from different architectures are converted into a unified IR representation, thereby eliminating the impact of instruction set differences on subsequent analysis. The original binary instructions first undergo instruction decoding and semantic mapping, being converted into an IR representation independent of the specific ISA.

[0038] Furthermore, based on the IR, enhanced program dependency graphs (E-PDGs) are constructed for VF, PF, and TF respectively. The nodes of the E-PDG correspond to IR statements, and the edges include data dependency edges, control dependency edges, and memory dependency edges. Constructing the enhanced program dependency graph at the granularity of function-level VEX IR statements aims not to perform precise program-proof dependency recovery, but to provide a more stable semantic structure carrier across versions for patch existence determination. Specifically, the basic blocks of the target function are first enumerated on the CFG, mapping each IR statement to a node (uniquely identified by the basic block address and statement index), and the normalized IR and semantic type (computation, control, memory read / write) are stored in the node attributes. Based on this, the three types of dependency edges are superimposed to form a unified representation.

[0039] (1) Data dependency edge: Characterizes the data flow relationship between variables, i.e., the def-use relationship. If statement S1 defines variable σ1, statement S2 uses σ1, and there is no redefinition of σ1 between the two, then there is a data dependency edge from S1 to S2. Specifically, by parsing the RdTmp (read temporary variable) and Get (read register) usage points in the IR expression, back-linking to the nearest WrTmp (write temporary variable) or Put (write register) definition point establishes the data dependency relationship. Among them, the temporary variable uses (bb_addr, tmp) as the namespace to avoid cross-block pollution, and the register maintains a global cache of the most recent register write to approximate cross-block propagation; (2) Control dependency edge: Characterizes the constraint of branch conditions on the executed statement. If the executability of statement S4 is affected by branch statement S3, then S4 has a control dependency edge on S3. Specifically, based on the basic block-level CFG to identify the real branch point, constraints are only established for conditional transfers (Exit) with multiple successors and non-constant guards, and connected to the statement nodes in its controlled successor block to avoid mistakenly establishing sequential execution as a control relationship; (3) Memory Dependency Edges: Characterizing the constraint relationships of memory access operations, conservative modeling using CFG constraints is adopted. Within a block, adjacent memory operations are connected sequentially according to statement order to encode happens-before relationships; between blocks, only the Store of the predecessor block is connected to the memory access node of the successor block along CFG adjacency edges, using a "reachable means potentially influential" approach to characterize post-write effects and ensure that no patch-related memory semantic propagation is missed. This strategy explicitly does not rely on alias refinement to pursue address-by-address accuracy, thus potentially introducing redundant edges. However, these redundancies are suppressed in subsequent dependency slicing driven by difference nodes + Top-k signature filtering, thereby achieving the robustness and reproducibility required for patch-oriented decision-making while ensuring coverage. A schematic diagram of the E-PDG structure is shown below. Figure 3 As shown.

[0040] Step 104: Based on the differences between the enhancement program dependency graphs corresponding to the vulnerability version and the patch version, extract the difference dependency slices and filter the difference dependency slices to generate the vulnerability version feature signature set and the patch version feature signature set.

[0041] Specifically, the complete process of the difference-dependent slice extraction algorithm (Algorithm 1) is as follows: Input: Vulnerability version E-PDG G v Patch version E-PDG G p Matching threshold θ, expansion radius r (default r=3) Output: Vulnerable version of the difference dependency slice set S v Patch version difference dependency slice set S p Algorithm 1: Difference-dependent slice extraction algorithm 1.H ← BuildHashIndex(G p / / Construct a hash index based on node semantics and structural features 2.M ← / / Initialize the set of matching pairs 3. for each v ∈ V(G) p do 4. hash v ← HashFeat(v) / / Calculate the hash feature of a node 5.C ← H(hash v / / Retrieve the set of candidate nodes for the vulnerability version using hash index 6. for each u ∈ C do 7. if NeighborhoodSim(u, v, G) v G p ) ≥ θ then / / Neighborhood structural similarity verification 8.M ← M ∪ {(u, v)} / / Match successful 9. break 10.end if 11. end for 12. end for 13.D v ← V(G v ) \π1(M) / / Set of differences in the vulnerability version (nodes that were not matched, π1 is the first projection) 14.D p ← V(G p) \π2(M) / / Patch version of the difference set (unmatched nodes, π2 is the second projection) 15.S v ← , S p ← / / Initialize the set of difference slices, with each element being a subgraph. 16. for each x ∈ D v do 17.S v ← S v ∪ {ExpandDependency(G v , x, r)} / / Bidirectional expansion along dependencies 18. end for 19. for each y ∈ D p do 20.S p ← S p ∪ {ExpandDependency(G p , y, r)} / / Bidirectional expansion along dependencies 21.end for 22.S v ← MergeByDependency(S v G v / / Depends on connectivity slice fusion 23.S p ← MergeByDependency(S p G p / / Depends on connectivity slice fusion 24. return S v , S p Where θ ∈ (0,1) is the matching threshold, with a default value of θ=0.3 as an empirical setting to avoid overly strict matching leading to missed detections. r represents the expansion radius of the difference dependency slice (the maximum number of hops to expand bidirectionally along data, control, and memory dependencies), with a default value of r=3 to strike a balance between covering the impact chain of patches and suppressing noise and control overhead. The difference dependency slice extraction process mainly includes the following three aspects.

[0042] (1) Node matching and difference identification: Nodes in the E-PDG of VF and PF are matched, and nodes that fail to match are identified as difference nodes. Specifically, a hash index based on node semantic and structural features is constructed to quickly align potentially corresponding node pairs, and the similarity of neighborhood structure is used for verification; (2) Dependency propagation expansion: Centered on each difference node, traverse forward and / or backward along the data dependency edge, control dependency edge, and memory dependency edge in its E-PDG to collect all nodes and edges within the preset expansion radius r, forming the initial difference slice. The default value of the expansion radius r is 3, which is a trade-off between covering the impact chain of the patch and suppressing noise and control overhead; (3) Slice fusion: Based on the dependencies between nodes, the initial dissimilar slices that are connected or overlapped are merged to form the final vulnerability feature slice set S. v and patch feature slice set S p .

[0043] Furthermore, (1) Importance score calculation: for S v and S p Each slice in the dataset is scored for importance, using the following formula:

[0044] Among them, |V i | represents the number of slice nodes, |E i | where C is the number of dependency edges. i V represents the number of nodes in the slice that are related to memory access and control statements. max The normalization factor is α, β, and γ, which are weighting coefficients and satisfy α + β + γ = 1. Preferably, α = 0.4, β = 0.4, and γ = 0.2. (2) Top-k feature selection: for S v and S p The slices are sorted in descending order of score, and the top k slices are selected to form the corresponding feature signature set. v and p The optimal value for parameter k is 4, which achieves the best balance between precision and recall. (3) Signature structuring: The selected feature slices and their dependencies are encoded into structured feature signatures for subsequent matching and judgment.

[0045] Step 106: Perform graph structure similarity matching between the enhancement program dependency graph of the target binary function to be detected and the vulnerability version signature set and the patch version signature set, respectively, to obtain the vulnerability matching score and the patch matching score.

[0046] Specifically, the E-PDG of TF will be compared with... v and p Graph structure similarity matching is performed to calculate the vulnerability matching score. vMatch score with patch p The graph structure similarity matching uses a matching algorithm based on subgraph isomorphism or graph neural network to calculate the similarity between the E-PDG of TF and each feature signature slice, and takes the average of all similarities within the same feature signature set.

[0047] Step 108: Compare the vulnerability matching score with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function to be detected has been patched; otherwise, it is determined that a vulnerability exists.

[0048] Specifically, compare scores p With Score v If Score p Score v If the patch is applied, the target function TF is determined to have been patched; otherwise, TF is determined not to have been patched and a vulnerability exists.

[0049] The aforementioned binary patch existence detection method fundamentally solves the problem of the single semantic modeling dimension of traditional methods by constructing an enhanced program dependency graph containing three types of dependency edges: data, control, and memory. Data dependencies capture variable propagation paths, control dependencies characterize branch constraints, and memory dependencies model stack access order. Together, these three constitute a three-dimensional representation of patch semantics, enabling the solution to comprehensively capture deep semantic changes, including enhanced memory boundary checks and control flow logic corrections. Furthermore, the solution does not simply compare the entire graph; instead, it extracts the difference dependency slices between the vulnerability version and the patch version, using the difference nodes as seeds to propagate bidirectionally along the three types of dependency edges. This accurately aggregates the core semantic features introduced by the patch while naturally filtering out non-semantic noise (such as register allocation changes and instruction reordering) caused by version iterations, compilation optimizations, or configuration differences, thus giving the solution excellent cross-version robustness. Furthermore, the scheme filters the extracted slices to generate feature signatures, and performs bidirectional graph matching on the augmented program dependency graph of the function to be detected with both vulnerability and patch feature signatures. The decision is made by comparing the relative magnitudes of the two matching scores. This mechanism eliminates the reliance on absolute thresholds for detection decisions, instead relying on a "competitive matching" of the semantic patterns of vulnerabilities and patches. This effectively avoids misjudgments caused by code similarity or contextual interference. While achieving high precision (accurately identifying the truly patched code), the complete dependency propagation of the difference slices ensures high recall (no missed patch features). In summary, the augmented program dependency graph is the semantic foundation for accurate extraction of difference slices, difference slices are a prerequisite for generating high-quality feature signatures, and bidirectional graph matching comparison is the decision-making loop that transforms semantic features into high-confidence judgments. Together, they achieve the technical effect of comprehensively capturing patch semantic features, effectively suppressing version evolution noise, and ensuring both high precision and high recall in source code-less scenarios.

[0050] In one embodiment, such as Figure 2 As shown, a binary program patch existence detection step based on enhanced program dependency graph and difference slicing is provided. The specific steps are as follows: S1: Obtain the input functions VF, PF, TF Assuming a vulnerability CVE-XXXX-XXXX is known to exist in a certain OpenSSL library, obtain the binary version of the library before the vulnerability was publicly disclosed (extracting the vulnerable function VF from it), and the binary version after the official patch was applied (extracting the patched function PF from it). Simultaneously, extract the target function TF, which is suspected of containing this OpenSSL library, from the software product to be audited.

[0051] S2: The intermediate signal indicates a conversion to the IR layer. Using Valgrind VEX IR or a similar binary analysis framework (such as Angr), the x86-64 machine instructions for VF, PF, and TF are each promoted to a unified VEX IR representation. The specific implementation is as follows: (1) Load the target binary program and initialize it using angr's project object. The framework will automatically recognize the binary architecture (x86-64). (2) Call interfaces such as CFGRecovery to construct the program control flow graph and promote the machine instructions in each basic block to VEX IR intermediate representation; (3) For each basic block within the function, traverse each IR statement (IRStmt) in its IR basic block (IRSB) and create it as a graph node. The node is uniquely identified by the basic block address and statement index. (4) Store the normalized IR and semantic type (computation, control, memory read / write) in the node attributes. (5) Perform the same operation on VF, PF and TF to obtain their IR representations respectively.

[0052] S3: Building E-PDG Data / Control / Memory Dependencies Based on the VEX IR obtained in step two, construct the augmentation dependency graph E-PDG for VF, PF, and TF: (1) Data dependency construction: Traverse the IR instruction sequence, and by parsing the RdTmp (read temporary variable) and Get (read register) usage points in the IR expression, backlink to the nearest WrTmp (write temporary variable) or Put (write register) definition point to establish data dependency edges. Temporary variables use (bb_addr, tmp) as the namespace to avoid cross-block pollution, while registers maintain a global cache of the most recent register write to approximate cross-block propagation; (2) Control Dependency Construction: Based on the control flow graph (CFG) of the IR program, the control constraints of conditional branch statements on statements within their successor blocks are identified. Specifically, based on the basic block-level CFG, real branch points are identified, and constraints are established only for conditional transfers (Exits) with multiple successors and non-guard values, and connected to the statement nodes within their controlled successor blocks to avoid mistakenly constructing sequential execution as control relationships; (3) Memory dependency construction: Identify Load and Store instructions in IR and analyze the dependencies of memory access operations. Connect adjacent memory operations in statement order within a block to encode happens-before relationships; connect the Store of the predecessor block to the memory access node of the successor block only along the CFG adjacency edge between blocks, and characterize the post-write effect in a reachable-may-have manner to ensure that no patch-related memory semantic propagation is missed.

[0053] Through the above steps, the enhanced procedure dependency graphs G for VF, PF, and TF are constructed respectively. v G p and G t .

[0054] S4: Difference slice extraction node matching, dependency expansion, and slice fusion. Compare G v and G p Extract differentially dependent slices: (1) Node matching and difference identification: First, G is matched and identified across the entire graph. v and G p The nodes are matched. By constructing a hash index based on the semantic and structural features of the nodes, possible corresponding node pairs are quickly aligned, and verified by neighborhood structural similarity (threshold θ=0.3), resulting in a node matching set M. Unmatched nodes are considered as difference seed nodes. D v ← V(G v π1(M), the set of differences in the vulnerability version; D p ← V(G p π2(M), the set of differences in the patch version; (2) Dependency propagation expansion: Taking each difference node as the center, perform bidirectional dependency traversal in its respective E-PDG. Set the expansion radius r=3, and perform forward and / or backward traversal along data dependency edges, control dependency edges and memory dependency edges to collect reachable nodes and edges, forming the initial difference slice; (3) Slice fusion: Based on the dependencies between nodes, the initial slices with dependent connectivity or overlapping nodes are merged to form the final vulnerability feature slice set S. v and patch feature slice set S p .

[0055] S5: Feature signature generation, importance scoring, and Top-k selection. (1) Importance score calculation: S is calculated according to the scoring formula. v and S p For each slice in the dataset, an importance score is calculated:

[0056] Among them, |V i | represents the number of slice nodes, |E i | where C is the number of dependency edges. i V represents the number of nodes in the slice that are related to memory access and control statements. max Normalization factor; (2) Top-k feature selection: For S v and S p The slices are sorted in descending order of score, and the top k=4 slices from each slice are selected to form the feature signature set. v and p ; (3) Signature structured encoding: The selected feature slices and their dependencies are encoded into structured feature signatures. The signature format includes a list of nodes and a list of dependent edges.

[0057] S6: Graph Structure Matching Score Calculation v and Score p (1) Graph structure similarity matching: The E-PDG (G) of the objective function is used to match the graph structure similarity. t ) respectively with v and p Subgraph similarity matching is performed on each signature slice. A similarity score (sim) is calculated using an algorithm based on graph edit distance or a pre-trained graph neural network model. (2) Calculate the matching score: calculate G respectively t and p Average similarity as Score p ,and v Average similarity as Score v :

[0058]

[0059] S7: Patch Existence Determination Score p Scorev Binary classification decision: Comparing scores p With Score v The size of the score. p Score v If the condition is met, the output will be: "The target function TF has included the CVE-XXXX-XXXX patch"; otherwise, the output will be: "The target function TF has a CVE-XXXX-XXXX vulnerability", which is the patch existence determination result.

[0060] In one embodiment, the vulnerable version binary function, the patched version binary function, and the target binary function to be detected are each elevated to a unified intermediate representation, and an enhancement program dependency graph corresponding to different versions of binary functions is constructed based on the intermediate representation.

[0061] In one embodiment, data dependency edges are established by parsing variable usage points in the intermediate representation statements and back-connecting them to the nearest definition point. Control dependency edges are established by identifying conditional branch statements in the control flow graph and connecting them to statement nodes within the successor block controlled by the conditional branch statements. Adjacent memory operations are connected in statement order within the basic block to encode the memory access order, and memory dependency edges are established by connecting memory write operations of the predecessor block to memory access nodes of the successor block along the adjacent edges of the control flow graph. The construction of data dependency edges, control dependency edges, and memory dependency edges is performed in parallel to build a corresponding enhanced program dependency graph based on the vulnerability version binary function, the patch version binary function, and the target binary function to be detected.

[0062] In one embodiment, node matching is performed on the enhancement program dependency graph corresponding to the vulnerability version and the patch version. Unmatched nodes are identified as difference seed nodes. Using each difference seed node as the center, bidirectional expansion is performed along the data dependency edge, the control dependency edge, and the memory dependency edge to collect nodes and edges within a preset radius to form an initial difference slice. The initial difference slices are merged according to the dependency connectivity between nodes to obtain the final vulnerability feature slice set and patch feature slice set.

[0063] In one embodiment, a hash index is constructed based on the semantic and structural features of the nodes in the enhancement program dependency graph corresponding to the patch version binary function. For each vulnerability version node in the enhancement program dependency graph of the vulnerability version binary function, the hash feature of the vulnerability version node is calculated, and a candidate node set is obtained through the hash index. For each candidate node in the candidate node set, the neighborhood structure similarity between the candidate node and the current vulnerability version node is calculated. If the similarity is greater than a preset matching threshold, the node pair is determined to be matched.

[0064] It is worth noting that, compared with existing technologies, the above technical steps have the following advantages: (1) More comprehensive semantic modeling: By integrating three types of semantic relationships—data dependency, control dependency, and memory dependency—the system comprehensively captures the semantic changes of the program introduced by the patch, especially significantly improving the modeling ability of key features such as memory access constraint modifications. Experiments show that after removing memory dependency, the F1 score decreased by 7.44 percentage points and the recall rate decreased by 7.31 percentage points, verifying the core role of memory dependency modeling. (2) More accurate feature extraction: Using the difference node as a seed to expand the extraction slice along the dependency relationship, it can aggregate the core semantic features of the patch while filtering irrelevant differences introduced by version evolution (such as instruction adjustments, variable changes, etc.). Experiments show that after removing the slice extraction module, the precision rate decreased from 94.54% to 79.92%, proving the key role of the slice extraction module in noise reduction and feature selection. (3) A good balance between precision and recall: By using importance scoring and Top-k screening strategies, a high precision (94.54%) and a high recall (85.23%) are maintained, with an overall F1 score of 89.64%, which is better than the existing mainstream methods BinXray (F1 score 80.72%) and PatchDiscovery (F1 score 88.76%). (4) Excellent cross-version robustness: In scenarios with version differences from 1 to 9, the method maintains stable discrimination performance, with the F1 score gradually decreasing from 100% to 76.11%, always remaining at a high level. The average F1 score of the five sets of experiments reached 90.21%, verifying the strong robustness of the method to software version evolution. (5) Wide range of applicable scenarios: The method is based entirely on binary analysis and does not rely on source code and debugging information, making it suitable for security auditing of various source code-free scenarios such as closed-source software, third-party components, and secondary encapsulation in the supply chain.

[0065] It should be understood that, although Figures 1-2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figures 1-2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0066] In one embodiment, such as Figure 4As shown, a binary patch existence detection system is provided, including: a dependency graph construction module 402, a difference slice extraction and feature signature generation module 404, a matching and discrimination module 406, and a patch detection module 408, wherein: The dependency graph construction module 402 is used to construct an enhanced program dependency graph of the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0067] The difference slice extraction and feature signature generation module 404 is used to extract difference dependency slices based on the differences between the enhancement program dependency graphs corresponding to the vulnerability version and the patch version, and to filter the difference dependency slices to generate a vulnerability version feature signature set and a patch version feature signature set.

[0068] The matching and discrimination module 406 is used to perform graph structure similarity matching between the enhancement program dependency graph of the target binary function to be detected and the vulnerability version feature signature set and the patch version feature signature set, respectively, to obtain vulnerability matching score and patch matching score.

[0069] The patch detection module 408 is used to compare the vulnerability matching score with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function to be detected has been patched; otherwise, it is determined that a vulnerability exists.

[0070] In one embodiment, the instruction promotion module 410 is used to promote the vulnerable version binary function, the patch version binary function, and the target binary function to be detected to a unified intermediate representation.

[0071] In one embodiment, the difference slice extraction and feature signature generation module 404 is further configured to perform importance scoring on each difference dependency slice in the initial feature slice set of the vulnerability and the initial feature slice set of the patch, respectively, to obtain an importance scoring result:

[0072] in, For the difference-dependent slice, α, β, and γ are the weight coefficients and satisfy α + β + γ = 1, |V i | represents the number of nodes in the differentially dependent slice, |E i | where C is the number of dependency edges. i V represents the number of nodes related to memory access and control statements in the differentially dependent slice. max As the normalization factor, The category of feature slice combination, A set of vulnerability feature slices, The vulnerability feature slice set and the patch feature slice set are respectively sorted in descending order of importance score for the difference dependency slices in the initial vulnerability feature slice set and the initial patch feature slice set. The top threshold difference dependency slices in each sorted set are selected as feature slices. The selected feature slices and their dependencies are encoded into structured feature signatures. The corresponding feature signature set is reconstructed to obtain the vulnerability feature slice set and the patch feature slice set.

[0073] For specific limitations regarding a binary patch existence detection system, please refer to the limitations of a binary patch existence detection method described above, which will not be repeated here. Each module in the aforementioned binary patch existence detection system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0074] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input system connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When executed by the processor, the computer program implements a binary patch presence detection method. The display screen can be an LCD screen or an e-ink screen. The input system can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device casing, or an external keyboard, touchpad, or mouse.

[0075] Those skilled in the art will understand that Figures 4-5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0076] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps: Construct an enhanced program dependency graph for the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0077] Based on the differences between the enhancement dependency graphs corresponding to the vulnerability version and the patch version, differential dependency slices are extracted and filtered to generate vulnerability version signature sets and patch version signature sets.

[0078] The enhancement program dependency graph of the target binary function to be detected is matched with the vulnerability version signature set and the patch version signature set respectively to obtain vulnerability matching score and patch matching score.

[0079] The vulnerability matching score is compared with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function has been patched; otherwise, it is determined that a vulnerability exists.

[0080] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Construct an enhanced program dependency graph for the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges.

[0081] Based on the differences between the enhancement dependency graphs corresponding to the vulnerability version and the patch version, differential dependency slices are extracted and filtered to generate vulnerability version signature sets and patch version signature sets.

[0082] The enhancement program dependency graph of the target binary function to be detected is matched with the vulnerability version signature set and the patch version signature set respectively to obtain vulnerability matching score and patch matching score.

[0083] The vulnerability matching score is compared with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function has been patched; otherwise, it is determined that a vulnerability exists.

[0084] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0085] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0086] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A binary patch existence detection method, characterized by, The method includes: Construct an enhanced program dependency graph of the vulnerable version binary function, the patched version binary function, and the target binary function to be detected, wherein the nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges; Based on the differences between the enhancement program dependency graphs corresponding to the vulnerability version and the patch version, differential dependency slices are extracted, and the differential dependency slices are filtered to generate a vulnerability version feature signature set and a patch version feature signature set. The enhancement program dependency graph of the target binary function to be detected is matched with the vulnerability version signature set and the patch version signature set respectively to obtain the vulnerability matching score and the patch matching score. The vulnerability matching score is compared with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function to be detected has been patched; otherwise, it is determined that a vulnerability exists.

2. The method of claim 1, wherein, Before the steps of constructing the augmentation dependency graph of the vulnerable version binary function, the patched version binary function, and the target binary function to be detected, the following are also included: The vulnerable version binary function, the patched version binary function, and the target binary function to be detected are all elevated to a unified intermediate representation, and an enhancement program dependency graph corresponding to different versions of binary functions is constructed based on the intermediate representation.

3. The method according to claim 2, characterized in that, Construct an enhancement program dependency graph of the vulnerable version binary function, the patched version binary function, and the target binary function to be detected, including: Data dependency edges are established by parsing the variable usage points in the intermediate representation statements and back-connecting them to the nearest definition point; Based on the control flow graph, conditional branch statements are identified and connected to statement nodes within the controlled successor block of the conditional branch statements to establish control dependency edges; Within a basic block, adjacent memory operations are connected in statement order to encode the memory access order, and along the adjacent edges of the control flow graph, the memory write operations of the predecessor block are connected to the memory access nodes of the successor block to establish memory dependency edges. The construction of the data dependency edges, control dependency edges, and memory dependency edges is performed in parallel to build the corresponding enhanced program dependency graph based on the vulnerability version binary function, the patch version binary function, and the target binary function to be detected.

4. The method according to claim 3, characterized in that, Based on the differences between the enhancement dependency graphs corresponding to the vulnerability version and the patch version, differential dependency slices are extracted, and these slices are then filtered to generate a vulnerability version signature set and a patch version signature set, including: Node matching is performed on the enhancement program dependency graph corresponding to the vulnerability version and the patch version. Unmatched nodes are identified as difference seed nodes. With each difference seed node as the center, bidirectional expansion is performed along the data dependency edge, the control dependency edge and the memory dependency edge to collect nodes and edges within a preset radius to form an initial difference slice. The initial difference slices are merged based on the dependency connectivity between nodes to obtain the final vulnerability feature slice set and patch feature slice set.

5. The method according to claim 4, characterized in that, The enhancement program dependency graph of the target binary function to be detected is matched with the vulnerability version signature set and the patch version signature set using graph structure similarity to obtain vulnerability matching score and patch matching score, including: Construct the hash index of the dependency graph of the patch version binary function corresponding to the enhancement program based on the semantic and structural characteristics of the nodes; For each vulnerable version node in the augmentation dependency graph of the vulnerable version binary function, calculate the hash feature of the vulnerable version node, and obtain a set of candidate nodes through the hash index; For each candidate node in the candidate node set, calculate the neighborhood structure similarity between the candidate node and the current vulnerability version node. If the similarity is greater than a preset matching threshold, then the node pair is determined to be matched.

6. A binary patch existence detection system, characterized in that, The system includes: The dependency graph construction module is used to construct an enhanced program dependency graph of the vulnerable version binary function, the patched version binary function, and the target binary function to be detected. The nodes of the enhanced program dependency graph correspond to program instructions, and the edges include data dependency edges, control dependency edges, and memory dependency edges. The difference slice extraction and feature signature generation module is used to extract difference dependency slices based on the differences between the enhancement program dependency graphs corresponding to the vulnerability version and the patch version, and to filter the difference dependency slices to generate a vulnerability version feature signature set and a patch version feature signature set. The matching and discrimination module is used to perform graph structure similarity matching between the enhancement program dependency graph of the target binary function to be detected and the vulnerability version feature signature set and the patch version feature signature set, respectively, to obtain vulnerability matching score and patch matching score; The patch detection module is used to compare the vulnerability matching score with the patch matching score. If the patch matching score is greater than the vulnerability matching score, it is determined that the target binary function to be detected has been patched; otherwise, it is determined that a vulnerability exists.

7. The system according to claim 6, characterized in that, The instruction elevation module is used to elevate the vulnerable version binary function, the patched version binary function, and the target binary function to a unified intermediate representation.

8. The method according to claim 6, characterized in that, The difference slice extraction and feature signature generation module is further used to perform importance scoring on each difference dependency slice in the initial feature slice set of the vulnerability and the initial feature slice set of the patch, respectively, to obtain the importance score result: in, For the difference-dependent slice, α, β, and γ are the weight coefficients and satisfy α + β + γ = 1, |V i | represents the number of nodes in the differentially dependent slice, |E i | where C is the number of dependency edges. i V represents the number of nodes related to memory access and control statements in the differentially dependent slice. max As the normalization factor, The category of feature slice combination, A set of vulnerability feature slices, A set of patch feature slices; The difference-dependent slices in the initial feature slice set of the vulnerability and the initial feature slice set of the patch are sorted in descending order according to the importance score results. The top-ranked threshold difference-dependent slices are selected as feature slices. The selected feature slices and their dependencies are encoded into structured feature signatures. The corresponding feature signature sets are reconstructed to obtain the vulnerability feature slice set and the patch feature slice set.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images