DEV Community: Karim DRIDI

Hexegesis : construction d’un programme PlayStation 3 minimal

Karim DRIDI — Mon, 07 Sep 2026 22:03:48 +0000

Construire un cas minimal et reproductible

Sur un ordinateur courant, un programme Hello World peut généralement être compilé et lancé en deux commandes. Sur PlayStation 3, le code C reste élémentaire, mais son exécution demande une chaîne beaucoup plus large : un compilateur croisé pour le PPU, les bibliothèques et les outils propres à la PS3, un exécutable au format SELF, un fichier de paramètres, un descripteur du support, une arborescence de jeu sur disque et, pour le chargement d’une image ISO dans RPCS3, une table de régions supplémentaire.

Les informations nécessaires se trouvent dans plusieurs sources complémentaires : ps3toolchain et PSL1GHT fournissent les outils et les règles de construction, la documentation communautaire décrit les formats, et le code source de RPCS3 révèle les contrôles effectués au chargement. Cet article réunit ces éléments dans une même procédure. Le problème traité n’est donc pas l’écriture du programme lui-même, mais l’identification, la compréhension et l’assemblage de tout ce qui permet de le lancer.

Nous procéderons par soustraction. Nous conserverons uniquement les outils, les transformations et les fichiers nécessaires au cas vérifié dans RPCS3. Docker fournira un environnement de construction reproductible ; les commandes seront exécutées explicitement afin de rendre visible le rôle de chaque étape. Nous essaierons d’abord le répertoire de jeu, puis son image ISO, de manière à isoler les erreurs éventuelles.

Le résultat sera un exemple synthétique et réutilisable : un programme PPU qui écrit Bonjour depuis Hexegesis., accompagné de PARAM.SFO, de PS3_DISC.SFB et d’EBOOT.BIN, puis placé dans une image ISO 9660 que la version testée de RPCS3 peut lancer.

Sommaire

Le résultat attendu
Construire l’image Docker
Créer les paramètres du jeu : PARAM.SFO
Créer le descripteur de disque minimal : PS3_DISC.SFB
Compiler le programme et créer EBOOT.BIN
Vérifier le répertoire de jeu dans RPCS3
Créer une image ISO 9660
Ajouter la table de régions PS3
Bilan

Le résultat attendu

Le répertoire de jeu construit dans cet article possède l’arborescence suivante :

disc-root/
├── PS3_DISC.SFB
└── PS3_GAME/
    ├── PARAM.SFO
    └── USRDIR/
        └── EBOOT.BIN

RPCS3 sait démarrer des jeux organisés de cette manière. Son code source constitue ici une référence particulièrement utile, car il révèle les chemins recherchés et les contrôles effectués lors du chargement. Le PS3 Developer Wiki décrit également l’arborescence habituelle d’un jeu sur disque, avec davantage de fichiers que notre exemple minimal.

`PS3_GAME/USRDIR/EBOOT.BIN` — le programme

C’est le programme lancé lorsque le jeu démarre. Dans un jeu plus riche, USRDIR contient aussi les ressources utilisées par ce programme : données, sons, textures, scripts ou fichiers de configuration.

Dans notre exemple, EBOOT.BIN contient du code destiné au PPU (Power Processing Unit), l’unité de traitement principale du processeur Cell. ppu-gcc produit d’abord un exécutable intermédiaire au format ELF (Executable and Linkable Format) ; les outils PS3 construisent ensuite, à partir de cet ELF, un fichier exécutable au format SELF. Ce fichier est enregistré sous le nom conventionnel EBOOT.BIN.

`PS3_GAME/PARAM.SFO` — les paramètres du jeu

Ce fichier rassemble les paramètres qui permettent d’identifier et de présenter le jeu : titre affiché, identifiant du titre, catégorie, version et capacités annoncées.

Notre fichier synthétique contient notamment le titre Bonjour depuis Hexegesis, l’identifiant HXGS00001, la catégorie DG, ainsi que les valeurs 01.00 pour APP_VER et VERSION.

`PS3_DISC.SFB` — le descripteur du support

Ce fichier se place à la racine d’un jeu sur disque et participe à l’identification du support.

Dans notre exemple minimal, ce fichier se réduit à la signature .SFB. Nous reviendrons sur cette simplification lorsque nous le créerons.

Cette arborescence suggère déjà le déroulement du travail :

programme C
→ exécutable PPU au format ELF
→ programme PS3 au format SELF, enregistré comme EBOOT.BIN

métadonnées lisibles
→ PARAM.SFO binaire

signature minimale du disque
→ PS3_DISC.SFB

ces trois fichiers
→ répertoire de jeu que RPCS3 peut démarrer

Le fichier central est EBOOT.BIN : sans lui, il n’y a pas de programme à exécuter. PARAM.SFO et PS3_DISC.SFB donnent toutefois au répertoire le contexte nécessaire pour être traité comme un jeu sur disque plutôt que comme une simple collection de fichiers.

Nous allons maintenant construire chaque fichier pas à pas. La version du projet utilisée pour cet article est disponible sur GitHub. Elle contient également un script qui automatise la construction.

↑ Retour au sommaire

Construire l’image Docker

La construction repose sur trois ensembles d’outils :

ps3toolchain installe ppu-gcc, le compilateur croisé qui produit des fichiers ELF destinés au PPU, ainsi que ppu-strip, qui en retire les informations inutiles à l’exécution ;
PSL1GHT ajoute les fichiers d’en-tête et les bibliothèques qui permettent au code C d’appeler les services de la PS3. Il fournit également sfo, qui crée PARAM.SFO, sprxlinker, qui prépare l’ELF pour la conversion, et make_self, qui produit le SELF ;
les utilitaires usuels terminent la préparation du disque : printf crée le fichier minimal PS3_DISC.SFB, xorriso place l’arborescence dans une image ISO 9660 générique, puis printf et dd écrivent les octets supplémentaires attendus par RPCS3.

Nous réunirons tous ces outils dans une même image Docker.

Récupérons le projet, puis plaçons-nous dans son répertoire :

git clone https://github.com/hexegesis/hexegesis-experiments.git
cd hexegesis-experiments
git checkout 8ca7eb9c02f36cc42c26b157f6013c68c56616e1
cd hello-world

Si le dépôt est déjà présent sur votre machine, ignorez git clone, placez-vous à sa racine et exécutez git fetch origin avant les deux dernières commandes.

Le Dockerfile.ps3dev construit les révisions indiquées de ps3toolchain, PSL1GHT et ps3libraries, puis installe xorriso et xxd. Construisons l’image :

docker build \
  --tag hexegesis-ps3dev \
  --file Dockerfile.ps3dev \
  .

La première construction télécharge et compile la chaîne PPU ; elle peut donc prendre plusieurs minutes. Les constructions suivantes réutilisent normalement le cache Docker.

Ouvrons ensuite un shell dans cette image. Le répertoire courant de l’hôte est monté dans /work : tout fichier créé dans /work depuis le conteneur restera dans notre répertoire de travail après la sortie du shell.

docker run --rm -it \
  --volume "$PWD:/work" \
  --workdir /work \
  --entrypoint /bin/sh \
  hexegesis-ps3dev

L’invite est maintenant celle du conteneur. Toutes les commandes qui suivent sont exécutées dans ce shell ; nous ne répéterons plus docker run.

pwd

for tool in ppu-gcc ppu-strip sprxlinker make_self sfo xorriso xxd; do
  command -v "$tool"
done

La première commande affiche /work. La seconde affiche un chemin pour chaque outil. Nous pouvons donc commencer à créer les fichiers. Nous laisserons ce shell ouvert jusqu’à la création et à la vérification de l’image ISO ; --rm supprimera ensuite le conteneur temporaire, mais pas les fichiers du volume monté.

↑ Retour au sommaire

Créer les paramètres du jeu : `PARAM.SFO`

PARAM.SFO contient les métadonnées du jeu. Chaque entrée associe le nom d’un paramètre, comme TITLE ou TITLE_ID, à une valeur typée. RPCS3 lit ce fichier pour obtenir notamment le titre affiché, l’identifiant, la catégorie et la version du jeu.

Le PS3 Developer Wiki décrit sa structure comme un en-tête suivi d’une table d’entrées, d’une table de clés et d’une table de valeurs. L’outil sfo installé par PSL1GHT produit cette structure à partir d’un fichier XML lisible.

Déclarer les paramètres

Créons le fichier param-sfo.xml avec le contenu suivant :

<?xml version="1.0"?>
<sfo>
  <!-- Version de l'application. La forme attendue est NN.NN. -->
  <value name="APP_VER" type="string">01.00</value>

  <!-- Drapeaux d'attributs optionnels. La valeur 0 n'en active aucun. -->
  <value name="ATTRIBUTE" type="integer">0</value>

  <!-- Indique si le contenu est amorçable : 1 pour oui, 0 pour non. -->
  <value name="BOOTABLE" type="integer">1</value>

  <!-- Nature du contenu. DG désigne un jeu sur disque. -->
  <!-- RPCS3 attend précisément DG lorsqu'il reconnaît ce répertoire comme jeu disque. -->
  <value name="CATEGORY" type="string">DG</value>

  <!-- Niveau de contrôle parental, sur une échelle communautairement documentée de 0 à 11. -->
  <!-- Nous conservons la valeur 0 du modèle fourni par PSL1GHT. -->
  <value name="PARENTAL_LEVEL" type="integer">0</value>

  <!-- Version minimale du logiciel système annoncée par le jeu, sous la forme NN.NNNN. -->
  <value name="PS3_SYSTEM_VER" type="string">01.8000</value>

  <!-- Drapeaux des modes vidéo annoncés. -->
  <!-- 63 = 1 + 2 + 4 + 8 + 16 + 32 : tous les drapeaux définis par RPCS3 sont activés. -->
  <!-- Ils correspondent à 480, 576, 720, 1080, 480 au format 16:9 et 576 au format 16:9. -->
  <value name="RESOLUTION" type="integer">63</value>

  <!-- Masque des formats audio annoncés au système. -->
  <!-- La valeur 1 correspond uniquement au mode LPCM 2.0. -->
  <!-- Le programme n'utilise aucune API audio et n'annonce donc aucun mode multicanal. -->
  <value name="SOUND_FORMAT" type="integer">1</value>

  <!-- Titre lisible du jeu. Des clés TITLE_00, TITLE_01, etc. peuvent fournir des traductions. -->
  <value name="TITLE" type="string">Bonjour depuis Hexegesis</value>

  <!-- Identifiant du titre. HXGS00001 est un identifiant synthétique de neuf caractères. -->
  <value name="TITLE_ID" type="string">HXGS00001</value>

  <!-- Version principale déclarée pour le contenu, distincte de APP_VER. -->
  <value name="VERSION" type="string">01.00</value>
</sfo>

Chaque balise <value> contient trois informations. Prenons cet exemple :

<value name="BOOTABLE" type="integer">1</value>

Ici, name="BOOTABLE" nomme le paramètre, type="integer" indique qu’il s’agit d’un entier et 1 en fournit la valeur. Pour TITLE, le type string désigne une chaîne de caractères.

Produire le fichier binaire

Créons le répertoire de destination, puis demandons à sfo de convertir le XML :

mkdir -p disc-root/PS3_GAME
sfo --fromxml param-sfo.xml disc-root/PS3_GAME/PARAM.SFO

Vérifions que l’outil peut relire le fichier produit :

sfo --list disc-root/PS3_GAME/PARAM.SFO

La sortie affiche les onze paramètres du XML. Vérifions notamment que CATEGORY vaut DG, que TITLE vaut Bonjour depuis Hexegesis et que TITLE_ID vaut HXGS00001. Cette relecture confirme que l’outil sfo retrouve les paramètres et les valeurs choisis ; l’essai dans RPCS3 vérifiera séparément que l’émulateur accepte le fichier. L’étude de l’en-tête, des tables et des offsets internes de PARAM.SFO dépasse l’objectif de ce tutoriel.

↑ Retour au sommaire

Créer le descripteur de disque minimal : `PS3_DISC.SFB`

