New to RE with AI? What to reverse engineer first, and how to ask

[CassieFox23]

TL;DR: Start small. Ask your AI short questions about one file you own, and check every answer. This guide gives a ladder of six targets, easiest first. It runs from a C program you write yourself up to malware inside a VM.

I'm a hobbyist who tests REA, not a lawyer, and this is not legal advice. I asked Claude Code (Sonnet 5.5) to research and draft this guide. Facts it checked say where they came from. Facts it could not check say "unverified". Dates are 2026-10-12.

Who is who. "I" is me, the human. "We" is me and Claude Code, the AI agent I use. I pick the targets and the questions. Claude Code runs the tools on my PC. The bigger tests below say which model ran them.

Edit (2026-10-12): A blind review found mistakes, and this version fixes them. Setup now ends with a working engine. The first steps come first. Wrong links and practice-site facts are fixed. The tips now fit any AI, not just Claude.

Part 0: for people new to both RE and AI

What this looks like

Reverse engineering (RE) with an AI means small, specific questions. You pick one file, one function or one format. You ask what it does. Then you check the answer.

It does not mean "rebuild this app". REA does not hand you a finished copy of a program.

Why "REA , make no mistakes, go" fails

• Big apps are huge. GIMP is an open-source photo editor (GPL-3.0-or-later, from the header of its app/main.c). GitHub's language count shows about 44 million bytes of C in its repo. That is the C only. We got it with gh api repos/GNOME/gimp/languages on 2026-10-12.
• The AI can only hold so much. At about 4 bytes per token, 44 million bytes is about 11 million tokens. The 4 is a rough rule of thumb, so this is an estimate. Even a big hosted model, like Claude Opus 5.5, holds up to 1M tokens, per models.dev. The source alone is about 11 times that. We did not measure any closed-source app, so its size is unverified.
• Stripped files lose your names. In a test on my PC, REA showed my own function main in a stripped build as FUN_004003a0. Ghidra made up that name. The AI has to guess what the code is for.
• It is against REA's rules to copy proprietary software. REA's disclaimer lists "copying proprietary software" as a thing it will not help with. In my #2304 guide, "Selling or posting a rebuilt copy of someone else's software" is red.
• The AI may stop. Hosted AIs have safety checks. Claude's checks, for one, "can sometimes flag" real security work. So says the Claude Code errors page. My Using REA with Claude and other AI models: what's fine, what needs permission, and where are the legal lines? #2304 guide covers several AI makers, with tips: say what you own, and keep the ask small.
• The answers can be wrong. The disclaimer says AI answers can be partial or wrong. No prompt can promise "no mistakes". You check.

Good ask, bad ask

Bad ask	Good ask
"REA , make no mistakes, go."	"I compiled hello.c myself. Open hello and show me main. What does each part do?"
"Rebuild the program."	"Which function prints this text? Who calls it?"
"Get past the license check."	"This is a crackme. Where does it check my input? Explain it in plain words."
"Is this safe? Just tell me."	"What does this function do? Show the assembly behind your answer."
"Do the whole job and send the result."	"Do one step. Tell me what you are not sure about."
"Write me a cheat for this online game."	"Here is my own build of a small open-source game. Where is the score kept?"

Bad asks 3 and 6 are on a list in REA's disclaimer. It lists what REA "will not help with". That list names "license checks" and "anti-cheat systems". It also names "developing game cheats". Bad ask 1 may break the same list if the app is closed-source. All six are weak asks anyway.

How we actually use it

I do not ask REA to take a whole game apart. I point it at one small part of a mod, to fix a problem or find a conflict. REA gives my AI and me the real bytes and functions from a file, plus Ghidra's analysis behind each answer. Each reply has an evidence id and a list of limits. That is easier than working with an agent alone. I put the questions in my own words. My notes keep what REA showed, not what I typed.

The ladder, easiest first

Every level has the same rule: it is yours, it is open source, or it was made to be taken apart. Nothing here is about online games, anti-cheat, DRM or cracking. The setup steps and Level 1 are right below. Levels 2 to 6 are in Details, with starter prompts.

