A binary security patch detection method and system

Abstract

The application provides a binary security patch detection method and system, electronic equipment and storage medium, and relates to the technical field of network security.The application can effectively reduce the differential noise introduced by variable renaming, compiler optimization and other factors by processing the pseudo code of the binary program through the iterative variable mapping and differential alignment algorithm, generate the high-quality pseudo code differential text after alignment, and provide clear and accurate input basis for subsequent security analysis;Further, through the large language model agent analysis mechanism, the program semantic information across functions and processes can be intelligently identified and utilized, the security impact of the patch is deeply reasoned, and finally the accurate detection and judgment of the binary security patch are realized.The application provides a security patch detection scheme which does not depend on the source code, can effectively process the binary program difference noise, and can comprehensively utilize the context information for accurate judgment.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a binary security patch detection method, system, electronic device, and storage medium. Background Technology

[0002] In software security maintenance, timely identification and application of security patches are crucial. Several security patch detection methods exist in the current technology. For example, Existing Technology 1 (CN120408641A) proposes a security patch variant localization method based on a two-dimensional feature design. This method preprocesses commit records in open-source software code repositories to extract information such as commit identifiers, titles, text, changed file paths, and code changes. Based on this, it designs similarity features and representational features, and uses a random forest model for prediction. However, this approach heavily relies on source code and commit history information, making it unsuitable for closed-source software, firmware, or IoT devices released only in binary form. Furthermore, this method lacks the ability to analyze program execution semantics and cross-function context. Existing Technology 2 (CN115729741A) proposes an automatic security patch localization method that integrates multi-dimensional features. This method collects information from vulnerability databases such as GitHub, CVE, and NVD, extracts deep semantic features using a pre-trained language model, and combines expert features extracted using the GumTree tool with a decision tree model for prediction. This approach also relies on vulnerability description text, submission information, and source code, making it difficult to apply to binary program analysis scenarios that lack this high-level information.

[0003] In summary, existing technical solutions mainly suffer from the following problems: 1) They generally rely on high-level information such as source code, commit records, and vulnerability descriptions, and cannot be applied to closed-source binary programs; 2) At the binary level, due to compilation optimization, variable names and type information are lost, and direct code differencing will generate a lot of noise; 3) They lack the ability to effectively utilize cross-function and cross-process context information for deep semantic reasoning, resulting in low accuracy in complex version updates (which mix security fixes, feature additions, and optimizations). Summary of the Invention

[0004] In view of this, the technical problem to be solved by the present invention is: how to solve the problem of low accuracy of binary security patch detection caused by lack of source code, large binary differential noise and insufficient utilization of context information.

[0005] On one hand, the present invention provides a binary security patch detection method, comprising the following steps: S1, pseudocode differential generation: obtaining the binary program before patching and the binary program after patching, locating the set of patch-related functions through function-level matching, generating pseudocode for the functions in the set of patch-related functions, and discovering and eliminating variable naming differences noise introduced by compilation or decompilation in the pseudocode through variable correspondence, generating aligned pseudocode differential text; and using an iterative variable mapping and differential alignment algorithm to process the pseudocode, generating aligned pseudocode differential text; S2, semantic analysis and judgment: based on a large language model, combined with the context information obtained as needed from the binary program before patching and / or the binary program after patching, performing security patch judgment analysis on the pseudocode differential text.

[0006] Optionally, in step S1, an iterative variable mapping and difference alignment algorithm is used to discover and eliminate variable naming difference noise in the pseudocode.

[0007] Optionally, in step S1, function-level matching includes: loading the pre-patch binary program and the post-patch binary program into the decompilation environment to generate an analysis database; using a function-level comparison plugin to compare the functions of the pre-patch binary program and the post-patch binary program, and exporting a function mapping table, which records the best matching function that is completely consistent, the partially matching functions with different contents, and the unmatched functions that exist only in either the pre-patch binary program or the post-patch binary program; and using the partially matching functions and the unmatched functions as a set of patch-related functions.

[0008] Optionally, the iterative variable mapping and difference alignment algorithm includes the following iterative steps: S11, statement sequence extraction: extract statement sequences from the pseudocode generated by the functions of the pre-patch binary program and the post-patch binary program respectively; S12, initial normalization: using the function mapping table, simultaneously normalize the known corresponding function names in the functions of the pre-patch binary program and the post-patch binary program; S13, MUM discovery: in the normalized statement sequences, find the longest matching segment that appears only once in the statement sequences of the functions of the pre-patch binary program and the post-patch binary program, i.e., the maximum unique match MUM; S14, variable mapping extraction: extract the M from step S13... In the UM segment, the co-occurrence relationship of statistical variables is generated to form a candidate variable mapping table. A frequency-based voting mechanism is adopted, and the variable mapping relationship in the candidate variable mapping table is only accepted when the difference between the highest and second highest co-occurrence frequency of a variable exceeds a preset threshold. S15, convergence judgment and re-normalization: If the variable mapping table obtained in this round is consistent with that in the previous round, the mapping is determined to have converged and the iteration ends; otherwise, the statement sequence obtained in step S11 is re-normalized using the new variable mapping table, the corresponding variables are replaced with unified identifiers, and the process returns to step S13 for the next round of iteration. S16, difference generation: After the iteration converges, a unified pseudocode difference text is generated based on the final function mapping table and variable mapping table.

