Binary Ninja Blog

Binary Ninja 6.0 (Krypton)

By Jordan Wiens

Caped Binja flying over the city. >

Binary Ninja 6.0 (Krypton) is here! This is a major version bump and it’s worth the wait. We’ve shipped a brand new MCP server, a new Binary Similarity feature, and a complete overhaul of the Plugin Manager as the new Extension Manager. Under the hood, you’ll find major improvements to performance and memory usage, a refactored calling convention to properly represent structure parameters and return values, and added HLIL structure initializers. On the scripting side, we’ve upgraded the bundled Python to 3.13 and included it on Linux. We’ve also added a new TMS320C6x architecture, a new user wizard to ease migration, and a long list of debugger improvements. And those are still only some of the new features detailed below.

We’re also improving the free edition. We’ve added the highly requested armv8 (AArch64) architecture as well as the above mentioned MCP server. Additionally, we’re also shipping a new Linux ARM64 build of the free version. Next, as previously announced, with this release we’re putting our new pricing and packaging into effect. Finally, thanks to everyone who participated in our 10 year celebration, we’re looking forward to another decade!

Major Features

Performance and Memory

Let’s get some universally applicable improvements out of the way first. No matter how you use Binary Ninja, you’ll see some fantastic speedups in 6.0 while also seeing decreases in memory usage. Exact improvements depend on the workload and hardware so we picked some representative sample binaries and ran a gamut of testing including multiple runs (for all samples but Chrome) to ensure reliability. The results speak for themselves.

5.3 stable 6.0 stable

syspolicyd

Mach-O universal, x86-64 slice

4,215 functions2.6 MB

Analysis time
13.8s
7.0s

1.97× faster

Peak memory
2.81 GB
2.30 GB

18% less

CPU instructions
0.51T
0.41T

19% fewer

chrome_crashpad_handler

ELF x86-64

6,092 functions1.9 MB

Analysis time
32.8s
30.9s

1.06× faster

Peak memory
3.00 GB
2.03 GB

32% less

CPU instructions
0.96T
0.76T

21% fewer

locationd

Mach-O universal, x86-64 slice

28,372 functions19.0 MB

Analysis time
63.9s
41.4s

1.54× faster

Peak memory
6.06 GB
3.62 GB

40% less

CPU instructions
3.33T
2.79T

16% fewer

ntoskrnl.exe

PE32+ x86-64

34,146 functions12.8 MB

Analysis time
257s
128s

2.02× faster

Peak memory
8.78 GB
3.96 GB

55% less

CPU instructions
18.3T
8.57T

53% fewer

libbinaryninjaui.so.1

ELF x86-64 shared object

43,957 functions136.1 MB

Analysis time
76.4s
55.6s

1.37× faster

Peak memory
8.48 GB
7.90 GB

7% less

CPU instructions
3.26T
2.94T

10% fewer

vmlinux 6.14

ELF AArch64, with DWARF

92,961 functions511.8 MB

Analysis time
761s
352s

2.16× faster

Peak memory
17.29 GB
12.25 GB

29% less

CPU instructions
46.7T
22.6T

52% fewer

chrome

ELF x86-64, with DWARF

950,042 functions1.47 GB

Analysis time
1186s
584s

2.03× faster

Peak memory
43.85 GB
32.82 GB

25% less

CPU instructions
59.3T
38.3T

35% fewer

How this was measured
Machine
AMD Ryzen 9 9950X (16 cores, 32 threads), 96 GB RAM, Ubuntu 26.04. Measurements made while idle.
Procedure
Default headless analysis to completion including full decompilation, three runs per binary (one for Chrome, which takes ten minutes a run), reporting the mean. Time is wall-clock analysis time; memory is peak resident set size.

As you can see, across a representative corpus, 6.0 analyzes up to 2.16 times faster than 5.3 while using as much as 55% less peak memory.

These gains come from many changes rather than any single optimization. There were dozens of smaller fixes, hundreds of hours of profiling, new tools developed to analyze memory usage, and Brian, Mark, Ryan, and others working to optimize the system. Nothing was sacred: many long-standing data structures and sections of code were critically examined for potential improvements.

Analysis Cache

Binary Ninja maintains an analysis cache of analyzed functions. However, choosing when to re-analyze and when to cache can be tricky to get right from a performance perspective. With improved instrumentation and analysis we were able to make much better use of the existing analysis cache while also fixing some bugs along the way.

Database Saving

