Simulating cooperative fire evacuation training in a virtual environment using gaming technology

I.   Introduction

Android systems increasingly contain private user information. Because of their openness, they often run a large number of untrusted programs, which results in frequent privacy leakage ^[1],[2]. The propagation and flow of sensitive information must be controlled ^[3]. Fine-grained information flow control is in-separable from information flow tracking, also known as taint tracking. Specifically, it first tags source data (e.g., GPS location data returned by API call) as tainted. Then, these taints are propagated through data flow or control flow. Finally, whether the tainted data reach sinks (e.g., the network output) is checked.

Solutions that rely on static taint analysis (STA) can comprehensively search for potential information leakage paths but may cause over-approximations by generalizing all possible behaviors of a program and produce false positives ^[1],[4]–^[7]. Furthermore, if a discovered leakage path and a legitimate path share a sink, it is challenging for STA to apply correct judgments and control due to the lack of runtime path information (Refer to the example in Section II for this problem).

In contrast, solutions that rely on dynamic taint analysis (DTA) search for security issues at program runtime. The characteristics of DTA enable it to provide sufficient context, which helps DTA to avoid false positives. DTA has been used in various application domains, including information flow control ^[5],[8]–^[13], vulnerability discovery ^[14–^20], security attacks ^[19],[21–^27], malware detection ^[27],[29], privacy leakage analysis ^[30–^32], etc. Despite its advantages, DTA is rarely used in practice today ^[9]. The most serious problem is its performance overhead since, in a pure DTA situation, every instruction of the original program usually takes 6 to 8 extra taint tracking instructions to propagate a taint tag ^[35–^37]. Several efforts have been made to reduce the overhead of DTA through hardware acceleration ^[5],[39–^42], parallelization ^[36–^37],[42–^46], code optimization ^{[14],[31],[52],} etc. For example, TaintPipe ^[37] can reduce the slowdown of dynamic taint analysis to 1x in some test cases. However, other problems then arise. Hardware-accelerated DTA requires additional hardware support. Parallelized DTA sacrifices the spare cores and wastes energy to accelerate DTA. Code optimization can only be realized for specific code features. Moreover, few pure DTA tools track implicit flows, which incur a significant performance overhead due to the lack of comprehensive branch structure information at runtime ^[30].

Hybrid analysis (HA) has been explored to accelerate DTA by static pre-optimized tracking logic ^[9]–^{[10],[52],[60],} static pre-reduced tracking range ^[10],[61], static part sharing tracking tasks ^[62], etc. Although HA can use STA rapidly to calculate implicit taint propagation caused by the control dependencies, these traditional HA are still based on dynamic taint tracking supplemented by STA, where the dynamic instruction-by-instruction tracking is still the main component. For example, Iodine ^[9] assumes that the fast path is often executed, while the slow path is less executed. Iodine only optimizes tracking for fast paths. If the fast and slow paths have equal probability of execution, or the profiler’s prejudgment of whether a path is fast or slow is not accurate, the advantages of Iodine are nullified, but the path switching and recovery overhead will increase. Therefore, these methods only exhibit their advantages in certain cases and are not adequately robust. Moreover, HA’s static analysis usually lacks runtime profile information, which leads to reduced optimization and accuracy. Additionally, HA introduces several STA’s shortcomings. For example, the classic STA algorithm IFDS (Interprocedure, Finite, Distributive, Subset) ^[34] does not analyze the stable periods of loop structures to avoid path length explosions, which may produce false positives (Refer to Section III D for this problem).

Fig. 1.Fig. 1. Comparison of tracking between pure DTA and FSAFlow

As for the above work, the tracking logic is not separated from the program execution, or the separation is not complete. Regarding privacy protection and performance improvement, the use of instruction-by-instruction tracking mechanisms for running programs is undesirable. Instead of caring about how information is spread between variables, research should consider whether the information flow path has occurred, whether it has reached the sink node, and whether the policy allows it. This requires a more effective regulatory mechanism. This paper proposes FSAFlow to address the above-mentioned challenges in HA. Its key idea is to separate the slow taint tracking logic from the program execution and further separate the path control logic from the taint tracking logic. Its static analysis does not require dynamic profile information, and it only searches for potential paths. Its runtime control is based on changes in path state rather than taint state. Figure 1 compares pure DTA and FSAFlow using an example. It assumes that variable td is a source, and printf (out ) is a sink. The taint is propagated to variables in , a, b and out successively. Finally, it reaches the sink, causing an information leakage. Figure 1 (a) shows the tracking of pure DTA. It adds taint tracking instructions for each data flow statement, as shown in ➀-➅. Figure 1 (b) shows the tracking of FSAFlow. It only inserts path tracking instructions at the start, end, and branches of the path, as shown in OI-O4. The detailed FSAFlow instrumenting logic is shown in Section III-D and Figure 5. FSAFlow is directly applicable to Android APK. The demo video can be downloaded from https://github.com/FSAFlow/FSAFlow.

The contributions of this paper are as follows:

1. A novel information flow protection system, FSAFlow, is proposed that uses path tracking rather than taint tracking for privacy protection. The target program is only instrumented with lightweight supervision code related to the path, which does not involve cumbersome variable taint propagation. Based on this, fast information flow tracking can be achieved at runtime.
2. FSAFlow uses a finite state machine to monitor the path state efficiently at runtime. It provides path-aware control which is difficult for STA and achieves higher precision than STA by verifying the paths that never occur and tracking throughout the execution stage of the loop body. It makes quick tracking operations by updating the path state only at branch statements, and can find and track implicit flow paths more easily than DTA by using STA comprehensively to search potential paths.
3. The experimental results show that FSAFlow incurs a low overhead, 2.06% for popular applications, and 5.41% on CaffeineMark 3.0, which is lower than some representative DTA optimization approaches such as tracking on demand, local code optimization, optimal hybrid taint analysis.

Fig. 2.Fig. 2. Code snippet of InsecureBankv2

II.   Motivation

In this section, a specific example, InsecureBankv2 ^[43], is provided to illustrate typical data leakage behavior and explain our motivation. InsecureBankv2 is used to evaluate the efficiency of security holes analysis tools. Data leakages designed in this app are basically the same as those in actual apps.

Figure 2 shows a code snippet from InsecureBankv2 with a slight modification. First, in the onCreate method, data , the initial position of privacy data (the 3rd line), is regarded as the source. The privacy information eventually flows to the log method (the 25th line), which is regarded as sink nodes. This code prints out the password in the log and the password is easily leaked out, which is a serious privacy issue.