Le fichier PS3_DISC.SFB se trouve à la racine du disque, tandis que PARAM.SFO se trouve dans PS3_GAME. Dans leur forme complète, ces fichiers ont des rôles distincts : le premier décrit le support et son contenu ; le second décrit le jeu lui-même. Le PS3 Developer Wiki documente un descripteur plus complet, avec des enregistrements et des drapeaux qui peuvent notamment désigner des paramètres du titre.

Notre objectif est plus modeste : créer le marqueur minimal accepté par la vérification étudiée dans RPCS3. printf écrit la chaîne .SFB sans ajouter de retour à la ligne :

printf '.SFB' > disc-root/PS3_DISC.SFB

Le fichier obtenu contient uniquement ces quatre caractères. Il ne contient aucune des tables supplémentaires décrites pour un descripteur complet.

Cette simplification est volontaire. Dans la révision de RPCS3 utilisée pour cette expérience, IsValidSfb exige que PS3_DISC.SFB existe, comporte au moins quatre octets et commence par le préfixe .SFB. Le démarrage d’un répertoire de jeu sur disque appelle cette vérification. Notre fichier satisfait ce contrôle de l’émulateur. Cette construction ne vise ni à reproduire le descripteur d’un disque commercial ni à établir une compatibilité avec une console physique.

↑ Retour au sommaire

Compiler le programme et créer `EBOOT.BIN`

Le fichier de paramètres et le descripteur du support existent maintenant. Il reste à produire le programme qu’ils accompagnent.

Créons les répertoires nécessaires au code source, à l’ELF préparé et au programme final :

mkdir -p source build disc-root/PS3_GAME/USRDIR

Créons ensuite source/main.c :

#include <stdio.h>
#include <stdlib.h>

/*
 * Écrit une ligne sur la sortie standard. La bibliothèque librt de PSL1GHT
 * transmet cette sortie au TTY de la PS3, que RPCS3 enregistre dans son journal.
 */
int main(void)
{
    /* puts ajoute automatiquement un retour à la ligne après le message. */
    puts("Bonjour depuis Hexegesis.");

    /* Indique au système que le programme s'est terminé normalement. */
    return EXIT_SUCCESS;
}

Le sigle TTY, hérité des téléscripteurs, désigne ici la sortie textuelle émulée de la PS3, que RPCS3 consigne dans son journal.

Compiler le code C et produire l’ELF PPU

ppu-gcc est un compilateur croisé : il s’exécute dans le conteneur, mais produit du code destiné au PPU. Commençons par compiler le code source C en fichier objet :

ppu-gcc \
  -O2 \
  -Wall \
  -mcpu=cell \
  -mhard-float \
  -c source/main.c \
  -o source/main.o

Voici le rôle de chaque option :

-mcpu=cell demande au compilateur de produire du code pour le processeur PPU du Cell ;
-mhard-float demande l’utilisation de l’unité matérielle de calcul en virgule flottante du PPU ;
-O2 active les optimisations usuelles ; cette option n’est pas indispensable à un programme aussi simple, mais correspond à un niveau d’optimisation courant ;
-Wall active les avertissements courants du compilateur et n’affecte pas le format du fichier produit ;
-c arrête la construction après la compilation, avant l’édition de liens ;
-o source/main.o nomme le fichier objet obtenu.

Procédons ensuite à l’édition de liens pour produire un exécutable PPU au format ELF :

ppu-gcc \
  -mcpu=cell \
  -mhard-float \
  source/main.o \
  -L"$PSL1GHT/ppu/lib" \
  -lrt \
  -llv2 \
  -o hello-world.elf

Ces options complètent l’édition de liens :

-L"$PSL1GHT/ppu/lib" ajoute le répertoire contenant les bibliothèques de PSL1GHT aux chemins parcourus par l’éditeur de liens ;
-lrt lie librt. Lorsque puts écrit sur stdout, l’implémentation de write fournie par cette bibliothèque appelle sysTtyWrite. Le message est ainsi envoyé au TTY de la PS3, que RPCS3 consigne dans son journal ;
-llv2 lie liblv2, la bibliothèque de base utilisée pour interagir avec LV2, le noyau système de la PS3.

L’ordre -lrt -llv2 reprend celui du Makefile du projet.

hello-world.elf est l’exécutable PPU intermédiaire. Il doit encore être transformé en SELF avant de prendre la place de EBOOT.BIN.

Transformer l’ELF en SELF

L’ELF ne peut pas encore servir directement d’EBOOT.BIN. Reproduisons les trois commandes employées par les règles de construction de PSL1GHT :

ppu-strip hello-world.elf -o build/hello-world.elf
sprxlinker build/hello-world.elf
make_self build/hello-world.elf hello-world.self

Lors de la commande précédente, ppu-gcc a déjà piloté l’éditeur de liens : les fichiers objets et les bibliothèques ont été réunis, leurs symboles ont été résolus et l’ELF exécutable a été produit. Les trois commandes suivantes accomplissent donc des transformations différentes :

ppu-strip crée build/hello-world.elf à partir de l’ELF original, puis supprime de cette copie la table des symboles et les autres informations inutiles à l’exécution ;
malgré son nom, sprxlinker ne réalise pas une seconde édition de liens. Il effectue dans l’ELF déjà lié les ajustements propres à la PS3 : il l’identifie comme un exécutable Cell LV2 et complète les informations relatives aux bibliothèques importées et aux fonctions du PPU. L’ELF est alors prêt à être transformé en SELF ;
make_self ne recompile pas le programme. Il construit un fichier SELF à partir des en-têtes et des segments de l’ELF préparé, ajoute les métadonnées propres à ce format, puis compresse et chiffre les segments avant d’ajouter les informations d’intégrité des segments et la signature du SELF. Les instructions produites par GCC ne sont pas recompilées.

PSL1GHT ne fournit pas de manuel distinct pour sprxlinker et make_self. Leur rôle est établi ici à partir des règles de construction du projet et de leur code source.

Le recours à une copie allégée permet de produire le SELF tout en conservant l’ELF original. Pour effectuer un débogage au niveau du code source, il faudrait également compiler cet original avec -g afin d’y ajouter les informations de débogage ; ce n’est pas l’objectif de ce tutoriel.

Nous disposons maintenant du fichier SELF produit par PSL1GHT à partir de l’ELF. Copions-le à l’emplacement attendu pour EBOOT.BIN :

cp hello-world.self disc-root/PS3_GAME/USRDIR/EBOOT.BIN

Nous pouvons enfin regarder l’arborescence complète :

find disc-root -type f -print | sort

disc-root/PS3_DISC.SFB
disc-root/PS3_GAME/PARAM.SFO
disc-root/PS3_GAME/USRDIR/EBOOT.BIN

Les trois fichiers présentés au début existent désormais au bon emplacement.

↑ Retour au sommaire

Vérifier le répertoire de jeu dans RPCS3

Les essais de ce tutoriel ont été réalisés avec RPCS3 Version: 0.0.42-19895-c6e96729 Alpha | master | local_build.

Le volume monté rend les fichiers de disc-root/ immédiatement accessibles sur l’hôte. Laissons le shell Docker ouvert et passons à RPCS3.

Dans RPCS3, choisissez File → Boot Game puis sélectionnez le dossier disc-root. Cette vérification permet d’isoler les problèmes liés au programme ou à l’arborescence avant d’introduire ceux que pourraient causer la création de l’image ISO ou sa table de régions.

RPCS3 lance alors le programme. Dans son journal TTY, vous pouvez lire le message suivant :

Bonjour depuis Hexegesis.

Cette observation établit le comportement de la version de RPCS3 testée avec cette arborescence synthétique. Elle ne démontre pas que le descripteur SFB minimal ou le SELF produit par la chaîne de développement seraient acceptés par une console physique.

Revenons maintenant au shell Docker, resté ouvert, pour créer l’image ISO.

↑ Retour au sommaire

Créer une image ISO 9660

Une image ISO représente le contenu d’un disque sous la forme d’une suite de secteurs. Nous demandons à xorriso d’y créer un système de fichiers ISO 9660 à partir du répertoire déjà vérifié, en reprenant les mêmes trois fichiers sans modifier leur contenu.

xorriso -as mkisofs \
  -iso-level 1 \
  -volid HXGS00001 \
  -no-pad \
  -output hello-world.iso \
  disc-root

Les arguments donnés à xorriso ont les rôles suivants :

-as mkisofs sélectionne l’interface de création compatible avec mkisofs ;
-iso-level 1 applique aux noms ISO 9660 les contraintes du niveau d’échange 1 : les noms de répertoires sont limités à huit caractères et les noms de fichiers suivent la forme « 8.3 », soit au plus huit caractères avant le point et trois pour l’extension. Le résumé de Wikipédia présente également ces restrictions ; tous les noms de notre arborescence les respectent ;
-volid HXGS00001 inscrit l’identifiant du volume ; nous choisissons ici la même valeur que TITLE_ID, même si les deux champs sont indépendants ;
-no-pad désactive les 300 Kio de remplissage que xorriso ajoute normalement à la fin de l’image ;
-output hello-world.iso nomme l’image produite ;
disc-root est le répertoire à placer dans l’image.

Vérifions l’inventaire sans extraire les fichiers :

xorriso -indev hello-world.iso -find / -type f -exec lsdl

Parmi les lignes affichées, vérifiez la présence des trois chemins suivants :

/PS3_DISC.SFB
/PS3_GAME/PARAM.SFO
/PS3_GAME/USRDIR/EBOOT.BIN

ISO 9660 divise l’image en secteurs logiques de 2 048 octets, numérotés à partir de zéro. Le numéro d’un secteur est son adresse logique de bloc, ou LBA (Logical Block Address). Un offset indique une position en octets depuis le début du fichier : la LBA 16 commence donc à l’offset 16 × 2048 = 32768, soit 0x8000. Les secteurs de LBA 0 à 15 constituent la zone système (System Area) ; la séquence des descripteurs de volume commence à la LBA 16. Pour approfondir ces notions, consultez l’article consacré à l’exploration d’une image ISO PlayStation 3, qui détaille la relation entre les LBA, les offsets et les descripteurs de volume.

xxd affiche une portion d’un fichier sous forme hexadécimale sans le modifier. Vérifions que xorriso a placé l’en-tête attendu à la LBA 16 :

xxd -g 1 -s $((16 * 2048)) -l 7 hello-world.iso

00008000: 01 43 44 30 30 31 01                             .CD001.

Les octets 01 CD001 01 identifient le descripteur principal de volume à l’emplacement attendu. Nous pourrons donc écrire la table de régions dans la zone système sans empiéter sur ce descripteur.

↑ Retour au sommaire

Ajouter la table de régions PS3

Le mot « région » ne désigne pas ici une zone géographique, mais un intervalle inclusif de LBA. Une région non protégée contient des secteurs non chiffrés, tandis qu’une région protégée contient des secteurs chiffrés. La table placée au début de l’image donne les bornes de ces régions.

D’où vient cette structure ? ECMA-119 réserve les seize premiers secteurs d’une image ISO 9660 à la zone système, mais ne définit pas leur usage par la PlayStation 3. Nous ne disposons pas d’une spécification publique de Sony à citer pour cette table. Sa description repose donc sur des documents et des implémentations indépendantes issues de la communauté PS3 :

l’annexe A du manuel de 3k3y ISO Tools explique l’alternance entre régions non chiffrées et chiffrées ;
IsoHeaderParser.GetUnprotectedRegions, dans PS3 Disc Dumper, lit en ordre big-endian — octet de poids fort en premier — un nombre de régions non protégées, un entier de 32 bits dont le rôle n’est pas nommé, puis les paires de LBA de début et de fin ;
le lecteur ISO de RPCS3 lit le même compteur et reconstruit l’alternance des régions. C’est cette dernière implémentation qui définit directement ce que notre ISO doit contenir pour être chargée par la version testée de RPCS3.

Notre image synthétique n’est pas chiffrée. Elle ne contient donc qu’une région non protégée, de la LBA 0 à la dernière LBA de l’image. Les seize premiers octets doivent décrire ceci :

offset 0x00 : nombre de régions non protégées = 1
offset 0x04 : champ non interprété = 0
offset 0x08 : première LBA = 0
offset 0x0c : dernière LBA = dernière LBA de l’image

