An application security patch detection method and system based on differential semantic analysis

Abstract

The application belongs to the technical field of software security patch, and particularly relates to an application security patch detection method and system based on differential semantic analysis, which comprises the following steps: a matching strategy combining name priority and hash similarity is used to accurately identify method differences between versions; based on call graphs and data dependency relationships, scattered associated modifications are aggregated into differential units; the differential units are subjected to structured code slicing to extract core changes and associated context across methods; the structured slices are input into a large language model for security patch reasoning, and a two-dimensional verification mechanism of logic verification and attack condition satisfaction reasoning is introduced to make confidence decisions on the detection results and output a detection report with high confidence. The application effectively improves the accuracy and reliability of Android closed-source application security patch detection, and solves the problems of method mismatching, context loss and insufficient semantic understanding in the prior art.

Description

Technical Field

[0001] This invention relates to the field of software security patching technology, and in particular to an application security patch detection method and system based on differential semantic analysis. Background Technology

[0002] The existing technologies still have the following shortcomings when applied to the detection of security patches for Android applications: (1) Most existing technologies are difficult to directly adapt to the differential analysis requirements of closed-source Android applications. Existing detection methods for open-source applications often directly use Git commit records as input. However, for Android applications, it is necessary to perform cross-version decompilation and differential analysis on APK files to identify code modifications. Moreover, existing matching methods rely too much on feature similarity, which can easily lead to mismatches due to short feature similarity methods. (2) There is a lack of joint analysis of related modifications and a serious lack of context extraction. Existing technologies usually start from a single code modification for isolated detection and fail to combine multiple semantically related modifications for comprehensive judgment, resulting in a lack of sufficient context information during analysis and a high risk of false negatives. (3) Traditional methods have weak deep semantic understanding capabilities and fail to leverage the advantages of large models. Existing methods mostly rely on manual extraction of shallow features or traditional machine learning classification, which limits the understanding of the deep semantics of code changes and the intent to repair. Summary of the Invention

[0003] This invention proposes an application security patch detection method and system based on differential semantic analysis, aiming to solve the technical problem in the existing technology that differential analysis methods rely too much on feature similarity matching, which leads to mismatches in short methods with similar features.

[0004] In a first aspect, the present invention provides an application security patch detection method based on differential semantic analysis, comprising: The first version of the Android application installation package and the second version of the Android application installation package are decompiled, and the method-level difference results between the first version and the second version are identified based on a strategy that combines method name priority matching and feature hash similarity matching. The method-level difference results include update methods, addition methods and deletion methods. Each change method in the method differential result is abstracted as a graph node. The edge weights are calculated based on the call graph association score and data association score between the graph nodes. The graph nodes are then clustered using a hierarchical clustering algorithm with size constraints. The update method, addition method and deletion method with logical association are aggregated into one or more differential units. For each differential unit, a core change slice and an associated slice are extracted, and the extracted slices are deduplicated and assembled to obtain a structured code slice; wherein, the core change slice includes the modification line and the adjacent context of the control flow and data flow, and the associated slice includes slices based on the call chain and slices based on shared field read and write; The structured code slices and differential unit metadata are input into a large language model, which drives the large language model to output candidate security patch units. The candidate security patch units are then subjected to two-dimensional verification: logical verification and attack condition satisfaction reasoning. Based on the comprehensive result of the two-dimensional verification, the final confidence level is determined, and a security patch identification report is output.

[0005] Furthermore, the method-level difference result identification step in the version difference step specifically includes: When matching methods within a matched class, determine whether the method name has been obfuscated. When the method name is determined to be unconfused, matching is prioritized based on the method name, and feature similarity is further calculated only when method overloading occurs. When it is determined that the method is confused, the feature similarity of all unmatched methods between the first version and the second version is calculated, and the matching is performed in descending order of similarity.

[0006] Furthermore, the graph nodes include: a U node representing the update method, an A node representing the addition method, and a D node representing the deletion method; wherein, the valid version set of the U node includes the first version and the second version, the valid version set of the A node includes only the second version, and the valid version set of the D node includes only the first version; The call graph association score is based on the shortest path distance of a node in the public version of the call graph, and is calculated by distance decay. The data association score is calculated based on the size of the intersection of the read and write operations of nodes on shared fields; The edge weight is the weighted sum of the call graph association score and the data association score.

[0007] Furthermore, the hierarchical clustering algorithm with size constraints includes: Each of the graph nodes is initialized as an independent cluster; Add all edges whose weights exceed a preset edge weight threshold to a priority queue in descending order of weight; Edges are popped from the priority queue in sequence, and it is determined whether the sum of the number of nodes in the two clusters connected by the edge is less than or equal to a preset cluster size threshold. If so, the two clusters are merged. Repeat the steps of popping edges from the priority queue and performing merging judgment until the priority queue is empty.

