Overview
There are two broad ways to analyze a binary: study it without running it (static analysis) or watch it while it runs (dynamic analysis). Each reveals different things and carries different risks. Skilled analysts combine both. This lesson explains the two approaches, the tools associated with each, and their tradeoffs — all within authorized, isolated practice where any execution happens safely.
Learning objectives
- Distinguish static analysis from dynamic analysis.
- Match tools to each approach: disassembler/decompiler versus debugger/tracer.
- Explain the tradeoffs of each approach.
- Decide when to use one, the other, or both.
Core concept
Static analysis examines a program without executing it. You read the bytes, the strings, the disassembly, and the reconstructed logic to understand what the program would do. Because nothing runs, it is inherently safe and lets you see the whole program at once — including paths that only trigger under specific conditions.
Dynamic analysis examines a program while it runs, observing real behavior: what it prints, which functions it calls, how values in memory change, what files or network connections it touches. It shows what actually happens, including behavior that is hard to reason about statically, but it requires running the code — which must only ever be done in an isolated sandbox (the next lesson).
Neither is strictly better; they answer different questions.
How it works
Static analysis tools:
strings/ file inspectors — quick triage of literal text and format (from earlier lessons).- Disassembler — translates machine code back into human-readable assembly instructions, so you can read the program's logic instruction by instruction.
- Decompiler — goes a step further, reconstructing an approximate high-level (C-like) version of the code, which is far easier to read than raw assembly. The reconstruction is an approximation, not the original source.
Dynamic analysis tools:
- Debugger — runs the program under your control: you set breakpoints, pause execution, step one instruction at a time, and inspect or change registers and memory. Ideal for watching the deciding branch as it happens.
- Tracers — record events during execution, such as which library or system calls the program makes, giving a behavioral summary without full manual stepping.
A common workflow: use static analysis to locate the interesting code (say, the password comparison), then attach a debugger dynamically, set a breakpoint at that comparison, and read the expected value straight out of memory as the program prepares to compare it.
Practical example
Imagine a challenge binary that decodes its secret at runtime, so strings shows nothing useful and the static disassembly only shows a decoding routine rather than a readable password.
- With static analysis alone, you could still read the decode routine and work out the algorithm by hand — accurate but potentially slow.
- With dynamic analysis, you run the binary in a sandbox under a debugger, set a breakpoint right after the decoding step, and simply read the now-decoded secret sitting in memory. Fast and direct.
This is the classic tradeoff in action: static gave you the complete picture safely but demanded manual effort; dynamic gave you the concrete value quickly but required (safe, isolated) execution. Using both — static to find where, dynamic to grab the value — is usually the most efficient path.
Cybersecurity relevance
The static/dynamic split is fundamental to malware analysis and vulnerability research. Analysts start statically because it is safe and gives an overview, then move to dynamic analysis in a controlled sandbox to confirm behavior that is obfuscated or only appears at runtime. Some malware actively resists one approach — packing or encrypting code to defeat static reading, or detecting debuggers and sandboxes to defeat dynamic observation — which is exactly why analysts need both in their toolkit. Understanding the tradeoffs helps you choose an efficient, safe strategy and recognize when a binary is fighting back.
Common mistakes
- Relying on only one approach. Static misses runtime-only behavior; dynamic misses untriggered paths.
- Running a binary to analyze it without a sandbox. Dynamic analysis of unknown code must happen in isolation (next lesson).
- Trusting decompiler output as exact source. It is a helpful approximation, not the original code.
- Manually reversing a decode routine when a breakpoint would hand you the value instantly (or vice versa — running when reading would have been safer/simpler).
Key takeaways
- Static analysis reads a program without running it (disassembler, decompiler,
strings); it is safe and complete but can be labor-intensive. - Dynamic analysis observes a program as it runs (debugger, tracer); it reveals real, runtime-only behavior but requires safe, isolated execution.
- The approaches are complementary: static to find where the interesting logic is, dynamic to observe or extract concrete values.
- Choose based on the question you are answering, and always run unknown code only in a sandbox.
Check your understanding
- What is the core difference between static and dynamic analysis, and what tool typifies each?
- Why might you use static analysis to locate a comparison but dynamic analysis to read the value being compared?