morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #8476] [Bug] Native value trace omits an external thunk target and its unknown flow #6620

New issue

Open

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

bsakaguchi commented

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

Owner

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

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

trace_native_values can stop at a Ghidra-created external import thunk without exposing that its external target's value flow is unexamined. The trace preserves the observed call to the thunk, but the thunk's synthetic HighFunction contains only RETURN and no call to its separately reported target. The trace does not report an unknown for that external target.

Reproduction

On macOS, build but do not execute this local arm64 Mach-O dylib:

.text
.space 0x1000
.globl _audit_import_call
.p2align 2
_audit_import_call:
 stp x29, x30, [sp, #-16]!
 mov x29, sp
 adrp x16, _malloc@GOTPAGE
 ldr x16, [x16, _malloc@GOTPAGEOFF]
 blr x16
 ldp x29, x30, [sp], #16
 ret

xcrun clang -arch arm64 -dynamiclib -o fixture.dylib fixture.s

Open the dylib with Ghidra through MCP. On the tested build, resolve_native_call_targets for 0x1368 reports a candidate at 0xc000.
procedure_info({procedure:"0xc000"}) reports a Ghidra thunk with target EXTERNAL:0x1. read_bytes({address:"0xc000",length:4}) returns zero bytes, complete:false; the target is in Ghidra's uninitialized external mapping. These addresses are build-specific.
trace_native_values({procedure:"0xc000",max_depth:1,max_functions:3}) returns two nodes, zero edges, unknowns: [], and traversal status complete. A separate Ghidra analyze_function dossier says it is a thunk, but its available HighFunction has only a synthetic RETURN and a parameter; the value trace does not include that classification or target.
trace_native_values({procedure:"_audit_import_call",max_depth:2,max_functions:5}) records the call to 0xc000 and the thunk procedure; it reports an unrelated missing-argument unknown, but none for the external target. By contrast, tracing EXTERNAL:0x1 directly returns the explicit unknown Ghidra has no HighFunction p-code model for this procedure.

Expected behavior

Preserve the observed Ghidra model and resolved call without equating it with the imported implementation. When known thunk metadata identifies an external or otherwise unexamined target, expose the target and the value-flow limitation or an appropriate unknown in the composed result. Do not claim that traversal status complete establishes complete runtime behavior, and do not automatically load or execute a library.

Impact and scope

The missing distinction can lead a consumer of the trace to treat the stub's small model as the end of the selected call chain. The source dossier and procedure_info do expose the thunk classification; the result also contains general decompiler limitations. A real live-session recovery control retrieved the thunk classification via inspect_analysis_view of the trace procedure's source Evidence on the cold run on main. The warm trace source lookup failed with evidence_integrity_mismatch (existing #8282). On exact PR #8384 head a20c186eb81785c96267f33cec3929ea5aeb8130, the same view retrieved the classification on cold and warm runs. This is a useful additional lookup, not an inline trace unknown or an automatic follow of the external target; offline export/import was not tested for this new case. No agent behavior or runtime call was observed. Two independently built copies of the same external-import fixture were tested on one host, not a prevalence estimate; other architectures and formats remain unverified. An internal-thunk control is described below. The first fixture and the independently rebuilt dylib were not executed and their hashes stayed unchanged during analysis. MCP SDK validated successful results against the compact schema on the first fixture and the full schema on the rebuilt fixture.

Internal-thunk counterexample

A separate source-owned arm64 fixture contains a real four-byte branch from _audit_thunk at 0x2c0 to the file-backed _audit_target at 0x2b8, which returns 42. Ghidra 12.1.4 independently classified the source as a thunk with target 0x2b8; read_bytes returned the actual branch bytes. For this case its thunk HighFunction contained a COPY at 0x2b8 and RETURN at 0x2bc: it reflected the target's operations even though the thunk body was only 0x2c0..0x2c3. Direct target analysis showed the same operation addresses, opcodes and operands, with different Ghidra p-code sequence/identity values. The thunk value trace used the selected thunk as procedure and preserved the target operation addresses, but did not explain the thunk-to-target relationship inline. This means a blanket statement that every unvisited thunk target was unexamined would be false. Kuna on the same fixture returned the branch/tail-call text but no native def-use model. Successful calls used the compact advertised schema; both fixtures were unexecuted and unchanged.

The call-only trace_call_path stopped at the branch under both providers, with a scoped negative over their reported call edges. Its separate tail-transfer design question is #8197; this control does not establish a call-path contract bug. Ghidra's Function.getThunkedFunction(false) exposes the referenced function; the provider's classification uses that immediate target. A further source-owned two-thunk chain confirmed the distinction: Ghidra reported outer 0x2cc → immediate 0x2c8 and inner 0x2c8 → 0x2c0, while both HighFunctions contained operations at the final function's 0x2c0 and 0x2c4. The outer trace retained the outer selected procedure and those operation addresses but did not report either thunk relationship. Actual Kuna reported no native def-use model. This is one static chain, not proof that all thunk models resolve recursively.

A fresh real Ghidra compact MCP session on this chain also exercised an existing manual route: inspect_analysis_view on the trace procedure's retained source exposed the first target, procedure_info on that target exposed the next, resolve_containing_procedure identified the final function, and inspect_native_instruction decoded all three addresses. All calls succeeded against advertised schemas; the target hash was unchanged. This was a cold-session scripted sequence, not an autonomous-agent or warm/offline replay study.

Any solution must distinguish a target already represented in a borrowed model from an unmodeled external target, retaining each source's provenance and the selected procedure.

REA version

a6caa79bf4f393c02601fbf2f6df246eae0b1558.

Runtime and platform

Node 24.22.1, macOS arm64, Ghidra 12.1.4/JDK 21; public stdio MCP.

Target and artifact context

Source-owned arm64 Mach-O dylib with a file-declared _malloc GOT binding; static analysis only.

Interface

MCP

Earliest failure stage

Native analysis or reconstruction.

Relevant output or evidence

The target thunk's classification is {external:false, thunk:true, thunk_target:"EXTERNAL:0x1", provenance:"ghidra-function-manager"}. Its direct value trace contains a RETURN operation and parameter, no unknowns, and no edge to EXTERNAL:0x1. Directly tracing the external entry retains the no-model unknown. The separately measured file binding and synthetic uninitialized Ghidra memory are different observations; neither establishes runtime loader behavior.

Typed outcome or recovery expected

A trace consumer can see that the known thunk target was not analyzed, while keeping the exact observed stub/model and its provenance. A caller can then explicitly inspect an available external target or a separately selected library; unavailable external implementation remains unknown.

Analysis or suspected cause

Source-derived: NativeValueTrace.ts consumes the dossier's native_value_flow, follows recovered CALL/CALLIND operations, and records procedure address/provider/Evidence ID. It does not currently project or follow the dossier's thunk classification and target. Ghidra supplies a valid but synthetic no-call HighFunction for the thunk, so this path reaches neither the external entry nor the no-model branch. This explains the observed result; it is not a claim that Ghidra's model is incorrect or that every thunk needs automatic traversal.

Additional context

Related #8408 concerns associating a Mach-O slot with its file-declared binding; #8277 concerns missing computed-call target completeness; #8282 concerns retained trace source closure. This issue is specifically about preserving a known thunk-to-target boundary in a value trace. Suggested further controls include internal backed thunks with distinct nontrivial target flow, longer or cyclic chains where permitted, real call edges, limited depth, and export/import; these have not been fully exercised. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8476 ### 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 `trace_native_values` can stop at a Ghidra-created external import thunk without exposing that its external target's value flow is unexamined. The trace preserves the observed call to the thunk, but the thunk's synthetic HighFunction contains only `RETURN` and no call to its separately reported target. The trace does not report an unknown for that external target. ### Reproduction On macOS, build but do not execute this local arm64 Mach-O dylib: ```asm .text .space 0x1000 .globl _audit_import_call .p2align 2 _audit_import_call: stp x29, x30, [sp, #-16]! mov x29, sp adrp x16, _malloc@GOTPAGE ldr x16, [x16, _malloc@GOTPAGEOFF] blr x16 ldp x29, x30, [sp], #16 ret ``` `xcrun clang -arch arm64 -dynamiclib -o fixture.dylib fixture.s` 1. Open the dylib with Ghidra through MCP. On the tested build, `resolve_native_call_targets` for `0x1368` reports a candidate at `0xc000`. 2. `procedure_info({procedure:"0xc000"})` reports a Ghidra thunk with target `EXTERNAL:0x1`. `read_bytes({address:"0xc000",length:4})` returns zero bytes, `complete:false`; the target is in Ghidra's uninitialized external mapping. These addresses are build-specific. 3. `trace_native_values({procedure:"0xc000",max_depth:1,max_functions:3})` returns two nodes, zero edges, `unknowns: []`, and traversal status `complete`. A separate Ghidra `analyze_function` dossier says it is a thunk, but its available HighFunction has only a synthetic `RETURN` and a parameter; the value trace does not include that classification or target. 4. `trace_native_values({procedure:"_audit_import_call",max_depth:2,max_functions:5})` records the call to `0xc000` and the thunk procedure; it reports an unrelated missing-argument unknown, but none for the external target. By contrast, tracing `EXTERNAL:0x1` directly returns the explicit unknown `Ghidra has no HighFunction p-code model for this procedure`. ### Expected behavior Preserve the observed Ghidra model and resolved call without equating it with the imported implementation. When known thunk metadata identifies an external or otherwise unexamined target, expose the target and the value-flow limitation or an appropriate unknown in the composed result. Do not claim that traversal status `complete` establishes complete runtime behavior, and do not automatically load or execute a library. ### Impact and scope The missing distinction can lead a consumer of the trace to treat the stub's small model as the end of the selected call chain. The source dossier and `procedure_info` do expose the thunk classification; the result also contains general decompiler limitations. A real live-session recovery control retrieved the thunk classification via `inspect_analysis_view` of the trace procedure's source Evidence on the cold run on main. The warm trace source lookup failed with `evidence_integrity_mismatch` (existing #8282). On exact PR #8384 head `a20c186eb81785c96267f33cec3929ea5aeb8130`, the same view retrieved the classification on cold and warm runs. This is a useful additional lookup, not an inline trace unknown or an automatic follow of the external target; offline export/import was not tested for this new case. No agent behavior or runtime call was observed. Two independently built copies of the same external-import fixture were tested on one host, not a prevalence estimate; other architectures and formats remain unverified. An internal-thunk control is described below. The first fixture and the independently rebuilt dylib were not executed and their hashes stayed unchanged during analysis. MCP SDK validated successful results against the compact schema on the first fixture and the full schema on the rebuilt fixture. ### Internal-thunk counterexample A separate source-owned arm64 fixture contains a real four-byte branch from `_audit_thunk` at `0x2c0` to the file-backed `_audit_target` at `0x2b8`, which returns 42. Ghidra 12.1.4 independently classified the source as a thunk with target `0x2b8`; `read_bytes` returned the actual branch bytes. For this case its thunk HighFunction contained a COPY at `0x2b8` and RETURN at `0x2bc`: it reflected the target's operations even though the thunk body was only `0x2c0..0x2c3`. Direct target analysis showed the same operation addresses, opcodes and operands, with different Ghidra p-code sequence/identity values. The thunk value trace used the selected thunk as `procedure` and preserved the target operation addresses, but did not explain the thunk-to-target relationship inline. This means a blanket statement that every unvisited thunk target was unexamined would be false. Kuna on the same fixture returned the branch/tail-call text but no native def-use model. Successful calls used the compact advertised schema; both fixtures were unexecuted and unchanged. The call-only `trace_call_path` stopped at the branch under both providers, with a scoped negative over their reported call edges. Its separate tail-transfer design question is #8197; this control does not establish a call-path contract bug. Ghidra's [`Function.getThunkedFunction(false)`](https://ghidra.re/ghidra_docs/api/ghidra/program/model/listing/Function.html#getThunkedFunction(boolean)) exposes the referenced function; the provider's classification uses that immediate target. A further source-owned two-thunk chain confirmed the distinction: Ghidra reported outer `0x2cc` → immediate `0x2c8` and inner `0x2c8` → `0x2c0`, while both HighFunctions contained operations at the final function's `0x2c0` and `0x2c4`. The outer trace retained the outer selected procedure and those operation addresses but did not report either thunk relationship. Actual Kuna reported no native def-use model. This is one static chain, not proof that all thunk models resolve recursively. A fresh real Ghidra compact MCP session on this chain also exercised an existing manual route: `inspect_analysis_view` on the trace procedure's retained source exposed the first target, `procedure_info` on that target exposed the next, `resolve_containing_procedure` identified the final function, and `inspect_native_instruction` decoded all three addresses. All calls succeeded against advertised schemas; the target hash was unchanged. This was a cold-session scripted sequence, not an autonomous-agent or warm/offline replay study. Any solution must distinguish a target already represented in a borrowed model from an unmodeled external target, retaining each source's provenance and the selected procedure. ### REA version `a6caa79bf4f393c02601fbf2f6df246eae0b1558`. ### Runtime and platform Node 24.22.1, macOS arm64, Ghidra 12.1.4/JDK 21; public stdio MCP. ### Target and artifact context Source-owned arm64 Mach-O dylib with a file-declared `_malloc` GOT binding; static analysis only. ### Interface MCP ### Earliest failure stage Native analysis or reconstruction. ### Relevant output or evidence The target thunk's `classification` is `{external:false, thunk:true, thunk_target:"EXTERNAL:0x1", provenance:"ghidra-function-manager"}`. Its direct value trace contains a `RETURN` operation and parameter, no `unknowns`, and no edge to `EXTERNAL:0x1`. Directly tracing the external entry retains the no-model unknown. The separately measured file binding and synthetic uninitialized Ghidra memory are different observations; neither establishes runtime loader behavior. ### Typed outcome or recovery expected A trace consumer can see that the known thunk target was not analyzed, while keeping the exact observed stub/model and its provenance. A caller can then explicitly inspect an available external target or a separately selected library; unavailable external implementation remains unknown. ### Analysis or suspected cause Source-derived: `NativeValueTrace.ts` consumes the dossier's `native_value_flow`, follows recovered `CALL`/`CALLIND` operations, and records procedure address/provider/Evidence ID. It does not currently project or follow the dossier's thunk classification and target. Ghidra supplies a valid but synthetic no-call HighFunction for the thunk, so this path reaches neither the external entry nor the no-model branch. This explains the observed result; it is not a claim that Ghidra's model is incorrect or that every thunk needs automatic traversal. ### Additional context Related #8408 concerns associating a Mach-O slot with its file-declared binding; #8277 concerns missing computed-call target completeness; #8282 concerns retained trace source closure. This issue is specifically about preserving a known thunk-to-target boundary in a value trace. Suggested further controls include internal backed thunks with distinct nontrivial target flow, longer or cyclic chains where permitted, real call edges, limited depth, and export/import; these have not been fully exercised. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

bug

triage

labels

2026-11-01 21:12:44 +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#6620

No description provided.

Rows
Columns