Universe Weird C132 : Android Application Based CTF Challenge Walkthrough

Universe Weird C132 is a beginner level Android application CTF challenge. It makes you realise that every application is a treasure hunt, more of a treasure and less of a hunt.

The aim of this CTF challenge is to concentrate on the basic flaws which are found while performing security assessment of a mobile application. We will be observing the basic mis-configurations which can lead to huge data loss.

Let’s take a minute to thank Moksh for creating this challenge. If someone wants to try and solve the challenge, the link for the CTF can be found [here] and the application can be downloaded from [here].

Tools Used :

adb : command line tool that lets you communicate with device

apktool : command line tool for reverse engineering android applications

jadx-gui : tool for producing Java source code from Android Dex and APK files

Android Studio : official Integrated Development Environment (IDE) for Android app development

Device : Android Device/Android Studio Emulator/Genymotion Emulator

Connecting the device with a USB cable and entering command for checking proper connectivity.

adb devices

The above command will list down all the connected devices/emulators.

The above exhibit shows the list of devices connected to the system

Note : Make sure to connect the android phone with debugging mode enabled for initiating the application installation process.

After downloading the application from the above given link, the application can be installed in device/emulator by a very simple command.

adb install <apk-name>

The above exhibit shows that the application has been successfully installed in the device

We can run the application in the device/emulator

The above exhibit shows that first page while running the application

Here, button “GENERATE FLAG” is observed.

On a single click we got nothing.. Let’s tap up on it again and again..

After clicking on the button three times we got a message…

“The Flag is : cygym3{damn_morty”

The above exhibit shows the message after tapping three times of the GENERATE FLAG button.

Is this it ? Are we done..

Is it that easy ? Just tapping three times.

Let’s see the application source code using jadx-gui

jadx-gui <apk-name>

We can start analysing the application source code from MainActivity.java

The above exhibit shows that the string is hard coded in application source code

So the string “The Flag is: cygym3{damn_morty” is hard coded.

So here, there are two possibilities..

  • This is a false flag just to divert us from the path
  • This is an incomplete flag

}” is missing in “cygym3{damn_morty

cygym3{damn_morty}” is this a complete flag ? NOOOOOOO!

Let’s move ahead and see the code..

So, the source code shows that after tapping 10 times on the button it will give us another hint…

The above exhibit shows the message after tapping 10 times on GENERATE FLAG button

The message says “Oh, the flag looks incomplete. Fishy!”

The hint indicated that the flag is incomplete and we need to find the second part of the flag.

Let’s read more source code..

The above exhibit shows that function call in reverse engineered source code

We can see there are three random hard coded strings being called by a function ja.jaVar(<String>)

Let’s read the function declaration…

The above exhibit shows the definition of the function in reverse engineered source code

So here, we are in a chaotic situation.. Strings are getting called but the function returns void. Strange!

It seems like a dead end.

Let’s start analysing the APK again…

Reverse engineering the application again using apktool with a very basic command.

apktool d <apk-name>

OR

apktool d <apk-name> -o <new-folder-name>

Note : Here “d” stands for decompiling the application.

The above exhibit shows that the application is being reverse engineered using apktool

The basic difference between apktool and jadx-gui is that, we get smali code while analysing APK using apktool and on the other side we get java source code using jadx-gui.

Straight away after reverse engineering the source code, we can start analysing the application XML files in a text editor.

The above exhibit shows the firebase instance identified in application source code

See what we got.. a Firebase instance.. JUICY!

Lets see the instance, if it is properly configured or not ? by checking it as

https://<firebase-instance>/.json

The above exhibit shows how to check the configuration of an firebase instance so that it does not leak any information

The firebase instance looks like it is properly configured and does not leak any information.

Are we at a dead end again ???

What else we founded in “res/values/strings.xml”

The above exhibit shows the other half of the URL being stored in application source code

The other part of the URL : /cybergym3.json

Now let’s check the firebase configuration again.

https://<firebase-instance>/ + <second-part-of-url>

The above exhibit shows that we finally found the flag

Hey ! You are smart !

So let’s complete the flag

cygym3{damn_morty_you_are_smart}

Takeaways :

Learned reading application source code

Tracing down application source code

Checking firebase instance configuration

Hard coding data is the first step to danger zone

a technofreak who loves poetry