Nanolathe: Clean-Room Reverse Engineering, Explained

⏱️ Reading time: 12 min

A team of developers released an engine that revives Total Annihilation, the classic 1997 RTS, without having seen a single line of the original code. Nanolathe, released under the MIT license, rebuilds the complete game through clean-room reverse engineering: they documented the binary’s behavior, annotated every file format, and wrote a new engine from that documentation.

📑 En este artículo

1. TL;DR
2. What Is Clean-Room Reverse Engineering?
3. Why It Matters
4. How It Works in Detail
5. Practical Examples
   1. The BIOS That Started the Practice
   2. ReactOS and the Windows Kernel
   3. Nanolathe and Total Annihilation
6. Getting Started
7. Real-World Use Cases
8. Common Mistakes and Best Practices
9. Comparison with Other Ways to Revive Old Software
10. Going Deeper
11. Frequently Asked Questions
    1. What is clean-room reverse engineering, and why did Nanolathe use it?
    2. Do I need to own Total Annihilation to play with Nanolathe’s engine?
    3. Does Nanolathe’s engine run on Linux and Mac, or only on Windows?
    4. Is clean-room design legal in every country?
    5. Can you play Nanolathe in multiplayer with friends?
    6. What does Nanolathe’s reconstruction of proprietary formats mean?
12. References

The technique isn’t as new as it seems: Phoenix Technologies used it to clone the IBM BIOS in 1984, and it still keeps ReactOS alive today. What changes with Nanolathe is the scale, applied to a complete game engine with its own renderer and networking, not just a chip.

TL;DR

• Clean-room design separates whoever documents the binary from whoever writes the new code, with no exceptions.
• Nanolathe’s MIT license covers the engine, not the game files, which remain the property of the original studio.
• The modern renderer’s textures are synthesized at 64×64 from the original 32×32-pixel tiles.
• Playing the browser demo doesn’t require installing anything: desktop Chrome, Edge, or Safari is enough.
• Reimplementing a proprietary format requires documenting observed behavior, never copying the code that produces it.

What Is Clean-Room Reverse Engineering?

Clean-room reverse engineering is a software development method in which one team documents the behavior of someone else’s program without touching its code, and a second team, isolated from the first, writes a new implementation based on that documentation.

The separation between the two teams is what legally sustains the method. If someone who saw the original code takes part in writing the new software, the result can no longer be defended as independent development. That’s why practitioners of clean-room design document every decision, every test, and every source consulted in writing, so it can be proven that the team that wrote the final code never had access to the original.

That documentation isn’t an informal summary: it’s a complete technical specification, thorough enough for a third party to build an equivalent program without ever having seen the binary that originated it.

Why It Matters

For a developer, this method solves a problem that neither open source nor piracy solves: how to keep alive a piece of software whose owner no longer supports it, without infringing on the rights to the code that makes it run. Nanolathe doesn’t redistribute Total Annihilation’s files: it asks the player to provide their own, purchased on GOG, Steam, or from the original CDs, and only contributes the engine that interprets them.

That same logic sustained Phoenix Technologies’ defense in 1984 against the accusation of having copied the IBM BIOS. Phoenix never had access to IBM’s source code: it documented the observed behavior of the original BIOS and wrote its own implementation from that documentation. That precedent turned the reconstruction of proprietary formats into a recognized legal defense, the same one that underpins ReactOS today.

It also matters for digital preservation. Many games and programs from the nineties don’t run on modern hardware, and their owners aren’t going to relaunch them. Cloning their behavior with verifiable documentation is, for now, the only legal path for those works to remain playable twenty years from now.

How It Works in Detail

The clean-room design process is organized into phases that are rarely skipped, because skipping them invalidates the entire legal defense.

