morluto/rea

Fork 0

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

[GH-ISSUE #6746] [Feature] Ghidra profile for PS2 Emotion Engine (R5900) executables #4105

New issue

Open

opened 2026-10-31 00:46:51 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:46:51 +00:00

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

PS2 Emotion Engine (EE, MIPS R5900) executables are refused, and no issue tracks
them. Draft PRs #5240 and #6422 already propose a profile; this issue gives them a
place for the maintainer scope decision and adds observations from a second
environment.

Observed (REA 6.7.0, Linux x64): rea inspect <ee.elf> --provider ghidra on a
commercial NTSC-U PS2 boot executable returns architecture_unsupported
("Machine-specific MIPS variants, including PSP Allegrex, need a separately
supported processor profile.").

Target header (observed): ELF32 LE EM_MIPS ET_EXEC, e_flags=0x20924001
(EF_MIPS_ARCH_3 | E_MIPS_MACH_5900 | E_MIPS_ABI_EABI64 | EF_MIPS_NOREORDER),
no .MIPS.abiflags, Sony .DVP.overlay* sections (embedded VU microcode).

Source-derived: the header fails three checks in
ghidraMipsUnsupportedReason
(machine variant, ISA level, EABI64), and the only machine-specific dispatch,
isGhidraPspTarget, matches Allegrex only. It needs its own profile, not a relaxed
generic MIPS gate.

Use cases

Static analysis of PS2 executables (functions, xrefs, strings, pseudocode) through
REA's CLI/MCP workflows with Evidence provenance. Today this needs plain Ghidra
headless plus custom scripts, without REA sessions or Evidence.

Desired outcome and success criteria

A verified EE header shape resolves a dedicated Ghidra profile using the
caller-installed ghidra-emotionengine-reloaded
extension and serves the ordinary read-only operations.
Evidence records the pinned language/compiler and extension identity, plus EE
limitations (EABI64/128-bit GPR typing, VU overlays, RAM mirrors).
A missing or incompatible extension fails with an actionable error; generic MIPS,
PSP and IOP (R3000) headers keep their current behavior.

Expected interaction with targets

Read existing files or captured data, Write or change files/configuration, Not sure yet

Target and scope details (optional)

Write (observed upstream behavior): the extension zip ships SLEIGH sources but
no r5900.sla; Ghidra compiled data/languages/r5900.sla into the installation
on the first import. #6422 avoids this by requiring a precompiled .sla.
Non-goals: IOP .IRX modules (possible follow-up), disc images, VU microcode
analysis, emulation, automatic extension installation.

Verification available so far

I have a prototype or observed results

Verification details (optional)

Observed with plain Ghidra 12.1.4 headless, JDK 21, Linux x64, extension v2.1.38
(SHA-256 e389ff3e921d9f7d4db2ece9906f808545ce4ff519d9e25a019b72ea509f240b),
language r5900:LE:32:default, one executable, one cold run:

Import plus auto-analysis: ~50 s wall, ~0.99 GB max RSS, 5692 functions, 4235
strings; readable pseudocode with hardware register labels (REG_GS_CSR,
REG_DMAC_*) worth preserving.
Memory mirrors at 0x20xxxxxx/0x30xxxxxx duplicate strings and xrefs (also seen
for a standard MIPS import with the extension installed; attributing it to the
extension is an inference).
No functions for handlers registered only by pointer, and no references through
gcc 2.x vtables; coverage reporting should not imply completeness.
Other toolchains: NOT_ENOUGH_INFO from me. I cannot share the executable.

Alternatives considered

Plain Ghidra headless with the extension and custom scripts: works, but outside
REA's sessions and Evidence.

Possible direction

Follow the PSP precedent (#1330, docs/ghidra-psp.md): exact verified e_flags,
bring-your-own extension fingerprinted under $GHIDRA_INSTALL_DIR/Ghidra/Extensions/,
pinned language and compiler, Linux x64 first. Open questions: which header shapes
to admit (recordless EABI64 vs PS2SDK n32), how to handle the .sla compiled into
the installation, and how Evidence reports RAM-mirror duplicates.

References

Draft PRs #5240 and #6422; precedent #1330.

Originally created by @FFernandes4280 on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6746 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation PS2 Emotion Engine (EE, MIPS R5900) executables are refused, and no issue tracks them. Draft PRs #5240 and #6422 already propose a profile; this issue gives them a place for the maintainer scope decision and adds observations from a second environment. **Observed (REA 6.7.0, Linux x64):** `rea inspect <ee.elf> --provider ghidra` on a commercial NTSC-U PS2 boot executable returns `architecture_unsupported` ("Machine-specific MIPS variants, including PSP Allegrex, need a separately supported processor profile."). **Target header (observed):** ELF32 LE `EM_MIPS` `ET_EXEC`, `e_flags=0x20924001` (`EF_MIPS_ARCH_3` | `E_MIPS_MACH_5900` | `E_MIPS_ABI_EABI64` | `EF_MIPS_NOREORDER`), no `.MIPS.abiflags`, Sony `.DVP.overlay*` sections (embedded VU microcode). **Source-derived:** the header fails three checks in [`ghidraMipsUnsupportedReason`](https://github.com/morluto/rea/blob/01788bac863ac786bfbb648cad69b11e23b40a89/src/ghidra/GhidraMipsProfile.ts#L107-L163) (machine variant, ISA level, EABI64), and the only machine-specific dispatch, `isGhidraPspTarget`, matches Allegrex only. It needs its own profile, not a relaxed generic MIPS gate. ### Use cases Static analysis of PS2 executables (functions, xrefs, strings, pseudocode) through REA's CLI/MCP workflows with Evidence provenance. Today this needs plain Ghidra headless plus custom scripts, without REA sessions or Evidence. ### Desired outcome and success criteria - A verified EE header shape resolves a dedicated Ghidra profile using the caller-installed [ghidra-emotionengine-reloaded](https://github.com/chaoticgd/ghidra-emotionengine-reloaded) extension and serves the ordinary read-only operations. - Evidence records the pinned language/compiler and extension identity, plus EE limitations (EABI64/128-bit GPR typing, VU overlays, RAM mirrors). - A missing or incompatible extension fails with an actionable error; generic MIPS, PSP and IOP (R3000) headers keep their current behavior. ### Expected interaction with targets Read existing files or captured data, Write or change files/configuration, Not sure yet ### Target and scope details (optional) - **Write (observed upstream behavior):** the extension zip ships SLEIGH sources but no `r5900.sla`; Ghidra compiled `data/languages/r5900.sla` into the installation on the first import. #6422 avoids this by requiring a precompiled `.sla`. - **Non-goals:** IOP `.IRX` modules (possible follow-up), disc images, VU microcode analysis, emulation, automatic extension installation. ### Verification available so far I have a prototype or observed results ### Verification details (optional) Observed with plain Ghidra 12.1.4 headless, JDK 21, Linux x64, extension v2.1.38 (SHA-256 `e389ff3e921d9f7d4db2ece9906f808545ce4ff519d9e25a019b72ea509f240b`), language `r5900:LE:32:default`, one executable, one cold run: - Import plus auto-analysis: ~50 s wall, ~0.99 GB max RSS, 5692 functions, 4235 strings; readable pseudocode with hardware register labels (`REG_GS_CSR`, `REG_DMAC_*`) worth preserving. - Memory mirrors at `0x20xxxxxx`/`0x30xxxxxx` duplicate strings and xrefs (also seen for a standard MIPS import with the extension installed; attributing it to the extension is an inference). - No functions for handlers registered only by pointer, and no references through gcc 2.x vtables; coverage reporting should not imply completeness. - Other toolchains: NOT_ENOUGH_INFO from me. I cannot share the executable. ### Alternatives considered Plain Ghidra headless with the extension and custom scripts: works, but outside REA's sessions and Evidence. ### Possible direction Follow the PSP precedent (#1330, `docs/ghidra-psp.md`): exact verified `e_flags`, bring-your-own extension fingerprinted under `$GHIDRA_INSTALL_DIR/Ghidra/Extensions/`, pinned language and compiler, Linux x64 first. Open questions: which header shapes to admit (recordless EABI64 vs PS2SDK n32), how to handle the `.sla` compiled into the installation, and how Evidence reports RAM-mirror duplicates. ### References Draft PRs #5240 and #6422; precedent #1330.

bsakaguchi commented

2026-10-31 00:46:52 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 24, 2026):

This is a well-scoped request — the header-level reasoning (EF_MIPS_ARCH_3 | E_MIPS_MACH_5900 | EABI64 all failing separate checks, so a dedicated profile is required rather than relaxing the generic MIPS gate) is exactly the right diagnosis, and following the PSP precedent with bring-your-own fingerprinted extension keeps the mainline footprint small. On the two open questions: (1) I'd lean toward requiring a precompiled .sla like #6422 proposes — letting Ghidra compile SLEIGH sources into the installation on first import makes builds non-reproducible and hard to verify in CI; (2) for the RAM-mirror duplicates in Evidence, consider recording the source address range or marking mirrored regions, so coverage counts don't double-count the same functions/strings across 0x20/0x30 mirrors.

@XinwangTao commented on GitHub (Oct 24, 2026): This is a well-scoped request — the header-level reasoning (EF_MIPS_ARCH_3 | E_MIPS_MACH_5900 | EABI64 all failing separate checks, so a dedicated profile is required rather than relaxing the generic MIPS gate) is exactly the right diagnosis, and following the PSP precedent with bring-your-own fingerprinted extension keeps the mainline footprint small. On the two open questions: (1) I'd lean toward requiring a precompiled .sla like #6422 proposes — letting Ghidra compile SLEIGH sources into the installation on first import makes builds non-reproducible and hard to verify in CI; (2) for the RAM-mirror duplicates in Evidence, consider recording the source address range or marking mirrored regions, so coverage counts don't double-count the same functions/strings across 0x20/0x30 mirrors.

bsakaguchi referenced this issue

2026-10-31 01:09:03 +00:00

[PR #3426] [CLOSED] fix(plist): preserve complete XML character-data key names #5737

bsakaguchi referenced this issue

2026-10-31 01:11:12 +00:00

[PR #4047] [CLOSED] fix(plist): preserve real character data #6017

bsakaguchi referenced this issue

2026-10-31 01:11:34 +00:00

[PR #4105] [MERGED] fix(apple): report __proto__ entries omitted from OpenStep property lists #6061

bsakaguchi referenced this issue

2026-11-03 00:30:18 +00:00

[GH-ISSUE #8661] [Bug] OpenStep quoted escapes make existing app executables appear missing #7503