morluto/rea

Fork 0

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

[GH-ISSUE #8393] [Design] Compare function observations within one selected Ghidra project #6580

New issue

Open

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

bsakaguchi commented

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

Owner

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

Before submitting

I searched open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Can two authenticated Ghidra function observations from the same immutable, selected project/program be compared in a shared project coordinate context, without treating that context as a mapping to the original binary, a fresh import, or a different project?

Context and evidence

On REA main 6e9ee97a with Ghidra 12.1.4, I opened an owned analyzed arm64 Mach-O project read-only. I requested _caller once by symbol and once by its entry address. The resulting complete analyze_function records had different Evidence IDs, the same target SHA-256, the same selected-project profile and program, and the same entry 0x1000012e8. After exporting and importing the records into a separate target-free MCP server, compare_functions matched the function by symbol but reported its references comparison unknown because no common coordinate context was committed. The calls comparison was also unknown for that reason. This differs from #8367's case of passing one Evidence ID twice.

The selected project's profile records a fingerprint of the selected project files and program name, but existingGhidraAnalysisProfile does not emit the function_coordinate_context that the comparison requires. This is source-derived; a project fingerprint is an identity commitment, not a direct observation of its memory mapping. A target import digest does not establish that a selected project is unedited or unre-based.

I tried a disposable prototype on top of #8391: it derives a same-project-only context from the selected project commitment, with a distinct domain marker. With the same fixture and two records, both the original and a separately rebased project's same-project comparisons matched by same-entry and reported the recorded references unchanged. The calls comparison remained unknown under #8391 because the selected projects' prior analysis completeness is unestablished. This is an exploratory result, not a proposed production patch or proof that the project fingerprint alone suffices in every case.

A negative control is important: the rebased project places _decoy at 0x1000012e8, the exact numeric address of _caller in the original project. The prototype's cross-project comparison did not match these as the same entry; it remained ambiguous. Comparing the original selected project to a fresh Ghidra import also retained unknown coordinate context. A different entry within the same selected project was identified as distinct. All comparisons were performed after bundle import into a target-free server; target and both original project file hashes were unchanged by REA, and the source-owned target was not executed.

The incomplete-project control from #8390 shows a caveat: on a no-analysis project, the prototype can report the two recorded reference sets as unchanged even though the project did not discover a known direct call. The overall comparison remains unknown and its outer Evidence retains the unknown project-history limitation, but the references dimension has no explicit observed-project-scope limitation. Any design should ensure a comparison of recorded facts cannot be read as an exhaustive artifact or behavior claim.

Expected interaction with targets

Read caller-selected local project/target files and retained Evidence; launch Ghidra only for the existing static-analysis workflow. No target execution or mutation is proposed.

Boundary details

Keep target digest, provider identity/version, exact project fingerprint and selected program, image/slice selection, address space, and any needed mapping facts distinct. Different project fingerprints or a missing commitment must not be assumed equivalent. Preserve the selected project's own memory and edits; do not infer equivalence to original file bytes or rebase addresses by arithmetic. Explain whether a positive result is equality of retained observations or a stronger claim. Consider snapshot/profile invalidation and old historical Evidence.

Options and tradeoffs

Keep current fail-closed behavior and improve the explanation or manual workflow.
Define a tagged same-project/program coordinate commitment and use it only when both authenticated sources satisfy its identity and applicability rules. A fingerprint-derived commitment must not be mislabeled as a directly measured mapping.
Expose an explicitly scoped comparison of recorded reference sets, independent of whole-artifact completeness. Preserve existing uncertainty for unobserved data and cross-project/provider coordinates.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Verify two distinct records from one selected project across sessions and offline imports; different entries; rebased projects with overlapping numeric addresses; fresh-versus-selected and cross-provider observations; modified project memory, overlays and multiple address spaces; universal Mach-O slice identity; missing/malformed commitments and old snapshots; and incomplete analysis. Establish what facts make same-project mapping stable before integration. One macOS arm64 host and fixture do not establish other platforms or generality.

References

Related #8367 (identical Kuna Evidence ID), #8372 (cross-provider mapping), #8213 (same-entry identity under a known context), #8390 / #8391 (selected-project call coverage), and #8215 (profile explanations). Maintainers: @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8393 ### Before submitting - [x] I searched open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Can two authenticated Ghidra function observations from the same immutable, selected project/program be compared in a shared project coordinate context, without treating that context as a mapping to the original binary, a fresh import, or a different project? ### Context and evidence On REA main `6e9ee97a` with Ghidra 12.1.4, I opened an owned analyzed arm64 Mach-O project read-only. I requested `_caller` once by symbol and once by its entry address. The resulting complete `analyze_function` records had **different Evidence IDs**, the same target SHA-256, the same selected-project profile and program, and the same entry `0x1000012e8`. After exporting and importing the records into a separate target-free MCP server, `compare_functions` matched the function by symbol but reported its references comparison `unknown` because no common coordinate context was committed. The calls comparison was also unknown for that reason. This differs from #8367's case of passing one Evidence ID twice. The selected project's profile records a fingerprint of the selected project files and program name, but `existingGhidraAnalysisProfile` does not emit the `function_coordinate_context` that the comparison requires. This is source-derived; a project fingerprint is an identity commitment, not a direct observation of its memory mapping. A target import digest does not establish that a selected project is unedited or unre-based. I tried a disposable prototype on top of #8391: it derives a same-project-only context from the selected project commitment, with a distinct domain marker. With the same fixture and two records, both the original and a separately rebased project's same-project comparisons matched by `same-entry` and reported the recorded references unchanged. The calls comparison remained unknown under #8391 because the selected projects' prior analysis completeness is unestablished. This is an exploratory result, not a proposed production patch or proof that the project fingerprint alone suffices in every case. A negative control is important: the rebased project places `_decoy` at `0x1000012e8`, the exact numeric address of `_caller` in the original project. The prototype's cross-project comparison did **not** match these as the same entry; it remained ambiguous. Comparing the original selected project to a fresh Ghidra import also retained unknown coordinate context. A different entry within the same selected project was identified as distinct. All comparisons were performed after bundle import into a target-free server; target and both original project file hashes were unchanged by REA, and the source-owned target was not executed. The incomplete-project control from #8390 shows a caveat: on a no-analysis project, the prototype can report the two recorded reference sets as unchanged even though the project did not discover a known direct call. The overall comparison remains unknown and its outer Evidence retains the unknown project-history limitation, but the references dimension has no explicit observed-project-scope limitation. Any design should ensure a comparison of recorded facts cannot be read as an exhaustive artifact or behavior claim. ### Expected interaction with targets Read caller-selected local project/target files and retained Evidence; launch Ghidra only for the existing static-analysis workflow. No target execution or mutation is proposed. ### Boundary details Keep target digest, provider identity/version, exact project fingerprint and selected program, image/slice selection, address space, and any needed mapping facts distinct. Different project fingerprints or a missing commitment must not be assumed equivalent. Preserve the selected project's own memory and edits; do not infer equivalence to original file bytes or rebase addresses by arithmetic. Explain whether a positive result is equality of retained observations or a stronger claim. Consider snapshot/profile invalidation and old historical Evidence. ### Options and tradeoffs - Keep current fail-closed behavior and improve the explanation or manual workflow. - Define a tagged same-project/program coordinate commitment and use it only when both authenticated sources satisfy its identity and applicability rules. A fingerprint-derived commitment must not be mislabeled as a directly measured mapping. - Expose an explicitly scoped comparison of recorded reference sets, independent of whole-artifact completeness. Preserve existing uncertainty for unobserved data and cross-project/provider coordinates. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Verify two distinct records from one selected project across sessions and offline imports; different entries; rebased projects with overlapping numeric addresses; fresh-versus-selected and cross-provider observations; modified project memory, overlays and multiple address spaces; universal Mach-O slice identity; missing/malformed commitments and old snapshots; and incomplete analysis. Establish what facts make same-project mapping stable before integration. One macOS arm64 host and fixture do not establish other platforms or generality. ### References Related #8367 (identical Kuna Evidence ID), #8372 (cross-provider mapping), #8213 (same-entry identity under a known context), #8390 / #8391 (selected-project call coverage), and #8215 (profile explanations). Maintainers: @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

enhancement

triage

labels

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

No description provided.

Rows
Columns