[GH-ISSUE #3664] [Bug] Invalidate Ghidra snapshots with pre-filter instruction references #1377

New issue

Closed

opened 2026-10-16 21:04:50 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:04:50 +00:00

Owner

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

Problem

#3204 is fixed on current main for fresh Ghidra analysis, but the persisted analysis-profile marker remains instruction_references: "exact-address-incoming-v1" before and after the behavior change. A snapshot produced before the fix can therefore still contain Ghidra's synthetic Entry Point:0x0 incoming reference and be admitted after upgrading, presenting the stale result under the corrected implementation.

The eligibility rule is also still duplicated: exact-address incoming references, xrefs, and function-level incoming/outgoing references each enumerate ReferenceManager results and independently decide whether an entry-point reference is observable. That divergence caused #3204 and makes another inconsistent consumer likely.

Proposed fix

Give observed Ghidra references one producer-side enumeration boundary that owns cancellation and excludes isEntryPointReference() before downstream formatting/deduplication.
Bump the instruction-reference coverage marker to a v2 name that states the corrected semantics for both raw and regular profiles.
Reject snapshots with v1 or missing instruction-reference coverage.

Evidence and verification

Current main after #3204 still emits exact-address-incoming-v1 in both Ghidra analysis profiles, and the snapshot admission test treats that value as current.
The original real Windows x64/x86 PE EXE reproduction is documented in #3204; both architectures exposed the synthetic reference before the fresh-analysis fix.
A candidate with the shared boundary and v2 marker has passed ordinary-user Ghidra 12.1.4 Windows workflows for x64/x86 EXE and DLL targets. All four lanes covered 26 provider operations, completed cleanup, left zero owned processes, and the EXE lanes passed synthetic-exclusion plus incoming/xrefs parity assertions. Detailed measurements will be included in the PR.

This is a read-only result/caching correction. It does not expand Ghidra authority or mutate target bytes.

Originally created by @N0zoM1z0 on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3664 ## Problem #3204 is fixed on current `main` for fresh Ghidra analysis, but the persisted analysis-profile marker remains `instruction_references: "exact-address-incoming-v1"` before and after the behavior change. A snapshot produced before the fix can therefore still contain Ghidra's synthetic `Entry Point:0x0` incoming reference and be admitted after upgrading, presenting the stale result under the corrected implementation. The eligibility rule is also still duplicated: exact-address incoming references, xrefs, and function-level incoming/outgoing references each enumerate `ReferenceManager` results and independently decide whether an entry-point reference is observable. That divergence caused #3204 and makes another inconsistent consumer likely. ## Proposed fix - Give observed Ghidra references one producer-side enumeration boundary that owns cancellation and excludes `isEntryPointReference()` before downstream formatting/deduplication. - Bump the instruction-reference coverage marker to a v2 name that states the corrected semantics for both raw and regular profiles. - Reject snapshots with v1 or missing instruction-reference coverage. ## Evidence and verification - Current `main` after #3204 still emits `exact-address-incoming-v1` in both Ghidra analysis profiles, and the snapshot admission test treats that value as current. - The original real Windows x64/x86 PE EXE reproduction is documented in #3204; both architectures exposed the synthetic reference before the fresh-analysis fix. - A candidate with the shared boundary and v2 marker has passed ordinary-user Ghidra 12.1.4 Windows workflows for x64/x86 EXE and DLL targets. All four lanes covered 26 provider operations, completed cleanup, left zero owned processes, and the EXE lanes passed synthetic-exclusion plus incoming/xrefs parity assertions. Detailed measurements will be included in the PR. This is a read-only result/caching correction. It does not expand Ghidra authority or mutate target bytes.

bsakaguchi closed this issue

2026-10-16 21:04:50 +00:00

bsakaguchi commented

2026-10-16 21:04:51 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 14, 2026):

Candidate validation is complete on exact head a1337e4c70f262d6ec027091480a2b9a0d7bcdfc, after normally merging current main fffb0741936067530d1ce9777461cd53e87398c2.

The final diff has three Ghidra files: one producer-side reference observation boundary, the v2 raw/regular profile identity, and snapshot-admission coverage for v1 plus missing markers. Local validation passed 218/218 changed tests, a fresh build, and non-cached typecheck/lint.

Real Windows Ghidra 12.1.4/JDK 21 replayed the complete x64 and x86 PE EXE workflows under an ordinary non-admin user, serialized on 2 logical CPUs with BelowNormal priority, Node/Java 768 MiB and a 3 GiB process-family Job limit. Both passed all 26 provider operations, synthetic-entry exclusion, incoming/xrefs and typed/full reference parity, reference ordering, source immutability, and complete cleanup; both left zero owned processes and had empty stderr.

x64: 1018.98 s wall, 632.28 s sampled process-family CPU, 2033.13 MiB peak Job commit, 1281.49 MiB sampled working set, 11.28 GiB minimum host free memory, 2623 output bytes.
x86: 968.48 s wall, 317.73 s sampled CPU, 2030.87 MiB Job, 1105.19 MiB working set, 13.83 GiB minimum host free memory, 2620 output bytes.

The exact-head bridge hash matches the earlier four-lane x64/x86 EXE+DLL candidate, whose DLL controls also passed. Byte-search continues to report cli_mcp_parity:false; file-offset parity passed. Two-second sampling can miss short-lived children. Whole-agent token cost is unmeasured and these data do not support a speedup claim.

@N0zoM1z0 commented on GitHub (Oct 14, 2026): Candidate validation is complete on exact head `a1337e4c70f262d6ec027091480a2b9a0d7bcdfc`, after normally merging current `main` `fffb0741936067530d1ce9777461cd53e87398c2`. The final diff has three Ghidra files: one producer-side reference observation boundary, the v2 raw/regular profile identity, and snapshot-admission coverage for v1 plus missing markers. Local validation passed 218/218 changed tests, a fresh build, and non-cached typecheck/lint. Real Windows Ghidra 12.1.4/JDK 21 replayed the complete x64 and x86 PE EXE workflows under an ordinary non-admin user, serialized on 2 logical CPUs with BelowNormal priority, Node/Java 768 MiB and a 3 GiB process-family Job limit. Both passed all 26 provider operations, synthetic-entry exclusion, incoming/xrefs and typed/full reference parity, reference ordering, source immutability, and complete cleanup; both left zero owned processes and had empty stderr. - x64: 1018.98 s wall, 632.28 s sampled process-family CPU, 2033.13 MiB peak Job commit, 1281.49 MiB sampled working set, 11.28 GiB minimum host free memory, 2623 output bytes. - x86: 968.48 s wall, 317.73 s sampled CPU, 2030.87 MiB Job, 1105.19 MiB working set, 13.83 GiB minimum host free memory, 2620 output bytes. The exact-head bridge hash matches the earlier four-lane x64/x86 EXE+DLL candidate, whose DLL controls also passed. Byte-search continues to report `cli_mcp_parity:false`; file-offset parity passed. Two-second sampling can miss short-lived children. Whole-agent token cost is unmeasured and these data do not support a speedup claim.

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

No description provided.

Rows
Columns