Clean Room versus Reverse Engineering: How AI Was Used to Reproduce Proprietary Software

Previously I wrote about how AI was used to reproduce Microsoft, Adobe, and AutoCAD software offerings using an allegedly legally free method called a clean-room implementation. Here I want to expound a bit on what that means in contrast to simply reverse engineering a piece of software.

Reverse Engineering

Reverse engineering is the process of analyzing a compiled program (a binary .exe)—most often without access to its original source code or design documents—to figure out how it works, what its architecture is, and how its data flows. The practice allows for a deep understanding of how the software was produced, including any potential intellectually protected algorithms that may have been employed and various other software optimization techniques that were used. Ultimately one can work backwards in a methodical fashion to the point where it becomes possible to produce source code that when compiled, creates an executable that is close to being a clone of the other. With source code in hand, it becomes possible to port the software to other architectures and operating systems, add new features, and so on. We’ll get to why anyone would do this in a bit.

The practice is certainly not limited to software and has been around for as long as mankind has been making tools. One of the earliest known examples occurred during the First Punic War (264 BCE – 241 BCE). The Roman Republic did not have a standing navy at the start. A Carthaginian quinquereme (a type of warship) was captured and the Romans took it apart piece by piece, measured its components, and used it as a blueprint to build their own fleet of some 300 ships in only three months. Reverse engineering is a common practice in every industry.

It seems like the main reason to reverse engineer software would be to illegally steal a competitor’s product, and that certainly does happen. There are actually many reasons for doing it, on more solid legal footing.

The first would be for malware analysis. Most of us are used to receiving software and blindly installing it on our phones or computers and never giving much thought into how safe or secure it is. We trust the sources (Apple or Microsoft, for example) and we assume that what they’re giving us is legitimate. However, there are many computer admins with a critical need to ensure that the software being installed on their systems is free of malicious intent. Reverse engineering is one means to reveal any hidden threats.

Along with malware analysis one looks for other hidden vulnerabilities. These might not exist due to malicious intent and it includes finding bugs or other design and algorithmic flaws that leave a system vulnerable to other exploits.

Third-party software companies, such as those looking to make “plug-ins” or other add-ons to existing software, often reverse engineer binaries. Think of a company such as NIK that makes filters for Adobe Photoshop, for example. They may reverse engineer Photoshop to learn of the file structures it uses to open and close image files and so on, on order to achieve compatibility. This form of reverse engineering is considered “fair use” under present US case law. See Sega Enterprises Ltd. v. Accolade, Inc.(977 F.2d 1510), 1992.

Legacy modernization is another reason. It happens sometimes that a company has an old executable that will no longer run on a new system and for which the software code may no longer exist. It relies on reverse engineering to learn how the original code was created and can then modify it or update it for future needs.

Finally, and this is by no means an exhaustive list, one of the best reasons to reverse engineer software is simply to learn new programming skills and techniques.

The Clean-Room Doctrine and the Chinese Wall

Let’s assume for now that the goal is to reproduce, as accurately as possible, a competitor’s software product, and then make it available to others (free or otherwise). Reverse engineering as a means to exactly copy the implementation and functionality of the code is largely illegal in most jurisdictions. For starters it constitutes copyright and IP theft. It may involve many patent violations. If the software being copied was obtained legally, you likely agreed to a Terms of Service agreement before being able to install or run it. Many ToS agreements stipulate that the software may not be reverse-engineered. (The legality of these ToS agreements is a topic worthy of discussion.) Breaking the ToS agreement constitutes a contract violation. Finally, there are many nuances introduced into this arena by the Digital Millennium Copyright Act of 1998. Simply reverse engineering a software product to make a version and pass it off as your own would land you in a world of trouble.

To mitigate these infringement risks, the technology industry developed the “clean-room” or “Chinese wall” methodology. Clean-room engineering is not truly an alternative to reverse engineering, but rather a disciplined framework that separates the technical analysis of a software product from the authoring of a new implementation through an airtight organizational division.

Let me give you one of the most well-known examples. When IBM introduced its first personal computer it had a lock on the market. Despite the fact that the machines used existing hardware which anyone could purchase and assemble in order to make their own IBM clones (as they would be called), the one crucial piece of software that made it all work was the BIOS (Basic Input/Output System) stored on a chip that the computer first reads when it is powered on. The BIOS tells the computer everything it needs to know in order to access the rest of the hardware and to go about its business. In June 1982, a company named Columbia Data Products released its own BIOS which duplicated the functionality of the IBM BIOS but whose software engineers never even saw the IBM BIOS executable. Despite being challenged in the courts, it was found to be legal. How was this achieved?

A clean-room implementation divides the effort into two entirely segregated teams: the “dirty” team and the “clean” team. The dirty team works directly with the target software. These engineers disassemble the binaries, intercept hardware signals, analyze protocol traces, and map out input-output relationships. However, they are strictly prohibited from writing any production code for the replacement product.

