A step-by-step Android penetration testing guide for beginners

Mobile applications and services are essential to our everyday lives both at home and at work. This makes them prime targets for malicious actors seeking sensitive information. 

In this guide, you’ll learn basic Android penetration testing techniques when performing mobile assessments to improve security. First, we'll set up the environment in order to start testing and then examine the functionality of tools that are useful in mobile assessments.

What is Android penetration testing?

Mobile or Android penetration testing aims to detect security vulnerabilities and ensure that mobile applications are not vulnerable to attacks. 

_{(Android and iOS operating systems have a combined market share of 99.35 percent.)}

Android applications can be analyzed either by using automated tools, or manually. During this process, the mobile penetration tester will use several techniques to simulate attacks, find security flaws in the mobile application, and gain access to sensitive data.

Why is Android penetration testing important

Modern Android applications are used for commercial purposes, healthcare, banking, learning, and more. These mobile applications, apart from holding sensitive information, also contain security vulnerabilities. Penetration testers and developers can find and fix these vulnerabilities and mitigate security risks.

In 2021, the payment application Klarna suffered an application flaw that caused users to log in to random accounts of other customers and expose sensitive personal and credit card information.   

 

ParkMobile, the company behind an app for cashless parking across the United States, is still battling a class action lawsuit from a 2021 mobile app data breach that affected 21 million users.

With new vulnerabilities surfacing every day, Android penetration testing is necessary to avoid fraud attacks, malware infections, and data leaks. This is vital for any company that wants to go live with a new app without having to worry about legal or security issues.

Mobile penetration testing can also be beneficial for evaluating the developer team’s work and checking the IT team's responsiveness, as tests can reveal vulnerabilities and misconfigurations in back-end services used by the app. (If you're new to penetration testing, start by reading our what is penetration testing post to understand the basics.) 

🎮 TEST YOUR ANDROID PENTESTING SKILLS NOW

Android package (APK) file structure explained 

An Android Package (APK), is an archive file with a .apk suffix, and it contains all the files (code and assets) that are required in order for the Android application to run.

APK files can be unpacked using the command `unzip app_name.apk` in Linux. The image below shows the unzipped structure of an APKfile: 

• METTA-INF: Contains verification information that is generated when the app is signed.

• MANIFEST.MF: Contains a list of names/hashes (usually SHA256 in Base64) for all the files of the APK.

• CERT.SF: Contains a list of names/hashes of the corresponding lines in the MANIFEST.MF file.

• CERT.RSA: This file contains the public key and the signature of CERT.SF.

• Assets: Contains assets that developers bundle with the application, and can be retrieved by the AssetManager. These assets can be images, videos, documents, databases, etc.

• lib: Contains native libraries with compiled code, for different device architectures.

• res: Contains predefined application resources, like XML files that define a state list of colors, user interface layout, fonts, values, etc. 

• AndroidManifest.xml: A manifest file that describes the application's package name, activities, resources, version, etc.

• classes.dex:  Contains all the java classes in a dex (Dalvik Executable) file format, to be executed by the Android Runtime.

• resources.arsc: Contains precompiled resources. It holds information that will link the code to resources.

Start with the OWASP Mobile Top Ten to find vulnerabilities

The Open Web Application Security Project (OWASP) is a nonprofit foundation that provides security tips and methodologies mainly for web applications. In 2016 OWASP created their latest list of Mobile Top 10 Vulnerabilities. It refers to the impact each vulnerability has on individuals and businesses and suggests methods of prevention.

If you’re new to Android penetration testing, these vulnerabilities are a great starting point that will help you find flaws and improve application security:

1. Improper platform usage

This category covers misuse of platform features such as Android intents, platform permissions, TouchID, Keychain, or failure to use platform security controls of the mobile operating system. In order for this vulnerability to be exploited, the organization must expose a web service or API call that is consumed by the mobile app.

Impact of vulnerability: The impact of exploiting this vulnerability ranges in severity from changing the content of the app to complete account compromise.

Prevention: Secure coding and configuration practices must be used on the server side of the mobile application.

2. Insecure data storage

