[GH-ISSUE #1745] [Feature] Confirm the 32-bit ARM (armhf / ARMv7 EABI) native lane and pin ARM:LE:32:v7 instead of auto-selection #585

New issue

Open

opened 2026-10-15 18:26:24 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:26:24 +00:00

Owner

Originally created by @Jiang-sustech on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1745

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Current limitation

BINARY_ARCHITECTURES in src/domain/binaryTargetTypes.ts admits arm alongside arm64, but the validated fixture set in docs/provider-evaluation.md covers only x86-64 ELF, AArch64 ELF, x86-64 PE and x86-64 Mach-O. I could not find a statement — or any issue — covering 32-bit ARM (ARMv7 EABI, EM_ARM) Linux ELF, so it is unclear whether the arm entry is proven or merely allowlisted.

The failure shape I am worried about is the one described in #1620 for MIPS32: for an armhf binary the correct Ghidra language is ARM:LE:32:v7, and real-world armhf code is ARM/Thumb-2 interworked, so auto-selection has several plausible wrong answers (ARM:LE:32:Cortex, an AArch64 language, or a Thumb-only variant) that decompile to garbage rather than failing loudly.

Use cases

Static investigation of armhf Linux firmware through REA's ordinary native workflow — functions, pseudocode, references, Evidence.

Concrete target: the ZWO ASIAIR astronomy device. Its application layer ships as armhf Debian packages (asiair_armhf.deb) containing zwoair_imager, zwoair_guider and zwoair_updater, reverse-engineered by an active hobbyist community. Notes and sources are public if useful to you: https://github.com/Jiang-sustech/REA-ZWO

Desired outcome and success criteria

Confirm whether the arm entry is backed by a verified 32-bit ARM ELF lane, or is allowlisted only.
If unverified: add the lane in the shape of the other architecture work — admit ELF32 EM_ARM, little-endian, ET_EXEC; select ARM:LE:32:v7; record the observed language/compiler spec in Evidence; refuse what the lane does not cover with a specific unsupported constraint rather than guessing a profile.
Verify with a source-owned fixture cross-compiled for armhf (arm-linux-gnueabihf), including a Thumb-2 interworking case — no third-party binaries, matching the existing fixture policy.

Authority boundaries and non-goals

Read-only, caller-supplied targets. No dynamic execution, no emulation, no vendor firmware redistribution.

Alternatives considered

Driving Ghidra headless directly with an explicit -processor ARM:LE:32:v7 works for a single binary, but loses everything REA provides around it (session lifecycle, Evidence, bounded subprocess, the agent workflow). Asking here first because that defeats the purpose of using REA at all.

Note

I have not yet run REA against these binaries, so I cannot offer a failing repro — I raised this before spending time on a setup that may be a documented boundary. If a repro is a prerequisite for an actionable report, say so and I will come back with one.

Originally created by @Jiang-sustech on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1745 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Current limitation `BINARY_ARCHITECTURES` in `src/domain/binaryTargetTypes.ts` admits `arm` alongside `arm64`, but the validated fixture set in `docs/provider-evaluation.md` covers only x86-64 ELF, AArch64 ELF, x86-64 PE and x86-64 Mach-O. I could not find a statement — or any issue — covering 32-bit ARM (ARMv7 EABI, `EM_ARM`) Linux ELF, so it is unclear whether the `arm` entry is proven or merely allowlisted. The failure shape I am worried about is the one described in #1620 for MIPS32: for an armhf binary the correct Ghidra language is `ARM:LE:32:v7`, and real-world armhf code is ARM/Thumb-2 interworked, so auto-selection has several plausible wrong answers (`ARM:LE:32:Cortex`, an AArch64 language, or a Thumb-only variant) that decompile to garbage rather than failing loudly. ### Use cases Static investigation of armhf Linux firmware through REA's ordinary native workflow — functions, pseudocode, references, Evidence. Concrete target: the ZWO ASIAIR astronomy device. Its application layer ships as armhf Debian packages (`asiair_armhf.deb`) containing `zwoair_imager`, `zwoair_guider` and `zwoair_updater`, reverse-engineered by an active hobbyist community. Notes and sources are public if useful to you: https://github.com/Jiang-sustech/REA-ZWO ### Desired outcome and success criteria - Confirm whether the `arm` entry is backed by a verified 32-bit ARM ELF lane, or is allowlisted only. - If unverified: add the lane in the shape of the other architecture work — admit ELF32 `EM_ARM`, little-endian, `ET_EXEC`; select `ARM:LE:32:v7`; record the observed language/compiler spec in Evidence; refuse what the lane does not cover with a specific unsupported constraint rather than guessing a profile. - Verify with a source-owned fixture cross-compiled for armhf (`arm-linux-gnueabihf`), including a Thumb-2 interworking case — no third-party binaries, matching the existing fixture policy. ### Authority boundaries and non-goals Read-only, caller-supplied targets. No dynamic execution, no emulation, no vendor firmware redistribution. ### Alternatives considered Driving Ghidra headless directly with an explicit `-processor ARM:LE:32:v7` works for a single binary, but loses everything REA provides around it (session lifecycle, Evidence, bounded subprocess, the agent workflow). Asking here first because that defeats the purpose of using REA at all. ### Note I have not yet run REA against these binaries, so I cannot offer a failing repro — I raised this before spending time on a setup that may be a documented boundary. If a repro is a prerequisite for an actionable report, say so and I will come back with one.

bsakaguchi added the

area: native

enhancement

P2: medium

labels

2026-10-15 18:26:24 +00:00

bsakaguchi commented

2026-10-15 18:26:25 +00:00

Author

Owner

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

Ghidra Architecture Binding Review

Auto-selection in Ghidra for 32-bit ARM ELF (EM_ARM = 40) frequently misidentifies ARM vs Thumb mode or selects an overly narrow microarchitecture variant:

Pinning Strategy: Following the MIPS precedent (#1620), pinning ARM:LE:32:v7 with compiler default ensures Thumb-2 interworking is decompiled properly without relying on Ghidra's fragile auto-detection.
Verification: Adding a small source-built ARMv7 EABI fixture with ARM/Thumb function transitions to tests/fixtures/ and validating via npm run verify:ghidra will formally certify the 32-bit ARM lane.

@matbrgz commented on GitHub (Oct 12, 2026): ### Ghidra Architecture Binding Review Auto-selection in Ghidra for 32-bit ARM ELF (`EM_ARM = 40`) frequently misidentifies ARM vs Thumb mode or selects an overly narrow microarchitecture variant: - **Pinning Strategy:** Following the MIPS precedent (#1620), pinning `ARM:LE:32:v7` with compiler `default` ensures Thumb-2 interworking is decompiled properly without relying on Ghidra's fragile auto-detection. - **Verification:** Adding a small source-built ARMv7 EABI fixture with ARM/Thumb function transitions to `tests/fixtures/` and validating via `npm run verify:ghidra` will formally certify the 32-bit ARM lane.

bsakaguchi referenced this issue

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

[PR #585] [MERGED] fix(mcp): return complete inline Evidence records #2085

bsakaguchi referenced this issue

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

[PR #597] [MERGED] fix!: repair boundary contracts across CLI and MCP #2097

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:29:19 +00:00