Binary Ninja Blog

Welcome back. Last time we started our look into all of the new features that have landed on our stable branch since the previous stable release in May. In part two of the series we’re contiuing our look at new features added to the: UI, Architecture improvements, update functionality, and documentation fixes.

It’s been a long time coming, but it’s finally here! Version 1.2 of Binary Ninja launches today with a huge list of improvements. There’s so many features that we’re splitting this blog post into three pieces. This post covers half of the changes that have happened since the last stable release back in May. The next post will cover the remaining features from the last stable, and the third will be a higher level overview of everything that’s happened since 1.1 from two years ago.

We’re not covering all bugs fixed to keep this from turning into a full-length novel. For more details, you can always check the list of closed issues.

We’re very pleased to announce that Binary Ninja Cloud is live!

This free service is still in beta and you can track our progress and roadmap via the project’s github page as well as file any bugs you find.

Feel free to go check it out right away or read on for more details on the current features and future plans.

(NOTE: This blog is primarily intended for Binary Ninja plugin authors – the user-facing component for the plugin manager is under testing and should be released shortly)

We’re pleased to announce the imminent release of Binary Ninja’s Plugin Manager 2.0. This article is intended for plugin authors interested in updating their plugins to ensure compatibility with the new interface. The new UI will dramatically improve plugin discoverability and highlight the many great plugin authors out there.

(No, this is not an April Fools post, but we have one available if you haven’t gotten your fill yet.)

A few weeks ago we kicked off a new tradition for Vector 35, a yearly hackathon. We’ve been wanting to do this for some time now, but over the new-year break we finally got a date on the calendar and spent March 11th-15th working on a variety of fun projects.

The rules were simple: whatever you worked on during the hackathon had to be something that you weren’t doing your daily routine, and it had to sound fun to you. The plan was to explore fresh ideas, try some experiments, or build things you thought were interesting but weren’t otherwise on our immediate to do list.

With only one week of hacking we cranked out a ton of different and useful results. This is also a good chance to introduce different members of the Vector 35 team you might not have been aware of too, so we’ll break down what everyone worked on below.

(EDTIOR’S NOTE: This introduction is by Jordan, but thanks so much to Kyle for the rest of this content)

We have mixed feelings at Vector 35 about April Fools jokes. They’re often very entertaining but they also have a tendancy of making April 1 a painful day to surf the web (here’s looking at you, Stack Overflow. For that reason, we’re going to give you the choice of a real update, or a fake one! For the real update, head over to our Hackathon Recap which includes details on several major new features!

Otherwise, carry on and enjoy. You’ve been warned. :-)

Welcome to 2019! As we kick off the new year, let’s look back on all the improvements 2018 brought to Binary Ninja and Vector 35. Plus, we’ll look forward at some of the exciting plans for 2019 and beyond.

It’s been quite a while since we’ve provided an overview of some of the recent activities of Vector 35 and Binary Ninja. The good news is that means this SotN is chock-full of goodies. Read on for a new contest, several new training opportunities, and a summary of the latest code changes.

This post describes how we wrote assemblers in an atypical manner: using genetic algorithms. Instead of containing logic as to how every opcode and operand is encoded, we guess. To score each guess, and guide the next guess toward the correct encoding, we invoke a disassembler and analyze its output string. The result is a surprisingly fast process that can assemble any string output by the disassembler. In effect, we construct an assembler by inverting a disassembler. It worked for PPC, then for MIPS, and it nears completion for ARM. I believe it’s presentable as a general approach, at least for fixed-width instruction encodings.

“How is Binary Ninja better than X?” That’s one of the most common questions we hear. (The other–“What is the main strength of Binary Ninja?”– is always the api and the platform that it provides for other scripts and plugins to build on.)

But “How is Binary Ninja better than X?” For one, our ability to change binaries quickly and easily.

Why would you want to be able to patch or modify an existing binary? Many reasons:

• To test a change without a long build process
• Black box application assessments
• Maintaining or updating legacy applications
• Tinkering and learning about a system through binary modification
• Third-party patching of security flaws
• Deobfuscation

There are both low-level and high-level ways to patch binaries and we support many different methods. From low level modifications like raw hex-editing and inline assembly editing, to simple right-click patching, and even a built-in C compiler.