Binary Ninja Blog

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.

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 an announcement that our merchandise store is re-opening this week with international shipping options available!

Malware authors often use many anti-analysis techniques to prevent reverse engineering tools from working against their binaries. One of the main goals of Binary Ninja is to turn manual analysis problems into small scripts to automatically solve such problems. Below, we’ll show how to automatically remove a class of anti-analysis automatically with Binary Ninja’s API by leveraging our architecture agnostic Medium Level IL (MLIL), data flow, and patching.

EDIT 2017-09-22: Added more detail to the pricing charts to differentiate between Named and Computer licenses

EDIT 2017-09-26: Fix incorrect year on purchase period for license extension

Many of you are probably aware that our mailing list posts take the form of State of the Ninja emails. We don’t post to the list frequently though, generally reserving it for situations with big announcements.

That said, we’d like to put some more regular updates with what we’re up to available so we’ll be posting those here on the blog. Look for an update in the middle of each month describing the current State of the Ninja. We’ll be offsetting that with a more technical deep dive into a particular component or feature of Binary Ninja at the beginning of each month in our own tick tock schedule.

One of the questions we most often hear is “Why did you invent yet another IL?” to which we respond, “we didn’t – we invented an entire FAMILY of ILs.” Which doesn’t really answer the question, but it makes us smile. In the interests of actually answering the question though, we recently presented with Sophia from Trail of Bits to talk about Program Analysis using Binary Ninja.

As noted in our last post though, there’s a lot left to be explained about how our IL works and to that end, Peter has just finished writing up a developer’s guide to our LLIL.

The main goal is to help clarify how some of the design in the IL impacts how you interact with it. We plan on some future updates to help explain the process of writing your own Archiecture module (IE, writing to Lifted IL), as well as new guides as we release new IL’s. We look forward to many more plugins being published that take advantage of all the analysis provided by each IL.

The documentation itself is open for public comment or feedback, feel free to issue a pull request or file an issue on our repo where the code lives.

We’ve just returned from a trip down the road to Miami, FL. What made us brave the road hazards and dangerous drivers in Miami? Why, our favorite conference: Infiltrate from Immunity. What makes Infiltrate so good? First, there’s no “lobby con”, but rather the whole conference feels like a lobby con but with much better food and drinks. Because the meals are provided and hang-out times are included, there’s plenty of opportunities to meet new, interesting people.

A number of folks have pointed out that the website hasn’t changed very much since we launched the product so we thought we’d remedy that. Not only do we have a changelog, but we’ve also launched our blog!

You might notice that the first entry from Andrew is a repost. He originally wrote it last year and published it under his personal blog, but we’ve polished it up a bit and are moving it here so we can have all of our Binary Ninja related blog posts in one place.

We plan a variety of types of blog posts. From brief overviews of our development plans and timelines, to in-depth technical discussions of core design decisions, to walk-throughs of specific features so keep an eye on this space.

Read on for an overview of what we’ve been up to these past few weeks.

For me, the fun in writing a disassembler drops off sharply after the first. It becomes just plain tedious. For our thumb2 disassembler, we looked for a more interesting way to construct one, and found benefits beyond reducing boredom: serviceability and accuracy.

Spoiler, what we’re doing is generating a disassembler from the ARM specification (spec) itself. This involves some intermediate steps and parsing, which we discuss below.