A structure-guided android application identifier semantic de-obfuscation method and system

Abstract

The application belongs to the technical field of computer software security and program analysis, and provides a structure-guided Android application identifier semantic de-obfuscation method and system. The method extracts program structure, constructs a function call graph, and obtains identifier mapping of a third-party library. The method classifies and selectively prunes nodes, uses known identifiers and resource semantics of the third-party library to enhance the analysis context of the developer's custom code, determines a bottom-up analysis order according to a call dependency relationship and a strongly connected component, inputs current method program representation and recovered called method semantics into a large language model, and sequentially recovers method, field, class and package names and executes corresponding naming constraints. Finally, the method verifies the compliance of the identifier, generates a mapping and reconstructs the application. The application reduces repeated reasoning on the third-party library code, improves the accuracy and consistency of the identifier semantic recovery of the custom code, eliminates generated name conflicts and reduces semantic drift.

Description

Technical Field

[0001] This invention belongs to the field of computer software security and program analysis technology, and particularly relates to a structure-guided method and system for semantic deobfuscating Android application identifiers. Background Technology

[0002] Android app development typically employs code obfuscation techniques to increase the difficulty of reverse engineering. Common obfuscation methods include identifier renaming, control flow transformation, and string encryption. Identifier renaming, in particular, removes a significant amount of semantic information from packages, classes, methods, and fields by replacing their semantically meaningful names with short or random strings, without altering the app's fundamental execution logic. While apps processed in this way may still function normally, security analysts find it difficult to quickly locate malicious behavior, privacy-related logic, and potential vulnerabilities through decompiling the code.

[0003] Existing identifier deobfuscation schemes mainly include code similarity-based mapping schemes, training corpus-based name prediction schemes, and large language model-based local code reasoning schemes. Code similarity-based schemes can migrate identifiers from known open-source libraries to matching code, but they often struggle to cover application-specific logic. Training corpus-based schemes rely on naming priors in the training data, and are prone to generating overly broad names when faced with new interfaces, new libraries, or specific application logic. Large language model-based schemes can understand code semantics, but they typically analyze individual methods or classes, lacking complete dependency information across methods, classes, and packages.

[0004] When a large language model only receives isolated code snippets, the functionality of called methods, the usage of fields in different locations, class inheritance relationships, and the original meaning of resource identifiers may all be missing. This can easily lead to semantic direction errors, multiple names for the same field, or inconsistent names within the same call chain. If the complete application code is directly input into the large language model, the numerous methods and third-party library code in modern Android applications consume significant context windows and inference resources, making it difficult to balance context integrity and processing efficiency. Furthermore, Java's object-oriented mechanism imposes explicit semantic and syntactic constraints on identifiers. The results generated by the large language model have a degree of randomness; without program structure constraints and unified verification, directly replacing identifiers may lead to compilation failures or changes in program semantics. Summary of the Invention

[0005] To address at least one of the technical problems existing in the background art described above, the present invention provides a method and system for deobfuscating the semantics of Android application identifiers in structure-guided architecture.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: The first aspect of the present invention provides a method for deobfuscating the semantics of Android application identifiers in structure-driven architecture, comprising the following steps: The target Android application installation package is parsed and statically analyzed to extract the program structure, construct a function call graph, and obtain the identifier mapping of third-party libraries; The method nodes in the function call graph are classified by source, and selective pruning is performed on the method nodes of different categories. The known identifier semantics of third-party libraries and resource identifier semantics are written into the reserved nodes to obtain the context-enhanced function call graph. The bottom-up method node analysis order is determined based on the call dependencies in the context-enhanced function call graph; According to the method node analysis order, a structured context is constructed for the method node to be recovered. The structured context is input into the large language model to obtain the candidate method name, candidate field name and behavior description of the current method. The obtained recovery name and behavior description are propagated to the caller along the call dependency relationship, and the coverage relationship consistency constraint and method signature uniqueness constraint are executed on the candidate method name. Based on the named method names, field names, and behavior descriptions, class-level contexts and package-level contexts are constructed, candidate class names and candidate package names are obtained sequentially, and uniqueness constraints within their respective scopes are applied to the candidate class names, candidate field names, and candidate package names. Java identifier validity verification is performed on the identifiers that have passed the aforementioned coverage relationship consistency constraint, method signature uniqueness constraint, and scope uniqueness constraint. Identifier mapping is generated, and the obfuscated identifiers in the target Android application are replaced by the identifier mapping and the deobfuscated Android application installation package is reconstructed.

[0007] Furthermore, the mapping of third-party libraries identified in the target Android application specifically includes: package mapping, class mapping, and method mapping. Among them, package mapping and class mapping include retaining the candidate mapping with the highest structural similarity for duplicate package mappings within the same third-party library, prioritizing the confirmation of parent package mappings based on package hierarchy, filtering out sub-package mappings that are inconsistent with the confirmed parent package mappings, and retaining only class mappings that are consistent with the confirmed package structure. Method mapping includes: based on the confirmed class mappings, performing direct signature matching, unique candidate matching after replacing the determinable parameter types and return types, and single remaining candidate matching within the same class in sequence to form method candidate mappings.

