Journal D’une image nommée .iso à un premier probe en Haskell

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
15
3
sept.
2026

Je travaille depuis quelque temps sur Hexegesis, un projet expérimental écrit en Haskell dont l’objectif est de comprendre et, à terme, de transformer les formats binaires rencontrés dans les jeux FromSoftware sur PlayStation 3. Le premier corpus étudié est la version PlayStation 3 originale de Demon’s Souls.

En cherchant de la documentation, j’ai constaté que les ressources techniques de qualité consacrées aux formats binaires, à la rétro-ingénierie et au modding sont très majoritairement rédigées en anglais. Je souhaite donc construire la ressource francophone que j’aurais aimé trouver : un texte accessible à une personne débutante, mais écrit avec un vocabulaire exact, sans remplacer les véritables concepts techniques par des approximations.

Je viens de publier le premier article de cette série sur DEV Community :

D’une image nommée .iso à un premier probe en Haskell

L’article part d’un fichier dont le nom se termine par .iso, sans considérer cette extension comme une preuve de son format. Nous observons directement ses octets avec des lectures xxd précisément bornées, puis nous reconstruisons progressivement plusieurs informations :

  • l’en-tête du Primary Volume Descriptor défini par ISO 9660 ;
  • l’identifiant du volume ;
  • le nombre de blocs logiques et la taille de chacun d’eux, enregistrés selon les deux ordres d’octets ;
  • la séquence des descripteurs de volume et son terminateur ;
  • le passage d’un Supplementary Volume Descriptor générique à la reconnaissance limitée d’un marqueur Joliet ;
  • le marqueur PlayStation3 et l’identifiant produit observés dans la zone système du disque.

Les commandes sont accompagnées de leurs sorties réelles. L’idée n’est pas seulement de donner les valeurs obtenues sur mon image, mais de montrer où elles se trouvent et comment les reconstruire : un lecteur qui observe d’autres octets au même emplacement doit pouvoir appliquer le même raisonnement à son propre exemplaire.

La seconde partie reproduit cette enquête directement dans GHCi. Le prototype Haskell effectue des lectures en mode lecture seule, contrôle leur longueur, décode les entiers little-endian et big-endian, borne le parcours des descripteurs et affiche finalement quatre informations :

ps3.product-id=BLES-00932
iso9660.volume-id=PS3VOLUME
iso9660.logical-block-size=2048
joliet.level=1

Ce résultat reste volontairement modeste. Le programme ne parcourt encore aucun répertoire, n’extrait aucun fichier, ne déchiffre aucune donnée et ne prétend pas valider intégralement ISO 9660 ou Joliet. Plusieurs observations intéressantes sont laissées hors du code lorsqu’elles ne servent pas ce résultat concret.

Je publie d’abord cette série, article après article, sur DEV Community afin d’éprouver la progression, le vocabulaire et les exemples auprès de lecteurs réels. Mon objectif à plus long terme est de reprendre l’ensemble de ces articles, de corriger ce qui doit l’être et d’en faire un cours complet et cohérent en français, que je souhaiterais ensuite publier sur Zeste de Savoir.

C’est précisément pour cela que les retours m’intéressent dès maintenant. Je serais notamment preneur de remarques sur les points suivants :

  • la progression reste-t-elle accessible à quelqu’un qui découvre les formats binaires ?
  • le vocabulaire est-il suffisamment précis sans devenir inutilement opaque ?
  • les sorties des commandes permettent-elles réellement de refaire le raisonnement ?
  • la partie Haskell avance-t-elle au bon rythme ?
  • certaines affirmations relatives à ISO 9660, Joliet ou aux images de disque PlayStation 3 devraient-elles être corrigées ou mieux nuancées ?
  • quels sujets devraient absolument figurer dans la suite ou dans le futur cours ?

Le dépôt du projet et les notes de recherche sont également disponibles ici :

Hexegesis sur GitHub

