Damn Exploitable Android App - Dynamic analysis and Reverse Engineering

In this article, we will explore two powerful techniques, dynamic analysis using Frida and reverse engineering using Ghidra, to uncover and address bugs and security loopholes in Android application native libraries.
Jul 19

Upcoming Blog posts:

- Setting up our mobile vulnerability research lab - Previous Page
- Dynamic analysis and Reverse Engineering – Current Page
- Abusing Info Leaks to bypass ASLR
- Exploit Stack Overflow

Android native libraries, written in C or C++, are essential components that complement Java or Kotlin code in Android applications. These libraries are responsible for performing computationally intensive tasks and accessing hardware features, significantly improving an app's performance.

In this article, we will explore two powerful techniques, dynamic analysis using Frida and reverse engineering using Ghidra, to uncover and address bugs and security loopholes in Android application native libraries.

Please follow our previous article for the lab step-up click here

Dynamic Analysis with Frida

Frida is a dynamic instrumentation tool that allows us to inject JavaScript code into a running Android application. This enables us to observe and modify the app's behavior in real-time, making it an excellent choice for dynamic analysis.

Setting Up Frida for Android:

Before Setting up Frida, we need forward traffic between VM with our development machine (local system).

We are going to use socat to forward the traffic between virtual device (local machine) and Virtual machine.

When you run the Android Debug Bridge (ADB) service on a virtual device, it opens a port on TCP 5555 for the localhost. To access ADB services from the virtual machine, you will need to forward the ADB service to the virtual machine. This allows the virtual machine to interact with ADB services as if they were running locally.

Instruction for install socat

For linux:
  • apt install socat
  • Open terminal and type:
  • sudo socat -v tcp-listen:5556,fork tcp:127.0.0.1:5555

For Mac:
Brew install socat

For Windows:
click link download the socat and run socat with administrator 
socat.exe -v tcp-listen:5556,fork tcp:127.0.0.1:5555
This will forward all ADB connection on localhost to all interfaces on port 5556
Now we will start setting up the Frida.
Deploy the Frida server on the target Android device

Download the Firda-server from github
To unzip xz file , we need install xz utils in VM
sudo apt-get install xz-utils
unxz frida-server-16.1.3-android-arm.xz

Push to dive and change permission to executable
  • adb push frida-server /data/local/tmp
  • chmod u+x frida-server
Frida server typically operates on port 27042 by default, and in order to access the service, it is necessary to forward the port to your Virtual Machine (VM).

  • adb forward tcp:localport tcp:remoteport


Install Frida on your Virtual machine:
sudo pip3 install –break-system-packages frida-tools

Before initiating the Frida analysis, it is essential to ensure that the application you intend to analyze is running. This will guarantee that Frida can properly attach to the target process and conduct the analysis successfully.

adb shell am start com.example.mynativetest/.MainActivity
To obtain the list of processes, you can use "frida-ps" to retrieve the Process IDs (PIDs) of the currently running processes.

  • frida-ps –H 127.0.0.1:27042

Frida-trace is a powerful tool designed for dynamically tracing native JNI (Java Native Interface) function calls. To utilize Frida-trace, you can attach it to a specific process ID and specify a search identifier to track and monitor the JNI calls occurring within the target process. This provides valuable insights into the interactions between the Java code and the underlying native functions, enabling in-depth analysis and debugging capabilities.


Inject Frida-trace code: Once attached, you can use Frida-trace to inject custom instrumentation code into the process, specifically targeting JNI function calls.

● Process id
  • -p 4072

● Search Identifier
  •  -i “Java_*”
● frida-trace –H 127.0.0.1:27042 –p 4072 –i “Java_*”
Tracing native JNI (Java Native Interface) function calls involves sending data to the application for monitoring and analysis purposes.

The Damn Exploitable Android App listens on port 6000. This means we need to forward port 6000 on the device to our VM in order to connect with it using the following command:

