Reverse engineering of Android applications is usually considered as somewhat effortless because of the possibility of retrieving the Java representation of the application’s code. An attacker is basically able to read through a human-readable version of the code in order to quickly extract the intellectual property, gather some assets, find vulnerabilities and so on. Nowadays, most of the Android application editors are aware of this weakness and try their best to make reverse engineers’ work harder. They often rely on integrating obfuscation strategies or shifting sensitive features from Java/Kotlin side to native code thanks to Java Native Interface (shortened JNI). However, the reverse engineering process gets much more complex when they decide to use both – that is, obfuscated native code. As a result, statically looking into the native library’s disassembly turns out to be pretty tedious and time-consuming. Fortunately, inspection at runtime is still possible and offers a convenient way to efficiently grasp the inner mechanisms of the application, even over obfuscation. Since protections against regular debuggers are quite common among popular applications, using a Dynamic Binary Instrumentation (DBI) framework such as Frida, remains a great option for a thorough examination. Technically speaking, Frida allows users to inject their own code at the beginning and the end of a native function or replace the whole implementation. Though, Frida lacks granularity at some point, especially when it comes to inspecting the execution at the instruction scale. In this context, QBDI, a DBI framework we have developed at Quarkslab, can give Frida a hand determining which parts of the code have been executed when calling a given native function. This talk aims to present how Frida and QBDI can be used together for making the native reverse engineering process easier on Android.
Tom Czayka (Quarkslab)
Tom Czayka is a security researcher working at Quarkslab. He is interested in everything related to Android operating system, especially internals. He is keen on reverse engineering, instrumentation, fuzzing and low-level programming. As well, he is into developing tools which assist reverse engineers and make their daily work easier.