PhotoRec : récupération de données

Magazine
Marque
MISC
Numéro
78
|
Mois de parution
mars 2015
|
Domaines


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

Body

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

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

À 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 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 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, quel que soit le système de fichiers, 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émontez (umount) celui-ci pour plus de précautions.

3. 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 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 dans l'en-tête, ou bien pour des cas plus complexes par une propriété de l'en-tête de ces fichiers.

4. 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 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 champ réservé est à 0, que l'offset est inférieur à la taille totale du fichier spécifiée dans l'en-tête... Avec quelques autres vérifications, le problème de faux positifs sur ce format de fichier disparaît.

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

6. 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 en-tê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'en-tê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'en-tê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 fichiers, 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 en-tê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'en-tê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 signatures de fichiers. 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.

7.PhotoRec en pratique

7.1 Installation

PhotoRec est multiplateforme: sur http://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 http://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

7.2 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

Photorec01_disklist

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

7.3 HPA/DCO

Photorec02_hpa_dco

Après avoir sélectionné mon deuxième disque SATA, PhotoRec affiche un avertissement indiquant que les 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ès 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.

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.

7.4 Type de partitionnement

Photorec03_partition_type

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

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

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

7.5 Sélection de la partition

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

7.6 Options

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

7.7 Familles de fichiers à récupérer

Photorec06_fileopts

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 à tort, 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 tous 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.

7.8 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 », 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 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.

Photorec07_ext2

7.9 Totalité de la partition ou espace libre uniquement

Photorec08_free

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 auquel on peut accéder normalement par son nom (blocs alloués) . Cependant, si le système de fichiers 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.

7.10 Destination des fichiers

Photorec09_dst

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.

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

Photorec10_analyse

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. L'estimation peut alors 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é.

Photorec11_recovery

Si la place vient à manquer sur la destination, un message vous en informera.

Photorec12_nospace

7.12 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 de destination, mais aussi de celle du processeur qui est sollicité notamment lors de la vérification des JPEG.

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.

8. 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 :

[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 du début du 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.

9. Développement

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

Pour les cas plus complexes ou pour maîtriser la taille des fichiers récupérés, il faut programmer.

Sur http://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. À 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 fichiers 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'en-tê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 champ 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);

  ...

};

10. 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'indiquent les tests du National Institute of Standards and Technology (NIST, http://www.cftt.nist.gov/filecarving.htm).

11. 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, images JPEG, archives 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.

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.

QPhotoRec

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


Sur le même sujet

Un poste de travail sous OpenBSD : installation et configuration

Magazine
Marque
Linux Pratique
Numéro
116
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Dans le monde des systèmes d’exploitation libres, le projet OpenBSD a toujours été reconnu comme étant le plus sécurisé. Outre ce point important, ce système d’exploitation est un logiciel dont il faut relever l’exemplarité du développement notamment concernant la qualité du code, élaboré par une communauté de développeurs.

Découvrir SQL avec SQLite

Magazine
Marque
Linux Pratique
Numéro
116
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Grâce au langage SQL (Structured Query Language), il est aisé de rédiger des requêtes pour définir la structure d’une base de données et manipuler son contenu. Partons à la découverte de ces sujets à l’aide de SQLite, un moteur de base de données au nom trompeur, car s’il fait preuve de modestie, il constitue un produit performant et polyvalent.

Élévation de privilèges sur macOS avec CVE-2018-4193

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Cet article explique comment exploiter la CVE-2018-4193, une élévation de privilèges affectant les versions de macOS inférieures à 10.13.5, en moins de 10 secondes. Les différents prérequis nécessaires à la compréhension de l’exploit seront détaillés de sorte qu’aucune connaissance préalable de macOS ne soit nécessaire, ce qui permet d’aborder l’exploitation de vulnérabilités dans les démons macOS en général.

AWX, une WebUI pour vos jobs Ansible

