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

Magazine
Marque
GNU/Linux Magazine
Numéro
210
Mois de parution
décembre 2017
Spécialité(s)


Résumé

Si vous avez voulu récupérer des données perdues, vous avez sans doute croisé le nom de PhotoRec. Il s’agit sans doute du logiciel libre de récupération de données le plus populaire. Bien que développé depuis quinze ans et connaissant plus de 400 formats de fichiers, il peut être nécessaire de lui apprendre à reconnaître un autre format de fichiers, celui utilisé par vos précieuses données. Après avoir vu son utilisation, découvrez comment étendre PhotoRec.


Body

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 :

$ wget -N https://www.cgsecurity.org/testdisk-7.1-WIP.linux26.tar.bz2

$ tar xjf testdisk-7.1-WIP.linux26.tar.bz2

$ cd testdisk-7.1-WIP

$ sudo ./photorec_static

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 :

# apt-get install -y build-essential e2fslibs-dev

libncurses5-dev libncursesw5-dev ntfs-3g-dev libjpeg-dev uuid-dev

zlib1g-dev qtbase5-dev qttools5-dev-tools pkg-config dh-autoreconf git

Fedora :

# dnf install -y @buildsys-build desktop-file-utils e2fsprogs-devel

libewf-devel libjpeg-devel libuuid-devel ncurses-devel ntfs-3g-devel

qt-devel zlib-devel

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 :

$ mkdir config

$ autoreconf --install -W all -I config

Lancez la compilation :

$ configure && make

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 :

$ sudo ./src/photorec

 

01_disk_selection

 

Fig. 1 : Sélection du disque.

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.

PhotoRec peut aussi travailler à partir d'une image disque, exemple photorec image.dd ou bien sur une image au format Expert Witness Format (EWF) utilisé par Encase Forensics, un logiciel commercial d'analyse informatique assez populaire.

6.4 HPA/DCO

photorec_hpa_dco

 

Fig. 2 : Présence de zones HPA et 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

02_options

 

Fig. 3 : Options par défaut.

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_partition_table_type

 

Fig. 4 : Format de la table des partitions.

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

03_file_families

 

Fig. 5

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

04_partition_selection

 

Fig. 6 : Sélection de la partition contenant les fichiers à récupérer.

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 ?

05_filesystem_type

 

Fig. 7 : Choix du type de système de fichiers.

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.

debugfs /data/data_for_testdisk/ext3.dd

debugfs 1.41.4 (27-Jan-2009)

debugfs: stat 2005_08_06_Paris_Plage/dscn5168.jpg

Inode: 12050 Type: regular Mode: 0644 Flags: 0x0

Generation: 3044349971 Version: 0x00000000

User: 500 Group: 500 Size: 361773

File ACL: 0 Directory ACL: 0

Links: 1 Blockcount: 714

Fragment: Address: 0 Number: 0 Size: 0

ctime: 0x487b285f -- Mon Jul 14 12:20:15 2008

atime: 0x4301937a -- Tue Aug 16 09:19:22 2005

mtime: 0x42f99b62 -- Wed Aug 10 08:14:58 2005

BLOCKS:

(0-11):49407-49418, (IND):49419, (12-267):49420-49675, (DIND):49676, (IND):49677, (268-353):49678-49763

TOTAL: 357

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

ext4 peut stocker ces numéros de blocs de manière plus efficace « tel bloc à tel bloc » (extents).

Afin de traiter ce cas, PhotoRec demande si le système de fichiers était un système ext2/ext3/ext4. Il essaiera alors de détecter ces blocs et de les exclure des données récupérées.

6.10 Totalité de la partition ou espace libre uniquement

06_filesystem_free_or_whole

 

Fig. 8 : Détermination de l'espace de recherche.

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

07_destination

Fig. 9 : Destination des fichiers récupérés.

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.

08_recovery_in_progress

 

Fig. 10 : Récupération en cours.

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 :

$ hexdump -C /home/kmaster/src/testfiles/sample.pfi | head

00000000 50 68 6f 74 6f 46 69 6c 74 72 65 20 49 6d 61 67 |PhotoFiltre Imag|

00000010 65 03 40 06 00 00 b0 04 00 00 40 19 01 00 40 19 |e.@.......@...@.|

00000020 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

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 :

pfi 0 "PhotoFiltre Image"

Ou encore :

pfi 0 "PhotoFiltre", 0x20, "Image"

Cette signature est à l'offset 0 du fichier.

Testons notre signature avec fidentify :

$ fidentify /home/kmaster/src/testfiles/sample.pfi

/home/kmaster/src/testfiles/sample.pfi: pfi

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.

Renommer des fichiers en masse

Pour renommer des fichiers en masse, vous pouvez utiliser sous Linux la commande rename :

$ rename xml.gz als *.xml.gz

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

