[GH-ISSUE #6933] Ghidra MIPS lane rejects EF_MIPS_ARCH_0 (MIPS-I) targets that Ghidra 12.1.4 itself analyzes #4241

New issue

Closed

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

bsakaguchi commented

2026-10-31 00:48:00 +00:00

Owner

Originally created by @roblennon on GitHub (Oct 24, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6933

Observed (rea 6.7.0, linux/amd64 dispatch container, Ghidra 12.1.4 at GHIDRA_INSTALL_DIR):

analyze_function on an ELF32 MIPS little-endian sample returns unsupported_provider with this precise rejection:

{"provider_id":"ghidra","code":"architecture_unsupported","reason":"This Ghidra MIPS lane requires EF_MIPS_ARCH_32R2 or a recordless legacy EF_MIPS_ARCH_32 header; other ISA revisions need separate verification."}

The sample carries e_flags ISA = 0 (MIPS-I). Direct Ghidra 12.1.4 analyzeHeadless -import on the same file succeeds (Analysis succeeded ... Import succeeded), so the gate sits in REA's lane verification, not in Ghidra's capability.

Sample context (public malware, no bytes attached): ELF32 MIPS-LE stager, 3016 bytes, sha256 f18ddb10b3f9044fa2f9d1bb5152e388d4f68c2209165b117135fb2490243d2b — the AVRecon stager publicly documented by Lumen (2023), FBI FLASH (2026-03), and Wyvern Labs (2026-04).

Ask: consider widening the Ghidra MIPS lane to admit MIPS-I / EF_MIPS_ARCH_0 targets (verification per your provider-verification lanes), or documenting the supported-ISA matrix so callers can pre-compute eligibility. The precise gate reason in the error is genuinely helpful — this report is about the coverage gap, not the message quality.

Scope note: observation from a third-party static-analysis lab (quarantined dispatch container, engines mounted read-only); workaround in place (direct PyGhidra drivers), so this is a coverage report, not a blocker for us.

Originally created by @roblennon on GitHub (Oct 24, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6933 **Observed (rea 6.7.0, linux/amd64 dispatch container, Ghidra 12.1.4 at GHIDRA_INSTALL_DIR):** `analyze_function` on an ELF32 MIPS little-endian sample returns `unsupported_provider` with this precise rejection: ```json {"provider_id":"ghidra","code":"architecture_unsupported","reason":"This Ghidra MIPS lane requires EF_MIPS_ARCH_32R2 or a recordless legacy EF_MIPS_ARCH_32 header; other ISA revisions need separate verification."} ``` The sample carries `e_flags` ISA = 0 (MIPS-I). Direct Ghidra 12.1.4 `analyzeHeadless -import` on the same file succeeds (`Analysis succeeded ... Import succeeded`), so the gate sits in REA's lane verification, not in Ghidra's capability. Sample context (public malware, no bytes attached): ELF32 MIPS-LE stager, 3016 bytes, sha256 `f18ddb10b3f9044fa2f9d1bb5152e388d4f68c2209165b117135fb2490243d2b` — the AVRecon stager publicly documented by Lumen (2023), FBI FLASH (2026-03), and Wyvern Labs (2026-04). **Ask:** consider widening the Ghidra MIPS lane to admit MIPS-I / `EF_MIPS_ARCH_0` targets (verification per your provider-verification lanes), or documenting the supported-ISA matrix so callers can pre-compute eligibility. The precise gate reason in the error is genuinely helpful — this report is about the coverage gap, not the message quality. **Scope note:** observation from a third-party static-analysis lab (quarantined dispatch container, engines mounted read-only); workaround in place (direct PyGhidra drivers), so this is a coverage report, not a blocker for us.

bsakaguchi closed this issue

2026-10-31 00:48:01 +00:00

bsakaguchi commented

2026-10-31 00:48:01 +00:00

Author

Owner

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

This matches what I'd expect from a lane-verification bug rather than a Ghidra capability gap — Ghidra 12.1.4 importing the sample cleanly proves the toolchain can handle MIPS-I, so REA's gate is stricter than the underlying provider. For AVRecon-class stagers specifically, MIPS-I is common because it compiles to the smallest footprint, so this rejection hits real samples, not edge cases. I'd lean toward widening the lane (MIPS-I is ancient but fully supported by Ghidra's language modules) plus a documented ISA matrix as the fallback. One thought: rather than hard-rejecting unknown e_flags ISA revisions, consider warning-and-passing them through to Ghidra — the worst case is a downstream analysis failure, which is more debuggable than a pre-emptive gate. This is also the second ELF32/MIPS coverage gap in this batch (#6934 being the other), so an audit of the verification lanes against what the pinned Ghidra version actually accepts would likely surface more of these.

@XinwangTao commented on GitHub (Oct 24, 2026): This matches what I'd expect from a lane-verification bug rather than a Ghidra capability gap — Ghidra 12.1.4 importing the sample cleanly proves the toolchain can handle MIPS-I, so REA's gate is stricter than the underlying provider. For AVRecon-class stagers specifically, MIPS-I is common because it compiles to the smallest footprint, so this rejection hits real samples, not edge cases. I'd lean toward widening the lane (MIPS-I is ancient but fully supported by Ghidra's language modules) plus a documented ISA matrix as the fallback. One thought: rather than hard-rejecting unknown e_flags ISA revisions, consider warning-and-passing them through to Ghidra — the worst case is a downstream analysis failure, which is more debuggable than a pre-emptive gate. This is also the second ELF32/MIPS coverage gap in this batch (#6934 being the other), so an audit of the verification lanes against what the pinned Ghidra version actually accepts would likely surface more of these.

bsakaguchi referenced this issue

2026-10-31 01:12:16 +00:00

[PR #4275] [CLOSED] fix(ghidra): report JVM heap exhaustion as a memory constraint #6152

bsakaguchi referenced this issue

2026-10-31 01:13:36 +00:00

[PR #4590] [MERGED] fix(ghidra): name the startup deadline setting when startup times out #6327