Repository navigation
[Feature] Add PSP/Allegrex native analysis through Ghidra #1330
Description
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.
Activity
fix(ghidra): bound MIPS floating-point mode admission
fix(native): validate MIPS ABI records before Ghidra admission
docs(ghidra): derive PSP acceptance boundaries from module research
feat(native): admit bounded MIPS ELF analysis through Ghidra (#1362)
matbrgz commentedon 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):
Allegrex:LE:32:default) models the VFPU vector coprocessor instruction set and custom system call calling conventions.EM_MIPSand Allegrex flags).~PSPmagic / encrypted PRX): Encrypted PRX requires offline decryption beforehand, while decrypted PRX can be parsed by Ghidra's PSP loader extension.morluto commentedon 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.