Duke Nukem: Zero Hour erreicht 100 % Decompilierung des N64-ROMs

 (github.com/Gillou68310)
1 Punkte von GN⁺ 2025-10-20 | 1 Kommentare | Auf WhatsApp teilen
  • Vorstellung eines Open-Source-Projekts, das das Nintendo-64-ROM von Duke Nukem: Zero Hour vollständig dekompiliert
  • Dieses Repository hat zu 100 % die Arbeit erreicht, den kompletten Original-Quellcode der Spielsoftware wiederherzustellen
  • Nutzer müssen die ROM des Spiels selbst besitzen, und mit der Original-US- oder französischen ROM ist ein vollständiger Build sowie Tests möglich
  • Gegenüber bestehenden Decompilation-Projekten zeichnet es sich durch vollständige funktionale Kompatibilität und Unterstützung von Debugging-Tools aus
  • Das Projekt ist eine äußerst wertvolle Ressource für Spiel-Engine-Forschung, Modifikation, Portierung und Engine-Analyse

Bedeutung und Wettbewerbsfähigkeit des Projekts

  • Duke Nukem: Zero Hour ist ein bekanntes Action-Spiel, das exklusiv auf der Nintendo-64-Plattform veröffentlicht wurde
  • Dieses Open-Source-Projekt dekompiliert die komplette ROM des Spiels vollständig mit C, Python usw. und rekonstruiert sie auf Quellcode-Ebene
  • Anders als andere N64-Decompilierungsprojekte bietet es vollständige Kompatibilität, einen funktionierenden ROM-Build und die Ausführung, Quellcode-basiertes Debugging sowie Mehrfachversionsunterstützung
  • Es hat einen erheblichen Quellenwert für die Erforschung der Game-Engine-Struktur und der Wissensgrundlagen der Konsolenspiel-Entwicklung der 1990er Jahre
  • Mehrere automatische Analyse-/Decompilierungs-Tools (asm-differ, mips2c, splat, decomp-permuter usw.) sind im Projekt integriert und maximieren die Effizienz der Entwickler

Hauptfunktionen und Architektur

Gesamtstruktur

  • Das Projekt ist mehrsprachig aufgebaut und in Teile in C (über 95 %), Python, Roff, C++, Makefile und Shell aufgeteilt
  • Wichtige Verzeichnisse:
    • .github/workflows: CI- und Automatisierungseinstellungen
    • include, libs, src: Spielquellcode, Bibliotheken und Header-Verwaltung
    • tools: Analyse-, Extraktions- und Konvertierungstools
    • versions: Struktur zur gleichzeitigen Unterstützung verschiedener Spielversionen, darunter US/FR
  • Das Projekt wird aktiv gepflegt, mit rund 370 Commits

Build- und Nutzungsmethodik

  • Ubuntu-20.04-Umgebung als Basis und Docker-Unterstützung
  • ROM-Extraktion, Bit-für-Bit-Vergleich, Unterstützung für den NON_MATCHING-Modus bei inkonsistenten Treffern
  • Unterstützung für die französische und US-ROM-Version, mit optionaler Konfiguration je nach Bedarf
  • Nutzung der Docker-Umgebung und der Mutagen Extension bietet OS-Kompatibilität für verschiedene Plattformen (WIN/Mac/Linux)

Debugging- und Entwicklungstools

  • Quellcode-basiertes Debugging auf Basis von gdb und mupen64plus (derzeit Windows-vorrangig)
  • Unterstützung für die Integration mit Visual Studio Code und der Native Debug Extension
  • Zentrale Automatisierungs- und Analysetools:
    • asm-differ: Vergleich von Assembler-Quelle/Ziel auf Assembly-Ebene
    • decomp-permuter: Neuausrichtung von Code und automatische Punktvergabe
    • mips2c: Konvertierung von MIPS-Assembler nach C
    • splat: ROM-Strukturanalyse-Tool