[0009] Optionally, in step S14, the preset threshold for the difference between the highest co-occurrence frequency and the second highest co-occurrence frequency is determined using a frequency-based conservative voting mechanism.

[0010] Optionally, step S2 includes the following steps: S21, pre-filtering: using a large language model to quickly filter the pseudocode differential text, eliminating non-security-related changes and retaining potential security patches; S22, iterative analysis: performing iterative contextual analysis on potential security patches to obtain a judgment result; S23, result output: outputting the judgment result of whether a potential security patch is a security patch, and generating a structured patch analysis report containing the judgment basis.

[0011] Optionally, in step S22, the iterative context analysis includes the following operations performed by the analysis agent and the context agent: the analysis agent performs security impact reasoning based on the currently available differential and context information, identifies information gaps, and generates a context request; the context agent responds to the context request, retrieves and returns the required context information from the decompiled environment of the pre-patch binary program; wherein, the analysis agent merges the returned context information to update the judgment result and confidence level until the confidence level reaches a preset threshold or the number of iterations reaches a preset upper limit.

[0012] Optionally, in step S22, the context information retrieved by the context proxy includes at least one of the following: the complete pseudocode of the specified function; caller or callee information obtained through call graph analysis; source, propagation, or usage location information of key variables obtained through data flow tracing; and code slices obtained by performing forward and / or backward slices within the function boundary, starting from the code behavior involved in the request.

[0013] Optionally, in step S22, when the context agent encounters an uncertain call relationship or data flow while responding to a context request and / or retrieving context information, it explicitly marks the corresponding information gap and records it in the evidence chain.

[0014] Optionally, in step S23, the structured patch analysis report may also include: general vulnerability enumeration CWE type, repair strategy, evidence chain, and confidence score.

[0015] On the one hand, the present invention also provides an electronic device, including a processor and a memory communicatively connected to the processor; wherein the memory stores a computer program / instruction executable by the processor, and when the computer program / instruction is executed by the processor, it implements the binary security patch detection method described above.

[0016] On the one hand, the present invention also provides a computer-readable storage medium having a computer program / instruction stored thereon, which, when executed by a processor, implements the binary security patch detection method described above.

[0017] On the other hand, the present invention also provides a binary security patch detection system, comprising: a pseudocode difference generation module, used to perform step S1 as described above to generate aligned pseudocode difference text; and a large language model proxy analysis module, used to perform step S2 as described above to analyze the pseudocode difference text and output security patch determination results.

[0018] Optionally, the pseudocode difference generation module is integrated into the decompilation environment, and the context agent in the large language model agent analysis module communicates with the decompilation environment to retrieve context information from it.

[0019] Implementing this invention offers the following advantages: This invention processes the pseudocode of binary programs using an iterative variable mapping and differential alignment algorithm, effectively reducing differential noise introduced by factors such as variable renaming and compiler optimization, generating high-quality aligned pseudocode differential text, providing a clear and accurate input foundation for subsequent security analysis; furthermore, through a large language model proxy analysis mechanism, it can intelligently identify and utilize cross-function and cross-process program semantic information to perform in-depth security impact reasoning on patches, ultimately achieving accurate detection and judgment of binary security patches. This invention, through iterative variable mapping and differential alignment algorithms, first solves the noise problem caused by variable renaming and compiler optimization, providing high-quality input for subsequent analysis; then, through a large language model proxy analysis mechanism, it solves the problem of insufficient utilization of cross-function contextual semantic information; the synergistic effect of these two mechanisms jointly solves the fundamental problem of low accuracy in binary security patch detection, ultimately achieving high accuracy and high reliability in detection. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating a binary security patch detection method in one embodiment; Figure 2 This is a flowchart of the pseudocode difference generation module in one embodiment; Figure 3 Here is a flowchart of the proxy analysis phase of a large language model in one embodiment; Figure 4 This is an example of the iterative variable mapping discovery process of the IMP-Diff algorithm in one embodiment. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. The step numbers in the following embodiments are only for ease of explanation and do not limit the order of the steps. The execution order of each step in the embodiments can be adapted according to the understanding of those skilled in the art.