[0008] Furthermore, the extraction of the core change slice specifically includes: For the update method, extract the difference modification line and the preset lines of code before and after it as the modification line slice; when the modification line is located in the control flow statement block, extract the control flow condition statement of the current level upwards; and extract the definition-usage chain of the variables involved in the modification line for one-step backtracking. For the newly added or deleted method, if the number of lines in the method body is less than a preset line count threshold, the complete method body is retained; if the number of lines in the method body exceeds the preset line count threshold, the field read / write operation lines, external method call lines, control flow condition statements, and method parameter usage statements are retained.

[0009] Furthermore, the extraction of associated slices specifically includes: Call graph association slicing: For method pairs with call associations within the differential unit, extract the relevant call code lines and their pre- and post-preset line contexts within each method on one or more shortest call paths; Data association slicing: Calculate the set of common fields within the difference unit, and extract the lines of code that perform read or write operations on each field in the set of common fields and their pre-set line contexts before and after them from all methods within the difference unit.

[0010] Furthermore, the logical verification includes: Exact match verification: Verify whether the risk evidence code string and the repair evidence code string in the candidate security patch unit exist exactly in the corresponding version of the code; Semantic self-consistency verification: The large language model is used to check the semantic consistency between risk description and risk evidence, as well as the semantic consistency between repair description and repair evidence; the semantic consistency includes: integrity verification, semantic matching verification and logical chain closure verification.

[0011] Furthermore, the attack condition satisfaction reasoning includes: Based on the risk descriptions and risk evidence in the candidate security patch units, extract the key conditions that enable the vulnerability to be successfully exploited. The code slice of the first version is analyzed using the large language model to determine whether the key conditions are met. The code slice of the second version is analyzed using the large language model to determine whether the key condition is no longer satisfied. The attack condition satisfaction reasoning is verified only if the first version explicitly satisfies the key condition and the second version explicitly does not satisfy the key condition.

[0012] Furthermore, the determination of the final confidence level based on the comprehensive results of the two-dimensional verification is specifically as follows: When both the logical verification and the attack condition satisfaction reasoning pass, the final confidence level of the decision is high confidence. When exactly one of the logical verification and the attack condition satisfaction reasoning passes, the final confidence level of the decision is medium confidence. When both the logical verification and the attack condition satisfaction reasoning fail, the final confidence level of the ruling is low confidence.

[0013] Secondly, the present invention provides an application security patch detection system based on differential semantic analysis, the system being used to execute the method, comprising: Version Differentiation Module: Used to decompile the first version Android application installation package and the second version Android application installation package, and identify the method-level difference results based on the method name priority matching and hash similarity matching strategy; Differential Unit Aggregation Module: This module abstracts the difference method into graph nodes, calculates edge weights based on the call graph and data dependencies, and uses a hierarchical clustering algorithm with size constraints to aggregate logically related modifications into differential units. Code slicing module: used to extract core change slices and associated slices from the differential unit, and perform deduplication and assembly to generate structured code slices; Large Model Inference Module: Used to input structured code slices into a large language model to obtain candidate security patch units; Two-dimensional verification module: used to perform logical verification and attack condition satisfaction reasoning on the candidate security patch unit; Confidence assessment and output module: used to determine the final confidence level based on the comprehensive results of the two-dimensional verification, and output a security patch identification report.

[0014] The technical effects of this invention are: First, by combining name priority with similarity in the matching strategy, the accuracy of differential analysis for closed-source applications is effectively improved, and mismatches caused by short-short-spot similarity methods are avoided.

[0015] Second, by using differential unit aggregation and cross-method dependency slicing, a complete logical context for security remediation is provided, avoiding false negatives caused by isolated analysis.

[0016] Third, by leveraging the deep semantic understanding capabilities of large language models and a rigorous two-dimensional verification mechanism, the accuracy and reliability of security patch identification have been significantly improved, effectively reducing false positives and false negatives.

[0017] Fourth, the structured slicing scheme effectively controls the context length of the input large model, avoiding the problem of model performance degradation; the two-dimensional verification mechanism effectively suppresses the negative impact of model illusion on the detection results. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an application security patch detection method based on differential semantic analysis proposed in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] This invention aims to address the following shortcomings in existing Android application security patch detection technologies: First, existing differential analysis methods rely excessively on feature similarity matching, leading to false matches easily occurring with short methods featuring similar features; Second, the lack of a mechanism for joint analysis of scattered modifications with logical connections results in insufficient extraction of contextual information, easily causing false negatives; Third, traditional methods rely on manual feature extraction or shallow machine learning, lacking deep semantic understanding of code changes and making it difficult to accurately identify complex security patches.

