Android attack surface exploration method based on AOSP static analysis

Abstract

The invention discloses an Android attack surface exploration method based on AOSP static analysis, and belongs to the field of mobile terminal security analysis. Comprising an attack point list acquisition module, a file system traversal module and a service dependency relationship generation module. The attack point list acquisition module extracts an AIDL interface method list through a compilation command tracking technology, identifies Content Provider and Broadcast attack points by using a static analysis technology, and generates a detailed attack point information list; the file system traversal module traverses a complete file system through a root permission, and screens user-mode accessible files in combination with the file permission; and the service dependency relationship generation module constructs a dependency relationship graph between the service interfaces by combining the generation dependency relationship and the variable dependency relationship. According to the method, the potential attack points of the Android system can be comprehensively and systematically identified, the dependency relationship between the interface and the service is established, and support is provided for vulnerability mining, security audit and authority management optimization.

Description

Technical Field

[0001] The present invention belongs to the field of mobile terminal security analysis, and specifically provides an Android attack surface exploration method based on AOSP static analysis, which can comprehensively and systematically identify potential attack points of the Android system, establish dependencies between interfaces and services, and provide theoretical and data support for vulnerability mining, security auditing, and permission management optimization. Background Art

[0002] With the rapid development of mobile Internet, Android has become one of the most widely used mobile operating systems in the world. However, due to its openness and complex system architecture, Android faces more and more security threats. Attackers often attack the system by exploiting the exposed attack surfaces in the system (such as services, content providers, broadcast mechanisms, and file systems), thereby causing sensitive data leakage or permission abuse. Therefore, comprehensive and accurate identification of attack surfaces in the Android system is of great significance to improving the overall security of the system.

[0003] However, there are still some obvious problems with the existing methods as a whole. First, the completeness is insufficient. Some studies only analyze possible attack service types and fail to fully cover all potential attack points, resulting in obvious omissions in the attack point list. Second, the analysis is not deep enough. The research on key components mostly stays on the surface, without deeply analyzing the specific implementation details and registration information of the service, which makes it easy to miss key attack points or misjudge the actual attack surface of the system. In addition, the analysis accuracy is low. The existing methods mainly rely on the abstract syntax tree (AST) for dependency analysis, but do not use more accurate static analysis technology, resulting in a high error rate in the constructed dependency graph, which makes it difficult to accurately reflect the true dependency between services. Summary of the invention

[0004] In view of the above-mentioned problems of the prior art, the purpose of the present invention is to provide an Android attack surface exploration method based on AOSP static analysis, which effectively solves the problem of insufficient coverage of the prior art through high-precision in-depth static analysis and type relationship parsing; and solves the problem of inaccurate service call chain by generating dependency and variable dependency modeling.

[0005] In order to achieve the above object, the present invention adopts the following technical solution:

[0006] The present invention provides an Android attack surface exploration method based on AOSP static analysis, comprising the following steps:

[0007] Step 1: Trace the compilation commands of the AOSP source code, obtain the system commands called during the compilation process through eBPF dynamic monitoring technology, and extract the AIDL interface method list.

[0008] Step 2: Based on the AIDL file path extracted in step 1, combine the data flow static analysis to identify the Content Provider and Broadcast attack points in the AOSP code, and generate a list containing detailed attack point information.

[0009] Step 3: Traverse the file system, identify all files accessible to user mode, and generate a list of file system attack points, including file paths and access permission information.

[0010] Step 4: Based on the AIDL file extracted in step 1, use type analysis technology, combined with generation dependency and variable dependency, to build a dependency graph between service interfaces, including interface generation relationship and call parameter dependency information.

[0011] In the above scheme, step 1 includes:

[0012] Step 1.1: Use eBPF technology to monitor the execve system call in the Linux kernel, capture the commands executed during the compilation process, and record the command line parameters and related context information.

[0013] Step 1.2: Filter the captured compilation commands, select the records containing AIDL compilation commands, and extract the path information of the AIDL file.

