An Android software static analysis method based on hybrid mode

Abstract

This invention proposes a hybrid-mode-based static analysis method for Android software, belonging to the field of malware analysis technology. It primarily addresses the accuracy degradation problem caused by existing Android cross-language static analysis frameworks using function digests for inter-function data flow connections. The main solutions include: function-level data flow analysis of the Android Java layer; lightweight inter-function data dependency analysis of the Android Native layer, generating dynamic function digests for each function; and full-program data flow analysis of the Android Java layer, where data flow connections involving Native function calls are reconstructed using function digests.

Description

Technical Field

[0001] This invention relates to security software, and more particularly to a static analysis method for Android software based on a hybrid model. Background Technology

[0002] Mobile devices and smartphones have become an indispensable part of people's daily lives. As of December 2022, Android phones held a 71.96% market share. The widespread use of Android devices among consumers has made Android software a prime target for hackers, posing higher demands on the privacy and financial security of Android users.

[0003] Taint analysis in static analysis is an important technique for detecting program privacy leaks. It tracks the flow of sensitive data in the program by marking points in the data flow graph as data source points or data leakage points. Android software is typically written in Java and native code (C / C++), which requires static analysis techniques for Android software to have cross-language program analysis capabilities that can simultaneously analyze Java bytecode and native code binary libraries, and analyze the data flow relationships between them. Currently, there is some research on cross-language static analysis of Android. Based on the algorithms used for data flow analysis between functions, current research can be classified into two categories: function summary analysis and full-program analysis.

[0004] In the paper "JuCify: a step towards Android code unification for enhanced static analysis," Jordan et al. performed taint analysis by constructing a unified dataflow graph. It uses decompilation tools to convert Java bytecode into Jimple intermediate code; it collects information about entry and exit points in native functions using symbolic execution techniques, and uses this key information to construct virtual Java pseudocode, which is then converted into Jimple intermediate code; it achieves a unified intermediate code format, and uses FlowDroid to perform dataflow taint analysis on the unified model. JuCiFy adds a large amount of noise to the native-Jimple intermediate code to ensure the reliability of loops, branching statements, and other situations. This behavior leads to JuCiFy potentially generating multiple tainted paths for a single genuine tainted path, resulting in path explosion.

[0005] In the paper "JN-SAF: Precise and Efficient NDK / JNI-aware Inter-language Static Analysis Framework for Security Vetting of Android Applications with Native Code," Wei et al. used function summaries to describe the data flow relationship between function entry and exit points, thus achieving data flow connection between Java and native functions. For native code, JN-SAF employs symbolic execution technology provided by Angr, inputting function entry points as special symbols into the simulated execution task. After the simulation is complete, the relationship between the entry and exit points is determined through the state information of the function exit points, enabling the calculation of the native function's summary. For Java code, JN-SAF calculates the function summary using the data flow analysis capabilities provided by its predecessor, Amandroid. This method of describing function information and connecting functions through function summaries discards function information, reducing the accuracy of data flow analysis. In JN-SAF, this manifests as the inability to analyze global variables within Java classes and global variables in native functions. Summary of the Invention

[0006] To address the aforementioned issues, this invention aims to propose a static analysis method and system for Android software that combines full-process and function digest modes. This method enables cross-language (Java and Native) static analysis of Android APK format software, effectively and completely extracting the data flow propagation behavior of Android software, thus allowing for more accurate data flow analysis. It can construct more accurate cross-language data flow graphs and capture sensitive information transmission behavior. Furthermore, it ensures that the static analysis algorithm has the accuracy of full-program analysis at the Java layer while possessing the accuracy and efficiency of full-program function digest analysis at the Native layer.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A static analysis method for Android software based on hybrid modes includes the following steps:

[0009] Step 1: Unzip the Android system APK file to obtain the Java bytecode file, native binary file, and related configuration files;

[0010] Step 2: Decompile the Java bytecode file and related configuration files obtained in Step 1 using the apktool library and convert them into jawa intermediate language code to obtain information about the Java layer code. Then, use static analysis tools to generate function call graphs and data flow graphs within functions for the Java layer code.

