From Mobile to Security : Towards Secure Smartphones

Fakultät für Elektrotechnik und Informationstechnik

From Mobile to Security

Towards Secure Smartphones

Dissertation

zur Erlangung des Grades eines Doktor-Ingenieurs der Fakultät für Elektrotechnik und Informationstechnik an der Ruhr-Universität Bochum

vorgelegt von

Johannes Hoﬀmann

aus 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 Security

Towards Secure Smartphones

Dissertation

zur Erlangung des Grades eines Doktor-Ingenieurs der Fakultät für Elektrotechnik und Informationstechnik an der Ruhr-Universität Bochum

vorgelegt von

Johannes Hoﬀmann

aus 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 increasing importance since the introduction of the first smartphones in 2007. Nowa- days, smartphones are commonly used, and because of their rich feature set always online, easily extensible with third-party applications, and usable for many tasks. Just like normal computers, they are complex systems of hard- and software processing vast amounts of data. Depending on the use cases, this may include private user data such as contact information or pictures, company secrets, as well as account credentials and payment information. A lack of knowledge related to security-sensitive tasks of most users and security related bugs in software provide evildoers with many attack vectors. Their goals can be diverse, but typically they steal data or misuse premium rate services at the users’ expense. The last years have shown that many pressing issues related to mobile security remain unsolved and must be addressed. The popularity of smartphones and their diversity make them not only attractive for their users, but also a target for 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 mobile security and emphasize its relevance. We point out that we need proper techniques to analyze malicious mobile applications. Therefore, we present a static program analysis tool which performs a technique called program slicing. We analyze more than 140,000 mobile applications and present many differences between benign and malicious applications. Next to our static approach, we present work in the dynamic program analysis field and evaluate whether (malicious) activities can be detected based on the energy consumption they cause on mobile devices. Following these two contributions to analyze mobile applications, we evaluate how robust state-of-the- art analysis tools are against advanced and highly obfuscated malware. We present a framework which obfuscates mobile applications and then test the effectiveness of well known tools against such altered applications. In a final step, we propose a tool which enables the usage of web browser on compromised machines while used credentials or other security relevant data is protected from attackers. We make use of the smartphone’s connectivity and link it to other computer systems in order to strengthen their security.

Zusammenfassung

Diese Dissertation widmet sich dem Forschungsthema Mobile Sicherheit, welches seit der Einführung der ersten Smartphones im Jahr 2007 immer relevanter wird. Smart- phones sind sehr weit verbreitet und dank ihrer üppigen Ausstattung an Sensoren und Netzwerkkomponenten immer online und durch einfach installierbare Applika- tionen für fast jeden Anwendungsfall nutzbar. Sie sind wie übliche Computer ein komplexes Gebilde aus Hard- und Software, die gewaltige Datenmengen verarbeiten. Zu diesen Daten gehören unter anderen – je nach Anwendungsfall – private Daten des Benutzers wie Kontaktdaten und Fotos, Firmendaten des Arbeitgebers sowie Benutzerkontendaten und hinterlegte Bezahloptionen. Ein mangelndes Verständnis der meisten Benutzer bezüglich sicherheitsrelevanter Fragestellungen und Sicherheitslücken in der Software, welche oft der Komplexität der Smartphones geschuldet sind, bieten Angreifern viele Angriﬀsvektoren. Deren Ziele können ganz unterschiedlich sein, oft wird jedoch Datenklau betrieben oder kostenpﬂichtige Mehrwertdienste werden zu Lasten des Besitzers ausgenutzt. Die letzten Jahre haben gezeigt, dass es im Bereich der mobilen Sicherheit viele ungelöste Probleme gibt und entsprechende Lösungen benötigt werden. Die explosionsartige Verbreitung von Smartphones und deren Potential machen diese nicht nur für deren Benutzer interessant, sondern auch zum Ziel von Cyberkriminalität. Im Rahmen dieser Dissertation nehmen wir uns einige dieser Probleme an. Wir stellen zunächst das Forschungsfeld der mobilen Sicherheit vor und verdeutlichen dessen Relevanz. Hierbei zeigen wir, dass Techniken zur Programmanalyse drin- gend benötigt werden um Schadsoftware zu analysieren. Infolgedessen stellen wir Arbeiten im Rahmen der statischen Schadsoftwareanalyse vor, in welcher wir über 140.000 Applikationen u. a. mittels der Technik Program Slicing untersuchen und viele Erkenntnisse über Schadsoftware präsentieren. Im Rahmen der dynamisch- en Programmanalyse untersuchen wir, inwieweit sich Software auf mobilen Geräten mittels ihres Stromverbrauches erkennen lässt. Zudem evaluieren wir, wie robust be- kannte und oft genutzte Analysesysteme gegenüber stark obfuskierter Schadsoftware sind. 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 nutzen wir die Konnektivität von Smartphones aus, um diese mit anderen Computersyste- men zu verbinden und so deren Sicherheit zu erhöhen.

iii

Contents

1 Introduction1 1.1 Motivation...... 1 1.2 Topic and Contributions...... 2 1.3 List of Publications...... 5 1.4 Outline...... 7

2 Background: From Mobile to Security9 2.1 Why Mobile Security?...... 10 2.1.1 Smartphone Characteristics...... 18 2.1.2 Smartphone Security Mechanisms...... 22 2.1.3 Attack Vectors...... 27 2.1.4 Mobile Malware...... 30 2.2 Analysis of Malicious Software...... 34 2.2.1 Static Analysis...... 35 2.2.2 Dynamic Analysis...... 36 2.2.3 Limitations...... 37 2.3 Speciﬁc Security Aspects...... 38 2.4 Discussion...... 40

3 Static Approach based on Program Slicing 43 3.1 Introduction...... 44 3.2 Related Work...... 46 3.3 High-Level Overview of SAAF...... 47 3.4 Static Backtracking...... 50

v 3.4.1 General Workﬂow...... 51 3.4.2 Program Slicing...... 51 3.4.3 Opcode Handling...... 53 3.4.4 Results...... 55 3.4.5 Example...... 56 3.5 Evaluation...... 58 3.5.1 Analysis Results...... 59 3.5.2 Malware Analysis...... 67 3.6 Discussion...... 69

4 Dynamic Approach based on Power Consumption 71 4.1 Introduction...... 72 4.2 Related Work...... 73 4.3 Measurement Setup...... 75 4.3.1 Application...... 76 4.3.2 Test Devices...... 77 4.4 Short Time Tests...... 77 4.4.1 Initial Tests...... 79 4.4.2 Energy Greedy Functions...... 81 4.4.3 Location API...... 82 4.4.4 Data Heist...... 83 4.5 Long Time Tests...... 85 4.5.1 Initial Tests...... 86 4.5.2 Energy Greedy Functions...... 87 4.5.3 Location API...... 88 4.5.4 Data Heist...... 89 4.5.5 Uncalibrated Phones...... 89 4.6 Validation...... 90 4.7 Evaluation...... 92 4.8 Discussion...... 95

5 Change of Ends: Obfuscating Android Applications 97 5.1 Introduction...... 98 5.2 Related Work...... 100 5.2.1 Android Application Analyzers...... 100 5.2.2 Android Obfuscators...... 106 5.3 Program Analysis Assumptions & Obfuscation Methods...... 107 5.3.1 Dynamic Analysis Evasion...... 108 5.3.2 Static Analysis Evasion...... 110 5.4 Evaluating the Robustness of Analysis Tools...... 114 5.4.1 Static Analysis Systems...... 115

vi 5.4.2 Dynamic Analysis Systems...... 116 5.4.3 Decompilers...... 120 5.4.4 Signatures & Antivirus Detection...... 123 5.4.5 Bugs...... 127 5.5 Implementation and Performance Evaluation...... 128 5.5.1 Implementation...... 128 5.5.2 Performance...... 129 5.5.3 Skipped Obfuscation Steps...... 130 5.6 Discussion...... 131

6 Enhancing Other Devices’ Security with SmartProxy 135 6.1 Introduction...... 136 6.2 Related Work...... 138 6.3 System Overview...... 140 6.3.1 Attacker Model...... 140 6.3.2 Approach...... 141 6.4 Implementation...... 142 6.4.1 Application Overview...... 143 6.4.2 Communication Modes...... 144 6.4.3 Proxy Workﬂow...... 145 6.4.4 Man-In-The-Middle Attack...... 147 6.4.5 Filtering...... 149 6.4.6 Personal Data Encryption...... 151 6.5 Evaluation...... 152 6.5.1 Synthetic Benchmarks...... 152 6.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

1 Introduction

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. We begin with a motivation why mobile security is an important research field and where problems surface. Thereafter we provide details about our contributions and the specific fields we worked on. We then provide a list of all publications the author was involved in during his PhD studies and close this first chapter with an outline of the remainder of this thesis.

1.1 Motivation

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

Their popularity is also caused by vendors who make sure that users have easy access to 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. The amount of oﬀered applications is astonishing: More than 1 million applications were available 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 also contributes to the smartphone’s popularity. These circumstances allow people to stay connected with their friends and coworkers through messaging applications or social media websites, do their online banking from 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 or secret company data on smartphones and therefore imply security relevant questions. Most users are not skilled in making reasonable security decisions and often do not even recognize that some decisions can result in, e. g., information disclosure or theft of money. As a result there is a huge potential for malware authors to exploit this lack 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 secure code? What if the smartphone operating system vendor ships the smartphone with faulty software? The connectivity, the vast amount of installable applications and the amount of data stored 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 to premium-rate numbers or they can steal payment information used on the smartphone, 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 gathered information. Furthermore, acquired private data such as intimate photos or conversations 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 ﬁeld of mobile security. Smartphones are a target for malware authors and malicious software is quickly improving with respect to 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 crucial to detect malicious or problematic software and we need ways to properly analyze them.

1.2 Topic and Contributions

In this thesis we address several topics in the ﬁeld of mobile security. Since malicious applications for smartphones are becoming more sophisticated and larger by their numbers, the need for proper tools to analyze and detect them is dire. We thus present new tools which analyze malicious applications for mobile devices, detect (malicious) activities based on the mobile device’s power consumption and enhance the 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 sophisticated malicious applications.

Our contributions on this topic are therefore twofold. We strengthen the security of smartphones in diﬀerent ways but also leverage them to mitigate attacks on other computer systems. The contributions of this thesis are summarized chapter-wise in the following.

Chapter2: Background: From Mobile to Security. In this introductory background chapter we thoroughly discuss many aspects of mobile security and motivate the contributions in the following chapters. We discuss how fast the smartphone market evolves and what features are offered by modern smartphones. We then report on security mechanisms utilized by smartphones and present attack vectors which can be abused by attackers and malicious software. To demonstrate the potential of such attacks, we provide a chronological overview of malicious software and their abilities which have been encountered on mobile devices. After we have motivated the need for proper analysis systems, we briefly discuss program analysis aspects for mobile applications and motivate our contributions in this field. We also report on aspects for smartphones not directly related to the term “security” but which can nevertheless lead to very real security issues, such as the simple act of charging a smartphone.

Chapter3: Static Approach based on Program Slicing. After we have discussed the need for proper program analysis tools, we present a tool named Saaf which is a static analysis framework for Android applications. Saaf’s main feature is its ability to analyze disassembled dex code—namely smali code—with a technique called program slicing. Utilizing this technique enables us to extract many useful information of malicious applications, e. g., which commands are passed and executed by the system shell or whether any premium rate short messages are sent to which destination number. The tool also supports an analyst with a manual analysis and oﬀers many other functions such as generating control ﬂow graphs, displaying all entry points and used permissions and it can easily decompile program code to Java code next to other features.

In total, we analyzed more than 136,000 benign applications and more than 6,100 malicious ones. We present many interesting analysis results and provide statistics in which way benign applications diﬀer from malicious ones. This includes aspects such as used permissions, used system services or loaded libraries to name but a few. We also speciﬁcally report on analysis results for chosen malware samples. The tool itself and its source code was made publicly available.

3 1 Introduction

Chapter4: Dynamic Approach based on Power Consumption. In this chapter, we present our contribution in the field of dynamic program analysis. Instead of choosing some “traditional way” to dynamically analyze an application, we chose a completely different approach. We evaluate whether it is possible to detect (malicious) activities performed on a smartphone based on their energy fingerprint. In theory, every performed action consumes some measurable amount of energy from the battery, as long as the battery is not being charged. With proper tools which precisely measure consumed energy it is theoretically possible to detect certain activities based on their consumed energy. We evaluate whether previously published work in this field—conducted for feature phones—is also valid for modern smartphones. We make use of a specialized software which precisely measures consumed energy and perform many tests in order to understand which activities consume which amount of energy under certain circumstances. We perform our measurements in synthetic short time tests but also for real-world scenarios in long time tests. We try to detect malicious activities by means of a self written proof-of-concept malware next to real-world malware samples. Our empirical tests indicate that the power consumed by many activities and applications is too small to be detectable.

Chapter5: Change of Ends: Obfuscating Android Applications. After we have presented our work in the field of program analysis, we evaluate the robustness of available application analysis tools for Android. We first introduce existing program analysis systems and then discuss on what assumptions such tools work and how these assumptions can be taken away. We then present a tool which is able to obfuscate 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 do not intend to break tools caused by implementation bugs, but we aim to take away the basic assumptions they rely upon. This includes, e. g., the removal of most direct method invocations which results in degenerate call graphs. Tools which utilize this graph probably cannot work to their full extend this way and the resulting analysis reports eventually lack important parts. We also discuss code modifications which reliable hinder the decompilation of Android applications and evaluate how well antivirus solutions are able to detect malicious but obfuscated malware. As we see in the next chapter, malware for mobile devices is advancing quickly with respect to their functionality and quality. Meaning, analyzing sophisticated malware samples becomes harder and harder. We want to emphasize that next to evolving malware, analysis tools must also improve in order to keep up with the flood of new malware families. We therefore evaluate the robustness of many static and dynamic analysis tools against well-obfuscates applications.

4 1.3 List of Publications

Chapter6: Enhancing Other Devices’ Security with SmartProxy. In our last contribution we completely change our point of view. Instead of analyzing mobile applications or attempting to protect mobile devices from malware, we instead enhance the security of a normal PC with the help of a smartphone. In this chapter we present a prototype named SmartProxy which runs on a trusted smartphone which can be connected to an untrusted PC, e. g., over a WiFi network or a USB cable. As the PC is untrusted, the user probably does not want to input any credentials; 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 credentials fall into the attacker’s hand if she somehow controls the PC. Our proposed solution enables 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. These fake credentials are substituted by SmartProxy on the smartphone with real ones, which have been set up previously. That way, an attacker never sees real credentials and cannot steal those. Our tool additionally strips any security relevant data sent from the remote web server to the PC, such as session IDs or cookies. These datasets are also replaced with dummy values and can therefore also not be abused by an attacker. Our solution works for plain HTTP connections as well as for encrypted HTTPS connections.

1.3 List of Publications

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

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

5 1 Introduction

Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices. This paper gives a broad overview in the emerging ﬁeld of mobile security with respect to early 2011. Chapter2 is partly based on this publication and it emerged as part of the MobWorm project. It was published together with Michael Becher, Felix C. Freiling, Thorsten Holz, Sebastian Uellenbeck and Christopher Wolf at 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 PC with the help of a smartphone such that an attacker cannot get hold of used credentials. It was jointly published with Sebastian Uellenbeck and Thorsten Holz as part of the MobWorm project at the DIMVA (Detection of Intrusions and Malware, and Vulnerability Assessment) conference in 2012 [111]. Chapter6 is based on this work.

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

Mobile-Sandbox: Having a Deeper Look into Android Applications. This paper presents an analysis system called Mobile Sandbox which automatically dynamically analyzes Android applications based on information previously gathered by static analysis techniques. This work also emerged in the MobWorm project and was done in cooperation with Micheal Spreitzenbarth, Florian Echtler, Thomas Schreck and Felix C. Freiling. It was published in 2013 at the ACM Symposium on Applied Computing (SAC) [210].

Mobile Sandbox: Ein Analyseframework für Android Applikationen. This work summarizes and extends the ﬁndings of the Mobile Sandbox and Slicing Droids publications already presented above. It partly emerged in the MobWorm project and was jointly conducted with Michael Spreitzenbarth, Hanno Lemoine, Thomas Schreck 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? This paper presents an evaluation whether (malicious) activities on a smartphone can be detected based on their power consumption. This work again was published as part 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 and Thorsten Holz and Chapter4 is based on it.

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

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

1.4 Outline

The remainder of this thesis is structured as follows. We first thoroughly introduce the field of mobile security in Chapter2. We discuss and motivate our contributions and give background information for the following chapters. We then introduce our work in the field of static program analysis in Chapter3. More specifically, we present a prototype named Saaf, which enables an analyst to perform program slicing on Android applications. Furthermore, we present many analysis results gathered while analyzing many benign and malicious applications. Afterwards, we present our works in the field of dynamic program analysis. In Chapter4, we evaluate how precise (malicious) activities can be detected by means of consumed energy of mobile applications.

7 1 Introduction

Following, we evaluate how robust state-of-the art analysis tools for mobile applications are against software, that tries to thwart analysis attempts. We therefore present a tool in Chapter5 which obfuscates Android applications and hampers static as well as dynamic analysis attempts. With this contribution we show that many tools cannot analyze well-obfuscated applications and that there exists a need to adapt to the rising number of sophisticated malware samples. After we have presented our work in the ﬁeld of program analysis we change our point of view in Chapter6. We present and discuss a prototype named Smart- Proxy which is able to provide secure use of a compromised PC with the help of a smartphone. The goal is to make a compromised PC usable for browsing the web while an attacker cannot get hold of any credentials. Afterwards, we conclude this thesis in Chapter7. We recap previous chapters and give an outlook on research ﬁelds which are worth to be looked at but were not treated within this thesis.

8 2 Background: From Mobile to Security

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

We begin with a thorough discussion of the term “mobile security” in Section 2.1 and emphasize the differences to “computing security” While doing so, we focus on smartphones and describe typical scenarios where security aspects surface and why they are important for this thesis. After this overview, we report on specific smartphone characteristics and their typical features in Section 2.1.1 followed by an overview of their security features and how data in general is protected by which mechanisms in Section 2.1.2. Afterwards, we define and categorize attack vectors in 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 devices and how it evolved since their dawn until now.

After we motivated the topic that security plays a big role in mobile computing and that mobile security matters, we give a short overview of program analysis techniques in Section 2.2. We cover the aspects of static and dynamic program analysis in Sections 2.2.1 and 2.2.2 in order to analyze (malicious) applications for mobile devices. Section 2.2.3 follows which covers the limitations of the aforementioned techniques. 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 are picked up again in the following chapters.

We emphasize special security aspects of mobile devices not previously covered in Section 2.3. While they are not directly related to computing security per se, they are 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 features oﬀered by smartphones in order to strengthen the security of normal PCs instead of making the smartphone more secure.

Throughout this chappter and especially in Sections 2.2 and 2.3 we point out which contributions we made to each of the research fields. We end this chapter with a summary in Section 2.4 and discuss how our work presented in the following chapters fits 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 of its own. Security, in the context of digital data processing is a huge topic covering many diﬀerent topics from communication protocols, data integrity, unforgeability as well as programming errors in software or hardware products to only name but a few. The diverse ﬁelds of security can be categorized in several broad topics describing their aspects, e. g., network security or operating system security. But what is so special about mobile security? The term security itself is not be covered in the following, as the meaning should be clear. What does the term mobile mean then? Let us start with Figure 2.1 from Google trends which illustrates when and how 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 at the end of 2010. If both trends are compared, a strong relation is immediately visible. A further investigation regarding similiar terms shows that the term mobile security also strongly correlates to the number of sold smartphones [212] over that time period.1

Apparently, our term has something to do with smartphones. Smartphones are available since 2007 to 2008 as “successors” to the so called feature phones, when Apple launched the iPhone [114] and Google introduced the Android operating system [174]. Before that time, feature phones were often also called Smartphone, as no distinction had to be made as “real” smartphones were not yet available (this

1 This does not proof that the numbers are statistical dependent, but an accidental correlation is very unlikely. Further investigations are ommited as the point should be made clear.

10 2.1 Why Mobile Security?

100 Mobile Security Smartphone

40 Interest over time

0 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 Year

Figure 2.1: Google Trends data [100] for the search terms “mobile security” (within quotes) and “smartphone”. The graph shows the worldwide interest over time with 100 marking the date of highest interest. explains the interest in the years before 2007 for smartphones in Figure 2.1). Since their dawn, smartphones top their previous year’s sell rate each year [212, 93]. In 2013, around 1 million Android smartphones were activated daily [99]. It is common that mobile security is often used in the context of smartphone security or mobile phone security. From now on we talk about smartphone security when we talk about mobile security and mobile devices most likely reference smartphones. A description of the technical details and what defines a smartphone is given in Section 2.1.1. For a distinction between feature phones and smartphones we refer the reader to the work 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 smartphone models, even the early generations offer many features previously not available in

11 2 Background: From Mobile to Security such small form factors. These features characterize smartphones—making them “smart”. Being able to establish and even hold a connection to the Internet at all 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 of opportunities and results in many different use cases. From home automation to online banking or the ability to remotely control cars to some extend and many other scenarios the options were never so easily doable by almost everyone from almost everywhere—even without much technically knowledge. Although most of these services are not directly supported by the smartphone or the operating system itself, they are made possible through the conjunction of utilizable hardware devices and the ability to install third party applications which make use of these and ultimately offer the features to the user. A description of the sensors and the features of typical smartphones is given in Section 2.1.1. Such additional applications are most of the time installed through so called application markets, like Google Play or Apple’s App Store. These application markets are divided in official and unofficial markets. Official ones as Google Play for Android or the App Store for iOS based smartphones are mostly directly enabled on new smartphones. They are easily accessible to the smartphone user as soon as the phone is activated and a user account has been created. The user only has to search for what he desires and install the application of his choice by simply clicking on more or less one button. Official markets on the one hand are supervised by smartphone hardware or OS vendors, who control what is offered to the 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 by the user, if desired. Trustworthiness of such markets vastly differs and we cover this topic in Section 2.1.4. For now, these markets offer easy access to additional applications, or apps, which enrich the smartphone. This might just be a simple game 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 categories of such apps is out of scope for this thesis, but, in general, one can imagine that there exists an app for almost every use case. To put it into a number: In July 2013 Google Play reached the mark of 1 million available applications [231]. Having easy access to so many installable applications leaves us with the question where all these offered applications come from. They are developed by a vast number of companies and individuals throughout the world. While the developer’s goals can be very different, the applications can nevertheless be categorized in three categories, depending on how they compensate the developer for the production costs:

12 2.1 Why Mobile Security?

• Free Applications. These applications do not cost any money and offer full functionality. • Free Applications with Ads. These are also offered for free, but display advertisements 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, the user 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 another way in order to be able to install or use them. Let us assume for a moment that free applications are free of ads, not malicious and are indeed free in the sense that the 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 respect to how users pay for applications. We therefore now look at ad-sponsored and paid applications and cover malicious ones afterwards. If an app is purchased, most of the time a purchase is performed from within the market application itself and the market vendor therefore has some way to charge the user for it. Although the user could enter a payment address each time a purchase is carried out, most of the time some credit card or other payment information is stored in some wallet application or directly on the market provider’s servers (or a mixture thereof), which is used for the transaction. For easiness, once a payment address has been set up, the whole purchase often is not more than accepting some confirmation and the charging itself is performed in the background. These payment information are 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 very valuable and sensitive data. Let us now look at apps, which display advertisements. Apparently, they must not be purchased by the user. Still, the developers aspire some compensation for their work and therefore display ads inside their application. When a user clicks on such a banner, the application’s developer is paid a small amount of money based on a contract between the developer and the ad provider. How the advertisement process works in detail is definitely out of scope for this thesis—for the Android operating system, e. g., Grace et al. [102] analyzed many ad frameworks. What matters is how the ad provider and the developer actually make money out of displaying advertisements. Typically, some company provides ads for an ad campaign, which the ad provider 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 by the company, e. g., their web shop or a website with more information about the advertised product, hoping that the user becomes a customer of some sort. The

13 2 Background: From Mobile to Security application developer gets paid by the ad provider when the user clicks on such a banner. Sometimes the ad even generates revenue for the developer if the banner is only displayed, without the user interacting with it at all. Since both sides are interested in getting the most money “out of a user”, the company as well as the ad provider are well interested in users who have a high probability for being interested in the advertised product. Displaying completely unrelated ads to users will most likely not entice them to consider clicking on the ad. This leaves us with the question how can one know what a user probably likes and therefore which ads are relevant for him? The key here is to build a profile about the user and to be able to identify this user although his real identity might still be unknown—the habits and likes are the information of interest. Here the smartphone with all its sensors plays a huge role. While ads are also served on a normal PC while browsing the web which are also selected based on a previously generated profile, typically much more information is available on a smartphone to build such a profile. Whether and which information sources, such as serial numbers or account data, are available and accessible is discussed in Section 2.1.2. We already briefly mentioned that smartphones offer a lot of sensors ready to be used by installed applications. The so provided information is also generally available to the ad provider through the ad-embedding application itself. That way it is possible to access unique identifiers for the smartphone itself, such as the IMEI and IMSI, or identifiers bound to the user account such as the mail address. Additional information such as geolocation data, nearby WiFi and GSM network identifiers or lists of running applications or contacts next to many other information sources can all be tied together and used to build a profile about the smartphone, respectively the user himself as it is uncommon that a smartphone is shared by more than one individual for a longer time. All this does not take into account personal and probably intimate information that are produced, consumed or stored on a smartphone. What about private messages exchanged with, e. g., the short message service, Twitter, Facebook or any other messaging service? What about pictures taken with the smartphone’s camera? The contact list or the call and browser history, let alone user credentials? All these information 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 also possible to deduce whether someone has a medical condition or to obtain his political attitude solely based on the call logs [181, 152]. How valuable such information is showed the recent acquisition of WhatsApp by Facebook [21]. $19B dollars were paid for a company of roughly 50 employees. What was so valuable for Facebook was the growth rate of this small messaging application having approximately 450

14 2.1 Why Mobile Security? million customers by the time of acquisition. But these customers were able to use WhatsApp for free for one year. After this first year further use was charged with 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 looking at these bare numbers of course blends out other factors but still shows how much personal data is worth. Additionally, WhatsApp was free of advertisements, so there was no direct income except for eventually paid annual fees (and of course venture capital). If Facebook is willing to pay so much money, there certainly are other 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 viewpoint or if an insurance would probably result in a deficiency. If an attacker gets hold of such data she could try to sell it at some underground market. A profile acquired that way may not be worth $42, but the underground offers user profiles (usually with login credentials) in bulk ranging from a few cents up to many dollar according to a study by Symantec [218]. High quality profiles and banking accounts are worth more money. Next to the vast amount of personal data stored and possibly accessible on a smartphone, there exists another unique “connection”. It is safe to assume that almost all smartphones are used with a SIM card by its user to be able to establish a mobile Internet connection. On the one hand, the SIM card itself is bound to one provider which offers cell phone services and enables the use of these. On the other hand it is also linked to a person (or company) who wants to use these services. This relationship enables the provider to charge the customer (the smartphone user in this case) for the used services. These normally include the short message service (SMS), telephony services as well as mobile Internet connectivity. How the customer is charged also varies and could include monthly fees or prepaid credit. This again looks attractive to a potential attacker because she is able to directly generate revenue by abusing this fact. If she could trick the provider’s customer into calling or sending short messages to a premium number that she set up, she would indirectly get access to the customer’s money. That is because her service is paid by the provider which itself gets the money back from the smartphone user. Abusing the short message services was a widespread scam in 2010 [50] where users were charged up to $5 for a single SMS which was silently sent by some malicious app which the user formerly installed after being tricked to do so. Attackers could also try to harvest other payment information, such as credit card numbers or online banking TANs which are processed by the smartphone—just like for normal PCs. Another opportunity for an attacker to immediately get monetary value out of stealing 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 2 Background: From Mobile to Security pay with these cryptocurrencies instead of “normal” money. The payment is usually performed with the help of smartphones which exchange data regarding the currency transfer with QR codes (Quick Response Code; other methods are possible, though). Without going into detail about the inner workings of such currencies, they are by design pseudonymous and unforgeable and whoever knows the secret key which is stored in the wallet has access to all digital coins related to that wallet. This and the recent rise in Bitcoin’s value to over $1000 in December 2013 [191] as well as the presence of exchange markets which also exchange to ﬁat currencies make such wallets valuable targets. Malware authors already target cryptocurrencies as was shown by Huang et al. [116] and the presumable theft of Bitcoins from one of the largest exchange markets Mt. Gox in early 2014 worth $480 million USD by that time [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 ﬁnd friends the application uploads the complete contact list to Facebook’s servers where they are processed to make some suggestions about known people. What about a weather app? It presumably has access to the Internet for downloading forecasts. In order to retrieve forecasts about the user’s region, it might also use the geolocation made available 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 some ads. In order to show ads which are interesting for the user, it might also access the geolocation and, e. g., advertise a local shop. We have to think about the privacy concerns in these scenarios. Who knows what happens with all the data after it “leaves” the smartphone. The weather application might also be a perfect tracker application which clandestinely spies on all the user’s movements while looking like an unsuspicious weather forecasts app. What if a car or health insurance company gets hold of this information? It can easily be deduced how fast someone drives on the highway and the insurance fee might be adjusted accordingly. Of course not all applications are malicious nor is the accessed information always abused in some way—but one should be aware of the consequences this might cause. The reader might take a moment and think about the potential privacy loss induced by large scale info gathering data mining operations as they have been reported to be feasible by state sponsored attackers [105]. Since smartphones are ubiquitous by now with a market share of 57.6 % for global mobile phone sales [92], somewhere between their advent and 2014 they also have become a malware target. Being at least as complex as a “normal PC” regarding their features and uses, this was an expected development. This can be easily seen in Figure 2.2 which depicts the monthly amount of malware seen for Android from early 2012 on. So where does that leave us with our initial question “Why mobile

16 2.1 Why Mobile Security?

160000

140000

120000

100000

80000 Samples 60000

40000

20000

02’12 05’12 08’12 11’12 02’13 05’13 08’13 11’13 02’14 05’14 Month

Figure 2.2: Monthly amount of previously unknown and unique malicious APK samples for the Android operating system seen by G Data, who also kindly provided this data. security?”. The rough overview sketched in this section should make clear, that the amount of data which has to be protected is tremendous while the potential to abuse it is huge. But regular solutions from the PC world such as a running Antivirus software are clearly not enough and also not the best solution because a smartphone is still a device with limited processing power and, more crucial, is battery powered. Running a full blown security suite which constantly drains energy from the battery and therefore further reduces the already limited runtime of 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 grained permission systems [64, 208, 45], control of information ﬂows [64, 173, 172, 76], shadowing real user data with bogus values [115] are only three examples of a huge puzzle regarding the security of smartphones. So mobile security refers to all these pieces and scenarios which make the phone smart while taking into account that it still is a phone. Let it be OS security or permission concepts for applications or studies about users’ behavior, who might not be able to assess the risks of installing

17 2 Background: From Mobile to Security unknown applications. Section 2.1.3 explicitly covers possible attack vectors and we also clarify more aspects of mobile security found on smartphones. We now present more details about several aspects of smartphones and topics related to mobile security. We start by giving an overview of smartphone characteristics followed by a quick evaluation of their security features. Then we look at possible attack vectors which might be exploited by attackers and ﬁnally summarize the evolution of mobile malware until recently.

2.1.1 Smartphone Characteristics

In this section we explain the main features which characterize smartphones. Due to the fact that several manufacturers produce many smartphone models with different features and operating systems, not every feature covered here can be found on every given model. The mobile market is a market of strong growth, therefore new features are generally added to new high-end smartphone generations and features which became more common are also made available in less expensive models. Albeit we are only interested in smartphones throughout this work, many discussed features are also relevant for so called feature phones and even “normal” cell phones. This section 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 x86 CPUs. The processors offer clock speeds up to 2.3 Ghz, depending on the model (e. g., the Snapdragon 800 [189]). The CPU is part of a SoC (system on chip) which also 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 multitude of sensors and interfaces, which are described next in the following paragraphs. Speaking bluntly, smartphones offer the computation power of a PC less than a decade ago but in a very small form factor.

Network Interfaces. The most important feature of smartphones are of course their ability to make phone calls and establish a mobile Internet connection with the integrated GSM and mobile broadband modem. Various generations (GPRS, UMTS, HSPA, LTE, . . . ) exist which oﬀer better connectivity options such as more bandwidth for newer generations. Additionally, smartphones are—like their predecessors—able to send and receive short messages (SMS) as well as multimedia

18 2.1 Why Mobile Security? messages (MMS). In addition to the aforementioned connectivity, they often also oﬀer interfaces to establish short range wireless connections over Bluetooth and WiFi interfaces. Although not exactly network interfaces, modern smartphones also feature communication with RFID and NFC transponders. IR interfaces used for communication which were common years ago are almost absent on smartphones.

Sensors. A smartphone is generally packed with multiple sensors which serve various purposes. We list the most relevant ones which should give a fair overview of what can be archived with the corresponding software which makes use of the sensor readings.

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

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

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 detecting whether something is near the display. It is, e. g., used to determine whether the user holds the phone against the ear while a call is established in order to turn oﬀ the display.

Light Sensor. This sensor is also often built into the front of the smartphone to be able to measure the ambient light intensity for automatically adjusting the display’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 used to quickly process abstract information which would otherwise be hard to input into the phone based on barcodes as well as QR codes. Most devices oﬀer 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 2 Background: From Mobile to Security

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], biometric sensors aim to directly identify a person based on, e. g., the fingerprint. The first smartphone offering this feature was the iPhone 5s [158].

