Android native reversing : from Ghidra JNI analysis to Frida hooking

Context & introduction

For the 7th edition of the HeroCTF, I decided to create some Android challenges for the first time of the history of the CTF. I wanted to do something that would force users to use Frida for dynamic analysis and prevent static analysis. Update : it didn’t work at all. The players threw the Android app code into LLMs, and the flag came out on its own.

But that’s okay, I will know it for next time.

They took everything from me

So, I decided to write an article explaining the methodology I wanted players to use.

I will also take this opportunity to explain how native libraries work on Android and talk about native Java interfaces.

You might say that other articles already exist, but in this one I will use the example of a “real” application to illustrate my point.

Let me finish

Challenge Description

Try to find the password to open this vault!

I was told that it was dangerous to let my application install on a rooted machine. I fixed the problem! I was also told that it was safer to move sensitive functions from my code to a native library, so that’s what I did!

Don’t waste too much time statically analyzing the application; there are much faster ways.

app-ctf.apk

The Java layer

In order to solve the challenge, the first step is to launch an Android virtual device (AVD) and install the application to see what it actually looks like. In the write-up I will use Android Studio AVD.

1
2
3
$ adb devices
List of devices attached
emulator-5554	device

Let’s install the APK on our device :

1
2
3
4
5
6
$ adb install app-release.apk 
Performing Streamed Install
Success

$ adb shell pm list packages -f | grep heroctf                
package:/data/app/~~1b4poT6kV7AblviUcZHcmA==/com.heroctf.freeda3-RTYZc77Wi--VPkkhLnipwQ==/base.apk=com.heroctf.freeda3

When launching the APK, we realize that the application detects that the AVD is rooted and it is not possible to enter passwords.

So I’m going to use JADX to decompile the APK and retrieve readable Java code.

1
2
3
4
$ jadx app-release.apk
INFO  - loading ...
INFO  - processing ...
INFO  - done                         

As we saw in the previous adb command, the package name is com.heroctf.freeda3, so the Java code for the main activity is located in the folder with the same path.

Application content

We can see that there is a NativeGate.java file. We can guess that a native library is being used.

1
2
3
4
5
6
7
package com.heroctf.freeda3.utils;

public final class NativeGate {
    static { System.loadLibrary("v3"); }  // => libv3.so
    public static native boolean nCheck(String input);
    private NativeGate() {}
}

Crossing the bridge to JNI

The Java Native Interface allows developers to declare Java methods implemented in native code (often C/C++). This is not specific to Android but rather to Java more generally. Developpers use this for performance reasons (C/C++ are faster than Java) or to user already existing components.

The toolset for this is the NDK (Native Development Kit).

On the Java side, there are two ways to declare a native library:

1
2
3
// The Android application must load the library
System.loadLibrary(“calc”) // libcalc.so
System.load(“lib/armeabi/libcalc.so”)

In the context of our application, we can see these lines of code indicating the use of a native library:

1
2
3
4
5
6
package com.heroctf.freeda3.utils;

public final class NativeGate {
    static { System.loadLibrary("v3"); }  // => libv3.so
    [...]
}

To be able to use a function from the native library in your Java code, you must declare a native method. This way, when this method is called, the “paired” function from the native library is executed. So, the next line telles that the native library will export a function named nCheck(String str) :

1
public static native boolean nCheck(String input);

Continuing through static analysis, we found where the exported function is used :

1
2
3
4
5
6
7
8
public abstract class CheckFlag {
    public static boolean checkFlag(String input) {
        if (input == null) {
            return false;
        }
        return NativeGate.nCheck(input);
    }
}

This line in CheckFlag.java suggests that this exported function checks the user’s input.

Reverse engineering JNI functions

We have just seen that the application uses a native library. The next step is to understand what the function does by reverse engineering the library.

What I didn’t talk about earlier is that here is two way to establish a link between a Java declaration and a C/C++ function.

The first way is by Dynamic Linking : the developer names the method and the function according to the specs such that the JNI system can dynamically do the linking. A native method name is concatenated from the following components:

Java_ prefix ;
Underscore separator ;
Fully qualified class name.

In our case, if the nCheck() method is in the class com.heroctf.freeda3.utils.NativeGate, the C/C++ function must be named : Java_com_heroctf_freeda3_utils_NativeGate_nCheck.

If there is not a function in the native library with that name, that means that the application must be doing static linking. For reasons of obfuscation, for example, a developer may not want to use a recognizable name for their function, then they must use static linking with the RegisterNatives API in order to do the pairing between the Java-declared native method and the function in the native library.

RegisterNatives function is called at the very start of the library (in the JNI_OnLoad function).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
typedef struct { 
	char *name; 
	char *signature; 
	void *fnPtr; 
} JNINativeMethod;

jint RegisterNatives(JNIEnv *env, jclass clazz, const JNINativeMethod *methods, jint nMethods); 

static JNINativeMethod methods[] = {
    {"bar", "([B)Z", (void *)native_bar}
};

If we are facing static linking during our reverse engineering, we just have to look at the structure that is being passed to RegisterNatives to find functions.

But in our case, the app is using Dynamic Linking so we just have to open Ghidra and find the function called Java_com_heroctf_freeda3_utils_NativeGate_nCheck.

Cleaning Ghidra’s mess

Here is the function found in Ghidra :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
bool Java_com_heroctf_freeda3_utils_NativeGate_nCheck(long *param_1,undefined8 param_2,long param_3)

