[GH-ISSUE #806] [Bug] #348

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

MCP or agent integration

Observed behavior

Summary

REA's Windows Ghidra provider currently rejects a native 32-bit x86 PE executable. This prevents the standard native analysis workflow (open_binary, followed by function listing and decompilation) from analyzing x86 Windows programs on this host.

Environment and target

Host: Windows (win32), x64
Target: native PE executable, x86 (32-bit)
REA operation: open_binary, then binary_overview / list_procedures
Target SHA-256: aa177c69b8d1d0c4a25b200bd3a5413ec82fad7a39bbece2ec823c0912f1e6a5

open_binary recognizes the target successfully as format: pe, kind: executable, architecture: x86. The subsequent analysis request fails with provider_unavailable. The provider diagnostics say:

Windows Ghidra P0 accepts x86-64 PE targets only.

The diagnostic also reports that Ghidra is not configured (GHIDRA_INSTALL_DIR is unset); however, the target-support rejection explicitly excludes x86 PE files independently of that missing configuration.

Reproduction

Open a 32-bit Windows PE executable with REA's open_binary using the automatic provider selection.
Request binary_overview or list_procedures.

Expected behavior

It would be useful if the Windows Ghidra provider could analyze supported 32-bit x86 PE executables, or if the MCP clearly documented that x86 PE targets are outside its Windows support matrix and exposed an appropriate alternative when one is available.

Impact and scope

With this target, REA could identify the file but could not enumerate or decompile its functions. Consequently, a static investigation such as locating a key-generation routine could not proceed through the MCP.

REA version

4.1.0

Runtime and platform

NODE 22

Target and artifact context

No response

Interface

MCP

Earliest failure stage

Unknown

Relevant output or evidence

Typed outcome or recovery expected

No response

Analysis or suspected cause

No response

Additional context

No response

Originally created by @wajih8 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/806 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Observed behavior ## Summary REA's Windows Ghidra provider currently rejects a native 32-bit x86 PE executable. This prevents the standard native analysis workflow (`open_binary`, followed by function listing and decompilation) from analyzing x86 Windows programs on this host. ## Environment and target - Host: Windows (`win32`), x64 - Target: native PE executable, x86 (32-bit) - REA operation: `open_binary`, then `binary_overview` / `list_procedures` - Target SHA-256: `aa177c69b8d1d0c4a25b200bd3a5413ec82fad7a39bbece2ec823c0912f1e6a5` `open_binary` recognizes the target successfully as `format: pe`, `kind: executable`, `architecture: x86`. The subsequent analysis request fails with `provider_unavailable`. The provider diagnostics say: > Windows Ghidra P0 accepts x86-64 PE targets only. The diagnostic also reports that Ghidra is not configured (`GHIDRA_INSTALL_DIR` is unset); however, the target-support rejection explicitly excludes x86 PE files independently of that missing configuration. ### Reproduction 1. Open a 32-bit Windows PE executable with REA's `open_binary` using the automatic provider selection. 2. Request `binary_overview` or `list_procedures`. ### Expected behavior It would be useful if the Windows Ghidra provider could analyze supported 32-bit x86 PE executables, or if the MCP clearly documented that x86 PE targets are outside its Windows support matrix and exposed an appropriate alternative when one is available. ### Impact and scope With this target, REA could identify the file but could not enumerate or decompile its functions. Consequently, a static investigation such as locating a key-generation routine could not proceed through the MCP. ### REA version 4.1.0 ### Runtime and platform NODE 22 ### Target and artifact context _No response_ ### Interface MCP ### Earliest failure stage Unknown ### Relevant output or evidence ```text ``` ### Typed outcome or recovery expected _No response_ ### Analysis or suspected cause _No response_ ### Additional context _No response_

bsakaguchi

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