Mobile Operating Systems. Although many different smartphone manufacturers and therefore models exists, the same is not true for their operating systems. By the time of writing, four major operating systems are widespread and from these only two are installed on the majority of all phones; namely Android by Google Inc. [98] which is available for a multitude of different smartphone models from different manufacturers and iOS by Apple Inc. [30] which is exclusively available for Apple devices. In December 2013 Android had a market share of 78.4 % while iOS had 15.6 % [92]. The other two players are Windows Phones by Microsoft [155] with a market share of 3.2 % and Blackberry OS by Blackberry Ltd. (formerly known as Research In Motion Limited or RIM) [40] with a market share of 0.9 %. While other 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 to be as power-conserving as possible. Meaning that even though the hardware is pretty 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 and takes into account the special form factor and input devices as well as available sensors. We do not discuss all the up- and downsides of the diﬀerent operating systems in this thesis. If speciﬁcs are of interest they are be mentioned in the appropriate sections.

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

20 2.1 Why Mobile Security?

3rd-party Applications. This is perhaps the most popular functionality smartphones offer: Enabling easy installation of additional software with more or less arbitrary functionality. It undoubtedly is a key factor for the success of smartphones in general. Being able to extend the functionality of a smartphone with a few clicks makes it “smart”. As already stated above, there is an application for almost every use case. We previously mentioned applications markets and now present more details about them. At least all major smartphone operating systems provide easy access to at least one official market where users can search for and install applications. Since the user in general cannot review the applications there might be some risks involved when installing an application from an unknown developer. The user of course also cannot review the operating system itself as well as the preinstalled applications, but we just assume that the user trusts those components—although multiple critical flaws were also found in those components [6,7]. We previously imagined a weather forecast application which could also track the user. The user’s chances of detecting such misuse is relatively small, as the only indicator is the requested permission set of the application, which explain in more detail in the next paragraph. Since attackers are constantly trying to spread malware and users cannot detect possible malicious apps, the market places should take care of it, as a trusted party of the user. And indeed, they are performing tests to detect malicious software. Google makes use of a service called Bouncer, which analyzes an application when it is uploaded to Google Play and looks for malicious activities and compares it against known malware [145]. While Google revealed some information about this process, Apple presumably uses a similar approach albeit concealing what they are doing. They claim to review all applications before they are made available in the market [29]. If an application does not follow all the guidelines2 they set up, it will be rejected. How the review process works is unknown, but applications by the time of this writing take on average 5 days until they are processed [207]. Other vendors typically also employ some analysis steps in order to detect malware, but details in general are also unknown. In order to prevent a flood of “useless” applications, a developer account in the official markets usually comes with some fee. Google demands an initial $25 and Apple’s fee is at $100 per year. Nevertheless, thousands of developers are offering their applications which the previously reported numbers of applications in the markets show. Few developers are of course security experts and therefore sometimes accidentally produce security problems. These might lead to vulnerabilities ranging from information disclosure to arbitrary code execution [42, 164]. In order

2 The guidelines are only available after a developer account has been created and are therefore not referenced.

21 2 Background: From Mobile to Security to detect such unintentionally introduced security bugs, as well as malware, several analysis tools exist which help an analyst in understanding the inner workings of an application. We describe analysis techniques in Section 2.2.

All major operating systems support code signing for their applications. If done correctly, a vendor can enforce that only signed applications distributed through oﬃcial channels can be run on the smartphone. Additionally, installed programs often run in a restricted environment and can only perform actions which are consent with given permissions in order to mitigate malicious activities. We describe these features in more detail in Section 2.1.2.

Nevertheless, if some malicious software was successfully sneaked into a market despite all precautions and users installed the malware, the market vendors might be able to automatically remove the oﬀending application from the smartphone without any user input or even consent. Google performed this action after the malware 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 brieﬂy covers fundamental security features mobile operating systems oﬀer. Since this is a very broad topic, we give just an overview and give details throughout this thesis in the following chapters whenever needed.

We ﬁrst write about authenticate mechanisms and then about how applications are sandboxed and how permissions work for applications. Afterwards we outline the concept of code signing and write about encryption mechanisms in general.

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

22 2.1 Why Mobile Security?

There exist several login mechanisms, but the major smartphone operating systems typically offer at least one of the following. • Patterns. The user has to “draw” a previously chosen pattern. If correct, he will gain access past the login screen. This mechanism is especially useful for touchscreens. 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 the pattern [31]. • PIN. The user has to enter a previously chosen PIN. Typically the user choses a short PIN because if the lock screen gets activated after a period of inactivity, the user desires quick access to the smartphone instead of more security. Since only numbers are allowed, the virtual keyboard is able to display an appropriate layout making the input procedure more easy. • Passphrase. Just like PIN, but this time all characters in additional to numbers can be chosen. Since the character set is larger, the virtual keyboard has to offer all the characters and the buttons are therefore smaller. This puts a burden on the user if the passphrase is long and consists of numbers, letters as well as special characters. Typically users seldom choose this mechanisms and if they do, chosen passphrases are often of poor quality [85]. A thorough evaluation and user study regarding login mechanisms for mobile devices was performed by Uellenbeck [225]. Next to the aforementioned authentication schemes 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 with bad intentions (briefly) accesses it. If a passphrase is chosen and if that is also used for decrypting the file system or parts of it, it better has to be of good quality as the 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 PC as well as on smartphones. The operating system kernel in collaboration with the hardware usually protects the address space of applications against other applications, makes use of address space layout randomization (ASLR) as well as enforcing that 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 root user which has restricted access to system components, e. g., based on the groups it is a member of. Some mobile operating systems also support policies which can be written to further prohibit applications from accessing, e. g., ﬁles which they not necessarily have to access. An example would be Android 4 which makes use of SELinux policies which add Mandatory Access Control (MAC) constraints to applications [175].

23 2 Background: From Mobile to Security

Most mobile operating systems additionally run applications in some sandbox which further delegates access to some API functions and adds additional security checks. Android for example runs most applications under a separate user id and inside the Dalvik Virtual Machine which provides a complete API for applications and delegates 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 process isolation, sandboxing and so on as this would be a topic on its own—other researchers have published work in this area, e. g., Xu et al. [240] or Dall et al. [61]. What is really special for mobile operating systems though is the concept of permissions to further enforce restrictions upon applications. Some functions or methods require the calling applications to possess some speciﬁc 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 to restrict access to certain information sources or hardware devices from an application’s perspective. While the implementations diﬀer, the goal is the same: The user should be able to decide which applications have access to which “features”. In general, a permission speciﬁes some information provider or function an application desires to use. That could be access to the contact list or the call history or the use of some hardware device such as the camera or the microphone.

Imagine a wallpaper application which accesses the complete contact list and uploads it to a remote server—the functionality is clearly not crucial for the application’s purpose 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 if a permission system is present, but he should at least be able to know that such a thing is possible, based on the granted permissions. In this example the application would need, e. g., the permission to change the wallpaper as well as to access the contact list and be able to open sockets. While not all of the exemplary permissions are available or controllable on each platform, the user could in this example see the “extended functionality” of the wallpaper application based on the requested permission set. Whether the application actually abuses the permission in such a way cannot be deduced from the permission set and they could also be of sole genuine purpose. The application may only use the granted permissions in order to advertise a wallpaper to a friend when the user choses to do so.

The operating systems typically restrict access to services which could be exploited by attackers and where misuse could have negative eﬀects for the user. This includes

24 2.1 Why Mobile Security? all functionality which occur costs, such as sending a SMS or establishing a phone call. Functionality related to sensitive or private information is also often controlled by permissions, e. g., serial numbers or databases storing contacts or chat messages etc. Access to certain hardware devices is also usually protected, e. g., the camera or the GPS sensor. We now brieﬂy describe the permission systems for the major operating systems. While their implementations diﬀer, the goal is always the same: regulate access to certain information and functions of the smartphone. How the permissions are enforced and how good each of the systems is is not elaborated in this thesis and we refer 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 asked whether the permissions the application requests should be granted. Depend- ing on the permission some warnings and implications might be displayed to point the user to possible misuse scenarios. If these are accepted, the application 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 installation time 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 or deny 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 a permission check exists. Windows Phone. Windows Phone does not know about permissions, but offers a similar approach called capabilities. Applications feature a set of capabilities which describe the intentions and demands of it. Software capabilities on the one hand specify, e. g., that the application is provided access to location services or the camera, just like their permissions counterpart. Rejecting particular capabilities while accepting others is also not possible, just as for Android permissions. Hardware capabilities on the other hand specify hardware 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 previous ones, but tries to archive the same goal: control what information and functions are accessible by an application. When an application is installed, it can be granted the trusted status, meaning it can access almost all information and functions. If it is not declared as trusted, it will work with a default permission set. Permissions can be set to “Allow”, “Deny” and “Prompt” just

25 2 Background: From Mobile to Security

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

If the permission system is well implemented and checks are performed by system components other than the application itself, some malfunctioning or even exploited application 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 protected functionality. We revisit this topic in Section 2.1.3 where we also talk about how smartphone users experience such systems. We provide statistics about requested permissions and how well developers make use of them in Chapter3.

Code Signing. A feature all major mobile operating systems support is code signing. Each application is signed with a certificate which the operating system trusts. Unsigned applications will normally not be installed and even development builds have to be signed, although a self-signed application might be acceptable in this case. Official markets always distribute applications which are properly signed. This establishes a unique connection between the application and the developer, as only he and probably the market vendor should have access to the private key. Depending on how strong the chain-of-trust is enforced, additional applications might only be installed through the official vendor’s channels, e. g., the trusted market application. Apple’s iOS for example only accepts signed applications distributed through Apple’s own market. Applications part of the boot process, the kernel as well as applications of the operating system are part of a trusted boot environment, meaning that an unsigned application will not be executed, including applications which shall additionally be installed. This is deemed as a security feature as it completely locks down the device and Apple has full control of which code runs on their devices since they also control the market. This is at least true in theory, but security experts found ways to circumvent the operating systems security features and were able to run code which ultimately disabled the chain-of-trust and defeated the secure boot procedure [77, 63]. This then enabled the execution of unsigned code and the introduction of external markets such as Cydia [119]. In general, this procedure is hard to 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 incorporate similar techniques though and, e. g., Microsoft goes a similar way with its Windows Phone as Apple does [109].

26 2.1 Why Mobile Security?

Encryption. In order to protect the confidentiality and integrity of data stored on the smartphone itself or data being received and sent, encryption mechanisms can be employed. While each application can provide its own encryption functions, it is 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’s GotoFail bugs illustrate which also affected many mobile devices [7,8]—at least they are (well) audited. These libraries can be used to establish SSL/TLS connections, manage encryption keys and to store encrypted data on the device. The operating systems also offer the feature to encrypt all personal data or even the complete hard drive. As this is a topic on its own, we do not provide deep insights about encryption mechanisms provided on smartphones in this thesis. We nevertheless report on some use-cases and how good provided encryption mechanisms perform in Chapter6.

2.1.3 Attack Vectors

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

Hardware-Centric Attacks. This category covers attacks against the hardware itself which also includes removable devices such as a SIM or SD card. The smartphone itself could, e. g., be attacked over not disabled JTAG connectors (Joint Test Action Group) to get (direct) access to the hardware, e. g., the processor in order to retrieve values stored in its registers. The SIM card could be the target of an attack as the communication between the smartphone and the SIM card can be intercepted and even changed. A device called TurboSim was used in the past to remove the SIM lock of an early iPhone model [39]. Forensic analysis techniques can also be applied to hardware devices. The complete contents as well as possible deleted ﬁles can be extracted if one has direct access to the SD card controller or the ﬂash chips [43]. A cold boot attack could also be executed to retrieve, e. g., cryptographic keys from memory [106]. This attack was also successfully performed on Android smartphones [163].

27 2 Background: From Mobile to Security

All these attacks are seldom seen, as they require direct access to the smartphone and sometimes even require modiﬁcations to the hardware itself like soldering cables to the JTAG connector or desoldering ﬂash chips.

Device-Independent Attacks. Attacks in this category are not directly related to smartphones, but to the services and protocols they use. Wireless connections to the mobile network which enable telephony services immediately come to mind. The cipher suites used to secure GSM connections have been broken which enables eavesdropping, impersonation attacks and DOS attacks. Attacks against it are well known [35, 41, 177] and were even extended to the communication protocols used by satellite phones [69]. DOS attacks could be executed if someone tries to exhaust special 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 immune to attacks [154, 186]. The same is true for WiFi connections established by the smartphone. Attacks against the used protocols are well known [220] and other communication protocols like Bluetooth are also affected [148]. Breaking cryptographic protocols in general is a topic that affects all the data which is encrypted on a smartphone. Stolen private keys for certificates of certification authorities or wrongly issued certificates [202, 59] are also an example which indirectly affects the smartphone (user), but are totally unrelated to the device itself.

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

Software-Centric Attacks. This category describes attacks related to software running on smartphones. This includes applications which are additionally installed by the user, applications and components provided by the operating system as well as software which is related to hardware tasks, e. g., the ﬁrmware of the GSM modem. Security relevant bugs can be found in all these layers and we give examples of prominent ones which were discovered recently. A general overview of diﬀerent bug classes reports on particular bugs are provided by several websites, e. g.,[9].

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

28 2.1 Why Mobile Security?

Although the market vendors claim to review the applications, bugs will always slip through this process and end up in applications installed on many smartphones. While most of the bugs are unintentionally “added”, some of them are security relevant for the end user. One example are so called confused deputy attacks, where one privileged application—the deputy—offers a service to an unprivileged application and is tricked into abusing its privileges. A special case of such attacks are permission re-delegation attacks [82], where the deputy holds additional permissions which 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 can be misused. A bug recently discovered in WhatsApp for Android allowed other applications to retrieve chat protocols after they were stored on the SD card where the operating system cannot easily enforce access restrictions [42]. Next to buggy software, 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 user is not allowed to modify the OS and its components. This somehow strengthens security because crucial components cannot be modified, but also weakens it if some bug opens up an attack vector while the user depends on the vendor to fix it. If one looks through bugs found in mobile operating system components, many of them are security relevant. Recently Apple shipped its standard SSL/TLS library with a bug which completely invalidated the signature check for established secure connections [8]. While the user could not count on secure connections anymore, he had to wait for Apple to release an update. Another example would be Samsung, which provided software to communicate with the modem with a “backdoor” which enables an attacker to gain file access to usually unreadable files [184]. It seems the backdoor was accidentally introduced into the code and is a good example of a confused deputy attack. Since some of the provided applications are heavily used by a great margin of the users, e. g., the default Web browser, security flaws in such products affect a great number of people. Security related bugs in the operating system can give 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 redsn0w for iOS [63]. Let us end this paragraph with security relevant flaws in software which directly runs on hardware components also found in smartphones, so called firmware. Typical devices would be the GSM modem, the WiFi interface or the camera. While the user itself usually never directly interferes with this type of software, it is still a crucial part of the smartphone and can offer attack vectors if the software is exploitable and can communicate with the smartphone in some way, e. g., over some bus system. Of particular interest are malicious removable hardware devices which are trusted by the smartphone when attached. One example would be SD cards, which can often be

29 2 Background: From Mobile to Security used to extend the phones internal storage capacity. Some cards can be flashed with a 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 as software in general can contain many different security relevant flaws, especially large programs. Again, a more detailed description can be found in the work of Becher et al. [38].

Layer-8 Attacks. This special category relates to the smartphone user and describes all non technical problems. “Layer 8” refers to the OSI model [118] where 7 abstraction layers describe the internal functions of communication protocols. Layer 1 represents the physical layer, describing the physical properties the protocol is based on ranging to Layer 7 which describes the application with which the user 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 attacking something. What use has a proper designed permission system for applications when the user just installs any application he wishes despite all permission warnings? What if the user just accepts all security relevant questions which pop up if something (bad) is about to happen? The best cryptography protocols just fall apart if the user is tricked into installing a fake certiﬁcate which is afterwards trusted by the operating system and enables an attacker to easily mount man-in-the-middle attacks against encrypted connections. Most users are not familiar with security in general and often do not understand complex systems such as smartphones. They are not able to deduce the implications of security relevant actions. Neither do they even want to care about such things, they just want things “to work”. A study conducted by Felt et al. [81] revealed that some Android users are not even aware that the required permissions are shown and have to be explicitly accepted before an application is installed. They just over-read the complete process because they know 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 it easy to trick people into doing things they should better not do—this is also known as social engineering. Preventing such attacks is a very diﬃcult task [157].

2.1.4 Mobile Malware

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

30 2.1 Why Mobile Security? as J2ME capable phones. It all started in 2004 with a few viruses and trojans for Symbian, 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. While some of the early samples were proof-of-concept viruses, others were already able to provide an attacker full remote control over the device. The functionality of the malware was getting better over the years, although almost no malware author had the goal to directly monetize a successful infection. Exceptions are RedBrowser and Wesber which send premium rate short messages as well as Pmcryptic which was released in 2008 for Windows Mobile and dialed premium numbers. A detailed list and a description of many malware families for these operating systems was compiled by Becher [37] which is also the source for the information previously provided in this paragraph. Coming back to smartphones, malicious software of course exists for all smartphone operating systems. Still, we focus on Android as explained earlier. In Figure 2.2 on page 17 we already visualized the constant rise of Android malware and now take a closer look at it. McAfee published a whitepaper where the “history” of Android malware is summarized until mid 2011 [50]. The following information is based on that whitepaper unless cited otherwise. It all started in August 2010 with a malware named FakePlayer, a SMS trojan. The application 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 is really simple, was not widespread and also was not available in the official market but still marks the beginning of an era of malware for Android. Before this very few malicious applications were to be found and these were either proof-of-concept ones or did not catch much attention at all. In the same month a game resembling the classic “snake” game was found. While the game was playable, in the background the malware collected and sent the GPS coordinates to a remote server. Another application could be purchased to view the stolen information on Google Maps, enabling someone to spy on someone’s smartphone. The malware was named Tap Snake after the game and is a typical example of spyware. While several other malicious applications were found in 2010, one is of particular interest. In the end of the year Geinimi was discovered, a malware much more sophisticated than the previous ones. It could be found in repackaged legitimate applications such as the game Monkey Jump 2 which were distributed in unofficial markets. It offered encrypted network communication and contained obfuscated code, both hindering its analysis. According to an analysis from Lookout [239] it is 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 2 Background: From Mobile to Security oﬀering botnet capabilities—something not seen before for Android malware. A fully working control server has never been observed, though. Still, Geinimi raised the bar for Android malware quite a bit and beginning in early 2011 many repackaged malicious applications were distributed mostly in unoﬃcial markets.

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

Then, in June 2011 a spyware named Plankton was found in many applications in the official market which was downloaded over 100,000 times. Directly after its detection, 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 used by software developers to monetize their applications in some way. The SDK adds code 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 could be classified as a very aggressive ad network. Additionally, it makes use of the DexClassLoader, a class loader provided by the official Android API. This class loader is used to download additional code from the Internet and execute it, making the application very difficult to analyze. It also features commands which can be run remotely, offering botnet capabilities. But, the applications did not behave like a typical malware, they only performed actions which were also described in their corresponding descriptions. Despite not being malicious per se, the software’s features are very malware like and absolutely suspicious and are therefore often classified as malicious.

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

32 2.1 Why Mobile Security? transaction which is performed on the PC. ZitMo is able to intercept such SMS and to silently forward them to the attacker, enabling her to secretly process transactions in the user’s name. Online banking customers are especially at risk if they perform it directly from a smartphone’s browser as the second “factor” for authentication might not be given anymore. If the smartphone is also the destination for SMS containing mTANs which are used to authorize online banking transactions, an attacker must only get access to one device—in this case the smartphone—defeating the purpose of a two-factor authentication. Then, in June 2013, a trojan named Obad was found by Kaspersky Labs who also provide a nice summary [227] on which the following information is based. Obad is capable of the usual functions trojans provide like sending SMS, stealing private data, installing additional software and so on. There are though a few things which make it really special. The malware contains code which exploits a bug in the analysis tool dex2jar [12] which is often used to analyze applications—therefore hindering its analysis. It also exploits buggy code in the Manifest parser (a file which contains information about the program, such as entry points or requested permissions) leading to a corrupted Manifest file which cannot easily be parsed by other tools but 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 which enabled the malware to gain Administration privileges although it does not appear in the list of such applications—making it impossible to remove it again. Exploiting three 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: All strings are encrypted and some crucial ones, such as the C&C server address, can only be decrypted if an Internet connection is available next to invoking methods over the Java Reflection API—again hindering (static) analysis attempts. The bot’s functionality enables the attackers to execute arbitrary code, spawn remote shells and to proxy connections through the smartphone to any remote computer. Obad also tries to spread itself via Bluetooth by copying a file to remote devices. This malicious software clearly raised the bar for Android malware and introduced a lot of features seen in advanced Windows malware families. Where does that leave us? The evolution of mobile malware exemplified for Android in this section clearly shows the need for proper analysis techniques. Smartphones contain so many datasets which attackers are eager to get their hands on, the user is often not aware of any security risks and the smartphone itself can be integrated into a botnet to serve attacker’s purposes, just like for normal PC malware. All in all, smartphones are a valuable target for malware authors. The rising amount of malware found in the wild tells the same story. Figure 2.3 exemplifies this with the steady growing number of known malware families for Android. Although mobile malware is not yet as sophisticated as Windows malware—we have not seen

33 2 Background: From Mobile to Security a single worm yet—, its complexity is getting better over time. Still, even simple malware applications or PUPs, which stands for Potentially Unwanted Program (see McAfee’s writeup [153] explaining the term in more detail), that “just” steal some information are attractive and are even successfully distributed over official markets. We therefore write about different analysis techniques for mobile malware to counter such threats in the next section and clarify our contributions in this field.

700

600

500

400

300 Known Families

200

100

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

Figure 2.3: Amount of known malware families for the Android operating system based on data kindly provided by G Data.

2.2 Analysis of Malicious Software

After reading the previous sections, it should be clear that there exists a need for tools in order to analyze smartphone applications, just like it exists in the PC world. In this section we describe program analysis approaches in general; speciﬁc analysis tools aimed for mobile applications are later covered in Section5. In general, there are two approaches to analyze an application: static and dynamic analysis techniques. Both are not restricted to smartphone applications and are usually applicable to all programs. We now ﬁrst describe static analysis techniques

34 2.2 Analysis of Malicious Software followed by dynamic ones. Thereafter we talk about their drawbacks and the problems that arise with these. Within this section we also point out which contributions we made in each of those research ﬁelds and revisit many aspects covered here in Chapter3 and5.

2.2.1 Static Analysis

Static analysis covers aspects of programs without the need of actually running the code itself. It is performed on source code or on compiled code. Since source code in general provides much more information such as proper names for, e. g., variables and methods and not-optimized code constructs, an analysis performed on it may produce better results. But source code is often not available, especially in the case for malware, and therefore many approaches also work with compiled code. Since the application is not executed at all, it is often not known which branches are taken and therefore which code paths will be executed, as long as such decisions can only be made during runtime. Despite this drawback, it provides the analyst an abstract view of the complete application. With the help of created Control Flow Graphs (CFG), the analyst is able to understand the inner workings of methods, since all non-branching instructions are represented 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 by directed 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 represent methods and directed edges represent called methods from those methods. While the CG can quickly become very huge depending on the application’s “size”, one can quickly locate entry points, uncalled methods and determine how values are passed between method calls. A third often used graph is the so called Program Dependence Graph (PDG). This graph represents which code constructs (data or code) are depending on which other constructs. Program Slicing [235] uses PDG’s in order to, e. g., detect which instructions affect a specific variable or register. With the help of PDGs so called use-def chains (for an explanation see Section 3.4.2) can be built which only contain those parts of the application which affect something of interest to the analyst. Next to the graphical representation of the program’s functionality, one can of course also make use of simpler approaches such as looking at strings, the amount of methods and so on, depending on the analyst’s goal. We cannot describe all possible static analysis techniques here but the interested reader might look into the work of

35 2 Background: From Mobile to Security

Nielson [167] as a stating point. We present the results of some of those techniques which we used to analyze Android applications later in Section3 and also present speciﬁc static analysis tools for the Android platform in Section5.

Our contribution in the ﬁeld of static program analysis is placed around Program Slicing. Since this is a very powerful analysis technique in general and no tool was available for Android by the time of conducting this work, we build a prototype called Saaf which introduces Program Slicing for Android applications. A speciﬁc scenario would be to, e. g., determine the telephone number and the text message of all calls to Android’s API which send short messages. That way the analyst could compare the text and the number against known premium numbers and subscription messages in order to see whether an application is potentially malicious or not. The tool and the techniques are described in detail in Section3.

2.2.2 Dynamic Analysis

Dynamic analysis involves the execution of a program—in contrast to a static analysis. 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 being taken. For these code paths, actual values assigned to registers and the like can be observed, resulting in a much less abstract view of the program with respect to the executed code paths. Dynamic analyses can also reveal the effects a running program 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 of malware often unwanted, dynamic analysis is often performed in emulators or virtual machines. Depending on the data of interest during the analysis step, the analysis component can reside in diﬀerent locations, e. g., the operating system kernel, some (injected) library, code injected inside the analyzed application itself or even in the hypervisor or hardware to name but a few. Depending on where and which data is gathered, the results can be coarse or ﬁne grained, ranging from, e. g., complete URLs 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, different 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 later roll back to it and also execute the non-taken path. That way, code coverage rises but this 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 diﬀerent inputs in order to reach all feasible paths. The size of the program tree quickly leads to the problem of path explosion, from

36 2.2 Analysis of Malicious Software which also multipath execution tools suﬀers, as its size grows exponential with respect to the branches. In order to tackle it, selective dynamic execution can be used to only execute branches of interest [56].

Since the program’s outputs are unknown prior to execution, an analyst might only be interested in speciﬁc actions the program might take. For smartphone applications it might be interesting whether the application reads contact information and sends it to some server over a socket. Detecting such scenarios is the goal of taint analysis [201, 76]: The analyst speciﬁes a set of sources (e. g., the contact list) and a set of sinks (e. g., a TCP socket) and the analyzer will taint all data read from sources 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 content providers are accessed, which IPC messages are exchanged or which sockets are opened. We later in Section5 describe many analysis tools speciﬁc to Android, but as for the static analysis approaches, we can also not describe the dynamic ones here in a thorough manner but instead refer the reader to the work of Willems [236] and Egele [71].

For this part our contribution took a completely diﬀerent approach. Instead of analyzing a running application on a smartphone or emulator in some of the “traditional” ways, we looked at one speciﬁc aspect which often cannot be found in normal execution environments, namely the battery and its limited energy supply next to the power consumption of the analyzed application. In theory, every executed instruction consumes some amount of energy which drains the smartphone’s battery—unless it is being charged. Our work described in Section4 evaluates whether certain (malicious) activities can be detected on a mobile device by only looking at their measured power consumption and comparing it to a previously generated power model.

2.2.3 Limitations

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

37 2 Background: From Mobile to Security

Despite these restrictions, other synthetic problems might be encountered. Static analysis gets much harder if the program is obfuscated. Depending on the level of obfuscation, some static analysis approaches might even be completely useless. If, e. g., each method invocation is only done indirectly, a Call Graph can hardly be generated. On Android, e. g., this is possible if the Java Reﬂection API is used to invoke methods and create new objects instead of the usual invoke and new-instance instructions. Dynamic approaches can be countered by code which detects the monitoring and consequently takes appropriate actions, such as letting the application crash 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 the tags or to not “overtaint” data [201].

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

2.3 Speciﬁc Security Aspects

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

Loss of Ownership. Since most people want immediately access to their smartphone 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 their monetary 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 serious implications for the designated owner since the ﬁnder now probably has access

38 2.3 Specific Security Aspects to the data which is stored on the smartphone, including personal data such as pictures and stored conversations let alone credentials. If the phone is not encrypted or even properly locked, such data is easily accessed and might end up in the wrong hands. Another study published by Symantec in 2012 [217] confirms such fears. The study reveals that 96 % of found smartphones were accessed and that 89 % of the finders accessed personal data and 83 % accessed corporate data. Although also 50 % contacted the owner in order to return it, private and corporate data is at risk if the smartphone is lost or stolen and not properly secured.

Display. Smartphones are used in almost all situations for arbitrary purposes. The main output and input device is the touch display—a very prominent part of such devices. Often, smartphone users are not alone and bystanders can easily see what is displayed and probably also what is inputted. This is called shoulder surﬁng and sensitive information might be exposed that way. Another risk pose so called smudge attacks [31]. The oily residues often left on the display after using it might expose, e. g., used login patterns which is a serious problem if the smartphone is lost or 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 hold for a complete day, depending on the usage behavior. This means that smartphones are often charged in order to be operational and people often attach their phones to foreign chargers or computers. Depending on the smartphone’s setup, the phone might immediately establish a USB connection and oﬀer mass storage device capabilities or similar functions (PTP or MTP modes) to the remote side. In the worst case even a debug connection can be established. If the charger is not trustworthy it 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 or malicious software could be uploaded to the SD card which is eventually automatically executed the next time a Windows PC is connected.

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

39 2 Background: From Mobile to Security

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

