La récupération de données sur SSD : un défi ?

Les disques durs SSD, à base de technologie Flash, arrivent de plus en plus nombreux et de moins en moins chers sur le marché. Grâce à des algorithmes toujours plus sophistiqués, ils sont capables de lire et écrire les données à des vitesses 10 fois supérieures à celles des disques durs à plateaux magnétiques. Ils sont également beaucoup plus résistants aux chocs.

Cependant, la technologie Flash a un certain nombre d'inconvénients, comme le taux d'erreurs, la durée de vie ou la vitesse d'effacement, accentués par des densités toujours plus élevées. Pour contourner ces problèmes et optimiser leurs produits, les fabricants ont recours à des mécanismes toujours plus complexes. Ainsi, pour aller plus loin et augmenter encore la rapidité en écriture, une commande ATA (TRIM) a été créée. Cette commande permet au disque d'être informé de la libération d’espace en vue d'accélérer l’écriture de nouvelles données.Ces algorithmes sont mis en œuvre par le contrôleur, interface entre les mémoires Flash et l’ordinateur hôte. Si les fabricants déploient beaucoup d’énergie pour inventer ces mécanismes et algorithmes pour gagner en performances, ils ne se soucient pas de l’aspect forensique et compliquent la tâche des experts en récupération de données.

Tout n’est cependant pas perdu et nous allons voir qu’il est possible de récupérer des données sur un disque SSD défectueux, et que dans certains cas, il est possible de retrouver des données effacées, ou plus précisément apparaissant comme définitivement effacées pour des outils forensiques classiques.

1. La théorie : technologie Flash et mécanismes utilisés par les SSD

1.1. Structure d’une mémoire Flash

Impossible de commencer sans un peu de théorie. Il est en effet capital de comprendre les structures des mémoires Flash et les principes des mécanismes qui gèrent ce type de mémoire pour être à même de récupérer des données dessus. Un disque SSD est physiquement constitué (cf. figure 1) d’une interface de communication et d’alimentation, d’un contrôleur, mais surtout de puces à technologie Flash.

Le contrôleur est l’élément central des disques SSD, il présente à l’utilisateur, via l’interface utilisateur (généralement SATA, USB, PCI Express, etc.), les données qu’il stocke sur la ou les puces Flash auxquelles il est relié. Nous verrons son fonctionnement un peu plus loin. Pour commencer, comprendre la structure des mémoires Flash est indispensable si l’on veut assimiler les mécanismes de gestion de données des SSD puisque ces derniers jonglent avec les éléments décrits ci-après pour organiser les données des utilisateurs. Un composant Flash peut contenir une ou plusieurs puces.

Chaque puce contient plusieurs (une puissance de 2) espaces de cellules mémoire - où l’information est réellement stockée - et leurs registres associés (sortes de buffer), de la taille d’une page (cf figure 4), ainsi qu’une partie logique permettant les opérations de lecture ou d’écriture.

L’espace des cellules mémoire est organisé hiérarchiquement selon une pyramide à trois niveaux :

• le bank : chaque bank est indépendant et peut être lu et écrit simultanément. Certaines puces n’ont pas ce niveau et sont directement organisées en blocs.
• le bloc : c’est la plus petite unité d’effacement. Chaque bloc contient des pages (nombre fixé par le fabricant de la puce).

La page est composée de deux zones : la zone de données et la zone de service. Dans cette dernière sont stockées des informations dont le contrôleur a besoin pour ses mécanismes de gestion ainsi que pour les codes de correction d’erreur.

Ces premiers éléments de structure vont nous permettre d’appréhender plus facilement les contraintes qui découlent de la technologie utilisée, que nous allons maintenant détailler.

1.2. Technologie Flash

Les puces utilisées dans les SSD sont à base de Flash NAND qui, contrairement à la Flash NOR, offre une ensité élevée pour un faible coût. Au niveau électronique, un bit est stocké dans une porte NAND en appliquant une tension entre la control gate et la source. Les électrons sont piégés dans la floating gate. Ainsi, si en appliquant un courant entre la bit line et la masse (ground), celui-ci est perturbé par les électrons, la porte est ouverte et le bit est à 0. Pour effacer ce bit et donc le remettre à 1 (porte fermée), on chasse les électrons en appliquant une tension très supérieure entre la control gate et la source.