Vérifions la valeur actuelle de ces seize octets :

xxd -g 4 -l 16 hello-world.iso

00000000: 00000000 00000000 00000000 00000000  ................

xorriso les a laissés à zéro. La première LBA et le champ non interprété ont donc déjà la valeur souhaitée pour cette expérience ; nous devons seulement écrire le compteur à l’offset 0 et la dernière LBA à l’offset 12.

Commençons par calculer cette dernière LBA. La taille étant un multiple de 2 048, le nombre de secteurs est la taille divisée par 2 048, et la dernière LBA est ce nombre moins un :

sector_size=2048
image_size=$(wc -c < hello-world.iso | tr -d ' ')
sector_count=$((image_size / sector_size))
last_lba=$((sector_count - 1))
printf 'octets=%s\nsecteurs=%s\nderniere-lba=%s\n' "$image_size" "$sector_count" "$last_lba"

Dans la construction observée pour cet article, l’image comporte 61 secteurs et sa dernière LBA vaut 60. Nous devons écrire 1 et 60 comme entiers de 32 bits en ordre big-endian. Cette petite fonction shell encode un entier en quatre octets dans cet ordre :

write_be32() {
  value=$1
  offset=$2
  bytes=$(printf '\\%03o\\%03o\\%03o\\%03o' \
    $(((value >> 24) & 255)) \
    $(((value >> 16) & 255)) \
    $(((value >> 8) & 255)) \
    $((value & 255)))
  printf '%b' "$bytes" | dd of=hello-world.iso bs=1 seek="$offset" conv=notrunc status=none
}

write_be32 1 0
write_be32 "$last_lba" 12

conv=notrunc est essentiel : dd écrit les quatre octets demandés sans tronquer le reste de l’image.

Examinons les seize premiers octets :

xxd -g 1 -l 16 hello-world.iso

Pour 61 secteurs, le résultat est :

00000000: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 3c  ...............<

Les quatre premiers octets donnent le compteur 1. Les quatre octets à l’offset 8 donnent la LBA de début 0. Les quatre derniers octets représentent 0x3c, soit la LBA de fin 60. Nous avons écrit huit octets dans la zone système, sans toucher au descripteur CD001 situé à la LBA 16.

Le projet contient aussi scripts/patch-ps3-regions.sh, qui automatise ces calculs et contrôle la taille, les bornes et la présence du descripteur de volume ISO 9660. Ici, nous avons détaillé explicitement les opérations afin d’observer précisément les valeurs ajoutées.

Contrôlons une dernière fois l’inventaire de l’image :

xorriso -indev hello-world.iso -find / -type f -exec lsdl

Quittons enfin le conteneur :

exit

Dans RPCS3, choisissez File → Boot ISO et sélectionnez hello-world.iso. Lors de notre essai, l’émulateur reconnaît l’unique région comme non protégée, n’essaie pas de la déchiffrer, monte le contenu de l’image, puis le programme écrit le même message :

Bonjour depuis Hexegesis.

↑ Retour au sommaire

Bilan

Nous sommes partis de trois fichiers dont nous connaissions la place et le rôle, puis nous les avons construits sans Makefile :

param-sfo.xml
→ sfo
→ PS3_GAME/PARAM.SFO

printf '.SFB'
→ PS3_DISC.SFB

source/main.c
→ ppu-gcc
→ hello-world.elf
→ ppu-strip + sprxlinker + make_self
→ PS3_GAME/USRDIR/EBOOT.BIN

ces trois fichiers
→ xorriso
→ hello-world.iso
→ table de régions PS3 dans la zone système

Nous avons relu PARAM.SFO avec sfo --list, contrôlé l’inventaire du répertoire et de l’image ISO, puis observé les valeurs ajoutées dans la zone système. Enfin, le message TTY a confirmé l’exécution du programme dans RPCS3.

Le résultat est un cas d’essai synthétique et redistribuable, utile aux prochaines étapes d’Hexegesis. L’expérience démontre sa construction et son exécution dans la version testée de RPCS3 ; elle ne permet ni d’affirmer que notre PS3_DISC.SFB minimal couvre le format complet, ni de conclure à une compatibilité avec une console PlayStation 3 ou avec des images de disques commerciaux.

↑ Retour au sommaire

Hexegesis : questions fréquentes

Karim DRIDI — Fri, 04 Sep 2026 14:49:11 +0000

Cette page rassemble les réponses aux questions générales sur Hexegesis. Elle pourra être complétée sans alourdir les articles techniques.

← Revenir au sommaire de la série

Faut-il connaître Haskell ?

Non. Les constructions nécessaires seront expliquées lorsqu’elles apparaîtront. Une première expérience de la programmation aidera à exécuter les exemples, mais elle ne conditionne pas la lecture des observations et de la méthode.

Faut-il posséder Demon’s Souls ?

Non pour lire la série ou exécuter les articles fondés sur des fixtures. Refaire les applications au corpus demandera en revanche de travailler sur son propre exemplaire, puisque les données commerciales ne seront pas fournies.

Les fichiers des jeux ou des mods seront-ils publiés ?

Non. Les dépôts contiendront du code, des fixtures synthétiques ou librement redistribuables, des références et des observations bornées. Ils ne contiendront pas d’images de disque ni de ressources extraites des jeux. Le contenu d’un mod existant ne sera pas republié sans autorisation.

Pourquoi utiliser des outils existants si Hexegesis doit les remplacer ?

Parce qu’ils fournissent immédiatement une procédure et un résultat de référence. Ils permettent de comprendre le problème avant de le réimplémenter. Leur usage initial et l’objectif d’une boîte à outils Haskell autonome correspondent à deux étapes différentes du projet.

Comment connaître les formats pris en charge par Hexegesis ?

La documentation et les tests du dépôt public Hexegesis décriront les capacités effectivement disponibles. Une structure étudiée dans un article ou un prototype ne suffit pas, à elle seule, à établir sa prise en charge par le logiciel.

La feuille de route est-elle définitive ?

Non. Les objectifs généraux sont connus, mais les formats rencontrés et les résultats obtenus détermineront le découpage des articles. Le sommaire restera le point d’entrée actualisé de la série.

↑ Revenir au sommaire de la série

Hexegesis : sommaire de la série

Karim DRIDI — Fri, 04 Sep 2026 14:46:20 +0000

Cette page est le point d’entrée de la série Hexegesis. Elle regroupe les textes de présentation, les articles publiés et les principales directions de travail.

Présentation et références

Présentation du projet — objectifs, choix de Haskell, méthode de travail et organisation des articles.
Questions fréquentes — prérequis, données utilisées, outils existants et portée du logiciel.

Articles publiés

Applications au corpus

Sonder une ISO PlayStation 3 en Haskell — lecture bornée de quelques métadonnées ISO 9660, Joliet et PlayStation 3, puis transcription de ces lectures dans GHCi.

Fondations reproductibles

Construire un programme PlayStation 3 minimal — chaîne reproductible pour compiler un programme PPU, produire les fichiers attendus par RPCS3 et construire une image ISO 9660 synthétique.

Prochaine application envisagée

Appliquer un mod existant à l’arborescence du jeu, vérifier son résultat dans RPCS3 et identifier précisément les fichiers et les opérations concernés. Cette référence donnera un objectif concret aux capacités suivantes d’Hexegesis.

Directions de travail

Les sujets actuellement envisagés comprennent :

la construction de fixtures binaires synthétiques ;
la description d’une structure commune à plusieurs interprétations ;
le parcours d’une arborescence Joliet ;
la localisation et l’extraction d’une ressource précise ;
l’étude des archives, des textures et des polices employées par le jeu ;
l’export d’une ressource vers un format modifiable ;
l’import de la modification et la reconstruction des conteneurs nécessaires ;
l’examen ultérieur des éléments associés au contenu abandonné.

Cette liste n’est ni un calendrier ni le plan définitif des articles. Les titres annonceront soit un concept de programmation effectivement étudié, soit un résultat concret obtenu dans le jeu. Ce sommaire sera mis à jour à mesure que le travail progressera.

Hexegesis : projet de modding des jeux FromSoftware en Haskell

Karim DRIDI — Fri, 04 Sep 2026 14:40:00 +0000

← Revenir au sommaire de la série

Hexegesis est un projet personnel consacré au modding des jeux FromSoftware en Haskell. J’ai envie d’y construire progressivement une boîte à outils composée de petits programmes en ligne de commande : inspecter les fichiers d’un jeu, identifier leurs formats, extraire des ressources, les transformer et les réintégrer.

Le point de départ reste très concret. Je voudrais remplacer une texture, modifier une police de caractères ou changer un écran d’accueil, puis vérifier le résultat dans RPCS3. Chaque objectif fournit un problème précis à résoudre et détermine les capacités dont j’ai réellement besoin. Plutôt que de chercher à prendre en charge intégralement un format, je commence par la plus petite partie utile.

Cette série me sert de journal de bord. J’y rassemble les problèmes rencontrés, les documents qui m’ont aidé, les choix d’implémentation et les limites de ce que j’ai effectivement vérifié. Je ne connais pas encore toutes les étapes nécessaires, et je ne souhaite pas reconstruire après coup une progression artificielle : les résultats obtenus détermineront la suite.

Ce préambule présente le projet, les raisons qui me poussent à le développer et la manière dont les articles seront organisés.

Sommaire

Une première modification visible dans RPCS3
L’ambition d’une BusyBox du modding
Pourquoi Demon’s Souls sur PlayStation 3 ?
Pourquoi Haskell ?
Du besoin à l’implémentation minimale
Écrire pour apprendre
Pourquoi écrire en français ?
Reproductibilité et corpus commercial

Une première modification visible dans RPCS3

Je souhaite commencer par une modification dont le résultat se constate immédiatement. Une nouvelle texture sur une arme ou un vêtement de départ, une autre police de caractères ou un écran d’accueil modifié conviendraient tous à cette première étape. Le choix définitif dépendra surtout de la chaîne de formats qu’il faudra réellement traiter.

RPCS3 peut charger une image du jeu ou une version extraite sous forme de répertoires. Pour appliquer les premiers mods, je travaillerai sur cette arborescence extraite : les fichiers modifiés pourront y être ajoutés ou remplacés sans reconstruire immédiatement une image ISO.

Une première expérience consistera à appliquer à mon exemplaire un mod déjà publié. Le but ne sera pas de republier son contenu, mais d’établir un résultat de référence : relever les fichiers concernés, identifier les outils employés, appliquer la modification, puis vérifier son effet dans RPCS3. Une fois cette procédure comprise, je pourrai reprendre chaque opération et déterminer comment produire moi-même une modification de même nature.

La chaîne de travail devrait ressembler à ceci :

obtenir l’arborescence du jeu
→ localiser le fichier concerné
→ identifier ses éventuels conteneurs
→ extraire la ressource recherchée
→ la convertir vers une représentation modifiable
→ effectuer la modification
→ reconstruire les conteneurs nécessaires
→ replacer les fichiers dans l’arborescence
→ vérifier le résultat dans RPCS3

Cette liste ne décrit pas encore une procédure validée. Je connais le résultat recherché, mais pas tous les formats intermédiaires ni toutes les contraintes de reconstruction. Les premières manipulations serviront précisément à les déterminer.

↑ Retour au sommaire

L’ambition d’une BusyBox du modding

Dans un premier temps, j’utiliserai les outils existants pour avancer, comprendre la chaîne de traitement et établir les résultats attendus. Un script Python, un programme spécialisé ou une manipulation manuelle peut parfaitement servir de référence provisoire.

À terme, j’aimerais cependant qu’Hexegesis permette de réaliser l’ensemble de ce travail sans dépendre d’une collection disparate de programmes. J’ai davantage une boussole qu’un plan arrêté : mon ambition serait qu’Hexegesis devienne, à son échelle, une sorte de BusyBox du modding. La comparaison place la barre assez haut, mais elle décrit bien la direction recherchée.

BusyBox réunit de nombreux utilitaires spécialisés derrière un même programme. Hexegesis suivrait un principe semblable dans un domaine plus restreint : sonder une image, parcourir une arborescence, trouver un fichier, l’extraire, reconnaître son format, l’exporter vers une représentation usuelle, importer une modification et reconstruire les données nécessaires.

