AI Reverse Engineering Is Here

For a long time, most people treated compiled software like a sealed box. You could run it, you could poke at it, but the real “how” lived safely in source code that only the author had. Reverse engineering existed, sure, but it was specialist work: expensive tools, slow workflows, deep expertise, and a lot of patience.

That mental model is now outdated.

What’s changed isn’t that binaries suddenly became easy. What’s changed is the economics and accessibility of understanding them. With modern AI coding tools, reverse engineering is increasingly becoming a practical workflow for regular developers—especially when the program you’re looking at is older, resource-heavy, or built on runtimes and formats that preserve lots of structure. The jump isn’t “AI can perfectly decompile everything.” The jump is: AI can accelerate the parts that used to make reverse engineering too time-consuming for most teams.

One story that illustrates this involved someone taking an old executable, handing it to Claude, and asking a pragmatic question: “How do I get this running? Could I modernise it?” Claude inspected the file, inferred key details about the program’s behaviour, and produced a working rewrite in a modern language—then iterated quickly on follow-up tweaks.

It’s worth sitting with that for a moment. Because whether you’re a developer, a business owner, or anyone shipping a client application, the implications are straightforward: if your product relies on “nobody can figure out how it works,” that’s not a strategy anymore.

What actually happened (in plain English)

Under the hood, the flow looks like this:

• There’s an old application distributed as a compiled executable.
• Running it today is painful: missing libraries, old dependencies, compatibility quirks, and trial-and-error setup.
• The executable is provided to Claude with a request to get it running or translate it to a modern stack.
• Claude extracts and recognises “clues” inside the file (names, UI elements, assets, behaviours).
• Claude generates a clean reimplementation (not just fragments) plus instructions.
• The user asks for small modifications, and Claude adjusts the program quickly.

The impressive part isn’t that Claude performed mystical mind-reading. It’s that it combined several real techniques—extraction, inference, reconstruction—and did the time-consuming translation work at machine speed.

Decompile vs infer vs rewrite: the taxonomy that keeps you sane

To avoid getting sucked into hype, it helps to separate three different claims people blur together:

• Decompile: “Turn the binary back into something like source code.” Depending on the language/platform, this can be very close (managed runtimes) or very rough (optimised native code).
• Infer: “Work out what the program does from partial evidence.” Strings, resources, UI layout, configuration, and observed behaviour can tell you a lot even without full decompilation.
• Rewrite (reimplement): “Create a new codebase that behaves the same.” This can be done even if you don’t recover the original implementation details perfectly.

In practice, Claude is often strongest at the infer + rewrite combination. That’s still a big deal. If your goal is “get something modern and working,” you don’t always need perfect historical source recovery. You need a faithful functional replacement plus a testable surface.

The uncomfortable nuance: not all “binaries” are equally opaque

Here’s the part most hype posts skip: some executables are inherently more reversible than others.

Many formats preserve structure such as:

• recognisable UI/control names (buttons, timers, forms, menus),
• embedded resources (images, sounds, dialog layouts),
• metadata that hints at program flow,
• bytecode or intermediate representations rather than raw machine code.

When you hear a story like “Claude turned an old EXE into working modern code,” you should ask: what kind of EXE was it?

• Managed/.NET/Java: Often decompiles surprisingly well. You can get something close to source-level structure.
• Older toolchains with interpretable forms (for example p-code style formats): Often contain more clues than people expect.
• Native, optimised, stripped C/C++/Rust: Much harder. You can still learn a lot, but “original code with original comments” is usually not realistic.

So the realistic takeaway is: AI makes reverse engineering cheaper, and in some ecosystems it makes it shockingly accessible. But the hardest cases are still hard.

What Claude is really doing in these workflows

In most of these cases, Claude isn’t doing one magic step. It’s combining multiple steps that look like a “pipeline”:

1. Extraction
   Pulling out strings, embedded resources, and any available identifiers. Even simple string extraction can reveal UI labels, file paths, error messages, or hidden feature toggles.