1. A tiny C program you write yourself, on Linux. Compare what REA shows with your own source.
2. Crackmes and practice CTF challenges, which are made to be solved.
3. A stripped build of a small open-source tool, like bzip2.
4. Open-source games and old programs, and save files of a single-player game you own.
5. Your own web app, or an open-source Electron app.
6. Malware, inside a VM only. This one is for later.

Your first 30 minutes

Before you start. Level 1 assumes Linux, with gcc and binutils installed. Binutils is the package that has strip, objdump and nm. Run gcc --version to check for gcc. What about Windows? REA's README has a link to its "experimental Windows Ghidra support" page. Its install doc says the Windows lane "admits native x86 and x86-64 PE applications and DLLs". PE is the Windows program format. Level 1 makes a Linux program, so it needs Linux.

REA's README gives most of these steps, and its installation doc gives step 2. I quote their commands as written. We did not run setup for this guide.

1. Check Node.js. The README says REA needs "Node.js 22.x (>=22.19), 24.x (>=24.11), or 26+, plus npm". Run node --version to see yours.

2. Get Ghidra and a JDK first. Setup will not do it for you. In the doc's words, setup "never downloads, installs, upgrades, or modifies Ghidra or Java". It says to "Extract Ghidra and install the JDK outside REA, then export absolute paths".

   • Download Ghidra 12.1.x from Ghidra's releases page on GitHub, and unzip it. The doc says REA "accepts Ghidra 12.1.x". On 2026-10-12 the newest was 12.1.4.

   • Install a 64-bit full JDK, 21 or newer. The doc says "Current 12.1 releases require JDK 21 or newer". "Full" means it has javac, which REA's check looks for.

   • In the terminal where you will run setup, set the two paths. Use your own folders:

     export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.4_PUBLIC
     export JAVA_HOME=/absolute/path/to/jdk-21

     The doc marks JAVA_HOME as "optional if java/javac are on PATH".

   Why Ghidra? For native programs, the README lists three engines. The disclaimer calls two of them proprietary tools. This guide uses the third, Ghidra. It is free, and it is Apache-2.0. On my PC, REA reported Ghidra 12.1.4. My NE (16-bit Windows) executables through the Ghidra lane: I have a working fork prototype. Would you want it? #2231 test used JDK 21. Static JavaScript and .NET checks need no engine.

3. Run setup in that same terminal. The command is npx rea-agents setup. The README says to choose your agents, review the proposed changes, and approve them. It supports many agent apps, such as Claude Code, Cursor, OpenCode and Qwen Code. See REA's list of supported agents. Setup can "save verified paths for an existing Ghidra installation". It "shows every exact environment entry in its plan". Setup may also offer Hopper, as "a separate optional choice". Hopper is "separate commercial software with its own license". This guide uses Ghidra, so you can say no to Hopper. Then restart your agent.

4. Check the link. Your agent app should list REA as a connected MCP server. Each app shows this its own way. In Claude Code, for example, type /mcp, or run claude mcp list in a terminal. We read both in Claude Code's own MCP docs.

5. Optional check. Run npm install --global rea-agents to get the rea command. Then rea doctor --provider ghidra --json tests Ghidra. That row is in REA's docs/installation.md.

6. Make a tiny target. Use the C program in Level 1 below.

7. Ask three starter questions. Give the full path, because REA rejects relative paths.

   • "Open /full/path/hello-O2-stripped with REA. What kind of file is it?"
   • "Search its strings for 'secret'. Which function uses that text?"
   • "Show me that function as code. Compare it with my hello.c. What differs?"

Running a program is a separate step. The README says runtime capture "runs or interacts with the selected target". REA's process capture doc says "This is not a sandbox." So never ask your AI to run a file from a stranger on your main machine.

How to check the AI's answer

• Compare it with the source, if you have it. Your own code and open-source code give you an answer key.
• Ask your AI to show the bytes or the assembly behind each claim.
• Look at the label on each piece of evidence. REA's evidence schema has three: observed, derived and inferred. In my A stripped bzip2 build on Linux: what REA returned, checked against the build and the docs #2254 test, facts from Ghidra came back observed. Facts REA worked out came back derived. Check the inferred ones the hardest.
• Ask what it is unsure about. Each REA reply has a list of limits. Read them.
• Check with a second tool. objdump -d and nm are on most Linux systems.
• Ask the same question a second way. If the answers differ, dig in.
• Treat names as guesses. Names like check_password are the AI's labels, not facts. A stripped file keeps no names for your own functions.
• Ask for small slices. A reply for my 5-file test app ran to about 262,000 characters.

