This article is about the GCM file format.
|
This file format is almost completely documented. The structure of this file is well known. |
| Block Name | Description |
|---|---|
| boot.bin | Base Information - Disc Header |
| bi2.bin | Additional Information - Debug, locales - Disc Header Information |
| apploader.img | Main Executable Loader |
| fst.bin | File String Table |
| boot.dol / elf | Main Executable |
| Files and Folders Tree | User Space Files and Folders Tree |
The file system is handled by the GameCube and we can see that files are loaded by names no matter in which order they have been stored (Dolphin Emulator).
The dol file and FST are stored after de apploader.img. The dol can be after or before FST. Most of the time dol is before FST. All GCM ROMs have a fixed length (mini DVD 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 overridden by new ones during devs. This empty spaces contains unused information. 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 interesting 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
| Offset (hex) | Size (bytes) | Description |
|---|---|---|
| 0x00 | 4 | GameCode (ASCII) - A-Za-z0-9 |
| 0x04 | 2 | MakerCode (ASCII) - A-Za-z0-9 |
| 0x06 | 1 | DiscNumber (0-98) |
| 0x07 | 1 | Version (0-99) |
| 0x08 | 1 | AudioStreaming Flag (0 or 1) |
| 0x09 | 1 | StreamBufferSize (0-15) |
| 0x1C | 4 | DVDMagic (0xc2339f3d) |
| 0x20 | 64 | GameName (ASCII and possibly Kanji) |
| 0x420 | 4 | DolOffset |
| 0x424 | 4 | FstOffset |
| 0x428 | 4 | FstLen |
| 0x42C | 4 | FstMaxLen (often corresponds to FST length but reserved for other mini DVDs) |
| 0x430 | 4 | FST Memory Address |
| 0x434 | 4 | UserPosition (Offset on mini DVD where the first game files begin) |
| 0x438 | 4 | UserLength (Total length where all files are located, may contain empty spaces) |
bi2.bin
| Offset (hex) | Size (bytes) | Description |
|---|---|---|
| 0x00 | 4 | DebugMonitorSize |
| 0x04 | 4 | SimulatedMemorySize |
| 0x08 | 4 | ArgumentOffset |
| 0x0C | 4 | DebugFlag |
| 0x10 | 4 | TrackLocation (or MetroTRK for some documentations) |
| 0x14 | 4 | TrackSize (or MetroTRK for some documentations) |
| 0x18 | 4 | CountryCode |
| 0x1C | 4 | TotalDisc (Total number of discs, <= 99) |
| 0x20 | 4 | LongFileNameSupport (1 = supported, 0 = constrained to 8.3 format) |
| 0x24 | 4 | PadSpec (Controller version for PADSetSpec) |
| 0x28 | 4 | DolLimit (Max length of the sum of data and text sections) |
| Value | Description |
|---|---|
| 0 | Normal Boot |
| 1 | Devkit Set to 0; MetroTRK Set to AMC DDH hardware |
| 2 | Devkit Set to 1; MetroTRK Set to GDEV hardware |
| 3 | Devkit Set to 2; MetroTRK Set to BBA |
| Value | Pays |
|---|---|
| 0 | Japan |
| 1 | USA |
| 2 | PAL |
| 4 | Korea |
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 those 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 its header information:
- 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 its 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 allow to pack the files and folders tree of the game and is divided into two blocks:
- The first one contains FST entries (folders and files) in Big Endian.
- The second one is the name_block which contains names of folders and files terminated by a NULL byte (0x00) in Little Endian.
In the first block we index each folder and file beginning with the index 1. Each folder or file is translated into a 12 bytes entry. The first entry is the root with index 0.
The 12 bytes for a folder entry:
- 1 byte for type, folder=0x01.
- 3 bytes uint - name_block name offset, relative to the start of the name_block.
- 4 bytes uint - index of the parent folder.
- 4 bytes uint - index of the next file or folder outside of it.
The 12 bytes for a file entry:
- 1 byte for type, file=0x00.
- 3 bytes uint - name_block name offset relative to the start of the name_block.
- 4 bytes uint - file offset relative to the start of the GCM/iso.
- 4 bytes uint - file length.
The root node is at the beginning of the FST and has the 3 bytes name_block name offset equal to 0x00 and the 4 bytes of the parent folder id also equal to 0x00. The index of the next file is equal to the total number of files and folders packed in the GCM/iso user space. We can find the name_block offset by multiplying this total by 12 and adding 12 to it (the root node length).
The alignment is important when building boot.bin and FST and is generally aligned to 4. If adx/sfd or audio files are packed then it's often aligned to 0x800 bytes. When unaligned the game could crash or songs are not loaded correctly.
JAP mini DVD contains non utf-8 chars like JIS charsets in the name_block. If using the Virtual World RE tool gcmtool.py then you have to install this charsets in your OS. When Dolphin Emulator extracts this JAP files it converts the original charset to utf-8.
The sorting of files in the FST is often case insensitive and special chars are sorted before letters. However some FST are arbitrary sorted and we found sometimes duplicated files like the dol or even the apploader also packed in the user space.
Extraction formats
GCReEx extracted files are as following:
sys:
|- apploader.img
|- boot.bin (Disc Header)
|- bi2.bin (Disc Header Information)
|- fst.bin (FileStringTable)
\- main.dol ("Executable" DOL)
root:
|- banner.bnr
\+ ALL GAME DATA (AFS, and so on.)
DiscEx extracted files are as following:
sys: |- apploader.img |- boot.bin (Information de base du jeu) \- bi2.bin (Information supplémentaires) game.iso: Repack copy of original iso.
We find many others formats.
This wiki about the nkit format offer a very good documentation about the GCM file format.