Is REA Legal? AI Reverse Engineering, SaaS, and UK Law Explained

What is REA, and why has it changed the conversation?

REA (Reverse Engineer Anything) is an open-source command-line tool and Model Context Protocol (MCP) server. It gives AI coding agents such as Claude Code, Codex, and Cursor structured access to established reverse engineering tools, including Ghidra, IDA Pro, and Hopper. MCP is the standard interface coding agents use to call external tools.

The project README lists a wide range of targets:

• Native binaries, including Go, Rust, and WebAssembly
• JavaScript and Electron applications, and websites
• .NET assemblies, Android packages, and Flutter apps
• Firmware, SQLite databases, and packet captures

The workflow its users describe is inspect, understand, recreate. The agent decompiles or traces the target, reasons about what each part does, then writes and tests its own implementation feature by feature. By October 2026 the repository had passed 300,000 GitHub stars.

None of the underlying techniques are new. Ghidra and IDA Pro have been standard tools for years. REA changes the cost: work that once needed a specialist for weeks can now be started by anyone with a coding agent. That is why the legal question has moved from security researchers to boardrooms.

REA’s own README is clear about its intended scope. It describes the tool as being for ‘lawful research, education, interoperability, software preservation’ and the ‘analysis of software you own or are authorized to examine’. It also says that bypassing licence restrictions is not authorised. Those limits track the legal position closely.

Is REA legal?

Downloading and running REA is not in itself unlawful. It is MIT-licensed open-source software that connects coding agents to analysis tools security researchers have used for years. Whether a particular use of REA is legal in the UK depends on two things: whose software you point it at, and what you do with the output.

In summary:

• Software you own, or hold a licence to modify: generally lawful, subject to third-party components and personal data.
• A vendor product you run under a use-only licence: lawful to observe and study, and to decompile only where interoperability or error correction requires it.
• A SaaS product: the highest-risk case, because copyright, the subscription terms, and the Computer Misuse Act all apply at once.
• Recreating a third party’s product from decompiled code: not defensible, whatever the target.

The sections below explain each case and the law behind it.

Is reverse engineering legal in the UK?

Some forms are, and some are not. UK law separates three activities that people tend to describe with the same phrase, and each one has a different answer.

Observing behaviour. Running a program and studying what it does, to work out the ideas and principles behind it, is protected by section 50BA of the Copyright, Designs and Patents Act 1988 (CDPA). This applies to a lawful user of a copy of the program, while they do things they are entitled to do with it, such as loading and running it.

Decompiling code. Converting a program’s machine code into a readable higher-level form reproduces and adapts the program, which are acts restricted by copyright. Section 50B permits it only where it is necessary to obtain the information needed to make an independently created program work with it. That is the ‘interoperability’ exception.

Recreating the product. Building a new program is lawful when the new program is your own expression of unprotected functionality. It is not lawful when the new program reproduces a substantial part of the original’s code, structure, or other protected expression, whatever route it took to get there.

The principle that functionality is not protected by copyright is well established. Our guide to replacing SaaS with a custom build covers the leading cases, Navitaire v easyJet and SAS Institute v World Programming. Both cases also show the limits: easyJet was found to have infringed by copying icons, and World Programming by reproducing parts of SAS’s manuals.

Why is decompiling and recreating riskier than observing?

Because the law protects code as a literary work, and decompilation puts that code in front of whoever builds the replacement. A clean-room process exists to prove that the people writing the new program never saw the original’s code. When an agent decompiles a program and then writes its replacement in the same session, the build side has seen everything.

The clean room depends on separation

In a traditional clean room, one team studies the original and writes a functional specification in its own words. A second team, which never sees the original, builds from that specification alone. The documentation of that separation is the defence if the original’s owner alleges copying.

REA’s loop is the opposite arrangement. The same agent, with the same context, reads the decompiled pseudocode and writes the new implementation. Even where the output looks different line by line, you would struggle to show that it was created independently of code the agent had just read.

Translation into another language is still an adaptation

A common assumption is that asking the agent to rewrite the logic in a different language produces new work. UK law says otherwise. Section 21(4) of the CDPA provides that a translation of a computer program includes a version converted into a different computer language or code. Making an adaptation, which includes a translation, is a restricted act.

The interoperability exception has strict conditions

