{"componentChunkName":"component---src-templates-post-template-js","path":"/ctf-android-apk-debug-tutorial-en","result":{"data":{"markdownRemark":{"id":"0cbfba44-2419-5ce3-9e64-fef7e9809178","html":"
\n

This page has been machine-translated from the original page.

\n
\n

Until now, whenever an APK challenge showed up in a CTF and I could not solve it with static analysis, I would just give up. But I figured it was time to properly learn dynamic analysis techniques for Android apps, so I wrote this article as part of that study.

\n

Using “Java Not Interesting” from Cryptoverse CTF 2023 as the theme, I will summarize some basic ways to dynamically analyze Android apps.

\n\n

Table of Contents

\n\n

Unpack the APK File and Perform Static Analysis

\n

First, unpack the APK file to get a rough understanding of the implementation.

\n

APK files can be unpacked with tools such as Apktool and dex2jar.

\n
apktool d app-debug.apk
\n

You can also unpack an APK by loading it in Android Studio from [File] > [Profile or Debug APK].

\n

\n \n \n \n \n \n \n \n \n

\n

To understand the overall picture of the APK being analyzed, start by checking AndroidManifest.xml.

\n

Read AndroidManifest.xml

\n

AndroidManifest.xml is the manifest file that is essential for Android app development.

\n

It declares many elements, including the SDK version the APK depends on, whether Android Studio can debug it, and the app’s permissions.

\n

For example, from the manifest file of app-debug.apk, which is the target of this analysis, we can read the following information.

\n
# The minimum SDK version is 23\n<uses-sdk\nandroid:minSdkVersion=\"23\"\nandroid:targetSdkVersion=\"33\" \n/>\n\n# The app is configured to be debuggable\n# The Main Activity is com.example.hellojni.HelloJni\n<application\nandroid:debuggable=\"true\"\n\n    <activity\n        android:name=\"com.example.hellojni.HelloJni\"\n        android:exported=\"true\">\n    </activity>\n/>
\n

Reference: App Manifest Overview | Android Developers

\n

Reference: AndroidManifest.xml - Monaca Docs

\n

By the way, if the target APK does not have debuggable set to True as in this case, you need to tamper with the APK file and repackage it.

\n

The following reference covers the details.

\n

Reference: Android Tampering and Reverse Engineering - owasp-mastg-ja

\n

Investigate the Main Activity

\n

Next, continue investigating to understand the overall structure of the target app.

\n

Once you understand the contents of AndroidManifest.xml, the next step is to look at the Main Activity that gets called first.

\n

In this binary, com.example.hellojni.HelloJni was registered as the Main Activity.

\n

If you unpack the APK in Android Studio, you can find this information in java/com.example/hellojni/HelloJni.smali.

\n

The .smali format is a disassembly of dex-format binaries used by Android’s Java VM (Dalvik).

\n

Incidentally, conversion to .smali is reversible, so you can edit it and then turn it back into an APK again.

\n

Smali files are somewhat readable as-is, but if you decompile them into Java with a tool such as smali2java, they become even easier to read.

\n

smali2java can be used with the following command.

\n
smali2java_windows_amd64.exe  -path_to_smali=./HelloJini.smali
\n

Reference: AlexeySoshin/smali2java: Recreate Java code from Smali

\n

The decompiled result of java/com.example/hellojni/HelloJni.smali obtained this time looked like this.

\n
// {{ omitted }}\n\nprivate native final Boolean checkValid ( java.lang.String p0 ) {\n} // .end method\n\nprivate native final java.lang.String getFIaggg ( ) {\n} // .end method\n\nprivate static final void onCreate$lambda$0 ( com.example.hellojni.HelloJni p0, com.example.hellojni.databinding.ActivityHelloJniBinding p1, android.view.View p2 ) {\n/* .registers 5 */\n/* .param p0, \"this$0\" # Lcom/example/hellojni/HelloJni; */\n/* .param p1, \"$binding\" # Lcom/example/hellojni/databinding/ActivityHelloJniBinding; */\n/* .param p2, \"it\" # Landroid/view/View; */\nfinal String v0 = \"this$0\"; // const-string v0, \"this$0\"\nkotlin.jvm.internal.Intrinsics .checkNotNullParameter ( p0,v0 );\nfinal String v0 = \"$binding\"; // const-string v0, \"$binding\"\nkotlin.jvm.internal.Intrinsics .checkNotNullParameter ( p1,v0 );\n/* .line 30 */\nv0 = this.flag;\n(( android.widget.EditText ) v0 ).getText ( ); // invoke-virtual {v0}, Landroid/widget/EditText;->getText()Landroid/text/Editable;\n(( java.lang.Object ) v0 ).toString ( ); // invoke-virtual {v0}, Ljava/lang/Object;->toString()Ljava/lang/String;\n\nv0 = /* invoke-direct {p0, v0}, Lcom/example/hellojni/HelloJni;->checkValid(Ljava/lang/String;)Z */\nif ( v0 != null) { // if-eqz v0, :cond_24\n /* .line 31 */\n v0 = this.valid;\n final String v1 = \"Correct!\"; // const-string v1, \"Correct!\"\n /* check-cast v1, Ljava/lang/CharSequence; */\n (( android.widget.TextView ) v0 ).setText ( v1 ); // invoke-virtual {v0, v1}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V\n /* .line 33 */\n} // :cond_24\nv0 = this.valid;\nv1 = this.flag;\n(( android.widget.EditText ) v1 ).getText ( ); // invoke-virtual {v1}, Landroid/widget/EditText;->getText()Landroid/text/Editable;\n(( java.lang.Object ) v1 ).toString ( ); // invoke-virtual {v1}, Ljava/lang/Object;->toString()Ljava/lang/String;\n/* check-cast v1, Ljava/lang/CharSequence; */\n(( android.widget.TextView ) v0 ).setText ( v1 ); // invoke-virtual {v0, v1}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V\n/* .line 35 */\n} // :goto_35\nreturn;\n} // .end method\n\n/* # virtual methods */\nprotected void onCreate ( android.os.Bundle p0 ) {\n/* .registers 5 */\n/* .param p1, \"savedInstanceState\" # Landroid/os/Bundle; */\n/* .line 25 */\n/* invoke-super {p0, p1}, Landroidx/appcompat/app/AppCompatActivity;->onCreate(Landroid/os/Bundle;)V */\n/* .line 27 */\n(( com.example.hellojni.HelloJni ) p0 ).getLayoutInflater ( ); // invoke-virtual {p0}, Lcom/example/hellojni/HelloJni;->getLayoutInflater()Landroid/view/LayoutInflater;\ncom.example.hellojni.databinding.ActivityHelloJniBinding .inflate ( v0 );\nfinal String v1 = \"inflate(layoutInflater)\"; // const-string v1, \"inflate(layoutInflater)\"\nkotlin.jvm.internal.Intrinsics .checkNotNullExpressionValue ( v0,v1 );\n/* .line 28 */\n/* .local v0, \"binding\":Lcom/example/hellojni/databinding/ActivityHelloJniBinding; */\n(( com.example.hellojni.databinding.ActivityHelloJniBinding ) v0 ).getRoot ( ); // invoke-virtual {v0}, Lcom/example/hellojni/databinding/ActivityHelloJniBinding;->getRoot()Landroidx/constraintlayout/widget/ConstraintLayout;\n/* check-cast v1, Landroid/view/View; */\n(( com.example.hellojni.HelloJni ) p0 ).setContentView ( v1 ); // invoke-virtual {p0, v1}, Lcom/example/hellojni/HelloJni;->setContentView(Landroid/view/View;)V\n/* .line 29 */\nv1 = this.getflag;\n/* new-instance v2, Lcom/example/hellojni/HelloJni$$ExternalSyntheticLambda0; */\n/* invoke-direct {v2, p0, v0}, Lcom/example/hellojni/HelloJni$$ExternalSyntheticLambda0;-><init>(Lcom/example/hellojni/HelloJni;Lcom/example/hellojni/databinding/ActivityHelloJniBinding;)V */\n(( android.widget.Button ) v1 ).setOnClickListener ( v2 ); // invoke-virtual {v1, v2}, Landroid/widget/Button;->setOnClickListener(Landroid/view/View$OnClickListener;)V\n/* .line 36 */\nreturn;\n} // .end method
\n

Reading the code above, you can see that when the button created in onCreate is tapped, onCreate$lambda$0 is called with the string entered in the form.

\n

The string passed here is then given to the checkValid function, which is called via invoke-direct {p0, v0} at the following point, and validated there.

\n
/* .line 30 */\nv0 = this.flag;\n(( android.widget.EditText ) v0 ).getText ( ); // invoke-virtual {v0}, Landroid/widget/EditText;->getText()Landroid/text/Editable;\n(( java.lang.Object ) v0 ).toString ( ); // invoke-virtual {v0}, Ljava/lang/Object;->toString()Ljava/lang/String;\n\nv0 = /* invoke-direct {p0, v0}, Lcom/example/hellojni/HelloJni;->checkValid(Ljava/lang/String;)Z */\nif ( v0 != null) { // if-eqz v0, :cond_24\n /* .line 31 */\n v0 = this.valid;\n final String v1 = \"Correct!\"; // const-string v1, \"Correct!\"\n /* check-cast v1, Ljava/lang/CharSequence; */\n (( android.widget.TextView ) v0 ).setText ( v1 ); // invoke-virtual {v0, v1}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V\n /* .line 33 */\n} // :cond_24
\n

Then, if the result of validation by the checkValid function is True, the app displays Correct! on the screen.

\n

In other words, we can infer that checkValid determines whether the correct Flag was supplied as input.

\n

From here, I wanted to inspect the implementation of checkValid to retrieve the Flag, but if you look at the following line that declares checkValid, it appears to be defined in a native library.

\n
private native final Boolean checkValid ( java.lang.String p0 ) {} // .end method
\n

So from here, we continue by analyzing the native library.

\n

Decompile the Native Library

\n

If you unpack the APK file with the command shown earlier, you can see that libhello-jni.so exists under app-debug/lib/arm64-v8a.

\n
apktool d app-debug.apk
\n

Because the checkValid function is implemented there, analyze this file with Ghidra.

\n

There are also other directories such as x86 under app-debug/lib/, but current Android environments basically require apps to support arm64-v8a, so I first used arm64-v8a as the analysis target.

\n

As described later, if you debug on an emulator running in an x86_64 environment, you can decompile x86 or other binaries as needed.

\n

Reference: Support 64-bit architectures | Android Developers

\n

By decompiling it in Ghidra, you can identify how the checkValid function works.

\n

\n \n \n \n \n \n \n \n \n

\n

From the decompiled result, the Flag appears to be 0x26 characters long, and characters 7 through 0x25 seem to be checked one by one at the line cVar1 != *pcVar5.

\n

(The first 6 characters and the last 1 character are probably ignored because the Flag format is cvctf{}.)

\n
lVar3 = FUN_0011f5ac(auStack_38);\nif (lVar3 == 0x26) {\n  _ZNSt6__ndk16vectorIiNS_9allocatorIiEEEC2Em(auStack_50,0x1f);\n  for (j = 0; j < 0x1f; j = j + 1) {\n    dVar6 = (double)FUN_0011f654(2,j % 0x10);\n    piVar4 = (int *)FUN_0011f698(auStack_50,(long)j);\n    *piVar4 = ((int)dVar6 % 0x25) % 0x1f;\n  }\n  _ZNSt6__ndk112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC2IDnEEPKc\n            (auStack_68,&UNK_001141ef);\n  for (i = 6; i < 0x25; i = i + 1) {\n    pcVar5 = (char *)FUN_0011f6bc(auStack_38,(long)i);\n    cVar1 = *pcVar5;\n    piVar4 = (int *)FUN_0011f698(auStack_50,(long)((i * 7) % 0x1f));\n    pcVar5 = (char *)FUN_0011f6bc(auStack_68,(long)*piVar4);\n    if (cVar1 != *pcVar5) {\n      uStack_6c = 0;\n      goto LAB_0011f508;\n    }\n  }\n  uStack_6c = 1;\nLAB_0011f508:\n  _ZNSt6__ndk112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED2Ev(auStack_68);\n  FUN_0011f6ec(auStack_50);\n}
\n

At this point, you could probably recover the Flag by statically analyzing the function in (char *)FUN_0011f6bc(auStack_68,(long)*piVar4);, which is used to obtain pcVar5, but that function is fairly complex, and it seemed like it would take quite a while to derive its output purely with static analysis.

\n

In a case like this, you can recover the Flag more easily by using dynamic analysis to obtain the return value of (char *)FUN_0011f6bc(auStack_68,(long)*piVar4); one by one.

\n

So from here on, I will focus on dynamically analyzing native libraries in Android apps.

\n

Perform Dynamic Analysis with the Android Studio Debugger

\n

As you can tell from AndroidManifest.xml, debugging was already enabled from the beginning for this APK file.

\n

That means after loading the APK file in Android Studio via [File] > [Profile or Debug APK], you can start debugging automatically on the emulator by clicking the bug icon in the top toolbar.

\n

(If debugging is not enabled, you need to edit AndroidManifest.xml and repackage the APK file.)

\n

\n \n \n \n \n \n \n \n \n

\n

When you start debugging in Android Studio, the APK launches on the emulator and then a debug window like the following opens.

\n

\n \n \n \n \n \n \n \n \n

\n

From here it looks like debugging would be easier if we could configure symbols for the native library, but unfortunately we do not have the target symbols on hand, so that approach is unavailable.

\n

\n \n \n \n \n \n \n \n \n

\n

Next, set [Debug Type] to [Native Only].

\n

\n \n \n \n \n \n \n \n \n

\n

This allows you to debug the native library from the Android Studio debugger.

\n

After changing this setting, press the debug button once more to start debugging the app again.

\n

Identify the App Architecture and Image Base

\n

Now that native library debugging is enabled in Android Studio, it is finally time to set a breakpoint at the location that validates the Flag and trace the execution.

\n

From here on, the work is not very different from ordinary dynamic analysis of a typical ELF binary.

\n

To determine where to set the breakpoint, first identify the image base where the target native library is loaded.

\n

After starting debugging, if you break the app while it is running, you will see the disassembly of the current stop location and the LLDB console as shown below.

\n

\n \n \n \n \n \n \n \n \n

\n

Next, run the following command in the LLDB console to list the loaded images.

\n
image list
\n

From the output of this command, find the line where libhello-jni.so, the library being analyzed, is displayed, and identify the image base address.

\n

\n \n \n \n \n \n \n \n \n

\n

By referring to the familiar table on Wikipedia, you can confirm that the image loaded during this debugging session uses the x86 architecture because e_machine at offset 0x12 is 0x3.

\n

Reference: Executable and Linkable Format - Wikipedia

\n

So I analyzed the x86 native library that Apktool had unpacked earlier in Ghidra and identified the offset of the checkValid function.

\n

From Ghidra’s analysis result, you can see that the offset of the checkValid function is 0x1a020, so I entered 0xd4b27020, which is the image base address plus that offset, into the disassembly window.

\n

This allowed me to identify the address of the checkValid function.

\n

\n \n \n \n \n \n \n \n \n

\n

At that moment, ECX contains the correct Flag character, and it is compared against EAX, which contains the input value.

\n

So if you print the value of ECX as shown below, write the value of ECX into EAX, and then continue execution, you can recover the correct Flag one character at a time.

\n

Originally, I wanted to automate this using LLDB’s embedded Python, but in Android Studio’s default debugger the source command did not work, so I used a source file for automation instead.

\n
# Put the following in cmd.txt\np/c $ecx\nregister write eax `$ecx`\ncontinue\n\n# Run the source file\ncommand source C:\\Users\\Tadpole01\\Downloads\\cmd.txt
\n

This allowed me to recover the Flag by determining it one character at a time, as shown below.

\n

\n \n \n \n \n \n \n \n \n

\n

By the way, the following reference was helpful for LLDB commands.

\n

Reference: GDB to LLDB command map — The LLDB Debugger

\n

Perform Dynamic Analysis by Attaching a Debugger to the Emulator

\n

Install the APK on the Emulator

\n

This time, instead of using Android Studio’s debugging features, I will attach a debugger to an application launched inside the system emulator.

\n

First, with the emulator running, install the target APK file with the following command.

\n
adb install app-debug.apk
\n

adb.exe is included in the Android SDK and can be downloaded from the following page.

\n

Reference: Download Android Studio & App Tools - Android Developers

\n

Once the APK has been installed, you will be able to launch the app on the running emulator.

\n

Next, download the Android NDK tools in advance so you can attach a debugger to the emulator.

\n

The NDK tools can be downloaded from the following page.

\n

Reference: NDK Downloads | Android NDK | Android Developers

\n

Incidentally, although we use the NDK tools to attach a debugger to the emulator, it seems that the current latest version, r25, no longer includes gdbserver, which was bundled with NDK tools up through r23.

\n

I would have preferred to use the familiar gdb, but thinking ahead I decided to use LLDB.

\n

Install LLDB on the Host Machine

\n

Next, install LLDB on the host machine so that it can attach to the emulator.

\n

To install LLDB, download the Windows installer from the releases page of the following GitHub repository.

\n

Reference: GitHub - llvm/llvm-project: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.

\n

The version I used this time, 16.0.3, depends on Python10, so if Python10 is not installed or is not in PATH, you need to install it separately in advance.

\n

Deploy lldb-server to the Android Emulator and Launch the App

\n

Now it is finally time to debug the app running on the Android emulator by attaching LLDB from the host machine.

\n

First, deploy lldb-server to the emulator side.

\n

The prebuilt lldb-server binary is placed inside the toolchains directory of the NDK obtained earlier.

\n

This time, to match the OS platform, I used the lldb-server located at $NDK_PATH\\toolchains\\llvm\\prebuilt\\windows-x86_64\\lib64\\clang\\14.0.7\\lib\\linux\\i386\\lldb-server.

\n
# Install the APK file on the emulator\nadb install app-debug.apk\n\n# Push lldb-server to the emulator\nadb push lldb-server /data/local/tmp\n\n# Grant execute permission to lldb-server\nadb shell chmod +x /data/local/tmp/lldb-server\n\n# Copy lldb-server to the target package path\nadb shell run-as com.example.hellojni cp /data/local/tmp/lldb-server /data/data/com.example.hellojni/
\n

In the commands above, I eventually grant execute permission to the pushed lldb-server and copy it to the target package path.

\n

You can identify the package name of the target from the AndroidManifest.xml analyzed earlier.

\n

Attach the Debugger

\n

Everything is finally ready, so let us start debugging.

\n

We will execute the following commands in order, but first let us look at the information for the target package.

\n
# Dump package information\nadb shell pm dump com.example.hellojni\n\n>\nDUMP OF SERVICE package:\nActivity Resolver Table:\n  Non-Data Actions:\n      android.intent.action.MAIN:\n        6525ec5 com.example.hellojni/.HelloJni filter 3d4e3e9\n          Action: \"android.intent.action.MAIN\"\n          Category: \"android.intent.category.LAUNCHER\"\n{{ omitted }}
\n

The dump command shows a very large amount of information, but here we especially want to note the package’s ActivityName.

\n

Make a note of the com.example.hellojni/.HelloJni part in the output above.

\n

Now that all preparations are complete, start debugging with the following commands.

\n

By the way, com.example.hellojni is the target package name here.

\n
# Stop lldb-server in advance (not needed the first time)\nadb shell run-as com.example.hellojni killall -9 lldb-server\n\n# Launch the app with adb shell am start -a <Main Activity> -D -n \"com.package.name/com.package.name.ActivityName\"\nadb shell am start -a android.intent.action.MAIN -n \"com.example.hellojni/.HelloJni\"\n\n# Once the app starts, begin listening with lldb-server\nadb shell run-as com.example.hellojni sh -c '/data/data/com.example.hellojni/lldb-server platform --server --listen unix-abstract:///data/data/com.example.hellojni/debug.socket'\n\n# Open another terminal and check the app's PID\nadb shell run-as com.example.hellojni ps\n\n# Launch lldb\nlldb.exe\n\n# Run these in order at the (lldb) prompt\nplatform select remote-android\nplatform connect unix-abstract-connect:///data/data/com.example.hellojni/debug.socket\n\n# Attach to the app PID identified above\nattach 17728
\n

Reference: How to find out activity names in a package? android. ADB shell - Stack Overflow

\n

Reference: How to start an application using Android ADB tools - Stack Overflow

\n

This lets you attach to the app running on the emulator from LLDB on the host machine.

\n

After that, as before, you can identify the Flag with the following commands.

\n
# Identify the base address of libhello-jni.so\nimage list\n>\n[202] 2720F64E-E4CD-4F44-2073-43B9B03816BB-CE41285A 0xd86b5000 libhello-jni.so\n\n# Set a breakpoint at 0xd86b5000+0x1a20c and resume app execution\nb *0xd86cf20c\ncontinue
\n

Now that you can set a breakpoint at the location where the Flag is validated in the app running on the emulator, you can retrieve the Flag in the same way as before.

\n

\n \n \nscript\n

Reference: Python Reference — The LLDB Debugger

\n

Now that we know Python scripts can be used in LLDB, we can automate Flag extraction as follows.

\n

This time, I decided to retrieve the Flag by registering a Python script that runs when the breakpoint is hit.

\n
# Identify the ID of the breakpoint you set\nbr list\n>\n1: address = libhello-jni.so[0x0001a20c], locations = 1, resolved = 1, hit count = 0\n\n# Use the identified breakpoint ID to define what happens when the breakpoint is hit\nscript counter=0\nbreakpoint command add --script-type python 1\n\n# Enter the following\nimport time\n\neax = frame.FindRegister(\"eax\")\necx = frame.FindRegister(\"ecx\").value\neax.SetValueFromCString(ecx)\nprint(chr(int(ecx,16)),end=\"\")\n\ntime.sleep(1)\nthread = frame.GetThread()\nprocess = thread.GetProcess()\nprocess.Continue()\nDONE
\n

When I actually ran this, I was able to capture the Flag characters as shown below.

\n

\n \n \n \n \n \n \n \n \n

\n

Because scripting works, remote attach feels easier than debugging directly inside Android Studio.

\n

Use dlopen on Library Functions and Dynamically Analyze Them as an ELF Binary

\n

In this challenge, unfortunately I could not get as far as recovering the Flag because I was unable to successfully connect the argument string passed from a C program to the GetStringUTFChars function on the native library side. Still, depending on the target, there are cases where loading native library functions with dlopen from your own program makes it easy to recover the Flag or debug the target.

\n

Identify the Native Library NDK Version

\n

To execute the native library after loading it with dlopen, you need to obtain libraries that satisfy the native library’s dependencies.

\n

The version of the native library included in the built APK can be identified by placing the native library file on the Android emulator and examining it with the file command.

\n

So I first placed libhello-jni.so on the emulator and checked its version with the file command as follows.

\n
# Push solver.out to the emulator\nadb push libhello-jni.so /data/local/tmp\n\n# Identify the version with the file command\nadb shell file /data/local/tmp/libhello-jni.so
\n

\n \n \n \n \n \n \n \n \n

\n

This showed that the NDK version used to build this library was r25b, so I downloaded the NDK r25b files from https://dl.google.com/android/repository/android-ndk-r25b-windows.zip.

\n

After extracting the downloaded file and expanding it with ndk-build.cmd, you can obtain prebuilt library files for each platform from under android-ndk-r25b\\toolchains\\llvm\\prebuilt\\windows-x86_64\\sysroot\\usr\\lib.

\n

This time I was using an x86 binary, so I copied the library files built under i686-linux-android.

\n

Create an Executable

\n

Once the required dependency libraries were ready, I next created a binary that calls the native library.

\n

I used the following code.

\n

The symbol for the checkValid function could be used exactly as identified in Ghidra.

\n
#include <stdio.h>\n#include <stdlib.h>\n#include <dlfcn.h>\n\nint main()\n{\n    void *handle;\n    char *error;\n\n    handle = dlopen(\"./libhello-jni.so\", RTLD_LAZY);\n    if (!handle)\n    {\n        fprintf(stderr, \"%s\\n\", dlerror());\n        exit(EXIT_FAILURE);\n    }\n\n    dlerror();\n    int (*checkValid)(wchar_t *) = dlsym(handle, \"Java_com_example_hellojni_HelloJni_checkValid\");\n    error = dlerror();\n    if (error != NULL)\n    {\n        fprintf(stderr, \"%s\\n\", error);\n        exit(EXIT_FAILURE);\n    }\n    printf(\"pid : %d\\n\", getpid());\n    puts(\"dlopen success\");\n    printf(\"handle addr : %p\\n\", handle);\n\n    wchar_t text = L\"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\";\n    int i = checkValid(text);\n    printf(\"Result : %d\\n\", i);\n    dlclose(handle);\n    return 0;\n}
\n

After building this code with the following command, launch it with gdb.

\n

At runtime, place the compiled file, libhello-jni.so, and the library files copied earlier including libandroid.so all in the same directory.

\n
# Build as an x86 binary\ngcc solver.c -m32 -o solver.out\n\n# Add the current directory to the library path\nexport LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH\n\n# Run the program with gdb\ngdb ./solver.out
\n

Running this shows that you can call the checkValid function implemented in the native library.

\n

Unfortunately, this time I could not successfully connect the argument string passed from the C program to the GetStringUTFChars function on the native library side, so I did not get as far as recovering the Flag. However, as shown below, I was still able to reach the Flag validation logic itself using gdb.

\n

\n \n \n \n \n \n \n \n \n

\n

In particular, native library functions that do not require arguments from the app can be debugged easily with this method.

\n

Perform Dynamic Analysis with Frida Hooks

\n

Frida is a tool that lets you analyze native apps on a wide range of platforms such as Windows, macOS, Linux, iOS, and Android by injecting JavaScript code.

\n

According to the documentation, Frida’s core is implemented in C, and by injecting the QuickJS Javascript Engine into the target black-box process, it can hook functions and call arbitrary functions inside the process.

\n

Reference: Welcome | Frida • A world-class dynamic instrumentation toolkit

\n

Set Up Frida

\n

Let us quickly set up Frida so we can analyze the Android app.

\n

First, install frida-tools on the host machine with pip.

\n
# Install frida-tools on a Windows machine\npython3.exe -m pip install frida-tools
\n

When I installed Frida in my environment, the Frida executable ended up under:

\n

%USERPROFILE%\\AppData\\Local\\Packages\\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\\LocalCache\\local-packages\\Python310\\Scripts

\n

So I placed the downloaded files in an appropriate folder and added that folder to PATH.

\n
# Check that Frida is available\nfrida.exe --version\n>\n16.0.19
\n

Now that Frida is installed on the host machine, the next step is to configure frida-server on the Android environment running on the emulator.

\n

From the Frida releases page below, download and extract a frida-server with the same version as the Frida installation on the host machine that we confirmed earlier.

\n

Reference: Releases · frida/frida

\n

This time, because I was running it on an emulator, I downloaded frida-server-16.0.19-android-x86.xz.

\n

If you install it on a physical Android device, choose the ARM version instead.

\n

The APK file and frida-server can be deployed to the emulator in roughly the same way as the lldb-server mentioned earlier, but note that this time root access is required.

\n

If adb root outputs the error adbd cannot run as root in production builds, then to avoid that problem you need to choose an emulator OS whose [Play Store] field is blank.

\n

Also, if Android 12 or later is configured by default, the OS platform version becomes x86_64, so be careful.

\n

In that case, you can start frida-server by using frida-server-16.0.19-android-x86_64.

\n

\n \n \n \n \n \n \n \n \n

\n

If you are using an emulator whose [Play Store] field is blank, adb root works correctly, so you can start frida-server with the following commands.

\n
# Enable adb root\nadb root\n\n# Install the APK on the emulator\nadb install app-debug.apk\n\n# Rename the extracted file\n# Use frida-server-16.0.19-android-x86_64 for the x86_64 platform\nren frida-server-16.0.19-android-x86 frida-server\n\n# Push frida-server to the emulator and grant execute permission\nadb push frida-server /data/local/tmp\nadb shell chmod +x /data/local/tmp/frida-server\n\n# Start frida-server\nadb shell /data/local/tmp/frida-server
\n

Debug with a Frida Hook

\n

Once frida-server is running on the emulator side, it is finally time to start analyzing the app.

\n

The actual operation of analyzing with a Frida hook is very simple.

\n

Basically, the idea is to attach from a Python script to the frida-server running on the emulator and let the embedded JavaScript code in the script do the processing.

\n

Let us first look at the first half.

\n

Up to this point, the script identifies the frida-server instance the Python script should attach to.

\n

DEVICE_NAME can be identified with the adb devices command.

\n
import frida\nimport sys\n\ndef on_message(message, data):\n    if message['type'] == 'send':\n        print(\"[*] {0}\".format(message['payload']))\n    else:\n        print(message)\n\n# Connect to the emulator\nDEVICE_NAME = \"emulator-5554\"\nAPK_PROCESS_NAME = \"HelloJni\"\nprocess = frida.get_device_manager().get_device(DEVICE_NAME).attach(APK_PROCESS_NAME)
\n

Next comes the main JavaScript portion. The basic idea is the same as the dynamic analysis performed with the debugger so far: recover the Flag.

\n

First, Module.findBaseAddress(module_name) obtains the image base address from the native library filename.

\n

Then it adds the offset of the Flag validation code already identified in Ghidra to produce target_address.

\n
var module_name = \"libhello-jni.so\";\n// var sym_name = \"Java_com_example_hellojni_HelloJni_checkValid\";\n\nvar base_addr = Module.findBaseAddress(module_name);\nvar target_offset = 0x1a20c\nvar target_address = base_addr.add(target_offset);\n\nvar flag = \"\";
\n

Next, Interceptor.attach uses onEnter: to define what should happen when the app reaches target_address. (It is like a breakpoint.)

\n

As identified through the analysis so far, the operations needed to recover the Flag were as follows.

\n
    \n
  1. Enter a 38-character string in the app and press the [Check Flag] button.
    2. \n
  2. At offset 0x1a20c in the native library, obtain one Flag character from the value stored in ecx.
    3. \n
  3. Copy the value of ecx to eax and continue processing.
    4. \n
\n

In the following code, when execution reaches target_address, this.context.ecx is used to read the value in the ecx register and tamper with the eax register.

\n
Interceptor.attach(target_address, {\n  onEnter: function(args) {\n    // console.log(\"eax: \" + this.context.eax);\n    // console.log(\"ecx: \" + this.context.ecx);\n\n    // Retrieve a Flag character\n    flag = flag + String.fromCharCode(this.context.ecx);\n    console.log(flag);\n\n    // Rewrite the register value\n    this.context.eax = this.context.ecx;\n  },\n  onLeave: function(retval) {\n    // Do nothing\n  }\n});
\n

The final code I implemented looked like this.

\n
import frida\nimport sys\n\ndef on_message(message, data):\n    if message['type'] == 'send':\n        print(\"[*] {0}\".format(message['payload']))\n    else:\n        print(message)\n\n# Connect to the emulator\nDEVICE_NAME = \"emulator-5554\"\nAPK_PROCESS_NAME = \"HelloJni\"\nprocess = frida.get_device_manager().get_device(DEVICE_NAME).attach(APK_PROCESS_NAME)\n\njscode = \"\"\"\nvar module_name = \"libhello-jni.so\";\nvar sym_name = \"Java_com_example_hellojni_HelloJni_checkValid\";\n\nvar base_addr = Module.findBaseAddress(module_name);\nvar target_offset = 0x1a20c\nvar target_address = base_addr.add(target_offset);\n\nvar flag = \"\";\n\n// console.log(base_addr);\n// console.log(target_address);\n\nInterceptor.attach(target_address, {\n  onEnter: function(args) {\n    // console.log(\"eax: \" + this.context.eax);\n    // console.log(\"ecx: \" + this.context.ecx);\n\n    // Retrieve a Flag character\n    flag = flag + String.fromCharCode(this.context.ecx);\n    console.log(flag);\n\n    // Rewrite the register value\n    this.context.eax = this.context.ecx;\n  },\n  onLeave: function(retval) {\n    // Do nothing\n  }\n});\n\"\"\"\n\nscript = process.create_script(jscode)\nscript.on(\"message\", on_message)\nprint(\"[*] Running APK\")\n\nscript.load()\nsys.stdin.read()
\n

By running this from the command prompt, I was able to recover the Flag as shown below.

\n

\n \n \n \n \n \n \n \n \n

\n

Bonus: Perform Dynamic Analysis with Symbolic Execution

\n

When I read angr’s official documentation, it appeared to mention support for symbolic execution of Android apps that use native libraries.

\n

Reference: experimental java, android, and jni support in angr

\n

Looking at the page above, it includes an example of recovering a Flag with angr from an Android app analysis challenge that actually appeared in a CTF.

\n

I did not try using angr for this problem, but if I feel like it later I may add an update.

\n

Summary

\n

This time I tried four (+1) approaches for dynamically analyzing an Android app challenge from a CTF.

\n

In particular, Frida hooking was a technique I had been meaning to try someday and had left untouched for a long time, but once I actually used it, it felt remarkably easy and extremely powerful.

\n

It seems likely to be useful beyond Android analysis as well, so I plan to keep experimenting with it in various contexts.

","fields":{"slug":"/ctf-android-apk-debug-tutorial-en","tagSlugs":["/tag/ctf-en/","/tag/rev-en/","/tag/android-en/","/tag/english/"]},"frontmatter":{"date":"2023-05-15","description":"I summarized five ways to perform dynamic analysis on Android apps.","tags":["CTF (en)","Rev (en)","Android (en)","English"],"title":"5 Techniques I Learned for Tackling Android App Reverse Engineering Challenges","socialImage":{"publicURL":"/static/8ac192ff1e4e680fa0e15e5f9f5b8939/ctf-android-apk-debug-tutorial.png"}}}},"pageContext":{"slug":"/ctf-android-apk-debug-tutorial-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}