The legal questions around reverse engineering a commercial game depend on what a project copies, how it obtains access, what it publishes, and the jurisdiction. US fair use and the specific interoperability provisions in 17 U.S.C. section 1201(f) address different questions; neither gives every game-port project automatic permission to distribute original material ^{1 2}.

Changing the format does not erase copyright

Disassembling machine code changes its representation, but that change alone does not determine whether publishing the result is permitted. A project’s own annotations can add original work without transferring ownership of the underlying game code. The rights and exceptions that apply depend on the material and use at issue ¹.

What about annotated disassemblies?

Many projects add comments, variable names, and function names to disassembly. Those annotations may be original contributions, while the accompanying instruction listing can still reproduce game material. The status of a particular release cannot be decided from the presence of annotations alone.

Keep annotations separate

One release design is to publish original notes and a symbol table separately from the disassembly. The table can associate researched names with addresses in a particular game revision, leaving users to analyze their own copy. This can reduce the amount of game-derived material distributed, although it does not itself settle every copyright question.

The catalogue of retail-game decompilations includes projects that publish different combinations of source, disassembly, symbol files, and native ports.

The Copyright Office’s summary of Sega v. Accolade describes a US decision in which disassembly to learn otherwise inaccessible functional elements for compatible, independently written games was fair use. That holding addresses the facts of that case; it is not a general ruling on publishing a game’s annotated disassembly ¹.

Reimplementations, Remasters and Remakes

Decompilations, static recompilations, and new implementations can publish different kinds and amounts of original game material. Assessing a release requires looking at its actual code, assets, build inputs, and output rather than its project label.

The N64 recomp guide explains the technical distinction between static recompilation, matching decompilation, and a source port.

---

Why emulation matters for preservation

Nerrel examines what a world without emulation would lose. The video supplies preservation context for this discussion rather than legal advice about a particular project.

Keep original assets out of public releases

Game art, music, and other extracted assets raise a separate distribution question from a project’s own code. Many community ports require users to provide a compatible game image and read assets locally rather than placing them in a public repository or release ³. Check source control history and packaged binaries as well as the visible file list: deleting a committed asset from the latest revision may leave it in earlier commits.

Choose what the project distributes

A project’s distribution model determines which game-derived material leaves the developer’s machine. These common approaches have different technical outputs:

Model	Published output	User-supplied input
Research metadata	Original notes, symbols, and build scripts	Game image for local analysis
Runtime ROM loading	Native program that reads game data at launch	Compatible game image
Delta patch	Difference file and patching instructions	Exact base image
User-side translation	Tools and runtime that translate code locally	Compatible game image

Zelda64Recomp says its repository and releases contain no game assets and require the original game. GoldenEye64Recomp documents an optional build that translates game functions from the user’s ROM at launch ^{3 4}. These are technical distribution choices, not legal guarantees. A delta patch can still contain copyrighted data, and requiring a user-supplied ROM does not establish that every method of obtaining or using one is lawful.

US law also has a conditional interoperability provision for circumvention in section 1201(f). It applies to identifying and analyzing elements necessary for interoperability under the statute’s stated conditions. It does not serve as blanket permission to distribute a game ROM or extracted assets ².

For emulation and preservation work, the RED-Project wiki is a useful external reference because it focuses on obtaining ROMs from officially released products rather than downloading loose files from the internet.

---

Legality of approaches for Reverse Engineering Code

Now what about the code for the re-implementation or any compiled executables built from that source code?

These project descriptions explain how an implementation was produced. They are not legal categories or a ranking of which project is lawful:

• Clean room - One group documents observable behavior; an independent group implements from that specification.
• Same-team reimplementation - Researchers inspect the original program and also write replacement code.
• Matching decompilation or static recompilation - A project reconstructs or translates original game instructions and supplies the resulting code or build steps.

Clean Room Reversing

In a strict clean-room process, the implementation team works from a functional specification instead of copied source or disassembly. This separation can help document independent development, but it is not a requirement announced by the Sega v. Accolade decision. That case found fair use for intermediate copying and disassembly under its particular interoperability facts ¹.

One team may inspect the original executable and document observable behavior. The implementation team then writes code from that documentation without access to the original implementation.

Calling a project “clean room” also requires evidence of that separation. Machine-translating the original instructions into C is static recompilation, not independent implementation merely because the output language differs.

An open project that accepts outside contributions needs a clear way to record which contributors saw the original implementation if it describes its process as clean room.

Same-team reimplementation

A small team may inspect the original program and write replacement behavior itself. Documenting observed interfaces and retaining evidence of independent design can make the process easier to understand, but no chosen language or team arrangement decides fair use by itself ¹.

Matching decompilation and static recompilation

A matching decompilation aims to reproduce the original binary from reconstructed source. A static recompilation translates the original instructions into host-compilable code. Both can involve game-derived material, so the contents of a published repository and release matter separately from the private analysis process.

The Super Mario 64 decompilation is a matching project: its build process reconstructs supported game images from C, assembly, and extracted assets supplied by the user ⁵.

---

History of Reverse engineering in the Games Industry

Reverse engineering is nothing new in the games industry and can go all the way back to the first Arcade games, with developers trying to figure out how their competitors managed to pull off the seemingly impossible in their new games.

SEGA vs EA

Former SEGA of America CEO Tom Kalinske was in charge when EA reverse-engineered the Sega Mega Drive. He was furious and famously said:

“Trip [Hawkins], didn’t your mother ever teach you the difference between right and wrong?”

This may have got the meeting off to a rough start but in the end SEGA got John Madden football and EA got favoured licensing rights.

So reverse engineering the Sega Mega Drive certainly brought benefits to both EA and SEGA at the time!

How Sega bet against Reverse Engineering…and lost

Modern Vintage Gamer covers reverse engineering on the Sega Genesis, including Electronic Arts and Accolade. For the legal holding in the Accolade case, use the court decision summarized by the Copyright Office rather than treating a video’s characterization of the method as the rule ¹.

Rare Reverse Engineered the NES to get an Official Nintendo License

The British company Rare made gaming history by becoming the first non-Japanese licensed game developer for the NES, securing the license from Nintendo through an ingenious demonstration of their skills by reverse engineering the console and showcasing the game “Slalom” as a convincing demo to Nintendo in 1986 ⁶.

---

References