Level 1: a tiny C program you write yourself

What it is. A program of about 20 lines that you write and compile. You open the build in REA and compare what it shows with your own source.

Why it is a good start. You know the right answer. You can see what the compiler does to your code. A program you wrote is yours to take apart.

Where to get it. On Linux with gcc and binutils, your computer has what you need. The compiler is gcc, which is GPL-3.0-or-later. We read that from the header of gcc/main.cc in the gcc-mirror GitHub repo. The repo also holds COPYING3 and COPYING.RUNTIME. GitHub's license API says GPL-2.0, from the older COPYING file. Save this as hello.c:

#include <stdio.h>
#include <string.h>

int add_up(int n) {
    int total = 0;
    for (int i = 1; i <= n; i++) {
        total += i;
    }
    return total;
}

int check_word(const char *guess) {
    return strcmp(guess, "pancake") == 0;
}

int main(int argc, char **argv) {
    printf("Sum of 1 to 10 is %d\n", add_up(10));
    if (argc > 1 && check_word(argv[1])) {
        puts("You found the secret word!");
    } else {
        puts("Try again.");
    }
    return 0;
}

Build it four ways:

gcc -O0 hello.c -o hello-O0
gcc -O2 hello.c -o hello-O2
strip hello-O0 -o hello-O0-stripped
strip hello-O2 -o hello-O2-stripped

Claude Code (Sonnet 5.5) ran these on my PC with gcc 16.2.1, while drafting this guide. All four builds work. The flag -O0 means no tuning. The flag -O2 lets the compiler tune the code. The tool strip removes the names of your own functions. Names from shared libraries, like printf, stay, since the program needs them to run.

Your addresses may differ. Run file hello-O2. Ours says "LSB executable". If yours says "pie executable", your gcc made a PIE build. Then main sits at a different address, so its FUN_ name differs too.

First prompts.

• "I wrote hello.c myself, and I compiled it. Open /full/path/hello-O2-stripped and tell me which function is main."
• "Search its strings for 'secret'. Which function uses that text? Show it as code and compare it with my source."

What we saw. Claude Code (Sonnet 5.5) opened hello-O2-stripped with REA and Ghidra 12.1.4 on my PC on 2026-10-12. We did not open the -O0 builds in REA, so we make no claim about those. The reply showed:

• The text "You found the secret word!" at 0x40120e. Stripping did not hide it.
• main at 0x4003a0, called FUN_004003a0. Your own names are gone.
• The code reads printf("Sum of 1 to 10 is %d\n",0x37). The call to add_up is gone. The compiler worked out the sum, 55, before you ever ran it. 0x37 is 55.
• The code compares your guess with "pancake" using strcmp. A secret in a file is not secret.

What you learn. Stripping removes your own names but keeps text. Optimizing changes the code. A decompiler gives a guess at your source, not the source.

Bonus. Make a small SQLite file yourself, like a to-do list. REA can read it with inspect_sqlite_database. Its doc says this needs "Node.js 24.x >=24.15 or 26+". So Node 25 is not on the list. SQLite is public domain, says sqlite.org. Untested here.

How to pick your own target

Ask these in order. A "no" to the first three means stop.

• Do I own it, is it open source, or was it made to be taken apart?
• Is it offline? No online game, no account, no server, no anti-cheat, no DRM.
• Do its license or its site's rules let me take it apart? Skip this one if I made it. For open source, read the LICENSE file. For a crackme from crackmes.one, its FAQ says yes.
• Is it small? Start with one file under about 1 MB. That is my rule of thumb.
• Do I have the source to check against?
• Is it from a stranger? Then use a VM and read it before you run it.
• Can I say in one line what I want to learn?
• Am I asking for one small thing, and saying what I own?

