Binary Ninja Blog

What a release! Even we were surprised when we started tallying up all the major improvements since 4.0. Even though this is a minor version increment, the list of improvements is huge. It’s hard to pick favorites as we’ve seen major improvements in decompilation quality, multiple new architectures, type library improvements across most of the supported platforms and so many other important new features.

• Decompiler Improvements
• Linux ARM Builds
• UEFI Enhancements
• BASE
• UI Improvements
  • History Widget
  • Address Display / Stack View
• macOS/iOS/Objective-C Improvements
• Fallback Libc
• Debugger
  • Debugger Annotations and Memory Map API
  • Time-Travel Debugging
• Architecture/Platform Changes
  • Platform Changes
  • Octeon Support
  • TriCore (paid Add-on)
• Open-Source Contributions
• Many More

Decompilation is an incredibly complicated process with a huge number of optimizations, analyses, and transformations happening behind the scenes. Luckily, Binary Ninja has many advanced features that expose access to this internal information. Whether it’s across the ILs, analysis, or the type system, there are tools built in to help display how things work. Not only do we use them internally, but you can leverage them as well to save time and gain understanding! Read on to learn about some of the features that exist for exactly this purpose.

We’d like to introduce you to the upcoming features for the next release of Sidekick! If you want to see some of the new features in action, check out the demonstration we gave during a recent Binary Ninja live stream. This post is the first in a series that will explain how it works and showcase its capabilities. To start the series, we want to first highlight what is unique about our approach and why Sidekick is more than just a thin wrapper around a Large Language Model (LLM).

For the upcoming Binary Ninja 4.1, we will be releasing a new implementation of our decompiler’s control flow recovery. You can try it today by switching to the development channel and updating to the latest build. It isn’t fully optimized yet and may produce non-optimal results in some cases, but there should already be improvements in readability of the output, including a reduction in nesting depth and a significant reduction in the complexity of conditional expressions.

This new implementation aims to improve the readability of the decompiler output while simultaneously improving accuracy. It also aims to significantly improve maintainability, allowing us to iterate on our decompiler faster. We have additionally added a new suite of tests to allow us to make changes to the decompiler and have more confidence that the changes haven’t caused regressions in accuracy.

Coming in the Binary Ninja 4.1 release (and out now on dev!) is the ability to show instruction addresses and stack offsets in a number of convenient ways.

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.