Les bases du hack NDS

De T.R.A.F - Wiki
Aller à : navigation, rechercher

Structure d'une rom

Pour faire simple, une rom NDS est comme une archive, c'est à dire un fichier qui contient plusieurs autres fichiers.

Ces fichiers sont organisés d'une façon précise que nous n'aborderons pas ici étant donné qu'il existe tout un tas d'outils permettant d'extraire l'ensemble des fichiers d'une rom.

Et afin de travailler plus facilement, il est grandement recommandé de travailler directement sur les fichiers plutôt que sur la rom.


Les fichiers de la rom peuvent être classés en deux grandes parties :

  • les fichiers systèmes
  • les fichiers de données

L'adressage

L'adressage de la NDS est sur 32 bits. C'est à dire que toute adresse ou pointeur est codé sur 4 octets.

On peut noter deux grands types de pointeur :

  • les pointeurs d’adresse

Ils pointent directement l’adresse de la donnée en mémoire (à partir de 0x02000000). Bien évidemment, il est possible de trouver des pointeurs 16 bits (2 octets) pour certaine données. La partie haute de l'adresse sera ajoutée ailleurs dans le code.

  • les pointeurs relatifs

Ils pointent l’adresse de la donnée à partir d’une adresse de référence, qui, pour une table de pointeurs, est souvent l’adresse du premier pointeur de la table. Mais cela peut être l’adresse du pointeur ou le début du fichier ou autre.

Les fichiers systèmes

Ils servent au bon fonctionnement du jeu et/ou de la rom. Ils n'ont pas vraiment de nom prédéfinis, mais il existe un certain standard sur le net.

  • header.bin

Il s'agit des données permettant principalement de connaître où se trouvent les différents parties (fichiers, overlays...) et de savoir si la rom est correcte (en calculant le CRC)

  • banner.bin

Il s'agit de l'icône du jeu. Il contient également le nom du jeu dans les principales langues (japonais, anglais, français, allemand, espagnol et italien).

  • arm9.bin

Il s'agit du fichier le plus important du jeu : l'exécutable. Il contient le code permettant de faire fonctionner le jeu. Ce fichier peut être compressé.

  • arm7.bin

Il s'agit de l'exécutable gérant les jeux GBA.

  • overlays

Il s'agit d'une sorte d'extension de l'exécutable arm9.bin. Cela permet de charger le code du jeu par petit bout en mémoire et ainsi l'alléger. Il est possible d'avoir des overlays pour l'arm9 et pour l'arm7 mais ces derniers sont très rares. Ces fichiers peuvent être compressés.

  • y9.bin

Il s'agit d'un index utilisé pour les overlays de l'arm9. Il indique, entre autres, la taille et l'emplacement des overlays en mémoire

  • y7.bin

Il s'agit d'un index utilisé pour les overlays de l'arm7. Il indique, entre autres, la taille et l'emplacement des overlays en mémoire

Les fichiers de données

Ces fichiers contiennent généralement les données à afficher à l'écran, c'est à dire les textes et les graphismes. Ils peuvent, bien entendu, contenir d'autres informations.

Avant d'aller plus loin, il y a une règle à respecter quand on analyse de tels fichiers. Et cette règle est : IL N'Y A PAS DE REGLE, TOUT EST POSSIBLE

Il faut se méfier des extensions d'un fichier parce que généralement, elles ne veulent rien dire. Et une extension dans un jeu ne veut pas forcément dire que la même extension dans un autre jeu veuille dire la même chose. Sauf pour les standard Nintendo que nous aborderons plus tard ou si les jeux ont été développés par la même équipe.