[0008] Furthermore, before classifying the source of method nodes in the function call graph, the process includes initializing the function call graph, recording the method signature, intermediate code snippets, node type, and semantic annotation fields for storing recovery names and behavior descriptions for each method node, and supplementing component lifecycle call edges and asynchronous call edges.

[0009] Furthermore, the method nodes include external application interface nodes, third-party library nodes, and developer-defined nodes; the third-party library nodes include precise third-party library nodes and library-level third-party library nodes; Selective pruning is performed on different types of method nodes, specifically including: For developer-defined nodes, entry path filtering is used, and the function call graph is traversed starting from the developer-defined entry node, without starting independent traversal from the third-party library entry point; External application interface nodes and precise third-party library nodes are used as unconditional pruning boundaries, preserving their names and functions for callers to use, but not continuing to traverse their downstream libraries. For library-level third-party library nodes, a conditional pruning boundary is adopted. The proportion of valid semantic elements such as unobfuscated field names, unobfuscated method names, and constants within the method is statistically analyzed to obtain a context information score. When the score is higher than a preset threshold, the node is taken as the pruning boundary. If the score is not higher than the threshold, the node is retained and its downstream call path is traversed.

[0010] Furthermore, the step of writing known third-party library identifier semantics and resource identifier semantics into reserved nodes to obtain a context-enhanced function call graph includes: Writing known third-party library identifier semantics into reserved nodes includes: replacing obfuscated third-party library identifiers in reserved nodes with package mapping, class mapping, and method mapping, and writing the identifiable third-party library names as stable semantics into the node context, thereby achieving third-party library semantic enhancement; Writing resource identifier semantics into the reserved nodes includes: parsing Android resource files, restoring the resource index to the resource type and resource name, and adding the restored resource semantics to the method node that accesses the resource, resulting in a context-enhanced function call graph that simultaneously contains the call structure, external interface semantics, third-party library semantics, and resource semantics.

[0011] Furthermore, the step of determining the bottom-up method analysis order based on the call dependencies in the context-enhanced function call graph includes: Identify method nodes with circular call relationships and aggregate them into strongly connected components; Construct a directed acyclic graph based on strongly connected components; The strongly connected components are processed from bottom to top according to the directed acyclic graph, and a first round of analysis and a conditional second round of analysis are performed on the method nodes in a single strongly connected component. In the first iteration, method nodes are selected in order of increasing number of unanalyzed called methods, semantic reasoning is performed on the selected method nodes, and the reasoning results are updated to the caller nodes within the strongly connected components; After completing the first round of iterations, identify method nodes that still have unresolved dependencies, and use the context within the strongly connected components formed in the first round of iterations to perform a second round of semantic reasoning on the method nodes. The analysis of the strongly connected component is stopped when there are no method nodes whose context is incomplete due to unresolved intra-component dependencies, or when further iterations no longer obtain new intra-component context.

[0012] Furthermore, the coverage relationship consistency check includes dividing method coverage groups according to the class inheritance graph and the method signature consisting of the method name and parameter type, so that methods within the same coverage group use the same name; when there are external application interface methods or exact third-party library methods within the coverage group, their known names are used; Method signature uniqueness check includes collecting non-private methods of various inheritances from bottom to top according to class hierarchy, detecting potential conflicts for methods that do not belong to the same coverage group but use the same name and parameter type, and reselecting different candidate names for conflicting methods.

[0013] A second aspect of the present invention provides a structure-guided Android application identifier semantic deobfuscation system, comprising: The program structure extraction module is used to parse and perform static analysis on the target Android application installation package, extract the program structure, construct a function call graph, and obtain the identifier mapping of third-party libraries. The graph optimization and context enhancement module is used to classify the source of method nodes in the function call graph, selectively prune method nodes of different categories, and write the known identifier semantics of third-party libraries and resource identifier semantics into the retained nodes to obtain the context-enhanced function call graph. The method and field recovery and constraint module is used to determine the bottom-up method node analysis order based on the call dependency relationship in the context-enhanced function call graph; according to the method node analysis order, a structured context is constructed for the method node to be recovered, the structured context is input into the large language model to obtain the candidate method name, candidate field name and behavior description of the current method, the obtained recovered name and behavior description are propagated to the caller along the call dependency relationship, and the coverage relationship consistency constraint and method signature uniqueness constraint are executed on the candidate method name; The class and package recovery and constraint module is used to construct class-level contexts and package-level contexts based on the named and constrained method names, field names and behavior descriptions, obtain candidate class names and candidate package names in sequence, and perform uniqueness constraints on the candidate class names, candidate field names and candidate package names within their respective scopes. The legality verification and reconstruction module is used to perform Java identifier legality verification on the identifiers that have passed the consistency constraints of the coverage relationship, the uniqueness constraints of the method signature, and the uniqueness constraints of each scope, generate an identifier mapping, use the identifier mapping to replace the obfuscated identifiers in the target Android application, and reconstruct to obtain the deobfuscated Android application installation package.

[0014] A third aspect of the present invention provides a computer-readable storage medium.

[0015] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of a structure-booted Android application identifier semantic deobfuscation method as described above.

[0016] A fourth aspect of the present invention provides a computer device.

