Dynamic Taint-tracking: Directions for Future Research

Fabian Berner and Johannes Sametinger

Dept. of Business Informatics, LIT Secure and Correct Systems Lab,

Johannes Kepler University Linz, Austria

Keywords:

Android, Information Disclosure, Taint-analysis, Taint-tracking.

Abstract:

Detection of unauthorized disclosure of sensitive data is a dynamic research ﬁeld. We can protect sensitive data

on mobile devices through various commercial, open source and academic approaches. Taint-tracking systems

represent one of the approaches to detect information disclosure attacks. In this paper, we give an overview

of taint-tracking systems for Android. We discuss the systems and their shortcomings. The contribution of

this paper is to provide an overview of Android taint-tracking systems, and to reveal directions for future

research.The overview can serve as a basis for the selection of a taint-tracking system in speciﬁc situations.

1 INTRODUCTION

Mobile devices like smartphones, tablets and smart-

watches have become ubiquitous in recent years.

They have advantages and disadvantages. On the one

hand, mobile Internet access allows to look up infor-

mation, to check emails, to schedule meetings and ap-

pointments, or to navigate. Mobile devices also in-

clude cameras that allow us to take pictures at any

time, and are used for many other purposes. On the

other hand, due to the permanent connection to the

Internet, we’re available 24/7. Since the amount of

sensitive data stored on mobile devices has increased,

they have become worthwhile targets for attackers.

Attacks can pursue a direct purpose like espionage,

spamming, or provide targeted advertising. Stolen

information can also be used by cybercriminals for

other attacks like social engineering, spooﬁng, phish-

ing or other frauds. In particular, the danger of frauds

has increased recently because of commercial and

payment services are now being also available on our

mobile devices. Examples are e-commercial services

like Amazon or EBay and ﬁnancial services like Pay-

Pal or Google Pay.

A broad overview of Android security systems can

be found for example in (Sufatrio et al., 2015; Xu

et al., 2016; Tam et al., 2017). These ones as well

as other similar studies do not focus on dynamic taint

analysis but rather discuss various security system ap-

proaches for Android. Most papers dealing with novel

taint-tracking systems also provide comparisons to

distinguish their speciﬁc system from other ones, e.g.,

(Sun et al., 2016; You et al., 2017). This article is fo-

cused on taint-tracking systems for Android that can

be used to detect app-based information disclosure at-

tacks by monitoring information ﬂows between a data

source and data sink. The ﬁrst part of this paper gives

an overview of existing systems. This overview can

serve as a basis for system selection. In the second

part, we will evaluate taint-tracking systems, identify

their shortcomings, and reveal possible future work.

2 DETECTION OF

INFORMATION DISCLOSURE

ATTACKS

Information disclosure means “unauthorized disclo-

sure” of “sensitive data” (Shirey, 2007). To detect

information disclosure attacks, we focus on dynamic

taint-tracking techniques (or taint-analysis). In dy-

namic analysis systems, the object of investigation

is executed and monitored, whereas a static analysis

system analyzes the source code without execution.

In general, both techniques are appropriate to detect

information disclosure attacks. The main advantage

of dynamic analysis is that apps can be tested in the

same system, conﬁguration and the same libraries as

on the target system. Therefore, it is possible to de-

tect attacks that need certain prerequisites. A collud-

ing apps attack for example can only start its mali-

cious function if all colluding apps are installed. In

(Zheng et al., 2014), Zheng et al. discuss the prob-

294

Berner, F. and Sametinger, J.

Dynamic Taint-tracking: Directions for Future Research.

DOI: 10.5220/0008118502940305

In Proceedings of the 16th International Joint Conference on e-Business and Telecommunications (ICETE 2019), pages 294-305

ISBN: 978-989-758-378-0

lems of static analysis in the context of apps written

in Java. In particular, they see the missing ability to

analyze dynamically bound code (e.g., with reﬂection

or generics) as a major problem of static analysis ap-

proaches. Wei et al. argue in (Wei et al., 2014) that

static analysis of Android apps is particularly chal-

lenging because the control ﬂow of Android apps is

event-based and therefore unpredictable. Xia et al.

add that some of the code paths identiﬁed in static

analysis “could never happen in real execution” (Xia

et al., 2015). Other big challenges are code obfus-

cation and code encryption. Encrypted or obfuscated

code cannot be analyzed by a static analysis system.

For attackers, these are easy ways to hide a malicious

code. Compared to static analysis, dynamic analysis

appears to be more promising to detect information

disclosure attacks so far. The main disadvantage of

dynamic analysis is that only the executed program

paths are analyzed. This leads to problems especially

in short analysis processes with low path coverage.

Nevertheless, it has to be mentioned that hybrid anal-

ysis, i.e., a combination of static and dynamic analy-

sis, can boost the quality of security analysis, e.g., see

(Graa et al., 2015; Rasthofer et al., 2016). Typically,

static analysis is performed as an upstream analysis

and the results are used as input for dynamic analysis.

On the basis of this upstream analysis, the dynamic

analysis can be used to run through speciﬁc execution

paths of the program in a more targeted manner and

thus potentially ﬁnd more security gaps.

3 TAINT-TRACKING

Taint-tracking is a data ﬂow analysis technique by

marking speciﬁc data with a taint tag or taint for

short. The taint itself is transparent for programs that

use this data. Therefore, it can be imagined as a wa-

termark. Tainted data originates from a taint source

and leaves the system in a taint sink. Typically, taint

source and the taint sink are system library meth-

ods. Taint-tracking means monitoring the data ﬂow

between taint source and taint sink. To evaluate the

usage of the tainted data, the taint propagation logic

monitors the program ﬂow and detects whether the

tainted data is processed or copied. If tainted data is

copied, the copy is also marked with the same taint as

the original data. Taint tags are stored in a taint tag

storage. Overtainting describes the case when insen-

sitive data is tainted and monitored. Overtainted data

ﬂowing to a taint sink leads to false positives. Under-

tainting describes the opposite, when sensitive data is

not marked by the taint-tracking. Undertainting can

lead to false negatives.

Different dynamic taint-tracking systems exist for

Android. Most of them are based on Taintdroid, while

some are based on Minemu, TaintART or TaintMan.

Taintdroid is used to date by default as a standard for

taint-tracking in Android, and it has been extended

by other academic security systems. Taintdroid was

implemented for the Dalvik Virtual Machine (VM)

but has not been ported to the newer Android Run-

time (ART). TaintART (Sun et al., 2016) is an unofﬁ-

cial successor of Taintdroid and is based on Android’s

ART. The authors of TaintART are planning to re-

lease an implementation as an open source. Minemu

is a taint-tracking system integrated in an emulator

(Bosman et al., 2011). Its latest version was pub-

lished in 2011 and is therefore outdated. TaintMan

(You et al., 2017) is also an unofﬁcial successor of

Taintdroid. It can be executed on the Dalvik VM as

well as in ART. Subsequently, we will focus on Taint-

droid, TaintART and TaintMan only.

