Android hacking and security, part 1: Exploiting and securing application components

March 27, 2014 by Srinivas

Mobile Application Security is one of the hottest segments in the security world, as security is really a big concern with growing mobile applications.

In this article, we will go through the attacks associated with Android application components.


What are android application components?

Application components are essential building blocks of an Android App. Every app is built as a combination of some or all of those components, which can be invoked individually. There are four main components in Android, which are explained below.

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.

Service: A Service can perform long-running operations in the background and does not provide a user interface.

Example: Playing Music

Content Providers: A content provider presents data to external applications as one or more tables. In other words, content providers can be treated as interfaces that connect data in one process with code running in another process.

Example: Using content providers, any app can read SMS from inbuilt SMS app’s repository in our device.

*READ_SMS permission must be declared in the app’s AndroidManifest.xml file in order to access SMS app’s data.

Broadcast Receivers: A broadcast receiver is a component that responds to system-wide broadcast announcements such as Battery Low, boot completed, headset plug etc. Though most of the broadcast receivers are originated by the system, applications can also announce broadcasts.

This article focuses on demonstrating the methodology to attack and secure vulnerable Activity components of applications.


You can download the sample application used in this article and follow the steps along with us.

Fill out the form below to download the APK file and Source Code.


As shown in the figure below, this app has two activities. The first activity takes a password as input. If the user enters the correct password he will be landed in a page which says “Private Area”, otherwise he will get a “Wrong password” message. For test purposes, the password to login is set as “password”. Ideally, the first screen should use an intent and invoke the second screen if a valid password is entered. We need to perform black box testing on this app to see if we can bypass the authentication by directly invoking the welcome screen.

Prerequisites to follow the steps

Computer with Android SDK Installed

A Non Rooted mobile device to install the app.

Topics involved:

Information gathering

Attacking Vulnerable Activity Components

Securing the applications

Information gathering

  • Decompile the app with APK tool.
  • Analyze AndroidManifest.xml file for exported Activity components.

Every Android App has a package name and every Activity has its own Class name inside the package. The initial steps are to find out the name of the package and names of the available sensitive activities. Though there are other methods to get this information, looking at the AndroidManifest.xml is a good approach. We can get the AndroidManifest.xml file by decompiling the application using APKTOOL.

  • Download APKTOOL from the link: https://code.google.com/p/android-apktool/downloads/list
  • Place the test application in the same folder as in APKTOOL.
  • Now, decompile the APK file using the following command as shown in the figure:

apktool d testapp.apk

As shown in the figure below, we should now be able to see a new folder named “testapp” with the AndroidManifest.xml file inside it.

Now, we need to search for the package name and its activities.

All the activities will be registered in AndroidManifest.xml file using <activity></activity> tags. So, anything inside these tags will be an activity. Looking at the AndroidManifest.xml file, we are able to see two Activity Components and the package name as shown in the figure below.

By examining the above figure, it is clear that we got the following information about the app.

com.isi.testapp is the name of the package.

com.isi.testapp.Welcome could be the activity we are getting after providing the correct password.

Attacking vulnerable activity components

Our job now is to launch Welcome activity without providing any password in the first screen.

We can perform attacks on vulnerable activity components in several ways, as mentioned below.

  1. Launching sensitive Activities with Activity Manager Tool.
  2. Using a Malicious App to invoke Activities of other apps.
  3. We can also use Mercury framework for performing these attacks, which will be covered in later articles.

Launching sensitive activities with Activity manager tool

Activity Manager is a tool that comes preinstalled with Android SDK and can be used along with “adb shell”. This tool can be used to launch Activities and Services of an application. We can even pass intents using it.

So, let’s begin.

  • Connect the device to the computer and get a shell on the device using the following command:

adb shell

  • Type in the following command to launch the Welcome activity:

am start –n com.isi.testapp/.Welcome

We should now see the welcome screen fired up without providing the password.

Using a Malicious App to invoke Activities of other apps

Another way of invoking other application’s activities is to write a malicious app and feed it with the name of the package and activity to be launched. The figure below is a code snippet to launch an activity where in com.isi.testapp.Welcome is the activity to be launched. In our case, the malicious app doesn’t require any permission to launch the “Welcome” activity of the vulnerable app.

Using Mercury framework

The same attack can be reproduced with Mercury framework. We will discuss Mercury framework later in this series.

Securing the application components

  • Setting android:exported attribute’s value to false

In the AndroidManifest.xml file of our application, we should add the following attribute to the application component to be secured. In our case com.isi.testapp.Welcome
is the activity to be secured.

The above code restricts other applications or any system component other than the current app from accessing this Activity. Only applications that have the same user id as the current app will be able to access this Activity.

  • Limiting access with custom permissions

The android:exported attribute is not the only way to limit an activity’s exposure to other applications. We can also impose permission-based restrictions by defining custom permissions for an activity. This is helpful if the developer wants to limit the access to his app’s components to those apps which have permissions.

Note: The above security controls are applicable to any other Application component which we discussed in the beginning of the article.


Android components 

Posted: March 27, 2014
View Profile

Srinivas is an Information Security professional with 4 years of industry experience in Web, Mobile and Infrastructure Penetration Testing. He is currently a security researcher at Infosec Institute Inc. He holds Offensive Security Certified Professional(OSCP) Certification. He blogs atwww.androidpentesting.com. Email: srini0x00@gmail.com

9 responses to “Android hacking and security, part 1: Exploiting and securing application components”

  1. Ss says:

    Hello. I have something to ask you. Is it possible to edit android app with java source and rebuild apkfile? Or i have to just edit .smali file in order to edit and rebuilt .apk file?

  2. Srinivas says:

    Hello Ss,

    Generally, We cannot recompile if you are using dex2jar like tool to get your java source. But, you can use the code to understand the logic.

    If you are using APKTOOL, We will have to edit the smali file and rebuild it if you want to modify the application. But, you have to sign it with your own key.


  3. Vishal says:

    Late to the party, but, I believe the better way to edit a Smali files in the application is:
    1. Write the attack in Java
    2. Compile it with some other Android application
    3. Decompile it with APK tool
    4. get the Smali code from it and add it to your application’s smali code
    5. Recompile, Sign it with APK tool and you can good to test the application
    Hint: Generally in Public void onCreate() method is a good place to inject code
    I know this is a long process, but this way you dont have to break your head understanding Smali code

  4. Tony says:

    Can’t find the “Android Hacking and Security, Part 1” testing apk in the file download list. May it be possible to share it? Thank you the good tutorials.

  5. RSenet says:


    This file : Android Hacking- Exploiting and Securing Android Application Components: Download Files. (go to article)

  6. abhinav says:

    Part from launching the activity what else can this lead to? I mean even if a malicious app is able to launch an activity of other app how can data be stolen?

  7. abhinav says:

    Okaay, and just before you can answer.

    I would like to thanks you for putting this very amazing tutorial online so that a lot of people can learn from it. I really really appreciate you for such a wonderfull effort.

  8. test says:

    you are executing the `am` command as root in the emulator. The root user has full permissions to everything,it can cause arbitrary activities to be launched. If you try this on a real (non-rooted) phone, it will not work because you cannot run commands as root ??? so what is impact of this vuln ??? as impact, exploit etc ???/

  9. Adnan Mehmood says:

    Guys i have 1 app, I just want to remove the Username & Passward authentication from it.
    Is it possible and anyone do it for me please.

Leave a Reply

Your email address will not be published.