A method and system for detecting dynamic and static ANDROID privacy leakage based on data flow analysis

Abstract

The application discloses a kind of based on data stream analysis's dynamic static ANDROID privacy disclosure detection method and system, the source code of target application is traversed to mark source point and sink point.According to source and sink list, static taint analysis is carried out, and potential privacy disclosure data stream is obtained.According to each sink point in potential disclosure data stream, and the dynamic execution result of application program, corresponding slice criterion is generated, and several times of backward slicing are carried out.The code segment generated by slicing is traversed, and whether source point is called is checked.In the above process, the application determines whether the data stream is false positive.Compared with the traditional taint analysis method, the application introduces dynamic program slicing to analyze the data stream twice, can extract the real execution track of application program, and through static taint analysis, a large amount of source and sink redundant information is removed, and the false positive rate of result output is effectively reduced under less system overhead.

Description

Technical Field

[0001] This invention relates to a dynamic and static Android privacy leakage detection method and system based on data flow analysis, belonging to the field of privacy leakage detection technology. Background Technology

[0002] Taint analysis technology has wide applications in the field of data breach detection. This technology first marks data in the target program as tainted or untainted, then monitors the flow of tainted data, and determines whether to taint untainted data according to a pre-defined information flow propagation strategy. When tainted data finally reaches the designated information breach point, it can be determined that the system has violated the information flow strategy. Here, the taint can be called the source, and the designated information breach point can be called the sink.

[0003] Taint analysis techniques are divided into static and dynamic categories. Static taint analysis performs static analysis on all code of a program using methods such as syntax analysis and lexical analysis, based on a custom taint propagation strategy. This method offers very broad code detection coverage and easily detects deeply hidden malicious behavior, but it suffers from path explosion, where false paths easily lead to many false positives. Dynamic taint analysis uses methods such as virtual execution and dynamic instrumentation to detect characteristics of the program during actual execution, resulting in a lower false positive rate, but its code detection coverage is smaller and prone to false negatives. To quickly search for potential leaks in the code without executing the application, researchers often use static taint analysis techniques to examine APK (Android application package) files.

[0004] The goal of static taint analysis is to find the connection between sources and sinks, and defining what constitutes a source and what constitutes a sink is crucial. In the field of privacy leak detection, APIs that acquire user privacy data (Application Programming Interfaces) are typically defined as sources, and APIs that transmit privacy data to external applications are defined as sinks.

[0005] While static taint analysis is cost-effective and has a wide coverage, it often results in a high false positive rate due to its conservative propagation strategy and imprecise modeling of code execution relationships.

[0006] Therefore, overcoming the shortcomings of taint analysis technology and realizing Android privacy leakage detection is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] Objective: To overcome the shortcomings of existing technologies, this invention provides a dynamic and static Android privacy leakage detection method and system based on data flow analysis. It combines static taint detection and dynamic program slicing techniques to perform secondary analysis on the data flow. By performing false positive checks after dynamic execution, the probability of false alarms is reduced, thereby improving the accuracy of leakage detection while minimizing the additional system overhead.

[0008] Technical solution: To solve the above technical problems, the technical solution adopted by the present invention is as follows: Firstly, a dynamic and static Android privacy leakage detection method based on data flow analysis includes the following steps: Step 1: Obtain the source code of the Android application to be tested, traverse all classes and their sub-functions in the source code, mark the functions that obtain sensitive information as source points, and mark the functions that send sensitive information to the outside world as sink points, and obtain the source and sink list corresponding to the application.

[0009] Step 2: Based on the function call relationships and control flow relationships within the function source code, generate an ICFG graph, and sequentially label the source nodes as pollution sources to simulate the propagation of pollution. When a source node or a sink node in the sink list is polluted, record all source nodes that act as pollution sources, marking a leaked data stream with one sink node corresponding to multiple source nodes. For each leaked data stream, mark a privacy leak with a source-sink pair.

[0010] Step 3: Store all the leaked data streams acquired into a collection PLSet. The elements of the collection PLSet include...<SourceSet, Sink> SourceSet represents the set of source nodes, and Sink represents the set of sink nodes. Two empty sets, FPSet and TPSet, are constructed. FPSet stores false positive leaks, and TPSet stores true positive leaks. The elements of the empty sets FPSet and TPSet include...<Source,Sink> , Source represents the source point.

