Authorized use only

An independent reader's guide to REA's disclaimer. Not affiliated with the project. Not legal advice.

1. What this page is (and isn't)

This is an independent reading of REA's own rules for lawful use. It is not affiliated with the REA project or rea.tools, and it is not legal advice.

The authoritative text is the official DISCLAIMER.md in the REA repository. Every quotation on this page links back to it, and where this page goes beyond the original — the four-tier ladder in §5, the three misreadings in §2 — it says so plainly. Treat those as our analysis, not the project's position.

The original also sets its own ceiling: it "explains REA's intended use, user responsibilities, and community support boundaries," and it "does not amend the MIT license." Nothing on this page creates a permission the official document withholds, or narrows one it grants.

2. The rule that settles most cases: authorization, not access

Most reverse-engineering questions people actually ask aren't legal questions. They're authorization questions wearing a legal costume. The disclaimer has one sentence that resolves the majority of them:

"Public availability of software, possession of a file, or access to a debugging endpoint does not by itself establish permission for every operation."

Read it carefully, because the work is in the words by itself and every operation. The sentence doesn't say those things are irrelevant — it says none of them is a permission, and none of them is a complete one.

Three misreadings this kills. "I bought it, so I can do what I want with it." Buying a copy gets you a licence, and a licence is a set of permissions — not all of them. Inspecting a file and defeating the check that guards it are different acts, and only the first is generally covered by possession. "It's publicly downloadable, so it's fair game." Availability is a fact about the internet, not a grant from the rights holder. "It has a debug endpoint, so I may debug it." An endpoint is an interface that happens to be reachable; reachability is not consent.

Authorization has a shape, not just an answer. The disclaimer asks you to "establish the legal authority and scope required for the targets, accounts, devices, software, data, and operations involved" — and scope is the load-bearing word. "I'm allowed to analyze this" is not a permission until you can say which artifact, on whose machine, under whose account, doing which operation. Authorization to look is routinely narrower than authorization to run: this whole page's four-tier ladder exists because of that gap.

The responsibility lands on you, including on what you delegate. "You are responsible for your use of REA, including commands, configurations, scripts, and actions you direct an AI agent to perform." A plan an agent generated on your behalf is your act, not the model's. And the scope covers more than criminal law — "comply with applicable laws, contracts, intellectual-property rights, privacy obligations, and tool licenses" means the EULA you clicked and the API terms you accepted sit in the same sentence as the statute.

Why this isn't legal advice. The disclaimer sets its own ceiling: it "does not amend the MIT license," and reversing "may be restricted in your jurisdiction or by the license of the software you analyze." So the honest move is procedural, not declarative: write down the basis for your authorization — you wrote it, you own it, you're auditing your own deployment, it's a CTF image, it's a vendor-supplied sample — before you run anything. If you can't finish that sentence, that's your answer to whether to proceed.

The "three misreadings" framing is this site's analysis, not the project's wording. The official text simply states the rule; it does not enumerate the misreadings.

3. What REA is built for

REA exists for legitimate analysis, and the project's own list is unusually specific rather than generically worded: "security research, malware and incident analysis, vulnerability research and coordinated disclosure, CTFs and education," followed by "interoperability, software preservation, and debugging or auditing software you own or are authorized to examine."

Read the shape of that list, not just its contents. It names purposes, not targets — and the last clause carries the condition: you own or are authorized to examine. Every allowed purpose is already scoped by authorization before you get to §2.

The feature set matches the list rather than exceeding it. REA's README frames the tool as answering a mundane question — "See a feature you like. Understand how it works, down to the binary level" — and describes what it actually does as inspecting "the app without its source code, explain how the feature works, show the evidence." Nothing there implies reaching a system you don't control.

So the practical test is simple: can you state which of those purposes you're serving, and on what basis? If yes, the rest of this page is about staying inside the lines. If no, no tool will fix that.

4. Six things that will get help refused

Start with what's allowed, because the disclaimer does: REA is "built for lawful analysis: security research, malware and incident analysis, vulnerability research and coordinated disclosure, CTFs and education, interoperability, software preservation…" The six refusals below are exceptions to that list, not a ban on reversing.

The project "does not support, and will not help with":

1. Protection measures. "circumventing DRM, license checks, anti-cheat systems or other technical protection measures." Reading a file to understand how a check works and defeating that check are different acts — the second is refused even when you legally own the copy.

2. Cheats and live services. "developing game cheats or tampering with online services." A single-player save editor and manipulation of a live service are different problems; this line sits at the second.

3. Authentication on systems you don't own. "bypassing authentication, bot protection or access controls on systems you are not authorized to test."

4. Copying. "copying proprietary software or reproducing its protected code and assets." Understanding a mechanism is one thing; re-shipping the code, art or data behind it is another — and it overlaps the rule that analysis output grants no rights to the original.

5. AI provider policies. "evading the usage policies or safety measures of AI model providers."

6. Account resale. "reselling or sharing AI accounts or API access."

How it's enforced matters as much as the list. "Requests for help with the uses above will be closed without response in issues and discussions, and may result in removal from the REA community." It's silent enforcement — a refused request gets a closed thread, not an explanation.

A refusal isn't a legal verdict. This list is a support boundary, not a legal one. The disclaimer describes itself as explaining "intended use, user responsibilities, and community support boundaries," and states it "does not amend the MIT license." Staying inside these six does not make your analysis lawful, and stepping outside them does not make it illegal — the legal question is separate and jurisdiction-dependent, since reverse engineering "may be restricted in your jurisdiction or by the license of the software you analyze." Separately, the project asks you not to use REA for "unauthorized access or exploitation, credential theft, malicious deployment of malware," nor for "unlawful collection or disclosure of data, unauthorized service disruption."

How to ask so you get an answer. State the target, your relationship to it — "I wrote this," "I'm auditing our own product," "it's a CTF image," "it's a vendor-supplied sample" — and the specific behaviour you want to understand. A request carrying an authorization context gets an answer; one that reads like "how do I get past X" gets closed.

5. Inspect vs. execute vs. intercept vs. modify

"Authorization to inspect an artifact does not necessarily authorize execution, interception, device changes, or interaction with another party's system."

Read that as four separate doors, not one. Being allowed through the first does not open the other three.

Tier 1 — Read the bytes. Static JavaScript/Electron inspection and .NET analysis read the files you supply without running them, and Go binaries, WASM artifacts, EVM bytecode, offline ELF layout, Flutter APKs and package inventories work the same way. Nothing executes. What you still need is the right to analyze that artifact: owning the laptop is not owning the software, and a file sitting on your disk is not permission to take it apart. The disclaimer is blunt about this — "public availability of software, possession of a file, or access to a debugging endpoint does not by itself establish permission for every operation."

Tier 2 — Read a recording. HAR or SAZ captures, pcap summaries, recorded crashes, packet and signal recordings, SQLite snapshots. No target runs, but these artifacts are other people's data: captures and database rows routinely carry credentials and personal data, and collecting, retaining or sharing them has obligations of its own. A capture taken without authority does not become authorized because you read it offline.

Tier 3 — Run or drive it. Process capture and Android device work — packages, processes, logs, dumps, screenshots over adb — run or interact with the target using your own user permissions. Note the word "your". These actions "can affect application state, files, accounts, devices, and services", so your permission as the machine's operator is not the same as the owner's permission over what runs on it.

Tier 4 — Intercept. Browser and network observation, mitmproxy, traffic capture, attaching to runtime or browser endpoints. Now you sit between two parties. The disclaimer's answer to "but it all ran locally" is: "local operation does not establish authorization or guarantee that executed targets and third-party tools have no external effects." Intercepting another party's session or service needs authority of its own — plus a plan for the data you collect.

And modify? REA is not a patching tool, but running a target is modifying it: state, files, logs, and on a device, sometimes more. Turning what you learn into a changed artifact, or a re-implementation shipped in your own product, is a separate question from whether you were allowed to read the code — "obtaining source-like output or an analysis report does not grant rights to the original program, its data, or the generated output."

The four-tier ladder and the "four doors" metaphor are this site's reading of the official disclaimer, not a framework the project states. The quoted sentences are verbatim.

6. Output is not a licence

"Obtaining source-like output or an analysis report does not grant rights to the original program, its data, or the generated output."

Read that sentence twice, because most people stop at the first clause and assume they've got it. It names three things, and the third is the one that surprises people: the original program, its data, and the generated output itself. The decompiled code sitting in your working directory is not yours to publish, ship, or relicense merely because you produced it.

Four distinctions separate "I understand this" from "I may use this."

Understanding a mechanism is not owning it. Reconstructing how a routine behaves tells you how it behaves. It transfers no right from the rights holder to you — which is exactly why the project's own refusal list includes "copying proprietary software or reproducing its protected code and assets."

Three rights, three separate questions. The target's code and assets, the data inside it, and the output you generated each need their own basis. Wanting to use any of them turns on the target's licence and the producing tool's terms — not on the fact that REA produced it. The disclaimer's instruction is to "Check the target's rights and the producing tool's applicable terms before publishing, sharing, or using results in another product or service." That second clause is where §7 (JEB restricting disclosure of decompiled code) becomes relevant to your write-up, not just your install.

The output is also uncertain, and that cuts both ways. "Decompilation, reconstruction, heuristics, and AI-assisted analysis may be incomplete or incorrect." And then: "Results do not guarantee accuracy, completeness, security, compatibility, or legal compliance." Note the last one — no analysis result can certify your use as lawful. "The tool decompiled it and it looked fine" is not a legal position, and the project is explicit that nothing it ships creates one: "No project description, example, analysis result, or third-party integration guarantees a particular outcome or establishes that your intended use is lawful or safe."

So the discipline is evidence, not output. The instruction is to "Review the underlying evidence and verify consequential conclusions before relying on them." That is only possible if you kept the evidence: which artifact, which version, which digest, which operation produced which claim. An analyst's write-up that can't be traced back to an artifact isn't a finding — it's a story.

7. Tool licences you must supply yourself

REA connects to analysis engines. It does not include them. The disclaimer is explicit: "You must legally obtain IDA Pro and Hex-Rays decompilers, Hopper, JEB, and any other proprietary tools, together with the rights required for your use" — and "REA provides no commercial-tool license, key, or activation entitlement."

Four distinctions worth memorising before you install anything.

A bridge's licence is not the product's licence. REA reaches IDA Pro through a bridge that is itself MIT-licensed — but that licence "licenses the bridge code, not IDA or Hex-Rays products." The bridge's own prerequisites require IDA Pro and state plainly that IDA Free is unsupported. An open-source connector is not a discounted path to a paid product.

Rights are granted per dimension. Owning a copy settles less than people assume. What you need is rights "for the required product, user, machine, decompiler, and automation interfaces" — because "an open-source bridge or accessible API does not grant additional user, machine, feature, automation, hosting, or output-sharing rights." Pointing REA at Hex-Rays on a shared workstation, or inside a service, can require a tier you don't hold.

Trials are usable — within their terms. "Permitted trials and demos remain subject to vendor terms." A demo that's perfectly fine for hands-on exploration may still exclude automation, and driving it programmatically through an agent is exactly what personal tiers tend to forbid. Hopper's terms, for instance, split personal from computer licences with different permitted-user and installation rules; having the installer is not the same as holding a seat.

Output carries its own restrictions. JEB's EULA "restricts public or third-party disclosure of decompiled code, reconstructed artifacts, and analysis reports unless expressly permitted by the license type." If your plan is a published write-up built on decompiler output, check that first — and remember the general rule that analysis output grants you no rights to the original program.

None of this applies to the open engines. Ghidra, JADX, Apktool, Binwalk, Unblob, pwntools and mitmproxy are separately supplied but openly licensed (Ghidra is Apache-2.0, and REA notes it is not affiliated with or endorsed by the NSA), and you keep their notices in place. The line isn't "free versus paid." It's that "the vendor's applicable agreement controls" — and REA never supplies a key. Cracked copies, stolen keys, shared keys and activation bypasses are simply "not authorized by REA."

8. Data you shouldn't casually keep

Some of the most useful REA inputs are files that were never meant to be published. Network captures, SQLite snapshots, crash dumps and files pulled off a device routinely carry credentials, personal data and third-party content. That turns a technical exercise into a data-protection one.

The disclaimer is direct about where the duty sits: you are responsible for protecting "credentials, personal data, captured traffic, and investigation artifacts" — and for "obtaining any permission required to collect, retain, process, or share them." The list of verbs is longer than "collect." Retaining and sharing are separate acts with separate bases, and a capture that was fine to take may not be fine to keep or post.

Two habits follow. Keep analysis local where the target allows — REA's README states that "analysis runs locally, and results include the evidence and limitations behind each conclusion" — and "use an appropriate environment for untrusted targets." Malware samples and hostile captures belong in a disposable environment.

When you paste a result into an AI agent, it leaves the local tool and passes to whatever service runs that agent; treat that handoff as a separate "share" under the paragraph above, and check the specific agent or model provider's terms yourself. We do not quote a provider data-policy line here, because none was verified verbatim for this version — an unverified paraphrase is worse than no sentence.

9. Jurisdiction, and where the primary source is

Reverse engineering is constrained by two different instruments, and either can be the binding one: where you are, and what you're looking at. The disclaimer states the first plainly — reverse engineering "may be restricted in your jurisdiction or by the license of the software you analyze."

The licence side is the one people skip, so it deserves its own sentence. Clicking through an EULA or accepting API terms is agreeing to terms, and the disclaimer folds contracts into the same duty as statutes: "Comply with applicable laws, contracts, intellectual-property rights, privacy obligations, and tool licenses." Note that "contracts" sits in a list with criminal law.

The primary source is the official DISCLAIMER.md, and it is explicit about its own boundaries: it does not "amend the MIT license, impose additional copyright-license conditions, replace upstream licenses, or grant rights to third-party software or targets."

Which fixes this page's role. It is navigation and translation, never authority. When our summary and the original disagree, the original wins; when this page is silent, silence is not permission.

10. Warranty, liability, versions, and non-endorsement

Three closing provisions matter to anyone relying on a result.

No warranty. REA is "provided AS IS, without express or implied warranties, including merchantability, fitness for a particular purpose, and noninfringement." You assume the risk of deciding the tool suits your task — and, as §6 covers, no result certifies your use.

Liability runs through the MIT licence. "The warranty and liability provisions of the MIT License govern REA's authors and copyright holders" — and the disclaimer expressly does not expand them or "override rights and obligations that cannot be excluded under applicable law."

A different version is not a different rule. The project's position "covers all REA versions, distribution forms, and platforms" — historical releases, git commits, npm packages, bundled or separately distributed skills, source checkouts, release archives, redistributed copies, whatever client or OS you run. "Using an older version or another distribution channel does not imply project endorsement or remove obligations under applicable law."

Non-endorsement. Being named is not being backed, and being redistributed is not affiliation: "Redistribution, bundling, or hosting by a third party does not by itself imply affiliation with or endorsement by the REA project." That is the sentence the footer of this site rests on.