Mach-O Binary Analyzer
Parse and analyze Mach-O binary headers, FAT universal binaries, CPU architectures, load commands, segments, sections, and symbol tables — all in your browser. Supports 32-bit, 64-bit, and FAT (universal) Mach-O formats for macOS, iOS, and all Apple platform binaries. Free, private, and no signup required.
Why Use Our Mach-O Binary Analyzer?
Complete Mach-O Format Support
Parses all Mach-O variants including 32-bit (MH_MAGIC), 64-bit (MH_MAGIC_64), and FAT universal binaries (FAT_MAGIC). Automatically detects byte order (little/big endian) and handles both thin and multi-architecture binaries.
CPU Architecture Detection
Identifies all major Apple CPU architectures including arm64 (Apple Silicon), x86_64 (Intel 64-bit), i386 (Intel 32-bit), ARM, and PowerPC. Shows CPU type, subtype, and architecture-specific details with formatted descriptions.
Load Command & Segment Inspector
Parses all load commands (LC_SEGMENT, LC_SYMTAB, LC_UUID, LC_BUILD_VERSION, LC_MAIN, and 40+ more). Displays each segment with its sections, virtual addresses, file offsets, protection flags, and relocation entries in sortable tables.
100% Private - No Upload Required
All Mach-O parsing happens entirely in your browser. Upload a binary or paste hex data — nothing is sent to any server. No account, no signup, no tracking. Export analysis results via copy or download.
Common Use Cases for the Mach-O Analyzer
Malware Analysis & Reverse Engineering
Security analysts use the Mach-O analyzer to inspect suspicious macOS and iOS binaries. Detect if a binary is a FAT universal binary hiding multiple architectures, inspect load commands for unusual dylib dependencies, and examine section flags for suspicious permissions like writable+executable memory regions.
Binary Verification & Integrity Checks
Verify that a Mach-O binary has the expected CPU architecture, check for PIE (Position Independent Executable) flag, inspect code signature presence, and validate UUID matching. Essential for build pipeline verification and ensuring correct architecture targeting.
Debug Symbol & Stripping Analysis
Analyze whether a binary has been stripped by examining the symbol table size and load commands. Detect dSYM companion bundles, inspect nlist entries to identify remaining symbols, and determine if the binary has been code-signed and notarized.
Obfuscation & Protection Detection
Identify obfuscated or protected Mach-O binaries by detecting encrypted sections (LC_ENCRYPTION_INFO), checking for fairplay/DRM indicators, examining section attributes for unusual characteristics, and analyzing symbol table anomalies common in protected binaries.
macOS/iOS App Store Validator
Validate iOS and macOS app binaries before App Store submission. Check for required architectures (arm64 for iOS, arm64 + x86_64 for macOS universal binaries), verify correct CPU subtype, and inspect minimum OS version requirements across Mach-O slices.
Mach-O Format Education & Research
Students and researchers can explore the Mach-O file format interactively. Load example binaries to see how the Mach-O header structure works, understand load command chains, explore segment/section relationships, and learn about nlist symbol table entries.
Understanding the Mach-O Binary Format
What is a Mach-O Binary?
Mach-O (Mach Object) is the native executable format used by macOS, iOS, iPadOS, watchOS, and tvOS. It replaced the older a.out format and is the standard binary format for all Apple operating systems. Every app, framework, library, and command-line tool on Apple platforms is packaged as a Mach-O binary. The format supports multiple CPU architectures in a single file through the FAT (Universal) binary format, using the magic number 0xCAFEBABE. Mach-O files contain a header, a chain of load commands describing the binary's structure, and the actual segment data (code, data, symbol tables, etc.).
How the Mach-O Analyzer Works
- Input detection: the analyzer reads the first 4 bytes (magic number) to determine the format — 32-bit (0xFEEDFACE), 64-bit (0xFEEDFACF), or FAT universal (0xCAFEBABE) — and detects the byte order (little-endian for Apple Silicon/Intel, big-endian for PowerPC).
- Header parsing: the Mach-O header is parsed to extract CPU type, CPU subtype, file type (executable, dylib, bundle, object, etc.), number of load commands, and binary flags (PIE, NOUNDEFS, TWOLEVEL, etc.).
- Load command traversal: the analyzer walks the load command chain, parsing each command based on its type. Segment commands (LC_SEGMENT/LC_SEGMENT_64) contain sub-tables of section information. Other commands provide UUID, version minimums, symbol table references, code signature offsets, and more.
- Symbol table extraction: if the binary has an LC_SYMTAB command, the analyzer reads nlist entries (struct nlist_64 for 64-bit) and resolves symbol names from the string table. The first 50 symbols are displayed with their type, section number, description flags, and address values.
Key Concepts in Mach-O
- FAT Binary (Universal): starts with 0xCAFEBABE magic, containing multiple Mach-O slices for different architectures. Each slice has its own CPU type, offset, size, and alignment. iOS apps typically have arm64 slices; macOS universal binaries have x86_64 + arm64 for both Intel and Apple Silicon.
- Load Commands:immediately follow the Mach-O header and describe the binary's layout. LC_SEGMENT defines memory regions mapped from the file; LC_SYMTAB points to the symbol table; LC_UUID provides a unique identifier; LC_BUILD_VERSION specifies target platform and SDK version.
- Segment & Sections: segments (__TEXT, __DATA, __LINKEDIT) map directly to memory regions. Sections within segments (__text, __cstring, __objc_methlist) contain specific types of content. Section type flags indicate whether a section contains code, string literals, symbol pointers, or initializers.
- nlist Symbol Entries: each symbol in the symbol table has a name (resolved through the string table), type (undefined, absolute, section-defined, or indirect), section number, description flags, and value/address. External symbols are marked with N_EXT for dynamic linking resolution.
Privacy & Technical Limitations
The Mach-O analyzer processes all binary data entirely in your browser using JavaScript. No data is ever uploaded to any server. The analyzer parses the header, load commands, segment/section structures, and symbol table — but does not disassemble executable code, decompress protected binaries, or decrypt encrypted Mach-O files. Binaries with FairPlay DRM (App Store encrypted) will show encryption information but cannot have their code sections read. For very large binaries (over 500 MB), parsing may be limited by browser memory constraints. The analyzer is designed for educational use, reverse engineering research, and security analysis of files you have legal authorization to inspect.
Frequently Asked Questions About Mach-O Binary Analysis
Mach-O (Mach Object) is the native executable format for Apple operating systems (macOS, iOS, watchOS, tvOS), while ELF is used on Linux and Android, and PE (Portable Executable) is used on Windows. Mach-O uses the magic numbers 0xFEEDFACE (32-bit), 0xFEEDFACF (64-bit), and 0xCAFEBABE (FAT universal binary). Key differences include the FAT binary format supporting multiple architectures in one file, the load command chain structure, and the nlist symbol table format. Apple transitioned from 32-bit to 64-bit with the iPhone 5s (arm64) and has since deprecated all 32-bit iOS app support.
The easiest way is to check the first four bytes (magic number). Mach-O 32-bit starts with 0xFEEDFACE, Mach-O 64-bit starts with 0xFEEDFACF, and FAT universal binaries start with 0xCAFEBABE. You can also check the file extension: .o (object files), .dylib (dynamic libraries), .bundle (loadable bundles), or no extension for executables. On macOS, the file command in Terminal can also identify Mach-O files. Our analyzer automatically detects and reports the format when you upload or paste a binary.
A FAT (Universal) binary contains multiple Mach-O executables for different CPU architectures in a single file. The FAT header lists each architecture with its CPU type, offset, size, and alignment. When the operating system loads the binary, it automatically selects the appropriate architecture slice for the current CPU. This allows developers to distribute a single binary that runs natively on both Intel (x86_64) and Apple Silicon (arm64) Macs. iOS apps targeting the App Store typically contain only arm64, while macOS apps are increasingly shipping as universal binaries.
Segments are major memory regions mapped from the binary: __TEXT contains executable code and read-only data, __DATA contains read-write data, __LINKEDIT contains linker metadata (symbol tables, string tables), and __PAGEZERO is a guard page that catches NULL pointer dereferences. Sections within segments have specific purposes: __text contains executable instructions, __cstring holds C string literals, __objc_methlist contains Objective-C method lists, __const stores constant data, __bss holds uninitialized static variables, and __stubs contains dynamic linker stub code.
A stripped binary will have a very small or empty symbol table (LC_SYMTAB with few symbols), while a debug build will have hundreds or thousands of named symbols. Check for LC_ENCRYPTION_INFO with cryptid != 0, which indicates the binary is encrypted (common for App Store apps with FairPlay DRM). Suspicious flags include ALLOW_STACK_EXECUTE (writable + executable stack) and unusual segment/section names. Obfuscated binaries may have renamed section names, obfuscated symbol names starting with special characters, or unusual load commands that differ from standard Apple toolchain output.
The symbol table (parsed from LC_SYMTAB) lists all symbols in the binary with their names (resolved from the string table), types (undefined, absolute, section-defined, or indirect), section associations, description flags, and address values. External symbols (marked N_EXT) are resolved by the dynamic linker at load time. The symbol table is essential for debugging, reverse engineering, and understanding library dependencies. In stripped binaries, most symbols are removed but dynamic symbol entries remain for external function calls.
LC_BUILD_VERSION specifies the target platform (macOS, iOS, tvOS, watchOS, driverKit, etc.), minimum OS version required to run the binary, the SDK version it was built against, and the tool versions used (clang, swift, ld). This information is crucial for compatibility checking: a binary compiled with a minimum macOS 13.0 deployment target will not run on macOS 12.x. The tool versions can also help identify which Xcode version was used to build the binary.
The Mach-O analyzer focuses on parsing the header structure — CPU architecture, load commands, segment layouts, section details, and symbol tables. It does not extract embedded files, disassemble code, or decompile the binary. For extracting embedded resources (like Info.plist, nib files, or asset catalogs), you would need additional tools. However, the analyzer does detect the presence of __cstring sections (string literals), Objective-C class information, and Swift runtime metadata sections.
Absolutely. The Mach-O analyzer processes all binary data entirely in your browser using JavaScript. The binary you upload or paste is never sent to any server — all parsing, analysis, and display happens locally on your device. No account is required, no data is stored, and no tracking occurs. You can safely analyze proprietary binaries, confidential applications, or any Mach-O files without privacy concerns. The results can be copied as a text report for offline use.
Yes — 100% free with no signup, no account, and no usage limits. All features including file upload, hex input, FAT binary analysis, load command parsing, segment/section inspection, and symbol table extraction are available without any restrictions. There are no premium tiers, hidden charges, or rate limits. The tool runs entirely client-side with no server dependencies.