REA Crosses 400k Stars — Agents Decompile Windows Binaries Through MCP and Ghidra

#reverseengineering #windows #mcp #ai

REA (Reverse Engineer Anything) crossed roughly 400k GitHub stars this week and keeps shipping MCP tools that let coding agents talk to Ghidra, Hopper, and IDA. The Windows Ghidra provider is still marked experimental, yet the architecture is already useful for anyone shipping native Windows tools that touch the audio stack.

The practical problem is the same one that hits every overlay or real-time capture app: the interesting logic lives inside closed binaries. WASAPI loopback, AudioSessionManager, or a third-party virtual cable driver rarely ships with source. When latency budgets tighten or an endpoint disappears after a Windows update, you either guess or you open the binary.

What REA actually exposes

REA is an MIT-licensed CLI + MCP server. You point an agent (Claude Code, Cursor, Codex, etc.) at a PE, an Electron app, a .NET assembly, or a live HAR capture. For native code it shells out to a configured Ghidra, Hopper, or IDA installation and returns:

decompiled pseudocode
raw disassembly with addresses
xrefs, callers, callees
strings, symbols, and an evidence ledger

The ledger is the useful part. Every claim comes with an address, a digest, or an explicit “unknown.” That stops the agent from hallucinating a call graph.

On Windows the Ghidra path is experimental. Recent reports show it passing rea doctor --provider ghidra on Windows 11 26H2 with Ghidra 12.1.x, and people have already used it on small PE samples. Deep analysis still works better on Linux/macOS hosts today; the Windows adapter is catching up.

Tracing a Windows audio capture path

Suppose you need to understand how a closed-source overlay grabs system audio without a virtual cable. Typical surface:

CoCreateInstance for IMMDeviceEnumerator
GetDefaultAudioEndpoint(eRender, eConsole)
Activate → IAudioClient
Initialize with AUDCLNT_STREAMFLAGS_LOOPBACK
GetService for IAudioCaptureClient
packet loop on GetNextPacketSize / GetBuffer / ReleaseBuffer

Those calls leave clear footprints. An agent + REA can ask Ghidra for xrefs to AUDCLNT_STREAMFLAGS_LOOPBACK or the GUID of IAudioCaptureClient, then walk the surrounding functions. You get the buffer size, the share mode, and whether they pin a specific format or renegotiate.

A minimal capture skeleton (the part you usually write yourself) looks like this:

// WASAPI loopback sketch — not production
IMMDeviceEnumerator* enumerator = nullptr;
CoCreateInstance(__uuidof(MMDeviceEnumerator), nullptr, CLSCTX_ALL,
                 __uuidof(IMMDeviceEnumerator), (void**)&enumerator);

IMMDevice* device = nullptr;
enumerator->GetDefaultAudioEndpoint(eRender, eConsole, &device);

IAudioClient* client = nullptr;
device->Activate(__uuidof(IAudioClient), CLSCTX_ALL, nullptr, (void**)&client);

WAVEFORMATEX* format = nullptr;
client->GetMixFormat(&format);

REFERENCE_TIME hns = 10000000; // 1s buffer
client->Initialize(AUDCLNT_SHAREMODE_SHARED,
                   AUDCLNT_STREAMFLAGS_LOOPBACK,
                   hns, 0, format, nullptr);

IAudioCaptureClient* capture = nullptr;
client->GetService(__uuidof(IAudioCaptureClient), (void**)&capture);
client->Start();

// then the packet loop...

When the binary does something non-obvious (resampling on a private thread, dropping packets under load, or mixing multiple sessions), the decompile plus the evidence addresses lets you confirm it instead of guessing from Process Monitor.

Latency budget that actually matters

Real-time STT or translation overlays live or die on the capture-to-final budget. Recent public numbers put good streaming models in the 45–100 ms time-to-final range once audio is already in the recognizer. Everything before that is your problem:

WASAPI period and buffer size (often 10–20 ms packets if you ask for it)
thread priority and affinity of the capture callback
any intermediate queue that can grow under GC or lock contention
format conversion if you force 16 kHz mono while the endpoint is 48 kHz float

A 100 ms capture buffer already eats the entire model budget. Agents that can quickly show you the Initialize parameters and the exact GetBuffer timing in the binary save hours of trial-and-error. You still have to measure end-to-end with a loopback test tone; the disassembly just tells you where to look.

Tradeoffs of the agent + RE workflow

Evidence vs vibes. The ledger is the reason this is usable. Without addresses you are back to prompting a model that has never seen the binary.
Setup cost. You still need a working Ghidra (or Hopper/IDA). The MCP layer does not replace the analysis engine; it orchestrates it.
Windows maturity. Experimental means edge cases in PE loading, symbol servers, and process isolation. Run it on a dedicated analysis VM.
Speed. Headless Ghidra on a medium binary is still slower than a quick strings + Procmon pass for the first five minutes. Use the agent when the call graph is the bottleneck.
Local models. Pairing REA with a local coding model keeps the entire session off the network. Useful when the binary itself is sensitive or when you are iterating on capture code that talks to cloud STT only as a last resort.

Automation that survives the next Windows update

Once you have the addresses, turn them into a small regression harness:

# dump the relevant symbols / xrefs after each Windows update
rea analyze .\overlay.exe --provider ghidra --query "xrefs AUDCLNT_STREAMFLAGS_LOOPBACK" --json > loopback.json
# then diff against the previous snapshot

The same pattern works for any closed audio component: Bluetooth stack quirks, USB audio class drivers, or the private mixing logic inside a conferencing app. You are not trying to ship a full decompiler; you are trying to keep the capture path you depend on from silently changing under you.

For anyone building real-time language tools on Windows—overlays that have to stay out of the way, local STT to cut round-trips, or tight integration with the system audio engine—the combination of MCP-exposed reverse engineering and ordinary measurement still beats pure black-box debugging. The binary does not lie; it just needs a fast way to ask it questions.

I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.

DEV Community