A first-pass methodology for unknown binaries

Reverse engineering rewards patience and punishes assumptions — but most of the time you don't need deep analysis to answer the first questions about an unknown binary: what is this, roughly, and does it deserve more of my time? This is the first-pass routine I run before opening a disassembler in anger. None of it is novel; the value is in doing it in the same order every time, so the notes from one sample are comparable with the next.

0. Provenance and hashes first

Before anything executes or opens: record SHA-256, size, source and timestamps, and check the hash against known-sample databases. Two minutes of bookkeeping saves hours of re-analysis later — and occasionally ends the investigation immediately.

1. File identity, not file extension

file, magic bytes, and header sanity. Is it really a PE/ELF? Which architecture, which linker, which compiler artefacts? Packers announce themselves here more often than people expect: section names, abnormal entry points, or a .text section that is suspiciously small.

2. Strings — but read them like evidence

Everyone runs strings; fewer people read the output critically. I look for three classes:

• Infrastructure: URLs, IPs, domains, user agents, registry paths
• Capability hints: format strings, error messages, command templates
• Absence: a real program has boring strings everywhere. A binary with almost none is telling you it's packed or obfuscated — which is itself a finding.

3. Imports as a capability map

The import table is the cheapest behavioural summary you will ever get. VirtualAlloc + WriteProcessMemory + CreateRemoteThread reads as injection; CryptEncrypt next to file-enumeration APIs reads as ransomware; almost no imports at all reads as a loader that resolves everything at runtime. Write the hypothesis down before disassembly — the point of the deep pass is to falsify it.

4. Entropy tells you where to look

Per-section entropy separates packed from plain in seconds. High-entropy .rsrc or overlay data is where payloads hide; a high-entropy .text means the real program only exists at runtime, and static analysis should shift to the unpacking stub instead of the noise.

5. Only now, the disassembler

With a hypothesis, Ghidra time is targeted instead of exploratory: entry point, the functions referencing the interesting strings and imports, cross-references outward. I annotate as I go and stop when the hypothesis is confirmed or broken — the goal of a first pass is a decision (escalate, archive, or detonate in the lab), not a complete reconstruction.

The meta-lesson

The routine matters more than the tools. Every step produces an artefact — hashes, identity, string classes, capability map, entropy profile — and the artefacts compose into a triage report that someone else can review. That reviewability is what separates analysis from vibes, and it is exactly the part worth automating. Automating it is an ongoing project of mine — the Binary Triage Toolkit — and this checklist is its specification.