Reverse Engineer Any App using REA (41k Stars)

Author: Prompt Engineer · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Reverse Engineer Any App using REA (41k Stars) · Channel: Prompt Engineer · 05:59 · Watch on YouTube

Topics: AI agents, Cybersecurity and software security, AI developer tools, Open source and software ecosystems

Summary

REA is an open-source reverse-engineering tool available as an MCP server and command-line utility, supporting targets that range from JavaScript and Electron apps to native binaries and Android APKs. The presenter tests its JavaScript analysis on a small Electron app and reports that REA correctly identifies the IPC channel, sender, and handler without executing the code. The output also states its limitations, including that some relationships are inferred from syntax rather than proven at runtime. The demo reveals a Node.js version requirement and practical constraints: native analysis engines were missing, and analyzing a large Electron app produced an enormous output file.

Key points

REA returns findings with supporting evidence and a list of limitations.
It supports multiple target types, including JavaScript and Electron apps, websites, Android APKs, native binaries, and network captures.
The presenter installed the CLI on Windows and used version 6.2.0.
The presenter encountered a Node.js requirement of version 22.19 or newer; using NPX with Node 24 worked around the issue.
In the test app, REA identified one IPC channel, one main handler, and one renderer transmission, and paired the sender with the handler.
The analysis parsed JavaScript without running the app.
REA warns that Electron relationships may be inferred from syntax and that graph coverage is incomplete.
Native binary decompiling was unavailable in the demo because Hopper, Ghidra, and IDA were not installed.
Analyzing a roughly 150 MB Electron app produced a 577 MB output file after eight minutes, so the presenter recommends narrowing the scope.
The project is intended for lawful reverse engineering, and users are responsible for having authorization.

Chapters

Start	Chapter	Summary
00:01	Introducing REA and its supported targets	The presenter introduces REA, describes its evidence-backed findings and supported targets, and outlines installation options and CLI commands.
01:42	Node.js requirement and Electron test	After encountering a Node.js version error, the presenter uses Node 24 through NPX and tests REA on a small Electron app with a known IPC flow.
03:45	Evidence, limitations, and agent workflow	The output documents what REA cannot prove, and the presenter explains how an agent can use its tools to trace code and cite files and lines.
04:50	Practical constraints and responsible use	The presenter reports limits in the local setup and large-app analysis, gives the project’s lawful-use disclaimer, and points viewers to the repository and website.

Quotes

It is an open-source tool that lets your AI agent take apart an app and tell you how it works with the evidence attached. — 00:01

Nothing on the system changes and it just works. — 02:13

So, the tool tells you what it could not prove. — 03:45

So, on big apps, you will want to narrow the scope — 04:50

you’re responsible for having authorization. — 05:25

Concepts and entities

REA, morluto/rea, MCP, CLI, Electron, Node.js, Ghidra, Hopper, IDA, HAR, IPC

Full transcript (original language)

00:01 All right, in this video we are going to look at REA, which stands for reverse engineer anything. It is an open-source tool that lets your AI agent take apart an app and tell you how it works with the evidence attached. And you can see on the screen that the star chart goes almost straight up in October to around 41,000 stars. Now, mind you, I did not just read the readme. I installed it on my own Windows laptop, ran it on a real electron app, and I will show you exactly what worked and what broke. Let’s go ahead and test this out. So, what is it? REA is one MCP server, and it also works as a normal command line

00:35 tool. You point it at a target, and it returns findings, and every finding comes with the supporting evidence and a list of its own limitations. The targets it supports are native binaries through Hopper, Ghidra, or IDA, JavaScript and electron apps, websites, network captures from HAR files, Android APKs, .NET assemblies, firmware, EVM bytecode, and even recorded process behavior. It is MIT licensed, so you can use it freely. Setup is two commands. The recommended one is NPX REA agent setup. It asks which agents you use. It shows you the changes it wants to make, backs up your

