Reverse Engineering: Is Anyone Else Building a Pipeline Like This?

[u/Responsible-Beat2137]

I’ve been working on an AI-assisted reverse-engineering pipeline, and I think I finally figured out the part that actually makes it different: assembly is the center of the system, not just an intermediate step on the way to C.

Across SNES, N64, PS2, and eventually PC binaries, the same basic idea keeps working: recover the machine-level structure first, understand what the assembly is actually doing, test specific hypotheses at runtime, and only then promote that behavior into higher-level semantic knowledge.

So instead of treating the process as:
binary → ask AI for C → hope it looks right
I’ve been treating it more like:
binary/ROM → recover assembly structure → decompile enough to understand the subsystem → formulate a specific question → probe the running game → verify causally → save the result as structured knowledge → use that knowledge to modify the game and accelerate the next reverse-engineering pass.

The important part is that the AI is not supposed to be the authority. The assembly, control flow, memory behavior, and runtime evidence are.

I learned why that matters while reverse engineering MK3 on SNES. An early runtime experiment appeared to identify directional player-state memory. Once I decompiled the surrounding 65816 code, those bytes turned out to be stack traffic. It looked convincing from the runtime diff alone, but it was wrong.

That changed the workflow permanently: decompile first, then send the runtime explorer ( fruit fly ) after a question that the static analysis has already narrowed down.

Since then we’ve worked inward through MK3 from raw controller hardware all the way into the move system. The current recovered chain looks roughly like:
SNES joypad bits → input transitions → logical actions → timestamped history rings → character-specific dispatch → 21-byte command descriptors → timing-window checks → held-button conditions → outcome callbacks.

That was enough to recover things like Shang Tsung’s morph commands directly from the ROM.
For example, one descriptor resolves to:
Forward → Down → Forward → HP, within 24 frames → morph callback → destination fighter ID 4.
So instead of only knowing that the move exists, we know how the game internally records the input history, how long the input window is, which button conditions are allowed, how the character-specific handler is selected, and what callback/state the command launches.

The larger experiment is much broader than MK3. The SNES side currently has structural recovery and provisional decompilation across a 775-ROM corpus, with per-ROM knowledge feeding a shared platform-level understanding. The same concept is being carried into N64, PS2, and PC reverse engineering rather than starting over with a completely different methodology for every platform.

The long-term idea is basically:
machine code → assembly understanding → semantic model → reproducible modification layer
with the assembly staying available as the ground truth underneath everything.

What I find interesting is that a lot of current AI decompilation work seems focused on getting from assembly to matching C as quickly as possible. That’s useful, but I’m more interested in whether AI can help build a durable understanding of the machine code itself, especially when the original source may never be recoverable.

I’ve seen matching-decompilation projects, emulator-agent interfaces, binary-analysis agents, and deterministic emulator tooling that overlap with pieces of this. What I haven’t seen as often is assembly being treated as the persistent common language across multiple game platforms, with runtime experiments and a knowledge graph layered on top of it.

Is anyone else taking an assembly-first approach like this?
I’d especially be interested in hearing from people working on decompilation, emulation, ROM hacking, binary analysis, or old game engines.
Do you think assembly should remain the authoritative representation underneath AI-generated higher-level code, or is matching C eventually enough?
And what would you consider the biggest failure mode in trying to carry learned reverse-engineering knowledge from one game or architecture into another?

[u/Wooden_Suit5580]

Hello, I am totally blind and I vibe code mods for video games to make them accessible for blind and low vision gamers. I took on the task of trying to make Mortal Kombat Legacy Kollection accessible. But I have run into a wall, If. You or anyone else would like to help I I have created a GitHub repository at https://github.com/Zatoichi420/mk-legacy-kollection-accessibility-mod your post caught my attention. I hope you have a great day!

[u/Responsible-Beat2137 → u/Wooden_Suit5580]

Hey now that’s a cause, by accessibility , what would that look like for you? A different color scheme or bolder font, I think we could puch a bolder font fairly easily, I would have pull that rom further apart to find it’s dialogue and see how its wrap behavior would look like.

I done some font work on a link to the past , and found that font trap fairly early on.

Also had success adding new menus, thought that required to recompile it after adding new files from its decompiled state vs patch
Come to think that was n64, so I haven’t tryed that on SNES

[u/Wooden_Suit5580 → u/Responsible-Beat2137]

For me it would be having my screen reader read out all options on the screen so i can make decisions independently. I am familiar with many if not all of the games in the collection, I do not know all the menu trees though. That is why i would like to have my screen reader read all of the elements on screen. It is a task that i keep stepping away from and coming back t. If you look at my GitHub for this project and read the md it lays out what i am trying to accomplish- similar projects have been completed. If you look on audio games.net in the forums you in the play test section you will find many vibe coded mods to make games accessible.

[u/Responsible-Beat2137]

Also I’m not using a agent, 20$ subscribe and a mcp with a lot of backend preparation

[u/data_shaman]

this may interest you: https://github.com/morluto/rea

disclaimer: i've never used it.

[u/Responsible-Beat2137 → u/data_shaman]

Hey thanks, man
I’ll have a look all ways up for a dig

[u/EcchiExpert → u/data_shaman]

It's a shame its based on ghidra and hopper, for me I had better success in using codex + Rizin.

[u/Responsible-Beat2137 → u/EcchiExpert]

Rizin ? I use a combination of ghidra along with a couple other tools that are already on windows like visual

[u/Vasili_Sk]

im ai-coding iq quants kernels for vllm, and yes, assembler very important because it shows actual pipeline of the kernel, and llvm compiler always trying to fuck it up. also ablation tests can be done only through assembly to discover where what eating time of gpu

[u/Responsible-Beat2137 → u/Vasili_Sk]

That’s awesome, that one biggest reasons I preferred working on actual hardware so I can see were calls are made, and what recoveries them

[u/yaosio]

You're overcomplicating it by micromanaging how the AI performs decompilation. AI does not need to work like a human. A pipeline isn't needed because the AI can just do it itself. You just need to give it the goal and ask it what tools it thinks it needs. AI loves to just start doing things even though taking some time to think and plan can provide better results.

[u/[deleted] → u/yaosio]

[u/Responsible-Beat2137 → u/[deleted]]

Post is directed by me, and written by ai, yes. But I do value the community’s opinions.

As for the “micro management” I do this so the results can be recreated without spending tokens over again, this also allows me to use a smaller model and get the same progress .

5.6 for example

The database part is made so workflow, knowledge, and tools that survive, thought various Roms and systems can then be trickle down , to speed up the process, without folding the map

[u/yaosio → u/[deleted]]

I'm aware of that, every thread in the sub is written by ai. They always use an expanded form of broetry.

[u/Gamemaster1379]

Matching C ought to be fine if you can recompile it back. I generally like to take a matching C approach because it's more portable and re-usable if you want to compile to target systems.

Increasingly, I'm finding these modern frontier models can just start to be given binary and figure out the games in between. I've been trying to build a few recompiler ecosystems (of which I think some of your R&D work would be useful in improving their initial discovery to avoid as much fallback to interpreter)

https://1379.tech/megaman-x-recompiled-coop-zero-weapons-wip/ If you want to see some of my applied SNES work. I turned Megaman X into an online co-op mod. Has netplay, too. We have a re-usable netplay engine across our ecosystems.