1

LEILA: formaL tool for idEntifying mobIlemaLicious behAviour

Gerardo Canfora, Fabio Martinelli, Francesco Mercaldo, Vittoria Nardone, Antonella Santone, Corrado Aaron Visaggio

Abstract—With the increasing diffusion of mobile technologies, nowadays mobile devices represent an irreplaceable tool to perform severaloperations, from posting a status on a social network to transfer money between bank accounts. As a consequence, mobile devices store a hugeamount of private and sensitive information and this is the reason why attackers are developing very sophisticated techniques to extort data andmoney from our devices. This paper presents the design and the implementation of LEILA (formaL tool for idEntifying mobIle maLicious behAviour), atool targeted at Android malware families detection. LEILA is based on a novel approach that exploits model checking to analyse and verify the JavaBytecode that is produced when the source code is compiled. After a thorough description of the method used for Android malware families detection,we report the experiments we have conducted using LEILA. The experiments demonstrated that the tool is effective in detecting malicious behaviourand, especially, in localizing the payload within the code: we evaluated real-world malware belonging to several widespread families obtaining anaccuracy ranging between 0.97 and 1.

Index Terms—Security, malware, model checking, testing, Android

F

1 INTRODUCTION

In Q3 2017, the researchers of Kaspersky Lab detected 1,598,196mobile malicious installation packages, 1.2 times more than in theprevious quarter1. The mobile malware phenomenon is exponen-tially growing; as a matter of fact, GData experts report that theyidentify a new Android malware strain every 11 seconds2.

Security patches are released as soon as a vulnerability isfound, which make most of the existing malware obsolete. Then,malware writers search for new vulnerabilities and release newmalware, or variants of old malware, to get around the newprotections. New patches are released to fix the newly discoveredvulnerabilities and the cycle starts over again. McAfee securityexperts define this process as “vicious cycle” 3.

Variants of existing malware are usually generated by addingnew behaviours or merging together parts of existing malwarecodes, since writing effective malware from scratch is costly andantimalware barely detects unknown variants of known malware[1], [2]. For this reason, malware analysts use to group malwarevariants in families: the codes belonging to the same family sharesignificant parts of a malicious behaviour.

This scenario is made more critical by enterprising malwareauthors who often package their malware as an exploit kit forsale to other cybercriminals, as for example the AndroRAT

• G. Canfora, V. Nardone and C.A. Visaggio were with the Department ofEngineering, University of Sannio, Benevento, ItalyE-mail: {canfora, vnardone, visaggio}@unisannio.it

• F. Martinelli and F. Mercaldo were with the Institute for Informatics andTelematics, National Research Council of Italy (CNR), Pisa, ItalyE-mail: {fabio.martinelli, francesco.mercaldo}@iit.cnr.it

• A. Santone was with the Department of Bioscience and Territory, Univer-sity of Molise, Pesche (IS), ItalyE-mail: antonella.santone@unimol.it

1. https://securelist.com/it-threat-evolution-q3-2017-statistics/83131/2. http://pliki.gdata.pl/partner/materialy prasowe/2016/02/MMWR EN

Q42015.pdf3. http://www.mcafee.com/us/resources/reports/

rp-mobile-threat-report-2016.pdf

APK Binder tool, that allows a remote attacker to control theinfected device by using a user friendly control panel [3]. A weakpoint of the current antivirus solutions is their main operatingmechanism: they mostly apply a signature-based detection. Thisapproach requires the vendor’s awareness of the malware, itidentifies the signature and sends out updates regularly. Signatureshave traditionally been in the form of fixed strings and regularexpressions, for this reason minimal variations are sufficient toalter the signature [2], [4], [5], [6], making the malware no longeridentifiable.

The current literature proposes several detection methods thatdo not rely on signatures; for instance, methods able to detect appsthat exhibit malicious behaviours based on required resources,such as permissions, suspicious API calls and system calls re-trieved using both static and dynamic analysis. For example,CrowDroid [7] collects system calls traces, while DroidAPIMiner[8] statically mines API in order to catch malware behaviours inmobile environment.

However, in order to bypass detection, malware writers aredeveloping more aggressive paradigms of attacks. A trend in thisarea is represented by splitting the payload in several methods [9];current antimalware, that tends to search harmful actions withinmethods separately taken, fails in this case. Considering that theAndroid operating system is event-based, the several pieces com-posing the split payload do not require to be invoked by a chainof methods where, after an initial trigger, one calls the followingone till the completion of the payload execution. On the contrary,each method of the payload needs only an external event to betriggered, but different triggers may be used for different methods:it is only needed that those triggers be somehow synchronizedfor performing correctly and completely the harmful action. Forinstance, it may happen that the malicious payload, able to sendsensitive information to a Command and Control (C&C) server,is split in two different actions: the first one gathers the sensitiveinformation, while the second one sends the information over thenetwork. The two methods are not related by a static point ofview, the call-graph analysis does not find a link between thetwo methods, but at runtime they are executed in a sequence. It

2

may happen that the first harmful action is invoked when the userboots the device (i.e., when the BOOT COMPLETED event islaunched), while the second one when the user receives a call: thismechanism makes the detection more difficult, considering thatthe full harmful action consists of the composition of differentmethods, stored in different classes and different packages that donot require to be called statically.

Inter-procedural analysis has been already explored by re-searchers in order to track the flow of privacy sensitive data byidentifying all the dependent variables and statements [10], [11],[12]. LEILA, with respect to existing inter-procedural analysistechniques, is also able to identify other common widespread high-level malicious behaviors, like, for example, ransomware encryp-tion or an attack perpetrated exploiting update mechanisms. As amatter of fact, the typical structure of Android apps offers manyopportunities for malware writers: in Android, an app consists ofa collection of several components, each in charge of some high-level functionality. LEILA overcomes the existing techniques, asit identifies the high-level malicious behaviors even if they are notimplemented in methods that are referenced among each others:this is the reason why we present LEILA as a tool able to localizethe malicious payload even if it is split cross different unrelatedmethods. A fragmented payload which is scattered over differentmethods without a reference among them cannot be detectable byInter-component communication (ICC).

In addition, malware writers generally use obfuscation tech-niques [13] aiming at changing the signature of the code, prevent-ing a virus scanner detecting the obfuscated virus with searchstrings: malware writers employ these techniques in order tomaximize the window of opportunity that elapses between therelease of a new threat and the generation of the signature suitableto its recognition.

In this landscape, the pernicious use of communication dislo-cated in different points of an app (for instance, the method M1 ofC1 class retrieves sensitive information that M2 method providedby C2 class will send to a drop server by using network resources)allows to successfully perform a large number of harmful actions.

As resulted by an extensive analysis on data exfiltration doneby Android malware [12], one of the main and common goalsof malware for mobile devices is to steal sensitive information,by sending it to a drop server or a remote controller. This kindof data are useful to cyber-criminals for many reasons: identitytheft, scams, phishing, harassment, espionage, sensitive informa-tion gathering. It is clear that the practice of splitting maliciousbehaviors into several small, and apparently not harmful, actionsimplemented in different parts of the app is a very appealingmechanism for malware writers in order to elude the many detec-tion mechanisms adopted by antimalware. An example of malwarepresenting split payload across parts that are not referenced amongeach others, but implement a cooperation mechanism, is shown inFigs. 1 and 2.

Fig. 1: The snippet shows the code that looks for the antimalwarepackages contained in the encrypted string at rows 3 and 4.

Fig. 2: The snippet shows the code that dynamically loads an externalexecutable resource.

The two code snippets are extracted by two classes (the“Waste” and the “Doctype” classes) of the same app belongingto the BaseBridge malware family: the first one (in Fig. 1) islooking for the execution of the following antimalware pack-ages: “com.qihoo360.mobilesafe”, “com.tencent.qqpimsecure”and “com.lbe.security” (the package names are stored in theencrypted string at rows 3 and 4): whether anyone of them isdetected, the malware will try to stop the corresponding process(of the antimalware). The second snippet (in Fig. 2) tries todownload the malicious payload, possibly with the antimalwarenot enabled. As a matter of fact, the dynamic loading can beconsidered a critical operation by most antimalware. The malwarewriters often do their best to disable the antimalware before themalicious update is downloaded.

We propose a behavioural based method for detecting Androidmalware families. More precisely, we define a model-checking-based method able to identify malicious actions and localize thepayload, regardless of whether they are implemented or not insame method or class of the application. Model checking [14]is an effective technique to automatically verify the correctnessof a system with respect to a desired behaviour, by checkingwhether a mathematical model of the system satisfies a formalspecification of such behavior, expressed using a temporal logic. Inthis paper we exploit the capabilities of model checking to detectAndroid malware. In particular, we use the Milner’s Calculus ofCommunicating Systems (CCS) [15]. CCS is one of the mostwell known process algebras and it is largely used for modelingcomplex systems. We specify each Android component in CCSbut we do not check each component separately. As explainedabove, analyzing methods separately is not enough to detect somecharacteristics of malware. For this reason, in this paper weperform an inter-methods analysis of apps.

In summary, the original contributions of the paper are:• the implementation of LEILA, a tool exploiting the proposed

method;• a set of rules for specifying many malicious behaviors char-

acterizing different kinds of malware families spread withinfamous malware campaigns;

• the evaluation of the effectiveness of our method throughthe application of LEILA to widespread real-world Androidmalware families. Our experimentation includes a datasetcontaining malware families released from 2011 to 2016.The samples of malware cover a huge spectrum of maliciouspayloads, from the ransomware encryption abilities to thenewest Android root exploits exhibited by the HummingBadfamily;

• the localization of fragmented payloads, as well as the local-ization of malicious payloads placed in one only method or

3

referenced methods;• the use of the model checking technique for Android apps

to identify malware families with the management of themethod calls, which has never been investigated, to the bestof the authors’ knowledge;

• the automatic dissection of a mobile app: the events able totrigger the malicious behavior can be caught and this is thereason why LEILA can be also used as a sanitizer tool, bydisarming the payload;

• the management of multi-threading in Android applicationswith a solution to tackle the state explosion problem arisingby the interleaving of the threads’ executions.

Besides the above novelties, other distinctive and relevantstrengths of our method are:• the detection of malware through the analysis of the Java

Bytecode instead of the source code, which is an advantagebecause source code could not be available or obtained byreverse engineering (due to obfuscation, for instance);

• the identification of malware families, which can help whendissecting a malware in order to make the picture about thepossible behavior and features of the malware;

• a behaviour-based detection as an approach to mitigate theeffect of code obfuscation techniques.

The reminder of the paper is organized as follows: Section 2reports the preliminaries on formal methods, Section 3 introducesthe method, Section 4 illustrates the results of the experiment,Section 5 discusses the distinctive features and the limitations ofour method. Section 6 thoroughly analyses related work. Finally,conclusions and future works are given in Section 7.

2 PRELIMINARIES ON FORMAL METHODS

Formal methods are mathematically based languages, techniques,and tools for specifying and verifying complex systems. To applyformal methods, we need:• a precise notation for defining systems;• a precise notation for defining properties.We examine in details these two notions in the following two

subsections.

2.1 A precise notation for defining systems

Specification is the process of describing a system. We assume thatthe system behaviour is represented as an automaton. It basicallyconsists of a set of nodes together with a set of labelled edgesbetween these nodes. A node represents a system state, whilea labelled edge represents a transition from one system state tothe next. That is, if the automaton contains an edge s a−→s′,then the system can evolve from state s into state s′ by theexecution of action a. One state is selected to be the root state,i.e., the initial state of the automaton. However, for the purposeof mathematical reasoning, it is often convenient to represent theautomaton algebraically in the form of processes. For this aim,we use Milner’s Calculus of Communicating Systems (CCS) [15].CCS is one of the most well known process algebras and it islargely used for modeling complex systems. Readers unfamiliarwith CCS are referred to [15] for further details. CCS containsbasic operators to build finite processes, communication operatorsto express concurrency, and some notion of recursion to captureinfinite behaviour. The syntax of processes is the following:

p ::= nil | α.p | p+ p | p|p | p\L | p[ f ] | x

where α ranges over a finite set of actions A = {τ,a,a,b,b, ...}.Input actions are labelled with “non-barred” names, i.e., a, whileoutput actions are “barred”, i.e., a. The action τ ∈ A is calledinternal action. The set L ranges over sets of visible actions (A−{τ}), f ranges over functions from actions to actions, while xranges over a set of constant names: each constant x is defined bya constant definition x def

= p.We give the semantics for CCS by induction over the structure

of processes:• the process nil can perform no actions;• the process α.p can perform the action α and thereby become

the process p;• the process p+q can behave either as p or as q;• the operator | expresses parallel composition: if the process

p can perform α and become p′, then p|q can perform α

and become p′|q, and similarly for q. Furthermore, if p canperform a visible action l and become p′, and q can performl and become q′, then p|q can perform τ and become p′|q′;

• the operator \ expresses the restriction of actions. If p canperform α and become p′, then p\L can perform α to becomep′\L only if α,α 6∈ L;

• the operator [ f ] expresses the relabeling of actions. If p canperform α and become p′, then p[ f ] can perform f (α) andbecome p′[ f ];

• each relabelling function f has the property that f (τ) = τ;• a constant x behaves as p if x def

= p.

A (labelled) transition system is a quadruple T =(S,A ,−→,s),where S is a set of states, A is a set of transition labels (actions),s ∈ S is the initial state, and −→ ⊆ S×A × S is the transitionrelation. If (s,α,s′) ∈ −→, we write s α−→s′. If δ ∈ A∗ and δ =

α1 . . .αn,n≥ 1, we write s δ−→s′ to mean s α1−→·· · αn−→s′. Moreovers λ−→s, where λ is the empty sequence. Given s ∈ S, with R (p) ={s′ | s δ−→s′} we denote the set of the states reachable from sby −→. Given a CCS process p, the standard transition systemfor p S(p) = (R (p),A ,−→, p). Note that, with abuse of notation,we use −→ for denoting both the operational semantics and thetransition relation among the states of the transition system.

