morluto/rea

Fork 0

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

[GH-ISSUE #8225] [Bug] Existing MIPS Ghidra projects fail with a misleading profile mismatch #6499

New issue

Closed

opened 2026-11-01 21:11:41 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched open and closed issues and pull requests for a related report. #3751 is the broader existing-project discussion; #8217 concerns a changed project, not this unchanged-project profile mismatch.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Ghidra existing-project selection and MIPS target/profile validation.

Observed behavior

Two real selected-project sessions for ordinary header-selected MIPS32r2 ELF fixtures accepted open_binary but their first provider query failed with a generic execution_failure. Nested diagnostics said the committed MIPS lane was resolved for a different target and advised reopening. Explicitly reopening the same target/project and repeating the query produced the same error.

Reproduction

Build the repository's tests/conformance/ghidra/mips-fixture.mjs fixtures for little- and big-endian MIPS32r2/o32. For each, use Ghidra 12.1.4 headless to import the same ELF into a new owned project, then select the .gpr and exact root program with REA_GHIDRA_PROJECT_PATH and REA_GHIDRA_PROGRAM_NAME.

In real stdio MCP, open_binary with provider_id: ghidra succeeded for each. list_procedures({detail:"summary"}) failed with the nested reason above; the same explicit reopen and retry failed again. The CLI rea search <big-endian-target> . --kind procedures --mode regex --provider ghidra --json failed with the same reason. A provider-scoped doctor with no target reported healthy: true; that check does not establish project/target applicability.

Independent read-only Ghidra headless processing of each selected program reported its recorded executable SHA-256 matching the selected file, and the expected MIPS:BE:32:default or MIPS:LE:32:default language. Separate real REA/Ghidra fresh-import sessions on the same files successfully listed three procedures each. The existing project in this test also contained a manually authored structure, but the failing list_procedures request does not depend on that type. Both target digests and the ten source-project regular-file digests per project stayed unchanged through REA; targets were not executed.

Expected behavior

Clarify and enforce the existing-project admission contract. The installation guide supports native ELF projects on POSIX without provider-pinned import preparation and requires fresh import for special pinned-language profiles. The fresh-import Evidence for these fixtures used language_id: auto-from-header and the ordinary elf32-exec-o32-arch32r2-standard-v3 lane. If this selected-project combination is supported, preserve target/profile checks and permit the matching project; if it is intentionally unsupported, return a typed, actionable selected-project limitation instead of a different-target diagnosis and a retry that does not help. Do not silently drop the project selection or its annotations.

Impact and scope

The saved program is usable directly in Ghidra but cannot be queried through REA with its current selected-project binding. This is two owned fixtures on macOS arm64, not proof that all MIPS projects or other pinned lanes behave alike. A matching executable digest does not prove the project was unedited or that its analysis is complete.

REA version

53a4ab78451a0654e9c3beb3d43a5e371a288fcc; Ghidra 12.1.4, JDK 21, Node 24.22.1.

Runtime and platform

macOS arm64; target ELF32 MIPS32r2/o32 little and big endian.

Interface

Real CLI and stdio MCP; direct Ghidra headless read-only control.

Earliest failure stage

Provider construction before the selected project is opened by REA's bridge.

Relevant output or evidence

Selected project first query and identical reopen retry: execution_failure, nested The committed MIPS analysis lane was resolved for a different target; reopen the target to resolve a new profile.
Fresh import of each same ELF: list_procedures summary with three observed rows.
Direct Ghidra saved-project control: matching recorded source SHA-256 and matching endian language.

Typed outcome or recovery expected

Preserve the project path/name, content fingerprint, target digest, program identity and unknown original analysis settings/completeness. Keep MIPS profile identity validation fail-closed; test matching and mismatched projects, both endiannesses, CLI/MCP errors and repeat-open recovery. Pinned, soft-float, PSP, raw and Windows lanes need separate applicable checks and must not be inferred supported from this report.

Analysis or suspected cause

Source inspection suggests the mismatch check expects target-derived mips_support_lane metadata, while existingGhidraAnalysisProfile omits that fresh-import lane. This is a source-derived hypothesis consistent with the reproduced error, not a proposed bypass of the check or a complete fix.

Draft fix and real-provider check

Draft #8605 binds the selected target's MIPS ELF metadata in the saved-project profile without claiming a fresh import lane. Both original projects worked in full and compact stdio MCP; the original projects and targets were unchanged. A mismatched target/project was still refused by the imported-byte digest check. The full real MIPS verifier passed six fixture variants, including newly source-built saved projects for both endiannesses and verified cleanup on macOS arm64. This does not widen pinned or other previously unsupported project modes.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8225 ### Before submitting - [x] I searched open and closed issues and pull requests for a related report. #3751 is the broader existing-project discussion; #8217 concerns a changed project, not this unchanged-project profile mismatch. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Ghidra existing-project selection and MIPS target/profile validation. ### Observed behavior Two real selected-project sessions for ordinary header-selected MIPS32r2 ELF fixtures accepted `open_binary` but their first provider query failed with a generic `execution_failure`. Nested diagnostics said the committed MIPS lane was resolved for a different target and advised reopening. Explicitly reopening the same target/project and repeating the query produced the same error. ### Reproduction Build the repository's `tests/conformance/ghidra/mips-fixture.mjs` fixtures for little- and big-endian MIPS32r2/o32. For each, use Ghidra 12.1.4 headless to import the same ELF into a new owned project, then select the `.gpr` and exact root program with `REA_GHIDRA_PROJECT_PATH` and `REA_GHIDRA_PROGRAM_NAME`. In real stdio MCP, `open_binary` with `provider_id: ghidra` succeeded for each. `list_procedures({detail:"summary"})` failed with the nested reason above; the same explicit reopen and retry failed again. The CLI `rea search <big-endian-target> . --kind procedures --mode regex --provider ghidra --json` failed with the same reason. A provider-scoped doctor with no target reported `healthy: true`; that check does not establish project/target applicability. Independent read-only Ghidra headless processing of each selected program reported its recorded executable SHA-256 matching the selected file, and the expected `MIPS:BE:32:default` or `MIPS:LE:32:default` language. Separate real REA/Ghidra fresh-import sessions on the same files successfully listed three procedures each. The existing project in this test also contained a manually authored structure, but the failing `list_procedures` request does not depend on that type. Both target digests and the ten source-project regular-file digests per project stayed unchanged through REA; targets were not executed. ### Expected behavior Clarify and enforce the existing-project admission contract. The installation guide supports native ELF projects on POSIX without provider-pinned import preparation and requires fresh import for special pinned-language profiles. The fresh-import Evidence for these fixtures used `language_id: auto-from-header` and the ordinary `elf32-exec-o32-arch32r2-standard-v3` lane. If this selected-project combination is supported, preserve target/profile checks and permit the matching project; if it is intentionally unsupported, return a typed, actionable selected-project limitation instead of a different-target diagnosis and a retry that does not help. Do not silently drop the project selection or its annotations. ### Impact and scope The saved program is usable directly in Ghidra but cannot be queried through REA with its current selected-project binding. This is two owned fixtures on macOS arm64, not proof that all MIPS projects or other pinned lanes behave alike. A matching executable digest does not prove the project was unedited or that its analysis is complete. ### REA version `53a4ab78451a0654e9c3beb3d43a5e371a288fcc`; Ghidra 12.1.4, JDK 21, Node 24.22.1. ### Runtime and platform macOS arm64; target ELF32 MIPS32r2/o32 little and big endian. ### Interface Real CLI and stdio MCP; direct Ghidra headless read-only control. ### Earliest failure stage Provider construction before the selected project is opened by REA's bridge. ### Relevant output or evidence - Selected project first query and identical reopen retry: `execution_failure`, nested `The committed MIPS analysis lane was resolved for a different target; reopen the target to resolve a new profile.` - Fresh import of each same ELF: `list_procedures` summary with three observed rows. - Direct Ghidra saved-project control: matching recorded source SHA-256 and matching endian language. ### Typed outcome or recovery expected Preserve the project path/name, content fingerprint, target digest, program identity and unknown original analysis settings/completeness. Keep MIPS profile identity validation fail-closed; test matching and mismatched projects, both endiannesses, CLI/MCP errors and repeat-open recovery. Pinned, soft-float, PSP, raw and Windows lanes need separate applicable checks and must not be inferred supported from this report. ### Analysis or suspected cause Source inspection suggests the mismatch check expects target-derived `mips_support_lane` metadata, while `existingGhidraAnalysisProfile` omits that fresh-import lane. This is a source-derived hypothesis consistent with the reproduced error, not a proposed bypass of the check or a complete fix. ### Draft fix and real-provider check Draft #8605 binds the selected target's MIPS ELF metadata in the saved-project profile without claiming a fresh import lane. Both original projects worked in full and compact stdio MCP; the original projects and targets were unchanged. A mismatched target/project was still refused by the imported-byte digest check. The full real MIPS verifier passed six fixture variants, including newly source-built saved projects for both endiannesses and verified cleanup on macOS arm64. This does not widen pinned or other previously unsupported project modes. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi commented

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

Author

Owner

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

A follow-up narrows the producing boundary without changing REA. I parsed each real MIPS ELF with REA's target resolver and called the existing profile constructor and MIPS mismatch function directly. For both targets, existingGhidraAnalysisProfile omitted mips_support_lane, while ghidraMipsProfileParameters for the same parsed target supplied elf32-exec-o32-arch32r2-standard-v3; the mismatch function rejected the existing-profile parameters. In this isolated function check, matching target-derived MIPS parameters passed, while the other endian's parameters or a changed ELF flags value were still rejected. This explains the previously observed failure more specifically, but is not a complete integration fix: fresh-import lane labels must not be used to imply that a selected project's analysis settings or completeness are known, and project/target identity checks remain necessary.

A separate pinned-language control helps preserve the documented admission boundary. I imported the owned RV32 ELF into a disposable headless Ghidra project; Ghidra's automatic language selection reported RISCV:LE:32:AndeStar_v5, with the matching recorded source SHA-256. Real REA MCP with that project selected refused open_binary with typed configuration_invalid and an existing-project/pinned-language explanation. A separate fresh REA/Ghidra import of the same target succeeded and disclosed its pinned generic RISC-V language. This is one control, not a request to silently admit or reinterpret pinned projects. The target digest was unchanged and no target was executed.

@morluto commented on GitHub (Oct 30, 2026): A follow-up narrows the producing boundary without changing REA. I parsed each real MIPS ELF with REA's target resolver and called the existing profile constructor and MIPS mismatch function directly. For both targets, `existingGhidraAnalysisProfile` omitted `mips_support_lane`, while `ghidraMipsProfileParameters` for the same parsed target supplied `elf32-exec-o32-arch32r2-standard-v3`; the mismatch function rejected the existing-profile parameters. In this isolated function check, matching target-derived MIPS parameters passed, while the other endian's parameters or a changed ELF flags value were still rejected. This explains the previously observed failure more specifically, but is not a complete integration fix: fresh-import lane labels must not be used to imply that a selected project's analysis settings or completeness are known, and project/target identity checks remain necessary. A separate pinned-language control helps preserve the documented admission boundary. I imported the owned RV32 ELF into a disposable headless Ghidra project; Ghidra's automatic language selection reported `RISCV:LE:32:AndeStar_v5`, with the matching recorded source SHA-256. Real REA MCP with that project selected refused `open_binary` with typed `configuration_invalid` and an existing-project/pinned-language explanation. A separate fresh REA/Ghidra import of the same target succeeded and disclosed its pinned generic RISC-V language. This is one control, not a request to silently admit or reinterpret pinned projects. The target digest was unchanged and no target was 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):