[0017] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of a structure-guided Android application identifier semantic deobfuscation method as described above.

[0018] Compared with the prior art, the beneficial effects of the present invention are: This invention organizes the analysis order of a large language model by function call dependencies, and uses the restored name and behavior description of the analyzed called method as the structured context of the caller, so that the semantics of the method can be propagated from bottom to top along the call relationship, thereby obtaining cross-method and cross-class context information without having to input the complete application code all at once.

[0019] This invention restores known semantics by mapping third-party library packages, classes, and methods, and uses semantically determined external nodes or third-party library nodes as pruning boundaries of the function call graph, enabling large language models to centrally process developer-defined logic and reducing context occupancy and repetitive reasoning caused by known library code.

[0020] This invention divides the circular call method into strongly connected components and adopts a two-round iteration within the component and a context backfilling mechanism, so that the interdependent methods can utilize the restored semantics within the component in subsequent rounds, reducing the context loss caused by circular dependencies.

[0021] This invention summarizes the method and field recovery results into class-level context and package-level context layer by layer, forming a hierarchical semantic recovery chain from method and field to class and package, which enables candidate names at different levels to remain associated within the same program structure.

[0022] This invention performs constraints on the consistency of the overriding method and the uniqueness of the method signature after the method is restored, performs constraints on the uniqueness of the class name, field name, and package name after the class and package are restored, and performs Java identifier validity checks before mapping replacement. This allows for timely resolution of inconsistencies in overriding relationships and name conflicts after candidate names are generated at each level, reducing the risk of refactoring failure and improving the usability and auditability of the deobfuscation results.

[0023] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0024] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0025] Figure 1 This is a flowchart of a structure-guided Android application identifier semantic deobfuscation method provided in an embodiment of the present invention; Figure 2 This is a flowchart of the target application parsing, program structure extraction, and third-party library mapping provided in this embodiment of the invention; Figure 3 This is a flowchart of the context-enhanced function call graph construction provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the method for determining the analysis sequence provided in this embodiment of the invention; Figure 5 This is a flowchart illustrating the method, field semantic recovery, and method naming constraints provided in this embodiment of the invention. Figure 6 This is a flowchart of class and package semantic recovery and naming constraints provided in an embodiment of the present invention; Figure 7 This is a flowchart of identifier validity verification, replacement, and application reconstruction provided in an embodiment of the present invention; Figure 8 This is a framework diagram of the structure-guided Android application identifier semantic deobfuscation system provided in this embodiment of the invention. Detailed Implementation

[0026] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0027] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0028] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0029] like Figure 1 As shown, this embodiment provides a method for deobfuscating the semantics of Android application identifiers in structure-driven architecture, including the following steps: S1: Parse and perform static analysis on the target Android application installation package, extract the program structure, construct a function call graph, and obtain the identifier mapping of third-party libraries.

[0030] like Figure 2 As shown, it specifically includes: S101: Installation package parsing; In this embodiment, the target Android application installation package is unpacked, and DEX bytecode, resource files, manifest files and other available metadata are extracted to form the basic input required for program structure analysis and application reconstruction.

[0031] S102: Program structure extraction; Static analysis of the target Android application installation package involves using a static analysis framework to convert DEX bytecode into an intermediate representation suitable for program analysis. Specifically, PacDroid, based on the Tai-e analysis engine, is used to perform pointer analysis; alternatively, other static analysis implementations capable of outputting equivalent intermediate program representations and call relationships can also be employed.

[0032] Extract the program structure, extract class definitions, inheritance and interface implementation relationships, method signatures, field access relationships and resource identification information from the intermediate representation of the program and application metadata, and form the class hierarchy relationship and method call relationship required for subsequent steps respectively. Construct a function call graph based on the method call relationship.

[0033] S103: Third-party library identification; In this embodiment, LibPecker is used to perform similarity matching between candidate packages or candidate classes in the target application and third-party library samples based on the structural dependencies between classes.

[0034] In one specific implementation, a structural similarity threshold of 0.6, recommended by LibPecker, is used to retain candidate libraries; it should be noted that the structural similarity threshold is an adjustable implementation parameter.

[0035] Based on the similarity threshold, we can filter out the third-party libraries that meet the requirements, that is, the third-party library identification results that reach the structural similarity threshold.

[0036] S104: Initial identifier mapping construction; Initial mapping of packages and classes: Based on the identification results of third-party libraries that have reached the structural similarity threshold, candidate mappings are established between obfuscated package paths, obfuscated class paths and corresponding unobfuscated paths in known third-party libraries, and the structural similarity of the candidate mappings is preserved.

[0037] Method matching set construction: Based on the candidate class mapping, SootUp is used to extract the name, parameter type and return type of each method in the mapped class pair, forming the target application method set and the known third-party library method set, which serve as inputs for subsequent method mapping filtering.

[0038] S105: Mapping filtering and conflict resolution, including: Package and class mapping refinement: For duplicate package mappings within the same third-party library, the candidate mapping with the highest structural similarity is retained. The parent package mapping is confirmed first based on the package hierarchy, and the child package mappings that are inconsistent with the confirmed parent package mapping are filtered out. Only the class mappings that are consistent with the confirmed package structure are retained.