{
  int iVar1;
  void *__s2;
  void *__s1;
  
  if (param_3 != 0) {
    __s2 = (void *)get_flag();
    iVar1 = (**(code **)(*param_1 + 0x540))(param_1,param_3);
    if (iVar1 == 0x30) {
      __s1 = (void *)(**(code **)(*param_1 + 0x548))(param_1,param_3,0);
      if (__s1 == (void *)0x0) {
        return false;
      }
      iVar1 = memcmp(__s1,__s2,0x30);
      (**(code **)(*param_1 + 0x550))(param_1,param_3,__s1);
      return iVar1 == 0;
    }
  }
  return false;
}

At the first glance, this is very messy and we can’t find Java arguments. But, we can add the jni_all.gdt file to help Ghidra recognize structures.

A really important things to know while reversing JAVA Native Librairies is that every function in native librairies takes JNIEnv* at first argument. JNIEnv is a pointer to a struct of function pointers to JNI Functions. The second argument will be the object that the function should be run on. For static native methods (they have the static keyword in the Java declaration) this will be NULL. Finally, the third argument is our argument, the String input.

The function can then be cleaned.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
bool Java_com_heroctf_freeda3_utils_NativeGate_nCheck(JNIEnv *JNIEnv,undefined8 param_2,jstring userInput)

{
  int iVar1;
  void *flag;
  jsize input;
  char *chars;
  
  if (userInput != (jstring)L'\0') {
    flag = (void *)get_flag();
    input = (*(*JNIEnv)->GetStringUTFLength)(JNIEnv,userInput);
    if ((int)input == 48) {
      chars = (*(*JNIEnv)->GetStringUTFChars)(JNIEnv,userInput,(jboolean *)0x0);
      if (chars == (char *)L'\0') {
        return false;
      }
      iVar1 = memcmp(chars,flag,0x30);
      (*(*JNIEnv)->ReleaseStringUTFChars)(JNIEnv,userInput,chars);
      return iVar1 == 0;
    }
  }
  return false;
}

Finally we understand something

That’s way better, we can see the JNI functions! It’s very simple to understand: a get_flag() function is called and its result is compared with the user’s input.

I will not loose any more time reversing the function and I will bring out Frida. Frida is a dynamic instrumentation toolkit. It allows you to inject JavaScript into the application process to hook functions and modify their behavior at runtime. It is particularly powerful here as it lets us interact directly with the native layer (C/C++) without needing to patch or re-sign the APK.

I’m going to use it to retrieve the value returned by the get_flag() function. But before that, I need to find its address.

Here is the list of commands :

1
2
3
4
var addr = Process.getModuleByName('libv3.so').findExportByName('get_flag');
var getFlag = new NativeFunction(ptr(addr), 'pointer', []);
var p = getFlag();
p.readCString();

Line-by-line breakdown:

Process.getModuleByName(‘libv3.so’).findExportByName('get_flag') Finds the address of the get_flag export in the loaded libv3.so library (ASLR managed by Frida).

new NativeFunction(ptr(addr), ‘pointer’, []) Wraps the previous address as a C function with no arguments that returns a pointer.

getFlag() Calls the function, the result p is a NativePointer (char *).

p.readCString() Reads the null-terminated string at this address and returns it (UTF-8).

One small difference, however, is that the library is not loaded immediately into the application, so the most practical approach is to attach to script to an existing process. You must enter a random password into the GUI to force the load of the library.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
$ frida-ps -Uai | grep com.hero  
2505  freeda3                  com.heroctf.freeda3

$ frida -U -p 2505 -l get_flag.js
     ____
    / _  |   Frida 17.3.2 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://frida.re/docs/home/
   . . . .
   . . . .   Connected to Android Emulator 5554 (id=emulator-5554)
Attaching...                                                            
Root detected - flag unavailable

Root detected - flag unavailable ; oh no, it looks like we missed something. Lets go back to Ghidra.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
char * get_flag(void)

{
  int iVar1;
  
  if (DAT_001054f4 != 0) {
    return &DAT_001054c0;
  }
  iVar1 = check_root();
  if (iVar1 != 0) {
    FUN_00102870();
    DAT_001054f4 = 1;
    return &DAT_001054c0;
  }
  return "Root detected - flag unavailable";
}

Looking at the get_flag function, we see that a check_root() function is called, and if the result is equal to 0, then the code returns “Root detected - flag unavailable,” considering that the device is rooted. We must therefore rewrite the output value to make it appear that the device is not rooted.

1
2
3
4
var addr = Process.getModuleByName('libv3.so').findExportByName('check_root'); 
Interceptor.replace(addr, new NativeCallback(function () {
  return 1; 
}, "int", []));

The script works like the one above: we hook the function that checks the flag by finding its address, then we rewrite its return value. The value will always be 1, as if the device were not rooted

Now we can combine the two parts:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Java.perform(function () {
  var addr = Process.getModuleByName('libv3.so').findExportByName('check_root'); 
  Interceptor.replace(addr, new NativeCallback(function () {
    return 1; // OK
  }, "int", []));
  console.log("[+] Root device set to false")

  var addr = Process.getModuleByName('libv3.so').findExportByName('get_flag'); 
  var getFlag = new NativeFunction(ptr(addr), 'pointer', []); 
  var p = getFlag(); 
  console.log("[+]",p.readCString());
});

And here is the flag !

Flag

Hero{F1NAL_57EP_Y0U_KN0W_H0W_TO_R3V3R53_4NDR01D}