awesome-rea

A curated list of AI-assisted reverse engineering: decompilation, static recompilation, native ports, and the agent tooling around them.

Every entry answers the same question: how does this project define "done"? This is not a collection of "AI is impressive" demos. It is a collection of projects that turned correctness into a gate a machine can decide — a byte comparison against the original ROM, a required hash match on the user's own dump, a compatibility matrix, a build that has to stay green.

The list runs on two tracks. Category pages hold projects that state how correctness is decided. Related Practices & Discussions holds practice signals — post-mortems, talk write-ups, arguments — which need no repository and no acceptance test, because a subject is worth recording while it is still an argument. Both tracks are first-class: an item with neither a repo nor a verification clause is a normal discussion entry here, not a rejected project.

The interesting part of an AI-assisted decompilation is never that a model wrote code. It is that someone decided what counts as correct before letting agents iterate, and then built the harness that decides it. That decision is what separates a project that finishes from one that produces plausible-looking source nobody can trust.

So a project with no stated acceptance test does not go on a category page. It goes into Related Practices & Discussions if it makes a public claim, or it waits.

This list has two tracks, and an item only has to satisfy one of them.

1. Public and citable. A reachable repository, project page or substantial write-up. Not a paywall, not a login wall, not a dead link.
2. AI or LLM agents did identifiable work. Not "AI could be used here" — an agent wrote functions, hunted root causes, wrote tests, ran verification, or played a verifier role. Generic reverse engineering with no agent in the loop is out of scope.
3. The acceptance test is stated. One sentence has to make the verification visible: what is compared, against what, and what has to pass.
4. One category per entry, chosen by what the project is, not by which company made it.

Some of the most useful material in this field is not a repository. A post-mortem that admits a headline number was oversold, a conference talk write-up, a thread where people who actually port games argue about whether the speed-ups are real — none of that has a build to point at, and all of it is practice signal. A public repository is not required for this track.

1. A public claim someone made. A thread, article, talk or write-up, readable without an account.
2. It is about the work, not about the excitement. "Here is what we did and where it broke" qualifies. "Look how fast AI is now" does not.
3. No artifact, so no verification clause. That is the point of having a second track: it is where a subject gets recorded while it is still an argument.

An item with no public repository and no stated acceptance test is a normal discussion entry here, not a rejected project.

Explicitly not accepted on either track: vendor announcements, sources that cannot be reached, and anything where "AI-powered" is marketing copy rather than a description of work.

A listing is not an endorsement. This project applies inclusion rules only — publicly citable, AI work identifiable, acceptance test stated. Inclusion says nothing about quality, legality in your jurisdiction, or whether a project will ever finish.

Treat same-day bulk submissions with particular care. Several repositories publishing on the same day, sharing a README template, a scaffold, or a single-commit history, are usually one project family rather than independent work. They count as one submission, and the list counts them once.

This corner of AI-assisted work sits closer to licence law than most, so read this before using anything here.

• Native ports do not include the original assets. Ports listed here are built from source that reimplements game logic; they still require you to own the game, and they ship no ROMs, textures, audio or data.
• Matching decompilation is a clean-room reimplementation. It reconstructs behaviour into new source and does not redistribute the original code. The legal position of publishing such source varies by project and jurisdiction, and is not settled everywhere.
• "Reverse engineer anything" tools carry real EULA and DMCA risk. Where an entry describes a tool used on a commercial product you did not licence for that purpose, that is a factual description of what someone did, not advice that you may.
• This list does not host or index ROMs, game assets, or decompiled asset dumps. Entries point at source that reimplements logic. Archives of extracted game data are out of scope however they are framed, and no entry here links to one.
• Nothing here is legal advice, and a listing is not approval. If you intend to ship something built from an entry on this list, check the licence, the local rules, and the terms you agreed to yourself.

Each entry lives in exactly one category, chosen by what the project is. The README is generated from the category files, so this page is always the current state of the list.

• Game Decompilation — 3 entries
• Static Recompilation & Native Ports — 5 entries
• Tooling & MCP — 3 entries
• Related Practices & Discussions — 17 entries