[0039] Method map filtering: Based on the confirmed class map, direct signature matching, unique candidate matching after replacing the definite parameter types and return types, and single remaining candidate matching in the same class are performed in sequence to form a method candidate map; among them, single remaining candidate matching is only applicable when there is only one unmatched method in the same class, and methods that still cannot be uniquely determined are not written into the exact method map.

[0040] Handling of inaccurate matching methods: Candidate libraries that do not reach the structural similarity threshold are not considered as identified third-party libraries; For method nodes whose package-level or class-level affiliation of a third-party library has been determined, but whose specific method mapping cannot be uniquely determined, they are marked as library-level third-party library nodes in step S203, and in step S204, they are scored based on context information to determine whether they are used as pruning boundaries.

[0041] S2: Classify the method nodes in the function call graph by source, selectively prune the third-party library nodes based on the node source and context information, and write the known third-party library identifier semantics and resource identifier semantics into the retained nodes to obtain the context-enhanced function call graph; In this embodiment, based on the function call graph constructed in S102, the information of each method node is initialized, and call edges related to the Android component lifecycle and asynchronous execution are supplemented. Then, method nodes from different sources are distinguished, and pruning boundaries are determined according to node semantics. Finally, third-party library mappings and resource semantics are written into the retained nodes, allowing the large language model to focus on processing developer-defined logic while retaining necessary library-level third-party library nodes to supplement the analysis context. Figure 3 As shown, it specifically includes: S201: Initialize the function call graph; Initialize the nodes and call edges of the function call graph: record the complete method signature, intermediate code snippets, access field index, node source type, and semantic annotation field for each method node; the semantic annotation field is used to store the recovery name and behavior description.

[0042] S202: Call relationship completion, specifically including: Component lifecycle edge completion: For the startup calls of activity components and service components, supplement the call edge from the call location to the corresponding lifecycle method of the target component, so that the component callback code can enter the subsequent semantic propagation path; Asynchronous execution edge supplementation: For asynchronous task calls, supplement the call edge from the scheduling position to the corresponding asynchronous task lifecycle method to make up for the asynchronous execution relationship that was missed when only the direct data propagation call edge was retained.

[0043] S203: Classify the source of method nodes in the function call graph; In this embodiment, method nodes are divided into external application interface nodes, third-party library nodes, and developer-defined nodes; among them, according to the third-party library package mapping, class mapping, or method mapping, the third-party library nodes are further divided into precise third-party library nodes with unique method mapping and library-level third-party library nodes that only determine package-level or class-level affiliation.

[0044] The specific classification method is as follows: First, identify external application interface nodes in the Android SDK or JDK based on the classpath and platform interface manifest; then, identify third-party library nodes based on package mapping, class mapping, and method mapping; finally, mark unclassified methods as developer-defined nodes; nodes confirmed by the platform manifest are not covered by lower confidence mappings.

[0045] S204: Selective pruning of method nodes of different categories; specifically including: Entry path filtering: Traverse the function call graph starting from the developer's custom entry node, without starting independent traversal from the entry point of a third-party library, so that the set to be analyzed focuses on the logic implemented by the application developer.

[0046] Unconditional pruning boundaries: External application interface nodes and precise third-party library nodes are used as unconditional pruning boundaries, preserving their names and functions for use by the caller, but not continuing to traverse their downstream library implementations.

[0047] Conditional pruning boundary: For library-level third-party library nodes, the proportion of valid semantic elements such as unobfuscated field names, unobfuscated method names, and constants within the statistical method is used to obtain a context information score; when the score is higher than a preset threshold, the node is taken as the pruning boundary, and when it is not higher than the threshold, the node is retained and its downstream call path is traversed.

[0048] In this embodiment, the preset threshold is set to 0.7.

[0049] S205: Write the known third-party library identifier semantics and resource identifier semantics into the reserved nodes to obtain the context-enhanced function call graph; The obfuscated third-party library identifier in the retained node is replaced by the third-party library mapping, and the resource identifier is resolved into resource type and resource name according to the Android resource file to obtain the context-enhanced function call graph.

[0050] Specifically, writing known third-party library identifier semantics into reserved nodes includes: replacing obfuscated third-party library identifiers in reserved nodes with package mapping, class mapping, and method mapping, and writing the identifiable third-party library names as stable semantics into the node context, thereby achieving third-party library semantic enhancement; writing resource identifier semantics into reserved nodes includes: parsing Android resource files, restoring resource indexes to resource types and resource names, and adding the restored resource semantics to the method nodes that access the resource, resulting in a context-enhanced function call graph that simultaneously contains call structure, external interface semantics, third-party library semantics, and resource semantics.

[0051] S3: Determine the bottom-up method analysis order based on the call dependencies in the context-enhanced function call graph; In this embodiment, the method analysis order is the processing order when the large language model recovers the semantics of each method. The basic principle is to analyze the called method first, and then use its recovery result to analyze the calling method. Based on the context-enhanced function call graph's call dependencies, the called method is analyzed before the calling method. For loop structures formed by recursion or mutual calls, strongly connected components are first shrunk, and then the processing order between and within components is determined separately, such as... Figure 4 As shown, it specifically includes: S301: Identify method nodes with circular call relationships and aggregate the method nodes into strongly connected components; A strongly connected component algorithm is used to identify method sets formed by recursive or mutual calls; method nodes without circular dependencies are treated as single-node strongly connected components.