[0011] Step 4: After instrumenting the Android application to be tested, install it on an Android emulator. Trigger a privacy leak by launching the application and inputting parameters through the UI using a stress testing tool. Obtain all runtime logs from the Android emulator, filter out the instrumented output statements, and obtain dynamic execution results based on the instrumented output statements.

[0012] Step 5: Select any leaked data stream from the PLSet set.<SourceSet,Sink> The system checks whether the dynamic execution result includes the sink of the leaked data stream. If it does, it proceeds to step 6. If it does not, it removes the sink corresponding to the leaked data stream.<Source,Sink> Add to FPSet.

[0013] Step 6: Construct a program dependency graph based on the dynamic execution results, and construct slicing criteria from the dynamic execution results including the Sink.<n,V> , where n is the line number of the point of contact and V is the set of variables of interest.

[0014] Step 7: Based on the program dependency graph and slicing criteria<n,V> Perform backward slicing to obtain the interest work set. Based on the slice fragments in the interest work set, determine the flag variable Flag of the slice fragment.

[0015] Step 8: Based on the value of the flag variable Flag, store the source and sink pairs corresponding to the slice fragment into the corresponding set to obtain the final judgment result of the current leakage.

[0016] Step 9: If every leaking data stream in PLSet...<SourceSet, Sink> All were visited, according to<SourceSet, Sink> Each privacy leak obtained from the breakdown<Source, Sink> If all leaks have been identified, FPSet and TPSet are returned. The detection method completes when FPSet and TPSet record the results of all leaks identified in step 2. If any unanalyzed leaked data streams exist...<SourceSet,Sink> Or privacy leaks<Source,Sink> If so, proceed to step 5.

[0017] As a preferred embodiment, the simulated pollution propagation is performed by using the IFDS algorithm to calculate the graph reachability problem.

[0018] As a preferred embodiment, step 4 specifically includes: Convert the bytecode of the Android application to be tested into an intermediate representation (IR).

[0019] Instrument the IR code by inserting system log output statements before each basic code block.

[0020] After instrumentation is complete, the IR code is converted back to bytecode, and the signed APK file is installed on the Android emulator.

[0021] The application was launched using a stress testing tool, which triggered a privacy breach. Parameters were sent to the application through manual clicking and input on the UI interface, further triggering the privacy breach.

[0022] After the vulnerability is triggered, all runtime logs of the Android emulator are obtained, and the instrumentation output statements are filtered out. Through the instrumentation output statements, the identifiers of the executed basic code blocks and the dynamic execution order of the basic code blocks, i.e., the dynamic execution results, are obtained.

[0023] As a preferred embodiment, step 6 specifically includes: Traverse each executed basic code block in the dynamic execution result, and construct a program dependency graph based on the execution order of the basic code blocks. The nodes in the program dependency graph are statement instances of each executed basic code block. Number the nodes, and add control flow dependencies and data flow dependencies to the program dependency graph according to the execution order of the statement instances of the basic code blocks.

[0024] If the statement instance of the basic code block corresponding to a node includes Sink, then the number corresponding to that node is used as n in the slicing criterion, and the variables of interest in the slicing related to Sink are stored in the variable set V, thus completing the generation of the slicing criterion.

[0025] As a preferred embodiment, step 7 specifically includes: Initialize the statement instances and their variables declared in the slicing guidelines to the working set of interest for the slice.

[0026] Based on control flow dependencies and data flow dependencies, add other relevant statement instances and all variables used by them to the working set of interest in sequence on the program dependency graph until no more relevant statements can be added to the working set of interest. After completion, slice the graph.

[0027] All statement instances in the interest work set constitute a slice fragment.

[0028] Store the set of statements in the slice into a set StmtSet, create a new flag variable Flag to record the attributes of the current leak, and initialize Flag to FP, that is, assume that the current leak is a false positive.

[0029] The flag variable Flag is used to determine the segment.