[0011] Step 3: Decompile the Native binary files and related configuration files obtained in Step 1 using Angr to obtain Native functions, generate a control flow graph within each Native function, and collect global variable information from each Native binary file;

[0012] Step 4: Using the function control flow graph generated in Step 3 and the global variable information collected in Step 3, symbolic execution techniques are used on each function control flow graph to obtain a lightweight data dependency graph.

[0013] Step 5: Using the lightweight data dependency graph of functions generated in Step 4 and the global variable information collected in Step 3, construct a lightweight data dependency graph between functions using the data flow graph construction algorithm;

[0014] Step 6: Construct a dynamic Native function summary generator using the lightweight inter-function data dependency graph generated in Step 5. This generator provides the ability to generate function summaries for the functions present in the lightweight inter-function data dependency graph. In Step 7, the user specifies the target function to be analyzed and provides the Native function summary generator with the input data stream of the target function. The Native function summary generator generates the output data stream of the target function using the input data stream and the lightweight inter-function data dependency graph, updates the global variable information in the lightweight inter-function data dependency graph, describes the data dependencies between the function's input and output data using a custom domain-specific language, and finally outputs the description result, i.e., the Native function summary.

[0015] Step 7: Based on the function call graph and intra-function data flow graph generated in Step 2, execute cross-function data flow analysis algorithms and cross-language data flow analysis algorithms in the Java layer to construct the data flow graph within the Java-Native cross-language component. The function call graph in the Java layer contains Java function calls and native function calls using JNI. The Java layer cross-function data flow analysis algorithm connects the data flow graphs involving Java function calls. When the Java layer cross-function data flow analysis algorithm encounters a native function call, it inputs the data flow at the time of the call to the native function summary dynamic generator generated in Step 6 to obtain the native function summary. The native data flow is then constructed using the native function summary, achieving cross-language data flow graph connection. The inter-component data flow graph construction algorithm is used to construct the full-process data flow graph of the Android software based on the data flow graph within the Java-Native cross-language component.

[0016] Step 8: Based on the user-defined tainted data source and leakage point, perform Android software taint analysis using the Android software full-process data flow diagram generated in Step 7 to obtain the transmission path of sensitive information in the Android software.

[0017] In the above technical solution, the specific steps of step 2 are as follows:

[0018] For the Java-related configuration files obtained in step 1, extract the information from the configuration files and build a virtual Android Java layer environment for the analysis framework to use;

[0019] For the Java bytecode file obtained in step 1, the apktool library is used to decompile the Java bytecode file and convert it into jawa format intermediate language code; the CHA algorithm is used to analyze the intermediate language code and generate a Java layer function call graph.

[0020] The intermediate language code is analyzed using control flow graph generation and data flow graph generation algorithms to generate data flow graphs within Java layer functions.

[0021] In the above technical solution, step 3 specifically involves the following steps:

[0022] For the configuration files related to the Native binary files obtained in step 1, extract the information from the configuration files and build a virtual Android Native layer environment for the analysis framework to use.

[0023] For the Native binary file obtained in step 1, extract the global variable information and the function names in the file to obtain the Native functions, and generate the control flow graph within each function using the CFGEmulated function provided by Angr.

[0024] In the above technical solution, step 4 specifically involves the following steps:

[0025] For the function control flow graph generated in step 3 in the Native layer, the function entry point is defined as the function parameters, the source of sensitive information, and the code location that reads global variables. The corresponding annotation is attached to the entry point information using the Annotation function provided by Angr. The function is then simulated using Angr symbolic execution. At the end of the symbolic execution, the state of the function exit point is recorded, including the function return value, the sensitive information leakage point, the Native function call point, the Java function call point, and the code location that writes global variables. The data dependency relationship between the function entry point and the exit point is constructed, thereby generating a lightweight data dependency graph of the function.

[0026] In the above technical solution, step 5 specifically involves the following steps:

[0027] For the lightweight data dependency graph of functions generated in step 4, find the native function call points contained in each function, and construct the data dependency relationship between functions through the data dependency information of function callers and function calling objects; find the modifications of global variables by each function, and construct the data dependency relationship involving global variables; construct a lightweight function data dependency graph through the data dependency relationship between functions, the data dependency relationship involving global variables, and the lightweight data dependency graph of functions.