[0022] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0023] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0024] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0025] Example 1 In this embodiment, as Figure 1 The binary security patch detection method shown includes the following steps: S1, Pseudocode Differential Generation: Obtain the binary program before patching and the binary program after patching, locate the set of patch-related functions through function-level matching, generate pseudocode for the functions in the set of patch-related functions, and discover and eliminate noise from variable naming differences introduced by compilation or decompilation in the pseudocode through variable correspondence, generating aligned pseudocode differential text; and use an iterative variable mapping and differential alignment algorithm to process the pseudocode and generate aligned pseudocode differential text. S2, Semantic Analysis and Judgment: Based on a large language model, and combined with contextual information obtained as needed from the pre-patch binary program and / or post-patch binary program, security patch judgment analysis is performed on the pseudocode differential text.

[0026] In step S1, an iterative variable mapping and differential alignment algorithm (IMP-Diff algorithm) is used to discover and eliminate variable naming difference noise in the pseudocode.

[0027] In this embodiment, in step S1, function-level matching includes: like Figure 2 As shown, the pre-patch binary program and the post-patch binary program are loaded into the decompilation environment to generate an analysis database; A function-level comparison plugin is used to compare functions in the pre-patch and post-patch binary programs, and a function mapping table is exported. The function mapping table records the best matching function that is completely identical, partially matching functions with differences, and unmatched functions that exist only in either the post-patch or pre-patch binary program. Furthermore, partially matching and unmatched functions are used as a priority candidate set of patch-related functions to narrow down the range of subsequent difference generation.

[0028] In this embodiment, the aforementioned set of patch-related functions calls the decompilation component to generate corresponding pseudocode representations. Pseudocode, compared to assembly, possesses higher-level structural information, capable of preserving semantic clues while masking architectural details, thus providing a more suitable input representation for iterative variable mapping and difference alignment algorithms.

[0029] In this embodiment, each function of the binary program before patching and the corresponding function of the binary program after patching form a function pair.

[0030] In this embodiment, for partially matching function pairs, inconsistent function variable naming in the patched binary program can generate significant noise in the pseudocode difference. This solution employs an iterative MUM (Maximal Unique Match)-driven difference generation algorithm to progressively discover and continuously normalize variable mapping relationships until convergence, at which point aligned difference text is output. The iterative variable mapping and difference alignment algorithm includes the following iterative steps:

[0031] S11, Statement Sequence Extraction: Extract statement sequences from the pseudocode generated by the functions of the binary program before patching and the binary program after patching, respectively, as the basic input for matching and alignment; S12, Initial Normalization: Using the function mapping table, the known corresponding function names in the functions of the binary program before patching and the functions of the binary program after patching are uniformly normalized to reduce irrelevant differences caused by different function names. S13, MUM finds: In the normalized statement sequence, find the longest matching segment that appears only once in the statement sequence of functions in the binary program before patching and functions in the binary program after patching, i.e., the maximum unique match MUM; S14, Variable Mapping Extraction: Statistically analyze the co-occurrence relationships of variables from the MUM fragments and generate a candidate variable mapping table; To reduce erroneous variable mapping caused by accidental matching, the variable mapping adopts a frequency-based voting mechanism, and only accepts the variable mapping relationship when the difference between the highest and second highest co-occurrence counts of a variable exceeds a preset threshold; S15, Convergence Judgment and Re-normalization: If the variable mapping table obtained in this round is consistent with that in the previous round, the mapping is determined to have converged, and the iteration ends; otherwise, the statement sequence obtained in step S11 is re-normalized using the new variable mapping table. Re-normalization includes replacing the corresponding variables with unified identifiers, making more originally non-unique MUM fragments unique after replacement, thereby triggering the next round of new mapping discovery, forming a cascading discovery effect, and returning to step S13 for the next round of iteration.

[0032] It should be noted that the binary program before and after the patch are essentially the same code snippets, and the variable mapping between them must be one-to-one. There will be no multiple solutions or circular dependencies in the variable mapping relationship. Therefore, there will be no situation where convergence is not possible.

[0033] S16, Differential Generation: After iterative convergence, a unified pseudocode differential text is generated based on the final function mapping table and variable mapping table to facilitate subsequent security analysis.

[0034] After steps S11 to S16, cleaner and more stable pseudocode difference results can be obtained at the binary level, significantly reducing the impact of variable renaming noise on the difference quality and providing reliable input for subsequent security patch determination.

[0035] In one possible implementation, finding the longest matching segment that appears only once in a sequence of statements can be achieved efficiently using structures such as suffix arrays and Longest Common Prefix (LCP).

[0036] In one possible implementation, the code flow of the iterative variable mapping and difference alignment algorithm is as follows: To reduce erroneous mappings caused by accidental matching, a frequency-based conservative voting mechanism is adopted in step S14: the mapping is only accepted when the highest co-occurrence frequency of a certain variable pair is higher than the second highest frequency by n times, thereby improving the stability of the mapping.

[0037] In this embodiment, as Figure 3 As shown, after obtaining the aligned pseudocode difference text, security relevance of patch changes is determined through large language model proxy analysis. The large language model proxy analysis stage consists of two parts: pre-filtering (initial screening based on patch patterns) and iterative context analysis.

