Binary Ninja Blog

We are so happy to announce the release of our long awaited Binary Ninja Enterprise product. Throughout my 17-year reverse engineering and vulnerability research career I’ve wanted a way to collaborate with my teammates and coworkers. We tried many open source solutions which would eventually get out of sync or corrupt our database. We even wrote our own solution thinking, “We’re not going to make the same mistakes all those other schmucks made!” Only after months of wasted effort did we realize how difficult the problem was and that the platform we were trying to implement collaboration with was very deeply incapable of supporting such a feature.

When we started developing Binary Ninja in 2015 we knew at a fundamental level that we needed the product to be able to support collaboration. This goal influenced many of the design decisions throughout our development. Finally, two years ago (almost to the day), we committed the first lines of code on the product that we’re releasing today. We’re so proud of the product our engineers created, especially Glenn and Josh who saw our vision through.

As we kick off this year’s Reverse Engineering Survey (don’t forget to submit before October 7 to be eligible for the prizes), we wanted to spend some time digging into last year’s results and showing some of what we learned. And surprisingly, that includes the question of exactly how humble are reverse engineers! In total, our 2020 survey had 582 responses, of which 52% were Binary Ninja users. That’s not surprising since people likely to hear about the survey are necessarily more likely to already be Binary Ninja users.

Given that, this is definitely a biased sample of the total set of reverse engineers so make sure to take that in mind when considering the results.

The Grand Reverse Engineering Challenge is an event that tests reverse engineer’s ability to break some of the strongest methods to protect software. The protections include control flow flattening/indirection, integer encryption, virtual machine protection, and anti-debugging, etc. Most of the challenges are protected by the Tigress obfuscator. Tigress offers plenty of methods to obfuscate and protect software. It is well-known for these challenges. Attempts to solve them often lead to interesting results.

One noticeable difference from other CTFs is that the reverse engineers are asked to install a piece of monitoring software on their machine (presumably a dedicated virtual machine). The software collects data on how reverse engineers deal with the challenges. The collected data will be later used for research purposes. I am glad to contribute to the research community, so I do not feel these requirements intrusive. After all, I did it on a clean VM.

In this blog post, I will explain how I solved one of the obfuscated challenges with Binary Ninja. Also, it is worth mentioning that I am lucky to win the event and earn prize money of 5,000 USD!

Binary Ninja has always had great support for user-created themes. While implementing a new theme is an easy process, designing a theme can be challenging. My goal is for this post to serve as a reference resource for those interested in creating themes for Binary Ninja. It will cover both the theory behind designing a theme, as well as the best practices for implementing one.

It’s that time again – we’ve just released another stable version, 2.4. This is the last in our line of 2.x updates, with our next stable update 3.0 coming next. While 3.0 contains a brand new UI overhaul, even this 2.4 release is chock-full of fantastic features, bug-fixes and improvements alike. The most notable new features include:

• Enhanced decompiler array support
• Search improvements
• Filtering and collapsing of types
• Plugin Manager dependency installation
• Automatic structure creation
• Function properties dialog

This blog post covers two new features from BinaryNinja version 2.3 (though both have seen some improvements on post-2.3 development branches as well!). Variable and type cross-references (xrefs) are two highly-demanded features for version 2.3. The two issues had accumulated 13 and 23 thumbs-up on GitHub, respectively. I am honored to work on such important features.

What does it take to almost completely re-write a full architecture module to get the highest accuracy AArch64/ARMv8 decompilation and lifting? Follow along as we not only talk about the improvements we’ve made since open sourcing it in October 2020, but also take a behind the scenes look at the new disassembler and how it was generated it from the ARM specification.

As we settle into our quarterly release cycle, this stable update includes changes from the past four months of Binary Ninja development. With over 600 commits and 157 issues resolved across an increasing number of repositories (most of which are open source), we continue to simultaneously launch new features, improve existing features, and resolve bugs.

The main new features for this release include new view-synchronization, type and variable cross-references, and a plethora of HLIL improvements. Read on for more!

Today’s entry is a guest-post brought to you from our friends at Kryptos Logic who have been working on a handy plugin we wanted to highlight. They were kind enough to let us cross-post their blog here, but make sure to check out the rest of their posts as well! Note, everything below this paragraph is from Jamie Hankins, not Jordan despite what the “author” tag on this post says!

It’s only been five months since the release of our HLIL decompiler and we’ve been busy on lots of fronts! Note only are we in the middle of open sourcing all of our core architectures, but we’re also launching a welcome back discount for customers who have had their support expire and are thinking of coming back and seeing everything that’s changed.

And speaking of what’s changed, just in the past three months since our last release we’ve almost 800 commits across our different repositories! That’s a lot of new changes to cover, so this is definitely not an exhaustive list, but let’s dig in!