Waiting

Hello Everyone, today I will be talking about how to hack the mobile app Waiting from hackthebox.

Let’s start by installing the app on the android-x86 VM.

After installing the app using adb lets take a quick look around and see what the purpose of the this app is and where the flag might be hidden.

On the first app screen there is a little note about the app getting updated recently and some features getting removed. As we can also see their is another button that when clicked takes the user to the next app screen.

On this page there is a bunch of text inputs and checkboxes along with a button to get a token. Below the get token button is a button that is disabled.

Now that we have an idea of what the app looks like it is time to use jadx-gui to look over the app and see if their is anything interesting.

Once we have launched jadx-gui we need to first look at the AndroidManifest.xml.

After looking through the AndroidManifest.xml we can see the two app screens that we found when looking through the app on the VM but, in the manifest there is a third app screen called .SecretActivity.

Now that we have seen that there is another app screen that is hidden from the user and not exported to other apps we can start working on getting in to this app.

The first plan of attack for this app is to look at the source code for this secret page and see what it displays and what functions are called when it is created.

But unfortunately jadx-gui can not decode this part of the app so we will have to use dex2jar and jd-gui.

$ unzip wait.apk -d unziped_waiting
$ cd unziped_waiting
$ dex2jar classes.dex
$ jd-gui ~/Desktop/waiting/unziped_waiting/classes-dex2jar.jar

After running these commands and navigating to the class secretActivity.class in jd-gui we can see all the functions that get called when this app screen is opened.

After poking through all the code in this function we can see that their are lots of functions called at the beginning of the onCreate function that appear to check if the app is signed with a different certificate and make sure that the app is not being hooked by Frida. Once all these checks pass and the app confirms that it is not hacked then it calls a c++ function called secret.getdxXEPMNe(); which appears to return the flag.

Now that we know that this c++ function is most likely the function that returns the flag. We need to call the .SecretActivity activity so we can get the flag. To do this we need to us the adb shell and escalate to root so that we can open this activity with the activity manager.

Once this command is run we can check the VM and see if the flag is displayed.

But unfortunately one of the functions that checks for suspicious activity stops the app from executing the c++ function. Since we can not edit the code in jd-gui we need to switch to the apktool so we can decompile the app and edit the smali code.

Once we decompile the Waiting app with apktool then we need to open the smali folder in visual studio code and find the secretActivity.class.

Now that we have open the smali code we need to add a few lines of smali code that will log the output of the secret.getdxXEPMNe(); to the adb logcat before the security functions are called.

new-instance v1, Lcom/example/waiting/Secrets;
invoke-direct {v1}, Lcom/example/waiting/Secrets;-><init>()V
invoke-virtual {v1}, Lcom/example/waiting/Secrets;->getdxXEPMNe()Ljava/lang/String;
move-result-object v0
.local v0, "str_var":Ljava/lang/String;
sget-object v1, Ljava/lang/System;->out:Ljava/io/PrintStream;
invoke-virtual {v1, v0}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V