Resident Evil 4 GameCube debug build fully decompiled to byte-identical C/C++

A complete reconstruction, verified byte for byte

A reverse-engineering project has published a full C and C++ reconstruction of Resident Evil 4 for the Nintendo GameCube — specifically the G4BE08 debug build, a "Nov 25 2004" prototype spread across two discs. According to the project's GitHub repository, which reached the Hacker News front page on 20 September 2026, recompiling the source reproduces the game's main executable (main.dol) and all 114 REL overlay modules exactly. SHA-1 checksums are checked automatically on every build to confirm the match.

The scale is large: 1,083 object files (675 in the main executable, 408 across the RELs) covering 15,641 functions, written as roughly 555,000 lines of C/C++ plus 33,000 lines of headers. The repository states that the tree contains no assembly source files.

Three original toolchains

Matching bytes exactly generally requires the exact compilers the original developers used, and the project reconstructed three of them. The game code was built with SN Systems ProDG 3.9.3 — effectively GCC 2.95.3 — which the team compiled natively from SN Systems' GPL source release. The CRI middleware libraries (audio and video) use Metrowerks CodeWarrior 2.4.7, reportedly the same compiler CRI shipped its libraries with. The Nintendo SDK portions use CodeWarrior GC/1.2.5n with SDK sources from dolsdk2004.

Candid accounting of the imperfect matches

The documentation is unusually frank about places where natural source could not reproduce the original machine code. Some 644 sites carry COMPILER-DIFF comments marking constructs such as dead tests, empty asm() statements, register pins and padding. Crucially, the project includes a tool that compiles every unit and verifies none of these markers emit an actual instruction. An earlier revision of the tree contained roughly 100 hand-placed instructions and about 100 register-pinning asm blocks; these were rewritten as plain C in September 2026, and the repository documents the technique used at each site.

Assembly survives only where the original authors themselves wrote assembly because their compilers could not express the code otherwise: paired-single maths and matrix kernels in the game code, cache and DSP-related kernels in the CRI libraries, and SDK intrinsics. Eight whole units (crt0, eabi, four SN Systems library files and two Capcom units) exist as C files whose functions are single top-level asm() bodies, since the originals showed no compiler fingerprint at all.

Original names recovered from debug artifacts

Because this is a debug build, its Bio4.sym files contain Capcom's own function names — names that are C++-mangled, which is why the game code itself is C++. File names and unit boundaries were recovered from assert strings left in the binaries, which reference the developers' original source paths. Struct and field names come from three places: the vendor's own type information extracted from a PS2 debug build and matched to the GameCube layouts with a purpose-built tool, names the project derived from usage, and placeholders for fields whose purpose is still unknown.

Legal posture and tooling

The repository contains no game assets and nothing copied from the discs. Builders must supply their own images of both debug discs, and the original files are read from them at configure time. The reconstructed source remains the intellectual property of Capcom, Nintendo and CRI Middleware and is published for research and preservation only; the project's own build scripts, tools and documentation are released under CC0.

The build runs on Linux with Python 3 and Ninja, and downloads the compilers and comparison tooling on the first configure run — except the native SN GCC, which requires the GPL source drop. Beyond the decompilation itself, the project ships an animation exporter to glTF and BVH that evaluates motion data with the game's own code and was verified against the game running in Dolphin, plus an overview document explaining how the engine is organised.

Why it matters

Byte-identical decompilation is the highest bar in game reverse engineering. It is neither a port nor a reimplementation: it is readable source that provably compiles back to the shipped binaries. Achieving it for a commercial title as complex as Resident Evil 4 — thousands of functions, multiple compilers, middleware from three vendors — turns a closed artifact into something that can be studied, audited, taught from and extended, all without distributing a byte of the game. The project's detailed research log, documenting how each compiler mechanism was reproduced, also makes it a practical reference for future decompilation efforts. Following earlier landmark projects in this space, it strengthens the case that source-accurate preservation of commercial games is achievable at scale.