Binary Ninja Blog

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.

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.