[0030] As a preferred embodiment, the method for determining the flag variable Flag of the slice segment specifically includes: Step 7.1: If the collection StmtSet is not empty, then let Stmt := pop(StmtSet), Stmt is assigned any statement in the collection StmtSet, and that statement is deleted from StmtSet.

[0031] Step 7.2: If the string match detects that Stmt contains Source, it means that the initial assumption is not true. Then set Flag := TP and jump to step 8.

[0032] Step 7.3: If the string matching detects that Stmt does not contain Source, then jump to step 7.1 or 7.4 according to the number of child elements in StmtSet.

[0033] Step 7.4: If StmtSet is empty, proceed to step 8.

[0034] As a preferred embodiment, step 8 specifically includes: Step 8.1: If Flag is TP, then the source and sink pairs are...<Source,Sink> Add it to the collection TPSet to confirm that the current leak actually exists.

[0035] Step 8.2: If Flag is FP, then the source and sink pairs are...<Source,Sink> Add the data to the FPSet set and determine that the current leak is a false positive.

[0036] In a second aspect, a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the dynamic and static Android privacy leakage detection method based on data flow analysis as described in any of the first aspects.

[0037] Thirdly, a computer device comprising: Memory is used to store instructions.

[0038] A processor is configured to execute the instructions, causing the computer device to perform operations of the dynamic and static ANDROID privacy leakage detection method based on data flow analysis as described in any of the first aspects.

[0039] Beneficial Effects: This invention provides a dynamic and static Android privacy leakage detection method and system based on data flow analysis. First, the source code of the target application is traversed to mark source and sink points. Second, static taint analysis is performed based on the source and sink lists to obtain potentially privacy-leaking data flows. Next, based on each sink in the potentially leaking data flow and the application's dynamic execution results, corresponding slicing criteria are generated, and several backward slicing operations are performed. Finally, the code fragments generated by the slices are traversed to check whether the source points are called. During the above process, the false positive rate of the data flow is determined. Compared to traditional taint analysis methods, this invention introduces dynamic program slicing for secondary analysis of the data flow, which can extract the application's true execution trajectory. Furthermore, through static taint analysis, a large amount of redundant information in the source and sink is removed, effectively reducing the false positive rate of the output results with less system overhead. Its advantages are as follows: I. This invention, based on static taint analysis, introduces dynamic program slicing for secondary analysis of the data stream, enabling the extraction of the application's true execution trajectory. Compared to single static taint analysis, the dynamic-static combined detection method proposed in this invention can identify false alarms and reduce the false positive rate in the output results.

[0040] For example, in the example application of this invention, static taint analysis identified three potential privacy-leaking data streams. After dynamic program slicing and false positive detection, one data stream was determined to be a false positive, and the other two were determined to be true positives. The method proposed in this invention reduces the generation of one false positive.

[0041] Second, this invention analyzes the data stream by first performing static taint analysis, followed by dynamic program slicing. If dynamic slicing were performed first, the source-sink pairs to be analyzed would directly come from the source and sink lists, containing a large number of possible pairings, resulting in significant time and space overhead. The current design, which performs static taint analysis first, greatly reduces the amount of information in the source and sink lists, removing most redundant information irrelevant to the leaked data stream. Subsequent slicing only requires a few more steps on this basis, effectively reducing false positives and improving accuracy with minimal system overhead.

[0042] For example, in the sample application of this invention, the table shows the markings of six key sub-functions. This is only a part of the source and assembly list; all library functions related to source code, program execution, service calls, etc., are marked before taint analysis. After static taint analysis, dynamic program slicing only requires further analysis of three potentially leaky data streams. Attached Figure Description

[0043] Figure 1 This is an overall flowchart of a dynamic and static Android privacy leak detection method based on data flow analysis.

[0044] Figure 2 This is the source code for the sample application. Detailed Implementation

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

[0046] The present invention will be further described below with reference to specific embodiments.

[0047] Example 1:

