morluto/rea

Fork 0

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

[GH-ISSUE #8815] [Bug] Ghidra literal search raw results do not identify candidate rows #7760

New issue

Open

opened 2026-11-03 16:33:11 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 16:33:11 +00:00

Owner

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

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; MCP and Evidence.

Observed behavior

For Ghidra case-insensitive literal searches, raw_result contains the bridge's deliberately broad candidate rows before REA applies its Unicode-aware matcher. The result does not identify those rows as candidates, so an agent inspecting the source evidence may mistake a nonmatching raw row for a match.

Reproduction

On REA 187f3d8cc, Ghidra 12.1.4/JDK 21 and macOS arm64, I opened a source-owned Mach-O in a real MCP session, used set_address_name to rename a function Ωprobe in the ephemeral database, and called search_procedures with pattern: "zzz_absent_321" (default case-insensitive literal mode). The response succeeded; raw_result contained the Ωprobe candidate while normalized_result was empty. Neither the response limitations nor the input parameters identified the raw row as an unfiltered candidate. Output validated against the advertised SDK schema. Closing the session discarded the metadata edit, and the executable SHA-256 cf3bbb6ecd658978ebaecc91189fbc280e9b82aedce1add7ff69333cef5053db stayed unchanged.

Expected behavior

Keep the exact raw provider observation and correct normalized matches, and make their differing roles clear to agents in the response. Do not infer that every raw row matches, silently discard source rows, or claim discovery beyond the provider inventory.

Impact and scope

The normalized answer is correct in this test; the ambiguity is the interpretation of the retained raw observation. One function, one target, one host and one case-insensitive literal query were exercised; no autonomous-agent mistake or broader frequency was measured.

REA version

187f3d8cc (the 1.990 verification branch, with unchanged Ghidra search behavior).

Runtime and platform

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

Target and artifact context

Source-owned arm64 Mach-O; ephemeral metadata edit only; target not executed or modified.

Interface

MCP

Earliest failure stage

Evidence projection / explanation of provider observation.

Relevant output or evidence

raw_result: [{value: "Ωprobe", ...}]; normalized_result: []; query pattern: "zzz_absent_321", mode: "literal", case_sensitive: false.

Typed outcome or recovery expected

Distinguish raw candidate rows from normalized matches while preserving both. Check procedures and strings, case-sensitive/regex modes, summaries and retained views, offline Evidence, source identity and SDK output schemas.

Analysis or suspected cause

Source-derived: GhidraProviderClient records the bridge result in rawResult and applies filterGhidraLiteralCandidates to construct normalized. The bridge keeps non-ASCII candidates to avoid losing matches across runtime Unicode versions. In a separate broad alias query the two arrays happened to be equal; this control shows equality is not an invariant. Related #8814 concerns bounded views, not this interpretation issue.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8815 ### 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; MCP and Evidence. ### Observed behavior For Ghidra case-insensitive literal searches, `raw_result` contains the bridge's deliberately broad candidate rows before REA applies its Unicode-aware matcher. The result does not identify those rows as candidates, so an agent inspecting the source evidence may mistake a nonmatching raw row for a match. ### Reproduction On REA `187f3d8cc`, Ghidra 12.1.4/JDK 21 and macOS arm64, I opened a source-owned Mach-O in a real MCP session, used `set_address_name` to rename a function `Ωprobe` in the ephemeral database, and called `search_procedures` with `pattern: "zzz_absent_321"` (default case-insensitive literal mode). The response succeeded; `raw_result` contained the `Ωprobe` candidate while `normalized_result` was empty. Neither the response limitations nor the input parameters identified the raw row as an unfiltered candidate. Output validated against the advertised SDK schema. Closing the session discarded the metadata edit, and the executable SHA-256 `cf3bbb6ecd658978ebaecc91189fbc280e9b82aedce1add7ff69333cef5053db` stayed unchanged. ### Expected behavior Keep the exact raw provider observation and correct normalized matches, and make their differing roles clear to agents in the response. Do not infer that every raw row matches, silently discard source rows, or claim discovery beyond the provider inventory. ### Impact and scope The normalized answer is correct in this test; the ambiguity is the interpretation of the retained raw observation. One function, one target, one host and one case-insensitive literal query were exercised; no autonomous-agent mistake or broader frequency was measured. ### REA version `187f3d8cc` (the 1.990 verification branch, with unchanged Ghidra search behavior). ### Runtime and platform macOS arm64, Node 24.22.1, Ghidra 12.1.4/JDK 21, stdio MCP. ### Target and artifact context Source-owned arm64 Mach-O; ephemeral metadata edit only; target not executed or modified. ### Interface MCP ### Earliest failure stage Evidence projection / explanation of provider observation. ### Relevant output or evidence `raw_result: [{value: "Ωprobe", ...}]`; `normalized_result: []`; query `pattern: "zzz_absent_321", mode: "literal", case_sensitive: false`. ### Typed outcome or recovery expected Distinguish raw candidate rows from normalized matches while preserving both. Check procedures and strings, case-sensitive/regex modes, summaries and retained views, offline Evidence, source identity and SDK output schemas. ### Analysis or suspected cause Source-derived: `GhidraProviderClient` records the bridge result in `rawResult` and applies `filterGhidraLiteralCandidates` to construct `normalized`. The bridge keeps non-ASCII candidates to avoid losing matches across runtime Unicode versions. In a separate broad alias query the two arrays happened to be equal; this control shows equality is not an invariant. Related #8814 concerns bounded views, not this interpretation issue. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

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

No description provided.

Rows
Columns