© 3dfoto, 123RF

Full Backup ohne Festplatte? Was bei Computern relativ leicht zu erledigen ist, das gehört zu den kniffligsten Aufgaben bei mobilen Geräten. Dann aber lassen sich sogar Chatprotokolle auslesen.

Während für PCs und Geräte mit echtem Linux zahlreiche Festplattenwerkzeuge wie Dd, Dc3dd oder gar solche mit eingebauter Komprimierung wie Ewfacquire [1] oder Partclone [2] zur Verfügung stehen, schaut es für all jene, die Ähnliches mit einem Android-Device versuchen, mau aus.

Admins, die sich getreu dem alten Motto “Nur ein volles Backup ist ein gutes Backup” tiefreichenden Zugriff wünschen, stehen vor einer schier unlösbaren Aufgabe – und ebenso der Forensiker, der die Smartphones und Tablets von Verdächtigten unter die Lupe nehmen soll. Besonders kritisch erweist sich die Lage bei älteren Smartphones, aber auch bei neueren Geräten der untersten Preisklasse.

Wear Leveling

Per Software initiiertes Wear Leveling erspart dem (Billig-)Hersteller zwar weitere Hardwarekomponenten, erschwert dem Admin das direkte Auslesen aus den Speicherchips aber zusätzlich. Immer noch gibt es viel zu wenig Software, die dann in der Lage ist, das Dateisystem auszulesen – was bereits ein Artikel im Linux-Magazin im Jahr 2011 monierte [3]. Seither ist aber viel Zeit vergangen und die Geräte mit YAFFS-Dateisystem sind Gott sei Dank auf dem Rückzug. Ende 2014 dominiert Ext 4 als Dateisystem in der Mittel- und Oberklasse mit großem Vorsprung.

Der folgende Artikel zeigt, wie Admins Backups mit YAFFS und Ext 4 umsetzen und Daten aus Anwendungen wie Skype und Whatsapp herausziehen. Die größte Hürde dabei ist: Das Smartphone muss gerootet sein, damit die beschriebenen Verfahren funktionieren. Anleitungen zum Rooten gibt es jede Menge, doch auf die Fülle der Modelle und Prozeduren geht dieser Artikel nicht ein und setzt einfach ein wie auch immer gerootetes Smartphone oder Tablet voraus – was sicher nicht in jedem Fall eine leichte Aufgabe ist.

Das auf dem Smartphone eingesetzte Dateisystem ist schnell ermittelt, analog zu vollwertigen Linux-Systemen. Mit aktiviertem USB-Debugging reicht der Befehl »adm shell mount« , dann erhält der Admin bei YAFFS unter anderem eine Ausgabe wie Listing 1, bei Ext 4 ein wenig mehr als Listing 2.

01 /dev/block/mtdblock4 /system yaffs2 ro,relatime 0 0
02 /dev/block/mtdblock6 /data yaffs2 rw,nosuid,nodev,relatime 0 0
03 /dev/block/mtdblock5 /cache yaffs2 rw,nosuid,nodev,relatime 0 0
04 /dev/block/mtdblock8 /cust yaffs2 ro,relatime 0 0
05 /dev/block/mtdblock7 /data/HWUserData yaffs2 rw,nosuid,nodev,relatime 0 0

01 /dev/block/platform/omap/omap_hsmmc.1/by-name/FACTORYFS /system ext4 ro,relatime,barrier=1,data=ordered 0 0
02 /dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered,noauto_da_alloc,discard 0 0
03 /dev/block/platform/omap/omap_hsmmc.1/by-name/CACHE /cache ext4 rw,nosuid,nodev,noatime,barrier=1,nomblk_io_submit,data=ordered 0 0
04 /dev/block/platform/omap/omap_hsmmc.1/by-name/EFS /efs ext4 rw,relatime,barrier=1,data=ordered 0 0

In beiden Fällen laufen Analyse wie auch das spätere Backup über die Android Debug Bridge (»adb« ), die der Admin zuvor über das Android SDK installieren muss. Wer den Download von Google vermeiden möchte und lediglich Adb ohne weitere Zutaten benötigt, bedient sich aus dem Repository seiner Distribution: Unter Ubuntu reicht »aptitude install android-tools-adb« .

Remote-Admin via USB

Adb erlaubt auch das Einloggen an einer Shell per Remote-Sitzung über USB, was das lästige Wischen und Tippen auf dem Touchscreen unnötig macht. Der Linux-Admin arbeitet dann mit der gewohnten Konsole, fast wie auf Linux: »adb shell« gefolgt von »su« zeigt den Android-Rootprompt, sofern alles vorbereitet ist.

