Toggle menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.
Revision as of 10:57, 23 August 2022 by Algoflash (talk | contribs)

← Gotcha Force

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

  • boot.bin (Base Informations - Disc Header)
  • bi2.bin (Additionnal informations - debug, locales - Disc 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 are the sames in all released mini DVD of the game?" An intersting thing is that burning data at the out border of the DVD increases performances when hardware DVD 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 - DiscNumber - 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, 1 for normal boot
    • 2 Devkit set to : 0; MetroTRK: Set to AMC DDH hardware
    • 3 Devkit set to : 1; MetroTRK : Set to GDEV hardware
    • 4 Devkit set to : 2; MetroTRK : Set to BBA
  • 0x10 - 4 bytes - TrackLocation - Or MetroTRK for some documentations
  • 0x14 - 4 bytes - TrackSize - Or MetroTRK for some documentations
  • 0x18 - 4 bytes - CountryCode - 0 for Japan, 1 for USA, 2 for PAL, 4 Korea
  • 0x1c - 4 bytes - TotalDisc - total number of discs <= 99
  • 0x20 - 4 bytes - LongFileNameSupport - 1 = support, 0 = constrain to 8.3 format
  • 0x24 - 4 bytes - PadSpec ? - controller version for PADSetSpec ?
  • 0x28 - 4 bytes - DolLimit - (Max length of the sum of data and text sections)

apploader.img

The apploader is a file, loaded by the GameCube BIOS (also called the Initial Program Loader / IPL), that creates virtual memory spaces and rebase the dol datas in this areas before starting it. Apploader is at offset 0x2440 just after the bi2.bin. The GCM/iso doesn't store any name of it so it's name depend to the software used to extract it: AppLoader.ldr / apploader.img (dolphin Emulator) and so on.

The apploader length is calculated with it's header informations:

  • Header has a length of 0x20 bytes:
    • 0 - 10 bytes - Version
    • 0x10 - 4 bytes - entry_point
    • 0x14 - 4 bytes - size
    • 0x18 - 4 bytes - trailer_size
  • apploader_size is at offset 0x14 of the apploader so at offset 0x2454 of the GCM/iso.
  • trailer_size is at offset 0x18 of the apploader so at offset 0x2458 of the GCM/iso. The trailer_size is an empty space reserved for further apploader updates.

boot.dol

The dol file format is an executable compiled for Gekko powerpc RISC architecture. It's header has a length of 0x100 bytes and we calculate it's total length by summing the header length with all 18 sections in it. At offset 0x90 we found 18 uint of 4 bytes (big endian) containing the length of the 18 sections.

File String Table

The 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.