AI News

AI Video Game Decompilation: What Works, What’s Possible, and What’s Legal

An AI-assisted Super Mario 64 DS reconstruction reports 99.9% of its functions matched. Its counter for source converted into readable form sits at 30.5%. Both numbers appear in the same project README.

That gap explains much of the excitement, and much of the confusion, around AI video game decompilation. Reproducing machine instructions, understanding the program, and shipping a dependable port are separate jobs. AI can contribute to all three, but a completion percentage usually describes only one.

Public projects now document models helping reconstruct engines, match compiled functions, and move established ports onto new platforms. The opportunity is substantial: source recovery, preservation, accessibility improvements, and authorized rereleases. The evidence also demands care. A repository announcement is different from an independently tested release, and technical success does not settle distribution rights.

This is a source-based examination of public projects and research, checked October 3, 2026. We have not independently built the games discussed or reproduced their progress counters. The legal discussion explains general principles in named jurisdictions; it does not determine the legality of any individual repository.

What gets called decompilation

Compilers turn source into machine instructions. Decompilers attempt to reconstruct a higher-level representation from those instructions. Names and comments may disappear during compilation; optimization can rearrange operations and collapse abstractions. Several possible source programs can produce the same executable behavior.

The phrase “AI decompiled a game” can therefore describe quite different work:

Method What the developer produces
Matching decompilation Source that compiles into the target machine code under a specified toolchain
Functional reconstruction Source intended to reproduce behavior, even when the compiled bytes differ
Static recompilation Translation of existing instructions into code compiled for another platform
Engine reimplementation A replacement runtime that reads the game’s existing content
Porting recovered source Adaptations that let an established reconstruction run on another system

These methods can overlap. Emulation supplies another route: reproduce the original system’s behavior so its executable can run.

N64Recomp demonstrates static recompilation. Given a binary, symbols, and metadata, it translates instructions into C for a host compiler. That literal translation need not recover the original classes or development structure. Graphics, audio, timing, and input still require supporting systems.

OpenMW provides a useful comparison. Its developers describe a Morrowind engine written from scratch without using the original executable. Players supply the game’s content. It illustrates independent engine development, rather than a recent AI breakthrough.

Why the compiler makes AI useful

The strongest matching workflows give a model a target that tools can check. An agent inspects assembly and callers, proposes C or C++, compiles it, examines differences, and tries again. A candidate that sounds convincing can still fail immediately.

Established tools supply much of the environment. Ghidra provides disassembly and decompilation. objdiff compares compiled objects. decomp-goal-harness organizes scoped agent work around project verification and recorded progress.

There are also models trained specifically for the task. LLM4Decompile includes assembly-to-source models and models that refine Ghidra output. Its documented settings involve Linux x86-64 and GCC optimization levels. Those results cannot be converted into a success rate for Nintendo games.

Our assessment is that the feedback loop matters as much as the model. It turns source generation into a series of testable proposals. Preparing that loop requires expertise: the right executable revision, compiler, build options, function boundaries, and comparison rules. An agent inherits those decisions rather than making their cost disappear.

The projects show several kinds of progress

The Super Mario 64 DS project distinguishes matching, readable conversion, and linkage into its PC port. It credits automatic templates for regular functions, AI assistance for harder work, and extensive community knowledge about names and structures. Its reported matching percentage includes a disclosed set of assembly primitives. Those details prevent one number from becoming a claim that a model recovered every original C++ file.

Yodecomp, a Yoda Stories project, describes Claude transcribing the engine into buildable C++. The maintainer supplied Ghidra access, reference projects, earlier asset-format knowledge, and technical guidance. Byte matching stalled, and work moved toward SDL porting.

The creator’s July 8 account describes an initial four-day effort. That is a useful reported milestone. It is not an independently measured end-to-end cost for a completely validated reconstruction. The documentation makes the human direction and prior foundations visible.

For Ocarina of Time, HarkinianPad adapts Ship of Harkinian to iPhone and iPad, including Metal rendering, touch controls, and ROM import. Reporting on Codex’s involvement describes work on already decompiled code. The achievement depends on earlier community reconstruction and source-port development.