[0052] S302: Construct a directed acyclic graph based on strongly connected components; In this embodiment, each strongly connected component is shrunk into a supernode, and the call dependency edges between different strongly connected components are preserved, so that the shrunk supernode graph forms a directed acyclic graph.

[0053] S303: Determine the order between components.

[0054] In this embodiment, reverse topological sorting is adopted: according to the reverse topological order of the directed acyclic graph of supernodes, each strongly connected component is arranged from the supernode with no unprocessed downstream dependencies toward the caller, so that each component enters the analysis queue only after its dependent downstream components have been processed.

[0055] S304: Intra-component order determination.

[0056] In this embodiment, performing the first round of analysis and the conditional second round of analysis on the method node in a single strongly connected component specifically includes: In the first iteration, within a strongly connected component containing multiple methods, the number of unanalyzed called methods for each method node is counted, and method nodes are selected from fewest to most. Semantic reasoning is performed on the selected method nodes, and the reasoning results are updated to the caller nodes within the strongly connected component. Whenever a node obtains semantics, the available context and subsequent selection order of the caller nodes within the component are updated.

[0057] After completing the first iteration, nodes that still lack the semantics of the called methods within the component during the initial analysis are marked, and the semantic reasoning of the method nodes is performed in the second round using the strong connected component context formed in the first iteration. When there are no method nodes whose context is incomplete due to unresolved intra-component dependencies, or when no new intra-component context is obtained by continuing the iteration, the analysis of the strong connected component is stopped.

[0058] S4: Following the method analysis order, construct a structured context for the method node to be restored, input the structured context into the large language model, obtain the candidate method name, candidate field name and behavior description of the current method, propagate the obtained restoration name and behavior description to the caller along the call dependency relationship, and perform coverage relationship consistency constraint and method signature uniqueness constraint on the candidate method name; like Figure 5 As shown, it specifically includes: S401: Construct a structured context for the method node to be restored; Context element organization: The structured context includes the full method signature of the current method, the preprocessed intermediate representation code snippet, the access field index, the restored name and behavior description of the analyzed called method; when there is a third-party library mapping or resource access, it also includes the restored package path, class path, method name, resource type and resource name.

[0059] Context scaling control: The called method only provides the recovery name and behavior description, without repeatedly attaching its complete code, so that the semantics of the call chain can be propagated upstream while reducing the amount of duplicate code occupying the model context.

[0060] S402: Input the structured context into the large language model to obtain the candidate method name, candidate field name, and behavior description of the current method; In this embodiment, the method-level context and Java identifier output constraints are combined into a structured hint, requiring the large language model to output candidate method names, candidate field names, and descriptions corresponding to program behavior.

[0061] In addition, the large language model uses GPT-5.4-mini with a temperature set to 0.1 to reduce naming fluctuations caused by multiple inferences in the same context; other model types and parameter settings can also be used in other embodiments.

[0062] Candidate result generation: Based on the program representation of the current method, known call semantics, and resource semantics, infer the method function, obtain the candidate method name, candidate field name, and behavior description, and write the parsable candidate results into the current method node.

[0063] S403: Propagate the obtained recovery name and behavior description to the caller along the calling dependencies; The method recovery name, field candidate names, and behavior description are propagated along the call dependency relationship to the caller node, enabling the caller to obtain the semantics of the called method in subsequent analysis.

[0064] For a multi-node strongly connected component, the first round completes node reasoning and result propagation in the order determined in step S304; then, the in-component context formed in the first round is used to re-analyze nodes with incomplete contexts until no such nodes exist or no new in-component contexts are generated.

[0065] For the same field accessed by multiple methods, summarize the candidate field names and behavior descriptions in different access contexts, analyze the common semantics of each usage location, and select a unified field name that is consistent with each access behavior and has a more complete semantic expression.

[0066] S404: Apply coverage consistency constraints and method signature uniqueness constraints to candidate method names; Coverage consistency check: Based on the class inheritance graph and the method signature consisting of the method name and parameter types, method coverage groups are divided, so that methods within the same coverage group use the same name; when there are external application interface methods or exact third-party library methods within the coverage group, their known names are preferred.

[0067] Method signature uniqueness check: Collect all non-private methods of inheritance from bottom to top according to the class hierarchy, detect potential conflicts for methods that do not belong to the same overriding group but use the same name and parameter type, and reselect different candidate names for conflicting methods.

[0068] Platform method protection: In one implementation, a list of public method protections is established that covers Android SDK versions 14 to 36 and JDK Long Term Support versions 8, 11, 17 and 21 to prevent candidate names from accidentally overriding standard library methods that do not appear in the current DEX file.