Under the aforementioned premise, we invented a tool called SmartProxy which utilizes the interface variety a smartphone usually oﬀers to easily connect it to a PC. This connection can then be used in a way that the smartphone acts a proxy for connections which are established by the PC, e. g., by the means of the web browser. Because the smartphone acts as a proxy it can also peek at the data exchanged between the PC and some remote server. Required credentials must not be entered into the untrusted PC anymore, but can be transparently injected by our proxy. This setup also allows us to strip security relevant information from the connection before it reaches the PC, e. g., cookies or a session id in a URL. A possible compromised machine cannot get hold of credentials or other security relevant data because they are never inputted nor do they reach it. That way we can enjoy the comfort the PC oﬀers while making sure our credentials are safe. We describe our solution in detail and also cover the aspects of encrypted connections in Section6.

2.4 Discussion

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

40 2.4 Discussion

The rest of this thesis is structured as follows. In the following chapter we introduce our work in the field of static program analysis. To be more precise, we present a prototype named Saaf which enables an analyst to perform program slicing on Android applications next to other analysis techniques. Afterwards, we present our works in the field of dynamic program analysis. In Chapter4 we evaluate how precise (malicious) activities can be detected by the means of the consumed energy of mobile applications. After the presentation of our contributions in the field of mobile program analysis, we evaluate how robust state-of-the art analysis tools for mobile applications are against software, which tries to thwart analysis attempts. We therefore present a tool in Chapter5 which obfuscates Android applications and hampers static as well as dynamic analysis attempts. With this contribution we show that many tools cannot analyze well-obfuscated applications and that there exists a need to adapt to the rising number of sophisticated malware samples. After we have presented our work in the field of program analysis we change our point of view in Chapter6. We present a prototype named SmartProxy which is able to provide secure use of a compromised PC with the help of a smartphone. Afterwards, we conclude this thesis in Chapter7.

3 Static Approach based on Program Slicing

We now present our work in the ﬁeld of static program analysis for Android applications. This chapter results from a publication [112] at the ACM Symposium on Applied Computing (SAC) in 2013 in cooperation with Martin Ussath, Michael Spreitzenbarth and Thorsten Holz. This work has been supported by the Federal Ministry of Education and Research (BMBF grant 01BY1020 – MobWorm). We would also like to thank Tilman Bender, Christian Kröger, Hanno Lemoine, and Teemu Rytilahti for their help on the created prototype and the analysis of the data.

Abstract. The popularity of mobile devices like smartphones and tablets has increased signiﬁcantly in the last few years with many millions of sold devices, as we already pointed out in the previous chapter. This growth also has its drawbacks: Attackers have realized that smartphones are an attractive target and therefore different kinds of malicious software for such devices have emerged. This worrisome development has the potential to hamper the prospering ecosystem of mobile devices and the potential for damage is huge. Considering these aspects, it is evident that malicious apps need to be detected early on in order to prevent further distribution and infections. This implies that it is necessary to develop techniques capable of detecting malicious apps in an automated way.

In this chapter, we present Saaf (Static Android Analysis Framework), a tool to analyze Android applications. Saaf analyzes smali code, a disassembled version of the DEX format used by Android’s Java VM implementation. Our goal is to create program slices in order to perform data-ﬂow analyses to backtrack parameters used by 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 ﬂow graphs or identiﬁcation of ad-related code are also implemented in Saaf. We present analysis results obtained by using these techniques for more than 136,000 benign and about 6,100 malicious apps.

3.1 Introduction

Within the past several years, the popularity of smartphones and other kinds of mobile devices like tablets has risen significantly, as discussed in Section2. This fact is accompanied by the large amount and variety of mobile applications (typically abbreviated as apps) and the increased functionality of the mobile devices themselves. Several mobile operating systems are available, with Android and iOS being the most popular ones. As a side effect of this popularity, centralized application marketplaces like Google Play and Apple’s App Store have massively grown. Such marketplaces enable developers to upload their own applications in a convenient way and users can download these apps directly to their mobile devices. Besides the official markets from platform vendors (e. g., Google and Apple) and manufacturers (e. g., Samsung and HTC), a large number of unofficial third-party marketplaces have emerged. Most of these markets contain thousands of apps and have millions of downloaded apps per month. For example, Google Play users download more than 1.5 billion applications each month and more than 1 million new Android devices are activated each day [99].

This fast growth rate also has a downside: Attackers have realized that rogue apps can be used to target smartphones and in the recent past, malware for smartphones became popular. According to G Data, during the second half year of 2013, almost 741,000 new malicious Android samples were seen in addition to the 520,000 seen ones from the ﬁrst half year (cf. Figure 2.2 on page 17). Symantec’s analysis of the Android.Bmaster malware [162] demonstrates the possibilities that an author of malware has: In this particular case, the amounts of money charged for a premium SMS that was sent by the malicious app is between 15 and 30 cents. Multiplying such small amounts with the number of potentially infected devices suggests that attacks against smartphones are a lucrative venue for adversaries. Unfortunately, it is hard to independently verify these numbers and objective measurements are missing. However, the often predicted rise of malicious software [38, 60, 130, 139, 140, 170] might ﬁnally come true given the recent developments.

Considering these aspects, it is evident that malicious apps need to be detected early on in order to prevent further distribution and infections. In addition, we need to consider 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 is important to develop eﬃcient and automated analyzing techniques that allow for a reliable assessment of an analyzed app.

We therefore present Saaf, a static malware analysis framework for Android apps that is able to recognize suspicious behavior patterns in an automated way. Saaf analyzes 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 robust analysis 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. introduced ded, a decompiler capable of analyzing about 94 % of the total classes in the applications studied. In contrast, Saaf is able to analyze all 140,000 applications as long as the smali code can be generated from the provided dex code (see Section 3.5 for more information and detailed analysis results).

Due to the prevalence and timeliness of malware for smartphones, this topic has received a lot of attention recently (e. g.,[62, 76, 74, 13, 251]) and our approach extends 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 given method. This enables us to identify suspicious code regions within a given app, we can for example detect whether a given app sends premium SMS in an automated way. Several other analysis techniques such as visualization of control flow graphs, a Manifest parser, and identification of ad-related code are also implemented in the tool. Based on our prototype implementation, we report on analysis results of more than 136,000 benign and about 6,100 malicious applications. We confirm several findings reported in other papers for smaller sample sets [74] and provide novel insights into the behavior of typical apps.

In summary, we make the following contributions:

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

• In an empirical study, we analyzed more than 136,000 benign apps and about 6,100 malicious ones. Our results conﬁrm observations previously reported for smaller sample sets and provide some new insights into typical Android apps.

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

45 3 Static Approach based on Program Slicing applications. We will then summarize our work and report on the limitations of our prototype in Section 3.6.

3.2 Related Work

Security aspects of smartphones have received a lot of attention recently and we are not the first to introduce analysis techniques for mobile apps. In the following, we discuss how Saaf relates to prior work in this area. We focus our discussion on other static analysis approaches, especially since many papers have been published in this area concurrently to our work. Afterwards, we also briefly discuss dynamic analysis techniques, which are basically complementary to our approach. Androguard is a toolset to decompile and analyze a given application, with the goal to detect malicious apps via signature matching [62]. We do not require decompilation, since this processing step might introduce imprecision in cases where the decompiler does not successfully reconstruct valid Java code, a problem that often occurs in practice [74]. Furthermore, Saaf does not only rely on pattern matching or static signatures and Androguard is not working in a fully automated way, which implies that 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 privacy leaks [127]. The authors evaluate ScanDal with a very small sample set containing only 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 will later present. Our evaluation set is three orders of magnitude larger and we expect that it provides a more realistic overview of the current threat landscape. Another tool closely related to our approach is ded, a decompiler that recovers source code of Android applications directly from their installation images [74]. The tool infers lost types, performs Dalvik VM to Java VM bytecode retargeting, and translates class and method structures. Furthermore, the authors studied 1,100 benign Android apps to better understand the security characteristics. Compared to 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, we are able to analyze all smali files which are generated by the android-apktool. Our analysis results are similar to the ones found by Enck et al. and confirm the findings reported on a larger sample set. Grace et al. demonstrate with their RiskRanker approach how to scan application markets for unknown malware samples [104]. Their approach is two-tiered: Within the 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 deals with obfuscated apps and tries to detect malicious apps that are encrypted or that load additional code. The system found 322 new instances of malware in a total set of 118,318 applications collected from various Android markets. The focus of Saaf lies on static analysis techniques and we implemented (among other program analysis techniques) a data-ﬂow analysis technique to determine which parameters of a method are static and might result in malicious uses.

There are several papers that touch on various Android-related topics and these papers also have a small overlap with our work. We brieﬂy discuss this kind of work but do not elaborate it in detail since the overlap is rather small. For example, Elish et al. implemented a static approach for malware identiﬁcation based on user-centric data dependence analysis [72]. DroidMOSS uses a fuzzy hashing method to detect repackaged apps in third-party Android markets [248]. The detection of privacy leaks and the unwanted access to user-related data on the Android platform has been explored extensively in the past. Some examples for detecting and mitigating these 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 similar research.

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 realtime analysis reports by leveraging Android’s execution environment. This system was complemented with a fully automated user emulation and reporting system by Lantz and is available under the name droidbox [13]. Both systems are unable to track native API calls and are slow compared to a static analysis approach like Saaf or the ones discussed above. DroidRanger implements a combination of a permission-based behavioral foot printing scheme to detect samples of already known malware families and a heuristic-based filtering scheme to detect unknown malicious apps [251]. With this approach, the authors were able to detect 32 malicious samples inside the official Android Market back in June 2011. Within their dynamic part, they use a kernel module to log system calls used by known Android malware. As discussed above, such dynamic approaches are complementary to our tool Saaf: static and dynamic analysis approaches can be combined to enhance the analysis results.

3.3 High-Level Overview of SAAF

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

47 3 Static Approach based on Program Slicing ical user interface and also supports automated analysis tasks such as automated unpacking and disassembling of applications. Furthermore, the tool can visualize the contents and code of a given app, and also offers several inspection tools to perform various program analysis tasks. In the following, we first provide a high-level overview of the features provided by Saaf and then discuss implementation details specifically related to data-flow analysis in Section 3.4.

Saaf covers an important aspect of an app analysis process: automated static analysis. Our implemented variant of data-ﬂow analysis [24, 87], namely program slicing [235], enables our tool to automatically search for constant values which are used as parameters in deﬁned method invocations. This way, the analyst can for example determine 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 is called static backtracking and we describe it in detail in the next section. All found constants are stored in a MySQL database or an XML report and are accessible for later analyses. Based on these results the analyst can, e. g., let some heuristic decide which apps are worth a more thorough inspection because they might exhibit malicious behavior: long sleep intervals, hardcoded telephone numbers, calls to sudo and so on (see Section 3.5.1 for more details).

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

• Navigate through the application contents which are presented in a tree structure. 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 method invocations require which permission(s).

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

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

• Saaf oﬀers 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 program’s functionality. They perform checks to output whether certain API method are used, e. g., the Reﬂection API, classloaders or the SmsManager.

48 3.3 High-Level Overview of SAAF

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

Figure 3.1 shows a screenshot of Saaf. What can be seen is the tree structure of the content and the code of one selected smali ﬁle. Below the tree structure is a list of all application entry points and on the right is a list of all methods within the selected class to easily navigate through it. The log output can be seen at the bottom. Figure 3.2 shows an exemplary control ﬂow graph of some application.

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

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

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

49 3 Static Approach based on Program Slicing

Figure 3.2: Exemplary CFG of Saaf. The shown code tries to send a short message and in the case when no exception is thrown returns the boolean true (left branch). Otherwise (right branch) it handles the thrown exception and generates a log message before returning. set is completed in less than 10 seconds on average. Sometimes the process is even faster, 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 software.

3.4 Static Backtracking

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

50 3.4 Static Backtracking able to send short messages to a hardcoded number or with any hardcoded message text—both of which indicate a suspicious usage of this feature. There are numerous methods with parameters which are worthwhile to analyze and we later present results from our analyses in Section 3.5. First, we describe the general workﬂow of our tool and then provide more detail on the implementation of the slicing process. Afterwards, we illustrate the workﬂow with an actual example.

3.4.1 General Workﬂow

Saaf is based on static analysis methods and thus the first step is to dissect Android applications. Such applications are packaged in APK files, which are more or less ZIP compressed files with the compiled bytecode, additional metadata such as the Manifest file, and additional resources such as image or audio files. Saaf unpacks these APK files in the following way in order to perform the data-flow analysis and further analysis operations: 1. The analyst loads an Android application (APK file) or specifies at least one from the command line. 2. Saaf unpacks the contents of the app and generates smali files for all classes of the Dalvik bytecode, using the android-apktool. Working directly on the bytecode enables us to obtain a detailed view of the code and overcomes limitations of tools that rely on decompiling the bytecode to Java code [74]. 3. Saaf then parses the smali files and creates an appropriate object representation of its contents. More precisely, we process the Manifest file, basic blocks of the methods, fields, and all opcodes. At this point, the static analysis can begin since all relevant information is unpacked and available in a usable form for further processing. Saaf will then perform the program slicing [235], which is explained in the next section. As noted above, our backtracking is a kind of data-flow analysis that specifically focuses on the analysis of method parameters to determine if certain parameters have static values that are relevant for the analysis process.

3.4.2 Program Slicing

In order to perform our backtracking of method parameters and to perform the slicing, a slicing criterion must be deﬁned. In our case, the criterion consists of the following information:

• method name and full classname of its corresponding class,

51 3 Static Approach based on Program Slicing

Source Slice int i; int i; int sum =0; int sum =0; int product =1; for (i =0; i < 10; ++i) { for (i =0; i < 10; ++i) { sum = sum + i; sum = sum + i; product = product * i; } } write(sum); write(sum); write(product);

Figure 3.3: Exemplary program slice. The slicing criterion is deﬁned 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 desired method 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 add new criteria. Such chains describe the use of a variable and all reachable definitions of it without any intervening definitions. Figure 3.3 shows an exemplary program slice.

We ﬁrst search through all invoke opcodes for matching ones. Afterwards, we translate the given parameter index to a particularly used register in the decompiled code (use information). We check the previous opcodes in the corresponding basic blocks and determine whether the opcodes perform some operation with the currently tracked register. In other words, we perform a backward slice. Generally speaking, we identify all opcodes that modify or use the tracked register and will backtrack all the interactions until we ﬁnd a constant (def information). We will explain in detail what is considered to be a constant in Section 3.4.4, the intuitive notion 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 been backtracked. The queue is initially filled with registers found during the first search for matching invoke opcodes and Saaf backtracks each register until the queue is empty. It is eventually filled as the logic finds opcodes inferring with the tracked register that make use of additional registers. The queue stores the register’s name and its exact opcode location in the program in order to backtrack it at some time later.

52 3.4 Static Backtracking

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. The same is true for all opcodes that put a result into the tracked register: All involved registers are added to the queue and are later backtracked. If the tracked register itself 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 require special handling in order to find constants of interest. We now describe how Saaf deals with some opcode classes and the involved registers and object references. We follow the general method of data-flow analysis and adopted it to the bytecode used within Android applications. Note that we do not explain the internal logic for all opcodes, as there are over 100 different ones. We have chosen the ones that explain the backtracking logic the most. Saaf itself handles all opcode classes and fully supports smali bytecode.

Method Invocations and Return Values. If the tracked register is part of the parameter 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), which is the case for, e. g., the Android API. Another case is introduced if the method invocation 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 corresponding method and backtracks the returned register. The backtracking continues at all return-opcodes and we search for constants that might get assigned to the returned register. The returned registers are added to the internal queue. If a method invocation is found, we always look at the method parameters, regardless of (1) or (2) being true. As a static analysis cannot correctly determine all possible states of a running program, Saaf will always additionally backtrack all involved registers (parameters) involved in the invocation. Note that this includes a reference of the object on which the method is invoked (if not static). This way, we do not miss any constants that might be related to the initially backtracked method parameter. An example where this behavior is relevant would be some kind of data structure, where values are added and internally “mixed up”, e. g., a string buffer. This way, Saaf finds all parameters of previous method invocations to this object, e. g., append(...), and eventually constant values. The only register that is not backtracked this way is the “this” reference for non-static invokes. This solution covers implicit method invocations such as constructors.

53 3 Static Approach based on Program Slicing

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

Furthermore, we record invoked methods that are unknown (i. e., no smali code is available) and have its return value assigned to our register as a result of our search. This way, we know that some method returned a value that is involved with the initially tracked register (parameter). This will yield methods that return relevant 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 the tracked register, we handle this array access in a special way. Furthermore, if the array is a class ﬁeld or a local array, additionally actions are performed.

Examining a class ﬁeld, we search for all opcodes in the whole program, which put some value into this array. We ignore the array index of such operations, as it might only be available during runtime. All found registers which have a value copied to this array are added to the queue. If the array is only local, we only search for opcodes inside the method where the array resides in. All found values that are stored in the array are treated as search results. If the array is the result of a returning 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 initialized with 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 a value assigned from a field, all opcodes that store something in the field are searched and their registers will be backtracked as well. The initial value of these fields is also considered as a constant and added to the search results.

54 3.4 Static Backtracking

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

Basic Block Boundaries. As all methods are divided into basic blocks, we often reach the beginning of these blocks. In order to find all relevant constants, the tracked registers will also be tracked in all previous basic blocks. Note that this covers 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 basic block). If this is the case, Saaf translates the tracked register to the given method parameter and starts a new search for all invokes to this method with the corresponding parameter index. This results in a new search in the same way as an analyst 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 marks our goal to find assigned constants in the bytecode which finishes our search for def information. All opcodes of the const-x type provide such information in addition to some others, e. g., mathematical operations or initialized fields and arrays. They assign constants to registers, e. g., strings or integers. In both cases the register will be overwritten and has an unknown semantically meaning before the assignment, which is irrelevant for our analysis. While the first one adds a resulting constant to our search, the second one only terminates our search for the corresponding register. If the register is overwritten with some reference, we will still see all involved constants 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 the search, if they are somehow linked to the tracked register v: • Fields and arrays with their types, names, initial and assigned values if a value is copied from them to v.

55 3 Static Approach based on Program Slicing

• Unknown (API) methods if they are called and return a value which is assigned to v. Known methods are part on the use-def chain and all return values are tracked. • Variable names and types for found constants. • Opcodes that overwrite v with something else, e. g., if an exception is moved to it. If such cases are found, they are added to the result set in a proper format and are tagged accordingly. We name them simply search results or constants for the rest of the chapter. These results store additional meta-information such as the line number, the filename, and other relevant information that is helpful during the analysis process. These search results reveal used values such as telephone numbers in the best case and show at least relevant information such as a called method which returns used data in other cases. If multiple constants are found for different parameters of one method call, e. g., the telephone number and the text part of the sendTextMessage(...) method, these constants are tagged accordingly in a way that the analyst knows that they are used as input for one specific invocation. Additionally, a path is stored which describes the “way” through the program, containing the (internally named) basic blocks, methods and classes which were analyzed in order to reach the constant from the slicing criterion.

3.4.5 Example

