Projeto de engenharia reversa do ROM de Duke Nukem: Zero Hour no N64 atinge 100%

• Apresenta um projeto open source que decompila perfeitamente o ROM do Nintendo 64 de Duke Nukem: Zero Hour
• Este repositório alcançou 100% na tarefa de recuperar todo o código-fonte do software do jogo original
• O usuário precisa possuir a ROM do jogo, e é possível compilar e testar tudo por meio da ROM original dos EUA ou da versão francesa
• Em comparação com projetos de decompilação já existentes, se destaca pela compatibilidade funcional completa e suporte a ferramentas de depuração
• Este projeto é uma fonte extremamente valiosa para pesquisa de engine, modificação, porting e análise de engine de jogos

---

Relevância e competitividade do projeto

• Duke Nukem: Zero Hour é um famoso jogo de ação lançado exclusivamente na plataforma Nintendo 64
• Este projeto open source recompõe totalmente a ROM completa desse jogo a partir de decompilação em C, Python, entre outras linguagens, reconstruindo tudo em nível de código-fonte
• Diferente de outros projetos de decompilação de N64, ele garante compatibilidade total, oferecendo build e execução normais de ROM, depuração baseada em código-fonte e suporte a múltiplas versões
• Possui valor de referência excepcional para pesquisar a estrutura da engine de jogos e o know-how de desenvolvimento de jogos de console dos anos 1990
• Várias ferramentas automáticas de análise/decompilação (asm-differ, mips2c, splat, decomp-permuter etc.) estão integradas ao projeto, maximizando a eficiência do desenvolvedor

Recursos e estrutura principais

Estrutura geral

• O projeto é composto por múltiplos idiomas, com partes separadas em C (acima de 95%), Python, Roff, C++, Makefile e Shell
• Diretórios principais:
  • .github/workflows: configurações de CI e automação
  • include, libs, src: gerenciamento de código-fonte e bibliotecas do jogo, cabeçalhos
  • tools: ferramentas de análise, extração e conversão
  • versions: estrutura de suporte a múltiplas versões do jogo, como US/FR
• O projeto é mantido ativamente, com perto de 370 commits

Resumo de build e uso

• Ambiente baseado em Ubuntu 20.04 com suporte a Docker
• Suporte para extração de ROM, comparação bit a bit e modo NON_MATCHING para não correspondência
• Suporte para ROM da versão francesa e versão americana, com opções configuráveis conforme a necessidade do usuário
• Compatibilidade com vários sistemas operacionais (Windows/Mac/Linux) por meio de ambiente Docker e Mutagen Extension

Ferramentas de depuração e desenvolvimento

• Depuração em nível de código-fonte com base em gdb e mupen64plus (atualmente com foco em Windows)
• Suporte de integração com Visual Studio Code e Native Debug Extension
• Ferramentas centrais de automação e análise:
  • asm-differ: comparação de origem e destino em nível de assembly
  • decomp-permuter: reajuste de código e pontuação automática
  • mips2c: conversão de assembly MIPS para C
  • splat: ferramenta de análise da estrutura da ROM

Casos de uso

• Possibilidade de uso do código em engenharia reversa de jogos, porting, análise de engine e projetos de melhoria de jogos clássicos
• Também muito adequado para preservação histórica e pesquisa educacional
• Manutenção e atualizações ativas seguem em andamento para diversas plataformas e versões

Conclusão

• Este projeto open source é um caso raro que realiza a liberação completa do código-fonte de software de jogos clássicos de console dos anos 1990
• Um recurso valioso para pesquisadores de engenharia reversa de jogos e consoles, desenvolvedores iniciantes, e criadores de ports e fan games

[GN⁺]

Opiniões no Hacker News

• Acho interessante que ele já esteja 100% decompilado em C, mas ainda haja muitas partes com nomes de funções e variáveis gerados automaticamente, então a rotulagem ainda não está totalmente concluída. Seria divertido se alguém tentasse fazer um port agora
  • Fico na dúvida sobre o quão eficaz um LLM seria para rotulagem. Não acabaria fazendo a gente perder tempo com rótulos errados?
  • Hoje em dia ferramentas como o Ghidra são oferecidas gratuitamente, então "100% decompilado em C" já não parece algo tão impressionante assim
  • Como o código-fonte do Build engine foi liberado para fins não comerciais, fico curioso se isso poderia ajudar a mapear nomes de funções e variáveis