• External observation: the analysis team runs the original program and records what it does, never how it does it internally.
• Formal documentation: every byte of a file format or every response from an interface is recorded in a specification independent of the code.
• Separation wall: no one who worked on the previous phase takes part in the next one, and on large projects they can’t even communicate during development.
• New implementation: a second team, which only saw the specification, writes the software from scratch, with its own internal design decisions.
• Cross-verification: the behavior of the new software is compared against the original, never by comparing the source code of both.

flowchart TD
A["Analysis team"] --> B["Documentation and specification"]
B --> C["Legal separation wall"]
C --> D["Clean implementation team"]
D --> E["New, independent software"]

In Nanolathe’s case, that work falls on Total Annihilation’s own formats: the HPI files that package the game’s resources, the 3DO models that define each unit’s geometry, and the COB scripts that control its behavior in combat. The project’s own site sums up that stage as reading the game’s formats, studying the engine’s design, and following the evidence behind its behavior, a description that fits exactly with the clean-room method applied to a 1997 game.

Proof that the new engine behaves the same as the original isn’t based on comparing code, but on comparing results. The site of Nanolathe published a comparison between its classic and modern renderers, generated with build 617540c5 from October 4, 2026, where the tile cache goes from the original 32×32 pixels to synthesized 64×64 tiles. That comparison, captured at 960×640 with no cropping or retouching, is the kind of evidence that supports a proprietary format reconstruction: there’s no need to show a single line of code to prove the behavior is equivalent.

Practical Examples

The BIOS That Started the Practice

In 1984, Phoenix Technologies needed a BIOS compatible with the IBM PC without copying IBM’s code. It hired engineers who had never seen that code, gave them a functional specification written by another team, and let them rebuild the behavior from scratch. The result allowed dozens of manufacturers to build compatible PCs without paying a license to IBM, and it set the legal standard that every later reconstruction has tried to follow.

ReactOS and the Windows Kernel

ReactOS publicly documents its clean-room development policy: any contributor who has had access to Windows source code is barred from writing code for the project. They can, however, take part in documenting observed behavior, which another contributor without that history then uses to program the equivalent piece.

Nanolathe and Total Annihilation

Nanolathe applies the same separation to a complete game: not just the graphics engine, but also combat physics, the units’ scripting system, and the networking code that syncs a multiplayer match. The resulting code is MIT-licensed, but it doesn’t include a single asset from the original game: no models, no sounds, no textures, and not the 1997 executable.

Getting Started

If you just want to see the result of this work, you don’t need to install anything or own the original game.

1. Open nanolathe.gg from a desktop browser: Chrome, Edge, and Safari work, though Firefox, mobile, and tablet haven’t been verified by the project yet.
2. Choose the option to play the demo and load the three missions from the original demo campaign. The files download on the fly and get cached for your next visit.
3. If you already own a copy of Total Annihilation (on GOG, Steam, or your original CDs), install the native beta for Windows, Mac, or Linux and point it to those files: that unlocks skirmish, survival, and the full campaign, with every match recorded as a replay.
4. To play online, choose the multiplayer option from the main menu, generate a match code, and share it with another person: the host decides whether the match runs with modern rules or the classic rules from earlier versions.

The engine is under the MIT license, so the code can be read, modified, and redistributed without asking permission. The only thing that license doesn’t cover is the original game’s files, which remain the property of their owner.

Real-World Use Cases

Video game preservation teams turn to this method when the original owner of a title has no commercial interest in relaunching it, but also won’t give up the rights: they document the behavior, publish the specification, and let the community build the engine, just as happened with Nanolathe and Total Annihilation.

Enterprise software legal teams use clean-room design when they need to interoperate with a proprietary file format without signing a license agreement. It’s the same principle, albeit at a different scale, that allowed Unix servers to speak Windows’ file protocol without copying Microsoft’s code.

And because Nanolathe’s code is MIT-licensed, any small studio or modder can use it as the base for a new game with its own mechanics, without asking permission or paying royalties, as long as they don’t redistribute Total Annihilation’s original files along with the engine.

Common Mistakes and Best Practices

