Duke Nukem: Zero Hour N64 ROM 리버스 엔지니어링 프로젝트 100% 달성
(github.com/Gillou68310)- Duke Nukem: Zero Hour의 Nintendo 64 ROM을 완벽하게 디컴파일링한 오픈소스 프로젝트 소개임
 - 이 리포지토리는 원게임 소프트웨어의 모든 소스 코드를 되살리는 작업을 100% 달성함
 - 사용자는 직접 게임의 ROM을 소유해야 하며, 원본 US 또는 프랑스판 ROM을 통해 전체 빌드와 테스트가 가능함
 - 기존에 존재하던 디컴파일 프로젝트들과 비교해, 완벽한 기능적 호환성과 디버깅 툴 지원으로 기술적 우위를 가짐
 - 이 프로젝트는 게임 엔진 연구, 변형, 이식, 그리고 엔진 분석에 매우 가치 있는 자료임
 
프로젝트 의의와 경쟁력
- Duke Nukem: Zero Hour는 Nintendo 64 플랫폼에서 독점적으로 발매된 유명 액션 게임임
 - 본 오픈소스 프로젝트는 해당 게임의 전체 ROM을 C, Python 등으로 완전하게 디컴파일링해 소스 코드 레벨에서 재구성함
 - 다른 N64 디컴파일 프로젝트와 달리 완벽한 호환성을 확보, 정상적인 ROM 빌드와 실행, 소스 코드 기반 디버깅, 멀티 버전 지원까지 제공함
 - 게임 엔진 구조와 90년대 콘솔 게임 개발 노하우를 연구하는 데 탁월한 자료적 가치를 지님
 - 여러 자동 분석/디컴파일 툴(asm-differ, mips2c, splat, decomp-permuter 등)이 프로젝트에 통합되어 개발자의 효율성을 극대화함
 
주요 기능 및 구조
전체 구조
- 프로젝트는 다중 언어로 구성되어 있으며, C(95% 이상), Python, Roff, C++, Makefile, Shell 등으로 각 파트가 나뉨
 - 주요 디렉터리:
- .github/workflows: CI 및 자동화 설정
 - include, libs, src: 게임 소스 및 라이브러리, 헤더 관리
 - tools: 분석, 추출, 변환 도구
 - versions: US/FR 등 여러 게임 버전 동시 지원 구조
 
 - 약 370회 가까이 커밋되어 활발하게 유지 관리됨
 
빌드 및 사용 방법 요약
- Ubuntu 20.04 기준 환경 및 Docker 지원
 - ROM 추출, 비트 단위 비교, 비정상 일치(NON_MATCHING) 모드 지원
 - 프랑스어 버전과 미국 버전 ROM을 모두 지원, 사용자 필요에 따라 옵션 지정 가능
 - Docker 환경 및 Mutagen Extension을 활용하여 다양한 OS(WIN/Mac/Linux) 호환성 제공
 
디버깅 및 개발 도구
- gdb와 mupen64plus 기반 소스 코드 레벨 디버깅 지원(현재 Windows 우선)
 - Visual Studio Code 및 Native Debug Extension과의 연동 지원
 - 핵심 자동화 및 분석 도구:
- asm-differ: 어셈블리 수준 소스/타깃 비교
 - decomp-permuter: 코드 재조정 및 자동 점수화
 - mips2c: MIPS 어셈블리에서 C로 코드 변환
 - splat: rom 구조 분석 툴
 
 
활용 방안
- 게임 리버스 엔지니어링, 이식, 엔진 분석, 고전 게임 개선 프로젝트의 소스 활용 가능성
 - 역사적 보존 및 교육적 연구 목적에도 매우 적합함
 - 다양한 플랫폼과 버전에 대한 유지보수 및 업데이트가 활발히 진행 중임
 
결론
- 이 오픈소스 프로젝트는 90년대 클래식 콘솔 게임 소프트웨어의 완전한 소스 공개를 실현한 보기 드문 사례임
 - 게임 및 콘솔 리버스 엔지니어링 연구자, 젊은 개발자, 게임 이식 및 팬 게임 제작자 모두에게 값진 자원임
 
Hacker News 의견
- 100% C로 디컴파일된 상태이지만, 함수와 변수 이름이 자동 생성된 부분이 많아서 아직 라벨링이 완전하지 않음에 흥미로움을 느낌. 누가 지금쯤 포팅을 시도한다면 재미있겠음
- LLM이 라벨링에 얼마나 효과적일지 의문임. 잘못된 라벨링으로 시간 낭비하는 일이 생기지 않을까 걱정임
 - 요즘에는 Ghidra 같은 툴이 무료로 제공되기 때문에, "100% C로 디컴파일"이 그리 대단한 일은 아닌 느낌임
 - 빌드 엔진의 소스코드가 비영리 목적으로 공개되어 있으니, 함수와 변수 이름을 매핑하는 데 도움될 수 있을까 궁금함
 
 - Gillou68310이 99%를 혼자 해낸 듯해서 정말 대단한 헌신이라 생각함. The Legend of Zelda: Twilight Princess도 잘 진행 중임 https://decomp.dev/zeldaret/tp
