lundi 01 septembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Hachoir, le couteau suisse qui découpe vos fichiers binaires

Posté par Victor STINNER (page perso, ). Modéré le 19 août 2006.
0
Hachoir est un projet permettant de lire toutes les informations contenues dans un fichier binaire. Effectivement, contrairement aux fichiers textes qui se lisent facilement : qui aujourd'hui est capable d'analyser le contenu d'une image PNG à l'aide d'un éditeur hexadécimal ?

La version 0.5, qui vient de sortir, supporte la majorité des formats de fichier « courants ». Cela va de l'image PNG à la vidéo AVI en passant par les archives bzip2 ou encore le système de fichier ext2. Par contre, tous les parseurs ne sont pas encore complets : les zones inconnues sont marquées « raw ».

Le parseur a un fonctionnement totalement paresseux : les informations ne sont lues que lorsqu'elles sont demandées, et les champs ne sont crées que lorsque c'est nécessaire. Il est dès lors possible de lire des fichiers complexes et/ou de grande taille (ex: disque dur de 10 Go).

Hachoir est avant tout une bibliothèque écrite en Python, mais plusieurs scripts l'utilisant sont disponibles. hachoir-metadata permet d'extraire les méta-données : durée d'une musique, taille d'une image, commentaires, etc. hachoir-urwid est une interface interactive permettant d'explorer le contenu d'un fichier. hachoir-grep permet de rechercher une chaîne de caractère dans un fichier, ou simplement lister toutes les chaînes d'un fichier.

NdM : Hachoir est disponible sous licence GNU/GPL

> Lire la suite (39 commentaires, moyenne: 3,8).   [dépêche : 1417 caractères]

Nouveautés de la version 0.5
Le script "hachoir" a été découpé en plusieurs scripts plus spécifiques : chaque script a maintenant ses propres options. En particulier, le script hachoir-metadata gagne les options --level et --mime (et accepte plusieurs fichiers en entrée), hachoir-urwid gagne les option --preload et --path. Création du script hachoir-grep. Ajout des parseurs ASF (vidéo WMV et musique WMA), MOV (vidéo Quicktime), CDA (cd audio sous Windows). Ajout d'un extracteur de méta-données pour le format Matroska. Meilleure gestion des charsets pour les chaînes de caractères : elles sont maintenant stockées en Unicode. Création d'un jeu de fichiers permettant d'automatiser les tests sur Hachoir.

Cette nouvelle version marque également le début du support des containers, soit essentiellement : archives, systèmes de fichiers et containers multimédia. En plus de la structure de ces formats, on peut vouloir analyser le contenu, alors même que celui-ci est fragmenté.

La liste complète des nouveautés est disponible sur le wiki.

On recrute !
Hachoir aurait besoin :


Contactez nous si vous êtes intéressés

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Souvenir...

Posté par ThesmallgamerS () le 19/08/2006 à 13:54. (lien). Évalué à 10.

Je me souviens encore de l'annonce du devellopement de Hachoir 0.0.01 sur DLFP, puis l'annonces de la version 0.2... Que c'est beau de voir un projet naître, grandir et vivre devant ses yeux. C'est encore plus mieux quand on est contributeur du projet ;-).

Hum.

Idées d'utilisation

Posté par Victor STINNER (page perso, ) le 19/08/2006 à 15:12. (lien). Évalué à 10.

Un ami m'a fait remarqué, à juste titre, qu'on parle peu des applications pratiques. Et bien, Hachoir peut déjà replacer la commande file (file --mime <=> hachoir-metadata --mime) et est une très bonne alternative au programme extract (extract <=> hachoir-metadata) : hachoir arrive souvent à extraire plus d'informations.

hachoir-grep est assez proche du programme strings sauf qu'il ne donne aucun "faux positif" et extrait les chaînes dans différents charsets (UTF-16LE, UTF-16BE, UTF-8, latin-1, etc.), là où strings a besoin de plusieurs appels. Mais la qualité de hachoir-grep dépend de la qualité des parseurs, et certains sont encore incomplets (il n'y a pas de faux-positif, mais on zappe beaucoup de chaînes si ça se trouve).

