Mobilfunkforensik. Autoren: Dr.-Ing. Michael Spreitzenbarth Ben Stock. Friedrich-Alexander-Universität Erlangen-Nürnberg

Transkript

1 Mobilfunkforensik Autoren: Dr.-Ing. Michael Spreitzenbarth Ben Stock Friedrich-Alexander-Universität Erlangen-Nürnberg

2

3 Modul 4 Mobilfunkforensik Studienbrief 1: Das Android-Betriebssystem Studienbrief 2: Mobilfunkforensik auf Basis des Android OS Studienbrief 3: Android-Applikationen Autoren: Dr.-Ing. Michael Spreitzenbarth Ben Stock 1. Auflage Friedrich-Alexander-Universität Erlangen-Nürnberg

4 2015 Dr.-Ing. Michael Spreitzenbarth und Dr.-Ing. Ben Stock Department Informatik Martensstr Erlangen 1. Auflage (01. Oktober 2014) Didaktische und redaktionelle Bearbeitung: Hochschule Albstadt-Sigmaringen Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung der Verfasser unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierung der weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen deshalb darauf hin, dass die Verwendung der männlichen Form explizit als geschlechtsunabhängig verstanden werden soll.

5 Inhaltsverzeichnis Seite 3 Inhaltsverzeichnis Einleitung zu den Studienbriefen 5 I. Abkürzungen derrandsymbole undfarbkodierungen II. Zu denautoren III. Modullehrziele Studienbrief 1 Das Android-Betriebssystem EinführunginAndroid AufbaudesAndroid-Systems Unterschiede zwischen der Java VM und der Dalvik VM Sicherheitsmechanismen desandroid-systems DasAndroid SDK DieAnalyseumgebung Einrichten derbibliotheken unddasos Erstellung eines Android-Emulators Studienbrief 2 Mobilfunkforensik auf Basis des Android OS Einführungindie Mobilfunkforensik Der klassische InvestigativeProcess Der Investigative ProcessfürSmartphones Wo befindensich die interessantendaten? Rooting vs. Recovery Bewegungsprofile Manuelle AnalyseeinesAndroid-Smartphones Das Mobilfunkforensik-Framework ADEL Die Idee hinter dem System Implementierung und SystemWorkflow Mobile-SandboxConnectivity Studienbrief 3 Android-Applikationen Aufbau vonandroid-applikationen Programmierungvon Android-Applikationen Erstelleneines neuenprojektesüber ADT Startender Applikation im Android-Emulator Hinzufügenvon Funktionalität EinführunginRechte undintents Zugriff auf im System gespeicherte Daten Obfuskierung EinführunginObfuskierung Fortgeschrittene Obfuskierungs-Techniken Analysevon Android-Applikationen Bedrohungsszenarien durch schadhafte Applikationen Einführung in das Analysieren von Android-Applikationen Manuelle Analyse des Netzwerkverkehrs einer Android- Applikation Manuelle Analyse des Source-Codes einer Android-Applikation Automatisierte Analysetechniken Automatisierte Analyse einer Android-Applikation Die Mobile-Sandbox Anhang 97 A. Official Android Permissions Verzeichnisse 101 I. Abbildungen II. Beispiele III. Definitionen

6 Seite 4 Inhaltsverzeichnis IV. Exkurse V. Kontrollaufgaben VI. Tabellen VII. Literatur Liste der Lösungen zu den Übungen 107

7 Einleitung zu den Studienbriefen Seite 5 Einleitung zu den Studienbriefen I. Abkürzungen der Randsymbole und Farbkodierungen Beispiel Definition Exkurs Kontrollaufgabe Quelltext Übung B D E K Q Ü

