morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #2255] [Feature] Ship REA releases with bundled open-source RE tools + ready-to-use MCP integrations #745

New issue

Open

opened 2026-10-15 18:27:54 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:27:54 +00:00

Owner

Originally created by @heaven-hm on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2255

Ship REA with the reverse-engineering tools it needs — not installation instructions

Why this matters

REA should ship ready-to-use, platform-specific distributions that include the open-source analysis engines its agents depend on. The point is simple: a user downloads REA, opens an executable, and starts investigating it through the CLI or MCP-connected AI agent. They should not have to spend their first hour finding Ghidra, downloading string extractors, matching Python versions, resolving PATHs, or troubleshooting separate debugger installations.

This is not a proposal to build our own disassembler or debugger. Existing open-source tools already solve these difficult problems, and their licenses generally permit redistribution when the distributor follows the license conditions. We can package the approved versions into REA releases and provide one consistent interface to them.

What users get

Before: install REA → research which programs are required → find legitimate binaries → install runtimes → configure each path/version → connect MCP adapters → start analysis.

Proposed: download an official REA bundle for your OS → run REA → static analysis works immediately; supported runtime analysis can be enabled and launched explicitly. MCP clients use the same configured bundled engines.

This removes a major adoption barrier, makes tutorials reproducible, and gives bug reports reproducible tool versions. A release with tested integrations is also a much stronger product than an orchestration layer that requires everyone to assemble the environment themselves.

Yes, redistribution is allowed — with compliance

I checked the upstream primary license texts below. MIT, BSD and Apache-2.0 expressly allow redistribution, including binaries, under their conditions. GPL, LGPL and AGPL tools can also be redistributed; their copyleft, source, notices, and component requirements must be satisfied. This is not an argument for ignoring licenses: licensing is how we can ship third-party software responsibly. An exact official release still needs a dependency and binary-notice audit before publication.

Tool	Verified primary license	Evidence	REA integration decision
Capstone	BSD	Upstream proof	Embed native disassembler; notices retained
LIEF	Apache-2.0	Upstream proof	Embed or managed helper; audit dependencies
pefile	MIT	Upstream proof	Optional Python PE parser
FLOSS	Apache-2.0	Upstream proof	Optional pinned strings CLI; audit packaged dependencies
capa	Apache-2.0	Upstream proof	Optional pinned capability CLI; audit rule sets
DynamoRIO	BSD primary, exceptions	Upstream proof	Separate opt-in instrumentation pack; component audit
Frida	wxWindows Library Licence 3.1	Upstream proof	Separate opt-in instrumentation pack; component audit
radare2	LGPL-family and mixed components	Upstream proof	Optional separate CLI; verify exact release/plugin license set
x64dbg	GPL-3.0 with project-specific text	Upstream proof	Optional separate debugger with GPL obligations
Ghidra	Apache-2.0 primary, mixed components	Upstream proof	Reuse existing provider; BYO initially
angr	BSD-style	Upstream proof	Optional Python environment; dependencies not audited
Manticore	AGPL-3.0	Upstream proof	BYO first; AGPL obligations
Keystone	GPL-2.0 base and exceptions	Upstream proof	BYO pending exception review

What I propose we actually ship

REA Static Edition — ready out of the box

Capstone for disassembly, LIEF for PE/ELF/Mach-O inspection.
FLOSS for decoded/obfuscated strings and capa for program capability recognition.
Optionally pefile if lightweight Windows PE-only parsing adds value.
Bundle their supported executable/library artifacts with the appropriate runtime and license notices so the user doesn't have to install Python or separate tools manually. Use existing REA Ghidra integration when present rather than forcing a second copy of a large engine.

REA Runtime Edition / opt-in platform pack

Frida for dynamic instrumentation and function hooks; DynamoRIO for native execution traces.
x64dbg on Windows, or platform-supported GDB/LLDB, for interactive native debugging once the existing adapter roadmap is delivered.
Runtime pack is included in a designated downloadable release or selected at install time, not silently injected/attached at REA startup.

REA Full / advanced pack (optional) can ship radare2, angr and other larger engines after exact artifact-level licensing, platform, and maintenance review. The full distribution may be large; retain a lightweight core release too.

This lets us truthfully offer preinstalled tools without requiring every engine on every OS, and without making all REA users pay in package size for specialized workflows.

The MCP advantage: one install, many AI clients

Bundle the engines and the REA adapters, not competing MCP servers for each individual tool. REA exposes structured operations to agents over its existing MCP interface:

Binary metadata/imports/symbols, instruction disassembly, detected strings and capability matches.
User-authorized process launch/attach, native tracing, breakpoint/memory/register observations where supported.
Typed inputs/outputs with tool/version, file hash, precise offsets/addresses, evidence, errors and timeouts.

Example: a user asks their agent “Find the function that decrypts these strings, inspect the call at runtime, and show supporting evidence.” REA can run FLOSS/capa/Capstone on the file, correlate findings with a static provider, and use Frida or a debugger for a target the user explicitly authorizes. Today, such work often needs several manual installs and separate integrations.

These are proposed workflows, not assertions that all of these MCP operations already exist.

Packaging plan that satisfies licenses

Choose a small first bundled release: Capstone + LIEF + FLOSS + capa. Verify specific versions, licenses and their complete shipped dependency trees.
Vendor or package official/prebuilt artifacts only after verifying provenance and SHA-256; record package version, origin, OS/CPU support, and reproducible build instructions where required.
Include THIRD_PARTY_LICENSES/, all required copyrights/NOTICE files, and source availability or source offers for applicable copyleft components. Keep a manifest/SBOM, review plugin/ruleset licenses, and apply license obligations to the actual combined work where relevant.
Build and test native release archives/installers for Windows, Linux, and macOS on each supported architecture. No runtime dependency hunting for supported static features.
Route all tool paths through the REA bundle's own manifest; support user-installed overrides. Never modify global PATH, system security configuration or host runtimes silently.
Test CLI and MCP end-to-end against source-generated binaries; verify captured outputs, errors, uninstall/update behavior and cancellation.
Ship runtime executables/adapters in a clearly labeled optional distribution, and implement explicit, controlled process permissions/lifecycle. Keep debugger control work aligned with #1267 and instrumentation work aligned with #968.

Why approve this?

Zero setup for supported workflows: users can start analyzing instead of hunting for prerequisites.
Redistribution is a feature of the open-source licenses: we can legally package approved components while preserving their rights and obligations.
Reliable results: pinned, tested engines remove “works on my machine” version mismatches.
Better agent experience: bundled tools become consistent CLI/MCP capabilities, not a pile of manual connectors.
Stronger release quality: official, versioned tool packs are easier to document, test, update and support than arbitrary external installs.
No reinvention: maintainers integrate mature open-source projects rather than creating new disassemblers/debuggers.

Acceptance criteria

Maintainers agree that shipping selected tools directly with REA releases is the goal, not simply documenting external installation.
First bundled static edition includes at least one native parser/disassembler and one higher-level analyzer with useful REA CLI/MCP entrypoints.
A tool and license manifest accompanies every release; artifact-specific dependencies and redistribution obligations verified.
Windows/Linux/macOS artifacts deliver install-free supported functionality where advertised.
Optional runtime packs provide useful traced/debugged observations without automatically running, attaching to or modifying user targets.
BYO/external provider overrides remain possible.

Requested decision: Can we approve a proof-of-concept official REA release that bundles Capstone, LIEF, FLOSS and capa, with CLI + MCP adapters and complete third-party notices, then extend the same distributable model to Frida/DynamoRIO and platform debuggers? This is a concrete distribution feature that can make REA dramatically easier to adopt.