[0048] like Figure 1 As shown, a dynamic and static Android privacy leakage detection method based on data flow analysis includes the following steps: Step 1: Select the Android application to be tested, and read the corresponding classes.dex and AndroidManifest.xml files from the APK archive. classes.dex stores the compiled source code, and AndroidManifest.xml declares the application's package name, all components (including activities, services, broadcast receivers, and content providers), required permissions, and necessary hardware and software functionalities. Iterate through all classes and their sub-functions in the classes.dex source code, marking functions that retrieve sensitive information as source points and functions that send sensitive information to the outside world as sink points, thus obtaining the source and sink list for the application.

[0049] Step 2: Based on the function call relationships and control flow relationships within the functions in the classes.dex source code, generate an ICFG graph. Label the source nodes sequentially as pollution sources. Calculate the graph reachability problem using the IFDS algorithm to simulate the propagation of pollution. If a source or sink node in the sink list is polluted, record all source nodes that act as pollution sources, marking a leaked data stream with one sink node corresponding to multiple source nodes. For each leaked data stream, mark a privacy leak using a source-sink pair.

[0050] Furthermore, in one embodiment, the static taint analysis problem is transformed into a special graph reachability problem, which can be solved exactly in polynomial time complexity. The algorithm used in this invention is the IFDS (Interprocedural, Finite, Distributive, and Subset) algorithm. The core idea of ​​the IFDS algorithm is to transform the data flow analysis problem into a graph reachability problem. The IFDS algorithm analyzes based on the interprocedural control flow graph (ICFG), converting the program into an ICFG and analyzing the program state at each node in the graph. The input of this algorithm is a hypergraph consisting of a control flow graph (CFG) of all functions, and the output is all valid paths. To determine the flow function of each edge in the hypergraph, i.e., the information flow mode, it is necessary to define the taint propagation strategy. Flow functions can be roughly divided into four categories: Normal flow functions, Call flow functions, Return flow functions, and Call-to-return flow functions. Different taint propagation rules can be customized for these four different cases.

[0051] Furthermore, in one embodiment, static taint analysis to obtain leaked data streams refers to the process of parsing the source code of an Android application, establishing a taint propagation model based on the source and sink lists, and searching for potential leaks. First, a source and sink list corresponding to the application to be analyzed is provided, with the source points considered as taint sources. Then, an ICFG graph is constructed based on the application's source code, and taint propagation is calculated on the graph. If the taint reaches the sink point, a potential privacy-leaking data stream is obtained.

[0052] Step 3: Store all leaked data streams obtained in Step 2 into a set PLSet (Potential Leak Set). The elements of this set are tuples PL=<SourceSet, Sink> It consists of a source set (SourceSet) and a sink set (Sink). Two new empty sets, FPSet (False Positive Set) and TPSet (True Positive Set), are created to store the leakage data stream classification results. FPSet stores false positive leakage identified by this detection method in subsequent steps, and TPSet stores the identified true positive leakage. The sub-elements of both sets are L=<Source, Sink> This refers to a privacy leak in one instance of a source-sink pair labeling.

[0053] Step 4: Convert the target application's bytecode to an Intermediate Representation (IR). Instrument the IR code by inserting system log output statements before each basic code block, ensuring that the application records a unique identifier for the current code block in the Android runtime log when executed. After instrumentation, convert the IR code back to bytecode. Following these steps, the source code file `classes.dex` has been modified, necessitating a re-signing of the application. Install the signed APK file onto an Android emulator and launch the application using a stress testing tool based on the package name declared in `AndroidManifest.xml`. After the application launches, further trigger privacy leaks through manual clicks and input on the UI, the specific triggering method depending on the APK's source code. Privacy leak vulnerabilities may occur during and after application launch. Once the vulnerability is triggered, obtain all runtime logs from the Android emulator, filter out the instrumented output statements, and use these statements to obtain the identifiers of the executed basic code blocks and their dynamic execution order (i.e., the dynamic execution result).

[0054] Furthermore, in one embodiment, the startup process involves many system operations, such as loading and initializing resources, creating processes, initializing application activities, starting services, etc., which can be simulated using stress testing tools.

