GCM (File format)

← Gotcha Force

The GameCube mini DVD use GCM file format (Gamecube Disk Image - extension gcm or iso) and can be in 6 blocks :

• boot.bin (Base Informations - Disk Header)
• bi2.bin (Additionnal informations - debug, locales - Disk Header Information)
• apploader.img (Loader of the main executable)
• fst.bin (FileStringTable)
• boot.dol / elf (Main executable)
• Files and Folders tree

The file system is handled by GameCube itself, and we can see that files are loaded by names no matter in which order the have been stored (Dolphin Emulator).

The dol file and FST are stored after de apploader.img dol after FST or FST after dol. Most of the time dol is before FST. All GCM ROMs have a mini DVD fixed length : 1 459 978 240 bytes. Because of that there is often empty spaces between files in the game released containing junk datas or old values partially overide by new ones during devs. This empty spaces contains useless information of the game. It could be used for mini DVD cyphering hardening . The question could be "does this junks data sames at all released mini DVD of the game? An intersting thing is that burning data at the out border of the DVD increase performances when hardware read head access to it.

GCM/ISO format Architecture

boot.bin

boot.bin file is at beginning of the mini DVD and its length is 0x440 bytes. We found on it:

• 0 - 4 bytes ascii - GameCode - A-Za-z0-9
• 4 - 2 bytes ascii - MakerCode - A-Za-z0-9
• 6 - 1 bytes - DiskNumber - beginning at 0 - 0-98
• 7 - 1 bytes - Version - 0-99
• 8 - 1 bytes - AudioStreaming - flag (0 ou 1)
• 9 - 1 bytes - StreamBufferSize - streaming buffers count - 0-15
• 0x1c - 4 bytes - DVDMagic - 0xc2339f3d
• 0x20 - 0x40 bytes - GameName can containc kanjis
• 0x420 - 4 bytes - DolOffset
• 0x424 - 4 bytes - FstOffset
• 0x428 - 4 bytes - FstLen
• 0x42c - 4 bytes - FstMaxLen - correspond often to the FST len but it's the space reserved for others mini DVDs FST length
• 0x430 - 4 bytes - FST memory address?
• 0x434 - 4 bytes - UserPosition - correspond to the offset on mini DVD where begin first game files
• 0x438 - 4 bytes - UserLength - correspond to the total length where we found all files (could contains empty junk spaces)

bi2.bin

bi2.bin files has a length of 0x2000 bytes and reside just after boot.bin (offset 0x440 of the GCM). It contains locales informations and debug configurations.

• 0 - 4 bytes - DebugMonitorSize
• 4 - 4 bytes - SimulatedMemorySize
• 8 - 4 bytes - ArgumentOffset
• 0xc - 4 bytes - DebugFlag - 0 pour tout debugueur sur GDEV; 3 pour CodeWarrior sur EV
• 0x10 - 4 bytes - TrackLocation - Il faut vérifier s'il ne sagit pas de MetroTRK (dans certaines dokus)
• 0x14 - 4 bytes - TrackSize - Il faut vérifier s'il ne sagit pas de MetroTRK (dans certaines dokus)
• 0x18 - 4 bytes - CountryCode - 0 pour Japon, 1 pour USA, 2 pour PAL, 4 pour Corée du Sud
• 0x1c - 4 bytes - TotalDisk - nombre total de disk <= 99
• 0x20 - 4 bytes - LongFileNameSupport - 1 = support, 0 = contraindre au format 8.3
• 0x24 - 4 bytes - PadSpec ? - controller version for PADSetSpec ?
• 0x28 - 4 bytes - DolLimit - (limite max de la somme des tailles des sections Text et Data)

apploader.img

L'apploader est un fichier, lancé par le BIOS de la GameCube (aussi appelé l'Initial Program Loader / IPL), qui permet de créer les différents espaces mémoires pour lancer l'exécutable du jeu (généralement au format dol). Il se situe à l'offset 0x2440, à la suite du fichier bi2.bin. Il portera un nom différent selon les programmes que l'on utilisera pour ouvrir l'image DVD du jeu : AppLoader.ldr / apploader.img (dolphin Emulator) etc.