3.1 Taintdroid

Taintdroid is the best known taint-tracking system for

Android. It was published in 2010 by William Enck

et al., (Enck et al., 2010) who developed it within the

scope of his PhD thesis under the title Analysis Tech-

niques for Mobile Operating System Security (Enck,

2011). An enhancement to the Taintdroid concept was

published in 2014 (Enck et al., 2014).

Taintdroid has been used by many security sys-

tems for Android, mostly in academia because of its

advanced development and its availability as open

source. In the design of any dynamic security analy-

sis system, developers have to decide between perfor-

mance and storage requirements. Generally speaking,

it is possible to reduce the performance overhead of a

security analysis system by using more storage capac-

ity and vice versa. Taintdroid’s tracking approach is

optimized to minimize performance and storage over-

head by limiting the amount of different kinds of data

sources. The majority of taint-tracking systems uses

a shadow memory or taint map. These are both being

speciﬁc data structures that contain taint information

(Enck, 2011, p. 58).

Taint Tag Storage. In Taintdroid, the taint tag stor-

age is called virtual taint map. To store taints in the

virtual taint map, Taintdroid uses a 32-bit vector for

each data type provided by Dalvik (method local vari-

able, method arguments, class static ﬁelds, class in-

stance ﬁelds and arrays (Enck, 2011)). Each of the

32 bits stands for a speciﬁc taint tag type and thereby

for a deﬁned set of sensitive data. Taintdroid is there-

fore limited to 32 types of trackable data.

Dynamic Taint-tracking: Directions for Future Research

295

Taint Propagation Logic. Taintdroid uses four

tracking techniques to monitor ﬂows of (1) variables,

(2) method parameters, (3) ﬁles and (4) Inter Process

Communication (IPC) messages that contain sensitive

data.

Discussion. Taintdroid is often cited in the context

of taint-tracking and some of its limitations are dis-

cussed in different publications. The following pro-

vides a comprehensive collection of Taintdroid’s lim-

itations, indicating the need for further research:

• 32-bit vector: Taintdroid is limited to 32 different

kinds of trackable data (Enck et al., 2010).

• Native code: A recurring problem is the analysis

of native code. Like most of the presented sys-

tems, Taintdroid is only able to analyze bytecode

(Enck et al., 2010).

• Covert channels: Taintdroid is only able to track

data over overt channels, e.g., IPC and Inter Com-

ponent Communication (ICC)). (Sarwar et al.,

2013).

• Implicit data ﬂows: Implicit data ﬂows, e.g.,

based on comparison, in which tainted data is only

read but not (directly) copied, cannot be detected

(Sarwar et al., 2013).

• Overtainting: The purpose of device identiﬁers

(IMSI, MCC, MNC, MSIN) is to provide a unique

reference number, which can be used to identify a

speciﬁc device. Taintdroid is unable to distinguish

between a mere identiﬁcation and an information

disclosure attack.

• Late reporting: Taintdroid reports to the user im-

mediately after the tainted information has been

sent to a taint sink. That means that the data has

left the mobile device before the user has had any

chance to react.

• Version: Taintdroid is based on an obsolete An-

droid version.

The detection of malicious code can be pre-

vented while Taintdroid’s security analysis is running,

i.e., by sandbox-detection and by evasion techniques.

Sandbox-detection includes several techniques to de-

tect whether execution is monitored by a security

analysis system. Evasion techniques prevent detec-

tion, for example, by awaiting the end of security

analysis. Attacks can also use weaknesses of Taint-

droid’s taint propagation mechanism. Such attacks

are discussed by Sarwar et al. in (Sarwar et al., 2013).

Finally, covert channels can bypass the ofﬁcial IPC

mechanisms and therefore cannot be tracked by Taint-

droid.

Security Systems based on Taintdroid. A variety

of security systems is based on Taintdroid. The sys-

tems we focus on and present in this section, detect

information disclosure attacks and help to protect sen-

sitive data on Android devices. However, Taintdroid

has also been used as basis for different security sys-

tems. For example, AppFence by Hornyack et al.

helps to diminish the harm of app-based information

disclosure attacks by using fake rather than real sen-

sitive data.

MOSES, short for MOde-of-uses SEparation in

Smartphones, presented by Russello et al, (Russello

et al., 2012; Zhauniarovich et al., 2014) provides

app isolation (soft virtualization) by policies that can

be modiﬁed at runtime. MOSES is a program that

places apps and the respective sensitive data in iso-

lated proﬁles, e.g., work, private and default (Horny-

ack et al., 2011). MOSES uses Taintdroid taint prop-

agation mechanism to monitor information ﬂows be-

tween different proﬁles.

TreeDroid by Dam et al. is another policy-based

security system that uses Taintdroid’s data ﬂow track-

ing technique (Dam et al., 2012). TreeDroid gener-

ates tree automata for a given app and provides ﬁne-

grained policy enforcement at runtime.

VetDroid by Zhang et al. analyzes app behavior

based on a permission usage analysis (Zhang et al.,

2013). After granting permissions in Android, it is

transparent to the user how permissions are used by

the app. VetDroid is able to “reconstruct permission

use behavior” (Zhang et al., 2013) of a given app.

YAASE, short for Yet Another Android Security Ex-

tension, by Russello et al. focuses on information dis-

closure via network and colluding applications (Rus-

sello et al., 2011). YAASE labels and tracks app-to-

app communication as well as app-to-internet com-

munication. This labeling (taint) mechanism is based

on a modiﬁed Taintdroid where the user can deter-

mine the data that should be examined and how it

should be labeled.

AppsPlayground developed by Rastogi, Chen and

Enck (Rastogi et al., 2013) is a modular and scalable

dynamic analysis framework for testing Android ap-

plications. It is based on Taintdroid and additional dy-

namic detection techniques like system call monitor-

ing. AppsPlayground automatically evaluates a given

app by triggering several kinds of system events based

on redundancy avoiding, a heuristic-based execution

technique.

Only little information is available on the

emulator-based security system DroidBox by Lantz

and Delosieres (cf. (Lantz and Delosieres, 2015)).

The open source system is available for Taintdroid

4.1.1, using the machine emulator Quick Emulator

SECRYPT 2019 - 16th International Conference on Security and Cryptography

296

(QEMU) (QEMU Project, 2017). At the beginning, a

QEMU instance is started with a Taintdroid Android

Virtual Device (AVD). Security analysis is done by

the droidbox.py script, which collects data from dif-

ferent sources, e.g., network data and API ﬁle opera-

tions.

Graa et al. propose a hybrid security analysis ap-

proach based on Taintdroid (Graa et al., 2015). Us-

ing an upstream static analysis placed in the Dalvik

VM Veriﬁer, it allows to inspect the control ﬂow of

an app. The results of the static analysis are used as

initial parameters for the dynamic analysis based on

Taintdroid.

Andrubis is based on Anubis, a dynamic malware

analysis sandbox for Windows applications (Weich-

selbaum et al., 2014; Lindorfer et al., 2014). An-