[0028] In the above technical solution, step 6 specifically involves the following steps:

[0029] Construct a dynamic native function summary generator. This generator holds the lightweight inter-function data dependency graph information generated in step 5. The input is the input data stream corresponding to a function call behavior, and the output is a function summary describing the data dependencies between the input and output parameters of the function. The generator runs according to the following algorithm:

[0030] The parameter information from the input native function call is passed to the lightweight function inter-data dependency graph and data dependency analysis is performed to obtain the program state after the native function is executed by this function call. The data dependency relationship between the function entry point and exit point mentioned in the specific steps of step 4 is extracted from it. The exit point in this step does not include the native function call point. The data dependency relationship is classified and filtered according to different exit points. The data dependency relationship with global variables as the exit point is used to update the global variable information in the lightweight function inter-data dependency graph. The data dependency relationship of the other three exit points is described as a native function summary in a custom domain-specific language and output.

[0031] In the above technical solution, step 7 specifically involves the following steps:

[0032] For the Java layer function call graph generated in step 2, the data flow relationship between functions is constructed through the function call relationship. In this process, when Java code calls a native function through JNI, the function call information is passed to the function summary generator built in step 6. The function summary returned by the generator is used to construct the data flow relationship for three cases: leakage of sensitive information of native function, native layer returning Java, and native calling Java function through JNI. This realizes the construction of the cross-layer part of the cross-language data flow graph. The data flow graph between functions is constructed through the data flow graph within the Java layer function generated in step 2. The cross-component data flow graph is constructed through the component call information between the Java layer and the native layer extracted from the data flow graph between functions. Finally, the full-process data flow graph of Android software is constructed.

[0033] In the above technical solution, step 8 specifically involves traversing the Android software full-process data flow graph generated in step 7, marking the tainted data sources and leakage point functions that conform to the user-defined tainted data sources as source points or leakage points, querying the paths from source points to leakage points in the data flow graph using the Dijkstra algorithm, and finally obtaining the sensitive information transmission path of the Android software.

[0034] Compared with the prior art, the beneficial effects of this invention are as follows:

[0035] I. This invention proposes a static analysis method for Android software based on a hybrid mode, which combines two common modes in cross-language analysis of Android software, avoiding the precision loss problem caused by Java layer function summary analysis, while retaining the high efficiency of Native layer function summary analysis.

[0036] Second, this invention addresses the problem in existing technologies that cannot analyze data flows involving Native global variables. By adding global variable information to a lightweight cross-function data dependency graph in Native, the accuracy of Native function summary analysis is improved. This invention enables the discovery of sensitive data propagation chains that spread through Native global variables, thereby improving the accuracy of Android software taint analysis. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the overall workflow of the present invention. Detailed Implementation

[0038] To clearly demonstrate the purpose, technical solution, and advantages of this invention, examples are provided below.

[0039] This invention is a method and system for detecting the flow of sensitive information data in Android software. The expected input of this invention is an Android APK format file, and the output is zero to multiple sensitive information propagation paths, with a line of intermediate code as a node, the data flow direction as an edge, the source of sensitive information as the starting point, and the leakage of sensitive information as the ending point.

[0040]

Example 1

[0041] Input: A manually written test sample APK file to demonstrate the cross-language analysis capability based on hybrid mode of this invention. In this file, functions involved in the propagation of sensitive information include the Java layer functions `foo` and `bar` within the same component, and the Native layer function `n1`. The function call relationship is: `foo` calls `n1`, then `n1` calls `bar`. Function `foo` uses `getDeviceId` to obtain the device ID information and passes the sensitive information data to `n1` and `bar` through function call parameters. Finally, `bar` uses the `printf` function to store the device ID information in a file.

[0042] Expected output: A path recording the propagation from the source of sensitive information to the point of leakage of sensitive information, in the following format: getDeviceId -> intermediate node -> call n1 -> intermediate node -> call bar -> intermediate node -> printf.

[0043] Step 1: Unzip the input APK and extract the Java bytecode files, native binary files, and other configuration files.