• Parece que o Gillou68310 fez 99% praticamente sozinho, o que acho uma dedicação realmente impressionante. The Legend of Zelda: Twilight Princess também está avançando bem https://decomp.dev/zeldaret/tp
  • Aproveitando, também queria torcer pelo projeto de decompilação de Castlevania: Symphony of the Night. Está indo muito bem (ainda há bastante coisa a fazer) https://github.com/Xeeynamo/sotn-decomp
• Zero Hour foi um dos títulos essenciais da era N64 e era um dos raros bons jogos da fase final da série Duke Nukem. Apesar dos elementos de plataforma desafiadores e de fases bem sofridas, sempre impressionou pelo esforço consistente em recriar ambientes sólidos e o charme de Duke 3D. Como o port recente de Perfect Dark ficou excelente, espero que esta decompilação receba um tratamento de qualidade semelhante
• Fico me perguntando por que justamente Duke Nukem: Zero Hour foi escolhido
  • Zero Hour é uma espécie de joia esquecida. Os jogos de Duke Nukem no Playstation eram clones de Tomb Raider e nem eram muito bem avaliados, mas Zero Hour é baseado no Build engine, como o Duke Nukem 3D original. Embora não chegue a esse nível, dá até para dizer que é o melhor jogo da série Duke Nukem que não foi feito pela 3D Realms. O ponto fraco é que mudaram a câmera para terceira pessoa (há um modo incompleto em primeira pessoa via cheat) e os controles não são muito bons. Mas agora que há o código-fonte, esses problemas também podem ser corrigidos
  • Boa pergunta. Só fico triste por não ter screenshots, porque eu queria compartilhar com meus amigos. Quando eu jogava isso com eles antigamente, era um paraíso do caos
• Fico curioso sobre por que uma pessoa (ou grupo) dedica tanto tempo e esforço a projetos de decompilação assim. Queria saber se isso vem de comunidades de jogadores hobbyistas que amam um título específico, ou se o objetivo é preservação digital
  • Fui eu quem reimplementou Cosmo's Cosmic Adventure (DOS, 1992). O motivo era simples: eu queria entender como esse jogo conseguia fazer truques gráficos tão legais em um hardware fraco (IBM AT). Não é que o jogo seja extraordinário, mas ele era uma memória importante da minha infância, então eu tinha apego a ele. Com essa experiência, aprendi sobre a plataforma PC, o ecossistema de C dos anos 80 e também sobre meus próprios gostos https://github.com/smitelli/cosmore https://cosmodoc.org/
  • Já dediquei muito tempo a fazer engenharia reversa de firmware de sintetizadores vintage (mais simples que jogos modernos). Por exemplo, já anotei ROMs de sintetizadores Yamaha DX7 e DX9, e esse processo ampliou muito minhas habilidades de engenharia. Também é divertido, e dá para conhecer gente extremamente inteligente. É como um quebra-cabeça técnico. Desse processo também saíram mods de firmware bem interessantes anotação do DX7 anotação do DX9 DX97 e até escrevi um tutorial sobre o processo de engenharia reversa tutorial. Também há algo de arqueologia nisso, porque você acaba tendo um vislumbre da forma de pensar dos engenheiros anteriores. E lembro que o N64 também era uma plataforma difícil de desenvolver na época
  • Pode ser simplesmente amor pelo jogo. Eu também adorava Mega Man Battle Network 2 quando era criança, e foi esse jogo que me fez aprender inglês e virar programador. Tenho até duas cópias físicas do cartucho guardadas. Às vezes analiso com o IDA e tento entender o jogo aos poucos, embora eu não tenha a habilidade nem o tempo da comunidade de ROM hacking de verdade, mas continuo tentando
  • Na minha visão, são pessoas que simplesmente querem fazer isso por conta própria ou têm um espírito de desafio fora do comum
  • Este ano apresentei sobre a decompilação de Castlevania: Symphony of the Night na Game On Expo https://github.com/xeeynamo/sotn-decomp. A motivação da maioria das pessoas que participa desse tipo de trabalho é simplesmente amar demais o jogo. Depois vêm coisas como port, modding, estudo, desejo de preservação etc. Pessoalmente, também acho divertido pelo desafio em si (parece um pouco resolver um quebra-cabeça matemático). Para trabalhar nisso por muito tempo, é preciso entender a história e a teoria dos compiladores, além das pressões comerciais e de engenharia da época em que o jogo foi feito. Nesse processo, às vezes você percebe por que certas partes do jogo foram feitas daquele jeito. Também faço transmissões do trabalho em SotN, e qualquer pergunta no chat é bem-vinda https://m.twitch.tv/madeupofwires/home
