CHD (Gotcha Force)

2022-02-17T12:33:13Z

Rigodron:

[[Gotcha Force | ← Gotcha Force]]

''Cet article est pour les format de fichiers CHD de Gotcha Force. Voir [[CHD (Format de fichier)]] pour les autres versions de ce fichier.''

<div style="text-align: center;">
<h2 style="color: red;">Cette section a besoin de beaucoup de recherche.<h2>
<h4 style="color: red;">Des recherches sur comment fonctionne le header et comment interagit le fichier sont nécessaire.<h4>
</div>

PGCD des tailles des chd = 16

__toc__

Les fichiers CHD contiennent différentes sections :

*0x0 "Head" Header CHD

0x4 : Amène au header Prog.

0x8 : Indique une quantité ?

0xC : Taille du fichier complet.

0x10 ?

0x14 ?

0x18 Amène au header Smpl.

0x1C Amène au header DSPi.

*0x20 "Prog" <span style="color: rgb(241, 196, 15);"> Pourrait faire référence à du script audio.</span>

0x24 : Taille du block data.

0x28 : Indique une quantité ?

0x2C : -1 ?

*0x0 "Smpl" Samples ?

0x4 : Taille du block data.

0x8 : Quantité de samples? (En hexadecimal. Ex 0x68 = 104 + 1(0,1,2....104))

0xC : -1 ?

*0x0 "Dspi" <span style="color: rgb(241, 196, 15);">DSP pour DSPADPCM, Piste possible : Liste des DSP dans [[DPK (Gotcha Force)]].</span>

0x4 : Taille du block data.

0x8 : Quantité de DSP? (En hexadecimal)

0xC : -1 ?

[[Catégorie:Format de fichier]]
[[Catégorie:Gotcha Force]]

CHD (Gotcha Force)

2022-02-17T11:34:55Z

Rigodron:

[[Gotcha Force | ← Gotcha Force]]

''Cet article est pour les format de fichiers CHD de Gotcha Force. Voir [[CHD (Format de fichier)]] pour les autres versions de ce fichier.''

<div style="text-align: center;">
<h2 style="color: red;">Cette section a besoin de beaucoup de recherche.<h2>
<h4 style="color: red;">Des recherches sur comment fonctionne le header et comment interagit le fichier sont nécessaire.<h4>
</div>

PGCD des tailles des chd = 16

__toc__

Les fichiers CHD contiennent différentes sections :

*0x0 "Head" Header CHD

0x4 : Amène au header Prog.

0x8 : Indique une quantité ?

0xC : Taille du fichier complet.

0x10 ?

0x14 ?

0x18 Amène au header Smpl.

0x1C Amène au header DSPi.

*0x20 "Prog" <span style="color: rgb(241, 196, 15);"> Pourrait faire référence à du script audio.</span>

0x24 : Taille du block data.

0x28 : Indique une quantité ?

0x2C : -1 ?

*0x0 "Smpl" Samples ?

0x4 : Taille du block data.

0x8 : Quantité de samples?

0xC : -1 ?

*0x0 "Dspi" <span style="color: rgb(241, 196, 15);">DSP pour DSPADPCM, Piste possible : Liste des DSP dans [[DPK (Gotcha Force)]].</span>

0x4 : Taille du block data.

0x8 : Quantité de DSP?

0xC : -1 ?

[[Catégorie:Format de fichier]]
[[Catégorie:Gotcha Force]]

Models

2022-02-09T08:18:51Z

Rigodron: /* Header */

<div style="text-align: center;">
<h2 style="color: rgb(241, 196, 15);">Cette section est en cours de rédaction.<h2>
<h4 style="color: rgb(241, 196, 15); text-align: center;">Des recherches sont encore nécessaires et certains paragraphes peuvent être faux.<h4>
</div>

__TOC__

== Modèle Gotcha Force ==

