[GH-ISSUE #2417] [Design] Automatic analysis engine selection policy when multiple deep providers (Ghidra, Hopper, IDA) are available #812

New issue

Open

opened 2026-10-15 18:28:41 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:28:41 +00:00

Owner

Originally created by @matbrgz on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2417

Problem and Analyst Context

When an analyst or AI agent configures an analysis engine in REA (Hopper, Ghidra, or IDA), the system accepts provider_id: "auto" (or leaves it defaulted) during open_binary.

Today, in src/application/binary/AnalysisProviderRegistry.ts (lines 323–325), if a workstation has multiple working deep providers configured and available (for example, both Ghidra and Hopper installed on macOS, or both Ghidra and IDA on Linux/Windows) and an opened binary is supported by more than one provider, auto selection fails closed with an ambiguous selection error:

if (usable.length > 1)
  return err(selectionError("ambiguous", "auto", statuses));

This forces an AI model or caller to manually discover the installed engines and explicitly supply provider_id: "ghidra", "hopper", or "ida", rather than allowing REA to select the most suitable engine or allowing the agent to evaluate provider suitability automatically.

Proposed Improvement

Deterministic Prioritization / Capability Match Matrix:
- Define an explicit, deterministic auto-selection preference matrix when multiple engines are present, based on target format, architecture, and analysis fidelity.
- For example:
  - Objective-C / Swift Mach-O on macOS: Hopper preferred when fast UI/ObjC decompilation is prioritized; Ghidra or IDA when deep cross-architecture analysis is required.
  - Windows PE with sidecar PDB / complex x86: IDA or Ghidra preferred over Hopper.
  - MIPS / RISC-V / embedded: Ghidra preferred where Ghidra has dedicated processor modules.
Autonomous Model Selection & Discovery Surface:
- Ensure open_binary with provider_id: "auto" returns the list of all available candidate engines and their target compatibility status in the session metadata, allowing the agent/model to consciously inspect and switch providers (switch_analysis_provider / reopening) without failing the initial target admission.
- Provide explicit agent guidance in .agents/skills/reverse-engineer-anything/ explaining how agents should evaluate available providers when multiple are present on the host.

Acceptance Criteria

open_binary on a host with multiple available providers handles auto selection deterministically without failing with an unhandled ambiguous error.
Selection rationale is documented in the session Evidence with the evaluated candidates and their match criteria.
No target execution, mutation, or side-effect authority is introduced; all engines operate within their existing read-only bounds.
Specification created under docs/specs/providers/auto-provider-selection/ with spec.md, plan.md, and tasks.md.

Originally created by @matbrgz on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2417 [![Type: Architecture / RFC](https://img.shields.io/badge/type-architecture_%2F_RFC-darkred.svg?style=flat-square)](https://github.com/morluto/rea) [![Status: Proposed](https://img.shields.io/badge/status-proposed-blue.svg?style=flat-square)](https://github.com/morluto/rea) [![Ecosystem: REA](https://img.shields.io/badge/ecosystem-morluto%2Frea-8A2BE2.svg?style=flat-square)](https://github.com/morluto/rea) ### Problem and Analyst Context When an analyst or AI agent configures an analysis engine in REA (Hopper, Ghidra, or IDA), the system accepts `provider_id: "auto"` (or leaves it defaulted) during `open_binary`. Today, in `src/application/binary/AnalysisProviderRegistry.ts` (lines 323–325), if a workstation has **multiple working deep providers configured and available** (for example, both Ghidra and Hopper installed on macOS, or both Ghidra and IDA on Linux/Windows) and an opened binary is supported by more than one provider, auto selection fails closed with an ambiguous selection error: ```ts if (usable.length > 1) return err(selectionError("ambiguous", "auto", statuses)); ``` This forces an AI model or caller to manually discover the installed engines and explicitly supply `provider_id: "ghidra"`, `"hopper"`, or `"ida"`, rather than allowing REA to select the most suitable engine or allowing the agent to evaluate provider suitability automatically. ### Proposed Improvement 1. **Deterministic Prioritization / Capability Match Matrix:** - Define an explicit, deterministic auto-selection preference matrix when multiple engines are present, based on target format, architecture, and analysis fidelity. - For example: - Objective-C / Swift Mach-O on macOS: Hopper preferred when fast UI/ObjC decompilation is prioritized; Ghidra or IDA when deep cross-architecture analysis is required. - Windows PE with sidecar PDB / complex x86: IDA or Ghidra preferred over Hopper. - MIPS / RISC-V / embedded: Ghidra preferred where Ghidra has dedicated processor modules. 2. **Autonomous Model Selection & Discovery Surface:** - Ensure `open_binary` with `provider_id: "auto"` returns the list of all available candidate engines and their target compatibility status in the session metadata, allowing the agent/model to consciously inspect and switch providers (`switch_analysis_provider` / reopening) without failing the initial target admission. - Provide explicit agent guidance in `.agents/skills/reverse-engineer-anything/` explaining how agents should evaluate available providers when multiple are present on the host. ### Acceptance Criteria - [ ] `open_binary` on a host with multiple available providers handles auto selection deterministically without failing with an unhandled ambiguous error. - [ ] Selection rationale is documented in the session Evidence with the evaluated candidates and their match criteria. - [ ] No target execution, mutation, or side-effect authority is introduced; all engines operate within their existing read-only bounds. - [ ] Specification created under `docs/specs/providers/auto-provider-selection/` with `spec.md`, `plan.md`, and `tasks.md`.

bsakaguchi added the

area: native

enhancement

labels

2026-10-15 18:28:41 +00:00

bsakaguchi commented

2026-10-15 18:28:41 +00:00

Author

Owner

@whoishaha commented on GitHub (Oct 14, 2026):

I've submitted a Draft PR for #2417 implementing the agent-aware provider selection path.

The change admits multi-provider targets in a selection_required state, exposes eligible candidates to external agents, and supports explicit provider binding with deterministic selection Evidence.

I'd appreciate feedback on the proposed session contract and whether this behavior matches the intended scope before requesting final review.

Draft PR: #3090

@whoishaha commented on GitHub (Oct 14, 2026): I've submitted a Draft PR for #2417 implementing the agent-aware provider selection path. The change admits multi-provider targets in a `selection_required` state, exposes eligible candidates to external agents, and supports explicit provider binding with deterministic selection Evidence. I'd appreciate feedback on the proposed session contract and whether this behavior matches the intended scope before requesting final review. Draft PR: [#3090](https://github.com/morluto/rea/pull/3090)

bsakaguchi referenced this issue

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

[PR #812] [CLOSED] fix(native): project Mach-O evidence into container file offsets #2259

bsakaguchi referenced this issue

2026-10-16 21:16:27 +00:00

[PR #815] [MERGED] fix: integrate 24 reviewed browser/native/semantics corrections #2262

bsakaguchi added

enhancement

and removed

enhancement

labels

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