© gary718, 123RF.com

Android gilt als freies Betriebssystem. Doch wer sein Smartphone an den PC anstöpselt und die enthaltenen Daten auslesen will, stößt an Grenzen. Dieser Artikel zeigt, wie das SDK, Linux-Bordmittel und kommerzielle Software dem Android-Besitzer weiterhelfen.

Für ein freies System gibt sich Android erstaunlich zugeknöpft. Das Linux-Magazin zeigt in diesem Artikel mehrere Varianten, wie der Besitzer trotzdem sein eigenes Gerät untersuchen kann, mit und ohne Jailbreak. Als Testlabor diente dafür ein Forensik-Lehrgang in Mosambik, wo ostafrikanische Linux-Spezialisten (Abbildung 1) mit Bordmitteln auf einem Linux-Server und verschiedenen Android-Telefonen versuchen sollten eine bekannte Android-WLAN-Lücke auszunutzen und virtuelle Androiden mit einem Trojaner zu infizieren und die Testgeräte auszulesen.

Abbildung 1: Bei einem Linux-Forensik-Lehrgang in Mosambik mussten die Teilnehmer auch ihr Wissen rund um die Auswertung sichergestellter Smartphones mit Android unter Beweis stellen.

Die Ergebnisse nützen jedem Admin mit Linux-Kenntnissen, weil die Smartphones – auch als logische Konsequenz der hohen Verbreitung von Android [1] – immer mehr in den Fokus von Angreifern rücken. Der Trend ist ungebrochen: In zunehmendem Maße speichern Anwender schützenswerte Daten auf den Telefonen, so werden auch die Linux-Systeme in den Smartphones immer lohnenswertere Ziele für bösartige Angreifer.

Automatische Anmeldung auch im offenen WLAN

Die folgende Schwachstelle betrifft trotz eines schnellen Patch von Google noch weit über 90 Prozent der Androiden, weil die Provider und Hardwarehersteller die Updates nur zögerlich oder gar nicht an die Kunden weitergeben.

Die zu untersuchende Android-Lücke datiert vom Mai 2011 [2]. Mitarbeiter der Universität Ulm hatten herausgefunden, dass die Smartphones Authentifizierungsdaten gerne unverschlüsselt übers Netz senden, ohne HTTPS und in unverschlüsselten WLANs. Erschwerend kommt hinzu, dass Androiden sich in der Standardeinstellung ohne Rückfrage mit einem einmal gespeicherten WLAN verbinden. Solche Fehler betreffen zwar theoretisch auch Laptops, stellen auf Smartphones jedoch ein deutlich höheres Risiko dar. Den benötigten Accesspoint lieferte Hostapd [3] auf einem an der Eduardo-Mondlane-Universität installierten X2go-Terminalserver von Linux4Afrika ([4], [5]).

Das Listing zeigt die Konfigurationsdatei »hostapd.conf« des Accesspoints:

interface=wlan0
driver=nl80211
ssid=Vodacom
channel=1

Die dort genannte SSID entspricht der eines simulierten ISP-Providers namens Vodacom.

Ein Linux-Server bietet sich als Accesspoint an, die Installation der Netzwerk- und Security-Software gerät zum Kinderspiel. Die Verbindung des Android-Smartphones zeichnet der Admin zum Beispiel mit Tcpdump auf. Auch ein Notebook mit eingebautem WLAN-Interface lässt sich mit Hostapd schnell zu einem Accesspoint umbauen. Damit der Rechner die Anfragen des Smartphones weiterleitet, bedarf es noch der Bridge-Utils. Ein paar Shellkommandos bringen die anfragenden Clients ins Netz:

ifconfig eth0 down
ifconfig wlan0 down
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 wlan0
ifconfig eth0 0.0.0.0 up
ifconfig wlan0 0.0.0.0 up
ifconfig br0 up
dhclient br0

Den kompletten Netzwerk-Traffic zeichnet nun »tcpdump -i br0 -s 0 -w vodacom.cap« auf. Die in einer Datei mitgeschnittenen Datenpakete lassen sich anschließend mit Wireshark betrachten und vergleichen. In der Schulung wurde dabei schnell klar, dass alle getesteten Smartphones für den unter [6] gezeigten Angriffsvektor zugänglich waren – die Androiden versandten ihre Authentifizierungs-Tokens freimütig unverschlüsselt.

Problemfall YAFFS