8 Seite 6 Einleitung zu den Studienbriefen II. Zu den Autoren Dr.-Ing. Michael Spreitzenbarth studierte Wirtschaftsinformatik an der Universität Mannheim mit Schwerpunkt in den Bereichen IT-Security und Digitale Forensik. Zwischen 2010 und 2013 arbeitete er als Doktorrand an der Universität Erlangen- Nürnberg. Seine Forschungsthemen lagen in den Bereichen der forensischen Analyse von Smartphones (speziell im Bereich Android) sowie im Bereich der Detektion und automatisierten Analyse von mobilem Schadcode (Malware). Seit April 2013 arbeitet er in einem weltweit operierenden CERT, wo sein Fokus auf der Absicherung mobiler Endgeräte, Incident Handling und der Analyse verdächtiger mobiler Applikationen liegt. In seiner Freizeit arbeitet Michael Spreitzenbarth immer noch im Bereich der Forschung und Entwicklung von Malware-Analyse- und Detektionstechniken sowie digitaler Forensik. Zusätzlich hält er regelmäßig Vorträge und Schulungen zu diesen Themen in der freien Wirtschaft sowie für öffentliche Auftraggeber. Ben Stock absolvierte sein Bachlor-Studium an der Universität Mannheim mit Fokus auf IT-Sicherheit und Forensik. Anschließend wechselte er für einen Master in IT-Security an die Technische Universität Darmstadt, wo er u. a. sein Wissen in dem Bereich Android-Sicherheit vertiefte. Seit 2013 ist er Doktorand am Lehrstuhl für IT-Sicherheits-Infrastrukturen an der Universität Erlangen-Nürnberg. Sein Forschungsthema ist dabei client-seitige Web- Sicherheit. Neben der Forschungstätigkeit betreut er das IT-Sicherheits-Praktikum des Lehrstuhls sowie die Übungen zu den Veranstaltungen Reverse Engineering und Angewandte IT-Sicherheit. Dazu veranstaltet er regelmäßig Workshops, die den Teilnehmern in kurzer Zeit eine ausführliche Einführung in verschiedene Themen der offensiven IT-Sicherheit bietet.

9 Modullehrziele Seite 7 III. Modullehrziele Sie verstehen den Aufbau und die Funktionsweise von Android und Android-Applikationen. Sie kennen nach erfolgreichem Absolvieren dieses Moduls die grundlegenden Methoden zur Vorbereitung einer forensischen Analyse von Android-Mobiltelefonen und können diese auch durchführen. Die Werkzeuge zur Analyse des Telefons sowie dessen Applikationen können sie anwenden und deren Vor- und Nachteile sind Ihnen bekannt. Sie kennen nach Abschluss dieses Moduls die gängigen Tools und Techniken zur Analyse von potentieller Malware. Sie können einfache Applikationen für Android programmieren und analysieren und sind mit der sicherheitskritischen Betrachtung dieser Applikationen vertraut. Sie verstehen die potentiellen Gefahren, die in mobilen Applikationen stecken können und wissen wo sich auf einem Androidbasierten Gerät interessante Daten für eine forensische Untersuchung befinden und wie Sie an diese gelangen können.

10 Seite 8 Einleitung zu den Studienbriefen Modulbeschreibung Modulbezeichnung: Studiengang: Verwendbarkeit: Lehrveranstaltungen und Lehrformen: Mobilfunkforensik Zertifikatsstudium Präsenzveranstaltung: Vorlesung, Übungen, Präsentation der Übungsergebnisse Onlineveranstaltungen: flexible Vertiefung wichtiger Themen, Lernen im Dialog, Fragen zu Übungen Modulverantwortliche(r): Dr.-Ing. Michael Spreitzenbarth Lehrende: Dr.-Ing. Michael Spreitzenbarth und Dr.-Ing. Ben Stock Dauer: 1 Semester Credits: 5 ECTS Studien- und Prüfungsleistungen: Schriftlicher Bericht (1/3) Mündliche Prüfung (2/3) Berechnung der Modulnote: Notwendige Voraussetzungen: Programmierkenntnisse in Python und Java gute Linux-/UNIX-Kenntnisse gute Englischkenntnisse Empfohlene Voraussetzungen: Unterrichts- und Prüfungssprache: Zuordnung des Moduls zu den Fachgebieten des Curriculums: Einordnung ins Fachsemester: Generelle Zielsetzung des Moduls: Arbeitsaufwand bzw. Gesamtworkload: Kenntnisse der forensischen Grundsätze Deutsch Vertiefung des Wissens von forensischen Ermittlern und Sicherheitsanalysten mit Interesse im Bereich mobile Endgeräte Präsenzzeit: 15 h Vorlesungsteil: 5 h Übungsteil: 10 h Eigenstudium: 135 h Durcharbeiten der Studienbriefe: 75 h Online Betreuung und Beratung: 10 h Ausarbeiten von Aufgaben: 50 h

