← Derniers articles
💻 computer science

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

Cette étude évalue la viabilité forensique de l'analyse de la mémoire Android à travers les versions de production d'Android 8 à 15, révélant que si le durcissement de la sécurité de Google a supprimé la plupart des symboles statiques et des références sources de libart.so, l'architecture mémoire sous-jacente demeure structurellement intacte, permettant aux outils forensiques de localiser toujours les points d'entrée d'exécution et de résoudre les structures de données en utilisant des versions de développement correspondantes.

Auteurs originaux : Jayasimha Nannapanen, Sneha Sudhakaran

Publié 2026-07-16
📖 7 min de lecture🧠 Analyse approfondie

Auteurs originaux : Jayasimha Nannapanen, Sneha Sudhakaran

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que votre smartphone soit une ville animée et hautement sécurisée. À l'intérieur de cette ville, vos applications sont comme des boutiques très fréquentées, et la RAM (la mémoire) est l'espace de travail temporaire où toutes les transactions actuelles se déroulent. Lorsque vous envoyez un message secret ou que vous vous connectez à un compte, les données existent dans cet espace de travail pendant un instant avant d'être supprimées ou déplacées vers le disque dur. La forensique numérique est l'art de s'introduire furtivement dans cet espace de travail pour saisir des preuves avant qu'elles ne disparaissent. Mais voici le hic : les architectes de la ville (Google) construisent des murs de plus en plus hauts et suppriment les panneaux de signalisation. Autrefois, les enquêteurs pouvaient entrer avec une carte (les symboles de débogage) qui leur indiquait exactement où se trouvait la boutique « Message Secret ». Désormais, la ville a été dépouillée de ces panneaux pour rendre l'intrusion des hackers plus difficile, laissant les enquêteurs face à un mur blanc, se demandant si les boutiques sont même encore là.

Ce document est une histoire de détective pour savoir si ces boutiques sont toujours debout, même si les panneaux ont disparu. Les chercheurs ont posé la question suivante : « Google a retiré les cartes des téléphones que nous achetons réellement, mais a-t-il aussi déplacé les bâtiments ? » Ils ont comparé les versions « blueprint » (le plan) du système Android (que les développeurs utilisent et qui possèdent des cartes complètes) par rapport aux versions « production » (celles que les gens ordinaires reçoivent, avec tous les panneaux supprimés). Ils ont découvert que si les panneaux de signalisation ont bien disparu, les bâtiments eux-mêmes n'ont pas bougé. La disposition de la mémoire reste la même ; elle n'a juste plus d'étiquette de nom. Cela signifie qu'avec un peu de travail de détective supplémentaire — en utilisant un plan d'une version correspondante de la ville — les enquêteurs peuvent toujours trouver les preuves, même sur les téléphones les plus modernes et les plus protégés.

Le grand vol de cartes

Pendant des années, les experts en forensique numérique se sont appuyés sur un fichier de bibliothèque appelé libart.so pour naviguer dans la mémoire chaotique des téléphones Android. Considérez ce fichier comme l'annuaire principal d'une immense bibliothèque. À l'intérieur, il y avait une liste complète de chaque livre, de chaque étagère et de l'emplacement exact de chaque paragraphe. Ces listes étaient appelées « symboles ». Si un enquêteur voulait trouver une preuve spécifique, comme un message de chat décrypté, il lui suffisait de chercher le symbole « chat » dans l'annuaire, et pouf, l'outil savait exactement où chercher dans la mémoire.

