Projet de rétro‑ingénierie du ROM N64 de Duke Nukem: Zero Hour atteint 100 %

 (github.com/Gillou68310)
1 points par GN⁺ 2025-10-20 | 1 commentaires | Partager sur WhatsApp
  • Présentation d’un projet open source ayant réalisé la décompilation complète du ROM Nintendo 64 de Duke Nukem: Zero Hour
  • Ce dépôt a atteint à 100 % la restauration de l’ensemble du code source du logiciel du jeu original
  • Les utilisateurs doivent posséder eux-mêmes le ROM ; une compilation et des tests complets sont possibles via la ROM US ou française d’origine
  • Par rapport aux projets de décompilation existants, il se distingue par une compatibilité fonctionnelle parfaite et une prise en charge des outils de débogage
  • Ce projet est une ressource très précieuse pour la recherche sur le moteur de jeu, le modding, le portage et l’analyse de moteur

Importance et atouts du projet

  • Duke Nukem: Zero Hour est un jeu d’action célèbre, sorti en exclusivité sur la plateforme Nintendo 64
  • Ce projet open source a décompilé intégralement l’ensemble du ROM du jeu en C, Python, etc. et l’a reconstruit au niveau du code source
  • Contrairement aux autres projets de décompilation sur N64, il garantit une compatibilité parfaite, offrant un build et une exécution normalisés du ROM, un débogage basé sur le code source, ainsi qu’un support multi-versions
  • Il offre une excellente valeur documentaire pour l’étude de l’architecture des moteurs de jeu et du savoir-faire du développement de jeux de console des années 1990
  • Plusieurs outils d’analyse/décompilation automatisée (asm-differ, mips2c, splat, decomp-permuter, etc.) sont intégrés, maximisant l’efficacité des développeurs

Principales fonctionnalités et architecture

Architecture globale

  • Le projet est multilingue, avec des parties en C (plus de 95 %), Python, Roff, C++, Makefile et Shell
  • Principaux répertoires :
    • .github/workflows : configuration CI et automatisation
    • include, libs, src : gestion des sources de jeu, des bibliothèques et des en-têtes
    • tools : outils d’analyse, d’extraction et de conversion
    • versions : structure de support de plusieurs versions du jeu, dont US/FR
  • Il est activement maintenu, avec près de 370 commits

Résumé de la compilation et de l’utilisation

  • Environnement basé sur Ubuntu 20.04 et prise en charge de Docker
  • Extraction du ROM, comparaison bit à bit, mode NON_MATCHING pris en charge
  • ROM française et ROM américaine supportées, avec choix d’options selon les besoins de l’utilisateur
  • Compatibilité avec plusieurs OS (WIN/Mac/Linux) via un environnement Docker et l’extension Mutagen

Débogage et outils de développement

  • Support du débogage au niveau du code source basé sur gdb et mupen64plus (sous Windows en priorité pour l’instant)
  • Intégration avec Visual Studio Code et l’extension Native Debug
  • Outils d’automatisation et d’analyse clés :
    • asm-differ : comparaison source/cible au niveau assembleur
    • decomp-permuter : réagencement de code et notation automatique
    • mips2c : conversion de l’assembleur MIPS vers le C
    • splat : outil d’analyse de la structure ROM

Cas d’usage

  • Potentiel de réutilisation du code pour le reverse engineering de jeux, le portage, l’analyse de moteurs et les projets d’amélioration de jeux classiques
  • Très adapté à la conservation historique et à la recherche éducative
  • La maintenance et les mises à jour pour différentes plateformes et versions sont menées activement

Conclusion

  • Ce projet open source constitue un cas rare de publication complète du code source d’un logiciel de jeu de console classique des années 1990
  • Il s’agit d’une ressource précieuse pour les chercheurs en reverse engineering de jeux et de consoles, les développeurs débutants, ainsi que pour les porteurs et créateurs de fan games

À lire aussi