11 Modullehrziele Seite 9 Lerninhalt und Niveau: Einführung in Android Aufbau des Android-Systems Unterschiede zwischen der Java-VM und der Dalvik- VM Das Android SDK Einführung in Mobilfunkforenisk für Android Wie kommt man an die wichtigen Daten? Rooting, Recovery und andere Zugriffsstrategien Wo befinden sich die interessanten Daten und welches Aussehen/Format haben sie? Einführung in SQLite Das Mobilfunkforensik-Framework ADEL Aufbau und Analyse von Android-Applikationen Bestandteile einer Android-Applikation (Manifest, Dalvik-Bytecode, Zertifikate, native Bibliotheken usw.) Einführung in das Dekompilieren und Reversen von Android-Applikationen Automatisierte Analysetechniken: Überblick, Einführung und Diskussion statische vs. dynamische Analyse Einführung in die Tools smali, dex2jar und JD-GUI Obfuskierung Einführung in Obfuskierung String-Obfuskierung (XOR, Crypt,...) Junkbytes zum Verwirren der Disassembler Kollision mehrerer Apps zum Verschleiern der Schadfunktion Das Niveau der Lerninhalte liegt gemessen am DQR-Niveau bei 7 (Master)

12 Seite 10 Einleitung zu den Studienbriefen Angestrebte Lernergebnisse: Fachkompetenz: Die Studierenden erwerben fundierte Kenntnisse über den Aufbau des Android und ios Betriebssystems. Sie sind in der Lage Android und ios Mobiltelefone zu analysieren und Spuren auf diesen Geräten zu sichern. Ebenso sind sie in der Lage Applikationen zu analysieren und verdächtiges Verhalten zu identifizieren. Methodenkompetenz: Die Studierenden beherrschen die Arbeitstechnik, mit bekannten Tools und Werkzeugen im Bereich Forensik und Android-Applikations-Analyse umzugehen. Weiter beherrschen sie die Problemlösefähigkeit, ein Android-Programm auf sein Verhalten zu untersuchen. Sozialkompetenz: Durch das gemeinsame Lösen von Aufgaben erlangen die Studierenden die Fähigkeit eigene Handlungsziele mit den Einstellungen und Werten einer Gruppe zu verknüpfen und ihre Teamfähigkeit zu stärken. Häufigkeit des Angebots: Anerkannte Module: Anerkannte anderweitige Lernergebnisse / Lernleistungen: Medienformen: Selbstkompetenz: Die Studierenden erlangen die Fähigkeit in komplexen Situationen zu handeln und eine Lösung für komplexe Probleme zu finden. Wintersemester Keine Keine Studienbriefe in schriftlicher und elektronischer Form Onlinematerial in Lernplattform Übungen und Projekt über Lernplattform Online-Konferenzen, Chat und Forum Präsenzveranstaltung mit Rechner und Beamer Literatur: Siehe Verweise innerhalb der einzelnen Studienbriefe

