AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
Can AI Agents Reverse Engineer Apps? REA Tool Tested India's Most Futuristic AI Conference Is Back – Bigger, Sharper, Bolder d : h : m : s Career GenAI Prompt Engg ChatGPT LLM Langchain RAG AI Agents Machine Learning Deep Learning GenAI Tools LLMOps Python NLP SQL AIML Projects Reading list How to Become a Data Analyst in 2025: A Complete RoadMap A Comprehensive Learning Path to Tableau in 2025 A Comprehensive NLP Learning Path 2025 Learning Path to Become a Data Scientist in 2025 Step-by-Step Roadmap to Become a Data Engineer in 2025 A Comprehensive MLOps Learning Path: 2025 Edition Roadmap to Become an AI Engineer in 2025 A Comprehensive Learning Path to Master Computer Vision in 2025 Best Roadmap to Learn Generative AI in 2025 GenAI Roadmap for Enterprises Large Language Models Demystified: A Beginner’s Roadmap Learning Path to Become a Prompt Engineering Specialist Reverse Engineer Anything (REA): Can AI Really Crack Closed Code? Aayush Tyagi Last Updated : 18 Oct, 2026 11 min read Every developer hits this wall eventually. A feature behaves in a way you can’t explain, and the code behind it is locked away. No source. No docs. Just a compiled binary or a wall of minified JavaScript. Figuring it out the traditional way means hours in a disassembler, specialist tools like Ghidra or IDA, and a skill set most developers never had time to learn. So most people guess, work around it, or give up. REA (Reverse Engineer Anything) is built to remove that wall. It’s an open-source MCP server that lets AI coding agents investigate native binaries, Electron apps, Android APKs, .NET assemblies, websites and firmware, all from plain-language instructions. You ask how something works. The agent digs in and shows you the evidence. But can you trust what it tells you? To find out, we predicted how Obsidian’s quick-switcher ranks search results before letting the agent inspect a single line. In this article, we explore REA’s setup, real-world accuracy, blind spots, and the time and token cost of reverse engineering with AI. Table of contents What is REA? Setup and requirements Step 1: Predicting the algorithm by hand Step 2: Putting REA to work Things to look out for while using REA Where REA actually fits The legal part you should not skip Conclusion Frequently Asked Questions What is REA? REA is an MCP server that connects to your coding agent and exposes about twenty categories of analysis target. The framing most coverage gets wrong is that REA is mostly a coordinator, not a decompiler. Miss that and you will install it, point it at a binary, and wonder why nothing happens. Key features Two analysis modes. For JavaScript and .NET, REA performs static inspection itself with no extra engine. For native binaries it drives Ghidra, Hopper or IDA, which you install and license separately. Local execution. The application never leaves your machine. Your agent’s model provider still sees the tool results under its own data policy, so this is not the same as fully offline analysis. Evidence with the answer. Results come back with byte offsets and source locations rather than a bare summary, which is what makes independent checking possible. Stated unknowns. The workflow instructions push the agent to report what it could not determine, which is the opposite of what a model does when left to improvise. Broad target support. Electron apps, APKs, .NET assemblies, Go and Rust binaries, websites, HAR captures, firmware, packet captures and Linux crash dumps. CLI as well as MCP. You can run the static analysers directly from the terminal if you do not want an agent in the loop. Setup and requirements Installation is one command, assuming Node 22 or newer: npx rea-agents setup It asks which agents to configure, shows the proposed config changes, backs up what it replaces, and registers the MCP server. Restart your agent afterwards. Claude Code, Codex, Cursor, Gemini CLI and Grok Build are supported out of the box. What you need beyond that depends entirely on your target: TargetWhat you need beyond REA JavaScript and ElectronNothing. Node and npm only .NET assembliesNothing. Static inspection only Go and Rust binariesNothing. Metadata is read from the binary Native binariesHopper, Ghidra or IDA, installed and licensed by you Android APKsHeadless JADX plus a full JDK WebsitesA Chrome-family browser Firmware, packet captures, crash dumpsVaries, several are Linux-only Everything in this article runs on the top half of that table, so it is reproducible with no paid tooling. One caution before installing. REA’s README warns that a similar repository name or a copied README does not make a download official, and names morluto/rea, rea.tools and the rea-agents npm package as the real sources. We checked the publisher first: the package is published through GitHub Actions trusted publishing, has 32 released versions, and the repository field matches. Given that setup registers a server which then runs analysis tools locally, this check is worth thirty seconds. Step 1: Predicting the algorithm by hand Our target was Obsidian 1.14.4 on macOS, and the question was how its quick-switcher ranks fuzzy filename matches. Before installing anything, we spent fifteen minutes typing into the search box. We built a throwaway vault of filenames engineered to compete on different match qualities, then recorded the rankings. This date-stamped record is what makes the rest of the article a test rather than a demo. Observation 1: the query “graph” RankFileMatch indexAt word boundary 1graph-db-benchmarks0yes 2graphql-schema-notes0yes 3graphql-gateway-design0yes 4graph-analysis-of-distributed-systems-and-queues0yes 5legacy-graph-queries7yes 6grpc-vs-graphql8yes 7a-b-c-d-e-f-g-h-i-graph18yes 8zgraph1no 9xgraphql-adapter1no 10grand-architecture-proposal-handbookscatteredn/a Two of those files were written specifically to break a hypothesis. a-b-c-d-e-f-g-h-i-graph matches eighteen characters in and is four times longer than zgraph, yet it ranks six places higher. Whatever the algorithm weights, starting a word beats starting early. The last row matters too. grand-architecture-proposal-handbook matches g, r, a, p, h scattered across word starts, which confirms subsequence matching exists and ranks below every contiguous match. The model we wrote down A tiered sort, in descending priority: Contiguous match beats scattered subsequence Match at a word boundary beats match mid-word Among boundary matches, earlier position wins At equal position, shorter filename wins All ten rows fit. We were fairly pleased with it. Observation 2: the query “gq” This query produced fourteen results, almost all scattered matches, and three rows killed the model outright. RankFileg indexq indexBoundaries hit 2goal-q3-planning05both 3git-log-quirks08both 5graphql-schema-notes05g only 6graphql-gateway-design05g only 7general-ledger-questions015both 11legacy-graph-queries212q only 12grpc-vs-graphql013g only 14graph-analysis-…-queues041both Ranks 5 and 6 hit one boundary and beat rank 7, which hits two, so boundary count is not the top key. grpc-vs-graphql starts its match at index 0 on a word boundary yet lands at rank 12, below a file whose g is buried mid-word, so first-character position is not the top key either. And the last row has both characters on clean word starts but finishes last, because its q sits at index 41. The revised prediction Not a tiered sort at all, but a weighted numeric score where every matched character contributes: a large penalty for fragmentation, a per-character penalty for landing mid-word, and a penalty growing with position. Two rows bracket the trade-off. Rank 3 beats rank 5 despite its q sitting three characters later, so a boundary is worth more than roughly three positions. Rank 6 beats rank 7 despite one fewer boundary and a q ten characters earlier, so a boundary is worth less than roughly ten. A boundary is worth between 3 and 10 positions. That is a falsifiable quantitative prediction, derived entirely from the outside in fifteen minutes. Step 2: Putting REA to work The prompt We gave no architectural hints, named no files, and pointed at nothing specific: Obsidian is installed at /Applications/Obsidian.app. Work out how its quick-switcher scores and ranks fuzzy matches. Show me the evidence for each step, and tell me what you could not determine. Finding the code The first useful thing the agent did was avoid an obvious trap. Contents/Resources/ holds both app.asar and obsidian.asar, and the one named app.asar is only a 472KB Electron bootstrap shim. The real application is the 27MB obsidian.asar. Extracting it produced a single 3.9MB minified app.js. Narrowing from 3.9MB to one function This is the step that justifies the exercise, and the approach was smarter than brute-force searching. Obsidian exposes prepareFuzzySearch and fuzzySearch as public API for plugin authors, so those names survive minification in the export table. The agent searched for them and followed their minified aliases inward: lx, sx, hx, ux, cx. The public API is a labelled door into unlabelled code. It then did the check that separates analysis from guesswork. It confirmed that oie, the actual QuickSwitcherModal class, extends D5, the suggestion class whose getSuggestions contains that pipeline. Finding plausible-looking scoring code and assuming it is the code that runs is the classic failure mode here, and it verified the inheritance before trusting the trace. The algorithm Matching happens in two tiers (hx/ux, around byte offset 1256510). Tier 1 requires every whitespace-separated token to appear as a literal contiguous substring, searched left to right. If that fails, Tier 2 falls back to character-by-character subsequence matching. If neither tier matches, the file is dropped entirely rather than scored low. Scoring is a single function, cx, around offset 1256690: r = 0 r -= max(0, fragments - 1) // 1.0 per extra fragment r -= boundaryMisses / 10 // 0.1 per mid-word character r -= (lastMatchEnd - firstMatchStart - queryLen) / 100 // 0.01 per character of span r -= firstMatchStart / 1000 // 0.001 per character of lateness r -= targetLen / 10000 // 0.0001 per character of filename Zero is the best possible score, everything else negative. The five constants are scaled roughly ten times apart, which makes the sum behave like a lexicographic priority order. A matched character escapes the boundary penalty if it is the first character of the string, if it is punctuation or CJK, if it is an uppercase letter following a lowercase one (the camelCase hump, so the S in webSocket is free), or if it is a lowercase letter following a separator. Two mechanisms were invisible from outside. A path wrapper at offset 1826030 tries the bare filename first and only falls back to the full path, applying a flat 1.0 penalty when it does, which is why filename matches almost always beat folder-name matches. And files in excluded folders are not dropped but penalised by 10.0, so they surface only when nothing else matches. Scoring the prediction against the code What we predicted from behaviourVerdict Contiguity dominates everythingCorrect. The 1.0 term, ten times the next Word boundary outranks positionCorrect. 0.1 against 0.001 Earlier position beats laterCorrect, but it is two terms, not one Shorter filename breaks tiesCorrect. The 0.0001 term The priority order of all fourCorrect, in exactly that sequence A boundary is worth 3 to 10 positionsCorrect. It is exactly 10 That last row came from a single pair of files where the two terms almost exactly cancel: graphql-gateway-design: -1 - 0.1 - 0.05 - 0 - 0.0022 = -1.1522 general-ledger-questions: -1 - 0 - 0.15 - 0 - 0.0024 = -1.1524 One boundary miss costs 0.1. Ten characters of span cost 0.10. The pair is a dead tie decided by [truncated for AI cost control]