Hack an Android App: Finding Forensic Artifacts
- Getting Started
- Extracting Data From a Real Device
- Examining Installed Apps on a Device
- Extracting Data From a Package
- Extracting Data From the Emulator
- Examining SharedPreferences
- Examining Other Files
- Analyzing Databases
- Recovering Deleted Data
- Reverse Engineering
- Understanding Bytecode
- Using Reverse Engineering Tools
- Obfuscating Code
- Working With Locked Devices
- Rooting and Unlocking the Bootloader
- Bypassing the Lock Screen
- Where to Go From Here?
So you’ve just completed your app and you’re ready to release it. However, you’re storing some user credentials and some code you want to keep secret, and you’re not sure if your app is secure enough.
How can you check? It’s time to take a look from the outside to see what vulnerabilities are lurking, as you learn how to hack an Android app. So put on your forensic examiner’s hat!
The purpose of this tutorial is to help you become a security-conscious app developer. It’s also an introduction for anyone interested in pursuing the area of mobile forensics.
During the process, you’ll learn how to:
- Access an app’s private data.
- Analyze databases.
- Reverse engineer code.
Since dealing with a variety of devices is a tutorial in and of itself, you’ll use the Pixel XL API Q Emulator to start with the basics.
Download and unzip the materials for this tutorial using the Download Materials button at the top or bottom of this page. You’ll notice this tutorial only has a final project. That’s because the scenario is that you’ve finished your project and you’re now focused on extracting the data.
Open and run the starter project in Android Studio 3.3.0 or higher to see what you’ll work with.
You’ll use a sample app called Snitcher, which lets users send anonymous tips about crimes to law enforcement. OK, it doesn’t really send the information to law enforcement. But this kind of app gives you plenty of motivation for privacy.
You’ll see a simple sign-up screen. Once you enter a password and choose SIGN UP, you’ll need to enter that password when you launch the app in the future.
After that step, you’ll get a list of wrongdoings to report. Oh wait, all the reports are for animals! Well, who doesn’t want to protect a furry friend from harm?
Tap an entry in the list to proceed to the reporting screen:
Explore the project in Android Studio. In order to get the SQLite database code & logic out of the way, the project uses a library called Room to store the reports.
If you’d like to know more about SQLite and Room, see our Data Persistence With Room tutorial.
Extracting Data From a Real Device
You’ll start off with an example walk-through for a real device. This will give you a sense of the process and the complications you’ll encounter along the way.
You won’t be able to follow along in this section unless you have a rooted device, so read through it instead of trying it on your own device. That is, unless you fancy rooting devices for fun. :]
Examining Installed Apps on a Device
One of the simplest things to do with ADB is to list the apps installed on a device.
adb shell #1 pm list packages -f #2 exit
- The first command starts the adb shell, letting you run commands on the device.
- The second line lists the installed packages on the device.
You should see a long list of installed packages on the device. If you’ve installed the Snitcher app on your device, you should see a similar line in your output:
Here, com.raywenderlich.android.snitcher is the Snitcher app’s package name.
Extracting Data From a Package
Once you’ve found the package you’re looking for (in this case com.raywenderlich.android.snitcher), try to see if you can run the app over adb to extract data with the correct permissions.
It’s easy to retrieve data from apps that allow external install locations or that save data to public areas, but in most cases, you’ll need to get at the data that’s in the private storage area.
On some versions, you can access the private storage of debuggable versions of the app:
adb shell adb exec-out run-as com.raywenderlich.android.snitcher cat databases/reports-db > reports-db
Here, you’re using run-as to execute commands with the same permissions as the app.
If that doesn’t work, you can also try to change file permissions or use the adb pull command:
adb shell run-as com.raywenderlich.android.snitcher #1 chmod 666 databases/reports-db #2 exit cp /data/data/com.raywenderlich.android.snitcher/databases/reports-db /sdcard/ #3 run-as com.raywenderlich.android.snitcher chmod 600 databases/reports-db #4 adb pull /sdcard/reports-db . #5
Here’s what’s going on inside this code:
- Tells adb to execute commands with the same app permissions.
- Executes chmod, which allows you to change file permissions. The permission 666 means all users can read and write to the file.
- Copies a reports-db file to sdcard, which is a public area of the device.
- Executes chmod again to reset the file permissions. Permission 600 means only the owner (the app) can read and write to the file.
- Now that you’ve put the file in a public area, this copies the file from the device to your working directory of your computer.
And just like that, you’ve got a copy of an app’s local database on your computer.
But many devices disable these features for security reasons. If that’s the case, the next thing you’d look to is a device backup. Device backups can include the APKs as well as the private data for each app:
adb backup -apk -shared com.raywenderlich.android.snitcher
Here, you use the backup command to write an archive of the app and its data to the working directory of your computer. The default filename is backup.adb.
Feel free to experiment and do research if you’re comfortable doing so on a test device. But for the sake of time and safety, this tutorial will use the Android Emulator to skip to the next step.