13 Modullehrziele Seite 11 Einleitung In den letzten Jahren stiegen die Absatzzahlen von Smartphones enorm und der Trend wandelte sich von altmodischen Handys mit nur geringer Funktionalität hin zu leistungsfähigen und funktionsreichen Smartphones. Die Google-Smartphone-Plattform Android ist dabei das beliebteste Betriebssystem geworden und überholte Symbian- und ios-basierte Telefone. Smartphones sind allgegenwärtig und spielen daher eine zunehmend wichtige Rolle für Beweise in forensischen Untersuchungen. Dabei spielt die Wiederherstellung von digitalen Spuren oft eine wesentliche Rolle bei der Prüfung und Klärung der Fakten im Rahmen von Straftaten. Obwohl es bereits einige Werkzeuge und Vorgehensbeschreibungen in diesem Bereich gibt, besteht weiterhin eine starke Nachfrage nach Methoden und Werkzeugen für die forensische Extraktion und Analyse von Daten, die auf Smartphones gespeichert sind. Dieser Bedarf wird durch das schnelle Wachstum und die steigende Diversifikation im Bereich des Mobilfunkmarktes geweckt. Durch die hohe Verbreitungsrate und steigende Popularität werden Smartphones nicht nur bei Straftaten verwendet, sie geraten auch als Angriffsziel zunehmend in den Fokus von Kriminellen. Für das bessere Verständnis der damit verbundenen Bedrohungen für Endnutzer, ist es wichtig, bösartige Software zu analysieren und zu identifizieren. Die exponentiell wachsenden Zahlen der Android-Malware in den vergangenen Jahren verlangen eine Automatisierung des Analyseprozesses, um dem schnell wachsenden Datenaufkommen gerecht zu werden. In diesem Modul werden die Spezifikationen und Besonderheiten von Android-Smartphones beschrieben. Des Weiteren wird auf Möglichkeiten zur forensischen Analyse von Smartphones eingegangen und es wird gezeigt, wie man Bewegungsprofile von Smartphone-Nutzern generieren und anhand dieser Profile den Aufenthaltsort eines Smartphones über einen gewissen Zeitraum in der Vergangenheit nachweisen kann. Dieser Schritt könnte vor allem bei der Aufklärung von Straftaten, bei denen es um eine spezifische Zeit-Ort- Kombination geht, eine wichtige Rolle spielen. Ein Beispiel für eine solche Fragestellung ist: Befand sich der Verdächtige zum Zeitpunkt des Einbruchs in der Nähe der ausgeraubten Villa? Im Zusammenhang mit der Aufklärung von Straftaten kommt es auch immer wieder zu dem Punkt, an dem ein Ermittler sich die Frage stellen muss: Wurde die Aktion auf dem Smartphone durch den Eigentümer ausgeführt, oder war das Mobiltelefon manipuliert? Um bei der Beantwortung dieser Frage Hilfestellung zu geben, wird im dritten Studienbrief der Fokus auf die Analyse von mobilem Schadcode gelegt. Rückmeldungen Trotz zahlreicher Verbesserungsvorschläge verschiedener Personen (vor Allem auch der Studierenden aus dem ersten Durchlauf) enthält dieser Text sicherlich noch Fehler, seien sie inhaltlich, konzeptionell, sprachlich oder stilistisch. Die Herausgeber freuen sich deshalb über jede konstruktive Rückmeldung, die wir in zukünftigen Versionen unseres Textes gerne berücksichtigen. Dr.-Ing. Michael Spreitzenbarth Ben Stock

14

15 Studienbrief 1 Das Android-Betriebssystem Seite 13 Studienbrief 1 Das Android-Betriebssystem Das Android OS, das speziell für die Verwendung auf Smartphones und Tablet- PCs designed wurde, findet in letzter Zeit aber auch immer mehr Verwendung auf Set-Top-Boxen, TVs oder als Car-Entertainment-System. Die Basis des Betriebssystems wird von der Open Handset Alliance unter der Führung von Google entwickelt und ist vollständig open-source, lediglich die Anpassungen von Google (eigene Apps wie z. B. Google-Maps und zugehörige Bibliotheken) sind nicht in ihrem Quellcode verfügbar. In den folgenden Abschnitten wird auf die wichtigsten Eigenschaften und das Grundgerüst der Android-Plattform eingegangen. Dazu zählt neben einem Rückblick über die Entwicklung des Systems auch ein Blick auf die wichtigsten Komponenten wie die Dalvik VM und das Android SDK, welches im weiteren Verlauf der Studienbriefe immer wieder Anwendung findet. Ein wichtiges Augenmerk wird dabei auch auf die Sicherheitsmechanismen gelegt, die in Android implementiert sind. 1.1 Einführung in Android Zu Beginn der Einführung in die Android-Plattform wird im Rahmen dieses Abschnitts die bisherige Entwicklung der verschiedenen Android-Versionen aufgezeigt. Die gesamte zeitliche Entwicklung der Plattform, speziell deren Haupt- Versionen, ist in Tabelle 1.1 zusammen mit ihren Versionsnummern, Codenamen und Erscheinungsdaten dargestellt. Seit der Version 1.5 haben die Haupt-Versionen immer den Namen von populären US-Süßigkeiten. Dies hat sich erst durch die Kooperation mit Nestlé in Version 4.4 und dem Codenamen KitKat geändert, Google blieb zwar bei den Süßigkeiten, wechselte jedoch auf den europäischen Markt. Version Codename Erscheinungsdatum Verwendung /2008 s 1.5 Cupcake 04/2009 s 1.6 Donut 09/2009 s 2.0 Eclair 10/2009 s 2.1 Eclair 01/2010 s 2.2 Froyo 05/2010 s 2.3 Gingerbread 12/2010 s 3.0 Honeycomb 02/2011 t 4.0 Ice Cream Sandwich 10/2011 s, t 4.1 Jelly Bean 06/2012 s, t 4.2 Jelly Bean 11/2012 s, t 4.3 Jelly Bean 07/2013 s, t 4.4 KitKat 10/2013 s, t 4.5 Lollipop 10/2014 s, t Tabelle 1.1: Liste der Android-OS-Versionen und deren Erscheinungsdatum seit der ersten offiziellen Veröffentlichung in2008.(s=smartphone, t=tablet-pc) Die Erfolgsgeschichte von Android began Ende 2008 mit der ersten offiziellen, jedoch namenlosen Version 1.0. Diese Version wurde speziell für Smartphones entwickelt und enthielt die ersten Apps für Gmail, GTalk, Youtube und Google- Maps, aber auch die Fähigkeit, SMS-Nachrichten zu empfangen bzw. zu versenden und natürlich zu telefonieren. Das erste Telefon, welches mit diesem OS ausgestattet war, war das legendäre Google G1 (siehe Abbildung 1.1), welches in Deutschland erstmalig im Februar 2009 bei T-Mobile erschien. Nur ein knappes halbes Jahr später veröffentlichte Google die Version 1.5 unter dem Namen Cupcake. Diese Version bot mehrheitlich Änderungen am Design der Oberfläche, aber auch Neuerungen wie die bekannten Widgets und die Möglichkeit, Videos aufzunehmen wurden hinzugefügt. Version 1.6 fügte im Anschluss noch die Steuerung per Gesten sowie die Optimierung für höhere Displayauflösungen hinzu, welche dafür sorgten, dass auch vermehrt Hersteller wie Motorola und HTC anfingen, Telefone mit Android OS auszuliefern.

