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

Posté par (page perso) . Modéré par Mouns.
Tags :
0
19
août
2006
Python
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 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 :
  • d'être packagé (Debian, Gentoo, etc.) ;
  • d'une interface graphique (Gtk ou Qt, pygtk/pyqt) ;
  • de meilleurs parseurs et de plus de parseurs.


Contactez nous si vous êtes intéressés
  • # Souvenir...

    Posté par . É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 (page perso) . É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 . É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.
    • [^] # Re: Package

      Posté par . Évalué à 1.

      J'oubliais ajoute la définition du mot hachoir, et sa phonétique sur ta page
      • [^] # Re: Package

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

        ... sa phonétique...

        Je me demande bien ce que ça peut donner en anglais, espagnol, allemand ou portugais ;-)
        Après tout, nous bouffons bien du grand-breton en quantité... Il faudra bien qu'ils ajoutent hachoir à mayonnaise et rendez-vous :-)
    • [^] # lapin compris

      Posté par . Évalué à 5.

      (trop jeune pour IT ...)
      IT n'est pas geek

      De quoi s'agit-il ? Je parle de "IT" (et je suis sérieux).

      Merci.
      • [^] # Re: lapin compris

        Posté par . Évalué à 2.

        C'est le service informatique qui ne fait rien pour d'aider, et utilise en production une distribution d'il y a 5 ans (ou pire windows XP, ou encore pire 95, ou ... MS DOS 6) parce qu'ils n'ont pas les budgets pour suivre la cadence.
    • [^] # Re: Package

      Posté par . Évalué à 10.

      Salvaire, avant de donner des leçons regarde comment les autres packages python sont packagés.
      Tes remarques montrent juste que tu as une méconnaissance de la façon de faire pour les packages python AMHHA.
      #!/usr/bin/env n'est certes pas portable pour windows, mais sur cette plateforme #! est considéré comme un commentaire.
      De plus PYTHONPATH n'a pas à être spécifié par le programme, c'est à l'utilisateur s'il l'installe dans un répertoire non destiné à cet effet de le rajouter à PYTHONPATH.
      Finalement, tu trouves à redire à installer un package en root.
      Mais pourtant sur ta distribution c'est nécessaire et tu ne trouves aucun problème à ça...
      De plus si l'utilisateur n'a pas les droits root il peut directement utiliser le programme sans l'installer dans un répertoire particulier.
      Dire que SVN est trop jeune, c'est de l'abus.
      Sur les nouveaux projets, je pense que SVN est largement devant CVS...
      Finalement, dans toutes les distributions GNU/Linux, et même sur *BSD, ou Windows, les packages python ne s'installent pas dans /*/lib mais dans site-packages/ qui est un répertoire à l'intérieur de l'installation Python.
      Par ailleurs il est vrai que certaines applications le font quand même et modifient le PYTHONPATH mais c'est uniquement dans le cas d'applications qui ne cherchent pas à être utilisé en tant que module python i.e. à être réutilisé dans du code python d'un autre programme.
      Or Hachoir est aussi un framework qui peut être réutilisé dans d'autres applications, notamment son extracteur de métadonnées.
      • [^] # Re: Package

        Posté par . Évalué à 5.


        Finalement, tu trouves à redire à installer un package en root.
        Mais pourtant sur ta distribution c'est nécessaire et tu ne trouves aucun problème à ça...
        De plus si l'utilisateur n'a pas les droits root il peut directement utiliser le programme sans l'installer dans un répertoire particulier.

        je ne connais pas trop les paquetages python etc...
        Mais je sais que pour tout ce qui est "à compiler" le fait de pouvoir spécifier le prefix (donc en étant utilisateur lors de l'installation), de pouvoir compiler en dehors du répertoire de sources etc ... est un grand plus!

        L'utilité est par exemple quand tu es sur un ordi ou tu n'as pas les droits root (ordi du boulot, ou portable prété par le boulot ou tu n'as pas les droits root , ou ...)
        pouvoir tout compiler dans (par exemple bien entendu) ~/obj_$ARCH/nom_apps et tout installer sur ~/$ARCH/{bin,lib,include,...} est trés appréciable.
        Ca évite entre autre de se farcir de rajouter un path à chaque fois dans son .bashrc ou autre, de savoir où sont les sources (dans ~/src :-D ), où faire les make, etc...
        • [^] # Re: Package

          Posté par . Évalué à 2.

          D'une part, tu n'as pas besoin de compilation mis à part la génération des pyc, et les avoir à un endroit ou un autre, franchement on s'en tappe.

          Je comprends ton problème, mais ce n'est pas tout simplement la façon standard de faire Python. En effet on peut pas faire du specific UNIX, Python est un langage, une VM, et une bibliothèque standard multiplateforme. La règle sous unix pour les bibliothèques externes c'est /usr/lib/pythonXX/site-packages/. Pour les binaires c'est comme le reste des applications.

          Si tu veux une install custom, rien ne t'empêche de le faire mais dans ce cas je vois pas l'intérêt d'utiliser un package. Tu prends le source, tu le décompresses, et tu l'utilises. Si tu veux utiliser un package tout de même avec une procédure dans laquelle tu spécifies le path, amha ça crééra plus de problèmes que de solution. Le développeur devra se soucier des divers problèmes ésotériques que ça peut entrainer. Sans compter qu'utiliser un package pour spécifier soit même les PATH de destination à la main c'est franchement superflu... Autant passer directement par le source.
    • [^] # Re: Package

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

      Raaah, ça m'énerve de lire ça.

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

      Il n'y a pas pire invention que autotools pour torturer les développeurs. Aussi bien les fichiers ".ac" et ".am" que le résultat (script configure et Makefile) sont imbitables ! De la grosse saloperie.

      Heureusement, en Python on n'a pas cette chose HORRIBLE : chaque programme/bibliothèque (bien foutue) a son script "setup.py" qui fait en quelques lignes tout ce qu'on peut attendre d'un script ayant ce nom, et bien plus encore (ex: générer un installateur Windows, si le bon paquet est installé).

      svn n'est pas aussi courant que cvs (trop jeune pour IT ...)

      Je sais pas qui est IT, mais euh c'est pas pour dire mais cvs est VRAIMENT vieux et dépassé. La majorité des projets majeurs utilisent SubVersion. D'ailleurs, svn n'est absolument pas nécessaire pour installer Hachoir : un .tar.gz existe (cherche un peu ...) et un .egg existe.

      j'aime pas les "rm -rf $hachoir" dans ton script ...

      C'est pour ça que je cherche des packageurs. Et d'ailleurs, tu as ma copié/collé la commande.

      * 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)


      setup.py peut installer Hachoir dans $HOME/<où tu veux>

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

      Ceci concerne le 2e mode d'installation (quick_install.sh).

      On peut installer Hachoir :
      * à partir du .tar.gz avec setup.py (pas besoin d'être root)
      * à partir du .egg (pas besoin d'être root, mais il faut easy_install)
      * avec quick_install.sh (il faut svn, càd ne pas vivre en 1990)

      IT n'est pas geek ...

      Hum ?

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

      Cela fonction sur UNIX et *BSD. Au pire il faut taper "python2.4 script" (hou là là, c'est dur !).

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

      Non, Hachoir doit être installé pour être utilisé... ou alors les gens qui ne veulent pas l'installer peuvent modifier eux-même leur PYTHONPATH.

      Si tu veux je peux t'envoyer un exemple avec essentiellement du Perl,

      QUOI ?
      --
      La prochaine fois, renseigne _un peu mieux_ avant de critiquer stp. Par contre, les contributions nous font toujours plaisir.

      Haypo
      • [^] # Re: Package

        Posté par . Évalué à 0.

        Raaah, ça m'énerve de lire ça.
        Moi aussi!

        Dire que j'avais commencé par un commentaire élogieux ...

        Je veux tester ton application, que je trouve intéressante, donc je vais sur ton site via le premier lien. J'ai pas trouvé une seule archive tar. Mais une méthode qui me demande d'exécuter sous root un programme -inconnu-, et une autre qui requière de compiler svn en local sur toute les distributions installées en entreprise (IT = service informatique) qui n'ont pas encore svn. Cvs est/était encore majoritairement le standard quoi que tu pense. Qu'est que ça coûte de mettre un tar.gz comme tous le monde (pour la première page de LinuxFr))?

        python setup.py
        Error: You need setuptools Python package!

        It's very easy to install it, you type (as root on Linux):
        python ez_setup.py
        (hachoir has it's copy)
        je lis bien: as root ...

        quick_install.sh:
        echo "Now set PYTHONPATH using:"
        echo " export PYTHONPATH=$HACHOIRDIR"
        Autotools est certes une belle saloperie. Mais c'est inutile, tu peux adapter les scripts durant l'installation une fois pour toute. Qu'est ce que ça coûte?

        Par contre, les contributions nous font toujours plaisir.
        Mais pas les commentaires. Faudra changer quand tu voudras gagner ta vie. Parce que: "j'ai programmé cela pour pas un euro, je n'accepte que les commentaires élogieux, et si ça vous plais pas allez vous faire voir." C'est pas la bonne méthode pour manger à sa faim! Le marketing ça sert! (Par expérience, il y a pleins de contributions utiles dans le libre qui traînent à l'abandon, faute de volonté du/des mainteneur(s) ... si si ça existe)

        Tu fait comme tu veux. Mais si une entreprise (peut être une source de revenu qui sait?) veut tester ton programme. Ils vont essayer de l'installer en user local: "tar -xzf hashoir.tar.gz; configure --prefix=...; hashoir-...". Pas avec un package, et pas sous root. Libre à toi de choisir la méthode pour le "configure" qui va préparer le terrain pour la première et définitive impression.

        Désolé de t'avoir énervé!
        • [^] # Re: Package

          Posté par . Évalué à 3.

          Je ne me suis pas intéressé au packaging, mais voici quelques éléments qui devraient t'éclairer :

          1. .tar.gz

          Je cite http://hachoir.org/wiki/HachoirYield :
          See also

          * informations about Hachoir in CheeseShop: You can find there .egg file and .tar.gz file
          Ok, ça saute pas aux yeux. On admet qu'il faille réorganiser un minimum le wiki.

          2. not as root

          Et l'option --help ??
          $ python ez_setup.py --help

          =>

          $ mkdir -p /tmp/usr/lib/python2.4/site-packages
          $ export PYTHONPATH=/tmp/usr/lib/python2.4/site-packages
          $ python2.4 hachoir/ez_setup.py --prefix=/tmp/usr
          $ /tmp/usr/bin/easy_install --prefix=/tmp/usr -U hachoir
          et vala, c'est installé

          3. quick_install

          Bon ben euh... comme son nom l'indique : ... and dirty
          Ca a d'autres avantages que celui de faire une install toute propre. Il a notamment été décidé d'utiliser la commande 'checkout' de subversion plutôt que 'export' pour télécharger hachoir :
          * Il y a tout les données de svn (répertoire .svn) et en particulier des fichiers en lecture seule, ce qui explique le 'rm -rf'.
          * C'est plutôt orienté beta-testeur : par exemple, si quelqu'un rapporte un bug sur un chan et si un dev peut corriger rapidement, il suffit de lui répondre 'svn up'.
          * ... ou développeur en déplacement : ça permet de réinstaller rapidement une copie de travail et toutes les librairies rarement installées comme python-urwid.


          Quant à svn, désolé, mais je considère qu'il faut aller de l'avant en info. Il faut bien que quelqu'un se dévoue pour utiliser un nouvel outil. Oh et puis de toute façon, comme ça a déjà été dit, svn est vraiment courant maintenant.
          Tu as de la chance pour le .tar.gz, tu as échappé au .cpio.7z (oui, c'est que j'utilise personnellement) :D
    • [^] # Re: Package

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

      Nouvelle réponse après respiré bien profondément.

      J'ai rédigé une documentation qui explique comment installer Hachoir. Il y a 5 manières différentes : easy_install, quick_install.sh, tarball, Gentoo & Arch ... bon disons 3 manières différente si on exclut les paquets.
      http://hachoir.org/wiki/Install

      Aucune des 3 méthodes ne demande les droits root. Par contre, mieux vaut avoir le bon module (setuptools).

      Hum, il y a encore une méthode qui n'est pas détaillée... (je le ferai plus tard) et c'est pourtant celle que j'utilise quotidiennement. Enfin, ce n'est pas une « installation », mais une bidouille pour éviter l'installation.

      => Modifier PYTHONPATH, il faut le faire pointer sur le dossier hachoir (celui qui contient le sous-dossier hachoir, et non pas le sous-dossier directement). Genre : « export PYTHONPATH=$HOME/hachoir ».
      --
      Au sujet des centres informatiques pas très ouverts, genre « on utilise des versions stables et point barre », je dirai que sous Unix/BSD on peut se *débrouiller* tant qu'on a de l'espace disque. Il faut jouer avec LD_LIBRARY_PATH, les "--prefix" & ci. C'est très contraignant, mais ça dépanne. Pendant longtemps j'ai du utiliser des "dpkg -x ~/pouet/ paquet.deb" avec des paquets venus de (Debian) backports.org pour pouvoir utiliser autre chose que le strict minimum installé de base.

      L'idéal étant d'arriver à faire comprendre le besoin de tel bibliothèque ou tel programme pour éviter quelques dpkg -x quotidient :-)

      Haypo
      • [^] # Re: Package

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

        Après de très nombreux tests dans des configurations différentes (avant/sans setuptools, avec/sans urwid) et un patch sur setup.py, j'ai réussi à installer Hachoir sans mon $HOME : sans être root (IT va être heureux) et sans extension Python (sans setuptools).

        Comme julien n'était pas trop chaud pour sortir 3 versions en 2 jours, voici une version "0.5.2-batarde" :
        http://www.haypocalc.com/tmp/hachoir/hachoir-0.5.2-batarde.t(...)

        Et l'½uf batard :
        http://www.haypocalc.com/tmp/hachoir/hachoir-0.5.2_batarde-p(...)

        $ md5sum *
        d30c4cbce43cd75c5150ccf7e38b6aaf hachoir-0.5.2_batarde-py2.4.egg
        77af3c33c67417102c5a22c35a882549 hachoir-0.5.2-batarde.tar.gz

        Le principal changement est un tout nouveau setup.py qui fonctionne sans setuptools (et qui peut être lancé de n'importe où : mais attention, il crée des dossiers dist et build).

        Haypo
        • [^] # Re: Package

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

          Après avoir lutté trois jours avec un bug dans Python :
          http://sourceforge.net/tracker/index.php?func=detail&aid(...)

          J'ai enfin réussi à sortir la version 0.5.2 :
          http://cheeseshop.python.org/pypi/hachoir


          Version 0.5.2 changelog

          Better setup.py script: can use distutils instead of setuptools, and can be run from any directory
          All scripts can be used out-of-the-box (don't need PYTHONPATH)
          Add iTunesDB parser (eg. used for iPod playlist)
          Fix Quicktime movie parser (buggy validate() function)


          Haypo
          • [^] # Re: Package

            Posté par . Évalué à 3.

            La version installée sans setuptools diffère de la précédente par l'absence d'un répertoire /usr/lib/python2.4/site-packages/hachoir-0.5.2-py2.4.egg-info . Je ne pense pas dire d'anneries en le considérant comme inutile à l'utilisation de hachoir. Mais en considérant un soft, appelons le dwarf, qui aurait besoin d'une bonne hache et qui utiliserait les setuptools pour son installation. Est-ce qu'il n'aura pas de problème pour détecter la présence ou non de hachoir?

            Autre chôse, dans le fichier INSTALL à propos de la désinstallation:
            <$ sudo rm /usr/bin/hachoir
            >$ sudo rm /usr/bin/hachoir-*
            me semble plus approprié. C'est du détail, mais bon tant que j'y suis. :)

            En tout cas, on ne peut pas te reprocher de ne pas tenir compte des retours/réclamations des utilisateurs (voir mini-troll plus haut :p).
            • [^] # Re: Package

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

              La version installée sans setuptools diffère de la précédente par l'absence d'un répertoire (...)/hachoir-0.5.2-py2.4.egg-info

              Normal, les ½ufs ont été introduit avec setuptools. Pas de setuptools, pas d'½uf. Le script setup.py du Hachoir tente d'utiliser setuptools et s'il ne le trouve pas, il se rabat sur la version « bas de gamme » (distutils, qui a la qualité d'être toujours dispo').

              Autre chôse, dans le fichier INSTALL à propos de la désinstallation:

              Ah mince, j'ai oublié de mettre à jour ce fichier. Il faut se référer à la page web. Je voudrais bien pouvoir synchroniser les deux via une commande ...

              En tout cas, on ne peut pas te reprocher de ne pas tenir compte des retours/réclamations des utilisateurs (voir mini-troll plus haut :p)

              Les retours font toujours plaisir. J'ai encore corrigé plein de bugs, mais ça attendra une version 0.6 je pense car des changements d'API ont été opérés (correction de l'API des chaînes de caractères).

              Haypo
  • # Compléments

    Posté par . É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 . É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?
    • [^] # Re: problème sous Arch x86_64

      Posté par . Évalué à 5.

      Tu peux essayer le dernier patch : http://hachoir.org/changeset/727 ?
      Au format diff : http://hachoir.org/changeset/727?format=diff
      Ou télécharger depuis le dépôt subversion : svn co svn://hachoir.org/hachoir/hachoir/trunk hachoir

      Si ça ne marche toujours pas, annule le commit 690 : http://hachoir.org/changeset/690
      (attention à la récente réorganisation des fichiers sources)
      • [^] # Re: problème sous Arch x86_64

        Posté par . Évalué à 4.

        Ok, ça marche avec la révision 727. Tout les tests passent avec la commande make test et mes essais rapides de hachoir-urwid passent impec. J'ai donc mis a jour le PKGBUILD pour qu'il utilise cette révision. :)

        Merci pour la réactivité, il est extra cet outil !
    • [^] # Re: problème sous Arch x86_64

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

      J'ai ajouté cette assertion 48h avant la sortie de la version 0.5... et je pensais aux archi' 64 bits en l'écrivant :-) C'était une sortie de "TODO" :-) Cela confirme mon doute : un "long" n'a pas forcément 32 bits avec l'outil struct de Python.

      Si "make test" passe, alors tu peux dire que tout marche :-) La documentation est testée, quelques tests unitaires, un jeu de fichier de tests et le packaging (setuptools).

      Haypo
    • [^] # Hop, version 0.5.1

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

      Pour corriger ce bug et le bug du parseur FAT, voici la version 0.5.1 :
      http://cheeseshop.python.org/pypi/hachoir

      Haypo
      • [^] # Re: Hop, version 0.5.1

        Posté par . Évalué à 2.

        Et un nouveau PKGBUILD: http://bursab.free.fr/pkgs/hachoir/PKGBUILD Cette fois basée sur le tar.gz (maintenant que je sais où le trouver :p) plutôt que sur le svn. C'est toujours une dépendance en moins.

        Et toujours celui basé sur le svn pour ceux qui veulent avoir la dernière version facilement: http://bursab.free.fr/pkgs/hachoir-svn/PKGBUILD
        • [^] # Re: Hop, version 0.5.1

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

          http://aur.archlinux.org/packages.php?do_Details=1&ID=64(...)

          GnunuX a préparé un paquet Arch. Si arno et GnunuX ne sont pas la même personne, ça serait bien que vous travailliez ensemble :-)

          Des paquets Arch et Gentoo : vous nous gattez :-) Merci. J'attend les paquets Debian et Ubuntu avec impatience.

          Haypo
          • [^] # Re: Hop, version 0.5.1

            Posté par . Évalué à 2.

            Les paquets debian arrivent normallement aujourd'hui (en fin de journée) ou demain.

            Pour le moment il n'y auras que debian unstable (portable a priori sur sid vu que la dependance et sarge, mais a vérifier) vu que la dependance seras python2.4

            Il faudras aussi tester pour *ubuntu.
            • [^] # Re: Hop, version 0.5.1

              Posté par . Évalué à 1.

              Dans la distrib officielle ? (J'ai vu passer un ITP sur hachoir juste avant que j'en fasse un)

              Il faudra qu'ils soient validés par ftpmaster, ce qui peut prendre quelques jours (voire mois) en fonction de leur temps libre. Il y a moyen de voir les paquets sur un site perso en attendant ?
              • [^] # Re: Hop, version 0.5.1

                Posté par . Évalué à 2.

                Je vais commencer par les mettre sur un site perso, et je pense commencer avec la 0.5.2_batarde re estampillée (pour le suivi des maj) en 0.5.1.1

                Le choix de la version batarde est de supprimer une dépendance.

                D'ailleurs je commence maintenant, et si les auteurs ont un problème avec, qu'ils me le fasse savoir.
                • [^] # Re: Hop, version 0.5.1

                  Posté par . Évalué à 1.

                  J'ai déjà plusieurs paquets python dans Debian (mercurial, tailor, commit-tool). Si tu as besoin d'un coup de main, fait moi signe.
                  • [^] # Re: Hop, version 0.5.1

                    Posté par . Évalué à 2.

                    Déjà, oui je veux bien un coup de main, car j'ai fait le paquet, mais il est pas "propre" selon moi.

                    L'installe se passe très bien comme il faut, mais la desinstallation, j'ai été obligé de mettre un prerem qui supprime comme il faut (sinon le uninstall ne vire pas les libs / scripts)


                    Ensuite, mon premier paquet debian est créé python-hachoir (le paquet regroupe TOUT hachoir, mais je pense dans un avenir proche le séparer en plusieurs paquets)

                    Le dépot (qui génère une erreur, je pense car je n'ai pas signé le paquet) est :

                    deb http://hachoir.demongeot.biz/debian ./


                    Il n'y as qu'une version unstable pour le moment.
                    Le paquet est la version 0.5.2_batarde rebaptisée en 0.5.1.1 (setuptools en moins comme dépendance)

                    J'attends vos commentaires ;)
  • # Packaging

    Posté par . É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 ;)
    • [^] # Re: Packaging

      Posté par . Évalué à 3.

      > Gentoo (quand j'aurais réinstallé un petit pc sous gentoo)

      Tu peux virer celui là de ta TODO, je viens de m'y coller :
      https://bugs.gentoo.org/show_bug.cgi?id=144532
      (par contre, j'ai rien contre les relectures / tests / critiques, évidemment...)
      • [^] # Re: Packaging

        Posté par . Évalué à 2.

        > Tu peux virer celui là de ta TODO, je viens de m'y coller :

        Et tu viens par la même occasion de me virer une raison d'installer Gentoo par la même occasion. Enfin, je vais quand même réinstaller une gentoo ;)

Suivre le flux des commentaires

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