Intent Security Testing
An Approach to Testing the Intent-based Vulnerability of Android Components
S´ebastien Salva, Stassia R. Zafimiharisoa and Patrice Laurenc¸ot
LIMOS - UMR CNRS 6158, PRES Clermont-Ferrand University, Clermont-Ferrand, France
Keywords:
Security Testing, Android Applications, Model-based Testing.
Abstract:
The intent mechanism is a powerful feature of the Android platform that helps compose existing components
together to build a Mobile application. However, hackers can leverage the intent messaging to extract personal
data or to call components without credentials by sending malicious intents to components. This paper tackles
this issue by proposing a security testing method which aims at detecting whether the components of an
Android application are vulnerable to malicious intents. Our method takes Android projects and intent-based
vulnerabilities formally represented with models called vulnerability patterns. The originality of our approach
resides in the generation of partial specifications from configuration files and component codes to generate test
cases. A tool, called APSET, is presented and evaluated with experimentations on some Android applications.
1 INTRODUCTION
As mobile usage grows, so should security: this sen-
tence summarises well the conclusions of several re-
cent reports (Report, 2012) providing analyses in Mo-
bile threats. These reports accentuate the idea that
Mobile security continues to be a global issue, in-
dependently of the platform. Security testing repre-
sents the most valuable solution to detect vulnerabil-
ity flaws in Mobile systems and applications. In this
context, the latter are experimented with test cases
usually constructed by hands from known attacks or
vulnerabilities. Model-based testing is another ap-
proach that brings some advantages, e.g., the automa-
tisation of some steps or the definition of the confi-
dence level of the test.
Mobile security testing is a very large field that
depends on several different concepts such as threat
families, internal mechanisms provided by the Mobile
platform or more sophisticated concepts such as com-
position of software. This paper focuses on the An-
droid inter-component communication mechanism,
called intent, and describes an original testing method
to detect intent-based vulnerabilities. This vulnerabil-
ity family stems from the Android application struc-
ture: these applications consist of one or more core
components tied together by means of intents. The
intent concept is an inter-component communication
mechanism, used to call or launch another compo-
nent, e.g., an activity (a componentwhich represents a
single screen), or a service (component which can be
executed in background). Any component can freely
interact with other exposed components, for exam-
ple to request data. A malicious component can also
leverage the intent mechanism to send attacks. So
considered, the intent mechanism becomes an attack
vector (Chin et al., 2011).
Some works, relative to security vulnerabilities as-
sociated with intents, have been recently proposed in
the literature: Zhong et al. showed that pre-installed
Android applications receiving oriented intents can
re-delegate wrong permissions (Zhong et al., 2012).
Some tools have been developed to detect this issue.
However, these tools are not tailored to detect other
vulnerabilities. Jing et al. proposed a model-based
conformance testing framework for the Android plat-
form as well (Jing et al., 2012). Basic specifications
(only intent descriptions) are constructed from the
configuration files of a project. Test cases are gen-
erated, from these specifications, to check whether
intent-based properties hold. This approach lacks of
scalability though since the set of properties is based
on the intent functioning and cannot be upgraded. So,
testing the presence of new vulnerabilities being dis-
covered cannot be achieved with this method.
The security testing method, introduced in this pa-
per, aims at detecting whether components are vulner-
able to malicious intents. The notion of vulnerability
of a component is modelled with specialised IOSTSs
(input output Symbolic Transition Systems (Frantzen
355
Salva S., R. Zafimiharisoa S. and Laurençot P..
Intent Security Testing - An Approach to Testing the Intent-based Vulnerability of Android Components.
DOI: 10.5220/0004515203550362
In Proceedings of the 10th International Conference on Security and Cryptography (SECRYPT-2013), pages 355-362
ISBN: 978-989-8565-73-0
Copyright
c
 2013 SCITEPRESS (Science and Technology Publications, Lda.)

et al., 2005)) called vulnerabilities patterns. This for-
mal model leads to define vulnerabilities and finally
test verdicts without ambiguity. Then, from vulner-
ability patterns, our method performs both the auto-
matic test case generation and execution. The orig-
inality of this work resides in the test case genera-
tion. First, partial class diagrams and partial IOSTS
specifications are generated from component com-
piled classes and configuration files. These class dia-
grams and specifications are used to determine the na-
ture of each component and represent the functional
behaviours that should be observed from each com-
ponent after the receipt of an intent (in reference to
the Android documentation (Android, 2013)). These
items help refine and reduce the test case generation.
For instance, vulnerability patterns dedicated to Ac-
tivity components shall be only applied on the Activ-
ities of an application. IOSTS test cases are derived
from a combination of vulnerability patterns with par-
tial specifications.
The paper is structured as follows: Section 2 gives
IOSTS definitions and notations to be used through-
out the paper. Vulnerability patterns are defined in
Section 3. Finally, the testing methodology is de-
scribed in Section 4 and we conclude in Section 5.
2 MODEL DEFINITION AND
NOTATIONS
We shall consider the input/output Symbolic Transi-
tion Systems (IOSTS) model (Frantzen et al., 2005)
to generate partial specifications of Android compo-
nents and to express vulnerabilities. Below, we recall
the definition of an IOSTS extension, called IOSTS
suspension, which also expresses quiescence i.e., the
authorised deadlocks observed from a location. For
an IOSTS S, quiescence is modelled by a new ac-
tion !δ and an augmented IOSTS denoted S
δ
, obtained
by adding a self-loop labelled by !δ for each location
where no output action may be observed.
Definition 1 (IOSTS Suspension). A deterministic
IOSTS suspension S
δ
is a tuple < L,l0,V,V0, I,Λ,
→>, where:
• L is the finite set of locations, l0 the initial loca-
tion,
• V is the finite set of internal variables, I is the
finite set of parameters. We denote D
v
the domain
in which a variable v takes values. The internal
variables are initialised with the assignment V0
on V, which is assumed to be unique,
• Λ is the finite set of symbolic actions a(p), with
p = (p
1
,..., p
k
) a finite list of parameters in I
k
(k ∈
N), p is assumed unique. Λ = Λ
I
∪ Λ
O
∪ {!δ}: Λ
I
represents the set of input actions, (Λ
O
) the set of
output actions,
• → is the finite transition set. A transition
(l
i
,l
j
,a(p),G,A), from the location l
i
∈ L to l
j
∈
L, denoted l
i
a(p),G,A
−−−−−→ l
j
is labelled by an action
a(p) ∈ Λ. G is a guard over (p ∪ V ∪ T(p ∪ V))
which restricts the firing of the transition. T(p∪
V) is a set of functions that return boolean values
only (a.k.a. predicates) over p∪V. Internal vari-
ables are updated with the assignment function A
of the form (x := A
x
)
x∈V
A
x
is an expression over
V ∪ p ∪ T(p∪V)
• for any location l ∈ L and for all pair of tran-
sitions (l, l
1
,a(p),G
1
,A
1
), (l,l
2
,a(p),G
2
,A
2
) la-
belled by the same action, G
1
∧ G
2
is unsatisfi-
able.
An IOSTS is also associated to an ioLTS (In-
put/Output Labelled Transition System) to formulate
its semantics. Intuitively, the ioLTS semantics corre-
sponds to a valued automaton without symbolic vari-
able, which is often infinite: the ioLTS states are la-
belled by internal variable valuations while transitions
are labelled by actions and parameter valuations. The
semantics of an IOSTS S =< L,l0,V,V0, I,Λ,→> is
the ioLTS JSK =< Q, q
0
,
∑
,→> composed of valued
states in Q = L× D
V
, q
0
= (l0,V0) is the initial one,
∑
is the set of valued symbols and → is the transition
relation. The complete definition of ioLTS semantics
can be found in (Frantzen et al., 2005). For an IOSTS
transition l
1
a(p),G,A
−−−−−→ l
2
, we obtain an ioLTS transition
(l
1
,v)
a(p),θ
−−−→ (l
2
,v
′
) with v a set of valuations over
the internal variable set, if there exists a parameter
value set θ such that the guard G evaluates to true
with v ∪ θ. Once the transition is executed, the in-
ternal variables are assigned with v
′
derived from the
assignment A(v ∪ θ). Runs and traces of an IOSTS
can now be defined from its semantics:
Definition 2 (Runs and Traces). For an IOSTS S =
< L,l0,V,V0,I,Λ,→>, interpreted by its ioLTS se-
mantics JSK =< Q,q
0
,
∑
,→>, a run q
0
α
0
...α
n−1
q
n
is an alternate sequence of states and valued actions.
Run(S) = Run(JSK) is the set of runs found in JSK.
Run
F
(S) is the set of runs of S finished by a state in
F × D
V
⊆ Q, with F a location set in L.
It follows that a trace of a run r is defined as
the projection proj
∑
(r) on actions. Traces
F
(S) =
Traces
F
(JSK) is the set of traces of all runs finished
by states in F × D
V
.
Below, we recall the definition of the parallel com-
position which is a classical state-machine operation
used to represent the parallel execution of two sys-
SECRYPT2013-InternationalConferenceonSecurityandCryptography
356

