[GH-ISSUE #3118] [Feature] Xbox 360 executables: accept PowerPC big-endian PE (machine 0x01F2) and detect XEX2 #1085

New issue

Open

opened 2026-10-15 18:30:57 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:30:57 +00:00

Owner

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

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

An XEX2 input matches no branch of parseExecutableHeader and fails
with "unsupported binary format" (src/domain/binaryTarget.ts).
A decrypted PPCBE PE basefile then fails decodePeMachine
(src/domain/peMachine.ts) with
"unsupported PE architecture (COFF machine 0x01f2)", and pe +
powerpc is not a representable BinaryTarget today.

Related: #1741 (32-bit big-endian PowerPC ELF through Ghidra), #3070, and #1868 (user-defined architecture for Ghidra).

Use cases

Static analysis of Xbox 360 games and homebrew the user legally owns, e.g. supporting static-recompilation ports such as https://github.com/santiquiroz/gow2-recomp (retail Gears of War 2 on PC), where finding missed function entry points and jump tables is the bottleneck.

Desired outcome and success criteria

This is a design-discussion issue asking for a scope decision before any
implementation, per CONTRIBUTING.md: add Xbox 360 support to REA without
any XEX decryption in REA.

Proposed scope:

Detect the XEX2 magic and return a clear message telling the user to
extract the PE basefile themselves (e.g. with XexTool -b).
Accept the resulting extracted PE whose COFF machine is 0x01F2
(IMAGE_FILE_MACHINE_POWERPCBE; headers little-endian, code
big-endian). Target CPU is Xenon: PowerPC 64-bit with 32-bit
addressing + VMX128.

REA must not decrypt, decompress, or accept keys for XEX. Per
CONTRIBUTING.md, DRM / access-control bypass workflows are excluded,
even through plugins.

Verified Ghidra blocker

Ghidra 12.1.3 stock support is also missing:

PowerPC.opinion only lists PE primaries 496/497, little-endian.
After adding
<constraint primary="498" processor="PowerPC" endian="big" size="64" variant="A2ALT-32addr" />,
the import still fell back to Old-style DOS Executable (MZ) with
warnings like Section .rdata is not aligned!.

So Ghidra's PeLoader needs changes too: the 0x01F2 machine constant
plus section-alignment handling for Xbox 360 basefiles.

Proposed first PR

Small and self-contained, no Ghidra lane changes:

XEX2 magic detection with a user-action error message (extract the
basefile externally; no bypass in REA).
0x01F2 mapping in src/domain/peMachine.ts plus the minimal
pe + powerpc target plumbing.
Unit tests: synthetic XEX2 header, truncated header, 0x01F2 PE
mapping, rejection of other machines.

The full Ghidra analysis lane (pinned PowerPC:BE:64:A2ALT-32addr
language, loader selection, real-provider conformance) would be a
follow-up, blocked on upstream Ghidra PeLoader support.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Is (a) detect-XEX2-and-redirect plus (b) accept user-supplied 0x01F2
PE basefiles an acceptable direction? If yes, we will send the small
first PR above and keep the Ghidra lane separate.

Verification available so far

Tested locally: a user-extracted basefile (XexTool -b) has COFF machine 0x01F2 and is rejected by REA today; Ghidra 12.1.3's PE loader falls back to MZ for it even with an added opinion constraint. No samples are attached (retail game code).

Originally created by @santiquiroz on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3118 ### 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 - An `XEX2` input matches no branch of `parseExecutableHeader` and fails with `"unsupported binary format"` (`src/domain/binaryTarget.ts`). - A decrypted PPCBE PE basefile then fails `decodePeMachine` (`src/domain/peMachine.ts`) with `"unsupported PE architecture (COFF machine 0x01f2)"`, and `pe` + `powerpc` is not a representable `BinaryTarget` today. Related: #1741 (32-bit big-endian PowerPC ELF through Ghidra), #3070, and #1868 (user-defined architecture for Ghidra). ### Use cases Static analysis of Xbox 360 games and homebrew the user legally owns, e.g. supporting static-recompilation ports such as https://github.com/santiquiroz/gow2-recomp (retail Gears of War 2 on PC), where finding missed function entry points and jump tables is the bottleneck. ### Desired outcome and success criteria This is a design-discussion issue asking for a scope decision before any implementation, per `CONTRIBUTING.md`: add Xbox 360 support to REA without any XEX decryption in REA. Proposed scope: 1. Detect the `XEX2` magic and return a clear message telling the user to extract the PE basefile themselves (e.g. with XexTool `-b`). 2. Accept the resulting extracted PE whose COFF machine is `0x01F2` (`IMAGE_FILE_MACHINE_POWERPCBE`; headers little-endian, code big-endian). Target CPU is Xenon: PowerPC 64-bit with 32-bit addressing + VMX128. REA must not decrypt, decompress, or accept keys for XEX. Per `CONTRIBUTING.md`, DRM / access-control bypass workflows are excluded, even through plugins. **Verified Ghidra blocker** Ghidra `12.1.3` stock support is also missing: - `PowerPC.opinion` only lists PE primaries `496`/`497`, little-endian. - After adding `<constraint primary="498" processor="PowerPC" endian="big" size="64" variant="A2ALT-32addr" />`, the import still fell back to `Old-style DOS Executable (MZ)` with warnings like `Section .rdata is not aligned!`. So Ghidra's `PeLoader` needs changes too: the `0x01F2` machine constant plus section-alignment handling for Xbox 360 basefiles. **Proposed first PR** Small and self-contained, no Ghidra lane changes: - `XEX2` magic detection with a user-action error message (extract the basefile externally; no bypass in REA). - `0x01F2` mapping in `src/domain/peMachine.ts` plus the minimal `pe` + `powerpc` target plumbing. - Unit tests: synthetic `XEX2` header, truncated header, `0x01F2` PE mapping, rejection of other machines. The full Ghidra analysis lane (pinned `PowerPC:BE:64:A2ALT-32addr` language, loader selection, real-provider conformance) would be a follow-up, blocked on upstream Ghidra `PeLoader` support. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Is (a) detect-`XEX2`-and-redirect plus (b) accept user-supplied `0x01F2` PE basefiles an acceptable direction? If yes, we will send the small first PR above and keep the Ghidra lane separate. ### Verification available so far Tested locally: a user-extracted basefile (XexTool `-b`) has COFF machine 0x01F2 and is rejected by REA today; Ghidra 12.1.3's PE loader falls back to MZ for it even with an added opinion constraint. No samples are attached (retail game code).

bsakaguchi added the

enhancement

label

2026-10-15 18:30:57 +00:00

bsakaguchi referenced this issue

2026-10-17 21:08:26 +00:00

[PR #1085] [MERGED] fix(browser): advertise zero-based units for runtime source coordinates #2633

bsakaguchi referenced this issue

2026-10-17 21:08:33 +00:00

[PR #1096] [MERGED] fix(browser): keep initiator callsites out of script coordinate guidance #2643

bsakaguchi added

enhancement