Binary Ninja Deep Thoughts

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

State of the Ninja: Episode 9

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!

Read more

Automated Opaque Predicate Removal

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.

Read more

State of the Ninja: Episode 8

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.

Read more

BNIL Series Part 1 : LLIL

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.

Infiltrate and Vector 35

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.

Read more