It is understood that Android presently cannot prevent such leakages. Android’s permission control mechanism only determines which sources (such as location, IMEI, etc.) or sinks (sending to networks, etc.) can be accessed by apps following the user’s choices. Android systems usually give a prompt such as whether to allow the program to read location information, but provide no mechanism that controls data propagation from sources to sinks nor information flow-control policies such as whether to allow the program to write location information into files. Information flow policies are crucial for privacy protection.

Owing to commercial interests or untrusted third-party components, some popular apps, such as instant messaging, and navigation software, not only use private data to complete normal functions but also spread private data without informing users. In this case, information flow tracking and control are needed to prevent the leakage paths beyond normal functions. However, the current methods have the following problems:

1. This leakage path can be found by traditional STA, but the kind of control to take at log.d is unknown. In Fig. 1, two paths converge to this sink. One contains the password information (the if-then path starting from lines 19-20), and the other contains no password information (the if-else path starting from lines 21-22). There is no runtime context information at log.d . In practice, a sink node often contains multiple paths from the sources. Simple prohibition or permission will cause usability or security problems.
2. If traditional DTA is adopted, the dynamic context information can be provided for correct control. However, the main problem is its excessive running overhead for single-step instruction track and its suffering in implicit flow tracking.

Fig. 3.Fig. 3. Workflow of FSAFlow

To solve these problems, a novel hybrid analysis method, FSAFlow is proposed for privacy protection. The key idea is to adopt global path tracking instead of micro taint tracking at runtime. Meanwhile, path tracking is optimized to ensure tracking efficiency at runtime. FSAFlow provides path-aware control at sink points to ensure the accuracy of control.

III.   Design and Implementation

A. Overall framework

As shown in Figure 3, FSAFlow consists of a mobile client and a cloud server (distinguished by color), and its workflow is as follows: First, at ➀, a user can use the client to customize the flow policies for any application on the mobile phone. By managing the information flow path from source to sink, the user obtains a customized privacy policy, such as whether the location information can be sent through the network or written to local files. Then, at ➁, the personal flow policy file is uploaded to the cloud server with the corresponding APK file for processing.

On the server side, FSAFlow performs static analysis and instrumentation processing according to the uploaded flow policy. In the static analysis stage, as shown at ➂, all the potential paths that violate the policy will be considered. Meanwhile, the key node information of these paths is recorded during this stage. In the static instrumentation stage, as shown at ➃, the important nodes of the supervised path are instrumented for efficient path-state management. Then, at ➄, the instrumented code is repackaged to generate a new APK file and returned to the client. Based on this, the security-enhanced application will be run and monitored efficiently on users’ mobile phones as shown in ➅.

B. Static analysis

The static analysis stage aims to mark potential leakage paths and record their necessary node information for static instrumentation. Since branch jumps are key nodes for distinguishing different paths, the contexts of branch nodes on the path will be recorded. Monitoring points are mainly instrumented at branches. In order to efficiently locate branch nodes during the instrumentation stage, the contexts of the function call and return will be recorded as separate nodes to indicate the method body where subsequent branch nodes are located. Therefore, for the branch node, we only need to record its relative position in the method body.

The FSAFlow’s static analysis component is realized by modifying the classic IFDS framework ^[34] and the FlowDroid tool. Many static analysis problems, including taint analysis, pointer analysis, live variables, and constant propagation, can be solved by IFDS using a special graph-reachability algorithm.

