Identifying Insecure Features in Android Applications

using Model Checking

Fabio Martinelli

, Francesco Mercaldo

and Vittoria Nardone

Istituto di Informatica e Telematica, Consiglio Nazionale delle Ricerche (CNR), Pisa, Italy

Department of Engineering, University of Sannio, Benevento, Italy

Keywords:

Android, Model Checking, Security.

Abstract:

Nowadays Android is the most widespread operating system. This is the reason why malware writers target

it. Both researchers and commercial antimalware provide several solutions to ﬁx and detect this phenome-

non. They analyze one single application per time using combinations of static, dynamic and behavior based

techniques. However, one of the last new threats is the collusion attack. In order to perpetrate this attack

the malicious behaviour is divided between two or more applications: collusion refers to multiple applicati-

ons that accomplish their fragment of malicious behaviour and then communicate using the Inter Component

Communication mechanism provided by Android platform. Basically the colluded applications intentionally

put in view private and sensitive information. The aim of this paper is to investigate whether legitimate and

malware applications share private data. One way to exchange data between different applications in Android

environment is through Shared Preferences. In this preliminary work we investigate whether an application

transfers data using Shared Preferences with public visibility.

1 INTRODUCTION

As reported in the IDC report

, Android continues

to be the most dominant platform and its popularity

will continue to grow. Due to this large popularity,

malware writers are developing more aggressive pa-

radigms of attack.

The new trend in this area is represented by the so-

called colluding attack: the malicious action is split-

ted in several applications. In this way current anti-

malware technologies, that analyze an application in

order to discover harmful action as a single entity, are

not able to identify the malicious payload.

In collusion attacks, a malicious operation is per-

formed through multiple applications: it is divided

into multiple parts and distributed among a set of col-

luding applications. In order to achieve their malici-

ous aims, the applications communicate trough Inter

Component Communication (ICC) mechanism. Each

application avoids suspicion by requesting the mini-

mum permissions needed for its role. For example,

when two applications collude, the ﬁrst application

might read sensitive data and transmit them to the se-

cond application, which transmits them to the outside

https://www.idc.com/getdoc.jsp?

containerId=prUS41425416

world. Analyzed individually, the applications would

be considered benign because there is no direct path

from sensitive data to their transmission.

Different research works ((Xu et al., 2016; Li

et al., 2014; Enck et al., 2014; Wei et al., 2014)) inves-

tigate information leaks using inter-component data

ﬂow analysis. However, these security techniques are

focused to detect vulnerabilities in a single applica-

tion, but fail to identify vulnerabilities involving mul-

tiple applications.

Recently, academic researches have extended ﬂow

analysis to include multiple applications using ICC

channels in order to communicate with each other (Li

et al., 2015b; Bhandari et al., 2017).

Conversely, this paper wants to investigate whet-

her legitimate and malware applications intentionally

put in view some data. In fact, in colluding attack the

applications intentionally exhibit private data. Thus,

this work not performs data ﬂow analysis but it inves-

tigates whether a data vulnerability is exposed using

model checking.

The proposed method aims to identify Shared Pre-

ferences feature with a public data, since intentionally

sharing some data is the ﬁrst step to mark an applica-

tion as good candidate in order to exﬁltrate data.

The remainder of this paper is organized as fol-

Martinelli F., Mercaldo F. and Nardone V.

Identifying Insecure Features in Android Applications using Model Checking.

DOI: 10.5220/0006758105890596

In Proceedings of the 4th International Conference on Information Systems Security and Privacy (ICISSP 2018), pages 589-596

ISBN: 978-989-758-282-0

lows. In Section 2 the state of the art related to collu-

ding attack research effort is analyzed. Section 3 pro-

vides the background knowledge required to under-

stand the working environment. Section 4 motivates

the aim of the work through an illustrative example.

In Section 5 the workﬂow of the proposed methodo-

logy is depicted. Section 6 shows the results obtained

during the evaluation and Section 7 discusses some

aspect of the work and investigates for further directi-

ons. Finally, Section 8 concludes the work.

2 RELATED WORK

The following section presents different experimen-

tal approaches for the detection of intra and inter-

application communication vulnerabilities.