The operational semantics of a process p is a labelled transitionsystem, i.e., an automaton whose states correspond to processes(the initial state corresponds to p) and whose transitions arelabelled by actions in A (see Table 1). This automaton is calledstandard transition system of p and denoted by S(p).

2.2 A precise notation for defining properties

This need can be solved using a temporal logic. Temporal logicspresent constructs allowing to state in a formal way that, forinstance, all scenarios will respect some property at every step,or that some particular event will eventually happen, and so on.The most noticeable examples are:• safety properties, which state that an undesirable situation

will never arise;• liveness properties, which state that some actions will always

be followed by some reactions.A model checker then accepts two inputs, a system described, forexample, in process-algebraic notations and a temporal formula,and returns “true” if the system satisfies the formula and “false”otherwise. In this paper we use the logic selective mu-calculus[16]. It was defined with the goal of reducing the number of statesof the transition systems in such a way that the reduction is driven

4

TABLE 1: Standard operational semantics of CCS

Actα.p α−→ p

Sump α−→ p′

p+q α−→ p′(and symmetric)

Relp α−→ p′

p[ f ]f (α)−→ p′[ f ]

Parp α−→ p′

p|q α−→ p′|q(and symmetric)

Conp α−→ p′

x α−→ p′x def= p Com

p l−→ p′, q l−→q′

p|q τ−→ p′|q′

Resp α−→ p′

p\L α−→ p′\Lα,α 6∈ L

by the formulae to be checked, and in particular by the syntacticstructure of the formulae. The selective mu-calculus is a variantof the mu-calculus [17], and differs from it in the definition ofthe modal operators. The syntax of the selective mu-calculus isthe following, where K and R range over sets of actions, while Zranges over a set of variables:

ϕ ::= tt | ff | Z | ϕ∨ϕ | ϕ∧ϕ | [K]R ϕ | 〈K〉R ϕ |νZ.ϕ | µZ.ϕ

The satisfaction of a formula ϕ by a state s of a transition systemis defined as follows:• each state satisfies tt and no state satisfies ff;• a state satisfies ϕ1∨ϕ2 (ϕ1∧ϕ2) if it satisfies ϕ1 or (and) ϕ2;• [K]R ϕ and 〈K〉R ϕ are the selective modal operators. They

require that the formula ϕ is satisfied after the execution of anaction of K, provided that it is not preceded by any action inK∪R. More precisely: [K]R ϕ is satisfied by a state which, forevery performance of a sequence of actions not belonging toR∪K, followed by an action in K, evolves in a state obeyingϕ. 〈K〉R ϕ is satisfied by a state which can evolve to a stateobeying ϕ by performing a sequence of actions not belongingto R∪K followed by an action in K.

The precise definition of the satisfaction of a closed formula ϕ

by a state is given in Table 2.As in standard mu-calculus, a fixed point formula has the form

µZ.ϕ (νZ.ϕ) where µZ (νZ) binds free occurrences of Z in ϕ. Anoccurrence of Z is free if it is not within the scope of a binder µZ(νZ). A formula is closed if it contains no free variables. µZ.ϕ isthe least fix-point of the recursive equation Z = ϕ, while νZ.ϕ isthe greatest one. To give an intuition of their meaning, considerthe formulae ϕ = µZ.(ψ ∨ 〈a〉 /0 Z) and ϕ′ = νZ.(ψ ∧ [a] /0 Z). Atransition system satisfies ϕ if it can evolve to a state satisfyingψ after a finite number of occurrences of action a (ignoring allother actions), while it satisfies ϕ′ if it satisfies ψ along any pathcontaining a (ignoring all other actions).

A transition system T satisfies a formula ϕ, written T |= ϕ, if andonly if q |= ϕ, where q is the initial state of T . A CCS process psatisfies ϕ if S(p) |= ϕ.

The selective mu-calculus is equivalent to the mu-calculus. In factit is easy to see that the standard mu-calculus modal operators[K]ϕ and 〈K〉ϕ can be defined by means of the selective operatorssubscribed by the whole set of actions A :

[K]ϕ = [K]A ϕ and 〈K〉ϕ = 〈K〉A ϕ

On the other hand the selective operators can be expressed instandard mu-calculus as follows:

〈K〉R ϕdef= µZ.〈K〉ϕ∨〈A− (K∪R)〉Z

[K]R ϕdef= νZ.[K]ϕ∧ [A− (K∪R)]Z

In the sequel we will use the following abbreviations (where Kranges over sets of actions and A is the set of all actions):

[α1, . . . ,αn]Rϕdef= [{α1, . . . ,αn}]Rϕ

[−]Rϕdef= [A ]Rϕ

[−K]Rϕdef= [A−K]Rϕ

This implies that to check selective mu-calculus formulae wecan use all formal verification environments which accept mu-calculus as property specification language.

Example 2.1. We give some examples of selective mu-calculusformulae to explain the use of the selective operators.

ψ1 = [a]{b}ff: “it is not possible to perform an action a if anaction b has not been previously performed”.

ψ2 = 〈a〉 /0tt: “it is possible to perform an action a preceded byany action”.

ψ3 = νZ.[a] /0(Z∧ [a]{b,c}ff): “it always holds that, after an actiona has occurred, a successive a cannot occur before either anaction b or an action c has occurred”.

a

c

bS1

c

a

b

ac S2

ba a

abS3

Fig. 3: Three transition systems

Let us consider the transition systems in Fig. 3. It holds that:

S1 6|= ψ1 S2 |= ψ1 S3 6|= ψ1

S1 |= ψ2 S2 |= ψ2 S3 |= ψ2

S1 |= ψ3 S2 6|= ψ3 S3 6|= ψ3

5

TABLE 2: Satisfaction of a closed formula by a state

p 6|= ff

p |= tt

p |= ϕ∧ψ iff p |= ϕ and p |= ψ

p |= ϕ∨ψ iff p |= ϕ or p |= ψ

p |= [K]R ϕ iff ∀p′.∀α ∈ K.p α=⇒K∪R p′ implies p′ |= ϕ

p |= 〈K〉R ϕ iff ∃p′.∃α ∈ K.p α=⇒K∪R p′ and p′ |= ϕ

p |= νZ.ϕ iff p |= νZn.ϕ for all n

p |= µZ.ϕ iff p |= µZn.ϕ for some n

where:• for each n, νZn.ϕ and µZn.ϕ are defined as:

νZ0.ϕ = tt µZ0.ϕ = ff

νZn+1.ϕ = ϕ[νZn.ϕ/Z] µZn+1.ϕ = ϕ[µZn.ϕ/Z]

where the notation ϕ[ψ/Z] indicates the substitution of ψ for every free occurrence of the variable Z in ϕ.• p α

=⇒I q iff p δα−→q, where δ ∈ (A− I)∗ and I ⊆ A .

One of the most popular environments for verifying concurrentsystems is the CAAL (Concurrency Workbench, Aalborg Edition)[18], which supports several different specification languages,among which CCS. In the CAAL the verification of temporal logicformulae is based on model checking [19]. In this paper we useCAAL as formal verification environment. It is worth noting thatCAAL represents output actions as ′a instead of a. In this paperwe use this notation.

3 THE METHOD

The method we propose consists of three main steps:1) the creation of a formal model;2) the definition of the temporal logic formulae that describe the

characterizing behaviors of Android malware families;3) the verification of the formulae with a formal verification

environment.

Step 1: Creation of a formal model

The first step aims at generating a formal model by parsing theJava Bytecode of the app to be analyzed; it is represented inFig. 4 (Box 1). More precisely, the Bytecode of the target appthat resides in a class folder or in JAR files is fed to a customparser, based on the Apache Commons Bytecode EngineeringLibrary (BCEL)4. The .class files of the parsed Java Bytecodeare successively translated into formal models. Since we usethe Calculus of Communicating Systems (CCS) [15], we specifya Java Bytecode-to-CCS transform operator T . The functionT directly applies to the Java Bytecode and translates it intoCCS process specifications. The function T is defined for eachinstruction of the Java Bytecode. We assume that a Java Bytecodeprogram P is a sequence c of instructions, numbered starting fromthe address 0; ∀i ∈ {0, . . . , ]c}, and c[i] is the instruction at theaddress i, where ]c denotes the length of c. All the Java Bytecodeinstructions have been translated in CCS, i.e., we associate a new

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

CCS process to each Java Bytecode instruction. This translationhas to be performed only one time for each app and it has beencompletely automated. A preliminary function T has been definedin [20], [21]. However, the CCS generated model was very simple,since it did not consider many features, such as the try-catchconstruct and method invocations. Thus, all the methods wereanalyzed separately. It is worth noting that analyzing methodsseparately is not enough to detect malware: it is needed to performan inter-methods analysis of the app. In fact, an Android appincludes multiple components, i.e., activities, services, broadcastreceivers, and content providers. ICC is performed using anintent, which is a messaging object that contains the destinationcomponent’s address or action string, and possibly data. Whileregular Java programs have a single entry point, Android apps canhave multiple entry points.

In the light of all above, in this paper we enrich our modeleliminating the previous limitations [20]. For clarity’s sake, thetranslation of some Java Bytecode instructions are provided.

Instruction: c[i] = goto j

T (i) = xidef= gotoj.x j

The instruction c[i] = goto j is translated into a CCS processxi that performs the action gotoj and then jumps to theinstruction j, corresponding to the CCS process x j.

Instruction: c[i] = tstore z

T (i) = xidef= store.xi+1

Each tstorez instruction is translated, regardless of the typet and of the name of the variable z, as store followed by theconstant process xi+1 representing the CCS translation of thesuccessive instruction.

Instruction: c[i] = if cond j

T (i) = xidef= if condff.xi+1 +if condtt.x j

6

Fig. 4: The Workflow of the proposed method

Conditional jumps are instead specified as non-deterministicchoices. In this case we define the CCS constant xi correspondingto the instruction i. The true (resp. false) condition is representedby the CCS action if condtt (resp. if condff), while

cond ∈ {eq, ne, icmeq, icmpne, ...}.

Thus, if the condition is true, the CCS process xi performs theaction if condtt and the execution branches to the process x j

corresponding to the process at the address j. If the condition isfalse, the execution continues at the successive instruction at theaddress i+1 (process xi+1).

Instruction: c[i] = athrow

T (i) = xidef= athrow.nil

The instruction athrow throws an error or exception and thisis represented by the CCS process xi which terminates afterperforming the action athrow.

Instruction: c[i] = invoke type MethodNamei

T (i) = xidef= ′callMethodNamei.returnMethodName.xi+1

Each invoke type instruction, where

type ∈ {dynamic,interface,special,static,virtual}

is represented by the CCS process xi which calls the methodMethodNamei, performing the action ′callMethodNamei. Thecontrol to the caller process is returned through the actionreturnMethodNamei and the execution continues at the succes-sive instruction at address i+1 (process xi+1).Note that, in order to simplify the notation, we have reported onlythe name MethodNamei in the CCS translation of a method’sinvocation, neglecting the arguments, their types and all the classpath. Let’s see, now, the translation of the method definition.

Method definition:

visibility type MethodNamei;

Code : mwhere

• m is a a sequence of method’s instructions , numbered startingfrom address 0; m[ j] is the instruction at address j, ∀ j ∈{0, . . . , ]m}.

• visibility ∈ {public,protected,private};• type ∈ {Primitive data type and any object type};

For each method definition we specify a CCS process

7

Fig. 5: Example of Method Call

MethodNamei as follows:

MethodNameidef= callMethodNamei.MethodNamei0

where

T (0) = MethodNamei0def= p0

· · ·T (m−1) = MethodNameim−1

def= pm−1

T (m) = MethodNameimdef= ′returnMethodNamei.MethodNamei

where 0 is the first instruction of the MethodNamei. Every methodcorresponds to a process waiting to be invoked through the actioncallMethodNamei. The action ′returnMethodNamei causesthe control being returned to the method caller. The instructions ofthe body, starting from 0, are translated in CCS processes throughT . Then, the process goes back to the starting action so that it canbe invoked again.

As already explained for the invocation of a method, alsoin the method definition the CCS translation shows only thename MethodNamei but does not show the arguments, forreadability and simplicity. An example of the complete definitionof a method is given in Fig. 5, where the definition methods ofP1 and M1 are shown. In addition to the name of the method,the class Path, the Return Type and the list of arguments arespecified. In the example, P1 calls M1 through the action’callclassPath_returnType_methodNameM1_argListpresent in the CCS process P3, while the corresponding non-barredaction callclassPath_returnType_methodNameM1_argListis in the CCS process M1. These actions allow thecommunication between the two processes. The actionsreturnclassPath_returnType_methodNameM1_argListin the CCS process P3 and the action’returnclassPath_returnType_methodNameM1_argLisin the CCS process Mm cause the control being returned to themethod caller.

Finally, the explicit inter-component communication is cod-ified in CSS as methods invocation while multiple entry pointsare codified in CSS using the non-deterministic choice operator:in this way they are always active and analyzed by the modelchecker.

Exception Table:

Exception table:from to target type

i j k t

Independently of the type t, all the CCS processes xl , withi ≤ l < j are modified adding the process xk as a choice of thebody of the process xl , i.e.,

xldef= p+ xk

where T (l) = xldef= p.

If an exception occurs during the execution of the instructionsbetween indexes i and j (corresponding to the processes xl , i ≤l < j), the control is transferred to the Java Virtual Machine codeat index k, which is the CCS process xk implementing the blockstarting from k.

The final CCS process describing a Java Bytecode program isobtained through the proposed method as a parallel of the Startprocess and all the MethodNamei processes, where i ∈ [1..n] if nis the number of the methods in the analyzed program, restrictedto all the actions used for communicating among such processes,i.e., callMethodNamei and returnMethodNamei. Formally,

