morluto/rea

Fork 0

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

[GH-ISSUE #8819] [Bug] Ghidra packed-program selection omits import recovery #7762

New issue

Closed

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/8819

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 provider setup and recovery.

Observed behavior

Setting REA_GHIDRA_PROJECT_PATH to a Ghidra packed program (.gzf) returns a configuration error telling the caller to select an expanded .gpr and restore .grez archives. It does not explain that .gzf is a packed program with a different import path, or how to get a usable expanded project.

Reproduction

On REA 187f3d8cc, Ghidra 12.1.4/JDK 21 and macOS arm64, I created a .gzf from a source-owned, unexecuted Mach-O using a headless script and set the project setting to its absolute path. rea doctor --provider ghidra --target <target> --format json --full-output returned config_drift for REA_GHIDRA_PROJECT_PATH with Select an expanded .gpr project marker; restore .grez archives first. The request is correctly refused; the recovery text is incomplete for the selected file type.

Expected behavior

For a .gzf selection, say that it is a packed program and explain the explicit Ghidra import-to-new-project route, then select the resulting .gpr and exact program name. Keep .grez project-archive guidance distinct. Do not silently import, overwrite caller files, or claim that REA directly opens .gzf.

Impact and scope

An analyst with only a packed program has a valid manual recovery but cannot infer it from the error. One fixture, Ghidra version and host were checked; no agent-selection study or broader compatibility claim is made.

REA version

187f3d8cc (1.990 verification branch; the existing-project configuration code is unchanged from its main base).

Runtime and platform

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

Target and artifact context

Source-owned Mach-O and caller-created packed program; no executable was run or modified.

Interface

CLI doctor; the same configuration validation runs at MCP startup.

Earliest failure stage

Provider configuration admission.

Relevant output or evidence

A separate Ghidra headless invocation, analyzeHeadless <new-project-directory> recovered -import <program.gzf> -noanalysis, created recovered.gpr and a program named program (from this packed filename). Selecting those in REA allowed rea decompile to return the expected audit_value function. The target, packed file and all regular files of the expanded project had unchanged content hashes during REA's read-only use. The Ghidra import created the new project before that check; Ghidra may select a different program name for another input.

Analysis or suspected cause

ghidraProjectPathSchema applies one static non-.gpr diagnostic that mentions .grez only. .gzf is a packed program rather than a whole project archive. Related broader support discussions: #3751, #8165, and #8344. This report concerns error recovery, not adding a direct import capability.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8819 ### 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 provider setup and recovery. ### Observed behavior Setting `REA_GHIDRA_PROJECT_PATH` to a Ghidra packed program (`.gzf`) returns a configuration error telling the caller to select an expanded `.gpr` and restore `.grez` archives. It does not explain that `.gzf` is a packed program with a different import path, or how to get a usable expanded project. ### Reproduction On REA `187f3d8cc`, Ghidra 12.1.4/JDK 21 and macOS arm64, I created a `.gzf` from a source-owned, unexecuted Mach-O using a headless script and set the project setting to its absolute path. `rea doctor --provider ghidra --target <target> --format json --full-output` returned `config_drift` for `REA_GHIDRA_PROJECT_PATH` with `Select an expanded .gpr project marker; restore .grez archives first`. The request is correctly refused; the recovery text is incomplete for the selected file type. ### Expected behavior For a `.gzf` selection, say that it is a packed program and explain the explicit Ghidra import-to-new-project route, then select the resulting `.gpr` and exact program name. Keep `.grez` project-archive guidance distinct. Do not silently import, overwrite caller files, or claim that REA directly opens `.gzf`. ### Impact and scope An analyst with only a packed program has a valid manual recovery but cannot infer it from the error. One fixture, Ghidra version and host were checked; no agent-selection study or broader compatibility claim is made. ### REA version `187f3d8cc` (1.990 verification branch; the existing-project configuration code is unchanged from its main base). ### Runtime and platform macOS arm64, Node 24.22.1, Ghidra 12.1.4/JDK 21. ### Target and artifact context Source-owned Mach-O and caller-created packed program; no executable was run or modified. ### Interface CLI doctor; the same configuration validation runs at MCP startup. ### Earliest failure stage Provider configuration admission. ### Relevant output or evidence A separate Ghidra headless invocation, `analyzeHeadless <new-project-directory> recovered -import <program.gzf> -noanalysis`, created `recovered.gpr` and a program named `program` (from this packed filename). Selecting those in REA allowed `rea decompile` to return the expected `audit_value` function. The target, packed file and all regular files of the expanded project had unchanged content hashes during REA's read-only use. The Ghidra import created the new project before that check; Ghidra may select a different program name for another input. ### Analysis or suspected cause `ghidraProjectPathSchema` applies one static non-`.gpr` diagnostic that mentions `.grez` only. `.gzf` is a packed program rather than a whole project archive. Related broader support discussions: #3751, #8165, and #8344. This report concerns error recovery, not adding a direct import capability. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi closed this issue

2026-11-04 18:21:32 +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#7762

No description provided.

Rows
Columns