This digital world aims to provide as much feasibility to the users that they can do everything from handheld devices. With this much flexibility come greater security risks. A subset of such risks lies in mobile applications (Android & IOS). We must secure these applications to make the digital world safer for everyone in the ecosystem. In this series of articles, we will discuss common Android Application vulnerabilities and how can you perform Android App Pentest to look for these vulnerabilities.
In this era of technology, almost every person has a smartphone and prefers these smartphones for accessibility. People now go with the “Mobile First” approach for almost everything. Since everything is now accessible with a single touch through these devices, smartphones have emerged in the lives of people as a necessity. According to research, there has been a tremendous increase in mobile phone usage in terms of internet traffic.
Previously, when mobile devices were not so common and internet access was limited, people used to visit websites through desktop computers. But as time passed, and with the accessibility of the digital ecosystem, people shifted toward a mobile-centric approach in their daily life. Since then, mobile applications have come into play to facilitate the users for a smoother experience.
To understand things better, first we will cover some basics of Android Architecture and a glimpse of how things work at low level.
Android Architecture
Android OS is based on the Linux Operating System. There are multiple layers in the Android OS and each layer has specific set of functionalities. However, each layer relies on the security of the lower layers. So, it is important to secure each layer to achieve device’s security.

Since our focus is on Android Application Security, we will focus on the top most layer. In this layer, applications install and run, and also interact with the server. For the scope of this testing , we will be interacting with the android system. So, it is important to know the file/folder permissions follow linux model. Therefore, while interacting with the android through a shell, we will use linux commands.

Android Virtual Machines
There are 2 types of Virtual Machines
- System Virtual Machines that provide a substitute for a real machine
- Process Virtual Machines that are to execute computer programs in a platform-independent environment
Android also uses Process Virtual Machines to run the APK files and following are some benefits for it:
- Application code isolation from core OS
- More stability & reliability
- Cross compatibility & platform independency
Every application runs in Android Virtual Machine. Android apps are compiled into platform independent Dalvik EXecutable (DEX)
. DVM (Dalvik VM) is VM that is optimized for mobile environment as compared to JVM. You can read more about why android does not use JVM here. However, DVM follows the principal of JVM. So the developers don’t need to write code for specific hardware or OS versions. Android VM runs the DEX directly compiled from the original Java code.
Android used DVM prior to KitKat (v.4.4). But with the introduction of KitKat, Android began using a new Virtual Machine, Android RunTime (ART)
. Eventuallly, android phased out DVM entirely with Lollipop (v.5.0). Both DVM & ART work on DEX, but ART has new optimization features. You can read more about the VMs in Android here.
Android RunTime (ART)
ART is the modern translation layer from application’s bytecode to device instructions. In ART, every app runs in its own sandboxed VM. On installation of an application, it creates a new unique user for the application to store and access the data in the file system. This is similar to file/folder permissions in linux and this way, all applications are isolated.
Data Storage
By default all application data is stored in its own folder which is in /data/data
folder. The folder of application is named according to the application’s package name usually starting with com.something.app
. This folder can only be accessed by the application’s own user and root user.
In addition to this, /data/app
folder stores generic application data.
To interact with other applications, user must explicitly provide the permissions or developers must expose a Content Provider/Broadcast Receiver in the application.
Need for Rooted device
Root user can access all the application’s data and its folders. For this reason, we mostly root the android device so that we have maximum level of access for performing Android App Pentest.
Application Security & APK Signing
Android requires that all APKs be digitally signed with a certificate before they are installed on a device or updated. Every developer must sign the APK with their own signing key. We can reverse engineer any android application and get access to the application’s source code. Having access to source code, we can modify the code and eventually rebuild the app and sign it. This opens new attack vector for attackers to inject malicious code in the application and change the app’s functionality.
Google PlayStore is the trusted marketplace to download and install the applications. And one must not directly install the APK unless they are sure of its legitimacy and being non-malicious.
Public Key Cryptography
Since anyone can modify the source code and sign the application and then publish to PlayStore, how can we ensure its integrity? How can be sure of that the application we download and install from PlayStore is coming from the original developer? Here comes the role of Public Key Cryptography. Developer must sign the application with their own upload key (you can get it from Google Play) to upload to the PlayStore. After that Google uses its own App Signing Key
to sign the app for second time before publishing it to the PlayStore. Google’s App Signing Key is unique to each application and adds a unique signature to the apps. Google Play Signing is another name for this.

If you sign the application with any other key rather than developer’s upload key, Google will consider that as a new application rather than the update to the original application.
There are 3 APK signing schemes v1, v2, and v3 each with additional security in later ones. Now a days, developers mostly sign the apps with v2 or v3.
Up Next
This article clears some basics and architectural concepts regarding Android Applications. From next article, we will dive into lab setup for Android App Pentest and start working on pentesting an application.
Leave a Reply