Final def=(MethodName1 | · · · |MethodNamen |Start)\S

where S = {callMethodNamei,returnMethodNamei}, ∀i ∈ [1..n]

The Start process is so defined:

Start def= ′callMethodk1 .returnMethodk1 .nil

| · · · |′callMethodkm .returnMethodkm .nil

Start is the parallel composition of CCS processes like′callMethodi.returnMethodi.nil, with i ∈ {k1, . . . ,km}. Each ofthese processes has the only aim of starting the multiple entrypoints Methodi. Unlike Java programs, Android applications donot have a main method. In fact, they can contain multiplecomponents, each one characterized by its own life cycle: theinformation about the component that will be launched whenthe app is started is provided by the Manifest file. In addition,considering that Android operating system is event-based, from astatic point of view there are methods that are not referenced (andcalled) by other methods that are triggered when an event happens(for instance, when the user receives a phone call or an SMS). Ourmethod takes into account these intrinsic characteristics of themobile platform, as a matter of fact, we consider these methodsin the CCS Start process. This makes particularly hard the staticanalysis in Android environment, as it has multiple entry points theanalysis should start from. In order to consider all the possible appentry points, we need to introduce Start as parallel composition ofall the CCS processes.

8

An example

To give the reader the flavour of the transformation function T ,we consider a very simple code fragment that implements thetraditional “Hello World” example. This app is composed only oftwo classes; the first class, shown in Listing 1, calls the methodof the other one, shown in Listing 2. The only action performedis the visualisation of the string “Hello World” on the screen. TheJava Bytecode of the two Java classes is shown in Listings 3 and4. The resulting CCS processes are shown in Listings 5 and 6.For simplicity’s sake, we have used x = p instead of x def

= p in thedefinition of a CCS process. To better understand the example,we also report the Java code in Listings 1 and 2 , even if thetransformation function T operates only on the Java Bytecode.

The Listing 7 shows the Final CCS process of the correlationbetween the two classes. For the sake of clarity, we considerthe Start process containing only the Main method call. TheFinal process does not involve the ExampleClass and Hello classConstructors into its specification, as shown in Listings 3 and4 respectively. They are automatically generated during the JavaBytecode visualization, using the command javap (included withthe JDK). This clearly emerges in the Listings 1 and 2 whichcontain the Java source code of the two classes respectively. Sincethese two methods specify the default Java constructors that we donot want to model checking, the Final process does not includethem in its specification. Differently, the Final process will containthe CCS specification of a Java class constructor only if it isdeclared by the programmer.

Listing 8 and Listing 9 show an example of try-catch transla-tion. In particular, the Listing 8 shows the Java Bytecode of themethod containing a try-catch block, while the corresponding CCStranslation is reported in Listing 9.

Step 2: Definition of Android malware families’ behaviors astemporal logic formulae

The second step aims at recognizing the characterizing behaviorsof the Android malware families, expressed in temporal logic: anexample is shown in Fig. 4 (Box 2). Identifying a behavior meansverifying the algebraic specification describing the characteristicsof malware families on the CCS processes obtained with the firststep, which are a representation of the app’s code. Finally, CAAL

verifies the logic formulae on the CCS processes, after that they areautomatically mapped to labelled transition systems. Dependingon the malware family to detect, different properties have beenconsidered. For each family F , a selected set of samples hasbeen manually inspected for defining the selective mu-calculusformulae characterising the malware behaviour of the family F .For example, in Table 3 is shown an example of Opfake Formula.

The formula means that it is always possible to perform thissequence of actions:

newandroidcontentIntent invokegetBroadcast invokegetDefaultinvokesendTextMessage

In other words, the formula is able to catch those maliciousbehaviours:• newandroidcontentIntent: the Intent is a mechanism for per-

forming late runtime binding between the codes of differentapplications. They are mostly used for launching activities;

• invokegetBroadcast: this represents an invocation of the get-Broadcast method belonging to PendingIntent class available

in Android; it performs a broadcast. Releasing a PendingItentto another app, corresponds to granting the right to performthe operation specified as argument to another app with thesame right of the caller;

• invokegetDefault: the getDefault method, belonging to theLocale class, gets the current value of the geographical regionof the device; it is used to obtain user personal information;

• invokesendTextMessage: the method sendTextMessage, pro-vided by Android SMSManager class, sends a text basedSMS; this is an action recurring within malicious payloadwith information gathering abilities. As a matter of fact, thisrule is able to identify the malicious payload that gathersthe sensitive information and creates a text SMS with thisinformation to be sent to the attacker (i.e. the person thatcontrols the malware and managed the infection campaign).

Step 3: Application of a formal verification environment

Finally, as shown in Fig. 4 (Box 3), a formal verification envi-ronment, including a model checker, is invoked to recognise themalware families through model checking. This step checks whichalgebraic formuale are verified on which CCS model, i.e., whichmalware characteristics are found on which app. We use the CAAL

tool [18] as formal verification environment. When the result ofthe CAAL model checker is true, it means that the app belongingto that malware family (the verified algebraic formulae correspondto), false otherwise.

3.1 The LEILA implementation

The method introduced in the previous section has been imple-mented in a tool named LEILA. LEILA is a Java system. It iscomposed of four packages:

1) Preprocessing: The aim of this package is to extract theclass files of the Android application. In particular, it in-tegrates the dex2jar5 tool in order to convert the dex (i.e.,the Dalvik Executable) file into jar (i.e., Java Archive)file. Using the dex2jar tool, LEILA obtains the Androidapplication in a compressed format. To extract the classesfrom the jar file, LEILA uses the command: jar -xvfprovided by the Java Development Kit. The outputs of thispackage are the classes belonging to the the Android app;

2) Parsing_&_Translation: It is the core of the tool sinceit builds the CCS model. Starting from the output of thefirst package and using the Bytecode Engineering Library(Apache Commons BCEL), LEILA parses the class files.Afterwards, starting from the main activity of the applica-tion, LEILA analyzes all the methods and all the multipleentry points of an Android application generating the FinalCCS process, as explained above. Thus, LEILA considersall events able to trigger activities, services and any otherAndroid component. This is obtained by implementing thetransformation function T . The output of this package is theCCS model of the app;

3) Reduction: It implements the CCS model reduction. Thispackage takes as input two files: the CCS model and the tem-poral logic formulae that describe the malicious behaviors.Starting from the logic formulae, LEILA is able to reducethe formal model of the Android application. The readers can

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

9

1 p u b l i c c l a s s ExampleClass {2

3 p u b l i c s t a t i c vo id main ( S t r i n g [ ] a r g s ) {4 S t r i n g s = ” H e l l o World ” ;5 H e l l o . p r i n t H e l l o ( s ) ;6 }7

8 }

Listing 1: Example of Java Source Code (java class ExampleClass )

1 p u b l i c c l a s s H e l l o {2

3 p u b l i c s t a t i c vo id p r i n t H e l l o ( S t r i n g s t r ) {4 System . o u t . p r i n t l n ( s t r ) ;5 }6

7 }

Listing 2: Example of Java Source Code (java class Hello)

1 Compiled from ” ExampleClass . j a v a ”2 p u b l i c c l a s s ExampleClass {3 p u b l i c ExampleClass ( ) ;4 Code :5 0 : a l o a d 06 1 : i n v o k e s p e c i a l #8 / / Method j a v a / l a n g /

O b j e c t .”< i n i t >” : ( )V7 4 : r e t u r n8

9 p u b l i c s t a t i c vo id main ( j a v a . l a n g . S t r i n g [ ] ) ;10 Code :11 0 : l d c #16 / / S t r i n g H e l l o World12 2 : a s t o r e 113 3 : a l o a d 114 4 : i n v o k e s t a t i c #18 / / Method H e l l o .

p r i n t H e l l o : ( L java / l a n g / S t r i n g ; ) V15 7 : r e t u r n16 }

Listing 3: Java Bytecode Related to ExampleClass class (Listing 1)

1 Compiled from ” H e l l o . j a v a ”2 p u b l i c c l a s s H e l l o {3 p u b l i c H e l l o ( ) ;4 Code :5 0 : a l o a d 06 1 : i n v o k e s p e c i a l #8 / / Method j a v a / l a n g /

O b j e c t .”< i n i t >” : ( )V7 4 : r e t u r n8

9 p u b l i c s t a t i c vo id p r i n t H e l l o ( j a v a . l a n g . S t r i n g ) ;10 Code :11 0 : g e t s t a t i c #16 / / F i e l d j a v a / l a n g /

System . o u t : L java / i o / P r i n t S t r e a m ;12 3 : a l o a d 013 4 : i n v o k e v i r t u a l #22 / / Method j a v a / i o /

P r i n t S t r e a m . p r i n t l n : ( L java / l a n g / S t r i n g ; ) V14 7 : r e t u r n15 }

Listing 4: Java Bytecode Related to Hello class (Listing 2)

1 EXAMPLECLASS0 = c a l l P u b l i c v o i d i n i t . l o a d . EXAMPLECLASS12 EXAMPLECLASS1 = i n v o k e i n i t . EXAMPLECLASS43 EXAMPLECLASS4 = ’ r e t u r n p u b l i c v o i d i n i t . EXAMPLECLASS04

5

6 MAIN0 = c a l l M a i n . pushHel loWor ld . MAIN27 MAIN2 = s t o r e . MAIN38 MAIN3 = l o a d . MAIN49 MAIN4 = ’ c a l l P r i n t H e l l o . r e t u r n p r i n t H e l l o . MAIN7

10 MAIN7 = ’ r e t u r n m a i n . MAIN0

Listing 5: CCS Model Related to Listing 3

1 HELLO0 = c a l l P u b l i c v o i d i n i t . l o a d . HELLO12 HELLO1 = i n v o k e i n i t . HELLO43 HELLO4 = ’ r e t u r n p u b l i c v o i d i n i t . HELLO04

5 PRINTHELLO0 = c a l l P r i n t H e l l o . g e t s t a t i c . PRINTHELLO36 PRINTHELLO3 = l o a d . PRINTHELLO47 PRINTHELLO4 = i n v o k e p r i n t l n . PRINTHELLO78 PRINTHELLO7 = ’ r e t u r n p r i n t H e l l o . PRINTHELLO0

Listing 6: CCS Model Related to Listing 4

1 FINAL = ( START | PRINTHELLO0 ) \ { c a l l P r i n t H e l l o , r e t u r n p r i n t H e l l o }2 START = ’ c a l l M a i n . r e t u r m a i n . n i l

Listing 7: CCS Final process

find more details about this process in Section 5. The outputof this package is the reduced CCS model;

4) Verification: It realizes the formal verification of themodel. It verifies the model, i.e., the reduced CCS model,through the CAAL model checker, checking the tempo-ral logic formulae: this package invokes the CAAL modelchecker. The output of this package is the identification ofthe malware family, if any, along with with the payloadlocalization.

The process described above is detailed considering one An-droid application as input, but LEILA is able to work on a set ofapplications, too.

4 EVALUATION

The goal of this study is to investigate the suitability and thelimitations of the proposed method in recognizing the malwarefamilies targeting the Android operating system. The quality focus

concerns the effectiveness and the performances of the detectionperformed by LEILA. The perspective is that of researchersinterested in evaluating a method based on model checking thatassociates a malware to the family it belongs to and locates theactual payload in the code.

We evaluated the following capabilities of LEILA:

1) effectiveness of malware classification: the correctness inidentifying the malware family a sample belongs to;

2) resiliency against obfuscation: how the classification capa-bilities are affected by the obfuscation of malware; and

3) performances of detection: which is the workload requiredto the computational resources when running LEILA.

To estimate the LEILA effectiveness of malware classification,we compute the metrics of precision and recall, F-measure (Fm)and Accuracy (Acc), defined as follows:

PR =T P

T P+FP; RC =

T PT P+FN

;

10

1 Compiled from ” ExampleClass . j a v a ”2 p u b l i c c l a s s com . example . ExampleClass {3 p u b l i c com . example . ExampleClass ( ) ;4 Code :5 0 : a l o a d 06 1 : i n v o k e s p e c i a l #8 / / Method j a v a / l a n g /

O b j e c t .”< i n i t >” : ( )V7 4 : r e t u r n8

9 p u b l i c s t a t i c vo id main ( j a v a . l a n g . S t r i n g [ ] ) ;10 Code :11 0 : g e t s t a t i c #16 / / F i e l d j a v a / l a n g /

System . o u t : L java / i o / P r i n t S t r e a m ;12 3 : l d c #22 / / S t r i n g HELLO13 5 : i n v o k e v i r t u a l #24 / / Method j a v a / i o /

P r i n t S t r e a m . p r i n t l n : ( L java / l a n g / S t r i n g ; ) V14 8 : go to 2015 1 1 : a s t o r e 116 1 2 : g e t s t a t i c #16 / / F i e l d j a v a / l a n g /

System . o u t : L java / i o / P r i n t S t r e a m ;17 1 5 : l d c #30 / / S t r i n g EXCEPTION18 1 7 : i n v o k e v i r t u a l #24 / / Method j a v a / i o /

P r i n t S t r e a m . p r i n t l n : ( L java / l a n g / S t r i n g ; ) V19 2 0 : r e t u r n20 E x c e p t i o n t a b l e :21 from t o t a r g e t t y p e22 0 8 11 C l a s s j a v a / l a n g / E x c e p t i o n23 }

Listing 8: A Java Bytecode example of Try-catch

1 MAIN0 = c a l l M a i n . g e t s t a t i c . MAIN3 + MAIN112 MAIN3 = pushHELLO . MAIN5 + MAIN113 MAIN5 = i n v o k e p r i n t l n . MAIN8 + MAIN114 MAIN8 = go to . MAIN20 + MAIN115 MAIN11 = s t o r e . MAIN126 MAIN12 = g e t s t a t i c . MAIN157 MAIN15 = pushEXCEPTION . MAIN178 MAIN17 = i n v o k e p r i n t l n . MAIN209 MAIN20 = ’ r e t u r n m a i n . MAIN0