[0038] In this embodiment, step S2 (large language model proxy analysis) includes the following steps: S21, Pre-filtering: Use a large language model to quickly filter the pseudocode differential text, remove non-security-related changes, and retain potential security patches; S22, Iterative Analysis: Perform iterative contextual analysis on potential security patches; S23, Output: Output the determination result of whether a potential security patch is a security patch, and generate a structured patch analysis report containing the determination criteria.

[0039] In this embodiment, before performing deep analysis using a large language model, the pseudocode difference text is first rapidly pre-filtered using the large language model to eliminate obvious insecure modifications as much as possible and retain potential security patches for the next stage. During pre-filtering, the large language model is provided with security patch pattern indication information at the pseudocode level, including but not limited to the information shown in Table 1. This security patch pattern indication information is based on common patterns extracted from empirical analysis of the performance characteristics of a large number of real security patches at the pseudocode level. It covers the structural features of typical security remediation behaviors in pseudocode, such as increased boundary checks, enhanced error handling, and secure API calls. Simultaneously, some "ambiguous patterns" (such as function replacements and parameter changes) are marked as requiring further deep analysis for confirmation, thus enabling the large language model to quickly filter the pseudocode difference text and maintain a high recall rate.

[0040] Table 1 Security Patch Mode Indication Information It should be noted that the security patch pattern indication information described above is exemplary and not exhaustive. Because software vulnerability types and security remediation patterns are constantly evolving, and the same security remediation may present different pseudocode forms under different compiler optimization levels and target architectures, the predefined pattern list cannot cover all possible security patch manifestations. In this embodiment, the purpose of the aforementioned security patch pattern indication information is to provide guidance and prompts for the large language model's focus, thereby improving the screening efficiency of the pre-filtering stage.

[0041] In step S22, potential security patches output from the pre-filtering stage are analyzed using iterative context analysis. Iterative context analysis includes analyzing the agent and the context agent.

[0042] Specifically, the analytics agent is used to perform security impact reasoning based on currently available differential and contextual information, identify information gaps, and generate context requests.

[0043] Specifically, the context proxy is used to respond to context requests, retrieve and return the required context information from the decompiled environment of the pre-patched binary program. The analysis proxy merges the returned context information to update the judgment result and confidence level until the confidence level reaches a preset threshold or the number of iterations reaches a preset upper limit.

[0044] In this embodiment, the confidence level is assessed based on a comprehensive judgment of the following dimensions: (a) Completeness of the chain of evidence: The analysis agent assesses whether the currently acquired contextual information is sufficient to support a security judgment. When the source of key variables has been traced, the behavior of relevant functions has been clarified, and the data flow path has been confirmed, the chain of evidence is considered complete, corresponding to a high level of confidence. When there are still unresolved information gaps (such as unidentifiable indirect call targets or untraceable variable sources), the chain of evidence is considered incomplete, and the confidence level is correspondingly reduced.

[0045] (b) Consistency of evidence: The analysis agent checks whether the evidence from various contextual information obtained in multiple iterations corroborates each other. Confidence increases when contextual information from multiple independent sources (such as call graph relationships, data flow trajectories, and pseudocode of related functions) all point to the same security decision; confidence decreases when evidence from different sources contradicts or points to different conclusions.

[0046] (c) Traceability of the reasoning process: The analysis agent assesses whether the reasoning process from observed code changes in pseudocode differential text to the final security determination is complete and traceable. Each step of reasoning must be supported by corresponding code evidence; high-confidence conclusions based on speculation or assumptions are not permitted.

[0047] In its implementation, the aforementioned confidence assessment rules are constrained by the analysis agent's prompts. It is clearly stipulated that a high confidence score (e.g., greater than 0.80) can only be output when the chain of evidence is complete, the evidence corroborates each other, and the reasoning process is uninterrupted. When there are any gaps in information, conflicts in evidence, or insufficient reasoning basis, the analysis agent must output a lower confidence score to ensure the conservatism and reliability of the final judgment.

[0048] In step S22, to ensure that the returned context information is sufficient without being excessively redundant, the context proxy provides an integrated toolset in the decompilation environment. The integrated toolset includes function-level pseudocode acquisition, call graph analysis (querying caller / callee relationships), and data flow tracing (tracking the source, propagation, and usage of key variables). Combined with a code slicing mechanism, forward and backward slicing is performed within the function boundary starting from the request line to extract compact context fragments related to control / data dependencies, thereby reducing irrelevant code noise.

[0049] Correspondingly, the context proxy retrieves context information through an integration toolset, including at least one of the following: the complete pseudocode of the specified function; caller or callee information obtained through call graph analysis; source, propagation, or usage location information of key variables obtained through data flow tracing; and code slices obtained by performing forward and / or backward slices within the function boundary, starting from the code behavior involved in the request.

[0050] In step S22, when the context agent encounters an uncertain call relationship or data flow while responding to a context request and / or retrieving context information, it explicitly marks the corresponding information gap and records it in the evidence chain.