[0069] S5: Based on the named method names, field names, and behavior descriptions, construct class-level and package-level contexts, sequentially obtain candidate class names and candidate package names, and apply uniqueness constraints within their respective scopes to the candidate class names, candidate field names, and candidate package names. For example... Figure 6 As shown, the specific steps include the following: S501: Construct a class-level context; In this embodiment, class-level context construction specifically includes target class filtering and inline field compensation; Among them, target class filtering: select classes containing restored developer-defined methods as class-level analysis objects, and organize class paths, parent class paths, interface paths, related annotations, complete method signatures, method behavior descriptions, field information, and known semantics of third-party libraries.

[0070] Inline field compensation: For fields that lack direct field access instructions due to compiler field inlining, the constant usage location and related method behavior descriptions are added to the class-level context, enabling class-level reasoning to recover the field meaning using the semantics of the method containing the constant.

[0071] S502: Input the class-level context into the large language model, perform class-level semantic reasoning, and obtain candidate class names, candidate field names, and class function descriptions.

[0072] In this embodiment, the class-level context is input into the large language model, and the candidate class name, candidate field name, and class function description are obtained by combining the structural relationship of the class, the functions jointly undertaken by a group of methods, and the usage of fields.

[0073] S503: Construct a package hierarchy graph and package-level context; The package hierarchy graph is constructed according to the actual directory relationship of classes in the application. Package nodes represent packages containing one or more class definitions, and edges represent the hierarchical relationship between parent packages and direct child packages. The restored name is only written as a package node attribute and does not change the original parent-child relationship.

[0074] The construction of a package-level context includes the construction of the leaf package context and the parent package context; Leaf package context construction: For leaf packages that do not contain sub-packages, the recovery names and class function descriptions of various types within the package are summarized to form the semantic input of the leaf package.

[0075] Parent package context construction: For non-leaf packages, in addition to summarizing the class information they directly contain, the names and functional descriptions of the recovered direct child packages are further summarized, so that parent package reasoning can utilize the semantics of the child packages.

[0076] S504: Input the packet-level context into the large language model to recover the packet semantics; Starting from the leaf package, the package-level context is input into the large language model to obtain the candidate package name and package function description; if the current package still has an unanalyzed parent package, the recovery result is written into the parent package context and processing continues to the root package.

[0077] S505: Apply uniqueness constraints within their respective scopes to candidate class names, candidate field names, and candidate package names; Among them, class and field uniqueness checks: constrain class names within the same package to be different, and constrain field names within the same class to be different; when a conflict is detected, a new name is selected from the candidate names at the corresponding level.

[0078] Package name uniqueness check: Constrain each root package name to be globally unique, and constrain the names of direct child packages under the same parent package to be unique, to prevent the accidental merging of originally independent package paths after renaming.

[0079] S6: Perform Java identifier validity verification on the identifiers that have passed the coverage relationship consistency constraint, method signature uniqueness constraint and each scope uniqueness constraint, generate identifier mapping, use the identifier mapping to replace the obfuscated identifier in the target Android application and reconstruct to obtain the deobfuscated Android application installation package.

[0080] like Figure 7 As shown, it specifically includes: S601: Identifier validity check.

[0081] Java Identifier Check: This checks whether candidate names meet Java identifier rules; it normalizes names containing spaces, hyphens, or other illegal characters and avoids the use of Java keywords. Normalized names are then re-entered for validity checks until they meet the requirements; if no valid candidate is found, the original name is retained.

[0082] Step S602: Identifier mapping and replacement.

[0083] Unified mapping generation: Record the original identifier and the restored identifier according to package, class, method and field respectively to form a unified identifier mapping; candidates that fail the semantic, naming constraints and legality checks are not written into the mapping.

[0084] Definition and reference synchronization replacement: Based on the definition and reference relationships between identifiers, the corresponding names in the Smali code are replaced synchronously to ensure that the same identifier remains consistent within its scope; identifiers that have not formed a mapping retain their original names.

[0085] S603: Application Refactoring.

[0086] Package Refactoring: The replaced Smali code and resource files are processed using an Android application packaging tool, and a deobfuscated Android application package is generated using Apktool. The generated package can be decompiled again for security auditors to view code with recovery semantics.

[0087] This embodiment uses S1 to S6 to continuously transfer the known semantics of the third-party library, the program call structure, and the hierarchical recovery results between different stages, enabling the large language model to focus on analyzing the developer's custom code; and executes the corresponding naming constraints in the method recovery stage and the class and package recovery stage respectively, and finally completes the identifier legality verification and application reconstruction.

[0088] The range of legal characters for Java identifiers is explicitly defined by Java syntax. Illegal characters in candidate names are replaced with legal characters such as underscores; for example, "user-name!" is normalized to "user_name_". During refactoring, the restored name needs to be written back to the program and the APK regenerated. If the name is invalid, the write-back or compilation process will report an error, causing the refactoring to fail. In the evaluation of 50 deobfuscated APKs, all APKs were successfully refactored, indicating that the output names all met the legality requirements.

[0089] This invention focuses on evaluating the semantic recovery performance of code. At the code fragment level, this invention employs both user study and large language model evaluation (LLM Rater Avg.), and uses ERR and BRR to measure whether the recovered results effectively express the original semantics and whether they outperform the recovery results of other tools. At the identifier level, this invention uses Subtoken F1 to evaluate the similarity between the recovered names of methods, fields, classes, and packages and the original names at the sub-word level. The methods of this invention are compared across the above metrics, as shown in Table 1: Table 1 Comparison of the present invention and existing methods in various indicators

