DataRecovery PAIR2007

Informations sur le projet

Numéro du projet : IN13
Titre du projet : Récupération de données
Suiveurs :

• Robert ERRA
• Christophe GRENIER

Etudiants :

• Stephen AMAR
• Laurent DELPRAT
• Jean-Noël GRANDRY
• Sébastien HAIRION
• Igor VALLÉE

Liens Utiles https://www.cgsecurity.org/wiki/DataRecovery_Stage_ESIEA

Comptes rendu des réunions

Compte rendu de la réunion du 12 Mars 2007

Compte rendu de la réunion du 28 Mars 2007

Implémentation du support GUID

Après diverses lectures, voici un petit résumé sur ce format de partition :

Bloc (LBA)	Description
0	MBR (Rétro-compatibilité avec l'ancien système)
1	En-tête de la table de partitions
2 à 2+b-1	Table de partitions
2+b à n-2-b	Données
n-2-b+1 à n-2	Table de partitions de secours
n-1	En-tête de la table de partitions de secours

Le MBR est là au cas où l'utilisateur utiliserai un logiciel incompatible avec le nouveau système de partitions. Il va faire croire qu'il existe une grande partition primaire de type inconnu.

L'en-tête de la table de partitions est un bloc qui définie plusieurs informations sur le disque. Il stock le GUID du disque, pointe vers le premier bloc de la table de partitions et donne la taille de chaque entrée dans la table (la variable b en dépend).

La table de partitions est un tableau qui a chaque entrée correspond une partition. Chaque entrée est composé de :

• un GUID qui identifie de manière unique la partition
• un GUID qui identifie de le type de partition
• Le bloc de début de la partition
• Le bloc de fin de la partition
• Le nom de la partition

https://uefi.org/specifications <--- Important ca !

https://en.wikipedia.org/wiki/Globally_Unique_Identifier
https://en.wikipedia.org/wiki/GUID_Partition_Table

Support du format OpenXML

Comme la plupart des formats de type "Office" (OpenDocument principalement), Il s'agit en réalité d'un fichier zip contenant des fichiers XML et toutes les images/sons/... Donc actuellement, PhotoRec reconnaitrait un fichier de ce type comme un fichier ZIP classique.
Le but est de rajouter un cas à la fonction de reconnaissance des fichiers ZIP. Pour cela, j'ai analysé avec l'aide de Christophe Grenier plusieurs fichiers OpenXML pour déterminer un moyen de les reconnaître par rapport à un fichier ZIP classique.

Nous avons trouver un moyen de trouver si un fichier zip est un fichier OpenXML, mais la difficulté est d'affiner la recherche pour déterminer si c'est un fichier word, excel ou powerpoint. ______________

La solution que nous avons trouvée est de regarder la structure dans le fichier. Le fichier zip est composé de dossiers dont le nom nous donne un indice. Par exemple : - pour les docx, on retrouve les caractères « word/_rels/document.xml » ou « word/document.xml ». - Pour les pptx, on retrouve les caractères « ppt/_rels/document.xml » ou «ppt/document.xml ». - Pour les xlsx, on retrouve les caractères « xl/_rels/document.xml » ou «xl/document.xml ».

C’est grâce à ces caractères que l’on peut dire si c’est un docx, pptx ou xlsx.

Par contre, en plus des docx, pptx et xlsx, Microsoft Office apporte également les nouveaux fichiers docm, xlsm et pptm qui correspondent à des fichiers avec les macros activées. Le problème est que si l’on renomme un docx en docm et vice versa (idem pour les pptx et xlsx avec les pptm et xlsm) cela ne fonctionne pas (au contraire des ppt et pps sous Office 2003 par exemple). Il faut donc différencier les docx des docm. Le problème est que la différence se situe dans un fichier XML qui est compressé dans le docx. Donc à moins de décompresser le fichier nous ne pouvons différencier les docx des docm.

Interface graphique

J'ai enfin fini d'installer une gentoo sur le pc à laurent (config exotique, si quelqu'un a besoin d'installer un linux je commence à être rodé) donc nous sommes en train de nous familiariser avec QTDesigner.

Amélioration du support JPEG

J'ai étudié le challenge de l'année dernière et les erreurs dont Igor m'avait parlé (comme l'image complète dans un apercu, mais coupée en 2 lorsqu'on veut la visualiser).

Donc, petit rappel sur le format JPEG :

Un image JPEG commence par un Marqueur de 2 octets nommé SOI, qui a pour valeur 0xFFD8 et se termine par le marqueur EOI qui a pour valeur 0xFFD9. Tout au long de l'image, il y a aussi des marqueurs de la forme :

0xFF puis 0xXX (avec XX le type du marqueur) puis 0xSSSS (avec SSSS la taille des données qui sont délimité par ce marqueur) puis DDDDDDDD, les données :)

Donc en analysant le résultat de l'année dernière, on peut voir des :

3c) One JPEG non-fragmented, but sector before it has 0xffd8 in the first two bytes 3j) One JPEG fragmented with singe sector in between that starts with 0xffd9

