> For the complete documentation index, see [llms.txt](https://blog.s1rn3tz.ovh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blog.s1rn3tz.ovh/pentest-mobile/android/corruption-de-memoire.md). # Corruption de Mémoire ## Outils #### AFL++ AFL++ est un outil de fuzzing de binaires et de code natif souvent utilisé pour chercher des vulnérabilités dans le code C/C++ dans le cas des applications mobiles. Ressource: #### LibFuzzer LibFuzzer est une librairie utilisée pour faire du fuzzing kernel généralement en association avec un autre moteur de fuzzing comme AFL. Ressource: #### Jazzer Jazzer est un outil de fuzzing de processes JVM basé sur LibFuzzer. Ressource: ## Description Chaque application a besoin de mémoire comme ressource pour faire son travail. Pour garantir que chaque application Android dispose de suffisamment de mémoire, le système Android doit gérer efficacement l’allocation de mémoire. Le runtime Android déclenche le Garbage Collection (GC) lorsque la mémoire est insuffisante. Le but de GC est de récupérer de la mémoire en nettoyant les objets qui ne sont plus utiles. Il y parvient en trois étapes. 1. Il Parcourt toutes les références d'objets en mémoire à partir des racines GC et marque les objets actifs qui ont des références à partir des racines GC. 2. Tous les objets non marqués (déchets) sont effacés de la mémoire. 3. Les objets vivants sont réorganisés. En bref, tout ce qui sert l'utilisateur doit être conservé en mémoire et tout le reste doit être effacé de la mémoire pour libérer des ressources. Cependant, lorsque le code est mal écrit et que les objets inutilisés sont référencés d'une manière ou d'une autre à partir d'objets accessibles, GC marque les objets inutilisés comme objets utiles et n'est donc pas en mesure de les supprimer. C'est ce qu'on appelle une fuite de mémoire. Sous Android, la réactivité des applications est surveillée par les services système Activity Manager et Window Manager. Android affiche la boîte de dialogue ANR pour une application particulière lorsqu'il détecte l'une des conditions suivantes: Il y a un délai de réponse supérieur à 5 secondes après un événement (key press, screen touch...) Un Broadcast Receiver n'a pas fini de s'executer après 10 secondes. ## Reconnaissance Avec [Leak Canary](https://github.com/square/leakcanary): Leak Canary crée des références faibles aux activités de votre application. (Vous pouvez également le personnaliser en ajoutant des montres à d'autres objets.) Il vérifie ensuite si la référence est effacée après GC. Sinon, il vide le tas dans un fichier .hprof et l'analyse pour confirmer s'il y a une fuite. S'il y en a un, il affiche une notification et dans une application distincte, il affiche l'arborescence de référence de la façon dont la fuite se produit. Avec Android Studio: 1. Compiler et lancer le debug build sur un appareil ou emulateur connecté à l'hôte. 2. Accédez à l'activité suspecte, puis revenez à l'activité précédente qui fera apparaître l'activité suspecte de la pile de tâches. 3. Dans Android Studio -> Fenêtre Android Monitor -> section Memory, cliquez sur le bouton Initiate GC. Cliquer ensuite sur le bouton Dump Java Heap. 4. Android Studio va alors ouvrir le dump .hprof. Dans le viewer du fichier, il y a plusieurs moyens de vérifier la présence de fuites mémoire. Il est possible d'utiliser l'outil Analyzer Tasks dans le coin en haut à droite pour détecter les fuites d'activités automatiquement. Une autre possibilité est de switcher vers la vue Package Tree View dans le coin en haut à gauche et de vérifier que la colonne Total Count pour les objets activités contient moins d'une instance. (Le cas contraire signifiant qu'il y a une fuite)
5. Une fois la fuite trouvée, il faut ensuite trouver dans le Reference Tree l'objet référencant l'activité qui devrait avoir été supprimée. ## Modèles de fuite courants Il existe de nombreuses façons de provoquer une fuite de mémoire dans Android. Pour résumer, il existe principalement trois catégories. * Fuite d'activité vers une référence statique * Fuite d'activité vers un worker thread * Fuite du thread lui-même Fuite d'activité vers une référence statique Fuite d'activité vers un worker thread Fuite du thread lui-même Lien utile: ## Fuite du mémoire dans code natif TODO ## Deserialization Java {% content-ref url="/pages/qd1JnlQiCWDZnXUT4KXl" %} [Insecure deserialization](/pentest-web/insecure-deserialization.md) {% endcontent-ref %} ## Android/Scudo ### Description Scudo est un **allocateur mémoire renforcé (hardened memory allocator)** développé dans l’écosystème LLVM et utilisé notamment dans Android pour rendre les bugs de corruption mémoire plus difficiles à exploiter. Son objectif principal est de **réduire l’impact des vulnérabilités mémoire** (comme les use-after-free, double free ou corruptions de heap) en ajoutant des mécanismes de détection et de durcissement autour des allocations. Ses principales caractéristiques : * **Séparation des métadonnées et des données utilisateur**\ → limite les corruptions directes de structures internes de l’allocateur. * **Vérifications d’intégrité**\ → détecte certaines incohérences lors des opérations d’allocation et de libération. * **Quarantaine des allocations libérées**\ → retarde la réutilisation de certaines zones mémoire afin de réduire les risques liés aux objets libérés puis réutilisés. * **Randomisation et durcissement du heap**\ → rend les comportements mémoire moins prévisibles. * **Détection de corruptions mémoire**\ → peut provoquer un arrêt contrôlé lorsqu’une incohérence est détectée plutôt que de laisser une corruption silencieuse continuer. Dans Android moderne, Scudo sert donc principalement de **barrière de sécurité entre un bug mémoire et une exploitation fiable**. Il ne supprime pas les erreurs de programmation, mais il augmente la difficulté nécessaire pour transformer une corruption mémoire en impact de sécurité significatif. ### Approche méthodologique #### Comprendre la classe de bug mémoire Le point de départ est toujours la primitive disponible : * **lecture hors limites (OOB read)**\ → risque principal : exposition d’informations sensibles. * **écriture hors limites (OOB write)**\ → risque principal : corruption de l’état d’un objet voisin. * **use-after-free (UAF)**\ → risque principal : réutilisation d’une zone mémoire avec un type inattendu. * **double free / corruption de gestion mémoire**\ → risque principal : incohérences internes de l’allocateur. Scudo ne "répare" pas le bug initial, il vise surtout à empêcher qu’une corruption mémoire devienne facilement exploitable. Les recherches modernes se concentrent davantage sur les conséquences applicatives : #### Corruption d’état d’un objet Plutôt que de viser l’allocateur lui-même, l’analyse porte souvent sur : * objets C/C++ voisins, * structures contenant des pointeurs, * états internes incohérents, * données métier critiques. La question devient : > "Quel état logique du programme peut être modifié par cette corruption ?" plutôt que : > "Comment détourner l’allocateur ?" ### Protections multi-layer Android Les systèmes Android récents utilisent plusieurs couches de mitigation : * ASLR * NX * CFI * PAC (selon matériel) * BTI * MTE (sur certains appareils) Cela signifie qu’un bug mémoire isolé ne donne généralement pas automatiquement un impact élevé. L’analyse de sécurité cherche donc à déterminer : * quelles informations peuvent être exposées. * quelles protections sont actives. * quelle surface est réellement affectée. ### Etapes Pour analyser un composant Android natif utilisant Scudo, les questions utiles sont : * Quelle entrée contrôle la taille ou l’index ? * Quelle est la durée de vie des objets concernés ? * Le bug touche-t-il des données utilisateur ou un état de contrôle ? * Quelles protections Android sont actives ? * Le bug est-il reproductible sous ASan/HWASan ? * Quelle est la conséquence fonctionnelle de la corruption ?