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

Stel je voor dat je smartphone een bruisende, hoogbeveiligde stad is. Binnen deze stad zijn je apps als drukke winkels, en het RAM (geheugen) is de tijdelijke werkruimte waar alle huidige transacties plaatsvinden. Wanneer je een geheim bericht stuurt of inlogt op een account, bestaat die data voor een moment in deze werkruimte voordat het wordt verwijderd of naar de harde schijf wordt verplaatst. Digitale forensica is de kunst van het stiekem binnendringen in deze werkruimte om bewijs te grijpen voordat het verdwijnt. Maar hier komt de crux: de architecten van de stad (Google) hebben steeds hogere muren gebouwd en de straatnaambordjes verwijderd. In het verleden konden onderzoekers binnenlopen met een kaart (debug-symbolen) die hen precies vertelde waar de winkel "Geheim Bericht" zich bevond. Nu zijn de straatnaambordjes uit de stad verwijderd om het voor hackers moeilijker te maken om in te breken, waardoor onderzoekers voor een blinde muur staan te staren, zich afvragend of de winkels er überhaupt nog wel zijn.

Dit artikel is een detectiveverhaal over de vraag of die winkels nog steeds staan, zelfs als de bordjes weg zijn. De onderzoekers vroegen zich af: "Google heeft de kaarten verwijderd van de telefoons die we daadwerkelijk kopen, maar hebben ze ook de gebouwen verplaatst?" Ze vergeleken de "blauwdruk"-versies van het Android-systeem (die ontwikkelaars gebruiken en die volledige kaarten hebben) met de "productie"-versies (die gewone mensen krijgen, waarbij alle bordjes zijn verwijderd). Ze ontdekten dat hoewel de straatnaambordjes inderdaad weg zijn, de gebouwen zelf niet zijn verplaatst. De lay-out van het geheugen is nog steeds hetzelfde; het heeft alleen geen naamkaartje meer. Dit betekent dat met een beetje extra detectivewerk — het gebruik van een blauwdruk van een overeenkomstige versie van de stad — onderzoekers nog steeds het bewijs kunnen vinden, zelfs op de meest moderne, verharde telefoons.

De Grote Kaartenroof

Jarenlang vertrouwden experts in digitale forensica op een bibliotheekbestand genaamd libart.so om door het chaotische geheugen van Android-telefoons te navigeren. Zie dit bestand als de hoofddirectory van een enorme bibliotheek. Hierin stond een complete lijst van elk boek, elke plank en precies waar elke paragraaf zich bevond. Deze lijsten werden "symbolen" genoemd. Als een onderzoeker een specifiek stuk bewijs wilde vinden, zoals een versleuteld chatbericht, zocht hij simpelweg het "chat"-symbool op in de directory, en poef, de tool wist precies waar hij in het geheugen moest kijken.

Maar Google begon, in een poging telefoons veiliger te maken voor hackers, een "hardening"-campagne. Ze realiseerden zich dat als een hacker de volledige directory zou hebben, hij gemakkelijk zwakheden kon vinden om het systeem binnen te dringen. Daarom begonnen ze deze directory's uit de telefoons te strippen die daadwerkelijk in de winkels worden verkocht. Ze namen de statische symbolen (de hoofdlijst), de bronbestand-referenties (de aantekeningen van de auteur) en de meeste van de dynamische symbolen weg. Het was alsof je een bibliotheek neemt en de kaartcatalogus verwijdert, waardoor er slechts enkele essentiële labels op de deuren blijven staan zodat de bibliothecarissen de deuren nog kunnen openen, maar de rest verborgen blijft.

De grote vraag was: hadden ze alleen de labels verwijderd, of hadden ze ook de planken verplaatst? Als de planken verplaatst waren, dan zou zelfs als een onderzoeker een blauwdruk van een oude versie van de bibliotheek had, dat niet helpen.

Het Detectivewerk

Om dit op te lossen, handelden de onderzoekers als tijdreizende bibliothecarissen. Ze pakten twee versies van het Android-systeem:

1. De "Developer" Build: Een versie met de volledige, niet-gestripte directory (de blauwdruk).
2. De "Production" Build: De versie die daadwerkelijk draait op een Google Pixel 7 telefoon (de gestripte realiteit).

