Skip to content
Get packs

Guide · Agent skill

How to use the Binary Diff Symbol Migration agent skill

Updated · written with AI from the project's own documentation and checked against our catalogue data

The binary-diff skill teaches an AI agent to carry reverse-engineering labels, such as function names, global variable names and struct offsets, from an older build of a compiled program to a newer build that has lost its symbols. It is meant for reverse engineers and security analysts who already have a labelled old version. By the end of this guide you will know what the skill needs, how to install it, how to phrase a request so the agent picks it up, and which safety checks to keep in place.

Binary Diff Symbol Migrationzhaoxuya520/reverse-skill · MIT

Quick start

  1. 1Download the ZIP. Download the binary-diff ZIP from the page where you found this guide.
  2. 2Unzip into a skills folder. Unzip it into ~/.claude/skills/ for personal use, or into .claude/skills/ in a project folder.
  3. 3Or upload it in the Claude apps. In the Claude apps, open Settings, go to Capabilities, then Skills, and upload the ZIP.
  4. 4Prepare old and new exports. Load both binaries into IDA Pro and export disassembly and pseudocode for matching anchor functions.
  5. 5Ask for a migration. Describe the old and new versions, the anchor and the symbol list in plain language.
  6. 6Review and apply the YAML. Check the matches the LLM returns, then apply them to the new database through IDA Pro tools.
  7. 7Spot-check results. Verify key symbols manually, since LLM matches are not always correct, then repeat from the new anchors.

What does the binary-diff skill make the agent do?

The skill describes a fixed workflow. The agent exports disassembly and pseudocode for a matching function from both the old and new versions. It fills a fixed prompt template with that material and asks an LLM to find where the labelled references appear in the new version. The LLM returns YAML, which the agent parses and applies to the new version through IDA Pro tools.

The skill defines five kinds of matches: virtual function calls, direct calls, function pointers, global variable references and struct offset references. Each one maps to a specific action, such as renaming a call target or adding a comment at an instruction address.

  • Virtual function calls become comments with the offset and function name.
  • Direct calls, function pointers and global variables are renamed through idapro_rename.
  • Struct offset references get a comment in the form StructName.MemberName.

Install the binary-diff skill

Download the ZIP for this skill from the page where you found this guide. Then choose one of the following locations, depending on how you use your agent.

For Claude Code, unzip the skill into ~/.claude/skills/ to make it available everywhere, or into .claude/skills/ inside a project to limit it to that project. If you use the Claude apps, you can instead upload the ZIP under Settings, then Capabilities, then Skills.

  • Personal install: unzip into ~/.claude/skills/.
  • Project install: unzip into .claude/skills/ in your project folder.
  • Claude apps: upload the ZIP under Settings, Capabilities, Skills.

Check what you need before you start

The skill assumes you already have a labelled old binary and an unlabelled new binary. You also need IDA Pro, or tooling that exposes idapro_rename and idapro_set_comments functions. Each binary needs disassembly and pseudocode exports.

You will need access to an LLM API with an API key. The skill suggests DeepSeek for medium-sized functions, and GPT-4o or Claude for very large functions. The skill also refers to a tool index and a precedent file, which are not included in the files you receive, so the agent may not be able to complete its setup steps as written.

  • IDA Pro or a compatible tool that provides idapro_rename and idapro_set_comments.
  • Old and new binaries with disassembly and pseudocode exports.
  • An LLM API key (DeepSeek, GPT-4o or Claude suggested).
  • Python with a YAML parser and an HTTP client, as the skill describes.

How to trigger the skill with natural requests

The skill's description lists trigger phrases such as symbol migration, binary diff, cross-version, missing PDB and function offset migration. You do not need to type these exactly. Describe the situation plainly: you have named functions in an old build and want them in the new one.

Give the agent the old and new versions, the anchor you want to start from, and the list of symbols to migrate. Naming a starting point such as an exported function or a string reference helps the agent follow the anchor-based workflow.

  • Example: I named 200 functions in target.exe v1.0. Migrate those names to v1.1 using the binary-diff skill.
  • Example: The kernel has no PDB for the new build. Use the old symbols to find the new address of a non-exported function.
  • Example: The app updated and my offsets moved. Find the new offset of the same function.

