Utilisez et étendez PhotoRec pour récupérer vos données perdues

TestDisk est né en 1998, sa vocation première était de pouvoir reconstruire la table des partitions PC/Intel après la suppression accidentelle d'une partition. L'idée m'était venue de créer ce programme capable d'automatiser cette tâche suite à la mésaventure d'un ami ayant décidé de repartitionner un de ses disques durs : sauvegarde des données, suppression des partitions, création des nouvelles partitions, formatage, restauration des données... « Tiens! Il semblerait que j'ai oublié de sauvegarder les données de l'une des partitions… ». Retrouver les informations nécessaires à l'aide d'un éditeur hexadécimal nous avait pris la journée complète. Avec TestDisk, ce même problème peut désormais être réglé en une dizaine de minutes.

Dans le même esprit, peu après avoir acheté mon premier appareil photo numérique en 2002, je me suis demandé comment récupérer les photos si jamais je les effaçais par erreur ou si je reformatais la carte mémoire. Aussi ai-je créé PhotoRec, un petit programme pour récupérer les photos jpg et les vidéos mov au cas où... Et dès le mois d'avril, je le distribuais sous licence GPL sur mon site web. J'ai commencé à réutiliser une partie du code correspondant à l'interface texte ncurses de TestDisk pour finir, fin 2004, par distribuer TestDisk et PhotoRec ensemble. PhotoRec a ainsi bénéficié de la popularité croissante de TestDisk. Et bien qu'il n'ait pas changé de nom, PhotoRec récupère bien plus que des photos, il récupère plusieurs centaines de formats de fichier.

1. Stockage et effacement d'un fichier

La plupart des systèmes d'exploitation essaient de stocker les données de manière contiguë de façon à minimiser la fragmentation. Le temps de recherche (en anglais seek time) des disques mécaniques est significatif lors des opérations de lecture/écriture, c'est pourquoi il est important de maintenir la fragmentation à un niveau faible. Cette contrainte est moins forte aujourd’hui : il est fréquent de rencontrer un SSD pour le système et des disques classiques/mécaniques pour le stockage de données volumineuses.

À chaque fichier est associé un ensemble de méta-informations : nom de fichier, date/heure, taille, emplacement du premier bloc de données... Selon le système de fichiers, ces informations sont plus ou moins riches : date/heure de création du fichier, de modification, d'accès, précision à 2 secondes près, à la seconde ou à la nanoseconde... Quand un fichier est effacé, la totalité ou une partie de ces méta-informations sont définitivement perdues.

Par exemple, pour un fichier d'un système FAT, la première lettre du nom court (8 caractères pour le nom, 3 pour l'extension) est écrasée lorsque le fichier est effacé ainsi que la liste des blocs qui le composait ; ces blocs deviennent libres, seul le numéro du premier bloc qui le composait reste connu. Si un nom long était présent, celui-ci reste récupérable.

Sur un système de fichiers ext3 ou ext4, le nom des fichiers effacés reste présent, mais l'emplacement des données, y compris du premier bloc, est perdu. Cela signifie donc que les données sont toujours présentes sur le système de fichiers, mais à un emplacement désormais inconnu.

À noter que, quel que soit le système de fichier, tout ou partie de ces données peuvent être écrasées par les données d'un nouveau fichier ou l'accroissement d'un fichier existant. Il convient donc de ne plus écrire de données sur le système de fichiers. Dans la mesure du possible, démonter (umount) celui-ci pour plus de précautions.

2. Principe de la récupération : File undelete versus data carving

Pour récupérer des fichiers effacés, la première méthode consiste à analyser les structures du système de fichiers à la recherche des traces restantes après effacement. Cela permet de retrouver des fichiers effacés avec leur nom d'origine, les dates de création/modification/..., leur taille exacte, etc., mais l'implémentation est à chaque fois spécifique au système de fichiers. Certains systèmes de fichiers rendent la tâche difficile, voire quasi impossible.

TestDisk permet la récupération de fichiers depuis les systèmes de fichiers FAT, NTFS, exFAT et ext2. Depuis ext3, le pointeur indiquant le numéro de bloc est mis à zéro lorsqu'un fichier est effacé, c'est-à-dire que l'on a bien les noms des fichiers effacés, mais on ignore où étaient stockées les données. ext3 étant journalisé, les dernières opérations sont indiquées sous forme de transactions dans le journal. Des outils comme ext3grep vont analyser les différentes transactions du journal pour retrouver l'emplacement des données. Cependant l'efficacité de cette méthode est limitée par la taille du journal, les transactions les plus anciennes sont écrasées.