Use this category for matching decompilation of games: projects that rebuild a retail binary into readable source and check the result against the original. The acceptance test is usually byte-exactness — a rebuilt function has to produce the same machine code as the ROM — so entries here should say which counter runs (functions matched, functions byte-exact) and what gates a function before it counts. What does not belong here: ports that do not claim byte-matching (see Static Recompilation & Native Ports), decompilation of non-game software (see Console & Firmware), and tools rather than projects (see Tooling & MCP).

• 500+ Billion Tokens Later - Decompilation: agents got 99% of a first-person shooter's functions into the reconstructed source with 83% of them byte-exact, gated by a byte-matching verification harness, and the operational finding was that dropping the context compaction threshold from 90% to 42% saved more than any model upgrade.
• sm64ds-decomp - Decompilation: an agent team rebuilds Super Mario 64 DS function by function against the retail cartridge, with progress tracked per function (11,385 of 11,389 matched) and each match gated by independent byte comparison, a source review gate and a relocation destination audit; the same repository ships a PC port kept honest by a smoke build that has to stay green.
• Xenosaga Ep I Decompilation Project - Decompilation: one person reached 3,669 of 7,645 game functions in a little over a week with AI assistance, using matching decompilation as the criterion and an independent byte checker that does not trust the build the agents produce.

Use this category for projects that turn a released binary into a program that runs natively on another platform — static recompilation, or a port built on top of a matching decompilation. These rarely promise byte-exactness; what they promise instead is that the game is playable and does not behave differently. So the acceptance test is what the entry has to name: a comparison against the original ROM, a required hash match on the user's own dump, a compatibility matrix, or frame-time measurements. What does not belong here: projects whose counter is byte-exact function matching (see Game Decompilation), and emulators, which do not reimplement the game at all.

• goldeneye-pc-port - Native port: two coding agents ported a matching decompilation of GoldenEye 007 to PC in 43 days, verified by byte comparison against the original ROM plus a porting-notes log that requires every recurring bug class to be written back before it is considered closed.
• BattleShip - Native port: a Super Smash Bros. port its author describes as 100% AI-generated over 25 days with Opus 4.6/4.7 and GPT 5.5, verified by requiring the user's own ROM dump to match a known hash, and shipping no Nintendo assets at all.
• ssbu-recomp - Static recompilation: Super Smash Bros. Ultimate 13.0.4 rebuilt as a native Windows program with Vulkan rendering, verified by a per-mode compatibility matrix that marks modes "works", "tested with scripted input only" or "not tested", plus frame-time measurements including a whole match at 59-60 fps on an integrated GPU.
• VandalHearts-decomp - Native port: Vandal Hearts rebuilt for PC on top of a byte-exact matching decompilation, so the port inherits the decompilation's byte comparison as its correctness check.
• KartPad - Native port: Mario Kart Wii and Retro Rewind running natively on iOS, iPadOS, macOS, tvOS and Android, verified by requiring a legally obtained PAL RMCP01 revision 0 image and by build, test and device records, and its README discloses substantial AI assistance with no audited percentage of generated code.

Use this category for the tooling an agent actually operates: MCP servers that expose a disassembler or decompiler, verification helpers that independently re-check what an agent produced, and collaboration layers that split work between agents. The entry should say what the tool exposes to the model and, where it applies, what it checks. What does not belong here: the decompilation or port projects themselves (see the two categories above), and general-purpose agent frameworks with no reverse-engineering surface.

• ida-mcp - Tooling: Hex-Rays' official MCP server for IDA; the 500-billion-token decompilation ran on it for almost the whole project and credits it as stable and headless, which is the practical bar for tooling in this loop.
• ida-pro-mcp - Tooling: an MCP server that gives an agent disassembly and decompilation from IDA Pro, the most widely used entry point for agent-driven reversing.
• decomp-compat-kit - Verification tooling: independent byte verification for matching decompilations, so the check runs outside the build the agents just produced.

