EVALUIERUNG VON COUNTERPROPAGATION ARTIFICIAL NEURAL NETWORKS ZUR ERKENNUNG VON ANDROID SCHADSOFTWARE

Transkript

1 Master Thesis

2 EVALUIERUNG VON COUNTERPROPAGATION ARTIFICIAL NEURAL NETWORKS ZUR ERKENNUNG VON ANDROID SCHADSOFTWARE Masterarbeit zur Erlangung des akademischen Grades Master of Science VerfasserIn: Franz Torghele Vorgelegt am FH-Masterstudiengang MultiMediaTechnology, Fachhochschule Salzburg Begutachtet durch: DI Dr. Peter Meerwald MSc (BetreuerIn) DI Dr. Simon Ginzinger MSc (ZweitgutachterIn) Puch bei Hallein,

3 i Eidesstattliche Erklärung Hiermit versichere ich, Franz Torghele, geboren am in Zell am See, dass ich die Grundsätze wissenschaftlichen Arbeitens nach bestem Wissen und Gewissen eingehalten habe und die vorliegende Masterarbeit von mir selbstständig verfasst wurde. Zur Erstellung wurden von mir keine anderen als die angegebenen Quellen und Hilfsmittel verwendet. Ich versichere, dass ich die Masterarbeit weder im In- noch Ausland bisher in irgendeiner Form als Prüfungsarbeit vorgelegt habe und dass diese Arbeit mit der den BegutachterInnen vorgelegten Arbeit übereinstimmt. Puch bei Hallein, am Unterschrift Franz Torghele Vorname Familienname Personenkennzeichen

4 ii Kurzfassung Smartphone und Tablet Verkäufe nahmen in den vergangenen Jahren stetig zu. Android verfügt mit Abstand über den größten Marktanteil in diesem Segment. Mehr als 1 Milliarde auf Android basierende Smartphones sollen schätzungsweise im Jahr 2017 ausgeliefert werden. Als Folge dieser großen Nachfrage ist die Android Plattform ein lukratives Ziel für EntwicklerInnen von Schadsoftware. Das mobile Betriebssystem sowie der Google Play Store, über welchen Applikationen gewöhnlich bezogen werden, verfügen über Schutzmaßnahmen um schädlichen Anwendungen entgegenzuwirken. Es zeigt sich allerdings, dass diese überwunden werden können und es wichtig ist, die Forschung in diesem Gebiet stetig voranzutreiben. In dieser Arbeit wird die Eignung von Self-Organizing Maps (SOM) beziehungsweise Counterpropagation Artificial Neural Networks (CP-ANN) zur Identifizierung von Schadsoftware unter Android Applikationen evaluiert. Im theoretischen Teil wird auf die Android Plattform und vorhandene Schutzmaßnahmen, auf die statische und dynamische Analyse von Android Applikationen zur Generierung von Feature-Vektoren, sowie auf maschinelles Lernen näher eingegangen. Im praktischen Teil schlägt der Autor ein im Zuge dieser Arbeit entwickeltes Framework namens AndroSOM vor, welches mittels statischer und dynamischer Analyse von Android Applikationen, Feature-Vektoren erzeugt. Diese werden anschließend mit Hilfe von SOM beziehungsweise CP-ANN analysiert, um schädliche von legitimen Applikationen zu trennen. Abschließend werden die Ergebnisse diskutiert und ein Ausblick auf weitere Entwicklungen gegeben. Im Zuge dieser Arbeit konnte gezeigt werden, dass sich CP-ANNs gut für die Identifizierung von Android-Schadsoftware eignen. Schlagwörter: Android, Schadsoftware, Maschinelles Lernen, Klassifizierung, Self-Organizing Maps, Counterpropagation Artificial Neural Networks

5 iii Abstract Smartphone and tablet sales continuously increased in recent years. Android has by far the largest market share in this segment. More than 1 billion Android-based smartphones and tablets are estimated to be shipped in As a result of this great success, the Android platform is a lucrative target for developers of malicious software. The mobile operating system as well as the Google Play Store, from which applications usually are obtained, have precautions to counter malicious software. It turns out, however, that this countermeasures can be overcome and it is important to constantly promote research in this area. In this work, the suitability of SOM respectively CP-ANN to identify malicious software among Android applications is evaluated. In the theoretical part of this thesis the Android platform and existing precautions, static and dynamic analysis of Android applications to generate feature vectors as well as self-organizing maps are elaborated. In the practical part, the author proposes a framework called AndroSOM which was developed in the course of this master s thesis. It uses static and dynamic code analysis to build strong feature vectors describing Android applications. These are afterwards analyzes using SOM respectively CP-ANN to distinguish legitimate from malicious applications. Finally the results are discussed and an outlook on further developments is given. In the course of this work it was shown that CP-ANN are well suited for the identification of Android malware. Keywords: Android, Malware, Machine Learning, Classification, Self-Organizing Maps, Counterpropagation Artificial Neural Networks

6 iv Danksagung Zunächst möchte ich mich bei allen bedanken, die mich in den vergangenen Monaten bei der Erstellung meiner Masterarbeit mit Rat und Tat unterstützt haben. Besonderer Dank gilt dem Studiengang MultiMedia Technology, Herrn Dr. Simon Ginzinger, und allen Teilnehmern des Research Seminars, in dessen Zuge das Thema meiner Masterarbeit stetig weiterentwickelt wurde. Unzählige inhaltliche Diskussionen mit meinen Kollegen gaben ihr zusätzliche Schwerpunkte, die nicht zu unterschätzen sind. Auch ein besonderer Dank gilt Herrn DI Dr. Peter Meerwald MSc, der die Betreuung meiner Masterarbeit übernommen hat und mich bei inhaltlichen sowie organisatorischen Fragen stets unterstützte. Ich bin dankbar für die Unterstützung von VirusTotal, einer Tochtergesellschaft von Google, die mir uneingeschränkten Zugriff auf ihre ansonsten kostenpflichtige API gewährt hat, wodurch Teile meiner Arbeit sehr erleichtert wurden. Nicht zuletzt gebührt besonderer Dank meiner Familie und Freunden: Meinen Eltern für ihre kontinuierliche und bedingungslose Unterstützung, sowie meiner Schwester und Freunden für das Korrekturlesen der Arbeit und für die ständige Motivation, auch oder gerade wenn etwas einmal nicht beim ersten Mal so funktionierte, wie ich es mir vorgestellt hatte.

7 INHALTSVERZEICHNIS v Inhaltsverzeichnis Inhaltsverzeichnis v 1 Einleitung Relevanz Methode Forschungsfrage Aufbau der Arbeit Android Grundlagen Das Android Betriebssystem Überblick System-Architektur Linux Kernel System-Bibliotheken Android Runtime Applikationsframework Applikationsschicht Binder Android Applikationen Komponenten Aktivierung von externen Komponenten Android Manifest Ressourcen Nativer Code Start einer Applikation Android Sicherheit System- und Kernel-Sicherheit Applikations-Sandbox Prozessübergreifende Kommunikation Applikations-Signierung Applikations-Verifizierung Berechtigungs-System

8 INHALTSVERZEICHNIS vi 3 Methoden Android Schadsoftware Arten von Schadsoftware Installations-Methoden Aktivierungs-Methoden Distribution Datensätze Erkennung von Schadsoftware Statische Analyse Dynamische Analyse Kombinierte Analyse Automatische Generierung von Input Maschinelles Lernen Künstliche Neuronale Netze Biologischer Hintergrund Anwendung Selbst-organisierende Karten Training Counterpropagation Artificial Neural Networks Training AndroSOM Feature Miner AndroSOM Graphical User Interface (GUI) Architektur des Frameworks Modul: Metadaten Modul: Statische Analyse Modul: Dynamische Analyse Nachverarbeitung und Generierung der Datensätze Resultate Applikations-Datensätze Einblicke Messmethode Verwendete Metriken

9 INHALTSVERZEICHNIS vii 5.4 Verwendete Datensätze Messergebnisse Error Rate im Verhältnis zur benötigten Zeit Einfluss verschiedener Arten von Feature-Vektoren Einfluss der Filter-Werte beim Erstellen der Datensätze Top-32 beziehungsweise Top-10 berechnete Modelle Vorhersage unbekannter Samples Diskussion & Ausblick Diskussion Ausblick Abbildungsverzeichnis 102 Quellcode Verzeichnis 103 Tabellenverzeichnis 104 Abkürzungsverzeichnis 105 Literaturverzeichnis 106 Anhang 113

10 1 EINLEITUNG 1 1 Einleitung In den vergangenen Jahren konnte ein rapider Anstieg an Smartphone und Tablet Verkäufen beobachtet werden. Laut Gartner (Gartner 2013), einem bekannten Marktforschungs- Unternehmen, das sich auf die IT Branche spezialisiert hat, stiegen die Smartphone Verkäufe an EndanwenderInnen im zweiten Quartal 2013 um 46,5% an und übertrafen somit das erste Mal die Verkaufszahlen von Feature Phones. Die Android Plattform verfügt mit Abstand über den größten Marktanteil in diesem Segment. Gartner zufolge basierten 79% aller weltweit verkauften Smartphones und Tablets im zweiten Quartal 2013 auf der Android Plattform, gefolgt von ios mit 14,2%. Mehr als 1 Milliarde auf Android basierende Smartphones sollen schätzungsweise im Jahr 2017 ausgeliefert werden. Als Folge dieses großen Erfolges ist Android ein lukratives Ziel für EntwicklerInnen von Schadsoftware. Es wird davon ausgegangen, dass jede veröffentlichte schädliche Applikation im Durchschnitt einen sofortigen Gewinn von 10 USD abwirft. (Juniper 2013) F-Secure (F-Secure 2014) schrieb im Mobile Thread Report Q1 2014, dass sich die Anzahl an neu gefundener Schadsoftware seit dem Jahr 2011 vervierfacht hat. Allein im ersten Quartal 2014 wurden 277 neue Varianten identifiziert wovon 99% auf Android abzielten. Davon handelte es sich bei 91% um Software, die ein signifikantes Sicherheitsrisiko für ein Smartphone oder Tablet und die darauf gespeicherten Informationen darstellt. Bei den restlichen 9% handelte es sich um potenziell unerwünschte Applikationen (PUA), welche bei falscher Verwendung die Sicherheit des Smartphones oder Tablets gefährden können. Die Android Plattform versucht, BenutzerInnen mit einer Reihe von Sicherheitsmechanismen gegen Schadsoftware zu schützen. Jede Applikation wird gewöhnlich in einer eigenen Sandbox ausgeführt, um verschiedene Applikationen voneinander abzuschotten. Dadurch können potenziellen Gefahren durch Programmierfehler minimiert werden und der Schadsoftware wird es erschwert, auf Ressourcen fremder Applikationen zuzugreifen. (Enck, Ongtang und McDaniel 2009) Der Zugang zu datenschutz- und sicherheitsrelevanten Teilen der Android Programmierschnittstelle (API) wird durch ein Berechtigungs-System gesteuert. Jede Anwendung enthält in ihrer Manifest-Datei Informationen dazu, welche Berechtigungen sie benötigt, um ordnungsgemäß zu funktionieren. BenutzerInnen müssen diese Berechtigungen vor der Installation jeder Anwendung bestätigen. Somit liegt es in der Verantwortung der BenutzerInnen, ob sie einer Anwendung vertrauen oder die Installation anderenfalls abbrechen. Dieses System wird allerdings ineffektiv, wenn Anwendungs-EntwicklerInnen routinemäßig mehr Berechtigungen anfordern, als sie tatsächlich benötigen. (Felt, Chin u. a. 2011) Dieses Berechtigungs-System stellt einen der wichtigsten Sicherheits-Mechanismen auf Android dar. Es ist jedoch fraglich, wie aufmerksam BenutzerInnen lesen, welche Berechtigungen von einer Anwendung tatsächlich angefordert werden. Einer Studie zufolge (Felt u. a. 2012) beachteten nur 17% der Teilnehmer während der Installation von Applikationen die angeforderten Berechtigungen und nur 3% konnten drei Fragen zu diesen richtig beantworten. Aktuelle Schadsoftware-Beispiele zeigen auch, dass über Android

11 1 EINLEITUNG 2 BenutzerInnen Super Mario Bros oder GTA 3 Moscow City auf ihren Endgeräten installiert hatten, obwohl sie vor der Installation gefragt wurden, ob sie Services that cost you money: send SMS messages erlauben wollen. (Zdnet 2012) 1.1 Relevanz Durch den enormen Zuwachs an Android Schadsoftware in den vergangenen Jahren müssen Sicherheits-ExpertInnen und HerstellerInnen von Antivirus-Lösungen eine immer größer werdende Anzahl schädlicher Applikationen analysieren, um deren Wirkungsweise zu verstehen und Gegenmaßnahmen zu entwickeln. Solch eine Analyse geschieht traditionell durch das De-kompilieren von Applikationen und mit Hilfe von Debuggern. Je nach Erfahrung des Analysten oder der Analystin kann diese Arbeit sehr zeitaufwendig und fehleranfällig sein. Darum gibt es seit Jahren das Bestreben, die Analyse von Android Anwendungen zu automatisieren. In Kapitel 3 wird dazu näher auf verschiedene Herangehensweisen und Methoden eingegangen. Da sich Schadsoftware ständig weiterentwickelt, darf auch deren Bekämpfung keinem Stillstand unterliegen. Es ist wichtig immer neue Wege zu erforschen, die zu einer möglichst guten Erkennungsrate führen. In dieser Arbeit soll dafür die Eignung von Self-Organizing Maps (SOM) beziehungsweise von Counterpropagation Artificial Neural Networks (CP- ANN), unter Verwendung von Feature-Vektoren aus statischer und dynamischer Analyse, analysiert werden. In (Barrera u. a. 2010) wurden SOMs bereits erfolgreich zur Analyse von Applikations- Berechtigungen, einem der grundlegenden Sicherheitsmechanismen unter Android, eingesetzt. Diese Arbeit unterscheidet sich dahingehend, dass nicht Berechtigungen alleine als Grundlage für die SOM und das CP-ANN herangezogen werden, sondern Daten, die aus statischer und dynamischer Analyse stammen. 1.2 Methode Software kann grundsätzlich auf zwei verschiedene Arten analysiert werden - statisch oder dynamisch. Bei der statischen Analyse wird der Quellcode einer Anwendung untersucht. Bei der dynamischen Analyse wird das Verhalten einer Anwendung überwacht, während sie in einer kontrollierten Umgebung ausgeführt wird. In dieser Arbeit werden statische sowie dynamische Analyse eingesetzt, um ein möglichst gutes Gesamtbild der zu analysierenden Applikationen zu erhalten. Dazu wurde ein Framework namens AndroSOM Feature Miner entwickelt. Besonderes Augenmerk lag hierbei darauf, die dynamische Analyse möglichst performant zu gestalten. Anschließend wurden die gesammelten Daten mit Hilfe von SOM beziehungsweise CP-ANN analysiert und versucht, schädliche von legitimen Applikationen zu trennen.

12 1 EINLEITUNG Forschungsfrage Im Zuge dieser Arbeit soll folgende Fragestellung beantwortet werden: Wie zuverlässig lassen sich schädliche von legitimen Android Applikationen mit Hilfe von Counterpropagation Artificial Neural Networks (CP-ANNs), unter Verwendung von Feature-Vektoren aus statischer und dynamischer Analyse, unterscheiden? 1.4 Aufbau der Arbeit Der Hauptteil dieser Arbeit ist in sechs Kapitel aufgeteilt: In Kapitel 2 wird auf Grundlagen zu Android eingegangen, die für das Verständnis dieser Arbeit von Nöten sind. Darunter befindet sich ein Überblick über die System- Architektur, die Komponenten und die Funktionsweise von Android Applikationen sowie vorhandene Sicherheitsmechanismen samt möglicher Angriffspunkte. In Kapitel 3 wird auf verschiedene Arten von Schadsoftware, sowie auf deren Abwehr und Analyse eingegangen. Hier werden vor allem bestehende Arbeiten vorgestellt. Anschließend folgt eine Einführung in Maschinelles Lernen (ML), Artificial Neural Networks (ANN), SOM und CP-ANN. In Kapitel 4 wird der AndroSOM Feature Miner vorgestellt und näher auf dessen Implementierung und Design-Entscheidungen eingegangen. Außerdem wird beschrieben, wie aus den gesammelten Rohdaten Feature-Vektoren entstehen. In Kapitel 5 werden die Messmethoden beschrieben und auf die Resultate näher eingegangen. In Kapitel 6 werden die Ergebnisse diskutiert, die Forschungsfrage beantwortet und ein Ausblick auf mögliche Weiterentwicklungen gegeben.

13 2 ANDROID GRUNDLAGEN 4 2 Android Grundlagen In diesem Kapitel erfahren Sie Grundlagen zu Android, die für das weitere Verständnis dieser Arbeit von Nöten sind. Es wird näher auf die Android Plattform und dessen System-Architektur, sowie auf die verschiedenen Komponenten in Android Applikationen eingegangen. Abschließend wird ein Unterkapitel den vorhandenen Sicherheitsmechanismen unter Android und bestehenden Angriffspunkten gewidmet. 2.1 Das Android Betriebssystem Bei Android handelt es sich um ein Betriebssystem, das vorwiegend für mobile Endgeräte, wie etwa Smartphones oder Tablets, entwickelt wird. Das Betriebssystem dient hierbei als Schnittstelle zwischen Hardwarekomponenten und den darauf laufenden Anwendungen. Android Anwendungen werden meist in Java geschrieben und in einer Virtuellen Maschine (VM) ausgeführt. Diese speziell für Android entwickelte VM nennt sich Dalvik und ist eine der Kern-Komponenten des Betriebssystems. In ihr werden alle Applikationen und einige System-Services ausgeführt (Google 2014g). Mit Android 4.4 (KitKat) wurde eine neue experimentelle VM namens Android Runtime (ART) eingeführt, welche die Dalvik VM voraussichtlich in kommenden Versionen des mobilen Betriebssystems, beginnend mit Android 5.0, ersetzen wird (Google 2014h). Version Name API-Levels Release Zeitraum Anzahl 1.0 Base 1-2 Sep Feb Cupcake 3 Apr Donut 4 Sep Eclair 5-7 Okt Jan Froyo 8 Mai Jan Gingerbread 9-10 Dez Sep x Honeycomb Feb Sep Ice Cream Sandwich Okt Feb Jelly Bean Jun Okt KitKat 19 Okt Jun W Wear 20 Jun Tabelle 1: Überblick Android Versionen Quelle: Das mobile Betriebssystem wurde ursprünglich von Android Inc. entwickelt und nach dem Verkauf an Google im Jahr 2007 als Android Open Source Project (AOSP) veröffentlicht. Von diesem Zeitpunkt an wurde Android von der Open Handset Alliance (OHA), einem Zusammenschluss von 78 Firmen, weiterentwickelt. Der Großteil des Android Quellcodes wird unter der Apache Software License, Version 2.0 zur Verfügung gestellt und kann von einem zentralen Archiv frei bezogen und auch modifiziert werden (Google 2014j).

14 2 ANDROID GRUNDLAGEN 5 Wie in Tabelle 1 zu sehen ist, schreitet die Entwicklung der Android Plattform schnell voran. In kurzen Abständen erscheinen neue Major-Releases. Dieser Umstand führt dazu, dass Informationen über Android, besonders in Büchern oder Artikeln, sehr schnell veralten. Als aktuelle Quellen können oftmals nur die Software Development Kit (SDK) Dokumentation oder Blogs dienen. 2.2 Überblick System-Architektur Wie in Abbildung 1 zu sehen ist, kann das Android Grundsystem grob in vier Schichten unterteilt werden: dem Linux Kernel samt grundlegenden Tools, den System-Bibliotheken, der Android Runtime, dem Applikationsframework und der darauf aufbauenden Applikationsschicht. Abbildung 1: Android System-Architektur (Google 2014e) Die verschiedenen Schichten setzen sich aus mehreren Komponenten zusammen, auf welche in den folgenden Kapiteln genauer eingegangen wird. Jede Schicht stellt dabei den darüber liegenden Schichten Funktionalität zur Verfügung. Die Kommunikation zwischen den verschiedenen Komponenten und Schichten erfolgt meist über einen Android spezifischen Inter-process Communication (IPC) Mechanismus namens Binder.

15 2 ANDROID GRUNDLAGEN Linux Kernel Die unterste Schicht bildet der Linux Kernel. Das gesamte Android Betriebssystem baut auf dem Linux 2.6 Kernel auf, welcher einigen architektonischen Änderungen unterzogen wurde. Ein Beispiel hierfür ist die IPC-Schnittstelle Binder, welche als Kernel-Modul implementiert ist. Der Kernel ist für die Interaktion mit der Hardware verantwortlich und beinhaltet alle wichtigen Treiber, beispielsweise für das Global Positioning System (GPS) Modul, Kamera, Audio und Bluetooth. Der Kernel dient somit als Abstraktions-Schicht zwischen der Hardware der Endgeräte und den darüber liegenden Software-Schichten. Von ihm wird die gesamte Kern-Funktionalität abgedeckt, wie etwa die Speicher-, Prozess-, Netzwerk- und Energieverwaltung. Die Verwendung des bewährten Linux Kernels macht es außerdem einfacher, Android auf verschiedene Endgeräte zu portieren (App-Market 2012) System-Bibliotheken Da Android auch auf mobilen Endgeräten mit wenig Hauptspeicher und einer langsamen Central Processing Unit (CPU) laufen muss, werden System-Bibliotheken für CPUund Graphics Processing Unit (GPU)-intensive Rechenaufgaben zu stark optimiertem, nativem Code kompiliert (App-Market 2012). Einige der wichtigsten nativen Bibliotheken sind folgende: Surface Manager: Der Surface Manager dient der Anzeigeverwaltung. Er entscheidet, welche Applikationen zu welcher Zeit ihre Inhalte auf dem Bildschirm des Endgerätes anzeigen dürfen. OpenGL ES: OpenGL ES kann für die Darstellung von 3D Inhalten verwendet werden. Verfügt das Endgerät über Hardwarebeschleunigung, kann diese genutzt werden, was auch aufwendige 3D Inhalte, wie sie etwa in Spielen anzutreffen sind, ermöglicht. SGL: Der Großteil der Applikationen verwendet allerdings eine Android Bibliothek namens Scalable Graphics Library, welche auf das Darstellen von 2D Inhalten ausgelegt ist. Media Framework: Das Media Framework beinhaltet verschiedene Codecs zum performanten Aufnehmen und Abspielen von Medien-Inhalten wie zum Beispiel von Videos. SQLite: SQLite steht unter Android Applikationen als Datenbank zur Verfügung 1. Android unterstützt momentan drei Prozessor-Architekturen, für die diese Bibliotheken zu nativem Code kompiliert werden können: ARM, x86 und MIPS (Google 2014i). 1.

16 2 ANDROID GRUNDLAGEN Android Runtime Bei der Android Runtime handelt es sich um diejenige Komponente, die das Betriebssystem am meisten von einer herkömmlichen mobilen Linux Implementation unterscheidet. Die Runtime beinhaltet die Dalvik VM sowie grundlegende Android Java Bibliotheken, die das Programmieren von Android Applikationen erst ermöglichen (Meier 2012, S. 15). Android Bibliotheken Bei diesen Bibliotheken handelt es sich nicht um herkömmliche JavaSE oder JavaME Bibliotheken. Viel mehr handelt es sich um stark optimierte Nach-Implementierungen der bewährten JavaSE Bibliotheken, gepaart mit Android spezifischer Funktionalität (App- Market 2012). Dalvik VM Android Applikationen und das darunter liegende Applikationsframework werden fast zur Gänze in Java geschrieben. Anstatt eine herkömmliche Java Virtual Machine (JVM), wie zum Beispiel die der JavaME zu verwenden, wurde für Android eine eigene VM namens Dalvik entwickelt. Diese virtuelle Maschine ist auch nicht zur JVM kompatibel, da sie auf leistungsschwache mobile Systeme optimiert wurde. Mobile Systeme verfügen oftmals nur über wenig Hauptspeicher, eine langsame CPU und anders als herkömmliche Systeme über keine Auslagerungs-Partition, um den ohnehin kleinen Hauptspeicher auszugleichen (Bornstein 2008). Im Gegensatz zur JVM werden in der Dalvik VM die.class-dateien nicht direkt ausgeführt. Die Dalvik VM verfügt über ihr eigenes Bytecode Format, welches speziell auf mobile Endgeräte abgestimmt wurde. Dieser Dalvik-Bytecode ist kleiner als normaler Java- Bytecode und bietet bessere Effizienz in Umgebungen mit geringen Ressourcen. Dadurch wird es ermöglicht, mehrere Instanzen der virtuellen Maschine effizient nebeneinander auf mobilen Endgeräten auszuführen (Meier 2012, S. 16). Der Bytecode wird der virtuellen Maschine hierfür in Form von Dalvik Executable Format (DEX)-Dateien, welche zu Dalvik-Bytecode kompilierte.class-dateinen enthalten, übergeben. Die Dalvik VM bietet außerdem ein hoch effizientes Speichermanagement, bei dem ein Prozess namens Zygote (siehe Kapitel 2.3.6) eine wichtige Rolle spielt, sowie Multithreading-Unterstützung (App-Market 2012). ART Mit Android 4.4 (KitKat) wurde eine neue experimentelle VM namens ART eingeführt, welche die Dalvik VM voraussichtlich in kommenden Versionen des mobilen Betriebssystems ersetzen wird (Google 2014h). Einige der Vorteile von ART gegenüber der Dalvik VM sind folgende:

17 2 ANDROID GRUNDLAGEN 8 Ahead Of Time (AOT) Kompilierung: Android Anwendungen werden in Zukunft zur Installationszeit aus DEX-Dateien zu nativem Code kompiliert. Dadurch soll die Performance zur Laufzeit verbessert werden. Verbesserte Garbage Collection (GC): Eine ineffektive GC kann die Reaktionsfähigkeit von Anwendungen negativ beeinflussen. Dem soll durch eine verbesserte GC entgegengewirkt werden. Verbessertes Debuggen von Anwendungen: EntwicklerInnen soll das Suchen von Fehlern in ihren Applikationen erleichtert werden Applikationsframework Hierbei handelt es sich um die Komponenten, mit denen Applikationen direkt interagieren. Das Applikationsframework dient außerdem als weitere Abstraktionsschicht für den Zugriff auf Hardware-Komponenten sowie Ressourcen (Meier 2012, S. 15). Das Applikationsframework besteht unter anderem aus folgenden Bestandteilen: Activity Manager: Der Activity Manager regelt den Lebenszyklus von Applikationen (siehe Kapitel 2.3.6). Package Manager: Der Package Manager ist für das Installieren, Deinstallieren und Updaten von Applikationen verantwortlich. Außerdem kann er Informationen zu allen auf dem Endgerät installierten Anwendungen liefern. Window Manager: Der Window Manager verwaltet, welche Fenster am Bildschirm wie angezeigt werden. Unter anderem führt er auch automatische Übergänge von Fenstern, sowie Animationen beim Öffnen oder Schließen von Applikationen und beim Drehen des Bildschirms durch. Telephony Manager: Der Telephony Manager ist für eingehende und ausgehende Anrufe verantwortlich. Content Providers: Content Provider können für den Austausch von Daten zwischen verschiedenen Applikationen verwendet werden, mehr dazu in Kapitel Resource Manager: Der Resource Manager verwaltet alle Ressourcen, wie zum Beispiel Bilder oder Extensible Markup Language (XML)-Dateien, auf die Applikationen Zugriff haben. Location Manager: Der Location Manager stellt Positionsdaten zur Verfügung. Diese kann er entweder durch GPS, WLAN oder das Mobilfunknetz beziehen.