Details (tap to open)

Level 2: crackmes and CTF challenges

What it is. Small programs built by other people to be taken apart. You find how the check works. A crackme is a program with a hidden check. A CTF (capture the flag) is a puzzle contest.

Why it is a good start. They are made for this, they are small, and many have a write-up to compare with.

Where to get it.

• crackmes.one is a site of small programs made to be solved. Visit crackmes.one. The crackmes.one FAQ says "all crackmes available on this website have been made to be cracked". It has upload rules too. One page is the Crackme Submission Rules. The other is the Writeup Submission Rules. The FAQ's ban list is about what people may upload. It bans game cracking, cheating or modding, cracks for paid software, DRM bypass, and real malware. The files use the zip password "crackmes.one". The FAQ says to run crackmes in an isolated environment, like a virtual machine. The crackmes.one search page filters by difficulty (1 to 6), size, language, and platform. Try Unix/linux, C/C++, small size, and difficulty 1. The FAQ says difficulty 1 crackmes "are designed for beginners". You need no account to download. On 2026-10-12, a download link sent us straight to the zip, with no login.
• CyLab Security Academy, which was picoCTF. The old picoCTF page title now reads "picoCTF.org is now CyLab Security Academy". It is a free program from Carnegie Mellon University. It says "No experience needed" and lists a Reverse Engineering group. Use the practice CyLab challenge library. It loads only as a script, so whether it needs a free account is unverified. The CyLab terms of use say users must be 13 or older. They say "Using tools from the internet is OK; asking people on the internet to help solve the problem is not". They say to use "all available resources". They also say "users solve the problems themselves". They do not mention AI. So whether an AI counts as a tool or as help is unverified. Each live event has its own rules. So stay out of live events with an AI, unless the event says it is fine.

First prompts.

• "This is a crackme from crackmes.one. It was made to be solved. I downloaded it myself. Open it and tell me what it does with my input."
• "Where does it check my input? Explain the check in plain words. Give me a hint, not the answer. I want to solve it myself."

What you learn. Strings, comparisons, and how a program decides yes or no. Aim to find the password and explain how the check works. A keygen for a crackme is fine, and the FAQ says why you might write one. Real software is another matter. There, REA's disclaimer will not help you get past "license checks". The FAQ says patching the file while you study it "is completely fine". But a writeup should not end in a patch, unless the author says it is fine.

Safety. These files come from strangers. Running a file is a separate step from reading it. If you run one, use a VM.

Level 3: a stripped build of a small open-source tool

What it is. A small command-line tool that is open source. You get a stripped build and the real source. Then you ask REA where things are, and check against the source.

Why it is a good start. The source is the answer key. It is how my #2254 demo worked.

Where to get it.

• bzip2 1.0.8. The source is on the bzip2 home page. Get the bzip2 1.0.8 tarball from Sourceware. Its LICENSE file holds the bzip2 license, a BSD-style one with four conditions. We read it from that tarball on 2026-10-12. My PC already has /usr/bin/bzip2. We checked that it is version 1.0.8, stripped, and has the "Can't guess original name" text. Your distro may differ, and it may patch the source.
• kilo (BSD-2-Clause). A text editor in under 1,000 lines of C, says its README. License from GitHub's license API. Get kilo on GitHub. Its Makefile builds it with make. Then strip a copy.

First prompts.

• "Open /usr/bin/bzip2. Find the text 'Can't guess original name'. Which function uses it, and who calls that function?"
• "I built kilo from source and stripped a copy. Which function handles the Ctrl-S key? Compare it with kilo.c."

What you learn. How a stripped build maps to source. How the compiler can fold small functions into bigger ones. Who calls whom.

Level 4: open-source games, old programs, and your own save files

What it is. This level has three kinds of target. One is bigger open-source programs. One is old programs. One is data files from a single-player game you own.

Why it is a good start. It is the same skill as Level 3 on bigger, more fun targets. They are still open source, so you can still check.

Where to get it.

