[GH-ISSUE #747] [Feature] Integrate IDA Pro MCP as an attached and headless analysis provider #332

New issue

Closed

opened 2026-10-15 18:24:00 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:24:00 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/747

Before submitting

Searched related issues and pull requests, including #26 and #740.
Removed credentials, private paths, and sensitive target data.

Area

Provider or capability discovery; native analysis; CLI and MCP integration.

Current limitation

REA does not currently adapt IDA Pro as a deep-analysis provider. Analysts who already run IDA Pro MCP must manage a separate connection, provider-specific tools, target identity, and database lifecycle. This interrupts REA's intended experience: connect once, select a target and question, and start analyzing.

Use cases

Analyze the target already open in an existing IDA GUI through REA's native analysis operations, without modifying or closing the user's database.
Give REA a local binary and let an upstream headless IDA MCP instance open and analyze it, with bounded resource use and deterministic session cleanup.
Use the same application workflows and evidence contracts through the CLI and MCP.

Desired outcome and success criteria

Implement a bring-your-own adapter for mrexodia/ida-pro-mcp. Reuse upstream installation and configuration rather than maintaining another IDA server or installer.

flowchart LR
  Agent --> REA[REA CLI / MCP]
  REA --> Provider[IDA provider adapter]
  Provider --> Upstream[Existing IDA Pro MCP]
  Upstream --> GUI[Attached IDA GUI database]
  Upstream --> Headless[Headless database worker]

Phase 1: attached GUI, read-only analysis

Add provider-owned transport, protocol parsing, and result normalization under src/ida/; keep wire protocols outside domain and application layers.
Reuse an upstream stdio registration or supported HTTP transport with one-time configuration.
Adapt supported function inventory, literal/regex search, function resolution, pseudocode, assembly, and observed relationships into existing provider-neutral operations.
Match the admitted target to upstream evidence; reject mismatches and unsupported or missing identity information with actionable errors.
Preserve reported addresses, metadata, upstream output, and limitations. Distinguish recorded input identity, live database observations, and unknown database revisions.
Prevent stale snapshots for externally mutable databases and detect changes to the attached target around operations.
Close only REA-owned connections or proxy processes; preserve the existing GUI and database.
Exercise real CLI and MCP analysis against the installed GUI provider, as well as malformed input, failure, cancellation, and lifecycle boundaries.

Phase 2: headless target and database lifecycle

Adapt upstream database open/list/close semantics and inject the returned database identity into every database-scoped request.
Open the caller-selected target without executing it, prefer headless operation, and bind the opened database to admitted artifact identity.
Bound owned worker concurrency and avoid unbounded engine, memory, or disk use.
Release owned sessions on close, target replacement, failed startup, and cancellation; do not save a read-only session or terminate adopted user sessions.
Verify the actual upstream lifecycle representation and ownership rules rather than inferring them from tool names.
Test real headless target analysis and cleanup where the installed IDA/idalib toolchain supports it; clearly distinguish real coverage from mock protocol coverage.

Shared integration and onboarding

Register IDA through REA's existing provider composition and selection mechanisms.
Advertise exact supported operations and effects; do not claim unsupported facets or mutations.
Document upstream prerequisites, version/profile differences, minimal working configuration, and equivalent CLI/MCP examples in English.
Keep generated metadata, provider guides, skills, and packaged artifacts aligned.
Run focused regressions, relevant static and generated-document checks, a packaged startup/analysis check, and an independent self-review before a ready-for-review PR.

Authority boundaries and non-goals

The initial integration is read-only with respect to the caller's binary and analysis database. No debugging, target execution, patches, renames, annotations, arbitrary Python forwarding, GUI manipulation, or automatic database saves. Starting a configured MCP proxy or headless analysis worker is an explicit lifecycle effect, not target execution.

REA does not install or upgrade IDA, Python, idalib, upstream MCP, or unrelated toolchains; licensing and upstream setup remain the user's responsibility. Do not vendor the upstream server. Do not close existing GUI databases or delete unrelated files. Keep engine version and protocol/profile version distinct, and report unknowns honestly.

Alternatives considered

A separate upstream IDA MCP connection already works, but leaves target/session/evidence orchestration outside REA.
A new IDAPython server would duplicate upstream protocol and lifecycle maintenance.
Waiting for the wider architecture work in #740 is unnecessary: the existing provider registry and shared workflows provide an integration seam.

Possible direction and current evidence

Use the existing pinned MCP client SDK behind a typed provider boundary. The installed legacy GUI distribution and current upstream headless supervisor use different tool and session representations; support explicit compatibility profiles rather than guessing equivalence.

Observed locally: an SDK client can initialize the existing stdio proxy, retrieve metadata, list functions, and decompile a function; closing the proxy leaves the GUI available. This establishes upstream connectivity only. REA provider behavior, target binding, caching, and headless lifecycle still require implementation and real verification.

References

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/747 ## Before submitting - [x] Searched related issues and pull requests, including #26 and #740. - [x] Removed credentials, private paths, and sensitive target data. ## Area Provider or capability discovery; native analysis; CLI and MCP integration. ## Current limitation REA does not currently adapt IDA Pro as a deep-analysis provider. Analysts who already run IDA Pro MCP must manage a separate connection, provider-specific tools, target identity, and database lifecycle. This interrupts REA's intended experience: connect once, select a target and question, and start analyzing. ## Use cases 1. Analyze the target already open in an existing IDA GUI through REA's native analysis operations, without modifying or closing the user's database. 2. Give REA a local binary and let an upstream headless IDA MCP instance open and analyze it, with bounded resource use and deterministic session cleanup. 3. Use the same application workflows and evidence contracts through the CLI and MCP. ## Desired outcome and success criteria Implement a bring-your-own adapter for [mrexodia/ida-pro-mcp](https://github.com/mrexodia/ida-pro-mcp). Reuse upstream installation and configuration rather than maintaining another IDA server or installer. ```mermaid flowchart LR Agent --> REA[REA CLI / MCP] REA --> Provider[IDA provider adapter] Provider --> Upstream[Existing IDA Pro MCP] Upstream --> GUI[Attached IDA GUI database] Upstream --> Headless[Headless database worker] ``` ### Phase 1: attached GUI, read-only analysis - [ ] Add provider-owned transport, protocol parsing, and result normalization under `src/ida/`; keep wire protocols outside domain and application layers. - [ ] Reuse an upstream stdio registration or supported HTTP transport with one-time configuration. - [ ] Adapt supported function inventory, literal/regex search, function resolution, pseudocode, assembly, and observed relationships into existing provider-neutral operations. - [ ] Match the admitted target to upstream evidence; reject mismatches and unsupported or missing identity information with actionable errors. - [ ] Preserve reported addresses, metadata, upstream output, and limitations. Distinguish recorded input identity, live database observations, and unknown database revisions. - [ ] Prevent stale snapshots for externally mutable databases and detect changes to the attached target around operations. - [ ] Close only REA-owned connections or proxy processes; preserve the existing GUI and database. - [ ] Exercise real CLI and MCP analysis against the installed GUI provider, as well as malformed input, failure, cancellation, and lifecycle boundaries. ### Phase 2: headless target and database lifecycle - [ ] Adapt upstream database open/list/close semantics and inject the returned database identity into every database-scoped request. - [ ] Open the caller-selected target without executing it, prefer headless operation, and bind the opened database to admitted artifact identity. - [ ] Bound owned worker concurrency and avoid unbounded engine, memory, or disk use. - [ ] Release owned sessions on close, target replacement, failed startup, and cancellation; do not save a read-only session or terminate adopted user sessions. - [ ] Verify the actual upstream lifecycle representation and ownership rules rather than inferring them from tool names. - [ ] Test real headless target analysis and cleanup where the installed IDA/idalib toolchain supports it; clearly distinguish real coverage from mock protocol coverage. ### Shared integration and onboarding - [ ] Register IDA through REA's existing provider composition and selection mechanisms. - [ ] Advertise exact supported operations and effects; do not claim unsupported facets or mutations. - [ ] Document upstream prerequisites, version/profile differences, minimal working configuration, and equivalent CLI/MCP examples in English. - [ ] Keep generated metadata, provider guides, skills, and packaged artifacts aligned. - [ ] Run focused regressions, relevant static and generated-document checks, a packaged startup/analysis check, and an independent self-review before a ready-for-review PR. ## Authority boundaries and non-goals The initial integration is read-only with respect to the caller's binary and analysis database. No debugging, target execution, patches, renames, annotations, arbitrary Python forwarding, GUI manipulation, or automatic database saves. Starting a configured MCP proxy or headless analysis worker is an explicit lifecycle effect, not target execution. REA does not install or upgrade IDA, Python, idalib, upstream MCP, or unrelated toolchains; licensing and upstream setup remain the user's responsibility. Do not vendor the upstream server. Do not close existing GUI databases or delete unrelated files. Keep engine version and protocol/profile version distinct, and report unknowns honestly. ## Alternatives considered - A separate upstream IDA MCP connection already works, but leaves target/session/evidence orchestration outside REA. - A new IDAPython server would duplicate upstream protocol and lifecycle maintenance. - Waiting for the wider architecture work in #740 is unnecessary: the existing provider registry and shared workflows provide an integration seam. ## Possible direction and current evidence Use the existing pinned MCP client SDK behind a typed provider boundary. The installed legacy GUI distribution and current upstream headless supervisor use different tool and session representations; support explicit compatibility profiles rather than guessing equivalence. Observed locally: an SDK client can initialize the existing stdio proxy, retrieve metadata, list functions, and decompile a function; closing the proxy leaves the GUI available. This establishes upstream connectivity only. REA provider behavior, target binding, caching, and headless lifecycle still require implementation and real verification. ## References - [Upstream IDA Pro MCP](https://github.com/mrexodia/ida-pro-mcp) - [Upstream headless session model](https://github.com/mrexodia/ida-pro-mcp#headless-idalib-session-model) - [Legacy 1.4.0 adapter source](https://github.com/mrexodia/ida-pro-mcp/tree/1.4.0/src/ida_pro_mcp) - #26 - #740

bsakaguchi

2026-10-15 18:24:00 +00:00