18 2 ANDROID GRUNDLAGEN Applikationsschicht Die Applikationsschicht ist die oberste Schicht in der Android Architektur. Für diese können EntwicklerInnen Applikationen schreiben. Es gibt einige Systemapplikationen, die mit jedem Android System ausgeliefert werden, beispielsweise eine Anwendung für den Startbildschirm, das Telefon, das Schreiben und Empfangen von SMS-Nachrichten, die Verwaltung von Kontakten und Terminen, das Surfen im Internet, das Schreiben und Empfangen von s, das Erstellen und Betrachten von Bildern, die Anzeige einer Uhr oder das Stellen eines Weckers. EntwicklerInnen ist es unter Android sogar erlaubt, jede dieser Systemapplikationen durch eigene Implementierungen zu ersetzen. Dadurch sind sie nicht limitiert, was die Anpassung von Android angeht (App-Market 2012). Neben den Systemapplikationen existiert eine große Anzahl von Applikationen von Drittanbietern. Diese können beispielsweise aus dem offiziellen Android Play Store oder alternativen Marktplätzen, wie Amazon, bezogen werden. Auf den Aufbau von Android Applikationen wird in Kapitel 2.3 näher eingegangen Binder Binder wurde ursprünglich unter dem Namen OpenBinder von Be Inc. entwickelt und von Android übernommen. Aus Lizenzgründen wurde OpenBinder für Android komplett neu implementiert. Bei Binder handelt es sich um einen leichtgewichtigen, hoch performanten Remote Procedure Call (RPC) Mechanismus, der sowohl innerhalb von Prozessen als auch prozessübergreifend eingesetzt werden kann (Google 2014e). Binder wurde als Linux Kernel-Modul implementiert, über welches Prozesse kommunizieren können. Dieses wird an Stelle von herkömmlichen Linux IPC Mechanismen eingesetzt, um IPC Operationen effizient als Thread Migration zu modellieren. Thread Migration bedeutet, dass der Thread, der die IPC veranlasst, in den Ziel Prozess wechselt, dort Code ausführt und mit dem Ergebnis anschließend zurück in den ursprünglichen Prozess wechselt. Aus Gründen der Sicherheit wurde der Binder IPC Mechanismus von Android allerdings ohne Thread Migration implementiert. Stattdessen verwaltet Binder einen Pool an Threads in jedem Prozess, die dafür genutzt werden, hereinkommende IPCs und lokale Anfragen abzuarbeiten. Das Kernel Modul emuliert im Fall von Android nur Thread Migration und stellt sicher, dass IPCs von ihrem ursprünglichen Thread entgegengenommen werden, wenn ein IPC in den initiierenden Prozess zurückkehrt. Das Binder Kernel Modul ist auch dafür verantwortlich, Objekt-Referenzen über Prozessgrenzen hinweg zu verfolgen. Entfernte Objekt-Referenzen werden dafür auf das jeweilige echte Objekt abgebildet. Dadurch wird sichergestellt, dass keine Objekte zerstört werden, solang ein entfernter Prozess eine Referenz auf diese hält (PalmSource 2005).

19 2 ANDROID GRUNDLAGEN 10 Intent Ein Intent ist eine Nachricht, die über die Binder IPC Schnittstelle geschickt wird. Dabei handelt es sich um eine abstrakte Repräsentation einer Operation, die ausgeführt werden soll. Abstrakt deshalb, weil nicht definiert sein muss, durch welche Komponente diese Operation ausgeführt werden soll. Ein Intent verfügt zumindest über ein Action und ein Data Feld, kann aber auch noch zusätzliche Informationen enthalten (Google 2014b). Tabelle 2 zeigt einige Beispiele, wie ein Intent aussehen kann. Action ACTION_VIEW ACTION_DEAL ACTION_EDIT ACTION_DIAL Data content://contacts/people/ content://contacts/people/1 content://contacts/people/1 tel:123 Tabelle 2: Android Intents (Google 2014b) Wenn ein Intent an eine bestimmte Komponente geschickt wird, handelt es sich um einen expliziten Intent. Wenn allerdings im Falle eines impliziten Intents keine Komponente definiert wurde, entscheidet das System, mit welcher Komponente die Operation ausgeführt wird oder bietet BenutzerInnen die Möglichkeit, selbst aus mehreren Alternativen zu wählen (Enck, Ongtang und McDaniel 2009). 2.3 Android Applikationen Android Applikationen werden großteils in Java geschrieben, können allerdings durch das Android Native Development Kit (NDK) auch native Komponenten (siehe Kapitel 2.3.5) enthalten. Mit Hilfe der Android SDK Werkzeuge wird der Quellcode kompiliert und zusammen mit allen benötigten Ressourcen zu einem Android Package (APK) zusammengefasst. Dabei handelt es sich um eine Archivdatei mit der Endung.apk, welche später auf Android Endgeräten installiert werden kann. (Google 2014f) Komponenten Eine Android Applikation besteht aus verschiedenen Komponenten. Jede Komponente kann dabei einen Einstiegspunkt in die Applikation darstellen. Es gibt vier verschiedene Arten von Komponenten. Jede davon dient einem bestimmten Zweck und verfügt über einen eigenen Lebenszyklus. Aktivitäten Eine Activity oder auch Aktivität repräsentiert eine einzelne Benutzeroberfläche. Zum Beispiel kann eine Kalender-Applikation eine Aktivität mit einer Wochenübersicht, eine

20 2 ANDROID GRUNDLAGEN 11 weitere Aktivität zum Eintragen eines Termins und eine Aktivität zum Anzeigen desselben besitzen. Obwohl diese verschiedenen Aktivitäten zusammenarbeiten, um für nahtlose Übergänge in der Kalender-Applikation zu sorgen, ist jede unabhängig von den anderen. Es ist sogar möglich, dass eine externe Applikation eine bestimmte Aktivität der Kalender-Applikation startet, sofern die Kalender-Applikation dass erlaubt. Beispielsweise könnte eine externe Geburtstags-Applikation die Aktivität zum Eintragen eines Termins der Kalender-Applikation verwenden. (Google 2014f) Auf nähere Details zum Lebenszyklus einer Aktivität wird in Kapitel eingegangen. Dienste Bei einem Service oder auch Dienst handelt es sich um eine Komponente, die im Hintergrund ausgeführt wird. Dienste werden vor allem für lang andauernde Operationen eingesetzt oder etwa um rechenaufwendige Aufgaben für Aktivitäten zu lösen, ohne deren GUI zu blockieren. Dienste verfügen über keine eigene GUI. Als Beispiel könnte ein Dienst Musik im Hintergrund abspielen oder Daten von einem externen Server herunterladen, während sich der oder die BenutzerIn gerade in einer anderen Applikation befindet. Dienste können von einer Aktivität oder durch einen Broadcast Receiver gestartet werden. Ein Dienst ist selbst für seinen Lebenszyklus verantwortlich und wird normalerweise nicht automatisch vom System beendet (Google 2014f). Content Providers Content Provider sind für die Verwaltung der Daten einer Applikation verantwortlich. EntwicklerInnen können Daten auf dem Dateisystem, in einer SQLite Datenbank, im Internet oder auf jeglichem anderen persistenten Speicherort ablegen, auf den sie Zugriff haben. Durch einen Content Provider wird es externen Applikationen ermöglicht, auf diese Daten zuzugreifen oder diese sogar zu ändern, sofern sie über die nötigen Berechtigungen verfügen. Das Android Betriebssystem stellt zum Beispiel einen Content Provider zur Verfügung, der Zugriff auf Kontaktdaten bietet. Jede Anwendung, die über die nötigen Berechtigungen verfügt, kann somit Kontaktdaten abfragen oder auch Informationen über einen bestimmten Kontakt bearbeiten (Google 2014f). Broadcast Receivers Ein Broadcast Receiver ist eine Komponente, die auf systemweite Broadcast-Mitteilungen reagiert. Viele Broadcasts stammen direkt von Android, beispielsweise die Nachricht, dass der Bildschirm ausgeschaltet wurde, die Batterie schwach ist, ein Anruf hereinkommt oder der Bootvorgang abgeschlossen wurde. Auch Applikationen können Broadcasts aussenden, beispielsweise um anderen Applikationen mitzuteilen, dass bestimmte Daten von nun an zur weiteren Nutzung bereitstehen. So wie zuvor bereits Dienste verfügen auch Broadcast Receiver über keine eigene GUI, sie können allerdings eine Mitteilung in der Android Statusbar erstellen, um auf ein bestimmtes Ereignis hinzuweisen. Meistens verrichtet ein

21 2 ANDROID GRUNDLAGEN 12 Broadcast Receiver nur sehr wenig oder gar keine Arbeit, sondern startet eine andere Komponente, meist einen Dienst, welcher diese Arbeit anschießend, basierend auf dem empfangenen Ereignis, verrichtet (Google 2014f). Wie eine andere Komponente gestartet werden kann, wird im folgenden Unterkapitel beschrieben Aktivierung von externen Komponenten Ein einzigartiger Aspekt des Android Betriebssystems ist die Tatsache, dass jede Applikation Komponenten einer anderen starten und benutzen kann. Wenn EntwicklerInnen zum Beispiel wollen, dass BenutzerInnen mit der Kamera des Endgerätes Videos aufnehmen, kann diese Funktionalität von einer externen Applikation bereitgestellt werden. Das aufgenommene Video wird anschließend an die eigene Applikation zur Weiterverarbeitung übergeben. Den EntwicklerInnen bleibt somit die Implementierung einer eigenen Aktivität zum Aufnehmen von Videos erspart. Dafür muss nicht einmal auf den Programmcode der externen Kamera-Applikation zugegriffen, sondern einfach nur deren Aktivität zum Aufnehmen von Videos gestartet werden. Für BenutzerInnen der Applikation erscheint es so, als ob die Kamera-Funktionalität Teil dieser wäre. Wenn eine Komponente gestartet werden soll, wird zuerst ein neuer Prozess, beziehungsweise eine neue VM, erstellt (wenn diese nicht bereits im Hintergrund läuft) und die Klassen, welche für die Komponente benötigt werden, instantiiert. Wenn wie im obigen Beispiel die Kamera-Aktivität gestartet wird, wird diese nicht in der VM der eigenen Anwendung ausgeführt. So kann die Isolation der Anwendungen aufrecht erhalten bleiben. Da es sich um verschiedene VMs beziehungsweise Prozesse handelt, können Android Applikationen die Komponenten von anderen Anwendungen auch nicht direkt starten (Google 2014f). Abbildung 2: Start einer externen Aktivität (Google 2014c) Wie in Abbildung 2 zu sehen ist, geschieht der Start von externen Komponenten, oder in diesem Fall einer Aktivität, durch einen Intent (siehe Kapitel 2.2.6). In Schritt 1 wird ein Intent, mit dem Wunsch eine bestimmte Aktivität zu starten, an startactivity()

22 2 ANDROID GRUNDLAGEN 13 übergeben. In Schritt 2 sucht das Android System unter allen installierten Anwendungen, ob eine entsprechende Aktivität vorhanden ist. Wurde diese gefunden, kann sie in Schritt 3 vom Android System gestartet werden (Google 2014c). Welche Komponenten eine Applikation enthält, wird in ihrem Manifest deklariert Android Manifest Bevor das Android System eine Applikations-Komponente starten kann, muss es wissen, dass diese Komponente existiert. Aus diesem Grund verfügt jede Android Applikation in ihrem Stammverzeichnis über eine Datei namens AndroidManifest.xml. In dieser Manifest-Datei müssen alle Komponenten deklariert sein (Google 2014f). Zusätzlich zur Deklaration der Komponenten, enthält das Android Manifest weitere wichtige Informationen, unter anderem folgende: Alle Berechtigungen, wie zum Beispiel Zugriff auf das Internet oder das Lesen von Kontaktdaten, die von der Applikation benötigt werden. Das minimale API Level (siehe Tabelle 1), welches von der Applikation vorausgesetzt wird. Deklaration aller Hardware-Features, wie zum Beispiel Kamera oder GPS Modul, auf die von der Applikation zugegriffen wird. Deklaration von zusätzlichen Bibliotheken, die nicht bereits im Android Framework enthalten sind, wie zum Beispiel die Google Maps Bibliothek. Listing 1 zeigt den Inhalt der Android Manifest Datei einer Beispielapplikation. Darin werden das Paket (at.torghele.camera), die Version der Applikation, das minimale API-Level sowie benötigte Berechtigungen (android.permission.camera) und Features (android.hardware.camera und android.hardware.camera.autofocus) aufgelistet. Außerdem wurde eine Aktivitäts-Komponente deklariert Ressourcen Android Anwendungen bestehen nicht nur aus Programmcode, sondern beinhalten auch andere Ressourcen, beispielsweise Bilder oder XML-Dateien. Unter Android werden zum Beispiel Animationen, Menüs, Farben und das Layout von GUI-Elementen in XML-Dateien gespeichert (Google 2014f). Die Vorteile sind folgende: Eigenschaften einer Applikation, wie zum Beispiel das Erscheinungsbild, können an einer zentralen Stelle, und nicht im Code selbst, modifiziert werden. Es ist einfach, mehrere alternative Ressourcen, zum Beispiel Bilder mit verschiedenen Auflösungen für verschiedene Endgeräte, bereitzustellen.

23 2 ANDROID GRUNDLAGEN 14 Listing 1: AndroidManifest.xml 1 <? xml version ="1.0" encoding =" utf -8"? > 2 <manifest xmlns: android =" schemas. android.com/apk/res/ android" 3 package="at.torghele.camera" 4 android: versioncode ="1" 5 android: versionname =" 1.0" > 6 <uses -sdk android: minsdkversion ="8" /> 7 <uses - permission android:name=" android. permission. CAMERA" /> 8 <uses - feature android:name=" android. hardware. camera" /> 9 <uses - feature android:name=" android. hardware. camera. autofocus" /> 10 <application android: label="@string/ app_name" > 11 <activity android:name=" CameraActivity" 12 android:label="@string/app_name"> 13 <intent - filter > 14 <action android:name=" android. intent. action.main" /> 15 <category android:name=" android. intent. category. LAUNCHER" /> 16 </intent -filter > 17 </activity > 18 </ application > 19 </manifest > Nativer Code Seit Juni 2009 bietet Google mit dem NDK die Möglichkeit, Android Applikationen nicht nur in Java, sondern zum Teil auch in C/C++ zu programmieren. Diese Vorgehensweise kann für manche Applikationen hilfreich sein, da auf existierende Bibliotheken, die in diesen Sprachen implementiert wurden, zurückgegriffen werden kann. Gewöhnliche Android Applikationen profitieren allerdings nicht oder nur selten von der Verwendung von nativen Bibliotheken, da deren Performance-Vorteil meist nicht im Verhältnis mit der zusätzlichen Komplexität der Applikationen steht. Typische Kandidaten für die Verwendung des NDK sind CPU- und GPU-intensive Anwendungsbereiche, wie beispielsweise Spiele-Engines, Signalverarbeitung oder Physik-Simulationen (Google 2014d). Der Performance Unterschied von nativem C/C++ Code zu in der Dalvik-VM interpretiertem Code wurde in (Lee und Jeon 2010) untersucht. Besonders hervorzuheben ist hierbei eine starke Performance-Steigerung im Hinblick auf Speicher-Operationen und Integer Kalkulationen. Kompatibilität Native Bibliotheken, welche mit Hilfe des Android NDKs erstellt wurden, können auf den Android Plattformen ab einem bestimmten API-Level verwendet werden. Um welches API-Level es sich dabei handelt, hängt von der CPU Architektur des Endgerätes ab.

24 2 ANDROID GRUNDLAGEN 15 CPU Architektur ARM, ARM-NEON x86 MIPS kompatible Android Plattformen Android 1.5 (API-Level 3) und höher Android 2.3 (API-Level 9) und höher Android 2.3 (API-Level 9) und höher Tabelle 3: Android NDK Kompatibilität Wie in Tabelle 3 zu sehen ist, genügt bei ARM-basierten Systemen das API-Level 3 beziehungsweise Android 1.5 oder eine neuere Version. Ab API-Level 2.3 werden auch x86 und MIPS unterstützt. Um native Bibliotheken zu implementieren, die auf die OpenGL ES APIs zugreifen, wird API-Level 4 für OpenGL ES 1.1 beziehungsweise API-Level 5 für OpenGL ES 2.0 vorausgesetzt Start einer Applikation Jede Android Applikation läuft standardmäßig in ihrem eigenen Linux Prozess mit nur einem Thread. Dieser Haupt-Thread besitzt eine Instanz von android.os.looper, in der alle Aufgaben nacheinander abgearbeitet und an die entsprechenden Funktionen weitergeleitet werden. Ein solcher Anwendungs-Prozess wird immer dann gestartet, wenn er benötigt wird und nicht bereits im Hintergrund läuft. Dies kann der Fall sein, wenn die Applikation von einem Benutzer oder einer Benutzerin gestartet wird oder der Start einer ihrer Komponenten von einem Dienst, einem Broadcast Receiver oder einer Aktivität angefordert wird. Prozesse werden gewöhnlich vom System so lange am Leben erhalten wie möglich, auch wenn keine Interaktion durch BenutzerInnen stattfindet. Sie werden erst vom System beendet, wenn es zu Ressourcen-Engpässen kommt. Dabei werden diejenigen Prozesse als erstes beendet, die am längsten inaktiv beziehungsweise im Hintergrund waren. Auf diese Art wird das aufwendige Starten und Beenden der VMs, in denen normalerweise jeweils nur eine Anwendung läuft, minimiert (Karandikar 2010). Um das Starten der Dalvik VM für jede einzelne Applikation zu beschleunigen und um Ressourcen zu sparen, gibt es unter Android einen besonderen Prozess namens Zygote. Der Zygote Prozess Dieser Prozess wird sehr früh während des Boot-Vorganges des Android Systems gestartet. Es handelt sich dabei um die erste Instanz der Dalvik VM, in der bereits alle Applikationsframework-Klassen und andere System-Bibliotheken geladen werden. Danach hört der Zygote Prozess auf ein Socket-Interface, um bei Bedarf neue VMs für andere Applikationen zu starten. Wird eine neue VM vom System angefordert, forkt sich der Zygote Prozess selbst und stellt somit eine vor-initialisierte Instanz der Dalvik VM samt Applikationsframework und benötigter Bibliotheken zum Ausführen einer Android Applikation zur Verfügung (Karandikar 2010).

25 2 ANDROID GRUNDLAGEN 16 Beim Aufruf von fork() erstellt der aktuelle Prozess eine Kopie von sich selbst. Da dies allerdings mittels Copy-on-Write geschieht, muss vorerst kein physischer Speicher dupliziert werden. Stattdessen können die virtuellen Speicherseiten in beiden Prozessen auf dieselben physischen Speicherseiten zeigen. Erst wenn eine dieser Speicherseiten verändert wird, muss diese dupliziert werden (Bach 1986). Abbildung 3: Start einer Android Applikation (Karandikar 2010) Abbildung 3 zeigt den Start einer Android Applikation. Nach einem Klick-Event wird zuerst ein Intent an den Activity Manager Service geschickt. Dieser sammelt anschließend Informationen über das Ziel des Intents und speichert diese für die weitere Verwendung im Intent-Objekt ab. An dieser Stelle wird überprüft, ob der Benutzer oder die Benutzerin über die nötigen Rechte verfügt, um die Ziel-Komponente auszuführen und wenn ja, ob der Applikations-Prozess bereits läuft. Es werden drei verschiedene Phasen während des Starts eines neuen Applikations-Prozesses unterschieden: 1. Prozess erzeugen 2. Applikation binden 3. Aktivität, Dienste oder Broadcast Receiver starten 1. Prozess erzeugen Der Activity Manager Service erzeugt einen neuen Prozess, indem er die Methode startprocesslocked() aufruft, welche über eine Socket-Verbindung Argumente an den

26 2 ANDROID GRUNDLAGEN 17 Zygote Prozess schickt. Dieser forkt sich anschließend selbst, startet den ActivityThread und gibt den Process Identifier (PID) des neu erstellten Prozesses zurück. 2. Applikation binden Im nächsten Schritt wird die Applikation an den Prozess gebunden. Dies geschieht, indem eine BIND_APPLICATION Nachricht an den ActivityThread, beziehungsweise an die darin ausgeführte Looper-Instanz, geschickt wird. Diese gibt die Nachricht an handlemessage() und in weiterer Folge an handlebindapplication() weiter, woraufhin ein Aufruf von makeapplication() folgt. An dieser Stelle werden schließlich die applikationsspezifischen Klassen geladen. 3. Aktivität starten Nach dem Binden der Applikation an den Prozess befinden sich die Klassen der Anwendung im privaten Speicher des Prozesses. Das Starten einer Aktivität unterscheidet sich von hier an nicht, egal ob es sich um einen neu erstellten oder einen bereits laufenden Prozess handelt. Dazu wird vom Activity Manager Service die LAUNCH_ACTIVITY Nachricht an den ActivityThread gesendet. Diese Nachricht wird durch den Looper von der handlelaunchactivity() Methode entgegengenommen, welche die entsprechende Aktivität schließlich startet. Lebenszyklus einer Aktivität Aktivitäten werden unter Android durch einen Activity Stack verwaltet. Die Oberste ist immer die gerade laufende Aktivität (Google 2014a). Wie in Abbildung 4 zu sehen ist, kann eine Aktivität dabei immer nur einen von vier Zuständen aufweisen: laufend: Wenn sich eine Aktivität am Bildschirm im Vordergrund befindet, ist sie aktiv oder läuft. Dieser Aktivität wird vom System die höchste Priorität zugewiesen und nur in Notfällen, etwa wenn sie mehr Speicher verbraucht als vom System zur Verfügung gestellt werden kann, beendet. pausiert: Wenn eine Aktivität den Fokus verloren hat, aber trotzdem noch sichtbar ist, beispielsweise wenn sich eine transparente Aktivität oder ein Dialogfeld darüber befindet, wird sie pausiert. Anders als pausiert vermuten lässt, bleibt die Aktivität allerdings vollständig aktiv, sie ist ja auch noch teilweise sichtbar. Eine pausierte Aktivität wird deshalb vom System nur bei extremer Ressourcenknappheit beendet. gestoppt: Wenn eine Aktivität vollkommen von einer anderen überdeckt wird, geht sie in den Zustand gestoppt über. Sie speichert den aktuellen Zustand und kann somit vom System sicher beendet werden, wenn an anderer Stelle Ressourcen benötigt werden.

27 2 ANDROID GRUNDLAGEN 18 Abbildung 4: Lebenszyklus einer Aktivität (Google 2014a) beendet: Wenn sich eine Aktivität im Zustand pausiert oder gestoppt befindet, kann sie vom System beendet werden. Wenn die beendete Aktivität allerdings am Activity Stack wieder an vorderste Stelle rückt, muss sie neu gestartet und ihr vorheriger Zustand wiederhergestellt werden. Abbildung 4 zeigt ein Diagramm mit den wichtigsten Zuständen einer Aktivität und ihren möglichen Transitionen. 2.4 Android Sicherheit Bei einer offenen Plattform wie Android stellt die Sicherheit eine besondere Herausforderung dar. Alle Änderungen am Android Quellcode unterlaufen deshalb dem Android Security Program (Google 2014e). Dieses beinhaltet unter anderem folgende Schritte: Penetrationstests und Code-Reviews: Während der Entwicklung von Android Komponenten, werden diese einer Vielzahl von Sicherheitsüberprüfungen unterzo-

28 2 ANDROID GRUNDLAGEN 19 gen. Diese werden vom Android Security Team und dem Information Security Engineering Team von Google, sowie von unabhängigen Sicherheits-Beratern durchgeführt. Ziel ist es, mögliche Schwachstellen bereits vor der Veröffentlichung des Quellcodes zu beheben. Open Source und Community-Review: Das AOSP ermöglicht eine umfassende Sicherheitsüberprüfung durch die Community. Android verwendet auch andere quelloffene Technologien wie den Linux Kernel, der weitgehenden Sicherheitsüberprüfungen unterzogen wurde. Laufende Überwachung: Trotz dieser Vorkehrungen kann es nach dem Ausliefern der Software zu Problemen kommen. Deshalb überwacht das Android Security Team Diskussionen zu Android-spezifischen oder allgemeinen Sicherheitsrisiken, um auf potentielle Gefahren und Schwachstellen schnellstmöglich zu reagieren. Das Android Betriebssystem versucht, personenbezogene Daten und System-Ressourcen bestmöglich zu schützen, sowie Applikationen voneinander zu isolieren. Um diese Ziele zu erreichen, setzt Android auf fünf Sicherheits-Bestandteile: 1. Robuste Sicherheit auf Betriebssystem-Ebene durch den Linux Kernel 2. Obligatorische Applikations-Sandbox für alle Anwendungen 3. Sichere Kommunikation zwischen Prozessen 4. Signierung und Verifizierung von Applikationen 5. Anwendungsdefinierte, von BenutzerInnen gewährte Berechtigungen Auf der Ebene des Betriebssystems baut die Android Plattform auf der Sicherheit des Linux Kernels, sowie einer Android-spezifischen Schnittstelle zur prozessübergreifenden Kommunikation namens Binder auf. Diese IPC Schnittstelle ermöglicht es Applikationen, die in verschiedenen Prozessen ausgeführt werden, zu kommunizieren. Auch nativer Code wird von der Applikations-Sandbox berücksichtigt. Wenn es sich dabei um schädlichen Code handelt, sollte dieser nicht auf andere Anwendungen oder das System übergreifen können (Google 2014e). In den folgenden Unterkapiteln wird auf diese Bestandteile, sowie auf bestehende Arbeiten, die sich näher mit der Sicherheit auseinandersetzen, eingegangen System- und Kernel-Sicherheit Die Basis der Android Plattform stellt der Linux Kernel dar. Dieser existiert seit Anfang der 1990er Jahre und wird in Millionen von sicherheitskritischen Umgebungen eingesetzt. In seiner Geschichte wurde er von tausenden EntwicklerInnen untersucht, attackiert und

