Analyse de la mémoire vive

Importante dans le domaine de l’informatique d’enquête (cyberforensics), l’analyse de la mémoire vive (AMV) fait partie de la famille de l’analyse dynamique (AD). Il s’agit d’une approche éprouvée pour effectuer l’analyse des maliciels sur les ordinateurs personnels. Hale Ligh et al. [58] ont rédigé un livre complet couvrant l’acquisition et l’analyse de la mémoire vive pour les SE Windows, Linux et Mac OS X principalement. Sur Android, plusieurs travaux (p.ex. [80, 113, 118]) ont démontré qu’il était possible d’extraire les SMS, des informations sur l’état interne du noyau Linux et les classes Java chargées dans l’application par l’AMV. Ce chapitre détaille l’état de la recherche sur l’AMV portant sur Android.La section 3.1 présente les principales techniques d’acquisition de la mémoire vive présentes sur Android. La section 3.2 fait état des techniques d’analyse applicables à ces captures. L’outil d’AMV appelé Volatility et les approches l’utilisant y sont également présentés.

Acquisition

L’acquisition de la mémoire vive est l’action d’extraire la mémoire volatile d’un appareil en exécution et de la copier dans un fichier appelé capture. Une considération importante de l’acquisition décrite dans les travaux de Chan et al. [23] ainsi que Solomon et al. [109], est que les données contenues en mémoire vive peuvent être perdues si elles ne sont pas acquises rapidement après la survenue de l’évènement d’intérêt. Le choix de l’algorithme de gestion de la mémoire utilisée dans le SE, l’espace en mémoire disponible, le type d’opérations effectuées sur le système ainsi que la charge de travail du processeur peuvent affecter l’espérance de vie des données qui y sont contenues. Pour ces raisons, il est important qu’un processus d’acquisition soit rapide et affecte lui-même le moins possible ce contenu lors de l’opération de capture de la mémoire vive afin d’éviter la corruption des données d’intérêt.

Carrier et Grand [19] ont proposé l’utilisation de matériels dédiés de type Peripheral Component Interconnect (PCI). Il a été également démontré possible d’utiliser des périphériques déjà présents sur une plateforme afin d’acquérir la mémoire vive. Notamment, les études de Gladyshev et Almansoori [43] et Zhang et al. [137] ont démontré cette capacité par l’utilisation du FireWire alors que Balogh et Mydlo [11] se sont intéressés à utiliser la carte réseau d’un système pour cette tâche. L’utilisation de matériel dédié permet de lire l’entièreté de la mémoire vive, et ce, sans nécessiter l’intervention du SE et du microprocesseur. En effet, l’interaction avec la mémoire vive s’effectue à l’aide d’une composante appelée Direct Memory Access (DMA) permettant à un périphérique de lire ou écrire directement avec la mémoire vive de façon indépendante de l’exécution du microprocesseur. Cette approche permet d’éviter l’envoi d’instructions au microprocesseur nécessitant des lectures et écritures en mémoire vive pour l’acquisition ce qui limite les risques de corruption des données qui s’y trouvent. Cette technique nécessite néanmoins la présence ou l’ajout de composantes électroniques sur le système ciblé et n’a pas été répliquée sur des appareils mobiles Android.

Une autre technique d’acquisition utilisée par Breeuwsma [15] fait appel au bus Joint Test Action Group (JTAG). Le JTAG est, à l’origine, un outil de développement permettant de charger un microprogramme sur un microcontrôleur et d’en faire le déverminage. Il permet d’interrompre l’exécution du microprocesseur pour contrôler son état interne, comme la valeur de ses registres ou des plages mémoires qu’il contient. Le contrôle de l’exécution du microprocesseur est l’une des fonctionnalités du JTAG qu’il est possible d’utiliser pour interrompre l’exécution de celui-ci et de lire l’entièreté de sa mémoire vive. Cette approche peu utilisée dans la littérature demande un accès physique au microcontrôleur de l’appareil visé. Également, elle peut nécessiter des modifications physiques comme des soudures de précision pour relier un connecteur JTAG au microcontrôleur. Ces altérations peuvent entraîner la destruction des composantes en cas d’erreur de manipulations. De plus, certains appareils n’exposent pas de connecteur JTAG ou celui-ci a été désactivé de façon permanente une fois l’installation d’usine terminée.

Il a été observé par Sylve et al. [113] que l’utilisation de dd modifie une quantité appréciable de champs en mémoire lorsqu’il est exécuté. Pour un émulateur Android possédant 512 Mo de mémoire vive, l’utilisation de dd provoque des écritures sur près de 20% de la totalité du contenu de la mémoire vive, détruisant toute information d’intérêt qui s’y trouve. La propension du SE à réécrire sur des plages mémoires pouvant contenir des données d’intérêt diminue avec l’augmentation de la quantité d’espace mémoire disponible. Plus le système dispose d’espace mémoire de libre, moins il est nécessaire de réutiliser des plages mémoires ayant déjà servi pour faire l’allocation de nouveaux espaces mémoire.Il est également possible d’acquérir la mémoire vive d’un processus par l’utilisation d’un dévermineur comme gdb [44]. Sur Android, il est nécessaire d’avoir les privilèges de l’utilisateur root pour connecter gdb à un processus en exécution et y lire la mémoire vive si ce processus n’est pas un enfant du processus lançant gdb. De plus, cette méthode est limitée à un ou plusieurs processus, mais ne permet pas de cibler le noyau Linux lui-même à moins qu’il n’ait été recompilé pour supporter cette option. Si tel est le cas, il est possible de contrôler l’ensemble de son exécution par un dévermineur distant, mais aux coûts d’importants ralentissements pouvant interférer avec des opérations sensibles aux retards (p. ex. communications réseaux, périphériques, etc.).Le dévermineur d’applications Android permet également d’analyser les variables en mémoire de celles-ci lors de leur exécution. Une application doit avoir été prévue pour être déverminée au moment de sa compilation, sans quoi le dévermineur ne sera pas autorisé à la contrôler. Cette approche ne permet pas d’observer l’ensemble du contenu de la mémoire vive du SE, des autres processus externes aux applications Android et des autres applications qui ne sont pas configurées pour être déverminables.