$ file /home/kmaster/src/testfiles/samples_7.1/sample*.als

/home/kmaster/src/testfiles/samples_7.1/sample2.als: gzip compressed data, from NTFS filesystem (NT)

/home/kmaster/src/testfiles/samples_7.1/sample.als: gzip compressed data, from Unix

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 :

$ fidentify /home/kmaster/src/testfiles/samples_7.1/*.als

/home/kmaster/src/testfiles/samples_7.1/sample2.als: xml.gz

/home/kmaster/src/testfiles/samples_7.1/sample.als: xml.gz

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

$ photorec /d recup_dir /cmd /home/kmaster/src/testfiles/samples_7.1/sample.als search

PhotoRec 7.1-WIP, Data Recovery Utility, August 2016

Christophe GRENIER <grenier@cgsecurity.org>

http://www.cgsecurity.org

$ ls recup_dir.1

f0000000.xml.gz report.xml

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 :

$ grep xml.gz src/file*.c

src/file_gz.c: file_recovery_new→extension="xml.gz";

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

if(memcmp(buffer_uncompr,"<?xml version=",14)==0)

{

file_recovery_new->extension="xml.gz";

return1;

}

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

$ zcat sample.als|hexdump -C|head -4

00000000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 |<?xml version="1|

00000010 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 55 54 |.0" encoding="UT|

00000020 46 2d 38 22 3f 3e 0a 3c 41 62 6c 65 74 6f 6e 20 |F-8"?>.<Ableton |

00000030 4d 61 6a 6f 72 56 65 72 73 69 6f 6e 3d 22 34 22 |MajorVersion="4"|

$ zcat sample2.als|hexdump -C|head -4

00000000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 |<?xml version="1|

00000010 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 55 54 |.0" encoding="UT|

00000020 46 2d 38 22 3f 3e 0d 0a 3c 41 62 6c 65 74 6f 6e |F-8"?>..<Ableton|

00000030 20 4d 61 6a 6f 72 56 65 72 73 69 6f 6e 3d 22 34 | MajorVersion="4|

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.

if(memcmp(buffer_uncompr,"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<Ableton", 0x30)==0||

memcmp(buffer_uncompr,"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Ableton", 0x2f)==0)

{

/* Ableton Liveset */

file_recovery_new->extension="als";

return1;

}

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.

$ ./configure && make

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

$ ./src/fidentify /home/kmaster/src/testfiles/samples_7.1/*.als

/home/kmaster/src/testfiles/samples_7.1/sample2.als: als

/home/kmaster/src/testfiles/samples_7.1/sample.als: als

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 :

$ file /home/kmaster/src/testfiles/samples_7.1/sample_device_43.prd

/home/kmaster/src/testfiles/samples_7.1/sample_device_43.prd: data

$ fidentify /home/kmaster/src/testfiles/samples_7.1/*.prd

/home/kmaster/src/testfiles/samples_7.1/sample_device_43.prd: unknown

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 :

#ifdef HAVE_CONFIG_H

#include <config.h>

#endif

#ifdef HAVE_STRING_H

#include <string.h>

#endif

#include <stdio.h>

#include "types.h"

#include "filegen.h"

 

staticvoidregister_header_check_prd(file_stat_t*file_stat);

 

constfile_hint_t file_hint_prd={

.extension="prd",

.description="Paessler PRTG",

.max_filesize=PHOTOREC_MAX_FILE_SIZE,

.recover=1,

.enable_by_default=1,

.register_header_check=&register_header_check_prd

};

 

staticintheader_check_prd(constunsignedchar*buffer,constunsignedintbuffer_size,constunsignedintsafe_header_only,constfile_recovery_t*file_recovery,file_recovery_t*file_recovery_new)

{

if(buffer[0x0d]!=0xdb||buffer[0x0e]!=0xe4||buffer[0x0f]!=0x40||

buffer[0x15]!=0xdb||buffer[0x16]!=0xe4||buffer[0x17]!=0x40)

return0;

reset_file_recovery(file_recovery_new);

file_recovery_new->extension=file_hint_prd.extension;

return1;

}

 

staticvoidregister_header_check_prd(file_stat_t*file_stat)

{

staticconstunsignedcharprd_header[8]={

0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00

};

register_header_check(0,prd_header,sizeof(prd_header),&header_check_prd,file_stat);

}

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.

structfile_recovery_struct

{

file_stat_t*file_stat;

time_t time;

constchar*extension;

uint64_t min_filesize;

uint64_t calculated_file_size;

int(*data_check)(constunsignedchar*buffer,constunsignedintbuffer_size,file_recovery_t*file_recovery);

void(*file_check)(file_recovery_t*file_recovery);

void(*file_rename)(constchar*old_filename);

...

};

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

 



Article rédigé par

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous