Native binary triage

When it applies

You have a compiled binary — a thick desktop/mobile client, a network service, a setuid helper during privesc, or a firmware component (reverse-eng-firmware) — and no source. You need to understand what it does, where attacker input reaches, and whether that path is exploitable, before committing to exploit-poc-development.

Why it works

A binary carries its logic in the code and its intent in the strings, imports, and symbols. Cheap static passes (strings, imports, cross-references) point straight at the interesting functions; a debugger then confirms what actually happens at runtime, so you spend deep analysis only on the paths that matter.

Method

1. Cheap recon first. file, strings -n8, and the import table tell you the language, protections, and intent in seconds. checksec (or rabin2 -I) for NX / PIE / RELRO / canary — they scope what an exploit would even need.
2. Map input → sink. Find where input enters (recv, read, argv, getenv, a file/format parse) and trace to dangerous sinks: strcpy/memcpy/sprintf/gets (overflow), system/exec/popen (command injection), format-string sinks (printf(user)), and integer math feeding an allocation size.
3. Read it in a decompiler. Ghidra or radare2/Cutter — jump to the sink, follow cross-references back to reachable entry points, and note the preconditions to reach it.
4. Confirm dynamically. Run under gdb+GEF/pwndbg (or ltrace/strace), break at the sink, feed a marker input, and watch whether you control size/pointer/format. A crash you can steer (controlled $pc, overwritten pointer) is the confirmation.
5. Pull the low-hanging intel — hardcoded secrets/keys (CWE-798), debug/backdoor paths, weak auth checks (a strcmp against a literal), and custom-protocol structure for later fuzzing.

Gotchas

• Stripped binaries have no symbols — lean on strings, imports, and library-call signatures; name functions as you go so the map survives.
• Packed/obfuscated (high entropy, tiny import table) → deobfuscate first (reverse-eng-deobfuscation).
• A crash is not yet a bug worth reporting — determine control and impact before you claim it; validate with reporting-triage-validation.
• Analyze untrusted binaries in an isolated VM — running an unknown executable is itself risky.

Verify success

You can state the input path, the vulnerable sink, the preconditions to reach it, and a runtime observation (controlled crash or a leaked secret) that proves it — a concrete lead for exploit development, not a guess from the disassembly.

References

Ghidra & radare2 documentation; pwndbg/GEF; the checksec protections model; CWE-121/787/798.