[0055] Furthermore, in one embodiment, instrumentation before dynamic execution requires direct parsing of the source code, the difficulty of which depends on the code's representation. The bytecode source file `classes.dex` of an Android application often contains hundreds of different opcodes, all of which must be simulated in terms of data flow facts. For each opcode, separate rules need to be defined to transform the incoming data flow facts, so that the output resembles the impact of the opcode on its respective data. To reduce the complexity of analysis, this invention performs instrumentation based on intermediate representation (IR). Compared to bytecode, IR opcode types are much fewer, and there is a complete semantic mapping between them. Although converting to IR code increases the overall number of lines of code, it effectively reduces the number of analysis cases by creating simple statement instances.

[0056] Step 5: Select any leaked data stream from the PLSet.<SourceSet,Sink> For this leaked data stream, we can randomly select one privacy breach within it, which is transmitted through a source-sink tuple.<Source,Sink> Provide a description. Determine whether it is a false positive based on the dynamic execution results.

[0057] Furthermore, in one embodiment, determining whether a result is a false positive based on the dynamic execution result specifically includes: Step 5.1: If none of the executed code blocks in the dynamic execution result contain a Sink, then the source-sink tuple will be...<Source,Sink> By adding FPSet, the algorithm will classify the current leak as a false positive.

[0058] Step 5.2: If any of the executed code blocks in the dynamic execution result contains a Sink, then proceed to step 6.

[0059] Step 6: Construct slicing criteria based on the dynamic execution results including the sink.<n,V> Here, n is the pointcut line number, and V is the set of variables of interest. The process iterates through each executed basic code block in the dynamic execution result, constructing a program dependency graph based on the execution order of these code blocks. Nodes in the program dependency graph are statement instances of each executed basic block. These nodes are numbered, and control flow dependencies and data flow dependencies are added to the graph according to the execution order of the statement instances. For each statement instance represented by a node, a sink is matched. If the sink is contained within the statement instance, the node's corresponding number is used as n in the slicing criterion. The actual parameters created, referenced, or received by the statement instance itself—that is, the variables of interest for the slice related to the sink—are stored in the variable set V through regular expression matching, thus completing the generation of the slicing criterion.

[0060] Step 7: Based on the slicing criteria and program dependency graph generated in Step 6, perform backward slicing. Initialize the statement instances and their variables declared in the slicing criteria into the working set of interest for the slice. On the program dependency graph, according to control flow dependencies and data flow dependencies, add other relevant statement instances and all their used variables into the working set of interest in sequence. The slicing process continues until no more related statements can be added to the working set of interest. After completion, the slicing proceeds backward, and all statement instances in the working set of interest constitute a slice fragment. Store the set of statements in the slice fragment into StmtSet (Statement Set). Create a new flag variable Flag to record the attribute of the current leak (FP or TP). Initialize Flag to FP, assuming the current leak is a false positive. If a source point is detected in the slice fragment in subsequent steps, it indicates that the path from the source point to the sink point is reachable during dynamic execution, and the privacy leak described by the source-sink tuple truly exists.

[0061] If sensitive information reaches the sink and is transmitted to the outside world, then all related source points are searched in reverse to define a privacy-leaking data stream, using data structures.<SourceSet,Sink> This indicates that, since the Sink is uniquely determined in this data structure, generating slicing criteria using the sink in step 6 is the most efficient method. In step 7, only one slicing operation is needed for this slicing criterion, and in the generated statement instance fragment, a string matches are performed for a source points. If slicing criteria are constructed based on the source points, then a slicing operations are needed based on a slicing criteria generated from a source points, and a string match is performed for the sink point for each slicing operation. Since the time complexity of slicing is much greater than that of string matching, the slicing criterion generation scheme proposed in this invention is optimal.

[0062] Program slicing is an analytical technique for decomposing programs, commonly used for code debugging, analysis, understanding, and refactoring. Its principle is to remove instructions unrelated to the criteria from the source code based on a custom slicing criterion, achieving the goals of simplifying the program and streamlining analysis. Backward slicing aims to find statements and control predicates in program P that affect variables at point of interest n, i.e., the point of interest is at the back end of program P. Forward slicing aims to find which statements and predicates in program P are affected by the value of variable V at point n, i.e., the point of interest is at the front end of program P. In step 6, the slicing criteria are constructed based on the sink point; therefore, this invention can only use backward slicing in this step.