drubis follows a hybrid analysis approach with an up-

stream static analysis for feature extraction, e.g., An-

droidManifest.xml) and a dynamic behavior analysis

at runtime. The dynamic analysis part is based on

Taintdroid, method tracing and a modiﬁed Dalvik VM

as a system analysis component. The analysis run is

fully automated, for example with Monkey as user in-

put generator.

Mobile-Sandbox provides a website, which apps

can be uploaded to for a hybrid analysis (Spreitzen-

barth et al., 2013; Spreitzenbarth et al., 2015) . For

the security analysis, different existing security sys-

tems are integrated. Static analysis is, for example,

done by tools like Droidlyzer and the Static Android

Analysis Framework (SAAF). The results are used as

input for the dynamic analysis tools like Taintdroid

and DroidBox.

QuantDroid is an extension for Taintdroid by

Markmann, Mollus and Westhoff (Mollus et al.,

2014). QuantDroid is a dynamic information ﬂow

analysis that generates ﬂow-graphs to quantify infor-

mation ﬂows between Android processes. The idea is

to deﬁne thresholds for communication between spe-

ciﬁc processes. For example, no data exchange or

only a speciﬁc amount of data is allowed over a spe-

ciﬁc communication channel.

Qian et al. suggest a system called NDroid,

which extends Taintdroid to track information ﬂows

through Java Native Interface (JNI) based on a modi-

ﬁed QEMU VM (Qian et al., 2014).

3.2 TaintART

TaintART by Sun, Wei and Lui was published in late

2016 (Sun et al., 2016). Since the Dalvik VM, which

Taintdroid is based on, was replaced by ART in An-

droid 5.0 (released in November 2014), Taintdroid has

become outdated. The public release of TaintART’s

source code has been announced but is not available

so far. The prototypical implementation was done for

Android 6.0 (Sun et al., 2016), which uses ART as

runtime environment for apps. The TaintART com-

piler integrates the taint logic into the compiled ap-

plication. At runtime, TaintART runtime executes

the compiled native code and tracks tainted data.

TaintART distinguishes between four levels of infor-

mation disclosure, from low to high security needs

(Sun et al., 2016).

Taint Tag Storage. To speed up taint-tracking,

TaintART uses a CPU register as the fastest storage

on a computer for taint tag storage. The prototypical

implementation is built on a 32-bit ARM processor

as target architecture and can therefore save 32 taint

tags. To avoid the limitation of registers, TaintART is

also able to temporarily store additional taint tags in

the device’s memory.

Taint Propagation Logic. TaintART provides three

taint propagation logic methods: (1) basic taint prop-

agation, (2) taint propagation via methods calls, and

(3) propagation between apps through Binder IPC.

For the basic taint propagation, the ART compiler

generates a Control Flow Graph (CFG), which is

used by the TaintART compiler to instrument the

source code for variable-level taint-tracking. In case

a method is called, TaintART uses an invocation taint

propagation to track tainted data in method parame-

ters. The third part is a message-level propagation for

Android’s Binder IPC.

Discussion. Compared with Taintdroid, the advan-

tage of TaintART is its compatibility with ART which

is the new runtime environment in Android. There-

fore, TaintART is an interesting alternative to Taint-

droid: on the one hand, it is partly similar to Taint-

droid and, on the other hand, it improves the concept

of taint-tracking. Compared to Taintdroid, one of the

improvements is the possible integration of NDroid

for analyzing native code.

Attacks against TaintART. To the best of the au-

thors’ knowledge, there is no speciﬁc attack vector

published yet that targets TaintART. Similar to Taint-

droid, TaintART’s analysis can also be circumvented

by collaborating applications that use covert channels

to bypass TaintART’s analysis mechanism.

Since TaintART’s source code has not been re-

leased yet as of this writing, extensions or systems

based on TaintART have not been published yet.

Dynamic Taint-tracking: Directions for Future Research

297

3.3 TaintMan

Another unofﬁcial successor of Taintdroid is Taint-

Man by You et al., which integrates the taint-

propagation logic in the apps and libraries to ana-

lyze (You et al., 2017). Therefore, TaintMan uses a

desktop computer program to statically instrument the

bytecode. First, the app to be analyzed is unpacked,

then the bytecode is instrumentated, the app’s entry

point is changed. Finally, the app is repacked. In

Android, apps can check their own integrity based on

digital signatures. In (You et al., 2017), the authors

discuss the possibility to bypass Androids system li-

brary. The tool is also able to download libraries from

an Android device, instrument them and upload the li-

braries back to the device. Once uploaded and instru-

mented, the system libraries do not replace the origi-

nal ones and are stored in a separate directory.

The release of TaintMan has not been announced,

and the program has not been available yet as of this

writing. The prototypical implementation seems to be

developed for Android 4.0 (which uses Dalvik VM)

and 5.0 (which uses ART) (You et al., 2017).

Taint Tag Storage. Similarly to Taintdroid, Taint-

Man uses a 32-bit vector for each variable to encode

the taint tag. For this reason, the amount of different

taint sources is also limited to 32. Instead of using

a taint map for storing the taint tags, like in Taint-

droid, TaintMan stores all taint tags for local vari-

ables, parameters, return values and exceptions on an

internal stack. Taint tags for class variables are stored

in shadow ﬁelds in the corresponding classes. As in

Taintdroid, only one taint tag per array is used to min-

imize the storage needs of TaintMan.

Taint Propagation Logic. TaintMan imbeds its

taint-tracking commands in the apps or libraries byte-

code. Therefore, its analysis capabilities are limited to

instrumented apps and libraries. This is a main differ-

ence in comparison to other Dynamic Taint Analysis

(DTA) systems discussed, which integrate the taint-

tracking logic in the mobile Operating System (OS).

To save resources, TaintMan tries to instrument as

few taint-tracking instructions in the app’s bytecode

as possible. A detailed overview of TaintMan’s taint

propagation logic commands, which can be instru-

mented in apps and libraries, can be found in (You

et al., 2017).

Discussion. TaintMan can execute taint-analysis on

non-rooted Android devices, which is a huge advan-

tage for its usability as well as for the quality of the

analysis. The quality of analysis has been improved

as the execution on a real device is more lifelike and

much harder to detect for an attacker.

Since TaintMan has not been released yet as of

this writing, no independent evaluations of TaintMan

are available. In (You et al., 2017) the authors at-

test TaintMan high effectiveness regarding detection

of information disclosure attacks with “acceptable”

(You et al., 2017) performance (42,3 % without and

28,9 % overhead with code optimizations (You et al.,

2017)) and storage overheads (instrumented code is

about 23 % larger (You et al., 2017)). Such overheads

are acceptable in case of software tests, but they are

not suitable for everyday use. Increased performance

overhead leads to decreased battery lifetime.

A comparison of TaintMan with Taintdroid or

TaintArt is difﬁcult:

• TaintMan uses the newer ART runtime envi-