Wind Waker supplies a particularly useful distinction. ZeldaRET’s tww describes a work-in-progress matching decompilation. Separately, BlueWake documents AI-assisted static recompilation with a compatibility runtime and fallback interpretation for rare instructions. Its distribution arrangements also distinguish personal builds from a Windows release containing translated code.

Those projects pursue different technical goals. A new platform demonstration does not establish completion of the matching project. Likewise, translated CPU instructions still need a runtime that makes the game’s assumptions work on new hardware.

Matching is strong evidence, with a defined scope

A complete, correctly linked executable that matches the target byte for byte provides strong evidence for that particular build. It deserves more weight than a screenshot or an assertion that the code looks right.

Partial scores need closer inspection. A comparison may normalize locations that a linker later fills with call or data addresses. Matching the remaining bytes does not establish that every destination is correct. The SM64DS documentation describes an additional destination check for precisely this issue.

Nor does a match uniquely recover historical source. Several expressions may compile identically. Comments, discarded assets, and development history require surviving evidence elsewhere. Source quality remains a separate concern: developers need meaningful structures and names to modify the program safely.

Portability adds another test. A hypothetical reconstruction could treat an address as a 32-bit integer and work under the original toolchain, then fail on a 64-bit host. Rendering and timing changes can introduce further problems.

A dependable release also needs progression, saves, reloading, menus, audio, controllers, and unusual states checked. Reaching the title screen proves that scene works. It cannot establish that the final boss, a rare transition, or a corrupted save behaves correctly.

What research can establish

Function benchmarks help identify failure modes. They do not automatically measure whole-game reliability.

The 2025 DecompileBench study evaluated traditional and LLM methods across real-world programs. In its tested setting, LLM approaches produced more understandable output while doing worse on functional correctness. The models and evaluation conditions matter; it is not a ranking of every frontier model available in October 2026.

More recent work explores feedback-driven repair. The June 2026 AutoDecompiler preprint studies multiple reconstruction attempts guided by compilation and execution feedback. That supports investigation of iterative workflows, while leaving whole-game claims to separate evidence.

Compilation is a basic milestone. Behavioral tests ask more, but they cover the cases supplied. If nobody tests an unusual input, the absence of a failure proves little about it. For a game, useful evidence combines binary comparison where appropriate, focused tests, and sustained gameplay checks.

What can realistically be recovered

AI can help explain difficult functions, suggest structures, generate matching candidates, and adapt existing code to platform APIs. Public projects already document portions of this work.

Older games can be manageable because their executable and dependencies may be smaller and their hardware well documented. Age is no guarantee. Custom compression, overlays, coprocessors, hand-written assembly, and obscure compilers can complicate reconstruction.

Large modern programs add optimized C++, concurrency, middleware, platform services, and extensive content pipelines. A promising result on a small function supplies limited evidence about that scale.

Missing online services impose an information limit. A client may reveal messages and visible responses without containing the server’s matchmaking, persistence, moderation, or economy. Rebuilding that service requires additional documentation, software, or observation. The model cannot recover absent source merely because it can read the client.

For rights holders, the practical opportunity is broader than exact recovery. A validated replacement may support a rerelease even when the historical comments and file layout remain lost. The acceptance criteria should follow the intended product and preservation goal.

How to assess the next impressive announcement

Consider a hypothetical game whose damage calculation uses an integer overflow behavior on its original platform. An agent could produce clean-looking source that passes ordinary combat tests, then fails when a rare combination reaches that overflow. This is an illustration of a verification problem, rather than a discovered defect in any project discussed here.

A comparison against the original executable can expose the discrepancy. A focused behavioral test can preserve the expected result during later changes. A modern port may need an explicit implementation of the old arithmetic rather than reliance on a compiler’s incidental behavior.

That example suggests a practical checklist for readers. Find the precise game revision and the meaning of its progress score. Check whether the result contains assembly, replacement routines, or interpreter fallbacks. Look for independent gameplay reports and a known-issues list. Read the dependency credits before attributing an entire project to a model.

