morluto/rea

Fork 0

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

[GH-ISSUE #8569] [Design] Find references to a selected data range #6655

New issue

Open

opened 2026-11-01 21:12:59 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:59 +00:00

Owner

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

Decision needed

How should an analyst discover incoming references to an explicitly selected address range, such as a matched table or data object, without one xrefs call per byte or an unsupported claim that the first address represents the whole range?

Context and evidence

Real compact stdio MCP with REA 96ba4225, Kuna 1.988 and Ghidra 12.1.4 on macOS arm64: an owned arm64 Mach-O placed a 256-byte table at 0x100000398; its lookup function directly loaded byte 16 at 0x1000003a8. For both providers, xrefs on the table start returned [], while xrefs on the interior address returned source 0x10000037c. The existing xrefs contract is exact-address and its results did not claim a range; this is a task-level opportunity, not a violation of that contract.

Independent llvm-objdump showed the load at 0x10000037c. Direct Kuna crypto --algorithm aes associated the whole table with _audit_lookup despite direct xrefs at the start being empty. The fixture contains a known AES S-box and a lookup, but no AES implementation; neither static match nor reference proves runtime use or encryption. The target SHA-256 597c08e1d2d8732cdfad7170f61b28cf9d25be4be65d7bc9e7486faf00f740ad was unchanged and it was not executed.

String trace control

On current REA 85013da0c, an owned x86-64 ELF has UTF-8 éclair at 0x200175 (eight bytes including NUL) and an instruction at 0x2011ac whose disassembly points to the interior address 0x200177. Kuna 1.988 direct strings with reference walking reported the string, one reference and function _start; its --no-xrefs mode returned zero and no functions because it skipped the walk. REA/Kuna search_strings found the same string; exact xrefs at 0x200175 returned none, while exact xrefs at 0x200177 returned 0x2011ac. trace_feature({query:"éclair"}) returned the match but no references, truncated:false, and no residual unknowns; its Evidence does state that Kuna xrefs are exact-address and empty results do not prove absence. REA/Ghidra exact xrefs also found the interior address, but its defined-string search did not discover this UTF-8 candidate. The target was not executed and its SHA-256 2e67fc0604eb81d8727da3b70581f88d69af1dd20d4684d6adbd8d1b916a7a7e was unchanged.

Pinned Kuna string source scans reference destinations through the observed byte extent and returns aggregate referring functions; it does not return a per-reference mapping for the range. Thus a range-aware handoff could help string tracing as well as tables, but those aggregate function observations cannot be treated as exact site-to-function mappings. The reference is static, and does not prove runtime use. See also #8184 for trace coverage.

A separate owned x86-64 ELF placed UTF-16LE WIDER at 0x20017e and an instruction at 0x2011b3 addressing 0x200180. On real REA/Kuna 1.988, both schema profiles found the string and interior xref, but trace_feature returned no references. Ghidra 12.1.4 fresh import found the interior xref but did not define the string. After defining it in an owned Ghidra project with a headless script, real REA/Ghidra existing-project mode found the string and the same interior reference, but the trace again returned none in both profiles. The tested #8575 branch reported its address-only caveat in Evidence. This explicitly distinguishes absent inventory from the range lookup; the project was deliberately authored for the test and remained unchanged during REA use. The target was unexecuted and SHA-256 4c1031ec3d29b65f5c16c381aa89175e7a00f90e7d7b693618ca28324d51fc23 was unchanged.

String extent boundary control

A third unexecuted x86-64 ELF gives WIDER a 12-byte UTF-16LE extent at 0x20017e–0x200189, including the two-byte terminator. Instructions refer to 0x200180 (interior), 0x200188 (terminator), and 0x20018a (immediately after the extent). Kuna 1.988 direct strings reported two references for WIDER; --no-xrefs reported zero because the walk was skipped. Real REA compact MCP exact xrefs from both Kuna and Ghidra returned the interior and terminator sites individually and two separate sources at the immediately following address; the string start returned none. Independent disassembly matched those addresses. SHA-256 c94e783728a59d55918d60136e289c8a6ce4a9425f9f0519a9da030924508f84 remained unchanged.

This one control is consistent with Kuna counting its observed half-open byte extent, including the terminator but excluding the next byte. It does not prove runtime string use. A range-aware UX must specify whether the caller selected the full encoded extent, text payload only, or other explicit bounds, and must preserve the actual destination: a terminator reference should not be silently described as a character access, and an adjacent object should not be folded into the string.

Provider implementation controls

Using Ghidra 12.1.4 headless with an owned project and a script calling ReferenceManager.getReferenceDestinationIterator(AddressSet, true), the inclusive range 0x100000398–0x1000003a7 did not include the observed load destination; extending the end one byte to 0x1000003a8 returned the READ reference from 0x10000037c to 0x1000003a8. Both ranges also returned a synthetic Entry Point / EXTERNAL reference to the table start. REA's existing exact-address Ghidra xrefs omits such synthetic non-actionable sources, as its limitation states. The project was created for this control and the target was not executed.

The installed Ghidra script example and this control demonstrate an address-set destination iterator; they do not prove its asymptotic performance, pagination behavior or complete indirect-reference coverage. Source inspection of Kuna v1.988's crypto implementation shows it builds a reference index and checks each address in each matched range against that in-memory index. Its CLI returns aggregate counts and functions, not the full per-reference range result needed by this proposal. The two providers therefore need independently verified adapters and source/coverage semantics; do not infer identical completeness or cost.

Multiple references at one destination

A second owned arm64 Mach-O fixture had two separate functions loading the same table byte. Independent Ghidra 12.1.4 headless getReferenceDestinationIterator returned one in-range destination 0x1000003b4 with two READ references from 0x10000037c and 0x10000039c, plus a separate synthetic entry-point reference to the table start. Real REA compact MCP exact xrefs at 0x1000003b4 returned both source addresses for both Ghidra and Kuna 1.988; the table-start query returned none. The target was unexecuted and SHA-256 stayed 4818a9e2164a816dd1274b5384999832ec7ba2b6558435c8f074fddbd073171a.

For a future paged range result, a page may stop within one destination's reference group. A cursor that resumes only at the next destination could lose rows; an inclusive destination-only cursor could repeat them. Define stable reference identity/order and a resume position within the group, or use another design that proves no skips or duplicates. This is a proposed verification requirement, not a reproduced defect in an existing range tool.

Headless pagination control

On the two-reference Mach-O above, an independent Ghidra 12.1.4 headless script enumerated the fixed project range with one memory reference per page. The complete enumeration returned 0x10000037c -> 0x1000003b4 and 0x10000039c -> 0x1000003b4 (both READ, operand 1). After returning the first, resuming strictly after the destination returned no rows, while resuming inclusively at that destination repeated the first. Re-enumerating the destination and skipping one admitted memory reference returned the second. The script filtered synthetic non-memory entry points before applying its offset; the fixture digest stayed unchanged.

This is a single fixed-project control, not proof that an offset or Ghidra iteration order is stable across requests, edits, providers, or reanalysis. A production design must bind continuation to an appropriate snapshot/order or retain its own stable result, define filtering before cursor accounting, and check cancellation and boundedness. The initial experimental script also logged REPORT SCRIPT ERROR for an invalid address range despite analyzeHeadless exiting zero; the corrected control asserted all rows and inspected its log. No REA range pagination implementation was exercised.

Existing retained-view primitive

Source inspection on REA 85013da0c: native-observation views page a retained observation with offset/limit and preserve source indices; their paging coverage describes the retained rows. This is a potential delivery pattern after bounded acquisition, not a ready-made live range-reference cursor or proof that an upstream producer found every edge. The current supported primitive operations do not include a range-reference observation. Any new workflow must separately establish acquisition bounds, provider coverage, and the lifetime/identity of the retained result before applying a view.

Existing function-scoped detail

On the two-reference fixture, real Ghidra compact MCP procedure_references(direction: "outgoing") for the already-known _audit_lookup and _audit_second functions returned each exact source and interior destination, source procedure, READ classification, and operand index 1. This is a useful existing detailed follow-up when source functions are known; the earlier exact xrefs results provide only source addresses. It does not by itself discover all references into a range when the relevant source functions are unknown, or establish that every indirect reference was found. No autonomous-agent trace or whole-program cost was measured.

Existing reference-edge contract

The existing referenceEdgeSchema already models source/destination addresses, optional procedure identities and reference classification, and Ghidra procedure_references uses it. For both real Kuna 1.988 rows in the two-source control, a production-domain schema experiment constructed an illustrative edge with the reported endpoints, native kind: read, and only a read flag. It was rejected because the available-kind branch requires all generic flags, including primary and operand_index, which these Kuna rows do not report. The unavailable branch accepted a free-text reason mentioning the native kind, but does not expose that kind as a typed field.

This does not prove that Kuna's read has identical semantics to Ghidra's READ, or that every missing flag can be inferred as false. Consider whether the owning reference representation needs explicit partial/provider-native classification, or a separate bounded source observation, before reusing it for mixed-provider range results. Preserve known labels and unknown flags without inventing facts or duplicating large raw payloads.

Source-containment control

In an owned Ghidra project for the two-reference fixture, a headless script deliberately added a third DATA reference from a mapped data address to the same interior byte. Real REA/Ghidra existing-project MCP xrefs returned all three source addresses. Calling resolve_containing_procedure on each found the two code functions and returned found: false, reason: not_in_procedure for the manually added data source. REA left the selected project files and target unchanged. The added data reference is a controlled metadata fixture, not a claim that it reflects an actual instruction or runtime access.

In a separate fresh-import control on the same binary, the two original instruction sources resolved to functions with Ghidra; REA/Kuna 1.988 returned capability_unavailable for both containment queries. This distinguishes known non-function from unavailable containment and supports preserving source kind and an explicit unknown rather than calling every source a function/caller. It also shows the existing exact-xref plus per-address containment workaround has provider-dependent coverage; no call-count or token-efficiency claim is measured.

Expected interaction with targets

Read existing artifacts and static analysis facts; launch an explicitly selected provider as necessary. No target execution or mutation proposed.

Boundary details

Keep each exact source and destination address, address space, provider provenance, target/profile, range bounds and searched/unsupported coverage. A complete page must not upgrade provider-wide or indirect-reference completeness. Empty results must not establish no runtime uses. Respect existing-project read-only semantics and caller-selected provider.

Options and tradeoffs

Investigate a bounded, paged range query or a task-level data-object reference workflow that reuses provider-owned facts and existing Evidence. Compare sparse provider indexing with repeated exact-address calls; avoid blindly scanning enormous ranges or adding an API-shaped wrapper. It may be useful beyond crypto for tables, strings and structures. Keep exact-address xrefs semantics intact unless a separately reviewed contract change is warranted.

Verification available so far

I have observed results on one fixture and two providers. No measurements of CPU, time, memory or agent tokens, no arbitrary-range coverage guarantee, and no indirect-reference completeness study.

Success criteria and open questions

Exercise references to the start, interior and end; multiple references to the same source/destination; empty ranges; unmapped or uninitialized spans; different address spaces; pagination and provider-specific missing/partial coverage. Verify that precise source/destination provenance survives and boundaries are unambiguous. Determine efficient behavior for large ranges and how the caller retrieves complete retained Evidence.

References

Related: #8194 (algorithm-constant investigation), #8348 (incoming reference observations), #8170 (byte-read semantics).

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Released Kuna 1.989: start and interior references from different functions

A self-built, unexecuted arm64 Mach-O stored rea_extent_reference_marker_82 at 0x1000004dc. One function passed the start to puts; another formed the start and then added 3 before passing the interior address 0x1000004df. With real REA 9ebbe67e full-profile MCP, both Ghidra 12.1.4 and Kuna 1.989 exact xrefs at 0x1000004df returned the interior-address source 0x10000048c. Ghidra trace_feature found the string but returned only the start-address reference from _from_start, with truncated: false and no residual unknowns; the interior site was absent. Kuna's trace included both functions' separate references to the start, because its lifter also reported the interior-using function's preceding base-address formation. It did not include that function's distinct interior-destination site in the start-address result.

Direct Kuna 1.989 strings with its reference walk reported both functions and three reference sites across the 31-byte string object; --no-xrefs remains REA's inventory policy. Direct exact Kuna xrefs independently distinguished the two start-destination rows from the interior-destination row. This illustrates that range attribution and exact-destination xrefs answer different questions even when one function appears in both, and that a range result should retain the actual destination rather than merely the owning function. Neither an address formation nor a reference establishes runtime string use. The target SHA-256 aeed1f352785fd14c9cfcc0e9cf9958354e22ca5c8b979d2f6047585c45ed4d8 remained unchanged. This is one fixture and output profile, not general provider completeness.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8569 ### Decision needed How should an analyst discover incoming references to an explicitly selected address range, such as a matched table or data object, without one `xrefs` call per byte or an unsupported claim that the first address represents the whole range? ### Context and evidence Real compact stdio MCP with REA `96ba4225`, Kuna 1.988 and Ghidra 12.1.4 on macOS arm64: an owned arm64 Mach-O placed a 256-byte table at `0x100000398`; its lookup function directly loaded byte 16 at `0x1000003a8`. For both providers, `xrefs` on the table start returned `[]`, while `xrefs` on the interior address returned source `0x10000037c`. The existing `xrefs` contract is exact-address and its results did not claim a range; this is a task-level opportunity, not a violation of that contract. Independent `llvm-objdump` showed the load at `0x10000037c`. Direct Kuna `crypto --algorithm aes` associated the whole table with `_audit_lookup` despite direct `xrefs` at the start being empty. The fixture contains a known AES S-box and a lookup, but no AES implementation; neither static match nor reference proves runtime use or encryption. The target SHA-256 `597c08e1d2d8732cdfad7170f61b28cf9d25be4be65d7bc9e7486faf00f740ad` was unchanged and it was not executed. ### String trace control On current REA `85013da0c`, an owned x86-64 ELF has UTF-8 `éclair` at `0x200175` (eight bytes including NUL) and an instruction at `0x2011ac` whose disassembly points to the interior address `0x200177`. Kuna 1.988 direct `strings` with reference walking reported the string, one reference and function `_start`; its `--no-xrefs` mode returned zero and no functions because it skipped the walk. REA/Kuna `search_strings` found the same string; exact `xrefs` at `0x200175` returned none, while exact `xrefs` at `0x200177` returned `0x2011ac`. `trace_feature({query:"éclair"})` returned the match but no references, `truncated:false`, and no residual unknowns; its Evidence does state that Kuna xrefs are exact-address and empty results do not prove absence. REA/Ghidra exact xrefs also found the interior address, but its defined-string search did not discover this UTF-8 candidate. The target was not executed and its SHA-256 `2e67fc0604eb81d8727da3b70581f88d69af1dd20d4684d6adbd8d1b916a7a7e` was unchanged. Pinned [Kuna string source](https://github.com/Noelo-Lab/kuna/blob/v1.988/decompiler/crates/kuna-cli/src/strings.rs) scans reference destinations through the observed byte extent and returns aggregate referring functions; it does not return a per-reference mapping for the range. Thus a range-aware handoff could help string tracing as well as tables, but those aggregate function observations cannot be treated as exact site-to-function mappings. The reference is static, and does not prove runtime use. See also #8184 for trace coverage. A separate owned x86-64 ELF placed UTF-16LE `WIDER` at `0x20017e` and an instruction at `0x2011b3` addressing `0x200180`. On real REA/Kuna 1.988, both schema profiles found the string and interior xref, but `trace_feature` returned no references. Ghidra 12.1.4 fresh import found the interior xref but did not define the string. After defining it in an owned Ghidra project with a headless script, real REA/Ghidra existing-project mode found the string and the same interior reference, but the trace again returned none in both profiles. The tested #8575 branch reported its address-only caveat in Evidence. This explicitly distinguishes absent inventory from the range lookup; the project was deliberately authored for the test and remained unchanged during REA use. The target was unexecuted and SHA-256 `4c1031ec3d29b65f5c16c381aa89175e7a00f90e7d7b693618ca28324d51fc23` was unchanged. ### String extent boundary control A third unexecuted x86-64 ELF gives `WIDER` a 12-byte UTF-16LE extent at `0x20017e`–`0x200189`, including the two-byte terminator. Instructions refer to `0x200180` (interior), `0x200188` (terminator), and `0x20018a` (immediately after the extent). Kuna 1.988 direct `strings` reported two references for `WIDER`; `--no-xrefs` reported zero because the walk was skipped. Real REA compact MCP exact `xrefs` from both Kuna and Ghidra returned the interior and terminator sites individually and two separate sources at the immediately following address; the string start returned none. Independent disassembly matched those addresses. SHA-256 `c94e783728a59d55918d60136e289c8a6ce4a9425f9f0519a9da030924508f84` remained unchanged. This one control is consistent with Kuna counting its observed half-open byte extent, including the terminator but excluding the next byte. It does not prove runtime string use. A range-aware UX must specify whether the caller selected the full encoded extent, text payload only, or other explicit bounds, and must preserve the actual destination: a terminator reference should not be silently described as a character access, and an adjacent object should not be folded into the string. ### Provider implementation controls Using Ghidra 12.1.4 headless with an owned project and a script calling `ReferenceManager.getReferenceDestinationIterator(AddressSet, true)`, the inclusive range `0x100000398`–`0x1000003a7` did not include the observed load destination; extending the end one byte to `0x1000003a8` returned the `READ` reference from `0x10000037c` to `0x1000003a8`. Both ranges also returned a synthetic `Entry Point` / `EXTERNAL` reference to the table start. REA's existing exact-address Ghidra `xrefs` omits such synthetic non-actionable sources, as its limitation states. The project was created for this control and the target was not executed. The installed Ghidra script example and this control demonstrate an address-set destination iterator; they do not prove its asymptotic performance, pagination behavior or complete indirect-reference coverage. Source inspection of [Kuna v1.988's crypto implementation](https://github.com/Noelo-Lab/kuna/blob/v1.988/decompiler/crates/kuna-cli/src/crypto.rs) shows it builds a reference index and checks each address in each matched range against that in-memory index. Its CLI returns aggregate counts and functions, not the full per-reference range result needed by this proposal. The two providers therefore need independently verified adapters and source/coverage semantics; do not infer identical completeness or cost. ### Multiple references at one destination A second owned arm64 Mach-O fixture had two separate functions loading the same table byte. Independent Ghidra 12.1.4 headless `getReferenceDestinationIterator` returned one in-range destination `0x1000003b4` with two `READ` references from `0x10000037c` and `0x10000039c`, plus a separate synthetic entry-point reference to the table start. Real REA compact MCP exact `xrefs` at `0x1000003b4` returned both source addresses for both Ghidra and Kuna 1.988; the table-start query returned none. The target was unexecuted and SHA-256 stayed `4818a9e2164a816dd1274b5384999832ec7ba2b6558435c8f074fddbd073171a`. For a future paged range result, a page may stop within one destination's reference group. A cursor that resumes only at the next destination could lose rows; an inclusive destination-only cursor could repeat them. Define stable reference identity/order and a resume position within the group, or use another design that proves no skips or duplicates. This is a proposed verification requirement, not a reproduced defect in an existing range tool. ### Headless pagination control On the two-reference Mach-O above, an independent Ghidra 12.1.4 headless script enumerated the fixed project range with one memory reference per page. The complete enumeration returned `0x10000037c -> 0x1000003b4` and `0x10000039c -> 0x1000003b4` (both `READ`, operand 1). After returning the first, resuming strictly after the destination returned no rows, while resuming inclusively at that destination repeated the first. Re-enumerating the destination and skipping one admitted memory reference returned the second. The script filtered synthetic non-memory entry points before applying its offset; the fixture digest stayed unchanged. This is a single fixed-project control, not proof that an offset or Ghidra iteration order is stable across requests, edits, providers, or reanalysis. A production design must bind continuation to an appropriate snapshot/order or retain its own stable result, define filtering before cursor accounting, and check cancellation and boundedness. The initial experimental script also logged `REPORT SCRIPT ERROR` for an invalid address range despite analyzeHeadless exiting zero; the corrected control asserted all rows and inspected its log. No REA range pagination implementation was exercised. ### Existing retained-view primitive Source inspection on REA `85013da0c`: `native-observation` views page a retained observation with `offset`/`limit` and preserve source indices; their paging coverage describes the retained rows. This is a potential delivery pattern after bounded acquisition, not a ready-made live range-reference cursor or proof that an upstream producer found every edge. The current supported primitive operations do not include a range-reference observation. Any new workflow must separately establish acquisition bounds, provider coverage, and the lifetime/identity of the retained result before applying a view. ### Existing function-scoped detail On the two-reference fixture, real Ghidra compact MCP `procedure_references(direction: "outgoing")` for the already-known `_audit_lookup` and `_audit_second` functions returned each exact source and interior destination, source procedure, `READ` classification, and operand index 1. This is a useful existing detailed follow-up when source functions are known; the earlier exact `xrefs` results provide only source addresses. It does not by itself discover all references into a range when the relevant source functions are unknown, or establish that every indirect reference was found. No autonomous-agent trace or whole-program cost was measured. ### Existing reference-edge contract The existing [`referenceEdgeSchema`](https://github.com/morluto/rea/blob/96ba4225ea65bef35495d43a7dca6da431164c6d/src/domain/native/nativeReference.ts) already models source/destination addresses, optional procedure identities and reference classification, and Ghidra `procedure_references` uses it. For both real Kuna 1.988 rows in the two-source control, a production-domain schema experiment constructed an illustrative edge with the reported endpoints, native `kind: read`, and only a `read` flag. It was rejected because the available-kind branch requires all generic flags, including `primary` and `operand_index`, which these Kuna rows do not report. The unavailable branch accepted a free-text reason mentioning the native kind, but does not expose that kind as a typed field. This does not prove that Kuna's `read` has identical semantics to Ghidra's `READ`, or that every missing flag can be inferred as false. Consider whether the owning reference representation needs explicit partial/provider-native classification, or a separate bounded source observation, before reusing it for mixed-provider range results. Preserve known labels and unknown flags without inventing facts or duplicating large raw payloads. ### Source-containment control In an owned Ghidra project for the two-reference fixture, a headless script deliberately added a third `DATA` reference from a mapped data address to the same interior byte. Real REA/Ghidra existing-project MCP `xrefs` returned all three source addresses. Calling `resolve_containing_procedure` on each found the two code functions and returned `found: false`, `reason: not_in_procedure` for the manually added data source. REA left the selected project files and target unchanged. The added data reference is a controlled metadata fixture, not a claim that it reflects an actual instruction or runtime access. In a separate fresh-import control on the same binary, the two original instruction sources resolved to functions with Ghidra; REA/Kuna 1.988 returned `capability_unavailable` for both containment queries. This distinguishes known non-function from unavailable containment and supports preserving source kind and an explicit unknown rather than calling every source a function/caller. It also shows the existing exact-xref plus per-address containment workaround has provider-dependent coverage; no call-count or token-efficiency claim is measured. ### Expected interaction with targets Read existing artifacts and static analysis facts; launch an explicitly selected provider as necessary. No target execution or mutation proposed. ### Boundary details Keep each exact source and destination address, address space, provider provenance, target/profile, range bounds and searched/unsupported coverage. A complete page must not upgrade provider-wide or indirect-reference completeness. Empty results must not establish no runtime uses. Respect existing-project read-only semantics and caller-selected provider. ### Options and tradeoffs Investigate a bounded, paged range query or a task-level data-object reference workflow that reuses provider-owned facts and existing Evidence. Compare sparse provider indexing with repeated exact-address calls; avoid blindly scanning enormous ranges or adding an API-shaped wrapper. It may be useful beyond crypto for tables, strings and structures. Keep exact-address `xrefs` semantics intact unless a separately reviewed contract change is warranted. ### Verification available so far I have observed results on one fixture and two providers. No measurements of CPU, time, memory or agent tokens, no arbitrary-range coverage guarantee, and no indirect-reference completeness study. ### Success criteria and open questions Exercise references to the start, interior and end; multiple references to the same source/destination; empty ranges; unmapped or uninitialized spans; different address spaces; pagination and provider-specific missing/partial coverage. Verify that precise source/destination provenance survives and boundaries are unambiguous. Determine efficient behavior for large ranges and how the caller retrieves complete retained Evidence. ### References Related: #8194 (algorithm-constant investigation), #8348 (incoming reference observations), #8170 (byte-read semantics). cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Released Kuna 1.989: start and interior references from different functions A self-built, unexecuted arm64 Mach-O stored `rea_extent_reference_marker_82` at `0x1000004dc`. One function passed the start to `puts`; another formed the start and then added 3 before passing the interior address `0x1000004df`. With real REA `9ebbe67e` full-profile MCP, both Ghidra 12.1.4 and Kuna 1.989 exact `xrefs` at `0x1000004df` returned the interior-address source `0x10000048c`. Ghidra `trace_feature` found the string but returned only the start-address reference from `_from_start`, with `truncated: false` and no residual unknowns; the interior site was absent. Kuna's trace included both functions' separate references to the **start**, because its lifter also reported the interior-using function's preceding base-address formation. It did not include that function's distinct interior-destination site in the start-address result. Direct Kuna 1.989 `strings` with its reference walk reported both functions and three reference sites across the 31-byte string object; `--no-xrefs` remains REA's inventory policy. Direct exact Kuna `xrefs` independently distinguished the two start-destination rows from the interior-destination row. This illustrates that range attribution and exact-destination xrefs answer different questions even when one function appears in both, and that a range result should retain the actual destination rather than merely the owning function. Neither an address formation nor a reference establishes runtime string use. The target SHA-256 `aeed1f352785fd14c9cfcc0e9cf9958354e22ca5c8b979d2f6047585c45ed4d8` remained unchanged. This is one fixture and output profile, not general provider completeness.

bsakaguchi added the

enhancement

triage

labels

2026-11-01 21:12:59 +00:00

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-11-03 12:24:58 +00:00