[0014] Step 1.3: Parse the extracted AIDL file, generate a list of all interfaces and their methods through syntax analysis, and record the method signatures and return value types.

[0015] In the above scheme, step 2 includes:

[0016] Step 2.1. Statically analyze the AOSP source code, identify non-abstract classes that inherit from android.content.ContentProvider, and extract the class names of these classes.

[0017] Step 2.2: Combined with the AndroidManifest.xml file, match each Content Provider class, extract its authority information and configured access rights, and generate a Content Provider attack point list containing the class name and authority.

[0018] Step 2.3: By statically analyzing the points in the code that call sendBroadcast, sendOrderedBroadcast, and their variants, extract the broadcast sending points and their permission fields, and generate a list of broadcast attack points, including the sending point location and the configured receiver permissions.

[0019] In the above scheme, step 3 includes:

[0020] Step 3.1: Use a user-mode process with root privileges to traverse the entire file system, recursively access all directories in the system and record the file paths;

[0021] Step 3.2: Verify the file type, permissions, and user group by calling the lstat function, and filter out files accessible to user-mode processes;

[0022] Step 3.3: Combined with the permission information, classify the files and generate a list of file system attack points including file paths and permissions. The categories include readable, writable, executable, SELinux content, etc.

[0023] In the above scheme, step 4 includes:

[0024] Step 4.1, analyze the Java source code corresponding to AIDL, get all the implemented interfaces and parent classes of the AIDL implementation class and return value, interface B implemented by A and parent class C, called A is a subtype of B, A is a subtype of C. Subtypes are transitive. This means that subtypes can be used directly as parent types; parent types can be forced to be converted into subtypes. Thus, a subtype relationship tree is obtained.

[0025] Step 4.2: Based on the return value type of the interface in step 1.3 and the subtype relationship in step 4.1, analyze the generation dependency of the interface object and construct a generation dependency graph; if the object returned by interface A is a subtype of interface B, interface A is considered to be dependent on interface B;

[0026] Step 4.3: Use the large language model to analyze the variable dependency between each pair of interfaces. By inputting the interface name, document comments and parameter information, determine whether the parameters of one interface need to be generated by the return value of another interface, and extract the dependency. Use natural language processing capabilities to automatically identify the complex relationship between interfaces, breaking through the limitations of traditional methods on annotation and parameter meaning analysis. ;

[0027] Step 4.4: Integrate the generated dependencies and variable dependencies to build a complete service dependency graph to display the call chain between services and their dependency hierarchy.

[0028] In the above scheme, step 4.2 includes:

[0029] Step 4.2.1: Analyze the AOSP source code statically to parse the class type inheritance relationship and interface implementation relationship.

[0030] Construct the type-subtype relationship diagram of the class, including: parent-subclass relationship, interface implementation relationship;

[0031] Step 4.1.2: Analyze and generate dependencies. If the method return value type of interface A is a subtype of interface B (Foo: <B), interface A is considered to be dependent on interface B. If the parent type of the method return value type of interface A contains interface B (B: <Foo), interface A is also considered to be dependent on interface B. Check the mandatory type conversion in the code to verify whether there is a type conversion generated dependency.

[0032] Step 4.1.3: Construct a generation dependency graph. Use the return value type of the interface method and the subtype relationship of other interfaces to construct a generation dependency graph. Each node in the graph represents an interface method, and the edge represents the generation dependency relationship between methods. The dependency graph is represented by the following formula:

[0033] E=\{(v i , v j )∨O j :<F i ∨F i :<O j}

[0034] Among them, v i and v j Respectively represent interface methods, O j and F i They respectively represent the return value type of the interface method and its dependencies, and “:<” represents a subtype relationship.

[0035] Compared with the prior art, the present invention has the following beneficial effects:

[0036] 1. Through comprehensive static analysis of AOSP source code, the present invention can obtain a complete list of attack points including system services, content providers, broadcast sending points, and user-mode accessible files, thereby avoiding the problem of missing key attack points due to insufficient coverage in the prior art.