[0063] Step 7.1: If StmtSet is not empty, then set Stmt := pop(StmtSet), that is, Stmt is assigned any statement in the StmtSet collection, and that statement is deleted from StmtSet. := means equal to.

[0064] Step 7.1.1: If the string match detects that Stmt contains Source, it means that the initial assumption is not true. Then set Flag := TP and jump to step 8.

[0065] Step 7.1.2: If the string matching detects that Stmt does not contain Source, then jump to step 7.1 or 7.2 according to the number of child elements in StmtSet.

[0066] Step 7.2: If StmtSet is empty, proceed to step 8.

[0067] Furthermore, in one embodiment, dynamic program slicing based on potential leaks refers to the process of extracting source and sink information from the data stream, dynamically executing the application, and then performing backward slicing to generate program fragments. First, the source and sink information of the potentially leaking data stream is extracted. Then, the application is dynamically executed on an Android emulator. Based on each source-sink pair and the dynamic execution result, corresponding slicing criteria are generated, and backward slicing is performed to obtain slice fragments.

[0068] Step 8: Based on the value of the flag variable Flag, store the source and sink pairs into the corresponding sets to obtain the final judgment result of the detection method for the current leakage.

[0069] Step 8.1: If Flag is TP, then the source-sink pair...<Source,Sink> Adding it to the set TPSet confirms that the current leak truly exists.

[0070] Step 8.2: If Flag is FP, then the source-sink pair...<Source,Sink> The algorithm determines that the current leak is a false positive by adding it to the set FPSet.

[0071] Step 9: If every leaking data stream in PLSet...<SourceSet, Sink> All were visited, according to<SourceSet, Sink> Each privacy leak obtained from the breakdown<Source, Sink> If all leaks have been identified, FPSet and TPSet are returned. The detection method completes when FPSet and TPSet record the results of all leaks in the target application identified by the static taint analysis in step 2. If any leaked data streams exist that have not been analyzed...<SourceSet,Sink> Or privacy leaks<Source,Sink> If so, proceed to step 5.

[0072] Furthermore, in one embodiment, false positive detection of data streams refers to the process of performing secondary analysis on potential leaks based on the results of dynamic program slicing to determine whether they are false positives. If there is no sink in the dynamic execution log, or no source in the slice fragment, the method classifies the leaked data stream as a false positive. If there is a sink in the dynamic execution log and a source in the slice fragment, the method classifies the leaked data stream as a true positive.

[0073] Example 2:

[0074] This invention selects the application ActivityEvent-Sequence1.apk from the open-source benchmark suite DroidBench 3.0 to further illustrate the dynamic and static Android privacy leakage detection method based on data flow analysis, but this should not be used to limit the scope of protection of this invention.

[0075] Figure 2 This is the source code corresponding to the example Android application selected in this invention. Information leakage is only triggered when onResume is called; it is not triggered when onStart or onRestoreInstanceState is called.

[0076] Step 1: When traversing all classes and their sub-functions in the source code, mark the four overridden callback functions and the library functions they call as source or sink points according to the function body content.

[0077] Table 1 describes the labeling results of all key functions, where function number 5 is labeled as the source and all other functions are labeled as the sink.

[0078] Table 1 shows the labeling results for all key functions.

[0079] Step 2: Calculate the taint propagation path on the ICFG graph of the example program. When the taint propagates to the sink marked in Step 1, the corresponding data stream is identified as a potential privacy leak, and the tuple describing the leaked data stream is...<SourceSet, SinkSet> Store the data in a PLSet set to complete the static taint analysis.

[0080] Table 2 describes three potential leaked data streams discovered by static taint analysis. The source of all three streams is the getDeviceId function, and the sinks are the onResume, onStart, and onRestoreInstanceState functions, respectively.

[0081] Table 2 shows the results of static stain analysis.

[0082] Step 3: Run the example application on the simulator and search for all sinks stored in PLSet in the dynamic execution results. It was found that onStart and onResume were both triggered, but onRestoreInstanceState was not triggered. Therefore, the third potentially leaky data stream was determined to be a false positive.

