AI for Reverse Engineering Is Becoming an Evidence Engine

The useful unit is not a clever answer. It is a defensible claim. A coding assistant can explain a decompiled function, summarize an Android manifest, or write a Frida hook. Those abilities look like reverse engineering, but they do not by themselves establish what a program does. A useful analysis system has to connect a claim to a concrete artifact, identify how the artifact was obtained, separate observation from inference, and say what remains unknown. It also has to test the claim against behavior when behavior is available.

That distinction runs through a recent thread by (@zg0820), which collected ten open-source projects around AI-assisted reverse engineering. This article audits those ten and adds Craft Anything, a closely related project not listed in the thread, for a total of eleven pinned repositories. The set is interesting less as a product catalogue than as a snapshot of an architectural shift. It ranges from a large Model Context Protocol server, REA, to small routing skills such as leanrea; from a CTF competition sandbox to a clean-room rebuild environment; and from APK-specific work to browser automation and evidence graphs.

The thesis of this article is deliberately narrow: AI becomes more reliable at reverse engineering when it stops treating analysis as prose generation and starts operating as an evidence engine. Tool orchestration lets it inspect artifacts it cannot infer from text. Structured evidence makes conclusions auditable. Unknown tracking prevents a gap from silently becoming a confident assertion. Behavioral checks provide a second route to truth. None of these properties is supplied merely by a stronger language model.

Reverse engineering is not the act of producing a plausible story about software. It is the discipline of producing the smallest story that the available evidence can support, while making the missing pieces visible.

The scope of this review is technical and lawful use: interoperability, security review, malware defense, vulnerability research, preservation, education, and analysis of systems you own or are authorized to inspect. It does not provide instructions for bypassing access controls, defeating DRM, avoiding anti-bot systems, stealing credentials, or attacking third-party services. Capability and authorization are separate questions, and a tool that makes analysis easier does not make an unauthorized target legitimate.

1. Why a chat window is the wrong abstraction

Reverse engineering begins with partial, heterogeneous artifacts. A native program may provide machine code, symbols, strings, imports, and runtime traces. A web application may provide minified JavaScript, source maps, HTTP traffic, cookies, and DOM behavior. An Android package may provide bytecode, resources, native libraries, signing metadata, and device logs. A robot system may add firmware images, message buses, configuration files, controller binaries, and time-series telemetry.

A language model can read any one of those representations, but it cannot directly see all of them unless software supplies them. It also cannot know whether a file is current, whether a capture is complete, whether a decompiler failed, or whether a process was observed under atypical conditions. When those details are absent, the model is forced to fill the gap with priors learned from other programs. The result can sound specific while being untethered from the target.

An evidence-producing system changes the task. Instead of asking, “What does this binary do?” it records:

• Artifact identity: which file, build, capture, process, or URL was inspected, including a hash or version where possible.
• Observation: the exact string, instruction, manifest field, API response, packet, source location, or runtime event that supports a claim.
• Method: which parser, decompiler, debugger, browser, emulator, or runtime probe produced the observation.
• Inference: what the model thinks the observation means, separated from the observation itself.
• Coverage: which parts of the target were inspected, skipped, truncated, or unsupported.
• Unknowns: the unresolved questions that would change the conclusion if answered.
• Reconciliation: whether static analysis and runtime behavior agree, and where they diverge.

This is a different interface contract from ordinary chat. The agent must be able to ask for an artifact, receive structured facts, cite the result, and decide what to inspect next. MCP is one way to expose such tools. A CLI with stable JSON output is another. The transport matters less than whether the system preserves provenance and limits.

2. A taxonomy of the eleven projects

The eleven repositories do not occupy one category. They solve different layers of the problem, and comparing them by “number of tools” or GitHub stars would obscure that. Four groupings are more useful.

Broad tool engines and brokers

REA, Craft Anything, and Open-ReverseLab belong here. They provide or connect a broad set of inspection capabilities. REA is an MCP-centered analysis layer that can drive native analysis engines and many target-specific workflows. Craft Anything is a larger Rust engine, desktop application, CLI, and MCP server that can both study a target and rebuild a compatible implementation. Open-ReverseLab is a desktop workspace and knowledge base with modular tool boards and an MCP server.

