Software Model Checking: A Promising Approach to Verify Mobile App Security

Software Model Checking:
A Promising Approach to Verify Mobile App Security

– A Position Paper –
Irina Măriuca Asăvoae INRIA, Paris, France Hoang Nga Nguyen Coventry University, Coventry, UK Markus Roggenbach Swansea University, Swansea, UK  and  Siraj Ahmed Shaikh Coventry University, Coventry, UK

In this position paper we advocate software model checking as a technique suitable for security analysis of mobile apps. Our recommendation is based on promising results that we achieved on analysing app collusion in the context of the Android operating system. Broadly speaking, app collusion appears when, in performing a threat, several apps are working together, i.e., they exchange information which they could not obtain on their own. In this context, we developed the -Android tool, which provides an encoding of the Android/Smali code semantics within the  framework. -Android allows for software model checking of Android APK files. Though our experience so far is limited to collusion, we believe the approach to be applicable to further security properties as well as other mobile operating systems.

Software Model Checking, Android, Collusion, Mobile Security
copyright: rightsretainedconference: Formal Techniques for Java-like Programs; June 2017; Barcelona, Spainjournalyear: 2017

1. Introduction

We advocate as a promising research direction: applying software model checking to Android apps for formal security analysis. This uses abstract model checking, which is an abstract interpretation technique. Here, we have already achieved a number of explorative results. These include: defining and experimenting with two executable semantics on the byte-code level, one concrete and one abstract. Both of them have been implemented in the -Android tool (Asavoae et al., 2016; Kandroid ACID Team, 2017), utilising the  framework (Roşu and Şerbănuţă, 2010) where Java/JVM semantics had already been defined (Bogdanas and Rosu, 2015). Our work targets however the byte-code level and Android operating system (ART/Dalvik); the work-flow of -Android is described in Fig. 1. Currently we are pioneering (w.r.t. the formal executable semantics for a virtual machine targeted by Java) a formal proof utilizing a simulation relation that these two semantics are in a sound relation.

In the followings we discuss a number of decisions underlying the suggested approach, give a brief status report on our research, and conclude by providing some insights that we gained.

Related work: Our work is closest to static analysis tools that detect security properties in Android. For example, the tool FlowDroid (Arzt et al., 2014) uses taint analysis to find connections between source and sink. The app inter-component communication pattern is subsequently analysed using a composite constant propagation technique (Octeau et al., 2016). We propose a similar approach, namely to track (sensitive) information flow and to detect app communication, but using model checking that gives witness traces in case of collusion detection. From the proof effort perspective, we mention CompCert (Leroy, 2009) that uses Coq theorem prover to validate a C compiler. Also, an up-to-date survey on app collusion in Android can be found in (Bhandari et al., 2016).

Figure 1. Work-flow for model checking with the framework.

2. Decisions

When setting up our framework for software model checking, we took a number of decisions that we conceive to be fundamental:

Verify byte-code rather than high level language programs

When considering the language level, the input language of the virtual machine appears to be the right level for investigating security properties. Users download their apps as APKs hence this needs to be the starting point for our investigation. Decompiling APKs is a possibility however not 100% successful. A further advantage is that a language such as Smali, which was designed to run on a Virtual Machine, is far less complex than a high-level language such as Java. Finally, Smali programs are independent of compiler optimisations: verification addressing specific Java constructs might fail on the byte code level as compiler optimisations might interfere.

Offer two semantics: a concrete and an abstract one

We believe it to be essential to work with two different semantics. Objectives of formulating a concrete semantics include:


To be close to the informal description of the language instructions to ease modelling. For Android these are Smali instructions as specified on the Android Project website (Android Open Source Project, 2016).


To work with actual values as much as possible: this allows to experiment with small example programs in order to validate the given semantics. Note that the  framework allows for executable specifications.

Objectives of formulating an abstract semantics include:


To enable effective model checking by selecting suitable abstraction principles. In -Android we have chosen:

  • virtual unrolling: this leads to finite flows (Martin et al., 1998);

  • memory abstraction: to reduce the state space (Arnold et al., 2006);

  • constant propagation: this abstracts from concrete values and thus also helps in reducing the state space (Kinder et al., 2009).


To be sound w.r.t. the security property under discussion, in our case: collusion.

Provide a soundness proof

In order to certify the correctness of the overall approach, a soundness proof is needed. Though the effort required in carrying out such a proof might appear as a high price to pay, the overall setup has a number of advantages:

  • The proof is done once; the savings of the abstract semantics in time and space apply every time model checking is carried out; moreover, the proof is re-usable as it is structured according to classes of Smali instructions – even when changing the property, the abstract semantics for some of these classes would stay the same.

  • Working with a single semantics confuses objectives, namely to be true to the informal descriptions (c.f. C-O1 and C-O2) and, at the same time to be effective (c.f. A-O1). This confusion might compromise the overall objective of providing a reliable analysis tool (c.f. A-O2).

