REA hits #1 on GitHub trending; hands-on test finds plain AI agents reverse-engineer .NET faster

A 183,000-star repo for taking binaries apart

A repository called REA, short for "Reverse Engineer Anything," climbed to the top of GitHub's weekly trending page after gathering roughly 183,000 stars in a single week, according to a hands-on write-up on dev.to. The claim driving the attention: connect it to an AI coding agent and it can dissect applications whose source it has never seen, including turning raw machine code back into readable code.

A developer publishing on dev.to put that claim through a controlled test, and the result is more layered than the hype suggests.

What REA actually is

Despite the name, REA does not decompile anything itself. As the dev.to author points out — a correction the project's README downplays — the tool is a coordinator. When an agent asks a question about a program, REA runs established analysis tools against the binary and returns findings with evidence attached.

For .NET assemblies it ships its own static reader for metadata and CIL bytecode, so the target never has to be executed. For native machine code it drives conventional decompilers such as Ghidra, Hopper or IDA. The AI then reads the resulting pseudocode — typically a wall of machine-generated placeholder names — infers what each routine does, and rewrites it as clean source.

One app, three builds

The test subject was a roughly 105-line C# program that turns a 24-bit BMP into dithered ASCII art using Floyd–Steinberg error diffusion, with a deliberately fake upload API key baked into the binary — a stand-in for the secrets real applications ship. The author compiled it three ways, with debug artifacts stripped to avoid leaking machine paths, and pointed REA at each build.

On the ordinary .NET build, REA's reader produced 114 KB of JSON in about a second and a half: every method, signature and string literal, key included. An AI given only that JSON rebuilt the full application in 85 seconds, and the recompiled reconstruction produced output whose SHA-256 hash matched the original exactly.

On a build obfuscated with Obfuscar, where class and method names became invisible Unicode characters and strings were encrypted, the AI still rebuilt the algorithm from bytecode in around three minutes and derived the encryption scheme on paper: each byte XORed with its position and a fixed constant, which the author independently verified. It could only guess encrypted strings by their length, mispredicting one command-line flag. More damning for the obfuscator, the API key sat in plain text in the assembly metadata, untouched by the renaming.

On the Native AOT build — a 1.1 MB pure x64 executable with no bytecode at all — Ghidra identified 3,627 functions, nearly all of them .NET runtime code. Guided by REA's output alone, the AI traced string references to the relevant functions and rebuilt the entire application in roughly 18 minutes, again with matching output hashes.

The control the hype skips

The sharpest finding came from running the same agent without REA. On the plain build it located ILSpy, a free decompiler, and produced real C# in 41 seconds. The obfuscated build took 56 seconds, with two lines of Python decrypting every string, key included. The native executable fell in under four minutes: the agent wrote its own disassembly scripts and recovered the constants, the key and even the original class names, which .NET leaves inside native binaries for stack traces. In every scenario the unaided agent finished faster than the one using REA.

One caveat deserves attention: the standalone agent also executed the unknown executable to observe its behaviour — acceptable on the author's own program, but a worrying default for analysing third-party binaries.

The author's verdict: REA is real and careful, static for .NET, evidence-based and genuinely effective on machine code, but at this application size the model was doing the reverse engineering either way. The case left untested, and where the tool likely justifies its stars, is large native applications.

Why it matters

For anyone shipping .NET software the lesson is blunt: neither obfuscation nor Native AOT protects embedded secrets. A test key was recovered in every configuration, sometimes within a minute, by a standard agent using ordinary tools. Anything that must stay private does not belong compiled into the binary.

For the AI tooling ecosystem, the runaway star count reflects appetite for this capability more than a unique technical edge: a generic agent already matches or beats the dedicated toolkit on small targets. And an autonomous agent that opts to run an unfamiliar executable highlights a governance question that will grow alongside these tools.