Exploiting Android Architecture

Written by Yuval Batan on

Exploiting Android Architecture

Written by Yuval Batan on


The Android operating system powers millions of smartphones worldwide, offering users an excessive number of applications responsible for every aspect of our lives, from personal organization to online banking applications. Many Android applications contain hidden vulnerabilities that can be manipulated, putting many users at risk for leaking sensitive information, unauthorized actions, and more. In this article, we will explore the key components of the Android application architecture and demonstrate common vulnerabilities for each relevant component on several intentionally vulnerable applications that can be found in the wild.

The Android App’s Key Components

Most Android applications are built with Java or Kotlin programming languages. However, regardless of the programming language, all applications use the following key components: 

  • Activities
  • Intents
  • Services
  • Content Providers
  • Broadcast Receivers

These components work together seamlessly to implement Android applications’ core functionalities, including displaying user interfaces, handling background tasks, responding to system events, and managing data.


While various tools can be used to achieve the same impact, we will use the following tools for demonstrating the various vulnerabilities:

  • Android Debug Bridge (ADB) – A desktop command-line tool for developers to communicate with Android devices. It can be used for many options, such as installing applications, debugging, etc.
  • Jadx – An open-source tool used to decompile Android applications (APKs) into readable Java and Smali source code.
  • Android Studio – An Integrated Development Environment (IDE) and code editor for building Android applications.


The Activity is a Class that represents the application’s user interface (UI) and facilitates an entry point for the users to interact with the application’s functionalities. Activities follow a defined lifecycle to ensure smooth transitions and efficient resource management. An Android application includes an Activity for each screen.
One of the vulnerabilities usually related to Activities is Improper Exportation:
The AndroidManifest.xml, a default file in Android applications, contains information and specifications about the different components of the application, including the Activities. Among several specifications, there is the option to mention if the Activity will be exported, which means other applications can access it. When configuring a sensitive Activity with exported=true, the application can be manipulated by accessing the sensitive Activity directly without passing via any application validation. This vulnerability can be more common in old applications (API level 17 and above) where the default value of the exported parameter will be true if not mentioned in specific.

In the following scenario, a login screen is supposed to validate the users’ credentials before proceeding to the next step.

Login Screen Requires Credentials

An improperly configured sensitive activity will allow bypassing the login screen and fetching the flag without validating any credentials. The following steps will exploit this misconfiguration:

  • View the AndroidManifest.xml file in the application’s Java code and notice that SecondActivity, the Activity responsible for storing the flag, can be exported.
SecondActivity is Exported
  • To bypass the login screen, directly export and trigger the SecondActivity Activity using the following ADB command, leading to unauthorized access:

adb shell am start -n {Package Name}/.{Activity Name}

Successfully Fetching Exported Activity using the ADB Command


To mitigate this vulnerability, configure all sensitive components in the application as exported=false or without any configuration when the application is updated and the default exported parameter value is false.


Many components interact and pass data in the application using the Intent mechanism. There are two types of Intent: Explicit and Implicit. The main difference between these two is how they specify the target recipient of the information or action. Explicit Intents define the target component to handle the Intent, providing a precise destination for the data or action.

In contrast, Implicit Intents do not specify a particular target component and instead declare a general action to be performed, allowing the system to determine the appropriate component based on its Intent filters. Each of the Intent types has its vulnerabilities which occur because of their behavior:

Android Intents Diagram

1. Implicit Intent

Implicit Intent does not declare a specific component to handle the action, leading to the main issue that can occur if a malicious actor hijacks an Intent using another application on the same device. The attacker’s custom application can register Intent filters to intercept the Intent, resulting in reading sensitive information and executing unauthorized actions on the targeted app.

For example, in the following scenario, the application uses Implicit Intent to load the website to the application with the user’s session token passed in the URL.

The Vulnerable Application is Accessing a Website With the Victim’s Token

Exploiting the vulnerable application can be done by performing the steps below:

  • Open the application’s Java code, access the MainActivity Activity, and find the code responsible for accessing the website.
Reviewing the Java Code and Observing The Implicit Intent
  • Notice that the application uses a vulnerable Implicit Intent that does not specify the destination of the data.
  • Exploit this code to hijack the user’s session token and build another application on the same device. This can be done by writing the following code:
    • AndroidManifest.xml –  add the ExploitActivity Activity and allow other applications to launch this Activity (exported=true) directly. Also, specify that the Activity should view specifically WEBVIEW actions on the OVAA app.
    • ExploitActivity Activity – extract the url parameter value from the vulnerable application’s Intent and log the session token.