This is just the beginning as we’re planning to focus even more on save and load times in future releases. However, in 6.0, we’ve already improved both memory usage and total time during saving, as well as fixed a file size creep bug where files could keep growing with repeated saves.

MCP

While Tim and BK on the Sidekick team have added MCP support so that Sidekick can access MCP servers in a previous release, with Binary Ninja 6.0, we shipped a first-party MCP server. It’s “batteries included” for the post-LLM world. It can interact directly with the UI you are looking at or, for versions of the product with headless API support, can be accessed directly without the UI at all.

There are two variants. The GUI server runs inside Binary Ninja over HTTP and is included in all editions including free. The headless server is a standalone binaryninja_mcp binary that speaks stdio, and is included with Commercial and Ultimate on macOS and Linux. Native Windows packages don’t ship the headless binary yet. Use the built-in GUI server there or run the Linux build under WSL. This is an unfortunate limitation due to Windows file system locking, where a running MCP server can corrupt or block an install.

Both variants expose the same data and allow the same actions: opening files and databases, selecting BinaryViews, driving and waiting on analysis updates, a compact triage summary of a binary, program structure (entry points, segments, sections, symbols, imports, exports, relocations, data variables, and strings), raw memory reads, function inspection covering metadata, disassembly, Pseudo C, ILs, and many more useful properties. They can rename objects, create and apply types, and create data variables as well.

Turning on the GUI server is easy: enable ui.mcp.enabled in settings and restart to always enable, or run Plugins > MCP > Start Server. With default settings it listens at http://127.0.0.1:24642/mcp, and Plugins > MCP > Copy Connection Info will hand you the exact URL and authorization header for your session so you can paste it straight into your client. If you’d rather lock it down, set ui.mcp.token and clients will need to send a matching bearer token.

The documentation has ready-to-paste configurations for Claude Desktop, Cursor, VS Code, and Codex, as well as much more information.

Binary Similarity

Binary Similarity is, at heart, the task of noticing that the two functions in front of you are the same person, except one has a cape and one wears glasses.

With 6.0 Mason created our Binary Similarity system for comparing two or more related binaries. It’s not a competing diffing engine to popular tools like BinDiff, Diaphora, or BSim. Rather, it’s a pluggable platform which can not only leverage multiple providers, but also allow you to integrate, compare, and do more with them than before.

We currently ship two providers: Google BinDiff (for finding structurally similar functions) and WARP (for finding exact function matches). All providers report similarity and confidence, allowing you to review possible matches, render them side by side, and apply the available analysis information to the new binary.

A similarity result rendered in Graph view.

For example, when comparing two releases of a popular game, Binary Similarity quickly highlights the changes in cGcFrontendPageShop::GenerateRepShopInventory. Rendering the result keeps both versions in sync and highlights the differences, making it easy to identify patched logic.

The changed game function rendered side by side.

Patch diffing is not the only use case. Often you have a heavily annotated binary whose annotations you want to port to a newer (or different) version. With Binary Similarity, we can automatically transfer annotations from one binary to another, saving time and effort.

The original `main` function in the reference build.

Of course, the UI is not the only way to use the new Binary Similarity functionality. This is Binary Ninja, after all: everything is pluggable and accessible via an API. The complete system is exposed through the Python API, C++ API, and Rust API, allowing you to create and run sessions headlessly.

Plugins can also register entirely new providers and resolvers. Providers find possible matches, while resolvers choose which results to use (and can apply them automatically), so the system is not limited to WARP and BinDiff or to our built-in matching algorithm(s). In fact, the third-party binja diff plugin, which wraps QBinDiff from Quarkslab, already supports adding QBinDiff as a provider for a second opinion to BinDiff.

NOTE: Binary Similarity is only available in Ultimate.

For more information on configuring sessions, reviewing and applying results, or running it headlessly, see the documentation. Our immediate roadmap includes new integrations and even our own novel matching implementation, so stay tuned!

Architectures and Platforms

TMS320C6x

Brandon’s been on a DSP kick and adding those difficult-to-decompile architectures to Binary Ninja. First it was Hexagon and, now with 6.0, it’s TMS320C6x.

Keep an eye out for an upcoming blog post with more detail about all the behind-the-scenes changes and how we can now handle such a problematic architecture. In the meantime, all customers with current Ultimate support can update to a version with 19 first-party architectures!

Here’s a quick sneak peek for everyone else:

Texas Instruments TMS320 C6x Support

Multiple Global Pointers

