BinSync is a Git-backed reversing plugin that lets reverse engineers share function headers, stack variables, structs, enums, and comments across IDA Pro, Binary Ninja, angr-management, and Ghidra, and it is for reversing teams whose members do not all work in the same decompiler.

What it is

BinSync is a decompiler collaboration tool built on the Git versioning system. It lives in the reverse engineering plugin ecosystem, distributed as a Python package and loaded as an extension by each supported decompiler. Its working unit is the Reverse Engineering Artifact (REA), the set of objects that good decompilers have in common: function headers carrying symbol, args, and type; stack variables carrying symbol and type; structs; enums; and comments. Those artifacts are what BinSync syncs, and user-created types such as structs are supported alongside the built-in ones. The project is built by mahaloz, the angr team, and the SEFCOM research lab, with substantial use by the Shellphish hacking team.

The concrete problem it solves is that analysis of one binary is normally trapped inside one analyst's decompiler database. Two reversing engineers on the same target who use different tools cannot see each other's renamed functions, retyped stack variables, or annotations without manual export and re-entry, and the same analyst working in two tools loses the same work twice. BinSync replaces that manual transfer with committed, versioned artifacts that any supported decompiler can pull and push. Git supplies the history and the merge boundary, so a team keeps one shared picture of a binary even when no two members open it in the same program.

Key capabilities

• Syncs five REA classes: function headers (symbol, args, type), stack variables (symbol, type), structs, enums, and comments, including user-created types.
• Cross-decompiler operation across IDA Pro, Binary Ninja, angr-management, and Ghidra, so a team is not forced onto one tool.
• Git-backed syncing with distinct Pull, Push, and Auto Push operations, letting artifact changes carry version history.
• Full support matrix on IDA Pro: symbols, types, pull, push, and auto push across function headers, stack variables, global vars, structs, enums, and comments.
• Two-part Python installer: pip3 install binsync && binsync --install.
• Optional extras installed as pip3 install binsync[extras], which pulls in support for features such as the ChatGPT User.
• Plugin-manager and mode-based loading: Binary Ninja plugin manager, and PyGhidra mode for Ghidra.

Who uses it and how

• The Shellphish hacking team uses it, alongside the angr team and the SEFCOM research lab that build it, in reversing work where members run different toolchains.
• Teams split across IDA Pro and Binary Ninja synchronize the same artifacts instead of re-typing names and comments on both sides.
• IDA Pro users on version 8.4 or newer get the complete matrix, including Auto Push; users on older IDA are directed to BinSync v4.10.1.
• Ghidra users on version 12.0 or newer, launched in PyGhidra mode, get the minimal feature set of artifact name syncing and comments.
• angr-management users on version 9.0 or newer participate in the same syncing as the commercial decompiler users.

Getting started

Install with pip3 install binsync && binsync --install, or install from the Binary Ninja plugin manager. Every platform requires Python 3.10 or newer and Git on the system, and Ghidra must be launched in PyGhidra mode; full install guidance is in the quickstart docs.

How it compares

No comparable collaboration tool is named in the facts for this registry, so BinSync stands alone here rather than replacing a listed paid product. The tools it sits among are the decompilers it plugs into: IDA Pro, Binary Ninja, angr-management, and Ghidra. Those are single-analyst analysis environments, and BinSync adds the shared, versioned layer that they lack on their own; its BSD-2-Clause licence and Git-based storage let a team keep the artifact history itself.

When to use it — and when not to

A self-hoster must run Git, since syncing is built on versioning, and must have Python 3.10 or newer on every participating machine; the facts do not mention a database, object storage, or SMTP service to operate. A team should not adopt it expecting parity across decompilers: Ghidra support is still very much in early stage, so only minimal features such as artifact name syncing and comments should be expected there, and the repository carries 59 open issues. Teams standardized entirely on Ghidra, or unwilling to add Git to their reversing workflow, are the weakest fit.

pip3 install binsync && binsync --install