REA Took Apart a Game and a Learning App. One Ran. One Stopped Cold.

In October 2026, the open-source project REA moved quickly through technical communities. Its full name is Reverse Engineer Anything. The loudest line around it was “reverse engineer everything, software is dead.” AI commentator Matthew Berman posted that line, and social platforms soon filled with reverse-engineering demos.

One developer was tired of paying more for the voice-input tool Typeless. They used REA plus Claude, spent 25 minutes, and rebuilt a local version on a Mac with no login and no subscription. Another user turned an air-conditioner app into a Mac menu-bar remote. One click switched the unit on or off and changed the temperature. Another user turned a smart-toilet WeChat Mini Program into a desktop remote. One click at a workstation lifted the toilet lid in the next room.

REA’s GitHub page followed the same curve. The repository had been public for more than half a year with little attention. In early October, its star count jumped from tens of thousands to more than 200,000 in a few days.

These cases show reach. They do not show tool capability. The tests below cover two subjects: the single-player Android game Naruto Senki and a learning app. They ask three questions. Can REA help an AI read proprietary resources and native libraries? Where does model safety policy cut the process? Can the result survive a runtime check?

What REA is

Reverse engineering means working without source code. You hold a compiled program and infer how it works. A cook tastes a dish without a recipe and reconstructs the ingredients. A reverse engineer opens an app without source and reconstructs its logic.

The field already has mature tools. Ghidra and IDA analyze native programs. JADX unpacks Android installation packages. These tools are powerful and hard to use. Their main users are security researchers and hackers. An ordinary developer who opens a decompiler often faces a wall of machine code and no clear next step.

REA packages these tools behind one interface and connects them to AI coding assistants such as Cursor, Codex, and Claude Code. Before REA, handing decompiled machine code to an AI usually failed. The model could not read it and did not know which tool to call. With REA, the model chooses tools, receives numbered evidence, and asks follow-up questions where the evidence is thin. The reverse-engineering process becomes a workflow the model can run.

Installation is light:

bash

npx rea-agents setup

Or ask the AI to install it:

text

Install github.com/morluto/rea for me

One point needs to be clear first. REA is a tool layer, not a large model. It did not invent a new reverse-engineering algorithm. Its base is Ghidra, IDA, JADX, and similar tools. Its work sits in integration and interface design: tool choice, evidence reading, and follow-up questions become automatic.

Test one: adding a character to a single-player game

The first subject was Naruto Senki, an Android game that had not been updated for years. The roster had stayed fixed for a long time. The test goal was to add one character.

Without source code, a game edit requires decompilation, resource-format knowledge, and pixel art. The test used an AI model plus REA.

The first round used Cursor with Claude Opus 5.5. The game package went to the model with instructions to follow the REA workflow. The model said it had added the character. The modified package froze on launch. A model’s self-report cannot replace a runtime check.

The setup then switched to Codex with GPT-6 Astra. The process moved with fewer dead ends. Codex did not start at once. It asked whether the new character had a specific identity. The choice was Might Guy, the ninja in green who opens the Eight Inner Gates.

Codex called REA to unpack the package. It mapped the engine and three proprietary resource formats. The game used a native library written with cocos2d-x. Character scripts were gzip files with modified headers. Textures were atlas files with modified headers. The animation index stored frame-name hashes and crop data.

The step that mattered was character registration. Dropping Might Guy’s assets into the game would not put him on the select screen. The roster is hard-coded in the native library. REA separated the proprietary formats and the native library, then organized them into evidence the model could read. Only then could the model see how characters register and render. Raw machine code gives a model no starting point.

Stats and skills stayed simple. Might Guy and Rock Lee both use taijutsu. Codex used Rock Lee’s stats as a baseline and reused existing attack and movement instructions for skills. That choice reduced the risk of breaking combat rules. A sub-agent drew the pixel sprite, including running, punching, kicking, and Eight Inner Gates effects.

After assets and stats were ready, Codex checked the result in a standalone Android emulator. The select screen showed Might Guy. He entered the match and stood correctly. Health, coins, and skill icons displayed. A match started, and skill casts ran. Stat balance, sound, and art style still had rough edges, but the game played.

This test gives two findings. REA helped at the layer that matters: it turned proprietary resource formats and native libraries into evidence an AI could read. Without that layer, the model would struggle to find registration and rendering logic in machine code. The first round also showed that validation cannot be skipped. The model claimed success while the package froze.

Test two: a learning app, a safety stop, and a Flutter skeleton

The second subject was a learning app. The first round again used Cursor with Claude Opus 5.5. The model triggered a safety filter at the start. The conversation switched to Claude Opus 4.8. The model would only run static analysis. It refused to decompile the full source. Its stated reason was that, whether framed as “learning” or “anti-fraud,” restoring the app’s code meant rebuilding the pipeline that delivers its content. The act crossed a line.