ronment, whereas Taintdroid uses the outdated

Dalvik VM. In most cases, execution of apps is

much faster in ART than in Dalvik VM.

• Both Taintdroid and TaintArt are not publicly

available and, therefore, cannot be tested or eval-

uated.

Attacks against TaintMan. Speciﬁc attack vectors

that target TaintMan have not been reported so far.

Similarly to Taintdroid and TaintART, TaintMan anal-

ysis can also be circumvented by collaborating appli-

cations that use covert channels to bypass TaintMan’s

analysis mechanism.

Without the availability of the source code, only

theoretical concepts can be built. Extensions or sys-

tems based on TaintMan have not been published yet.

4 COMPARISON

Without the source code of TaintART and TaintMan,

our knowledge about both systems is based on the in-

formation given in (Sun et al., 2016) and (You et al.,

2017). Taintdroid, TaintART and TaintMan must be

compared with caution. Taintdroid is well known and

has been described earlier. Its functions and limita-

tions have been discussed in many papers. In contrast,

both TaintART and TaintMan have not received that

much attention yet. We expect TaintART and Taint-

Man to display similar limitations. It remains to be

seen whether TaintART or TaintMan can close the gap

left by Taintdroid.

The subsequent system comparison shows the dif-

ferences among these systems and can serve as a basis

for system selection in a speciﬁc scenario. In the ta-

bles below a check mark (X) shows that a property

SECRYPT 2019 - 16th International Conference on Security and Cryptography

298

is fulﬁlled and a dash (-) shows that it is not fulﬁlled

by the respective system. If the analysis technology

cannot be clearly classiﬁed by the given scheme, the

analysis techniques are marked with a question mark

(?). Tendencies are marked with a check mark or dash

in front of the question mark. Tendencies occur when

a property is incompletely (X(?)) or even rudimentary

fulﬁlled (- (?)) by the system. In case the property is

not applicable, the abbreviation n/a is used.

All information and system characteristics are

taken from the papers cited above. Most systems

are not publicly available and thus can not be inves-

tigated any further. Another limitation is the classiﬁ-

cation scheme: Some systems have the characteristics

of more than one classiﬁcation class. In these cases,

the system is attributed to the closest class.

4.1 General Information

We can roughly distinguish among the following three

types of users:

• Average User. User without any special knowl-

edge of computer security.

• Administrator or Pen Tester. User with special

knowledge in computer security who has to test

the security of an app or has to adjust the conﬁg-

uration of an OS or app for security reasons.

• App Developer. User who wants to validate and

test an app.

Most systems do not specify their target group. In

this case, we determine it as normal users for every

live analysis system in which the user has to decide

on the security relevant issues. All systems that run

ahead of the app usage can also be used by adminis-

trators or pen testers. This also applies to systems that

are conﬁgured once and run without user interaction.

Table 1 provides basic information about the sys-

tems: the OS and its version (or version range), the

existing security software the system is based on as

well as the probable target group. We have marked

the version with n/a when we were not able to ﬁnd

any information about it.

4.2 Analysis

All systems use a dynamic analysis approach, which

is enhanced by a few systems to a hybrid analysis.

They are integrated in the mobile OS, and only for

TaintART the mobile OS has to be rooted addition-

ally. The property device (emulator or real device)

deserves special attention as well as the possibility

for iterative security analysis. Systems designed to

Table 1: General Information and Assumed Target Group.

Name Base Year Version avg admin dev

TaintDroid

(TD)

- 2011 2.X - 4.3 - (?) (?)

TaintART - 2016 6.0 - (?) (?)

TaintMan SB 2017 4.0 - 5.0 - (?) (?)

Andrubis TD, A 2012 n/a - X X

AppFence TD 2011 2.1 (?) - -

AppsPlayground TD 2013 n/a - X X

DroidBox

(DB)

TD n/a 2.3 - 4.1.1 - X (?)

Graa et al. TD 2015 n/a - (?) (?)

Mobile

Sandbox

TD/DB 2013 n/a - 4.1.X - X (?)

MOSES

Droid

TD 2012 2.3.4 r1 - X (?)

Ndroid TD, DS, D 2014 n/a - 4.1.1 r6 - X (?)

TreeDroid TD, D2J 2012 2.3 - X (?)

QuantDroid TD 2012 2.3 - n/a - X X

VetDroid TD 2013 2.3 - X (?)

YAASE TD 2011 n/a - X (?)

Legend: avg ... average user, admin ... administrator/pen tester, dev ... app

developer; TD ... TaintDroid, A .. Anubis, D ... Darm 1), D2J ... dex2jar 2),

DB ... DroidBox, DS ... DroidScope, SB ... Smali/Baksmali 3)

1) https://github.com/jbremer/darm, 2) https://sourceforge.net/projects/dex2jar/,

3) https://github.com/JesusFreke/smali/wiki

run on real devices cannot detect every malicious be-

havior. Note that every false-negative ends in an in-

formation disclosure of sensitive data. Even worse,

the warning message in Taintdroid is not generated

until the sensitive data we want to protect has already

left the device. No doubt, a solution can be found

to counteract this weakness. It occurs only because

Taintdroid is of academic origin and has to be devel-

oped further.

Since mobile devices have limited resources, the

location where the security analysis is executed is an-

other interesting characteristic. Basically, there exist

host-based security analysis approaches that are exe-

cuted on the mobile device itself, and distributed ap-

proaches that help to minimize the needed resources.

All systems except for QuantDroid and Mobile Sand-

box are host-based. If the security system is executed

on an emulated device, the difference between both

characteristics can mostly be neglected.

The ability to run iterative tests and the compa-

rability of two or more test runs have yet to be ad-

dressed. All shown systems are based on monitoring

and offer no features for comparison because moni-

toring is a process without a clearly deﬁned start or

end of analysis. In contrast, systems that run in an

emulation environment normally use a scanning ap-

proach, which is started and stopped for an analysis

run. None of the publications on the systems com-

pared above have mentioned the possibility of com-

paring the results of analysis runs. None of them are

able to analyze native code. However, You et al. have

disscussed the possible integration of NDroid to ex-

tend its analysis capabilities to native code (You et al.,

2017).

Table 2 summarizes information about the secu-

Dynamic Taint-tracking: Directions for Future Research

299

Table 2: Security Analysis.

Static

Dynamic

Integrated in OS

Rooted OS

Device

Host-based

Distributed

Iterative

analysis?

A single app

Two or more apps

Complete system

Native Code

TaintDroid - X X - r X - m X X X -

TaintART - X X X r X - m X X X -

TaintMan X X - - r X - m X X - -

Andrubis X X X - e X - s X X - -

AppFence - X X n/a r X - m X X X -

AppsPlayground X X X - e X - s X X - -

DroidBox - X X - e X - s X X - -

Graa et al. X X X - r X - m X X X -

Mobile Sandbox X X X - e X (?) s X X - -

MOSES Droid - X X n/a r X - m X X X -

Ndroid - X X - e X - s X X - -