Also ask what changed between releases. A port can begin with a placeholder renderer or incomplete audio and improve later. A criticism of the first release may remain valid historically while describing the current version poorly. Developers and critics should identify the build they tested.

Players can reasonably expect some reconstructions to make new resolutions, controls, translations, and accessibility changes easier. Each feature still needs implementation and verification. A higher frame rate may expose timing assumptions; changing a field of view may reveal geometry the original camera concealed. Recovering code creates opportunities without automatically supplying polished improvements.

The U.S. legal question changes with the activity

Acquiring a copy, analyzing it, bypassing an access control, publishing source, and distributing a rebuilt game raise different issues. “Is decompilation legal?” compresses those activities into one question.

U.S. copyright law separates protected expression from ideas, procedures, and methods of operation. It also grants reproduction, adaptation, and distribution rights. Functional information can be unprotected while program code contains protected expression. Sections 102 and 106 provide the starting point.

Two influential cases support certain compatibility work. In Sega v. Accolade, the Ninth Circuit recognized fair use for necessary disassembly to access unprotected functional elements for a legitimate purpose. Accolade used interface information to develop its own games.

In Sony v. Connectix, intermediate BIOS copying during development of a noninfringing emulator received fair-use protection. Those factual settings are important. Neither decision supplies blanket permission to distribute the commercial program that was examined.

Section 107 requires considering purpose, the work’s nature, the amount used, and market effects. Free distribution does not establish immunity. Research and preservation labels do not determine the result either.

Removing music and textures addresses those materials. It leaves the question of what the source or executable contains. Requiring users to provide their own disc may change the facts, but it does not automatically clear a package that distributes translated game code.

AI generation adds no general exception. Rewriting names or syntax does not establish independent authorship of the underlying expression. The Copyright Office’s AI copyrightability report concerns protection for human and generated contributions; it does not grant permission to republish protected inputs.

Access controls, contracts, and lawsuits

The DMCA creates additional questions. Section 1201 regulates certain access-control circumvention and trafficking in circumvention tools. Its interoperability provision has conditions involving lawful access, necessity, and an independently created program. A copyright fair-use argument does not automatically answer an access-control claim.

The 2024 exemption rule includes limited game provisions, such as personal local play after an authentication server closes and qualifying institutional preservation. Conditions concern acquisition, purpose, eligibility, and access arrangements. These exemptions do not authorize unrestricted public game downloads.

Contracts can matter too. Bowers v. Baystate upheld a contractual reverse-engineering prohibition, with disagreement over copyright preemption. Its holding should not become a universal claim that every EULA always defeats every defense.

A clean-room process can help document independent implementation by separating analysis from implementation using permitted specifications. Its value depends on the actual inputs and separation. Calling an AI transcript “clean room” does not establish those facts.

Enforcement examples also need accurate descriptions. A February 2023 filing says Take-Two and represented defendants in the re3/reVC dispute settled in principle. The Yuzu dispute produced a proposed consent judgment concerning Switch access controls. Settlements do not supply contested appellate rulings that decide every reconstruction or emulator’s legality.

Repository availability is similarly inconclusive. GitHub’s DMCA process can remove or restore material through notice procedures. Either outcome differs from a judicial ruling on the underlying rights.

Canada and the EU have their own rules

Canada’s Copyright Act section 30.61 permits certain reproduction to obtain interoperability information by someone with an authorized copy or licence. It limits use and disclosure. Section 41.12, amended in 2024, separately addresses circumvention for interoperability involving programs, devices, and components, with conditions and exclusions.

In the EU, Article 6 of Directive 2009/24/EC permits certain decompilation indispensable for interoperability. Requirements concern lawful use, unavailable information, and necessary portions. The information cannot be used to develop a program substantially similar in protected expression or for other infringement. Article 8 invalidates contracts contrary to specified exceptions.

Neither framework offers unrestricted permission to redistribute reconstructed games. Developers need analysis of their jurisdiction, purpose, inputs, and releases. A U.S. fair-use precedent alone cannot settle a Canadian or European project.

