UNIVERISTE MOHAMMED PREMIER ‫جامعة محمد األول‬

École Nationale des Sciences Appliquées ‫المدرسة الوطنية للعلوم التطبيقية وجدة‬
Oujda

Mémoire de Projet du Module Analyse d’Évidence

Terminaux Mobiles

Spécialité : Sécurité Informatique & Cyber-Sécurité

Sujet intitulé:

Android memory
forensics

Présenté par : Sous la direction de :

FILALI Abdelilah Mr. KOULALI MOHAMMED AMINE

RAGGUI Salah Eddine
RAHMANI Mohamed

Année universitaire 2023-2024

TABLE DE MATIERES

ABSTRACT ..............................................................................................................1
INTRODUCTION GÉNÉRAL ...............................................................................2
Chapitre 1: Acquisition de mémoire.......................................................................3
1.1 Outils d'exploitation utilisés dans le projet ..................................................3
1.2 Compiler un noyau Linux ..............................................................................4
1.2.1 Installation de l'environnement de compilation ....................................4
1.2.2 Compilation et exécution du noyau Goldfish (AVD) .............................4
1.3 Compilation de LiME .....................................................................................6
1.4 Acquisition d'une image mémoire .................................................................6
1.5 Remplacement de l'image de démarrage d'origine .....................................7
Chapitre 2: Techniques d'analyse de la mémoire Android ..................................9
2.1 Création d'un profil de Volatility ..................................................................9
2.2 Analyse de la mémoire avec Volatility .........................................................12
2.2.1 Linux_arp ................................................................................................13
2.2.2 linux_route_cache ...................................................................................13
2.2.3 linux_enumerate_files ............................................................................14
2.2.4 linux_lsof ..................................................................................................14
2.2.5 Analyse de la mémoire physique ...........................................................15
2.2.6 Correspondance de motifs ....................................................................15
2.2.7 Information sur le réseau .......................................................................18
Conclusion Générale ..............................................................................................19
Bibliographie ..........................................................................................................20
ABSTRACT

Android memory forensics is an indispensable facet of digital forensics that meticulously examines
the volatile memory (RAM) of Android devices. Given Android's global dominance in the
smartphone market, this field encounters distinctive challenges stemming from the varied
landscape of manufacturers, device architectures, and Android versions. This abstract delves into
the pivotal role of Android memory forensics, highlighting its significance in extracting real-time
information essential for comprehensive digital investigations.
The diversity inherent in Android devices necessitates tailored approaches to memory forensics,
addressing nuances in acquisition and analysis methods. This process unveils critical details,
including active processes, network connections, and encryption keys, enriching investigations
beyond the capabilities of traditional forensic methodologies. The real-time nature of Android
memory forensics proves instrumental in revealing dynamic data, such as user interactions,
running applications, and potential security threats.
Acquisition techniques primarily rely on software-based methods, involving the execution of
specialized tools or scripts directly on live Android devices. Selecting appropriate techniques
requires consideration of factors such as device rooting, Android version, and manufacturer-
specific intricacies. Furthermore, the diversity within the Android ecosystem demands forensic
analysts to adapt methodologies to device-specific characteristics, ensuring a nuanced
understanding of volatile memory content. This adaptability extends to addressing encryption
mechanisms and variations in Android OS implementations.
In conclusion, Android memory forensics emerges as a crucial component in the investigative
arsenal, offering unparalleled insights into the dynamic and diverse landscape of Android devices.
Successfully navigating the challenges posed by this ecosystem enhances the capacity to uncover
vital information, empowering cybersecurity and legal professionals engaged in digital forensic
examinations.

Page | 1
INTRODUCTION GÉNÉRAL

