[GH-ISSUE #4786] [Bug] Electron fuse inspection reports null architecture for ELF and PE executables #2489

Closed
opened 2026-10-17 21:05:37 +00:00 by bsakaguchi · 2 comments
Owner

Originally created by @AniketR10 on GitHub (Oct 17, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4786

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

inspect-electron-fuses returns architecture: null for ELF (Linux) and PE (Windows) Electron executables, both in the Evidence subject and in the slice. Mach-O files report their architecture correctly.

Reproduction

Ran once against an installed VS Code (x86-64 ELF):

node scripts/rea.mjs inspect-electron-fuses /usr/share/code/code --format json

file reports ELF 64-bit LSB pie executable, x86-64.

Expected behavior

The slice and the subject report architecture: "x86_64", the same way thin Mach-O files report theirs. An architecture REA does not recognize should stay null; it should not make the fuse read fail.

Impact and scope

Fuse values are still read correctly. Only the architecture is missing, so x64 and arm64 builds of a Windows or Linux app cannot be told apart from this Evidence. I ran it only on the Linux ELF above. PE is source-derived: it follows the same code path but I did not run it.

REA version

source 5d6029ea6 (6.5.0)

Runtime and platform

Node 24.16.0, Fedora Linux 44 x86_64

Target and artifact context

VS Code's code executable (Electron, x86-64 ELF)

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

"subject": { "format": "elf", "architecture": null },
"slices": [{ "index": 0, "architecture": null, "sentinel_count": 1 }]

Analysis or suspected cause

Source-derived: in identifyContainer in src/electron/ElectronFuseReader.ts, the ELF and PE branches only check magic bytes and hardcode architecture: null. Only the Mach-O branch uses a parser. The domain parsers that parseExecutableHeader already uses (readElfFixedHeader, decodePeMachine) could provide the architecture. Existing tests cover the Mach-O architecture only.

Originally created by @AniketR10 on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4786 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior `inspect-electron-fuses` returns `architecture: null` for ELF (Linux) and PE (Windows) Electron executables, both in the Evidence `subject` and in the slice. Mach-O files report their architecture correctly. ### Reproduction Ran once against an installed VS Code (x86-64 ELF): ```sh node scripts/rea.mjs inspect-electron-fuses /usr/share/code/code --format json ``` `file` reports `ELF 64-bit LSB pie executable, x86-64`. ### Expected behavior The slice and the subject report `architecture: "x86_64"`, the same way thin Mach-O files report theirs. An architecture REA does not recognize should stay `null`; it should not make the fuse read fail. ### Impact and scope Fuse values are still read correctly. Only the architecture is missing, so x64 and arm64 builds of a Windows or Linux app cannot be told apart from this Evidence. I ran it only on the Linux ELF above. PE is source-derived: it follows the same code path but I did not run it. ### REA version source `5d6029ea6` (6.5.0) ### Runtime and platform Node 24.16.0, Fedora Linux 44 x86_64 ### Target and artifact context VS Code's `code` executable (Electron, x86-64 ELF) ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence ```json "subject": { "format": "elf", "architecture": null }, "slices": [{ "index": 0, "architecture": null, "sentinel_count": 1 }] ``` ### Analysis or suspected cause Source-derived: in `identifyContainer` in `src/electron/ElectronFuseReader.ts`, the ELF and PE branches only check magic bytes and hardcode `architecture: null`. Only the Mach-O branch uses a parser. The domain parsers that `parseExecutableHeader` already uses (`readElfFixedHeader`, `decodePeMachine`) could provide the architecture. Existing tests cover the Mach-O architecture only.
Author
Owner

@pablodiazjorge commented on GitHub (Oct 17, 2026):

Reproduced on Windows 11 with main 149a0fc06: a small x86-64 PE (Machine 0x8664) carrying a fuse wire reads its fuses correctly but reports architecture: null in both the Evidence subject and the slice, matching your reading of identifyContainer. I'd like to take this one: derive the ELF and PE slice architecture with the header parsers parseExecutableHeader already uses (readElfFixedHeader, decodePeMachine), with tests for PE and ELF on x86, x86_64 and arm64, and an unknown machine staying null.

<!-- gh-comment-id:6233849169 --> @pablodiazjorge commented on GitHub (Oct 17, 2026): Reproduced on Windows 11 with main 149a0fc06: a small x86-64 PE (Machine 0x8664) carrying a fuse wire reads its fuses correctly but reports `architecture: null` in both the Evidence subject and the slice, matching your reading of `identifyContainer`. I'd like to take this one: derive the ELF and PE slice architecture with the header parsers `parseExecutableHeader` already uses (`readElfFixedHeader`, `decodePeMachine`), with tests for PE and ELF on x86, x86_64 and arm64, and an unknown machine staying `null`.
Author
Owner

@morluto commented on GitHub (Oct 17, 2026):

Fixed on main in bf54c4626.

Known ELF and PE machine values now reach both slice architecture and Evidence subject. The shared fixed ELF header owns raw machine and canonical family; binary-target, MIPS and Go consumers reuse those parsed facts. PE signature detection and complete COFF machine decoding happen together; unknown/incomplete headers and unproven managed OS overrides retain null while fuse scanning remains available.

Adapted the CLI controls and fixture builders from @kaoru0822-kitauji’s #4788, credited in the commit; extended x86, ELF class/byte order, unknown/malformed headers, MCP and byte-preservation coverage.

Validation: 430 distinct focused checks passed, one Windows-only skip; build, static and documentation checks passed. Five authored inert fixtures have identical full built-CLI and actual stdio MCP Evidence. Thirty small CLI cost tasks compare baseline and candidate; unknown ELF/PE and Mach-O control replies are byte identical. No performance improvement claimed. After rebasing over the incoming unrelated formatting change, 48 affected checks passed with the same skip, and the pre-push static check passed.

Scope: authored minimal headers on macOS; no installed Linux/Windows Electron app run or target execution.

<!-- gh-comment-id:6234276672 --> @morluto commented on GitHub (Oct 17, 2026): Fixed on main in bf54c4626. Known ELF and PE machine values now reach both slice architecture and Evidence subject. The shared fixed ELF header owns raw machine and canonical family; binary-target, MIPS and Go consumers reuse those parsed facts. PE signature detection and complete COFF machine decoding happen together; unknown/incomplete headers and unproven managed OS overrides retain null while fuse scanning remains available. Adapted the CLI controls and fixture builders from @kaoru0822-kitauji’s #4788, credited in the commit; extended x86, ELF class/byte order, unknown/malformed headers, MCP and byte-preservation coverage. Validation: 430 distinct focused checks passed, one Windows-only skip; build, static and documentation checks passed. Five authored inert fixtures have identical full built-CLI and actual stdio MCP Evidence. Thirty small CLI cost tasks compare baseline and candidate; unknown ELF/PE and Mach-O control replies are byte identical. No performance improvement claimed. After rebasing over the incoming unrelated formatting change, 48 affected checks passed with the same skip, and the pre-push static check passed. Scope: authored minimal headers on macOS; no installed Linux/Windows Electron app run or target execution.
Sign in to join this conversation.
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#2489
No description provided.