Binary Ninja Blog

It’s been just under 4 months since we officially launched Sidekick 1.0. During that time, we have been busy making improvements and creating new ways to make reversing even easier. All of that hard work has culminated into the release of Sidekick 2.0, which we are pleased to introduce to you today.

We don’t increment major version numbers lightly, and Sidekick has earned this bump with a major new feature that will change the way you reverse engineer in addition to other improvements and fixes.

Not long ago, we gave a sneak preview of the Analysis Workbench (formerly called the Analysis Console) and wrote a blog introducing its concepts in advance of this release. With the Sidekick 2.0 release today, it’s here and ready to save you time and effort.

Sidekick 2.0 introduces a powerful set of features that significantly enhance firmware analysis capabilities. In this post, we’ll demonstrate how Sidekick, in conjunction with the Firmware Ninja plugin (currently in development) for Binary Ninja, can streamline the process of analyzing Memory Mapped I/O (MMIO) in firmware samples.

Sidekick 2.0 includes a set of powerful features that can help you accomplish a variety of tasks. Today, we will be applying several of them to the task of de-obfuscating strings in a malware sample called Amadey.

Amadey, as explained in its Malpedia entry, is a botnet that periodically sends information about the system and installed AV software to its C2 server and polls to receive orders from it. Its main functionality is that it can load other payloads (called “tasks”) for all or specifically targeted computers compromised by the malware. This particular malware sample employs an obfuscation technique that stores the strings referenced by the binary as encrypted strings that are then decrypted during runtime. This makes it more difficult for analysts to reverse engineer and understand what the malware is doing and also prevents anti-virus software from identifying it.

Big thanks to Josh Reynolds from InvokeRE for giving us the Amadey sample and working with our team to improve Sidekick’s malware analysis while we were working on this post.

New in version 4.1, Binary Ninja now has a fallback type library for libc-like libraries. We showed it briefly in the Binary Ninja 4.1 Feature Stream and also showed one screenshot in our 4.1 announcement blog post.

This post will go into more detail as to what it is, how it works, and how it makes your reverse engineering experience better.

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
• 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.