REA (Reverse Engineer Anything)

What the Adobe replacement story actually shows

ArtCraft is building an open-source set of creative applications, including PhotoCraft, FilmCraft and other tools aimed at familiar Adobe workflows. The original seven-app announcement describes AI-assisted development and a goal of reaching parity. PhotoCraft’s repository calls its implementation clean-room and written in Rust. That is a claim about a newly written implementation, not an announcement that Adobe’s original code has been recovered.

• As checked on October 12, the official lineup lists twelve applications. PhotoCraft and PdfCraft are early alpha; most others are development-stage builds, even when installers exist. Current status takes priority over an ambitious announcement.
• File compatibility is a reader’s first useful test. Opening a PSD is different from preserving every layer, effect, color-management rule, plugin and editing operation through a round trip.
• The original discussion asks about costs, maintenance, formats and MCP access. Those are practical questions to test, rather than evidence that professional feature parity has already arrived.
• ArtCraft and REA are separate projects. The cited sources do not establish that ArtCraft used REA; this is an adjacent example of AI-assisted reimplementation.

What reverse engineering means

Reverse engineering works backward from a program or its behavior to an explanation of how it works. Depending on the target, you may examine a shipped executable, a JavaScript bundle, a file format, a protocol trace or a controlled execution. The immediate goal can be as small as explaining one calculation. Rebuilding the program is a further engineering step, with its own tests and limits.

• Decompilation converts machine instructions into a higher-level representation. Compiler transformations, missing symbols and incomplete observations can leave ambiguity; readable pseudocode is not the original project with its names, comments and build system.
• Exact reconstruction attempts to reproduce selected code, interfaces or layout against the original artifact. State precisely whether a check covers one function, authored code or the whole executable.
• Behavioral reimplementation uses a new design to reproduce observed or documented behavior. A compatible file reader or creative tool can be useful without recovering the vendor’s internal architecture.
• A visual clone reproduces appearance or selected interactions. It needs separate proof for algorithms, file handling, performance and professional workflows.

How REA changes the agent’s investigation

REA connects an agent’s questions to concrete analysis tools. A model can ask about a function, inspect its callers, follow a relevant value and compare the explanation with a reference. It can then write an implementation and tests. REA returns observations and their limitations; the agent supplies the reasoning and development work. This is a loop of investigation, hypotheses and checks, not a single prompt that proves an entire application has been recovered.

• Native targets use configured engines such as Hopper, Ghidra or IDA. JavaScript/Electron, .NET, browser and other workflows have their own requirements; the package does not provide every engine or make every host equally capable.
• A useful result links a conclusion to the relevant code, bytes, calls or runtime observation. Coverage gaps remain unknown until another observation or test resolves them.
• A reconstruction needs a reference and an acceptance condition. Inspecting a branch, compiling new code and observing one successful task establish different things.
• The coding agent can keep evidence and tests with the implementation so later work can reproduce the conclusion. That is how an investigation becomes reusable engineering knowledge.

The people behind REA and their technical interests

The public project is associated with morluto and collaborator N0zoM1z0, who describes co-building REA. Their profiles connect agent research with formal verification and software reconstruction. morluto lists work on agents, reinforcement-learning environments and preference learning, alongside projects such as LeanToken and Jacobian. These are public self-descriptions and project links, rather than a verified employment or education biography.

• Their public mathematics work includes an Erdős Problem #81 repository and formal Lean proof material. The interesting connection is the emphasis on explicit evidence and checkable results; a profile’s claim is not, by itself, independent confirmation of a theorem.
• N0zoM1z0’s October 10 essay describes years of manual game reverse engineering and a serious shift toward agent-driven work in August 2026. The human still chooses the objective and how a result will be accepted.
• The Touhou work continued substantial prior human reconstruction. The author credits GensokyoClub’s TH08 work and existing ReC98 knowledge, rather than presenting every result as an AI project started from nothing.
• The essay also describes disagreement with maintainers who reject primarily AI-produced contributions. Credit, reviewability and community acceptance remain part of the engineering story alongside faster iteration.

When an “exact” comparison accepted the wrong game behavior

The strongest story in N0zoM1z0’s account is a failure of the checker. A TH08 reconstruction used 0.0 where the original item-collection logic used a 128.0 power threshold. The function had passed an exact comparison: the tool adjusted referenced addresses but did not verify the floating-point value stored at the address. Matching instructions therefore concealed a behavior-changing data error.

• According to the maintainer’s account, the September 2 correction fixed both the source and the comparison. A wider audit then found additional incorrect floating-literal references in previously accepted functions.
• The lesson is concrete: test the verifier with inputs it should reject, and revisit earlier passes after discovering a shared blind spot. An agent’s confidence or a green report cannot fill a gap in the oracle.
• TH08’s repository separates authored-function matching, whole-executable identity and playable ports. A playable reconstruction or high authored-code match is useful progress; it does not establish an identical complete executable.
• The AI-era shift described here is repeated, tool-assisted investigation with checks and repository memory. The inherited human work, original artifact and human review remain visible parts of that process.

A smaller official case: DX-Ball’s sound panning

REA’s DX-Ball showcase narrows the job to one sound-pan calculation. It follows instructions, callers and data reads into a maintained C implementation, then checks selected behavior against the original x86 routine and a separate compiler replay. The released illustration reports 3,205 reference cases and a 63-byte replay. This is a bounded example of recovering a rule and testing it; it is not a claim to have recovered the entire game.