That detail matters. AI reverse engineering has limits. Model safety policy applies to specific targets, especially full source restoration and content-distribution pipelines. Tool capability, model policy, and target type decide the result together.

Static analysis still produced useful facts. The app used Flutter. Its business logic was compiled into libapp.so. It had a 360 hardening shell, but the shell protected Java-layer code and left the Flutter side open. The app still used a 2017 crypto library that should have been replaced years earlier. The analysis also mapped the app’s money model.

This type of app is bait and switch. Learning is the cover. The business is harvesting users. Three tactics appeared.

1. The app used three virtual currencies. Real money became coins, coins became points, and the layers hid the total spend.

2. Daily check-ins gave random coins. Referrals gave rebates. The first tactic used slot-machine mechanics. The second pulled friends and relatives into a distribution chain.

3. Customer service and refunds routed to off-platform chat apps. If the app was banned, the operator could relist under a new name. The user had no evidence.

That is enough reason to avoid such apps for study.

The setup then switched to DeepSeek Harness with a DeepSeek model. The work moved to the engineering skeleton. The app was written with Flutter 3.27. UI, logic, and lower-level capabilities sat in separate layers. A reskin only needed the top layer. The app did not use the system video player. It bundled Bilibili’s open-source IJKPlayer. The reason was compatibility. Phone vendors decide which formats the system player supports. The same video can play on one phone and fail on another. A bundled player gives the app control over decoding.

Night mode had its own set of 128 color assets. The product accepted several extra megabytes to keep the night view readable. The choice fits a product whose users study in bed at night.

In a further test, the app became an AI programming learning app. Several sub-agents worked in parallel. The output was a technical explainer and a runnable learning app. The local build opened on a course map with seven modules, from Python basics to Agent practice. The first lesson had explanations, copy-and-run code, and quizzes. The content was original AI programming material.

Reverse engineering this app also produced a lesson for client developers. Many developers assume Flutter code becomes unreadable once compiled. They hard-code keys and endpoint addresses. The hardening shell covers the Java layer. The Flutter side stays open. That is a security illusion. Keys and central logic should not sit in the client when the backend can hold them.

Where REA helps and where it costs

The two tests give five findings.

REA’s integration value is larger than its technical novelty. It turns Ghidra, IDA, and JADX into AI-callable tools. It automates tool choice, evidence reading, and follow-up questions. For people outside the reverse-engineering toolchain, that lowers the barrier.

REA helps an AI advance concrete work. In the game test, the model could locate character registration and rendering only after REA organized proprietary formats and native libraries into readable evidence. Raw machine code gives the model little to work with.

Context cost is high. REA has around 170 tool definitions and inserts more than 100,000 tokens into context. Without REA, current models can still install tools and read decompilation output on their own. With less context weight, they may finish faster and cheaper. That limits daily use.

Safety limits change the experience. In the learning-app test, Claude Opus 5.5 hit a safety filter, dropped to Opus 4.8, and refused full source restoration. “Reverse engineer everything” does not hold at the model layer.

Validation cannot be skipped. In the first game round, the model claimed success while the package froze. A reverse-engineering result must run in an isolated environment before anyone can judge whether it works. A model’s self-report is an intermediate state, not a delivery conclusion.

Conclusion: a client can be opened, a product may not be copied

“Software is dead” works as a slogan. It does not work as an engineering judgment.

The reverse-engineering process can hit model safety limits and be downgraded or refused. The learning-app test showed that. A strong tool does not mean any target can be restored without conditions.

Client code and UI can be read and rewritten. The backend, data, and daily operations are a different matter. Much of a product’s value sits in backend services, data assets, business rules, and operations. The client is the entry point. Opening the client shows that the UI and local logic can be understood. It does not copy the product.

For developers, three actions follow.

1. Check the client for hard-coded keys, central endpoint addresses, and sensitive business rules. Move what can move to the backend.

2. Do not treat compiled machine code as a security boundary. Flutter code, native libraries, and resource formats can be analyzed. A hardening shell raises the bar. It does not replace security design.

3. Keep a runtime check for AI-generated reverse-engineering work. Run it in an isolated environment, retest critical paths, and roll back on failure.

For ordinary users, the check is simpler. Watch for three virtual currencies, random coins for check-ins, referral rebates, and refunds routed to off-platform chat apps. Those products use learning as an entry point and distribution as the harvesting engine.

REA’s breakout shows one shift. The interface layer of reverse-engineering tools is being absorbed into AI workflows. The barrier will keep falling. Model safety policy, context cost, runtime validation, and backend moats still decide what can be copied. A client can be taken apart. A product may not be copied. As tools get stronger, boundary judgment still has to land on concrete actions.