morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #3532] [Feature] Headerless SuperH-4 (SH-4) raw-binary lane for the Ghidra provider #1311

New issue

Open

opened 2026-10-16 21:04:05 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:04:05 +00:00

Owner

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

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

The raw-binary lane admits headerless images only for x86, x86_64, arm, arm64 and 6502 (src/ghidra/GhidraRawBinaryLanguage.ts, docs/raw-binary.md). A headerless little-endian SH-4 image, such as a Sega Dreamcast boot executable, which has no ELF/PE/Mach-O wrapper and is loaded at a fixed address like 0x8C010000, cannot be opened through REA. Ghidra handles it directly: analyzeHeadless with the raw BinaryLoader, SuperH4:LE:32:default and a base address imports and analyzes it.

Related but distinct: #2410 asks for SuperH PE files (Windows CE). That is the PE-container path; this request is the headerless raw-image path. The two do not overlap in code (peArchitecture() vs admitRawBinary/ghidraRawBinaryLanguage).

Use cases

Dreamcast homebrew and research builds, which are headerless SH-4 images.
Other embedded SH-4 firmware dumped as flat images.

Desired outcome and success criteria

--target-format raw-binary --architecture sh4 --entry-point 0x… --provider ghidra opens a headerless little-endian SH-4 image with the same verified load-image, instruction, reference and decompilation workflow the 6502 lane provides:

architecture: "sh4" is admitted with a 32-bit address width and a 2-byte-aligned entry point; odd entries are rejected.
ghidraRawBinaryLanguage("sh4") maps to SuperH4:LE:32:default, compiler spec default, address space ram.
A real-Ghidra proof (verify:ghidra:sh4) is structured like the 6502 lane's.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Little-endian SH-4 only. Big-endian (SuperH4:BE:32:default) stays out of scope for this increment. No platform-specific structure (Dreamcast IP.BIN, GD-ROM layout, memory maps) is interpreted. Windows P0 admission is unchanged.

Verification available so far

I have a prototype or observed results

Verification details (optional)

A prototype on a local branch follows the 6502 lane: a caller-visible family string, a ghidraRawBinaryLanguage case, a source-owned tests/conformance/ghidra/sh4.s fixture assembled with sh4-linux-gnu binutils 2.42, and scripts/verify-real-ghidra-sh4.mjs. Against Ghidra 12.1.4 on Linux, GHIDRA_INSTALL_DIR=<ghidra-12.1.4> npm run verify:ghidra:sh4 reports ok: true. Its checks cover CLI/MCP load-image parity, a bsr call reference, a bf conditional-branch target, decompilation, the entry return being preserved, odd-entry rejection, unchanged source bytes and runtime cleanup. The touched unit test files pass (159 tests). I'm happy to open a PR if the scope fits.

Alternatives considered

Running Ghidra's analyzeHeadless directly works, but it loses REA's agent-facing evidence, artifact and MCP workflow, which is the reason to use REA.

Possible direction

Mirror the 6502 lane. The prototype touches rawBinary.ts, binaryTargetTypes.ts, binaryTarget.ts, GhidraRawBinaryLanguage.ts, the Ghidra provider/client and evidence/snapshot schema groups, plus tests and docs (raw-binary.md, testing.md, native-and-artifacts.md, CHANGELOG.md).

References

6502 lane (verify:ghidra:6502): the structural model.
#1330 (PSP/Allegrex): the contribution pattern for a new processor family.
#2410: SuperH PE support (related, distinct path).
Ghidra Ghidra/Processors/SuperH4/data/languages/*.ldefs: SuperH4:LE:32:default.

Originally created by @theonepichael on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3532 ### 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 The raw-binary lane admits headerless images only for `x86`, `x86_64`, `arm`, `arm64` and `6502` (`src/ghidra/GhidraRawBinaryLanguage.ts`, `docs/raw-binary.md`). A headerless little-endian SH-4 image, such as a Sega Dreamcast boot executable, which has no ELF/PE/Mach-O wrapper and is loaded at a fixed address like `0x8C010000`, cannot be opened through REA. Ghidra handles it directly: `analyzeHeadless` with the raw `BinaryLoader`, `SuperH4:LE:32:default` and a base address imports and analyzes it. Related but distinct: #2410 asks for SuperH **PE** files (Windows CE). That is the PE-container path; this request is the headerless raw-image path. The two do not overlap in code (`peArchitecture()` vs `admitRawBinary`/`ghidraRawBinaryLanguage`). ### Use cases - Dreamcast homebrew and research builds, which are headerless SH-4 images. - Other embedded SH-4 firmware dumped as flat images. ### Desired outcome and success criteria `--target-format raw-binary --architecture sh4 --entry-point 0x… --provider ghidra` opens a headerless little-endian SH-4 image with the same verified load-image, instruction, reference and decompilation workflow the `6502` lane provides: - `architecture: "sh4"` is admitted with a 32-bit address width and a 2-byte-aligned entry point; odd entries are rejected. - `ghidraRawBinaryLanguage("sh4")` maps to `SuperH4:LE:32:default`, compiler spec `default`, address space `ram`. - A real-Ghidra proof (`verify:ghidra:sh4`) is structured like the 6502 lane's. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Little-endian SH-4 only. Big-endian (`SuperH4:BE:32:default`) stays out of scope for this increment. No platform-specific structure (Dreamcast IP.BIN, GD-ROM layout, memory maps) is interpreted. Windows P0 admission is unchanged. ### Verification available so far I have a prototype or observed results ### Verification details (optional) A prototype on a local branch follows the 6502 lane: a caller-visible family string, a `ghidraRawBinaryLanguage` case, a source-owned `tests/conformance/ghidra/sh4.s` fixture assembled with `sh4-linux-gnu` binutils 2.42, and `scripts/verify-real-ghidra-sh4.mjs`. Against Ghidra 12.1.4 on Linux, `GHIDRA_INSTALL_DIR=<ghidra-12.1.4> npm run verify:ghidra:sh4` reports `ok: true`. Its checks cover CLI/MCP load-image parity, a `bsr` call reference, a `bf` conditional-branch target, decompilation, the entry return being preserved, odd-entry rejection, unchanged source bytes and runtime cleanup. The touched unit test files pass (159 tests). I'm happy to open a PR if the scope fits. ### Alternatives considered Running Ghidra's `analyzeHeadless` directly works, but it loses REA's agent-facing evidence, artifact and MCP workflow, which is the reason to use REA. ### Possible direction Mirror the 6502 lane. The prototype touches `rawBinary.ts`, `binaryTargetTypes.ts`, `binaryTarget.ts`, `GhidraRawBinaryLanguage.ts`, the Ghidra provider/client and evidence/snapshot schema groups, plus tests and docs (`raw-binary.md`, `testing.md`, `native-and-artifacts.md`, `CHANGELOG.md`). ### References - 6502 lane (`verify:ghidra:6502`): the structural model. - #1330 (PSP/Allegrex): the contribution pattern for a new processor family. - #2410: SuperH PE support (related, distinct path). - Ghidra `Ghidra/Processors/SuperH4/data/languages/*.ldefs`: `SuperH4:LE:32:default`.

bsakaguchi referenced this issue

2026-10-17 21:10:18 +00:00

[PR #1311] [CLOSED] fix(reference): report malformed UTF-8 before import parsing #2791

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

No description provided.

Rows
Columns