TreeDroid - X X n/a r X - m X X X -

QuantDroid - X X n/a r/e X X s X X X -

VetDroid - X X n/a r/e X - m/s X X - -

YAASE - X X n/a r X - m

X X X -

r ... real device; e ... emulator-based

s ... scanner; m ... monitor

rity analysis approach. All taint-tracking systems

mentioned above can be used to evaluate the security

of a single app. At least theoretically, they should

also be able to evaluate two or more apps, for exam-

ple, in order to detect colluding apps. Since most

of the systems are not publicly available, it is im-

possible to check this out. The system’s ability to

secure the whole device is questionable: Taintdroid

and TaintART were developed to monitor information

disclosure attacks on the application level. Neither

Taintdroid as the basis of the discussed systems nor

TaintART monitor the OS itself. The second part of

Table 2 shows the analysis range of the security sys-

tems. Analysis range means the scope analyzed by

the system: (1) a single app, (2) two or more apps,

and (3) the complete OS with all running apps and

3rd party libraries. The analysis range is important

because attack vectors can stretch over more than one

app, cf. colluding apps. Systems that are limited to

one app are not able to detect such attack vectors. The

category complete system means that all apps that run

together in one OS instance can be analyzed simulta-

neously. However, the term complete system does not

refer to the OS itself.

Taintdroid and TaintART focus solely on dynamic

taint-tracking for the detection of information disclo-

sure attacks. Most of the mentioned systems com-

bine the dynamic taint-tracking approach with some

additional analysis techniques. TaintART and Taint-

droid are integrated in the Android’s app runtime en-

vironment and can therefore use analysis data from

the OS. This also affects other security systems based

on Taintdroid. Some of the systems additionally ex-

tract analysis data from the apps or rather the source

code after decompiling the app. None of the systems

uses data sources from outside the analyzed device.

Analyzing data from outside the analyzed device can

be important to security analysis, especially for de-

tecting information disclosure attacks.

The following classiﬁcation of static and dynamic

security systems is adopted from (Neuer et al., 2014).

Static security analysis systems:

• Extraction of Metadata. “Tools extract informa-

tion from an application’s manifest and provide

information about requested permissions, activi-

ties, services and registered broadcast receivers.

Meta information is often used during later dy-

namic analysis in order to trigger an application’s

functionality.”

• Weaving. “Tools rewrite bytecode of applications

using a bytecode weaving technique. This allows

them, for instance, to insert tracing functionality

into an existing application.”

• Decompiler. “Tools implement a Dalvik bytecode

decompiler or disassembler.”

Dynamic security analysis systems:

• Taint-tracking. “Taint-tracking tools are often

used in dynamic analysis frameworks to imple-

ment system-wide dynamic taint propagation in

order to detect potential misuse of users’ private

information.”

• Virtual Machine Introspection (VMI). “VMI-

based frameworks . . . intercept events that occur

within the emulated environment. Dalvik VMI-

based systems monitor the execution of Android

APIs through modiﬁcations in the Dalvik VM.

Qemu VMI-based systems are implemented on

the emulator level to enable the analysis of native

code. However, emulators are prone to emulator

evasion.”

• System Call Monitoring. “Frameworks collect an

overview of executed system calls, by using, for

instance, VMI, strace or a kernel module. This

enables (partial) tracing of native code.”

• Method Tracing. “Frameworks trace Java method

invocations of an app in the Dalvik VM.”

We distinguish the following possible sources of

analysis data:

• App or Source Code: About half of the systems

gain information from the analyzed app, the com-

piled bytecode or the source code.

• Meta Data: Also about half of the systems evalu-

ate app meta data like the manifest ﬁle of Android

apps.

• Mobile OS: The OS generates information that

can be used for security analysis like systems log

ﬁles. Furthermore, altered Application Program-

ming Interfaces (APIs) etc. can be used to gen-

erate additional analysis data. All systems dis-

SECRYPT 2019 - 16th International Conference on Security and Cryptography

300

cussed above use information from the mobile OS

in some form.

• Agents and Network: None of the systems dis-

cussed above uses agents or other network anal-

ysis techniques outside the mobile OS.

Table 3 summarizes security analysis approaches

used by the different taint-tracking systems, which

implement different analysis methods for static and

dynamic analysis.

Table 3: Static and dynamic analysis methods.

Static Analysis Dynamic Analysis Analysis Data Source

Metadata Extrac-

tion

Weaving

Taint-tracking

Decompiler

Taint-tracking

VM Introspec-

tion

System Call Moni-

tor

Method tracing

Adjustable data

collection

App or source

code

Metadata

Agents

Network

TaintDroid - - - - X - - - - (?) - - X - -

TaintART - - - - X - - - X X - X - -

TaintMan - X - X X X - - - (?) X - - - -

Andrubis X - - X X X X X - X X X - -

AppFence - - - - X - X(?) - - - X X - -

AppsPlayground - - - X n/a X n/a - X n/a X - -

DroidBox - X(?) - - X - - - - - X(?) X - -

Graa et al. X n/a n/a n/a X - - - - X n/a X - -

Mobile Sandbox X n/a - X X n/a X(?) X(?) - X X X - -

MOSES Droid - - - - X - n/a n/a - - X X - -

Ndroid - - - - X n/a X(?) X(?) - - - X - -

TreeDroid - - - - X - - (?) - (?) - n/a n/a X - -

QuantDroid - - - - X - X X - - X(?) X - -

VetDroid - - - - X - (?) n/a n/a - - n/a X - -

YAASE X - - - X - X - - - X X - -

5 POTENTIAL RESEARCH

DIRECTIONS

All security systems described above share a subset

of shortcomings. We will discuss these shortcomings

along with directions for possible research.

5.1 Detection Rates

No security system is able to detect all possible in-

formation disclosure attacks. This is in the nature of

things, but it proves that analysis at runtime on a mo-

bile device with real sensitive data is problematic. Ev-

ery false-negative on a real mobile device that stores

real sensitive data leads to a real information disclo-

sure, which is irreversible. On real mobile devices,

it is also problematic to execute an upstream analysis

before executing the app because it slows down the

start of the app. Another point is the analysis of apps

that use native code functions or libraries. Most of

the evaluated security systems are not able to analyze

native code.

Potential Research. To increase detection rates

(true-positives and true-negatives) and, thus, to de-

crease false alarms (false-positives), more security

relevant analysis data is needed. Ideally, the analy-

sis data should be enlarged by additional data sources

that are independent from the existing ones. Indepen-

dent here means that two analysis data sources should

not depend on each other. For example, an informa-

tion disclosure attack can be detected by the analysis

of information ﬂow among apps and by network traf-

ﬁc analysis. The analysis data collection of existing

systems is often limited . . .

• . . . to one app at a time: a security system is not

able to detect attack vectors like colluding appli-

cations, confused deputy or covert channels be-

cause the relevant analysis data cannot be col-

lected.

• . . . to the external borders of a mobile device: se-

curity systems are not able to collect analysis data