[0044] Step 2: Analyze the data flow within the Java layer execution function, specifically including the following steps:

[0045] Step 2.1: Use the apktool library to decompile the Java bytecode file extracted in Step 1 into jawa format intermediate language code, and build a virtual Android Java layer environment using the Java layer-related configuration files extracted in Step 1.

[0046] Step 2.2: Apply the CHA algorithm to the intermediate language code generated in Step 2.1 to generate a function call graph.

[0047] Step 2.3: Apply the reachability analysis algorithm to the intermediate language code generated in Step 2.1 to generate a data flow graph within the function.

[0048] After step 2, the intermediate state of the program is as follows: the function call graph shows foo calling n1, and bar exists alone; at the same time, the program has the data flow graphs within the functions foo and bar.

[0049] Step 3: Perform file-level inter-function data dependency analysis on the Native layer on a binary file basis. Therefore, the following specific steps will be executed multiple times for multiple Native layer binary files, including the following steps:

[0050] Step 3.1: Construct a virtual Android Native layer environment based on the Native binary files and Native layer-related configuration files extracted in Step 1, and extract all Native function entry points and all global variable information using Angr.

[0051] Step 3.2: Based on the entry point of each Native function extracted in Step 3.1, generate a control flow graph for each function using the CFGEmulated function provided by the Angr library.

[0052] Step 3.3: Use the Angr annotation function to simulate execution on the control flow graph generated in step 3.2, and construct a lightweight data dependency graph within the function based on the information of the function entry point and exit point.

[0053] Step 3.4: Construct a file-level inter-function data dependency graph based on the global variable information collected in Step 3.1 and the lightweight intra-function data dependency graph generated in Step 3.3.

[0054] After step 3, the intermediate state of the program is as follows: the function call graph is foo calling n1, and bar exists alone; at the same time, the program has the data flow graphs within the functions foo and bar, as well as the lightweight data dependency graph of function n1.

[0055] Step 4: Construct the Java-Native cross-language component data flow graph, which includes the following steps:

[0056] Step 4.1: Traverse the function call graph generated in Step 2.2. Fill each Java function node with the intra-function data flow graph generated in Step 2.3. Use the data flow connection algorithm to process the call edges between functions and construct the inter-function data flow graph.

[0057] Step 4.2: When a node that uses JNI to make a native function call is encountered during the traversal in Step 4.1, a request to analyze the function is sent to the Native Analysis Server that holds the result of Step 3. The Native Analysis Server constructs a function summary of the target function through the data dependency graph generated in Step 3.4 and returns the result.

[0058] Step 4.3: The function digests generated in Step 4.2 can be categorized into three types based on the data flow. The first type involves native functions that do not return values ​​to Java and whose data flow terminates at the native function. This invention addresses this by constructing a terminated native data flow at the Java layer. The second type involves native functions that do not return values ​​to Java and call another Java layer function via JNI. This invention addresses this by analyzing the function digest to construct a data flow from Java to native and back to Java, and by reconstructing the control flow from native to Java that could not be analyzed in Step 2.2 through simulated indirect calls. The third type involves native functions that return values ​​to Java. This invention addresses this by constructing a native data flow that returns to the Java layer at the Java layer.

[0059] After step 4, the intermediate state of the program is as follows: the function call graph is foo calling n1, and n1 calling bar; at the same time, the program has the data flow graphs within the functions foo and bar, as well as the lightweight data dependency graph of function n1.

[0060] Step 5: By extracting the cross-component call information from the cross-language data flow graph generated in Step 4, establish the data flow connection relationship between Android software components and construct a cross-language, cross-component full Android software data flow graph.

[0061] Step 6: Query all sensitive information sources and leakage point functions in the program, use Dijkstra's algorithm to find the paths between these points and output them.

[0062] After step 6, the program output is the same as expected.

[0063]

Example 2