le premier scenario, Photorec s'en fou. Le second est le plus interessant ! Dans un premier temps, Photorec prendra l'image correctement, mais avec ce petit secteur dedans. Mais après, les visualisateurs d'image penseront que l'image s'arrete à ce secteur. Il faut donc trouver un moyen de le supprimer.

Récupération des fichiers MP3

• Fichiers et méta-données supportés

Actuellement mon programme retrouve la taille des fichiers MP3 suivants :

- MPEG 1, 2, 2.5 Layer I/ II/ III (CBR, VBR, VBRI)

Et supporte les méta-informations suivantes :

- ID3v1 & ID3v1.1 (ie. TagV1)

- ID3v2.2.0 & ID3v2.3.0 & ID3v2.4.0

- Lyrics3 & Lyrics3v2.00

- APE Tag v2 (la version 1 des Ape Tag n'a pas de header donc la recherche n'est pas implémentée).

• Méthode de calcul

Pour calculer la taille d'une frame, j'utilise la formule suivante:

Frame_Size = ( (Samples_Per_Frame / Bit_Per_Slot * Bitrate) / Sampling_Rate) + Padding_Size

- Bit Per Slot

Layer  | Bit Per Slot
  I    |    32
 II    |     8
III    |     8

- Samples Per Frame

           | MPEG 1 | MPEG 2(LSF) | MPEG 2.5 (LSF)
Layer I    |   384  |     384     |    384
Layer II   |  1152  |    1152     |   1152
Layer III  |  1152  |     576     |    576

- Padding

J'utilise le padding de la frame mais je fais un calcul de padding moi-même à l'aide de la formule :

count += ((float)(Samples_Per_Frame / 8 * (float) Bitrate / (float) Sampling_Rate) - Frame_Size);
if(count>0.5)
    count--;

A chaque frame, la valeur de ce compteur doit rester inférieure à 0.5

si le compteur > 0.5 et que l'on ne trouve pas la frame à l'endroit prévu (par le calcul de la Frame_Size) alors on va "changer" le padding et utiliser celui prévu par le calcul (ie. si count>0.5 alors padding=1 sinon padding=0).

sinon le compteur ne sert à rien, tout se déroule comme prévu.

MAJ : Le bit de padding est défini dans le header de chaque frame mp3, on en tiendra compte normalement.

Le problème de décalage d'octet, entre deux frames, provenait de l'utilisation d'une mauvaise formule :

Frame_Size = (144 * Bitrate / Sampling_Rate) + Padding_Size

Ainsi, dans certain cas la Frame_Size retournait la taille de plusieurs frames et ne tenait donc pas compte des éventuels bit de padding des frames "sautées".

• Résultats

Actuellement, je retrouve correctement une grande partie des fichiers mp3.

J'ai testé mon algorithme sur les 42 samples disponibles sur https://www.getid3.org/

Score actuel 40 sur 42 :

-> ./sample/Lyrics3-1 not 5100 bytes long.mp3

La première frame audio utilise un sample rate "réservé" donc le programme ne peut pas déterminer la taille de la frame.

-> ./sample/New ID3v1 tag created by - Meracl ID3 Tag Writer v1.3.4.mp3
totalsize = 71496
real size = 71623

Le TAG (ID3v1) est décalé d'un octet (-1) donc il n'est pas trouvé.

Sur un échantillon de 8410 mp3 :

Score          : 6273 / 8410           -> parfaitement retrouvés

ERREURS
Mauvais        : (1%)   22 / 2137      -> pas de header ID3 ou de header MP3	
Trop grand     : (26%) 561 / 2137      -> taille trouvée > taille réelle
> 95           : (24%) 514 / 2137      -> au moins 95% du fichier est retrouvé
Aucune frame   : (38%) 807 / 2137      -> auncune frame n'est trouvé après le header
                                          (problème de padding du ID3!!)
< 5            : (1)    21 / 2137      -> moins de 5% du fichier est retrouvé
NC             : (10%) 205 / 2137      -> ??!

Le programme retrouve 74.6% des fichiers correctement.

Si on considère les cas d'erreur "taille trouvée trop grande" et "au moins 95% du fichier a été retrouvé" comme acceptable, on arrive à :

plus de 87% des fichiers sont "acceptablement" retrouvés.

• TODO

- Implémentation dans PhotoRec.

- Support des Music Match tag : ces tags auraient été utilisé par des anciennes versions de Music Match (ce tag se trouve à la fin du fichier).

- Sur certain mp3, il peut y avoir un problème de détection de la première frame audio à cause de padding du ID3 !! (des octets '00' sont rajoutés entre la "fin" du ID3v2 et le début de la première frame, cela dans le but d'éviter de réécrire entièrement le fichier mp3 en cas d'ajout d'information dans l'ID3v2).

• Sources

MPEG Audio Layer I/II/III frame header : http://www.mp3-tech.org/programmer/frame_header.html

MPEG Audio Frame Header  : https://www.codeproject.com/Articles/8295/MPEG-Audio-Frame-Header

ID3 and Lyrics3 documents  : https://www.getid3.org/