Alle Android-Versionen haben den Dd-Befehl standardmäßig an Bord, bei YAFSS-Dateisystemen nützt er allerdings nichts. Das liegt an der Dateistruktur, die unabhängige Datenströme nach dem Out-of-Band-Data-Konzept einsetzt [4]. Warum das in solchen Fällen hilfreiche Tool Nanddump auf Android-Geräten nicht das hier nutzlose Dd ersetzt, bleibt das Geheimnis von Google.

Mit Ext 4 ist alles ein wenig einfacher. Ist auch noch eine SD-Karte vorhanden, kann der Admin das Image dort ablegen. Dazu muss er nur den zugehörigen Mountpoint ermitteln (Listing 3). Quelle und Ziel sind dem Admin jetzt bekannt, Dd erledigt den Rest:

01 adb shell mount | grep -i sdcard
02 /dev/block/vold/179:25 /mnt/extSdCard vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1023,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

dd if=/dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS of=/mnt/extSdCard/image.dd

Anschließend kann er das Image von der SD-Karte kopieren, auch ohne das Smartphone anzufassen – via Android Debug Bridge:

adb pull /mnt/extSdCard/image.dd

Was tun, wenn es sich um ein internes Speichermedium handelt, das nicht genügend Speicherplatz zur Verfügung stellt? Auch hier bietet Adb eine Lösung an: Dd übergibt an Netcat. Das Problem dabei: Das per USB angeschlossene Gerät besitzt ja auf den ersten Blick keine Internetadresse.

Tricksen mit IP-Adressen

Doch das stimmt nicht ganz, denn es bleibt immer die IP-Adresse 127.0.0.1. Wer jetzt an TCP-Forwarding denkt, der hat schon Witterung aufgenommen, baucht dafür aber das Netcat-Binary auf dem Smartphone. Weil das für die ARM-Architektur und statisch kompiliert sein muss, kann der Admin es nicht einfach von einem Linux-System kopieren. Das Binary findet sich auch auf der DELUG-DVD, »file« hilft bei der Kontrolle:

file nc
nc: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped

Bevor die Aktivitäten im Smartphone beginnen, muss der Admin auf dem Hostsystem TCP-Forwarding einrichten:

adb forward tcp:8888 tcp:8888

Es folgt die Übertragung ins Smartphone. Doch dort ist die Systempartition immer nur Read-only gemountet und kann daher nicht als Empfänger für das zu schreibende Image dienen. »adb remount« könnte dies zwar ändern, weil das Beispiel aber Nc gar nicht permanent benötigt, erscheint es als bessere Wahl, die Daten in einem Verzeichnis unter »tmpfs« abzulegen, zum Beispiel »/dev« .

Umwege

Listing 4 erledigt die wesentlichen Schritte. Der Umweg über »/mnt/sdcard« ist notwendig, da die erforderlichen Rechte fehlen und das Spielzeugdateisystem Vfat diese auch gar nicht in Betracht zieht. Allerdings gehen dabei die Linux-Attribute verloren, was der anschließende Chmod-Befehl wieder korrigiert. Viele Smartphones haben den Cp-Befehl nicht an Bord, dort muss dann eben der Cat-Befehl herhalten.

01 adb push nc /mnt/extsdcard
02 adb shell
03 su
04 cat /mnt/sdcard/nc > /dev/nc
05 chmod 777 /dev/nc

Im Smartphone startet das folgende Kommando die Übertragung:

dd if=/dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS | /dev/nc -l -p 8888

Das Gerät befindet sich nun im Listen-Modus von Nc, auf dem Host startet der Admin die Image-Erstellung mit:

nc 127.0.0.1 8888 > image.dd

Das Image liegt jetzt im aktuellen Verzeichnis und lässt sich mit einem normalen Mount-Befehl einbinden.

GPS-, Skype, Whatsapp

Im Backup der Datenpartition findet sich neben vielen Konfigurationen auch Privates. Was den Forensiker freut, muss der Admin natürlich zunächst von einer rechtlichen Seite klären lassen. Darf er auf die privaten Daten des Mitarbeiters zugreifen? Dabei sind dem Informationshunger nur wenig Grenzen gesetzt: Die zuletzt genutzte GPS-Koordinate ist ebenso ersichtlich wie der Skype-Chat oder die Whatsapp-Konversation.

Das Kommando »find /mnt -type f -iname “main.db”« fördert schnell zu Tage, wo sich die Skype-Informationen befinden. Statt die Tabellen der SQlite-Datenbank mühsam selbst zusammenzustellen, bedient sich der Admin eines fertigen Python-Skripts [5], das zusätzlich auch noch ordentlich formatierte HTML-Ausgabe erzeugt: »python skype.py main.db« (Abbildungen 1 und 2).

Abbildung 1: Das Python-Skript stellt die vertraulichen Daten der Skype-Kommunikation wieder her …

Abbildung 2: … und erstellt eine übersichtliche HTML-Ausgabe zur schnelleren Auswertung für den Forensiker.

