Journal Hachoir version 2005-12-11

Posté par  (site web personnel) .
Étiquettes :
0
11
déc.
2005
Après deux mois de développement, j'ai fini de coder mon idée d'outil permettant de lire n'importe quel flux binaire : le projet "Hachoir". C'est un programme Python offrant une interface GTK2. La liste des formats de fichier supportés est longue: images JPEG, GIF, XCF et PNG ; archive ZIP, GZIP, TAR, BZ2, Debian et Arch ; email ; document PDF ; etc. Il y a également de nombreux types de "flux" supportés : fichier, chaîne de caractère, décompression gzip / bz2 / deflate, décodeur base64, etc.

Les formats sont écrits dans des plugins chargés au lancement (vive Python). Le type MIME du flux est détecté pour le choix du plugin. Là où ça devient intéressant, c'est que les fichiers contenus dans une archive / un email sont à leur tour analysés, etc. On peut donc extraire la miniature d'une image JPEG contenue dans une archive Tar compressée dans un fichier Gzip.

Au fur et à mesure, j'apprend beaucoup de choses sur les formats binaires. Les archives .tar gaspillent beaucoup de place : chaque fichier (avec son entête TAR) est aligné sur 512, et l'archive se termine par un entête nul. Je viens de découvrir qu'une image JPEG embarque une autre image JPEG dans les informations EXIF. Cette image étant en fait une miniature. Le truc marrant est qu'elle n'est pas toujours à jour :-) Le format Arch (utilisé dans les .deb) est en fait un format texte qui embarque des données binaires (comme le PDF d'ailleurs).

Le projet est encore très expérimental. Ne vous étonnez donc pas d'une assertion manquée avec un "backtrace" kilométrique. Il y a également des plugins en développement comme les parseurs RPM, ASN1, ELF et PE. Il est possible d'agir sur l'interprétation pour la modifier, mais c'est à manipuler avec précaution (au pire le programme plante mais jamais il ne touchera à vos fichiers).

Évitez les gros fichiers car tout est chargé en mémoire, et lorsqu'on a une dizaine de niveau de profondeur, ça commence à faire du monde. Mais j'essaye petit à petit de modifier le programme pour faire une analyse "à la volée". Exemple : les données ne sont réellement lues dans le fichier que lorsqu'on y accède.

Informations sur le projet avec lien pour le télécharger :
http://www.haypocalc.com/wiki/Hachoir

Ancien journal présentant le hachoir :
http://linuxfr.org/~haypo/19974.html

---

Le but du projet n'est pas de supporter tous les formats, mais plutôt de faciliter le support de nouveaux formats. J'ai essayé de créer des outils simplifiant au maximum la tâche du développeur. J'ai aussi noté pas mal d'idée sur le site web du Hachoir. Exemples : ajouter un désassembleur, supporter le déchiffrement, écrire une version pour FUSE, KIO, Gnome-VFS et/ou Hurd, etc.

