morluto/rea

Fork 0

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

[GH-ISSUE #7265] [Feature] Accept original Xbox XBE executables and route them to provider loaders #4314

New issue

Open

opened 2026-10-31 00:48:49 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:48:49 +00:00

Owner

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

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

open_binary rejects original Xbox .xbe executables with unsupported binary format (file_format_rejected), because parseExecutableHeader only recognizes ELF, MZ/PE, Mach-O and FAT Mach-O headers. An XBE starts with the XBEH magic instead.

Both deep providers can already load these files with community loaders: Ghidra 12.1.4 with XboxDev/ghidra-xbe, and IDA Pro 9.3 with emoose/idaxex. Because REA turns the file away before it reaches either provider, the loaders cannot be used through REA's CLI or MCP workflows.

Observed on Windows 10 x64 with REA 6.7.0 and again with 6.8.0 (2026-10-26), using an open-source GPL-3.0 XBE (Cxbx-Reloaded/xbox_kernel_test_suite release build): open_binary with provider_id: "ida" returned target_unavailable / unsupported binary format.

Use cases

Studying open-source and homebrew Xbox software built with nxdk, with the decompiler output checked against published source.
Preservation and emulator work (for example, Cxbx-Reloaded and xemu developers comparing kernel-call behavior).
Cross-checking the same XBE in Ghidra and IDA through one evidence workflow.

Desired outcome and success criteria

open_binary accepts a well-formed XBE and reports a distinct format (for example xbe) with architecture x86.
With a provider whose XBE loader is installed, analysis runs through the provider's own loader (ghidra-xbe or idaxex), and decompilation and string, import and reference queries work as they do for PE files.
When no XBE loader is installed for the selected provider, REA fails with a clear, specific error rather than falling back to raw-binary interpretation.
Malformed or truncated XBE headers are rejected with a precise reason.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Static, read-only analysis of local files only: no execution, injection or mutation. This covers loading original Xbox executables for disassembly and decompilation. It does not include any key handling, signature or encryption bypass, or protection recovery. Xbox 360 executables are covered separately by #3118 (XEX2 and big-endian PowerPC PE) and are out of scope here. This request is only the original Xbox's x86 XBE format, which #3118 does not cover.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

Sample: the release build of Cxbx-Reloaded/xbox_kernel_test_suite (GPL-3.0, built with nxdk), whose source is public. A check could confirm that the decompiled main() references the strings D:\name.txt, D:\kernel_tests.log, D:\config.txt and Kernel Test Suite, matching src/main.cpp, and that xboxkrnl imports such as AvGetSavedDataAddress resolve by name.

Alternatives considered

format: "raw-binary" with an architecture and entry point: this bypasses the provider loaders, so sections, kernel imports and symbol recovery are lost.
Running IDA's idalib MCP server directly, outside REA: it works for IDA, but loses REA's evidence and provenance model and the shared Ghidra workflow.

Possible direction

Add XBE header detection alongside the existing formats: the XBEH magic, the base address, and the entry point, which is stored XOR-encoded with known retail and debug keys. Then pass the file to each provider's automatic loader selection, and report the loader the provider actually chose in the evidence.

References

https://github.com/XboxDev/ghidra-xbe
https://github.com/emoose/idaxex
https://github.com/Cxbx-Reloaded/xbox_kernel_test_suite
XBE format documentation: https://xboxdevwiki.net/Xbe

Originally created by @aschaeffer9 on GitHub (Oct 26, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7265 ### 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 open_binary rejects original Xbox .xbe executables with unsupported binary format (file_format_rejected), because parseExecutableHeader only recognizes ELF, MZ/PE, Mach-O and FAT Mach-O headers. An XBE starts with the XBEH magic instead. Both deep providers can already load these files with community loaders: Ghidra 12.1.4 with XboxDev/ghidra-xbe, and IDA Pro 9.3 with emoose/idaxex. Because REA turns the file away before it reaches either provider, the loaders cannot be used through REA's CLI or MCP workflows. Observed on Windows 10 x64 with REA 6.7.0 and again with 6.8.0 (2026-10-26), using an open-source GPL-3.0 XBE (Cxbx-Reloaded/xbox_kernel_test_suite release build): open_binary with provider_id: "ida" returned target_unavailable / unsupported binary format. ### Use cases Studying open-source and homebrew Xbox software built with nxdk, with the decompiler output checked against published source. Preservation and emulator work (for example, Cxbx-Reloaded and xemu developers comparing kernel-call behavior). Cross-checking the same XBE in Ghidra and IDA through one evidence workflow. ### Desired outcome and success criteria open_binary accepts a well-formed XBE and reports a distinct format (for example xbe) with architecture x86. With a provider whose XBE loader is installed, analysis runs through the provider's own loader (ghidra-xbe or idaxex), and decompilation and string, import and reference queries work as they do for PE files. When no XBE loader is installed for the selected provider, REA fails with a clear, specific error rather than falling back to raw-binary interpretation. Malformed or truncated XBE headers are rejected with a precise reason. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Static, read-only analysis of local files only: no execution, injection or mutation. This covers loading original Xbox executables for disassembly and decompilation. It does not include any key handling, signature or encryption bypass, or protection recovery. Xbox 360 executables are covered separately by #3118 (XEX2 and big-endian PowerPC PE) and are out of scope here. This request is only the original Xbox's x86 XBE format, which #3118 does not cover. ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) Sample: the release build of Cxbx-Reloaded/xbox_kernel_test_suite (GPL-3.0, built with nxdk), whose source is public. A check could confirm that the decompiled main() references the strings D:\name.txt, D:\kernel_tests.log, D:\config.txt and Kernel Test Suite, matching src/main.cpp, and that xboxkrnl imports such as AvGetSavedDataAddress resolve by name. ### Alternatives considered format: "raw-binary" with an architecture and entry point: this bypasses the provider loaders, so sections, kernel imports and symbol recovery are lost. Running IDA's idalib MCP server directly, outside REA: it works for IDA, but loses REA's evidence and provenance model and the shared Ghidra workflow. ### Possible direction Add XBE header detection alongside the existing formats: the XBEH magic, the base address, and the entry point, which is stored XOR-encoded with known retail and debug keys. Then pass the file to each provider's automatic loader selection, and report the loader the provider actually chose in the evidence. ### References https://github.com/XboxDev/ghidra-xbe https://github.com/emoose/idaxex https://github.com/Cxbx-Reloaded/xbox_kernel_test_suite XBE format documentation: https://xboxdevwiki.net/Xbe

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:48:49 +00:00

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

No description provided.

Rows
Columns