AI Reverse Engineering Isn’t Magic: What’s Really Happening When Software Gets Cloned

If you’ve caught any tech news in the last few weeks, you’ve probably heard some version of this story: somebody uploaded a program to Grok, Claude or ChatGPT, typed “reverse engineer this and make me a clone,” and a few minutes later out popped a free copy of an app that costs a thousand dollars a year. The end of software. Pack it up, everybody.

That’s not what’s happening. Not even close.

Something real is going on, and it’s genuinely interesting. But it looks a lot more like a forensics lab than a magic trick, held together by tools that predate chatbots and a ton of testing. If you only listen to the media, you’ll think the T-1000 is a lot closer than it actually is.

So let’s talk about what people are really doing, and why it works (and where it falls apart). To be clear: this is an explainer, not a how-to. No commands, no prompts, no recipes and nothing about getting around copy protection. I’m explaining the plumbing, not handing out lockpicks.

Where the buzz is coming from

The hype didn’t come from nowhere. In October 2026, an open-source project called Reverse Engineer Anything (REA) went viral on GitHub. InfoQ describes it as a bridge between AI coding agents and established reverse engineering tools like Ghidra, Hopper and IDA. Notice what that says: the agent drives existing analysis tools. The project also doesn’t claim to recover the original source code.

Around the same time, a small studio published open-source clones of big-name apps like Photoshop and Office. ABC News reported it’s being dubbed “the end of software,” and 404 Media called it the new Wild West of AI.

Here’s what rarely makes the headline. According to Builder.io, the Photoshop clone’s own parity tracker rates it about 45% ready for real work, with an estimated 2,300 to 4,100 more agent-hours to reach full parity. That’s not a prompt. That’s a grind.

Why a compiled binary is a crime scene, not a blueprint

To understand why “just upload it” is a fallacy, you have to understand what a compiler throws away.

Source code is full of meaning. Variables have names like customerBalance, functions have names like calculateShippingCost(), and there are comments, data types, classes and all the little hints a human leaves for the next human.

The compiler doesn’t care about any of that. Its job is to produce machine code that runs fast and small. Along the way:

• Names disappear. Variables become registers and memory offsets. A shipped binary that’s been “stripped” loses its symbol table too, so even function names are gone.
• Types disappear. The processor doesn’t know a “customer record” from a pile of bytes. It just knows sizes and addresses.
• Comments and structure disappear. Neat loops and classes get flattened into jumps and branches.
• The optimizer rearranges the furniture. Small functions get inlined into their callers, loops get unrolled and code gets reordered. It runs great and no longer looks much like what the developer wrote.

Source code is the recipe card; the binary is the cake. You can taste it, weigh it and study it under a microscope, but the card is gone. You can’t un-bake it. Simple as that.

What decompilers actually give you

This is where the old-school tools come in, and they’re the real heavy lifters.

A disassembler translates machine code back into assembly, the human-readable form of the processor’s instructions. A decompiler goes further and lifts that into something that looks like C, with functions, loops and if statements.

The best-known name right now is Ghidra, the framework the NSA released for free at the RSA Conference in March 2019 (yes, that NSA). It’s far from alone. IDA Pro with its Hex-Rays decompiler has been the commercial heavyweight for years, Binary Ninja is a popular modern alternative, and radare2 and its fork Rizin (with the Cutter interface) cover the open-source crowd.

What comes out is useful, but it isn’t the original code. It’s pseudo-C that reads like a crime scene report written by someone who never met the victim. Functions are named FUN_00401a3c. Variables are local_28 and param_2. Instead of order.total you get “the value 0x40 bytes past this address.” Structurally correct-ish, semantically anonymous.

Making sense of that has always been slow, skilled, human work: days or weeks of renaming things and figuring out what each function is for. That’s the bottleneck AI is actually attacking.

Where AI really fits in

Large language models turn out to be very good at one specific part of this job: looking at anonymous, ugly code and making strong educated guesses about what it means. They’ve read an enormous amount of real code, so they recognize the patterns common jobs leave behind.

In practice, the model helps with:

• Renaming. Turning local_28 into something like retryCount based on how it’s used.
• Type recovery. Inferring that a cluster of pointer offsets is really a structure with named fields.
• Summarizing. “This looks like it parses a config file and validates a checksum.”
• Cleanup. Rewriting clunky decompiler output into tidier code a human can follow.

There’s real research behind this. A 2022 USENIX Security paper on DIRTY trained a transformer to predict variable names and types for decompiled code. In 2024, the LLM4Decompile project measured something even better than readability: whether the recovered code still works. Their metric, “re-executability,” asks whether the decompiled function compiles and passes the original’s test cases.

On their benchmark of small C functions, Ghidra’s raw output passed about 20% of the time. When their fine-tuned 6.7 billion parameter model refined Ghidra’s output, that jumped to about 53%, from a model small enough to run on one decent GPU.

One more time for the folks in the back, though: even that result failed roughly half the time, on single, small functions, not a whole application.

You don’t need a frontier lab budget