beyond the device context. Especially for infor-

mation disclosure attack detection, information

ﬂows in both directions – to and from a mobile

device to other devices – seem to be an important

source of analysis data.

• . . . by time and resources: dynamic analysis on a

mobile device suffers because of the strong limi-

tations of the device resources. If security is eval-

uated by an upstream analysis system, it is limited

by time in order to speed up the app installation or

loading time.

The analysis data collection mechanism of dy-

namic analysis systems, which are executed live on a

real mobile device, is often intentionally limited for

performance reasons. For example Taintdroid sup-

ports only 32 different kinds of taint-sources for that

matter.

5.2 Limited System Resources

Security analysis at runtime on a mobile device costs

valuable resources. Even if devices become more

powerful, we may not forget that Android penetrates

also into other areas. Android Wear powered devices

like smart watches are just one example. This short-

coming becomes evident only on security systems

running on the mobile device directly.

Potential Research. There are three ways to de-

crease the performance overhead of mobile device se-

curity systems:

• Security analysis approaches can be optimized in

favor of better performance. The problem is that

the optimization potential is limited because it di-

rectly depends on the amount of analysis data.

As discussed above, using additional data sources

will lead to an additional slowdown of the security

analysis.

Dynamic Taint-tracking: Directions for Future Research

301

• Performance of the mobile device can be in-

creased by moving security analysis to an external

system. Security systems like Paranoid Android

(Portokalidis et al., 2010) and Mobile-Sandbox

(Spreitzenbarth et al., 2015) are already using this

approach. However, this leads to a further limi-

tation because the next bottleneck on mobile de-

vices is caused by network connectivity and per-

formance. Additionally, trust is a big issue if se-

curity analysis does not run on the mobile device

itself.

• Security analysis can be executed before the ap-

plication is used on a mobile device. In terms

of performance, this is the best solution because

it generates no performance overhead on the mo-

bile device. The problem of this approach is – of

course – that the behavior of the app is not moni-

tored at runtime. Eventually, this limitation could

be mitigated by rerunning security analysis over

the time of use.

5.3 User Interface Complexity

A runtime security analysis either has to be fully au-

tomated or the user has to react manually to identify

potential security risks. Without expert knowledge in

computer security, however, the average user may re-

act incorrectly to the security systems warning. An-

other – maybe worse – reaction to messages of the

security system could be deactivation of the detection

mechanism in case the user is overwhelmed by the

amount and complexity of security warnings.

Potential Research. The complexity of the exist-

ing security systems for average users is theoretically

easy to reduce by transferring the responsibility from

the average user to an expert. However, this respon-

sibility transfer is accompanied by rising costs for the

company, which originally did not intend to put the

security in the hands of their employees. Neverthe-

less, it is irresponsible to force an average user to take

security-relevant decisions.

5.4 Analysis Abstraction Level

Most of the security systems use a fully automated

high level analysis or a manual low level analysis. A

good balance between these two analysis approaches

is rare. Especially the lack of customizability of the

data collection mechanisms and security analysis is

the major disadvantage of most existing systems.

Potential Research. There are reasons for low-

level and high-level approaches; however, their focus

is different: fully automated security analysis systems

are designed to minimize the analysis effort for the

user, whereas manually executed analysis, which is a

high effort for the user, has other advantages like the

ability to analyze speciﬁc parts – say system calls –

of an application. A good balance between these two

approaches can mitigate various disadvantages. Addi-

tionally, it is be beneﬁcial if the security system user

can choose the abstraction level on basis of the given

app, the security objectives and a given suspicion as

discussed below. To make the analysis level adapt-

able, future systems should be able to provide anal-

ysis methods of different analysis levels. A modular

architecture, which can be extended with additional

analysis methods, can satisfy this need.

The potential reseach directions of 5.3 and 5.4 go

hand in hand. Systems that aim end users often try

to automate the complete analysis process. In doing

so, however, the systems are limited to detecting spe-

ciﬁc attacks (with signature-based analysis) or detect-

ing abnormal behavior (with anomaly-based analy-

sis). Abnormal behavior does not necessarily indicate

that the system is under attack. Otherwise, ”normal”

behavior does not necessarily indicate that the system

is free of ongoing attacks.

5.5 Detection of Collaborating Apps

Taint-tracking systems can be used to detect informa-

tion ﬂows between apps. However, they are only able

to analyze information ﬂows that use overt channels

like IPC.

Potential Research. All security analysis ap-

proaches which are limited to the analysis of one app

are inappropriate. Future systems should allow, to

install and execute more than one app at a time and

to monitor possible information ﬂows between these

apps.

5.6 Security Analysis Rerun

Because of the short release cycles of Android apps as

well as of Android itself, an automated rerun of secu-

rity analysis and a subsequent comparison of analysis

results seem to be an important function of a secu-

rity system. In order to fully exhaust the potential of

analysis reruns, degrees of freedom as well as varia-

tions should be considered. Variation arises through

even minimal divergences in automatic security anal-

ysis reruns. Degrees of freedom instead are desirable

because they enable the user to repeat a security anal-

ysis run with slightly different variables, if necessary.

SECRYPT 2019 - 16th International Conference on Security and Cryptography

302

Such variables can, for example, be a newer version

of an app or a new version of a mobile device OS.

Potential Research. The inability of a system to re-

run security analyzes is a major limitation of exist-

ing systems. However, this issue occurs only on up-

stream security analysis approaches, which have a de-

ﬁned start and end. For security analysis approaches

which are not executed at runtime on mobile devices,

it makes sense to enable the system to record an exe-

cuted security test and to replay it automatically to re-

run the security test for a given application. This can

decrease the amount of work for testing because the

responsible employee does not have to repeat the tests

manually. Linked to an automated security test re-

run functionality, other useful features should be dis-

cussed:

• An automatically executed test replay is particu-

larly useful when certain degrees of freedom are

possible. Examples for reasonable degrees of

freedom are: app version, Android version as well

as a variety of apps which are executed simultane-

ously.

• A second useful feature is the possibility to replay

recorded security analysis runs in parts. Thereby,

a rerun can be speeded up in case only some spe-

ciﬁc parts have to be analyzed, for example, when

only a speciﬁc part of the original test run leads to

an information disclosure attack.

• To save resources, the automatically executed test

rerun can be speeded up by shortening pauses be-

tween user interactions and system events.

• A security system that provides automated test re-

runs does not have to be executed locally: at least

the replays can be executed in a cloud or web ser-

vice. In combination with the additional compar-

ing function, the security analysis can be further

automated: after an executed test rerun, the results

of the original test run and of the actual one can be

compared. If the security level had changed, that

could also be reported to the user.

5.7 Granularity of Reaction

Most systems adopt the all-or-nothing principle. It

means that possible reactions are not ﬁne-grained

enough. An example is AppFence that disconnects

all internet connections as soon as a possible infor-

mation disclosure is detected (Russello et al., 2011).

In this case, it would actually be sufﬁcient to inter-

