Binary Ninja Blog

Cloud Open Beta is Live

Binary Ninja Cloud Logo >

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.

Read more

Plugin Manager 2.0

(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.

Read more

Hackathon 2019 Summary

(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.

Read more

Interface Update

(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. :-)

Read more

State of the Ninja: Episode 12

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.

Read more

State of the Ninja: Episode 11

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.

Read more

A Fast Track to Assembler Writing

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.

Read more

Change is in the air

“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.

Read more

State of the Ninja: Episode 10

This month’s state of the Ninja contains the usual mid-month status updates, including a brief summary of previous and upcoming commits, sightings of Binary Ninja in the news and online, upcoming events, and a few special announcements.

The first special announcement is an opportunity for a free Binary Ninja license!

Read more

Architecture Agnostic Function Detection in Binaries

Function start detection in stripped binaries is an undecidable problem. This should be no surprise. Many problems in the program analysis domain fall into this category. Add to that the numerous types of CPU architectures, compilers, programming languages, application binary interfaces (ABIs), etc. and you’re left with an interesting, multifaceted, hard problem. Accurate detection of both function starts and the low-level basic blocks is often the first step in program analysis. Performing this task accurately is critical. These foundational analysis artifacts are often the starting point for many automated analysis tools.

Being undecidable, there is no single algorithm to identify all function starts across the wide variety of program binaries. Among some of the approaches enlisted to try and solve this problem are machine learning algorithms (e.g. Byteweight and Neural Networks) which use signature based pattern recognition. At first glance the results of these learners look promising but they are often biased to their training set.

Other approaches to function detection (e.g. Nucleus and Function Interface Analysis) are more sensible. Their research is focused on control-flow, data-flow, and function interface analysis rather than signature detection. Yet, these solutions fall short of addressing the entire problem domain across architectures in a generalized way.

For example, the Nucleus approach can be improved upon since it relies on heuristics to handle indirect control flow. What’s wrong with heuristics? They must be updated constantly for the latest compiler constructs, and can frequently produce invalid results, especially in highly optimized binaries. Even today, many tools rely on heuristics. That’s a dilemma. Even though they solve a specific problem really well, they rarely generalize to solve an entire class of problems.

Read more