hachoir-urwid permet de vérifier ce que contient un fichier. On y découvre des fois des surprises. J'ai appris par exemple d'une image JPEG embarque une miniature (et des fois, la miniature n'est pas mise à jour, on découvre des choses......), qu'une vidéo Matroska peut contenir d'autres fichiers (ex: fichier texte, image, etc.), qu'un document Word est basé sur un système de fichier proche de FAT, qu'un document Word contient des secteurs (512 ou 64 octets) inutilisés (là où on trouve des paragraphes soit-disant supprimés...), etc. J'ai aussi que dans une vidéo : le titre du film, un lien vers le site d'où provient la vidéo, une partie des acteurs, etc. La majorité des fichiers AVI contiennent le nom du logiciel utilisé pour générer la vidéo : et quel logiciel affiche ces informations ? Perso, je n'en connais aucun (même pas extract :-)).
--
Autre idée : écrire un programme qui va valider un fichier à la manière d'une DTD ou XML Schema pour un document XML. Un tel programme mis en amont d'un serveur (web) éviterait certaines attaques (cf. faille JPEG, faille gzip, etc.).

Une fois que Hachoir permettra l'édition d'un document. Les possibilités seront encore augmentées.

Ex: éditer/ajouter des commentaires à n'importe quel document.

Ex: pouvoir supprimer tous les "mouchards" d'un document (auteur, date de création, logiciel utilisé pour la création, coordonnées GPS (si si, ça existe dans Exif), etc.).

Ex: pouvoir injecter un document dans un autre document ("stéganographie du pauvre").

Ex: supprimer une partie inutile d'un fichier pour réduire sa taille (ex: commentaires du logiciel de création, commentaires inutiles, "padding" inutile, etc.).

Ceux ne sont que quelques idées. Avec un peu d'imagination, on peut en trouver d'autres. Après "yapluka".

Haypo

Package

Posté par salvaire () le 19/08/2006 à 15:18. (lien). Évalué à 4.

Un Hachoir générique est une excellente idée! Éducatif, étude d'un format, ingénierie renversé etc

Il te faut absolument un .tar.gz avec autotools!

svn n'est pas aussi courant que cvs (trop jeune pour IT ...) et j'aime pas les "rm -rf $hachoir" dans ton script ...

J'ai mis en gras ce qui est très rebutant:


* Debian/Ubuntu: apt-get install python2.4-setuptools
* Other distrib: download ez_setup.py and execute it as root (another copy if needed: ez_setup.py)

it needs svn and wget (and python2.4) programs

N'oublie pas que tes utilisateurs potentiels n'ont pas forcément les même droits et devoirs que toi sur ton pc! IT n'est pas geek ...

#!/usr/bin/env python2.4
n'est pas "portable", configure doit insérer la bonne commande.

from hachoir.error
idem, tu dois insérer le chemin, export PYTHONPATH= c'est pas automatique.

Si tu veux je peux t'envoyer un exemple avec essentiellement du Perl, mais aussi Python. Tu n'auras qu'a retirer le superflu et modifier.
Je pense que les commandes dans script doivent être installé dans bin, et les .py de hachoir dans lib.

Compléments

Posté par lcld () le 19/08/2006 à 15:54. (lien). Évalué à 10.

Pour commencer, non, il n'y a pas encore d'interface graphique. Je sais qu'une interface console rebute de plus en plus de monde. C'est dommage, le mode texte a pourtant de nombreux avantages. Sachant que l'aide est quasiment absente, il faudrait que je détaille un peu.


Avant j'aimerais parler d'une des nouveautés d'Hachoir : le support du système de fichiers FAT. Euh... oops on est sur linuxfr.org... Oui, ça fait bizarre. D'ailleurs, ce format ne m'intéresse pas du tout. Mais à défaut d'être bien foutu, il a l'avantage d'être simple et de bien mettre en évidence les limitations d'Hachoir. Sans les améliorations apportées à l'API d'Hachoir, implémenter FAT aurait été presque impossible.

[1] Ce système de fichiers n'a pas une structure arborescente. Tout est à plat et pour atteindre un fichier en particulier, il faudrait presque tout parser et on finirait avec un liste de plusieurs miliers d'entrées. On ne peut plus dire qu'Hachoir reste paresseux ; on serait vite limité à des petits FS.

[2] Admettons qu'on atteigne le champ qui contient les données du fichier recherché. On peut vouloir hacher le contenu. C'était possible avec Hachoir 0.1. Voilà, la feature est de nouveau là, dans l'interface urwid.

[3] Oui mais... quel système de fichiers ne fragmente jamais ? Sûrement pas la FAT.


Hachoir 0.5 marque le début du support des containers.
J'appelle container tout format destiné à contenir des données dans un format quelconque. Les catégories les plus courantes sont :
- archives : C'est le cas le plus facile. Le contenu est en un seul morceau. (La compression est une toute autre histoire)
- systèmes de fichiers : Ca se corce. On fait souvent face à des contenus fragmentés.
- containers multimedia : Là, ça peut devenir un cauchemar. Il s'agit souvent d'un flux de paquets (un paquet pouvant être à son tour fragmenté ; avec 2 types de fragmentation, finir le parseur ogg va être un casse-tête) et le format ne peut pas se contenter d'un flux bêtement défragmenté : il peut avoir besoin de connaître le découpage.

