Short answer: In rea vs Ghidra, rea does not replace Ghidra. It can read a JavaScript app by itself, and it stops on a binary until Ghidra 12.1.4 or Hopper is actually installed.
I wanted to know how search worked in a tiny notes script, without reading it line by line. The same question is harder when the program was compiled and the source is gone. Reverse engineering is that job: look at a program and say how one feature works, even when you cannot open it as the original source. A binary is the compiled file the computer actually runs. Ghidra is the free desktop tool people use to turn a binary back into rough code. rea is a terminal command, and a small server a coding tool can call, that tries to do the look-up from the terminal or from chat. Use rea alone on JavaScript. Keep Ghidra when the file is a binary. I ran both on one Linux machine. Only the JavaScript path finished.
The picture is the question, not the answer. One closed app, one feature you care about, and no source file to scroll.
What is rea?
rea is one command-line tool that lets you, or a coding tool, inspect an app and come back with evidence instead of a guess. It does not itself turn a binary into rough code. It sits in front of that job, and it can also read JavaScript, Electron apps, .NET assemblies, and web pages without Ghidra.
I ran npx -y rea-agents@latest --help. The first line was rea@4.0.1, and the command list had 69 entries. The command for a script folder is analyze-javascript-application. The command for a compiled file is analyze. The second one refused to start, which is the whole comparison.
A coding tool can call the same commands if you register rea as MCP (a small server your coding tool is allowed to run). The manual block uses command npx and arguments -y, rea-agents@4.0.1, and mcp. That block was not needed here. The terminal was enough. A coding tool is a loop that reads, asks, and calls tools. That loop is mapped in how Claude Code works. rea is one tool that loop can call. It is not that loop.
The project itself is morluto/rea. Ghidra, the desktop tool it can call later, is NationalSecurityAgency/ghidra.
How do I reverse engineer a JavaScript app with rea?
Point analyze-javascript-application at the folder. It reads the files as text. It does not run them.
I made a folder with one file, search.js, 599 bytes. It held a notes list and two functions, normalize and searchNotes. searchNotes lowercases the query and keeps notes whose title or body contains that query. rea was not told those names.
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/the/folder --format jsonThe command exited 0. It parsed 1 JavaScript file, walked 122 syntax nodes, and recorded 1 finding. The result named the file search.js, the function normalize on lines 7 to 9, and the function searchNotes on lines 11 to 17. It also saw the inner filter function, the names NOTES and q, and the fields title and body. Confidence on those functions was exact. The authority was static analysis, which means it read the shape of the text. It did not run the program. The tool wrote that limit itself: JavaScript was parsed as inert text, and the code was never executed.
So rea can tell you the function exists and where it sits. It cannot tell you that a search for milk returns the oat-milk note. I already knew that, because I ran the script myself. The tool did not.
That split is the useful part. Static means it read the shape. Runtime means it watched the program run. On this folder, rea did only the first.
Does rea replace Ghidra?
No. On a compiled program, rea still asks Ghidra or Hopper to do the deep read. If neither is ready, it stops.
I ran this:
npx -y rea-agents@latest analyze /bin/ls --format jsonIt exited 1. The code was provider_unavailable. The candidates were ghidra and hopper. Ghidra was rejected with not_configured. The message said to set GHIDRA_INSTALL_DIR to an extracted Ghidra 12.1.4 directory. Hopper was missing too. The launcher it looked for was /opt/hopper/bin/Hopper, and that file was not there.
rea doctor on this machine was also unhealthy. Node was fine, at 22.23.3. The host reported itself as Debian 12 and was marked unsupported. The hosts it names are macOS 12 or newer, Ubuntu 24.04 or newer, Fedora 41 or newer, 64-bit Arch, and an experimental Windows path. Java on the machine was 17.0.20.1, 64-bit, and the Java check failed as unsupported_version. In rea 4.0.1 that check asks for a 64-bit JDK 21. A newer Java alone would not have saved this run. The host check would still have failed, and there was still no Ghidra directory.
If your machine is one of those supported hosts and you only want to read a JavaScript or Electron app, you can skip Ghidra. If you want a function out of a binary, rea is the front door and Ghidra is still the room.
How do I connect rea to Ghidra?
Install Ghidra yourself. rea will not download it, and it will not install Java for you.
The version the tool checks for is Ghidra 12.1.4, with a 64-bit JDK 21. On macOS the Ghidra folder also needs the native decompiler for that Mac. Linux, on the failure I hit, said the native decompiler was not required on that platform. Then:
export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.4_PUBLIC
export JAVA_HOME=/absolute/path/to/jdk-21
npx -y rea-agents@latest doctor --format json
npx -y rea-agents@latest setup
npx -y rea-agents@latest providers --format jsonsetup is supposed to show its changes before it writes them, and it can record the Ghidra path into the coding tools it detects. I skipped setup. There was no Ghidra directory to point at, and with doctor already rejecting the machine there was no reason to let it write agent config.
providers still listed Ghidra and Hopper by name, with version empty, next to rea’s own artifact reader and a .NET reader. Listing a name is not the same as opening a binary. analyze /bin/ls had already proved that.
The Ghidra path inside rea 4.0.1 is a temporary read-only import. The imported program and the temporary project are deleted on close. It is not an edit of a Ghidra project you already have open. No live Ghidra session was reached on this machine, so that is how the 4.0.1 build is written to behave, not a session watched end to end. If you live in Ghidra’s window, renaming variables and fixing types by hand, stay in that window. rea is the wrong tool for that part of the job.
When should I stay in Ghidra?
Stay in Ghidra when the file is a binary and you need to change the analysis, not only read a one-shot report. Stay there when doctor says your host is outside the list above. Stay there when you already have a project open and you want the names you typed last week. rea’s Ghidra side does not keep that project.
Stay with rea, and skip Ghidra, when the target is a JavaScript folder, an Electron app, a website you can observe, or a .NET assembly you only need to inventory. That is the path I actually finished. One command, one file, the two function names, and a written limit that the code never ran.
| Job | rea alone | rea with Ghidra | Ghidra by itself |
|---|---|---|---|
| Read a JavaScript folder | Yes. I did this. | Not needed | Wrong tool |
| Open a compiled program | Stops with provider_unavailable | Needs Ghidra 12.1.4 and JDK 21, on a host doctor accepts | Yes, in its own window |
| Keep names you typed in an open project | No | No. Temporary import, deleted on close | Yes |
| My Debian 12 machine | JavaScript path worked | Doctor marked the host unsupported | Not installed |
Hopper is the other deep reader. It is a separate app with its own license. rea doctor says rea setup can install it, and you have to agree. I skipped that. If you have neither Hopper nor Ghidra, analyze on a binary stops the way mine stopped.
Is rea worth it?
Yes, if you want a coding tool, or your own terminal, to inspect a JavaScript app and show its work. No, if you hoped it was a free Ghidra that installs itself.
The check takes about ten minutes. Put a real folder of your own scripts on disk. Run analyze-javascript-application on that folder. Read the function labels and the limitations list. If the names match the file, you have the JavaScript path. Then run analyze on one compiled binary you are allowed to inspect. If the error is provider_unavailable, you still need Ghidra 12.1.4 or Hopper, on a host the doctor accepts.
I would not point it at a program you are not allowed to inspect. The tool runs as you. It is not a locked room around the target. A separate box for a coding tool is a different job, the one in the coop sandbox note. And if the coding tool, once it understands the feature, rebuilds it with three extra layers, the brake is the short file in the CLAUDE.md note, not another reverse-engineering pass.
Common questions about rea vs Ghidra
Can I use rea instead of Ghidra?
Only for the jobs rea does without a deep provider. JavaScript worked with no Ghidra on my machine. A native binary did not. Electron, passive web observation, and managed-assembly inventory are also in the command list of the same build; this run only finished the JavaScript path.
Why does rea fail if Ghidra is not installed?
Because analyze on a binary picks Ghidra or Hopper and will not invent a decompiler. My /bin/ls run failed with provider_unavailable, and the Ghidra line was GHIDRA_INSTALL_DIR is not set. The Java on the machine was also the wrong major version for that build.
Does rea upload my app?
No. The JavaScript run read a local folder and wrote the evidence on that machine. There is no hosted analysis step in the command I ran. The help text and the doctor output never asked for an account.
Do I need Hopper?
No, for JavaScript. Yes, for a compiled program, if you do not bring your own Ghidra 12.1.4. Hopper stays a separate install with its own license. On my run the launcher was simply missing, and that was enough for rea to refuse the binary.
I will keep rea on script folders, where it named searchNotes without being told. I will keep Ghidra for compiled files, because rea stopped at the door and told me the exact reason.