[0051] In this embodiment, the explicit marking of information gaps directly affects the confidence assessment. For example, when calculating the confidence level, the analysis agent uses the marked information gaps as evidence of an incomplete chain of evidence, thereby automatically reducing the confidence score of the corresponding judgment and avoiding making overly certain security decisions when information is insufficient.

[0052] In step S23, the structured patch analysis report also includes: general vulnerability enumeration CWE type, repair strategy, evidence chain, and confidence score.

[0053] Specifically, after the iterative context analysis is completed, a structured patch classification report (e.g., JSON structure) is generated, outputting a binary classification result of whether a patch is a security patch, and providing key analysis points, including possible CWE types, remediation strategies and traceable evidence chains, root cause analysis, and confidence scores in the range of 0 to 1.0; and a conservative threshold strategy can be adopted, only outputting a security patch when it is determined to be secure and the confidence score is higher than a specified threshold, in order to reduce false positives.

[0054] It should be noted that binary decompilation and program analysis have inherent limitations. For example, indirect calls, dynamic jumps, and pointer aliases may lead to incomplete or inaccurate context retrieval. To address these issues, this solution adopts a conservative approach to ensure the reliability of the analysis results.

[0055] It should be noted that binary decompilation and program analysis have inherent limitations, which propagate along the processing chain of this solution, affecting each stage to varying degrees. The following systematically analyzes the limitations of binary decompilation and program analysis and the mitigation measures adopted by this invention at each stage.

[0056] ① The limitations of decompilation include: Binary programs lose a significant amount of high-level source code information during compilation, including variable names, data types, comments, and debugging information. With symbol stripping, symbolic information such as function names is further lost. Furthermore, program behaviors such as indirect calls (calls made through function pointers or virtual tables), dynamic jumps (jump targets determined at runtime), and pointer aliases (multiple pointers pointing to the same memory location) are difficult to accurately reconstruct in static analysis.

[0057] ②The limitations of the pseudocode difference generation stage and the methods to mitigate them are as follows: During the pseudocode differential generation stage, the limitations of decompilation may lead to structural deviations between the pseudocode generated by the decompiler and the original source code. These deviations could include inaccurate variable type inferences, distortion of complex control structures (such as switch-case statements and exception handling), and merging or splitting of expressions. These structural deviations may manifest inconsistently in the pseudocode of the pre-patch and post-patch binary programs, introducing additional differential noise.

[0058] To mitigate the potential structural discrepancies between the pseudocode generated by the decompiler and the original source code, the following measures were taken in the IMP-Diff algorithm: First, the IMP-Diff algorithm uses a sequence of statements as the matching granularity rather than a single expression, which allows it to tolerate minor structural changes at the expression level. Second, the frequency-based conservative voting mechanism requires that variable mappings be consistently confirmed in multiple independent MUM fragments, and occasional decompilation structure deviations are difficult to pass the voting threshold and thus be effectively filtered out. Third, the cascading discovery mechanism of iterative context analysis means that even if some MUM fragments cannot be matched in the initial stage due to decompilation bias, in subsequent iterations, as the confirmed variable mapping relationships accumulate and normalization processing progresses, the fragments that could not be matched before may still be successfully matched in subsequent rounds, thereby making up for the information loss caused by decompilation bias in the initial stage to a certain extent.

[0059] ③ Impact on the accuracy of variable mapping and mitigation measures: Decompilers may generate pseudocode with significantly different structures for the same source code logic under different compilation optimization levels. This reduces the number of unique matching fragments available in the IMP-Diff algorithm, and variable mapping may be incomplete (i.e., some variables fail to be mapped successfully). Unmapped variables will retain their original names in the pseudocode difference text, constituting residual noise.

[0060] Mitigation measures for residual noise include: For variables that are not successfully mapped, the IMP-Diff algorithm explicitly marks them when generating pseudocode difference text (e.g., marking unmapped variables in the patched binary program as distinctive identifiers). This enables the large language model in the semantic analysis and decision-making stages to recognize these explicit markers and define them as unmapped variables rather than substantial code changes. As a result, subsequent semantic analysis and decision-making have the ability to understand and filter residual noise, and can determine whether this residual noise has a security meaning based on contextual information.

[0061] ④ Impact on the semantic analysis and decision-making stages and mitigation measures: Poor decompilation quality leading to pseudocode structure deviations, incomplete variable mapping resulting in residual noise, and incomplete or inaccurate context information due to indirect calls or pointer aliases during the context retrieval phase can all interfere with the security reasoning of the analysis agent.

[0062] To mitigate potential interference with the security reasoning of the analysis agent, a multi-layered defense mechanism can be established during the semantic analysis and decision-making phases to eliminate this interference, as detailed below: Explicit marking of information gaps: When the context proxy encounters uncertain call relationships or data flows while responding to context requests and retrieving context information (such as indirect call targets that cannot be statically resolved, pointer aliases causing uncertainty in data flow tracing, etc.), it explicitly marks the corresponding information gaps and records them in the evidence chain, rather than making potentially erroneous inferences based on incomplete information; the explicit marking mechanism ensures that subsequent reasoning processes are based only on confirmed evidence.