Ze keken eerst naar de cijfers. In de oude Android 8-versie had de bibliotheek 20.495 statische symbolen. In de nieuwe Android 15-versie was dat aantal gedaald naar nul. De bronbestand-referenties, die vertelden uit welk codebestand een functie kwam, waren ook volledig verdwenen. De dynamische symbolen (de weinige labels die moesten blijven zodat de telefoon kon werken) waren met ongeveer 60 procent gedaald, van 6.577 naar 2.614.

Het leek een ramp voor de forensica. Maar toen keken ze dieper. Ze controleerden de werkelijke structuur van het geheugen — de "planken" en "boeken" zelf. Ze vergeleken de geheugenkaarten van een Android 8-telefoon en een Android 15-telefoon. Ze ontdekten dat de kernstructuren, zoals de "heap" (waar apps hun data opslaan) en de "garbage collector" (die oude data opruimt), nog steeds aanwezig waren. Ze hadden alleen hun namen lichtelijk veranderd. Bijvoorbeeld, een geheugenruimte genaamd dalvik-allocspace main rosalloc in Android 8 werd dalvik-allocspace non moving in Android 15. Het gebouw bewoog, maar het adres veranderde niet.

De "Magische Blauwdruk" Truc

Het meest opwindende deel van het artikel is de "magische truc" die ze uitvoerden. Omdat de telefoon zelf geen kaart heeft, besloten de onderzoekers een kaart te lenen van een overeenkomstige versie.

Ze namen de "Developer" build van Android 15 (die nog steeds de volledige kaart had) en gebruikten deze om de exacte offset (de afstand in bytes) naar specifieke structuren te vinden. Daarna gingen ze naar de "Production" Pixel 7 (die geen kaart had) en pasten zij diezelfde afstanden toe.

Dit is wat er gebeurde:

1. Ze vonden het "Runtime"-object (de hoofdbeheerder van het geheugen van de telefoon) met behulp van een enkel symbool dat moest blijven bestaan om de telefoon te laten werken.
2. Ze gebruikten de "Developer"-kaart om te vinden waar de "Heap" (de opslag van data) zich binnen dat Runtime-object bevond.
3. Ze pasten die afstand toe op de "Production"-telefoon.
4. Resultaat: Het werkte perfect. De pointer die ze berekenden leidde naar exact hetzelfde geldige geheugenadres op de echte telefoon.

Ze herhaalden dit voor de "Thread List" en de "Bump Pointer Space", en elke keer weer leidde de blauwdruk van de developer-versie hen naar de juiste plek op de gestripte productie-telefoon.

Wat dit betekent voor de toekomst

Het artikel sugggeert dat hoewel de "easy mode" van forensica voorbij is, het spel nog niet verloren is. De beveiligingsverharding heeft de geheugenarchitectuur niet gebroken; het heeft alleen de labels verborgen.

• Het goede nieuws: De interne lay-out van het geheugen blijft behouden. Als je een "Developer" build hebt die exact overeenkomt met de versie van de telefoon die je onderzoekt, kun je diens kaart gebruiken om door de gestripte telefoon te navigeren.
• Het slechte nieuws: Je kunt niet zomaar een oude kaart gebruiken. Het artikel merkt op dat structurele offsets veranderen tussen verschillende Android-versies (zoals Android 14 versus 15). Je kunt dus dus geen Android 8-kaart gebruiken om een Android 15-geval op te lossen. Je hebt een versie-overeenkomende blauwdruk nodig.
• De adder onder het gras: Dit proces is nu veel meer handmatig. Onderzoekers kunnen niet simpelweg een tool draaien die zegt: "Zoek Bewijs". Ze moeten de exacte versie van de telefoon vinden, de bijbehorende developer-build ophalen, de specifieke afstanden extraheren en deze vervolgens handmatig toepassen.

De onderzoekers merkten ook op dat ze dit alleen op Google Pixel-apparaten hebben getest. Ze weten niet zeker of andere telefoonsfabrikanten (zoals Samsung of Xiaomi) hetzelfde hebben gedaan of dat zij de planken volledig hebben verplaatst. Maar voor de apparaten die zij hebben getest, is de conclusie duidelijk: de stad is er nog steeds, de gebouwen zijn niet verplaatst, maar je zult je eigen kaart moeten meebrengen om de weg te vinden.