Was kann ein Besitzer tun, wenn er vermutet Opfer eines Angriffs geworden zu sein? Datenforensiker besitzen in der Regel einen gut ausgestatteten Koffer mit Adapterkabeln für alle Geräte, die auch nur irgendwie zum Telefonieren dienen. Doch bei Android hilft das beste Equipment nicht weiter, weil das von Google verwendete Dateisystem YAFFS (Yet Another Flash File System, [7]) die meisten Anbieter der Auswertungssoftware vor größere Probleme stellt.

Der Linux-Freak nimmt auf der Suche nach einem Treiber meist zuerst Fuse [8] ins Visier. Diese Treiber beeindrucken im Gegensatz zu den Kernel-basierten zwar nicht mit Performance, für die Analyse reichen sie aber allemal. Aber obwohl YAFFS2 derzeit bei fast allen Android-Geräten für den internen Flashspeicher zum Einsatz kommt und als Open-Source-Projekt vorliegt, erweist sich die Treibersuche überraschenderweise als echtes Problem. Es ist also gut, dass künftige Android-Versionen auf Ext 4 wechseln werden.

Alternative Lösungen sind deshalb angesagt, um den Zugriff auf den internen Smartphone-Speicher zu erhalten. Der Kasten “Hands on YAFFS” zeigt, wie Ubuntu 10.10 immerhin bedingt YAFFS-tauglich wird. Das auf der Bücherseite in diesem Magazin beschriebene Buch “Android Forensics” von Andrew Hoog [9] liefert ebenfalls wertvolle Hilfe: Es zeigt, dass ein Software Development Kit nicht nur als Werkzeug für Programmierer, sondern auch für andere Interessierte wichtige Unterstützung bietet.

tar xvzf yaffs2.tar.gz
cd yaffs2
make
mkdir /media/yaffs
modprobe mtd
modprobe mtdblock
insmod yaffs2.ko
lsmod
Module                  Size  Used by
yaffs2                 92683  0
mtdblock                3039  0
mtd_blkdevs             5755  1 mtdblock
mtd                    18877  3 yaffs2,mtd_blkdevs
[...]

modprobe nandsim first_id_byte=0x20 second_id_byte=0xa2 third_id_byte=0x00 fourth_id_byte=0x15

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 04000000 00020000 "NAND simulator partition 0"

nanddump -a /dev/mtd0ro | xxd | less
0000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
[...]

mount -t yaffs2 /dev/mtdblock0 /media/yaffs

0000000: 0100 0000 0100 0000 ffff 7465 7374 6669  ..........testfi
0000010: 6c65 2e74 7874 0000 0000 0000 0000 0000  le.txt..........
[...]

Nicht nur für Programmierer: Das Android-SDK

Für die Analyse mit dem Android-SDK standen den Kursteilnehmern in Mosambiks Hauptstadt Maputo drei unterschiedliche Google-Smartphones zur Verfügung, von denen sich nur das HTC Desire HD einem Jailbreak standhaft widersetzt hatte:

• HTC Desire HD (Android 2.3.3, nicht gerootet)
• HTC Desire Z (2.2.1, gerootet)
• LG-P350 (2.2.1, gerootet)

Die Installation des Android-SDK auf den Linux-Rechnern der Teilnehmer gestaltet sich recht einfach via Download [10] und Entpacken am besten nach »/opt« . Die im Folgenden vorgestellten Programme »android« , »abd« und »ddms« stehen nach der Installation leider in zwei verschiedenen Unterverzeichnissen.

Um sie von überall auf der Kommandozeile starten zu können, nimmt der folgende Befehl in der Datei »/etc/bash.bashrc« (oder in der »~/bash.bashrc« des Users) die beiden SDK-Verzeichnisse in die Umgebungsvariablen für die Pfadsuche auf:

export PATH=$PATH:/opt/android-sdk-linux_x86/tools
export PATH=$PATH:/opt/android-sdk-linux_x86/platform-tools

Vor dem ersten Start sind noch die Udev-USB-Profile zu ergänzen, damit später die Verbindung zu den Smartphones klappt. Die Hersteller-Informationen zum Erstellen einer Datei namens »51-android.rules« sind unter [11] detailliert beschrieben. Wer die Datei nicht manuell anlegen möchte, kopiert sie einfach aus der DELUG-DVD oder vom Listingsserver des Linux-Magazins [12] nach »/etc/udev/rules.d/« .

