morluto/rea

Fork 0

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

[GH-ISSUE #6581] [Bug] Rust binary inspection drops the recognized arm64_32 Mach-O architecture #3970

New issue

Closed

opened 2026-10-31 00:45:41 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:45:41 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6581

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

Source-only finding; runtime reproduction NOT RUN. inspect_rust_binary accepts a thin Mach-O declaring CPU_TYPE_ARM64_32 (0x0200000c) but reports architecture: "macho-cpu-33554444". The Rust Evidence subject then loses its architecture because that numeric fallback is not a canonical family. REA already recognizes these same header bytes as arm64_32 in its owning target classifier.

Reproduction

Runtime reproduction NOT RUN. Source tracing only; no executable or provider was run.

Proposed steps, UNEXECUTED:

Select a valid thin little-endian watchOS arm64_32 Mach-O executable or library. Its Mach-O CPU type is 0x0200000c; no .dep-v0 section is necessary because absence is a supported successful inspection.
Call inspect_rust_binary with {"path":"/artifacts/watch-binary"}, without architecture (that argument is for universal-image selection).
Inspect the source-derived normalized_result.architecture and Evidence subject architecture: the current path yields the numeric fallback and an unknown subject instead of the known arm64_32 family.

Expected behavior

Preserve arm64_32 in the accepted image's architecture report and Evidence subject. This establishes the declared CPU family only; it makes no claim of a verified disassembler lane or a compiler identity. The canonical architecture vocabulary includes arm64_32, and the target header classifier explicitly recognizes this CPU.

Impact and scope

An accepted static metadata result loses a known CPU family, preventing consumers from reliably correlating the Rust dependency report with other REA Evidence for the same arm64_32 artifact. This applies to the cited thin-image path regardless of dependency-section presence. Other architectures and universal-image selection are outside this report. No persistent artifact change or security impact is alleged. No runtime workaround was established.

REA version

6.7.0; source baseline 46111dd091f2ae01baab9eb119b53b9bd309a05b on main. The supplied release baseline is npm 6.7.0.

Runtime and platform

Source-only (no REA or provider runtime run). The bundled in-process reader requires no Rust toolchain or deep-analysis provider. No local Node.js or provider version was measured.

Target and artifact context

A valid thin arm64_32 Mach-O executable/library, such as watchOS code with AArch64 instructions and 32-bit pointers. Missing embedded dependency metadata is explicitly supported.

Interface

MCP

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Evidence provenance: source-derived. Runtime reproduction: NOT RUN.

The common Mach-O reader omits 0x0200000c from its CPU map and substitutes macho-cpu-${cpu}.
Rust copies that architecture directly into its image result; the provider reads the selected thin bytes and includes that result in its report.
The Rust subject mapper admits only recognized canonical names or its x86 aliases, and Evidence construction omits architecture when the mapper returns undefined.
In contrast, the owning header classifier maps exactly this CPU to arm64_32; an existing header test names the same CPU. That test is source evidence, not a test executed in this investigation.

Typed outcome or recovery expected

A successful Rust metadata result should retain architecture: "arm64_32" and the same family in its Evidence subject. Header width and dependency metadata should continue to describe their own independent facts.

Analysis or suspected cause

The shared native metadata reader keeps a separate incomplete CPU-name table from the established Mach-O target classifier. This differs from #4197: PowerPC already leaves the reader as ppc and is lost by alias translation, whereas arm64_32 is unknown before the Rust subject mapper runs. PR #4220's ppc mapping does not fix this input.

Additional context

The supplied open-issue and open-PR snapshots were searched by titles and relevant bodies. #5191 concerns universal format and arm64e subtype spellings; #5359 concerns encryption evidence. Neither addresses Rust's missing arm64_32 family. A final live open/closed search found closed #5713, which concerns refusal at native target admission. This report concerns an accepted Rust inspection result losing architecture in the separate metadata-reader path; the canonical classifier cited above already recognizes the family. No separate reverification pass was run.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: Accepted metadata for a recognized CPU family exposes a numeric unknown and drops the canonical Evidence architecture, impairing artifact correlation without rejecting the request.
Workaround status: unverified
Workaround basis: Other REA header parsing recognizes the family in source, but no separate user workflow was executed to establish an identity-preserving workaround for the Rust result.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6581 ### 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 Source-only finding; runtime reproduction NOT RUN. `inspect_rust_binary` accepts a thin Mach-O declaring `CPU_TYPE_ARM64_32` (`0x0200000c`) but reports `architecture: "macho-cpu-33554444"`. The Rust Evidence subject then loses its architecture because that numeric fallback is not a canonical family. REA already recognizes these same header bytes as `arm64_32` in its owning target classifier. ### Reproduction Runtime reproduction NOT RUN. Source tracing only; no executable or provider was run. Proposed steps, UNEXECUTED: 1. Select a valid thin little-endian watchOS arm64_32 Mach-O executable or library. Its Mach-O CPU type is `0x0200000c`; no `.dep-v0` section is necessary because absence is a supported successful inspection. 2. Call `inspect_rust_binary` with `{"path":"/artifacts/watch-binary"}`, without `architecture` (that argument is for universal-image selection). 3. Inspect the source-derived `normalized_result.architecture` and Evidence subject architecture: the current path yields the numeric fallback and an unknown subject instead of the known `arm64_32` family. ### Expected behavior Preserve `arm64_32` in the accepted image's architecture report and Evidence subject. This establishes the declared CPU family only; it makes no claim of a verified disassembler lane or a compiler identity. The [canonical architecture vocabulary includes arm64_32](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/domain/binaryTargetTypes.ts#L3-L16), and the [target header classifier explicitly recognizes this CPU](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/domain/binaryTarget.ts#L130-L164). ### Impact and scope An accepted static metadata result loses a known CPU family, preventing consumers from reliably correlating the Rust dependency report with other REA Evidence for the same arm64_32 artifact. This applies to the cited thin-image path regardless of dependency-section presence. Other architectures and universal-image selection are outside this report. No persistent artifact change or security impact is alleged. No runtime workaround was established. ### REA version 6.7.0; source baseline `46111dd091f2ae01baab9eb119b53b9bd309a05b` on main. The supplied release baseline is npm 6.7.0. ### Runtime and platform Source-only (no REA or provider runtime run). The bundled in-process reader requires no Rust toolchain or deep-analysis provider. No local Node.js or provider version was measured. ### Target and artifact context A valid thin arm64_32 Mach-O executable/library, such as watchOS code with AArch64 instructions and 32-bit pointers. Missing embedded dependency metadata is explicitly supported. ### Interface MCP ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence Evidence provenance: source-derived. Runtime reproduction: NOT RUN. - The common Mach-O reader [omits `0x0200000c` from its CPU map and substitutes `macho-cpu-${cpu}`](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/native/metadata/MachoImage.ts#L153-L167). - Rust [copies that architecture directly into its image result](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/rust/RustBinaryImage.ts#L32-L45); the [provider reads the selected thin bytes and includes that result in its report](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/rust/RustBinaryProvider.ts#L93-L114). - The Rust [subject mapper admits only recognized canonical names or its x86 aliases](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/domain/rust/rustBinary.ts#L15-L26), and [Evidence construction omits architecture when the mapper returns undefined](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/application/rust/RustBinaryService.ts#L89-L98). - In contrast, the [owning header classifier maps exactly this CPU to arm64_32](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/domain/binaryTarget.ts#L130-L164); an [existing header test names the same CPU](https://github.com/morluto/rea/blob/46111dd091f2ae01baab9eb119b53b9bd309a05b/src/domain/binaryTarget.test.ts#L17-L28). That test is source evidence, not a test executed in this investigation. ### Typed outcome or recovery expected A successful Rust metadata result should retain `architecture: "arm64_32"` and the same family in its Evidence subject. Header width and dependency metadata should continue to describe their own independent facts. ### Analysis or suspected cause The shared native metadata reader keeps a separate incomplete CPU-name table from the established Mach-O target classifier. This differs from #4197: PowerPC already leaves the reader as `ppc` and is lost by alias translation, whereas arm64_32 is unknown before the Rust subject mapper runs. PR #4220's ppc mapping does not fix this input. ### Additional context The supplied open-issue and open-PR snapshots were searched by titles and relevant bodies. #5191 concerns universal format and arm64e subtype spellings; #5359 concerns encryption evidence. Neither addresses Rust's missing arm64_32 family. A final live open/closed search found closed #5713, which concerns refusal at native target admission. This report concerns an accepted Rust inspection result losing architecture in the separate metadata-reader path; the canonical classifier cited above already recognizes the family. No separate reverification pass was run. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: Accepted metadata for a recognized CPU family exposes a numeric unknown and drops the canonical Evidence architecture, impairing artifact correlation without rejecting the request. - Workaround status: unverified - Workaround basis: Other REA header parsing recognizes the family in source, but no separate user workflow was executed to establish an identity-preserving workaround for the Rust result.

bsakaguchi closed this issue

2026-10-31 00:45:41 +00:00

bsakaguchi referenced this issue

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

[PR #3997] [CLOSED] fix(native): admit zero-length PE resource payloads at the section end #5981

bsakaguchi referenced this issue

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

[PR #4007] [CLOSED] fix: accept zero-length PE resources at section end #5987

bsakaguchi referenced this issue

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

[PR #4156] [CLOSED] fix(ghidra): compare DOS relocation windows with final loaded bytes #6094

bsakaguchi referenced this issue