The IFDS problem is represented by a tuple ($G^{\#}$, D, F, M , $\cap$), where $G^{\#}$=($\psi,\ E^{\#}$) is called the Interprocedural Control Flow Graph (ICFG), and it provides the directed supergraph representation of a program. Each n $\in\psi$ corresponds to a statement of the program, and each ($n_{1},n_{2})\in E^{\#}$ indicates that Statement n₂ is a direct successor to Statement n₁ . D is a finite set of information flow facts, indicating the variables that are infected. $F \subseteq 2^{D}\rightarrow 2^{D}$ is a set of information flow functions. A flow function defines the impact of a statement on a set of flow facts. For example, the statement $s:x=y$ would be associated with a flow function that maps a fact set {y } (i.e., y is tainted) to a fact set {x,y }(x and y are both tainted), which can be expressed as {xy }=f_s ({y }). M : $E^{\#}\rightarrow$F is a map from the edges of $G^{\#}$ to flow functions, and the meet operator $\cap$ is the union for taint analysis.

$G^{\#}$ consists of a set of flow graphs {$G_{1},G_{2},\ldots$}(one per function). The flowgraph G_p of a function p is composed of a unique start node s_p , a unique exit node e_p , and the remaining nodes representing the statements and predicates in p . In $G^{\#}$, a statement m of calling a function q is represented by two nodes, a call node c_m , and a return-site node r_m . Three edges are used to connect m and q : a call-to-return edge from c_m to r_m , a call-to-start edge from c_m to s_q , and an exit-to-return edge from e_q to r_m .

To convert static analysis problems to graph-reachability problems, $G^{\#}$ is extended to a supergraph $G^{\ast}=(N^{\ast},E^{\ast})$, where $N^{\ast} =N^{\#}\times(D\cup\emptyset)$ and $E^{\ast}=\{\lt u,d_{x}\gt \rightarrow\lt v,d_{y}\gt \mid(u,v)\in E^{\#},d_{y}\in f_{u} (d_{x})\}$. For example, $(n_{1}:x=y\rightarrow n_{2}:z=x)\in E^{\#}$ can be extended to $\{(\lt n_{1},y>\longrightarrow\lt n_{2},y>,\lt n_{1},x\gt \longrightarrow\lt n_{2},y\gt )\}\in E^{\ast}$, if y has been tainted before n₁ . Note that $\emptyset$ signifies an empty set of facts.

Algorithm IAlgorithm I   Static analysis

Based on the definition of flow functions, the IFDS algorithm performs width-first traversal of the ICFG from the source statement and searches for all paths ending with the sink statement in $E^{\ast}$. Therefore, if there is a path from node $\lt n_{0}$: $y=$ source() $(,\emptyset\gt$. to node $\lt n_{\text{final}}:\operatorname{sink}(x),Z\gt$. in $G^{\ast}$, the sequence of statements corresponding to the nodes on the path constitutes the information flow path from source to $\operatorname{sink}$.

FSAFlow continues to extend $G^{\ast}$ to $G^{\wedge}=(N^{\wedge},E^{\wedge})$, where $N^{\wedge}=N^{\ast}\times$ String and $E^{\wedge}=\{\lt u, d_{x}, P_{FSA}\gt \rightarrow\lt v, d_{y}, P_{FSA}\gt |(u,\ v)\in E^{\ast}, d_{y}\in f_{u}(d_{x})\}$. $P_{FSA}$ records the key information to identify the path so far, including the context of branch statements and call/return statements, etc. The search and recording are performed concurrently. The specific static analysis is shown in Algorithm 1.

In Algorithm 1, The inputs Sourcelist and Sinklist are obtained by reading user policy files, and $G^{\#}$ is generated by calling the SOOT tool. First, $G^{\#}$ is searched to find the source statement set. Then, each source is taken as a starting point to search $E^{\wedge}$ for the paths to the target sinks. The searched edges are recorded in the variable pathedge and will not be searched again (lines 12-13). The variable Worklist records the set of edges that remain to be searched. The newly found edges will be added to Worklist (lines 7, 23,27, etc.), and the old edges that have been searched will be removed from the worklist (line 11).

Fig. 4.Fig. 4. Information flow analysis and path coding

The string array P_FSA stores the information of each key node sequentially. In P_FSA , different nodes are segmented with a special separator. FSAFlow extracts different key information for different statement types.

1. The statement type sink (lines 16-18). It indicates that a flow path has been found. At this time, the path expansion is terminated and P_FSA is output.
2. The statement type function call (lines 19-27). When this node is first encountered, the caller’s and callee’s call -site information is appended to P_FSA , and the path is extended to the callee. Otherwise, the new extended path fragment Part_FSA about the callee can be extracted from the function summary Summaryhash , and the search is then performed on the return-site node .
3. The statement type function return (lines 28-33). The function summary is appended to Summaryhash for reuse. Then, the algorithm returns to the call node and continues to expand the next statement. Summaryhash stores the path fragment of the information flow when it flows through the function.
4. The statement type assignment (lines 34-38). P_FSA will not be updated. The assignment statement is not the key information for FSAFlow, but, in this case, the alias problem is considered. FSAFlow performs on-demand alias analysis. Whenever a variable is tainted, FSAFlow searches backwards for its aliases and then taints them as well. The result variable output by the function of backward alias analysis, the current statement, and P_FSA combined form a new node in $N^{\wedge}$. This node will be exploited to continue the forward data flow analysis.
5. The statement type branch (lines 39-47). The information m_p of the first statement m_s of a subsequent branch path is appended to P_FSA as a node. The node m_p consists of a tuple <sn, size, no, type, s $n'$, m >, where sn represents m_p 's position in P_FSA , size represents the branching number of the branch, no is for the branch serial number of the target path, and type is for the node type, indicating to which branch type the selected branch belongs. The node type can be in (entering loop body), out (the type of exiting loop body), and x (others). If m_s appears more than once on the path within the current function, s $n'$ is used to record the first corresponding position of m_s in P_FSA . m is for the statement itself. Finally, when P_FSA is output, m is removed from this node in P_FSA . Refer to Section III-D and C for the use of branch information.

Taking the code snippet in section II as an example, algorithm 1’s path analysis process is given. The polluted process at the sink can be abstracted as the process steps ➀-➇ in Figure 4(a). Meanwhile, the main structure of the path obtained by the static analysis is shown in Figure 4(b). FSAFlow operates on the Jimple code, therefore, to facilitate subsequent instrumentation, the output path is also represented by Jimple statements.

In step ➀, the tainted variable password starts to propagate forward. At ➁, the class RequestTask is tainted. Step ➂ continues tracking when the tainted variable is called by postData . At ➃, the tainted variable is called by ConvertStream ToString . Step ➄ represents the return of the function call. The tainted variable continues to propagate forward through ➅ and passes through two branches due to the if statements. At ➅, loginfo is tainted. This triggers the backward alias analysis through steps ➆ and ➇, the alias loginfo_tmpt2 for loginfo is found and then propagates forward as a normal taint. Finally, at ➈, the tainted variable loginfo_tmpt2 leaks at the sink.

FSAFlow adjusts the output format of P_FSA and aggregates the nodes according to classes and methods. After the static analysis is completed, the key information of paths is output and written into path files.

C. Static instrumentation

The static instrumentation stage aims to embed the lightweight code for path monitoring into the apps, which transforms untrusted apps into policy-enforcing apps. According to the results of static analysis and user-defined flow policies, the disallowed paths are extracted and instrumented for the source nodes, branch nodes, and sink nodes.

Before instrumentation, FSAFlow preprocesses the path file. Because there is a loop structure, a statement may repeatedly appear on the path, thus let SN be the set of all the positions (sn ) on the path where a statement m appears. FSAFlow appends SN to the node where m first appears on the path for m ’s location to be instrumented only once. After appending, other nodes about m remain on the path to ensure the consistency of the control flow when the following nodes are instrumented. Moreover, each loop structure involved in the path is assigned a unique ID that is used for status monitoring in nested loops. Refer to Section III-D for the use of loop ID.

Furthermore, all paths are managed hierarchically and uniformly by a multilevel hash table HashMap_policy according to class, method, and path identification. Hereby, the involved classes and methods are each traversed only once. HashMap_policy has a data structure of <classname, <method , <pathid , path-fragment >>>, and is directly accessed through the multi-level key-value. Each key value of the method index can store the fragment information of multiple paths while pathfragment only stores branch nodes. The nodes associated with function calls on the path can be removed and will not occur in $HashMap_{policy}$. Subsequent instrumentation is based on HashMap_policy .

Algorithm 2Algorithm 2   Code Instrumentation

Fig. 5.Fig. 5. Code instrumentation

FSAFlow extends SOOT’s BodyTransformer and the method internalTransform is implemented to traverse the units (statements) of all method bodies and insert the monitoring code in the specified location. Algorithm 2 describes the process of code instrumentation in detail.

The classes that appear in HashMap_policy are loaded item by item from the actual class files. Then, the methods in the class file are individually parsed. For each method, the corresponding path identification and path segment are extracted from the hash table, and there are three contexts for node processing:

1. If it matches the source type, the corresponding statement is located and the control code is inserted before it, which can activate the monitoring of the specified path at runtime.
2. If it matches the branch type, the next branch from the current location is located. For different following paths, the responding control codes are inserted before the first statement of the subsequent target path as shown in Table I in Section III-D. If a node is the non-first repeated node (sn ’=-1), it means that this node has been processed and can be ignored.
3. If it matches the sink type, the corresponding statement is located and the control code is inserted before this statement, which allows information flow control and auditing.

In a path, a method may be called more than once. The newinvoke type is used for updating the current instrument location to the method’s initial node. Due to limited space, the details of the relevant newinvoke nodes in the description of Algorithms 1 and 2 are omitted.

After completing the code instrumentation for related class files by traversing HashMap_policy , a set of new class files is obtained. Then, all the new class files are repacked into.dex files to replace the.dex files in the original APK file. Using the compression package, a new APK file is generated.

The code instrumentation example of InsecureBankv2 is shown in Figure 5. Only the statements before and after the instrumentation node are retained in this figure, and part of the instrumentation for the branch node is omitted. The inserted code is actually a function call code. Considering the hierarchy and interface of the project, the functions needed for actual operation are encapsulated into separate classes. When these functions are called in the running process, the related functions can be realized.

D. Runtime control

The runtime control stage aims to efficiently monitor the change of path states and dynamically prevent information leakage when the leakage path occurs. This section describes the specific control principle based on a finite state machine. The code snippet shown in Figure 1 is taken as an example to illustrate the runtime control mechanism.

If the IFDS algorithm is used to analyze this example, after it traverses the loop body from s 2 to s 5 three times, the nodes <s 3,td >, <s 3,in >, <s 3,a >, <s 3,b >, <s 3,c > in $N^{\ast}$ of the program will be found. When IFDS tries to traverse s 3 for the fourth time, it will find that there is no new node available for the path expansion. Then, IFDS stops traversing the loop body and continues to traverse s 6. Finally, it will output a path $s0-s1-s2_{1}-s3_{1}-s4_{1}-s5_{1}-s2_{2}-s3_{2}-s4_{2}-s5_{2}-s2_{3}-s3_{3}-s4_{3}-s5_{3}-s6$ represents the n-th execution ofsi ), while the actual execution path is ${s0-s1-s2_{1}-s3_{1}-s4_{1}-s5_{1}-s2_{2}-s3_{2}-s4_{2}-s5_{2}-s2_{3}-s3_{3}-s4_{3}-s5_{3}-s2_{4}-s3_{4}-s4_{4}-s5_{4}-s6}$, which leads to information leakage and causes false negatives in IFDS. However, all STA techniques may face this problem.

To deal with this problem effectively, the process of taint propagation is divided into three periods along the path: 1) Forward propagation period (N ): The executed statement is outside the loop, corresponding to the execution period of s 1 and s 6.2) Loop propagation period (P ): The execution statement is in the loop body. According to IFDS, there are still new node extensions in the current loop round that corresponds to the execution period of “$s2_{1}-s3_{1}-s4_{1}-s5_{1}-s2_{2}-s3_{2}-s4_{2}-s5_{2}-s2_{3}-s3_{3}-s4_{3}-s5_{3}$”. 3) Loop stable period (S ): The executed statement is in the loop body structure. According to IFDS, the current loop round has no new node extension. The execution is then no longer tracked by IFDS, which corresponds to the execution period of “$s2_{4}-s3_{4}-s4_{4}-s5_{4}$”.

To avoid the problem of path length explosion, IFDS does not analyze the S period yet still achieves good accuracy. However, further monitoring of the S period is beneficial. If there is a leakage path that includes an S period, it will cause false negatives in the IFDS. The use of an over-accurate STA algorithm for the S period can easily lead to excessive overhead because STA has difficulty in determining the number of loop executions in the S period. Thus, a more effective and reasonable method is required to solve this problem. Before the execution enters into the S period of a loop, it has experienced the P period and reached the maximum taint state by taint accumulation. Thus, to maintain the maximum taint state of the loop, the repetitive execution of the same code segment of a loop in the S period often tends to be stable. In practice, the code in the loops may be repetitive logical behaviors, such as scientific calculation, file reading, and writing, etc. The execution of the path usually does not change the final propagation state of the P period. Thus, these paths are still valid but have no role in propagation. In most cases, to ensure safety, FSAFlow continues to monitor the stable period, and only monitors the key branch nodes to ensure performance and correctness, as shown in Table III. In a few cases, a false positive judgment may occur during the S period. Then, this path’s monitoring policy is revised to reduce the false positive judgments by no longer monitoring its stable period.

Fig. 6.Fig. 6. Path control Automaton

FSAFlow implements the control of the path based on a pushdown automaton, which is an extension of the finite-state automaton and is composed of a state controller, an input, and a stack. As shown in Figure 6, given a path path output by static analysis and assuming its length is N , at runtime the corresponding automaton is formally expressed as $M=(Q,\Sigma,\Gamma,\delta,q_{0,}F)$, where:

1. Q is a finite set of states. Each node i on the path corresponds to a state $q_{i}(i\gt 0).\ q_{0}$ corresponds to the inactive state of the path; q₁ corresponds to the source node; q_n corresponds to the sink node.
2. $\Sigma:2^{\{0,1,\ldots,N\}}\times TYPE\times L_{ID}$ is the input alphabet. Each input symbol corresponds to a monitoring point of FSAFlow, and the input sequence represents the sequence execution of monitoring points for program execution. The input symbol $\sigma$ is composed of a tuple (SNs,type, lia). $SNs\in 2^{\{0,1,\ldots,N\}}$ is the set of allowed node numbers corresponding to the monitoring point. Each node $q_{i}(\gt 0)$ on the path is assigned a node number i in sequence. In a special case, $SNs=\{0\}$ indicates that the monitoring point is on the non-target branch path. type $\in\{in,out,x\}$ is the type of the location of the monitoring point. in/out/x respectively indicate that the monitoring point is an entry/exit point of loop structure and other types. l_id represents the identification of the loop structure. If type=x, then $l_{id}=1$.
3. $\Gamma$: Period $\times L_{ID}$ is the stack alphabet. Stack is a “last in, first out” storage device that records the corresponding execution period of a loop when executing nested loops. Period: $\{N,P,S\}$ respectively represent the forward propagation period $(N)$, loop propagation period $(P)$, and loop stable period $(S).\ L_{ID}$ is the set of IDs of the loop. For a stack symbol $\gamma=($. period, l_id ), if period $=N$, then $l_{id}=-1$.
4. $\delta:Q\times\Sigma\times\Gamma\rightarrow Q\times\Gamma$ is the transition function. According to the current state, if the current input and the symbol are at the top of the stack, the next action of M is determined, including the state transition, and the Push or Pop operation.
5. $q_{0}\in Q$ is the initial state, which indicates that the path is not activated.
6. F:$\{q_{0},\ q_{n}\}\subseteq Q$ is the set of accepting states.

Fig. 7.Fig. 7. Code instrumentation

The transition function of M is listed in Table I. M starts from the state q₀ and the empty stack. After the source statement is executed, it reaches the q₁ state and enters the N period. During the N period, when a branch jump such as If/Switch is encountered, the state will be updated one step forward if the jumping target points to the next node in path ; when a While/For loop is encountered, M will enter the P period, and the state is updated one step forward if both the jumping target and the target path point must enter the loop body. During the P period, when a branch jump is encountered, the state will be updated one step forward if the jumping target points to the next node in path ; otherwise, M will enter the S period if the branch jump enters the loop body again while the next node in path points to the loop exit branch. In this case, it is indicated that the program should continue to execute the loop body after the execution reaches the path’s maximum value of taint propagation. During the S period, the branch that does not jump from the loop body is continuously monitored, and the path state remains unchanged. When a branch that jumps from the loop body is encountered, M will pop up the stack and restore the last period indicated by the stack as the current period. Then, it continues tracking and monitoring according to different period requirements. During the P or S period, loop nesting will occur if M determines to enter a different loop by distinguishing the loop ID. In this case, new period information will be pushed into the stack, and the assignment of the new period remains that of the current period. If other situations are encountered, M will return to the q₀ state and clear the stack.

FSAFlow exploits global variables to record the execution states and the stack of all supervised paths. As shown in Figure 1, the example has four monitoring points. The main control codes of these monitoring points are shown in Figure 7.

If the execution reaches the corresponding monitoring point of the sink, FSAFlow will check whether the execution matches the required state. If so, FSAFlow will limit the execution of the sink. If the intercepted sensitive data are numeric, they are assigned the value 0. If the intercepted sensitive data are character data, the character is first replaced with the ASCII code for 0. To prevent covert communication by using the length of sensitive data, the random number generation API is further called to determine the length of cleared character data randomly. This confuses potential eavesdroppers, rendering it difficult to determine if the received information is truly sensitive and from their partners. Finally, to avoid affecting the normal functioning of the program, the purified data is passed to the sink point for execution. Moreover, the users will be notified that information has been intercepted, as shown in Figure 8 (c). To prevent attackers from removing path monitoring code from an app by upgrading the software, FSAFlow records the fingerprint of each app’s executable file. FSAFlow will always first check whether the fingerprint has changed before an app runs. If it has changed, the user must re-apply for the app’s path monitoring. Furthermore, to prevent attackers from escaping detection through complex reflections, we will adopt a strict taint-sensitive policy: if any input parameters are tainted, all output parameters in the reflections will be tainted. This taint propagation policy is relatively strict, but it may be the best practical approach to prevent attacks.

As concerns the tracking of native calls, similar to FlowDroid, FSAFlow directly updates the taint state of the parameter variables of the call by following predefined propagation rules, rather than entering the native call body to continue the analysis. This reduces the difficulty of path control in tracking. Accordingly, the internal statements of the native method will not be recorded on the path. FSAFlow can still monitor the path by setting monitoring points at branch statements without additional processing.

E. Implementation

The completion of each step in the FSAFlow system is shown in Figure 8. The interaction between the client and server adopts the WebSocket protocol and full-duplex mode to enhance the stability and availability of the system.

The cloud server was written in Java, JDK 1.8. The static path analysis module was developed by modifying more than 2000 lines of FlowDroid code. The path monitoring instrumentation framework of FSAFlow was developed on the SOOT platform, where the intermediate representation of the 3-address code provided by Jimple, and the accurate call graph analysis framework lay an important foundation for the FSAFlow system. Meanwhile, the Dexpler plugin and Heros framework were also used. The client apps can run on the latest version of Android, which is downward compatible with Android 4.0 and above.

Figure 8(a) illustrates the user-defined information flow-path management interface of FSAFlow. The function of selecting the target APK file and selecting the information flow source node and sink node has been realized. After being submitted to the cloud server for processing, as shown in Figure 8(b), the new APK file can be downloaded through the query function. Taking InsecureBankv2 as an example, the running of the processed APK file is shown in Figure 8(c)-(f). Before the sensitive information is leaked out by the information flow, it will be limited, and a notification will be sent to the user after being successfully intercepted, as shown in Figure 8(c)-(d). The user can click on the notification to view the details of the leakage path, which is shown in Figure 8(e)-(f).

Fig. 8.Fig. 8. Components of FSAFlow

FastDroid ^[69] is an STA method, similar to FlowDroid. FastDroid implements a static information flow search based on a taint value graph by modifying the FlowDroid tool. Although the experiment in ^[69] showed that FastDroid can obtain better search performance, FSAFlow is not implemented on Fast-Droid since FastDroid’s path is only composed of variable relationships. The statements on the path, including branch statements, are invisible in FastDroid, which makes it difficult to extract key path information from its output for path tracking.

F. Limitations

False negatives/positives: FSAFlow searches all paths using the STA tool FlowDroid. Although STA benefits from analyzing the complete program code, FSAFlow may exhibit false negatives due to implementation limitations ^[70], such as reflective calls and inaccessible code. FlowDroid resolves reflective calls only if their arguments are string constants. However, if reflective call targets are determined by external configuration or network servers, the edge of a reflection call will be lost in the ICFG, resulting in potential false negatives. In order to prevent malicious developers from writing their code deliberately like that to leak whatever they want to leak, our further work will adopt a strict taint-sensitive policy mentioned in Section III D. For native code, FlowDroid assumes a sensible default: the call arguments and the return value become tainted if at least one parameter is previously tainted. Although this may be the best practical approximation in a black-box setting, it is also generally unsound. To minimize the storage overhead, FSAFlow may also exhibit false positives in coarse tracking granularity for arrays, lists, etc.

Partially support for multithreading: FSAFlow has three phases: program static analysis, static instrumentation, and runtime control. FSAFlow ’s runtime control can handle multithreaded cases since it sets the path states as global variables that are managed through synchronized monitoring functions. Calls to these functions are multithreading-safe. FSAFlow’s static analysis is implemented on the modified FlowDroid. FlowDroid itself partially supports multithreading analysis, including AsyncTask/Java’s normal threading/Java’s Runnable mechanisms. Should the improvement to FlowDroid support more multithreading mechanisms, such as Java’s Executor mechanism, FSAFlow would provide full multithreading support.

Implicit flows: Untrusted programs can launder taint through implicit flows ^[63][64], which poses a greater challenge to privacy protection. Similar to FlowDroid, FSAFlow cannot analyse implicit flows through table lookups. For implicit flows through control dependencies, pure DTA systems may incur significant performance overhead due to the lack of comprehensive branch structure information ^[30]. Although both our evaluations and the analysis of the IFDS algorithm in Section V-B-3) show that the performance of FSAFlow is not significantly affected in most cases, there remain a few where large-scale implicit flows can be identified, and solutions must still be developed. For how to decide whether an implicit flow is a true violation, FSAFlow comes to a decision according to the user-defined policies, avoiding the difficulties in judging the code among benign and malicious cases. All information flows, including implicit information flows, from a source to a sink that are prohibited by the user will be prevented by FSAFlow.

In general, implicit flows (as well as reflection and native code) remain major problems, however, our solution to implicit flow control caters mostly to benign code that is written so as to avoid such complicating constructs. For instance, a developer may vouch for a program’s trustworthiness by indicating that it is fit for FSAFlow. Future work will attempt to analyze the specific characteristics and behaviors of malicious implicit flows for reducing misjudgment.

IV.   Function & Complexity Analysis

This section reports on the theoretical analysis conducted to prove that FSAFlow can perform correct instruction tracking and it is more efficient than the classic DTA system.

A. Function Analysis

For ease of description, a definition is presented as follows:

B. Complexity Analysis

V.   Evaluation

This section reports on how FSAFlow’s function and performance were evaluated. Experiments were performed on a simulator. The host ran Windows 10, and was equipped with an Intel(R) Core (TM) i7-10710U CPU with 16.0 GB RAM. The simulator environment is a Pixel 2 smartphone with Android 10.0, API 29.

A. Function Evaluation

This function evaluation verifies whether the system correctly prevents the release of prohibited information and releases authorized information. Conventional DTA may produce false negatives due to its low code coverage, while FSAFlow may exhibit false negatives due to its implementation limitations during the static analysis stage. We mainly compared FSAFlow with TaintDroid, an important DTA tool, from the perspective of false negatives. Considering that FSAFlow is based on FlowDroid, a well-known STA tool, FlowDroid was also chosen to mainly compare false positive rates because this is a common problem in STA. For the evaluations, implicit flow analysis was only enabled in FSAFlow and FlowDroid, since TaintDroid cannot support it.

1. First, DroidBench 2.0 ^[57] was exploited to verify function adaptability in mining specific information flow paths. DroidBench2.0 is an open-source benchmark suite for comparing Android taint-analysis functions.
2. Since FlowDroid and TaintDroid can only perform analysis but not control, their test results were judged by whether the given path can be found, while the test results of FSAFlow were judged by whether the given path can be intercepted at runtime. A11120 apps in DroidBench 2.0 were used and divided into 13 categories. FSAFlow/FlowDroid defines more sources than DroidBench, such as getLastKnownLocation, etc. To focus on function evaluations, the leakage paths brought by such sources are marked as positive cases. The test results are listed in Table II.
3. There are 115 leakage paths among all the test cases. Both FlowDroid and FSAFlow found 101 of these paths, but FlowDroid misreported eight paths, while FSAFlow misreported five. The three paths that FlowDroid misreported and FSAFlow did not misreport actually never occur in tests. These are Unregisterl/Callbacks , Exceptions3/General Java , and VirtualDispatch3/General Java . FlowDroid does not provide a more precise analysis of the codes in the unregistered-again callback, the non-occurring exceptions, and the nevercalled factory method. The five paths misreported by FSAFlow involved a coarse-grained array or list tracking, and inaccurate backward alias analysis. To avoid incurring a significant storage overhead, all data items in an array or a list share the same taint tag, which caused four false positives.
4. FlowDroid and FSAFlow missed 14 paths, mainly because some special codes were not tracked, including propagating taints across interleavings of separate components (Singletons1/ ICC), ICC Handler constructs (ServiceCommunicationl/I CC), static initialization method (StaticInitializationl/General java), formatter (StringFormatterl/General java), etc.
5. TaintDroid adopts a coarse-grained tracking strategy similar to FlowDroid, and stores only one taint tag per array/list/ object to minimize the storage overhead. Thus, it misreported seven paths in the tests of Arrays, Lists, and object fields. It missed 15 paths, seven of which were implicit flow paths. TaintDroid does not track control flows and it missed seven implicit flows generated by the control-flow dependency in the ImplicitFlow 1-4/ImplicitFlows tests. Instead, FSAFlow/FlowDroid tracks implicit flow generated by control dependency. Additionally, TaintDroid cannot track taint propagation in some specific objects, such as Sharedreferences (SharedPreference-Changedl/ lifecycle), or for specific sources such as findViewById (Private DataLeakl-2/AndroidSpecific), etc.
6. In short, FSAFlow achieved a recall of 87.83% and a precision of 95.28%. FlowDroid also achieved a recall of 87.83%, but only 92.66% for precision. TaintDroid achieved a recall of 86.96% and a precision of 93.46%.
7. The tracking ability during the loop stable period was then tested. DroidBench 2.0 have very few loop structures. Therefore, a java program, GT , was written to produce test cases with taint propagation in loop bodies. The input parameters of GT included the number M of variables (including a source variable in and a sink variable out ), the number N of statements contained in a loop body, the number of loop laps L (L >M ), and the number K of loop nesting layers. Each statement was a simple assignment of x =y or x =0. GT first randomly generated schemes of assignment statements in loop bodies, then the schemes with propagation from in to out in the loop bodies were selected. A test case in the form of a java file was generated according to a selected scheme. The case first obtained the mobile IMEI and then sent the information by SMS after propagating in nested loops. Because L >M , all the cases had loop stable periods. Three groups of cases were output. Each group had 20 cases that used the same parameter settings. The test results are listed in Table III. FlowDroid did not track in loop stable periods, causing all leakage paths to be missed and misreported 95 paths that did not actually occur. FSAFlow only misreported three paths and had no false negatives. The exceptions had forms akin to a loop body: {out -in, in =0;}. Although out was infected in the first round, it was cleaned again in the second round. Such loop processing may have little meaning since it rarely appears in practice.
8. Finally, the functions were evaluated on 150 popular real-world apps from HUAWEI and Google’s app store. These were randomly selected from 15 different categories. These apps were shown as benign by VirusTotal, an authoritative website that provides malware-analysis services. For the paths found by FlowDroid, FSAFlow, and TaintDroid, since there was no available information about the privacy leakage of these apps, manual horizontal comparison and analysis were conducted according to the app functions, self-declarations, and user comments on the app stores, The test results are listed in Table IV.

Thirty-two apps were found that have potential leakage paths. The main basis of judgment was that these release paths were not identified by the declarations of these apps, and they were not related to the main functions. For example, the Currency world app in the Finance category collects user accounts and writes them to a local file without prompting the user. The Fit fitness app in the Sports and Health category sends location data to advertising service providers.

All three tools exhibit analysis errors. As for false negatives, TaintDroid missed two leakage paths on LET Vvideo, dragonfly FM in the Media and Entertainment category because it did not track interface input information (e.g., passwords), while FSAFlow and FlowDroid reported correctly. However, FSAFlow and FlowDroid failed to report one leakage path where the information of dynamic reflection is stored in configuration files, such as Car Headlines from the Cars category, while TaintDroid reported correctly. Regarding false positives, the three tools all misreported one leakage path involving arrays in Baby Read from the Kids category because of their coarse tracking granularity for arrays. Besides, FlowDroid misreported 1 leak path that will not occur in the Touch app of the Communication category. The APK file of this application contains debugging code that does not execute at runtime. FSAFlow could avoid this misreport by runtime verification.

B. Performance Evaluation

FSAFlow’s performance was evaluated by comparing it with some representative optimization techniques on DTA. In the evaluations, the implicit flow analysis was enabled in FSAFlow only, since the DTA techniques used for comparison

1. Evaluation on real-world apps. The selected test cases are 32 apps with potential leakage paths from evaluation A-3).
2. We compared FSAFlow’s static analysis with FlowDroid, and compared FSAFlow’s runtime control with Tracking On Demand (TOD), Local Code optimization (LCO), Optimal Hybrid Analysis (OHA) and native Android system (Baseline). LIFT ^[47] was chosen as the TOD reference. LIFT checks whether all live-in/out variables are safe before tracking a basic block. If so, it runs the basic block without any tracking; otherwise, it runs the basic block with conventional tracking. Since LIFT’s implementation does not support Android, a simulation analysis was conducted on the best case of LIFT. In this case, LIFT did not spend any time determining whether basic blocks need to be tracked, but made quick operations directly on the basic blocks that had been inserted. In our experiment, it was manually determined whether there are already contaminated variables in a basic block before the execution enters this basic block; if so, we inserted tracking instructions into the basic block. CDroid ^[21] was chosen as an LCD reference, and it deploys local code optimization methods on hot traces, including reductant taint load/store elimination, reductant taint compute elimination, taint load hoisting and taint store sinking. Iodine ^[9] was chosen as an OHA reference. In the static analysis stage, Iodine only inserts tracking instructions for the statements that change the taint state of expected executions rather than all executions. Iodine realized rollback-free recovery from unexpected executions for its DTA to be sound. Since Iodine’s implementation also does not support Android, simulation analysis was conducted on the best case of Iodine. In this case, let Iodine execute the leakage path as a fast path without triggering a tracking failure/recovery mechanism. According to Iodine’s principle for fast path optimization, we only inserted tracking instructions for the statements whose source operands could be tainted by the taint source in forward STA, and destination operands could reach the sink in backward STA along the leakage path.
3. In these test cases, different operations were performed for different applications to trigger the corresponding paths and test their execution time. For instance, in shopping apps, the leakage path of a payment password could be triggered by clicking the confirm button; in communication apps, the leakage path of the chat messages could be triggered by clicking the send button. Twenty tests were performed on each app, and the average execution time was recorded. The test results are listed in Table V.
4. FSAFlow incurred a slightly higher overhead in static analysis than FlowDroid, which indicates that FSAFlow takes less time to extract key additional path information. FSAFlow needed less time in static analysis than in static instrumentation, mainly because only the key nodes of a few paths were instrumented with monitoring pointers. As for runtime tracking, compared with native Android, the average overhead of CDroid, LIFT, Iodine and FSAFlow respectively was 13.93%, 9.06%, 5.05% and 2.06%. Both LIFT and Iodine have lower overhead than CDroid. Although the test result of Iodine is closest to that of FSAFlow, it is obtained in Iodine’s best case, that is, let Iodine execute the leak path as a fast path without triggering a failure/recovery mechanism during the experiment. Note that the overheads of LIFT and Iodine fluctuated, because of the diverse sizes of flow statements contained in the different paths they encountered. In contrast, FSAFlow had the lowest overhead with good robustness, which is attributable to the branch statements accounting for a small proportion of statements on most paths. Thus, the code execution of the corresponding monitoring point had little impact on the program execution time.
5. Evaluation on the CaffeineMark 3.0 benchmark. This benchmark uses a scoring metric to measure various aspects of system performance. The test on CaffeineMark 3.0 is scored by dividing the number of executed cases by the time taken to execute all the cases. Its six test cases that can run on Android were modified, and all were computationally intensive. The test objective was to obtain the overhead of FSAFlow when the CPU performed intensive sensitive information flow operations. Specifically, the initially assigned variable was set as the source node, and the output result variable was set as the sink node to perform path tracking. LIFT and Iodine were simulated using the method in 1). The test results are shown in Figure 9.
6. The respective scores of the native Android system, CDroid, LIFT, Iodine, and FSAFlow are 5975 $(S_{B})$, 4965 $(S_{O1})$, 5190 $(S_{O2})$, 5431 $(S_{O3})$, and 5652 $(S_{O4})$. Compared with the native Android, the average overhead of CDroid, LIFT, Iodine and FSAFlow respectively are 16.90%, 13.14%, 9.10% and 5.41% (overhead percentage $=(S_{B}-S_{Oi})/S_{B}$). The results in Figure 9 show that the overhead of FSAFlow caused by using loop and logic cases is higher than that of other cases. This may be due to the code structure of loop and logic encountering more branch nodes, which increases path state monitoring. CDroid incurs higher overhead in string cases than other cases. This is probably due to the additional memory comparisons for string objects in method prototypes. Iodine and Lift have higher overhead in method cases than in other cases, which may be caused by more taint propagation statements in the target path in method cases. The score of FSAFlow is close to that of the native Android system, proving that our tracking method is more efficient.
7. The results of Evaluation 1) and 2) show that FSAFlow has better performance than several representative optimization approaches, such as Iodine (Hybrid Analysis), LIFT(Tracking On Demand), and CDroid (Local Code optimization).
8. Evaluation of implicit flow analysis. The test is divided into five groups. The first group consists of 32 apps in Table V, and each remaining group consists of eight randomly selected samples from the same family in the malware dataset Drebin ^[66]. Comparative experiments were conducted with and without implicit flow enabled. Ten tests were performed on each group, and the average execution time was recorded. The final test results are listed in Table VI.
9. The results show that adding implicit flow analysis may add insignificant overhead to FSAFlow. Moreover, the number of leak paths output by FSAFlow increases minimally. The main reasons are as follows: (a) The static IFDS algorithm performs width-first traversal to access the branch structure information, thus rapidly calculating the taint propagation caused by the control dependencies. (b) In IFDS, the control-dependent taint propagation in conditional branches will not occur if independent variables are not tainted. (c) Furthermore, in these test cases, the tainted variables were found to appear rarely in conditional jump statements, indicating that the sensitive information flows seldom affect the control behaviors of real apps. (d) Even in the case of some malware attempting to convey sensitive information through implicit flows, to hide itself, the number of instructions involved in the leakage path is very small, resulting in the cost of FSAFlow tracking the small fragment of code controllable.

