[GH-ISSUE #8068] [Design] Make Ghidra decompile coordinate intent explicit for unresolved canonical hex selectors #4666

New issue

Open

opened 2026-10-31 00:52:12 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:52:12 +00:00

Owner

Originally created by @Xipong on GitHub (Oct 29, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8068

Problem observed

During a Ghidra investigation I passed procedure_pseudo_code an analysis VA that was not a recognized procedure in that analysis profile. Instead of failing in that coordinate system, decompilation succeeded for a different function after treating the same number as a source-file offset. I had to exclude that result from my investigation and add an exact-entry preflight to the client.

This is a selection-contract/agent-safety request, not a claim that REA forged locations or that file-offset support itself is broken. The result does retain the mapping. I understand #2078 and merged #2101 deliberately introduced this fallback; the uncovered need is a way to state analysis-coordinate intent and fail closed without changing that intent.

Observed request/result

Installed rea-agents 6.7.0, Ghidra 12.1.4, Linux x64/WSL. Target: a local PE32/x86 executable. No target execution was needed.

{"procedure":"0x4198e0"}

The successful response contained:

{"file_offset":4298976,"mapped_address":"0x8198e0","procedure_address":"0x819875"}

This is retained output from an actual earlier native analysis, read back during this audit; I did not reimport the binary just to file this report. The target binary and pseudocode are not attached. The reproduction condition is an unresolved analysis-address selector whose numeric value also has a valid source mapping into another procedure. Preflighting the intended address and validating the returned canonical entry prevents the mistake in our client.

Current upstream / expected behavior

Source inspection at main 317bf3fe235e655b2d752d3be261cc0da7d00f2b still shows the not_found + 0x[0-9a-fA-F]+ fallback in resolveDecompileProcedure. Published 6.8.0 was also inspected; it was not runtime-tested here.

Please provide/document an unambiguous analysis-address mode for decompile, for example an explicit typed selector or strict-address option. In that mode an unresolved VA should remain not_found, not be retried as a file offset. Existing explicit file-offset:0x... selection and legacy fallback could remain available for callers that want them. If a supported strict selector already exists, documenting its exact CLI/MCP syntax alongside the canonical 0x... addresses would address an important part of this request.

Suggested checks: recognized VA retains its function; unresolved strict VA fails even when the numeric file offset maps elsewhere; explicit file offset still succeeds and retains both mapped coordinates. These are proposed acceptance checks, not a claimed run on current main.

Impact and scope

A successful but semantically different function can mislead downstream reverse-engineering conclusions unless every client independently checks selection metadata. This is not a regression attribution, arbitrary-code-execution report, or request to remove useful offset support.

Originally created by @Xipong on GitHub (Oct 29, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8068 ### Problem observed During a Ghidra investigation I passed `procedure_pseudo_code` an analysis VA that was not a recognized procedure in that analysis profile. Instead of failing in that coordinate system, decompilation succeeded for a different function after treating the same number as a source-file offset. I had to exclude that result from my investigation and add an exact-entry preflight to the client. This is a selection-contract/agent-safety request, **not** a claim that REA forged locations or that file-offset support itself is broken. The result does retain the mapping. I understand #2078 and merged #2101 deliberately introduced this fallback; the uncovered need is a way to state **analysis-coordinate intent** and fail closed without changing that intent. ### Observed request/result Installed `rea-agents` **6.7.0**, Ghidra **12.1.4**, Linux x64/WSL. Target: a local PE32/x86 executable. No target execution was needed. ```json {"procedure":"0x4198e0"} ``` The successful response contained: ```json {"file_offset":4298976,"mapped_address":"0x8198e0","procedure_address":"0x819875"} ``` This is retained output from an actual earlier native analysis, read back during this audit; I did **not** reimport the binary just to file this report. The target binary and pseudocode are not attached. The reproduction condition is an unresolved analysis-address selector whose numeric value also has a valid source mapping into another procedure. Preflighting the intended address and validating the returned canonical entry prevents the mistake in our client. ### Current upstream / expected behavior Source inspection at main `317bf3fe235e655b2d752d3be261cc0da7d00f2b` still shows the `not_found` + `0x[0-9a-fA-F]+` fallback in [resolveDecompileProcedure](https://github.com/morluto/rea/blob/317bf3fe235e655b2d752d3be261cc0da7d00f2b/bridge/ghidra/ReaGhidraBridge.java#L981-L1035). Published 6.8.0 was also inspected; it was not runtime-tested here. Please provide/document an unambiguous analysis-address mode for decompile, for example an explicit typed selector or strict-address option. In that mode an unresolved VA should remain `not_found`, not be retried as a file offset. Existing explicit `file-offset:0x...` selection and legacy fallback could remain available for callers that want them. If a supported strict selector already exists, documenting its exact CLI/MCP syntax alongside the canonical `0x...` addresses would address an important part of this request. Suggested checks: recognized VA retains its function; unresolved strict VA fails even when the numeric file offset maps elsewhere; explicit file offset still succeeds and retains both mapped coordinates. These are proposed acceptance checks, not a claimed run on current main. ### Impact and scope A successful but semantically different function can mislead downstream reverse-engineering conclusions unless every client independently checks selection metadata. This is not a regression attribution, arbitrary-code-execution report, or request to remove useful offset support.

bsakaguchi commented

2026-10-31 00:52:14 +00:00

Author

Owner

@bonro commented on GitHub (Oct 30, 2026):

We offer the full series of GPT models at 0.2x official pricing and the full series of Claude models at 0.3x official pricing, available now at lanmu1313.top.

@bonro commented on GitHub (Oct 30, 2026): We offer the full series of GPT models at 0.2x official pricing and the full series of Claude models at 0.3x official pricing, available now at lanmu1313.top.

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

No description provided.

Rows
Columns