# AI Clean-Room Rebuilds: The SPEC.md → Oracle Loop, and Where the Law Draws the Line

> AI agents can now study a binary, write a behavioural SPEC.md, rebuild the software from the spec, and check it against the original as an oracle until it matches. How the clean-room loop works, why the "clean-room wall" matters, what US and EU law actually allow (Sega v. Accolade, Sony v. Connectix, Bowers v. Baystate, DMCA 1201(f), EU Directive 2009/24/EC), and what it means for defenders.

Source: https://playciso.com/blog/ai-clean-room-reimplementation-spec-oracle-loop · Published: 2026-10-27 · Publisher: PlayCISO (https://playciso.com)

---

The viral "AI reverse-engineering studio" post ends its tool list with one line that matters more than the other nineteen: _"clean-room loop: SPEC.md, oracles and checks until it matches,"_ and a pipeline — **binary → REA → SPEC.md → rebuild → oracle → retry**. That is a recipe for reimplementing software from its behaviour. It is not new as an idea. What is new is that an AI agent can now run all of it. (For the tools themselves, see our [guide to the 20-tool studio](/blog/ai-reverse-engineering-studio-open-source-tools).) One clarification first: REA's own documentation says it explains how software works and does **not** recover original source code or clone apps. The rebuild loop is a separate method people layer on top, not something we could confirm REA ships. ## How the loop works - Observe. Analyze the original: decompile it, run it, capture its inputs and outputs, file formats and network traffic. - Specify. Write a behaviour-only specification — what the program does, its interfaces, edge cases and error handling — without copying how it is written. A single SPEC.md at the repository root is the common convention. - Rebuild. A separate implementer writes new code from the specification alone. - Check against the oracle. Run the original and the rebuild on the same inputs. The original is the oracle: any output difference is a defect in the rebuild. - Retry. Feed the differences back, fix, and repeat until they match. Steps 4 and 5 are differential testing — the same technique security tools use to prove a patch did not change intended behaviour. ## The clean-room wall The loop only earns the name "clean room" if the people who read the original never write the new code. In the 1980s Phoenix Technologies built a compatible PC BIOS this way: one team studied IBM's BIOS and wrote specifications; a second team, which had never seen IBM's code, implemented from those specifications. The separation was the legal evidence of independent creation. With AI the equivalent is **context separation**: one agent reads the binary and writes the spec, a different agent with a fresh context implements from the spec only, and a log shows that nothing but the spec crossed over. Open-source tooling already implements this pattern — for example, the clean-room-skill project splits a "contaminated" analysis workspace from a clean implementation workspace with a one-way boundary. A single agent that read decompiled code and then wrote the rebuild has no wall, and its output is much closer to a copy. ## Where the law draws the line AI does not change the law; it changes how often people will test it. The key reference points (not legal advice): - Disassembly for interoperability can be fair use (US). Sega v. Accolade (9th Cir. 1992) held that disassembling code to learn how to make compatible games was fair use; Sony Computer Entertainment v. Connectix (9th Cir. 2000) extended that to intermediate copying while building a compatible emulator. - Reimplementing an interface can be fair use. Google v. Oracle (US Supreme Court, 2021) found Google's reimplementation of Java API declarations to be fair use. - DMCA section 1201(f) permits circumventing protection measures to achieve interoperability of an independently created program, within limits. - EU Software Directive 2009/24/EC, Article 6 permits decompilation when it is indispensable for interoperability, limited to the necessary parts, and the information may not be used to build a substantially similar program. - Contracts can override it. Bowers v. Baystate (Fed. Cir. 2003) enforced a licence term prohibiting reverse engineering. Clicking "I agree" may have waived the rights above. - A clean room does not touch patents. Independent creation is a copyright defence; a patent is infringed regardless. - Trade secrets and terms of service are separate risks, especially for SaaS clients and online services. Notice the recurring word: _interoperability_. The strongest legal footing is building something that works _with_ another system. Rebuilding a competitor's product to sell as a substitute sits on much weaker ground. ## What it means for defenders and vendors - Client-side logic is now cheap to replicate. If behaviour is observable on the client, assume someone can specify and rebuild it. Keep pricing, fraud rules, model weights and keys server-side. - Server-side authorization is the real control. A rebuilt client that understands your protocol perfectly should still get nothing it is not entitled to. - Know which protection covers what. Copyright covers your code, not your behaviour. Patents, contracts and trademarks cover different things. - Use the loop for good. The same method preserves abandoned software, builds compatible tools for proprietary formats, and documents legacy systems nobody understands anymore. - Red-team yourself. Run the loop against your own app and measure how much of it an outsider could reconstruct. _Not legal advice. Case summaries are simplified; outcomes depend on facts and jurisdiction. Consult counsel before reverse engineering or reimplementing software you do not own._