Hex Patterns & Choosing Stable Ones

What is it?

Hex patterns match raw bytes, with wildcards (?? any byte) and jumps ([4-6] skip 4–6 bytes). They catch code sequences and structures that have no readable text. Choosing STABLE bytes (not ones that change per build) is the skill.

Why it matters

Malware families share code stubs that survive across variants even when strings change. A hex pattern on a stable stub (with wildcards for the volatile parts) catches the family, not one sample.

Where you see it

`$stub = { 55 8B EC ?? ?? 68 [4] E8 }` — a prologue and call with wildcards for the addresses that vary per compile.

What normal looks like

Hex patterns anchored on meaningful, stable byte sequences with wildcards only where bytes legitimately vary.

What suspicious looks like

A hex pattern that includes addresses/offsets which change every build (matches only one sample), or one so short and generic it appears in benign code.

How analysts investigate

Pick byte sequences that are part of the family's logic (a decode stub, a marker), wildcard the volatile bytes (addresses), and make it long/specific enough to be unlikely in benign files.

Common beginner mistakes

Baking build-specific addresses into a hex pattern (matches one sample only).
A hex stub too short to be specific, hitting benign code.

Stable bytes, wildcarded volatiles

  fragile: { 68 A0 14 42 00 }   ← the 4 address bytes change per build
  stable:  { 68 [4] E8 ?? ?? ?? ?? }  ← push <addr> ; call, addresses wildcarded
  choose the family's LOGIC bytes; wildcard what legitimately varies
  long + specific → unlikely in benign files

Hex patterns should anchor on stable logic bytes and wildcard the volatile ones (addresses/offsets).

Quick check

Your hex rule matched the analyzed sample but no other variant. Likely cause?

A quick self-check — it doesn't affect your XP or progress.