Binary Ninja Blog

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.

Check out our latest YouTube Short, “Working with Functions!”

Two weeks ago, we announced that our new AI-powered reverse engineering service, Binary Ninja Sidekick, would soon be available in limited fashion to a number of early access customers. This week, we have completed our soft-launch. A number of lucky customers have been using the service since early this week and have helped us with some initial testing.

C++’s standard library containers are extremely convenient, as standard library components should be. They’re so convenient that you’ve probably only ever needed to remember their Big-O notations for insertion, deletion, and search after your data structures final exam. However, beyond their cold, clean, bare, templated masks, C++ container templates are quite complex.

Most of the time, when you’re using a container, you don’t care about how it allocates or frees memory. But, because the specifics of allocation can sometimes matter, C++ exposes the allocation backend to you through a default template parameter. The default allocator most of the standard library uses for its containers is std::allocator<T> on the type you’re allocating.

Now, from a programming perspective, this is great. C++ is well-known for the control it allows you to have over memory, alongside other primitives. It provides this control while still trying to be user-friendly by hiding options most programmers will never need to use. Unfortunately, as reverse engineers, these things are no longer hidden from us. And, since even default templates are a form of code reuse and generation, those default parameters can balloon into type signatures of insane sizes at compile time.

This begs the question: What does something as simple as vector<string> really look like? And how bad can it get?

This year, we’re preparing to ship a number of very important features in a big upcoming update for Binary Ninja. One of those features will be coming in the form of a new plugin: Sidekick. Sidekick is a free plugin, but many of its features work with a paid service that leverages several different machine learning models. We’re currently taking sign-ups for our limited public release of the service, which is currently planned for the week of January 15 (exact date TBD).

If you’re interested, or just want more information, please head over to our brand-new Binary Ninja Sidekick site for more details. Anyone that makes an account before the limited public release will be placed in our pool of early access candidates and we’ll reach out to you with further instructions if you’re selected.

The Flare-On challenge is the Olympics for reverse engineers. This year, while celebrating the 10th sequel of the event, the organizers set “a new standard for difficulty and creativity” (words from last year’s challenge solutions). As a long-time player, I was very excited to complete all challenges in just over a month.

In this write-up, I will discuss two challenges (5th and 13th) and share how Binary Ninja can easily tackle obfuscated code. I will put more focus on the obfuscation rather than the validation algorithm. If you wish to read full write-ups, I recommend you refer to the official solutions published by Mandiant.

Thanks to Mandiant and the Flare-On team for another great event!

With a slew of decompilation improvements, Binary Ninja 3.5 (Coruscant) has completed its jump from hyperspace dev with even more improvements to the decompilation quality and many other quality of life improvements across the UI, API, documentation, debugger, and more! Here’s a list of the biggest changes, but don’t forget to check out the full list of changes with even more fixes and features.

• MOD/DIV Deoptimization
• Automatic Variable Naming
• UEFI Support
• Heuristic Pointer Analysis
• Dead Code Elimination Improvements
• Type Library Deserialization
• TTD Debugging
• MH_FILESET graduated
• Leaks-Be-Gone
• Experimental Features
  • Components UI
  • DWARF Import
  • DWARF Export
• Many More

To find out why our mascot for this release has a pitchfork and more on nerdy naming, read below the fold. For the summary of Braize’s (3.4) major new features (including one surprise feature that appeared mid-roadmap), here’s the highlights:

• Inherited Types (C++ Support)
• Automatic Outlining
• Sparse Switch Recovery
• Import from BNDB
• Enterprise Improvements
• Debugger Improvements
• Experimental Features
  • Components UI
  • MH_FILESET
• Many More

You’ll notice the theme of this release has been major improvements in decompilation, we’re really excited with the quality of improvements for the first three major features described above and they’re joined by several other important improvements as well.