morluto/rea

Fork 0

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

[GH-ISSUE #8232] [Design] Compare selected Ghidra project memory with bounded original bytes #6501

New issue

Open

opened 2026-11-01 21:11:42 +00:00 by bsakaguchi · 7 comments

bsakaguchi commented

2026-11-01 21:11:42 +00:00

Owner

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

Before submitting

I searched the 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

Should an analyst be able to compare a bounded address range in a caller-selected Ghidra project's analyzed image with its mapped original artifact bytes, while keeping relocation effects and unknown causes explicit?

Context and evidence

On macOS arm64 / Ghidra 12.1.4, I imported an owned Mach-O into a new disposable project, used a separate headless script to change one instruction in the program database, and saved it. The executable itself was unchanged. The saved program's recorded import SHA-256 still matched the original executable, as expected: that is import identity, not a claim that its database was never edited.

A real REA MCP session selected this project. At 0x1000002d8, read_bytes returned 40058052c0035fd6 and pseudocode returned 0x2a. A separate REA fresh-import session for the same target returned 00008052c0035fd6 and pseudocode returned zero; direct reading of the original file at the Ghidra-reported offset 728 matched the fresh bytes. Both sessions mapped the address to 728. The existing-project Evidence records the project fingerprint, its import mode and a limitation that previous edits may exist; the installation guide correctly explains that matching import digests do not prove an unedited database. Original target and all ten selected project regular-file digests remained unchanged during REA's sessions. REA did not make the edit.

inspect_native_load_image(detail: summary) followed by an inspect_analysis_view native-load-image / source_files page exposed different original and modified source-file SHA-256 values for the edited project. The same view of this particular fresh-import fixture showed equal values. However, a different fresh-import Mach-O with a loader-applied relocation showed different original/modified source digests too, with an APPLIED relocation. Therefore digest inequality alone does not identify a user patch. Both examples returned verification: unsupported for Mach-O; an empty relocation collection in the edited example is only the provider's reported collection, not proof that all possible causes were excluded.

Expected interaction with targets

Read selected local artifact and provider observations; launch the user-supplied analysis provider; no target execution, byte mutation, or write to the source project is proposed.

Boundary details (optional)

Bind each observation to the exact target, selected project fingerprint/program, address space, mapping and byte range. Preserve uninitialized, unmapped, overlay, nonunique and unavailable cases. Imported file identity, Ghidra file-byte digest, analyzed memory, loader relocations and analyst edits are distinct observations; unknown cause must remain unknown. Do not infer a user patch from digest inequality, assume a complete relocation inventory, or treat an address-to-file-offset mapping as proof of byte equality.

Options and tradeoffs

Compare documenting the existing multi-step workflow, enriching an existing bounded bytes/load-image view with independently read original bytes and coverage, or a retained comparison composed from the existing contracts. A whole-image comparison may be expensive; an agent asking about a specific instruction can select a bounded range. Reuse existing read_bytes, address_to_file_offset, and inspect_native_load_image rather than adding a provider-only API wrapper. Consider an explicit source/project origin in the result alongside existing profile and limitations, without weakening Evidence identity.

Verification available so far

I have a prototype or observed results

Success criteria and open questions

Exercise a saved byte-edited project, a no-edit project, fresh imports with and without relocations, mapped/unmapped and uninitialized ranges, multiple source files, overlaps/overlays, changed source digest and partial reads. Confirm correct provenance and that relocation or unknown cause is not labeled a patch. Large projects, CLI, other operating systems, Ghidra versions, and actual agent decisions remain untested. Establish resource bounds and cleanup behavior before any integration.

References

Existing-project documentation
Related #3751 (project selection), #8165 (checkpoint), and #8170 (analyzed versus source bytes and Kuna capability).

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8232 ### Before submitting - [x] I searched the 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 Should an analyst be able to compare a bounded address range in a caller-selected Ghidra project's analyzed image with its mapped original artifact bytes, while keeping relocation effects and unknown causes explicit? ### Context and evidence On macOS arm64 / Ghidra 12.1.4, I imported an owned Mach-O into a new disposable project, used a separate headless script to change one instruction in the program database, and saved it. The executable itself was unchanged. The saved program's recorded import SHA-256 still matched the original executable, as expected: that is import identity, not a claim that its database was never edited. A real REA MCP session selected this project. At `0x1000002d8`, `read_bytes` returned `40058052c0035fd6` and pseudocode returned `0x2a`. A separate REA fresh-import session for the same target returned `00008052c0035fd6` and pseudocode returned zero; direct reading of the original file at the Ghidra-reported offset 728 matched the fresh bytes. Both sessions mapped the address to 728. The existing-project Evidence records the project fingerprint, its import mode and a limitation that previous edits may exist; the installation guide correctly explains that matching import digests do not prove an unedited database. Original target and all ten selected project regular-file digests remained unchanged during REA's sessions. REA did not make the edit. `inspect_native_load_image(detail: summary)` followed by an `inspect_analysis_view` `native-load-image` / `source_files` page exposed different original and modified source-file SHA-256 values for the edited project. The same view of this particular fresh-import fixture showed equal values. However, a different fresh-import Mach-O with a loader-applied relocation showed different original/modified source digests too, with an `APPLIED` relocation. Therefore digest inequality alone does not identify a user patch. Both examples returned `verification: unsupported` for Mach-O; an empty relocation collection in the edited example is only the provider's reported collection, not proof that all possible causes were excluded. ### Expected interaction with targets Read selected local artifact and provider observations; launch the user-supplied analysis provider; no target execution, byte mutation, or write to the source project is proposed. ### Boundary details (optional) Bind each observation to the exact target, selected project fingerprint/program, address space, mapping and byte range. Preserve uninitialized, unmapped, overlay, nonunique and unavailable cases. Imported file identity, Ghidra file-byte digest, analyzed memory, loader relocations and analyst edits are distinct observations; unknown cause must remain unknown. Do not infer a user patch from digest inequality, assume a complete relocation inventory, or treat an address-to-file-offset mapping as proof of byte equality. ### Options and tradeoffs Compare documenting the existing multi-step workflow, enriching an existing bounded bytes/load-image view with independently read original bytes and coverage, or a retained comparison composed from the existing contracts. A whole-image comparison may be expensive; an agent asking about a specific instruction can select a bounded range. Reuse existing `read_bytes`, `address_to_file_offset`, and `inspect_native_load_image` rather than adding a provider-only API wrapper. Consider an explicit source/project origin in the result alongside existing profile and limitations, without weakening Evidence identity. ### Verification available so far I have a prototype or observed results ### Success criteria and open questions Exercise a saved byte-edited project, a no-edit project, fresh imports with and without relocations, mapped/unmapped and uninitialized ranges, multiple source files, overlaps/overlays, changed source digest and partial reads. Confirm correct provenance and that relocation or unknown cause is not labeled a patch. Large projects, CLI, other operating systems, Ghidra versions, and actual agent decisions remain untested. Establish resource bounds and cleanup behavior before any integration. ### References - [Existing-project documentation](https://github.com/morluto/rea/blob/53a4ab78451a0654e9c3beb3d43a5e371a288fcc/docs/installation.md#reuse-an-existing-ghidra-project) - Related #3751 (project selection), #8165 (checkpoint), and #8170 (analyzed versus source bytes and Kuna capability).

bsakaguchi added the

enhancement

triage

labels

2026-11-01 21:11:42 +00:00

bsakaguchi commented

2026-11-01 21:11:42 +00:00

Author

Owner

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

An overlay control adds an important limitation to digest-based comparison. In a new owned Ghidra project, I added a 16-byte initialized overlay at the same numeric address as the file-backed entry, without changing the original file-backed bytes. REA/Ghidra's source-files view reported equal original and modified source digests, while its mappings view separately exposed an initialized overlay in AUDIT_OVERLAY with source_file_index: null and file_offset: null. read_bytes returned different bytes for the explicit overlay and default address-space coordinates; mapping the overlay to a file offset was refused. Equal source-file digests therefore do not establish that all program memory is file-backed or that an overlay has matching original bytes.

An explicitly bounded search_bytes over the overlay found all nine overlapping matches across three pages. An unbounded search omitted it and placed it under skipped_not_loaded even though the load-image mapping reported it as loaded; the provider guide documents this combined omission, and #8233 tracks the misleading category and MCP discoverability. This test used one authored overlay; it does not establish behavior for every overlay or provider. Target and project file contents stayed unchanged during REA sessions; the target was not executed.

@morluto commented on GitHub (Oct 30, 2026): An overlay control adds an important limitation to digest-based comparison. In a new owned Ghidra project, I added a 16-byte initialized overlay at the same numeric address as the file-backed entry, without changing the original file-backed bytes. REA/Ghidra's source-files view reported equal original and modified source digests, while its mappings view separately exposed an initialized overlay in `AUDIT_OVERLAY` with `source_file_index: null` and `file_offset: null`. `read_bytes` returned different bytes for the explicit overlay and default address-space coordinates; mapping the overlay to a file offset was refused. Equal source-file digests therefore do not establish that all program memory is file-backed or that an overlay has matching original bytes. An explicitly bounded `search_bytes` over the overlay found all nine overlapping matches across three pages. An unbounded search omitted it and placed it under `skipped_not_loaded` even though the load-image mapping reported it as loaded; the provider guide documents this combined omission, and #8233 tracks the misleading category and MCP discoverability. This test used one authored overlay; it does not establish behavior for every overlay or provider. Target and project file contents stayed unchanged during REA sessions; the target was not executed.

bsakaguchi commented

2026-11-01 21:11:42 +00:00

Author

Owner

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

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

bsakaguchi commented

2026-11-01 21:11:42 +00:00

Author

Owner

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

Explicit source offset with an edited saved program

I revisited the controlled edited-project fixture through the actual file-offset workflow. On REA b43c329df779708e43ae297f498a844e45d9c923 and Ghidra 12.1.4, procedure_pseudo_code({procedure:"file-offset:0x2d8"}) selected source offset 728, mapped address 0x1000002d8, and the same procedure entry in both a fresh import and the caller-selected, read-only edited project. The fresh result returned 0; the selected-project result returned 0x2a.

An independent read of the target file at offset 728 was 00008052c0035fd6. Real REA/Ghidra read_bytes returned those bytes in the fresh import, and 40058052c0035fd6 in the previously edited project. The selected-project Evidence recorded its content fingerprint and warned that prior edits may be present. inspect_native_load_image also retained different original/modified source-file digests, with independent Mach-O verification unsupported. The target SHA-256 and ten project-file hashes stayed unchanged during the REA sessions; the target was not executed.

This confirms a useful boundary for #8178 and this issue: a valid target-file coordinate can identify the source location while the selected analysis program contains different bytes. The test does not imply that every original/modified digest difference is a patch; the earlier loader-relocation control remains relevant.

@morluto commented on GitHub (Oct 31, 2026): ### Explicit source offset with an edited saved program I revisited the controlled edited-project fixture through the actual file-offset workflow. On REA `b43c329df779708e43ae297f498a844e45d9c923` and Ghidra 12.1.4, `procedure_pseudo_code({procedure:"file-offset:0x2d8"})` selected source offset `728`, mapped address `0x1000002d8`, and the same procedure entry in both a fresh import and the caller-selected, read-only edited project. The fresh result returned `0`; the selected-project result returned `0x2a`. An independent read of the target file at offset 728 was `00008052c0035fd6`. Real REA/Ghidra `read_bytes` returned those bytes in the fresh import, and `40058052c0035fd6` in the previously edited project. The selected-project Evidence recorded its content fingerprint and warned that prior edits may be present. `inspect_native_load_image` also retained different original/modified source-file digests, with independent Mach-O verification unsupported. The target SHA-256 and ten project-file hashes stayed unchanged during the REA sessions; the target was not executed. This confirms a useful boundary for #8178 and this issue: a valid target-file coordinate can identify the source location while the selected analysis program contains different bytes. The test does not imply that every original/modified digest difference is a patch; the earlier loader-relocation control remains relevant.

bsakaguchi commented

2026-11-01 21:11:42 +00:00

Author

Owner

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

Rechecked the earlier byte-edited project against current REA main 60149282 with real Ghidra 12.1.4. At the same mapped address/file offset, the selected saved project still returned edited instruction bytes and return 0x2a; a fresh import returned the original bytes and return 0, matching an independent file read. Both source-file digest views survived Evidence export and target-free import exactly. Target and source project hashes remained unchanged during the checks.

The project-discovery experiment in #8344 independently found the original executable SHA-256 in the edited program's saved DomainFile metadata. This is an import-identity observation, not proof that program memory is unchanged. The previous relocation control remains relevant: different source digests alone do not identify the cause. No target executed; this is one owned example, not broad format or provider coverage.

@morluto commented on GitHub (Oct 31, 2026): Rechecked the earlier byte-edited project against current REA main `60149282` with real Ghidra 12.1.4. At the same mapped address/file offset, the selected saved project still returned edited instruction bytes and `return 0x2a`; a fresh import returned the original bytes and `return 0`, matching an independent file read. Both source-file digest views survived Evidence export and target-free import exactly. Target and source project hashes remained unchanged during the checks. The project-discovery experiment in #8344 independently found the original executable SHA-256 in the edited program's saved `DomainFile` metadata. This is an import-identity observation, not proof that program memory is unchanged. The previous relocation control remains relevant: different source digests alone do not identify the cause. No target executed; this is one owned example, not broad format or provider coverage.

bsakaguchi commented

2026-11-01 21:11:42 +00:00

Author

Owner

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

A bounded file-to-memory comparison needs to stop at a mapping boundary, even when the input file has more bytes. I exercised a new self-built, unexecuted x86-64 ELF through real REA main 60149282 / Ghidra 12.1.4 MCP. Independent llvm-readelf identified an eight-byte .data file mapping immediately followed in virtual memory by eight-byte .bss (NOBITS); Ghidra placed them at 0x103360..0x103367 and 0x103368..0x10336f, respectively.

read_bytes({address:"0x103364",length:8}) returned only 55667788, returned_bytes: 4, complete: false. The start mapped to file offset 868, but the next virtual address 0x103368 produced an explicit file_mapping: uninitialized; 0x103370 was explicitly unmapped. A direct file read at offsets 868–875 gives 556677884c696e6b: the latter four bytes are from the unrelated on-disk .comment section, not a source for the BSS. The .data eight-byte read was complete and matched its source bytes.

This is a working negative control for the proposed comparison, not a new REA bug: the public result retains partial-read status and mapping failure. A future bounded comparison should report the four comparable source bytes and the remainder as unavailable rather than padding, inferring a contiguous file range from the first offset, or labeling the remainder changed. Compact MCP output schemas were fetched before the calls; target SHA-256 44bacc0c5a2321118915bfcf375fe9709dcc9423f99904336bbb3d3d114b55ee was unchanged. This single fresh-import ELF does not exercise edited projects, overlays, relocation effects or other formats.

Selected-project control: I separately imported the same ELF into a new owned Ghidra project with -noanalysis, then selected that program through REA's read-only project mode. The complete .data read, partial boundary read, uninitialized mapping refusal and unmapped-address refusal produced the same normalized results as the fresh import. The target and all regular-file hashes under the selected source project were unchanged during the REA calls. This adds one unedited selected-project control; it does not replace the earlier saved-byte-edit and relocation controls.

@morluto commented on GitHub (Oct 31, 2026): A bounded file-to-memory comparison needs to stop at a mapping boundary, even when the input file has more bytes. I exercised a new self-built, unexecuted x86-64 ELF through real REA main `60149282` / Ghidra 12.1.4 MCP. Independent `llvm-readelf` identified an eight-byte `.data` file mapping immediately followed in virtual memory by eight-byte `.bss` (`NOBITS`); Ghidra placed them at `0x103360..0x103367` and `0x103368..0x10336f`, respectively. `read_bytes({address:"0x103364",length:8})` returned only `55667788`, `returned_bytes: 4`, `complete: false`. The start mapped to file offset 868, but the next virtual address `0x103368` produced an explicit `file_mapping: uninitialized`; `0x103370` was explicitly `unmapped`. A direct file read at offsets 868–875 gives `556677884c696e6b`: the latter four bytes are from the unrelated on-disk `.comment` section, not a source for the BSS. The `.data` eight-byte read was complete and matched its source bytes. This is a working negative control for the proposed comparison, not a new REA bug: the public result retains partial-read status and mapping failure. A future bounded comparison should report the four comparable source bytes and the remainder as unavailable rather than padding, inferring a contiguous file range from the first offset, or labeling the remainder changed. Compact MCP output schemas were fetched before the calls; target SHA-256 `44bacc0c5a2321118915bfcf375fe9709dcc9423f99904336bbb3d3d114b55ee` was unchanged. This single fresh-import ELF does not exercise edited projects, overlays, relocation effects or other formats. Selected-project control: I separately imported the same ELF into a new owned Ghidra project with `-noanalysis`, then selected that program through REA's read-only project mode. The complete `.data` read, partial boundary read, uninitialized mapping refusal and unmapped-address refusal produced the same normalized results as the fresh import. The target and all regular-file hashes under the selected source project were unchanged during the REA calls. This adds one unedited selected-project control; it does not replace the earlier saved-byte-edit and relocation controls.

bsakaguchi commented

2026-11-01 21:11:42 +00:00

Author

Owner

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

I exercised a local orchestration experiment, not a new REA tool, against six real Ghidra 12.1.4 cases on main d54a4661d. For each selected range it read inspect_native_load_image, read_bytes and address_to_file_offset, checked the observed source-file digest against the explicitly selected target, and compared only bytes within the one matching initialized provider mapping. Original file bytes were read separately by the audit script; the comparison itself was not REA Evidence.

Fresh Mach-O: 8/8 compared bytes equal. The previously byte-edited selected project: 8/8 compared, different; no cause was assigned by the comparison.
Selected ELF .data crossing into .bss: 4/8 bytes compared and equal; the remaining four stayed unavailable. A wholly uninitialized range and a separately addressed initialized overlay both had no usable source-file mapping, even though the overlay's memory read succeeded.
Fresh Mach-O at an observed relocation: 8/8 compared, different. The same provider load-image observation separately recorded an APPLIED relocation at that address with the same original and memory bytes. Thus “different” cannot by itself mean analyst patch. An empty relocation list in another case is not proof that all causes are excluded.

For the edited and relocation cases, the three individual REA Evidence records (inspect_native_load_image, read_bytes, address_to_file_offset) survived export and exact import into a fresh targetless session. The audit script's independently read source bytes and comparison were not captured as a composed REA record, so those bundles alone are not a complete offline comparison. The provider's load-image status was unsupported for independent Mach-O/ELF verification; matching its mappings and digest does not upgrade that status to verified.

This supports testing a bounded, task-level comparison, while preserving the individual source observations, source-byte identity, address-space qualifier, partial/unavailable portions, and unknown difference cause. It is not production-ready: the experiment stopped at one provider mapping, did not handle mapping overlaps or ranges spanning multiple mappings, and did not establish a stable atomic source snapshot under concurrent changes. My initial harness also failed on a qualified overlay address; the corrected rerun kept the address space separate. All tested target and selected-project file hashes stayed unchanged during the main comparison runs; no target was executed.

@morluto commented on GitHub (Oct 31, 2026): I exercised a **local orchestration experiment**, not a new REA tool, against six real Ghidra 12.1.4 cases on main `d54a4661d`. For each selected range it read `inspect_native_load_image`, `read_bytes` and `address_to_file_offset`, checked the observed source-file digest against the explicitly selected target, and compared only bytes within the one matching initialized provider mapping. Original file bytes were read separately by the audit script; the comparison itself was not REA Evidence. - Fresh Mach-O: 8/8 compared bytes equal. The previously byte-edited selected project: 8/8 compared, different; no cause was assigned by the comparison. - Selected ELF `.data` crossing into `.bss`: 4/8 bytes compared and equal; the remaining four stayed unavailable. A wholly uninitialized range and a separately addressed initialized overlay both had no usable source-file mapping, even though the overlay's memory read succeeded. - Fresh Mach-O at an observed relocation: 8/8 compared, different. The same provider load-image observation separately recorded an `APPLIED` relocation at that address with the same original and memory bytes. Thus “different” cannot by itself mean analyst patch. An empty relocation list in another case is not proof that all causes are excluded. For the edited and relocation cases, the three individual REA Evidence records (`inspect_native_load_image`, `read_bytes`, `address_to_file_offset`) survived export and exact import into a fresh targetless session. The audit script's independently read source bytes and comparison were not captured as a composed REA record, so those bundles alone are not a complete offline comparison. The provider's load-image status was `unsupported` for independent Mach-O/ELF verification; matching its mappings and digest does not upgrade that status to verified. This supports testing a bounded, task-level comparison, while preserving the individual source observations, source-byte identity, address-space qualifier, partial/unavailable portions, and unknown difference cause. It is not production-ready: the experiment stopped at one provider mapping, did not handle mapping overlaps or ranges spanning multiple mappings, and did not establish a stable atomic source snapshot under concurrent changes. My initial harness also failed on a qualified overlay address; the corrected rerun kept the address space separate. All tested target and selected-project file hashes stayed unchanged during the main comparison runs; no target was executed.

bsakaguchi commented

2026-11-01 21:11:42 +00:00

Author

Owner

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

Additional real MCP search and handoff check on the same owned fixture and byte-edited selected project:

Within the bounded range 0x1000002d8..0x1000002df, search_bytes for 40 05 80 52 c0 03 5f d6 found the address in the selected project and reported file offset 728; the original-byte pattern returned no match in that range. read_bytes returned the edited pattern.
A fresh Ghidra import of the same target did the opposite: it found 00 00 80 52 c0 03 5f d6, did not find the edited pattern in that range, and reported the same address and offset. Direct reading of the original file at offset 728 gave the original pattern.
The selected-project and fresh observations carried distinct profile digests. Each search, byte-read and offset Evidence record survived export, close, and import in a fresh MCP server exactly, with full advertised output-schema validation.

This is expected analyzed-memory behavior, not a search correctness bug. It illustrates why a hit's file_offset identifies a mapping and does not assert the original file has the matching bytes. This project was deliberately edited by a separate headless script before the test; REA's sessions left both the target and every selected-project regular-file digest unchanged. No target was executed. Scope: one ARM64 Mach-O, Ghidra 12.1.4, macOS arm64 and REA d54a4661da20382ad8456564a08569fdd24131c5; other mappings and causes remain open as described above.

A separate unexecuted ARM64 Mach-O with a 16-byte __bss supplies an uninitialized control. At the BSS address, read_bytes returned zero bytes and complete: false; search_bytes returned no matches, explicitly listed all 16 bytes as skipped_uninitialized, and set complete: true for the initialized search it performed. address_to_file_offset refused the BSS address with an explicit uninitialized-memory reason; code bytes and their file offset were available as a positive control. The fixture SHA-256 156085b7dd9ca5e7335011e663a64665a174aafbed0d61eb1c3afc889aad308a was unchanged. Thus the comparison design must carry skipped-range coverage rather than treating the empty match list as an observation of zero bytes.

@morluto commented on GitHub (Oct 31, 2026): Additional real MCP search and handoff check on the same owned fixture and byte-edited selected project: - Within the bounded range `0x1000002d8..0x1000002df`, `search_bytes` for `40 05 80 52 c0 03 5f d6` found the address in the selected project and reported file offset 728; the original-byte pattern returned no match in that range. `read_bytes` returned the edited pattern. - A fresh Ghidra import of the same target did the opposite: it found `00 00 80 52 c0 03 5f d6`, did not find the edited pattern in that range, and reported the same address and offset. Direct reading of the original file at offset 728 gave the original pattern. - The selected-project and fresh observations carried distinct profile digests. Each search, byte-read and offset Evidence record survived export, close, and import in a fresh MCP server exactly, with full advertised output-schema validation. This is expected analyzed-memory behavior, not a search correctness bug. It illustrates why a hit's `file_offset` identifies a mapping and does not assert the original file has the matching bytes. This project was deliberately edited by a separate headless script before the test; REA's sessions left both the target and every selected-project regular-file digest unchanged. No target was executed. Scope: one ARM64 Mach-O, Ghidra 12.1.4, macOS arm64 and REA `d54a4661da20382ad8456564a08569fdd24131c5`; other mappings and causes remain open as described above. A separate unexecuted ARM64 Mach-O with a 16-byte `__bss` supplies an uninitialized control. At the BSS address, `read_bytes` returned zero bytes and `complete: false`; `search_bytes` returned no matches, explicitly listed all 16 bytes as `skipped_uninitialized`, and set `complete: true` for the initialized search it performed. `address_to_file_offset` refused the BSS address with an explicit uninitialized-memory reason; code bytes and their file offset were available as a positive control. The fixture SHA-256 `156085b7dd9ca5e7335011e663a64665a174aafbed0d61eb1c3afc889aad308a` was unchanged. Thus the comparison design must carry skipped-range coverage rather than treating the empty match list as an observation of zero bytes.

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

No description provided.

Rows
Columns