Binary Ninja Blog

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.

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!