Wer im SDK unter »Available Packages« mindestens eine Plattform aus dem Android-Repository installiert hat, kann mit dem Tool »android« virtuelle Systeme erstellen. Das Angebot, gleich alle verfügbaren Plattformen auszuwählen, dürfte für die von deutschen Bandbreiten verwöhnten Leser meist als Default dienen, im schlecht angebundenen Ostafrika verwarfen die Teilnehmer des Trainings diese Idee jedoch schnell und beschränkten sich auf ein einzelnes SDK.

Ein eigenes Android

Nach der Installation legt der Anwender ein erstes Virtual Device an und vergibt einen Namen für das Gastsystem, wählt die gewünschte Android-Version (Abbildung 2) und einige weitere, meist selbsterklärende Parameter. Jetzt steht ihm ein virtuelles Software-Android für einige Tests zur Verfügung (Abbildung 3). Hat der PC Internetzugang, dann geht auch das virtuelle Android-Image sofort online. Schon damit eignet sich solch ein System hervorragend zur Malware-Analyse: »lsof -i -n -P« zeigt die Verbindung, über die sich Host und Gast unterhalten:

emulator- 8961 root 20r IPv4 578071520t0 TCP 127.0.0.1:5555 (LISTEN)
emulator- 8961 root 21r IPv4 578071530t0 TCP 127.0.0.1:5554 (LISTEN)

Abbildung 2: Im SDK wählt der Anwender die Android-Version.

Wer beispielsweise den HTTP-Traffic aufzeichnen will, geht einfach über die IP-Adresse des Hostsystems »tcpdump -i eth0 -s 0 -w sdk.cap port 80« . Auf Browser-Aktivitäten sollte er dabei allerdings verzichten, die würden ebenfalls aufgezeichnet. Alternativ dazu bietet das SDK die Möglichkeit, einen dedizierten Proxy zu verwenden.

Fast Race mit Golddream

Einen aktuellen Android-Trojaner beschreibt [13]: Golddream.A verbreitet sich über das Spiel “Fast Race” und protokolliert unter anderem alle ein- und ausgehenden Gespräche in einer Datei namens »ziphonecalls.txt« auf dem internen Speicher des Handys. Allein deren Anwesenheit ist ein deutliches Signal für ein kompromittiertes Gerät. [13] zeigt den Trojaner in Aktion auf zwei virtuellen Androiden und beschreibt seine Arbeitsweise im Detail. Das Spiel ist im Screenshot zwar ausgeblendet, die Websuche nach der App ist aber immer noch erfolgreich.

Abbildung 3: Das virtuelle Android zeigt die Website des Linux-Magazins.

Fast Race auf virtuellen Androids zu installieren ermöglicht es, wertvolle eigene Erfahrungen zu sammeln, ohne sich in Gefahr zu begeben. Sowohl der Netzwerkverkehr als auch die logische Auswertung des Dateisystems zu Übungszwecken lassen sich so nachvollziehen. »tcptrace« zeigt die erzeugten Verbindungen, die das SDK von Android über die private IP-Adresse (192.168.0.2) des Hostsystems an das Gateway weiterreicht (Listing 1). Der Besuch der Webseite des Linux-Magazins (Abbildung 3) liefert dabei beispielsweise folgende Uniq-IPs:

01: 1:  192.168.0.2:59796  -  209.85.148.105:80  (a2b)    54>    28<   (complete)
02: 2:  192.168.0.2:39885  -  80.237.227.140:80  (c2d)    48>    57<   (complete)
03: 3:  192.168.0.2:56801  -  62.146.124.44:80   (e2f)     5>     5<   (complete)
04: 4:  192.168.0.2:49067  -  74.125.79.102:80   (g2h)     8>     5<   (complete)
05: 5:  192.168.0.2:51323  -  193.46.63.130:80   (i2j)     6>     5<   (complete)
06: 6:  192.168.0.2:54279  -  80.237.227.187:80  (k2l)    31>    27<   (complete)
07: 7:  192.168.0.2:39890  -  80.237.227.140:80  (m2n)    21>    19<   (complete)
08: 8:  192.168.0.2:54281  -  80.237.227.187:80  (o2p)    24>    13<   (complete)
09: 9:  192.168.0.2:54282  -  80.237.227.187:80  (q2r)     6>     4<   (complete)
10: 10: 192.168.0.2:51968  -  66.220.153.11:80   (s2t)    18>    16<   (complete)
[...]

tcptrace -n /tmp/sdk.cap | awk '{print $4}' | sort -g | uniq | awk -F":" '{print $1}'
62.146.124.44
66.220.153.11[...]