To give a small example of use-def chains, we provide a small Java program and the corresponding decompiled smali code in Listings 3.1 and 3.2. Both are shortened for the sake of brevity. If two slicing criteria for this program are set to search for the parameters destination number and message (1st and 3rd parameter) of the sendTextMessage() method in Android’s API, the following constants are identiﬁed (the f value corresponds to the fuzzy 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 3.4 Static Backtracking

Listing 3.1: Sample Java code. 1 private String number = "12345"; 2 3 public void work() { 4 StringBuilder sb = new StringBuilder(); 5 String s = "imei = "; 6 sb.append(s); 7 TelephonyManager tm = (TelephonyManager) 8 getSystemService ( Context .TELEPHONY_SERVICE) ; 9 String imei = tm.getDeviceId(); 10 sb . append ( imei ) ; 11 sendMsg(sb.toString()); 12 } 13 14 private void sendMsg(String text) { 15 SmsManager sms = SmsManager.getDefault(); 16 sms.sendTextMessage(number, null , text , null , null); 17 }

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

Note that our approach to track parameters in method calls where no smali code is accessible, e. g., API methods such as the aforementioned append(), might result in inaccurately identiﬁed constants. Nevertheless, this behavior is relevant for some data structures and the reason and implications where introduced in Section 3.4.3.

57 3 Static Approach based on Program Slicing

Listing 3.2: Sample smali code. 1 .field private number:Lj/l/String; 2 3 .method public constructor ()V 4 const−string v0, "12345" 5 iput−object v0, p0, Lxmpl;−>number:Lj/l/String ; 6 return −void 7 8 .method public work()V 9 new−instance v2, Lj/l/StringBuilder; 10 invoke−direct {v2}, Lj/l/StringBuilder;−>< i n i t >()V 11 const−string v1, "imei = " 12 invoke−virtual {v2, v1}, Lj/l/StringBuilder;−>append(Lj/l/String ;)Lj/l/ StringBuilder ; 13 const−string v4, "phone" 14 invoke−virtual {p0, v4}, Lexample;−>getSystemService(Lj/l/String ;)Lj/l/ Object ; 15 move−r e s u l t −o b j e c t v3 16 check−cast v3, La/t/TelephonyManager; 17 invoke−virtual {v3}, La/t/TelephonyManager;−>getDeviceId()Lj/l/String; 18 move−r e s u l t −o b j e c t v0 19 invoke−virtual {v2, v0}, Lj/l/StringBuilder;−>append(Lj/l/String ;)Lj/l/ StringBuilder ; 20 invoke−virtual {v2}, Lj/l/StringBuilder;−>toString()Lj/l/String; 21 move−r e s u l t −o b j e c t v4 22 invoke−direct {p0, v4}, Lxmpl;−>sendMsg(Lj/l/String ;)V 23 return −void 24 25 .method private sendMsg(Lj/l/String;)V 26 const /4 v2 , 0x0 27 invoke−static {}, La/t/SmsManager;−>getDefault ()La/t/SmsManager 28 move−r e s u l t −o b j e c t v0 29 i g e t −object v1, p0, Lxmpl;−>number:Lj/l/String ; 30 move−object v3, p1 31 move−object v4, v2 32 move−object v5, v2 33 invoke−virtual/range {v0 .. v5}, La/t/SmsManager;−>sendTextMessage(Lj/l/ String ;Lj/l/String ;Lj/l/String ;La/a/PendingIntent;La/a/PendingIntent ;)V 34 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 consists of 6,187 samples of old and new malware samples, and should cover samples from most of the known malware families. As long as the android-apktool is able to generate 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 sometimes needs additional files (resources or framework files) in order to successfully decode a 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.20 READ_PHONE_STATE 77.51 ACCESS_NETWORK_STATE 52.08 SEND_SMS 63.69 WRITE_EXTERNAL_STORAGE 34.01 ACCESS_NETWORK_STATE 52.63 READ_PHONE_STATE 32.46 WRITE_EXTERNAL_STORAGE 48.07 ACCESS_COARSE_LOCATION 22.98 RECEIVE_SMS 40.32 ACCESS_FINE_LOCATION 22.42 RECEIVE_BOOT_COMPLETED 36.90 VIBRATE 18.05 READ_SMS 22.42 WAKE_LOCK 12.36 ACCESS_WIFI_STATE 21.45 ACCESS_WIFI_STATE 11.01 VIBRATE 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 analysis is feasible. Other tools which also rely on smali code or even Java code generated from smali code, face the same problem. The evaluation was performed on two diﬀerent servers, one was equipped with an Intel Xeon E5620 2.40GHz CPU and one with an E5630 2.53GHz CPU. Both have 24GB of RAM and no SSDs. For the rest of this chapter, applications from the crawled Google Play platform will be typically referred to as samples from the market and 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 used features for benign and malicious applications.

Android Permissions. We analyzed the permissions used by both types of applications and present the results in Table 3.1. Analyzing the permissions reveals the permissions one would expect for malicious applications: Almost all applications have the permission to access the Internet and most of the other permissions grant access to sensitive information like the various identiﬁers of the phone and, more importantly, to read and send short messages. Since criminals attempt to generate revenue from premium short message services, it is obvious that the corresponding permission is placed third in the total ranking. The only exception is the last permission, VIBRATE, which seems to be a remnant from trojanized popular games which can often be found in third party markets. This assumption is backed up by

59 3 Static Approach based on Program Slicing the fact that this permission is also ranked high in the analyzed applications from the Google Market.

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

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

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

IMEI/IMSI. Many app authors use the IMEI and IMSI number from a device as a unique identiﬁer. While 53 % of the malware determines at least one of these numbers through the appropriate API call, only 23 % applications from the market set do so. These numbers seem rather small, but compared to the applications which have 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 one year old and the strategies of included ad frameworks have changed since, as one would expect a higher amount of these unique identiﬁers.

Executed Commands. We also backtracked the strings that are passed to the exec Android API method, which executes a command in a command shell. We found that malware mainly uses this function to call the su binary in order to install applications, remount partitions, or to enumerate running processes. Executing such commands with elevated privileges is crucial for the malware to obtain a higher level of 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 this function. Since many people root their smartphones to gain access to additional features, this percentage looks reasonable.

SMS API Usage. Finding applications that are able to send short messages to hardcoded numbers and possible hardcoded content might give a strong clue to classify such software as malicious. A total of 54 % applications call such API methods in the malware set, while only 3.4 % do so in the market set. This huge number for malicious applications seems reasonable, as a lot of samples were found in recent time which abuse premium number services. While there are also legitimate use cases, a small amount of the applications in the oﬃcial market also make use of this feature, e. g., an SMS forwarder application. The following numbers are an excerpt from the numbers Saaf found during the analysis phase, all of them representing premium numbers that were identiﬁed 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 identiﬁers for Android System Services for all applications, determined by the parameter used for the API method Context.getSystemService(...). Malware uses the TelephonyManager service the most, which is requested by the identiﬁer “phone”. This service has many methods which reveal a lot information about the state of the phone, whether a data connection is established, which network the phone is connected to, serial numbers, country codes and so on. Because many malware samples send short messages to premium services, the software often determines the country the phone is currently located, so the right premium number can be chosen; otherwise the premium rate service number might not be

61 3 Static Approach based on Program Slicing

Table 3.2: Top 10 system services. # Malware Market 1 phone window 2 connectivity layout_inflater 3 notification location 4 layout_inflater phone 5 activity connectivity 6 alarm audio 7 location input_method 8 input_method notification 9 window sensor 10 audio vibrator available if chosen wrongly. The ConnectivityManager—which is requested by the id “connectivity”—serves a similar role as the TelephonyManager regarding network connectivity 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 layout states, which the ﬁrst two used system services reveal for this sample set. The third entry “location” refers to the LocationManager. It is used to request the phone’s location based on GPS or network coordinates. Most ad frameworks make use of this feature to serve targeted ads to the user.

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

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

We were interested in the average amount of time applications use the method Thread.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 speciﬁes how many milliseconds the calling thread should sleep. We calculated the average value of all obtained values which are between 0 and 86,400,000 (24 hours) and which have a fuzzy level of 0, i. e., are absolutely accurate backtracking results. The ﬁnding is very interesting, because both sets have very similar values. While malware goes to sleep for 21.9 seconds on average, market applications do so for 22.9 seconds. We have not analyzed why the results are almost identical and leave it for a future evaluation. As a last note, we found values that were negative—which should produce an exception during runtime—or extraordinary high (many days or weeks up to years).

Loaded Libraries. Looking at the search results for libraries which are called by the analyzed 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 the Android command-line shell. We additionally found suspicious identiﬁers for loaded libraries such as ScanVirus, VirusBackRunner, ScanController and scan_engine which indicate that the malware might be related to some kind of fake anti-virus campaign, a popular attack vector in the desktop computer world [215] that recently became 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 (3D engine).

Java Reflection. Saaf evaluates whether an application loads classes or calls methods with the Java Reflection API. There are many legitimate use cases for this which we will not describe in this chapter, but reflections can also be used to obfuscate the control flow, since no method invocation can be observed if a method is 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, as the following exemplary classes are loaded throughout this sample set:

• android.os.SystemProperties,

• telephony.SmsManager,

• android.telephony.cdma.CdmaCellLocation,

63 3 Static Approach based on Program Slicing

• java.net.InetAddress, and

• android.content.pm.PackageManager.

Eﬀectively, the malware samples use reﬂections to hide the fact that they want to access sensitive APIs. On the other hand, market applications mostly use the API inside the included ad frameworks.

Intents. In the Android operating system, intents are used to perform special actions and to communicate with (other) application components. For the malware set, the two most commonly used intents clearly indicate the program’s purpose, namely SMS_SENT and SMS_DELIVERED (without a package preﬁx). In contrast, the market 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 data exchange over the HTTP(S) protocol, some developers chose to create plain sockets to communicate with some end point. If security matters, they hopefully encrypt the data. Android provides the widely used SSL/TLS protocol for such cases. Creating a secure socket is rather easy, but old Android versions by default chose a ciphersuite that 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 or EXP-RC2-CBC-MD5. This behavior was changed in later versions, but Android 2.2 was quite common when the market applications were crawled. In June 2014 the market share of this version diminished to below 1 % [28], but the mechanism can be used for other use-cases.

For us, it is interesting to see how many applications create SSL sockets and how many manually set the ciphersuites. We found that 153 malware samples do so and 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 also available for old devices, as it might introduce severe security implications, e. g., an attacker could perform a man-in-the-middle attack and trick the application into accepting a weak ciphersuite.

64 3.5 Evaluation

Content Provider. Most of the data stored on Android devices can be accessed through so called content providers. To access data, a developer has to form a URI which speciﬁes the desired content. An example for the calendar would be content://calendar/calendars. The provider parses this URI and will serve requested data from the according data structures, and it additionally ensures that required 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 diﬀerent content providers such as the calendar, contacts, and SMS/MMS databases. The most accessed content by malware samples is related to the SMS/MMS providers, by a large margin. 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 code which is not available in Java bytecode but is located in native libraries, e. g., .so shared objects. We found that 9.43 % of the malicious apps perform such calls and 4.61 % of the market applications do so.

Another feature of Java and Android is the ability to load classes from arbitrary destinations, 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. On the contrary, 22.05 % of the apps from the market do so. This high number seems very unlikely, so we invested how many apps contain code which uses classloaders and 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, but seeing this feature as a typical one for malicious apps to evade detection or analyses seems vague.

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

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

65 3 Static Approach based on Program Slicing

Listing 3.3: Patched code to circumvent copy-protection mechanisms. 1 [METHOD] n.d:(Ljava/lang/String ;)Ljava/util/Map; 2 new−instance v0, Ljava/util/HashMap; 3 invoke−direct {v0}, Ljava/util/HashMap;.:()V 4 const−string v1, "VT" 5 const−string v2, "9223372036854775807" 6 invoke−interface {v0, v1, v2}, Ljava/util/Map;.put:(Ljava/lang/Object;Ljava/ lang/Object ;)Ljava/lang/Object; 7 const−string v1, "GT" 8 invoke−interface {v0, v1, v2}, Ljava/util/Map;.put:(Ljava/lang/Object;Ljava/ lang/Object ;)Ljava/lang/Object; 9 const−string v1, "GR" 10 invoke−interface {v0, v1, v2}, Ljava/util/Map;.put:(Ljava/lang/Object;Ljava/ lang/Object ;)Ljava/lang/Object; 11 return −o b j e c t v0 12 new−instance v0, Ljava/util/HashMap; 13 invoke−direct {v0}, Ljava/util/HashMap;.:()V 14 new−instance v1, Ljava/net/URI; 15 new−instance v2, Ljava/lang/StringBuilder; 16 invoke−direct {v2}, Ljava/lang/StringBuilder;.:()V 17 const−string v3, "?" 18 [ . . . ]

Repackaged Applications. Saaf does some internal sanity checks while performing the backtracking process in order to ﬁnd logic bugs. One thing we stumbled upon 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 and returns in line 11 and therefore never executes everything below that instruction. Finding such code constructs yielded an error as everything below the return-opcode would be dead code and should not be produced by the compiler. We investigated this issue believing our code did something wrong.

As it turned out, the smali code was correctly parsed and the basic blocks and the CFGs were also correctly built according to our rules. Looking at these specific applications, 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 a message that it was cracked by some release group. Looking at the method names which contain such code structures further bolstered our assumption. For example, some method names are checkAccess, GetIsAppLicensed or simply allowAccess and often return a boolean. Saaf will report such findings through so called quick checks which can be enabled in the config file. These were briefly introduced in Section 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 information might give another hint to an analyst whether an application in question might be malicious. This detector flags classes and whole applications as possibly obfuscated and also highlights these in the GUI. As the metric for deciding whether a class is obfuscated or not, the median lengths of the field and method names were used. Unobfuscated packages yielded medi- ans between 6 and 11, while the corresponding median for obfuscated classes with ProGuard [134] was 1. This is not surprising considering the fact that ProGuard uses short names consisting of letters in alphabetical order, therefore giving a huge number of short identifiers for both methods and field names. While a lot of analyzed packages ship several external libraries, it does not seem to affect the final results for a complete application. Nevertheless, the most commonly used libraries such as advertising services and libraries from projects such as Apache could be excluded from the results in the future. The same approach could also be tested against other possible obfuscation methods such as DexGuard [198], which introduces comparably more advanced obfuscation techniques. Our current implementation can reliably detect ProGuard-obfuscated apps, but might fail for other tools.

3.5.2 Malware Analysis

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

DougaLeaker.A. The ﬁrst sample we report on was initially discovered in April 2012. 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 manual analysis revealed that the data is sent to the ﬁrst found URL.

Rufraud. The next sample belongs to the Rufraud family and presents itself as the popular game Angry Birds. The sample itself is a fake installer and sends premium 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. Depending on the country the user resides in, the malware sends premium SMS to diﬀerent

67 3 Static Approach based on Program Slicing 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 of the messages. Instead, a string (E273FED8415F7B1D8CFEAC80A96CFF46) is found which is used to decrypt the message text that is supposed to be sent. The results additionally reveal that the sample checks whether the messages were successfully sent or not, as the strings SMS_SENT and SMS_DELIVERED indicate, which are passed to the Android IntentFilter class. Such results give a strong hint that the analyzed application has malicious intents.

Gone in 60 Seconds. As a third example we provide an overview of three variants of the GI60S “malware” that appeared in September 2011 on the oﬃcial Google Market. This malware copies private information as the SMS database and contact details from a phone to a remote location. The user is then presented with an access code which enables him to see all the stolen data and the application removes itself. All this happens in less than 60 seconds, hence the name. For each sample Saaf found several constants, the most interesting ones being an URI to query 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. These results indicate the desired functionality of this particular application. It accesses the 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 to obtain an initial overview of a given Android app.

DroidCleaner. The last sample we report on is also known as as Superclean. This genuine 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 of gathering and forwarding a bunch of information about the infected device. The malware author can also forward and delete arbitrary files, send and receive SMS, phish for passwords, and control some device settings. Another interesting feature is its ability to infect a connected PC by downloading and storing files on the SD card which are possibly automatically run by a Windows system if the smartphone is used as an external storage device. The software makes use of a command dispatcher which is accessed over the network. More detailed analysis reports are available on the Internet [230]. In our analysis we were interested in the supported commands which can be be run over the network. It turned out that Saaf can easily extract the possible commands from this dispatcher. Creating slicing criteria which backtrack parameters of the String.equals() and String.startsWith() methods quickly returned

68 3.6 Discussion command strings. Among those were the following ones which deﬁnitely give an insight 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 previously mentioned in this section. All checksums were calculated on the APK ﬁles. DougaLeaker.A 91d57eb7ee2582e0600f21b08dac9538

Rufraud 95a04cfc5ed03c54d4749310ba29dda9

Gone in 60 Seconds 8d4018a73a35e079aba1d0fd8a06e522 cb236442cf93a47bc15e3f312f097992 859cc9082b8475fe6102cd03d1df10e5

DroidCleaner / Superclean b0c28334373332d4677c01bd48eed431

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 applications and mainly performs data-flow analysis based on program slicing to analyze the structure of apps, but is also capable of performing other kinds of analysis. We surveyed a large collection of Android apps and malware, and our evaluation results confirm some insights previously obtained on smaller sample sets [74]. We were able

69 3 Static Approach based on Program Slicing to find destination numbers as well the text parts of outgoing short messages, the usage 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 course also has some limitations. Being a static analyzer, it has all the drawbacks static analyzers have in general [159]. For example, information available only at runtime is not available, and the usage of encryption methods and obfuscation put a heavy burden on such tools. Despite these general drawbacks that Saaf shares with other static 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 often also the called class and method, Saaf currently does not backtrack into methods found this way while backtracking a register. Despite the effects of heavy obfuscation and dynamic code loading, the analyst can easily see if and to what extend such features are used as the automatic analysis will reveal these. Such indicators might give a strong clue of the intents of an application. The fact that Saaf is able to analyze 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 something is missed. For obvious reasons, we have been unable to check all found results against expected results.

70 4 Dynamic Approach based on Power Consumption

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

Abstract. With the ever rising amount and quality of malicious software for mobile phones, multiple ways to detect such threats are desirable. Next to classical approaches such as dynamic and static analysis, the idea of detecting malicious activities based on the energy consumption introduced by them was recently proposed by several researchers. The key idea behind this kind of detection is the fact that each activity performed on a battery powered device drains a certain amount of energy from it. This implies that measuring the energy consumption may reveal unwanted and possibly malicious software running next to genuine applications on such a device: If the normal energy consumption is known for a device, additional used up energy should be detectable.

In this chapter, we evaluate whether such an approach is indeed feasible for modern smartphones and argue that results presented in prior work are not applicable to such devices. By studying the typical energy consumption of diﬀerent aspects of common Android phones, we show that it varies quite a lot in practice. Further- more, empirical tests with both artiﬁcial 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 mean error rates of state-of-the art measurement tools.

4.1 Introduction

In the last years, smartphone sales began to rise significantly and also the number of malicious software for these devices grew as we have shown in Chapter2. As a result, several techniques to analyze smartphone applications emerged with the goal to detect and warn users of unwanted software. Most solutions are based on classic 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 by a battery and the insight that every performed action drains a specific amount of energy from that battery, the idea came up to measure the consumed energy and to deduce from that data whether any unwanted (malicious) activities occurred, possibly hidden from the user [126, 144]. The developed tools use the system API or additional external devices to obtain information about the battery status, running applications, actions performed by the user (if any), and calculate the normal amount of energy a clean device should consume under such circumstances. This model is then used in the detection phase to compare live measurement data against it in order to detect additional activities. Such a method could—at least in theory— detect software that was loaded onto the device or applications that suddenly behave in a different way.

The proposed prototypes [126, 144] were implemented and tested on feature phones with a limited amount of additional installable (third party) applications compared to the “application markets” of today’s smartphones. Furthermore, the devices themselves were equipped with considerably less features and sensors, such as an accelerometer, GPS, WiFi, large touchscreens, or a full-blown browser. Compared to a modern smartphone, feature phones oﬀer less possibilities to a user.

Throughout this chapter, we attempt to verify or disprove the possibility to detect malware on modern smartphones based on their energy consumption. We use a specialized tool named PowerTutor [245] to measure the energy consumption of several potentially malicious activities in both short and long time test scenarios. We evaluate the energy consumption for each action and the energy consumption for the complete device based on the reports provided by PowerTutor. Our short time tests 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 scenarios that can be found on smartphones used every day. We measure the impact of classic malicious 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 possible in order to commit some kind of denial-of-service attack. We implement our own proof-of-concept malware that accomplishes our malicious tasks and we validate our findings with two real-world malware samples. Our main contribution is the evaluation of a method to detect malicious software that was conducted in the first place on “old” feature phones rather than on modern smartphones. We argue that the proposed methods do not hold in practice anymore and study in detail how a modern Android phone consumes power. We show that the energy needed to perform relevant malicious activities, such as stealing private data, is too small to be detectable with the mean error rates of state-of-the art measurement tools. The remaining of this chapter is structured as follows. We first discuss related work in Section 4.2 in order to introduce the used tools and the aforementioned proposed 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 in Section 4.8.

4.2 Related Work

Since we want to (dis)prove that malware detection is possible on a modern smartphone by measuring its power consumption, we first discuss related work in this field. Kim et al. introduced the idea of detecting malicious software based on its power consumption [126]. They built a prototype for phones running Windows Mobile 5.0 that works with power signatures. These signatures are based on the power consumption of a program rather than its code or exhibited behavior. In order to be useful to the enduser, a signature database has to be available. This circumstance does not allow the detection of new and unknown malware, as no signature is 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 system is profiled. Then, in a second step, the actual used energy is compared against the learned profile and if a certain threshold is reached, the systems alerts the user that additional (maybe malicious) activities have been performed on the phone.

73 4 Dynamic Approach based on Power Consumption

Throughout this chapter, we perform similar tests not on features phones but on modern Android smartphones and evaluate to what extend malicious activities can be detected (if any). Work by Dixon et al. shows that the location has a huge impact on the user’s activities [65]. Leveraging this information, the average power consumption for different locations can be computed that could then be used to detect anomalies in the power signature for these locations if, e. g., malware performs additional operations next to the expected power consumption introduced by a user. A study performed by Balasubramanian et al. [32] analyzed the tail energy overhead introduced by trans- fers over the wireless connections offered by smartphones. Although they measured the used energy for different connection types, they focused on the amount of energy that can be saved if a special protocol is used by applications that make use of wireless connections. Dong et al. propose Sesame, a tool that is able to generate a power model for smartphones and notebooks and the underlying hardware, battery, usage etc. by itself without external tools [67]. They argue that factory-built models are unlikely to provide accurate values for different scenarios, such as different hardware or usage patterns. Since all such tools need to measure the used energy in one or another way, work related to this task is also relevant for us. The first tool, called PowerTutor [245], was designed to provide a precise report of energy spent on a smartphone. This report includes the power consumption of sole devices such as the NIC or the display. In order to provide a very detailed power model for an analyzed application, a power model for the used mobile device has to be calculated in the first place. This model was generated with the help of specialized hardware that precisely measured the power consumption of the device under certain circumstances. Since these models are bound to the device, accurate results with a claimed long-term error rate of less than 2.5 % for an application’s lifespan can only be provided if PowerTutor runs on such a “calibrated” device. PowerTutor runs on Android, requires no changes to the operating system and the Android framework, and its source code is freely available. Next to PowerTutor, a tool called eprof was introduced to measure the power consumption of a given app on Windows Mobile and Android smartphones [183]. It is also able to provide a breakdown of the power consumption of sole methods inside applications. This is possible because eprof works on the system call level: All I/O operations that consume energy from internal devices are realized through system calls performed by the application, e. g., sending a packet over the mobile Internet connection through the GPS modem. This enables a precise measurement of the energy 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 of eprof claim an error rate of under 6 % for all tested applications in contrast to an error rate of 3–50 % for utilization-based methods. Furthermore, eprof can be used to measure which application components use what amount of energy [182]. The tool is not available and the authors describe changes to the OS kernel, the OS/Android framework, and the analyzed application itself. Yoon et al. recently proposed another tool named AppScope [243] to measure the energy consumption on Android smartphones. Their monitoring software is able to estimate the energy consumption on a per app basis in a similar way as PowerTutor by making use of a kernel module that hooks and reports certain events on the syscall 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 or access 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 information.

4.3 Measurement Setup

To measure accurate power consumption traces for several use cases on a modern smartphone, we first have to chose a stable setup under which all studies are performed. Furthermore, we need some way to actually generate accurate power measurements and we need a tool that performs defined actions that consume power. Our tool of choice to measure the power consumption is PowerTutor [245], which was 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 for our calculations throughout this chapter. Since we want to verify if a software- based detection mechanism is capable of detecting additionally installed malware on a smartphone, we cannot make use of any hardware-assisted measurement mechanisms. Such additional devices (note that the phone itself is not capable of doing this with the exception of reporting an approximate battery charge level and voltage) would severely reduce the user acceptance to perform such measurements at all. Since end users are the target of such a software as they shall be protected from malicious software, it should be a purely software based solution as one would expect from traditional AV software products. We chose PowerTutor over eprof because we have access to the tool, the mean error rate is comparable, and we are able to generate good measurement results despite using a utilization-based measurement

75 4 Dynamic Approach based on Power Consumption method since we have control over the test system (i. e., we can control how much parallel interactions occur, see Section 4.4 for more details). In the following we describe our software which we used for our test cases and explain the choice of our used smartphones.

4.3.1 Application

We now describe how we perform the power consumption measurements of different smartphone features. Since the main contribution of this work is to (dis)prove the possibility to detect malicious software due to its power consumption, we wrote a 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 power consumption is measured by PowerTutor. Our proof-of-concept malware is able to perform the following functions in order to evaluate what features or combinations of features are detectable. It can send and receive SMS; make use of the location API; access content providers, e. g., contacts and SMS database; send arbitrary (encrypted) data over the network; access serial numbers, e. g., the IMEI; record audio; set Android wake locks to control the power states of the CPU and the screen; and run in an endless loop to put a heavy burden on 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 disrupt operational time of the smartphone is easily imaginable. The measurement results for these functions or a combination thereof are later evaluated in order to see whether such activities are detectable by the amount of consumed power, similar to the 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 are requested in the application’s Manifest file. It basically consists of a control program that initiates an action over the network and a service which performs it. Actions can be run once, repeated in an interval, delayed and so on. This scheduling is performed with the help of the Android AlarmManager. All actions are performed by the service and are therefore performed without any GUI elements. This is crucial for the measurement step, as PowerTutor accounts the power consumption of GUI elements to the appropriate app. They influence the displays power consumption for OLED displays and, additionally, foreground processes have a higher priority than background processes within Android. The power consumption of this test malware will 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 this is that this phone was explicitly tested and used by the PowerTutor developers, saving us from calculating our own power model for the smartphone. They used three different phones, but the Nexus One is the newest one and is upgradeable to a 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 power consumption 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 of PowerTutor. All tests are performed by this phone unless stated otherwise. We additionally performed some tests with a Samsung Galaxy Nexus phone in order to validate our results. This was the latest Android developer phone available by the time 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 being called “HD Super AMOLED”, next to some additional sensors and it is used for validation purposes (although PowerTutor measurements might be less accurate due to a missing calibration). The phone’s remaining battery capacity and its runtime can 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 order to ensure maximum battery lifetimes. Note that our setup suffers from the same problems all such systems have, e. g., the reported battery capacity and voltage may change a lot due to different parameters [180].

4.4 Short Time Tests

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

77 4 Dynamic Approach based on Power Consumption for email fetching; and our own proof-of-concept malware for our evaluations. All tests are repeated six times in a row for 5 minutes from which the arithmetic median of the consumed energy is calculated. During this time, no additional interaction with the phone occurs. Note that such measurements do not represent a valid usage pattern in any case, but they enable us to determine the power consumption of basic phone features.

For all following tests, the same usage pattern is used. When the phone is fully charged and set to an initial state, PowerTutor is started and directly put in the background such that the home screen with the live wallpaper and the launcher is visible. No further input will occur in the next 5 minutes which causes the screen to be turned oﬀ after 30 seconds. As long as nothing is noted, a test does not deviate from this pattern.

In the following, we calculate the amount of used energy in mW and its coefficient of 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 defines the 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 noise that is introduced by all components. If any action consumes less energy than the noise rate (i. e., amount of energy described by the CV for an idling phone), it is not measurable with a single measurement. We could of course measure the power demands of such consumers if we would perform many measurements of the same consumer and would calculate the noise out of the results. A detection engine that works with power signatures does not have this kind of luxury, as it has to pinpoint malicious behavior as soon as possible. If many measurements must occur in the first place, a malicious software could already have easily performed its payload undetected. If the additionally consumed power of some activity is given in later tests in a table (referred as “Rise” in the corresponding column), it will be shown in bold letters if its value is above the CV of an idling phone, meaning the measured action has a higher energy consumption than the average noise ratio of an idling phone. Such a component could be detected by a power signature.

Tables with measurement results will also often contain a column labeled “Total Cons.” that depicts the total consumed energy during the test as reported by Pow- erTutor. Unexpected Framework and OS activities triggered during a test might introduce additional noise, which can be seen in this column. The impact is of course higher for the conducted short time test. If this value is higher than the total consumption of the initial tests (see next paragraph) plus the noise ratio (CV value), 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 used energy throughout the test. Note that if the value is written in bold letters, it does

78 4.4 Short Time Tests not imply that it can be detected in a reliable way. Its value must be signiﬁcant higher than the CV value, which describes the average noise. False positives are possible here, one must carefully check the size of the value. Higher diﬀerences to the 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 that includes the sending of short messages in Section 4.5.5. In order to overcome the drawbacks of the utilization-based measurement method of PowerTutor, we strictly control all additionally running applications (next to the running OS applications) and their access to any device. Doing this mitigates the problem of accounting the used energy to programs running in parallel.

4.4.1 Initial Tests

We start our evaluation with tests in which we measure the power consumption of several components such as the display as well as the inﬂuence of running software. These initial tests deﬁne a basis for later tests which are compared with the initial ones. Knowing the minimum amount of energy a smartphone requires in certain circumstances is crucial for the detection of additional malicious activities.

Data Connectivity. This test evaluates the differences between a WiFi and a 3G connection on an otherwise idling phone. Table 4.1 shows how much power their usage consumes if the connection is only established, but no data is actually transferred. The WiFi connection can automat- Table 4.1: Short time initial tests for a 5 ically be turned off if the smart- minute period. Average power con- phone’s screen blanks in order to sumption for wireless connections. safe energy. Using this feature Connection Consumption CV saves no energy in this short time span compared to being always WiFi (always on) 51.17 mW 0.87 % on. On average, the smartphone WiFi (if screen is on) 51.26 mW 1.14 % consumes 51 mW with an enabled 3G 68.47 mW 9.49 % WiFi connection with a low CV. Remarkable among these numbers is that the smartphone consumes 34 % less energy using WiFi instead of 3G. Additionally, the CV is much higher for the 3G connection, with measured absolute numbers from 47.77 to 75.85 mW . This is likely caused by different bitrates and link qualities (GPRS, EDGE, UMTS, HSDPA) depending on the coverage area and the signal strength at the time the test was conducted.

79 4 Dynamic Approach based on Power Consumption

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

It may even change for the same location at diﬀerent times. For the rest of this section, we compare the results of the other tests against the values from this test where WiFi is always on and from the 3G case.

Background Processes. To get an idea of the energy consumption of the applications running on a smartphone, we used PowerTutor to measure the energy usage of the automatically started preinstalled applications after each restart. The results can be found in Table 4.2. What can be seen in this table is the fact that the foreground application—which is the Launcher—consumes the largest amount of power. As it manages the live wallpaper, PowerTutor will add the power consumption used by the OLED display to show the wallpaper to the Launcher instead of to the Wallpaper application. However, the same is not true for its CPU consumption. PowerTutor itself consumes about 3.0 % compared to the overall consumption, but this value is calculated out in all further tests. All other values are left alone, as they present characteristics of the base system, such as Android Services (by this term we mean several Android OS processes). Again, no synchronization or other activities occurred 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 higher numbers represent a brighter display. The lowest user selectable value is 20. The value can be set manually or by the system itself, which can determine the brightness of the phone’s surroundings with a light sensor. We measured the power consumption for diﬀerent values and the results can be found in Table 4.3. During this test, the display was never turned oﬀ which will prevent

80 4.4 Short Time Tests the phone from entering the sleep state. Additionally, the WiFi connection was enabled. With these settings, the battery lasts for about 10 hours with a diﬀerence of 2 hours between the darkest and the brightest setting.

What can be seen is that the brighter Table 4.3: Average power consumption for the display is, the smaller the CV gets. diﬀerent brightness levels. This is caused by the relative high Setting Consumption VC amount of power which is consumed by the display, even for dark settings. All Dark (20) 445.89 mW 2.50 % other energy consumers such as back- Auto (standard) 462.20 mW 1.73 % ground processes quickly loose their sig- Medium (130) 494.61 mW 1.13 % niﬁcance in contrast to this huge en- Bright (255) 550.70 mW 1.01 % ergy consumer, compared to the numbers from Table 4.2. These results show that the display’s energy demand plays a big 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 by various means. Such activities can be seen as a kind of DOS attack against the smartphone, as it is unable to operate with a depleted battery.

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

Such a setting will consume 81.50 mW in total and causes a raise of 59.27 % in terms of used battery power. Although PowerTutor does not detect that our software sets 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 activities in the background—at least not to such an extend. Such a setting, whether used by mistake or on purpose, can easily be detected by any program monitoring the power consumption.

81 4 Dynamic Approach based on Power Consumption

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

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

Both tests put a heavy burden on the phone’s runtime. While the ﬁrst test “only” consumes about double the energy than it would normally do, the second test clearly shows that a malicious program can totally disrupt the battery lifetime. With a raise of over 1,000 % in energy consumption, the battery would only last for about 8 hours even though the screen turns oﬀ. But again, the Android system detects that our application wastes so much energy and the user can take countermeasures. Additionally, the phone gets quite hot under such load. Some AV program could also 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 accurate GPS position is requested. Since location data represents a very sensitive piece of information, we measure the energy required to steal it from the phone.

Last Known Position. In this ﬁrst test, our software will only use the last known position (LKP) which is returned by the Android API. Because no new position is determined, the energy consumption is expected to be low. To mimic actual malware, the returned coordinates are wrapped in an XML structure and sent over the network through the WiFi or 3G connection. Table 4.5 shows the results; the position is retrieved only once during the test. As expected, the power consumption is 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 4.4 Short Time Tests is still very low with a rise of 0.25 % over the normal consumption. This is basically only the amount of energy needed to use the WiFi interface, which is evaluated in more detail in Section 4.4.4.

Table 4.5: Average power consumption for accessing the location API. LKP = Last known position. Connection Function MW Cons. Total Cons. Rise LKP 0.017 mW 52.25 mW 0.03 % LKP (sent) 0.126 mW 51.39 mW 0.25 % WiFi GPS 7.91 mW 61.18 mW 15.46 % GPS (sent) 7.97 mW 63.28 mW 15.58 % LKP (sent) 8.111 mW 87.25 mW 11.85 % 3G GPS (sent) 12.01 mW 107.79 mW 17.54 %

If position data (LKP) is sent over the 3G connection, 2.36 % more energy is consumed 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 the 3G 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 which has to be determined by the hardware GPS module. It is said that it consumes a lot of power; we will see if this accusation is correct or not. The position is again retrieved only once by our software and sent over the network encapsulated in XML format. The results are also presented in Table 4.5. What can be seen is that our software consumes more than 7 mW additional power when the GPS module gets active. We have to note that PowerTutor measures the GPS module’s power consumption separately, but we added it to our malware consumption as it is the sole program using it. It does not matter whether the data is 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 above the noise ratio even for the 3G connection.

4.4.4 Data Heist

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

83 4 Dynamic Approach based on Power Consumption

Table 4.6: Average power consumption for data transmission. Connection Function MW Cons. Total Cons. Rise 349 Bytes (1 SMS) 0.112 mW 51.55 mW 0.22 % WiFi 37.6 kB (200 SMS) 1.182 mW 53.39 mW 2.31 % 365 kB (2,000 SMS) 1.949 mW 54.73 mW 3.81 % 349 Bytes (1 SMS) 8.114 mW 99.15 mW 11.85 % 3G 37.6 kB (200 SMS) 8.161 mW 103.41 mW 11.92 % 365 kB (2,000 SMS) 13.724 mW 86.95 mW 20.39 %

Data Size. We ﬁrst measure the impact of the ﬁle size of the data which is sent over the Internet connection. To get an idea of how much data is transferred, our malware sends data equivalent to the size of 1, 200 and 2,000 short messages encapsulated in a XML structure over TCP/IP. Table 4.6 lists the power consumption for both Internet connection types. As one can clearly see, more sent data consumes more energy. The higher consumption whilst using WiFi is more visible than for 3G, as this connection type implies less noise. Sending small quantities of data quickly puts the energy consumption over our threshold for this short duration with both connection types. In Section 4.5, we evaluate if this is still true for real world scenarios.

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 content provider, the SD card and so on. Only the amount of data matters.

Encryption. Some sophisticated malware might encrypt the sent data to hide its intention. As encryption of course uses CPU cycles, we are interested if this overhead is measurable. We performed the same measurements as above, but the data was additionally encrypted with AES in Counter Mode with PKCS5Padding and a random key. We have measured that our malware consumes 1.19 mW of energy to encrypt 37.6 kB of data which is sent over the WiFi connection. Compared to our last test with data of the same size, almost the same amount of energy is consumed: A rise of 2.33 % instead of 2.31 % is measured, which lets us conclude that the encryption only consumes 0.02 % more energy. Rather than using the 3G interface, we only performed the test with the WiFi interface as the results are more clean due to lower noise. Additional encryption is therefore not measurable as it is indistinguishable 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 aforementioned features are measurable by means of their power consumption under two more realistic scenarios. The ﬁrst scenario (A) covers a real world scenario where the smartphone 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 scenarios are run for 1 hour and repeated three times, resulting in a total duration of three hours for each test run.

Table 4.7: Joblist for scenario A. Minute Job Duration 5 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 oﬀ) 35 Facebook App 2 minutes 50 Angry Birds 5 minutes 55 1x E-Mail 1 minute (120 characters)

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

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

85 4 Dynamic Approach based on Power Consumption

4.5.1 Initial Tests

In order to detect malicious activities, we again ﬁrst need to know how much energy is consumed in both scenarios without them. Table 4.9 shows the four CV values which again represent our threshold values. Any action which consumes less energy than 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 WiFi 63 % 299.67 mW 2.08 % A (heavy) 3G 48 % 419.09 mW 2.67 % WiFi 77 % 97.28 mW 2.79 % B (light) 3G 78 % 145.14 mW 3.16 %

The battery charge value is eye-catching. Although in scenario B the total energy consumption diﬀers by approximate 50 %, the charge level is even higher for a more depleted battery. This is a strong indicator that the user cannot trust the battery charge value by any means and that it should only be considered as a very vague value.

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

As one could already see in the short tests, the 3G Internet connection uses more power than the WiFi connection. The CV for the tests with 3G connections is much lower as in the short tests because there are a lot more actions performed than just keeping 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 up for these scenarios.

Table 4.10 provides an overview of the power consumption of several apps as we did in the last section. As one would expect, the game Angry Birds and the Web browser consume 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 except for the Facebook app. The CPU consumption seems a bit high. The reason for this is unclear, but the app felt unresponsive on the old phone which might be caused by not well written code. The missing values for the apps total energy consumption are used by the GPS module, the speaker and other devices.

Table 4.10: Exemplary power consumption of diﬀerent apps (scenario A). Values in mW (missing energy was consumed by unlisted components). Application OLED CPU WiFi Total PowerTutor 0.25 3.45 0.00 3.70 K9-Mail 13.87 0.60 0.48 14.95 MMS Application 21.44 1.04 0.00 22.48 Music 0.00 0.34 0.00 26.28 Launcher 28.05 1.46 0.00 29.51 Facebook 26.98 12.47 8.40 47.85 Angry Birds 53.89 9.71 1.51 68.10 Browser 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 we want to know how big the impact of such energy-greedy software is in contrast to all other apps, we disabled the sleep mode, meaning that the CPU and all apps keep running even when the display blanks. Table 4.11 shows the results. As one would expect, our malware consumes a lot of energy in both scenarios but most in scenario B, as it gets more CPU cycles in total because there is less concurrent interaction opposed to scenario A. This is also caused by the fact that Android prioritizes foreground apps. The energy consumption compared to Table 4.4 is a bit lower, as other software runs next to our malware. The values are not higher as one might wrongly expect because W is deﬁned as one joule per second.

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

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

87 4 Dynamic Approach based on Power Consumption hours in scenario A and 6.7 hours in scenario B. If the user does not know how to check which apps consume what amount of energy, this will vastly degrade the user’s smartphone experience. Additionally, if the CPU is not the fastest, the user might feel some unresponsivenesses in some apps. Nevertheless, this behavior can be 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 what circumstances. If an app retrieves the last known location from the API, almost no energy is consumed. We therefore limit our tests to the case where our malware retrieves the GPS location. We chose four diﬀerent intervals for each scenario and the location is always encapsulated in an XML structure and sent out through the WiFi interface.

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

Table 4.12: Average power consumption for stealing GPS position (WiFi only). Scenario Function MW Cons. Total Cons. Rise 5 minutes 5.32 mW 315.61 mW 1.78 % 15 minutes 2.88 mW 328.49 mW 0.96 % A (heavy) 30 minutes 2.56 mW 304.88 mW 0.85 % 60 minutes 0.87 mW 292.97 mW 0.29 % 5 minutes 6.11 mW 105.42 mW 6.28 % 15 minutes 2.24 mW 100.84 mW 2.30 % B (light) 30 minutes 1.73 mW 104.12 mW 1.78 % 60 minutes 0.94 mW 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 5 min. (13 MB) 2.01 mW 295.71 mW 0.67 % WiFi 1 min. (65 MB) 11.42 mW 322.82 mW 3.81 % A (heavy) 5 min. (13MB) 8.02 mW 450.65 mW 1.91 % 3G 1 min. (65 MB) 51.72 mW 538.74 mW 12.34 % 5 min. (13 MB) 2.14 mW 100.84 mW 2.20 % WiFi 1 min. (65 MB) 6.11 mW 105.42 mW 6.28 % B (light) 5 min. (13 MB) 7.50 mW 148.82 mW 5.17 % 3G 1 min. (65 MB) 39.78 mW 197.78 mW 27.41 %

The short time tests revealed that even small quantities of data sent through either the WiFi or the 3G interface are detectable. This section examines if this is also true for real world scenarios. In both scenarios, 369 kB are read and sent through each interface. Two diﬀerent 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 from a spyware is not that easily detectable in a real world scenario. A well written malicious software that steals data could send approximately 35 MB of data in small chunks in 3 hours without being detectable by its energy consumption. This amount decreases 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 are copied. In contrast to that, theft of SMS databases or serial numbers such as the IMEI are unrecognizable.

4.5.5 Uncalibrated Phones

Next to our test with PowerTutor on a HTC Nexus One, we also performed some tests with a Samsung Galaxy Nexus. Since PowerTutor is not fine tuned to this phone, we only use the provided battery charge level and the reported battery voltage by the tool (similar to the approaches presented in the literature [126, 144]). This way we can determine what is possible without a sophisticated tool. We performed three tests on the Galaxy Nexus. The first two are identical to the last two from the previous test: Data is sent over the WiFi interface in two different

89 4 Dynamic Approach based on Power Consumption intervals for our two scenarios. In the third test, our malware sends a short message every 5 minutes resulting in 36 messages over 3 hours. Unfortunately, PowerTutor is unable to measure the power consumption of the GSM modem. Therefore, this test was not performed on the Nexus One and cannot be compared to any previous measurements.