Authors in (Liu et al., 2017) present MR-Droid

a MapReduce based framework able to detect inter-

app communication threats. Is is specialized in intent

hijacking, intent spooﬁng and collusion. MR-Droid

builds a large-scale ICC graph extracting data-ﬂow

features between multiple communicating apps. This

kind of approach is scalable and accurate. However,

it is able to only handle intent based communications.

Another limitation is related to detection of privacy

leakage across two apps.

Bhandari et al. in (Bhandari et al., 2017) present

a model-checking based approach to detect inter-app

collusion. The proposed approach is composed by

four steps. The ﬁrst step aims to collect information

related to ICC sources and sinks. The second step car-

ries out data-ﬂow analysis in order to map sensitive

information provided by sensitive API call. The third

step aims to generate for each app a PROMELA mo-

del. In the fourth step, model checking is applied in

order to verify the collusion detection property on the

generated models. Whether the compositional model

of apps satisfy the property, then that set of apps is not

a colluding set candidate.

Filiol and Irolla in (Filiol, ) propose three diffe-

rent tools. The ﬁrst one, called Tarentula, is a web

crawler collecting mobile applications. The second

one, called Egide, is a static malware detector. Fi-

nally Panoptes, the third one, is an advanced dynamic

tool analyzing network communications. It can moni-

tor all communications based on HTTP, HTTPS, POP,

IMAP, SMTP between the application and the Inter-

net. It especially addresses the issue of data privacy

regarding banking apps and Facebook app. (Filiol, )

analyzes only the network trafﬁc, instead this work

aims to investigate the feasible exposure of some data

using the Android communication channels.

Authors in (Asavoae et al., 2016) propose two

approaches able to identify collusion apps candida-

tes. The ﬁrst one is a rule based approach developed

in Prolog. The second one is a statistical based ap-

proach. The rule based approach use some features

(e.g. permissions, communication channels) to iden-

tify colluding apps. In the statistical approach a pro-

babilistic model is deﬁned. Additionally the authors

say that also model-checking is a feasible approach to

detect collusion in Android apps.

Authors in (Li et al., 2015b) propose IccTA which

is a static taint analyzer to detect privacy leaks be-

tween components in Android applications. Com-

bining it with APKCombiner (Li et al., 2015a),

IccTA can also detect inter-app leakage paths. IccTA

goes beyond state-of-the-art approaches by suppor-

ting inter-component detection. IccTA improves the

precision of the analysis spreading context informa-

tion between components.

In (Bagheri et al., 2015) Bagheri et al. present CO-

VERT, a tool for compositional analysis of Android

inter-app vulnerabilities. COVERT statically analy-

zes the source code of each application, then it ex-

tracts relevant security speciﬁcations in a format suit-

able for formal veriﬁcation. COVERT uses model

checker tool in order to verify whether the formal mo-

del deﬁned is affected by collusion.

Conversely from the above approaches, this work

aim to investigate whether an application deﬁnes pu-

blic communication channels. In particular, this paper

investigates if into applications there are Shared Pre-

ferences with a world readable visibility. As speciﬁed

in the Android developers guide, using a Shared Pre-

ferences with this kind of visibility is very dangerous.

In these kind of cases every applications have access

to the Shared Preferences information.

3 PRELIMINARIES

This section aims to introduce some preliminary con-

cepts related to the android environment and model

checking technique.

3.1 Android Overview

Linux Kernel is the base of the Android Operating

system. In Android system the applications run in

an isolated sandbox. In order to protect the device

the Android operating system provides several secu-

rity features: application signing, application-deﬁned

and user-granted permissions and secure interprocess

communication. Permissions are used to regulate the

access to sensitive resources, such as users’ personal

information or sensor data (e.g., camera, GPS, etc.).

Android applications are developed in Java. They

are composed by four different components: Activi-

ties, Services, Broadcast Receivers and Content Pro-

viders. An application may be build using many dif-

ferent components and any their combination. In the

following, these components are brieﬂy described:

An Activity usually allows the interaction with the

physical user. It includes a set of GUI components

representing the visible interface to the user.

A Service deals of background computations

which keep on even when the application is not in fo-