Android est devenu le système d'exploitation le plus vendu au monde sur les smartphones depuis
2011, le nombre d'appareils Android actifs mensuels dépassait les deux milliards. En conséquence,
la capacité à analyser les appareils Android à des fins d'enquête légale est devenue cruciale.
Une zone importante dans le domaine de l'analyse légale concerne l'étude de la mémoire volatile.
Cette mémoire volatile renferme une multitude d'informations sur les systèmes d'exploitation et
les logiciels utilisateurs. Certaines de ces données, comme les artefacts réseau et les mots de passe,
ne sont pas stockées dans la mémoire flash non volatile. D'autres artefacts, comme les messages
texte, sont souvent chiffrés avant d'être enregistrés dans la mémoire flash, mais résident toujours
en texte clair dans la mémoire vive.
Si l'analyse de la mémoire volatile des systèmes d'exploitation Windows et Linux est devenue une
pratique courante pour les enquêteurs légaux et les analystes de logiciels malveillants, cela ne
semble pas être le cas pour les appareils Android. L'analyse de la mémoire volatile d'Android
demeure une lacune pour de nombreux analystes.
Ce projet propose une approche pratique pour l'acquisition et l'analyse basées sur des logiciels de
la mémoire volatile des appareils Android. Le terme "basé sur des logiciels" se réfère à la méthode
d'acquisition qui consiste à exécuter un logiciel sur un appareil Android en direct. L'article aborde
également l'analyse de l'image mémoire et démontre quelques techniques pour extraire des
données système et des applications utilisateur pertinentes de la mémoire. Suivre la même
approche devrait permettre d'identifier et d'extraire bien plus d'informations pertinentes.
Il est important de noter que la méthode exacte pour acquérir et analyser la mémoire Android
dépend de nombreux facteurs, tels que le fabricant de l'appareil, la version d'Android, la version
du noyau, la configuration, l'architecture du processeur, et d'autres encore. Par conséquent, cet
article ne prétend pas être un manuel complet pour tous les appareils Android possibles, mais
l'application de la même approche devrait permettre d'analyser la mémoire de la plupart d'entre
eux, bien que dans certains cas avec certaines limitations.

Page | 2
Chapitre 1: Acquisition de mémoire

1.1 Outils d'exploitation utilisés dans le projet

Android Virtual Device (AVD)

Un AVD est une configuration qui définit le caractéristiques d'un appareil Android. Ce dispositif peut
être simulé dans le Émulateur Android, qui fait partie de Android Studio.

Volatility
Un outil open source en Python pour extraire des artefacts numériques de la mémoire
volatile. Il permet d'analyser l'état d'un système sans altérer son fonctionnement et sert à
comprendre les activités en cours lors d'une enquête forensique.

CyanogenMod
CyanogenMod est un système d'exploitation de remplacement sur plus de 70 smartphones
et tablettes, construit sur Android. Il offre des fonctionnalités et des options indisponibles
sur les versions d’Android distribuées par les vendeurs sur leurs appareils.

linux memory extractor (LiMe)

Est un module de noyau chargeable, qui permet l'acquisition de mémoire volatile à partir de Linux et
d'appareils basés sur Linux, tels que ceux alimentés par Android.

goldfish kernel
créé par Google sera utilisé avec Android Studio émulateur. Il contient des suppléments fonctionnalité qui
permet à l'hôte du émulateur pour interagir avec l’AVD. La compilation de l'émulateur Goldfish est un
prérequis pour compiler le LiME module. L'image du noyau résultante peut également être utilisé pour
émuler l'AVD, qui s'assure que le module LiME est compatible de manière optimale avec l'AVD.

Page | 3
1.2 Compiler un noyau Linux

• Objectif: Mettre en place un environnement de compilation pour le noyau Android.

• But: Compiler le noyau Goldfish pour les émulateurs Android et générer un fichier
d'image de noyau utilisable.

Le noyau du système d'exploitation Android est basé sur le noyau Linux, ce qui rend le processus
de compilation similaire à celui d'un noyau de bureau ou de serveur Linux classique. Pour
démarrer, il est nécessaire de mettre en place un environnement de construction Android sur votre
hôte.

1.2.1 Installation de l'environnement de compilation

La configuration de l'environnement de compilation Android implique l'installation de logiciels

nécessaires à la compilation du code source et des noyaux Android. Cette étape requiert un
système Linux ou Mac, Windows n'étant actuellement pas pris en charge. Le processus démontré
est adapté pour un hôte Ubuntu 18.04 en 64 bits.

Pour un système Ubuntu 18.04 en 64 bits, la commande suivante installe les paquets requis :

$ sudo apt install git-core gnupg flex bison build-essential curl g++-multilib lib32ncurses5-dev
lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc

1.2.2 Compilation et exécution du noyau Goldfish (AVD)

Le noyau Goldfish a été développé par Google pour être utilisé avec l'émulateur d'Android Studio.
Il intègre des fonctionnalités supplémentaires permettant à l'hôte de l'émulateur d'interagir avec
l'AVD. Compiler le noyau Goldfish est une étape préalable à la compilation du module LiME.
L'image du noyau résultante peut également être utilisée pour émuler l'AVD créé, assurant ainsi
une compatibilité optimale avec le module LiME. De plus, la compilation du noyau générera le
fichier System.map, l'un des deux fichiers nécessaires à la création d'un profil Volatility, utilisé
pour analyser l'image mémoire avec Volatility.