[0063] Conservative limitations on the slice range: The context proxy's on-demand slicing mechanism strictly limits forward and backward slicing to within function boundaries, avoiding attempts to trace indirect calls or dynamically jump targets across functions. This circumvents the inherent challenges of cross-function static analysis and ensures high reliability of the returned slice context. When cross-function information is truly necessary, direct call relationships are obtained by calling graph analysis tools. Indirect call relationships that cannot be determined are marked as information gaps and handled by the confidence mechanism.

[0064] Confidence constraints on the chain of evidence: After each iteration, the analysis agent updates the confidence score based on the completeness of the evidence chain, the consistency of various pieces of evidence, and the traceability of the reasoning chain. Poor pseudocode quality, incomplete variable mapping, or missing contextual information can all lead to an incomplete or ambiguous evidence chain, resulting in a lower confidence score. Furthermore, a conservative threshold strategy is employed, ensuring that only when a security patch is identified and the confidence score exceeds a specified threshold is it output as the final security patch. This effectively controls the impact of decompilation errors, incomplete mapping, or missing context on the final decision within an acceptable range.

[0065] In summary, the synergistic effect of the above mitigation measures enables the binary security patch detection method of the present invention to output reliable analysis results with clear confidence levels even when faced with limited decompilation quality.

[0066] Regarding the handling of incomplete or inaccurate context retrieval, when the context agent encounters an uncertain data stream or call relationship, the analysis agent explicitly marks it as an "information gap" and records it in the chain of evidence, rather than making potentially erroneous inferences based on incomplete information. This explicit marking mechanism ensures that subsequent reasoning is based solely on confirmed evidence.

[0067] Regarding the final decision constraint, the analysis agent updates the confidence score after each iteration based on the completeness and consistency of the evidence chain, as well as the traceability of the reasoning process. Specifically, the confidence score reflects the completeness of the evidence chain upon which the current analysis conclusion is based, the degree of mutual corroboration between various pieces of evidence, and the completeness of the reasoning chain from code change to security determination. When contextual information is missing or ambiguous, the confidence score will remain at a low level. Only when it is determined to be a security patch and the confidence score is higher than a specified threshold (preset according to actual needs, such as 0.80) is it output as the final security patch, thereby effectively reducing the risk of misjudgment due to decompilation errors or incomplete context.

[0068] In this embodiment, to ensure that security patch determination is not limited to the differential fragment itself, a context proxy is used to retrieve and return the minimum necessary context as needed after the analysis agent identifies an information gap, thereby supporting iterative reasoning and evidence chain construction. The responsibilities of the context proxy include: converting the analysis agent's context requests into executable tool calls and executing the calls to collect the required context information.

[0069] Specifically, the context proxy's workflow includes context request parsing and parameterization, IDA integration toolset invocation, code slicing to generate compact contexts, and context return and traceability.

[0070] In this embodiment, context request parsing and parameterization specifically include: After reading the difference, the analysis agent identifies key gaps (such as unknown variable origins, unknown function behavior, unclear data flow, etc.) and generates a precise request (e.g., "Where does variable v6 come from?"). The context agent receives this request and parses it into specific retrieval targets and parameters (e.g., variable name, function name, target line number, tracing direction, etc.).

[0071] In this embodiment, the context proxy completes context acquisition based on the integrated toolset of IDA Pro (Interactive Disassembler Professional), including at least: ① Function retrieval: Extracts the complete function-level pseudocode of a specified subroutine, providing a complete implementation context for the analysis agent.

[0072] ② Call graph analysis: Traverses the call hierarchy, identifies the caller and callee of the target function, and provides cross-process call relationships and call patterns.

[0073] ③ Data flow tracking: Tracks the sources, propagation, transformations, and sinks of key variables in the program to clarify the origin and scope of influence of variable values.

[0074] In this embodiment, to avoid returning entire function blocks or large amounts of irrelevant code to the analysis agent, on-demand code slicing is used to generate compact contexts. The on-demand code slicing mechanism specifically includes: Starting with the code line containing the variables or functions involved in the context request, forward and backward slicing are performed simultaneously within the function boundary. This extracts data dependency or control dependency code segments related to the request, forming a compact yet informative slice context. This reduces irrelevant noise while meeting analysis needs. Furthermore, the on-demand slicing mechanism strictly limits forward and backward slicing to within function boundaries, avoiding attempts to trace indirect calls or dynamically jump targets across functions. This circumvents the inherent challenges of cross-function analysis and ensures the high reliability of the returned slice context.

[0075] In this embodiment, context return and traceability specifically include: The context agent returns the results of the aforementioned tool calls (function pseudocode, call relationships, data flow traces, and slice context) to the analysis agent to complete the evidence chain and update the security judgment. Furthermore, the process of returning results to the analysis agent aims for "minimum necessary information," returning only the content needed to directly answer the requested question, thereby improving iteration efficiency and reducing the risk of misjudgment.

