Forensik von iMessage auf iOS5

Forensik von iMessage auf iOS5

Marc Ruef
von Marc Ruef
Lesezeit: 9 Minuten

Am 12. Oktober 2011 war es so weit: Apple hat das Betriebssysten iOS5 für ihre mobilen Geräte herausgegeben. Wie es sich für ein Major-Update gehört wurde die neue Version mit eine Vielzahl an Erweiterungen bestückt. Diese sind mitunter ebenfalls aus Sicht einer forensischen Untersuchung von Interesse. In diesem Beitrag soll die Einbindung und Auswertung von iMessage diskutiert werden.

Apple iOS5 iMessage

Bei iMessage handelt es sich um eine zentrale Erweiterung der Kommunikationsmöglichkeit. Kurznachrichten werden nach Möglichkeiten über den Datenkanal übertragen. Da ein solcher in der Regel weniger kostet, ist der Versand bedeutend kostengünstiger als bei einer klassischen SMS. Grosser Vorteil gegenüber bekannten Lösungen wie WhatsApp ist, dass iMessage direkt in das bestehende SMS-Nachrichtensystem integriert wurde und sich damit für den Benutzer komplett transparent verhält. Einzige Voraussetzung zur Nutzung von iMessage ist, dass sowohl Sender als auch Empfänger ein iOS-Gerät mit dieser Funktion einsetzen. Verschiedene Stellen prognostizieren der klassischen SMS damit einen ersten Todesstoss.

Die Verschmelzung von SMS und iMessage ist nicht nur in der grafischen Oberfläche, mit der sich der Benutzer auseinandersetzt, zu sehen. Auch die interne Verarbeitung wird an zentraler Stelle vorgenommen. Dies wird klar, wenn eine forensische Untersuchung eines Backups – die Grundlagen einer solchen sind im Beitrag iPhone Forensik illustriert worden – vornimmt. Von Interesse ist dabei die Datei 3d0d7e5fb2ce288813306e4d4636395e047a3d28, welche noch immer die verschickten und empfangenen Kurznachrichten bereithält. Das Kernstück dieser ist die Tabelle messages, deren Struktur für die beiden iOS-Versionen 4 und 5 nachfolgend dargestellt wird.

ID Name Typ IOS4 IOS5 Beschreibung
0 ROWID INT     ID (innerhalb SQLite)
1 address TEXT     Zieladresse/Absender (SMS)
2 date INT     Datum (Unix-Timestamp)
3 text TEXT     Nachrichtentext
4 flags INT     Typ (0=iMessage, 2=SMS in, 3=SMS out)
5 replace INT     Alte Nachricht ersetzen (0=nein)
6 svc_center TEXT     unbekannt
7 group_id INT     Gruppendefinition (ID)
8 association_id INT     Datumszuordnung
9 height INT     unbekannt
10 UIFlags INT     Darstellungsmodus (5=Link, 6=Symbole)
11 version INT     Version (immer 0)
12 subject TEXT     Betreff (optional)
13 country TEXT     Landeskürzel (ch=Schweiz)
14 headers BLOB     unbekannt
15 recipients BLOB     Encod. Nachrichtentext (mehrere Empfänger)
16 read INT     Lesestatus Lokal (0=nein, 1=ja)
17 madrid_attributedBody BLOB     unbekannt (codierter Inhalt)
18 madrid_handle TEXT     Absender/Empfänger (iMessage)
19 madrid_version INT     Version (Standard=0)
20 madrid_guid TEXT     Weltweit eindeutige Nachrichtenidentifikation
21 madrid_type INT     unbekannt (Standard=0)
22 madrid_roomname TEXT     unbekannt
23 madrid_service TEXT     unbekannt (Standard=Madrid)
24 madrid_account TEXT     Assoziiertes Konto (e:<mail>, p:<privat>)
25 madrid_flags INT     Richtung (36869=out, 12289=in)
26 madrid_attachmentInfo BLOB     unbekannt
27 madrid_url TEXT     unbekannt
28 madrid_error INT     Fehlercode (0=ok)
29 is_madrid INT     iMessage-Identifikation (SMS=0, iMessage=1)
30 madrid_date_read INT     Lesedatum Lokal (Unix-Timestamp)
31 madrid_date_delivered INT     Zustelldatum (Unix-Timestamp)
32 madrid_account_guid TEXT     Weltweit eindeutige Kontoidentifikation

Hierbei ist klar zu sehen, dass die Felder 17-32 bei iOS4 noch nicht vorhanden waren und erst mit iOS5 angefügt wurden. Dabei handelt es sich um die sogenannten Madrid-Felder. Verschiedene Stellen vermuten, dass Madrid der interne Codename von iMessage während der Entwicklung war. Zu einem gewissen Grad erstaunt es, dass schlussendlich nicht der offizielle Name der Funktion in den jeweiligen Komponenten seine Verwendung fand.

Apple hat versucht ein hohes Mass an Rückwärtskompatibilität gewährleisten zu können. Die altbekannten Felder wurden weitestgehend belassen. Sie wurden höchstens um zusätzliche Werte erweitert (z.B. flags kennt nun 0 für iMessages). Dabei sind ihnen aber anscheinend einige konzeptionelle Ungereimtheiten unterlaufen. Zum Beispiel speichern SMS (address) und iMessage (madrid_account) den Empfänger/Absender in unterschiedlichen Feldern. Da mit flags eine klare Trennung zwischen den Nachrichtentypen vorgenommen werden kann, wäre dies aber nicht nötig gewesen.

Danksagung

Wir möchten uns an dieser Stelle bei @pytey des iPhone DevTeam für die freundliche Unterstützung bedanken. Er hat uns dabei geholfen, die interne Funktionsweise von iOS5 besser zu verstehen.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv