Sortie de la version 2005-12-28 du Hachoir

Posté par (page perso) . Modéré par jerome.
Tags :
0
29
déc.
2005
Python
Hachoir est un outil écrit en Python permettant de visualiser le contenu d'un fichier binaire de manière intelligible. Son objectif n'est pas de reconnaître tous les formats, mais d'avoir une boîte à outils très complète pour supporter rapidement de nouveaux formats. De nombreux formats sont déjà supportés de base (musique mp3, partition ext2, vidéo avi, exécutable elf, archive rpm, image xcf, etc.).

Les données ne sont réellement lues que lorsqu'elles sont accédées. Ceci permet de traiter de très gros fichiers sans problème (ex: partition de 9 Go contenant plusieurs centaine de milliers d'objets), et le chargement d'un fichier prend rarement plus d'une seconde.

Le projet est encore jeune, mais n'hésitez pas à le tester et m'envoyer vos retours d'expérience. Dépendances :

Pour utiliser le Hachoir, vous aurez besoin de Python 2.3, Python GTK+, et Python Glade. Il est conseillé d'utiliser Python Magic (vient de libmagic et de la commande file) si c'est possible.

Pour entrer dans les détails :

L'élément le plus petit est un "chunk" qui peut être de trois types : FormatChunk (entier, chaîne binaire, tableau d'entiers, etc.), StringChunk (chaîne de caractère C, ligne Unix, etc.) et BitsChunk (champs de bits). La décompression est supportée (bzip2, gzip, rle, etc.), et le déchiffrement est prévu (pour plus tard).

Un filtre est un ensemble de chunks sachant qu'il existe un 4e type, FilterChunk, qui embarque à son tour un filtre. Ce qui donne finalement un arbre.

Pour la suite :

Les prochains chantiers sont :
  • la possibilité d'éditer un filtre (ajouter / modifier / supprimer un chunk), ce qui était possible avec la version précédente du Hachoir d'ailleurs ;
  • la possibilité d'éditer le fichier (en mettant à jour les champs qui en dépendent bien sûr).
  • # Moteurs de recherche de bureau

    Posté par (page perso) . Évalué à 9.

    Est-ce que ce programme ne pourrait pas avoir une application pour les moteurs de recherche de bureau (kat, beagle, et autre...) ? Parcequ'en gros, il te sort du full-text (avec en plus une structure, mais qui n'a pas d'intérêt pour les moteurs de recherche de bureau) à partir d'un fichier ou j'ai mal compris ?
  • # très interessant

    Posté par . Évalué à 4.

    Ca peut etre très util ce programme ... entre autre pour debugger un problème.
  • # Rétro-ingénierie

    Posté par (page perso) . Évalué à 9.

    Là où le Hachoir est le plus utile actuellement, c'est pour deviner un format binaire. Je bosse d'ailleurs sur le format DIR de Worms2 avec un ami (enfin, surtout lui). Un bon morceau du format est reconnu, reste à comprendre l'algorithme de compression des images.

    Si quelqu'un est intéressé (et/ou compétent :-)), je lui envoie le fichier pour qu'il nous file un coup de main.

    N'empêche stocker les données (hors palette de couleur) 640x480 pixels et 256 couleurs (80 pour être exact) dans 274 octets, je dis chapeau ! C'est peut-être un format vectoriel, ou bien compression avec codage des répétitions ? Ou alors un pattern utilisant d'autres images ? Genre : tu me dessines l'image 3 en (10,20), tu me dessines l'image 6 en (200,400), etc.

    Au passage, j'ai trouvé un site intéressant sur le format des données des jeux :
    http://wiki.xentax.com/index.php/Main_Page

    Haypo
    • [^] # Re: Rétro-ingénierie

      Posté par . Évalué à 7.

      Du 640x480, même en monochromone, en bitmap, ça ne PEUT PAS tenir sur 274 octets (sauf si on s'appelle i2bp ;)

      Il y a de fortes chances que les 274 octets référencent des images externes (amusant, ça me rappelle l'bon vieux temps des moteurs de shoot'em'up...)

      1° octet : numéro d'image à afficher ligne 1, colonne 1
      2° octet: numéro d'image à afficher ligne 1, colonne 2
      ...
      n° octet: numéro d'image à afficher ligne 2, colonne 1
      ..
      etc etc

      Oui mais voila: 640x480 n'est pas divisible par 274 (on ne peut pas découper l'image en 274 blocs identiques), ce qui veut dire qu'il y a des octets qui servent aussi à d'autres choses, ou que la taille des blocs est variable. Peut être que les premiers octets servent à référencer une 'image de base' ou il faut aller piocher les blocs référencés par la suite ? Peut être aussi que je suis à côté de la plaque.

      Je pense que tu vas passer des soirées sympas avec un éditeur hexa, avec du 'je remplace un octet, je lance le jeu, je note la différence'...
      • [^] # Re: Rétro-ingénierie

        Posté par (page perso) . Évalué à 3.

        J'ai ouvert un fil de discution sur le forum de XeNTaX, site dédié à la rétro-ingénierie de formats binaires de jeux vidéos. On les trouve les auteurs des logiciels Game Extractor et MultiEx Commander. Ces gars sont vraiment doués dans ce domaine, leurs logiciels reconnaissent plusieurs centaines de jeux (parfois en autorisant l'écriture).

        Beaucoup d'idées sont échangés sur le format de Worms2 :
        http://forum.xentax.com/viewtopic.php?t=1659

        Par contre, je me suis trompé dans les tailles. Quelques valeurs :
        - Image de 640x28 pixels en 8 bits/pixel => 259 octets
        - Image de 640x28 pixels en 8 bits/pixel => 333 octets
        - Image de 28x479 pixels en 8 bits/pixel => 535 octets

        Ces images ne contiennent que peu d'information, elles sont donc susceptible d'être bien compressibles.

        Haypo
    • [^] # Re: Rétro-ingénierie

      Posté par (page perso) . Évalué à 5.

      Pour continuer sur le thème de la rétro-ingénierie, j'ai écrit une classe Reverse qui devrait faciliter le travail. L'idée générale est de donner en entrée plusieurs sources d'informations, et des informations approximatives. L'outil va alors tenter d'en déduire des conclusions.

      Les premiers essais sont très intéressant. J'ai donné 10 fichiers gzip en entrée, la taille du fichier décompressé, et la classe m'a dit à quelle position se trouvait le champ ! J'ai fait un autre test sur un champ que je n'arrivais pas à trouver dans les ressources du jeu Worms 2 ... ben j'ai pas trouvé car je demandais la valeur exacte, alors qu'en fait il fallait la valeur plus un :-) Au second test, en spécifiant un intervalle, mon outil trouve le résultat tout de suite ! Le format, nombre d'octets et endian, sont détectés automatiquement (ils sont testés l'un après l'autre en fait).

      Après, on peut imaginer des trucs plus costaux, comme reconnaître un motif. Exemple : header de taille fixe, chunk contenant sa taille, chunk contenant sa taille, etc. => format classique et facilement identifiable (ça prend du temps de calcul, mais c'est facile).

      Haypo
  • # Bravo !

    Posté par . Évalué à 5.

    Je viens de tester hachoir sur plusieurs fichiers (images, vidéos, et même exes windows), et je suis très fortement impressioné !
    Donc bravo à l'auteur pour son travail, et espérons que d'autres plugins sortiront !
  • # Un beau plugin de CraCkERZ

    Posté par (page perso) . Évalué à 6.

    un plugin qui permet de récupérer les mots de passe et autres broutilles dans les fichiers sniffés (en wifi, en ethernet...) ;)
    Quoi il existe des wifis non cryptés... -> toutes les 9Box d'avant Juillet-Aout dernier :)
  • # Récupération après cracsh

    Posté par (page perso) . Évalué à 3.

    Je viens de perdre une partition suite à des pistes défectueuses du disque dur. Après avoir récupéré ce qui l'était http://abul.org/article335.html jai dû identifier les fichiers de lost+found qui avaient perdu leurs noms. Ils se nommaient alors :
    45_79078 45_80409 45_80979 45_82674 45_84740 45_86903 45_88031 4_63568 66766_67669
    45_79080 45_80431 45_80987 45_82700 45_84746 45_86904 45_88033 4_63958 66766_67674

    Je pense que Hachoir aurait pu me rendre service.
    • [^] # Commande file

      Posté par . Évalué à 6.

      La commande file peut également avoir pas mal d'utilités.
      Elle permet de connaître le type d'un fichier, et ne se base pas sur l'extension, mais sur des "magic numbers".
      Elle ne permet pas comme Hachoir de disséquer très précisément les fichiers supportés, mais elle est présente sur presque toutes les distributions et supporte en générale un grand type de fichiers. Sur certains fichiers elle peut afficher plus d'informations, par exemple la résolution d'une image ou le sample rate d'un fichier audio.

      Pour l'information, sur ma distribution le fichier de magic numbers est dans /usr/share/misc/file/magic et fait plus de 10000 lignes.
  • # jsuis déçu

    Posté par . Évalué à 3.

    fausse joie

    permettant de visualiser le contenu d'un fichier binaire de manière intelligible


    Zut, j'ai cru que ça allait afficher de la musique et jouer des images.
    Ou plutôt le contraire.

    enfin pour moi c'est ça afficher un fichier binnaire de façon intéligible


    Sinon, ça a l'air d'un super programme, mais geek-only ;-)
    • [^] # Re: jsuis déçu

      Posté par (page perso) . Évalué à 6.

      bin à toi de rajouter les plugins pour lancer le visualiseur approprié ;-)

      je te sens chaud sur l'action, je sais pas pourquoi... en plus ça ferait de cet outil un véritable couteau suisse.
      • [^] # Re: jsuis déçu

        Posté par . Évalué à 2.

        heu, ben, désolé, j'ai aucune idée de comment faire ça, mais c'est vrai que ça pourait être pas mal, en plus ça devrais pas être compliqué
        mais bon, en visualisateur, je connait presque que eog qui est vraiment lourd, je trouve

        Si t'en connait un léger, je suis preneur
    • [^] # Re: jsuis déçu

      Posté par (page perso) . Évalué à 3.

      Tu confonds avec Konqueror / Mozilla Firefox là ... :-) Mais ça pourrait se faire plus tard. J'ai pensé à la possibilité d'ajouter des boutons / icônes / zones texte selon le plugin. Un plugin qui lit une image pourra par exemple l'afficher ! Et mieux, on peut imaginer un bouton "convertir" (en PNG/JPG) vu qu'on a toutes les infos : taille, donnée, etc.

      Haypo
  • # avec FUSE ?

    Posté par (page perso) . Évalué à 3.

    Je me demande qi il n'est pas possible den faire un plugin pour FUSE ...
    Ca permetrait par exemple de 'monter' des archives tar.gz/bz2 ou tout format reconnu par le Hachoir.
    Ce serait bien je trouve.

    Et si en, plus cela pouvait être intégré à Nautilus/Konqueror, ce serait le mieux.
    • [^] # Ca existe déjà

      Posté par (page perso) . Évalué à 4.

      Le Hurd :)
    • [^] # Re: avec FUSE ?

      Posté par . Évalué à 5.

      pour le 'montage' gz/bz2, y a deja les kioslaves de konqueror qui bossent pas mal...
      • [^] # montages et URIs

        Posté par . Évalué à 4.

        haha je préparais un commentaire sur l'opposition "montages" et URIs mais en réfléchissant, je me suis rendu compte que c'était pas si différent et que peut-être allait arriver une sorte de "fusion" des 2, c'est vrai que ça pourrait être cool.
        [hs] intéressant de commencer avec une note négative
    • [^] # Re: avec FUSE ?

      Posté par (page perso) . Évalué à 2.

      J'ai noté ça dans la page développement : creuser du côté de FUSE, translators Hurd et KIO slaves serait intéressant. Effectivement, ça existe déjà pour des .tar.gz par exemple. Après c'est une histoire de temps aussi, c'est très intéressant, mais j'ai pas le temps de tout faire (l'envie y est par contre ;-)).

      Haypo
  • # DataWorkshop

    Posté par (page perso) . Évalué à 6.

    Tel un parasite, je profite de ce nouvel article pour rappeler l'existence d'un autre projet qui fonctionne dans la même veine : DataWorkshop[1]. Il ne fonctionne pas exactement comme le hachoir, ce qui le limite dans la taille des fichiers manipulé, mais lui permet de faire de l'édition (modifier les fichiers visualisés).
    Très récemment, il a recut une contribution lui permettant de manipuler des flux MPEG1/2[2].

    Personnellement, je maintiens ce soft car il m'a bien aidé dans le cadre de mon boulot, mais je n'ai pas le temps d'y porter des modifications pour l'améliorer. Si un développeur Java en mal de sujet passe dans le coin... l'avis est lancé.

    [1] https://gna.org/projects/dataworkshop
    [2] http://linuxfr.org/~guyou/20446.html
    • [^] # Re: DataWorkshop les copies d'écran

      Posté par (page perso) . Évalué à 4.

      les screenshots, tu as oublié les screenshots...

      http://dataworkshop.de/screenshots.html

      faut être plus vendeur / précis si tu veux de l'aide ;-)

      et les fonctionnalités de ton projet : http://dataworkshop.de/ (le site de gna! précise une licence GPL v2 et celui-ci freeware... mais bon sans doute un oubli de màj).
    • [^] # Re: DataWorkshop

      Posté par (page perso) . Évalué à 4.

      Oui, j'ai hésité à le mettre dans la niouze, car ce logiciel me ferait presque de l'ombre :-D Par contre, il est depuis longtemps sur le site web du projet Hachoir à côté d'autres logiciels qui ont un peu la même utilité (Game Extractor, aussi écrit en Java, à l'air plutôt chouette).

      DataWorkshop a l'air (j'ai testé vite fait) d'être un bon logiciel. Il a une approche un peu différente, mais semble fonctionnel et abouti (contrairement au Hachoir encore en chantier). Il peut travailler au niveau du bit plus naturellement (adresse avec virgule genre 10,3 => le chiffre après la virgule = le bit). Il a une autre qualité remarquable : on peut utiliser un widget différent selon le type de donnée.

      J'ai écrit un hack dans le Hachoir pour travailler au niveau du bit, et j'ai noté qq. part l'idée de pouvoir utiliser un widget différent. D'ailleurs, j'ai pensé aussi que chaque filtre pourrait ajouter des outils en plus : nouveau onglet, nouveau bouton, etc. Ca serait sympa de pouvoir afficher une couleur, une image, lire un son, etc. :-D (pour rebondir sur un commentaire déposé plus haut)

      Haypo
  • # La jungle des formats

    Posté par . Évalué à 3.

    Je connais (un peu trop à mon gout) deux formats de fichiers très bien documentés. Ce qui est intéressant c'est qu'ils sont super documentés, à tel point que la plupart des outils de conversion le transforment en xml.
    Ce sont les formats ERF et GFF de Bioware (voir http://nwn.bioware.com/developers/ les sections "The Generic File Format (GFF)" et "The Encapsulated Resource Format (ERF)").

    Enfin je dis ça, c'est surtout parce que je travaille un peu sur un éditeur de resources en python, et qu'il serait parfois pratique d'examiner ce que l'on écrit :D

    Si j'ai le temps, je regarderais peut être comment sont faits tes plugins...

Suivre le flux des commentaires

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