Routing and orchestration skills

reverse-skill, ctf-skills, and leanrea concentrate on how an agent chooses and sequences work. They are closer to operating procedures than analysis engines. Their value is in scope gates, target classification, tool selection, and context economy. Their weakness is that a routing policy cannot compensate for missing parsers or weak evidence.

Focused analysis workflows

android-reverse-engineering-skill, reverse-skills, and hello_js_reverse_skill narrow the target. A focused workflow can encode the real shape of a domain: APK structure and JADX output, IDA/Frida/Unicorn routines, or JavaScript virtual machines, signatures, cookies, and browser evidence. Narrow scope is often an advantage because the agent receives less irrelevant context and more domain-specific checks.

Clean-room reconstruction and pipeline prototypes

replica-skill and js-reverse-automation--skill sit closer to structured reconstruction. replica-skill studies public behavior and rebuilds features in a clean-room style. The JavaScript automation project combines browser tooling, schemas, an evidence graph, validation, and generated services. Both are more prescriptive than a generic coding assistant, and both need careful distinction between observing behavior and copying protected implementation.

4. Craft Anything: study, build, check, and keep the modes separate

Craft Anything takes a different route. Its purpose is not only to explain an existing system, but to study it and build a new implementation. The repository describes a four-stage loop: Study → Build → Check → Ready/Refine. Study inspects the target. Build asks a coding agent to create a new project. Check compares the new implementation with the original. Ready opens the result, while Refine feeds discrepancies back into the loop.

The project is pure Rust, is early alpha, and reports 320 tools across its engine, AI, and setup layers. It includes a desktop application, a CLI, and an MCP server. Every advertised tool is intended to be available through both the CLI and MCP, which makes the same engine reusable from a human workbench and an agent workflow. The architecture is closer to an analysis operating environment than to a collection of prompts.

Craft Anything’s most important conceptual contribution is its separation between Clean room and Deep modes. Clean room studies only externally observable behavior: screenshots, visible text, measured layout, colors, fonts, spacing, menus, and an app window when permitted. It refuses tools that would read source code, internal files, or disassembly. Deep mode reads files and code and can use Ghidra when installed.

This distinction is not cosmetic. It forces the product to state what kind of knowledge is allowed into the reconstruction loop. A clean-room implementation can still be informed by observed behavior, but it should not be contaminated by copied private implementation. Deep mode supports interoperability and security work where reading internals is legitimate, but it creates a stronger obligation to manage source rights, confidential data, and downstream code provenance.

The name “clean room” can be misleading if read as a security guarantee. Craft Anything explicitly says its clean-room mode is a rule about which tools the system offers and refuses. It is not an operating-system sandbox. A coding agent still acts with its own permissions. The repository also warns that dependency installation runs code. This is exactly the kind of boundary a deployment review should capture: policy controls, process isolation, filesystem permissions, network access, and agent tool permissions are different layers.

Craft Anything’s parity stage is a useful model for agent evaluation. The agent is not rewarded merely for producing a working page or application. It must compare the result with the original and list what does not match. For a website, the system can compare screenshots at multiple widths. For a game, it can use a self-test. For an app, it can exercise runtime behavior. The exact checks vary, but the principle is stable: the agent’s generated artifact is tested against an external observable, not against its own description.

The repository’s docs/STATUS.md is unusually valuable because it separates working, partial, and unverified capabilities. It records hundreds of tests, but it also states that some agent backends and platform paths have not been run live. Claude Code is the live-verified builder, while other agents or API backends were built but not necessarily exercised. That distinction should be normal in AI reverse-engineering documentation. “Implemented” and “verified on this target” are not the same claim.

5. The other projects: specialization is where rigor becomes practical

reverse-skill: routing before capability

Despite the generic name, reverse-skill is primarily a CTF sandbox and competition orchestrator. It provides a single routing entry, downstream specialized skills, scope gates, security review, and an explicit trust model. That shape is useful beyond competitions. A single entry point can classify the target, reject work outside the authorized scope, choose a narrow workflow, and require a review before an action is taken.

