No edit summary |
|||
Line 7: | Line 7: | ||
* fst.bin (FileStringTable) | * fst.bin (FileStringTable) | ||
* boot.dol / elf (Main executable) | * boot.dol / elf (Main executable) | ||
* Files and Folders tree | * Files and Folders tree <- We talk about this block when mentioning "user space" | ||
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 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). | ||
Line 92: | Line 92: | ||
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. | 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: | sys: | ||
|- apploader.img | |- apploader.img | ||
|- boot.bin ( | |- boot.bin (Disc Header) | ||
|- bi2.bin (Information | |- bi2.bin (Disc Header Information) | ||
|- fst.bin (FileStringTable) | |- fst.bin (FileStringTable) | ||
\- main.dol ("Executable" DOL) | \- main.dol ("Executable" DOL) | ||
root: | root: | ||
|- banner.bnr | |- banner.bnr | ||
\+ ALL GAME DATA (AFS, | \+ ALL GAME DATA (AFS, and so on.) | ||
DiscEx extracted files are as following: | |||
sys: | sys: | ||
|- apploader.img | |- apploader.img | ||
|- boot.bin (Information de base du jeu) | |- boot.bin (Information de base du jeu) | ||
\- bi2.bin (Information supplémentaires) | \- bi2.bin (Information supplémentaires) | ||
game.iso : | game.iso : Repack copy of original iso. | ||
We find many others formats. | |||
This wiki about the [https://wiki.gbatemp.net/wiki/NKit/Discs#Disc_Header nkit format] offer a very good documentation about the GCM file format. | |||
[[Category:File format]] | [[Category:File format]] | ||
[[Category:Gotcha Force]] | [[Category:Gotcha Force]] |
Revision as of 11:32, 23 August 2022
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 <- We talk about this block when mentioning "user space"
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 allow to pack the files and folders tree of the game and is divided in 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 every folders and files beginning with the index 1. Every folder or file is translated in 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 at 0x00 and the 4 bytes parent folder id also at 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 nameblock offset by multiplying this total by 12 and adding 12 to it (the root node length).
The align is important when building boot.bin and FST and is generaly 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 song 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 extract 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.