Resolving Dynamic API Hashing

When to Use

• A sample resolves APIs by hash (no plaintext import names) and you have the hash constants from disassembly.
• You need to map each hash back to an API/DLL name to understand functionality.

Do not use this to execute the resolver — it computes hashes over a name wordlist statically and matches them to your observed constants.

Prerequisites

• The hash constants observed in the binary and (optionally) a names wordlist.

Workflow

Step 1: Identify the algorithm

python scripts/analyst.py id 0x6A4ABC5B

Computes the constant under each supported algorithm against a built-in seed list to suggest which algorithm/seed reproduces known API hashes.

Step 2: Resolve hashes against a wordlist

python scripts/analyst.py resolve hashes.txt --algo ror13 --wordlist names.txt

Brute-forces the provided hashes against the wordlist using the chosen algorithm and reports matches.

Step 3: Annotate the disassembly

Label resolved call sites with their API names to recover behavior.

Step 4: Document the routine

Record the algorithm, seed/initial value, and any key so the routine is reusable.

Validation

• The chosen algorithm reproduces at least one known API hash (sanity anchor).
• Resolved names are real exported symbols of plausible DLLs.
• Unresolved hashes are reported, not silently dropped.

Pitfalls

• Wrong endianness/rotation direction producing no matches — try variants.
• Algorithms seeded with a per-sample key; without the key, matches fail.
• Case sensitivity: some routines hash uppercased names, others as-is.

References

• See references/api-reference.md for the resolver.
• ATT&CK T1027.007 and the Windows API Index (linked in frontmatter).