Versehentlich oder auch absichtlich gelöschte Dateien kann der Admin wie auf PCs mit »tsk_recover« aus dem Sleuthkit [6] rekonstruieren: Nach einem Aufruf von »tsk_recover images.dd undelete« finden sich alle “geretteten” Dateien im Verzeichnis »undelete« .

YAFFS

Ein so erstelltes Ext-Image zu mounten gehört zu den alltäglichen Arbeiten eines Linux-Admin, komplizierter wird die Angelegenheit allerdings mit dem YAFFS-Dateisystem. Das Sleuthkit ermöglicht zwar physikalischen Zugriff, das Mounten ist aber nur mit viel Aufwand möglich und häufig ist ein Erfolg auch nicht garantiert [3].

Sleuthkit unterstützt seit Version 4 auch YAFFS. Das zum Kit gehörende Programm Fls liefert die Inode-Information zur Extraktion (Listing 5).

01 + r/r * 1049663:        accounts.db-journal#1087,4
02 + r/r * 787519:         accounts.db-journal#1087,3
03 + r/r * 787561:         accounts.db-journal#1129,3
04 + r/r * 1311853:        accounts.db-journal#1133,5
05 + r/r * 1049709:        accounts.db-journal#1133,4
06 + r/r * 525426:         accounts.db-journal#1138,2
07 + r/r * 263282:         accounts.db-journal#1138,1
08 + r/r * 787574:         accounts.db-journal#1142,3
09 + r/r * 525431:         accounts.db-journal#1143,2
10 + r/r * 263293:         accounts.db-journal#1149,1
11 + r/r * 1311877:        accounts.db-journal#1157,5
12 + r/r * 1049733:        accounts.db-journal#1157,4
13 + r/r * 1836169:        accounts.db-journal#1161,7
14 + r/r * 1574025:        accounts.db-journal#1161,6
15 + r/r * 1049739:        accounts.db-journal#1163,4
16 + r/r * 787599:         accounts.db-journal#1167,3
17 + r/r * 787601:         accounts.db-journal#1169,3
18 + r/r * 525457:         accounts.db-journal#1169,2

Dieses Listing zeigt als Beispiel die »accounts.db« -Datenbank eines Smartphone. Leicht zu erkennen ist, wie das Wear-Leveling für viele Versionen einzelner Dateien sorgt. Ein normal benutztes Smartphone, auf dem sich im Lauf der Zeit mehr als 4000 SQlite-Dateien ansammeln, ist da keine Seltenheit.

Für bessere Übersichtlichkeit sorgt eine Fls-Grep-Pipe, die nur jene Dateien ausgibt, die aktuell in Benutzung sind und die Nutzerdaten enthalten (Listing 6): Da taucht dann auch die zuvor besprochene »main.db« aus Skype auf, hier beispielsweise mit Inode 780 gelistet. Extrahieren kann der Admin die Datei nun mit dem Icat-Befehl, der für Inode Extraktion steht:

01 +++ r/r 1142:   launcher.db
02 +++ r/r 730:    downloads.db
03 +++ r/r 1143:   weather.db
04 +++ r/r 813:    pluscontacts.db
05 +++ r/r 816:    gcore_ulr_ApiMetadata.db
06 +++ r/r 821:    keys.db
07 +++ r/r 851:    plus.db
08 +++ r/r 871:    rmq.db
09 +++ r/r 877:    games_743b08da.db
10 +++ r/r 914:    gcore_ulr_ActivityDetection.db
11 +++ r/r 929:    peoplelog.db
12 +++ r/r 968:    gcore_ulr_UlrLocation.db
13 +++ r/r 1159:   app_state.db
14 +++ r/r 580:    wa.db
15 +++ r/r 1157:   msgstore.db
16 ++++ r/r 1132:  queue.db
17 ++++ r/r 780:   main.db
18 ++++ r/r 834:   eas.db
19 ++++ r/r 904:   bistats.db
20 ++++ r/r 924:   keyval.db
21 +++++ r/r 784:  qik_main.db
22 ++++ r/r 1130:  statistics.db
23 ++++ r/r 1170:  msn.db
24 + r/r 492:      accounts.db

icat userdata.nanddump 780 > main.db

Ein simpler Header-Test mit »file main.db« liefert »main.db: SQLite 3.x database« . Es liegt also eine SQlite-Datenbank vor, die sich leicht analysieren lässt.

Zur Fleißarbeit wird das Ganze, wenn der Admin alle Datenbanken auf einen Schlag mit einem Befehl extrahieren will. Da hilft es, gewiefte Scripting-Experten zu kennen oder auf Veranstaltungen zu treffen, zum Beispiel bei einem Forensik-Kurs Ende 2013 im Linuxhotel Essen: Der Kursteilnehmer Tom Schier packte kurzerhand Icat mit ein paar anderen gängigen Linux-Tools wie Awk zu dem Skript aus Listing 7 zusammen.

