What people reverse engineer with AI
Updated 11 November 2026 · 106 projects
Projects in this directory used AI for a handful of recurring jobs. This page groups them by the job, with one real result for each and the figures the authors report.
Each project goes into the first job whose rule it matches, read from its target type, title and summary. Entries that lift a vendor's limits are left off. Outcomes are as reported by each project's author.
In short
- 91 of 106 listed projects fall into one of 7 jobs. Native ports of old games is the largest group with 52. 15 fit none of them, such as mods, editors and engines built around one game.
- 40% of the grouped projects are reported as working by their authors (36 of 91). Partial and research results make up the rest.
- Device protocols (Bluetooth, USB, network) has the highest share reported as working (100%). Decompilation has the lowest among groups of five or more (14%).
- Many entries describe how the result was checked: against the original game, on a real device or on real files.
The jobs at a glance
Result rows are the entry with a cover image and a working outcome where one exists, so they show what the job looks like at its best.
Run an old game natively on new hardware
20 of 52 are reported as working. Static recompilation translates a game's machine code into C or Rust so it runs natively, which gives a model a checkable, repetitive job: translate, build, compare. The write-ups also set limits. Most need the reader's own copy of the game or disc image and ship no game assets, and several are labelled beta or in progress.
Works 20Partial 29Research 3
Rebuild a game's source
3 of 22 are reported as working. Some entries aim for byte-identical output checked by a build, with owner-approved compiler profiles. Others only recover readable C or C#, and one checks that the rebuilt C# compiles to the same IL as the original. Matching work is repetitive and checkable, which suits a model; plenty of entries are still marked as started or in progress.
Works 3Partial 18Research 1
Control a device without its app
7 of 7 are reported as working, and 3 of them report a test on the real device. A model reads packet captures, app code and logs quickly. The physical work stays with the person: several authors describe removing a dongle, wiring a microcontroller to a bus or finding the signal pair with a multimeter.
Works 7
Keep old hardware working
2 of 4 are reported as working, and 3 report a test on real hardware. Firmware work is where the write-ups are most careful about limits: one says outright not to flash its result onto a physical inverter because it was only tested in an emulator, and another notes that the headset microphone still does not work.
Works 2Partial 1Research 1
Read a file format nobody documented
2 of 2 are reported as working. A format is a closed problem: a model can write a parser, run it on real files and see whether they come out the same. Entries also say what is left open, such as fields that are read-only or not yet understood, and several are save editors for a single game.
Works 2
Talk to an undocumented API
2 of 2 are reported as working, and 2 publish their code. The entries picked here are interoperability work: clients for a user's own smart-home account, local replacements for a cloud service, or libraries that read documented behaviour from a game's data. Entries about removing a vendor's limits are left off this page. Protocols that change without notice can break a client later.
Works 2
Analyse malware safely
Only 0 of 2 are reported as working and 2 as research, because most are experiments in analysis, not finished tools. The write-ups are open about errors: one found wrong indicators of compromise and file relationships even after verification passes, and another found a generated script that printed a made-up URL instead of extracting one. The author of that comparison concludes that verdicts still need an experienced analyst. This directory lists defensive analysis only.
Research 2




