Binary Ninja could previously track and allow users to override only a single global pointer register, but that doesn’t cut it for every architecture. TriCore, for example, uses four registers to point into different global data regions, and Binary Ninja can now track and override each of them independently. With accurate global pointer values available during analysis, references to global data resolve correctly and produce much cleaner decompilation.

Multiple Global Pointers

Analysis

Improved BASE (Fast Analysis Mode)

Introduced in a previous post, BASE is our automated base address detection feature built into all versions of Binary Ninja. With 6.0, it includes a new “sampling” mode, enabled by default, which can produce accurate results in a much shorter timeframe. It’s especially useful for large files, though the previous IL Analysis Mode is still available when accuracy matters more than speed.

Base Detection - IL Sampling Mode

Calling Convention Refactor

One of our main thrusts going forward is better handling of language-specific decompilation. We’ve built language representation features for that, and our workflow system lets us tweak the decompilation in really useful ways. But our type system, calling convention, and ILs likely need changes to fully support the most modern programming languages. Instead of sticking to just treating everything like C, we want to keep working toward language-specific support like we have with Objective-C.

To that end, in 6.0 Rusty refactored our calling convention system. We can now support structure returns and parameters which are used in a number of languages. Most of the changes you’ll see in 6.0 are minimal on the face of it, but this change unblocks several future language-specific decompilation improvements that you should be able to see in upcoming releases (or even sooner on our development branch).

That said, we do ship two specific changes. While the added Go and Pascal calling conventions don’t do much out of the box, when combined with a plugin like Delphinja, you can get some much improved results since it includes type libraries and specific debug information parsing that can leverage the new convention!

The Go calling convention support is in the core, but as we’re not yet processing the metadata available in .gopclntab sections and similar information, you won’t see any automatic changes yet. Keep an eye out for this in the next release, however!

HLIL_STRUCT_INITIALIZE

A new IL instruction and a system for initializer expressions greatly simplify structure initializations, resulting in some really clean decompilation.

Structure Initialization

Type Fragments

Fragments from Krypton are usually bad news. Type fragments are the useful kind.

A type fragment represents a bitwise slice of a larger source type while that slice is carried in integer-like storage. When a calling convention passes pieces of a structure in registers, or an optimized inline memcpy copies a typed object in register-sized chunks, those pieces used to decay into anonymous integers and the connection back to the original object was lost. Fragments preserve that relationship, tracking which bits of which source type a given register is holding as it moves through the program.

These are intermediate, in-flight types used by analysis rather than something you’ll define yourself, and they render in decompiled output using __frag notation (or __frag_be when the source is big-endian). Together with the calling convention refactor above, that means structures split across registers keep their types instead of dissolving into integers along the way.

Scripting and Extensions

Python 3.13 and Linux

We’ve been shipping a bundled Python in our macOS and Windows builds of Binary Ninja for a while now. Now, in 6.0, we ship this bundled Python with all builds on all platforms, including x86-64 and AArch64 Linux. This means that our support for third-party Linux distributions should be a bit more reliable since we don’t need to make assumptions about what’s installed by default.

While he was at it, Alex also bumped the included version to 3.13 to keep things a bit more modern. Our minimum supported version is still 3.10 if you require something older, however.

This does mean that if you were running the previously bundled version of Python and you switch, none of your dependencies will be installed! The one-time Plugin Migration dialog will reinstall them for you.

Scripting Console

A small but noticeable quality-of-life improvement for those who do a lot of scripting: the scripting console now hints at individual parameters instead of just the prototype.

Scripting Console Parameter Hints

Extension Manager

The Plugin Manager is dead, long live the Extension Manager! This change not only sets the groundwork for better plugin features, but also paves the way for native plugins and being able to install things other than plugins like themes or type libraries. Almost half the team touched the extension manager code this release, it was truly a team effort.

Switching between installed versions of an extension

Here are the main features you’ll see with the new Extension Manager:

  • You can switch versions for installed plugins
  • Dependency installation opens a dialog so you can see pip at work
  • Downloads can be per-platform now (a necessary prerequisite for native plugins)
  • Conflicting dependencies have some auto-detection and resolution
  • Plugin details are cached offline
  • Plugins are more verbose about their status in details and the list
  • Snippets ships by default
  • Plugins can be sorted by name, publication date, or most recently updated

Sorting the extension list

One heads-up if you’re upgrading: Extensions now live in channels/ instead of repositories/, so your first 6.0 launch will run a one-time migration. This will reinstall everything you had previously, dependencies included, and re-enable them when it’s done.

We also want to have a special mention to one of our summer interns Ashvika who did a ton of work to improve our plugin ecosystem. If you notice many more plugins with proper images and readmes, you can thank her for it.