Fig. 9.Fig. 9. Performance Test Scores of CaffeineMark 30

VI.   Related Work

In this section, the previous research on DTA, DTA optimization, and hybrid analysis (HA) are introduced. The limiting factors are also discussed, casting the problem in terms of DTA optimization and proposing a new methodology based on HA.

A. Dynamic Taint Analysis

There has been considerable research on DTA systems ^{[19],[28],[30],[33],[35],[53}–^56]. The time overhead of Dytan for data-flow based propagation alone was approximately 30x, whereas the overhead imposed by control- and data-flow based propagation was approximately 50x ^[33]. Panorama was 20 times slower on average ^[28].

B. DTA optimization

Past work has developed many optimized DTA techniques. Important paths explored by previous research include:

Hardware support : The hardware typically consists of logic blocks that monitor the execution of each instruction in the processor and keep track of the tag information flowing from the execution unit at every cycle ^[5],[38–^41]. Many hardware acceleration schemes require additional non-standard commodity components or a redesign of the entire processor core, which limits the practicality of these approaches.

Parallelization : The proliferation of multicore systems has inspired researchers to decouple taint tracking logic to spare cores to improve performance ^{[36],[37],[44}–^46],[65]. ShadowReplica ^[65] spawns a secondary shadow thread from the original process to run DTA on spare cores in parallel. ShadowReplica performs a combined offline dynamic and static analysis of the application to minimize the data that must be communicated for decoupling the analysis. However, ShadowReplica’s performance improvement achieved by this “primary & secondary” thread model is fixed and cannot be improved further when more cores are available ^[37]. TaintPipe ^[37] spawns multiple threads or processes in different stages of a pipeline to carry segmented symbolic taint analysis in parallel. Its pipeline style relies on straight-line code with very few runtime values, enabling lightweight online logging and a significantly lower runtime overhead. These efforts reduce the latency of DTA through parallelization, but also require OS or hardware level support, which limits commercial applications.