• SuperTux (GPL-3.0-or-later). A 2D platform game. License from the header of its src/supertux/main.cpp. Get SuperTux on GitHub. Build it yourself. Untested here.
• OpenMW's small tools (GPL-3.0). OpenMW is an open-source engine. Its apps folder has esmtool, bsatool and niftest. They read data files from an older single-player RPG you own. The project is on OpenMW's GitHub page. A release ships esmtool. Strip a copy, as in the esmtool case in Real examples below.
• Old programs from Open Watcom v2. The license is the Sybase Open Watcom Public License 1.0 (Watcom-1.0), read from its license.txt. The SPDX license list marks it as approved by the OSI, but not as free by the FSF. Builds are on the Open Watcom v2 releases page. REA's DOS doc says REA opens 16-bit DOS programs and refuses NE, LE and LX files. In NE (16-bit Windows) executables through the Ghidra lane: I have a working fork prototype. Would you want it? #2231, a 16-bit Windows (NE) program was refused. This is a stretch goal.
• Save files of a single-player game you own. Work offline, on a copy. Read them to understand the format. REA is built for programs, so your agent's own file tools may suit a plain data file better. That is my reading of the docs, not a test.

First prompts.

• "I built SuperTux from source. One menu shows the text . Find the function that uses that text."
• "This is a copy of a save file from a single-player game I own. Here are two copies, before and after I picked up one item. Which bytes changed?"

What you learn. Bigger call graphs. File formats. How to cut a big program down to one question.

Level 5: your own web app, or an open-source Electron app

What it is. Electron apps are desktop apps built from web pages. REA can read a web page's scripts, and an Electron app's folder or app.asar file.

Why it is a good start. Scripts are plain text. Your own app has an answer key. A static check reads the files and does not run the app, says the README.

Where to get it.

• Your own app. Write a tiny web page, or a tiny Electron app. To start a new Electron app, the Electron team now points to Electron Forge (MIT). For a tiny target to read, Electron's minimal-repro (CC0-1.0) has just a few small files. It used to be called electron-quick-start. Electron itself is MIT. A bundler such as Vite (MIT) can make a packed build you can compare with your source.
• An open-source Electron app. MarkText (MIT) has a Linux AppImage and tarball on the MarkText releases page. Its latest release when we looked was v0.21.2. Zettlr (GPL-3.0) has an AppImage on the Zettlr releases page. Latest was v4.8.0. Match the release tag to the source tag. We did not download or open either one.
• An Android option. Fossify Calculator (GPL-3.0-only) has an APK. Get it from the Fossify Calculator releases page. Its F-Droid page lists GPL-3.0-only. REA's Android lane needs JADX (Apache-2.0) and a full JDK, says the README. Untested here.

What we tested. Claude Code (Sonnet 5.5) made a 5-file Electron-style folder on my PC for this guide. It has a main file, a preload file, a page, a script and a package.json. It pointed analyze_javascript_application at it. REA found 1 window, 1 preload file, 1 bridge API, and 1 message channel. It showed a sender in the page and a handler in the main process. It did not run the app. The reply was about 262,000 characters long. We did not open MarkText or Zettlr.

First prompts.

• "This folder is a tiny app I wrote: /full/path. List its window, its preload file and the messages between them. Keep the answer short."
• "Which file handles the button click? Show it next to my source."

Only your own sites. Use REA's browser tools on pages on your own computer. Never point them at a site you do not own. The disclaimer says a right to inspect a file "does not necessarily" let you do more. One thing it names is "interaction with another party's system".

What you learn. Modules, imports, and how a window talks to the main program.

Level 6: malware, for later

Warnings first.

• Do this only inside a virtual machine. Use no shared folders and no shared clipboard. Take a snapshot you can roll back to.
• A hosted AI needs the internet to reach its model, so the VM stays online. That is why the sample must never run. Do static work only: read it, and never run it.
• Never run a sample on your main machine.
• REA's process capture "is not a sandbox", says its doc. So keep REA's runtime tools away from a sample.
• Get samples only from a research source you can trust. REA's disclaimer says not to use REA for "malicious deployment of malware". If you ever share a sample, zip it with a password, as MalwareBazaar does.
• Your AI may refuse or stop. Using REA with Claude and other AI models: what's fine, what needs permission, and where are the legal lines? #2304 says Anthropic, for one, warns that this work "may be interrupted". Don't try tricks. REA's disclaimer says it will not help with "evading the usage policies or safety measures" of AI firms.