Einsatzmöglichkeiten

  • Nutzungsmöglichkeiten für Spiel-Reverse-Engineering, Portierung, Engine-Analyse und klassische Spiele-Verbesserungsprojekte
  • Sehr geeignet auch für historische Erhaltung und Bildungsforschung
  • Laufende Wartung und Updates erfolgen aktiv für verschiedene Plattformen und Versionen

Fazit

  • Dieses Open-Source-Projekt ist ein seltener Fall, der eine vollständige Offenlegung des vollständigen Quellcodes von klassischer Konsolenspielsoftware der 1990er Jahre realisiert
  • Für Forscher im Bereich Spiel- und Konsolen-Reverse-Engineering, junge Entwickler sowie für Portierungs- und Fangame-Entwickler ist es eine wertvolle Ressource

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-20
Hacker-News-Kommentare
  • Ich finde es faszinierend, dass es zwar zu 100 % nach C dekompiliert wurde, aber viele Funktions- und Variablennamen noch automatisch generiert sind und die Beschriftung daher noch nicht vollständig ist. Es wäre spannend, wenn jetzt jemand versuchen würde, es zu portieren
    • Ich frage mich, wie effektiv ein LLM beim Labeling wäre. Ich hätte Sorge, dass man mit falschen Bezeichnungen am Ende Zeit verschwendet
    • Heutzutage sind Tools wie Ghidra kostenlos verfügbar, deshalb wirkt „zu 100 % nach C dekompiliert“ nicht mehr wie eine so große Sache
    • Der Source Code der Build Engine ist für nichtkommerzielle Zwecke freigegeben, daher frage ich mich, ob das beim Mapping von Funktions- und Variablennamen helfen könnte
  • Es sieht so aus, als hätte Gillou68310 99 % davon allein gemacht, was ich für eine wirklich beeindruckende Hingabe halte. Auch The Legend of Zelda: Twilight Princess macht gute Fortschritte https://decomp.dev/zeldaret/tp
    • Bei der Gelegenheit möchte ich auch das Decompilation-Projekt zu Castlevania: Symphony of the Night unterstützen. Es kommt ziemlich gut voran (auch wenn noch viel zu tun ist) https://github.com/Xeeynamo/sotn-decomp
  • Zero Hour war einer der Pflicht-Titel der N64-Ära und eines der seltenen guten Spiele aus der späteren Duke-Nukem-Reihe. Es gibt zwar anspruchsvolle Platforming-Elemente und einige ziemlich frustrierende Level, aber die konstant solide Gestaltung der Umgebungen und der Versuch, den Charme von Duke 3D nachzubilden, waren beeindruckend. Der jüngste Perfect-Dark-Port war großartig, daher hoffe ich, dass diese Decompilation ähnlich hochwertig behandelt wird
  • Ich frage mich, warum ausgerechnet Duke Nukem: Zero Hour ausgewählt wurde
    • Zero Hour ist so etwas wie ein etwas vergessenes Juwel. Die Duke-Nukem-Spiele auf der Playstation sind eher Tomb-Raider-Klone und wurden auch nicht besonders gut bewertet, aber Zero Hour basiert wie das originale Duke Nukem 3D auf der Build Engine. Zwar erreicht es dessen Niveau nicht ganz, aber man könnte es trotzdem als das beste Duke-Nukem-Spiel außerhalb von 3D Realms bezeichnen. Ein Nachteil ist, dass die Perspektive auf Third-Person umgestellt wurde (einen unfertigen First-Person-Modus gibt es per Cheat) und sich die Steuerung nicht besonders gut anfühlt. Aber da der Source Code jetzt da ist, kann man solche Probleme vielleicht beheben
    • Gute Frage. Ich wünschte allerdings, es gäbe Screenshots, dann könnte ich es mit Freunden teilen. Früher war es mit Freunden pures Chaos und ein Riesenspaß
  • Ich frage mich, warum Menschen (oder Gruppen) Zeit und Mühe in solche Decompilation-Projekte stecken. Ob es eher eine Gruppe von Hobby-Gamern ist, die ihre Lieblingstitel lieben, oder ob es mehr um digitale Bewahrung geht, würde mich interessieren
    • Ich bin die Person, die Cosmo's Cosmic Adventure (DOS, 1992) neu implementiert hat. Der Grund war einfach, dass ich wissen wollte, wie dieses Spiel auf leistungsschwacher Hardware (IBM AT) so coole Grafiktricks umsetzen konnte. Nicht, weil das Spiel objektiv besonders herausragend wäre, sondern weil es ein wichtiger Teil meiner Kindheit war und ich deshalb eine Bindung dazu hatte. Durch diese Erfahrung habe ich die PC-Plattform, das C-Ökosystem der 80er und meinen eigenen Geschmack besser verstanden https://github.com/smitelli/cosmore https://cosmodoc.org/
    • Ich habe viel Zeit darauf verwendet, Firmware für Vintage-Synthesizer zu reverse engineeren (einfacher als moderne Spiele). Zum Beispiel habe ich die ROMs der Yamaha-DX7- und DX9-Synthesizer kommentiert, und dieser Prozess hat meine technischen Fähigkeiten stark erweitert. Es hat Spaß gemacht, und ich habe dabei die Gelegenheit gehabt, unglaublich kluge Leute kennenzulernen. Es ist wie ein technisches Puzzlespiel. Daraus sind auch interessante Firmware-Mods entstanden DX7 annotiert DX9 annotiert DX97 und ich habe auch ein Tutorial über den Reverse-Engineering-Prozess geschrieben Tutorial. Es ist ein bisschen wie Archäologie, weil man Einblick in die Denkweise früherer Ingenieure bekommt. Ich erinnere mich auch daran, dass die N64 damals als schwer zu entwickeln galt
    • Es kann einfach Liebe zu einem Spiel sein. Ich mochte als Kind Mega Man Battle Network 2 wirklich sehr, und dieses Spiel hat mir sogar geholfen, Englisch zu lernen und Programmierer zu werden. Ich besitze sogar noch zwei physische Cartridges davon. Manchmal analysiere ich es mit IDA und versuche, das Spiel Stück für Stück besser zu verstehen. Ich habe zwar nicht das Können oder die Zeit der eigentlichen ROM-Hacking-Community, aber ich versuche es trotzdem
    • Meiner Ansicht nach sind das Leute, die es einfach selbst machen wollen oder einen besonders starken Herausforderungssinn haben
    • Ich habe dieses Jahr auf der Game On Expo einen Vortrag über die Decompilation von Castlevania: Symphony of the Night gehalten https://github.com/xeeynamo/sotn-decomp. Die meisten Leute, die an solchen Arbeiten teilnehmen, werden vor allem durch ihre Liebe zu einem Spiel motiviert. Danach kommen Portierung, Modding, Lernen, Bewahrungswille und vieles mehr. Für mich persönlich macht auch die Herausforderung selbst Spaß (ähnlich wie ein mathematisches Rätsel). Wenn man lange daran arbeitet, muss man Compiler-Historie und Theorie verstehen, ebenso wie die geschäftlichen und technischen Zwänge zur Zeit der Spieleentwicklung. Dabei begreift man mitunter auch, warum bestimmte Teile eines Spiels so gebaut wurden. Ich streame auch die Arbeit an SotN, und Fragen im Chat sind jederzeit willkommen https://m.twitch.tv/madeupofwires/home
  • Tolles Projekt! Aber … ich bin etwas nervös wegen der Plattform GitHub. Ich fürchte, dass bald eine Löschaufforderung kommt
    • Ich habe das Repository kurz durchgesehen, und es scheint kein urheberrechtlich geschütztes Material zu enthalten. Es ist nur der Code hochgeladen, der die eigentliche Decompilation durchführt
    • Auch Nintendo-Spiel-Decompilations sind öffentlich auf GitHub, deshalb verstehe ich nicht, warum das gelöscht werden sollte
  • Ich möchte betonen, dass dort der Hinweis steht: „Dies ist die Duke Nukem Zero Hour N64-Decompilation. Hinweis: Um dieses Repository zu verwenden, musst du das Spielmodul besitzen“
  • Ich frage mich, ob LLMs für so eine Art von Reverse Engineering geeignet sind
    • Mit LLMs kann man ziemlich viel Labeling automatisieren. „So lange iterativ anpassen, bis es mit dem Binärformat übereinstimmt“ scheint theoretisch auch möglich, aber ich habe noch kein tatsächlich aufgeräumtes Beispiel dafür gesehen. Als Referenz gibt es das Projekt decompai, das einen ähnlichen Ansatz verfolgt (wenn auch etwas anders als dieses Projekt). Ich habe es selbst ausprobiert, und wenn bereits ein gewisser Kontext vorhanden ist, ist es bei der Schätzung von Variablennamen ziemlich nützlich. Besonders effektiv ist es bei langweiligen, repetitiven Aufgaben wie dem Benennen von Zählern oder temporären Variablen. Auch Funktionsnamen lassen sich anhand von Algorithmusmustern teilweise erschließen
    • Ich weiß nicht, ob die EFF dazu schon eine offizielle Position zur Nutzung von LLMs veröffentlicht hat, aber ich denke, aus urheberrechtlicher Sicht besteht ein rechtliches Risiko. Decompilation ist möglich, weil dabei ein neues kreatives Werk entsteht, während man bei LLMs leicht der Behauptung ausgesetzt ist, sie würden nur abgeleitete oder nicht-kreative Ergebnisse erzeugen. Dass AI-Unternehmen enorme Summen für Trainingsdatenlizenzen zahlen, macht die Lage noch komplizierter. Ich würde ihre Nutzung wegen dieses Copyright-Risikos eher vermeiden. Wenn Decompilation mithilfe von LLMs aber wirklich sehr einfach wird, dürfte es bald neue Präzedenzfälle geben
    • Ich halte sie für ziemlich brauchbar. Perfekt sind sie nicht, aber sie sparen viel Zeit. Besonders bei der Identifikation von Bibliotheksfunktionen oder bekannten Algorithmen sind sie so präzise, dass Menschen kaum mithalten können. Sie erkennen das selbst dann noch, wenn der Code durch Kompilierung und Decompilation stark verändert wurde
    • Ich portiere gerade ein Spiel mit Hilfe von Agenten. Selbst wenn Source Code vorhanden ist, läuft es oft nicht gut. LLMs versuchen häufig nicht einmal, viele Bibliotheken zu portieren, und der Versuch, repetitive Arbeit zu reduzieren, führt stattdessen oft zu einem Haufen Stubs und Annahmen, die das ganze Projekt verheddern
    • Ich habe es selbst noch nie benutzt, aber ich denke, für lokale Verbesserungen wie das Umbenennen von Variablen und Funktionen könnte es hilfreich sein
  • Es wird absichtlich noch einmal auf den Hinweis hingewiesen: „Um das Repository zu verwenden, muss man das Spielmodul besitzen“
    • Wer chinesische Retro-Handhelds benutzt, muss seine ROMs selbst extrahieren, damit es legal ist. Kauft man aber die billige Variante mit 10.000 Spielen im Paket, ist auf wundersame Weise plötzlich alles legal. Natürlich wird in Wirklichkeit kaum jemand dafür belangt, deshalb wirkt so ein Hinweis fast niedlich
    • Tatsächlich konnte ich es auch ohne Spielmodul problemlos verwenden. Ich denke, der Hinweis ist falsch
    • Das ist in Wirklichkeit nur ein juristischer Disclaimer und keine echte Nutzungsvoraussetzung
  • Ich warte immer noch sehnsüchtig auf Duke Nukem Forever. Ich weiß schon gar nicht mehr, wie lange das inzwischen her ist