This cleanup work doesn’t need the biggest model on the planet. Open-weight models, the kind you can download and run yourself, have gotten very capable. Families like Alibaba’s Qwen, DeepSeek, Google’s Gemma, Meta’s Llama and OpenAI’s gpt-oss come in a range of sizes, and the small and mid-size ones, quantized to fit, run on a single consumer GPU with 16 to 24 GB of VRAM or a Mac with plenty of unified memory. The very largest open models still want multi-GPU hardware, but you don’t need those to rename variables.

People often pair those models with an agentic AI harness, software that lets the model use tools and loop on a task. OpenClaw comes up a lot here, and it’s worth being accurate: it isn’t a model. It’s an open-source, self-hosted assistant and agent framework that can drive hosted or local open-weight models. The model does the guessing; the harness keeps it working.

Curious what that hardware costs? See Run Your Own AI at Home for the Price of a Gaming PC, and the AI rent vs. own vs. hybrid TCO model has a free workbook for running the numbers. Want to know what happens inside the model while it “thinks”? Here’s the whole trip a prompt takes.

The limits nobody puts in the headline

Hallucinated meaning. A model that’s guessing will sometimes guess wrong, and it’ll do it confidently. The LLM4Decompile authors noted that a general-purpose code model they tested “could generate code that seemed correct but failed to retain the original program semantics.” Looks right, isn’t right. That’s the most dangerous kind of wrong.

Optimization hurts. The same research showed accuracy dropping sharply on optimized code, which is how almost all commercial software ships. One well-known commercial model went from about 30% correct on unoptimized code to about 11% on optimized code.

Obfuscation. Plenty of software is deliberately scrambled to resist this kind of analysis, and models trained on normal code struggle with code built to mislead.

Scale. A function is not an application. Real products have thousands of interlocking pieces, plus servers, file formats and years of edge cases. One correct function doesn’t mean the whole thing hangs together.

Testing is the actual work. Every credible success story has a judge. The strongest projects check each rebuilt piece against the original, by comparing compiled bytes or behavior on real test cases. REA’s own showcase rebuilt a sound-panning function from the classic game DX-Ball and matched the original across all 3,205 test cases. Builder.io cites a developer who rebuilt 99% of a big-name game’s functions (83% byte for byte) over about five months. Five months! That’s the opposite of “upload and done.”

How a “clone” really comes together

So what does the end result look like? Usually not a copy. It’s a re-implementation.

At a high level, you study the original until you understand what it does: its features, behavior and file formats. Then you write new code that does the same things, often in a different language or structure, and test it against the original until the behavior matches. AI speeds up both halves. The code that comes out is restructured; the features are what get mimicked.

None of this is new, either. In 1984, Phoenix Technologies built an IBM-compatible PC BIOS using clean-room design. One team studied the original’s behavior and wrote a specification; a separate engineer who’d never seen IBM’s code wrote a new implementation from that spec alone. That separation is the point: it shows the new code was written independently, not copied. The tools have changed. The concept hasn’t.

Hype vs. reality

What the hype says	What’s actually happening
Upload a binary to a chatbot and ask for a clone	Decompilers like Ghidra or IDA lift the machine code into rough pseudo-C first
AI recovers the original source code	The original is gone; AI makes educated guesses about names, types and purpose
It takes minutes	Serious projects take weeks or months of iteration
You need a frontier AI lab	Open-weight models on home-lab-class GPUs handle much of the cleanup
The clone is identical	It’s a re-implementation that mimics behavior, verified by extensive testing
Anything can be cloned instantly	Optimization, obfuscation and sheer scale still stop a lot of attempts cold

A quick word on the legal side

I’m not a lawyer, and this isn’t legal advice. But the picture is more nuanced than “it’s all piracy” or “it’s all fine.”

In the US, courts have held that disassembling software can be fair use when it’s the only way to get at functional, unprotected elements, as in Sega v. Accolade (1992). The DMCA’s anti-circumvention rules include a narrow exception in Section 1201(f) for reverse engineering aimed at interoperability. In the EU, Article 6 of the Software Directive allows decompilation only when it’s indispensable for interoperability, and specifically not to build a substantially similar program.

On the other side of the ledger, license agreements matter. In Bowers v. Baystate (2003), a federal appeals court enforced a license term that prohibited reverse engineering. And copying actual code, artwork or text is a different matter from re-implementing behavior. As one lawyer told ABC, it’s “going to get very grey.” Thinking about doing this with someone else’s product? Talk to an actual attorney first.

The bottom line

AI reverse engineering is real, it’s getting better fast, and it’s going to change how software companies think about what they ship.

But it isn’t a chatbot pulling a finished app out of a hat. It’s decades-old disassembly and decompilation, plus models that are good at educated guessing, plus people testing every guess against the original. The AI speeds up the hard middle part. It doesn’t remove the need for skill, time or verification.

So the next time a headline says software is over, ask what tools were used, how long it took and how the result was tested. Don’t take my word for it; read the research. The robots are getting smarter, sure. They’re just not shape-shifting out of liquid metal anytime soon.