In order to obtain any information about the phone’s power consumption, we began our evaluation with a measurement of the phone’s energy demands for the two scenarios without any additional actions. We again call them initial tests and they are performed in the same way as mentioned before (3 hours in total). The results can be found in Table 4.14 and clearly tell one story: Without any sophisticated measurement of the actual consumed power, no predictions of any additional running malware can be made (at least for our chosen scenarios and tests). Each test ended up with a battery charge rate which was higher than that for the initial test. This should of course not be the case, as additional actions were performed. The reported voltage also does not correlate to our expectation that more energy is used and it should therefore be lower (the battery voltage decreases if depleted). Therefore, a user cannot trust the values displayed on the phone and so cannot any monitoring software.

Table 4.14: Battery charge level for the Galaxy Nexus after sending data and short messages (WiFi only). Scenario Function Charge Voltage Initial test 74 % 3,812 mV 5 minutes/13 MB 79 % 3,887 mV A (heavy) 1 minute/65 MB 76 % 3,900 mV 36x SMS (every 5 minutes) 76 % 3,845 mV Initial test 90 % 4,060 mV 5 minutes/13 MB 91 % 4,072 mV B (light) 1 minute/65 MB 91 % 4,023 mV 36x SMS (every 5 minutes) 90 % 4,022 mV

4.6 Validation with Real-World Malware

This section covers the energy demands of two malicious software samples named Gone in 60 seconds (GI60S) and Superclean/DroidCleaner (SC) that were found in 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 validate our 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 to some server: contacts, short messages, call history, and browser history. When finished, it will display a code that can be entered on the GI60S homepage which will enable the user to see all stolen data (messages are behind a paywall). In a last step, the software removes itself from the smartphone. In our case, 251 kB of data got transferred. The name is based on the fact that all this is done in less than 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 on the SD card which are possibly run by a Windows system if the smartphone is used as an external storage device. It also offers some bot functionality and is able to gather 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, phish for passwords, and control some device settings. More detailed analysis reports are available on the Internet [230]. We wrote a small server for SC and tricked it into connecting to this one and not the original one (which was already down). This way we were able to control the bot and send commands to it in order to measure the consumed power. We used the functionality to download several files (images, PDF and music), SMS, and contacts next to retrieving all information about the phone. 22.46 MB of data were transferred over WiFi to our server. Table 4.15 shows the results of our measurements.

Table 4.15: Veriﬁcation with malware in controlled scenarios (WiFi only). Scenario MW MW Cons. Total Cons. Rise GI60S 1.45 mW 311.51 mW 0.48 % A (heavy) SC 4.06 mW 296.87 mW 1.35 % GI60S 1.54 mW 103.35 mW 1.58 % B (light) SC 5.60 mW 113.65 mW 5.45 %

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

91 4 Dynamic Approach based on Power Consumption the SC test in scenario B is detectable which is not astonishing, as we copied a lot of data from the phone which raises the energy consumption a lot in the light usage scenario. Malware could act much less inconspicuous, but that was not our goal in this test.

