An Introduction to Mobile Application Penetration Testing

Mobile application penetration testing is a form of security testing that is used by companies to evaluate security from inside of a mobile environment. Mobile penetration testing is built on OWASP mobile application security verification standard. Mobile pentesting performed by qualified reputable specialists is focused on client-side safety, file system, hardware, and network security.

The companies ignoring mobile penetration testing face the risk of experiencing not only direct financial losses but also reputational and legal damage after the release of their mobile apps due to security problems. That is why mobile application penetration testing should become a core element of security testing for every solid developer of applications for mobile phones.

Introduction to Android Security


When we talk about operating system, the most common answers were Windows, Linux, and mac operating system. However, with the undying competition in the mobile phones market, the next big thing entered was ANDROID, which in no time became the heart of smart phones. Android provides a rich application framework that allows you to build innovative apps and games for mobile devices in a Java language environment.

Android is a mobile operating system developed by Google, based on a modified version of the Linux kernel and other open source software and designed primarily for touch screen mobile devices such as smart phones and tablets. In addition, Google has further developed Android TV for televisions, Android Auto for cars, and Wear OS for wrist watches, each with a specialized user interface. Variants of Android are also used on game consoles, digital cameras, PCs and other electronics.

The Android Operating System is a Linux-based OS developed by the Open Handset Alliance (OHA). The Android OS was originally created by Android, Inc., which was bought by Google in 2005. Google teamed up with other companies to form the Open Handset Alliance (OHA), which has become responsible for the continued development of the Android OS.

The android is a powerful operating system and it supports large number of applications in Smart phones. These applications are more comfortable and advanced for the users. The hardware that supports android software is based on ARM architecture platform. The android is an open-source operating system means that it’s free and any one can use it.


The Android operating system is built on top of a modified Linux kernel. Android software stack contains a Linux Kernel, collection of c/c++ libraries which are exposed through an application framework services, runtime, and application.

Android system architecture contains the following components:

The Linux Kernel

The whole Android OS is built on top of the Linux 2.6 Kernel with some further architectural changes made by Google. It is this Linux that interacts with the hardware and contains all the essential hardware drivers. Android uses the Linux for all its core functionality such as Memory management, process management, networking, security settings etc. As the Android is built on a most popular and proven foundation, it made the porting of Android to variety of hardware, a relatively painless task


This layer controls and accesses applications data. Android provides a lot of C/C++ libraries for different uses. Here some of the most useful libraries:

  • System C Library: It allows developers to createapplications.
  • Media framework: It is useful to program video and audio files.
  • Android.content: It allows messaging between applications and application components
  • Android.webkit: It provides access to the internet within an application
Android Run Time

This layer consists of Dalvik Virtual machine and Core Java libraries, Dalvik VM is a type of JVM used in Android devices to run apps and is optimized for low processing power and low memory environments. It allows multiple instance of Virtual machine to be created simultaneously providing security, isolation, memory management and threading support

Application Framework

These are the blocks that our application directly interacts with. These programs manage the basic functions of phone like resource management, voice call management etc

System Apps

This is the top layer in the Android architecture and this is where applications run. Several standard applications come pre-installed with every device, such as SMS client app, Dialler, Web browser, Contact manager etc. Most studies regarding security of smart phones have mainly focused on the application layer, such as viruses, worms, MMS exploitation and Cross-Service Attacks.

The only problem with the work is that Android Versions have tripled with a lot of bug fixes and modification in the security architecture of the recent Versions. So the test can only be true for earlier Version of the Android based smartphones. This paper is an improvement in the earlier work using more simplified and sophisticated method for information gathering and port scanning.

Android operating system deployed on a Virtual machine with respect to its core architecture and TCP/IP network stack security issues. The security analysis was performed using a white box penetration testing. Information on the target system were gathered and identified and then penetration tests performed, starting from well-known vulnerabilities to more specific deep penetration attacks. The test was performed on a simulated virtual machine with Android images using open source penetration tools

Android Security Features

