morluto/rea

Fork 0

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

[GH-ISSUE #4800] [Bug] inspect-pe-resources never reports the subject architecture #2496

New issue

Closed

opened 2026-10-17 21:05:43 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-17 21:05:43 +00:00

Owner

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

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-pe-resources never sets subject.architecture. It stays null for every PE file, even though the same report contains the COFF machine (normalized_result.machine). Other PE readers (inspect-go-binary, inspect-rust-binary, inspect-managed-artifact) report the architecture for the same files.

Reproduction

Ran once each on four real Windows PE files:

node scripts/rea.mjs inspect-pe-resources fastlist-0.3.0-x86.exe --format json

File	`machine`	`subject.architecture`
`fastlist-0.3.0-x86.exe` (pnpm vendor)	332 (i386)	`null`
`clipboard_x86_64.exe` (clipboardy)	34404 (AMD64)	`null`
`clipboard_aarch64.exe` (clipboardy)	43620 (ARM64)	`null`
`winpty.dll` (node-pty prebuild)	34404 (AMD64)	`null`

Expected behavior

subject.architecture is x86, x86_64 or arm64, as the other PE readers report. A machine REA does not recognize stays null.

Impact and scope

Resource data is correct. Only the subject architecture is missing, so this Evidence cannot be matched by architecture with other Evidence for the same file.

REA version

source 7aa4b98c9 (6.5.0)

Runtime and platform

Node 24.16.0, Fedora Linux 44 x86_64

Target and artifact context

Public PE files shipped in npm packages (pnpm, clipboardy, node-pty)

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

"subject": { "format": "pe", "architecture": null },
"normalized_result": { "format": "pe32", "machine": 332 }

Analysis or suspected cause

Source-derived: PeResourcesService builds the Evidence subject with path, format and sha256 only. It never maps report.machine through decodePeMachine. I have a fix ready and will open a PR.

Originally created by @AniketR10 on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4800 ### 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-pe-resources` never sets `subject.architecture`. It stays `null` for every PE file, even though the same report contains the COFF machine (`normalized_result.machine`). Other PE readers (`inspect-go-binary`, `inspect-rust-binary`, `inspect-managed-artifact`) report the architecture for the same files. ### Reproduction Ran once each on four real Windows PE files: ```sh node scripts/rea.mjs inspect-pe-resources fastlist-0.3.0-x86.exe --format json ``` | File | `machine` | `subject.architecture` | | --- | --- | --- | | `fastlist-0.3.0-x86.exe` (pnpm vendor) | 332 (i386) | `null` | | `clipboard_x86_64.exe` (clipboardy) | 34404 (AMD64) | `null` | | `clipboard_aarch64.exe` (clipboardy) | 43620 (ARM64) | `null` | | `winpty.dll` (node-pty prebuild) | 34404 (AMD64) | `null` | ### Expected behavior `subject.architecture` is `x86`, `x86_64` or `arm64`, as the other PE readers report. A machine REA does not recognize stays `null`. ### Impact and scope Resource data is correct. Only the subject architecture is missing, so this Evidence cannot be matched by architecture with other Evidence for the same file. ### REA version source `7aa4b98c9` (6.5.0) ### Runtime and platform Node 24.16.0, Fedora Linux 44 x86_64 ### Target and artifact context Public PE files shipped in npm packages (pnpm, clipboardy, node-pty) ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence ```json "subject": { "format": "pe", "architecture": null }, "normalized_result": { "format": "pe32", "machine": 332 } ``` ### Analysis or suspected cause Source-derived: `PeResourcesService` builds the Evidence subject with `path`, `format` and `sha256` only. It never maps `report.machine` through `decodePeMachine`. I have a fix ready and will open a PR.

bsakaguchi closed this issue

2026-10-17 21:05:43 +00:00

bsakaguchi commented

2026-10-17 21:05:45 +00:00

Author

Owner

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

Fixed on main in 926e18b3f, adapting @AniketR10's #4801 with coauthor credit.

The Evidence subject now uses the canonical COFF machine decoder and shared optional-header magic rule. Conflicting headers, unknown machines and unproven managed OS overrides stay unknown. Raw machine/format facts remain in the report. The old private machine-to-magic interpretation was removed from binary-target parsing.

Executed validation: two service regressions failed before the fix; 139 focused checks across six files passed afterward, including actual built CLI and real stdio MCP subject/result identity parity. Added all supported ARM encodings and late-cancellation subject retention to the contributor controls. Build, typecheck/lint and commit/push hooks passed. Independent source review found no blockers. Authored inert PE files only; no Windows host or real target execution claim.

24 completed actual CLI cost tasks compared four tiny PE fixtures, with first processes separated from two alternating repeats. Unknown/conflicting full replies were byte-identical; known architecture intentionally changes Evidence identity. Repeat medians were roughly 0.35–0.38 seconds elapsed, 0.53–0.55 seconds CPU and 331–352 MB sampled process-family peak. Full reply cl100k estimates: x86 1785→1792, x64 1787→1785, unknown 1775→1775, conflict 1785→1785 (Evidence IDs also change). Small samples; no speedup or true-cold claim. Whole-agent, MCP and large-file costs remain unmeasured.

@morluto commented on GitHub (Oct 17, 2026): Fixed on main in 926e18b3f, adapting @AniketR10's #4801 with coauthor credit. The Evidence subject now uses the canonical COFF machine decoder and shared optional-header magic rule. Conflicting headers, unknown machines and unproven managed OS overrides stay unknown. Raw machine/format facts remain in the report. The old private machine-to-magic interpretation was removed from binary-target parsing. Executed validation: two service regressions failed before the fix; 139 focused checks across six files passed afterward, including actual built CLI and real stdio MCP subject/result identity parity. Added all supported ARM encodings and late-cancellation subject retention to the contributor controls. Build, typecheck/lint and commit/push hooks passed. Independent source review found no blockers. Authored inert PE files only; no Windows host or real target execution claim. 24 completed actual CLI cost tasks compared four tiny PE fixtures, with first processes separated from two alternating repeats. Unknown/conflicting full replies were byte-identical; known architecture intentionally changes Evidence identity. Repeat medians were roughly 0.35–0.38 seconds elapsed, 0.53–0.55 seconds CPU and 331–352 MB sampled process-family peak. Full reply cl100k estimates: x86 1785→1792, x64 1787→1785, unknown 1775→1775, conflict 1785→1785 (Evidence IDs also change). Small samples; no speedup or true-cold claim. Whole-agent, MCP and large-file costs remain unmeasured.

bsakaguchi referenced this issue

2026-10-31 01:05:17 +00:00

[PR #2487] [MERGED] feat(signals): discover installed decoders and option help #5266

bsakaguchi referenced this issue

2026-10-31 01:05:22 +00:00

[PR #2496] [MERGED] feat(captures): discover installed protocol and field definitions #5275

bsakaguchi referenced this issue

2026-10-31 01:05:34 +00:00

[PR #2643] [MERGED] fix(process): preserve discovery ownership across cleanup retries #5301

bsakaguchi referenced this issue

2026-10-31 01:05:40 +00:00

[PR #2691] [MERGED] test: share repeated boundary preambles to restore the jscpd gate #5315