Furthermore, we tested GI60S in an “all day long test” (i.e., the phone was “used normally” during an 8 hour period). During this time, GI60S was run once such that all data was stolen. This test was performed twice and the results can be found in Table 4.16. These show that the overall power consumption during an 8 hour period can greatly differ. The CV for the total consumption during a day (total runtime was 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 from the last hour, depending on the actual usage pattern. Having such a high CV, it is almost impossible to detect anything based on a single power measurement. Even if very accurate and timely measurements with small intervals are available and the smartphone reports accurate battery levels, this would still be a tough job since the user has such a big influence and his actions are almost unpredictable resulting in a very high noise ratio. The solution proposed by Dixon [65] might lower the CV, but it seems unlikely that it will reach a usable value. We have not tested SC in this test since the results should be very similar.

Table 4.16: Power Consumption during the “all day long tests”. The CV is calculated from 8 time slices during that period lasting for 1 hour each. Run Application Consumption CV Rise Charge Total 64.57 mW 70.40 % 40 % 1st day GI60S 1.24 mW 1.92 % Total 87.14 mW 82.86 % 56 % 2nd day GI60S 0.54 mW 0.62 %

4.7 Evaluation

In this section, we evaluate our measurements and findings. We can boldly say that 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 energy demand and ultimately the smartphone’s runtime. Let alone the fact that precise battery charge levels are very hard to measure and depend on a lot of different factors [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 for the used smartphone. We therefore deem its measurements as accurate enough for our 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 modern smartphone operating system: Such a signature would contain the energy demands of the application in question under certain circumstances. If an app would suddenly act in a malicious way (e. g., stealing private information) a monitor should detect these actions based on its power signature. In theory, this should work as all additional (malicious) actions will use additional energy which is measurable. In practice however, accurate measurements are hard to perform as discussed throughout this chapter. This will yield to a certain error rate which we called “noise” in the previous sections. This noise describes the varying amount of energy which is consumed more or less for the same action(s) in the same amount of time. Even for a ﬁve minute interval, a noise ratio of 1 % was measured. Despite the fact that we were able to control many settings on the smartphone during this time span, our measurements were not 100 % accurate. Since we used a modern smartphone with a variety of features, this problems gets worse for larger intervals as more features kick in (e. g., email fetching or synchronization). This leads to a noise ratio of up to 2.79 % for long time tests. The fact that such a monitor should run on everyday smartphones, forces it to cope with such noise ratios.

Our measurements for the various test cases in Sections 4.4 and 4.5 show that such a power signature would not be accurate enough, as a lot of possible malicious activities can easily go by undetected compared to the measured amount of energy these actions cause. If such a signature would only work with the total consumed power of the smartphone, it will alert the user for a lot of these actions. But, if the total 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 could lead to many false positives. Generating a good threshold is inherently hard, as the users’ habits may change and even for the same user and for two consecutive days the CV is above 70 % (see Table 4.16), which is completely unusable. Lowering the measurement interval could decrease the CV, but only to some extent as it heavily depends on actual user input in some cases, see Section 4.8 for an example. A detailed analysis of the smartphone usage of 250 users was conducted by Falaki et al. [78] and they also found out that even a single user can show very varying usage patterns. If the total consumption is not considered, an attacker could, e. g., steal an amount as high as 35MB over 3 hours without being conspicuously. This is also true for a lot of other actions.

93 4 Dynamic Approach based on Power Consumption

If one not only analyzes the energy consumption introduced by an application in total or even on a device basis (e. g., WiFi), consumption patterns might occur. But these patterns still suffer from the introduced noise, as the power consumption is only infered from a model that was previously generated (the phone does not provide power stats of sole devices). Having some kind of pattern which states that some app consumed x1 mW during y1 seconds in device z1 and then x2 mW during y2 seconds in device z2 and so on, one could use that as a signature. However, searching for that information in, e. g., the syscall trace would also be enough because it was used to interfere these values in the first place. Although such power signatures cannot detect the described activities, they still can detect some malicious ones. Amateurish written malware could be detected if too many features are used too aggressively, e. g., determining the current position by GPS in a very short interval. What is easily detectable is energy-greedy malware which has the goal to disrupt the battery lifetime. But this clearly is not the normal behavior malware exhibits—most of them steal (private) data or send premium rate SMS. This leads us back to VirusMeter: This approach makes use of predicted user behavior and their resulting energy demands. If the used energy (measured by the different battery charge levels) does not match the assumption, then something is wrong and an alert is generated. While the tools to measure events and power consumption clearly improved compared to the possibilities the authors of VirusMeter faced, we cannot verify their findings for a modern Android based smartphone. The noise ratio 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 sophisticated heuristic performs the evaluation externally or on the smartphone itself if 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, and therefore noise ratios, which are too high. Using some sophisticated power model will not negate the small amount of additional energy (often below 2 %, which is under the mean error rate for most tools and settings) that is needed to perform most malicious activities. We therefore opted to not generate our own model as it is unable to cope with such settings. Even if malicious activities are detected by such means, most activities would already have finished and the damage would have been committed. Otherwise, no additional 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 any satisfying manner as most of the relevant cases can only be detected when it is too late. 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 detect malicious activities.

4.8 Discussion

In order to reach the goal of this work—namely to evaluate whether the detection of malware running on a mobile phone is possible by measuring the power consumption of certain activities and devices—we need precise power measurements. We believe that PowerTutor is a good starting point on an adjusted device such as the Nexus One. Although the measurements are not perfect, we deem them accurate enough for our purposes. At least they are more accurate than the parameters used for VirusMeter [144]. Additionally, the mean error rate is comparable to other tools such as Appscope and eprof. One thing PowerTutor is unable to cope with is the power consumption of actions which make use of the GSM modem, such as the short message service. We were therefore unable to measure precise results for such activities. Another thing that is not reported in a good manner is the power consumption of the GPS device. PowerTutor can only report the consumption of the whole device, not the consumption of a speciﬁc “consumer”. We therefore have to calculate an approximate value for its usage if more than one software is using it. eprof would be better suited for such a test case, as it is able to calculate the consumption for each app separately. The authors of VirusMeter build a proﬁle for the user in order to detect anomalies which we did not do. We refrained from doing so, as our measured numbers are either too close at our thresholds (CV) or too far away. Without reasonable results for the long time tests generating such a model is futile in our opinion regarding a low false-positive count. The user’s activities are just too random for modern smartphones [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 of how a monitoring software performs which does not have access to accurate results such 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 was still modern enough with respect to early 2013 to actually perform meaningful tests with it. In fact, AppScope also only supports this phone. Furthermore, the results are not encouraging at all. We tried to be as precise as possible during our tests. But since these tests were all performed by hand, there are certainly slight variations for each result. Automatic testing was not possible, so all the performed tests took a lot of time and patience.

95 4 Dynamic Approach based on Power Consumption

Our results indicate that software-based approaches to measure the power consumption of an Android smartphone and to interfere from these results whether additional malicious activities occurred, is not satisfactory in most cases. The approach mainly fails due to the noise introduced into the system by unpredictable user and environment interactions, such as the reception rate or the delivered content of accessed websites. While a more precise power model could mitigate effects such as varying reception 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 have optimal but comparatively real world settings. The short time tests indicate that some activities can be detected by such a system, but under settings seldom found on a smartphone that is regularly used. We even go one step further and think that such a system is not feasible at all on a modern smartphone—at least with available measurement methods and normal use cases. Let alone the fact that the hardware components have to provide very accurate values of consumed energy, the system still needs a very precise model of what 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, as normal users change their behavior quite often, depending on the actually installed apps and so on. Even if a precise profile would exist and the user would not change his habits too often, apps can be very dynamic in a way that a power profile for these 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 a power signature for its behavior. We conclude that well written malicious software running on a modern smartphone can hardly be detected by means of additionally consumed energy as the noise ratio is too high. Only DoS attacks against the battery runtime and so called “energy bugs” [123] as well as certain activities performed under strictly given scenarios can be reliably detected, which is not enough to be of great use for normal smartphone usage patterns. As a last point we note that modern smartphones with modern operating systems such as Android are more or less a general purpose computer with a very small form factor. If such proposed systems would be usable as a malware detector, they should also work on regular notebooks or PCs. To the best of our knowledge, no such system was ever used for this purpose. We therefore deem energy based approaches for malware detection as a dead end—at least for modern smartphones without extended capabilities to account for used energy.

96 5 Change 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 is currently in submission and was jointly done with Davide Maiorca, Teemu Rytilahti, Marcel Winandy, Thorsten Holz and Giorgio Giacinto. We would also like to thank Oussama Renuli and Nicolai Wilkop for their help while evaluating the diﬀerent analysis framworks.

Abstract. The recent past has shown that smartphones became a target for malware authors—particularly Android based ones. The ﬁrst detected malware samples were rather simple, mostly abusing premium-rate services, cf. Section 2.1.4. How- ever, recent malware families oﬀer a variety of features and allow, among other features, spying as well as theft of arbitrary data and can often cause monetary damage by various means. This circumstance led to the introduction of many different analysis methods for mobile malware and in return caused malware authors to write more sophisticated malware attempting to thwart such analyses.

In this chapter, we first categorize mobile application analysis systems and describe on which assumptions they rely on. We then present a new obfuscation tool that modifies Android applications so that these assumptions do not hold anymore. We evaluate the robustness of many analysis systems for (malicious) Android applications against such transformations. As some tools rely on Java source code, we also introduce code modifications that particularly oppose decompilation attempts. Finally, we present detection rates of antivirus systems, including those for mobile platforms, 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 blind spots 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. While the first such samples were rather simple and unsophisticated, the complexity of today’s malicious apps is steadily increasing. Especially malware for Android-based smartphones has significantly advanced in the recent past [250]. This is a repetition of the evolution of malware we observed for desktop computers: While the very first computer viruses and worms were rather basic, their level of difficulty constantly rose over the years and modern malware like Stuxnet or Flame impressively demonstrate the sophistication of today’s threats. Hence, we also expect that malware for mobile devices will become more mature in the near future, especially since adversaries have an 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 evolution of malware. The typical arms race in computer security between attackers and defenders is especially distinctive in this area. Researchers from both academia and industry developed a large number of analysis methods for Android apps in recent years (e. g.,[62, 241, 251, 79, 55, 195]). These tools explored many different approaches and they took into account lessons learned from analyzing malware for desktop computers. However, existing analysis methods cannot simply be ported to Android due to many intricacies of the platform (e. g., multiple entry points and a new binary format). Thus, many novel analysis approaches were examined and this led to a huge body of work on this topic. In this work, we systematically evaluate the robustness of state-of-the-art analysis tools for Android apps. Such an empirical evaluation is needed to assess how reliable existing analysis tools are. Especially due to the constant rise in malicious apps we need such an evaluation: Antivirus vendors report to have detected more than 100,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 automated analyses, we need to know their limitations and drawbacks. Moreover, we want to anticipate the next generation of mobile malware that leverages sophisticated obfuscation methods to impede automated analyses. In a first step, we survey 28 existing analysis methods and categorize these approaches 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 of tools. 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 decompile the 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 API function names in the code. We found that the number of underlying assumptions for all existing methods is rather small. To produce an obfuscated app, a viable strategy is thus to systematically thwart these assumptions. For example, we can obfuscate the code such that decompilation becomes impossible, degenerate the CG such that it does not contain meaningful information, or hide all API strings. The resulting app has the same semantics as the unobfuscated one, but it withstands the analysis tools since their basic assumptions are not fulfilled anymore. We implemented the identified obfuscation methods as a basis for our study of the robustness of existing analysis methods. We opted to perform this obfuscation directly on DEX bytecode since this implies that we do not need access to the app’s source code and can thus be applied on arbitrary, existing apps. Compared to 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 potential obfuscation techniques. On the one hand, we leverage methods to bypass dynamic and static analysis methods (e. g., detection of the analysis environment, entry point pollution, bypassing taint analysis, breaking use-def chains, hiding types). On the other hand, we also came up with methods that confuse decompilers to be able to also bypass them (e. g., changing the catch handler order, adding bogus code, or clashing types). Consequently, our goal is not only to bypass existing antivirus solutions as many of them simply rely on static signatures, but to bypass all existing static and dynamic analysis frameworks that aim to provide a comprehensive analysis. To the best of our knowledge, this study is the first to assess the robustness of a wide range of analysis approaches for Android apps.

In summary, we make the following four contributions: • We survey existing analysis methods and provide a comprehensive overview of state-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 assumptions can be thwarted (e. g., decoupling the CG). Our goal is to produce an obfuscated app with the same semantics as the original one, but which withstands existing analysis tools. • We implemented the identiﬁed obfuscation methods. Our implementation directly modiﬁes the Dalvik bytecode, so we can obfuscate arbitrary Android

99 5 Change of Ends: Obfuscating Android Applications

apps without requiring access to source code.

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

5.2 Related Work

In this section we ﬁrst survey Android application analysis frameworks. Then we discuss related work on obfuscation for Android apps and explain why we implemented our own obfuscation tool.

5.2.1 Android Application Analyzers

Prior surveys have given an overview on security research on Android [75] and evaluated the eﬀectiveness of malware detection with dynamic analyses [166]. In contrast, we consider both static and dynamic analysis frameworks, and we include general analysis tools, not only malware detection. As such, existing approaches of Android application analysis can be categorized into ﬁve classes according to their main purpose. 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 properties 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 disassemble DEX files, ded [171] to convert Dalvik bytecode to Java bytecode, and Soot [228] to decompile and transform Java bytecode.

AndroGuard [62] is a static analysis framework which includes a decompiler and premade tools for various tasks such as component and permission analysis, determining native code usage, and it can create CFGs and shows differences between apps. TaintDroid [76] implements dynamic taint tracking to discover information leakage in apps. First, one or more sources of sensitive data are specified and the corresponding data is marked as tainted. Then the app is executed and monitored in 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 alarm is 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 architectural levels of Android: the native Linux and the Dalvik contexts. Besides a modified DVM it also uses a modified QEMU, which is also instrumented to log specific operations. To some extent, DroidScope can keep track of tainted data when native code 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 dynamic analyses may not execute all code paths. FlowDroid [89] is such a static taint analysis system that provides a precise model of the application lifecycle, and it is context, flow, field and object-sensitive. FlowDroid builds a so-called exploded supergraph based on flow functions that define the data flow on program statements. The decision whether a variable is tainted at a certain point in the code is reduced to a graph reachability problem. The analysis depends on successful decompilation.

Mobile-Sandbox [210] combines static and dynamic analysis to identify malicious functionality in apps. A static analysis checks for malware, determines required permissions, and identiﬁes possible entrypoints. It also searches in the disassembled code for certain functions that are often used by malware (e. g., to send SMS messages). Then the app is executed in an Android emulator that performs a taint analysis, logs any native library calls, and stores the network traﬃc.

Detecting Malware in Application Markets

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

DroidMOSS [248] aims to detect similarities between original apps in Google’s marketplace and repackaged apps in third-party marketplaces. Although it does not look for malware directly, such repackaged apps may include additional functionality or modiﬁcation to the original code which could be potentially malicious. To this end, DroidMOSS generates a ﬁngerprint for each app using fuzzy hashing on the disassembled bytecode and calculates a similarity score to other apps.

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

101 5 Change of Ends: Obfuscating Android Applications

RiskRanker [104] automatically classiﬁes apps into three risk levels. It includes two analysis engines. The ﬁrst one requires non-obfuscated apps and scans for native code that contains known exploits and looks for code paths that contain suspicious API calls. The second engine uses symbolic execution over decompiled code to identify critical execution paths that contain certain API functions such as executing encrypted native code or dynamic code loading.

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

Analyzing Requested and Used Permissions

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

PermissionWatcher [216] is an Android app that shows the permissions of other apps that are installed on the same smartphone, and reports predeﬁned risk levels based on the set of requested permissions. Permission Based Risk Signals [199] start earlier and indicate whether it is a risk to install an app based on the requested permissions, the category in the marketplace, and the set of permissions other apps typically have in the same category. This approach is a more generalized form of the same principle used by DroidRanger. Probabilistic Generative Models [185] even improve this approach from a binary decision to reporting risk scores for each app using 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 tool identiﬁes 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, it can track the usage of Java Reﬂection and detect speciﬁc API calls that are related to permissions. COPES [36] also detects over-privileged apps via static analysis, but it has a more precise mapping of permissions to API calls since it uses an automatic analysis 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 in an app, based on which one may determine a malicious intent. The analysis is based on the construction of so-called Permission Event Graphs, which represent the temporal order between requested permissions and API calls. VetDroid [246], in contrast, is a dynamic analyzer that examines how permissions are used in the code of an app. The app is executed in an Android emulator that monitors code execution and identifies those code positions that request a resource protected by a permission. Then it analyzes in which execution paths this resource is re-used and whether this results in information leakage or other malicious activity. While those approaches relying on meta-data will not be affected by code obfuscation, static analyzers will most likely have difficulties in finding critical API calls in obfuscated apps, and permission pollution may affect their effectiveness.

Analyzing ICC Vulnerabilities

Inter-Component Communication (ICC) is another crucial aspect of app security on Android. Apps could be abused via ICC by malicious apps to gain access to sensitive data or to attack their control flow. Messages going to be sent from one app to another 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 and between Android apps. This tool concentrates on flows from and to data stores, in particular content providers, databases, files, and URIs. ComDroid [55] was the first static analysis tool to examine potential security violations resulting from implicit Intents or publicly made components in Android apps. It analyzes disassembled bytecode and identifies the creation of Intent objects, whether they are explicit or implicit, and follows the control flow to determine Intents that are used in unprotected ICC calls. Further static analyzers for ICC vulnerabilities have been developed: CHEX [147] focuses on detecting component hijacking vulnerabilities by analyzing disassembled bytecode. Woodpecker [103] aims at detecting ICC vulnerabilities in the bytecode of the pre-installed apps on an Android system. DroidChecker [51] focuses on finding ICC vulnerabilities that could be exploited by a confused deputy attack. DroidChecker performs an interprocedural flow and taint analysis on the decompiled source code to find exploitable data 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 to possible Intent values. The novelty in this approach is that the ICC analysis problem is 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 5 Change of Ends: Obfuscating Android Applications the possible Intent values in conditional branches, so it can eﬀectively map call sites to ICC entry points, even across applications. IccTA [141] and DIDFAIL [131] both combine and improve the analysis tools Epicc and FlowDroid to ﬁnd privacy leaks across multiple apps that are linked via ICC.

It is reasonable to assume that ICC vulnerabilities will cause a multitude of security violations, as interactions among apps increase. Interestingly, all existing ICC analyzers are based on static analysis, and most of them require the ability of performing string matching on source code or disassembled bytecode to ﬁnd critical API functions. We can expect that most or all of these tools will fail if apps are obfuscated.

Analyzing Application Behavior

The last group of tools aims at systematic monitoring and proﬁling of the behavior of apps. Based on these proﬁles, users can make more informed decisions whether they want to install the app or not.

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

CopperDroid [195] performs a dynamic behavioral analysis by logging low-level system 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 uses a pre-computed mapping of API calls to privacy-relevant behavior, and statically analyzes 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, a static code analysis identiﬁes 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 cases that will show if data transmissions match with user events.

Most of the approaches in this category rely to some extent on static analyses of the code. Hence, we can expect that behavior profiles will not be detectable with these tools 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 normal API calls are replaced by reflection calls.

104 5.2 Related Work modified QEMU, modified DVM dexpler, Soot, Heros baksmali, TaintDroid/DroidBox, ltrace modified DVM modified Linux kernel, DVM, TaintDroid QEMU, GDB apktool, adb, strace, tcpdump — baksmali disassembler, fuzzy hashing malware behavior footprints critical behavior in code paths — Soot Dedexer, ComDroid DexLib, WALA, Stowaway Dedexer Epicc, FlowDroid Java Decompiler (JD), ANTLR Dare, Soot (Spark, Heros) Epicc, FlowDroid, ApkCombiner decompiler (not implemented), WALA baksmali ded, Soot, JavaPathfinder ded, Fortify SCA, Stowaway Code Analysis Requirements construction, Decomp: Decompilation, MW: Malware Detection).

FlowDroid [ 89 ] Mobile-Sandbox [ 210 ] TaintDroid [ 76 ] WHYPER [ 179 ]ProﬁleDroid] [ 234 app’s description, NLP engine ToolAndroGuard [ 62 ] DroidScope [ 241 ] DroidMOSS [ 248 ] DroidRanger [ 251 ] RiskRanker [ 104 ] COPES Static [ 36 ] Pegasus [ 52 ] DynamicPermissionWatcher [ 216 ] Decomp.Permission Risk CG Signals [ 199 ]Prob. Generative APISM Models [ 185 ]Stowaway [ 79 ] Based onVetDroid [ 246 ] CHEX [ 147 ] ComDroid [ 55 ] DIDFAIL [ 131 ] DroidChecker [ 51 ] Epicc] [ 172 IccTA [ 141 ] SCanDroid [ 90 ] Woodpecker [ 103 ] AppIntent [ 242 ] AppProﬁler [ 196 ] Public CopperDroid [ 195 ] app’s app’s manifest, manifest, list app’s list of manifest, of critical list critical permissions of permissions critical permissions

General MW Permissions vulnerabilities ICC Behaviour Table 5.1: Overview of app analysis tools for the Android platform (APISM: API string matching, CG: Callgraph

105 5 Change of Ends: Obfuscating Android Applications

5.2.2 Android Obfuscators

Since we want to evade analysis attempts with different obfuscation strategies, we need an obfuscator capable of transforming DEX code. DexGuard is probably the most powerful commercially available obfuscator so far released for Android. It can rename identifiers and also features advanced transformations, such as utilizing reflections for indirect invokes, as well as string and class encryption. Although DexGuard offers many features that are required by our evaluation presented in Section 5.4, we had to resort to building our own tool in order to perform all desired modifications. 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 with DexGuard as well as injecting arbitrary instructions, methods or classes (cf. Sec- tion 5.4). Additionally, DexGuard does not directly modify DEX files, but works on Java 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 are often obfuscated with Proguard, the open source predecessor of DexGuard. It works on Java code, too, but offers less features and its main purpose is to optimize applications by means of, e. g., string replacements and the removal of unused program parts. Among other obfuscators of Java code, we mention Allatori [1] and DashO [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 obfuscator SandMarks [57] on Android executables. This was done by decompiling DEX code with the Soot framework, in order to transform it in its Java equivalent. They tested the transformed applications against repackaging detectors. Unfortunately, as the authors also stated, this approach has a lot of limits as the conversion from DEX to Java 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. They evaluated which changes to a DEX file produce different results in the detection rates for antivirus programs. They call methods indirectly and encrypt strings next to the encryption of assets. What clearly sets us apart from their work are our extended modifications we automatically apply to apps and our focus to evaluate analysis systems in general—not just antivirus solutions. Besides, the authors only evaluated 6 samples against 10 antivirus solutions. Protsenko and Müller present Pandora [188] and evaluate how well antivirus solutions 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 index shifting as well as method in-/outlining, and the creation of getters and setters for field access. Their transformations are accomplished with the Soot framework, and their main goal is to analyze antivirus robustness against transformation attacks. Zheng et al. did some early similar work with their tool ADAM [247]. They evaluated which APK modifications impact the detection rates of antivirus systems. Their obfuscations include string encryption and the addition of dead junk code. They apply much less obfuscation features compared to ours. Similar to other works, their goal was to evade antivirus signatures, which is only one aspect of our contribution. Zhou et al. replace original bytecode with application-specific one in order to thwart static analysis and decompilation attempts [249]. This type of obfuscation is called table interpretation by Collberg et al. [58], and they considered it to be one of the most effective and expensive obfuscations available. In order to avoid the expensive interpretation, they are hooking the Dalvik interpreter to interpret their custom bytecode. While being really effective against both dynamic and static analysis, the real bytecode of executed paths can be dumped out with dynamic analysis techniques and the artificial instruction set can be defeated by reverse-engineering to some extent. As the authors themselves state, it can be used as a supplement with other obfuscation methods for better protection. Another well-known form of hindering analyses is packing: The original payload is somehow encrypted and only loaded and decrypted when it is being executed [204]. Currently, there are already multiple services offering packing for Android applications such as Bangcle App Shield [3]. While making static analysis hard, there are ways to dump the original code after decryption from memory and then perform the analysis on the decrypted part. Therefore, such methods should also be combined with other obfuscation methods for better evasion.

5.3 Program Analysis Assumptions & Obfuscation Methods

Based on the survey of existing analysis approaches, we now review the basic assumptions on which these analysis tools rely on in order to perform their analysis and discuss how these assumptions can be disturbed. More speciﬁcally, we explain how applications can be altered to thwart analysis attempts. Our goal is to produce an obfuscated app with the same semantics as the original one, but which cannot easily be analyzed by existing analysis methods. We have three requirements: First, our altered app must run on Android devices without any required modiﬁcations to

107 5 Change of Ends: Obfuscating Android Applications 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 operate directly on DEX bytecode.

5.3.1 Dynamic Analysis Evasion

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

Analysis Detection. A common approach in malware is to detect the analysis environment 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 is commonly used by analysis systems, which can be detected by various ways. Vidas et al. list a variety of mechanisms to detect such environments successfully [232]. Ad- vanced detection mechanism leveraging the implementation details of QEMU among others were evaluated and tested by Petsas et al. [187]. All these revealing information sources should be changed in custom analysis environments to avoid detection. We can inject checks against analysis environments into each entry point of the application and divert execution if an analysis environment is detected. The same is true for connected debuggers (detectable via Debug.isDebuggerConnected()). Still, we found that stock or only slightly modified emulators are often used in analysis systems and thus such techniques can be easily applied by malware in practice.

Time. As analyses are usually run for a limited time, another common technique to evade dynamic analysis approaches is to perform malicious activities at a certain point in time. Android allows such artiﬁcal delays by using for example Thread.sleep() or the AlarmManager. Analysis frameworks have adopted to this technique and fake the amount of elapsed time and therefore can circumvent such methods. 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 mobile devices. Further, the computation time for well known tasks can be measured, and if the timings diﬀer from previously recorded ones, one can assume to run in some kind of analysis system. Keeping track of elapsed time could additionally be performed with the help of external sources, such as NTP servers.

108 5.3 Program Analysis Assumptions & Obfuscation Methods

Entry Point Pollution. Programs typically have well defined entry points, e. g., some kind of main() method. Android applications, though, can have a multitude of entry points being event-driven and execution of their parts rely on the Android framework. While there is no real main() method, most of the times there is a standard Activity for applications which is instantiated when the user clicks on its icon. Next to this “main Activity”, an arbitrary amount of other Activities can be specified which can be activated by the program itself or by other applications. Other entry points include Receivers which are instantiated by the Android framework if a matching Intent is handled by the application, and Services which typically run invisible in the background and are usable by other apps. They can also be used by external programs. Depending on the specifics of these entry points, it is often not clear when and how they are launched, if at all. Thus, a dynamic analysis should invoke all these entry points to generate a good code coverage rate. To complicate analysis attempts, we can specify a random amount of unused entry points. As arbitrary code can be executed by all these, their code should also be analyzed. These entry points could either let the application crash, exit, enter an infinite loop, or hamper the analysis other ways, e. g., setting a flag that gets checked before malicious activities take place.

Taint Analysis. Taint analysis is a powerful analysis technique where sources and sinks 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 declared as a source and the send() method of a socket as a sink. Whenever information is requested from the source, it is marked with a chosen tag and whenever tagged data is sent to a sink, a report is generated. This allows modelling of general data flows and enables detection of information leaks. TaintDroid [76] was the first tool to offer taint analysis on Android. The problem of too many tags being assigned to (unrelated) data is known as overtainting, while undertainting describes a condition where the sensitive data is not tagged properly. Both cases can be used to thwart taint analysis. Our tool makes use of a list of sensitive sources from by Rasthofer et al. [192]. If data from such sources is represented as a numeric value (e. g., a serial number) or a string (e. g., contact information), our injected code automatically “untaints” the data by leveraging techniques described by Sarwar et al. [200] before it is further processed.

Multipath and Dynamic Symbolic Execution. Dynamic analysis frameworks have access 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-taken branches. In order to increase code coverage, mainly two techniques were invented,

109 5 Change of Ends: Obfuscating Android Applications namely multipath execution [160] and dynamic symbolic execution [209]. The former stores the program state when a branch is taken and executes first the code which normally would be executed, and afterwards executing the other path from a restored state. The latter takes another approach, by computing the conditions of conditional branches 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 of interest or to report the required states. Both techniques become harder to apply for larger programs because of the well known path explosion problem, which quickly gets hard computational-wise, thus limiting their practicality. Artificially amplifying this 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 must therefore be evaluated at runtime. The normally never-taken path can also lead to the execution of broken code or some flag could be set to hinder following analysis steps. 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 for executing multiple paths for Android is available yet, but two publicly available symbolic execution frameworks exist: SymDroid [122] and ACTEve [26, 27]. The former one transforms DEX code to an intermediate language and emulates many of the 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 describe several obfuscation strategies we utilize in order to prevent static analyses. While we only discuss a small excerpt of possible transformations, these techniques are suﬃcient to hinder the analysis as we later see in Section 5.4. A comprehensive taxonomy with Java bytecode in mind is provided by Collberg et al. [58].

Call Graph Decoupling. As Java supports reﬂections, most direct method invocations 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 and invoke-x/range instruction is replaced by an indirect call, a call graph would be totally degenerated and would only contain calls to Java’s Reﬂection API. Only invocations that cannot be replaced this way (e. g., calls to superclass methods due to 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 the code in our example is not well-obfuscated for readability. This will change when we apply additionally techniques described in the following sections.

110 5.3 Program Analysis Assumptions & Obfuscation Methods

Listing 5.1: Indirect invokes. Code in line 4 is replaced with semantically equivalent code from lines 6–28. 1 sget −object v0, Lj/l/System;.out:Lj/i/PrintStream; 2 const−string v1, "some string" 3 4 invoke−virtual {v0, v1}, Lj/i/PrintStream;. println:(Lj/l/String;)V 5 6 const−string v4, "java.io.PrintStream" 7 invoke−static/range {v4}, Lj/l/Class ;.forName:(Lj/l/String;)Lj/l/Class; 8 move−r e s u l t −o b j e c t v4 9 const/16 v8, #int 1 10 const−class v7, Lj/l/Class; 11 invoke−static/range {v7, v8}, Lj/l/reflect/Array;.newInstance:(Lj/l/Class;I)Lj / l / Object ; 12 move−r e s u l t −o b j e c t v6 13 check−cast v6, [Lj/l/Class; 14 const−class v8, Lj/l/String; 15 const /16 v7 , #i n t 0 16 aput−object v8, v6, v7 17 const−string v5, "println" 18 invoke−virtual/range {v4, v5, v6}, Lj/l/Class ;.getDeclaredMethod:(Lj/l/String ;[Lj/l/Class;)Lj/l/reflect/Method; 19 move−r e s u l t −o b j e c t v9 20 const /16 v12 , #i n t 1 21 const−class v11, Lj/l/Object; 22 invoke−static/range {v11, v12}, Lj/l/reflect/Array;.newInstance:(Lj/l/Class;I) Lj/l/Object; 23 move−r e s u l t −o b j e c t v11 24 check−cast v11, [Lj/l/Object; 25 const /16 v4 , #i n t 0 26 aput−object v1, v11, v4 27 move−object/16 v10, v0 28 invoke−virtual/range {v9, v10, v11}, Lj/l/reflect/Method;.invoke:(Lj/l/Object ;[ Lj/l/Object;)Lj/l/Object;

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

Hiding Types. The previous techniques do not completely hide types, so that they could be inferred by an analyst rather easily. Listing 5.1 already contains hints on how that can be achieved. Many Reﬂection APIs accept parameters of the type

111 5 Change of Ends: Obfuscating Android Applications j.l.Object—every other object extends this type—see lines 11 and 28. The virtual machine checks at runtime whether the passed objects match the expected types or not. This enables us to get rid of most visible types, except for primitive types, and types referenced by method calls which cannot be invoked indirectly. All arithmetic instructions (e. g., add-int) or branch-instructions (e. g., if-eq) work on non-object registers, which require unboxed primitive values. Replacing for example arithmetic instructions with methods doing the same operation, is possible, and primitive types could be boxed to their corresponding objects, while the type can be hidden again. Branching instructions cannot be replaced that way so easily, as control ﬂow changes should 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 obfuscate array accesses for primitive component types).

We additionally create new class instances indirectly. Each call to () methods is replaced with a call to j.l.r.Constructor.newInstance(). This still requires a class object, as shown in lines 10 and 13-14, which is done with the type-revealing const-class opcode. These and const-string calls are left in the example for readability. Class object can also be acquired indirectly by using j.l.Class.forName(String). In this way, type information could be only retrieved from the String argument of this method. However, such strings can also be obfuscated, attaining almost complete type information hiding. We later show how this can be achieved. If this is done with non-default classloaders, classes can be dynamically loaded from everywhere and any representation (e. g., encrypted ﬁles retrieved from the Internet). We additionally remove annotations which are not required by the virtual machine but which “leak” type information, such as the signature of a method.

Applying all these techniques on a method reduces the visible types to only basic Java ones, particularly from the Reflection package. In summary, we access fields and arrays and invoke methods including constructors indirectly over reflection. We also pass parameters as Objects whenever possible, making the type-checking a runtime-only operation. Class objects are also accessed indirectly and we only cast primitive types (and arrays) back to their corresponding types. If required, we also apply 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 stored in a local anonymous array without revealing its type.

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

112 5.3 Program Analysis Assumptions & Obfuscation Methods

Listing 5.2: Indirect static ﬁeld and local array access without revealing the object type. Code in lines 4–6 is replaced with semantically equivalent code from lines 8–15. 1 const/4 v2, #int 1 2 new−array v1, v2, [Lj/l/String; 3 4 sget −object v0, Lexmpl/Main;. aField:Lj/l/String; 5 const/4 v2, #int 0 6 aput−object v0, v1, v2 7 8 const−class v9, Lexmpl/Main; 9 const−string v10, "aField" 10 invoke−virtual/range {v9, v10}, Lj/l/Class;. getDeclaredField:(Lj/l/String;)Lj/ l/reflect/Field; 11 move−r e s u l t −o b j e c t v8 12 invoke−virtual/range {v8, v9}, Lj/l/reflect/Field;.get:(Lj/l/Object;)Lj/l/ Object ; 13 move−r e s u l t −o b j e c t v0 14 const /4 v2 , #i n t 0 15 invoke−static {v1, v2, v0}, Lj/l/reflect/Array;. set:(Lj/l/Object;ILj/l/Object ;)V

Checksums: Checksums are calculated over parts of or whole ﬁles by using hash algorithms, and changes to the ﬁle most likely change the checksum.

Occurrences: Counting ﬁle sizes, number of classes, ﬁelds, methods, or instructions to name but a few can be used to detect similar programs. This however is easily avoided by changing, adding, or removing (unused) parts of a program.

Strings and Literals: In order to save disk space and memory, all unique strings used by an app are stored in an array called string section and are referenced by an index. In practice, this means that all identiﬁers, types, and strings deﬁned with const-string instructions, as well as all other strings used by, e. g., annotations or debug symbols are located in this one array.

Strings and static numerical values used within a program do not only give an analyst an overview of the programs intents, but can also be used to detect repackaged applications. Thus, hiding that information is a very effective technique to thwart any analysis attempts which rely on such information. Our tool replaces all instructions which define or reference such information with a method invocation returning the value from an encrypted data structure stored somewhere in the app. Special care has to be taken for the constant values 0 and 1, as they can also be interpreted as primitive booleans and the null-reference. There are also no opcodes to directly declare a primitive value of some specific type, this is done implicitly based on its value, or in the case of methods, by their return type. This means that in some cases manual casting is required.

113 5 Change of Ends: Obfuscating Android Applications

Entry Points: Android explicitly declares all possible entry points in the Manifest file of the app. Many tools analyze entry points and attempt to detect maliciousness or duplication of known software. Therefore, while renaming classes we also pay attention to rename the entry points when needed. Adding new entry points may also affect the detection. As a common practice to export functionalities to other applications is by using intent filters instead of names, we can safely rename all not-exported entry points.

Permissions: As many tools use permissions to rank the suspiciousness of applications, 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 permissions [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 frameworks that work at the source code level. If the decompilation process can successfully be hindered, such tools cannot perform the analysis completely. Decompilers exist which try to generate Java source code from DEX bytecode or smali code (a disassembled version of the former) while others ﬁrst convert it to Java bytecode. We later report on the robustness of such tools and evaluate how they cope with artiﬁcially generated bytecode constructs.

5.4 Evaluating the Robustness of Analysis Tools

We implemented a tool that is capable of obfuscating arbitrary Android apps with the techniques introduced in the previous section. In the following, we study how such obfuscated apps are handled by common analysis systems. We ﬁrst discuss static analysis tools followed by their dynamic counterparts. Afterwards, we show how decompilers can be defeated. Following this, we evaluate how well antivirus products can detect well-known, but obfuscated malware samples. Although we do not intend to abuse bugs in analysis systems in order to prevent the analysis, we still found many bugs during our empirical evaluation. We end this section describing a few found bugs which lead to failed analyses or even broken devices.

We evaluated several analysis systems with self-written samples that exhibit detectable behavior targeted to the analyzers and which are obfuscated with the following methods:

• Most strings, literals and types are obfuscated;

114 5.4 Evaluating the Robustness of Analysis Tools

• classes, methods, ﬁelds and arrays are only accessed indirectly;

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

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

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

5.4.1 Static Analysis Systems

We begin our evaluation of analysis systems with static analyzers. All of these systems are from academia and are freely available. Due to our heavy modifications, such tools should have many difficulties performing their actions. Our tool decouples the call graph almost completely, and therefore static tools cannot properly analyze the 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 to produce 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 and sources, i. e., Intents, Receivers and Content Providers. They additionally analyze which information (type) is communicated. Epicc [172] and ComDroid [55] are unable 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 sinks if all types are hidden and aborts the analysis. DIDFAIL [131] performs similar analyses as the aforementioned tools, but was not able to start the analysis on any of our test samples—it did indeed fail. All tested tools generate no results on our test samples after they are obfuscated. The only information available to these tools is the information deﬁned in the Manifest ﬁle. Without the information where data is generated and sent to, no analysis can be performed.

Other tools which work in a similar way should suﬀer the same fate. Saaf (cf. Chapter3) for example is not able to retrieve meaningful information from generated program slices. Analysis results also miss relevant information and cannot be used

115 5 Change of Ends: Obfuscating Android Applications to understand the program’s semantics. Permission analysis tools like Stowaway should 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 Java source code. This implies that the application must be decompilable, and for our tests we did not hamper decompilation. We provide a detailed analysis of how this can be done later in Section 5.4.3. In general, all tools that rely on the detection of called methods and accessed types should fail, as the information is not there. Only dynamic 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 following reasons. According to the description provided by SymDroid [122], all required framework classes used during evaluation are just modeled. Since we are time- wise unable to model many missing Android framework pieces for our tests, we are 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 analysis made through Soot can easily be interrupted. Additionally, the tool will likely encounter 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 test applications [27] while not covering all possible paths. Due to these restrictions, we also refrained from evaluating it as we do not believe it can generate suitable results for our test application—let alone the addition of opaque predicates.

Our results clearly show that automatically applied obfuscation to programs completely defeats static analyzers. Most information accessible by them is only of generic value and does not lead to informative analysis reports. The heavy use of reﬂections can be ﬂagged suspicious by such tools, but it cannot be used solely for tagging 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 not have any difficulties in detecting suspicious behavior. To test such systems, we wrote four applications which exhibit malicious behavior, but do not contain known malicious code detected by any antivirus software. All our applications display a “Hello World” Activity while invoking additional functions. The first application creates three threads that each do at least suspicious actions. The first sends an SMS with static text to a hardcoded number, while the second one accesses the Browser’s search terms and sends them unencrypted over a TCP socket to one of our servers. The third one behaves like the second one, but steals the IMEI. Our

116 5.4 Evaluating the Robustness of Analysis Tools

Table 5.2: Results for dynamic analysis services. Vendor Direct Sleep Alarm EmuDetect Network Taints Anubis ForeSafe n. a. Mobile Sandbox NVISO Tracedroid 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 service using Android’s AlarmManager, triggered after 5 minutes. The forth application ﬁrst attempts to detect whether it is running in an emulator and if the test is negative, it sends an SMS and steals the IMEI. We chose the aforementioned actions as they are often used by malware and should therefore be reported by analysis systems. All tests are implemented in a straightforward fashion, meaning that, e. g., the SmsManager was accessed and an SMS was directly sent with values directly declared in that method and should be easily detectable.

Our emulator detection is rather simple as advanced ones are surely to be undetected and would therefore cancel our suspicious actions, as has been shown by Petsas et al. [187]. We check against well-known IDs which default to known values in the emulator: Build.Hardware, Build.Model, Build.Product, the network operator’s name, IMEI, and the Android ID. As these are hopefully changed, we perform an additional test. We include the Google Play Services library in our application to check whether the Play services are correctly set up on the device and whether a connection to them can be established. If that succeeds, we retrieve the Android Ad ID. The last check is not complex, but requires a fully set up Google Play environment. 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 academic analyzers in Table 5.2. Satisfying analysis results—meaning the analysis system was resistant to our modiﬁcations—are marked with an “” and information not available with “n. a.”. Our ﬁrst test application is referred to as Direct, while the others are abbreviated as Sleep, Alarm and EmuDetect accordingly. All test applications are obfuscated. If provided results for that application do not contain hints for suspicious behavior (such as simply marking it as “unsuspicious”), we mark them in the table with a “”. We also check whether the services allow Internet connections and mark it so if our applications connected back to our server.

117 5 Change of Ends: Obfuscating Android Applications

If data is leaked that way, TaintDroid is able to tag such data and to report if tagged data is being accessed by a sink. As we mentioned earlier, we make use of techniques which try to lose such tags once attached to data. If leaked information is being sent back to us and the report does not provide information about tainted data, but does so in other reports, we know that our anti-tainting techniques are successfully applied to leaked data. Lost taints are marked with a “”. If tainted data is not specifically 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 demonstrate many shortcomings of existing analysis methods as we discuss in the following paragraphs. Anubis [2] for Android, also called Andrubis, displays results in a nice manner on their webpage and also presents a screenshot of the analyzed app. The reports also contain a section where all sent network data is listed on a host basis and one can easily see which data was leaked. A network dump can additionally be downloaded. Anubis also assigns a malicious value ranging from 0 (likely benign) to 10 (likely malicious) to tested applications which for our samples always marked them towards malicous, sometimes with a high value of ~9. Anubis successfully analyzed the Direct and Alarm samples but failed for the Sleep and EmuDetect samples. 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 the IMEI, the used emulator has not changed any identifiers and no valid Google Account is set up, leading to an easy detection. Dynamic results provided by Mobile Sandbox [210, 15] look very promising. It is the only analyzer which is able to correctly analyze all but one test sample and only fails the emulator detection test because no valid Google account is available. It is therefore the only system which changes all checked emulator identifying strings but 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 “confirmed malicious”. All the information are available, although some can only be found in the provided PCAP file. The report does not directly show that browser searches or the IMEI have been leaked. This seems to be caused by our anti-tainting, as other reports contain such information. Still, the sending of the SMS is flagged red in the report and contains the destination as well as the text part. The connection to our server is also listed. Unfortunately, all other applications are ranked as “no malicious activity detected” and no malicious activities are detected. The used emulator only reports a changed IMEI—all other identifiers are set to their defaults.

118 5.4 Evaluating the Robustness of Analysis Tools

ForeSafe [86] analyzed our samples and provided us with a screenshot of our running application, meaning, the app could be started successfully. The report of the dynamic analysis rates our app with a “No Risk Detected”. There was no mention about any of our performed activities. Since nothing risky was detected, we checked ForeSafe against our non-obfuscated sample and then at least the sent SMS was detected with the correct destination and text part (but also did not ﬂag the app as suspicious). No identiﬁers are changed during our tests, making the emulator easily detectable.

The last analysis system we report on is Tracedroid [229]. The reports about our test samples contain a lot of information and provide a complete trace of the programs. Even calls done reflectively are listed with the used parameters, making it possible to see all the invoked methods, accessed classes, and fields. Reports are provided in text files for each thread containing the execution trace, so an analyst has to look through them, or better, parse them for relevant activities. Still, the reports completely reveal what happened while executing the application. A screenshot 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 is easily detectable and malicious activities can be suppressed.

In addition to the analysis systems listed in Table 5.2, we also tested other known systems, but failed to do so for various reasons. AnaDroid’s web page [142] was unreachable. CopperDroid [195] was not able to analyze our applications and the author 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 an even older version, namely Android 2.1. VisualThreat [233] just responded with an “unknown error” after some time. The non-obfuscated “direct” sample was analyzed correctly and marked as suspicious. After our samples were uploaded to SandDroid [17], no feedback was provided at all although reports for other applications were updated on the webpage. Unfortunately, we got similar results for AndroidSandbox [34] (v. 1.0.0.15). Both tools were also unable to analyze our unobfuscated samples, meaning some characteristic of the samples pose problems for them. We can just guess that some problems are related to the included Play Service library which is large and complex, or that Google APIs are missing in the analysis environment.

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

119 5 Change of Ends: Obfuscating Android Applications

Table 5.3: Decompilation results for diﬀerent test cases.

GO1 GO2 CHO CT DC BC SM RSA MC jadx ()() dex2jar W ∅ ()I Dare (JD-GUI) W II ()I Dare (Soot) M I ()() systems, we can conclude that many have problems analyzing our obfuscated test samples correctly. In the end, we only got satisfying results from two tested system, namely Mobile Sandbox and TraceDroid. Although both did not pass the emulator detection test and TraceDroid did also fail the sleep test, a combination of those two systems would be beneﬁcial while analyzing obfuscated samples.

5.4.3 Decompilers

In this section, we report on the results when testing four freely available decompilers for Android applications, namely jadx, dex2jar with JD-GUI, Dare with JD-GUI and Soot. These decompilers try to transform DEX code to a Java-equivalent and are used by some analysis tools as well as in manual analyses. We present and test different code constructs allowed by DEX which do not exist in Java with the aim of confusing decompilers. We now present our test cases and condensed results can be found in Table 5.3 where we use the following notations: If the test case is handled correctly, we assign a “”, and “()” 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 recompiled without further modifications. Syntactically correct code which reflects different semantics will be marked as “W” describing wrong code. If some instructions are missing in the Java code, we note that with an “M” (meaning that code can be hidden from such tools) and test cases which result in completely empty methods are marked as “∅” if no errors are reported meaning that code can also be hidden in this case. If the decompiler is not able to obtain any results for a method, but raises an exception (when that happens, decompilers often print a dump of the DEX code), we mark it with “ ”. Goto Instruction (GO1/GO2). The goto instructions in particular can pose problems to decompilers, as there is no direct equivalent in Java and the code can jump

120 5.4 Evaluating the Robustness of Analysis Tools

almost arbitrarily inside a method, including between catch handlers. Imagine a method as shown in Listing 5.3 where the invoked method will never throw an exception (with rare exceptions such as in out-of-memory scenarios). Still, the invocation is covered by a try-item which speciﬁes two handlers. The problem here is that both handlers refer each other and form a loop (line 3–4). While executing the shown method, these handlers are never touched. In Java, each handler forms a new scope and cannot interfere with other handlers, making this construct impossible. All decompiler crash with this test (GO1) while handling the method with the exception of Dare (Soot) which completely ignores the try-catch clause. In the second test (GO2), we tested how decompilers handle the goto/32 instruction referring to itself. Example code is shown in Listing 5.4. The code jumps to the invocation of a method and then enters an inﬁnite loop (line 2), which is completely legit in DEX. Only Dare (Soot) works correctly by substituting the instruction with an empty while (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−static/range {}, Lsome/Class ;.someMethod:()V 2 0x03: goto 0006 // +0003 3 0x04: goto 0005 // +0001 4 0x05: goto 0004 // −0001 5 0x06: return −void 6 c a t c h e s : 1 7 0x00 − 0x03 8 Lj/l/NullPointerException; −> 0x05 9 Lj/l/RuntimeException; −> 0x04

Listing 5.4: Misuse of the goto instruction, example (2). 1 0x00: goto 0004 // +0004 2 0x01: goto/32 #00000000 3 0x04: invoke−static/range {}, Lsome/Class ;.someMethod:()V 4 0x07: goto 0001 // −0006 5 0x08: return −void

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

121 5 Change of Ends: Obfuscating Android Applications

Listing 5.5: Wrong exception handler order. 1 0x00: const v0, #int 42 2 0x03: invoke−static/range {}, Lsome/Class ;.someMethod:()V 3 0x06: return −void 4 0x07 : add−int/lit16 v0, v0, #int 1 5 0x09: goto 0006 // −0003 6 0x0a : add−int/lit16 v0, v0, #int 2 7 0x0c: goto 0006 // −0006 8 c a t c h e s : 1 9 0x03 − 0x06 10 Lj / l / Exception ; −> 0x0a 11 Lj/l/RuntimeException; −> 0x07

Clashing Types (CT). In DEX, some registers can have different types depending on the usage. The instruction const v0, 0 for example assigns the DEX type ZERO to register v0. This type can then be interpreted in multiple ways: for reference types it refers to a null reference, for booleans to false, and for primitive literals 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 an Object.

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

Bogus Code (BC). For this test we inject an unused class with a method containing invalid instructions. Such a method would be rejected by the Android Veriﬁer during runtime, if accessed. As the class is unused, the application will still be installable and executable. A subtle example would be, e. g., a method invocation using a register holding an uninitialized reference. We quickly found code where all decompilers bail out with an exception. With the sole exception of jadx, all tools stopped working completely while analyzing the method in question, skipping the rest of the program and providing no output in the end. jadx only threw an exception 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 that the construct was generated by the compiler and has no counterpart in the source

122 5.4 Evaluating the Robustness of Analysis Tools code. Bridge methods are treated as such. All decompilers correctly handle the code (thus ignoring the synthetic modiﬁer—jadx also points out its presence by adding a comment to the class)—with the exception of dex2jar which completely hides the content of the class or method.

Removing Signature Annotations (RSA). DEX stores information about types in generic containers inside Signature annotations when needed. This is done in order to deliver the information about what is being contained, e. g., in a List for debuggers. When removing signatures, the tested decompilers are unable to infer types correctly. This causes missing type information with all tested compilers, but may also break applications leveraging that information during runtime.

Modifier Changes (MC). Modifying access flags can also cause different results with different decompilers. In Java, an enumerated type extends j.l.Enum implicitly and thus cannot extend any other class. However, in DEX it is possible to declare any class with an ENUM access flag without runtime side effects. When decompiling such bytecode, dex2jar will mark the class as an enum and omit the superclass 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 at least four out of nine test cases and no test case is handled by all tools with the exception of simply removing type information. Automatically creating such code reliably hinders the analysis of an obfuscated application if the analysis depends on decompiled 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 obfuscated references there. Annotations can also be removed to some extent as well as debug information. Applying all these actions leaves almost no original strings in the DEX file and comparisons based on strings will likely not work anymore. Leftover types are 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 and can also create bogus fields. Counting instructions or the ordering of them will also

123 5 Change of Ends: Obfuscating Android Applications likely fail, as many instructions originally present in DEX code will be replaced with other 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 our obfuscation. Although it is not our primary goal, it is of interest to evaluate whether or not our strategies are able to evade antivirus systems, since they are often utilized to protect common users against malware. It has been previously shown that antivirus solutions are vulnerable against obfuscation attacks [247, 194]. However, such attacks were rather simple and were tested only on a reduced number of samples and antivirus solutions. In our experiment, we test our obfuscation techniques against more than 50 antivirus solutions provided by VirusTotal [101], which provides a huge number of desktop-based solutions that are also able to detect mobile malware. 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 well as individual DEX files, because APK files contain additionally assets, images, resource files and external native libraries that are subjected to analysis while being independent of the obfuscation on the DEX file. We test the effectiveness of our strategies on the samples of the ContagioMiniDump dataset [156] for mobile malware, composed of 237 samples collected until July 2014. We chose this set as it is publicly available and therefore all samples should be known to antivirus vendors. All samples are obfuscated with the previously described techniques. With respect to desktop solutions, we observe that only 3 out of 50 engines were able to detect more than 90 % of DEX obfuscated samples. Another two engines exhibited detection rate values of 50 % and 60 %. Moreover, 36 engines completely failed at detection. Things improved when analyzing APK files, where some vendors showed better performances. This is likely caused by detection logics that also factor in additional files next to the DEX file which we do not modify. Detailed analysis results are listed in Table 5.4. In order to present meaningful results, we show results for both 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 0 AegisLab 236 21 1 1 Ikarus 236 147 236 38 McAfee-GW-Edition 235 10 235 0 Commtouch 235 12 234 0 Continued on next page

124 5.4 Evaluating the Robustness of Analysis Tools

Table 5.4 – continued from previous page

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

125 5 Change of Ends: Obfuscating Android Applications

Table 5.4 – continued from previous page

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

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

Since the engines supported by VirusTotal mainly target the x86 architecture, it is not guaranteed that they feature mobile-dedicated signatures. For this reason, we repeated the same test on 13 mobile antivirus solutions. We refrained from using AndroTotal [149] as its service was slow by the time of testing. We used a self-build framework 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 DEX ﬁles are in this case essentially the same, with a slight increase in detection results. Obfuscated ﬁles are detected much better with huge leaps in detection rates for some vendors. Vendors who already performed well for their x86 counterpart usually also produced good results with their mobile product. The labels for obfuscated samples

126 5.4 Evaluating the Robustness of Analysis Tools

Table 5.5: Contagio Minidump AV detection rates for mobile AV solutions (N=237).

Vendor .apk .apkobf .dex .dexobf Comodo 236 136 236 135 Avg 235 215 234 214 G Data 235 226 235 226 F-Secure 232 179 229 76 McAfee 231 70 230 58 DrWeb 230 118 230 106 Zoner 229 0 28 0 Kaspersky 216 216 216 229 Avast 210 206 210 206 ESET 210 210 210 207 Trendmicro 210 209 209 176 Symantec 204 114 114 101 Webroot 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 tools and systems which enabled us to completely evade analysis attempts. Such bugs are often only implementation bugs or corner cases developers did not anticipate. We therefore focused on taking away the assumptions the tools rely on rather than exploiting 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 checking for packages to be installed, causing a variety of problems. It is possible to cause a Denial-of-Service attack with specially crafted DEX files, forcing the device to reboot and leaving it in an unbootable state, as the same file will be verified on subsequent 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 the only solution is to perform a factory reset.

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

127 5 Change of Ends: Obfuscating Android Applications of the install user. We were also able to modify DEX ﬁles making the application to crash immediately if a debugger is being attached to it.

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

While the restrictions for valid identiﬁers are stricter in Java than in DEX, it is possible to create names that may cause problems whenever an analysis application is enforcing the type checks on Java types. For instance, the jdb debugger does not allow setting a breakpoint on a method if the identiﬁer is invalid in Java.

5.5 Implementation and Performance Evaluation

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

5.5.1 Implementation

Our tool is written in Java and heavily extends dexlib which is part of the smali tool [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 order to properly obfuscate it whilst retaining program semantics. Our tool accepts a DEX or a complete package (APK) file as input. We directly rewrite DEX bytecode without converting it to have full control for modifications, while requiring to also deal with all of its limitations.

Google introduced a new runtime environment called Android RunTime (ART) for Android applications in Android 4.4 as a successor to Dalvik. In the next Android version (codenamed Android L), it will be the default runtime. Therefore, a strongly desired feature is compatibility with it. While we are working on the bytecode and the instruction set has not changed, ART still contains a completely new compiler along veriﬁcation 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 the future.

128 5.5 Implementation and Performance Evaluation

We tested our tool against a variety of popular apps oﬀered in the top categories on Google Play. We tested these applications to see whether they still continued working after our obfuscation is applied. We found that many applications run without 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 obfuscation process with our current prototype implementation. Some applications cannot be obfuscated by our tool correctly as we fail to precisely handle type-information in some cases. This might be related to wrongly used bootclasses, which describe framework classes and so on: if these change for diﬀerent API versions, information retrieved from the used bootclasses might be wrong. Other applications simply trigger implementation bugs in our obfuscation logic, which leads to broken code that often still passes the veriﬁcation process upon installation. Examples of apps that 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 of apps as these are important factors for the obfuscation. We start with artificial benchmark results to get an idea of how large the slowdown can be if an application is obfuscated. We wrote four small test cases for this example. In our first test, we open 200 sockets and immediately close them again. Our second test creates 200 files and the third test creates 100 Java processes which execute the “id” command in a shell while reading its output. The last test loops over an array of 10,000 primitive integers and sums them up. Since operations occur on primitive types, they are not obfuscated. The looping condition checks whether the last array position has been visited, and this array-length instruction is performed indirectly in each loop iteration.

Each test is performed exactly twelve times while the best and worst timings are discarded, and an average is taken from the remaining ten values. The results for two diﬀerent smartphones are listed in Table 5.6. All of our described obfuscation techniques in Section 5.3 have been applied. The Galaxy Nexus runs Android 4.3 with Dalvik and the Nexus 5 runs the preview of Android L with the new ART runtime.

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

129 5 Change of Ends: Obfuscating Android Applications

Table 5.6: Artificial benchmark results. Values in seconds. Device Obf. Socket File Process Array Nexus 5 (ART) 0.7756 0.1581 2.4756 0.0127 Nexus 5 (ART) 1.4549 0.9422 2.6515 0.4890 Galaxy Nexus 1.5791 0.1972 1.6423 0.0375 Galaxy Nexus 1.9243 0.8896 2.7481 0.8598 which is barely slower. The second worst overhead is introduced for the file creation test on the same device which is almost six times slower. The worst slowdown is introduced for the array-test. This test clearly shows how huge a slowdown can be if only one single instruction is exchanged with a semantically equivalent call over reflection. On the Nexus 5 the obfuscated sample is about 39 times slower. Modifying instructions in loops which can otherwise be efficiently optimized by the runtime can lead to enormous slowdowns.

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

Besides runtime overhead, we also evaluated how our obfuscation aﬀects the size of obfuscated applications. Since several instructions are replaced with multiple ones, the size can quickly grow and we found that the application’s size increases by approximately 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 other techniques enabled. While they still can analyze generic aspects of applications, the need to further distract them with additional entry points is unnecessary. Dynamic analyzers also did not require that feature since all but one emulator can easily be detected with simple tests. The automatic injection of opaque predicates is also absent. Right now there is no dynamic tool that could be irritated by it—static tools based on symbolic execution could compute path constraints, but they cannot analyze the semantics and all tools known to us are in a rough prototype state. We also omitted techniques like method merging and inlining as well as moving methods and fields around. Dynamic analyzers are not affected by this effect and static ones are already blind with respect to the performed obfuscations. We also do not obfuscate literal values of 0 and 1, due to the fact that they have multiple use-cases. While it is doable to obfuscate lots of them, some cannot be changed without making larger modifications to the DEX code, as the same value may be re-used in different codepaths.

5.6 Discussion

In the following, we first discuss the limitations of our tool and how they can lead to semantically different execution or even broken code. We also explain how limitations could be fixed in future versions of our obfuscation tool and conclude our work. Renaming classes, methods, and fields can be tricky for event-driven applications. For Android, the framework itself executes well-defined entry points which can be obfuscated if the definition is appropriately changed in the Manifest file. If some application leverages the names of the entry points instead of provided Intents, we cannot be sure that the existing client application continues to work after obfuscation. 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 or methods 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 other libraries. One notable example is the Bundle.CREATOR field. This behavior is also exhibited by some object mapper libraries, such as the one provided by the Jackson JSON library, which map dynamic data to pre-existing objects. Without analyzing the behavior of the application by, e. g., performing a runtime analysis, it is hard to know which elements can be freely changed. We also do not currently implement the

131 5 Change of Ends: Obfuscating Android Applications 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 than usually. Accessing such objects by addressing their (original) name directly works fine, though.

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

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

Our obfuscation can of course not directly hide executed code against dynamic analysis. The only way to mitigate this is to detect such analyzers and stop or divert the execution. This is a generally unsolvable problem, though. By utilizing static or dynamic instrumentation frameworks and dynamic analyzers in general, it is always possible to deobfuscate a program as the runtime semantics must stay the same. Applied obfuscations in general make this task time consuming and it requires 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 and using ART instead of Dalvik gives us already promising speed-ups to the performance. In order to minimize the performance penalties, we could store looked up objects such as decrypted strings and methods in a cache. This would speed up execution especially when something is being fetched while in a loop.

Our test results let us conclude that many analysis tools are not capable of analyzing obfuscated apps in a satisfying manner. The situation for static tools is particularly bad. This result, however, was expected for such tools as obfuscation in general greatly 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 analysis systems becomes dysfunctional by simply modifying the DEX code such that decompilers cannot process it anymore: Namely all tools that require Java source code. Malware authors who obfuscate their malicious apps do not have to fear static analyzers as the effort which has to be put into deobfuscating such malware in order to get usable results is high. Additionally, many antivirus products fail at detecting our obfuscated apps and, even when samples are detected, many signatures are completely invalidated, as our tests show. Dynamic analysis systems are much more robust against code modifications, as executed 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 a lot 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 work flawlessly 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 whether the IMEI is set to something different than its default value. Sophisticated malware cannot easily be analyzed by such systems, as one can expect that they actively try to detect analysis systems. The worrying aspect is that the code modifications as described in Section 5.3 can be automatically added to a given (malicious) app. The intentions might not always be evil—as many software authors just try to protect their code and labor—but the impact on analysis systems is huge. Malicious software can easily piggyback obfuscated apps and clandestinely execute their payload while most detection systems remain blind. Since obfuscation techniques will not vanish and the usage of the Reflection API will likely not be restricted on Android (and if so, code would just be moved to native libraries which enjoy an even greater freedom with respect to their instruction set), we need tools that properly analyze well-obfuscated applications. Dynamic tools are the usual way to go, but the emulation detection mechanisms must still be pinpointed and disabled. A combination of static and dynamic instrumentation could help here and more research on this topic is needed. Another aspect is to move monitors and other analysis components directly into the hypervisor of modern smartphones to improve the precision of analysis methods. Availability: To foster research on analysis of obfuscated Android apps and increase the robustness of existing methods, we plan to offer a web service such that arbitrary apps can be obfuscated for research purposes.

133

6 Enhancing Other Devices’ Security with SmartProxy

We now present our work which leverages smartphones in order to enhance the security of normal PCs. This chapter results from a publication [111] at the Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA) in 2012 in cooperation with Sebastian Uellenbeck and Thorsten Holz. This work has been supported by the Federal Ministry of Education and Research (BMBF grant 01BY1020 – MobWorm).

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

To relieve the user from the trust he or she has to grant to these computers, we propose a privacy proxy called SmartProxy, running on a smartphone. The point of this proxy is that it can be accessed from untrusted or even compromised machines via a WiFi or a USB connection, so as to enable secure logins, while at the same time preventing the attacker (who is controlling the machine) from seeing crucial data like user credentials or browser cookies. SmartProxy is capable of handling both 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. Our solution combines the security beneﬁts of a trusted smartphone with the comfort of using a regular, yet untrusted, computer, i. e., this functionality is especially appealing 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 systems, we are still observing security incidents happening on a daily basis. Attackers have managed to compromise the integrity of computer systems, as techniques such as control-flow attacks on software systems or exploiting logical flaws of applications were developed [22, 95, 165, 203]. Due to the growing complexity of today’s systems, it is highly unlikely that we will have trustworthy computer systems without any security flaw at our disposal in the near future. We thus need to investigate how certain security properties can be guaranteed despite compromised computer systems being in operation. In this chapter, we focus on the threat of stealing user credentials from web browsers. More precisely, the attacker’s goal often entails illegal gathering of user credentials such as passwords or browser cookies from an already compromised machine. Several reports on malicious software specialized in stealing credentials provide evidence for the prevalence of this threat (e. g., bots and keyloggers) [88, 113].

In practice, we do not only need to worry about the integrity of our personal (home or office) computer, but of each and every machine we interact with and enter our credentials into. Surfing on public Internet terminals, using computers in Internet cafés, or simply browsing the web on an arbitrary in-office or friend’s computer can all bring about a number of potential threats. A golden rule of thumb for our safety is that we cannot trust any such machines, or going one step further: We have to assume that they have been compromised. Still, all things considered, protecting the 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 over the system and can modify the settings in an arbitrary way. Furthermore, she can read all memory contents, the CPU state, and all other information pertaining to the current state of the system in question. Based on the so-obtained data, an attacker can easily reconstruct (user) credentials [106, 108] as it becomes harder (if not 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 devices and 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 changes on 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 the authentication tokens can be accessed by a skilled attacker or that the key is dirctly extracted from the device itself [176]. A different idea is to use an external device with more computational power as a trusted intermediary supporting the authentication routine [47, 121, 238]. Such approaches typically either require changes on the server side or an additional server that needs to be trusted. As a result, they are typically not compatible with existing systems or trust needs to be put into another device not under the user’s control.

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

Since the phone is a potential target for the attacks, we also make sure that we split the transferred information in such a way that even if an attacker compromises both the machine and the smartphone, she at least cannot steal all data at once. This is achieved 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. We have implemented a fully working prototype of SmartProxy for Android-based devices. Our evaluation demonstrates that the overhead introduced by the tool is reasonable: Micro-benchmarks indicate that the SSL handshake typically takes less

137 6 Enhancing Other Devices’ Security with SmartProxy than 42 ms on a current smartphone, while in macro-benchmarks we found a typical overhead 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 be used to preserve credentials in spite of the presence of a compromised machine that an attacker controls. • We have implemented a fully-working prototype and our performance benchmarks 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 discuss related work in this ﬁeld in the next section. We then present our attacker model and a brief overview of our proposed system in Section 6.3. Thereafter, in Section 6.4, we exhaustively describe how SmartProxy accomplishes our goals, and how a connection between the computer and a smartphone can be established, as we at the same time scrutinize and evaluate the security implications of our framework. Next up follows 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 solution and 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 solve similar problems as we discuss in the following. Mannan and Oorschot [150] proposed an approach to secure banking transactions by using a (trusted) smartphone as an additional trust anchor. In a very similar approach, Bodson et al. [66] proposed an authentication scheme where users have to 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 for the authentication to be performed there externally. To fulfill their needs, both approaches had to implement server side changes. Conversely, one of our main goals is to only alter the client’s side by adding a self-signed root certificate to a browser and 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 a working 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 the user wants to authenticate against. The authentication requests are sent via short messages (SMS) in this setup. By doing this, the authors mitigate the risk of MitM attacks, but have to trust the safety of the user’s computer, which in our scenario might as well be compromised.

Balfanz and Felten [33] developed an application that moves the computation of email signatures to a trusted mobile device so that the untrusted computers can be used without revealing the key to the intermediary computer. However, this approach is limited in the application scope.

Burnside et al. [47] proposed a solution for a similar problem: They want to surf the web with an untrusted computer and get alerted when the received data is different to the data sent by the web server. Unlike the idea behind our approach, they do not examine 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 with the web server from which the user requests data from on another. Requests are sent from the untrusted computer to the user’s proxy which then forwards them to the designated web server. Following this action, the user must take a picture of the untrusted computer’s screen with a smartphone camera. This photo is later on transferred to the proxy in order to let it analyze the data depicted. The proxy can then decide whether the information the user can see on the untrusted computer’s screen is changed by someone in the middle, and if this is the case, it will alarm the user immediately. The downside of this approach is that it only catches “visual modifications” and not injected JavaScript or similar processes, thus it does not protect 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 idea behind Janus is to enable simple, secure and anonymous web browsing. Credentials and email addresses are automatically and securely generated with the help of a proxy server for HTTP connections. The proxy assures that only secure credentials and no identifying usernames and email addresses are sent to the web server. In contrast to our work, Janus does only support SSL secured connections from the proxy to the web server and the proxy resides on the client machine, which does not ﬁt our attacker model (c. f. Section 6.3.1). It does also not handle other security relevant information like cookies which our approach does.

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

139 6 Enhancing Other Devices’ Security with SmartProxy

6.3 System Overview

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

6.3.1 Attacker Model

In the following, we assume that an attacker has compromised a computer system and thus has complete control over it. This allows her to obtain the system state’s full information and enables arbitrary modifications. On a practical level, this might be the case when an attacker managed to infect a computer with some kind of malicious 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 system and symmetric ciphers with reasonable parameters, i. e., we assume that unless the used key is known and out in the open, the used ciphersuites cannot be broken by the attacker. As a special action, the attacker might disable our proxy for the web browser. Doing this will only result in a denial of service attack against the user, as long 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 as Facebook or Wikipedia needs to have valid user credentials. Essentially, he has no simple means to decide whether the machine he wishes to put to work is indeed compromised or not since it is not a machine under his control (e. g., a public Internet terminal or an arbitrary in-office computer). He may also simply not know how to verify the integrity of the machine in question. Overall, it is a complex problem in itself and we assume that the user cannot efficiently assess whether the endangerment has taken place or not. Luckily, the user has as an auxiliary means of resorting to his smartphone which he can, to a certain extent, trust. We suppose for now that the smartphone has not been compromised, which implies that the user can run software on the phone without having to worry about an attacker. At the same time, we understand that the user wants to surf the Web on a computer rather than a smartphone since it provides a larger screen and a natural-sized keyboard. In addition, the computer has more computational power, as it is for example capable to render complex web content quickly and with ease. Based on these assumptions, the goal of our system can be clearly indicated as enabling the user to log in to a website without vexing about his credentials. We focus on the HTTP and HTTPS protocol, connections with arbitrary protocols over sockets 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) nor obtain any information about them. Note that the system cannot protect the web content on the computer as the attacker is already assumed to be able to read all information on that device. For that reason, the attacker can still read as well as modify all content accessed by the user, yet she cannot log in on the website at a later point in time as all valid user credentials are no longer there to be taken away.

In addition, we need to make sure that an attacker cannot obtain credentials by compromising the smartphone. This would imply that our system has a single point of failure. Even if the attacker can compromise both the computer and the smartphone 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 warrant that an attacker can only observe the data which are evidently made use of in real time.

6.3.2 Approach

As stated previously, in order to protect user credentials from an attacker operating a 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, as it depicts the flow of information in the system. As a preparatory step, the user needs to configure the web browser on the computer in such a way that it engages the smartphone as a web proxy for HTTP and HTTPS traffic. As we discuss in Section 6.4.2, there are quite a few different ways for a smartphone being connected to 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).

Smartphone (Compromised) Webserver Computer

1 2 SSL Tunnel 3

Figure 6.1: Schematic Overview of SmartProxy.

141 6 Enhancing Other Devices’ Security with SmartProxy

Once the machine and the smartphone are connected (Step 1 in Figure 6.1), the smartphone transparently substitutes fake credentials entered by the user on the compromised computer with valid credentials, which are then sent to the target destination the user wants to visit (Step 2 in Figure 6.1). The smartphone can perform this substitution by carrying out a MitM attack on the HTTPS connection: Our tool intercepts the initial SSL connection attempt from the computer, establishes its own SSL session to the target web server on behalf of the computer, and transparently substitutes the fake credentials with valid ones. These steps require us to launch a fake SSL connection to the web browser on the computer, for which we spoof a HTTPS session pretending to be the targeted web server. We generate an SSL certificate that corresponds to the targeted server using the root certificate imported in the preparation phase. Thus, this certificate will be accepted by the browser and the user can regard this connection trustworthy. We discuss the workflow of our approach 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 an attacker cannot obtain them when they reach the (compromised) computer (Step 4 in Figure 6.1). Our tool successfully alters information on one hand, yet grants the possibility of a web browser usage on the other. Meanwhile, an attacker does not have the power to obtain any useful information from the processes taking place. More details about this substitution procedure and its security aspects are available in Section 6.4.5.

Eﬀectively, we move the handling of sensitive data from the (potentially compromised) computer to the smartphone, which prevents an attacker from stealing sensitive data. De facto, this carries the problem over to another device which we need to protect: The smartphone turns into an attractive target for the attackers, as it now serves as a primary storage space for all the sensitive data. At the end, we need to be fully conﬁdent that the information is kept and retained in a way that fully prevents an attacker from accessing it, even if she manages to compromise both the computer and the smartphone at the same time. This can be achieved by storing and provisioning information in an encrypted manner. Decrypting this data may only occur strictly on demand, as we explain in detail in Section 6.4.6. The potential damage 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 called SmartProxy. More speciﬁcally, 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 compromised machines is handled by the proxy. We conclude this section with a description of secure storage of private user data within SmartProxy, as it is employed to minimize the attack surface.

6.4.1 Application Overview

SmartProxy is implemented as an Android application in Java and we use the Bouncy Castle library to forge certificates. All services related to SSL are provided by Android’s own SSL provider AndroidOpenSSL. Our implementation of the HTTP protocol supports both HTTP/1.0 and HTTP/1.1 (we implemented a required subset 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), and HTTP pipelining of browser requests. The proxy software includes a graphical user interface on the smartphone, mainly utilized to start or stop the proxy and manage security-related aspects of the tool. More precisely, a user can manage trusted and forged certificates, stored cookies, and user credentials within the interface. The proxy itself listens on two different TCP ports, one for the plain HTTP traffic, and a second one for the encrypted HTTPS traffic. One goal of the design was the minimization of required user interaction since SmartProxy should not become yet another complicated task to deal with at the user’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 ways enumerated in the next section. The browser on the untrusted computer then needs to be configured to employ the smartphone as proxy. This simply requires setting the smartphone’s IP address and the ports as the proxy address of the browser. If it is the first time for engaging the proxy, an automatically generated X509 V1 root certificate has to be exported from the smartphone (e. g., either through the SD card or by mounting the smartphone as an external storage device). It shall later be imported into the web browser as a trusted root certificate destined and valid for signing other websites’ certificates. Once the setup process has been completed, any type of user interaction is required in only two additional cases. First, in the instance where our SSL trust manager is unable to verify a server certificate. In practice, this might happen in several different circumstances, 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 an invalid 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 6 Enhancing Other Devices’ Security with SmartProxy approve the certificate in a dialog on the smartphone. This is a replication of a security model behavior as it can be found in web browsers. If a user accepts the certificate, an exception for this certificate is generated and further on it will be perceived and processed as validated. Second case of user interaction demand is of course linked to the setup of the fake credentials for any website that the user wishes to log in to securely.

In addition to the aforementioned interactions, the user is able to list and delete all stored cookies and edit credentials with their original and substituted values. SmartProxy also enables a user to list and delete all forged and manually trusted certiﬁcations. For example, it might at one point be necessary to issue a removal of a user-trusted certiﬁcate which has been later on proven invalid and shall therefore no 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 web browser running on the untrusted computer is possible in several diﬀerent ways, as we explain in the following.

Computer acting as WiFi access point. A computer provides a wireless hotspot or an ad-hoc wireless network to which the smartphone connects to. The smartphone’s IP is displayed in the user interface and it is this address that is used as the proxy address by the web browser running on the untrusted machine. With this setup, all network traﬃc is “routed back” to the computer and this particular network connection is used for tunneling, as it is likely faster than the network connection available via GSM or 3G networks. Practically, solely rooted Android devices are able to connect to ad-hoc networks because vanilla Android devices do not support this connection mode.

Smartphone acting as WiFi access point. The Android OS is capable of serving as an access point for WiFi-enabled computers. For example, a notebook could connect to the smartphone’s access point and utilize the proxy running on the phone. In this 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 computer will 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 to the PC via the USB port. The phone needs to be configured for the USB tethering and the USB network device on the PC will in this case get an IP address from the smartphone. The smartphone’s IP address can again be displayed within the user interface and is also used as the proxy address in the web browser running on the computer. This configuration routes all traffic through the smartphone’s own Internet 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 smartphone use the same (wireless) network, then the smartphone is accessible from the computer and the computer can easily use the smartphone as a proxy. Furthermore, the smartphone may use the Internet connection oﬀered by the WiFi network, instead of its own GSM or 3G connection. If this setup is possible, it is the easiest to use in practice.

Upon familiarizing oneself with the list of communication methods above, one may notice that all these setups do not require any special access rights on either side. Although the ﬁrst three setups require special privileges on the computer, they are likely to be enabled for all users because setting up a network interface is a common use case for most consumer targeted operating systems. This was an implementation aim for the software to be kept usable in most environments.

6.4.3 Proxy Workﬂow

We now present SmartProxy’s workflow and the different steps that are necessary to enable the filtering of sensitive data. During the preparation stage, we need to connect the smartphone to the computer by using one of the methods discussed in Section 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 certificate must be imported into the web browser. After performing these actions, the actual workflow can start which we discuss in the following. The workflow is also visualized in Figure 6.2:

1. SmartProxy listens for new network connections. 2. When the user opens a website in the browser on the computer, SmartProxy accepts this connection and spawns a new thread which parses the HTTP CONNECT statement.

145 6 Enhancing Other Devices’ Security with SmartProxy

Browser SmartProxy Server

1) Listen 2) Send: "CONNECT" 3) Target SSL Handshake

4) Forge Certiﬁcate 5.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 6.4) Forward Filter Response Response