✓ Clonage du noyau Goldfish à partir de googlesource.com :

$ git clone https://android.googlesource.com/kernel/goldfish
✓ Sélection d'une branche du noyau :

$ cd goldfish
$ git branch -a

Page | 4
 $ git checkout remotes/origin/android-goldfish-3.18

✓ Choix d'un compilateur pour la compilation croisée du code source :

$ git clone --depth=1 https://android.googlesource.com/platform/prebuilts/gcc/linux-

x86/arm/arm-eabi-4.8

✓ Configuration des variables du Makefile :

• ARCH=arm pour indiquer que le noyau sera compilé pour une architecture ARM.
• CROSS_COMPILE pour définir le préfixe commun des exécutables utilisés lors de la
compilation.

✓ Configuration du fichier .config :

• Extrait du fichier de configuration original de l'appareil cible via ADB.

• Copie de ce fichier dans le répertoire du noyau Goldfish.
• Exécution de make menuconfig pour configurer les fonctionnalités du noyau, notamment le
support des modules chargeables requis par LiME

✓ Compilation du noyau :
$ make modules_prepare
$ make

✓ Lorsque la compilation est terminée avec succès, l'image du noyau (zImage) se trouve dans le
répertoire arch/arm/boot.

✓ Lancement de l'AVD avec la nouvelle image du noyau

$ cd ~/Android/Sdk/emulator
$ ./emulator -avd Nexus_5_API_23 -kernel ~/goldfish/arch/arm/boot/zImage -show-
kernel -verbose

Ces étapes détaillées permettent de comprendre le processus de compilation du noyau

Goldfish pour un AVD, ainsi que les différentes configurations et commandes requises
pour cette opération.

Page | 5
1.3 Compilation de LiME

• Objectif: Compiler le module LiME pour capturer des images de mémoire.

• But: Créer un module capable d'extraire et de sauvegarder la mémoire du périphérique
Android.

La première étape pour compiler LiME consiste à cloner son code source sur votre système hôte.
✓ Clonage du code source de LiME:
$ git clone --depth=1 https://github.com/504ensicsLabs/LiME.git
$ cd LiME/src

✓ Modification du Makefile:
Éditez le fichier Makefile pour inclure plusieurs chemins et informations essentielles :
• KDIR : Chemin vers le noyau cible compilé.
• CCPATH : Chemin vers le compilateur croisé utilisé pour compiler le code source du
noyau.
• KVER : Version du noyau cible.
• ARCH : Architecture du noyau cible.

Figure 1: Malefile

✓ Compilation du module LiME:

$ make clean
$ make

1.4 Acquisition d'une image mémoire

• Objectif: Transférer le module LiME vers le périphérique cible et capturer l'image de la

mémoire.
• But: Obtenir une copie de la mémoire du périphérique pour une analyse ultérieure.

À ce stade, l'acquisition du contenu de la mémoire nécessite le chargement du module LiME dans

le noyau du périphérique cible. Voici les étapes détaillées:

Page | 6
 ✓ Copie du module LiME sur le périphérique cible:
Utilisez la commande adb push pour copier le module LiME sur le périphérique cible. Si
le système de fichiers est en lecture seule, vous devez le remonter en écriture:

$ ~/Android/Sdk/platform-tools/adb push ~/Android/LiME/src/lime-goldfish.ko

/sdcard/lime-goldfish.ko

# Remontez le système de fichiers en écriture

$ ~/Android/Sdk/platform-tools/adb shell
root@kali:/ # su
root@kali:/ # mount -o rw,remount rootfs /

✓ Chargement du module LiME sur le périphérique cible:

Une fois le module LiME copié, ouvrez un shell avec des privilèges root sur le périphérique et
chargez le module LiME via la commande insmod:
$ ~/Android/Sdk/platform-tools/adb shell
root@kali:/ # su
root@kali:/ # cd /sdcard/
root@kali:/ # insmod lime-goldfish.ko "path=android.lime format=lime"

✓ Acquisition de l'image mémoire:

Après le chargement du module, celui-ci commencera à écrire le contenu de la mémoire dans un
fichier. Copiez ce fichier sur votre ordinateur avec la commande adb pull:
$ ~/Android/Sdk/platform-tools/adb pull /sdcard/android.lime