[0037] Second, the present invention deeply analyzes the implementation details and registration information of the service, combines the Manifest file and other configuration data, ensures that the description of the attack point is more accurate and comprehensive, and reduces the misjudgment caused by superficial analysis.

[0038] 3. The present invention adopts precise static analysis technology and type analysis method, replacing the traditional low-precision method based on abstract syntax tree, constructs service dependency graph from two dimensions of generation dependency and variable dependency, and significantly improves the accuracy of dependency analysis.

[0039] 4. By generating a comprehensive attack surface list and a high-precision dependency graph, the present invention provides detailed data support and theoretical basis for security protection measures such as sandbox perception detection and privacy leakage vulnerability mining, and has high practical application value. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is the overall architecture diagram of the present invention; DETAILED DESCRIPTION

[0041] The following is a detailed description of the embodiments of the present invention. Although the present invention will be described and illustrated in conjunction with some specific embodiments, it should be noted that the present invention is not limited to these embodiments. On the contrary, modifications or equivalent substitutions made to the present invention should all be included in the scope of the claims of the present invention.

[0042] In addition, in order to better illustrate the present invention, numerous specific details are given in the following specific embodiments. It will be understood by those skilled in the art that the present invention can also be implemented without these specific details.

[0043] The present invention provides an Android attack surface exploration method based on AOSP static analysis, comprising the following steps:

[0044] Step 1: Track the compilation commands of the AOSP source code, obtain the system commands called during the compilation process through dynamic monitoring technology, and extract the AIDL interface method list.

[0045] Step 2: Based on the AIDL file path extracted in step 1, combined with static analysis technology, identify the Content Provider and Broadcast attack points in the AOSP code, and generate a list containing detailed attack point information.

[0046] Step 3: Traverse the file system, identify all files accessible to user mode, and generate a list of file system attack points, including file paths and access permission information.

[0047] Step 4: Based on the AIDL file extracted in step 1, use type analysis technology, combined with generation dependency and variable dependency, to build a dependency graph between service interfaces, including interface generation relationship and call parameter dependency information.

[0048] In the above scheme, step 1 includes:

[0049] Step 1.1: Use eBPF technology to monitor the execve system call in the Linux kernel, capture the commands executed during the compilation process, and record the command line parameters and related context information.

[0050] Step 1.2: Filter the captured compilation commands through string matching, filter out the records containing AIDL compilation commands, and extract the path information of the AIDL file.

[0051] Step 1.3: Parse the extracted AIDL file, write the tree-sitter grammar rules of AIDL, obtain the abstract syntax tree of AIDL through tree-sitter analysis, further analyze the abstract syntax tree to obtain a list of all interfaces and their methods, and record the method signature and return value type.

[0052] In the above scheme, step 2 includes:

[0053] Step 2.1: Use the CodeQL tool to statically analyze the AOSP source code, find non-abstract classes that inherit from android.content.ContentProvider, and extract the class names of these classes. CodeQL is an advanced analysis tool based on logical queries, which supports deep mining of code structure and data flow, greatly improving the accuracy and efficiency of analysis.

[0054] Step 2.2: Combined with the AndroidManifest.xml file, match each Content Provider class, extract its authority information and configured access rights, and generate a ContentProvider attack point list containing the class name and authority.

[0055] Step 2.3: Use CodeQL to perform data flow analysis to find the points in the AOSP source code that call sendBroadcast, sendOrderedBroadcast, and their variants, extract the broadcast sending points and their permission fields, and generate a list of broadcast attack points, including the sending point location and the configured receiver permissions. Using the data flow analysis function of CodeQL, the code location of calling sendBroadcast and its variants is accurately located, and the permission configuration is analyzed, overcoming the shortcomings of traditional analysis methods that are prone to missing key information in complex call chains.

[0056] In the above scheme, step 3 includes:

[0057] Step 3.1: Use a user-mode process with root privileges to traverse the entire file system, recursively access all directories in the system and record the file paths;

