It’s only been five months since the release of our HLIL decompiler and we’ve been busy on lots of fronts! Note only are we in the middle of open sourcing all of our core architectures, but we’re also launching a welcome back discount for customers who have had their support expire and are thinking of coming back and seeing everything that’s changed.
And speaking of what’s changed, just in the past three months since our last release we’ve almost 800 commits across our different repositories! That’s a lot of new changes to cover, so this is definitely not an exhaustive list, but let’s dig in!
Here’s a summary with details of our favorite changes for this release.
While our Python documentation is often something we receive compliments for, there was a glaring lack of documentation of our other APIs. Thankfully, with this release we now have early progress for C++ and UI documentation. You’ll notice that actual documentation is sparse, but now that we have a framework we can test it on, expect to see new APIs have documentation and we’ll begin working backward on the archive to flesh out other APIs as well. And of course contributions are welcome as well.
Despite its innocuous sounding name, this feature is a major improvement to the readability of HLIL. Consider the following before/after image:
A lot of work went into both making sure the implementation was performant and also did not over-optimize nor under-optimize and we’re very happy with the results.
Missing type information for commonly included libraries can dramatically harm static analysis. With the release of 2.2 we’ve take a big step in improving our type libraries, not only for Windows with the addition of type information for advapi32
, kernel32
, kernelbase
, and user32
on both x86 and x64, but also by including syscall libraries for linux on many different architectures:
Here’s another look at just how much nicer things look with good type libraries:
Want the ability to inform Binary Ninja’s value-set analysis and constant dataflow propagation? Now you can! There’s a lot to this amazing feature–so much that we put it into a separate blog post.
Sometimes an improvement isn’t about adding new code, but removing old code. In this case, removing Python 2.x support allows us to support newer type annotations and also is required to support new platforms such as MacOS on Apple Silicon. Those type annotations will improve plugin writing and make larger codebases easier to maintain. Thankfully, ever since our last stable release, all plugins in the plugin manager have supported Python 3.x. If your plugin still needs porting, we’re happy to help answer questions about the process in the public support slack.
To see even more of the improvements that didn’t make this summary, check out the long list of closed GitHub issues.