Static binary analysis isn’t a spectator sport. You’re not just reading code—you’re dissecting compiled flesh, hunting for malformations, backdoors, and the subtle fingerprints of a compiler that lied. I’m Zel Mathis, and I’ve spent more nights than I’d like to admit staring at hex dumps and control-flow graphs, trying to figure out what some black-box firmware is really doing. The right tools make the difference between a clean extraction of truth and a week lost in false positives. Here’s what actually works.
Why Static Binary Analysis Matters
When you can’t run the binary—maybe it’s for an embedded device you don’t own, or it’s malware you’re not insane enough to execute—static analysis is your only window. Even when you can run it, dynamic analysis shows you one path. Static analysis shows you all possible paths. That’s the theory, anyway. In practice, you’re wrestling with stripped symbols, obfuscated control flow, and instruction sets that make your eyes bleed. The tools you pick determine whether you’ll find the hidden command-and-control loop or just generate a 200MB PDF of worthless call graphs.
I’ve spent years in the weeds with firmware extraction, reverse engineering, and vulnerability research. The tools below aren’t the shiniest or the most marketed. They’re the ones that don’t crash when you feed them a 40MB monolithic ARM binary, the ones that let you script your way out of a corner, and the ones that actually teach you something about the code you’re dissecting.
Disassemblers: The Foundation
Without a disassembler, you’re reading raw bytes. That’s a special kind of masochism. A good disassembler doesn’t just translate opcodes—it builds a mental model of the binary’s layout, resolves cross-references, and gives you a canvas for annotation. The two that dominate the underground are IDA Pro and Ghidra, but they serve different masters.
IDA Pro: The Old King
IDA Pro is the standard for a reason. Its interactive interface, mature scripting engine, and vast processor support make it the go-to for professional reverse engineers. The FLIRT signature database can identify library functions in stripped binaries, saving you from reversing memcpy for the hundredth time. The decompiler plugin (Hex-Rays) is expensive but often worth it—it turns assembly into pseudo-C that’s surprisingly readable, especially after you’ve spent a few hours teaching it function prototypes and structure definitions.
But IDA has warts. It’s proprietary, expensive, and its plugin ecosystem is a walled garden. The Python API is powerful but quirky, and you’ll find yourself fighting with type systems when you just want to iterate over basic blocks. For large binaries, the analysis can be slow, and the database files balloon to gigabytes. Still, when I need to deeply understand a binary’s logic, IDA is where I live.
Ghidra: The Open-Source Contender
Ghidra came out of the NSA in 2019 and immediately changed the game. It’s free, open-source, and its decompiler rivals Hex-Rays in many cases—sometimes surpassing it, especially on weird calling conventions or obfuscated code. The collaborative server mode lets multiple analysts work on the same binary simultaneously, which is a godsend for large firmware dumps. Ghidra’s scripting is Java-based, which feels clunky compared to IDA’s Python, but the API is well-designed and you can do serious automation with it.
Where Ghidra really shines is in its analysis of non-standard architectures. I’ve thrown obscure DSP firmware at it and watched it correctly identify function boundaries that IDA missed. The learning curve is steeper—the UI is dense and the terminology is idiosyncratic—but once you internalize its mental model, you can work fast. For anyone starting out or working on a budget, Ghidra is the obvious choice.
Binary Ninja: The Middle Ground
Binary Ninja occupies a sweet spot between IDA’s power and Ghidra’s accessibility. It’s commercial but reasonably priced, with a clean, modern UI and a Python API that feels thoughtfully designed rather than bolted on. Its intermediate language (IL) representation is a standout feature—you can write analysis scripts that work across x86, ARM, MIPS, and PowerPC without rewriting architecture-specific logic. The decompiler is good and improving rapidly, and the plugin ecosystem is small but high-quality.
I reach for Binary Ninja when I need to prototype an analysis quickly or when I’m working with a team that needs a gentler learning curve than Ghidra. Its type system and structure recovery are intuitive, and the graph view is the best of any tool I’ve used. The main limitation is architecture support—it covers the majors but lacks the esoteric DSPs and microcontrollers that IDA handles. For mainstream reverse engineering, though, it’s a joy to use.
Specialized Analysis Engines
Disassemblers give you the raw material. Specialized tools help you ask specific questions: Does this binary contain known vulnerable code patterns? What are the actual import dependencies? Where are the crypto constants hiding? These tools don’t replace your brain—they amplify it.
Radare2 / Rizin: The Scriptable Workhorse
Radare2 (and its community fork Rizin) is the command-line powerhouse. It’s not pretty, but it’s fast, scriptable, and can chew through binaries that make IDA choke. I use it for batch analysis—pulling strings, identifying crypto constants, extracting entropy data, and doing initial triage on hundreds of firmware images. The learning curve is a cliff face, but once you’ve internalized the command syntax, you can pipe analysis results into Python or your own toolchain with minimal friction.
Rizin is the cleaner, more modern fork that fixes many of radare2’s historical UI and stability issues. It’s the one I recommend for new users. The rz-ghidra plugin brings Ghidra’s decompiler into Rizin, giving you a powerful free command-line decompiler. For automated binary analysis pipelines, Rizin is hard to beat.
angr: Symbolic Execution for the Brave
angr is a Python framework for binary analysis that includes a symbolic execution engine. It lets you ask questions like “What input reaches this basic block?” or “Is there any path from this function to that sensitive system call?” It’s not a tool you use casually—setting up an angr analysis requires real programming and a deep understanding of the binary’s logic. But when you need to automatically explore state spaces that are too large for manual analysis, angr is unmatched.
I’ve used angr to find authentication bypasses in embedded web servers and to generate inputs that trigger hidden debug modes. It’s slow, memory-hungry, and the learning curve is brutal. But it solves problems that no other tool can touch. If you’re doing vulnerability research on complex binaries, angr belongs in your arsenal.
Binary Diffing: Finding the Needle
When a vendor silently patches a vulnerability, you need to know what changed. Binary diffing tools compare two versions of a compiled binary and highlight the differences—new basic blocks, modified functions, changed constants. This is how you find the fix and then reverse-engineer the original bug.
Diaphora: IDA’s Diffing Plugin
Diaphora is a plugin for IDA Pro that performs binary diffing at multiple levels: raw bytes, assembly instructions, basic blocks, and pseudo-code. It’s fast, free, and the output is a searchable database that lets you filter by similarity percentage, function name, or specific instruction patterns. I use it to track changes across firmware versions and to identify borrowed code between different vendors’ products. The pseudo-code diffing is particularly useful—it can spot semantic changes that raw assembly diffing misses.
BinDiff: The Commercial Standard
BinDiff (now owned by Google, distributed as a free IDA plugin) is the other major player. It uses a more sophisticated graph-theoretic approach to function matching, which can be more resilient against compiler changes and optimization differences. BinDiff’s visual diff mode is excellent for quickly understanding how a function’s control flow changed. I tend to use both Diaphora and BinDiff on the same binary pair—they catch different things, and the combination gives a more complete picture.
Unpacking and Deobfuscation
Malware and DRM-protected binaries rarely come in the clear. Packers, cryptors, and obfuscators wrap the real code in layers of garbage. Static analysis of a packed binary is a waste of time—you need to strip the armor first.
Detect It Easy (DIE): Packer Identification
Before you can unpack, you need to know what you’re dealing with. DIE is a signature-based tool that identifies packers, compilers, and cryptors. It’s more comprehensive than the old PEiD and is actively maintained. DIE gives you entropy graphs, section analysis, and heuristic detection that often nails the exact packer version. It’s the first thing I run on an unknown sample.
UnpacMe: Automated Unpacking
UnpacMe is an online service that automates unpacking for many common packers. You upload a sample, it runs it through a gauntlet of unpacking engines, and returns the unpacked binary. It’s not perfect—custom packers and advanced obfuscation will defeat it—but for commodity malware, it saves hours of manual unpacking. The service is free for small files and has an API for batch processing.
String Analysis and Pattern Matching
Strings are the lowest-hanging fruit in static analysis. A binary’s strings can reveal URLs, IP addresses, registry keys, file paths, and even embedded scripts. But standard strings misses Unicode, misses XOR-obfuscated strings, and gives you no context. Better tools exist.
flare-floss: Strings with Brains
FLOSS (FireEye Labs Obfuscated String Solver) is a must-have. It extracts ASCII and Unicode strings like the standard tool, but also statically deobfuscates strings that are built at runtime—XOR loops, stack constructions, and simple decryption routines. It works on Windows, Linux, and macOS binaries. I’ve found C2 addresses and decryption keys that the standard strings command completely missed. FLOSS also provides a “tight strings” score that helps you focus on the most likely interesting strings, filtering out compiler noise.
YARA: Pattern Matching for Binaries
YARA is a rule-based pattern matching engine. You write rules that describe byte sequences, strings, or regular expressions, and YARA scans binaries for matches. It’s the backbone of malware classification and threat intelligence sharing. I use YARA to identify known code families, to find embedded cryptographic constants, and to flag binaries that contain specific vulnerable code patterns. Writing good YARA rules is an art—too specific and you miss variants, too broad and you drown in false positives. But once you have a solid rule set, it’s like having a metal detector in a minefield.
Control Flow and Call Graph Analysis
Understanding how functions relate to each other is essential for reverse engineering. A flat disassembly listing is nearly useless for large binaries—you need to see the call graph, identify clusters of related functions, and spot anomalies like functions that are never called or that call into suspicious APIs.
Gephi + IDA/Ghidra Export: Visualizing the Graph
Both IDA and Ghidra can export call graphs, but their built-in visualization is limited. I export the graph data and load it into Gephi, an open-source graph visualization tool. Gephi lets you apply force-directed layouts, size nodes by centrality, and color by modularity class. This reveals the binary’s architecture at a glance—you can see the main loop, the initialization routines, the network handlers, and any disconnected “islands” of code that might be injected or obfuscated. It’s a technique I picked up from malware analysts and it’s saved me days of manual graph tracing.
FAQ
Which tool should I learn first for static binary analysis?
Start with Ghidra. It’s free, powerful, and has an excellent decompiler. The learning curve is real, but there are plenty of tutorials and the community is active. Once you’re comfortable with Ghidra, you’ll appreciate IDA Pro’s polish and Binary Ninja’s speed, but you won’t be lost without them. If you’re on a budget and need to do real work, Ghidra is the answer.
Can static analysis find all vulnerabilities?
No. Static analysis can find many bug classes—buffer overflows, use-after-free patterns, hardcoded credentials, missing bounds checks—but it can’t find everything. Logic flaws that depend on runtime state, vulnerabilities in dynamically generated code, and issues that only manifest under specific environmental conditions often require dynamic analysis or manual code review. Static analysis is a filter, not a guarantee.
How do I handle heavily obfuscated binaries?
Start with packer identification (DIE) and automated unpacking (UnpacMe). If those fail, you’re in for manual unpacking—find the original entry point, dump the process memory, and rebuild the import table. For code-level obfuscation like control-flow flattening or opaque predicates, Ghidra’s decompiler often cuts through the noise better than IDA’s. In extreme cases, you may need to write custom scripts using angr or a disassembler API to deobfuscate specific patterns. There’s no silver bullet—obfuscation is an arms race.
What’s the best way to analyze firmware blobs?
First, extract the filesystem with binwalk or unblob. Then identify the architecture—DIE can help, or you can look for telltale opcode patterns. Load the main binary into Ghidra or IDA, but be prepared for a stripped binary with no symbols. Use FLOSS to pull strings, YARA to identify known code, and Gephi to map the call graph. Firmware analysis is mostly about persistence and pattern recognition—the tools help, but experience is what gets you through.
The tools I’ve described are my daily drivers. They’re not the only ones, and they’re not always the best for every situation. But they’re the ones that have earned their place on my hard drive through years of actual use. Static binary analysis is a craft—the tools are your instruments, but your brain is the one making the music. Pick tools that respect your intelligence and don’t get in your way.