What it is. You take apart real malware to learn how it works.

Why it is last. One wrong click on a live sample can harm your machine and your files.

Where to get it. MalwareBazaar is run by abuse.ch and Spamhaus. Visit MalwareBazaar. The abuse.ch terms of use say you must be an authenticated user. Use is free for not-for-profit work. The MalwareBazaar FAQ says the batch zip files use the password "infected". How a single download works is unverified. Use a VM program that you trust.

First prompts.

• "This sample is from a research site. I'm in a VM, and I will not run it. Do static analysis only. List its imports and strings."
• "Which strings look like web addresses or file paths? Show the evidence for each."

What you learn. Imports, strings, packing, and how to write up what you found.

Real examples: how we use REA on mods and small tools

These are our own runs. Claude Code ran each one on my PC, and each part says which model.

A neon city RPG (wake up, choom): troubleshooting its mod plugins

I don't name the game, because it is closed-source. An earlier Claude Code session ran these, and my notes don't say which model. I always work on a copy of a mod file, never the installed files. The game's own program file is about 60 MB. The first open in REA took about 20 minutes. That time comes from my own notes and we did not re-time it. So small mod files win.

• A tiny graphics-fix plugin. It is closed-source, so I don't name it. It is 12 KB with 89 functions. We asked what it checks when the game loads it. REA showed it compares exact bytes at four spots in the game's program file. If any byte differs, it logs "executable signature mismatch." and stays out. If all match, it hooks the four spots. Why it helped: it explains how a plugin can go quiet after a game update. The log line is the first thing to check. That last step is my inference, not tested. On REA 6.0.0, two of the four spots would not decompile. On 6.2.0 all four did.
• Codeware 1.20.5 (open source, MIT). It is 1.9 MB with 5,057 functions, and it took about a minute to analyse. We asked which function logs one message about a component. REA's answer matched the function ReportOrphanComponent in the real source at the v1.20.5 tag. It reads two fields, at +0x40 and +0x48. The same file finds game functions by a hash, using RED4ext.SDK (MIT). The error text "Failed to find the address for the hash" sits inside the DLL. Why it helped: open source gives you an answer key. You see REA be right before you trust it on a closed file.
• Two big story mods, read before install (unnamed). This one is not a REA case. These are script mods. My notes list a Lua file and a .reds file, so we read them as plain text. We asked what each one touches. The notes say the newer one keeps the old version's five files byte for byte. It adds five new spots that need a second "core" mod. Without the core, it shows a popup on every start. The core mod wraps no game code and does no per-frame work. One 8 KB archive stayed unread, because it needs another tool. Why it helped: it is the same habit. Read first, install second. We knew the needs and risks before the install.

A dragon-shouting fantasy RPG: a memory bug in its mod plugins, found with kuna

Same rule: I don't name the game, and I don't ask REA to take it apart. These two plugin files are open source. We ran them through kuna, a separate open-source decompiler (Apache-2.0), in kuna issue 1034. Claude Code (Sonnet 5.5, verified by Opus 5.5) ran it, per the footer of that issue. It is not REA, but the habit is the same.

• A batch of 170 plugin files. We ran decompile-all with a 6 GB memory cap per run. 167 finished clean. Two hit the cap. One is the CrashLoggerSSE plugin file (MIT, 3,209,728 bytes). The other is the A-pose fix plugin file (GPL-3.0, with added exceptions). The last file finished, but one of its worker processes hit the cap on the way. The issue counts only 169 of the 170. That last file comes from my run notes. Why it helped: a batch can find odd files that you would never check by hand.
• Halving to find the cause. In the first file, one function is 297,952 bytes long. The next largest is 19,888. Every group of functions with it hit the cap. Every group without it ran clean. Memory grew about 376 MB per second and hit the cap at about 17 seconds. The 60 second limit did not stop it. The maintainer found why: kuna never checked that limit in this step. Why it helped: numbers like these gave the maintainers something to act on.
• The fix. The kuna maintainers fixed it in [AUTOMATED] Let the per-function watchdog stop heritage's guard placement Noelo-Lab/kuna#1044 and [AUTOMATED] Stop one function at a memory limit (--max-fn-memory, cgroup default) Noelo-Lab/kuna#1045. The first made the time limit work. The second added a memory limit, --max-fn-memory. On the merged build, the first file finishes in 20 seconds with 8 workers. The second finishes in 17 minutes. There, 390 of 14,543 functions end in errors, mostly from the memory limit. Why it helped: the report led to a fix that other people can use.