Listing 9: CCS Model of the Try-Catch

TABLE 3: An Example of the Opfake Formula

ϕ = νZ.〈newandroidcontentIntent〉 /0 〈invokegetBroadcast〉 /0 〈invokegetDe f ault〉 /0 〈invokesendTextMessage〉 /0 Z

Fm =2PR RCPR+RC

; Acc =T P+T N

T P+FN +FP+T N

where T P is the number of malware that are correctly associatedto the right family (True Positives), T N is the number of malwarecorrectly identified as not belonging to the family (True Nega-tives), FP is the number of malware that are incorrectly associatedto a family (False Positives), and FN is the number of malware thatare not recognized as belonging to their family (False Negatives).

4.1 Dataset

The samples examined in the experiment were gathered fromdifferent sources: (i) the Drebin project’s dataset [22], [23]: thatis a very well known collection of malware widely used bythe scientific community, which includes the most widespreadAndroid families, (ii) the HelDroid dataset [24] that contains freelyavailable Android ransomware, (iii) the ContagioMobile website6,that hosts a collection of Android malware and (iv) Google Play,the Android official market, in order to obtain the legitimate apps.

The considered malware dataset consists of families charac-terized by several installation methods: (i) standalone, apps thatintentionally include malicious functionalities; (ii) repackaging,known and common (goodware) apps that are first disassembled,then the malicious payload is added, and finally are re-assembledand distributed as a new version (of the original app); and (iii)update attack, apps that initially do not show harmful behaviors

6. http://contagiominidump.blogspot.com

and download an update containing the malicious payload, atruntime.

The malware dataset is also partitioned according to themalware family; each family contains samples which share severalcharacteristics: the payload installation, the kind of attack and theevents that trigger the malicious payload [25].

Table 4 shows the 6 malware families with the largest numberof apps in the malware dataset with the details of the installationtypes, the kinds of attack and the events which activate thepayload.

TABLE 4: Families in malware dataset with details of the installationmethod (standalone, repackaging, update), the kind of attack (trojan,botnet), the events that trigger the malicious payload, the discoverydate and a brief family description.

Family Installation Attack Activation date DescriptionOpfake r t main 2013 first Android polymorphic malwareGinMaster r t boot 2011 malicious service to root devicesFakeInstaller r t boot 2014 sends SMS messages to premium rate numbersPlankton u,s b main 2011 fetches and runs a remote jar fileRansomware u,s t,b main 2015 ability to lock the GUI and cypher SD filesHummingBad u,s t main 2016 persistent rootkit to generate fraudulent ad revenue

The malware belonging to Opfake, GinMaster, FakeInstallerand Plankton families were retrieved from the Drebin project[22], [23], while we obtained the Ransomware samples from acollection7 of freely available malware belonging to HelDroiddataset and appeared from December 2014 to June 2015. The

7. http://ransom.mobi/

11

HummingBad family was download by the ContagioMobile web-site8.

Here is a brief description of the 6 populous families in thedataset.

1) The Opfake samples make use of an algorithm that canchange shape over time to evade the detection. The Op-fake malware demands payment for the application con-tent through premium text messages. The Opfake maliciouspayload is triggered by the user i.e., by an UI event. Asa matter of fact, SMS messages to premium-rate numbersare sent when the wapxload.ru/opera/ web page is displayedon the infected device screen once the user opens it. Themalicious payload application does not read the content ofthe HTTP response but it is able to enables the JavaScriptfunctionality in the browser and registers a callback methodnamed onJsPrompt. This family represents an example ofpolymorphic malware [26] in Android environment: it iswritten with an algorithm that can change shape over timeto evade detection by signature based antimalware;

2) GinMaster family contains a malicious service with theability to root devices to escalate privileges, steal confidentialinformation and send the stolen data to a remote website,as well as install applications without user interaction. Itis also a trojan application (basically, the term “trojan”relates to an application that hides its true purpose9 i.e.,the concealment of the malicious functions behind harmlessones) and starts its malicious services as soon as it receivesa BOOT COMPLETED or USER PRESENT intent. Themalware can successfully avoid detection by mobile anti-virus software by using polymorphic techniques to hide mali-cious code, obfuscating class names for each infected object,and randomizing package names and self-signed certificatesfor applications (typically polymorphic malware attempts toevade detection by encrypting itself differently, and rewritingthe decrypting module accordingly. The second variant ofGinMaster is able to make use of the encryption as, but thedecrypting module is static);

3) the main aim of FakeInstaller samples is to send SMSmessages to premium rate numbers, without the consent ofthe user, passing itself off as the installer for a legitimateapplication. When a FakeInstaller sample is executed, itdisplays a service agreement: the user is forced to click an“Agree button”, which sends the premium SMS messages.There are also seen variants that send the messages before theuser of the infected device clicks this “Agree button” 10. Fur-thermore, FakeInstaller samples are server-side polymorphici.e., the server is able to provide different APK files for thesame URL request. For instance, when the user requests anapplication from the fake market provided by FakeInstaller,the server redirects the browser to another server able toprocess the request in order to send a customized APK whichhas an associated ID in the generated URL: the installationpackage sent to the user is associated with the IP address of

8. http://contagiominidump.blogspot.it/2016/07/hummingbad-android-fraudulent-ad.html

9. https://usa.kaspersky.com/resource-center/threats/trojans#.VvD3eOLhDtQ

10. https://securingtomorrow.mcafee.com/mcafee-labs/fakeinstaller-leads-the-attack-on-android-phones/

the infected device11;4) the Plankton payload is able to silently forward information

about the device to a drop server. It does not require rootprivileges and the payload is downloaded from a remotelocation. The malicious service checks the details of theinstalled application, including its security permissions, andit sends the details to a hard-coded HTTP server. The serverreplies with a URL that is used to download a JAR filethat contains the malicious payload [27]. The downloadedDex code launches a connection to the Command server andlistens for commands to execute (for instance, send detailslike IMEI, browser history, permissions granted) [25];

5) Ransomware is one of the newest threats in mobile envi-ronment: basically the samples belonging to this categoryhinder the access to the device or the data within the deviceuntil a ransom is paid. They employ different techniquesin order to lock the phone (i.e., to take control of the userinterface either locking the screen always on the same viewor encrypting all files of the sd-card) [28], [29]. Typicallythese samples masquerade as well-known applications, suchas Adobe Flash and a number of antimalware applications,and pretend to scan the device upon launch. After completingthe fake scan it locks the infected device [28]. The user isnot able to navigate away and if he/she tries to reboot, thefake FBI message will be the first thing the user sees whenthe device turns on. Furthermore, it demands several hundreddollars in a MoneyPakvoucher in order to release the infecteddevice [29];

6) the HummingBad family represents the most recent threatin the evaluated malware dataset: as a matter of fact, itwas discovered by Check Point analysts in February 201612.In July 2016, the same analysts discovered that this kindof malicious payload is able to install more than 50,000fraudulent applications each day, displays 20 million mali-cious advertisements, and generates more than $300,000 permonth in revenue13. The attacks use multiple exploits in anattempt to gain root access on a device. When rooting fails, asecond component delivers a fake system update notificationin hopes of tricking users into granting HummingBad system-level permissions14. Whether or not rooting succeeds, Hum-mingBad downloads a large number of apps. In some cases,malicious components are dynamically downloaded onto adevice after an infected app is installed. From there, infectedphones display illegitimate ads and install fraudulent appsafter certain events, such as rebooting, the screen turningon or off, a detection that the user is present, or a changein Internet connectivity. HummingBad also has the abilityto inject code into Google Play in order to tamper with itsratings and statistics. This is done by using infected devicesto imitate clicks on the install, buy, and accept buttons15.

In order to download trusted applications, we crawled the

11. https://securingtomorrow.mcafee.com/mcafee-labs/fakeinstaller-leads-the-attack-on-android-phones/

12. https://blog.checkpoint.com/2016/02/04/hummingbad-a-persistent-mobile-chain-attack/

13. https://blog.checkpoint.com/2016/07/01/from-hummingbad-to-worse-new-in-depth-details-and-analysis-of-the-hummingbad-andriod-malware-campaign/

14. http://blog.elevenpaths.com/2016/07/another-month-another-new-rooting.html

15. https://blog.checkpoint.com/wp-content/uploads/2016/07/HummingBad-Research-report FINAL-62916.pdf

12

Google’s official app store16, by using an open-source crawler17.The obtained trusted dataset includes samples belonging to all thedifferent categories available on the market.

The legitimate applications were collected between January2016 and April 2016.

The (malware and trusted) dataset is composed by 400 sam-ples, we randomly selected 50 samples belonging to each family;we described and 50 applications retrieved from Google Play.Moreover, in order to better evaluate the families misclassification,we take into account additional 50 samples belonging to malwarefamilies different from the ones considered into the evaluation(i.e., 50 samples randomly selected among the top ten most popu-lous families of Drebin project dataset not already considered).

Table 5 shows the number of samples considered for eachfamily in the experiment. More precisely, the first column ofthe table shows the number the samples manually inspected togenerate the selective mu-calculus logic formulae characterisingthe malicious behavior of the family. Clearly, for the “Trusted”apps and “Other Malware” ones, no sample has been manuallyinspected since for them no logic formula has been specified. Thesecond column of the table shows the number of samples thathave been evaluated by LEILA. Finally, the third column showsthe total number of the samples considered in our experiment(which is the sum of the other two columns). With the aim ofevaluating the misclassification, we applied the formulae to othermalware families: the number of these samples is shown in “OtherMalware” row.

TABLE 5: The Dataset. The first column shows the families involvedin the experiments; the second column shows the number of thesamples that have been manually inspected; the third column showsthe number of samples that have been evaluated by LEILA; the fourthcolumn shows the total number of the samples considered in ourexperiment.

Family # Inspected Samples # Evaluated Samples # Samples ConsideredOpfake 5 50 55GinMaster 5 50 55FakeInstaller 5 50 55Plankton 5 50 55Ransomware 5 50 55HummingBad 5 50 55Trusted - 50 50Other Malware - 50 50

In order to validate the correctness of the dataset’s classifi-cation, we analyzed the dataset with the VirusTotal service18, aservice running 57 different antimalware software (i.e., Symantec,Avast, Kasperky, McAfee, Panda, and others): the analysis con-firmed that the legitimate applications did not contain maliciouspayload while the malware ones were actually recognized asmalicious.

4.2 Results

Table 6 shows the results of our evaluation. LEILA recognizesthe evaluated Android malware families with an accuracy rangingbetween 0.97 and 1.

The precision varies between 0.84 and 1, while the recallbetween 0.86 and 1. It is worth noticing that we obtained verylow FP values: 4 for Opfake (i.e., 1%), 2 for GinMaster (i.e.,.5%); 9 for Ransomware (i.e., 2.2%); 0 for Plankton samples; 5(i.e., 1.2%) for FakeInstaller samples and 0 for HummingBad.

16. https://play.google.com/store17. https://github.com/liato/android-market-api-py18. https://www.virustotal.com/

Table 7 reports the achieved results with the obfuscated sam-ples showing that the performances keep pretty unchanged.

In order to generate the obfuscated versions of the malware,we used the Droidchameleon [5] tool. Basically the obfuscationprocess consists of code injections (i.e., junk code insertion, codereordering, call indirections and renaming) aimed at generatingmorphed versions of the applications belonging to the malwaredataset.

The DroidChameleon tool applies the transformation tech-niques not only on the malicious payload but to all the applicationcode. For instance, in case we apply the junk code insertiontechnique, all the methods of the application will be obfuscatedwith this technique, the same happens with the other injectedobfuscations. For this reason we can state that 100% of the codewill be obfuscated (more precisely considering for instance, thestring encryption, the 100% of the strings will be obfuscated).

A previous work [5] demonstrated that current antimalwaresolutions fail to recognize the malware after these transformations.We applied our method to the morphed dataset in order to verify ifLEILA loses its effectiveness after the malware has been altered.

The analysis confirms that LEILA is resilient to the commoncode obfuscation techniques. LEILA keeps successful becauseit relies on behavioral features extracted by the Bytecode. As amatter of fact, LEILA detection is realized with logic formulae thatdescribe (and so catch) some characterizing behaviors extractedfrom the Bytecode. A direct benefit is that many code obfuscationtechniques are transparent to the Bytecode, as well as the “nop”insertion: “nop” are not included in the Bytecode.

Table 8 shows the comparison between LEILA and sevencurrent well-know antimalware solutions. This comparison isperformed on the original and morphed versions of the samples.The table reports the number of samples correctly identified asbelonging to the right family. LEILA achieves the best identifica-tion performance if compared with the other antimalware solutions(with both the original and morphed samples). These results revealthat a model-checking-based method is able to recognize themorphed samples, too.

Finally, Table 9 shows, for each family involved in the ex-periment, the details about the number of samples identified byall the considered rules. More precisely, given the formula ϕF ,characterizing the family F , the table shows how many apps satisfythe formula, i.e, belong in the family F . For instance, the Opfakeformula (i.e., the formula ϕOp f ake) is able to:• correctly identify 46 apps of the Opfake family;• incorrectly identify 1 app of the GinMaster family;• incorrectly identify 1 app of the Ransomware family;• incorrectly identify 2 apps of the Plankton family;• correctly identify no app of FakeInstaller family;• correctly identify no app of HummingBad family;• correctly identify no app of Trusted;• correctly identify no app of Other Malware.