Storing unencrypted data in the device's local storage is a bad practice, as there are malicious apps that may attempt to retrieve sensitive information from it. Attackers can  also retrieve data from a stolen device directly.

Impact of vulnerability: Exploiting this vulnerability can result in data loss and/or extraction of the application’s sensitive information. Business impact includes identity theft, fraud, reputation damage, external policy violation (PCI) and material loss.

Prevention: To prevent this kind of attack, you can encrypt the stored data or/and restrict access to the local data storage. As OWASP suggests, it is important to understand the information assets that the app processes and how the APIs handle those assets.

3. Insecure communication

In this type of attack, malicious actors exploit vulnerabilities to intercept sensitive data in a compromised network (e.g. monitoring the network traffic of a company). Targeted attacks are easier to perform.

Impact of vulnerability: By exploiting this flaw, attackers can expose personal data, or even fully compromise accounts and servers. For businesses, it can result in a privacy violation which in turn may result in identity theft, fraud, or reputational damage.

Prevention:

• Use SSL/TLS protocol for secure communication.

• Rely on strong industry-standard cipher suites with appropriate key lengths.

• Ensure that certificates are signed by a trusted CA provider and not self signed.

• Require SSL chain verification.

• Apply a separate layer of encryption to any sensitive data before it is given to the SSL channel.

4. Insecure authentication

Attackers usually use available or custom automated tools to exploit this vulnerability. They try to log in using default credentials or by bypassing authentication protocols with poor implementation.

Impact of vulnerability: The impact of poor authentication can result in reputational damage, information theft, or unauthorized access to data.

Prevention:

• Ensure all authentication requests are performed server-side.

• Encrypt data when client-side storage is used.

• Check that persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.

• Ensure that device-specific authentication tokens must be utilized by the app.

• Do not allow users to provide 4-digit PIN numbers for authentication passwords.

5. Insufficient cryptography

Data that has been improperly encrypted, can be reverted by attackers with physical access, or through malware applications.

Impact of vulnerability: This vulnerability will result in the unauthorized retrieval of sensitive information from the mobile device. Also, this can have a number of different business impacts like privacy violations, information theft, code theft, intellectual property theft, or reputational damage.

Prevention: To prevent this attack one should avoid storing sensitive data in the mobile device, apply cryptographic standards that will withstand the test of time for at least 10 years into the future, and follow the NIST guidelines on recommended algorithms.

6. Insecure authorization

Attackers usually use available or custom automated tools to log in to an application as a legitimate user. After logging in, they can perform binary attacks against the mobile app and try to execute privileged functionality that should only be executable with a user of higher privilege while the mobile app is in "offline" mode.

Impact of vulnerability: The impact of insecure authorization can result in reputational damage, fraud, or information theft.

Prevention: To prevent this attack, roles and permissions of the authenticated user must be verified using only information contained in backend systems. The backend code should also verify the identities.

7. Poor code quality

In this case, an attacker can pass untrusted inputs to method calls that are made within the mobile code. Poor code-quality issues are typically exploited via malware or phishing scams. Typical types of attacks will exploit memory leaks and buffer overflows.

Impact of vulnerability: Poor code quality issues that result in remote code execution could lead to information theft, reputational damage, intellectual property theft.

Prevention: To prevent code quality issues:

• Maintain consistent coding patterns that everyone in the organization agrees upon.

• Write code that is easy to read and well-documented.

• Always validate the lengths of any incoming buffer data.

• Identify buffer overflows and memory leaks using third-party static analysis tools.

8. Code tampering

Attackers can create malicious apps by modifying the source code of existing apps and hosting them in third-party app stores. Attackers can also deliver these modified malicious apps to the victim by using phishing techniques.

Impact of vulnerability: Code tampering can result in unauthorized new features, identity theft, fraud, revenue loss due to piracy, and reputational damage.

Prevention: To prevent such an attack, mobile apps must be able to detect at runtime that code has been added or changed. Also, since apps like these will execute within a jailbroken or rooted environment, users can check if the device is rooted or jailbroken.

9. Reverse engineering

Attackers will download an app from the app store in order to perform reverse engineering and static analysis techniques, using available tools. This allows them to understand the functionality of the app, change the code, and recompile it.

