How to debug android native libraries using JEB decompiler?

5 min readDec 3, 2023

Hello guys, welcome back to the new blog.
In this blog, again I am going to show you one more method to debug native libraries of an Android application and get the secret stored in it using JEB.

Links —

Tool -> JEB Decompiler version 4

2. Bypass debugger protection and debug native libraries using IDA Pro.

3. Debug native library using GDB debugger (open source free).

I am going to demonstrate this using the “hpandro” vulnerable app which contains different activities, out of which the “backdoor7” activity is what we will look at today.

What is and why is native code used in apps?
Native codes are written in C/C++ and compiled into binary files that can be linked to mobile applications (in Android one can find it under the libs folder based on your device architecture). iOS apps are developed in Objective-C or Swift programming language. Some developers use this library (.so files) to hide some sensitive code like encryption keys, OTP generation, root detection, debugger detection, Frida detection, or some business logic. Now to connect Java code with Native C/C++ libraries, the JNI framework is used, which allows JVM to call and be called by native libraries. Further in detail, please check this blog to learn about native libraries.

Summary of what is the activity about.
The hpandro has one activity named “backdoor7” which compares two codes, one user input (4-digit PIN) and the second 4-digit code generated by the native library at runtime. So, if the code entered by the user is correct, then the native code will return some boolean value and the secret flag will be revealed. On opening, the library based on the Android architecture in IDA Pro, radare 2, Ghidra, or JEB we can see that the native library contains one JNI call “Java_com_hpandro_androidsecurity_ui_activity_task_misc_Backdoor7Activity_hello” which has the logic of “strcmp” method. Upon inspecting, we can see that the r14 register holds the user input, and the r12 register holds the value generated by the native code.

3 — Hello method that will take user input

How to debug native library with the JEB decompiler?

Step 1 — Open the JEB decompiler -> open the <app_name>.apk in JEB. Remember, to set the ‘ “android:debuggable=”true” ‘ flag in manifest.xml to make the app debuggable.
Note — JEB decompiler v4.0 will open so many tabs so have at least 8GB of RAM. Also, I think there is some protection to read memory values after Android 8, so please use Android 8 or 7. If you are using Android 8+ then please download the latest version of JEB.

Step 2 — Navigate to “Bytecode/Hierarchy” on the left panel and search for “Backdoor7Activity”. Double-click on the class name and we will be able to open the smali code in the JEB decompiler. In the Project Explorer view -> navigate to the libraries folder and open the library based on your Android architecture.

Step 3 — As we know the “hello” method is responsible for taking the user input in the native library and comparing it inside the library using JADX-GUI. So, add a breakpoint as shown below in the smali code and in the native library add a breakpoint on registers r14 and r12.

Step 4 — Go to the “Debugger” menu and click the “start” button. It will open a dialog box named “Attach the debugger” -> click the “Debug” window and in it, you will see the device ID and process information -> click “Attach” after selecting two options in this window.

Step 5 -After getting connected and the analysis is finished by the JEB decompiler -> click the “Run” icon from the toolbar to resume the process and enter some random value in the app, which will make the process break at the mentioned breakpoint. Now as a normal debugger, we have some other icons, named step in, step out, step over. Click step into and it will step into the native library.