29 2 ANDROID GRUNDLAGEN 20 repariert. Dadurch entwickelte er sich zu einem stabilen und sicheren Kernel, dem viele Firmen und Sicherheits-Experten vertrauen (Google 2014e). Der Linux Kernel stellt der Android Plattform einige wichtige sicherheitsrelevante Funktionen zur Verfügung, unter anderem: Ein Berechtigungsmodell auf BenutzerInnen- und Gruppen-Ebene Isolation von Prozessen Erweiterbare Mechanismen zur prozessübergreifenden Kommunikation Die Möglichkeit, nicht benötigte und potentiell unsichere Komponenten aus dem Kernel zu entfernen Als ein MehrbenutzerInnen-Betriebssystem ist es eines der fundamentalen Ziele des Linux Kernels, Ressourcen von BenutzerInnen voneinander zu isolieren. Er stellt sicher, dass: BenutzerIn A nicht auf Dateien von BenutzerIn B zugreifen kann BenutzerIn A nicht den Hauptspeicher von BenutzerIn B verbraucht BenutzerIn A nicht die CPU-Ressourcen von BentzerIn B erschöpft BenutzerIn A nicht die Geräte (zum Beispiel GPS) von BenutzerIn B blockiert Vor Android 4.3 beruhte diese Isolation auf Discretionary Access Control (DAC). Dabei handelt es sich um ein Sicherheitskonzept, bei dem die Entscheidung, ob auf eine Ressource zugegriffen werden darf oder nicht, auf BenutzerInnen- und Gruppen-Basis getroffen wird. DAC weist einige gravierende Nachteile auf. Darunter die Möglichkeit, dass fehlerhafte oder bösartige Applikationen Daten durchsickern lassen können, die grobe Granularität der DAC-Berechtigungen und das Unvermögen, Systemprogramme zu isolieren, die als Root ausgeführt werden (Smalley und Craig 2013). SELinux SELinux wurde ursprünglich von der National Security Agency als Linux Security Modul entwickelt. Es beinhaltet unter anderem einen Mandatory Access Control (MAC) Mechanismus, der die Schwächen von DAC überwinden soll. Im Gegensatz zu DAC erzwingt SELinux eine systemweite Sicherheits-Policy, die alle Prozesse, Objekte und Operationen einschließt. Durch den MAC Mechanismus ist es SELinux möglich, schädliche und fehlerhafte Anwendungen, sogar diejenigen, die als Root oder Superuser ausgeführt werden, zu isolieren (Smalley und Craig 2013). Ohne SELinux wäre Android ein leichtes Ziel für Angriffe auf System-Services, die als Root ausgeführt werden. Würde ein Angreifer dort eine Schwachstelle finden, könnte er

30 2 ANDROID GRUNDLAGEN 21 die volle Kontrolle über das Endgerät erlangen. Die Community hat im Laufe der Zeit bereits einige kritische Sicherheitsschwachstellen in Android gefunden. Diese Schwachstellen reichten von Buffer-Overflows in frühen Versionen des Applikationsframeworks bis hin zur Interpretation von allen lokalen Tasteneingaben auf G1 Smartphones als Root-Shell Kommandos (Shabtai, Fledel und Elovici 2010). Beginnend mit Android 4.3 wurde SELinux in den Android Kernel aufgenommen, um dessen Sicherheit zu erhöhen. Zum Beispiel muss eine Anwendung typischerweise über Root- Rechte verfügen, um auf die System-Partition zu schreiben. Wenn in einer traditionellen DAC basierten Linux-Umgebung, wie es vor Android 4.3 der Fall war, der Root-Benutzer kompromittiert wurde, konnte eine Applikation Zugriff auf alle Systemdateien erlangen. SELinux kann in so einem Fall den Zugriff mit Hilfe einer Policy trotzdem verhindern. Solch eine Policy könnte beispielsweise besagen, dass Anwendungen von Drittanbietern, auch wenn sie als Root ausgeführt werden, keinen Zugriff auf Systemdateien erhalten (Google 2014e) Applikations-Sandbox Einer der Grundpfeiler für die Sicherheit unter Android ist die sogenannte Applikations- Sandbox. Darunter ist die Isolation von Ressourcen auf BenutzerInnen und Gruppenebene durch den Linux Kernel gemeint. Das Android System weist jeder Applikation während der Installation einen eindeutigen User Identifier (UID) zu. Jede Applikation wird in weiterer Folge immer in einem eigenen Prozess, dem diese UID zugewiesen ist, ausgeführt. Dieser Ansatz unterscheidet sich von anderen Betriebssystemen (einschließlich der traditionellen Linux-Distributionen) dahingehend, dass normalerweise mehrere Anwendungen einem oder einer BenutzerIn zugewiesen sind. Dadurch entsteht eine Applikations-Sandbox auf Level des Kernels. Standardmäßig können Applikationen nicht untereinander kommunizieren und haben nur begrenzten Zugriff auf das Betriebssystem. Wenn Anwendung A etwas Bösartiges versucht, wie etwa auf die Daten von Anwendung B zuzugreifen oder einen Anruf zu tätigen, wofür wiederum eine separate Anwendung C nötig ist, wird das vom Kernel verhindert, wenn Anwendung A nicht über die nötigen Rechte verfügt. Da sich diese Anwendungs-Sandbox im Kernel befindet, greift sie auch bei nativen Code und System-Anwendungen. Jegliche Software oberhalb des Kernels, wie in Abbildung 1 zu sehen ist, einschließlich System-Bibliotheken, Applikationsframework und die Android Runtime samt aller Applikationen, wird in dieser Sandbox ausgeführt. Auf einigen Betriebssystemen können Speicherzugriffsverletzungen die Sicherheit des gesamten Systems beeinträchtigen. Das ist unter Android nicht der Fall, da sich alle Applikationen und deren Ressourcen in einer Sandbox auf Betriebssystem- Ebene befinden. Eine Speicherzugriffsverletzung erlaubt nur das Ausführen von Code im Kontext der jeweiligen Applikation, unter Berücksichtigung der ihr gewährten Berechtigungen. Wie jedes Sicherheits-Feature ist auch die Android Applikations-Sandbox nicht unüberwindbar. Um jedoch aus der Sandbox eines standardmäßig konfigurierten Android Systems auszubrechen, muss der Linux Kernel kompromittiert werden (Google 2014e).

31 2 ANDROID GRUNDLAGEN Prozessübergreifende Kommunikation IPC ist auf Android über die herkömmlichen UNIX Mechanismen, wie das Dateisystem, lokale Sockets oder Shared Memory möglich. Diese Mechanismen sollten allerdings nur in Ausnahmefällen direkt von EntwicklerInnen verwendet werden, weil dadurch Android Sicherheits-Mechanismen umgangen werden. Android stellt deshalb für die Kommunikation zwischen verschiedenen Komponenten eigene Mechanismen zur Verfügung: Binder: Dabei handelt es sich um einen leichtgewichtigen, hoch performanten RPC Mechanismus. Dienste: Dienste können ein Interface bereitstellen, welches direkt durch Binder angesprochen werden kann. Intents: Ein Intent ist eine Nachricht, die über die Binder IPC Schnittstelle gesendet wird, siehe Kapitel Content Provider: Content Provider sind für die Verwaltung der Daten einer Applikation verantwortlich und können diese auch anderen Prozessen oder Applikationen zur Verfügung stellen, siehe Kapitel Wie in der obigen Auflistung zu sehen ist, spielt Binder für die IPC auf Android eine zentrale Rolle. Binder wurde als Kernel Modul implementiert und kann durch /dev/binder angesprochen werden. Dieser Endpunkt muss von allen Prozessen beschreibbar sein, wodurch es dem Linux Kernel nicht möglich ist, die Binder IPC durch DAC zu überwachen. Deshalb wird jegliche Kommunikation über Binder durch das Android Framework mittels eines MAC Referenz Monitors überwacht. Jede Applikation oder Applikations- Komponente verfügt dafür über bestimmte Berechtigungen, die in ihrer Manifest-Datei festgelegt werden. Wenn eine Komponente eine IPC initiiert, wird überprüft, ob die entsprechende Berechtigung vorhanden ist. Wenn ja, wird die IPC fortgesetzt, andernfalls abgebrochen, selbst wenn sich die Komponenten in derselben Applikation befinden (Enck, Ongtang und McDaniel 2009). In (Chin u. a. 2011) beschreiben die Autoren, welches Gefahrenpotential in den IPC Mechanismen von Android steckt, wenn EntwicklerInnen es verabsäumen, Sicherheitsvorkehrungen zu treffen. Hinausgehende Kommunikation kann zum Beispiel zu Broadcastund Datendiebstahl, der Modifikation von IPC Ergebnissen oder Aktivitäts- und Dienst- Hijacking führen. Hereinkommende Kommunikation kann eine Applikation der Gefahr von schädlichen Aktivitäten, dem ungewollten Start von Diensten oder einer Broadcast Injektion aussetzen. Wie in (Davi u. a. 2011) und (Felt, Wang u. a. 2011) beschrieben wird, kann es trotz der Applikations-Sandbox zu einer Confused Deputy Attack beziehungsweise Permission Re-Delegation kommen. Dies kann der Fall sein, wenn einzelne Komponenten einer Applikation nicht ordnungsgemäß vor der Verwendung von nicht autorisierten Anwendungen

32 2 ANDROID GRUNDLAGEN 23 geschützt wurden. Die Android Sicherheits-Architektur verhindert nicht, dass Komponenten, welche bestimmte Berechtigungen benötigen, von externen Applikationen aufgerufen werden, die nicht mindestens über dieselben Berechtigungen verfügen. Abbildung 5: Permission Re-Delegation Attack (Davi u. a. 2011) In Abbildung 5 wird eine mögliche Permission Re-Delegation Attack beschrieben. Hier kann Applikation A ohne besondere Berechtigungen eine Komponente von Applikation B nutzen. Applikation B wiederum verfügt über die Berechtigung, auf eine geschützte Komponente von Applikation C zuzugreifen. In weiterer Folge kann Applikation A diesen Umstand ausnutzen, um auf die geschützte Komponente von Applikation C zuzugreifen. In (Bugiel u. a. 2011) wird ein Framework namens XManDroid (extended Monitoring on Android) vorgestellt, das in der Lage sein soll, Privilege Escalation Attacks, worunter auch Permission Re-Delegation oder Confused Deputy Attacks fallen, zu verhindern. Das Framework erweitert dafür die Überwachungs-Mechanismen von Android dahingehend, dass auch der Gebrauch von transitiven Berechtigungen mittels MAC erkannt wird. Diese Arbeit wurde später in (Bugiel u. a. 2012) fortgesetzt. Da es sich bei Privilege Escalation Attacks allerdings um ein Schlupfloch in der Android Sicherheits-Architektur handelt, beziehungsweise um einen Mangel, der durch die fehlerhafte Implementierung von Applikations-Komponenten durch EntwicklerInnen hervorgerufen wird, kann auch MAC nicht immer davor schützen Applikations-Signierung Jede Applikation, die auf Android installiert werden soll, muss durch deren EntwicklerInnen signiert werden. Applikationen, die nicht signiert wurden, werden standardmäßig bei

33 2 ANDROID GRUNDLAGEN 24 der Installation entweder von Google Play oder dem Package Manager zurückgewiesen. Das gewährleistet einerseits, dass Applikationen unverändert auf den Endgeräten ankommen, andererseits können so EntwicklerInnen von Google für schädliches Verhalten ihrer Anwendungen zur Verantwortung gezogen werden. Die Signierung einer Applikation ist der erste Schritt, um eine Anwendung in der Android Sandbox auszuführen. Das Zertifikat entscheidet darüber, welche UID einer Applikation zugewiesen wird. Während der Installation überprüft der Package Manager, ob die zu installierende APK mit dem in ihr enthaltenen Zertifikat signiert wurde. Wenn ein Zertifikat für die Signierung mehrerer Applikationen verwendet wurde, besteht die Möglichkeit, dass sich diese Applikationen eine UID und somit auch eine Sandbox teilen. Da normalerweise jede Android Applikation in ihrer eigenen Sandbox ausgeführt wird und es sich dabei um einen der grundlegenden Sicherheitsmechanismen unter Android handelt, muss jede beteiligte Applikation diese Ausnahme im Manifest deklarieren (Google 2014e). Nur weil eine Applikation signiert wurde, bedeutet dies allerdings nicht, dass sie nicht verändert wurde. Wie (Zhou, Zhou u. a. 2012) beschreiben, sind 5-13% aller Applikationen in alternativen Marktplätzen repackaged applications. Dabei handelt es sich meist um legitime, oft kostenpflichtige Applikationen aus dem offiziellen Google Play Store, die modifiziert wurden. Diese Modifikationen reichen vom Hinzufügen oder Austauschen von Werbebannern bis hin zum Hinzufügen von Schadcode. Die Applikationen werden nach der Modifikation zu neuen APK Dateien gepackt und neu signiert Applikations-Verifizierung Ein Bestandteil, der nicht direkt mit dem Android Betriebssystem zusammenhängt, aber dennoch für den Schutz von EndanwenderInnen vor Schadsoftware eine wichtige Rolle spielt, ist eine Software namens Bouncer. Dabei handelt es sich um einen in den Google Play Store integrierten Sicherheitsmechanismus, der verhindern soll, dass bösartige Applikationen in den offiziellen Marktplatz gelangen. Bouncer sucht dafür automatisch nach schädlichen Anwendungen und erspart EntwicklerInnen damit ein aufwendiges Review- Verfahren beim Veröffentlichen ihrer Applikationen. Der Dienst führt eine Reihe von Analysen auf neuen Applikationen, Applikationen, die sich bereits im Marktplatz befinden und auf EntwicklerInnen-Konten durch. Sobald eine Applikation in den Marktplatz hochgeladen wurde, startet der Dienst sofort mit der Suche nach bekannter Schadsoftware, Spyware und Trojanern. Anschließend wird eine dynamische Analyse der Applikation durchgeführt, und ihr Verhalten mit zuvor überprüften Anwendungen verglichen, um mögliche schädliche Verhaltensmuster zu identifizieren (Lockheimer 2012). In (Oberheide und Miller 2012) und (Paleari u. a. 2009) werden Verfahren beschrieben, wie Bouncer umgangen werden kann. Wird eine Applikation dynamisch analysiert, kann beispielsweise festgestellt werden, ob sie auf einem echten Endgerät oder in einem Emulator ausgeführt wird. Wird ein Emulator erkannt, wird kein schädlicher Code ausgeführt und dieser auch nicht erkannt.

34 2 ANDROID GRUNDLAGEN 25 Seit Android 4.2 verfügt Android über ein Feature namens Applikations-Verifizierung. Dieses wurde in weiterer Folge für alle Android Versionen beginnend mit 2.3 nachgereicht. Die Applikations-Verifizierung wird besonders empfohlen, wenn Anwendungen von unbekannten Quellen, beispielsweise alternativen Marktplätzen, installiert werden. Ist dieses Feature aktiviert, wird jede Applikation vor ihrer Installation auf mögliche Schadsoftware überprüft (Google 2014e). Abbildung 6: Applikations-Verifizierungs-Dienst von Google (Jiang 2012) In Abbildung 6 wird die Funktionsweise des Applikations-Verifizierungs-Dienstes beschrieben. Wenn eine Applikation installiert wird (Schritt 1), werden Informationen über diese (zum Beispiel Name, Version und Größe), sowie über das Endgerät, gesammelt (Schritt 2) und an die Google Cloud gesendet (Schritt 3). Die Google Cloud antwortet anschließend mit dem Ergebnis der Analyse (Schritt 4). Wenn die Applikation als potentiell gefährlich oder gefährlich eingestuft wurde, wird eine Warnmeldung angezeigt (Schritt 5). Potentiell gefährliche Applikationen können von dem oder der BenutzerIn auf eigene Gefahr installiert werden. Die Installation von gefährlichen Applikationen wird blockiert (Schritt 6). Aus einer Evaluierung (Jiang 2012) des Applikations-Verifizierungs-Dienstes geht hervor, dass dieser, kurz nach dessen Einführung, weniger als 25% der bekannten Schadsoftware Samples erkannte. Zum selben Zeitpunkt erzielten 9 von 10 getesteten Antivirus-Lösungen auf demselben Datensatz bereits eine Erkennungsrate von %. Seit einem Update des Google Play Store im Februar 2014 läuft die Applikations-Verifizierung auf allen Android Versionen, beginnend mit Android 2.3, periodisch im Hintergrund und nicht mehr nur vor der Installation, was zusätzlichen Schutz gewährleisten soll (Whitwam 2014) Berechtigungs-System Das Berechtigungs-System stellt einen der wichtigsten Sicherheits-Mechanismen auf Android dar. Es steuert den Zugang zu datenschutz- und sicherheitsrelevanten Teilen der Android API. Jede Anwendung enthält in ihrer Manifest-Datei (siehe Kapitel 2.3.3) Informationen dazu, welche Berechtigungen sie benötigt, um ordnungsgemäß zu funktionieren (Google 2014e). Solche sensible APIs, für die spezielle Berechtigungen benötigt werden, beinhalten unter anderem: Zugriff auf die Kamera zum Aufnehmen von Bildern und Videos

35 2 ANDROID GRUNDLAGEN 26 Zugriff auf das Mikrofon Zugriff auf Positionsdaten (GPS) Zugriff auf Funktionen zum Telefonieren Zugriff auf das Senden und Empfangen von SMS/MMS Zugriff auf Netzwerk beziehungsweise Datenverbindungen (Internet) Bei der obigen Auflistung handelt es sich um Berechtigungen, die unter die Kategorie Gefährlich fallen. Es gibt noch zwei weitere Kategorien, Normal und Signatur/System. Außerdem sind EntwicklerInnen von Android Applikationen in der Lage, eigene Berechtigungen zu definieren, um so den Zugriff auf ihre Anwendungen zu steuern (Felt, Chin u. a. 2011). Normal Normale Berechtigungen schützen BenutzerInnen vor API-Aufrufen, die zwar stören, allerdings keinen Schaden verursachen können. Ein Beispiel hierfür ist die Berechtigung SET_WALLPAPER, welche eine Applikation berechtigt, das Hintergrundbild eines Benutzers oder einer Benutzerin zu verändern. Gefährlich Gefährliche Berechtigungen schränken die Benutzung von potentiell gefährlichen APIs ein. Diese beinhalten beispielsweise den Zugriff auf personenbezogene Daten oder Funktionalität, die den Benutzer oder die Benutzerin Geld kosten kann. Dabei kann es sich etwa um das automatische Senden von SMS-Nachrichten oder den Zugriff auf das Adressbuch handeln. Signatur/System System- und Signatur-Berechtigungen steuern den Zugriff auf besonders gefährliche Teile der API, wie beispielsweise den Package Manager, mit dem Applikationen installiert oder gelöscht werden können. Diese Berechtigungen können deshalb auch nicht einfach, wie andere Berechtigungen, in der Manifest-Datei einer Applikation deklariert werden. Signatur- Berechtigungen werden nur Applikationen erteilt, die mit dem Zertifikat des Geräteherstellers signiert wurden. Um System-Berechtigungen zu erlangen, muss eine Applikation entweder vom Gerätehersteller signiert oder in ein spezielles System-Verzeichnis installiert worden sein. Dadurch wird die Verwendung von Signatur- oder System-Berechtigungen im Grunde auf vorinstallierte Applikationen limitiert, solange es sich nicht um ein gerootetes Endgerät handelt. Wurde ein Endgerät gerootet, können auch Applikationen von Drittanbietern mit Root-Rechten ausgeführt werden, womit vorhandene Sicherheits- Mechanismen umgangen werden.

36 2 ANDROID GRUNDLAGEN 27 Applikations-Berechtigungen Auch EntwicklerInnen können eigene Berechtigungen für ihre Applikationen definieren. Sie sind somit in der Lage, den Zugriff auf deren Funktionalität oder Daten zu schützen. Meist werden solche Berechtigungen auf Signatur-Basis definiert, um nur Applikationen derselben EntwicklerInnen Zugriff darauf zu erlauben. BenutzerInnen werden dazu aufgefordert, diese Berechtigungen vor der Installation einer jeden Anwendung, beziehungsweise beim Updaten, wenn sich an den Berechtigungen etwas geändert hat, zu bestätigen. Wie Abbildung 7 zeigt, liegt es in der Verantwortung der BenutzerInnen, ob sie einer Anwendung vertrauen oder die Installation anderenfalls abbrechen (Google 2014e). Abbildung 7: Berechtigungs Dialog bei der Installation einer Applikation (Google 2014e) Es ist jedoch fraglich, wie aufmerksam BenutzerInnen lesen, welche Berechtigungen von einer Applikation tatsächlich angefordert werden. Einer Studie zufolge (Felt u. a. 2012) beachteten nur 17% der Teilnehmer während der Installation von Applikationen die angeforderten Berechtigungen und nur 3% konnten drei Fragen zu diesen richtig beantworten. Auch wenn sich laut der Autoren nur knapp ein Fünftel der Probanden mit den Applikations-Berechtigungen auseinandergesetzt hat, könnten diese ausreichen, um andere BenutzerInnen zu schützen, wenn ihre Meinung über bestimmte Applikations- Berechtigungen erfolgreich über Applikations-Reviews kommuniziert werden kann. Ein großes Problem ist laut (Felt, Chin u. a. 2011) allerdings die Tatsache, dass gerade unerfahrene EntwicklerInnen routinemäßig mehr Berechtigungen anfordern als sie tat-

37 2 ANDROID GRUNDLAGEN 28 sächlich benötigen. In einer statischen Analyse von 900 Android Applikationen fanden die Autoren, dass 323 (35,8%) über-privilegiert waren. Da es sich hierbei, neben der Applikations-Sandbox, um einen der Grundpfeiler der Android Sicherheit handelt, beschäftigen sich bereits einige Arbeiten mit diesem Thema. Es wurden verschiedene Vorschläge erarbeitet, wie das Berechtigungs-System und der Zugriff auf APIs und Ressourcen auf Android verbessert werden könnten. Darunter finden sich unter anderem: Apex: Bei Apex handelt es sich um eine Erweiterung des Android Berechtigungs- Systems. Es erlaubt es BenutzerInnen, genau festzulegen, auf welche sensiblen Ressourcen eine Applikation Zugriff haben soll. Die Autoren bemängeln, dass BenutzerInnen unter Android bei der Installation einer Applikation zwar alle benötigten Berechtigungen aufgelistet bekommen, es aber nicht möglich ist, nur bestimmte Berechtigungen zu gewähren. Außerdem gibt es keine Möglichkeit, die Verwendung von bestimmten Ressourcen mittels Umgebungsvariablen, wie beispielsweise der momentanen GPS Position des Endgerätes, einzuschränken. Um diese Funktionalität zu bieten, wurden das bestehende Berechtigungs-System und die Anwendung zum Installieren von neuen Applikationen dementsprechend erweitert (Nauman, Khan und Zhang 2010). Saint: Das Saint Framework bietet eine erhöhte Flexibilität und Sicherheit für die Einschränkung von Applikations-Interaktionen. Dafür schränkt Saint nicht nur die Vergabe von bestimmten Berechtigungen während der Installation einer Applikation ein, sondern ermöglicht auch die Aufstellung von Regeln für die Kommunikation zwischen Applikationen. Dadurch können beteiligte Applikationen sicherstellen, dass ihre Kommunikation unter sicheren Bedingungen stattfindet. Beispielsweise könnte eine Einkaufs-Applikation über eine Liste von vertrauenswürdigen Bezahl- Applikationen verfügen. Ob eine Applikation vertrauenswürdig ist, könnte in weiterer Folge von deren Version abhängig gemacht werden, um beispielsweise Versionen der Anwendung mit bekannten Sicherheitslücken auszuschließen (Ongtang u. a. 2012). TISSA: In (Zhou u. a. 2011) beschreiben die Autoren einen Privacy-Modus für Android. Dieser Privacy-Modus kann dafür genutzt werden, einer Anwendung den Zugriff auf private Informationen zu verweigern. Wenn ein Benutzer oder eine Benutzerin eine nicht vertrauenswürdige Applikation installiert, kann er oder sie genau festlegen, welche privaten Informationen (beispielsweise Kontakte, Position oder Bilder) der Applikation zur Verfügung gestellt werden. Außerdem sind BenutzerInnen in der Lage, diese Einschränkungen zur Laufzeit anzupassen. MockDroid: Auch bei MockDroid (Beresford u. a. 2011) handelt es sich um eine modifizierte Version des Android Systems, die es erlaubt, den Zugriff auf bestimmte Berechtigungen zur Laufzeit zu unterbinden. Bei der Installation einer Anwendung müssen dafür nicht alle angeforderten Berechtigungen erlaubt werden. Immer, wenn

38 2 ANDROID GRUNDLAGEN 29 eine Applikation eine Ressource anfordert, für die keine Berechtigung erteilt wurde, wird diese vom System als leer oder nicht verfügbar zurückgegeben. Der Benutzer oder die Benutzerin wird in diesem Fall informiert und kann bei Bedarf die fehlende Berechtigung erteilen. Auf diese Art können BenutzerInnen während der Nutzung einer Applikation abwägen, ob die Funktionalität die Herausgabe von sensiblen Informationen rechtfertigt.

39 3 METHODEN 30 3 Methoden In diesem Kapitel werden verschiedene Arten von Android Schadsoftware und deren Erkennung beschrieben. Dazu werden verschiedene Herangehensweisen zum Extrahieren von Features aus Android Anwendungen besprochen und auf die Analyse dieser mittels maschinellen Lernens eingegangen. Besonderes Augenmerk liegt auf künstlichen neuronalen Netzen, Selbst-organisierenden Karten und Counterpropagation Artificial Neural Networks. 3.1 Android Schadsoftware Laut (Alcatel-Lucent 2014) steigt die Anzahl von mit Schadsoftware infizierten mobilen Endgeräten seit 2012 jährlich um etwa 20%. Seit Juni 2012 wurden fast Malware- Samples identifiziert. Abbildung 8: Infektionsrate mobiler Endgeräte (Alcatel-Lucent 2014) Abbildung 8 zeigt den monatlichen Prozentsatz von infizierten mobilen Endgeräten seit Dezember Zu sehen ist ein jährlicher Anstieg von etwa 20%. In der ersten Hälfte von 2014 hat sich dieser Anstieg allerdings fast verdoppelt. Die Infektionsrate von 0,65% entspricht etwa 15 Millionen infizierten Endgeräten, bei geschätzten 2,3 Milliarden Smartphones weltweit. Da diese Schätzung von (Alcatel-Lucent 2014) keine Daten zu Regionen wie China und Russland enthält, wo Infektionsraten laut der AutorInnen tendenziell höher ausfallen, entsprechen diese Zahlen eher einer unteren Grenze Arten von Schadsoftware BenutzerInnen von mobilen Endgeräten werden laut (Felt, Finifter u. a. 2011) von drei Arten mehr oder weniger schädlicher Software bedroht: Malware, Grayware und Personal Spyware. Diese drei Kategorien ergaben sich für die AutorInnen aufgrund der Art der Auslieferung von Schadsoftware, der Legalität der Software selbst und ob EndbenutzerInnen über die genaue Funktionalität dieser Software in Kenntnis gesetzt werden. Malware Malware verschafft sich Zugriff zu ansonsten geschützten Funktionen des Endgerätes, um beispielsweise Daten zu stehlen oder dem oder der BenutzerIn finanziellen Schaden zuzufü-