tems. We give this definition for IOSTSs. However,
the same operation can be also applied between two
underlying ioLTS semantics. For IOSTSs, this paral-
lel execution illustrates shared behaviours of the two
original IOSTSs that are compatible:
Definition 3 (Compatible IOSTSs). An IOSTS S
1
=
< L
1
, l0
1
, V
1
,V0
1
, I
1
,Λ
1
,→
1
> is compatible with S
2
= < L
2
, l0
2
, V
2
,V0
2
,I
2
, Λ
2
,→
2
> iffV
1
∩V
2
=
/
0, Λ
I
1
=
Λ
I
2
, Λ
O
1
= Λ
O
2
and I
1
= I
2
.
Definition 4 (Parallel Composition ||). The
parallel composition of two compatible
IOSTSs S
1
,S
2
, denoted S
1
||S
2
, is the IOSTS
P =< L
P
,l0
P
,V
P
,V0
P
,I
P
,Λ
P
,→
P
> such that
V
P
= V
1
∪ V
2
, V0
P
= V0
1
∧ V0
2
, I
P
= I
1
∪ I
2
,
L
P
= L
1
× L
2
, l0
P
= (l0
1
,l0
2
), Λ
P
= Λ
1
∪ Λ
2
. The
transition set →
P
is the smallest set satisfying the
following inference rule:
l
1
a(p),G
1
,A
1
−−−−−−→
S
1
l
2
,l
′
1
a(p),G
2
,A
2
−−−−−−→
S
2
l
′
2
⊢ (l
1
,l
′
1
)
a(p),G
1
∧G
2
,A
1
∪A
2
−−−−−−−−−−−→
P
(l
2
,l
′
2
)
Lemma 1 (Parallel Composition Traces). If S
2
and S
1
are compatible then Traces
F
1
×F
2
(S
1
||S
2
) =
Traces
F
1
(S
1
) ∩ Traces
F
2
(S
2
), with F
1
⊆ L
S
1
, F
2
⊆
L
S
2
.
3 VULNERABILITY
MODELLING
3.1 Android Applications and Notations
In this Section, we define some notations to model
intent-based behaviours of Android components with
IOSTSs. Android applications are usually con-
structed over a set of components. A component be-
longs to one of the four basic types: Activities (user
interfaces) , Services (background processing), Con-
tent providers (SQLite database management) and
Broadcast receivers (broadcast message handling).
For readability, we essentially focus on Activities in
the paper.
The inter-component communication is
performed with intents. An intent, denoted
intent(a, d,c,t, ed) gathers: an action a which
has to be performed, a data d expressed as a URI,
and eventually a component category c, a type t
which specifies the MIME type of the intent data and
extra data ed representing additional data. Intents
are divided into two groups: explicit intents, which
explicitly target a component, and implicit intents
(the most generally ones) which let the Android
system choose the most appropriate component.
Both can be exploited by a malicious application to
send attacks to components since any component
may determine the list of available components at
runtime. As a consequence, we consider both implicit
and explicit intents in this work. The mapping of
an implicit intent to a component is expressed with
items called intent filters stored in Manifest files. A
Manifest file, is a part of any Android project and
specifies configuration information about the whole
application.
Intent actions have different purposes, e.g., the ac-
tion VIEW is called to display something, the action
PICK is called to choose an item and to return its URI
to the calling component. Hence, in reference to the
Android documentation (Android, 2013), the action
set, denoted ACT, is divided into categories to ease
the vulnerability and component modelling: the ac-
tion set ACT
r
gathers the actions requiring the receipt
of a response, ACT
nr
gathers the other actions. We
denote C, the set of predefined Android categories, T
the set of types.
Android components may raise exceptions that we
group into two categories: those raised by the An-
droid system on account of the crash of a component
and the other ones. This difference can be observed
while testing with our framework. This is modelled
with the actions !SystemExp and !ComponentExp re-
spectively.
Finally, Android components, called by intents,
produce different behaviours in reference to their
types. For instance, the Activity role has to display
screens (denoted !Display(Activity a)) with a response
message or not, while a service usually aims to return
a response only. To ease the writing of vulnerability
patterns, we denote AuthAct
type
the action set that can
be used with a type of component in accordance with
the Android documentation. For instance, for Activi-
ties AuthAct
Activity
= {?intent(a,d,c,t, ed),!δ,
!Display(A),!SystemExp, !ComponentExp}.
3.2 Vulnerability Patterns
We chose the IOSTS formalism to model vulnerabil-
ity patterns because it powerful enough and still user-
friendly to express intent vulnerabilities that do not re-
quire obligation, permission, and related concepts. In-
stead of defining the vulnerabilities of a specification,
which have to be written for each specification, we
prefer defining vulnerability patterns for describing
intent-based vulnerabilities in general terms. A vul-
nerability pattern is a specialised IOSTS suspension
composed of two distinct final locations Vul, NVul.
The latter aim to recognise the vulnerability status
over component executions: runs of a vulnerability
pattern starting from the initial location and ended by
IntentSecurityTesting-AnApproachtoTestingtheIntent-basedVulnerabilityofAndroidComponents
357