- 이 기회에 Castlevania: Symphony of the Night 디컴파일 프로젝트에도 응원하고 싶음. 꽤 잘 되고 있는 중임 (아직 할 일은 많음) https://github.com/Xeeynamo/sotn-decomp
 
 - Zero Hour는 N64 시대의 필수 타이틀 중 하나였고, Duke Nukem 시리즈 후반부에서 드물게 좋은 게임이었음. 도전적인 플랫폼 요소와 꽤 괴로운 스테이지도 있지만, 꾸준히 탄탄한 환경과 Duke 3D의 매력을 재현하려는 노력이 인상적이었음. 최근의 Perfect Dark 이식이 훌륭해서 이번 디컴파일도 비슷한 퀄리티로 다뤄지길 기대함
 - 왜 하필이면 Duke Nukem: Zero Hour가 선택됐는지 궁금함
- Zero Hour는 조금 잊힌 보석 같은 작품임. Playstation의 Duke Nukem 게임들은 Tomb Raider의 아류에다 평가도 별로지만, Zero Hour는 오리지널 Duke Nukem 3D처럼 Build 엔진 기반임. 비록 그 수준까지는 아니지만 3D Realms가 아닌 Duke Nukem 시리즈 중에서는 가장 좋다는 평가도 가능함. 단점이라면 시점을 3인칭으로 바꿨고(미완성 1인칭 모드는 치트로 있음) 조작감이 별로라는 점임. 하지만 소스 코드가 있으니 이제는 이런 문제도 고칠 수 있음
 - 좋은 질문임. 다만 스크린샷이 있었으면 친구들에게 공유하고 싶어서 아쉬움. 예전에 친구들과 플레이할 때 혼돈의 낙원이었음
 
 - 이런 디컴파일 프로젝트에 사람(혹은 그룹)이 시간과 노력을 들이는 이유가 궁금함. 좋아하는 게임 타이틀을 사랑하는 취미 게이머 모임이 있는 것인지, 혹은 디지털 보존 목적 때문인지 알고 싶음
- 나는 Cosmo's Cosmic Adventure(DOS, 1992)를 다시 구현했던 사람임. 이유는 단순히 이 게임이 성능 약한 하드웨어(IBM AT)에서 어떻게 멋진 그래픽 트릭을 구현했는지 궁금해서였음. 이 게임이 뭔가 뛰어나다기보다는 내 어린 시절 중요한 추억이라 애착이 있었음. 이 경험을 통해 PC 플랫폼, 80년대 C 생태계, 그리고 내 취향을 알게 되었음 https://github.com/smitelli/cosmore https://cosmodoc.org/
 - 나는 빈티지 신시사이저 펌웨어를 리버스 엔지니어링하는 데 많은 시간을 쏟았음 (현대 게임보다 단순). 예를 들어 Yamaha DX7, DX9 신스 롬을 주석처리해봤고, 이 과정이 내 엔지니어링 스킬을 크게 넓혀줬음. 재미도 있고, 엄청 똑똑한 분들을 만나는 기회도 있었음. 기술적 조각맞추기 놀이 같음. 이 과정 덕분에 나온 재미있는 펌웨어 모드도 있음 DX7 주석화 DX9 주석화 DX97 그리고 리버스 엔지니어링 과정에 대한 튜토리얼도 작성함 튜토리얼 고고학처럼 이전 엔지니어의 사고방식을 엿보게 되기도 함. N64도 당시로서는 개발 난이도가 있었던 기억임
 - 단순히 게임에 대한 애정 때문일 수 있음. 나도 어린 시절 Mega Man Battle Network 2라는 게임을 정말 아꼈고, 그 게임 덕에 영어도 배우고 프로그래머가 되었음. 두 개의 실물 카트리지를 보관하고 있을 정도임. 가끔 IDA로 분석하며 조금씩 게임을 이해하려고 하지만, 실제 ROM 해킹 커뮤니티만큼 실력이나 시간은 없지만 그래도 시도 중임
 - 내가 볼 때 직접 해보고 싶거나 남달리 도전 정신이 있는 분들임
 - 올해 Game On Expo에서 Castlevania: Symphony of the Night 디컴파일에 대해 발표했었음 https://github.com/xeeynamo/sotn-decomp. 대부분 이런 작업에 참여하는 사람들은 게임을 너무 사랑하는 게 동기임. 그 다음은 포팅, 모딩, 공부, 보존욕구 등 다양함. 개인적으로는 도전의 재미도 있음(수학 퍼즐 맞추기와 비슷한 느낌). 오래 작업하려면 컴파일러 히스토리와 이론, 그리고 게임 제작 당시의 비즈니스와 공학적 압박까지 이해할 필요가 있음. 이 과정에서 왜 게임 일부가 그렇게 만들어졌는지 깨닫게 되기도 함. SotN 작업하는 방송도 하고, 질문 있으면 채팅으로 뭐든 환영임 https://m.twitch.tv/madeupofwires/home
 
 - 멋진 프로젝트임! 그런데… 플랫폼이 GitHub라 살짝 걱정스러움. 곧 삭제 통보가 오지 않을까 우려임
