iOS – Tracking Bundle-IDs für Container, Shared Container und Plugins
Wenn ich in iOS Daten durcharbeite oder einem Schüler bei Fragen helfe, muss ich immer wieder feststellen, welche Anwendung dafür verantwortlich ist, Daten an einem bestimmten Ort abzulegen. Mit einigen der fantastischen Arbeiten, die von anderen, darunter Alexis Brignoni, auf der ApplicationState.db als Teil des FrontBoard-Verzeichnisses geleistet wurden, ist es immer eine meiner ersten Anlaufstellen geworden, um eine „Schatzkarte“ von Anwendungen zu erstellen, um mit diesen lästigen AppGUIDs umzugehen, die Apple jeder App auf einem Gerät zuweist. Diese lästigen Dinge findet man, wenn man nach Daten in sucht:
/private/var/mobile/Containers/Data/Application
Glücklicherweise analysieren die meisten Tools die ApplicationState.db und ordnen jede dieser eindeutigen IDs der Anwendung zu, die darin gespeichert ist.
Fantastisch! Es ist so viel einfacher, herauszufinden, welche Anwendungen wo leben. Manchmal stößt man jedoch in einem Ordner auf eine interessante Datei und muss dann den Verzeichnispfad mit dieser Datenbank abgleichen. Vielleicht sind Sie in einer Situation, in der Sie nur mit dem Rohbild arbeiten und auch nur begrenzten Zugang zu Tools haben. Wie können wir die BundleID der Anwendung bereits innerhalb eines Verzeichnisses finden?
Im Pfad der Anwendungsdaten sollte im Stammverzeichnis eine Datei „.com.apple.mobile_container_manager.metadata.plist“ vorhanden sein, die in jedem Anwendungsverzeichnis den gleichen Namen zu haben scheint. Diese Informationen enthalten Schlüssel, die die BundleID der Anwendung enthalten, was sehr nützlich ist, wenn man in der Klemme steckt und nicht hin und her springen will.
Interessanter ist jedoch, was passiert, wenn Sie auf Ihrem iOS-Gerät nach dieser Datei suchen. Wenn Sie das tun, werden Sie sehen, dass die Datei .com.apple.mobile_container_manager.metadata.plist an vielen Stellen erscheint, unter anderem:
- /private/var/containers/Bundle/Application/APPGUID/
- /private/var/containers/Shared/SystemGroup/APPGUID/
- /private/var/containers/Data/System/APPGUID/
- /private/var/mobile/Containers/Shared/AppGroup/APPGUID/
- /private/var/mobile/Containers/Data/Application/APPGUID [duh]
- /private/var/mobile/Containers/Data/InternalDaemon/APPGUID/
- /private/var/mobile/Containers/Data/PluginKitPlugin/APPGUID/
Wow. Das sind viele weitere Orte, die wir erkunden müssen, um unsere Schatzkarte zu erstellen. Was ist diese Datei überhaupt? Lassen Sie uns zunächst über Sandboxing sprechen. Apple setzt in iOS stark auf Sandboxing. Damit soll verhindert werden, dass Anwendungen Zugriff auf Daten erhalten, auf die sie nicht zugreifen dürfen. Jede Anwendung hat ihre eigene Sandbox, in der sie spielen kann, und nur dieser Bereich ist ihr vorbehalten. Mit dieser plist-Datei können wir sehen, in welcher Sandbox wir uns befinden und wem diese Sandbox aus Sicht der Anwendung gehört. Anhand dieser Informationen können wir die obigen Pfadinformationen ein wenig weiter aufschlüsseln, um herauszufinden, warum bestimmte Anwendungen Daten an einem bestimmten Ort speichern.
/private/var/containers/Bundle/Application/
In diesem Verzeichnis befindet sich die .app auf dem Gerät. Es gibt einige zusätzliche Daten, die wir hier über die Anwendung selbst und darüber, wer sie auf das Gerät heruntergeladen hat, verfolgen können. Zusammen mit der .app-Datei gibt es eine iTunesMetadata- und BundleMetadata-Plist-Datei, die Informationen auflisten kann, z. B. wann die Anwendung heruntergeladen wurde, welche Version der Anwendung heruntergeladen wurde und welche AppleID sie tatsächlich heruntergeladen hat.
/private/var/containers/Shared/SystemGroup/
Dieses Verzeichnis ähnelt dem obigen, bezieht sich aber auf die Kernanwendungen des iOS-Geräts. Hier gibt es weniger Informationen, aber immer noch eine .plist-Datei, die Aufschluss darüber geben kann, welche Systemanwendung für den Container verantwortlich ist. /
private/var/containers/Data/System/
Auch hier ist es ähnlich wie im obigen Verzeichnis, aber es scheint sich um Systemanwendungen zu handeln, die keine Informationen zwischen Kernanwendungen austauschen wollen. Auch hier gibt es weniger relevante Informationen außer der BundleID, die den Container besitzt.
/private/var/mobile/Containers/Shared/AppGroup/
Jetzt beginnt der EIGENTLICHE Spaß! Ich habe das Sandboxing bereits erwähnt. Apple sagt, dass Anwendungen keine Informationen weitergeben dürfen, ohne sie vorher über offizielle Kanäle anzufordern. Um Informationen gemeinsam zu nutzen, können Anwendungsentwickler ihrer Anwendung eine „Gruppe“ zuweisen. Nach den Entwicklerinformationen von Apple können diese Gruppen dann Daten untereinander austauschen. Möglicherweise haben Sie diese auch in Backup-Images gesehen, die als „AppDomainGroup-group.bundleID“ anstelle der Struktur „AppDomain-com.bundle.ID“ aufgeführt sind. Ich habe diesen Pfad oft verwendet, wenn ich die gesuchten Daten im Hauptpfad für Anwendungsdaten nicht finden konnte.
Und nun die Kehrseite. Die ApplicationState.db enthält keine Informationen über diesen Pfad. Das Gute daran? Das „Shared/AppGroup“-Verzeichnis jeder Anwendung wird eine unserer .com.apple.mobile_container_manager.metadata.plist-Dateien enthalten! Juhu! Um es noch besser zu machen, hat Alexis Brignoni eine Unterstützung in iLeapp eingebaut, um alle diese Dateien aus diesem Verzeichnis aufzulisten, so dass wir den Inhalt der Datei mit dem Pfad abgleichen können, in dem sie sich befindet. [Holen Sie sich iLeapp hier]
Eine Anwendung kann auch mehr als einen Ordner in diesem Pfad haben. Ein paar Beispiele wären die Dropbox-Anwendung, die hier über 4 verschiedene Container verfügt, und die Spark-E-Mail-Anwendung, die 2 Container hat. Noch wichtiger ist, dass einige Anwendungen alle ihre relevanten Daten hier statt im Verzeichnis /private/var/mobile/Containers/Application/Data/ aufbewahren können. Ein Beispiel hierfür ist die E-Mail-Anwendung Spark (iTunes-Web-Link), die alle relevanten Datenbanken in der Verzeichnisstruktur /private/var/mobile/Containers/Shared/AppGroup/ speichert, anstatt in der üblichen Verzeichnisstruktur /private/var/mobile/Containers/Application/Data/. [Andere bemerkenswerte Beispiele hierfür sind WhatsApp und Signal] [Other notable examples of this include WhatsApp and Signal]
/private/var/mobile/Containers/Application/Data
Der Ort, an dem wir nach Anwendungsdaten suchen sollen. Gut verständlich und dokumentiert. Nur nicht dort, wo wir am Ende doch immer hinschauen wollen.
/private/var/mobile/Containers/Application/InternalDaemon
Bei meinen Testgeräten handelte es sich offenbar um Apple-Dienste (oder interne Daemons), die mit denselben .com.apple.mobile_container_manager_metadata.plist-Dateien verfolgt werden konnten.
/private/var/mobile/Containers/Application/PluginKitPlugin/
In letzter Zeit hatte ich zwei Situationen, in denen ich Studenten dabei geholfen habe, zu verstehen, wo wichtige Daten für ihre Fälle in diesem Bereich gelandet sind. Es ist schwierig, hier genau übereinstimmende Daten zu finden, aber es gab ein paar Situationen, in denen ich eine ganze Reihe von Informationen finden konnte. Da Apple Anwendungen erlaubt, Plugins zu verwenden, um sie miteinander zu verbinden (man denke nur an die Giphy-Tastatur, meinen persönlichen Favoriten), können diese Plugins Daten innerhalb dieser Verzeichnisstruktur speichern. In einem Testfall ging es darum, herauszufinden, warum in einem bestimmten Verzeichnis eine Reihe von illegalen Videos auftauchten. Mithilfe der Datei .com.apple.mobile_container_manager.metadata.plist konnte der Analyst herausfinden, welches Plugin dazu beitrug, Daten in diesem Verzeichnis abzulegen und zu welcher BundleID das Plugin gehörte. In diesem Fall war es mit der PhotoMessagesApp von com.apple.mobileslideshow verbunden.
Hinweis: com.apple.mobileslideshow ist die Anwendung Fotos auf iOS.
Da wir nun wissen, zu welchem Plugin und zu welcher Anwendung das Verzeichnis gehört, können wir versuchen, Daten zu generieren, um zu beweisen, wie diese Informationen hierher gelangen. In meinem Beispiel habe ich das Foto-Picker-Plugin in iMessage verwendet und dann das Video direkt in diesem Plugin geändert, ohne die ursprüngliche com.apple.mobileslideshow-Anwendung zu starten. Mit Hilfe von KnowledgeC können Sie in den folgenden Screenshots sehen, dass sich die MobileSMS-Anwendung und andere Plugins überschneiden, wenn diese Dateien innerhalb der Verzeichnisstruktur PluginKitPlugin/APPGUID/ erstellt wurden.
Andere Plugins wie „com.apple.mobileslideshow.photo-picker“ sind in anderen Ermittlungen aufgetaucht, aber manchmal ist es schwierig, diese Verzeichnisse ohne KnowledgeC oder PowerLog zu befüllen. Wenn wir zumindest die zugehörige BundleID kennen, können wir herausfinden, wie die Daten dorthin gelangt sind, wo sie sind.
Jetzt haben wir eine bessere Möglichkeit, unsere eigenen Schatzkarten zu erstellen und wissen, dass .com.apple.mobile_container_manager.metadata.plist-Dateien in der Regel das „X“ liefern, das die Stelle markiert.
Dieser Beitrag wurde von Christopher Vance, Manager, Curriculum Development bei Magnet Forensics, verfasst. Er erscheint auch in seinem D20 Forensics Blog.