Figure 1: Vulnerability pattern for testing component avail-
ability.
Vul exhibit the presence of the vulnerability. By de-
duction, runs ended by NVul express functional be-
haviours which show the absence of the vulnerability.
Such patterns have to be composed with actions
which match one component type. For instance, if a
vulnerability pattern is dedicated to Activities, then its
action set must be equal to AuthAct
Activity
. Guards can
also be composed of specific predicates to ease their
writing. In the paper, we consider some predicates
such as in () which represents a Boolean function re-
turning true if the parameter belongs to a given value
set. In the same way, we consider several value sets
to categorise malicious values and attacks: RV is a set
of values known for relieving bugs enriched with ran-
dom values. Inj is a set gathering XML and SQL in-
jections constructed from database table URIs found
in the tested Android application. URI is a set of
randomly constructed URIs completed with the URIs
found in the tested Android application. New sets can
be also added upon condition that real value sets with
the same name would be added to the testing tool.
Definition 5 (Vulnerability Pattern). A Vulnerabil-
ity pattern is a deterministic IOSTS suspension
VP =< L
VP
,l0
VP
,V
VP
,V0
VP
,I
VP
,Λ
VP
,→>
VP
>
such that the final locations of L
VP
belong to
{Vul, NVul}. Λ
VP
= AuthAct
type
with type the com-
ponent type targeted by VP.
Figure 1 illustrates a straightforward example of
vulnerability pattern to test the Availability of An-
droid Activities. It describes that an Activity is un-
available and consequently vulnerable when quies-
cence is observed or when the Activity crashes, which
is observed when an exception is raised by the An-
droid system. The intent action belongs either to the
Android action set or in the RV(String) set which
stands for String values known for relieving bugs,
e.g., ”$” or ”;” and random values. The data d takes a
value either in URI or in RV(String) or in Inj.
Considering an IOSTS S compatible with a vul-
nerability pattern VP, the vulnerability status of S is
given when its suspension traces are recognisedby the
VP locations Vul and NVul:
Definition 6 (Vulnerability Status of an IOSTS). Let
S be an IOSTS, VP be a vulnerability pattern such
that S
δ
is compatible with VP. We define the vulnera-
bility status of S (and of its underlying ioLTS seman-
tics JSK) over VP with:
• S is not vulnerable to VP, denoted S |= VP if
Traces(S
δ
) ⊆ Traces
NVul
(VP),
• S is vulnerable to VP, denoted S 2 VP if
Traces(S
δ
) ∩Traces
Vul
(VP) 6=
/
0.
4 SECURITY TESTING
METHODOLOGY
The steps of our approach can be summarised as fol-
lows: we assume having a set of vulnerability pat-
terns modelled with IOSTS suspensions. From an
Android project (compiled classes and configuration
files), we extract a partial class diagram by introspec-
tion. This one lists the components, gives their types
and the associations between classes. Furthermore,
IOSTS suspensions expressing partial specifications
of one component, are extracted from the Manifest
file. Intermediate IOSTSs, called vulnerability prop-
erties, are then derived from the combination of vul-
nerability patterns with partial specifications. These
properties still express vulnerabilities but are refined
with the implicit and explicit intents that a compo-
nent may accept. Test cases are obtained by concretis-
ing vulnerability properties i.e., parameter values are
added to obtain executable test cases only. Finally,
the latter are translated into JUNIT test cases to be
executed with classical development tools. All these
steps are detailed below.
4.1 Model Generation
Android applications gather a lot of information that
can be used to produce partial models:
1. a simplified class diagram, depicting Android
components of the application and their types, is
initially computed. The component method and
attribute names are established by applying re-
verse engineering based on Java reflection. This
class diagram also gives some informations about
the relationships among components. This step
aims to later reduce the test case generation. For
instance, the verification of data vulnerabilities
has to be done on components tied with Con-
tent providers (specialized components managing
database). This relationship is established when a
component has a ContentResolver attribute,
SECRYPT2013-InternationalConferenceonSecurityandCryptography
358

