morluto/rea

Fork 0

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

[GH-ISSUE #1026] [Bug] Windows Ghidra snapshot lease blocks Java readers #378

New issue

Closed

opened 2026-10-15 18:24:26 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

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

Before submitting

Searched open and closed issues for related reports.
Removed credentials, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

On a real Windows x64 host, the Ghidra provider fails before the authenticated bridge starts. Ghidra cannot open REA’s private target snapshot and reports a file sharing violation. The failure reproduces with the supported native x86-64 PE fixture; it also blocks the independent x86 backend investigation for #806.

Reproduction

Configure an existing Ghidra 12.1.4 installation and JDK 21 on Windows x64.
Build REA and provide its matching Windows native artifact.
Run node scripts/create-ghidra-windows-fixture.mjs.
Run node scripts/verify-real-ghidra-windows.mjs.
Observe Ghidra’s import failure before bridge startup.

Expected behavior

Ghidra can read the admitted immutable snapshot. Competing writes, replacement, rename, and deletion remain denied during analysis; cancellation and owner cleanup remove owned files.

Impact and scope

The admitted Windows Ghidra P0 workflow is blocked even for x86-64 PE applications. This is separate from x86 admission restrictions in #806. The reduced test does not execute the target. Linux and macOS use a different snapshot implementation.

REA version

Source revision 984fc27c, using the matching 5.0.0 Windows native artifact. The native sources are unchanged since the published 5.0.0 artifact.

Runtime and platform

Windows x64; Node.js 22.19.0; Ghidra 12.1.4; JDK 21.0.12.

Target and artifact context

Controlled 1 KiB native x86-64 PE application fixture.

Interface

CLI / Ghidra provider verification

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

GhidraSessionError: Ghidra exited before bridge startup
HeadlessAnalyzer: FileNotFoundException: <private snapshot>
The process cannot access the file because it is being used by another process.

Analysis or suspected cause

Source-derived diagnosis: native snapshot creation requests DELETE | GENERIC_WRITE | GENERIC_READ, and retains that handle until owner cleanup. Ghidra’s Java reader does not share delete access. Windows checks sharing compatibility in both directions, so a retained DELETE-access handle blocks this reader even though REA shares read access.

The fix should reduce the snapshot handle’s requested authority, preserve the deny-write/delete lease, and preserve identity-bound cancellation cleanup. It should not release the lease before import or broaden sharing to permit mutation.

Microsoft CreateFileW sharing semantics

Additional context

Both x86-64 control and x86 backend probe failed with the same import error. The x86-64 control used approximately 305 MiB peak combined working set, a 512 MiB JVM heap cap, two CPUs, and a disk reserve. Add a real Windows reader regression to the native conformance lane and rerun real Ghidra before claiming provider recovery.

Originally created by @N0zoM1z0 on GitHub (Oct 7, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1026 ### Before submitting - [x] Searched open and closed issues for related reports. - [x] Removed credentials, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior On a real Windows x64 host, the Ghidra provider fails before the authenticated bridge starts. Ghidra cannot open REA’s private target snapshot and reports a file sharing violation. The failure reproduces with the supported native x86-64 PE fixture; it also blocks the independent x86 backend investigation for #806. ### Reproduction 1. Configure an existing Ghidra 12.1.4 installation and JDK 21 on Windows x64. 2. Build REA and provide its matching Windows native artifact. 3. Run `node scripts/create-ghidra-windows-fixture.mjs`. 4. Run `node scripts/verify-real-ghidra-windows.mjs`. 5. Observe Ghidra’s import failure before bridge startup. ### Expected behavior Ghidra can read the admitted immutable snapshot. Competing writes, replacement, rename, and deletion remain denied during analysis; cancellation and owner cleanup remove owned files. ### Impact and scope The admitted Windows Ghidra P0 workflow is blocked even for x86-64 PE applications. This is separate from x86 admission restrictions in #806. The reduced test does not execute the target. Linux and macOS use a different snapshot implementation. ### REA version Source revision `984fc27c`, using the matching 5.0.0 Windows native artifact. The native sources are unchanged since the published 5.0.0 artifact. ### Runtime and platform Windows x64; Node.js 22.19.0; Ghidra 12.1.4; JDK 21.0.12. ### Target and artifact context Controlled 1 KiB native x86-64 PE application fixture. ### Interface CLI / Ghidra provider verification ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence ```text GhidraSessionError: Ghidra exited before bridge startup HeadlessAnalyzer: FileNotFoundException: <private snapshot> The process cannot access the file because it is being used by another process. ``` ### Analysis or suspected cause Source-derived diagnosis: native snapshot creation requests `DELETE | GENERIC_WRITE | GENERIC_READ`, and retains that handle until owner cleanup. Ghidra’s Java reader does not share delete access. Windows checks sharing compatibility in both directions, so a retained DELETE-access handle blocks this reader even though REA shares read access. The fix should reduce the snapshot handle’s requested authority, preserve the deny-write/delete lease, and preserve identity-bound cancellation cleanup. It should not release the lease before import or broaden sharing to permit mutation. [Microsoft CreateFileW sharing semantics](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew) ### Additional context Both x86-64 control and x86 backend probe failed with the same import error. The x86-64 control used approximately 305 MiB peak combined working set, a 512 MiB JVM heap cap, two CPUs, and a disk reserve. Add a real Windows reader regression to the native conformance lane and rerun real Ghidra before claiming provider recovery.

bsakaguchi

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

closed this issue
added the
triage

bug
labels

bsakaguchi referenced this issue

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

[PR #433] [MERGED] feat: add runtime reconstruction roadmap workflows #1982

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

No description provided.

Rows
Columns