[0076] Example 2 This embodiment, based on Embodiment 1, provides a specific example of an iterative variable mapping and difference alignment algorithm.

[0077] In this embodiment, as Figure 4 As shown, to facilitate understanding of the working process of iterative variable mapping and difference alignment algorithms, a specific example is used below.

[0078] exist Figure 4 In the diagram, orange blocks represent MUM segments that satisfy the uniqueness constraint and are successfully matched, gray blocks represent segments that do not satisfy the uniqueness constraint due to multiple occurrences, and blue blocks represent parts where variable substitution has been completed. Figure 4 The process is divided into four stages, each corresponding to... Figure 4 Middle (1) ~ (4).

[0079] In this embodiment, it is assumed that the binary program code before patching uses variables v1-v9 and the function name func1, and the binary program code after patching uses variables a1-a9 and the function name func2. The two sets of code are semantically identical but have different names. The iterative process of the algorithm is as follows:

[0080] Phase (1) is the initial state. At this time, due to the differences in variable names and function names between the two sides, direct difference will generate a lot of irrelevant noise.

[0081] Phase (2) is the state after initial normalization. The iterative variable mapping and difference alignment algorithm first uses the function mapping table to unify the known function names on both sides (func2 is normalized to func1), and replaces all variables with placeholders x for MUM lookup. At this time, the orange blocks in the figure represent code segments that satisfy the uniqueness constraint (appearing only once on each side), and can be successfully matched with MUM, thus discovering the initial variable mapping relationship v1→a1 and v2→a2. The gray blocks represent code segments containing common patterns (such as "x=x+1", "x=x*2"), which do not satisfy the uniqueness constraint because they appear multiple times on each side, and cannot be matched temporarily.

[0082] Phase (3) represents the state after the first round of mapping. The iterative variable mapping and difference alignment algorithm applies the discovered variable mappings (v1→a1, v2→a2) to the statement sequences on both sides for further normalization. At this point, code segments that were previously indistinguishable due to the use of placeholder x become uniquely identifiable after being replaced with the specific variable name v2. In the figure, the blue blocks represent the parts where variable replacement has been completed, and the orange blocks expand accordingly, triggering new MUM matching and thus discovering more variable mapping relationships.

[0083] Stage (4) is the final state after convergence. After several rounds of iteration, all variable mapping relationships are discovered, and the code on both sides is fully aligned. At this point, the iterative variable mapping and difference alignment algorithm terminates the iteration and outputs a unified pseudocode difference text.

[0084] pass Figure 4 The cascading discovery mechanism formed in the middle stages (1) to (4) allows the IMP-Diff algorithm to gradually eliminate the difference noise introduced by variable renaming and finally generate clean and stable aligned difference results.

[0085] Example 3 This embodiment provides an electronic device based on any of the above embodiments.

[0086] In this embodiment, the electronic device includes a processor and a memory communicatively connected to the processor; wherein, the memory stores computer programs / instructions executable by the processor, and when the computer programs / instructions are executed by the processor, the binary security patch detection method described above is implemented.

[0087] Example 4 This embodiment provides a computer-readable storage medium based on any of the above embodiments.

[0088] In this embodiment, a computer program / instruction is stored on a computer-readable storage medium, and when the computer program / instruction is executed by a processor, it implements the binary security patch detection method described above.

[0089] Example 5 This embodiment provides a binary security patch detection system based on any of the above embodiments.

[0090] In this embodiment, the binary security patch detection system includes: The pseudocode difference generation module is used to perform step S1 to generate aligned pseudocode difference text; The large language model proxy analysis module is used to execute step S2 to analyze the pseudocode differential text and output the security patch determination result.

[0091] Optionally, the pseudocode difference generation module is integrated into the decompilation environment, and the context agent in the large language model agent analysis module communicates with the decompilation environment to retrieve context information from it.

[0092] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A binary security patch detection method, characterized in that, Includes the following steps: S1, Pseudocode Differential Generation: Obtain the binary program before patching and the binary program after patching, locate the set of patch-related functions through function-level matching, generate pseudocode for the functions in the set of patch-related functions, and discover and eliminate the noise of variable naming differences introduced by compilation or decompilation in the pseudocode through variable correspondence, and generate aligned pseudocode differential text; The pseudocode is then processed using an iterative variable mapping and difference alignment algorithm to generate aligned pseudocode difference text. S2, Semantic Analysis and Judgment: Based on the large language model, and combined with the context information obtained as needed from the pre-patch binary program and / or the post-patch binary program, the pseudocode differential text is subjected to security patch judgment analysis.

2. The binary security patch detection method as described in claim 1, characterized in that, In step S1, an iterative variable mapping and differential alignment algorithm is used to discover and eliminate variable naming difference noise in the pseudocode.

