Gotcha Force

Gotcha Force est un jeu vidéo de combat/tir à la troisième personne développé et publié par Capcom pour GameCube en 2003.

Matériel

Spécification technique de la GameCube

Manuel du processeur Gekko : ce manuel est utile lors du reverse engineering des fichiers exécutables (dol, etc.). On y trouvera la description des instructions assembleur.

Apploader

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 est situé à une adresse fixe sur le DVD. Il portera un nom différent selon les programmes que l'on utilisera pour ouvrir l'image DVD du jeu : AppLoader.ldr (GCRebuilder v1.1) / apploader.img (dolphin Emulator) etc. Les empreintes sha256 sont cependant identiques.

Formats de fichiers du jeu

Le "Definitive Guide To Exploring File Formats" est une bonne entrée en matière pour comprendre l'organisation des fichiers. On peut éventuellement faire une liste de champs possibles pouvant apparaître dans le header du fichier étudié afin de trouver les différents éléments du header et leur fonction.

Format	Contenu
ADX	Fichier audio
AFS	Dossier d'archive
ARC	Dossier d'archive ?
ARZ	Inconnu
BIN	Inconnu
BNR	Banner file format
CHD	Inconnu
DOL	Fichier exécutable SysDolphin
DPK	Inconnu
HDR	Inconnu
LDR	Apploader
MDT	Inconnu
PTL	Inconnu
PZZ	Dossier d'archive
REF	Inconnu
SFD	MPEG Sofdec
TOC	Inconnu
TPL	Librairie de palette de textures
TSB	Inconnu
TXG	Inconnu

Une page est réservée aux méthodes de reverse de binaires et aux recherches en cours sur le sujet.

Arborescence des fichiers

Voici l'arborescence des fichier pour GotchaForceUsa (USA/NTSC, GameCode : GG4E) :

