PhotoRec : récupération de données

Magazine
Marque
MISC
Numéro
78
Mois de parution
mars 2015
Spécialité(s)


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.

 



Article rédigé par

Par le(s) même(s) auteur(s)

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.

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 67 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous