MachOExplorer turns a Mach-O binary into a tree you can walk

One window from file header down to individual bytes

The problem is that a Mach-O file is a nested structure with several unrelated vocabularies stacked on top of each other, and the usual tools expose one layer at a time. MachOExplorer presents the file as a navigable tree instead. The README describes it as a focused desktop explorer for Mach-O binaries, Fat and Universal binaries, .a archives and the dyld shared cache, built for people who reverse engineer and inspect Apple binaries. The layout tree goes file to header to load commands to sections, symbols and link-edit data, and a search box filters that tree by node name and also matches the contents of tables you have already opened. The hex view stays in sync with the selected node, so you can jump from any table row to the exact bytes behind it. That link between a parsed structure and its raw bytes is the part that makes it a tool for inspection rather than a viewer.

The Apple-specific layers are the reason to use it at all

The feature list is where the project justifies itself, and most of it is metadata that a generic hex editor cannot decode. It covers load commands, sections, symbol and string tables, relocations, indirect symbols, function starts and data-in-code. On top of that it parses the embedded code signing SuperBlob, meaning the Code Directory, the Requirements and the CMS signature, and it decodes the entitlements plist. The Objective-C metadata is broken down into classes, methods, ivars, properties and protocols, and the Swift support is a semantic graph built over the __swift5_* sections. The dyld info section covers the rebase, bind, lazy-bind and exports trie structures along with chained fixups. A cross-reference report resolves call and jump targets and ties them back to symbols, which is the feature that turns a static listing into something you can navigate by behaviour rather than by name.

Four input formats, and one of them is a multi-gigabyte directory

The supported formats table is short and the fourth row is the interesting one. Mach-O is supported in both 32-bit and 64-bit, Fat and Universal binaries with multiple architecture slices are supported, static archives are supported as .a files with Mach-O members, and the dyld shared cache can be listed, extracted and inspected image by image. The shared cache is what makes the performance work necessary. On a current macOS installation that cache holds most of the system frameworks, and the README makes the responsiveness claim as a design constraint rather than a feature: parsing runs off the UI thread, so opening a large binary or a multi-gigabyte shared cache keeps the window responsive. The shared cache handling includes listing images, extracting a single image or all of them, and drilling straight into an extracted image once it is on disk.

Installing on macOS is a cask, and on Linux or Windows it is a build

The install section splits the platforms, and the split is worth knowing before you plan around it. On macOS you can download the latest release from GitHub or install through Homebrew, and the README gives the exact cask command:

brew update && brew tap everettjf/homebrew-tap && brew install --cask machoexplorer

@@C1@@On Linux and Windows there are no prebuilt binaries. The README says prebuilt macOS releases are published on GitHub, and that on Linux and Windows you build from source, with a note that the Linux build and the full regression suite run in CI on every change. The Windows route is a build_macos.sh-style script per platform, with build_linux.sh, build_macos.sh and build_windows.bat all at the repository root. The practical consequence is that a Linux or Windows user who just wants to look at one binary has to install a Qt toolchain first, which is a much larger step than a cask install.

A headless mode that prints the whole analysis as JSON

The automation mode is the feature that changes how you would use the tool in a pipeline, and it is a first-class mode rather than an export button. The README shows the headless invocation writing the analysis to stdout or to a file, in text or in what it calls stable JSON:

./build/MachOExplorer --cli sample/simple
./build/MachOExplorer --cli --format json --output /tmp/simple-analysis.json sample/simple

@@C2@@The option table is where the practical value is. You can limit rows per table with --max-rows, where 0 means unlimited, limit the tree depth with --max-depth, also with 0 for unlimited, and export only one matching subtree with --root-path, which is how you would pull a single load command out of a large file. --name-filter keeps nodes whose display names match, --table-mode controls table payload size with full, headers or summary, and --include-empty pulls in nodes that would otherwise be dropped. The JSON is described as automation-friendly and stable, and it carries a schemaVersion field alongside a summary, node path, kind and childIndex, and row cells with a rowIndex, and string values are sanitised to valid UTF-8 so the output stays well-formed even when the input is malformed. The full guide is in CLI.md, which has a Chinese translation alongside the English README and CLI guide.

The parser is written to survive a hostile file

A tool whose job is opening binaries that may be malformed has one job it cannot get wrong, and the README devotes a section to it. The parser is bounds- and alignment-checked throughout, with the named areas being LEB128 streams, load-command walking, string tables and code-signature blobs. There is a malformed-input crash-regression suite that runs against truncated and fuzzed binaries, and the stated behaviour is that opening a hostile or corrupted file degrades gracefully instead of crashing. That is a meaningful design constraint for a reverse engineering tool, because the files people most want to look at are often the ones someone else produced badly. The repository layout backs it up, with a tests/ directory, an AGENTS.md, a DEVELOP.md developer guide and a scripts/ directory, and the contributing section asks you to build the project and run tests/regression/run_all.sh before opening a pull request.

Disassembly is optional, and the build is CMake and Qt 6

The build requirements are stated precisely, and the disassembly is the optional part. You need CMake 3.16 or newer, Qt 6 with the Core, Gui, Widgets, Network and Concurrent modules, a C++14 compiler, and optionally Capstone for disassembly. The disassembly itself is described as optional Capstone disassembly of __TEXT,__text for arm64, x86_64, arm and i386, so a build without Capstone gives you everything except the instruction listing. The macOS build command passes a CMAKE_PREFIX_PATH pointing at your Qt installation, and the Linux notes list the Debian and Ubuntu packages qt6-base-dev, libgl1-mesa-dev and libcapstone-dev. The project is MIT licensed with the LICENSE file at the root, the primary language in the repository is C++, and the recent tags are v2.0.16, v2.0.15 and v2.0.14, all dated 2026-03-13, with the last push to the repository on 2026-10-06.

Editorial conclusion

MachOExplorer suits a reverse engineer or systems programmer on macOS who wants to open a binary and walk it interactively rather than write a script for each question, and who wants the same view available on Linux and Windows. It does not suit a build server that needs a stable programmatic API, because the CLI output is documented as stable but is one entry point in a project whose version moves often, and it does not suit someone who wants a disassembly without installing Capstone, since the README lists that as optional. Before adopting, install it on macOS from the Homebrew cask or the release page, and note that the last push to the repository was on 2026-10-06 with the newest tagged release v2.0.16 from 2026-03-13.

Frequently asked questions

Official sources

1. everettjf/machoexplorer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases