morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8772] [Bug] Ghidra ambiguous file-offset mapping suggests schema repair #7538

New issue

Open

opened 2026-11-03 10:21:17 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 10:21:17 +00:00

Owner

Originally created by @morluto on GitHub (Nov 3, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8772

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

A valid file-offset: selector that maps to more than one Ghidra analysis address returns both candidates in the error details, but top-level recovery tells the caller to inspect the input schema. The selector is valid; schema repair cannot choose a mapping.

Reproduction

On REA main 9ebbe67e, Node 24.22.1, macOS arm64, Ghidra 12.1.4 and JDK 21:

Build a small x86-64 PE DLL with at least two sections. In a disposable copy, set the second section's PointerToRawData to the first section's value, so both map file offset 0x400 to distinct analysis addresses. The fixture was not executed.
Open that copy with Ghidra through stdio MCP and call procedure_pseudo_code with { "procedure": "file-offset:0x400" }.
In compact and full output profiles the error is invalid_request, with details File offset 0x400 has multiple loaded mappings: [0x180001000, 0x180002000]; select an explicit analysis address, but top-level recovery is inspect_input_contract and advises schema repair.

The deliberately modified target SHA-256 was 9288ce1a1a3e4aae2a47ba0fc97c466c6258285ddff1cf4efdb62cfb52151595 and remained unchanged during analysis. The same result occurred on #8768 head 42df3e23e, which intentionally distinguishes procedure-name ambiguity without changing this mapping case.

Expected behavior

Preserve the file offset, distinct mappings and their ambiguity, and offer an explicit-address selection workflow without suggesting the schema is malformed or automatically selecting a mapping. Whether each mapping is a function remains unknown; selecting an address must not imply either is a valid procedure.

Impact and scope

The caller receives contradictory recovery but the provider does not silently choose a mapping. This is one constructed PE fixture and host; prevalence, CLI behavior and autonomous-agent behavior are unknown.

REA version

9ebbe67e

Runtime and platform

Node 24.22.1; macOS arm64; Ghidra 12.1.4 / JDK 21.

Target and artifact context

Source-owned, deliberately modified x86-64 PE DLL; static analysis only.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Both profiles reported the two mapping addresses in details.issues[0].message, with recovery.kind: inspect_input_contract. No successful explicit-address recovery was claimed for both mappings.

Typed outcome or recovery expected

A schema-valid ambiguous mapping outcome with explicit mapping selection and uncertainty about function identity.

Analysis or suspected cause

Source-derived: the bridge reports this mapping condition as remote ambiguous; the Ghidra adapter projects it via generic AnalysisInputError, which defaults to schema inspection. It is distinct from procedure-name ambiguity #8767 and file-backed address-to-offset ambiguity handling.

Additional context

Related #8767 and #8768. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8772 ### 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 A valid `file-offset:` selector that maps to more than one Ghidra analysis address returns both candidates in the error details, but top-level recovery tells the caller to inspect the input schema. The selector is valid; schema repair cannot choose a mapping. ### Reproduction On REA main `9ebbe67e`, Node 24.22.1, macOS arm64, Ghidra 12.1.4 and JDK 21: 1. Build a small x86-64 PE DLL with at least two sections. In a disposable copy, set the second section's `PointerToRawData` to the first section's value, so both map file offset `0x400` to distinct analysis addresses. The fixture was not executed. 2. Open that copy with Ghidra through stdio MCP and call `procedure_pseudo_code` with `{ "procedure": "file-offset:0x400" }`. 3. In compact and full output profiles the error is `invalid_request`, with details `File offset 0x400 has multiple loaded mappings: [0x180001000, 0x180002000]; select an explicit analysis address`, but top-level recovery is `inspect_input_contract` and advises schema repair. The deliberately modified target SHA-256 was `9288ce1a1a3e4aae2a47ba0fc97c466c6258285ddff1cf4efdb62cfb52151595` and remained unchanged during analysis. The same result occurred on #8768 head `42df3e23e`, which intentionally distinguishes procedure-name ambiguity without changing this mapping case. ### Expected behavior Preserve the file offset, distinct mappings and their ambiguity, and offer an explicit-address selection workflow without suggesting the schema is malformed or automatically selecting a mapping. Whether each mapping is a function remains unknown; selecting an address must not imply either is a valid procedure. ### Impact and scope The caller receives contradictory recovery but the provider does not silently choose a mapping. This is one constructed PE fixture and host; prevalence, CLI behavior and autonomous-agent behavior are unknown. ### REA version `9ebbe67e` ### Runtime and platform Node 24.22.1; macOS arm64; Ghidra 12.1.4 / JDK 21. ### Target and artifact context Source-owned, deliberately modified x86-64 PE DLL; static analysis only. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence Both profiles reported the two mapping addresses in `details.issues[0].message`, with `recovery.kind: inspect_input_contract`. No successful explicit-address recovery was claimed for both mappings. ### Typed outcome or recovery expected A schema-valid ambiguous mapping outcome with explicit mapping selection and uncertainty about function identity. ### Analysis or suspected cause Source-derived: the bridge reports this mapping condition as remote `ambiguous`; the Ghidra adapter projects it via generic `AnalysisInputError`, which defaults to schema inspection. It is distinct from procedure-name ambiguity #8767 and file-backed address-to-offset ambiguity handling. ### Additional context Related #8767 and #8768. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

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#7538

No description provided.

Rows
Columns