[0058] Step 3.2: Verify the file type, permissions, and user group by calling the lstat function, and filter out files accessible to user-mode processes;

[0059] Step 3.3: Combined with the permission information, classify the files and generate a list of file system attack points including file paths and permissions. The categories include readable, writable, executable, SELinux content, etc.

[0060] In the above scheme, step 4 includes:

[0061] Step 4.1, analyze the Java source code corresponding to AIDL according to the interface implementation relationship, and obtain all the implemented interfaces and parent classes of the AIDL implementation class and return value through CodeQL query. Interface B implemented by A and parent class C are called A is a subtype of B and A is a subtype of C. Subtypes are transitive. This means that subtypes can be used directly as parent types; parent types can be forced to be converted into subtypes. Thus, a subtype relationship tree is obtained.

[0062] Step 4.2: Based on the return value type of the interface in step 1.3 and the subtype relationship in step 4.1, analyze the generation dependency of the interface object and construct a generation dependency graph; if the object returned by interface A is a subtype of interface B, interface A is considered to be dependent on interface B;

[0063] Step 4.3: Use the large language model to analyze the variable dependency between each pair of interfaces. By inputting the interface name, document comments and parameter information, determine whether the parameters of one interface need to be generated by the return value of another interface, and extract the dependency. The complex relationship between interfaces can be automatically identified through natural language processing capabilities. The traditional method relies on manual analysis and is inefficient.

[0064] Step 4.4: Integrate the generated dependencies and variable dependencies to build a complete service dependency graph to display the call chain between services and their dependency hierarchy.

[0065] In the above scheme, step 4.2 includes:

[0066] Step 4.2.1. Use CodeQL to statically analyze the AOSP source code, parse the class type inheritance relationship and interface implementation relationship, and build a class type subtype relationship diagram, including: parent class and subclass relationship, interface implementation relationship. CodeQL-based type relationship analysis can accurately identify complex inheritance and dependency relationships, significantly improving the accuracy of dependency analysis;

[0067] Step 4.1.2: Analyze and generate dependencies. If the method return value type of interface A is a subtype of interface B (Foo: <B), interface A is considered to be dependent on interface B. If the parent type of the method return value type of interface A contains interface B (B: <Foo), interface A is also considered to be dependent on interface B. Check the mandatory type conversion in the code to verify whether there is a type conversion generated dependency.

[0068] Step 4.1.3: Construct a generation dependency graph. Use the return value type of the interface method and the subtype relationship of other interfaces to construct a generation dependency graph. Each node in the graph represents an interface method, and the edge represents the generation dependency relationship between methods. The dependency graph is represented by the following formula:

[0069] E=\{(v i , v j )∨O j :<F i ∨F i :<O j}

[0070] Among them, v i and v j Respectively represent interface methods, O j and F i They represent the return value type of the interface method and its dependencies respectively, and “:<” represents the subtype relationship; a complete service dependency graph including generation dependencies and variable dependencies is constructed, which clearly shows the call chain and hierarchical relationship between interfaces, providing an intuitive basis for security analysis.

Claims

1. An Android attack surface exploration method based on AOSP static analysis, characterized in that: The following steps are involved: Step 1: Track the compilation commands of the AOSP source code, obtain the system commands called during the compilation process through dynamic monitoring technology, and extract the AIDL interface method list; Step 2: Based on the AIDL file path extracted in step 1, combined with static analysis technology, identify the Content Provider and Broadcast attack points in the AOSP code, and generate a list containing detailed attack point information; Step 3: Traverse the file system, identify all files accessible to user mode, and generate a list of file system attack points, including file paths and access rights information; Step 4: Based on the AIDL file extracted in step 1, use type analysis technology, combined with generation dependency and variable dependency, to build a dependency graph between service interfaces, including interface generation relationship and call parameter dependency information.