We highlight that all the considered formulae are not true onthe trusted samples and on the other malware ones. This issymptomatic that the logic formulae are able to characterize themalicious behaviour of the considered malware families. Note thatfor the “trusted” samples and the “other malware” ones no formulacharacterizing their behaviour exists in the “Formula” column ofTable 9, since in these cases we verify the conjunction of thenegation of all the specified formulae. Furthermore, for the Fake-Installer (resp. HummingBad) family, no sample is misclassified,i.e., no sample belonging to the family is incorrectly recognized by

13

the formula ϕF , where the family F is different from FakeInstaller(resp. HummingBad). In some cases, it is possible that the formulaϕF identifies apps not belonging to the family F . The reasonis that, as demonstrated in [30], those samples can share themalicious behaviour (i.e., ϕFakeInstaller is true on 4 samples of theOpfake family). In other words, the formula is verified also in theapps of other families because the corresponding behavior occursin those families. It is not infrequent that different families canshare single behaviors. Thus, the problem is to choose the overallset of rules that identifies the single family.

4.3 Performance Analysis

We evaluated the CPU load of a machine running LEILA, with theaim to evaluate the LEILA overhead from a computational pointof view.

We resort to the Windows Management InstrumentationCommand-line (WMIC) tool in order to obtain information aboutthe machine carrying out the experiment and to gather the CPUload measurements. Basically, WMIC is a command-line andscripting interface that simplifies the use of Windows ManagementInstrumentation (WMI) and systems managed through WMI. Weconsidered a tool working at the level of operating system insteadof one working at the Virtual Machine level (i.e., JProfiler),because we need to collect also the time required to execute CAAL

(that cannot be measured by a Java virtual machine profiler).WMI is installed by default on Windows desktop and serverenvironments and it is useful to extract several data about themachine under analysis i.e., about the CPU and the architecture.

In order to take the measurements, we considered the fol-lowing command: “wmic cpu get loadpercentage /every:1”: the“/every:1” parameter allows us to take the CPU load percentageevery 1 second. We measured the CPU load in different phasesi.e., the CPU load when LEILA is not running (idle), the decom-pilation phase (dex2jar), the jar to Bytecode process performedby the BCEL library (Bytecode), the building automaton phase(automaton) and, finally, the verification phase (verification). Wecollected the measurements for all these phases every second on100 different apps of different sizes (from 100 KB to 10 MB) andwe computed the average between the measurement points of thesame phase of the considered apps. The average CPU load in theidle phase is 7%, in the dex2jar one is 9%, in the Bytecode one is8%, in the automaton one is 11% and finally in the verification oneis equal to 23%. We highlight that the most representative LEILAphases (i.e., the automaton and the verification ones) are the lessCPU intensive if compared with the other phases. In addition, ifwe consider that the CPU load of the machine under analysis inidle is equal to 7% we can state that the automaton phase requiresthe 3% of CPU load (11%-7%) while the verification one the 16%(23%-7%) of total CPU load average.

In addition, in order to measure the LEILA performancesfrom a temporal point of view, we considered the Sys-tem.currentTimeMillis() Java method that returns the current timein milliseconds. Table 10 shows the performances of our method(both the CPU load and time point of view). These two valuesare the average times, i.e., they are computed as the total timeemployed by LEILA to process the samples divided the numberof samples evaluated.

The machine used to evaluate the LEILA CPU load hasthese characteristics: an Intel Core i3 CPU 540@3.04 GHz (in-formation obtained using the following WIMC option: “wmic

Fig. 6: An Example of Payload Localization: the involved classes

cpu get name, CurrentClockSpeed”), with Microsoft Windows7 Ultimate Service Pack 1 64 bit on board (“wmic OSget Caption,CSDVersion,OSArchitecture”). The CPU presents 2cores and 4 logical processors (“wmic cpu get NumberOf-Cores,NumberOfLogicalProcessors”).

The times we have obtained seem to be still high for an usagein the real world, nevertheless LEILA is intended to be used toperform antimalware analysis on apps marketplace, before thepublication of an app. The times could be improved a lot, consid-ering the deployment on appropriate servers of the marketplace’sback end running LEILA; and as the analysis will not run on thedevice, LEILA will not affect the usability of the device.

5 DISCUSSION

In the following subsections we discuss the distinctive featuresand the limitations of our method.

5.1 Detailed discussion of the novelties

We can point out some key novelties of the proposed approach.• We provide an automatic dissection of a mobile application,

since it checks whether an app performs a specific behaviour,with an additional benefit: the localization into the code ofthose instructions that implement the actions that determinethe malicious behaviour. Our solution is able to identifythe exact position of those instructions characterizing themalicious behaviour. The method indicates the class file(s)where the rule is verified, with a precision at method level.This is a very novel result in the malware analysis and itcould be used by the current antimalware to build a new typeof birthmark which is expressed by a behaviour, i.e., a set ofrules, instead of a sequence of bytes, i.e., a signature. Fig. 6shows the name of the classes involved for the satisfactionof the formula. In details, LEILA also reports the list of thecalled and the calling methods. In Fig. 7 we have graphicallyshown only a part of that list. The complete representation isomitted in the figure to save space.A first attempt to localize the payload can be found in [31].HookRanker tool provides ranked lists of potentially mali-cious packages taking into account the way in which malwarebehaviour is triggered. HookRanker is able to perform adissection of a sample under analysis at the granularity levelof packages, while LEILA analysis localizes the maliciousbehaviour at a lower level;

• in addition to the payload localization, we can catch theevents that trigger the malicious payload. We focus on thisaspect because at the best of authors’ knowledge the currentantimalware technologies are able only to delete the detectedsamples: our method can be used as a sanitizer tool i.e., amethod able to make the payload not activable;

14

TABLE 6: Results of the evaluation. The first column represents the logic formula of all the families involved in the experiments. The secondand the third column show respectively the number of samples belonging and not belonging to the family associated to the formula. The fourthcolumn shows the number of trusted samples. All the other columns contain True Positives, False Positives, False Negatives, True Negatives,Precision, Recall, F-measure, and Accuracy.

Formula #Malware ∈ Family #Malware 6∈ Family #Trusted TP FP FN TN PR RC Fm AccOpfake 50 300 50 46 4 4 346 0.92 0.92 0.92 0.98GinMaster 50 300 50 47 2 3 348 0.95 0.94 0.94 0.98Ransomware 50 300 50 48 9 2 341 0.84 0.96 0.84 0.97Plankton 50 300 50 50 0 0 350 1 1 1 1FakeInstaller 50 300 50 43 5 7 345 0.89 0.86 0.87 0.97HummingBad 50 300 50 50 0 0 350 1 1 1 1

Fig. 7: An Example of Payload Localization: the involved methods

TABLE 7: Resilience to the Obfuscation Techniques. The first columnrepresents the families involved in the experiments. The secondand the fourth column show respectively the number of samplesbelonging to the original and morphed family. The third and the fifthcolumn report the number of samples correctly identified by LEILA(TP),respectively in the original forma and in the morphed form.

Dataset Original Morphed# Samples TP # Samples TP

Opfake 50 46 50 46GinMaster 50 47 50 47Ransomware 50 48 50 48Plankton 50 50 50 50FakeInstaller 50 43 50 43HummingBad 50 50 50 50

• another important novelty of our approach is the use of modelchecking techniques for Android applications to identifymalware families with the management of the method calls.All these aspects have never been treated jointly, to thebest of the authors’ knowledge. In addition, model checking,besides proving that a program is not correct, can also helpdebugging, making it possible to locate errors. In fact, ifa property does not hold, the model checking algorithmgenerates a counter-example, i.e., an execution trace leadingto a state in which the property is violated. This abilityto generate counter-examples, which can be exploited topinpoint the cause of an error, is the main advantage of model

checking, as compared to other well-known techniques forsoftware verification, as abstract static analysis. Thus, ourformal model can be used (i) to identify Android malwarefamily; (ii) to perform code obfuscation detection; (iii) tohelp in code analysis; and (iv) to get insight on liveness andsafety properties of the code, using a single model-checkingbased framework;

• we propose a behaviour-based detection as an approach tomitigate the effect of code obfuscation techniques. This isagainst the backdrop of the limitations of signature-based ap-proach commonly in use nowadays by most antivirus engines.Signature-based approaches require: the analysis of signaturestrings, to obtain signatures of malware, and storing them indatabases with which strings of any new attacks are comparedfor possible detection. New attacks whose signatures have notbeen previously obtained and stored in databases can not bedetected. Our behaviour-based approach is able to handle newmalware payloads and detect real malware found in the wild,when the new malware exhibits a behavior similar to that ofan analyzed payload;

• our approach can manage multi-threading in Android ap-plications being based on CCS with its intrinsic notionof concurrency. Using the CCS parallel operator we canproduce automatically all the interleavings of the executionsof the threads, differently from the dynamic analysis wheredifferent executions of the same software systems will gen-erally produce different traces depending on the execution

15

TABLE 8: Comparison between LEILA and antimalware. The comparison is performed in terms of number of original and morphed samplescorrectly identified

Family #Samples LEILA AVG Ad Aware Avast Arcabit Alibaba ESET NOD32 McAfeeOriginal Samples

Opfake 50 46 48 23 32 21 18 33 7GinMaster 50 47 41 42 44 45 37 39 12Ransomware 50 48 13 50 27 49 34 9 6Plankton 50 50 31 28 23 42 19 50 7FakeInstaller 50 43 37 3 41 46 4 35 4HummingBad 50 50 3 2 0 1 11 0 0

Morphed SamplesOpfake 50 46 44 10 14 10 9 22 3GinMaster 50 47 33 37 38 37 24 27 5Ransomware 50 48 7 45 19 45 26 4 2Plankton 50 50 24 20 17 35 8 46 3FakeInstaller 50 43 25 0 28 34 0 23 0HummingBad 50 50 0 0 0 0 4 0 0

TABLE 9: Cross check for Properties Evaluation. Each row is associated to the formula charactering the family F, while the column F indicatesthe number of samples correctly identified, all the other columns indicate the number of samples incorrectly identified.

Formula

Samples Opfake50

GinMaster50

Ransomware50

Plankton50

FakeInstaller50

HummingBad50

Trusted50

Other Malware50

Opfake 46 1 1 2 0 0 0 0GinMaster 1 47 0 1 0 0 0 0Ransomware 3 4 48 2 0 0 0 0Plankton 0 0 0 50 0 0 0 0FakeInstaller 4 0 1 0 43 0 0 0HummingBad 0 0 0 0 0 50 0 0

TABLE 10: LEILA Performance Analysis Evaluation. The idle col-umn represents the performances analysis measured when LEILA isnot running, the dex2jar column is related when LEILA executesthe decompilation phase, the bytecode column represents the jar toBytecode process performed by the BCEL library, the automaton onerepresents the building automaton phase and, finally, the verificationphase (i.e., the verification column ).

analysis idle dex2jar bytecode automaton verificationCPU load 7% 9% 8% 11% 23%time 0 s 2 s 5 s 4 s 483 s

order of the different instructions due to thread schedulingor other software external content. Events in Android mayoccur asynchronously. The order of these events is nondeter-ministic, but may be relevant to the checked formula. Ourinterleaving-based model avoids this problem. Obviously, amodel checking based approach can become unscalable asthe number of threads grows. To cope with this problem,we propose a state-space reduction in order to improve thedetection performance, as explained in the following section.

Our method derives CCS processes from the Java Bytecodeand uses them to check properties expressing the key characteris-tics of a malware family. A significant feature of our approachis that we try to reuse existing model checkers avoiding thedesign of custom-made model checker. In fact our goal is torecognise malware families with the criteria of reusing existingmodel checking technologies. Model checkers, especially the mostwidely used ones, are extremely sophisticated programs that havebeen crafted over many years by experts in the specific techniquesemployed by the tool. A re-implementation of the algorithms inthese tools could likely yield worst performance.

The benefit of our method derives from the power of auto-mated model checking to search a state space. Also the generation

of the formal model is automated. Moreover, being the CCS apowerful language for specifying and reasoning about concurrentsystems, we are able to model call of methods and recognizea malicious behaviour not only by checking the presence of agiven sequence, like happens with pattern-matching approach,but also by checking a branching temporal logic formula, thatpermits to define a wide range of properties of program executions,security properties and more generally, invariant, liveness or safetyproperties.

The fundamental drawback of a pattern-matching approachto malware detection is that it is purely syntactic and it ignoresthe behaviour of a program. Commercial malware detectors usesimple pattern matching approaches to malware detection. A codeis considered malware if it contains a sequence of instructionsthat is matched by a regular expression. Recently, it has beenshown that such malware detectors can be easily defeated usingsimple program obfuscations [32], that are already being usedby the malware writers. Since the pattern-matching algorithm isnot resilient to slight modifications, these malware detectors mustuse different patterns to recognize two malware instances that aresmall modifications of each other. Thus, the signatures databaseof a commercial virus scanner has to be frequently updated.Our approach overcomes this kind of problem, being resilient tominor obfuscations and modifications, as shown in [20] and in theprevious section.

On the other side, our method requires that a set of logicrules be defined for each family. Actually, they have been definedmanually by inspecting very few samples for each family, but weare studying approaches to automatically deduce the logic rules.Some hints are given in Section 5.3.

Our method leverages the Bytecode representation of Java pro-grams produced by a Java compiler. Performing Android malwarefamilies detection on the Bytecode and not directly on the Javacode has several advantages:

16

• independence of the source programming language (e.g.,Kotlin Language19);

• detection of malware families without decompilation evenwhen source code is missing;

• ease of parsing a lower-level code;• independence from some obfuscation techniques.Another relevant feature of our method is the detection of