16 Seite 14 Studienbrief 1 Das Android-Betriebssystem Abb. 1.1: Erstes Android Smartphone: Google G1. Mit dem ersten Major-Update auf Version 2.0 Eclair kamen eine hohe Anzahl an geschlossenen Sicherheitslücken, neue Nutzerfeatures sowie der Support für MS- Exchange und Bluetooth 2.1 hinzu. Im kurz darauf folgenden Update auf Version 2.1 wurde nur die API für die inzwischen zahlreichen Entwicklern von Apps für das Android OS angepasst und erweitert. Knapp 4 Monate später veröffentlichte Google Froyo. In dieser Version wurde besonderen Wert auf Performance des OS gelegt und zudem die Fähigkeiten eines mobilen Hotspots und des Remote-Wipes (sobald das Telefon mit einem MS-Exchange-Account verbunden war) hinzugefügt. Die wohl wichtigsten Änderungen für den Großteil der Nutzer war jedoch, dass sie nun auch Apps auf der SD-Karte installieren konnten und dass es nun eine neue Generation Smartphones mit mehr als 256MB an RAM gab (dies war in den vorangegangenen Versionen des Android OS das Maximum, welches verwendet werden konnte). Gingerbread war im Bezug auf die Änderungen am Android-System wohl eines der gravierendsten Versionsupdates. In dieser Version wurde der JIT-Compiler verbessert, es wurde Garbage-Collection in der Dalvik VM eingeführt, Apps konnten nun auch in C geschriebene Bibliotheken nachladen und es wurde NFC als neuer Kommunikationskanal hinzugefügt. Der jedoch größte Unterschied war, dass man beim Dateisystem von YAFFS2 auf Ext4 umgesattelt hat. Diese Version von Android war über viele Jahre eine der am häufigsten verwendeten Version von Android; so war ihr Anteil Ende 2012 immer noch bei über 60 % aller im Feld befindlicher Android-Smartphones und selbst aktuell liegt ihr Anteil noch bei knapp über 16 % (siehe Tabelle 1.2). Tabelle 1.2: Verbreitung der Android-Versionen (zugrunde liegende Daten wurden in einer 7-tägigen Periode mit demendeam1.mai 2014 gesammelt)[android Developers, 2014] Version Codename API Distribution 2.2 Froyo 8 1,0 % 2.3 Gingerbread 10 16,2 % 3.x Honeycomb 13 0,1 % 4.0 Ice Cream Sandwich 15 13,4 % 4.1.x Jelly Bean 16 33,5 % 4.2.x Jelly Bean 17 18,8 % 4.3.x Jelly Bean 18 8,5 % 4.4 KitKat 19 8,5 % Nur kurze Zeit später hat Google Version 3.0 des Android-Systems veröffentlicht: Honeycomb. Diese Version war speziell für die Verwendung auf Tablet-PCs gedacht. Die meisten Tablet-PCs verwendeten jedoch modifizierte Versionen der weit verbreiteten Gingerbread- und Froyo-Systeme; Honeycomb wurde somit nur sehr wenig in der freien Wildbahn des Android-Ökosystems gefunden. Mit dem