Chaque commande devra accomplir une opération précise. Elle devra posséder des entrées, une sortie, des erreurs et des limites explicites. Les commandes pourront être utilisées seules ou composées depuis le Shell ; leur logique restera également accessible depuis une bibliothèque Haskell.

L’existence préalable d’un outil ne retire donc pas automatiquement une opération du périmètre d’Hexegesis. Cet outil peut d’abord me permettre d’avancer et de vérifier mon résultat. Son remplacement ultérieur par une implémentation Haskell répondra à un autre objectif : obtenir une boîte à outils cohérente, documentée et suffisante pour les formats effectivement pris en charge.

La lecture seule constitue le premier périmètre. Lorsqu’une opération d’écriture deviendra nécessaire, elle devra produire un nouveau fichier ou une nouvelle arborescence plutôt que modifier silencieusement la source. Les règles précises seront définies et testées à partir du premier besoin réel d’import ou de reconstruction.

↑ Retour au sommaire

Pourquoi Demon’s Souls sur PlayStation 3 ?

Il fallait choisir un premier jeu parmi des milliers. J’ai choisi la version PlayStation 3 de Demon’s Souls pour une raison simple : j’aime ce jeu. Je préfère consacrer du temps à des fichiers que j’ai réellement envie de comprendre et pouvoir lancer régulièrement le jeu sans que la vérification devienne une corvée.

Je collectionne les jeux vidéo depuis l’enfance et j’en possède aujourd’hui plus d’un millier. Les jeux FromSoftware occupent une place particulière dans cette collection. J’apprécie aussi la manière dont les mods permettent de redécouvrir un jeu connu, parfois plusieurs années après sa sortie. Le modding réunit ainsi deux activités qui m’intéressent déjà séparément : programmer et jouer.

Je possède au moins deux versions différentes de Demon’s Souls, Dark Souls et Dark Souls II. Elles pourront plus tard servir de corpus comparatif. Une structure observée dans une version ne sera cependant pas attribuée aux autres sans vérification : une édition régionale, une révision ou une plateforme différente peut employer une organisation distincte.

Demon’s Souls offre enfin un autre sujet qui m’intéresse depuis longtemps. De nombreux articles consacrés au data mining évoquent les ressources associées au royaume des géants et à la sixième Archstone, abandonnée dans le jeu publié. Ces articles rapportent les conclusions de personnes qui ont examiné les fichiers, mais ils donnent rarement les moyens de mesurer directement ce qui subsiste.

J’aimerais pouvoir le vérifier moi-même. S’agit-il de quelques fichiers isolés autour desquels les interprétations se sont accumulées ? D’une zone déjà largement construite mais privée de certaines ressources ? Quels éléments sont directement observables et quelles conclusions demandent une extrapolation ? Je ne veux pas supposer la réponse. Je veux disposer des outils nécessaires pour examiner les données et délimiter ce qu’elles permettent réellement d’affirmer.

Cette étude viendra plus tard. Avant d’analyser un contenu abandonné, il faut savoir atteindre les ressources, reconnaître leurs formats et les lire correctement.

↑ Retour au sommaire

Pourquoi Haskell ?

La première raison est personnelle : j’aime Haskell et j’ai envie de mieux le maîtriser. Le projet ne cherche pas à démontrer qu’il serait le meilleur langage pour la rétro-ingénierie ou le modding. De nombreux langages et outils savent déjà traiter des formats binaires. Je choisis Haskell parce que c’est dans ce langage que je souhaite réfléchir à ces problèmes.

J’ai commencé à programmer avec de l’assembleur. J’ai ensuite pratiqué le VHDL et l’assembleur sur Game Boy, puis je me suis progressivement tourné vers les langages fortement typés et fonctionnels, notamment OCaml et Haskell. Ces deux parcours ne me paraissent pas contradictoires. Le bas niveau oblige à comprendre la représentation effective des données ; les types et les abstractions permettent ensuite d’exprimer cette compréhension sans la laisser dispersée dans le programme.

Après une trentaine d’années de programmation, je prends de plus en plus de plaisir à reprendre des opérations simples et à chercher la formulation qui les rend à la fois explicites et composables. Lire quatre octets, calculer un offset ou décoder un entier ne présente aucune difficulté algorithmique particulière. La question intéressante devient : où placer la connaissance de la largeur du champ ? Comment représenter un résultat inconnu ou invalide ? Comment séparer la description d’une structure de l’effet qui consiste à lire un fichier ? Comment réutiliser une même description pour décoder, annoter ou documenter ?

Le programme produit m’intéresse, mais la manière de l’écrire m’intéresse tout autant. Je souhaite trouver une syntaxe dans laquelle l’intention reste visible et où les contraintes du format ne sont pas disséminées entre plusieurs couches de code.

Les types algébriques permettent de nommer les différents résultats au lieu de les réduire à des valeurs conventionnelles. Les fonctions pures permettent d’étudier séparément la transformation des octets et leur acquisition. L’écriture monadique permet d’enchaîner les calculs tout en rendant explicites les effets qu’ils requièrent. Cette séparation entre la valeur recherchée et les effets nécessaires à son obtention correspond particulièrement bien à la manière dont j’ai envie d’aborder les parseurs.

J’ai déjà expérimenté des architectures fondées sur les GADT, les approches tagless final ou les monades libres. Je connais encore peu certaines bibliothèques d’effets comme effectful, mais j’y pressens des outils susceptibles de m’intéresser. Hexegesis me fournit une raison concrète de les étudier, de les comparer et surtout de constater ce qu’elles apportent sur un programme réel.

Ces techniques ne seront pas introduites pour donner au projet une apparence sophistiquée. Elles apparaîtront si un besoin les justifie. Une abstraction pourra être essayée, mesurée sur plusieurs formats, puis conservée, simplifiée ou abandonnée. Le journal de bord devra rendre compte de cette décision au lieu de présenter après coup l’architecture retenue comme une évidence.

Le modding est donc à la fois une finalité et un domaine d’application pour mon apprentissage de Haskell. Inversement, Haskell me fournit les outils conceptuels avec lesquels je souhaite formaliser le travail de modding. Aucun des deux sujets n’est un simple décor pour l’autre.

↑ Retour au sommaire

Du besoin à l’implémentation minimale

Les informations utiles au modding sont souvent dispersées entre des forums, des dépôts de code, des scripts, des outils spécialisés et des documents techniques volumineux. Beaucoup de ces ressources ont été écrites pour résoudre efficacement un problème précis. Leur contexte, leurs hypothèses et les raisons d’un offset particulier ne sont donc pas toujours explicités.

Je souhaite produire le type de document qui me manque lorsque j’aborde un nouveau format : un objectif concret, les passages utiles des sources, les observations correspondantes, le raisonnement qui les relie et une implémentation dont le périmètre est annoncé.

Il ne s’agit pas de lire intégralement une spécification avant d’agir. Dans le premier article, la norme ISO 9660 publiée sous la référence ECMA-119 contient bien davantage d’informations que nécessaire pour retrouver le nom du volume, sa taille logique ou le marqueur Joliet. Je consulte les sections qui répondent à la question en cours, tout en conservant la référence complète afin de savoir où poursuivre si un besoin ultérieur l’exige.

Pour chaque capacité, je suivrai autant que possible le même ordre de travail :

formuler un résultat observable ;
examiner les outils et les implémentations existants ;
retrouver les documents qui décrivent les structures nécessaires ;
effectuer une lecture petite, précise, bornée et strictement en lecture seule ;
interpréter les valeurs et consigner leur provenance ;
distinguer les faits établis, les observations locales, les inférences et les questions restantes ;
écrire la plus petite implémentation utile au résultat ;
construire des données synthétiques pour tester les cas valides et les erreurs ;
confronter séparément l’implémentation au corpus réel ;
annoncer exactement les capacités obtenues et leurs limites.

Cette discipline est connue sous le nom de design par soustraction. Fumito Ueda l’a mise en œuvre dans la conception d’Ico en retirant les éléments qui ne servaient pas son idée centrale. David Sirlin, présent lors de la conférence donnée par Ueda à la Game Developers Conference de 2004, en propose une explication détaillée à partir de cet exemple.

La référence trouve naturellement sa place dans ce projet : Hidetaka Miyazaki a expliqué que la découverte d’Ico lui avait révélé les possibilités du jeu vidéo et donné envie d’en créer lui-même. Cette décision l’a conduit à rejoindre FromSoftware, où il a ensuite dirigé Demon’s Souls.

Appliqué à Hexegesis, le principe reste concret. Lorsqu’une capacité ne contribue pas au résultat actuel, je préfère l’écarter plutôt que la développer sur la base d’un usage hypothétique. Une abstraction n’est introduite qu’après l’apparition d’une répétition ou d’une difficulté réelle. Sa confrontation à un second format permet ensuite de décider si elle doit être conservée, réduite ou remplacée.

Cette méthode n’oppose pas la pratique à la théorie. Une observation sans modèle reste difficile à généraliser ; une description théorique qui n’est jamais confrontée aux données ne suffit pas davantage. Les commandes Shell, les spécifications, les types Haskell et les tests apportent des formes de preuve différentes qui doivent rester reliées sans être confondues.

Une norme définit un format, mais ne prouve pas qu’une image particulière lui est entièrement conforme. Deux implémentations indépendantes peuvent corroborer une structure sans devenir une spécification officielle. Une valeur lue dans mon exemplaire reste une observation locale. Une fixture synthétique prouve qu’un test couvre le cas qu’elle représente, pas que le programme accepte toutes les variantes rencontrées dans le monde réel.

↑ Retour au sommaire

Écrire pour apprendre

Cette série est d’abord écrite pour moi. Les problèmes de modding qui m’intéressent sont difficiles à reprendre plusieurs mois plus tard lorsque les informations restent réparties entre mon historique Shell, quelques notes et des dépôts externes. Un article m’oblige à reconstruire le raisonnement de manière assez précise pour pouvoir m’en servir de nouveau.

J’ai travaillé une dizaine d’années comme formateur à Epitech et je suis aujourd’hui consultant en intelligence artificielle. Cette expérience a renforcé une conviction simple : transmettre quelque chose reste pour moi l’un des meilleurs moyens de l’apprendre. Expliquer une structure oblige à vérifier son vocabulaire ; publier un exemple oblige à retrouver sa source ; écrire un test oblige à préciser le comportement attendu.

Je ne présente donc pas un programme d’enseignement dont je maîtriserais déjà toutes les étapes. Je partage un apprentissage en cours. Certains articles documenteront une réussite directe ; d’autres conserveront une erreur ou une hypothèse abandonnée lorsqu’elle aide réellement à comprendre la solution.

Je ne souhaite pas non plus réduire artificiellement les sujets difficiles. Une notion complexe peut être présentée simplement sans employer un synonyme approximatif ni dissimuler sa véritable définition. Le rôle du texte est d’introduire le terme exact, de fournir le modèle mental nécessaire et de montrer son usage sur un cas concret.

La série s’adresse ainsi aux personnes qui souhaitent commencer le modding, découvrir les formats binaires, lire du Haskell dans un contexte concret ou mieux formaliser une pratique déjà empirique. Il n’est pas nécessaire de connaître Haskell ni d’avoir déjà étudié des formats binaires avant de commencer. Une première expérience du terminal et de la programmation facilitera les manipulations, mais les notions nécessaires seront présentées au moment où elles interviennent.

Ce ne sera pas pour autant un cursus exhaustif. Je développerai ce que j’ai moi-même besoin de comprendre ou de formaliser. Lorsqu’une notion périphérique est déjà bien traitée ailleurs, une explication courte et une référence pourront suffire.

↑ Retour au sommaire

Pourquoi écrire en français ?

J’ai longtemps hésité entre l’anglais, qui permettrait de toucher une communauté plus large, et le français, que je préfère lire et écrire. Je consulte quotidiennement de la documentation anglaise et j’ai vécu plusieurs années à Londres ; ce choix ne vient donc pas d’une difficulté à travailler en anglais.