adb forward tcp:6000 tcp:6000
Once the forwarding is done you can open another terminal and connect using nc and send some arbitrary data by typing and pressing enter

nc 127.0.0.1 6000
Switch over to the Frida Trace terminal tab and observer the trace.
Frida-trace will now intercept and log the JNI function calls as they occur within the target application, allowing you to analyze the interactions between Java and native code.
Currently, it is possible to perform reverse engineering using Ghidra on logged JNI functions from Frida trace.

Reverse Engineering Using Ghidra

Ghidra is a powerful software tool used for binary analysis and reverse engineering. One of its key features is the ability to decompile binary files, which allows developers and security researchers to convert low-level assembly code back into a higher-level programming language representation, such as C or C++ and is a free and open-source tool that provides support for a wide range of architectures.
Import the Native library of the application from the gdb_sysroot_armv7 to Ghidra.

Native library file location:
/home/fuzzing-android/Desktop/gdb_sysroot_armv7/data/app/com.example.mynativetest-1/lib/arm/
Filter out the JNI function in and disassemble it into a higher-level programming language representation, specifically a C program in Ghidra.
By utilizing the function call tree in Ghidra, you can examine the outgoing calls for the JNI functions.
the third parameter of the JNI function, represented by 'jbyteArray,' is assigned to the variable 'pcVar1,' while the fourth parameter, an integer denoted by 'int,' is assigned to the local variable 'local_18' and then passed as an argument to the subfunction 'cp()'.
While analyzing the 'cp()' function, the arguments have been assigned to local variables ranging from 'param_1' to 'local_c,' and 'param_2' has been assigned to 'local_10'.

local_10 = param_2;
local_c = param_1;

The local variable 'auStack_d8' is allocated with a buffer size of 200.
undefined auStack_d8 [200];

The code uses an 'if' condition to check whether 'param_2' (also referred to as 'local_10') is greater than zero and whether 'param_1' (denoted as 'local_c') starts with the hexadecimal value '0xfa'.
The memcpy function is utilized to copy user control data to the stack without performing any size checks.
the lack of size checks when using the memcpy function to copy user control data to the stack can lead to a stack overflow vulnerability. 

This vulnerability arises when data is copied into a buffer without proper bounds checking, allowing an attacker to overwrite adjacent memory regions beyond the intended boundaries of the buffer. As a result, the attacker can potentially execute malicious code, disrupt program execution, or gain unauthorized access to sensitive information, posing significant security risks to the application. It is crucial to ensure proper size validation and bounds checking when handling user data to prevent such vulnerabilities.

Summary

Dynamic analysis using Frida and reverse engineering with Ghidra are potent methodologies that play a pivotal role in discovering bugs and vulnerabilities within Android application native libraries. By proactively identifying and rectifying security loopholes, developers can bolster the protection of user data and fortify the overall resilience of their Android apps. As the cybersecurity landscape evolves, integrating these practices into the development workflow becomes crucial to maintaining user trust and ensuring the long-term prosperity of Android applications. Moreover, these techniques also enable the creation of fuzzing harnesses, which aid in the detection of memory-based vulnerabilities, further enhancing the app's security posture.

Next Article:
- Exploit Stack Overflow

In addition, we've set up a device that can support the operation of the Damn Exploitable Android app. In our upcoming article titled "Abusing Info Leaks to Bypass ASLR," our primary focus will be on utilizing memory leaks to bypass ASLR through the clever application of format string vulnerabilities. Our aim is to identify critical areas of interest, with a specific emphasis on analyzing the native components of the application.
Stay tuned for this deep dive as we unravel possible targets to focus on, leveraging these tools to expose vulnerabilities and learn how to build an exploit for an Android Device running on an Armv7 Processor.

Want to learn how do this on our cutting edge platform and running for Android 13 running on Arm64 without setting up a lab?

Check out our training: https://www.mobilehackinglab.com/course/android-userland-fuzzing-and-exploitation