# Binary Ninja community plugins: a catalogue frozen for old versions

> The Vector35 community-plugins repository is a table of third party Binary Ninja plugins, with an author, a description, an update date, a type, the Python API level and a licence for each entry. The README marks the repository deprecated and says it is kept for Binary Ninja 5.1 and older on a best-effort basis.

**Vector35/community-plugins** — Repository for community provided Binary Ninja plugins

- Repository: https://github.com/Vector35/community-plugins
- Website: https://extensions.binary.ninja/
- Stars: 595 · Forks: 50
- Language: Python
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/vector35-community-plugins

## An index that is explicitly on its way out

The first thing in the README is a warning, and it is unusually direct. The repository is deprecated, the current list is at extensions.binary.ninja, and this one is maintained only for older versions of Binary Ninja, namely 5.1 and older, as a best-effort attempt with no guarantee of support. That framing changes what the repository is. It is no longer the front door to the plugin ecosystem, it is a frozen copy that still answers a question for people on old versions, and it is kept alive by the fact that the index is generated and the community still pushes entries to it. The last push was on 2026-10-15, so the file is being maintained, but what is being maintained is the record rather than the ecosystem. The homepage of the project is the extensions site, which is where a new plugin should be listed today, and the older registry's value to a reader is historical and practical rather than current. It is a catalogue, not a package, and the distinction matters when you decide where to spend your time.

## What each column in the table tells you

The table is the product, and its columns are the metadata that makes a catalogue useful. There is the name, which links to the plugin's own repository, and the author, which matters for two reasons, because you can judge the work and because you can find the maintainer when something breaks. There is a one line description of what the plugin does. There is a last updated date, which is the most useful column in a catalogue of this kind, since a plugin last touched in 2019 and one updated last month behave very differently against a changing analysis product. There is the type, which says where the plugin hooks into the application, and the API field, which records the Python version the plugin targets. And there is the licence. The API column shows mostly python3, with a handful of entries marked for both python2 and python3, and one entry listed as python3 with rust. That single field is what tells you whether a plugin will even load in your installation, and it is the column people tend to skip and then regret. The licence column is equally varied, and it ranges across MIT, Apache 2.0 in two spellings, BSD 2-clause, BSD 0-clause, the Unlicense, GPL-3.0 and AGPL-3.0.

## The plugin types, and what each one hooks into

The type column uses a small controlled vocabulary, and understanding it tells you what a plugin can and cannot do. The helper type is the most common, covering plugins that add commands, utilities and quality of life functions without changing how the binary view behaves. The binaryview type covers plugins that change how a binary is displayed or loaded, and the entries in that category include loaders for firmware formats, an Android Dex loader, a Playstation 3 ELF loader and an AMD Secure Processor or PSP firmware loader, plus a plugin for ar archives of object files. The architecture type registers support for a processor architecture, and the Blackfin entry is the example in the list. The ui type covers interface additions such as sidebars, widgets and inspectors. The core type is for plugins that change fundamental behaviour, which is where the signature generator and the indirect branch information plugin sit. The sync type is for cross-tool collaboration, and BinSync is the entry, adding support for collaboration between decompilers. The analysis type covers analysis tooling, with a side-by-side binary diffing plugin in that group. Knowing the type is how you predict the blast radius of installing something, because a core plugin behaves very differently from a helper that adds a menu command.

## Where the ecosystem is heading: local models, MCP and YARA-X

Reading the table as a whole shows which directions the plugin community has taken, and the most recent entries are the most revealing. Several plugins integrate local language models. One integrates with a locally hosted Ollama server to rename functions and variables with AI, and it is typed across all five plugin categories at once, which tells you it touches most of the product. Another provides large language model helpers to explain code and assist in reverse engineering, and a third is an MCP server for Binary Ninja with dual transport support over SSE and STDIO, which is a sign that the tool is being wired into agent workflows rather than only into a keyboard-driven UI. Signature work has moved too, with a plugin that generates and finds signatures, and one that adds YARA-X scanning with a rule editor, and one that is written in python3 and rust rather than Python alone. On the extraction side, there is a plugin that splits portable executables and ELF files into individual object files per function, and one that integrates a modern Rust based version of Binwalk into the reversing workflow for firmware analysis. And one entry rebuilds a plausible source tree from the __FILE__ path strings passed to logging or assertion functions, which is the kind of inference that is only useful once you trust the tooling underneath it.

## The scripts that generate the index

