[GH-ISSUE #5657] [Design] Classic console ROM targets on Windows (raw image with an installed Ghidra language, or a named Ghidra loader) #3426

New issue

Open

opened 2026-10-31 00:40:20 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:40:20 +00:00

Owner

Originally created by @mlg583 on GitHub (Oct 20, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5657

Before submitting

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

Decision needed

Should open_binary accept classic console ROM images on Windows? Two ways it could work:

(a) Let a raw image name a Ghidra language that is installed, taken from the catalog REA already reads, including Ghidra/Extensions, plus a load base separate from the entry point.
(b) Delegate to a named Ghidra loader that is installed (for example GhidraNes, ghidra-sm83, N64LoaderWV) and let it build the memory map.

Context and evidence

Environment: REA 6.7.0, Windows 11, Ghidra 12.1.4. Ghidra has console loader extensions installed in Ghidra/Extensions.

Observed

open_binary on a Game Boy ROM (.gb) returns file_format_rejected / "unsupported binary format".
If the ROM is wrapped in a minimal ELF32 with REA_GHIDRA_LANGUAGE_ID=SM83:LE:16:default, the gate admits it. The provider then rejects it with target_format_unsupported: "Windows Ghidra P0 accepts native PE and explicitly selected raw 6502 targets only."
Raw 6502 works. An NES ROM converted to a raw image opens and decompiles. Because file offset 0 is mapped at the entry point, the image has to start with a synthetic JSR nmi / JSR irq / JMP reset stub so the code lands at $8000 and all three vector handlers are analyzed.
The same ROMs import cleanly through Ghidra itself (headless) with the extension loaders. Examples: SM83 (Game Boy), 65816 (SNES), MIPS (N64), ARMv4T/ARMv5T (GBA/DS), PowerPC Gekko/Broadway (GameCube). Each gets a proper memory map, and functions decompile.

Source-derived (6.7.0 dist/)

inspectWindowsP0TargetSupport (ghidra/GhidraProvider.js) admits only native PE files and raw 6502 images on Windows.
ghidraRawBinaryLanguage maps raw architectures to six fixed languages, and raw-binary profiles refuse REA_GHIDRA_LANGUAGE_ID.
readGhidraLanguageCatalog already includes Ghidra/Extensions languages, so an extension language could be validated against the installation.

Unknown: what verification the P0 lane would need before admitting more architectures. That's the main question for maintainers.

Expected interaction with targets

Read existing files or captured data.

Boundary details

The workflow is static and read-only, the same as the existing raw 6502 lane: an ephemeral import with no execution, and the original bytes are never written. Non-goals: emulation, copy-protection or anti-piracy checks, and any change to the ROM files.

Options and tradeoffs

(a) Raw image + any installed language + separate load base. A small contract change: architecture would accept a language ID from the catalog, and a new optional load_address would be added. The caller supplies the memory map knowledge. There would be no I/O labels or banking, as with 6502 today.
(b) Named Ghidra loader. Better results, because the loader builds bank overlays and hardware labels. But REA would be trusting third-party loader code in its import path, and that code varies in quality: two of the loaders tested blocked headless imports with modal dialogs (fixes are open as pedro-javierf/NTRGhidra#37 and Cuyler36/Ghidra-GameCube-Loader#109).
(c) Leave Windows as is and document WSL/Linux. The Linux lanes admit ELF MIPS/PowerPC/ARM, but not SM83 or 65816.

Verification available so far

Manual checks on one retail ROM per console, through Ghidra headless with the extension loaders. Through REA: the NES raw-6502 path only.

🤖 Generated with Claude Code

Originally created by @mlg583 on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5657 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Should `open_binary` accept classic console ROM images on Windows? Two ways it could work: - **(a)** Let a raw image name a Ghidra language that is installed, taken from the catalog REA already reads, including `Ghidra/Extensions`, plus a load base separate from the entry point. - **(b)** Delegate to a named Ghidra loader that is installed (for example GhidraNes, ghidra-sm83, N64LoaderWV) and let it build the memory map. ### Context and evidence Environment: REA 6.7.0, Windows 11, Ghidra 12.1.4. Ghidra has console loader extensions installed in `Ghidra/Extensions`. **Observed** - `open_binary` on a Game Boy ROM (`.gb`) returns `file_format_rejected` / "unsupported binary format". - If the ROM is wrapped in a minimal ELF32 with `REA_GHIDRA_LANGUAGE_ID=SM83:LE:16:default`, the gate admits it. The provider then rejects it with `target_format_unsupported`: "Windows Ghidra P0 accepts native PE and explicitly selected raw 6502 targets only." - Raw 6502 works. An NES ROM converted to a raw image opens and decompiles. Because file offset 0 is mapped at the entry point, the image has to start with a synthetic `JSR nmi / JSR irq / JMP reset` stub so the code lands at `$8000` and all three vector handlers are analyzed. - The same ROMs import cleanly through Ghidra itself (headless) with the extension loaders. Examples: SM83 (Game Boy), 65816 (SNES), MIPS (N64), ARMv4T/ARMv5T (GBA/DS), PowerPC Gekko/Broadway (GameCube). Each gets a proper memory map, and functions decompile. **Source-derived** (6.7.0 `dist/`) - `inspectWindowsP0TargetSupport` (`ghidra/GhidraProvider.js`) admits only native PE files and raw 6502 images on Windows. - `ghidraRawBinaryLanguage` maps raw architectures to six fixed languages, and raw-binary profiles refuse `REA_GHIDRA_LANGUAGE_ID`. - `readGhidraLanguageCatalog` already includes `Ghidra/Extensions` languages, so an extension language could be validated against the installation. **Unknown:** what verification the P0 lane would need before admitting more architectures. That's the main question for maintainers. ### Expected interaction with targets Read existing files or captured data. ### Boundary details The workflow is static and read-only, the same as the existing raw 6502 lane: an ephemeral import with no execution, and the original bytes are never written. Non-goals: emulation, copy-protection or anti-piracy checks, and any change to the ROM files. ### Options and tradeoffs - **(a) Raw image + any installed language + separate load base.** A small contract change: `architecture` would accept a language ID from the catalog, and a new optional `load_address` would be added. The caller supplies the memory map knowledge. There would be no I/O labels or banking, as with 6502 today. - **(b) Named Ghidra loader.** Better results, because the loader builds bank overlays and hardware labels. But REA would be trusting third-party loader code in its import path, and that code varies in quality: two of the loaders tested blocked headless imports with modal dialogs (fixes are open as pedro-javierf/NTRGhidra#37 and Cuyler36/Ghidra-GameCube-Loader#109). - **(c) Leave Windows as is and document WSL/Linux.** The Linux lanes admit ELF MIPS/PowerPC/ARM, but not SM83 or 65816. ### Verification available so far Manual checks on one retail ROM per console, through Ghidra headless with the extension loaders. Through REA: the NES raw-6502 path only. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

bsakaguchi commented

2026-10-31 00:40:21 +00:00

Author

Owner

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

Cross-referencing with canonical issue #1741 ([Feature] Add PowerPC (32-bit big-endian) native analysis through Ghidra, with a GameCube/Wii DOL follow-up) and siblings #2072 (NES iNES container routing) and #4794 (SNES raw ROM 65C816 support). All address classic console ROM loading, language identification, and Ghidra loader integration. Cataloged under Cluster BY in consolidation tracker #4330.

@matbrgz commented on GitHub (Oct 20, 2026): Cross-referencing with canonical issue #1741 (`[Feature] Add PowerPC (32-bit big-endian) native analysis through Ghidra, with a GameCube/Wii DOL follow-up`) and siblings #2072 (NES iNES container routing) and #4794 (SNES raw ROM 65C816 support). All address classic console ROM loading, language identification, and Ghidra loader integration. Cataloged under Cluster BY in consolidation tracker #4330.

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:15 +00:00

[PR #4054] [CLOSED] fix(plist): preserve CDATA real values (#4042) #6024