morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #6934] inspect_binary_layout requires ELF64 LE; ELF32 targets get no layout profile and no named alternative #4242

New issue

Closed

opened 2026-10-31 00:48:01 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

Observed (rea 6.7.0, linux/amd64 dispatch container):

inspect-binary-layout on an ELF32 little-endian target returns unsupported_target:

{"code":"unsupported_target","message":"Unsupported target for inspect_binary_layout at /art/<sample>.elf: Initial layout profile requires ELF64 little-endian objects.","retryable":false,"remediation":{"action":"Select a target supported by this operation or choose an operation supporting the reported target format."}}

Every ELF32 sample in our current set (four IoT/router implants: ARM32 and MIPS32) falls outside this operation. analyze_function did work on the ARM32 sample via the Ghidra provider, so the ELF32 gap is specific to the layout profile (observed on ARM32; inferred the same boundary applies to ELF32 generally from the message wording — not separately tested for BE).

Ask: consider an ELF32 layout profile, or extending the remediation text to name the operation (or provider path) that covers ELF32 layout facts for callers. Currently the remediation suggests "choose an operation supporting the reported target format" without naming one.

Sample context (public malware, no bytes attached): same family set as the MIPS-lane report filed alongside this one — publicly documented AVRecon router implants.

Scope note: third-party static-analysis lab; pwntools-elf engines caller-supplied in the container per the documented pattern. Workaround in place (custom ELF32 parsers), so this is a coverage/UX report rather than a blocker.

Originally created by @roblennon on GitHub (Oct 24, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6934 **Observed (rea 6.7.0, linux/amd64 dispatch container):** `inspect-binary-layout` on an ELF32 little-endian target returns `unsupported_target`: ```json {"code":"unsupported_target","message":"Unsupported target for inspect_binary_layout at /art/<sample>.elf: Initial layout profile requires ELF64 little-endian objects.","retryable":false,"remediation":{"action":"Select a target supported by this operation or choose an operation supporting the reported target format."}} ``` Every ELF32 sample in our current set (four IoT/router implants: ARM32 and MIPS32) falls outside this operation. `analyze_function` did work on the ARM32 sample via the Ghidra provider, so the ELF32 gap is specific to the layout profile (observed on ARM32; inferred the same boundary applies to ELF32 generally from the message wording — not separately tested for BE). **Ask:** consider an ELF32 layout profile, or extending the remediation text to name the operation (or provider path) that covers ELF32 layout facts for callers. Currently the remediation suggests "choose an operation supporting the reported target format" without naming one. Sample context (public malware, no bytes attached): same family set as the MIPS-lane report filed alongside this one — publicly documented AVRecon router implants. **Scope note:** third-party static-analysis lab; pwntools-elf engines caller-supplied in the container per the documented pattern. Workaround in place (custom ELF32 parsers), so this is a coverage/UX report rather than a blocker.

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):

Confirmed this is a real coverage gap: most IoT/router firmware samples (AVRecon family included) are ELF32, so inspect_binary_layout silently missing them makes the layout profile effectively unusable for that whole class of targets. The remediation text is the bigger issue though — "choose an operation supporting the reported target format" doesn't name any alternative, and analyze_function is the only thing that demonstrably works today. Suggest two things: (1) mention the actual provider path (e.g. Ghidra provider's analyze_function) in the remediation so callers have a concrete fallback; (2) consider adding an ELF32 layout profile as a follow-up — ARM32/MIPS32 section and segment layout facts are equally valuable for triage, and the profile logic is mostly endianness-independent once the ELF header parsing is parameterized.

@XinwangTao commented on GitHub (Oct 24, 2026): Confirmed this is a real coverage gap: most IoT/router firmware samples (AVRecon family included) are ELF32, so inspect_binary_layout silently missing them makes the layout profile effectively unusable for that whole class of targets. The remediation text is the bigger issue though — "choose an operation supporting the reported target format" doesn't name any alternative, and analyze_function is the only thing that demonstrably works today. Suggest two things: (1) mention the actual provider path (e.g. Ghidra provider's analyze_function) in the remediation so callers have a concrete fallback; (2) consider adding an ELF32 layout profile as a follow-up — ARM32/MIPS32 section and segment layout facts are equally valuable for triage, and the profile logic is mostly endianness-independent once the ELF header parsing is parameterized.

bsakaguchi commented

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

Author

Owner

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

#7052 修复到位：按 ELF class 计算最小符号项尺寸是关键，避免 ELF32 用 ELF64 布局假设导致越界/错位。建议后续补一个 ELF32 big-endian（如 MIPS BE 或 ARM BE8）的回归用例，确保不会退回"无命名替代"的旧行为。

@XinwangTao commented on GitHub (Oct 25, 2026): #7052 修复到位：按 ELF class 计算最小符号项尺寸是关键，避免 ELF32 用 ELF64 布局假设导致越界/错位。建议后续补一个 ELF32 big-endian（如 MIPS BE 或 ARM BE8）的回归用例，确保不会退回"无命名替代"的旧行为。

bsakaguchi referenced this issue

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

[PR #4272] [CLOSED] fix(javascript): preserve canonical rest-array property keys #6150

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

No description provided.

Rows
Columns