Stackness
All moves

Using coding agents to reverse engineer unfamiliar software and hardware

by Stackness

AI Tools

Instead of using coding agents only to write new code, developers are pointing them at unfamiliar compiled software, games, or hardware control units to inspect, explain, and reverse engineer how they work. Dedicated skill sets and MCP tools now package reconnaissance, disassembly, and in-system testing so the agent can both understand and then modify the target, whether that is modding a PC game, explaining a calculator binary, or writing assembly to emulate an engine control unit.

What it is

This move treats a coding agent as a reverse engineering partner rather than just a code generator. You point the agent at a compiled binary, a game, or a piece of embedded hardware firmware and ask it to inspect, explain, and eventually modify the target. Tooling built specifically for this purpose packages up reconnaissance, disassembly, decompiled code, and call tracing so the agent can reason about unfamiliar systems the same way a human reverse engineer would, then act on that understanding.

How to do it

  • Install a dedicated toolset for the target type. For PC games, a plugin can add skills and MCP tools covering recon, reverse engineering, asset generation, and in-game testing. For general binaries, an agent setup command can wire up disassembly and decompiled-code access for a running program.
  • Ask the agent a plain-language question about observed behavior, such as why a calculator produces a specific result for an operation.
  • Let the agent inspect instructions, trace function calls, and identify the relevant branch or handler before explaining the underlying rule in plain terms.
  • Once the agent can explain the mechanism, ask it to rebuild or modify it, for example adjusting a game's acceleration rule or patching a control unit's logic.
  • For hardware with slow physical test cycles, have the agent write a software emulator of the target chip so patches can be validated without constant flashing and field testing.

When it helps

This works well when documentation is thin or nonexistent, such as decades-old engine control units, closed game binaries, or system utilities where only the compiled artifact is available. It is also useful when the test loop is expensive, since an emulator written by the agent can shortcut physical reflashing and driving cycles.

Pitfalls

The agent's explanations and rebuilt logic are only as good as its ability to correctly trace branches and calls, so verify its conclusions against real behavior rather than trusting them outright. Emulators or patches generated this way still need real-world validation before being relied upon, especially on physical hardware.

Sources

Tools

Claude Code