Figure 6.2: Protocol sequence diagram.

3. SmartProxy opens a TCP connection to the desired web server, initiates an SSL handshake (called target SSL handshake) and verifies the server’s X509 certificate. If it is not trusted or invalid (e. g., the certificate is expired or the attacker on the compromised computer attempts to intercept the connection), the tool ceases the action and notifies the user that an exceptional rule for this certificate has to be generated in the hopes of proceeding with the connection to 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 and store it for later use. The forged certificate is an X509 V3 certificate signed by the proxy’s CA certificate. Note that the user has imported this certificate in the browser in the preparatory phase, thus the browser regards this forged certificate as valid. 5. SmartProxy responds to the web browser with a plain text 200 OK HTTP status code and upgrades the unencrypted TCP connection from the browser to 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 network traﬃc between the web browser and the destination web server is encrypted and will be eavesdropped by the proxy. This and the following step are similar to a normal MitM attack except for the signing part. A more in-depth analysis of 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 served and ﬁltered between the two endpoints. The ﬁltering performed by our tool substitutes fake credential user data entered on the (potentially compromised) web browser with genuine credentials. Furthermore, we remove cookies and other types of sensitive data whilst hiding them from the web browser, as explained in Section 6.4.5. In order to provide some feedback to the user as to when user credentials are replaced, the smartphone vibrates and generates a visual output on each substitution.

This workﬂow corresponds to the SSL-secured HTTP connections, but a very similar approach can be used for plain HTTP connections with only minor modiﬁcations. Steps 3–5 are not needed, and solely standard HTTP requests (e. g., GET or POST operations) have to be processed. We discuss the security implications of plain HTTP 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 assumption that the user’s computer is compromised, we need to presume that an attacker has total control over the machine and therefore can read and manipulate all data, including the input received from the proxy. This indicates that the SSL connection between the web browser and the proxy after the initial CONNECT statement may also be intercepted and is therefore somehow useless. To keep the confidential data hidden from the compromised machine, no encryption between the web browser and the proxy is required, as sensitive data is only transferred in another SSL-secured connection between the proxy and the designated web server. This connection can be guaranteed to remain unreadable by the attacker, even if the traffic is back-routed over the compromised computer. This is ascertained by the verification of the web server’s SSL certificate within the SSL connection between the proxy on the smartphone and the target web server.

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

147 6 Enhancing Other Devices’ Security with SmartProxy supported by the web browsers we have tested. They instead expect an SSL handshake after each CONNECT statement and an SSL “downgrade” to the NULL cipher is not supported. All things considered, this behavior is clearly highly beneﬁcial for general security reasons.

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

In order to keep the number of forged certificates low, hence enabling faster SSL Session resuming (see Section 6.5.1), step 5 from Section 6.4.3 generates forged certificates valid for more hosts than the original ones. If an original certificate is only legitimate for the host a.b.c, its new counterpart will be valid for the following hosts: *.a.b.c, a.b.c, *.b.c, and b.c. These alternate subject names are added to 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 encryption between the proxy and the web browser is suddenly a sound cause for concern. Another skilled attacker might sniff this connection and attempt to break the SSL encryption. This would allow her to observe the connection between the web browser and the proxy over the airlink. Such an attacker might not be detected by 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 has compromised the machine, since both can only observe obfuscated data after the substitution by SmartProxy took place. An attack on the air link can be easily prevented by increasing the keysize to a strength of 2048 bits or more. It is also possible 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 proxy has to change some elements in the data stream between the web browser and the web server. This is accomplished by implementing an extendable set of filters which can be attached to each data stream. These filters can in turn be used to change arbitrary HTTP header fields as well as payload data. When wishing to perform a login on a specific website without inserting the real credentials into the untrusted computer, the first action for a user to carry out is to set these accounts up 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 information is encrypted before it is written into a database (see Section 6.4.6 for details), and can then be used by our filters. Different filters are applied to the process of data modification, which we describe in the following.

Password Filter

Real credentials should not be entered into the user’s computer, therefore one has to 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 the web server for the login’s fulfillment. The Password Filter’s function is to find and replace these fake credentials in the data stream. To do just so, the filter searches the POST data for false credentials, determines if the credentials are indeed entered into valid form fields, and then performs the substitution. Furthermore, credentials are only substituted if the domain in the request matches the stored domain in the database. In order to defeat some attacks, two additional checks are performed before the real credentials are inserted. First, we check if the password was already requested a short amount of time before (e. g., 15 minutes). After a valid login, the user should be identified by some session ID and no credentials should be used anymore, thus this case might indicate an attack. Second, we check if the request contains at least three variables from which two are identical and a fake password. This could mean that 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 ﬁlter that searches for the Authorization ﬁeld inside the request header. In this case, we used the same framework as for the Password Filter, seeing as the user is also required to set up the

149 6 Enhancing Other Devices’ Security with SmartProxy corresponding fake credentials. Currently, our prototype supports the widespread Basic Authentication exclusively and not the lesser used but more secure Digest Authentication. To effectuate this functionality, we only had to substitute fake credentials with their genuine counterparts, just as we perform this in the Password Filter (except for them being Base64-encoded in this particular instance). The filter first decodes the data, then checks for a positive match, substitutes the fake credentials, and finally encodes them back before performing the act of sending them to the server. Note that this filter cannot make use of the rate limit for substitutions as the Password Filter since each request will contain the fake credentials which have to be substituted.

Cookie Filter

A potential attack against our approach could be a session hijacking attack through cross-site scripting. This event involves a session identifier (which authenticates the user in the eyes of the web server) that is stored in a cookie and can be stolen by an adversary, who can then employ this cookie to take over a complete session. To solve such issues, we modify the cookies sent through our proxy. Cookies are set by the web server with the Set-Cookie field in the HTTP header and are sent from the web browser to the web server with the Cookie field in the HTTP header. The first field is originating from a web server and has to be altered in such a manner that the data reaching the browser cannot be brought into operation for an attempted session 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 arbitrary string. For the reverse direction (web browser to web server), the cookie values have to be restored from the database. Lastly, cookies can be created on the client machine directly in the browser with the use of techniques such as JavaScript or Adobe Flash. We decided to let these unknown cookies (for our proxy failed to notice a corresponding Set-Cookie HTTP header ﬁeld) pass through in an unaltered stage because we do not think that an adversary can remodel such “self generated” cookies to be harmful for the user, and to be compatible with websites which depend on this behavior. Once we have dropped them, several websites responded and complained with warnings such as “Your browser does not support cookies!”.

If we substitute all cookies, we might provoke errors with scripts which use cookie values to, e. g., personalize the website. To overcome this, we only substitute cookies which have a value which is at least eight bytes long and has a high entropy since these cookies likely store sensitive data. Shorter cookies or cookies with low entropy are 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 cookies are 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 whitelist can be set up for each domain to deﬁne which cookies shall (not) be protected by SmartProxy.

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

Note that all cookies are only replaced within requests or the COOKIE header ﬁelds if the destination domain matches the domain which is stored in the database for the 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 the secrecy of the stored user credentials. If it gets lost, stolen, or compromised, all deposited credentials must be considered known by a third party. To prevent this from occurring, we store all credentials in an encrypted form in the database in such a way that makes them unlikely to be revealed to a potential attacker. Each genuine username ug and password pg is encrypted with a key k derived from a fake password pf using a password-based key derivation function (PBKDF2 [125]). The encryption 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 real username and password leads to the fact that the fake passwords must not be stored in the database. This hinders the filters from Section 6.4.5 to find and replace these strings, as they may then appear almost anywhere in the header or payload, and their appearance may be just as arbitrary. To enable the matching of arbitrary fake 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 a leading fp_ and a closing _. This is a process that can be put in action easily. The intermediate string is used as pf , and ug and pg may be decrypted with the latter operation’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 6 Enhancing Other Devices’ Security with SmartProxy

pf , eventually decrypting the credentials. The correct pf can easily be determined by 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 benchmarks are divided into two categories, namely micro- and macro-benchmarks. The former measure “atomic operations’ (e. g., an SSL handshakes on the smartphone), while the latter are executed to estimate additional load time caused by our tool when accessing several popular websites. The smartphone we used in the testing phase was an HTC Desire with Cyanogen Mod 7.0.3 (Android 2.3.3, not overclocked, using the default CPU governor). Additionally, the same benchmarks were performed on a vanilla Samsung Nexus S with Android 2.3.4. All results were comparable, thus we omit them in the following for conciseness reasons. On the client’s side, we used wget in version 1.12 to automatically establish new connections, and our test smartphone device was connected to the Internet over a wireless connection to a 54 Mbit AP where a downstream of 2.7 MB/s is reachable. We used the adb port forwarding technique to launch and maintain a connection between the web browser and the proxy.

6.5.1 Synthetic Benchmarks

A main feature of the proxy is its ability to alter the payload in the SSL-secured HTTP 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 to measure these times without too much interference from the network latency, web server load, DNS lookups and so on, we have applied the benchmarks to a local server which is only three network hops away. The server is equipped with a Core i7 CPU, 8GB of RAM and was running Ubuntu 11.04 with Apache 2.2.17 using mod_ssl without any special configurations or optimizations. SmartProxy is required to complete two different SSL handshakes for normal operation, hence we tested several configurations for this prerequisite. SSL Session resumption—for an explanation read below—was explicitly disabled for these benchmarks. At first, we tested the speed rate of the handshake to the target server, and evaluated how this depends on different RSA key sizes and ciphersuites. Then we repeated this test for the local SSL handshake. All measurement times are stated

152 6.5 Evaluation

Table 6.1: Micro benchmark for the Table 6.2: Micro benchmark for the target SSL handshake (KS local SSL handshake (KS = Keysize in bit, AVG = Av- = Keysize in bit, AVG = Av- erage Time, SD = Standard erage Time, SD = Standard Deviation). Deviation). KS Ciphersuite AVG [ms] SD [ms] KS Ciphersuite AVG [ms] SD [ms] 512 RSA/AES/256/SHA 29 24 512 RSA/AES/256/SHA 35 16 1024 RSA/AES/256/SHA 33 17 1024 RSA/AES/256/SHA 42 20 2048 RSA/AES/256/SHA 37 9 2048 RSA/AES/256/SHA 90 68 4096 RSA/AES/256/SHA 90 17 4096 RSA/AES/256/SHA 360 326 512 DHE/AES/256/SHA 84 15 512 DHE/AES/256/SHA 3,734 4,422 1024 DHE/AES/256/SHA 83 17 1024 DHE/AES/256/SHA 3,344 4,096 2048 DHE/AES/256/SHA 90 17 2048 DHE/AES/256/SHA 3,551 4,101 4096 DHE/AES/256/SHA 124 17 4096 DHE/AES/256/SHA 3,670 4,115 without the added time necessary to validate a certificate, with the exception of a special check designed to investigate whether the certificate has already been validated at some prior time. Certificates are validated when they are seen for the first time and then stored for later use. Each “new” certificate is first checked against those pre-existing ones to determine whether it is already known and valid, and then, provided it is in the clear, it is accepted. This greatly speeds up the process thanks to the fact that the Online Certificate Status Protocol (OCSP) and certificate 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 connection to 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 per our tests, this takes approximately 33 ms for a 1024 bit strong RSA key with our own server. Table 6.1 provides an overview of the benchmarking results for establishing a secure channel between the proxy and our local test web server, all for different setups. What we discuss below is that these handshakes were all completed in an acceptable time, even with a 4096 bit strong RSA key, and, equally, for ephemeral Diffie-Hellman (EDH or DHE) ciphersuites, which are generally slower.

In the second step, the certificate presented by the web server has to be forged in order to establish a secure and trusted connection between the web browser and the proxy. The average time to forge and sign such a certificate is 150 ms, which is sufficiently 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 ﬁnal step, the web browser upgrades its plain text connection to the proxy to an SSL-secured connection type. This implies an SSL server hand-

153 6 Enhancing Other Devices’ Security with SmartProxy shake on the proxy involving a forged certificate. Once again, this is a pretty fast operation which takes only 42 ms on average for a 1024 bit strong RSA key. Table 6.2 provides an overview of how long the local SSL handshake takes for several configurations. In order to accomplish decent times for the local handshakes, it is crucial to choose the right ciphersuites. While plain RSA handshakes operate fast enough even for a 2048 bit key, a noticeable delay is caused by a 4096 bit key. Conversely, if the web browser chooses EDH ciphersuites for the session key exchange, the time to complete such a handshake might be pinned down as anywhere from 1 to up to 10 or more seconds for each handshake—even with the same certificate, which explains the high standard derivation for these tests. EDH handshakes are more secure, yet evidently and understandably more expensive than plain RSA handshakes. Still, normally they do not reach the factor of 100 which we measured. We have reasons to believe that this operation is not well optimized in the used OpenSSL stack on Android, 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 much faster indicates that this code lacks optimizations for the server mode of the handshake, cf. Section 6.5.2. We believe that it takes a relatively long time to compute the EDH parameters and this phenomenon would explain the vast amount of time it takes to complete a local handshake with EDH ciphersuites. Conclusively, to enable 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, and RSA/AES/256/CBC/SHA. Nevertheless, all available secure (EDH) ciphersuites are enabled for the SSL handshake to the web server.

In order to accelerate the expensive SSL handshakes, SSL and TLS support the mechanisms called Sessions. Sessions are identiﬁed with a unique ID by the client and the server. Once a completed handshake is bound to such a Session, it will not happen again when the Session is still valid. The client and the server may both reuse a Session, and the already negotiated cryptographic parameters that come with it. This feature can greatly facilitate the establishment of new connections. As an initial handshake from the ﬁrst step is completed, a new connection to our web server is established within under 30 ms on average from the proxy. A standard estimate for a resumed local server handshake to take place is about 40 ms.

We did not benchmark the SSL operations for diﬀerent websites separately because all operations, except the SSL handshake to the web server, use the same static key materials in the ﬁrst step which results in almost the same benchmark for each operation.

3 With respect to 2012. In the meantime the handshake performance was probably ﬁxed and RC4 cannot be deemed secure anymore, as serious ﬂaws have been discovered [23].

154 6.5 Evaluation