Section 50B allows decompilation only where all of its conditions are met. The information must not already be readily available, and the decompiling must be limited to what interoperability requires. The information must not be passed to anyone who does not need it for that purpose.

Most importantly for REA, section 50B(3)(d) says the exception does not apply if the information is used to create a program substantially similar in its expression to the one decompiled. Interoperability means building something that works with the original. Rebuilding the original falls outside it.

Is SaaS reverse engineering with REA legal?

SaaS reverse engineering is the riskiest use of REA. You can use it on the parts of a SaaS product you lawfully receive, but the legal footing is weaker than for installed software. Recreating the product from what you find is not a defensible route.

What can REA reach in a SaaS product?

Most of a SaaS product’s logic runs on the vendor’s servers, which REA cannot reach. What it can reach is the client side:

• The JavaScript bundle your browser downloads
• Any desktop, Electron, or mobile client the vendor distributes
• The network traffic between those clients and the vendor’s servers

Each of these is the vendor’s code or the vendor’s service, and three bodies of law apply at once.

Copyright

The browser bundle and any distributed client are copies of the vendor’s program. Decompiling or deobfuscating them, and having an agent recreate the behaviour from the result, raises the same issues set out above. Section 50B is framed around converting a program from a lower-level language into a higher-level one. We have not found a UK decision on how it applies to minified JavaScript, so it is not safe to assume it helps.

There is a further open question for the server side. Sections 50B and 50BA protect a lawful user of a copy of a program. A SaaS customer accesses a service and may never hold a copy of the server software at all. We have not found UK authority on how those provisions apply to hosted software. If they do not apply, the subscription terms carry more weight.

Contract

SaaS agreements commonly prohibit reverse engineering, automated access, and use of the service to build a competing product. Section 296A of the CDPA voids a term only to the extent it restricts the acts in sections 50B and 50BA. Restrictions that go further, for example on scraping or on using non-public documentation, can be enforced as a matter of contract.

Our SaaS replacement legal guide covers how English law treats non-compete and non-replication clauses.

Computer misuse

The Computer Misuse Act 1990 makes it an offence to access programs or data on a computer without authorisation. Using your own account in the normal way is authorised. Pointing an agent at the vendor’s endpoints to probe what lies behind them, or using credentials outside their permitted purpose, can stray beyond that authorisation.

Agents work fast and at volume, which makes this easier to do by accident. Define the scope of any agent session before it starts, and keep it within what your account is entitled to do.

Where that leaves a SaaS replacement project

REA does not offer a shortcut that our clean-room guidance permits. The defensible route remains the one in our SaaS replacement legal guide. Describe the functionality you need in your own words, from your own use of the product and your business knowledge, and build from that specification.

We apply the same rule on SaaS replacement and legacy modernisation projects. Unless the client owns the copyright in the software, or holds a licence that covers this kind of work, its code does not go into our AI tools, whether as source, decompiled output, or screenshots. Where the client does hold those rights, analysing the system is a legitimate part of recovering how it works. We confirm the rights, and what the contract allows, before the work starts.

What about a licensed product we run on our own servers?

This section covers a use-only licence: the right to run a vendor’s product, without any right to its source code or to modify it. You have more room than with SaaS, because you hold a copy of the program, and the statutory exceptions apply to lawful users of a copy. The common case is a package from a vendor that has gone out of business, or one whose support has ended, which still runs a critical process.

Three exceptions are relevant:

• Observing, studying, and testing (s.50BA). You may study how the program behaves, while running it as your licence allows, to understand the ideas and principles behind it. A contract term restricting this is void under section 296A.
• Decompilation for interoperability (s.50B). You may decompile what is necessary to make an independent program work with it, such as understanding a data format to migrate your data out.
• Copying or adapting for lawful use (s.50C). This can include correcting errors. Unlike the other two, it does not apply where your agreement prohibits the act.

The Court of Justice of the European Union confirmed in Top System v Belgian State (2021) that a lawful purchaser may decompile a program to correct errors. That ruling came after the end of the Brexit transition period, so it does not bind UK courts, though they may have regard to it.

These exceptions support understanding the system, getting your data out, and keeping it running. They do not support producing a copy of the vendor’s product. If the goal is a replacement, the observation route is your strongest basis: document what the system does, then build from that description.

Can we use REA on software our organisation owns or licenses?