The repository is not only a markdown table, and the top level listing shows the machinery. There are two Python scripts, generate_index.py and generate_plugininfo.py, plus validate_json.py, and the data they work on in listing.json and plugins.json. There is also mirror-all-plugins.sh, a shell script for mirroring, and an INFO file, plus a .gitmodules entry, which suggests the listing pulls from somewhere else rather than being hand written. The scripts declare their dependencies in a requirements file, and it is a short one.

```bash
requests
python-dateutil
```

Two libraries, requests and python-dateutil, tells you the shape of the job. The scripts fetch remote plugin metadata over HTTP and stamp or sort it with date handling, then the JSON files hold the machine readable form of the catalogue and the markdown table is generated from them. That structure is the point of the repository, because a catalogue of a few hundred third party repositories is exactly the kind of list that rots when it is maintained by hand. Having a validator in the same directory means the generated table and the underlying JSON can be checked against each other, and having a mirror script means the whole set can be replicated without relying on a single host. The cost of this design is that the deprecated repository still consumes review time, and the README says as much by describing itself as a best-effort effort.

## Licence variety, and why it matters before you install

The licence column is not decoration. Most entries are MIT, which is the permissive default and imposes nothing on you beyond keeping the notice. Others are Apache 2.0, which adds an explicit patent grant and a requirement to note changes. The BSD variants appear in two forms, the 2-clause and the 0-clause, which differ in how much they ask you to reproduce. The Unlicense is the most permissive of the set, placing the code in the public domain as far as the author can. At the other end, GPL-3.0 and AGPL-3.0 appear, and for those two the obligations reach beyond the plugin file. A GPL plugin loaded into a commercial analysis environment raises questions about distribution, and the AGPL entry in this list, a plugin for taking and managing database snapshots, is the one to look at first if you are working inside a company. There is no licensing guidance in the README, so the check has to be per plugin, using the licence field in the table as a pointer and the plugin's own repository as the authority. For an analyst working on binaries they are authorised to examine, the practical question is different, because the licence of the analysis tool does not change the legal position on the target, and that remains your responsibility to establish.

## Conclusion

Use this repository as an archive rather than a source, because the README itself states that it is deprecated, that the current list lives at extensions.binary.ninja, and that support here is not guaranteed. It remains genuinely useful for two things, finding the plugin that solves a problem you already have, and finding the tooling that a specific analysis workflow needs, since the table records licence and API level for each entry. Before you install anything from it, check the entry's own repository for its current state, and check the type field, because an architecture or binaryview plugin is tied to a specific Binary Ninja version and will not load on a newer one.

## FAQ

### Is the Binary Ninja community-plugins repository still current?

The README carries a warning that the repository is deprecated, that the current list is at extensions.binary.ninja, and that this repository is maintained only for older versions of Binary Ninja, 5.1 and older, as a best-effort attempt with support not guaranteed. The last push was on 2026-10-15.

### What does the type field in the plugin table mean?

The type records where a plugin hooks into the application, with values such as helper, binaryview, architecture, ui, core, analysis and sync. The README's table shows helpers for added commands and utilities, binaryview plugins for loaders and display changes, architecture plugins for processor support, ui plugins for sidebars and widgets, core plugins for fundamental behaviour, and sync for cross-decompiler collaboration.

### Which licences appear in the Binary Ninja plugin list?

The table records MIT for most entries, along with Apache 2.0, BSD 2-clause, BSD 0-clause, the Unlicense, GPL-3.0 and AGPL-3.0, and a few entries spell the Apache licence as Apache version 2.0. The README gives no licensing guidance, so check the plugin's own repository for the authoritative terms.

### What do the API and Last Updated columns help me decide?

The API field records the Python version a plugin targets, mostly python3 with some entries marked for python2 and python3 and one listed as python3 and rust, which tells you whether it will load at all. The Last Updated date tells you how a plugin is likely to cope with a changing analysis product, and the table spans entries from 2019 through 2026.

### Which plugins in the list use local language models or agent protocols?

The table includes a plugin that integrates with a locally hosted Ollama server to rename functions and variables with AI, a plugin providing large language model helpers to explain code and assist in reverse engineering, and an MCP server for Binary Ninja with dual transport support over SSE and STDIO.

## Sources

- [Issues](https://github.com/Vector35/community-plugins/issues)
- [License: MIT](https://github.com/Vector35/community-plugins/blob/master/LICENSE)
- [Project website](https://extensions.binary.ninja/)
- [README](https://github.com/Vector35/community-plugins/blob/master/README.md)
- [Vector35/community-plugins on GitHub](https://github.com/Vector35/community-plugins)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vector35-community-plugins