J’ai finalement choisi le français parce que j’ai envie de contribuer à une documentation technique francophone précise et de travailler mon propre style dans cette langue. Je souhaite écrire les articles que j’aurais aimé trouver moi-même : naturels, rigoureux et suffisamment détaillés pour retrouver le raisonnement, pas seulement son résultat.

Le français de l’article n’impose pas de traduire tout le vocabulaire. Les identifiants du code resteront naturellement en anglais. Les noms officiels des champs et des structures seront conservés lorsqu’ils facilitent la consultation des sources. L’objectif n’est pas de franciser mécaniquement la terminologie, mais de choisir le mot qui décrit le plus exactement le concept.

↑ Retour au sommaire

Reproductibilité et corpus commercial

Les images et les ressources des jeux étudiés sont commerciales et ne seront pas distribuées avec les articles. Cette contrainte impose de distinguer le protocole documenté de l’expérience entièrement reproductible.

Une commande exécutée sur mon exemplaire produit une observation locale. Je peux publier la commande, l’offset, la règle d’interprétation et le résultat utile au raisonnement. Un lecteur qui travaille sur son propre exemplaire pourra reprendre ce protocole, mais il devra vérifier ses valeurs au lieu de supposer qu’elles sont identiques aux miennes.

La série comportera donc deux catégories principales d’articles.

Fondations reproductibles

Ces articles étudieront un mécanisme général sur des données synthétiques ou librement redistribuables : lecture binaire bornée, endianness, description de formats, validation, interprètes, diagnostics, tests ou gestion des effets.

Le code et les fixtures permettront d’exécuter les exemples, de modifier les valeurs et de provoquer les erreurs décrites. La CI exécutera les tests associés aux propriétés explicitement vérifiables sur ces données. Elle ne prétendra pas valider les observations réalisées sur les jeux commerciaux.

Applications au corpus

Ces articles appliqueront les mécanismes précédents aux exemplaires de jeux FromSoftware que j’étudie. Ils pourront publier des offsets, des métadonnées, des méthodes et des résultats bornés, mais pas les images de disque, les ressources commerciales, les clés ou les exécutables déchiffrés.

Un article pourra naturellement mêler les deux dimensions. Sa catégorie indiquera seulement de quoi dépend son résultat principal. Une difficulté rencontrée sur le corpus pourra fournir le problème d’un prochain article général ; une capacité validée sur des fixtures devra ensuite être vérifiée séparément sur les données réelles.

Cette alternance permet aussi de lire la série pour des raisons différentes. Une personne intéressée par Haskell mais ne possédant pas Demon’s Souls pourra exécuter les fondations reproductibles. Une personne surtout intéressée par le modding pourra suivre leur mise en application sans être obligée d’adopter toutes les abstractions étudiées.

↑ Retour au sommaire

← Revenir au sommaire de la série

Hexegesis : sonder une ISO PlayStation 3 en Haskell

Karim DRIDI — Thu, 03 Sep 2026 00:31:00 +0000

À propos de cette série. Cette série raconte la construction progressive, en Haskell, d’outils consacrés à l’étude et à la transformation des formats binaires employés par les jeux FromSoftware sur PlayStation 3. Elle prend pour premier corpus la version PlayStation 3 originale de Demon’s Souls et avance par enquêtes documentées : observer une structure, établir ce qui est documenté, distinguer les faits des hypothèses, puis implémenter la plus petite capacité nécessaire à l’étape suivante.

← Revenir au sommaire de la série

Dans ce premier article, nous allons déterminer ce qu’un fichier nommé image.iso permet réellement d’affirmer. Nous commencerons par observer ses métadonnées au moyen de lectures précisément bornées, avant de transcrire cette reconnaissance dans un prototype direct écrit en Haskell.

Le nom image.iso constitue une hypothèse, non une preuve de format. Une extension est une convention du système de fichiers hôte ; elle ne garantit pas le contenu du fichier. Nous allons donc rechercher une structure définie par ISO 9660, lire plusieurs champs précis, puis reconnaître deux informations supplémentaires : un marqueur Joliet et un enregistrement propre aux disques PlayStation 3.

Notre périmètre restera strictement en lecture seule. Nous ne monterons pas l’image, ne parcourrons aucun répertoire, n’extrairons rien, ne déchiffrerons rien et n’écrirons aucun octet. À la fin, notre prototype affichera seulement :

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

Ces quatre lignes sont un résultat de reconnaissance borné, non un certificat de conformité de l’image entière.

Sommaire

Localiser les métadonnées : de la LBA à l’offset
Reconnaître ISO 9660 dans les octets
Suivre les descripteurs jusqu’au terminateur
Reconnaître Joliet dans un descripteur supplémentaire
Retrouver les indices propres à la PlayStation 3
Construire le probe dans GHCi
Conclusion

Localiser les métadonnées : de la LBA à l’offset

Un fichier binaire est une suite d’octets. Nous appelons offset la position, comptée depuis zéro, d’un octet dans cette suite.

ISO 9660 organise les informations qui nous intéressent en secteurs logiques de 2 048 octets. Une LBA (Logical Block Address, adresse logique de bloc) est le numéro d’un tel secteur : le secteur de LBA 0 commence à l’offset 0, celui de LBA 1 à l’offset 2 048, et ainsi de suite. La formule que nous réutiliserons est :

offset absolu = LBA × taille du secteur + offset relatif du champ

Selon ECMA-119, la norme qui décrit ISO 9660, les secteurs de LBA 0 à 15 forment la System Area, ou zone système. La séquence des descripteurs de volume commence à la LBA 16. La page ISO 9660 d’OSDev fournit une table pratique pour s’orienter ; ECMA-119 demeure la source normative.

Nous commençons par deux constantes Shell :

IMAGE=image.iso # Remplacer au besoin par un chemin absolu vers l’image locale.
SECTOR=2048

Toutes les commandes xxd de cet article emploient -s pour fixer l’offset et -l pour borner la quantité lue. L’option -g 1 sépare les octets à l’affichage. Aucune de ces commandes ne modifie l’image ; nous n’utiliserons notamment jamais xxd -r.

↑ Retour au sommaire

Reconnaître ISO 9660 dans les octets

Un descripteur de volume (Volume Descriptor) est un secteur de métadonnées. La séquence qui les contient commence à la LBA 16 et doit comprendre au moins un descripteur principal de volume (Primary Volume Descriptor). Dans notre image, ce descripteur principal est précisément le premier élément de la séquence.

Tous les descripteurs ISO 9660 commencent par le même en-tête de sept octets. Les offsets de l’article sont comptés depuis zéro ; la colonne « Position ECMA-119 » reprend la numérotation à partir de 1 employée par la norme.

Offset relatif	Position ECMA-119	Taille	Nom canonique du champ	Rôle
0	1	1	`Volume Descriptor Type`	nature du descripteur
1	2 à 6	5	`Standard Identifier`	identifiant `CD001`
6	7	1	`Volume Descriptor Version`	version de la structure

Le descripteur principal occupe exactement 2 048 octets. Sa disposition complète est la suivante. Les champs que notre probe décodera ne sont donc pas les seuls renseignements disponibles dans ce secteur.

Offset relatif	Position ECMA-119	Taille	Nom canonique du champ	Encodage ou fonction
0	1	1	`Volume Descriptor Type`	entier 8 bits, valeur 1
1	2 à 6	5	`Standard Identifier`	caractères `CD001`
6	7	1	`Volume Descriptor Version`	entier 8 bits, valeur 1
7	8	1	`Unused Field`	octet nul
8	9 à 40	32	`System Identifier`	caractères `a`
40	41 à 72	32	`Volume Identifier`	caractères `d`, complétés à largeur fixe
72	73 à 80	8	`Unused Field`	octets nuls
80	81 à 88	8	`Volume Space Size`	entier 32 bits both-endian
88	89 à 120	32	`Unused Field`	octets nuls
120	121 à 124	4	`Volume Set Size`	entier 16 bits both-endian
124	125 à 128	4	`Volume Sequence Number`	entier 16 bits both-endian
128	129 à 132	4	`Logical Block Size`	entier 16 bits both-endian
132	133 à 140	8	`Path Table Size`	entier 32 bits both-endian
140	141 à 144	4	`Location of Occurrence of Type L Path Table`	numéro de bloc, little-endian
144	145 à 148	4	`Location of Optional Occurrence of Type L Path Table`	numéro de bloc, little-endian
148	149 à 152	4	`Location of Occurrence of Type M Path Table`	numéro de bloc, big-endian
152	153 à 156	4	`Location of Optional Occurrence of Type M Path Table`	numéro de bloc, big-endian
156	157 à 190	34	`Directory Record for Root Directory`	enregistrement du répertoire racine
190	191 à 318	128	`Volume Set Identifier`	caractères `d`
318	319 à 446	128	`Publisher Identifier`	caractères `a`
446	447 à 574	128	`Data Preparer Identifier`	caractères `a`
574	575 à 702	128	`Application Identifier`	caractères `a`
702	703 à 739	37	`Copyright File Identifier`	identifiant de fichier
739	740 à 776	37	`Abstract File Identifier`	identifiant de fichier
776	777 à 813	37	`Bibliographic File Identifier`	identifiant de fichier
813	814 à 830	17	`Volume Creation Date and Time`	date et heure décimales
830	831 à 847	17	`Volume Modification Date and Time`	date et heure décimales
847	848 à 864	17	`Volume Expiration Date and Time`	date et heure décimales
864	865 à 881	17	`Volume Effective Date and Time`	date et heure décimales
881	882	1	`File Structure Version`	entier 8 bits
882	883	1	champ réservé	octet nul
883	884 à 1395	512	`Application Use`	contenu non spécifié par ECMA-119
1395	1396 à 2048	653	champ réservé	octets nuls

Les catégories de caractères a et d sont définies par ECMA-119. Elles imposent un répertoire de caractères plus précis que la simple propriété « octet ASCII ». Nous ne décoderons ici que les champs nécessaires au résultat final, mais les offsets du tableau permettent d’examiner les autres sans rechercher de nouveau la disposition générale.

La LBA 16 commence à :

16 × 2 048 = 32 768 = 0x8000

Nous lisons donc exactement ses sept premiers octets :

xxd -g 1 -l 7 -s $((16 * SECTOR)) "$IMAGE"

La sortie observée dans notre image est :

00008000: 01 43 44 30 30 31 01                             .CD001.

Nous pouvons maintenant situer chaque valeur au lieu de reconnaître seulement une chaîne plausible :

00008000 est l’offset absolu affiché en hexadécimal ; 0x8000 vaut bien 32 768 ;
le premier octet, 01, est le type du descripteur ; le type 1 désigne le descripteur principal de volume ;
43 44 30 30 31 est l’encodage ASCII (American Standard Code for Information Interchange) de l’identifiant standard CD001 ;
le dernier 01 est la version commune du descripteur, ici 1.

C’est le type, et non l’octet de version, qui établit la nature principale de ce descripteur. À ce stade, nous avons reconnu un en-tête attendu ; nous n’avons pas validé tout le secteur ni le système de fichiers.

Si une autre image produit des octets différents, la règle réutilisable n’est pas de rechercher visuellement le mot CD001 n’importe où. Il faut retrouver, à l’offset exact de la LBA 16, le triplet structuré « type 1, identifiant CD001, version prise en charge ».

Le champ `Volume Identifier`

Le champ anglais canonique Volume Identifier désigne l’identifiant textuel du volume. Dans le descripteur principal de volume, il commence à l’offset relatif 40 et occupe 32 octets. Sa position absolue vaut donc :

16 × 2 048 + 40 = 32 808 = 0x8028

Nous lisons les 32 octets, sans davantage :

xxd -g 1 -l 32 -s $((16 * SECTOR + 40)) "$IMAGE"

Nous observons :

00008028: 50 53 33 56 4f 4c 55 4d 45 20 20 20 20 20 20 20  PS3VOLUME
00008038: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

Les octets 50 53 33 56 4f 4c 55 4d 45 donnent PS3VOLUME en ASCII. Les octets 20 qui suivent sont des espaces de remplissage jusqu’à la largeur fixe de 32 octets. Pour l’affichage, nous retirerons uniquement ces espaces terminaux. Nous ne supprimerons ni un éventuel espace initial, ni des octets arbitraires qui appartiendraient réellement au champ d’une autre image.