Les modèles Gotcha force fonctionnent comme ceux du jeu Smash Bros investigué par sa [https://smashboards.com/threads/melee-dat-format.292603/ communauté].

Les modèles sont des fichiers HSD de la library Hal SysDolphin.

=== Header ===

Le header ce compose de la position du fichier HSD puis contient une location de suite de flags et la liste des armatures.

En 0x0 on retrouve l'offset 0x100 menant au fichier HSD.

En 0x4 on retrouve l'offset 0x20 menant à la liste des flags des armatures. Flags qui sont '''Inconnu''' à ce jour.
Les flags sont en u8 pouvant aller de 00 à FF.

En 0x8 on retrouve l'offset 0xC0 menant à la liste des armatures.
------------------------------------------------------------------------------
Les fichiers _mdl se retrouvent dans les pzz des borgs (plxxxx.pzz) en position 004 à 009 ainsi que les fichiers pl*_mdl.arc. Il s'agit d'un format de fichier relatif au fonctionnement de la lib HSD utilisé dans plusieurs jeux par Capcom. L'usage d'un script est nécessaire pour référencer les fichiers éligibles au format _mdl dans l'ensemble de l'AFS data et dans les sous fichiers des pzz.

Pour commencer, il s'agit de synthétiser les investigations de la commu Super Smash Bros Melee et de les traduire. HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows(Algoflash) (segfaults même sur SSBM -> fichiers spécifiés comme bien géré dans la dernière release des sources - sans pouvoir investiguer plus) et ne permet pas d'éditer les fichiers. Par contre, il est prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 (celui ou on a la taille totale du fichier en big endian) permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le noeud en violet.

-----------------------------------------------

Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB.
La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

Le format dat/usd sur ssbm se découpe en plusieurs blocks :
* '''Header''' - 0x20 octets - unsigned big endian
** 4 octets - Taille totale du fichier
** 4 octets - Taille du Data block
** 4 octets - Nombre d'entrée dans la Table de relocs
** 4 octets - root0_count
** 4 octets - root1_count
** 12 octets - Pad ? à voir de manière scripté si des valeurs apparaissent à ces offsets
* '''Data block''' :
** JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
* '''Relocation Table''' :
** Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
* '''Root Nodes (2)''' :
** Tableau de taille 8 * root0_count
*** 4 octets - root_offset - relatif au DB
*** 4 octets - string_table_offset - relatif à la StringTable
** Tableau de taille 8 * root1_count (ou 4 octets 0x00 si root1_count == 0)
*** 4 octets - root_offset - relatif au DB
*** 4 octets - string_table_offset - relatif à la StringTable
* '''String Table''' :
** Suite de strings terminées par Null au nombre de root0_count + root1_count

Structures rencontrées dans le DB :
* Structures JOBJ pointées par les listes dans Root Nodes (0x40 octets)
** 4 octets - Inconnu
** 4 octets - flags
** 4 octets - child_offset (JOBJ)
** 4 octets - next_offset (JOBJ)
** 4 octets - dobj_offset (DOBJ)
** float3 - rotation_xyz (taille en octets d'un float à déterminer)
** float3 - scale_xyz
** float3 - translation_xyz
** 4 octets - transform_offset (inverse transform = méthode de nombres aléatoires ? mouvement ?)
** 4 octets - Inconnu

Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

* DOBJ_DATA : liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JOBJ auquel il est lié
** 4 octets - Inconnu
** 4 octets - next_offset - prochain DOBJ
** 4 octets - mobj_offset - material ?
** 4 octets - pobj_offset - mesh ?

* MOBJ_DATA : Contient les textures & informations sur les couleurs des Materials
** 4 octets - Inconnu
** 4 octets - Flags Inconnus
** 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
** 4 octets - material_offset - couleurs des materials ?
** 8 octets - Inconnu

* MATERIAL_COLORS : (material_offset)
** 4 octets - Couleur Inconnue - diffuse?
** 4 octets - Couleur Inconnue - ambient?
** 4 octets - Couleur Inconnue - specular?
** float - Inconnu
** float - Inconnu

* TOBJ_DATA : Informations de Textures (0x5c)
** 19 * 4 octets - Inconnu [19]
** 4 octets - image_offset - image header information
** 4 octets - palette_offset - palette header information
** 2 * 4 octets - Inconnu

Le TOBJ contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* IMAGE_HEADER :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* PALETTE_HEADER : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

* POBJ_DATA :
** 4 octets - Inconnu
** 4 octets - next_offset
** 4 octets - vertex_attr_array_offset - vertex attribute list
** 2 octets - Flags Inconnus
** 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
** 4 octets - display_list_offset - display list
** 4 octets - weight_list_offset - joint weight info

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. POBJ_DATA contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 20 octets - tableau inconnu (x5)
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Catégorie:Format de fichier]]
[[Catégorie:Gotcha Force]]

Models

2022-02-09T08:17:01Z

Rigodron: /* Header */

<div style="text-align: center;">
<h2 style="color: rgb(241, 196, 15);">Cette section est en cours de rédaction.<h2>
<h4 style="color: rgb(241, 196, 15); text-align: center;">Des recherches sont encore nécessaires et certains paragraphes peuvent être faux.<h4>
</div>

__TOC__

== Modèle Gotcha Force ==

Les modèles Gotcha force fonctionnent comme ceux du jeu Smash Bros investigué par sa [https://smashboards.com/threads/melee-dat-format.292603/ communauté].

Les modèles sont des fichiers HSD de la library Hal SysDolphin.

=== Header ===

Le header ce compose de la position du fichier HSD puis contient une location de suite de flags et la liste des armatures.

En 0x0 on retrouve l'offset 0x100 menant au fichier HSD.

En 0x4 on retrouve l'offset 0x20 menant à la liste des flags des armatures. Flags qui sont '''Inconnu''' à ce jour.
Les flags sont en u8 pouvant aller de 00 à FF.

En 0x8 on retrouve l'offset 0xC0 menant à la liste des armatures.
------------------------------------------------------------------------------
Les fichiers _mdl se retrouvent dans les pzz des borgs (plxxxx.pzz) en position 004 à 009 ainsi que les fichiers pl*_mdl.arc. Il s'agit d'un format de fichier relatif au fonctionnement de la lib HSD utilisé dans plusieurs jeux par Capcom. L'usage d'un script est nécessaire pour référencer les fichiers éligibles au format _mdl dans l'ensemble de l'AFS data et dans les sous fichiers des pzz.

Pour commencer, il s'agit de synthétiser les investigations de la commu Super Smash Melee et de les traduire. HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (segfaults même sur SSBM -> fichiers spécifiés comme bien géré dans la dernière release des sources - sans pouvoir investiguer plus) et ne permet pas d'éditer les fichiers. Par contre, il est prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 (celui ou on a la taille totale du fichier en big endian) permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le noeud en violet.

-----------------------------------------------

Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB.
La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

Le format dat/usd sur ssbm se découpe en plusieurs blocks :
* '''Header''' - 0x20 octets - unsigned big endian
** 4 octets - Taille totale du fichier
** 4 octets - Taille du Data block
** 4 octets - Nombre d'entrée dans la Table de relocs
** 4 octets - root0_count
** 4 octets - root1_count
** 12 octets - Pad ? à voir de manière scripté si des valeurs apparaissent à ces offsets
* '''Data block''' :
** JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
* '''Relocation Table''' :
** Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
* '''Root Nodes (2)''' :
** Tableau de taille 8 * root0_count
*** 4 octets - root_offset - relatif au DB
*** 4 octets - string_table_offset - relatif à la StringTable
** Tableau de taille 8 * root1_count (ou 4 octets 0x00 si root1_count == 0)
*** 4 octets - root_offset - relatif au DB
*** 4 octets - string_table_offset - relatif à la StringTable
* '''String Table''' :
** Suite de strings terminées par Null au nombre de root0_count + root1_count

Structures rencontrées dans le DB :
* Structures JOBJ pointées par les listes dans Root Nodes (0x40 octets)
** 4 octets - Inconnu
** 4 octets - flags
** 4 octets - child_offset (JOBJ)
** 4 octets - next_offset (JOBJ)
** 4 octets - dobj_offset (DOBJ)
** float3 - rotation_xyz (taille en octets d'un float à déterminer)
** float3 - scale_xyz
** float3 - translation_xyz
** 4 octets - transform_offset (inverse transform = méthode de nombres aléatoires ? mouvement ?)
** 4 octets - Inconnu

Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

* DOBJ_DATA : liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JOBJ auquel il est lié
** 4 octets - Inconnu
** 4 octets - next_offset - prochain DOBJ
** 4 octets - mobj_offset - material ?
** 4 octets - pobj_offset - mesh ?

* MOBJ_DATA : Contient les textures & informations sur les couleurs des Materials
** 4 octets - Inconnu
** 4 octets - Flags Inconnus
** 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
** 4 octets - material_offset - couleurs des materials ?
** 8 octets - Inconnu

* MATERIAL_COLORS : (material_offset)
** 4 octets - Couleur Inconnue - diffuse?
** 4 octets - Couleur Inconnue - ambient?
** 4 octets - Couleur Inconnue - specular?
** float - Inconnu
** float - Inconnu

* TOBJ_DATA : Informations de Textures (0x5c)
** 19 * 4 octets - Inconnu [19]
** 4 octets - image_offset - image header information
** 4 octets - palette_offset - palette header information
** 2 * 4 octets - Inconnu

Le TOBJ contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* IMAGE_HEADER :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* PALETTE_HEADER : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

* POBJ_DATA :
** 4 octets - Inconnu
** 4 octets - next_offset
** 4 octets - vertex_attr_array_offset - vertex attribute list
** 2 octets - Flags Inconnus
** 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
** 4 octets - display_list_offset - display list
** 4 octets - weight_list_offset - joint weight info

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. POBJ_DATA contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 20 octets - tableau inconnu (x5)
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Catégorie:Format de fichier]]
[[Catégorie:Gotcha Force]]

Models

2021-12-26T06:43:15Z

Rigodron: /* Header */

Models

2021-12-26T06:42:20Z

Rigodron: /* Header */

2021-11-26T22:40:20Z

Rigodron: A retiré la protection de « Onimusha 3: Demon Siege »

[[Category:Jeux]]
'''Les recherches sont en cours, les informations affichées ici peuvent être erronées !'''

'''Onimusha 3: Demon Siege''' est un jeu vidéo d'action-aventure hack-and-slash développé et publié par Capcom.

__TOC__

== Le fichier de sauvegarde ==

Le jeu possède un fichier unique de sauvegarde pour les 9 profils de sauvegarde.<br>
Le jeu ne semble pas vouloir sauvegarder certains paramètres essentiels tel que la résolution.

Le fichier de sauvegarde se trouve dans <code>/save/SAVE</code> a la racine du dossier du jeu (Par défaut : <code>C:\Program Files (x86)\CAPCOM\ONIMUSHA3\</code> ou <code>C:\Program Files\CAPCOM\ONIMUSHA3\</code> sur Windows 32 Bits)

=== Structure du fichier de sauvegarde ===

{| class="wikitable"
! Adresse
! Ordre
! Type
! Description
|-
| 0x020C3C
| Little-Endian
| U32 ?
| Nombre de sauvagardes (SLOT 1)
|}

=== Fonctions qui font appel au fichier de sauvegarde ===

'''Note: Les adresses données ici correspondent a des adresses générés par IDA Pro 7.5'''<br>
La fonction a l’adresse <code>0x555700</code> est constamment appelé lors de l’utilisation de <code>aSave</code><br>
<code>aSave</code> est la variable globale qui contient la chaîne de caractère <code>/SAVE/</code>

{| class="wikitable"
! Adresse
! Nom de la fonction
! Offset d'instruction
|-
| 0x555980
| N/A
| +AF
|-
| 0x555A90
| N/A
| +AF
|-
| 0x555BA0
| N/A
| +88
|-
| 0x5576E0
| N/A
| +9F
|-
| 0x557FC0
| N/A
| +255
|-
| 0x559010
| N/A
| +FC
|-
| 0x559010
| N/A
| +281
|}

== Versions du jeu ==

=== PlayStation 2 ===
{| class="wikitable"
! Build
! Date de Build
! Date de sortie
! Région
|-
| Release
| Inconnue
| 26 février 2004
| JAP
|-
| Release
| 9 mars 2004
| 27 avril 2004
| US (NA)
|-
| Prototype
| 18 mars 2004
| 20 mars 2021 (leak)
| US (NA)
|-
| Release
| Inconnue
| 8 juillet 2004
| EUR
|}

=== Windows ===
{| class="wikitable"
! Build
! Date de build
! Date de sortie
! Région
! SecuROM
|-
| Release
| N/A
| 25 novembre 2005
| JAP
| N/A
|-
| R 1.0.0.3
| 12 janvier 2006
| 24 février 2006
| EUR
| SecuROM 7
|-
| R 1.1.0.0
| 01 mars 2006
| Mars 2006
| EUR
| SecuROM 7
|-
| Release
| 31 octobre 2005
| 16 mars 2006
| US (NA)
| Non
|-
| Demo
| 04 octobre 2005
| 2005 / 2006 ?
| JAP
| Non
|-
| Release
| N/A
| 22 aout 2007
| International (Steam)
| N/A
|}

File formats reverse engineering

2021-11-26T22:21:32Z

Rigodron:

= Reverse de formats =
Cette page est destinée aux recherches sur le reverse de fichiers et aux essais en cours.
== Typage des variable ==
[[Fichier:Typage & compilation.png|800px|center|thumb|vignette]]
Les types sont traduits par le compilateur pour une architecture précise et se traduise en binaire de différentes manières.
== Tailles de fichiers ==
=== PGCD et taille de fichier ===
L'idée, c'est d'observer les tailles de fichiers pour retrouver des caractéristiques de certaines archives, telles que la taille du header, et l'éventuelle utilisations de "conteneurs"/chunks de taille fixe.

Pour cela, on prend l'ensemble des tailles en octets de chaque fichier du format étudié. On réalise le PGCD sur ces tailles et si le PGCD est conséquent, c'est qu'on a potentiellement un header et des chunks de la taille du PGCD.

=== PGCD et taille de header variable ===
Dans le cas on on aurait un fichier avec une taille de header différente de la taille des chunks, on peut tester les PGCD en soustrayant la taille d'un header que l'on augmente.

La structure du fichier recherché serait la suivante :

|---- HEADER ----|------------ CHUNK 1 ------------|------------ CHUNK 2 ------------|------------ CHUNK N ------------|

On utilisera alors un seuil au dessus duquel nous afficherons la taille du header et la taille du PGCD.

== Recherche de propriétés et clair connu ==
=== Bruteforce d'un offset fixe ===
Dans le cas où on peut rassembler un ensemble de caractéristiques que l'on peut clairement attribuer à un groupe de fichiers, il est alors envisageable de bruteforcer pour retrouver l'endroit dans le fichier où ces propriétés sont stockées.

La première étape est de rechercher un ensemble de données pour les réunir dans un csv. Ces données devront être associées à un nom de fichier. On pourra par exemple scraper ces données sur des sites de fans par exemple.

La seconde étape, c'est de programmer la recherche de nombreux encodages cohérents pour chaque propriétés du csv recherchée. On recherchera tous ces encodages dans l'ensemble des fichier de la position 0 à la fin du plus petit des fichiers du lot. On vérifiera alors si la propriété apparait à la position donnée, et si elle n'est pas présente, on passera alors à la position suivante.

Il est à noter que les types sont traduits de différentes manières selon les compilateurs. On prendra soin de tester différentes représentations (nombres signés compléments à 1, à 2, signe et valeur absolue, virgule fixe, virgule flottante, avec différentes tailles de signe/mantis/exposant, etc.).

=== Ensembles et masque ===
Ici aussi, on dispose d'un dataset avec des propriétés en lien avec les fichiers étudiés. Il s'agit de regrouper les propriétés par valeurs et d'étudier les changements dans les fichiers associés pour identifier la position potentielle d'une propriété.

Pour les fichiers :
* A = Ensemble(fichiers AVEC valeur "a" de la propriété)
* B = Ensemble(fichiers SANS valeur "a" de la propriété)
* D = FichierMasque # de la taille du fichier ; on y mettra FF ou des bits à 1 si le bit ou l'octet peut représenter la propriété

Pour tous les A si l'octet à l'offset étudié est identique, on met l'octet dans D à FF, 00 sinon
Pour tous les B s'il existe un B identique à l'octet correspondant dans A alors on met l'octet dans D à 0x00

On répète l'opération pour toutes les valeurs de la propriété. Pour ajouter de la souplesse, on peut ajouter une tolérance aux erreurs pour un dataset comportant éventuellement des erreurs, ou la présence de valeurs spéciales encodées différemment.

L'approche par bit pose un soucis dans la comparaison entre A et B. Pour rappel, si l'octet à la position i est identique pour A et B, alors on retire l'octet du masque. Mais pour le bit, il nous faut la taille exacte de l'encodage de la propriété car si la taille en bits est inférieure, on retrouve alors des valeurs possiblement identique pour A et B, avec le bit suivant ou précédent qui appartient à la propriété et qui lui, diffère. Idem si la taille en bits est supérieure.

C'est pourquoi il est nécessaire de faire plusieurs masques pour chaque taille en bits. Les similarités ou les différences ajoutées aléatoirement avec une mauvaise taille en bits de l'encodage de la propriété réduisent à néant le masque, ce qui permet de tester en incrémentant les tailles et de ne garder que le masque qui produit un résultat.

Il est aussi à noter le recroisement du masque après un décalage. Si on étudie par exemple les bits de 0 à 4 et qu'on met le masque à 1111 on étudiera ensuite les bits de 1 à 5 et on aura potentiellement 10000 <- ce qui effacerait le travail précédent. L'idée serait de forcer les bits à 1 et de ne pas réinitialiser quand ils sont mis à 1 dans la comparaison de A et de B. On peut éventuellement créer deux masques A <-> A et A <-> B pour en faire ensuite le & logique.

== Outils à tester ==
* https://hexinator.com/
* https://www.sweetscape.com/010editor/

tester l'entropie avec binwalk (1. dans doku)

== Doku ==
* 1. https://archive.fosdem.org/2021/schedule/event/reverse_engineering/attachments/slides/4518/export/events/attachments/reverse_engineering/slides/4518/Reverse_Engineering_of_binary_File_Formats.pdf
* 2. [http://www.iwriteiam.nl/Ha_HTCABFF.html www.iwriteiam.nl/Ha_HTCABFF.html] (Reste à extraire les tools dans les liens)
* 3. https://github.com/tylerha97/awesome-reversing (Grande liste à étudier, déterminer ce qui correspond au reverse de binaires - voir d'il existe d'autres "awesome ..")
* 4. https://beginners.re/RE4B-FR.pdf (voir le sommaire détaillé et trouver les sections qui parlent de reverse de binaires)

https://en.wikibooks.org/wiki/Reverse_Engineering/File_Formats

2021-11-22T16:23:11Z

Rigodron: /* Nommage des fichiers dans afs_data.afs */

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

__TOC__

== Matériel ==

[https://en.wikipedia.org/wiki/GameCube_technical_specifications Spécification technique de la GameCube]

[http://datasheets.chipdb.org/IBM/PowerPC/Gekko/gekko_user_manual.pdf#page=337 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'[https://www.gc-forever.com/wiki/index.php?title=Apploader apploader] est un fichier, lancé par le BIOS de la GameCube (aussi appelé l'[https://wiki.dolphin-emu.org/index.php?title=GameCube_Main_Menu 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 "[http://wiki.xentax.com/index.php/DGTEFF 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.

{| class="wikitable"
! Format
! Contenu
|-
| [[ADX (Format de fichier)|ADX]]
| Fichier audio
|-
| [[AFS (Format de fichier)|AFS]]
| Dossier d'archive
|-
| [[ARC (Gotcha Force)|ARC]]
| Dossier d'archive ?
|-
| [[ARZ (Gotcha Force)|ARZ]]
! Inconnu
|-
| [[BIN (Gotcha Force)|BIN]]
! Inconnu
|-
| [[BNR (Format de fichier)|BNR]]
| Banner file format
|-
| [[CHD (Gotcha Force)|CHD]]
! Inconnu
|-
| [[DOL (Gotcha Force)|DOL]]
| Fichier exécutable [[SysDolphin]]
|-
| [[DPK (Gotcha Force)|DPK]]
! Inconnu
|-
| [[HDR (Gotcha Force)|HDR]]
! Inconnu
|-
| [[LDR (Gotcha Force)|LDR]]
| Apploader
|-
| [[MDT (Gotcha Force)|MDT]]
! Inconnu
|-
| [[PTL (Gotcha Force)|PTL]]
! Inconnu
|-
| [[PZZ (Gotcha Force)|PZZ]]
| Dossier d'archive
|-
| [[REF (Gotcha Force)|REF]]
! Inconnu
|-
| [[SFD (Format de fichier)|SFD]]
| MPEG Sofdec
|-
| [[TOC (Gotcha Force)|TOC]]
! Inconnu
|-
| [[TPL (Format de fichier)|TPL]]
| Librairie de palette de textures
|-
| [[TSB (Gotcha Force)|TSB]]
! Inconnu
|-
| [[TXG (Gotcha Force)|TXG]]
! Inconnu
|}
<p class="mwt-heading" >Une [[Reverse de binaires|page]] est réservée aux méthodes de reverse de binaires et aux recherches en cours sur le sujet.</p>
== 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)

<br>Les logiciels utilisés sont GCRebuilder v1.1, et AFSExplorer 3.7.<br>
== Nommage des fichiers dans afs_data.afs ==
L'investigation mené par la communauté de [https://zenhax.com/viewtopic.php?t=13419 GioGio Bizarre Adventure] montre une certaine logique qui peut potentiellement être utilisée dans le nommage des fichiers interne de afs_data.afs :<br>
<br>
files containing "'''tbl'''" in the filename seem to be animations
'''d#####.pzz''' - Character and/or prop data for 3D Cutscenes
'''k###.pzz''' - 2D cutscene data (panels are 3D models
'''ks##.pzz''' - 2D Drama cutscene data (panels are 3D models
'''npc###.pzz''' - NPC files
'''pl##.pzz''' -  Character files
'''pl##p.pzz''' - Character specific props
'''pl##.hit''' - Character collision data
'''lw###.pzz''' - Stage collisions
'''st###.pzz''' - Stage model data
'''se###.pzz''' - Stage props
'''ld###.pzz''' - Loading screen model and textures (they're just planes
'''dcomn.pzz''' - Speech bubbles, onomatopoeia, zoom lines and others
'''demo.pzz''' - Title screen textures (can be used to decompress data
'''ga00p''' - Gallery room (several textures and models in here
'''re00.pzz''' - Results screen
'''icon.bin''' - 3D icon used for the memory card file
'''ball.pzz''' - Seems to just be a sphere model with a 32x32 blank texture

=== Observations ===

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. <span style="color: rgb(224, 62, 45);">Les empreintes sha256 sont différentes entre dolphin Emulator et GCR !</span>

L'exécutable principal embarque [https://usermanual.wiki/m/f28d717b124185a5deabfe6020cb945538679565e15cad6ec9f93a47e04eabef.pdf 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 [https://smashboards.com/search/1402833/?q=hsd&o=relevance la communauté du jeux GameCube "Super Smash Bros. Melee"] sur lequel on peut se baser :

-[https://github.com/UnclePunch/Training-Mode/wiki/HSD-Documentation Description générale des éléments de HSD]

-[https://github.com/PsiLupan/FRAY Reverse engineering des sources en C]

-[http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format) 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 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.

[[Fichier:Gfbeta02.jpg|800px|center|thumb|Map bêta isométrique. [https://www.unseen64.net/2008/04/08/gotcha-force-gc-beta-concept/ Source]]]
[[Fichier:gotchaforcebeta01.jpg|800px|center|thumb|Description bêta borg. [https://www.unseen64.net/2008/04/08/gotcha-force-gc-beta-concept/ Source]]]