New in version 4.1, Binary Ninja now has a fallback type library for libc-like libraries. We showed it briefly in the Binary Ninja 4.1 Feature Stream and also showed one screenshot in our 4.1 announcement blog post.

This post will go into more detail as to what it is, how it works, and how it makes your reverse engineering experience better.

Type Library Recap

Before looking into the fallback type library, let’s do a quick summary of how types are applied in Binary Ninja.

Binary Ninja provides type libraries and type archives. Type libraries are intended to help analyze imported functions, which will be introduced to the binary view when the target binary depends on a library that matches the type library’s name (or alternate_name).

Let’s create a simple type library.

tl = TypeLibrary.new(Architecture['x86_64'], "libc-test.so")
tl.add_alternate_name('libc.so')
tl.add_alternate_name('libc.so.6')

The type library above will match on libc.so, libc.so.6, and libc-test.so.

To learn how to create a type library see the documentation and check our example.

Included with the program download, we provide several type libraries for different architectures and platforms. They will be applied automatically and you can also put your own type libraries into your user folder.

Why Fallback?

So what’s a fallback type library and why does it exist?

Honestly, there are still some platforms/architectures where our existing type libraries do not exist or may not be correctly applied. Although in most cases our heuristic analysis is good enough to identify parameters and some types, it is always better to have types for function signatures even if they’re generic compared to an exact type library for a specific architecture.

Here are two cases where our previous type system fails:

Libc Doesn’t Match the alternate name

You may have noticed that the typelib must have a matched alternate name. What if the binary depends on a libc with an unusual name?

Unfortunately, it happens. For example, our armv7 libc typelib matches libc.so or libc.so.6, which are commonly used. But in the following case, the binary depends on libc.so.0, which is a uClibc library. As a result, the existing type library won’t be loaded into the binary view, and functions like scanf and malloc won’t have types.

>>> bv.platform.type_libraries[-2]
<typelib 'libc_armv7.so.6':armv7>
>>> bv.platform.type_libraries[-2].alternate_names
['libc.so', 'libc.so.6']
>>> bv.libraries
['libdl.so.0', 'libpthread.so.0', 'libcrypto.so.1.0.0', 'libc.so.0']

New Platforms

Recently, we added several new architectures: RISC-V, nanoMIPS, and Tricore.

Platforms on these architectures don’t yet have libc type libraries. The fallback type library can be used as a temporary solution in that situation.

Similarly, the fallback type library should be helpful when you are working on a custom platform/architecture and don’t want to make your own type libraries.

How Fallback Types Work

To solve such cases, starting in version 4.1, we have added a fallback type library. This fallback type library is created at runtime (during platform initialization) and will be introduced into the binary view when:

1. The binary depends on a “libc-like” library.
2. We don’t find a matching type library for this platform.
3. The platform enables the fallback type library.

Examples are always better than an explanation. Check the following examples:

On a RISC-V ELF:

On a binary depending on libc.so.0:

Try it now!

The fallback type library is available on both dev and the 4.1 stable. Enjoy your reverse engineering with Binary Ninja!