Pointing an agent at a program and asking "how does this work?" is now a one-line request. That speed is the reason to slow down on one question first: are you allowed to? The projects built with REA, Reverse Engineer Anything, cluster into careful ones and risky ones, and the difference is rarely the technique. It is what they chose to study and what they chose to publish.
This guide gives you a checklist you can run before and after an investigation. It is general information from public sources, not legal advice, and the law varies by country. If you are working on a commercial product, get a lawyer's opinion.
TL;DR: the checklist
| Question | Safer answer | Risky answer |
|---|---|---|
| Whose software is it? | Mine, or openly licensed | A commercial product I have no rights to study |
| What does the license or EULA say? | Allows study or interoperability | Forbids reverse engineering |
| What is my purpose? | Learning, research, interoperability, preservation | Cloning a product to compete |
| What will I publish? | A written spec and my own new code | Decompiled code or original assets |
| Do I copy the look and brand? | No, original design and name | Near-identical UI, name or logo |
| Did one person see the code and write the rebuild? | Separate spec writer and implementer | Same person, same session |
| Can I show my work? | Tests, notes, provenance | Nothing, just a claim |
What REA itself says
REA's README includes a disclaimer, and projects that quote it have the right instinct. The tool is described as providing tools for lawful research, and the responsibility for obtaining any required authorization, and for complying with applicable law, sits with you. REA does not decide for you. Its analysis runs locally, and your agent receives the tool results under your model provider's data policy, which is a privacy matter separate from the legal one.
The hexgrab project, a small color picker built from a REA study of Microsoft PowerToys, puts the warning plainly in its README: do not point reverse-engineering tools at commercial software you do not have the rights to study, because most commercial licenses forbid it and copying code from a decompiled binary is copyright infringement. It picks an MIT-licensed target on purpose. That is the model to follow.
Step 1: choose the target with care
Rank your targets from safest to riskiest.
- Your own software. You have the rights. This is the best place to learn the workflow, and our proof guide suggests compiling your own program and checking the agent against your source.
- Openly licensed software. Permissive licenses such as MIT allow study, and public source lets you verify findings.
- Software you own a copy of, for interoperability or preservation. Many old-game projects live here, but rules differ by country and by license.
- Commercial software you only have a license to run. Read the EULA first. Many forbid reverse engineering. Some jurisdictions carve out exceptions for interoperability, so the answer is not the same everywhere.
- Anything involving circumventing access controls, DRM or security measures. This can raise separate legal issues. Stop and get advice.
Before you start, read three things: the license in the repository, the EULA in the installer, and the terms of service for any online component.
Step 2: understand what "clean room" means
A clean-room implementation separates learning what the software does from writing the new code. Classically, one team studies the original and writes a behavior specification, and a different team that never saw the original code writes the implementation from that spec. The separation is what lets the second team argue it did not copy.
AI changes the picture in a subtle way. If the same agent session reads decompiled code and then writes the replacement, the separation is gone. Practical ways to keep it:
- Have the agent write a specification file first: behavior, inputs, outputs, constants and unknowns.
- Start a fresh session that sees only the spec when it writes the new code.
- Instruct it not to reproduce decompiled structure, names or comments.
- Keep the spec, the test results and the session notes as your provenance record.
The Ski or Die Snowball War reconstruction follows a spec-first shape: its README says the workflow analyzes the shipped binary, recovers gameplay rules with evidence, records them, and rebuilds from that specification. Other projects are looser. Read each one's notes before you assume it is clean-room.
A path to a flag marking a clean-room milestone for software rebuilt from a written specification
Step 3: separate code, assets and brand
A rebuild touches three different kinds of material, and each has its own rules.
| Material | Typical rule of thumb | What good projects do |
|---|---|---|
| Code | Do not copy decompiled code into your repo | Write new code from a spec |
| Assets: art, audio, text, fonts | Separately copyrighted even if you rebuild the engine | Require users to supply their own copy |
| Name, logo, UI look | Trademark and design rights apply | Use an original name and say you are not affiliated |
Examples from the projects we reviewed in our top 10 list: Open Scrantic and the Ski or Die reconstruction both require your own copy of the original files. paper-rs states that no original code or assets are included and that it is not affiliated with the product it studied. The community collection ai-rebuilds sets ground rules that forbid committing original game files.
Step 4: pick your license and credit your sources
If you study an MIT or Apache project, you can still learn from it, but check what the license asks of you if any code ends up in your repo. If you study a GPL project, such as OBS Studio, which is GPL-2.0, be especially careful that a permissively licensed rewrite does not copy protected expression. rec-rs, a Rust recorder studied from OBS's architecture, is licensed Apache-2.0, which is exactly the kind of combination where you should read the provenance notes.
Write down what you used. A short docs/provenance.md that lists the target, version, tools, date and what you did and did not copy is cheap insurance, and it helps readers trust the project.
Step 5: watch the red flags when you publish
Stop and rethink if any of these are true:
- You are about to commit decompiled output, even "cleaned up."
- The project's name, icon or screenshots come from the original.
- The README implies endorsement by the original maker.
- You are redistributing a patched binary or the original game files.
- The tool bypasses a license check, copy protection or an online service.
- You cannot explain which parts are your own work.
Open Claude UI is a useful case study in judgment. The repository says it reconstructs UI components and animation constants from a modern desktop AI client using REA, and it includes an asset-compliance note. A close visual reconstruction of a commercial product can still raise trademark and licensing questions, so the note is a good start, not a finish line.
Step 6: be honest about what you verified
Part of staying safe is not overclaiming. A project that says "we recovered one function and tested it" is on firmer ground than one that says "we cloned the app." The best projects document what is unfinished. DX-Ball says its exact reconstruction is still in progress, and Open Scrantic lists deliberate behavior differences. That honesty helps with the legal question too, because it shows you are doing research and learning, not shipping a counterfeit.
How companies and platforms are reacting
The ground is shifting. Some studios are exploring the technique themselves, as in Xbox Labs' game decompiling and recompiling work, while communities push back on AI-assisted decompilation in other places, as in the decomp.dev shutdown story. For a closer look at where copying ends and building begins, see our PhotoCraft clean-room coverage, and for browser ports of decompiled games, AI-decompiled games in the browser.
A pre-flight checklist you can paste into your agent
Before analyzing this target, check and tell me:
1. Who owns it and what license or EULA applies.
2. Whether that license allows study, interoperability or reverse engineering.
3. What I plan to publish and what must stay out of the repo.
Then write a behavior specification only, with no decompiled code or names.
I will review it before any implementation starts.
If you want to practice agent workflows with guardrails built in, our workshops walk through setup, review and safe handoffs.
Frequently asked questions
Is it legal to reverse engineer software with an AI agent? It depends on your jurisdiction, the license and your purpose. This is not legal advice.
What is the safest thing to study? Your own software and openly licensed software, as hexgrab did with MIT-licensed PowerToys.
What is a clean-room implementation? A rebuild written from a behavior specification, not from the original code, ideally by a separate party or session.
Can I publish original assets? Usually not. Ask users to supply their own copy.
Does a copied look and feel matter without copied code? Yes. Trademarks and design rights are separate from code copyright.
Related reading
- Top 10 projects built with the REA skill
- How to install and use the REA skill with Claude Code
- Prove an AI reverse engineering result with tests
- PhotoCraft and the clean-room question
- Xbox Labs, AI game decompiling and recompiling
- REA MCP server: what changes in your setup
- Official: REA disclaimer and README
This article is general information, not legal advice. Project details were checked on GitHub on October 19, 2026 and may have changed.