Das Dateisystem des virtuellen Android befindet sich auf dem Host im Homedirectory des Erstellers, und zwar in einem versteckten Verzeichnis namens ».android« . Eine schnelle Überprüfung der Fileheader führt zur Einsicht, dass einige Images vor dem Zugriff besonderer Behandlung bedürfen (Listing 2): Während sich die virtuelle SD-Karte als FAT-32-Image problemlos mounten lässt, sind die Images »cache.img« und »userdate-qemu.img« zunächst nicht mountbar, da sie als YAFFS2-Dateisystem vorliegen. Was der Admin vor dem erfolgreichen Mount unternehmen muss, zeigt der Kasten “Hands on YAFFS”.

01 cache.img:              VMS Alpha executable
02 cache.img.lock:         ASCII text, with no line terminators
03 config.ini:             ASCII text
04 hardware-qemu.ini:      ASCII text
05 hardware-qemu.ini.lock: ASCII text, with no line terminators
06 sdcard.img:             x86 boot sector, code offset 0x5a, OEM-ID
 "MSWIN4.1", sectors/cluster 4, Media descriptor 0xf8, sectors 8388608
 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 16352, reserved3 0x800000,
 serial number 0xfec0e1b, label: "     SDCARD" sdcard.img.lock:        ASCII
 text, with no line terminators userdata.img:           VMS Alpha executable
07 userdata-qemu.img:      VMS Alpha executable
08 userdata-qemu.img.lock: ASCII text, with no line terminators
09 [...]

Dalvik Debug Monitor

Ein virtuelles Interface ist zwar bereits sehr gut für erste Tests geeignet, spannender ist meist die Verbindung mit einem physikalischen Device. Dafür bringt das SDK den Dalvik Debug Monitor »ddms« mit (Abbildung 4). Alle drei Testkandidaten reicht der Ubuntu-Test-PC erfolgreich über die USB-Verbindung an den Debugger durch, wenn der USB-Debug-Modus des Smartphones aktiviert ist.

Abbildung 4: Dalvik Debug Monitor hat die drei Testgeräte von HTC und LQ erfolgreich erkannt und eingebunden.

Ddms bringt einige hilfreiche Funktionen, zum Beispiel Bildschirm-Schnappschüsse (im Menü »Device | Screen capture« ) und einen »File Explorer« , der logische Filedumps von »data« , »mnt« und »system« liefert. Diese Verzeichnisse sind Partitionen innerhalb des YAFFS2-Dateisystems, auf die der physikalische Zugriff unmöglich ist. Einzige Ausnahme ist das mit FAT formatierte »/mnt/sdcard« .

Die beiden Icons »Pull File From Device« und »Push File Onto Device« ermöglichen bidirektionalen Dateitransfer. Ob die zugehörigen Zugriffsrechte ausreichen, um einen kompletten Filedump von Android auf den PC zu ermöglichen, hängt maßgeblich davon ab, ob ein gerootetes Smartphone vorliegt. In der Praxis dürfte dies wohl eher selten der Fall sein. Aber schon mit einfachen Benutzerrechten sind diverse Dumps von wichtigen Dateien möglich. Android speichert viele seiner Information in XML-Dateien oder SQLite-Datenbanken.

Die Protokolldateien des Androiden auswerten

Zur Logfile-Auswertung muss der Administrator keinen kompletten Dateidump durchführen, er kann im Dalvik-Debugger direkt auf fünf Funktionen zugreifen:

• »Show process status….« zeigt die laufenden Prozesse auf dem angeschlossenen Gerät,
• »Dump Device State…« dessen Status,
• »Dump App State…« die installierten Anwendungen.
• »Dump Radio State…« liefert Informationen über Funkverbindungen,
• »Run logcat« das Systemprotokoll.

Das dritte Tool im Bunde ist das nicht weniger wichtige Kommandozeilentool »adb« , die Android Debug Bridge. Ein erster Kontakt erfolgt an der Bash mit dem Befehl »adb devices« :

List of devices attached
HT0ABR200609 device

Eine Übersicht des Dateisystems erreicht der Anwender mit Hilfe von »adb shell« (Listing 3).

