[GH-ISSUE #2410] [Feature] Accept SuperH (SH3/SH4) PE files for the Ghidra provider (Windows CE targets) #809

New issue

Open

opened 2026-10-15 18:28:39 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:28:39 +00:00

Owner

Originally created by @AdrianLzkno on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2410

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

I'm reverse engineering a Windows CE 5.0 car navigation unit (Renesas SH-4, SH7724) for an educational project. The main UI executable is a PE with Machine = 0x01A6 (IMAGE_FILE_MACHINE_SH4).

open_binary with provider_id: "ghidra" (rea-agents 6.4.0) refuses it before Ghidra ever sees the file:

{"error":{"code":"target_unavailable","message":"Cannot open artifact: unsupported PE architecture. ...","details":{"reason":"unsupported PE architecture"}}}

The refusal comes from peArchitecture() in dist/domain/binaryTarget.js, which only maps 0x14c, 0x8664, 0x1c0/0x1c2/0x1c4 and 0xaa64.

Ghidra itself handles this file fine. With the same Ghidra 12.1.4 install REA detects, analyzeHeadless ... -import picks Loader: Portable Executable (PE) and Language/Compiler: SuperH4:LE:32:default:windows automatically, and the import succeeds. Ghidra also logs Exception Data unsupported architecture: 0x1a6, which only means it doesn't parse SH4 .pdata.

Use cases

Windows CE / Windows Mobile firmware on Hitachi/Renesas SuperH: car navigation and head units, PDAs, industrial handhelds. Typical machine values are SH3 0x1A2, SH3DSP 0x1A3, SH3E 0x1A4 and SH4 0x1A6. SH5 0x1A8 is rarely seen.
The same applies to other Ghidra-supported PE machines REA rejects today, such as MIPS 0x166/0x169 and PowerPC 0x1F0/0x1F1, which were common on Windows CE.

Desired outcome and success criteria

open_binary accepts PE files with SuperH machine types when the selected provider (Ghidra) supports them. For example, it maps 0x1A6 to an sh4 architecture and lets Ghidra's auto-detected language stand, SuperH4:LE:32:default:windows.
Tools that depend on x86/ARM-specific logic report unavailable for that target, with a clear reason, instead of the whole file being refused.
If SH is out of scope, a refusal message that says "PE machine 0x1A6 (SH4) is not supported by REA; Ghidra supports it directly" would already help. Like #1979, the current "check the path" advice points to the wrong cause.

Expected interaction with targets

Static analysis only (no target execution).

Originally created by @AdrianLzkno on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2410 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the 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 I'm reverse engineering a Windows CE 5.0 car navigation unit (Renesas SH-4, SH7724) for an educational project. The main UI executable is a PE with `Machine = 0x01A6` (`IMAGE_FILE_MACHINE_SH4`). `open_binary` with `provider_id: "ghidra"` (rea-agents 6.4.0) refuses it before Ghidra ever sees the file: ```json {"error":{"code":"target_unavailable","message":"Cannot open artifact: unsupported PE architecture. ...","details":{"reason":"unsupported PE architecture"}}} ``` The refusal comes from `peArchitecture()` in `dist/domain/binaryTarget.js`, which only maps `0x14c`, `0x8664`, `0x1c0/0x1c2/0x1c4` and `0xaa64`. Ghidra itself handles this file fine. With the same Ghidra 12.1.4 install REA detects, `analyzeHeadless ... -import` picks `Loader: Portable Executable (PE)` and `Language/Compiler: SuperH4:LE:32:default:windows` automatically, and the import succeeds. Ghidra also logs `Exception Data unsupported architecture: 0x1a6`, which only means it doesn't parse SH4 `.pdata`. ### Use cases - Windows CE / Windows Mobile firmware on Hitachi/Renesas SuperH: car navigation and head units, PDAs, industrial handhelds. Typical machine values are SH3 `0x1A2`, SH3DSP `0x1A3`, SH3E `0x1A4` and SH4 `0x1A6`. SH5 `0x1A8` is rarely seen. - The same applies to other Ghidra-supported PE machines REA rejects today, such as MIPS `0x166`/`0x169` and PowerPC `0x1F0`/`0x1F1`, which were common on Windows CE. ### Desired outcome and success criteria - `open_binary` accepts PE files with SuperH machine types when the selected provider (Ghidra) supports them. For example, it maps `0x1A6` to an `sh4` architecture and lets Ghidra's auto-detected language stand, `SuperH4:LE:32:default:windows`. - Tools that depend on x86/ARM-specific logic report `unavailable` for that target, with a clear reason, instead of the whole file being refused. - If SH is out of scope, a refusal message that says "PE machine 0x1A6 (SH4) is not supported by REA; Ghidra supports it directly" would already help. Like #1979, the current "check the path" advice points to the wrong cause. ### Expected interaction with targets Static analysis only (no target execution).

bsakaguchi added the

area: native

enhancement

labels

2026-10-15 18:28:39 +00:00

bsakaguchi referenced this issue

2026-10-16 21:16:22 +00:00

[PR #809] [MERGED] fix: capture IndexedDB object-store record fingerprints #2256

bsakaguchi referenced this issue

2026-10-16 21:16:27 +00:00

[PR #815] [MERGED] fix: integrate 24 reviewed browser/native/semantics corrections #2262

bsakaguchi added