Développeur : Sortie de la version 2005-12-28 du Hachoir
Posté par Victor STINNER (page perso, ). Modéré le 29 décembre 2005.
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.
![[fr]](../images/fr.png)
Site web du projet Hachoir (3121 hits)-
Captures d'écran du Hachoir (3367 hits)
-
Partie développeur de site web du Hachoir (375 hits)
> Lire la dépêche (29 commentaires, moyenne: 4,2).
Vous avez demandé le commentaire #665903.
Run by 
Cette page a été générée par Templeet en 0.0488s (dont 0.0048 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Rétro-ingénierie
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
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
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
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