À ce stade, l'acquisition de l'image complète de la mémoire de l'AVD émulée sur l'hôte devrait être réussie.
L'examen de l'image mémoire avec l'utilitaire strings a révélé des données valides telles que des noms
d'applications, des URL, et bien d'autres informations.

1.5 Remplacement de l'image de démarrage d'origine

• Objectif: Modifier temporairement l'image de démarrage du périphérique pour y injecter

un noyau personnalisé.
• But: Tester un noyau personnalisé sans modifier l'image d'origine du périphérique.

Pour remplacer le noyau d'origine sur le périphérique cible par une image de noyau compilée
personnalisée, une nouvelle image de démarrage doit être créée. Une image de démarrage se
compose d'une image de noyau et d'un ramdisk.

✓ Extraction de l'image de démarrage d'origine:

Pour conserver le périphérique cible le plus proche possible de son état d'origine, il est recommandé
d'extraire et de modifier l'image de démarrage d'origine. Les commandes suivantes copient l'image
de démarrage d'un Nexus 5 vers son stockage partagé (sdcard) et la récupèrent sur l'ordinateur hôte
via adb:

$ ~/Android/Sdk/platform-tools/adb shell Nexus 5

shell@kali:/ $ su

Page | 7
 root@kali:/ # cp /dev/block/platform/msm_sdcc.1/by-name/boot /sdcard/boot.img
$ ~/Android/Sdk/platform-tools/adb pull /sdcard/boot.img boot.img

✓ Modification de l'image de démarrage avec les outils CyanogenMod:

Utilisez les outils CyanogenMod (mkbootimg et unpackbootimg) pour modifier l'image de
démarrage. Ces outils peuvent être clonés depuis le référentiel android_system_core sur Github:
$ git clone --depth=1 https://github.com/CyanogenMod/android_system_core.git

# Copie optionnelle des outils dans /usr/bin pour les ajouter au $PATH:
$ sudo cp android_system_core/mkbootimg/mkbootimg /usr/bin
$ sudo cp android_system_core/mkbootimg/unpackbootimg /usr/bin

✓ Déballage de l'image de démarrage d'origine:

Utilisez unpackbootimg pour extraire les composants de l'image de démarrage:
$ unpackbootimg -i boot.img

✓ Création d'une nouvelle image de démarrage avec le noyau personnalisé:

Utilisez les données extraites pour créer une nouvelle image de démarrage avec le noyau
personnalisé :

$ mkbootimg --kernel path/to/zImage-dtb --ramdisk boot.img-ramdisk.gz --cmdline

boot.img-cmdline --base boot.img-base --pagesize boot.img-pagesize --output new-
boot.img

✓ Amorçage du périphérique Android avec la nouvelle image de démarrage:

Utilisez fastboot pour amorcer temporairement le périphérique à partir de la nouvelle image de
démarrage :
$ sudo fastboot boot new-boot.img

✓ Vérification du démarrage avec la nouvelle image:

Le périphérique devrait démarrer comme d'habitude, sans différence notable, sauf la capacité à
charger des modules de noyau. Aucune modification permanente n'a été apportée à l'image
d'origine, donc tout dysfonctionnement peut être corrigé en redémarrant le périphérique.

Page | 8
Chapitre 2: Techniques d'analyse de la mémoire Android

2.1 Création d'un profil de Volatility

Un profil de Volatility est un fichier qui contient des informations sur un noyau spécifique,
nécessaires à Volatility pour localiser et reconstruire des données à partir d'une image mémoire
dans un format structuré. Volatility inclut des profils préfabriqués pour Windows, ce qui signifie
que les images mémoire Windows peuvent être analysées sans avoir à créer un profil. Cependant,
Volatility n'inclut aucun profil Linux. La raison en est qu'il existe trop de versions de noyau Linux
différentes pour inclure un profil pour chaque version. Par conséquent, il revient généralement à
l'analyste de créer un profil de Volatility pour l'analyse des images mémoire Linux ou Android.
Un profil de Volatility pour Linux est une archive ZIP qui contient deux fichiers : System.map et
module.dwarf. System.map contient une correspondance entre tous les noms de symboles de
l'image du noyau Linux et leurs adresses en mémoire. Ce fichier System.map est généré lors de la
compilation du noyau. La capture d'écran suivante montre les premières lignes (sur plus de 80 000)
du System.map du noyau stock du notre Virtual Device:

Figure 2: System.map for AVD

