Binary Ninja Blog

The Binary Ninja development team here at Vector 35 is hard at work on the next version of Binary Ninja. 4.1 will bring some awesome features like ARM Linux builds, the automated base address detection feature we showed off last week, and some decompiler output improvements you won’t want to miss! These first two are available now to customers with active support via our dev channel.

Unfortunately, the wait for 4.1 will be just a little bit longer. As a result, we’ve decided to release an updated build for our current stable release, 4.0.5336, that addresses some issues we felt couldn’t wait.

We recently fixed an information leak in our Sidekick plugin. Specifically, a user’s API keys could be leaked when sharing a .BNDB database with someone else. Thankfully, this issue did not expose user data in any way, but could have been used to gain free access to the service with another user’s key. Additionally, this issue was discovered during internal testing and we do not have evidence it was abused externally prior to identifying and correcting the issue.

If we have made this mistake, it’s likely other plugin authors may have as well, so we wanted to write up this post to provide more details about the issue and what we’ve changed in the API itself to mitigate it.

One of the first steps a reverse engineer must take when statically analyzing a position-dependent raw firmware binary is to determine the base address of the image at runtime. Those who have had the pleasure of reversing a bootloader or raw embedded Linux kernel image understand that this can be a frustrating process of trial and error.

Today, we’re excited to unveil a new feature in Binary Ninja that aims to alleviate this challenge. Even better, this is available now in builds on our development channel!

A while ago, I was working on adding support for Windows kernel debugging in our debugger. It did not take me long to make the typical two-machine remote kernel debugging work since we already have code to leverage the DbgEng API. The only difference for starting a kernel debugging session is to call AttachKernel instead of CreateProcess2.

However, I was unable to quickly figure out how to start a local kernel debugging session. The documentation does not mention it! I tried to send a few different connection strings to AttachKernel, but had no luck.

There are multiple ways to deal with the issue, but I figured I should debug WinDbg and see how it actually starts a local kernel debugging session. And, of course, I chose to do so with Binary Ninja’s debugger.

One of the more frustrating situations as a reverse engineer is when the architecture of your target is not supported by your decompiler. So, today, let’s dive into one of our latest creations: the official Binary Ninja nanoMIPS architecture plugin.

Earlier this year, we opened up Sidekick for early access as we continued to refine its features in preparation for today’s launch. Now that we are here, we would like to officially introduce you to Sidekick - your AI-powered extension to Binary Ninja that makes reversing easy.

Binary Ninja’s extensibility allows for powerful customizations, one of which is the ability to tailor how data is presented in Linear View. This capability is primarily provided by the DataRenderer class (C++, Python). In this post, we’ll delve into how to leverage a DataRenderer to create custom representations for specific types of data, enhancing the clarity and utility of Binary Ninja’s interface for reverse engineering tasks.

Can you believe it’s been over 2 years since our last major version increment? We certainly couldn’t at first, but when we look over the list of changes since then it seems almost surprising we haven’t done it sooner! We’re super pleased to announce Binary Ninja 4.0 is available. It includes an absolutely massive set of improvements, new features, and fixes. Far more than any previous release and we can’t wait for everyone to try it out!

We’ve got so many changes that we’re not going to go into detail on each of them in a single blog post. Instead, we’ll be doing a quick summary of some new features and then over the next few weeks we’ll be doing deep dives into them.

Just check out this list of just the highest impact changes, and you’ll see why that’s the case:

• Binary Ninja Free
• Types View / Type Archives
• UI Refresh
  • New Tab
  • Themes
  • Sidebar Refactor
  • Icons
  • Symbols View
• Windows Improvements
  • Windows Platform Types
  • Kernel Types
  • COMPanion
  • Local/Remote Windows Kernel Debugging
• Documentation Refresh
• New Architecture: RISC-V
• Commercial Only
  • Projects
  • New Architecture: nanoMIPS
• Sidekick
• Many More

One of the many issues facing the development of a complex software product like Binary Ninja is discoverability. In UX design, a feature is “discoverable” if a user is able to locate that feature, understand what they can do with it, and use it to accomplish their goal.

There are many ways of solving this problem, but our favorite is the Command Palette. Unfortunately, the Command Palette itself has a bit of a discoverability problem. So, today, we’re going to show it off a bit and explain why you should consider spending more time using it.

Reverse engineering COM (Component Object Model) objects has traditionally been a complex and time-consuming process, involving a deep understanding of interface structures, GUIDs (Globally Unique Identifiers), and the intricate relationships between COM components. With the upcoming release of Binary Ninja 4.0, this task has become significantly more manageable thanks to several enhancements that improve the reverse engineering workflow for COM objects.