La seconde méthode, le file carving, consiste à ignorer le système de fichiers et à rechercher directement les données. Le début des fichiers est identifié à l'aide de caractéristiques du format de fichier utilisé : signature formée par un contenu invariant (magic bytes) dans l'entête, ou bien pour des cas plus complexes par une propriété de l'entête de ces fichiers. C’est cette méthode qu’utilise PhotoRec.

3. Data carving : identification d'un fichier

Il est possible d'utiliser les techniques de data-carving pour récupérer des fichiers ou bien des fichiers eux-mêmes présents à l'intérieur d'autres, par exemple une image jpeg à l'intérieur d'un diaporama PowerPoint. Certains outils recherchent par défaut des fichiers à n'importe quel endroit du disque (précision d'un octet : foremost), d'autres à chaque secteur ou à chaque bloc/cluster comme PhotoRec.

Pour récupérer ces fichiers perdus, PhotoRec commence par déterminer la taille des blocs de données. Si le système de fichiers n'est pas corrompu, cette information peut être lue depuis le superblock (ext2/ext3/ext4) ou depuis le secteur de boot (FAT, NTFS, exFAT). Sinon, PhotoRec lit le support et utilisant sa base de signature, vérifie secteur par secteur si l'un d'eux correspond à un format de fichier connu. Une fois que dix débuts de fichier sont localisés ou la fin du support atteinte, PhotoRec déduit de leurs emplacements la taille des blocs.

Une fois la taille des blocs connue, PhotoRec vérifie la présence de signatures connues bloc par bloc (ou cluster par cluster) au lieu de secteur par secteur, le nombre de comparaisons sera donc réduit, cela va augmenter les performances et réduire le nombre de faux-positifs (le taux de faux-positifs n'est pas modifié). Cette base de signature native au produit n'a cessé de grossir avec chaque nouvelle version depuis la sortie du logiciel.

Par exemple, PhotoRec identifie un fichier JPEG lorsqu'un bloc de données commence par :

• SOI (Start Of Image) + APP0 : 0xff, 0xd8, 0xff, 0xe0 ;
• SOI + APP1 : 0xff, 0xd8, 0xff, 0xe1 ;
• ou SOI + Comment (Commentaire) : 0xff, 0xd8, 0xff, 0xfe.

Dans la mesure du possible, PhotoRec ne se contente pas de vérifier la présence de signature, il vérifie ensuite si certaines contraintes sur le format de fichier sont respectées.

Prenons l'exemple du format de fichier image bmp. Ces fichiers commencent par les octets « BM ». Cette signature est très courte et en pratique, si on l'utilise telle quelle, elle sera à l'origine de nombreux faux-positifs.

Pour éviter ces faux positifs, PhotoRec va effectuer d'autres vérifications propres au format de fichier : que le champ réservé est à 0, que l'offset est inférieur à la taille totale du fichier spécifiée dans l'entête... Avec quelques autres vérifications, le problème de faux positifs sur ce format de fichier disparaît.

4. Data carving : limitations à la récupération des fichiers

Le data carving permet donc la récupération de fichiers utilisant des formats de fichiers connus à partir de systèmes de fichiers, corrompus ou non, stockant les fichiers sous forme d'une suite de blocs de données (sous Windows en anglais cluster), la taille des blocs ayant été fixée lors du formatage du système de fichiers.

Ainsi PhotoRec va fonctionner avec la quasi-totalité des systèmes de fichiers : une exception notable, ReiserFS, qui stocke les petits fichiers et la fin des fichiers (si elle est courte) dans sa structure (utiliser le paramètre notail pour désactiver ce comportement par défaut).

Les données stockées dans les Alternate Data Stream (ADS) de fichiers NTFS n'étant pas des fichiers eux-mêmes ne sont pas récupérées par les méthodes de file carving.

5. Data carving : gestion de la fin de fichier

Nous venons de voir comment identifier le début d'un fichier, mais quels critères utiliser pour arrêter la sauvegarde du fichier récupéré ?

Le premier critère est évident, on arrête lorsque l'on arrive à la fin du disque. Autre critère utilisé par PhotoRec : la détection d'un nouveau fichier. Ce critère n'est pas utilisable par les logiciels de data-carving travaillant octet par octet qui recherchent des fichiers à l'intérieur de fichiers.

Selon le format de fichier et la connaissance qu'a l'outil de celui-ci, PhotoRec définit une taille maximale du fichier, recherche une signature de fin de fichier (footer), détermine la taille du fichier à partir de son entête et récupère les données jusqu'à ce que cette taille soit atteinte, décode le fichier bloc par bloc jusqu'à rencontrer des données incompatibles avec le format de fichier...

Si les données ne sont pas fragmentées, le fichier récupéré sera donc identique à l'original ou aura une taille plus grande que le fichier original, cela n’empêche généralement pas son utilisation.

Dans certains cas, PhotoRec peut apprendre la taille d'origine du fichier à partir de l'entête de celui-ci ; avec cette information, PhotoRec tronque le fichier à la bonne taille. Si jamais le fichier récupéré était plus petit que la taille déterminée à partir de l'entête, ce fichier est ignoré, car invalide. Cependant, la majorité des formats de fichier ne stocke pas la taille du fichier.

Pour certains formats de fichier, il est possible de vérifier l'intégrité des données. C'est le cas par exemple des fichiers audios MP3 : ils sont constitués de flux de données, chaque tronçon de données commence par un entête avec diverses informations comme la fréquence d'échantillonnage audio permettant la détermination de la taille du bloc de données. Lorsque PhotoRec analyse ces données, si l'entête ne correspond plus à celui d'un MP3, PhotoRec considère qu'il a identifié la fin du flux audio et arrête donc la récupération du fichier. Le fichier récupéré devrait donc être valide et avoir la bonne taille.

Quand un fichier est récupéré avec succès, PhotoRec vérifie à nouveau les blocs de données précédents à la recherche de signature de fichier. Cela peut arriver si un fichier avait été rejeté parce qu'il était trop petit. PhotoRec essaie donc à nouveau de le récupérer. Avec un peu de chance, la suite du fichier se trouve juste après le fichier que l'on vient de récupérer. Avec cette méthode, certains fichiers fragmentés sont récupérés avec succès.

6. PhotoRec en pratique

6.1 Installation

PhotoRec est multiplateforme : sur https://www.cgsecurity.org/wiki/TestDisk_Download des versions Linux, Dos, Windows, Mac OS X sont disponibles, mais il peut aussi être compilé sous OS/2 et les différents BSD. PhotoRec est disponible dans le package testdisk dans la majorité des distributions Linux (Fedora, CentOS/EPEL, Debian, Ubuntu, etc.), mais il peut avoir son propre package photorec (Mageia).

Pour utiliser la version de développement, il suffit de récupérer la dernière archive, la décompresser et lancer le programme avec les droits root :

6.2 Compilation

Comme cet article se termine sur l’ajout de nouveaux formats de fichiers, je vous conseille de compiler PhotoRec plutôt que d’installer les binaires ou packages prêts à l’emploi présenté juste avant.

PhotoRec utilise différentes librairies, dont certaines optionnelles ; installons-les. Comme toujours, le nom exact des librairies varie en fonction des distributions :

Debian / Ubuntu :

Fedora :

Selon votre préférence, récupérez une archive du code source de testdisk & photorec sur https://www.cgsecurity.org ou bien clonez avec git clone https://git.cgsecurity.org/testdisk.git.

Le projet utilise les autotools. Si vous avez cloné le dépôt, regénérez le script configure :

Lancez la compilation :

6.3 Lancement de PhotoRec

Afin de pouvoir lire le contenu brut du disque dur ou de la carte mémoire, PhotoRec a besoin d'être exécuté avec les droits root. Exemple :

PhotoRec présente une liste des périphériques identifiés. Sur la figure 1, il y a 4 disques durs, mais on peut avoir aussi des cartes mémoires, des clés USB, des RAID logiciels, un volume chiffré débloqué (c’est-à-dire dont le mot de passe a été saisi), des CD/DVDs, etc.

6.4 HPA/DCO

Après avoir sélectionné ce disque SATA, PhotoRec affiche un avertissement comme quoi des zones HPA et DCO sont présentes (voir figure 2). La zone HPA, Host Protected Area, peut être utilisée pour y placer divers utilitaires comme un utilitaire de restauration disque. Cette zone peut aussi avoir des utilisations illégitimes comme servir à dissimuler des données illégales ou y cacher un rootkit.

Le Device Configuration Overlay (DCO) permet au constructeur de spécifier la taille du disque telle qu'elle sera retournée au BIOS. Ainsi le constructeur peut proposer des disques aux caractéristiques identiques au secteur prêt même s'il a modernisé sa chaîne de production pour fabriquer des disques qui physiquement sont de plus grande capacité. Là encore, il y a moyen de dissimuler des informations par ce moyen.

En général, il n'y a pas de raison de s'alarmer si vous avez ce message d'avertissement, vous pouvez donc passer à l'écran suivant. Évidemment, si vous êtes en train d'analyser le disque à la recherche de preuves informatiques, il faudra vous pencher avec intérêt sur ces zones du disque.

6.5 Options

Il est en général inutile de modifier les options par défaut (voir figure 3). Cependant, si vous effectuez la récupération d'une carte mémoire d'un appareil photo, il peut être intéressant d'activer l'option de récupération de JPEG par force brute (paramètre Paranoid) : à la fin de la recherche classique, PhotoRec va tenter de réassembler les fragments qui composaient la photo. Cela est particulièrement lent et peu efficace, c'est pourquoi cela n'est pas utilisé par défaut.

Si vous souhaitez récupérer même des fragments de fichiers, il est possible d'activer l'option Keep corrupted files. Enfin, le mode expert permet d'accéder à d'autres fonctionnalités comme une fonction de récupération de données dédiée aux systèmes FAT qui ont été reformatés ou bien la création d'une image disque comportant toutes les zones disques non identifiées par PhotoRec.

6.6 Type de partitionnement

PhotoRec détecte automatiquement le format de la table des partitions (voir figure 4). Il s'agit en général de Intel/PC ou EFI GPT.

Si le mode expert est activé dans le menu Options, cet écran permet de forcer un autre type de partition.

6.7 Familles de fichiers à récupérer

Le menu présenté en figure 5 permet de modifier les familles de fichiers à récupérer. Par exemple :

• la famille .doc regroupe les documents MS Office Word .doc, Excel .xls, PowerPoint .ppt, etc.
• la famille .zip regroupe les archives du même nom, mais aussi les documents MS Office docx/xlsx/pptx, etc. et Libre/OpenOffice qui sont malgré leur extension aussi des archives zip.

Il n'est pas donc toujours évident de localiser une extension dans la liste. Mais normalement, il n'y a pas de raison de modifier la configuration par défaut.

Cependant, des cas particuliers existent :

• En cas de faux-positifs, c'est-à-dire si par exemple PhotoRec détecte la présence de fichiers à tort, il peut être souhaitable de désactiver le format de fichier en cause.
• Si vous disposez de peu d'espace pour stocker les fichiers récupérés, vous pouvez être tenté de tout désélectionner pour n'activer que les formats de fichiers qui vous intéressent. Attention cependant, cela peut empêcher la récupération de certains fichiers fragmentés et conduit pour certains formats de fichier à des fichiers récupérés beaucoup plus grands que les fichiers d’origine.

6.8 Sélection de la partition

Il faut ensuite sélectionner la partition contenant les fichiers à récupérer (voir figue 6). Attention, si vous souhaitez récupérer les fichiers de l'intégralité du disque, il est possible de choisir Whole Disk, cependant comme chaque système de fichiers a ses propres caractéristiques définies lors du formatage, il faut mieux récupérer les données une partition après l'autre. En pratique, ne sélectionner Whole Disk que si aucune partition n'est listée et si aucune partition n'a pu être retrouvée avec TestDisk.

6.9 ext2/ext3/ext4 ?

S'il n'y a pas de fragmentation, les données d'un fichier seront stockées de manière contiguë pour un système de fichiers FAT, exFAT ou NTFS.

Pour un système de fichiers ext2/ext3/ext4, les premiers blocs utilisés pour stocker les données d'un fichier sont enregistrés dans la structure de répertoire (inode) indiquant le nom du fichier, sa taille et différentes informations. Si le fichier est plus grand, les numéros de blocs sont alors stockés dans des blocs appelés « blocs d'indirections » et, au besoin, des blocs de double indirection stockent les numéros des blocs d'indirection. Il peut même y avoir des blocs de triple indirection.

Les blocs de données vont se retrouver au niveau du disque séparés par ces blocs d'indirection ou de double-indirection.

6.10 Totalité de la partition ou espace libre uniquement

PhotoRec a la possibilité d'exclure l'espace alloué des systèmes de fichiers FAT, NTFS, ext2/ext3/ext4. Cela permet de récupérer les fichiers effacés (blocs non alloués) tout en évitant de récupérer un fichier que l'on peut accéder normalement par son nom (blocs alloués). Cependant, si le système de fichier est sévèrement corrompu, l'accès habituel au fichier est impossible, et donc pour récupérer un maximum de fichiers, il faut choisir [Whole] pour ignorer la table indiquant les blocs alloués ou non.

6.11 Destination des fichiers

PhotoRec vous demande où sauvegarder les fichiers récupérés. Par défaut, il propose le répertoire courant. Il faut faire attention à ne pas choisir un répertoire du système de fichiers source sans quoi on risque d'écraser les données que l'on souhaite récupérer. Concernant l'espace nécessaire pour stocker les fichiers récupérés, il faut prévoir en général autant d'espace libre que la taille totale de la source.

6.12 C'est parti !

Le message Filesystem analysis, please wait... va apparaître si PhotoRec est configuré pour ne récupérer que les données se trouvant dans l'espace libre du système de fichiers, cela peut durer moins d'une seconde jusqu'à quelques minutes sur de très gros volumes.

Pendant la récupération des données, PhotoRec indique le nombre de fichiers récupérés, un top 10 des familles de fichiers et une estimation du temps restant. Comme la charge de travail dépend de la nature des données analysées, cette estimation fluctue ; en présence de secteurs défectueux, PhotoRec informe des erreurs de lecture et l'estimation peut tendre vers des dizaines d'heures. Il convient de réaliser une image du disque avec TestDisk (TestDisk, Advanced, Image Creation) ou ddrescue et d'utiliser PhotoRec sur cette image plutôt que directement sur le support endommagé.

Si la place vient à manquer sur la destination, un message vous en informera et vous pourrez choisir une autre destination.

6.13 Vitesse de récupération

La vitesse de récupération des données par PhotoRec dépend principalement de la vitesse de lecture du disque source et de la vitesse d'écriture du disque destination, mais aussi de celle du processeur qui est sollicité notamment lors de la vérification des jpegs.

Il est conseillé de connecter les disques directement en SATA plutôt qu'en USB, en particulier si le disque présente des secteurs défectueux.

On peut gagner en vitesse en désactivant certaines familles de fichiers comme txt, mais il ne faut le faire évidemment que si on ne souhaite récupérer aucun fichier de la famille en question.

7. Ajout de signature

PhotoRec connaît de nombreux formats de fichiers, mais peut-être pas celui qui vous intéresse... Vérifiez-le avec la commande fidentify nom_du_fichier. Si unknown est indiqué, le format de fichier est inconnu.

PhotoRec va rechercher le fichier de signature dans les emplacements suivants :

• sous Windows, photorec.sig dans le répertoire USERPROFILE ou HOMEPATH, par exemple C:\Documents and Settings\bob\ ou C:\Users\bob ;
• sous Linux, .photorec.sig dans le répertoire HOME, /home/bob par exemple ;
• et finalement photorec.sig dans le répertoire courant.

Ce fichier n'existe pas par défaut, il faut en créer un.

Il doit comporter une définition de signature par ligne, chaque définition étant composée :

• d'une extension ;
• de l'offset de la signature ;
• de la signature elle-même, le fameux invariant propre à ce format de fichier.

La signature peut être composée :

• d'une chaîne de texte, les caractères spéciaux suivants \b, \n, \r, \t, \0 et \\ sont reconnus ;
• d'une représentation hexadécimale. Les trois formes 0x123456, 0x12 0x34 0x56 et 0x12, 0x34, 0x56 sont équivalentes ;
• les espaces ou virgules sont ignorés.

Par exemple, imaginons que l'on souhaite récupérer des fichiers pfi créés par PhotoFiltre Studio ; regardons le contenu hexadécimal d'un de ces fichiers :

En vérifiant avec plusieurs fichiers, nous pouvons constater que la chaîne de texte débutant le fichier est présente dans chacun de ces fichiers : nous avons trouvé notre signature. Elle peut s'écrire :

Ou encore :

Cette signature est à l'offset 0 du fichier.

Testons notre signature avec fidentify :

Cela fonctionne, PhotoRec est en mesure de récupérer les fichiers pfi perdus.

8. Exemples de développement

Le mécanisme de signature que nous avons utilisé est assez basique. Pour les cas plus complexes ou pour maîtriser la taille des fichiers récupérés, il faut programmer.

Sur https://www.cgsecurity.org/wiki/Developers, vous trouverez quelques exemples plus ou moins complexes indiquant comment :

• identifier le début d'un fichier par des valeurs constantes/magiques ;
• extraire la date et l'heure stockées dans le fichier même ;
• déterminer la taille d'un fichier correspondant à un streaming ;
• extraire le nom du fichier...

Vos patchs sont les bienvenus, cette section présente quelques exemples de modifications concrètes. À défaut, n'hésitez pas à envoyer quelques fichiers (trois pour faire bonne mesure) et je regarderai ce que je peux faire.

8.1 Fichier récupéré avec une mauvaise extension

Prenons l’exemple de fichiers Ableton Liveset, ils portent l’extension als. Un utilisateur m’a indiqué début 2017 que PhotoRec les récupérait avec une « mauvaise extension », c’est-à-dire une extension autre que .als. Regardons comment corriger ce problème de façon à ce que l’utilisateur n’ait pas à changer l’extension de ces fichiers un à un.

La commande file indique qu’il s’agit de données compressées avec gzip :

Si on se basait sur la commande file, les fichiers récupérés auraient l’extension gz.

Regardons ce qu’il en est pour PhotoRec en utilisant la commande fidentify, un programme d’identification de format de fichier qui utilise les mêmes fonctions que photorec pour déterminer l’extension :

Nous obtenons le même résultat en lançant photorec sur le premier fichier. Cette ligne de commandes utilise le mode non interactif :

Fidentify a l’avantage, par rapport à PhotoRec, de pouvoir travailler sur plusieurs fichiers ou répertoires sans créer de nouveaux fichiers. Comme indiqué par l’utilisateur, PhotoRec récupère ce fichier avec l’extension xml.gz et non als comme espéré. Nous venons de reproduire le problème, cherchons à le corriger.

Au niveau du code source, le fichier file_gz.c est responsable de cette identification :

Les premiers octets du fichier sont décompressés dans le buffer nommé buffer_uncompr puis la signature "<?xml version=" est recherchée.

Regardons par nous-même l’entête de deux fichiers .als :

Il y a une différence sur le retour à la ligne : 0x0a ou \n pour le premier fichier, 0x0d 0x0a soit \r\n pour le second. Il s’agit d’un retour à ligne unix dans le premier cas et un retour à ligne dos/windows dans le second.

Pour corriger le problème, j’ai choisi de comparer le début des données décompressées avec ces deux entêtes. Remarque : j’aurais pu utiliser la fonction strcasecmp() afin de ne pas être sensible à la casse.

Vérifions que nos modifications permettent bien de récupérer le fichier avec son extension d’origine.

Problème résolu : nous sommes en mesure de récupérer des fichiers effacés Ableton Liveset et ils portent désormais leur extension .als.

8.2 Format de fichier inconnu

Attaquons-nous à un autre problème. On cherche cette fois-ci à récupérer des fichiers prd utilisés par le logiciel propriétaire Paessler PRTG :

Ni la commande file, ni PhotoRec ne reconnaît ce format de fichier. Une recherche Google sur ce format de fichier ne retourne aucune information exploitable.

En utilisant hexdump sur plusieurs fichiers, nous trouvons les valeurs invariantes suivantes (magic bytes) :

0000 01 00 00 00 00 00 00 00 XX XX XX XX XX db e4 40 | @|

0010 XX XX XX XX XX db e4 40 XX XX 00 00 04 00 10 00 | @ |

0020 40 1a 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 |@ |

0030 XX XX XX XX XX db e4 40 XX XX 00 00 XX XX XX XX | @ |

Une signature doit être suffisamment longue pour éviter les faux positifs. Une signature sur 4 octets a une chance sur 4 millions d’être présente sur un secteur. Un volume de 2 Tio comporte 4 millions de blocs de 512 octets. En prenant comme signature les 8 premiers octets (cf register_header_check_prd()), le problème de faux-positifs devrait donc être faible, non ? Ce n’est pas du tout le cas, car les données stockées sur un disque ne sont pas aléatoires : j’ai rencontré plus d’une dizaine de faux-positifs en testant cette signature sur une sélection de fichiers représentant un peu moins de 10 Gio de données.

Pour réduire ces faux-positifs, en plus de cette signature, j’ai choisi de vérifier que les 3 octets en 0x0d et 0x15 valent 0xdb 0xe4 0x40 dans la fonction header_check_prd(). N’ayant pas de description du format de fichier, nous ne pouvons qu’espérer que notre signature ne soit pas spécifique à la version du logiciel ou à l’environnement utilisateur de la personne nous ayant communiqué les fichiers d’exemple.

Au niveau du code, voici le contenu du fichier src/file_prd.c :

Pour que ce fichier soit pris en compte, il faut l’ajouter au Makefile.am et ajouter l’adresse de la fonction &file_hint_prd dans le fichier file_list.c avant de lancer la commande make.

La structure file_hint_t comporte l’extension la plus courante pour ce format de fichier « prd », une courte description « Paessler PRTG », une indication sur la taille maximale (ici, PHOTOREC_MAX_FILE_SIZE, c’est-à-dire pas de limite), que le fichier doit être récupéré (.recover=1) et que ce format doit être détecté par défaut (.enable_by_default=1). register_header_check pointe vers la fonction register_header_check_prd responsable de l’enregistrement de la signature basique.

La fonction register_header_check_prd fait autant d'appels à la fonction register_header_check() qu'il y a de signatures à enregistrer avec à chaque fois l'indication d'une fonction de callback.

La fonction header_check_prd appelée lorsque cette signature est identifiée est responsable de vérifier plus avant les données et si un nouveau fichier est bien rencontré, la variable file_recovery_new est remplie avec au minimum le nom de l’extension.

La variable file_recovery contient les informations du fichier actuellement récupéré. C’est très utile pour les formats de fichiers pour lesquels la signature du fichier n’est pas spécifique à l’entête, mais peut se retrouver à plusieurs endroits dans le fichier. Ici, nous n’utilisons pas cette information, mais par exemple pour un fichier audio mp3 qui utilise un format adapté au streaming, si on ignorait cette information, on récupèrerait d’une dizaine de petits fichiers mp3 valides à la place d’un seul fichier.

8.3 Contrôler la récupération

Il est aussi possible de définir  :

• une fonction data_check() chargée de stopper la récupération des données si un bloc de données est étranger au fichier (présence de caractère incompatible avec le format de fichier, fin du fichier atteinte…) ;
• une fonction file_check() pour vérifier la cohérence du fichier récupéré et déterminer sa taille réelle au besoin ;
• une fonction file_rename() pour donner un nom plus parlant au fichier que le nom générique par défaut ou même corriger l'extension du fichier ;
• le champ time pour indiquer la date et heure de modification du fichier.

Par défaut, PhotoRec arrête la récupération d’un fichier lorsqu’un nouveau est détecté. De manière générale, les fichiers récupérés seront donc plus long que les originaux. Si l’entête du fichier contient la taille attendue du fichier (exemple : format d’image BMP), nous pouvons la renseigner dans file_recovery_new->calculated_file_size. Cela permettra à PhotoRec d’ignorer les fichiers tronqués et de limiter la taille du fichier récupéré à la bonne taille.

Si l’entête du fichier comporte une information de date (exemple fichier compressé en .gz), PhotoRec va forcer la date de modification du fichier à celle-ci via le paramètre file_recovery_new->time. S’il faut avoir récupéré le fichier en entier pour retrouver cette information (Document office .doc par exemple), on peut forcer la date du fichier via une fonction callback listée dans file_recovery_new->file_rename. Conçu pour renommer les fichiers récupérés, file_post_recovery aurait sans doute été un meilleur nom. Cette fonction est appelée après la vérification optionnelle file_check. Les fichiers identifiés comme invalides sont rejetés par défaut, cela permet de réduire le nombre de fichiers récupérés corrompus.

Concernant la vérification du fichier récupéré par file_check, il est parfois intéressant de ne pas attendre que le fichier soit totalement récupéré pour vérifier quoi que ce soit : la fonction data_check permet de réaliser un test sur le bloc de données qui vient d’être lu. Peu de formats de fichiers se prêtent à ce genre de test, nous avons cependant la recherche de l’octet nul lorsqu’un fichier texte est récupéré ; si un tel caractère est détecté, nous sommes à la fin du fichier texte et nous pouvons en arrêter la récupération. La fonction data_check est aussi souvent utilisée lorsque la taille d’un fichier est connue à l’avance (via les données présentes dans l’entête d’une image BMP par exemple), la fonction data_check_size permet de ne pas récupérer trop de données pour ce fichier.

9. Effet des mesures anti-forensics

PhotoRec ne contient pas de protection anti-forensics : il ne recherche pas les fichiers intégrés dans d'autres fichiers ou à leur fin par exemple. Cependant, il est très performant et très fiable comme l'indique les tests du National Institute of Standards and Technology (NIST, https://www.cftt.nist.gov/filecarving.htm).

10. Qui utilise PhotoRec ?

Les principaux utilisateurs de PhotoRec sont :

• des photographes, professionnels ou amateurs, ayant perdu le contenu de leur carte mémoire : fichiers effacés, carte reformatée, système de fichiers corrompu...
• des personnes travaillant sous Linux ou Mac OS X : PhotoRec compte parmi le petit nombre de logiciels de récupération de données fonctionnant sous un autre système d'exploitation que Windows ;
• des personnes ayant perdu des données dans un format de fichier peu courant : PhotoRec récupère aussi bien des formats de fichiers classiques comme les documents MS Office, OpenOffice, image jpeg, archive zip que des formats de fichiers très spécialisés : étant open source (comprendre gratuit), les utilisateurs n'ont pas peur de demander l'ajout d'un nouveau format de fichier ;
• des sociétés de récupération de données et des enquêteurs à la recherche de preuves numériques.

QPhotoRec est une version graphique basée sur Qt de PhotoRec. En la mettant en avant, il devrait être possible d'élargir la base d'utilisateurs qu’une interface texte découragerait.

11. Anecdotes

Je reçois avec plaisir toutes les semaines des messages de remerciements de la part d'utilisateurs ayant récupéré leurs données : la thèse qu'il faut rendre la semaine prochaine dont la dernière sauvegarde date de plusieurs mois, les photos du voyage de noces, des années de photos numériques qui n'ont jamais été sauvegardées... Mais je crois que l'une des anecdotes qui m'a le plus amusée est celle que j'ai reçue en janvier 2007 : dans un premier mail, l'utilisateur explique qu'un appareil photo a été volé dans sa voiture, mais qu'une semaine plus tard, la police a trouvé le coupable et a pu restituer l'appareil photo. Le contenu avait été effacé, mais grâce à PhotoRec, l'utilisateur avait récupéré plus de 300 photos :

Currently I am recovering over 300 photos using PhotoRec that my sister in law took over the holidays. Our car was broken into and the camera was stolen. A week later the police found the guy! They found the camera, but it had been wiped. I had read about recovering photo's from flash cards via a story on slashdot, and now here I am.

Quelques heures plus tard, j'ai reçu la suite de l'histoire :

I have recovered some pictures that look to be taken by the thief [...] I am submitting a CD of the data I have recovered to the Detective involved in the case. My little camera was involved in a much larger theft, so hopefully the pictures they took will help nail them all!

Le voleur avait utilisé l'appareil photo, PhotoRec a permis de récupérer des photos ayant beaucoup intéressé le détective en charge du dossier: celui-ci espère découvrir les autres personnes impliquées dans un vol de plus grande envergure.

Conclusion

Je vous encourage à utiliser la commande fidentify dans un répertoire de données et de regarder si des fichiers sont mal ou non reconnus. Si c’est le cas, vous avez devant vous de quoi passer à la pratique. Vos contributions à PhotoRec sont les bienvenues. N’attendez pas d’avoir perdu vos données pour vous poser la question de comment faire pour les récupérer le cas échéant. Comment diraient certains, soyez prêts, winter is comming !

Références

[1] Site officiel de TestDisk & PhotoRec : https://www.cgsecurity.org

[2] Dépôt Git pour TestDisk & PhotoRec : https://git.cgsecurity.org ou https://github.com/cgsecurity/testdisk