payload fragmentation, as shown in Fig. 8. In particular, thepayload is related to formula ϕ in Table 3. The two snippets ofcode belong to the Opfake family. The payload is highlightedby the big red rectangle both in Sample A and in Sample B.The difference is that, in sample A the payload occurs in thefor instruction, while in the sample B the payload is locatedin the sendSMS method that is invoked in the for instruction.According to the formula ϕ of Table 3, a sample is infected byOpFake malware if the actions involved in the formula ϕ occurmany times in the sample’s code. By analyzing in isolation onlythe body of the method of the Sample B, it is not possible torecognize the malicious payload, since the malicious actions occuronly one time. To recognize the Sample B as malware, it is neededto implement the method call, as done in our method.

As a simple example, Fig. 9 shows a fragment of the automa-ton generated by the code of Sample B in Fig. 8. Our model isable to characterize the code behaviour. In fact, the automatonmimics both the cyclic behaviors of a code and the method calls.By using a model checker tool, it is possible to verify, in anautomatic manner, if the model exhibits a specified behaviour. Themodel checker verifies if the behaviour specified by the formulais true (or not) on the model. Both the model and the formulaare the inputs of the model checker tool. The advantage is thatno responsibility of the human verifier of the system is required,i.e., user intervention is not needed. Using this kind of approachis simple and automatic to verify every behaviour of a model.Considering the example of Fig. 9, the formula ϕ is true on theautomaton, recognizing in this way the malicious payload.

5.2 Motivation of the use of the selective mu-calculus logic

It is well-known that most current formal methods are mainlyapplicable to small-scale applications, but do not scale up well.However, the state explosion problem, typical of model checking,can be a real problem when analyzing Android applications, sincethe produced CCS specifications can have a large number of statesand transitions. In fact, our new formal model takes into accountalso methods invocations specified as a parallel composition. Toalleviate the state explosion problem, we use the selective mu-calculus logic to express Android malware families. In this waywe improve both the performance, i.e., the speed at which themodel checker returns its results, and its scalability, i.e., the extentto which the model checker can manage increasingly large apps.In the following, we discuss the results of these tests.

The basic characteristic of the selective mu-calculus is that theactions relevant for checking a formula ϕ are those ones explicitlymentioned in the modal operators used in the formula itself. Thus,we define the set O(ϕ) of occurring actions of a formula ϕ as theunion of all sets K and R appearing in the modal operators ([K]Rψ,〈K〉Rψ) occurring in ϕ.

In the work [16] ρ-equivalence is defined, formally character-izing the notion of “the same behavior with respect to a set ρ ofactions”:

19. https://developer.android.com/kotlin/index.html

two transition systems are ρ-equivalent if a ρ-bisimulationrelating their initial states exists.

The definition of ρ-bisimulation is based on the concept of α-ending path: an α-ending path is a sequence of transitions labelledby actions not in ρ followed by a transition labelled by the actionα in ρ. Two states S1 and S2 are ρ-bisimilar if and only if for eachα-ending path starting from S1 and ending into S′1, there exists anα-ending path starting from S2 and ending into a state ρ-bisimilarto S′1, and vice-versa. In [16] it is proved that

two transition systems are ρ-equivalent if and only if they satisfythe same set of formulae with occurring actions in ρ.

As a consequence, a formula of the selective mu-calculus withoccurring actions in ρ can be checked on any transition systemρ-equivalent to the standard one. Thus, improvements in modelchecking can be obtained by minimizing the transition systemwith respect to the actions in ρ. Obviously, the degree of reductiondepends on the size of ρ with respect to the size of the whole setA of actions.

Consider again the transition systems illustrated in Fig. 3. S1is {a,b}-equivalent to S3. The two transition systems give thesame value for the formulae containing only actions in {a,b}.In particular, they satisfy ψ2, while they do not satisfy ψ1. Notethat O(ψ1) = {a,b} and O(ψ2) = {a} ⊆ {a,b}. On the contraryS2 is not {a,b}-equivalent to S3, since it can perform an action bwithout performing an action a. In [33] a method is defined, which,given a process p and a set of interesting actions ρ occurring ina formula ϕ to be checked, transforms p into another processq, corresponding to a smaller transition system than that of p,on which ϕ can be equivalently checked. The tool is based ona set of syntactic transformations rules. A prototype tool whichimplements the algorithm has also been defined; it is written inSICStus Prolog20.

We discuss our experience with the above method. The aimis to evaluate the performances of the approach and compare itagainst the standard formal verification environment. First, we ap-ply our tool to transform the specification into a smaller one, wherethe reduction is driven by the actions occurring in the formulae.Then, we check the properties on the reduced specification. Allproperties have been checked on reduced CCS processes; belowwe will show only the application on a single property, just to givethe reader the flavor of the approach followed.

Consider the following property:

ψ = 〈invokesqlEscapeString〉 /0〈new javalangStringBuilder〉 /0〈invokeappend〉 /0 〈invokeexecSQL〉 /0〈invokerawQuery〉 /0 〈invokemoveToNext〉 /0〈invokeclose〉 /0tt

ψ is a selective mu-calculus logic formulation characterizingthe Gin Master family. It holds that the set of interesting actionsof the above property is:

ρ = O(ψ) = { invokesqlEscapeString,new javalangStringBuilder, invokeappend,invokeexecSQL, invokerawQuery,invokemoveToNext, invokeclose

}

20. http://www.sics.se/isl/sicstus.html

17

Fig. 8: An Example of the Payload Fragmentation. The two considered samples belong to the Opfake family

TABLE 11: State-Space reduction

State-space State-space(ψ-reduction) (without reduction)states trans. states trans.4,688 12,898 20,435 51,213

Table 11 shows the number of states and transitions of the ψ-reduction, i.e., is the reduced CCS process obtained by applyingthe property-based method with ρ. It is worth noting that the re-duction we perform of the states and transitions is significant. Notethat also for all the other properties we obtain great reductions.Obviously, a reduction of the state-space implies also a reductionof the time employed by model checker to check the formulae.In most cases we obtain a reduction more than 95%. In general,the usefulness of our tool depends both on the number of actionsoccurring in the formula and on the structure of the formula to bechecked.

5.3 Limitations

This section discusses the limitations of our method.• Non-Detectable by Static Analysis obfuscation techniques. As

stated in [34], obfuscation transformations can be classifiedinto two classes: (i) those which result in variants that can stillbe detected by advanced static analyses involving data-flowand control-flow analysis, like for example, call indirections,code reordering; (ii) and those which can render malwareundetectable by static analysis, like for example, reflection[35], Bytecode encryption. Our method, being static, cannotmanage obfuscations belonging to the undetectable by staticanalysis type. In fact, LEILA is not able to resolve the targetof reflected method calls if these targets are stored encryptedor created dynamically;

• Virtual calls. LEILA does not handle dynamic runtime be-haviors of Java programs, such as virtual method invoca-tions. In presence of inheritance, the problem of resolvingvirtual methods is not managed, since our method flattens

all possible flows into a single one that is based on thestatic declaration of the reference used to access the object.However, our method also checks all the other methods notoccurring in the analyzed flow (i.e., never referred in theBytecode), since they are specified as a non-deterministicchoice in our model. Obviously, this solution breaks down thecomplexity of our method, reducing the number of virtual calltargets, but may introduce incorrectness and incompleteness,even if in reality, as shown in the “Results” section, this hasnot massively occurred;

• Manual definition of the formulae. The logic rule-set charac-terizing a malware family needs to be designed and defined.Writing the correct rules can be a rather complex task.Currently, we are studying an approach based on clone detec-tion to automatically deduce the logic rules. Another viablesolution could be the use of natural language processing toolsfor the analysis of technical reports. Furthermore, to help thedesigner to write simple temporal properties, it is possible touse the user-friendly interface (UFI) developed by one of theauthors and al. in [36]. UFI has the aim of simplifying thewriting of the logic properties;

• Performances. LEILA is currently a research prototype toolwhose main aim is to demonstrate the effectiveness of ourmethod in malware families identification, thus the perfor-mances are not the core issue of development of LEILA.Although the times we have obtained seem to be still highfor an usage in the real world, it should be considered howLEILA is intended to be applied. LEILA was conceived toperform antimalware analysis on apps marketplace, beforethe publication of an app. Consequently appropriate architec-tures can be deployed on the marketplace back end in orderto improve performances, and, in any case, it does not affectthe device’s usability;

• Native code and cross-site-scripting. Another weakness ofour method is represented by the fact that LEILA prototypeconsiders in its analysis the Bytecode extracted by the dexfile of the mobile application excluding the native code andthe javascript code possibly embedded into the application.

Overall, we think that these limitations do not severely restrict

18

Fig. 9: An Example of fragment of the automaton related to the payload code shown in Fig. 8 Sample B

the applicability of our method. Our method, as the experimen-tation demonstrated, should be considered as a good check toget a reasonable trust in the correctness of detecting maliciousbehaviour and, especially, localizing the payload within the code.

6 RELATED WORK

Previous researches have demonstrated that the formal verificationcan help to detect malware. In the following we describe malwaredetection methodologies employing formal methods.

In [37] an extension CTPL (Computation Tree PredicateLogic) of CTL (Computation Tree Logic) has been proposed toexpress some malicious properties that are used to detect themalicious behavior of thirteen Windows malware variants usingas dataset a set of worms dating from 2002 to 2004. Further, Songand Touili extend CTPL to SCTPL for better description on stack-based actions of viral behaviors [38].

Song et al. [38] present an approach to model MicrosoftWindows XP binary programs as a PushDown System (PDS).They evaluate 200 malware variants (generated by NGVCK andVCL32 engines) and 8 benign programs.

The tool PoMMaDe [39] implements a custom-made model-checking algorithm that it is able to detect 600 real malwarefor PCs, 200 malwares generated by two malware generators(NGVCK and VCL32), and proves the reliability of benignprograms: a Microsoft Windows binary program is modeled as aPushDown System which allows to track the stack of the program.

First of all, our main objective is to reuse existing modelcheckers avoiding the design of custom-made model checker.Model checkers are extremely sophisticated programs that havebeen crafted over many years by experts in the specific techniques

employed by the tool. A re-implementation of the algorithmsin these tools could likely yield worst performance. Secondly,we focus on Android Mobile malware, instead on PC malware.Thirdly, our approach is able to identify the localization of themalicious payload, especially if it is broken up into severalmethods, classes and packages of the application under analysis.Finally, we propose a method for the identification of familymalware.

Song and Touili in [40] apply model checking to Androidapps. However, they model mobile applications using a PushDownSystem in order to discovery only private data leaking working atSmali code level.

Jacob and colleagues [41] provide a basis for a malwaremodel, founded on the Join-Calculus: they consider the systemcall sequences to build the model. It is a theoretical paper thatshows the intractability of the malware detection problem provid-ing a formalization of malware in a Turing complete model ofcomputation.

Recently, in [42] the authors have built a general frameworknamed DROIDPF upon Java PathFinder (JPF), towards modelchecking Android apps. DROIDPF focuses on common securityvulnerabilities in Android apps including sensitive data leakageinvolving a non-trivial flow- and context-sensitive taint-style anal-ysis. Differently, LEILA focuses on the detection of maliciousfamily identification.

The possibility to identify the malicious payload in Androidmalware using a model checking based approach has been alreadyexplored by some the authors of these papers [43], [20], [21].Starting from the payload behavior definition the authors formu-late logic rules and then test them by using a real world datasetcomposed by real world Android malware samples. The main

19

difference with the method presented in this paper is representedby the fact that the cited methodologies are not able to catch amalicious action divided in different small parts of the applicationi.e., the payload using these methods is recognizable only if it isfully included in a single method.

6.1 A comparison with Machine Learning based approaches

In last years machine learning was largely employed to generatethe classifiers able to discriminate malware samples from thegoodware. The main task of machine learning based approachesis represented by the feature(s) selection phase, once extractedthe feature representing the malware payload, the training process(and the consequently testing phase) is automatically provided bywell-known algorithms. In the following we briefly describe themost representative efforts done by researchers in this direction.

Canfora et al. [44]: the authors have proposed a machine learn-ing based approach to identify Android malware families. Thefeatures are extracted using two techniques: the Hidden MarkovModel (HMM) and the Structural Entropy. The first techniqueconsiders HMMs with the aim to determine if an applicationis similar to malware, while the second one is based on theestimation of structural entropy of an the executable (i.e., the .dexfile) using the wavelet transform to obtain a representation of theentropy series. The features gathered using the two techniques areused to classify malware families with following algorithms: J48,LabTree, NBTree, RandomForest, RandomTree and RepTree.

Madam [45]: MADAM is an Android malware detector thatconcurrently monitors the device under analysis both at kerneland at user level; machine learning techniques are employed todistinguish between standard and malicious behaviors. At kernel-level, features related to the following system parameters areextracted: system calls, running processes, free RAM and CPUusage. At user-level, features related to the following systemparameters are considered: idle/active, key-stroke, called numbers,sent/received SMS and Bluetooth/Wi-Fi analysis. The developedprototype is able to detect several real-world malware applicationsfound in the wild with a low number of false positives.

ICCDetector [46]: the authors have proposed a machine learn-ing based detection method, called ICCDetector. This approachrecognizes a malware using its Inter-Component Communication(ICC) patterns. Starting from an APK file the authors model howit use the ICC mechanism. At the end of this process the ICCpatterns of the APK file are defined. Afterwards, they trainedICCDetector with the ICC patterns belonging to benign andmalicious applications. According to the ICC patterns identified,ICCDetector further has classified the malicious application in fivenew malware categories.

DroidClone [1]: the authors use a clone detection to recognizeAndroid malware variants. In order to find code clone MAILlanguage is used, a new Malware Analysis and IntermediateLanguage. MAIL is used to specify control flow patterns whichreduces the effect of obfuscations and provides automation andplatform independence.

DroidScribe [47]: the authors use machine learning techniquesto automatically classify Android malware samples into fami-lies observing their runtime behavior i.e., performing a dynamicanalysis. They have considered several feature sets in order toincrease the accuracy: the first one, based on IP, port and networktraffic size; the second one, based on file name and type, nameclasses; the third one, based on method name and parameters

