NationalSecurityAgency

The NSA built a full reverse engineering suite and gave it away for free. It's called Ghidra. THE SAME TOOL THE NSA USES TO TAKE APART MALWARE IS OPEN SOURCE. WHAT COULD YOU TAKE APART WITH IT? nationalsecurityagency/ghidra

Want to make an Enshrouded mod but have no idea where to start? I’m pretty new to modding myself, and one of the most confusing parts was figuring out how to actually get started. My suggestion would be to start with a small mod using EML. Get comfortable finding game data, changing a value, and testing it before worrying about native code or custom multiplayer systems. 1. Pick something small. Slightly modifying an existing feature is a much easier first project than adding a new weapon system or custom interface. It's good if you can describe your idea in one sentence: “I want this recipe to require fewer materials.” That gives you something specific to find, change, and test. You can expand it once that works. Also check whether the game’s world settings already cover what you want. Sometimes you don’t even need a mod. 2. Start with EML and Lua. EML stands for Enshrouded Mod Loader. Making a small Lua mod that changes existing game data is a good place to learn how an Enshrouded mod is put together. These are useful starting points: - EML installation and usage - Setting up a mod project - Writing your first mod Follow the setup instructions for the version you’re using. Get the loader and a known-working mod running before troubleshooting your own script. 3. Keep your tool setup simple. For a first EML mod, you’ll mainly want: - A text editor, such as VS Code. - The documentation and a small example mod. - A test character and world. - Backups of your actual saves. Lua is the scripting language you’ll be working with. You can learn the basics as you go: variables, tables, conditions, functions, and loops. You don’t need to start by learning C++, compiling DLLs, or opening the game in a disassembler. 4. Make sure your mod loads before changing gameplay. Use the template described in the EML setup guide. You’ll see files like these: |File|What's it for| |:-|:-| |mod.json|The mod’s ID, name, version, and required capabilities| |src/mod.lua|Your main script| |README.md|Instructions and notes| |.luarc.json|Lua editor configuration| Your first script can be as simple as: print("Dude your mod loaded!") Check the loader’s output for that message. It’s a small step, but now you know the project is being found and the script is running. If your next change fails, you’ve already ruled that part out. 5. Find the data before changing it. A lot of early modding is working out where the thing you want to change actually lives. The EML tutorial shows how to inspect resources and access their data. The generated Lua definition files can also help you find available fields and understand their structure. Start by printing the resource or value you’re interested in. Once you’ve confirmed it’s the right one, change a single field and test it. Don’t assume a field does what you want just because the name sounds right. Also, changing something on one recipe doesn’t necessarily change every recipe that looks similar. 6. Make one change at a time. For a recipe change, check more than whether the menu looks different: - Does the displayed cost change? - Does crafting consume the correct amount? - Did anything unrelated change? - Does it still work after restarting? Follow the restart requirements for the kind of mod you’re making. Editing a script doesn’t necessarily change data that has already been loaded. Keep a copy of the last version that worked. A dated backup folder is enough to get started; Git is useful once you’re comfortable. When something breaks, being able to go back one change is much easier than trying to remember everything you changed that afternoon. 7. Move to native DLL code when your idea needs it. Eventually, you might want to change something that isn’t exposed through the available data or Lua APIs—such as intercepting a game function or changing more complex behavior while the game is running. That’s where a DLL-based approach can become necessary. You’ll need a way to load your DLL into the game, such as ShroudForge, along with a C++ build setup. Depending on the feature, you may also need to investigate the game’s native functions and memory layouts. Ghidracan be really useful for that. If you’ve never used it, a walkthrough can help you get your bearings. You can also ask an AI tool to explain what you’re looking at, but treat its explanations as things to check rather than proof of what the game does. Be cautious though, native code can crash the game, and addresses or layouts can change after updates. Check what your chosen framework already exposes before writing a native hook. Runtime behavior doesn’t automatically mean you need a custom DLL; it depends on what the available APIs let you do. 8. Learn to use the logs. When something breaks, check whether it’s: - Invalid JSON in the manifest. - A Lua syntax error. - A missing capability. - A resource that wasn’t found. - An API being used in the wrong phase. - The mod not loading at all. An error with a line number gives you somewhere to start. If you get a wall of errors, start with the first one—later errors might just be consequences of it. If you ask for help, include the relevant code, the exact error, your game and loader versions, and what you expected to happen. Mention any other mods you have installed too. 9. Multiplayer is it's own beast. A mod working in singleplayer doesn’t automatically tell you whether it works on a dedicated server or in someone else’s hosted world. Check whether your change needs to run on the client, the host/server, or both. There isn’t one installation rule for every mod. Test with another player when possible. Something can look correct to the host while behaving differently for the person joining. If multiplayer is your goal, test it while the project is still small. 10. Learn from other mods. Small existing mods can be useful examples. Just be sure to give credit where it’s due if you build off of someone else's work. When sharing your own mod, include what it changes, what it requires, installation instructions, and what you actually tested. It’s fine to call something experimental. Definitely share, though. If you wanted something badly enough to make a mod for it, chances are someone else wants it too. Your first mod doesn’t need to do anything groundbreaking. Getting one small change working—and understanding how to undo it—is a good start.

Reverse Engineering Block Blast Block Blast looks like a puzzle game. A decompile of the app suggests it's closer to a per-player ad pricing engine with a puzzle attached. Three tree-based models run on your phone, a bandit experiment tunes when you lose, and a rule decides your next three pieces based on what ad is sitting in memory. The Problem It's Solving The game is free and has no ad-free purchase, so revenue depends on rewarded and full-screen ads. Sensor Tower estimates put its ad revenue at roughly $127 million for January to May 2026, ahead of Candy Crush Saga at $81.1 million. Ad value varies a lot per player (country, device, history), and the best moment to show a rewarded ad is right after a loss. Making that work needs per-player prediction, per-deal control of the pieces, and the ability to change both without shipping an app update. How the System Is Built The research is Ayo Omolewa's breakdown of Android 10.8.2 and iOS 7.4.9, using jadx and Ghidra. The store APK holds very little. Logic ships as "traits" (modules with variants called arms), and at launch the server tells the app which arm of which trait you get. His config named about 700 traits, selected 254, and 101 were fetched after install as XXTEA-encrypted, Brotli-compressed JavaScript. Two players can run different games, and the studio can change yours silently. The Models | Model | Size and inputs | What it decides | |---|---|---| | XGBoost regression (xgboost_regression_model111.json) | 59 trees, depth up to 8, 27 inputs (18 about ads) | finalEcpm: your estimated ad value | | XGBoost classifier (predict_travel_difficulty_dead) | 500 trees, 52 inputs | Where in a level the lethal puzzle lands | | LightGBM | 1,000 trees, 93 inputs | Whether you'll be less active tomorrow | The ad value model. The inputs are mostly money-related: prices of ads loaded today and yesterday, country, phone model, RAM, install date, and how your first game went. The trees lean hardest on first score, latest ad price, RAM, phone model and country. The inference code is a plain loop: start each tree at the root, go left or right on a feature threshold (missing values follow a default direction), add the leaf weight to a running sum starting at the base score. Omolewa's port reproduces the game's outputs to the last decimal. Changing one input on a made-up US player on an iPhone 15 gives: | Change | Ad value (eCPM) | |---|---| | Baseline (US, first score 1,000) | 25.48 | | Brazil | 8.08 | | India | 5.59 | | First score 500 / 2,000 / 10,000 | 25.79 / 21.12 / 20.34 | The same US baseline on Android scores 48.96. The output feeds other rules. One compares your rewarded and full-screen prices and, if rewarded is worth at least twice full-screen in the shipped version, grants an extra revive (which plays a rewarded ad). Others add a full-screen ad when your price is high or skip full-screen ads when you're worth almost nothing. The "where do you lose" model. The game scores 12 candidate options (4 values of a sw_process setting times 3 difficulty levels) and keeps the argmax. Inputs are mostly about your history: current level, attempts, games finished this week, time since install. The winning sw_process maps to a stretch of the level (first 30%, 30 to 80%, last 20%). On reaching it, players who usually accept revives (above 75%) get an extra one, and from the fourth deal after that the game requests the lethal puzzle. Other rules read the same pick the opposite way and make the level easier when it lands on the fourth option. The churn model. If the LightGBM score is 0.69 or higher, a pink revive button replaces the normal one and skips the ad, once a day. It leans on app age, high score, RAM and average score. Server-side models. Rules also call models named for churn, LTV, revive-click and xDeepFM. Those weights never reach the phone, so the only visible part is the request. One call to /v1/ecpm_prediction sends 40 fields, including carrier, storage, hour of day and recent ad prices. The Rules That Act on the Predictions These are hand-written, not learned. RewardHighValueAdHarvestTrait fires when you finished your last three rewarded ads, the ad currently loaded is worth at least 3.5 times your last one (read from AppLovin MAX eCPM), and you're 1,000 points past your high score (500 or 750 in other arms). It then requests generator ZHI_SI_TI. The generator picks two pieces that fit and one that doesn't, searches every order and placement including line clears, and keeps the set only if nothing works. The code labels the pieces "lethal puzzle" in Chinese. PersonalMarginBreakTrait gives every deal a 20% chance of the same hand once you're 10% past your record. MultiClearBoostThenKillTrait sends your user ID to two server endpoints, and for the tiers labelled "not sensitive to being forced to die," waits for a big clear, then requests the lethal puzzle a few rounds later once the game reaches roughly your usual length. FastHandPunishTrait asks for hard pieces when your last six sets averaged under 4.2 seconds and you're past 93% of your high score. MaturityDevelopmentV2Trait scores habit, skill and ad history (10.98, 14.66 and 19.27 in the live test), and when the total (44.91) is under 65 it swaps hard puzzles for easy fills. AdPlusMinusStrategyTrait adds a random bonus of up to 10% of your high score after one type of revive. MABXiBaiTrait is a six-arm experiment on how soon the lethal puzzle may be requested: never, or after 4, 6, 10, about 17 or 30 minutes. Per arm it logs whether you started a new game within 15 minutes and the share of revive offers you accepted. Why This Is a Bigger Deal Than It Looks The ML itself is cheap: tree ensembles walked in a loop over JSON, no GPU, runs on a low-end phone and offline. The engineering is the delivery layer. Server-assigned arms, encrypted hot-loaded JavaScript and per-player A/B tests make this a feature-flag platform with bandit tuning, which is why it can be changed daily. Because the lethal-puzzle rule needs a rewarded ad loaded, it can't fire offline or with a phone-wide DNS blocker, while ad-independent rules keep running. Apple permits JavaScript updates that don't change what the app is. Whether this qualifies is Apple's call. The usual caveat applies: this is one researcher's analysis. mobilegamer.biz reported no reply from Hungry Studio, and TechRadar noted that independent verification matters. The evidence bundles (decoded rules, test scripts, hashes) are public at Ayoships if you want to run the checks yourself. Availability and Access The game is on Google Play and iOS. The decryption key and the steps for getting past the apps' protection aren't published. If a free puzzle game ships three on-device models and a bandit experiment, the real question for developers isn't whether consumer apps use ML. It's how much of their behavior now lives in a config server instead of the binary. Follow for more coverage on MCP, agentic AI, and AI infrastructure. Inspired to write this by @StompnWorldfan's video on YouTube: watch it here.

