morluto/rea

Fork 0

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

[GH-ISSUE #5191] [Bug] Inconsistent format names, collapsed slice names and raw platform codes across the binary tools #3184

New issue

Closed

opened 2026-10-31 00:37:37 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-31 00:37:37 +00:00

Owner

Originally created by @fp2s92d5pd-bit on GitHub (Oct 19, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5191

REA 6.5.0 on macOS (Apple silicon, Xcode 27 simulator runtimes). Found while using the MCP tools on stock system binaries; all reproducible from a stock 6.5.0 install.

Observed

For a two-slice universal binary (arm64 + arm64e.x1), e.g. /System/Applications/Calculator.app/Contents/MacOS/Calculator:

open_binary and binary_session report format: "mach-o-universal", while inspect_macho reports format: "mach-o". A consumer keying on the format cannot tell fat from thin without also reading architectures.total > 1.
inspect_macho lists architectures: ["arm64"] for the arm64 + arm64e.x1 pair, and trace_dylib_resolution labels the arm64e.x1 image arm64. The vmex subtypes are present in the load commands but are not surfaced as slice names. (Related: #3072, #4293.)
inspect_macho.build_metadata.platform is the raw code: "7" (iOS simulator), "8" (tvOS simulator), "9" (watchOS simulator), "12" (visionOS simulator), rather than names such as iOSSimulator, tvOSSimulator, watchOSSimulator, visionOSSimulator. macOS and device platforms use the same numeric scheme.
6.4.0 returned endian: null for every Mach-O measured; 6.5.0 returns little — already fixed, noted only for the changelog.

Proposal

Use one format vocabulary across open_binary, binary_session and inspect_macho: mach-o for thin, mach-o-universal for fat.
Surface exact slice names (arm64, arm64e, arm64e.x1) in inspect_macho and trace_dylib_resolution, not a collapsed base architecture.
Decode LC_BUILD_VERSION.platform to the platform name and keep the numeric code as an additional field for consumers that want it.
Keep the 6.5.0 inspect_macho detail=summary route; it turns a ~295 KB complete payload into ~3.2 KB.

Reproduction

open_binary, list_architectures, inspect_macho, inspect_signature and trace_dylib_resolution on the universal Calculator app and on the Xcode simulator runtime binaries. Not a request for new analysis capability; the fields above are what the MCP surface returned.

Originally created by @fp2s92d5pd-bit on GitHub (Oct 19, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5191 REA 6.5.0 on macOS (Apple silicon, Xcode 27 simulator runtimes). Found while using the MCP tools on stock system binaries; all reproducible from a stock 6.5.0 install. ### Observed For a two-slice universal binary (`arm64` + `arm64e.x1`), e.g. `/System/Applications/Calculator.app/Contents/MacOS/Calculator`: - `open_binary` and `binary_session` report `format: "mach-o-universal"`, while `inspect_macho` reports `format: "mach-o"`. A consumer keying on the format cannot tell fat from thin without also reading `architectures.total > 1`. - `inspect_macho` lists `architectures: ["arm64"]` for the `arm64 + arm64e.x1` pair, and `trace_dylib_resolution` labels the `arm64e.x1` image `arm64`. The vmex subtypes are present in the load commands but are not surfaced as slice names. (Related: #3072, #4293.) - `inspect_macho.build_metadata.platform` is the raw code: `"7"` (iOS simulator), `"8"` (tvOS simulator), `"9"` (watchOS simulator), `"12"` (visionOS simulator), rather than names such as `iOSSimulator`, `tvOSSimulator`, `watchOSSimulator`, `visionOSSimulator`. macOS and device platforms use the same numeric scheme. - 6.4.0 returned `endian: null` for every Mach-O measured; 6.5.0 returns `little` — already fixed, noted only for the changelog. ### Proposal - Use one format vocabulary across `open_binary`, `binary_session` and `inspect_macho`: `mach-o` for thin, `mach-o-universal` for fat. - Surface exact slice names (`arm64`, `arm64e`, `arm64e.x1`) in `inspect_macho` and `trace_dylib_resolution`, not a collapsed base architecture. - Decode `LC_BUILD_VERSION.platform` to the platform name and keep the numeric code as an additional field for consumers that want it. - Keep the 6.5.0 `inspect_macho detail=summary` route; it turns a ~295 KB complete payload into ~3.2 KB. ### Reproduction `open_binary`, `list_architectures`, `inspect_macho`, `inspect_signature` and `trace_dylib_resolution` on the universal Calculator app and on the Xcode simulator runtime binaries. Not a request for new analysis capability; the fields above are what the MCP surface returned.

bsakaguchi closed this issue

2026-10-31 00:37:37 +00:00

bsakaguchi commented

2026-10-31 00:37:38 +00:00

Author

Owner

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

These inconsistencies are easy to trip over in practice — a consumer keying on format to pick a parsing path gets different answers from different tools, and collapsed slice names hide the real arch layout of simulator binaries. +1 to the unified vocabulary (mach-o / mach-o-universal) and to surfacing exact slice names. One note on the platform decode: exposing a human-readable name is good, but keeping the numeric code as an additional field (as you propose) matters for existing consumers that switch on the raw value — making it additive avoids a breaking change. Also agree with keeping the detail=summary route given the payload size.

@XinwangTao commented on GitHub (Oct 19, 2026): These inconsistencies are easy to trip over in practice — a consumer keying on format to pick a parsing path gets different answers from different tools, and collapsed slice names hide the real arch layout of simulator binaries. +1 to the unified vocabulary (mach-o / mach-o-universal) and to surfacing exact slice names. One note on the platform decode: exposing a human-readable name is good, but keeping the numeric code as an additional field (as you propose) matters for existing consumers that switch on the raw value — making it additive avoids a breaking change. Also agree with keeping the detail=summary route given the payload size.

bsakaguchi commented

2026-10-31 00:37:38 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

I'd like to take this one, will follow up with a fix shortly. Plan: (1) unify the format vocabulary to a single source — thin = mach-o, fat = mach-o-universal — so open_binary/binary_session/inspect_macho agree; (2) decode LC_BUILD_VERSION platform to its name in the inspect_macho chain, keeping the numeric value in a new platform_code field for compatibility. I will explicitly stay away from the slice-name/arch-label part (tracked by #4293, PR #4359 in flight).

@akushonkamen commented on GitHub (Oct 19, 2026): I'd like to take this one, will follow up with a fix shortly. Plan: (1) unify the format vocabulary to a single source — thin = `mach-o`, fat = `mach-o-universal` — so `open_binary`/`binary_session`/`inspect_macho` agree; (2) decode `LC_BUILD_VERSION` platform to its name in the `inspect_macho` chain, keeping the numeric value in a new `platform_code` field for compatibility. I will explicitly stay away from the slice-name/arch-label part (tracked by #4293, PR #4359 in flight).

bsakaguchi commented

2026-10-31 00:37:38 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

Update: the fix is complete and pushed to akushonkamen/rea branch fix/5191-format-vocab-platform-decode (commit 1464701). It unifies the format vocabulary (inspect_macho now reports mach-o / mach-o-universal from lipo's thin/fat framing, matching open_binary/binary_session), names build platforms through one shared vocabulary on both the otool and pure-TS chains, and preserves the raw number in an additive platform_code field. The slice-name collapse part is intentionally left to #4293 / PR #4359.

I could not open the pull request: GitHub currently refuses pull-request creation for this account on this repository (the GraphQL createPullRequest mutation returns FORBIDDEN and the REST endpoint returns 404, retried over ~15 minutes, while the same account can still open PRs on its own fork). I'll try to open the PR as soon as the restriction clears; the full red→green verification notes are in the branch's commit message.

@akushonkamen commented on GitHub (Oct 19, 2026): Update: the fix is complete and pushed to [`akushonkamen/rea` branch `fix/5191-format-vocab-platform-decode`](https://github.com/akushonkamen/rea/tree/fix/5191-format-vocab-platform-decode) (commit 1464701). It unifies the format vocabulary (`inspect_macho` now reports `mach-o` / `mach-o-universal` from lipo's thin/fat framing, matching `open_binary`/`binary_session`), names build platforms through one shared vocabulary on both the otool and pure-TS chains, and preserves the raw number in an additive `platform_code` field. The slice-name collapse part is intentionally left to #4293 / PR #4359. I could not open the pull request: GitHub currently refuses pull-request creation for this account on this repository (the GraphQL `createPullRequest` mutation returns FORBIDDEN and the REST endpoint returns 404, retried over ~15 minutes, while the same account can still open PRs on its own fork). I'll try to open the PR as soon as the restriction clears; the full red→green verification notes are in the branch's commit message.

bsakaguchi commented

2026-10-31 00:37:38 +00:00

Author

Owner

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

Thanks for the update — the fix lands exactly along the lines discussed: unified format vocabulary plus an additive platform_code instead of replacing the raw number, which keeps existing consumers intact. Carrying the red→green verification notes in the commit message is a good trail. On the PR creation block: since the same account can still open PRs on its own fork, opening from akushonkamen/rea → morluto/rea usually works around a repo-level restriction — worth retrying now that some time has passed. Either way the branch is visible here, and keeping the slice-name part with #4293 / #4359 keeps the scope clean.

@XinwangTao commented on GitHub (Oct 20, 2026): Thanks for the update — the fix lands exactly along the lines discussed: unified format vocabulary plus an additive platform_code instead of replacing the raw number, which keeps existing consumers intact. Carrying the red→green verification notes in the commit message is a good trail. On the PR creation block: since the same account can still open PRs on its own fork, opening from akushonkamen/rea → morluto/rea usually works around a repo-level restriction — worth retrying now that some time has passed. Either way the branch is visible here, and keeping the slice-name part with #4293 / #4359 keeps the scope clean.

bsakaguchi commented

2026-10-31 00:37:38 +00:00

Author

Owner

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

Thank you for the detailed macOS report. The reported inconsistencies have been addressed on main: container framing now supplies mach-o-universal (cf3288d8c), subtype identity retains arm64e.x1 across consumers (0c49878b9), and the simulator platform codes are named by the native parser (#2065). I am closing the issue for those fixes. The optional request to expose the numeric platform alongside the normalized build-metadata value is separate and is not claimed as implemented; please feel free to reopen or file a focused follow-up if that field is still needed. #5254 remains open for its distinct selector and lipo handling. This assessment is from source and existing tests, not a new run on the reported Mac.

@morluto commented on GitHub (Oct 26, 2026): Thank you for the detailed macOS report. The reported inconsistencies have been addressed on main: container framing now supplies `mach-o-universal` (cf3288d8c), subtype identity retains `arm64e.x1` across consumers (0c49878b9), and the simulator platform codes are named by the native parser (#2065). I am closing the issue for those fixes. The optional request to expose the numeric platform alongside the normalized build-metadata value is separate and is not claimed as implemented; please feel free to reopen or file a focused follow-up if that field is still needed. #5254 remains open for its distinct selector and lipo handling. This assessment is from source and existing tests, not a new run on the reported Mac.

bsakaguchi referenced this issue

2026-10-31 01:08:54 +00:00

[PR #3356] test(cli): cover Frida argument admission and spawn ordering #5720

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

No description provided.

Rows
Columns