and the last one, based on user permission to execute a file. Thetrained classifiers fuses Support Vector Machines with ConformalPrediction obtaining an accuracy equal to 84%.

StormDroid [48]: StormDroid is a machine learning basedframework for malware detection. The authors have defined twokind of features: well received features and newly-defined features.The first one are the required permissions by an application andthe sensitive API calls. The second one are the newly defined“Sequences” and Dynamic behaviours. The Sequence is the quan-tity of sensitive API calls (i.e., the number of sensitive API callsrequested by the malicious applications and the benign ones,respectively). Dynamic behaviour analysis aims to observe themalicious activities performed by an application, for instance amalicious app request sensitive information more frequently thanthe benign one. The top features of dynamic behaviors used in thiswork are network activity, file system access and interaction withthe operating system. In order to collect these features StormDroidperforms an hybrid analysis, it employs both static and dynamicanalysis.

DroidSieve [49]: the proposed approach is an Android mal-ware classifier based on static analysis. The authors identifytwo high-level classes: resource-centric features are derived fromresources used by the application under analysis, while syntacticfeatures are derived from the code and metadata of the mobile ap-plication. Furthermore, the authors consider obfuscation-invariantfeatures and artifacts introduced by obfuscation mechanisms com-monly used by malware writers.

Nix and Zhang [50]: the authors have proposed a classificationmethods based on Deep Neural Networks (DNNs). In particular,they design a Convolutional Neural Network (CNN) to detectmalware. The features used in the classification are the Androidsystem-API calls. They extract these feature without any executionof the code. Authors track the program instructions followingthe all possible execution of the code without computing anystate information of the program. Authors also compare with therecurrent neural network with Long Short Term Memory (LSTM)and other n-gram based methods.

In order to highlight the novelty of LEILA, we compare ourtool with the above approaches. There are plenty of possiblecriteria for such comparison. We formulate seven essential criteria:• C1: Approach. The approaches can be static, dynamic or

hybrid;• C2: Family Identification Capability. The approach is able

to categorize the malware sample in the right family, i.e., torecognize the family which the malware belongs to;

• C3: Resilience to Code Obfuscation. The approach relies oncommon code obfuscation techniques;

• C4: Behavioural Analysis. The approach performs somebehavioural analyses on the sample under analysis;

• C5: Statement-level Localization. The approach performsmalicious payload localization at lower level i.e., it providessome information about the malicious payload and its posi-tion in the code of the sample;

• C6: Completely Automatic. The approach performs its anal-ysis without human involvement;

• C7: Multi-threading. The approach supports multi-threadanalysis. This analysis is important since Android is event-based and it has several components able to interact with eachother.

Table 12 highlights the differences between LEILA and thethe other considered approaches. In Table 12 the rows are the

20

considered approaches and the columns are the formulated criteriafor the comparison. Note that, whether a criterion is not explicitlyspecified in the work, the Table 12 presents the label N/A standingfor information Not Available. Table 12 shows that LEILA is theonly method able to both localize the malicious behaviours and toperform multi-thread analysis.

Furthermore, the main criticisms related to machine learningtechniques are the following: (i) the usage of an extensive trainingset in order to reach high precision and recall, (ii) if the featuresrelated to a malware behaviour are not represented in the trainingset, the application will be not successfully recognized, (iii) thehigh false positives rate, (iv) the need to continually update thetraining set in order to catch the new threats.

Differently, our method requires a small subset of samples inorder to extract the logic rules representing the malware behaviourand it has a few false positives. In addition, with the featuresextracted it is not possible to build classifiers able to localize themalicious payload, as a matter of fact the aim in these cases isthe binary malware detection (i.e., the aim of the authors is todiscriminate malware applications from legitimate ones).

6.2 A comparison with Flow Analysis Approaches

Differently from the previous techniques there is another kind ofapproach related to the detection of the ICC issue. The maindifferences with our work is represented by the fact that thesetools do not identify malicious payload, but the source andthe destination of exfiltered data, for this reason they are notconsidered as malware detector but as tools that help the securityexpert to analyze if there is a connection from source of privateand confidential data to the sink (i.e., the channel used to senddata out of device for instance, a method writing the informationto a socket). The following tools perform ICC detection.

Amandroid [11] performs an ICC analysis to detect ICC leaks,and has been developed concurrently with IccTA. Amandroidneeds to build an Inter-component Data Flow Graph (ICDFG)and an Data Dependence Graph (DDG) to perform ICC analysis.It is basically a general framework to enable analysts to build acustomized analysis on Android apps.

FlowDroid [10] adequately models Android-specific chal-lenges like the application lifecycle or callback methods. It helpsreduce missed leaks or false positives. Novel on-demand algo-rithms allow FlowDroid to maintain efficiency despite its strongcontext and object sensitivity.

Epicc [51] identifies a specification for every ICC source andsink. This includes the location of the ICC entry point or exit point,the ICC Intent action, data type and category, as well as the ICCIntent key/value types and the target component name. Note thatwhere ICC values are not fixed Epicc infer all possible ICC values,thereby building a complete specification of the possible ways ICCcan be used. The specifications are recorded in a database as flowsdetected by matching compatible specifications.

IccTA [52] uses a static taint analysis technique to find privacyleaks, i.e., paths from sensitive data, called sources, to statementssending the data outside the application or device, called sinks.A path may be within a single component or cross multiplecomponents. To verify their approach, authors developed 22 appscontaining ICC-based privacy leaks.

TaintDroid [53] is an extension to the Android operatingsystem that tracks the flow of privacy sensitive data through third-party applications. TaintDroid assumes that downloaded, third-

party applications are not trusted, and monitors in realtime howthese applications access and manipulate users’ personal data.

PCLeaks [54] performs data-flow analysis to detect potentialcomponent leaks, which not only include component hijackingvulnerabilities, but also component launch (or injection) vulnera-bilities.

7 CONCLUDING REMARKS AND FUTURE WORK

Malware in last years is plagiarizing mobile users: threats arequickly becoming more and more aggressive in gathering sen-sitive and private user information and stealing credit. Currentantimalware technologies are not able to protect users also whena malware is recognized by antimalware, by using trivial obfusca-tion techniques the attackers can easily elude the detection. Inorder to overcome these limitations, in this paper we proposeLEILA, a model checking-based method able to identify An-droid malware introducing new features, as the localization ofthe malicious classes into the infected application, family andfragmented payload recognition. We evaluated LEILA using real-world Android malware belonging to six widespread families(Opfake, GinMaster, FakeInstaller, HummingBad, Plankton andRansomware), obtaining an accuracy ranging between 0.97 and 1.We produced morphed variants of the dataset we tested in orderto demonstrate the effectiveness of LEILA in obfuscated malwareidentification, finding that even when signature-based antimalwareare eluded by the obfuscated samples, LEILA is anyway able torecognize the malicious payloads.

The main disadvantage of the proposed technique is repre-sented by the manual rule generation. This is the reason why weplan to design an approach to automatically deduce logic rules. Asstated in Section 5.3, we are studying an approach based on clonedetection to automatically deduce the logic rules.

As future work, we plan to test LEILA with other malwarefamilies, with particular regards with colluding malware [55] i.e.,malicious applications with the ability to exploit covert or overtchannels. In addition, we will improve our method in order tomake ineffective the malicious payload once localized by LEILA.

Another trend in Android malware is the exploit of MultiDexapplications i.e., applications that use two Dalvik Executable(DEX) files to deliver the final payload. The current antimalwareand the state-of-the-art detectors fail to recognize this kind ofmalware as they focus on a single DEX file as well. Our approachcan identify the malicious payload also in MultiDex applications.

In addition, we plan to evolve LEILA and make it able toinspect also ARM instructions (this requires to build the automa-ton related to the ARM libraries in order to verify whether themalicious payload is implemented). With regard to the cross-site-scripting (i.e., the JavaScript injection), considering that An-droid application can embed urls into the application code, acountermeasures in order to mitigate this kind of attacks can berepresented by the usage of a sandbox to visit the url and downloadthe malicious JavaScript in order to analyze it.

Finally, the efficiency of LEILA will be tested also on malwareprovided by Mystique [56], a framework to automatically generatemalware with specific features. This will allow us to verifiesspecific behavior on samples ad-hoc generated.

ACKNOWLEDGMENT