3. The binary security patch detection method as described in claim 2, characterized in that, In step S1, the function-level matching includes: The pre-patch binary program and the post-patch binary program are respectively loaded into the decompilation environment to generate an analysis database; The functions of the pre-patch binary program and the post-patch binary program are compared using a function-level comparison plugin, and a function mapping table is exported. The function mapping table records the best matching functions that are completely identical, the partially matching functions that have different contents, and the unmatched functions that exist only in either the pre-patch binary program or the post-patch binary program. The partially matched functions and the unmatched functions are used as the set of patch-related functions.

4. The binary security patch detection method as described in claim 2, characterized in that, The iterative variable mapping and difference alignment algorithm includes the following iterative steps: S11, Statement sequence extraction: Extract statement sequences from the pseudocode generated by the functions of the binary program before patching and the functions of the binary program after patching, respectively. S12, Initial normalization: Using the function mapping table, the known corresponding function names in the functions of the binary program before patching and the functions of the binary program after patching are uniformly normalized. S13, MUM finds: In the normalized sequence of statements, find the longest matching segment that appears only once in the sequence of statements in the functions of the binary program before patching and the functions of the binary program after patching, i.e., the maximum unique match MUM; S14, Variable mapping extraction: Statistical analysis of variable co-occurrence relationships is performed from the MUM fragments obtained in step S13 to generate a candidate variable mapping table; a frequency-based voting mechanism is adopted, and variable mapping relationships in the candidate variable mapping table are only accepted when the difference between the highest and second highest co-occurrence counts of a variable exceeds a preset threshold; S15, Convergence Judgment and Re-normalization: If the variable mapping table obtained in this round is consistent with that in the previous round, then the mapping is determined to have converged, and the iteration ends; Otherwise, the statement sequence obtained in step S11 is normalized again using the new variable mapping table, the corresponding variables are replaced with unified identifiers, and the process returns to step S13 for the next iteration. S16, Differential Generation: After iterative convergence, a unified pseudocode differential text is generated based on the final function mapping table and variable mapping table.

5. The binary security patch detection method as described in claim 4, characterized in that, In step S14, the preset threshold for the difference between the highest co-occurrence frequency and the second highest co-occurrence frequency is determined using a frequency-based conservative voting mechanism.

6. The binary security patch detection method as described in claim 1, characterized in that, Step S2 includes the following steps: S21, Pre-filtering: Use a large language model to quickly filter the pseudocode differential text, remove non-security-related changes, and retain potential security patches; S22, Iterative analysis: Perform iterative context analysis on the potential security patch to obtain a determination result; S23, Output the result: Output the determination result of whether the potential security patch is a security patch, and generate a structured patch analysis report containing the determination criteria.

7. The binary security patch detection method as described in claim 6, characterized in that, In step S22, the iterative context analysis includes performing the following operations through the analysis agent and the context agent: The analysis agent performs security impact reasoning based on currently available differential and contextual information, identifies information gaps, and generates context requests. The context agent responds to the context request by retrieving and returning the required context information from the decompiled environment of the pre-patch binary program; The analysis agent returns context information to update the judgment result and confidence level until the confidence level reaches a preset threshold or the number of iterations reaches a preset upper limit.

8. The binary security patch detection method as described in claim 7, characterized in that, In step S22, the context information retrieved by the context agent includes at least one of the following: The complete pseudocode of the specified function; Information about the caller or callee obtained through call graph analysis; Information on the source, propagation, or usage location of key variables obtained through data stream tracing; Code slices are obtained by performing forward and / or backward slices within function boundaries, starting from the code behavior involved in the request.

9. The binary security patch detection method as described in claim 7, characterized in that, In step S22, when the context agent encounters an uncertain call relationship or data flow while responding to the context request and / or retrieving the context information, it explicitly marks the corresponding information gap and records it in the evidence chain.

10. The binary security patch detection method as described in claim 6, characterized in that, In step S23, the structured patch analysis report also includes: general vulnerability enumeration CWE type, repair strategy, evidence chain, and confidence score.

11. An electronic device, characterized in that, The system includes a processor and a memory connected in communication with the processor; wherein the memory stores a computer program / instruction executable by the processor, and when the computer program / instruction is executed by the processor, it implements the binary security patch detection method as described in any one of claims 1 to 10.

12. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instruction is executed by the processor, it implements the binary security patch detection method as described in any one of claims 1 to 10.

13. A binary security patch detection system, characterized in that, include: The pseudocode difference generation module is used to perform step S1 as described in claim 1 to generate aligned pseudocode difference text; The large language model proxy analysis module is used to perform step S2 as described in claim 1, so as to analyze the pseudocode differential text and output the security patch determination result.

14. The binary security patch detection system as described in claim 13, characterized in that, The pseudocode differential generation module is integrated into the decompilation environment, and the context agent in the large language model proxy analysis module is connected to the decompilation environment to retrieve context information from it.

Images