1 commentaires

 
GN⁺ 2025-10-20
Avis Hacker News
  • Le projet est décompilé à 100 % en C, mais c’est intéressant de voir que l’étiquetage n’est pas encore complètement finalisé, car beaucoup de noms de fonctions et de variables ont été générés automatiquement. Si quelqu’un tentait un portage maintenant, ce serait amusant
    • Je me demande à quel point les LLM seraient efficaces pour l’étiquetage. Je crains qu’ils ne fassent perdre du temps avec de mauvais labels
    • Maintenant que des outils comme Ghidra sont disponibles gratuitement, « décompilé à 100 % en C » ne me semble plus si extraordinaire
    • Comme le code source du Build engine est publié pour un usage non commercial, je me demande si cela pourrait aider à faire correspondre les noms de fonctions et de variables
  • Le fait que Gillou68310 semble avoir réalisé 99 % du travail en solo témoigne d’un engagement vraiment impressionnant. The Legend of Zelda: Twilight Princess avance aussi très bien https://decomp.dev/zeldaret/tp
    • J’en profite pour encourager aussi le projet de décompilation de Castlevania: Symphony of the Night. Ça avance plutôt bien (même s’il reste encore beaucoup à faire) https://github.com/Xeeynamo/sotn-decomp
  • Zero Hour faisait partie des titres incontournables de l’ère N64, et c’était l’un des rares bons jeux de la fin de la série Duke Nukem. Il y a des passages de plateforme exigeants et des niveaux parfois assez pénibles, mais j’ai toujours été impressionné par la solidité des environnements et par les efforts constants pour recréer le charme de Duke 3D. Le portage récent de Perfect Dark était excellent, donc j’espère que cette décompilation bénéficiera d’un traitement d’une qualité comparable
  • Je me demande pourquoi c’est précisément Duke Nukem: Zero Hour qui a été choisi
    • Zero Hour est une sorte de joyau un peu oublié. Les jeux Duke Nukem sur Playstation sont des clones de Tomb Raider assez mal considérés, alors que Zero Hour repose sur le Build engine comme le Duke Nukem 3D original. Ce n’est pas au même niveau, mais on peut dire que c’est le meilleur des Duke Nukem qui n’ont pas été faits par 3D Realms. Son principal défaut, c’est d’avoir adopté une vue à la troisième personne (il existe un mode première personne inachevé via un cheat) et des contrôles peu convaincants. Mais maintenant qu’on a le code source, on peut aussi corriger ce genre de problèmes
    • Bonne question. Cela dit, j’aurais aimé qu’il y ait des captures d’écran pour pouvoir le partager à mes amis. À l’époque, c’était le paradis du chaos quand on y jouait ensemble
  • Je me demande pourquoi des personnes (ou des groupes) investissent autant de temps et d’efforts dans ce type de projet de décompilation. Est-ce qu’il s’agit de communautés de passionnés attachés à leurs jeux favoris, ou est-ce surtout pour la préservation numérique ?
    • C’est moi qui ai réimplémenté Cosmo's Cosmic Adventure (DOS, 1992). La raison était simple : je voulais comprendre comment ce jeu arrivait à produire d’aussi chouettes astuces graphiques sur du matériel peu puissant (IBM AT). Ce n’est pas tant que le jeu soit exceptionnel, mais il représente un souvenir important de mon enfance, donc j’y étais très attaché. Cette expérience m’a permis de mieux comprendre la plateforme PC, l’écosystème C des années 80 et mes propres goûts https://github.com/smitelli/cosmore https://cosmodoc.org/
    • J’ai passé énormément de temps à faire de la rétro-ingénierie de firmwares de synthétiseurs vintage (plus simples que les jeux modernes). Par exemple, j’ai annoté les ROM des synthés Yamaha DX7 et DX9, et ce processus a énormément élargi mes compétences d’ingénierie. C’est amusant, et ça m’a aussi donné l’occasion de rencontrer des gens extrêmement brillants. C’est un peu comme un puzzle technique. Il en est même sorti des mods de firmware assez sympas annotation DX7 annotation DX9 DX97 et j’ai aussi écrit un tutoriel sur le processus de rétro-ingénierie tutoriel. C’est un peu comme de l’archéologie, on entrevoit la façon de penser des ingénieurs précédents. Et dans mon souvenir, le développement sur N64 n’était pas simple à l’époque
    • Ça peut tout simplement venir de l’amour du jeu. Moi aussi, j’adorais Mega Man Battle Network 2 quand j’étais enfant ; c’est ce jeu qui m’a fait apprendre l’anglais et devenir programmeur. J’ai encore deux cartouches physiques chez moi. De temps en temps, je l’analyse avec IDA pour essayer de le comprendre un peu mieux. Je n’ai ni le niveau ni le temps des vraies communautés de ROM hacking, mais j’essaie quand même
    • À mon avis, ce sont juste des gens qui ont envie de le faire eux-mêmes ou qui ont un goût particulier pour le défi
    • J’ai fait une présentation cette année à la Game On Expo sur la décompilation de Castlevania: Symphony of the Night https://github.com/xeeynamo/sotn-decomp. La plupart des gens qui participent à ce genre de travail sont motivés avant tout par l’amour qu’ils portent au jeu. Ensuite viennent le portage, le modding, l’apprentissage, le désir de préservation, etc. Personnellement, j’y trouve aussi le plaisir du défi (un peu comme résoudre un puzzle mathématique). Pour tenir sur la durée, il faut comprendre l’histoire et la théorie des compilateurs, ainsi que les contraintes commerciales et techniques de l’époque où le jeu a été développé. On finit alors parfois par comprendre pourquoi certaines parties du jeu ont été faites de cette manière. Je streame aussi mon travail sur SotN, et si vous avez des questions, elles sont toujours bienvenues dans le chat https://m.twitch.tv/madeupofwires/home
  • Super projet ! Mais… le fait que ce soit hébergé sur GitHub m’inquiète un peu. J’ai peur qu’un avis de suppression n’arrive bientôt
    • J’ai parcouru rapidement le dépôt, et il ne semble pas contenir de contenu protégé par le droit d’auteur. Il n’y a que le code qui effectue réellement la décompilation
    • Des décompilations de jeux Nintendo sont aussi publiées sur GitHub, donc je ne vois pas vraiment pourquoi celle-ci devrait être supprimée
  • Il faut souligner qu’il y a bien cette mention : « Ceci est une décompilation N64 de Duke Nukem Zero Hour. Note : vous devez posséder la cartouche du jeu pour utiliser ce dépôt »
  • Je me demande si les LLM sont adaptés à ce type de rétro-ingénierie
    • On peut automatiser pas mal d’étiquetage avec des LLM. Il devrait même être possible de « corriger en boucle jusqu’à correspondre au binaire », même si je n’ai pas vu d’exemple réellement abouti. À titre de référence, le projet decompai suit une approche similaire (bien que légèrement différente de ce projet-ci). Je l’ai testé moi-même, et quand on dispose déjà d’un peu d’informations, il est vraiment utile pour estimer les noms de variables. Il est particulièrement efficace pour les tâches fastidieuses et répétitives comme nommer des compteurs ou des variables temporaires. Il peut aussi déduire des noms de fonctions en reconnaissant des motifs algorithmiques
    • Je ne sais pas si l’EFF a publié une position officielle sur l’usage des LLM, mais je pense qu’il existe un risque juridique en matière de droit d’auteur. La décompilation est possible parce qu’elle produit une nouvelle œuvre créative, alors que les LLM peuvent plus facilement être accusés de produire des résultats dérivés ou non créatifs. Le fait que les entreprises d’IA paient des sommes énormes pour licencier des données d’entraînement complique encore la situation. Personnellement, j’éviterais de les utiliser à cause de ce risque. Mais si la décompilation assistée par LLM devient vraiment facile, on aura probablement bientôt une nouvelle jurisprudence
    • Je pense que c’est plutôt utile. Ce n’est pas parfait, mais ça fait gagner énormément de temps. En particulier pour identifier des fonctions de bibliothèque ou des algorithmes connus, c’est d’une précision presque hors de portée d’un humain. Il peut reconnaître du code même après qu’il a été altéré par les étapes de compilation et de décompilation
    • J’utilise des agents pour porter des jeux. Même avec le code source, ça se passe souvent mal. Comme les LLM essaient souvent d’éviter de porter beaucoup de bibliothèques, j’ai fréquemment fini avec plein de stubs et d’hypothèses, ce qui a embrouillé tout le travail au lieu de réduire la charge répétitive
    • Je ne les ai jamais utilisés moi-même, mais je pense qu’ils peuvent aider pour des améliorations locales comme le renommage de variables ou de fonctions
  • On insiste volontairement sur l’avertissement « il faut posséder la cartouche du jeu pour utiliser le dépôt »
    • Pour les gens qui utilisent des consoles portables rétro chinoises, il faut légalement extraire soi-même les ROM. Mais si on achète une version bon marché avec 10 000 jeux inclus, tout devient miraculeusement légal. De toute façon, presque personne n’est réellement poursuivi, donc ce genre d’avertissement me paraît presque mignon
    • En pratique, j’ai pu l’utiliser sans avoir la cartouche du jeu. Je pense donc que l’avertissement est faux
    • C’est simplement un avertissement juridique, pas une condition réellement appliquée
  • J’attends encore Duke Nukem Forever avec impatience. Honnêtement, je ne me souviens même plus depuis combien de temps