rupt only the connection through which the informa-

tion has been leaked.

Potential Research. The security systems dis-

cussed above neither provide automated reactions nor

suggest reactions to the user. For systems, no au-

tomated reaction system is needed when the system

does not run on mobile devices with real sensitive

data.

5.8 Suspicion-based Analysis

This shortcoming is closely connected with restric-

tions due to the predetermined analysis abstraction

level. A fully automated analysis or a manual analysis

system are not appropriate to analyze an application

for a speciﬁc suspicion. A security analysis approach

is needed that can be used to analyze the behavior of

an app to conﬁrm or rule out the suspicion.

Potential Research. A suspicion-based analysis

can not be done with taint-tracking systems or most of

the other security systems discussed previously. That

means that these systems are not able to analyze a spe-

ciﬁc part of an application that seems suspicious for

whatever reason. To analyze a speciﬁc suspicion, the

analysis data collection and the analysis itself have to

be adaptable; thus, a fully automated test run is not

appropriate. For suspicion-based analysis, the data

collection phase needs to be manually controlled by

the user. Therefore, analysis systems which run in

parallel are neither appropriate. In order to prevent

misunderstandings: the inappropriate ability of au-

tomatic analysis systems to perform suspicion-based

analysis should not be confused with automated re-

plays, as discussed before. Automated replays can

also be used in a suspicion-based analysis, for exam-

ple to test a suspicious function of an app under dif-

ferent conditions.

Table 4 shows the mapping between shortcomings

and taint-tracking systems. Stars (*) indicate a short-

Table 4: Summary of Shortcomings.

Detection

Rates

Limited sys-

tem resources

User Interface

complexity

Analysis ab-

straction level

Detection of

collaborating

apps

Security anal-

ysis rerun

Reaction

granular-

ity

Suspicion-

based analysis

TaintDroid * * * * * * * - *

TaintART * * * * * * - *

TaintMan * * * * * * - *

Andrubis * - - * * * - *

AppFence * * * * * * * *

AppsPlayground * - - * * * - *

DroidBox * * * * * * - *

Graa et al. * * * * * * - *

Mobile Sandbox * - - * * * - *

MOSES Droid * * * * * * * *

Ndroid * - - * - * * *

TreeDroid * - - * * * - *

QuantDroid * * * * * * - *

vetDroid * - - * * * - *

YAASE * * * * * * - *

Legend: * ... shortcoming applies; - ... shortcoming does not apply

Dynamic Taint-tracking: Directions for Future Research

303

coming for a speciﬁc system. Dashes (-) are used

when a shortcoming has not been proved to be true.

To address some of the above shortcomings, we

propose a changed security analysis concept, that is

based on dynamic taint-tracking: instead of a live

analysis we propose an (1) upstream analysis ap-

proach, which is executed by a security expert before

the the app is used in a productive way. The analysis

is executed in a (2) virtualized environment, which al-

lows an extended analysis data collection mechanism.

Existing systems, that are executed on real mobile de-

vices are limited by performance reasons. Since the

virtualized device is not used in a productive way, it

is possible to use fake data instead of real sensitive

data. Thereby the analysis puts no real sensitive data

on risk. To extend the system’s architecture, the sys-

tem needs to be built on an (3) extendable and open

architecture. Our future work will target this security

analysis concept.

6 SUMMARY

In this paper, advantages and disadvantages of static

and dynamic security analyzes have been compared.

Because of the limitations of static analysis, we have

focused on dynamic analysis systems for detecting

app-based information disclosure attacks. Android as

the given target platform has narrowed the evaluated

systems for analyzing Android apps.

To detect information disclosure attacks, taint-

tracking seems to be a promising approach. At

the time of this writing, neither the source code of

TaintART nor that of TaintMan has been released,

Taintdroid and its unofﬁcial successors remain the

main available taint-tracking approaches for analyz-

ing Android apps. Some of the discussed systems

seem to be outdated; however, since every system has

its speciﬁc purpose, we believe it is necessary to re-

view the research done on the topic and different ap-

proaches for improving taint-tracking. The evolved

shortcomings show that there is a need for further re-

search and new security systems.

Although all discussed shortcomings are impor-

tant, we are convinced that particularly the replay of

security analysis runs with the ability to compare the

security analysis results are an important feature for

future taint-tracking and other security systems. For

all security systems that follow a scanner approach,

the possibility of automated security analysis reruns

with result comparison seems the only appropriate

way given the amount of apps used, the short re-

lease cycles of apps and mobile device OS as well as

the heterogeneity of mobile computing caused by the

amount of mobile device manufactures, mobile device

OS and versions.

REFERENCES

Bosman, E., Slowinska, A., and Bos, H. (2011). Minemu:

The world’s fastest taint tracker. In Hutchison, D.

e. a., editor, Recent Advances in Intrusion Detection,

volume 6961 of Lecture Notes in Computer Science,

pages 1–20. Springer Berlin Heidelberg.

Dam, M., Le Guernic, G., and Lundblad, A. (2012). Tree-

droid: A tree automaton based approach to enforcing

data processing policies. In Proceeding CCS ’12 Pro-

ceedings of the 2012 ACM conference on Computer

and communications security, page 894.

Enck, W., Gilbert, P., Chun, B.-G., Cox, L. P., Jung, J., Mc-

Daniel, P., and Sheth, A. N. (2010). Taintdroid: an

information-ﬂow tracking system for realtime privacy

monitoring on smartphones. In Proceeding OSDI’10

Proceedings of the 9th USENIX conference on Oper-

ating systems design and implementation.

Enck, W., Gilbert, P., Han, S., Tendulkar, V., Chun, B.-G.,

Cox, L. P., Jung, J., McDaniel, P., and Sheth, A. N.

(2014). Taintdroid: An information-ﬂow tracking sys-

tem for realtime privacy monitoring on smartphones.

ACM Transactions on Computer Systems, 32(2):1–29.

Enck, W. H. (May 2011). Analysis Techniques for Mobile

Operating System Security. PhD thesis, Pennsylvania

State University.

Graa, M., Cuppens-Boulahia, N., Cuppens, F., and Cavalli,

A. (2015). Detection of illegal control ﬂow in an-

droid system: Protecting private data used by smart-

phone apps. In Cuppens, F., Garcia-Alfaro, J., Zincir

Heywood, N., and Fong, P. W. L., editors, Founda-

tions and Practice of Security, volume 8930 of Lecture

Notes in Computer Science, pages 337–346. Springer

International Publishing.

Hornyack, P., Han, S., Jung, J., Schechter, S., and Wether-

all, D. (2011). These aren’t the droids you’re looking

for: retroﬁtting android to protect data from imperious

applications. In Chen, Y., Danezis, G., and Shmatikov,

V., editors, Proceedings of the 18th ACM conference

on Computer and communications security, page 639.

Lantz, P. and Delosieres, L. (2015). Droidbox - android

application sandbox.

Lindorfer, M., Neugschwandtner, M., Weichselbaum, L.,