Impact of vulnerability: Attackers can then reveal information about backend servers and perform attacks, reveal cryptographic constants and ciphers, steal intellectual property. This can result in reputational damage for companies and customer identity theft. 

Prevention: Code obfuscation is key to mitigating reverse engineering vulnerabilities.

10. Extraneous functionality

Attackers will try to understand how the app works, in order to discover the functionality of the back-end system. Then, they try to exploit the back-end system directly.

Impact of vulnerability: The technical impact of this type of attack includes exposure of the backend systems functionality, and execution of unauthorized high-privileged actions, as well as reputational damage and intellectual property theft.

Prevention: Source code reviews should be performed manually in order to protect against this type of vulnerability.

Suggested tools for Android penetration testing

Below is a list of tools that can be used to conduct Android application penetration testing. Some are used for automated testing, and others for manual testing.

Automated Android penetration testing tools are good for scanning common vulnerabilities. They offer a faster and cheaper solution in comparison to manual tools and processes, which offer more depth and vulnerability insights by combining human intelligence with automated tools:

• Android Debug Bridge (ADB): A versatile command-line tool that lets you communicate with a device.

• Dex2jar: Converts .dex files to .class files, zipped as a jar file.

• JD-GUI: A standalone graphical utility that displays Java sources from CLASS files.

• JADX: Command line and GUI tools for producing Java source code from Android Dex and APK files.

• APKTOOL:  A tool for reverse engineering 3rd party, closed, binary Android apps.

• Burp Suite: A set of tools used for web applications penetration testing.

• Frida: A dynamic instrumentation toolkit for developers, reverse engineers, and security researchers.

• Objection: A runtime mobile exploration toolkit, powered by Frida, built to help you assess the security posture of your mobile applications, without needing a jailbreak.

• Ghidra: A software reverse engineering (SRE) suite of tools developed by NSA's Research Directorate in support of the Cybersecurity mission.

• Drozer: drozer (formerly Mercury) is the leading security testing framework for Android.

• MobSF: Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.

Setting up the pentesting environment for Android

In order to conduct assessments of Android devices and applications, we require either a real or emulated Android device. An Android Virtual Device (AVD) is provided along with the Android Studio IDE (Integrated Development Environment), and it is a good solution to start with. (Large mobile development teams may need something more robust).  

Genymotion and Corellium are also good options, as they provide a cloud-based environment and ARM-based virtualization (CPU architecture used for mobile devices). Utilizing the cloud-based environment, we can spawn and customize mobile devices using the web browser, while Corellium gives the options to root or jailbreak the Android or iPhone device accordingly.

ARM is the CPU architecture used for Android and iPhone devices today. Kernel exploitation is related to the CPU architecture. Most emulators virtualize a non-ARM CPU architecture, this makes it impossible for a pentester to work on a potential new kernel exploitation technique using a mobile emulator. Fortunately for us, Corellium and Genymotion solve this problem with ARM-based virtualization.

Installing Android Studio on Linux is really easy. All we have to do is unzip it and run the file studio.sh inside the bin/ directory. To install Android Studio on Windows or macOS, we need to follow the setup wizard. The process is pretty much the same for both operating systems.

On Windows, for example, we click on the executable and then follow the steps of the setup wizard. After the installation is complete, we just need to wait for some components to download. 

Once this is done, click Finish and then New Project.

Select Empty Activity and then click Next in the following window.

Finally, click Finish to complete the process.

Now that we have created a new project, we just need to wait for some more files to be downloaded automatically from the IDE. When that's done, click on the top centre of the IDE (as below) and select AVD Manager.

On the AVD Manager menu, click on the green Play button to start the emulator.

Once the device is started, it should look like this: 

Five effective Android penetration testing techniques

In an Android device, there are many things you test to discover security flaws.

Reversing the code of an APK (Android Package) file, intercepting HTTP requests, or even enumerating the file structure of an installed application, could lead to the potential exposure of sensitive information that might allow us to change the intended logic flow of a particular functionality. I'll explain how to examine an Android device in the sections below.

1. Local data storage enumeration