2. one partial specification S
ct
= (S1
ct
,S2
ct
) is gen-
erated for each component found in the Android
application. S1
ct
is an IOSTS suspension com-
posed of the implicit intents given in the Manifest
file. In contrast, S2
ct
models any (explicit) intent
except the implicit ones. This separation shall be
particularly useful to distributethe test case set be-
tween implicit and explicit intents when the num-
ber of test cases is limited.
Algorithm 1 constructs a partial specification
S
ct
= (S1
ct
,S2
ct
) from the intent filters IntentFil-
ter(act,cat,data) found in a Manifest file. The ac-
tion sets of Λ
Si
ct
(i = 1, 2) are set to AuthAct
type(ct)
with type(ct) the type of the component, e.g.,
Activity. For readability, we present the algo-
rithm dedicated to Activities only. It produces two
IOSTSs w.r.t. the intent functioning described in
the Android documentation. Firstly, Algorithm 1
constructs S1
ct
with the implicit intents found in
the intent filters (lines 6-16). Depending on the
action type read, the guard of the output action is
completed to reflect the fact that a response may
be received or not. If the action of the intent fil-
ter is unknown (lines 12,13), no guard is formu-
lated on the output action (a response may be re-
ceived or not). While the generation of S1
ct
, the
algorithm also produces a guard G equals to the
negation of the union of guards added with the
?intent action (line 15). Then, S2
ct
is constructed
by means of this guard: it models the sending of
an intent with the guard G (intuitively, any intent
except the intents of S1
ct
) followed by a transition
carrying the action !Display without guard and a
transition labelled by !ComponentException.
Finally, both S1
ct
and S2
ct
are completed on the
output set to express incorrect behaviours mod-
elled with new transitions to the Fail location,
guarded by the negation of the union of guards
of the same output action on outgoing transitions
(lines 17-20). The new Fail location shall be par-
ticularly useful to refine the test verdict by help-
ing recognise correct and incorrect behaviours of
an Android component w.r.t. its specification.
For the other Android component types, the al-
gorithms are very similar.
Figure 2 illustrates a partial specification example
composed of implicit intents (S1
ct
). Two intents are
accepted by the component, one composed of the ac-
tion VIEW that is called to display information about
the first person in the contact list of the Mobile phone
and another action PICK which aims to ask the user
to choose a contact that is returned to the calling com-
ponent. Transitions to Fail represent undesired be-
haviours. For instance, after a PICK action, the res
Algorithm 1: Partial Specification Generation.
input : Manifest file MF
output: Partial specifications S
ct
= (S1
ct
,S2
ct
)
1 foreach component ct in MF do
2 it := 0;G :=
/
0;
3 S
ct
= (S1
ct
,S2
ct
) is a partial specification of ct /
Λ
Si
ct
(i = 1,2) = AuthAct
type(ct)
;
4 Add l0
Si
ct
!δ
−→
Si
ct
l0
Si
ct
to →
Si
ct
;(i = 1,2)
5 if type of ct == Activity then
6 foreach IntentFilter(act,cat,data) of ct in
MF do
7 it := it + 1 ;
8 if act ∈ ACT
r
then
9 Add l0
S1
ct
?evt
(1)
1
−−−→
S1
ct
(l
it,1
)
!di
(2)
1
,[ct.resp6=Null]
−−−−−−−−−−−−→ l0
S1
ct
to →
S1
ct
10 else if act ∈ ACT
nr
then
11 Add l0
S1
ct
?evt
(1)
1
−−−→
S1
ct
(l
it,1
)
!di
(2)
1
,[ct.resp=Null]
−−−−−−−−−−−−→ l0
S1
ct
to →
S1
ct
12 else
13 Add l0
S1
ct
?evt
(1)
1
−−−→
S1
ct
(l
it,1
)
!di
(2)
1
−−−→ l0
S1
ct
to →
S1
ct
14 Add (l
it,1
)
!ComponentExp
−−−−−−−−−→
S1
ct
l0
S1
ct
to
→
S1
ct
;
15 G := G∧ ¬G1;
16 Add
l0
S2
ct
?intent(a,d,c,v),G,A=(x:=x)
x∈V
S2
ct
−−−−−−−−−−−−−−−−−−−−→
S2
ct
l
1
!di
(2)
2
−−−→ l0
S2
ct
, l
1
!ComponentExp
−−−−−−−−−→
S2
ct
l0
S2
ct
to
→
S2
ct
;
17 foreach l
1
∈ L
Si
ct
(1 ≤ i ≤ 2) such that
l
1
!a,G,A
−−−−→
Si
ct
l
2
do
18 foreach a ∈ Λ
O
Si
ct
do
19 G
a
=
V
l
1
a(p),G,A
−−−−−→
Si
ct
l
¬G;
20 Add l
1
?a(p),G
a
,A
a
=(x:=x)
x∈V
−−−−−−−−−−−−−−→
Si
ct
Fail to →
Si
ct
21 (1) ?intent(a,d, c,v),G1 = [a = act ∧ d = data∧ c =
cat],A = (x := x)
x∈V
S1
ct
(2)!Display(Activity ct),A = (x := x)
x∈V
Si
ct
ponse must not be null.
4.2 Test Case Selection
A component under test (CUT) is regarded as a black
box whose interfaces are known only. However, one
usually assumes the following test hypotheses to per-
form the test case execution:
• the functional behaviours of the component un-
der test, observed while testing, can be modelled
IntentSecurityTesting-AnApproachtoTestingtheIntent-basedVulnerabilityofAndroidComponents
359