Ghidra MCP vs REA: How AI Agents Reverse Engineer Software, and What the Setup Changes on Your Machine --- title: Ghidra MCP vs REA: How AI Agents Reverse Engineer Software, and What the Setup Changes on Your Machine published: true date: 2026-10-29 08:00:00 UTC tags: ghidramcp,ghidramcpserver,ghidradecompiler,reaagents canonical_url: alekseialeinikov.com --- !Ghidra MCP vs REA: How AI Agents Reverse Engineer Software, and What the Setup Changes on Your Machine An AI agent that can read compiled code sounds like a party trick until you watch what it replaces: hours of scrolling through decompiler output, renaming FUN_00401a30 to something that means anything, and tracing who calls what. There are now two families of tools that hand that work to an agent. The first is a growing pile of Ghidra MCP servers , bridges that let Claude, Cursor or Codex drive the NSA’s open-source reverse engineering framework. The second is a newcomer called REA (rea-agents on npm), which says it is “one MCP for reverse engineering across binaries, applications, and runtime behavior”. They get lumped together because both end with an agent asking for a decompiled function. They are not the same kind of thing, and they do not change your machine in the same way. This article compares them from the documentation, explains in plain words what each layer does, walks through what the setup actually touches, and ends with the part most posts skip: where the legal lines are. !Ghidra MCP vs REA: a sealed black box cracks open and pours out readable pseudocode while Ghidra plugs in with one cable and REA with a bundle of cables, an illustration of AI reverse engineering. The Short Answer - Want Ghidra’s decompiler inside a chat, for native binaries? Use a Ghidra MCP bridge. GhidraMCP is the simplest start, pyghidra-mcp suits headless and multi-binary projects, ghidra-mcp has the most tools and the most to configure. - Your question crosses formats? An Android app plus its backend traffic, an Electron app, firmware, WebAssembly. REA is built for that, and Ghidra is only one of its engines. - Care about knowing what was proven? REA’s docs make evidence and limitations first-class. A static call graph is labelled as static, an empty result is not read as “does not exist”. - Care about a small footprint? A Ghidra bridge adds a plugin and a local port. REA edits your agent’s global configuration. Both are reversible, neither is nothing. - Analyzing unknown malware? Do it in an isolated VM, with either tool, and with no credentials on the box. More on why below. What Is a Ghidra MCP Server? Engine, Bridge, Agent Three words get mixed up, so it is worth separating them. A disassembler turns machine code into assembly instructions. A decompiler goes one step further and reconstructs C-like pseudocode from those instructions. The pseudocode compiles to nothing and is not the original source: names are gone, types are guessed, loops are inferred. That matters later. Ghidra is the engine, and its decompiler is the part an AI agent leans on most. It is a software reverse engineering framework created and maintained by the NSA Research Directorate, with disassembly, assembly, decompilation, graphing and scripting, support for a wide range of processor instruction sets and executable formats, and both user-interactive and automated modes. You can extend it in Java or Python. MCP (the Model Context Protocol) is the plug that lets an agent call tools. If the idea is new, the MCP gateway article explains why every MCP server is a place where an agent gains real capabilities. A Ghidra MCP server is therefore a translator between two worlds: the agent speaks MCP, Ghidra speaks Java and Python. The agent says “decompile the function at this address”, the bridge asks Ghidra, Ghidra answers, the agent reads and reasons. That loop, repeated a few hundred times with renames in between, is what turns FUN_00401a30 into verify_license_key. Ghidra MCP Servers Compared: GhidraMCP vs ghidra-mcp vs pyghidra-mcp Search for “ghidra mcp” and you will find several projects with similar names. Three lead by GitHub stars, and smaller ones exist, such as mrphrazer’s ghidra-headless-mcp. Two of the three shipped major releases this month: GhidraMCP 2.0 on October 10 and ghidra-mcp 7.0.0 on October 21. They share the engine and differ in how they reach it. | | GhidraMCP (LaurieWired) | ghidra-mcp (bethington) | pyghidra-mcp (clearbluejar) | | --- | --- | --- | --- | | GitHub stars | about 11.6k, created March 2025 | about 6k, created August 2025 | about 455, created July 2025 | | Licence | Apache-2.0 | Apache-2.0 | Apache-2.0 | | Shape | Ghidra plugin plus a Python MCP bridge | Rewrite of the above: Python bridge, HTTP REST, Java plugin | Headless-first, runs Ghidra in the same JVM through pyghidra and JPype | | Needs Ghidra GUI running | Yes, with an optional headless mode through PyGhidra | Yes for the full tool set, a headless server exists with fewer endpoints | No, it has a --gui mode but cannot attach to a running Ghidra | | Scope | Decompile, rename methods and data, list methods, classes, imports, exports | 219 MCP tools by the project’s own count | Project-wide analysis, semantic code search, xrefs, call graphs | | Transport | stdio and streamable HTTP | stdio and streamable HTTP | streamable HTTP recommended | | Requires | Ghidra 12.1.4, uv | Ghidra 12.1.4, Java 21, uv | pyghidra, Python | Three details from those READMEs are worth knowing before you pick one. The architecture is a chain, and every link is a process. In ghidra-mcp, the agent talks to a Python MCP bridge over stdio or streamable HTTP, the bridge talks to a Java plugin inside Ghidra over an HTTP REST API on localhost port 8089, and Ghidra does the analysis. GhidraMCP uses the same pattern with its HTTP server on localhost port 8080. The practical meaning: there is a local network port on your machine that can read and, in some tools, modify your analysis database. Both projects bind to localhost by default, and ghidra-mcp requires an auth token (GHIDRA_MCP_AUTH_TOKEN) if you bind to anything else. More tools is not automatically better for the agent. ghidra-mcp ships 219 tools (the GUI plugin serves 216 of them, the headless server 201). Its README documents an unusual consequence: Gemini rejects the full tool schema with a 400 INVALID_ARGUMENT “too many states” error. So the project loads tools lazily by default, 70 endpoints plus 8 static tools in the listing, function and program groups, and the agent pulls in more groups on demand. That is a good illustration of a real limit: every tool description costs context and every client has a tolerance. Dangerous capabilities are opt-in, which is the right default. Since version 5.4.1 of ghidra-mcp, the script execution endpoints are off unless you set GHIDRA_MCP_ALLOW_SCRIPTS, and the README says plainly that they “execute arbitrary Java against the Ghidra process”. There is also a GHIDRA_MCP_FILE_ROOT setting to restrict file access. Its other headline features, per its own README: write tools for renaming, typing, structs and comments, P-code emulation, debugger integration through TraceRmi (GUI only), malware-oriented tools such as detect_malware_behaviors and extract_iocs_with_context, cross-binary documentation transfer by function hash, Ghidra Server integration and a Docker headless setup. The README also claims “3x more than any competing implementation” and “93% fewer API calls” through batching. Those are the project’s own claims. pyghidra-mcp thinks in projects, not single binaries. It can analyze every binary in a Ghidra project concurrently, searches code semantically with a ChromaDB vector index, generates call graphs as Mermaid, decompiles in batches, and ships a CLI client and a Docker image. That is the better fit for “here are 40 binaries from one firmware, find the one that parses the config”. > “Ghidra MCP” is a category, not a product. Pick by shape: plugin plus GUI (GhidraMCP), maximum tools (ghidra-mcp) or headless and project-wide (pyghidra-mcp). The engine, and therefore the quality of the decompilation, is the same. What Is REA (rea-agents)? One MCP for Many Targets REA (github.com/morluto/rea, site rea.tools) is MIT licensed and distributed as the npm package rea-agents. It is a different shape of tool: an MCP server, a command-line tool called rea and an agent skill called reverse-engineer-anything, all in one package. Its pitch is breadth. The documented targets include: - native binaries, ELF layout, Go, Rust and IL2CPP - WebAssembly and EVM bytecode - GGUF and safetensors model files, SQLite databases - JavaScript and Electron apps (modules, IPC, source maps) and live websites through Chrome - HAR and SAZ captures, packets through TShark - .NET assemblies, Android APKs through JADX, ADB, Flutter - firmware through Binwalk and Unblob, PyInstaller bundles - process behavior at runtime For native code, REA does not reinvent the decompiler. It calls one: Ghidra 12.x (12.1 or newer) with a full 64-bit JDK, Hopper (commercial), IDA or Kuna, plus objdump and Rizin. It requires an existing Ghidra install and never installs Ghidra itself. So the honest relationship is not “REA vs Ghidra” but “REA on top of Ghidra, among others”. If you point REA’s Ghidra provider at a binary, you get Ghidra’s decompiler either way. What sets REA apart is less the tool list than the contract it puts on every answer. Its native investigation docs repeat the same discipline in many places: - A result carries Evidence and explicit limitations. Unknown means unknown, not false. - “An empty Hopper inventory cannot establish that no such call exists.” - A static call route “does not establish runtime reachability”. - Decompiler pseudocode is never treated as original source. - Static references enumerated by the analyzer “are not observed runtime reads or writes”. For an agent, that contract is the point. Language models want to give a clean answer. A tool whose output says “this is a static observation, completeness unknown” gives the model less room to overclaim, and gives you something to check. On the Ghidra side specifically, REA’s adapter is deliberately conservative. It exposes 27 operations, all read-only: 15 for inventory, names and search, and 12 for function analysis. It opens the target in an ephemeral project (-readOnly -deleteProject), and name and comment edits are session metadata that is discarded when the session closes. The default startup deadline is 330 seconds. Windows support is marked experimental. If that reads like a trade-off, it is one: you give up Ghidra’s full write surface for a smaller, auditable one. REA’s showcase examples show the intended style: finding why a Chrome dino game’s speed starts at 6 and rises while below 13, tracing the % button of Windows Calculator (200 + 10% = 220), recovering an Electron app’s clipboard bridge, reproducing 63 compiled function bytes of a DX-Ball sound routine against 3,205 original-x86 test cases. These are demonstrations from the project, not independent results. A quick note on REA’s numbers. GitHub shows about 404,000 stars for a repository created in April, and npm has 34 releases since July 12 (6.8.0 on October 25). How the stars accumulated can’t be checked, so judge REA by its docs and code. It is also essentially a one-maintainer project, with about 3,800 of roughly 6,200 commits from one developer, so pin the version you tested. Ghidra MCP vs REA Side by Side !Ghidra MCP vs REA architecture: a Ghidra bridge connects the agent to one Ghidra engine through a Python bridge, a local HTTP port and a plugin; REA connects the agent to one MCP server with provider adapters for Ghidra, Hopper, IDA, JADX, Chrome and more, and returns Evidence with limitations. _One engine behind a bridge, or a toolbench behind one server._ | | Ghidra MCP bridges | REA | | --- | --- | --- | | What it is | Adapter between an agent and Ghidra | MCP server, CLI and skill over many engines | | Targets | What Ghidra imports: native binaries, many architectures | Native, Android, JS and Electron, .NET, firmware, WASM, packets, runtime and more | | Decompiler | Ghidra | Ghidra, Hopper, IDA or Kuna for native code | | Interface to the engine | Plugin plus local HTTP, or headless through PyGhidra | Provider adapters, Ghidra in an ephemeral read-only project | | Write access | Yes: rename, retype, comment, structs, depending on the project | Ghidra adapter read-only; annotations live in a temporary session | | Scripts | Script execution endpoints exist, off by default in ghidra-mcp | Not part of the Ghidra adapter described in the docs | | How results are framed | Raw tool output, the agent interprets | Evidence, coverage and limitations on every result | | Runtime analysis | ghidra-mcp: emulation and a GUI-only debugger | Opt-in runtime capture; LLDB call observation launches an owned process | | Install effort | Install Ghidra, an extension or Python package, match versions | npx rea-agents setup plus an existing Ghidra if you want native analysis | | Maturity signal | Three independent projects, the oldest from March 2025 | One project, first release July 2026, fast release cadence | | Licence | Apache-2.0 (GhidraMCP, ghidra-mcp) | MIT | How AI Reverse Engineering Works: What the Agent Actually Does The two families share the same loop. Only the commands differ. With a Ghidra bridge , the agent works the way a human would in the CodeBrowser. It lists functions, imports and strings, decompiles the interesting ones, follows cross-references, renames what it understands and writes comments. Because the writes land in the open Ghidra database, a good session leaves behind an annotated project you can open afterwards. With REA , the documented native workflow is explicit about picking exact names. From its docs, with the Ghidra provider: _Terminal window_ rea inspect /absolute/path/to/program --provider ghidra --json rea search /absolute/path/to/program entry --kind procedures --provider ghidra --json rea function /absolute/path/to/program <procedure> --provider ghidra --json rea decompile /absolute/path/to/program <procedure> --provider ghidra <button title="Copy to clipboard" data-copied="Copied!" data-code="rea inspect /absolute/path/to/program --provider ghidra --jsonrea search /absolute/path/to/program entry --kind procedures --provider ghidra --jsonrea function /absolute/path/to/program &lt;procedure&gt; --provider ghidra --jsonrea decompile /absolute/path/to/program &lt;procedure&gt; --provider ghidra"><div></div></button> The docs add a small warning that is easy to miss and typical for the project: do not assume every target names its entry function entry; pick an exact name or address from the returned inventory. Over MCP the same flow is open_binary, then focused tools such as list_procedures and analyze_function on the same session. Beyond that: - batch_decompile reads several functions at once, and decompile_all writes one pseudocode file per function plus a manifest that contains counts but no code. - search_bytes finds masked byte patterns and says what it did not search, for example uninitialized blocks. - trace_native_values builds def-use graphs from the decompiler’s high p-code across statically resolved calls. - export_evidence_bundle keeps the observations so a conclusion can be reviewed later without trusting the chat. The last item is the quiet strength. A transcript of an agent saying “this function validates a licence key” is a claim. An evidence bundle with the addresses, references and limitations behind it is something a second person can check. Ghidra MCP and REA Setup: What Changes on Your Machine This is the section most comparisons skip, and the one that should decide whether you try something. Everything below is from the projects’ docs. Ghidra bridges Typical flow: install a JDK and the exact Ghidra release the extension was built for (the READMEs name Ghidra 12.1.4), install the plugin zip through File, Install Extensions , enable it in the configuration, restart Ghidra, then register the MCP server with your client, for example with uvx --from git+https://github.com/LaurieWired/GhidraMCP ghidra-mcp --ghidra-server http://127.0.0.1:8080/. What changes: - a plugin inside Ghidra, which loads only in the exact Ghidra version it was built for - a local HTTP server on a fixed port while Ghidra runs - an entry in your agent’s MCP configuration - a Python process started on demand, with uvx fetching code from a Git URL at run time, which is worth pinning to a commit or tag Note a version tension: the Ghidra README for its current master branch asks for JDK 25, while the bridge projects document Ghidra 12.1.4 and Java 21. Match them to the bridge’s README rather than to the newest Ghidra. REA npx rea-agents setup is the documented entry point. According to the install docs: 1. It first prints a plan that lists config file paths, skill destinations, external software it might need, network origins, integrity evidence and package-manager commands. 2. It writes nothing until you approve. Approving the plan is separate from your approval of the npm download itself. 3. It makes .rea.backup copies of config files before editing, preserves unrelated entries, and treats a malformed config as a reason to block the whole transaction instead of guessing. 4. For Claude Code it registers mcpServers.rea in ~/.claude.json and installs the skill in ~/.claude/skills/reverse-engineer-anything. You choose the clients in a multi-select. Existing REA registrations are preselected, newly detected clients are not, because detection gives setup context, not permission. The skill is installed by default and --skill=false skips it. If you use Claude Desktop, quit it fully before approving, since a running app can overwrite the registration. More than two dozen client identifiers are supported, including Claude Code and Desktop, Codex, Cursor, Gemini CLI, Windsurf, VS Code, Copilot CLI and OpenCode, and there is a plugin route (/plugin marketplace add morluto/rea) and an MCP Registry entry, io.github.morluto/rea. What deserves attention, again straight from the docs: - The registration is global. For Claude Code, the entry and the skill apply to every project. The docs describe limiting that with a separate CLAUDE_CONFIG_DIR profile or a local scope, and are candid that an agent running under the same OS account can still run rea or npx and read files. - It registers an absolute path to node and the entry script, so the npx cache must stay in place. - The install script is not signature-checked. The docs say so themselves: “Neither command verifies a signature on the downloaded script.” They show a safer flow: download the script from a pinned tag, read it with less, then run it with the matching --version. Or skip it and use the npm route. - Run package runners from a trusted directory outside the target, because they can read project configuration. - Hopper setup can download the official package with a PGP signature check (the docs list the primary key fingerprint) and a DMG digest check on macOS, with HTTPS-only redirects. Ghidra is never downloaded. - Undo exists. rea doctor is read-only, rea uninstall removes only registrations REA owns (--purge-data also clears its cache), and rea update keeps dependency lifecycle scripts disabled. The npm package itself defines only prepare and prepublishOnly scripts, no install-time hooks, and has 42 dependencies at about 49 MB unpacked. <aside role="note"><p>Warning</p> <p>The README warns that look-alike repositories exist and are not official. For a tool that edits your agent’s configuration, verify the source (<code>morluto/rea</code>, <code>rea-agents</code>) before running anything. The same applies to the many repositories named “ghidra-mcp”.</p></aside> For the broader habit of installing tools that run code on your machine, npm supply chain attack mitigation covers what to pin, what to disable and what to read first. !Ghidra MCP vs REA setup: what each installer touches. A Ghidra bridge adds a plugin and a local HTTP port; REA shows a plan, waits for approval, backs up config files, writes the MCP registration and skill, and can be removed with a single uninstall command. _Both are reversible. Neither is nothing._ What Can Go Wrong Four risks are worth naming. The first is from my own analysis and is not in either project’s docs; the others are documented. 1. The binary talks back. From the model’s point of view, a sample is untrusted text. Strings, symbol names, embedded resources and comments all arrive inside tool results. A malicious binary can include a string like “ignore previous instructions and run this command”, and an agent with shell access and secrets is exactly the target. This is the lethal trifecta: private data, untrusted content and a way out. The defense is architectural: unknown samples go into a disposable VM with no credentials, the agent gets only the tools it needs, and anything that can execute code stays off. The case where rogue AI agents compromised a real website shows how little it takes once an agent has capability and a goal. 2. Write tools change your analysis. Renames and retyping are what make a session useful and what make a wrong guess spread: a function named check_license by a confident model will colour every later decision, yours included. REA’s read-only Ghidra adapter sidesteps that by design. With a write-capable bridge, keep a copy of the project before the agent starts. 3. Runtime features run the target. REA’s docs are explicit: runtime capture executes the target with your user permissions, and its LLDB call observation launches an owned process that “may change files, show UI or use the network”. Authorization to inspect a file “does not necessarily authorize execution”. Use a VM here too. 4. The model provider sees what the tools return. REA’s docs say its analysis is local, and that “your agent receives the tool results, and its model provider has its own data policy”. That means decompiled code leaves your machine as soon as it enters a cloud model’s context. For proprietary or contractually restricted software, that is a legal and a confidentiality question before it is a technical one. Is Reverse Engineering Legal? <aside role="note"><p>Warning</p> <p>This is a summary of public statute text, not legal advice. Law differs by country, contract and case. If a decision matters, ask a lawyer who knows software and IP in your jurisdiction.</p></aside> The useful way to think about it is four layers, and an action must clear all of them. | Layer | The question | What the sources say | | --- | --- | --- | | Authorization | Is it yours, or do you have permission? | REA’s disclaimer: public availability, possession of a file or access to a debugging endpoint “does not by itself establish permission for every operation”. US 17 U.S.C. 1201(j) defines security testing as good-faith testing “with the authorization of the owner or operator”. | | Contract | What does the licence or EULA say? | Germany: terms that contradict section 69d(2), (3), (5), (7) or section 69e UrhG are void (section 69g(2)). The US position on EULA restrictions was not researched for this article. | | Copyright and access controls | Is there a statutory exception? | US 1201(f) for interoperability; Germany section 69e for decompilation and section 69d(3) for studying a program; EU Directive 2009/24/EC behind the German rules. | | Tool policy | What does the tool refuse to help with? | REA will not help with DRM or licence circumvention, game cheats, bypassing access controls, copying proprietary code or evading AI providers’ usage policies. | United States. Section 1201 of the Copyright Act is about circumventing technical protection measures that control access to a work. Its reverse engineering exception, 1201(f), lets a person who lawfully obtained the right to use a copy of a computer program circumvent such a measure “for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs”, where those elements were not previously readily available, “to the extent any such acts of identification and analysis do not constitute infringement”. The tools to do it, and the information gained, may be shared only for interoperability. Separately, 1201(c)(1) says the section does not affect fair use or other defenses to infringement. Note what this is not: a general permission to disassemble anything for any reason. Germany and the EU. The German rules implement the EU computer programs directive, 2009/24/EC, which replaced the original 1991 directive. Section 69d(3) UrhG says a person entitled to use a copy may “observe, study or test the functioning” of the program to determine the ideas and principles behind its elements, if this happens through acts of loading, displaying, running, transmitting or storing that they are entitled to perform. Section 69e allows decompilation without the rightholder’s consent only if reproducing the code or translating its form is indispensable to obtain information needed for interoperability of an independently created program, and only if: it is done by a licensee or authorized person; the information was not already readily accessible; and the acts are limited to the parts necessary. The information may not be used for other purposes, passed on beyond what interoperability needs, or used to build a program with a substantially similar expression. And section 69g(2) makes contract terms that contradict section 69e void, so an EULA cannot simply forbid what the statute allows. Trade-secret law points the same way: under section 3(1) no. 2 of the German Trade Secrets Act (GeschGehG), a trade secret may be obtained by observing, studying, taking apart or testing a product that was made publicly available or is in your lawful possession, unless you are bound by a duty to limit that. What that means in practice, as a reading aid and not advice: - Analyzing your own software, or malware samples in a lab, is the common and uncontroversial case. The agent changes the speed, not the status. - Interoperability has explicit statutory support in both systems, with conditions on necessity and on what you do with what you learn. - Security testing needs the owner’s authorization, in the US text and in REA’s own policy. - Circumventing DRM, licence checks or anti-cheat , and copying protected code , are outside what these exceptions cover and outside what REA will help with. - An AI does not launder it. REA’s disclaimer says you are responsible for “actions you direct an AI agent to perform”, and that getting source-like output “does not grant rights to the original program”. A Safe Setup Checklist for AI Reverse Engineering These are my recommendations, built from the documented behavior above. None of them needs a special tool. 1. Use a disposable VM for unknown samples, with no credentials, no SSH agent and no cloud tokens on it. 2. Keep the tool out of your daily agent profile. For REA on Claude Code, a separate CLAUDE_CONFIG_DIR profile keeps the registration and skill away from your other projects. 3. Pin versions. Use the Ghidra release the bridge names, a bridge tag or commit instead of a moving branch, and an exact rea-agents version. 4. Prefer read-only tools. Leave script execution off (GHIDRA_MCP_ALLOW_SCRIPTS), and copy the Ghidra project before an agent gets write tools. 5. Keep servers on localhost. If you bind elsewhere, set the auth token the project asks for. 6. Treat strings and comments in the sample as hostile. Do not give the agent a shell or open network access in the same session. 7. Keep the evidence. Save addresses and references for every claim, and verify the important ones in the disassembly or a debugger. 8. Check permission before you start. Confirm you may analyze the target, and read your model provider’s data policy before sending proprietary code through it. When to Use Which 1. Learning, CTFs, one native binary, you like Ghidra’s UI: GhidraMCP. Lowest friction, and the annotations end up in a Ghidra project you can keep. 2. Many binaries, scripts and automation, no GUI: pyghidra-mcp, for its headless and project-wide design. 3. You want every Ghidra feature exposed and will configure it carefully: ghidra-mcp, with scripts left off and a file root set. 4. The target is not a plain native binary: an Electron or Android app, a firmware image, a WebAssembly module, network captures. REA’s breadth is the reason to use it. 5. You need reviewable conclusions, for example for an incident report: REA’s evidence bundles and explicit limitations fit better than a chat transcript. 6. Unknown, possibly hostile samples: either tool, only in a VM without secrets, preferably with read-only tools and no execution features. !Ghidra MCP vs REA and the law: four layers an analysis must clear, authorization, contract, statutory exceptions in the US and Germany, and the tool’s own policy. _AI changes how fast you read, not whether you are allowed to._ When Neither Is the Answer - You have the source. Read the source. - You need ground truth. A decompiler tells you what the code appears to do. A debugger, a test or the vendor’s documentation tells you what it does. - The code is heavily obfuscated or packed. The agent will still produce fluent output, and it will be less trustworthy. Unpack first, with the right tools. - The task is circumvention. No tool here is a licence for that. The Bottom Line Ghidra MCP and REA answer different questions. A Ghidra MCP server answers “how do I let my agent drive the decompiler I already use?”, and three decent open-source projects exist for it. REA answers “how do I let an agent investigate anything compiled or packaged, and make the answer say how much it proves?”, at the price of a broader integration with your agent’s configuration. REA also uses Ghidra when you ask it to, so the two are less rivals than neighbouring layers. What does not change is the shape of the risk. The agent reads untrusted input, the tools can write or execute, a cloud model sees the output, and the law cares about permission and purpose. The best setup is the boring one: a disposable VM, read-only tools, pinned versions, a saved evidence trail and a clear answer to “am I allowed to do this?”. > If you are connecting agents to tools in a team, how an MCP gateway enforces user-level permissions is the control layer that sits above any single server. Sources - REA: GitHub repository, rea.tools, rea-agents on npm - Ghidra: NationalSecurityAgency/ghidra - Ghidra MCP: GhidraMCP, ghidra-mcp, pyghidra-mcp - Law: 17 U.S.C. 1201, UrhG sections 69d, 69e, 69g, GeschGehG section 3, Directive 2009/24/EC _Originally published at alekseialeinikov.com_

