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

Immagina che il tuo smartphone sia una città frenetica e ad alta sicurezza. All'interno di questa città, le tue app sono come negozi molto frequentati, e la RAM (memoria) è lo spazio di lavoro temporaneo dove avvengono tutte le transazioni attuali. Quando invii un messaggio segreto o accedi a un account, i dati esistono in questo spazio di lavoro per un momento prima di essere eliminati o spostati nell'hard drive. La forense digitale è l'arte di intrufolarsi in questo spazio di lavoro per recuperare prove prima che svaniscano. Ma ecco il problema: gli architetti della città (Google) hanno costruito muri più alti e rimosso i cartelli stradali. In passato, gli investigatori potevano entrare con una mappa (simboli di debug) che indicava esattamente dove si trovasse il negozio "Messaggio Segreto". Ora, la città è stata privata di quei cartelli per rendere più difficile l'intrusione degli hacker, lasciando gli investigatori davanti a un muro vuoto, chiedendosi se i negozi siano ancora lì.

Questo articolo è una storia investigativa su se quei negozi siano ancora in piedi, anche se i cartelli sono spariti. I ricercatori si sono chiesti: "Google ha rimosso le mappe dai telefoni che acquistiamo realmente, ma ha anche spostato gli edifici?". Hanno confrontato le versioni "blueprint" (progetto) del sistema Android (che i developer usano e hanno mappe complete) contro le versioni "production" (quelle che la gente comune riceve, con tutti i cartelli rimossi). Hanno scoperto che, sebbene i cartelli stradali siano effettivamente spariti, gli edifici stessi non si sono spostati. Il layout della memoria è rimasto lo stesso; solo che non ha più un'etichetta con il nome. Ciò significa che con un po' di lavoro investigativo extra — usando una mappa proveniente da una versione corrispondente della città — gli investigatori possono ancora trovare le prove, anche sui telefoni più moderni e protetti.

Il Grande Furto delle Mappe

Per anni, gli esperti di forense digitale si sono affidati a un file di libreria chiamato libart.so per navigare nel caos della memoria dei telefoni Android. Pensa a questo file come alla directory principale di una massiccia biblioteca. Al suo interno, aveva un elenco completo di ogni libro, ogni scaffale e l'esatta posizione di ogni paragrafo. Questi elenchi erano chiamati "simboli". Se un investigatore voleva trovare una specifica prova, come un messaggio di chat decriptato, cercava semplicemente il simbolo "chat" nella directory, e puff, lo strumento sapeva esattamente dove guardare nella memoria.

Ma Google, volendo rendere i telefoni più sicuri contro gli hacker, ha iniziato una campagna di "hardening" (indurimento). Si sono resi conto che se un hacker avesse avuto la directory completa, avrebbe potuto facilmente trovare le debolezze per violare il sistema. Così, hanno iniziato a rimuovere queste directory dai telefoni che vengono effettivamente spediti nei negozi. Hanno tolto i simboli statici (l'elenco principale), i riferimenti ai file sorgente (le note dell'autore) e la maggior parte dei simboli dinamici. È stato come prendere una biblioteca e rimuovere il catalogo, lasciando solo pochi etichette essenziali sulle porte in modo che i bibliotecari potessero ancora aprirle, ma nascondendo tutto il resto.

La grande domanda era: hanno solo rimosso le etichette o hanno anche riorganizzato gli scaffali? Se gli scaffali si fossero mossi, allora anche se un investigatore avesse avuto una mappa di una vecchia versione della biblioteca, non servirebbe a nulla.

Il Lavoro Investigativo

Per risolvere la questione, i ricercatori hanno agito come bibliotecari viaggiatori nel tempo. Hanno preso due versioni del sistema Android:

1. La Build "Developer": Una versione con la directory completa e non rimossa (il blueprint/progetto).
2. La Build "Production": La versione che gira effettivamente su un Google Pixel 7 (la realtà depurata).