The one-time Plugin Migration dialog, listing BinSync for reinstall

You’ll notice the new name in the API, too: The Python module is now extensionmanager, with a deprecation shim left behind.

New User Wizard

It’s hard to switch tools when you’re used to a particular workflow or hotkey, and it’s even harder to dig and find all the settings you might want to change in a new tool. New in 6.0 is a short three-step wizard. You choose a light or dark theme, a preferred experience, and a few privacy and network toggles (automatic crash reports, automatic update checks, and online WARP).

The middle step is for you if you’re arriving from another tool. Next to the Binary Ninja Defaults, you can pick a Ghidra-Like experience, or IDA-Like preset. There are multiple differences among them, and the configuration lives in docs/files in the API repository so contributions are welcome.

Choosing a starting workflow preset

If you want more information about what’s different compared to other tools, start with our migration guide.

Debugger

Krypton gives you a much clearer picture of the process around the code you are debugging. The new Debugger Memory Map sidebar shows every mapped region reported by the debug adapter, including its address range, size, permissions, and name. Binary Ninja can also mirror those mappings as individual memory regions, allowing Find to search mapped memory without trying to scan the entire address space. And when an address belongs to a library that was not part of the original analysis, you can now load symbols from the debugger backend on demand, either for one module or for all loaded modules. These are added as auto symbols, so they participate in analysis and annotations without overriding any names you have defined yourself.

Loading backend symbols from the Module widget's context menu

Packaging and Licensing

New Features in Free

The most common request from Binary Ninja Free users was for AArch64 support, and with 6.0 it’s finally here! The free edition now decompiles armv8 (AArch64) in addition to x86, x86_64, and armv7 (with Thumb2). That covers the overwhelming majority of binaries most people run into today and we’re happy to make the free version even more useful.

Adding armv8 also removed the reason we held back an ARM Linux build of the free edition in 4.1. So 6.0 ships a fourth free installer for Linux available on the free download page.

Armv8 isn’t the only thing new in Free for 6.0. Our new MCP server is included so you can point your favorite LLM at Binary Ninja and let it use our analysis completely for free. Free keeps getting more powerful under a yellow sun.

Everything else stays the same. It’s still free for non-commercial and commercial evaluation uses. The remaining limitations (no API or plugins and a reduced set of ILs) still apply. If you need any of our other architectures, the full breakdown of what ships in each edition lives on the purchase page.

Sidekick Free

In case you missed it over on the Sidekick blog, we recently launched free Sidekick credits for ALL Binary Ninja users with active support. You don’t need a credit card for a trial or to sign up. Just install the plugin and start using it. The included free credits refill every month.

Pricing and Packaging

As we outlined in our 6.0 pricing changes announcement, collaboration is no longer included with Ultimate. It is now a per-seat add-on available for named, computer, and floating Ultimate licenses. You can choose to add it to only the seats that need shared projects, versioned check-ins, real-time chat, and more.

We have also removed the old minimum seat count needed to get access to the Binary Ninja Enterprise Server. Enterprise Servers are no longer licensed separately: Customers with the collaboration add-on or floating Ultimate licenses can download and self-host as many servers as they need, wherever they need them.

Server Deployments

The new packaging also greatly improves how Enterprise Servers are managed. Instead of receiving a license for each server, you now create a server deployment in the Binary Ninja Portal. A deployment represents one named server installation and belongs either to your account or to a team you manage.

From the portal’s new Server Deployments page, you can create a deployment, assign floating licenses, and download a server bundle for your chosen platform, release channel, and version. The server bundle includes everything needed to set up the server, and will look very familiar to those who have deployed Enterprise Servers in the past. If the floating licenses assigned to a deployment change, you can also download only a new license bundle without having to download the entire server bundle again.

Each floating license can be assigned to only one deployment at a time; if a multi-seat floating license needs to be divided across deployments, split it in the portal first, then assign each resulting license to the appropriate deployment. Floating licenses can also be released from one deployment and reassigned to another. This lets you decide exactly how to distribute your floating seats across as many self-hosted deployments as your environment needs.

Open-Source Contributions

Special thanks to the following open-source contributors whose PRs were merged into this release:

We appreciate your contributions!

Everything Else

Analysis / Core

Performance

UI

Architectures and Platforms

Core Plugins

Extension Manager

Collaboration / Projects

API

Rust API

Debugger

Documentation

Other

With such a large release, we’ve done more than even the list shown here. For even more details, check out our closed milestone on GitHub.