Mais Google, voulant rendre les téléphones plus sûrs contre les hackers, a lancé une campagne de « durcissement » (hardening). Ils ont réalisé que si un hacker possédait l'annuaire complet, il pourrait facilement trouver des failles pour s'introduire dans le système. Ils ont donc commencé à retirer ces annuaires des téléphones qui sont réellement vendus en magasin. Ils ont supprimé les symboles statiques (la liste principale), les références aux fichiers sources (les notes de l'auteur) et la plupart des symboles dynamiques. C'était comme prendre une bibliothèque et retirer le catalogue de fiches, ne laissant que quelques étiquettes essentielles sur les portes pour que les bibliothécaires puissent toujours les ouvrir, tout en cachant tout le reste.

La grande question était : ont-ils seulement retiré les étiquettes, ou ont-ils aussi réorganisé les étagères ? Si les étagères avaient bougé, alors même si un enquêteur possédait un plan d'une ancienne version de la bibliothèque, cela ne servirait à rien.

Le travail de détective

Pour résoudre cela, les chercheurs ont agi comme des bibliothécaires voyageant dans le temps. Ils ont récupéré deux versions du système Android :

  1. Le build « Développeur » : Une version avec l'annuaire complet, non dépouillé (le plan).
  2. Le build « Production » : La version qui fonctionne réellement sur un Google Pixel 7 (la réalité dépouillée).

Ils ont d'abord examiné les chiffres. Dans l'ancienne version Android 8, la bibliothèque possédait 20 495 symboles statiques. Dans la nouvelle version Android 15, ce nombre est tombé à zéro. Les références aux fichiers sources, qui indiquaient de quel fichier de code provenait une fonction, ont également totalement disparu. Les symboles dynamiques (les quelques étiquettes qui devaient rester pour que le téléphone fonctionne) ont chuté d'environ 60 pour cent, passant de 6 577 à 2 614.

Cela ressemblait à un désastre pour la forensique. Mais ensuite, ils ont regardé plus profondément. Ils ont vérifié la structure réelle de la mémoire — les « étagères » et les « livres » eux-mêmes. Ils ont comparé les cartes mémoire d'un téléphone Android 8 et d'un téléphone Android 15. Ils ont constaté que les structures de base, comme le « heap » (où les applications stockent leurs données) et le « garbage collector » (qui nettoie les anciennes données), étaient toujours là. Elles avaient simplement changé de nom légèrement. Par exemple, un espace mémoire appelé dalvik-allocspace main rosalloc dans Android 8 est devenu dalvik-allocspace non moving dans Android 15. Le bâtiment a bougé, mais l'adresse n'a pas changé.

Le tour de magie du « Plan Magique »

La partie la plus excitante de l'article est le « tour de magie » qu'ils ont réalisé. Puisque le téléphone lui-même n'a pas de carte, les chercheurs ont décidé d'emprunter une carte à une version correspondante.

Ils ont pris la version « Développeur » d'Android 15 (qui possède toujours la carte complète) et l'ont utilisée pour trouver l'offset exact (la distance en octets) de structures spécifiques. Ensuite, ils sont allés sur le Pixel 7 de « Production » (qui n'a pas de carte) et ont appliqué ces mêmes distances.

Voici ce qui s'est passé :

  1. Ils ont trouvé l'objet « Runtime » (le gestionnaire principal de la mémoire du téléphone) en utilisant un seul symbole qui devait rester pour que le téléphone fonctionne.
  2. Ils ont utilisé la carte « Développeur » pour trouver où se situait le « Heap » (le stockage de données) à l'intérieur de cet objet Runtime.
  3. Ils ont appliqué cette distance au téléphone de « Production ».
  4. Résultat : Cela a parfaitement fonctionné. Le pointeur qu'ils ont calculé menait exactement à la même adresse mémoire valide sur le vrai téléphone.

Ils ont répété l'opération pour la « Thread List » (liste des threads) et le « Bump Pointer Space », et à chaque fois, le plan de la version développeur les a menés au bon endroit sur le téléphone de production dépouillé.

Ce que cela signifie pour l'avenir

L'article suggère que si le « mode facile » de la forensique est terminé, la partie n'est pas perdue. Le durcissement de la sécurité n'a pas brisé l'architecture de la mémoire ; il a simplement caché les étiquettes.

  • La bonne nouvelle : La disposition interne de la mémoire est préservée. Si vous possédez une version « Développeur » qui correspond exactement à la version du téléphone que vous enquêtez, vous pouvez utiliser son plan pour naviguer dans le téléphone dépouillé.
  • La mauvaise nouvelle : Vous ne pouvez pas simplement utiliser un ancien plan. L'article note que les décalages de structure (offsets) changent entre les différentes versions d'Android (comme Android 14 vs 15). Vous ne pouvez donc pas utiliser un plan d'Android 8 pour résoudre un cas sur Android 15. Vous avez besoin d'un plan correspondant à la version.
  • Le bémol : Ce processus est désormais beaucoup plus manuel. Les enquêteurs ne peuvent pas simplement lancer un outil qui dit « Trouver les preuves ». Ils doivent trouver la version exacte du téléphone, extraire le build développeur correspondant, extraire les distances spécifiques, puis les appliquer manuellement.

Les chercheurs ont également noté qu'ils n'ont testé cela que sur des appareils Google Pixel. Ils ne sont pas certains si d'autres fabricants de téléphones (comme Samsung ou Xiaomi) ont fait la même chose ou s'ils ont entièrement réorganisé les étagères. Mais pour les appareils qu'ils ont testés, la conclusion est claire : la ville est toujours là, les bâtiments n'ont pas bougé, mais vous devrez apporter votre propre carte pour trouver votre chemin.

Noyé(e) sous les articles dans votre domaine ?

Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.

Essayer Digest →