Le champ `Volume Space Size` et ses deux ordres d’octets

Le champ Volume Space Size, à l’offset relatif 80, indique un nombre de blocs logiques, pas encore une taille en octets. ECMA-119 l’enregistre deux fois sur quatre octets : d’abord en little-endian, puis en big-endian.

Ces deux termes décrivent l’ordre des octets d’un entier multioctet. En little-endian, l’octet de poids faible vient en premier ; en big-endian, l’octet de poids fort vient en premier. Nous séparons ici les deux copies afin que leur ordre reste visible :

xxd -g 1 -l 4 -s $((16 * SECTOR + 80)) "$IMAGE"
xxd -g 1 -l 4 -s $((16 * SECTOR + 84)) "$IMAGE"

Les sorties observées sont :

00008050: a0 27 43 00                                      .'C.
00008054: 00 43 27 a0                                      .C'.

La colonne de droite est seulement une tentative de représentation ASCII par xxd ; elle n’a aucune signification pour ce champ numérique.

Pour quatre octets b0 b1 b2 b3, les formules sont :

little-endian = b0 + b1×256 + b2×65 536 + b3×16 777 216
big-endian    = b0×16 777 216 + b1×65 536 + b2×256 + b3

Appliquons-les aux octets réellement lus. La copie little-endian donne :

0xa0 + 0x27×0x100 + 0x43×0x10000 + 0x00×0x1000000
= 0x4327a0

La copie big-endian donne directement la même écriture numérique :

00 43 27 a0 = 0x4327a0

Or 0x4327a0 vaut 4 401 056. Le volume annonce donc 4 401 056 blocs logiques. Sur une autre image, il faut appliquer les mêmes formules à ses propres octets, puis comparer les deux résultats. Un lecteur ne choisit pas la copie qui paraît la plus vraisemblable : leur désaccord constitue une incohérence du champ both-endian.

Le champ `Logical Block Size`

Il nous manque la taille d’un bloc logique. Le champ Logical Block Size se trouve à l’offset relatif 128. Il occupe quatre octets : une copie little-endian de deux octets, puis une copie big-endian de deux octets.

xxd -g 1 -l 2 -s $((16 * SECTOR + 128)) "$IMAGE"
xxd -g 1 -l 2 -s $((16 * SECTOR + 130)) "$IMAGE"

Nous observons :

00008080: 00 08                                            ..
00008082: 08 00                                            ..

Pour deux octets b0 b1 :

little-endian = b0 + b1×256
big-endian    = b0×256 + b1

La première copie, 00 08, vaut donc 0x00 + 0x08×0x100 = 0x0800. La seconde, 08 00, vaut également 0x0800. En décimal, 0x0800 vaut 2 048 octets par bloc logique.

Nous pouvons désormais reconstruire la taille annoncée de l’espace du volume :

4 401 056 × 2 048 = 9 013 362 688 octets

Comparons cette valeur à la longueur du fichier hôte, toujours sans le modifier :

ls -l "$IMAGE"

La sortie observée est :

-rw-r--r--@ 1 kdridi  staff  9013362688 Sep  2 02:02 image.iso

Pour cet échantillon, la longueur du fichier est exactement égale à l’espace annoncé. C’est un contrôle de cohérence utile, pas une égalité universelle : un conteneur peut ajouter du remplissage ou des données après le volume. Dans le modèle direct que nous utilisons ici, un fichier plus court que l’espace annoncé serait en revanche insuffisant pour contenir ce volume.

Le résultat dépasse 4 Gio (gibioctets). Notre code Haskell devra donc convertir les deux facteurs vers un entier suffisamment large avant de les multiplier ; un entier limité à 32 bits ne convient pas à ce calcul.

↑ Retour au sommaire

Suivre les descripteurs jusqu’au terminateur

Le secteur de LBA 16 n’est que le début d’une séquence. ISO 9660 autorise d’autres descripteurs dans les secteurs suivants et marque la fin de l’ensemble par un terminateur de séquence de descripteurs de volume (Volume Descriptor Set Terminator) de type 255.

Le premier octet de l’en-tête commun détermine la nature de chaque secteur de métadonnées :

Valeur du type	Nom canonique	Fonction
0	`Boot Record`	informations destinées à un système d’amorçage
1	`Primary Volume Descriptor`	description principale du volume et d’une arborescence
2	`Supplementary Volume Descriptor` ou `Enhanced Volume Descriptor`	description d’une arborescence supplémentaire ; la version distingue les deux formes
3	`Volume Partition Descriptor`	description d’une partition du volume
4 à 254	réservé	aucune interprétation normalisée ici
255	`Volume Descriptor Set Terminator`	fin de la séquence

Le terminateur possède lui-même une disposition complète particulièrement simple :

Offset relatif	Taille	Nom canonique du champ	Valeur
0	1	`Volume Descriptor Type`	255
1	5	`Standard Identifier`	`CD001`
6	1	`Volume Descriptor Version`	1
7	2 041	champ réservé	octets nuls

Puisque les descripteurs occupent chacun un secteur et sont contigus à partir de la LBA 16, les sept octets que nous lirons à chaque itération se répartissent toujours ainsi :

Offset absolu pour la LBA `n`	Taille	Champ lu
`n × 2 048 + 0`	1	`Volume Descriptor Type`
`n × 2 048 + 1`	5	`Standard Identifier`
`n × 2 048 + 6`	1	`Volume Descriptor Version`

Pour observer les deux secteurs suivants :

for n in $(seq 17 18)
do
    xxd -g 1 -l 7 -s $(($n * SECTOR)) "$IMAGE"
done

La sortie observée est :

00008800: 02 43 44 30 30 31 01                             .CD001.
00009000: ff 43 44 30 30 31 01                             .CD001.

En réunissant l’en-tête déjà lu à la LBA 16 et les deux premiers résultats de cette boucle, nous obtenons la séquence ISO 9660 suivante :

LBA	Offset absolu	Sept premiers octets	Interprétation
16	`0x8000`	`01 43 44 30 30 31 01`	descripteur principal, `CD001`, version 1
17	`0x8800`	`02 43 44 30 30 31 01`	descripteur supplémentaire, `CD001`, version 1
18	`0x9000`	`ff 43 44 30 30 31 01`	terminateur, `CD001`, version 1

À la LBA 17, 02 CD001 01 est l’en-tête d’un descripteur supplémentaire de volume (Supplementary Volume Descriptor). À la LBA 18, ff CD001 01 est le terminateur. La séquence ISO 9660 de notre image comprend donc, dans l’ordre observé, le descripteur principal à la LBA 16, un descripteur supplémentaire à la LBA 17 et le terminateur à la LBA 18.

Cette commande d’observation connaissait déjà les deux LBA à lire. Un scanner ISO 9660 général, lui, doit commencer à la LBA 16, avancer secteur par secteur, contrôler l’identifiant et la version, puis s’arrêter immédiatement au type 255. Il lui faut aussi une borne défensive : une image mal formée ne doit pas provoquer une lecture indéfinie si le terminateur manque.

↑ Retour au sommaire

Reconnaître Joliet dans un descripteur supplémentaire

Le type 2 ne signifie pas à lui seul « Joliet ». ECMA-119 définit un descripteur supplémentaire générique. La version 1 désigne le descripteur supplémentaire étudié ici ; la version 2 désigne un descripteur amélioré (Enhanced Volume Descriptor).

Le descripteur supplémentaire conserve l’essentiel de la disposition du descripteur principal, mais ajoute les informations nécessaires à l’interprétation de ses champs textuels. Voici sa structure complète :

Offset relatif	Taille	Nom canonique du champ	Différence ou fonction principale
0	1	`Volume Descriptor Type`	valeur 2
1	5	`Standard Identifier`	caractères `CD001`
6	1	`Volume Descriptor Version`	1 pour la forme supplémentaire, 2 pour la forme améliorée
7	1	`Volume Flags`	propriétés des séquences d’échappement
8	32	`System Identifier`	caractères interprétés selon la forme du descripteur
40	32	`Volume Identifier`	caractères `d1` dans la forme supplémentaire
72	8	`Unused Field`	octets nuls
80	8	`Volume Space Size`	entier 32 bits both-endian
88	32	`Escape Sequences`	désignation des jeux de caractères
120	4	`Volume Set Size`	entier 16 bits both-endian
124	4	`Volume Sequence Number`	entier 16 bits both-endian
128	4	`Logical Block Size`	entier 16 bits both-endian
132	8	`Path Table Size`	entier 32 bits both-endian
140	4	`Location of Occurrence of Type L Path Table`	numéro de bloc, little-endian
144	4	`Location of Optional Occurrence of Type L Path Table`	numéro de bloc, little-endian
148	4	`Location of Occurrence of Type M Path Table`	numéro de bloc, big-endian
152	4	`Location of Optional Occurrence of Type M Path Table`	numéro de bloc, big-endian
156	34	`Directory Record for Root Directory`	enregistrement du répertoire racine de cette arborescence
190	128	`Volume Set Identifier`	caractères `d1`
318	128	`Publisher Identifier`	caractères `a1`
446	128	`Data Preparer Identifier`	caractères `a1`
574	128	`Application Identifier`	caractères `a1`
702	37	`Copyright File Identifier`	identifiant de fichier en caractères `d1`
739	37	`Abstract File Identifier`	identifiant de fichier en caractères `d1`
776	37	`Bibliographic File Identifier`	identifiant de fichier en caractères `d1`
813	17	`Volume Creation Date and Time`	date et heure décimales
830	17	`Volume Modification Date and Time`	date et heure décimales
847	17	`Volume Expiration Date and Time`	date et heure décimales
864	17	`Volume Effective Date and Time`	date et heure décimales
881	1	`File Structure Version`	entier 8 bits
882	1	champ réservé	octet nul
883	512	`Application Use`	contenu non spécifié par ECMA-119
1395	653	champ réservé	octets nuls

La section 8.5.6 d’ECMA-119 place donc le champ Escape Sequences à l’offset relatif 88, sur 32 octets. Ce champ sert à désigner des jeux de caractères ; il ne contient pas nécessairement le nom d’une extension.

La spécification historique Microsoft Joliet utilise précisément ce mécanisme pour décrire un ensemble de fichiers dont les noms emploient UCS-2. UCS-2 (Universal Character Set, 2-byte form) est un codage historique fondé sur des unités de code de 16 bits. Nous devons donc examiner le champ avant de classifier le descripteur.

Son offset absolu est :

17 × 2 048 + 88 = 34 904 = 0x8858

Cette arithmétique permet notamment d’éviter une erreur de transcription entre les offsets relatifs 87 et 88. Lisons le champ complet :

xxd -g 1 -l 32 -s $((17 * SECTOR + 88)) "$IMAGE"

Nous observons :

00008858: 25 2f 40 00 00 00 00 00 00 00 00 00 00 00 00 00  %/@.............
00008868: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Les trois premiers octets, 25 2f 40, représentent %/@ en ASCII ; les 29 octets suivants sont nuls.

La chaîne documentaire qui donne son sens à cette observation mérite d’être conservée. ISO 2022 définit un mécanisme de désignation des jeux de caractères. ISO 2375 en organise l’enregistrement, et le registre ISO-IR associe des séquences complètes à trois niveaux d’UCS-2 :

Registre	Jeu de caractères	Séquence complète enregistrée
ISO-IR 162	UCS-2 niveau 1	`ESC 25 2F 40`
ISO-IR 174	UCS-2 niveau 2	`ESC 25 2F 43`
ISO-IR 176	UCS-2 niveau 3	`ESC 25 2F 45`

ESC désigne ici l’octet de contrôle d’échappement. Ces enregistrements datent de 1992 et 1993, avant la publication de Joliet en 1995. Le champ du descripteur supplémentaire contient les trois octets qui suivent ESC ; Microsoft n’a donc pas inventé une étiquette privée appelée « Joliet », mais a sélectionné des identifiants de jeux de caractères déjà enregistrés.

La spécification Joliet associe ces valeurs aux niveaux suivants :

Valeur dans le champ	Niveau Joliet
`%/@`	1
`%/C`	2
`%/E`	3