cus. It also provides interfaces for Inter Component

Communication exposing some of its functionality to

other applications.

Broadcast Receivers allow to receive broadcast

messages both from the other application or the sy-

stem. It implements a sort of publish-subscribe design

pattern. Usually, when an event occurs a broadcast is

sent by either the system or an application. In order

to receive speciﬁc broadcasts an application can be

subscribed to it.

Content Provider provides a mechanism able to

sharing data with other applications. It shares data as

relational database-like model.

3.1.1 Inter Component Communication (ICC)

Android framework provides some channel for inter

component communication. The main Android com-

munication channels are the following:

• Intent allows to application components to invoke

other components of the same or other applicati-

ons. Using Bundles it is also possible to pass data

between different components. An Intent is the

preferred messaging object for asynchronous ICC

in Android. It contains the following primary in-

formation: component name, action string, cate-

gory and data. These information are optional.

Based on presence/absence of component name

(i.e. the destination) there are two type of intent:

Explicit and Implicit Intent. In the ﬁrst case the

destination is speciﬁed in the second case no des-

tination is speciﬁed.

• Content Provider is like relational databases. It

stores structured data and can be used to transfer

data across components of same or different apps.

The data can be accessed and modiﬁed using Con-

tentResolver objects. Best practice is to attach

read and write permissions to the content provi-

der, in order to protect it from data exposure.

• External Storage is the storage space external

to an app. It is placed in the SD card. Ex-

ternal storage can be accessed using the follo-

wing permissions: READ EXTERNAL STORAGE and

WRITE EXTERNAL STORAGE.

• Shared Preferences allow applications to store

key-value pairs of data. It is an operating system

feature and it is usually used to store preferences

information. Applications can access to key-value

pairs data according to the mode visibility deﬁned

for the preferences. This paper aim to focus on

mode visibility used to deﬁne a Shared Preferen-

ces. Since using a public visibility could be ex-

pose an application to a data exﬁltration. To more

detail see Section 4.

3.2 Model Checking

Complex systems veriﬁcation and speciﬁcation is

usually performed using Formal Methods. Model

Checking belongs to formal techniques and requires

three main phases:

• modeling the system with a precise notation;

• specifying the system behavioural properties with

a precise notation;

• verifying the properties on the system using a mo-

del checker tool.

While model checking was originally developed to

verify the correctness of systems, recently it has been

also proposed in other ﬁelds such as clone detection

(Santone, 2011), biology (De Ruvo et al., 2015), se-

cure information ﬂow (De Francesco et al., 2003), and

mobile computing (Anastasi et al., 2001). In the last

years, model checking has been successfully applied

also in the security ﬁeld, as explained in the following

works: (Battista et al., 2016) and (Mercaldo et al.,

2016). The main aim of these works is to detect and

identify Android malware families.

In the following the three phases of model

checking are detailed.

Modeling the System

The system behavior is deﬁned using an automaton. It

has a set of labeled edges and a set of nodes. The sta-

tes of the system are represented by the nodes while

the transitions from a state to another state (precisely

the next state) are represented by the edges. Every ed-

ges have a label meaning that the system can switch

from a state s to a state s

performing an action a. This

action a is the label of the edge. The automaton’ root

is the initial state of the system and usually a transi-

tion is depicted as follow: s

−→s

Processes are an algebraical helpful representa-

tion to deﬁne the automaton. Thus, the precise nota-

tion used to describe complex systems is usually the

process algebra. The methodology of this work uses

Milner’s Calculus of Communicating Systems (CCS)

Figure 1: Vulnerable Applications: a Simple Example.

(Milner, 1989) as process algebra. In CCS process

algebra the states of the system are modeled through

processes and the transitions are modeled using the

actions. The reader can refer to (Bruns, 1997; Milner,

1989) for more details on CCS.

Specifying the Properties

The behavioural properties of the system can be de-

ﬁned using a temporal logic. Usually properties are

sequences of actions that a system should perform in

order to accomplish a particular purpose. In order to

formally verify this kind of properties temporal logic

constructs are used. General examples of properties

can be the following: verifying whether a particular

event will eventually occur or a property is veriﬁed