Ghidra MCP vs REA: Wie KI-Agenten Software per Reverse Engineering analysieren und was das Setup auf deinem Rechner verändert --- title: Ghidra MCP vs REA: Wie KI-Agenten Software per Reverse Engineering analysieren und was das Setup auf deinem Rechner verändert published: true date: 2026-10-29 08:00:00 UTC tags: ghidramcp,ghidramcpserver,ghidradecompiler,reaagents canonical_url: alekseialeinikov.com --- !Ghidra MCP vs REA: Wie KI-Agenten Software per Reverse Engineering analysieren und was das Setup auf deinem Rechner verändert Ein KI-Agent, der kompilierten Code lesen kann, klingt nach Partytrick, bis man sieht, was er ersetzt: Stunden im Scrollen durch Decompiler-Ausgabe, das Umbenennen von FUN_00401a30 in etwas, das irgendeine Bedeutung hat, und das Nachverfolgen, wer wen aufruft. Heute gibt es zwei Werkzeugfamilien, die diese Arbeit an einen Agenten übergeben. Die erste ist ein wachsender Haufen von Ghidra-MCP-Servern , Brücken, über die Claude, Cursor oder Codex das Open-Source-Reverse-Engineering-Framework der NSA steuern. Die zweite ist ein Neuling namens REA (rea-agents auf npm), der sich als „one MCP for reverse engineering across binaries, applications, and runtime behavior“ beschreibt. Beide werden in einen Topf geworfen, weil am Ende ein Agent eine dekompilierte Funktion anfordert. Sie sind aber nicht dieselbe Art Werkzeug, und sie verändern deinen Rechner nicht auf dieselbe Weise. Dieser Artikel vergleicht sie anhand der Dokumentation, erklärt in einfachen Worten, was jede Schicht tut, geht durch, was das Setup tatsächlich anfasst, und endet mit dem Teil, den die meisten Beiträge auslassen: wo die rechtlichen Grenzen verlaufen. !Ghidra MCP vs REA: Eine versiegelte Black Box bricht auf und gibt lesbaren Pseudocode frei, Ghidra steckt mit einem Kabel an, REA mit einem Kabelbündel, eine Illustration von KI-Reverse-Engineering. Die kurze Antwort - Du willst Ghidras Decompiler im Chat, für native Binärdateien? Nimm eine Ghidra-MCP-Brücke. GhidraMCP ist der einfachste Einstieg, pyghidra-mcp passt zu Headless und Projekten mit mehreren Binärdateien, ghidra-mcp hat die meisten Tools und am meisten zu konfigurieren. - Deine Frage überschreitet Formate? Eine Android-App samt Backend-Verkehr, eine Electron-App, Firmware, WebAssembly. Dafür ist REA gebaut, und Ghidra ist nur eine seiner Engines. - Dir ist wichtig, was bewiesen wurde? REAs Doku macht Belege und Einschränkungen zu Kernelementen. Ein statischer Aufrufgraph wird als statisch bezeichnet, ein leeres Ergebnis nicht als „existiert nicht“ gelesen. - Dir ist ein kleiner Fußabdruck wichtig? Eine Ghidra-Brücke fügt ein Plugin und einen lokalen Port hinzu. REA ändert die globale Konfiguration deines Agenten. Beides ist rückgängig zu machen, keines ist nichts. - Du analysierst unbekannte Malware? Mach das in einer isolierten VM, mit jedem der Werkzeuge, ohne Zugangsdaten auf der Kiste. Warum, steht weiter unten. Was ist ein Ghidra-MCP-Server? Engine, Brücke, Agent Drei Begriffe werden oft vermischt, deshalb lohnt sich die Trennung. Ein Disassembler übersetzt Maschinencode in Assembler-Anweisungen. Ein Decompiler geht einen Schritt weiter und rekonstruiert aus diesen Anweisungen C-ähnlichen Pseudocode. Dieser Pseudocode lässt sich nicht einfach kompilieren und ist nicht der Originalquelltext: Namen fehlen, Typen sind geraten, Schleifen sind erschlossen. Das wird später wichtig. Ghidra ist die Engine, und ihr Decompiler ist der Teil, auf den sich ein KI-Agent am meisten stützt. Es ist ein Software-Reverse-Engineering-Framework (SRE), das von der NSA Research Directorate entwickelt und gepflegt wird, mit Disassemblierung, Assemblierung, Dekompilierung, Graphen und Skripting, Unterstützung für viele Prozessor-Befehlssätze und Dateiformate sowie interaktivem und automatisiertem Betrieb. Erweitern lässt es sich in Java oder Python. MCP (Model Context Protocol) ist der Stecker, über den ein Agent Tools aufruft. Falls die Idee neu ist: Der Artikel zum MCP-Gateway erklärt, warum jeder MCP-Server ein Ort ist, an dem ein Agent echte Fähigkeiten erhält. Ein Ghidra-MCP-Server ist deshalb ein Übersetzer zwischen zwei Welten: Der Agent spricht MCP, Ghidra spricht Java und Python. Der Agent sagt „dekompiliere die Funktion an dieser Adresse“, die Brücke fragt Ghidra, Ghidra antwortet, der Agent liest und schlussfolgert. Diese Schleife, einige hundert Mal mit Umbenennungen dazwischen, macht aus FUN_00401a30 ein verify_license_key. Ghidra-MCP-Server im Vergleich: GhidraMCP vs ghidra-mcp vs pyghidra-mcp Wer nach „ghidra mcp“ sucht, findet mehrere Projekte mit ähnlichen Namen. Drei Projekte führen nach GitHub-Sternen, und es gibt kleinere wie mrphrazers ghidra-headless-mcp. Zwei der drei haben diesen Monat Major-Releases veröffentlicht: GhidraMCP 2.0 am 10. Oktober und ghidra-mcp 7.0.0 am 21. Oktober. Sie teilen sich die Engine und unterscheiden sich darin, wie sie sie erreichen. | | GhidraMCP (LaurieWired) | ghidra-mcp (bethington) | pyghidra-mcp (clearbluejar) | | --- | --- | --- | --- | | GitHub-Sterne | rund 11,6k, erstellt März 2025 | rund 6k, erstellt August 2025 | rund 455, erstellt Juli 2025 | | Lizenz | Apache-2.0 | Apache-2.0 | Apache-2.0 | | Aufbau | Ghidra-Plugin plus Python-MCP-Brücke | Neuentwicklung auf dieser Basis: Python-Brücke, HTTP-REST, Java-Plugin | Headless zuerst, Ghidra läuft in derselben JVM über pyghidra und JPype | | Ghidra-GUI nötig | Ja, optionaler Headless-Modus über PyGhidra | Ja für den vollen Tool-Satz, ein Headless-Server mit weniger Endpunkten existiert | Nein, es gibt einen --gui-Modus, aber ein Anhängen an ein laufendes Ghidra ist nicht möglich | | Umfang | Dekompilieren, Methoden und Daten umbenennen, Methoden, Klassen, Importe, Exporte auflisten | 219 MCP-Tools nach eigener Zählung | Projektweite Analyse, semantische Codesuche, Xrefs, Aufrufgraphen | | Transport | stdio und Streamable HTTP | stdio und Streamable HTTP | Streamable HTTP empfohlen | | Voraussetzungen | Ghidra 12.1.4, uv | Ghidra 12.1.4, Java 21, uv | pyghidra, Python | Drei Details aus diesen READMEs solltest du kennen, bevor du dich entscheidest. Die Architektur ist eine Kette, und jedes Glied ist ein Prozess. Bei ghidra-mcp spricht der Agent über stdio oder Streamable HTTP mit einer Python-MCP-Brücke, die Brücke spricht über eine HTTP-REST-API auf localhost Port 8089 mit einem Java-Plugin in Ghidra, und Ghidra analysiert. GhidraMCP nutzt dasselbe Muster mit seinem HTTP-Server auf localhost Port 8080. Praktisch heißt das: Auf deinem Rechner gibt es einen lokalen Netzwerkport, der deine Analysedatenbank lesen und in manchen Tools auch verändern kann. Beide Projekte binden standardmäßig an localhost, und ghidra-mcp verlangt ein Auth-Token (GHIDRA_MCP_AUTH_TOKEN), sobald du an etwas anderes bindest. Mehr Tools ist für den Agenten nicht automatisch besser. ghidra-mcp liefert 219 Tools (das GUI-Plugin bedient 216 davon, der Headless-Server 201). Sein README dokumentiert eine ungewöhnliche Folge: Gemini lehnt das vollständige Tool-Schema mit dem Fehler 400 INVALID_ARGUMENT („too many states“) ab. Deshalb lädt das Projekt Tools standardmäßig lazy, 70 Endpunkte plus 8 statische Tools in den Gruppen listing, function und program, und der Agent holt weitere Gruppen bei Bedarf nach. Das ist ein gutes Beispiel für eine echte Grenze: Jede Tool-Beschreibung kostet Kontext, und jeder Client hat eine Toleranzgrenze. Gefährliche Fähigkeiten sind Opt-in, und das ist die richtige Voreinstellung. Seit Version 5.4.1 von ghidra-mcp sind die Endpunkte zur Skriptausführung aus, solange du nicht GHIDRA_MCP_ALLOW_SCRIPTS setzt, und das README sagt klar, dass sie „execute arbitrary Java against the Ghidra process“. Mit GHIDRA_MCP_FILE_ROOT lässt sich der Dateizugriff einschränken. Weitere Hauptmerkmale laut README: Schreib-Tools für Umbenennen, Typisieren, Strukturen und Kommentare, P-Code-Emulation, Debugger-Anbindung über TraceRmi (nur GUI), malware-orientierte Tools wie detect_malware_behaviors und extract_iocs_with_context, Übertragung von Dokumentation zwischen Binärdateien über Funktions-Hashes, Ghidra-Server-Integration und ein Docker-Headless-Setup. Das README behauptet außerdem „3x more than any competing implementation“ und „93% fewer API calls“ durch Batching. Das sind Eigenangaben des Projekts. pyghidra-mcp denkt in Projekten, nicht in einzelnen Binärdateien. Es kann alle Binärdateien eines Ghidra-Projekts parallel analysieren, durchsucht Code semantisch mit einem ChromaDB-Vektorindex, erzeugt Aufrufgraphen als Mermaid, dekompiliert im Batch und bringt einen CLI-Client und ein Docker-Image mit. Das passt besser zu „hier sind 40 Binärdateien aus einer Firmware, finde die, die die Konfiguration parst“. > „Ghidra MCP“ ist eine Kategorie, kein Produkt. Wähle nach Bauform: Plugin plus GUI (GhidraMCP), maximale Tool-Zahl (ghidra-mcp) oder Headless und projektweit (pyghidra-mcp). Die Engine, und damit die Qualität der Dekompilierung, ist dieselbe. Was ist REA (rea-agents)? Ein MCP für viele Ziele REA (github.com/morluto/rea, Website rea.tools) steht unter MIT-Lizenz und wird als npm-Paket rea-agents verteilt. Es ist ein anderer Werkzeugtyp: ein MCP-Server, ein Kommandozeilenwerkzeug namens rea und ein Agenten-Skill namens reverse-engineer-anything, alles in einem Paket. Das Versprechen ist Breite. Dokumentierte Ziele sind unter anderem: - native Binärdateien, ELF-Layout, Go, Rust und IL2CPP - WebAssembly und EVM-Bytecode - GGUF- und safetensors-Modelldateien, SQLite-Datenbanken - JavaScript- und Electron-Apps (Module, IPC, Source Maps) und Live-Websites über Chrome - HAR- und SAZ-Mitschnitte, Pakete über TShark - .NET-Assemblies, Android-APKs über JADX, ADB, Flutter - Firmware über Binwalk und Unblob, PyInstaller-Bündel - Prozessverhalten zur Laufzeit Für nativen Code erfindet REA den Decompiler nicht neu, sondern ruft einen auf: Ghidra 12.x (ab 12.1) mit einem vollständigen 64-Bit-JDK, Hopper (kommerziell), IDA oder Kuna, dazu objdump und Rizin. Es verlangt eine vorhandene Ghidra-Installation und installiert Ghidra nie selbst. Das ehrliche Verhältnis lautet also nicht „REA gegen Ghidra“, sondern „REA auf Ghidra, neben anderen“. Wenn du REAs Ghidra-Provider auf eine Binärdatei richtest, bekommst du so oder so Ghidras Decompiler. Was REA unterscheidet, ist weniger die Werkzeugliste als der Vertrag, den es jeder Antwort auferlegt. Die Doku zur nativen Analyse wiederholt dieselbe Disziplin an vielen Stellen: - Ein Ergebnis trägt Evidence (Belege) und ausdrückliche Limitations. Unbekannt heißt unbekannt, nicht falsch. - „An empty Hopper inventory cannot establish that no such call exists.“ - Ein statischer Aufrufpfad „does not establish runtime reachability“. - Decompiler-Pseudocode gilt nie als Originalquelltext. - Vom Analysator aufgezählte statische Referenzen „are not observed runtime reads or writes“. Für einen Agenten ist dieser Vertrag der Kern. Sprachmodelle wollen eine saubere Antwort geben. Ein Werkzeug, dessen Ausgabe sagt „das ist eine statische Beobachtung, Vollständigkeit unbekannt“, lässt dem Modell weniger Spielraum zum Übertreiben und gibt dir etwas zum Nachprüfen. Speziell auf der Ghidra-Seite ist REAs Adapter bewusst konservativ. Er bietet 27 Operationen, alle schreibgeschützt: 15 für Inventar, Namen und Suche, 12 für Funktionsanalyse. Das Ziel wird in einem flüchtigen Projekt geöffnet (-readOnly -deleteProject), und Umbenennungen und Kommentare sind Sitzungs-Metadaten, die beim Schließen der Sitzung verworfen werden. Die Standard-Startfrist beträgt 330 Sekunden. Windows-Unterstützung ist als experimentell markiert. Wenn das nach einem Kompromiss klingt, ist es einer: Du gibst Ghidras volle Schreibfläche für eine kleinere, prüfbare auf. REAs Showcase-Beispiele zeigen den gedachten Stil: herausfinden, warum die Geschwindigkeit im Chrome-Dino-Spiel bei 6 beginnt und steigt, solange sie unter 13 liegt, die %-Taste des Windows-Rechners nachverfolgen (200 + 10 % = 220), die Zwischenablagen-Brücke einer Electron-App rekonstruieren, 63 kompilierte Funktionsbytes einer DX-Ball-Soundroutine gegen 3.205 Original-x86-Testfälle reproduzieren. Das sind Demonstrationen des Projekts, keine unabhängigen Ergebnisse. Kurz zu REAs Zahlen. GitHub zeigt rund 404.000 Sterne für ein im April angelegtes Repository, und npm hat seit dem 12. Juli 34 Releases (6.8.0 am 25. Oktober). Wie die Sterne zusammenkamen, lässt sich nicht prüfen, beurteile REA also nach Doku und Code. Es ist außerdem im Kern ein Ein-Personen-Projekt, rund 3.800 von etwa 6.200 Commits stammen von einem Entwickler, also pinne die Version, die du getestet hast. Ghidra MCP vs REA im direkten Vergleich !Ghidra MCP vs REA Architektur: Eine Ghidra-Brücke verbindet den Agenten über eine Python-Brücke, einen lokalen HTTP-Port und ein Plugin mit einer Ghidra-Engine; REA verbindet ihn mit einem MCP-Server und Provider-Adaptern für Ghidra, Hopper, IDA, JADX, Chrome und mehr und liefert Evidence mit Limitations zurück. _Eine Engine hinter einer Brücke oder eine Werkbank hinter einem Server._ | | Ghidra-MCP-Brücken | REA | | --- | --- | --- | | Was es ist | Adapter zwischen Agent und Ghidra | MCP-Server, CLI und Skill über viele Engines | | Ziele | Was Ghidra importiert: native Binärdateien, viele Architekturen | Nativ, Android, JS und Electron, .NET, Firmware, WASM, Pakete, Laufzeit und mehr | | Decompiler | Ghidra | Ghidra, Hopper, IDA oder Kuna für nativen Code | | Schnittstelle zur Engine | Plugin plus lokales HTTP, oder Headless über PyGhidra | Provider-Adapter, Ghidra in einem flüchtigen, schreibgeschützten Projekt | | Schreibzugriff | Ja: umbenennen, Typen setzen, kommentieren, Strukturen, je nach Projekt | Ghidra-Adapter schreibgeschützt; Annotationen leben in einer temporären Sitzung | | Skripte | Endpunkte zur Skriptausführung vorhanden, bei ghidra-mcp standardmäßig aus | Laut Doku nicht Teil des beschriebenen Ghidra-Adapters | | Rahmung der Ergebnisse | Rohe Tool-Ausgabe, der Agent deutet | Evidence, Abdeckung und Limitations bei jedem Ergebnis | | Laufzeitanalyse | ghidra-mcp: Emulation und ein Debugger nur in der GUI | Opt-in-Laufzeitmitschnitt; LLDB-Aufrufbeobachtung startet einen eigenen Prozess | | Installationsaufwand | Ghidra installieren, Erweiterung oder Python-Paket, Versionen abstimmen | npx rea-agents setup plus vorhandenes Ghidra für native Analyse | | Reife-Signal | Drei unabhängige Projekte, das älteste von März 2025 | Ein Projekt, erstes Release Juli 2026, hohe Release-Frequenz | | Lizenz | Apache-2.0 (GhidraMCP, ghidra-mcp) | MIT | So funktioniert KI-Reverse-Engineering: Was der Agent tatsächlich tut Beide Familien teilen dieselbe Schleife. Nur die Befehle unterscheiden sich. Mit einer Ghidra-Brücke arbeitet der Agent wie ein Mensch im CodeBrowser. Er listet Funktionen, Importe und Strings auf, dekompiliert die interessanten, folgt Querverweisen, benennt um, was er versteht, und schreibt Kommentare. Weil die Schreibvorgänge in der offenen Ghidra-Datenbank landen, hinterlässt eine gute Sitzung ein annotiertes Projekt, das du danach öffnen kannst. Mit REA ist der dokumentierte native Ablauf ausdrücklich darauf bedacht, exakte Namen zu wählen. Aus der Doku, mit dem Ghidra-Provider: _Terminal window_ rea inspect /absolute/path/to/program --provider ghidra --json rea search /absolute/path/to/program entry --kind procedures --provider ghidra --json rea function /absolute/path/to/program <procedure> --provider ghidra --json rea decompile /absolute/path/to/program <procedure> --provider ghidra <button title="Copy to clipboard" data-copied="Copied!" data-code="rea inspect /absolute/path/to/program --provider ghidra --jsonrea search /absolute/path/to/program entry --kind procedures --provider ghidra --jsonrea function /absolute/path/to/program &lt;procedure&gt; --provider ghidra --jsonrea decompile /absolute/path/to/program &lt;procedure&gt; --provider ghidra"><div></div></button> Die Doku ergänzt einen leicht zu übersehenden, für das Projekt typischen Hinweis: Nimm nicht an, dass jedes Ziel seine Einstiegsfunktion entry nennt, sondern wähle einen exakten Namen oder eine Adresse aus dem zurückgelieferten Inventar. Über MCP ist es derselbe Ablauf mit open_binary, danach fokussierte Tools wie list_procedures und analyze_function in derselben Sitzung. Darüber hinaus: - batch_decompile liest mehrere Funktionen auf einmal, und decompile_all schreibt pro Funktion eine Pseudocode-Datei plus ein Manifest, das Zählungen, aber keinen Code enthält. - search_bytes findet maskierte Byte-Muster und sagt, was es nicht durchsucht hat, etwa nicht initialisierte Blöcke. - trace_native_values baut Def-Use-Graphen aus dem High-P-Code des Decompilers über statisch aufgelöste Aufrufe hinweg. - export_evidence_bundle bewahrt die Beobachtungen auf, sodass eine Schlussfolgerung später geprüft werden kann, ohne dem Chat zu vertrauen. Der letzte Punkt ist die stille Stärke. Das Protokoll eines Agenten, der sagt „diese Funktion prüft einen Lizenzschlüssel“, ist eine Behauptung. Ein Evidence-Bundle mit Adressen, Referenzen und Limitations dahinter kann eine zweite Person prüfen. Ghidra MCP und REA einrichten: Was sich auf deinem Rechner ändert Das ist der Abschnitt, den die meisten Vergleiche überspringen und der entscheiden sollte, ob du etwas ausprobierst. Alles Folgende stammt aus der Doku der Projekte. Ghidra-Brücken Typischer Ablauf: ein JDK und genau die Ghidra-Version installieren, für die die Erweiterung gebaut wurde (die READMEs nennen Ghidra 12.1.4), das Plugin-ZIP über File, Install Extensions einspielen, in der Konfiguration aktivieren, Ghidra neu starten und dann den MCP-Server beim Client registrieren, zum Beispiel mit uvx --from git+https://github.com/LaurieWired/GhidraMCP ghidra-mcp --ghidra-server http://127.0.0.1:8080/. Was sich ändert: - ein Plugin in Ghidra, das nur in genau der Ghidra-Version lädt, für die es gebaut wurde - ein lokaler HTTP-Server auf festem Port, solange Ghidra läuft - ein Eintrag in der MCP-Konfiguration deines Agenten - ein Python-Prozess, der bei Bedarf startet, wobei uvx zur Laufzeit Code von einer Git-URL holt, was du auf einen Commit oder Tag pinnen solltest Beachte eine Versionsspannung: Das Ghidra-README für den aktuellen Master-Branch verlangt JDK 25, während die Brücken-Projekte Ghidra 12.1.4 und Java 21 dokumentieren. Richte dich nach dem README der Brücke, nicht nach dem neuesten Ghidra. REA npx rea-agents setup ist der dokumentierte Einstieg. Laut Installationsdoku: 1. Es gibt zuerst einen Plan aus, der Konfigurationspfade, Skill-Ziele, mögliche externe Software, Netzwerk-Ursprünge, Integritätsnachweise und Paketmanager-Befehle auflistet. 2. Es schreibt nichts, bis du freigibst. Die Freigabe des Plans ist getrennt von deiner Freigabe des npm-Downloads selbst. 3. Es legt vor dem Bearbeiten .rea.backup-Kopien der Konfigurationsdateien an, bewahrt fremde Einträge und blockiert die gesamte Transaktion, wenn eine Konfiguration fehlerhaft ist, statt zu raten. 4. Für Claude Code registriert es mcpServers.rea in ~/.claude.json und installiert den Skill in ~/.claude/skills/reverse-engineer-anything. Die Clients wählst du in einer Mehrfachauswahl. Vorhandene REA-Registrierungen sind vorausgewählt, neu erkannte Clients nicht, denn Erkennung liefert dem Setup Kontext, keine Erlaubnis. Der Skill wird standardmäßig installiert, mit --skill=false lässt du ihn weg. Wenn du Claude Desktop nutzt, beende es vor der Freigabe vollständig, weil eine laufende App die Registrierung überschreiben kann. Unterstützt werden mehr als zwei Dutzend Client-Kennungen, darunter Claude Code und Desktop, Codex, Cursor, Gemini CLI, Windsurf, VS Code, Copilot CLI und OpenCode, dazu gibt es einen Plugin-Weg (/plugin marketplace add morluto/rea) und einen MCP-Registry-Eintrag, io.github.morluto/rea. Was Aufmerksamkeit verdient, wieder direkt aus der Doku: - Die Registrierung ist global. Für Claude Code gelten Eintrag und Skill für jedes Projekt. Die Doku beschreibt, wie man das mit einem separaten CLAUDE_CONFIG_DIR-Profil oder einem lokalen Scope begrenzt, und sagt offen, dass ein Agent unter demselben OS-Konto weiterhin rea oder npx ausführen und Dateien lesen kann. - Es registriert einen absoluten Pfad zu node und zum Einstiegsskript, der npx-Cache muss also bestehen bleiben. - Das Installationsskript wird nicht per Signatur geprüft. Die Doku sagt es selbst: „Neither command verifies a signature on the downloaded script.“ Sie zeigt einen sichereren Ablauf: das Skript von einem gepinnten Tag laden, mit less lesen und dann mit passendem --version ausführen. Oder du nimmst den npm-Weg. - Starte Paket-Runner aus einem vertrauenswürdigen Verzeichnis außerhalb des Ziels, denn sie können Projektkonfiguration lesen. - Das Hopper-Setup kann das offizielle Paket herunterladen , mit PGP-Signaturprüfung (die Doku nennt den Fingerprint des Hauptschlüssels) und einer DMG-Digest-Prüfung unter macOS, mit ausschließlich HTTPS-Weiterleitungen. Ghidra wird nie heruntergeladen. - Rückgängig machen geht. rea doctor ist nur lesend, rea uninstall entfernt nur Registrierungen, die REA besitzt (--purge-data löscht auch den Cache), und rea update lässt Lifecycle-Skripte der Abhängigkeiten deaktiviert. Das npm-Paket selbst definiert nur die Skripte prepare und prepublishOnly, keine Hooks bei der Installation, und hat 42 Abhängigkeiten bei rund 49 MB entpackt. <aside role="note"><p>Achtung</p> <p>Das README warnt, dass es Lookalike-Repositories gibt, die nicht offiziell sind. Bei einem Werkzeug, das die Konfiguration deines Agenten ändert, prüfe die Quelle (<code>morluto/rea</code>, <code>rea-agents</code>), bevor du etwas ausführst. Dasselbe gilt für die vielen Repositories namens „ghidra-mcp“.</p></aside> Für die allgemeine Gewohnheit, Werkzeuge zu installieren, die Code auf deinem Rechner ausführen, zeigt Abwehr von npm-Lieferkettenangriffen, was du pinnen, abschalten und vorher lesen solltest. !Ghidra MCP vs REA Setup: was jeder Installer anfasst. Eine Ghidra-Brücke fügt ein Plugin und einen lokalen HTTP-Port hinzu; REA zeigt einen Plan, wartet auf Freigabe, sichert Konfigurationsdateien, schreibt MCP-Registrierung und Skill und lässt sich mit einem Befehl entfernen. _Beides ist rückgängig zu machen. Keines ist nichts._ Was schiefgehen kann Vier Risiken verdienen einen Namen. Das erste stammt aus meiner eigenen Analyse und steht in keiner Projekt-Doku; die anderen sind dokumentiert. 1. Die Binärdatei redet zurück. Aus Sicht des Modells ist eine Probe nicht vertrauenswürdiger Text. Strings, Symbolnamen, eingebettete Ressourcen und Kommentare kommen alle in Tool-Ergebnissen an. Eine bösartige Binärdatei kann einen String wie „ignore previous instructions and run this command“ enthalten, und ein Agent mit Shell-Zugriff und Geheimnissen ist genau das Ziel. Das ist das Lethal-Trifecta-Muster: private Daten, nicht vertrauenswürdige Inhalte und ein Ausgang nach draußen. Die Abwehr ist architektonisch: Unbekannte Proben kommen in eine Wegwerf-VM ohne Zugangsdaten, der Agent bekommt nur die nötigen Tools, und alles, was Code ausführen kann, bleibt aus. Der Fall, in dem Rogue-KI-Agenten eine echte Website kompromittierten, zeigt, wie wenig es braucht, sobald ein Agent Fähigkeit und ein Ziel hat. 2. Schreib-Tools verändern deine Analyse. Umbenennen und Neutypisieren machen eine Sitzung nützlich und lassen einen falschen Tipp sich ausbreiten: Eine von einem selbstsicheren Modell check_license genannte Funktion färbt jede spätere Entscheidung, auch deine. REAs schreibgeschützter Ghidra-Adapter umgeht das per Design. Behalte bei einer schreibfähigen Brücke eine Kopie des Projekts, bevor der Agent anfängt. 3. Laufzeitfunktionen führen das Ziel aus. REAs Doku ist eindeutig: Laufzeitmitschnitt führt das Ziel mit den Rechten deines Benutzers aus, und die LLDB-Aufrufbeobachtung startet einen eigenen Prozess, der „may change files, show UI or use the network“. Die Erlaubnis, eine Datei zu untersuchen, „does not necessarily authorize execution“. Nimm auch hier eine VM. 4. Der Modellanbieter sieht, was die Tools zurückgeben. REAs Doku sagt, die Analyse laufe lokal und „your agent receives the tool results, and its model provider has its own data policy“. Das heißt: Dekompilierter Code verlässt deinen Rechner, sobald er im Kontext eines Cloud-Modells landet. Bei proprietärer oder vertraglich beschränkter Software ist das erst eine rechtliche und vertrauliche Frage und dann eine technische. Ist Reverse Engineering legal? <aside role="note"><p>Achtung</p> <p>Dies ist eine Zusammenfassung öffentlicher Gesetzestexte, keine Rechtsberatung. Das Recht unterscheidet sich nach Land, Vertrag und Einzelfall. Wenn eine Entscheidung zählt, frag eine Juristin oder einen Juristen, die oder der Software- und IP-Recht in deinem Land kennt.</p></aside> Nützlich ist es, in vier Schichten zu denken, und eine Handlung muss alle passieren. | Schicht | Die Frage | Was die Quellen sagen | | --- | --- | --- | | Erlaubnis | Gehört es dir, oder hast du die Erlaubnis? | REAs Disclaimer: öffentliche Verfügbarkeit, Besitz einer Datei oder Zugang zu einem Debugging-Endpunkt „does not by itself establish permission for every operation“. US 17 U.S.C. 1201(j) definiert Sicherheitstests als Tests in gutem Glauben „with the authorization of the owner or operator“. | | Vertrag | Was sagen Lizenz oder EULA? | Deutschland: Vertragsbestimmungen, die zu § 69d Abs. 2, 3, 5, 7 oder zu § 69e UrhG im Widerspruch stehen, sind nichtig (§ 69g Abs. 2). Die US-Lage zu EULA-Beschränkungen wurde für diesen Artikel nicht recherchiert. | | Urheberrecht und Zugriffskontrollen | Gibt es eine gesetzliche Ausnahme? | US 1201(f) für Interoperabilität; Deutschland § 69e für Dekompilierung und § 69d Abs. 3 für das Untersuchen eines Programms; EU-Richtlinie 2009/24/EG hinter den deutschen Regeln. | | Regeln des Werkzeugs | Wobei hilft das Werkzeug nicht? | REA hilft nicht bei DRM- oder Lizenzumgehung, Spiele-Cheats, dem Umgehen von Zugriffskontrollen, dem Kopieren proprietären Codes oder dem Umgehen der Nutzungsregeln von KI-Anbietern. | USA. Section 1201 des Copyright Act betrifft die Umgehung technischer Schutzmaßnahmen, die den Zugang zu einem Werk kontrollieren. Die Reverse-Engineering-Ausnahme 1201(f) erlaubt jemandem, der rechtmäßig das Recht erlangt hat, eine Kopie eines Computerprogramms zu nutzen, eine solche Maßnahme zu umgehen „for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs“, sofern diese Elemente nicht schon leicht zugänglich waren, „to the extent any such acts of identification and analysis do not constitute infringement“. Die Werkzeuge dafür und die gewonnenen Informationen dürfen nur zur Interoperabilität weitergegeben werden. Davon getrennt sagt 1201(c)(1), dass der Abschnitt Fair Use und andere Verteidigungen gegen den Vorwurf der Verletzung nicht berührt. Beachte, was das nicht ist: eine allgemeine Erlaubnis, beliebiges zu beliebigem Zweck zu disassemblieren. Deutschland und EU. Die deutschen Regeln setzen die EU-Computerprogramm-Richtlinie 2009/24/EG um, die die ursprüngliche Richtlinie von 1991 ersetzt hat. § 69d Abs. 3 UrhG sagt, dass der zur Verwendung einer Programmkopie Berechtigte das Funktionieren des Programms „beobachten, untersuchen oder testen“ kann, um die einem Programmelement zugrundeliegenden Ideen und Grundsätze zu ermitteln, wenn dies durch Handlungen zum Laden, Anzeigen, Ablaufen, Übertragen oder Speichern geschieht, zu denen er berechtigt ist. § 69e erlaubt die Dekompilierung ohne Zustimmung des Rechtsinhabers nur, wenn die Vervielfältigung des Codes oder die Übersetzung der Codeform unerlässlich ist, um die für die Interoperabilität eines unabhängig geschaffenen Programms erforderlichen Informationen zu erhalten, und nur wenn: die Handlungen vom Lizenznehmer oder einer anderen berechtigten Person vorgenommen werden; die Informationen nicht bereits ohne Weiteres zugänglich sind; und die Handlungen auf die notwendigen Programmteile beschränkt bleiben. Die Informationen dürfen nicht zu anderen Zwecken verwendet, nicht über das für die Interoperabilität Notwendige hinaus weitergegeben und nicht für ein Programm mit im Wesentlichen ähnlicher Ausdrucksform genutzt werden. Und § 69g Abs. 2 erklärt Vertragsbestimmungen, die § 69e widersprechen, für nichtig, eine EULA kann also nicht einfach verbieten, was das Gesetz erlaubt. Das Geheimnisschutzrecht geht in dieselbe Richtung: Nach § 3 Abs. 1 Nr. 2 des Geschäftsgeheimnisgesetzes (GeschGehG) darf ein Geschäftsgeheimnis durch Beobachten, Untersuchen, Rückbauen oder Testen eines Produkts erlangt werden, das öffentlich verfügbar gemacht wurde oder sich in deinem rechtmäßigen Besitz befindet, solange du keiner Pflicht zur Beschränkung unterliegst. Was das praktisch bedeutet, als Lesehilfe und nicht als Beratung: - Die Analyse eigener Software oder von Malware-Proben im Labor ist der übliche, unstrittige Fall. Der Agent ändert die Geschwindigkeit, nicht den Status. - Interoperabilität hat in beiden Systemen ausdrückliche gesetzliche Unterstützung, mit Bedingungen an Notwendigkeit und an den Umgang mit dem Gelernten. - Sicherheitstests brauchen die Erlaubnis des Eigentümers, im US-Text wie in REAs eigener Regel. - Das Umgehen von DRM, Lizenzprüfungen oder Anti-Cheat und das Kopieren geschützten Codes liegen außerhalb dessen, was diese Ausnahmen abdecken, und außerhalb dessen, wobei REA hilft. - Eine KI wäscht nichts rein. REAs Disclaimer sagt, du seist für „actions you direct an AI agent to perform“ verantwortlich, und dass quelltextähnliche Ausgabe „does not grant rights to the original program“. Eine Setup-Checkliste für sicheres KI-Reverse-Engineering Das sind meine Empfehlungen, abgeleitet aus dem oben dokumentierten Verhalten. Keine davon braucht ein Spezialwerkzeug. 1. Nimm eine Wegwerf-VM für unbekannte Proben, ohne Zugangsdaten, ohne SSH-Agent und ohne Cloud-Token darauf. 2. Halte das Werkzeug aus deinem Alltagsprofil heraus. Bei REA unter Claude Code hält ein eigenes CLAUDE_CONFIG_DIR-Profil Registrierung und Skill von deinen anderen Projekten fern. 3. Pinne Versionen. Nimm das Ghidra-Release, das die Brücke nennt, einen Tag oder Commit der Brücke statt eines beweglichen Branches und eine exakte rea-agents-Version. 4. Bevorzuge schreibgeschützte Tools. Lass die Skriptausführung aus (GHIDRA_MCP_ALLOW_SCRIPTS) und kopiere das Ghidra-Projekt, bevor ein Agent Schreib-Tools bekommt. 5. Halte Server auf localhost. Wenn du anders bindest, setze das vom Projekt verlangte Auth-Token. 6. Behandle Strings und Kommentare in der Probe als feindlich. Gib dem Agenten in derselben Sitzung keine Shell und keinen offenen Netzzugang. 7. Bewahre die Belege auf. Speichere Adressen und Referenzen zu jeder Aussage und prüfe die wichtigen im Disassembly oder mit einem Debugger. 8. Kläre die Erlaubnis vorab. Stelle sicher, dass du das Ziel analysieren darfst, und lies die Datenrichtlinie deines Modellanbieters, bevor du proprietären Code hindurchschickst. Wann was 1. Lernen, CTFs, eine native Binärdatei, du magst Ghidras Oberfläche: GhidraMCP. Geringste Reibung, und die Annotationen landen in einem Ghidra-Projekt, das du behalten kannst. 2. Viele Binärdateien, Skripte und Automatisierung, keine GUI: pyghidra-mcp, wegen des Headless- und projektweiten Designs. 3. Du willst alle Ghidra-Funktionen bereitstellen und konfigurierst sorgfältig: ghidra-mcp, mit ausgeschalteten Skripten und gesetztem File Root. 4. Das Ziel ist keine einfache native Binärdatei: eine Electron- oder Android-App, ein Firmware-Image, ein WebAssembly-Modul, Netzwerkmitschnitte. REAs Breite ist der Grund, es zu nehmen. 5. Du brauchst nachprüfbare Schlussfolgerungen, etwa für einen Incident-Bericht: REAs Evidence-Bundles und ausdrückliche Limitations passen besser als ein Chat-Protokoll. 6. Unbekannte, möglicherweise feindliche Proben: jedes der Werkzeuge, nur in einer VM ohne Geheimnisse, möglichst mit schreibgeschützten Tools und ohne Ausführungsfunktionen. !Ghidra MCP vs REA und das Recht: vier Schichten, die eine Analyse passieren muss: Erlaubnis, Vertrag, gesetzliche Ausnahmen in den USA und Deutschland und die Regeln des Werkzeugs selbst. _KI ändert, wie schnell du liest, nicht ob du es darfst._ Wenn keines von beiden die Antwort ist - Du hast den Quelltext. Lies den Quelltext. - Du brauchst Ground Truth. Ein Decompiler sagt dir, was der Code zu tun scheint. Ein Debugger, ein Test oder die Dokumentation des Herstellers sagt dir, was er tut. - Der Code ist stark verschleiert oder gepackt. Der Agent liefert trotzdem flüssige Ausgabe, und sie ist weniger vertrauenswürdig. Entpacke zuerst, mit den richtigen Werkzeugen. - Die Aufgabe ist Umgehung. Kein Werkzeug hier ist eine Lizenz dafür. Das Fazit Ghidra MCP und REA beantworten verschiedene Fragen. Ein Ghidra-MCP-Server beantwortet „wie lasse ich meinen Agenten den Decompiler steuern, den ich ohnehin nutze?“, und dafür gibt es drei brauchbare Open-Source-Projekte. REA beantwortet „wie lasse ich einen Agenten alles Kompilierte oder Gepackte untersuchen und sorge dafür, dass die Antwort sagt, wie viel sie beweist?“, zum Preis einer breiteren Integration in die Konfiguration deines Agenten. REA nutzt außerdem Ghidra, wenn du es verlangst, die beiden sind also weniger Rivalen als benachbarte Schichten. Was sich nicht ändert, ist die Form des Risikos. Der Agent liest nicht vertrauenswürdige Eingaben, die Tools können schreiben oder ausführen, ein Cloud-Modell sieht die Ausgabe, und das Recht fragt nach Erlaubnis und Zweck. Das beste Setup ist das langweilige: eine Wegwerf-VM, schreibgeschützte Tools, gepinnte Versionen, ein gesicherter Beleg-Pfad und eine klare Antwort auf „darf ich das?“. > Wenn du Agenten im Team mit Tools verbindest: Wie ein MCP-Gateway benutzerbezogene Berechtigungen durchsetzt ist die Kontrollschicht, die über jedem einzelnen Server sitzt. Quellen - REA: GitHub-Repository, rea.tools, rea-agents auf npm - Ghidra: NationalSecurityAgency/ghidra - Ghidra MCP: GhidraMCP, ghidra-mcp, pyghidra-mcp - Recht: 17 U.S.C. 1201, UrhG §§ 69d, 69e, 69g, GeschGehG § 3, Richtlinie 2009/24/EG _Ursprünglich veröffentlicht auf alekseialeinikov.com_