40 3 METHODEN 31 gen. Der oder die AngreiferIn bringt BenutzerInnen ohne deren Wissen oder Einwilligung dazu, schädliche Applikationen zu installieren, oder verschafft sich unbefugten Zugriff auf deren Endgeräte, indem er oder sie eine Sicherheitslücke ausnutzt. Malware inkludiert Trojaner, Würmer, Bot-Netze und Viren. Diese sind in den meisten Ländern verboten und deren Einsatz kann zu Gefängnisstrafen führen (Felt, Finifter u. a. 2011). Personal Spyware Personal Spyware sammelt über einen bestimmten Zeitraum personenbezogene Daten, wie beispielsweise den Aufenthaltsort (GPS Koordinaten) oder SMS-Nachrichten von BenutzerInnen. Um Personal Spyware einzusetzen, benötigten AngreiferInnen physischen Zugriff auf das zu überwachende Endgerät, um die Schadsoftware ohne das Wissen der Opfer zu installieren. Personal Spyware sendet die gesammelten Informationen direkt an den oder die AngreiferIn und nicht an die EntwicklerInnen der Software selbst. Zum Beispiel könnte ein Unternehmen Personal Spyware auf den Dienst-Telefonen der Mitarbeiter installieren. In einigen Ländern, wie beispielsweise den USA, ist es erlaubt Personal Spyware zu verkaufen, da KäuferInnen (AngreiferInnen) nicht selbst geschädigt werden und ihnen gegenüber der Zweck der Anwendung nicht verschleiert wird. Es ist allerdings illegal, Personal Spyware auf dem Smartphone einer anderen Person ohne deren Einwilligung zu installieren (Felt, Finifter u. a. 2011). Grayware Viele legitime Applikationen sammeln Informationen über deren BenutzerInnen, um Profile zu erstellen. Diese werden beispielsweise eingesetzt, um den BenutzerInnen personalisierte Werbung anzuzeigen. Grayware spioniert zwar BenutzerInnen aus, zielt allerdings nicht darauf ab, Schaden anzurichten. In vielen Fällen bietet diese sogar echte Funktionalität, wie zum Beispiel das Präsentieren oder Vorschlagen von auf BenutzerInnen zugeschnittene Inhalte. Unternehmen, die Grayware vertreiben, müssen darauf in ihrer Datenschutzerklärung hinweisen. Grayware befindet sich oftmals an der Grenze zur Illegalität, je nachdem wie detailliert die jeweilige Datenschutzerklärung ist beziehungsweise ob die darin enthaltenen Paragrafen rechtmäßig sind. Wenn in dieser Arbeit von Schadsoftware gesprochen wird, liegt der Fokus vor allem auf verschiedenen Arten von Malware, also Trojanern, Würmern, Bot-Netzen und Viren. Motivation hinter Schadsoftware Abbildung 9: Die Motivation hinter Schadsoftware (F-Secure 2014)

41 3 METHODEN 32 Wie Abbildung 9 zeigt, ist die Motivation hinter mobiler Schadsoftware vor allem finanzieller Profit. (Juniper 2013) zufolge wird davon ausgegangen, dass jede veröffentlichte schädliche Applikation im Durchschnitt einen sofortigen Gewinn von 10 USD abwirft. 19 Prozent der von F-Secure im ersten Quartal 2014 analysierten Schadsoftware gliederte das Endgerät zusätzlich in ein Bot-Netz ein. Dadurch sind AngreiferInnen in der Lage, die Endgeräte über einen Command-and-Controll-Server zu steuern und in weiterer Folge für ihre Zwecke zu missbrauchen. Laut (F-Secure 2014) stellen momentan Trojaner die größte Gefahr für mobile Endgeräte dar. Dabei wurden im ersten Quartal 2014 typischerweise eine oder mehrere der folgenden Aktivitäten ausgeführt: SMS-Betrug: SMS-Nachrichten werden an Mehrwertnummern gesendet oder der oder die BenutzerIn wird bei auf SMS-Nachrichten basierenden Abo-Diensten angemeldet. Applikations-Download: Unerwünschte Applikationen werden im Hintergrund, ohne das Wissen des oder der BenutzerIn, heruntergeladen und installiert. Datendiebstahl: Diebstahl von Kontakten, Fotos und anderen personenbezogenen Daten wie beispielsweise der GPS Position. Link-Klicker: Im Hintergrund werden automatisch Websites aufgerufen und/oder auf Werbebanner geklickt, um so Umsätze zu generieren. Bank Betrug: Online-Banking bezogene SMS-Nachrichten werden mitgelesen. Fake Antivirus: Eine Applikation gibt vor, eine mobile Antivirus Lösung zu sein, besitzt jedoch keine entsprechende Funktionalität. Einheben von Gebühren: Es werden für die Benutzung, das Aktualisieren oder die Installation einer legitimen (meist freien) Applikation Gebühren verrechnet Installations-Methoden Um mobile Endgeräte zu infizieren, werden BenutzerInnen oftmals dahingehend getäuscht, dass sie schädliche Applikationen selbst herunterladen und installieren. (Jiang und Zhou 2013) teilten nach der Analyse von 1260 Schadsoftware Samples die Installations-Methoden in drei Haupt-Kategorien ein: 1. Repackaging: Dabei handelt es sich um eine der am weitesten verbreiteten Techniken, die EntwicklerInnen von Schadsoftware verwenden. Dazu wird schädlicher Code in legitimen Applikationen versteckt. Der oder die AngreiferIn muss dazu eine legitime Applikation herunterladen, diese de-kompilieren, den Schadcode hinzufügen und

42 3 METHODEN 33 die Applikation anschließend zu einer neuen APK kompilieren und diese neu signieren. Um nicht aufzufallen, wird der Schadcode oftmals in harmlos klingenden Klassen und Namensräumen versteckt, beispielsweise com.sec.android.provider.drm. Danach wird die modifizierte Applikation im offiziellen Google Play Store oder einem alternativen Marktplatz veröffentlicht. Laut (Jiang und Zhou 2013) handelte es sich bei 1083, der von ihnen analysierten 1260 schädlichen Applikationen (86%) um solche modifizierten Versionen von legitimen Anwendungen. Von den 49 Schadsoftware- Familien in ihrem Datensatz, nutzten 25 diese Technik, um Endgeräte zu infizieren. 2. Update Attack: Bei der ersten Technik wird einer Applikation der gesamte Schadcode eingepflanzt, der nötig ist, um einen Angriff zu starten. Dadurch besteht ein hohes Risiko, dass der schädliche Code durch statische Analyse erkannt wird. Eine Update Attack macht diese Erkennung schwieriger. In den meisten Fällen wird auch hier Schadcode in legitimen Applikationen versteckt, jedoch nicht der gesamte, sondern nur eine Update Komponente, die den wirklichen Schadcode zur Laufzeit nachlädt. Im Datensatz des Android Malware Genome Project (Jiang und Zhou 2013) befinden sich vier Schadsoftware-Familien, die diese Technik nutzen: BaseBridge, DroidKungFuUpdate, AnserverBot und Plankton. Die ersten beiden benötigen das Einverständnis des oder der BenutzerIn, um die Applikation zu aktualisieren. Im Fall von AnserverBot und Plankton werden BenutzerInnen komplett umgangen. Anstelle der gesamten Applikation werden nur Teile ausgetauscht, wodurch auf dem Android System keine Zustimmung des oder der BenutzerIn benötigt wird. Plankton lädt dafür eine Java Archive (JAR)-Datei herunter und führt diese aus, während AnserverBot einen verschlüsselten Blog Eintrag herunterlädt, der den schädlichen Code enthält. 3. Drive-by Download: Dabei handelt es sich um eine Technik, bei der BenutzerInnen durch aggressive Werbung in Applikationen oder durch QR-Codes dazu bewegt werden, Schadsoftware zu installieren. Beispiele hierfür sind GGTracker, Jifake, Spitmo oder ZitMo. Bei der GGTracker Schadsoftware gelangen BenutzerInnen nach dem Klick auf einen Werbebanner auf eine Website, die dem Google Play Store nachempfunden wurde und werden aufgefordert, eine Applikation zu installieren. Bei Jifake geschieht dasselbe durch das Scannen eines QR-Codes. Beide Schadsoftware- Familien versenden fortan kostenpflichtige SMS-Nachrichten. Bei Spitmo und ZitMo handelt es sich um Schadsoftware, die unter die Rubrik Bank-Betrug fallen. In beiden Fällen muss allerdings der PC oder Laptop von BenutzerInnen von Online-Banking Diensten befallen sein. BenutzerInnen werden dazu verleitet, auf ihrem Smartphone eine Software zu installieren, welche die Sicherheit ihres Online-Bankings vermeintlich erhöhen soll (Jiang und Zhou 2013) Aktivierungs-Methoden Schadsoftware wird auf Android meist durch systemweite Events, durch das Austauschen der Haupt-Aktivität oder durch Eingaben von BenutzerInnen aktiviert. In vielen Fällen

43 3 METHODEN 34 Kategorie Systemstart Telefon Packet Manager SMS USB Batterie Netzwerk Applikation System Events BOOT COMPLETED PHONE STATE NEW OUTGOING CALL PACKAGE ADDED PACKAGE REMOVED PACKAGE CHANGED PACKAGE REPLACED PACKAGE RESTARTED PACKAGE INSTALL SMS RECEIVED WAP PUSH RECEIVED UMS CONNECTED UMS DISCONNECTED ACTION POWER CONNECTED ACTION POWER DISCONNECTED BATTERY LOW BATTERY OKAY BATTERY CHANGED ACTION CONNECTIVITY CHANGE PICK WIFI WORK ACTION MAIN USER PRESENT INPUT METHOD CHANGED SIG STR SIM FULL Tabelle 4: Auszug von Android Broadcast Events (Zhou und Jiang 2012) nutzt Schadsoftware unter Android Broadcast Receiver (siehe 2.3.1), um den schädlichen Code im richtigen Moment ausführen zu können. In Tabelle 4 wurden einige der laut (Zhou und Jiang 2012) am meisten dafür genutzten Events aufgelistet. Unter allen vorhandenen System-Events, ist BOOT_COMPLETED das wohl Interessanteste für Schadsoftware. Das ist wenig überraschend, da der Zeitpunkt, an dem das Android System den Startvorgang abgeschlossen hat, ein idealer Zeitpunkt ist, um schädliche Hintergrunddienste zu aktivieren. Durch das Hören auf solche Events kann Schadsoftware das Android Broadcast-System ausnutzen, um ohne die Interaktion von BenutzerInnen den Schadcode zum idealen Zeitpunkt auszuführen. Im Datensatz des Android Malware Genome Project befinden sich 29 von 49 Schadsoftware-Familien (oder 83,3% aller Samples), die auf das BOOT_COMPLETED Event hören. An zweiter Stelle kommt das SMS_RECEIVED Event mit 21 von 49 Schadsoftware-Familien, die darauf hören. Dieses Event wird vom Android System verbreitet, wenn eine neue SMS-Nachricht empfangen wurde. Schadsoftware ist damit in der Lage SMS-Nachrichten abzufangen, bevor sie dem oder der BenutzerIn angezeigt

44 3 METHODEN 35 werden, die SMS-Nachrichten zu löschen oder auch automatisch auf diese zu antworten. So wird Schadsoftware oftmals dazu genutzt, BenutzerInnen ohne deren Wissen bei Mehrwert-SMS-Diensten anzumelden (Zhou und Jiang 2012). Mit Android 4.2 wurde ein Feature eingeführt, das Trojanern, die im Hintergrund Mehrwert SMS-Nachrichten versenden, entgegenwirken soll. BenutzerInnen wird immer dann ein Bestätigungs-Dialog angezeigt, wenn eine Applikation versucht, eine SMS-Nachricht an einen Mehrwert-Dienst zu senden. BenutzerInnen können dadurch selbst entscheiden, ob sie dieses Verhalten zulassen oder blockieren wollen (Google 2014e). Es wurde auch beobachtet, dass einige Schadsoftware-Familien, beispielsweise DroidDream, die Haupt-Aktivität einer Applikation austauschen. Diese wird immer ausgeführt, wenn BenutzerInnen eine Applikation über deren Icon am Startbildschirm starten. Dadurch wird es der Schadsoftware ermöglicht, ihren schädlichen Code, noch bevor die eigentliche Applikation gestartet wird, auszuführen. Schädliches Verhalten kann außerdem durch Eingaben von BenutzerInnen ausgelöst werden. Ein Beispiel hierfür ist eine Schadsoftware- Familie namens Zsone. Diese erweitert beispielsweise den onclick()-callback von GUI Elementen dahingehend, dass bei jedem Klick eine SMS-Nachricht gesendet wird (Zhou und Jiang 2012) Distribution Android BenutzerInnen können eine Vielzahl von Applikationen von Drittanbietern installieren. Diese beziehen sie meistens entweder aus dem offiziellen Google Play Store oder von einem der alternativen Marktplätze. Um Applikationen aus einem alternativen Marktplatz zu installieren, müssen BenutzerInnen in den Android Einstellungen die Option Unbekannte Herkunft aktivieren und mit den damit verbundenen Risiken einverstanden sein. Ist diese Option aktiviert, sind BenutzerInnen in der Lage, APKs direkt zu installieren oder einen Marktplatz eines Drittanbieters zu nutzen. Im Gegensatz zum offiziellen Google Play Store, der versucht, seine BenutzerInnen durch eine Software namens Bouncer vor Schadsoftware zu schützen (siehe 2.4.5), verfügen alternative Marktplätze oftmals über keine solchen Schutzmaßnahmen. Laut (Juniper 2013) gibt es mehr als 500 alternative Marktplätze für Android Applikationen, die von Schadsoftware befallen sind. Diese Marktplätze von Drittanbietern können oftmals nur schwer zur Verantwortung gezogen werden, wodurch sich Schadsoftware dort sehr lange halten und zum Download angeboten werden kann. Das Mobile Thread Center von Juniper Networks zeigt außerdem, dass sich drei von fünf dieser alternativen Marktplätze in China und Russland befinden. In einer Studie, die 2012 von (Zhou, Wang u. a. 2012) durchgeführt wurde und den Google Play Store, sowie vier alternative Marktplätze umfasste, wurden im Falle des Google Play Stores eine Infektionsrate von 0,02% festgestellt, bei den alternativen Marktplätzen reichte die Infektionsrate bereits von 0,2% bis 0,47%. Dementsprechend war die Infektionsrate in alternativen Marktplätzen um mehr als eine Größenordnung höher, als im offiziellen Google Play Store. Grund dafür ist laut den AutorInnen, dass Schadsoftware, die aus dem