in every state. This work uses the mu-calculus lo-

gic(Stirling, 1989).

Formal Veriﬁcation Environment: Model Checker

Tool

The last phase of Model Checking technique is the

veriﬁcation of the speciﬁed properties (temporal lo-

gic formulae) on the system (labeled transition sy-

stem). To accomplish this aim a model checker tool

is usually used. It takes as input both the modeled

system and the properties. The model checker provi-

des a binary output: whether the system veriﬁes the

property it return TRUE or FALSE otherwise. The tool

performs an exhaustive state space search is guaran-

teed to terminate since the model is ﬁnite. In this work

the Concurrency Workbench of New Century (CWB-

NC) (Cleaveland and Sims, 1996) is used as formal

veriﬁcation environment.

4 MOTIVATING EXAMPLE

Figure 1 shows a pattern example of inter applications

vulnerabilities. This example point out the privilege

escalation that motivates this work. The ﬁgure shows

a malicious application App1 sharing a public Shared

Preferences containing the contact list of a user. App2

takes this list, without the READ

CONTACTS permis-

sion, and sends it, through Internet, to a remote ser-

ver. This is a simple example of a vulnerability using

Inter Component Communication (ICC) among An-

droid apps.

As the ﬁgure shown, the privilege escalation is ex-

ploited since the Shared Preferences visibility is pu-

blic. For this reason, our work aims to investigate

in Android environment whether legitimate and mal-

ware applications employ Shared Preferences with

public visibility. Thus, this work searches the inse-

cure feature related to a public Shared Preferences.

5 METHODOLOGY

Figure 2 shows the methodology workﬂow. This mo-

del checking based methodology has two main steps:

• building the model starting from Bytecode in-

structions of an Android application;

• specifying the properties checking insecure featu-

res related to Android Shared Preferences.

Formal Model

In order to build the formal model of an Android ap-

plication this methodology aims, using a reverse engi-

neering process, to obtain the app executable ﬁles, i.e.

the .class ﬁles. Starting from the apk ﬁle dex2jar

tool is used to obtain the Java Archive ﬁle (jar) from

the application Dalvik Executable ﬁle (dex). The exe-

cutable ﬁles are extracted from the from the jar ﬁle

through the jar -xvf command provided by the Java

Development Kit. At the end of this reverse engi-

neering process the classes of the Android application

are obtained. Afterwards, Apache Commons Byte-

code Engineering Library (BCEL)

is used to parse

the Bytecode. Finally, every Bytecode instruction

is translated in an algebraical process. In particular,

as state before, this methodology uses CCS language

(Calculus of Communicating Systems of Milner (Mil-

ner, 1989)). Using a Java Bytecode-to-CCS trans-

formation function every Java Bytecode instruction

is translated in a CCS process. This representation

allows to simulate the normal ﬂow of the instructi-

ons. A simple example of this transformation function

is the following: the if statement is translated as a

non-deterministic choice. In this case the system can

evolve from a process s to two different processes

and s

, corresponding to the two alternative paths

(true/false) of the classical if statement.

The formal model construction is an automatic

process in this methodology. The output of this ﬁrst

step is the formal model of the application.

https://sourceforge.net/projects/dex2jar/

http://commons.apache.org/bcel/

Figure 2: Methodology Workﬂow.

Behavioural Properties

The aim of this second step is to investigate whet-

her an application is developed using insecure feature

which may cause security issues in mobile applicati-

ons. In this methodology the deﬁned behavioural pro-

perty investigates whether a Shared Preferences is de-

clared as: MODE WORLD READABLE. Usually, this mode

is indicated through the (0x00000001) constant value.

In Bytecode this value is translated with the iconst 1

opcode. In order to better understand this kind of in-

secure feature, an example of Shared Preferences de-

claration is reported in Listing 1.

As listing 1 shown, the getSharedPreferences

method has two arguments: the name of the prefe-

rences ﬁle and the operating mode. If a preferences

ﬁle by the speciﬁed name does not exist, it will

be created editing and committing the changes.

The operating mode can assume the following

values: MODE PRIVATE, MODE WORLD READABLE,

MODE WORLD WRITEABLE or MODE MULTI PROCESS.