In order to enumerate the file structure of an installed application, we need to have access to a real or emulated device. This could be achieved by using the Android Debug Bridge (ADB), a command-line tool that lets you communicate directly with the device. Using ADB, we can install and debug applications, while the Unix shell it provides can be used to run commands on the device.

ADB can be easily installed in Linux by typing sudo apt install adb. Once installed, the adb client also starts an adb server, which in turn sets up connections to all running devices automatically. If this doesn’t work, we have to establish the connection manually, by following the steps below: 

Connecting via ADB manually

First, we enable the USB Debugging option on the device. To do so, we tap on Settings, then About Device or About Phone, depending on the device, and then we scroll down and tap on the Build Number seven times until the message "You are now a developer!" pops up.

Next, tap the back button one time and navigate to Developer Options.

Then scroll down to the Debugging section until we find and enable the USB Debugging option.

Now that USB Debugging is enabled, we can install ADB in Linux by typing sudo apt install adb. Back on our Android device, we tap on the Settings icon, then navigate to Wi-Fi, and finally tap on the gear icon at the top right of the screen in order to obtain an IP address.

Once we get the IP, we type adb connect 192.168.232.2:5555. This command will also start an adb server locally, waiting for new connections. According to the official ADB documentation, port 5555 is used by the adb server, and it is the first port in a sequence that the emulator will attempt to connect to. Once the connection is established, we can type adb devices to list the connected devices.

The connected devices might be displayed either in the format of name-port or ip-port. In our case, the device is displayed as emulator-5554.

Important directories

The directories listed below are the most important directories in an Android device and are worth being aware of.

• /data/data: Contains all the applications that are installed by the user.

• /data/user/0: Contains data that only the app can access.

• /data/app: Contains the APKs of the applications that are installed by the user.

• /system/app: Contains the pre-installed applications of the device.

• /system/bin: Contains binary files.

• /data/local/tmp: A world-writable directory.

• /data/system: Contains system configuration files.

• /etc/apns-conf.xml: Contains the default Access Point Name (APN) configurations. APN is used in order for the device to connect with our current carrier’s network.

• /data/misc/wifi: Contains WiFi configuration files.

• /data/misc/user/0/cacerts-added: User certificate store. It contains certificates added by the user.

• /etc/security/cacerts/: System certificate store. Permission to non-root users is not permitted.

• /sdcard: Contains a symbolic link to the directories DCIM, Downloads, Music, Pictures, etc.

Enumerating 

In Android, the directory /data/data/ contains the installation directories of every application that is installed on the device. This directory is private and cannot be accessed by other apps or by non-root users. Having root access via ADB, we can list the contents of this directory.

As mentioned earlier, applications that are stored in the internal memory of the device reside in the directory /data/data/. In some cases, directories like databases and shared_prefs are created as part of the installation process. The databases directory is usually populated when the app is first run, storing structured data in a private database.

Having access to the device via ADB, we can enumerate any available databases using the `sqlite3` client. Let’s say that the /data/data/com.example.demo package is installed, and a database is used for storing data. In that case, the database can be found under the directory /data/data/com.example.demo/databases/.

Once the database is identified, we can use the sqlite3 tool to read its content.

Databases are not the only place where data is stored. In the source code, SharedPreferences are objects that point to XML files in order to read and write on them. These XML files eventually will contain a collection of key-value pairs, and will be stored in a directory called shared_prefs. Reading these files, sensitive information can be gained.

Storing any sensitive values in encrypted form can mitigate information disclosure attacks like the one we saw earlier. Also, using libraries like EncryptedSharedPreferences might be a good solution for securing the content of the XML files, as it encrypts the key-value pairs.

2. Extracting APK files

Reverse engineering an APK file could lead to bypassing various security measures. APK files can be reversed by using open-source tools such as dex2jar, JADX, JD-GUI, APKTOOL, and others. Let’s see how we can reverse an app, and use the information gathered from the source code to bypass an authentication mechanism.

Finding the APK Online

Having an APK file allows us to install it and play around with its functionality, before we get started with reverse engineering. Extraction of an APK file can be performed in many ways. The first approach we are going to examine is finding the APK online. To do that, we navigate to APKCombo, and search for the app of which we want to export the APK file. Let’s search for the Twitter app.

Select the first result, and click on the green button that says Download APK.

Finally, click on the Twitter icon to download the APK file.

That’s it. Twitter APK has been downloaded successfully.

Extracting the APK using third-party Tools

Android third-party tools can also be used to export APKs. APK Export is an Android application that automatically exports the APK file of another app and stores it locally. We can install APK Export directly from the Google Play store.

Once it’s installed, we can start it by tapping on it and then navigate to the desired app.

Let’s try to export the APK file of the application HelloKotlin. To do so, we tap on the HelloKotlin app, and then tap on the disc icon at the bottom-right of the window.

Then, if we navigate through the file storage using a file explorer app, we see a new directory called "apk".

Finally, browsing to the APK folder, we can see that "HelloKotlin1.0.apk" has been successfully exported.

Extracting the APK from the device

Let’s now assume that the application is not available in the Google Play store. When an application is already installed on the device, the APK file is stored in the directory /data/app/<package name>-1/base.apk. 

For example, if the package name is com.example.myapp, the full path of the APK should be /data/app/com.example.myapp-1/base.apk.

We can see that the package name is followed by a number. In some Android versions this is a sequence number, and in other versions a random string. Reading the content of the directory /data/app/ is not permitted for non-root users, and thus it is difficult to guess the full package name of the app.

To get the package name we can type the following command, since the app name is usually a part of the package name.

adb shell pm list packages | grep myapp

Once we get the package name, we type the following command to get the full path of the APK file.

adb shell pm path com.example.myapp

Finally, we can type the following command to retrieve the base.apk file.

adb pull /data/app/com.example.myapp-1/base.apk

3. Reverse engineering using JADX

Let’s now proceed to the next part of the process, reverse engineering the APK.

Assuming that the application is installed in an AVD, we can see that its main function is to ask for a VIP code, and if this passes validation it returns a ticket.

Let’s go ahead and reverse the APK file to examine the source code. Using JADX-GUI, we can directly open the APK file and read the application’s Java pseudocode. You can install this tool via the APT package manager on Linux by typing apt install jadx or downloading it from GitHub. Type jadx-gui to start the program, and load the demo.apk file.

Then we can navigate the application structure. On the left side of the window, we can see the packages and files that are contained in the APK file.

In some cases, source code can be obfuscated. Obfuscation is the process of making the code difficult for humans to read. Android Studio is using ProGuard for code obfuscation.

ProGuard is an open-source command-line tool that shrinks, optimizes, and obfuscates Java code. In a new Android Studio project, under the Grandle Scriptssection, there is a file called proguard-rules.pro where you can specify additional rules. Obfuscating the source code doesn’t mean it’s completely unreadable.

When obfuscating with ProGuard, all method names are replaced with letters like a, b, c, and so on. This way, it will be difficult for someone to understand the functionality of the app, and thus, it will partially protect it from reverse engineering. In Android Studio, code obfuscation is not enabled by default. To enable it you have to set the boolean variable minifyEnabled to true, in the build.gradle file.

For more information about ProGuard and Android Studio, read the official documentation here. (Analyzing the source code of an obfuscated application will be the subject of a future blog post!) Looking at the right window on JADX-GUI, we see the source code of the app.  Let’s take a look at the source code of the class MainActivity.class.

This snippet of code indicates that the AES algorithm is being used to encrypt the string that gets returned to the user, if the right password is provided. The secret key for the encryption is also revealed. Close inspection of the source code, and in particular the following snippet, reveals the ciphertext.

The source code of the APK file gives us all the information we need to create a script and decrypt the ciphertext. The script can be written in any language we choose. Following methodologies like this, we can reverse any APK file, in order to study the flow of the source code and change or bypass the intended functionality.

4. Decompiling and recompiling the APK file

Another useful tool that can be used in Android reverse engineering, is Apktool. 

It can also be used to further examine an application whose code is obfuscated. The main features are the ability to disassemble the APK, allowing this way to read and make changes to the source code, and then rebuild the resources back to the APK file. This lets the user change the functionality of the application.

Let’s assume that we have the following application, and we want to try to bypass the login screen.

In order to do this, we will try to reverse engineer the app, find and edit the snippet of code that validates the user’s input, and then recompile it. For this, we are going to use Apktool. Apktool will provide us with Smali code. Smali code is harder to read compared to the Java pseudocode that JADX provides. To have a good first glance of the source code flow, let’s open the apk file with JADX first.

As we can see, the above snippet of code reveals an if statement that looks like it checks for username and password. More specifically, the embedded if statement looks like it validates the MD5 value of the user input, with an existing MD5 string, and if they match, a message is displayed, otherwise, the message "Wrong Credentials" is displayed instead. Let’s try to find and edit this snippet of code using Apktool.

In order to install Apktool in a Debian-based Linux system, type apt install apktool. Then type apktool d demo.apk to start disassembling the APK file.

Once the decompilation is done, we can go on and list the content of the file demo that has been created.

As we can see, Apktool has decompiled AndroidManifest.xml. As we mentioned earlier, this file contains information about the application's package name, activities, resources, version, etc. This file provides important information when enumerating an APK file. Apart from this file, we also notice the directory smali.

Smali code is an assembler/disassembler for the dex format used by dalvik, Android's Java VM implementation. In other words, it is a symbolic language, like the Assembly code of a C program. As we mentioned earlier, java classes are packed in a dex (Dalvik Executable) file format, to be executed by the Android Runtime.

Since we have access to the smali code, we can read it, change it, and recompile it using Apktool. Below we can see the decompiled Activities of the app: 

Let’s open the MainActivity$a.smali and read its content.

After scrolling down a bit, we can find the line that contains the MD5 string, and the if statement that checks if the MD5 value of the user input is equal to this MD5 string. Let’s try to change this statement and make it check if the input is not equal to this MD5 string. This way, the app will allow us to login whenever we type the wrong password.

To do this, we have to change the instruction if-eqz to if-nez.  Then, we will recompile the edited code along with the resources and create a new APK file. To do this we type the following command and pass as an argument the name of the directory that was created when we decompiled the demo.apk file.

apktool b demo

If the build is finished successfully like in the picture above, all we have to do is sign the new APK file that is created with a self-signed certificate, and install it on our device. First, we generate a new key keytool -genkey -keystore john.keystore -validity 1000 -alias john.

Once we have our key generated, we type the following to sign the APK file:

jarsigner -keystore john.keystore -verbose demo/dist/demo.apk john

The APK file was signed successfully, and it’s located inside the directory ./demo/dist/demo.apk. Before we install it on the device, we first need to uninstall the one that is already installed. We can either do this from the UI or type the following in the terminal: adb uninstall com.example.demo

We can now go on and type the following command to install the new APK: adb install demo.apk

From the UI we find the application name Demo and tap on it. Once it's opened, we type the username admin, as we saw on the source code in the previous step, and then provide a random password.

The message "Login Successful!” is displayed on the screen indicating that we have successfully bypassed the login screen of this app. More reverse engineering techniques can be used for both static and dynamic analysis, using tools like Ghidra and Frida, but this will be the subject of a future blog post.

5. Intercepting network traffic

The process of intercepting HTTP requests in Android using Burp Suite is straightforward. Many Android apps are using servers to process or store data remotely. While the app and the server are communicating, one could intercept the requests/responses, and read the data that are sent over the HTTP protocol.

Let’s examine a scenario in which the app is featuring a login form that sends the data to a remote server, in order to authenticate the user. Furthermore, this app has the user’s credentials stored from a previous session, but the password is hidden and thus, it’s unreadable.

Assuming that the app uses a remote service to authenticate the user, one could read the password by intercepting the HTTP request. Android Virtual Device (AVD), provides a configuration tab in which the proxy preferences can be set up, under Settings -> Proxy. Check the Manual Proxy Configuration option, and then set the IP address of the host and port 8080.

Having the proxy settings configured on the AVD, we need to edit the IP address of the proxy server, changing it from localhost to the local IP address of the host.

Once this is done, we can go on and start the proxy server using Burp, and then click the login button in the app. We see below the intercepted request, along with the user’s credentials in plain text.