Ces cellules sont montées en parallèle, afin de pouvoir augmenter la densité pour un coût peu élevé. On ne peut adresser qu'une page et non un octet (ce qui est le cas pour la NOR). L'unité d'écriture est par conséquent la page ; celle d'effacement, le bloc. Ces puces nécessitent que la page soit vide avant de pouvoir être écrite. Ainsi, afin de modifier 1 bit, le bloc entier doit être effacé avant que la page contenant le bit modifié soit réécrite (avec les autres pages contenant des données). Deux problèmes découlent de ces contraintes :

• soit la vitesse d'écriture est très lente car le bloc est mis en RAM puis la page est modifiée en RAM, puis le bloc est effacé (opération très longue) et enfin réécrit. Dans cette configuration, en cas de coupure d’alimentation électrique, les données sont perdues.
• soit pour pallier les défauts ci-dessus, le même bloc est réécrit dans un autre espace disponible de la mémoire (une seule opération, d'écriture). Ceci entraîne une multiplication importante des données et nécessite un système de gestion avancé des données.

Une autre contrainte de la technologie NAND est la durée de vie des cellules, composants permettant de stocker physiquement (charge électronique) la donnée. Les nouvelles cellules MLC (Multi Layer Cells) - qui peuvent contenir plusieurs bits - sont encore plus sensibles. Une cellule classique (Single Layer Cell - 1 bit par cellule) supportait un nombre d'effacement de l'ordre de 100 000 cycles alors que les MLC ont une durée de vie de l'ordre de 10 000 cycles. Cette contrainte est compensée par une densité plus importante, mais nécessite des algorithmes de gestion plus sophistiqués. Enfin, le taux d'erreur sur les données augmente avec la densité et avec les MLC. En effet, plus les cellules sont petites et plus elles contiennent d’information (taille de la cellule / taille d’un électron), plus elles sont sensibles aux champs électriques créés par leurs voisines et par l’activité de la mémoire ([9] et [10]). C’est pourquoi les mécanismes de correction évoluent et l'espace de stockage des codes de correction augmente.

Vous l’aurez compris, une écriture rapide (par écriture dans un espace disponible), une capacité augmentée (par des cellules à plusieurs niveaux) et une garantie d’intégrité des données (correction d’erreur) nécessitent une gestion avancée des données. Celle-ci se manifeste par des algorithmes toujours plus nombreux et efficaces de la structure de la Flash, comme nous vous les présentons ci-après.

1.3. Mécanismes de gestion utilisés par les SSD

Les mécanismes de gestion de mémoires Flash permettent aux disques SDD de gagner en rapidité, en capacité et en longévité tout en préservant l’intégrité des données. Ces mécanismes s’appuient essentiellement sur 2 principes, le wear leveling (1) et le garbage collector (2).

1.3.1. Wear leveling

La réponse apportée à la contrainte de durée de vie est un mécanisme de répartition des données sur l'intégralité de la mémoire. Cet algorithme, basé sur le nombre d'effacements de chaque bloc principalement, permet au contrôleur d'effacer le moins possible chaque bloc en écrivant les nouvelles données prioritairement sur les blocs vides qui ont été les moins utilisés.

Dans l’exemple simplifié ci-dessus, 5 blocs sont remplis avec des données. Puis 2 blocs sont supprimés et donc libérés. Sans wear leveling, les nouvelles pages (F et G) sont écrites dans les premiers blocs disponibles, soit à la place des anciennes pages (A et B). Avec le wear leveling, les deux premiers blocs sont marqués comme ayant été utilisés déjà 1 fois. Les nouvelles pages sont donc écrites dans les premiers blocs ayant un compteur d’utilisation le plus bas. Ici, le premier bloc avec un compteur au plus bas (0) est celui à droite de la page E. La page F est donc écrite ici. À droite de F, le compteur est déjà à 1. Comme il existe encore des blocs libres avec un compteur à 0, la page G est écrite à droite du bloc, et ainsi de suite.

Ainsi, plusieurs versions de chaque bloc peuvent être présentes en même temps physiquement sur la mémoire. En lisant le composant au niveau physique, on peut donc retrouver « l’historique » d’un bloc. C’est intéressant du point de vue forensique pour retrouver des modifications de fichiers. Mais pour la récupération de données, c’est une contrainte. Il faut en effet pouvoir différencier chaque version et identifier la dernière (cf partie 2).

1.3.2. Garbage collector

Comme nous venons de le voir, en présence de wear leveling, lorsqu’un bloc doit être modifié, le contrôleur le copie avec les données modifiées ailleurs en mémoire et relie cette nouvelle adresse physique à l'adresse logique ; le précédent bloc est quant à lui marqué comme invalide. Conformément aux principes de la Flash NAND présentés en 1.2, avant de pouvoir être utilisé à nouveau, le bloc libéré doit être effacé.

Les opérations d’effacement sont lentes et ralentissent les écritures sur les blocs libérés. Pour augmenter la vitesse d'écriture, suffisamment de blocs libres doivent être présents et pour cela l’espace doit être libéré en avance de phase. C'est pourquoi un mécanisme appelé garbage collector profite des périodes de moindre activité du disque pour aménager l’espace libre. Si un bloc contient des pages marquées comme invalides, il déplace les pages valides vers un autre bloc, puis efface le premier. Ce mécanisme est très complexe car il doit préserver la durée de vie de la Flash. Il doit donc trouver un juste équilibre pour ne pas effacer un bloc dès qu'une page est invalide.

Lorsque l’utilisateur supprime des données sur son système de fichiers, ce mécanisme n’est pas déclenché car seules les entrées dans les tables d'allocation sont modifiées.

1.4. La commande TRIM

1.4.1. Principe

Nous avons vu précédemment que pour effacer des données physiquement, les blocs libérés doivent être marqués comme invalides, afin que le garbage collector réalise effectivement l’opération d’effacement. Néanmoins, dans un contexte utilisateur, le système d'exploitation n'effaçant que les entrées de fichier, les blocs contenant les données sont toujours valides et aucun espace sur la mémoire Flash n’est réellement libéré. Lorsque le système d’exploitation a besoin d’allouer à nouveau cet espace qu’il considère comme disponible, une opération d’effacement des blocs concernés doit être mise en œuvre, ralentissant l’opération d’écriture. Afin d'augmenter cette vitesse d'écriture, il serait intéressant pour le contrôleur du SSD de connaître les blocs libérés par le système d’exploitation afin d’effacer préventivement ces blocs. La commande TRIM a donc été créée dans ce but. Grâce à elle, l'OS est capable de signaler au contrôleur les données effacées et celui-ci peut les marquer comme invalides. Le garbage collector peut alors effacer préventivement ces blocs.

La commande TRIM, prévue dans la norme ATA, est passée par le système d’exploitation hôte au contrôleur en indiquant une plage de LBA (3) pouvant être libérée.

1.4.2. Effets du TRIM

Lorsque le contrôleur SSD reçoit une plage de LBA pouvant être libérée, celui-ci marque simplement les espaces mémoires Flash correspondants comme libres. Aussi, la commande TRIM n'a aucun effet d'effacement. C'est le garbage collector qui fera l'opération d'effacement proprement dite. La probabilité de retrouver des données effacées dépend donc de la fréquence et du seuil de déclenchement de ce mécanisme. Le tableau suivant présente des résultats obtenus sur divers disques SSD :

SSD	Contrôleur	Seuil d’activation du garbage collector (taille de fichier en KB)	Délai d’effacement (s)
Crucial M4	Marvell	0	4-6
OCZ Vertex	Indilinx	16	119
Kingston V	Toshiba	?	10-12 mais effacement partiel (les premières pages sont persistantes)
Corsair F60	SandForce	0	6
Samsung 470	Samsung	16	5-6
Intel X25-M	Intel	0	6

Une expérience conduite par Christopher King et Timothy Vidas en 2011 [4] montre des résultats similaires :

Il en ressort qu'il est peu probable de retrouver des données effacées en imageant le support quelques minutes après leur effacement. Seuls les petits fichiers peuvent avoir été épargnés selon le disque. Ces expériences se limitent à la vision logique de l’effet du TRIM. Nous développerons la récupération de données physiques dans la partie 2 et verrons que la donne peut changer.

1.4.3. Implémentation de la commande TRIM

La commande TRIM est une commande ATA optionnelle du DATA SET MANAGEMENT (depuis juin 2010). Pour l'instant, elle n'est pas transmise aux médias externes par USB. Cela pourra devenir le cas dans le futur, lorsque les contrôleurs USB la supporteront. Aussi, pour le moment, la probabilité de récupérer des données effacées sur un disque externe est très élevée. Par ailleurs, la commande TRIM n’est supportée que par les OS récents (> Windows 7, Mac OS X 10.6.8, Linux 2.6.28). La récupération de données effacées sur des disques gérés par des systèmes d’exploitation ne supportant pas TRIM répond aux même contraintes que pour des disques à plateaux.

2. La pratique : récupérer des données sur un SSD

Si le disque est fonctionnel, il se comporte comme un disque magnétique classique. Cependant, il est fort probable que les données effacées ne soient plus présentes (du fait de la commande TRIM).

Sur un disque SSD défectueux, la méthode diffère de celle utilisée sur les disques à plateaux. Pour ces derniers, il est nécessaire de réparer ou remplacer les éléments défectueux (carte contrôleur, têtes de lecture, moteur, microprogramme embarqué, modules de service, etc.). Cette réparation est difficile et le résultat n’est pas certain. Une fois l’accès aux données rétabli, celles-ci sont disponibles immédiatement. Sur un SSD (non reconnu par exemple), il est nécessaire de procéder au dessoudage des composants Flash. Cette opération permet de s’affranchir du contrôleur, de ses défauts, et surtout de ses filtres. Elle supprime également l’algorithme d’organisation des données sur les composants. L’extraction des données est donc simple, mais celles-ci ne sont pas organisées et donc illisibles. La partie complexe est donc la réorganisation de ces données. Pour cela, il faut comprendre comment les contrôleurs des SSD peuvent les gérer.

2.1. L’organisation physique des données

Outre les mécanismes de gestion des blocs vus dans la partie 1, les contrôleurs organisent les données sur les composants afin d’optimiser les vitesses de lecture et d’écriture. Plusieurs fonctions sont utilisées. Chaque contrôleur utilisera une combinaison de ces fonctions avec des paramètres liés ou non à des caractéristiques physiques pour stocker les données. Pour reconstruire le système de fichiers et retrouver les données, il faudra donc être capable de retrouver cette combinaison.

2.1.1. La séparation par octet

Pour gagner en vitesse, les contrôleurs s’inspirent largement des systèmes RAID (4). Ainsi, la première fonction qui peut être testée est la séparation par octet. Le contrôleur va écrire un octet sur un composant et un octet sur un deuxième.

Le contrôleur écrivant en parallèle sur deux composants, la vitesse de lecture/écriture est multipliée par 2. Cette fonction peut aussi être implémentée sur 4 composants en parallèle.

2.1.2. L’inversion / le XOR (5) / le chiffrement

Ces fonctions ont pour objectif d’augmenter la durée de vie des composants.

En effet, dans une mémoire Flash, les cellules sont à 1 par défaut. Comme nos données contiennent majoritairement plus de 0, stocker l’inverse sollicite moins la mémoire. Ainsi, les données présentes au niveau électronique sont le plus souvent l’inverse des données logiquement enregistrées. Cette fonction est très facile à simuler pour remettre les données à leur valeur originale : il suffit d’inverser à nouveau.

Le XOR ou le chiffrement permettent de lisser les 0 et les 1 sur une zone de données. En effet, les influences électriques induites par une trop forte présence de 1 par exemple, peut introduire des erreurs. Il devient alors indispensable de limiter les influences électriques en diffusant quelques 0 dans la zone de données. Le XOR permettra donc de passer d’une zone à risque d’erreur (comme illustré ci-dessous) vers une zone stable :

Ces fonctions XOR sont plus difficiles à détecter et à rétroconcevoir. Pour récupérer les données, il est nécessaire de trouver la clé mise en place pour pouvoir appliquer un XOR à nouveau. Pour cela, il faut un contrôleur identique avec lequel on va pouvoir stocker des données connues et en déduire le pattern utilisé.

Enfin, le chiffrement permet de garder les algorithmes de gestion secrets. Cette fonction n’est pas implémentée pour la sécurité des utilisateurs, mais pour le secret industriel. Certains algorithmes de gestion étant très complexes et donc très coûteux en R&D, le fabricant se protège des tentatives de rétro-ingénierie. Ces fonctions de chiffrement empêchent donc pour le moment la récupération de données après dessoudage.

Ces trois fonctions (inversion, XOR et chiffrement) sont exclusives les unes des autres. C'est pourquoi lorsque l'on reconstruit un dump, on essaye d'abord l'inversion. En cas d'échec, on peut s'interroger sur l'utilisation d'une fonction XOR, en essayant notamment de trouver des patterns qui reviennent. Sinon, il s'agit probablement de chiffrement. Certains fabricants l'utilisent systématiquement (SandForce par exemple).

À ce niveau de la récupération, des données sont visibles. Les fichiers de moins d’une page sont intègres. Les fichiers de plus grande taille sont toutefois corrompus puisque restent à prendre en compte les principes d’entrelacement (interne ou externe) et l’organisation des blocs.

2.1.3. Entrelacement

L’entrelacement consiste, toujours en vue d’améliorer les vitesses de lecture/écriture, à répartir les pages de données sur plusieurs espaces mémoire différents. Il existe plusieurs types d’entrelacement en fonction du niveau d’espace mémoire utilisé pour la répartition :

• l’entrelacement interne historique qui répartit les pages par demi-puce (ou bank) ;
• l’entrelacement interne nouvelle génération qui répartit les pages par bloc ;
• l’entrelacement externe qui répartit les pages par composant.

Un contrôleur peut utiliser à la fois un entrelacement interne et un entrelacement externe.

2.1.3.1. Entrelacement interne historique

Les anciens contrôleurs utilisent un entrelacement qui sépare l’espace mémoire d’une puce en deux et écrit une page sur la première partie puis une page sur la deuxième.

Afin de retrouver les données stockées dans un disque SSD utilisant cet entrelacement, il convient donc de désentrelacer les pages en faisant une lecture continue et alternée des pages présentes sur la première et la seconde moitié d’une puce. En pratique, cela se fait en deux opérations. Le fichier de données est divisé en deux fichiers de même taille, puis ces fichiers sont assemblés par page (1 page du fichier 1 puis une page du fichier 2, etc.).

2.1.3.2. Entrelacement interne nouvelle génération

La nouvelle génération d’entrelacement interne s’appuie sur le même principe mais non plus sur des demi-dumps, mais sur deux blocs consécutifs (figure 12).

Le désentrelacement se fait toujours en deux opérations. Premièrement, on découpe le dump par bloc en créant deux fichiers. Le premier accueille les blocs pairs ; le deuxième les blocs impairs. Deuxièmement, on assemble ces fichiers par page.

2.1.3.3. Entrelacement externe

L’entrelacement externe est une fonction du contrôleur écrivant une page sur un composant, puis la suivante sur un autre. Il permet ainsi de doubler la vitesse de lecture/écriture. Cet entrelacement peut être réalisé sur quatre composants, ce qui double à nouveau la vitesse de lecture/écriture (à condition que le contrôleur soit dimensionné pour).

Pour désentrelacer les pages, il suffit d’assembler les deux dumps par page. À l’issue des opérations de désentrelacement, les données sont continues sur un bloc.

Les données pourraient être considérées comme réorganisées si jamais la problématique de vieillissement des cellules Flash ne devait pas être prise en compte. Néanmoins, comme nous l’avons vu en 1.3, les mécanismes de wear leveling et garbage collectoreffectuent une manipulation permanente des blocs.

2.1.4. Organisation des blocs

Les mécanismes décrits en première partie sont les principaux acteurs du désordre des blocs. En effet, dans un dump physique d’un composant Flash, on ne trouve pas de MBR dans le premier bloc. Le bloc 0 physique n’est pas le bloc 0 logique, qui peut être situé n’importe où. De plus, on retrouve très souvent plusieurs versions du même bloc (cf 1.3). Le contrôleur utilise des algorithmes très complexes permettant de reconstituer le volume logique en utilisant la dernière version de chaque bloc dans le bon ordre. Pour cela, il stocke quelque part le numéro du bloc ainsi que le numéro de version. On les retrouve le plus souvent dans la zone de service de chaque page. Dans un tel cas, si l’on veut passer d’un dump physique à un dump logique, il faut pouvoir les identifier. Les numéros de blocs sont repérables car ils sont identiques sur les pages du même bloc et changent donc toutes les X pages (X étant le nombre de pages par bloc).

Une fois ce numéro repéré, les blocs peuvent être remis dans l’ordre. Si plusieurs blocs portent le même numéro, il faut identifier le plus récent. Le numéro de version étant difficilement repérable, un algorithme simple de reconstruction fera des essais, en prenant le premier trouvé dans un premier temps par exemple.

Une fois les blocs remis dans l’ordre, le système de fichiers est accessible.

En pratique, il faut réaliser de nombreux essais et avoir de l’expérience pour reconstruire un dump physique. Cela prend du temps, en plus de celui nécessaire au dessoudage et à la lecture des composants. Les résultats sont souvent imparfaits, mais la grande majorité des données peut être retrouvée.

2.2. Cas concret : récupération de données sur un disque défectueux

Prenons un disque qui nous a été confié récemment (CORSAIR NOVA Series V32). Ce disque n’est détecté ni par Windows ni par Linux. Contrairement aux disques magnétiques, pas de bruits sur un SSD et pas de parties mobiles. Que ce soit un défaut du contrôleur, des puces mémoire ou d’autres composants, le diagnostic s’arrête. La méthode est simple : dessouder les composants mémoire et les lire.

Nous procédons donc au dessoudage des 8 puces (Intel 29F3G08AAMDB) de ce disque. Après les avoir nettoyées, nous les lisons grâce à un lecteur de composant (ACE PC-3000 Flash) doté d’un adaptateur TSOP48 (packaging assez standard). Après quelques heures, nous avons à notre disposition 8 dumps physiques d’environ 4Go (4Go de données plus les données de service). Là commence une laborieuse reconstruction.

Pour cela, nous allons devoir identifier les fonctions (vues au 2.1) utilisées par le contrôleur puis appliquer les méthodes permettant de les inverser. Il existe des bases de connaissances (6) des contrôleurs utilisés dans les SSD sur Internet. Le contrôleur est un INDILINX IDX100M01-LC. Celui-ci étant couramment utilisé, il est présent dans cette base, et nous pouvons donc savoir qu’il met en œuvre les fonctions d’organisation des données suivantes :

• la séparation par octet ;
• un XOR ;
• l’entrelacement interne (nouvelle génération).

Mais tout d’abord, il s’agit de savoir dans quel ordre prendre les dumps. En ayant pris soin au dessoudage de noter où chaque composant était, nous pouvons reconstituer l’ordre grâce aux indications marquées sur la carte.

La première étape consiste donc à assembler les composants par octet. Nous essayons le 1 avec le 2, le 3 avec le 4, … Nous parcourons ensuite un des 4 dumps reconstruits à la recherche de données reconnaissables (FAT, texte, JPG, ...). Rien n’est identifiable, le résultat demeure une mixture d’octets.

Ceci peut s’expliquer par la fonction XOR qu’utilise le contrôleur. La difficulté est alors de retrouver la valeur XOR utilisée. Fort heureusement, les logiciels commerciaux dédiés (7) connaissent les clés XOR de certains contrôleurs. Nous essayons donc d’appliquer celle préconisée par notre outil pour ce contrôleur. Nous parcourons à nouveau un des dumps. Toujours pas de données claires, mais nous retrouvons plus de 00 et des choses qui ressemblent à du texte.

L’ordre d’assemblage par octet ne doit pas être bon. Nous retournons à l’étape précédente et tentons d’inverser : le 2 avec le 1, le 4 avec le 3, ... Nous appliquons à nouveau le XOR et parcourons à nouveau le dump. Des structures de données (MBR, entrées FAT) sont à présent identifiables.

Il est maintenant nécessaire de réorganiser les pages à l’intérieur des blocs. Nous avons obtenu de l'interrogation de la base de connaissances que ce modèle de contrôleur utilise un entrelacement interne de nouvelle génération. Nous désentrelaçons les pages en découpant par bloc puis en réassemblant par page. Enfin, il reste à réorganiser les blocs entre eux. Le contrôleur du disque est supporté par le logiciel ACE PC3000 Flash. Nous pouvons donc utiliser une fonction de « translator ». Cette fonction doit remettre les blocs dans l’ordre en utilisant des paramètres que les éditeurs du logiciel ont définis suite à des recherches sur ce type de contrôleur. Ceci permet d’éviter une étude fastidieuse des données de service.

Après avoir appliqué cette fonction, nous obtenons une image avec les blocs dans l’ordre. Cependant, un secteur de boot est trouvé avec une partition Linux. Mais le root directory est vide. Nous constatons également que le logiciel a découvert de nombreuses versions des premiers blocs. Nous devons donc essayer plusieurs combinaisons pour tenter d’accéder aux données. Dès lors, le remontage du dump physique peut être considéré comme terminé et la récupération de données s’effectue manuellement, souvent en présence du requérant, afin d’identifier les dernières versions des blocs et de se focaliser sur les données recherchées.

2.3. Expériences de récupération de données effacées

Essayons maintenant de récupérer des données effacées avec la commande TRIM, afin d’en évaluer la portée au niveau du dump physique.

Nous prenons un disque OCZ ONYX, équipé d’un contrôleur IDX100M01-LC supportant TRIM. Nous installons un système Windows 7 et nous nous assurons de l’activation du support de TRIM (8). Nous réalisons un jeu de fichiers de test avec 5 fichiers de 1,1 Go composés de 0x20000 pages de 0x2000 octets chacune. Les pages sont remplies par « ligne » de 0x10 octets comprenant 8 octets de 0 puis le numéro de la page (en hexadécimal) codé sur 8 octets. Ce numéro est unique quel que soit le fichier (le fichier 2 commence là où le fichier 1 s’arrête).

Nous copions ces fichiers sur le disque puis les supprimons (Maj-Suppr pour une suppression définitive). Un logiciel forensique retrouve la trace des fichiers dans la MFT (9) mais ne ressort que des plages de 0 aux adresses logiques des données (sur un disque à plateaux, les données auraient été présentes). Ce résultat, au niveau logique, est conforme aux effets escomptés de la commande TRIM détaillés en 1.4.

Afin d’évaluer la portée de TRIM au niveau physique, nous allons maintenant procéder à une analyse des données contenues sur les composants Flash du disque SSD. Nous arrêtons le système mais laissons le disque sous tension pendant 1h30 afin que le garbage collector ait le temps de s’exécuter et de « nettoyer » les blocs précédemment libérés. Ensuite, nous dessoudons les 16 composants mémoire du disque et les lisons. Le contrôleur étant déjà connu, nous appliquons la même méthode que dans l’exemple précédent. Cependant, volontairement, nous ne procédons pas à la réorganisation des blocs (translator). Nous recherchons uniquement les pages spécifiques créées dans les fichiers du jeu de test. Nous retrouvons 612 365 pages alors que le jeu initial en comptait 655 360. Le taux de récupération sur cet exemple est donc de 93,44%.

Cet exemple nous montre que malgré une commande TRIM qui ne permet pas de récupérer des données au niveau logique, celles-ci sont encore présentes physiquement. Le contrôleur nous présente donc des données (les zéros) qui n’existent pas. Une hypothèse peut expliquer ce phénomène : le contrôleur maintient une table contenant les blocs libres. Il interroge cette table lors de la lecture d'une page et présente des zéros si le bloc demandé est présent.Cependant, la récupération de ces données n’est pas triviale car il faut ensuite pouvoir retrouver l’assemblage des blocs effacés qui sont par définition exclus par le contrôleur de la vision logique.

3. Limites de la récupération de données sur SSD

3.1. Intégrité de la copie

Certaines rumeurs, spécialement dans le monde criminalistique, disent qu’il serait difficile de prouver l’intégrité de la copie d’un disque SSD par un logiciel d'acquisition forensique (imager). Il faut tordre le cou à ces affirmations pour plusieurs raisons.

D’une part, le mécanisme de gestion de données wear leveling agit au niveau physique et non logique. Ainsi, les données présentées par le contrôleur, les blocs logiques, restent les mêmes, quel que soit le bloc physique où elles sont stockées.

D’autre part, les mécanismes liés à la commande TRIM qui peuvent avoir un impact sur les données présentées par le contrôleur (cf 1.4.2) sont déclenchés dans des délais de l’ordre de la minute. Du point de vue d’une enquête, à moins de tomber sur un mis en cause en train d’effacer les données au moment de la perquisition, les données ne changeront pas. Des copies successives présenteront donc toutes les mêmes données et la même signature.

3.2. Diversité des implémentations

L’expérience nous a démontré que, même si les mécanismes se ressemblent fortement et que des grands principes émergent, il n’existe pas de standard quant à la gestion des données physiques sur un SSD.

Nous avons constaté que le garbage collector, notamment, se déclenche suivant des paramètres différents selon les fabricants. Il n’est donc pas possible de définir le comportement d’un SSD sans l’étudier précisément, et ainsi d’évaluer la capacité à retrouver des données effacées.

3.3. Contrôleur utilisant la compression ou le chiffrement

Actuellement, la compagnie SandForce, gros fabricant de contrôleurs pour SSD (près de 50% du marché), fournit une technologie vantée comme robuste et rapide. Elle utilise notamment une forme de compression pour réduire les mouvements de blocs. Cependant, en plus de la compression, SandForce chiffre les données afin de garder le secret de ses algorithmes. La récupération de données sur les puces gérée par ces contrôleurs est impossible par la méthode décrite en partie 2 (dessoudage et lecture des composants).

Des recherches sont actuellement en cours dans les laboratoires criminalistiques européens et chez les fournisseurs de solutions de récupération de données pour trouver des alternatives. Deux pistes principales sont à l’étude :

• l’utilisation de ports de debug JTAG (10) de la carte électronique ;
• le détournement de la fonction de mise à jour du firmware du contrôleur pour accéder à des fonctions bas niveau.

Conclusion

Retrouver, à l’aide d’un outil forensique classique, des données effacées sur un disque SSD devient de plus en plus difficile suite à l’adoption de la commande TRIM par les systèmes d’exploitation récents. En effet, dans un souci d’augmenter les performances en écriture, l’OS « désigne » via cette commande les plages de mémoire à effacer, pouvant ainsi être préparées pour une prochaine réécriture (effacement des blocs physiques correspondants).

Récupérer des données (visibles surtout) sur un SSD défectueux est possible mais pas trivial. Contrairement aux disques magnétiques, pour lesquels la partie réparation est difficile et incertaine, copier les données présentes en mémoire d’un SSD n’est pas un problème. Par contre, celles-ci sont totalement désorganisées et retrouver cette organisation est une tâche compliquée. La deuxième partie de cet article en témoigne brièvement.

La récupération de données sur un support défectueux, que ce soit sur un disque magnétique ou un SSD, reste donc un défi qu’il faut relever chaque jour... Paradoxalement, la récupération de données sur un SSD en parfait état de fonctionnement est un défi encore plus difficile à relever si l’on veut exploiter les traces physiques de données logiquement effacées ou surchargées (TRIM, wipe, etc.).

Notes

(1) Action de répartir la charge uniformément

(2) En traduction littérale, « ramasseur de poubelle »

(3) Logical Block Address : adresse logique utilisée par le système d’exploitation

(4) Redundant Array of Independent Disks

(5) Ou exclusif

(6) http://www.pc-3000Flash.com/solbase/index.php?parent_id=9&lang=eng

(7) ACE PC 3000 Flash, Soft Center

(8) Dans une invite de commande : fsutil behavior set disabledeletenotify 0

(9) Master File Table : table d’entrée des répertoires et fichiers (cf. NTFS)

(10) Join Test Action Group

Bibliographie

[1] Fkrezgy Yohannes, (2011, SOLID STATE DRIVE (SSD) DIGITAL FORENSICS CONSTRUCTION, Politecnico di Milano - Thèse)

[2] Graeme B. Bell et Richard Boddington, (2010, « SSD : The Beginning of the End of Current Practice in Digital Forensic Recovery ? »)

[3] European Union - European Commission Directorate General Home Affairs - Prevention of and Fight against Crime Program (2012, « SSD - Techniques and Forensic Issues »)

[4] Christopher King, Timothy Vidas (2011, « Empirical analysis of solid state disk data retention when used with contemporary operating systems »)

[5] Nitin Agrawal∗ , Vijayan Prabhakaran, Ted Wobber, John D. Davis, Mark Manasse, Rina Panigrahy (2008, « Design Tradeoffs for SSD Performance »)

[6] Wikipédia - TRIM (http://en.wikipedia.org/wiki/TRIM)

[7] Wikipédia - Write Amplification (http://en.wikipedia.org/wiki/Write_amplification)

[8] Robert Hallock (2008, The hows and whys od SSDs, http://icrontic.com/article/how_ssds_work)

[9] Al Fazio (2004, Flash Memory Scaling, MRS Bulletin)

[10] Seiichi Aritome, Riichiro Shirota, Gertjan Hemink, Tetsuo Endho et Fujio Masuaoka (1993, Reliability Issues of Flash Memory Cells)