Originally created by @heaven-hm on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2255 ## Ship REA with the reverse-engineering tools it needs — not installation instructions ### Why this matters **REA should ship ready-to-use, platform-specific distributions that include the open-source analysis engines its agents depend on.** The point is simple: a user downloads REA, opens an executable, and starts investigating it through the CLI or MCP-connected AI agent. They should not have to spend their first hour finding Ghidra, downloading string extractors, matching Python versions, resolving PATHs, or troubleshooting separate debugger installations. This is not a proposal to build our own disassembler or debugger. **Existing open-source tools already solve these difficult problems, and their licenses generally permit redistribution when the distributor follows the license conditions.** We can package the approved versions into REA releases and provide one consistent interface to them. ### What users get **Before:** install REA → research which programs are required → find legitimate binaries → install runtimes → configure each path/version → connect MCP adapters → start analysis. **Proposed:** download an official REA bundle for your OS → run REA → static analysis works immediately; supported runtime analysis can be enabled and launched explicitly. MCP clients use the same configured bundled engines. This removes a major adoption barrier, makes tutorials reproducible, and gives bug reports reproducible tool versions. A release with tested integrations is also a much stronger product than an orchestration layer that requires everyone to assemble the environment themselves. ### Yes, redistribution is allowed — with compliance I checked the upstream primary license texts below. **MIT, BSD and Apache-2.0 expressly allow redistribution, including binaries, under their conditions. GPL, LGPL and AGPL tools can also be redistributed; their copyleft, source, notices, and component requirements must be satisfied.** This is not an argument for ignoring licenses: licensing is how we can ship third-party software responsibly. An exact official release still needs a dependency and binary-notice audit before publication. | Tool | Verified primary license | Evidence | REA integration decision | |---|---|---|---| | Capstone | BSD | [Upstream proof](https://github.com/capstone-engine/capstone/blob/next/LICENSES/LICENSE.TXT) | Embed native disassembler; notices retained | | LIEF | Apache-2.0 | [Upstream proof](https://github.com/lief-project/LIEF/blob/main/LICENSE) | Embed or managed helper; audit dependencies | | pefile | MIT | [Upstream proof](https://github.com/erocarrera/pefile/blob/master/LICENSE) | Optional Python PE parser | | FLOSS | Apache-2.0 | [Upstream proof](https://github.com/mandiant/flare-floss/blob/master/LICENSE.txt) | Optional pinned strings CLI; audit packaged dependencies | | capa | Apache-2.0 | [Upstream proof](https://github.com/mandiant/capa/blob/master/LICENSE.txt) | Optional pinned capability CLI; audit rule sets | | DynamoRIO | BSD primary, exceptions | [Upstream proof](https://github.com/DynamoRIO/dynamorio/blob/master/License.txt) | Separate opt-in instrumentation pack; component audit | | Frida | wxWindows Library Licence 3.1 | [Upstream proof](https://github.com/frida/frida/blob/main/COPYING) | Separate opt-in instrumentation pack; component audit | | radare2 | LGPL-family and mixed components | [Upstream proof](https://github.com/radareorg/radare2) | Optional separate CLI; verify exact release/plugin license set | | x64dbg | GPL-3.0 with project-specific text | [Upstream proof](https://github.com/x64dbg/x64dbg/blob/development/LICENSE) | Optional separate debugger with GPL obligations | | Ghidra | Apache-2.0 primary, mixed components | [Upstream proof](https://github.com/NationalSecurityAgency/ghidra/blob/master/LICENSE) | Reuse existing provider; BYO initially | | angr | BSD-style | [Upstream proof](https://github.com/angr/angr/blob/master/LICENSE) | Optional Python environment; dependencies not audited | | Manticore | AGPL-3.0 | [Upstream proof](https://github.com/trailofbits/manticore/blob/master/LICENSE) | BYO first; AGPL obligations | | Keystone | GPL-2.0 base and exceptions | [Upstream proof](https://github.com/keystone-engine/keystone/blob/master/COPYING) | BYO pending exception review | ### What I propose we actually ship **REA Static Edition — ready out of the box** - **Capstone** for disassembly, **LIEF** for PE/ELF/Mach-O inspection. - **FLOSS** for decoded/obfuscated strings and **capa** for program capability recognition. - Optionally **pefile** if lightweight Windows PE-only parsing adds value. - Bundle their supported executable/library artifacts with the appropriate runtime and license notices so the user doesn't have to install Python or separate tools manually. Use existing REA Ghidra integration when present rather than forcing a second copy of a large engine. **REA Runtime Edition / opt-in platform pack** - **Frida** for dynamic instrumentation and function hooks; **DynamoRIO** for native execution traces. - **x64dbg on Windows**, or platform-supported **GDB/LLDB**, for interactive native debugging once the existing adapter roadmap is delivered. - Runtime pack is included in a designated downloadable release or selected at install time, not silently injected/attached at REA startup. **REA Full / advanced pack (optional)** can ship radare2, angr and other larger engines after exact artifact-level licensing, platform, and maintenance review. The full distribution may be large; retain a lightweight core release too. This lets us truthfully offer preinstalled tools **without requiring every engine on every OS**, and without making all REA users pay in package size for specialized workflows. ### The MCP advantage: one install, many AI clients Bundle **the engines and the REA adapters**, not competing MCP servers for each individual tool. REA exposes structured operations to agents over its existing MCP interface: - Binary metadata/imports/symbols, instruction disassembly, detected strings and capability matches. - User-authorized process launch/attach, native tracing, breakpoint/memory/register observations where supported. - Typed inputs/outputs with tool/version, file hash, precise offsets/addresses, evidence, errors and timeouts. **Example:** a user asks their agent “Find the function that decrypts these strings, inspect the call at runtime, and show supporting evidence.” REA can run FLOSS/capa/Capstone on the file, correlate findings with a static provider, and use Frida or a debugger for a target the user explicitly authorizes. Today, such work often needs several manual installs and separate integrations. These are proposed workflows, not assertions that all of these MCP operations already exist. ### Packaging plan that satisfies licenses 1. Choose a **small first bundled release**: Capstone + LIEF + FLOSS + capa. Verify specific versions, licenses and their complete shipped dependency trees. 2. **Vendor or package official/prebuilt artifacts** only after verifying provenance and SHA-256; record package version, origin, OS/CPU support, and reproducible build instructions where required. 3. Include `THIRD_PARTY_LICENSES/`, all required copyrights/NOTICE files, and source availability or source offers for applicable copyleft components. Keep a manifest/SBOM, review plugin/ruleset licenses, and apply license obligations to the actual combined work where relevant. 4. Build and test native release archives/installers for Windows, Linux, and macOS **on each supported architecture**. No runtime dependency hunting for supported static features. 5. Route all tool paths through the REA bundle's own manifest; support user-installed overrides. Never modify global PATH, system security configuration or host runtimes silently. 6. Test CLI **and MCP end-to-end** against source-generated binaries; verify captured outputs, errors, uninstall/update behavior and cancellation. 7. Ship runtime executables/adapters in a **clearly labeled optional distribution**, and implement explicit, controlled process permissions/lifecycle. Keep debugger control work aligned with [#1267](https://github.com/morluto/rea/issues/1267) and instrumentation work aligned with [#968](https://github.com/morluto/rea/issues/968). ### Why approve this? - **Zero setup for supported workflows:** users can start analyzing instead of hunting for prerequisites. - **Redistribution is a feature of the open-source licenses:** we can legally package approved components while preserving their rights and obligations. - **Reliable results:** pinned, tested engines remove “works on my machine” version mismatches. - **Better agent experience:** bundled tools become consistent CLI/MCP capabilities, not a pile of manual connectors. - **Stronger release quality:** official, versioned tool packs are easier to document, test, update and support than arbitrary external installs. - **No reinvention:** maintainers integrate mature open-source projects rather than creating new disassemblers/debuggers. ### Acceptance criteria - [ ] Maintainers agree that **shipping selected tools directly with REA releases** is the goal, not simply documenting external installation. - [ ] First bundled static edition includes at least one native parser/disassembler and one higher-level analyzer with useful REA CLI/MCP entrypoints. - [ ] A tool and license manifest accompanies every release; artifact-specific dependencies and redistribution obligations verified. - [ ] Windows/Linux/macOS artifacts deliver install-free supported functionality where advertised. - [ ] Optional runtime packs provide useful traced/debugged observations without automatically running, attaching to or modifying user targets. - [ ] BYO/external provider overrides remain possible. **Requested decision:** Can we approve a proof-of-concept official REA release that bundles Capstone, LIEF, FLOSS and capa, with CLI + MCP adapters and complete third-party notices, then extend the same distributable model to Frida/DynamoRIO and platform debuggers? This is a concrete distribution feature that can make REA dramatically easier to adopt.