The license structure also has a boundary worth noticing: the repository’s top-level license is MIT, while its bundled CTF-Sandbox-Orchestrator carries GPL-3.0. A team reusing the orchestration stack should inspect the component it actually imports or redistributes rather than treating the repository-level label as a blanket answer.

The CTF origin also exposes the gap between a challenge and a production system. A CTF target is usually designed to be solved, has a defined boundary, and tolerates aggressive experimentation. A robot controller, medical device, or vendor application has safety, availability, privacy, and contractual constraints. A routing policy built for one environment needs a new threat model before it can be used in the other.

android-reverse-engineering-skill: domain structure matters

The Android skill handles APK, XAPK, JAR, and AAR analysis with JADX and Fernflower. It extracts APIs and recovers Kotlin metadata names. This is a good example of why focused skills can outperform broad prompts. Android analysis has a specific artifact grammar: manifest declarations, DEX and resources, native libraries, signing information, and framework behavior. A workflow that knows those boundaries can ask better questions and attach better evidence.

It still inherits decompiler limitations. JADX may reduce or misname constructs, Kotlin metadata recovery is not source recovery, and resource names can be obfuscated. The right output is therefore a set of claims with method references, confidence, and missing branches, not a generated “source reconstruction” that hides uncertainty.

replica-skill: parity without copying

replica-skill contains eleven skills for studying public behavior and rebuilding functionality. Its README makes an important legal and ethical distinction: “clone any app” means features and flows, not code, logos, content, or private data. The workflow appears aimed at own-account studies, clean-room reconstruction, parity checks, and branding separation.

That distinction should be encoded in the artifact model, not only in prose. A reconstruction system should be able to answer which observations came from the original, which design choices were independently made, which assets are licensed, and which similarities are functional necessities versus copied expression. Without that ledger, a clean-room claim is difficult to defend.

leanrea: the context-economy experiment

leanrea is a single skill of roughly 8 KB that drives local tools directly instead of exposing the full REA MCP surface. Its stated motivation is context economy: large tool schemas consume tokens and attention even when most tools are irrelevant to the current target.

The repository reports 38% less wall time and 35% lower cost than REA, but the comparison uses three repetitions, one model, and one machine. That is a useful signal, not a settled result. Wall time and cost are highly sensitive to caching, model version, network conditions, task mix, and how much exploratory work the agent performs. The right conclusion is that transport and schema design may matter substantially, not that one architecture is universally faster.

ctf-skills and reverse-skills: breadth versus depth

ctf-skills covers many CTF categories, including reverse engineering, tool setup, and MCP integration. reverse-skills is narrower, with eight focused IDA, Frida, Unicorn, Android, and iOS workflows. The first optimizes for discovering the right category; the second optimizes for detailed work inside a known category.

Both need the same missing layer: a common evidence format. A category-specific skill can produce an excellent transcript while still making it hard to compare two analyses, reproduce a finding, or measure how often the agent claims more than the tools observed. reverse-skills is older than most projects in this set and has no top-level license file despite saying MIT in its README, so reuse requires clarification rather than assumption.

hello_js_reverse_skill: the browser is an instrument

hello_js_reverse_skill focuses on web and JavaScript analysis: controlled experiments, signatures, cookies, JSVMP, and browser evidence. This is a useful counterweight to the assumption that “reverse engineering” means disassembling a native binary. In a browser, the relevant evidence may be a request sequence, a generated value, a DOM transition, a stack trace, or a script response.

The project had no top-level license file in the reviewed snapshot. That does not make its ideas unusable, but it does mean a team should not copy its code into a product without confirming permission. This is a recurring problem in fast-moving agent-skill repositories: a public repository is not automatically an open-source license grant.

Open-ReverseLab: analysis as a workspace and knowledge base

Open-ReverseLab is a large desktop and knowledge-base workspace with modular tool boards and an MCP tool server. Its value is organizational: artifacts, notes, tools, and analysis state can live in one environment instead of being spread across chat transcripts and ad hoc folders. The repository also includes public-release checks and explicit rules against committing real credentials, targets, or private artifacts.

