morluto/rea

Fork 0

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

[GH-ISSUE #1330] [Feature] Add PSP/Allegrex native analysis through Ghidra #468

New issue

Closed

opened 2026-10-15 18:25:18 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:25:18 +00:00

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, private paths, and sensitive target data.

Area

Native analysis or decompilation

Current limitation

REA's provider-neutral executable architecture type currently admits x86, x86_64, ARM, and ARM64, so a PSP ELF cannot reach REA's Ghidra analysis workflow. The existing #718 roadmap already calls out generic MIPS ELF support across header parsing, domain/contracts, target admission, provider profile, and real Ghidra verification. Generic MIPS ELF admission is intentionally out of scope for this issue and should be reused from #718 rather than reimplemented here. This request is for the additional PSP/Allegrex path on top of that generic work: selecting the PSP loader and Allegrex language semantics supplied by Ghidra's existing extension.

Use cases

For static investigation of a legally obtained PSP executable, I would like to use REA's normal native workflow to obtain functions, instructions, pseudocode, references, and Evidence through Ghidra with ghidra-allegrex. Today that requires a separate specialist interface and duplicates session and evidence handling.

The desired path is PSP ELF → REA → Ghidra → ghidra-allegrex. Relocatable PRX support is not required for this first milestone; it can follow where it needs additional target-admission, loader, or relocation verification. This is static analysis; PSP emulation and runtime debugging remain with dedicated tools.

Desired outcome and success criteria

A focused first milestone could:

Admit a supported PSP ELF target while preserving its MIPS/Allegrex identity through target classification and Evidence.
Select the PSP ELF loader and Allegrex language/profile when a compatible ghidra-allegrex installation is already available.
Expose REA's ordinary read-only native operations supported by that provider, with provider/version and known limitations recorded in Evidence.
Fail with an actionable error when the extension or a compatible Ghidra version is unavailable.
Verify import, language selection, function analysis, and decompilation with a small source-owned PSPSDK fixture; no commercial game fixture is needed.

The extension's latest release is v21.4, whose changelog says it targets Ghidra 12.1.3. The extension documents builds against a selected GHIDRA_INSTALL_DIR, but compatibility with Ghidra 12.1.4 has not been verified here. Please make the supported Ghidra/extension pair explicit and test it rather than assuming patch-version compatibility.

Authority boundaries and non-goals

This request does not include PSP emulation, PPSSPP integration, ISO/CSO handling, game-specific logic, automatic extension installation, or a claim of complete VFPU decompilation. The extension documents VFPU limitations; REA should preserve those limitations in its results. Targets remain caller-supplied, and analysis should remain read-only. The requested outcome does not require vendoring ghidra-allegrex. Using a caller-supplied compatible extension would preserve upstream ownership and reduce duplicated maintenance, but the maintainers should choose the packaging and integration approach that best fits REA. Automatic extension installation is outside the initial milestone.

Alternatives considered

A separate Ghidra MCP adapter with ghidra-allegrex works for PSP analysis, but duplicates general session, operation, and Evidence workflows REA already provides for admitted native targets. Reusing the extension would keep Allegrex/PSP processor semantics in their existing upstream project while REA owns its agent-facing workflow.

Possible direction

Build on #718's generic MIPS ELF work, then add PSP-specific loader/language selection and real-provider verification. Keep the extension bring-your-own and version-compatible. A generated PSPSDK fixture could cover the boundary without distributing commercial data.

References

Originally created by @jaelliot on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1330 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Current limitation REA's provider-neutral executable architecture type currently admits x86, x86_64, ARM, and ARM64, so a PSP ELF cannot reach REA's Ghidra analysis workflow. The existing [#718 roadmap](https://github.com/morluto/rea/issues/718) already calls out generic MIPS ELF support across header parsing, domain/contracts, target admission, provider profile, and real Ghidra verification. Generic MIPS ELF admission is intentionally out of scope for this issue and should be reused from #718 rather than reimplemented here. This request is for the additional PSP/Allegrex path on top of that generic work: selecting the PSP loader and Allegrex language semantics supplied by Ghidra's existing extension. ### Use cases For static investigation of a legally obtained PSP executable, I would like to use REA's normal native workflow to obtain functions, instructions, pseudocode, references, and Evidence through Ghidra with [ghidra-allegrex](https://github.com/kotcrab/ghidra-allegrex). Today that requires a separate specialist interface and duplicates session and evidence handling. The desired path is PSP ELF → REA → Ghidra → ghidra-allegrex. Relocatable PRX support is not required for this first milestone; it can follow where it needs additional target-admission, loader, or relocation verification. This is static analysis; PSP emulation and runtime debugging remain with dedicated tools. ### Desired outcome and success criteria A focused first milestone could: - Admit a supported PSP ELF target while preserving its MIPS/Allegrex identity through target classification and Evidence. - Select the PSP ELF loader and Allegrex language/profile when a compatible ghidra-allegrex installation is already available. - Expose REA's ordinary read-only native operations supported by that provider, with provider/version and known limitations recorded in Evidence. - Fail with an actionable error when the extension or a compatible Ghidra version is unavailable. - Verify import, language selection, function analysis, and decompilation with a small source-owned PSPSDK fixture; no commercial game fixture is needed. The extension's latest release is v21.4, whose changelog says it targets Ghidra 12.1.3. The extension documents builds against a selected GHIDRA_INSTALL_DIR, but compatibility with Ghidra 12.1.4 has not been verified here. Please make the supported Ghidra/extension pair explicit and test it rather than assuming patch-version compatibility. ### Authority boundaries and non-goals This request does not include PSP emulation, PPSSPP integration, ISO/CSO handling, game-specific logic, automatic extension installation, or a claim of complete VFPU decompilation. The extension documents VFPU limitations; REA should preserve those limitations in its results. Targets remain caller-supplied, and analysis should remain read-only. The requested outcome does not require vendoring ghidra-allegrex. Using a caller-supplied compatible extension would preserve upstream ownership and reduce duplicated maintenance, but the maintainers should choose the packaging and integration approach that best fits REA. Automatic extension installation is outside the initial milestone. ### Alternatives considered A separate Ghidra MCP adapter with ghidra-allegrex works for PSP analysis, but duplicates general session, operation, and Evidence workflows REA already provides for admitted native targets. Reusing the extension would keep Allegrex/PSP processor semantics in their existing upstream project while REA owns its agent-facing workflow. ### Possible direction Build on #718's generic MIPS ELF work, then add PSP-specific loader/language selection and real-provider verification. Keep the extension bring-your-own and version-compatible. A generated PSPSDK fixture could cover the boundary without distributing commercial data. ### References - [REA #718: generic MIPS ELF follow-up](https://github.com/morluto/rea/issues/718) - [REA architecture type](https://github.com/morluto/rea/blob/main/src/domain/binaryTargetTypes.ts) - [REA Ghidra analysis profile](https://github.com/morluto/rea/blob/main/src/ghidra/GhidraAnalysisProfile.ts) - [ghidra-allegrex README](https://github.com/kotcrab/ghidra-allegrex) - [ghidra-allegrex v21.4 release](https://github.com/kotcrab/ghidra-allegrex/releases/tag/v21.4) - [ghidra-allegrex change log](https://github.com/kotcrab/ghidra-allegrex/blob/master/CHANGES.md)

bsakaguchi added the

labels

2026-10-15 18:25:18 +00:00

bsakaguchi commented

2026-10-15 18:25:19 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Architecture & Extension Scoping Review

Adding PSP (Allegrex / MIPS R4000 variant with VFPU) support builds directly upon the generic MIPS ELF work (#718 / PR #2362):

Processor Semantics: Ghidra's Allegrex language (Allegrex:LE:32:default) models the VFPU vector coprocessor instruction set and custom system call calling conventions.
Container Recognition:
- Standard PSP ELF executables (plain ELF with EM_MIPS and Allegrex flags).
- PRX relocatable modules (~PSP magic / encrypted PRX): Encrypted PRX requires offline decryption beforehand, while decrypted PRX can be parsed by Ghidra's PSP loader extension.
Phasing: Ensure base MIPS32 shared library admission (PR #2362) lands first, then introduce the Allegrex processor variant binding.

@matbrgz commented on GitHub (Oct 12, 2026): ### Architecture & Extension Scoping Review Adding PSP (Allegrex / MIPS R4000 variant with VFPU) support builds directly upon the generic MIPS ELF work (#718 / PR #2362): - **Processor Semantics:** Ghidra's Allegrex language (`Allegrex:LE:32:default`) models the VFPU vector coprocessor instruction set and custom system call calling conventions. - **Container Recognition:** - Standard PSP ELF executables (plain ELF with `EM_MIPS` and Allegrex flags). - PRX relocatable modules (`~PSP` magic / encrypted PRX): Encrypted PRX requires offline decryption beforehand, while decrypted PRX can be parsed by Ghidra's PSP loader extension. - **Phasing:** Ensure base MIPS32 shared library admission (PR #2362) lands first, then introduce the Allegrex processor variant binding.

bsakaguchi referenced this issue

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

[PR #468] [MERGED] refactor(mcp): make analysis states unrepresentable #2014

bsakaguchi

2026-10-31 00:29:10 +00:00

closed this issue
added
enhancement
and removed
enhancement
labels

bsakaguchi commented

2026-10-31 00:29:11 +00:00

Author

Owner

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

Thank you for the focused PSP proposal. The requested initial static-ELF lane landed in #1599: it uses a caller-installed Allegrex extension, selects the PSP loader and language, preserves profile/extension identity and limitations, and reports missing prerequisites. Its recorded real-Ghidra checkpoint exercised a source-owned PSP fixture through CLI/MCP; see the PR for the exact revision and verification limits. The current lane is explicitly bounded to Linux x64 and the documented declarations; PRX, other hosts and full VFPU semantics remain outside it. I am closing the first-milestone request as addressed. Please reopen if an acceptance point is still missing or open a focused follow-up for a broader target.

@morluto commented on GitHub (Oct 26, 2026): Thank you for the focused PSP proposal. The requested initial static-ELF lane landed in #1599: it uses a caller-installed Allegrex extension, selects the PSP loader and language, preserves profile/extension identity and limitations, and reports missing prerequisites. Its recorded real-Ghidra checkpoint exercised a source-owned PSP fixture through CLI/MCP; see the PR for the exact revision and verification limits. The current lane is explicitly bounded to Linux x64 and the documented declarations; PRX, other hosts and full VFPU semantics remain outside it. I am closing the first-milestone request as addressed. Please reopen if an acceptance point is still missing or open a focused follow-up for a broader target.

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

No description provided.

Rows
Columns