bsakaguchi added the

area: build

P3: low

enhancement

labels

2026-10-15 18:27:54 +00:00

bsakaguchi commented

2026-10-15 18:27:55 +00:00

Author

Owner

@morluto commented on GitHub (Oct 12, 2026):

We will look to move to a more modular architecture in the future. Just a lot of support + bugs we have to fix now.
I can tell you put a lot of effort into this issue and it shows.
Thank you!

@morluto commented on GitHub (Oct 12, 2026): We will look to move to a more modular architecture in the future. Just a lot of support + bugs we have to fix now. I can tell you put a lot of effort into this issue and it shows. Thank you!

bsakaguchi commented

2026-10-15 18:27:55 +00:00

Author

Owner

@heaven-hm commented on GitHub (Oct 12, 2026):

4. We will look to move to a more modular architecture in the future. Just a lot of support + bugs we have to fix now.
I can tell you put a lot of effort into this issue and it shows.
Thank you!

Thanks yes bugs/fix needs priority this feature request can wait for future release.

@heaven-hm commented on GitHub (Oct 12, 2026): > 4\. We will look to move to a more modular architecture in the future. Just a lot of support + bugs we have to fix now. > I can tell you put a lot of effort into this issue and it shows. > Thank you! Thanks yes bugs/fix needs priority this feature request can wait for future release.

bsakaguchi referenced this issue

2026-10-16 21:15:41 +00:00

[PR #745] [MERGED] docs: clarify onboarding and align provider guidance #2209

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:29:30 +00:00