Le deuxième fichier qui fait partie du profil Volatility est appelé module.dwarf. Ce fichier contient
une collection de VTypes. Ce sont des définitions de structures utilisées par Volatility pour
représenter les structures de données en C (utilisées par le noyau Linux) en Python (utilisé par
Volatility). Ci-dessous, voici un exemple simplifié de la façon dont une structure de données en C
est représentée en tant que VType.

Figure 3: VTypes

Page | 9
Le nom de la structure (proc) devient le nom d'une clé de dictionnaire, qui contient les membres
ainsi que leurs types et leur décalage par rapport à la base de la structure (dans cet exemple, un
entier, un tableau de caractères et un pointeur vers une chaîne de caractères).
Le fichier module.dwarf est obtenu en compilant un module noyau factice qui déclare des membres
de tous les types nécessaires à Volatility pour le noyau cible, puis en extrayant les symboles
DWARF du module factice avec l'outil dwarfdump. Le code source de ce module est inclus dans
le référentiel de Volatility et se trouve à l'emplacement volatility/tools/linux/module.c. Notez que
la compilation du module instruira automatiquement l'outil dwarfdump pour extraire les symboles
DWARF du module résultant, donc dwarfdump doit être installé au préalable:

Figure 4: Installation de dwarfdump

La prochaine étape consiste à cloner Volatility depuis Github et à éditer le Makefile du module
factice (module.c), qui se trouve dans le répertoire volatility/tools/linux.
$ git clone --depth=1 https://github.com/volatilityfoundation/volatility.git
$ cd ~/volatility/tools/linux

Figure 5: Cloning du repository du Volatility

Page | 10
Le Makefile doit être modifié pour inclure le chemin vers le noyau cible compilé (KDIR), le
chemin vers le compilateur croisé utilisé pour compiler le code source du noyau (CCPATH), la
version du noyau cible (KVER) et son architecture (ARCH). Notez que dans la capture d'écran
suivante, la variable CROSS_COMPILE est définie comme CCPATH suivie de arm-eabi-. Cela
peut nécessiter d'être modifié pour correspondre au préfixe commun de tous les exécutables situés
dans le répertoire bin du compilateur croisé.

Figure 6: Modification du Makefile

À présent, le module factice peut être compilé en exécutant la commande make. Cela produira le
module appelé module.ko et, comme indiqué par le Makefile, l'outil dwarfdump extraira les
symboles DWARF de ce module et les écrira dans un nouveau fichier appelé module.dwarf. La
capture d'écran suivante montre le début du fichier module.dwarf qui a été créé pour le Nexus 5.

La dernière étape pour créer un profil Volatility pour Linux consiste à ajouter les fichiers
System.map et module.dwarf dans une archive ZIP.
$ zip Nexus5.zip module.dwarf System.map

La création du profil Volatility est désormais terminée, et l'utilisation de ce profil avec Volatility
est démontrée dans la section suivante. Il est important de noter que dans certains cas, le profil
peut ne pas être compatible avec le noyau standard en cours d'exécution sur l'appareil cible. Si tel
est le cas, Volatility générera l'erreur "Aucune correspondance d'espace d'adressage appropriée
trouvée" lors de la tentative d'exécution de tout plugin. Cette erreur indique probablement une
disparité entre le noyau en cours d'exécution sur l'appareil cible et le noyau cross-compilé sur votre
machine hôte. Ces différences peuvent résulter de l'utilisation d'options de compilation différentes
de celles employées par le fabricant.
Les solutions possibles consistent à recompiler le code source du noyau avec différentes options
(un fichier .config différent) ou à flasher le noyau compilé sur votre machine hôte sur l'appareil
cible afin d'éliminer toute incohérence. Ces actions visent à garantir une concordance entre les
configurations du noyau utilisées lors de la compilation, car des divergences dans ces options
peuvent avoir un impact significatif sur l'image du noyau résultante.

Page | 11
2.2 Analyse de la mémoire avec Volatility

En général, Volatility requiert trois paramètres en ligne de commande: le nom du fichier de l'image
mémoire (--filename ou -f), le nom du profil à utiliser (--profile), et le plugin à exécuter (spécifié
sans aucun paramètre préfixe). Lors de l'analyse d'images mémoire non Windows, le répertoire
contenant le profil Volatility (le fichier ZIP créé dans la section précédente) doit également être
transmis à Volatility via le paramètre --plugins. Ce répertoire peut également contenir des plugins
Volatility tiers (fichiers Python), qui étendent les fonctionnalités de Volatility. Notez que le
paramètre --plugins doit être le premier paramètre transmis à Volatility, sinon il ne sera pas traité.
Avant que la commande complète de Volatility puisse être construite, le nom du profil créé dans
la section précédente doit être identifié. Cela peut être fait en exécutant Volatility avec le paramètre
--info.

