Diving Deep: A Comprehensive Guide to Android Penetration Testing — Part 1

Introduction: Navigating the Android Abyss

Salutations, Digital Artisan!

In the vast sea of cybersecurity, Android Penetration Testing emerges as a critical expedition. This comprehensive guide, “Diving Deep,” unfolds across six essential parts, each illuminating a facet of the Android security landscape. Join us on this journey as we navigate through the intricacies, unveiling vulnerabilities, and providing you with the expertise to strengthen your digital defenses. From the foundations to advanced techniques, let’s embark together on this exploration of Android’s security abyss, ensuring you emerge equipped and empowered. Part 1 is full of basics and theory.
Are you ready to dive into the depths of Android Penetration Testing? Let the exploration begin.

Introduction to Mobile Penetration Testing
Mobile penetration testing involves a comprehensive evaluation of mobile devices, applications, and systems to pinpoint vulnerabilities that malicious actors could exploit. Ethical hackers, or penetration testers, employ real attack methods to discover and take advantage of security weaknesses.
The primary objective of mobile penetration testing is to uncover security threats and vulnerabilities, offering guidance on how to address them. This process aids organizations in enhancing the security of their mobile assets, reducing the risk of security breaches, reputational harm, and financial losses.

Mobile Penetration Testing process

Static Analysis: Static analysis, a vital software assessment method, examines code without execution. It’s pivotal for developers and security experts to detect vulnerabilities in code before deployment, enhancing software security. Regular static analysis safeguards software reliability and identifies issues in third-party libraries.

Dynamic analysis : Dynamic analysis, an essential software evaluation method, examines code behavior in real-time through execution. It complements static analysis by revealing hidden vulnerabilities and weaknesses. Developers and security experts employ dynamic analysis regularly to enhance software security and reliability, including third-party library assessments.

Getting Started with Android

If we have a look at the architecture of Android as shown in the following figure, we will see that it is divided into four different layers. At the bottom of it sits the Linux kernel, which has been modified for better performance in a mobile environment. The Linux kernel also has to interact with all the hardware components, and thus contains most of the hardware drivers as well.

The libraries in Android are written in C and C++, most of which are ported from Linux.
All the applications in Android run under a virtual environment, which is called Dalvik Virtual Machine (DVM).
Each and every application that runs will run under its own instance of Dalvik Virtual Machine. So, if we are running three different applications, there will be three different virtual instances

Android Architecture

• Application Layer :The applications are at the topmost layer of the Android stack. An average user of theAndroid device would mostly interact with this layer.
• Application Framework Layer : Our applications directly interact with these blocks of the Android architecture. These programs manage the basic functions of phone like resource management, voice call management etc.
• Native Libraries Layer : The next layer in the Android architecture includes Android’s native libraries. Libraries carry a set of instructions to guide the device in handling different types of data. For instance, the playback and recording of various audio and video formats is guided by the Media Framework Library.
• Kernel Layer : At the bottom of the Android stack is the Linux Kernel. It never really interacts with the users and developers, but is at the heart of the whole system.

Android Components

• Activity: An Activity provides a screen with which users can interact in order to do something. Users can perform operations such as making a call, sending an SMS, etc. Example: Login screen of your Facebook app.
• Intent : Used to launch an Activities , trigger Broadcast Receivers or communication with services.eg. Click on the button.
• Services : Runs in background to perform long operations. Don’t have a user interface.
• Broadcast Receivers : Respond to announcements broadcasted by system or apps . Originate from systems or apps. Don’t have a user interface. Gateway to other apps.eg. Battery Low, boot completed, headset plug etc.
• Content Providers: Allow applications to have centralized data and modify it.(Its like a DB)
  Eg. Contacts , calendar , system dictionary, photos etc

Android file system

The Android file system is organized into various partitions, each serving a specific purpose. Here’s a brief overview of the provided directories:

/boot: Contains the bootloader and kernel, essential for the initial stages of the device boot process.
/system: Holds the Android operating system and system-related files. This partition is read-only to ensure the integrity of the OS.
/cache: Stores temporary files and cached data from apps. Clearing this partition can help resolve certain performance issues.
/misc: Contains miscellaneous system-related files.
/data/data: This is where individual app data is stored, including user settings, databases, and other application-specific information.
/data/app: Holds the APK (Android Package) files of installed apps.
/data/system: Stores system-related data, including system settings and preferences.
/data/local/tmp: Temporary directory for storing files during app installation and system updates.

Application Launch Flow chart

What is an APK file

APK stands for Android Package Kit (also Android Application Package) and is the file format that Android uses to distribute and install apps. It contains all the elements that an app needs to install correctly on your device.

What Does APK File Contains

An APK (Android Package) file is the package format used by the Android operating system to distribute and install applications. It typically contains the following components:

• Classes.dex : The classes.dex file in an APK is the heart of Android app code, containing bytecode that’s optimized for the device’s runtime. It’s created by converting Java bytecode using the dx tool during the build process. This compact file enables efficient execution on the Android Runtime, whether it’s Dalvik or ART. The dex format includes optimizations for size and performance, making it a crucial component for app installation and execution on Android devices.
• Application Code: This includes the compiled code and resources required for the app to function, such as Java or Kotlin code, XML layouts, and image and sound files.
• Manifest File: The AndroidManifest.xml file describes the app’s structure, permissions, components (activities, services, receivers), and other essential information.
• Assets: These are files that the app can use, such as additional media, configuration files, or data files.
• Libraries: APKs may include shared libraries or dependencies required by the app.
• Resources: This folder contains non-code resources like images, icons, and localized strings, which are essential for the app’s user interface and functionality.

Meta-Information: Information like the app’s digital signature, package name, and version code is also included in the APK.

Additional Note :

All the binaries that you use as commands are located at /system/bin and /system/xbin. Also, the application’s data that we install from the Play Store or any other source will be located at /data/data, whereas their original installation file, that is, “.apk” will be stored at /data/app. Also, there are some applications that need to be purchased from the Play Store instead of just downloading it for free. These applications will be stored at /data/app-private.

Android Package (APK) is the default extension for the Android applications, which is just an archive file that contains all the necessary files and folders of the application.

Sandboxing and the permission model

In order to understand Android Sandboxing, let’s take an example with the following figure: As explained in the preceding figure and discussed earlier, each application in Android runs in its own instance of Dalvik Virtual Machine.

An Android application developer has to specify all of these permissions while developing the application, in a file called AndroidManifest.xml.
All the Android applications are assigned a unique UID when they are first started after being installed. All the users with a given UID belong to a particular group depending on the permissions they ask for. For example, an application asking for just the Internet permission would belong to the inet group, as the Internet permission in Android comes under the inet group.
The groups and the permissions inside it are specified in the file in our device named platform.xml located at /system/etc/permissions/

Application Signing

Application signing is one of the unique features of Android, which has led to its success due to its openness and its developer community. There are two types of certificate signing mechanisms in general. One is signed by a governing Certificate Authority(CA) and the other is a Self-signed certificate
To check who signed the application.
$ jarsigner -verify -certs -verbose testing.apk
CERT.RSA file present in the META-INF folder after unzipping the .apk file in order to get the signature
$ unzip testing.apk
$ cd META-INF
$ openssl pkcs7 -in CERT.RSA -print_certs -inform DER -out out.cer
$ cat out.cer

As we conclude Part 1, stay tuned for the seamless transition into Part 2, ensuring a connected and cohesive exploration of our Android Penetration Testing journey.

Feel free to connect with me on LinkedIn for more discussions and insights related to Android Penetration Testing.
You can find me on LinkedIn at @Omkar Gaikwad