• Team contamination: if even one person on the implementation team ever read the original code, the entire legal defense collapses, even if that person never wrote a single line.
• Incomplete documentation: a specification with gaps forces the second team to guess, and guessing wrong produces bugs that don’t exist in the original.
• Mixing assets with code: redistributing the original software’s files alongside the new engine voids the legal separation between the two, even if the code itself is original.
• Underestimating the time: documenting a complete binary format almost always takes longer than writing the code that later interprets it.

⚠️ Watch out: redistributing Total Annihilation’s original files along with the engine, even by mistake, turns an MIT project into a copyright violation. The separation between engine and data isn’t a minor legal detail.

Comparison with Other Ways to Revive Old Software

Not every way of resurrecting an old program carries the same legal risk or the same level of fidelity to the original.

Going Deeper

What distinguishes a serious clean-room project from an improvised one is traceability. Every claim in the specification has to be traceable back to a concrete observation: a network capture, a memory dump read only in read-only mode, a byte table annotated byte by byte. Without that traceability, no one can later prove that the implementation team never saw the original.

flowchart LR
A["Original Total Annihilation files (HPI, 3DO, COB)"] --> B["Nanolathe engine (MIT, new code)"]
B --> C["Classic or modern renderer"]
C --> D["Playable match on Windows, Mac, Linux, or browser"]

That scheme explains why Nanolathe can offer two renderers (one faithful to the 1997 original and another with modern lighting and glow) without touching the game’s data: both read the same format specification, only how the final result is drawn on screen changes.

💭 Key point: the legal defense of clean-room design doesn’t depend on the intent of whoever writes the code: it depends on being able to prove, with documents, that they never had access to the original.

Your next step: open the Nanolathe demo in your browser, check which original mission loads first, and compare it with a video of the classic 1997 campaign to spot where the modern rendering changes.

Frequently Asked Questions

What is clean-room reverse engineering, and why did Nanolathe use it?

It’s the method that separates whoever documents someone else’s program from whoever writes the new code, so the result doesn’t legally derive from the original. Nanolathe used it because Total Annihilation isn’t free software: without that separation, reconstructing its formats would have been an unauthorized copy, not independent development.

Do I need to own Total Annihilation to play with Nanolathe’s engine?

No, not for the browser demo: it includes the three missions from the original demo, so you can try it without a game folder. For the full experience you need your own files from a legitimate copy, purchased on GOG, Steam, or from the original CDs.

Does Nanolathe’s engine run on Linux and Mac, or only on Windows?

It runs natively on Windows, Mac, and Linux, in addition to the desktop browser demo with Chrome, Edge, or Safari. Firefox, mobile, and tablet haven’t been verified by the project yet.

Is clean-room design legal in every country?

Not automatically: it depends on each country’s legislation and on the process being well documented. The most cited precedent is Phoenix Technologies, which in 1984 successfully defended its cloned BIOS by showing it never had access to IBM’s code.

Can you play Nanolathe in multiplayer with friends?

Yes, both in the installed game and in desktop Chrome or Edge, and the two can play against each other. Skirmish mode supports 2 to 10 players, and survival 2 to 3; every match gets recorded as a replay.

What does Nanolathe’s reconstruction of proprietary formats mean?

It means writing, based on observing a binary file’s behavior, a complete specification of its structure without ever having read the code that generated it. That specification is what made it possible to write a new engine capable of reading Total Annihilation’s original HPI, 3DO, and COB files.

References

• Nanolathe: the project’s official site, with the playable demo, the build 617540c5 changelog, and FAQs about the native beta.
• Wikipedia: Clean room design: a general explanation of the legal method of documented reverse engineering.
• Wikipedia: BIOS: the history of Phoenix Technologies’ reimplementation of the IBM BIOS in 1984.
• ReactOS: an operating system project that publicly documents its clean-room development policy.

📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Juanjo Jaramillo en Unsplash