morluto/rea

Fork 0

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

[GH-ISSUE #8352] [Bug] Kuna rejects a reported call destination as definite Mach-O data #6556

New issue

Open

opened 2026-11-01 21:12:13 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

With Kuna, an instruction sequence in an executable Mach-O segment is treated categorically as data because its section has no instruction attributes. REA's own procedure_callees reports a direct call to the address, but procedure_assembly, procedure_pseudo_code, and trace_call_path refuse the destination as “data ... not a procedure”; search_procedures omits it. Ghidra on the same binary resolves, decodes, and decompiles the destination.

Reproduction

Build this owned arm64 Mach-O with xcrun clang -arch arm64 -Wl,-e,_main -o const-code const-code.s (do not run it):

.section __TEXT,__text,regular,pure_instructions
.p2align 2
.globl _main
_main:
  bl _placed_in_const
  ret
.section __TEXT,__const
.p2align 2
.globl _placed_in_const
_placed_in_const:
  mov w0, #42
  ret
.section __DATA,__data
.p2align 2
.globl _audit_data
_audit_data:
  .long 42

Open the binary via open_binary with provider_id: "kuna".
procedure_callees({procedure:"_main"}) returns ["0x1000003c8"]; xrefs({address:"0x1000003c8"}) returns ["0x1000003c0"]. search_procedures({pattern:"placed_in_const"}) returns [] with an omission limitation.
procedure_assembly({procedure:"0x1000003c8"}) returns invalid_request: placed_in_const (0x1000003c8) lies in __TEXT,__const, a Mach-O section whose attributes declare no instructions, so it is data that Kuna lists, not a procedure. The address is build-specific.
On the same open target, explicitly select Ghidra with open_binary. inspect_native_instruction decodes bl 0x1000003c8 at 0x1000003c0 and mov w0,#0x2a at the destination; procedure_pseudo_code returns a function containing return 0x2a. Ghidra xrefs also finds the call.

The direct released Kuna functions, xrefs --to, and explicit disassemble --as code commands independently report the symbol, the call, and mov w0,#0x2a; ret. Before #8335, the same REA/Kuna fixture's cold single-function decompile returned return 0x2a and the call path reached the address. The completed Kuna project export did not supply a body for that destination; this report does not claim it did.

Expected behavior

Keep the section declaration and the conflicting call/instruction observations distinct. An address in an unflagged section of an executable segment is not, by that fact alone, proven to be data. Preserve uncertainty and a usable explicit investigation route when code evidence exists; continue to identify or qualify genuine data without treating all exports as functions. Ghidra provider selection is a working alternative when installed, with its own session state.

Impact and scope

An analyst can receive a call destination but cannot follow it with Kuna's procedure tools and receives a categorical contradiction. This is a deliberately constructed static counterexample, not a runtime observation, prevalence estimate, or claim that arbitrary instruction-like bytes are code. One arm64 Mach-O and one host were tested; other architectures and stripped files are unverified. The ordinary data fixture and a shipped Brotli data-table control did improve under #8335.

REA version

d54a4661da20382ad8456564a08569fdd24131c5 (current main after #8335).

Runtime and platform

Node 24.22.1; macOS arm64; Kuna 1.986; Ghidra 12.1.4 / JDK 21; TypeScript MCP SDK 2.3.1.

Target and artifact context

Self-authored arm64 Mach-O; SHA-256 e8590d7779078d8308b6c03d12c42602e87829ed26721e387ecfeb028042ae8a. Target was statically inspected, not executed; hash unchanged.

Interface

MCP

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

nm -m reports _placed_in_const in __TEXT,__const; otool -l reports that section's flags as 0 and its enclosing __TEXT segment's initprot as 0x5. Ghidra's read_bytes returns 40058052c0035fd6 at the destination, corresponding to the two displayed arm64 instructions. Successful SDK calls used the advertised compact output schemas. After a Kuna-to-Ghidra switch, export and target-free import of the Evidence bundle preserved both providers' successful call, reference, instruction and pseudocode observations. Error responses were not retained as successful Evidence.

Typed outcome or recovery expected

Avoid reporting a classification as certain when section and direct-call observations conflict. Preserve the exact section fact, provider source, and a route to the caller-selected address; expose any remaining uncertainty.

Analysis or suspected cause

Source-derived: sectionPlacement marks every non-stub, non-import section lacking instruction attributes as data; the session filters and refuses such inventory entries without considering a separately reported call. This explains the reproduced behavior; a solution need not perform whole-program analysis or rely on names.

Additional context

Follow-up to closed #8168 and merged #8335; the pre-merge real-provider comparison includes the ordinary data and Brotli controls. The PR's two inspected provider/MCP boundary test files passed 8/8 but did not cover instructions in an unflagged section. Last tested pre-change revision: 60149282fcfc05ac32fbc94434c107710120da6f; first tested merged main: d54a4661da20382ad8456564a08569fdd24131c5.

Valid-instruction data control

On REA 60c0cf977 and verified Kuna 1.986, I built another unexecuted arm64 Mach-O with a called function and an explicitly authored .long 0xd65f03c0 data word in the same unflagged __TEXT,__const section. Direct Kuna disassemble --as code decodes the function's return and the data word as the same valid ret bytes (c0035fd6), without a decoder warning. Its graph labels both entries data; REA reports an incoming direct call to the function but none to the data word and refuses both as procedures. Separately selected Ghidra resolves the called entry and reports the data word as not-in-listing without decoding it. Successful stdio MCP calls used compact advertised-schema validation; error payloads were inspected, not independently schema-validated. The fixture SHA-256 5a25df84d7dce09e5461d260a5656008f11a51ca3669a0e907f07e08f368f9c3 stayed unchanged.

This controlled example shows why a successful forced decode cannot by itself establish a procedure: the same instruction bytes were deliberately used as data. A reported direct call is additional static evidence, while absence of an xref is not proof that an address is data or unreachable. This is one synthetic fixture, not an estimate of prevalence or runtime behavior.

Byte-read recovery control

On the valid-instruction data fixture above, current REA/Kuna read_bytes at both the called address and data address returned typed capability_unavailable; its generic action advised choosing another analysis or target. Direct Kuna 1.986 read and separately selected REA/Ghidra returned the same bytes at both addresses. Ghidra also decoded the called entry and retained its incoming call reference. REA's successful MCP results were validated with compact schemas and the target digest stayed unchanged. #8170 tracks whether Kuna can implement the existing byte-read contract, including mapping and coverage questions. A byte read is useful evidence, but the data control prevents treating a successful decode as proof of a procedure.

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

Released Kuna 1.988 control

On REA main 53363166f, macOS arm64 and the same owned unexecuted fixture, the new release changes the observed failure. Direct Kuna 1.988 functions --json returns only _main; its xrefs --to 0x1000003c8 --json identifies the bl at 0x1000003c0 as a call and reports to_function: null. Its decompile-graph contains the _main node with no edges. Through compact stdio MCP, REA likewise returns that incoming xref, but procedure_callees(_main) and the forward get_call_graph contain no call edge, with relationship_coverage.status: complete. The accompanying limitation says calls outside the discovered function inventory remain unknown. search_procedures returns no matching entry; an explicit assembly request is refused as not found, rather than the 1.986 categorical data classification.

In the same session, an explicit Ghidra 12.1.4 switch resolves and decodes the branch and destination and decompiles the destination to a return of 42. Both providers' captured Evidence survived export and target-free reimport, and the fixture digest remained unchanged. A separate side-by-side control confirmed 1.986's call-graph edge versus 1.988's missing edge on this fixture. This is one constructed static example, not a prevalence estimate or proof of runtime execution. It shows that release changes can move the uncertainty boundary upstream: a complete-within-inventory graph and a separate observed call reference must not be treated as globally complete control flow.

Kuna 1.990 coverage control

On PR #8813 head 187f3d8cc, a newly built, unexecuted arm64 Mach-O has _main at 0x100000328 calling _placed_in_const at 0x100000330 in executable __TEXT,__const. Direct Kuna 1.990 xrefs --to reports the call and, in its coverage, states the destination was not walked because its executable section is not marked as code. In compact and full public MCP profiles, REA xrefs reports the caller but retains only the source digest, counts and general xref limitation, omitting that specific coverage observation. procedure_callees(_main) returns [] with relationship_coverage.status: complete; its limitation qualifies that graph edges only cover discovered function nodes and outside targets remain unknown. A direct assembly request for the target returns the unlisted-entry error. Successful results were checked by the MCP SDK against fetched schemas; error details were inspected. The target SHA-256 f6bef0ecd9a90e34efb799b81640fe7785610aa655a8e6ec1ce7c4716908ff8e stayed unchanged.

This is one version and fixture. The provider's unwalked list describes sources outside the walk, and the listed source happens to be the selected target in this control. It does not prove that source refers to any particular target. A separate case where an unwalked source does reference another queried target is documented in #8184. Preserve that distinction; the note is not proof of runtime execution or an instruction to run an external command.

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8352 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior With Kuna, an instruction sequence in an executable Mach-O segment is treated categorically as data because its section has no instruction attributes. REA's own `procedure_callees` reports a direct call to the address, but `procedure_assembly`, `procedure_pseudo_code`, and `trace_call_path` refuse the destination as “data ... not a procedure”; `search_procedures` omits it. Ghidra on the same binary resolves, decodes, and decompiles the destination. ### Reproduction Build this owned arm64 Mach-O with `xcrun clang -arch arm64 -Wl,-e,_main -o const-code const-code.s` (do not run it): ```asm .section __TEXT,__text,regular,pure_instructions .p2align 2 .globl _main _main: bl _placed_in_const ret .section __TEXT,__const .p2align 2 .globl _placed_in_const _placed_in_const: mov w0, #42 ret .section __DATA,__data .p2align 2 .globl _audit_data _audit_data: .long 42 ``` 1. Open the binary via `open_binary` with `provider_id: "kuna"`. 2. `procedure_callees({procedure:"_main"})` returns `["0x1000003c8"]`; `xrefs({address:"0x1000003c8"})` returns `["0x1000003c0"]`. `search_procedures({pattern:"placed_in_const"})` returns `[]` with an omission limitation. 3. `procedure_assembly({procedure:"0x1000003c8"})` returns `invalid_request`: `placed_in_const (0x1000003c8) lies in __TEXT,__const, a Mach-O section whose attributes declare no instructions, so it is data that Kuna lists, not a procedure.` The address is build-specific. 4. On the same open target, explicitly select Ghidra with `open_binary`. `inspect_native_instruction` decodes `bl 0x1000003c8` at `0x1000003c0` and `mov w0,#0x2a` at the destination; `procedure_pseudo_code` returns a function containing `return 0x2a`. Ghidra `xrefs` also finds the call. The direct released Kuna `functions`, `xrefs --to`, and explicit `disassemble --as code` commands independently report the symbol, the call, and `mov w0,#0x2a; ret`. Before #8335, the same REA/Kuna fixture's cold single-function decompile returned `return 0x2a` and the call path reached the address. The completed Kuna project export did not supply a body for that destination; this report does not claim it did. ### Expected behavior Keep the section declaration and the conflicting call/instruction observations distinct. An address in an unflagged section of an executable segment is not, by that fact alone, proven to be data. Preserve uncertainty and a usable explicit investigation route when code evidence exists; continue to identify or qualify genuine data without treating all exports as functions. Ghidra provider selection is a working alternative when installed, with its own session state. ### Impact and scope An analyst can receive a call destination but cannot follow it with Kuna's procedure tools and receives a categorical contradiction. This is a deliberately constructed static counterexample, not a runtime observation, prevalence estimate, or claim that arbitrary instruction-like bytes are code. One arm64 Mach-O and one host were tested; other architectures and stripped files are unverified. The ordinary data fixture and a shipped Brotli data-table control did improve under #8335. ### REA version `d54a4661da20382ad8456564a08569fdd24131c5` (current main after #8335). ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.986; Ghidra 12.1.4 / JDK 21; TypeScript MCP SDK 2.3.1. ### Target and artifact context Self-authored arm64 Mach-O; SHA-256 `e8590d7779078d8308b6c03d12c42602e87829ed26721e387ecfeb028042ae8a`. Target was statically inspected, not executed; hash unchanged. ### Interface MCP ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence `nm -m` reports `_placed_in_const` in `__TEXT,__const`; `otool -l` reports that section's flags as `0` and its enclosing `__TEXT` segment's `initprot` as `0x5`. Ghidra's `read_bytes` returns `40058052c0035fd6` at the destination, corresponding to the two displayed arm64 instructions. Successful SDK calls used the advertised compact output schemas. After a Kuna-to-Ghidra switch, export and target-free import of the Evidence bundle preserved both providers' successful call, reference, instruction and pseudocode observations. Error responses were not retained as successful Evidence. ### Typed outcome or recovery expected Avoid reporting a classification as certain when section and direct-call observations conflict. Preserve the exact section fact, provider source, and a route to the caller-selected address; expose any remaining uncertainty. ### Analysis or suspected cause Source-derived: [`sectionPlacement`](https://github.com/morluto/rea/blob/d54a4661da20382ad8456564a08569fdd24131c5/src/kuna/KunaInventoryPlacement.ts) marks every non-stub, non-import section lacking instruction attributes as `data`; the session filters and refuses such inventory entries without considering a separately reported call. This explains the reproduced behavior; a solution need not perform whole-program analysis or rely on names. ### Additional context Follow-up to closed #8168 and merged #8335; the pre-merge [real-provider comparison](https://github.com/morluto/rea/pull/8335#issuecomment-6547264405) includes the ordinary data and Brotli controls. The PR's two inspected provider/MCP boundary test files passed 8/8 but did not cover instructions in an unflagged section. Last tested pre-change revision: `60149282fcfc05ac32fbc94434c107710120da6f`; first tested merged main: `d54a4661da20382ad8456564a08569fdd24131c5`. ### Valid-instruction data control On REA `60c0cf977` and verified Kuna 1.986, I built another unexecuted arm64 Mach-O with a called function and an explicitly authored `.long 0xd65f03c0` data word in the same unflagged `__TEXT,__const` section. Direct Kuna `disassemble --as code` decodes the function's return and the data word as the same valid `ret` bytes (`c0035fd6`), without a decoder warning. Its graph labels both entries `data`; REA reports an incoming direct call to the function but none to the data word and refuses both as procedures. Separately selected Ghidra resolves the called entry and reports the data word as `not-in-listing` without decoding it. Successful stdio MCP calls used compact advertised-schema validation; error payloads were inspected, not independently schema-validated. The fixture SHA-256 `5a25df84d7dce09e5461d260a5656008f11a51ca3669a0e907f07e08f368f9c3` stayed unchanged. This controlled example shows why a successful forced decode cannot by itself establish a procedure: the same instruction bytes were deliberately used as data. A reported direct call is additional static evidence, while absence of an xref is not proof that an address is data or unreachable. This is one synthetic fixture, not an estimate of prevalence or runtime behavior. ### Byte-read recovery control On the valid-instruction data fixture above, current REA/Kuna `read_bytes` at both the called address and data address returned typed `capability_unavailable`; its generic action advised choosing another analysis or target. Direct Kuna 1.986 `read` and separately selected REA/Ghidra returned the same bytes at both addresses. Ghidra also decoded the called entry and retained its incoming call reference. REA's successful MCP results were validated with compact schemas and the target digest stayed unchanged. #8170 tracks whether Kuna can implement the existing byte-read contract, including mapping and coverage questions. A byte read is useful evidence, but the data control prevents treating a successful decode as proof of a procedure. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0. ### Released Kuna 1.988 control On REA main `53363166f`, macOS arm64 and the same owned unexecuted fixture, the new release changes the observed failure. Direct Kuna 1.988 `functions --json` returns only `_main`; its `xrefs --to 0x1000003c8 --json` identifies the `bl` at `0x1000003c0` as a call and reports `to_function: null`. Its `decompile-graph` contains the `_main` node with no edges. Through compact stdio MCP, REA likewise returns that incoming xref, but `procedure_callees(_main)` and the forward `get_call_graph` contain no call edge, with `relationship_coverage.status: complete`. The accompanying limitation says calls outside the discovered function inventory remain unknown. `search_procedures` returns no matching entry; an explicit assembly request is refused as not found, rather than the 1.986 categorical data classification. In the same session, an explicit Ghidra 12.1.4 switch resolves and decodes the branch and destination and decompiles the destination to a return of 42. Both providers' captured Evidence survived export and target-free reimport, and the fixture digest remained unchanged. A separate side-by-side control confirmed 1.986's call-graph edge versus 1.988's missing edge on this fixture. This is one constructed static example, not a prevalence estimate or proof of runtime execution. It shows that release changes can move the uncertainty boundary upstream: a complete-within-inventory graph and a separate observed call reference must not be treated as globally complete control flow. ### Kuna 1.990 coverage control On PR #8813 head `187f3d8cc`, a newly built, unexecuted arm64 Mach-O has `_main` at `0x100000328` calling `_placed_in_const` at `0x100000330` in executable `__TEXT,__const`. Direct Kuna 1.990 `xrefs --to` reports the call and, in its `coverage`, states the destination was not walked because its executable section is not marked as code. In compact and full public MCP profiles, REA `xrefs` reports the caller but retains only the source digest, counts and general xref limitation, omitting that specific coverage observation. `procedure_callees(_main)` returns `[]` with `relationship_coverage.status: complete`; its limitation qualifies that graph edges only cover discovered function nodes and outside targets remain unknown. A direct assembly request for the target returns the unlisted-entry error. Successful results were checked by the MCP SDK against fetched schemas; error details were inspected. The target SHA-256 `f6bef0ecd9a90e34efb799b81640fe7785610aa655a8e6ec1ce7c4716908ff8e` stayed unchanged. This is one version and fixture. The provider's unwalked list describes sources outside the walk, and the listed source happens to be the selected target in this control. It does not prove that source refers to any particular target. A separate case where an unwalked source does reference another queried target is documented in #8184. Preserve that distinction; the note is not proof of runtime execution or an instruction to run an external command.

bsakaguchi added the

bug

triage

labels

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

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Isolated explicit-address experiment and its limits

I tested one unmerged prototype, not a proposed complete fix, on REA d54a4661da20382ad8456564a08569fdd24131c5. It keeps unflagged entries out of ordinary procedure discovery, but accepts an exact address with a caveat that the section does not establish code versus data. It also changes the listing/name wording to avoid asserting that every excluded entry is definitely data. No production source was changed.

With real Kuna 1.986 and the issue's unexecuted fixture, an explicitly selected 0x1000003c8 returned the single-function reconstruction return 0x2a and trace_call_path reached it. The individual response carried the section/classification caveat and raw_result identified the single-function source. Discovery by name still returned no row and naming the omitted symbol as a procedure still refused with a route to its address.

The tradeoffs are significant:

An explicit address for the known data global also returned a successful UndefinedInstructionException reconstruction while the export was building. On real Brotli 1.2.0, an explicit address for _kBrotliPrefixCodeRanges likewise returned a warned halt_baddata() reconstruction. A warning is essential but does not turn those bytes into a function.
In a cold batch_decompile of the code and data addresses, both items had status: ok; the two section caveats were aggregated at batch level, without per-success-item association. This is the existing successful-item provenance problem in #8350, now directly relevant to this route.
Once the project export completed, both selected addresses returned null because that export had no body, each with the classification and no-body caveats. A fresh exact-range decompile_all for the code address selected zero entries because that workflow starts from the filtered inventory. Permitting the direct lookup alone therefore does not provide a reliable decompile/export workflow.

The real-Kuna cold/warm comparison used an owned launcher that delayed decompile-project by 12 seconds; this is controlled scheduling, not a natural frequency or release-integrity check. Direct, batch, path and warm-result Evidence survived target-free bundle export/import with their normalized results and limitations. SDK 2.3.1 validated successful compact responses; fixture and Brotli hashes were unchanged and neither target ran.

The existing two provider/MCP boundary files gave 7 passes and 1 failure at an assertion on the original categorical omission wording; later assertions in that failed test did not run. The prototype also permits explicit selection of the header and does not resolve name discovery, batch item attribution, warm-cache behavior, output bounds, cancellation, or other formats. It is deliberately not integration-ready. The evidence suggests evaluating an explicitly qualified address-based investigation together with its batch, export and provider-state behavior, rather than assuming this small override resolves the issue.

@morluto commented on GitHub (Oct 31, 2026): ### Isolated explicit-address experiment and its limits I tested one **unmerged prototype**, not a proposed complete fix, on REA `d54a4661da20382ad8456564a08569fdd24131c5`. It keeps unflagged entries out of ordinary procedure discovery, but accepts an exact address with a caveat that the section does not establish code versus data. It also changes the listing/name wording to avoid asserting that every excluded entry is definitely data. No production source was changed. With real Kuna 1.986 and the issue's unexecuted fixture, an explicitly selected `0x1000003c8` returned the single-function reconstruction `return 0x2a` and `trace_call_path` reached it. The individual response carried the section/classification caveat and `raw_result` identified the single-function source. Discovery by name still returned no row and naming the omitted symbol as a procedure still refused with a route to its address. The tradeoffs are significant: - An explicit address for the **known data** global also returned a successful `UndefinedInstructionException` reconstruction while the export was building. On real Brotli 1.2.0, an explicit address for `_kBrotliPrefixCodeRanges` likewise returned a warned `halt_baddata()` reconstruction. A warning is essential but does not turn those bytes into a function. - In a cold `batch_decompile` of the code and data addresses, both items had `status: ok`; the two section caveats were aggregated at batch level, without per-success-item association. This is the existing successful-item provenance problem in #8350, now directly relevant to this route. - Once the project export completed, both selected addresses returned null because that export had no body, each with the classification and no-body caveats. A fresh exact-range `decompile_all` for the code address selected zero entries because that workflow starts from the filtered inventory. Permitting the direct lookup alone therefore does not provide a reliable decompile/export workflow. The real-Kuna cold/warm comparison used an owned launcher that delayed `decompile-project` by 12 seconds; this is controlled scheduling, not a natural frequency or release-integrity check. Direct, batch, path and warm-result Evidence survived target-free bundle export/import with their normalized results and limitations. SDK 2.3.1 validated successful compact responses; fixture and Brotli hashes were unchanged and neither target ran. The existing two provider/MCP boundary files gave 7 passes and 1 failure at an assertion on the original categorical omission wording; later assertions in that failed test did not run. The prototype also permits explicit selection of the header and does not resolve name discovery, batch item attribution, warm-cache behavior, output bounds, cancellation, or other formats. It is deliberately not integration-ready. The evidence suggests evaluating an explicitly qualified address-based investigation together with its batch, export and provider-state behavior, rather than assuming this small override resolves the issue.

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Additional agent-recovery check on a second fixture (two direct calls), using the full advertised MCP output schemas and verified Kuna 1.986:

After procedure_callees(_main) returned the _middle address, procedure_address, procedure_assembly, and analyze_function all rejected that exact address with the section-classification message described above. Their structured error also says recovery.kind: inspect_input_contract and advises the agent to read the tool schema, correct fields, and retry. The requests themselves use the advertised schema; inspecting it cannot resolve the provider's classification.
read_function_instructions returns capability_unavailable for Kuna. On the same binary through Ghidra, the address resolves and both assembly and instruction-list requests return the two instructions. Ghidra provider selection remains an explicit user choice, with its own session state.
An unverified current Kuna source build also rejects the same explicit address, but because it is absent from its discovered procedure inventory; it likewise returns the schema-inspection recovery. This observation is not a verified-release claim.

Source-derived: these semantic lookup refusals are constructed as AnalysisInputError without distinguishing a contract-valid selector; generic error projection then supplies schema recovery. A useful fix should preserve the actual unknown/classification reason and a truthful available next step, rather than making an unconditional provider switch or claiming arbitrary data is code. Related recovery design for selected Ghidra projects: #8208; the resulting complete negative caller/path evidence is tracked separately in #8362.

@morluto commented on GitHub (Oct 31, 2026): Additional agent-recovery check on a second fixture (two direct calls), using the full advertised MCP output schemas and verified Kuna 1.986: - After `procedure_callees(_main)` returned the `_middle` address, `procedure_address`, `procedure_assembly`, and `analyze_function` all rejected that exact address with the section-classification message described above. Their structured error also says `recovery.kind: inspect_input_contract` and advises the agent to read the tool schema, correct fields, and retry. The requests themselves use the advertised schema; inspecting it cannot resolve the provider's classification. - `read_function_instructions` returns `capability_unavailable` for Kuna. On the same binary through Ghidra, the address resolves and both assembly and instruction-list requests return the two instructions. Ghidra provider selection remains an explicit user choice, with its own session state. - An unverified current Kuna source build also rejects the same explicit address, but because it is absent from its discovered procedure inventory; it likewise returns the schema-inspection recovery. This observation is not a verified-release claim. Source-derived: these semantic lookup refusals are constructed as `AnalysisInputError` without distinguishing a contract-valid selector; generic error projection then supplies schema recovery. A useful fix should preserve the actual unknown/classification reason and a truthful available next step, rather than making an unconditional provider switch or claiming arbitrary data is code. Related recovery design for selected Ghidra projects: #8208; the resulting complete negative caller/path evidence is tracked separately in #8362.

bsakaguchi referenced this issue

2026-11-01 21:47:26 +00:00

[PR #6570] [MERGED] fix(tests): stabilize process fixtures and malformed input coverage #7379

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

No description provided.

Rows
Columns