Intermittent tracking : Performance is improved by dynamically deactivating tracking under certain conditions, e.g., when the program does not operate on tagged data ^{[41],[47],[48]} or when it is not handling risky tasks (reading network data) ^[49],[51]. Data tracking can also be applied on-demand based on CPU usage, or by manual activation ^[50]. The disadvantage of this kind of research work is that it fails to determine the timing of dynamic opening or closing. Non-professional users may suffer from privacy leakage when turning off taint tracking. Performance loss can also be incurred by the dynamic switch.

Code optimization : Frequently executed taint logic code incurs substantial overhead. The work in ^[31] developed function summaries to track taint at the function level. Jee et al. ^[52] proposed Taint Flow Algebra to abstract and optimize taint logic for basic blocks. In ^[13] several lightweight taint propagation optimization methods were deployed on hot traces. Taint Rabbit ^[68] employed a JIT compiler to optimize generic taint analysis. Basic blocks without operating taints were not tracked, while the frequently executed basic blocks with operating taints were further subdivided to only track sub-blocks that operate taints. For software vulnerability analysis, Neutaint ^[15] exploited machine learning methods to model the reachability from hot bytes in the input to the sink nodes. Such vulnerability can be exploited and attacked using the hot byte. In privacy protection, privacy data such as phone numbers are often sent to the sink in entirety. Often, the status of hot bytes is equivalent, which may be not suitable for privacy protection. Code optimization can only be realized for specific code features, and their effect is limited.