[0021] This invention provides a method for detecting application security patches based on differential semantic analysis. Taking a pair of Android application installation packages (APKs) to be detected as an example, the older version APK (i.e., the first version APK) and the newer version APK (i.e., the second version APK) are different release versions of the same application. This embodiment aims to automatically identify whether the newer version APK contains patches to fix security vulnerabilities. (Reference) Figure 1 As shown, the specific steps include: Step S1, version differential phase, includes: (1) Input the old version APK and the new version APK into a decompilation tool (e.g., using the Soot code analysis framework) to decompile them into an intermediate representation of Java bytecode. In this embodiment, the Jimple intermediate representation in the Soot framework is preferred. Jimple is an intermediate representation based on three-address code, which can simplify the analysis and optimization of Java bytecode. After decompilation, extract the instruction sequence of each method. For each method, use the SSDEEP fuzzy hash algorithm to calculate its feature hash value. SSDEEP is a context-triggered segmented hash algorithm that can identify partial similarity between files. Two similar methods will produce similar hash values. At the same time, for each class, concatenate the method descriptors and class field information in the class, and also use the SSDEEP algorithm to calculate the feature hash value of the class.

[0022] (2) Class matching: Prioritize matching classes with completely identical feature hashes as anchor classes. For the remaining unmatched classes, match them within a limited range based on feature similarity. Specifically, calculate the SSDEEP hash similarity between unmatched classes, and establish matching relationships between class pairs with similarity exceeding a preset threshold.

[0023] (3) Method matching (a combination of name priority and similarity strategy). Method matching is performed within the matched classes. This embodiment adopts the following strategy: First, it is determined whether the method name has been obfuscated. The judgment rule is: calculate the length of the method name and the hit rate of short words in the method name. For example, if the length of the method name is less than a preset threshold (such as 5 characters) and it is not in the preset short word whitelist, it is determined to be obfuscated; otherwise, it is determined to be unobfuscated.

[0024] Unobfuscated method matching: When the method name is determined to be unobfuscated, matching is prioritized based on the method name. Specifically, methods with the same name are searched for matching pairs within the same category. When method overloading occurs (i.e., methods with the same name but different parameters), feature similarity is further calculated for the overloaded methods, and the pair with the highest similarity is matched.

[0025] Obfuscated method matching: When a method name is determined to be obfuscated, calculate the SSDEEP feature similarity between all unmatched methods in the old version and all unmatched methods in the current version, sort all method pairs in descending order of similarity, establish matching relationships sequentially, and skip methods that have already been matched.

[0026] Through the above matching strategy, this embodiment finally outputs method-level difference results, including four types: unchanged method, updated method (U node, which exists in both the old and new versions, but the code content has changed), added method (A node, which only exists in the new version), and deleted method (D node, which only exists in the old version).

[0027] The technical benefits of this step are: by combining name priority with similarity in the matching strategy, the problem of mismatches caused by short-sighted methods with similar features in traditional pure similarity matching methods is effectively avoided, and the accuracy of difference analysis is significantly improved.

[0028] Step S2, Differential Unit Aggregation Stage: This stage aims to organize the scattered code changes into logically related analysis units. In this embodiment, the update (U), add (A), and delete (D) methods in the differential results are aggregated into differential units.

[0029] 1. Node definition: Abstract each difference method into a graph node. Define three types of nodes based on version attributes and assign them a valid version set: U node (update method): The set of valid versions V(U) = {Old, New} indicates that the node exists in both the old and new versions.

[0030] Node A (New Method): The set of valid versions V(A) = {New}, indicating that this node only exists in the new version.

[0031] Node D (deletion method): The set of valid versions V(D) = {Old} indicates that the node only exists in the old version.

[0032] For any two nodes and Its public computing version is =V( )∩V( ).like If the set is empty (e.g., between node A and node D), then there is no association between the two nodes, and the edge weight is directly set to 0.

[0033] 2. Edge weight calculation, nodes and correlation score between Score associated with the call graph Data-related scores Weighted composition. The calculation formula is: .

[0034] (1) Call graph association score The calculation.

[0035] For each public version v∈ Obtain the call graph for this version. The call graph is constructed based on the CHA (ClassHierarchy Analysis) or RTA (RapidType Analysis) algorithm. Compute nodes arrive The shortest path distance d in the call graph (d is infinite if the paths are disconnected). In this embodiment, the call distance threshold Dmax is set to 3 (the recommended range is 2-3). This value can cover direct calls (distance 1) and most indirect calls (distance 2 or 3), while avoiding connecting too many unrelated methods.

[0036] The formula for calculating the graph association score is as follows: If 1 <d≤Dmax: ,in Based on the correlation score, This is the attenuation factor. In this embodiment... Take 1.0, Let's take 0.5. When d=2, =0.5; when d=3, =0.25.

[0037] If d > Dmax or there is no path: =0.

[0038] If the same node has multiple call distances in the public version, the maximum relevance is taken as the distance. .

