[GH-ISSUE #481] [Feature] Add a read-only Ghidra provider for macOS #257

New issue

Closed

opened 2026-10-15 18:23:04 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:23:04 +00:00

Owner

Originally created by @morluto on GitHub (Sep 28, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/481

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Current limitation

REA's documented Ghidra bridge currently supports Linux x64, with a separate experimental Windows x64 boundary. On macOS, users who already have Ghidra and a suitable JDK cannot select the Ghidra read-only provider through REA. They must use another configured provider or run Ghidra outside REA and manually move results into their investigation. This is especially limiting for analysts who need headless, non-GUI native analysis.

Use cases

Analyze native macOS, iOS, and other supported Mach-O binaries with a locally installed Ghidra distribution.
Run bounded decompilation and cross-reference work without opening or raising a disassembler GUI window.
Keep analysis sessions, target binding, and Evidence v2 output consistent between CLI and MCP.

Desired outcome and success criteria

Add a bring-your-own Ghidra provider for supported macOS hosts. The provider should:

validate the Ghidra release, full JDK/Javac, host architecture, and analyzeHeadless path with actionable typed capability diagnostics;
support caller-configured absolute installation paths and never download or install Ghidra or Java implicitly;
provide the same admitted read-only operations and truthful capability metadata as the existing Ghidra provider;
analyze a digest-verified target copy/project with read-only settings, bounded CPU, memory, deadlines, cancellation, authentication, and verified cleanup;
avoid launching the Ghidra GUI and preserve the active target/provider binding on failure;
pass the shared native fixture suite for Mach-O and cross-format analysis, including malformed input, cancellation, concurrency, and cleanup cases.

Document the exact supported Ghidra/JDK/host matrix, and report unsupported architectures or versions as unavailable rather than falling back silently to another provider.

Authority boundaries and non-goals

Static Ghidra analysis only; no arbitrary scripting, target execution, runtime attachment, or database mutation through this provider.
BYO installation paths remain operator supplied; no implicit installation, licensing changes, or GUI launch.
Preserve provider neutrality and Evidence v2 authority/coverage metadata.

Alternatives considered

The Hopper provider is a separate analysis engine and may expose a GUI window. It does not satisfy a requirement to use an installed Ghidra distribution headlessly.
Running Ghidra manually can answer questions but loses REA's normalized provider operations, session routing, and evidence linkage.
The native macOS inspection provider supplies deterministic Mach-O metadata but is not a full decompiler.

Possible direction

Extend the existing Ghidra adapter and its host-specific runtime/verification boundary to macOS after defining an explicit supported architecture and JDK matrix. Keep provider selection explicit and retain the existing no-fallback semantics.

References

Ghidra provider configuration in the README: https://github.com/morluto/rea#ghidra-read-only-analysis-provider
Prior provider evaluation: #26
Agent-first provider roadmap: #32

Originally created by @morluto on GitHub (Sep 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/481 ## Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Area Native analysis or decompilation ## Current limitation REA's documented Ghidra bridge currently supports Linux x64, with a separate experimental Windows x64 boundary. On macOS, users who already have Ghidra and a suitable JDK cannot select the Ghidra read-only provider through REA. They must use another configured provider or run Ghidra outside REA and manually move results into their investigation. This is especially limiting for analysts who need headless, non-GUI native analysis. ## Use cases - Analyze native macOS, iOS, and other supported Mach-O binaries with a locally installed Ghidra distribution. - Run bounded decompilation and cross-reference work without opening or raising a disassembler GUI window. - Keep analysis sessions, target binding, and Evidence v2 output consistent between CLI and MCP. ## Desired outcome and success criteria Add a bring-your-own Ghidra provider for supported macOS hosts. The provider should: - validate the Ghidra release, full JDK/Javac, host architecture, and `analyzeHeadless` path with actionable typed capability diagnostics; - support caller-configured absolute installation paths and never download or install Ghidra or Java implicitly; - provide the same admitted read-only operations and truthful capability metadata as the existing Ghidra provider; - analyze a digest-verified target copy/project with read-only settings, bounded CPU, memory, deadlines, cancellation, authentication, and verified cleanup; - avoid launching the Ghidra GUI and preserve the active target/provider binding on failure; - pass the shared native fixture suite for Mach-O and cross-format analysis, including malformed input, cancellation, concurrency, and cleanup cases. Document the exact supported Ghidra/JDK/host matrix, and report unsupported architectures or versions as unavailable rather than falling back silently to another provider. ## Authority boundaries and non-goals - Static Ghidra analysis only; no arbitrary scripting, target execution, runtime attachment, or database mutation through this provider. - BYO installation paths remain operator supplied; no implicit installation, licensing changes, or GUI launch. - Preserve provider neutrality and Evidence v2 authority/coverage metadata. ## Alternatives considered - The Hopper provider is a separate analysis engine and may expose a GUI window. It does not satisfy a requirement to use an installed Ghidra distribution headlessly. - Running Ghidra manually can answer questions but loses REA's normalized provider operations, session routing, and evidence linkage. - The native macOS inspection provider supplies deterministic Mach-O metadata but is not a full decompiler. ## Possible direction Extend the existing Ghidra adapter and its host-specific runtime/verification boundary to macOS after defining an explicit supported architecture and JDK matrix. Keep provider selection explicit and retain the existing no-fallback semantics. ## References - Ghidra provider configuration in the README: https://github.com/morluto/rea#ghidra-read-only-analysis-provider - Prior provider evaluation: #26 - Agent-first provider roadmap: #32

bsakaguchi

2026-10-15 18:23:04 +00:00

closed this issue
added the
triage

enhancement
labels

bsakaguchi commented

2026-10-15 18:23:06 +00:00

Author

Owner

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

Verified fixed on main (7a7460f0). src/ghidra/GhidraInstallation.ts admits darwin x64/arm64 with native-decompiler check, matching the requested bring-your-own macOS provider. Closing per audit.

@morluto commented on GitHub (Oct 8, 2026): Verified fixed on main (7a7460f0). src/ghidra/GhidraInstallation.ts admits darwin x64/arm64 with native-decompiler check, matching the requested bring-your-own macOS provider. Closing per audit.

bsakaguchi referenced this issue

2026-10-16 21:12:23 +00:00

[PR #257] [MERGED] docs(security): define controlled replay authority #1906

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:28:57 +00:00