[GH-ISSUE #553] Managed PE/CLI inspection must use explicit targets consistently through CLI and MCP #282

New issue

Closed

opened 2026-10-15 18:23:24 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:23:24 +00:00

Owner

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

Remaining scope

The managed MCP artifact handler still opens through the native session, unlike direct managed inspection. Managed artifact, member and native-boundary inspection should use the managed provider consistently for the same explicit file. The secondary seed allegation was investigated and is not established by the cited graph: application route seeds address route-kind endpoints, API seeds address context-bridge APIs, and semantic endpoint/literal seeds address companion-graph request/literal nodes. A network endpoint produced from call:app.get is a different node type. Any Express route-recognition defect needs its own source-level reproduction.

Verification

Exercise representative valid and malformed producer data through the consumer boundary and assert the resulting observations, unknowns, or actionable failure. Keep CLI/MCP behavior aligned where applicable.

This scope was refreshed after removal of replay and permission plumbing and merge of PR #538; implementation is being addressed in the boundary root-cause cleanup.

Reproduction

Inside one session with a native PE open (notepad.exe), against System.Text.Json.dll:

await open_binary({ path: "C:\\Windows\\System32\\notepad.exe", provider_id: "ghidra" });

await inspect_managed_members({ path: "C:\\...\\System.Text.Json.dll" });
// OK  -> predicate_type "rea.analysis", full member inventory

await inspect_managed_artifact({ path: "C:\\...\\System.Text.Json.dll" });
// capability_unavailable / unsupported_provider
// "The selected analysis provider does not support this target"
//   rejections[0].provider_id = "ghidra"
//   rejections[0].code        = "target_role_unsupported"
//   rejections[0].reason      = "Windows Ghidra P0 accepts PE applications,
//                                 not DLL or non-executable images."

await inspect_managed_native_boundaries({ path: "C:\\...\\System.TextJson.dll" });
// execution_failure

So inspect_managed_members takes a managed-only path, while inspect_managed_artifact is routed through the deep-analysis session and hits the Windows Ghidra P0 target-role boundary — which by design rejects DLLs.

The CLI equivalents behave differently again: rea inspect-managed-artifact <dll> and rea inspect-managed-members <dll> both succeed and return full Evidence with SHA-256 digests. So the same operation is reachable via CLI and unreachable via MCP.

Originally created by @whft on GitHub (Oct 5, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/553 ## Remaining scope The managed MCP artifact handler still opens through the native session, unlike direct managed inspection. Managed artifact, member and native-boundary inspection should use the managed provider consistently for the same explicit file. The secondary seed allegation was investigated and is not established by the cited graph: application route seeds address route-kind endpoints, API seeds address context-bridge APIs, and semantic endpoint/literal seeds address companion-graph request/literal nodes. A network endpoint produced from call:app.get is a different node type. Any Express route-recognition defect needs its own source-level reproduction. ## Verification Exercise representative valid and malformed producer data through the consumer boundary and assert the resulting observations, unknowns, or actionable failure. Keep CLI/MCP behavior aligned where applicable. This scope was refreshed after removal of replay and permission plumbing and merge of PR #538; implementation is being addressed in the boundary root-cause cleanup. ## Reproduction Inside one session with a native PE open (`notepad.exe`), against `System.Text.Json.dll`: ```js await open_binary({ path: "C:\\Windows\\System32\\notepad.exe", provider_id: "ghidra" }); await inspect_managed_members({ path: "C:\\...\\System.Text.Json.dll" }); // OK -> predicate_type "rea.analysis", full member inventory await inspect_managed_artifact({ path: "C:\\...\\System.Text.Json.dll" }); // capability_unavailable / unsupported_provider // "The selected analysis provider does not support this target" // rejections[0].provider_id = "ghidra" // rejections[0].code = "target_role_unsupported" // rejections[0].reason = "Windows Ghidra P0 accepts PE applications, // not DLL or non-executable images." await inspect_managed_native_boundaries({ path: "C:\\...\\System.TextJson.dll" }); // execution_failure ``` So `inspect_managed_members` takes a managed-only path, while `inspect_managed_artifact` is routed through the deep-analysis session and hits the Windows Ghidra P0 target-role boundary — which by design rejects DLLs. The CLI equivalents behave differently again: `rea inspect-managed-artifact <dll>` and `rea inspect-managed-members <dll>` both succeed and return full Evidence with SHA-256 digests. So the same operation is reachable via CLI and unreachable via MCP.

bsakaguchi

2026-10-15 18:23:24 +00:00

closed this issue
added the
area: cli

enhancement
labels

bsakaguchi commented

2026-10-15 18:23:27 +00:00

Author

Owner

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

The confirmed managed routing defect is fixed in #597: all three inspection tools accept the same explicit PE/CLI path through a managed-only session and return Evidence bound to that file, independently of an active native target. Failed selections do not overwrite the last successful managed selection. Public MCP regressions and the installed-package managed checks pass locally; Windows execution remains for CI.

I narrowed this issue to that defect after checking the secondary seed report. The cited node is an application-graph network endpoint. A route seed matches route-kind endpoints; an API seed matches context-bridge APIs. Semantic endpoint and literal seeds address request and literal nodes in the companion semantic graph. The reported network node therefore does not establish a dead matcher, and the application's zero-match outcome explicitly states that it does not prove feature absence. Existing acceptance coverage demonstrates matching API seeds.

Recognizing a particular Express app.get call as a route would be a separate source-recognition report; it needs the relevant source and binding context. The managed defect will close when #597 merges.

@morluto commented on GitHub (Oct 5, 2026): The confirmed managed routing defect is fixed in #597: all three inspection tools accept the same explicit PE/CLI path through a managed-only session and return Evidence bound to that file, independently of an active native target. Failed selections do not overwrite the last successful managed selection. Public MCP regressions and the installed-package managed checks pass locally; Windows execution remains for CI. I narrowed this issue to that defect after checking the secondary seed report. The cited node is an application-graph network endpoint. A route seed matches route-kind endpoints; an API seed matches context-bridge APIs. Semantic endpoint and literal seeds address request and literal nodes in the companion semantic graph. The reported network node therefore does not establish a dead matcher, and the application's zero-match outcome explicitly states that it does not prove feature absence. Existing acceptance coverage demonstrates matching API seeds. Recognizing a particular Express `app.get` call as a route would be a separate source-recognition report; it needs the relevant source and binding context. The managed defect will close when #597 merges.

bsakaguchi referenced this issue

2026-10-15 18:28:04 +00:00

[GH-ISSUE #2299] [Feature] Return optional decompiled C# for selected .NET members as reconstruction inference #761

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:12:32 +00:00

[PR #282] [MERGED] feat(dotnet): add BYO ILSpy oracle diagnostics #1923

bsakaguchi added

enhancement

and removed