C. Hybrid analysis

Hybrid analysis (HA) uses static analysis to narrow the scope of code pieces to be examined at runtime and then perform dynamic analysis on them. Many well-known STA tools ^[57–^59] can be exploited by hybrid analysis to complete pre-optimized tracking logic ^[9]–^{[10],[52],[60],} pre-reduced tracking range ^[10],[61], and share some tracking tasks ^[62]. While ^[10] used sound STA conservatively to reduce dynamic overheads. Iodine ^[9] and OHA ^[60] further reduced runtime overheads using unsound and predicated static analysis. They provided a recovery mechanism to handle any potential unsoundness in speculative execution. In OHA, the program execution was replayed from the beginning and analyzed, which is not feasible for online security analysis of live executions ^[9]. To solve this problem, Iodine exploited constraint predicated static analysis to achieve forward recovery. To optimize tracking, Iodine inserted monitoring points only at the statements that can change the taint state of variables when the fast-path is executed. However, if the execution probabilities of fast- and slow-paths are equal in the program to be analyzed, or the profiling of whether the path is fast or slow is inaccurate, they exhibit no advantages, conversely, considerable path switching and recovery overheads will be incurred. The current hybrid analysis shows that the DTA retains several dynamic single-step taint tracking instructions. The extant hybrid analysis methods only have advantages in some specific situations. The proposed FSAFlow differs from these methods since FSAFlow realizes a complete separation of the slow one-by-one tracking logic and dynamic operation in a program, and is continuously efficient for Android privacy protection through path monitoring.

HA also has many practical applications. As a vulnerability protection tool, DynPTA ^[67] uses scoped byte-level DTA to narrow the range of objects identified for static pointer analysis. DynPTA only optimizes DTA specifically in loop optimizations for array accesses. According to the results of pointer analysis, the selective data is encrypted to prevent external attacks from exploiting the vulnerability of pointer misuse to obtain sensitive data. FSAFlow’s purpose differs from that of DynPTA. FSAFlow optimizes the performance of taint tracking and further prevents untrusted programs from actively leaking private information.

VII.   Conclusion

A novel approach, FSAFlow, is proposed to perform a hybrid analysis for privacy protection. This solves the key overhead problem of applying DTA. The central concept of FSAFlow is to completely separate the one-by-one tracking logic and the program execution and perform tracking control based on the path instead of the taint. FSAFlow manages the path state through FSA. Because the state transition of the path mainly depends on the branch statements rather than all the statements, FSAFlow runs efficiently. The theoretical and experimental analysis proves that implementing FSAFlow is rational and efficient.