Like the rest of the system, Android’s security model also takes advantage of the security features offered by the Linux kernel. Linux is a multiuser operating system and the kernel can isolate user resources from one another, just as it isolates processes. In a Linux system, one user cannot access another user’s files unless the user has elevated permissions. Android takes advantage of this user isolation but treats users differently than a traditional Linux system does. In a traditional system, a UID is given either to a physical user that can log into the system and execute commands via the shell, or to a system service that executes in the background.

Android was originally designed for smartphones, and because mobile phones are personal devices, there was no need to register different physical users with the system. The physical user is implicit, and UIDs are used to distinguish applications instead.

Below are the security features provided by Android to make the Android devices you develop as secure as possible.

App sandbox

Android automatically assigns a unique UID which is called app ID, to each application during installation and executes that application in a dedicated process running as that UID. Additionally, each application is given a dedicated data directory which only it has permission to read and write to. Thus, applications are isolated, or sandboxed, both at the process level and at the file level.

This creates a kernel-level application sandbox, which applies to all applications, regardless of whether they are executed in a native or virtual machine process. System daemons and applications run under well-defined and constant UIDs, and very few daemons run as the root user. Android does not have the traditional /etc/password file and its system UIDs are statically defined in the android filesystem config.h header file.


Android uses the concept of user-authentication-gated cryptographic keys that requires cryptographic key storage and service provider and user authenticators.

On devices with a fingerprint sensor, users can enroll one or more fingerprints and use those fingerprints to unlock the device and perform other tasks. The Gatekeeper subsystem performs device pattern/password authentication in a Trusted Execution Environment (TEE).

Android 9 and higher includes Protected Confirmation, which gives users a way to formally confirm critical transactions, such as payments.


Android 9 and higher includes a BiometricPrompt API that app developers can use to integrate biometric authentication into their apps in a device- and modality-agnostic fashion. Only strong biometrics can integrate with BiometricPrompt.


Once a device is encrypted, all user-created data is automatically encrypted before committing it to disk and all reads automatically decrypt data before returning it to the calling process. Encryption ensures that even if an unauthorized party tries to access the data, they won’t be able to read it.


Android offers a hardware-backed Keystore that provides key generation, import and export of asymmetric keys, import of raw symmetric keys, asymmetric encryption and decryption with appropriate padding modes, and more.

Security-Enhanced Linux

As part of the Android security model, Android uses Security-Enhanced Linux (SELinux) to enforce mandatory access control (MAC) over all processes, even processes running with root/superuser privileges (Linux capabilities).

Trusty Trusted Execution Environment (TEE)

Trusty is a secure Operating System (OS) that provides a Trusted Execution Environment (TEE) for Android. The Trusty OS runs on the same processor as the Android OS, but Trusty is isolated from the rest of the system by both hardware and software.

Verified Boot

Verified Boot strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption. It establishes a full chain of trust, starting from a hardware-protected root of trust to the bootloader, to the boot partition and other verified partitions.

APK File Structure

An APK file is an archive that usually contains the following files and directories:

Manifest file:An additional Android manifest file, describing the name, version, access rights, referenced library files for the application. This file may be in Android binary XML that can be converted into human-readable plaintext XML with tools such as AXMLPrinter2, apktool, or Androguard.

Signatures (META-INF):It contains the Certificates and the signatures.

Assets:A directory containing applications assets, which can be retrieved by AssetManager.

Compiled resources(resources.arsc):A file containing precompiled resources, such as binary XML for example

Native Libraries(lib): The directory containing the compiled code that is platform dependent; the directory is split into more directories within it:

  • armeabi-v7a:compiled code for all ARMv7 and above based processors only
  • arm64-v8a:compiled code for all ARMv8 arm64 and above based processors only
  • x86:compiled code for x86 processors only
  • x86_64:compiled code for x86 64 processors only

Dalvik bytecode(class.dex):The classes compiled in the dex file format understandable by the Dalvik virtual machine and by the Android Runtime.

Resources(res):the directory containing resources not compiled into resources.arsc

Introduction to Mobile Application Penetration Testing - Part 2