[0039] (2) Data association score The calculation.

[0040] In the public version v∈ In the code, extract the usage relationship between nodes and class / object fields. Let Write( ) is a node The set of fields to be assigned values, Read( ) is a node The set of fields read internally, the shared set of fields F=(Write( )∩Read( ))∪(Write( )∩Read( If |F|>0 (where |F| represents the number of elements in the shared field set), then =β×|F|, where β is the basic score for data association. In this embodiment, β is taken as 0.5 (the recommended range is 0.3-0.7). This value is based on the following considerations: the method association provided by the shared field should be lower than that of direct calls, and comparable to that of indirect calls (distance 2). The maximum value in the public version is taken as... .

[0041] (3) Edge weight threshold and edge construction.

[0042] This embodiment sets an edge weight threshold. The default value is 0.5 (recommended range is 0.3-0.7). Only when... > At that time, arrive Edges are established between clusters. If the edge weight threshold is too low, a large number of noisy edges will be introduced, causing the cluster size to frequently reach the threshold during the clustering process; if the edge weight threshold is too high, weak but real associations will be severed, leading to over-splitting.

[0043] 3. Hierarchical clustering algorithm with size constraints.

[0044] To avoid generating excessively large clusters (exceeding the context window limit of a large model) using traditional clustering algorithms, this embodiment employs a hierarchical aggregation algorithm with size constraints. The specific steps are as follows: Step 1: Initialization. Initialize each Diff node as an independent cluster with a cluster size Size(C) = 1.

[0045] Step 2: Construct a priority queue for candidate edges. (This step involves selecting all full queues.) > Edges are added to the priority queue in descending order of their weights.

[0046] Step 3: Constrained Greedy Aggregation. Pop edges sequentially from the priority queue. , ),turn up Cluster and Cluster .like and If they are in the same cluster, skip; if Size( )+Size( If the size of the cluster is less than or equal to the threshold, the two clusters are merged, and the size of the new cluster is the sum of the two sizes; if the size exceeds the threshold, the merging is abandoned.

[0047] Cluster size threshold: In this embodiment, the value is 10 (recommended range 8-15). This value is mainly estimated based on the performance of large models at different context lengths. According to research published at ACL 2025, the performance of large models will significantly decrease when the input code length exceeds 32K tokens. Considering the token consumption caused by prompt word templates and tool calls, the token consumption for cluster analysis of size 10 is generally about 16K, which is within a safe range. For different large models, this value can be further verified experimentally: select 20-50 samples labeled with security patching methods, adjust the Threshold value while keeping other parameters fixed, conduct multiple rounds of experiments, calculate the F1 score by comparing the output results of the security patch detection module with the labeled results, and select the value with the higher F1 score.

[0048] Stopping condition: The priority queue is empty (i.e., all candidate edges have been attempted to be merged). Since the total number of edges in the priority queue does not exceed the square of the number of nodes, the algorithm guarantees termination in a finite number of steps. Unmerged isolated nodes are retained as independent clusters because their association with all clusters is relatively low.

[0049] By employing a hierarchical clustering algorithm with size constraints, logically related, scattered modifications are aggregated into unified differential units. This allows subsequent analysis to obtain a complete security repair logic context, fundamentally overcoming the shortcomings of isolated analysis. Simultaneously, the cluster size constraint effectively controls the context length of large input models, preventing model performance degradation.

[0050] Step S3, the differential unit code slicing stage, involves performing structured code slicing on each differential unit to address the limitations of the large model context window and the need for security patch analysis. The slicing is divided into two main parts: core change slices and related slices.

[0051] 1. Core Change Slices: Core change slices directly display the Diff content and its immediate context, processed separately according to method type: (1) Update the slice of the method and modify the row slice: extract all rows containing modification markers (+ / -) in the difference analysis (Diff) and their context m rows before and after them. In this embodiment, m is 3.

[0052] Control flow enhancement slicing: If the modified line is located within a control block such as if, while, or try-catch, the control flow conditional statement at the current level is extracted upwards. For example, if the modified line is located within the code block of an if statement, the conditional statement line of that if statement is extracted.

[0053] Enhanced data flow slicing: Extracting the definition of variables involved in the modified line - using chaining, performing a one-step backtracking of the variable within the current method, that is, finding the last assignment position or parameter input position of the variable, and extracting the corresponding line of code.

[0054] (2) When adding / deleting slices of methods, if the number of lines in the method body is less than the threshold (30 lines in this embodiment), the complete method body is retained. If the number of lines in the method body exceeds the threshold (i.e., a long method), the following content is selectively retained: all field read / write operation lines, external method call lines, control flow conditional statements (such as if, switch, and loop conditions), and method parameter usage statements. This selective retention can focus on key logic while avoiding the introduction of too much irrelevant code in long methods.

[0055] 2. Associated slices: Based on method associations within the difference unit, extract cross-method call chains and data dependency slices: (1) Call graph association slicing: For method pairs with call associations within a cluster (i.e., the distance on the call graph is less than the Dmax threshold), slice along their shortest call path. For example, if the call path is Mi→Mmid→Mj, extract the code line in Mi that calls Mmid, the code line in Mmid that calls Mj, and the context lines before and after it (n is 2 in this embodiment). When there are multiple shortest call paths between method pairs (Mi, Mj) (i.e., the path length is the same and all are minimum values), slice all call points on the shortest paths, because different paths may reflect different call contexts. If duplicate segments appear, they are merged and deduplicated in the subsequent slice assembly stage.

[0056] (2) Data association slicing: Calculate the common field set Fshared = Wcluster ∩ Rcluster within the cluster, where Wcluster is the set of fields in any method within the cluster where write operations occur, and Rcluster is the set of fields in any method within the cluster where read operations occur. For each field in Fshared, extract the lines of code for read or write operations on that field from all methods within the cluster, along with the n lines of context before and after them, and attach field read / write comments (e.g., " / / [Shared field] Field X is written here").

[0057] 3. Slice Assembly and Deduplication: To avoid context redundancy, this embodiment employs a unified addressing deduplication mechanism: using (fully qualified method name, line number) as the unique identifier. If the same line is matched by multiple slicing rules, the core change slice marker is retained first, and data association comments are added. This stage outputs the assembled and deduplicated structured code slices, which serve as the model input for subsequent security patch determination.

[0058] By using a structured code slicing approach, core changes and their immediate contexts are preserved, while cross-method association information is supplemented. At the same time, the input length is effectively controlled, avoiding the problem of attention dispersion in large models.

[0059] Step S4, the semantic analysis and security patch determination stage based on the large model, takes differential unit metadata and structured code slices as input, and uses the large language model (LLM) to detect, verify and determine the confidence level of security patches.

[0060] 1. The security patch detection module inputs structured code slices and differential unit metadata into the LLM (Local Level Management Model). Driven by a preset prompt word template, the model acts as a security expert, performing semantic analysis on changes. In this embodiment, the prompt word template includes the following core content: Role and task: The model is required to act as an Android security analysis expert to determine whether the differential cell contains a security patch.

[0061] Input description: Describe the structure of the differential unit metadata (method list, method signature, version information) and structured code slices.

[0062] Analysis Dimension: The model is required to identify security vulnerabilities in older versions and determine whether the remediation measures in newer versions specifically address these vulnerabilities.

[0063] Tool Invocation Instructions: Inform the model that it can obtain supplementary context by calling the tool's interface, including categories such as code completion, call chain analysis, data flow analysis, and control flow analysis.

[0064] Output Format: The candidate security patch unit list must be output in strict JSON format. The model can call external code analysis tools via the MCP (ModelContextProtocol). MCP is a standardized interface style that provides large language models with the ability to call external tools. For models that support tool calls, the prompt includes instructions on tool usage and injects information such as the specific functions provided by the tool and their calling formats into the model context or system prompt. If the model returns a tool call request, the inference process will not end immediately. Instead, the system will call the specified tool and append the returned result to the inference context, continuing inference until the model returns an end-of-analysis flag and the analysis result. There is a maximum of k tool calls per analysis (k is 5 in this example). If the maximum is exceeded, a prompt will be returned indicating that tool calls are refused, requiring the model to generate results based on the existing information.

[0065] This embodiment provides the following types of tools: (1) Code viewing tools: By connecting to decompilation tools (such as Jadx), the tool supports searching the model by fully qualified method name or class name and returning the corresponding source code representation. Specific functions include: viewing the complete code of a specified method in the old or new version; obtaining the field definitions and complete method list of a specified class.

[0066] (2) Data flow analysis tools: Based on the static program analysis framework, these tools provide the model with the ability to query data dependencies of variables and fields. Specific functions include: tracing the definition-usage chain of a variable within a specified method and tracing its data source (such as parameter input or the last assignment position); querying the read and write positions of a specified field in related methods and the corresponding code snippets; and performing simplified taint analysis.

[0067] (3) Call graph analysis tools: Cross-version call graphs constructed based on CHA or RTA algorithms provide the model with the ability to query the call relationships between methods. Specific functions include: querying the list of direct callers and callees of a specified method; querying the shortest call path between two methods in the call graph and the intermediate nodes on the path; obtaining the call hierarchy and entry point analysis of a specified method.

[0068] This module outputs zero to multiple candidate security patch units (CandidatePatch), each unit output in strict JSON format, containing the following fields: methods: A list of methods involved in this patch (taken from the U / A / D methods in the differential cell). risk_desc: Description of vulnerability risk (including type, triggering conditions, and impact); fix_desc: Description of the repair measures (including principles and methods); risk_evidence: Contains a list of code snippets and descriptions that contain vulnerabilities in older versions; fix_evidence: A list containing code snippets and descriptions of fixes in the new version.

[0069] 2. Verification Module: The verification module performs two-dimensional verification on candidate security patch units, including a logical verification submodule and a conditional verification submodule.

[0070] (1) Logic verification submodule, which includes the following two parts: Exact match verification: Verify, using a code search tool, whether the code strings in `risk_evidence` and `fix_evidence` exist exactly in the corresponding version of the method. If the code string of either piece of evidence cannot be found to have an exact match in the code at the specified location, the exact match verification fails.

[0071] Semantic self-consistency verification: Input the slice and CandidatePatch into the LLM and check whether risk_desc is semantically consistent with risk_evidence, and whether fix_desc is semantically consistent with fix_evidence. In this embodiment, the prompt word template for semantic self-consistency verification requires the model to verify from the following three aspects: Completeness verification: dissect the technical claims in risk_desc sentence by sentence, check whether there is direct corresponding code evidence in risk_evidence, and identify any missing items that are "described but not supported by evidence"; the same applies to fix_desc and fix_evidence.

[0072] Semantic matching verification: For each item in risk_evidence and fix_evidence, independently verify whether the code behavior, logic or vulnerability characteristics stated in the evidence description can be directly supported by the corresponding code facts.

[0073] Logical chain closure verification: Verify whether the overall set of risk_evidence is sufficient to deduce the existence of the vulnerability defined by risk_desc; verify whether the overall set of fix_evidence is sufficient to deduce the remediation measures defined by fix_desc.

[0074] This submodule outputs logic_pass (a boolean value) and the reason for failure.

[0075] (2) Condition Verification Submodule (Attack Condition Satisfaction Reasoning): This submodule uses LLM for static reasoning, and the steps are as follows: Step 1: Extract Key Conditions. Based on risk_desc and risk_evidence, generate a set of natural language preconditions required for a successful attack. This embodiment uses the attacker's perspective, condition classification, exclusion rules, and the independence principle for extraction. The output format of the key condition prompt template is a JSON list, for example: ["Parameter query was not filtered by SQL metacharacters before being passed to execSQL", "Parameter query comes from user-controlled external input", "There is no SQL metacharacter filtering on the propagation path from external input to parameter query"].

[0076] Step Two: Security Risk Reasoning. Analyze the code slices of the old version (Version 1) and determine whether each of the above preconditions is necessarily met. For each condition, LLM verifies it using a process of direct in-code judgment and tool-assisted judgment. The judgment criteria are: met (explicitly confirmed), not met (explicitly invalid), and uncertain (cannot be verified or disproven). Output verdict and reasoning.

[0077] Step 3: Patch Fix Reasoning. Analyze the code slices of the new version (version 2), and use the same process to determine whether the same preconditions are still met, outputting "met" / "not met" / "uncertain" and the reason.

[0078] Step 4: Pass the test. This submodule passes the test only if the old version explicitly meets all the attack conditions (the vulnerability actually exists) and the new version explicitly does not meet the attack conditions (the fix is ​​effective). Otherwise, it outputs cond_pass=True and the reasoning behind it.

[0079] (3) Regarding the design of mechanisms to avoid model hallucinations, this embodiment designs mechanisms to suppress model hallucinations in the following four aspects: First, the prompt word template is designed with specific step-by-step verification steps and provides clear judgment conditions, which avoids the model from developing illusions due to divergent thinking in the absence of constraints.

[0080] Second, the verification module is designed as a two-dimensional verification mode, and the verification process is broken down into multiple sub-tasks to prevent the model from reaching the limit of its context attention ability when the task is too complex and it needs to maintain the logical chain, factual details and output format in long texts at the same time.

[0081] Third, the conditional verification module introduces verification tools to assist in the judgment. In specific types of verification, it can simplify the verification steps of large models, reduce the reasoning complexity, and thus reduce the probability of hallucinations.

[0082] Fourth, as an optional enhancement, this embodiment can introduce a multi-instance voting mechanism in necessary verification steps (such as semantic self-consistency verification): select multiple different large model instances to perform the verification step at the same time. If more than half or 2 / 3 of the model instances produce a verification result that passes the verification, then the verification step is considered to have passed; otherwise, it is considered to have failed.

[0083] 3. Final confidence score adjudication module: This module takes logic_pass, cond_pass, and the initial confidence score confidence_initial as input and adjudicates according to the following rules: If logic_pass=True and cond_pass=True: the final confidence level is high, and it is retained as a security patch detection result; If exactly one of logic_pass and cond_pass is True: the final confidence level is medium confidence level, and it is considered an uncertain item that requires manual auditing; If logic_pass=False and cond_pass=False: the final confidence level is low, and the candidate unit is filtered out.

[0084] The final output is a security patch identification report with additional confidence levels, including verified security patches (high confidence), candidates requiring manual auditing (medium confidence), and filtered low confidence items.

[0085] By introducing a large language model for security patch inference and combining it with a two-dimensional verification mechanism, the accuracy and reliability of security patch identification are significantly improved. The tool invocation mechanism in the verification module effectively supplements the contextual information not covered by the slices, and the multi-dimensional illusion suppression design ensures the reliability of the model output results. The confidence adjudication module provides a quantifiable reliability assessment of the detection results.

[0086] Step S5, parameter adjustment and optimization. This embodiment involves several adjustable parameters, including the cluster size threshold Threshold, the call distance threshold Dmax, the edge weight calculation parameters (α, β, γ), and the edge weight threshold. This embodiment provides the following parameter optimization methods: (1) Optimization of cluster size threshold Threshold: For different large models, select 20-50 samples labeled with security patching methods, adjust the Threshold value for multiple rounds of experiments while keeping other parameters fixed, calculate the F1 score based on the comparison between the output of the security patch detection module and the labeling results, and select the value with the higher F1 score.

[0087] (2) Edge weight parameters ( Grid search optimization: Randomly select several manually labeled samples (e.g., 30-50 groups of APKs containing security patches), perform grid search on different combinations of (β, γ, edge_th), and compare the consistency between the clustering results and the manually labeled patch groupings. The evaluation method is as follows: For each manually labeled security patch S, perform clustering to obtain several clusters, find the cluster containing the most elements from S and denote it as C, calculate Precision = |C ∩ S| / |C|, Recall = |C ∩ S| / |S|, and F1 = 2×P×R / (P+R). For all security patches in all samples, calculate the weighted average F1 (using the number of methods involved in the patch as the weight) as the final score for that parameter combination. Search within the recommended data range with a step size of 0.1 or 0.05, and determine the optimal solution by maximizing the F1 score.

[0088] This invention effectively improves the accuracy of differential analysis in closed-source applications by employing a matching strategy that combines name priority and similarity. It completes the logical context of security patching through differential unit aggregation and cross-method dependency slicing. Furthermore, it significantly enhances the accuracy and reliability of security patch identification through the deep semantic understanding capabilities of a large language model and a rigorous two-dimensional verification mechanism. This embodiment can effectively detect silent patches in Android closed-source applications, providing a crucial data source for constructing high-quality vulnerability / patch datasets.

[0089] Based on the same inventive concept, embodiments of the present invention also provide an application security patch detection system based on differential semantic analysis, the system being used to execute the method, including: Version Differentiation Module: Used to decompile the first version Android application installation package and the second version Android application installation package, and identify the method-level difference results based on the method name priority matching and hash similarity matching strategy; Differential Unit Aggregation Module: This module abstracts the difference method into graph nodes, calculates edge weights based on the call graph and data dependencies, and uses a hierarchical clustering algorithm with size constraints to aggregate logically related modifications into differential units. Code slicing module: used to extract core change slices and associated slices from the differential unit, and perform deduplication and assembly to generate structured code slices; Large Model Inference Module: Used to input structured code slices into a large language model to obtain candidate security patch units; Two-dimensional verification module: used to perform logical verification and attack condition satisfaction reasoning on the candidate security patch unit; Confidence assessment and output module: used to determine the final confidence level based on the comprehensive results of the two-dimensional verification, and output a security patch identification report.

[0090] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for detecting application security patches based on differential semantic analysis, characterized in that, include: The first version of the Android application installation package and the second version of the Android application installation package are decompiled, and the method-level difference results between the first version and the second version are identified based on a strategy that combines method name priority matching and feature hash similarity matching. The method-level difference results include update methods, addition methods and deletion methods. Each change method in the method differential result is abstracted as a graph node. The edge weights are calculated based on the call graph association score and data association score between the graph nodes. The graph nodes are then clustered using a hierarchical clustering algorithm with size constraints. The update method, addition method and deletion method with logical association are aggregated into one or more differential units. For each differential unit, a core change slice and an associated slice are extracted, and the extracted slices are deduplicated and assembled to obtain a structured code slice; wherein, the core change slice includes the modification line and the adjacent context of the control flow and data flow, and the associated slice includes slices based on the call chain and slices based on shared field read and write; The structured code slices and differential unit metadata are input into a large language model, which drives the large language model to output candidate security patch units. The candidate security patch units are then subjected to two-dimensional verification: logical verification and attack condition satisfaction reasoning. Based on the comprehensive result of the two-dimensional verification, the final confidence level is determined, and a security patch identification report is output.

2. The method according to claim 1, characterized in that, The method-level difference result identification step in the version difference step specifically includes: When matching methods within a matched class, determine whether the method name has been obfuscated. When the method name is determined to be unconfused, matching is prioritized based on the method name, and feature similarity is further calculated only when method overloading occurs. When it is determined that the method is confused, the feature similarity of all unmatched methods between the first version and the second version is calculated, and the matching is performed in descending order of similarity.

3. The method according to claim 1, characterized in that, The graph nodes include: a U node representing the update method, an A node representing the addition method, and a D node representing the deletion method; wherein, the valid version set of the U node includes the first version and the second version, the valid version set of the A node includes only the second version, and the valid version set of the D node includes only the first version; The call graph association score is based on the shortest path distance of a node in the public version of the call graph, and is calculated by distance decay. The data association score is calculated based on the size of the intersection of the read and write operations of nodes on shared fields; The edge weight is the weighted sum of the call graph association score and the data association score.

4. The method according to claim 1, characterized in that, The hierarchical clustering algorithm with size constraints includes: Each of the graph nodes is initialized as an independent cluster; Add all edges whose weights exceed a preset edge weight threshold to a priority queue in descending order of weight; Edges are popped from the priority queue in sequence, and it is determined whether the sum of the number of nodes in the two clusters connected by the edge is less than or equal to a preset cluster size threshold. If so, the two clusters are merged. Repeat the steps of popping edges from the priority queue and performing merging judgment until the priority queue is empty.

5. The method according to claim 1, characterized in that, The extraction of the core change slice specifically includes: For the update method, extract the difference modification line and the preset lines of code before and after it as the modification line slice; when the modification line is located in the control flow statement block, extract the control flow condition statement of the current level upwards; and extract the definition-usage chain of the variables involved in the modification line for one-step backtracking. For the newly added or deleted method, if the number of lines in the method body is less than a preset line count threshold, the complete method body is retained; if the number of lines in the method body exceeds the preset line count threshold, the field read / write operation lines, external method call lines, control flow condition statements, and method parameter usage statements are retained.

6. The method according to claim 1, characterized in that, The extraction of associated slices specifically includes: Call graph association slicing: For method pairs with call associations within the differential unit, extract the relevant call code lines and their pre- and post-preset line contexts within each method on one or more shortest call paths; Data association slicing: Calculate the set of common fields within the difference unit, and extract the lines of code that perform read or write operations on each field in the set of common fields and their pre-set line contexts before and after them from all methods within the difference unit.

7. The method according to claim 1, characterized in that, The logical verification includes: Exact match verification: Verify whether the risk evidence code string and the repair evidence code string in the candidate security patch unit exist exactly in the corresponding version of the code; Semantic self-consistency verification: The large language model is used to check the semantic consistency between risk description and risk evidence, as well as the semantic consistency between repair description and repair evidence; the semantic consistency includes: integrity verification, semantic matching verification and logical chain closure verification.

8. The method according to claim 1, characterized in that, The attack condition satisfaction reasoning includes: Based on the risk descriptions and risk evidence in the candidate security patch units, extract the key conditions that enable the vulnerability to be successfully exploited. The code slice of the first version is analyzed using the large language model to determine whether the key conditions are met. The code slice of the second version is analyzed using the large language model to determine whether the key condition is no longer satisfied. The attack condition satisfaction reasoning is verified only if the first version explicitly satisfies the key condition and the second version explicitly does not satisfy the key condition.

9. The method according to claim 1, characterized in that, The final confidence level is determined based on the comprehensive results of the two-dimensional verification, specifically as follows: When both the logical verification and the attack condition satisfaction reasoning pass, the final confidence level of the decision is high confidence. When exactly one of the logical verification and the attack condition satisfaction reasoning passes, the final confidence level of the decision is medium confidence. When both the logical verification and the attack condition satisfaction reasoning fail, the final confidence level of the ruling is low confidence.

10. An application security patch detection system based on differential semantic analysis, characterized in that, The system is used to perform the method according to any one of claims 1-9, comprising: Version Differentiation Module: Used to decompile the first version Android application installation package and the second version Android application installation package, and identify the method-level difference results based on the method name priority matching and hash similarity matching strategy; Differential Unit Aggregation Module: This module abstracts the difference method into graph nodes, calculates edge weights based on the call graph and data dependencies, and uses a hierarchical clustering algorithm with size constraints to aggregate logically related modifications into differential units. Code slicing module: used to extract core change slices and associated slices from the differential unit, and perform deduplication and assembly to generate structured code slices; Large Model Inference Module: Used to input structured code slices into a large language model to obtain candidate security patch units; Two-dimensional verification module: used to perform logical verification and attack condition satisfaction reasoning on the candidate security patch unit; Confidence assessment and output module: used to determine the final confidence level based on the comprehensive results of the two-dimensional verification, and output a security patch identification report.

Images