Haypo
  • # Debian?

    Posté par  (site web personnel) . Évalué à 2.

    Bon je veux bien croire que t'y ai passé pas mal de temps donc tu devrais bien connaitre mais le format debian c'est pas 'ar' ?
    Bon sinon bon boulot mais un détail
    Pour que ce soit utilisé en kio ou gnome-vfs le python c'est pas top... à la limite en utilisant la libpython mais c'est pas encore ca...
    • [^] # Re: Debian?

      Posté par  . Évalué à 4.

      T'as des bindings : python-gnome2 pour gnome-vfs (j'ai pas testé), et pykde (intégré dans kdebindings depuis KDE 3.4) avec les pykdeextensions pour simplifier la tâche : http://www.simonzone.com/software/pykdeextensions/
    • [^] # Re: Debian?

      Posté par  (site web personnel) . Évalué à 1.


      Bon je veux bien croire que t'y ai passé pas mal de temps donc tu devrais bien connaitre mais le format debian c'est pas 'ar' ?


      C'est exactement ce qu'il a dit.
      • [^] # Re: Debian?

        Posté par  . Évalué à 0.

        Le format Arch (utilisé dans les .deb) est en fait un format texte (...)
        • [^] # Re: Debian?

          Posté par  (site web personnel) . Évalué à 3.

          Je t'invite a essayer par toi meme de creer une archive .a avec ar. Tu constateras que la reflexion de l'auteur du journal, meme si elle est peut etre mal tournée, est parfaitement juste.
    • [^] # Re: Debian?

      Posté par  (site web personnel) . Évalué à 3.

      Bon je veux bien croire que t'y ai passé pas mal de temps donc tu devrais bien connaitre mais le format debian c'est pas 'ar' ?

      Et bien si :-) J'ai réalisé ça après en voyant que les fichiers .a avaient aussi l'entête "<!arch>". J'ai mis du temps à comprendre que "2" était le contenu d'un fichier et pas juste un entête ;-)

      Pour que ce soit utilisé en kio ou gnome-vfs le python c'est pas top... à la limite en utilisant la libpython mais c'est pas encore ca...

      Comment ça ? Trop lourd/lent ? Ben ça peut toujours s'optimiser par plus tard. Par contre, je sais que pour FUSE, on peut utiliser du Python.

      Haypo
  • # Super projet!

    Posté par  (site web personnel) . Évalué à 6.

    Pour avoir passé 4 ans dans le développage de protocole de com', ton projet me fait littéralement baver!

    Je pense que ceux qui font du revers engeenring doivent tous se dire:
    "C'est le truc qu'il me faut s'il y avait":

    - la gestion d'enums!
    - ajout de règles pour detecter certaines choises (lrc, crc, md4/5 etc.)
    - passer des bouts dans des moulettes (gunzip etc.)
    - idem mais uniquement pour l'affichage (exemple : transformer un timestamp en date jour heur minute seconde)
    - etc.

    Je suis prêt à parier que si ton projet évolue dans ce sens, il sera The outil pour le reverse engeenring!
    • [^] # Re: Super projet!

      Posté par  (site web personnel) . Évalué à 2.

      Pour avoir passé 4 ans dans le développage de protocole de com', ton projet me fait littéralement baver!

      Ah ouais ?

      Je pense que ceux qui font du revers engeenring doivent tous se dire: "C'est le truc qu'il me faut s'il y avait":

      Oui, je devrais proposer ça aux gens qui en ont besoin. Aux gens de VLC ou d'OpenOffice par exemple.

      - la gestion d'enums!
      - ajout de règles pour detecter certaines choises (lrc, crc, md4/5 etc.)
      - passer des bouts dans des moulettes (gunzip etc.)
      - idem mais uniquement pour l'affichage (exemple : transformer un timestamp en date jour heur minute seconde)
      - etc.

      Python a été d'une grande aide en fait. On peut faire un peu tout et n'importe quoi ! Ma fierté, c'est le "post process", c-à-d faire une traitement juste après avoir lu l'information pour transformer l'affichage (comme tu le disais, afficher un timestamp Unix).

      Haypo
  • # PK2, PK3

    Posté par  . Évalué à 3.

    Dans la liste "à développer" sur le site, je vois :
    # Quake pk2 et pk3 (pk1 existe?)


    Pour le pk2 je suis pas sur mais le pk3 c'est du zip à 100% :)
  • # hachoir, MPEG1/2

    Posté par  . Évalué à 3.

    salut,
    voici de quoi commencer un travail sur le format MPEG :
    http://homepage.mac.com/rnc/EditMpegHeaderIFO.html

    ceci detaile les entêtes.
    • [^] # Re: hachoir, MPEG1/2

      Posté par  (site web personnel) . Évalué à 2.

      Hum, le format détaille sur cette page ne correspond pas aux quelques fichiers MPEG que j'ai sur mon disque dur :-( J'ai trouvé une autre source d'information : le projet ffmpeg, reconnu pour être rapide et supporter de nombreux formats vidéos et audios (je vois AVI, ASF, Matroska, MPEG, etc.).

      Je viens d'écrire un parseur pour le conteneur vidéo AVI à l'instant. Il arrive à décoder les quelques AVI que j'ai sur mon disque. J'ai trouvé où est stocké les informations sur la vidéo et sur le son. Tiens, encore une fois, il y a du "JUNK", zone du fichier qui ne sert à rien. Enfin, ça doit servir à aligner les données pour que la vidéo commence à la position 4096, mais quand même ... Mplayer (mencoder) la remplit avec la chaîne "[=Mplayer junk data! =]" répétée pour remplir cet espace.

      Haypo
      • [^] # Re: hachoir, MPEG1/2

        Posté par  . Évalué à 2.

        ha... j'ai pas verifié. en fait j'ai trouvé ceci et j'ai tout de suite pensé a ton projet.
        et oui, tu as des rabatteurs... :)

        Bonne continuation.
  • # DataWorkshop

    Posté par  (site web personnel) . Évalué à 2.

    Dans l'esprit "Donner une représentation intelligible d'un fichier binaire", il y a aussi DataWorkshop.
    Personellement, je le trouve très puissant.
    Il est écrit en Java, ce qui rend son look austère.

    HomePage : http://dataworkshop.de/
    ProjectPage : http://gna.org/projects/dataworkshop
    • [^] # Re: DataWorkshop

      Posté par  (site web personnel) . Évalué à 4.

      Très intéressant ! Le projet ressemble au mien, et j'ai l'impression que son auteur est même allé plus loin :
      - On peut avoir plusieurs vues différentes des données
      - On peut éditer les données
      - Apparemment, l'outil est capable de travailler au niveau du bit alors que j'ai choisi de travail uniquement au niveau de l'octet. À la limite, cette tache sera effectuée par un autre outil interne

      Haypo
      • [^] # Re: DataWorkshop

        Posté par  . Évalué à 2.

        J'espere que ca ne t'incitera pas a ralentir ou arreter, mais plutot que ca te donnera des idées.

        en effet, j'ai pas envie d'installer java pour faire tourner le bidule.
        • [^] # Re: DataWorkshop

          Posté par  (site web personnel) . Évalué à 3.

          :-)

          Mais nan. Je vais lui "voler" des idées. Je trouve sa manière dont il affiche les objets est très jolie par exemple. Et puis, il offre des tableaux associant des valeurs à une chaîne de caractère (genre d'ENUM) qu'on peut éditer. Bref, des choses sympas.

          Haypo
      • [^] # Re: DataWorkshop

        Posté par  (site web personnel) . Évalué à 1.

        Pour info, je m'en sert pour le boulot (édition de fichiers de télémesure).

        Le coup de la précision au niveau du bit est quasi indispensable dans mon boulot.

        Le fait de pouvoir éditer les valeurs (et pas simplement les consulter) est tout simplement formidable.

        Par contre, je trouve que l'IHM n'est pas des plus pratique à prendre en main. Si j'avais du temps à y consacrer, ce serai là ou il faudrait bosser.
  • # miniature EXXXIF...

    Posté par  . Évalué à 2.

    Vu le sourire coquin de ton smiley lorque tu parle de miniature pas à jour dans une image jpeg, je suppose que tu connais cette adresse:

    http://wizbangblog.com/archives/000491.php

    d'autres indiscretions, un peu moins croustillantes:

    http://blogs.23.nu/disLEXia/stories/5751/
    • [^] # Re: miniature EXXXIF...

      Posté par  (site web personnel) . Évalué à 2.

      Euh ... il est pas coquin mais jovial le sourire. Je pensais à une photo tout à fait normale :
      http://www.wormux.org/wiki/Image:gentildemon-roller.jpg.php

      Mais apparement le phénomène est connu vu les liens donnés ...

      Sinon, un peu dans le même domaire, j'ai discuté avec l'auteur de DHIS. C'est un programme qui cache des informations dans des fichiers ELF de manière distribuée. Je lui ai suggeré d'aller voir du côté des fichiers TAR, PNG et GZIP qui contiennent des espaces qui peuvent être exploités dans les fichiers (ex. pour gzip: créer un champ commentaire).
      http://dhis.devhell.org/

      Haypo
  • # Hachoir en tant qu'outil de "Forensics"

    Posté par  (site web personnel) . Évalué à 2.

    Je suis en train de bosser sur le format ext2. Je me dis que si j'arrive à rendre le code pas trop lent, le Hachoir pourrait servir d'outil de forensics (y'a un terme français pour ça ?).

    Avec ses outils de détection de type MIME et les outils existants et futurs (déchiffrement à la volée et gestion propre des erreurs), ça pourrait donner un bon outil.

    Haypo
    • [^] # Re: Hachoir en tant qu'outil de "Forensics"

      Posté par  . Évalué à 3.

      outil de forensics (y'a un terme français pour ça ?).

      Oui, dans ce sens : autopsie (surtout dans une utilisation post mortem), diagnostic, étude.

      (Au départ, forensic vient de forum : qui relève de l'argumentation, du débat ; d'où « qui relève des débats en cour, en justice », d'où forensic medicine, « médecine légale », mais aussi forensics, « criminologie », étude des faits criminels, en général a posteriori.)

Suivre le flux des commentaires

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