01 $ pwd
02 /
03 $ ls -l
04 drwxr-xr-x root system 2011-08-08 21:26 app-cache
05 dr-x------ root root 2011-08-08 21:25 config
06 lrwxrwxrwx root root 2011-08-08 21:25 sdcard -> /mnt/sdcard
07 drwxr-xr-x root root 2011-08-08 21:25 acct
08 drwxrwxr-x root system 2011-08-08 21:25 mnt
09 lrwxrwxrwx root root 2011-08-08 21:25 vendor -> /system/vendor
10 lrwxrwxrwx root root 2011-08-08 21:25 d -> /sys/kernel/debug
11 lrwxrwxrwx root root 2011-08-08 21:25 etc -> /system/etc
12 drwx------ root root 2011-08-10 11:40 devlog
13 drwxrwx--- system cache 2011-08-10 08:14 cache
14 -rw-r--r-- root root 659 1970-01-01 01:00 ueventd.vision.rc
15 -rw-r--r-- root root 4261 1970-01-01 01:00 ueventd.rc
16 -rw-r--r-- root root 0 1970-01-01 01:00 ueventd.goldfish.rc
17 drwxr-xr-x root root 2011-08-08 20:48 system
18 drwxr-xr-x root root 2011-08-08 21:25 sys
19 drwxr-x--- root root 1970-01-01 01:00 sbin
20 dr-xr-xr-x root root 1970-01-01 01:00 proc
21 -rwxr-x--- root root 5024 1970-01-01 01:00 init.vision.rc
22 -rwxr-x--- root root 19601 1970-01-01 01:00 init.rc
23 -rwxr-x--- root root 1677 1970-01-01 01:00 init.goldfish.rc
24 -rwxr-x--- root root 103132 1970-01-01 01:00 init
25 -rw-r--r-- root root 118 1970-01-01 01:00 default.prop
26 drwxrwx--x system system 2011-08-09 01:21 data
27 -rw-r--r-- root root 1398 1970-01-01 01:00 cwkeys
28 -rw-r--r-- root root 460 1970-01-01 01:00 bootcomplete.rc
29 drwx------ root root 2011-06-13 04:31 root
30 drwxr-xr-x root root 2011-08-08 21:25 dev
31 $

File Carving: Vermeintlich gelöschte Daten auslesen

Bei der Suche nach gelöschten Dateien ist File Carving [16] angesagt. Die wohl bekanntesten Vertreter sind Foremost und Scalpel, beide in den gängigen Repositories zu finden.

Der folgende Abschnitt zeigt den Einsatz von Scalpel an einem virtuellen, mit dem Android-SDK erstellten Smartphone. Als Imagefile dient »userdata.img« . Die Konfigurationsdatei von Scalpel befindet sich in »/etc/scalpel« , die Ergebnisse landen in »/tmp/recovered« . Der Carving-Vorgang soll nach Gifs, JPGs und SQLite-Datenbanken suchen. Leider fehlen die Informationen zu SQLite-Headern in »scalpel.conf« . Deshalb fügt der Admin die Zeile für die Header- und Footer-Informationen manuell am Ende der Konfigurationsdatei ein:

# SQLite für Android
db y 409600 SQLite\x20format

Anschließend startet »scalpel -c /etc/scalpel/scalpel.conf -o /tmp/carved userdata.img« den Carver (Listing 4). Im Ausgabeverzeichnis warten jetzt die gefundenen Bilder, SQLite-Datenbanken hat das Übungsbeispiel auf dem virtuellen Android nicht gefunden.

01 Scalpel version 1.60
02 Written by Golden G. Richard III, based on Foremost 0.69.
03
04 Opening target "/root/.android/avd/Android_Forensik.avd/userdata.img"
05
06 Image file pass 1/2.
07 userdata.img: 100.0% |*****************|    3.9 MB    00:00 ETAAllocating work queues...
08 Work queues allocation complete. Building carve lists...
09 Carve lists built.  Workload:
10 gif with header "\x47\x49\x46\x38\x37\x61" and footer "\x00\x3b" --> 0 files
11 gif with header "\x47\x49\x46\x38\x39\x61" and footer "\x00\x3b" --> 2 files
12 jpg with header "\xff\xd8\xff\xe0\x00\x10" and footer "\xff\xd9" --> 70 files
13 db with header "\x53\x51\x4c\x69\x74\x65\x20\x66\x6f\x72\x6d\x61\x74" and footer "" --> 0 files
14 Carving files from image.
15 Image file pass 2/2.
16 userdata.img: 100.0% |****************|    3.9 MB    00:00 ETAProcessing of image file complete. Cleaning up...
17 Done.

Wer detaillierte Berichte und Reports der auf dem Androiden gefundenen Daten erhalten will, sollte sich Via Extract von Via Forensics [17] ansehen. Für Strafverfolgungsbehörden gibt es eine Demoversion von Via Extract gratis. Auch ein VMware-Image mit vorinstalliertem Via Extract steht nach der Registrierung bereit. Diese Demoversion beschränkt jedoch die jeweiligen Auswertungsergebnisse auf zehn Einträge.

