morluto/rea

Fork 0

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

[GH-ISSUE #8696] [Design] Inspect explicitly selected code outside provider inventory #7515

New issue

Open

opened 2026-11-03 00:30:27 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 00:30:27 +00:00

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

How can an agent investigate references from a specific code address that the provider's procedure inventory did not recognize, while retaining what was actually decoded and what remains unexplored? Should this extend an existing REA investigation contract or use another bounded evidence workflow?

Context and evidence

On the self-owned arm64 Mach-O in #8362 (SHA-256 788ab9e10b0313cb3a60c3ca59baa0333b271b0ba022122b85408896932ef0b8), real REA/Kuna 1.989 full-schema stdio MCP resolves address_name(0x1000003e0) to _middle and incoming xrefs identifies _main's call site. But procedure_address and procedure_assembly reject the same address as absent from the discovered procedure inventory, procedure_callees reports its graph relationships unknown, and procedure_references is unavailable. The graph-based trace_call_path returns a complete-looking negative; #8443 addresses its discovery-scope reporting.

Direct Kuna 1.989 xrefs --from 0x1000003e0 --kind call --json reports the _middle to _goal call and says the explicitly requested address was decoded in an executable but non-code-marked section. For a paired fixture with the call replaced by NOP, the same query reports decoded with zero calls. Independent LLVM disassembly shows the call versus NOP. For _main, direct Kuna returns the call to _middle and reports _middle under coverage.unwalked. A nearby non-entry address, data address and unmapped address each return zero calls with coverage.decoded: false and different reasons. The three latter controls demonstrate why a successful empty answer alone cannot be treated as a covered negative.

The REA calls were full-profile only; earlier path controls also used compact. This is one host and two constructed binaries, not a provider-wide accuracy claim. Both target hashes remained unchanged and the binaries were not executed. Raw examples and version-specific context are in #8362. Kuna 1.989 is verified on proposed #8691, not current main.

Expected interaction with targets

Read the caller-selected local binary and launch the user-supplied static provider; any REA temporary workspace or cache writes remain owned and subject to existing cleanup. Do not execute or modify target code.

Boundary details

Keep the caller's explicit address distinct from a discovered function identity. Preserve source/destination, call-site kind, producer and target identity, decode/section observations and unwalked destinations. Distinguish unknown target, not decoded, decoded with no reported calls, and missing provider coverage. A provider's local decode is not proof of exhaustive call paths or runtime execution.

Options and tradeoffs

Compare extending an existing address-centered evidence contract with a bounded explicit-source investigation against a Ghidra-backed alternative and direct Kuna CLI use. Preserve typed data versus call semantics (#8190) without promising provider parity. Avoid an unconditional per-node xrefs pass in graph traversal; evaluate targeted calls, response budgets, timeouts and any bounded follow-up workflow.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise a recognized code entry, explicitly targeted unmarked executable entry with and without a call, non-entry, non-executable section and unmapped address; compare direct provider and REA in full/compact profiles, preserve source Evidence across export/import, and test malformed, partial and unavailable coverage. Establish which provider-reported facts are safe to normalize before designing any automatic traversal.

References

#8362 (false negative), #8443 (discovery scope), #8190 (outgoing data-reference semantics), #8200 (path call-site context), and upstream Noelo-Lab/kuna#1406.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Existing Ghidra-backed alternative

On the original fixture, real REA/Ghidra 12.1.4 with JDK 21 and both compact and full stdio MCP profiles recognized _middle as a function at 0x1000003e0. procedure_assembly returned bl 0x1000003c8; ret, procedure_callees returned _goal, and outgoing procedure_references returned the source/target and an UNCONDITIONAL_CALL ReferenceManager classification. trace_call_path returned reached. On the paired NOP fixture (full profile), Ghidra returned nop; ret, no callees or outgoing references, and a not-reached path. This is a practical alternative for the sampled target when the caller supplies Ghidra; observations are Ghidra's analysis and do not establish runtime behavior or universal provider coverage.

A full-profile interior-address control at 0x1000003e4 showed that these Ghidra procedure operations resolve the containing _middle function and return its function-wide reference at 0x1000003e0, rather than limiting the observation to instructions starting at the exact selected address. The non-executable data address 0x100004000 was rejected by those procedure operations as invalid. A new address-centered contract should make the selected-address versus containing-function distinction explicit and should not present function-wide results as exact-site references. Both artifacts stayed unchanged and were not executed; this is one host and fixture pair.

Recovery for a data address

With fresh-import Ghidra on the mapped data address 0x100004000, baseline #8691 returned invalid_request with generic schema-inspection recovery, although the detailed issue said no procedure exists at that address. On existing selector-recovery PR #8470 head c9039515e, real full and compact MCP instead surfaced the no-procedure reason and suggested inspecting the discovered inventory, without schema-inspection recovery. A subsequent full-profile read_bytes at that same address returned 2a000000, and a valid path query still succeeded in the same session. This demonstrates a usable data-inspection alternative in this fixture, but the procedure-recovery advice itself did not suggest read_bytes and does not establish whether data inspection is the caller's intended task. The target was unchanged and not executed.

Originally created by @morluto on GitHub (Nov 2, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8696 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed How can an agent investigate references from a specific code address that the provider's procedure inventory did not recognize, while retaining what was actually decoded and what remains unexplored? Should this extend an existing REA investigation contract or use another bounded evidence workflow? ### Context and evidence On the self-owned arm64 Mach-O in #8362 (SHA-256 `788ab9e10b0313cb3a60c3ca59baa0333b271b0ba022122b85408896932ef0b8`), real REA/Kuna 1.989 full-schema stdio MCP resolves `address_name(0x1000003e0)` to `_middle` and incoming `xrefs` identifies `_main`'s call site. But `procedure_address` and `procedure_assembly` reject the same address as absent from the discovered procedure inventory, `procedure_callees` reports its graph relationships unknown, and `procedure_references` is unavailable. The graph-based `trace_call_path` returns a complete-looking negative; #8443 addresses its discovery-scope reporting. Direct Kuna 1.989 `xrefs --from 0x1000003e0 --kind call --json` reports the `_middle` to `_goal` call and says the explicitly requested address was decoded in an executable but non-code-marked section. For a paired fixture with the call replaced by NOP, the same query reports decoded with zero calls. Independent LLVM disassembly shows the call versus NOP. For `_main`, direct Kuna returns the call to `_middle` and reports `_middle` under `coverage.unwalked`. A nearby non-entry address, data address and unmapped address each return zero calls with `coverage.decoded: false` and different reasons. The three latter controls demonstrate why a successful empty answer alone cannot be treated as a covered negative. The REA calls were full-profile only; earlier path controls also used compact. This is one host and two constructed binaries, not a provider-wide accuracy claim. Both target hashes remained unchanged and the binaries were not executed. Raw examples and version-specific context are in #8362. Kuna 1.989 is verified on proposed #8691, not current main. ### Expected interaction with targets Read the caller-selected local binary and launch the user-supplied static provider; any REA temporary workspace or cache writes remain owned and subject to existing cleanup. Do not execute or modify target code. ### Boundary details Keep the caller's explicit address distinct from a discovered function identity. Preserve source/destination, call-site kind, producer and target identity, decode/section observations and unwalked destinations. Distinguish unknown target, not decoded, decoded with no reported calls, and missing provider coverage. A provider's local decode is not proof of exhaustive call paths or runtime execution. ### Options and tradeoffs Compare extending an existing address-centered evidence contract with a bounded explicit-source investigation against a Ghidra-backed alternative and direct Kuna CLI use. Preserve typed data versus call semantics (#8190) without promising provider parity. Avoid an unconditional per-node xrefs pass in graph traversal; evaluate targeted calls, response budgets, timeouts and any bounded follow-up workflow. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise a recognized code entry, explicitly targeted unmarked executable entry with and without a call, non-entry, non-executable section and unmapped address; compare direct provider and REA in full/compact profiles, preserve source Evidence across export/import, and test malformed, partial and unavailable coverage. Establish which provider-reported facts are safe to normalize before designing any automatic traversal. ### References #8362 (false negative), #8443 (discovery scope), #8190 (outgoing data-reference semantics), #8200 (path call-site context), and upstream [Noelo-Lab/kuna#1406](https://github.com/Noelo-Lab/kuna/issues/1406). @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Existing Ghidra-backed alternative On the original fixture, real REA/Ghidra 12.1.4 with JDK 21 and both compact and full stdio MCP profiles recognized `_middle` as a function at `0x1000003e0`. `procedure_assembly` returned `bl 0x1000003c8; ret`, `procedure_callees` returned `_goal`, and outgoing `procedure_references` returned the source/target and an `UNCONDITIONAL_CALL` ReferenceManager classification. `trace_call_path` returned reached. On the paired NOP fixture (full profile), Ghidra returned `nop; ret`, no callees or outgoing references, and a not-reached path. This is a practical alternative for the sampled target when the caller supplies Ghidra; observations are Ghidra's analysis and do not establish runtime behavior or universal provider coverage. A full-profile interior-address control at `0x1000003e4` showed that these Ghidra procedure operations resolve the containing `_middle` function and return its function-wide reference at `0x1000003e0`, rather than limiting the observation to instructions starting at the exact selected address. The non-executable data address `0x100004000` was rejected by those procedure operations as invalid. A new address-centered contract should make the selected-address versus containing-function distinction explicit and should not present function-wide results as exact-site references. Both artifacts stayed unchanged and were not executed; this is one host and fixture pair. ### Recovery for a data address With fresh-import Ghidra on the mapped data address `0x100004000`, baseline #8691 returned `invalid_request` with generic schema-inspection recovery, although the detailed issue said no procedure exists at that address. On existing selector-recovery PR #8470 head `c9039515e`, real full and compact MCP instead surfaced the no-procedure reason and suggested inspecting the discovered inventory, without schema-inspection recovery. A subsequent full-profile `read_bytes` at that same address returned `2a000000`, and a valid path query still succeeded in the same session. This demonstrates a usable data-inspection alternative in this fixture, but the procedure-recovery advice itself did not suggest `read_bytes` and does not establish whether data inspection is the caller's intended task. The target was unchanged and not executed.

bsakaguchi added the

enhancement

triage

labels

2026-11-03 00:30:27 +00:00

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

No description provided.

Rows
Columns