Assessing the Forensic Viability of Android Memory Analysis Across Production Builds: A Cross-Version Study of Security Hardening and Structure Preservation

Stellen Sie sich vor, Ihr Smartphone wäre eine geschäftige, hochgesicherte Stadt. In dieser Stadt sind Ihre Apps wie belebte Geschäfte, und der RAM (Arbeitsspeicher) ist der temporäre Arbeitsbereich, in dem alle aktuellen Transaktionen stattfinden. Wenn Sie eine geheime Nachricht senden oder sich bei einem Konto anmelden, existieren diese Daten für einen Moment in diesem Arbeitsbereich, bevor sie gelöscht oder auf die Festplatte verschoben werden. Digitale Forensik ist die Kunst, sich in diesen Arbeitsbereich zu schleichen, um Beweise zu sichern, bevor sie verschwinden. Aber hier ist der Haken: Die Architekten der Stadt (Google) bauen immer höhere Mauern und entfernen die Straßenschilder. In der Vergangenheit konnten Ermittler mit einer Karte (Debug-Symbolen) hineingehen, die ihnen genau sagte, wo sich das Geschäft „Geheime Nachricht“ befand. Jetzt wurden die Straßenschilder aus der Stadt entfernt, um es Hackern schwerer zu machen, einzubrechen, was Ermittler vor eine leere Wand stellt, während sie sich fragen, ob die Geschäfte überhaupt noch da sind.

Dieses Paper ist eine Detektivgeschichte darüber, ob diese Geschäfte noch stehen, selbst wenn die Schilder fehlen. Die Forscher fragten: „Google hat die Karten von den Telefonen entfernt, die wir tatsächlich kaufen, aber haben sie auch die Gebäude versetzt?“ Sie verglichen die „Blaupausen“-Versionen des Android-Systems (die Entwickler nutzen und die über vollständige Karten verfügen) mit den „Produktions“-Versionen (die normale Menschen erhalten, bei denen alle Schilder entfernt wurden). Sie fanden heraus, dass die Straßenbeschilderung zwar verschwunden ist, die Gebäude selbst sich jedoch nicht bewegt haben. Das Layout des Speichers ist immer noch dasselbe; es hat nur kein Namensschild mehr. Das bedeutet, dass Ermittler mit ein wenig zusätzlicher Detektivarbeit – unter Verwendung einer Blaupause einer passenden Version der Stadt – immer noch Beweise finden können, selbst auf den modernsten, gehärteten Telefonen.

Der große Kartenraub

Jahrelang verließen sich Experten für digitale Forensik auf eine Bibliotheksdatei namens libart.so, um durch das Chaos im Speicher von Android-Telefonen zu navigieren. Man kann sich diese Datei wie das Hauptverzeichnis einer riesigen Bibliothek vorstellen. Darin befand sich eine vollständige Liste jedes Buches, jedes Regals und genau der Ort, an dem sich jedes einzelne Kapitel befand. Diese Listen wurden „Symbole“ genannt. Wenn ein Ermittler ein spezifisches Beweisstück finden wollte, wie etwa eine entschlüsselte Chat-Nachricht, suchte er einfach nach dem „Chat“-Symbol im Verzeichnis, und puf, das Tool wusste genau, wo es im Speicher suchen musste.

Aber Google begann, um Handys sicherer gegen Hacker zu machen, eine „Härtungskampagne“. Ihnen wurde klar, dass ein Hacker, der über das vollständige Verzeichnis verfügt, leicht Schwachstellen finden könnte, um in das System einzubrechen. Also begannen sie, diese Verzeichnisse aus den Telefonen zu entfernen, die tatsächlich in den Handel kommen. Sie entfernten die statischen Symbole (die Hauptliste), die Quelldateireferenzen (die Notizen des Autors) und die meisten der dynamischen Symbole. Es war, als würde man eine Bibliothek nehmen und den Katalog entfernen, sodass nur noch wenige essenzielle Etiketten an den Türen bleiben, damit die Bibliothekare sie noch öffnen können, während alles andere verborgen wird.

Die große Frage war: Haben sie nur die Etiketten entfernt oder auch die Regale umgestellt? Wenn sich die Regale bewegt hätten, dann würde selbst ein Ermittler, der eine Blaupause einer alten Version der Bibliothek besitzt, nicht helfen.

Die Detektivarbeit

Um dies zu lösen, agierten die Forscher wie zeitreisende Bibliothekare. Sie schnappten sich zwei Versionen des Android-Systems:

1. Das „Entwickler“-Build: Eine Version mit dem vollständigen, ungestrippten Verzeichnis (die Blaupause).
2. Das „Produktions“-Build: Die Version, die tatsächlich auf einem Google Pixel 7 läuft (die reduzierte Realität).