Hanno analizzato prima i numeri. Nella vecchia versione Android 8, la libreria aveva 20.495 simboli statici. Nella nuova versione Android 15, quel numero è sceso a zero. Anche i riferimenti ai file sorgente, che indicavano da quale file di codice proveniva una funzione, sono scomparsi completamente. I simboli dinamici (le poche etichette che dovevano restare affinché il telefono funzionasse) sono diminuiti di circa il 60 percento, da 6.577 a 2.614.

Sembrava un disastro per la forense. Ma poi, hanno guardato più a fondo. Hanno controllato la struttura reale della memoria — gli "scaffali" e i "libri" stessi. Hanno confrontato le mappe di memoria di un telefono Android 8 e di un telefono Android 15. Hanno scoperto che le strutture principali, come l' "heap" (dove le app memorizzano i dati) e il "garbage collector" (che pulisce i vecchi dati), erano ancora lì. Avevano solo cambiato leggermente nome. Ad esempio, uno spazio di memoria chiamato dalvik-allocspace main rosalloc in Android 8 è diventato dalvik-allocspace non moving in Android 15. L'edificio si era spostato, ma l'indirizzo non era cambiato.

Il Trucco del "Blueprint Magico"

La parte più entusiasmante dell'articolo è il "trucco magico" che hanno messo in atto. Poiché il telefono non ha una mappa, i ricercatori hanno deciso di prendere in prestito una mappa da una versione corrispondente.

Hanno preso la build "Developer" di Android 15 (che aveva ancora la mappa completa) e l'hanno usata per trovare l'offset esatto (la distanza in byte) di specifiche strutture. Poi, sono andati sul Pixel 7 "Production" (che non aveva la mappa) e hanno applicato quelle stesse distanze.

Ecco cosa è successo:

1. Hanno trovato l'oggetto "Runtime" (il gestore principale della memoria del telefono) usando un singolo simbolo che doveva restare per far funzionare il telefono.
2. Hanno usato la mappa "Developer" per trovare dove si trovasse l' "Heap" (lo stoccaggio dati) all'interno di quell'oggetto Runtime.
3. Hanno applicato quella distanza al telefono "Production".
4. Risultato: Ha funzionato perfettamente. Il puntatore che avevano calcolato portava esattamente allo stesso indirizzo di memoria valido sul telefono reale.

Hanno ripetuto questo processo per la "Thread List" e la "Bump Pointer Space", e ogni singola volta, il blueprint della versione developer li ha condotti nel punto corretto sul telefono di produzione depurato.

Cosa Significa per il Futuro

L'articolo suggerisce che, sebbene la "modalità facile" della forense sia finita, la partita non è persa. L'indurimento della sicurezza non ha rotto l'architettura della memoria; ha solo nascosto le etichette.

• La Buona Notizia: Il layout interno della memoria è preservato. Se hai una build "Developer" che corrisponde esattamente alla versione del telefono che stai investigando, puoi usare la sua mappa per navigare nel telefono depurato.
• La Cattiva Notizia: Non puoi usare una vecchia mappa. L'articolo nota che gli offset delle strutture cambiano tra le diverse versioni di Android (come tra Android 14 e 15). Quindi, non puoi usare una mappa di Android 8 per risolvere un caso di Android 15. Hai bisogno di un blueprint che corrisponda alla versione.
• Il Problema: Questo processo è ora molto più manuale. Gli investigatori non possono semplicemente eseguire uno strumento che dice "Trova Evidenza". Devono trovare la versione esatta del telefono, estrarre la build developer corrispondente, estrarre le distanze specifiche e poi applicarle manualmente.

I ricercatori hanno anche notato che hanno testato questo metodo solo su dispositivi Google Pixel. Non sono sicuri se altri produttori di telefoni (come Samsung o Xiaomi) abbiano fatto la stessa cosa o se abbiano completamente riorganizzato gli scaffali. Ma per i dispositivi testati, la conclusione è chiara: la città è ancora lì, gli edifici non si sono spostati, ma dovrai portare la tua mappa per orientarti.