Dans l'interface urwid, 2 raccourcis ont fait leur apparition :
1. La touche 'espace', utile pour les parseurs non terminés. Il considère le champ actuellement sélectionné comme un contenu ayant son propre format. Une nouvelle fenêtre est ouverte, Hachoir cherche un parseur approprié et commence un nouveau hachage. On peut l'utiliser n'importe où et même pour un fichier non fragmenté dans un FS. Actuellement, c'est le seulement moyen d'hacher :
- une partition si on a lancé hachoir sur un disque entier
- un fichier attaché à un fichier matroska
- ...
2. La touche 'f' qui, pour le moment, fonctionne uniquement pour le parseur FAT. Une fois que le début d'un fichier (fragmenté ou non) est sélectionné (il ne faut pas sélectionner le champ "data" mais le champ parent), une nouvelle fenêtre est ouverte et cette fois-ci, c'est tout le contenu défragmenté qui est haché.


Pour ceux qui seraient intéressés par le support des flux fragmentés, un bug sérieux affecte malheureusement la version 0.5. Je m'en suis aperçu quelques heures après que tout a été packagé. Il faudra alors appliquer le patch http://hachoir.org/changeset/726 (plutôt gruik d'ailleurs ; va falloir que je revois l'API) ou télécharger depuis le dépôt subversion.


Une autre nouveauté : le lien interne. Dans urwid, on suit un lien tout comme on développe/réduit un champ : avec la touche 'entrée'. Le lien permet de faciliter là navigation.
Pour l'instant, il y en a très peu : dans les parseurs Matroska et FAT uniquement.

Dans les fichiers Matroska, il existe une structure ('Cues') qui indexe certaines trames. En général, les trames clés d'un flux video. Il faut consulter plusieurs champs pour localiser la trame clé dans le fichier, et de toute façon, même si un seul champ suffisait, celui-ci ne serait pas forcément intelligible : indice de temps, ou position en octets par rapport à un endroit bien précis (et lire les specs pour le connaître), etc.

Dans le cas du système FAT, les liens permettent par exemple de naviguer entre les différents fragments d'un fichier.
Mais c'est surtout en suivant le lien dans une entrée de répertoire qu'on déclenche le hachage du fichier correspondant à cet entrée. Cela résoud [1]. On laisse des zones non hachées (padding) puis on hache ces zones à la demande.

problème sous Arch x86_64

Posté par arno () le 19/08/2006 à 19:05. (lien). Évalué à 4.

J'ai fait un PKGBUILD pour Arch:
http://bursab.free.fr/pkgs/hachoir-svn/PKGBUILD

Manque de bol, à l'exécution de n'importe quel scripts j'obtiens ça:


$ hachoir-grep
Traceback (most recent call last):
File "/usr/bin/hachoir-grep", line 5, in ?
from hachoir.cmd_line import (createParser, runBenchmark,
File "/usr/lib/python2.4/site-packages/hachoir/cmd_line.py", line 2, in ?
from hachoir.plugin import printParserList
File "/usr/lib/python2.4/site-packages/hachoir/plugin.py", line 10, in ?
from hachoir.field import Parser
File "/usr/lib/python2.4/site-packages/hachoir/field/__init__.py", line 3, in ?
from hachoir.field.bit_field import Bit, Bits, RawBits
File "/usr/lib/python2.4/site-packages/hachoir/field/bit_field.py", line 9, in ?
from hachoir.bits import countBits
File "/usr/lib/python2.4/site-packages/hachoir/bits.py", line 208, in ?
assert struct.calcsize("L") == 4
AssertionError


Une idée?

Packaging

Posté par rdem (page perso, ) le 20/08/2006 à 00:49. (lien). Évalué à 3.

Bonjour,

je peux essayer de packager pour debian (instable / testing / stable)
OpenBSD (je relance bientôt mon serveur)
Gentoo (quand j'aurais réinstallé un petit pc sous gentoo)

Je n'ai jamais packagé pour aucun de ces systèmes, mais je veux bien essayer d'apprendre.

Je veux bien aussi aider pour le code, mais mon experience en python se limite pour le moment a une relecture d'un projet de cours.

En attendant, je vais déjà commencer par lire le code ;)

--
partisan du libre, j'utilise Debian et OpenBSD
Ma fiertée

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1597s (dont 0.0319 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !