Mobile Security (Android)

For the past few months, I have been in an extremely fulfilling internship, as a mobile pentester/researcher, and since then I have gained new knowledge on mobile security that I would like to share for those who are interested or would like to learn more about mobile security.

For this post, I will focus mainly on Android, because I have slightly more experience with Android development and the pentesting of Android apps! Enjoy 🙂

First and foremost, i feel that pentesting an Android app is relatively more manageable compared to iOS application; I shall lean towards Android because I have little to almost no experience with iOS, and on top of that I have never owned an iPhone or a MacBook ever. It is possible to reverse engineer both Android and iOS apps, however, in Android, you might be able to expose it’s Java functions and even Native C++/C libraries/functions used, even with obfuscation you might still be able to deduce the events that are carried out as you run an Android application, unlike iOS. You can, however, still reverse engineer iOS, with reverse engineering tools such as IDA. (You will actually need IDA Pro because of the arm architecture) But it will be harder to those who are not comfortable with assembly. (And i am one of them, still learning though.) There are a couple of tools dedicated to mobile pentesting anyway, just like when you pentest Web applications. For mobile, we have the likes of Frida and as mentioned, common reverse engineering tools such as Ghidra, IDA, and debuggers such as GDB.

Reverse Engineer an Android application

Now for some hands on. We will reverse engineer a sample application, just to show you how it works. And we might expand on it as we go along, so if you are keen to follow, feel free to fork my repository!

https://github.com/matthewng1996/TestApp

Requirements

Set up (After cloning the Git repo, etc)

In activity_main.xml, we will remove the “Hello World” text (Strikethrough for illustration), and add an id (Bold and underlined) to the TextView.

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">

<TextView
android:id="@+id/text1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Hello World!"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent" />

</androidx.constraintlayout.widget.ConstraintLayout>

Next, in MainActivity.Java, we initialise the textView and set the text to “The real Hello World!”

package com.version.testapp;

import androidx.appcompat.app.AppCompatActivity;

import android.os.Bundle;
import android.widget.TextView;

public class MainActivity extends AppCompatActivity {

TextView text;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
text = findViewById(R.id.text1);
setContentView(R.layout.activity_main);

text.setText("The real Hello World!");
}
}

Next, we head to Build > Build Bundle(s)/APK(s) > Build APK(s). Under Event Logs (The bottom right corner of Android Studio), we click locate on the last event logs message.

Next, we change the extension of the apk to zip.

Open up the zip file, and extract classes.dex and classes2.dex.

For a start, you simply need to reverse engineer the dex files into jar file so that they are more human readable!

From your terminal, using dex2jar, you convert the dex files into jar files!

Here’s the output after you are done. (Located in your dex2jar directory)

Now that it is a jar file, it will be relatively easy to read these files, i usually use JD-GUI since it has a proper GUI and it’s beginner friendly.

Now when you open classes.jar, you will realise your package isn’t there. That is perfectly fine since it will then most likely appear in classes2.jar. It appears that our libraries are found here instead, which we do not need at this point of time.

classes2.jar as expected, shows our package name clearly, and expanding it shows our MainActivity.class. Now clicking that will then reveal our decompiled code.

With this, you have successfully reverse engineered your first Android app! It’s really easy.

Extras!

So if you have noticed, currently it can take quite some time to rename your apk to zip, and then having to extract your dex files and then getting them converted into jar via dex2jar. Fret not, because automation is the way to go.

I would like to thus use this opportunity to introduce my new tool, which is currently at a very early development stage. With that being said, there’s alot to be done on my side, and i will do my best to bring the best out of this automated tool.

Currently, this tool helps you create your zip file, and extracts your dex files and even decompress your AndroidManifest.xml for you!!! (I will explain the security implications of a poor AndroidManifest.xml next time) It might just be saving a few seconds of your time, but over time these few seconds can amount to minutes, hours and days and weeks and months and years and…. you get my point. The repo for it is https://github.com/matthewng1996/APKBreaker, if you would like, feel free to follow its development or even contribute if you have any ideas and are feeling generous to contribute to the open-source community. Automation + cybersecurity (In terms of pentesting) is what i aim to achieve for APKBreaker. 🙂

And that’s it for today. While there aren’t any security threats mentioned for this post, but it still covers Reverse Engineering right? So please forgive me if you find that this post has no place in this cybersecurity blog. Have a good night’s rest and a good week ahead as we dive deeper into the realm of Android in the days to come!