[GH-ISSUE #790] [Bug] Ghidra bridge discovery collides with a same-named working-directory entry #345

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

Ghidra provider launch and bridge-script identity.

Observed behavior

On real Windows x64, the packaged Ghidra provider fails to load its bridge when the current working directory contains an empty directory named ReaGhidraBridge.java. The correct installed bridge exists, is readable by ordinary-user Node and Java, and is listed in Ghidra's configured script paths. Ghidra nevertheless selects the same-named working-directory entry, finishes analyzing the owned PE, then reports that it cannot find the source bundle containing the script.

Removing only the empty working-directory entry allows the same package, target, engine, and launch environment to pass full CLI and MCP acceptance. This was observed in an isolated audit prefix after a failed batch invocation left empty argument-named directories. It is independent of the path-separator fix in #786: the bridge argument remains a basename in both revisions.

Reproduction

With an existing Ghidra/JDK registration and a small source-owned native x86-64 PE fixture:

New-Item -ItemType Directory .\ReaGhidraBridge.java
rea inspect .\fixture.exe --provider ghidra --json

Run from the directory containing the empty same-named entry. Remove that owned empty directory and repeat to obtain a passing control. No target code needs to run.

Expected behavior

Select the exact packaged bridge script independently of unrelated entries in the caller's working directory. Keep the configured script source directory for bundle compilation and use explicit script coordinates where the producer accepts them.

Impact and scope

A valid installation becomes unusable because of a working-directory name collision; the failure appears after engine analysis and looks like an installation or script compilation problem. Observed Windows behavior only. Similar behavior on other hosts and the COM preparation script are source-derived risks, not executed claims. No arbitrary-script execution or permission bypass was demonstrated.

REA version

4.1.0; source baseline e1ca412757 with the ordinary-separator fix under test.

Runtime and platform

Windows x64, Node 22.19.0, Ghidra 12.1.4, JDK 21, independently verified ordinary-user token, isolated native npm package.

Target and artifact context

Small source-owned native x86-64 PE; bytes and digest were preserved. Passing control completed all admitted read-only operations and cleanup.

Interface

Packaged CLI and MCP Ghidra provider.

Earliest failure stage

Provider bridge startup / script discovery.

Relevant output or evidence

Failed to find script in any script directory: <working-directory>/ReaGhidraBridge.java
Failed to find source bundle containing script: <working-directory>/ReaGhidraBridge.java

Ordinary-user Java ResourceFile probes separately verified that the installed source exists and that the same-named relative directory also returns exists=true. Private raw diagnostics are retained locally.

Typed outcome or recovery expected

Opening a supported target should use REA's packaged bridge without requiring users to inspect or clean unrelated working-directory entries. Real unsupported or missing script failures should remain actionable.

Analysis or suspected cause

REA's ghidraHeadlessArguments supplies -scriptPath for the installed bridge directory but passes only basename(bridgeScriptPath) to -postScript. The locally installed upstream HeadlessAnalyzer.findScript first canonicalizes the script argument against the working directory and accepts any existing entry before consulting GhidraScriptUtil.findScriptByName. The selected empty directory is outside the registered source bundles.

Additional context

A focused regression should place a same-named inert file or directory in the caller cwd and verify that the packaged script is selected, with the original input byte oracle and cleanup assertions. Avoid introducing a working-directory cleanup requirement or another preparation step for users.

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/790 ### 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 Ghidra provider launch and bridge-script identity. ### Observed behavior On real Windows x64, the packaged Ghidra provider fails to load its bridge when the current working directory contains an empty directory named `ReaGhidraBridge.java`. The correct installed bridge exists, is readable by ordinary-user Node and Java, and is listed in Ghidra's configured script paths. Ghidra nevertheless selects the same-named working-directory entry, finishes analyzing the owned PE, then reports that it cannot find the source bundle containing the script. Removing only the empty working-directory entry allows the same package, target, engine, and launch environment to pass full CLI and MCP acceptance. This was observed in an isolated audit prefix after a failed batch invocation left empty argument-named directories. It is independent of the path-separator fix in #786: the bridge argument remains a basename in both revisions. ### Reproduction With an existing Ghidra/JDK registration and a small source-owned native x86-64 PE fixture: ```powershell New-Item -ItemType Directory .\ReaGhidraBridge.java rea inspect .\fixture.exe --provider ghidra --json ``` Run from the directory containing the empty same-named entry. Remove that owned empty directory and repeat to obtain a passing control. No target code needs to run. ### Expected behavior Select the exact packaged bridge script independently of unrelated entries in the caller's working directory. Keep the configured script source directory for bundle compilation and use explicit script coordinates where the producer accepts them. ### Impact and scope A valid installation becomes unusable because of a working-directory name collision; the failure appears after engine analysis and looks like an installation or script compilation problem. Observed Windows behavior only. Similar behavior on other hosts and the COM preparation script are source-derived risks, not executed claims. No arbitrary-script execution or permission bypass was demonstrated. ### REA version 4.1.0; source baseline e1ca412757bb01be855a66bf72006e3becd497b6 with the ordinary-separator fix under test. ### Runtime and platform Windows x64, Node 22.19.0, Ghidra 12.1.4, JDK 21, independently verified ordinary-user token, isolated native npm package. ### Target and artifact context Small source-owned native x86-64 PE; bytes and digest were preserved. Passing control completed all admitted read-only operations and cleanup. ### Interface Packaged CLI and MCP Ghidra provider. ### Earliest failure stage Provider bridge startup / script discovery. ### Relevant output or evidence ```text Failed to find script in any script directory: <working-directory>/ReaGhidraBridge.java Failed to find source bundle containing script: <working-directory>/ReaGhidraBridge.java ``` Ordinary-user Java ResourceFile probes separately verified that the installed source exists and that the same-named relative directory also returns exists=true. Private raw diagnostics are retained locally. ### Typed outcome or recovery expected Opening a supported target should use REA's packaged bridge without requiring users to inspect or clean unrelated working-directory entries. Real unsupported or missing script failures should remain actionable. ### Analysis or suspected cause REA's ghidraHeadlessArguments supplies `-scriptPath` for the installed bridge directory but passes only `basename(bridgeScriptPath)` to `-postScript`. The locally installed upstream HeadlessAnalyzer.findScript first canonicalizes the script argument against the working directory and accepts any existing entry before consulting GhidraScriptUtil.findScriptByName. The selected empty directory is outside the registered source bundles. ### Additional context A focused regression should place a same-named inert file or directory in the caller cwd and verify that the packaged script is selected, with the original input byte oracle and cleanup assertions. Avoid introducing a working-directory cleanup requirement or another preparation step for users.

bsakaguchi

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