[0090] As can be seen from Table 1, the DeMask of the present invention outperforms the comparative tools in all the above indicators, indicating that it has better semantic recovery capabilities.

[0091] Example 2 This embodiment provides a structure-guided Android application identifier semantic deobfuscation system, the structure of which is as follows: Figure 8 As shown, specifically including The program structure extraction module is used to parse and perform static analysis on the target Android application installation package, extract the program structure, construct a function call graph, and obtain the identifier mapping of third-party libraries. The graph optimization and context enhancement module is used to classify the source of method nodes in the function call graph, selectively prune method nodes of different categories, and write the known identifier semantics of third-party libraries and resource identifier semantics into the retained nodes to obtain the context-enhanced function call graph. The method and field recovery and constraint module is used to determine the bottom-up method node analysis order based on the call dependency relationship in the context-enhanced function call graph; according to the method node analysis order, a structured context is constructed for the method node to be recovered, the structured context is input into the large language model to obtain the candidate method name, candidate field name and behavior description of the current method, the obtained recovered name and behavior description are propagated to the caller along the call dependency relationship, and the coverage relationship consistency constraint and method signature uniqueness constraint are executed on the candidate method name; The class and package recovery and constraint module is used to construct class-level contexts and package-level contexts based on the named and constrained method names, field names and behavior descriptions, obtain candidate class names and candidate package names in sequence, and perform uniqueness constraints on the candidate class names, candidate field names and candidate package names within their respective scopes. The legality verification and reconstruction module is used to perform Java identifier legality verification on the identifiers that have passed the consistency constraints of the coverage relationship, the uniqueness constraints of the method signature, and the uniqueness constraints of each scope, generate an identifier mapping, use the identifier mapping to replace the obfuscated identifiers in the target Android application, and reconstruct to obtain the deobfuscated Android application installation package.

[0092] It should be noted that the specific implementation of the structure-guided Android application identifier semantic deobfuscation system in this embodiment of the invention is similar to the specific implementation of the structure-guided Android application identifier semantic deobfuscation method in this embodiment of the invention. For details, please refer to the description in the method section. To reduce redundancy, it will not be repeated here.

[0093] Example 3 This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the structure-guided Android application identifier semantic deobfuscation method described above.

[0094] Example 4 This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the structure-guided Android application identifier semantic deobfuscation method described above.

[0095] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0096] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0097] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0098] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0099] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0100] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for semantic deobfuscating Android application identifiers based on structure guidance, characterized in that, Includes the following steps: The target Android application installation package is parsed and statically analyzed to extract the program structure, construct a function call graph, and obtain the identifier mapping of third-party libraries; The method nodes in the function call graph are classified by source, and selective pruning is performed on the method nodes of different categories. The known identifier semantics of third-party libraries and resource identifier semantics are written into the reserved nodes to obtain the context-enhanced function call graph. The bottom-up method node analysis order is determined based on the call dependencies in the context-enhanced function call graph; According to the method node analysis order, a structured context is constructed for the method node to be recovered. The structured context is input into the large language model to obtain the candidate method name, candidate field name and behavior description of the current method. The obtained recovery name and behavior description are propagated to the caller along the call dependency relationship, and the coverage relationship consistency constraint and method signature uniqueness constraint are executed on the candidate method name. Based on the named method names, field names, and behavior descriptions, class-level contexts and package-level contexts are constructed, candidate class names and candidate package names are obtained sequentially, and uniqueness constraints within their respective scopes are applied to the candidate class names, candidate field names, and candidate package names. Java identifier validity verification is performed on the identifiers that have passed the aforementioned coverage relationship consistency constraint, method signature uniqueness constraint, and scope uniqueness constraint. Identifier mapping is generated, and the obfuscated identifiers in the target Android application are replaced by the identifier mapping and the deobfuscated Android application installation package is reconstructed.

2. The method for deobfuscating the semantics of Android application identifiers in structure-guided programming as described in claim 1, characterized in that, The mapping of third-party libraries identified in the target Android application specifically includes: package mapping, class mapping, and method mapping. Among them, package mapping and class mapping include retaining the candidate mapping with the highest structural similarity for duplicate package mappings within the same third-party library, prioritizing the confirmation of parent package mappings based on package hierarchy, filtering out sub-package mappings that are inconsistent with the confirmed parent package mappings, and retaining only class mappings that are consistent with the confirmed package structure. Method mapping includes: based on the confirmed class mappings, performing direct signature matching, unique candidate matching after replacing the determinable parameter types and return types, and single remaining candidate matching within the same class in sequence to form method candidate mappings.

3. The method for semantic deobfuscating Android application identifiers based on structure guidance as described in claim 1, characterized in that, Before classifying the source of method nodes in the function call graph, the process includes initializing the function call graph, recording the method signature, intermediate code snippets, node type, and semantic annotation fields for storing recovery names and behavior descriptions for each method node, and supplementing component lifecycle call edges and asynchronous call edges.