• Projeto muito legal! Mas... fico um pouco preocupado por a plataforma ser o GitHub. Não corre o risco de receber logo uma notificação para remoção?
  • Dei uma olhada rápida no repositório e não parece haver material protegido por direitos autorais. Só está publicado o código que realiza a decompilação em si
  • Há decompilações de jogos da Nintendo publicadas no GitHub, então não vejo por que isso precisaria ser removido
• Destaco que há um aviso dizendo: "Isto é uma decompilação de Duke Nukem Zero Hour para N64. Observação: você precisa ter o cartucho do jogo para usar este repositório"
• Fico curioso se LLMs são adequados para esse tipo de engenharia reversa
  • Dá para automatizar bastante a rotulagem com LLMs. Talvez até seja possível fazer algo como "corrigir iterativamente até bater com o binário", embora eu ainda não tenha visto um caso realmente organizado disso. Como referência, o projeto decompai segue uma abordagem parecida (ainda que um pouco diferente deste projeto). Já rodei isso, e quando já existe alguma informação disponível, é bastante útil para estimar nomes de variáveis. Funciona especialmente bem em tarefas chatas e repetitivas, como nomear contadores ou variáveis temporárias. Também dá para inferir nomes de funções observando padrões de algoritmo
  • Não sei se a EFF já publicou uma posição oficial sobre o uso de LLMs nisso, mas acho que existe risco jurídico do ponto de vista de direitos autorais. A decompilação é possível porque gera uma nova obra criativa, mas LLMs podem ficar muito expostos à alegação de produzirem resultados derivados e não criativos. O fato de empresas de IA estarem pagando fortunas por licenças de dados de treinamento também complica o cenário. Eu evitaria usar por esse risco autoral. Mas, se decompilar com LLM realmente ficar muito fácil, logo deve surgir nova jurisprudência
  • Acho que são bastante úteis. Não são perfeitos, mas economizam muito tempo. Especialmente na identificação de funções de biblioteca ou algoritmos conhecidos, chegam a ser precisos em um nível que humanos mal conseguem alcançar. Eles reconhecem isso até em código degradado ao passar por compilação e decompilação
  • Estou usando agentes para portar um jogo. Mesmo com o código-fonte, muitas vezes não dá certo. Como LLMs evitam portar muitas bibliotecas, já aconteceu várias vezes de eu tentar reduzir o trabalho repetitivo e acabar, na prática, com um monte de stubs e suposições, embolando o trabalho inteiro
  • Nunca usei, mas imagino que ajudem em melhorias localizadas, como renomear variáveis e funções
• Algumas pessoas chamaram atenção de propósito para o aviso de que "é preciso ter o cartucho do jogo para usar o repositório"
  • Quem usa portáteis retrô chineses precisa extrair a própria ROM para estar dentro da lei. Mas, se você compra uma versão baratinha com 10 mil jogos incluídos, misteriosamente tudo vira legal. Como quase ninguém é punido de verdade, esse tipo de aviso acaba parecendo até fofo
  • Na prática, consegui usar sem ter o cartucho do jogo. Então acho que o aviso está errado
  • Isso é só um aviso jurídico mesmo, não um requisito real de aplicação
• Ainda estou esperando ansiosamente Duke Nukem Forever. Já faz tanto tempo que mal consigo lembrar há quanto
  • Não sei se é brincadeira, mas caso você não soubesse, Duke Nukem Forever já foi lançado no Steam https://store.steampowered.com/agecheck/app/57900/