2. Structural inference
   Building a mental model: what screens exist, what actions exist, what inputs cause what outputs, what the program’s “shape” looks like.
3. API/protocol inference (when relevant)
   If the program talks to a server, it’s often possible to infer endpoints, payload shapes, retry logic, authentication patterns, and error handling.
4. Reimplementation
   Generating a new codebase in a modern language/framework with clearer structure and instructions.
5. Iterative refinement
   The real multiplier. Instead of spending days in a disassembler, you can describe the behaviour you want and tighten it in minutes.

The reason this matters is that reverse engineering traditionally has a “last mile” problem: even if you understand 70–80% of the program, producing maintainable software from that knowledge is slow. Claude compresses the last mile.

Why this matters for businesses (not just hobbyists)

If you run a software business—or even if software is just part of your operations—this changes the risk landscape. You should assume that motivated parties, now assisted by AI copilots, can recover a lot more than you expect from shipped applications.

• Assume client-side logic can be understood. If your business value depends on “nobody can figure out our client,” that’s a fragile moat.
• Assume protocols can be replicated. If your backend accepts requests from “the official app,” assume an unofficial one can be built.
• Assume embedded secrets will be found. Hardcoded API keys, tokens, “hidden admin” routes, and licensing logic become easier to locate and reason about.

And the opportunity side is real too:

• Legacy recovery becomes practical. Old internal tools with lost source code can sometimes be modernised instead of rewritten from scratch.
• Documentation can be reconstructed. Even if you don’t rewrite the app, extracting flows and generating diagrams/tests can reduce operational risk.
• Migration planning improves. Understanding what an old system does is half the battle of replacing it.

A simple rule: if it runs, it can be studied

Reverse engineering isn’t new. What’s new is that the cost to “get started” has collapsed. Instead of a specialist spending days just to get oriented, a developer can often get a useful explanation and a plausible rewrite quickly, then verify it experimentally.

That shifts the strategic posture for shipping software:

Design as if your client will be inspected—because it will be.

Practical mitigations that actually help

If you only take one thing from this article, take this: do not rely on obscurity for security. If the client can be studied, your job is to make sure studying it doesn’t unlock your business.

• Move secrets server-side. Never ship long-lived private keys inside apps. If a key must exist, make it short-lived and scoped.
• Treat the client as untrusted. All important checks must happen server-side: permissions, entitlements, pricing, limits, and business rules.
• Use short-lived credentials. Prefer expiring tokens; rotate them; bind them to device/app instances where appropriate.
• Harden your APIs. Rate limit, detect anomalies, log suspicious patterns, and apply abuse controls. This matters even for “private” APIs.
• Protect IP with business design, not magic client code. Your moat should be service quality, data, distribution, brand, and execution—things that don’t vanish when someone understands your protocol.

In an Australian context, this also overlaps with governance and risk. If you’re handling customer data, assume that attackers can inspect client apps and attempt to misuse APIs. That should shape your controls, audit logs, and incident response posture.

The ethical line: modernisation vs cloning

There’s a real ethical split here.

• Reviving your own old software, preserving abandoned tools, or recovering lost internal utilities can be constructive.
• Recreating proprietary software you don’t own and shipping it as a substitute is where you collide with legal and ethical boundaries.

AI doesn’t remove responsibility. It just makes capability more common.

Where this goes next

The near future looks like reverse engineering becoming conversational: “What does this function do?” “Where is the licensing check?” “Describe the network protocol.” Toolchains will increasingly bundle static analysis, runtime tracing, and AI into a single loop.

AI reverse engineering is here. The right response isn’t panic, and it isn’t denial. It’s updating how we think about software distribution: the binary is no longer a black box—it’s a clue-rich artifact that can be studied, explained, and increasingly, rewritten.

Ready to harden your software against real-world threats? Get in touch with us to review your API security, secret management, and client-trust assumptions. We’ll help you design systems that stay resilient even when the code gets inspected.