Binary Ninja Blog

Is Microsoft shipping a hidden binary to your computer – inside the registry?

A few weeks ago I was watching a YouTube video that covered my earlier research on the UCPD driver, and for a split second I saw a registry key that I have been searching for an example of for some time. I contacted the video’s author and obtained the key from his machine. It was Base64 encoded and to my surprise, once I decoded it, it started with MZ.

Sure enough, it’s a valid Windows executable sitting inside a registry key. This post is the story of both taking it apart as well as the bug I found that means the whole mechanism is dead anyway.

Ten years snuck up on us. It was only a few months ago that we realized how close we were to ten years of shipping Binary Ninja to customers. It’s been an exciting journey and we’ve seen a lot of changes along the way. Our goal was nothing short of shaking up the decompilation market. We wanted to introduce some new ideas and challenge the status quo in how decompilation was done.

When we kicked off our tenth anniversary a few days ago, we promised a dedicated post with specifics behind our upcoming pricing changes and the rationale behind them. This is it! Much like we’ve done previously, we’ll walk through the changes and give you plenty of time beforehand.

The short version:

• Non-Commercial is getting cheaper
• Commercial is going up in price
• Our “introductory” Ultimate pricing is ending
• The renewal discount is changing and rewards auto-renewal
• Enterprise is moving from one-size-fits-all bundles to an add-on structure
• Finally, yes, despite industry trends, the product will remain a perpetual license

Ten years ago tomorrow, we shipped the first build of Binary Ninja. In the beginning, there were just four of us looking to take on the monumental task of building a commercial-grade decompiler from scratch. We knew it would be a lot of work, but we were excited to take our ideas about how we could improve the state of the art and make a difference in a community we had long been involved in. A decade later and we’ve had tens of thousands of customers put their trust in us. Other than the name and having a dark theme, the product feels light-years different from the version we first launched with. And the most surprising thing of all? The amazing community that has grown around the tool. The super active plugin ecosystem, Slack, people posting tips on YouTube, and all the amazing feedback we’ve been given over the years have truly blown us away.

Given all that, we’re going to celebrate it in style. Over the next ten days we’re running 10 Days for 10 Years: our first-ever sale, a giveaway every single day, and more blog posts covering where we came from, where 6.0 is going, and a fresh new facelift for the brand.

Today we’re releasing a new “R2” for Jotunheim. This second stable release of 5.3 primarily contains stability fixes with a heavy emphasis on crashes and hangs (in part thanks to our new Sentry infrastructure). This release should result in a much more stable reverse engineering experience.

As always, customers with active support on the development branch have access to these changes and more.

For Binary Ninja 5.3, we’re bringing features and fixes across a number of areas. For improved interoperability, we’ve added Ghidra Export to the existing Ghidra Import code and have improved our IDB Import capability. For new architectures and platforms, we’ve added NDS32 to Ultimate, a new ILP32 ABI for AArch64, and a new set of APIs for “weird” architectures. And of course, we’ve made a number of improvements to the UI including a new Universal Mach-O loader UI, usability improvements to the container browser, and a new “super” command palette! Plus, changes to the debugger, enterprise features, new opt-in crash reporting to help us squash bugs faster, and so much more!

Firmware analysis, malware triage, and embedded systems reverse engineering often require extracting files from nested container formats: TAR archives inside GZIP files, encrypted firmware wrapped in multiple compression layers, or password-protected ZIPs containing “infected” malware.

Manually peeling each layer with separate tools gets old fast.

Binary Ninja’s Container Transform system automates this workflow, handling detection, extraction, password management, and multi-layer nesting while preserving the structure and provenance of each stage.

Adding platform support to an architecture plugin is one of the best ways to improve decompilation. While disassembling and lifting give us good results, they are limited in scope and cannot fill in details about the operating system. With platform support, we can add rich annotations to the analysis and get better results. Let’s look through the many systems Binary Ninja includes for implementing platform support in a plugin of your own.

Lifting is the critical step to unlocking Binary Ninja’s powerful analysis and decompilation. Often the “left as an exercise to the reader” of Binary Ninja custom architecture tutorials, it is both a lengthy process and one with a lot of subtlety. From simple instructions to flags and intrinsics, the lifting process describes the behavior of every instruction. Let’s write a lifter for Quark!

From the beginning, the most important feature of Binary Ninja has been our API. The goal is simple: your plugins should be capable of producing the same high-quality decompilation as our official architectures. In this three-part series, we will implement a complete architecture and platform using some lesser-known features in Binary Ninja. From disassembly and lifting, to calling conventions, Type Libraries, and function signatures, we will explore the many steps involved in getting and refining decompilation results. The series is intended to be used both as a roadmap for how to build your own architecture plugin and as ideas for how to improve an existing one you might already have.