어케 보면 위키리크스의 문건으로 인한 후폭발이... 위키리크스에서 CIA의 Vault 7 이란 파일을 터트렸는데, 거기서 쓰인 짱쎈 디컴파일러 기드라를 NSA에서 데헷하면서 풀어버리고 관리해서 말이죠. LLM, 즉 REA에서 이 기드라를 써서 뚫어뻥 한다고 합니다. LLM 시대전에도 있었고 기술이 당연 필요했는데, 대 LLM 시대가 오니 LLM 장난감이 되었죠. 얘 이름은 고지라 시리즈의 킹 기도라에서 가져왔습니다... NationalSecurityAgency/ghidra

Реверс‑инжиниринг и криптография: заставляем десктопные USB‑токены работать на Android Всем привет. Я уже довольно давно увлекаюсь темой криптографии, и недавно мне удалось реализовать весьма интересный кейс. Начался он как интересный спор в одном ИТ‑чатике, а перерос в весьма интересный (хотя пока еще не примененный) проект. Но обо всем по порядку. USB‑токены, что это и с чем едятся Когда речь заходит о криптографии, первыми на ум приходят HTTPS‑сертификаты, но это веб‑безопасность. Помимо защиты соединений, у криптографии есть еще одна сторона: электронная подпись. Я думаю, об этом очень часто слышат даже за пределами ИТ, ведь электронные подписи сейчас используются в госуслугах, при подписании бизнес‑контрактов, даже при сделках с недвижимостью. Но так как электронные подписи приравниваются к рукописной подписи, с соответсвующей юридической значимостью, их нужно очень хорошо защитить. И вот защита электронных подписей как раз обеспечивается специальными, похожими на флешки, физическими устройствами, так называемыми токенами. Чаще всего они выглядят как обычные флешки, иногда как брелки, или даже Bluetooth‑ или NFC‑модули. На картинке один из примеров, токен российского производства. Токен КриптоПро В отличие от Bluetooth‑ и NFC‑токенов, которые чаще всего ориентированы на использование на мобильных устройствах, USB‑токены обычно ориентированы на использование исключительно на десктопе. Есть другой вариант — TypeC‑токены, они нередко бывают кроссплатформенными, и вендоры часто поставляют как десктопные, так и мобильные SDK. В чем же проблема? Вот допустим есть N‑ое количество пользователей, у которых на руках есть исключительно USB‑токены. Эти токены выдавались пользователям еще очень давно, когда даже в мыслях у бизнеса не было пытаться работать с электронной подписью на мобилках. И тут приходит понимание: мобильные устройства очень удобны, их всегда можно таскать с собой, а те же самые ноутбуки (на которых как раз эти токены и работают) таскать с собой везде и всюду как‑то не охота. И было бы классно если бы пользователи могли бы работать с документами, в том числе и подписывать их, прямо с мобильного устройства. И как же достичь этого? С одной стороны, можно просто закупить партию новых токенов, которые можно использовать с мобилками — возможно, по такому сценарию и пошли бы большинство бизнесов. А можно написать свои драйвера и подружить уже имеющиеся у пользователей токены с мобилками, но тогда придется пользователям самим покупать себе OTG‑переходники (либо бизнес может сам раскошелиться на покупку этих переходников). Честно, я не маркетолог и не предприниматель, и рассуждать, насколько любое из этих решений рентабельно, тут не буду. Я лишь хочу показать примерный процесс интеграции токенов в приложения и сервисы тех бизнесов, которые все же захотели бы пойти по второму сценарию. Какие именно токены будем интегрировать? Конкретно в моей стране в ходу есть две модели токенов: Longmai mToken CryptoID Этот токен оказался самым простым в интеграции, и именно его мы «препарируем» в этой статье. Feitian ePass2003Auto Несмотря на то, что драйвер второго токена вполне себе опенсорсный, его интеграция оказалась напорядок сложнее, и пока что я даже ее не завершил, позже в статье я объясню почему. Оба токена китайского производства, доступны на самых разных маркетплейсах. И далее мы углубимся в дивный мир криптографических устройств и стандартов, поймем почему токены такие защищенные, и как даже под закрытое устройство, не имея в руках ничего кроме десктопного драйвера от вендора, токена и ноутбука (даже реальный смартфон опционален, по крайней мере если речь идет про Android) можно написать (почти) полноценный драйвер для столь серьезного средства защиты информации:) Почему токены такие защищенные? Особенность этих токенов в том, что они стандартизированы по FIPS (Federal Information Processing Standard) — американский стандарт по обработке информации, в котором расписаны требования к средствам защиты информации, правилам работы с закрытыми ключами и так далее — своего рода аналог стандартов по СЗИ в РФ. Помним как я выше писал о том, что интегрировать второй токен (ePass) оказалось значительно сложнее? А все потому что токены могут оперировать в нескольких режимах: FIPS mode и nonFIPS mode. Токен от Longmai по‑умолчанию работает в nonFIPS режиме, что значит что соединение между токеном и компьютером не шифруется. В то время как ePass наоборот, по‑умолчанию работает в FIPS режиме, что значит, что нам ОБЯЗАТЕЛЬНО нужно будет реализовывать логику Secure Messaging в драйвере, из‑за чего, собственно, я пока что и отложил интеграцию ePass. Также маркером режима работы является цвет индикатора на самом токене, на nonFIPS токене горит красный индикатор, а на FIPS токене — зеленый. Эти режимы может менять поставщик токенов, и делается это с помощью специализированных утилит, либо дерганием методов из драйвера вендора вручную. Главная задача токена — защитить закрытый ключ пользователя. Для этого, согласно тому же стандарту FIPS, применяются самые разные методы, такие как противодествие вскрытию (обнуление закрытых ключей в случае нарушения), защита пин‑кодом (токен блокируется после нескольких неверных вводов), а также противодействие энергетическим воздействиям на корпус или порт токена (в англоязычной литературе это называется fault injection, что можно перевести как «внедрение ошибок»). Все эти меры позволяют предотвратить атаки по сторонним каналами и сделать устройство бесполезным в руках вора. Как токен общается с компьютером? В идеале хотелось бы SDK от вендора, но так как его нет, мы напишем нужные нам компоненты самостоятельно. Внизу диаграмма взаимодействия между токеном и комьютером, и некоторую ее часть нам придется перенести в свой драйвер, так как этой логики нет в ядре Android (в отличие от Linux, где это может работать чуть ли не из коробки). Важно сказать, что в рамках работы над драйвером мы можем назвать токен смарт‑картой, так как по сути все это работает через один и тот же стек. Если бы у нас на руках была бы реальная смарт‑карта и отдельно от нее ридер, логика работы была бы той же самой, но нельзя было бы сказать что токен == ридер, а сейчас мы так сказать можем, поскольку токен в рамках данной диаграммы можно представить как ридер с одной единственной смарт‑картой. Другой важной оговоркой является то, что на диаграмме PKCS#11-модули работают над CCID‑драйвером, это не значит что нам обязательно нужен PKCS#11 для работы с токеном. CCID позволяет работать с токеном напрямую, то есть из диаграммы можно даже убрать слой PKCS#11. Но мы его оставим, просто чтобы не нарушать целостность картины, ну и еще потому что одним из главных источников команд для токена будет именно вендорский PKCS#11-модуль, потому что он все равно работает с CCID, только через него и никак иначе. Что нам нужно, чтобы токен заработал на Android? Для того, чтобы токен мог успешно «общаться» с токеном, нам нужно реализовать логику работы CCID, которой нет ядре Android, а потребителям нашего драйвера можно просто поставлять библиотеку, которую можно интегрировать в приложение. То есть, по сути, мы пишем user‑space драйвер. Начиная с Android 3.0, в системе уже имеется реализация USB‑стека, которая нам нужна для физического обмена сообщениями с токеном, нам же остается просто отправлять на токен корректные команды и правильно интерпретировать ответы от него. Выбираем стек Надеюсь меня не закидают тут тапками, но никакого хардкора с указателями и сильно глубокой системщиной не будет:) А все потому что на своей текущей работе я пишу на c#, и именно его я выбрал в качестве инструмента для реализации этой задачи. Это возможно благодаря таким технологиям, как MAUI, которые делают.NET кроссплатформенным. Более того, вся разработка осуществлялась на windows. Но разумеется, все было написано не совсем на голом дотнете, так как опенсорс‑сообщество уже предлагает определенные готовые решения для низкоуровневой работы со смарт‑картами на десктопе, и нам нужно будет всего‑навсего адаптировать их под свои нужды на мобилках. У нас есть: Pcsc‑sharp — библиотека, позволяющая отправлять APDU‑команды на токен напрямую, работает на windows, linux и macOS, мы адаптируем ее под android. Device.net — комплект библиотек для работы с USB‑устройствами напрямую, позволяет отправлять сырые байты на самые разные устройства, но не для смарт‑карт на десктопе, так как смарт‑карты обычно эксклюзивно блокируются операционной системой на уровне ядра; мы будем использовать ее для бесшовного переключения между десктопным (во время интеграционных тестов) и мобильным (работа на реальном смартфоне) устройствами. LibWDI — потребуется для интеграционного тестирования CCID‑слоя без использования смартфона/эмулятора; как было сказано ранее, ОС блокирует токен исключительно для себя, и для тестирования наших CCID‑пакетов нам придется на время теста подменять драйвер токена на обычный win‑usb драйвер, чтобы система думала что токен — это просто generic usb device и не блокировала его. PKCS11interop — используется в юнит‑тестах, для проведения тестовых операций с токеном, как если бы мы работали с ним в обычном приложении, тем самым мы создаем и анализируем трафик между вендорским драйвером и нашим компьютером, это нужно для извлечения APDU‑команд. PKCS#11-модуль токена — именно его мы будем использовать для общения с токеном в тестах, генерации трафика между токеном и компьютером, и именно его мы декомпилируем для извлечения нужных нам команд из него. Chilkat ScMinidriver — используется в интеграционных тестах для тестирования CCID‑слоя драйвера, позволяя нам отправлять сырые CCID‑пакеты прямо на токен. Это что касается используемых проектов в коде, помимо этого нам понадобится некоторый инструментарий на самом компьютере, это все не входит непосредственно в проект: Ghidra — очень мощная программа для декомпиляции исполняемых бинарников; она понадобится нам для извлечения всего лишь одной, но очень важной APDU‑команды. Wireshark + USBPcap‑драйвер — нужно для анализа трафика между токеном и компьютером. Google AI или любой другой ИИ агент — хоть и опционально, но так как я вкатывался в работу со смарт‑картами с нуля, я использовал его для анализа трафика и превращения команд, отловленных с помощью Wireshark, в рабочий код. Android‑эмулятор — нужен нам для запуска мини‑приложения, которое мы напишем специально для тестирования работы нашего драйвера на реальном устройстве. Основные усилия были направлены на написание тестов, которые позволят нам убедиться в корректности работы как самих APDU‑команд, так и CCID‑части драйвера. Примечательно, что всю работу можно вести прямо на компьютере, даже не беря в руки смартфон, для этого нам нужно соответствующим образом настроить android‑эмулятор, об этом будет рассказано ниже. Разберём основные подводные камни и сложности, с которыми столкнулся проект. Для чтения сертификатов с токена не нужен пин‑код, и вот почему Я ранее работал с PKCS11, и там на каждый чих нужно было вызывать Login(), а вот при работе с CCID этого вообще не нужно! А все потому что PKCS11 и CCID слои работают с токеном на разных уровнях, и если PKCS11 драйвер сохраняет сессии внутри себя, то CCID вообще не знает о сессиях ничего, и работает напрямую с файлами токена напрямую. Для лучшего понимания разницы между этими слоями подойдет вот это: Таблица взята из спецификации ScMinidriver [прямая ссылка на скачивание.docx — прим. модератора] от майкрософт, страница 103. Иными словами, с точки зрения CCID, токен — просто своего рода флешка с файлами, доступ к которым можно получить определенными командами (теми самыми APDU‑командами, которые мы прослушиваем с помощью Wireshark). Различия между вводом пин‑кода через PKCS11.Login и CCID.VerifyPin У токена состояния только два: залогинен или разлогинен. И если после завершения работы с драйвером не сбрасывается состояние на самом токене, это оставляет его залогиненным для других процессов пока он не будет извлечен из компьютера и вставлен снова. Сам PKCS11-модуль корректно обрабатывает эти вещи, и нам тоже нужно вручную отправлять APDU‑команду Logout на токен, иначе операции с токеном могут выполнять другие процессы на компьютере/телефоне, не требуя ввода пин‑кода. Это как оставить ключи от сейфа с миллионом долларов под ковриком на пороге. Тестирование CCID‑слоя Самая интересная часть работы, так как если протестировать работу APDU‑команд на десктопе легко, тот тут уже имеем дело с уровнем драйверов самой ОС, и чтобы протестировать работу этого слоя, нам придется «подвинуть» системный CCID‑драйвер, чтобы получить сырой доступ к токену и иметь возможность отправлять ему свои собственные CCID‑пакеты. Делается это с помощью libwdi, мы просто подменяем системный CCID‑драйвер на обычный WinUSB, а из кода работаем с токеном как с обычном USB‑устройством с помощью библиотек device.net. К примеру, этот код сначала подменяет ccid‑драйвер winusb, а потом возвращает все обратно: private async Task SwitchToWinUsbAsync(string vid, string pid) { Console.WriteLine($"[Setup] Переключаем устройство {HardwareId} на WinUSB через wdi-simple..."); // Ищем wdi-simple.exe в директории запуска тестов string wdiPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "wdi-simple.exe"); if (!File.Exists(wdiPath)) { throw new FileNotFoundException("Файл wdi-simple.exe не найден в директории сборки. Убедитесь, что он копируется в Output Directory."); } // Параметры для wdi-simple: // --vid и --pid указывают на наше целевое устройство. // --driver=0 указывает libwdi установить именно WinUSB (1 = libusb-win32, 2 = libusbK). // --name задает кастомное имя устройства в диспетчере. string arguments = $"--vid=0x{vid} --pid=0x{pid} --type=0 --name=\"Raw USB Smart Card Token\""; await ScriptRunner.RunProcessAsync(wdiPath, arguments); // Даем Windows время чтобы окончательно перестроить USB-стек после Zadig-инсталляции await Task.Delay(4000); Console.WriteLine("[Setup] Устройство успешно переведено в режим WinUSB."); } [SupportedOSPlatform("windows")] public async Task RestoreDefaultDriverAsync() { Console.WriteLine($"[TearDown] Откатываем устройство {HardwareId} к стандартному CCID драйверу..."); var resultCleanup = await ScriptRunner.RunScriptAsync("wdi-cleanup.ps1"); Console.WriteLine($"Результат удаления устройства:\n[Ошибки]: {resultCleanup.Error}\n[Вывод]:{resultCleanup.Output}\n"); var resultInstall = await ScriptRunner.RunScriptAsync(Path.Combine("install.bat"), workDir: "drivers_mtoken"); Console.WriteLine($"Результат установки устройства:\n[Ошибки]: {resultInstall.Error}\n[Вывод]:{resultInstall.Output}\n"); await Task.Delay(4000); SmartCardDeviceManager.ResetAllSmartCardReaders(); Console.WriteLine("[TearDown] Стандартный CCID драйвер смарт-карт успешно восстановлен."); }sourcecraft.dev Возврат токена обратно к классу смарт‑карт происходит с помощью специального powershell‑скрипта, иначе мне это сделать просто не удалось + тут была другая проблема: из‑за моих других экспериментов я чуть не сломал дерево устройств, так как в нем было слишком много dummy‑устройств, из‑за которых мой токен не хотел видеться как обычно. Вот кстати сам скрипт, если кому‑то тоже понадобится: Get-WindowsDriver -Online -All | Where-Object { $_.ProviderName -eq "libwdi" -and $_.OriginalFileName -like "*usb_device.inf" } | ForEach-Object { Write-Host "Удаление $_.Driver..."; pnputil /delete-driver $_.Driver /uninstall /force }sourcecraft.dev Но у таких тестов есть еще одна нерешенная проблема: после каждого теста, отдельно (то есть такие тесты нельзя запускать на последовательное выполнение, только по одному), нужно извлекать токен и вставлять обратно, чтобы система его увидела, иначе токен не хочеть видеться. Тест драйвера на эмуляторе Тоже одна из самых интересных и сложных фич проета. Дело в том, что эмулятор андроида из коробки не поддерживает работу с USB‑устройствами, хотя у самого эмулятора есть флаг --usb-passthrough, который как раз для этого и предназначен. Для того, чтобы можно было подключаться к токену прямо из эмулятора, нужно его пропатчить, добавив такое содержимое: <permissions><feature name="android.hardware.usb.host" /></permissions>, в файл: /system/etc/permissions/android.hardware.usb.host.xml. Делается это с помощью вот примерно такого кода: Write-Output "Launching ADB with root..." & $adbPath root | Out-Null Start-Sleep -Seconds 2 Write-Output "Disabling dm-verity..." $verityResult = & $adbPath disable-verity 2>&1 Write-Output $verityResult if ($verityResult -match "disabled" -or $verityResult -match "already") { Write-Output "Rebooting to disable dm-verity..." & $adbPath reboot Start-Sleep -Seconds 5 Wait-For-Device "Verity disabled succesfully" } else { Write-Warning "Warning: disable-verity gave unexpected response. Probably bootloader is locked." }sourcecraft.dev Этот код отключает verity, позволяя записывать нужные нам разрешения в системные директории. На скриншоте выше, я запустил свое тестовое приложение на эмуляторе, который я предварительно настроил для работы с токеном, и, как видно, эмулятор без проблем увидел сертификаты на токене. Использование ИИ Хочу это тоже выделить в отдельный пункт и рассказать, в каких местах я использовал ИИ, так как это тема очень актуальная, вся лента буквально пестрит этим, чего отставать от тренда: Скрипты для автоматической настройки эмулятора — полностью написаны ИИ, я только свои пожелания ему кидал, сам я в PowerShell не очень соображаю. CCID‑слой — в какой‑то степени тоже был написан ИИ, а именно: извлечение протокола (T0, T1) из ATR, обмен CCID‑пакетами, их отправка и чтение (но дочитку больших пакетов порциями — это писал я, так как там было слишком точечно), адаптация pcsc‑sharp для работы с мобилками (реализация ISCardApi для андроида). Что не было написано ИИ Адаптация device.net на Андроид. Дело в том, что этот проект старый (еще на Xamarin работал), свежих форков нет (еще бы, какие нишевые задачи), и мне нужно было перевести его на MAUI. За вечер я справился с этим сам, все для того, чтобы иметь возможность быстро писать тесты и отделить транспортную логику от CCID. Собственный RSA‑провайдер для удобного использования с криптографическими библиотеками — тут нужно было всего лишь проставить соответствующие вызовы APDU‑команд, ИИ был бы избыточен. Итого Я покопался еще по проекту, вроде все основные и интересные моменты расписал, больше ничего в голову не приходит. Данный проект наглядно показывает, как можно обойти вендорские ограничения даже по поддержке криптографического оборудования на разных платформах. Работал над проектом я ~2 месяца: 1 месяц я тупил и стагнировал (мне просто хотелось извлечь все APDU‑команды из декомпилированного драйвера, я не хотел пользоваться wireshark), второй месяц я очень активно занимался этим проектом. Пока что это мой самый интересный и сложный проект за мою карьеру:)