Table 6.3: Evaluation results for global Top 25 websites from alexa.com without duplicates 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 % X facebook.com 1024 RSA/RC4/128/MD5 424 103 1.37 58 % X youtube.com 1024 RSA/RC4/128/SHA 71 8 2.93 20 % X yahoo.com 1024 RSA/RC4/128/MD5 192 52 4.34 26 % X wikipedia.org 1024 RSA/RC4/128/MD5 363 169 5.11 50 % X live.com 2048 RSA/AES/128/SHA 595 31 1.60 23 % X twitter.com 2048 RSA/RC4/128/MD5 400 97 3.66 17 % X linkedin.com 2048 RSA/RC4/128/MD5 426 72 1.93 78 % X taobao.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 % X wordpress.com 1024 DHE/AES/256/SHA 527 52 16.66 204 % X yandex.ru 1024 DHE/AES/256/SHA 274 50 5.75 260 % X ebay.com 2048 RSA/RC4/128/MD5 587 51 1.49 46 % X bing.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 to be our test sites for additional benchmarking, yet we omitted “duplicate” sites like google.co.jp and google.de, as well as all the sites we were unable to understand content-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 feature of the proxy is its ability to withhold crucial information such as user credentials and 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 found out that our proxy successfully substituted fake credentials with genuine ones on all tested websites.

We measured SSL handshakes for real-world sites (micro-benchmarks) and again used wget for these tests. Firefox 5.0 with the Firebug 1.8.1 plugin was used to measure website load times (macro-benchmarks). No caching was undertaken between each page reload and we additionally invalidated all SSL Sessions after each connection for the micro-benchmarks. The certiﬁcates are validated by mirroring the method described in the previous section. Table 6.3 lists all times and the implied overhead.

155 6 Enhancing Other Devices’ Security with SmartProxy

To keep the impact of unknown side eﬀects low, we trialled all websites in a row and repeated this 100 times on a rolling basis. In order to measure the overall overhead (macro-benchmarks), we tested each website ﬁve times and calculated the load time, comparing the results for when the proxy was used versus the same action without it being used.

It is vital to note that these times include a lot of operations with timings which we cannot inﬂuence or control. These include the web server’s load, the time needed to look up the IP address, certiﬁcate checks (OCSP/CRL), as well as general network latency. Overall, the SSL handshake from our proxy to the web server is fast enough not to hinder the user’s experience. This is interesting because the SSL Sessions can be resumed, the feature which was explicitly disabled for the micro-benchmarks testing 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 our tested devices.

Table 6.3 shows that the total overhead is reasonable when SmartProxy is used as a privacy proxy. While the tool has a certain overhead, it does not in any case makes it unacceptable to surf the Web. For the majority of the tested sites, the overhead is 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 web page is accessed with the proxy and the web browser uses its cache, the overhead is sometimes not even noticeable by a user. Some sites such as twitter.com and yandex.ru have a larger infrastructure and several SSL handshakes may be needed in order to load a single page, for the content is served from many different hosts with different SSL certificates. Our approach to add additionally derived alternate subject names to the forged certificates, cf. Section 6.4.4, may reduce the amount of SSL handshakes which are needed to be performed, although this depends on the infrastructure of the specific website, as the completely different overhead for these two 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 they close a connection rather than allowing our tool to reuse it, we need to establish a new connection to the proxy and to the web server, which implies two additional SSL handshakes. This takes time and is clearly visible in the measurement results for wordpress.com, a site that exhibits this behavior. This is obviously an implementation detail, but our prototype currently allows only “pairs of connections”: namely one connection established from the web browser is tied to one connection to a designated web server.

156 6.6 Discussion

Aside for “normal web surfing”, we evaluated how fast we are able to download large files. The average download speed with SmartProxy enabled is only slightly slower than the download without the proxy. We have seen download rates that differ by only a few KB/s up to some 100 KB/s. This of course depends on the accessed server and the WiFi connection’s quality. The fastest download speed achieved with the proxy enabled was 2.7 MB/s. To complete our evaluation, we did some research into a selection of the video portals to check if they work correctly. The video portals typically make use of many different web technologies to stream the video content to the browser. When performing our tests, we have not identified any problems on the 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 an eavesdropper by taking advantage of a smartphone that acts as a privacy proxy, i. e., the smartphone transparently substitutes fake information entered on an untrusted machine and replaces it with genuine credentials. We have shown that it is possible to enable secure logins despite working on a compromised machine. The steps for achieving the desirable output are relatively easy, as they mainly require connecting the smartphone to the computer and configuring the web browser so that it uses our proxy. Compared to previous work in this area, we do not rely on a trusted third party that performs the substitution, but everything is handled by the smartphone itself. We have implemented a fully-working prototype of our idea in a tool called SmartProxy. The overhead is reasonable and often even unnoticeable to the user as demonstrated with our benchmarking results. Furthermore, we evaluated the security implications of the setup and we are convinced that our solution is beneficial for many users. We will now discussion several limitations of our solution and also sketch potential future improvements to strengthen SmartProxy. As already explained in Section 6.4.1, the smartphone may route all its traffic back to 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 case that the web browser uses the proxy for plain HTTP websites. Because all HTTP traffic is unencrypted, an attacker may read and alter all traffic on the compromised computer. This includes all data that have been formerly replaced; or, in other words, the genuine credentials and cookies. The current implementation does not check for this scenario. However, all SSL-secured connections are not affected because a MitM attack would be detected by the proxy running on the smartphone—as long as the PKI is trustworthy. Furthermore, we could extend SmartProxy to automatically “upgrade” each HTTP to a HTTPS connection whenever possible, thus

157 6 Enhancing Other Devices’ Security with SmartProxy preventing this attack scenario. Another potential weakness is that the login procedure on a website could perform some kind of computation during the login process with techniques such as JavaScript, Java, Adobe Flash, Active-X or other similar technologies. These procedures could compute arbitrary values which are in turn sent 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 evaluation but cannot guarantee that it always works as expected. Some websites might require the use of the white- and blacklist feature. As the attacker is able to interact with all the contents of a web site, she is able to perform so called transaction generator attacks [120]. This means that she can make 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 tell by any means which requests are legit and which are not. Jackson et al. propose some countermeasures [120], which could be included in SmartProxy. The best defense SmartProxy offers for now is that the user can always see what is going on as all requests are visible on the smartphone’s screen. The user might simply cut the connection to the proxy if something looks suspicious. In this case, the attacker might disable the usage of the proxy, but will not be able to proceed, as no credentials and cookies are available to her. We did not carry out a user study to see how successful people are able to set up SmartProxy. We are aware that people often have difficulties understanding what is going on with security related problems (see for example [54]). As long as the users remember to never input real credentials into the computer while they use SmartProxy, 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 includes importing the root certificate for SSL secured websites. Albeit the certificate is not crucial if the link between the smartphone and the computer is secure—e. g., when connected with a USB cable—, it greatly enhances the user experience as otherwise each SSL secured website will enforce a certificate warning from the browser. In the remaining of this section, we briefly discuss future work. First, there could be a better connectivity between a smartphone and a computer. A type of an automatic wireless connection would be helpful, and the use could potentially be made of the Bluetooth protocol. We did not look into this aspect because the current connectivity scope was deemed sufficient for the prototype. It would be advantageous to see some kind of “Reverse Tethering” support on Android, like the ActiveSync 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 proper detection of cases when the plain HTTP traffic is routed back to the computer on which the web browser runs would be essential in order to prohibit vulnerable setups of this sort. Additional filters could be implemented to hide content from web browsers, for example 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 attacker attempts to send substituted real data back to the web browser through the proxy to get hold of them. Although the attacker would need access to the web server to enable such mirroring and would already have access to the data, such an attack would be harder for the attacker. As the filter system is pluggable, this can be implemented 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 it is already pretty fast for most use cases, this is undoubtedly a desirable direction of improvements in the future. There are some existing solutions which are known to reflect 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 solutions are currently tested by Google in selected applications and servers. If they prove successful, they will be hopefully integrated into Google’s Android.

159

7 Summary and Conclusion

In this thesis we addressed several mobile security research problems and asked how we could make our “smart” phones more secure. We introduced new tools for analyzing Android applications, evaluated how robust such tools are against well- obfuscated software, and we discussed a prototype which leverages a smartphone in order to enhance the security of PCs.

We now summarize our contributions per chapter and also discuss what future work could 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 respect to mobile security.

Chapter2: Background: From Mobile to Security. We started this thesis with an introduction of the term mobile security and what sets it apart from the well known research ﬁeld of computer security in general. We then discussed smartphone characteristics and reported on speciﬁcs of their mobile operating systems. Since this thesis is about mobile security we quickly came to the point where we introduced the problem of malware and also discussed possible attack vectors. After providing a summarized time line of known malware for feature phones and smartphones, we discussed analysis techniques to counter these threats.

Chapter3: Static Approach based on Program Slicing. After emphasizing the need for proper and novel analysis tools for mobile applications in the previous chapter, we introduced in this chapter a static analysis tool for Android applications. Out tool named Saaf is able to calculate program slices and to use them in order to ﬁnd

161 7 Summary and Conclusion hardcoded information which are used as method parameters. An example would be 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,000 were malicious. We reported on many found characteristics after analyzing such a large corpus of data for both benign and malicious applications. Since Saaf is a tool to statically analyze programs, it suﬀers from all disadvantages that come with it. The problem here lies in the heavy burden that well-obfuscated programs put onto such tools. As we have shown in the next chapter, such analyzers can be completely hindered if the program’s code is well-obfuscated. Despite these drawbacks, static analyzers still provide good results if the analyzed application is not well-protected. Saaf’s main feature is its ability to perform a technique called program slicing on applications, but the implementation could be enhanced. Our prototype does not correctly handle eﬀects caused by polymorphism introduced by Java’s object oriented paradigm: If an overwritten method is invoked, it does not correctly handle this case and the called—but eventually not the overriding—method is analyzed. Additionally, the analysis of method calls is not context-sensitive [222]. Enhancing the tool will certainly lead to better analysis results, but the general occurring problems while analyzing obfuscated applications remain for such a static analysis tool.

Chapter4: Dynamic Approach based on Power Consumption. After we have introduced a static analyzer in the previous chapter, we also presented a dynamic analysis tool. Instead of dynamically analyzing mobile applications in the “usual way”, we evaluated if and how malicious mobile software can be detected based on the consumed energy. In theory, it should be possible to detect additionally executed (malicious) behavior as each performed action consumes some amount of energy. In the case of smartphones this energy is provided by the battery. We made use of a sophisticated tool to measure the spent energy of installed applications and which actions drain which amount of energy from the battery. Although we were able to detect malicious activities in artificially short-time tests, we were not able to do so in longer real-world like tests. Our evaluation with real malware samples has also not produced desired results. Despite the evaluation of many different test scenarios, we had to conclude that the detection of (malicious) activities based on its energy fingerprint seems to be a dead end—at least for nowadays available smartphones.

Chapter5: Change of Ends: Obfuscating Android Applications. In the previous two chapters we introduced a static and a dynamic analysis tool for Android applications. While the ﬁrst system produces good results for non-obfuscated applications, 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 assumption previously made for feature phones to detect malware based on its energy consumption does not hold for modern smartphones—malware cannot reliable be detected that way. Since we experienced problems with our first tool, we got curious how other analysis tools perform under certain circumstances. We therefore built a tool which automatically obfuscates Android applications and evaluated how robust state-of-the art analysis tools in general are. After evaluating many available tools, we came to the conclusion that many have drawbacks and cannot analyze well protected applications. This situation is particular unpleasant, as malware for mobile devices quickly advances with respect to their functionality and code quality. Samples can still be analyzed, but a manual analysis is often necessary for good results. Automatic ones are easily hampered with easily addable anti-analysis techniques. More robust tools are desirable and more tools should be made available to the community. Many research tools are just not published at all and maintenance often stops after the results were published. It is also desirable that more analysis techniques are available for mobile application analyzes. Tools that support multipath execution would be very beneficial for analyzing malicious software. The same is true for tools which properly support static or dynamic instrumentation in order to (automatically) defeat the “misuse” of the Java Reflection API in malicious Android applications and obfuscation in general. Our evaluation shows that even dynamic analysis systems have problems with obfuscated applications. Still, two systems generated proper reports, namely Mobile Sandbox and TraceDroid. A combination of these two system would be beneficial in order to dynamically analyze Android applications.

Chapter6: Enhancing Other Devices’ Security with SmartProxy. After reporting on the analysis of mobile applications, we discussed in this chapter the possibility to enhance the security of a PC with the help of a smartphone. Our particular assumption was that someone must use an untrusted computer for browsing the web, e. g., in the coworker’s oﬃce. We presented a prototype named SmartProxy which runs on a smartphone and eases the user’s worries about entering credentials into an eventually compromised computer. The prototype also takes care that an attacker cannot get hold of other security related information, such as cookies or session IDs. If the smartphone on which our tool runs is connected to the PC, all traﬃc—including encrypted connections—can be routed over the smartphone and SmartProxy can strip out security relevant information in a way that they never reach the PC. Additionally, the user never enters real credentials but only fake 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 name but a few is also feasible in such a setup, as the proxy could also ﬁlter these out. Leveraging the smartphone’s processing power and connectivity to enhance the security of other devices is an interesting approach that could see adaption if the connection between the smartphone and, e. g., the PC would be seamless and applications would support such an approach. That way credentials could be distributed over these devices in a way that no device has all the information and an attacker must successfully gain control of both devices in order to cause harm. Our presented prototype proved the feasibility of such an approach, but more work is required to ease the setup for normal users who generally do not want to spent any time for additional security.

Outlook

Although smartphones are very common nowadays, they will presumably become even more prevalent. The same can be expected for other mobile devices with similar features, such as smartglasses and smartwatches. The daily use cases where we utilize such devices will therefore rise. Health and fitness applications are a booming segment by the time of writing and such applications are running on “smart devices” which enable them in the first place. The amount of automatically collected and processed data will rise and privacy issues will play a huge factor for such applications—even more than they should today. Mobile security will also play a huge factor in the field of automotive security, especially since vendors use the same operating systems and the car will be well connected with our mobile devices [124]. Cars can already be controlled to a certain extend by our smartphones, but the interdependence will most likely grow. This trend is also visible for, e. g., TVs [124], although this development does not raise that many concerns. The amount of information we likely share with corporations such as Google and Apple will increase in the near future, as everything will be more connected than ever. How valuable and attractive such information are was thoroughly evaluated in Chapter2. Malware authors will for sure attempt to also get hold of such information in order to commit illicit activities. It is therefore crucial that mobile operating systems provide decent security mechanisms and that program analysts have access to 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 be seen 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 have been learned and smartphones feature security mechanisms usually not available on PCs, ﬁghting 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...... 17 2.3 Amount of known malware families...... 34

3.1 Screenshot of Saaf...... 49 3.2 Exemplary CFG of Saaf...... 50 3.3 Exemplary program slice...... 52

6.1 Schematic Overview of SmartProxy...... 141 6.2 Protocol sequence diagram...... 146

167

List of Tables

3.1 Top 10 permissions...... 59 3.2 Top 10 system services...... 62

4.1 Short time initial tests for a 5 minute period. Average power consumption for wireless connections...... 79 4.2 Exemplary power consumption of different apps after system start for a 5 minute interval...... 80 4.3 Average power consumption for different brightness levels...... 81 4.4 Average power consumption for different power states...... 82 4.5 Average power consumption for accessing the location API...... 83 4.6 Average power consumption for data transmission...... 84 4.7 Joblist for scenario A...... 85 4.8 Joblist for scenario B...... 85 4.9 Long time initial tests (3 hour period)...... 86 4.10 Exemplary power consumption of different apps (scenario A)..... 87 4.11 Average power consumption with disabled sleepmode...... 87 4.12 Average power consumption for stealing GPS position...... 88 4.13 Average power consumption for data transmission...... 89 4.14 Battery charge level for the Galaxy Nexus after sending data and short messages...... 90 4.15 Verification with malware in controlled scenarios...... 91 4.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...... 117 5.3 Decompilation results for diﬀerent test cases...... 120 5.4 Contagio Minidump AV detection rates for VirusTotal...... 124 5.5 Contagio Minidump AV detection rates for mobile AV solutions... 127 5.6 Artiﬁcial benchmark results...... 130

6.1 Micro benchmark for the target SSL handshake...... 153 6.2 Micro benchmark for the local SSL handshake...... 153 6.3 Evaluation results for global Top 25 websites from alexa.com..... 155

170 Listings

3.1 Sample Java code...... 57 3.2 Sample smali code...... 58 3.3 Patched code to circumvent copy-protection mechanisms...... 66

5.1 Example code for indirect invokes...... 111 5.2 Example code for indirect ﬁeld and array access...... 113 5.3 Misuse of the goto instruction, example (1)...... 121 5.4 Misuse of the goto instruction, example (2)...... 121 5.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 [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 Purchase Of 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 Proﬁt,” 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 ﬂow 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 symbolic execution of java programs,” in ASE, 2011, pp. 33–42. [27] S. Anand, M. Naik, M. J. Harrold, and H. Yang, “Automated concolic testing of 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 [30] ——, “iOS,” https://www.apple.com/ios/.

[31] A. J. Aviv, K. Gibson, E. Mossop, M. Blaze, and J. M. Smith, “Smudge attacks on smartphone touch screens,” in WOOT, C. Miller and H. Shacham, Eds. USENIX Association, 2010.

[32] N. Balasubramanian, A. Balasubramanian, and A. Venkataramani, “Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network 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 Smart Cards,” 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 cryptanalysis of 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 securing permission-based software by reducing the attack surface: An application to Android,” in Proceedings of the 27th IEEE/ACM International Conference on Automated 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. Hoﬀmann, T. Holz, S. Uellenbeck, and C. Wolf, “Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices,” in Security and Privacy (SP), 2011 IEEE 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 iPhone unlocking,” 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 realtime attack on a5/2 without precomputations,” in CHES, ser. Lecture Notes in Computer Science, P. Paillier and I. Verbauwhede, Eds., vol. 4727. Springer, 2007, pp. 394–412.

175 [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. Knijﬀ, and M. Roeloﬀs, “Forensic Data Recovery from Flash Memory,” Small Scale Digital Device Forensic Journal, vol. 1, no. 1, 2007.

[44] J. Brodkin, “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/.

[45] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Flexible and ﬁne-grained mandatory access control on android for diverse security and privacy policies,” in USENIX Security, 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, and R. Rivest, “The untrusted computer problem and camera-based authentication,” 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 Android applications for capability leak,” in Proceedings of the Fifth ACM Conference on 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 applications with 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 ACM Conference on Computer and Communications Security, CCS 2011, Chicago, Illinois, USA, October 17-21, 2011. ACM, 2011.

176 [54] S. Chiasson, P. C. van Oorschot, and R. Biddle, “A usability study and critique of 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 International Conference 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-vivo multi-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 are Coming!” 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,” In Proc. 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 power analysis to detect malicious code in smartphones,” in ACM Workshop on Security 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 Proceedings of the Second International ICST Conference on Mobile Computing, Applica- tions, and Services (MobiCASE), 2010.

177 [67] M. Dong and L. Zhong, “Self-Constructive High-Rate System Energy Modeling for Battery-Powered Mobile Systems,” in International Conference on 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-ﬁles-for-bankruptcy.html.

[69] B. Driessen, R. Hund, C. Willems, C. Paar, and T. Holz, “Don’t trust satellite phones: A security analysis of two satphone standards,” in IEEE Symposium on Security and Privacy. IEEE Computer Society, 2012, pp. 128–142.

[70] M. Egele, C. Kruegel, E. Kirda, and G. Vigna, “PiOS: Detecting Privacy Leaks in iOS Applications,” in Network and Distributed System Security Symposium (NDSS), 2011.

[71] M. Egele, T. Scholte, E. Kirda, and C. Kruegel, “A survey on automated dynamic 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 Security Technologies, 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 Android Application Security,” in USENIX Security Symposium, 2011.

[75] W. Enck, “Defending users against smartphone apps: Techniques and future directions,” 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, and A. Sheth, “TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones,” in OSDI, R. H. Arpaci-Dusseau and B. 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, and D. Estrin, “Diversity in smartphone usage,” in International Conference on Mobile Systems, Applications and Services, ser. MobiSys, 2010. [Online]. Available: http://doi.acm.org/10.1145/1814433.1814453

178 [79] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner, “Android Permis- sions Demystiﬁed,” in ACM Conference on Computer and Communications Security, 2011.

[80] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, “A survey of mobile malware 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, “Android permissions: 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. Hoﬀmann, and M. Meier, “Cooperation enablement for centralistic 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 Intrusions and Malware, and Vulnerability Assessment - 9th International Conference, DIMVA 2012, Heraklion, Crete, Greece, July 26-27, 2012, Revised Selected Papers, 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 ﬂow 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 nature and causes of the wealth of internet miscreants,” in ACM Conference on Computer 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 applications,” TU Darmstadt, Tech. Rep. EC SPRIDE Technical Report TUD-CS- 2013-0113, 2013.

179 [90] A. P. Fuchs, A. Chaudhuri, and J. S. Foster, “SCanDroid: Automated security certiﬁcation 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 Feature Phones 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 Authentication on 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 Large Scale,” 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, Steal Your 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 [102] M. Grace, W. Zhou, X. Jiang, and A.-R. Sadeghi, “Unsafe exposure analysis of mobile 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 capability leaks in stock Android smartphones,” in Proceedings of the 19th Annual Network and Distributed System Security Symposium, ser. NDSS ’12. Internet Society, 2012. [104] M. Grace, Y. Zhou, Q. Zhang, S. Zou, and X. Jiang, “RiskRanker: Scalable and Accurate Zero-day Android Malware Detection,” in International Conference on Mobile Systems, Applications, and Services, ser. MobiSys, 2012. [105] G. Greenwald, E. MacAskill, and L. Poitras, “Edward Snowden: the whistleblower 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 as a 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 Private Keys,” 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 on Energy Fingerprints - A Dead End?” in RAID, ser. Lecture Notes in Computer Science, 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 in Computer 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 [113] T. Holz, M. Engelberth, and F. C. Freiling, “Learning more about the underground economy: A case-study of keyloggers and dropzones,” in European Symposium 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’t the droids you’re looking for: retroﬁtting android to protect data from impe- rious applications,” in ACM Conference on Computer and Communications Security, 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 Security Symposium (NDSS), 2014.

[117] H. Huang, S. Zhu, P. Liu, and D. Wu, “A framework for evaluating mobile app repackaging 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 for web,” 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 Secure Website Access from an Untrusted Machine,” in Annual Computer Security Applications Conference (ACSAC), 2006.

[122] J. Jeon, K. K. Micinski, and J. S. Foster, “SymDroid: Symbolic Execution for Dalvik Bytecode,” Department of Computer Science, University of Maryland, College Park, Tech. Rep., 2012.

[123] A. Jindal, A. Pathak, Y. C. Hu, and S. P. Midkiﬀ, “Hypnos: Understanding and Treating Sleep Conﬂicts 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 [125] B. Kaliski, “PKCS #5: Password-Based Cryptography Speciﬁcation Version 2.0,” 2000, http://tools.ietf.org/html/rfc2898.

[126] H. Kim, J. Smith, and K. G. Shin, “Detecting Energy-Greedy Anomalies and Mobile 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 Privacy Leaks 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 ﬂow analysis for app sets,” in Proceedings of the 3rd ACM SIGPLAN International Workshop 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: detection and mitigation of execution-stalling malicious code,” in ACM Confer- ence on Computer and Communications Security, Y. Chen, G. Danezis, and V. Shmatikov, Eds. ACM, 2011, pp. 285–296.

[133] M. Kührer, J. Hoﬀmann, and T. Holz, “CloudSylla: Detecting Suspicious System Calls in the Cloud,” Stabilization, Safety, and Security of Distributed Systems – 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 Layer Security (TLS) False Start,” 2010, https://tools.ietf.org/html/ draft-bmoeller-tls-falsestart-00.

183 [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: uncovering privacy 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 android with 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: Preventing Your Cellphone from Spies,” in International Symposium on Recent Advances 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 Cost U.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 Android apps for component hijacking vulnerabilities,” in Proceedings of the 19th ACM Conference 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: A Practical Attack on Bluetooth Encryption,” in CRYPTO, ser. Lecture Notes in Computer Science, V. Shoup, Ed., vol. 3621. Springer, 2005, pp. 97–117.

[149] F. Maggi, A. Valdi, and S. Zanero, “AndroTotal: A Flexible, Scalable Toolbox and Service for Testing Mobile Malware Detectors,” in Proceedings of the 3rd Annual ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM), November 2013.

184 [150] M. Mannan and P. C. Van Oorschot, “Using a Personal Device to Strengthen Password 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,” in PIMRC. 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 Human Element of Security. Wiley, 2003.

[158] R. Mogull, “The iPhone 5s ﬁngerprint reader: what you need to know,” http://www.macworld.com/article/2048514/ the-iphone-5s-ﬁngerprint-reader-what-you-need-to-know.html.

[159] A. Moser, C. Kruegel, and E. Kirda, “Limits of Static Analysis for Malware Detection,” in Annual Computer Security Applications Conference (ACSAC), Dec. 2007.

[160] A. Moser, C. Krügel, and E. Kirda, “Exploring Multiple Execution Paths for Malware Analysis,” in IEEE Symposium on Security and Privacy. IEEE Computer Society, 2007, pp. 231–245.

[161] Mozilla, “Firefox OS,” http://www.mozilla.org/en-US/ﬁrefox/os/.

[162] C. Mullaney, “A Million-Dollar Mobile Botnet,” Feb. 2012, http://www. symantec.com/connect/blogs/androidbmaster-million-dollar-mobile-botnet.

185 [163] T. Müller and M. Spreitzenbarth, “FROST – Forensic Recovery of Scrambled Telephones,” 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 Vice Versa): Demystifying Security Challenges in Mobile Environments,” in Work- shop on Mobile Computing Systems and Applications (HotMobile), February 2010.

[171] D. Octeau, W. Enck, and P. McDaniel, “The ded Decompiler,” Networking and 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, and Y. Le Traon, “Eﬀective inter-component communication mapping in Android with Epicc: An essential step towards holistic security analysis,” in Proceedings of 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, “Semantically rich application-centric security in android,” in ACSAC. IEEE Computer Society, 2009, pp. 340–349.

186 [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 Yubikey 2 One-Time Password Generator,” in RAID, ser. Lecture Notes in Computer Science, 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: Towards automating risk assessment of mobile applications,” in Proceedings of the 22nd USENIX Security Symposium. USENIX Association, 2013, pp. 527–542.

[180] S. Park, A. Savvides, and M. Srivastava, “Battery Capacity Measurement And Analysis Using Lithium Coin Cell Battery,” in International Symposium on 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 yield vast 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 my app? Fine Grained Energy Accounting on Smartphones with Eprof,” in ACM European 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-Grained Power Modeling for Smartphones Using System Call Tracing,” in ACM European Conference on Computer Systems, ser. EuroSys, 2011. [Online]. Available: http://doi.acm.org/10.1145/1966445.1966460

[184] Paul K., “Replicant developers ﬁnd and close Samsung Galaxy backdoor,” http://www.fsf.org/blogs/community/ replicant-developers-ﬁnd-and-close-samsung-galaxy-backdoor.

187 [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 and Communications Security, ser. CCS ’12. ACM, 2012, pp. 241–252.

[186] D. Perez and J. Pico, “A practical attack against GPRS/EDGE/UMTS/HSPA mobile 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 android malware,” in EUROSEC, D. Balzarotti and J. Caballero, Eds. ACM, 2014, p. 5.

[188] M. Protsenko and T. Müller, “Pandora applies non-deterministic obfuscation randomly 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 aware system 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 security analysis 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 on Information Forensics and Security, pp. 99–108, 2014.

[195] A. Reina, A. Fattori, and L. Cavallaro, “A system call-centric analysis and stimulation technique to automatically reconstruct Android malware behaviors,” in Proceedings of the 6th European Workshop on System Security (EUROSEC), 2013, see also: http://copperdroid.isg.rhul.ac.uk/copperdroid/ about.php.

188 [196] S. Rosen, Z. Qian, and Z. M. Mao, “AppProfiler: A flexible method of exposing privacy-related behavior in Android applications to end users,” in Proceedings of 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 password 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,” in Proceedings 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 effectiveness of dynamic taint analysis for protecting against private information leaks on android-based devices.” in SECRYPT, 2013, pp. 461–468. [201] E. J. Schwartz, T. Avgerinos, and D. Brumley, “All You Ever Wanted to Know about Dynamic Taint Analysis and Forward Symbolic Execution (but Might Have 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-libc Without Function Calls (on the x86),” in ACM Conference on Computer and Communications Security (CCS), 2007. [204] M. I. Sharif, A. Lanzi, J. T. Giffin, and W. Lee, “Impeding Malware Analysis Using Conditional Code Obfuscation,” in NDSS. The Internet Society, 2008. [205] G. Shih, “Facebook admits year-long data breach exposed 6 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 ACM Symposium 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 [208] S. Smalley and R. Craig, “Security enhanced (se) android: Bringing flexible mac 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 Approach to Computer Security via Binary Analysis,” in ICISS, ser. Lecture Notes in Computer 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,” Proceedings of 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, “Investigating User 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, Rodney Bay, 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 Workshop on 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 systems,” in Ambient Intelligence - Third International Joint Conference, AmI 2012, Pisa, Italy, November 13-15, 2012. Proceedings, ser. Lecture Notes in Computer 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 [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 open functionality 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 Mobile Devices,” Ph.D. dissertation, Ruhr-University Bochum, Germany, 2014. [226] S. Uellenbeck, M. Dürmuth, C. Wolf, and T. Holz, “Quantifying the Security of Graphical Passwords: The Case of Android Unlock Patterns,” in ACM Conference 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 1999 Conference 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 1 million apps, now oﬃcially largest,” http://www.phonearena.com/ news/Androids-Google-Play-beats-App-Store-with-over-1-million-apps-\ now-oﬃcially-largest_id45680.

191 [232] T. Vidas and N. Christin, “Evading android runtime analysis via sandbox detection,” 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-layer profiling 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 apk files,” http://code.google.com/p/android-apktool/. [238] M. Wu, S. Garfinkel, and R. Miller, “Secure Web Authentication with Mobile Phones,” in DIMACS Workshop on Usable Privacy and Security Systems, 2004. [239] T. Wyatt, “Security Alert: Geinimi, Sophisticated New Android Trojan Found in Wild,” https://blog.lookout.com/blog/2010/12/29/geinimi_trojan/. [240] R. Xu, H. Saïdi, and R. Anderson, “Aurasium: Practical policy enforcement for 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 and Dalvik semantic views for dynamic Android malware analysis,” in Proceedings of the 21st USENIX Security Symposium. USENIX Association, 2012, p. 29 ff. [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 Communications Security, ser. CCS ’13. ACM, 2013, pp. 1043–1054. [243] C. Yoon, D. Kim, W. Jung, C. Kang, and H. Cha, “AppScope: Application Energy Metering Framework for Android Smartphones Using Kernel Activity Monitoring,” in USENIX Annual Technical Conference, ser. ATC, 2012. [Online]. Available: http://dl.acm.org/citation.cfm?id=2342821.2342857

192 [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 based power 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 Communications Security, 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 repackaged smartphone 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 intermediate language for anti-repackaging on android platform,” in Proceedings of the 4th ACM conference on Data and application security and privacy. ACM, 2014, pp. 199–210. [250] Y. Zhou and X. Jiang, “Dissecting Android Malware: Characterization and Evolution,” in IEEE Symposium on Security and Privacy, 2012. [251] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang, “Hey, You, Get Oﬀ of My Mar- ket: Detecting Malicious Apps in Oﬃcial and Alternative Android Markets,” Symposium on Network and Distributed System Security, 2012.

193

Johannes Hoﬀmann

Persönliche Daten Geboren am 23. 02. 1982 Geburtsort Herdecke E-Mail johannes.hoﬀ[email protected] Schul- und Berufsbildung 2010–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