Migrate symbols across binary versions using LLM diff

The skill migrates symbols between two versions of a binary when the old version has symbols and the new one does not: a kernel/driver missing its PDB, an updated application that was already reverse-engineered once, an updated protection mechanism, or any old-symboled-versus-new-unsymboled comparison. The core workflow: load both binaries in IDA and find shared anchor functions (exports are most reliable since their names survive even when addresses move, followed by string references, constants, and code patterns); export disassembly and pseudocode for the anchor from both versions; fill a fixed prompt template with the old (referenced, symboled) and new (target, unsymboled) disassembly and pseudocode plus the symbol names to locate, and send it to an LLM; parse the returned YAML symbol mapping; and batch-apply it to the new IDB, then use the newly-migrated functions as fresh anchors and iterate deeper. One function is compared per LLM call to avoid context overflow - medium functions (under 200 lines) go to DeepSeek V3 for low cost, huge functions (over 500 lines) or complex control flow go to GPT-4o or Claude, with 10-20 concurrent calls and result caching.

The LLM's YAML output covers five symbol types: found_vcall (indirect/virtual calls, keyed by vfunc_offset and func_name), found_call (direct calls, keyed by func_name), found_funcptr (function-pointer references), found_gv (global-variable references), and found_struct_offset (struct-member offsets, keyed by offset/struct_name/member_name). Each parses into a specific IDA action, quoted verbatim from the source:

found_call → idapro_rename(addr=call_target, name=func_name)
found_vcall → idapro_set_comments(addr=insn_va, comment="vcall: {func_name} @ +{offset}")
found_funcptr → idapro_rename(addr=funcptr_target, name=funcptr_name)
found_gv → idapro_rename(addr=gv_addr, name=gv_name)
found_struct_offset → idapro_set_comments(addr=insn_va, comment="{struct_name}.{member_name}")

Compared to manual side-by-side IDA review (free but hours of work), BinDiff auto-matching (free, fast, but unreliable across large structural changes), or handing the whole task to a general coding agent (50-100 yuan, slow), this LLM-batch approach is framed as roughly 1 yuan and about 10 seconds per function at comparable accuracy - though results still need manual spot-checking since the LLM is not 100% accurate, and a bad anchor invalidates everything built on it. A worked example: locating a renamed PspSetCreateProcessNotifyRoutine in a newer ntoskrnl.exe build whose PDB was pulled, by finding the still-exported PsSetCreateProcessNotifyRoutine as an anchor and letting the LLM match its unsymboled callee to the old symboled one.

Use it when old reverse-engineering results or symbols exist for one binary version and need to be migrated to a new, unsymboled version, rather than reversing the new version from scratch. Reversing a binary from zero uses ida-reverse/ or radare2/ instead; comparing two genuinely different binaries uses traditional BinDiff/Diaphora. It requires IDA Pro (not auto-installable) plus Python, PyYAML, and an LLM API key, and diff quality degrades with heavy recompilation or obfuscation between versions.

Input is the old version's symboled disassembly/pseudocode, the new version's unsymboled disassembly/pseudocode for the same function, and the list of symbol names to locate. Output is a YAML symbol-mapping file, parsed into batch IDA rename and comment operations on the new binary's IDB.

Reverse engineers who already have named results for an old binary version and need to carry that work forward to a new build without re-reversing every function by hand.