The release-hygiene rules are as important as the feature list. Reverse-engineering workspaces naturally accumulate proprietary binaries, credentials, private URLs, packet captures, and customer data. A tool that makes those artifacts easy to collect also makes accidental publication easier. Release checks should be treated as part of the operating model, not as an optional repository checklist.

js-reverse-automation--skill: from trace to validated service

js-reverse-automation--skill combines a browser MCP, JSRPC, Flask, and Burp-related workflows. It adds schemas, an evidence graph, validation, and generated services. The architecture is interesting because it closes the loop from observation to reusable implementation while retaining a record of how the implementation was derived.

That closure also raises the stakes. A generated service can normalize an analysis that was never fully understood, and it can expose a capability far beyond the original investigation. The system needs scope enforcement, secret handling, request limits, human review, and a clear distinction between a diagnostic experiment and a production automation path.

6. MCP versus lightweight skills: the context question is architectural

MCP is presented as a standard way to connect models to tools, but a large tool catalogue can create a new problem. The agent must decide which tool to use from names, descriptions, and schemas. Those definitions consume context, and the model may choose poorly when hundreds of similar operations are visible. A CLI skill can reduce that overhead by keeping the public interface small and letting a shell command discover or invoke a narrower set of operations.

REA addresses this from the other direction. It offers compact input schemas by default, complete output schemas, and optional compact or disabled output schemas for clients with frame limits. This is evidence that protocol design is becoming an engineering discipline. The goal is not to hide capabilities, but to expose enough structure for correct selection while preserving server-side validation and bounded result sizes.

A useful distinction is:

• Discovery cost: how many tokens and decisions are required to find the right operation.
• Call cost: how much data the selected tool returns.
• Grounding cost: how much additional context is needed to interpret the result correctly.
• Recovery cost: how easily the agent can detect and correct a bad tool call.

A 300-tool server can be cheaper than a small CLI if its schemas and evidence objects let the agent navigate directly to the right evidence. A tiny skill can be more expensive if it forces repeated shell discovery and unstructured parsing. Claims about “MCP overhead” or “skill speed” without a task distribution and error-rate measurement are incomplete.

There is also a human-audit question. A protocol can expose a complete result, but the interface should still make the result inspectable. Craft Anything’s workbench and Open-ReverseLab’s persistent workspace are valuable because they show the evidence to a person, not just to a model. A system that is efficient for the agent but opaque to the reviewer has moved the bottleneck rather than removed it.

7. Failure modes that stronger models do not solve

Hallucinated structure

The most familiar failure is a model naming a function, protocol, or data structure that was never observed. Better code comprehension reduces the frequency but does not eliminate the problem. The mitigation is structural: every high-confidence claim should resolve to an evidence ID or accepted runtime observation. If the evidence is absent, the output should say “unknown” or “hypothesis,” even when the model finds the hypothesis plausible.

Evidence contamination and prompt injection

Targets are hostile inputs. A string in a binary, a comment in source, an error page, a packet payload, or a README can contain instructions telling the agent to ignore its scope, reveal secrets, or run a command. A system should label target content as data, not instructions, and keep the agent’s policy outside the analyzed artifact. Tool descriptions and generated files need the same scrutiny. A prompt-injection defense that exists only in the system prompt is weaker than one enforced by permissions and scope checks.

False equivalence

Similarity is not identity. Two functions can have similar strings or control flow while serving different protocols. A rebuilt page can look identical while failing on error states, accessibility, localization, or data safety. Craft Anything’s own documentation is careful to present visual parity as a bounded check. An evaluation should ask which equivalence classes matter: API behavior, state transitions, output distributions, timing, security properties, or visual layout.

Weak benchmark evidence

The leanrea comparison is a useful example of honest but limited measurement. Three repetitions on one model and one machine can reveal a large effect, but they cannot support a general performance claim. Reverse-engineering benchmarks should report task family, target complexity, model versions, tool versions, token budget, wall time, cost, success criteria, and human intervention. They should also report failures, not only successful examples.

License and provenance contamination

A clean-room workflow can be defeated by a single copied file, an unlicensed skill, or an agent that read the original source and then wrote a “new” implementation. The legal question is not solved by the word “clone.” Teams need artifact provenance, license checks, asset inventories, and a record of which mode was used. The absence of a license file is a stop sign for reuse until clarified.