Real-provider follow-up on main e6d061897, macOS arm64, Ghidra 12.1.4: both original MIPS32r2 existing-project cases still failed on the first query and identical reopen/retry, while fresh imports of the same little- and big-endian ELFs succeeded.

In a temporary diagnostic experiment, I added the current target-derived MIPS profile parameters to existingGhidraAnalysisProfile, rebuilt, and reran real MCP sessions. Both matching existing projects then listed procedures and returned their manually authored /audit/endian/Bits type. Swapping the target and project in both directions still failed before a usable session; Ghidra's captured bridge error reported imported-byte digest does not match the admitted target. The public error in those mismatch controls was generic execution_failure, consistent with #8169. Both target hashes and both source-project file trees were unchanged.

This experiment strengthens the missing-profile-facts diagnosis; it is not a proposed fix. In particular, copying a fresh-import lane description into an existing-project profile can imply unobserved import settings or analysis completeness, and the two swapped fixtures do not exhaust target identity or format/profile controls. Preserve unknown original analysis settings and independently validate project identity. The temporary edit was reverted and the runtime rebuilt; no production change was committed.

@morluto commented on GitHub (Oct 31, 2026): Real-provider follow-up on main `e6d061897`, macOS arm64, Ghidra 12.1.4: both original MIPS32r2 existing-project cases still failed on the first query and identical reopen/retry, while fresh imports of the same little- and big-endian ELFs succeeded. In a **temporary diagnostic experiment**, I added the current target-derived MIPS profile parameters to `existingGhidraAnalysisProfile`, rebuilt, and reran real MCP sessions. Both matching existing projects then listed procedures and returned their manually authored `/audit/endian/Bits` type. Swapping the target and project in both directions still failed before a usable session; Ghidra's captured bridge error reported `imported-byte digest does not match the admitted target`. The public error in those mismatch controls was generic `execution_failure`, consistent with #8169. Both target hashes and both source-project file trees were unchanged. This experiment strengthens the missing-profile-facts diagnosis; it is **not a proposed fix**. In particular, copying a fresh-import lane description into an existing-project profile can imply unobserved import settings or analysis completeness, and the two swapped fixtures do not exhaust target identity or format/profile controls. Preserve unknown original analysis settings and independently validate project identity. The temporary edit was reverted and the runtime rebuilt; no production change was committed.

bsakaguchi referenced this issue

2026-11-01 21:47:23 +00:00

[PR #6499] [MERGED] docs(readme): add Roman Urdu edition #7371

bsakaguchi referenced this issue

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

[PR #6530] [MERGED] feat(cli): report version and runtime with an explicit output format #7377

bsakaguchi closed this issue

2026-11-04 20:25:26 +00:00