Manipulation de miniatures de fichiers jpg

Manipulation de miniatures de fichiers jpg

J'avais envie de jouer avec les miniatures intégrées aux photos au format jpg pour voir comment les différents OS réagissaient...

J'ai donc pris deux photos avec mon smartphone. Il s'agit d'une feuille blanche sur laquelle j'ai écrit une fois "petite" et l'autre fois "grande" :

petite et grande

J'ai donc deux fichiers jpg contenant chacun une miniature. J'appellerai l'image sur laquelle j'ai écrit "petite" la petite et celle sur laquelle j'ai écrit "grande" la grande. L'idée est de prendre la miniature de la petite pour la mettre dans la grande.

Muni d'un bon éditeur hexadécimal, j'avais trois parties à modifier :

  • La taille du marqueur APP1 à l'offset 0x4, qui correspond à la taille des métadonnées Exif,
  • La taille de la miniature, dans ce cas à l'offset 0x4B8,
  • le contenu de la miniature, dans ce cas à l'offset 0x4D0

grande hexadecimal

Dans la grande image, la miniature fait 6153 octets (0x1809). Dans la petite image, la miniature est légèrement plus grande. Elle fait 6418 octets (0x1912). Ainsi, j'ai effectué les manipulations suivantes :

  • suppression de la miniature entre l'offset 0x4D0 et 0x1CD8 pour la remplacer par l'autre miniature,
  • remplacement de la taille de la miniature à l'offset 0x4B8 : 0x1809 (6153) devient 0x1912 (6418) et on écrit donc 0x1219 (little endian)
  • remplacement de la taille du marqueur APP1 à l'offset 0x4 : on a ajouté 265 octets au fichiers et donc 0x1CD5 (7381) devient 0x1DDE (7646) et on écrit donc 0x1DDE (big endian)

On obtient donc ceci :

grande modifiée hexadecimal

L'idée est ensuite de voir comment les systèmes d'exploitations se comportent avec une telle image.

En ce qui concerne MacOS, voici ce que j'obtiens dans le finder et sur mon bureau : macOS finder

macOS bureau

En ce qui concerne Windows 10, voici ce que j'obtiens :

windows 10 explorer

En ce qui concerne Windows 7, en dehors du fait que l'image n'est pas pivotée, les résultats sont identiques :

windows 7 explorer

Enfin sous Android, voici ce que j'obtiens (en vidéo) :

On constate donc que les systèmes d'exploitations ne génèrent pas les miniatures, mais utilisent celles qui sont présentes dans les métadonnées des fichiers.

D'un point de vue de l'investigation numérique, il est important de faire attention à ce genre de choses, sinon on risque de passer à coté.

En bonus, à partir des captures de l'éditeur hexadécimal, ceux qui le souhaitent pourront tenter de me dire quand j'ai pris ces photos (plutôt facile) mais surtout où je les ai prises (un peu plus compliqué)...

SHAttered, comment cela peut fonctionner ? Analyse des fichiers

SHAttered, comment cela peut fonctionner ? Analyse des fichiers

La semaine dernière, une équipe du CWI et de Google Research a publié le site shattered.io. Ils montrent la première collision SHA1 réelle. Il s'agit de générer deux fichiers différents présentant le même hash, SHA1 dans ce cas. L'objet de cet article est l'analyse en profondeur de ces deux fichiers afin de déterminer comment cela peut fonctionner.

On trouve les PDF ici et .

Tout d'abord, ils présentent bien un SHA1 identique, mais un MD5 différent :

shattered_md5_sha1

Les MD5 montrent que les fichiers sont bien différents.

Il s'agit de PDF ne contenant qu'une page. Visuellement, on les différencie par la couleur de fond de la partie haute. Sur le premier fichier, elle est bleue et sur le second, elle est rouge.

2shattered

Les deux fichiers font exactement la même taille. Lorsqu'on les compare, on constate que 99,97 % de leur contenu sont strictement identiques. Seuls 62 octets entre les offset 0xC0 et 0x130 sont différents :

shatteredvs

On remarque également que les fichiers PDF contiennent chacun la signature d'un fichier JPG à l'offset 0x95. Ces images occupent, à elles seules, plus de 99 % des PDF. A l'aide de PDF Stream Dumper, on peut visualiser les différents flux des PDF. On constate qu'il n'y en a que 13 et qu'ils sont structurés très simplement. Ce logiciel permet également d'extraire les fichiers JPG :

shattered_pdfstream

Les deux fichiers JPG contiennent les mêmes différences que les fichiers PDF.

shattered_jpgvs

En s'intéressant à la structure les fichiers JPG, on remarque qu'ils contiennent des commentaires de tailles différentes :

shattered_jpgvs_color

En reproduisant, sur l'intégralité des deux images, le même processus que sur l'image précédente, on obtient quelque chose comme cela :

shattered_jps_comm

On en conclut qu'en réalité, les fichiers contiennent tous les deux les deux images.
De plus, seul l'octet à l'offset 0x2B (0x73 pour la première image et 0x7F pour la deuxième), c'est à dire le deuxième octet de la taille du deuxième commentaire, permet de passer d'une image à l'autre. Ainsi, le logiciel en charge d'afficher les images ne lit pas les mêmes zones de données en fonction de l'octet à l'offset 0x2B. Dans le cas de l'image du premier fichier, seule la seconde moitié est réellement utile, et pour l'image du second fichier, seule la première moitié est réellement utile.

Au final, une fois que les JPG et les PDF ont été générés, les chercheurs disposaient de 369 octets pour générer leur collision. Ils n'en ont utilisé que 127, dont seulement 61 modifiés.

Pour conclure, déterminer comment cela peut fonctionner est assez simple. Mais générer la collision, c'est là qu'est la difficulté, surtout en terme de puissance de calcul.