You have an application binary—maybe a legacy utility, maybe something you suspect isn't behaving as advertised—and you want to see what it actually does. You drop it onto Hopper Disassembler. Within seconds, the file is laid out in a control-flow graph, assembly instructions colour-coded and cross-referenced, ready to be read like a map of its own logic.
Hopper is a reverse-engineering environment built specifically for macOS, written in Cocoa so it feels at home on the desktop. It disassembles x86_64 and ARMv7 binaries, then goes a step further by decompiling them into readable C-like pseudo-code—a rare bridge between raw instructions and human understanding. The debugging side talks to GDB, letting you step through a running process while the graph highlights the path taken.
This is a tool for security researchers picking apart malware, for developers chasing a crash inside a closed-source library, and for students learning how compilers translate high-level ideas into machine code. It doesn't wrap the complexity in wizards; it presents the data clearly and lets you follow the branches yourself.
Switch to Intel syntax for instant readability
Out of the box, Hopper defaults to AT&T assembly syntax. If your brain parses Intel syntax more comfortably—and many people's does—switch it immediately under View > Assembly Syntax > Intel. The difference is night and day for readability, especially when you are cross-referencing with Intel manuals or online resources that favour the mov eax, 1 style over the percentage-sign dialect.
A second stop: the decompiler preferences. Hopper's pseudo-code generator is good, but its verbosity is adjustable. Ticking Show stack variables as local variables gives you cleaner output that reads closer to actual C. While you are there, enable Show most relevant function signature—it pulls type information from the binary's imported symbols and saves you from staring at generic int arg1, int arg2 where a const char *path should have been.
Quiet conveniences hiding in plain sight
The navigation bar at the top of the main view accepts more than addresses. Type a function name, even a partial one, and Hopper jumps to it instantly. Press G to bring up that go-to field from anywhere. Less obvious: the X key, pressed while hovering over a symbol, lists every cross-reference to it across the entire binary—callers, data reads, jump targets—in a single popover. It turns tracing a parameter through a maze of calls into something you can do in a few keystrokes.
The procedure graph view has a small but mighty feature tucked into its right-click menu: Detect loops. Hopper analyses the control-flow graph and highlights the loop bodies with a soft background tint, so the boundaries between a loop header, its inner block, and the exit path become visually distinct without any manual annotation. When you are staring at a function that spans three screens, that highlight alone can cut the reading time down considerably.
Finding procedures in stripped binaries
One question that surfaces often is whether Hopper handles binaries stripped of symbols. It does—and its analysis of function prologues means it can identify procedure boundaries and local variable slots even when the symbol table is gone. The decompiler will still give you pseudo-code, though the names will be generic. What gets lost is the easy navigation; you end up working with sub_1000012c0 instead of -[NSView drawRect:], which is where the cross-reference tool becomes indispensable for rebuilding context manually.
People also ask whether the ARM support covers Apple Silicon properly. Hopper runs natively on Apple Silicon and disassembles ARMv7 and ARM64 binaries, including Mach-O executables compiled for iOS or modern macOS. The decompiler handles ARM64 instruction sequences gracefully, translating the load/store pairs and conditional branches into pseudo-code that does not feel like a register-renaming puzzle.
- macOS 11 or later
- Apple Silicon Mac
Questions from the booth
It handles x86_64 and ARMv7 binaries, covering modern Mac hardware and a range of embedded or legacy Unix software.
Yes. Its decompiler produces C-like pseudo-code from disassembled routines, giving you a structural view of the logic without needing to interpret every instruction.