Figure 2: An Activity specification.
by an ioLTS CUT. CUT is unknown (and poten-
tially nondeterministic). CUT is assumed input-
enabled (it accepts any of its input actions from
any of its states). CUT
δ
denotes its ioLTS sus-
pension,
• to be able to dialog with CUT, one assumes that
CUT is a component whose type is the same as
the component type targeted by the vulnerability
pattern VP and that it is compatible with VP.
Test cases stem from the composition of vulnera-
bility patterns with compatible partial specifications.
Given a vulnerability pattern VP and a partial speci-
fication S
ct
= (S1
ct
,S2
ct
), the composition V(S
ct
) =
(VP||S1
ct
,VP||S2
ct
) is called a vulnerability property
of S
ct
. It represents the vulnerable and non-vulnerable
behaviours which may be observed from the compo-
nent with implicit or explicit intents. The parallel
compositions (VP||Si
ct
)(i = 1,2) produce new loca-
tions and in particular new final verdict locations:
Definition 7 (Verdict location sets). Let VP be a
vulnerability pattern and S
ct
= (S1
ct
,S2
ct
) a partial
specification with Si
ct
(i = 1,2) compatible with VP.
(VP||Si
ct
)(i = 1,2) are composed of new locations
recognising vulnerability status:
1. NVUL = NVul × L
Si
ct
. Particularly, NVUL/FAIL
= (NVul, Fail) ∈ NVUL aims to recognise incor-
rect behaviours w.r.t. the partial specification S
ct
and not vulnerable behaviours w.r.t. VP,
2. VUL = Vul × L
Si
ct
. Particularly, VUL/FAIL
= (Vul,Fail) aims to recognise incorrect be-
haviours w.r.t. S
ct
and vulnerable behaviours
w.r.t. VP.
Test cases are achieved with Algorithm 2 which
performs the two followingmain steps on each IOSTS
of the vulnerability property V(S
ct
) = (VP||S1
ct
,
VP||S2
ct
). Firstly, it splits (VP||Si
ct
) into several
IOSTSs. Intuitively, from a location l having k transi-
tions carrying an input action, e.g., an intent, k new
test cases are constructed to experiment CUT with
the k input actions and so on for each location l hav-
ing transitions labelled by input actions (lines 2-5).
Figure 3: A test case example.
Then, a set tuple of valuations is computed for the
list of undefined parameters of the input action (line
6). Instead of using a cartesian product to construct a
tuple of valuations, we adopted a Pairwise technique
(Cohen et al., 2003). Assuming that errors can be re-
vealed by modifying pairs of variables, this technique
strongly reduces the coverage of a variable domain by
constructing discrete combinations for pair of param-
eters only. The set of valuation tuples is constructed
with the Pairwise procedure which takes the list of
undefined parameters and the transition guard to find
the domain of each parameter. If no domain is found,
the RV set is used instead. In the second step (line
7-14), input actions are concretised, i.e. each unde-
fined parameter of an input action is assigned to a
value. Given a transition t and its set of valuation
tuples P(t), this step constructs a new test case for
each tuple pv = (p
1
= v
1
,..., p
n
= v
n
) by replacing
the guard G with G ∧ pv if G∧ pv is satisfiable. Fi-
nally, if the resulting IOSTS suspension tc has ver-
dict locations, then tc is added into the test case set
TC
(VP||Si
ct
)
. Steps 1. and 2. are iteratively applied
until each combination of transitions labelled by in-
put actions and each combination of valuation tuples
are covered. Since the algorithm may produce a large
set of test cases, the algorithm also ends when the
test case set TC
(VP||Si
ct
)
reaches a cardinality of tcnb
(lines 18,19). This condition limits the test case num-
ber but also allows balancing the generation of test
cases build with implicit intents (those obtained from
S1
ct
) with the test cases executing explicit intents (ob-
tained from S2
ct
).
A test case example is depicted in Figure 3. It
originates from the IOSTS suspension S1
ct
of Figure
2 and expresses the sending of an intent with the ex-
tra data part composed of an SQL injection. In other
terms, it illustrates the call of the component under
test with a malicious intent composed of the classi-
cal SQL injection ”’or 1=1–”. Other test cases are
also generated from S2
ct
to send intents composed of
malicious actions, categories, etc.
The test cases, constructed with Algorithm 2, are
composed of paths of a vulnerability property,starting
from its initial locations and whose transitions are
SECRYPT2013-InternationalConferenceonSecurityandCryptography
360