In order to mitigate issues like this, Secure Sockets Layer (SSL) can be used. Implementing SSL in Android can be done in various ways. However, techniques to bypass these implementations have been developed as well.

For example, SSL Pinning is a technique that is used to prevent man-in-the-middle attacks. This technique either puts the certificate in the app bundle (Certificate Pinning), or includes the certificate’s public key or hash inside the source code as a string.

Frida is a well-known framework used in mobile assessments that allows us to tamper with the application’s code at runtime. Using Frida to inject code into the APK, SSL pinning can be bypassed. A more in-depth examination of the Frida framework will be the subject of a later blog post.

Forensics can help form a more detailed picture of mobile security

In some cases reverse engineering won't show you the true damage done by a malware infection or compromised app, this is where forensics comes in. Forensic examinations will help you identify evidence of a breach and prevent your apps from being compromised in the future by revealing more details behind a vulnerability.

With Android devices, it’s possible to make a copy of the disk image in order to further examine it using tools like Autopsy. Autopsy is an open-source digital forensics platform that works well on Windows. This tool can help you retrieve deleted files and images from the disk, read databases, EXIF data, SMS and phone call logs, read the history of a web browser, and much else.

Android disk images can be acquired in devices that are rooted. Rooting an Android device can be done in many ways. At this point, it is worth noting that having access to the device’s terminal as the root user is a completely different thing than rooting the device itself. Rooting an AVD like the Nexus 5X we set up earlier in Android Studio can be easily performed by following the instructions in this GitHub project. The following image shows the results of the application RootChecker, after successfully rooting the device.

Once the device is rooted, the disk image can be acquired by using the dd Unix utility. At this point, we also need to introduce the application BusyBox. BusyBox is a software suite that provides several Unix utilities in a single executable file. It can be installed via ADB on a rooted device.

Assuming we have a rooted AVD with BusyBox installed, the partition we need to acquire is the one that is mounted on the `/data` directory. The mounted partitions on an Android device could look like this.

Device drivers for hardware and special device files appear in the file system just like normal files. The dd  command-line utility is capable of backing up the boot sector of a hard drive. Once we have found the right partition, we can use dd to acquire the disk image, and nc from the BusyBox app in order to send the disk image directly to our host machine. The following command acquires the disk image, and starts a listener.

adb shell "dd if=/dev/block/dm-0 | busybox nc -l -p 8888" &

Next, we forward the traffic on port 8888, using ADB.

adb forward tcp:8888 tcp:8888

Finally, we run the following command to get the disk image locally.

nc 127.0.0.1 8888 > disk.dd

Once this is done, we can start Autopsy and follow the steps that are provided in order to load the disk image. First, let’s name the new case.

Next, we set the case number.

In the next step, select the Host Name and the Data Source Type.

Then select the disk image that we acquired earlier, and load it as a Data Source.

Finally, click Next and Finish.

At this point, the disk image should be loaded successfully. Looking at the left window, we can see a folding menu that allows us to navigate through the files that have been collected from the device.

A great feature of Autopsy is the ability to recover deleted files from the device. The image below shows that the deleted file Credentials.xlsx has been recovered.

Practice your Android penetration testing skills

This article has introduced some of the most common techniques for assessing the security of an Android application or device. Mobile devices are an integral part of our daily lives, and interest in both how to secure and hack these devices is expected to increase in the years to come.

The best way to learn the techniques we've covered is to put your skills to the test in a realistic environment where you can use common Android exploitation vectors!

🎮 PLAY THE TRACK

Author bio: Grigoris Papoutsis, Innovation Engineer at Hack The Box (bertolis).  Having worked as a Penetration Tester, I’m passionate about mobile security and creating innovative content for cybersecurity training. And as a former HTB machine creator, I love creating content that would motivate people to start learning new technologies, especially mobile security tech. Outside of content creation, I’m a core member of the cyber security INSSec research group (University of West Attica), and graduated with an M.Sc degree in Digital Systems Security and hold a B.Sc in Computer Science with a specialization in software development. You can connect with me on LinkedIn or Twitter.