- 저장소를 빠르게 살펴보니 저작권 자료는 없는 것 같음. 실제로 디컴파일을 수행하는 코드만 올라와 있음
 - Nintendo 게임 디컴파일도 GitHub에서 공개 중인데 굳이 왜 삭제되어야 하는지 모르겠음
 
 - “Duke Nukem Zero Hour N64 디컴파일입니다. 참고: 이 저장소를 사용하려면 게임 카트리지가 있어야 합니다”라는 안내가 있음을 강조함
 - LLM이 이런 리버스 엔지니어링에 적합한지 궁금함
- LLM으로 라벨링을 꽤 많이 자동화할 수 있음. "바이너리와 일치할 때까지 반복 수정"도 가능할 것 같긴 한데, 실제로 정리한 사례는 못 봤음. 참고로 decompai 프로젝트가 비슷한 접근임(이 프로젝트와는 약간 다름). 직접 돌려봤는데, 이미 어느 정도 정보가 있으면 변수명 추정에 상당히 유용함. 카운터나 임시변수 네이밍처럼 지루하고 반복적인 작업에 특히 효과적임. 함수 이름도 알고리즘 패턴을 보면서 추론 가능함
 - LLM 활용에 대해 EFF에서 공식 입장을 냈는지 모르겠으나 저작권 측면에서 법적 위험이 있다고 생각함. 디컴파일은 새로운 창작물이 나오기 때문에 가능하지만, LLM은 파생적/비창작적인 결과를 만들어낸다는 주장에 쉽게 노출될 수 있음. AI 기업들이 학습 데이터 라이선스에 거액을 지불하는 것도 상황을 복잡하게 함. 나는 이런 저작권 위험 때문에 사용하는 걸 피할 것 같음. 하지만 만약 LLM을 이용한 디컴파일이 정말 쉬워지면, 곧 새로운 판례가 나올 듯함
 - 꽤 쓸만하다고 봄. 완벽하진 않지만 시간을 크게 줄여줌. 특히 라이브러리 함수나 유명 알고리즘 식별엔 사람이 범접할 수 없을 정도로 정확함. 컴파일과 디컴파일 과정을 거치며 훼손된 코드에서도 알아봄
 - 에이전트를 활용해 게임 포팅 중임. 소스코드가 있는데도 잘 안 풀리는 경우가 많음. LLM이 많은 라이브러리를 포팅하려 하지 않아서 반복 작업량을 줄이려다 오히려 스텁과 가정 투성이가 되어 전체 작업이 꼬였던 적이 많음
 - 내가 써본 적은 없지만 변수명/함수명 리네이밍처럼 국소적인 개선엔 도움이 될 것이라 생각함
 
 - “저장소를 사용하려면 게임 카트리지 소유 필요”라는 주의를 일부러 언급함
- 중국산 레트로 휴대용 게임기를 쓰는 사람들은 직접 ROM을 추출해야 합법임. 하지만 1만개 게임 묶음의 저렴판을 사면 신기하게도 모두 합법이 됨. 물론 정말 처벌받는 사람은 거의 없으니 이런 고지사항이 귀엽게 느껴짐
 - 실제론 게임 카트리지가 없어도 잘 쓸 수 있었음. 고지사항이 틀렸다고 생각함
 - 이건 진짜 법적인 주의문일 뿐 실제 적용 요건은 아님
 
 - 아직도 Duke Nukem Forever를 목 빠지게 기다리는 중임. 대체 얼마나 오래 됐는지 기억조차 희미함
- 농담인지 모르겠지만, 혹시 모르셨다면 이미 스팀에 Duke Nukem Forever가 출시되어 있음 https://store.steampowered.com/agecheck/app/57900/