17 1.2 Aufbau des Android-Systems Seite 15 Update auf Android 4.0 hat Google dann schließlich die Systeme für Smartphones und Tablets verschmolzen. Neben den üblichen Sicherheitsupdates, welche bei Android nur mit System-Updates eingespielt werden, wurde in Android 4.0 auch erstmal Full-Disk-Encryption (FDE) mittels dm-crypt in der breiten Masse der Android-Hardware eingeführt. Daneben wurde das Benutzerinterface (UI) komplett überarbeitet, neue NFC-Funktionen sowie Direct-WiFi implementiert und schlussendlich noch weitere Möglichkeiten eingeführt, wie man das Display sperren kann. Darunter auch die zweifelhafte Variante der Gesichtserkennung, bei der man als Nutzer in die Frontkamera schauen muss und das erzeugte Bild dann mit einem bereits gespeicherten Bild verglichen wird. Eines der auch heute noch am weitesten verbreiteten Systeme ist Jelly Bean mit seinen unterschiedlichen Versionsnummern (von 4.1.x bis 4.3.x). In diesen Versionen wurden die Verschlüsselung von Apps sowie das sogenannte Smart-Update (es werden keine kompletten Apps mehr beim Update ersetzt, sondern nur geänderte Komponenten, die dann lokal auf dem Gerät mit der alten App verschmolzen werden) eingeführt. Die neue Verschlüsselung der Apps bewirkt, dass bezahlte Apps vor dem Download mit einem geräteabhängigen Schlüssel verschlüsselt werden, so dass sie nicht auf anderen Geräten (die nicht für die App bezahlt haben) installiert werden können. Die aktuellste Version des Android-Systems KitKat bietet im Wesentlichen Sicherheitsupdates, ein deutliches Plus an Performance und eine Optimierung für Cloud-Dienste. Mit ihr versucht Google auch ältere Geräte zu versorgen, um die starke Fragmentierung des Ökosystems zu verringern. Dies ist bisher aber leider nicht gelungen, da viele Hersteller die neue Version noch nicht auf ihre Geräte portiert haben. Damit sind wir auch bei einer der größten Nachteile der Android-Welt: Sicherheitsupdates werden nur mit neuen Android-Versionen bereitgestellt und diese müssen von den Herstellern zuerst an die vorhandenen Geräte angepasst werden, bevor sie an den Nutzer ausgerollt werden können. Selbst wenn also alle Hersteller immer und umgehend die von Google bereitgestellten Updates sofort anpassen und verteilen würden, würden Sicherheitsupdates im Schnitt nur alle zwei Monate bereitgestellt werden. Diese Zeitspanne klingt im ersten Moment noch recht akzeptabel, schaut man aber die Realität an, so sieht man häufig, dass Updates gar nicht ausgerollt werden oder mit mehreren Monaten Verzug, wodurch eine große Anzahl an Geräten gegen Angriffe ungeschützt sind. Wie man in diesem Abschnitt gesehen hat, ist das Android-System speziell für Smartphones und Tablet-PCs designed worden und zeigt hier auch seine Stärken. Das System als solches basiert auf einem Linux-Kernel und wurde für die Advanced-RISC-Machines (ARM) Architektur optimiert. In den folgenden Abschnitten werden diese Eigenheiten und die internen Strukturen näher erläutert. Kontrollaufgabe 1.1: Sicherheitsprobleme bei Android Worin liegt eines der größten Probleme in der Android-Welt, wenn es um das Thema Sicherheit geht? K 1.2 Aufbau des Android-Systems Die Android-Architektur kann in vier verschiedene Schichten unterteilt werden: Basis der Architektur ist der Linux-Kernel, darüber liegt eine kombinierte Schicht aus Systembibliotheken und der eigentlichen Android-Laufzeitumgebung, das