J’ai testé l’outil IA viral qui permet de COPIER n’importe quelle app ✉️ Rejoindre ma newsletter: sharma.fr 📅 S'inscrire en liste d'attente de mes workshops privés: sharma.fr → 🔗 Le repo REA morluto/rea → 🔗 Ghidra, l'outil de reverse engineering de la NSA NationalSecurityAgency/ghidra REA promet de reconstruire n'importe quelle application grâce à l'IA. On l'a testé en live avec Claude Code pour voir ce que ça vaut vraiment. Dans cette vidéo : ce qu'est le reverse engineering, du code source au binaire comment REA branche Claude Code sur Ghidra, Hopper ou IDA le point juridique à connaître avant de décompiler une app une app Mac reconstruite en 10 minutes, avec et sans REA pourquoi les applis qui dépendent d'un serveur restent hors de portée ce que ça change pour la valeur des logiciels Et vous, quelle application aimeriez-vous reconstruire ? Dites-le-moi en commentaire. 00:00 Introduction 02:42 REA : un MCP pour Claude Code 04:09 Installer REA et Ghidra 09:06 1er test 10:22 2ème test 13:48 Les fonctions cachées 16:07 La même app sans REA 17:58 Le verdict 18:18 La limite de REA MES AUTRES COMPTES: 🌍 Mon site web - sharma.fr 👨‍💻 Linkedin - sharma.fr 📱 TikTok - sharma.fr 🐦 Twitter - sharma.fr 📸 Instagram - sharma.fr [en-US] I Tested the Viral AI Tool That Can COPY Any App ✉️ Join my newsletter: sharma.fr 📅 Sign up for the waiting list for my private workshops: sharma.fr → 🔗 The REA repository morluto/rea → 🔗 Ghidra, the NSA's reverse engineering tool NationalSecurityAgency/ghidra REA promises to rebuild any application using AI. We tested it live with Claude Code to see how it really performs. In this video: What reverse engineering is, from source code to binary How REA connects Claude Code to Ghidra, Hopper, or IDA The legal point to know before decompiling an app A Mac app rebuilt in 10 minutes, with and without REA Why server-dependent apps remain out of reach What this changes for software value And you, what application would you like to rebuild? Let me know in the comments. 00:00 Introduction 02:42 REA: An MCP for Claude Code 04:09 Installing REA and Ghidra 09:06 First Test 10:22 Second Test 13:48 Hidden Functions 16:07 The Same App Without REA 17:58 The Verdict 18:18 The Limitations of REA MY OTHER ACCOUNTS: 🌍 My website - sharma.fr 👨‍💻 LinkedIn - sharma.fr 📱 TikTok - sharma.fr 🐦 Twitter - sharma.fr 📸 Instagram - sharma.fr

