Now that we have starting points for where we think we ought to begin reversing, let’s get started and then talk more about the “how” and “tips and tricks”.
In Exercise #2, we’re going to continue with where we left off in Exercise #1 You can find this sample in the VM at
~/samples/ThaiCamera.apk. The SHA256 digest of this sample is 55da412157e93153e419c3385ebcd5335bd0d0c3f77a75e2d2413dd128270be2. We are going to reverse engineer this application to determine if it is doing premium SMS fraud.
To be doing premium SMS fraud, the application must send a premium SMS message (premium phone numbers are usually shortcodes) without disclosure that includes the phone number the SMS is being sent to and the cost of the SMS message and user consent.
The goal of this exercise is to: Reverse engineer our 1st Android application (DEX code)! More specifically:
You are a malware analyst for Android applications. You are concerned that this sample maybe doing premium SMS fraud, meaning that it sends an SMS to a premium phone number without disclosure & user consent. In order to flag as malware, you need to determine if the Android application is:
jadx-guicommand in the terminal and open ThaiCamera.apk in the jadx GUI in the same way as in Exercise #1.
The two exercises up until this point have focused on reverse engineering an Android app in order to determine if it is malware. Now, let’s apply our reverse engineering skills to finding a vulnerability in an application. You can find the sample for this exercise in
~/samples/FotaProvider.apk. The SHA256 digest for the sample is 6fddd183bc832659cbea0e55d08ae72016fae25a4aa3eca8156f0a9a0db7f491.
The goal of this exercise is to apply our DEX reverse engineering skills to finding a vulnerability in an Android app. This example is a little more complex and will introduce us to reversing across different components of the application.
You are auditing a set of phones for security issues prior to allowing them onto your enterprise network. You are going through the apps that come pre-installed. For this pre-installed application, you are concerned that there may be a vulnerability that allows it to run arbitrary commands.
There is a vulnerability in that any application or component on the device can have an aribtrary command executed as the privileged system user through this application. The FotaProvider.apk sample exports the
WriteCommandReceiver broadcast receiver through the action
android.intent.action.AdupsFota.operReceiver. Any component on the device can send an intent with this action and with the String extra “cmd” and that “cmd” will be executed as the system user. On Android, the system UID is the most privileged UID behind root.
This vulnerability/backdoor was first identified by Kryptowire in 2016. They give a detail explanation of this command execution issue as well as other identified security issues in the Adups OTA apps in their 2017 BlackHat USA presentation, “All your SMS and Contacts Belong to Adups & Others” [slides] [video].
In this exercise we will once again try and identify whether an application has a vulnerability that permits arbitrary command execution, but this time it is done in a different way. This will introduce us to how to reverse engineer apps that are using Binder, an Android inter-process communication mechanism.
For this exercise, you will use the app at
~/samples/HonSystemService.apk in the VM. The SHA256 digest for the sample is 86a1ba436be2d1ee480e1d40418df3aa5f47571d154a8c41e74c439fbfb04b27.
The goal of this exercise is to understand how to reverse engineer applications that are using Binder, specifically to look for vulnerabilities.
Let’s use the same context as Exercise #3, but this time the solution will look different. This will show us another pattern and help us understand Binder.
If you’re interested in more resources on analyzing and reverse-engineering pre-installed Android applications, you can check out my Blackhat USA 2019 talk, “Securing the System: A Deep Dive into Reversing Android Pre-Installed Apps” [slides]. This example is covered in Case Study #1.