3. Current Status of our work

Figure 2. Semantic module structure.

In our tool -Android (Asavoae et al., 2016; Kandroid ACID Team, 2017), we implement experimental versions of a concrete and an abstract semantics, which both cover the whole Smali language–see Figure 2 for the chosen module structure. We have successfully applied our tool to a number of Android apps to analyse them for collusion. Here, the counter-example traces provided by the model checking give good guidance for the code-analysis that distinguishes between collusion and false positives.

Our correctness proof is ”well on its way”–we covered the core constructs, e.g., method calls and returns. Although the sheer number of cases to consider (Smali has about 220 instructions) makes the proof time consuming, we classified the instructions in about 20 groups that share a similar build. This modularisation provides the proof with flexibility and reusability characteristics.

4. First insights

Concerning the question if it would be possible to directly build a suitable abstract semantics, our experience suggests that the two step approach including a proof is a necessity. In our ongoing proof, we learned that in some cases our originally implemented semantics went wrong. Reflecting on the abstraction via a formal simulation relation helped us to find the correct semantic clauses.

Concerning the applicability of our approach, experiments with our concrete and abstract semantics indicate that, provided an astute abstraction, software model checking for security is feasible and might even scale even for demanding properties as collusion.

5. Conclusion

Our ongoing work demonstrates that software model checking is a viable technique for analysing mobile apps for security. Verification times are below a minute for small examples consisting of about 5K lines of Smali code. The concrete semantics provided as well as the abstraction principles applied can be re-used to investigate further security properties. Though -Android is tailored to the Android operating system, the concepts in other mobile operating systems such as Symbian, MeeGo, iOS, Android, Tizen, etc. appear to be similar enough that it should be possible to apply software model checking also in their context. Compared to the predominant static analysis methods traditionally applied in mobile security verification, especially the possibility to obtain counter-example traces makes software model checking a promising approach.


  • (1)
  • Android Open Source Project (2016) Android Open Source Project. 2016. Dalvik Bytecode. (2016).
  • Arnold et al. (2006) Gilad Arnold, Roman Manevich, Mooly Sagiv, and Ran Shaham. 2006. Combining Shape Analyses by Intersecting Abstractions. In VMCAI 2006 (Lecture Notes in Computer Science), Vol. 3855. Springer, 33–48.
  • Arzt et al. (2014) Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bartel, Jacques Klein, Yves Le Traon, Damien Octeau, and Patrick McDaniel. 2014. FlowDroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for Android apps. In ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI ’14, Edinburgh, United Kingdom - June 09 - 11, 2014. ACM, 29.
  • Asavoae et al. (2016) Irina Mariuca Asavoae, Hoang Nga Nguyen, Markus Roggenbach, and Siraj Ahmed Shaikh. 2016. Utilising K Semantics for Collusion Detection in Android Applications. In FMICS-AVoCS 2016 (Lecture Notes in Computer Science), Vol. 9933. Springer, 142–149.
  • Bhandari et al. (2016) Shweta Bhandari, Wafa Ben Jaballah, Vineeta Jain, Vijay Laxmi, Akka Zemmari, Manoj Singh Gaur, and Mauro Conti. 2016. Android App Collusion Threat and Mitigation Techniques. CoRR abs/1611.10076 (2016).
  • Bogdanas and Rosu (2015) Denis Bogdanas and Grigore Rosu. 2015. K-Java: A Complete Semantics of Java. In POPL 2015. ACM, 445–456.
  • Kandroid ACID Team (2017) Kandroid ACID Team. 2017. Kandroid Tool. (2017).
  • Kinder et al. (2009) Johannes Kinder, Florian Zuleger, and Helmut Veith. 2009. An Abstract Interpretation-Based Framework for Control Flow Reconstruction from Binaries. In VMCAI 2009 (Lecture Notes in Computer Science), Vol. 5403. Springer, 214–228.
  • Leroy (2009) Xavier Leroy. 2009. Formal verification of a realistic compiler. Commun. ACM 52, 7 (2009), 107–115.
  • Martin et al. (1998) Florian Martin, Martin Alt, Reinhard Wilhelm, and Christian Ferdinand. 1998. Analysis of Loops. In Compiler Construction, 7th International Conference in ETAPS’98 (Lecture Notes in Computer Science), Vol. 1383. Springer, 80–94.
  • Octeau et al. (2016) Damien Octeau, Daniel Luchaup, Somesh Jha, and Patrick D. McDaniel. 2016. Composite Constant Propagation and its Application to Android Program Analysis. IEEE Trans. Software Eng. 42, 11 (2016), 999–1014.
  • Roşu and Şerbănuţă (2010) Grigore Roşu and Traian Florin Şerbănuţă. 2010. An Overview of the K Semantic Framework. Journal of Logic and Algebraic Programming 79, 6 (2010), 397–434.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description