Dans notre image, %/@ constitue donc un marqueur Joliet de niveau 1. Cette conclusion reste étroite : le marqueur indique comment interpréter le descripteur et l’arborescence qui lui est associée, mais il ne prouve pas que cette arborescence entière respecte Joliet. Il faudrait la parcourir et la valider pour l’affirmer, ce que nous ne ferons pas dans cet article.

Un lecteur général devrait également définir une politique pour d’autres séquences enregistrées. Notre probe reconnaîtra seulement %/@, %/C et %/E. Une autre valeur restera le champ d’un descripteur supplémentaire reconnu, avec un jeu de caractères non pris en charge ; elle ne sera ni devinée ni silencieusement reclassée.

↑ Retour au sommaire

Retrouver les indices propres à la PlayStation 3

Les seize premiers secteurs sont réservés par ISO 9660 à la zone système, mais ECMA-119 ne définit pas la disposition PlayStation 3 que nous y observons. Aucune spécification publique Sony normative de ces champs n’a été identifiée. Leur interprétation repose sur la convergence d’implémentations indépendantes — notamment RPCS3 et ps3netsrv — ainsi que sur l’observation de notre image. Ce sont des preuves d’implémentation non normatives, pas une norme Sony.

Les 512 premiers octets du secteur 1 suivent la disposition observée et corroborée ci-dessous. Le reste de ce secteur est nul dans notre image ; cette dernière propriété reste une observation locale.

Offset relatif	Taille	Contenu ou fonction	Statut dans cet article
`0x000`	`0x010` (16)	`PlayStation3` suivi de quatre octets nuls	reconnu par le probe
`0x010`	`0x020` (32)	identifiant produit complété par des espaces	reconnu par le probe
`0x030`	`0x010` (16)	octets nuls	observé, non utilisé
`0x040`	`0x1b0` (432)	informations de disque dont la sémantique n’est pas établie ici	opaque
`0x1f0`	`0x010` (16)	valeur opaque décrite comme un hachage par `ps3netsrv`	opaque
`0x200`	`0x600` (1 536)	fin du secteur, nulle dans l’image étudiée	observation locale

Le marqueur de plateforme

À la LBA 1, nous lisons d’abord un champ de 16 octets :

xxd -g 1 -l 16 -s $((1 * SECTOR)) "$IMAGE"

La sortie réelle est :

00000800: 50 6c 61 79 53 74 61 74 69 6f 6e 33 00 00 00 00  PlayStation3....

Les douze premiers octets codent PlayStation3 en ASCII ; quatre octets nuls complètent le champ. Nous parlons d’un champ de 16 octets, non d’un texte arbitraire de 16 caractères.

L’identifiant produit

Le champ adjacent commence 16 octets plus loin et en occupe 32 :

xxd -g 1 -l 32 -s $((1 * SECTOR + 16)) "$IMAGE"

Nous observons :

00000810: 42 4c 45 53 2d 30 30 39 33 32 20 20 20 20 20 20  BLES-00932
00000820: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

Les dix premiers octets donnent BLES-00932 ; vingt-deux espaces complètent le champ. Notre reconnaissance minimale exigera le marqueur PlayStation3 complet, puis retirera seulement les espaces terminaux de l’identifiant produit. Cette combinaison suffit à la ligne que nous voulons rapporter, mais ne valide pas toutes les structures propres à un disque PlayStation 3.

↑ Retour au sommaire

Construire le probe dans GHCi

Nous avons maintenant une suite précise de règles à transcrire. GHCi est l’interpréteur interactif de Glasgow Haskell Compiler : il permet de saisir des définitions Haskell et d’en voir immédiatement le résultat. Nous allons y construire un prototype direct, sans infrastructure générale de décodage binaire.

Depuis le même terminal, nous rendons le chemin accessible au processus, puis lançons GHCi avec le paquet bytestring :

export IMAGE="${IMAGE:-image.iso}"
ghci -package bytestring

L’invite ressemble à :

ghci>

Un ByteString est une suite compacte d’octets. Nous utiliserons sa variante stricte parce que chacune de nos lectures est petite et bornée. Les interfaces employées sont documentées dans System.IO, Data.ByteString et Data.Word.

Saisie multiligne dans GHCi. Les blocs qui suivent sont présentés comme du code Haskell ordinaire, sans commandes propres à l’interpréteur. Pour saisir une définition multiligne directement dans GHCi, commencez par entrer :{ sur une ligne isolée, saisissez ou collez la définition, puis terminez par :}, également sur une ligne isolée. Ces deux commandes sont volontairement omises des blocs afin de ne pas les confondre avec la syntaxe du langage Haskell.

Octets bruts, puis décodage endian

Commençons par les imports communs :

import Control.Monad (unless, when)
import Data.Bits (Bits, shiftL, (.|.))
import qualified Data.ByteString as BS
import qualified Data.ByteString.Char8 as BSC
import Data.Word (Word8, Word16, Word32)
import System.Environment (getEnv)
import System.IO (Handle, IOMode(ReadMode), SeekMode(AbsoluteSeek), hFileSize, hSeek, withBinaryFile)

Avant toute entrée-sortie, reprenons quatre octets synthétiques. Leur type ne leur attribue encore ni signification ni ordre :

let rawBytes = BS.pack [0x00, 0x00, 0x00, 0x03]
BS.unpack rawBytes

GHCi affiche :

[0,0,0,3]

L’endianness n’est pas une propriété du ByteString ni un mode de lecture du fichier. C’est une règle du champ que nous sommes en train de décoder. Nous définissons deux transformations privées :

-- Décode un champ big-endian dont l’appelant a déjà contrôlé la largeur.
decodeBE :: (Bits a, Num a) => BS.ByteString -> a
decodeBE =
    BS.foldl'
        (\acc byte -> shiftL acc 8 .|. fromIntegral byte)
        0

-- Même opération pour un champ little-endian.
decodeLE :: (Bits a, Num a) => BS.ByteString -> a
decodeLE =
    BS.foldr'
        (\byte acc -> shiftL acc 8 .|. fromIntegral byte)
        0

La même suite brute donne des valeurs différentes selon l’interprétation :

decodeBE rawBytes :: Word32
decodeLE rawBytes :: Word32

Résultat :

3
50331648

50331648 vaut 0x03000000. Le format, et non une préférence du programmeur, détermine quel décodeur convient. Ces fonctions n’imposent pas elles-mêmes une largeur ; dans ce prototype, cette garantie appartient à la frontière de lecture qui les précède.

Une lecture exacte et bornée

BS.hGet peut renvoyer moins d’octets que demandé si la fin du fichier survient. Nous devons contrôler la longueur avant tout BS.index ou décodage. Les offsets restent des Integer, afin de ne pas limiter artificiellement l’adressage aux fichiers de moins de 4 Gio.

sectorSize :: Integer
sectorSize = 2048

-- Centralise les lectures bornées et refuse tout résultat partiel.
readExactlyAt :: Handle -> Integer -> Int -> IO BS.ByteString
readExactlyAt handle offset width
    | offset < 0 = ioError (userError "negative read offset")
    | width < 0  = ioError (userError "negative read width")
    | otherwise  = do
        hSeek handle AbsoluteSeek offset
        bytes <- BS.hGet handle width
        if BS.length bytes == width
            then pure bytes
            else ioError
                (userError
                    ("short read at offset " <> show offset
                        <> ": expected " <> show width
                        <> " bytes, got " <> show (BS.length bytes)))

ReadMode exprime l’intention de lecture seule. withBinaryFile referme le handle même si une exception survient. Vérifions cette frontière avec les sept octets déjà observés :

imageFile <- getEnv "IMAGE"

headerBytes <- withBinaryFile imageFile ReadMode $ \handle ->
    readExactlyAt handle (16 * sectorSize) 7

BS.length headerBytes
BS.unpack headerBytes

Nous retrouvons :

7
[1,67,68,48,48,49,1]

Les décimaux 67 68 48 48 49 sont les codes ASCII de CD001. Si GHCi affiche parfois un ByteString textuel sous la forme "\SOHCD001\SOH", SOH n’est pas un octet ajouté : c’est le nom d’affichage du caractère de contrôle 0x01.

Décoder les champs utiles du descripteur principal

Nous donnons maintenant un type aux trois composants de l’en-tête, puis un type aux trois informations ISO que notre lecture conservera :

-- Représente l’en-tête commun de sept octets des descripteurs ISO 9660.
data DescriptorHeader = DescriptorHeader
    { headerType       :: Word8
    , headerIdentifier :: BS.ByteString
    , headerVersion    :: Word8
    }
    deriving (Eq, Show)

-- Conserve uniquement les champs du descripteur principal utiles au probe.
data IsoInfo = IsoInfo
    { isoVolumeIdentifier :: BS.ByteString
    , isoVolumeSpaceSize  :: Word32
    , isoLogicalBlockSize :: Word16
    }
    deriving (Eq, Show)

-- Précondition : la largeur de l’en-tête a été contrôlée en amont.
decodeDescriptorHeader :: BS.ByteString -> DescriptorHeader
decodeDescriptorHeader bytes =
    DescriptorHeader
        { headerType = BS.index bytes 0
        , headerIdentifier = BS.take 5 (BS.drop 1 bytes)
        , headerVersion = BS.index bytes 6
        }

decodeDescriptorHeader emploie BS.index, qui serait partiel sur une entrée trop courte. Il reste privé et ne reçoit ici que des données dont la largeur a déjà été vérifiée par readExactlyAt.

La fonction suivante lit exactement le secteur de 2 048 octets à la LBA 16, contrôle son en-tête, découpe les trois champs, décode séparément les deux copies numériques et vérifie leur égalité. Pour le contrôle de cohérence avec le fichier hôte, elle refuse seulement une longueur insuffisante ; elle accepte d’éventuelles données terminales.

-- Lit et valide le sous-ensemble du descripteur principal nécessaire au probe.
readPrimaryVolumeDescriptor :: Handle -> IO IsoInfo
readPrimaryVolumeDescriptor handle = do
    descriptor <- readExactlyAt handle (16 * sectorSize) 2048
    let header = decodeDescriptorHeader descriptor

    unless
        (headerType header == 1
            && headerIdentifier header == BSC.pack "CD001"
            && headerVersion header == 1)
        (ioError (userError "no supported Primary Volume Descriptor at LBA 16"))

    let volumeField = BS.take 32 (BS.drop 40 descriptor)
        spaceField  = BS.take 8  (BS.drop 80 descriptor)
        blockField  = BS.take 4  (BS.drop 128 descriptor)

        (spaceLEBytes, spaceBEBytes) = BS.splitAt 4 spaceField
        (blockLEBytes, blockBEBytes) = BS.splitAt 2 blockField

        spaceLE = decodeLE spaceLEBytes :: Word32
        spaceBE = decodeBE spaceBEBytes :: Word32
        blockLE = decodeLE blockLEBytes :: Word16
        blockBE = decodeBE blockBEBytes :: Word16

    unless (spaceLE == spaceBE)
        (ioError (userError "inconsistent Volume Space Size copies"))
    unless (blockLE == blockBE)
        (ioError (userError "inconsistent Logical Block Size copies"))
    when (blockLE == 0)
        (ioError (userError "zero Logical Block Size"))

    hostSize <- hFileSize handle
    let declaredSize = toInteger spaceLE * toInteger blockLE
    when (hostSize < declaredSize)
        (ioError
            (userError
                ("truncated image: declared " <> show declaredSize
                    <> " bytes, host file has " <> show hostSize)))

    pure
        IsoInfo
            { isoVolumeIdentifier = BSC.dropWhileEnd (== ' ') volumeField
            , isoVolumeSpaceSize = spaceLE
            , isoLogicalBlockSize = blockLE
            }

Exécutons ce bloc sur l’image :

isoInfo <- withBinaryFile imageFile ReadMode readPrimaryVolumeDescriptor
isoInfo

La sortie importante rassemble les valeurs reconstruites dans le Shell :

IsoInfo {isoVolumeIdentifier = "PS3VOLUME", isoVolumeSpaceSize = 4401056, isoLogicalBlockSize = 2048}

Ce résultat signifie que les contrôles explicitement codés ont réussi. Il ne prétend pas valider les nombreux champs du descripteur que nous n’avons pas lus.