• Record what entered the calculation, what the original routine returned and how the implementation was compared. A test count becomes useful only with those conditions.
• Keep instruction identity and behavior testing separate. Recompiled instructions can differ across compilers or architectures even when selected behavior is preserved.
• The official site also demonstrates Calculator percentage handling and a browser dinosaur game. Those are teaching and publisher case materials; this guide has not independently repeated their target executions.

Diablo, Jak and Bloodborne: what a game reconstruction really covers

Game projects make the distinction between reconstruction, a port and an unfinished ambition especially clear. Devilution’s history predates the current coding-agent wave: its documentation credits GalaXyHaXz’s 2018 Diablo reverse engineering and explains how symbols left in the Japanese PlayStation release, together with debugging information, helped recover program structure. That was useful metadata for reconstruction, rather than Blizzard or Sony publishing the original development project.

• Devilution seeks the old Diablo behavior, including bugs. DevilutionX is the separate modern cross-platform port and engine-improvement effort. Both keep game code work separate from copyrighted game data; the projects do not supply the original assets. These are historical community projects, not demonstrated REA or AI achievements.
• OpenGOAL reconstructs the GOAL code used by the Jak and Daxter games and provides a compiler, decompiler and new runtime. Its official material explains the PS2-to-PC architecture and requires the player’s own retail game/ISO. A working Jak reconstruction does not imply access to Naughty Dog’s original repository or coverage of Sony’s whole catalog.
• Paleblood describes an independent Bloodborne decompilation and source-port effort. At the checked October 12 snapshot it reports only 21 verified functions out of 157,757 and explicitly says its own runtime cannot yet run the complete game. This is ongoing reconstruction, not a released full PC replacement.
• Paleblood permits disclosed AI assistance subject to function-level validation and independent review. Permission to use AI is not evidence that AI produced its present results. No source selected here establishes that the core Devilution or OpenGOAL work was AI-driven.
• For any game claim, ask which version was examined, how recovered functions were validated, whether a complete program is playable, and which original data is still required. A native source port, an emulator, a demake and a visual clone answer different questions.

Is the Closed-Source Era Over?

No. These examples support a narrower conclusion: keeping source private does not guarantee that shipped behavior will remain difficult to understand or reproduce. AI can help an investigator traverse code, propose explanations, generate tests and implement an alternative. That can reduce the effort required for a particular feature. It does not establish access to the original development project or a complete, maintained replacement.

• The practical pressure is on reproducible behavior. A client-side rule, familiar interface or documented format can become a reconstruction target. The analysis available still depends on what is shipped and what can actually be observed; inspecting a client does not reveal a server’s complete implementation.
• A working replacement must survive the details people depend on: old files, edge cases, performance, plugins, accessibility, interoperability and support. ArtCraft’s early status and the TH08 checker failure show why these cannot be inferred from a compelling demonstration.
• Readable reconstructed code is an interpretation that needs evidence. Original comments, design history, missing dependencies and unexercised paths are separate questions. A program that runs once has not proved all of them.
• REA’s license covers REA-authored software and documentation. It does not grant licenses to target programs, commercial analysis engines, game assets or trademarks. A project calling itself clean-room has not, through that label alone, resolved every permission question.
• Our reading of these cases is that some barriers move toward validation, integration and maintenance. Treat “closed source is dead” as a debate about those changing costs, with the artifact and acceptance criteria visible, rather than as a demonstrated universal result.

Start with one feature you can verify

Choose a small target you own or are authorized to examine, and one question with an observable answer: a CSV export rule, a percentage calculation or a sound parameter. Follow the official setup guide, review its proposed agent configuration changes and restart the agent. As checked here, the published package is rea-agents 6.4.0 and requires Node.js 22.19+ within 22.x, 24.11+ within 24.x, or 26+.

• The pinned setup command is npx rea-agents@6.4.0 setup. Review the plan and any required provider installation or licensing separately; static JavaScript inspection does not require a native decompiler.
• Example investigation prompt, not an executed installation: “Use REA to inspect this application I am authorized to analyze. Explain how its CSV export handles headers and quoted values. Cite the relevant code or runtime evidence, identify unknowns, then implement a small compatible exporter and test changed inputs against the reference.”
• For native work, select a supported provider and target format first. The 6.4.0 documentation describes experimental Windows Ghidra support for scoped workflows; it is not a promise that every native or runtime workflow runs on Windows.
• Accept the first result only after a changed input produces the expected reference and reconstruction outputs. Keep the target version, selected cases and unresolved paths with that check.

Costs, privacy and the limit of a local instance

REA runs its analysis components locally, but it is used through a coding agent. The agent’s configured model can receive tool results and code context. A local MCP process therefore does not, by itself, establish an entirely offline investigation. Costs and permissions also depend on the model service, external engines and selected target.

• REA is MIT-licensed open-source software. A model API, Hopper, IDA or another engine can have separate charges and license requirements; installing REA does not provide those entitlements.
• Static inspection and runtime capture have different effects. The documented JavaScript/.NET static paths read artifacts without running the application; runtime paths may launch or interact with a target using your permissions.
• A server answering an identity request proves that the instance responds. An advertised catalog or a successful setup is not proof that every provider is installed or that a particular reconstruction will work.
• Choose evidence suitable for your agent and model’s data handling. Keep private screenshots, target files, credentials and investigation logs out of public examples.

Useful first jobs

• Explain one feature in a shipped program using traceable analysis evidence.
• Reconstruct and test a selected rule for interoperability or software preservation.
• Investigate packaged JavaScript/Electron, native or managed software with the appropriate provider.
• Learn how agent-led reverse engineering differs from source recovery, UI cloning and product replacement.