Sowohl die Demo- als auch die Vollversion stellt der Anbieter als VMware-Image auf einem Ubuntu-i386-Desktop mit XFCE-Oberfläche (10.10) zur Verfügung. Der Hersteller hält sich allerdings derzeit noch etwas bedeckt, was die Installation auf einem echten System anbelangt. Via Extract bringt Module zur Auswertung und Berichterstellung für zahlreiche Mobiltelefone, auch jenseits von Android (Abbildungen 5 und 6).

Abbildungen 5 und 6: Das proprietäre Via Extract listet die Daten in übersichtlichen Tabellen auf und generiert auf Wunsch PDF-Reports.

Rooten

Nur mit Rootzugriff sind zahlreiche Befehle oder das Editieren diverser Dateien auf dem Android-Device möglich. Denkbar wäre etwa die Installation eines Nanddump-Binary für ARM-Prozessoren auf dem Smartphone, um einen Speicherdump auf einer eingebauten SD-Karte abzulegen oder per SSH/SCP auf ein externes Auswertesystem zu übertragen.

Im Web sind zum Thema Jailbreak viele Tipps und Tricks zu finden, die alle angeblich ein Android erfolgreich rooten. Die Praxis sieht eher ernüchternd aus. Das bekannte Rooting-Tool Visionary (im Android-Market) versagt sehr oft, die Ursache liegt hier wie bei vielen Fehlern des Smartphone-Systems in den vielen unterschiedlichen Android-Versionen.

Der empfohlene Weg – die eigene Version zunächst downgraden, dann mit Visionary rooten und zuletzt wieder eine aktuelle Version einspielen – gehört nicht unbedingt zu den anwenderfreundlichsten, manchmal nicht einmal zu den erfolgreichen Ansätzen.

Doch mit Gingerbreak kommt ein neues Werkzeug ins Spiel, das sich zum Rooten eignet. Das LG war im Test schnell dazu bereit, Rootberechtigungen anzunehmen, das HTC Desire HD weigerte sich jedoch. Das Android-SDK gestattet es dem Anwender, mit dem Befehl »adb shell su« einfach zu überprüfen, ob er vollen Zugriff hat. Erscheint »permission denied« , liegt ein nicht gerootetes Android vor, sonst meldet sich der Rootprompt.

Auch übers Booten in den Recovery-Modus lässt sich ein Smartphone rooten. Hier haben aber Hersteller und ISPs oftmals Sperren eingebaut, damit Anwender den Recovery-Modus nicht zum Upgrade auf alternative Android-Versionen nutzen können. In einer Onlinepetition haben über 7000 Unterzeichner zumindest HTC dazu bewegt, diese Sperre zu entfernen. HTC-Besitzer können immerhin über ein installiertes Android-SDK ihren Bootloader entriegeln [18], was allerdings zu Lasten der Garantie geht.

Authentifizierung

Die Anmeldung am System erschwert zudem die Root-Problematik. Androiden kennen prinzipiell drei verschiedene Authentifizierungs-Mechanismen: Pattern Lock, PIN-Authentifizierung und Password-Authentifizierung. Techniken, um den meist verwendeten Passwortschutz zu umgehen, finden sich einige im Web. Meist steht dabei der Ansatz über die Android Debug Bridge an erster Stelle. Aber auch andere Techniken wie Smudge Attack oder das Booten in den Recovery-Modus ermöglichen oft den (unbefugten) Eintritt ins System. Selbstverständlich taugen auch Social Engineering, sofern das Gmail-Konto mit Passwort bekannt ist, oder die Passwort-Reset-Funktion.

Fazit

Dass ausgerechnet das offene Android-Betriebssystem Schwierigkeiten bei der forensischen Auswertung bereitet, ist auf den ersten Blick zwar erstaunlich, doch die Hürden, die schon das Dateisystem YAFFS2 aufstellt, sind beträchtlich. Mit dem Android-SDK steht aber ein Kit bereit, das nicht nur dem Programmierer wertvolle Unterstützung liefert. Administratoren und Forensikern werden damit wichtige Kommandozeilen-Programme an die Hand gegeben, die zusammen mit den Filecarvern Auswertungen ermöglichen. Das proprietäre Tool Via Extract gehört zu den leistungsfähigsten Produkten auf dem Markt, eine eingeschränkte Demoversion steht leider nur den Strafverfolgern zur Verfügung.