Figure 7: Goldfish Profile

Lors de l'exécution de cette commande, Volatility analysera le contenu du répertoire des profils et
inclura une liste des profils valides dans sa sortie. Tout profil personnalisé devrait être répertorié
dans la sortie au-dessus des profils Windows intégrés. Le nom du profil personnalisé est basé sur
le nom de fichier de l'archive ZIP. Dans cet exemple, l'archive ZIP était appelée Nexus5.zip, ce qui
a fait apparaître le texte "Nexus5" dans le nom du profil. Volatility a détecté que le profil est adapté
à une image mémoire d'un système avec un noyau Linux et une architecture ARM, et a ajouté cette
information au nom du profil. Cela a donné le nom de profil LinuxNexus5ARM. C'est le nom du
profil qui doit être transmis à Volatility via le paramètre --profile dans cet exemple. Étant donné
qu'Android est un système d'exploitation basé sur Linux, les plugins Linux doivent être utilisés
pour analyser la mémoire Android. Les noms des plugins compatibles avec Linux sont préfixés
par linux_. Une vue d'ensemble de ces plugins est incluse dans la sortie info de la commande
précédente. La capture d'écran suivante montre un exemple de commande Volatility qui exécute le
plugin linux_pslist. Ce plugin extrait une liste des processus en cours d'exécution à partir de l'image
mémoire. Notez que la capture d'écran est rognée pour inclure uniquement les premiers processus.

Page | 12
 Figure 8: commande linux_pslist

2.2.1 Linux_arp

Le plugin linux_arp extrait la table de cache ARP de l'image mémoire. Le cache ARP conserve
les adresses MAC qui ont été résolues via le protocole de résolution d'adresses (ARP). Ce
cache peut fournir une vue sur les systèmes auxquels le périphérique mobile s'est récemment
connecté dans le même sous-réseau.

Figure 9: commande linux_arp

Dans la capture d'écran ci-dessus, l'adresse IP 192.168.1.1 est visible. Cette adresse IP correspond
généralement à l'adresse IP de la passerelle par défaut. Ces informations pourraient aider à indiquer
que l'appareil Android s'est connecté à un point d'accès sans fil particulier, en faisant correspondre
l'adresse MAC dans cette sortie de commande à l'adresse MAC du point d'accès correspondant.
D'autres artefacts tels que les SSID des points d'accès enregistrés, les données de l'application de
cartes et les données GPS peuvent également contribuer à localiser ce point d'accès sans fil.

2.2.2 linux_route_cache

Le plugin linux_route_cache extrait le cache de routage de l'image mémoire. Ce cache peut fournir
une vue sur les adresses IP auxquelles l'appareil Android s'est connecté. Les connexions à ces
adresses IP pourraient avoir été initiées par n'importe quel logiciel sur l'appareil, y compris le
système d'exploitation, les applications système et les applications utilisateur.

Page | 13
 Figure 10: commande linux_route_cache

2.2.3 linux_enumerate_files

Le plugin linux_enumerate_files peut trouver des fichiers et des répertoires en mémoire en

identifiant et en analysant les structures du système de fichiers. Le plugin produit en sortie l'adresse
de l'inode, le numéro d'inode et le chemin du fichier.

Figure 11: commande linux_enumerate_files

