Static reversing examines a binary without executing it, using disassemblers, metadata, and string extraction to understand structure and intent. Dynamic reversing observes the sample while it runs, focusing on process behaviour, filesystem activity, network connections, and runtime changes. Strong macOS analysis usually blends both approaches because static review explains what the code can do, while dynamic review shows what it actually does.
How static reversing differs from dynamic reversing on macOS
Static reversing stays at the binary and artefact level. On macOS, that means inspecting Mach-O structure, symbols, strings, embedded entitlements, Info.plist values, import tables, and decompiled logic to infer what a program can do. It is the best way to map capabilities, hidden features, and suspicious code paths before execution.
Dynamic reversing adds runtime observation. You run the sample in a controlled environment and watch how it behaves: processes it spawns, files it touches, sockets it opens, APIs it calls, and whether it mutates memory or downloads additional payloads. That makes it better for confirming actual behaviour, especially when code is obfuscated or conditional.
On macOS, the distinction matters because many behaviours are easier to see in one mode than the other. Static analysis is stronger for unpacking architecture, reviewing Objective-C or Swift metadata, and spotting suspicious strings or imported frameworks. Dynamic analysis is stronger for observing TCC prompts, sandbox interaction, persistence attempts, launch agents, AppleScript use, and any activity that only appears after launch.
What each approach tells you on a Mac
Static reversing answers questions about intent and capability. You can see whether a binary contains routines for credential theft, persistence, browser inspection, or code injection even if those routines never execute during a quick test run. It is also useful when a sample checks for a VM, a debugger, or a specific hostname before it unlocks its full logic.
Dynamic reversing answers questions about execution and effect. You can confirm whether a sample actually reaches out to a command channel, drops files in user or system locations, modifies launch items, or attempts to enumerate local data. That makes it especially valuable when the code path depends on environment, user interaction, or network responses.
The practical rule is that static analysis gives you the map, while dynamic analysis gives you the route the sample actually takes. On macOS, that usually means using both: first read the binary for structure and likely intent, then validate the most important paths under observation so you do not confuse dead code, decoys, or architecture-specific branches with real behaviour.
Why the difference matters in real macOS investigations
macOS samples often blend native code, scripts, signed components, and post-execution behaviour, so relying on only one method can leave blind spots. A clean-looking binary may still unpack or fetch malicious content at runtime, while a noisy runtime trace may hide the original design if the binary was already partly transformed or encrypted. Static and dynamic reversing complement each other because they answer different evidentiary questions.
This is why analysts often compare the binary’s declared capabilities with its observed behaviour. If the static view suggests persistence and the dynamic view shows no persistence attempt, that may mean the sample is environment-gated, incomplete, or intentionally staged. If the dynamic view shows network or file activity that static review did not reveal, that is a sign to inspect packers, loaders, or runtime-generated strings more closely. The same logic applies to a MITRE ATT&CK Enterprise Matrix style investigation, where static clues and runtime evidence both help map technique use.
For macOS specifically, the difference also affects how you interpret code signing and platform protections. Static review can tell you whether a binary is signed, what entitlements it requests, and whether suspicious capabilities are embedded. Dynamic review shows whether those capabilities are actually exercised, blocked, or redirected by system controls during execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1057 — Process Discovery | Static and dynamic reversing both help map process behaviour and runtime execution paths. |
| Recommendation — Map observed runtime behaviour to ATT&CK techniques and validate process activity with telemetry. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for anomalous events | Dynamic reversing relies on monitoring process, file, and network activity during execution. |
| Recommendation — Instrument execution monitoring to capture file, process, and network changes during analysis. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Reversing depends on reviewing collected execution evidence and logs for meaningful behaviour. |
| SI-4 — System Monitoring | Dynamic analysis on macOS depends on detecting file, process, and network actions as they occur. | |
| Recommendation — Review and correlate logs to confirm runtime behaviour and identify suspicious execution patterns. Monitor system activity to observe sample behaviour during controlled execution. | ||
Practitioner Guidance
What to verify: Use static reversing first to identify high-value runtime claims, then verify them dynamically rather than treating either view as complete on its own. On macOS, the highest-value checks are persistence, network reach-outs, filesystem writes, and any action that depends on user context or external inputs.
Decision rule: If the binary is obfuscated, packed, or environment-sensitive, expect static and dynamic results to diverge and plan for both passes. If the sample is simple and transparent, static review may answer most of the question quickly, but dynamic observation still matters for confirmation.
What practitioners underestimate: Dynamic reversing is not just “running the sample,” it is controlled evidence collection. Without clean process, file, and network telemetry, you can miss the very behaviour you intended to validate, especially when the sample launches child processes or delays execution.
Practitioner takeaway: Static reversing explains the candidate behaviour set, while dynamic reversing proves which parts of that set are actually reachable in the macOS runtime you are testing.