Binary Ninja Blog

Binary Ninja’s signature system automatically matches and renames copies of known functions based on their function signature. The signature system is designed to aid in analyzing statically-linked binaries without symbols available.

While a few signature libraries are bundled with Binary Ninja, you can now create your own signature libraries! These tools are available as the Signature Kit Plugin. If you’re on the dev branch, you can install it in the plugin manager now.

Warning: SigKit is no longer under active development. For more information, please see https://binary.ninja/2025/08/22/warp.html.

This post marks the official release of the signature system, and also serves as documentation for how it works and how to most effectively use it.

Thankfully the wait from 1.2 to 1.3 was much less than last time. Our goal is to aim for quarter releases as often as possible, and yet we still managed to pack in a large number of fixes and features into just a few months.

As always, another good reference for what has changed is our list of closed issues.

Binary Ninja is built to be as extensible as possible and that includes adding and extending new architectures. While we’ve published example architectures before, this blog post is meant to serve as a more detailed introduction to what goes into adding an architecture. Specifically, this series of blog posts will get you started from zero plugin writing experience to a fully functional architecture with easy to verify checkpoints along the way in a short amount of time.

This first post in the series is meant to get you going with a very fast architecture disassembler in an afternoon by leveraging an existing disassembler and wrapping it into the appropriate APIs. In the second part of the series, I’ll introduce more of the concepts behind Binary Ninja’s IL and how that forms the basis for its advanced analysis.

[EDITOR’S NOTE: This post was lost in the shuffle during some website maintenance and is being re-posted in a corrected form. Sorry about that!]

We’re happy to announce that version 1.0 of Binary Ninja Cloud is live!

Go check it out right away or read on for more details of the current features and future plans.

Welcome back. Last time we started our look into all of the new features that have landed on our stable branch since the previous stable release in May. In part two of the series we’re contiuing our look at new features added to the: UI, Architecture improvements, update functionality, and documentation fixes.

It’s been a long time coming, but it’s finally here! Version 1.2 of Binary Ninja launches today with a huge list of improvements. There’s so many features that we’re splitting this blog post into three pieces. This post covers half of the changes that have happened since the last stable release back in May. The next post will cover the remaining features from the last stable, and the third will be a higher level overview of everything that’s happened since 1.1 from two years ago.

We’re not covering all bugs fixed to keep this from turning into a full-length novel. For more details, you can always check the list of closed issues.

We’re very pleased to announce that Binary Ninja Cloud is live!

This free service is still in beta and you can track our progress and roadmap via the project’s github page as well as file any bugs you find.

Feel free to go check it out right away or read on for more details on the current features and future plans.

(NOTE: This blog is primarily intended for Binary Ninja plugin authors – the user-facing component for the plugin manager is under testing and should be released shortly)

We’re pleased to announce the imminent release of Binary Ninja’s Plugin Manager 2.0. This article is intended for plugin authors interested in updating their plugins to ensure compatibility with the new interface. The new UI will dramatically improve plugin discoverability and highlight the many great plugin authors out there.

(No, this is not an April Fools post, but we have one available if you haven’t gotten your fill yet.)

A few weeks ago we kicked off a new tradition for Vector 35, a yearly hackathon. We’ve been wanting to do this for some time now, but over the new-year break we finally got a date on the calendar and spent March 11th-15th working on a variety of fun projects.

The rules were simple: whatever you worked on during the hackathon had to be something that you weren’t doing your daily routine, and it had to sound fun to you. The plan was to explore fresh ideas, try some experiments, or build things you thought were interesting but weren’t otherwise on our immediate to do list.

With only one week of hacking we cranked out a ton of different and useful results. This is also a good chance to introduce different members of the Vector 35 team you might not have been aware of too, so we’ll break down what everyone worked on below.

(EDTIOR’S NOTE: This introduction is by Jordan, but thanks so much to Kyle for the rest of this content)

We have mixed feelings at Vector 35 about April Fools jokes. They’re often very entertaining but they also have a tendancy of making April 1 a painful day to surf the web (here’s looking at you, Stack Overflow. For that reason, we’re going to give you the choice of a real update, or a fake one! For the real update, head over to our Hackathon Recap which includes details on several major new features!

Otherwise, carry on and enjoy. You’ve been warned. :-)