This work was partially supported by the H2020 EU fundedproject NeCS [GA #675320], by the H2020 EU funded projectC3ISP [GA #700294].

21

TABLE 12: Comparison of Approaches for Malware Detection

Approaches

Criteria

Year

Kin

dof

appr

oach

Fam

ilyId

entifi

catio

nC

apab

ility

Res

ilien

ceto

Cod

eO

bfus

catio

n

Beh

avio

ural

Ana

lysi

s

Stat

emen

t-le

vel L

ocal

izat

ion

Com

plet

ely

Aut

omat

ic

Mul

ti-th

read

ing

Canfora et al. [44] 2016 Static 3 N/A 7 7 3 7Madam [45] 2016 Hybrid 7 N/A 7 7 3 7

ICCDetector [46] 2016 Static 7 N/A 7 7 3 7DroidClone [1] 2016 Static 7 3 7 7 3 7

DroidScribe [47] 2016 Dynamic 3 3 3 7 3 7StormDroid [48] 2016 Hybrid 7 N/A 3 7 3 7DroidSieve [49] 2017 Static 3 3 7 7 3 7

Nix and Zhang [50] 2017 Pseudo-Dynamic 3 N/A 7 7 3 7LEILA 2017 Static 3 3 3 3 7 3

The Authors thank Maurizio Viscusi and Raffaele Sanzari forhelping in the LEILA implementation.

REFERENCES

[1] S. Alam, R. Riley, I. Sogukpinar, and N. Carkaci, “Droidclone: Detectingandroid malware variants by exposing code clones,” in Digital Infor-mation and Communication Technology and its Applications (DICTAP),2016 Sixth International Conference on. IEEE, 2016, pp. 79–84.

[2] G. Canfora, A. Di Sorbo, F. Mercaldo, and C. A. Visaggio, “Obfuscationtechniques against signature-based detection: a case study,” in 2015Mobile Systems Technologies Workshop (MST). IEEE, 2015, pp. 21–26.

[3] L. Nishani, “Review on security threats for mobile devices and significantcountermeasures on securing android mobiles,” Automated EnterpriseSystems for Maximizing Business Performance, 2015.

[4] V. Rastogi, Y. Chen, and X. Jiang, “Catch me if you can: Evaluatingandroid anti-malware against transformation attacks,” IEEE Transactionson Information Forensics and Security, vol. 9, no. 1, pp. 99–108, 2014.

[5] ——, “Droidchameleon: evaluating android anti-malware against trans-formation attacks,” in Proceedings of the 8th ACM SIGSAC symposiumon Information, computer and communications security. ACM, 2013,pp. 329–334.

[6] M. Zheng, P. P. Lee, and J. C. Lui, “Adam: an automatic and extensibleplatform to stress test android anti-virus systems,” in InternationalConference on Detection of Intrusions and Malware, and VulnerabilityAssessment. Springer, 2012, pp. 82–101.

[7] I. Burguera, U. Zurutuza, and S. Nadjm-Tehrani, “Crowdroid: behavior-based malware detection system for android,” in Proceedings of the 1stACM workshop on Security and privacy in smartphones and mobiledevices. ACM, 2011, pp. 15–26.

[8] Y. Aafer, W. Du, and H. Yin, “Droidapiminer: Mining api-level featuresfor robust malware detection in android,” in International Conference onSecurity and Privacy in Communication Systems. Springer, 2013, pp.86–103.

[9] F. Wei, Y. Li, S. Roy, X. Ou, and W. Zhou, “Deep ground truth analysisof current android malware,” in International Conference on Detection ofIntrusions and Malware, and Vulnerability Assessment. Springer, 2017,pp. 252–276.

[10] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y. Le Traon,D. Octeau, and P. McDaniel, “Flowdroid: Precise context, flow, field,object-sensitive and lifecycle-aware taint analysis for android apps,”ACM SIGPLAN Notices, vol. 49, no. 6, pp. 259–269, 2014.

[11] F. Wei, S. Roy, X. Ou et al., “Amandroid: A precise and generalinter-component data flow analysis framework for security vetting ofandroid apps,” in Proceedings of the 2014 ACM SIGSAC Conference onComputer and Communications Security. ACM, 2014, pp. 1329–1341.

[12] C. K. Georgios Kambourakis, Asaf Shabtai and D. Damopoulos, Eds.,Data Leakage in Mobile Malware: the what, the why and the how. Taylorand Francis, 2017.

[13] V. Rastogi, Y. Chen, and X. Jiang, “Catch me if you can: Evaluatingandroid anti-malware against transformation attacks,” IEEE Trans.Information Forensics and Security, vol. 9, no. 1, pp. 99–108, 2014.[Online]. Available: http://dx.doi.org/10.1109/TIFS.2013.2290431

[14] E. M. Clarke and E. A. Emerson, “Design and synthesis of synchro-nization skeletons using branching time temporal logic,” in 25 Years ofModel Checking, ser. Lecture Notes in Computer Science, O. Grumbergand H. Veith, Eds., vol. 5000. Springer, 2008, pp. 196–215.

[15] R. Milner, Communication and concurrency, ser. PHI Series in computerscience. Prentice Hall, 1989.

[16] R. Barbuti, N. D. Francesco, A. Santone, and G. Vaglini, “Selectivemu-calculus and formula-based equivalence of transition systems,” J.Comput. Syst. Sci., vol. 59, no. 3, pp. 537–556, 1999.

[17] C. Stirling, “An introduction to modal and temporal logics for ccs,”in Concurrency: Theory, Language, And Architecture, ser. LNCS,A. Yonezawa and T. Ito, Eds., vol. 491. Springer, 1989, pp. 2–20.

[18] J. R. Andersen, N. Andersen, S. Enevoldsen, M. M. Hansen, K. G.Larsen, S. R. Olesen, J. Srba, and J. K. Wortmann, “CAAL: concurrencyworkbench, aalborg edition,” in Theoretical Aspects of Computing -ICTAC 2015 - 12th International Colloquium Cali, Colombia, October29-31, 2015, Proceedings, ser. Lecture Notes in Computer Science, vol.9399. Springer, 2015, pp. 573–582.

[19] E. M. Clarke, O. Grumberg, and D. Peled, Model checking. MIT Press,2001.

[20] F. Mercaldo, V. Nardone, A. Santone, and C. A. Visaggio, “Ransomwaresteals your phone. formal methods rescue it,” in Formal Techniquesfor Distributed Objects, Components, and Systems - 36th IFIP WG 6.1International Conference, FORTE 2016, Held as Part of the 11th In-ternational Federated Conference on Distributed Computing Techniques,DisCoTec 2016, Heraklion, Crete, Greece, June 6-9, 2016, Proceedings,ser. Lecture Notes in Computer Science, vol. 9688. Springer, 2016, pp.212–221.

[21] ——, “Download malware? no, thanks: how formal methods can blockupdate attacks,” in Proceedings of the 4th FME Workshop on FormalMethods in Software Engineering, FormaliSE@ICSE 2016, Austin, Texas,USA, May 15, 2016. ACM, 2016, pp. 22–28.

[22] D. Arp, M. Spreitzenbarth, M. Huebner, H. Gascon, and K. Rieck,“Drebin: Efficient and explainable detection of android malware in yourpocket,” in Proceedings of 21th Annual Network and Distributed SystemSecurity Symposium (NDSS), 2014.

[23] M. Spreitzenbarth, F. Echtler, T. Schreck, F. C. Freling, and J. Hoffmann,“Mobilesandbox: Looking deeper into android applications,” in 28thInternational ACM Symposium on Applied Computing (SAC), 2013.

[24] N. Andronio, S. Zanero, and F. Maggi, “Heldroid: Dissecting and detect-ing mobile ransomware,” in International Workshop on Recent Advancesin Intrusion Detection. Springer, 2015, pp. 382–404.

[25] Y. Zhou and X. Jiang, “Dissecting android malware: Characterizationand evolution,” in Proceedings of 33rd IEEE Symposium on Security andPrivacy (Oakland 2012), 2012.

[26] I. You and K. Yim, “Malware obfuscation techniques: A brief survey,”in Broadband, Wireless Computing, Communication and Applications

22

(BWCCA), 2010 International Conference on. IEEE, 2010, pp. 297–300.

[27] F. Mercaldo, V. Nardone, A. Santone, and C. A. Visaggio, “Downloadmalware? no, thanks: how formal methods can block update attacks,” inProceedings of the 4th FME Workshop on Formal Methods in SoftwareEngineering. ACM, 2016, pp. 22–28.

[28] F. Mercaldo, V. Nardone, and A. Santone, “Ransomware inside out,”in Availability, Reliability and Security (ARES), 2016 11th InternationalConference on. IEEE, 2016, pp. 628–637.

[29] F. Mercaldo, V. Nardone, A. Santone, and C. A. Visaggio, “Ransomwaresteals your phone. formal methods rescue it,” in International Conferenceon Formal Techniques for Distributed Objects, Components, and Systems.Springer, 2016, pp. 212–221.

[30] A. Cimitile, F. Martinelli, F. Mercaldo, V. Nardone, A. Santone, andG. Vaglini, “Model checking for mobile android malware evolution,” inFormal Methods in Software Engineering (FormaliSE), 2017 IEEE/ACM5th International FME Workshop on. IEEE, 2017, pp. 24–30.

[31] L. Li, D. Li, T. F. Bissyande, J. Klein, H. Cai, D. Lo, and Y. Le Traon,“On locating malicious code in piggybacked android apps,” Journal ofComputer Science and Technology, vol. 32, no. 6, pp. 1108–1124, 2017.

[32] S. Schrittwieser, S. Katzenbeisser, J. Kinder, G. Merzdovnik, and E. R.Weippl, “Protecting software through obfuscation: Can it keep pace withprogress in code analysis?” ACM Comput. Surv., vol. 49, no. 1, p. 4,2016. [Online]. Available: http://doi.acm.org/10.1145/2886012

[33] R. Barbuti, N. D. Francesco, A. Santone, and G. Vaglini, “Reducedmodels for efficient CCS verification,” Formal Methods in System Design,vol. 26, no. 3, pp. 319–350, 2005.

[34] V. Rastogi, Y. Chen, and X. Jiang, “Droidchameleon:evaluating androidanti-malware against transformation attacks,” in ACM Symposium onInformation, Computer and Communications Security, May 2013, pp.329–334.

[35] L. Li, T. F. Bissyande, D. Octeau, and J. Klein, “Droidra: Taming reflec-tion to support whole-program analysis of android apps,” in Proceedingsof the 25th International Symposium on Software Testing and Analysis.ACM, 2016, pp. 318–329.

[36] N. D. Francesco, A. Santone, and G. Vaglini, “A user-friendlyinterface to specify temporal properties of concurrent systems,” Inf.Sci., vol. 177, no. 1, pp. 299–311, 2007. [Online]. Available:https://doi.org/10.1016/j.ins.2006.03.008

[37] J. Kinder, S. Katzenbeisser, C. Schallhart, and H. Veith, “Detecting ma-licious code by model checking,” Detection of Intrusions and Malware,and Vulnerability Assessment, pp. 174–187, 2005.

[38] F. Song and T. Touili, “Efficient malware detection using model-checking,” FM 2012: Formal Methods, pp. 418–433, 2001.

[39] ——, “Pommade: Pushdown model-checking for malware detection,” inProceedings of the 2013 9th Joint Meeting on Foundations of SoftwareEngineering, 2013, pp. 607–610.

[40] ——, “Model-checking for android malware detection,” APLAS, pp.216–235, 2014.

[41] G. Jacob, E. Filiol, and H. Debar, “Formalization of viruses and malwarethrough process algebras,” in International Conference on Availability,Reliability and Security (ARES 2010), 2010, pp. 597–602.

[42] G. Bai, Q. Ye, Y. Wu, H. van der Merwe, J. Sun, Y. Liu, J. S. Dong, andW. Visser, “Towards model checking android applications,” IEEE Trans.Software Eng., 2017.

[43] P. Battista, F. Mercaldo, V. Nardone, A. Santone, and C. A. Visaggio,“Identification of android malware families with model checking,” inProceedings of the 2nd International Conference on Information SystemsSecurity and Privacy - Volume 1: ICISSP, 2016, pp. 542–547.

[44] G. Canfora, F. Mercaldo, and C. A. Visaggio, “An hmm andstructural entropy based detector for android malware,” Comput.Secur., vol. 61, no. C, pp. 1–18, Aug. 2016. [Online]. Available:http://dx.doi.org/10.1016/j.cose.2016.04.009

[45] A. Saracino, D. Sgandurra, G. Dini, and F. Martinelli, “Madam: Effectiveand efficient behavior-based android malware detection and prevention,”IEEE Transactions on Dependable and Secure Computing, 2016.

[46] K. Xu, Y. Li, and R. H. Deng, “Iccdetector: Icc-based malware detectionon android,” IEEE Transactions on Information Forensics and Security,vol. 11, no. 6, pp. 1252–1264, 2016.

[47] S. K. Dash, G. Suarez-Tangil, S. Khan, K. Tam, M. Ahmadi, J. Kinder,and L. Cavallaro, “Droidscribe: Classifying android malware based onruntime behavior,” in Security and Privacy Workshops (SPW), 2016IEEE. IEEE, 2016, pp. 252–261.

[48] S. Chen, M. Xue, Z. Tang, L. Xu, and H. Zhu, “Stormdroid: A streamin-glized machine learning-based system for detecting android malware,”in Proceedings of the 11th ACM on Asia Conference on Computer andCommunications Security. ACM, 2016, pp. 377–388.

[49] G. Suarez-Tangil, S. K. Dash, M. Ahmadi, J. Kinder, G. Giacinto, andL. Cavallaro, “Droidsieve: Fast and accurate classification of obfuscatedandroid malware,” in Proceedings of the Seventh ACM on Conference onData and Application Security and Privacy. ACM, 2017, pp. 309–320.

[50] R. Nix and J. Zhang, “Classification of android apps and malware usingdeep neural networks,” in 2017 International Joint Conference on NeuralNetworks (IJCNN), May 2017, pp. 1871–1878.

[51] D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden, J. Klein, andY. Le Traon, “Effective inter-component communication mapping in an-droid: An essential step towards holistic security analysis,” in Presentedas part of the 22nd USENIX Security Symposium (USENIX Security 13),2013, pp. 543–558.

[52] L. Li, A. Bartel, T. F. Bissyande, J. Klein, Y. Le Traon, S. Arzt,S. Rasthofer, E. Bodden, D. Octeau, and P. McDaniel, “Iccta: Detectinginter-component privacy leaks in android apps,” in Proceedings of the37th International Conference on Software Engineering-Volume 1. IEEEPress, 2015, pp. 280–291.

[53] W. Enck, P. Gilbert, S. Han, V. Tendulkar, B.-G. Chun, L. P. Cox,J. Jung, P. McDaniel, and A. N. Sheth, “Taintdroid: an information-flowtracking system for realtime privacy monitoring on smartphones,” ACMTransactions on Computer Systems (TOCS), vol. 32, no. 2, p. 5, 2014.

[54] L. Li, A. Bartel, J. Klein, and Y. Le Traon, “Automatically exploitingpotential component leaks in android applications,” in 2014 IEEE 13thInternational Conference on Trust, Security and Privacy in Computingand Communications. IEEE, 2014, pp. 388–397.

[55] K. O. Elish, D. Yao, and B. G. Ryder, “On the need of precise inter-appicc classification for detecting android malware collusions,” in Proceed-ings of IEEE mobile security technologies (MoST), in conjunction withthe IEEE symposium on security and privacy, 2015.

[56] G. Meng, Y. Xue, M. Chandramohan, A. Narayanan, Y. Liu, J. Zhang,and T. Chen, “Mystique: Evolving android malware for auditing anti-malware tools,” in Proceedings of the 11th ACM on Asia Conference onComputer and Communications Security, AsiaCCS 2016, Xi’an, China,May 30 - June 3, 2016. ACM, 2016, pp. 365–376.

Gerardo Canfora is a professor of computer sci-ence at the Faculty of Engineering of the Universityof Sannio, Italy. His research interests include soft-ware maintenance and evolution, security and privacy,empirical software engineering, and service-orientedcomputing. Canfora has authored over 200 researchpapers. He serves on the program and organizingcommittees of a number of international conferences.He was general chair of WCRE06 and CSMR03, andprogram co-chair of ICSE15, WETSoM12 and 10,ICSM01 and07, IWPSE05, CSMR04 and IWPC97.

Canfora is co-editor of the Journal of Software: Evolution and Processes (former:Journal of Software Maintenance, Research and Practice).

Fabio Martinelli received the M.Sc. degree from theUniversity of Pisa, Pisa, Italy, in 1994 and the Ph.D.degree from the University of Siena, Siena, Italy, in1999. He is currently a Senior Researcher with theInstitute of Informatics and Telematics of the ConsiglioNazionale delle Ricerche, Pisa, Italy, where he leadsthe Cyber Security Project. He has co-authored morethan 200 papers in international journals and con-ference or workshop proceedings. He is involved inseveral steering committees of international WGs orconferences and workshops. He manages research

and development projects on information and communication security. His mainresearch interests include security and privacy in distributed and mobile systemsand foundations of security and trust.

23

Francesco Mercaldo received his master degree incomputer engineering from the University of Sannio(Benevento, Italy), with a thesis in software testing.He obtained his Ph.D. in 2015 with a dissertation onmalware analysis using machine learning techniques.The research areas of Francesco are software test-ing, verification, and validation, with the emphasis onthe application of empirical methods. Currently, he isworking as post-doctoral researcher at the Istituto diInformatica e Telematica, Consiglio Nazionale delleRicerche (CNR) in Pisa (Italy). He is also involved

as lecturer in Database, Operating Systems (Bachelor Degree) and SoftwareSecurity (Master Degree) courses at the University of Molise (Italy).

Vittoria Nardone obtained the MsC in Computer En-gineering at the University of Sannio. Vittoria is a PhDstudent at the same University under the supervisionof Antonella Santone. Her current research is focusedon the application on formal verification methods, inparticular on the model checking technique. She ap-plies the following technique on the Android malwareanalysis environment in order to identify maliciousbehaviours.

Antonella Santone received the Laurea degree inComputer Science at the University of Pisa, Italy, inApril 1993. In September 1997 she received the Ph.D.degree in Computer Systems Engineering at the Di-partimento di Ingegneria della Informazione, Univer-sity of Pisa. She is an Associate Professor at theUniversity of Molise since September 2017. She hasbeen Assistant Professor at the University of Pisa fromNovember 1998 to October 2001. She has been anAssociate Professor at the Department of Engineeringof the University of Sannio from November 2001 to

August 2017. She was involved in several research activities and projects.Antonella Santone’s current research is focused on formal verification methods.Her research interests include formal description techniques, temporal logic,concurrent and distributed systems modelling, heuristic search, formal methodsin systems biology and in software security. She has written more than hundredpapers for international journals and conferences.

Corrado Aaron Visaggio obtained the PhD in com-puter engineering at University of Sannio (Italy). He isassistant professor of Software Security of the MsCin Computer Engineering at the University of Sannio,Italy. His research interests include: empirical soft-ware engineering, software security, and data privacy.He is author of more than 50 papers published oninternational journals, international and national con-ference’s proceedings, and books. He serves in manyprogram committees and editorial boards of interna-tional conferences and journals.