[GH-ISSUE #2063] [Feature] Add RISC-V ELF analysis through Ghidra (RV32/RV64) #683

New issue

Closed

opened 2026-10-15 18:27:21 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:27:21 +00:00

Owner

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

Problem

REA 6.4.0 rejects a valid RISC-V ELF before Ghidra analysis with:

{"code":"target_unavailable","details":{"reason":"unsupported ELF architecture"}}

The same RV32 input was successfully imported, analyzed, and decompiled directly with Ghidra 12.1.4 / JDK 21 on Linux. Ghidra selected RISCV:LE:32:AndeStar_v5 with compiler gcc.

In the installed REA package, elfArchitecture() has no RISC-V branch. The shared architecture list and GhidraProvider supported-architecture list also omit RISC-V. Adding ELF detection alone would therefore leave another admission barrier.

Requested scope

Add RISC-V support as an architecture family, covering RV32 and RV64:

Recognize EM_RISCV = 243, recording ELF class / bit width, byte order, and relevant flags separately.
Extend architecture contracts, schemas, and Ghidra admission consistently.
Select and verify the Ghidra language/compiler for supported RISC-V variants, including the observed Andes RV32 case. Report unverified or unsupported combinations explicitly.
Verify the native analysis workflow through CLI and MCP, including function enumeration, decompilation, and evidence serialization.

RV32 is the observed failure case; RV64 is part of the requested implementation scope and has not yet been verified in this report.

Acceptance criteria

Source-generated public RV32 and RV64 ELF fixtures complete the Ghidra workflow.
Parser/admission tests cover bit width, malformed headers, and unsupported combinations.
Architecture and analysis-profile information remain accurate in evidence and cached results.
Existing architecture/provider workflows retain their behavior.

Contribution

I would like to implement this. Is anyone already working on RISC-V support, and does this scope fit the project?

Related: #718 identified RISC-V admission as a firmware-analysis gap. Searches of open and closed issues/PRs for riscv and RISC-V did not find a dedicated implementation request for this scope. No private binary, local path, or credential is included in this report.

Originally created by @desayVincent on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2063 ## Problem REA 6.4.0 rejects a valid RISC-V ELF before Ghidra analysis with: ```json {"code":"target_unavailable","details":{"reason":"unsupported ELF architecture"}} ``` The same RV32 input was successfully imported, analyzed, and decompiled directly with Ghidra 12.1.4 / JDK 21 on Linux. Ghidra selected `RISCV:LE:32:AndeStar_v5` with compiler `gcc`. In the installed REA package, `elfArchitecture()` has no RISC-V branch. The shared architecture list and `GhidraProvider` supported-architecture list also omit RISC-V. Adding ELF detection alone would therefore leave another admission barrier. ## Requested scope Add RISC-V support as an architecture family, covering RV32 and RV64: - Recognize `EM_RISCV = 243`, recording ELF class / bit width, byte order, and relevant flags separately. - Extend architecture contracts, schemas, and Ghidra admission consistently. - Select and verify the Ghidra language/compiler for supported RISC-V variants, including the observed Andes RV32 case. Report unverified or unsupported combinations explicitly. - Verify the native analysis workflow through CLI and MCP, including function enumeration, decompilation, and evidence serialization. RV32 is the observed failure case; RV64 is part of the requested implementation scope and has not yet been verified in this report. ## Acceptance criteria - Source-generated public RV32 and RV64 ELF fixtures complete the Ghidra workflow. - Parser/admission tests cover bit width, malformed headers, and unsupported combinations. - Architecture and analysis-profile information remain accurate in evidence and cached results. - Existing architecture/provider workflows retain their behavior. ## Contribution I would like to implement this. Is anyone already working on RISC-V support, and does this scope fit the project? Related: #718 identified RISC-V admission as a firmware-analysis gap. Searches of open and closed issues/PRs for `riscv` and `RISC-V` did not find a dedicated implementation request for this scope. No private binary, local path, or credential is included in this report.

bsakaguchi

2026-10-15 18:27:21 +00:00

closed this issue
added the
area: native

enhancement

P2: medium
labels

bsakaguchi commented

2026-10-15 18:27:22 +00:00

Author

Owner

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

Implementation & Scope Review

Adding RISC-V ELF support (RV32 / RV64) is an important architecture family addition:

ELF Machine ID: EM_RISCV = 243 (0xF3).
Language Binding in Ghidra:
- 32-bit: Map to RISCV:LE:32:default (or specific extensions based on ELF flags).
- 64-bit: Map to RISCV:LE:64:default.
Contract Expansion: Add "riscv32" and "riscv64" (or unified "riscv") to public architecture enums across src/contracts/ and src/domain/binaryTarget.ts accompanied by focused tests with synthetic RV32/RV64 ELF headers.

@matbrgz commented on GitHub (Oct 12, 2026): ### Implementation & Scope Review Adding RISC-V ELF support (RV32 / RV64) is an important architecture family addition: - **ELF Machine ID:** `EM_RISCV = 243` (`0xF3`). - **Language Binding in Ghidra:** - 32-bit: Map to `RISCV:LE:32:default` (or specific extensions based on ELF flags). - 64-bit: Map to `RISCV:LE:64:default`. - **Contract Expansion:** Add `"riscv32"` and `"riscv64"` (or unified `"riscv"`) to public architecture enums across `src/contracts/` and `src/domain/binaryTarget.ts` accompanied by focused tests with synthetic RV32/RV64 ELF headers.

bsakaguchi commented

2026-10-15 18:27:22 +00:00

Author

Owner

@desayVincent commented on GitHub (Oct 13, 2026):

Got it — thanks for the merge. I'll try it out myself first.

@desayVincent commented on GitHub (Oct 13, 2026): Got it — thanks for the merge. I'll try it out myself first.

bsakaguchi referenced this issue

2026-10-16 21:15:07 +00:00

[PR #683] [MERGED] docs: add the official Trendshift badge to README headers #2165

bsakaguchi added

enhancement