Fratantonio, Y., Victor van der Veen, and Platzer, C.

(2014). Andrubis - 1,000,000 apps later: A view on

current android malware behaviors. In Proceedings of

the the 3rd International Workshop on Building Anal-

ysis Datasets and Gathering Experience Returns for

Security (BADGERS).

Mollus, K., Westhoff, D., and Markmann, T. (2014). Cur-

tailing privilege escalation attacks over asynchronous

channels on android. In 14th International Conference

on Innovations for Community Services (I4CS), pages

87–94.

Neuer, S., van der Veen, V., Lindorfer, M., Huber, M.,

Merzdovnik, G., Mulazzani, M., and Weippl, E.

SECRYPT 2019 - 16th International Conference on Security and Cryptography

304

(2014). Enter sandbox: Android sandbox compari-

son. In Koved, L., Singh, K., Chen, H., and Just, M.,

editors, Proceedings of the Third Workshop on Mobile

Security Technologies (MoST) 2014.

Portokalidis, G., Homburg, P., Anagnostakis, K., and Bos,

H. (2010). Paranoid android: versatile protection for

smartphones. In Gates, C., Franz, M., and McDer-

mott, J., editors, Proceedings of the 26th Annual Com-

puter Security Applications Conference (ACSAC ’10),

page 347.

QEMU Project (2017). Documentation/networking.

Qian, C., Luo, X., Shao, Y., and Chan, A. T. (2014). On

tracking information ﬂows through jni in android ap-

plications. In 2014 44th Annual IEEE/IFIP Interna-

tional Conference on Dependable Systems and Net-

works (DSN), pages 180–191. IEEE.

Rasthofer, S., Arzt, S., Miltenberger, M., and Bodden, E.

(February 21-24, 2016). Harvesting runtime values

in android applications that feature anti-analysis tech-

niques. In Capkun, S., editor, Proceedings 2016 Net-

work and Distributed System Security Symposium. In-

ternet Society.

Rastogi, V., Chen, Y., and Enck, W. (2013). Appsplay-

ground: automatic security analysis of smartphone ap-

plications. In Bertino, E., Sandhu, R., Bauer, L., and

Park, J., editors, Proceedings of the third ACM con-

ference on Data and application security and privacy,

page 209.

Russello, G., Conti, M., Crispo, B., and Fernandes, E.

(2012). Moses: Supporting operation modes on smart-

phones. In Proceedings of the 17th ACM symposium

on Access Control Models and Technologies - SAC-

MAT ’12, page 3. ACM Press.

Russello, G., Crispo, B., Fernandes, E., and Zhauniarovich,

Y. (2011). Yaase: Yet another android security exten-

sion. In 2011 IEEE Third Int’l Conference on Privacy,

Security, Risk and Trust (PASSAT) / 2011 IEEE Third

Int’l Conference on Social Computing (SocialCom),

pages 1033–1040.

Sarwar, G., Mehani, O., Boreli, R., and Kaafar, M. A.

(2013). On the effectiveness of dynamic taint anal-

ysis for protecting against private information leaks

on android-based devices. In Samarati, P., editor, SE-

CRYPT 2013, 10th International Conference on Secu-

rity and Cryptography. SciTePress.

Shirey, R. (2007). Rfc 4949: Internet security glossary, ver-

sion 2.

Spreitzenbarth, M., Freiling, F., Echtler, F., Schreck, T.,

and Hoffmann, J. (2013). Mobile-sandbox: having

a deeper look into android applications. In Shin, S. Y.

and Maldonado, J. C., editors, the 28th Annual ACM

Symposium, page 1808.

Spreitzenbarth, M., Schreck, T., Echtler, F., Arp, D., and

Hoffmann, J. (2015). Mobile-sandbox: combining

static and dynamic analysis with machine-learning

techniques: Combining static and dynamic analy-

sis with machine-learning techniques. International

Journal of Information Security, 14(2):141–153.

Sufatrio, Tan, D. J. J., Chua, T.-W., and Thing, V. L. L.

(2015). Securing android: A survey, taxonomy, and

challenges. ACM Computing Surveys, 47(4):1–45.

Sun, M., Wei, T., and Lui, J. C. (2016). Taintart: A prac-

tical multi-level information-ﬂow tracking system for

android runtime. In Katzenbeisser, S. and Weippl, E.,

editors, Proceedings of the 2016 ACM SIGSAC Con-

ference on Computer and Communications Security,

pages 331–342. Association for Computing Machin-

ery.

Tam, K., Feizollah, A., Anuar, N. B., Salleh, R., and Caval-

laro, L. (2017). The evolution of android malware and

android analysis techniques. ACM Computing Sur-

veys, 49(4):1–41.

Wei, F., Roy, S., Ou, X., and Robby (2014). Amandroid: A

precise and general inter-component data ﬂow analy-

sis framework for security vetting of android apps. In

Ahn, G.-J., editor, Proceedings of the 21st ACM Con-

ference on Computer and Communications Security,

pages 1329–1341. ACM.

Weichselbaum, L., Neugschwandter, M., Lindorfer, M.,

Fratantonio, Y., van der Veen, V., and Platzer, C.

(2014). Andrubis: Android malware under the mag-

nifying glass.

Xia, M., Gong, L., Lyu, Y., Qi, Z., and Liu, X. (2015). Ef-

fective real-time android application auditing. In 2015

IEEE Symposium on Security and Privacy (SP), pages

899–914. IEEE.

Xu, M., Qian, C., Lee, S., Kim, T., Song, C., Ji, Y., Shih,

M.-W., Lu, K., Zheng, C., Duan, R., Jang, Y., and

Lee, B. (2016). Toward engineering a secure android

ecosystem. ACM Computing Surveys, 49(2):1–47.

You, W., Liang, B., Shi, W., Wang, P., and Zhang, X.

(2017). Taintman: An art-compatible dynamic taint

analysis framework on unmodiﬁed and non-rooted an-

droid devices. IEEE Transactions on Dependable and

Secure Computing, page 1.

Zhang, Y., Yang, M., Xu, B., Yang, Z., Gu, G., Ning, P.,

Wang, X. S., and Zang, B. (2013). Vetting undesirable

behaviors in android apps with permission use analy-

sis. In Sadeghi, A.-R., Gligor, V., and Yung, M., edi-

tors, The 2013 ACM SIGSAC conference, pages 611–

622.

Zhauniarovich, Y., Russello, G., Conti, M., Crispo, B.,

and Fernandes, E. (2014). Moses: Supporting and

enforcing security proﬁles on smartphones. IEEE

Transactions on Dependable and Secure Computing,

11(3):211–223.

Zheng, M., Sun, M., and Lui, J. C. (2014). Droid-

trace: A ptrace based android dynamic analysis sys-

tem with forward execution capability. In 2014 Inter-

national Wireless Communications and Mobile Com-

puting Conference (IWCMC), pages 128–133.

Dynamic Taint-tracking: Directions for Future Research

305