La taille de l'apploader se calcul à partir de son header :

• Le header fait 0x20 octets :
  • 0 - 10 octets - version
  • 0x10 - 4 octets - entry_point
  • 0x14 - 4 octets - size
  • 0x18 - 4 octets - trailer_size
• apploader_size à l'offset 0x14, donc à l'offset 0x2454 de l'iso GCM.
• trailer_size à l'offset 0x18, donc à l'offset 0x2458 de l'iso GCM. La trailer_size est un espace réservé à d'éventuelles évolutions de l'apploader.

boot.dol

Le fichier au format dol est un exécutable compilé pour l'architecture Gekko (powerpc). Son header fait 0x100 octets, et on trouvera la taille totale du dol en additionnant la taille du header et la taille de l'ensemble des 18 sections de celui-ci. A partir de l'offset 0x90, on trouvera 18 uint de 4 octets (big endian) contenant les tailles des 18 sections.

File String Table

La FST permet de packer l'arborescence de fichiers et de dossiers du jeu dans la suite de l'iso. Elle se divise en deux blocks :

• Le premier contient les entrées de la FST (dossiers et fichiers). (Big endian)
• Le second, le name_block, contient tous les noms des dossiers et des fichiers chacun terminés par un NULL byte (0x00). (Little endian)

Dans la première partie, on indexera tous les dossiers et les fichiers à partir du numéro 1. Chaque dossier ou fichier est traduit en 12 octets, et la toute première entrée est le nœud racine, portant l'index 0.

Les 12 octets d'une entrée pour un dossier :

• 1 octet pour le type, dossier=0x01.
• 3 octets uint pour l'offset du nom dans le name_block, commençant à l'offset 0 au début du name_block.
• 4 octets uint pour l'index du dossier parent.
• 4 octets uint pour l'index du dossier ou fichier suivant.

Les 12 octets d'une entrée pour un fichier :

• 1 octet pour le type, fichier=0x00.
• 3 octets uint pour l'offset du nom dans le name_block, commençant à l'offset 0 au début du name_block.
• 4 octets uint pour l'offset du fichier par rapport au début de l'iso GCM.
• 4 octets uint pour la taille du fichier.

Le nœud racine se situe au tout début de la FST, c'est un dossier avec les 3 octets de l'offset du nom et les 4 octets du dossier parent à 0x00. L'index du fichier suivant est égal au nombre total de dossiers et de fichiers du DVD. On trouvera alors l'offset du name_block en multipliant cet index par 12 et en y ajoutant 12 (taille du nœud racine).

L'alignement de l'ensemble des fichiers est important lors de la construction du boot.bin et de la FST. En effet, on alignera par exemple sur 4 octets, l'iso GCM ne fonctionnant pas au cas contraire.

Les DVD GCM JAP contiennent des caractères non utf-8 dans le name_block. L'application gcmtool.py, permettant de parser les iso GCM et de les patcher, ne prends pas en charge ces jeux là. Dolphin Emulator extraira les fichiers en traduisant le charset original en utf-8.

Le tris par défaut des dossiers et fichiers est non sensible à la casse (tous les noms en majuscules), et fait apparaître les caractères spéciaux avant les lettres. Néanmoins le format GCM permet de doubler des fichiers aux mêmes offsets ou encore de les positionner dans un ordre arbitraire.

Formats d'extraction

Le format GCReEx comporte les informations suivantes :

sys:
|- apploader.img
|- boot.bin (Information de base)
|- bi2.bin  (Information supplémentaires)
|- fst.bin  (FileStringTable)
\- main.dol ("Executable" DOL)
root:
|- banner.bnr
\+ ALL GAME DATA (AFS, etc)

Le format DiscEx comporte moins d'informations :

sys:
|- apploader.img
|- boot.bin (Information de base du jeu)
\- bi2.bin  (Information supplémentaires)
game.iso : Copie repack de l'iso d'origine.

On retrouvera d'autres formats.

Ce wiki sur le format nkit offre une très bonne documentation sur le format GCM.