Small open-source tools, no game names needed

Claude Code ran these too. The tests are in #2326, #2254 and #2231. Each footer there names the model: Sonnet 5.5, verified by Opus 5.5.

• OpenMW's esmtool (GPL-3.0). We opened a stripped copy of the 0.51.0 build. We asked REA for the callee lists of 50 functions, then checked each one against objdump. 22 of the 50 lost real calls. Twenty of those were picked because they lost the most, so 22 is not a rate. All 100 replies said complete, with no note about the cut. This became issue [Bug] Callee and caller reads give no warning when Ghidra's function body stops short #2326, and another contributor opened a fix in fix(ghidra): warn when callee/caller reads stop at a truncated function body #2360. Both were still open on 2026-10-12. Why it helped: REA's reply was clear enough to test against a second tool, and the gap was easy to show.
• A stripped bzip2 (A stripped bzip2 build on Linux: what REA returned, checked against the build and the docs #2254). We asked which function prints one message. REA found the function, one caller and 24 callees. All of them matched an unstripped build and the source. REA also refused two bad requests with typed error codes. Why it helped: every answer could be checked, and each carried an evidence id.
• An old Open Watcom program (NE (16-bit Windows) executables through the Ghidra lane: I have a working fork prototype. Would you want it? #2231, [Feature] Open 16-bit Windows (NE) executables through the Ghidra lane #2408). Open Watcom v2 uses the Sybase Open Watcom Public License 1.0. REA refused a 16-bit Windows (NE) program from it, and its docs say that is on purpose. In my fork, a small change opened the file with 217 functions, the same as Ghidra alone. That became a feature request, [Feature] Open 16-bit Windows (NE) executables through the Ghidra lane #2408. It covers one sample on Linux only. Why it helped: the refusal was clear, so we knew where the limit was.

Not confirmed

• Whether the CyLab practice library needs a free account. The page loads only as a script, so we could not see.
• How CyLab rules apply to AI help. The terms allow "tools from the internet" but not "asking people on the internet". They never say which one an AI is.
• Whether the Electron lane works on MarkText and Zettlr. We tested only a hand-made folder. We downloaded neither app.
• Whether REA's Android lane works on the Fossify Calculator APK.
• How a single MalwareBazaar download works, and whether it needs an Auth-Key.
• The ~20 minutes to open a 60 MB game file. It is secondhand, from my own notes.
• Which model ran the neon city RPG tests. My notes don't say.
• The 11 million tokens. It uses a rough 4 bytes per token.
• The sizes of closed-source apps. We did not measure any.
• The -O0 builds in REA. We built them but did not open them.
• The SuperTux and OpenMW build steps. Not run here.
• Whether Ghidra's native analysis ever runs the file. REA's docs we read only say runtime capture runs a program.
• The questions in "How we actually use it" are in my own words. My notes do not keep what I typed.
• Which A-pose fix build matches the file we tested. [AUTOMATED] One huge function uses over 6 GB of memory in decompile Noelo-Lab/kuna#1034 says the repo has no releases.
• The status of [Bug] Callee and caller reads give no warning when Ghidra's function body stops short #2326, fix(ghidra): warn when callee/caller reads stop at a truncated function body #2360 and [Feature] Open 16-bit Windows (NE) executables through the Ghidra lane #2408 changes over time. All three were open when we checked.

Sources

• REA README
• REA disclaimer
• REA installation doc
• REA Windows Ghidra doc
• REA evidence schema
• REA DOS doc
• REA process capture doc
• REA SQLite doc
• My use-case guide, #2304
• My bzip2 demo, #2254
• My NE prototype, #2231
• Callee warning issue, #2326
• Fix PR, #2360
• NE feature request, #2408
• kuna issue 1034
• kuna time limit fix, PR 1044
• kuna memory limit fix, PR 1045
• Claude Code MCP docs
• Claude Code errors page
• crackmes.one FAQ
• The rules for a crackme on crackmes.one
• The rules for a writeup on crackmes.one
• crackmes.one search
• The CyLab Security Academy site
• CyLab terms
• The CyLab page for contest players
• picoCTF home page
• bzip2 home
• The bzip2 1.0.8 tarball, with its LICENSE
• kilo
• SuperTux
• OpenMW
• Open Watcom v2 license
• SPDX entry for Watcom-1.0
• Electron Forge
• Electron minimal-repro
• MarkText
• Zettlr
• Fossify Calculator
• Fossify Calculator page on F-Droid
• JADX
• Ghidra
• Ghidra releases
• gcc source header
• GIMP source header
• SQLite copyright page
• MalwareBazaar
• MalwareBazaar FAQ
• abuse.ch terms
• models.dev
• Codeware, by psiberx on GitHub (MIT)
• RED4ext.SDK
• CrashLoggerSSE
• The A-pose fix plugin, by Monitor221hz on GitHub (GPL-3.0, with added exceptions)
• kuna
• My plugin notes for the neon city RPG. A local file in my Gaming & Mods vault, not public.
• My OpenMW recheck notes, dated 2026-10-12. A local file in my Gaming & Mods vault, not public.
• My kuna batch notes, dated 2026-10-11. A local file in my Gaming & Mods vault, not public.

Licenses checked

• REA: MIT, GitHub license API.
• Ghidra: Apache-2.0, GitHub license API.
• gcc: GPL-3.0-or-later, file header in the gcc-mirror repo, plus COPYING3 and COPYING.RUNTIME there.
• GIMP: GPL-3.0-or-later, header of app/main.c. The license API said NOASSERTION.
• bzip2: the BSD-style bzip2 license, LICENSE in the 1.0.8 tarball from Sourceware.
• kilo: BSD-2-Clause, license API.
• SuperTux: GPL-3.0-or-later. Its src/supertux/main.cpp header says "or (at your option) any later version".
• OpenMW: GPL-3.0. Its README says "GPLv3". It adds neither "only" nor "or later".
• Open Watcom v2: Sybase Open Watcom Public License 1.0, its license.txt. The SPDX id is Watcom-1.0. SPDX list 3.29.0 marks it OSI-approved, but not FSF-free.
• Electron: MIT, license API.
• Electron Forge: MIT, its LICENSE file.
• Vite: MIT, license API.
• Node.js: an MIT-style license, read from its LICENSE file. The license API said NOASSERTION.
• npm: Artistic License 2.0, read from its LICENSE file. The license API said NOASSERTION.
• Electron minimal-repro: CC0-1.0, license API and its LICENSE.md.
• MarkText: MIT, from the license API.
• Zettlr: GPL-3.0. Its package.json says "GPL-3.0", and its README says "GNU GPL v3".
• Fossify Calculator is GPL-3.0-only, as its page on F-Droid says. Its repo holds the plain GPL v3 text.
• JADX: Apache-2.0, license API.
• SQLite: public domain, says its own site.
• kuna: Apache-2.0, license API.
• Codeware: MIT. RED4ext.SDK: MIT. CrashLoggerSSE: MIT. All from the license API.
• A-pose fix plugin: GPL-3.0, from its LICENSE file, with a modding exception and a linking exception in its EXCEPTIONS file.

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

[ylwl1997]

Thanks for writing this ladder — the “own tiny C first → check every claim → never ‘reverse the whole app’” framing matches what trips most new REA users.

One practical add-on for people who want a disposable practice target without installing Ghidra on day one: the community Codespaces/Actions lab ships a self-owned Electron-shaped demo only (authorized fixture), so you can walk install → absolute path → narrow question without bringing a stranger’s binary onto your main machine.

Community install notes (unofficial, pin-aware): https://rea.run/docs/install/

Not affiliated with the REA maintainers — just documenting the same authorized-lab habit you describe.