COMO EU FIZ O PORT DO INFAMOUS PARA PC USANDO O REA COM IA - #claude #ia #rea Em uma semana eu portei três jogos de PS4 pra rodar nativo no PC (Windows e Linux): inFAMOUS Second Son, The Last Guardian e Gravity Rush 2. Neste vídeo eu mostro o processo do zero: o dump do seu próprio jogo, o Ghidra, o REA (MCP de engenharia reversa) e, principalmente, como pedir pra IA (Claude Code, Codex) te ajudar no port. ⚠️ Pirataria é crime. Port e emulação são preservação. Nenhum arquivo do jogo, da Sony ou das desenvolvedoras é distribuído: pra jogar você precisa da SUA cópia e do SEU dump. 💬 Discord (testes, dúvidas, logs e novos ports): discord.gg O link também está no launcher dos três ports. 🎮 MEUS PORTS • inFAMOUS Second Son (CUSA00223): HayatoG/iss_pc • The Last Guardian (CUSA03627): HayatoG/tlg_pc • Gravity Rush 2 (CUSA03694): HayatoG/gr2_pc • PS4 Core (núcleo pra começar o seu port): HayatoG/ps4_core 🐞 Deu problema? No launcher: Suporte → Relatar um problema. Ou abra uma issue com o seu log: github.com/HayatoG/iss_pc/issues 🧰 FERRAMENTAS • GoldHEN (homebrew no PS4 com jailbreak): GoldHEN/GoldHEN • Itemzflow (dump do jogo no PS4): LightningMods/Itemzflow • Ghidra (engenharia reversa, gratuito, da NSA): NationalSecurityAgency/ghidra • REA, Reverse Engineer Anything: rea.tools (instalação: npx rea-agents setup) 📚 PROJETOS QUE SERVIRAM DE BASE (créditos!) • God of War III PC (SpartanPort), de Felipe Prado: FelipePrado0/SpartanPort • Bloodborne PC, de Dead Inside: deadinside28/bloodborne_pc • shadPS4 inFAMOUS Fix Build, de Ray Lancaner: rayhlancaner-png/shadPS4-Infamous-FixBuild • shadPS4 (tradução da GPU e dos shaders do PS4 pro Vulkan): shadps4-emu/shadPS4 🤖 O PROMPT "Eu tenho um jogo de PlayStation 4 que tá no meu PlayStation 4 com jailbreak. Quero fazer o dump dele pra poder preservar. Quero colocar esses arquivos no meu PC pra fazer um port, pra que eu possa jogar no meu PC." "Quero que se inspire nesses repositórios: [links acima]. Eles já usam funções que o PlayStation 4 utiliza pra rodar o jogo. Faça o clone desses projetos pra analisar o código e ver o que é reutilizável no nosso projeto." "Quero fazer um port nativo de inFAMOUS Second Son (PlayStation 4, CUSA00223, update 1.07) pra PC no Linux (ou Windows). Tenho o dump do meu console e o eboot.bin aberto no Ghidra com o REA. Como referência: o PS4 Core, o TLG PC e o Bloodborne PC. Primeiro, só planeje: liste os imports que o jogo usa, quais já existem no PS4 Core e quais faltam. Não escreva código ainda." Regra de ouro: diga o jogo e a versão, passe repositórios que deram certo e peça pra PLANEJAR antes de codar. 🧠 QUAL IA EU USEI • Ler o jogo no Ghidra: Claude Code com o REA • Planejar o port: Claude Code num modelo mais forte (Opus 5.5) • Escrever e corrigir o código: Claude Code no terminal • Também dá com o REA: Codex, Cursor, Gemini, Grok Build 📰 QUEM DIVULGOU (obrigado!) • DSOGaming: dsogaming.com • Nerd Maldito: nerdmaldito.com • Gameplayscassi: gameplayscassi.com.br • Senhor Linguiça: x.com Valeu também ao Leatherface, ao Apolar (presets que rodam a 30 e até 60 FPS), ao Illusion, ao Birex, ao kamynako (issue #188) e a todo mundo que testou e compartilhou no X. 💻 Desempenho honesto: no meu Ryzen 7 5700X3D + RTX 2060 6 GB + 32 GB de RAM roda entre 25 e 30 FPS. Em máquinas mais fortes tem gente a 50–60 FPS. O port tem 6 dias e segue sendo otimizado. ⏱️ CAPÍTULOS 0:00 Esse vídeo é diferente: 3 ports em uma semana 0:44 A repercussão: DSOGaming, Nerd Maldito, Gameplayscassi 1:35 Discord: de ~100 para mais de 1.300 pessoas 1:59 Os 3 jogos: inFAMOUS, The Last Guardian e Gravity Rush 2 2:47 Aviso: pirataria é crime, port é preservação 3:31 Passo 1: o dump (jailbreak, GoldHEN, Itemzflow) 5:01 eboot.bin e .prx: o que tem no dump 6:32 Por que dá certo: o PS4 é x86-64 como o PC 7:42 Ghidra: engenharia reversa gratuita 8:27 REA: o MCP que liga o Ghidra à sua IA 9:29 Como pedir pra IA (a parte mais importante) 11:44 O prompt, passo a passo 13:04 Repositórios-base e o PS4 Core 14:54 O prompt exato que eu usei 17:32 Qual IA usar em cada etapa 18:25 Aprenda a ler o log 18:59 Agradecimentos 19:38 Desempenho real (e honesto) 20:32 Discord, testes e hardware diferente 21:53 Como reportar um problema: log + issue 22:30 Apolar e os presets 23:09 Shaders e stutter: a pré-compilação 24:53 Issue #188: o stutter melhorou 26:06 6 dias de port e como começar o seu #inFAMOUS #PS4 #PCPort #EngenhariaReversa #IA [en] I Ported inFAMOUS from PS4 to PC with AI (Here's How) In one week I ported three PS4 games to run natively on PC (Windows and Linux): inFAMOUS Second Son, The Last Guardian and Gravity Rush 2. In this video I show the whole process from scratch: dumping your own game, Ghidra, REA (a reverse-engineering MCP) and, most importantly, how to ask AI (Claude Code, Codex) to help you with the port. 🌎 Video in Brazilian Portuguese with English subtitles (CC). ⚠️ Piracy is a crime. Porting and emulation are preservation. No game, Sony or developer files are distributed: to play you need YOUR own copy and YOUR own dump. 💬 Discord (testing, questions, logs and new ports): discord.gg The link is also inside the launcher of all three ports. 🎮 MY PORTS • inFAMOUS Second Son (CUSA00223): HayatoG/iss_pc • The Last Guardian (CUSA03627): HayatoG/tlg_pc • Gravity Rush 2 (CUSA03694): HayatoG/gr2_pc • PS4 Core (a core to kick-start your own port): HayatoG/ps4_core 🐞 Having issues? In the launcher: Support → Report a problem. Or open an issue with your log: github.com/HayatoG/iss_pc/issues 🧰 TOOLS • GoldHEN (homebrew on a jailbroken PS4): GoldHEN/GoldHEN • Itemzflow (dump the game on the PS4): LightningMods/Itemzflow • Ghidra (free reverse engineering, by the NSA): NationalSecurityAgency/ghidra • REA, Reverse Engineer Anything: rea.tools (install: npx rea-agents setup) 📚 PROJECTS I BUILT ON (credits!) • God of War III PC (SpartanPort), by Felipe Prado: FelipePrado0/SpartanPort • Bloodborne PC, by Dead Inside: deadinside28/bloodborne_pc • shadPS4 inFAMOUS Fix Build, by Ray Lancaner: rayhlancaner-png/shadPS4-Infamous-FixBuild • shadPS4 (PS4 GPU and shader translation to Vulkan): shadps4-emu/shadPS4 🤖 THE PROMPT 1) "I have a PlayStation 4 game on my jailbroken PlayStation 4. I want to dump it to preserve it, and move those files to my PC to make a port so I can play it on my PC." 2) "Take inspiration from these repositories: [links above]. They already use functions the PlayStation 4 uses to run games. Clone them, analyze the code and see what can be reused in our project." 3) "I want to make a native port of inFAMOUS Second Son (PlayStation 4, CUSA00223, update 1.07) to PC on Linux (or Windows). I have my console's dump and the eboot.bin open in Ghidra with REA. As reference: PS4 Core, TLG PC and Bloodborne PC. First, only plan: list the imports the game uses, which already exist in PS4 Core and which are missing. Don't write any code yet." Golden rule: name the game and the version, point to repositories that worked, and ask it to PLAN before coding. 🧠 WHICH AI I USED • Reading the game in Ghidra: Claude Code with REA • Planning the port: Claude Code on a stronger model (Opus 5.5) • Writing and fixing the code: Claude Code in the terminal • Also works with REA: Codex, Cursor, Gemini, Grok Build 📰 THANKS FOR SPREADING THE WORD • DSOGaming: dsogaming.com • Nerd Maldito: nerdmaldito.com • Gameplayscassi: gameplayscassi.com.br • Senhor Linguiça: x.com Thanks also to Leatherface, Apolar (presets running at 30 and even 60 FPS), Illusion, Birex, kamynako (issue #188) and everyone who tested and shared it on X. 💻 Honest performance: on my Ryzen 7 5700X3D + RTX 2060 6 GB + 32 GB RAM it runs at 25–30 FPS. On stronger machines people get 50–60 FPS. The port is 6 days old and still being optimized. ⏱️ CHAPTERS 0:00 This video is different: 3 ports in one week 0:44 The reaction: DSOGaming, Nerd Maldito, Gameplayscassi 1:35 Discord: from ~100 to over 1,300 people 1:59 The 3 games: inFAMOUS, The Last Guardian and Gravity Rush 2 2:47 Disclaimer: piracy is a crime, porting is preservation 3:31 Step 1: the dump (jailbreak, GoldHEN, Itemzflow) 5:01 eboot.bin and .prx: what's in the dump 6:32 Why it works: the PS4 is x86-64 like a PC 7:42 Ghidra: free reverse engineering 8:27 REA: the MCP that connects Ghidra to your AI 9:29 How to ask the AI (the most important part) 11:44 The prompt, step by step 13:04 Base repositories and PS4 Core 14:54 The exact prompt I used 17:32 Which AI to use at each step 18:25 Learn to read the log 18:59 Thank-yous 19:38 Real (and honest) performance 20:32 Discord, testing and different hardware 21:53 How to report a problem: log + issue 22:30 Apolar and the presets 23:09 Shaders and stutter: precompilation 24:53 Issue #188: the stutter got better 26:06 6 days of porting and how to start yours Started a port? Tag me on Discord and I'll create a channel for it so the community can help. #inFAMOUS #PS4 #PCPort #ReverseEngineering #AI