4. The method for semantic deobfuscating Android application identifiers based on structure guidance as described in claim 1, characterized in that, Method nodes include external application interface nodes, third-party library nodes, and developer-defined nodes; Third-party library nodes include precise third-party library nodes and library-level third-party library nodes; Selective pruning is performed on different types of method nodes, specifically including: For developer-defined nodes, entry path filtering is used, and the function call graph is traversed starting from the developer-defined entry node, without starting independent traversal from the third-party library entry point; External application interface nodes and precise third-party library nodes are used as unconditional pruning boundaries, preserving their names and functions for callers to use, but not continuing to traverse their downstream libraries. For library-level third-party library nodes, a conditional pruning boundary is adopted. The proportion of valid semantic elements such as unobfuscated field names, unobfuscated method names, and constants within the method is statistically analyzed to obtain a context information score. When the score is higher than a preset threshold, the node is taken as the pruning boundary. If the score is not higher than the threshold, the node is retained and its downstream call path is traversed.

5. The method for semantic deobfuscating Android application identifiers based on structure guidance as described in claim 1, characterized in that, The step of writing known third-party library identifier semantics and resource identifier semantics into reserved nodes to obtain a context-enhanced function call graph includes: Writing known third-party library identifier semantics into reserved nodes includes: replacing obfuscated third-party library identifiers in reserved nodes with package mapping, class mapping, and method mapping, and writing the identifiable third-party library names as stable semantics into the node context, thereby achieving third-party library semantic enhancement; Writing resource identifier semantics into the reserved nodes includes: parsing Android resource files, restoring the resource index to the resource type and resource name, and adding the restored resource semantics to the method node that accesses the resource, resulting in a context-enhanced function call graph that simultaneously contains the call structure, external interface semantics, third-party library semantics, and resource semantics.

6. The method for semantic deobfuscating Android application identifiers based on structure guidance as described in claim 1, characterized in that, The step of determining the bottom-up method analysis order based on the call dependencies in the context-enhanced function call graph includes: Identify method nodes with circular call relationships and aggregate them into strongly connected components; Construct a directed acyclic graph based on strongly connected components; The strongly connected components are processed from bottom to top according to the directed acyclic graph, and a first round of analysis and a conditional second round of analysis are performed on the method nodes in a single strongly connected component. In the first iteration, method nodes are selected in order of increasing number of unanalyzed called methods, semantic reasoning is performed on the selected method nodes, and the reasoning results are updated to the caller nodes within the strongly connected components; After completing the first round of iterations, identify method nodes that still have unresolved dependencies, and use the context within the strongly connected components formed in the first round of iterations to perform a second round of semantic reasoning on the method nodes. The analysis of the strongly connected component is stopped when there are no method nodes whose context is incomplete due to unresolved intra-component dependencies, or when further iterations no longer obtain new intra-component context.

7. The method for semantic deobfuscating Android application identifiers based on structure guidance as described in claim 1, characterized in that, The coverage consistency check includes dividing method coverage groups according to the class inheritance graph and the method signature consisting of method name and parameter type, so that methods in the same coverage group use the same name; when there are external application interface methods or exact third-party library methods in the coverage group, their known names are used. Method signature uniqueness check includes collecting non-private methods of various inheritances from bottom to top according to class hierarchy, detecting potential conflicts for methods that do not belong to the same coverage group but use the same name and parameter type, and reselecting different candidate names for conflicting methods.

8. A structure-guided Android application identifier semantic deobfuscation system, characterized in that, include: The program structure extraction module is used to parse and perform static analysis on the target Android application installation package, extract the program structure, construct a function call graph, and obtain the identifier mapping of third-party libraries. The graph optimization and context enhancement module is used to classify the source of method nodes in the function call graph, selectively prune method nodes of different categories, and write the known identifier semantics of third-party libraries and resource identifier semantics into the retained nodes to obtain the context-enhanced function call graph. The method and field recovery and constraint module is used to determine the bottom-up method node analysis order based on the call dependency relationship in the context-enhanced function call graph; according to the method node analysis order, a structured context is constructed for the method node to be recovered, the structured context is input into the large language model to obtain the candidate method name, candidate field name and behavior description of the current method, the obtained recovered name and behavior description are propagated to the caller along the call dependency relationship, and the coverage relationship consistency constraint and method signature uniqueness constraint are executed on the candidate method name; The class and package recovery and constraint module is used to construct class-level contexts and package-level contexts based on the named and constrained method names, field names and behavior descriptions, obtain candidate class names and candidate package names in sequence, and perform uniqueness constraints on the candidate class names, candidate field names and candidate package names within their respective scopes. The legality verification and reconstruction module is used to perform Java identifier legality verification on the identifiers that have passed the consistency constraints of the coverage relationship, the uniqueness constraints of the method signature, and the uniqueness constraints of each scope, generate an identifier mapping, use the identifier mapping to replace the obfuscated identifiers in the target Android application, and reconstruct to obtain the deobfuscated Android application installation package.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps in the structure-guided Android application identifier semantic deobfuscation method as described in any one of claims 1-7.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the structure-guided Android application identifier semantic deobfuscation method as described in any one of claims 1-7.

Images