Parcourir directement et sans débordement la séquence ISO 9660

Nous généralisons maintenant la lecture des sept octets d’en-tête à une LBA quelconque. Le scanner part de 16, exige CD001 et la version 1 à chaque étape, inclut le terminateur dans son résultat et s’y arrête. La limite de 64 descripteurs est un choix défensif du probe : elle transforme l’absence de terminateur proche en erreur au lieu de poursuivre sans borne.

-- Retrouve l’en-tête situé à une LBA donnée.
readDescriptorHeader :: Handle -> Integer -> IO DescriptorHeader
readDescriptorHeader handle lba =
    decodeDescriptorHeader
        <$> readExactlyAt handle (lba * sectorSize) 7

-- Parcourt au plus 64 descripteurs et s’arrête au terminateur de type 255.
scanIsoSequence :: Handle -> IO [(Integer, DescriptorHeader)]
scanIsoSequence handle = go 16 64 []
  where
    go lba remaining accumulated
        | remaining == 0 =
            ioError (userError "ISO descriptor scan limit reached")
        | otherwise = do
            header <- readDescriptorHeader handle lba
            unless
                (headerIdentifier header == BSC.pack "CD001"
                    && headerVersion header == 1)
                (ioError
                    (userError
                        ("invalid ISO descriptor header at LBA " <> show lba)))

            let located = (lba, header)
            if headerType header == 255
                then pure (reverse (located : accumulated))
                else go (lba + 1) (remaining - 1) (located : accumulated)

Nous n’avons plus à connaître d’avance le nombre de descripteurs :

descriptors <- withBinaryFile imageFile ReadMode scanIsoSequence
map (\(lba, header) -> (lba, headerType header)) descriptors

Nous obtenons :

[(16,1),(17,2),(18,255)]

Le secteur 19 n’est jamais consommé par ce scanner ISO 9660. C’est exactement la différence observée entre la boucle Shell exploratoire et la règle du format.

Examiner tous les descripteurs supplémentaires et classifier Joliet

ECMA-119 autorise zéro ou plusieurs descripteurs supplémentaires. Sélectionner seulement le premier serait donc une hypothèse injustifiée. Nous lisons le champ Escape Sequences complet de chacun d’eux et conservons aussi les valeurs que notre petit probe ne sait pas classifier.

data JolietLevel
    = JolietLevel1
    | JolietLevel2
    | JolietLevel3
    deriving (Eq, Show)

data SupplementaryFinding
    = JolietFinding Integer JolietLevel
    | UnsupportedCharacterSet Integer BS.ByteString
    deriving (Eq, Show)

-- Classe le marqueur Joliet sans perdre les champs non pris en charge.
classifySupplementary
    :: Integer
    -> BS.ByteString
    -> SupplementaryFinding
classifySupplementary lba field =
    let prefix = BS.take 3 field
        zeroPadding = BS.all (== 0) (BS.drop 3 field)
        level
            | prefix == BSC.pack "%/@" = Just JolietLevel1
            | prefix == BSC.pack "%/C" = Just JolietLevel2
            | prefix == BSC.pack "%/E" = Just JolietLevel3
            | otherwise                 = Nothing
    in case (level, zeroPadding) of
        (Just jolietLevel, True) -> JolietFinding lba jolietLevel
        _ -> UnsupportedCharacterSet lba field

-- Examine tous les descripteurs de type 2, pas seulement le premier.
readSupplementaryFindings
    :: Handle
    -> [(Integer, DescriptorHeader)]
    -> IO [SupplementaryFinding]
readSupplementaryFindings handle allDescriptors =
    mapM readOne supplementaryLbas
  where
    supplementaryLbas =
        [ lba
        | (lba, header) <- allDescriptors
        , headerType header == 2
        ]

    readOne lba = do
        field <- readExactlyAt handle (lba * sectorSize + 88) 32
        pure (classifySupplementary lba field)

Appliquons cette lecture à tous les candidats trouvés :

supplementaryFindings <- withBinaryFile imageFile ReadMode $ \handle ->
    readSupplementaryFindings handle descriptors

supplementaryFindings

La sortie situe le résultat autant qu’elle le classe :

[JolietFinding 17 JolietLevel1]

Le constructeur UnsupportedCharacterSet évite de transformer une séquence inconnue en absence de descripteur. Quant à JolietFinding, il atteste seulement le marqueur, jamais la conformité de l’arborescence.

Reconnaître le minimum propre à la PlayStation 3

Pour produire l’identifiant produit, 48 octets suffisent : le champ marqueur de 16 octets, puis le champ produit de 32 octets.

-- Rapporte l’identifiant produit uniquement si le marqueur PS3 est exact.
readPs3ProductId :: Handle -> IO (Maybe BS.ByteString)
readPs3ProductId handle = do
    fields <- readExactlyAt handle sectorSize 48
    let marker = BS.take 16 fields
        productField = BS.drop 16 fields
        expectedMarker =
            BSC.pack "PlayStation3" <> BS.replicate 4 0

    pure
        (if marker == expectedMarker
            then Just (BSC.dropWhileEnd (== ' ') productField)
            else Nothing)

Exécutons-la :

ps3ProductId <- withBinaryFile imageFile ReadMode readPs3ProductId
ps3ProductId

Nous retrouvons :

Just "BLES-00932"

Nothing signifierait seulement que ce marqueur d’implémentation n’a pas été reconnu. Cela ne suffirait pas à classifier universellement l’entrée comme « non-PlayStation 3 ».

Agréger les observations et les rendre dans un ordre stable

Il reste à ouvrir l’image une fois, à effectuer les lectures précédentes par offsets absolus, puis à construire les lignes reconnues. La structure finale conserve les descripteurs supplémentaires non pris en charge, même si le rendu demandé n’émet que les niveaux Joliet reconnus.

-- Réunit les observations indépendantes avant leur rendu textuel.
data ProbeResult = ProbeResult
    { resultPs3ProductId       :: Maybe BS.ByteString
    , resultIso9660            :: IsoInfo
    , resultSupplementary      :: [SupplementaryFinding]
    }
    deriving (Eq, Show)

-- Ouvre l’image une seule fois, en lecture seule, pour toutes les lectures.
probe :: FilePath -> IO ProbeResult
probe path =
    withBinaryFile path ReadMode $ \handle -> do
        isoDescriptors <- scanIsoSequence handle
        recognizedIso <- readPrimaryVolumeDescriptor handle
        supplementary <-
            readSupplementaryFindings handle isoDescriptors
        productId <- readPs3ProductId handle
        pure
            ProbeResult
                { resultPs3ProductId = productId
                , resultIso9660 = recognizedIso
                , resultSupplementary = supplementary
                }

renderJolietLevel :: JolietLevel -> String
renderJolietLevel JolietLevel1 = "1"
renderJolietLevel JolietLevel2 = "2"
renderJolietLevel JolietLevel3 = "3"

-- Produit uniquement les lignes reconnues, dans un ordre stable.
renderProbeResult :: ProbeResult -> [String]
renderProbeResult result =
    maybe
        []
        (\productId ->
            ["ps3.product-id=" <> BSC.unpack productId])
        (resultPs3ProductId result)
    ++ [ "iso9660.volume-id="
            <> BSC.unpack
                (isoVolumeIdentifier (resultIso9660 result))
       , "iso9660.logical-block-size="
            <> show (isoLogicalBlockSize (resultIso9660 result))
       ]
    ++ [ "joliet.level=" <> renderJolietLevel level
       | JolietFinding _ level <- resultSupplementary result
       ]

Lançons enfin le probe et son rendu :

result <- probe imageFile
mapM_ putStrLn (renderProbeResult result)

La sortie est exactement :

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

↑ Retour au sommaire

Conclusion

La première ligne repose sur un marqueur et une disposition de champs corroborés par plusieurs implémentations PlayStation 3 non normatives. Les deuxième et troisième lignes proviennent de champs précis du descripteur principal de volume ISO 9660, après contrôle de l’en-tête, des deux copies endian et de la taille minimale du fichier. La quatrième rapporte un marqueur Joliet de niveau 1 trouvé dans l’unique descripteur supplémentaire observé, après parcours borné de toute la séquence ISO 9660.

Elles ne prouvent ni la conformité complète à ISO 9660 ou Joliet, ni la validité des répertoires et des noms UCS-2, ni l’état de chiffrement de l’image. Elles n’autorisent encore aucun parcours de répertoire, aucune extraction, aucun déchiffrement et aucune écriture. Elles disent seulement que quatre informations ont été reconnues selon les règles et les limites que nous avons rendues explicites.

Notre code direct révèle enfin une répétition concrète : plusieurs lectures fixes reviennent à combiner un offset, une largeur et une opération de décodage, puis à interpréter le résultat. Un prochain article technique pourra partir de cette duplication observée — non d’une abstraction décidée à l’avance — pour étudier comment décrire ces opérations et leur donner plusieurs interprétations plus générales.

↑ Retour au sommaire

DEV Community: Karim DRIDI

Hexegesis : construction d’un programme PlayStation 3 minimal

Construire un cas minimal et reproductible

Sommaire

Le résultat attendu

PS3_GAME/USRDIR/EBOOT.BIN — le programme

PS3_GAME/PARAM.SFO — les paramètres du jeu

PS3_DISC.SFB — le descripteur du support

Construire l’image Docker

Créer les paramètres du jeu : PARAM.SFO

Déclarer les paramètres

Produire le fichier binaire

Créer le descripteur de disque minimal : PS3_DISC.SFB

Compiler le programme et créer EBOOT.BIN

Compiler le code C et produire l’ELF PPU

Transformer l’ELF en SELF

Vérifier le répertoire de jeu dans RPCS3

Créer une image ISO 9660

Ajouter la table de régions PS3

Bilan

Hexegesis : questions fréquentes

Faut-il connaître Haskell ?

Faut-il posséder Demon’s Souls ?

Les fichiers des jeux ou des mods seront-ils publiés ?

Pourquoi utiliser des outils existants si Hexegesis doit les remplacer ?

Comment connaître les formats pris en charge par Hexegesis ?

La feuille de route est-elle définitive ?

Hexegesis : sommaire de la série

Présentation et références

Articles publiés

Applications au corpus

Fondations reproductibles

Prochaine application envisagée

Directions de travail

Hexegesis : projet de modding des jeux FromSoftware en Haskell

Sommaire

Une première modification visible dans RPCS3

L’ambition d’une BusyBox du modding

Pourquoi Demon’s Souls sur PlayStation 3 ?

Pourquoi Haskell ?

Du besoin à l’implémentation minimale

Écrire pour apprendre

Pourquoi écrire en français ?

Reproductibilité et corpus commercial

Fondations reproductibles

Applications au corpus

Hexegesis : sonder une ISO PlayStation 3 en Haskell

Sommaire

Localiser les métadonnées : de la LBA à l’offset

Reconnaître ISO 9660 dans les octets

Le champ Volume Identifier

Le champ Volume Space Size et ses deux ordres d’octets

Le champ Logical Block Size

Suivre les descripteurs jusqu’au terminateur

Reconnaître Joliet dans un descripteur supplémentaire

Retrouver les indices propres à la PlayStation 3

Le marqueur de plateforme

L’identifiant produit

Construire le probe dans GHCi

Octets bruts, puis décodage endian

Une lecture exacte et bornée

Décoder les champs utiles du descripteur principal

Parcourir directement et sans débordement la séquence ISO 9660

Examiner tous les descripteurs supplémentaires et classifier Joliet

Reconnaître le minimum propre à la PlayStation 3

Agréger les observations et les rendre dans un ordre stable

Conclusion

`PS3_GAME/USRDIR/EBOOT.BIN` — le programme

`PS3_GAME/PARAM.SFO` — les paramètres du jeu

`PS3_DISC.SFB` — le descripteur du support

Créer les paramètres du jeu : `PARAM.SFO`

Créer le descripteur de disque minimal : `PS3_DISC.SFB`

Compiler le programme et créer `EBOOT.BIN`

Le champ `Volume Identifier`

Le champ `Volume Space Size` et ses deux ordres d’octets

Le champ `Logical Block Size`