2. According to claim 1, an Android attack surface exploration method based on AOSP static analysis is characterized in that: Step 1 includes: Step 1.1: Use eBPF technology to monitor the execve system call in the Linux kernel, capture the commands executed during the compilation process, and record the command line parameters and related context information; Step 1.2: Filter the captured compilation commands, select the records containing AIDL compilation commands, and extract the path information of the AIDL files; Step 1.3: Parse the extracted AIDL file, generate a list of all interfaces and their methods through syntax analysis, and record the method signatures and return value types.

3. The Android attack surface exploration method based on AOSP static analysis according to claim 1, characterized in that: Step 2 includes: Step 2.1, statically analyze the AOSP source code, identify non-abstract classes inherited from android.content.ContentProvider, and extract the class names of these classes; Step 2.2, combined with the AndroidManifest.xml file, match each Content Provider class, extract its authority information and configured access rights, and generate a Content that contains the class name and authority Provider attack point list; Step 2.3: By statically analyzing the points in the code that call sendBroadcast, sendOrderedBroadcast, and their variants, extract the broadcast sending points and their permission fields, and generate a list of broadcast attack points, including the sending point location and the configured receiver permissions.

4. The Android attack surface exploration method based on AOSP static analysis according to claim 1, characterized in that: Step 3 includes: Step 3.1: Use a user-mode process with root privileges to traverse the entire file system, recursively access all directories in the system and record the file paths; Step 3.2: Verify the file type, permissions, and user group by calling the lstat function, and filter out files accessible to user-mode processes; Step 3.3: Combined with the permission information, classify the files and generate a list of file system attack points including file paths and permissions. The categories include readable, writable, executable, SELinux content, etc.

5. The Android attack surface exploration method based on AOSP static analysis according to claim 1, characterized in that: Step 4 includes: Step 4.1, analyze the Java source code corresponding to AIDL, get all the implemented interfaces and parent classes of the AIDL implementation class and return value, interface B implemented by A and parent class C, called A is a subtype of B, A is a subtype of C. Subtypes are transitive. This means that subtypes can be used directly as parent types; parent types can be forced to be converted into subtypes. Thus, a subtype relationship tree is obtained. Step 4.2: Based on the return value type of the interface in step 1.3 and the subtype relationship in step 4.1, analyze the generation dependency of the interface object and construct a generation dependency graph; if the object returned by interface A is a subtype of interface B, interface A is considered to be dependent on interface B; Step 4.3: Use the large language model to analyze the variable dependency between each pair of interfaces. By inputting the interface name, document comments and parameter information, determine whether the parameters of one interface need to be generated by the return value of another interface, and extract the dependency. Use natural language processing capabilities to automatically identify the complex relationship between interfaces, breaking through the limitations of traditional methods on annotation and parameter meaning analysis. ; Step 4.4: Integrate the generated dependencies and variable dependencies to build a complete service dependency graph to display the call chain between services and their dependency hierarchy.

6. The Android attack surface exploration method based on AOSP static analysis according to claim 1, characterized in that: Step 4.2 includes: Step 4.2.1, by statically analyzing the AOSP source code, parsing the class type inheritance relationship and the interface implementation relationship, constructing the class type subtype relationship diagram, including: parent class and subclass relationship, interface implementation relationship; Step 4.1.2: Analyze and generate dependencies. If the method return value type of interface A is a subtype of interface B (Foo: <B), interface A is considered to be dependent on interface B. If the parent type of the method return value type of interface A contains interface B (B: <Foo), interface A is also considered to be dependent on interface B. Check the mandatory type conversion in the code to verify whether there is a type conversion generated dependency. Step 4.1.3: Construct a generation dependency graph. Use the return value type of the interface method and the subtype relationship of other interfaces to construct a generation dependency graph. Each node in the graph represents an interface method, and the edge represents the generation dependency relationship between methods. The dependency graph is represented by the following formula: E=\{(v i ,v j )∨O j :<F i ∨F i :<O j } Among them, v i and v j Respectively represent interface methods, O j and F i They represent the return value type of the interface method and its dependencies respectively, and ":<" represents the subtype relationship.

Images