morluto/rea

Fork 0

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

[GH-ISSUE #4943] [Enhancement] Add XEX support #3068

New issue

Open

opened 2026-10-31 00:35:51 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

Originally created by @Gargadon on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4943

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Provider or capability discovery

Observed behavior

Codex says REA refuses to send XEX to Ghidra, launching an error: "file_format_rejected". Also, Codex says Windows version admits PE x86/AMD64, and raw 6502, but no PowerPC.

So, Ghidra doesn't reach the XEX file to analyze it via XEXLoaderWV plugin.

Ghidra and XEXLoaderWV works well on Codex without REA, but it's still a little slow and token-hunger.

Reproduction

Install REA from npx
Download Ghidra and install XEXLoaderWV (12.1.3 for compatibility)
Configure
Set GHIDRA_INSTALL_DIR on config.toml
Tell Codex to use REA to decompile an XEX.

Expected behavior

REA sending XEX to Ghidra

Impact and scope

N/A

REA version

6.5.0

Runtime and platform

Windows 11 LTSC 26H2 (x64), Ghidra 12.1.3

Target and artifact context

No response

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Typed outcome or recovery expected

No response

Analysis or suspected cause

No response

Additional context

No response

Originally created by @Gargadon on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4943 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Provider or capability discovery ### Observed behavior Codex says REA refuses to send XEX to Ghidra, launching an error: "file_format_rejected". Also, Codex says Windows version admits PE x86/AMD64, and raw 6502, but no PowerPC. So, Ghidra doesn't reach the XEX file to analyze it via XEXLoaderWV plugin. Ghidra and XEXLoaderWV works well on Codex without REA, but it's still a little slow and token-hunger. ### Reproduction - Install REA from npx - Download Ghidra and install XEXLoaderWV (12.1.3 for compatibility) - Configure - Set GHIDRA_INSTALL_DIR on config.toml - Tell Codex to use REA to decompile an XEX. ### Expected behavior REA sending XEX to Ghidra ### Impact and scope N/A ### REA version 6.5.0 ### Runtime and platform Windows 11 LTSC 26H2 (x64), Ghidra 12.1.3 ### Target and artifact context _No response_ ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence <img width="1087" height="446" alt="Image" src="https://github.com/user-attachments/assets/ca3389af-09ea-4de4-a2df-c94e66a400f8" /> ### Typed outcome or recovery expected _No response_ ### Analysis or suspected cause _No response_ ### Additional context _No response_

bsakaguchi added the

triage

bug

labels

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

bsakaguchi commented

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

Author

Owner

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

This looks like a reasonable admission gap rather than a hard blocker — XEX is a real format Ghidra handles through XEXLoaderWV, and rejecting it at the file-format gate keeps users from using REA as the thin MCP wrapper for that workflow.

One concrete suggestion: XEX2 has a distinctive magic (bytes "XEX2" at the start of the header) and the conventional extension is .xex, so it can be admitted without much ambiguity — you could add it to the format allowlist keyed on that magic (plus .xex extension) and document it alongside the other supported formats. That would let the Ghidra-based XEXLoaderWV path work while keeping the rejection for genuinely unknown formats.

@XinwangTao commented on GitHub (Oct 18, 2026): This looks like a reasonable admission gap rather than a hard blocker — XEX is a real format Ghidra handles through XEXLoaderWV, and rejecting it at the file-format gate keeps users from using REA as the thin MCP wrapper for that workflow. One concrete suggestion: XEX2 has a distinctive magic (bytes "XEX2" at the start of the header) and the conventional extension is .xex, so it can be admitted without much ambiguity — you could add it to the format allowlist keyed on that magic (plus .xex extension) and document it alongside the other supported formats. That would let the Ghidra-based XEXLoaderWV path work while keeping the rejection for genuinely unknown formats.

bsakaguchi commented

2026-10-31 00:35:53 +00:00

Author

Owner

@Gargadon commented on GitHub (Oct 20, 2026):

Still pending in REA 6.7.0

@Gargadon commented on GitHub (Oct 20, 2026): Still pending in REA 6.7.0

bsakaguchi referenced this issue

2026-10-31 01:07:51 +00:00

[PR #3077] [CLOSED] fix(session): report adb, apktool, and jeb readiness #5596

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

No description provided.

Rows
Columns