01:08 existing configuration, and then you restart your agent. Cloud Code, Dex Cursor, Gemini CLI are all in the list. If you only want the command line, it is npm install -g REA agents, and then REA –help. That is what I did, and the version I got is 6.2.0. Now, when I ran REA –help, you can see a long list scrolling by. I counted it, and there are about 97 here. There is analyze, decompile, compare, capture web screenshot, capture electron scenario, extract artifact, export web scripts, and a command called doctor that checks

01:42 whether your machine is ready. The one we care about today is analyze JavaScript application, because it works without Ghidra or Hopper or any native engine. Now, here’s the first thing that bit me, and mind you, it is not in the readme front page. REA wants Node 22.19 or newer. My laptop has Node 22.16, so I ran the command and you can see the error on the left, artifact integrity mismatch, directory entry change before open main.js. That message sounds like my file is corrupted, but it is not. It is the Node version. So, what you can do

02:13 is run it through NPX with Node 24, like NPX -p node at 24 -p REA agents REA and then your command. Nothing on the system changes and it just works. For the test, I wrote a tiny Electron app on purpose, so I know the right answer. It has two files. In main.js, ipcMain.handle listens on a channel called save-note and writes the text to a file with fs.writeSync in pre.js. A context bridge exposes one function called save, which sends the

02:44 text over ipcRenderer.invoke to the same channel. That is the whole app. So, the correct answer is one channel, one handler, one sender. Let’s run it. The command is REA analyze JavaScript application, the path to the app folder, and dash dash JSON. It prints a progress line and then about 23 seconds later, you have a result. The output is 441 KB of JSON. Now, if you look at the summary block, you can see browser windows, one, context bridge APIs, one, and under IPC, literal channels, one, main handlers, one, render transmissions, one, paired

03:14 render transmissions, one, and ambiguous ones, zero. So, that matches exactly what I built. It found the save-note channel. It found that the renderer sends to it and the main process handles it and it paired the two. It parsed two JavaScript files and visited 93 syntax nodes and it did all of this without running my app. REA says right in the output that the JavaScript was parsed as inner text and nothing was executed. That matters because you can point it at code you do not trust yet. And this is the part I actually respect. At the

03:45 bottom of the result, there is a limitations list and it is not marketing. It says Electron relationships are derived from inner syntax, runtime registration, and enforcement remain unproven. It says graph coverage is incomplete and unavailable facts must not be read as absence. So, the tool tells you what it could not prove. When an agent writes a report from this, you know which claims are solid and which are guesses. Now, the agent way is where this gets interesting. After setup, you just describe what you want in plain words. For example, find out how search works

04:17 in the notes app, show me the evidence, and then build something similar for my project. The agent calls REA tools, traces the code, and comes back with files and line references instead of a vague summary. The command line I showed is the same engine. You’re just driving it by hand. Now, let me be honest about what did not work for me. I ran REA doctor and it reports healthy faults. Node is flagged, which we already know. Hopper, Ghidra, and IDA are all marked missing analysis engine. So, native binary decompiling is not available on this laptop until I install one of them and set GHIDRA installed there. None of

04:50 the agent registrations were set up either because I only installed the CLI. So, treat my demo as the JavaScript half of REA, not the native half. One more thing, I also pointed it at a real app on this machine, Open Code, which is about 150 MB of electron code. After 8 minutes, the output file was already 577 MB and I stopped it. So, on big apps, you will want to narrow the scope and I will say plainly that I have not yet found the right flags for that. So, that is something to explore from the docs on the CLI page. Last, a disclaimer because it matters. The readme says REA is for

05:25 lawful reverse engineering, research, analysis, and reconstruction and you’re responsible for having authorization. It also says the project has not issued any cryptocurrency or token. So, if you see a token using the REA name, it is not affiliated. Stay with your own apps, apps you have permission for, and open source. So, in this video, we have seen what REA is, how to install it, the node version trap on Windows, and a real run where it found my save-node channel and paired the sender with the handler with limitations stated honestly. If you’re interested, the repo is morluto/rea on

05:59 GitHub and the website is rea.tools. Go ahead and try it on one of your own apps and let me know what it finds. I will see you in another one. Check out the next video.