All About HackingBlackhat Hacking ToolsFree CoursesHacking

Android hacking and security, part 3: Exploiting broadcast receivers

In this article we will learn about Android hacking and security.

What is Android hacking and security?

In the first two articles, we discussed attacks related to Activity Components, leaking content providers and how to secure them. In this article, we will cover attacks on broadcast receivers.

What are transceivers?

The broadcast receiver is another important part of the Android system. Transceivers are registered for specific events. When the event occurs, the receiver is invoked and performs tasks such as displaying the message to the user. What we can do with broadcast receivers is up to the creativity of the developer because there are a lot of things that can be done with them.

Security risks

To understand the security risks associated with broadcast receivers, we should know how events are broadcast. There are two types of events.

System events

An application can be registered to receive broadcasts that occur due to system events such as BOOT COMPLETE, SMS RECEIVED, BATTERY LOW, etc. When an application is registered for the SMS RECEIVED event, its receiver will be invoked every time a new SMS is received.

Own broadcasting

In addition to system-generated events, the application can also generate its own broadcast intents, for which we can register a receiver.

Now let’s ask ourselves some questions.

  • When our app broadcasts a broadcast intent, is it only received by the intended app or can all apps receive it?
  • When we register the receiver, are we only receiving broadcasts from legitimate sources, or can any other malicious application spoof those broadcasts?

As long as the developer doesn’t enforce control over who can and can’t broadcast, the answer is of course YES. If the receiver receives broadcasts from untrusted sources, it can seriously compromise our application.

To demonstrate how such scenarios can be used, I developed a simple application.

Please fill out the form below to download the APK file and source code.

Prerequisites for performing the steps

  • A computer with the Android SDK installed
  • Two emulators (in my case emulator-5554 is where the vulnerable app is installed; emulator-5556 is to receive SMS from the vulnerable app).
  • Test the functionality of the application
  • After downloading the test app, install it in the emulator to test and use it.

It can be installed using adb using the following command:

[c]adb install .apk[/c]

When we run the application it will appear as shown in the image below. We need to register a particular mobile number using registration activity as shown in the image. Once, after clicking the send button, a custom broadcast will be sent and we will receive a confirmation SMS to the registered number (emulator-5556 in my case).

The idea is to send fake broadcast intents and see if the application receives them. If so, we will use the app to send SMS to some random mobile numbers using fake broadcast.

Topics Involved

  • Understanding the functionality of the application
  • Attacking vulnerable broadcast receivers
  • Application security

Understanding the functionality of the application

The broadcast receiver “MyBroadCastReceiver” is registered in the AndroidManifest.xml file.

Transceivers are generally registered in the following format. The code seems insecure because the receiver is exported.

The following piece of code takes the mobile number from the broadcast and sends a confirmation SMS to the registered number.

In the next section, we will try to exploit the above functionality by sending broadcasts from untrusted sources.

Attacking vulnerable broadcast receivers

Now let’s try sending some fake broadcasts to the above receiver. This can be done in several ways.

  • Using the am tool available in adb
  • Using a malicious application to query
  • Using the Mercury Framework
  • Using adb

. Get an adb shell on your device and type the following command to send a fake broadcast.

am broadcast -a MyBroadcast -n com.isi.vul_broadcastreceiver/.MyBroadcastReceiver


The above command sends a broadcast but does not contain any mobile number. We can pass the mobile number as a string using the –es option available with the am utility. Now the above command becomes:

am broadcast -a MyBroadcast -n com.isi.vul_broadcastreceiver/.MyBroadCastReceiver –es number 5556.

The same is shown in the image below.

Now the broadcast event is sent in the background, and since the application does not validate the input source, the SMS will be sent to the emulator-5556 without user intervention.

Using a malicious application to query

We can also write a malicious application that will send broadcasts and exploit the functionality of the vulnerable application. The best part is that the malicious application does not need the SEND_SMS permission because it uses the permissions registered by the vulnerable application.

Using the Mercury framework

The entire process can be done even more efficiently and simply using the Mercury framework.

Application security

Setting the value of the android:exported attribute to false
In our app’s AndroidManifest.xml file, we should add the following attribute to the receiver to make it secure.

Restrict access using custom permissions

We can also impose permission-based restrictions by defining custom permissions for each recipient. This is useful if a developer wants to restrict access to their application’s components to applications that have permissions.

That’s why we need to specify “android.permission.RECEIVE_SMS” permission in AndroidManifest.xml if any app wants to listen to Receive SMS events using “android.provider.Telephony.SMS_RECEIVED” action

Final words

On Android, broadcast receivers provide great functionality for developing creative apps. However, if proper security controls are not enforced, this can lead to serious attacks. So it is always a good idea to test all the components of the application during the pentest.

Leave a Reply

Your email address will not be published. Required fields are marked *