Ce journal est un appel à contribution
J'ai pas mal bossé sur une réécriture from scratch (version 0.2) qui corrige les défauts de la première ébauche (v0.1) : meilleure API (plus simple, plus claire), plus rapide (temps de chargement), adresse et taille en bit (et non plus en octet), support de l'écriture (ajout/suppression/modification de champs), séparation nette entre la bibliothèque et l'interface utilisateur, etc. La nouvelle version est encore en gros travaux bien qu'elle fonctionne déjà bien en mode visualisation (uniquement en mode texte pour l'instant). La modification d'un fichier reste encore expérimentale.
Je n'ai pas trop touché à la version précédente, j'ai écrit quelques parseurs supplémentaires. J'ai écrit en quelques heures un parseur des protocoles réseaux (Ethernet, ARP, IPv4, TCP, UDP). Le résultat ressemble fortement à Ethereal (normal, je me suis basé dessus).
http://www.haypocalc.com/tmp/hachoir_tcpdump.png
Pour prévoir l'accueil de contributeurs, j'ai demandé un compte sur le service Python hosting qui offre gratuitement (pour les projets relatifs au Python) SubVersion + Trac (très agréable à utiliser). J'ai migré le site internet, traduit en anglais au passage, à cette adresse :
http://hachoir.python-hosting.com/
Bon, je vais quand même rappeler ce qu'est le projet Hachoir : Hachoir est une bibliothèque écrite en Python permettant de visualiser le contenu d'un fichier binaire sous forme de champs ; un champ étant l'information la plus petite qui puisse être stockée (bit, entier, flottant, chaîne). Les champs sont organisés hiérachiquement (sous forme d'arbre), comme un système de fichier Unix par exemple. On travaille vraiment au plus bas-niveau, très proche du fichier.
L'intérêt est de savoir exactement ce que contient un fichier, comment il est construit. Les utilisations peuvent être très nombreuses : extraction d'informations précises d'un fichier (un/plusieurs champ(s) dans un fichier, tel que les méta-informations), modifier certains champs d'un fichier normalement inaccessibles (ex: commentaires d'un archive gzip), convertir un format de fichier vers un autre format, etc.
Il n'existe pas encore d'application utilisant Hachoir, mise à part un visionneur (interface GTK) de fichier basé sur la version 0.1. Mais le potentiel d'applications est très large.
Actualités précédentes sur mon projet :
http://linuxfr.org/2005/12/29/20131.html (29 décembre 2005)
http://linuxfr.org/~haypo/19974.html (15 novembre 2005)
Retrouvez plus d'informations sur le site web :
http://hachoir.python-hosting.com/
Haypo
Journal Nouvelles du programme Hachoir
26
mar.
2006
# Pour simplifier les tests
Posté par Victor STINNER (site web personnel) . Évalué à 4.
http://www.haypocalc.com/perso/prog/hachoir/hachoir-2006-03-(...) : 81 Ko (pour ça Python est appréciable : les archives sont petites !)
Il faut Python 2.4 et pygtk pour l'utiliser. Ca marche sous Windows selon mes derniers tests (et bien sûr sous Linux, et très certainement tous les OS qui ont Python et pyGTK).
Haypo
# Merci
Posté par Anonyme . Évalué à 2.
Quand j'aurais besoin d'un plugin non-existant, j'essaierai d'écrire un plugin.
# bruteforce
Posté par M . Évalué à 3.
Les différents morceaux serait retrouvés à partir de signature des différents formats.
[^] # Re: bruteforce
Posté par Thomas Douillard . Évalué à 2.
(Je pose la question par curiosité, si ca existe pas va pas te faire chier à l'implémenter si ça sert à rien ;) )
[^] # Re: bruteforce
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Oui ! Hé hé hé. Je me suis essayé à la rétro-ingénierie, et j'ai noté des motifs particuliers. J'ai écrit un algo pour reconnaitre l'organisation utilisée dans le format PNG par exemple :
La taille étant un entier, signé ou non, d'un taille de 8, 16 ou 32 bits.
Bref oui, c'est de la "brute force", et ça marche plutôt bien ! (testé avec succès sur le format Worms2 DIR et PNG) En plus c'est très rapide (moins d'une seconde je crois bien) ;-)
Si ça t'intéresse, je vais refaire fonctionner le code que j'avais écrit. C'est le fichier "reverse.py" qui contient des trucs comme ça.
(2) [est il] possible de gérer des formats de fichiers dont la présence de certains champs (ou groupe de champs) est optionelle, ou encore dépend de la valeur d'un champ précédent ?
Bien sûr ;-) J'ai justement fait un gros travail là-dessus. C'était un des objectifs à remplir. Ca pourrait être un CRC32 recalculé lors de l'enregistrement, des champs qui sont supprimés quand on modifie un flag, ou un champ qui est ajouté quand on modifie un autre drapeau.
D'ailleurs, mes essais sur l'écriture ont été fait sur le format Gzip : lorsqu'on assigne la valeur "True" au champ "has_comment", un événement est déclanché qui va insérer un nouveau champ.
Je prévois un peu tout et n'importe quoi comme événement : champ déplacé, champ redimensionné, champ modifié, nouveau champ, etc. Après, il faut écrire le code qui gère tous les cas ... c'est pas gagné :-P
Haypo
[^] # Re: bruteforce
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Ah, j'ai réalisé que tu parles peut-être en fait des parseurs (lecture d'un fichier). Si c'est le cas : bien sûr ! C'est supporté depuis toujours ça :-) Tous les formats nécessites des "if" (et certains des "for"), voir des trucs plus complexes ...
Haypo
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.