tifact

Ar en
t * Complete
*

AECDo
*
se * Consist
PLDI *

We
ll
FlowDroid: Precise Context, Flow, Field, Object-sensitive

*
cu m
eu

Ev
e
nt R

*
ed
* Easy to
alu
at e d
and Lifecycle-aware Taint Analysis for Android Apps
Steven Arzt, Siegfried Rasthofer, Alexandre Bartel, Jacques Klein, Damien Octeau, Patrick McDaniel
Christian Fritz, Eric Bodden and Yves Le Traon Department of Computer Science and
EC SPRIDE Interdisciplinary Centre for Security, Engineering
Technische Universität Darmstadt Reliability and Trust Pennsylvania State University
[email protected] University of Luxembourg {octeau,mcdaniel}@cse.psu.edu
[email protected]

Abstract 1. Introduction
Today’s smartphones are a ubiquitous source of private and confi- According to a recent study [9], Android has seen a constantly
dential data. At the same time, smartphone users are plagued by growing market share in the mobile phone market, which is now
carelessly programmed apps that leak important data by accident, at 81%. With Android phones being ubiquitous, they become a
and by malicious apps that exploit their given privileges to copy such worthwhile target for attacks on users’ privacy-sensitive data. Felt et
data intentionally. While existing static taint-analysis approaches al. classified different kinds of Android malware [12] and found that
have the potential of detecting such data leaks ahead of time, all ap- one of the main threats posed by malicious Android applications
proaches for Android use a number of coarse-grain approximations are privacy violations which leak sensitive information such as
that can yield high numbers of missed leaks and false alarms. location information, contact data, pictures, SMS messages, etc.
In this work we thus present F LOW D ROID, a novel and highly to the attacker. But even applications that are not malicious and
precise static taint analysis for Android applications. A precise were carefully programmed may suffer from such leaks, for instance
model of Android’s lifecycle allows the analysis to properly handle when they contain advertisement libraries [16]. Many app developers
callbacks invoked by the Android framework, while context, flow, include such libraries to obtain some remuneration for their efforts,
field and object-sensitivity allows the analysis to reduce the number but few of them fully understand their privacy implications, nor
of false alarms. Novel on-demand algorithms help F LOW D ROID are they able to fully control which data these libraries process.
maintain high efficiency and precision at the same time. Common libraries distill private information that identifies a person
We also propose D ROID B ENCH, an open test suite for evaluating for targeted advertisement such as unique identifiers (e.g., IMEI,
the effectiveness and accuracy of taint-analysis tools specifically MAC-address, etc.), country or location information.
for Android apps. As we show through a set of experiments using Taint analyses address this problem by analyzing applications
SecuriBench Micro, D ROID B ENCH, and a set of well-known An- and presenting potentially malicious data flows to human analysts
droid test applications, F LOW D ROID finds a very high fraction or to automated malware-detection tools which can then decide
of data leaks while keeping the rate of false positives low. On whether a leak actually constitutes a policy violation. These ap-
D ROID B ENCH, F LOW D ROID achieves 93% recall and 86% pre- proaches track sensitive “tainted” information through the applica-
cision, greatly outperforming the commercial tools IBM AppScan tion by starting at a pre-defined source (e.g. an API method return-
Source and Fortify SCA. F LOW D ROID successfully finds leaks in a ing location information) and then following the data flow until it
subset of 500 apps from Google Play and about 1,000 malware apps reaches a given sink (e.g. a method writing the information to a
from the VirusShare project. socket), giving precise information about which data may be leaked
where. The analyses can inspect the app both dynamically and stati-
Categories and Subject Descriptors F.3.2 [Semantics of Program- cally. Dynamic program analyses, though, require many test runs
ming Languages]: Program analysis; D.4.6 [Security and Protec- to reach appropriate code coverage. Moreover, current malware can
tion]: Information flow controls recognize dynamic monitors as the analyzed app executes, causing
the app to pose as a benign program in these situations.
While static code analyses do not share these problems, they run
the risk of being imprecise, as they need to abstract from program
inputs and to approximate runtime objects. The precise modeling
of the runtime execution is particularly challenging for Android
apps, as those apps are no stand-alone applications but are actually
Permission to make digital or hard copies of all or part of this work for personal or plugins into the Android framework. Apps consist of different
classroom use is granted without fee provided that copies are not made or distributed components with a distinct lifecycle. During an app’s execution,
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
the framework calls different callbacks within the app, notifying
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, it of system events, which can start/pause/resume/shutdown the
to post on servers or to redistribute to lists, requires prior specific permission and/or a app etc. [17]. To be able to effectively predict the app’s control
fee. Request permissions from [email protected]. flow, static analyses must not only model this lifecycle, but must
PLDI ’14, June 9-11 2014, Edinburgh, United Kingdom. also integrate further callbacks for system-event handling (e.g., for
Copyright c 2014 ACM 978-1-4503-2784-8/14/06. . . $15.00.
http://dx.doi.org/10.1145/2594291.2594299
phone sensors like GPS), UI interaction, and others. As we show in
this work, recognizing callbacks is anything but trivial and requires • F LOW D ROID, the first fully context, field, object and flow-
dedicated algorithms. Another challenge is posed by sources of sensitive taint analysis which considers the Android application
sensitive information such as password fields in the user interface. lifecycle and UI widgets, and which features a novel, particularly
The respective API calls returning their contents cannot be detected precise variant of an on-demand alias analysis;
based on the program code alone. Instead, their detection requires • a full open-source implementation of F LOW D ROID,
a model of auxiliary information stored in the manifest and layout
XML files. Last but not least, like any application written in Java, • D ROID B ENCH, a novel, open and comprehensive micro bench-
Android apps also contain aliasing and virtual dispatch constructs. mark suite for Android flow analyses,
Typical static analyses for Java handle these problems through some • a set of experiments confirming superior precision and recall
degree of context and object sensitivity. The framework nature of of F LOW D ROID compared to the commercial tools AppScan
Android makes this problem harder than usual, as we found it to Source and Fortify SCA, and
expose extraordinarily deep aliasing relationships.
• a set of experiments applying F LOW D ROID to over 500 apps
Past data-flow analysis approaches for Android [14, 15, 24,
40] handle the above challenges in an unsatisfactory manner us- from Google Play and about 1000 malware apps from the
ing coarse-grained over- as well as under-approximations. Under- VirusShare project [1].
approximations, usually caused by the lack of a faithful lifecycle We make available online our full implementation as an open
model, can cause these analyses to miss important data flows. In source project, along with all benchmarks and scripts to reproduce
practice even worse, though, the tools’ over-approximations can our experimental results:
cause many false warnings, easily overwhelming security analysts
to the point at which they stop using the analysis tools entirely. http://sseblog.ec-spride.de/tools/flowdroid/
In this work, we therefore present F LOW D ROID, a novel static
Space limitations preclude us from including some details necessary
taint-analysis system specifically tailored to the Android platform,
to fully reproduce our approach. We thus publish an accompanying
and based on novel on-demand algorithms that yield high precision
Technical Report, [13] which formalizes F LOW D ROID’s transfer
while maintaining acceptable performance. F LOW D ROID analyzes
functions and gives additional details on the implementation.
the apps’ bytecode and configuration files to find potential privacy
The paper continues as follows. Section 2 gives a motivating
leaks, either caused by carelessness or created with malicious
example and explains the necessary background on Android security.
intention. Opposed to earlier analyses, F LOW D ROID is the first
Section 3 explains how F LOW D ROID models the Android lifecycle
static taint-analysis system that is fully context, flow, field and
while Section 4 gives important details about the actual taint
object-sensitive while precisely modeling the complete Android
analysis. In Section 5, the paper discusses implementation details
lifecycle, including the correct handling of callbacks and user-
and limitations, while Section 6 evaluates F LOW D ROID. Section 7
defined UI widgets within the apps. This design maximizes precision
discusses related work and Section 8 concludes.
and recall, i.e., aims at minimizing the number of missed leaks
and false warnings. To obtain deep context and object sensitivity
while maintaining acceptable performance, F LOW D ROID uses a 2. Background and Example
novel on-demand alias analysis. The analysis algorithm is inspired
by Andromeda [37] but improves over Andromeda’s in terms of We start by giving a motivating example and then explain the attacker
precision. We have open-sourced F LOW D ROID in summer 2013. model this work assumes. The example in Listing 1 (abstracted from
The tool has already been picked up by several research groups and a real-world malware app [42]) implements an activity, which in
we are in contact with a leading producer of anti-virus tools, who Android represents a screen in the user interface. The app reads
plans to use F LOW D ROID productively in the analysis backend. a password from a text field (line 5) whenever the framework
For us and others to be able to measure scientific progress in restarts the app. When the user clicks on a button of the activity, the
this important field of research it is required that researchers are password is sent via SMS (line 24). This constitutes a tainted data
able to conduct comparative studies of Android taint-analysis tools. flow from the password field (the source) to the SMS API (the sink).
Unfortunately, up until now there exist no benchmarks that would In this example, sendMessage() is associated with a button in the
allow for systematic studies. As another contribution of this work app’s UI, which is triggered when the user clicks the button. In
we thus make available D ROID B ENCH, a novel open-source micro- Android, listeners are defined either directly in the code or in the
benchmark suite for comparing the effectiveness of taint analyses for layout XML file, as is assumed here. Thus, analyzing the source code
Android. We have made D ROID B ENCH available online in spring alone is insufficient—the analysis must also process the metadata
2013 and know of several research groups who have used it already files to correctly associate all callback methods. In this code a leak
to measure and improve the effectiveness of their Android analysis only occurs if onRestart() is called (initializing the user variable)
tools [19]. A first group of external researchers has already agreed before sendMessage() executes. To avoid false negatives, a taint
to contribute further micro benchmarks to the suite [35]. analysis must model the app lifecycle correctly, recognizing that a
F LOW D ROID can be used to secure in-house developed Android user may indeed hit the button after an app has restarted.
apps as well as assist in the triage of Android malware. Both To avoid false positives, an analysis of this example must be
use cases demand not a perfect but yet a reasonably low rate field sensitive: the user object contains two fields for the user name
of false positives and false negatives. A set of experiments with and password, but only the latter of which should be considered a
SecuriBench Micro, D ROID B ENCH and some well-known apps private value. Object-sensitivity, while not required for this example,
containing data leaks shows that F LOW D ROID finds a very high is essential to distinguish objects originating at different allocation
fraction of data leaks while keeping the rate of false positives low. sites but reaching the same code locations. In our experiments we
On D ROID B ENCH 1.0, F LOW D ROID achieves 93% recall and 86% found some cases requiring deep object sensitivity to be able to
precision, greatly outperforming the commercial tools AppScan automatically dismiss false positives. This is due to the relatively
Source [2] and Fortify SCA [3]. Further experiments with real apps deep call and assignment chains of the Android framework.
confirm F LOW D ROID’s utility in practice. Operations such as string concatenation (line 19) require a model
To summarize, this work presents the following original contri- that defines whether and how data flows through those operations.
butions: Treating such operations as normal method calls and analyzing
library methods like application code can be imprecise (because
 to start or stop the component, or to pause or resume it, depending
1 public class LeakageApp extends Activity {
2 private User user = null ;
on environment needs. For instance, it can stop an application be-
3 protected void onRestart () { cause of memory depletion, and later restart it when the user returns
4 EditText usernameText = to it [17]. In result, when constructing a call graph, Android analy-
( EditText ) findViewById ( R . id . username ) ; ses cannot simply start by inspecting a predefined “main” method.
5 EditText passwordText = Instead, all possible transitions in the Android lifecycle must be
( EditText )findViewById(R.id.pwdString); modeled precisely. To cope with this problem, F LOW D ROID con-
6 String uname = usernameText . toString () ; structs a custom dummy main method emulating the lifecycle. In the
7 String pwd = passwordText . toString () ; following we explain how this method is constructed.
8 if (! uname . isEmpty () && ! pwd . isEmpty () )
9 this . user = new User ( uname , pwd ) ; Asynchronously executing components An application can con-
10 } tain multiple components, e.g., three activities and one service. Al-
11 // Callback method in xml file though the activities run sequentially, one cannot pre-determine their
12 public void sendMessage ( View view ) {
13 if ( user == null ) return ;
order. One activity could, for instance, be the main one initially visi-
14 Password pwd = user . getpwd () ; ble to the user and then launch either one of the others depending on
15 String pwdString = pwd . getPassword () ; user input. Services run as parallel background tasks. F LOW D ROID
16 String obfPwd = " " ; models this execution by assuming that all components (activities,
17 // must track primitives : services, etc.) inside an application can run in an arbitrary sequential
18 for ( char c : pwdString . toCharArray () ) order (including repetition). Some static analyses are path sensi-
19 obfPwd += c + " _ " ; // String concat . tive, i.e., consider each possible program path separately. In such
20 cases, considering all possible orderings would be very expensive.
21 String message = " User : " + F LOW D ROID bases its analysis on IFDS [32], an analysis frame-
22 user . getName () + " | Pwd : " + obfPwd ;
23 SmsManager sms = SmsManager . getDefault () ;
work which is not path sensitive and instead joins analysis results
24 sms.sendTextMessage( " +44 020 7321 0905 " , immediately at any control-flow merge point. F LOW D ROID can thus
25 null , message , null , null ) ; generate and efficiently analyze a dummy main method in which
26 } every order of individual component lifecycles and callbacks is
possible; it does not need to traverse all possible paths.
Listing 1: Example Android Application
Callbacks The Android operating system allows applications to
register callbacks for various types of information, e.g., location
updates or UI interactions. F LOW D ROID models these callbacks in
it ignores the operations’ semantics) and, as we found, is often its dummy main method, for instance to recognize cases where an
forbiddingly expensive in practice. application stores the location data that the framework passes to the
callback as a parameter, and later sends this data to the Internet when
Attacker model F LOW D ROID can be used to detect data flows the activity is stopped. The order in which callbacks are invoked
in general, no matter whether they are caused by carelessness or cannot generally be predicted, which is why F LOW D ROID assumes
malicious intent. For malicious cases, we assume the following that all callbacks can be invoked in any possible order. However,
attacker model. The attacker may supply an app with arbitrary callbacks can only happen while the parent component (e.g. activity)
malicious Dalvik bytecode. Typically, the attacker’s goal would be is running. For precision, F LOW D ROID thus associates components
to leak private data through a dangerously broad set of permissions (activities, services, etc.) with the callbacks they register. An activity
granted by the user [4]. F LOW D ROID makes sound assumptions may, for instance, register callbacks that get invoked when a button
on the installation environment and app inputs, meaning that the is pressed. The respective callback handler would then have to be
attacker is free to tamper with those as well. F LOW D ROID does analyzed between the onResume() and onPause() events of this
assume, however, that the attacker has no way of circumventing activity only.
the security measures of the Android platform or exploiting side There are two different ways to register callback handlers on the
channels. Further, we assume that the attacker does not use implicit Android platform. Firstly, callbacks can be defined declaratively in
flows [20] to disguise data leaks. Given the current kind of available the XML files of an activity. Alternatively, they can also be registered
malware, this is a very reasonable assumption. imperatively using well-known calls to specific system methods.
F LOW D ROID supports both ways. Additionally, for malware there
3. Precise Modelling of Lifecycle is the risk that an attacker registers undocumented callbacks by
In the following we explain F LOW D ROID’s precise modeling of overwriting methods of the Android infrastructure, some of which
the lifecycle, including entry points, and asynchronously executing could even be called by native code. F LOW D ROID recognizes such
components and callbacks. overwritten methods, handling them similar to normal callback
handlers such as button clicks.
Multiple entry points Unlike Java programs, Android applications For finding callbacks registered in the application code, F LOW-
do not have a main method. Apps instead comprise many entry D ROID first computes one call graph per component, starting at the
points, i.e., methods that are implicitly called by the Android frame- lifecycle methods (onCreate(), onStop(), etc.) implemented in the
work. The Android operating system defines a complete lifecycle respective component class. This call graph is then used to scan for
for all components in an application. There are four different kinds calls to Android system methods that use one of the well-known
of components an app developer can define: activities are single callback interfaces as a formal parameter type. Afterwards, the call
focused user actions, services perform background tasks, content graph is incrementally extended to include these newly discovered
providers define a database-like storage, and broadcast receivers callbacks, and the scan is run again since callback handlers are free
listen for global events. All these components are implemented by to register new callbacks on their own, potentially requiring F LOW-
deriving a custom class from a predefined operating system class, D ROID to re-extend the call graph and re-analyze until a fixed point
registering it in the AndroidManifest.xml file and overwriting it reached. While this method is more expensive than just scanning
the lifecycle methods. The Android framework calls these methods for classes implementing the callback interfaces, it delivers a more
 LeakageApp la = new LeakageApp();
5
4
void main() { a.g.f
la.onCreate(); void foo( z ) { z.g.f
a = new A(); x = z.g;
7
la.onStart(); b = a.g; 6 w = source();
b.f foo(a); x.f x.f = w; w
la.onResume(); sink(b.f); }
3 1
} x.f
p 2
Figure 2: Taint analysis under realistic aliasing
p la.sendMessage();

la.onPause(); F LOW D ROID models the taint-analysis problem within the

IFDS [32] framework for inter-procedural distributive subset prob-
p lems. Section 4.1 explains the transfer functions that the analysis
uses. Most functions are relatively standard. There is one important
la.onStop(); situation, however, in which F LOW D ROID’s analysis differs from
standard taint-analysis algorithms, namely at statements at which
p tainted values are assigned to the heap, i.e., to fields or arrays. This
situation will cause the backward alias analysis to be called, details
p la.onRestart(); of which we will explain in Section 4.2. Due to space restrictions
we keep the description of flow functions on an informal level. To al-
la.onDestroy(); low others to reproduce our approach, the accompanying Technical
Figure 1: CFG for dummy main method Report contains a complete formalization [13].

4.1 Taint analysis

precise mapping between components and callbacks. This does not
only reduce false positives, but we also found it to considerably de- Both the forward and backward analysis propagate access paths.
crease the runtime of the following taint analysis. Once the dummy An access path is of the form x.f.g where x is a local variable or
main method has been constructed, F LOW D ROID computes a final parameter and f and g are fields. Access paths can have different
call graph using this method as the app’s entry point. lengths up to a user-customizable maximal length (5 by default). An
For callbacks defined in the layout XML files, the respective access path of length 0 is a simple local variable or parameter, e.g.,
XML file is mapped to one or more application components using x. In F LOW D ROID, an access path implicitly describes the set of all
the respective layout controls. A button-click handler, for instance, objects reachable through this path, e.g., x.f includes taints x.f.g,
is only valid for the activity that hosts the respective button. F LOW- x.f.h, x.f.g.h and so on.
D ROID analyzes each activity to see which identifiers from the XML The transfer function for assignments taints the left-hand side if
file it registers. This information is then used to create the mapping. any of the operands on the right-hand side is tainted. Assignments
to array elements are treated conservatively by tainting the entire
Example Note that, to gain maximal precision, F LOW D ROID array. Assigning a “new”-expression to a variable x erases all
generates a new dummy main method for each app analyzed. taints modeled by access paths rooted at x. Method calls translate
Each main method will only involve the part of the lifecycle that, access paths to the callee’s context by replacing actual with formal
according to the app’s XML configuration files, can actually occur at parameters; the inverse translation happens at method returns,
runtime. Disabled activities are automatically filtered and callback including the return value if present. As usual with IFDS-based
methods are only invoked in the contexts of the components to which analyses, F LOW D ROID also includes a call-to-return flow function
they actually belong. A button-click handler, for instance, is only (bypassing each method call on the side of the caller). This function
analyzed in the context of its respective activity. In Figure 1 we show propagates taints not relevant for the call, generates new taints at
the control-flow graph of the dummy main method for our previous sources, reports taints at sinks and propagates taints for native calls.
example. The graph models a generic activity lifecycle augmented Section 5 gives further information on the latter.
with the sendMessage callback. In this figure, p represents an
opaque predicate of which we know that F LOW D ROID won’t be 4.2 On-demand alias analysis
able to evaluate it statically. In result, the analysis will automatically Whenever a tainted value is assigned to a heap location such as
consider on equal terms both branches for conditions involving p. a field or an array, F LOW D ROID searches backwards for aliases
of the target variable to then taint them as well. In Listing 2, for
now consider the first call to taintIt (line 3), which taints the
4. Precise Flow-Sensitive Analysis formal parameter in. In line 10, this will cause the access path x.f
to get tainted due to the assignment x.f = in. In this situation
One major difficulty in the analysis is how to implement high object
(generally at all assignments to the heap), F LOW D ROID will initiate
sensitivity to resolve aliasing effectively. Figure 2 (abstracted from
a backward search for aliases of x.f, finding out.f in line 9. At this
a real-world case) shows how F LOW D ROID combines a forward-
point, a new forward taint propagation is started for out.f from this
taint analysis and an on-demand backward-alias analysis to deduce
statement, which will eventually discover the leak in line 11. The
that b.f is tainted at the sink. In step 1 , the tainted variable w is backward analysis will also continue to search backwards, though,
propagated forward, tainting the heap object x.f. Step 2 continues discovering the alias p.f in main, with which it then spawns a
the taint tracking for w and x.f. The important step is 3 : Whenever forward analysis leading to a second taint-flow report at line 4.
a heap object gets tainted, the backward analysis searches upwards
for aliases of the respective object (x.f in this case). At 7 , the Maintaining context sensitivity Algorithms 1 and 2 show the
alias b.f is found and then propagated forward as a normal taint. main loops of both the forward and the backward analysis solver in
 entry 1 void main () {
0 in x.f 0 x.f out.f
2 Data p = new ... , p2 = new ...
3 taintIt (source() , p ) ;
x = out; 4 sink( p . f ) ;
5 taintIt ( " public " , p2 ) ;
naive 6 sink( p2 . f ) ;
x.f = in; approach 7 }
8 void taintIt ( String in , Data out ) {
9 x = out ;
injected
...
context 10 x . f = in ;
11 sink( out . f ) ;
12 }
0 in x.f out.f
Listing 2: Example for context injection

taint flow path edge handover

pseudo code. The algorithmic representation assumes the reader
Figure 3: Analysis handover with context injection in taintIt to be familiar with the algorithmic description of the original
IFDS algorithm [32]. Both solvers operate on their own worklist,
containing so-called path-edges that summarize the data-flows
Algorithm 1 Main loop of forward solver
computed so far up to the current statement/node n. An edge
1: while WorkListF W 6= ∅ do hsp , d1 i → hn, d2 i effectively states that the analysis concluded
2: pop hsp , d1 i → hn, d2 i off WorkListF W that d2 holds at n if d1 holds at the start point sp of n’s procedure p.
3: switch (n) In our particular implementation, the abstract-domain values di are
4: case n is call statement: effectively access paths describing references to tainted values. The
5: if summary exists for call then handover between both analyses is quite non-trivial. If coordinated
6: apply summary in a naive fashion, one will easily obtain two independent analyses
7: else that each on their own may be context sensitive, but would in
8: map actual parameters to formal parameters combination produce analysis information for unrealizable paths
9: end if along conflicting contexts. For instance, note that in the example
10: case n is exit statement: from Listing 2 the aliases of x.f become tainted only if in was
11: install summary hsp , d1 i → hn, d2 i tainted previously. In particular, the analysis should not report a leak
12: map formal parameters to actual parameters at line 6, whose corresponding taintIt-call only propagated the
13: map return value back to caller’s context string "public".
14: case n is assignment lhs = rhs: Figure 3 shows both how a naive implementation could cause
15: d3 := replace rhs by lhs in d2 such a false positive, and how F LOW D ROID handles the problem by
16: insert hsp , d1 i → hn, d3 i into WorkListBW injecting contexts from one analysis to another. The figure assumes
17: extend path-edges via the propagate-method of the classical some familiarity with the typical notation [32] for flow functions
IFDS algorithm within the IFDS framework. Here the black nodes represent data-
18: end while flow facts before/after the respective statement and the black and
red edges represent data flows. The fact 0 is the tautological fact that
is always true, which is why one 0 node always connects to the next.
Algorithm 2 Main loop of backward solver The left-hand side of the figure shows how the forward taint analysis
determines x.f to be tainted. When processing the assignment
1: while WorkListBW 6= ∅ do to x.f, the forward analysis spawns an instance of the backward
2: pop hsp , d1 i → hn, d2 i off WorkListBW alias analysis, shown on the right-hand side. The naive way to
3: switch (n) spawn this analysis would be to initialize it with an edge from 0 to
4: case n is call statement: x.f (dotted line). This implementation, although straightforward,
5: if summary exists for call then leads to imprecision, as its semantics state that aliases of x.f are
6: apply summary tainted no matter what. In Listing 2, this could cause the analysis
7: else to incorrectly report a taint violation even for p2.f. The correct
8: map actual parameters to formal parameters way is thus to inject into the backwards analysis the context of the
9: end if forward analysis: F LOW D ROID consults the “path edge” to x.f,
10: extend path-edges via the propagate-method of the classi- which the IFDS algorithm stores as a side-effect of its summary
cal IFDS algorithm computation. It then injects that entire edge into the backward solver.
11: case n is method’s first statement: (see Algorithm 1, line 16) Context injection happens both ways. At
12: install summary hsp , d1 i → hn, d2 i line 9 in the example, when the backward analysis spawns a forward
13: insert hsp , d1 i → hn, d2 i into WorkListF W analysis for out.f, it injects into the forward analysis the original
14: do not extend path-edges via the propagate-method of the context in. (see Algorithm 2, line 17) Semantically, for the example
classical IFDS algorithm, killing current taint d2 this implies that all taints that both analyses discover for taintIt
15: case n is assignment lhs = rhs: are conditional w.r.t. in being tainted initially.
16: d3 := replace lhs by rhs in d2 A second problem is to avoid false positives due to unrealizable
17: insert hsp , d1 i → hn, d3 i into WorkListF W paths: F LOW D ROID needs to prevent the backwards analysis to
18: extend path-edges via the propagate-method of the classi- return into contexts not analyzed by the forward analysis (and
cal IFDS algorithm vice versa). To implement this constraint, the backward analysis
19: end while in F LOW D ROID actually never returns into the caller at all. Instead,
 1 Data p = new ... , p2 = p ; source, sink and
2 sink( p2 . f ) ; entry-point detection
3 p . f = source() ; generate
4 sink( p2 . f ) ; parse manifest file
main method
Listing 3: Example for activation statements
parse .dex files build call graph

whenever finding an alias it triggers the forward analysis on that perform taint
parse layout xmls
analysis
alias, such as for out.f in line 9. It is then the task of the forward
analysis to map back any relevant taints into the caller’s context. Figure 4: Overview of F LOW D ROID
In the example, the forward analysis knows the calling context it
originated from, which is why it can easily make sure to map back Further algorithmic details Our implementation of IFDS uses
the taints into the right context only. In the example, the forward the extensions explained by Naeem and Lhoták [26]. With this
pass would map out.f to p.f in line 3 only, not to p2.f in line 5. In extension, the IFDS implementation computes the program’s super
essence, the backwards analysis can descend into callees, but never graph on the fly, which means that in our case we compute taint
returns back into callers; all returns are handled by the forward information only for those variables/access paths that are indeed
analysis. When the backwards analysis descends into a call, it will tainted. Our implementation uses two instances of the IFDS solver,
eventually spawn a forward analysis when reaching the method each of which with slight adjustments as explained in Algorithms
header. (see Algorithm 2, line 13) The forward analysis can then 1 and 2. Each instance contains a separate table of summary
make sure to only return into the right caller because its context functions that, as in the original IFDS algorithm, is used to avoid
is injected by the backward analysis. (Technically, its incoming- re-computation for the same callees under the same contexts di .
set [26] is injected.) Whenever the forward analysis maps back to
the caller a taint associated with a heap object, it spawns a new alias 5. Implementation
search inside the caller.
F LOW D ROID extends the Soot framework [21] which provides
important prerequisites for a precise analysis, in particular the three-
Maintaining flow sensitivity Andromeda [37] is another taint- address code intermediate representation Jimple and the accurate
analysis tool that inspired F LOW D ROID’s on-demand alias analysis. call-graph analysis framework Spark [22]. A plugin called Dex-
Andromeda’s analysis, however, can lead to flow-insensitive results. pler [5] allows F LOW D ROID to convert Android’s Dalvik bytecode
In the example in Listing 3, the analysis would report two leaks at into Jimple. On top of Soot and Dexpler, F LOW D ROID further uses
lines 2 and 4, even though the first call to sink definitely happens Heros [7], a scalable, highly multi-threaded implementation of the
before p2.f becomes tainted. In fact, the very same problem would IFDS framework [32]. We next explain F LOW D ROID’s architecture,
hold also for F LOW D ROID’s analysis as we described it above: the while the subsequent sections explain important implementation
backward analysis would discover the tainted alias p2.f at line 1 details and F LOW D ROID’s current limitations.
and trigger a forward pass with that value, causing a taint to be Architecture Figure 4 shows F LOW D ROID’s architecture. An-
reported henceforth anywhere where p2.f is leaked. droid applications are packaged in apk files (Android Packages),
F LOW D ROID addresses this problem by keeping track of what which are essentially zip-compressed archives. After unzipping an
we call activation statements. Whenever spawning an instance of the archive, F LOW D ROID searches the application for lifecycle and
backwards alias analysis, the respective access path is augmented callback methods as well as calls to sources and sinks. This is done
with the current statement, the alias’ activation statement. Also, by parsing various Android-specific files, including the layout XML
the tainted alias is marked as inactive. Semantically, only active files, the dex files containing the executable code and the mani-
taints cause leaks when reaching a sink. Inactive taints are aliases to fest file defining the activities, services, broadcast receivers and
memory locations which have not yet been tainted. Whenever the content providers in the application. Next, F LOW D ROID generates
backward analysis spawns the forward analysis again, and when then the dummy main method from the list of lifecycle and callback
the forward analysis propagates the aliased taint over its activation methods. This main method is then used to generate a call graph
statement, the taint becomes activated and thus gains its ability to and an inter-procedural control-flow graph (ICFG). Starting at the
actually cause leaks to be reported. In the example, the activation detected sources, the taint analysis then tracks taints by traversing
statement is at line 3, which thus causes the analysis to only report a the ICFG as explained in Section 4. F LOW D ROID is configured
leak at the succeeding line 4, avoiding the false alarm at line 2. with sources and sinks inferred by our SuSi project [30], by far the
In general, activation statements are representatives of call trees. most comprehensive one available. The concrete lists of sources
Assume for a moment that the heap assignment in Listing 3 was and sinks are available from the F LOW D ROID website. At the end,
contained inside a method call such as it was the case in the F LOW D ROID reports all discovered flows from sources to sinks. The
assignment at line 10 of Listing 2, which occurs within method calls reports include full path information. To obtain this information, the
to taintIt. In that example, when the forward analysis processes implementation links data-flow abstraction objects to their predeces-
the return edge back into line 3 of main, the analysis globally sors and to their generating statements. This allows F LOW D ROID’s
associates the call to taintIt (line 3) with the activation statement reporting component to fully reconstruct a graph of all relevant as-
since whenever this call has completed, the activation statement also signment statements that might have caused a taint violation at the
has been processed and thus the taint will be active. In other words, given sink.
activation statements are used for looking up the call trees in which
they occur to translate them back into (transitive) callers. Defining shortcuts Including the full JRE or Android platform
To the best of our knowledge, F LOW D ROID is the first approach runtime in the analysis not only requires a lot of analysis time and
to implement an on-demand analysis that fully maintains context memory, but, due to approximations performed during the library’s
and flow sensitivity. In the future we plan to investigate to what analysis, can also lead to undesired imprecision. F LOW D ROID
extent the principles explained here can be reused outside the scope therefore comprises an interface for external library models. The tool
of taint analysis, ideally yielding a rather generic extension of IFDS. supports a simple textual file format for defining certain “shortcut
rules”. Predefined rules handle collection classes, string buffers and 6.1 RQ1: Commercial taint-analysis tools
similar commonly used data structures, e.g., specifying that adding a While there are benchmark suites for analyzing web applications or
tainted element to a set taints the entire set. Technically, the shortcuts specifically for detecting different kinds of Java vulnerabilities [23],
are implemented using the call-to-return edge. If a library call has there is no Android-specific analysis benchmark suite at the moment.
no associated rule then it is fully analyzed. This is problematic because the generic Java test suites do not cover
Native Calls Both Java and the Android platform support the aspects like the Android lifecycle, callbacks or interactions with
invocation of native methods written in C or other unmanaged UI elements like password fields. Thus, they cannot be used for
languages. For a Java-based analysis, such methods are black assessing the practical effectiveness of Android analysis tools.
boxes which cannot be analyzed. F LOW D ROID comes with explicit
DroidBench Specifically for this work, we therefore developed an
taint-propagation rules for the most common native methods, such
Android-specific test suite called D ROID B ENCH. In this evaluation
as System.arraycopy. In this example, the rule defines the third
we consider version 1.0, which contains 39 hand-crafted Android
argument (the output array) to become tainted if the first argument
apps. The suite can be used to assess both static and dynamic taint
(the input array) is tainted before the call. For native methods
analyses, but in particular it contains test cases for interesting static-
without an explicit rule, F LOW D ROID assumes a sensible default:
analysis problems (field sensitivity, object sensitivity, tradeoffs in
call arguments and the return value to become tainted if at least
access-path lengths etc.) as well as for Android-specific challenges
one parameter was tainted before. This is neither entirely sound nor
like correctly modeling an application’s lifecycle, adequately han-
maximally precise but is likely the best practical approximation in a
dling asynchronous callbacks and interacting with the UI. Our Tech-
black-box setting.
nical Report [13] gives additional information about the individual
Inter-Component Communication F LOW D ROID over-approxi- apps. We have made available online D ROID B ENCH in spring 2013
mates explicit inter-component communication by regarding method and know of several research groups [19] who have used it already
which send intents as sinks and callbacks which receive intents as to measure and improve the effectiveness of their Android analysis
sources. Android also supports implicit intent-based communication, tools. A first group of external researchers has already agreed to
e.g., by setting the result value of a called activity which is then contribute further micro benchmarks to the suite [35].
automatically passed back to the calling activity by the operating Table 1 presents the analysis results for F LOW D ROID and two
system. Supporting such behavior together with a more accurate commercial analysis tools (explained in the following) when applied
inter-component connection model is left to future work. In particu- to D ROID B ENCH. As the results show, F LOW D ROID achieves 93%
lar, we are working on integrating F LOW D ROID with EPICC [27], a recall and 86% precision.1 As explained before, for performance
novel static analysis that uses Soot and Heros to perform a String reasons, F LOW D ROID handles array indices imprecisely. The same
analysis to resolve inter-app communication more precisely. limitation applies to ListAccess1, causing false positives in the first
category. Handling indices precisely and efficiently is an interesting
Limitations Although F LOW D ROID is generally aiming for a research question in its own [10]. Button2 causes a false positive
sound analysis, it does share some inherent limitations with most because F LOW D ROID does not currently support strong updates. In
other static-analysis tools. For instance, F LOW D ROID resolves result, it cannot kill taints for certain button combinations. Allowing
reflective calls only if their arguments are string constants, which is strong updates would require a (probably quite expensive) must-
not always the case. On the Java platform, reflection-analysis tools alias analysis. Incorporating such an analysis into F LOW D ROID is
such as TamiFlex [8] can be used to make static analysis tools aware out of the scope of this work. IntentSink1 is not detected because
of reflective calls issued at runtime. Such tool require load-time the test case contains no actual sink. Instead, the tainted value is
instrumentation through java.lang.instrument, though, which the stored in an intent which is then handed back to the activity by the
Android platform does not currently support. Unsoundness can also framework. Such cases are hard to handle without special treatment.
arise in case the Android lifecycle contains callbacks we are not StaticInitialization1 fails because Soot currently assumes all static
aware of, or through native methods that our rules model incorrectly. initializers to execute at the beginning of the program, which in this
At the moment F LOW D ROID is also oblivious to multi-threading: it case is not correct. Determining exactly where such initializers can
assumes threads to execute in an arbitrary but sequential order, which execute at runtime is an interesting research question. We plan to
is generally unsound as well. Fully incorporating sound support for add better support in the future.
multi-threading is a big challenge in its own right, which we thus
leave to future work. Comparison with IBM AppScan Source We compared F LOW-
D ROID with IBM AppScan Source [2] version 8.7, on all tests
6. Experimental Evaluation from D ROID B ENCH. AppScan Source distinguishes three different
categories of findings: vulnerabilities, exceptions of type 1 and ex-
Our evaluation addresses the following research questions: ceptions of type 2. Like reports by F LOW D ROID, vulnerabilities
RQ1 How does F LOW D ROID compare to commercial taint-analysis include a complete path from source to sink. For a type 1 exception,
tools for Android in terms of precision and recall? there is a flow from source to sink as well, but the semantics of
some methods along the propagation path is unknown (e.g. possible
RQ2 Can F LOW D ROID find all privacy leaks in InsecureBank, an sanitization). Since F LOW D ROID does not support sanitization at
app specifically designed by others to challenge vulnerability- the moment, we consider both vulnerabilities and type 1 exceptions
detection tools for Android [28], and what is its performance? as findings. For type 2 exceptions on the other hand, there is no
RQ3 Can F LOW D ROID find leaks in real-world applications and trace. These reports are generated when certain code constructs (e.g.
how fast is it? writing a variable value into the log file) are detected. As these find-
RQ4 How well does F LOW D ROID perform when being applied ings are highly imprecise and completely disregard data flow, we
to taint-analysis problems related to Java, not Android, both in do not count them as findings. As Table 1 shows, AppScan Source
terms of precision and recall? finds only about 50% of all leaks. Major problems occur with the

The next sections address each research question in detail. 1 We exclude the analysis of implicit flows [20] caused through control-flow
Section 6.5 explains why, unfortunately, we were unable to directly dependencies as none of the tools, including F LOW D ROID was designed to
compare F LOW D ROID to other academic Android analysis tools. analyze such flows.
 ? = correct warning, ? = false warning, = missed leak and callbacks. Figure 1 shows that Fortify detects 4 out of 6 data
multiple circles in one row: multiple leaks expected leaks for the lifecycle tests, but closer inspection shows that this
all-empty row: no leaks expected, none reported only happens by chance. In these tests, the data source involves a
App Name AppScan Fortify FlowDroid static field, which Fortify apparently treats in a special way that
Arrays and Lists coincidentally causes a leak to be reported. When removing the
ArrayAccess1 ? static modifier, which does not change the semantics of the test
ArrayAccess2 ? ? ? case, Fortify does not detect the leak any longer. Fortify’s precision
ListAccess1 ? ? ? measures as 81%.
Callbacks
AnonymousClass1 ? ? Conclusion From our experiments we conclude that, to not over-
Button1 ? ? burden the user with false positives, AppScan Source and Fortify
Button2 ? ? ? ? ? ? SCA aim for relatively high precision while sacrificing recall, thus
LocationLeak1 ? ? risking to miss actual privacy leaks. In comparison, F LOW D ROID
LocationLeak2 ? ? shows a significantly higher recall and even a slightly improved
MethodOverride1 ? ? ?
precision.
Field and Object Sensitivity
FieldSensitivity1 6.2 RQ2: Performance on InsecureBank
FieldSensitivity2
FieldSensitivity3 ? ? ? InsecureBank [28] is a vulnerable Android app created by Paladion
FieldSensitivity4 ? Inc. specifically for the purpose of evaluating analysis tools such
InheritedObjects1 ? ? ? as F LOW D ROID. It contains various vulnerabilities and data leaks
ObjectSensitivity1 similar to those found in real-world applications. Analyzing the
ObjectSensitivity2 ? application takes about 31 seconds on a laptop computer with an
Inter-App Communication Intel Core 2 Centrino CPU and 4 GB of physical memory running
IntentSink1 ? ?
on Windows 7 with Oracle’s Java Runtime version 1.7 (64 bit) in its
IntentSink2 ? ? ?
? ? ?
default settings. F LOW D ROID finds all seven data leaks which we
ActivityCommunication1 all verified by hand. There are no false positives nor false negatives.
Lifecycle
BroadcastReceiverLifecycle1 ? ? ?
6.3 RQ3: Performance on Real-World Applications
ActivityLifecycle1 ? ? ?
ActivityLifecycle2 ? ? For assessing F LOW D ROID on real applications, we applied it to
ActivityLifecycle3 ? the 500 most popular Android applications from Google Play.2
ActivityLifecycle4 ? ? Fortunately, despite F LOW D ROID’s high recall, the analysis did not
ServiceLifecycle1 ?
reveal any leaks hinting at truly malicious behavior. Nevertheless,
General Java the majority of apps was reported to—probably accidentally—leak
Loop1 ? ?
? ?
sensitive information like the IMEI (a unique ID) or location data
Loop2
? ? ?
into logs and preference files.
SourceCodeSpecific1
StaticInitialization1 ? Samsung’s Push Service, for instance, logs the phone’s IMEI.
UnreachableCode ? Logs are problematic, as the OS does not impose the same access re-
Miscellaneous Android-Specific strictions on logs as it does on files: for devices running Android 4.0
PrivateDataLeak1 ? or lower, all logs are readable by any app that has the READ LOGS
PrivateDataLeak2 ? ? ? permission. The problem is deemed so important that the mecha-
DirectLeak1 ? ? ? nism was changed in Android 4.1. Since this version, logs are only
InactiveActivity ? ? privately visible, unless the app is run with debugging enabled. Addi-
LogNoLeak tionally, Samsung’s Push Service also broadcasts an Android intent
Sum, Precision and Recall containing the IMEI. All other applications can simply subscribe to
? , higher is better 14 17 26 this intent and get the broadcast IMEI, thereby circumventing the
? , lower is better 5 4 4 Android permission system for this data item.
, lower is better 14 11 2 The game Hugo Runner stores longitude and latitude into a pref-
Precision p = ? /( ? + ?) 74% 81% 86%
erences file. As we verified by hand, though, those preferences were
Recall r = ? /( ? + ) 50% 61% 93%
F-measure 2pr/(p + r) 0.60 0.70 0.89 correctly written in private mode, precluding any access by other
apps. This indicates again how important a precise environment
Table 1: D ROID B ENCH test results model is to reduce the number of false positives. Future tools should
thus model the respective APIs more precisely.
handling of callbacks and the Android component. It appears like For most examined apps F LOW D ROID terminated in under
the advertised support for Android is mostly restricted to AppScan a minute. The instance that took the longest to complete was
being configured with some appropriate sources and sinks. AppScan Samsung’s Push Service which took about 4.5 minutes to analyze.
shows a relatively decent precision of 74%. We also ran F LOW D ROID on about 1000 known malware sam-
ples from the VirusShare project [1]. The average runtime was 16
Comparison with Fortify SCA Fortify SCA [3] by HP is another seconds since the Malware samples seem to be comparatively small.
commercial tool widely used by security analysts. Similar to IBM The minimum runtime was 5 seconds, the maximum was 71 seconds
AppScan Source, Fortify also provides different kinds of findings, which only happened for a single, comparatively large application.
such as data flows from sensitive sources to public sinks, requests for Most of the apps contained two data leaks (1.85 leaks per appli-
security-sensitive permissions, calls to security-sensitive methods, cation on average), usually with identification information like the
etc. In our evaluation, we only considered findings about data flows.
All tests were carried out using version 5.14. As can be seen in 2 For legal reasons we are unable to provide these applications online. To be
Table 1, Fortify SCA shows problems similar to those of IBM able to reproduce our results, though, researchers may email the first author
AppScan, like the handling of the Android component lifecycle to obtain a copy of those applications.
 Test-case group TP FP participate in the experiment as his tool ignores aliasing, making
Aliasing 11/11 0 any comparison meaningless. The authors of ScanDal [19] could not
Arrays 9/9 6 provide their tool due to intellectual property claimed by Samsung,
Basic 58/60 0 but used our benchmark suite and feedback to improve their analysis.
Collections 14/14 3 According to the authors, on D ROID B ENCH, the analysis now
Datastructure 5/5 0 reports results similar to F LOW D ROID.
Factory 3/3 0 In result, we were unable to successfully evaluate even a single
Inter 14/16 0 scientific taint-analysis tool for Android on our own. This is quite
Pred n/a n/a unfortunate, as it restricts us to comparing to those tools only
Reflection n/a n/a based on the available publications. We hope that the availability of
Sanitizer n/a n/a F LOW D ROID and D ROID B ENCH will greatly improve this situation
Session 3/3 0 in the future. After all, publishing irreproducible results hinders
StrongUpdates 0/0 0 progress in the field and is considered unacceptable in most other
Sum 117/121 9 sciences.
Table 2: SecuriBench Micro test results
7. Related Work
IMEI being sent to a remote server to register the phone, or sent There are several approaches to static analysis of Android applica-
as part of an SMS message, sometimes to a premium-rate number. tions differing in precision, runtime, scope and focus.
Some malware applications were even found to receive data through One of the most sophisticated ones is CHEX [24], a tool to detect
broadcast receivers and to then send out this data in SMS messages. component hijacking vulnerabilities in Android applications by
This can allow other applications to send SMS messages indirectly, tracking taints between externally accessible interfaces and sensitive
without requiring the respective permission on their own. sources or sinks. Although not built for the task, CHEX can, in
principle, be used for taint analysis. CHEX does not analyze calls
6.4 RQ4: SecuriBench Micro
into Android framework itself but instead requires a (hopefully
F LOW D ROID was specifically designed for Android, and in this complete) model of the framework. In F LOW D ROID such a model
space gains much precision through its complete and precise han- is optional and, except for native calls, is used only to increase
dling of Android’s lifecycle. Nevertheless, there is nothing that precision and performance. Users can thus omit the model entirely
would preclude software developers from applying F LOW D ROID to and still be sure not to lose taints. CHEX’s entry-point model
Java applications as well. To assess how well F LOW D ROID is set requires an enumeration of all possible “split orderings” which
up for this use case, we evaluated F LOW D ROID against Stanford is not necessary in F LOW D ROID. Furthermore, CHEX is limited to
SecuriBench Micro [23] version 1.08, a common set of 96 J2EE mi- at most 1-object-sensitivity, while F LOW D ROID’s demand-driven
cro benchmarks originally intended for web-based applications. For alias analysis allows for contexts of arbitrary lengths (using a default
each of the benchmarks in the suite, we manually defined the nec- of 5). We found 1-object-sensitivity to be too imprecise in practice.
essary lists of sources, sinks and entry points. Since F LOW D ROID LeakMiner [40] appears similar to our approach from a technical
supports a simple textual file format for defining these parameters, point of view: like F LOW D ROID, it is based on Soot, uses Spark for
and since all benchmarks cases have the same structure, this was not call-graph generation, it implements the Android lifecycle, and the
much effort. We omitted from our experiments test cases involving paper states that an app can be analyzed in 2.5 minutes on average.
sanitization, reflection, predicates and multi-threading. As we ex- However, the analysis is not context-sensitive which precludes the
plained earlier, such features are out of scope for our analysis tool, precise analysis of most test cases in D ROID B ENCH.
just as they are for all other existing Android analysis tools. AndroidLeaks [15] also states the ability to handle the Android
Table 2 shows our test results grouped by test categories. The Lifecycle including callback methods. It is based on WALA’s
TP column shows the true positives, i.e., the number of actual leaks context-sensitive System Dependence Graph with a context-
that F LOW D ROID found. For the example of Basic, for instance, insensitive overlay for heap tracking, but is not as precise as
F LOW D ROID found 58 out of 60. The FP column shows the number F LOW D ROID, because it taints the whole object if tainted data
of false positives, i.e., the finding that F LOW D ROID reported that did is stored in one of its fields, i.e., is neither field nor object sensitive.
not correspond to actual leaks, but were rather artifacts of an overly This precludes the precise analysis of many practical scenarios.
approximate analysis. In most cases this number is reasonably low SCanDroid [14] is another tool for reasoning about data flows
or even zero, except for the Arrays category in which F LOW D ROID in Android applications. Its main focus is the inter-component
reports 6 false positives. Again, those are caused by the failure to (e.g. between two activities in the same app) and inter-app data
model array indices precisely. flow. This poses the challenge of connecting intent senders to their
respective receivers in other applications. SCanDroid prunes all
6.5 Comparison with Other Tools call edges to Android OS methods and conservatively assumes the
We also tried to compare F LOW D ROID to a number of other base object, the parameters, and the return value to inherit taints
tools from the scientific literature, namely TrustDroid [41], Leak- from arguments. This is much less precise than F LOW D ROID’s
Miner [40], and the tool by Batyuk et al. [6]. Unfortunately none of treatment; F LOW D ROID applies this default rule only for native
those tools are available online, nor did the respective authors reply calls not modeled explicitly. F LOW D ROID currently models intent
to our inquiries. sending as sink and intent reception as source, yielding a sound
We tried to run D ROID B ENCH on SCanDroid [14], but faced treatment of inter-app communication. In the future, we plan to
technical difficulties. The tool did not report any findings at all in integrate F LOW D ROID with EPICC [27], a novel static analysis that
our setup. Though being in contact with the authors, we were unable uses String analysis to precisely resolve inter-app communication.
to fix these issues and both sides eventually gave up. The authors of Other approaches like CopperDroid [31] dynamically observe
AndroidLeaks [15] promised to run their tool on D ROID B ENCH but interactions between the Android components and the underlying
never delivered. We also contacted the authors of CHEX [24], but Linux system to reconstruct higher-level behavior. Special stim-
they were unable to provide the tool or any benchmark results due ulation techniques are used for exercising the application to find
to intellectual property claimed by NEC. Starostin [25] declined to malicious activities. Attackers, however, can easily modify an app
to detect whether it is running inside a virtual machine and then helps reduce missed leaks or false positives. Novel on-demand algo-
leak no data during that time [29]. Alternatively, data leaks might rithms allow F LOW D ROID to maintain efficiency despite its strong
only occur after a certain runtime threshold. Aurasium [38] and context and object sensitivity. For assessing the effectiveness of
DroidScope [39] largely suffer from the same shortcomings with analysis tools, we have proposed the Android-specific benchmark
respect to static leak detection. suite D ROID B ENCH and used it for comparing F LOW D ROID to the
TaintDroid [11] is one of the most sophisticated Android taint- commercial tools AppScan Source and Fortify SCA, showing that
tracking systems to date. As a dynamic approach, however, it yields besides finding more real leaks (93% of all leaks in total), F LOW-
some quite different tradeoffs compared to F LOW D ROID. For in- D ROID also has a higher precision (86%) resulting in fewer false
stance, TaintDroid has no problem tracking taints through reflective positives. We hope that in the future D ROID B ENCH will serve as a
method calls, as TaintDroid is implemented as an extension to the standard test set for Android taint analyses.
execution environment, for which it does not matter whether meth- For analyzing the top 500 real-world applications from Google’s
ods are invoked through reflection or not. On the other hand, if used Play Store, F LOW D ROID only took under a minute per application
for triaging malware before installation time, then TaintDroid can and found several leaks. About 1000 malware samples were ana-
successfully detect malware only if paired with a dynamic testing lyzed in about 16 seconds per minute, uncovering 2 leaks per sample
approach that yields decent code coverage. Static ahead-of-time on average. An evaluation of F LOW D ROID on SecuriBench Micro
analyses like F LOW D ROID do not share this shortcoming because shows a 96% recall with only 9 false positives.
they cover all execution paths. Secondly, a dynamic approach such In future work we plan to improve the support for handling reflec-
as TaintDroid can be fooled by a malicious apps that recognize that tion. Also we are interested in pre-computing library abstractions
it is being analyzed in which case the app could simply refrain from automatically.
performing any malicious activities [29]. While this is not problem-
atic if the dynamic analysis is installed on the end user’s mobile Acknowledgements We would like to thank Stephan Huber from
phone (in that case, the malware would effectively be tamed), it is Fraunhofer SIT for supporting us with real-world applications from
problematic if the dynamic analysis is only used for ahead-of-time the Google Play market and Dr. Karsten Sohr from TZI Bremen
triaging of malware that could then later on be installed on a sys- for supporting us with the Fortify SCA evaluation. Thanks to Marc-
tem not protected by the dynamic analysis (in which case the app André Laverdière and others for contributions to a our implemen-
could resume its malicious activities). Static approaches such as tations of F LOW D ROID, Soot and Heros. This work was supported
F LOW D ROID do not share this particular shortcoming as they never by a Google Faculty Research Award, by the BMBF within EC
actually execute the app. SPRIDE and ZertApps, by the Hessian LOEWE excellence initia-
F4F [36] is a framework for performing taint analysis of tive within CASED, by the DFG within the project RUNSECURE,
framework-based applications using a specification language called a project associated with the DFG Priority Programme 1496 “Re-
WAFL for describing the functional behavior of the respective frame- liably Secure Software Systems – RS3 ”, by the Fonds National de
work. While originally created for web applications, it might also la Recherche (FNR), Luxembourg, under the AndroMap project,
be extended to model the Android framework by adding a WAFL and by the National Science Foundation Grants No. CNS-1228700,
generator for Android. F LOW D ROID’s dummy-main generation has CNS-0905447, CNS- 1064944 and CNS-0643907. Any opinions,
the big advantage to only include components and callbacks that findings, and conclusions or recommendations expressed in this ma-
are indeed accessed by the app. This, however, requires a semantic terial are those of the authors and do not necessarily reflect the views
model of the app’s manifest, the layout XML files, the compiled of the National Science Foundation or any other funding partner.
resources file and the app’s source code, which are all interleaved.
F4F could at best be used to give a coarse approximation modeling
the common denominator of all possible apps. References
F LOW D ROID currently handles exceptional flows through a [1] Virus share, aug 2013. http://virusshare.com/.
coarse over-approximation. Kastrinis and Smaragdakis have recently
[2] IBM Rational AppScan, Apr. 2013. http://www-01.ibm.com/
presented a novel and particularly efficient approach for analyzing software/de/rational/appscan/.
exceptions and points-to analysis in combination [18]. It would be
interesting to see whether F LOW D ROID can easily benefit from an [3] Fortify 360 Source Code Analyzer (SCA), Apr. 2013.
integration of some of those concepts. http://www8.hp.com/us/en/software-solutions/software.
html?compURI=1214365#.UW6CVKuAtfQ.
Rountev et al. have proposed a way to pre-compute summaries
for large libraries with the intention to speed up the repeated analysis [4] A. Bartel, J. Klein, Y. Le Traon, and M. Monperrus. Automatically
of client code [33]. For Android apps, which come with the huge securing permission-based software by reducing the attack surface: an
Android framework, such an approach makes a lot of sense. Roun- application to android. In ASE 2012, pages 274–277, 2012.
tev’s work is based on the IDE framework [34], which F LOW D ROID [5] A. Bartel, J. Klein, Y. Le Traon, and M. Monperrus. Dexpler: converting
also uses internally to conduct its IFDS-based analyses. It should android dalvik bytecode to jimple for static analysis with soot. In
therefore be entirely possible to incorporate the authors’ ideas into Proceedings of the ACM SIGPLAN International Workshop on State of
F LOW D ROID. the Art in Java Program analysis, SOAP ’12, pages 27–38, 2012.
Dillig et al. developed an approach to more precisely analyzing [6] L. Batyuk, M. Herpich, S. Camtepe, K. Raddatz, A.-D. Schmidt,
the contents of collections and arrays [10]. The required analysis and S. Albayrak. Using static analysis for automatic assessment
effort is non-trivial, but given our results it is clear that F LOW D ROID and mitigation of unwanted and malicious activities within android
could increase its precision further by implementing analysis sup- applications. In Malicious and Unwanted Software (MALWARE), 2011
6th International Conference on, pages 66–72, 2011.
ports along those lines.
[7] E. Bodden. Inter-procedural data-flow analysis with ifds/ide and soot.
In Proceedings of the ACM SIGPLAN International Workshop on State
8. Conclusions of the Art in Java Program analysis, SOAP ’12, pages 3–8, 2012.
We have presented F LOW D ROID, a novel and highly precise static [8] E. Bodden, A. Sewe, J. Sinschek, H. Oueslati, and M. Mezini. Taming
taint-analysis tool for Android applications. Unlike previous ap- reflection: Aiding static analysis in the presence of reflection and
proaches, F LOW D ROID adequately models Android-specific chal- custom class loaders. In ICSE ’11: International Conference on
lenges like the application lifecycle or callback methods, which Software Engineering, pages 241–250. ACM, May 2011.
 [9] I. D. Corporation. Worldwide quarterly mobile phone tracker 3q12, [25] C. Mann and A. Starostin. A framework for static detection of privacy
Nov. 2012. http://www.idc.com/tracker/showproductinfo. leaks in android applications. In Proceedings of the 27th Annual ACM
jsp?prod_id=37. Symposium on Applied Computing, SAC ’12, pages 1457–1462, 2012.
[10] I. Dillig, T. Dillig, and A. Aiken. Precise reasoning for programs using [26] N. A. Naeem, O. Lhoták, and J. Rodriguez. Practical extensions to the
containers. In Proceedings of the 38th annual ACM SIGPLAN-SIGACT ifds algorithm. In Compiler Construction 2010, pages 124–144, 2010.
symposium on Principles of programming languages, POPL ’11, pages [27] D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden, J. Klein, and Y. L.
187–200, 2011. Traon. Effective inter-component communication mapping in android:
[11] W. Enck, P. Gilbert, B. gon Chun, L. P. Cox, J. Jung, P. McDaniel, and An essential step towards holistic security analysis. In USENIX Security
A. Sheth. Taintdroid: An information-flow tracking system for realtime Symposium 2013, Aug. 2013.
privacy monitoring on smartphones. In R. H. Arpaci-Dusseau and [28] Paladion. Insecurebank test app. http://www.paladion.net/
B. Chen, editors, OSDI, pages 393–407. USENIX Association, 2010. downloadapp.html.
[12] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner. A survey [29] N. J. Percoco and S. Schulte. Adventures in bouncerland. Blackhat
of mobile malware in the wild. In Proceedings of the 1st ACM USA, 2012.
workshop on Security and privacy in smartphones and mobile devices,
[30] S. Rasthofer, S. Arzt, and E. Bodden. A machine-learning approach
SPSM ’11, pages 3–14, New York, NY, USA, 2011. ACM. . URL
for classifying and categorizing android sources and sinks. In 2014
http://doi.acm.org/10.1145/2046614.2046618.
Network and Distributed System Security Symposium (NDSS), Feb.
[13] C. Fritz, S. Arzt, S. Rasthofer, E. Bodden, A. Bartel, J. Klein, 2014. URL http://www.bodden.de/pubs/rab14classifying.
Y. le Traon, D. Octeau, and P. McDaniel. Highly precise taint analy- pdf. To appear.
sis for android applications. Technical Report TUD-CS-2013-0113,
[31] A. Reina, A. Fattori, and L. Cavallaro. A system call-centric analysis
EC SPRIDE, May 2013. URL http://www.bodden.de/pubs/
and stimulation technique to automatically reconstruct android malware
TUD-CS-2013-0113.pdf.
behaviors. In EUROSEC, Prague, Czech Republic, April 2013.
[14] A. P. Fuchs, A. Chaudhuri, and J. S. Foster. Scandroid: Automated
security certification of android applications. [32] T. Reps, S. Horwitz, and M. Sagiv. Precise interprocedural dataflow
analysis via graph reachability. In POPL ’95, pages 49–61, 1995.
[15] C. Gibler, J. Crussell, J. Erickson, and H. Chen. Androidleaks:
automatically detecting potential privacy leaks in android applications [33] A. Rountev, M. Sharp, and G. Xu. Ide dataflow analysis in the presence
on a large scale. In Proceedings of the 5th international conference on of large object-oriented libraries. In Compiler Construction, volume
Trust and Trustworthy Computing, TRUST’12, pages 291–307, 2012. 4959 of LNCS, pages 53–68. Springer, 2008.
[16] M. C. Grace, W. Zhou, X. Jiang, and A.-R. Sadeghi. Unsafe exposure [34] M. Sagiv, T. Reps, and S. Horwitz. Precise interprocedural dataflow
analysis of mobile in-app advertisements. In Proceedings of the fifth analysis with applications to constant propagation. In TAPSOFT ’95,
ACM conference on Security and Privacy in Wireless and Mobile pages 131–170, 1996.
Networks, WISEC ’12, pages 101–112, New York, NY, USA, 2012. [35] G. Sarwar, O. Mehani, R. Boreli, and M. A. Kaafar. On the effectiveness
ACM. . URL http://doi.acm.org/10.1145/2185448.2185464. of dynamic taint analysis for protecting against private information
[17] G. Inc. Application fundamentals. 2013. URL http://developer. leaks on android-based devices, 2013.
android.com/guide/components/fundamentals.html. [36] M. Sridharan, S. Artzi, M. Pistoia, S. Guarnieri, O. Tripp, and R. Berg.
[18] G. Kastrinis and Y. Smaragdakis. Efficient and effective handling of F4F: taint analysis of framework-based web applications. In OOPSLA
exceptions in java points-to analysis. In R. Jhala and K. D. Bosschere, 2011, pages 1053–1068, 2011.
editors, CC, volume 7791 of Lecture Notes in Computer Science, pages [37] O. Tripp, M. Pistoia, P. Cousot, R. Cousot, and S. Guarnieri. An-
41–60. Springer, 2013. dromeda: Accurate and scalable security analysis of web applications.
[19] J. Kim, Y. Yoon, K. Yi, and J. Shin. ScanDal: Static analyzer for In FASE 2013, pages 210–225, 2013.
detecting privacy leaks in android applications. In H. Chen, L. Koved, [38] R. Xu, H. Saı̈di, and R. Anderson. Aurasium: practical policy enforce-
and D. S. Wallach, editors, MoST 2012: Mobile Security Technologies ment for android applications. In USENIX Security 2012, Security’12,
2012, Los Alamitos, CA, USA, May 2012. IEEE. pages 27–27, Berkeley, CA, USA, 2012. USENIX Association.
[20] D. King, B. Hicks, M. Hicks, and T. Jaeger. Implicit flows: Can’t live [39] L. K. Yan and H. Yin. Droidscope: seamlessly reconstructing the os
with ‘em, can’t live without ‘em. In Proceedings of the 4th International and dalvik semantic views for dynamic android malware analysis. In
Conference on Information Systems Security, ICISS ’08, pages 56–70, USENIX Security 2012, Security’12, pages 29–29, Berkeley, CA, USA,
Berlin, Heidelberg, 2008. Springer-Verlag. . 2012. USENIX Association.
[21] P. Lam, E. Bodden, O. Lhotak, and L. Hendren. The soot framework [40] Z. Yang and M. Yang. Leakminer: Detect information leakage on
for java program analysis: a retrospective. In Cetus Users and Compiler android with static taint analysis. In Software Engineering (WCSE),
Infastructure Workshop (CETUS 2011), Oktober 2011. 2012 Third World Congress on, pages 101–104, 2012.
[22] O. Lhoták and L. Hendren. Scaling java points-to analysis using spark. [41] Z. Zhao and F. Osono. Trustdroid: Preventing the use of smartphones
In G. Hedin, editor, Compiler Construction, volume 2622 of LNCS, for information leaking in corporate networks through the used of
pages 153–169. Springer Berlin Heidelberg, 2003. . static analysis taint tracking. In Malicious and Unwanted Software
[23] B. Livshits. Securibench micro, Mar. 2013. http://suif.stanford. (MALWARE), 2012 7th International Conference on, pages 135–143,
edu/~livshits/work/securibench-micro/. 2012.
[24] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang. Chex: statically vetting [42] Y. Zhou and X. Jiang. Dissecting android malware: Characterization
android apps for component hijacking vulnerabilities. In CCS 2012, and evolution. In Proceedings of the 2012 IEEE Symposium on Security
pages 229–240, 2012. and Privacy, SP ’12, pages 95–109, 2012.