Hijacking Users’ Token Using a Malicious Android Application
  • Build and run the exploit application on the same device, which will hijack and log the user’s token in every use of the vulnerable application:
Successfully Fetching the User’s Token


To mitigate this vulnerability, avoid sending sensitive information, such as tokens, passwords, etc., through Implicit Intent and limit its use as much as possible.

2. Explicit Intent

As mentioned, Explicit Intent specifies the target component to get the information, making it safer to use. However, if not configured correctly, Explicit Intent can also be vulnerable and exploited by malicious actors.


It is recommended that the information received from any resource and its permissions be validated, and the components’ entire path must be specified to avoid attacks such as intent hijacking and more. 


Services are background-running components in Android applications. Unlike Activities, which provide a user interface, services handle long-running operations or tasks that don’t require direct user interaction. They operate in the background, independent of the Activity lifecycle, and even run when the user navigates away from the application. Some of the vulnerabilities that can occur in these components are:

  • Services require specific permissions to access certain resources or functionalities. Improper permission handling, like using unnecessary permissions or granting them to untrusted components, can expose sensitive data or functionalities to malicious actors.
  • If services rely on insecure methods for communication, attackers might intercept or manipulate data being exchanged.
Android Services Lifecycle Diagram


To mitigate this vulnerability, grant services only the essential permissions they need to function. Also, secure methods for communication between services and other application components should be used.

Content Providers

Content providers mediate data sharing between Android applications based on multiple options, such as local and remote databases. They are also responsible for ensuring that only authorized applications can access the data, which, when not implemented properly, can result in the retrieval of sensitive information, unauthorized actions, and more.

In the following scenario, the Android application receives a username as input and adds it to the SQLite database using the Content Provider component without any input validation.

Successfully Adding a User to the Database
  • To further explore this functionality and find the vulnerable code, it is possible to fetch the application’s Java source code:
Java Source Code is Fetched and Vulnerable to SQL Injection
  • This code is vulnerable to SQL Injection attacks, allowing SQL queries to be injected into the username field without sanitization.
  • Exploit this vulnerability by injecting the ‘ or 1=1;– – basic SQL query into the username field, which will reveal all users in the database as follows:
Successfully Dumping the App’s Database Information through SQL Injection


To mitigate this vulnerability, sanitize user input using well-known libraries before inserting it into the Content Provider’s query.

Broadcast Receivers

The Broadcast Receivers are used to send and receive event messages called broadcast messages from other applications, the device itself, and more. These messages include various events, from system events like battery level changes to user actions like connecting headphones. If not implemented correctly, several vulnerabilities can occur, leading to unauthorized access and actions as well as the retrieval of sensitive information.
In the following scenario, the application uses an exported Broadcast Receiver component to receive information from the device, including checking for battery events and a custom event to check if the user enters the correct message value. Because of the exported attribute, it is possible to exploit the application’s logic and send the value from outside the app.

Vulnerable Application Requires a Message Value
  • To investigate the vulnerable application further, we will examine its estimated source code and find out that the Broadcast Receiver is set to exported and that the correct value is hardcoded as an MD5 hashed value.
The Application’s Vulnerable Code
  • Fetching the correct message value, “summer,” from the hardcoded MD5 algorithm hash is possible.
  • Because of the exported Broadcast Receiver, it is possible to send the correct value and retrieve the response from outside the application using ADB, as follows:

adb shell am broadcast -a {Broadcast Receiver Path} –es {Parameter Name} {Value}

 ADB Command Sent Successfully from Outside the App


To mitigate this vulnerability, ensure all Broadcast Receivers are properly secured and not accessible from outside the application. This can be achieved by explicitly defining custom permissions for Broadcast Receivers, thereby restricting access to authorized components only.


As the Android ecosystem expands, the importance of secure development practices cannot be overstated. Comprehensively understanding and effectively utilizing the core components of Android applications: Activities, Intents, Services, Content Providers, and Broadcast Receivers will significantly reduce their attack surface. This proactive approach safeguards user data and privacy and fosters trust within the Android ecosystem, benefiting developers, users, and the platform.

Organizations should prioritize cyber security risk assessments and penetration tests to mitigate risks in Android application deployments. Clear Gate, a trusted cybersecurity provider, offers in-depth manual penetration tests to help organizations strengthen their mobile applications’ security and protect valuable data from potential threats.