We are looking for a supported way to establish an independent byte-level reference for two Apple-supplied executables: /bin/df and /usr/bin/codesign. This is a provenance inquiry, not an allegation of tampering or a known Apple defect.
The Apple Developer OS download catalog lists macOS 27.0.1, build 26A434, released September 28, 2026, and links to this Apple silicon restore image:
https://updates.cdn-apple.com/2026FallFCS/59241290-5d51-4ca8-9df4-31624b9a4eac/UniversalMac_27.0.1_26A434_Restore.ipsw
We have saved whole-file lengths and SHA-256 observations from earlier local reads. Different observations had different whole-file digests. A separate historical OS version record identifies 26A434, but it is not contemporaneous with every file observation, so we use this build only as a candidate reference, not as an established build for every sample. The historical device context is Apple silicon / Mac18,5. No new machine inspection is requested or implied here.
Questions:
- Does Apple publish, or have a supported way to obtain, authenticated whole-file byte lengths and SHA-256 values for these exact two paths in the 26A434 Apple silicon distribution? Please specify the applicable architecture and file representation.
- If not, is there a supported read-only procedure to authenticate the exact restore asset and extract these two complete files as a comparable reference, without installing or restoring macOS? What checks establish the build, model applicability and integrity of the extracted content?
- Are there documented transformations during installation, personalization or architecture selection that could make a valid installed file differ byte-for-byte from the corresponding restore-image file? If so, what comparison is supported without silently changing a whole-file-equality requirement?
We understand from TN2206 and TN3126 that architectures in universal binaries are signed independently and that removing an architecture can preserve signature validity. A valid signature or CDHash is therefore not being treated as a substitute for our whole-file SHA-256 observations. Likewise, a checksum for the complete IPSW would not itself be the checksum of either executable.
The intended comparison must not rely solely on the previously observed local codesign executable whose own whole-file binding changed. We are seeking a supported independent reference or verification method; we are not asking to disable Gatekeeper, SIP, authenticated-root protection, modify trust settings, re-sign system executables, or infer the cause of the historical differences.
No system image has been downloaded or mounted for this inquiry. No passwords, account identifiers, keychain contents, private keys, logs, or attachments are included.
References:
https://developer.apple.com/download/os/
https://developer.apple.com/library/archive/technotes/tn2206/
https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes
https://support.apple.com/guide/security/signed-system-volume-security-secd698747c9/web