EBADMACHO
EBADMACHO is the Darwin program-loading error for a malformed Mach-O file. It is a structural diagnosis: the loader cannot safely interpret the image as the Mach-O object it is supposed to be. This differs from an architecture mismatch or an incompatible dynamic-library version, both of which can occur with an otherwise well-formed image.
For a 64-bit image, the Mach-O header begins with fields including the magic value, CPU type, file type, number of load commands, and total size of those commands. The load commands follow the header; each has a type and a size. XNU also specifies alignment and layout rules for these structures. Truncation, accidental binary patching, a bad extractor, or an incomplete deployment can make those fields or offsets inconsistent.
What this code is not
EBADARCHmeans the image does not provide a usable CPU architecture.ESHLIBVERSconcerns a dependent library’s compatibility-version test.- A code-signing or notarization rejection is a separate trust-validation question. Do not assume that every launch failure with a signature message is a malformed Mach-O image, or vice versa.
Safe diagnostic sequence
- Preserve the exact failing file and compute a hash before replacing or modifying it; compare it with the original build or package artifact.
- Run
file <path>andotool -l <path>. A parser failure or implausible load-command output is useful evidence; do not try to repair header bytes by hand. - Inspect every transferred, unpacked, or post-processed copy in the deployment chain. A valid source binary does not prove that the installed file is identical.
- After restoring a known-good artifact, validate the complete bundle and its libraries rather than testing only the top-level executable.
XNU marks some load commands as required for execution. If dyld encounters an unknown required command, it rejects the image instead of ignoring it. That is why the full header and load-command set matters, not just the first Mach-O magic bytes.