18 Seite 16 Studienbrief 1 Das Android-Betriebssystem Applikations-Framework und als oberste Ebene die eigentlichen Applikationen (für eine grafische Darstellung siehe Abbildung 1.2). Jede dieser vier Schichten stellt spezielle Interfaces und Systemressourcen für die darüberliegende Schicht zur Verfügung, so dass eine Interaktion zwischen den einzelnen Schichten ermöglicht wird. Abb. 1.2: Übersicht der Architektur des Android- Betriebssystems[Android Developers, a]. Browser Contacts Applications Phone etc. Activity Manager Window Manager Application Framework Resource Manager Manager Package Manager Telephony Manager Content Providers Location Manager View System Libraries Android Runtime SGL SSL libc Core Libraries Surface Manager Media Framework SQLite Dalvik Virtual Machine OpenGL / ES FreeType WebKit Display Driver Keypad Driver Camera Driver Wi-Fi Driver Linux Kernel Flash Memory Driver Audio Drivers Binder IPC Driver Power Management Wie im vorherigen Abschnitt bereits beschrieben bildet der Linux-Kernel in Version 2.6.x die Basis des Android-Systems. Dieser wurde um spezielle Module erweitert, um die Hardware der Android-Geräte zu unterstützen. Zusätzlich dazu wird der Kernel für die Verwaltung der laufenden Prozesse sowie des Speichers verwendet und stellt einige der Sicherheitsmechanismen bereit, welche in Android implementiert sind. Prozesse mit ihrem zugehörigen Identifier (PID) sind eines der bedeutendsten Konzepte des Linux-Kernels. Neben dieser PID speichert der Kernel weitere wichtige Informationen über laufende Prozesse wie z. B. den Prozessstatus, den Threat, in dem der Prozess läuft und welche Dateien verwendet werden (eine vollständige Liste stellt der Linux-Quellcode [Linux Kernel Organization Inc., 2012] bereit). Diese Daten werden in einer gesonderten Struktur task_struct abgelegt. Die PID ist im weiteren Zusammenhang sehr wichtig, da anhand von ihr während der dynamischen Analyse die Operationen den eigenen Apps zugeordnet werden können (mehr dazu in Abschnitt 3.4.7). In der darüberliegenden Schicht befinden sich sie Systembibliotheken und die eigentliche Android-Laufzeitumgebung. Diese Bibliotheken sind in C bzw. C++ geschrieben und werden sowohl von dem System selbst als auch von allen installierten Apps verwendet. Die Android-Laufzeitumgebung enthält die Dalvik Virtual Machine (DVM) sowie die wichtigsten Java-Bibliotheken. Die DVM- und die Java-Bibliotheken wurden speziell an die Vorgaben eines mobilen Betriebssystems geringer Stromverbrauch und geringe Rechenleistung angepasst. Die hierdurch entstandenen Unterschiede werden genauer in Abschnitt 1.3 beschrieben. Die nächste Ebene stellt das Application Programming Interface (API) bereit. Diese Ebene ist eine Art Übersetzungsschicht; sie stellt eine hohe Anzahl an geräteabhängigen Schnittstellen zur Verfügung, die es einem Entwickler erlauben, auf alle

19 1.3 Unterschiede zwischen der Java VM und der Dalvik VM Seite 17 Features des Telefons zugreifen zu können, ohne dass er hierfür tiefere Kenntnisse der einzelnen Komponenten benötigt. Darüber liegen schlussendlich die eigentlichen Applikationen. Jede dieser installierten Applikationen ist zum großen Teil in Java geschrieben (mit optionalen eigenen Bibliotheken) und wird zur Laufzeit in einer eigenen DVM ausgeführt. Ende 2013 gab es im offiziellen Google Play Store knapp 1 Million dieser Applikationen (Apps). Exkurs 1.1: Architektur des ARM-CPU Die Architektur des ARM-CPUs ist sehr ähnlich zu der des Reduced Instruction Set Computer (RISC). Eine typische Eigenschaft des ARM-CPU besteht darin, dass Datenverarbeitung ausschließlich in Registern geschieht und nicht direkt auf Speicherstellen. Jedes dieser Register kann 32 bit an Daten speichern; abhängig vom Operationsmodus, gibt es ein Subset von 16 dieser Register, welche verwendet werden können. Die neueren Android- Smartphones verwenden einen ARMv7-CPU im Gegensatz zu dem ARMv5, welcher in älteren Geräten Verwendung findet. Der neuere ARMv7 bietet Verbesserungen durch die Beschleunigung in der Verarbeitung von Java (Jazelle) und eine eigene TrustZone (vergleiche Abbildung 1.3). E Abb. 1.3: ARM-CPU- Übersicht[ARM Ltd., 2012]. Kontrollaufgabe 1.2: PID Was ist eine PID und warum ist sie so wichtig? K 1.3 Unterschiede zwischen der Java VM und der Dalvik VM Android-Applikationen sind großteils in Java programmiert und werden in den Versionen 1.x bis 4.4.x in der Dalvik Virtual Machine (DVM) ausgeführt, welche sich in wesentlichen Punkten von der bekannten Java Virtual Machine (JVM) unterscheidet. Die DVM wurde von Google entwickelt und ist speziell auf die Eigenschaften von mobilen Betriebssystemen und deren Hardware hin optimiert. Dabei wird der herkömmliche Java-Bytecode in das dex-format überführt, indem die Java.class-Dateien mittels dx in Dalvik-Bytecode übersetzt werden. Um Android- Applikationen zu analysieren, ist es nötig, den Dalvik-Bytecode und dessen Format zu verstehen, daher werden im Folgenden die wesentlichen Unterschiede der beiden Bytecodes dargestellt (siehe auch Wiliam Enck et al. [Enck et al., 2011]):

