Binary Ninja Blog

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.

First and foremost, when we originally implemented UI plugins, the following was not the use-case we had in mind. That said, UI Plugins are extremely powerful, and allow you to customize Binary Ninja’s interface to your heart’s content, for fun and for profit!

New year, new Binary Ninja version, new survey and sweepstakes. Take the survey to help shape the future of reverse engineering tools and have a chance to win some great prizes! The survey starts today, January 26, 2023 and will end on February 8, 2023 at 12pm EST.

The future is now; Binary Ninja 3.3 (Arrakis) is available. You may have noticed that we’ve renamed our milestones based on an alphabetical list of famous Sci-Fi/Fantasy planets, and the first release in this theme is named after the famous desert planet from Dune - Arrakis. The bytes must flow!

So what spicy goodies are in this release?

• Decompiler Improvements
  • Parameter Rejection
  • Improved Objective-C
  • Automatic Outlining
• Debugger
• Type Interactions
  • Create Array Dialog
  • Import / Export Header Files
  • Enumeration Dialog
• More Windows Improvements
  • SEH Prolog/Epilog Inlining
  • Type Libraries and Signatures
• Enterprise Improvements
  • Named Snapshots
  • SAML Support
• Many More