[0064] Input: A manually written test sample APK file to demonstrate the ability of this invention to detect native global variable data streams. In this file, functions involved in the propagation of sensitive information include the Java layer functions `foo` and `bar`, the Native layer functions `n1` and `n2` within the same binary file, and the global variable `g1`. The function call relationship is that `foo` calls `n1` and then `n2`. Function `foo` uses `getDeviceId` to obtain the device ID information and passes the sensitive information data to `n1` through function call parameters. `n1` stores the sensitive information in `g1`. When `foo` calls `n2`, `n2` reads the information from `g1` and stores the device ID information in a file using the `printf` function.

[0065] Expected output: A propagation path that records the sensitive information from the source to the point of leakage, specifically in the format: getDeviceId -> intermediate node -> call n1 -> intermediate node -> g1 -> call n2 -> read g1 -> printf.

[0066] Step 1: Same as in Example 1

[0067] Step 2: Same as in Example 1

[0068] After step 2, the intermediate state of the program is as follows: the function call graph shows foo calling n1 and foo calling n2; at the same time, the program has the data flow graph inside the function foo.

[0069] Step 3: Same as in Example 1

[0070] After step 3, the intermediate state of the program is as follows: the function call graph is foo calling n1, and foo calling n2; at the same time, the program has the data flow graph inside the function foo, as well as the lightweight data dependency graphs of functions n1 and n2.

[0071] Step 4: Same as in Example 1

[0072] After step 4, the intermediate state of the program is as follows: the function call graph is foo calling n1, and foo calling n2; at the same time, the program has the data flow graph within the function foo, as well as a lightweight data dependency graph from n1 to g1 and then to n2.

[0073] Step 5: Same as in Example 1

[0074] Step 6: Same as in Example 1

[0075] After step 6, the program output is the same as expected.

Claims

1. A static analysis method for Android software based on a hybrid mode, characterized in that, Includes the following steps: Step 1: Unzip the Android system APK file to obtain the Java bytecode file, native binary file, and related configuration files; Step 2: Decompile the Java bytecode file and related configuration files obtained in Step 1 using the apktool library and convert them into jawa intermediate language code to obtain information about the Java layer code. Then, use static analysis tools to generate function call graphs and data flow graphs within functions for the Java layer code. Step 3: Decompile the Native binary files and related configuration files obtained in Step 1 using Angr to obtain Native functions, generate a control flow graph within each Native function, and collect global variable information from each Native binary file; Step 4: Using the function control flow graph generated in Step 3 and the global variable information collected in Step 3, symbolic execution techniques are used on each function control flow graph to obtain a lightweight data dependency graph. Step 5: Using the lightweight data dependency graph of functions generated in Step 4 and the global variable information collected in Step 3, construct a lightweight data dependency graph between functions using the data flow graph construction algorithm; Step 6: Construct a Native function summary dynamic generator using the lightweight function dependency graph generated in Step 5. The Native function summary dynamic generator generates the output data stream of the target function through the input data stream and the lightweight function dependency graph, and updates the global variable information in the lightweight function dependency graph. It describes the data dependency relationship between the function input data and output data in a custom domain-specific language, and finally outputs the description result, i.e., the Native function summary. Step 7: Based on the function call graph and function data flow graph generated in Step 2, execute cross-function data flow analysis algorithms and cross-language data flow analysis algorithms in the Java layer to construct a data flow graph within the Java-Native cross-language component. The function call graph in the Java layer contains Java function calls and native function calls using JNI. The Java layer cross-function data flow analysis algorithm connects the data flow graphs involving Java function calls. When the Java layer cross-function data flow analysis algorithm encounters a native function call, it inputs the data flow at the time of the call to the native function summary dynamic generator generated in Step 6 to obtain a native function summary. A native data flow is constructed using the native function summary, achieving cross-language data flow graph connection. Finally, an inter-component data flow graph construction algorithm is used to construct the full-process data flow graph of the Android software based on the data flow graph within the Java-Native cross-language component. Step 8: Based on the user-defined tainted data source and leakage point, perform Android software taint analysis using the Android software full-process data flow diagram generated in Step 7 to obtain the transmission path of sensitive information in the Android software.