Magazine
Marque
Linux Pratique
Numéro
116
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Ansible c’est cool [1], ça vous apporte rapidité de déploiement, une grande souplesse grâce à ses modèles et bien d’autres avantages. Seulement, vous ne pouvez pas le laisser entre toutes les mains, l'oubli d’une option lors d'un déploiement et c’est tout votre infra qui risque d'être impactée.Le moment tant redouté est-il arrivé ? Êtes-vous devenu le Single Point of Failure de toute l'infrastructure ? Allez-vous devoir vous charger de tous les déploiements, et ce, jusqu’à ce que mort s’ensuive ? Non, non, non et non ! Vous n'allez pas vous laisser faire ! Et quoi de mieux pour mettre le pied à l'étrier de tout le monde qu'une simple WebUI ?

Du Dev au Sysadmin : Apprenez à concevoir et distribuer vos applications sur plusieurs plateformes avec CMake

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
105
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Vous avez souvent réalisé des applications que vous aimeriez tester et partager avec vos collègues, mais vous êtes toujours coincés au niveau de l’organisation des fichiers sources et du déploiement ? Vous tombez pile sur l'article qu’il faut pour résoudre ces problèmes.

Par le même auteur

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

PhotoRec : récupération de données

Magazine
Marque
MISC
Numéro
78
|
Mois de parution
mars 2015
|
Domaines
Résumé
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.

Challenge Honeynet 5 : analyse de logs

Magazine
Marque
GNU/Linux Magazine
Numéro
139
|
Mois de parution
juin 2011
|
Résumé
Fin 2010, le projet Honeynet a proposé son 5ème challenge de l'année : une analyse de logs. Cette épreuve a été annoncée comme nécessitant un niveau intermédiaire de connaissance. En pratique, aucun participant n'a donné de résultats satisfaisants ! Analyser correctement des logs est plus difficile que l'on ne le croit et c'est pour cela que je vous propose de découvrir en détail ce challenge.

4ème challenge honeynet : analyse d'attaque ToIP/VoIP

Magazine
Marque
GNU/Linux Magazine
Numéro
135
|
Mois de parution
février 2011
|
Résumé
Après trois challenges successivement sur une faille Windows exploitée via le réseau, l'exploitation de failles liées à un navigateur Internet Explorer et enfin des failles dans l'implémentation du javascript d'Acrobat Reader, le projet Honeynet a proposé au début de l'été un challenge assez original : l'analyse d'attaques d'un système de téléphonie sur Internet (ToIP en francais, VoIP en anglais) à partir des logs applicatifs et ensuite à partir d'une capture réseau.

Challenge Honeynet 3 : analyse mémoire d'une machine compromise

Magazine
Marque
GNU/Linux Magazine
Numéro
131
|
Mois de parution
octobre 2010
|
Résumé
Des opérations bancaires suspectes ont eu lieu sur le compte de la société. Un employé ayant accès au compte a reçu récemment un PDF d'un ancien collègue, mais lorsqu'il a ouvert ce document, celui-ci était vide. Avec le recul, il est possible que ce PDF ait été le moyen de compromettre la sécurité de sa machine. Une image mémoire a été réalisée, notre tâche est de l'analyser pour faire le point sur ce problème de sécurité. Tel est le difficile challenge « Banking Troubles » proposé par le projet Honeynet.

Second challenge Honeynet : le navigateur web

Magazine
Marque
GNU/Linux Magazine
Numéro
130
|
Mois de parution
septembre 2010
|
Résumé
Ce deuxième challenge du projet Honeynet présente une cible de plus en plus fréquente : le navigateur web. Outil indispensable, pas un ordinateur n'en est dépourvu, il se révèle une victime de choix pour s'introduire dans un réseau et intégrer l'ordinateur dans un botnet, un ensemble de machines sous le contrôle non autorisé d'un tiers pour effectuer des attaques concertées : envoi de spam, déni de service, vol d'informations, ...