&&SystemData
├─ ISO.hdr
├─ AppLoader.ldr (Le nom de l'apploader diffère selon les applications.)
├─ Start.dol (Le nom du dol principal diffère selon les application.)
└─ Game.toc
afs_data.afs
├─ *.adx (2113)
├─ *.arc (1369)
├─ *.arz (184)
├─ *.bin (586)
├─ *.chd (4)
├─ *.dpk (4)
├─ *.mdt (6)
├─ ptcl00.ptl
├─ *.pzz (254)
├─ ptcl00.ref
├─ *.sfd (2)
├─ *.tpl (442)
├─ *.tsb (4)
└─ ptcl00.txg
opening.bnr
poq_adx_usa.afs
├─ *.adx (2115)
└─ *.sfd (2)

Les logiciels utilisés sont GCRebuilder v1.1, et AFSExplorer 3.7.

Nommage des fichiers dans afs_data.afs

Fichiers compris :

pl####.pzz - Décrit chaque borg
firstld.pzz - Utilisation liée à la carte mémoire (First load - image de la carte mémoire inclue dans le pzz)
        firstld\003C_firstldicon.bin est identique à icon.bin dans l'afs_data.afs

L'investigation mené par la communauté de GioGio Bizarre Adventure montre une certaine logique qui peut potentiellement être utilisée dans le nommage des fichiers interne de afs_data.afs :

d#####.pzz - Character and/or prop data for 3D Cutscenes
pl##p.pzz - Character specific props
pl##.hit - Character collision data
st###.pzz - Stage model data
icon.bin - 3D icon used for the memory card file

Fichiers absents :

files containing "tbl" in the filename seem to be animations
ga00p - Gallery room (several textures and models in here
ball.pzz - Seems to just be a sphere model with a 32x32 blank texture
re00.pzz - Results screen
dcomn.pzz - Speech bubbles, onomatopoeia, zoom lines and others
ld###.pzz - Loading screen model and textures (they're just planes)
demo.pzz - Title screen textures (can be used to decompress data)
se###.pzz - Stage props
lw###.pzz - Stage collisions
npc###.pzz - NPC files
ks##.pzz - 2D Drama cutscene data (panels are 3D models)
k###.pzz - 2D cutscene data (panels are 3D models)

Observations

Pour chaque borg on a :

plxxxx.pzz
plxxxxdata.bin  <- position 0 du pzz
plxxxxhit.bin   <- position 2 du pzz
plxxxxmot.bin   <- position 3 du pzz
plxxxx_mdl.arc  <- position 4 du pzz ?
plxxxxb_mdl.arc <- position 5 du pzz ?
plxxxxg_mdl.arc <- position 6 du pzz ?
plxxxxs_mdl.arc <- position 7 du pzz ?
plxxxxc_mdl.arc <- position 8 du pzz ?
plxxxxk_mdl.arc <- position 9 du pzz ?

Ces fichiers ne sont pas toujours tous présents. On trouve pour certains plxxxx le fichier plxxxxdata2.bin ou encore plxxxxdata3.bin.

Position 000 : Pour tous les fichiers plxxxx.pzz (position 000) sans exception on retrouve le fichier plxxxxdata.bin correspondant identique dans l'afs_data.afs. A noter : pour pl0604 il s'agit de pl0604data2.bin. (Version NTSC).

Position 002 : Pour tous les fichiers plxxxx.pzz (position 002) on retrouve un fichier "plxxxxhit.bin" correspondant identique dans l'afs_data, excepté pour le borg pl0507 et pl0513 pour qui le fichier 2 et le hit diffèrent. Note : cela peut venir de la gestion du padding mal implémenté. (Version NTSC).

Position 003 : Pour tous les fichiers plxxxx.pzz (position 003) on retrouve soit un fichier "plxxxxmot.bin" correspondant identique dans l'afs_data, soit pas de fichier "plxxxxmot.bin", excepté pour le borg "pl0009" pour qui le fichier 3 et le mot diffèrent. Note : cela peut venir de la gestion du padding mal implémenté. (Version NTSC).

Pour chaque mdl correspondant à leurs position dans le pzz, lors de la décompression, les fichiers décompressé sont différent à la toute fin du fichier ou l'on retrouve dans le mdl original 0x746100 il semblerai que la décompression n'enlève pas les derniers 0x00 et on ce retrouve avec 0x74610000 dans les fichiers dat, ce qui augmente de 1 octet la taille du fichier mais ne change en rien le contenu qui reste le même que l'original.

pl0803 - pl080b - pl0f07 : Il reste uniquement le fichier pl0803hit.bin et pl080bhit.bin et aucun de leurs fichiers associés (notamment, pas de pzz associé), ce qui indique qu'ils sont à priori des restes de borgs non implémentés ... De même que le pzz pl0f07 n'a pas son fichier hit, ni ses 4 TPL internes (4 fichiers vides à la place) mais juste son fichier pl0f07_mdl.arc, ce qui indique que ce borg n'est pas implémenté non plus. (Version NTSC).

Exécutable principal

Le nom de l'exécutable principal dépend des applications utilisées boot.dol (dolphin Emulator) / Start.dol (GCRebuilder v1.1) etc. Les empreintes sha256 sont différentes entre dolphin Emulator et GCR !

L'exécutable principal embarque MetroTRK, un noyaux de débogage pour les systèmes embarqués.

Parmi les librairies utilisées, on retrouve notamment la librairie HSD (HAL Sysdolphin Engine). Les sources n'ont à priori pas leaké sur internet. On peut néanmoins retrouver un énorme travail réalisé par la communauté du jeux GameCube "Super Smash Bros. Melee" sur lequel on peut se baser :

-Description générale des éléments de HSD

-Reverse engineering des sources en C

-HAL DAT (Format de fichier)

Version Bêta

La version bêta du jeu contient des différences visibles quant aux versions finales. La map 3D était Isométrique avec des éléments en 3D sur la map et la description des borgs tenait sur tout l'écran avec deux sections. L'un pour les caractéristiques et l'autre pour l'histoire du borg.