Ces fichiers peuvent être compressés. Dans ce cas, deux solutions :

  • il s'agit d'une compression "standard" et il existe des outils pour les décompresser (voir Formats de fichiers).
  • il s'agit d'une compression inconnue et là, il faut créer un outil soi-même (ou connaître quelqu'un qui accepte de le faire pour vous ;)).

On peut également trouver des archives. Vous savez, des fichiers qui en contiennent d'autres. Dans ce cas, il est recommandé de les désarchiver pour travailler sur chaque fichier indépendamment. Certes, cela augmente le nombre de fichiers à regarder mais cela rend la recherche de certaines informations (comme les pointeurs) plus simple. C’est également plus facile pour déplacer les données à l’intérieur du fichier voir d’agrandir le fichier lui-même. Bien sûr, il est nécessaire, de reconstruire l’archive en mettant à jour l’index pour prendre en compte les nouvelles adresses et tailles de chaque fichier.

Formats de fichiers “standard”

Voici une liste non exhaustive des différents “standards” (Nintendo ou non)

Compression

Nous n'allons pas entrer dans les détails des compressions mais juste voir celles qui existent et comment on peut les reconnaître.

  • arm9.bin

Ce fichier n'est pas forcément compressé. Mais, quoiqu'il arrive, la compression est connue et la plupart des outils existants la gère sans problème.

  • overlays

Ils ne sont pas forcément compressés et il s'agit de la même compression que pour le fichier arm9.bin.

  • 0x11

Il s'agit d'une compression régulièrement utilisée. Si le premier octet de votre fichier commence par la valeur 0x11, il y a des chances qu'il s'agisse de cette compression. Compression connue et prise en charge par plusieurs outils.

  • 0x10

Il s'agit d'une compression régulièrement utilisée. Si le premier octet de votre fichier commence par la valeur 0x10, il y a des chances qu'il s'agisse de cette compression. Compression connue et prise en charge par plusieurs outils.

  • 0x40

Il s'agit d'une compression utilisée principalement dans Golden Sun. Est maintenant connue et prise en charge par différents outils.

Graphismes

Pour les graphismes, Nintendo semble avoir incorporé un certain standard, que les développeurs peuvent utiliser ou non.

Il y a deux façons de reconnaître les standards :

  • l'extension du fichier. Il arrive que les développeurs mettent le type de fichier dans l'extension.
  • la signature du fichier. Elle est visible dans un éditeur hexadécimal et correspond aux 4 premiers octets du fichier.

Apparemment, beaucoup de développeurs utilisent ce système de signature même s'il ne s'agit pas de standard. Cela peut donc aider à comprendre ce que c'est et surtout de reconnaître d'autres fichiers identiques.

Côté format d'image, elles sont généralement au format 4BPP (pour les utilisateurs de TileMolester, c'est 4BPP linear reverse) et 8BPP.

Voici une liste non exhaustive des différents formats de fichiers standard d'image :

  • NFTR : Il s'agit d'une font avec tout ce qu'il faut pour modifier la largeur des lettres.
  • NCGR : Il s'agit de données graphiques.
  • NCER : Il s'agit de cordonnées permettant de placer les données graphiques à l'ecran.
  • NCLR : Il s'agit de palettes de couleurs pour les graphismes.
  • NSCR : Il s'agit des Tilemaps qui définissent la position des graphismes à l'écran.
  • NANR : Il s'agit des données d'animations des images (certaines images étant animées un peu comme le sont les gifs).

Concernant les palettes, elles sont généralement au format RGB555. Cela veut dire qu'il y a 2 octets par couleur et que dans ces 2 octets, il y a 5 bits pour le Rouge, 5 bits pour le Vert et 5 bits pour le Bleu. Le dernier bit n’est pas utilisé.

Archives

Il existe quelques archives standard mais en général chaque développeur gère son archive comme il le veut. Pour pouvoir désarchiver une archive, il faut connaître son index. Il y en a forcément un afin de savoir où se trouve chaque fichier dans l'archive. L'inconvénient c'est que cet index peut être n'importe où, au début du fichier, à la fin du fichier ou même dans un autre fichier (arm9, overlays, …).

Une fois l'index trouvé, il faut le comprendre. Et là, pas de miracle, il faut utiliser son cerveau. Les informations qu'on retrouve généralement dans un index sont les suivantes (une ou plusieurs peuvent être utilisées) :

  • nombre de fichiers dans l'archive
  • adresse de début de chaque fichier
  • adresse de fin de chaque fichier
  • taille de chaque fichier

Ces informations sont généralement sur 32 bits.

Outils

Il y a deux types d'outils indispensable pour tous les supports : l'éditeur hexadécimal et l'éditeur graphique. Le premier permet de dire si le fichier contient du texte ou non et aide également à comprendre le fonctionnement d'un fichier (archive...) Le second permet de dire si le fichier est du graphisme ou non.

Il existe maintenant des outils spécifiques à la Nintendo DS qui permettent non seulement d'extraire les fichiers d'une rom mais aussi de gérer (extraction/insertion) les fichiers standards de Nintendo.

Un des premiers outils permettant d'extraire les fichiers d'une rom ou d'en recréer une. Fonctionne en ligne de commande.

Il s'agit d'une interface pour NDSTool rendant son utilisation plus simple.

Il s'agit d'une interface pour NDSTool rendant son utilisation plus simple (plus récente que DSLazy).

  • Crystal Tile 2 -
    • Extraction des fichiers d'une rom
    • Décompression de fichiers utilisant une compression standard
    • Désassembleur
    • Visualiseur de tiles
  • ConsoleTool - http://llref.emutalk.net/projects/ctool/
    • Extraction des fichiers d'une rom
    • Décompression de fichiers utilisant une compression standard
    • Affichage des images au format standard de Nintendo

Un outil en ligne de commande permettant de (dé)compresser les fichiers utilisant les compressions standard. Peut décompresser le contenu de tout un répertoire.

Permet de décompresser les compressions 0x10 et 0x11

Permet de gérer les fichiers font NFTR version 1