Instead, the dirty team’s sole output is a functional specification. This is a comprehensive, neutral document describing what the software does. It is entirely stripped of any proprietary expression detailing how it was written which might include patented algorithms and so on. This specification defines inputs, valid state transitions, error conditions, return codes, and boundary behaviors using abstract descriptions, mathematical formulas, or formal interface definition languages.

The clean team then receives this functional specification and is tasked to write a software implementation of it. It consists exclusively of developers who have had no prior access to the target system’s binary, decompiled code, or proprietary technical documentation. No one on the clean team may have had any contact with those on the dirty team. If a clean-room engineer encounters an ambiguous requirement or unexpected edge case, they do not inspect the target software themselves; they submit a formal inquiry back across the barrier. The dirty team verifies the behavior on the target system and updates the specification accordingly.

The point is that the clean team simply produces software based on a document that was handed to them which describes—in non-proprietary language—what the software needs to do. Courts have by and large found this to be free of the legal flaws inherent in simple reverse-engineered processes.

AI Enters the Fray

Hopefully you now understand the process of reverse-engineering and what a clean-room implementation means. Now we can begin to discuss at a high level just what ArtCraft did in order to reproduce the software offerings from some of the world’s largest vendors.

Essentially, ArtCraft built a system consisting of a dirty team and a clean team entirely using AI agents. 

AI agents making up the dirty team were given access to tools used to examine existing binaries. For legal reasons, the ArtCraft team decided to strictly enforce a rule that no binary could be decompiled or otherwise disassembled. Instead, any and all publicly available documents about the software, such as API specifications, file layouts, etc, were fed into the system. An example would be a document freely available from Adobe that describes the file layout of its PSD image files.

The dirty AI agents were also given access to the software to be scrutinized. The way in which the software would be probed was to then have these agents act like humans using the software, trying out every known published feature and menu option simply to see what the effect was. They were given complete access to the system on which the software ran and could emulate all known keyboard strokes and mouse movements and clicks. They could see how the software could interact with the machine, how files could be opened, generated, and/or closed. Because they are non-human with no need to sleep, and could operate at electronic speeds, they were able to completely determine what a piece of software could do in a matter of hours. Results were handed off to other dirty team AI agents tasked with writing the specification that a traditional coder would then use to begin to write software.

The clean team consisted of AI agents using Anthropic’s Claude Opus 5.5 to read the specification document and write all new code entirely in the Rust programming language that would compile and behave exactly as specified. These AI agents never examined the original software.

There is also a feedback loop built into this system which compiles the Rust code and runs the new software through the same process used to run the proprietary software. This is done by the dirty AI agents who created a test harness, a collection of tasks the new software needs to pass in order to verify compatibility. One task, for example, might be to run some image filter on a file, using the new software as well as Adobe’s Photoshop, and verify that the resulting output files match byte for byte. If the test fails, the dirty agents learn why, and write new information into the specification to address it. Again, because of the speed with which this system can run, this all happens in short order.

The end result after several iterations through the feedback loop is software code that will compile and run, which looks and acts nearly identically to that of the proprietary software. This is what ArtCraft has now done for Adobe’s entire product line, Microsoft’s Office 365 suite, and AutoCAD’s famous CAD software. The quality isn’t perfect with most users and testers (myself included) deeming it alpha-release quality. However, there is enough there to allow the rest of a larger community of open-source developers to quickly clean it up, fix issues, and add necessary features. The largest single advantage from my personal point of view is that all these packages compile and run under Linux, giving me an entirely new way to use older hardware such as my 2016 Apple MacBook Pro. The MBP is no longer supported by Apple with software and security updates but I can run Linux on it readily enough. I also have a desktop Linux box built for less than $600 that rivals what a new Apple M6 Mini can do which costs over $2,000. The ability to run software (freely available even) on it which previously only existed for Apple or Windows OSes is a godsend.

Technical Limits and Legal Controversies

While the technical speed of the project is unprecedented—moving seven separate applications into alpha stages in a matter of weeks—the clean-room implementation strategy does face some significant skepticism. I have seen a few YouTube videos by legal and technical experts which hit upon some major areas to be addressed.

• The Chinese Wall: Because an LLM wrote the code, it is impossible to independently verify what proprietary data or source code the model was exposed to during its baseline training. This has been somewhat alleviated by ArtCraft releasing another code project, the complete set of AI tools used to do what they did, for anyone who would like to do similar work on other software. This also allows anyone to examine in detail their clean-room setup.
• Terms of Service Violation: Remember earlier when I wrote about having to agree to a software vendor’s Terms of Service agreement in order to install or use the software? Even if copyright infringement is avoided via the clean room setup, analyzing the commercial software to extract behavior typically violates standard ToS agreements and EULAs (End User License Agreements). This may be the route the industry takes to combat ArtCraft and others. To date, from my research, there is no clear legal decision that has enforced the language barring reverse-engineering inside of these agreements. They would, for example, bar fair-use methods which the courts have already determined are legal.
• Copyright and Trademark Infringement: Even if everything else remains free of any legal issues, these other infringements may exist. The icons used and the text used in internal prompts and help menus may all be included in the software’s Intellectual Property (IP). The ArtCraft developers have to scrutinize this and replace content wherever necessary.