01 #!/bin/bash
02 if [ $# -le 1 ]
03 then
04   echo "Usage: " $0 " <nanddumpfile> <directory to save dbs>"
05 else
06   dumpfileescaped=`echo "$1" | sed -e "s/\//\\\\\\\\\//g"`
07   dirnameescaped=`echo "$2" | sed -e "s/\//\\\\\\\\\//g"`
08   mkdir -p $2
09   fls -r $1 | grep "\.db$" | grep -v "*" | awk '{print $3 " " $4}' | sed -e "s/:/\ $dumpfileescaped\ $dirnameescaped/g" | awk '{system("icat " $2 " " $1 " > " $3 "/" $4 " && echo extracting: "$4" \n")}'
10 fi

01 extracting: webview.db
02 extracting: google_analytics.db
03 extracting: webviewCache.db
04 extracting: mmssms.db
05 extracting: telephony.db
06 extracting: settings.db
07 extracting: alarms.db
08 extracting: user_dict.db
09 extracting: webviewCache.db
10 extracting: library.db
11 extracting: suggestions.db
12 extracting: localappstate.db
13 extracting: billing4.db
14 extracting: webview.db
15 extracting: package_verification.db
16 extracting: inconfig.db
17 extracting: external-56f81af2.db
18 extracting: internal.db
19 extracting: userbigram_dict.db
20 extracting: auto_dict.db
21 extracting: gls.db
22 extracting: talk.db
23 extracting: gservices.db
24 extracting: googlesettings.db
25 extracting: hwphone.db
26 extracting: contacts2.db

Vom Whatsapp-Praktikanten?

Die SQlite-Datenbanken (Listing 8) sind mit Tools wie dem SQlite-Browser leicht lesbar, nicht aber bei Whatsapp. Die Chat- und IM-App gehört wohl zu den am häufigsten genutzten Apps auf Smartphones aller Couleur und legt Daten verschlüsselt ab. Die Datenbank ist damit erst mal nicht lesbar. Aber bei genauerem Hinsehen entsteht der Eindruck, dass es sich beim Code um eine Praktikantenarbeit handelt. Der Klassiker “Poor Programming” ermöglicht auch hier Zugriff.

Whatsapp Xtract

Mit Whatsapp Xtract [7] steht ein ähnlicher Ansatz wie bei Skype zur Verfügung, um die Datenbank-Informationen HTML-gerecht aufzubereiten. Die alten Datenbankversionen nutzten folgende Dateien:

msgstore.db
msgstore.db.crypt
msgstore.db.crypt5

Zu finden sind sie normalerweise im Whatsapp-Verzeichnis auf der SD-Karte. Sie liegen zwar verschlüsselt vor, lassen sich jedoch leicht aufgrund eines AES-Cypher-Crypting-Bugs entschlüsseln. Ähnlich wie bei Skype gibt es auch dazu fertige Software, etwa Whatcrypt ([8], Abbildung 3). Ubuntu-Anwender brauchen vorher Python und Python-django aus den Repositories. Je nach Version erfolgt die Extraktion mit einem der nachfolgenden Befehle. Ein Python-Skript öffnet die in Abbildung 4 gezeigte Webseite.

Abbildung 3: Weil Whatsapp einen Fehler in seinen Crypto-Funktionen aufweist, kann Whatcrypt alle Daten lesbar machen.

Abbildung 4: Auch die vermeintlich verschlüsselt abgelegten Whatsapp-Kontakte lassen sich mit Linux-Bordmitteln auslesen, weil der Hersteller der App bei der Kryptographie versagt hat.

python whatsapp_xtract.py msgstore.db -w wa.db
python whatsapp_xtract.py msgstore.db
python whatsapp_xtract.py msgstore.db crypt

Das funktioniert wunderbar mit älteren Versionen von Whatsapp. Weil die App aber Updates auf die aktuelle Version erzwingt, muss der Admin ab der Version Crypt 5 die Datenbank zuerst ins alte Format konvertieren. Dafür gibt es Apps, die der Anwender auf sein Smartphone installiert, etwa den Whatsapp Crypt-DB Converter (aus dem Play Store) oder Whatcrypt (als Apk-Paket auf der Heft-DVD). Whatsapp führt auch automatisch Backups durch, die sich zusammenführen und auswerten lassen [9].

Der Autor

Hans-Peter Merkel ist mit dem Schwerpunkt Datenforensik seit vielen Jahren in der Open-Source-Community aktiv. Er bildet Mitarbeiter von Strafverfolgungsbehörden in Europa, Asien und Afrika aus und engagiert sich als Gründer und Vorsitzender bei Freioss und Linux4afrika.