Using the MODE PRIVATE mode the created ﬁle can

only be accessed by the calling application. The other

cases allow all other applications to have access to

the created ﬁle. Creating ﬁles using these ways can

imply security issues, and may generate insecurity

applications. For this reason this paper aims to

investigate whether an application uses public Shared

Preferences which are visible to all other applications

installed on mobile devices.

Table 1 shows the logic rule ϕ related to the above

explained unsafe behaviour.

The mu-calculus logic, (Stirling, 1989) as a bran-

ching temporal logic, is used to describe a determi-

ned behavior of the app. In this formula is used the

last ﬁxpoint (µZ.φ) of the recursive recursive equa-

tion Z = φ. µZ binds free occurrences of Z in φ. An

occurrence of Z is free if it is not within the scope of a

binder µZ. Finally, at the end of this second step, the

temporal logic rule is speciﬁed.

Formal Veriﬁcation Environment

In this approach the Concurrency Workbench of New

Century (CWB-NC) (Cleaveland and Sims, 1996) is

used as formal veriﬁcation environment. The CWB-

NC model checker takes as input the formal model of

an application (written in CCS) and the temporal logic

property written in mu-calculus. The output of this

veriﬁcation step is binary: true, whether the property

is veriﬁed on the model and false otherwise. For

this approach, an application is considered insecure

whether the property ϕ shown in Table 1 is veriﬁed

on the model.

It is well-known that a model checking technique

typically suffers of the state explosion problem. In

fact, it is mainly applicable to small-scale applicati-

ons, but do not scale up well. However, the state ex-

plosion problem is not a real problem when verifying

Android applications, since the produced CCS spe-

ciﬁcations do not have a large number of states and

transitions.

6 SECURITY EVALUATION

In order to evaluate this methodology, two different

dataset are used: 200 legitimate applications and 200

real world samples belonging to the Drebin project’s

dataset (Arp et al., 2014; Spreitzenbarth et al., 2013).

The legitimate applications are downloaded from

Google Play

, the Android ofﬁcial market. These

trusted applications have been crawled from the Goo-

gle’s ofﬁcial app store

using an open-source cra-

wler

. They were downloaded by between January

2016 and April 2016. The legitimate applications of

this dataset belonging to all the different categories

available on the market.

https://play.google.com

https://play.google.com/store

https://github.com/liato/android-market-api-py

1 S h a r e d P r e f e r e n c e s g e t S h a r e d P r e f e r e n c e s ( S t r i n g name , i n t mode )

Listing 1: Example of SharedPreferences declaration.

Table 1: An example of logic rule.

ϕ = µX = hiconst 1i hinvokegetSharedPre f erencesi tt ∨ h−iconst 1, invokegetSharedPre f erencesi X

The malware dataset is a very well known col-

lection of malware which includes the most diffused

Android: in the evaluation we consider four diffe-

rent families with 50 samples for each one of them.

The analyzed families are the following: FakeInstal-

ler, GinMaster, Opfake and Plankton.

Table 2 shows the results achieved during the in-

vestigation related to the legitimate applications. Ta-

ble 2 is organized as follow: considering the ϕ for-

mula, # Secure Apps is the number of apps resulting

false to the formula; # Insecure Apps is the number

of apps resulting true to the formula. The last column

is the number of total applications analyzed in this

preliminary work.

As the table shown, 17 applications are classi-

ﬁed as insecure. In fact, these applications declare

Shared Preferences with a public visibility. Cre-

ating world-readable ﬁles is very dangerous and 17

applications belonging to this dataset have done it.

Table 2: Security Evaluation on Legitimate Applications.

Family

# Secure Apps # Insecure Apps # Legitimate

ϕ = FALSE ϕ = T RU E Apps

Legitimate 183 17 200

Conversely, Table 3 shows the results achieved du-

ring the investigation related to the malware samples.

Table 3 is organized as follow: each row shows the

results achieved by each family evaluating the ϕ for-

mula. As stated before, this methodology considers

as Secure Apps the samples resulting false to the for-

mula ϕ and classiﬁes as Insecure Apps the samples

resulting true to the formula ϕ. The last column shows

