[GH-ISSUE #1170] [Bug] Ghidra cannot select a function by the imported _main symbol from its name inventory #413

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

Originally created by @coygeek on GitHub (Oct 9, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1170

Before submitting

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

Area

Native analysis or decompilation

Observed behavior

With the Ghidra provider, list_names returns an imported label _main at the exact entry address of the function Ghidra names entry, but selecting _main in function/analyze_function or procedure_pseudo_code fails with invalid_request "Unknown Ghidra procedure name or address: _main". The address and the canonical name entry both work. The documentation tells callers to use the names the inventory returns, including platform symbol prefixes, so the C main of an ordinary unstripped macOS executable cannot be selected by the name an agent naturally tries.

list_names includes {"address":"0x100000328","value":"_main","symbol":{"primary":false,"type":"label","source":"imported"}}, and list_procedures includes entry at 0x100000328. Selecting _main exits 1 (CLI) or returns isError: true (MCP):

{"code":"invalid_request","details":{"operation":"analyze_function","issues":[{"path":[],"reason":"invalid_value","message":"Unknown Ghidra procedure name or address: _main"}]}}

Selecting entry or 0x100000328 returns the function and its pseudocode (undefined8 entry(void) { return 0; }). Reproduced on two separately built fixtures through CLI and MCP on the npm release, and through CLI and a raw MCP client on the main build. Other alias kinds and the Hopper and IDA providers were not tested.

Reproduction

export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC JAVA_HOME=/path/to/jdk-21
printf 'int main(void) { return 0; }\n' > minimal.c
clang -O0 minimal.c -o minimal
nm -nm minimal                 # _main at the entry address, 0x100000328 on this host
npx -y rea-agents@6.1.0 function ./minimal _main --provider ghidra --json; echo "exit=$?"
npx -y rea-agents@6.1.0 function ./minimal 0x100000328 --provider ghidra --json; echo "exit=$?"

Use the _main address nm prints if it differs. Over MCP, open_binary (provider_id: "ghidra"), then list_names, list_procedures, and analyze_function / procedure_pseudo_code with procedure: "_main" and with procedure: "entry" show the same split.

Expected behavior

docs/native-investigation.md (procedure identifiers): "an exact database symbol name takes precedence over a bare hexadecimal address ... Use the names returned by the inventory, including their namespaces and any platform symbol prefix." _main is an exact database symbol returned by the name inventory and sits at a function entry, so selecting it should return that function, the same result as entry or 0x100000328.

Impact and scope

Callers following the documented selector rule cannot select a C program's main by its inventory name with Ghidra; the failure is bounded and the target is not affected.

Workaround: Selecting the function by its address or by the canonical entry name returned by list_procedures works and was observed.

REA version

rea-agents@6.1.0 from npm, and main at 089bbf58f3 built locally with npm ci && npm run build:cached.

Runtime and platform

Node v24.21.0, macOS 27.0.1 (26A434), arm64; Apple clang 21.0.0.; Ghidra 12.1.4 (official ghidra_12.1.4_PUBLIC archive, macOS natives built with buildNatives), Eclipse Temurin JDK 21.0.12.1+1; rea doctor --provider ghidra --json healthy.

Target and artifact context

Unstripped arm64 Mach-O C executable (Ghidra provider)

Interface

CLI

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

  • Expected source: docs/native-investigation.md, procedure-identifier paragraph (unchanged on the main build).
  • Failure source: the list_names entry and selection error quoted under Observed behavior.
  • Evidence provenance: observed
  • Local verification: reproduced
  • Reproduction completeness: complete

Typed outcome or recovery expected

Failing now: function ./minimal _main --provider ghidra exits 1 with "Unknown Ghidra procedure name or address: _main". Restored: it exits 0 and returns the function at the _main address. Control: a label that is not at a function entry is still rejected rather than resolved to an enclosing function, and entry and the address keep working.

Analysis or suspected cause

Source-derived, not verified by a patch: bridge/ghidra/ReaGhidraBridge.java resolveProcedure matches only each function's own name or qualified symbol, not secondary symbols at a function's entry address. If only list_procedures names are meant to be selectors, the documentation's "names returned by the inventory" wording is the part that disagrees.

Additional context

Found while exercising typical REA workflows on macOS with rea-agents@6.1.0; each case was reproduced on the npm release and on a local build of main, and re-checked on main at 6a1e558db3 just before filing.

Originally created by @coygeek on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1170 ### 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 Native analysis or decompilation ### Observed behavior With the Ghidra provider, `list_names` returns an imported label `_main` at the exact entry address of the function Ghidra names `entry`, but selecting `_main` in `function`/`analyze_function` or `procedure_pseudo_code` fails with `invalid_request` "Unknown Ghidra procedure name or address: _main". The address and the canonical name `entry` both work. The documentation tells callers to use the names the inventory returns, including platform symbol prefixes, so the C `main` of an ordinary unstripped macOS executable cannot be selected by the name an agent naturally tries. `list_names` includes `{"address":"0x100000328","value":"_main","symbol":{"primary":false,"type":"label","source":"imported"}}`, and `list_procedures` includes `entry` at `0x100000328`. Selecting `_main` exits 1 (CLI) or returns `isError: true` (MCP): ```json {"code":"invalid_request","details":{"operation":"analyze_function","issues":[{"path":[],"reason":"invalid_value","message":"Unknown Ghidra procedure name or address: _main"}]}} ``` Selecting `entry` or `0x100000328` returns the function and its pseudocode (`undefined8 entry(void) { return 0; }`). Reproduced on two separately built fixtures through CLI and MCP on the npm release, and through CLI and a raw MCP client on the `main` build. Other alias kinds and the Hopper and IDA providers were not tested. ### Reproduction ```sh export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC JAVA_HOME=/path/to/jdk-21 printf 'int main(void) { return 0; }\n' > minimal.c clang -O0 minimal.c -o minimal nm -nm minimal # _main at the entry address, 0x100000328 on this host npx -y rea-agents@6.1.0 function ./minimal _main --provider ghidra --json; echo "exit=$?" npx -y rea-agents@6.1.0 function ./minimal 0x100000328 --provider ghidra --json; echo "exit=$?" ``` Use the `_main` address `nm` prints if it differs. Over MCP, `open_binary` (`provider_id: "ghidra"`), then `list_names`, `list_procedures`, and `analyze_function` / `procedure_pseudo_code` with `procedure: "_main"` and with `procedure: "entry"` show the same split. ### Expected behavior `docs/native-investigation.md` (procedure identifiers): "an exact database symbol name takes precedence over a bare hexadecimal address ... Use the names returned by the inventory, including their namespaces and any platform symbol prefix." `_main` is an exact database symbol returned by the name inventory and sits at a function entry, so selecting it should return that function, the same result as `entry` or `0x100000328`. ### Impact and scope Callers following the documented selector rule cannot select a C program's `main` by its inventory name with Ghidra; the failure is bounded and the target is not affected. Workaround: Selecting the function by its address or by the canonical `entry` name returned by `list_procedures` works and was observed. ### REA version `rea-agents@6.1.0` from npm, and `main` at 089bbf58f3561e3f465c544bbcf8c307287b1256 built locally with `npm ci && npm run build:cached`. ### Runtime and platform Node v24.21.0, macOS 27.0.1 (26A434), arm64; Apple clang 21.0.0.; Ghidra 12.1.4 (official `ghidra_12.1.4_PUBLIC` archive, macOS natives built with `buildNatives`), Eclipse Temurin JDK 21.0.12.1+1; `rea doctor --provider ghidra --json` healthy. ### Target and artifact context Unstripped arm64 Mach-O C executable (Ghidra provider) ### Interface CLI ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence - Expected source: `docs/native-investigation.md`, procedure-identifier paragraph (unchanged on the `main` build). - Failure source: the `list_names` entry and selection error quoted under Observed behavior. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete ### Typed outcome or recovery expected Failing now: `function ./minimal _main --provider ghidra` exits 1 with "Unknown Ghidra procedure name or address: _main". Restored: it exits 0 and returns the function at the `_main` address. Control: a label that is not at a function entry is still rejected rather than resolved to an enclosing function, and `entry` and the address keep working. ### Analysis or suspected cause Source-derived, not verified by a patch: `bridge/ghidra/ReaGhidraBridge.java` `resolveProcedure` matches only each function's own name or qualified symbol, not secondary symbols at a function's entry address. If only `list_procedures` names are meant to be selectors, the documentation's "names returned by the inventory" wording is the part that disagrees. ### Additional context Found while exercising typical REA workflows on macOS with `rea-agents@6.1.0`; each case was reproduced on the npm release and on a local build of `main`, and re-checked on `main` at 6a1e558db3ec2b69561e91ea817f1c2065dfc676 just before filing.
bsakaguchi 2026-10-15 18:24:51 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#413
No description provided.