Toggle menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.
Revision as of 18:48, 17 January 2022 by Algoflash (talk | contribs)

Reverse de formats

Cette page est destinée aux recherches sur le reverse de fichiers et aux essais en cours.

Archives / Fichiers compressés

Le "Definitive Guide To Exploring File Formats" est une bonne entrée en matière pour comprendre l'organisation des fichiers. On pourra éventuellement faire une liste de champs possibles pouvant apparaître dans le header du fichier étudié afin de trouver les différents éléments du header et leur fonction.

Typage des variable

800px|center|thumb|vignette Lors de l'étude de fichiers structurant des données issue d'un programme, il faut garder en tête que les types sont traduits par le compilateur pour une architecture précise. De ce fait, une même valeur peut se traduise en binaire de différentes manières.

Tailles de fichiers

PGCD et taille de fichier

L'idée, c'est d'observer les tailles de fichiers pour retrouver des caractéristiques de certaines archives, telles que la taille du header, et l'éventuelle utilisations de "conteneurs"/chunks de taille fixe.

Pour cela, on prend l'ensemble des tailles en octets de chaque fichier du format étudié. On réalise le PGCD sur ces tailles et si le PGCD est conséquent, c'est qu'on a potentiellement un header et des chunks de la taille du PGCD.

PGCD et taille de header variable

Dans le cas on on aurait un fichier avec une taille de header différente de la taille des chunks, on peut tester les PGCD en soustrayant la taille d'un header que l'on augmente.

La structure du fichier recherché serait la suivante :

|---- HEADER ----|------------ CHUNK 1 ------------|------------ CHUNK 2 ------------|------------ CHUNK N ------------|

On utilisera alors un seuil au dessus duquel nous afficherons la taille du header et la taille du PGCD.

Recherche de propriétés et clair connu

Bruteforce d'un offset fixe

Dans le cas où on peut rassembler un ensemble de caractéristiques que l'on peut clairement attribuer à un groupe de fichiers, il est alors envisageable de bruteforcer pour retrouver l'endroit dans le fichier où ces propriétés sont stockées.

La première étape est de rechercher un ensemble de données pour les réunir dans un csv. Ces données devront être associées à un nom de fichier. On pourra par exemple scraper ces données sur des sites de fans par exemple.

La seconde étape, c'est de programmer la recherche de nombreux encodages cohérents pour chaque propriétés du csv recherchée. On recherchera tous ces encodages dans l'ensemble des fichier de la position 0 à la fin du plus petit des fichiers du lot. On vérifiera alors si la propriété apparait à la position donnée, et si elle n'est pas présente, on passera alors à la position suivante.

Il est à noter que les types sont traduits de différentes manières selon les compilateurs. On prendra soin de tester différentes représentations (nombres signés compléments à 1, à 2, signe et valeur absolue, virgule fixe, virgule flottante, avec différentes tailles de signe/mantis/exposant, etc.).

Ensembles et masque

Ici aussi, on dispose d'un dataset avec des propriétés en lien avec les fichiers étudiés. Il s'agit de regrouper les propriétés par valeurs et d'étudier les changements dans les fichiers associés pour identifier la position potentielle d'une propriété.

Pour les fichiers :

  • A = Ensemble(fichiers AVEC valeur "a" de la propriété)
  • B = Ensemble(fichiers SANS valeur "a" de la propriété)
  • D = FichierMasque # de la taille du fichier ; on y mettra FF ou des bits à 1 si le bit ou l'octet peut représenter la propriété

Pour tous les A si l'octet à l'offset étudié est identique, on met l'octet dans D à FF, 00 sinon Pour tous les B s'il existe un B identique à l'octet correspondant dans A alors on met l'octet dans D à 0x00

On répète l'opération pour toutes les valeurs de la propriété. Pour ajouter de la souplesse, on peut ajouter une tolérance aux erreurs pour un dataset comportant éventuellement des erreurs, ou la présence de valeurs spéciales encodées différemment.

L'approche par bit pose un soucis dans la comparaison entre A et B. Pour rappel, si l'octet à la position i est identique pour A et B, alors on retire l'octet du masque. Mais pour le bit, il nous faut la taille exacte de l'encodage de la propriété car si la taille en bits est inférieure, on retrouve alors des valeurs possiblement identique pour A et B, avec le bit suivant ou précédent qui appartient à la propriété et qui lui, diffère. Idem si la taille en bits est supérieure.

C'est pourquoi il est nécessaire de faire plusieurs masques pour chaque taille en bits. Les similarités ou les différences ajoutées aléatoirement avec une mauvaise taille en bits de l'encodage de la propriété réduisent à néant le masque, ce qui permet de tester en incrémentant les tailles et de ne garder que le masque qui produit un résultat.

Il est aussi à noter le recroisement du masque après un décalage. Si on étudie par exemple les bits de 0 à 4 et qu'on met le masque à 1111 on étudiera ensuite les bits de 1 à 5 et on aura potentiellement 10000 <- ce qui effacerait le travail précédent. L'idée serait de forcer les bits à 1 et de ne pas réinitialiser quand ils sont mis à 1 dans la comparaison de A et de B. On peut éventuellement créer deux masques A <-> A et A <-> B pour en faire ensuite le & logique.

Outils à tester


tester l'entropie avec binwalk (1. dans doku)

Doku

https://en.wikibooks.org/wiki/Reverse_Engineering/File_Formats

Catégorie:Format de fichier Catégorie:Gotcha Force