Capability without containment

An agent that can run a debugger, install dependencies, launch an emulator, or call a browser can also change the host. Clean-room policy is not isolation. Runtime capture is not sandboxing. An MCP capability token is not a complete security boundary. Containment requires operating-system controls, network policy, least privilege, snapshotting, and a way to stop a process before it reaches a restricted target.

8. An evaluation rubric for AI reverse-engineering systems

The relevant question is not whether an agent can produce an impressive reconstruction in a demo. It is whether the system produces more reliable analysis than the existing workflow under a known budget and scope. Six metrics capture most of the value.

1. Evidence coverage. What fraction of claims can be traced to a valid artifact or runtime observation? Define supported claims as $S$ and all claims as $C$; a simple metric is $C_e = S / C$, with “supported” decided by the review protocol rather than the model.
2. Reproduction rate. How often can a second analyst repeat the analysis from the recorded artifacts and reach the same conclusion? This catches private knowledge, hidden tool state, and nondeterministic reasoning.
3. Unknown tracking. Does the system identify what it did not inspect? A useful report should list skipped images, unsupported architectures, truncated functions, failed parsers, and unobserved runtime branches.
4. False-certainty rate. Among claims the system marks high confidence, how many are wrong or unsupported? This is more informative than a single aggregate accuracy score because confidently wrong claims are the expensive kind.
5. Behavioral reconciliation. When runtime evidence exists, does it agree with the static model? If not, does the system explain the discrepancy instead of averaging it away?
6. Cost and intervention. Record token cost, wall time, tool cost, model calls, human approvals, and the number and severity of interventions.

Each metric should be reported by task family. Native binaries, minified web applications, Android apps, firmware, and robot telemetry have different ambiguity, tool coverage, and safety constraints. A single average over all of them would hide the exact conditions under which the system is useful.

A strong evaluation design also includes negative controls. Give the agent a target with a deliberately missing artifact. Give it an observation that contradicts static analysis. Include an untrusted input containing instructions. Include a file that resembles a known library but has a changed behavior. A system that handles only clean demos has not demonstrated the properties required for real reverse engineering.

9. Why this matters for robots and physical AI

RobotWorld’s interest in these tools is not generic software curiosity. A modern robot system is a stack of opaque boundaries: vendor firmware, controller binaries, ROS or DDS nodes, machine-learning runtimes, model artifacts, configuration bundles, phone applications, and cloud services. When a robot behaves differently after an upgrade, the relevant evidence may be spread across a binary, a log, a packet capture, a model manifest, and a physical observation.

AI-assisted evidence engines can help with authorized debugging in several concrete ways:

• Firmware and package inventory: identify versions, components, signing metadata, extracted files, and unsupported regions before maintenance.
• Interface reconstruction: map documented and observed message flows without assuming that a protocol name implies a complete specification.
• Incident triage: connect a crash, log, runtime trace, binary location, and configuration change into one reviewable timeline.
• Upgrade comparison: compare builds and report changed symbols, permissions, dependencies, and behavior while preserving the evidence behind each difference.
• Digital-twin validation: compare a simulation or reconstructed interface with the observable behavior of the real system, including timing and failure cases.

The physical layer makes false certainty more costly. A wrong claim about a network API may cause a failed request. A wrong claim about a robot controller’s safety state can cause equipment damage or injury. That is why the evidence engine model is more appropriate than an autonomous “solve it” agent. Analysis should be separated from actuation, and any generated implementation should pass simulation, hardware-in-the-loop, and human safety review before it can command a physical system.

The same tools also create new risks. A robot may expose maintenance interfaces, credentials, telemetry, or proprietary control logic. An agent with broad filesystem and network access can collect all of them in one session. Deployment should isolate target artifacts, minimize network egress, separate production credentials, and require explicit approval for actions that could alter firmware or move a robot.

10. Adoption guidance

The safest path is a narrow pilot with a strong evidence contract, not a company-wide installation of every skill in the list.

