In the previous article, we have seen how to debug Java applications using a little tool called JDB. In this article, we will apply the same logic to exploit Android apps, if they are flagged as debuggable. If an application is flagged as debuggable, we can inject our own code to execute it in the context of the vulnerable application process.
**Background**
To make this article more interesting, I have developed a vulnerable application for demonstration purposes, which has a “**button**” and a “**textview**“.
Fill out the form below to download the code associated with this article.
INFOSEC FILE DOWNLOAD
If we launch the application, it shows the message “**Crack Me**“.
If we click the button, it says “**Try Again**“. Now, our goal is to change the message “Try Again” to “Hacked” without modifying the application’s source code. To be precise, we have to change it at runtime.
In this step, we will set up all the required things to inject code in to the app during its execution. As mentioned in the previous article, we will use remote debugging in this article.
**Note:** JDWP stands for Java Debug Wire Protocol. If an application running in its VM is debuggable, it exposes a unique port on which we can connect to it using JDB. This is possible in Dalvik Virtual Machines with the support of JDWP.
4. Now, launch our target application and run the same command to see the listening port associated with our target application. It looks as shown below.
If we observe the difference between Figure 2 and Figure 3, there is one extra port 543 listening after launching the target application in Figure 3. We will attach JDB to the application using this port, since this is our target.
5. Before attaching to the application, we need to port forward using adb since we are using remote debugging. This is shown in Figure 4.
In this step, we will actually exploit the vulnerable application by modifying its behavior at runtime.
To modify the application’s behavior at runtime, we need to set up breakpoints and control the flow. But, we don’t know what classes and methods are used in the application. So, let’s use the following commands to find out the classes and methods used in the application.
Since I have too many classes listed, I am listing only a few classes. But if you still scroll down, you will see some interesting user defined classes as shown in the figure below.
To hit the breakpoint, we will have to manually click the button in the application. Once after clicking the button, the breakpoint will be hit and it appears as shown in Figure 9.
It’s pretty clear that TextView has been loaded into method arguments. If we look at the source code provided in Figure 10, the line associated with TextView instantiation has been executed.
Let’s now execute the next lines by executing the “**next**” command, and check the local variables as shown in the figure below.
As we can see, all the local variables have been displayed. The string “**secret**” looks interesting. The value “Try Again” is what is going to be printed when we click the button.
From Figure 10, it is very clear that the method **setText** is getting executed to print the value “**Try Again**“. So, let’s use the “**step**” command to get into the definition of the “**setText**” method and dynamically modify the text to be printed.
We have successfully modified the output of the application at runtime. This is just an example to show how an application’s behavior can be modified if the application is debuggable. We can perform various other things including “**Getting a shell**” on the device in the context of the vulnerable application.
**Conclusion**
In this article, we have demonstrated how one can exploit an Android application if it is left debuggable when moving it to the production. Pentesters should always look for this vulnerability during their Android app pentests.