Owning a disc also differs from owning copyright. “Abandonware” does not become public domain because a publisher stopped selling it. U.S. copyright duration depends on statutory rules rather than shelf availability. An open-source label can license contributors’ rights; it cannot supply rights they do not hold.

Preservation needs usable results and people to maintain them

The preservation problem is well documented. The Video Game History Foundation’s 2023 study reported 87% out of print in a random sample of 1,500 U.S. games released before 2010. That is a dated availability finding, rather than a measurement of destroyed files or every game’s status today.

Maintainable source can make behavior inspectable and support accessibility, bug fixes, and future ports. Emulation remains valuable for preserving original execution environments. Different methods serve different goals.

AI’s contribution also depends on which games receive attention. Familiar franchises draw developers and public interest. Our expectation is that cheaper reconstruction could help obscure titles, but that broader preservation benefit remains to be demonstrated.

Maintainer objections deserve technical attention. N64Recomp prohibits AI-generated contributions, citing provenance, maintenance, and hardware-fidelity concerns. RPCS3’s policy permits AI research assistance while requiring contributors to understand their work and disclose relevant AI involvement. These are different approaches.

Generating more code can increase review work. A local fix might make one game appear correct while breaking shared behavior. Upstream maintainers bear that cost when submissions lack explanation or testing. Contribution policies and licence permissions are also separate: permitted downstream reuse does not guarantee acceptance upstream.

An October 2 GamesRadar report describes disagreement over an AI-assisted Banjo-Tooie recompilation, including criticism from developers of earlier ports. It is evidence of a dispute and the positions reported, rather than an independent technical audit. The project repository documents its reliance on N64Recomp and RT64.

The fair way to assess such a release is to identify specific defects, reproduce them on a named version, and obtain the developer’s explanation. Broad declarations that AI always ruins a project, or that a working demo vindicates every generated change, provide little help to users. Credit and compatibility checks can be evaluated through records rather than a developer’s enthusiasm for or opposition to AI.

Where a credible business could emerge

The most defensible commercial opportunities involve authorized recovery, licensed ports, preservation services, and verification tools. Publishers may value reconstruction of lost code even when it requires substantial human engineering. Middleware and soundtrack rights still need checking.

There is no reliable universal cost for decompiling a game. A fast milestone can inherit years of maps, documentation, templates, and rendering work. Model usage excludes preparation, failed attempts, review, and release testing.

Useful project reporting should disclose the starting state, model version, spending, human hours, verification method, remaining placeholders, and gameplay coverage. Readers should also know exactly what is distributed: tools, source, translated code, binaries, or assets.

A publisher commissioning recovery could begin with a narrow milestone: reconstruct one subsystem and compare it against known behavior. That reveals whether the toolchain and verifier are suitable before funding a full port. Later milestones could cover complete builds, content integration, platform compliance, and acceptance testing. This is a proposed evaluation approach, not a published industry price model.

For a small archive, the first investment may instead be documenting the available copies, revisions, and hardware. Without that foundation, model work can produce an uncertain reconstruction of an uncertain target. Preserving those records also helps future researchers understand why a particular implementation was accepted.

Public enthusiasts can contribute beyond generating source. Reproducible bug reports, save files that reach a broken transition, accurate documentation, and tests for hardware behavior can advance a project. Those contributions help convert a demonstration into software another person can trust and maintain.

Researchers could also run controlled experiments on permissively licensed programs with known source. Compile a program, remove selected information, and measure how an agent reconstructs it. Keep matching, behavioral accuracy, readability, and human effort as separate measures. Publishing the inputs and test cases would make the result easier to reproduce. Such an experiment would establish evidence about that program and setup; extending the conclusion to commercial games would require additional testing.

For a representative reconstruction, the strongest next evidence would pair a reproducible build and sustained gameplay checks with a rights analysis of its actual release package. That would show how much labor AI saved, which defects survived, and whether the resulting work can be maintained and distributed for its intended purpose.