the number of samples belonging to each family in-

volved in this evaluation. As the table shown, 47

malware samples are classiﬁed as insecure, this me-

ans that 47 malware samples have deﬁned Shared

Preferences with a public visibility. The results also

highlight that only the samples belonging to Opfake

and Plankton families expose this kind of vulnerabi-

lity.

Another result is related to the comparison bet-

ween legitimate and malware applications. In par-

ticular, the tables 2 and 3 show that the number of

malware samples affected by Shared Preferences vul-

nerability (47) is greater than the number of legiti-

mate applications (17). This preliminary result seems

to indicate that legitimate applications are less vul-

nerable if compared with the malware samples, since

Shared Preferences with a public visibility are most

commonly used by malware samples.

Table 3: Security Evaluation on Malware Samples

Family

# Secure Apps # Insecure Apps

# Malware

ϕ = FALSE ϕ = T RU E

FakeInstaller 50 0 50

GinMaster 50 0 50

Opfake 22 28 50

Plankton 31 19 50

Total 153 47 200

7 DISCUSSION AND FUTURE

EXTENSIONS

The evaluation of the proposed method consider a re-

duced number of legitimate and malware applicati-

ons. Thus, the ﬁrst improvement is related to the eva-

luation of an extended dataset. For example, as future

work a grater number of samples have to be consi-

dered in the evaluation, including also other malware

families.

Another limitation of this work is related to its abi-

lity to handle only Shared Preference vulnerability.

Other kinds of vulnerability can be detected in the

future, e.g. intent based ICC communications. Usu-

ally, Intents are the most common components used to

inter-app communication. For example, a future work

can investigate whether an intent is vulnerable, with

particular attention on the implicit intent.

Furthermore, it is also interesting to investigate

whether these kinds of vulnerability generate collu-

sion attacks. For example, for the Shared Preferences

vulnerability, a combiner can be built. This combiner

aim to link two applications, the ﬁrst application that

is able to put something in a Shared Preferences and

the second one able to get to the resource. Afterwards,

some logic formulae can be used in order to verify if

information ﬂow has occurred.

8 CONCLUSIONS

Android is the most widespread mobile operating sy-

stem. Malware writers threaten it using new types of

attacks. One of the last new threats is the collusion

attack. During this kind of attack the malicious be-

haviour is performed through multiple applications:

two or more applications collaborate in order to ac-

complish malicious aims. In collusion attacks the ap-

plications intentionally put in view some private data.

This paper aims to investigate whether legitimate and

malware applications show public user data. This is a

kind of vulnerability detected by the methodology de-

signed in this work using a dataset composed by 200

legitimate applications downloaded from the Android

ofﬁcial store and 200 malware samples belonging to

the Drebin dataset. The results show that some legi-

timate applications intentionally expose public data.

Instead, Opfake and Plankton malware samples lar-

gely expose the public Shared Preferences vulnerabi-

lity.

ACKNOWLEDGEMENTS

This work has been partially supported by H2020

EU-funded projects NeCS and C3ISP and EIT-Digital

Project HII.

REFERENCES

Anastasi, G., Bartoli, A., De Francesco, N., and Santone, A.

(2001). Efﬁcient veriﬁcation of a multicast protocol

for mobile computing. Computer Journal, 44(1):21–

30. cited By 12.

Arp, D., Spreitzenbarth, M., Huebner, M., Gascon, H., and

Rieck, K. (2014). Drebin: Efﬁcient and explainable

detection of android malware in your pocket. In Pro-

ceedings of 21th Annual Network and Distributed Sy-

stem Security Symposium (NDSS).

Asavoae, I. M., Blasco, J., Chen, T. M., Kalutarage, H. K.,

Muttik, I., Nguyen, H. N., Roggenbach, M., and

Shaikh, S. A. (2016). Towards automated android app

collusion detection. arXiv preprint arXiv:1603.02308.

Bagheri, H., Sadeghi, A., Garcia, J., and Malek, S. (2015).

Covert: Compositional analysis of android inter-app

permission leakage. IEEE Transactions on Software

Engineering, 41:866–886.

Battista, P., Mercaldo, F., Nardone, V., Santone, A., and