Generally yes, and this is where AI reverse engineering is most useful. If your organisation owns the copyright, there is no third party whose expression you are reproducing. The same is broadly true where you hold a licence that gives you the right to copy, modify, and adapt the code, which is how many bespoke systems are supplied.

Three checks come first.

Confirm what rights you hold. Under English law, copyright in commissioned software stays with the developer unless the contract assigns it. Many bespoke contracts grant a licence instead, as our guide to software IP licensing explains, and a well-drafted one can be enough. Read it for:

• The right to copy and modify. Decompiling reproduces and adapts the program, so a right to use it is not sufficient on its own.
• The right to have a third party do the work. If a supplier will carry out the analysis, the licence needs to allow contractors to work on the code on your behalf.
• Confidentiality and permitted use. Some licences limit who may see the code or what it may be used for, which can affect whether it may be sent to an AI service.
• Source code access. If the licence already gives you the source, work from that. Decompiling is only needed where the source has been lost or was never delivered.

Escrow access is not the same as a licence to modify. Our founder ownership checklist sets out what else to look for.

Identify third-party components. Your own binary may contain commercial libraries, controls, or runtime components licensed from someone else. Those keep their own licence terms, and your rights in the application do not extend to them.

Plan for personal data. Database files, packet captures, and application logs often contain live personal data. UK GDPR applies to the analysis in the same way it applies to recordings, which our guide to lawful reverse engineering from recordings and screenshots covers in detail.

Where the source code is lost entirely, the method matters as much as the law. Our legacy system reverse engineering service combines code analysis with recorded workshops and verification. Our guide to recovering business rules without source code sets out how to verify what decompilation and observation suggest, rather than trusting an agent’s reading.

What should never go near an AI reverse engineering tool?

Some activities are out of bounds whatever the ownership position, and REA’s own guidance excludes them:

• Circumventing licence checks, activation, or copy protection. This raises separate issues under the CDPA, and REA’s README states it is not authorised.
• Cracked or unlicensed analysis tools. Commercial tools such as IDA Pro need their own licence.
• Access you are not authorised to have. This includes other customers’ data, administrative endpoints, and systems you reach with borrowed credentials.
• Extracting a vendor’s content wholesale. Templates, question banks, and reference data can be protected by database right as well as copyright.

Does the law treat this differently outside the UK?

Yes, and the governing law of your agreement may not be English. In the United States, courts have treated some reverse engineering as fair use, but they have also enforced contractual bans on it, as in Bowers v Baystate Technologies. If your contract with a vendor is governed by US or another law, the UK exceptions described here may not decide the outcome.

A checklist before anyone runs REA

1. Name the target and your rights in it. Write down who owns the software and what your organisation may do with it, whether by ownership or licence, with the contract that proves it.
2. State the purpose. Interoperability, data migration, error correction, and understanding your own system are defensible. Recreating a third party’s product is not.
3. Read the agreement. Identify reverse engineering, automated access, confidentiality, and competing product clauses, and note which law governs it.
4. Set the agent’s scope. List the files and endpoints it may touch, and keep live services within what your account is entitled to do.
5. Separate understanding from building. Where the target is third-party, a human-written functional specification is the only input the build side should receive.
6. Screen for personal data before anything is extracted, and minimise it at source.
7. Keep a record of the tools, the inputs, and the purpose of each session.
8. Take advice before acting on the output where the target is not yours.

Where to go from here

AI has made reverse engineering cheap. It has not changed what the law permits, and the question of what rights you hold still comes first.

For the wider legal framework on replacing a product you do not own, read what you can and cannot legally copy when replacing SaaS. If you own software and are concerned about others doing this to you, our guide to protecting your software from AI reverse engineering covers it from the owner’s side.

If you have a legacy system you need to understand, or a SaaS product you want to replace without stepping over these lines, book a consultation and we will talk through the options.

This guide provides general information about UK copyright, contract, and computer misuse law as it applies to reverse engineering software. It is not legal advice, and it reflects the position as at October 2026. Several of the questions it raises, particularly around hosted software and AI-assisted rewriting, have not been decided by UK courts. Talk Think Do is a software development consultancy, not a law firm, and nothing in this guide creates a solicitor-client relationship. Consult a solicitor qualified in intellectual property law for advice specific to your circumstances.