PhotoRec Recupération de données

PhotoRec : Récupération de données

Christophe GRENIER

Développé depuis plus de dix ans, PhotoRec est, sans fausse modestie, un des logiciels de récupération de données par data-carving le plus performant. Rencontrez ce logiciel libre si ce n'est pas déjà le cas, dans tous les cas, découvrez son fonctionnement interne.

Genèse du projet

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 tache 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'ai pas changé de nom, PhotoRec récupère bien plus que des photos, il récupère plusieurs centaines de formats de fichier.

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 disparaitra peut-être lorsque la capacité des SSD rivalisera pour un prix similaire à celui des disques mécaniques classiques.

A 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 fichier 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 nano-seconde... 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 fichier 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 fichier mais à un emplacement désormais inconnu.

A noter, quelque 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 fichier. Dans la mesure du possible, démonter (umount) celui-ci pour plus de précaution.

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 mais l'implémentation est à chaque fois spécifique au système de fichier. Certains systèmes de fichiers rendent la tache difficile, voire quasi impossible.

TestDisk permet la récupération de fichiers depuis les systèmes de fichier 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 fichier 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 dans l'entête, ou bien pour des cas plus complexes par une propriété de l'entête de ces fichiers.

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ême 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 fichier 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 10 débuts de fichier 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: que le champs 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 disparait.

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 fichier.

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.

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 recherche 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 une 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.

PhotoRec en pratique

Installation

PhotoRec est multi-plateforme: 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. Sous la majorité des distributions (Fedora, Debian, Ubuntu), si vous installez le package testdisk, celui-ci contiendra aussi photorec mais sous Mandriva, photorec a son propre package. 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 https://www.cgsecurity.org/testdisk-7.0-WIP.linux26.tar.bz2
tar xjf testdisk-7.0-WIP.linux26.tar.bz2
cd testdisk-7.0-WIP
sudo ./photorec_static

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

[kmaster@adsl ~]$ cd testdisk-7.0-WIP
[kmaster@adsl linux]$ sudo ./photorec_static

PhotoRec présente une liste des périphériques identifiés, ici

• /dev/sda, /dev/sdb et /dev/sdc, trois disques SATA,
• /dev/sdf, une carte mémoire SD
• /dev/sdh, une clé USB
• /dev/md0, un RAID logiciel
• /dev/dm-0 /dev/mapper/perso, un volume chiffré (le mot de passe a été saisie, il est donc débloqué)
• /dev/sr0 un DVD endommagé

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

HPA/DCO

Après avoir sélectionné mon deuxième disque SATA, PhotoRec affiche un avertissement comme quoi des zones HPA et DCO sont présentes. 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 chaine 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. Évidement, 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.

La détection des zones HPA/DCO est présente dans les versions Linux de PhotoRec depuis la version 6.11, mais des correctifs ont été faits dans la version 6.12 pour mieux gérer les disques faisant plus de 1 To.

Type de partitionnement

PhotoRec détecte automatiquement le format de la table des partitions. Il s'agit en générale de Intel/PC.

Exceptions notables, les Mac Book, Mac Pro et autres produits Apple utilisent une table des partitions EFI GPT.

Cette écran n'est affiché que si le mode expert est activé.

Sélection de la partition

Sélectionner la partition contenant les fichiers à récupérer. 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 fichier 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.

Options

Il est en général inutile de modifier les options par défaut. 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 composait 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és 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és par PhotoRec.

Familles de fichiers à récupérer

Ce menu 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...
• la famille .zip regroupe les archives du même nom, mais aussi les documents 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 pour 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 à tord, il peut être souhaitable de désactiver le format de fichier en cause.
• Pour récupérer des archives Bacula n'utilisant pas la compression, désactiver tout les formats de fichier et n'activer que celui-ci. Cela évitera que PhotoRec récupère les fichiers à l'intérieur de l'archive plutôt que l'archive.
• Si vous disposez de peu d'espace pour stocker les fichiers récupérés, vous pouvez là aussi 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.

ext2/ext3/ext4 ?

S'il n'y a pas de fragmentation, les données d'un fichier seront stockés 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", 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 indirections.

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.

Remarque, 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 fichier é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.

Totalité de la partition ou espace libre uniquement

PhotoRec a la possibilité d'exclure l'espace alloué des systèmes de fichier 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.

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 fichier 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.

C'est parti!

Le message Filesystem analysis, please wait... va apparaitre si PhotoRec est configuré pour ne récupérer que les données se trouvant dans l'espace libre du système de fichier, 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.

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 cette famille.

Ajout de signatures

PhotoRec connait 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

[kmaster@adsl ~]$ 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

[kmaster@adsl ~]$ 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.

Développement

Le mécanisme de signature que nous avons utilisé est cependant assez basique.

Pour les cas plus complexes ou pour maitriser 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. A défaut, n'hésitez pas à envoyer quelques fichiers (trois pour faire bonne mesure) et je regarderai ce que je peux faire.

En résumé, le développeur doit renseigner une première structure avec notamment l'extension, un texte descriptif, si la récupération de cette famille de fichier est activée par défaut ou non, le nom d'une fonction.

const file_hint_t file_hint_png= {
  .extension="png",
  .description="Portable/JPEG/Multiple-Image Network Graphics",
  .min_header_distance=0,
  .max_filesize=PHOTOREC_MAX_FILE_SIZE,
  .recover=1,
  .enable_by_default=1,
  .register_header_check=&register_header_check_png
};

Cette fonction (ici register_header_check_png) 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.

register_header_check(0, jng_header,sizeof(jng_header), &header_check_png, file_stat);

Cette fonction de callback (ici header_check_png) est chargée de réaliser des tests plus poussés sur l'entête que la présence d'une simple signature et, si les tests sont concluants, confirmer la présence d'un nouveau fichier. Il est possible de définir aussi :

• 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 champs time pour indiquer la date et heure de modification du fichier

struct file_recovery_struct
{
  file_stat_t *file_stat;
  time_t time;
  const char *extension;
  uint64_t min_filesize;
  uint64_t calculated_file_size;
  int (*data_check)(const unsigned char*buffer, const unsigned int buffer_size, file_recovery_t *file_recovery);
  void (*file_check)(file_recovery_t *file_recovery);
  void (*file_rename)(const char *old_filename);
  ...
};

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.nist.gov/itl/ssd/software-quality-group/computer-forensics-tool-testing-program-cftt/cftt-technical-0).

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 fichier 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 OpenSource (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

Depuis la version de développement 7.0-WIP, une version graphique basée sur Qt de PhotoRec est disponible. Cela devrait permettre d'élargir sa base d'utilisateurs que l'interface texte découragerait.

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é 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.

Christophe Grenier grenier@cgsecurity.org

Auteur des logiciels libres de récupération de données TestDisk & PhotoRec