Use this category for credible public practice signals that describe how AI-assisted reverse engineering is actually being done — post-mortems, methodology write-ups, threads where practitioners disagree, X articles — especially when no standalone project page exists yet, or when the interesting part is the argument rather than the artifact. A public repository is not required here, and neither is an acceptance test. When a subject has no artifact to check, this is where it goes, and that is a normal outcome rather than a polite rejection: a subject is worth recording while it is still being argued about. Entries still need a claim someone made publicly, not a summary of a trend. What does not belong here: projects that belong in a project category, vendor announcements, and any post whose only content is excitement about AI rather than description of work.

• Define correctness as PASS/FAIL, then let agents iterate - X thread: the transferable move is defining correctness as something a machine can decide and then letting agents iterate against it, because wrong decompiled code can look entirely plausible — and the pattern is not specific to games.
• Where "software is solved" is overstated - X breakdown: takes a widely shared claim apart point by point, quoting the core idea that a verifiable outcome can be looped against, and then separating that from the conclusion people draw from it.
• Reverse Engineer Anything, tried on a live game - X test: a Steam game taken apart and running in Unity in about half an hour, which is the clearest reason this list carries a legal section rather than a disclaimer.
• Decompiling a Nintendo 64 Game in 84 Days - Post-mortem: a matching decompilation finished in 84 days against 596 for its predecessor, and the author refuses the tidy version of why — he had nearly two years of prior experience on a similar project, and roughly 4.8% of matching commits still needed a human expert, so attributing the whole gap to LLMs would be a gross oversimplification.
• The Long Tail of LLM-Assisted Decompilation - Post-mortem: matched code climbs from about 25% to 58% quickly and then stalls, forcing the workflow to change, and the extra automation needed guardrails because an unsupervised agent could commit mistakes.
• Using Coding Agents to Decompile Nintendo 64 Games - Methodology: the first post in the series, describing how coding agents were set up to work a matching decompilation before the results were known.
• All games are open source now - X article: frames matching decompilation plus agents as an abundance shift for game preservation.
• Development Journey on Game Decompilation Using AI - Hands-on study: a GAMBIconf talk write-up on using AI to decompile retro games, built around an agent called Kappa that runs inside VS Code Copilot and works one function at a time.
• Claims that genAI speeds up PC ports of classic games are either "false" or missing the point - Discussion: argues the speed-up claims either fail outright or miss where porting actually spends its time, from a community that does the work.
• AI-generated decompilations are garbage - Counterpoint: a decompilation community thread rejecting the AI output as unusable, kept here so the dissent stays attached to the positive entries.
• Why isn't decompilation a solved problem in the AI era? - HN thread: asks why a general AI decompiler still does not exist when source-and-binary pairs are abundant and the compiler is a parameter a model can account for, and what exists to try today.
• How are y'all using ai to make recompilations? - Practice thread: a recompilation community trading notes on where agents actually help in the pipeline, which is the discussion equivalent of an acceptance test.
• Zelda and Banjo Recompiled dev slams the slew of poor-quality "slopcomps" - Discussion: an established recompilation developer names low-quality AI-assisted ports "slopcomps", and the thread argues whether that is gatekeeping or a real quality divide; the word is now the community's term for what this list declines to promote.
• Snowboard Kids 2 is 100% Decompiled - Milestone post: every function is implemented in C and compiles to assembly matching the original game, which is what "100%" means in this field rather than a claim that the port is finished.
• Finding Jingle Town: Debugging an N64 Game without Symbols - Debugging write-up: using a debugger alongside the matched source to explain runtime behaviour once the original symbols are gone, which is the part of a decompilation that byte-matching does not cover.
• decomp.wtf - Withdrawal: a 422-star tool that had an AI agent decompile games you own into compiling C, archived after pushback from the decompilation community, with the code left up under MIT and a request to use it only on games you own and not to share the code it produces - the strongest evidence yet that this community polices the line.
• Awesome Decomp Games - Resource: a rated, auto-refreshed list of decompiled and recompiled games, generated from a data directory rather than hand-edited, which is the same acceptance-visible rule applied to a catalogue.

The categories below are tracked but deliberately empty: they stay off the front page until a qualifying entry exists, so that an empty category never reads as a claim.

• Console & Firmware — tracked, no qualifying entries yet