Sie betrachteten zuerst die Zahlen. In der alten Android 8 Version hatte die Bibliothek 20.495 statische Symbole. In der neuen Android 15 Version sank diese Zahl auf null. Auch die Quelldateireferenzen, die angaben, aus welcher Code-Datei eine Funktion stammt, verschwanden vollständig. Die dynamischen Symbole (die wenigen Etiketten, die bleiben mussten, damit das Telefon funktioniert) sanken um etwa 60 Prozent, von 6.577 auf 2.614.

Es sah nach einer Katastrophe für die Forensik aus. Doch dann schauten sie tiefer. Sie überprüften die eigentliche Struktur des Speichers – die „Regale“ und „Bücher“ selbst. Sie verglichen die Speicherabbilder eines Android 8 Telefons mit denen eines Android 15 Telefons. Sie fanden heraus, dass die Kernstrukturen, wie der „Heap“ (wo Apps ihre Daten speichern) und der „Garbage Collector“ (der alte Daten aufräumt), immer noch vorhanden waren. Sie hatten nur ihre Namen leicht geändert. Zum Beispiel wurde ein Speicherbereich namens dalvik-allocspace main rosalloc in Android 8 zu dalvik-allocspace non moving in Android 15. Das Gebäude bewegte sich, aber die Adresse änderte sich nicht.

Der „Magische Blaupausen“-Trick

Der spannendste Teil des Papers ist der „magische Trick“, den sie vollzogen haben. Da das Telefon selbst keine Karte besitzt, beschlossen die Forscher, sich eine Karte von einer passenden Version auszuleihen.

Sie nahmen das „Entwickler“-Build von Android 15 (das noch die vollständige Karte besaß) und nutzten es, um den exakten Offset (den Abstand in Bytes) zu spezifischen Strukturen zu finden. Dann gingen sie zum „Produktions“-Pixel 7 (das keine Karte hatte) und wandten dieselben Abstände an.

So lief es ab:

1. Sie fanden das „Runtime“-Objekt (den Hauptmanager des Telefon-Speichers) mithilfe eines einzigen Symbols, das bleiben musste, damit das Telefon funktioniert.
2. Sie nutzten die „Entwickler“-Blaupause, um zu finden, wo sich der „Heap“ (der Datenspeicher) innerhalb dieses Runtime-Objekts befand.
3. Sie wandten diesen Abstand auf das „Produktions“-Telefon an.
4. Ergebnis: Es funktionierte perfekt. Der berechnete Zeiger führte zur exakt gleichen gültigen Speicheradresse auf dem echten Telefon.

Sie wiederholten dies für die „Thread List“ und den „Bump Pointer Space“, und jedes Mal führte die Blaupause aus der Entwicklerversion sie an den richtigen Ort auf dem gestrippten Produktions-Telefon.

Was dies für die Zukunft bedeutet

Das Paper legt nahe, dass der „Leichtspiel-Modus“ der Forensik zwar vorbei ist, das Spiel aber nicht verloren ist. Die Sicherheitshärtung hat die Speicherarchitektur nicht zerstört, sondern nur die Etiketten versteckt.

• Die gute Nachricht: Das interne Layout des Speichers bleibt erhalten. Wenn man eine passende „Entwickler“-Build besitzt, die exakt mit der Version des untersuchten Telefons übereinstimmt, kann man deren Karte nutzen, um im gestrippten Telefon zu navigieren.
• Die schlechte Nachricht: Man kann nicht einfach eine alte Karte verwenden. Das Paper stellt fest, dass sich die Struktur-Offsets zwischen verschiedenen Android-Versionen (wie Android 14 vs. 15) ändern. Man kann also keine Android 8 Karte nutzen, um einen Android 15 Fall zu lösen. Man benötigt eine versionsgleiche Blaupause.
• Der Haken: Dieser Prozess ist nun viel manueller. Ermittler können nicht einfach ein Tool ausführen, das sagt: „Finde Beweise“. Sie müssen die exakte Version des Telefons finden, die passende Entwickler-Build beschaffen, die spezifischen Abstände extrahieren und diese dann manuell anwenden.

Die Forscher merkten auch an, dass sie dies nur auf Google Pixel-Geräten getestet haben. Sie sind sich nicht sicher, ob andere Telefonhersteller (wie Samsung oder Xiaomi) dasselbe getan haben oder ob sie die Regale komplett umgestellt haben. Aber für die getesteten Geräte ist das Fazit eindeutig: Die Stadt ist noch da, die Gebäude haben sich nicht bewegt, aber man muss seine eigene Karte mitbringen, um sich zurechtzufinden.