REA - I tested AI agent reverse engineering - Korben

· Korben's website ·

6 min read Original article ↗

REA , for " Reverse Engineer Anything ", is an MCP server that's been buzzing these past few days. It lets you hook your AI agent (Claude Code, Codex, Cursor...) up to Ghidra, Hopper or IDA, as well as to analyzers for Electron apps, .NET apps or websites.

So you spot a feature you like in an app, the agent picks it apart without the source code, and you code a brand-new version of it... Hmm, that reminds me of something...

Since I wanted to see what it could do, I threw together a quick-and-dirty test bench on my computer with Claude Code running Opus 5.5, REA 6.4.0 as the only MCP server, and Ghidra as the engine.

My tests are split into 4 exercises: a keygen, a patch, an app feature to recreate, and cheat codes. For the first two, I of course compiled homemade programs with a fake licensing system, so as not to wander into illegal territory by coding a real keygen or crack (and get my Anthropic account deleted in the process ^^).

rea doctor validates Ghidra 12.1.4

My crackme is a fake app called "PixelNote Pro" that asks for a username and an activation key, compiled for Apple Silicon Macs.

Once I told it what I wanted to do, the agent opened the binary in Ghidra via REA, read the pseudo-code, cross-checked it against the assembly where the decompiler had written a bit rotation in a barely readable form, and spat out a Python keygen in 2 minutes flat for a Claude API cost of 50 cents. I then ran its generator on 479 randomly picked names, and the binary accepted every single one.

The crackme opened by hand in Ghidra: the entry function and its pseudo-code

The key calculation loop, in the pseudo-code that REA serves to the agent

The patch was the most impressive one, I thought. The little utility I made counts the lines and words of a text file. It's very basic. So I wanted a patch that makes it display the characters too. Since REA, with Ghidra, doesn't touch the executable's bytes, the agent had to do the rest by hand... it tucked its instructions into a zero-filled area of the executable section, redirected three of the original instructions to them, then re-signed the binary so macOS would run it:

The original counter, its version patched by the agent, then the crackme keygen accepted by the binary

For my 3rd exercise, I figured I'd clone the feature of Amphetamine [FR] that keeps my Mac awake as long as a given app is open. Through Ghidra, REA unfortunately refused Amphetamine's universal Intel + ARM binary, so the agent extracted the ARM part itself. It then found that Amphetamine was setting a system power assertion and watching the list of running apps. And, AI magic, it then coded a small Swift tool that does the exact same thing. I tested it with Calculator, and it works, as long as you give it the app's name in the system language, or its identifier.

pmset only shows the wake assertion while Calculator is open

And the last one is Wolfenstein 3D (I used shareware version 1.4), whose DOS executable is compressed. The agent wrote its own decompressor, then found in the code the keyboard shortcut for cheating (M+L+I, which sets health to 100 and gives you ammo, keys, the machine gun... and resets your score to zero), the goobers parameter which, with Left Shift + Alt + Backspace, unlocks the debug keys like god mode, and even a hidden jukebox. Everything matches the source code that id Software has since published.

That said, its logs show it was searching for these codes by name before having seen them. So I got fooled, since the model already knew them. Still, it did find them in the binary.

Start of a shareware 1.4 game in DOSBox, launched with the goobers parameter

The three occurrences of goobers in the decompressed executable

So, is REA essential?

Well, to find out, I reran the four exercises with the same model, the same files and the same instructions, but without REA... just Claude Code driving Ghidra. And bare Claude succeeded at everything too, but by writing its own Ghidra scripts in Java whenever it needed them, where REA served it the pseudo-code and assembly on a silver platter.

In short, what I can tell you from my tests is that REA doesn't do any better than a Claude you ask to install Ghidra and use it. That said, REA was faster on the keygen (2 minutes 22 versus 2 minutes 48 for Claude), on Amphetamine (9 minutes versus 16 for Claude) and on Wolfenstein (10 versus 14 for Claude), but slower on the patch (7.5 minutes versus a bit over 2 for Claude).

It'd be interesting to see what this would give with a local model like Qwen (unlocked with Heretic , come on)...

REA is MIT-licensed and the analysis runs locally (even though its results still get sent to your model provider, so avoid feeding it a confidential binary), and both Hopper and IDA remain commercial tools for which REA provides no license.

Also note that its creator excludes license circumvention and making patches for games, hence, once again, my homemade crackme and the codes that id themselves put in Wolfenstein ^^.

Another precaution to take if you dive in, this time about the reliability of what the AI agent might tell you: researchers published a preprint at the end of May showing that a booby-trapped binary can give its own orders to the AI analyzing it . All it takes is slipping in text strings that have no effect at runtime, which then end up in the decompiled code and whisper fake instructions to the model, making it misinterpret the program. I haven't tested REA against this, but the principle presumably applies to any agent plugged into Ghidra, so be careful before handing a suspicious sample to your favorite AI agent.

And if only Ghidra interests you, know that the MCP I told you about in February also lets you bridge an AI agent <> Ghidra.

There you go, to install REA, a quick:

npx rea-agents setup

And off you go!

This article was originally written in French and automatically translated. Read the original.