[0083] Step 4: Generate corresponding slicing criteria for onStart and onResume respectively, and perform backward slicing.

[0084] Table 3 describes the basis for generating slice criteria for the two sinks respectively. The slice criterion corresponding to onStart is <12, all variable sets>, and the slice criterion corresponding to onResume is <18, all variable sets>.

[0085] Table 3 shows the criteria for generating slices.

[0086] Step 5: Based on the slicing criteria generated in Step 4, perform two backward slices in sequence, and search for the source point getDeviceId in the two different program fragments generated.

[0087] Table 4 describes the results of the first backward slicing. The slicing criterion was that, based on the <12, all variable sets> generated by the sink onStart, the source node getDeviceId was called in segment number 4, thus classifying this leaky data stream as a true positive. Similarly, the source node getDeviceId was also found in the second backward slicing results, therefore the data stream reaching the sink onResume was also classified as a true positive. Thus, this invention has performed secondary analysis on all three potentially privacy-sensitive data streams, classifying one as a false positive and the other two as true positives.

[0088] Table 4 Results of backward slicing

[0089] Example 3: This embodiment describes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the dynamic and static Android privacy leakage detection method based on data flow analysis as described in any of Embodiment 1.

[0090] Example 4:

[0091] This embodiment describes a computer device, including: Memory is used to store instructions.

[0092] A processor is configured to execute the instructions, causing the computer device to perform operations as described in any of Embodiment 1 of the dynamic and static ANDROID privacy leakage detection method based on data flow analysis.

[0093] 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 a completely hardware embodiment, a completely software embodiment, or an embodiment 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, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for detecting privacy leaks in dynamic and static Android devices based on data flow analysis, characterized in that: Includes the following steps: Step 1: Obtain the source code of the Android application to be tested, traverse all classes and their sub-functions in the source code, mark the functions that obtain sensitive information as source points, and mark the functions that send sensitive information to the outside world as sink points, and obtain the source and sink list corresponding to the application. Step 2: Based on the function call relationships in the source code and the control flow relationships within the functions, generate an ICFG graph, and label the source points as pollution sources in sequence to simulate the spread of pollution; when the source and sink points in the sink list are polluted, record all the source points that are pollution sources, and mark a leaked data stream in a way that one sink point corresponds to multiple source points; for each leaked data stream, mark a privacy leak with a source-sink pair; Step 3: Store all the leaked data streams acquired into a collection PLSet. The elements of the collection PLSet include...<SourceSet, Sink> SourceSet represents the set of source nodes, and Sink represents the set of sink nodes; construct two empty sets, FPSet and TPSet, where FPSet stores false positive leaks and TPSet stores true positive leaks; the elements of the empty sets FPSet and TPSet include<Source,Sink> Source indicates the source node; Step 4: After instrumenting the Android application to be tested, install it on the Android emulator. Trigger privacy leakage by launching the application and inputting parameters through the UI interface using a stress testing tool. Obtain all the running logs of the Android emulator, filter out the instrumented output statements, and obtain the dynamic execution results based on the instrumented output statements. Step 5: Select any leaked data stream from the PLSet set.<SourceSet,Sink> Determine whether the dynamic execution result includes the sink of the leaked data stream. If it does, proceed to step 6; otherwise, change the location of the sink.<Source,Sink> Add to FPSet; Step 6: Construct a program dependency graph based on the dynamic execution results, and construct slicing criteria from the dynamic execution results including the Sink.<n,V> , where n is the line number of the point of interest, and V is the set of variables of interest; Step 7: Based on the program dependency graph and slicing criteria<n,V> Perform backward slicing to obtain the interest work set. Based on the slice fragments in the interest work set, determine the flag variable Flag of the slice fragment. Step 8: Based on the value of the flag variable Flag, store the source and sink pairs corresponding to the slice fragments into the corresponding sets to obtain the final judgment result of the current leakage; Step 9: If every leaking data stream in PLSet...<SourceSet, Sink> All were visited, according to<SourceSet, Sink> Each privacy leak obtained from the breakdown<Source, Sink> If all leaks have been identified, FPSet and TPSet are returned. The detection method completes when FPSet and TPSet record all leak identification results for the target application identified in step 2. If any unanalyzed leaked data streams exist...<SourceSet,Sink> Or privacy leaks<Source,Sink> If so, proceed to step 5.