Merci d’avance à celles et ceux qui prendront le temps de lire, de relever une imprécision ou simplement de décrire l’endroit où ils ont perdu le fil. Pour cette série, un retour sur la manière d’apprendre compte autant qu’une correction technique.

  • # Correction du lien

    Posté par  (site web personnel) . Évalué à 2 (+1/-0).

    Évidemment, le lien vers l'article n'était pas le bon :-)

  • # ok, mais pourquoi ISO

    Posté par  . Évalué à 4 (+3/-1).

    Je souhaite donc construire la ressource francophone que j’aurais aimé trouver : un texte accessible à une personne débutante, mais écrit avec un vocabulaire exact, sans remplacer les véritables concepts techniques par des approximations.

    ok avec l'idée, je trouve ça bien. Mais j'ouvre ton github: "Hexegesis is an experimental Haskell toolkit for describing, (…)" C'est en anglais?

    Ensuite, c'est bien mais c'est vaste, l'article présente la différence extension/type de fichier (c'est bien), pour expliquer les MAGIC, puis le parsing ISO, puis enfin arriver à la spécificité playstation3.
    C'est beaucoup d'infos. Je pense que quelqu'un qui veut décoder des CD PS3 connait déjà toute la base (iso, extension, etc..) et quelqu'un qui s'intéresse au formats de fichiers au sens large va être perdu car tu vas beaucoup trop loin.. Le découper en petite parties aurait permis (en tout cas à moi) d'accéder à ce qui m'intéresse + vite.

    Après, je suis perdu parceque haskell j'y connais rien :D

    Ensuite j'aime bien les commandes shells, mais comme on a pas l'ISO source, on peut pas reproduire; et j'aime bien dans les exemples pouvoir les rejouer à l'identique, modifier une valeur, etc… sans l'ISO, pas moyen. Et comme je pense qu'il n'y a pas moyen de partager l'ISO de demon's soul, ça va être compliqué :-/

    En fait je crois que c'est ça qui me choque ce mélange "playstation 3/demon's soul -> format binaires, reverse, retroengineering, retrogaming etc.." et "analyse d'un format de fichier et programmation haskell". Ca va pas bien ensemble je dirais :-(

    en tout cas ça fait plaisir de voir des recherches bien documentées comme ça

    • [^] # Re: ok, mais pourquoi ISO

      Posté par  (Mastodon) . Évalué à 4 (+1/-0).

      Et comme je pense qu'il n'y a pas moyen de partager l'ISO de demon's soul, ça va être compliqué :-/

      Honnêtement pour une approche didactique il faut absolument partir d'un jeu/app qui est diffusé librement comme un homebrew. Et un qui n'utilise pas des marques enregistrées (Sonic, Mario) ou qui ne soit pas un port d'un jeu proprio avec des assets non recréés.

      • [^] # Re: ok, mais pourquoi ISO

        Posté par  (site web personnel) . Évalué à 2 (+1/-0).

        Je vais probablement alterner entre des articles plus théoriques, fondés sur des données libres ou synthétiques que chacun pourra manipuler, et des études de cas plus courtes sur mes propres images de jeux FromSoftware, que les personnes intéressées pourront reproduire avec leurs propres exemplaires.

    • [^] # Re: ok, mais pourquoi ISO

      Posté par  (site web personnel) . Évalué à 5 (+4/-0).

      Merci beaucoup d’avoir pris le temps de lire l’article et d’écrire un retour aussi détaillé. C’est exactement pour recevoir ce genre de remarques que je l’ai publié, donc ça me fait vraiment plaisir. :-)

      Tu as tout à fait raison pour le dépôt GitHub en anglais. Jusqu’à la publication, je n’avais pas encore complètement tranché entre l’anglais, pour toucher davantage de monde, et le français, qui correspond beaucoup mieux à ce que j’ai envie de faire. C’est finalement en terminant l’article que j’ai fait mon choix : la série sera en français.

      Je lis l’anglais technique sans problème, mais je préfère lire et écrire en français. J’ai aussi envie de travailler mon style et de montrer qu’on peut produire de la documentation technique précise et agréable à lire dans notre langue. J’ai simplement oublié que le dépôt était resté en anglais après cette décision. Je vais donc le repasser en français. Merci de m’avoir signalé cette incohérence.

      Pour la longueur, tu mets aussi le doigt sur quelque chose avec lequel j’ai beaucoup hésité. Je voulais que ce premier article arrive à un résultat concret, même modeste, et j’avais peur qu’en le découpant trop il s’arrête avant d’avoir produit quoi que ce soit d’intéressant. Mais, à l’arrivée, j’ai empilé beaucoup de sujets : extensions et formats, signatures binaires, ISO 9660, Joliet, PlayStation 3, commandes shell, puis Haskell. Il y a en plus une double manipulation, puisque je mène d’abord l’enquête avec le shell avant de la refaire dans GHCi.

      Le passage par ISO 9660 avait une raison : avant d’atteindre les fichiers propres au jeu, il faut comprendre les couches extérieures de l’image qui permettent de les retrouver. Ce n’est donc pas le sujet final du projet, mais une étape vers les données de Demon’s Souls. Si cela ressemble à un long détour, c’est que je ne l’ai probablement pas assez bien expliqué.

      Ta remarque sur la reproductibilité est également très juste. Les commandes et leurs sorties permettent de voir où se trouvent les informations et de refaire le raisonnement sur une autre image. Mais elles ne permettent pas de rejouer l’expérience à l’identique ni de modifier mes données, puisque je ne peux pas redistribuer l’image du jeu.

      Je pourrais utiliser une image ISO libre pour cet article, mais ce ne serait pas vraiment cohérent avec la suite : je vais rapidement travailler sur des données issues des jeux FromSoftware que je ne pourrai pas davantage redistribuer. Je préfère donc assumer ce corpus plutôt que de donner provisoirement une fausse impression de reproductibilité.

      En revanche, ton commentaire me donne une idée de découpage qui me paraît bien meilleure : faire les articles généraux (lecture binaire, offsets, endianness, description des structures, etc.) avec des données synthétiques ou librement accessibles, afin qu’ils soient entièrement reproductibles. Puis publier entre eux des articles plus courts et plus pratiques montrant comment appliquer ces notions à mes exemplaires de Demon’s Souls, Dark Souls ou Dark Souls II.

      Je crois que mon premier article a essayé d’être ces deux choses à la fois, ce qui explique sans doute sa longueur. Pour la suite, je vais essayer de mieux séparer les fondations générales, reproductibles et pédagogiques, des études de cas concrètes sur les jeux.

      Enfin, Haskell est un choix complètement assumé : c’est un langage que j’aime beaucoup et que j’ai envie d’approfondir. Mais cela ne veut pas dire qu’il est immédiatement accessible à tout le monde. Je dois mieux annoncer les prérequis et éviter de demander au même article d’introduire à la fois Haskell, l’analyse binaire et les particularités d’une image PlayStation 3.

      Merci encore pour ton retour. Il ne m’aide pas seulement à corriger quelques détails : il me donne une structure beaucoup plus claire pour toute la suite de la série. :-)

  • # intro

    Posté par  (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 03 septembre 2026 à 12:34.

    les questions qui me viennent naturellement sont qu'ils me manquent un § d'introduction ;-)

    Là on rentre directement dans le sujet (et j'ai trouvé cela plutôt agréable à lire, plus ci-dessous).

    bref, un article d'intro pour le contexte m'aurait aidé, avant de devoir mettre les mains dans le cambouis directement ;-)

    J'y verrais les thèmes suivants.

    pourquoi le choix de Haskell ? En quoi est-il bien — voire mieux — adapté à la rétro-ingénierie ? Quels auraient été tes autres choix ?

    à mon grand étonnement, le code haskell est bien lisible (je ne pratique pas :D) même si ajouter des commentaires dans le code pourrait être utile pour rentrer dans la logique de son découpage : objet des fonctions (entrées et sorties attendues selon les cas), pourquoi certaines fonctions sont ressorties ? (réutilisation ? facilitation lecture ? généricité ?). Même si tu donnes le contexte autour (ce qui m'a beaucoup facilité la lecture du code), j'ai tendance à attendre que le code ait le minimum de commentaires permettant de comprendre à quoi il sert et ce qu'il produit.

    bravo pour les références à ECMA-119, au moins c'est normatif et raccroché à quelque chose de concret ;-) (et un peu indispensable)
    donc l'objet de ta série d'article est de corroborer en quoi les fichiers à ta disposition sont conformes à ECMA-119 ? ou d'identifier des écarts et leur trouver une justification (et exhaustivité des cas rencontrés) ?

    ça manque un peu d'un rappel des limites que tu te donnes pour publication, même si cela transparaît dans tes formulations, notamment «  implémenter la plus petite capacité nécessaire à l’étape suivante ». Rappeler (plutôt dans un article dédié) les « zones grises » me paraît important. Notamment le fait que tu te confrontes à des CLUF non adaptés au droit européen dans lequel il est par exemple illégal de prétendre que la décompilation est illégale (cela fait des clauses léonines dans ces contrats, trop longs à lire de toute façon et non rédigés pour être compréhensibles par le commun des mortels…). Ce qui est légal en Europe, c'est la rétro-ingénierie à des fins d'interopérabilité, justement le cas qui te concerne avec des fichiers censés respecter des normes et pouvoir être a minima relus par d'autres logiciels en lien avec tout ce qui est format ouvert. Comme dans beaucoup d'autres pays, tu n'as en revanche par défaut pas le droit de publier tel quel le produit d'une décompilation (hormis licence libre du fichier d'origine, par exemple). J'imagine que les autres outils auquel tu fais allusion ont un § similaire (plus ou moins développé, autant reprendre ce qui s'applique à ton cas).

    bref, il y a de quoi peupler tout un article, et tu aurais intérêt à le garder sous le coude pour tracer au fur et à mesure les choix de ce que tu publies et ce que tu conserves pour toi.

    typiquement, il serait intéressant d'avoir des fichiers d'exemple — sous une licence acceptable permettant un minimum de republication (voire une publication sans limitation, on peut rêver, même si la licence MIT est intéressante pour cela :p) — rien que pour que chaque utilisateur puisse valider le bon fonctionnement de ton outil de leur côté ou mettre en place une chaîne de CI. Et bien sûr, ce ne sera sans doute pas les fichier d'origine :/ Mais cela donnerait les indications à ceux qui l'appliqueraient à leurs fichiers à disposition ce qu'ils peuvent se permettre de publier et ce qu'ils doivent garder pour eux.

    sinon, petite remarque : tu as conservé le terme offset non traduit — à raison àmha — autant réutiliser le terme du domaine lorsqu'il est approprié (plutôt qu'une traduction bancale), cela facilite la lecture des articles en anglais, d'autant que lorsque tu choisis une traduction tu donnes la référence des termes d'origine.

    voilà pour des remarques générales à première lecture, il n'y a pas vraiment de points spécifiques qui m'ont gêné lors de cette lecture ;-) bravo pour le style.

    • [^] # Re: intro

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      Merci beaucoup pour ce retour, il me donne pas mal d’idées pour la suite ! Avec le commentaire précédent, je comprends qu’il manque sans doute un texte d’introduction, entre préambule et FAQ, pour présenter le projet, le corpus, le choix de Haskell et les prérequis.

      Ces choix viennent en partie de mon parcours : je collectionne les jeux vidéo depuis plus de 20 ans, j’adore les jeux FromSoftware et j’ai toujours aimé le bas niveau, de l’assembleur au VHDL en passant par la Game Boy. Haskell se trouve un peu au croisement de tout cela : j’aime son système de types, la composition des fonctions et la façon dont on peut y construire des parseurs. Ce n’est pas forcément « le meilleur langage » pour la rétro-ingénierie, mais c’est celui que j’ai envie d’approfondir. L’introduction sera justement l’occasion d’expliquer ce choix et les alternatives possibles.

      Je suis très content que le code t’ait paru lisible sans pratiquer (pour le moment :p) Haskell. :-) Je comprends aussi ta remarque sur les commentaires : je me suis beaucoup appuyé sur les explications autour du code et sur les signatures des fonctions, mais cela ne suffit pas toujours à faire comprendre leur rôle ni les raisons du découpage. Ajouter quelques commentaires directement aux endroits importants permettrait de mieux relier le code au raisonnement de l’article, sans pour autant le surcharger.

      Pour ECMA-119, je ne cherche pas à couvrir toute la norme ni à garantir la conformité de toutes les images. J’applique plutôt un design par soustraction : implémenter le minimum nécessaire pour atteindre un objectif précis. Les références normatives permettent ensuite à ceux qui le souhaitent de partir du code pour aller plus loin. Une structure qui sort du sous-ensemble reconnu devra simplement être signalée comme absente, incorrecte ou non prise en charge. Mais je prends en compte cette remarque :-)

      Nous sommes également d’accord sur les fixtures et l’intégration continue. Je compte développer le projet en TDD, car les tests peuvent aussi servir de documentation exécutable de l’API. Les parties générales pourront ainsi utiliser des données libres ou synthétiques que chacun pourra rejouer dans la CI.

      Merci aussi d’avoir soulevé la question juridique. Je n’ai aucune intention de diffuser du contenu protégé et je veillerai à respecter le cadre applicable, mais je n’ai pas encore suffisamment approfondi cet aspect pour en dire davantage.

      Merci encore pour toutes ces pistes. Je comprends qu’il ne manque pas forcément plus de contenu au premier article, mais plutôt une vraie porte d’entrée avant de mettre les mains dans le cambouis. :-)

  • # Titre

    Posté par  . Évalué à 5 (+3/-0).

    Hello, juste une petite note rapide: dommage pour le titre, le sujet est intéressant, l'article de même, cependant le titre est loin d'être acrocheur. Le sujet porte sur du reverse et de l'étude pour éventuellement du modding/tooling pour de la PS3. En lisant simplement le titre, on passe devant le potentiel de l'article;

    • [^] # Re: Titre

      Posté par  (site web personnel) . Évalué à 1 (+0/-0).

      À commentaire sans appel, réponse sans appel : lol, j’avoue :-)

      Je ne m’étais pas rendu compte à quel point mon titre était franchement bof voire un peu naze, mais maintenant que tu le soulignes, c’est assez évident :-)

      Je l’ai remplacé par Modding de jeux FromSoftware en Haskell : sonder une ISO PlayStation 3, qui devrait déjà être plus explicite et plus accrocheur \o/

      Plus généralement, tous vos retours m’ont beaucoup aidé à clarifier ce que je devrais faire pour la suite, et surtout ce que j’ai réellement envie d’en faire.

      Merci chaleureusement à vous tous !!!

Envoyer un commentaire

Suivre le flux des commentaires

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