Algorithm 2: Test case generation.
input : A vulnerability property V(S
ct
), tcnb the
maximal number of test cases
output: Test case set TC
1 foreach (VP||Si
ct
)(i = 1,2) ∈ V(S
ct
) do
2 begin 1. input action choice
3 foreach location l having outgoing
transitions carrying input actions do
4 Choose a transition
t = l
?a(p),G,A
−−−−−−→
(VP||Si
ct
)
l
2
;
5 remove the other transitions labelled by
input actions;
6 P(t) = Pairwise(p
1
,..., p
n
,G) with
(p
1
,..., p
n
) ⊆ p the list of undefined
parameters;
7 begin 2. input concretisation
8 foreach t = l
?a(p),G,A
−−−−−−→
(VP||Si
ct
)
l
2
do
9 Choose a valuation tuple
pv = (p
1
= v
1
,..., p
n
= v
n
) in P(t);
10 if G∧ pv is satisfiable then
11 Replace G by G∧ pv in t;
12 else
13 Choose another valuation tuple in
P(t);
14 tc is the resulting IOSTS suspension;
15 begin 3.
16 if tc has reachable verdict locations then
17 TC
(VP||Si
ct
)
:= TC
(VP||Si
ct
)
∪ {tc} ;
18 if Card(TC
(VP||Si
ct
)
) ≥ tcnb then
19 STOP;
20 Repeat 1. and 2. until each combination of
transitions carrying input actions and each
combination of valuation tuples are covered;
21 TC =
[
i=1,2
TC
(VP||Si
ct
)
;
concretised with values that meet the original guards.
In other words, the test selection algorithm does not
add new traces leading to verdict locations. Hence,
one can deduce that the test case traces belong to the
trace set of the vulnerability property:
Proposition 8. LetV(S
ct
) be a vulnerability property
derived from the composition of a vulnerability pat-
tern VP and a partial specification S
ct
= (S1
ct
,S2
ct
).
TC is the test case set generated by Algorithm 2.
We have ∀tc ∈ TC, Traces(tc) ⊆ (Traces(VP||S1
ct
)∪
Traces(VP||S2
ct
)).
4.3 Test Case Execution Definition
The test case execution is usually defined by the par-
allel composition of the test cases with the implemen-
tation CUT:
Proposition 9 (Test case execution). Let TC be a test
case set obtained from the vulnerability pattern VP.
CUT is the ioLTS of the component under test, as-
sumed compatible with VP. For all test case tc ∈ TC,
the execution of tc on CUT is defined by the parallel
composition tc||CUT
δ
.
The above proposition leads to the test verdict of
a component under test against a vulnerability pattern
VP. Intuitively, this one refers to the Vulnerability
status definition, completed by the detection of incor-
rect behaviours described in the partial specification
of the component with the verdict locations VUL/-
FAIL and NVUL/FAIL. An inconclusive verdict is also
defined when a verdict location has not been reached
after a test case execution:
Definition 10 (Test verdict). We take back the nota-
tions of Proposition 9. The execution of the test case
set TC on CUT yields one of the following verdicts:
• CUT is vulnerable to VP iff ∃tc ∈ TC, tc||CUT
produces a trace σ such that σ is also a
trace of Traces
VUL
(tc). If σ is a trace of
Traces
VUL/FAIL
(tc) then CUT does not also re-
spect the component normal functioning,
• CUT is not vulnerable to VP iff ∀tc ∈ TC,
tc||CUT produces a trace σ such that σ is also
a trace of Traces
NVUL
(tc). However, if σ is a
trace of Traces
NVUL/FAIL
(tc) then CUT does not
respect the component normal functioning,
• CUT has an unknown status iff ∃tc∈ TC,tc||CUT
produces a trace σ such that σ /∈ Traces
VUL
(tc) ∪
Traces
NVUL
(tc).
The above security testing method has been im-
plemented in a tool called APSET (Android aPpli-
cations SEcurity Testing), publicly available in a
Github repository
1
. It takes an Android application
project (uncompressed APK) and vulnerability pat-
terns, builds IOSTS specifications and generates JU-
NIT test cases. Then, it executes them on Android
emulators or devices and displays the final verdicts.
The guard solving, used in Algorithm 2 and during the
test case execution, is performed by the SMT (Satisfi-
ability Modulo Theories) solver Z3
2
, whose language
is augmented with the predicates given in Section 3.
We experimented several real Android applica-
tions provided by the Openium company
3
. Table ??
summarises the results obtained on 10 applications
with two vulnerability patterns: VP1 is the one of
Figure 1, VP2 is a vulnerability pattern dedicated to
1
https://github.com/statops/apset.git
2
http://z3.codeplex.com/
3
http://www.openium.fr/
IntentSecurityTesting-AnApproachtoTestingtheIntent-basedVulnerabilityofAndroidComponents
361

Table 1: Experimentation Results.
Applications VP1 test results VP2 test results
App # com-
ponent
Time/
test
#vul/
#testcases
Time/
test
#vul/#
testcases
app 1 35 8s 861/969 0.7s 0/175
app 2 6 12s 95/147 0.25s 7/60
app 3 5 4s 0/117 - -
app 4 24 0.15s 52/545 - -
app 5 11 2s 3/33 0.175s 7/77
app 6 11 3s 11/120 - -
app 7 11 3s 20/110 - -
app 8 11 3s 20/110 - -
app 9 13 0.90s 19/80 - -
app 10 15 2.1s 15/105 1.6s 31/105
integrity testing. Intuitively, this one aims at check-
ing whether stored data can be modified with mali-
cious intents: initially, a set of structured data, man-
aged by a Content Provider, are stored. Then, all the
components (Service or Activity) composed with this
Content provider, are called with malicious intents
composed of SQL and XML injections. Finally, the
Content Provider state is requested to check if it has
been modified without having any user or administra-
tor credentials.
For each application and each vulnerability pat-
tern, we provide, the number of tested components,
the average test case execution time delay, and the
number of vulnerability issues detected over the test
case number. With VP1, all the tested applications
revealed vulnerability issues. For instance, 969 test
cases were generated by our tool for app 1 and 861
revealed issues. Obviously, several vulnerable ver-
dicts were obtained on account of the same vulner-
ability in the component code. All these issues were
essentially observed by component crashes when re-
ceiving malicious intents (receipt of exceptions such
as NullPointerException). With VP2, tests were only
applied on the applications whose generated class dia-
grams reveal at least one Content Provider component
(applications 1, 2, 5 and 10). We detected some data
integrity issues with app 5 and app 10. In particu-
lar, the test reports showed that the modifications of
data were detected with app 5 and the deletion of data
with app 10 without providing login credentials with
the intents.
5 CONCLUSIONS
We have presented a security testing method of An-
droid applications for testing whether components are
vulnerable to malicious intents. The originality of this
work resides in the intent mechanism security test-
ing first, but also in the automatic generation of par-
tial specifications from Android Manifest files. These
specifications are used to generate test cases com-
posed of either implicit or explicit intents. They also
contribute to complete the test verdict with the spe-
cific verdicts NVUL/FAIL and VUL/FAIL, pointing
out that the component under test does not meet the
recommendations provided in the Android documen-
tation. In future works, we intend to perform other
experimentations with further vulnerability patterns
based on the Authorisation concept.
REFERENCES
Android, D. (2013). Android developer’s guide. In http://
developer.android.com/index.html, last accessed feb
2013.
Chin, E., Felt, A. P., Greenwood, K., and Wagner, D.
(2011). Analyzing inter-application communication in
android. In Proceedings of the 9th international con-
ference on Mobile systems, applications, and services,
pages 239–252.
Cohen, M. B., Gibbons, P. B., Mugridge, W. B., and Col-
bourn, C. J. (2003). Constructing test suites for in-
teraction testing. In Proc. of the 25th International
Conference on Software Engineering, pages 38–48.
Frantzen, L., Tretmans, J., and Willemse, T. (2005). Test
Generation Based on Symbolic Specifications. In
Grabowski, J. and Nielsen, B., editors, FATES 2004,
number 3395 in Lecture Notes in Computer Science,
pages 1–15. Springer.
Jing, Y., Ahn, G.-J., and Hu, H. (2012). Model-based con-
formance testing for android. In Hanaoka, G. and Ya-
mauchi, T., editors, Proceedings of the 7th Interna-
tional Workshop on Security (IWSEC), volume 7631
of Lecture Notes in Computer Science, pages 1–18.
Springer.
Report (2012). It business: Android security. In http://
www.itbusinessedge.com/cm/blogs/weinschenk/
google-must-deal-with-android-security-problems-
quickly/?cs=49291, , last accessed feb 2013.
Zhong, J., Huang, J., and Liang, B. (2012). Android permis-
sion re-delegation detection and test case generation.
In Computer Science Service System (CSSS), 2012 In-
ternational Conference on, pages 871 –874.
SECRYPT2013-InternationalConferenceonSecurityandCryptography
362