Visaggio, C. A. (2016). Identiﬁcation of android mal-

ware families with model checking. In Proceedings of

the 2nd International Conference on Information Sys-

tems Security and Privacy - Volume 1: ICISSP,, pages

542–547.

Bhandari, S., Herbreteau, F., Laxmi, V., Zemmari, A.,

Roop, P. S., and Gaur, M. S. (2017). Poster: Detecting

inter-app information leakage paths. In Proceedings of

the 2017 ACM on Asia Conference on Computer and

Communications Security, pages 908–910. ACM.

Bruns, G. (1997). Distributed Systems Analysis with CCS.

Prentice-Hall.

Cleaveland, R. and Sims, S. (1996). The ncsu concurrency

workbench. In CAV. Springer.

De Francesco, N., Santone, A., and Tesei, L. (2003). Ab-

stract interpretation and model checking for checking

secure information ﬂow in concurrent systems. Fun-

damenta Informaticae, 54(2-3):195–211. cited By 12.

De Ruvo, G., Nardone, V., Santone, A., Ceccarelli, M.,

and Cerulo, L. (2015). Infer gene regulatory net-

works from time series data with probabilistic model

checking. pages 26–32. cited By 7.

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 sy-

stem for realtime privacy monitoring on smartphones.

ACM Transactions on Computer Systems (TOCS),

32(2):5.

Filiol, E. i irolla, p.(2015).(in) security of mobile banking...

and of other mobile apps*.

Li, L., Bartel, A., Bissyand

e, T. F., Klein, J., and Le Traon,

Y. (2015a). Apkcombiner: Combining multiple an-

droid apps to support inter-app analysis. In IFIP Inter-

national Information Security Conference, pages 513–

527. Springer.

Li, L., Bartel, A., Bissyand

e, T. F., Klein, J., Le Traon,

Y., Arzt, S., Rasthofer, S., Bodden, E., Octeau, D.,

and McDaniel, P. (2015b). Iccta: Detecting inter-

component privacy leaks in android apps. In Procee-

dings of the 37th International Conference on Soft-

ware Engineering - Volume 1, ICSE ’15, pages 280–

291, Piscataway, NJ, USA. IEEE Press.

Li, L., Bartel, A., Klein, J., and Le Traon, Y. (2014). Auto-

matically exploiting potential component leaks in an-

droid applications. In 2014 IEEE 13th International

Conference on Trust, Security and Privacy in Compu-

ting and Communications, pages 388–397. IEEE.

Liu, F., Cai, H., Wang, G., Yao, D. D., Elish, K. O., and

Ryder, B. G. (2017). Mr-droid: A scalable and priori-

tized analysis of inter-app communication risks. Proc.

of MoST.

Mercaldo, F., Nardone, V., Santone, A., and Visaggio, C. A.

(2016). Download malware? no, thanks: How formal

methods can block update attacks. In Proceedings of

the 4th FME Workshop on Formal Methods in Soft-

ware Engineering, FormaliSE ’16, pages 22–28, New

York, NY, USA. ACM.

Milner, R. (1989). Communication and concurrency. PHI

Series in computer science. Prentice Hall.

Santone, A. (2011). Clone detection through process alge-

bras and java bytecode. pages 73–74. cited By 10.

Spreitzenbarth, M., Echtler, F., Schreck, T., Freling, F. C.,

and Hoffmann, J. (2013). Mobilesandbox: Looking

deeper into android applications. In 28th International

ACM Symposium on Applied Computing (SAC).

Stirling, C. (1989). An introduction to modal and temporal

logics for ccs. In Concurrency: Theory, Language,

And Architecture, pages 2–20.

Wei, F., Roy, S., Ou, X., et al. (2014). Amandroid: A pre-

cise and general inter-component data ﬂow analysis

framework for security vetting of android apps. In

Proceedings of the 2014 ACM SIGSAC Conference

on Computer and Communications Security, pages

1329–1341. ACM.

Xu, K., Li, Y., and Deng, R. H. (2016). Iccdetec-

tor: Icc-based malware detection on android. IEEE

Transactions on Information Forensics and Security,

11(6):1252–1264.