2. The method for static analysis of Android software based on a hybrid mode according to claim 1, characterized in that, The specific steps of step 2 are as follows: For the Java-related configuration files obtained in step 1, extract the information from the configuration files and build a virtual Android Java layer environment for the analysis framework to use. For the Java bytecode file obtained in step 1, the apktool library is used to decompile the Java bytecode file and convert it into jawa format intermediate language code; the CHA algorithm is used to analyze the intermediate language code and generate a Java layer function call graph. The intermediate language code is analyzed using control flow graph generation and data flow graph generation algorithms to generate data flow graphs within Java layer functions.

3. The method for static analysis of Android software based on a hybrid mode according to claim 1, characterized in that, The specific steps of step 3 are as follows: For the configuration files related to the Native binary files obtained in step 1, extract the information from the configuration files and build a virtual Android Native layer environment for the analysis framework to use. For the Native binary file obtained in step 1, extract the global variable information and the function names in the file to obtain the Native functions, and generate the control flow graph within each function using the CFGEmulated function provided by Angr.

4. The static analysis method for Android software based on a hybrid mode according to claim 1, characterized in that, The specific steps of step 4 are as follows: For the function control flow graph generated in step 3 in the Native layer, the function entry point is defined as the function parameters, the source of sensitive information, and the code location that reads global variables. The corresponding annotation is attached to the entry point information using the Annotation function provided by Angr. The function is then simulated using Angr symbolic execution. At the end of the symbolic execution, the state of the function exit point is recorded, including the function return value, the sensitive information leakage point, the Native function call point, the Java function call point, and the code location that writes global variables. The data dependency relationship between the function entry point and the exit point is constructed, thereby generating a lightweight data dependency graph of the function.

5. The static analysis method for Android software based on a hybrid mode according to claim 1, characterized in that, The specific steps of step 5 are as follows: For the lightweight data dependency graph of functions generated in step 4, find the native function call points contained in each function, and construct the data dependency relationship between functions through the data dependency information of function callers and function calling objects; find the modifications of global variables by each function, and construct the data dependency relationship involving global variables; construct a lightweight function data dependency graph through the data dependency relationship between functions, the data dependency relationship involving global variables, and the lightweight data dependency graph of functions.

6. The method for static analysis of Android software based on a hybrid mode according to claim 1, characterized in that, The specific steps of step 6 are as follows: Construct a dynamic native function summary generator. This generator holds the lightweight inter-function data dependency graph information generated in step 5. The input is the input data stream corresponding to a function call behavior, and the output is a function summary describing the data dependencies between the input and output parameters of the function. The generator runs according to the following algorithm: The parameter information from the input native function call is passed to the lightweight function inter-data dependency graph and data dependency analysis is performed to obtain the program state after the native function is executed by this function call. The data dependency relationship between the function entry point and exit point mentioned in the specific steps of step 4 is extracted from it. The exit point in this step does not include the native function call point. The data dependency relationship is classified and filtered according to different exit points. The data dependency relationship with global variables as the exit point is used to update the global variable information in the lightweight function inter-data dependency graph. The data dependency relationship of the other three exit points is described as a native function summary in a custom domain-specific language and output.

7. The method for static analysis of Android software based on a hybrid mode according to claim 1, characterized in that, The specific steps of step 7 are as follows: For the Java layer function call graph generated in step 2, the data flow relationship between functions is constructed through the function call relationship. In this process, when Java code calls a native function through JNI, the function call information is passed to the function summary generator built in step 6. The function summary returned by the generator is used to construct the data flow relationship for three cases: leakage of sensitive information of native function, native layer returning Java, and native calling Java function through JNI. This realizes the construction of the cross-layer part of the cross-language data flow graph. The data flow graph between functions is constructed through the data flow graph within the Java layer function generated in step 2. The cross-component data flow graph is constructed through the component call information between the Java layer and the native layer extracted from the data flow graph between functions. Finally, the full-process data flow graph of Android software is constructed.

8. The method for static analysis of Android software based on a hybrid mode according to claim 7, characterized in that, The specific steps of step 8 are as follows: traverse the Android software full-process data flow graph generated in step 7, mark the tainted data sources and leakage point functions that meet the user definition as source points or leakage points, query the path from the source point to the leakage point in the data flow graph through the Dijkstra algorithm, and finally obtain the sensitive information transmission path of the Android software.

Images