2. The method for detecting dynamic and static Android privacy leaks based on data flow analysis according to claim 1, characterized in that: The simulated pollution propagation was performed using the IFDS algorithm to calculate the graph reachability problem.

3. The method for detecting dynamic and static Android privacy leaks based on data flow analysis according to claim 1, characterized in that: Step 4 specifically includes: Convert the bytecode of the Android application to be tested into an intermediate representation (IR); Instrument the IR code by inserting system log output statements before each basic code block; After instrumentation is complete, the IR code is converted back to bytecode, and the signed APK file is installed on the Android emulator. The application was launched by a stress testing tool, which triggered a privacy leak. Parameters were sent to the application through manual clicking and input on the UI interface, which further triggered a privacy leak. After the vulnerability is triggered, all runtime logs of the Android emulator are obtained, and the instrumentation output statements are filtered out. Through the instrumentation output statements, the identifiers of the executed basic code blocks and the dynamic execution order of the basic code blocks, i.e., the dynamic execution results, are obtained.

4. The method for detecting dynamic and static Android privacy leaks based on data flow analysis according to claim 1, characterized in that: Step 6 specifically includes: Traverse each runnable basic code block in the dynamic execution result, and construct a program dependency graph based on the execution order of the basic code blocks. The nodes in the program dependency graph are statement instances of each runnable basic code block. Number the nodes and add control flow dependencies and data flow dependencies to the program dependency graph based on the execution order of the statement instances of the basic code blocks. If the statement instance of the basic code block corresponding to a node includes Sink, then the number corresponding to that node is used as n in the slicing criterion, and the variables of interest in the slicing related to Sink are stored in the variable set V, thus completing the generation of the slicing criterion.

5. The method for detecting dynamic and static Android privacy leaks based on data flow analysis according to claim 1, characterized in that: Step 7 specifically includes: Initialize the statement instances and their variables declared in the slicing guidelines to the work set of interest for the slice; Based on control flow dependencies and data flow dependencies, add other relevant statement instances and all variables used by them to the interest working set in turn, until no more relevant statements can be added to the interest working set. After completion, slice the graph. All statement instances in the interest work set constitute a slice fragment; Store the set of statements in the slice into a set StmtSet, create a new flag variable Flag to record the attributes of the current leak, and initialize Flag to FP, that is, assume that the current leak is a false positive; The flag variable Flag is used to determine the segment.

6. The method for detecting dynamic and static Android privacy leaks based on data flow analysis according to claim 5, characterized in that: The method for determining the flag variable Flag of the slice segment specifically includes: Step 7.1: If the collection StmtSet is not empty, then let Stmt := pop(StmtSet), Stmt is assigned any statement in the collection StmtSet, and that statement is deleted from StmtSet; Step 7.2: If the string match detects that Stmt contains Source, it means that the initial assumption is not true. So set Flag := TP and jump to step 8. Step 7.3: If the string matching detects that Stmt does not contain Source, then jump to step 7.1 or 7.4 according to the number of child elements in StmtSet; Step 7.4: If StmtSet is empty, proceed to step 8.

7. The method for detecting dynamic and static Android privacy leaks based on data flow analysis according to claim 1, characterized in that: Step 8 specifically includes: Step 8.1: If Flag is TP, then the source and sink pairs are...<Source,Sink> Add the data to the TPSet set to confirm that the current leak actually exists; Step 8.2: If Flag is FP, then the source and sink pairs are...<Source,Sink> Add the data to the FPSet set and determine that the current leak is a false positive.

8. A computer-readable storage medium, characterized in that: It stores a computer program that, when executed by a processor, implements the dynamic and static Android privacy leakage detection method based on data flow analysis as described in any one of claims 1-7.

9. A computer device, characterized in that: include: Memory, used to store instructions; A processor is configured to execute the instructions, causing the computer device to perform the operation of the dynamic and static ANDROID privacy leakage detection method based on data flow analysis as described in any one of claims 1-7.

Images