Work through the migration in steps

The workflow runs in five steps. First, load both versions into IDA and find anchor functions that exist in both, such as exported functions or string references. Second, export disassembly and pseudocode from each side. Third, fill the prompt template and collect YAML from the LLM. Fourth, apply the mappings to the new database. Fifth, treat the newly named functions as new anchors and repeat.

The source advises one function per comparison to avoid overloading the model's context, parallel calls with a modest concurrency, and caching results to save tokens. It also says every result should be spot-checked by a person, because LLM matches are not always correct.

  • Use exported functions as the most reliable anchors, then string references, constants and code patterns.
  • Keep each comparison to one function.
  • Cache intermediate results.
  • Verify key symbols by hand.
found_call: - insn_va: '0x180888800' insn_disasm: call sub_180999900 func_name: CLoopMode_RegisterEventMapInternal

When to use binary-diff and when to use other tools

Use this skill when you already have labels for an older build. If you are starting from nothing, the source points to an IDA or radare2 skill instead. If you are comparing two unrelated binaries, it recommends traditional tools such as BinDiff or Diaphora, or manual analysis.

The source compares approaches by cost, time and accuracy. It says BinDiff is free and fast but less accurate when code structure changes a lot, and that manual comparison is accurate but slow. These are the author's claims and are not benchmarked in the source.

  • Starting from scratch: use an IDA or radare2 skill.
  • Old labels exist, new build unlabelled: use binary-diff.
  • Two unrelated binaries: use BinDiff, Diaphora or manual analysis.

Safety, authorisation and network notes

The skill runs scripts and makes network calls, because it sends exported code to an LLM API. Read the skill files before you run it, and be careful about what code you send to a third-party service. Only use the skill on software you are authorised to analyse. The skill tells the agent to check an authorisation record first, but that record is referenced and not included, so you must confirm authorisation yourself.

The skill's first instruction is to read a field journal and tool index, and it tells the agent not to guess tool paths. Those files are not in the package, so review how your agent handles missing files.

  • The skill runs scripts and uses the network.
  • Exported disassembly and pseudocode are sent to the LLM provider you choose.
  • Confirm you have authorisation before analysing any software.
  • Check any tool paths the agent reports before trusting them.

What people use it for

  • Recovering function names in an updated application after the labels were lost.
  • Locating non-exported kernel or driver functions when newer debug symbols are unavailable.
  • Tracking where protected functions moved after a software update, so you can find their new offsets.
  • Batch-renaming global variables and struct member references across a new build.

Frequently asked questions

How do I install the binary-diff skill?

Download the ZIP from the page, then unzip it into ~/.claude/skills/ for personal use or into .claude/skills/ inside a project. In the Claude apps, you can upload the ZIP under Settings, Capabilities, Skills instead.

What do I need to use binary-diff?

You need IDA Pro or compatible tooling with idapro_rename and idapro_set_comments, labelled old and new binaries with exports, and an LLM API key. The skill suggests DeepSeek, GPT-4o or Claude.

Is the binary-diff skill free?

The files on this page do not state a licence fee for the skill beyond its MIT licence. The LLM API you use is billed by its provider, and IDA Pro is commercial software that the skill does not include.

Is binary-diff better than BinDiff or Diaphora?

It targets a different job. The skill is for transferring labels from a named old build to a new one, while BinDiff and Diaphora compare two binaries directly. The skill says traditional tools are more suitable for comparing unrelated binaries.

Why does the skill not work for starting a reverse-engineering project?

The skill assumes you already have a labelled old version. For a project with no labels, the source recommends an IDA or radare2 skill.

Can the LLM make mistakes in the symbol matches?

Yes. The skill states that LLM matches are not 100 percent accurate, so key symbols should be checked by a person before you rely on them.

New agent skills, repos and AI tools — every week

The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.

Our verdict

Use binary-diff if you already have labelled reverse-engineering results for an older build and want them moved to an updated build, and you are authorised to analyse the software. Pick a different skill or tool if you are starting from an unlabelled binary, comparing two unrelated programs, or cannot send the exported code to an external LLM API.

Download the skill