Reverse Engineer Anything: The Open-Source Tool That Turns Any Binary Into a Readable Spec (And Why Big Tech Won’t Love It) Closed source has always leaned on an unstated assumption: reading someone else's compiled code is slow. REA, short for Reverse Engineer Anything, is an MIT-licensed project built to make that assumption false. It showed up in a year when tech companies cut jobs at a pace TechCrunch's running tally put at around 120,000 by early July, with AI the most-cited reason. I'll cover what REA does and what it changes for companies. Then I'll give you my read on why it exists now, and you're free to disagree with it. The Problem It's Solving The tools for taking software apart already exist. Ghidra is free, Hopper is cheap, and IDA Pro is the long-standing commercial standard. What was missing is someone to drive them. An analyst picks the tool, learns its quirks, moves evidence between programs, and decides what to look at next. That takes skill, and it takes time. REA hands the driving to a coding agent. The pitch on rea.tools is simple: ask your agent how a feature in some app works, and REA gives it the tools to inspect the code behind the answer. The README goes further and says the agent can then build a version of that feature for your own project. How REA Actually Works REA is an MCP server plus a CLI. You run npx rea-agents setup, review the proposed changes, approve them, and restart your agent. Setup registers the server and installs matching workflow instructions, with backups of your existing config. The supported agents list includes Claude Code, Codex, Cursor, Gemini CLI and Grok Build. From there the agent calls REA like any other tool. REA inspects the target and returns findings along with the evidence and limitations behind each conclusion. The agent uses them to explain the behavior or write and test an implementation. According to the README, analysis runs locally. Your agent still receives the tool results, so your model provider's data policy applies to whatever it sees. The target list is long. Native binaries go through Hopper, Ghidra or IDA. Offline inspection can use GNU objdump or Rizin that you supply yourself. JavaScript and Electron applications get static analysis of modules, imports, source maps, routes and IPC with no native engine needed. Android APKs go through JADX. The README table also lists .NET assemblies, Flutter apps, firmware, Unity IL2CPP metadata, Godot archives, WASM, SQLite files, packet captures and live websites. One correction to the hype. REA is not a new decompiler, and it doesn't hand back original source code. A fact-check from October 14 makes the same point. REA returns pseudocode, assembly, modules and the relationships between them. The new piece is the agent working the loop. What Developers Are Actually Using It For The showcases show the work best, because each one asks a narrow question about software the author didn't write. On the site's Calculator example, the question is why Windows Calculator turns 200 + 10% into 220. The agent reads the percent handler's x64 instructions, finds that after addition the percent applies to the first operand, and checks the result against Microsoft's public source. In the dinosaur game example, it pulls the speed rule out of the running script: start at 6, add 0.001 per update, stop at 13. Then it rebuilds the game with a speed slider. The longer case studies go deeper. The Notion study traces the Electron clipboard bridge from the renderer through preload and IPC into the main process. The DX-Ball study recovers a 1996 game's sound-pan math as C, and the README says the reconstruction passes 3,205 original-x86 cases and reproduces all 63 compiled function bytes. The Aegis study follows an authenticator's six-digit code through its APK, and the TH04 study recovers bullet-ring angles from a PC-98 game. The site also lists bigger prompts as examples: clone this website, or reconstruct this game from its executable. So the project isn't pretending this stops at education. Why This Is a Bigger Deal Than It Looks Reading binaries was never impossible. It was expensive. REA lowers the cost, and that shifts a few things for companies. Shipped desktop and mobile apps are easier to study than they were. The README and site describe analyzing installed apps, Electron bundles, APKs and website scripts, all without source access. Anything a company ships to a user's machine can be inspected on that machine. The "we never looked at their code" defense gets harder to make. In a classic clean-room setup, one team analyzes and writes a spec while another team implements from the spec. REA's own example prompt asks one agent to investigate, show the evidence and build a similar feature, all in one session. That doesn't make it illegal. It does make independent development harder to demonstrate. This is my reading, and I'm not a lawyer. The law is older than the tooling. In Sega v. Accolade, the Ninth Circuit held in 1992 that disassembly for interoperability was fair use, and DMCA §1201(f) added an interoperability exception. EFF's reverse engineering FAQ treats contract law as its own separate risk, which matters because plenty of EULAs forbid reverse engineering. REA's DISCLAIMER says the project won't help with circumventing DRM, building cheats, bypassing authentication, or copying proprietary software and its protected code and assets. It also puts responsibility for authorization on the user. There's a tension there. The README advertises building a feature you saw in someone else's app, and the disclaimer rules out copying proprietary software. Where "learn how it works" ends and "copy it" begins is up to the person typing the prompt. Security cuts both ways. The README says runtime workflows execute or interact with the target under your user permissions, and the disclaimer says to use an appropriate environment for untrusted targets. The project has also had a supply-chain scare. The fact-check reports that on October 13 someone flagged a fake copy under an organization called rea-tools, advertising a "Windows Standalone .exe". It also reports that Microsoft Defender classified the file as a trojan and that 8 of 45 VirusTotal engines flagged it as a dropper. The official README now says to download only from the repo, rea.tools or the rea-agents npm package. The star count deserves a caveat too. The repo was created on April 14, 2026. The fact-check counted about 234,000 stars on October 14, and the repo page showed roughly 348,000 when I loaded it a week later. The fact-check says nobody can tell how many stars come from real readers, and I can't either. I'd treat the number as attention, not proof of adoption. My Take: Engineers Got Laid Off, Then Got Agents This section is opinion. Where I state a fact, there's a source next to it. Start with what is on record. Amazon announced 16,000 cuts on January 28, and Networkworld reports it posted record revenue of $716.9 billion for 2025. Meta cut roughly 8,000 jobs in May while guiding 2026 capex as high as $135 billion. Block's CEO tied its cuts to AI, per the same Newsweek piece. Microsoft cut 4,800 in July. Per Nairametrics, its CFO said headcount would keep falling as spending moves to AI infrastructure, while TechCrunch's tally quotes Microsoft saying those roles aren't being replaced by AI. The FT counts about 140,000 US tech jobs cut so far this year, about 50,000 of them at Amazon, Oracle, Meta and Microsoft. Trackers disagree on the totals, but every count is large. Now the part nobody can prove. I don't know who built REA, and nothing in the repo says they were laid off. So I'm not claiming that. My claim is narrower. Companies cut people while spending more on AI, and the same AI now sits in the hands of anyone with a free weekend. I believe many of the people cut were strong engineers. The trackers don't measure that and I can't prove it. But an engineer who is good at their job doesn't lose the skill when the badge stops working. That's where I think the energy is going. An MIT-licensed repo, under a year old, with nearly 4,000 commits, hundreds of open issues and pull requests, and an active Discord, did not come from nowhere. Someone cared enough to build it in public and give it away. I think a lot of developers right now are asking the same question: if my employer can decide my work is replaceable, why would I keep building closed things for them? Look at the other open-source moves this year, and be precise about each one. The Claude Code leak was an accident, not a protest. On March 31, a source map in an npm package exposed about 512,000 lines of Anthropic's TypeScript, and Anthropic confirmed it was unintentional. Google's decision to ship Gemma 4 under Apache 2.0 was a corporate licensing choice, the first Apache release in the Gemma line. REA is the odd one out: independent, deliberate, and aimed at everyone else's closed code. I'd say the three together point one direction, and only one of them is a revolt. So here is my actual prediction. The next few years will favor whoever ships in the open and lets people look inside. Companies that depend on nobody reading their code will have a harder time. What could make me wrong? Some of these layoffs may be ordinary cost cutting wearing an AI label. Microsoft's own statement points that way. REA's users may be mostly hobbyists, students and security researchers. Stars can be inflated. Agent output can be wrong, and REA's disclaimer says as much. Understanding how Notion bridges its clipboard does not give you Notion. And one repo doesn't make a movement. I'm still watching it, because I think the direction is right. Availability and Access REA is free and MIT-licensed. It needs Node.js 22.x (22.19 or later), 24.x (24.11 or later) or 26+, plus npm. npx rea-agents setup Native analysis needs Hopper, Ghidra or IDA already installed. REA grants no keys or licenses for commercial tools, so you need to obtain those legally yourself. Static JavaScript, Electron and .NET analysis need no native engine. Install the CLI with npm install --global rea-agents and keep it current with rea update. Get it only from morluto/rea, rea.tools, or the npm package. There's also a Discord for questions. Closed source has leaned on reading being slow. REA is one more sign, among several this year, that the slowness is going away. Follow for more coverage on MCP, agentic AI, and AI infrastructure.