1. Define the authorized target and question. Record ownership, purpose, permitted actions, excluded data, and stopping conditions. “Analyze the app” is not a scope.
2. Choose one workflow family. Start with APK inventory, native function triage, JavaScript evidence collection, or firmware package inspection. Measure that family before adding more tools.
3. Run in a disposable environment. Use a separate account, restricted network, read-only source mounts where possible, and no production credentials. Treat dependency installation and runtime capture as code execution.
4. Require structured evidence. Reject reports whose claims lack artifact identity, source location, method, coverage, and unknowns.
5. Review side effects separately. Reading a binary, launching a local process, installing a dependency, opening a network connection, and writing to a target are different risk classes.
6. Test failure behavior. Include malformed files, unsupported formats, adversarial strings, incomplete captures, and conflicting static/runtime evidence.
7. Record provenance for reconstruction. Keep observed behavior, independently authored implementation, licensed assets, and copied artifacts in separate ledgers.
8. Measure human review. An agent that saves tool time but creates ambiguous reports may increase total cost. Track reviewer minutes and the number of conclusions that had to be corrected.

A reasonable pilot outcome is not “the agent reverse engineered an app.” It is a smaller, reproducible result: for a defined artifact, with a fixed toolchain and budget, the system recovered a specified set of facts, cited the evidence, identified its blind spots, and produced a second analyst-verifiable report. That outcome can be compared, audited, and improved. A polished narrative cannot.

11. Conclusion: the model is not the evidence layer

The eleven projects point in the same direction even when their architectures differ. REA turns a large tool surface into bounded, evidence-bearing agent operations. Craft Anything makes clean-room policy and parity checks visible. The focused skills encode domain structure that a generic model would otherwise have to rediscover. Open-ReverseLab preserves analysis state, and the JavaScript projects show how observation can be transformed into validated services.

The durable contribution is not that an AI can now “read code.” Models could already produce useful explanations. The change is that software can now give the model controlled access to the artifacts, parsers, runtimes, and comparison tools that make explanation accountable. It can assign evidence IDs, constrain output, expose missing coverage, and force a static claim to meet a runtime observation.

That is also the correct way to judge the next wave of tools. Ask what the system can observe, how it represents uncertainty, what it does when a tool fails, how it keeps target content from becoming instructions, and whether another analyst can reproduce the result. A system that answers those questions is more than a coding assistant with reverse-engineering prompts. It is an evidence engine. A system that does not answer them is still capable of producing an attractive story, which is precisely why it should not be trusted with a consequential conclusion.

Sources and evidence note

This article is a documentation and repository audit, not an independent execution benchmark. The source thread lists ten projects; Craft Anything is an additional related project selected for this review, and all eleven repository snapshots were pinned on 2026-11-09. Claims about tool count, supported targets, verification status, and limitations are taken from the projects’ own README, status, and design documents; they were not independently validated against every target platform. The only performance figures discussed are the ones published by project authors, with their stated sample-size limitations.

• Source thread: (@zg0820), 2026-11-08; it lists ten projects. Craft Anything was added separately as a related project for this audit.
• morluto/rea at c78c8aed, MIT.
• storytold/craft-anything at bc50c085, MIT OR Apache-2.0.
• zhaoxuya520/reverse-skill at cab634bd, top-level MIT; bundled CTF-Sandbox-Orchestrator is GPL-3.0.
• SimoneAvogadro/android-reverse-engineering-skill at 0c7cf898, Apache-2.0.
• Jakeschincariol/replica-skill at 77c9436f, MIT.
• aicodeking/leanrea at 09ba4aa0, MIT.
• ljagiello/ctf-skills at 2ad85d36, MIT.
• P4nda0s/reverse-skills at a2baa31c, README states MIT; no top-level license file was found in the reviewed snapshot.
• WhiteNightShadow/hello_js_reverse_skill at 9fb8e001, no top-level license file was found in the reviewed snapshot.
• LING71671/open-reverselab at d0ccbdca, GPL-3.0.
• Fausto-404/js-reverse-automation--skill at d8969b1b, Apache-2.0.

All screenshots remain the property of their respective projects and are used with source attribution for technical commentary. The article does not grant permission to reproduce proprietary software, bypass technical controls, or analyze systems without authorization.