From Crash …to trash? cash? or (bin)bash?

Patrick Wardle opens by arguing that crash reports deserve more attention. Users send them to developers so bugs get fixed, security teams use them to catch failed exploit attempts, and malware that misbehaves can leave them behind for detection. He cites a Microsoft case where a rare crash exposed a zero-day, and a leaked NSA document that treated crash data as useful fingerprinting.

Next he explains the anatomy of a macOS crash report, including the exception type, crashing thread, stack trace, register state and loaded binaries. Because address space layout randomization shifts binaries in memory, he rebases them in a disassembler before matching the faulting instruction to code, demonstrating this with a deliberate null pointer write. He then covers crashes from his own machine during normal use: stack exhaustion from unbounded recursion in his open-source firewall, an uninitialized pointer in Apple's Security framework, and a kernel panic from an off-by-one error whose patch introduced a kernel memory leak. An unbounded copy in the same kernel code led to a heap overflow. Further crashes hit Safari with a null dereference, the shell with a use-after-free in signal handling, and Apple's notarization service with another use-after-free.

He closes by saying crash reports help developers, can reveal exploitable memory corruption, and can flag malware. The practical lesson is to read the registers and map the faulting instruction back to source before guessing at causes.