Le noyau Linux utilise un cache de pages pour sauvegarder le contenu des fichiers chargés en
mémoire afin d'améliorer les performances. Le plugin linux_find_file peut extraire des fichiers de
ce cache de pages. Cependant, l'utilisation de ce plugin pour extraire des fichiers de la mémoire de
plusieurs dispositifs AVD et d'un appareil Android Nexus 5 a donné des résultats médiocres. Plus
précisément, la plupart des fichiers extraits ne pouvaient pas être ouverts par les applications
appropriées (en fonction de l'extension de fichier), et l'utilitaire file ne reconnaissait pas la plupart
des fichiers extraits comme un type de fichier particulier, ce qui indique que les fichiers extraits
étaient corrompus. Heureusement, il est toujours possible d'extraire des fichiers valides de la
mémoire en utilisant des techniques de file carving, comme le montre la section suivante.
2.2.4 linux_lsof

Le plugin linux_lsof affiche une liste des fichiers ouverts, similaire à la commande lsof sur Linux.
Ce plugin peut fournir plus de contexte sur les fichiers en mémoire car il montre quel processus a
ouvert quel fichier. Par exemple, si une image a été ouverte par une application de messagerie, cela
pourrait indiquer que l'image a été envoyée ou reçue via l'application. Notez qu'il existe d'autres

Page | 14
raisons pour lesquelles une application de messagerie pourrait ouvrir des images, par exemple,
pour permettre à l'utilisateur de parcourir les images sur l'appareil afin d'en sélectionner une ou
plusieurs à envoyer. Le répertoire dans lequel l'image est stockée et les données de la conversation
de l'application de messagerie pourraient être examinés plus en détail pour obtenir une indication
de la manière dont l'image a été traitée (envoyée ou reçue).

Figure 12: commande linux_lsof

2.2.5 Analyse de la mémoire physique

Actuellement, Volatility ne dispose pas de plugins pour extraire des données utilisateur à partir
d'applications Android. Chaque application stocke ses données différemment en mémoire et en
raison du grand nombre d'applications Android, dont beaucoup sont régulièrement mises à jour, il
serait peu pratique de rédiger et de maintenir des plugins pour extraire les données de chaque
application. Cependant, des données d'application pertinentes peuvent toujours être obtenues en
utilisant des techniques générales d'analyse de chaînes et de découpage linéaire de fichiers.
Bien qu'il soit possible d'extraire des artefacts directement à partir d'une image mémoire physique,
il est généralement recommandé de rechercher et d'extraire des données de la mémoire des
processus. La principale raison en est que l'espace d'adressage virtuel d'un processus est continu,
contrairement aux données dans une image mémoire physique. Plus précisément, des données qui
traversent les limites de page dans l'espace d'adressage virtuel peuvent être réparties sur plusieurs
emplacements dans la mémoire physique. En conséquence, les signatures peuvent ne pas
correspondre à ces motifs dans la mémoire physique. Cela est particulièrement pertinent à prendre
en compte lors du découpage de fichiers en mémoire qui sont plus grands que la taille de page, qui
est généralement de 4 ko.

2.2.6 Correspondance de motifs

Un autre avantage de l'analyse de la mémoire des processus est que vous savez à quel processus
appartiennent les motifs correspondants. Ce contexte est important pour déterminer la signification
et la pertinence des données en mémoire et serait manqué lors de l'analyse directe de l'image

Page | 15
mémoire physique. Un autre avantage de l'analyse de la mémoire des processus est que les données
des processus non pertinents sont filtrées, ce qui résulte potentiellement en moins de
correspondances non pertinentes.
L'analyse de la mémoire physique peut encore être utile dans certains cas, par exemple lors de la
recherche de données liées à des processus terminés. L'espace d'adressage virtuel des processus
terminés ne peut pas être reconstruit, mais des données résiduelles dans les pages libérées qui n'ont
pas encore été écrasées peuvent encore être récupérées à partir de la mémoire physique.
Commande : ./volatility linux_yarascan -p 10471 -Y ‘Host: ’

Figure 13: commande linux_yarascan

Dans cet exemple, seule la mémoire du processus du navigateur a été recherchée en passant son
PID avec l'option -p. Omettre cette option fera en sorte que le plugin recherche tous les processus,
mais cela prendra considérablement plus de temps. Cependant, cela pourrait être une bonne façon
de déterminer dans quel(s) processus(s) un certain motif réside. Par défaut, le plugin
linux_yarascan ne recherche que la mémoire de l'espace utilisateur, mais la mémoire du noyau
peut être incluse en passant l'option -K. Dans cet exemple, la règle YARA a été passée en tant que
chaîne avec l'option -Y, mais il est également possible de passer un fichier de règles YARA avec
l'option -y à la place.
Les mêmes résultats peuvent être obtenus en extrayant la mémoire du processus sur le disque avec
le plugin linux_dump_map et en recherchant les régions de mémoire extraites avec des utilitaires
tels que yara, strings et grep. Le plugin linux_dump_map fonctionne en identifiant les adresses de
début et de fin des plages de mémoire du processus et en sauvegardant chaque page à l'intérieur
de ces plages sur le disque. Les adresses obtenues par Volatility correspondent aux adresses qui
seraient obtenues sur un système en direct en lisant depuis /proc/<pid>/maps. Passer le PID avec
l'option -p au plugin linux_dump_map entraînera la sauvegarde de toutes les correspondances du
processus spécifié. Le plugin linux_dump_map nécessite également qu'un répertoire de sortie soit
passé avec le paramètre -D.
Command: $ ./volatility linux_dump_map -p 10471 -D linux_dump_map_output/
Notez que le plugin linux_dump_map extrait toutes les pages accessibles au processus, y compris
les pages auxquelles le processus peut accéder dans la mémoire du noyau. L'utilitaire strings peut
être utilisé pour extraire toutes les chaînes de caractères des régions de mémoire vers un nouveau

Page | 16
fichier texte. Pour extraire également les chaînes de caractères Unicode, l'utilitaire strings doit être
exécuté une deuxième fois avec l'option -el.
Command:
$ strings -a linux_dump_map_output/*.vma > opera_browser.txt
$ strings -a -el linux_dump_map_output/*.vma >> opera_browser.txt

Figure 14: http host header

Cette approche peut également être utilisée pour extraire des messages texte de la mémoire.
L'exemple suivant montre le contenu des messages texte et les métadonnées qui ont été extraites
du processus Kik Messenger.

Figure 15: contenue de message extraits

Ces données révèlent le contenu des messages, le destinataire, l'horodatage, et plus encore. Chaque
message était stocké dans un format structuré : encapsulé par une balise de message. En
recherchant toutes les chaînes de caractères contenant le texte “<message ”, tous les messages
résidents en mémoire pouvaient être extraits.
L'extraction des messages texte de la mémoire pourrait potentiellement révéler des messages qui
ont été supprimés de la mémoire flash, ou qui étaient stockés uniquement sous un format chiffré
sur la mémoire flash. Certaines applications de messagerie instantanée telles que WhatsApp
peuvent être configurées pour nécessiter une authentification d'empreinte digitale supplémentaire.
L'inspection de la mémoire du processus pourrait toujours révéler des messages qui autrement ne
seraient pas accessibles sur l'appareil Android en direct.

Page | 17
2.2.7 Information sur le réseau

L'inspection de l'image mémoire révèle également des structures de données contenant des
informations sur les points d'accès sans fil, telles que le SSID (Service Set Identifier) et la clé de
sécurité (PSK). Ces données se trouvaient dans le processus wpa_supplicant. Notez que l'appareil
Android redémarrait après s'être connecté au point d'accès pour la première fois, ce qui signifie
que la PSK était automatiquement chargée en mémoire à nouveau après le redémarrage de
l'appareil.

Figure 16: Inspection du reseau

Page | 18
Conclusion Générale

À l'heure actuelle, plusieurs limitations techniques pourraient entraver l'acquisition

de mémoire dans le cadre d'une enquête forensique réelle. La première limitation majeure
est la nécessité d'avoir des privilèges root sur l'appareil Android pour acquérir sa mémoire,
comme démontré dans cet article. Il est probable que l'appareil investigué dans un scénario
réel ne soit pas encore rooté. Même s'il est généralement possible de rooter l'appareil
Android, le processus nécessitera probablement un redémarrage de l'appareil, ce qui
effacerait le contenu original de la mémoire.
La deuxième limitation majeure est la nécessité que l'appareil Android active la prise
en charge des modules chargeables. Le noyau par défaut de certains appareils Android
n'autorise pas le chargement de modules, auquel cas il n'est pas possible d'acquérir la
mémoire avec un module noyau, comme démontré dans cet article. Il est possible de
remplacer le noyau de l'appareil Android par une version modifiée autorisant le chargement
de modules, mais cela nécessite un redémarrage de l'appareil, effaçant ainsi le contenu
original de la mémoire.
Par conséquent, des travaux futurs seraient utiles pour développer une méthode plus
réalisable permettant d'acquérir la mémoire de l'appareil Android sans avoir à redémarrer
l'appareil, par exemple en extrayant la mémoire via JTAG sans retirer la batterie de
l'appareil dans le processus.

Page | 19
Bibliographie

https://github.com/volatilityfoundation/volatility
https://tunnelix.com/linux-memory-analysis-with-lime-and-volatility/
https://gabrio-tognozzi.medium.com/lime-on-android-avds-for-volatility-analysis-a3d2d89a9dd0
https://github.com/volatilityfoundation/volatility/wiki/Android#extract-the-memory-dump-file

Page | 20