towards secure smartphones

Fakultät für

Elektrotechnik und

Informationstechnik

From Mobile to SecurityTowards Secure Smartphones

Dissertation

zur Erlangung des Grades eines Doktor-Ingenieursder Fakultät für Elektrotechnik und Informationstechnik

an der Ruhr-Universität Bochum

vorgelegt von

Johannes Hoffmannaus Herdecke

Bochum, 30. 09. 2014

Erstgutachter: Prof. Dr. Thorsten Holz» Ruhr-Universität Bochum

Zweitgutachter: Prof. Dr. Felix C. Freiling» Friedrich-Alexander-Universität Erlangen-Nürnberg

Fakultät für

Elektrotechnik und

Informationstechnik

From Mobile to SecurityTowards Secure Smartphones

Dissertation

zur Erlangung des Grades eines Doktor-Ingenieursder Fakultät für Elektrotechnik und Informationstechnik

an der Ruhr-Universität Bochum

vorgelegt von

Johannes Hoffmannaus Herdecke

Bochum, 30. 09. 2014

Tag der mündlichen Prüfung: 28. 08. 2014

Erstgutachter: Prof. Dr. Thorsten Holz» Ruhr-Universität Bochum

Zweitgutachter: Prof. Dr. Felix C. Freiling» Friedrich-Alexander-Universität Erlangen-Nürnberg

Quis custodiet ipsos custodes?D. Iunius Iuvenalis

This thesis was typeset with LATEX, KOMA-Script and Kile.

Abstract

This thesis addresses problems in the research field of mobile security—a field of in-creasing importance since the introduction of the first smartphones in 2007. Nowa-days, smartphones are commonly used, and because of their rich feature set alwaysonline, easily extensible with third-party applications, and usable for many tasks.Just like normal computers, they are complex systems of hard- and software process-ing vast amounts of data. Depending on the use cases, this may include private userdata such as contact information or pictures, company secrets, as well as accountcredentials and payment information.

A lack of knowledge related to security-sensitive tasks of most users and securityrelated bugs in software provide evildoers with many attack vectors. Their goalscan be diverse, but typically they steal data or misuse premium rate services at theusers’ expense. The last years have shown that many pressing issues related to mobilesecurity remain unsolved and must be addressed. The popularity of smartphonesand their diversity make them not only attractive for their users, but also a targetfor cybercriminals.

In this thesis, we approach a selection of these problems and provide proper solutions.We start our work with a thorough introduction of the research field of mobilesecurity and emphasize its relevance. We point out that we need proper techniquesto analyze malicious mobile applications. Therefore, we present a static programanalysis tool which performs a technique called program slicing. We analyze morethan 140,000 mobile applications and present many differences between benign andmalicious applications. Next to our static approach, we present work in the dynamicprogram analysis field and evaluate whether (malicious) activities can be detectedbased on the energy consumption they cause on mobile devices. Following these twocontributions to analyze mobile applications, we evaluate how robust state-of-the-art analysis tools are against advanced and highly obfuscated malware. We presenta framework which obfuscates mobile applications and then test the effectiveness ofwell known tools against such altered applications. In a final step, we propose atool which enables the usage of web browser on compromised machines while usedcredentials or other security relevant data is protected from attackers. We make useof the smartphone’s connectivity and link it to other computer systems in order tostrengthen their security.

i

Zusammenfassung

Diese Dissertation widmet sich dem ForschungsthemaMobile Sicherheit, welches seitder Einführung der ersten Smartphones im Jahr 2007 immer relevanter wird. Smart-phones sind sehr weit verbreitet und dank ihrer üppigen Ausstattung an Sensorenund Netzwerkkomponenten immer online und durch einfach installierbare Applika-tionen für fast jeden Anwendungsfall nutzbar. Sie sind wie übliche Computer einkomplexes Gebilde aus Hard- und Software, die gewaltige Datenmengen verarbeiten.Zu diesen Daten gehören unter anderen – je nach Anwendungsfall – private Datendes Benutzers wie Kontaktdaten und Fotos, Firmendaten des Arbeitgebers sowieBenutzerkontendaten und hinterlegte Bezahloptionen.

Ein mangelndes Verständnis der meisten Benutzer bezüglich sicherheitsrelevanterFragestellungen und Sicherheitslücken in der Software, welche oft der Komplexitätder Smartphones geschuldet sind, bieten Angreifern viele Angriffsvektoren. DerenZiele können ganz unterschiedlich sein, oft wird jedoch Datenklau betrieben oderkostenpflichtige Mehrwertdienste werden zu Lasten des Besitzers ausgenutzt. Dieletzten Jahre haben gezeigt, dass es im Bereich der mobilen Sicherheit viele ungelösteProbleme gibt und entsprechende Lösungen benötigt werden. Die explosionsartigeVerbreitung von Smartphones und deren Potential machen diese nicht nur für derenBenutzer interessant, sondern auch zum Ziel von Cyberkriminalität.

Im Rahmen dieser Dissertation nehmen wir uns einige dieser Probleme an. Wirstellen zunächst das Forschungsfeld der mobilen Sicherheit vor und verdeutlichendessen Relevanz. Hierbei zeigen wir, dass Techniken zur Programmanalyse drin-gend benötigt werden um Schadsoftware zu analysieren. Infolgedessen stellen wirArbeiten im Rahmen der statischen Schadsoftwareanalyse vor, in welcher wir über140.000 Applikationen u. a. mittels der Technik Program Slicing untersuchen undviele Erkenntnisse über Schadsoftware präsentieren. Im Rahmen der dynamisch-en Programmanalyse untersuchen wir, inwieweit sich Software auf mobilen Gerätenmittels ihres Stromverbrauches erkennen lässt. Zudem evaluieren wir, wie robust be-kannte und oft genutzte Analysesysteme gegenüber stark obfuskierter Schadsoftwaresind. Wir präsentieren diesbezüglich eine Applikation, welche die Instruktionen mo-biler Applikationen entsprechend ändert. Abschließend stellen wir ein System vor,welches die Webnutzung auf einem kompromittierten PC ermöglicht. Hierzu nutzenwir die Konnektivität von Smartphones aus, um diese mit anderen Computersyste-men zu verbinden und so deren Sicherheit zu erhöhen.

iii

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Topic and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 List of Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background: From Mobile to Security 92.1 Why Mobile Security? . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Smartphone Characteristics . . . . . . . . . . . . . . . . . . . 182.1.2 Smartphone Security Mechanisms . . . . . . . . . . . . . . . 222.1.3 Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.4 Mobile Malware . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2 Analysis of Malicious Software . . . . . . . . . . . . . . . . . . . . . 342.2.1 Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.2 Dynamic Analysis . . . . . . . . . . . . . . . . . . . . . . . . 362.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3 Specific Security Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 382.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Static Approach based on Program Slicing 433.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3 High-Level Overview of SAAF . . . . . . . . . . . . . . . . . . . . . . 473.4 Static Backtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

v

3.4.1 General Workflow . . . . . . . . . . . . . . . . . . . . . . . . 513.4.2 Program Slicing . . . . . . . . . . . . . . . . . . . . . . . . . 513.4.3 Opcode Handling . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.5.1 Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . 593.5.2 Malware Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4 Dynamic Approach based on Power Consumption 714.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.3 Measurement Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.3.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.3.2 Test Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.4 Short Time Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.4.1 Initial Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.4.2 Energy Greedy Functions . . . . . . . . . . . . . . . . . . . . 814.4.3 Location API . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.4.4 Data Heist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.5 Long Time Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.5.1 Initial Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.5.2 Energy Greedy Functions . . . . . . . . . . . . . . . . . . . . 874.5.3 Location API . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.5.4 Data Heist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.5.5 Uncalibrated Phones . . . . . . . . . . . . . . . . . . . . . . . 89

4.6 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5 Change of Ends: Obfuscating Android Applications 975.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.2.1 Android Application Analyzers . . . . . . . . . . . . . . . . . 1005.2.2 Android Obfuscators . . . . . . . . . . . . . . . . . . . . . . . 106

5.3 Program Analysis Assumptions & Obfuscation Methods . . . . . . . 1075.3.1 Dynamic Analysis Evasion . . . . . . . . . . . . . . . . . . . . 1085.3.2 Static Analysis Evasion . . . . . . . . . . . . . . . . . . . . . 110

5.4 Evaluating the Robustness of Analysis Tools . . . . . . . . . . . . . . 1145.4.1 Static Analysis Systems . . . . . . . . . . . . . . . . . . . . . 115

vi

5.4.2 Dynamic Analysis Systems . . . . . . . . . . . . . . . . . . . 1165.4.3 Decompilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.4.4 Signatures & Antivirus Detection . . . . . . . . . . . . . . . . 1235.4.5 Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5.5 Implementation and Performance Evaluation . . . . . . . . . . . . . 1285.5.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 1285.5.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.5.3 Skipped Obfuscation Steps . . . . . . . . . . . . . . . . . . . 130

5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6 Enhancing Other Devices’ Security with SmartProxy 1356.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.3 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6.3.1 Attacker Model . . . . . . . . . . . . . . . . . . . . . . . . . . 1406.3.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426.4.1 Application Overview . . . . . . . . . . . . . . . . . . . . . . 1436.4.2 Communication Modes . . . . . . . . . . . . . . . . . . . . . . 1446.4.3 Proxy Workflow . . . . . . . . . . . . . . . . . . . . . . . . . 1456.4.4 Man-In-The-Middle Attack . . . . . . . . . . . . . . . . . . . 1476.4.5 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496.4.6 Personal Data Encryption . . . . . . . . . . . . . . . . . . . . 151

6.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526.5.1 Synthetic Benchmarks . . . . . . . . . . . . . . . . . . . . . . 1526.5.2 Real-World Benchmarks . . . . . . . . . . . . . . . . . . . . . 155

6.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

7 Summary and Conclusion 161

List of Figures 167

List of Tables 169

Listings 171

Bibliography 173

Curriculum Vitae 195

vii

1Introduction

In this thesis, we present our work in the field of mobile security and how we con-tributed to enhance the security of mobile devices, in particular smartphones. Webegin with a motivation why mobile security is an important research field andwhere problems surface. Thereafter we provide details about our contributions andthe specific fields we worked on. We then provide a list of all publications the authorwas involved in during his PhD studies and close this first chapter with an outlineof the remainder of this thesis.

1.1 Motivation

The first smartphones were introduced in 2007 by Apple and Google and since thensmartphones have become almost ubiquitous in the modern world. They are offeredin many varieties and are affordable by many people. The features they offer makethem great helpers for private daily tasks as well as for business tasks. Smartphonesare well connected and can be online all the time, offering up-to-date informationaround the clock whilst also providing the possibility to send arbitrary informationto almost anyone at the same time. They have the computational power normalPCs had a decade ago but fit into everyones pocket.

Their popularity is also caused by vendors who make sure that users have easy accessto new applications and therefore can discover new use cases for their smartphones.Applications can be installed in very few steps through so called App stores. Theamount of offered applications is astonishing: More than 1 million applications wereavailable for Android devices in July 2013 [231]. While some applications must

1

1 Introduction

be purchased, the majority can be installed and used free of charge which alsocontributes to the smartphone’s popularity.

These circumstances allow people to stay connected with their friends and coworkersthrough messaging applications or social media websites, do their online bankingfrom everywhere, shop arbitrary things online, or directly pay with it in a real shop.Many activities of course (in)directly store sensitive data such as private photos orsecret company data on smartphones and therefore imply security relevant questions.Most users are not skilled in making reasonable security decisions and often do noteven recognize that some decisions can result in, e. g., information disclosure or theftof money. As a result there is a huge potential for malware authors to exploit thislack of knowledge. But what if the user can make accurate security related decisions,is he or his data safe? What if application authors are not good at writing securecode? What if the smartphone operating system vendor ships the smartphone withfaulty software?

The connectivity, the vast amount of installable applications and the amount of datastored or processed on smartphones is very appealing to evildoers. They can, e. g.,generate money if they can trick the victim’s smartphone to send short messages topremium-rate numbers or they can steal payment information used on the smart-phone, such as credit card numbers. Stealing account credentials is also attractive,as these accounts can then be used to perform further attacks or to sell the gath-ered information. Furthermore, acquired private data such as intimate photos orconversations can be used to discredit or even blackmail involved individuals.

These examples are a very short excerpt of what can “go wrong” on a smartphone.Problems like these lead to the huge field of mobile security. Smartphones are atarget for malware authors and malicious software is quickly improving with respectto its functionality and code quality, as we show in the next chapter. In this thesis,we work on some of these problems and provide solutions for them. It is crucialto detect malicious or problematic software and we need ways to properly analyzethem.

1.2 Topic and Contributions

In this thesis we address several topics in the field of mobile security. Since maliciousapplications for smartphones are becoming more sophisticated and larger by theirnumbers, the need for proper tools to analyze and detect them is dire. We thuspresent new tools which analyze malicious applications for mobile devices, detect(malicious) activities based on the mobile device’s power consumption and enhancethe security of normal PCs with the help of a smartphone. We also present work in

2

1.2 Topic and Contributions

which we evaluate the robustness of state-of-the art analysis tools against sophisti-cated malicious applications.

Our contributions on this topic are therefore twofold. We strengthen the security ofsmartphones in different ways but also leverage them to mitigate attacks on othercomputer systems. The contributions of this thesis are summarized chapter-wise inthe following.

Chapter 2: Background: From Mobile to Security. In this introductory back-ground chapter we thoroughly discuss many aspects of mobile security and motivatethe contributions in the following chapters. We discuss how fast the smartphonemarket evolves and what features are offered by modern smartphones. We thenreport on security mechanisms utilized by smartphones and present attack vectorswhich can be abused by attackers and malicious software. To demonstrate the po-tential of such attacks, we provide a chronological overview of malicious softwareand their abilities which have been encountered on mobile devices. After we havemotivated the need for proper analysis systems, we briefly discuss program analysisaspects for mobile applications and motivate our contributions in this field. We alsoreport on aspects for smartphones not directly related to the term “security” butwhich can nevertheless lead to very real security issues, such as the simple act ofcharging a smartphone.

Chapter 3: Static Approach based on Program Slicing. After we have discussedthe need for proper program analysis tools, we present a tool named Saaf which is astatic analysis framework for Android applications. Saaf’s main feature is its abil-ity to analyze disassembled dex code—namely smali code—with a technique calledprogram slicing. Utilizing this technique enables us to extract many useful infor-mation of malicious applications, e. g., which commands are passed and executedby the system shell or whether any premium rate short messages are sent to whichdestination number. The tool also supports an analyst with a manual analysis andoffers many other functions such as generating control flow graphs, displaying allentry points and used permissions and it can easily decompile program code to Javacode next to other features.

In total, we analyzed more than 136,000 benign applications and more than 6,100malicious ones. We present many interesting analysis results and provide statisticsin which way benign applications differ from malicious ones. This includes aspectssuch as used permissions, used system services or loaded libraries to name but a few.We also specifically report on analysis results for chosen malware samples. The toolitself and its source code was made publicly available.

3

1 Introduction

Chapter 4: Dynamic Approach based on Power Consumption. In this chapter,we present our contribution in the field of dynamic program analysis. Instead ofchoosing some “traditional way” to dynamically analyze an application, we chose acompletely different approach. We evaluate whether it is possible to detect (mali-cious) activities performed on a smartphone based on their energy fingerprint. Intheory, every performed action consumes some measurable amount of energy fromthe battery, as long as the battery is not being charged. With proper tools whichprecisely measure consumed energy it is theoretically possible to detect certain ac-tivities based on their consumed energy.

We evaluate whether previously published work in this field—conducted for featurephones—is also valid for modern smartphones. We make use of a specialized soft-ware which precisely measures consumed energy and perform many tests in orderto understand which activities consume which amount of energy under certain cir-cumstances. We perform our measurements in synthetic short time tests but alsofor real-world scenarios in long time tests. We try to detect malicious activities bymeans of a self written proof-of-concept malware next to real-world malware sam-ples. Our empirical tests indicate that the power consumed by many activities andapplications is too small to be detectable.

Chapter 5: Change of Ends: Obfuscating Android Applications. After we havepresented our work in the field of program analysis, we evaluate the robustness ofavailable application analysis tools for Android. We first introduce existing programanalysis systems and then discuss on what assumptions such tools work and howthese assumptions can be taken away. We then present a tool which is able toobfuscate Android DEX code and therefore does not need access to any source code.The obfuscation’s goal is to prevent dynamic and static analysis approaches. We donot intend to break tools caused by implementation bugs, but we aim to take awaythe basic assumptions they rely upon. This includes, e. g., the removal of most directmethod invocations which results in degenerate call graphs. Tools which utilize thisgraph probably cannot work to their full extend this way and the resulting analysisreports eventually lack important parts. We also discuss code modifications whichreliable hinder the decompilation of Android applications and evaluate how wellantivirus solutions are able to detect malicious but obfuscated malware.

As we see in the next chapter, malware for mobile devices is advancing quickly withrespect to their functionality and quality. Meaning, analyzing sophisticated malwaresamples becomes harder and harder. We want to emphasize that next to evolvingmalware, analysis tools must also improve in order to keep up with the flood of newmalware families. We therefore evaluate the robustness of many static and dynamicanalysis tools against well-obfuscates applications.

4

1.3 List of Publications

Chapter 6: Enhancing Other Devices’ Security with SmartProxy. In our lastcontribution we completely change our point of view. Instead of analyzing mobileapplications or attempting to protect mobile devices from malware, we instead en-hance the security of a normal PC with the help of a smartphone. In this chapterwe present a prototype named SmartProxy which runs on a trusted smartphonewhich can be connected to an untrusted PC, e. g., over a WiFi network or a USBcable. As the PC is untrusted, the user probably does not want to input any creden-tials; but he still wants to enjoy the comfort of a full-sized keyboard and monitor.If our tool is used correctly, the user needs not to worry anymore that credentialsfall into the attacker’s hand if she somehow controls the PC. Our proposed solutionenables the user to browse the web and to even log in to websites in this scenario.

We enable secure logins when our tool is used as a proxy for the PC’s web browser.If so, the user must not enter real credentials anymore, but only fake ones. Thesefake credentials are substituted by SmartProxy on the smartphone with real ones,which have been set up previously. That way, an attacker never sees real credentialsand cannot steal those. Our tool additionally strips any security relevant data sentfrom the remote web server to the PC, such as session IDs or cookies. These datasetsare also replaced with dummy values and can therefore also not be abused by anattacker. Our solution works for plain HTTP connections as well as for encryptedHTTPS connections.

1.3 List of Publications

This thesis is based on academic publications published on several conferences butalso contains new and unpublished work. The author additionally was involved inother publications during his PhD studies and all these publications are listed inthis section in chronological order with a brief summary. If a chapter in this thesisis based on a publication, it is marked accordingly. Additionally, if a publicationemerged in the MobWorm project supported by the Federal Ministry of Educationand Research (BMBF grant 01BY1020), it is also marked as such.

Cooperation Enablement for Centralistic Early Warning Systems. This publica-tion deals with the problem of sharing data in early warning systems in order todetect upcoming threats while simultaneously protecting private data of involvedparties. This work was published together with Ulrich Flegel and Michael Meier atthe ACM Symposium on Applied Computing (SAC) in 2010 [83].

5

1 Introduction

Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security ofMobile Devices. This paper gives a broad overview in the emerging field of mobilesecurity with respect to early 2011. Chapter 2 is partly based on this publication andit emerged as part of the MobWorm project. It was published together with MichaelBecher, Felix C. Freiling, Thorsten Holz, Sebastian Uellenbeck and Christopher Wolfat the IEEE Symposium on Security and Privacy (“Oakland”) in 2011 [38].

SmartProxy: Secure Smartphone-Assisted Login on Compromised Machines.The paper presents a technique to enable the usage of a possibly compromised PCwith the help of a smartphone such that an attacker cannot get hold of used cre-dentials. It was jointly published with Sebastian Uellenbeck and Thorsten Holz aspart of the MobWorm project at the DIMVA (Detection of Intrusions and Malware,and Vulnerability Assessment) conference in 2012 [111]. Chapter 6 is based on thiswork.

Slicing Droids: Program Slicing for Smali Code. This paper introduces a staticprogram analysis technique named program slicing for applications written for theAndroid operating system. It was published at the ACM Symposium on AppliedComputing (SAC) in 2013 [112] in collaboration with Martin Ussath, Michael Spre-itzenbarth and Thorsten Holz as part of the MobWorm project. Chapter 3 is basedon this work.

Mobile-Sandbox: Having a Deeper Look into Android Applications. This paperpresents an analysis system called Mobile Sandbox which automatically dynamicallyanalyzes Android applications based on information previously gathered by staticanalysis techniques. This work also emerged in the MobWorm project and was donein cooperation with Micheal Spreitzenbarth, Florian Echtler, Thomas Schreck andFelix C. Freiling. It was published in 2013 at the ACM Symposium on AppliedComputing (SAC) [210].

Mobile Sandbox: Ein Analyseframework für Android Applikationen. This worksummarizes and extends the findings of the Mobile Sandbox and Slicing Droidspublications already presented above. It partly emerged in the MobWorm projectand was jointly conducted with Michael Spreitzenbarth, Hanno Lemoine, ThomasSchreck and Florian Echtler. The publication is in german and was presented at the“BSI Deutscher IT-Sicherheitskongress” in 2013 [211].

6

1.4 Outline

Mobile Malware Detection Based on Energy Fingerprints – A Dead End? Thispaper presents an evaluation whether (malicious) activities on a smartphone canbe detected based on their power consumption. This work again was published aspart of the MobWorm project at the Symposium of Research in Attacks, Intrusions,and Defenses (RAID) in 2013 [110]. It is joint work with Stephan Neumann andThorsten Holz and Chapter 4 is based on it.

CloudSylla: Detecting Suspicious System Calls in the Cloud. In this work weevaluate how normal computers as well smartphones can be protected by monitoringAPI and system calls. These traces are sent to the cloud and are searched formalicious behavior rather than performing such operations with a local softwaresolution. The proposed framework relieves the client of expensive computations inorder to detect malware as well as from regularly updating its signatures. This workis unpublished yet but will be presented at the Symposium on Stabilization, Safety,and Security of Distributed Systems (SSS) in September 2014 [133]. This publicationpartly emerged in the MobWorm project and work was jointly performed with MarcKührer and Thorsten Holz.

Evaluating the Status Quo of Analysis Tools for Android Apps. In this workwe discuss on which assumptions Android program analysis systems rely and howrobust these are against well-obfuscated (malicious) applications. This work is noveland has not yet been published but currently is in submission. It is joint workwith Davide Maiorca, Teemu Rytilahti, Marcel Winandy and Thorsten Holz andChapter 5 is based on it.

1.4 Outline

The remainder of this thesis is structured as follows. We first thoroughly introducethe field of mobile security in Chapter 2. We discuss and motivate our contributionsand give background information for the following chapters.

We then introduce our work in the field of static program analysis in Chapter 3.More specifically, we present a prototype named Saaf, which enables an analyst toperform program slicing on Android applications. Furthermore, we present manyanalysis results gathered while analyzing many benign and malicious applications.

Afterwards, we present our works in the field of dynamic program analysis. InChapter 4, we evaluate how precise (malicious) activities can be detected by meansof consumed energy of mobile applications.

7

1 Introduction

Following, we evaluate how robust state-of-the art analysis tools for mobile appli-cations are against software, that tries to thwart analysis attempts. We thereforepresent a tool in Chapter 5 which obfuscates Android applications and hampersstatic as well as dynamic analysis attempts. With this contribution we show thatmany tools cannot analyze well-obfuscated applications and that there exists a needto adapt to the rising number of sophisticated malware samples.

After we have presented our work in the field of program analysis we change ourpoint of view in Chapter 6. We present and discuss a prototype named Smart-Proxy which is able to provide secure use of a compromised PC with the help of asmartphone. The goal is to make a compromised PC usable for browsing the webwhile an attacker cannot get hold of any credentials.

Afterwards, we conclude this thesis in Chapter 7. We recap previous chapters andgive an outlook on research fields which are worth to be looked at but were nottreated within this thesis.

8

2Background: From Mobile to Security

This chapter provides an overview of the fieldmobile computing and especiallymobilesecurity. It lays the foundation for the following chapters and motivates each of ourworks and why we have undertaken them. It covers general aspects of (mobile)security and introduces some specific topics more thoroughly as we recur to themin later chapters. We draw a big picture of our topic mobile security without goinginto too much detail but provide enough information to motivate our works in thisfield.

We begin with a thorough discussion of the term “mobile security” in Section 2.1and emphasize the differences to “computing security” While doing so, we focuson smartphones and describe typical scenarios where security aspects surface andwhy they are important for this thesis. After this overview, we report on specificsmartphone characteristics and their typical features in Section 2.1.1 followed by anoverview of their security features and how data in general is protected by whichmechanisms in Section 2.1.2. Afterwards, we define and categorize attack vectorsin Section 2.1.3 which could be used to compromise a smartphone or parts thereof.Section 2.1.4 immediately follows with an overview of malware for mobile devicesand how it evolved since their dawn until now.

After we motivated the topic that security plays a big role in mobile computing andthat mobile security matters, we give a short overview of program analysis tech-niques in Section 2.2. We cover the aspects of static and dynamic program analysisin Sections 2.2.1 and 2.2.2 in order to analyze (malicious) applications for mobiledevices. Section 2.2.3 follows which covers the limitations of the aforementionedtechniques. Within these sections we do not discuss every aspect in detail as this

9

2 Background: From Mobile to Security

would be a topic on its own, but we rather introduce relevant aspects which arepicked up again in the following chapters.

We emphasize special security aspects of mobile devices not previously covered inSection 2.3. While they are not directly related to computing security per se, theyare strongly tied to it and, if ignored, might result in very real security problems.We also change our point of view and evaluate how we could leverage the featuresoffered by smartphones in order to strengthen the security of normal PCs instead ofmaking the smartphone more secure.

Throughout this chappter and especially in Sections 2.2 and 2.3 we point out whichcontributions we made to each of the research fields. We end this chapter with asummary in Section 2.4 and discuss how our work presented in the following chaptersfits into the research fields covered in this chapter.

2.1 Why Mobile Security?

This sections explains what is special about mobile security and why it is a term ofits own. Security, in the context of digital data processing is a huge topic coveringmany different topics from communication protocols, data integrity, unforgeabilityas well as programming errors in software or hardware products to only name buta few. The diverse fields of security can be categorized in several broad topicsdescribing their aspects, e. g., network security or operating system security. Butwhat is so special about mobile security? The term security itself is not be coveredin the following, as the meaning should be clear. What does the term mobile meanthen? Let us start with Figure 2.1 from Google trends which illustrates when andhow often the terms mobile security and smartphone showed up in search queries.Both terms are not new at all, but were used much more frequently beginning atthe end of 2010. If both trends are compared, a strong relation is immediatelyvisible. A further investigation regarding similiar terms shows that the term mobilesecurity also strongly correlates to the number of sold smartphones [212] over thattime period.1

Apparently, our term has something to do with smartphones. Smartphones areavailable since 2007 to 2008 as “successors” to the so called feature phones, whenApple launched the iPhone [114] and Google introduced the Android operating sys-tem [174]. Before that time, feature phones were often also called Smartphone, asno distinction had to be made as “real” smartphones were not yet available (this1 This does not proof that the numbers are statistical dependent, but an accidental correlation isvery unlikely. Further investigations are ommited as the point should be made clear.

10


2005 2006 2007 2008 2009 2010 2011 2012 2013 2014Year

0

20

40

60

80

100

Inte

rest

over

time

Mobile SecuritySmartphone

Figure 2.1: Google Trends data [100] for the search terms “mobile security” (withinquotes) and “smartphone”. The graph shows the worldwide interest overtime with 100 marking the date of highest interest.

explains the interest in the years before 2007 for smartphones in Figure 2.1). Sincetheir dawn, smartphones top their previous year’s sell rate each year [212, 93]. In2013, around 1 million Android smartphones were activated daily [99]. It is commonthat mobile security is often used in the context of smartphone security or mobilephone security. From now on we talk about smartphone security when we talk aboutmobile security and mobile devices most likely reference smartphones. A descriptionof the technical details and what defines a smartphone is given in Section 2.1.1. Fora distinction between feature phones and smartphones we refer the reader to thework of Becher [37].

Focusing on smartphones leaves us with their properties and how they affect security.Although more and more features and sensors are included in newer smartphonemodels, even the early generations offer many features previously not available in

11


such small form factors. These features characterize smartphones—making them“smart”. Being able to establish and even hold a connection to the Internet atall times in conjunction with many sensors, e. g., cameras, GPS, accelerometers,light sensors and other communication services next to GSM (and its successors,e. g., GPRS, UMTS, and LTE) such as WiFi, Bluetooth or NFC offers a lot ofopportunities and results in many different use cases. From home automation toonline banking or the ability to remotely control cars to some extend and manyother scenarios the options were never so easily doable by almost everyone fromalmost everywhere—even without much technically knowledge. Although most ofthese services are not directly supported by the smartphone or the operating systemitself, they are made possible through the conjunction of utilizable hardware devicesand the ability to install third party applications which make use of these andultimately offer the features to the user. A description of the sensors and the featuresof typical smartphones is given in Section 2.1.1. Such additional applications aremost of the time installed through so called application markets, like Google Play orApple’s App Store.

These application markets are divided in official and unofficial markets. Official onesas Google Play for Android or the App Store for iOS based smartphones are mostlydirectly enabled on new smartphones. They are easily accessible to the smartphoneuser as soon as the phone is activated and a user account has been created. Theuser only has to search for what he desires and install the application of his choiceby simply clicking on more or less one button. Official markets on the one hand aresupervised by smartphone hardware or OS vendors, who control what is offered tothe user. Unofficial markets on the other hand are not controlled by these vendors,but by other companies, e. g., Amazon’s Appstore for Android [25], or (groups of)individuals like Cydia [119]. Unofficial markets have to be manually enabled bythe user, if desired. Trustworthiness of such markets vastly differs and we coverthis topic in Section 2.1.4. For now, these markets offer easy access to additionalapplications, or apps, which enrich the smartphone. This might just be a simplegame or an image viewer, but it can also extend its functionality in some aspect,e. g., being able to remote control the TV at home or even the car (not driving,but, e. g., opening the doors and starting the engine). Discussing all the categoriesof such apps is out of scope for this thesis, but, in general, one can imagine thatthere exists an app for almost every use case. To put it into a number: In July 2013Google Play reached the mark of 1 million available applications [231].

Having easy access to so many installable applications leaves us with the questionwhere all these offered applications come from. They are developed by a vast numberof companies and individuals throughout the world. While the developer’s goals canbe very different, the applications can nevertheless be categorized in three categories,depending on how they compensate the developer for the production costs:

12


• Free Applications. These applications do not cost any money and offer fullfunctionality.

• Free Applications with Ads. These are also offered for free, but display adver-tisements to the user which eventually produce some income for the developer.

• Paid Applications. Before they can be used at all or to the full extend, theuser first has to purchase them.

Mixtures of these categories are possible but can safely be ignored in the following.What we want to show is how users “pay” for some applications in one or anotherway in order to be able to install or use them. Let us assume for a moment thatfree applications are free of ads, not malicious and are indeed free in the sense thatthe author does not try to make money in any way listed below. If that is the case,we can skip this category because we get no further insights from them with respectto how users pay for applications. We therefore now look at ad-sponsored and paidapplications and cover malicious ones afterwards.

If an app is purchased, most of the time a purchase is performed from within themarket application itself and the market vendor therefore has some way to charge theuser for it. Although the user could enter a payment address each time a purchase iscarried out, most of the time some credit card or other payment information is storedin some wallet application or directly on the market provider’s servers (or a mixturethereof), which is used for the transaction. For easiness, once a payment address hasbeen set up, the whole purchase often is not more than accepting some confirmationand the charging itself is performed in the background. These payment informationare of course valuable targets for an attacker. Other payment methods are viable,but what matters is that payment information such as credit card numbers are veryvaluable and sensitive data.

Let us now look at apps, which display advertisements. Apparently, they must notbe purchased by the user. Still, the developers aspire some compensation for theirwork and therefore display ads inside their application. When a user clicks on sucha banner, the application’s developer is paid a small amount of money based on acontract between the developer and the ad provider. How the advertisement processworks in detail is definitely out of scope for this thesis—for the Android operatingsystem, e. g., Grace et al. [102] analyzed many ad frameworks. What matters is howthe ad provider and the developer actually make money out of displaying advertise-ments. Typically, some company provides ads for an ad campaign, which the adprovider then displays on websites, or, as in this case, in smartphone applications.When a user clicks on such an ad, the user is redirected to some website chosen bythe company, e. g., their web shop or a website with more information about theadvertised product, hoping that the user becomes a customer of some sort. The

13


application developer gets paid by the ad provider when the user clicks on such abanner. Sometimes the ad even generates revenue for the developer if the banneris only displayed, without the user interacting with it at all. Since both sides areinterested in getting the most money “out of a user”, the company as well as thead provider are well interested in users who have a high probability for being inter-ested in the advertised product. Displaying completely unrelated ads to users willmost likely not entice them to consider clicking on the ad. This leaves us with thequestion how can one know what a user probably likes and therefore which ads arerelevant for him? The key here is to build a profile about the user and to be ableto identify this user although his real identity might still be unknown—the habitsand likes are the information of interest. Here the smartphone with all its sensorsplays a huge role. While ads are also served on a normal PC while browsing theweb which are also selected based on a previously generated profile, typically muchmore information is available on a smartphone to build such a profile. Whether andwhich information sources, such as serial numbers or account data, are available andaccessible is discussed in Section 2.1.2.

We already briefly mentioned that smartphones offer a lot of sensors ready to be usedby installed applications. The so provided information is also generally availableto the ad provider through the ad-embedding application itself. That way it ispossible to access unique identifiers for the smartphone itself, such as the IMEI andIMSI, or identifiers bound to the user account such as the mail address. Additionalinformation such as geolocation data, nearby WiFi and GSM network identifiers orlists of running applications or contacts next to many other information sources canall be tied together and used to build a profile about the smartphone, respectivelythe user himself as it is uncommon that a smartphone is shared by more than oneindividual for a longer time.

All this does not take into account personal and probably intimate information thatare produced, consumed or stored on a smartphone. What about private messagesexchanged with, e. g., the short message service, Twitter, Facebook or any othermessaging service? What about pictures taken with the smartphone’s camera? Thecontact list or the call and browser history, let alone user credentials? All theseinformation sources can be used to get a very detailed view of the smartphone owner.The profile created from all the available information sources can be deadly accurate.If enough data is available, it can easily be interfered where the user lives and works,what hobbies he has and for which things he in general has an interest in. It is alsopossible to deduce whether someone has a medical condition or to obtain his politicalattitude solely based on the call logs [181, 152]. How valuable such information isshowed the recent acquisition of WhatsApp by Facebook [21]. $19B dollars werepaid for a company of roughly 50 employees. What was so valuable for Facebookwas the growth rate of this small messaging application having approximately 450

14


million customers by the time of acquisition. But these customers were able touse WhatsApp for free for one year. After this first year further use was chargedwith only $1 per year. For Facebook, which earns money with advertisements each“customer”—or better the profile about the user—is worth roughly $42. Just lookingat these bare numbers of course blends out other factors but still shows how muchpersonal data is worth. Additionally, WhatsApp was free of advertisements, sothere was no direct income except for eventually paid annual fees (and of courseventure capital). If Facebook is willing to pay so much money, there certainly areother companies which are interested in such data. Insurance companies could, e. g.,check whether a new customer is worth to be insured from a monetary viewpointor if an insurance would probably result in a deficiency. If an attacker gets hold ofsuch data she could try to sell it at some underground market. A profile acquiredthat way may not be worth $42, but the underground offers user profiles (usuallywith login credentials) in bulk ranging from a few cents up to many dollar accordingto a study by Symantec [218]. High quality profiles and banking accounts are worthmore money.

Next to the vast amount of personal data stored and possibly accessible on a smart-phone, there exists another unique “connection”. It is safe to assume that almost allsmartphones are used with a SIM card by its user to be able to establish a mobileInternet connection. On the one hand, the SIM card itself is bound to one providerwhich offers cell phone services and enables the use of these. On the other handit is also linked to a person (or company) who wants to use these services. Thisrelationship enables the provider to charge the customer (the smartphone user inthis case) for the used services. These normally include the short message service(SMS), telephony services as well as mobile Internet connectivity. How the customeris charged also varies and could include monthly fees or prepaid credit. This againlooks attractive to a potential attacker because she is able to directly generate rev-enue by abusing this fact. If she could trick the provider’s customer into callingor sending short messages to a premium number that she set up, she would indi-rectly get access to the customer’s money. That is because her service is paid bythe provider which itself gets the money back from the smartphone user. Abusingthe short message services was a widespread scam in 2010 [50] where users werecharged up to $5 for a single SMS which was silently sent by some malicious appwhich the user formerly installed after being tricked to do so. Attackers could alsotry to harvest other payment information, such as credit card numbers or onlinebanking TANs which are processed by the smartphone—just like for normal PCs.

Another opportunity for an attacker to immediately get monetary value out of steal-ing data is to get illicit access to so called cryptocurrency wallets. Cryptocurrencies,such as Bitcoin [5] or Litecoin [14], are not widespread as a payment platform yet,but interest in is constantly rising. In some cities and stores customers already can

15


pay with these cryptocurrencies instead of “normal” money. The payment is usuallyperformed with the help of smartphones which exchange data regarding the currencytransfer with QR codes (Quick Response Code; other methods are possible, though).Without going into detail about the inner workings of such currencies, they are bydesign pseudonymous and unforgeable and whoever knows the secret key which isstored in the wallet has access to all digital coins related to that wallet. This andthe recent rise in Bitcoin’s value to over $1000 in December 2013 [191] as well asthe presence of exchange markets which also exchange to fiat currencies make suchwallets valuable targets. Malware authors already target cryptocurrencies as wasshown by Huang et al. [116] and the presumable theft of Bitcoins from one of thelargest exchange markets Mt. Gox in early 2014 worth $480 million USD by thattime [68].

We now shortly revisit all the information which might be stored on a smartphone.What is the purpose of an installed application to access these? Let us look at, e. g.,Facebook’s application for Android. In order to be able to easily find friends theapplication uploads the complete contact list to Facebook’s servers where they areprocessed to make some suggestions about known people. What about a weatherapp? It presumably has access to the Internet for downloading forecasts. In orderto retrieve forecasts about the user’s region, it might also use the geolocation madeavailable through the GPS sensor. These use cases seem genuine and not malicious.What about the game Angry Birds? It has Internet access because it displays someads. In order to show ads which are interesting for the user, it might also access thegeolocation and, e. g., advertise a local shop. We have to think about the privacyconcerns in these scenarios. Who knows what happens with all the data after it“leaves” the smartphone. The weather application might also be a perfect trackerapplication which clandestinely spies on all the user’s movements while looking likean unsuspicious weather forecasts app. What if a car or health insurance companygets hold of this information? It can easily be deduced how fast someone drives onthe highway and the insurance fee might be adjusted accordingly. Of course not allapplications are malicious nor is the accessed information always abused in someway—but one should be aware of the consequences this might cause. The readermight take a moment and think about the potential privacy loss induced by largescale info gathering data mining operations as they have been reported to be feasibleby state sponsored attackers [105].

Since smartphones are ubiquitous by now with a market share of 57.6% for globalmobile phone sales [92], somewhere between their advent and 2014 they also havebecome a malware target. Being at least as complex as a “normal PC” regardingtheir features and uses, this was an expected development. This can be easily seenin Figure 2.2 which depicts the monthly amount of malware seen for Android fromearly 2012 on. So where does that leave us with our initial question “Why mobile

16


02’1205’12

08’1211’12

02’1305’13

08’1311’13

02’1405’14

Month

0

20000

40000

60000

80000

100000

120000

140000

160000

Sam

ples

Figure 2.2: Monthly amount of previously unknown and unique malicious APK sam-ples for the Android operating system seen by GData, who also kindlyprovided this data.

security?”. The rough overview sketched in this section should make clear, thatthe amount of data which has to be protected is tremendous while the potentialto abuse it is huge. But regular solutions from the PC world such as a runningAntivirus software are clearly not enough and also not the best solution becausea smartphone is still a device with limited processing power and, more crucial,is battery powered. Running a full blown security suite which constantly drainsenergy from the battery and therefore further reduces the already limited runtimeof a smartphone is not acceptable for most users. While AV software is not useless,there exist further options which enhance the security of smartphones. Fine grainedpermission systems [64, 208, 45], control of information flows [64, 173, 172, 76],shadowing real user data with bogus values [115] are only three examples of a hugepuzzle regarding the security of smartphones. So mobile security refers to all thesepieces and scenarios which make the phone smart while taking into account thatit still is a phone. Let it be OS security or permission concepts for applications orstudies about users’ behavior, who might not be able to assess the risks of installing

17


unknown applications. Section 2.1.3 explicitly covers possible attack vectors and wealso clarify more aspects of mobile security found on smartphones.

We now present more details about several aspects of smartphones and topics relatedto mobile security. We start by giving an overview of smartphone characteristicsfollowed by a quick evaluation of their security features. Then we look at possibleattack vectors which might be exploited by attackers and finally summarize theevolution of mobile malware until recently.

2.1.1 Smartphone Characteristics

In this section we explain the main features which characterize smartphones. Due tothe fact that several manufacturers produce many smartphone models with differentfeatures and operating systems, not every feature covered here can be found on everygiven model. The mobile market is a market of strong growth, therefore new featuresare generally added to new high-end smartphone generations and features whichbecame more common are also made available in less expensive models. Albeit weare only interested in smartphones throughout this work, many discussed featuresare also relevant for so called feature phones and even “normal” cell phones. Thissection does not cover all possible sensors or hardware modules that can be built-in,but covers the most relevant ones to draw a general map of smartphone features.

In general, smartphones are hand-held mobile devices with a relatively large screen.The main processor is most of the time an ARM based one with 1 to 8 cores.Although ARM processors are very widespread, some smartphones also feature x86CPUs. The processors offer clock speeds up to 2.3Ghz, depending on the model(e. g., the Snapdragon 800 [189]). The CPU is part of a SoC (system on chip) whichalso contains a GPU fast enough for 3D games and able to decode HD videos [189].While most smartphones offer a touch screen as input device, some (additionally)offer a small keyboard. They are of course battery powered and offer a multitudeof sensors and interfaces, which are described next in the following paragraphs.Speaking bluntly, smartphones offer the computation power of a PC less than adecade ago but in a very small form factor.

Network Interfaces. The most important feature of smartphones are of coursetheir ability to make phone calls and establish a mobile Internet connection withthe integrated GSM and mobile broadband modem. Various generations (GPRS,UMTS, HSPA, LTE, . . . ) exist which offer better connectivity options such asmore bandwidth for newer generations. Additionally, smartphones are—like theirpredecessors—able to send and receive short messages (SMS) as well as multimedia

18


messages (MMS). In addition to the aforementioned connectivity, they often alsooffer interfaces to establish short range wireless connections over Bluetooth andWiFi interfaces. Although not exactly network interfaces, modern smartphones alsofeature communication with RFID and NFC transponders. IR interfaces used forcommunication which were common years ago are almost absent on smartphones.

Sensors. A smartphone is generally packed with multiple sensors which serve var-ious purposes. We list the most relevant ones which should give a fair overview ofwhat can be archived with the corresponding software which makes use of the sensorreadings.

GPS. This sensor can accurately calculate the geolocation of the smartphone basedon GPS data sent by the Global Positioning System satellites. It can alsoderive the speed and direction based on multiple readings. Position data isused by many applications, e. g., navigation software.

Accelerometer and Gyroscope. These sensors measures the acceleration as well asthe orientation of the smartphone. They are often used in games or to deter-mine whether and how the user is directly or indirectly interacting with thedevice.

Magnetometer. This sensor can be used to serve as a digital compass.

Proximity Sensor. Built into the front of the smartphone it is capable of detectingwhether something is near the display. It is, e. g., used to determine whetherthe user holds the phone against the ear while a call is established in order toturn off the display.

Light Sensor. This sensor is also often built into the front of the smartphone tobe able to measure the ambient light intensity for automatically adjusting thedisplay’s brightness.

Microphone. The microphone itself is a central sensor of every smartphone. With-out it basic functionality would not be possible.

Camera. It is normally used to take pictures or shoot videos but can also be usedto quickly process abstract information which would otherwise be hard toinput into the phone based on barcodes as well as QR codes. Most devicesoffer one camera mounted on the backside of the phone for taking pictures,but additional front-cameras are becoming more common to enable video-telephony.

19


Biometric Sensors. While some data can be interpolated from the others sensors,e. g., how one grabs and holds the phone while inputing data [94], biometricsensors aim to directly identify a person based on, e. g., the fingerprint. Thefirst smartphone offering this feature was the iPhone 5s [158].

Mobile Operating Systems. Although many different smartphone manufacturersand therefore models exists, the same is not true for their operating systems. Bythe time of writing, four major operating systems are widespread and from theseonly two are installed on the majority of all phones; namely Android by GoogleInc. [98] which is available for a multitude of different smartphone models fromdifferent manufacturers and iOS by Apple Inc. [30] which is exclusively available forApple devices. In December 2013 Android had a market share of 78.4% while iOShad 15.6% [92]. The other two players are Windows Phones by Microsoft [155] witha market share of 3.2% and Blackberry OS by Blackberry Ltd. (formerly knownas Research In Motion Limited or RIM) [40] with a market share of 0.9%. Whileother operating systems exists, e. g., Firefox OS [161] or Ubuntu Touch OS [49],their market share is currently negligible.

All the operating systems are optimized for mobile devices and therefore try tobe as power-conserving as possible. Meaning that even though the hardware ispretty powerful a good runtime and at least a good stand-by time can be archived.Additionally, a special designed user interface is provided to ease the usability andtakes into account the special form factor and input devices as well as availablesensors. We do not discuss all the up- and downsides of the different operatingsystems in this thesis. If specifics are of interest they are be mentioned in theappropriate sections.

What is of interest though is that only one of the four major operating systemsis (mainly) an open source product, meaning that all the source files except for,e. g., some binary drivers, are available. This is only the case for Android—all theother are proprietary with (mostly) closed source. Therefore a great communityestablished around Android, providing patches, new tools and even complete forksof the Android operating system itself which introduce new security concepts andfeatures, e. g., CyanogenMod [10]. The same is true about academic research—mostof the publications deal with Android somehow. Our contributions also were onlyevaluated with Android, being on par with almost all the other research labs. Theresults of course might be generally applicable, but implementing and testing mostof the time happens where it can easily be performed. Having access to the sourcecode and a good documentation is a strong point to chose Android as one’s targetoperating system.

20


3rd-party Applications. This is perhaps the most popular functionality smart-phones offer: Enabling easy installation of additional software with more or lessarbitrary functionality. It undoubtedly is a key factor for the success of smart-phones in general. Being able to extend the functionality of a smartphone with afew clicks makes it “smart”. As already stated above, there is an application for al-most every use case. We previously mentioned applications markets and now presentmore details about them.

At least all major smartphone operating systems provide easy access to at least oneofficial market where users can search for and install applications. Since the userin general cannot review the applications there might be some risks involved wheninstalling an application from an unknown developer. The user of course also cannotreview the operating system itself as well as the preinstalled applications, but we justassume that the user trusts those components—although multiple critical flaws werealso found in those components [6, 7]. We previously imagined a weather forecastapplication which could also track the user. The user’s chances of detecting suchmisuse is relatively small, as the only indicator is the requested permission set ofthe application, which explain in more detail in the next paragraph. Since attackersare constantly trying to spread malware and users cannot detect possible maliciousapps, the market places should take care of it, as a trusted party of the user. Andindeed, they are performing tests to detect malicious software.

Google makes use of a service called Bouncer, which analyzes an application whenit is uploaded to Google Play and looks for malicious activities and compares itagainst known malware [145]. While Google revealed some information about thisprocess, Apple presumably uses a similar approach albeit concealing what they aredoing. They claim to review all applications before they are made available in themarket [29]. If an application does not follow all the guidelines2 they set up, it willbe rejected. How the review process works is unknown, but applications by the timeof this writing take on average 5 days until they are processed [207]. Other vendorstypically also employ some analysis steps in order to detect malware, but details ingeneral are also unknown.

In order to prevent a flood of “useless” applications, a developer account in theofficial markets usually comes with some fee. Google demands an initial $25 andApple’s fee is at $100 per year. Nevertheless, thousands of developers are offer-ing their applications which the previously reported numbers of applications in themarkets show. Few developers are of course security experts and therefore some-times accidentally produce security problems. These might lead to vulnerabilitiesranging from information disclosure to arbitrary code execution [42, 164]. In order2 The guidelines are only available after a developer account has been created and are thereforenot referenced.

21


to detect such unintentionally introduced security bugs, as well as malware, severalanalysis tools exist which help an analyst in understanding the inner workings of anapplication. We describe analysis techniques in Section 2.2.

All major operating systems support code signing for their applications. If donecorrectly, a vendor can enforce that only signed applications distributed throughofficial channels can be run on the smartphone. Additionally, installed programsoften run in a restricted environment and can only perform actions which are consentwith given permissions in order to mitigate malicious activities. We describe thesefeatures in more detail in Section 2.1.2.

Nevertheless, if some malicious software was successfully sneaked into a marketdespite all precautions and users installed the malware, the market vendors mightbe able to automatically remove the offending application from the smartphonewithout any user input or even consent. Google performed this action after themalware DroidDream was found in their market [50] and for removing proof-of-concept applications published by Oberheide [169].

2.1.2 Smartphone Security Mechanisms

This section briefly covers fundamental security features mobile operating systemsoffer. Since this is a very broad topic, we give just an overview and give detailsthroughout this thesis in the following chapters whenever needed.

We first write about authenticate mechanisms and then about how applications aresandboxed and how permissions work for applications. Afterwards we outline theconcept of code signing and write about encryption mechanisms in general.

User Authentication. Similar to a normal PC users normally must authenticate insome way before the smartphone can be used. Most of the time users authenticatewith a secret PIN and unlock the SIM card in order to get access to the SIMprovider’s telephony services. Although this unlocks the SIM card, the user hasnot provided any authentication credentials to the smartphone operating system. Ifthe smartphone permits a login without any authentication, the user is now ableto perform any operations which are not protected by any special means—whichusually means he has full control of the device. If a login procedure is set up, theuser must first authenticate against this one before being able to use most of thesmartphone functionality (some features such as taking a picture are even availablefrom the lock screen). The lock screen can also be automatically activated after achosen time of inactivity, just like a screensaver.

22


There exist several login mechanisms, but the major smartphone operating systemstypically offer at least one of the following.

• Patterns. The user has to “draw” a previously chosen pattern. If correct, hewill gain access past the login screen. This mechanism is especially useful fortouchscreens. Still, studies show that the patterns are often not complex [226]and “drawing” it leaves residues on the screen which can be used to infer thepattern [31].

• PIN. The user has to enter a previously chosen PIN. Typically the user chosesa short PIN because if the lock screen gets activated after a period of inactiv-ity, the user desires quick access to the smartphone instead of more security.Since only numbers are allowed, the virtual keyboard is able to display anappropriate layout making the input procedure more easy.

• Passphrase. Just like PIN, but this time all characters in additional to num-bers can be chosen. Since the character set is larger, the virtual keyboard hasto offer all the characters and the buttons are therefore smaller. This puts aburden on the user if the passphrase is long and consists of numbers, lettersas well as special characters. Typically users seldom choose this mechanismsand if they do, chosen passphrases are often of poor quality [85].

A thorough evaluation and user study regarding login mechanisms for mobile deviceswas performed by Uellenbeck [225]. Next to the aforementioned authenticationschemes additional ones can be installed and they can also be completely turned off—despite all the drawbacks if the smartphone gets lost or stolen or someone withbad intentions (briefly) accesses it. If a passphrase is chosen and if that is also usedfor decrypting the file system or parts of it, it better has to be of good quality asthe encryption can only be as good as the chosen—or derived—key.

Sandboxing. Let us start with some features which are present on a normal PCas well as on smartphones. The operating system kernel in collaboration with thehardware usually protects the address space of applications against other applica-tions, makes use of address space layout randomization (ASLR) as well as enforcingthat memory is not write- and executable at the same time (NX). Additionally, most(additionally installed) programs are run under some user except the admin or rootuser which has restricted access to system components, e. g., based on the groupsit is a member of. Some mobile operating systems also support policies which canbe written to further prohibit applications from accessing, e. g., files which theynot necessarily have to access. An example would be Android 4 which makes useof SELinux policies which add Mandatory Access Control (MAC) constraints toapplications [175].

23


Most mobile operating systems additionally run applications in some sandbox whichfurther delegates access to some API functions and adds additional security checks.Android for example runs most applications under a separate user id and insidethe Dalvik Virtual Machine which provides a complete API for applications anddelegates necessary functionality to system libraries or the kernel while performing(additional) security checks.

We do not describe all the pros and cons of all the security features related to processisolation, sandboxing and so on as this would be a topic on its own—other researchershave published work in this area, e. g., Xu et al. [240] or Dall et al. [61]. What isreally special for mobile operating systems though is the concept of permissions tofurther enforce restrictions upon applications. Some functions or methods requirethe calling applications to possess some specific permission in order to be usable.Permissions and related work are covered in the next paragraph.

Permission System. All of the major four mobile operating systems are able torestrict access to certain information sources or hardware devices from an appli-cation’s perspective. While the implementations differ, the goal is the same: Theuser should be able to decide which applications have access to which “features”. Ingeneral, a permission specifies some information provider or function an applicationdesires to use. That could be access to the contact list or the call history or the useof some hardware device such as the camera or the microphone.

Imagine a wallpaper application which accesses the complete contact list and uploadsit to a remote server—the functionality is clearly not crucial for the application’spurpose and might not be what the user expects of such an application. With-out a proper permission system the user would never know about such possible(mis)behavior. This does not mean that the user is able to detect such misuse ifa permission system is present, but he should at least be able to know that such athing is possible, based on the granted permissions. In this example the applicationwould need, e. g., the permission to change the wallpaper as well as to access thecontact list and be able to open sockets. While not all of the exemplary permissionsare available or controllable on each platform, the user could in this example see the“extended functionality” of the wallpaper application based on the requested per-mission set. Whether the application actually abuses the permission in such a waycannot be deduced from the permission set and they could also be of sole genuinepurpose. The application may only use the granted permissions in order to advertisea wallpaper to a friend when the user choses to do so.

The operating systems typically restrict access to services which could be exploitedby attackers and where misuse could have negative effects for the user. This includes

24


all functionality which occur costs, such as sending a SMS or establishing a phonecall. Functionality related to sensitive or private information is also often controlledby permissions, e. g., serial numbers or databases storing contacts or chat messagesetc. Access to certain hardware devices is also usually protected, e. g., the cameraor the GPS sensor.

We now briefly describe the permission systems for the major operating systems.While their implementations differ, the goal is always the same: regulate accessto certain information and functions of the smartphone. How the permissions areenforced and how good each of the systems is is not elaborated in this thesis and werefer to the work of Felt et al. [80] and Grace et al. [102].

Android. Before an application is installed through Google Play the user is askedwhether the permissions the application requests should be granted. Depend-ing on the permission some warnings and implications might be displayed topoint the user to possible misuse scenarios. If these are accepted, the applica-tion can make use of them at any time without further restrictions or inquiries.If the user rejects the permissions, the application will not be installed at all—this is an all-or-nothing approach.

Apple iOS. Applications are not granted any particular permissions at installationtime but the user is asked when certain information sources are queried, e. g.,location information or the contact list. The user is then able to grant ordeny the request. While not all sensitive features are protected that way, e. g.,Internet access is not protected, the user still can disable specific features if apermission check exists.

Windows Phone. Windows Phone does not know about permissions, but offers asimilar approach called capabilities. Applications feature a set of capabili-ties which describe the intentions and demands of it. Software capabilitieson the one hand specify, e. g., that the application is provided access to loca-tion services or the camera, just like their permissions counterpart. Rejectingparticular capabilities while accepting others is also not possible, just as forAndroid permissions. Hardware capabilities on the other hand specify hard-ware requirements which are required for the application to work properly,e. g., the presence of a front camera. They are not related to any permission.

Blackberry. The permission system for Blackberry differs a little from the previousones, but tries to archive the same goal: control what information and func-tions are accessible by an application. When an application is installed, it canbe granted the trusted status, meaning it can access almost all informationand functions. If it is not declared as trusted, it will work with a defaultpermission set. Permissions can be set to “Allow”, “Deny” and “Prompt” just

25


like in iOS. The default permission set can be changed by the user as well asthe permissions for one particular application. Applications might not workcorrectly if some permissions are denied, depending on the application’s code.

If the permission system is well implemented and checks are performed by systemcomponents other than the application itself, some malfunctioning or even exploitedapplication cannot cause more harm than the corresponding permission set allows.An attacker requires a successful privilege escalation attack or must proceed with,e. g., a confused deputy attack in order to obtain further access to otherwise pro-tected functionality. We revisit this topic in Section 2.1.3 where we also talk abouthow smartphone users experience such systems. We provide statistics about re-quested permissions and how well developers make use of them in Chapter 3.

Code Signing. A feature all major mobile operating systems support is code sign-ing. Each application is signed with a certificate which the operating system trusts.Unsigned applications will normally not be installed and even development buildshave to be signed, although a self-signed application might be acceptable in this case.Official markets always distribute applications which are properly signed. This es-tablishes a unique connection between the application and the developer, as only heand probably the market vendor should have access to the private key. Dependingon how strong the chain-of-trust is enforced, additional applications might only beinstalled through the official vendor’s channels, e. g., the trusted market applica-tion. Apple’s iOS for example only accepts signed applications distributed throughApple’s own market. Applications part of the boot process, the kernel as well as ap-plications of the operating system are part of a trusted boot environment, meaningthat an unsigned application will not be executed, including applications which shalladditionally be installed. This is deemed as a security feature as it completely locksdown the device and Apple has full control of which code runs on their devices sincethey also control the market. This is at least true in theory, but security expertsfound ways to circumvent the operating systems security features and were able torun code which ultimately disabled the chain-of-trust and defeated the secure bootprocedure [77, 63]. This then enabled the execution of unsigned code and the intro-duction of external markets such as Cydia [119]. In general, this procedure is hardto evade and exploits against such a system are rare if done correctly. Google’s An-droid does not feature such restrictions because the operating system is advertised as“open” and developer-friendly. Manufacturers of Android devices may incorporatesimilar techniques though and, e. g., Microsoft goes a similar way with its WindowsPhone as Apple does [109].

26


Encryption. In order to protect the confidentiality and integrity of data stored onthe smartphone itself or data being received and sent, encryption mechanisms canbe employed. While each application can provide its own encryption functions, itis often best to make use of well approved libraries to avoid many pitfalls [221].For third party applications the operating systems provide cryptographic libraries,although even those are not always bug free as OpenSSL’s Heartbleed or Apple’sGotoFail bugs illustrate which also affected many mobile devices [7, 8]—at least theyare (well) audited. These libraries can be used to establish SSL/TLS connections,manage encryption keys and to store encrypted data on the device. The operatingsystems also offer the feature to encrypt all personal data or even the complete harddrive. As this is a topic on its own, we do not provide deep insights about encryptionmechanisms provided on smartphones in this thesis. We nevertheless report on someuse-cases and how good provided encryption mechanisms perform in Chapter 6.

2.1.3 Attack Vectors

We now describe attack vectors which can be used by attackers in order to ob-tain extended access to the smartphone. Since smartphones offer more interfacesand (mobile) services like normal PCs, they also offer a broad spectrum for attackstrategies. We classify the vectors in four categories and give examples for each ofthem. This section picks up the categories described by Becher et al. [37, 38] andextends some with new ideas. More details about the categories and more attackdetails can be found in their works. While most of the attack scenarios are notrelevant for the following chapters, we still briefly present them to give an overviewof the attack surface.

Hardware-Centric Attacks. This category covers attacks against the hardware it-self which also includes removable devices such as a SIM or SD card. The smart-phone itself could, e. g., be attacked over not disabled JTAG connectors (Joint TestAction Group) to get (direct) access to the hardware, e. g., the processor in orderto retrieve values stored in its registers. The SIM card could be the target of anattack as the communication between the smartphone and the SIM card can beintercepted and even changed. A device called TurboSim was used in the past toremove the SIM lock of an early iPhone model [39]. Forensic analysis techniquescan also be applied to hardware devices. The complete contents as well as possibledeleted files can be extracted if one has direct access to the SD card controller orthe flash chips [43]. A cold boot attack could also be executed to retrieve, e. g.,cryptographic keys from memory [106]. This attack was also successfully performedon Android smartphones [163].

27


All these attacks are seldom seen, as they require direct access to the smartphoneand sometimes even require modifications to the hardware itself like soldering cablesto the JTAG connector or desoldering flash chips.

Device-Independent Attacks. Attacks in this category are not directly related tosmartphones, but to the services and protocols they use. Wireless connections tothe mobile network which enable telephony services immediately come to mind.The cipher suites used to secure GSM connections have been broken which enableseavesdropping, impersonation attacks and DOS attacks. Attacks against it are wellknown [35, 41, 177] and were even extended to the communication protocols usedby satellite phones [69]. DOS attacks could be executed if someone tries to exhaustspecial channels in the GSM protocol by flooding it with, e. g., SMS messages [224].While similar attacks exists against the successors of GSM such as GPRS or UMTS,the protocols were designed with more security in mind, but are still not immuneto attacks [154, 186]. The same is true for WiFi connections established by thesmartphone. Attacks against the used protocols are well known [220] and othercommunication protocols like Bluetooth are also affected [148]. Breaking crypto-graphic protocols in general is a topic that affects all the data which is encryptedon a smartphone. Stolen private keys for certificates of certification authorities orwrongly issued certificates [202, 59] are also an example which indirectly affects thesmartphone (user), but are totally unrelated to the device itself.

Another field applies to data which is transmitted from the smartphone—not takinginto account the aforementioned protocol flaws. Take for example an automaticbackup, e. g., the operating system’s automatic syncing of data to the cloud. Evenif the transmission is perfectly secure, who can assure that the data is also securelystored? Apparently, a lot of problems occur in such cases, most likely resulting in theloss of the data [44] or being leaked somehow [205]. Let alone the use of data whichwas not intended by the user, e. g., creating profiles for advertisement purposes.

Software-Centric Attacks. This category describes attacks related to software run-ning on smartphones. This includes applications which are additionally installed bythe user, applications and components provided by the operating system as well assoftware which is related to hardware tasks, e. g., the firmware of the GSM modem.Security relevant bugs can be found in all these layers and we give examples ofprominent ones which were discovered recently. A general overview of different bugclasses reports on particular bugs are provided by several websites, e. g., [9].

Let us start with applications which are not preinstalled on smartphones. Such ap-plications are mostly installed through the market applications we already discussed.

28


Although the market vendors claim to review the applications, bugs will always slipthrough this process and end up in applications installed on many smartphones.While most of the bugs are unintentionally “added”, some of them are security rel-evant for the end user. One example are so called confused deputy attacks, whereone privileged application—the deputy—offers a service to an unprivileged applica-tion and is tricked into abusing its privileges. A special case of such attacks arepermission re-delegation attacks [82], where the deputy holds additional permissionswhich are then misused. This could lead to, e. g., the disclosure of sensitive data.Problems also arise if the application developer is not aware that some features canbe misused. A bug recently discovered in WhatsApp for Android allowed other ap-plications to retrieve chat protocols after they were stored on the SD card wherethe operating system cannot easily enforce access restrictions [42]. Next to buggysoftware, attackers often distribute malware which directly follows a malicious cause.We report about this in Section 2.1.4.

We now focus on the operating system itself and its components. Usually, the useris not allowed to modify the OS and its components. This somehow strengthenssecurity because crucial components cannot be modified, but also weakens it if somebug opens up an attack vector while the user depends on the vendor to fix it. If onelooks through bugs found in mobile operating system components, many of themare security relevant. Recently Apple shipped its standard SSL/TLS library with abug which completely invalidated the signature check for established secure connec-tions [8]. While the user could not count on secure connections anymore, he had towait for Apple to release an update. Another example would be Samsung, whichprovided software to communicate with the modem with a “backdoor” which enablesan attacker to gain file access to usually unreadable files [184]. It seems the back-door was accidentally introduced into the code and is a good example of a confuseddeputy attack. Since some of the provided applications are heavily used by a greatmargin of the users, e. g., the default Web browser, security flaws in such productsaffect a great number of people. Security related bugs in the operating system cangive attackers complete control of the device, as they might get root access that way.Examples are the root exploits Rage Against the Cage for Android [16] and redsn0wfor iOS [63].

Let us end this paragraph with security relevant flaws in software which directlyruns on hardware components also found in smartphones, so called firmware. Typicaldevices would be the GSM modem, the WiFi interface or the camera. While the useritself usually never directly interferes with this type of software, it is still a crucialpart of the smartphone and can offer attack vectors if the software is exploitable andcan communicate with the smartphone in some way, e. g., over some bus system. Ofparticular interest are malicious removable hardware devices which are trusted bythe smartphone when attached. One example would be SD cards, which can often be

29


used to extend the phones internal storage capacity. Some cards can be flashed witha custom firmware which can then lead to MITM attacks against the file system [46].This can be used by an attacker to circumvent file access checks.

The described software related attack vectors only provide a rough overview assoftware in general can contain many different security relevant flaws, especiallylarge programs. Again, a more detailed description can be found in the work ofBecher et al. [38].

Layer-8 Attacks. This special category relates to the smartphone user and de-scribes all non technical problems. “Layer 8” refers to the OSI model [118] where7 abstraction layers describe the internal functions of communication protocols.Layer 1 represents the physical layer, describing the physical properties the pro-tocol is based on ranging to Layer 7 which describes the application with which theuser interacts. Layer 8 refers to the user himself, but is not part of the OSI model.It is still used to describe aspects of the human element as we also do.

Attackers often target the weakest element in a “security chain” while attackingsomething. What use has a proper designed permission system for applicationswhen the user just installs any application he wishes despite all permission warn-ings? What if the user just accepts all security relevant questions which pop upif something (bad) is about to happen? The best cryptography protocols just fallapart if the user is tricked into installing a fake certificate which is afterwards trustedby the operating system and enables an attacker to easily mount man-in-the-middleattacks against encrypted connections. Most users are not familiar with security ingeneral and often do not understand complex systems such as smartphones. Theyare not able to deduce the implications of security relevant actions. Neither do theyeven want to care about such things, they just want things “to work”. A studyconducted by Felt et al. [81] revealed that some Android users are not even awarethat the required permissions are shown and have to be explicitly accepted beforean application is installed. They just over-read the complete process because theyknow that they will only be able to successfully install applications if everything is“accepted” by pressing the appropriate Yes or Ok buttons. This behavior makes iteasy to trick people into doing things they should better not do—this is also knownas social engineering. Preventing such attacks is a very difficult task [157].

2.1.4 Mobile Malware

We now report on malicious software for mobile devices. Before the era of smart-phones, there already existed malware written for Symbian, Windows Mobile as well

30


as J2ME capable phones. It all started in 2004 with a few viruses and trojans forSymbian, such as Cabir and Skulls, and with Dust and Brador for Windows Mobile.In 2006 J2ME was targeted with two trojans called RedBrowser and Wesber. Whilesome of the early samples were proof-of-concept viruses, others were already ableto provide an attacker full remote control over the device. The functionality of themalware was getting better over the years, although almost no malware author hadthe goal to directly monetize a successful infection. Exceptions are RedBrowser andWesber which send premium rate short messages as well as Pmcryptic which wasreleased in 2008 for Windows Mobile and dialed premium numbers. A detailed listand a description of many malware families for these operating systems was com-piled by Becher [37] which is also the source for the information previously providedin this paragraph.

Coming back to smartphones, malicious software of course exists for all smartphoneoperating systems. Still, we focus on Android as explained earlier. In Figure 2.2 onpage 17 we already visualized the constant rise of Android malware and now takea closer look at it. McAfee published a whitepaper where the “history” of Androidmalware is summarized until mid 2011 [50]. The following information is based onthat whitepaper unless cited otherwise.

It all started in August 2010 with a malware named FakePlayer, a SMS trojan. Theapplication itself appears to be a media player but offers no such functionality—instead it sends short messages which cost about $5 per message. The malware isreally simple, was not widespread and also was not available in the official marketbut still marks the beginning of an era of malware for Android. Before this very fewmalicious applications were to be found and these were either proof-of-concept onesor did not catch much attention at all.

In the same month a game resembling the classic “snake” game was found. Whilethe game was playable, in the background the malware collected and sent the GPScoordinates to a remote server. Another application could be purchased to viewthe stolen information on Google Maps, enabling someone to spy on someone’ssmartphone. The malware was named Tap Snake after the game and is a typicalexample of spyware.

While several other malicious applications were found in 2010, one is of particularinterest. In the end of the year Geinimi was discovered, a malware much moresophisticated than the previous ones. It could be found in repackaged legitimateapplications such as the game Monkey Jump 2 which were distributed in unofficialmarkets. It offered encrypted network communication and contained obfuscatedcode, both hindering its analysis. According to an analysis from Lookout [239] itis able to send geolocation data and is able to un- as well as install applications.The most interesting functionality though was its ability to be remote controllable,

31


offering botnet capabilities—something not seen before for Android malware. A fullyworking control server has never been observed, though. Still, Geinimi raised thebar for Android malware quite a bit and beginning in early 2011 many repackagedmalicious applications were distributed mostly in unofficial markets.

In March 2011 repackaged malicious applications were “finally” found in the officialAndroid market. Analyses revealed that they were not just a new version of Geinimibut a completely new malicious family which was named DroidDream. Despite itsability to steal sensitive information such as the IMEI and IMSI, it also contained aroot exploit which could break out of Android’s sandbox and gain root access whichwould then eventually be used to gain full control over the smartphone. DroidDreamwas also able to download and execute additional code from the Internet, extendingits functionality arbitrarily [97]. In the end, Google removed the malware fromthe market and remotely uninstalled it from all devices, as well as undoing the rootexploit. Nevertheless, in four days 50,000 to 200,000 downloads were registered fromthe market. Later in May a very similar malware named DroidKungFu was foundin the official market which had the same functionality as DroidDream, albeit usingstronger encryption mechanism to protect additional malicious content.

Then, in June 2011 a spyware named Plankton was found in many applicationsin the official market which was downloaded over 100,000 times. Directly after itsdetection, people discussed whether it should be classified as malware or not [223].The malicious code part seems to be provided by the Apperhand SDK which is usedby software developers to monetize their applications in some way. The SDK addscode to gather a lot of private information about the phone and the user (IMEI,IMSI, bookmarks and many more) and sends them to a remote server. It couldbe classified as a very aggressive ad network. Additionally, it makes use of theDexClassLoader, a class loader provided by the official Android API. This classloader is used to download additional code from the Internet and execute it, makingthe application very difficult to analyze. It also features commands which can berun remotely, offering botnet capabilities. But, the applications did not behavelike a typical malware, they only performed actions which were also described intheir corresponding descriptions. Despite not being malicious per se, the software’sfeatures are very malware like and absolutely suspicious and are therefore oftenclassified as malicious.

In July 2011 also the first version of Zeus for Android, or correctly ZitMo (Zeus-in-the-Mobile), was spotted [151]. Zeus is a trojan specialized in stealing online bankinginformation like TANs and was first seen in 2007 [219]. ZitMo is also specializedin stealing banking information, especially in defeating two-factor authenticationfor online banking. Typically, the bank sends a secret mTAN (mobile transactionauthentication number) to a mobile phone which is then used to authenticate the

32


transaction which is performed on the PC. ZitMo is able to intercept such SMS andto silently forward them to the attacker, enabling her to secretly process transactionsin the user’s name. Online banking customers are especially at risk if they perform itdirectly from a smartphone’s browser as the second “factor” for authentication mightnot be given anymore. If the smartphone is also the destination for SMS containingmTANs which are used to authorize online banking transactions, an attacker mustonly get access to one device—in this case the smartphone—defeating the purposeof a two-factor authentication.

Then, in June 2013, a trojan named Obad was found by Kaspersky Labs who alsoprovide a nice summary [227] on which the following information is based. Obadis capable of the usual functions trojans provide like sending SMS, stealing privatedata, installing additional software and so on. There are though a few things whichmake it really special. The malware contains code which exploits a bug in the analy-sis tool dex2jar [12] which is often used to analyze applications—therefore hinderingits analysis. It also exploits buggy code in the Manifest parser (a file which con-tains information about the program, such as entry points or requested permissions)leading to a corrupted Manifest file which cannot easily be parsed by other toolsbut is accepted by the Android parser. This also hinders a fast analysis. Addition-ally, the authors abuse a previously unknown error in the operating system whichenabled the malware to gain Administration privileges although it does not appearin the list of such applications—making it impossible to remove it again. Exploitingthree previously unknown bugs at once was not seen before in Android malware,but Obad even had more things to “offer”. Its code is completely obfuscated: Allstrings are encrypted and some crucial ones, such as the C&C server address, canonly be decrypted if an Internet connection is available next to invoking methodsover the Java Reflection API—again hindering (static) analysis attempts. The bot’sfunctionality enables the attackers to execute arbitrary code, spawn remote shellsand to proxy connections through the smartphone to any remote computer. Obadalso tries to spread itself via Bluetooth by copying a file to remote devices. Thismalicious software clearly raised the bar for Android malware and introduced a lotof features seen in advanced Windows malware families.

Where does that leave us? The evolution of mobile malware exemplified for Androidin this section clearly shows the need for proper analysis techniques. Smartphonescontain so many datasets which attackers are eager to get their hands on, the useris often not aware of any security risks and the smartphone itself can be integratedinto a botnet to serve attacker’s purposes, just like for normal PC malware. Allin all, smartphones are a valuable target for malware authors. The rising amountof malware found in the wild tells the same story. Figure 2.3 exemplifies this withthe steady growing number of known malware families for Android. Although mo-bile malware is not yet as sophisticated as Windows malware—we have not seen

33


a single worm yet—, its complexity is getting better over time. Still, even simplemalware applications or PUPs, which stands for Potentially Unwanted Program (seeMcAfee’s writeup [153] explaining the term in more detail), that “just” steal someinformation are attractive and are even successfully distributed over official markets.We therefore write about different analysis techniques for mobile malware to countersuch threats in the next section and clarify our contributions in this field.

H1 2012 H2 2012 H1 2013 H2 2013 H1 2014Half-year

0

100

200

300

400

500

600

700

Kno

wn

Fam

ilies

Figure 2.3: Amount of known malware families for the Android operating systembased on data kindly provided by GData.

2.2 Analysis of Malicious Software

After reading the previous sections, it should be clear that there exists a need fortools in order to analyze smartphone applications, just like it exists in the PC world.In this section we describe program analysis approaches in general; specific analysistools aimed for mobile applications are later covered in Section 5.

In general, there are two approaches to analyze an application: static and dynamicanalysis techniques. Both are not restricted to smartphone applications and areusually applicable to all programs. We now first describe static analysis techniques

34


followed by dynamic ones. Thereafter we talk about their drawbacks and the prob-lems that arise with these.

Within this section we also point out which contributions we made in each of thoseresearch fields and revisit many aspects covered here in Chapter 3 and 5.

2.2.1 Static Analysis

Static analysis covers aspects of programs without the need of actually running thecode itself. It is performed on source code or on compiled code. Since source codein general provides much more information such as proper names for, e. g., variablesand methods and not-optimized code constructs, an analysis performed on it mayproduce better results. But source code is often not available, especially in the casefor malware, and therefore many approaches also work with compiled code. Sincethe application is not executed at all, it is often not known which branches are takenand therefore which code paths will be executed, as long as such decisions can onlybe made during runtime. Despite this drawback, it provides the analyst an abstractview of the complete application.

With the help of created Control Flow Graphs (CFG), the analyst is able to un-derstand the inner workings of methods, since all non-branching instructions arerepresented in basic blocks which are itself connected depending on the control flow,e. g., jump targets. While the basic blocks represent nodes which are connected bydirected edges based on the control flow, they form a graph, in this case the CFG.

Another graph often utilized is the Call Graph (CG), where the nodes representmethods and directed edges represent called methods from those methods. Whilethe CG can quickly become very huge depending on the application’s “size”, one canquickly locate entry points, uncalled methods and determine how values are passedbetween method calls.

A third often used graph is the so called Program Dependence Graph (PDG). Thisgraph represents which code constructs (data or code) are depending on which otherconstructs. Program Slicing [235] uses PDG’s in order to, e. g., detect which instruc-tions affect a specific variable or register. With the help of PDGs so called use-defchains (for an explanation see Section 3.4.2) can be built which only contain thoseparts of the application which affect something of interest to the analyst.

Next to the graphical representation of the program’s functionality, one can of coursealso make use of simpler approaches such as looking at strings, the amount of meth-ods and so on, depending on the analyst’s goal. We cannot describe all possiblestatic analysis techniques here but the interested reader might look into the work of

35


Nielson [167] as a stating point. We present the results of some of those techniqueswhich we used to analyze Android applications later in Section 3 and also presentspecific static analysis tools for the Android platform in Section 5.

Our contribution in the field of static program analysis is placed around ProgramSlicing. Since this is a very powerful analysis technique in general and no tool wasavailable for Android by the time of conducting this work, we build a prototypecalled Saaf which introduces Program Slicing for Android applications. A specificscenario would be to, e. g., determine the telephone number and the text message ofall calls to Android’s API which send short messages. That way the analyst couldcompare the text and the number against known premium numbers and subscriptionmessages in order to see whether an application is potentially malicious or not. Thetool and the techniques are described in detail in Section 3.

2.2.2 Dynamic Analysis

Dynamic analysis involves the execution of a program—in contrast to a static analy-sis. While probably not all code paths are executed depending on the taken branches,dynamic analysis often only results in a subset of all possible control-flows beingtaken. For these code paths, actual values assigned to registers and the like canbe observed, resulting in a much less abstract view of the program with respect tothe executed code paths. Dynamic analyses can also reveal the effects a runningprogram has to its environment such as which files are being accessed.

Since the behavior of the analyzed program is often unknown and in the case ofmalware often unwanted, dynamic analysis is often performed in emulators or virtualmachines. Depending on the data of interest during the analysis step, the analysiscomponent can reside in different locations, e. g., the operating system kernel, some(injected) library, code injected inside the analyzed application itself or even in thehypervisor or hardware to name but a few. Depending on where and which datais gathered, the results can be coarse or fine grained, ranging from, e. g., completeURLs of accessed web sites to raw memory data which was somehow accessed.

In order to tackle the problem of only being able to analyze taken code paths, dif-ferent solutions were invented. Multipath execution is one of those techniques [160].Whenever a branch is taken, a snapshot of the application is taken in order to laterroll back to it and also execute the non-taken path. That way, code coverage rises butthis also results in problems with, e. g., stateful connections as they incur in TCP.Dynamic symbolic execution is another technique to improve code coverage [209].Here, the program is run with different inputs in order to reach all feasible paths.The size of the program tree quickly leads to the problem of path explosion, from

36


which also multipath execution tools suffers, as its size grows exponential with re-spect to the branches. In order to tackle it, selective dynamic execution can be usedto only execute branches of interest [56].

Since the program’s outputs are unknown prior to execution, an analyst might onlybe interested in specific actions the program might take. For smartphone applica-tions it might be interesting whether the application reads contact information andsends it to some server over a socket. Detecting such scenarios is the goal of taintanalysis [201, 76]: The analyst specifies a set of sources (e. g., the contact list) anda set of sinks (e. g., a TCP socket) and the analyzer will taint all data read fromsources and will generate a report if such tainted data is sent to a sink.

Especially in the Android environment, many dynamic analysis tools reside in An-droid framework components. That way they can, e. g., control which contentproviders are accessed, which IPC messages are exchanged or which sockets areopened. We later in Section 5 describe many analysis tools specific to Android, butas for the static analysis approaches, we can also not describe the dynamic ones herein a thorough manner but instead refer the reader to the work of Willems [236] andEgele [71].

For this part our contribution took a completely different approach. Instead ofanalyzing a running application on a smartphone or emulator in some of the “tra-ditional” ways, we looked at one specific aspect which often cannot be found innormal execution environments, namely the battery and its limited energy supplynext to the power consumption of the analyzed application. In theory, every exe-cuted instruction consumes some amount of energy which drains the smartphone’sbattery—unless it is being charged. Our work described in Section 4 evaluateswhether certain (malicious) activities can be detected on a mobile device by onlylooking at their measured power consumption and comparing it to a previouslygenerated power model.

2.2.3 Limitations

We already mentioned some of the drawbacks that static and dynamic analysisapproaches have. Static approaches on the one hand cover the complete program,but can only provide an abstract view on it. Dynamic approaches on the otherhand can yield precise analysis results because runtime data is available and exactprogram values can be retrieved, but those observations result only from the takencode paths instead of the complete program code. Therefore, a thorough analysisoften incorporates both approaches in order to get good analysis results.

37


Despite these restrictions, other synthetic problems might be encountered. Staticanalysis gets much harder if the program is obfuscated. Depending on the level ofobfuscation, some static analysis approaches might even be completely useless. If,e. g., each method invocation is only done indirectly, a Call Graph can hardly begenerated. On Android, e. g., this is possible if the Java Reflection API is used toinvoke methods and create new objects instead of the usual invoke and new-instanceinstructions. Dynamic approaches can be countered by code which detects the mon-itoring and consequently takes appropriate actions, such as letting the applicationcrash or execute only benign code in case of malware. Approaches like Taint Anal-ysis can also be defeated by code which makes it extremely hard to maintain thetags or to not “overtaint” data [201].

As we already previously mentioned, we can only give a rough overview on this broadtopic in this thesis. We later come back to this topic in Section 5 when we elaborateit specifically for the Android platform. Our contribution here is that we createda toolkit which obfuscates Android applications and has the goal to specificallydefeat most of the used dynamic and static analysis approaches in order to revealweaknesses and deficiencies in these. While we do not directly target the tools, wetarget the assumptions on which they operate. Meaning, that if some logic operateson Call Graphs, it will not be able to perform correctly if no valid Call Graph canbe computed in the first place. It is undisputed that malware for mobile devices isbecoming more and more widespread and sophisticated; in order to keep up withmalware authors available analysis tools also have to evolve. We report on the stateof many tools in Section 5.

2.3 Specific Security Aspects

In this section we pick up specific aspects which are mostly only relevant for mobiledevices which are daily used and therefore most of the time are “with us”. Thisalways present, always on and always usable manner implies a few security aspectswhich at least deserve a few thoughts.

Loss of Ownership. Since most people want immediately access to their smart-phone almost everywhere, they of course carry them around at almost all times.This causes a lot of smartphones to either get lost or being stolen because of theirmonetary value. According to a study published by Lookout in 2012 [146], “U. S.consumers lose their phone about once a year” in 2011. A lost smartphone has seri-ous implications for the designated owner since the finder now probably has access

38

2.3 Specific Security Aspects

to the data which is stored on the smartphone, including personal data such as pic-tures and stored conversations let alone credentials. If the phone is not encryptedor even properly locked, such data is easily accessed and might end up in the wronghands. Another study published by Symantec in 2012 [217] confirms such fears.The study reveals that 96% of found smartphones were accessed and that 89% ofthe finders accessed personal data and 83% accessed corporate data. Although also50% contacted the owner in order to return it, private and corporate data is at riskif the smartphone is lost or stolen and not properly secured.

Display. Smartphones are used in almost all situations for arbitrary purposes. Themain output and input device is the touch display—a very prominent part of suchdevices. Often, smartphone users are not alone and bystanders can easily see whatis displayed and probably also what is inputted. This is called shoulder surfingand sensitive information might be exposed that way. Another risk pose so calledsmudge attacks [31]. The oily residues often left on the display after using it mightexpose, e. g., used login patterns which is a serious problem if the smartphone is lostor stolen as an attacker might get access to it even if it is locked.

Charging. Smartphones are battery powered and one charge often does not holdfor a complete day, depending on the usage behavior. This means that smartphonesare often charged in order to be operational and people often attach their phonesto foreign chargers or computers. Depending on the smartphone’s setup, the phonemight immediately establish a USB connection and offer mass storage device capa-bilities or similar functions (PTP or MTP modes) to the remote side. In the worstcase even a debug connection can be established. If the charger is not trustworthyit might steal information that way, possibly without the owner recognizing it [138].Two examples would be that pictures taken by the camera could be downloaded ormalicious software could be uploaded to the SD card which is eventually automati-cally executed the next time a Windows PC is connected.

Interfaces. As we already described earlier in this section, smartphones offer amultitude of interfaces in order to stay “connected” with its environment. Often,WiFi networks are utilized to lower the burden put onto paid data plans establishedwith the mobile carrier. If the smartphone automatically connects to open WiFinetworks, e. g., in an airport or café, unencrypted data might be eavesdropped andpotentially also even altered. This offers a lot opportunities to attackers for so calledMan-in-the-Middle attacks. If not configured correctly, automatically establishedconnections might expose sensitive data or might even result in a compromisedphone.

39


Since smartphones offer a lot of unique possibilities, we thought about how wecould leverage all these options in order to secure a “normal PC” with the help ofa smartphone. Our smartphones are mostly trusted devices and we happily inputor store credentials on it, e. g., for websites where we regularly log in. Despite thecomfort smartphones offer, their screen sizes are still a reason why we often switchto a normal PC with a regular monitor and keyboard. But what if we do not fullytrust a PC and have concerns to input our credentials for, e. g., social media websitesor a web store? Imagine someone wants to use a co-worker’s or friend’s PC or apublic terminal in an Internet café. Our contribution here is that we came up with asolution that makes use of a regular smartphone and enables us to use an eventuallycompromised machine without worrying about our credentials.

Under the aforementioned premise, we invented a tool called SmartProxy whichutilizes the interface variety a smartphone usually offers to easily connect it to aPC. This connection can then be used in a way that the smartphone acts a proxyfor connections which are established by the PC, e. g., by the means of the webbrowser. Because the smartphone acts as a proxy it can also peek at the dataexchanged between the PC and some remote server. Required credentials must notbe entered into the untrusted PC anymore, but can be transparently injected byour proxy. This setup also allows us to strip security relevant information from theconnection before it reaches the PC, e. g., cookies or a session id in a URL. A possiblecompromised machine cannot get hold of credentials or other security relevant databecause they are never inputted nor do they reach it. That way we can enjoy thecomfort the PC offers while making sure our credentials are safe. We describe oursolution in detail and also cover the aspects of encrypted connections in Section 6.

2.4 Discussion

In this chapter we clarified the term mobile security. While many discussed aspectsare related or even the same compared to computer security in general, all thecomponents and features, which make a phone smart, bring up the field of mobilesecurity. We discussed smartphone features and their security mechanisms next toattack vectors and malicious software targeted at such devices. After clarifying theneed for proper analysis techniques for mobile applications throughout this chapter,we gave a brief introduction into program analysis in order to get a hold againstmalicious software which tries to exploit security flaws or attempts to strip unawareusers of their money. Lastly, we also pointed out aspects which are typically onlyrelated to mobile devices.

40

2.4 Discussion

The rest of this thesis is structured as follows. In the following chapter we introduceour work in the field of static program analysis. To be more precise, we presenta prototype named Saaf which enables an analyst to perform program slicing onAndroid applications next to other analysis techniques. Afterwards, we present ourworks in the field of dynamic program analysis. In Chapter 4 we evaluate howprecise (malicious) activities can be detected by the means of the consumed energyof mobile applications. After the presentation of our contributions in the field ofmobile program analysis, we evaluate how robust state-of-the art analysis tools formobile applications are against software, which tries to thwart analysis attempts.We therefore present a tool in Chapter 5 which obfuscates Android applications andhampers static as well as dynamic analysis attempts. With this contribution weshow that many tools cannot analyze well-obfuscated applications and that thereexists a need to adapt to the rising number of sophisticated malware samples. Afterwe have presented our work in the field of program analysis we change our point ofview in Chapter 6. We present a prototype named SmartProxy which is able toprovide secure use of a compromised PC with the help of a smartphone. Afterwards,we conclude this thesis in Chapter 7.

41

3Static Approach based on Program Slicing

We now present our work in the field of static program analysis for Android ap-plications. This chapter results from a publication [112] at the ACM Symposiumon Applied Computing (SAC) in 2013 in cooperation with Martin Ussath, MichaelSpreitzenbarth and Thorsten Holz. This work has been supported by the FederalMinistry of Education and Research (BMBF grant 01BY1020 – MobWorm). Wewould also like to thank Tilman Bender, Christian Kröger, Hanno Lemoine, andTeemu Rytilahti for their help on the created prototype and the analysis of thedata.

Abstract. The popularity of mobile devices like smartphones and tablets has in-creased significantly in the last few years with many millions of sold devices, as wealready pointed out in the previous chapter. This growth also has its drawbacks:Attackers have realized that smartphones are an attractive target and therefore dif-ferent kinds of malicious software for such devices have emerged. This worrisomedevelopment has the potential to hamper the prospering ecosystem of mobile devicesand the potential for damage is huge. Considering these aspects, it is evident thatmalicious apps need to be detected early on in order to prevent further distributionand infections. This implies that it is necessary to develop techniques capable ofdetecting malicious apps in an automated way.

In this chapter, we present Saaf (Static Android Analysis Framework), a tool toanalyze Android applications. Saaf analyzes smali code, a disassembled version ofthe DEX format used by Android’s Java VM implementation. Our goal is to createprogram slices in order to perform data-flow analyses to backtrack parameters usedby a given method. This helps us to identify suspicious code regions in an automated

43

3 Static Approach based on Program Slicing

way. Several other analysis techniques such as visualization of control flow graphs oridentification of ad-related code are also implemented in Saaf. We present analysisresults obtained by using these techniques for more than 136,000 benign and about6,100 malicious apps.

3.1 Introduction

Within the past several years, the popularity of smartphones and other kinds of mo-bile devices like tablets has risen significantly, as discussed in Section 2. This factis accompanied by the large amount and variety of mobile applications (typicallyabbreviated as apps) and the increased functionality of the mobile devices them-selves. Several mobile operating systems are available, with Android and iOS beingthe most popular ones. As a side effect of this popularity, centralized applicationmarketplaces like Google Play and Apple’s App Store have massively grown. Suchmarketplaces enable developers to upload their own applications in a convenientway and users can download these apps directly to their mobile devices. Besides theofficial markets from platform vendors (e. g., Google and Apple) and manufactur-ers (e. g., Samsung and HTC), a large number of unofficial third-party marketplaceshave emerged. Most of these markets contain thousands of apps and have millions ofdownloaded apps per month. For example, Google Play users download more than1.5 billion applications each month and more than 1 million new Android devicesare activated each day [99].

This fast growth rate also has a downside: Attackers have realized that rogue appscan be used to target smartphones and in the recent past, malware for smartphonesbecame popular. According to GData, during the second half year of 2013, almost741,000 new malicious Android samples were seen in addition to the 520,000 seenones from the first half year (cf. Figure 2.2 on page 17). Symantec’s analysis ofthe Android.Bmaster malware [162] demonstrates the possibilities that an author ofmalware has: In this particular case, the amounts of money charged for a premiumSMS that was sent by the malicious app is between 15 and 30 cents. Multiplying suchsmall amounts with the number of potentially infected devices suggests that attacksagainst smartphones are a lucrative venue for adversaries. Unfortunately, it is hardto independently verify these numbers and objective measurements are missing.However, the often predicted rise of malicious software [38, 60, 130, 139, 140, 170]might finally come true given the recent developments.

Considering these aspects, it is evident that malicious apps need to be detected earlyon in order to prevent further distribution and infections. In addition, we need toconsider the growth rates of the app markets—a manual analysis is infeasible and

44

3.1 Introduction

automated approaches are needed to tackle this problem. This implies that it isimportant to develop efficient and automated analyzing techniques that allow for areliable assessment of an analyzed app.

We therefore present Saaf, a static malware analysis framework for Android appsthat is able to recognize suspicious behavior patterns in an automated way. Saafanalyzes smali code, a disassembled version of the DEX format used by Dalvik, An-droid’s Java VM implementation. This approach enables us to perform a robustanalysis that overcomes limitations of state-of-the-art tools that rely on disassem-blers to Java code, a process that is fragile in practice [74]: Enck et al. introducedded, a decompiler capable of analyzing about 94% of the total classes in the appli-cations studied. In contrast, Saaf is able to analyze all 140,000 applications as longas the smali code can be generated from the provided dex code (see Section 3.5 formore information and detailed analysis results).

Due to the prevalence and timeliness of malware for smartphones, this topic hasreceived a lot of attention recently (e. g., [62, 76, 74, 13, 251]) and our approachextends prior work in this area. Saaf performs static data-flow analysis [24, 87](more precisely program slicing [235]) to backtrack the parameters used by a givenmethod. This enables us to identify suspicious code regions within a given app, wecan for example detect whether a given app sends premium SMS in an automatedway. Several other analysis techniques such as visualization of control flow graphs,a Manifest parser, and identification of ad-related code are also implemented in thetool. Based on our prototype implementation, we report on analysis results of morethan 136,000 benign and about 6,100 malicious applications. We confirm severalfindings reported in other papers for smaller sample sets [74] and provide novelinsights into the behavior of typical apps.

In summary, we make the following contributions:

• We introduce Saaf, a static analysis framework for Android apps. Saafimplements different program analysis techniques such as data-flow analysisand visualization of control flow graphs.

• In an empirical study, we analyzed more than 136,000 benign apps and about6,100 malicious ones. Our results confirm observations previously reported forsmaller sample sets and provide some new insights into typical Android apps.

This chapter is organized as follows. We will first present related work in the follow-ing section, followed by an overview of our prototype called Saaf in Section 3.3. Wewill then report on our implementation of program slicing in Section 3.4 followed byan evaluation in Section 3.5 where we present our results obtained from the analyzed

45


applications. We will then summarize our work and report on the limitations of ourprototype in Section 3.6.

3.2 Related Work

Security aspects of smartphones have received a lot of attention recently and we arenot the first to introduce analysis techniques for mobile apps. In the following, wediscuss how Saaf relates to prior work in this area. We focus our discussion onother static analysis approaches, especially since many papers have been publishedin this area concurrently to our work. Afterwards, we also briefly discuss dynamicanalysis techniques, which are basically complementary to our approach.

Androguard is a toolset to decompile and analyze a given application, with the goal todetect malicious apps via signature matching [62]. We do not require decompilation,since this processing step might introduce imprecision in cases where the decompilerdoes not successfully reconstruct valid Java code, a problem that often occurs inpractice [74]. Furthermore, Saaf does not only rely on pattern matching or staticsignatures and Androguard is not working in a fully automated way, which impliesthat the tool is not designed to handle a large corpus of apps.

Kim et al. presented a tool called ScanDal that is able to automatically detect privacyleaks [127]. The authors evaluate ScanDal with a very small sample set containingonly 8 malicious and 90 benign samples. In addition, ScanDal has some limitations,as it does not support reflection-related APIs which we do to some extend as we willlater present. Our evaluation set is three orders of magnitude larger and we expectthat it provides a more realistic overview of the current threat landscape.

Another tool closely related to our approach is ded, a decompiler that recoverssource code of Android applications directly from their installation images [74]. Thetool infers lost types, performs Dalvik VM to Java VM bytecode retargeting, andtranslates class and method structures. Furthermore, the authors studied 1,100benign Android apps to better understand the security characteristics. Comparedto ded, Saaf has a higher coverage: The authors of ded report that about 94%of the total classes in the applications studied could be recovered. In contrast, weare able to analyze all smali files which are generated by the android-apktool. Ouranalysis results are similar to the ones found by Enck et al. and confirm the findingsreported on a larger sample set.

Grace et al. demonstrate with their RiskRanker approach how to scan applicationmarkets for unknown malware samples [104]. Their approach is two-tiered: Withinthe first detection stage, RiskRanker tries to find apps with native code that use

46

3.3 High-Level Overview of SAAF

known root exploits or that send premium SMS messages. The second stage dealswith obfuscated apps and tries to detect malicious apps that are encrypted or thatload additional code. The system found 322 new instances of malware in a totalset of 118,318 applications collected from various Android markets. The focus ofSaaf lies on static analysis techniques and we implemented (among other programanalysis techniques) a data-flow analysis technique to determine which parametersof a method are static and might result in malicious uses.

There are several papers that touch on various Android-related topics and thesepapers also have a small overlap with our work. We briefly discuss this kind of workbut do not elaborate it in detail since the overlap is rather small. For example, Elishet al. implemented a static approach for malware identification based on user-centricdata dependence analysis [72]. DroidMOSS uses a fuzzy hashing method to detectrepackaged apps in third-party Android markets [248]. The detection of privacyleaks and the unwanted access to user-related data on the Android platform hasbeen explored extensively in the past. Some examples for detecting and mitigatingthese leaks are provided by Gibler et al. [96] and King et al. [128]. Regarding the in-app ad-networks, Stevens et al. [213] and Grace et al. [102] performed some similarresearch.

One of the first dynamic malware and privacy leak detection systems was Taint-Droid [76]. It is an efficient and dynamic taint tracking system that provides real-time analysis reports by leveraging Android’s execution environment. This systemwas complemented with a fully automated user emulation and reporting systemby Lantz and is available under the name droidbox [13]. Both systems are un-able to track native API calls and are slow compared to a static analysis approachlike Saaf or the ones discussed above. DroidRanger implements a combinationof a permission-based behavioral foot printing scheme to detect samples of alreadyknown malware families and a heuristic-based filtering scheme to detect unknownmalicious apps [251]. With this approach, the authors were able to detect 32 ma-licious samples inside the official Android Market back in June 2011. Within theirdynamic part, they use a kernel module to log system calls used by known Androidmalware. As discussed above, such dynamic approaches are complementary to ourtool Saaf: static and dynamic analysis approaches can be combined to enhance theanalysis results.


Saaf is able to perform static analysis of Android applications and also supports ahuman analyst to understand the behavior of a given app. The tool offers a graph-

47


ical user interface and also supports automated analysis tasks such as automatedunpacking and disassembling of applications. Furthermore, the tool can visualizethe contents and code of a given app, and also offers several inspection tools to per-form various program analysis tasks. In the following, we first provide a high-leveloverview of the features provided by Saaf and then discuss implementation detailsspecifically related to data-flow analysis in Section 3.4.

Saaf covers an important aspect of an app analysis process: automated static anal-ysis. Our implemented variant of data-flow analysis [24, 87], namely program slic-ing [235], enables our tool to automatically search for constant values which are usedas parameters in defined method invocations. This way, the analyst can for exampledetermine if an application is able to send short messages to a hardcoded number—which would result in a strong misuse potential of this application. This search iscalled static backtracking and we describe it in detail in the next section. All foundconstants are stored in a MySQL database or an XML report and are accessiblefor later analyses. Based on these results the analyst can, e. g., let some heuristicdecide which apps are worth a more thorough inspection because they might exhibitmalicious behavior: long sleep intervals, hardcoded telephone numbers, calls to sudoand so on (see Section 3.5.1 for more details).

Furthermore, Saaf does support an analyst doing a manual inspection. After anapplication is loaded within the framework, the analyst has access to options suchas:

• Navigate through the application contents which are presented in a tree struc-ture. Smali and optionally decompiled Java code is accessible, which is colored,and links to labels and methods are clickable.

• Saaf makes use of the Android Permission Map [79] and shows which methodinvocations require which permission(s).

• Program entry points such as Activities, Services and Receivers are easilyaccessible.

• Control flow graphs (CFGs) can be generated and exported.

• Saaf offers the possibility to search for several program components, e. g.,strings, invocations and opcodes in general.

• Saaf knows about ad package paths and can ignore classes inside them.

• So called quick checks provide the analyst with a quick overview of the pro-gram’s functionality. They perform checks to output whether certain APImethod are used, e. g., the Reflection API, classloaders or the SmsManager.

48


They are easily extendable and one such check is introduced in more detail inSection 3.5.

Figure 3.1 shows a screenshot of Saaf. What can be seen is the tree structure ofthe content and the code of one selected smali file. Below the tree structure is alist of all application entry points and on the right is a list of all methods withinthe selected class to easily navigate through it. The log output can be seen at thebottom. Figure 3.2 shows an exemplary control flow graph of some application.

Figure 3.1: Screenshot of Saaf. On the left side the file tree and all entry pointsare listed. The right side shows the methods of the visible smali code inthe center. Log messages are shown on the bottom.

An automatic analysis should run in the background, possibly on a large set ofapplications. Obviously, a GUI would hamper such a task and Saaf thus offers alot of command line options to properly work without a GUI.

Being a static analyzer, Saaf is expected to work fast for our use case. Manyapplications need to be analyzed in a short amount of time to quickly get an ideawhich applications need to be investigated more closely by means of a more expensivemanual or dynamic analysis. A static analysis of a typical app from our evaluation

49


Figure 3.2: Exemplary CFG of Saaf. The shown code tries to send a short messageand in the case when no exception is thrown returns the boolean true(left branch). Otherwise (right branch) it handles the thrown exceptionand generates a log message before returning.

set is completed in less than 10 seconds on average. Sometimes the process is evenfaster, if the application is small.

Saaf is written in Java and the full source code can be found at http://code.google.com/p/saaf/. It is licensed under the GPL v3 license as open-source soft-ware.

3.4 Static Backtracking

The ability to perform static data-flow analyses [24, 87] of method parameters (calledstatic backtracking in this work) is one of the core components of Saaf. It enablesthe analyst to define a set of methods of interest with their respective signature(parameters), in order to see whether they obtain any constants as input. This isof interest if, for example, the analyst wants to determine if some application is

50

http://code.google.com/p/saaf/

http://code.google.com/p/saaf/


able to send short messages to a hardcoded number or with any hardcoded messagetext—both of which indicate a suspicious usage of this feature. There are numerousmethods with parameters which are worthwhile to analyze and we later presentresults from our analyses in Section 3.5. First, we describe the general workflow ofour tool and then provide more detail on the implementation of the slicing process.Afterwards, we illustrate the workflow with an actual example.

3.4.1 General Workflow

Saaf is based on static analysis methods and thus the first step is to dissect Androidapplications. Such applications are packaged in APK files, which are more or lessZIP compressed files with the compiled bytecode, additional metadata such as theManifest file, and additional resources such as image or audio files. Saaf unpacksthese APK files in the following way in order to perform the data-flow analysis andfurther analysis operations:

1. The analyst loads an Android application (APK file) or specifies at least onefrom the command line.

2. Saaf unpacks the contents of the app and generates smali files for all classes ofthe Dalvik bytecode, using the android-apktool. Working directly on the byte-code enables us to obtain a detailed view of the code and overcomes limitationsof tools that rely on decompiling the bytecode to Java code [74].

3. Saaf then parses the smali files and creates an appropriate object representa-tion of its contents. More precisely, we process the Manifest file, basic blocksof the methods, fields, and all opcodes.

At this point, the static analysis can begin since all relevant information is unpackedand available in a usable form for further processing. Saaf will then perform theprogram slicing [235], which is explained in the next section. As noted above, ourbacktracking is a kind of data-flow analysis that specifically focuses on the analysisof method parameters to determine if certain parameters have static values that arerelevant for the analysis process.

3.4.2 Program Slicing

In order to perform our backtracking of method parameters and to perform theslicing, a slicing criterion must be defined. In our case, the criterion consists of thefollowing information:

• method name and full classname of its corresponding class,

51

Sourceint i;int sum = 0;int product = 1;for (i = 0; i < 10; ++i) {

sum = sum + i;product = product * i;

}write(sum);write(product);

Sliceint i;int sum = 0;

for (i = 0; i < 10; ++i) {sum = sum + i;

}write(sum);

Figure 3.3: Exemplary program slice. The slicing criterion is defined as write(sum).

• method signature, and the

• index of the parameter that shall be backtracked.

The slicing criterion fully specifies the relevant opcodes that invoke the desiredmethod in the analyzed application. Such a criterion enables us to search for use-def chains (or use-definition chains) and they are defined in a config file to easily addnew criteria. Such chains describe the use of a variable and all reachable definitionsof it without any intervening definitions. Figure 3.3 shows an exemplary programslice.

We first search through all invoke opcodes for matching ones. Afterwards, we trans-late the given parameter index to a particularly used register in the decompiledcode (use information). We check the previous opcodes in the corresponding basicblocks and determine whether the opcodes perform some operation with the cur-rently tracked register. In other words, we perform a backward slice. Generallyspeaking, we identify all opcodes that modify or use the tracked register and willbacktrack all the interactions until we find a constant (def information). We willexplain in detail what is considered to be a constant in Section 3.4.4, the intuitivenotion is that for example a hardcoded string would be a constant.

Saaf has an internal queue where all registers are stored which have not yet beenbacktracked. The queue is initially filled with registers found during the first searchfor matching invoke opcodes and Saaf backtracks each register until the queue isempty. It is eventually filled as the logic finds opcodes inferring with the trackedregister that make use of additional registers. The queue stores the register’s nameand its exact opcode location in the program in order to backtrack it at some timelater.

52


If a tracked register vx is overwritten by register vy by the means of a move opcode,register vy will of course be backtracked from this instruction on instead of vx. Thesame is true for all opcodes that put a result into the tracked register: All involvedregisters are added to the queue and are later backtracked. If the tracked registeritself is not part of the value registers, it will not be backtracked anymore.

3.4.3 Opcode Handling

Until a found constant terminates the backward slicing, several opcodes requirespecial handling in order to find constants of interest. We now describe how Saafdeals with some opcode classes and the involved registers and object references. Wefollow the general method of data-flow analysis and adopted it to the bytecode usedwithin Android applications. Note that we do not explain the internal logic for allopcodes, as there are over 100 different ones. We have chosen the ones that explainthe backtracking logic the most. Saaf itself handles all opcode classes and fullysupports smali bytecode.

Method Invocations and Return Values. If the tracked register is part of theparameter set for a method invocation, Saaf differentiates the following three cases:if the invoked method is “known” and its smali code is available (1) or not (2), whichis the case for, e. g., the Android API. Another case is introduced if the methodinvocation returns a value that gets assigned to the tracked register (3).

If (1) and (3) are true, Saaf searches for all return values in the correspondingmethod and backtracks the returned register. The backtracking continues at allreturn-opcodes and we search for constants that might get assigned to the returnedregister. The returned registers are added to the internal queue.

If a method invocation is found, we always look at the method parameters, regardlessof (1) or (2) being true. As a static analysis cannot correctly determine all possiblestates of a running program, Saaf will always additionally backtrack all involvedregisters (parameters) involved in the invocation. Note that this includes a referenceof the object on which the method is invoked (if not static). This way, we donot miss any constants that might be related to the initially backtracked methodparameter. An example where this behavior is relevant would be some kind ofdata structure, where values are added and internally “mixed up”, e. g., a stringbuffer. This way, Saaf finds all parameters of previous method invocations to thisobject, e. g., append(...), and eventually constant values. The only register that isnot backtracked this way is the “this” reference for non-static invokes. This solutioncovers implicit method invocations such as constructors.

53


Note that such an approach may yield inaccurate search results. Since we cannotknow for sure what is relevant in such cases, we opt to track all involved registers. Inorder to later distinguish between good and probably inaccurate results, we tag suchfound search results as fuzzy. This tag is an integer and indicates how inaccuratethe result is from our analysis point of view. A fuzziness value of 0 means that theresult is accurate. Values higher than 0 indicate more inaccuracy and express ouruncertainty about the precision of this result. Each such backtracked register willincrement its fuzzy value by 1. The value is passed on to tracked registers that areadded to the register queue due to the currently tracked register. An added registerwill therefore inherit the fuzziness value of the register it is related to. This approachenables us to control the overestimation of the analysis phase and the fuzzy valueimplies a metric to “measure” this uncertainty.

Furthermore, we record invoked methods that are unknown (i. e., no smali codeis available) and have its return value assigned to our register as a result of oursearch. This way, we know that some method returned a value that is involvedwith the initially tracked register (parameter). This will yield methods that returnrelevant but unaccessible data from API calls and the like, e. g., TelephonyMan-ager.getDeviceId().

Arrays. If Saaf encounters opcodes that copy a value from an array into thetracked register, we handle this array access in a special way. Furthermore, if thearray is a class field or a local array, additionally actions are performed.

Examining a class field, we search for all opcodes in the whole program, which putsome value into this array. We ignore the array index of such operations, as it mightonly be available during runtime. All found registers which have a value copiedto this array are added to the queue. If the array is only local, we only searchfor opcodes inside the method where the array resides in. All found values thatare stored in the array are treated as search results. If the array is the result of areturning method, the method is treated as described above.

In summary, we search in both cases for the creation of the array and if it is initializedwith any values. If so, the initial values are saved as search results.

Fields. Fields are handled in a similar way as arrays. If the tracked register gets avalue assigned from a field, all opcodes that store something in the field are searchedand their registers will be backtracked as well. The initial value of these fields isalso considered as a constant and added to the search results.

54


Arithmetic Opcodes. Some opcodes perform arithmetic operations on registersthat use some constant value. If such an opcode is found which involves the trackedregister or the result is moved into the register, this constant value is added tothe search results. Additional source registers are added to the queue for laterprocessing, even if the opcode does not use any constant value.

Basic Block Boundaries. As all methods are divided into basic blocks, we oftenreach the beginning of these blocks. In order to find all relevant constants, thetracked registers will also be tracked in all previous basic blocks. Note that thiscovers all code paths that are the result of jumps and exception handling.

A special case occurs if we reach the beginning of a method (i. e., the first basicblock). If this is the case, Saaf translates the tracked register to the given methodparameter and starts a new search for all invokes to this method with the corre-sponding parameter index. This results in a new search in the same way as ananalyst defined right at the beginning.

3.4.4 Results (Def-Information)

We terminate the analysis process when one of the following conditions holds:

• A constant value is assigned to the tracked register.

• An object reference is written into the tracked register.

These two cases end the search for constants for a tracked register: The first marksour goal to find assigned constants in the bytecode which finishes our search for definformation. All opcodes of the const-x type provide such information in additionto some others, e. g., mathematical operations or initialized fields and arrays. Theyassign constants to registers, e. g., strings or integers. In both cases the register willbe overwritten and has an unknown semantically meaning before the assignment,which is irrelevant for our analysis. While the first one adds a resulting constantto our search, the second one only terminates our search for the correspondingregister. If the register is overwritten with some reference, we will still see all involvedconstants for this object, which is explained in the example in the next section.

Apart from opcodes that put a constant of a specific type into the tracked register,we are also interested in the following aspects that might be encountered during thesearch, if they are somehow linked to the tracked register v:

• Fields and arrays with their types, names, initial and assigned values if a valueis copied from them to v.

55


• Unknown (API) methods if they are called and return a value which is assignedto v. Known methods are part on the use-def chain and all return values aretracked.

• Variable names and types for found constants.

• Opcodes that overwrite v with something else, e. g., if an exception is movedto it.

If such cases are found, they are added to the result set in a proper format andare tagged accordingly. We name them simply search results or constants for therest of the chapter. These results store additional meta-information such as theline number, the filename, and other relevant information that is helpful during theanalysis process. These search results reveal used values such as telephone numbersin the best case and show at least relevant information such as a called methodwhich returns used data in other cases.

If multiple constants are found for different parameters of one method call, e. g., thetelephone number and the text part of the sendTextMessage(...) method, theseconstants are tagged accordingly in a way that the analyst knows that they are usedas input for one specific invocation. Additionally, a path is stored which describesthe “way” through the program, containing the (internally named) basic blocks,methods and classes which were analyzed in order to reach the constant from theslicing criterion.

3.4.5 Example

To give a small example of use-def chains, we provide a small Java program and thecorresponding decompiled smali code in Listings 3.1 and 3.2. Both are shortenedfor the sake of brevity.

If two slicing criteria for this program are set to search for the parameters destinationnumber and message (1st and 3rd parameter) of the sendTextMessage() method inAndroid’s API, the following constants are identified (the f value corresponds to thefuzzy value explained in Section 3.4.3):

• The number 12345 (f=0 ) for the 1st parameter,

• the method a.t.T.getDeviceId() (f=1 ) and

• the string “imei = ” (f=1 ) for the 3rd parameter.

• Additionally, the invocations of toString() (f=0 ) and getSystemService()(f=1 ) are found next to the string phone (f=2 ).

56


Listing 3.1: Sample Java code.1 p r i v a t e S t r i n g number = " 1 2 3 4 5 " ;23 p u b l i c void work ( ) {4 S t r i n g B u i l d e r sb = new S t r i n g B u i l d e r ( ) ;5 S t r i n g s = " imei = " ;6 sb . append ( s ) ;7 TelephonyManager tm = ( TelephonyManager )8 getSystemServ ice ( Context .TELEPHONY_SERVICE) ;9 S t r i n g imei = tm . getDev ice Id ( ) ;

10 sb . append ( imei ) ;11 sendMsg ( sb . t o S t r i n g ( ) ) ;12 }1314 p r i v a t e void sendMsg ( S t r i n g tex t ) {15 SmsManager sms = SmsManager . ge tDe fau l t ( ) ;16 sms . sendTextMessage ( number , nu l l , text , nu l l , n u l l ) ;17 }

The telephone number is found by the means of program slicing: Saaf translates itto register v1 in line 33 and starts the slicing process which promptly finds that theregister gets a field value assigned at line 29. Possible values for this field are thenfound by searching for corresponding setters, which are found in the constructor inline 4-5. The register for the message content is translated to register v3 in line33. The slicing process then reveals that the register gets the value of register p1assigned in line 30, which relates to the method parameter in line 25. In a nextstep, Saaf searches for all method invocations for the method sendMsg() withthe corresponding signature and package path. The slicing process will thereforecontinue at line 22 and will backtrack register v4 as the corresponding parameter.Register v4 gets some unknown value assigned through the toString() invocationof the StringBuilder object which is assigned to register v2 (see line 20-21). As thevalue itself is unknown, Saaf will now treat the method as a constant and furthersearch for more constants that interfere with this object (v2 ). It determines thatregister v0 is passed as a parameter to the method invocation of append() on thecorresponding StringBuilder object referenced by v2. This way, in lines 17-19 registerv0 will also be tracked and this will lead to the call of a.t.T.getDeviceId() whichreturns and writes something unknown to v0, in this case, the IMEI. v3 is now alsotracked because getDeviceId() was invoked on it and as v2 is still tracked, thestring “imei = ” and “phone” will be found in a similar way.

Note that our approach to track parameters in method calls where no smali codeis accessible, e. g., API methods such as the aforementioned append(), might resultin inaccurately identified constants. Nevertheless, this behavior is relevant for somedata structures and the reason and implications where introduced in Section 3.4.3.

57

Listing 3.2: Sample smali code.1 . f i e l d p r i v a t e number : Lj / l / S t r i n g ;23 . method p u b l i c c o n s t r u c t o r ()V4 const−s t r i n g v0 , "12345"5 iput−o b j e c t v0 , p0 , Lxmpl;−>number : Lj / l / S t r i n g ;6 return−void78 . method p u b l i c work ( )V9 new−i n s t a n c e v2 , Lj / l / S t r i n g B u i l d e r ;

10 invoke−d i r e c t {v2 } , Lj / l / S t r i n g B u i l d e r ;−>()V11 const−s t r i n g v1 , " imei = "12 invoke−v i r t u a l {v2 , v1 } , Lj / l / S t r i n g B u i l d e r ;−>append ( Lj / l / S t r i n g ; ) Lj / l /

S t r i n g B u i l d e r ;13 const−s t r i n g v4 , " phone "14 invoke−v i r t u a l {p0 , v4 } , Lexample;−>getSystemServ ice ( Lj / l / S t r i n g ; ) Lj / l /

Object ;15 move−r e s u l t −o b j e c t v316 check−c a s t v3 , La/ t /TelephonyManager ;17 invoke−v i r t u a l {v3 } , La/ t /TelephonyManager;−>getDevice Id ( ) Lj / l / S t r i n g ;18 move−r e s u l t −o b j e c t v019 invoke−v i r t u a l {v2 , v0 } , Lj / l / S t r i n g B u i l d e r ;−>append ( Lj / l / S t r i n g ; ) Lj / l /

S t r i n g B u i l d e r ;20 invoke−v i r t u a l {v2 } , Lj / l / S t r i n g B u i l d e r ;−> t o S t r i n g ( ) Lj / l / S t r i n g ;21 move−r e s u l t −o b j e c t v422 invoke−d i r e c t {p0 , v4 } , Lxmpl;−>sendMsg ( Lj / l / S t r i n g ; )V23 return−void2425 . method p r i v a t e sendMsg ( Lj / l / S t r i n g ; )V26 const /4 v2 , 0x027 invoke−s t a t i c {} , La/ t /SmsManager;−>getDe fau l t ( ) La/ t /SmsManager28 move−r e s u l t −o b j e c t v029 ige t −o b j e c t v1 , p0 , Lxmpl;−>number : Lj / l / S t r i n g ;30 move−o b j e c t v3 , p131 move−o b j e c t v4 , v232 move−o b j e c t v5 , v233 invoke−v i r t u a l / range {v0 . . v5 } , La/ t /SmsManager;−>sendTextMessage ( Lj / l /

S t r i n g ; Lj / l / S t r i n g ; Lj / l / S t r i n g ; La/a/ PendingIntent ; La/a/ PendingIntent ; )V34 return−void

3.5 Evaluation

We now present several evaluation results obtained with the help of Saaf. In total,we successfully analyzed 136,603 free samples which we crawled from Google Play(formerly known as Google Market) in the mid of 2011. Our malware set consistsof 6,187 samples of old and new malware samples, and should cover samples frommost of the known malware families. As long as the android-apktool is able togenerate smali files from the app, Saaf is able to analyze this app. Theoretically,all dex-files should be convertible to smali files. Practically, the apktool sometimesneeds additional files (resources or framework files) in order to successfully decodea file. These files can be provided, but automating this process may be difficult.

58

3.5 Evaluation

Table 3.1: Top 10 permissions.Malware % Market %INTERNET 93.45 INTERNET 86.20READ_PHONE_STATE 77.51 ACCESS_NETWORK_STATE 52.08SEND_SMS 63.69 WRITE_EXTERNAL_STORAGE 34.01ACCESS_NETWORK_STATE 52.63 READ_PHONE_STATE 32.46WRITE_EXTERNAL_STORAGE 48.07 ACCESS_COARSE_LOCATION 22.98RECEIVE_SMS 40.32 ACCESS_FINE_LOCATION 22.42RECEIVE_BOOT_COMPLETED 36.90 VIBRATE 18.05READ_SMS 22.42 WAKE_LOCK 12.36ACCESS_WIFI_STATE 21.45 ACCESS_WIFI_STATE 11.01VIBRATE 20.36 CALL_PHONE 8.99

We therefore only report on applications which can automatically be disassembled.Very few apps need manual intervention, but doing this during a manual analysisis feasible. Other tools which also rely on smali code or even Java code generatedfrom smali code, face the same problem.

The evaluation was performed on two different servers, one was equipped with anIntel Xeon E5620 2.40GHz CPU and one with an E5630 2.53GHz CPU. Both have24GB of RAM and no SSDs. For the rest of this chapter, applications from thecrawled Google Play platform will be typically referred to as samples from the marketand the malware samples will simply be called malware or malware set.

3.5.1 Analysis Results

We will now present analysis results for several application characteristics and usedfeatures for benign and malicious applications.

Android Permissions. We analyzed the permissions used by both types of appli-cations and present the results in Table 3.1. Analyzing the permissions reveals thepermissions one would expect for malicious applications: Almost all applicationshave the permission to access the Internet and most of the other permissions grantaccess to sensitive information like the various identifiers of the phone and, moreimportantly, to read and send short messages. Since criminals attempt to generaterevenue from premium short message services, it is obvious that the correspond-ing permission is placed third in the total ranking. The only exception is the lastpermission, VIBRATE, which seems to be a remnant from trojanized popular gameswhich can often be found in third party markets. This assumption is backed up by

59


the fact that this permission is also ranked high in the analyzed applications fromthe Google Market.

The permission ranking for the market applications is also similar as one wouldexpect: most applications access the Internet, determine the network state, andidentify the device. The only exception is the 10th permission named CALL_PHONE.Apps with these permissions are hard to categorize. There are obvious ones suchas dialers or SIP applications, but also a lot of applications that have the sameprefixed package path, but fall into many categories as games, “reader applications”for websites, and so on. Many applications look like they were either developedby the same person(s) who reuse old components, or were created by applicationbuilders. One package path can be found in 1,100 applications and another one inover 600 applications. All these applications request the same permissions for thecorresponding package path. It seems that the applications do not really make useof the granted permissions, especially of the CALL_PHONE permission.

Another interesting fact is the average number of requested permissions per appli-cations. Applications from the market request 4.4 permissions on average, whilemalicious applications requests 8.9 permission on average. A possible explanationis that a trojanized application needs the original permission set in addition to thenew ones required for the added malicious code.

We are interested in the amount of applications which have the permission to accessthe Internet and additionally at least one permission that grants access to sensitiveuser data. Such applications could leak data by the means of sending it anywhereover the network connection. Our evaluation takes into account permissions thatgrant access to device serial numbers, SMS/MMS, location data, contacts, logs, ac-count data, and the calendar. From the malware set, 90.6% have a permission setwhich allows such information leakage. This is not surprising, as most malware aimsat either stealing data or sending premium rate messages. The market applicationsare less likely to leak private information, but still 67,4% of these apps have a permis-sion set allowing this. This is partly caused by ad frameworks which are permissionhungry in order to identify their “customers”, but additionally from unexperienceddevelopers which accidentally over-privilege their applications, as Felt et al. foundout [79].

IMEI/IMSI. Many app authors use the IMEI and IMSI number from a device asa unique identifier. While 53% of the malware determines at least one of thesenumbers through the appropriate API call, only 23% applications from the marketset do so. These numbers seem rather small, but compared to the applications whichhave the required permission READ_PHONE_STATE, cf. Table 3.1, these numbers look

60

3.5 Evaluation

reasonable. One possible explanation is that the market set is approximately oneyear old and the strategies of included ad frameworks have changed since, as onewould expect a higher amount of these unique identifiers.

Executed Commands. We also backtracked the strings that are passed to theexec Android API method, which executes a command in a command shell. Wefound that malware mainly uses this function to call the su binary in order to installapplications, remount partitions, or to enumerate running processes. Executing suchcommands with elevated privileges is crucial for the malware to obtain a higher levelof rights. Interestingly, some of these commands can also be found in the market set,albeit with a much lower frequency. Malware makes use of this method in 18.9%of the samples, while only 6.4% of the applications from the market set call thisfunction. Since many people root their smartphones to gain access to additionalfeatures, this percentage looks reasonable.

SMS API Usage. Finding applications that are able to send short messages tohardcoded numbers and possible hardcoded content might give a strong clue toclassify such software as malicious. A total of 54% applications call such API meth-ods in the malware set, while only 3.4% do so in the market set. This huge numberfor malicious applications seems reasonable, as a lot of samples were found in re-cent time which abuse premium number services. While there are also legitimateuse cases, a small amount of the applications in the official market also make useof this feature, e. g., an SMS forwarder application. The following numbers arean excerpt from the numbers Saaf found during the analysis phase, all of themrepresenting premium numbers that were identified in an automated way: 69229,7781, 1121, 10086, 9685, 9818, 4157, 4545, 7790, 79067, 8014, 80888, 7061, 7250,1065-71090-88877, and many more.

System Services. Table 3.2 provides an overview of the overall used identifiers forAndroid System Services for all applications, determined by the parameter used forthe API method Context.getSystemService(...).

Malware uses the TelephonyManager service the most, which is requested by theidentifier “phone”. This service has many methods which reveal a lot informationabout the state of the phone, whether a data connection is established, which net-work the phone is connected to, serial numbers, country codes and so on. Becausemany malware samples send short messages to premium services, the software of-ten determines the country the phone is currently located, so the right premiumnumber can be chosen; otherwise the premium rate service number might not be

61


Table 3.2: Top 10 system services.# Malware Market1 phone window2 connectivity layout_inflater3 notification location4 layout_inflater phone5 activity connectivity6 alarm audio7 location input_method8 input_method notification9 window sensor10 audio vibrator

available if chosen wrongly. The ConnectivityManager—which is requested by theid “connectivity”—serves a similar role as the TelephonyManager regarding networkconnectivity changes and the like.

While malicious applications seem to be very interested about the phone’s state,samples from the market set most often care about window (activity) and layoutstates, which the first two used system services reveal for this sample set. The thirdentry “location” refers to the LocationManager. It is used to request the phone’slocation based on GPS or network coordinates. Most ad frameworks make use ofthis feature to serve targeted ads to the user.

The other requested system services throughout the two sets are more or less nor-mally distributed, if one recalls that malware often mimics non-malicious applica-tions or piggybacks those.

Alarm Usage and Thread.sleep(). During the analysis we also evaluated the usageof API functions that halt the execution of the active thread or which (periodically)wake the application up after a specified amount of time. While such a behavioris not malicious per se, it still might indicate that a given application might sleepfor a certain amount of time first before becoming active, a typical behavior seenfor Windows malware. As expected, such API usage was commonly found in bothapplication sets: 56.9% of the malicious applications and 44.4% of the marketapplications call at least one such API function.

We were interested in the average amount of time applications use the methodThread.sleep() throughout both application sets. We therefore queried Saaf for

62

3.5 Evaluation

all values that are passed to the sleep function. This is an integer value and specifieshow many milliseconds the calling thread should sleep. We calculated the averagevalue of all obtained values which are between 0 and 86,400,000 (24 hours) andwhich have a fuzzy level of 0, i. e., are absolutely accurate backtracking results.The finding is very interesting, because both sets have very similar values. Whilemalware goes to sleep for 21.9 seconds on average, market applications do so for22.9 seconds. We have not analyzed why the results are almost identical and leave itfor a future evaluation. As a last note, we found values that were negative—whichshould produce an exception during runtime—or extraordinary high (many days orweeks up to years).

Loaded Libraries. Looking at the search results for libraries which are called by theanalyzed applications, we found that malware most often loads a library called an-droidterm. This library is part of a terminal and provides functionality to access theAndroid command-line shell. We additionally found suspicious identifiers for loadedlibraries such as ScanVirus, VirusBackRunner, ScanController and scan_enginewhich indicate that the malware might be related to some kind of fake anti-viruscampaign, a popular attack vector in the desktop computer world [215] that recentlybecame relevant for smartphones as well.

The legitimate applications mostly use libraries to manipulate images, e. g., lept(Leptonica lib) or ones which are often used in games, e. g., andenginephysics-box2dextension (2D engine), gdx (libgdx, a game development lib) or unity (3Dengine).

Java Reflection. Saaf evaluates whether an application loads classes or callsmethods with the Java Reflection API. There are many legitimate use cases forthis which we will not describe in this chapter, but reflections can also be used toobfuscate the control flow, since no method invocation can be observed if a methodis executed through this API. We found that 36.5% of the malicious and even 57.5%of the market applications make use of the reflection API.

It is of interest for us to determine for which goal the API is used. On the one hand,the called methods indicate that malware tries to hide some of its functionality, asthe following exemplary classes are loaded throughout this sample set:

• android.os.SystemProperties,

• telephony.SmsManager,

• android.telephony.cdma.CdmaCellLocation,

63


• java.net.InetAddress, and

• android.content.pm.PackageManager.

Effectively, the malware samples use reflections to hide the fact that they want toaccess sensitive APIs. On the other hand, market applications mostly use the APIinside the included ad frameworks.

Intents. In the Android operating system, intents are used to perform special ac-tions and to communicate with (other) application components. For the malwareset, the two most commonly used intents clearly indicate the program’s purpose,namely SMS_SENT and SMS_DELIVERED (without a package prefix). In contrast, themarket applications use normal system intents most often such as for example:

• android.net.conn.CONNECTIVITY_CHANGE,

• android.intent.action.SCREEN_ON, and

• android.intent.action.BATTERY_CHANGED.

SSL Sockets. Although most popular libraries and used API functions enable dataexchange over the HTTP(S) protocol, some developers chose to create plain socketsto communicate with some end point. If security matters, they hopefully encrypt thedata. Android provides the widely used SSL/TLS protocol for such cases. Creatinga secure socket is rather easy, but old Android versions by default chose a ciphersuitethat contains a lot of old ciphers. If not changed before a connection is established,old Android versions up to version 2.2 will provide ciphers such as DES-CBC-MD5 orEXP-RC2-CBC-MD5. This behavior was changed in later versions, but Android 2.2was quite common when the market applications were crawled. In June 2014 themarket share of this version diminished to below 1% [28], but the mechanism canbe used for other use-cases.

For us, it is interesting to see how many applications create SSL sockets and howmany manually set the ciphersuites. We found that 153 malware samples do soand only 31 set ciphersuites. The same pattern is visible for market applications:only 943 out of 7,174 do so. This is a bad behavior for applications which are alsoavailable for old devices, as it might introduce severe security implications, e. g., anattacker could perform a man-in-the-middle attack and trick the application intoaccepting a weak ciphersuite.

64

3.5 Evaluation

Content Provider. Most of the data stored on Android devices can be accessedthrough so called content providers. To access data, a developer has to form aURI which specifies the desired content. An example for the calendar would becontent://calendar/calendars. The provider parses this URI and will serve re-quested data from the according data structures, and it additionally ensures thatrequired permissions are at hand (if required). Applications from the Google Mar-ket set have a very diverse set of used URIs which access a lot of different contentproviders such as the calendar, contacts, and SMS/MMS databases. The most ac-cessed content by malware samples is related to the SMS/MMS providers, by a largemargin. Of course the malware samples also access the aforementioned providers,but most URIs are SMS/MMS related.

Native Code and Classloaders. Java and also Android allow calls to native codewhich is not available in Java bytecode but is located in native libraries, e. g., .soshared objects. We found that 9.43% of the malicious apps perform such calls and4.61% of the market applications do so.

Another feature of Java and Android is the ability to load classes from arbitrary des-tinations, e. g., from the Internet, and to run the included code within these classes.While not being malicious per se, this feature can be abused to hide (malicious)code from being analyzed. We analyzed how many applications use the ClassLoader(sub)classes in any way and found that only 0.87% of the malicious apps to so. Onthe contrary, 22.05% of the apps from the market do so. This high number seemsvery unlikely, so we invested how many apps contain code which uses classloadersand which is not located in ad framework package paths. Excluding these ad classes,3,04% of all apps remain. This is still almost 4-times the amount for malicious apps.We leave it for a further evaluation to determine what these apps actual do, butseeing this feature as a typical one for malicious apps to evade detection or analysesseems vague.

Crypto. Next we want to report about the presence of cryptography in the analyzedapplications. Saaf analyzed those and looked for usages of the doFinal() methodin the class java.crypto.Cipher method. If an application makes use of the built-incryptographic routines, they most likely call this function.

Out of all malware samples, 17.6% use this function and 25.3% of all market applica-tions do so. This indicates that the usage of cryptographic functions is no indicatorfor malicious behavior. Unfortunately, Saaf is at this point unable to detect self-written cryptographic functions, so the real usage of cryptographic functions in themalware is likely higher.

65

Listing 3.3: Patched code to circumvent copy-protection mechanisms.1 [METHOD] n . d : ( Ljava / lang / S t r i n g ; ) Ljava / u t i l /Map;2 new−i n s t a n c e v0 , Ljava / u t i l /HashMap ;3 invoke−d i r e c t {v0 } , Ljava / u t i l /HashMap;. :()V4 const−s t r i n g v1 , "VT"5 const−s t r i n g v2 , "9223372036854775807"6 invoke−i n t e r f a c e {v0 , v1 , v2 } , Ljava / u t i l /Map ; . put : ( Ljava / lang / Object ; Ljava /

lang / Object ; ) Ljava / lang / Object ;7 const−s t r i n g v1 , "GT"8 invoke−i n t e r f a c e {v0 , v1 , v2 } , Ljava / u t i l /Map ; . put : ( Ljava / lang / Object ; Ljava /

lang / Object ; ) Ljava / lang / Object ;9 const−s t r i n g v1 , "GR"

10 invoke−i n t e r f a c e {v0 , v1 , v2 } , Ljava / u t i l /Map ; . put : ( Ljava / lang / Object ; Ljava /lang / Object ; ) Ljava / lang / Object ;

11 return−o b j e c t v012 new−i n s t a n c e v0 , Ljava / u t i l /HashMap ;13 invoke−d i r e c t {v0 } , Ljava / u t i l /HashMap;. :()V14 new−i n s t a n c e v1 , Ljava / net /URI ;15 new−i n s t a n c e v2 , Ljava / lang / S t r i n g B u i l d e r ;16 invoke−d i r e c t {v2 } , Ljava / lang / S t r i n g B u i l d e r ;. :()V17 const−s t r i n g v3 , " ? "18 [ . . . ]

Repackaged Applications. Saaf does some internal sanity checks while perform-ing the backtracking process in order to find logic bugs. One thing we stumbledupon while creating CFGs and parsing the basic blocks was the presence of return-opcodes in the middle of basic blocks, as can be seen in Listing 3.3 (code is shortened,but no branches point to the shown code). The method shown begins in line 2 andreturns in line 11 and therefore never executes everything below that instruction.Finding such code constructs yielded an error as everything below the return-opcodewould be dead code and should not be produced by the compiler. We investigatedthis issue believing our code did something wrong.

As it turned out, the smali code was correctly parsed and the basic blocks and theCFGs were also correctly built according to our rules. Looking at these specificapplications, we found that all these applications were indeed patched. Some copy-protection mechanisms were disabled and security checks were removed by overwrit-ing the code with NOP instructions. One particular app even greeted us with amessage that it was cracked by some release group. Looking at the method nameswhich contain such code structures further bolstered our assumption. For example,some method names are checkAccess, GetIsAppLicensed or simply allowAccessand often return a boolean. Saaf will report such findings through so called quickchecks which can be enabled in the config file. These were briefly introduced inSection 3.3 and provide a quick insight of a program’s capabilities.

66

3.5 Evaluation

Obfuscation. We also added a detector for obfuscated code as this informationmight give another hint to an analyst whether an application in question might bemalicious. This detector flags classes and whole applications as possibly obfuscatedand also highlights these in the GUI.

As the metric for deciding whether a class is obfuscated or not, the median lengthsof the field and method names were used. Unobfuscated packages yielded medi-ans between 6 and 11, while the corresponding median for obfuscated classes withProGuard [134] was 1. This is not surprising considering the fact that ProGuarduses short names consisting of letters in alphabetical order, therefore giving a hugenumber of short identifiers for both methods and field names.

While a lot of analyzed packages ship several external libraries, it does not seem toaffect the final results for a complete application. Nevertheless, the most commonlyused libraries such as advertising services and libraries from projects such as Apachecould be excluded from the results in the future. The same approach could also betested against other possible obfuscation methods such as DexGuard [198], whichintroduces comparably more advanced obfuscation techniques. Our current imple-mentation can reliably detect ProGuard-obfuscated apps, but might fail for othertools.

3.5.2 Malware Analysis

We now give a brief excerpt of the analysis of four malware families. All sampleswere automatically analyzed and the results should give an overview of how Saafcan be put to work. As a reference, the MD5 checksums of all samples can be foundat the end of this section.

DougaLeaker.A. The first sample we report on was initially discovered in April2012. The sample steals contact data and sends it to a remote host. For this sample,Saaf was able to extract two URLs to where stolen data might be transmitted:http://depot.bulks.jp/movie/movie44.mp4 and http://depot.bulks.jp/get44.php.The URLs are arguments to the Android and Apache URI parsers. A manualanalysis revealed that the data is sent to the first found URL.

Rufraud. The next sample belongs to the Rufraud family and presents itself asthe popular game Angry Birds. The sample itself is a fake installer and sendspremium rate short messages after the user is tricked into agreeing being charged.These samples were found at the end of 2011 in the Google Market. Dependingon the country the user resides in, the malware sends premium SMS to different

67


providers. Saaf is able to extract 19 distinct destination numbers (1121, 1171,1645, 17013, 1874, 4157, 4545, 69229, 7540, 7781, 7790, 79067, 8014, 80888, 81185,9014, 90901599, 9090199, and 92525), but is not able to extract the text part ofthe messages. Instead, a string (E273FED8415F7B1D8CFEAC80A96CFF46) is foundwhich is used to decrypt the message text that is supposed to be sent. The resultsadditionally reveal that the sample checks whether the messages were successfullysent or not, as the strings SMS_SENT and SMS_DELIVERED indicate, which are passedto the Android IntentFilter class. Such results give a strong hint that the analyzedapplication has malicious intents.

Gone in 60 Seconds. As a third example we provide an overview of three variantsof the GI60S “malware” that appeared in September 2011 on the official GoogleMarket. This malware copies private information as the SMS database and con-tact details from a phone to a remote location. The user is then presented withan access code which enables him to see all the stolen data and the applicationremoves itself. All this happens in less than 60 seconds, hence the name. For eachsample Saaf found several constants, the most interesting ones being an URI toquery the SMS database (content://sms) and an URL pointing to the drop zone(http://gi60s.com/upload.php) which is used in an HTTP POST request. Theseresults indicate the desired functionality of this particular application. It accessesthe SMS database and connects to a website to where it uploads the stolen data.These results extracted by Saaf support a malware researcher and enable her toobtain an initial overview of a given Android app.

DroidCleaner. The last sample we report on is also known as as Superclean. Thisgenuine looking software promises to speed up the smartphone by freeing up memory.But, the real purpose is to offer bot functionality to the attacker. Is is capable ofgathering and forwarding a bunch of information about the infected device. Themalware author can also forward and delete arbitrary files, send and receive SMS,phish for passwords, and control some device settings. Another interesting featureis its ability to infect a connected PC by downloading and storing files on the SDcard which are possibly automatically run by a Windows system if the smartphone isused as an external storage device. The software makes use of a command dispatcherwhich is accessed over the network. More detailed analysis reports are available onthe Internet [230]. In our analysis we were interested in the supported commandswhich can be be run over the network. It turned out that Saaf can easily extract thepossible commands from this dispatcher. Creating slicing criteria which backtrackparameters of the String.equals() and String.startsWith() methods quickly returned

68

3.6 Discussion

command strings. Among those were the following ones which definitely give aninsight about the malware’s capabilities:

• get_contacts,

• del_sms,

• usb_autorun_attack,

• get_packages,

• get_file and

• creds_dropbox.

MD5 sums. The following MD5 sums specify the analyzed samples previouslymentioned in this section. All checksums were calculated on the APK files.

DougaLeaker.A91d57eb7ee2582e0600f21b08dac9538

Rufraud95a04cfc5ed03c54d4749310ba29dda9

Gone in 60 Seconds8d4018a73a35e079aba1d0fd8a06e522cb236442cf93a47bc15e3f312f097992859cc9082b8475fe6102cd03d1df10e5

DroidCleaner / Supercleanb0c28334373332d4677c01bd48eed431

3.6 Discussion

In this chapter, we introduced Saaf, a static analysis framework for Android apps.Saaf analyzes smali code, a disassembled version of the DEX format used by Dalvik,Android’s Java VM implementation. Since no decompilation to Java is performed,the approach is more robust and resilient to code obfuscation techniques or insuffi-ciencies of decompilers. Saaf successfully analyzed more than than 140,000 appli-cations and mainly performs data-flow analysis based on program slicing to analyzethe structure of apps, but is also capable of performing other kinds of analysis. Wesurveyed a large collection of Android apps and malware, and our evaluation resultsconfirm some insights previously obtained on smaller sample sets [74]. We were able

69


to find destination numbers as well the text parts of outgoing short messages, the us-age of libraries, the Reflection API, content providers and much more. Additionally,our tool supports a manual analysis of Android applications.

Although Saaf successfully analyzed such a large corpus of applications, it of coursealso has some limitations. Being a static analyzer, it has all the drawbacks staticanalyzers have in general [159]. For example, information available only at runtimeis not available, and the usage of encryption methods and obfuscation put a heavyburden on such tools. Despite these general drawbacks that Saaf shares with otherstatic analysis tools, our framework could be improved in the following ways. First,although being able to detect the usage of the Reflection API and additionally oftenalso the called class and method, Saaf currently does not backtrack into methodsfound this way while backtracking a register. Despite the effects of heavy obfuscationand dynamic code loading, the analyst can easily see if and to what extend suchfeatures are used as the automatic analysis will reveal these. Such indicators mightgive a strong clue of the intents of an application. The fact that Saaf is able toanalyze smali files does not mean that it is guaranteed to always find all constants.There are likely corner cases where code constructs are misinterpreted and somethingis missed. For obvious reasons, we have been unable to check all found results againstexpected results.

70

4Dynamic Approach based on Power Consumption

After presenting our work in the field of static program analysis in the last chap-ter, we now present our contribution in the field of dynamic program analysis forAndroid applications. This chapter results from a publication [110] at the Sympo-sium of Research in Attacks, Intrusions, and Defenses (RAID) conference in 2013 incooperation with Stephan Neumann and Thorsten Holz. This work has been sup-ported by the Federal Ministry of Education and Research (BMBF grant 01BY1020– MobWorm).

Abstract. With the ever rising amount and quality of malicious software for mo-bile phones, multiple ways to detect such threats are desirable. Next to classicalapproaches such as dynamic and static analysis, the idea of detecting malicious ac-tivities based on the energy consumption introduced by them was recently proposedby several researchers. The key idea behind this kind of detection is the fact thateach activity performed on a battery powered device drains a certain amount ofenergy from it. This implies that measuring the energy consumption may revealunwanted and possibly malicious software running next to genuine applications onsuch a device: If the normal energy consumption is known for a device, additionalused up energy should be detectable.

In this chapter, we evaluate whether such an approach is indeed feasible for modernsmartphones and argue that results presented in prior work are not applicable tosuch devices. By studying the typical energy consumption of different aspects ofcommon Android phones, we show that it varies quite a lot in practice. Further-more, empirical tests with both artificial and real-world malware indicate that the

71

4 Dynamic Approach based on Power Consumption

additional power consumed by such apps is too small to be detectable with the meanerror rates of state-of-the art measurement tools.

4.1 Introduction

In the last years, smartphone sales began to rise significantly and also the numberof malicious software for these devices grew as we have shown in Chapter 2. Asa result, several techniques to analyze smartphone applications emerged with thegoal to detect and warn users of unwanted software. Most solutions are based onclassic techniques known from the PC area, such as dynamic and static analyses(e. g., [76, 70, 104, 251]). Based on the fact that mobile phones are powered bya battery and the insight that every performed action drains a specific amount ofenergy from that battery, the idea came up to measure the consumed energy andto deduce from that data whether any unwanted (malicious) activities occurred,possibly hidden from the user [126, 144]. The developed tools use the system API oradditional external devices to obtain information about the battery status, runningapplications, actions performed by the user (if any), and calculate the normal amountof energy a clean device should consume under such circumstances. This model isthen used in the detection phase to compare live measurement data against it inorder to detect additional activities. Such a method could—at least in theory—detect software that was loaded onto the device or applications that suddenly behavein a different way.

The proposed prototypes [126, 144] were implemented and tested on feature phoneswith a limited amount of additional installable (third party) applications comparedto the “application markets” of today’s smartphones. Furthermore, the devicesthemselves were equipped with considerably less features and sensors, such as anaccelerometer, GPS, WiFi, large touchscreens, or a full-blown browser. Comparedto a modern smartphone, feature phones offer less possibilities to a user.

Throughout this chapter, we attempt to verify or disprove the possibility to detectmalware on modern smartphones based on their energy consumption. We use aspecialized tool named PowerTutor [245] to measure the energy consumption ofseveral potentially malicious activities in both short and long time test scenarios.We evaluate the energy consumption for each action and the energy consumption forthe complete device based on the reports provided by PowerTutor. Our short timetests aim to get an idea of the measurement possibilities for a short time duration(5 minutes) and the long time tests (1 hour) evaluate what is possible in scenariosthat can be found on smartphones used every day. We measure the impact of classicmalicious activities such as stealing personal data or abusing the short message

72

4.2 Related Work

service (SMS) next to artificial ones like draining the battery as fast as possiblein order to commit some kind of denial-of-service attack. We implement our ownproof-of-concept malware that accomplishes our malicious tasks and we validate ourfindings with two real-world malware samples.

Our main contribution is the evaluation of a method to detect malicious softwarethat was conducted in the first place on “old” feature phones rather than on modernsmartphones. We argue that the proposed methods do not hold in practice anymoreand study in detail how a modern Android phone consumes power. We show thatthe energy needed to perform relevant malicious activities, such as stealing privatedata, is too small to be detectable with the mean error rates of state-of-the artmeasurement tools.

The remaining of this chapter is structured as follows. We first discuss relatedwork in Section 4.2 in order to introduce the used tools and the aforementionedproposed methods. We then describe in Section 4.3 our setup, the used smartphones,and our proof-of-concept malware. Sections 4.4 and 4.5 cover our performed tests,followed by a validation of our results in Section 4.6 and an evaluation in Section 4.7.Afterwards, we describe the limitations of our approach followed by a conclusion inSection 4.8.

4.2 Related Work

Since we want to (dis)prove that malware detection is possible on a modern smart-phone by measuring its power consumption, we first discuss related work in thisfield.

Kim et al. introduced the idea of detecting malicious software based on its powerconsumption [126]. They built a prototype for phones running Windows Mobile5.0 that works with power signatures. These signatures are based on the powerconsumption of a program rather than its code or exhibited behavior. In order tobe useful to the enduser, a signature database has to be available. This circum-stance does not allow the detection of new and unknown malware, as no signatureis available.

Another tool for Symbian based phones was proposed by Liu et al. [144]. Their tool,called VirusMeter, works without any signatures but on heuristics. In a first step,the user’s behavior and the corresponding power consumption on a clean systemis profiled. Then, in a second step, the actual used energy is compared againstthe learned profile and if a certain threshold is reached, the systems alerts the userthat additional (maybe malicious) activities have been performed on the phone.

73


Throughout this chapter, we perform similar tests not on features phones but onmodern Android smartphones and evaluate to what extend malicious activities canbe detected (if any).

Work by Dixon et al. shows that the location has a huge impact on the user’s activ-ities [65]. Leveraging this information, the average power consumption for differentlocations can be computed that could then be used to detect anomalies in the powersignature for these locations if, e. g., malware performs additional operations nextto the expected power consumption introduced by a user. A study performed byBalasubramanian et al. [32] analyzed the tail energy overhead introduced by trans-fers over the wireless connections offered by smartphones. Although they measuredthe used energy for different connection types, they focused on the amount of en-ergy that can be saved if a special protocol is used by applications that make use ofwireless connections.

Dong et al. propose Sesame, a tool that is able to generate a power model forsmartphones and notebooks and the underlying hardware, battery, usage etc. byitself without external tools [67]. They argue that factory-built models are unlikelyto provide accurate values for different scenarios, such as different hardware or usagepatterns.

Since all such tools need to measure the used energy in one or another way, workrelated to this task is also relevant for us. The first tool, called PowerTutor [245], wasdesigned to provide a precise report of energy spent on a smartphone. This reportincludes the power consumption of sole devices such as the NIC or the display. Inorder to provide a very detailed power model for an analyzed application, a powermodel for the used mobile device has to be calculated in the first place. This modelwas generated with the help of specialized hardware that precisely measured thepower consumption of the device under certain circumstances. Since these modelsare bound to the device, accurate results with a claimed long-term error rate of lessthan 2.5% for an application’s lifespan can only be provided if PowerTutor runson such a “calibrated” device. PowerTutor runs on Android, requires no changesto the operating system and the Android framework, and its source code is freelyavailable.

Next to PowerTutor, a tool called eprof was introduced to measure the power con-sumption of a given app on Windows Mobile and Android smartphones [183]. It isalso able to provide a breakdown of the power consumption of sole methods insideapplications. This is possible because eprof works on the system call level: All I/Ooperations that consume energy from internal devices are realized through systemcalls performed by the application, e. g., sending a packet over the mobile Internetconnection through the GPS modem. This enables a precise measurement of theenergy spent for an application in question. This measurement method is different

74

4.3 Measurement Setup

compared to the utilization-based one performed by PowerTutor. The authors ofeprof claim an error rate of under 6% for all tested applications in contrast to an er-ror rate of 3–50% for utilization-based methods. Furthermore, eprof can be used tomeasure which application components use what amount of energy [182]. The toolis not available and the authors describe changes to the OS kernel, the OS/Androidframework, and the analyzed application itself.

Yoon et al. recently proposed another tool named AppScope [243] to measure theenergy consumption on Android smartphones. Their monitoring software is able toestimate the energy consumption on a per app basis in a similar way as PowerTutorby making use of a kernel module that hooks and reports certain events on thesyscall level and by using a linear power model. The error rate ranges from 0.9–7.5%depending on the tested software as long as no GPU intense tasks are performed.For games like Angry Birds it raises up to 14.7%.

All three tools can interfere the current power consumption of an app at whole oraccess to some component in detail from some previously generated power model.The subsystems itself, e. g., the WiFi device or its driver, do not provide such infor-mation.

4.3 Measurement Setup

To measure accurate power consumption traces for several use cases on a modernsmartphone, we first have to chose a stable setup under which all studies are per-formed. Furthermore, we need some way to actually generate accurate power mea-surements and we need a tool that performs defined actions that consume power.

Our tool of choice to measure the power consumption is PowerTutor [245], whichwas already introduced in the last section. Having access to PowerTutor ’s sources,we modified it slightly such that it generates verbose log files which we used forour calculations throughout this chapter. Since we want to verify if a software-based detection mechanism is capable of detecting additionally installed malware ona smartphone, we cannot make use of any hardware-assisted measurement mecha-nisms. Such additional devices (note that the phone itself is not capable of doingthis with the exception of reporting an approximate battery charge level and volt-age) would severely reduce the user acceptance to perform such measurements atall. Since end users are the target of such a software as they shall be protected frommalicious software, it should be a purely software based solution as one would expectfrom traditional AV software products. We chose PowerTutor over eprof becausewe have access to the tool, the mean error rate is comparable, and we are able togenerate good measurement results despite using a utilization-based measurement

75


method since we have control over the test system (i. e., we can control how muchparallel interactions occur, see Section 4.4 for more details).

In the following we describe our software which we used for our test cases and explainthe choice of our used smartphones.

4.3.1 Application

We now describe how we perform the power consumption measurements of differ-ent smartphone features. Since the main contribution of this work is to (dis)provethe possibility to detect malicious software due to its power consumption, we wrotea software that is able to run artificial tests of relevant functions that actual An-droid malware exhibits. While our test malware performs these actions, the powerconsumption is measured by PowerTutor.

Our proof-of-concept malware is able to perform the following functions in order toevaluate what features or combinations of features are detectable. It can send andreceive SMS; make use of the location API; access content providers, e. g., contactsand SMS database; send arbitrary (encrypted) data over the network; access serialnumbers, e. g., the IMEI; record audio; set Android wake locks to control the powerstates of the CPU and the screen; and run in an endless loop to put a heavy burdenon the CPU.

These features are typically used by malicious applications once they are installed,with the exception of the last one. Nevertheless, a malware that aims to disruptoperational time of the smartphone is easily imaginable. The measurement resultsfor these functions or a combination thereof are later evaluated in order to seewhether such activities are detectable by the amount of consumed power, similar tothe malware tests conducted by VirusMeter [144].

Our software is written in Java and is installed like any other Android application.To be able to perform the described actions, all required Android permissions arerequested in the application’s Manifest file. It basically consists of a control programthat initiates an action over the network and a service which performs it. Actionscan be run once, repeated in an interval, delayed and so on. This scheduling isperformed with the help of the Android AlarmManager. All actions are performedby the service and are therefore performed without any GUI elements. This is crucialfor the measurement step, as PowerTutor accounts the power consumption of GUIelements to the appropriate app. They influence the displays power consumption forOLED displays and, additionally, foreground processes have a higher priority thanbackground processes within Android. The power consumption of this test malwarewill be referred as “MW” in all tables.

76

4.4 Short Time Tests

4.3.2 Test Devices

We performed most tests with a HTC Nexus One smartphone. The reason for thisis that this phone was explicitly tested and used by the PowerTutor developers,saving us from calculating our own power model for the smartphone. They usedthree different phones, but the Nexus One is the newest one and is upgradeable toa recent Android version with respect to early 2013 (Android 2.3.6 / Gingerbread).Having a rooted phone also enables PowerTutor to calculate a more precise powerconsumption for the built-in OLED display which depends on the visible pixel colors.By using this phone we believe we get the most accurate measurements out ofPowerTutor. All tests are performed by this phone unless stated otherwise.

We additionally performed some tests with a Samsung Galaxy Nexus phone in orderto validate our results. This was the latest Android developer phone available by thetime we performed our research and runs Android version 4.0 (Ice Cream Sandwich).The phone is also equipped with an OLED display, albeit with a newer version beingcalled “HD Super AMOLED”, next to some additional sensors and it is used forvalidation purposes (although PowerTutor measurements might be less accurate dueto a missing calibration). The phone’s remaining battery capacity and its runtimecan still be used to compare the results with those of the Nexus One.

Both phones have been equipped with new and formerly unused batteries in orderto ensure maximum battery lifetimes. Note that our setup suffers from the sameproblems all such systems have, e. g., the reported battery capacity and voltage maychange a lot due to different parameters [180].


In order to determine whether malicious software is detectable on a phone with thehelp of power signatures, we first need to know the power requirements of severalsoft- and hardware components. To obtain an overview, we first conducted shorttime tests to measure which features consume what amount of battery capacityfor later comparisons. First, all tests were run with the same basic settings. Thehardware GPS module is activated, but not used. The display brightness is set to afixed value of 130/255 and it switches off after 30 seconds of inactivity. The standardlive wallpaper is active on the home screen but no synchronization, background data,mail fetching, or widgets are active. Internet connectivity is either provided by WiFior by 3G, depending on the test. Additionally, the OS is freshly installed and onlya few additional applications are installed: PowerTutor to be able to perform ourmeasurements; MyPhoneExplorer to easily access logged data from a PC; K-9 Mail

77


for email fetching; and our own proof-of-concept malware for our evaluations. Alltests are repeated six times in a row for 5 minutes from which the arithmetic medianof the consumed energy is calculated. During this time, no additional interactionwith the phone occurs. Note that such measurements do not represent a valid usagepattern in any case, but they enable us to determine the power consumption of basicphone features.

For all following tests, the same usage pattern is used. When the phone is fullycharged and set to an initial state, PowerTutor is started and directly put in thebackground such that the home screen with the live wallpaper and the launcher isvisible. No further input will occur in the next 5 minutes which causes the screen tobe turned off after 30 seconds. As long as nothing is noted, a test does not deviatefrom this pattern.

In the following, we calculate the amount of used energy in mW and its coefficientof variation (CV) for several power consumers or the whole system, respectively.First, the CV is calculated for an idling phone (see next paragraph) and this definesthe average percentage of deviating consumed energy during a given time interval.In other words, the CV for an idling phone describes the average amount of noisethat is introduced by all components. If any action consumes less energy than thenoise rate (i. e., amount of energy described by the CV for an idling phone), it isnot measurable with a single measurement. We could of course measure the powerdemands of such consumers if we would perform many measurements of the sameconsumer and would calculate the noise out of the results. A detection engine thatworks with power signatures does not have this kind of luxury, as it has to pinpointmalicious behavior as soon as possible. If many measurements must occur in thefirst place, a malicious software could already have easily performed its payloadundetected. If the additionally consumed power of some activity is given in latertests in a table (referred as “Rise” in the corresponding column), it will be shown inbold letters if its value is above the CV of an idling phone, meaning the measuredaction has a higher energy consumption than the average noise ratio of an idlingphone. Such a component could be detected by a power signature.

Tables with measurement results will also often contain a column labeled “TotalCons.” that depicts the total consumed energy during the test as reported by Pow-erTutor. Unexpected Framework and OS activities triggered during a test mightintroduce additional noise, which can be seen in this column. The impact is ofcourse higher for the conducted short time test. If this value is higher than thetotal consumption of the initial tests (see next paragraph) plus the noise ratio (CVvalue), it will also be written in bold letters. This value does not related to the“Rise” column but describes unexpected introduced noise in addition to any usedenergy throughout the test. Note that if the value is written in bold letters, it does

78


not imply that it can be detected in a reliable way. Its value must be significanthigher than the CV value, which describes the average noise. False positives arepossible here, one must carefully check the size of the value. Higher differences tothe initial total consumption mean potentially less false positives.

Since PowerTutor is unable to measure the power consumption of the GSM modem,we cannot provide any measurement about its usage. Still, we performed a test thatincludes the sending of short messages in Section 4.5.5. In order to overcome thedrawbacks of the utilization-based measurement method of PowerTutor, we strictlycontrol all additionally running applications (next to the running OS applications)and their access to any device. Doing this mitigates the problem of accounting theused energy to programs running in parallel.

4.4.1 Initial Tests

We start our evaluation with tests in which we measure the power consumption ofseveral components such as the display as well as the influence of running software.These initial tests define a basis for later tests which are compared with the initialones. Knowing the minimum amount of energy a smartphone requires in certaincircumstances is crucial for the detection of additional malicious activities.

Data Connectivity. This test evaluates the differences between a WiFi and a 3Gconnection on an otherwise idling phone. Table 4.1 shows how much power theirusage consumes if the connection is only established, but no data is actually trans-ferred.

Table 4.1: Short time initial tests for a 5minute period. Average power con-sumption for wireless connections.

Connection Consumption CVWiFi (always on) 51.17mW 0.87%WiFi (if screen is on) 51.26mW 1.14%3G 68.47mW 9.49%

The WiFi connection can automat-ically be turned off if the smart-phone’s screen blanks in order tosafe energy. Using this featuresaves no energy in this short timespan compared to being alwayson. On average, the smartphoneconsumes 51mW with an enabledWiFi connection with a low CV.Remarkable among these numbers is that the smartphone consumes 34% less energyusing WiFi instead of 3G. Additionally, the CV is much higher for the 3G connec-tion, with measured absolute numbers from 47.77 to 75.85mW . This is likely causedby different bitrates and link qualities (GPRS, EDGE, UMTS, HSDPA) dependingon the coverage area and the signal strength at the time the test was conducted.

79


Table 4.2: Exemplary power consumption of different apps after system start for a 5minute interval. Values in mW (missing energy was consumed in unlistedcomponents).Application OLED CPU WiFi TotalDesktopclock 0.00 0.03 0.00 0.03MyPhoneExplorer 0.00 0.00 0.00 0.05Gallery3D 0.00 0.07 0.00 0.07Android Services 0.00 0.12 0.11 0.23Maps 0.00 0.00 0.34 0.92PowerTutor 0.00 1.87 0.00 1.87Wallpaper 0.00 4.31 0.00 4.31Launcher 39.79 0.01 0.00 39.80

It may even change for the same location at different times. For the rest of thissection, we compare the results of the other tests against the values from this testwhere WiFi is always on and from the 3G case.

Background Processes. To get an idea of the energy consumption of the applica-tions running on a smartphone, we used PowerTutor to measure the energy usageof the automatically started preinstalled applications after each restart. The resultscan be found in Table 4.2. What can be seen in this table is the fact that theforeground application—which is the Launcher—consumes the largest amount ofpower. As it manages the live wallpaper, PowerTutor will add the power consump-tion used by the OLED display to show the wallpaper to the Launcher instead of tothe Wallpaper application. However, the same is not true for its CPU consumption.PowerTutor itself consumes about 3.0% compared to the overall consumption, butthis value is calculated out in all further tests. All other values are left alone, as theypresent characteristics of the base system, such as Android Services (by this term wemean several Android OS processes). Again, no synchronization or other activitiesoccurred during the short time tests, they will be evaluated in Section 4.5.

Brightness. The brightness of the display scales between 0 and 255, while highernumbers represent a brighter display. The lowest user selectable value is 20. Thevalue can be set manually or by the system itself, which can determine the brightnessof the phone’s surroundings with a light sensor.

We measured the power consumption for different values and the results can be foundin Table 4.3. During this test, the display was never turned off which will prevent

80


the phone from entering the sleep state. Additionally, the WiFi connection wasenabled. With these settings, the battery lasts for about 10 hours with a differenceof 2 hours between the darkest and the brightest setting.

Table 4.3: Average power consumption fordifferent brightness levels.

Setting Consumption VCDark (20) 445.89mW 2.50%Auto (standard) 462.20mW 1.73%Medium (130) 494.61mW 1.13%Bright (255) 550.70mW 1.01%

What can be seen is that the brighterthe display is, the smaller the CV gets.This is caused by the relative highamount of power which is consumed bythe display, even for dark settings. Allother energy consumers such as back-ground processes quickly loose their sig-nificance in contrast to this huge en-ergy consumer, compared to the num-bers from Table 4.2. These results show that the display’s energy demand plays abig role for the smartphone’s runtime.

4.4.2 Energy Greedy Functions

This section deals with software which aims to draw as much power as possible byvarious means. Such activities can be seen as a kind of DOS attack against thesmartphone, as it is unable to operate with a depleted battery.

Sleep Mode. We first determine how much energy gets consumed by the CPU ifit is not allowed to reach its energy saving sleep modes. It is easy to do this inAndroid, as one only has to set a partial wake lock. This will cause the screen tobe turned off after the normal timeout but the CPU keeps running. This feature isnormally used for tasks which run periodically in the background and that shall notbe interrupted when the phone would otherwise enter its sleep mode.

Such a setting will consume 81.50mW in total and causes a raise of 59.27% in termsof used battery power. Although PowerTutor does not detect that our softwaresets the wake lock, the Android system does and marks it correspondingly in the“battery settings”. Note that this can be easily detected by the user. However,setting a wake lock is not a feature that has to be used to hide malicious activitiesin the background—at least not to such an extend. Such a setting, whether used bymistake or on purpose, can easily be detected by any program monitoring the powerconsumption.

81


CPU Burn. The last test revealed a high rise in energy consumption if the CPUkeeps running all the time. This test will determine how big the impact is when theCPU will not only run all the time, but also has to crunch some numbers. Table 4.4shows the results of the following two tests. In the first one, the CPU is allowed tosleep when the screen turns off. This way, the CPU will only have a maximum loadwhen the phone is active. In the second test the CPU is disallowed to enter its sleepstate when the screen turns off. During both tests, the program calls Math.sqrt()in a loop.

Table 4.4: Average power consumption for different power states.Function MW Cons. Total Cons. RiseSleepmode allowed 54.02mW 110.29mW 105.57%Sleepmode disallowed 518.84mW 602.92mW 1,013.95%

Both tests put a heavy burden on the phone’s runtime. While the first test “only”consumes about double the energy than it would normally do, the second test clearlyshows that a malicious program can totally disrupt the battery lifetime. With araise of over 1,000% in energy consumption, the battery would only last for about8 hours even though the screen turns off. But again, the Android system detectsthat our application wastes so much energy and the user can take countermeasures.Additionally, the phone gets quite hot under such load. Some AV program couldalso easily detect such (mis)use and alert the user.

4.4.3 Location API

Next, we evaluate how much energy is consumed while the location API is used.We cover the case where the last known position is reused and when an accurateGPS position is requested. Since location data represents a very sensitive piece ofinformation, we measure the energy required to steal it from the phone.

Last Known Position. In this first test, our software will only use the last knownposition (LKP) which is returned by the Android API. Because no new positionis determined, the energy consumption is expected to be low. To mimic actualmalware, the returned coordinates are wrapped in an XML structure and sent overthe network through the WiFi or 3G connection. Table 4.5 shows the results; theposition is retrieved only once during the test. As expected, the power consumptionis really low if the data is only retrieved and not forwarded at all (WiFi is enabled,though). If it is sent over the WiFi connection, the consumed energy raises a bit, but

82


is still very low with a rise of 0.25% over the normal consumption. This is basicallyonly the amount of energy needed to use the WiFi interface, which is evaluated inmore detail in Section 4.4.4.

Table 4.5: Average power consumption for accessing the location API. LKP = Lastknown position.Connection Function MW Cons. Total Cons. Rise

WiFi

LKP 0.017mW 52.25 mW 0.03%LKP (sent) 0.126mW 51.39mW 0.25%GPS 7.91mW 61.18 mW 15.46%GPS (sent) 7.97mW 63.28 mW 15.58%

3G LKP (sent) 8.111mW 87.25 mW 11.85%GPS (sent) 12.01mW 107.79 mW 17.54%

If position data (LKP) is sent over the 3G connection, 2.36% more energy is con-sumed in contrast to the CV for an idling phone with an established 3G connection,cf. Section 4.4.1. In Section 4.5, we evaluate whether the added consumption in the3G case is still measurable in real life scenarios and would therefore be detectable.

Determine GPS Location. This test makes use of the current GPS position whichhas to be determined by the hardware GPS module. It is said that it consumes alot of power; we will see if this accusation is correct or not. The position is againretrieved only once by our software and sent over the network encapsulated in XMLformat. The results are also presented in Table 4.5.

What can be seen is that our software consumes more than 7mW additional powerwhen the GPS module gets active. We have to note that PowerTutor measuresthe GPS module’s power consumption separately, but we added it to our malwareconsumption as it is the sole program using it. It does not matter whether the datais sent over the network or not in order to introduce a huge gain in consumed energy.If sent over the 3G connection, a rise of 17.54% is measured, which is clearly abovethe noise ratio even for the 3G connection.

4.4.4 Data Heist

This section examines whether the acquisition and forwarding of (private) informa-tion raises the energy consumption to an extent that it is detectable. This is acommon feature of current mobile malware [250].

83


Table 4.6: Average power consumption for data transmission.Connection Function MW Cons. Total Cons. Rise

WiFi349 Bytes (1 SMS) 0.112mW 51.55mW 0.22%37.6 kB (200 SMS) 1.182mW 53.39 mW 2.31%

365 kB (2,000 SMS) 1.949mW 54.73 mW 3.81%

3G349 Bytes (1 SMS) 8.114mW 99.15 mW 11.85%37.6 kB (200 SMS) 8.161mW 103.41 mW 11.92%

365 kB (2,000 SMS) 13.724mW 86.95 mW 20.39%

Data Size. We first measure the impact of the file size of the data which is sent overthe Internet connection. To get an idea of how much data is transferred, our malwaresends data equivalent to the size of 1, 200 and 2,000 short messages encapsulatedin a XML structure over TCP/IP. Table 4.6 lists the power consumption for bothInternet connection types. As one can clearly see, more sent data consumes moreenergy. The higher consumption whilst using WiFi is more visible than for 3G, asthis connection type implies less noise. Sending small quantities of data quicklyputs the energy consumption over our threshold for this short duration with bothconnection types. In Section 4.5, we evaluate if this is still true for real worldscenarios.

We also tested whether the data source has some impact on the energy consumption.The results show that it does not matter if our data originates from some contentprovider, the SD card and so on. Only the amount of data matters.

Encryption. Some sophisticated malware might encrypt the sent data to hide itsintention. As encryption of course uses CPU cycles, we are interested if this over-head is measurable. We performed the same measurements as above, but the datawas additionally encrypted with AES in Counter Mode with PKCS5Padding anda random key. We have measured that our malware consumes 1.19mW of energyto encrypt 37.6 kB of data which is sent over the WiFi connection. Compared toour last test with data of the same size, almost the same amount of energy is con-sumed: A rise of 2.33% instead of 2.31% is measured, which lets us conclude thatthe encryption only consumes 0.02% more energy. Rather than using the 3G in-terface, we only performed the test with the WiFi interface as the results are moreclean due to lower noise. Additional encryption is therefore not measurable as it isindistinguishable from noise, at least with a cipher such as AES.

84

4.5 Long Time Tests

4.5 Long Time Tests

This section covers long time tests which evaluate if and to what extend the afore-mentioned features are measurable by means of their power consumption under twomore realistic scenarios. The first scenario (A) covers a real world scenario where thesmartphone is heavily used, while the other (B) covers a scenario with light usage.The details of the two scenarios can be found in Tables 4.7 and 4.8. Both scenariosare run for 1 hour and repeated three times, resulting in a total duration of threehours for each test run.

Table 4.7: Joblist for scenario A.Minute Job Duration5 1x write SMS 1 minute (160 characters)10 1x send SMS 1 minute (160 characters)20 Use Browser 5 minutes (4 site accesses)25 Music 10 minutes (display off)35 Facebook App 2 minutes50 Angry Birds 5 minutes55 1x E-Mail 1 minute (120 characters)

Table 4.8: Joblist for scenario B.Minute Job Duration5 1x write SMS 1 minute (160 characters)20 Use Browser 2 minutes (1 site access)30 Music 3 minutes (display off)40 1x E-Mail 1 minute (120 characters)

In order to simulate an average Jon Doe’s smartphone, several Widgets were visibleon the home screen (Facebook, Twitter, a clock, and a weather forecast) in scenarioA. These were absent in scenario B, but both additionally made use of backgroundmail fetching (POP3 with K-9 Mail, every 15 minutes) and synchronized the datawith Google. GPS was enabled all the time and everything else was left at its defaultsetting.

85


4.5.1 Initial Tests

In order to detect malicious activities, we again first need to know how much energyis consumed in both scenarios without them. Table 4.9 shows the four CV valueswhich again represent our threshold values. Any action which consumes less energythan these values is indistinguishable from noise in the corresponding scenario.

Table 4.9: Long time initial tests (3 hour period).Scenario Function Charge Total Cons. CV

A (heavy) WiFi 63% 299.67mW 2.08%3G 48% 419.09mW 2.67%

B (light) WiFi 77% 97.28mW 2.79%3G 78% 145.14mW 3.16%

The battery charge value is eye-catching. Although in scenario B the total energyconsumption differs by approximate 50%, the charge level is even higher for a moredepleted battery. This is a strong indicator that the user cannot trust the batterycharge value by any means and that it should only be considered as a very vaguevalue.

As this test includes normal user behavior such as Web browsing, the power con-sumptions depends a lot on the actual user input. For example, when and howlong the Web browser is used is defined and always the same in all tests, but theactual power consumptions is influenced a lot by the actual accessed Web sites. TheOLED display might consume more or less energy on one website as it would dis-playing another one. The same is true for the browser process. How many and whatscripts are executed, is the browser’s geolocation API accessed? During the test thesame websites were visited, but the content changed over time which at least mightinfluenced the OLED display to a certain extent.

As one could already see in the short tests, the 3G Internet connection uses morepower than the WiFi connection. The CV for the tests with 3G connections is muchlower as in the short tests because there are a lot more actions performed than justkeeping this connection up, which reduces the noise introduced by this consumer.The same is true in the opposing way for the WiFi connection, as the CV goes upfor these scenarios.

Table 4.10 provides an overview of the power consumption of several apps as we didin the last section. As one would expect, the game Angry Birds and the Web browserconsume a lot of energy. The values for the OLED display, the CPU, and the WiFi

86

4.5 Long Time Tests

module also look sane and correlate to the provided applications functionality exceptfor the Facebook app. The CPU consumption seems a bit high. The reason for thisis unclear, but the app felt unresponsive on the old phone which might be causedby not well written code. The missing values for the apps total energy consumptionare used by the GPS module, the speaker and other devices.

Table 4.10: Exemplary power consumption of different apps (scenario A). Values inmW (missing energy was consumed by unlisted components).Application OLED CPU WiFi TotalPowerTutor 0.25 3.45 0.00 3.70K9-Mail 13.87 0.60 0.48 14.95MMS Application 21.44 1.04 0.00 22.48Music 0.00 0.34 0.00 26.28Launcher 28.05 1.46 0.00 29.51Facebook 26.98 12.47 8.40 47.85Angry Birds 53.89 9.71 1.51 68.10Browser 39.79 14.28 1.01 78.01

4.5.2 Energy Greedy Functions

In this test, we again stress the CPU to its maximum in both scenarios. Since wewant to know how big the impact of such energy-greedy software is in contrast toall other apps, we disabled the sleep mode, meaning that the CPU and all appskeep running even when the display blanks. Table 4.11 shows the results. As onewould expect, our malware consumes a lot of energy in both scenarios but mostin scenario B, as it gets more CPU cycles in total because there is less concurrentinteraction opposed to scenario A. This is also caused by the fact that Androidprioritizes foreground apps. The energy consumption compared to Table 4.4 is a bitlower, as other software runs next to our malware. The values are not higher as onemight wrongly expect because W is defined as one joule per second.

Table 4.11: Average power consumption with disabled sleepmode (WiFi only).Scenario MW Cons. Total Cons. RiseA (heavy) 419.26mW 764.53 mW 139.91%B (light) 505.55mW 645.82 mW 519.69%

Under these circumstances, the smartphone’s battery will last for approximately 8

87


hours in scenario A and 6.7 hours in scenario B. If the user does not know howto check which apps consume what amount of energy, this will vastly degrade theuser’s smartphone experience. Additionally, if the CPU is not the fastest, the usermight feel some unresponsivenesses in some apps. Nevertheless, this behavior canbe detected by AV software in both scenarios.

4.5.3 Location API

In this section we test how much energy a “tracker app“ consumes under whatcircumstances. If an app retrieves the last known location from the API, almostno energy is consumed. We therefore limit our tests to the case where our malwareretrieves the GPS location. We chose four different intervals for each scenario andthe location is always encapsulated in an XML structure and sent out through theWiFi interface.

Table 4.12 shows the consumed energy for each test case. The results show thatretrieving the location during the long time tests is less obtrusive compared to theshort time tests. In scenario A, the added power consumption is indistinguishablefrom noise and in scenario B carefully set parameters are also indistinguishable (in-terval ≥ 15). Our location listener was updated at the set interval, but an additionalparameter which sets the minimum distance from the last location which must bereached in order to get notified was set to 0. This means that our malware woke upat all interval times, even if the location did not change. One could be much moreenergy friendly if a minimum distance is set and/or if a passive location listeneris used which only gets notified if some other app is performing a regular locationrequest.

Table 4.12: Average power consumption for stealing GPS position (WiFi only).Scenario Function MW Cons. Total Cons. Rise

A (heavy)

5 minutes 5.32mW 315.61 mW 1.78%15 minutes 2.88mW 328.49 mW 0.96%30 minutes 2.56mW 304.88mW 0.85%60 minutes 0.87mW 292.97mW 0.29%

B (light)

5 minutes 6.11mW 105.42 mW 6.28%15 minutes 2.24mW 100.84 mW 2.30%30 minutes 1.73mW 104.12 mW 1.78%60 minutes 0.94mW 101.08 mW 0.97%

88

4.5 Long Time Tests

4.5.4 Data Heist

Table 4.13: Average power consumption for data transmission.Scenario Function MW Cons. Total Cons. Rise

A (heavy)WiFi 5 min. (13MB) 2.01mW 295.71mW 0.67%

1 min. (65MB) 11.42mW 322.82 mW 3.81%

3G 5 min. (13MB) 8.02mW 450.65 mW 1.91%1 min. (65MB) 51.72mW 538.74 mW 12.34%

B (light)WiFi 5 min. (13MB) 2.14mW 100.84 mW 2.20%

1 min. (65MB) 6.11mW 105.42 mW 6.28%

3G 5 min. (13MB) 7.50mW 148.82mW 5.17%1 min. (65MB) 39.78mW 197.78 mW 27.41%

The short time tests revealed that even small quantities of data sent through eitherthe WiFi or the 3G interface are detectable. This section examines if this is alsotrue for real world scenarios. In both scenarios, 369 kB are read and sent througheach interface. Two different intervals were tested during which the data was sent.Table 4.13 shows the results for each test. It is clearly visible, that data heist froma spyware is not that easily detectable in a real world scenario. A well writtenmalicious software that steals data could send approximately 35MB of data in smallchunks in 3 hours without being detectable by its energy consumption. This amountdecreases vastly for the 3G interface.

Data theft can—to some extent—be detectable by means of additionally used energy.This means that it gets detectable if, e. g., many pictures or large documents arecopied. In contrast to that, theft of SMS databases or serial numbers such as theIMEI are unrecognizable.

4.5.5 Uncalibrated Phones

Next to our test with PowerTutor on a HTC Nexus One, we also performed sometests with a Samsung Galaxy Nexus. Since PowerTutor is not fine tuned to thisphone, we only use the provided battery charge level and the reported battery voltageby the tool (similar to the approaches presented in the literature [126, 144]). Thisway we can determine what is possible without a sophisticated tool.

We performed three tests on the Galaxy Nexus. The first two are identical to thelast two from the previous test: Data is sent over the WiFi interface in two different

89


intervals for our two scenarios. In the third test, our malware sends a short messageevery 5 minutes resulting in 36 messages over 3 hours. Unfortunately, PowerTutoris unable to measure the power consumption of the GSM modem. Therefore, thistest was not performed on the Nexus One and cannot be compared to any previousmeasurements.

In order to obtain any information about the phone’s power consumption, we beganour evaluation with a measurement of the phone’s energy demands for the twoscenarios without any additional actions. We again call them initial tests and theyare performed in the same way as mentioned before (3 hours in total). The resultscan be found in Table 4.14 and clearly tell one story: Without any sophisticatedmeasurement of the actual consumed power, no predictions of any additional runningmalware can be made (at least for our chosen scenarios and tests). Each test endedup with a battery charge rate which was higher than that for the initial test. Thisshould of course not be the case, as additional actions were performed. The reportedvoltage also does not correlate to our expectation that more energy is used and itshould therefore be lower (the battery voltage decreases if depleted). Therefore, auser cannot trust the values displayed on the phone and so cannot any monitoringsoftware.

Table 4.14: Battery charge level for the Galaxy Nexus after sending data and shortmessages (WiFi only).

Scenario Function Charge Voltage

A (heavy)

Initial test 74% 3,812mV5 minutes/13MB 79% 3,887mV1 minute/65MB 76% 3,900mV36x SMS (every 5 minutes) 76% 3,845mV

B (light)

Initial test 90% 4,060mV5 minutes/13MB 91% 4,072mV1 minute/65MB 91% 4,023mV36x SMS (every 5 minutes) 90% 4,022mV

4.6 Validation with Real-World Malware

This section covers the energy demands of two malicious software samples namedGone in 60 seconds (GI60S) and Superclean/DroidCleaner (SC) that were foundin the Google Play Store in September 2011 and January 2013. We have tested

90

4.6 Validation

whether they are detectable in our test scenarios from the last section and validateour measurements for the Nexus One.

We now briefly explain what both samples do. GI60S is a not a malware per se,but mostly classified as such. Once it is installed, it sends the following data tosome server: contacts, short messages, call history, and browser history. Whenfinished, it will display a code that can be entered on the GI60S homepage whichwill enable the user to see all stolen data (messages are behind a paywall). In alast step, the software removes itself from the smartphone. In our case, 251 kB ofdata got transferred. The name is based on the fact that all this is done in lessthan 60 seconds. SC promises to speed up the smartphone by freeing up memory.Additionally, it aims to infect a connected PC by downloading and storing files onthe SD card which are possibly run by a Windows system if the smartphone is usedas an external storage device. It also offers some bot functionality and is able togather and forward a bunch of information about the infected device to the author.The author can also forward and delete arbitrary files, send and receive SMS, phishfor passwords, and control some device settings. More detailed analysis reports areavailable on the Internet [230]. We wrote a small server for SC and tricked it intoconnecting to this one and not the original one (which was already down). This waywe were able to control the bot and send commands to it in order to measure theconsumed power. We used the functionality to download several files (images, PDFand music), SMS, and contacts next to retrieving all information about the phone.22.46MB of data were transferred over WiFi to our server. Table 4.15 shows theresults of our measurements.

Table 4.15: Verification with malware in controlled scenarios (WiFi only).Scenario MW MW Cons. Total Cons. Rise

A (heavy) GI60S 1.45mW 311.51 mW 0.48%SC 4.06mW 296.87mW 1.35%

B (light) GI60S 1.54mW 103.35 mW 1.58%SC 5.60 mW 113.65 mW 5.45%

It can be seen that the energy consumption is similar to our test malware withthe corresponding feature set. Therefore, our malware has a reasonable power con-sumption and the results should be comparable to other software performing similartasks. This also means that both samples are in 3 out of 4 cases not detectable byits power consumption as our measurements reveal—they go down in the noise. Thetotal power consumption is even lower than the initial one for the SC case and isonly slightly above the CV for the initial consumption for both GI60S cases. Only

91


the SC test in scenario B is detectable which is not astonishing, as we copied a lotof data from the phone which raises the energy consumption a lot in the light usagescenario. Malware could act much less inconspicuous, but that was not our goal inthis test.

Furthermore, we tested GI60S in an “all day long test” (i.e., the phone was “usednormally” during an 8 hour period). During this time, GI60S was run once such thatall data was stolen. This test was performed twice and the results can be found inTable 4.16. These show that the overall power consumption during an 8 hour periodcan greatly differ. The CV for the total consumption during a day (total runtimewas divided into 8 slices lasting one hour each) is huge, with over 70%. This means,the power consumed during one hour of usage might be completely different fromthe last hour, depending on the actual usage pattern. Having such a high CV, it isalmost impossible to detect anything based on a single power measurement. Evenif very accurate and timely measurements with small intervals are available and thesmartphone reports accurate battery levels, this would still be a tough job since theuser has such a big influence and his actions are almost unpredictable resulting in avery high noise ratio. The solution proposed by Dixon [65] might lower the CV, butit seems unlikely that it will reach a usable value. We have not tested SC in thistest since the results should be very similar.

Table 4.16: Power Consumption during the “all day long tests”. The CV is calculatedfrom 8 time slices during that period lasting for 1 hour each.

Run Application Consumption CV Rise Charge

1st day Total 64.57mW 70.40% 40%GI60S 1.24mW 1.92%

2nd day Total 87.14mW 82.86% 56%GI60S 0.54mW 0.62%

4.7 Evaluation

In this section, we evaluate our measurements and findings. We can boldly saythat measuring power consumption on a smartphone in general is not an easy task.There are many parameters that influence the whole system and thus the energydemand and ultimately the smartphone’s runtime. Let alone the fact that precisebattery charge levels are very hard to measure and depend on a lot of differentfactors [4, 190], it is even harder doing with software only. This fact is somehow

92

4.7 Evaluation

mitigated as PowerTutor is a very specialized tool for this task and is adjusted forthe used smartphone. We therefore deem its measurements as accurate enough forour purposes although it is not perfect.

We will now compare our results with the proposed solutions of VirusMeter [144].The creation of power signatures would not be satisfactorily for us on a modernsmartphone operating system: Such a signature would contain the energy demandsof the application in question under certain circumstances. If an app would sud-denly act in a malicious way (e. g., stealing private information) a monitor shoulddetect these actions based on its power signature. In theory, this should work asall additional (malicious) actions will use additional energy which is measurable. Inpractice however, accurate measurements are hard to perform as discussed through-out this chapter. This will yield to a certain error rate which we called “noise” inthe previous sections. This noise describes the varying amount of energy which isconsumed more or less for the same action(s) in the same amount of time. Even fora five minute interval, a noise ratio of 1% was measured. Despite the fact that wewere able to control many settings on the smartphone during this time span, ourmeasurements were not 100% accurate. Since we used a modern smartphone witha variety of features, this problems gets worse for larger intervals as more featureskick in (e. g., email fetching or synchronization). This leads to a noise ratio of upto 2.79% for long time tests. The fact that such a monitor should run on everydaysmartphones, forces it to cope with such noise ratios.

Our measurements for the various test cases in Sections 4.4 and 4.5 show that sucha power signature would not be accurate enough, as a lot of possible maliciousactivities can easily go by undetected compared to the measured amount of energythese actions cause. If such a signature would only work with the total consumedpower of the smartphone, it will alert the user for a lot of these actions. But, if thetotal consumption is higher than the initial power consumption plus the CV value,this only means that the action required more energy than the average noise level.Many tests lead to values which are just a bit above this threshold which couldlead to many false positives. Generating a good threshold is inherently hard, as theusers’ habits may change and even for the same user and for two consecutive daysthe CV is above 70% (see Table 4.16), which is completely unusable. Lowering themeasurement interval could decrease the CV, but only to some extent as it heavilydepends on actual user input in some cases, see Section 4.8 for an example. Adetailed analysis of the smartphone usage of 250 users was conducted by Falaki etal. [78] and they also found out that even a single user can show very varying usagepatterns. If the total consumption is not considered, an attacker could, e. g., stealan amount as high as 35MB over 3 hours without being conspicuously. This is alsotrue for a lot of other actions.

93


If one not only analyzes the energy consumption introduced by an application intotal or even on a device basis (e. g., WiFi), consumption patterns might occur. Butthese patterns still suffer from the introduced noise, as the power consumption isonly infered from a model that was previously generated (the phone does not providepower stats of sole devices). Having some kind of pattern which states that some appconsumed x1 mW during y1 seconds in device z1 and then x2 mW during y2 secondsin device z2 and so on, one could use that as a signature. However, searching forthat information in, e. g., the syscall trace would also be enough because it was usedto interfere these values in the first place.

Although such power signatures cannot detect the described activities, they still candetect some malicious ones. Amateurish written malware could be detected if toomany features are used too aggressively, e. g., determining the current position byGPS in a very short interval. What is easily detectable is energy-greedy malwarewhich has the goal to disrupt the battery lifetime. But this clearly is not the normalbehavior malware exhibits—most of them steal (private) data or send premium rateSMS.

This leads us back to VirusMeter : This approach makes use of predicted user behav-ior and their resulting energy demands. If the used energy (measured by the differentbattery charge levels) does not match the assumption, then something is wrong andan alert is generated. While the tools to measure events and power consumptionclearly improved compared to the possibilities the authors of VirusMeter faced, wecannot verify their findings for a modern Android based smartphone. The noiseratio and the impact of interfering events is too big to get good and usable results(see, e. g., Table 4.16). Even if all events and measurements are logged and some so-phisticated heuristic performs the evaluation externally or on the smartphone itselfif the battery is charging, malware can still hide below the noise level.

We believe the noise level is the biggest show stopper for such a detection approach.All other proposed tools such as eprof [182] and AppScope [243] have error rates, andtherefore noise ratios, which are too high. Using some sophisticated power modelwill not negate the small amount of additional energy (often below 2%, which isunder the mean error rate for most tools and settings) that is needed to performmost malicious activities. We therefore opted to not generate our own model as itis unable to cope with such settings.

Even if malicious activities are detected by such means, most activities would al-ready have finished and the damage would have been committed. Otherwise, noadditional power would have been consumed in order to perform any detection.This assumption lets us further expect that such a system is not feasible in anysatisfying manner as most of the relevant cases can only be detected when it is toolate. Additionally, we believe that the false-positive and false-negative rate would be

94

4.8 Discussion

too high in practice, even if the system does not aim to prevent but only to detectmalicious activities.

4.8 Discussion

In order to reach the goal of this work—namely to evaluate whether the detection ofmalware running on a mobile phone is possible by measuring the power consumptionof certain activities and devices—we need precise power measurements. We believethat PowerTutor is a good starting point on an adjusted device such as the NexusOne. Although the measurements are not perfect, we deem them accurate enoughfor our purposes. At least they are more accurate than the parameters used forVirusMeter [144]. Additionally, the mean error rate is comparable to other toolssuch as Appscope and eprof. One thing PowerTutor is unable to cope with is thepower consumption of actions which make use of the GSM modem, such as theshort message service. We were therefore unable to measure precise results forsuch activities. Another thing that is not reported in a good manner is the powerconsumption of the GPS device. PowerTutor can only report the consumption ofthe whole device, not the consumption of a specific “consumer”. We therefore haveto calculate an approximate value for its usage if more than one software is usingit. eprof would be better suited for such a test case, as it is able to calculate theconsumption for each app separately.

The authors of VirusMeter build a profile for the user in order to detect anomalieswhich we did not do. We refrained from doing so, as our measured numbers areeither too close at our thresholds (CV) or too far away. Without reasonable resultsfor the long time tests generating such a model is futile in our opinion regardinga low false-positive count. The user’s activities are just too random for modernsmartphones [78].

Additionally, our tests were mainly performed with one smartphone, the Nexus One.A second phone, the Galaxy Nexus, was only used in two test cases to get a feeling ofhow a monitoring software performs which does not have access to accurate resultssuch as provided from PowerTutor. More tested devices would of course be favorable,but the Nexus One is the only device which is supported by PowerTutor and wasstill modern enough with respect to early 2013 to actually perform meaningful testswith it. In fact, AppScope also only supports this phone. Furthermore, the resultsare not encouraging at all.

We tried to be as precise as possible during our tests. But since these tests were allperformed by hand, there are certainly slight variations for each result. Automatictesting was not possible, so all the performed tests took a lot of time and patience.

95


Our results indicate that software-based approaches to measure the power consump-tion of an Android smartphone and to interfere from these results whether additionalmalicious activities occurred, is not satisfactory in most cases. The approach mainlyfails due to the noise introduced into the system by unpredictable user and envi-ronment interactions, such as the reception rate or the delivered content of accessedwebsites. While a more precise power model could mitigate effects such as varyingreception rates, it cannot calculate out the effects of many user interactions, e. g.,browser usage. This is at least true for our long time test results, which do not haveoptimal but comparatively real world settings. The short time tests indicate thatsome activities can be detected by such a system, but under settings seldom foundon a smartphone that is regularly used.

We even go one step further and think that such a system is not feasible at all ona modern smartphone—at least with available measurement methods and normaluse cases. Let alone the fact that the hardware components have to provide veryaccurate values of consumed energy, the system still needs a very precise model ofwhat the user usually does and how much energy these actions typically consume.We assume that such an anomaly detection would generate a lot of false positives, asnormal users change their behavior quite often, depending on the actually installedapps and so on. Even if a precise profile would exist and the user would not changehis habits too often, apps can be very dynamic in a way that a power profile forthese apps cannot be precise at all. Just imagine what the browser is capable of(e. g., complete Office suites are offered as a web application) and try to generate apower signature for its behavior.

We conclude that well written malicious software running on a modern smartphonecan hardly be detected by means of additionally consumed energy as the noise ratiois too high. Only DoS attacks against the battery runtime and so called “energybugs” [123] as well as certain activities performed under strictly given scenarios canbe reliably detected, which is not enough to be of great use for normal smartphoneusage patterns.

As a last point we note that modern smartphones with modern operating systemssuch as Android are more or less a general purpose computer with a very smallform factor. If such proposed systems would be usable as a malware detector, theyshould also work on regular notebooks or PCs. To the best of our knowledge, no suchsystem was ever used for this purpose. We therefore deem energy based approachesfor malware detection as a dead end—at least for modern smartphones withoutextended capabilities to account for used energy.

96

5Change of Ends: Obfuscating Android Applications

In this chapter we report on the status quo of analysis tools for Android applications.This chapter contains novel and unpublished work. A publication of this work iscurrently in submission and was jointly done with Davide Maiorca, Teemu Rytilahti,Marcel Winandy, Thorsten Holz and Giorgio Giacinto. We would also like to thankOussama Renuli and Nicolai Wilkop for their help while evaluating the differentanalysis framworks.

Abstract. The recent past has shown that smartphones became a target for mal-ware authors—particularly Android based ones. The first detected malware sampleswere rather simple, mostly abusing premium-rate services, cf. Section 2.1.4. How-ever, recent malware families offer a variety of features and allow, among otherfeatures, spying as well as theft of arbitrary data and can often cause monetarydamage by various means. This circumstance led to the introduction of many dif-ferent analysis methods for mobile malware and in return caused malware authorsto write more sophisticated malware attempting to thwart such analyses.

In this chapter, we first categorize mobile application analysis systems and describeon which assumptions they rely on. We then present a new obfuscation tool thatmodifies Android applications so that these assumptions do not hold anymore. Weevaluate the robustness of many analysis systems for (malicious) Android applica-tions against such transformations. As some tools rely on Java source code, wealso introduce code modifications that particularly oppose decompilation attempts.Finally, we present detection rates of antivirus systems, including those for mobileplatforms, against well-known but obfuscated malware samples.

97

5 Change of Ends: Obfuscating Android Applications

We report on the status quo of mobile analysis tools for Android apps against well-obfuscated malicious software. We want to emphasize that many systems have blindspots and outline research problems that should be addressed by future tools.

5.1 Introduction

Malicious software for mobile devices became prevalent in the last few years. Whilethe first such samples were rather simple and unsophisticated, the complexity oftoday’s malicious apps is steadily increasing. Especially malware for Android-basedsmartphones has significantly advanced in the recent past [250]. This is a repetitionof the evolution of malware we observed for desktop computers: While the very firstcomputer viruses and worms were rather basic, their level of difficulty constantly roseover the years and modern malware like Stuxnet or Flame impressively demonstratethe sophistication of today’s threats. Hence, we also expect that malware for mobiledevices will become more mature in the near future, especially since adversaries havean intrinsic motivation to hamper analysis processes for their malicious apps, e. g.,to bypass antivirus solutions or appear innocent during an automated analysis.

To counter this development, analysis tools must keep up with the constant evolutionof malware. The typical arms race in computer security between attackers anddefenders is especially distinctive in this area. Researchers from both academiaand industry developed a large number of analysis methods for Android apps inrecent years (e. g., [62, 241, 251, 79, 55, 195]). These tools explored many differentapproaches and they took into account lessons learned from analyzing malware fordesktop computers. However, existing analysis methods cannot simply be ported toAndroid due to many intricacies of the platform (e. g., multiple entry points and anew binary format). Thus, many novel analysis approaches were examined and thisled to a huge body of work on this topic.

In this work, we systematically evaluate the robustness of state-of-the-art analysistools for Android apps. Such an empirical evaluation is needed to assess how reliableexisting analysis tools are. Especially due to the constant rise in malicious appswe need such an evaluation: Antivirus vendors report to have detected more than100,000 new malware samples monthly for Android (cf. Figure 2.2 on page 17).Manual analysis of all apps is clearly not feasible. However, if we rely on automatedanalyses, we need to know their limitations and drawbacks. Moreover, we wantto anticipate the next generation of mobile malware that leverages sophisticatedobfuscation methods to impede automated analyses.

In a first step, we survey 28 existing analysis methods and categorize these ap-proaches according to their main analysis goal. This provides us with a compre-

98

5.1 Introduction

hensive overview of the state-of-the-art and we identified five different categories oftools. These tools have several basic assumptions on which their analysis is based.For example, to perform an analysis a tool could rely on (i) the ability to decompilethe app such that the analysis process can be carried out on the decompiled code, or(ii) having access to the call graph (CG) of the app, or (iii) being able to find APIfunction names in the code. We found that the number of underlying assumptionsfor all existing methods is rather small. To produce an obfuscated app, a viablestrategy is thus to systematically thwart these assumptions. For example, we canobfuscate the code such that decompilation becomes impossible, degenerate the CGsuch that it does not contain meaningful information, or hide all API strings. Theresulting app has the same semantics as the unobfuscated one, but it withstands theanalysis tools since their basic assumptions are not fulfilled anymore.

We implemented the identified obfuscation methods as a basis for our study ofthe robustness of existing analysis methods. We opted to perform this obfuscationdirectly on DEX bytecode since this implies that we do not need access to theapp’s source code and can thus be applied on arbitrary, existing apps. Comparedto existing methods to obfuscate Android apps (e. g., [198, 194, 247, 188, 117]),our method is the most comprehensive one since we cover a wide range of potentialobfuscation techniques. On the one hand, we leverage methods to bypass dynamicand static analysis methods (e. g., detection of the analysis environment, entry pointpollution, bypassing taint analysis, breaking use-def chains, hiding types). On theother hand, we also came up with methods that confuse decompilers to be able to alsobypass them (e. g., changing the catch handler order, adding bogus code, or clashingtypes). Consequently, our goal is not only to bypass existing antivirus solutions asmany of them simply rely on static signatures, but to bypass all existing static anddynamic analysis frameworks that aim to provide a comprehensive analysis. To thebest of our knowledge, this study is the first to assess the robustness of a wide rangeof analysis approaches for Android apps.

In summary, we make the following four contributions:

• We survey existing analysis methods and provide a comprehensive overview ofstate-of-the-art tools.

• We analyze the basic assumptions underlying existing analysis methods (e. g.,ability to reconstruct a CG) and systematically explore how these assumptionscan be thwarted (e. g., decoupling the CG). Our goal is to produce an obfus-cated app with the same semantics as the original one, but which withstandsexisting analysis tools.

• We implemented the identified obfuscation methods. Our implementation di-rectly modifies the Dalvik bytecode, so we can obfuscate arbitrary Android

99


apps without requiring access to source code.

• We evaluated our obfuscations empirically and found that they severely ham-per state-of-the-art tools and can successfully evade static and dynamic anal-ysis tools as well as decompilation attempts.

5.2 Related Work

In this section we first survey Android application analysis frameworks. Then we dis-cuss related work on obfuscation for Android apps and explain why we implementedour own obfuscation tool.

5.2.1 Android Application Analyzers

Prior surveys have given an overview on security research on Android [75] and evalu-ated the effectiveness of malware detection with dynamic analyses [166]. In contrast,we consider both static and dynamic analysis frameworks, and we include generalanalysis tools, not only malware detection. As such, existing approaches of Androidapplication analysis can be categorized into five classes according to their main pur-pose. Table 5.1 shows an overview of the tools and compares their main features.We review the approaches in the following.

Basic and General Analysis Tools

The first class consists of general analysis tools that try to determine specific proper-ties of individual apps. Often these tools are used as building blocks for other tools.For example, basic static tools are Dedexer [178] and baksmali [18] to disassembleDEX files, ded [171] to convert Dalvik bytecode to Java bytecode, and Soot [228] todecompile and transform Java bytecode.

AndroGuard [62] is a static analysis framework which includes a decompiler andpremade tools for various tasks such as component and permission analysis, deter-mining native code usage, and it can create CFGs and shows differences betweenapps. TaintDroid [76] implements dynamic taint tracking to discover informationleakage in apps. First, one or more sources of sensitive data are specified and thecorresponding data is marked as tainted. Then the app is executed and monitoredin a modified Dalvik VM, which tracks the tainted data flow through the bytecode.When any tainted data reaches a specified sink, e. g., Internet connection, an alarmis raised.

100

5.2 Related Work

DroidScope [241] is a dynamic binary instrumentation tool that uses a virtualization-based analysis. In contrast to TaintDroid, DroidScope targets both architecturallevels of Android: the native Linux and the Dalvik contexts. Besides a modifiedDVM it also uses a modified QEMU, which is also instrumented to log specificoperations. To some extent, DroidScope can keep track of tainted data when nativecode is executed, as its taint analysis is based on machine and bytecode level.

More recent research is concentrating on static code and taint analysis since dynamicanalyses may not execute all code paths. FlowDroid [89] is such a static taint analysissystem that provides a precise model of the application lifecycle, and it is context,flow, field and object-sensitive. FlowDroid builds a so-called exploded supergraphbased on flow functions that define the data flow on program statements. Thedecision whether a variable is tainted at a certain point in the code is reduced to agraph reachability problem. The analysis depends on successful decompilation.

Mobile-Sandbox [210] combines static and dynamic analysis to identify maliciousfunctionality in apps. A static analysis checks for malware, determines requiredpermissions, and identifies possible entrypoints. It also searches in the disassem-bled code for certain functions that are often used by malware (e. g., to send SMSmessages). Then the app is executed in an Android emulator that performs a taintanalysis, logs any native library calls, and stores the network traffic.

Detecting Malware in Application Markets

App markets are the primary software distribution channel on mobile platforms.However, malware may also be among the offered apps as static virus signaturescanning mechanisms are inadequate to capture zero-days or hidden malicious func-tionality. A few approaches focus on alternative detection schemes.

DroidMOSS [248] aims to detect similarities between original apps in Google’s mar-ketplace and repackaged apps in third-party marketplaces. Although it does notlook for malware directly, such repackaged apps may include additional function-ality or modification to the original code which could be potentially malicious. Tothis end, DroidMOSS generates a fingerprint for each app using fuzzy hashing onthe disassembled bytecode and calculates a similarity score to other apps.

DroidRanger [251] uses a combination of footprint-based detection (including typicalsets of permissions as requested by known malware) and a heuristics-based dynamicdetection of malicious behavior. A static analysis first checks for broadcast receivers,the internal tree structure of the app package, and for bytecode sequences thatimplement critical API calls (e. g., loading dynamic Java or native code). A dynamicanalysis logs API calls and tries to identify malicious behavior.

101


RiskRanker [104] automatically classifies apps into three risk levels. It includes twoanalysis engines. The first one requires non-obfuscated apps and scans for nativecode that contains known exploits and looks for code paths that contain suspiciousAPI calls. The second engine uses symbolic execution over decompiled code toidentify critical execution paths that contain certain API functions such as executingencrypted native code or dynamic code loading.

All three approaches look for suspicious code, whether it is based on hashes onopcodes or containing certain API calls, requiring to perform string matching onnon-obfuscated code.

Analyzing Requested and Used Permissions

Permissions are a key security concept on Android, but they exhibited some limitsduring the years. On the one hand, a benign app can have too many permissions andmay be exploitable by a confused deputy attack. On the other hand, a malicious appmay misuse a combination of permissions to steal or harm data. Therefore, a numberof approaches have been developed to analyze the permissions of apps. Simpleapproaches only look at the set of requested permissions to make their conclusions,while more sophisticated approaches analyze the code of the apps to determinewhether and how permissions are used.

PermissionWatcher [216] is an Android app that shows the permissions of otherapps that are installed on the same smartphone, and reports predefined risk levelsbased on the set of requested permissions. Permission Based Risk Signals [199] startearlier and indicate whether it is a risk to install an app based on the requestedpermissions, the category in the marketplace, and the set of permissions other appstypically have in the same category. This approach is a more generalized form ofthe same principle used by DroidRanger. Probabilistic Generative Models [185] evenimprove this approach from a binary decision to reporting risk scores for each appusing statistical models on the number and type of permissions and other meta-information. Finally, WHYPER [179] uses Natural Language Processing (NLP)to infer from an app’s description why it requests certain permissions. The toolidentifies in the text resources and actions that are related to permissions.

Stowaway [79] statically analyzes the API calls and associates those to permissions.Based on this analysis, it can detect whether an app is overprivileged. Moreover, itcan track the usage of Java Reflection and detect specific API calls that are relatedto permissions. COPES [36] also detects over-privileged apps via static analysis, butit has a more precise mapping of permissions to API calls since it uses an automaticanalysis of the Android source code with Soot.

102

5.2 Related Work

Pegasus [52] is a static analyzer that shows the context of a permission usage inan app, based on which one may determine a malicious intent. The analysis isbased on the construction of so-called Permission Event Graphs, which representthe temporal order between requested permissions and API calls. VetDroid [246],in contrast, is a dynamic analyzer that examines how permissions are used in thecode of an app. The app is executed in an Android emulator that monitors codeexecution and identifies those code positions that request a resource protected by apermission. Then it analyzes in which execution paths this resource is re-used andwhether this results in information leakage or other malicious activity.

While those approaches relying on meta-data will not be affected by code obfusca-tion, static analyzers will most likely have difficulties in finding critical API calls inobfuscated apps, and permission pollution may affect their effectiveness.

Analyzing ICC Vulnerabilities

Inter-Component Communication (ICC) is another crucial aspect of app security onAndroid. Apps could be abused via ICC by malicious apps to gain access to sensitivedata or to attack their control flow. Messages going to be sent from one app toanother could be delivered to an unintended receiver (e. g., via implicit Intents).

SCanDroid [90] is an early static analyzer that checks for data flow security in andbetween Android apps. This tool concentrates on flows from and to data stores, inparticular content providers, databases, files, and URIs.

ComDroid [55] was the first static analysis tool to examine potential security vi-olations resulting from implicit Intents or publicly made components in Androidapps. It analyzes disassembled bytecode and identifies the creation of Intent ob-jects, whether they are explicit or implicit, and follows the control flow to deter-mine Intents that are used in unprotected ICC calls. Further static analyzers forICC vulnerabilities have been developed: CHEX [147] focuses on detecting compo-nent hijacking vulnerabilities by analyzing disassembled bytecode. Woodpecker [103]aims at detecting ICC vulnerabilities in the bytecode of the pre-installed apps onan Android system. DroidChecker [51] focuses on finding ICC vulnerabilities thatcould be exploited by a confused deputy attack. DroidChecker performs an inter-procedural flow and taint analysis on the decompiled source code to find exploitabledata paths.

Epicc [172] is a static analyzer that creates a mapping of ICC to components of apps.It identifies and matches corresponding entry and exit points of ICC according topossible Intent values. The novelty in this approach is that the ICC analysis problemis reduced to an instance of the Interprocedural Distributive Environment (IDE)problem, which can be solved efficiently. In particular, the tool is able to analyze

103


the possible Intent values in conditional branches, so it can effectively map call sitesto ICC entry points, even across applications. IccTA [141] and DIDFAIL [131] bothcombine and improve the analysis tools Epicc and FlowDroid to find privacy leaksacross multiple apps that are linked via ICC.

It is reasonable to assume that ICC vulnerabilities will cause a multitude of secu-rity violations, as interactions among apps increase. Interestingly, all existing ICCanalyzers are based on static analysis, and most of them require the ability of per-forming string matching on source code or disassembled bytecode to find criticalAPI functions. We can expect that most or all of these tools will fail if apps areobfuscated.

Analyzing Application Behavior

The last group of tools aims at systematic monitoring and profiling of the behaviorof apps. Based on these profiles, users can make more informed decisions whetherthey want to install the app or not.

ProfileDroid [234] generates behavior profiles based on a combination of static anddynamic analyses. It performs a static analysis of the bytecode to search for usedIntents, and it dynamically looks at user-generated input events, OS-level systemcalls, and network traffic usage.

CopperDroid [195] performs a dynamic behavioral analysis by logging low-level sys-tem calls to the Linux kernel and high-level API calls to the Android middleware.Based on these call profiles, apps can be compared to those of malware. AppPro-filer [196] follows a similar approach, though resorting to static analysis. It usesa pre-computed mapping of API calls to privacy-relevant behavior, and staticallyanalyzes the decompiled code of apps whether it matches such a profile.

AppIntent [242] analyzes whether external data transmissions in apps can be asso-ciated to user intentions. The tool combines static and dynamic methods. First, astatic code analysis identifies execution paths leading to external data transmission,and a symbolic execution searches for possible events leading to user actions. Then,a dynamic execution instruments the app to run automatically generated test casesthat will show if data transmissions match with user events.

Most of the approaches in this category rely to some extent on static analyses of thecode. Hence, we can expect that behavior profiles will not be detectable with thesetools when the code of the apps is obfuscated. The only exception is CopperDroid,which dynamically monitors system calls that do not change when code is obfuscated.However, the profile of the high-level API calls should be different, e. g., when normalAPI calls are replaced by reflection calls.

104

5.2 Related WorkTa

ble5.1:

Overview

ofap

pan

alysis

toolsfortheAnd

roid

platform

(API

SM:A

PIstrin

gmatching,

CG:C

allgraph

construc

tion,

Decom

p:Decom

pilatio

n,MW

:Malwa

reDetectio

n).

Cod

eAna

lysis

Requirements

Tool

Static

Dyn

amic

Decom

p.CG

APISM

Based

onPub

lic

GeneralAnd

roGua

rd[62]

33

3—

3

DroidScop

e[241]

3mod

ified

QEMU,m

odified

DVM

3

Flow

Droid

[89]

33

3de

xpler,

Soot,H

eros

3

Mob

ile-San

dbox

[210]

33

3ba

ksmali,Ta

intD

roid/D

roidBox

,ltrace

3

TaintD

roid

[76]

3mod

ified

DVM

3

MW

DroidMOSS

[248]

3ba

ksmalid

isassembler,fuzzy

hashing

DroidRan

ger[251]

33

33

malwarebe

havior

footprints

RiskR

anker[104]

33

3criticalb

ehav

iorin

code

paths

Permissions

COPES[36]

33

—Pe

gasus[52]

33

33

Soot

Perm

issionWatcher

[216]

app’sman

ifest,listof

criticalp

ermission

s3

Perm

ission

RiskSign

als[199]

app’sman

ifest,listof

criticalp

ermission

sProb.

Gen

erativeMod

els[185]

app’sman

ifest,listof

criticalp

ermission

sStow

away

[79]

33

Ded

exer,C

omDroid

VetD

roid

[246]

3mod

ified

Linu

xkernel,D

VM,T

aintDroid

WHYPER

[179]

app’sde

scrip

tion,

NLP

engine

3

ICCvulnerabilities

CHEX

[147]

33

DexLib,

WALA

,Stowaw

ayCom

Droid

[55]

33

3Ded

exer

3

DID

FAIL

[131]

33

33

Epicc,F

lowDroid

3

DroidChe

cker

[51]

33

33

Java

Decom

piler(JD),

ANTLR

Epicc

[172]

33

33

Dare,

Soot

(Spa

rk,H

eros)

3

IccT

A[141]

33

33

Epicc,F

lowDroid,A

pkCom

bine

r3

SCan

Droid

[90]

33

33

decompiler(not

implem

ented),W

ALA

Woo

dpecker[103]

33

3ba

ksmali

Behaviour

App

Intent

[242]

33

33

ded,

Soot,J

avaP

athfi

nder

App

Profiler

[196]

33

3de

d,Fo

rtify

SCA,S

towaw

ay3

Cop

perD

roid

[195]

3QEMU,G

DB

3

ProfileD

roid

[234]

33

3ap

ktoo

l,ad

b,strace,tcp

dump

105


5.2.2 Android Obfuscators

Since we want to evade analysis attempts with different obfuscation strategies, weneed an obfuscator capable of transforming DEX code. DexGuard is probably themost powerful commercially available obfuscator so far released for Android. Itcan rename identifiers and also features advanced transformations, such as utilizingreflections for indirect invokes, as well as string and class encryption. AlthoughDexGuard offers many features that are required by our evaluation presented inSection 5.4, we had to resort to building our own tool in order to perform all desiredmodifications.

The reasons for this were mainly additional requirements not covered by DexGuard.For instance, easily controlling indirect access to fields and arrays is not possible withDexGuard as well as injecting arbitrary instructions, methods or classes (cf. Sec-tion 5.4). Additionally, DexGuard does not directly modify DEX files, but works onJava bytecode. Details about our implementation can be found in Section 5.5.1.

Other obfuscators exist, but also do not fit our needs. Android applications areoften obfuscated with Proguard, the open source predecessor of DexGuard. It workson Java code, too, but offers less features and its main purpose is to optimize ap-plications by means of, e. g., string replacements and the removal of unused pro-gram parts. Among other obfuscators of Java code, we mention Allatori [1] andDashO [11]. DexProtector [143] is another proprietary tool to obfuscate DEX files,with properties similar to DexGuard.

Huang et al. [117] proposed to apply the algorithms of the Java bytecode obfuscatorSandMarks [57] on Android executables. This was done by decompiling DEX codewith the Soot framework, in order to transform it in its Java equivalent. They testedthe transformed applications against repackaging detectors. Unfortunately, as theauthors also stated, this approach has a lot of limits as the conversion from DEX toJava bytecode might create problems, for example, when managing type ambiguities(see also Section 5.4.3).

Rastogi et al. [194] presented DroidChameleon, which is related to our work. Theyevaluated which changes to a DEX file produce different results in the detectionrates for antivirus programs. They call methods indirectly and encrypt strings nextto the encryption of assets. What clearly sets us apart from their work are ourextended modifications we automatically apply to apps and our focus to evaluateanalysis systems in general—not just antivirus solutions. Besides, the authors onlyevaluated 6 samples against 10 antivirus solutions.

Protsenko and Müller present Pandora [188] and evaluate how well antivirus so-lutions can detect obfuscated Android malware. Their tool applies the following

106

5.3 Program Analysis Assumptions & Obfuscation Methods

modifications among others: String encryption, literal encodings inclusive array in-dex shifting as well as method in-/outlining, and the creation of getters and settersfor field access. Their transformations are accomplished with the Soot framework,and their main goal is to analyze antivirus robustness against transformation at-tacks. Zheng et al. did some early similar work with their tool ADAM [247]. Theyevaluated which APK modifications impact the detection rates of antivirus sys-tems. Their obfuscations include string encryption and the addition of dead junkcode. They apply much less obfuscation features compared to ours. Similar to otherworks, their goal was to evade antivirus signatures, which is only one aspect of ourcontribution.

Zhou et al. replace original bytecode with application-specific one in order to thwartstatic analysis and decompilation attempts [249]. This type of obfuscation is calledtable interpretation by Collberg et al. [58], and they considered it to be one of themost effective and expensive obfuscations available. In order to avoid the expensiveinterpretation, they are hooking the Dalvik interpreter to interpret their custombytecode. While being really effective against both dynamic and static analysis,the real bytecode of executed paths can be dumped out with dynamic analysistechniques and the artificial instruction set can be defeated by reverse-engineeringto some extent. As the authors themselves state, it can be used as a supplementwith other obfuscation methods for better protection.

Another well-known form of hindering analyses is packing: The original payload issomehow encrypted and only loaded and decrypted when it is being executed [204].Currently, there are already multiple services offering packing for Android applica-tions such as Bangcle App Shield [3]. While making static analysis hard, there areways to dump the original code after decryption from memory and then perform theanalysis on the decrypted part. Therefore, such methods should also be combinedwith other obfuscation methods for better evasion.

5.3 Program Analysis Assumptions & ObfuscationMethods

Based on the survey of existing analysis approaches, we now review the basic as-sumptions on which these analysis tools rely on in order to perform their analysisand discuss how these assumptions can be disturbed. More specifically, we explainhow applications can be altered to thwart analysis attempts. Our goal is to producean obfuscated app with the same semantics as the original one, but which cannoteasily be analyzed by existing analysis methods. We have three requirements: First,our altered app must run on Android devices without any required modifications to

107


the OS. Second, it must not be bound to any OS version unless the original app is.Third, we require no access to the app’s source code or Java bytecode, but operatedirectly on DEX bytecode.

5.3.1 Dynamic Analysis Evasion

We start with dynamic analysis techniques and describe how we attempt to hindersuch techniques from obtaining meaningful results.

Analysis Detection. A common approach in malware is to detect the analysis en-vironment and divert the application’s control flow away from its malicious parts.A more or less modified instance of the emulator shipped with the Android SDK iscommonly used by analysis systems, which can be detected by various ways. Vidas etal. list a variety of mechanisms to detect such environments successfully [232]. Ad-vanced detection mechanism leveraging the implementation details of QEMU amongothers were evaluated and tested by Petsas et al. [187]. All these revealing informa-tion sources should be changed in custom analysis environments to avoid detection.We can inject checks against analysis environments into each entry point of the appli-cation and divert execution if an analysis environment is detected. The same is truefor connected debuggers (detectable via Debug.isDebuggerConnected()). Still, wefound that stock or only slightly modified emulators are often used in analysis sys-tems and thus such techniques can be easily applied by malware in practice.

Time. As analyses are usually run for a limited time, another common tech-nique to evade dynamic analysis approaches is to perform malicious activities ata certain point in time. Android allows such artifical delays by using for exampleThread.sleep() or the AlarmManager. Analysis frameworks have adopted to thistechnique and fake the amount of elapsed time and therefore can circumvent suchmethods. Adding an expensive computation and then using the result as a require-ment for malicious actions is a more challenging analysis task. While Hasten [132]can detect and mitigate such execution-stalling loops, it is not available for mobiledevices. Further, the computation time for well known tasks can be measured, and ifthe timings differ from previously recorded ones, one can assume to run in some kindof analysis system. Keeping track of elapsed time could additionally be performedwith the help of external sources, such as NTP servers.

108


Entry Point Pollution. Programs typically have well defined entry points, e. g.,some kind of main() method. Android applications, though, can have a multitudeof entry points being event-driven and execution of their parts rely on the Androidframework. While there is no real main() method, most of the times there is astandard Activity for applications which is instantiated when the user clicks on itsicon. Next to this “main Activity”, an arbitrary amount of other Activities can bespecified which can be activated by the program itself or by other applications. Otherentry points include Receivers which are instantiated by the Android framework ifa matching Intent is handled by the application, and Services which typically runinvisible in the background and are usable by other apps. They can also be used byexternal programs. Depending on the specifics of these entry points, it is often notclear when and how they are launched, if at all. Thus, a dynamic analysis shouldinvoke all these entry points to generate a good code coverage rate.

To complicate analysis attempts, we can specify a random amount of unused entrypoints. As arbitrary code can be executed by all these, their code should also beanalyzed. These entry points could either let the application crash, exit, enter aninfinite loop, or hamper the analysis other ways, e. g., setting a flag that gets checkedbefore malicious activities take place.

Taint Analysis. Taint analysis is a powerful analysis technique where sources andsinks are defined and data is tainted with so called tags [201]. In a simple example,a framework method which returns the IMEI of the smartphone can be declaredas a source and the send() method of a socket as a sink. Whenever informationis requested from the source, it is marked with a chosen tag and whenever taggeddata is sent to a sink, a report is generated. This allows modelling of general dataflows and enables detection of information leaks. TaintDroid [76] was the first toolto offer taint analysis on Android. The problem of too many tags being assigned to(unrelated) data is known as overtainting, while undertainting describes a conditionwhere the sensitive data is not tagged properly. Both cases can be used to thwarttaint analysis. Our tool makes use of a list of sensitive sources from by Rasthofer etal. [192]. If data from such sources is represented as a numeric value (e. g., a serialnumber) or a string (e. g., contact information), our injected code automatically“untaints” the data by leveraging techniques described by Sarwar et al. [200] beforeit is further processed.

Multipath and Dynamic Symbolic Execution. Dynamic analysis frameworks haveaccess to all concrete values used by a program which are available during runtime,while only seeing the taken execution branch and miss all instructions in non-takenbranches. In order to increase code coverage, mainly two techniques were invented,

109


namely multipath execution [160] and dynamic symbolic execution [209]. The formerstores the program state when a branch is taken and executes first the code whichnormally would be executed, and afterwards executing the other path from a restoredstate. The latter takes another approach, by computing the conditions of conditionalbranches which must be met such that a certain code path is taken within a program.If all conditions are known, the program can be instrumented to take a path ofinterest or to report the required states. Both techniques become harder to applyfor larger programs because of the well known path explosion problem, which quicklygets hard computational-wise, thus limiting their practicality. Artificially amplifyingthis problem is rather easy with so called opaque predicates [58]. These predicates,while always known to be true or false, cannot be determined statically and musttherefore be evaluated at runtime. The normally never-taken path can also lead tothe execution of broken code or some flag could be set to hinder following analysissteps. Additional restrictions apply, such as the problem of keeping connection (e. g.,TCP) and program states intact. To the best of our knowledge, no framework forexecuting multiple paths for Android is available yet, but two publicly availablesymbolic execution frameworks exist: SymDroid [122] and ACTEve [26, 27]. Theformer one transforms DEX code to an intermediate language and emulates many ofthe framework APIs, while the latter one makes use of the Soot framework [228].

5.3.2 Static Analysis Evasion

In this section, we describe how static analyzers can be confused. Again, we describeseveral obfuscation strategies we utilize in order to prevent static analyses. Whilewe only discuss a small excerpt of possible transformations, these techniques aresufficient to hinder the analysis as we later see in Section 5.4. A comprehensivetaxonomy with Java bytecode in mind is provided by Collberg et al. [58].

Call Graph Decoupling. As Java supports reflections, most direct method invoca-tions can be replaced with indirect ones. A simple example is given in Listing 5.1.A direct call to Java’s println-method is called indirectly. If each invoke-x andinvoke-x/range instruction is replaced by an indirect call, a call graph would betotally degenerated and would only contain calls to Java’s Reflection API. Only in-vocations that cannot be replaced this way (e. g., calls to superclass methods dueto polymorphism and required invocations that initialize an instance) would be left.Most methods therefore seem to never being called. We have to point out that thecode in our example is not well-obfuscated for readability. This will change whenwe apply additionally techniques described in the following sections.

110


Listing 5.1: Indirect invokes. Code in line 4 is replaced with semantically equivalentcode from lines 6–28.

1 sget −o b j e c t v0 , Lj / l /System ; . out : Lj / i / PrintStream ;2 const−s t r i n g v1 , " some s t r i n g "34 invoke−v i r t u a l {v0 , v1 } , Lj / i / PrintStream ; . p r i n t l n : ( Lj / l / S t r i n g ; )V56 const−s t r i n g v4 , " java . i o . PrintStream "7 invoke−s t a t i c / range {v4 } , Lj / l / Class ; . forName : ( Lj / l / S t r i n g ; ) Lj / l / Class ;8 move−r e s u l t −o b j e c t v49 const /16 v8 , #i n t 1

10 const−c l a s s v7 , Lj / l / Class ;11 invoke−s t a t i c / range {v7 , v8 } , Lj / l / r e f l e c t /Array ; . newInstance : ( Lj / l / Class ; I ) Lj

/ l / Object ;12 move−r e s u l t −o b j e c t v613 check−c a s t v6 , [ Lj / l / Class ;14 const−c l a s s v8 , Lj / l / S t r i n g ;15 const /16 v7 , #i n t 016 aput−o b j e c t v8 , v6 , v717 const−s t r i n g v5 , " p r i n t l n "18 invoke−v i r t u a l / range {v4 , v5 , v6 } , Lj / l / Class ; . getDeclaredMethod : ( Lj / l / S t r i n g

; [ Lj / l / Class ; ) Lj / l / r e f l e c t /Method ;19 move−r e s u l t −o b j e c t v920 const /16 v12 , #i n t 121 const−c l a s s v11 , Lj / l / Object ;22 invoke−s t a t i c / range {v11 , v12 } , Lj / l / r e f l e c t /Array ; . newInstance : ( Lj / l / Class ; I )

Lj / l / Object ;23 move−r e s u l t −o b j e c t v1124 check−c a s t v11 , [ Lj / l / Object ;25 const /16 v4 , #i n t 026 aput−o b j e c t v1 , v11 , v427 move−o b j e c t /16 v10 , v028 invoke−v i r t u a l / range {v9 , v10 , v11 } , Lj / l / r e f l e c t /Method ; . invoke : ( Lj / l / Object

; [ Lj / l / Object ; ) Lj / l / Object ;

Breaking Use-Def Chains. Use-definition (use-def) chains can be used to trackdata flow throughout a program. In DEX code, such chains can easily be builtbecause access to fields and arrays is easily visible by examining the correspondingarray and field instructions (e. g., *put and *get opcodes). Therefore, in order tobreak those chains, those accesses can be transformed in indirect accesses. Doingso is exemplified in Listing 5.2. To hide field accesses, one has to specify the classand field name and then indirectly access it through the corresponding API (lines8–11). Array accesses can be handled in the same way (lines 14–15). This techniqueis strongly tied to the next one, so that they should be used in combination to hideclearly visible type information, as shown in the example.

Hiding Types. The previous techniques do not completely hide types, so that theycould be inferred by an analyst rather easily. Listing 5.1 already contains hints onhow that can be achieved. Many Reflection APIs accept parameters of the type

111

j.l.Object—every other object extends this type—see lines 11 and 28. The virtualmachine checks at runtime whether the passed objects match the expected types ornot. This enables us to get rid of most visible types, except for primitive types, andtypes referenced by method calls which cannot be invoked indirectly. All arithmeticinstructions (e. g., add-int) or branch-instructions (e. g., if-eq) work on non-objectregisters, which require unboxed primitive values. Replacing for example arithmeticinstructions with methods doing the same operation, is possible, and primitive typescould be boxed to their corresponding objects, while the type can be hidden again.Branching instructions cannot be replaced that way so easily, as control flow changesshould then be modeled by other means. We thus hide all types, and omit type-checking except for primitive types and primitive arrays (we also do not obfuscatearray accesses for primitive component types).

We additionally create new class instances indirectly. Each call to <init>() meth-ods is replaced with a call to j.l.r.Constructor.newInstance(). This still re-quires a class object, as shown in lines 10 and 13-14, which is done with thetype-revealing const-class opcode. These and const-string calls are left inthe example for readability. Class object can also be acquired indirectly by usingj.l.Class.forName(String). In this way, type information could be only retrievedfrom the String argument of this method. However, such strings can also be obfus-cated, attaining almost complete type information hiding. We later show how thiscan be achieved. If this is done with non-default classloaders, classes can be dynam-ically loaded from everywhere and any representation (e. g., encrypted files retrievedfrom the Internet). We additionally remove annotations which are not required bythe virtual machine but which “leak” type information, such as the signature of amethod.

Applying all these techniques on a method reduces the visible types to only basicJava ones, particularly from the Reflection package. In summary, we access fieldsand arrays and invoke methods including constructors indirectly over reflection.We also pass parameters as Objects whenever possible, making the type-checking aruntime-only operation. Class objects are also accessed indirectly and we only castprimitive types (and arrays) back to their corresponding types. If required, we alsoapply Java’s auto(un)boxing feature (e. g., converting a primitive int to an Integer).Listing 5.2 gives an example of how a value is retrieved from a static field and storedin a local anonymous array without revealing its type.

Bypassing Signature Matching. Some tools identify maliciousness based on theoccurrence of certain characteristics in an app. We list the most prominent ones andalso discuss how such detection mechanisms can be fooled.

112


Listing 5.2: Indirect static field and local array access without revealing the objecttype. Code in lines 4–6 is replaced with semantically equivalent codefrom lines 8–15.

1 const /4 v2 , #i n t 12 new−array v1 , v2 , [ Lj / l / S t r i n g ;34 sget −o b j e c t v0 , Lexmpl/Main ; . aF i e ld : Lj / l / S t r i n g ;5 const /4 v2 , #i n t 06 aput−o b j e c t v0 , v1 , v278 const−c l a s s v9 , Lexmpl/Main ;9 const−s t r i n g v10 , " aF ie ld "

10 invoke−v i r t u a l / range {v9 , v10 } , Lj / l / Class ; . g e tDec la r edF i e ld : ( Lj / l / S t r i n g ; ) Lj /l / r e f l e c t / F i e ld ;

11 move−r e s u l t −o b j e c t v812 invoke−v i r t u a l / range {v8 , v9 } , Lj / l / r e f l e c t / F i e ld ; . get : ( Lj / l / Object ; ) Lj / l /

Object ;13 move−r e s u l t −o b j e c t v014 const /4 v2 , #i n t 015 invoke−s t a t i c {v1 , v2 , v0 } , Lj / l / r e f l e c t /Array ; . s e t : ( Lj / l / Object ; IL j / l / Object

; )V

Checksums: Checksums are calculated over parts of or whole files by using hashalgorithms, and changes to the file most likely change the checksum.

Occurrences: Counting file sizes, number of classes, fields, methods, or instructionsto name but a few can be used to detect similar programs. This however is easilyavoided by changing, adding, or removing (unused) parts of a program.

Strings and Literals: In order to save disk space and memory, all unique stringsused by an app are stored in an array called string section and are referenced byan index. In practice, this means that all identifiers, types, and strings defined withconst-string instructions, as well as all other strings used by, e. g., annotations ordebug symbols are located in this one array.

Strings and static numerical values used within a program do not only give an ana-lyst an overview of the programs intents, but can also be used to detect repackagedapplications. Thus, hiding that information is a very effective technique to thwartany analysis attempts which rely on such information. Our tool replaces all instruc-tions which define or reference such information with a method invocation returningthe value from an encrypted data structure stored somewhere in the app. Specialcare has to be taken for the constant values 0 and 1, as they can also be interpretedas primitive booleans and the null-reference. There are also no opcodes to directlydeclare a primitive value of some specific type, this is done implicitly based on itsvalue, or in the case of methods, by their return type. This means that in somecases manual casting is required.

113


Entry Points: Android explicitly declares all possible entry points in the Manifest fileof the app. Many tools analyze entry points and attempt to detect maliciousnessor duplication of known software. Therefore, while renaming classes we also payattention to rename the entry points when needed. Adding new entry points mayalso affect the detection. As a common practice to export functionalities to otherapplications is by using intent filters instead of names, we can safely rename allnot-exported entry points.

Permissions: As many tools use permissions to rank the suspiciousness of applica-tions, it is useful to modify them. Removal of permissions will likely result in crashes,but new and unused ones can easily be added. It is possible to detect unused per-missions [79] from the API use, an assumption we break with our obfuscations.Therefore adding unused, normally looking permissions may skew results.

Source Code Analysis. Some tools perform their analysis steps with frameworksthat work at the source code level. If the decompilation process can successfullybe hindered, such tools cannot perform the analysis completely. Decompilers ex-ist which try to generate Java source code from DEX bytecode or smali code (adisassembled version of the former) while others first convert it to Java bytecode.We later report on the robustness of such tools and evaluate how they cope withartificially generated bytecode constructs.

5.4 Evaluating the Robustness of Analysis Tools

We implemented a tool that is capable of obfuscating arbitrary Android apps withthe techniques introduced in the previous section. In the following, we study howsuch obfuscated apps are handled by common analysis systems. We first discussstatic analysis tools followed by their dynamic counterparts. Afterwards, we showhow decompilers can be defeated. Following this, we evaluate how well antivirusproducts can detect well-known, but obfuscated malware samples. Although we donot intend to abuse bugs in analysis systems in order to prevent the analysis, we stillfound many bugs during our empirical evaluation. We end this section describing afew found bugs which lead to failed analyses or even broken devices.

We evaluated several analysis systems with self-written samples that exhibit de-tectable behavior targeted to the analyzers and which are obfuscated with the fol-lowing methods:

• Most strings, literals and types are obfuscated;

114


• classes, methods, fields and arrays are only accessed indirectly;

• unnecessary information is stripped from the application (e. g., debug section,specific annotations, unused strings); and

• all types except primitive ones are presented by the most generic one, namelyj.l.Object, where possible.

The applications are compiled for API level 10 (Android 2.3) and should thereforebe supported by all analysis systems. At the time of writing, that version is still usedby almost 15% of the users, while almost all other used Android smartphones runAndroid 4 [28]. We tested our samples on a Nexus 5 smartphone running Android4.4.2 before providing them to analysis systems in order to make sure that ourobfuscations can be considered functional.

5.4.1 Static Analysis Systems

We begin our evaluation of analysis systems with static analyzers. All of thesesystems are from academia and are freely available. Due to our heavy modifications,such tools should have many difficulties performing their actions. Our tool decouplesthe call graph almost completely, and therefore static tools cannot properly analyzethe program’s control and data flows. They additionally also see almost no types,literals, nor strings. All tools relying on such information will likely not be able toproduce usable and meaningful results.

We start with tools that analyze inter-process and inter-component communication.All of these tools have in common that they search for corresponding sinks andsources, i. e., Intents, Receivers and Content Providers. They additionally analyzewhich information (type) is communicated. Epicc [172] and ComDroid [55] areunable to properly analyze data being passed around after our obfuscation is applied.The same is true for FlowDroid [89]: It is unable to determine sources and sinksif all types are hidden and aborts the analysis. DIDFAIL [131] performs similaranalyses as the aforementioned tools, but was not able to start the analysis on anyof our test samples—it did indeed fail. All tested tools generate no results on ourtest samples after they are obfuscated. The only information available to these toolsis the information defined in the Manifest file. Without the information where datais generated and sent to, no analysis can be performed.

Other tools which work in a similar way should suffer the same fate. Saaf (cf.Chapter 3) for example is not able to retrieve meaningful information from generatedprogram slices. Analysis results also miss relevant information and cannot be used

115


to understand the program’s semantics. Permission analysis tools like Stowawayshould also fail, although we have not tested them as they are not available.

Additionally, some static tools such as DroidChecker rely on tools that analyze Javasource code. This implies that the application must be decompilable, and for ourtests we did not hamper decompilation. We provide a detailed analysis of how thiscan be done later in Section 5.4.3. In general, all tools that rely on the detection ofcalled methods and accessed types should fail, as the information is not there. Onlydynamic analysis tools are able to provide such information in a timely manner,which we will report on in Section 5.4.2.

We did not evaluate the available symbolic executions tools because of the follow-ing reasons. According to the description provided by SymDroid [122], all requiredframework classes used during evaluation are just modeled. Since we are time-wise unable to model many missing Android framework pieces for our tests, weare not able to properly analyze our obfuscated applications. The second tool,ACTEve [26, 27], relies on Soot. We later show in Section 5.4.3 that the analy-sis made through Soot can easily be interrupted. Additionally, the tool will likelyencounter the problem of path explosion and although the authors propose an algo-rithm that alleviates this problem, it still takes on average about 1h for simple testapplications [27] while not covering all possible paths. Due to these restrictions, wealso refrained from evaluating it as we do not believe it can generate suitable resultsfor our test application—let alone the addition of opaque predicates.

Our results clearly show that automatically applied obfuscation to programs com-pletely defeats static analyzers. Most information accessible by them is only ofgeneric value and does not lead to informative analysis reports. The heavy use ofreflections can be flagged suspicious by such tools, but it cannot be used solely fortagging apps as malicious due to its wide-spread use-cases.

5.4.2 Dynamic Analysis Systems

Although we heavily obfuscate program code, dynamic analysis tools should nothave any difficulties in detecting suspicious behavior. To test such systems, wewrote four applications which exhibit malicious behavior, but do not contain knownmalicious code detected by any antivirus software. All our applications display a“Hello World” Activity while invoking additional functions. The first applicationcreates three threads that each do at least suspicious actions. The first sends anSMS with static text to a hardcoded number, while the second one accesses theBrowser’s search terms and sends them unencrypted over a TCP socket to one ofour servers. The third one behaves like the second one, but steals the IMEI. Our

116


Table 5.2: Results for dynamic analysis services.Vendor Direct Sleep Alarm EmuDetect Network TaintsAnubis 3 7 3 7 3 7

ForeSafe 7 7 7 7 3 n. a.Mobile Sandbox 3 3 3 7 3 7

NVISO 3 7 7 7 3 7

Tracedroid 3 7 3 7 3 n. a.

second test application only sends an SMS, but does so after calling Thread.sleep()for 5 minutes. The third one also sends an SMS, but only after it started a serviceusing Android’s AlarmManager, triggered after 5 minutes. The forth applicationfirst attempts to detect whether it is running in an emulator and if the test isnegative, it sends an SMS and steals the IMEI. We chose the aforementioned actionsas they are often used by malware and should therefore be reported by analysissystems. All tests are implemented in a straightforward fashion, meaning that, e. g.,the SmsManager was accessed and an SMS was directly sent with values directlydeclared in that method and should be easily detectable.

Our emulator detection is rather simple as advanced ones are surely to be undetectedand would therefore cancel our suspicious actions, as has been shown by Petsaset al. [187]. We check against well-known IDs which default to known values inthe emulator: Build.Hardware, Build.Model, Build.Product, the network operator’sname, IMEI, and the Android ID. As these are hopefully changed, we perform anadditional test. We include the Google Play Services library in our application tocheck whether the Play services are correctly set up on the device and whether aconnection to them can be established. If that succeeds, we retrieve the AndroidAd ID. The last check is not complex, but requires a fully set up Google Playenvironment. If at least one of the above tests fails or if no Ad ID can be retrieved,we do not perform the malicious activity.

We show a summary of the results of our tests on several commercial and academicanalyzers in Table 5.2. Satisfying analysis results—meaning the analysis system wasresistant to our modifications—are marked with an “3” and information not avail-able with “n. a.”. Our first test application is referred to as Direct, while the othersare abbreviated as Sleep, Alarm and EmuDetect accordingly. All test applicationsare obfuscated. If provided results for that application do not contain hints for sus-picious behavior (such as simply marking it as “unsuspicious”), we mark them inthe table with a “7”. We also check whether the services allow Internet connectionsand mark it so if our applications connected back to our server.

117


If data is leaked that way, TaintDroid is able to tag such data and to report if taggeddata is being accessed by a sink. As we mentioned earlier, we make use of techniqueswhich try to lose such tags once attached to data. If leaked information is beingsent back to us and the report does not provide information about tainted data, butdoes so in other reports, we know that our anti-tainting techniques are successfullyapplied to leaked data. Lost taints are marked with a “7”. If tainted data is notspecifically marked in reports, but is nevertheless contained, e. g., in network dumps,we mark it as “n. a.” as no tags have been added in the first place.

The results obtained by the tested analysis systems presented in Table 5.2 demon-strate many shortcomings of existing analysis methods as we discuss in the followingparagraphs.

Anubis [2] for Android, also called Andrubis, displays results in a nice manner ontheir webpage and also presents a screenshot of the analyzed app. The reportsalso contain a section where all sent network data is listed on a host basis andone can easily see which data was leaked. A network dump can additionally bedownloaded. Anubis also assigns a malicious value ranging from 0 (likely benign)to 10 (likely malicious) to tested applications which for our samples always markedthem towards malicous, sometimes with a high value of ~9. Anubis successfullyanalyzed the Direct and Alarm samples but failed for the Sleep and EmuDetectsamples. Taint tags are not retained, otherwise the report contains a section labeled“Data leaks” which points to leaked information, e. g., the IMEI. Apart from theIMEI, the used emulator has not changed any identifiers and no valid Google Accountis set up, leading to an easy detection.

Dynamic results provided by Mobile Sandbox [210, 15] look very promising. It isthe only analyzer which is able to correctly analyze all but one test sample and onlyfails the emulator detection test because no valid Google account is available. Itis therefore the only system which changes all checked emulator identifying stringsbut also does not retain taint tags if we attempt to remove them from marked data.Since Mobile Sandbox is based on DroidBox [13], we did not evaluate it separately.

NVISO [168] was also able to analyze all four samples and provided nice results(including a screenshot) for the first “direct” test sample and ranking it as “confirmedmalicious”. All the information are available, although some can only be found inthe provided PCAP file. The report does not directly show that browser searches orthe IMEI have been leaked. This seems to be caused by our anti-tainting, as otherreports contain such information. Still, the sending of the SMS is flagged red in thereport and contains the destination as well as the text part. The connection to ourserver is also listed. Unfortunately, all other applications are ranked as “no maliciousactivity detected” and no malicious activities are detected. The used emulator onlyreports a changed IMEI—all other identifiers are set to their defaults.

118


ForeSafe [86] analyzed our samples and provided us with a screenshot of our run-ning application, meaning, the app could be started successfully. The report of thedynamic analysis rates our app with a “No Risk Detected”. There was no mentionabout any of our performed activities. Since nothing risky was detected, we checkedForeSafe against our non-obfuscated sample and then at least the sent SMS wasdetected with the correct destination and text part (but also did not flag the app assuspicious). No identifiers are changed during our tests, making the emulator easilydetectable.

The last analysis system we report on is Tracedroid [229]. The reports about ourtest samples contain a lot of information and provide a complete trace of the pro-grams. Even calls done reflectively are listed with the used parameters, making itpossible to see all the invoked methods, accessed classes, and fields. Reports areprovided in text files for each thread containing the execution trace, so an analysthas to look through them, or better, parse them for relevant activities. Still, thereports completely reveal what happened while executing the application. A screen-shot next to a (decoupled) call graph (PDF) and a network dump is also provided.Unfortunately, no strings that identify the emulator are changed, so the service iseasily detectable and malicious activities can be suppressed.

In addition to the analysis systems listed in Table 5.2, we also tested other knownsystems, but failed to do so for various reasons. AnaDroid’s web page [142] wasunreachable. CopperDroid [195] was not able to analyze our applications and theauthor asked us to generate samples for API level 8, which refers to Android 2.2,a rather old Android version. AppsPlayground [193] is also only available for aneven older version, namely Android 2.1. VisualThreat [233] just responded withan “unknown error” after some time. The non-obfuscated “direct” sample was an-alyzed correctly and marked as suspicious. After our samples were uploaded toSandDroid [17], no feedback was provided at all although reports for other appli-cations were updated on the webpage. Unfortunately, we got similar results forAndroidSandbox [34] (v. 1.0.0.15). Both tools were also unable to analyze our un-obfuscated samples, meaning some characteristic of the samples pose problems forthem. We can just guess that some problems are related to the included Play Servicelibrary which is large and complex, or that Google APIs are missing in the analysisenvironment.

Although our samples were implemented in a straightforward way in the first place,dynamic analyzers seem to have problems analyzing them. Our obfuscation tech-niques confuse such systems, although they should have no impact on dynamic an-alyzers unless we make use of the emulator detection and anti-tainting feature. Nosample exceeded the maximum file sizes and no system listed any restrictions whichwe did not met. If we look at all the results obtained while testing dynamic analysis

119


Table 5.3: Decompilation results for different test cases.

GO1GO

2CH

OCT DC BC SM RS

AMC

jadx � � � � � � 3 (3) (3)dex2jar � W � 3 3 � ∅ (3) IDare (JD-GUI) � W � I I � 3 (3) IDare (Soot) M 3 � I 3 � 3 (3) (3)

systems, we can conclude that many have problems analyzing our obfuscated testsamples correctly. In the end, we only got satisfying results from two tested system,namely Mobile Sandbox and TraceDroid. Although both did not pass the emulatordetection test and TraceDroid did also fail the sleep test, a combination of those twosystems would be beneficial while analyzing obfuscated samples.

5.4.3 Decompilers

In this section, we report on the results when testing four freely available decompilersfor Android applications, namely jadx, dex2jar with JD-GUI, Dare with JD-GUIand Soot. These decompilers try to transform DEX code to a Java-equivalent andare used by some analysis tools as well as in manual analyses. We present and testdifferent code constructs allowed by DEX which do not exist in Java with the aimof confusing decompilers.

We now present our test cases and condensed results can be found in Table 5.3 wherewe use the following notations: If the test case is handled correctly, we assign a “3”,and “(3)” if the code is almost correct and can very easily be fixed by an analyst.Invalid code will be marked with an “I”, meaning the code cannot be recompiledwithout further modifications. Syntactically correct code which reflects differentsemantics will be marked as “W” describing wrong code. If some instructions aremissing in the Java code, we note that with an “M” (meaning that code can behidden from such tools) and test cases which result in completely empty methodsare marked as “∅” if no errors are reported meaning that code can also be hiddenin this case. If the decompiler is not able to obtain any results for a method, butraises an exception (when that happens, decompilers often print a dump of the DEXcode), we mark it with “�”.

Goto Instruction (GO1/GO2). The goto instructions in particular can pose prob-lems to decompilers, as there is no direct equivalent in Java and the code can jump

120


almost arbitrarily inside a method, including between catch handlers. Imagine amethod as shown in Listing 5.3 where the invoked method will never throw anexception (with rare exceptions such as in out-of-memory scenarios). Still, the in-vocation is covered by a try-item which specifies two handlers. The problem here isthat both handlers refer each other and form a loop (line 3–4). While executing theshown method, these handlers are never touched. In Java, each handler forms a newscope and cannot interfere with other handlers, making this construct impossible.All decompiler crash with this test (GO1) while handling the method with the ex-ception of Dare (Soot) which completely ignores the try-catch clause. In the secondtest (GO2), we tested how decompilers handle the goto/32 instruction referring toitself. Example code is shown in Listing 5.4. The code jumps to the invocation of amethod and then enters an infinite loop (line 2), which is completely legit in DEX.Only Dare (Soot) works correctly by substituting the instruction with an emptywhile (true) loop. Dare (JD-GUI) and dex2jar call the method inside a while (true)loop and jadx crashes with an exception.

Listing 5.3: Misuse of the goto instruction, example (1).1 0x00 : invoke−s t a t i c / range {} , Lsome/ Class ; . someMethod : ( )V2 0x03 : goto 0006 // +00033 0x04 : goto 0005 // +00014 0x05 : goto 0004 // −00015 0x06 : return−void6 catches : 17 0x00 − 0x038 Lj / l / Nul lPo interExcept ion ; −> 0x059 Lj / l / RuntimeException ; −> 0x04

Listing 5.4: Misuse of the goto instruction, example (2).1 0x00 : goto 0004 // +00042 0x01 : goto /32 #000000003 0x04 : invoke−s t a t i c / range {} , Lsome/ Class ; . someMethod : ( )V4 0x07 : goto 0001 // −00065 0x08 : return−void

Catch Handler Order (CHO). Imagine a try-catch clause which catches two ex-ceptions and the second handler catches a supertype of the first handled exception.If we reverse the handler order, the second handler will never be executed, as thefirst one always handles the thrown type. A matching handler is searched based onthe type in the order of declaration. The Java compiler enforces correct orderingas otherwise dead code would be generated. A wrong order will therefore result ininvalid Java code if decompiled. For our example in Listing 5.5, the correct resultwould be to simply remove the second handler. As it turns out, no tool is able todecompile the method and all abort with an exception.

121


Listing 5.5: Wrong exception handler order.1 0x00 : const v0 , #i n t 422 0x03 : invoke−s t a t i c / range {} , Lsome/ Class ; . someMethod : ( )V3 0x06 : return−void4 0x07 : add−i n t / l i t 1 6 v0 , v0 , #i n t 15 0x09 : goto 0006 // −00036 0x0a : add−i n t / l i t 1 6 v0 , v0 , #i n t 27 0x0c : goto 0006 // −00068 catches : 19 0x03 − 0x06

10 Lj / l / Exception ; −> 0x0a11 Lj / l / RuntimeException ; −> 0x07

Clashing Types (CT). In DEX, some registers can have different types dependingon the usage. The instruction const v0, 0 for example assigns the DEX typeZERO to register v0. This type can then be interpreted in multiple ways: forreference types it refers to a null reference, for booleans to false, and for primitiveliterals to 0. In our test, we put such literal to fields with different types. As a result,only dex2jar correctly handles the types while jadx quits with a thrown exception.Dare (JD-GUI) tries to assign 0 to a boolean field, while Dare (Soot) casts 0 to anObject.

Dead Code (DC). Dead code refers to code which cannot be reached at all. For ourtest we inject valid code after return instructions. Ideally, such code does not showup in decompiled code. Results show that jadx quits with an exception. dex2jar andDare (Soot) correctly handle the code. Dare (JD-GUI) returns completely invalidcode with wrong assignments such as this = 5;.

Bogus Code (BC). For this test we inject an unused class with a method contain-ing invalid instructions. Such a method would be rejected by the Android Verifierduring runtime, if accessed. As the class is unused, the application will still beinstallable and executable. A subtle example would be, e. g., a method invocationusing a register holding an uninitialized reference. We quickly found code whereall decompilers bail out with an exception. With the sole exception of jadx, alltools stopped working completely while analyzing the method in question, skippingthe rest of the program and providing no output in the end. jadx only threw anexception for the methods in question but proceeded with other code.

Synthetic Modifier (SM). We also evaluated what happens if we add the syn-thethic modifier to classes, methods, and fields. Technically, the modifier hints thatthe construct was generated by the compiler and has no counterpart in the source

122

code. Bridge methods are treated as such. All decompilers correctly handle the code(thus ignoring the synthetic modifier—jadx also points out its presence by addinga comment to the class)—with the exception of dex2jar which completely hides thecontent of the class or method.

Removing Signature Annotations (RSA). DEX stores information about types ingeneric containers inside Signature annotations when needed. This is done in orderto deliver the information about what is being contained, e. g., in a List<T> fordebuggers. When removing signatures, the tested decompilers are unable to infertypes correctly. This causes missing type information with all tested compilers, butmay also break applications leveraging that information during runtime.

Modifier Changes (MC). Modifying access flags can also cause different resultswith different decompilers. In Java, an enumerated type extends j.l.Enum<T> im-plicitly and thus cannot extend any other class. However, in DEX it is possible todeclare any class with an ENUM access flag without runtime side effects. Whendecompiling such bytecode, dex2jar will mark the class as an enum and omit the su-perclass information completely, which is the same behavior as with Dare (JD-GUI).jadx will still show super classes correctly, like Dare (Soot) also does.

Judging from the results presented above, it is clear that all decompilers fail for atleast four out of nine test cases and no test case is handled by all tools with theexception of simply removing type information. Automatically creating such codereliably hinders the analysis of an obfuscated application if the analysis depends ondecompiled code. The most robust decompiler based our tests is Dare (Soot).

5.4.4 Signatures & Antivirus Detection

After our obfuscations are applied, all strings directly referenced by the the appli-ation’s code are removed from the string section and stored in encrypted arrays.If all feasible classes, methods, as well as, fields are renamed with random names,the original strings can be stripped from the strings section, leaving only obfuscatedreferences there. Annotations can also be removed to some extent as well as debuginformation. Applying all these actions leaves almost no original strings in the DEXfile and comparisons based on strings will likely not work anymore. Leftover typesare also not meaningful, as the package paths are also obfuscated. Counting classes,methods, and fields is also not viable anymore, as we inject methods and classes andcan also create bogus fields. Counting instructions or the ordering of them will also

123


likely fail, as many instructions originally present in DEX code will be replaced withother ones and most of the time one instruction is replaced with multiple ones.

If signatures are built upon such data, they will most likely be invalidated by ourobfuscation. Although it is not our primary goal, it is of interest to evaluate whetheror not our strategies are able to evade antivirus systems, since they are often uti-lized to protect common users against malware. It has been previously shown thatantivirus solutions are vulnerable against obfuscation attacks [247, 194]. However,such attacks were rather simple and were tested only on a reduced number of sam-ples and antivirus solutions. In our experiment, we test our obfuscation techniquesagainst more than 50 antivirus solutions provided by VirusTotal [101], which pro-vides a huge number of desktop-based solutions that are also able to detect mobilemalware. We also test the same obfuscations against 13 mobile antivirus solutions,as desktop ones might not have optimized signatures for mobile applications.

We evaluate the antivirus detection capabilities against complete APK files as wellas individual DEX files, because APK files contain additionally assets, images, re-source files and external native libraries that are subjected to analysis while beingindependent of the obfuscation on the DEX file. We test the effectiveness of ourstrategies on the samples of the ContagioMiniDump dataset [156] for mobile mal-ware, composed of 237 samples collected until July 2014. We chose this set as itis publicly available and therefore all samples should be known to antivirus ven-dors. All samples are obfuscated with the previously described techniques. Withrespect to desktop solutions, we observe that only 3 out of 50 engines were able todetect more than 90% of DEX obfuscated samples. Another two engines exhibiteddetection rate values of 50% and 60%. Moreover, 36 engines completely failed atdetection. Things improved when analyzing APK files, where some vendors showedbetter performances. This is likely caused by detection logics that also factor in ad-ditional files next to the DEX file which we do not modify. Detailed analysis resultsare listed in Table 5.4. In order to present meaningful results, we show results forboth original as well as obfuscated APK and DEX files.

Table 5.4: Contagio Minidump AV detection rates for VirusTotal (N=237).Vendor .apk .apkobf .dex .dexobf

McAfee 236 10 235 0AegisLab 236 21 1 1Ikarus 236 147 236 38McAfee-GW-Edition 235 10 235 0Commtouch 235 12 234 0

Continued on next page

124


Table 5.4 – continued from previous pageVendor .apk .apkobf .dex .dexobf

AntiVir 234 138 233 130ESET-NOD32 234 216 231 209Comodo 233 19 233 0GData 233 150 109 0BitDefender 232 63 7 0Ad-Aware 232 63 6 0Emsisoft 232 50 7 0F-Secure 232 189 224 69MicroWorld-eScan 231 63 7 0VIPRE 231 36 220 25AVG 229 213 233 214F-Prot 228 12 227 0NANO-Antivirus 228 14 226 0Kingsoft 228 7 0 0DrWeb 227 120 230 103TrendMicro-HouseCall 226 14 179 0Sophos 226 85 227 100Qihoo-360 226 99 98 0Fortinet 224 28 150 16AhnLab-V3 222 8 0 0K7GW 218 8 207 0Avast 210 175 210 85Baidu-International 205 8 160 0CAT-QuickHeal 204 88 204 85Kaspersky 202 222 214 225Tencent 200 6 197 0Symantec 188 123 159 111TrendMicro 184 13 179 0Microsoft 181 150 180 144Norman 161 7 161 0VBA32 157 4 157 0Agnitum 152 3 152 0Jiangmin 150 13 198 0TotalDefense 149 6 145 0ClamAV 117 25 102 8K7AntiVirus 88 8 40 0

Continued on next page

125


Table 5.4 – continued from previous pageVendor .apk .apkobf .dex .dexobf

Bkav 75 0 84 0Rising 32 2 32 2Zillya 9 5 1 0TheHacker 6 0 6 0ViRobot 2 0 0 0Panda 1 0 0 0nProtect 0 0 0 0CMC 0 0 0 0Malwarebytes 0 0 0 0SUPERAntiSpyware 0 0 0 0ByteHero 0 0 0 0Antiy-AVL 0 0 0 0Zoner 0 0 0 0

Although some vendors performed very well at detecting samples, we observe thatmany of their signatures were completely invalidated. In fact, in order to detectour samples, they resort to generic heuristics that do not allow for an accuratedescription of the malware. Obfuscated samples might be labeled as Android/Mal-Crypt.J or Android/Generic.AR, while unobfuscated ones point to specific families,e. g., Android/TrojanSMS.Agent.V or Trojan-SMS.AndroidOS.Opfake.bo. Lookingat the labels, we suspected that some of these signatures were tailored to obfuscationstrategies. In order to verify our hypothesis, we have obfuscated a non-malicious“Hello World” application and scanned it by the engines. And indeed, even thissample is marked as malicious and labeled with a generic signature.

Since the engines supported by VirusTotal mainly target the x86 architecture, it isnot guaranteed that they feature mobile-dedicated signatures. For this reason, werepeated the same test on 13 mobile antivirus solutions. We refrained from usingAndroTotal [149] as its service was slow by the time of testing. We used a self-buildframework which supports many antivirus solutions running on real smartphones.While conducting our test, signatures were updated to the last version available.Table 5.5 shows results for these antivirus solutions.

We observe that mobile solutions performances on unobfuscated APK and DEXfiles are in this case essentially the same, with a slight increase in detection results.Obfuscated files are detected much better with huge leaps in detection rates for somevendors. Vendors who already performed well for their x86 counterpart usually alsoproduced good results with their mobile product. The labels for obfuscated samples

126


Table 5.5: Contagio Minidump AV detection rates for mobile AV solutions (N=237).Vendor .apk .apkobf .dex .dexobf

Comodo 236 136 236 135Avg 235 215 234 214GData 235 226 235 226F-Secure 232 179 229 76McAfee 231 70 230 58DrWeb 230 118 230 106Zoner 229 0 28 0Kaspersky 216 216 216 229Avast 210 206 210 206ESET 210 210 210 207Trendmicro 210 209 209 176Symantec 204 114 114 101Webroot 12 0 5 0

also changed to a great extend and most of the signatures are generic ones, e. g.,Android:MalCrypt-J[Trj].

5.4.5 Bugs

Analysis tools are complex pieces of software and therefore certainly contain bugs.Finding such bugs was not the goal of this work, but we found bugs in tested toolsand systems which enabled us to completely evade analysis attempts. Such bugsare often only implementation bugs or corner cases developers did not anticipate.We therefore focused on taking away the assumptions the tools rely on rather thanexploiting bugs. For the sake of completeness we are reporting on them now.

We found out that the bytecode verifier for Dalvik does not do proper input checkingfor packages to be installed, causing a variety of problems. It is possible to causea Denial-of-Service attack with specially crafted DEX files, forcing the device toreboot and leaving it in an unbootable state, as the same file will be verified onsubsequent boots. This is a minor nuisance if the offending file can be removed(e. g., with a debug shell) from the file system, but when that is not possible theonly solution is to perform a factory reset.

In another case, the program counter of Android’s dexopt could be controlled by spe-cial instructions, causing the possibility to execute custom code with the privileges

127


of the install user. We were also able to modify DEX files making the applicationto crash immediately if a debugger is being attached to it.

Dedexer [178], a decompiler for DEX files, does not support the move-object/16opcode which we use for our obfuscations, causing all the tools depending on it foranalysis also to fail. This may be an overlooked fact, as the instruction does notseem to be widely used.

While the restrictions for valid identifiers are stricter in Java than in DEX, it ispossible to create names that may cause problems whenever an analysis applicationis enforcing the type checks on Java types. For instance, the jdb debugger does notallow setting a breakpoint on a method if the identifier is invalid in Java.

5.5 Implementation and Performance Evaluation

In this section, we first report on our implementation and describe the app set whichwe used to obfuscate and evaluate against. Since we rewrite applications, we alsoevaluate how our modifications affect the execution speed. After doing so, we discusswhich obfuscation strategies were not tested.

5.5.1 Implementation

Our tool is written in Java and heavily extends dexlib which is part of the smalitool [18]. In order to manipulate APK files, we leverage the widely used apktool [237].We added functionality to dexlib to automatically rewrite parts of a program in orderto properly obfuscate it whilst retaining program semantics. Our tool accepts aDEX or a complete package (APK) file as input. We directly rewrite DEX bytecodewithout converting it to have full control for modifications, while requiring to alsodeal with all of its limitations.

Google introduced a new runtime environment called Android RunTime (ART) forAndroid applications in Android 4.4 as a successor to Dalvik. In the next Androidversion (codenamed Android L), it will be the default runtime. Therefore, a stronglydesired feature is compatibility with it. While we are working on the bytecode andthe instruction set has not changed, ART still contains a completely new compileralong verification code. ART does Ahead-Of-Time compiling instead of Just-In-Time used in Dalvik, compiling bytecode to native code during the installation,which will likely allow our obfuscations to have a smaller runtime overhead in thefuture.

128

5.5 Implementation and Performance Evaluation

We tested our tool against a variety of popular apps offered in the top categorieson Google Play. We tested these applications to see whether they still continuedworking after our obfuscation is applied. We found that many applications runwithout problems and even the interaction between obfuscated applications works(e. g., messaging applications). Working applications include Firefox, Viber, Twitter,Telegram, Whatsapp, Shazam, and Instagram among many others.

Unfortunately, we also encountered some problems in the automated obfuscationprocess with our current prototype implementation. Some applications cannot beobfuscated by our tool correctly as we fail to precisely handle type-information insome cases. This might be related to wrongly used bootclasses, which describeframework classes and so on: if these change for different API versions, informationretrieved from the used bootclasses might be wrong. Other applications simplytrigger implementation bugs in our obfuscation logic, which leads to broken codethat often still passes the verification process upon installation. Examples of appsthat we could not automatically obfuscate include Facebook and Lovoo.

5.5.2 Performance

Depending on the app’s size, our tool can run for a few seconds up to few minutes.We now discuss the overhead our tool adds to the runtime as well as the size ofapps as these are important factors for the obfuscation. We start with artificialbenchmark results to get an idea of how large the slowdown can be if an applicationis obfuscated. We wrote four small test cases for this example. In our first test, weopen 200 sockets and immediately close them again. Our second test creates 200 filesand the third test creates 100 Java processes which execute the “id” command in ashell while reading its output. The last test loops over an array of 10,000 primitiveintegers and sums them up. Since operations occur on primitive types, they arenot obfuscated. The looping condition checks whether the last array position hasbeen visited, and this array-length instruction is performed indirectly in each loopiteration.

Each test is performed exactly twelve times while the best and worst timings arediscarded, and an average is taken from the remaining ten values. The results fortwo different smartphones are listed in Table 5.6. All of our described obfuscationtechniques in Section 5.3 have been applied. The Galaxy Nexus runs Android 4.3with Dalvik and the Nexus 5 runs the preview of Android L with the new ARTruntime.

What can be seen is that the overhead can vary by a huge margin, depending onthe test. The least overhead is given on the Nexus 5 for the process creation test

129


Table 5.6: Artificial benchmark results. Values in seconds.Device Obf. Socket File Process ArrayNexus 5 (ART) 0.7756 0.1581 2.4756 0.0127Nexus 5 (ART) 3 1.4549 0.9422 2.6515 0.4890Galaxy Nexus 1.5791 0.1972 1.6423 0.0375Galaxy Nexus 3 1.9243 0.8896 2.7481 0.8598

which is barely slower. The second worst overhead is introduced for the file creationtest on the same device which is almost six times slower. The worst slowdown isintroduced for the array-test. This test clearly shows how huge a slowdown canbe if only one single instruction is exchanged with a semantically equivalent callover reflection. On the Nexus 5 the obfuscated sample is about 39 times slower.Modifying instructions in loops which can otherwise be efficiently optimized by theruntime can lead to enormous slowdowns.

As these tests are purely artificial, we also evaluated what a user experiences whileusing an obfuscated app. For this test case we took two identical phones and installedthe original app in one and the obfuscated in another. Most apps do not performheavy operations on the main thread, which is also responsible for the GUI rendering,making the perceived slowdown unnoticeable if we simultaneously perform the sameactions on those two devices. What causes huge slowdowns are recursive operations,e. g., parsers that parse JSON objects retrieved from the Internet. Apps also feelslower if many instructions are triggered on input events. Firefox, e. g., automaticallystarts suggesting URLs which is an expensive operation, even unobfuscated. Suchactions are noticeable by the user, but can easily be blacklisted in order to avoid theslowdown—at the cost of unobfuscated program code.

Besides runtime overhead, we also evaluated how our obfuscation affects the sizeof obfuscated applications. Since several instructions are replaced with multipleones, the size can quickly grow and we found that the application’s size increases byapproximately 20% on average.

5.5.3 Skipped Obfuscation Steps

We did not evaluate all of the the obfuscation techniques described in Section 5.3.We now discuss which techniques were omitted during our evaluation and why.Although our tool is able to add bogus entry points into an application in question,we did not evaluate how tools deal with it. Static analyzers are already unable

130

5.6 Discussion

to obtain any meaningful results about the program semantics with just our othertechniques enabled. While they still can analyze generic aspects of applications, theneed to further distract them with additional entry points is unnecessary. Dynamicanalyzers also did not require that feature since all but one emulator can easily bedetected with simple tests.

The automatic injection of opaque predicates is also absent. Right now there is nodynamic tool that could be irritated by it—static tools based on symbolic executioncould compute path constraints, but they cannot analyze the semantics and all toolsknown to us are in a rough prototype state.

We also omitted techniques like method merging and inlining as well as movingmethods and fields around. Dynamic analyzers are not affected by this effect andstatic ones are already blind with respect to the performed obfuscations. We alsodo not obfuscate literal values of 0 and 1, due to the fact that they have multipleuse-cases. While it is doable to obfuscate lots of them, some cannot be changedwithout making larger modifications to the DEX code, as the same value may bere-used in different codepaths.

5.6 Discussion

In the following, we first discuss the limitations of our tool and how they can leadto semantically different execution or even broken code. We also explain how lim-itations could be fixed in future versions of our obfuscation tool and conclude ourwork.

Renaming classes, methods, and fields can be tricky for event-driven applications.For Android, the framework itself executes well-defined entry points which can beobfuscated if the definition is appropriately changed in the Manifest file. If someapplication leverages the names of the entry points instead of provided Intents, wecannot be sure that the existing client application continues to work after obfusca-tion. One way to tackle the problem is to allow blacklisting of such classes.

The same is true for code with implicit dependencies, which expect, e. g., fields ormethods to have certain names. While we can control the code of our application,we may still be restricted by the implicit API choices of the framework or of otherlibraries. One notable example is the Bundle.CREATOR field. This behavior is alsoexhibited by some object mapper libraries, such as the one provided by the JacksonJSON library, which map dynamic data to pre-existing objects. Without analyzingthe behavior of the application by, e. g., performing a runtime analysis, it is hard toknow which elements can be freely changed. We also do not currently implement the

131


complete Reflection API: If code iterates over all fields and compares the (renamed)name it will not find a matching one and probably take another code branch thanusually. Accessing such objects by addressing their (original) name directly worksfine, though.

Native code can cause similar problems. Although we are able to handle most ofthe Java Reflection API for obfuscated applications—even if methods, classes andfields are renamed—this does not work when the methods are called from nativecode. During our research we encountered multiple applications calling methodsfrom native libraries using the JNI interface. In order to make those invocationswork correctly, we would need to instrument the calls through JNI interfaces andmodify the names of the receiving side accordingly.

Android also has a quite limited amount of available stack memory by default. Itcan be changed for new threads, but the framework threads which execute most theof application’s code cannot be modified that way. If all invocations are replacedwith indirect ones, for each called method two additional methods are put onto thecall stack by the Reflection API. This can cause the stack to overflow for some callpaths if a certain (recursion) depth is reached. Notable examples are libraries whichprovide recursive parses for, e. g., JSON objects. The problem could also occuron not obfuscated applications if given too large input. If libraries exhibiting thisbehavior are found, they can be excluded from obfuscation.

Our obfuscation can of course not directly hide executed code against dynamicanalysis. The only way to mitigate this is to detect such analyzers and stop ordivert the execution. This is a generally unsolvable problem, though. By utilizingstatic or dynamic instrumentation frameworks and dynamic analyzers in general,it is always possible to deobfuscate a program as the runtime semantics must staythe same. Applied obfuscations in general make this task time consuming and itrequires a manual analysis.

Another limitation in our current approach are performance penalties caused by,e. g., method and string lookups. For most of the use-cases this is not crucial andusing ART instead of Dalvik gives us already promising speed-ups to the perfor-mance. In order to minimize the performance penalties, we could store looked upobjects such as decrypted strings and methods in a cache. This would speed upexecution especially when something is being fetched while in a loop.

Our test results let us conclude that many analysis tools are not capable of analyzingobfuscated apps in a satisfying manner. The situation for static tools is particularlybad. This result, however, was expected for such tools as obfuscation in generalgreatly interferes with their analysis techniques. Still, we have to point out that

132

5.6 Discussion

no tool was able to provide meaningful results and that a whole category of anal-ysis systems becomes dysfunctional by simply modifying the DEX code such thatdecompilers cannot process it anymore: Namely all tools that require Java sourcecode. Malware authors who obfuscate their malicious apps do not have to fear staticanalyzers as the effort which has to be put into deobfuscating such malware in orderto get usable results is high. Additionally, many antivirus products fail at detect-ing our obfuscated apps and, even when samples are detected, many signatures arecompletely invalidated, as our tests show.

Dynamic analysis systems are much more robust against code modifications, asexecuted code cannot be hidden if obfuscated apps should retain their semantics.Although such tools should be able to analyze our test samples, they also failed in alot of tests. Some systems did not work at all, while others failed to report malicious(or at least suspicious) behavior. Well-known techniques to detect emulators workflawlessly and can be utilized to hinder such systems from generating correct reports.Even the most obvious ones did work for some analyzers, such as checking whetherthe IMEI is set to something different than its default value. Sophisticated malwarecannot easily be analyzed by such systems, as one can expect that they actively tryto detect analysis systems.

The worrying aspect is that the code modifications as described in Section 5.3 canbe automatically added to a given (malicious) app. The intentions might not alwaysbe evil—as many software authors just try to protect their code and labor—but theimpact on analysis systems is huge. Malicious software can easily piggyback obfus-cated apps and clandestinely execute their payload while most detection systemsremain blind.

Since obfuscation techniques will not vanish and the usage of the Reflection API willlikely not be restricted on Android (and if so, code would just be moved to nativelibraries which enjoy an even greater freedom with respect to their instruction set),we need tools that properly analyze well-obfuscated applications. Dynamic tools arethe usual way to go, but the emulation detection mechanisms must still be pinpointedand disabled. A combination of static and dynamic instrumentation could help hereand more research on this topic is needed. Another aspect is to move monitors andother analysis components directly into the hypervisor of modern smartphones toimprove the precision of analysis methods.

Availability: To foster research on analysis of obfuscated Android apps andincrease the robustness of existing methods, we plan to offer a web service such thatarbitrary apps can be obfuscated for research purposes.

133

6Enhancing Other Devices’ Security with SmartProxy

We now present our work which leverages smartphones in order to enhance the secu-rity of normal PCs. This chapter results from a publication [111] at the Conferenceon Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA) in2012 in cooperation with Sebastian Uellenbeck and Thorsten Holz. This work hasbeen supported by the Federal Ministry of Education and Research (BMBF grant01BY1020 – MobWorm).

Abstract. In modern attacks, the attacker’s goal often entails illegal gathering ofuser credentials such as passwords or browser cookies from a compromised webbrowser. An attacker first compromises the computer via some kind of attack, andthen uses the control over the system to steal interesting data that she can utilize forother kinds of attacks (e. g., impersonation attacks). Protecting user credentials fromsuch attacks is a challenging task, especially if we assume to not have trustworthycomputer systems. While users may be inclined to trust their personal computersand smartphones, they might not invest the same confidence in the external machinesof others, although they sometimes have no choice but to rely on them, e. g., in theirco-workers’ offices.

To relieve the user from the trust he or she has to grant to these computers, wepropose a privacy proxy called SmartProxy, running on a smartphone. The pointof this proxy is that it can be accessed from untrusted or even compromised machinesvia a WiFi or a USB connection, so as to enable secure logins, while at the sametime preventing the attacker (who is controlling the machine) from seeing crucialdata like user credentials or browser cookies. SmartProxy is capable of handlingboth HTTP and HTTPS connections and uses either the smartphone’s Internet

135

6 Enhancing Other Devices’ Security with SmartProxy

connection, or the fast connection provided by the computer it is linked to. Oursolution combines the security benefits of a trusted smartphone with the comfortof using a regular, yet untrusted, computer, i. e., this functionality is especiallyappealing to those who value the use of a full-sized screen and keyboard.

6.1 Introduction

Regardless of the passing years witnessing numerous efforts to secure software sys-tems, we are still observing security incidents happening on a daily basis. Attackershave managed to compromise the integrity of computer systems, as techniques suchas control-flow attacks on software systems or exploiting logical flaws of applicationswere developed [22, 95, 165, 203]. Due to the growing complexity of today’s sys-tems, it is highly unlikely that we will have trustworthy computer systems withoutany security flaw at our disposal in the near future. We thus need to investigatehow certain security properties can be guaranteed despite compromised computersystems being in operation. In this chapter, we focus on the threat of stealing usercredentials from web browsers. More precisely, the attacker’s goal often entails il-legal gathering of user credentials such as passwords or browser cookies from analready compromised machine. Several reports on malicious software specialized instealing credentials provide evidence for the prevalence of this threat (e. g., bots andkeyloggers) [88, 113].

In practice, we do not only need to worry about the integrity of our personal (homeor office) computer, but of each and every machine we interact with and enter ourcredentials into. Surfing on public Internet terminals, using computers in Internetcafés, or simply browsing the web on an arbitrary in-office or friend’s computer canall bring about a number of potential threats. A golden rule of thumb for our safetyis that we cannot trust any such machines, or going one step further: We have toassume that they have been compromised. Still, all things considered, protectingthe credentials from attackers in such situations proves to be a major challenge:If an attacker has compromised a system, she has complete and full control overthe system and can modify the settings in an arbitrary way. Furthermore, she canread all memory contents, the CPU state, and all other information pertaining tothe current state of the system in question. Based on the so-obtained data, anattacker can easily reconstruct (user) credentials [106, 108] as it becomes harder (ifnot impossible) to protect the integrity of personal, login, and other sorts of data.

One idea for improving the integrity of credentials is to use external trusted devicesand generate one-time keys (e. g., RSA SecurID [73] or Yubico YubiKeys [244]).

136

6.1 Introduction

Here, even if an attacker has compromised the system, she only obtains a one-time password that cannot be reused, hence the potential harm is greatly limited.Nonetheless, this approach does not support legacy applications and requires changeson the server’s side since the one-time password needs to be verified by the server.Furthermore, the compromise of RSA and Lockheed Martin in 2011 [48] has illus-trated that such systems can also be periled, provided that the seed files for theauthentication tokens can be accessed by a skilled attacker or that the key is dirctlyextracted from the device itself [176]. A different idea is to use an external devicewith more computational power as a trusted intermediary supporting the authen-tication routine [47, 121, 238]. Such approaches typically either require changes onthe server side or an additional server that needs to be trusted. As a result, they aretypically not compatible with existing systems or trust needs to be put into anotherdevice not under the user’s control.

In this chapter, we introduce a system called SmartProxy that protects user cre-dentials when interacting with a compromised machine. The basic idea is to use asmartphone as a special kind of privacy proxy as we shall tunnel all network connec-tions of the untrusted machine over the phone and filter all sensitive data there. Tobe more precise, we intend the user to only enter fake information on the untrustedmachine, as we will have our tool substitute this data with the real credentials onthe outgoing network connections on the fly. For incoming network connections,SmartProxy will also replace different kinds of sensitive data (e. g., cookies) withimitative information, so that a potential attacker operating from the untrustedmachine cannot achieve her goals. As a result, a (semi-)trusted smartphone takescare of handling sensitive data related to the user and therefore, the confidentialinformation never reaches the untrusted machine on which an attacker could poten-tially track and observe it. This is achieved through selective usage of encryptedcommunication channels via SSL: SmartProxy intercepts the phone’s outgoingSSL connections and performs a Man-in-the-Middle (MitM) attack, eventually be-ing capable of substituting fake credentials with valid ones. All of the tool-initiatednetwork connections to the destination server additionally use SSL, meaning thatan attacker cannot intercept or eavesdrop on those channels.

Since the phone is a potential target for the attacks, we also make sure that we splitthe transferred information in such a way that even if an attacker compromises boththe machine and the smartphone, she at least cannot steal all data at once. This isachieved by encrypting all private data with a user-selected key for each credential.Conclusively, our tool enables a sound and robust method to handle credentials. Wehave implemented a fully working prototype of SmartProxy for Android-baseddevices. Our evaluation demonstrates that the overhead introduced by the tool isreasonable: Micro-benchmarks indicate that the SSL handshake typically takes less

137


than 42ms on a current smartphone, while in macro-benchmarks we found a typicaloverhead of less than 50 percent to the load time for popular websites.

In summary, we make the following contributions:

• We introduce the concept of a smartphone-based privacy proxy that can beused to preserve credentials in spite of the presence of a compromised machinethat an attacker controls.

• We have implemented a fully-working prototype and our performance bench-marks indicate that the overhead of SmartProxy on typical websites is mod-erate.

The following outline is used for the next sections of this chapter. Firstly, we discussrelated work in this field in the next section. We then present our attacker model anda brief overview of our proposed system in Section 6.3. Thereafter, in Section 6.4, weexhaustively describe how SmartProxy accomplishes our goals, and how a connec-tion between the computer and a smartphone can be established, as we at the sametime scrutinize and evaluate the security implications of our framework. Next upfollows a detailed evaluation and we present benchmark results in Section 6.5. Fol-lowing this process, we discuss the limitations and possible additions of our solutionand close this chapter with a discussion and conclusion in Section 6.6.

6.2 Related Work

Research in this area with respect to 2012 was focused on the attempts to solvesimilar problems as we discuss in the following.

Mannan and Oorschot [150] proposed an approach to secure banking transactionsby using a (trusted) smartphone as an additional trust anchor. In a very similarapproach, Bodson et al. [66] proposed an authentication scheme where users haveto take pictures of QR codes presented on websites in order to log in securely.The picture taken is then sent over the smartphone’s airlink to the web server forthe authentication to be performed there externally. To fulfill their needs, bothapproaches had to implement server side changes. Conversely, one of our main goalsis to only alter the client’s side by adding a self-signed root certificate to a browserand configuring the smartphone as a HTTP/HTTPS proxy, as we explain later.

Hallsteinsen et al. [107] also use a mobile phone to obtain a unified authentication.This approach is based on one-time passwords on the one hand and the need for aworking GSM system on the other. In this research, an additional Authentication

138

6.2 Related Work

Server is connected to both the GSM network and the service provider which theuser wants to authenticate against. The authentication requests are sent via shortmessages (SMS) in this setup. By doing this, the authors mitigate the risk of MitMattacks, but have to trust the safety of the user’s computer, which in our scenariomight as well be compromised.

Balfanz and Felten [33] developed an application that moves the computation ofemail signatures to a trusted mobile device so that the untrusted computers canbe used without revealing the key to the intermediary computer. However, thisapproach is limited in the application scope.

Burnside et al. [47] proposed a solution for a similar problem: They want to surf theweb with an untrusted computer and get alerted when the received data is differentto the data sent by the web server. Unlike the idea behind our approach, they do notexamine whether the data could be eavesdropped on. For their desirable outputs,they need a proxy that interacts with the untrusted computer on one hand and withthe web server from which the user requests data from on another. Requests aresent from the untrusted computer to the user’s proxy which then forwards them tothe designated web server. Following this action, the user must take a picture ofthe untrusted computer’s screen with a smartphone camera. This photo is later ontransferred to the proxy in order to let it analyze the data depicted. The proxy canthen decide whether the information the user can see on the untrusted computer’sscreen is changed by someone in the middle, and if this is the case, it will alarmthe user immediately. The downside of this approach is that it only catches “visualmodifications” and not injected JavaScript or similar processes, thus it does notprotect the user in any way aside for modified visible content of the website.

Perhaps closest to our idea is Janus, a Personalized Web Anonymizer [91]. The ideabehind Janus is to enable simple, secure and anonymous web browsing. Credentialsand email addresses are automatically and securely generated with the help of aproxy server for HTTP connections. The proxy assures that only secure credentialsand no identifying usernames and email addresses are sent to the web server. Incontrast to our work, Janus does only support SSL secured connections from theproxy to the web server and the proxy resides on the client machine, which doesnot fit our attacker model (c. f. Section 6.3.1). It does also not handle other securityrelevant information like cookies which our approach does.

Finally, Ross et al. [197] proposed a browser plugin which automatically generatessecure login passwords for the user. The user has to enter a “fake password” whichis prefixed with @@ and which is replaced by the plugin by some secure password.This approach is similar to our credential substitution process, but does not providea remedy against compromised machines.

139


6.3 System Overview

In this section, we describe the attacker model which has been employed throughoutthe rest of this work. Furthermore, we give a brief overview of our approach tosecuring user credentials in face of a compromised machine and sketch the high-levelidea.

6.3.1 Attacker Model

In the following, we assume that an attacker has compromised a computer systemand thus has complete control over it. This allows her to obtain the system state’sfull information and enables arbitrary modifications. On a practical level, this mightbe the case when an attacker managed to infect a computer with some kind ofmalicious software that can steal credentials or alter the settings of a web browser.Furthermore, we assume that the attacker cannot break a public key crypto systemand symmetric ciphers with reasonable parameters, i. e., we assume that unless theused key is known and out in the open, the used ciphersuites cannot be broken bythe attacker. As a special action, the attacker might disable our proxy for the webbrowser. Doing this will only result in a denial of service attack against the user, aslong as the user always only enters fake credentials into the web browser.

A user who wants to utilize the web browser and log in to a given website such asFacebook or Wikipedia needs to have valid user credentials. Essentially, he has nosimple means to decide whether the machine he wishes to put to work is indeedcompromised or not since it is not a machine under his control (e. g., a publicInternet terminal or an arbitrary in-office computer). He may also simply not knowhow to verify the integrity of the machine in question. Overall, it is a complexproblem in itself and we assume that the user cannot efficiently assess whether theendangerment has taken place or not. Luckily, the user has as an auxiliary means ofresorting to his smartphone which he can, to a certain extent, trust. We suppose fornow that the smartphone has not been compromised, which implies that the usercan run software on the phone without having to worry about an attacker. At thesame time, we understand that the user wants to surf the Web on a computer ratherthan a smartphone since it provides a larger screen and a natural-sized keyboard. Inaddition, the computer has more computational power, as it is for example capableto render complex web content quickly and with ease.

Based on these assumptions, the goal of our system can be clearly indicated asenabling the user to log in to a website without vexing about his credentials. Wefocus on the HTTP and HTTPS protocol, connections with arbitrary protocols oversockets are not considered for now. With our tool in place, the attacker will neither

140

6.3 System Overview

acquire the login credentials (i. e., username, passwords, or browser cookies) norobtain any information about them. Note that the system cannot protect the webcontent on the computer as the attacker is already assumed to be able to read allinformation on that device. For that reason, the attacker can still read as well asmodify all content accessed by the user, yet she cannot log in on the website ata later point in time as all valid user credentials are no longer there to be takenaway.

In addition, we need to make sure that an attacker cannot obtain credentials bycompromising the smartphone. This would imply that our system has a singlepoint of failure. Even if the attacker can compromise both the computer and thesmartphone at the same time, she remains unable to acquire all valid credentials.By splitting the actual credentials in a clever way (see Section 6.4.6), we warrantthat an attacker can only observe the data which are evidently made use of in realtime.

6.3.2 Approach

As stated previously, in order to protect user credentials from an attacker operatinga compromised machine, we propose to use a smartphone as a kind of privacy proxy.Figure 6.1 provides a comprehensive and paramount overview of our approach, asit depicts the flow of information in the system. As a preparatory step, the userneeds to configure the web browser on the computer in such a way that it engagesthe smartphone as a web proxy for HTTP and HTTPS traffic. As we discuss inSection 6.4.2, there are quite a few different ways for a smartphone being connectedto a computer, which leads us to pinpointing an easy way to set up our system.Moreover, the user needs to import a X509 V1 root certificate into the web browser,as we need to intercept SSL connections (as we explain later on).

1

4

(Compromised)Computer

WebserverSmartphone

23SSL Tunnel

Figure 6.1: Schematic Overview of SmartProxy.

141


Once the machine and the smartphone are connected (Step 1 in Figure 6.1), thesmartphone transparently substitutes fake credentials entered by the user on thecompromised computer with valid credentials, which are then sent to the target des-tination the user wants to visit (Step 2 in Figure 6.1). The smartphone can performthis substitution by carrying out a MitM attack on the HTTPS connection: Our toolintercepts the initial SSL connection attempt from the computer, establishes its ownSSL session to the target web server on behalf of the computer, and transparentlysubstitutes the fake credentials with valid ones. These steps require us to launcha fake SSL connection to the web browser on the computer, for which we spoof aHTTPS session pretending to be the targeted web server. We generate an SSL cer-tificate that corresponds to the targeted server using the root certificate importedin the preparation phase. Thus, this certificate will be accepted by the browser andthe user can regard this connection trustworthy. We discuss the workflow of ourapproach and the MitM attack in more detail in Sections 6.4.3 and 6.4.4.

Moving on, the smartphone supplants sensitive information sent from the website(Step 3 in Figure 6.1) to the browser (such as browser cookies) in a way that anattacker cannot obtain them when they reach the (compromised) computer (Step 4in Figure 6.1). Our tool successfully alters information on one hand, yet grants thepossibility of a web browser usage on the other. Meanwhile, an attacker does nothave the power to obtain any useful information from the processes taking place.More details about this substitution procedure and its security aspects are availablein Section 6.4.5.

Effectively, we move the handling of sensitive data from the (potentially compro-mised) computer to the smartphone, which prevents an attacker from stealing sen-sitive data. De facto, this carries the problem over to another device which we needto protect: The smartphone turns into an attractive target for the attackers, as itnow serves as a primary storage space for all the sensitive data. At the end, we needto be fully confident that the information is kept and retained in a way that fullyprevents an attacker from accessing it, even if she manages to compromise both thecomputer and the smartphone at the same time. This can be achieved by storingand provisioning information in an encrypted manner. Decrypting this data mayonly occur strictly on demand, as we explain in detail in Section 6.4.6. The potentialdamage is here-limited to the actually-used credentials exclusively.

6.4 Implementation

We now describe the implementation of the ideas sketched above in a tool calledSmartProxy. More specifically, we explain how the browser is able to communicate

142

6.4 Implementation

with the proxy running on a smartphone and what user interactions are required.We also clarify how the whole process of enabling secure logins on compromisedmachines is handled by the proxy. We conclude this section with a descriptionof secure storage of private user data within SmartProxy, as it is employed tominimize the attack surface.

6.4.1 Application Overview

SmartProxy is implemented as an Android application in Java and we use theBouncy Castle library to forge certificates. All services related to SSL are providedby Android’s own SSL provider AndroidOpenSSL. Our implementation of the HTTPprotocol supports both HTTP/1.0 and HTTP/1.1 (we implemented a required sub-set of the protocol, not the whole specification), multiple concurrent connections,SSL/TLS (for the rest of the chapter we simply use the shortened term SSL), andHTTP pipelining of browser requests. The proxy software includes a graphical userinterface on the smartphone, mainly utilized to start or stop the proxy and managesecurity-related aspects of the tool. More precisely, a user can manage trusted andforged certificates, stored cookies, and user credentials within the interface. Theproxy itself listens on two different TCP ports, one for the plain HTTP traffic, anda second one for the encrypted HTTPS traffic.

One goal of the design was the minimization of required user interaction sinceSmartProxy should not become yet another complicated task to deal with at theuser’s end. Nevertheless, some user interaction is unavoidable for normal operation.For the proxy to be used, it has to be connected to the computer in one of the waysenumerated in the next section. The browser on the untrusted computer then needsto be configured to employ the smartphone as proxy. This simply requires settingthe smartphone’s IP address and the ports as the proxy address of the browser. Ifit is the first time for engaging the proxy, an automatically generated X509 V1 rootcertificate has to be exported from the smartphone (e. g., either through the SDcard or by mounting the smartphone as an external storage device). It shall laterbe imported into the web browser as a trusted root certificate destined and valid forsigning other websites’ certificates.

Once the setup process has been completed, any type of user interaction is requiredin only two additional cases. First, in the instance where our SSL trust manager isunable to verify a server certificate. In practice, this might happen in several differentcircumstances, e. g., if the certificate is self-signed, not signed by a trusted authority,or if the certificate is for some reason invalid (e. g., it has expired). Beware that aninvalid certificate might equally indicate an attack as we discuss in Section 6.4.4.If a certificate cannot be verified, the user has to manually examine and perhaps

143


approve the certificate in a dialog on the smartphone. This is a replication of asecurity model behavior as it can be found in web browsers. If a user accepts thecertificate, an exception for this certificate is generated and further on it will beperceived and processed as validated. Second case of user interaction demand is ofcourse linked to the setup of the fake credentials for any website that the user wishesto log in to securely.

In addition to the aforementioned interactions, the user is able to list and deleteall stored cookies and edit credentials with their original and substituted values.SmartProxy also enables a user to list and delete all forged and manually trustedcertifications. For example, it might at one point be necessary to issue a removal ofa user-trusted certificate which has been later on proven invalid and shall thereforeno longer be used to establish encrypted connections to the corresponding server.

6.4.2 Communication Modes

The communication between SmartProxy running on the smartphone and the webbrowser running on the untrusted computer is possible in several different ways, aswe explain in the following.

Computer acting as WiFi access point. A computer provides a wireless hotspot oran ad-hoc wireless network to which the smartphone connects to. The smartphone’sIP is displayed in the user interface and it is this address that is used as the proxyaddress by the web browser running on the untrusted machine. With this setup,all network traffic is “routed back” to the computer and this particular networkconnection is used for tunneling, as it is likely faster than the network connectionavailable via GSM or 3G networks. Practically, solely rooted Android devices areable to connect to ad-hoc networks because vanilla Android devices do not supportthis connection mode.

Smartphone acting as WiFi access point. The Android OS is capable of serving asan access point for WiFi-enabled computers. For example, a notebook could connectto the smartphone’s access point and utilize the proxy running on the phone. Inthis configuration, all traffic is routed over the smartphone’s own Internet connection(e. g., GSM, 3G, but not WiFi because it acts as an AP), and the linked-in computerwill not be able to observe any altered outgoing Internet traffic.

144

6.4 Implementation

USB cable with USB tethering. In this setup, the smartphone is connected tothe PC via the USB port. The phone needs to be configured for the USB tetheringand the USB network device on the PC will in this case get an IP address fromthe smartphone. The smartphone’s IP address can again be displayed within theuser interface and is also used as the proxy address in the web browser running onthe computer. This configuration routes all traffic through the smartphone’s ownInternet connection and the computer does not observe any additional network traffic(similar to the previous case, but this time the WiFi connection may be used).

Smartphone and computer on same network. If both the computer and the smart-phone use the same (wireless) network, then the smartphone is accessible from thecomputer and the computer can easily use the smartphone as a proxy. Furthermore,the smartphone may use the Internet connection offered by the WiFi network, in-stead of its own GSM or 3G connection. If this setup is possible, it is the easiest touse in practice.

Upon familiarizing oneself with the list of communication methods above, one maynotice that all these setups do not require any special access rights on either side.Although the first three setups require special privileges on the computer, they arelikely to be enabled for all users because setting up a network interface is a commonuse case for most consumer targeted operating systems. This was an implementationaim for the software to be kept usable in most environments.

6.4.3 Proxy Workflow

We now present SmartProxy’s workflow and the different steps that are necessaryto enable the filtering of sensitive data. During the preparation stage, we need toconnect the smartphone to the computer by using one of the methods discussed inSection 6.4.2. Next, it is necessary to set up the browser on the computer (i. e.,configure a proxy within the browser) and start the proxy software on the phone.If this is the first time SmartProxy is used, the tool’s X509 V1 root certificatemust be imported into the web browser. After performing these actions, the actualworkflow can start which we discuss in the following. The workflow is also visualizedin Figure 6.2:

1. SmartProxy listens for new network connections.

2. When the user opens a website in the browser on the computer, SmartProxyaccepts this connection and spawns a new thread which parses the HTTPCONNECT statement.

145


SmartProxy ServerBrowser

1) Listen2) Send: "CONNECT"

3) Target SSL Handshake

4) Forge Certificate5.1) Send: "200 OK"

5.2) Local SSL Handshake

5.3) Send Request

6.1) Parse and Filter Request

6.2) Handle Request

6.3) Parse and Filter Response6.4) Forward

Response

Figure 6.2: Protocol sequence diagram.

3. SmartProxy opens a TCP connection to the desired web server, initiates anSSL handshake (called target SSL handshake) and verifies the server’s X509certificate. If it is not trusted or invalid (e. g., the certificate is expired or theattacker on the compromised computer attempts to intercept the connection),the tool ceases the action and notifies the user that an exceptional rule for thiscertificate has to be generated in the hopes of proceeding with the connectionto the selected server.

4. If this is the first time a connection is established for this particular destination,we need to forge the supplied server certificate with our own RSA keypair andstore it for later use. The forged certificate is an X509 V3 certificate signedby the proxy’s CA certificate. Note that the user has imported this certificatein the browser in the preparatory phase, thus the browser regards this forgedcertificate as valid.

5. SmartProxy responds to the web browser with a plain text 200 OK HTTPstatus code and upgrades the unencrypted TCP connection from the browserto an encrypted SSL connection with the forged certificate from the last step(called local SSL handshake). The web browser now assumes that it is talking

146

6.4 Implementation

securely with the designated web server. From this point forward, all networktraffic between the web browser and the destination web server is encryptedand will be eavesdropped by the proxy. This and the following step are similarto a normal MitM attack except for the signing part. A more in-depth analysisof the MitM attack we have performed is available in Section 6.4.4.

6. After the connection setup is done, all requests from the web browser are servedand filtered between the two endpoints. The filtering performed by our toolsubstitutes fake credential user data entered on the (potentially compromised)web browser with genuine credentials. Furthermore, we remove cookies andother types of sensitive data whilst hiding them from the web browser, asexplained in Section 6.4.5. In order to provide some feedback to the user asto when user credentials are replaced, the smartphone vibrates and generatesa visual output on each substitution.

This workflow corresponds to the SSL-secured HTTP connections, but a very similarapproach can be used for plain HTTP connections with only minor modifications.Steps 3–5 are not needed, and solely standard HTTP requests (e. g., GET or POSToperations) have to be processed. We discuss the security implications of plainHTTP requests in Section 6.6.

6.4.4 Man-In-The-Middle Attack

Our approach relies on a MitM attack for SSL-secured connections. Under the as-sumption that the user’s computer is compromised, we need to presume that anattacker has total control over the machine and therefore can read and manipu-late all data, including the input received from the proxy. This indicates that theSSL connection between the web browser and the proxy after the initial CONNECTstatement may also be intercepted and is therefore somehow useless. To keep theconfidential data hidden from the compromised machine, no encryption betweenthe web browser and the proxy is required, as sensitive data is only transferred inanother SSL-secured connection between the proxy and the designated web server.This connection can be guaranteed to remain unreadable by the attacker, even if thetraffic is back-routed over the compromised computer. This is ascertained by theverification of the web server’s SSL certificate within the SSL connection betweenthe proxy on the smartphone and the target web server.

All these circumstances make it feasible to use no encryption on the connectionbetween the web browser and the proxy, which would in turn decrease the com-putational pressure placed on the smartphone. However, this is unfortunately not

147


supported by the web browsers we have tested. They instead expect an SSL hand-shake after each CONNECT statement and an SSL “downgrade” to the NULL cipheris not supported. All things considered, this behavior is clearly highly beneficial forgeneral security reasons.

In order to successfully carry out our MitM attack, we need two RSA keypairs. Thesekeys have a modulus of 1024 bit which is believed to be safe enough, if we reckon thesecurity point of view as the one elaborated on above. We did not choose strongerkeys because of our desire to require as little as possible computational power on thesmartphone. One of these RSA keypairs is used in an X509 V1 certificate, whichis the root certificate of our own certificate authority. The other keypair is usedwithin all forged X509 V3 certificates as the public key. This way, we only needto create two different RSA keypairs and helpfully save computational time whenwe have to forge a new certificate. The web browsers do not check whether allcertificates they see use the same public key, thus they are prone to accept them aslong as they have a valid digital signature (from our V1 certificate): The browsersverify the complete certificate chain, but use the same keypair for all relevant SSLoperations. Interestingly enough, we actually have not intended doing this check-upin our implementation, but discovered it during the testing phase.

In order to keep the number of forged certificates low, hence enabling faster SSLSession resuming (see Section 6.5.1), step 5 from Section 6.4.3 generates forgedcertificates valid for more hosts than the original ones. If an original certificate isonly legitimate for the host a.b.c, its new counterpart will be valid for the followinghosts: *.a.b.c, a.b.c, *.b.c, and b.c. These alternate subject names are addedto the forged certificate for each host which is found in the original one.

If the proxy is accessed over an insecure WiFi connection, the aforementioned en-cryption between the proxy and the web browser is suddenly a sound cause forconcern. Another skilled attacker might sniff this connection and attempt to breakthe SSL encryption. This would allow her to observe the connection between theweb browser and the proxy over the airlink. Such an attacker might not be detectedby either side, thus the attacker in question might be able to capture data. However,this secondary attacker does not obtain more data compared to the attacker who hascompromised the machine, since both can only observe obfuscated data after thesubstitution by SmartProxy took place. An attack on the air link can be easilyprevented by increasing the keysize to a strength of 2048 bits or more. It is alsopossible to generate and use different keys for each forged certificate.

148

6.4 Implementation

6.4.5 Filtering

In order to transfer all security related information while surfing the web, the proxyhas to change some elements in the data stream between the web browser andthe web server. This is accomplished by implementing an extendable set of filterswhich can be attached to each data stream. These filters can in turn be used tochange arbitrary HTTP header fields as well as payload data. When wishing toperform a login on a specific website without inserting the real credentials into theuntrusted computer, the first action for a user to carry out is to set these accountsup within SmartProxy. The account data contains: real username and password,the domain where the login should be fulfilled, and a fake username and password.All of the above can be inserted into and modified through a GUI. The informationis encrypted before it is written into a database (see Section 6.4.6 for details), andcan then be used by our filters. Different filters are applied to the process of datamodification, which we describe in the following.

Password Filter

Real credentials should not be entered into the user’s computer, therefore one hasto exercise fake data input sent from the web browser to the server. Certainly,these fake credentials have to be substituted with genuine ones expected by theweb server for the login’s fulfillment. The Password Filter’s function is to find andreplace these fake credentials in the data stream. To do just so, the filter searchesthe POST data for false credentials, determines if the credentials are indeed enteredinto valid form fields, and then performs the substitution. Furthermore, credentialsare only substituted if the domain in the request matches the stored domain in thedatabase.

In order to defeat some attacks, two additional checks are performed before the realcredentials are inserted. First, we check if the password was already requested ashort amount of time before (e. g., 15 minutes). After a valid login, the user shouldbe identified by some session ID and no credentials should be used anymore, thusthis case might indicate an attack. Second, we check if the request contains at leastthree variables from which two are identical and a fake password. This could meanthat someone is attempting to change the password (which might be an attacker,see Section 6.6). In both cases, SmartProxy asks the user for confirmation.

Authentication Filter

In order to support HTTP authentication, we added a second filter that searches forthe Authorization field inside the request header. In this case, we used the sameframework as for the Password Filter, seeing as the user is also required to set up the

149


corresponding fake credentials. Currently, our prototype supports the widespreadBasic Authentication exclusively and not the lesser used but more secure DigestAuthentication. To effectuate this functionality, we only had to substitute fakecredentials with their genuine counterparts, just as we perform this in the PasswordFilter (except for them being Base64-encoded in this particular instance). Thefilter first decodes the data, then checks for a positive match, substitutes the fakecredentials, and finally encodes them back before performing the act of sending themto the server. Note that this filter cannot make use of the rate limit for substitutionsas the Password Filter since each request will contain the fake credentials which haveto be substituted.

Cookie Filter

A potential attack against our approach could be a session hijacking attack throughcross-site scripting. This event involves a session identifier (which authenticates theuser in the eyes of the web server) that is stored in a cookie and can be stolen byan adversary, who can then employ this cookie to take over a complete session. Tosolve such issues, we modify the cookies sent through our proxy. Cookies are set bythe web server with the Set-Cookie field in the HTTP header and are sent from theweb browser to the web server with the Cookie field in the HTTP header. The firstfield is originating from a web server and has to be altered in such a manner thatthe data reaching the browser cannot be brought into operation for an attemptedsession theft.

This is accomplished by all cookie properties (e. g., VALUE, DOMAIN, NAME, or PATH)being stored in a database and the value of cookies being changed to an arbitrarystring. For the reverse direction (web browser to web server), the cookie valueshave to be restored from the database. Lastly, cookies can be created on the clientmachine directly in the browser with the use of techniques such as JavaScript orAdobe Flash. We decided to let these unknown cookies (for our proxy failed to noticea corresponding Set-Cookie HTTP header field) pass through in an unaltered stagebecause we do not think that an adversary can remodel such “self generated” cookiesto be harmful for the user, and to be compatible with websites which depend on thisbehavior. Once we have dropped them, several websites responded and complainedwith warnings such as “Your browser does not support cookies!”.

If we substitute all cookies, we might provoke errors with scripts which use cookievalues to, e. g., personalize the website. To overcome this, we only substitute cookieswhich have a value which is at least eight bytes long and has a high entropy sincethese cookies likely store sensitive data. Shorter cookies or cookies with low entropyare likely not security sensitive since an attacker could brute-force such cookies.Furthermore, all cookies which contain special strings such as id, sid, or session in

150

6.4 Implementation

the name are forced to be substituted. We assume that all security relevant cookiesare protected this way and that personalized website settings are still functional.To be able to ensure the proper working of a website, a black- and a whitelistcan be set up for each domain to define which cookies shall (not) be protected bySmartProxy.

Since some websites use cookie values to form special requests, we implemented acompanion filter for the Cookie Filter to preserve the functionality of websites whichdepend on this behavior. One example is the Google Chat within GMail, whichperforms the following request: GET /mail/channel/test?VER=8&at=COOKIE&i...Here, the substituted value is meaningless and it hinders the website from operatingnormally. The purpose of the companion filter is to search for substituted cookievalues in requests and to insert the correct value within outgoing requests.

Note that all cookies are only replaced within requests or the COOKIE header fieldsif the destination domain matches the domain which is stored in the database forthe corresponding cookie. This further hinders an attacker from stealing cookies.

6.4.6 Personal Data Encryption

The smartphone is a kind of a single point of failure when one is investigating thesecrecy of the stored user credentials. If it gets lost, stolen, or compromised, alldeposited credentials must be considered known by a third party. To prevent thisfrom occurring, we store all credentials in an encrypted form in the database insuch a way that makes them unlikely to be revealed to a potential attacker. Eachgenuine username ug and password pg is encrypted with a key k derived from a fakepassword pf using a password-based key derivation function (PBKDF2 [125]). Theencryption of ug and pg is performed with AES in CBC mode.

To improve the security of the genuine data, each fake password should be different.The fact that a fake password is used to derive the encryption key k for a realusername and password leads to the fact that the fake passwords must not be storedin the database. This hinders the filters from Section 6.4.5 to find and replace thesestrings, as they may then appear almost anywhere in the header or payload, andtheir appearance may be just as arbitrary. To enable the matching of arbitraryfake password strings, the user enters the fake password in a special format, e. g.,fp_fakepass1_. That way, the filters have only to look for strings enclosed by aleading fp_ and a closing _. This is a process that can be put in action easily. Theintermediate string is used as pf , and ug and pg may be decrypted with the latteroperation’s result. If by chance multiple strings are enclosed in our chosen markers,the corresponding filter will attempt to decrypt ug and pg with all found strings as

151


pf , eventually decrypting the credentials. The correct pf can easily be determinedby the use of a checksum.

6.5 Evaluation

We have implemented a fully-working prototype of SmartProxy. In this section,we present benchmark results, analyze the overhead imposed by our proxy software,and discuss some test results of using our proxy on popular websites. All benchmarksare divided into two categories, namely micro- and macro-benchmarks. The formermeasure “atomic operations’ (e. g., an SSL handshakes on the smartphone), whilethe latter are executed to estimate additional load time caused by our tool whenaccessing several popular websites. The smartphone we used in the testing phasewas an HTC Desire with Cyanogen Mod 7.0.3 (Android 2.3.3, not overclocked, usingthe default CPU governor). Additionally, the same benchmarks were performed ona vanilla Samsung Nexus S with Android 2.3.4. All results were comparable, thus weomit them in the following for conciseness reasons. On the client’s side, we used wgetin version 1.12 to automatically establish new connections, and our test smartphonedevice was connected to the Internet over a wireless connection to a 54Mbit APwhere a downstream of 2.7MB/s is reachable. We used the adb port forwardingtechnique to launch and maintain a connection between the web browser and theproxy.

6.5.1 Synthetic Benchmarks

A main feature of the proxy is its ability to alter the payload in the SSL-securedHTTP connections, thus we need to evaluate the performance of the necessary steps.All measurement times are averaged over 100 test runs. In order to be able tomeasure these times without too much interference from the network latency, webserver load, DNS lookups and so on, we have applied the benchmarks to a localserver which is only three network hops away. The server is equipped with a Corei7 CPU, 8GB of RAM and was running Ubuntu 11.04 with Apache 2.2.17 usingmod_ssl without any special configurations or optimizations.

SmartProxy is required to complete two different SSL handshakes for normaloperation, hence we tested several configurations for this prerequisite. SSL Sessionresumption—for an explanation read below—was explicitly disabled for these bench-marks. At first, we tested the speed rate of the handshake to the target server, andevaluated how this depends on different RSA key sizes and ciphersuites. Then werepeated this test for the local SSL handshake. All measurement times are stated

152

6.5 Evaluation

Table 6.1: Micro benchmark for thetarget SSL handshake (KS= Keysize in bit, AVG = Av-erage Time, SD = StandardDeviation).

KS Ciphersuite AVG [ms] SD [ms]

512 RSA/AES/256/SHA 29 241024 RSA/AES/256/SHA 33 172048 RSA/AES/256/SHA 37 94096 RSA/AES/256/SHA 90 17512 DHE/AES/256/SHA 84 15

1024 DHE/AES/256/SHA 83 172048 DHE/AES/256/SHA 90 174096 DHE/AES/256/SHA 124 17

Table 6.2: Micro benchmark for thelocal SSL handshake (KS= Keysize in bit, AVG = Av-erage Time, SD = StandardDeviation).

KS Ciphersuite AVG [ms] SD [ms]

512 RSA/AES/256/SHA 35 161024 RSA/AES/256/SHA 42 202048 RSA/AES/256/SHA 90 684096 RSA/AES/256/SHA 360 326512 DHE/AES/256/SHA 3,734 4,422

1024 DHE/AES/256/SHA 3,344 4,0962048 DHE/AES/256/SHA 3,551 4,1014096 DHE/AES/256/SHA 3,670 4,115

without the added time necessary to validate a certificate, with the exception of aspecial check designed to investigate whether the certificate has already been vali-dated at some prior time. Certificates are validated when they are seen for the firsttime and then stored for later use. Each “new” certificate is first checked againstthose pre-existing ones to determine whether it is already known and valid, andthen, provided it is in the clear, it is accepted. This greatly speeds up the processthanks to the fact that the Online Certificate Status Protocol (OCSP) and certifi-cate checks against Certificate Revocation Lists (CRL) are usually time-consuming,which needs to be done only once for each certificate during the proxy’s runtime.

The first SSL-related action that occurs when a browser requests a secure connectionto a HTTP server is a client handshake from the proxy to the designated host,necessary to establish a MitM controlled connection between these devices. As perour tests, this takes approximately 33ms for a 1024 bit strong RSA key with our ownserver. Table 6.1 provides an overview of the benchmarking results for establishinga secure channel between the proxy and our local test web server, all for differentsetups. What we discuss below is that these handshakes were all completed in anacceptable time, even with a 4096 bit strong RSA key, and, equally, for ephemeralDiffie-Hellman (EDH or DHE) ciphersuites, which are generally slower.

In the second step, the certificate presented by the web server has to be forged inorder to establish a secure and trusted connection between the web browser and theproxy. The average time to forge and sign such a certificate is 150 ms, which issufficiently fast and needs to be only performed once for each accepted certificate.Operations like persisting a new certificate in a keystore are also here-contained.

During the third and final step, the web browser upgrades its plain text connectionto the proxy to an SSL-secured connection type. This implies an SSL server hand-

153


shake on the proxy involving a forged certificate. Once again, this is a pretty fastoperation which takes only 42ms on average for a 1024 bit strong RSA key. Table 6.2provides an overview of how long the local SSL handshake takes for several config-urations. In order to accomplish decent times for the local handshakes, it is crucialto choose the right ciphersuites. While plain RSA handshakes operate fast enougheven for a 2048 bit key, a noticeable delay is caused by a 4096 bit key. Conversely, ifthe web browser chooses EDH ciphersuites for the session key exchange, the time tocomplete such a handshake might be pinned down as anywhere from 1 to up to 10or more seconds for each handshake—even with the same certificate, which explainsthe high standard derivation for these tests. EDH handshakes are more secure, yetevidently and understandably more expensive than plain RSA handshakes. Still,normally they do not reach the factor of 100 which we measured. We have reasonsto believe that this operation is not well optimized in the used OpenSSL stack onAndroid, albeit it employs the native code in order to do the expensive operations.The fact that SSL handshakes with EDH ciphersuites to the target server are muchfaster indicates that this code lacks optimizations for the server mode of the hand-shake, cf. Section 6.5.2. We believe that it takes a relatively long time to computethe EDH parameters and this phenomenon would explain the vast amount of timeit takes to complete a local handshake with EDH ciphersuites. Conclusively, to en-able fast local SSL handshakes, we only accept the following secure ciphersuites3

for these cases: RSA/RC4/128/SHA, RSA/RC4/128/MD5, RSA/AES/128/CBC/SHA, andRSA/AES/256/CBC/SHA. Nevertheless, all available secure (EDH) ciphersuites are en-abled for the SSL handshake to the web server.

In order to accelerate the expensive SSL handshakes, SSL and TLS support themechanisms called Sessions. Sessions are identified with a unique ID by the clientand the server. Once a completed handshake is bound to such a Session, it will nothappen again when the Session is still valid. The client and the server may bothreuse a Session, and the already negotiated cryptographic parameters that comewith it. This feature can greatly facilitate the establishment of new connections.As an initial handshake from the first step is completed, a new connection to ourweb server is established within under 30ms on average from the proxy. A standardestimate for a resumed local server handshake to take place is about 40ms.

We did not benchmark the SSL operations for different websites separately becauseall operations, except the SSL handshake to the web server, use the same statickey materials in the first step which results in almost the same benchmark for eachoperation.

3 With respect to 2012. In the meantime the handshake performance was probably fixed and RC4cannot be deemed secure anymore, as serious flaws have been discovered [23].

154

6.5 Evaluation

Table 6.3: Evaluation results for global Top 25 websites from alexa.com withoutduplicates and sites that do not support SSL (KS = Keysize, HS = Handshake,SD = Standard Deviation, LT = Load Time, OH = Overhead).

Micro Benchmarks Macro Benchmarks

Website KS [bit] Ciphersuitea HS [ms] SD [ms] LT [s] OH Login

google.com 1024 RSA/RC4/128/SHA 91 49 0.95 23 % Xfacebook.com 1024 RSA/RC4/128/MD5 424 103 1.37 58 % Xyoutube.com 1024 RSA/RC4/128/SHA 71 8 2.93 20 % Xyahoo.com 1024 RSA/RC4/128/MD5 192 52 4.34 26 % Xwikipedia.org 1024 RSA/RC4/128/MD5 363 169 5.11 50 % Xlive.com 2048 RSA/AES/128/SHA 595 31 1.60 23 % Xtwitter.com 2048 RSA/RC4/128/MD5 400 97 3.66 17 % Xlinkedin.com 2048 RSA/RC4/128/MD5 426 72 1.93 78 % Xtaobao.com 1024 RSA/RC4/128/MD5 2,716 2,817 34.82 154 % � b

amazon.com 1024 RSA/RC4/128/MD5 263 19 2.24 18 % Xwordpress.com 1024 DHE/AES/256/SHA 527 52 16.66 204 % Xyandex.ru 1024 DHE/AES/256/SHA 274 50 5.75 260 % Xebay.com 2048 RSA/RC4/128/MD5 587 51 1.49 46 % Xbing.com 1024 RSA/RC4/128/MD5 52 25 0.62 142 % X

a DHE with RSA and AES in CBC mode for local handshake.b We were not able to create a login for this website because we could not translate the content of this site.

6.5.2 Real-World Benchmarks

We have selected the global top 25 websites as they are listed at www.alexa.com tobe our test sites for additional benchmarking, yet we omitted “duplicate” sites likegoogle.co.jp and google.de, as well as all the sites we were unable to understandcontent-wise due to its language (despite the attempted use of website translators),e. g., qq.com. All the web pages tested are listed in Table 6.3. The main featureof the proxy is its ability to withhold crucial information such as user credentialsand cookies, cf. Section 6.3. This functionality is tested on all popular websites.Whenever it was possible, we created a login and tested the functionality. We foundout that our proxy successfully substituted fake credentials with genuine ones on alltested websites.

We measured SSL handshakes for real-world sites (micro-benchmarks) and againused wget for these tests. Firefox 5.0 with the Firebug 1.8.1 plugin was used to mea-sure website load times (macro-benchmarks). No caching was undertaken betweeneach page reload and we additionally invalidated all SSL Sessions after each con-nection for the micro-benchmarks. The certificates are validated by mirroring themethod described in the previous section. Table 6.3 lists all times and the impliedoverhead.

155

www.alexa.com

google.co.jp

google.de

qq.com


To keep the impact of unknown side effects low, we trialled all websites in a row andrepeated this 100 times on a rolling basis. In order to measure the overall overhead(macro-benchmarks), we tested each website five times and calculated the load time,comparing the results for when the proxy was used versus the same action withoutit being used.

It is vital to note that these times include a lot of operations with timings which wecannot influence or control. These include the web server’s load, the time needed tolook up the IP address, certificate checks (OCSP/CRL), as well as general networklatency. Overall, the SSL handshake from our proxy to the web server is fast enoughnot to hinder the user’s experience. This is interesting because the SSL Sessionscan be resumed, the feature which was explicitly disabled for the micro-benchmarkstesting here (see Section 6.5.1). As this is the time it takes for the initial handshake,it does not have a huge impact on the page load times for the subsequent handshakes.One notable exception is taobao.com, but this page was generally slow with all ourtested devices.

Table 6.3 shows that the total overhead is reasonable when SmartProxy is used asa privacy proxy. While the tool has a certain overhead, it does not in any case makesit unacceptable to surf the Web. For the majority of the tested sites, the overheadis less than 50%, which means that the web page will load up to 1.5 times slower.These times refer to a complete web page load with an empty cache. When the webpage is accessed with the proxy and the web browser uses its cache, the overheadis sometimes not even noticeable by a user. Some sites such as twitter.com andyandex.ru have a larger infrastructure and several SSL handshakes may be neededin order to load a single page, for the content is served from many different hostswith different SSL certificates. Our approach to add additionally derived alternatesubject names to the forged certificates, cf. Section 6.4.4, may reduce the amountof SSL handshakes which are needed to be performed, although this depends on theinfrastructure of the specific website, as the completely different overhead for thesetwo web pages shows in Table 6.3.

Another aspect which has a certain impact on the overhead introduced by Smart-Proxy is the method used by the web servers to handle the connections. If theyclose a connection rather than allowing our tool to reuse it, we need to establish anew connection to the proxy and to the web server, which implies two additionalSSL handshakes. This takes time and is clearly visible in the measurement resultsfor wordpress.com, a site that exhibits this behavior. This is obviously an imple-mentation detail, but our prototype currently allows only “pairs of connections”:namely one connection established from the web browser is tied to one connectionto a designated web server.

156

taobao.com

twitter.com

yandex.ru

wordpress.com

6.6 Discussion

Aside for “normal web surfing”, we evaluated how fast we are able to download largefiles. The average download speed with SmartProxy enabled is only slightly slowerthan the download without the proxy. We have seen download rates that differ byonly a few KB/s up to some 100KB/s. This of course depends on the accessed serverand the WiFi connection’s quality. The fastest download speed achieved with theproxy enabled was 2.7MB/s. To complete our evaluation, we did some research intoa selection of the video portals to check if they work correctly. The video portalstypically make use of many different web technologies to stream the video contentto the browser. When performing our tests, we have not identified any problems onthe three most popular video portals from the global Alexa ranking.

6.6 Discussion

In this chapter we have introduced an approach to protect user credentials from aneavesdropper by taking advantage of a smartphone that acts as a privacy proxy, i. e.,the smartphone transparently substitutes fake information entered on an untrustedmachine and replaces it with genuine credentials. We have shown that it is possibleto enable secure logins despite working on a compromised machine. The steps forachieving the desirable output are relatively easy, as they mainly require connectingthe smartphone to the computer and configuring the web browser so that it uses ourproxy. Compared to previous work in this area, we do not rely on a trusted thirdparty that performs the substitution, but everything is handled by the smartphoneitself. We have implemented a fully-working prototype of our idea in a tool calledSmartProxy. The overhead is reasonable and often even unnoticeable to the useras demonstrated with our benchmarking results. Furthermore, we evaluated thesecurity implications of the setup and we are convinced that our solution is beneficialfor many users. We will now discussion several limitations of our solution and alsosketch potential future improvements to strengthen SmartProxy.

As already explained in Section 6.4.1, the smartphone may route all its traffic backto the potentially compromised computer, as this is the machine engaged as the In-ternet access point (default gateway). Clearly, this poses a security problem in casethat the web browser uses the proxy for plain HTTP websites. Because all HTTPtraffic is unencrypted, an attacker may read and alter all traffic on the compromisedcomputer. This includes all data that have been formerly replaced; or, in otherwords, the genuine credentials and cookies. The current implementation does notcheck for this scenario. However, all SSL-secured connections are not affected be-cause a MitM attack would be detected by the proxy running on the smartphone—aslong as the PKI is trustworthy. Furthermore, we could extend SmartProxy to au-tomatically “upgrade” each HTTP to a HTTPS connection whenever possible, thus

157


preventing this attack scenario. Another potential weakness is that the login proce-dure on a website could perform some kind of computation during the login processwith techniques such as JavaScript, Java, Adobe Flash, Active-X or other similartechnologies. These procedures could compute arbitrary values which are in turnsent to some unknown destinations. Currently, we do not support these setups.

Our cookie filtering approach might also cause trouble on some websites due to over-or underfiltering. We have not found any problems during our tests and evaluationbut cannot guarantee that it always works as expected. Some websites might requirethe use of the white- and blacklist feature.

As the attacker is able to interact with all the contents of a web site, she is ableto perform so called transaction generator attacks [120]. This means that she canmake all actions on behalf of the user, e. g., make orders in web stores, post messages,and so on. This cannot effectively be prevented by SmartProxy, as it cannot tellby any means which requests are legit and which are not. Jackson et al. proposesome countermeasures [120], which could be included in SmartProxy. The bestdefense SmartProxy offers for now is that the user can always see what is goingon as all requests are visible on the smartphone’s screen. The user might simplycut the connection to the proxy if something looks suspicious. In this case, theattacker might disable the usage of the proxy, but will not be able to proceed, as nocredentials and cookies are available to her.

We did not carry out a user study to see how successful people are able to set upSmartProxy. We are aware that people often have difficulties understanding whatis going on with security related problems (see for example [54]). As long as theusers remember to never input real credentials into the computer while they useSmartProxy, they can at least be assured that their credentials are safe.

The last limitation we report on is that SmartProxy is not yet really scalable.Each web browser which shall be used with the proxy has to be set up. This includesimporting the root certificate for SSL secured websites. Albeit the certificate is notcrucial if the link between the smartphone and the computer is secure—e. g., whenconnected with a USB cable—, it greatly enhances the user experience as otherwiseeach SSL secured website will enforce a certificate warning from the browser.

In the remaining of this section, we briefly discuss future work. First, there couldbe a better connectivity between a smartphone and a computer. A type of anautomatic wireless connection would be helpful, and the use could potentially bemade of the Bluetooth protocol. We did not look into this aspect because thecurrent connectivity scope was deemed sufficient for the prototype. It would beadvantageous to see some kind of “Reverse Tethering” support on Android, like theActiveSync feature that Windows Mobile offers. This could enable effortless use of

158

6.6 Discussion

the fast Internet connection of the computer. Furthermore, a guarantee of a properdetection of cases when the plain HTTP traffic is routed back to the computer onwhich the web browser runs would be essential in order to prohibit vulnerable setupsof this sort.

Additional filters could be implemented to hide content from web browsers, forexample by some type of blacklist to substitute valuable data with fake information.Examples could include names, addresses, credit card and social security numbers,and even real credentials. This would also avert “mirror attacks” where an attackerattempts to send substituted real data back to the web browser through the proxyto get hold of them. Although the attacker would need access to the web server toenable such mirroring and would already have access to the data, such an attackwould be harder for the attacker. As the filter system is pluggable, this can beimplemented rather easily but was not done for our prototype at this stage.

Last but not least, the speed of the SSL handshakes could be improved. Although itis already pretty fast for most use cases, this is undoubtedly a desirable direction ofimprovements in the future. There are some existing solutions which are known toreflect and cater to this need, but they are currently unavailable on the Android OS.One example would be what Google proposes in the instances of False Start [137],Next Protocol Negotiation [135], SPDY [19] and Snap Start [136]. These solutionsare currently tested by Google in selected applications and servers. If they provesuccessful, they will be hopefully integrated into Google’s Android.

159

7Summary and Conclusion

In this thesis we addressed several mobile security research problems and askedhow we could make our “smart” phones more secure. We introduced new tools foranalyzing Android applications, evaluated how robust such tools are against well-obfuscated software, and we discussed a prototype which leverages a smartphone inorder to enhance the security of PCs.

We now summarize our contributions per chapter and also discuss what future workcould be done in the corresponding area, as we could of course not cover all aspects.Afterwards, we give an outlook and discuss what the future might unfold with respectto mobile security.

Chapter 2: Background: From Mobile to Security. We started this thesis withan introduction of the term mobile security and what sets it apart from the wellknown research field of computer security in general. We then discussed smartphonecharacteristics and reported on specifics of their mobile operating systems. Sincethis thesis is about mobile security we quickly came to the point where we introducedthe problem of malware and also discussed possible attack vectors. After providinga summarized time line of known malware for feature phones and smartphones, wediscussed analysis techniques to counter these threats.

Chapter 3: Static Approach based on Program Slicing. After emphasizing theneed for proper and novel analysis tools for mobile applications in the previous chap-ter, we introduced in this chapter a static analysis tool for Android applications. Outtool named Saaf is able to calculate program slices and to use them in order to find

161

7 Summary and Conclusion

hardcoded information which are used as method parameters. An example wouldbe a URL for a HTTP request or the destination number of sent short messages.We successfully analyzed more than 140,000 applications of which more than 6,000were malicious. We reported on many found characteristics after analyzing such alarge corpus of data for both benign and malicious applications.

Since Saaf is a tool to statically analyze programs, it suffers from all disadvantagesthat come with it. The problem here lies in the heavy burden that well-obfuscatedprograms put onto such tools. As we have shown in the next chapter, such analyzerscan be completely hindered if the program’s code is well-obfuscated. Despite thesedrawbacks, static analyzers still provide good results if the analyzed application isnot well-protected. Saaf’s main feature is its ability to perform a technique calledprogram slicing on applications, but the implementation could be enhanced. Ourprototype does not correctly handle effects caused by polymorphism introduced byJava’s object oriented paradigm: If an overwritten method is invoked, it does notcorrectly handle this case and the called—but eventually not the overriding—methodis analyzed. Additionally, the analysis of method calls is not context-sensitive [222].Enhancing the tool will certainly lead to better analysis results, but the generaloccurring problems while analyzing obfuscated applications remain for such a staticanalysis tool.

Chapter 4: Dynamic Approach based on Power Consumption. After we haveintroduced a static analyzer in the previous chapter, we also presented a dynamicanalysis tool. Instead of dynamically analyzing mobile applications in the “usualway”, we evaluated if and how malicious mobile software can be detected based onthe consumed energy. In theory, it should be possible to detect additionally executed(malicious) behavior as each performed action consumes some amount of energy. Inthe case of smartphones this energy is provided by the battery. We made use of asophisticated tool to measure the spent energy of installed applications and whichactions drain which amount of energy from the battery. Although we were able todetect malicious activities in artificially short-time tests, we were not able to do so inlonger real-world like tests. Our evaluation with real malware samples has also notproduced desired results. Despite the evaluation of many different test scenarios,we had to conclude that the detection of (malicious) activities based on its energyfingerprint seems to be a dead end—at least for nowadays available smartphones.

Chapter 5: Change of Ends: Obfuscating Android Applications. In the previ-ous two chapters we introduced a static and a dynamic analysis tool for Androidapplications. While the first system produces good results for non-obfuscated ap-plications, we showed that it cannot cope well with obfuscated applications. Our

162

second approach was deemed as a dead end based on our evaluation. The assumptionpreviously made for feature phones to detect malware based on its energy consump-tion does not hold for modern smartphones—malware cannot reliable be detectedthat way.

Since we experienced problems with our first tool, we got curious how other analysistools perform under certain circumstances. We therefore built a tool which auto-matically obfuscates Android applications and evaluated how robust state-of-the artanalysis tools in general are. After evaluating many available tools, we came to theconclusion that many have drawbacks and cannot analyze well protected applica-tions. This situation is particular unpleasant, as malware for mobile devices quicklyadvances with respect to their functionality and code quality. Samples can still beanalyzed, but a manual analysis is often necessary for good results. Automatic onesare easily hampered with easily addable anti-analysis techniques. More robust toolsare desirable and more tools should be made available to the community. Manyresearch tools are just not published at all and maintenance often stops after theresults were published.

It is also desirable that more analysis techniques are available for mobile applicationanalyzes. Tools that support multipath execution would be very beneficial for ana-lyzing malicious software. The same is true for tools which properly support staticor dynamic instrumentation in order to (automatically) defeat the “misuse” of theJava Reflection API in malicious Android applications and obfuscation in general.Our evaluation shows that even dynamic analysis systems have problems with ob-fuscated applications. Still, two systems generated proper reports, namely MobileSandbox and TraceDroid. A combination of these two system would be beneficialin order to dynamically analyze Android applications.

Chapter 6: Enhancing Other Devices’ Security with SmartProxy. After reportingon the analysis of mobile applications, we discussed in this chapter the possibilityto enhance the security of a PC with the help of a smartphone. Our particularassumption was that someone must use an untrusted computer for browsing theweb, e. g., in the coworker’s office. We presented a prototype named SmartProxywhich runs on a smartphone and eases the user’s worries about entering credentialsinto an eventually compromised computer. The prototype also takes care that anattacker cannot get hold of other security related information, such as cookies orsession IDs. If the smartphone on which our tool runs is connected to the PC,all traffic—including encrypted connections—can be routed over the smartphoneand SmartProxy can strip out security relevant information in a way that theynever reach the PC. Additionally, the user never enters real credentials but onlyfake ones into the PC and all such data is swapped with genuine ones by our proxy.

163

7 Summary and Conclusion

Substituting private data, such as names, addresses, credit card numbers to namebut a few is also feasible in such a setup, as the proxy could also filter these out.

Leveraging the smartphone’s processing power and connectivity to enhance the se-curity of other devices is an interesting approach that could see adaption if theconnection between the smartphone and, e. g., the PC would be seamless and appli-cations would support such an approach. That way credentials could be distributedover these devices in a way that no device has all the information and an attackermust successfully gain control of both devices in order to cause harm. Our presentedprototype proved the feasibility of such an approach, but more work is required toease the setup for normal users who generally do not want to spent any time foradditional security.

Outlook

Although smartphones are very common nowadays, they will presumably becomeeven more prevalent. The same can be expected for other mobile devices withsimilar features, such as smartglasses and smartwatches. The daily use cases wherewe utilize such devices will therefore rise. Health and fitness applications are abooming segment by the time of writing and such applications are running on “smartdevices” which enable them in the first place. The amount of automatically collectedand processed data will rise and privacy issues will play a huge factor for suchapplications—even more than they should today.

Mobile security will also play a huge factor in the field of automotive security, espe-cially since vendors use the same operating systems and the car will be well connectedwith our mobile devices [124]. Cars can already be controlled to a certain extendby our smartphones, but the interdependence will most likely grow. This trend isalso visible for, e. g., TVs [124], although this development does not raise that manyconcerns.

The amount of information we likely share with corporations such as Google andApple will increase in the near future, as everything will be more connected thanever. How valuable and attractive such information are was thoroughly evaluated inChapter 2. Malware authors will for sure attempt to also get hold of such informationin order to commit illicit activities. It is therefore crucial that mobile operatingsystems provide decent security mechanisms and that program analysts have accessto usable tools in order to fight malware, which is likely not to vanish in the future.

A repetition of what we saw for Windows malware in the last decade will also beseen on mobile devices: Mobile malware will become much more sophisticated in any

164

aspect and many new samples will emerge in the future. Although many lessons havebeen learned and smartphones feature security mechanisms usually not available onPCs, fighting these threats will not be an easy task.

165

List of Figures

2.1 Google Trends data [100] for the search terms “mobile security” and“smartphone”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Monthly amount of malicious APKs for Android. . . . . . . . . . . . 172.3 Amount of known malware families. . . . . . . . . . . . . . . . . . . 34

3.1 Screenshot of Saaf. . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.2 Exemplary CFG of Saaf. . . . . . . . . . . . . . . . . . . . . . . . . 503.3 Exemplary program slice. . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1 Schematic Overview of SmartProxy. . . . . . . . . . . . . . . . . . 1416.2 Protocol sequence diagram. . . . . . . . . . . . . . . . . . . . . . . . 146

167

List of Tables

3.1 Top 10 permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.2 Top 10 system services. . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.1 Short time initial tests for a 5 minute period. Average power con-sumption for wireless connections. . . . . . . . . . . . . . . . . . . . 79

4.2 Exemplary power consumption of different apps after system start fora 5 minute interval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3 Average power consumption for different brightness levels. . . . . . . 814.4 Average power consumption for different power states. . . . . . . . . 824.5 Average power consumption for accessing the location API. . . . . . 834.6 Average power consumption for data transmission. . . . . . . . . . . 844.7 Joblist for scenario A. . . . . . . . . . . . . . . . . . . . . . . . . . . 854.8 Joblist for scenario B. . . . . . . . . . . . . . . . . . . . . . . . . . . 854.9 Long time initial tests (3 hour period). . . . . . . . . . . . . . . . . . 864.10 Exemplary power consumption of different apps (scenario A). . . . . 874.11 Average power consumption with disabled sleepmode. . . . . . . . . 874.12 Average power consumption for stealing GPS position. . . . . . . . . 884.13 Average power consumption for data transmission. . . . . . . . . . . 894.14 Battery charge level for the Galaxy Nexus after sending data and

short messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.15 Verification with malware in controlled scenarios. . . . . . . . . . . . 914.16 Power Consumption during the “all day long tests”. . . . . . . . . . . 92

5.1 Overview of app analysis tools for the Android platform. . . . . . . . 105

169

5.2 Results for dynamic analysis services. . . . . . . . . . . . . . . . . . 1175.3 Decompilation results for different test cases. . . . . . . . . . . . . . 1205.4 Contagio Minidump AV detection rates for VirusTotal. . . . . . . . . 1245.5 Contagio Minidump AV detection rates for mobile AV solutions. . . 1275.6 Artificial benchmark results. . . . . . . . . . . . . . . . . . . . . . . . 130

6.1 Micro benchmark for the target SSL handshake. . . . . . . . . . . . 1536.2 Micro benchmark for the local SSL handshake. . . . . . . . . . . . . 1536.3 Evaluation results for global Top 25 websites from alexa.com. . . . . 155

170

Listings

3.1 Sample Java code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.2 Sample smali code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.3 Patched code to circumvent copy-protection mechanisms. . . . . . . 66

5.1 Example code for indirect invokes. . . . . . . . . . . . . . . . . . . . 1115.2 Example code for indirect field and array access. . . . . . . . . . . . 1135.3 Misuse of the goto instruction, example (1). . . . . . . . . . . . . . . 1215.4 Misuse of the goto instruction, example (2). . . . . . . . . . . . . . . 1215.5 Wrong exception handler order. . . . . . . . . . . . . . . . . . . . . . 122

171

Bibliography

[1] “Allatori,” http://www.allatori.com/.

[2] “Anubis – Malware Analysis for Unknown Binaries,” https://anubis.iseclab.org/.

[3] “Bangcle App Shield,” hhttp://bangcle.com/appProtect/.

[4] “Battery Performance Characteristics,” http://www.mpoweruk.com/performance.htm.

[5] “Bitcoin,” https://bitcoin.org/.

[6] “CVE-2013-4787 – Android: Wrong cryptographic signature check,” http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4787.

[7] “CVE-2014-0160 – Heartbleed Bug,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160.

[8] “CVE-2014-1266 – Apple Goto Fail,” https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1266.

[9] “CVE Details,” http://www.cvedetails.com/.

[10] “Cyanogenmod,” http://www.cyanogenmod.org/.

[11] “DashO,” https://www.preemptive.com/products/dasho.

[12] “dex2jar,” http://code.google.com/p/dex2jar/.

173

http://www.allatori.com/

https://anubis.iseclab.org/

https://anubis.iseclab.org/

hhttp://bangcle.com/appProtect/

http://www.mpoweruk.com/performance.htm

http://www.mpoweruk.com/performance.htm

https://bitcoin.org/

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4787

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4787

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160




http://www.cvedetails.com/

http://www.cyanogenmod.org/

https://www.preemptive.com/products/dasho

http://code.google.com/p/dex2jar/

[13] “DroidBox – Android Application Sandbox,” http://code.google.com/p/droidbox/.

[14] “Litecoin,” https://litecoin.org/.

[15] “Mobile Sandbox,” http://mobilesandbox.org/.

[16] “rageagainstthecage,” https://github.com/bibanon/android-development-codex/wiki/rageagainstthecage.

[17] “SandDroid – An automatic Android application analysis sandbox,” http://sanddroid.xjtu.edu.cn/.

[18] “smali – An assembler/disassembler for Android’s dex format,” http://code.google.com/p/smali/.

[19] “SPDY,” http://www.chromium.org/spdy.

[20] 20th USENIX Security Symposium, San Francisco, CA, USA, August 8-12,2011, Proceedings. USENIX Association, 2011.

[21] Adam Hartung, “Three Smart Lessons From Facebook’s PurchaseOf WhatsApp,” http://www.forbes.com/sites/adamhartung/2014/02/24/zuckerbergs-3-smart-leadership-lessons-from-facebook-buying-whatsapp/.

[22] Aleph One, “Smashing the Stack for Fun and Profit,” Phrack Magazine, vol. 49,no. 14, 1996, http://www.phrack.org/issues.html?issue=49&id=14.

[23] N. J. AlFardan, D. J. Bernstein, K. G. Paterson, B. Poettering, and J. C. N.Schuldt, “On the Security of RC4 in TLS,” in USENIX Security, S. T. King,Ed. USENIX Association, 2013, pp. 305–320.

[24] F. E. Allen and J. Cocke, “A program data flow analysis procedure,” Commun.ACM, vol. 19, no. 3, Mar. 1976.

[25] Amazon.com, “Amazon Appstore for Android,” http://www.amazon.com/mobile-apps/b?node=2350149011.

[26] S. Anand and M. J. Harrold, “Heap cloning: Enabling dynamic symbolicexecution of java programs,” in ASE, 2011, pp. 33–42.

[27] S. Anand, M. Naik, M. J. Harrold, and H. Yang, “Automated concolic testingof smartphone apps,” in SIGSOFT FSE, 2012, p. 59.

[28] Android Developers, “Platform Versions,” June 2014, http://developer.android.com/resources/dashboard/platform-versions.html.

[29] Apple, “App Review,” https://developer.apple.com/app-store/review/.

174

http://code.google.com/p/droidbox/

http://code.google.com/p/droidbox/

https://litecoin.org/

http://mobilesandbox.org/

https://github.com/bibanon/android-development-codex/wiki/rageagainstthecage

https://github.com/bibanon/android-development-codex/wiki/rageagainstthecage

http://sanddroid.xjtu.edu.cn/

http://sanddroid.xjtu.edu.cn/

http://code.google.com/p/smali/

http://code.google.com/p/smali/

http://www.chromium.org/spdy

http://www.forbes.com/sites/adamhartung/2014/02/24/zuckerbergs-3-smart-leadership-lessons-from-facebook-buying-whatsapp/

http://www.forbes.com/sites/adamhartung/2014/02/24/zuckerbergs-3-smart-leadership-lessons-from-facebook-buying-whatsapp/

http://www.phrack.org/issues.html?issue=49&id=14

http://www.amazon.com/mobile-apps/b?node=2350149011

http://www.amazon.com/mobile-apps/b?node=2350149011

http://developer.android.com/resources/dashboard/platform-versions.html

http://developer.android.com/resources/dashboard/platform-versions.html

https://developer.apple.com/app-store/review/

[30] ——, “iOS,” https://www.apple.com/ios/.

[31] A. J. Aviv, K. Gibson, E. Mossop, M. Blaze, and J. M. Smith, “Smudgeattacks on smartphone touch screens,” in WOOT, C. Miller and H. Shacham,Eds. USENIX Association, 2010.

[32] N. Balasubramanian, A. Balasubramanian, and A. Venkataramani, “EnergyConsumption in Mobile Phones: A Measurement Study and Implications forNetwork Applications,” in Internet Measurement Conference (IMC), 2009.[Online]. Available: http://doi.acm.org/10.1145/1644893.1644927

[33] D. Balfanz and E. W. Felten, “Hand-Held Computers Can Be Better SmartCards,” in USENIX Security Symposium, 1999.

[34] I. Baliç and B. Baliç, “Android Sandbox – Automated Malware Analysis,”http://androidsandbox.net/.

[35] E. Barkan, E. Biham, and N. Keller, “Instant ciphertext-only cryptanalysisof gsm encrypted communication,” J. Cryptology, vol. 21, no. 3, pp. 392–429,2008.

[36] A. Bartel, J. Klein, Y. Le Traon, and M. Monperrus, “Automatically securingpermission-based software by reducing the attack surface: An application toAndroid,” in Proceedings of the 27th IEEE/ACM International Conference onAutomated Software Engineering, ser. ASE 2012. ACM, 2012, pp. 274–277.

[37] M. Becher, “Security of Smartphones at the Dawn of Their Ubiquitousness,”Ph.D. dissertation, University of Mannheim, Germany, 2009.

[38] M. Becher, F. C. Freiling, J. Hoffmann, T. Holz, S. Uellenbeck, andC. Wolf, “Mobile Security Catching Up? Revealing the Nuts and Boltsof the Security of Mobile Devices,” in Security and Privacy (SP), 2011IEEE Symposium on. IEEE, May 2011, pp. 96–111. [Online]. Available:http://dx.doi.org/10.1109/SP.2011.29

[39] J. Berka, “Turbo SIM add-on allows full iPhoneunlocking,” http://arstechnica.com/apple/2007/08/turbo-sim-add-on-allows-full-iphone-unlocking/.

[40] BlackBerry Ltd, “Blackberry,” http://us.blackberry.com/.

[41] A. Bogdanov, T. Eisenbarth, and A. Rupp, “A hardware-assisted realtimeattack on a5/2 without precomputations,” in CHES, ser. Lecture Notes inComputer Science, P. Paillier and I. Verbauwhede, Eds., vol. 4727. Springer,2007, pp. 394–412.

175

https://www.apple.com/ios/

http://doi.acm.org/10.1145/1644893.1644927

http://androidsandbox.net/

http://dx.doi.org/10.1109/SP.2011.29

http://arstechnica.com/apple/2007/08/turbo-sim-add-on-allows-full-iphone-unlocking/

http://arstechnica.com/apple/2007/08/turbo-sim-add-on-allows-full-iphone-unlocking/

http://us.blackberry.com/

[42] B. Bosschert, “Steal WhatsApp database (PoC),” http://bas.bosschert.nl/steal-whatsapp-database/.

[43] M. Breeuwsma, M. D. Jongh, C. Klaver, R. V. D. Knijff, and M. Roeloffs,“Forensic Data Recovery from Flash Memory,” Small Scale Digital DeviceForensic Journal, vol. 1, no. 1, 2007.

[44] J. Brodkin, “Kim Dotcom: Megaupload data in Europe wipedout by hosting company,” http://arstechnica.com/tech-policy/2013/06/kim-dotcom-megaupload-data-in-europe-wiped-out-by-hosting- company/ .

[45] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Flexible and fine-grained mandatoryaccess control on android for diverse security and privacy policies,” in USENIXSecurity, S. T. King, Ed. USENIX Association, 2013, pp. 131–146.

[46] bunnie and xobs, “On Hacking MicroSD Cards,” http://www.bunniestudios.com/blog/?p=3554.

[47] M. Burnside, D. Clarke, B. Gassend, T. Kotwal, M. van Dijk, S. Devadas, andR. Rivest, “The untrusted computer problem and camera-based authentica-tion,” in In Pervasive Computing, volume 2414 of LNCS. Springer-Verlag,2002, pp. 114–124.

[48] C. Drew (The New York Times), “Stolen Data Is Tracked to Hacking at Lock-heed,” http://www.nytimes.com/2011/06/04/technology/04security.html.

[49] Canonical Ltd., “Ubuntu Touch,” http://www.ubuntu.com/phone.

[50] C. A. Castillo, “Android Malware Past, Present, and Future(McAfee White Paper),” www.mcafee.com/us/resources/white-papers/wp-android-malware-past-present-future.pdf.

[51] P. P. Chan, L. C. Hui, and S. M. Yiu, “DroidChecker: Analyzing Androidapplications for capability leak,” in Proceedings of the Fifth ACM Conferenceon Security and Privacy in Wireless and Mobile Networks, ser. WISEC ’12.ACM, 2012, pp. 125–136.

[52] K. Chen, N. Johnson, V. D’Silva, K. MacNamara, T. Magrino, E. Wu, M. Ri-nard, and D. Song, “Contextual policy enforcement for Android applicationswith permission event graphs,” in Proceedings of the 20th Network and Dis-tributed System Security Symposium, ser. NDSS. Internet Society, 2013.

[53] Y. Chen, G. Danezis, and V. Shmatikov, Eds., Proceedings of the 18th ACMConference on Computer and Communications Security, CCS 2011, Chicago,Illinois, USA, October 17-21, 2011. ACM, 2011.

176

http://bas.bosschert.nl/steal-whatsapp-database/

http://bas.bosschert.nl/steal-whatsapp-database/

http://arstechnica.com/tech-policy/2013/06/kim-dotcom-megaupload-data-in-europe-wiped-out-by-hosting-company/

http://arstechnica.com/tech-policy/2013/06/kim-dotcom-megaupload-data-in-europe-wiped-out-by-hosting-company/

http://www.bunniestudios.com/blog/?p=3554

http://www.bunniestudios.com/blog/?p=3554

http://www.nytimes.com/2011/06/04/technology/04security.html

http://www.ubuntu.com/phone

www.mcafee.com/us/resources/white-papers/wp-android-malware-past-present-future.pdf

www.mcafee.com/us/resources/white-papers/wp-android-malware-past-present-future.pdf

[54] S. Chiasson, P. C. van Oorschot, and R. Biddle, “A usability study and critiqueof two password managers,” in USENIX Security Symposium, 2006.

[55] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner, “Analyzing inter-application communication in Android,” in Proceedings of the 9th InternationalConference on Mobile Systems, Applications, and Services, ser. MobiSys ’11.ACM, 2011, pp. 239–252.

[56] V. Chipounov, V. Kuznetsov, and G. Candea, “S2E: a platform for in-vivomulti-path analysis of software systems,” in ASPLOS, R. Gupta and T. C.Mowry, Eds. ACM, 2011, pp. 265–278.

[57] C. Collberg, “SandMark: A Tool for the Study of Software Protection Algo-rithms,” http://sandmark.cs.arizona.edu/index.html.

[58] C. Collberg, C. Thomborson, and D. Low, “A Taxonomy of Obfuscating Trans-formations,” Tech. Rep., 1997.

[59] Comodo Group, “Incident Report,” https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html.

[60] D. Dagon et al., “Mobile Phones as Computing Devices: The Viruses areComing!” IEEE Pervasive Computing, vol. 3, no. 4, 2004.

[61] C. Dall, J. Andrus, A. V. Hof, O. Laadan, and J. Nieh, “The Design, Im-plementation, and Evaluation of Cells: A Virtual Smartphone Architecture,”ACM Trans. Comput. Syst., vol. 30, no. 3, p. 9, 2012.

[62] A. Desnos and G. Gueguen, “Android: From reversing to decompilation,” InProc. of Black Hat Abu Dhabi, 2011.

[63] dev team, “redsn0w – iOS Jailbreak,” http://blog.iphone-dev.org/tagged/redsn0w.

[64] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Wallach, “Quire:Lightweight provenance for smart phone operating systems,” in USENIX Se-curity Symposium. USENIX Association, 2011.

[65] B. Dixon, Y. Jiang, A. Jaiantilal, and S. Mishra, “Location based poweranalysis to detect malicious code in smartphones,” in ACM Workshop onSecurity and Privacy in Smartphones and Mobile Devices, ser. SPSM, 2011.[Online]. Available: http://doi.acm.org/10.1145/2046614.2046620

[66] B. Dodson, D. Sengupta, D. Boneh, and M. S. Lam, “Secure, Consumer-Friendly Web Authentication and Payments with a Phone,” in Proceedingsof the Second International ICST Conference on Mobile Computing, Applica-tions, and Services (MobiCASE), 2010.

177

http://sandmark.cs.arizona.edu/index.html

https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html

https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html

http://blog.iphone-dev.org/tagged/redsn0w

http://blog.iphone-dev.org/tagged/redsn0w

http://doi.acm.org/10.1145/2046614.2046620

[67] M. Dong and L. Zhong, “Self-Constructive High-Rate System EnergyModeling for Battery-Powered Mobile Systems,” in International Conferenceon Mobile Systems, Applications, and Services, ser. MobiSys, 2011. [Online].Available: http://doi.acm.org/10.1145/1999995.2000027

[68] C. Dougherty and G. Huang, “Mt. Gox Seeks Bankruptcy After$480 Million Bitcoin Loss,” http://www.bloomberg.com/news/2014-02-28/mt-gox-exchange-files-for-bankruptcy.html.

[69] B. Driessen, R. Hund, C. Willems, C. Paar, and T. Holz, “Don’t trust satellitephones: A security analysis of two satphone standards,” in IEEE Symposiumon Security and Privacy. IEEE Computer Society, 2012, pp. 128–142.

[70] M. Egele, C. Kruegel, E. Kirda, and G. Vigna, “PiOS: Detecting Privacy Leaksin iOS Applications,” in Network and Distributed System Security Symposium(NDSS), 2011.

[71] M. Egele, T. Scholte, E. Kirda, and C. Kruegel, “A survey on automateddynamic malware-analysis techniques and tools,” ACM Comput. Surv., vol. 44,no. 2, p. 6, 2012.

[72] K. O. Elish, D. Yao, and B. G. Ryder, “User-Centric Dependence Analy-sis For Identifying Malicious Mobile Apps,” in Workshop on Mobile SecurityTechnologies, 2012.

[73] EMC Corporation, “RSA SecurID,” http://www.rsa.com/node.aspx?id=1156.

[74] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri, “A Study of AndroidApplication Security,” in USENIX Security Symposium, 2011.

[75] W. Enck, “Defending users against smartphone apps: Techniques and futuredirections,” in 7th International Conference on Information Systems Security(ICISS). Springer, 2011, pp. 49–70.

[76] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, andA. Sheth, “TaintDroid: An Information-Flow Tracking System for RealtimePrivacy Monitoring on Smartphones,” in OSDI, R. H. Arpaci-Dusseau andB. Chen, Eds. USENIX Association, 2010, pp. 393–407.

[77] evad3rs, “evasi0n7 – iOS 7.0.x Jailbreak,” http://evasi0n.com/.

[78] H. Falaki, R. Mahajan, S. Kandula, D. Lymberopoulos, R. Govindan, andD. Estrin, “Diversity in smartphone usage,” in International Conference onMobile Systems, Applications and Services, ser. MobiSys, 2010. [Online].Available: http://doi.acm.org/10.1145/1814433.1814453

178

http://doi.acm.org/10.1145/1999995.2000027

http://www.bloomberg.com/news/2014-02-28/mt-gox-exchange-files-for-bankruptcy.html

http://www.bloomberg.com/news/2014-02-28/mt-gox-exchange-files-for-bankruptcy.html

http://www.rsa.com/node.aspx?id=1156

http://evasi0n.com/

http://doi.acm.org/10.1145/1814433.1814453

[79] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner, “Android Permis-sions Demystified,” in ACM Conference on Computer and CommunicationsSecurity, 2011.

[80] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, “A survey of mobilemalware in the wild,” in SPSM@CCS, X. Jiang, A. Bhattacharya, P. Dasgupta,and W. Enck, Eds. ACM, 2011, pp. 3–14.

[81] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D. Wagner, “Androidpermissions: user attention, comprehension, and behavior,” in SOUPS, L. F.Cranor, Ed. ACM, 2012, p. 3.

[82] A. P. Felt, H. J. Wang, A. Moshchuk, S. Hanna, and E. Chin, “Permis-sion Re-Delegation: Attacks and Defenses,” in USENIX Security Symposium.USENIX Association, 2011.

[83] U. Flegel, J. Hoffmann, and M. Meier, “Cooperation enablement for centralis-tic early warning systems,” in SAC, S. Y. Shin, S. Ossowski, M. Schumacher,M. J. Palakal, and C.-C. Hung, Eds. ACM, 2010, pp. 2001–2008.

[84] U. Flegel, E. P. Markatos, and W. Robertson, Eds., Detection of Intrusionsand Malware, and Vulnerability Assessment - 9th International Conference,DIMVA 2012, Heraklion, Crete, Greece, July 26-27, 2012, Revised SelectedPapers, ser. Lecture Notes in Computer Science, vol. 7591. Springer, 2013.

[85] D. A. F. Florêncio and C. Herley, “A large-scale study of web password habits,”in WWW, C. L. Williamson, M. E. Zurko, P. F. Patel-Schneider, and P. J.Shenoy, Eds. ACM, 2007, pp. 657–666.

[86] ForeSafe, “ForeSafe Online Scanner,” http://www.foresafe.com/scan.

[87] L. D. Fosdick and L. J. Osterweil, “Data flow analysis in software reliability,”ACM Comput. Surv., vol. 8, no. 3, Sep. 1976.

[88] J. Franklin, A. Perrig, V. Paxson, and S. Savage, “An inquiry into the na-ture and causes of the wealth of internet miscreants,” in ACM Conference onComputer and Communications Security (CCS), 2007.

[89] C. Fritz, S. Arzt, S. Rasthofer, E. Bodden, A. Bartel, J. Klein, Y. le Traon,D. Octeau, and P. McDaniel, “Highly precise taint analysis for Android appli-cations,” TU Darmstadt, Tech. Rep. EC SPRIDE Technical Report TUD-CS-2013-0113, 2013.

179

http://www.foresafe.com/scan

[90] A. P. Fuchs, A. Chaudhuri, and J. S. Foster, “SCanDroid: Automated secu-rity certification of Android applications,” Department of Computer Science,University of Maryland, College Park, Tech. Rep. CS-TR-4991, Nov. 2009,https://www.cs.umd.edu/~avik/papers/scandroidascaa.pdf.

[91] E. Gabber, P. B. Gibbons, Y. Matias, and A. Mayer, “How to Make Person-alized Web Browsing Simple, Secure, and Anonymous,” in Financial Cryptog-raphy and Data Security (FC), 1998.

[92] Gartner, “Gartner Says Annual Smartphone Sales Surpassed Sales of FeaturePhones for the First Time in 2013,” http://www.gartner.com/newsroom/id/2665715.

[93] ——, “Gartner Says Worldwide Traditional PC, Tablet, Ultramobile and Mo-bile Phone Shipments On Pace to Grow 7.6 Percent in 2014,” http://www.gartner.com/newsroom/id/2645115.

[94] H. Gascon, S. Uellenbeck, C. Wolf, and K. Rieck, “Continuous Authenticationon Mobile Devices by Analysis of Typing Motion Behavior,” in Sicherheit, ser.LNI, S. Katzenbeisser, V. Lotz, and E. R. Weippl, Eds., vol. 228. GI, 2014,pp. 1–12.

[95] gera, “Advances in Format String Exploitation,” Phrack Magazine, vol. 59,no. 12, 2002. [Online]. Available: http://www.phrack.com/issues.html?issue=59&id=7

[96] C. Gibler, J. Crussell, J. Erickson, and H. Chen, “AndroidLeaks: Automati-cally Detecting Potential Privacy Leaks in Android Applications on a LargeScale,” Trust and Trustworthy Computing, June 2012.

[97] A. Gingrich, “The Mother Of All Android Malware Has Arrived:Stolen Apps Released To The Market That Root Your Phone, StealYour Data, And Open Backdoor,” http://www.androidpolice.com/2011/03/01/the-mother-of-all-android-malware-has-arrived-stolen-apps-released-to-the-market-that-root-your-phone-steal-your-data-and-open-backdoor/ .

[98] Google, “Android OS,” http://www.android.com/.

[99] ——, “Android, the world’s most popular mobile platform,” http://developer.android.com/about/index.html.

[100] ——, “Google Trends,” http://www.google.com/trends/.

[101] ——, “VirusTotal,” https://www.virustotal.com/.

180

https://www.cs.umd.edu/~avik/papers/scandroidascaa.pdf

http://www.gartner.com/newsroom/id/2665715




http://www.phrack.com/issues.html?issue=59&id=7

http://www.phrack.com/issues.html?issue=59&id=7

http://www.androidpolice.com/2011/03/01/the-mother-of-all-android-malware-has-arrived-stolen-apps-released-to-the-market-that-root-your-phone-steal-your-data-and-open-backdoor/




http://www.android.com/

http://developer.android.com/about/index.html

http://developer.android.com/about/index.html

http://www.google.com/trends/

https://www.virustotal.com/

[102] M. Grace, W. Zhou, X. Jiang, and A.-R. Sadeghi, “Unsafe exposure analysis ofmobile in-app advertisements,” in WISEC, M. Krunz, L. Lazos, R. D. Pietro,and W. Trappe, Eds. ACM, 2012, pp. 101–112.

[103] M. Grace, Y. Zhou, Z. Wang, and X. Jiang, “Systematic detection of capa-bility leaks in stock Android smartphones,” in Proceedings of the 19th AnnualNetwork and Distributed System Security Symposium, ser. NDSS ’12. InternetSociety, 2012.

[104] M. Grace, Y. Zhou, Q. Zhang, S. Zou, and X. Jiang, “RiskRanker: Scalable andAccurate Zero-day Android Malware Detection,” in International Conferenceon Mobile Systems, Applications, and Services, ser. MobiSys, 2012.

[105] G. Greenwald, E. MacAskill, and L. Poitras, “Edward Snowden: the whistle-blower behind the NSA surveillance revelations,” http://www.theguardian.com/world/2013/jun/09/edward-snowden-nsa-whistleblower-surveillance.

[106] J. A. Halderman, S. D. Schoen, N. Heninger, W. Clarkson, W. Paul, J. A. Ca-landrino, A. J. Feldman, J. Appelbaum, and E. W. Felten, “Lest we remember:Cold boot attacks on encryption keys,” in USENIX Security Symposium, P. C.van Oorschot, Ed. USENIX Association, 2008, pp. 45–60.

[107] S. Hallsteinsen, I. Jorstad, and D. Van Thanh, “Using the mobile phone asa security token for unified authentication,” in Proceedings of the Second In-ternational Conference on Systems and Networks Communications (ICSNC),2007.

[108] W. Henecka, A. May, and A. Meurer, “Correcting Errors in RSA PrivateKeys,” in Advances in Cryptology (CRYPTO), 2010.

[109] D. Hernie, “Windows Phone 8 Security deep dive,” https://www.msec.be/mobcom/ws2013/presentations/david_hernie.pdf.

[110] J. Hoffmann, S. Neumann, and T. Holz, “Mobile Malware Detection Based onEnergy Fingerprints - A Dead End?” in RAID, ser. Lecture Notes in ComputerScience, S. J. Stolfo, A. Stavrou, and C. V. Wright, Eds., vol. 8145. Springer,2013, pp. 348–368.

[111] J. Hoffmann, S. Uellenbeck, and T. Holz, “SmartProxy: Secure Smartphone-Assisted Login on Compromised Machines,” in DIMVA, ser. Lecture Notes inComputer Science, U. Flegel, E. P. Markatos, and W. Robertson, Eds., vol.7591. Springer, 2012, pp. 184–203.

[112] J. Hoffmann, M. Ussath, T. Holz, and M. Spreitzenbarth, “Slicing Droids:Program Slicing for Smali Code,” in SAC, S. Y. Shin and J. C. Maldonado,Eds. ACM, 2013, pp. 1844–1851.

181

http://www.theguardian.com/world/2013/jun/09/edward-snowden-nsa-whistleblower-surveillance

http://www.theguardian.com/world/2013/jun/09/edward-snowden-nsa-whistleblower-surveillance

https://www.msec.be/mobcom/ws2013/presentations/david_hernie.pdf

https://www.msec.be/mobcom/ws2013/presentations/david_hernie.pdf

[113] T. Holz, M. Engelberth, and F. C. Freiling, “Learning more about the un-derground economy: A case-study of keyloggers and dropzones,” in EuropeanSymposium on Research in Computer Security (ESORICS), 2009.

[114] M. Honan, “Apple unveils iPhone,” Jan 2007, http://www.macworld.com/article/1054769/iphone.html.

[115] P. Hornyack, S. Han, J. Jung, S. E. Schechter, and D. Wetherall, “These aren’tthe droids you’re looking for: retrofitting android to protect data from impe-rious applications,” in ACM Conference on Computer and CommunicationsSecurity, Y. Chen, G. Danezis, and V. Shmatikov, Eds. ACM, 2011, pp.639–652.

[116] D. Y. Huang, H. Dharmdasani, S. Meiklejohn, V. Dave, C. Grier, D. McCoy,S. Savage, N. Weaver, A. C. Snoeren, and K. Levchenko, “Botcoin: Monetiz-ing Stolen Cycles,” in 21th Annual Network and Distributed System SecuritySymposium (NDSS), 2014.

[117] H. Huang, S. Zhu, P. Liu, and D. Wu, “A framework for evaluating mobile apprepackaging detection algorithms,” in TRUST. Springer, 2013, pp. 169–186.

[118] International Organization for Standardization, “ISO/IEC 7498-1:1994,” http://www.iso.org/iso/catalogue_detail.htm?csnumber=20269.

[119] J. Freeman (saurik), “Cydia,” http://cydia.saurik.com/.

[120] C. Jackson, D. Boneh, and J. Mitchell, “Transaction generators: root kits forweb,” in USENIX Workshop on Hot Topics in Security (HotSec), 2007.

[121] R. C. Jammalamadaka, T. W. van der Horst, S. Mehrotra, K. E. Seamons,and N. Venkasubramanian, “Delegate: A Proxy Based Architecture for SecureWebsite Access from an Untrusted Machine,” in Annual Computer SecurityApplications Conference (ACSAC), 2006.

[122] J. Jeon, K. K. Micinski, and J. S. Foster, “SymDroid: Symbolic Execution forDalvik Bytecode,” Department of Computer Science, University of Maryland,College Park, Tech. Rep., 2012.

[123] A. Jindal, A. Pathak, Y. C. Hu, and S. P. Midkiff, “Hypnos: Understandingand Treating Sleep Conflicts in Smartphones.” in EuroSys, 2013, pp. 253–266.

[124] Josie Ensor, “The Telegraph: Google I/O 2014:Google reveals Android for cars, TVs and watches,” http://www.telegraph.co.uk/technology/google/10926554/Google-IO-2014-Google-reveals-Android-for-cars-TVs-and-watches.htmll.

182

http://www.macworld.com/article/1054769/iphone.html

http://www.macworld.com/article/1054769/iphone.html

http://www.iso.org/iso/catalogue_detail.htm?csnumber=20269

http://www.iso.org/iso/catalogue_detail.htm?csnumber=20269

http://cydia.saurik.com/

http://www.telegraph.co.uk/technology/google/10926554/Google-IO-2014-Google-reveals-Android-for-cars-TVs-and-watches.htmll

http://www.telegraph.co.uk/technology/google/10926554/Google-IO-2014-Google-reveals-Android-for-cars-TVs-and-watches.htmll

[125] B. Kaliski, “PKCS #5: Password-Based Cryptography Specification Version2.0,” 2000, http://tools.ietf.org/html/rfc2898.

[126] H. Kim, J. Smith, and K. G. Shin, “Detecting Energy-Greedy Anomalies andMobile Malware Variants,” in International Conference on Mobile Systems,Applications and Services, ser. MobiSys, 2008.

[127] J. Kim, Y. Yoon, and K. Yi, “ScanDal: Static Analyzer for Detecting PrivacyLeaks in Android Applications,” Workshop on Mobile Security Technologies(MoST), 2012.

[128] J. King, A. Lampinen, and A. Smolen, “Privacy: Is There An App For That?”Symposium On Usable Privacy and Security, 2011.

[129] S. T. King, Ed., Proceedings of the 22th USENIX Security Symposium, Wash-ington, DC, USA, August 14-16, 2013. USENIX Association, 2013.

[130] J. Kleinberg, “The Wireless Epidemic,” Nature, vol. 449, no. 20, 2007.

[131] W. Klieber, L. Flynn, A. Bhosale, L. Jia, and L. Bauer, “Android taint flowanalysis for app sets,” in Proceedings of the 3rd ACM SIGPLAN InternationalWorkshop on the State of the Art in Java Program Analysis, ser. SOAP ’14.ACM, 2014, pp. 1–6.

[132] C. Kolbitsch, E. Kirda, and C. Kruegel, “The power of procrastination: de-tection and mitigation of execution-stalling malicious code,” in ACM Confer-ence on Computer and Communications Security, Y. Chen, G. Danezis, andV. Shmatikov, Eds. ACM, 2011, pp. 285–296.

[133] M. Kührer, J. Hoffmann, and T. Holz, “CloudSylla: Detecting SuspiciousSystem Calls in the Cloud,” Stabilization, Safety, and Security of DistributedSystems – 16th International Symposium, SSS 2014, Paderborn, Germany,September 2014.

[134] E. Lafortune, “ProGuard,” http://proguard.sourceforge.net/.

[135] A. Langley, “Transport Layer Security (TLS) Next Protocol Negotiation Ex-tension,” 2010.

[136] ——, “Transport Layer Security (TLS) Snap Start,” 2010, http://tools.ietf.org/html/draft-agl-tls-snapstart-00.

[137] A. Langley, N. Modadugu, and B. Moeller, “Transport LayerSecurity (TLS) False Start,” 2010, https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00.

183

http://tools.ietf.org/html/rfc2898

http://proguard.sourceforge.net/

http://tools.ietf.org/html/draft-agl-tls-snapstart-00

http://tools.ietf.org/html/draft-agl-tls-snapstart-00

https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

[138] B. Lau, Y. Jang, C. Song, T. Wang, P. H. Chung, and P. Royal, “MACTANS:Injecting Malware into iOS Devices via Malicious Chargers,” Blackhat, 2013.

[139] N. Leavitt, “Malicious Code Moves to Mobile Devices,” IEEE Computer,vol. 33, no. 12, 2000.

[140] ——, “Mobile Phones: The Next Frontier for Hackers?” IEEE Computer,vol. 38, no. 4, 2005.

[141] L. Li, A. Bartel, J. Klein, Y. L. Traon, S. Arzt, S. Rasthofer, E. Bodden,D. Octeau, and P. McDaniel, “I know what leaked in your pocket: uncoveringprivacy leaks on android apps with static taint analysis,” CoRR, vol.abs/1404.7431, 2014. [Online]. Available: http://arxiv.org/abs/1404.7431

[142] S. Liang, M. Might, and D. V. Horn, “Anadroid: Malware analysis of androidwith user-supplied predicates,” CoRR, vol. abs/1311.4198, 2013.

[143] Licel LLC, “DexProtector – Cutting edge obfuscator for Android apps,” http://dexprotector.com/.

[144] L. Liu, G. Yan, X. Zhang, and S. Chen, “VirusMeter: PreventingYour Cellphone from Spies,” in International Symposium on RecentAdvances in Intrusion Detection, ser. RAID, 2009. [Online]. Available:http://dx.doi.org/10.1007/978-3-642-04342-0_13

[145] H. Lockheimer, “Android and Security,” http://googlemobile.blogspot.de/2012/02/android-and-security.html.

[146] Lookout, “Lookout Projects Lost and Stolen Phones Could CostU.S. Consumers Over $30 Billion in 2012,” https://www.lookout.com/news-mobile-security/lookout-lost-phones-30-billion.

[147] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang, “CHEX: Statically vetting Androidapps for component hijacking vulnerabilities,” in Proceedings of the 19th ACMConference on Computer and Communications Security, ser. CCS ’12. ACM,2012, pp. 229–240.

[148] Y. Lu, W. Meier, and S. Vaudenay, “The Conditional Correlation Attack: APractical Attack on Bluetooth Encryption,” in CRYPTO, ser. Lecture Notesin Computer Science, V. Shoup, Ed., vol. 3621. Springer, 2005, pp. 97–117.

[149] F. Maggi, A. Valdi, and S. Zanero, “AndroTotal: A Flexible, Scalable Toolboxand Service for Testing Mobile Malware Detectors,” in Proceedings of the 3rdAnnual ACM CCS Workshop on Security and Privacy in Smartphones andMobile Devices (SPSM), November 2013.

184

http://arxiv.org/abs/1404.7431

http://dexprotector.com/

http://dexprotector.com/

http://dx.doi.org/10.1007/978-3-642-04342-0_13

http://googlemobile.blogspot.de/2012/02/android-and-security.html

http://googlemobile.blogspot.de/2012/02/android-and-security.html

https://www.lookout.com/news-mobile-security/lookout-lost-phones-30-billion

https://www.lookout.com/news-mobile-security/lookout-lost-phones-30-billion

[150] M. Mannan and P. C. Van Oorschot, “Using a Personal Device to StrengthenPassword Authentication From an Untrusted Computer,” in Financial Cryp-tography and Data Security (FC), 2007.

[151] D. Maslennikov, “ZeuS-in-the-Mobile – Facts and Theories,” http://www.securelist.com/en/analysis/204792194/ZeuS_in_the_Mobile_Facts_and_Theories#8.

[152] J. Mayer and P. Mutchler, “MetaPhone: The Sensitiv-ity of Telephone Metadata,” http://webpolicy.org/2014/03/12/metaphone-the-sensitivity-of-telephone-metadata/.

[153] McAfee, “Potentially Unwanted Programs (White Paper),” http://code.google.com/p/dex2jar/.

[154] U. Meyer and S. Wetzel, “On the impact of GSM encryption and man-in-the-middle attacks on the security of interoperating GSM/UMTS networks,” inPIMRC. IEEE, 2004, pp. 2876–2883.

[155] Microsoft, “Windows Phone,” http://www.windowsphone.com/.

[156] Mila, “contagio mobile – mobile malware mini dump,” http://contagiominidump.blogspot.de/.

[157] K. D. Mitnick and W. L. Simon, The Art of Deception: Controlling the HumanElement of Security. Wiley, 2003.

[158] R. Mogull, “The iPhone 5s fingerprint reader: what youneed to know,” http://www.macworld.com/article/2048514/the-iphone-5s-fingerprint-reader-what-you-need-to-know.html.

[159] A. Moser, C. Kruegel, and E. Kirda, “Limits of Static Analysis for MalwareDetection,” in Annual Computer Security Applications Conference (ACSAC),Dec. 2007.

[160] A. Moser, C. Krügel, and E. Kirda, “Exploring Multiple Execution Paths forMalware Analysis,” in IEEE Symposium on Security and Privacy. IEEEComputer Society, 2007, pp. 231–245.

[161] Mozilla, “Firefox OS,” http://www.mozilla.org/en-US/firefox/os/.

[162] C. Mullaney, “A Million-Dollar Mobile Botnet,” Feb. 2012, http://www.symantec.com/connect/blogs/androidbmaster-million-dollar-mobile-botnet.

185

http://www.securelist.com/en/analysis/204792194/ZeuS_in_the_Mobile_Facts_and_Theories#8



http://webpolicy.org/2014/03/12/metaphone-the-sensitivity-of-telephone-metadata/

http://webpolicy.org/2014/03/12/metaphone-the-sensitivity-of-telephone-metadata/



http://www.windowsphone.com/

http://contagiominidump.blogspot.de/

http://contagiominidump.blogspot.de/

http://www.macworld.com/article/2048514/the-iphone-5s-fingerprint-reader-what-you-need-to-know.html

http://www.macworld.com/article/2048514/the-iphone-5s-fingerprint-reader-what-you-need-to-know.html

http://www.mozilla.org/en-US/firefox/os/

http://www.symantec.com/connect/blogs/androidbmaster-million-dollar-mobile-botnet

http://www.symantec.com/connect/blogs/androidbmaster-million-dollar-mobile-botnet

[163] T. Müller and M. Spreitzenbarth, “FROST – Forensic Recovery of ScrambledTelephones,” in ACNS, ser. Lecture Notes in Computer Science, M. J. J. Jr.,M. E. Locasto, P. Mohassel, and R. Safavi-Naini, Eds., vol. 7954. Springer,2013, pp. 373–388.

[164] MWR Labs, “Adventures with Android WebViews,” https://labs.mwrinfosecurity.com/blog/2012/04/23/adventures-with-android-webviews/.

[165] Nergal, “The Advanced return-into-lib(c) Exploits: PaX Case Study,”Phrack Magazine, vol. 58, no. 4, 2001. [Online]. Available: http://www.phrack.org/issues.html?issue=58&id=4#article

[166] S. Neuner, V. V. der Veen, M. Lindorfer, M. Huber, G. Merzdovnik, M. Mu-lazzani, and E. R. Weippl, “Enter sandbox: Android sandbox comparison,”in Proceedings of the IEEE Mobile Security Technologies Workshop (MoST).IEEE, 2014.

[167] F. Nielson, H. R. Nielson, and C. Hankin, Principles of Program Analysis.Springer, 2010.

[168] NVISO, “NVISO ApkScan – Scan Android applications for malware,” http://apkscan.nviso.be/.

[169] J. Oberheide, “Remote Kill and Install on Google Android,” https://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/.

[170] J. Oberheide and F. Jahanian, “When Mobile is Harder Than Fixed (and ViceVersa): Demystifying Security Challenges in Mobile Environments,” in Work-shop on Mobile Computing Systems and Applications (HotMobile), February2010.

[171] D. Octeau, W. Enck, and P. McDaniel, “The ded Decompiler,” Networkingand Security Research Center, Pennsylvania State University, Tech. Rep. NAS-TR-0140-2010, Sep. 2010.

[172] D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden, J. Klein, andY. Le Traon, “Effective inter-component communication mapping in Androidwith Epicc: An essential step towards holistic security analysis,” in Proceedingsof the 22nd USENIX Security Symposium, ser. SEC’13. USENIX Association,2013, pp. 543–558.

[173] M. Ongtang, S. E. McLaughlin, W. Enck, and P. D. McDaniel, “Semanticallyrich application-centric security in android,” in ACSAC. IEEE ComputerSociety, 2009, pp. 340–349.

186

https://labs.mwrinfosecurity.com/blog/2012/04/23/adventures-with-android-webviews/

https://labs.mwrinfosecurity.com/blog/2012/04/23/adventures-with-android-webviews/

http://www.phrack.org/issues.html?issue=58&id=4#article

http://www.phrack.org/issues.html?issue=58&id=4#article

http://apkscan.nviso.be/

http://apkscan.nviso.be/

https://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/

https://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/

[174] Open Handset Alliance, “Industry Leaders Announce Open Platform for Mo-bile Devices (Press Release),” 2007, http://www.openhandsetalliance.com/press_110507.html.

[175] S. Ortolani, “Android 4.3 and SELinux,” http://www.securelist.com/en/blog/9175/Android_4_3_and_SELinux.

[176] D. Oswald, B. Richter, and C. Paar, “Side-Channel Attacks on the Yubikey2 One-Time Password Generator,” in RAID, ser. Lecture Notes in ComputerScience, S. J. Stolfo, A. Stavrou, and C. V. Wright, Eds., vol. 8145. Springer,2013, pp. 204–222.

[177] C. Paget and K. Nohl, “GSM: SRSLY?” 26th Chaos Communication Congress,2009, http://events.ccc.de/congress/2009/Fahrplan/events/3654.en.html.

[178] G. Paller, “Dedexer,” http://dedexer.sourceforge.net/.

[179] R. Pandita, X. Xiao, W. Yang, W. Enck, and T. Xie, “WHYPER: Towardsautomating risk assessment of mobile applications,” in Proceedings of the 22ndUSENIX Security Symposium. USENIX Association, 2013, pp. 527–542.

[180] S. Park, A. Savvides, and M. Srivastava, “Battery Capacity MeasurementAnd Analysis Using Lithium Coin Cell Battery,” in International Symposiumon Low Power Electronics and Design, ser. ISLPED, 2001. [Online]. Available:http://doi.acm.org/10.1145/383082.383187

[181] C. B. Parker, “Stanford students show that phone record surveillance can yieldvast amounts of information,” http://news.stanford.edu/news/2014/march/nsa-phone-surveillance-031214.html.

[182] A. Pathak, Y. C. Hu, and M. Zhang, “Where is the energy spent inside myapp? Fine Grained Energy Accounting on Smartphones with Eprof,” in ACMEuropean Conference on Computer Systems, ser. EuroSys, 2012. [Online].Available: http://doi.acm.org/10.1145/2168836.2168841

[183] A. Pathak, Y. C. Hu, M. Zhang, P. Bahl, and Y.-M. Wang, “Fine-GrainedPower Modeling for Smartphones Using System Call Tracing,” in ACMEuropean Conference on Computer Systems, ser. EuroSys, 2011. [Online].Available: http://doi.acm.org/10.1145/1966445.1966460

[184] Paul K., “Replicant developers find and close SamsungGalaxy backdoor,” http://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor.

187

http://www.openhandsetalliance.com/press_110507.html

http://www.openhandsetalliance.com/press_110507.html

http://www.securelist.com/en/blog/9175/Android_4_3_and_SELinux

http://www.securelist.com/en/blog/9175/Android_4_3_and_SELinux

http://events.ccc.de/congress/2009/Fahrplan/events/3654.en.html

http://dedexer.sourceforge.net/

http://doi.acm.org/10.1145/383082.383187

http://news.stanford.edu/news/2014/march/nsa-phone-surveillance-031214.html

http://news.stanford.edu/news/2014/march/nsa-phone-surveillance-031214.html

http://doi.acm.org/10.1145/2168836.2168841

http://doi.acm.org/10.1145/1966445.1966460

http://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor

http://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor

[185] H. Peng, C. Gates, B. Sarma, N. Li, Y. Qi, R. Potharaju, C. Nita-Rotaru,and I. Molloy, “Using probabilistic generative models for ranking risks of An-droid apps,” in Proceedings of the 2012 ACM Conference on Computer andCommunications Security, ser. CCS ’12. ACM, 2012, pp. 241–252.

[186] D. Perez and J. Pico, “A practical attack against GPRS/EDGE/UMTS/HSPAmobile data communications,” Black Hat DC, 2011.

[187] T. Petsas, G. Voyatzis, E. Athanasopoulos, M. Polychronakis, and S. Ioannidis,“Rage against the virtual machine: hindering dynamic analysis of androidmalware,” in EUROSEC, D. Balzarotti and J. Caballero, Eds. ACM, 2014,p. 5.

[188] M. Protsenko and T. Müller, “Pandora applies non-deterministic obfuscationrandomly to android,” in MALWARE. IEEE, 2013, pp. 59–67.

[189] Qualcomm, “Snapdragon 800 processors,” http://www.qualcomm.com/snapdragon/processors/800.

[190] R. Rao, S. Vrudhula, and D. Rakhmatov, “Battery modeling for energy awaresystem design,” Computer, vol. 36, no. 12, pp. 77–87, Dec. 2003.

[191] K. Rapoza, “Bitcoin $10,000?” http://www.forbes.com/sites/kenrapoza/2013/12/04/the-bitcoin-bubble/.

[192] S. Rasthofer, S. Arzt, and E. Bodden, “A machine-learning approach for clas-sifying and categorizing android sources and sinks,” in 2014 Network and Dis-tributed System Security Symposium (NDSS), 2014.

[193] V. Rastogi, Y. Chen, and W. Enck, “Appsplayground: automatic securityanalysis of smartphone applications,” in CODASPY, E. Bertino, R. S. Sandhu,L. Bauer, and J. Park, Eds. ACM, 2013, pp. 209–220.

[194] V. Rastogi, Y. Chen, and X. Jiang, “Catch Me If You Can: Evaluating An-droid Anti-Malware Against Transformation Attacks,” IEEE Transactions onInformation Forensics and Security, pp. 99–108, 2014.

[195] A. Reina, A. Fattori, and L. Cavallaro, “A system call-centric analysisand stimulation technique to automatically reconstruct Android malware be-haviors,” in Proceedings of the 6th European Workshop on System Security(EUROSEC), 2013, see also: http://copperdroid.isg.rhul.ac.uk/copperdroid/about.php.

188

http://www.qualcomm.com/snapdragon/processors/800

http://www.qualcomm.com/snapdragon/processors/800

http://www.forbes.com/sites/kenrapoza/2013/12/04/the-bitcoin-bubble/

http://www.forbes.com/sites/kenrapoza/2013/12/04/the-bitcoin-bubble/

http://copperdroid.isg.rhul.ac.uk/copperdroid/about.php

http://copperdroid.isg.rhul.ac.uk/copperdroid/about.php

[196] S. Rosen, Z. Qian, and Z. M. Mao, “AppProfiler: A flexible method of exposingprivacy-related behavior in Android applications to end users,” in Proceedingsof the Third ACM Conference on Data and Application Security and Privacy,ser. CODASPY ’13. ACM, 2013, pp. 221–232.

[197] B. Ross, C. Jackson, N. Miyake, D. Boneh, and J. C. Mitchell, “Stronger pass-word authentication using browser extensions,” in USENIX Security Sympo-sium, 2005.

[198] Saikoa BVBA, “DexGuard,” http://www.saikoa.com/dexguard.

[199] B. P. Sarma, N. Li, C. Gates, R. Potharaju, C. Nita-Rotaru, and I. Mol-loy, “Android permissions: A perspective combining risks and benefits,” inProceedings of the 17th ACM Symposium on Access Control Models and Tech-nologies, ser. SACMAT ’12. ACM, 2012, pp. 13–22.

[200] G. Sarwar, O. Mehani, R. Boreli, and M. A. Kaafar, “On the effectivenessof dynamic taint analysis for protecting against private information leaks onandroid-based devices.” in SECRYPT, 2013, pp. 461–468.

[201] E. J. Schwartz, T. Avgerinos, and D. Brumley, “All You Ever Wanted to Knowabout Dynamic Taint Analysis and Forward Symbolic Execution (but MightHave Been Afraid to Ask),” in IEEE Symposium on Security and Privacy.IEEE Computer Society, 2010, pp. 317–331.

[202] M. J. Schwartz, “Stolen Digital Certificates Compromised CIA,MI6, Tor,” http://www.darkreading.com/attacks-and-breaches/stolen-digital-certificates-compromised-cia-mi6-tor/d/d-id/1099964?

[203] H. Shacham, “The Geometry of Innocent Flesh on the Bone: Return-into-libcWithout Function Calls (on the x86),” in ACM Conference on Computer andCommunications Security (CCS), 2007.

[204] M. I. Sharif, A. Lanzi, J. T. Giffin, and W. Lee, “Impeding Malware AnalysisUsing Conditional Code Obfuscation,” in NDSS. The Internet Society, 2008.

[205] G. Shih, “Facebook admits year-long data breach exposed6 million users,” http://www.reuters.com/article/2013/06/21/net-us-facebook-security-idUSBRE95K18Y20130621.

[206] S. Y. Shin and J. C. Maldonado, Eds., Proceedings of the 28th Annual ACMSymposium on Applied Computing, SAC ’13, Coimbra, Portugal, March 18-22,2013. ACM, 2013.

[207] Shiny Development, “Average App Store Review Times,” http://appreviewtimes.com/.

189

http://www.saikoa.com/dexguard

http://www.darkreading.com/attacks-and-breaches/stolen-digital-certificates-compromised-cia-mi6-tor/d/d-id/1099964?

http://www.darkreading.com/attacks-and-breaches/stolen-digital-certificates-compromised-cia-mi6-tor/d/d-id/1099964?

http://www.reuters.com/article/2013/06/21/net-us-facebook-security-idUSBRE95K18Y20130621

http://www.reuters.com/article/2013/06/21/net-us-facebook-security-idUSBRE95K18Y20130621

http://appreviewtimes.com/

http://appreviewtimes.com/

[208] S. Smalley and R. Craig, “Security enhanced (se) android: Bringing flexiblemac to android,” in NDSS. The Internet Society, 2013.

[209] D. X. Song, D. Brumley, H. Yin, J. Caballero, I. Jager, M. G. Kang, Z. Liang,J. Newsome, P. Poosankam, and P. Saxena, “BitBlaze: A New Approachto Computer Security via Binary Analysis,” in ICISS, ser. Lecture Notes inComputer Science, R. Sekar and A. K. Pujari, Eds., vol. 5352. Springer, 2008,pp. 1–25.

[210] M. Spreitzenbarth, F. C. Freiling, F. Echtler, T. Schreck, and J. Hoffmann,“Mobile-Sandbox: Having a Deeper Look into Android Applications,” in SAC,S. Y. Shin and J. C. Maldonado, Eds. ACM, 2013, pp. 1808–1815.

[211] M. Spreitzenbarth, J. Hoffmann, H. Lemoine, T. Schreck, and F. Echtler, “Mo-bile Sandbox: Ein Analyseframework für Android Applikationen,” Proceedingsof the 13th Deutscher IT-Sicherheitskongress, 2013.

[212] statistica, “Global smartphone sales by operating system 2009-2013,by quarter,” http://www.statista.com/statistics/266219/global-smartphone-sales-since-1st-quarter-2009-by-operating-system/ .

[213] R. Stevens, C. Gibler, J. Crussell, J. Erickson, and H. Chen, “InvestigatingUser Privacy in Android Ad Libraries,” Workshop on Mobile Security Tech-nologies (MoST), 2012.

[214] S. J. Stolfo, A. Stavrou, and C. V. Wright, Eds., Research in Attacks, In-trusions, and Defenses - 16th International Symposium, RAID 2013, RodneyBay, St. Lucia, October 23-25, 2013. Proceedings, ser. Lecture Notes in Com-puter Science, vol. 8145. Springer, 2013.

[215] B. Stone-Gross, R. Abman, R. A. Kemmerer, C. Kruegel, and D. G. Steiger-wald, “The Underground Economy of Fake Antivirus Software,” in Workshopon Economics of Information Security (WEIS), 2011.

[216] E. Struse, J. Seifert, S. Uellenbeck, E. Rukzio, and C. Wolf, “Permission-Watcher: Creating user awareness of application permissions in mobile sys-tems,” in Ambient Intelligence - Third International Joint Conference, AmI2012, Pisa, Italy, November 13-15, 2012. Proceedings, ser. Lecture Notes inComputer Science, vol. 7683, 2012, pp. 65–80.

[217] Symantec, “Symantec Smartphone Honey Stick Project,” http://www.symantec.com/about/news/resources/press_kits/detail.jsp?pkid=symantec-smartphone-honey-stick-project.

[218] Symantec, “Global Internet Security Threat Report,” 2008.

190

http://www.statista.com/statistics/266219/global-smartphone-sales-since-1st-quarter-2009-by-operating-system/

http://www.statista.com/statistics/266219/global-smartphone-sales-since-1st-quarter-2009-by-operating-system/

http://www.symantec.com/about/news/resources/press_kits/detail.jsp?pkid=symantec-smartphone-honey-stick-project



[219] D. Tarakanov, “ZeuS on the Hunt,” http://www.securelist.com/en/analysis/204792107/ZeuS_on_the_Hunt.

[220] E. Tews and M. Beck, “Practical attacks against WEP and WPA,” in WISEC,D. A. Basin, S. Capkun, and W. Lee, Eds. ACM, 2009, pp. 79–86.

[221] S. Thomas, “DecryptoCat,” http://tobtu.com/decryptocat.php.

[222] F. Tip, “A survey of program slicing techniques,” J. Prog. Lang., vol. 3, no. 3,1995.

[223] C. Torralba, “Symantec Now Agrees with Lookout Security, Mal-ware Just an Aggressive Ad Network,” http://www.androidauthority.com/symantec-now-agrees-with-lookout-security-51110/.

[224] P. Traynor, W. Enck, P. McDaniel, and T. F. L. Porta, “Exploiting openfunctionality in SMS-capable cellular networks,” Journal of Computer Secu-rity, vol. 16, no. 6, pp. 713–742, 2008.

[225] S. Uellenbeck, “Towards Secure and Usable User Authentication on MobileDevices,” Ph.D. dissertation, Ruhr-University Bochum, Germany, 2014.

[226] S. Uellenbeck, M. Dürmuth, C. Wolf, and T. Holz, “Quantifying the Securityof Graphical Passwords: The Case of Android Unlock Patterns,” in ACMConference on Computer and Communications Security, A.-R. Sadeghi, V. D.Gligor, and M. Yung, Eds. ACM, 2013, pp. 161–172.

[227] R. Unuchek, “The most sophisticated Android Trojan,” http://www.securelist.com/en/blog/8106/The_most_sophisticated_Android_Trojan.

[228] R. Vallée-Rai, P. Co, E. Gagnon, L. Hendren, P. Lam, and V. Sundaresan,“Soot - a Java Bytecode Optimization Framework,” in Proceedings of the 1999Conference of the Centre for Advanced Studies on Collaborative Research, ser.CASCON ’99. IBM Press, 1999, available online http://www.sable.mcgill.ca/soot/.

[229] V. van der Veen and C. Rossow, “Tracedroid – Dynamic Android app analysis,”http://tracedroid.few.vu.nl.

[230] Victor Chebyshev, “Mobile attacks!” http://www.securelist.com/en/blog/805/Mobile_attacks.

[231] Victor H., “Android’s Google Play beats App Store with over 1million apps, now officially largest,” http://www.phonearena.com/news/Androids-Google-Play-beats-App-Store-with-over-1-million-apps-\now-officially-largest_id45680 .

191

http://www.securelist.com/en/analysis/204792107/ZeuS_on_the_Hunt

http://www.securelist.com/en/analysis/204792107/ZeuS_on_the_Hunt

http://tobtu.com/decryptocat.php

http://www.androidauthority.com/symantec-now-agrees-with-lookout-security-51110/

http://www.androidauthority.com/symantec-now-agrees-with-lookout-security-51110/

http://www.securelist.com/en/blog/8106/The_most_sophisticated_Android_Trojan

http://www.securelist.com/en/blog/8106/The_most_sophisticated_Android_Trojan

http://www.sable.mcgill.ca/soot/

http://www.sable.mcgill.ca/soot/

http://tracedroid.few.vu.nl

http://www.securelist.com/en/blog/805/Mobile_attacks

http://www.securelist.com/en/blog/805/Mobile_attacks

http://www.phonearena.com/news/Androids-Google-Play-beats-App-Store-with-over-1-million-apps-\now-officially-largest_id45680



[232] T. Vidas and N. Christin, “Evading android runtime analysis via sandboxdetection,” in ASIACCS, S. Moriai, T. Jaeger, and K. Sakurai, Eds. ACM,2014, pp. 447–458.

[233] VisualThreat, “VisualThreat – Deep Visualization for Mobile Threat,” http://www.visualthreat.com/index.action.

[234] X. Wei, L. Gomez, I. Neamtiu, and M. Faloutsos, “ProfileDroid: Multi-layerprofiling of Android applications,” in Proceedings of the 18th Annual Interna-tional Conference on Mobile Computing and Networking, ser. Mobicom ’12.ACM, 2012, pp. 137–148.

[235] M. Weiser, “Program slicing,” IEEE Trans. Software Eng., vol. 10, no. 4, pp.352–357, 1984.

[236] C. Willems, “Instrumenting Existing System Components for Dynamic Analy-sis of Malicious Software,” Ph.D. dissertation, Ruhr-University Bochum, Ger-many, 2013.

[237] R. Wisniewski, “android-apktool – A tool for reverse engineering Android apkfiles,” http://code.google.com/p/android-apktool/.

[238] M. Wu, S. Garfinkel, and R. Miller, “Secure Web Authentication with MobilePhones,” inDIMACS Workshop on Usable Privacy and Security Systems, 2004.

[239] T. Wyatt, “Security Alert: Geinimi, Sophisticated New Android Trojan Foundin Wild,” https://blog.lookout.com/blog/2010/12/29/geinimi_trojan/.

[240] R. Xu, H. Saïdi, and R. Anderson, “Aurasium: Practical policy enforcementfor android applications,” in USENIX Security Symposium, T. Kohno, Ed.USENIX Association, 2012, pp. 539–552.

[241] L. K. Yan and H. Yin, “DroidScope: Seamlessly reconstructing the OS andDalvik semantic views for dynamic Android malware analysis,” in Proceedingsof the 21st USENIX Security Symposium. USENIX Association, 2012, p. 29ff.

[242] Z. Yang, M. Yang, Y. Zhang, G. Gu, P. Ning, and X. S. Wang, “AppIntent: An-alyzing sensitive data transmission in Android for privacy leakage detection,”in Proceedings of the 20th ACM Conference on Computer and CommunicationsSecurity, ser. CCS ’13. ACM, 2013, pp. 1043–1054.

[243] C. Yoon, D. Kim, W. Jung, C. Kang, and H. Cha, “AppScope: ApplicationEnergy Metering Framework for Android Smartphones Using Kernel ActivityMonitoring,” in USENIX Annual Technical Conference, ser. ATC, 2012.[Online]. Available: http://dl.acm.org/citation.cfm?id=2342821.2342857

192

http://www.visualthreat.com/index.action

http://www.visualthreat.com/index.action

http://code.google.com/p/android-apktool/

https://blog.lookout.com/blog/2010/12/29/geinimi_trojan/

http://dl.acm.org/citation.cfm?id=2342821.2342857

[244] Yubico, “YubiKey – The key to the cloud,” http://www.yubico.com/products-250.

[245] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P. Dick, Z. M. Mao, and L. Yang,“Accurate online power estimation and automatic battery behavior basedpower model generation for smartphones,” in Conference on Hardware/Soft-ware Codesign and System Synthesis, 2010.

[246] Y. Zhang, M. Yang, B. Xu, Z. Yang, G. Gu, P. Ning, X. S. Wang, and B. Zang,“Vetting undesirable behaviors in Android apps with permission use analysis,”in Proceedings of the 20th ACM Conference on Computer and CommunicationsSecurity, ser. CCS ’13. ACM, 2013, pp. 611–622.

[247] M. Zheng, P. P. C. Lee, and J. C. S. Lui, “ADAM: An Automatic and Ex-tensible Platform to Stress Test Android Anti-virus Systems,” in DIMVA, ser.Lecture Notes in Computer Science, U. Flegel, E. P. Markatos, and W. Robert-son, Eds., vol. 7591. Springer, 2012, pp. 82–101.

[248] W. Zhou, Y. Zhou, X. Jiang, and P. Ning, “Droidmoss: Detecting repackagedsmartphone applications in third-party android marketplaces,” ACM Confer-ence on Data and Application Security and Privacy, 2012.

[249] W. Zhou, Z. Wang, Y. Zhou, and X. Jiang, “Divilar: diversifying intermediatelanguage for anti-repackaging on android platform,” in Proceedings of the 4thACM conference on Data and application security and privacy. ACM, 2014,pp. 199–210.

[250] Y. Zhou and X. Jiang, “Dissecting Android Malware: Characterization andEvolution,” in IEEE Symposium on Security and Privacy, 2012.

[251] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang, “Hey, You, Get Off of My Mar-ket: Detecting Malicious Apps in Official and Alternative Android Markets,”Symposium on Network and Distributed System Security, 2012.

193

http://www.yubico.com/products-250

http://www.yubico.com/products-250

Johannes Hoffmann

Persönliche DatenGeboren am 23. 02. 1982Geburtsort Herdecke

E-Mail [email protected]

Schul- und Berufsbildung2010–2014 Wissenschaftlicher Mitarbeiter, Ruhr-Universität/HGI, Bochum.2009–2010 Wissenschaftlicher Mitarbeiter, Technische Universität, Dortmund.2003–2009 Studium, Technische Universität, Dortmund, Dipl.-Inf.2002–2003 Studium, Ruhr-Universität, Bochum.2001–2002 Zivildienst, H.O.T. Delta in Marl.1992–2001 Schule, Gymnasium im Loekamp, Marl, Abitur.

195

towards secure smartphones

Documents

Transcript of towards secure smartphones