45 3 METHODEN 36 Google Play Store bereits entfernt wurde, oftmals noch Monate später in alternativen Marktplätzen zu finden ist. Ein Beispiel hierfür ist die Schadsoftware DroidDream, welche im März 2011 innerhalb von 48 Stunden rund Android Endgeräte infizierte, bevor Google die Schadsoftware aus dem offiziellen Marktplatz entfernte. Diese war allerdings auch drei Monate später noch in alternativen Marktplätzen auffindbar. In einer weiteren Studie zeigten (Zhou, Zhou u. a. 2012), dass 5% bis 13% aller Applikationen in sechs untersuchen alternativen Marktplätzen repackaged (siehe Kapitel 3.1.2) waren. Dabei werden meist legitime Applikationen aus dem offiziellen Google Play Store genommen, modifiziert und in alternativen Marktplätzen veröffentlicht. Abbildung 10: Android Versionen im Umlauf (Quelle: Abbildung 10 zeigt die Verteilung von Android Versionen am 9. September Versionen, die von weniger als 0,1% der EndbenutzerInnen verwendet werden, sowie alle Versionen unter 2.2 Froyo wurden nicht berücksichtigt. Zu sehen ist, dass es immer noch viele BenutzerInnen gibt, denen wichtige Sicherheits- Features, wie der Warn-Dialog beim Versenden von Mehrwert SMS-Nachrichten ab Version 4.2 oder SELinux ab Version 4.3, nicht zur Verfügung stehen Datensätze Die im Zuge dieser Arbeit verwendeten Android Schadsoftware Samples stammen aus dem Android Malware Genome Project (Zhou und Jiang 2012) sowie von Contagio Mobile 2. Das Android Malware Genome Project entstand im Zuge der Arbeit von Zhou and Jiang und beinhaltet 1260 Schadsoftware Samples, die in 49 Familien eingeteilt werden können. Dieser Datensatz wurde zwischen August 2010 und Oktober 2011 aufgebaut. Contagio Mobile bietet eine Dropbox, von welcher Forscher Schadsoftware Samples beziehen oder 2.

46 3 METHODEN 37 hochladen können. Diese Datenbank beinhaltet rund 380 Schadsoftware Samples, die zwischen September 2012 und September 2014 gesammelt wurden. Als weitere, und weit umfangreichere Quelle, die allerdings für diese Arbeit nicht Verwendung fand, könnte VirusTotal herangezogen werden. Bei VirusTotal, einer Tochtergesellschaft von Google, handelt es sich um einen Dienst zum Erkennen von Schadsoftware. Sampels, die an VirusTotal übermittelt werden, können von mehr als 50 verschiedenen Virenscannern untersucht werden. Durch Nutzung der privaten API 3 ist es möglich, als Schadsoftware erkannte Samples durch Angabe eines Hashes herunterzuladen. 3.2 Erkennung von Schadsoftware Um Android Schadsoftware effizient erkennen zu können, wird von kommerziellen Anti- Malware Systemen meist auf die Erkennung von bestimmten Mustern, sogenannten Signaturen, gesetzt. Diese Signaturen enthalten charakteristische Muster, die eine Schadsoftware eindeutig identifizieren sollen. Um diese Signaturen erstellen zu können, werden bekannte Android Schadsoftware Samples meist einer statischen Codeanalyse oder einer dynamischen Verhaltensanalyse unterzogen. Da beide Verfahren Vor- und Nachteile aufweisen, wird oftmals eine Kombination aus beiden Verfahren eingesetzt. Besonders die dynamische Analyse kann hierbei von einer vorangegangenen statischen Analyse profitieren. In den folgenden Unterkapiteln wird näher auf die statische Analyse und deren Probleme durch Quelltext-Verschleierung, auf die dynamische Verhaltensanalyse und Möglichkeiten eine solche Analyse zu erkennen, sowie auf kombinierte Verfahren eingegangen. Außerdem werden jeweils bestehende Arbeiten, beziehungsweise Frameworks, vorgestellt Statische Analyse Bei der statischen Analyse wird eine Applikation analysiert, ohne diese tatsächlich auszuführen. Werkzeuge, die dafür verwendet werden, reichen von Dis-Assemblern, De-Compilern und komplexen Quellcode-Analyse-Programmen bis hin zu einfachen Werkzeugen wie beispielsweise grep. Der Vorteil von statischer Analyse liegt darin, dass sie den gesamten Quellcode abdeckt. Sie kann so auch zeigen, wie sich Applikationen unter ungewöhnlichen Bedingungen verhalten, da auch Teile des Quellcodes analysiert werden, die unter normalen Umständen niemals ausgeführt würden. Statische Analyse alleine kann allerdings nur ein ungefähres Bild liefern. Es ist damit nicht möglich, jedes Verhalten einer Applikation vollständig vorherzusagen (Farmer und Venema 2004). Auch wenn die Werkzeuge für statische Analyse stetig weiterentwickelt werden, gibt es laut (Moser, Kruegel und Kirda 2007) ein fundamentales Limit, welcher Code noch untersucht werden kann und welcher nicht. Dieses Limit ergibt sich laut (Anderson 2008) dadurch, dass auch bei der statischen Analyse oft nur in der Theorie alle Zustände und 3.

47 3 METHODEN 38 Ausführungs-Pfade simuliert werden können. Wenn eine Methode, die keinerlei Schleifen enthält, n Zustände aufweist, von denen es mehrere mögliche Übergänge in verschiedene Folge-Zustände gibt, müssten bereits bis zu 2 n Ausführungs-Pfade berücksichtigt werden. In der Praxis sind es weniger, da sich viele Pfade überschneiden. Wenn in dieser Methode andere Methoden-Aufrufe und deren mögliche Rückgabelwerte berücksichtigt werden, ist die Anzahl der möglichen Ausführungs-Pfade laut (Anderson 2008) bereits doppelt exponentiell. Werden auch noch Schleifen berücksichtigt, kann es unendlich viele mögliche Ausführungs-Pfade geben. Da es nicht möglich ist, so viele Pfade zu untersuchen, werden diese normalerweise limitiert. Schleifen werden beispielsweise nur eine bestimmte fixe Anzahl von Durchläufen untersucht oder beim Analysieren einer Methode wird ein oberes Limit von zu analysierenden Ausführungs-Pfaden gesetzt. Wurde der Quellcode zu stark durch Verschleierungs-Techniken modifiziert, stößt statische Analyse schnell an ihre Grenzen, da es eben zu viele mögliche Ausführungs-Pfade gibt. Diese Grenzen sind von geringer Tragweite, wenn es um das Finden von Programmierfehlern geht, wofür statische Analyse normalerweise eingesetzt wird. Kommt es allerdings zu Schadsoftware, deren Quellcode absichtlich so konstruiert wurde, dass er einer statischen Analyse widersteht, stellt dass ein Problem dar. Aus diesem Grund kann statische Analyse alleine nicht sicherstellen, das Schadsoftware zuverlässig identifiziert wird. Statische Analyse sollte deshalb laut (Moser, Kruegel und Kirda 2007) durch dynamische Analyse ergänzt werden, da diese deutlich weniger anfällig für Quelltext-Verschleierungen und -Transformationen ist. Quellcode-Verschleierung Die Code Obfuscation oder Quellcode Verschleierung ist eine Technik, die es erschweren soll, Applikationen zu verstehen. Dafür wird eine neue, modifizierte Version einer Applikation generiert, die sich funktionell nicht unterscheidet. Ursprünglich wurden diese Techniken entwickelt, um das geistige Eigentum von Software-EntwicklerInnen zu schützen. Diese werden allerdings auch von EntwicklerInnen von Schadsoftware genutzt, um schädlichen Code so zu verstecken, dass er nicht erkannt werden kann (You und Yim 2010). Verschleierung kann auf verschiedenen Ebenen stattfinden, beispielsweise auf Ebene des Quellcodes oder auf der des kompilierten Maschinencodes. Einige Verschleierungs-Techniken, sind laut (Moser, Kruegel und Kirda 2007) folgende: Verschleierung von Konstanten: Konstanten sind allgegenwärtig in der Programmierung. Im einfachsten Fall werden sie in ein Register geladen. Diese Ladeoperation kann durch eine Abfolge von Instruktionen, die semantisch äquivalent aber schwerer zu analysieren sind, ersetzt werden. Beispielsweise können Konstanten kompliziert berechnet werden, anstatt sie einfach zuzuweisen. Verschleierung der Kontrollstruktur: Eine Grundvoraussetzung, um fortgeschrittene statische Analysen durchzuführen, ist die Erstellung von Kontrollstruktur- Graphen. Ein Kontrollstruktur-Graph oder Control Flow Graph ist ein gerichteter

48 3 METHODEN 39 Graph G = (V, E), dessen Knoten u, v V Blöcke repräsentieren, während die Kanten e E : u v einen möglichen Kontrollfluss von u nach v darstellen. Ein Block besteht hierbei aus einer Sequenz von Instruktionen ohne Sprunganweisungen. JMPund CALL-Instruktionen stellen Kanten dar. Die Idee hinter der Verschleierung von Kontrollstrukturen ist, diese Sprunganweisungen durch andere Instruktionen zu ersetzen, so dass der Kontrollfluss nicht beeinflusst wird, es allerdings schwierig ist, die jeweiligen Ziele durch statische Analyse herauszufinden. Dafür kann die Verschleierung von Konstanten, in diesem Fall einer Speicheradresse, eingesetzt werden. Verschleierung von Daten: Der Speicherort von Daten wird oftmals durch Konstanten oder mittels konstanter Offsets relativ zu einem bestimmten Register festgelegt. In beiden Fällen kann wiederum der genaue Speicherort oder der Zugriff auf bestimmte Daten durch die Nutzung verschleierter Konstanten versteckt werden. Techniken zur Mutation von Schadsoftware Auf Ebene des Maschinencodes, gibt es laut (You und Yim 2010) verschiedene einfache Techniken, um neue Mutationen oder Varianten von Schadsoftware zu erstellen. Dadurch soll deren Auffindbarkeit durch Signaturen erschwert werden. Einfügen von totem Code: Das Einfügen von totem Maschinencode, der nicht ausgeführt wird, ist eine einfache Technik, um das Erscheinungsbild einer Applikation zu verändern, ihre Funktionalität allerdings unverändert zu lassen. Ein Beispiel hierfür wäre das willkürliche Einfügen des NOP Kommandos (NOP steht für No Operation und hat keine Auswirkung auf den Programmablauf). Eine auf Signaturen basierende Erkennung ist möglich, wenn vor der Analyse ineffektive Befehle entfernt werden. Neuzuordnung von Registern: Eine weitere Technik ist das Vertauschen von Registern. Von Generation zu Generation werden Register zufällig vertauscht, ohne das Verhalten der Applikation zu verändern. Dieser Technik kann durch die Nutzung von Wildcards in den Signaturen gut entgegengewirkt werden. Umsortieren von Subroutinen: Auch durch das zufällige Umsortieren von Subroutinen können neue Schadsoftware Generationen entstehen. Einzelne Subroutinen können allerdings immer noch durch Signaturen erkannt werden. Substitution von Instruktionen: Bei der Substitution von Instruktionen werden Instruktionen durch gleichwertige ersetzt. So kann zum Beispiel ein XOR durch SUB oder MOV durch PUSH/POP ersetzt werden. Auch dieser Technik kann durch die Nutzung von Wildcards in den Signaturen entgegengewirkt werden. Transposition von Code: Bei der Transposition von Maschinencode werden Instruktionen zufällig umsortiert, während das Verhalten der Applikation erhalten bleibt. Das kann auf zwei Arten bewerkstelligt werden. Entweder werden JMP Instruktionen benutzt, um die Ausführungsreihenfolge zu erhalten oder es werden nur

49 3 METHODEN 40 Blöcke mit Instruktionen, die keinen Einfluss auf andere Instruktionen haben, verschoben. Diese zu finden ist allerdings aufwendig. (Automatische) Mutation von Schadsoftware Um die Erkennung zu erschweren, kann fortgeschrittene Schadsoftware selbst mutieren. Laut (Ször und Ferrie 2001) können vier verschiedene Arten von Mutation unterschieden werden, wobei jede Stufe eine größere Herausforderung darstellt, um sie zu identifizieren: 1. Verschlüsselt: Bei der ersten Variante wird Verschlüsselung eingesetzt, um einer Erkennung zu entgehen. Dafür besteht verschlüsselte Schadsoftware aus einem Verschlüsselungsmodul und dem verschlüsselten Hauptteil. Das Verschlüsselungsmodul entschlüsselt den Hauptteil immer dann, wenn die infizierte Applikation ausgeführt wird. Da bei jeder Infektion ein zufälliger Schlüssel verwendet wird, ist der verschlüsselte Hauptteil der Applikation einzigartig und kann nur schwer durch Signaturen erkannt werden. Die Erkennung solcher Schadsoftware ist allerdings möglich, ohne den verschlüsselten Hauptteil zu untersuchen. In den meisten Fällen ist das Verschlüsselungsmodul einzigartig genug, um erkannt zu werden. 2. Oligomorph: Bei oligomorpher Schadsoftware mutiert auch das Verschlüsselungsmodul von einer Generation zur nächsten. Die Anzahl von mögliche Mutationen ist allerdings begrenzt, wodurch auch oligomorphe Schadsoftware durch Signaturen erkannt werden kann. 3. Polymorph: Polymorphe Schadsoftware kann, mit Hilfe von Mutations-Techniken, eine theoretisch endlose Anzahl von neuen Verschlüsselungsmodulen erzeugen, die wiederum verschiedene Methoden zum Entschlüsseln des Hauptteiles unterstützen können. Identifiziert werden kann eine solche Schadsoftware in manchen Fällen durch unzulänglich generierte Zufallszahlen in der Mutations-Engine. Anderenfalls kann polymorphe Schadsoftware nur durch dynamische Analyse erkannt werden. 4. Metamorph: Metamorphe Schadsoftware verzichtet auf ein Verschlüsselungsmodul. Stattdessen werden wiederum Mutations-Techniken eingesetzt, woraufhin sich die Schadsoftware selbst neu kompiliert, um eine neue Generation zu erzeugen. Da dadurch jedes Mal eine komplett neue Applikation entsteht, kann diese auch meist nur durch dynamische Verhaltensanalyse erkannt werden. Für Android ist diese Art von Schadsoftware allerdings weitgehend uninteressant, da für die Generierung neuer Generationen auf dem infizierten System eine Umgebung zum Kompilieren von Applikationen vorhanden sein muss. Vor- und Nachteile von statischer Analyse + Deckt den gesamten Quellcode ab. + Es wird auch Code berücksichtigt, der unter normalen Umständen nicht ausgeführt würde.

50 3 METHODEN 41 + Im Gegensatz zur dynamischen Analyse sehr schnell (wenn automatisiert). + Verfahren zur Erkennung von dynamischer Analyse können erkannt werden. Es besteht ein fundamentales Limit bei der Anzahl von Ausführungs-Pfaden, die berücksichtigt werden können. Quellcode Verschleierung und Mutation von Software können die Anzahl von möglichen Ausführungs-Pfaden enorm erhöhen. Bisherige Arbeiten Trotz der Probleme, die statische Analyse mit sich bringen kann, wurde in den vergangenen Jahren durchaus erfolgreiche Forschung in diese Richtung betrieben: ReadElf: Im Jahr 2009 versuchten (Schmidt u. a. 2009) mit Hilfe des readelf Werkzeugs, Funktionsaufrufe von Android Applikationen zu extrahieren. Die extrahierten Funktionsaufrufe wurden anschließend mittels PART, Prism und Nearest Neighbor Algorithmen analysiert und mit bekannter Schadsoftware verglichen. SOM: Im Jahr 2010 präsentierten (Barrera u. a. 2010) eine empirische Analyse des Android Berechtigungs-Systems mit Hilfe von SOM. Dazu wurden 1100 Applikationen untersucht. Mit Hilfe des SOM Algorithmus wurde gezeigt, wie bestimmte Berechtigungen von EntwicklerInnen genutzt werden. Es wurde herausgefunden, dass Android zwar über eine große Anzahl von verschiedenen Berechtigungen verfügt, allerdings nur eine geringe Anzahl davon wirklich aktiv von EntwicklerInnen genutzt wird. Es wurden dabei Berechtigungen entdeckt, die sehr weitläufig sind und so eine große Anzahl an Features abdecken. Andere Berechtigungen sind wiederum nur für ein bestimmtes Feature verantwortlich. Die durchgeführte empirische Analyse sollte eine Basis für mögliche Verbesserungen beim Android Berechtigungs-System liefern. DED: Im Jahr 2011 stellte (Enck u. a. 2011) den DED De-Compiler vor. Dabei handelt es sich um einen Dalvik De-Compiler, der in der Lage ist, Java Quellcode aus einer APK Installationsdatei zu rekonstruieren. Dies geschieht, indem Dalvik Bytecode in Java Bytecode umgewandelt wird und anschließend verlorene Datentypen sowie Klassen und Methoden wiederhergestellt werden. Laut der AutorInnen existierte vor DED kein Werkzeug, das mit Dalvik Bytecode arbeiten konnte. Aufgrund des großen Unterschiedes zwischen Java Bytecode und Dalvik Bytecode war es nicht möglich, existierende Werkzeuge anzupassen. Mit Hilfe des entwickelten DED De- Compilers wurde eine Studie mit 1100 verbreiteten Android Applikationen durchgeführt. Es wurde festgestellt, dass sensible Informationen, besonders Identifizierungs- Merkmale von Endgeräten wie International Mobile Equipment Identity (IMEI) oder International Mobile Subscriber Identity (IMSI) und Positionsdaten missbraucht wurden. Schadsoftware konnte dabei keine identifiziert werden. Allerdings wurde gezeigt, dass bei der Entwicklung von Android Applikationen von EntwicklerInnen

51 3 METHODEN 42 wenig auf die sichere Verwendung von APIs und somit auf den Schutz sensibler Daten geachtet wird. Auch enthielten 51% der analysierten Applikationen Bibliotheken von Werbe- oder Analysenetzwerken. Viele Applikationen enthielten sogar mehr als eine Werbebibliothek. Androguard: Im selben Jahr wurde Androguard als Framework für statische Analyse vorgestellt. Dabei wird mit Hilfe von DED aus Android Applikationen Java Quellcode generiert. Unter anderem ist es mit Androguard möglich, Schadsoftware mit Hilfe von Signaturen zu identifizieren, die Ähnlichkeit zweier Anwendungen zu berechnen um Repackaging zu erkennen, und eine Vielzahl von Informationen aus einer Applikation auszulesen, beispielsweise welche Komponenten sie enthält. Aufgrund seiner Flexibilität wird Androguard bei vielen, auch dynamischen, Analyse- Frameworks als Basis verwendet (Desnos und Gueguen 2011). RiskRanker: Im Jahr 2012 schlugen (Grace u. a. 2012) ein Framework namens RiskRanker vor. Mit dessen Hilfe soll es möglich sein, zero-day Schadsoftware ausfindig zu machen. Das automatisierte System ist in der Lage zu erkennen, ob eine Applikation gefährliche Verhaltensmuster aufweist. Beispiele hierfür sind die Anwendung von Root-Exploits oder das Versenden von Mehrwert SMS-Nachrichten im Hintergrund. Mit Hilfe der gesammelten Daten wird anschließend eine priorisierte Liste von Applikationen erstellt, die einer genaueren Untersuchung bedürfen. In der durchgeführten Studie wurden insgesamt Applikationen aus verschiedenen Marktplätzen untersucht. Das System fand darunter 3281 Applikationen, die als gefährlich eingestuft wurden. Diese 3281 Applikationen enthielten 718 bekannte Schadsoftware Samples aus 29 Schadsoftware-Familien, wovon es sich bei 322 um zero-day Schadsoftware (11 Familien) handelte Dynamische Analyse Bei der dynamischen Analyse oder auch Verhaltensanalyse wird eine Applikation während deren Ausführung überwacht, beziehungsweise analysiert. Werkzeuge, die dafür Verwendung finden, sind Debugger, Tracer, Emulatoren und Netzwerk Sniffer. Der Vorteil von dynamischer gegenüber statischer Analyse ist, dass verschleierter Code keine Probleme macht, da nicht der Quellcode direkt analysiert wird, sondern das Verhalten der Applikation. Nachteile sind die im Vergleich zur statischen Analyse oftmals langen Ausführungszeiten und dass nicht immer alle Pfade erreicht werden. Es werden dabei nur diejenigen Pfade analysiert, die auch tatsächlich ausgeführt werden. Da es bei komplexen Applikationen nur schwer möglich ist, alle vorhandenen Pfade zur Ausführung zu bringen, ist auch die dynamische Analyse nicht zu 100% zuverlässig (Farmer und Venema 2004). Aus diesem Grund wird oftmals vor der dynamischen Analyse einer Android Applikation eine statische Analyse durchgeführt, um beispielsweise alle vorhandenen Komponenten im Vorfeld zu kennen. Da jede Komponente unter Android einen Einstiegspunkt in die Applikation darstellt, kann in der dynamischen Analyse so zum Beispiel versucht wer-

52 3 METHODEN 43 den, jede Komponente einzeln auszuführen, um eine größere Abdeckung der möglichen Ausführungspfade zu erreichen. Neben der Tatsache, dass es nur schwer möglich ist, bei komplexeren Applikationen alle Ausführungspfade abzudecken, wird dies laut (Paleari u. a. 2009) im Fall von Schadsoftware oftmals zusätzlich erschwert. Umso länger es dauert, neue Schadsoftware zu identifizieren, umso länger überlebt sie (zum Beispiel im offiziellen Google Play Store) und umso mehr Endgeräte können befallen werden. Da sich AutorInnen von Schadsoftware darüber im Klaren sind, dass diese einer dynamischen Analyse, im Falle vom Google Play Store durch ein Framework namens Bouncer, unterzogen wird, versuchen sie durch Tests festzustellen, ob die Applikation auf einem echten Endgerät oder in einem Emulator, einer Virtuellen Maschine oder einem Debugger ausgeführt wird. Wenn ein solcher Test ergibt, dass die Applikation in einer solchen Umgebung läuft, wird versucht, das schädliche Verhalten zu verbergen. Hypervisoren und Emulatoren Unter einem Hypervisor (auch Virtual Machine Monitor (VMM) genannt) oder einem Emulator werden Programme verstanden, die Hardware simulieren können. In dieser simulierten Umgebung können ganze Betriebssysteme so ausgeführt werden, als ob sie auf echter Hardware laufen würden (Raffetseder, Kruegel und Kirda 2007). In (Popek und Goldberg 1974) werden VMs als ein effizientes, isoliertes Duplikat einer echten Maschine beschrieben. Außerdem muss ein VMM folgende Charakteristiken erfüllen: Der VMM stellt Programmen eine Umgebung zur Verfügung, die außer der Verfügbarkeit von System-Ressourcen der einer echten Maschine gleicht. Programme, die in einer solchen Umgebung ausgeführt werden, zeigen höchstens einen geringen Geschwindigkeitsunterschied. Ein signifikanter Anteil von Instruktionen muss dafür auf der echten Hardware ausgeführt werden. Der VMM behält die komplette Kontrolle über die System-Ressourcen. Programme, die in einer VM ausgeführt werden können nur auf Ressourcen zugreifen, die ihnen explizit zugewiesen wurden. Der zweite Punkt unterscheidet einen VMM von einem Emulator. Emulatoren führen keinen Code direkt auf der Hardware aus, wodurch es oft zu großen Geschwindigkeitseinbußen kommt. Ein Emulator simuliert das Verhalten der CPU mit Hilfe von Software. Alle Instruktionen werden vom Emulator abgefangen, für die Ziel Plattform übersetzt und erst dann auf der Hardware ausgeführt. Ein Emulator ist deshalb, im Gegensatz zu einem VMM, in der Lage, auch Software, die für eine andere Prozessor-Architektur als die des Host-Computers kompiliert wurde, auszuführen (Raffetseder, Kruegel und Kirda 2007).

53 3 METHODEN 44 Erkennung von virtuellen Umgebungen Wie bereits zuvor beschrieben, sind laut (Raffetseder, Kruegel und Kirda 2007) EntwicklerInnen in der Lage zu erkennen, ob ihre Software in einem Emulator oder einer VM ausgeführt wird. Dafür gibt es verschiedene Möglichkeiten, unter anderem folgende: Unterschiede im Verhalten: Die Ausführung einer Applikation auf echter Hardware und in einer virtuellen Umgebung sollte zum selben Ergebnis führen, um eine perfekte Emulation zu gewährleisten. Gibt es Unterschiede, kann ein Emulator erkannt werden. Besonderes Augenmerk wird hierbei auf Fehler von CPUs und modellspezifische Register gelegt. Moderne CPUs sind sehr komplex, wodurch jede Prozessor-Familie Fehler enthält. Durch das Vorhandensein oder Fehlen von bestimmten Fehlern kann eine CPU eindeutig erkannt werden. Unterschiede im Timing: Die Performance einer Applikation, die in einer virtuellen Umgebung ausgeführt wird, ist immer geringer als wenn sie auf echter Hardware ausgeführt würde. Zu messen, ob die absolute Performance einer bestimmten Applikation zur verwendeten CPU passt, um Virtualisierung festzustellen, ist allerdings sehr fehleranfällig. Stattdessen wird die relative Performance zwischen zwei Instruktionen gemessen. Werden die beteiligten Instruktionen richtig gewählt, kann wiederum eine bestimmte CPU Familie oder eben ein VMM beziehungsweise Emulator erkannt werden. Spezifische Hardware: In einer simulierten Umgebung müssen alle peripheren Geräte, beispielsweise Grafikkarten oder Festplatten, emuliert werden. Bestimmte Emulatoren implementieren diese virtuellen Geräte auf eine charakteristische Art und Weise, die erkannt werden kann. Um solche hardwarespezifischen Unterschiede (sogenannte red-pills) zu finden, die eine CPU oder einen Emulator eindeutig identifizieren können, wurde von (Paleari u. a. 2009) eine systematische Technik vorgeschlagen. Damit war es den ForscherInnen möglich, tausende dieser red-pills für zwei weit verbreitete Emulatoren, QEMU 4 und BOCHS 5, zu generieren. Laut der AutorInnen lässt sich diese Technik auch einfach auf andere virtuelle Umgebungen, beispielsweise die von VirtualBox 6 oder VMware 7 anwenden. Für QEMU, wobei es sich um den Standart-Emulator von Android handelt, der mit jedem SDK ausgeliefert wird und auch in Bouncer Verwendung findet, konnten solcher eindeutigen red-pills identifiziert werden. Ob solche red-pills in Schadsoftware zum Einsatz kommen, kann oftmals nur durch statische Analyse erkannt werden

54 3 METHODEN 45 Vor- und Nachteile von dynamischer Analyse + Dynamische Analyse ist resistent gegen Quellcode-Verschleierung. + Dynamische Analyse berücksichtigt auch Code, der beispielsweise aus dem Internet nachgeladen wird. Dynamische Analyse ist meist ressourcenintensiver als statische Analyse. Dynamische Analyse kann erkannt werden. Es wird eine isolierte Sandbox benötigt, deren Ausgangszustand exakt wiederherstellbar ist. Die zu analysierende Applikation muss ausgeführt werden, was sehr zeitintensiv sein kann, um eine gute Codeabdekung zu erreichen. Es ist nur schwer möglich, den gesamten Code abzudecken. Bisherige Arbeiten Vor allem im Bereich der dynamischen Verhaltens-Analyse von Android Applikationen wurde in den vergangenen Jahren geforscht, woraus einige Analyse Frameworks hervorgegangen sind: TaintDroid: Im Jahr 2010 präsentierten (Enck u. a. 2010) TaintDroid. Dabei handelte es sich ursprünglich um eine modifizierte Android 2.1 Version. TaintDroid steht mittlerweile außerdem für die Versionen 2.3, 4.1 und 4.3 von Android zur Verfügung 8 und wird in vielen dynamischen Analyse Frameworks eingesetzt. Es existierte allerdings zum Zeitpunkt des Schreibens dieser Arbeit noch kein Release für das aktuelle Android 4.4 (KitKat). Das Ziel von TaintDroid ist es, den Fluss von sensiblen Daten durch nicht vertrauenswürdige Applikationen zur Laufzeit zu verfolgen und dabei privacy leaks zu erkennen. Da TaintDroid in der Dalvik VM implementiert wurde, ist es damit nicht möglich, nativen Code zu überwachen. CrowDroid: Im Jahr 2011 veröffentlichten (Burguera, Zurutuza und Nadjm-Tehrani 2011) eine Crowdsourcing Applikation namens CrowDroid. Dabei handelt es sich um eine Anwendung, die mittels strace 9 Systemaufrufe von installierten Applikationen zur Laufzeit aufzeichnet. Diese wurden anschließend zur Analyse an einen zentralen Server gesendet, welcher mittels ML Techniken entschied, ob die ausgeführte Applikation gut- oder bösartig ist

55 3 METHODEN 46 DroidBox: Im selben Jahr wurde (Lantz 2014) DroidBox 10 präsentiert. Dieses Framework wurde als Teil des Google Summer of Code (GSoC) 2011 entwickelt. DroidBox verbindet TaintDroid mit einigen Modifikationen der Android System- Bibliotheken (siehe Kapitel 2.2.2). Es werden zusätzlich das Lesen und Schreiben von Dateien, Aktivitäten der Kryptographie API, Netzwerkverbindungen sowie Netzwerkverkehr und das Versenden von SMS-Nachrichten sowie Telefonanrufe überwacht. DroidScope: Im Jahr 2012 schlugen (Yan und Yin 2012) ein Framework namens DroidScope vor. Sie modifizierten QEMU, sowie die Dalvik VM dahingehend, dass detaillierte native und Dalvik Instruction Traces aufgezeichnet wurden. Außerdem wurden Android API Aufrufe und, ähnlich wie unter TaintDroid, privacy leaks überwacht. CopperDroid: Im Jahr 2013 wurde von (Reina, Fattori und Cavallaro 2013) CopperDroid veröffentlicht. Auch dieses Framework verwendet QEMU als Emulator. Dieser wurde wie bei DroidScope so modifiziert, dass Systemaufrufe aufgezeichnet werden. Der Fokus dieser Arbeit lag allerdings nicht darauf, ein Framework zu entwickeln, sondern zu zeigen, wie durch eine Analyse auf Basis von Systemaufrufen Schadsoftware identifiziert werden kann Kombinierte Analyse Wie bereits in Kapitel und Kapitel beschrieben wurde, ist es sinnvoll, statische Analyse in Kombination mit einer dynamischen Verhaltensanalyse einzusetzen. Bei der statischen Analyse können beispielsweise Informationen gesammelt werden, die hilfreich sind, um bei der nachfolgenden dynamischen Analyse eine möglichst gute Codeabdeckung zu erreichen. Viele dynamische Analyse Frameworks machen deshalb Gebrauch von einer vorangegangenen statischen Analyse, darunter: AASandbox: Im Jahr 2010 erschien das erste dynamische Analyse Framework namens AASandbox (Blasing u. a. 2010). Das Framework führt zuerst eine statische Analyse durch, um nach verdächtigen Mustern zu suchen. Danach wird die zu untersuchende Applikation in einer isolierten Umgebung (Sandbox) ausgeführt, um Systemaufrufe mit Hilfe eines Kernel-Moduls aufzuzeichnen, die später analysiert werden. Die AASandbox und der dazugehörige Erkennungs-Algorithmus wurden so implementiert, dass sie in der Cloud ausgeführt werden können. Leider existierten zu dieser Zeit keine umfangreichen Android Schadsoftware Datensätze, weshalb nur mit den damaligen Top 150 Applikationen aus dem Google Play Store und einem selbst entwickelten Fork-Bomb Sample experimentiert wurde

56 3 METHODEN 47 Structured Control Flow: Im selben Jahr veröffentlichten (Cesare und Xiang 2010) ein Framework, das mit Hilfe von Kontrollstrukturen Schadsoftware erkennen sollte. Dafür wurde zuerst durch eine Entropie-Analyse festgestellt, ob es sich um gepackte Schadsoftware handelt. Unter gepackt wird in diesem Zusammenhang verstanden, dass der Schadcode in komprimierter oder verschlüsselter Form vorliegt und erst zur Laufzeit wiederhergestellt wird (siehe Kapitel 3.2.1). Handelt es sich um gepackte Schadsoftware, wird diese dynamisch ausgeführt, um versteckten Code aufzudecken. Es werden Kontrollstrukturen extrahiert, die als Signaturen dienen. Diese können mit einer Datenbank bekannter Schadsoftware abgeglichen werden. Um Schadsoftware zu klassifizieren, wird die Bearbeitungs-Distanz zwischen verschiedenen Kontrollstrukturen herangezogen. Auch dieses System wurde nur mit synthetischer Schadsoftware getestet, da zu diesem Zeitpunkt keine umfangreiche Datenbank mit Android Schadsoftware existierte. Andrubis: Im Jahr 2012 wurde Andrubis vom International Secure Systems Lab vorgestellt (Lindorfer 2012). Dabei handelte es sich um eine Erweiterung von Anubis 11 und die erste Analyse Plattform, bei der es BenutzerInnen möglich war, Android Applikationen über ein Web-Interface hochzuladen und analysieren zu lassen. Andrubis generiert nach Abschluss der Analyse einen Report, der die Ergebnisse der statischen und dynamischen Analyse enthält. Das erste Release von Andrubis baute auf DroidBox auf und unterstützte Android 2.1. Andrubis wurde seither stark weiterentwickelt und hat seit 2012 rund Android Applikationen (3500 pro Tag) analysiert (Weichselbaum u. a. 2014). DroidRanger: Im selben Jahr wurde DroidRanger (Zhou, Wang u. a. 2012) vorgestellt. Dabei werden Applikationen aufgrund der in ihrer Manifest-Datei deklarierten Berechtigungen vor-gefiltert, um nur Applikationen genauer zu untersuchen, die Berechtigungen anfordern, welche oftmals von Schadsoftware missbraucht werden. Die übrigen Applikationen werden einer dynamischen Verhaltensanalyse unterzogen, um bereits bekannte Schadsoftware zu identifizieren. Dafür wird ein Kernel-Modul verwendet, das Systemaufrufe aufzeichnet, die in bekannten Android Exploits Verwendung finden. Danach wird noch ein heuristisches Filterungs-Schema angewandt, um zero-day Schadsoftware zu finden. Bei der durchgeführten Analyse von Android Applikationen wurden 211 Schadsoftware Samples gefunden. Durch das heuristische Filtern konnten darin 40 zero-day Samples aus 2 Familien identifiziert werden, 11 davon im offiziellen Google Play Store. AppsPlayground: Im Jahr 2013 veröffentlichten (Rastogi, Chen und Enck 2013) AppsPlayground. Dieses Framework baut auf TaintDroid auf, um privacy leaks zu überwachen. Auch hier werden zusätzlich verschiedene API- und Systemaufrufe aufgezeichnet, während Android mittels QEMU emuliert wird. BenutzerInnen-Eingaben werden durch ein zuvor für jede Applikation definiertes Modell simuliert. Dieses Modell wird im Vorfeld aus Informationen, die aus GUI-Elementen extrahiert werden, 11.

57 3 METHODEN 48 generiert. Damit konnte im Durchschnitt eine 30% höhere Codeabdeckung als durch Zufallseingaben bewirkt werden. Mobile-Sandbox: Im Jahr 2013 wurde die Mobile-Sandbox von (Spreitzenbarth u. a. 2013) veröffentlicht. Sie zeigt starke Ähnlichkeit zu Andrubis, da auch sie auf DroidBox aufbaut und TaintDroid zum Identifizieren von privacy leaks verwendet. Um Systemaufrufe aufzuzeichnen, wurde allerdings nicht der Emulator erweitert, sondern ltrace 12 eingesetzt. 3.3 Automatische Generierung von Input Bei der dynamischen Analyse von Android Applikationen sollte eine möglichst gute Codeabdeckung gewährleistet werden. Dafür können Eingaben manuell von BenutzerInnen erfolgen, wie es zum Beispiel bei CrowDroid der Fall ist. Werden die Daten für die Analyse allerdings nicht durch Crowdsourcing generiert, sondern versucht, eine große Anzahl von Applikationen automatisiert zu analysieren, müssen normalerweise Eingaben und Events automatisch generiert werden. Google stellt für diesen Zweck als Teil des Android SDKs ein Werkzeug namens Monkey zur Verfügung. Monkey ist ein Programm, das im Emulator oder auf einem echten Endgerät ausgeführt werden kann, um pseudo-zufällige Streams von BenutzerInnen-Events zu erzeugen. Diese enthalten unter anderem Klick-, Touch- und Swipe-Events sowie einige System-Events (Google 2014k). Eine bessere Codeabdeckung kann allerdings erzielt werden, wenn diese Events nicht zufällig generiert werden. Wie bereits beschrieben, konnte AppsPlayground eine 30% höhere Codeabdeckung erzielen, indem zuvor GUI-Elemente untersucht wurden, um daraus ein Modell für die Generierung von Eingaben zu erstellen. Da GUI-Elemente unter Android normalerweise in Form von XML-Dateien vorliegen, können diese relativ einfach aus einer APK extrahiert werden. Auch (Amalfitano u. a. 2012) versuchten, Android Applikationen mit Hilfe ihrer entwickelten AndroidRipper Software in einer strukturierten Form auszuführen. AndroidRipper analysiert dafür dynamisch die GUI einer Applikation um passende Event-Sequenzen zu generieren. Es hat sich allerdings gezeigt, dass dieses Verfahren besser dafür geeignet ist, Fehler in Applikationen zu finden als damit eine dynamische Schadsoftware-Analyse durchzuführen. Laut (Elish, Yao und Ryder 2012) wird schädlicher Code ohnehin nur in wenigen Fällen durch GUI-Events zur Ausführung gebracht. Viel öfter verlässt sich Schadsoftware auf System-Events wie zum Beispiel auf die Android Broadcasts

58 3 METHODEN Maschinelles Lernen Unter Maschinellem Lernen (ML) kann das automatische Finden von Mustern in Daten durch Algorithmen verstanden werden. Mit Hilfe dieser Muster ist es beispielsweise möglich, Daten zu klassifizieren (Bishop 2006). Eine formellere Definition von ML durch (Mitchell 1997) lautet folgendermaßen:... A computer program is said to learn from experience E with respect to some class of tasks T and performance measure P, if its performance at tasks in T, as measured by P, improves with experience E... (2) ML wird oftmals mit Data Mining verwechselt, da sich beide Disziplinen stark überschneiden. Im Unterschied zu ML, konzentriert sich das Data Mining allerdings auf das Finden von neuen, zuvor unbekannten Informationen oder Eigenschaften in Daten. Die Anwendungsbereiche von ML sind vielfältig und enthalten im Grunde alle Bereiche, in denen mit hochdimensionalen Daten gearbeitet wird. Zeichenerkennung und Erkennung von Handschrift Gesichtserkennung Geräuscherkennung Verständnis gesprochener Sprache Vorhersage von Börsenkursen Wetter- und Klima-Prognosen Medizin, beispielsweise Genom-Entschlüsselung Verhaltensanalyse Abbildung 11 zeigt handgeschriebene Ziffern. Jede dieser Ziffern entspricht einer 28x28 Pixel großen Bilddatei und kann durch einen Vektor X s = (x s1, x s2,..., x s784 ), der 784 reelle Zahlen enthält, beschrieben werden. Das Ziel ist es, eine Maschine zu bauen, die einen solchen Vektor X s als Eingabe akzeptiert und als Ausgabe eine Zahl 0,..., 9 liefert. Das stellt, aufgrund der großen Variabilität von Handschriften, ein nicht triviales Problem dar. Dieses könnte durch manuell aufgestellte Regeln oder Heuristiken, die auf der Form der Striche basieren, gelöst werden. Bei dieser Herangehensweise würde es allerdings zu einer Vielzahl von Ausnahmen und Grenzfällen kommen, was zu schlechten Resultaten führen würde (Bishop 2006). Bessere Resultate können durch einen ML-Ansatz erzielt werden, bei dem eine große Anzahl von N Zahlen {x 1,..., x N }, genannt Trainings-Set, genutzt wird, um ein adaptives Modell zu generieren. Die Kategorien der einzelnen Ziffern im Trainings-Set sind dabei

59 3 METHODEN 50 Abbildung 11: Handgeschriebene Ziffern (Bishop 2006) bereits bekannt und werden den Ziel-Vektoren T s = (t s1, t s2,..., t s784 ) zugewiesen. Für jedes Ziffern-Bild X s wird dabei ein solcher Ziel-Vektor T s erstellt (Bishop 2006). Das Resultat des ML-Algorithmus kann als Funktion y(x) ausgedrückt werden, welche ein neues Ziffern-Bild X s als Eingabe erwartet und als Ergebnis einen Vektor Y s = (y s1, y s2,..., y s784 ) liefert, der auf dieselbe Art encodiert ist wie die Ziel-Vektoren. Wie die Funktion y(x) genau aussieht, wird während der Trainings-Phase, auch Lern-Phase genannt, auf Basis der Trainings-Daten bestimmt. Nachdem das Modell trainiert wurde, können damit neue Ziffern-Bilder aus einem Test-Set kategorisiert werden. Die Fähigkeit, auch Ziffern-Bilder richtig zu kategorisieren, die von denen aus dem Trainings-Set abweichen, nennt man Generalisierung. Das Trainings-Set enthält normalerweise nur einen Bruchteil aller möglichen Vektoren, wodurch Generalisierung eine wichtige Rolle im ML einnimmt (Bishop 2006). Die Eingabe-Objekte werden typischerweise vor-verarbeitet, um das zu lösende Problem zu vereinfachen. Beim Ziffern-Problem können die Ziffern-Bilder beispielsweise so zugeschnitten und skaliert werden, dass sie eine Box mit fixer Größe ausfüllen. Das alleine kann die Variabilität der einzelnen Ziffern-Klassen bereits enorm reduzieren und so den Rechenaufwand minimieren. Alle Daten aus dem Trainings- und Test-Set müssen allerdings derselben Vorverarbeitung unterzogen werden (Bishop 2006). Überwachtes Lernen Beim überwachten Lernen oder supervised learning ist für alle Daten im Trainings-Set bereits im Vorfeld bekannt, welchem Ziel-Vektor beziehungsweise welcher Kategorie oder Klasse diese entsprechen. Ein Teilgebiet des überwachten Lernens ist die automatische Klassifizierung, bei der zuvor unbekannten Eingabe-Vektoren eine aus einer endlichen Anzahl diskreter Kategorien beziehungsweise Klassen, zugewiesen wird (Bishop 2006). Nicht überwachtes Lernen Im Gegensatz zum überwachten Lernen sind beim nicht überwachten Lernen oder unsupervised learning die Ziel-Vektoren nicht im Vorfeld bekannt. Ziele des nicht überwachten Lernens sind beispielsweise ähnliche, oder gleiche Datensätze zu finden (Clustering), herauszufinden, wie sich die Daten verteilen (Density Estimation) oder das Projizieren von hochdimensionalen Daten hinunter in die zweite oder dritte Dimension, um sie zu visualisieren (Bishop 2006).

60 3 METHODEN 51 Bestärkendes Lernen Unter bestärkendem Lernen oder reinforcement learning wird das Finden von geeigneten Aktionen in bestimmten Situationen verstanden, um den Gewinn zu maximieren. Auch hier verfügt der Lernalgorithmus, wie beim nicht überwachten Lernen, über keine Beispiele, wie die optimale Lösung auszusehen hat. Der Algorithmus muss sich hierbei an die optimale Lösung durch Versuch und Irrtum herantasten (Bishop 2006). 3.5 Künstliche Neuronale Netze In dieser Arbeit sollen schädliche Android Applikationen mit Hilfe von SOM beziehungsweise CP-ANN identifiziert werden. Bei beiden Modellen handelt es sich um ein künstliches neuronales Netz (ANN), wobei CP-ANN auf SOM aufbaut und im Gegensatz zu SOM überwachtes Lernen ermöglicht. Der Begriff neuronales Netz wurde bereits in den 1940er Jahren geprägt und hat seine Wurzeln im Versuch, die Informationsverarbeitung in biologischen Systemen mathematisch zu repräsentieren (Bishop 2006). Künstliche neuronale Netze (ANN) versuchen die Funktionsweise von biologischen Systemen, beispielsweise des menschlichen Gehirns, nachzubilden. Solche künstlichen neuronalen Netze können laut (Yin 2008) nicht nur bessere Ergebnisse als traditionelle Problem-Löse-Verfahren liefern, sondern geben uns auch ein besseres Verständnis der geistigen Fähigkeiten des menschlichen Gehirns. Laut (Yegnanarayana 2009, 15) ist es allerdings noch ein weiter Weg, bis ANNs ein biologisches neuronales Netz gänzlich nachbilden können. Hauptgrund dafür ist die enorme Anzahl von Neuronen und Synapsen, sowie deren asynchrone Interaktion, die simuliert werden müsste. Doch auch mit der heutigen Rechenleistung ist es durchaus möglich, Probleme mit Hilfe von ANNs zu lösen Biologischer Hintergrund Der im menschlichen Gehirn am höchsten entwickelte Teil, von dem auch unsere Intelligenz ausgeht, ist der Neocortex, ein Teil der Großhirnrinde. Dieser hat eine ungefähre Fläche von 0,2 Quadratmetern, ist circa 2-3 Millimeter dick und stark verworren, um Platz zu sparen. Im Neocortex können verschiedene Bereiche unterschieden werden, die auf bestimmte Aufgaben spezialisiert sind, beispielsweise visuelle Wahrnehmung oder Bewegung (Ritter u. a. 1992, 12). Laut (Andersen, Korbo und Pakkenberg 1992) verfügt die menschliche Großhirnrinde über 21 bis 26 Milliarden Neuronen. Abbildung 12 zeigt die Entwicklung des SyNAPSE Chips, der von IBM entwickelt wird. Die zweite Generation des Chips, die im August 2014 vorgestellt wurde, verfügt bereits über 1 Million programmierbarer Neuronen und kann 256 Millionen Synapsen Hardwareunterstützt simulieren. Um damit die menschliche Großhirnrinde, und damit deren Intelligenz zu simulieren, wäre ein Verbund von rund dieser Chips nötig. Die Entwicklung innerhalb von nur drei Jahren von der ersten auf die zweite Generation zeigt jedoch, dass dieses Ziel in greifbare Nähe rückt.

61 3 METHODEN 52 Abbildung 12: IBM SyNAPSE Chip (Quelle: Anwendung Das Ziel von ANNs ist es, die Art, wie natürliche neuronale Netze Wahrnehmungs- oder Wiedererkennungs-Aufgaben lösen, nachzubilden. Damit ein neuronales Netz eine bestimmte Aufgabe lösen kann, müssen die Neuronen durch eine enorme Anzahl von gewichteten Synapsen verbunden werden. Das Verbinden der Neuronen und die Gewichtung der entstehenden Synapsen erfolgt durch ein Lern-Verfahren beziehungsweise einen Trainings-Algorithmus (Yin 2008). Ein trainiertes ANN soll laut (Zupan, Novič und Ruisánchez 1997) in der Lage sein, eine der folgenden Aufgaben beziehungsweise Probleme zu lösen: 1. Für jedes gegebene Signal X s = (x s1, x s2,..., x sm ) dasjenige Ausgabe-Signal Y s = (y s1, y s2,..., y sn ) zu finden, das dem vordefinierten Ziel-Vektor T s = (t s1, t s2,..., t sn ) am ähnlichsten ist. 2. Für jedes gegebene Signal X s = (x s1, x s2,..., x sm ) mit der Klasse q s, alle Neuronen, die dieser Klasse entsprechen, zu aktivieren. 3. Ohne das vorherige Wissen über die intrinsischen Eigenschaften der Eingabe-Objekte, eine zweidimensionale topologische Distribution (2D Karte), mit den am meisten aktiven Ausgabe-Signalen (Neuronen), als Ergebnis für alle r Eingabe-Objekte X s = (x s1, x s2,..., x sm ), s = 1,..., r, zu erzeugen. Um die ersten beiden Aufgaben zu lösen, wird überwachtes Lernen eingesetzt (siehe 3.4). Dafür wird ein Set von Eingabe-Ausgabe-Paaren {X s, T s }, wobei X s = (x s1, x s2,..., x sm ) einem m-dimensionalen Eingabe-Objekt und T s = (t s1, t s2,..., t sn ) dem dazugehörigen Ziel- Vektor entspricht, benötigt. Während des überwachten Lernens wird für jedes Eingabe- Objekt X s der Ausgabe-Vektor Y s berechnet und mit dem Ziel-Vektor T s verglichen. Nach diesem Vergleich werden, entsprechend der jeweiligen ANN-Strategie, die Gewichte der Neuronen so angepasst, dass im finalen Modell Y s und T s bestmöglich übereinstimmen. Die letzte Aufgabe (2D Karte) wird durch nicht überwachtes Lernen (siehe 3.4) gelöst, wobei keine Ziel-Vektoren T s im Voraus bekannt sind. Diese können allerdings, falls vorhanden, genutzt werden, um das gelernte Modell im Nachhinein zu überprüfen.

62 3 METHODEN 53 In jedem Fall ist es nötig, alle Eingabe-Objekte X s des Trainings-Sets (und Ziel-Vektoren T s wenn benötigt) mehrfach auf das Netzwerk anzuwenden, um dieses zu trainieren. Das Anpassen aller Gewichtungen im ANN durch alle Eingabe-Objekte entspricht dabei einem Zyklus, auch Epoche genannt, des Lern-Prozesses. Das Anwenden aller Eingabe-Objekte wird so lange wiederholt, bis entweder die Distanz zwischen allen T s und Y s akzeptabel ist oder eine definierte Anzahl von Epochen erreicht wurde. 3.6 Selbst-organisierende Karten Unter den existierenden ANN Architekturen und Algorithmen, ist die Self-Organizing Map (SOM) oder auch Kohonen ANN von (Kohonen 1990) eines der populärsten Modelle. Dabei handelt es sich um ein abstraktes mathematisches Modell zur topographischen Zuordnung von (visuellen) Reizen durch ein neuronales Netzwerk (Yin 2008). Abbildung 13: Selbst-Organisierende Karte (Zupan, Novič und Ruisánchez 1997) Abbildung 13 zeigt eine SOM oder Kohonen-Karte. Die Neuronen werden dabei als Säulen dargestellt und sind in einer quadratischen Matrix (N net N net ) angeordnet. Die Länge der Säulen (m) entspricht dabei der Anzahl von Gewichten beziehungsweise der Anzahl der Dimensionen der Eingabe-Vektoren X s. Alle Gewichte der i-ten Ebene erhalten gleichzeitig die i-te Komponente x i des Eingabe-Vektors X s. Das erregte Neuron c mit dem Label L wird aufgrund der besten Übereinstimmung gewählt. Das Kohonen ANN basiert auf einer einzigen Schicht von Neuronen, die quadratisch angeordnet sind und einer zweidimensionalen Fläche, die Reaktionen auf der Oberseite anzeigt (siehe Abbildung 13). Jedes Neuron in diesem Schema besitzt 8, 16, 24, usw. Nachbarn in seiner ersten, zweiten, dritten, usw. Ebene (Zupan, Novič und Ruisánchez 1997).

63 3 METHODEN Training Während des Lernvorganges wird derselbe multidimensionale Vektor X s allen Neuronen als Eingabe übergeben. Für jedes Neuron wird dieser Vektor X s mit dessen Gewichten verglichen. Die Gewichte wurden dafür vor dem Lernprozess zufällig mit 0 <= w <= 1 initialisiert. Für Kohonen ANNs gilt die Regel, dass ein Eingabe-Objekt nur ein Neuron stimulieren darf. Aus diesem Grund konkurrieren die Neuronen untereinander darum, welches schlussendlich erregt wird. Es wird daher auch von competitive learning gesprochen. Das Neuron, das aus der N net N net Matrix als Sieger hervorgeht, wird als winning oder central Neuron c bezeichnet. Die Auswahl des gewinnenden Neurons basiert auf dem Vergleich der Gewichts-Vektoren W j = (w j1, w j2,..., w jm ) aller Neuronen mit dem Eingabe-Signal X s = (x s1, x s2,..., x sm ) und ist folgendermaßen definiert: { m } Neuron c min (x si w ji ) 2, j = 1, 2,..., c,..., N net N net (1) i=1 Nachdem das gewinnende Neuron c gefunden wurde, startet die Korrektur der Gewichte (lernen). Das charakteristische Merkmahl des Kohonen ANN ist die Implementierung dieser Korrektur, welche einem natürlichen neuronalen Netz stark nachempfunden wurde. Die Korrektur der Gewichte betrifft hierbei nicht das gesamte Netzwerk und nicht einmal die selbe Anzahl von Neuronen in verschiedenen Phasen des Lernprozesses. Es werden nur die Gewichte der Neuronen aktualisiert, die sich in topologischer Nähe zum gewinnenden Neuron befinden. Dieses local feed-back Verfahren bringt alle topologisch nahen Neuronen dazu, sich ähnlich zu verhalten, wenn dem ANN ähnliche Eingabe-Objekte übergeben werden. Das bedeutet, dass durch zwei ähnliche Objekte auch zwei topologisch nahe Neuronen erregt werden. Damit das ANN lernt, müssen die Gewichte W ci des Neurons c in jeder Epoche so angepasst werden, dass diese in den folgenden Epochen die Eingabe-Objekte X s immer besser widerspiegeln (siehe Gleichung 1). Wie bereits erwähnt, werden nicht nur das gewinnende Neuron c, sondern auch dessen 8, 16, 24,..., 8p Nachbarn in dessen ersten, zweiten, dritten,... p-ten Nachbarschaft stimuliert. Jedoch hängt es von den Parametern der Lern-Strategie a max, a min, N net und i tot ab, welche benachbarten Neuronen und in welchem Umfang diese stimuliert werden: w ji = [(a max a min )(p/n net ) + a min ] [1 d/(p + 1)] ( ) (2) x si wji old, d = 0, 1, 2,..., p Gleichung 2 beschreibt, wie die Korrektur des Gewichtes w ji mit steigender Lernzeit und der steigenden topologischen Distanz d zwischen dem j-ten und dem gewinnenden Neuron c, abnimmt. Das Intervall p, das bestimmt, wie viele Neuronen in der Nachbarschaft stimuliert werden, nimmt dafür während des Lernvorganges folgendermaßen ab: p = (i tot i it )N net /(i tot 1) (3)

64 3 METHODEN 55 Am Beginn des Lernvorganges (i it = 1) deckt p das gesamte Netzwerk (p = N net ) ab. Am Ende (i it = i tot ) beschränkt sich p nur noch auf das gewinnende Neuron c (p = 0). Egal ob die Differenz zwischen ( ) x si wji old in Gleichung 2 positiv oder negativ ist, wird wji new nach jeder Epoche näher an x si sein als an wji old. Das nicht überwachte Lernen wird gewöhnlich für eine vorbestimmte Anzahl an Iterationen oder Epochen (i tot ) durchgeführt (Zupan, Novič und Ruisánchez 1997). Top-Map Nachdem das Kohonen ANN alle Epochen (i tot ) der Trainingsphase durchlaufen hat, werden die gesamten Eingabe-Objekte ein weiteres Mal dem ANN übergeben. In diesem letzten Durchlauf werden die Labels der Eingabe-Objekte in der Top-Map den jeweils erregten Neuronen zugewiesen. Diese Top-Map kann als einfache, zweidimensionale Visualisierung der hochdimensionalen Daten betrachtet werden. (Zupan, Novič und Ruisánchez 1997). 3.7 Counterpropagation Artificial Neural Networks Was den Aufbau und die Lern-Strategie angeht, sind CP-ANN und Kohonen ANN sehr ähnlich. Ein CP-ANN besteht aus zwei Schichten, einer Kohonen- und einer Ausgabe- Schicht. Beide Schichten haben exakt die selbe Anzahl und Anordnung von Neuronen, welche auch exakt übereinander angeordnet sind. Jedes Neuron der Kohonen-Schicht hat somit eine eins-zu-eins Beziehung zum jeweiligen Neuron der Ausgabe-Schicht (siehe Abbildung 14). Das CP-ANN stellt somit eine Erweiterung des Kohonen ANN beziehungsweise SOM dar. Der Zweck dieser Erweiterung ist es, mit Hilfe eines Kohonen ANN auch Probleme des überwachten Lernens (siehe 3.4) zu lösen. Auch wenn die Ausgabe-Schicht über exakt die selbe Anzahl und Anordnung von Neuronen wie die Kohonen-Schicht verfügt, unterscheidet sich die Anzahl der Gewichte dieser Neuronen. In der Ausgabe-Schicht entspricht die Anzahl der Gewichte von Neuronen den Dimensionen der Ziel-Vektoren T s (Zupan, Novič und Ruisánchez 1997). Abbildung 14 zeigt ein CP-ANN, welches aus zwei Neuronen-Schichten, der Kohonen- und der Ausgabe-Schicht, besteht. Das gewinnende Neuron c wird für Eingabe-Objekte X s in der Kohonen-Schicht ermittelt. Die Gewichtungen der benachbarten Neuronen werden anschließend in der Kohonen und der Ausgabe-Schicht angepasst Training In CP-ANN werden die Gewichte der Neuronen der Kohonen- und Ausgabe-Schicht laut (Zupan, Novič und Ruisánchez 1997) mittels der sehr ähnlichen Gleichungen 4 und 5 korrigiert: w Kohonen ji = [(a max a min )(p/n net ) + a min ] [1 d/(p + 1)] ( x si w Kohonen ji ), d = 0, 1, 2,..., p (4)

65 3 METHODEN 56 Abbildung 14: Counterpropagation Artificial Neural Network (Zupan, Novič und Ruisánchez 1997) w output ji = [(a max a min )(p/n net ) + a min ] [1 d/(p + 1)] ( ) t si w output (5) ji, d = 0, 1, 2,..., p Beide Gleichungen wurden von Gleichung 2, die zum Korrigieren der Gewichte im Kohonen ANN verwendet wird, abgeleitet. Die Gleichungen 4 und 5 werden auf die Gewichte wji Kohonen und w output ji der Eingabe- (Kohonen) und Ausgabe-Schicht des CP-ANN Modells angewandt. Gleichung 2 und 4 sind dabei identisch, während Gleichung 5 leicht modifiziert wurde, um überwachtes Lernen und damit Ziel-Vektoren T s anstelle von Eingabe-Objekten X s zu unterstützen. Einen entscheidenden Unterschied stellt hierbei die Wahl des gewinnenden Neurons c und damit auch die Wahl der betroffenen benachbarten Neuronen dar. Bei Gleichung 4 wird c genau wie beim Kohonen ANN gewählt. Mittels der Gleichung 1 wird das Neuron gesucht, dessen Gewichte dem Eingabe-Vektor X s = (x s1, x s2,..., x sm ) am ähnlichsten sind. Wenn das gewinnende Neuron c in der Eingabe-Schicht (Kohonen) gefunden wurde, gilt dieses auch für die Ausgabe-Schicht. Das bedeutet, dass die topologische Position des Neurons c in beiden Schichten gleich ist. Die Gewichte in der Ausgabe-Schicht werden anschließend mittels der Komponenten t si des Ziel-Vektors T s = (t s1, t s2,..., t sn ) anstelle von x si der Eingabe-Objekte, korrigiert (Zupan, Novič und Ruisánchez 1997). Nachdem das Training beendet wurde, kann mit Hilfe der Kohonen-Schicht im CP-ANN für jedes Eingabe-Objekt X s die Position des Neurons in der Ausgabe-Schicht ermittelt werden. Aufgrund der Tatsache, dass auch die Ziel-Klassen während des Lern-Prozesses verteilt werden (siehe Gleichung 5), enthalten alle Neuronen der Ausgabe-Schicht Klassen, auch wenn das dazugehörige Neuron der Kohonen-Schicht niemals während des Trainings erregt wurde (Zupan, Novič und Ruisánchez 1997).

66 4 ANDROSOM FEATURE MINER 57 4 AndroSOM Feature Miner In dieser Arbeit werden statische sowie dynamische Analyse eingesetzt, um ein möglichst gutes Gesamtbild der zu analysierenden Applikationen zu erhalten. Dazu wurde ein Framework namens AndroSOM Feature Miner entwickelt. Das Grundgerüst wurde in der Programmiersprache GO 13 implementiert und verfügt über ein GUI. Mit Hilfe dieses GUI können alle nötigen Schritte durchgeführt werden, um verschiedene Datensätze zu erstellen, welche später in MatLab analysiert werden können. Das Framework zum Extrahieren von Features wurde in drei Module eingeteilt: 1. Modul zum Sammeln von Metadaten: Metadaten werden von VirusTotal 14 bezogen. Mit Hilfe dieser Daten wird entschieden, ob es sich bei einem bestimmten Sample um Schadsoftware handelt oder nicht. 2. Modul zur statischen Analyse: Die statische Analyse wird mit Hilfe von Androguard durchgeführt, einem weit verbreiteten Framework für die statische Analyse von Android Applikationen (siehe und 3.2.3). Daten aus der statischen Analyse fließen nicht nur direkt in die später erzeugten Feature-Vektoren ein, sondern werden auch für die dynamische Analyse verwendet, um beispielsweise alle Dienste eines Samples zu starten oder bestimmte Broadcasts auszusenden, auf die eine Applikation hört. 3. Modul zur dynamischen Analyse: Besonderes Augenmerk lag bei der dynamischen Analyse darauf, diese möglichst performant zu gestalten. Deshalb wird nicht, wie in vielen anderen Arbeiten (siehe und 3.2.3), QEMU als Emulator verwendet, sondern auf VirtualBox und Android-x86 gesetzt. Während der dynamischen Analyse wird nicht nur das Verhalten eines Samples während dessen Ausführung überwacht, sondern auch ein möglicher Netzwerk-Verkehr analysiert. Die Module zum Sammeln von Metadaten und zur statischen sowie dynamischen Analyse wurden größtenteils in Python beziehungsweise in Form von Shell-Skripten implementiert. 4.1 AndroSOM GUI Das GUI wurde mit Hilfe von GTK 15 implementiert und ist in drei Bereiche aufgeteilt, die über Tabs (siehe Abbildung 15) zu erreichen sind. Um das AndroSOM GUI zu starten, kann im Stammverzeichnis des Frameworks./featureminer ausgeführt werden. Dabei handelt es sich um eine für die Linux x86-architektur kompilierte Binärdatei. Ansonsten kann das AndroSOM Framework auch mittels des Befehls go run featureminer im Stammverzeichnis des Frameworks aufgerufen werden. Dafür ist allerdings eine vorangehende Installation der GO Entwicklungsumgebung von Nöten

67 4 ANDROSOM FEATURE MINER 58 (a) Miner Tab (b) Dependencies Tab (c) Dataset Tab Abbildung 15: AndroSOM: GUI Installation der Abhängigkeiten Wie in Abbildung 15b zu sehen ist, können über das AndroSOM GUI alle benötigten Abhängigkeiten installiert, sowie das AndroSOM Android 4.4 x86 System-Image heruntergeladen und in VirtualBox importiert werden. Abschließend wird diese AndroSOM Sandbox für die weitere Verwendung eingerichtet. Dazu müssen die AndroSOM Sandbox gebootet und der Lockscreen entsperrt werden. Durch den anschließenden Klick auf Take Snapshot wird ein Abbild des momentanen, sauberen System-Zustandes angefertigt und die VM automatisch heruntergefahren. Dieses Abbild wird in weiterer Folge vor jedem dynamischen Analyse-Durchgang wiederhergestellt, damit jedes Sample auf einem sauberen und unveränderten System ausgeführt wird. Die Installation aller notwendigen Komponenten beziehungsweise Abhängigkeiten durch vorgefertigte Setup-Scripte und die Einrichtung der AndroSOM Sandbox für die dynamische Analyse wurde unter Linux Mint bit getestet. Sollte es zu Problemen

68 4 ANDROSOM FEATURE MINER 59 kommen, kann die genaue Auflistung aller benötigten Pakete und deren Installations- Verzeichnis den jeweiligen Setup-Scripten unter./scripts/setup/ entnommen werden. Extrahieren der Features Um Features zu extrahieren, kann nach der Installation der Abhängigkeiten und der Einrichtung der AndroSOM Sandbox der Feature Miner Tab (siehe Abbildung 15a) verwendet werden. Dieser gliedert sich in vier Bereiche: Einen allgemeinen Bereich, in dem das Input- und ein Output-Verzeichnis zu wählen ist und drei Bereiche zum Steuern der zuvor genannten Module. Das Input-Verzeichnis enthält alle zu analysierenden Samples in Form von APK-Dateien. Diese können sich auch in Unterordnern befinden. Im Output-Verzeichnis werden, beispielsweise während der dynamischen Analyse, alle gesammelten Log-Dateien in Unterverzeichnissen für jedes Sample gesichert, damit diese gegebenenfalls auch für eine spätere Analyse durch externe Anwendungen zur Verfügung stehen. Das Sichern der Rohdaten erschien sinnvoll, da ein erneuter Durchlauf der dynamischen Analyse sehr zeitaufwendig wäre. Nach dem Auswählen der Verzeichnisse können die Samples durch einen Klick auf Load Android APKs geladen werden. Ab diesem Zeitpunkt stehen alle drei Module zur Verfügung. Diese müssen jedoch in der gegebenen Reihenfolge ausgeführt werden, da sie aufeinander aufbauen. 1. VirusTotal: Dieses Modul dient zum Sammeln von Metadaten. Wird ein gültiger API-Schlüssel für die private API angegeben, können die benötigten Daten sehr schnell parallel abgefragt werden. Verfügt der oder die BenutzerIn nur über einen öffentlichen API-Schlüssel, sind nur 4 Anfragen pro Minute möglich. Auch das Einreichen von Samples, die über 32 Megabyte groß sind, funktioniert nur über die private API. Ein öffentlicher API-Schlüssel wird allen auf VirusTotal 16 angemeldeten BenutzerInnen gratis zur Verfügung gestellt. 2. Static Analysis: Dieses Modul führt eine statische Analyse einer APK-Datei mit Hilfe von Androguard durch. Es können maximal so viele Samples parallel analysiert werden, wie CPU-Kerne auf dem System zur Verfügung stehen. 3. Dynamic Analysis: Dieses Modul führt eine dynamische Analyse durch. Auf die Funktionsweise der dynamischen Analyse wird in Kapitel genau eingegangen. Datensätze erstellen Um Datensätze für die spätere Analyse in MatLab 17 zu erstellen, verfügt der Feature Miner über einen Tab namens Build Dataset (siehe Abbildung 15c)

69 4 ANDROSOM FEATURE MINER 60 Hier stehen wiederum zwei Module zur Verfügung, welche in der gegebenen Reihenfolge ausgeführt werden müssen. Um diese Module zu benutzen, ist es nötig, dass im Feature Miner Tab ein Input- und Output-Verzeichnis gewählt und die Samples geladen wurden, die später in den Datensätzen enthalten sein sollen. So können auch kleinere Datensätze, die nicht alle analysierten Samples enthalten, erstellt werden. 1. Preparation: Im ersten Schritt werden die gesamten Features aller geladenen Samples in einer zentralen Datenbank gesammelt, zusammen mit der Häufigkeit ihres Vorkommens in schädlichen und legitimen Applikationen und anderen Metadaten. 2. Build Datasets: Im zweiten Schritt werden mit Hilfe der zuvor generierten Feature- Datenbank spezifische Feature-Vektoren für alle geladenen Samples erstellt. Diese Feature-Vektoren werden anschließend in verschiedene Datensätze geschrieben. Dabei kann für alle drei Arten von Features (aus der statischen und dynamischen Analyse, wobei bei der dynamischen Analyse die Daten aus dem Netzwerk-Verkehr extra behandelt werden) ein Filter gesetzt werden, welcher angibt, in wie vielen Samples ein bestimmtes Feature vorhanden sein muss, um in die entsprechenden Datensätze aufgenommen zu werden. Mit einem Klick auf Check Filters kann überprüft werden, wie viele Features sich in den resultierenden Datensätzen, bei den momentan gesetzten Filter-Werten, befinden. 4.2 Architektur des Frameworks Abbildung 16: AndroSOM: Architektur

70 4 ANDROSOM FEATURE MINER 61 Wie bereits zuvor beschrieben, besteht das Framework aus einem Grundgerüst und verschiedenen Modulen, die ineinander greifen. Für die Implementierung des Frameworks wurden dabei unterschiedliche Programmiersprachen verwendet. Das Grundgerüst wurde dabei in GO geschrieben, während es sich bei den Modulen größtenteils um Python- beziehungsweise Shell-Skripte handelt. Damit wurde versucht, für jede Aufgabe das richtige Werkzeug zu wählen. Abbildung 16 zeigt, wie der AndroSOM Feature Miner grob aufgebaut ist. Im Zentrum steht eine NoSQL Datenbank (MongoDB), in die alle Module ihre generierten Daten als Sammlungen von JavaScript Object Notation (JSON)-ähnlichen Dokumenten speichern. Diese Daten können in weiterer Folge bei Bedarf effizient von den anderen Modulen abgefragt werden. Zuerst müssen Metadaten zu den Samples gesammelt werden. Diese stammen von VirusTotal und werden in der Datenbank abgelegt, sofern diese noch nicht vorhanden sind. Jedes Sample wird dafür eindeutig durch dessen Secure Hash Algorithm - Version 1 (SHA-1) Hash identifiziert. Die so gesammelten Daten von VirusTotal finden hauptsächlich für die Filterung von Samples Verwendung, bei denen es sich nicht eindeutig genug um Schadsoftware (von mindestens 35 Viren-Scannern erkannt) oder legitime Applikationen (von keinem einzigen Viren-Scanner erkannt) handelt. 35 positive Treffer, bei momentan 50 Viren-Scannern, erschien geeignet, da diese Zahl relativ hoch ist, aber trotzdem nicht allzu viele Samples aus der Wertung fallen (siehe auch Abbildung 24). Alle anderen Module greifen auf diese Daten zu, um nicht brauchbare Samples zu überspringen. Die statische Analyse benötigt als weiteren Input nur eine APK-Datei und legt die mittels Androguard gesammelten und aufbereiteten Daten anschließend in eine MongoDB Collection (Sammlung von Dokumenten) ab. Die so generierten Daten werden unter anderem von der dynamischen Analyse verwendet, um bestimmte Events, wie beispielsweise Broadcasts zu simulieren oder einfach alle in einem Sample enthaltenen Dienste gleich am Beginn der Ausführungszeit zu starten. Zusätzlich werden zufällige Events durch den Android Monkey (siehe Kapitel 3.3) generiert. Die bei der dynamischen Analyse mittels strace und tcpdump gesammelten Daten werden aufbereitet und in separaten MongoDB Collections abgelegt. Nach dem Analysieren der Samples wird eine Referenz-Collection angelegt, die alle Features zusammen mit Metadaten enthält (siehe Listing 7). Bei diesen Metadaten handelt es sich um die Anzahl der Vorkommen eines Features in legitimen Applikationen beziehungsweise in Schadsoftware. Wenn nötig, wird auch ein Maximal-Wert, der beschreibt, wie oft ein Feature in einem Sample maximal vorkommt, abgespeichert. Dieser kann für die spätere Normalisierung der Daten benötigt werden. Die gesammelten Metadaten werden außerdem für die Filterung von Features verwendet. Als letzter Schritt werden verschiedene Datensätze generiert, die für die weitere Analyse in MatLab importiert werden können. Das Grundgerüst wurde in GO geschrieben und besteht unter anderem aus einem GUI (siehe Abbildung 15), sowie mehreren GO-Packages, beispielsweise (./miner/miner.go), mit dessen Hilfe Python-Scripte effizient parallel ausgeführt und das GUI aktualisiert

71 4 ANDROSOM FEATURE MINER 62 werden können. Hierfür stellt GO sogenannte Channels 18 zur Verfügung, womit ein Producer/Consumer Pattern, wie es in Listing 2 zu sehen ist, implementiert wurde. Listing 2: Producer/Consumer Pattern in GO 1 type Job struct { 2 command string 3 args [] string 4 } 5 6 func Producer(apks *[] string, outputfolder string, 7 script string, numcpu int) { 8 numofjobs := len(* apks) 9 jobschan := make(chan Job, numofjobs) 10 donechan := make(chan int) go func() { 13 for _, path := range * apks { 14 args := [] string{ 15 "-i" + path, 16 "-o" + outputfolder, 17 } 18 job := Job{ command: working_dir + "/ scripts/" + script, args: args} 19 jobschan <- job 20 } 21 }() for i := 0; i < numcpu; i++ { 24 go consumer(jobschan, donechan) 25 } updategui(donechan, progressbar, numofjobs) 28 } func consumer( jobschan chan Job, donechan chan int) { 31 for { 32 job := <-jobschan 33 cmd := exec. Command(job.command, job.args...) 34 if err := cmd. Run(); err!= nil { 35 fmt. Println(err) 36 } 37 donechan <- True 38 } 39 } 18.

72 4 ANDROSOM FEATURE MINER 63 Die Producer Methode wird dabei nur einmal durch das GUI aufgerufen. Ihr werden unter anderem ein String-Array mit den Pfaden aller geladenen APK-Dateien, der Pfad zum jeweiligen Analyse-Script (beispielsweise statische oder dynamische Analyse) und die Anzahl zu startender Consumer übergeben. Zuerst werden zwei Channels angelegt. Durch den jobschan werden nacheinander die Pfade von allen geladenen APK Dateien geschickt, während durch den donechan immer dann ein True gesendet wird, wenn das auszuführende Python-Script beendet wurde. Um den jobschan zu befüllen, wird eine Go-Routine, welche in einem extra Thread asynchron ausgeführt wird, gestartet. Parallel dazu wird eine beliebige Anzahl von Consomer-Methoden, ebenfalls als GO-Routinen, gestartet. Der Producer wartet anschließend, bis alle Job-Instanzen abgearbeitet wurden und aktualisiert gegebenenfalls das GUI. Die Consumer nehmen nacheinander alle Job-Instanzen entgegen, arbeiten diese ab und benachrichtigen den Producer, wenn ein Job fertiggestellt wurde. Neben dem GUI und dem Miner-Package ist die in./tools/mongodb/ installierte MongoDB Datenbank einer der Grundpfeiler des Frameworks. Diese läuft auf einem eigens konfigurierten Port und legt ihre Daten in./data/ ab, wodurch es zu keinen Konflikten kommen sollte, auch wenn MongoDB bereits auf dem System installiert sein sollte. Die Datenbank wird automatisch mit dem GUI gestartet beziehungsweise beendet. Weitere Grundpfeiler sind das unter./tools/androguard/ installierte Androguard Framework, welches für die statische Analyse verwendet wird, sowie eine für den lokalen Benutzer installierte VirtualBox- und Android Entwicklungs-Umgebung. All diese Abhängigkeiten können über die entsprechenden Installations-Scripte in./scripts/setup/ oder direkt über das GUI (siehe Abbildung 15b) installiert werden Modul: Metadaten Ob es sich bei einem Sample um Schadsoftware handelt oder nicht, wird mit Hilfe von VirusTotal entschieden. Von den in dieser Arbeit verwendeten Samples befanden sich bereits rund 95% in der VirusTotal Datenbank und mussten somit nicht mehr extra analysiert werden. Die Daten standen daher in den meisten Fällen ohne weitere Wartezeit zur Verfügung. Abbildung 17: AndroSOM: Sammeln von Metadaten

73 4 ANDROSOM FEATURE MINER 64 In Abbildung 17 wird die Funktionsweise des Metadaten-Moduls vereinfacht dargestellt. Dem Kontrollscript wird eine APK-Datei übergeben. Mit dieser wird ein SHA-1 Hash generiert, der genutzt wird, um einen Bericht für das entsprechende Sample von VirusTotal anzufordern. Wird von der VirusTotal-API der Response-Code 0 zurückgegeben, handelt es sich um ein unbekanntes Sample, welches zur weiteren Analyse durch eine Vielzahl von Viren-Scannern hochgeladen werden muss. Kommt als Response-Code 1 zurück, können die erhaltenen Daten (siehe Listing 3) direkt in die entsprechende MongoDB Collection geschrieben werden. Der Response-Code -2 bedeutet, dass sich das bereits hochgeladene Sample in der Warteschlange befindet und die Daten zu einem späteren Zeitpunkt bezogen werden können. Wenn ein Sample zur Analyse an die VirusTotal-API geschickt werden muss, sollte es kleiner als 32MB sein. Für größere Samples muss über die private API eine Upload-URL angefordert werden, wofür ein privater API-Schlüssel von Nöten ist. Da nur Metadaten für Samples angefordert werden, die sich noch nicht in der Datenbank befinden, kann dieses Modul so oft hintereinander ausgeführt werden, bis für jedes Sample auf VirusTotal ein Bericht vorliegt. Gesammelte Daten Die Metadaten werden direkt von der VirusTotal-API bezogen und unverändert in einer MongoDB Collection abgelegt. Listing 3 zeigt einen Auszug der Daten, welche von VirusTotal durch Angabe eines Hashes bezogen werden können. Besonders wichtig hierbei sind die positives. Dieser Wert gibt an, von wie vielen Viren-Scannern eine Datei als schädlich klassifiziert wurde. Im Zuge dieser Arbeit wurde ein Grenzwert von mindestens 35 Viren-Scannern festgelegt, die ein Sample als Schadsoftware klassifiziert haben müssen, beziehungsweise 0 positive Treffer für legitime Applikationen (siehe auch 24). Samples, die von zwischen 1 bis 34 Viren-Scannern positiv klassifiziert wurden, werden nicht berücksichtigt. Listing 3: VirusTotal API Response 1 { 2 "sha1": " fc16aba5d aaf7cf9b439bbdc9", 3 " response_code": NumberInt(1), 4 " positives": NumberInt (40), 5 "total": NumberInt (53), 6 " scan_date": " : 53: 10", 7 "scans": { 8 "Bkav": { 9 " detected": true, 10 " result": " MW. Clod81b. Trojan. bc0e", 11 }, } 14 }

74 4 ANDROSOM FEATURE MINER Modul: Statische Analyse Für die statische Analyse wird Androguard eingesetzt. Wie in Abbildung 18 zu sehen ist, wird auch dem für die statische Analyse zuständigen Python-Script eine APK-Datei übergeben. Die Analyse wird gleich zu Beginn abgebrochen, wenn für das übergebene Sample keine VirusTotal Metadaten gefunden werden können oder es sich nicht eindeutig genug um Schadsoftware beziehungsweise eine legitime Applikation handelt. Abbildung 18: AndroSOM: Statische Analyse Wenn die Analyse nicht zuvor abgebrochen wurde, wird das Sample entpackt und anschließend durch Androguard festgestellt, ob es sich dabei um eine valide APK-Datei handelt. Wenn ja, wird die statische Analyse durchgeführt. Anschließend werden die Ergebnisse aufbereitet und in einer MongoDB Collection geschrieben. Die statische Analyse kann, wie auch das vorangegangene Sammeln von Metadaten, parallelisiert werden. Abbildung 19: Laufzeiten-Verteilung bei der statischen Analyse Abbildung 19 zeigt die Laufzeiten-Verteilung der statischen Analyse. Zu sehen ist, dass die Laufzeit beim Großteil der Applikationen weniger als 20 Sekunden betrug. Die meisten Applikationen konnten sogar innerhalb der ersten 5 Sekunden analysiert werden.

75 4 ANDROSOM FEATURE MINER 66 Gesammelte Rohdaten Bei der statischen Analyse werden unter anderem die in Tabelle 5 aufgelisteten Daten gesammelt. Viele der extrahierten Daten können dabei fast unverändert von Androguard übernommen werden. Einige Daten, beispielsweise die gesammelten externalmethodcalls und die actualpermissions, werden zuvor aufbereitet, um Speicher zu sparen (siehe Listing 4 und 5). Methoden-Aufrufe mit gleichen Signaturen werden dafür zusammengefasst und mit der Anzahl ihrer Vorkommen versehen. Die gesammelten Daten werden später zum Erstellen von Features sowie für die Steuerung der dynamischen Analyse genutzt. Listing 4: Statische Analyse: Externe Methoden Aufrufe "Landroid/os/Environment;": { 3 " getexternalstoragedirectory": { 4 "() Ljava/ io/ File;": NumberInt(3) 5 } 6 } 7... Listing 5: Statische Analyse: Benötigte Berechtigungen 1 " READ_PHONE_STATE": { 2 "Lorg/acra/util": { 3 " Landroid/ telephony/ TelephonyManager;": { 4 "getdeviceid": { 5 "() Ljava/ lang/ String;": NumberInt(1) 6 } 7 } 8 } 9 } Modul: Dynamische Analyse Die dynamische Analyse stellt den aufwendigsten Teil des Frameworks dar, nicht nur was den Entwicklungsaufwand, sondern auch was die Laufzeit betrifft. Besonderes Augenmerk liegt deshalb bei der dynamischen Analyse darauf, diese möglichst performant zu gestalten. Aus diesem Grund wird nicht, wie in vielen anderen Arbeiten (siehe und 3.2.3), QEMU als Emulator eingesetzt, sondern auf VirtualBox und Android-x86 gesetzt. Warum VirtualBox? Der Android Emulator in seiner Standard-Konfiguration ist sehr langsam. Allein der Start des Emulators und der Bootvorgang des Android-Systems können einige Minuten beanspruchen, was bei der dynamischen Analyse zu viel längeren Laufzeiten führen würde.

76 4 ANDROSOM FEATURE MINER 67 validapk True oder False, je nachdem ob Androguard in der Lage war die APK-Datei zu öffnen oder nicht. package Das Applikations-Package beziehungsweise der Namensraum, in dem sich die Applikation befindet, beispielsweise at.torghele.camera. mainactivity Diejenige Aktivität, die beim Start einer Applikation über deren Icon im Launcher ausgeführt wird, beispielsweise CameraActivity. activities Alle weiteren Aktivitäten, über die eine Applikation verfügt. Diese werden später bei der dynamischen Analyse nacheinander gestartet, um eine möglichst gute Code-Abdeckung zu erreichen. providers Alle Content-Provider, die von einer Applikation zur Verfügung gestellt werden. receivers Alle Broadcast-Receiver, die eine Applikation enthält. Die entsprechenden Broadcasts werden während der dynamischen Analyse gesendet. services Alle Dienste, die eine Applikation zur Verfügung stellt. Diese werden zum Beginn der dynamischen Analyse gestartet. libraries Externe Bibliotheken, die eine Applikation benötigt, beispielsweise die Google Maps Bibliothek. iscryptocode True oder False, je nachdem ob verschlüsselte Code-Teile gefunden wurden oder nicht. isdynamiccode True oder False, je nachdem ob Code dynamisch nachgeladen wird oder nicht. isnativecode True oder False, je nachdem ob nativer Code vorhanden ist oder nicht. isreflectioncode True oder False, je nachdem ob Code Reflexion eingesetzt wird oder nicht. permissions Alle Berechtigungen, die von einer Applikation in deren Manifest- Datei angefordert werden. externalmethodcalls Enthält alle Aufrufe von Methoden, die sich außerhalb des eigenen Namensraumes befinden. Hier sind auch alle Android API Aufrufe enthalten (siehe Listing 4). Außerdem wird zu jeder Methoden- Signatur die Anzahl der Aufrufe gespeichert. actualpermissions Enthält alle Methoden, die eine bestimmte Berechtigung voraussetzen (siehe Listing 5). Auch hier wird zu jeder Methoden- Signatur die Anzahl der Aufrufe gespeichert. Tabelle 5: AndroSOM: Statische Features

77 4 ANDROSOM FEATURE MINER 68 Es wäre damit aus Performance-Gründen auch nur sehr schwer möglich, die dynamische Analyse mittels strace, vor allem wenn damit der Zygote-Prozess und damit nahezu das gesamte System überwacht wird, durchzuführen. Aus diesem Grund verwenden einige andere Arbeiten (siehe und 3.2.3) speziell entwickelte Kernel-Module zum Aufzeichnen von System-Aufrufen. Es gibt mehrere Möglichkeiten, um den Android Emulator zu beschleunigen und somit eine Analyse mittels strace zu ermöglichen: Den Bootvorgang durch ein Snapshot beschleunigen / überspringen CPU Hardware-Beschleunigung GPU Hardware-Beschleunigung Durch das Wiederherstellen eines Snapshots können zwei Probleme gelöst werden. Einerseits kann der Bootvorgang übersprungen werden, wodurch das System innerhalb von wenigen Sekunden anstatt mehreren Minuten zur Verfügung steht, andererseits steht für jeden Analyse-Durchlauf ein sauberes, unverändertes System zur Verfügung, wenn das System zuvor immer wieder auf diesen Snapshot zurückgesetzt wird. Sowohl QEMU als auch VirtualBox verfügen über die Möglichkeit, Snapshots zu erzeugen. Die Standard-CPU-Architektur von Android für Smartphones und Tablet-PCs ist ARM. Wenn die ARM-Architektur auf einem x86-system emuliert werden muss, entsteht ein enormer Overhead. Deshalb stellt das Android SDK für API-Level 10 und 15+ auch x86-images zur Verfügung. Diese können auch unter QEMU Hardware-beschleunigt ausgeführt werden. In VirtualBox können auf einem Host-Computer mit x86-architektur nur x86 Android Images ausgeführt werden. Neben der Emulation der CPU entstehen vor allem durch die Emulation der GPU bei der Darstellung des GUI Performance-Engpässe. Ab API-Level 14 kann unter QEMU auch dafür Hardware-Beschleunigung genutzt werden. Es entsteht dabei allerdings folgendes Problem: Snapshots und GPU Hardware-Beschleunigung schließen sich unter QEMU gegenseitig aus. Um ein flüssig laufendes System für die dynamische Analyse zu erreichen, dem neben der Ausführung von Applikationen (darunter auch Spiele mit 3D-Inhalten) noch genügend Ressourcen zur Verfügung stehen, um problemlos strace auf nahezu allen laufenden Prozessen und tcpdump auszuführen, müssen CPU und GPU Hardware-beschleunigt sein. Wird eine der beiden Komponenten emuliert, läuft die AndroSOM Sandbox nicht mehr flüssig. Unter QEMU müsste in diesem Fall auf Snapshots verzichtet werden, wodurch nicht nur der Bootvorgang bei jedem Durchlauf abgewartet, sondern auch sichergestellt werden müsste, dass ein unverändertes Android-System vorliegt. VirtualBox hingegen unterstützt alle drei Features. Mit einem x86-image unter QEMU würde der Bootvorgang zwar von mehreren Minuten auf rund 90 Sekunden verkürzt, was allerdings bei 2691 getesteten Samples immer noch einer rund 2 1/2 Tage längeren Analyse-Laufzeit entspricht.

78 4 ANDROSOM FEATURE MINER 69 Android-x86 Für AndroSOM wurde unter Verwendung des Android-x86 Projektes ein zum Zeitpunkt der Implementierung des Frameworks aktuelles Android System-Image kompiliert. Dieses beinhaltet einige zusätzliche Werkzeuge, beispielsweise tcpdump und busybox 19. Zum Erzeugen dieses Images wurde ein Build-Environment aufgesetzt. Zusätzlich zu den in der Dokumentation angegebenen Abhängigkeiten 20 mussten noch squashfs-tools, gettext, yasm und javadoc installiert werden, damit der Build-Vorgang erfolgreich abgeschlossen werden konnte. Listing 6 zeigt die Build-Konfiguration. Wichtig ist hierbei, dass die TARGET_BUILD_VARIANT auf eng gesetzt ist. Andere Möglichkeiten wären user oder userdebug. Dann ständen allerdings für AndroSOM wichtige Funktionen nicht zur Verfügung. Handelt es sich um einen Eng(ineering)-Build, werden nahezu alle vorhandenen Module und Werkzeuge in das resultierende Android-Image, welches schließlich durch den Befehl make iso_img erstellt werden kann, integriert. Außerdem ist die Android Debug Bridge (ADB) standardmäßig aktiviert und das System gerootet. Das Builden des gesamten Android-Systems dauert, je nach System, mehrere Stunden. Listing 6: buildspec.mk 1 TARGET_PRODUCT:= android_x86 2 TARGET_BUILD_VARIANT:= eng 3 TARGET_BUILD_TYPE:= release 4 TARGET_KERNEL_CONFIG:= android - x86_defconfig 5 CUSTOM_TARGETS += tcpdump Nach dem Erstellen des Images wurde dieses in VirtualBox installiert. Da das Android-x86 Repository aus Lizenzgründen keine Applikationen von Google, wie beispielsweise Google Maps enthalten darf, wurden diese manuell installiert. Die VM wurde nach Abschluss der Installation des Android-Systems und aller Standard Google-Applikationen sowie Bibliotheken als Open Virtualization Format (OVA)-Datei exportiert. Diese wird auf Dropbox 21 bereitgestellt und kann direkt über das AndroSOM GUI bezogen werden. Funktionsweise der dynamischen Analyse Abbildung 20 beschreibt den groben Ablauf der dynamischen Analyse. Durchgehende Pfeile entsprechen hierbei dem Fluss von Daten, während gestrichelte Pfeile andeuten, welche Komponente von welcher anderen Komponente gesteuert wird. Wie bereits bei der statischen Analyse zuvor, wird auch hier überprüft, ob die benötigten VirusTotal-Metadaten vorhanden sind und damit entschieden, ob das Sample analysiert

79 4 ANDROSOM FEATURE MINER 70 Abbildung 20: AndroSOM: Dynamische Analyse werden soll oder nicht. Ein weiterer Grund für den vorzeitigen Abbruch der Analyse ist das Fehlen der statischen Analyse eines Samples. Aus dieser werden zumindest der Applikations-Namensraum sowie die Haupt-Aktivität benötigt, um die Applikation später in der AndroSOM Sandbox auszuführen. Da es in vereinzelten Fällen (64 von 2691 analysierten Samples oder 2,38%) vorkam, dass das Android-System während der Ausführung eines Samples gänzlich einfror, wodurch die dynamische Analyse ohne manuelles Einschreiten niemals zu einem Ende gekommen wäre, wurde ein Timeout von 600 Sekunden festgelegt (300 Sekunden mehr, als ein normaler Analyse-Prozesses dauern sollte, siehe Abbildung 21). Dafür wird ein separater Thread gestartet, der nach Ablauf der gegebenen Zeit die Sandbox ordnungsgemäß herunterfährt und den Haupt-Thread beendet. Die dynamische Analyse läuft dabei folgendermaßen ab: 1. get_broadcasts(): Zuerst werden alle Broadcast-Receiver zusammen mit den System- Broadcasts, auf die sie hören, direkt aus dem Manifest der APK-Datei ausgelesen. Diese werden später, während der Laufzeit der Applikation, zur Generierung von Events genutzt. 2. clean_state(): Durch diese Methode werden einerseits alle Dateien in./tmp/

80 4 ANDROSOM FEATURE MINER 71 gelöscht und andererseits der Befehl VBoxManage snapshot AndroidVM restore cleanstate aufgerufen. Dieser setzt die VM auf einen, während der Setup-Phase erstellten, sauberen Snapshot zurück. Das Zurücksetzen einer VM auf einen Snapshot dauert dabei zwischen 0,5 und 3 Sekunden. Damit herrschen für jeden dynamischen Analyse-Durchlauf die exakt gleichen Voraussetzungen. 3. start_vm(): Wie der Name dieser Methode bereits vermuten lässt, wird an dieser Stelle mittels VBoxManage startvm AndroidVM die AndroSOM Sandbox gestartet. Da zuvor ein Snapshot wiederhergestellt wurde, in dem das Android-System bereits voll hochgefahren ist und auf BenutzerInnen Eingaben wartet, steht innerhalb von rund weiteren 2 Sekunden eine voll funktionsfähige Android Sandbox zur Verfügung. Zum Vergleich hätte der Bootvorgang eines in QEMU emulierten Android 4.4 ARM Systems auf derselben Hardware durchschnittlich rund 380 Sekunden beansprucht. Diese enorme Zeitersparnis kann erreicht werden, da der Bootvorgang durch das Snapshot gänzlich übersprungen werden kann und die Hardware-beschleunigte Ausführung des Android-Systems in einem VMM gegenüber einem Emulator um ein Vielfaches effizienter ist (siehe Kapitel 3.2.2). 4. connect_adb(): Nachdem die VM gestartet wurde, wird die Android Debug Bridge ADB gestartet und eine Verbindung zum in der VM laufenden Android-System aufgebaut. Von nun an kann mittels des Befehls adb shell direkt auf die Android Kommandozeile zugegriffen werden. Es ist unter anderem auch möglich, mittels adb push/pull Dateien zu übertragen. 5. push_tasks(): An dieser Stelle ist es nötig, das Shell-Script./scripts/tasks.sh auf das Android-System zu übertragen und diesem Ausführungsrechte zu gewähren. Dieses Script verfügt über folgende Funktionen, die direkt auf dem Android-System ausgeführt werden: fnprepare(): Diese Funktion erstellt unter /sdcard/features/ ein leeres Verzeichnis zum Sammeln von Log-Dateien, die später an den Host-Computer übertragen werden. fnlogpids(): Diese Funktion erwartet als Argument einen Android Username. Wenn diese Funktion aufgerufen wird, werden in einer Endlosschleife alle PIDs, die unter dem übergebenen Usernamen ausgeführt werden, aufgezeichnet. Diese Liste von PIDs wird zur Filterung der strace-logs verwendet, um nur Prozesse zu berücksichtigen, die zur jeweiligen unter Beobachtung stehenden Applikation gehören. fntcpdump(): Mit Hilfe dieser Funktion kann tcpdump zum Aufzeichnen des Netzwerk-Verkehrs auf dem Android-System gestartet oder gestoppt werden. fnstrace(): Mit Hilfe dieser Funktion kann strace zum Überwachen von System-Methoden auf dem Android-System gestartet oder gestoppt werden. strace wird dabei direkt auf den Zygote Prozess und all seine geforkten Unterprozesse angesetzt (siehe Kapitel 2.3.6). Damit werden bis auf vereinzelte

81 4 ANDROSOM FEATURE MINER 72 System-Prozesse alle Prozesse, die auf dem Android-System ausgeführt werden, überwacht. Für jede PID wird dabei eine eigene Log-Datei angelegt. Durch die Aufzeichnung der PIDs im Hintergrund mit Hilfe der zuvor beschriebenen fnlogpids() Funktion können alle Log-Dateien von anderen Applikationen im Nachhinein herausgefiltert werden. fntransfer(): Diese Funktion sendet alle Dateien, die sich im Log-Verzeichnis befinden, mittels File Transfer Protocol (FTP) an den Host-Computer. Der Umweg über FTP wurde aus Performance-Gründen anstelle von adb pull gewählt. Die Dauer des Datentransfers konnte so, abhängig vom jeweiligen Sample, von mehreren Minuten auf wenige Sekunden reduziert werden. fnmonkey(): Diese Funktion erwartet als Argumente den Prozess-Namen, die gewünschte Anzahl an zu generierenden Events und einen Seed. Danach werden der entsprechende Prozess (die zu testende Applikation) gestartet und Events erzeugt. Durch Angabe eines Seeds sind diese Events nicht zufällig, sondern reproduzierbar. 6. install_apk(): Diese Methode installiert das zu analysierende Sample mittels ADB in der AndroidSOM Sandbox. Dafür wird der Befehl adb install <apk Pfad> verwendet. 7. get_username(): Eine Liste aller installierten Applikationen wird vom Android- System in einer Datei namens packages.list geführt. Neben dem eindeutigen Paket-Namen einer jeden Applikation können hier auch Informationen wie beispielsweise die dazugehörige UID ausgelesen werden. Es ist sehr einfach, von einer Android UID den dazugehörigen Username abzuleiten, da diese einem fixen Schema folgen. Die UID 1005 entspricht beispielsweise dem Username u0_a5, die vorangehende 100 wird also einfach durch u0_a ersetzt. Um den Username zu erhalten, welcher mit der zuvor installierten Applikation verknüpft ist, wird die packages.list mittels adb pull heruntergeladen und entsprechend geparst. Der Username, unter dem die zu analysierende Applikation ausgeführt wird, ist für die Aufzeichnung der PIDs durch fnlogpids() nötig. 8. start_tcpdump(): Diese Methode startet mittels der ADB tcpdump in der Andro- SOM Sandbox. Dafür wird adb shell sh /data/local/tasks.sh tcpdump start aufgerufen. 9. start_strace(): Diese Methode startet mittels der ADB strace in der Andro- SOM Sandbox. Dafür wird adb shell sh /data/local/tasks.sh strace start aufgerufen. Außerdem müssen ab diesem Zeitpunkt alle PIDs aufgezeichnet werden, die mit der zu analysierenden Applikation in Verbindung stehen. Dafür wird adb shell sh /data/local/tasks.sh logpids <username> gestartet. 10. start_logcat(): Bei Logcat handelt es sich um ein Android-Werkzeug zum Mitlesen von verschiedenen Android-spezifischen Log-Dateien. Während der dynamischen Analyse wird das Radio-, Events- und Main-Log in entsprechende Dateien

82 4 ANDROSOM FEATURE MINER 73 am Host-Computer geschrieben und später gesichert. Diese könnten zur Fehlersuche herangezogen werden. Ab diesem Zeitpunkt werden das Android-System, sowie die zu analysierende Applikation, in der Sandbox überwacht und die automatisierte Generierung von Events kann beginnen. 11. send_broadcasts(): Diese Methode sendet mittels adb shell am broadcast die zuvor extrahierten Broadcasts direkt an ihre Empfänger. Damit sollen mögliches schädliches Verhalten ausgelöst oder Dienste gestartet werden. 12. start_all_services(): Um sicherzustellen, dass alle in einer Applikation enthaltenen Dienste ausgeführt werden, wird zusätzlich mittels adb shell am startservice versucht, alle vorhandenen Dienste zu starten. 13. run_all_activities(): Diese Methode startet nacheinander jede in der Applikation gefundene Aktivität und führt auf dieser anschließend den Android Monkey zum Simulieren von Events aus. Dabei werden 100 Events an jede Aktivität geschickt. Die Gesamt-Laufzeit dieser Methode wird aufgezeichnet. 14. monkey(restzeit): Da alle Samples bei der dynamischen Analyse gleich lange analysiert werden sollten und es von der Anzahl der Aktivitäten abhängt, wie lange run_all_activities() läuft, wird an dieser Stelle der Android Monkey so oft hintereinander ausgeführt, bis die vordefinierte Gesamt-Analyse-Zeit erreicht wurde. Sollte der Android Monkey hierfür mehr als 20 Anläufe brauchen, kann davon ausgegangen werden, dass die zu analysierende Applikation direkt nach deren Start abstürzt. In diesem Fall wird abgebrochen, um Zeit zu sparen. 15. stop_strace(): Diese Methode beendet mittels der ADB strace in der Andro- SOM Sandbox. Dafür wird adb shell sh /data/local/tasks.sh strace stop aufgerufen. 16. stop_tcpdump(): Diese Methode beendet mittels der ADB tcpdump in der Andro- SOM Sandbox. Dafür wird adb shell sh /data/local/tasks.sh tcpdump stop aufgerufen. 17. pull_data(): Diese Methode startet einen minimalen Python FTP-Server auf dem Host-Computer. Anschließend wird adb shell sh /data/local/tasks.sh transfer aufgerufen und alle Dateien, die sich im Verzeichnis /sdcard/features/ der AndroSOM Sandbox befinden, werden an den Host-Computer übertragen. Wenn alle Dateien übertragen wurden, kann der FTP-Server beendet werden. 18. stop_vm(): Nachdem alle Daten übertragen wurden kann die VM-Instanz heruntergefahren werden. Dies geschieht mittels VBoxManage controlvm AndroidVM poweroff. Auch die ADB muss an dieser Stelle beendet werden um die nötigen Ports für den nächsten Durchlauf freizugeben.

83 4 ANDROSOM FEATURE MINER 74 An dieser Stelle werden alle gesammelten Daten aufbereitet und gesichert. Da das AndroSOM Framework derzeit nur über eine Sandbox-Instanz verfügt und nicht auf die dynamische Analyse von mehreren Samples gleichzeitig ausgelegt ist, kann die Analyse derzeit nicht parallelisiert werden. Abbildung 21: AndroSOM: Laufzeit der dynamischen Analyse Abbildung 21 zeigt den zeitlichen Ablauf der dynamischen Analyse. Die Initialisierungs- Phase beinhaltet dabei alle oben genannten Punkte bis hin zum Punkt start_logcat(), an dem die VM hochgefahren, die zu untersuchende APK installiert und alle Aufzeichnungs- Werkzeuge gestartet wurden. Dieser Schritt dauert durchschnittlich 16,76 Sekunden. In der zweiten Phase wird versucht, möglichst viele Ausführungs-Pfade der zu untersuchenden Applikation zu durchlaufen. Dafür werden Broadcasts gesendet, Dienste gestartet und jede in der Manifest-Datei der Applikation gefundene Aktivität gestartet und mit Zufalls- Events durch den Android Monkey stimuliert. Diese zweite Phase dauert durchschnittlich 98,21 Sekunden und ist gelb markiert. In der nun folgenden Phase der dynamischen Analyse wird der Android Monkey so lange ausgeführt, bis die vordefinierte Mindest- Analyse-Zeit von 300 Sekunden überschritten wurde. Diese Phase ist grün markiert und wird durchschnittlich nach weiteren 222,06 Sekunden beendet. In der letzten Phase der dynamischen Analyse werden die Aufzeichnungs-Werkzeuge gestoppt, die gesammelten Daten aus der VM heruntergeladen, die VM beendet und anschließend die Daten aufbereitet, was durchschnittlich weitere 8,92 Sekunden beansprucht. Die Gesamt-Laufzeit eines dynamischen Analyse-Durchlaufes beträgt somit durchschnittlich 345,95 Sekunden, was bei 2691 analysierten Samples einer Laufzeit von fast 11 Tagen entspricht. Die gemessenen Durchschnitts-Zeiten beruhen auf den Daten von erfolgreichen Analyse-Durchläufen. Durchläufe, die nach dem gesetzten Timeout von 600 Sekunden beendet wurden, wurden hierfür nicht berücksichtigt. Abbildung 22 zeigt die Laufzeiten-Verteilung bei der dynamischen Analyse. Zu sehen ist, dass die Analyse der meisten Samples zwischen 300 und 400 Sekunden in Anspruch genommen hat. Der einzelne Ausschlag bei 600 Sekunden wurde durch diejenigen Applikationen verursacht, die nach dem Erreichen des Timeouts vom Framework beendet wurden.

84 4 ANDROSOM FEATURE MINER 75 Abbildung 22: Laufzeiten-Verteilung bei der dynamischen Analyse valid True oder False, je nachdem ob die dynamische Analyse erfolgreich war oder nicht. Die dynamische Analyse schlägt fehl, wenn bei der Ausführung der Applikation ein vordefiniertes Zeitlimit überschritten wird oder die zu testende Applikation immer gleich nach dem Start abstürzt. chmodedfiles Alle Dateien, deren Zugriffs- und Ausführungs-Berechtigungen durch die Applikation während der Laufzeit verändert wurden, zusammen mit der Anzahl der Zugriffe. accessedfiles Alle Dateien, deren Zugriffs- oder Ausführungs-Berechtigungen durch die Applikation während der Laufzeit getestet wurden, zusammen mit der Anzahl der Tests. openedfiles Alle Dateien, auf die von der Applikation zur Laufzeit lesend oder schreibend zugegriffen wurde, zusammen mit der Anzahl der Zugriffe. methodcalls Alle Aufrufe von System-Methoden wie beispielsweise clock_gettime, mprotect oder getuid32 zusammen mit der genauen Anzahl dieser Aufrufe. Tabelle 6: AndroSOM: Dynamische Features Gesammelte Rohdaten Bei der dynamischen Analyse eines Samples werden einerseits Aufrufe von System-Methoden und der Zugriff auf Dateien durch strace, andererseits der Netzwerk-Verkehr durch tcpdump aufgezeichnet. Die Ergebnisse werden in separaten MongoDB Collections abgelegt und enthalten unter anderem die in den Tabellen 6 und 7 aufgeführten Daten beziehungsweise Features. Alle Features aus der dynamischen Analyse, die in Tabelle 6 aufgelistet sind, können eindeutig der zu untersuchenden Applikation zugeschrieben werden. Die Features der Analyse des Netzwerk-Verkehrs in Tabelle 7 betreffen das gesamte System, könnten also auch von anderen Applikationen oder dem Android-System selber stammen. Da für jeden Durchlauf dieselben Voraussetzungen herrschen, sollte das allerdings kein Problem darstellen.

85 4 ANDROSOM FEATURE MINER 76 accessedips accessedhostnames destinationports usedhttpmethods responsecodes contenttypes Enthält alle Internet Protocol (IP) Adressen, auf die während der Laufzeit der Applikation zugegriffen wurde, zusammen mit der Anzahl der Zugriffe. Enthält alle Hostnames, auf die während der Laufzeit der Applikation zugegriffen wurde, zusammen mit der Anzahl der Zugriffe. Enthält alle Ziel-Port-Nummern, über die Netzwerk-Aktivitäten während der Laufzeit der Applikation stattfanden, zusammen mit der Anzahl dieser Aktivitäten. Enthält, wenn vorhanden, die Anzahl aller getätigten HTTP- Requests (GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS) Enthält die zurückgegebenen Response-Codes samt deren Häufigkeit. Enthält die Content-Types, beispielsweise application/binary, zusammen mit deren Anzahl. Tabelle 7: AndroSOM: Traffic Features 4.3 Nachverarbeitung und Generierung der Datensätze Wie bereits zuvor erwähnt, erfolgt die Generierung der Datensätze in zwei Schritten. Zuerst werden alle Features aus der statischen und dynamischen Analyse zusammengetragen und zusammen mit Metadaten in eine MongoDB Collection geschrieben. Listing 7: Nachverarbeitung: Features mit Metadaten 1 { 2 "_id": " static_externalmethodcalls org/ xmlpull/ v1/ XmlPullParser -> setinput", 3 " inmalwarecount": NumberInt (297), 4 " inbenigncount": NumberInt (833), 5 " maxvalue": NumberInt (42), 6 }, { 7 "_id": " traffic_responsecodes 304", 8 " inmalwarecount": NumberInt (33), 9 " inbenigncount": NumberInt (127), 10 " maxvalue": , 11 } Wie in Listing 7 zu sehen ist, wird für jedes Feature eine eindeutiger Identifikator (_id) generiert. Metadaten, die dazu abgespeichert werden, sind der inmalwarecount, welcher angibt in wie vielen Schadsoftware-Samples dieses Feature gefunden wurde, der inbenigncount, welcher angibt, in wie vielen legitimen Applikationen dieses Feature gefunden wurde und der Maximal-Wert, der beschreibt, wie häufig dieses Feature maximal in einem Sample, in dem es enthalten war, gefunden wurden. Da es bei der Laufzeit der dynamischen Analyse immer geringfügige Abweichungen gibt, wird dieser Maximal-Wert auf 60 Sekunden normalisiert.

86 4 ANDROSOM FEATURE MINER 77 Im zweiten Schritt werden mit Hilfe der zuvor generierten Feature-Collection Samplespezifische Feature Vektoren erstellt. Diese werden anschließend in verschiedene Datensätze geschrieben. Dabei kann über das GUI für die verschiedenen Features ein Filter gesetzt werden, welcher angibt, in wie vielen Samples ein bestimmtes Feature vorhanden sein muss, um in die Datensätze aufgenommen zu werden. Alle Gewichte der generierten Feature-Vektoren, sofern es sich nicht um boolesche Werte handelt, werden, wie in Listing 8 zu sehen ist, für die spätere Verwendung in MatLab auf den Wertebereich [0, 1] normalisiert. Listing 8: AndroSOM Feature-Vektor , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, , 0, 0, , , , 0, 0, 0, 0, , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,..., 0, 0, 0, 0, 0, 0, 0, , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, , 0, 0, 0, 0, 0, 0, 0, 0, , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0 Listing 8 zeigt, wie ein Feature-Vektor aufgebaut sein kann. Dieser kann beispielsweise Daten aus der statischen Analyse (gelb markiert), aus der dynamischen Analyse von System-Aufrufen (grün markiert) und aus der Analyse des Netzwerk-Verkehres während der dynamischen Analyse (blau markiert) enthalten. Nachdem die verschiedenen Feature-Vektoren für alle Samples erzeugt wurden, können daraus die Datensätze für MatLab generiert werden.

87 5 RESULTATE 78 5 Resultate In diesem Kapitel werden anfangs die verwendeten APK-Datensätze beschrieben, sowie Einblicke in diese gegeben. Anschließend werden die Messmethode beschrieben und Messergebnisse für verschiedene CP-ANN-Modelle präsentiert. Abschließend werden die Top- 10 CP-ANN-Modelle identifiziert, welche einer vierfachen Kreuz-Validierung unterzogen werden. Damit soll deren Leistung (Accuracy) in Hinblick auf zuvor unbekannte Samples gezeigt werden. 5.1 Applikations-Datensätze Für diese Arbeit wurden sowohl schädliche als auch legitime Applikationen verwendet. Diese stammen aus bekannten Schadsoftware-Sammlungen, beziehungsweise wurden sie vom Autor dieser Arbeit aus dem offiziellen Google Play Store manuell heruntergeladen. Schadsoftware Die im Zuge dieser Arbeit verwendeten Android Schadsoftware-Samples stammen aus dem Android Malware Genome Project (Zhou und Jiang 2012), sowie von Contagio Mobile 22. Das Android Malware Genome Project entstand im Zuge der Arbeit von Zhou and Jiang und beinhaltet 1260 Schadsoftware-Samples, die in 49 Familien eingeteilt werden können. Dieser Datensatz wurde zwischen August 2010 und Oktober 2011 aufgebaut. Die Contagio Mobile Datenbank beinhaltet rund 380 Schadsoftware Samples, die zwischen September 2012 und September 2014 gesammelt wurden. Insgesamt konnten mit Hilfe von VirusTotal 78 verschiedene Schadsoftware-Familien identifiziert werden. Legitime Applikationen Die legitimen Applikationen wurden zwischen dem 16. und 20. Februar 2014 vom Autor dieser Arbeit manuell aus dem offiziellen Google Play Store heruntergeladen. Dabei handelt es sich jeweils um die Top 60 Applikationen (auf Österreich bezogen) aus 34 Kategorien. Diese teilen sich auf 26 allgemeine und 8 Kategorien für Spiele auf. Insgesamt wurden dabei 2040 Applikationen gesammelt, wobei manche in mehreren Kategorien enthalten waren. Samples, die öfter als ein Mal vorhanden sind, werden nach der ersten statischen beziehungsweise dynamischen Analyse nicht mehr weiter berücksichtigt. Schadsoftware Legitime Applikationen ursprünglich gefiltert Tabelle 8: Ursprüngliche und gefilterte Samples

88 5 RESULTATE 79 Tabelle 8 zeigt die Anzahl von gesammelten Applikationen im Vergleich mit der Anzahl später tatsächlich verwendeter Samples. Herausgefiltert wurden mehrfach enthaltene Applikationen sowie Samples, die nicht eindeutig genug durch VirusTotal als Schadsoftware beziehungsweise legitime Applikationen klassifiziert werden konnten. Auch einige mutmaßlich legitime Applikationen aus dem offiziellen Google Play Store wurden entfernt, da sie zumindest bei einigen der 50 Viren-Scanner, die von VirusTotal unterstützt werden, als Schadsoftware identifiziert wurden. Von VirusTotal als Schadsoftware erkannte Applikationen Bei VirusTotal werden Samples mit 50 Viren-Scannern auf Schadsoftware überprüft. Nicht alle Viren-Scanner erkennen dieselben Samples, was Abbildung 23 verdeutlichen soll. Abbildung 23: Als Schadsoftware erkannte Applikationen Wie in Abbildung 23 zu sehen ist, wurden 215 Samples von nur einem beziehungsweise 100 Samples von genau zwei Viren-Scannern erkannt. Dabei handelt es sich vermutlich um False Positives (siehe Tabelle 10). Danach bewegt sich die Erkennungs-Rate zwischen 0 und 20 Samples, die von einer bestimmten Anzahl an Viren-Scannern als Schadsoftware klassifiziert wurden. Die Anzahl an als schädlich klassifizierten Samples steigt erst ab 32 positiven VirusTotal-Treffern merklich an und erreicht bei 39 verschiedenen Viren- Scannern, die 293 Samples als Schadsoftware identifiziert haben, ihren Höhepunkt. Keine der Applikationen wurde von 47 oder mehr Viren-Scannern erkannt. Auswahl des Schwellenwertes für Schadsoftware Um nicht zu viele Samples aus dem APK-Datensatz zu entfernen, musste ein geeigneter Schwellenwert für die Anzahl an Viren-Scannern festgelegt werden, die nötig sind, um ein Sample eindeutig als schädlich zu klassifizieren. Nur wenn ein Sample diesen Schwellenwert erreicht, wird es in dieser Arbeit als Schadsoftware-Sample weiterverwendet. Legitime Applikationen dürfen hingegen von keinem einzigen Viren-Scanner erkannt werden, um verwendet zu werden. Abbildung 24 zeigt in Abständen von fünf Viren-Scannern, wie viele Samples zusätzlich aus der Wertung fallen, wenn ein bestimmter Schwellenwert gewählt wird.

89 5 RESULTATE 80 Abbildung 24: Schwellenwert für die Klassifizierung als Schadsoftware Einblicke In schädlichen sowie in legitimen Applikationen kommen bestimmte Features (siehe Tabelle 5, 6 und 7) unterschiedlich oft vor. Aus diesem Grund können schädliche von legitimen Samples auch unterschieden werden. Es folgt eine Auflistung der jeweils 25 am häufigsten in Schadsoftware beziehungsweise in legitimen Applikationen gefundenen Features. Statische Analyse Abbildung 25 zeigt eine Auflistung der 25 am häufigsten aus legitimen Applikationen extrahierten Features, die durch statische Analyse gewonnen wurden, im Vergleich zu den 25 am häufigsten in Schadsoftware gefundenen Features aus dieser Analyse-Art. Einige Features, welche möglicherweise auf Schadsoftware hindeuten, wurden rot markiert. Zu sehen ist die Initialisierung von Intents (siehe Kapitel 2.2.6), welche genutzt werden können, um Aktivitäten zu starten, Broadcasts zu senden sowie um Dienste zu starten beziehungsweise mit diesen zu kommunizieren. Schadsoftware kann Intents beispielsweise zum Starten von schädlichen Hintergrund-Diensten nutzen. Auch sehr oft kommen Methoden zum Manipulieren von Zeichenketten vor, welche beispielsweise für einfache Verschleierungs-Techniken (siehe Kapitel 3.2.1) genutzt werden können. Auch die Methode getsystemservice() scheint unter den Top 25 Schadsoftware-Features auf. Über diese Methode kann beispielsweise ein TelephonyManager 23 instantiiert werden, welcher Zugang auf alle Telefonbuch-Daten bieten kann. Die Methode currenttimemillis() könnte beispielsweise genutzt werden, um schädlichen Code erst nach einer bestimmten Laufzeit einer Applikation auszuführen und somit eine dynamische Erkennung in einer Sandbox zu erschweren

90 5 RESULTATE 81 Abbildung 25: Vergleich der am häufigsten gefundenen statischen Features Dynamische Analyse Abbildung 26 zeigt eine Auflistung der 25 am häufigsten aus legitimen Applikationen extrahierten Features, die durch die dynamische Analyse von System-Aufrufen und Datei- Zugriffen gewonnen wurden, im Vergleich zu den 25 am häufigsten in Schadsoftware gefundenen Features. Einige Features, auf die näher eingegangen wird, da diese auf Schadsoftware hindeuten können, wurden rot markiert. Der access System-Aufruf liefert Informationen darüber, ob der aktuelle Prozess über die nötigen Berechtigungen verfügt, die zum Lesen, Schreiben oder Testen, ob eine Datei vorhanden ist, erforderlich sind. Eine Applikation kann damit feststellen, ob sie Zugriff auf System-Dateien oder -Partitionen hat (beispielsweise wenn es sich um ein gerootetes System handelt) und gegebenenfalls weitere Schritte einleiten, um Schaden anzurichten. Der System-Aufruf fcntl64 wird zur Manipulation von Datei-Deskriptoren eingesetzt, vor allem aber um Dateien zu sperren, wenn auf diese beispielsweise gerade schreibend zugegriffen wird. Dieser System-Aufruf sowie read deuten auf erhöhte Lese- beziehungsweise Schreib-Aktivität am Filesystem hin, was für Schadsoftware sprechen kann. Über den System-Aufruf capset können einem Prozess bestimmte Berechtigungen gewährt werden. Der System-Aufruf mount könnte benutzt werden, um die normalerweise schreibgeschützte Android System-Partition mit Schreib-

91 5 RESULTATE 82 zugriff neu einzubinden. Bei ashmem handelt es sich um das Android Shared-Memory Subsystem, durch welches die Binder-IPC umgangen werden kann. Abbildung 26: Vergleich der am häufigsten gefundenen dynamischen Features Netzwerkverkehr Analyse Abbildung 26 zeigt eine Auflistung der 25 am häufigsten aus legitimen Applikationen extrahierten Netzwerkverkehrs-Features, die während der dynamischen Analyse gesammelt wurden, im Vergleich zu den 25 am häufigsten in Schadsoftware gefundenen Features aus der Analyse des Netzwerkverkehrs. Einige Features, welche möglicherweise auf Schadsoftware hindeuten, wurden rot markiert. Auffällig ist hierbei, dass besonders oft der Response-Code 404 zurückgegeben wird. Grund hierfür könnte sein, dass bestimmte Botnetz-Kontroll-Server über die Zeit entdeckt wurden und offline gingen. Die verwendete Schadsoftware kommunizierte auch oft mit Adwo 24, einem chinesischen Werbenetzwerk beziehungsweise adtouchnetwork.net (offline). Legitime Applikationen hingegen verwendeten meist die Google-eigenen Werbenetzwerke DoubleClick 25 und AdMob 26. Auch wird

92 5 RESULTATE 83 oft eine Verbindung auf Port 8080 aufgebaut, was ungewöhnlich erscheint. Ebenfalls unter den Top 25 Features befinden sich vier IP-Adressen, mit denen nur Schadsoftware-Samples Verbindungen aufbauten. Abbildung 27: Vergleich der am häufigsten gefundenen Netzwerkverkehr Features 5.2 Messmethode Um die Messungen auszuwerten, wurde MatLab verwendet. MatLab ist sowohl eine höhere Programmiersprache als auch eine interaktive Entwicklungsumgebung für numerische Berechnungen und Visualisierungen. MatLab kann dabei nicht nur zur Analyse von Daten und zur Algorithmen-Entwicklung, sondern auch zur Erstellung von Modellen und Anwendungen verwendet werden 27. Unter MatLab ist es möglich, aus einzelnen Skripten oder Funktionen sogenannte Toolboxes zu erstellen. Diese sind meist anwendungsorientiert und können beispielsweise alle nötigen Werkzeuge enthalten, um ANNs zu berechnen