20 Seite 18 Studienbrief 1 Das Android-Betriebssystem Abb. 1.4: Compilation process for Android applications [Enck et al., 2011]. Java Compiler class1.class Constant Pool Class Info Data dx class2.class Constant Pool Class Info Data classes.dex Header Constant Pool Notiz Notiz Java Source Code... classn.class Constant Pool Class Info Data Data Applikations-Architektur: Der JVM-Bytecode besteht aus mehreren.class- Dateien (jede davon beinhaltet eine Java Klasse). Während der Ausführung lädt die JVM dynamisch den Bytecode der verwendeten Klassen aus den zugehörigen.class Dateien während bei der DVM der gesamte Bytecode aller verwendeten Klassen in einer einzigen.dex-datei zusammengeführt ist. Abbildung 1.4 zeigt den Prozess, wie diese Datei erzeugt wird. Nachdem der Java-Compiler den Java-Bytecode erzeugt hat, löscht der Dalvik-Compiler dx die.class-dateien, kompiliert deren Inhalt zu Dalvik-Bytecode und fügt sie in einer.dex-datei neu zusammen. Dieser Prozess beinhaltet die Übersetzung sowie Neuordnung und Interpretation der Basiselemente einer Applikation (Konstanten-Bereich, Klassendefinitionen und Datensegmente). Der Konstanten-Bereich beschreibt sämtliche in der Applikation vorhandenen Konstanten inklusive Referenzen und Methodennamen. Die Klassendefinitionen beinhalten unter anderem die Klassennamen und Zugriffsrechte. Der eigentliche Code einer Applikation wird im Datensegment abgelegt, welches somit den Funktionscode, welcher später von der VM ausgeführt wird, wie auch alle dazugehörigen Informationen der Klassen und Funktionen (z. B. Anzahl der von der DVM verwendeten Register) beinhaltet. Struktur der Register Im Gegensatz zur JVM (welche stack-basiert ist) ist die DVM register-basiert. Bei der JVM werden die lokalen Variablen in der Variablenliste gespeichert und auf den Stack gepusht, wo sie mit den entsprechenden Opcodes manipuliert werden können. Zusätzlich kann die JVM auch direkt auf dem Stack arbeiten, ohne die Variablen zuvor in die lokale Variablenliste zu speichern. Im Gegensatz dazu werden bei der DVM lokale Variablen den 2 16 verfügbaren Registern zugeordnet, wo sie direkt mit den entsprechenden Opcodes manipuliert werden können, ohne den Stack zu verwenden. Instruction-Set Dalvik besitzt 218 Opcodes welche sich wesentlich von den knapp 200 Opcodes aus dem Java-Umfeld unterscheiden. In Java gibt es z. B. mehrere Dutzend Opcodes, welche dafür zuständig sind, Daten zwischen dem Stack und der lokalen Variablenliste zu transferieren. Aufgrund des Designs der DVM sind diese hier vollkommen überflüssig. Hingegen sind die Opcodes in Dalvik länger als ihre vergleichbaren Instruktionen in Java, da sie ein Quell- und Zielregister beinhalten. Struktur der Konstanten-Bereiche Der JVM-Bytecode besitzt wiederholende Konstanten-Bereiche in allen.class-dateien. Im Gegensatz dazu besitzt der Dalvik-Bytecode nur einen einzigen dieser Bereiche, welcher mittels dx