{"id":901,"date":"2018-10-08T09:45:30","date_gmt":"2018-10-08T17:45:30","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=901"},"modified":"2018-10-08T09:45:30","modified_gmt":"2018-10-08T17:45:30","slug":"android-ndk-libraries-signatures","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/android-ndk-libraries-signatures\/","title":{"rendered":"Android NDK Libraries Signatures"},"content":{"rendered":"

In this blog post, we present a new batch of native signatures released with JEB3 to identify Android Native Development Kit (NDK)<\/a> libraries. <\/span><\/p>\n

First, let\u2019s briefly give some context. The Android NDK is a set of tools allowing developers to embed compiled C\/C++ code into their Android applications. Thus, developers can integrate existing native code libraries, develop performance-sensitive code in C\/C++ or obfuscate algorithms with native code protectors.<\/span><\/p>\n

In practice, native code within Android applications comes in the form of ELF shared libraries (\u201c.so\u201d); the native methods can then be called from Java using Java Native Interface (JNI), which we described in a previous blog post<\/a>.<\/span><\/p>\n

NDK Pre-Built Libraries<\/span><\/h3>\n

Android NDK provides some <\/span>pre-built<\/span><\/i> libraries that can be linked against. For example, there are several C++ Standard Template Library (STL) 1<\/a><\/sup> , or the Zlib decompression library<\/a>.<\/span><\/p>\n

As an example, let\u2019s compile a “hello world” Android NDK C++ library with NDK r17. By default, the C++ implementation will be gnustl<\/em> — the default choice before NDK r18. <\/span><\/p>\n

Here is the C++ code:<\/span><\/p>\n

<\/p>\n

When compiled with Android Studio’s default settings, libraries are linked dynamically<\/i>, and libgnustl_shared.so<\/em>\u00a0is directly included in the application — because it is not a system library –, for each supported Application Binary Interface (ABI).<\/p>\n

\"\"
Files hierarchy of the Android application containing our “hello world” native library<\/figcaption><\/figure>\n

If we open the ARM library we can pretty easily understand the — already convoluted — logic of our “hello world” routine, thanks to the names of gnustl external API calls:<\/span><\/p>\n

\"\"
Control-flow graph of ARM “hello world” with gnustl dynamically linked. Note that JEB displays mangled names when API calls correspond to external routines.<\/figcaption><\/figure>\n

Now, Android NDK also provides <\/span>static<\/span><\/i> versions for most of the pre-built libraries. A developer — especially a malware developer wishing to hinder analysis — might prefer to use those. <\/span><\/p>\n

When compiled in static mode, gnustl library is now \u2018included\u2019 in our native library, and here is our “hello world” routine:<\/span><\/p>\n

\"\"
Control-flow graph of ARM “hello world” with gnustl statically linked. Subroutines bear no specific names.<\/figcaption><\/figure>\n

In this case, the analysis will be slowed down by the numerous routine calls with no specific names; each of this subroutine will need to be looked at to understand the whole purpose. <\/span><\/p>\n

This brings us to a common reverse-engineering problem: is there a way to automatically identify and rename static library code, such that the analyst can focus on the application code?<\/span><\/p>\n

JEB3 NDK Signatures<\/span><\/h3>\n

That’s when JEB native signatures come to the rescue! Indeed JEB3 now provides signatures<\/span>\u00a0for the following Android NDK\u00a0 static libraries:<\/p>\n