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.
Extracting Data From the Emulator
Now that you have access to the file system of a device, it’s time to extract the data. Build and run the app in the emulator, then go ahead and make a report.
On the report screen, fill in the details and tap the SEND REPORT button. In Android Studio, select View ▸ Tool Windows ▸ Device File Explorer then choose Emulator Pixel_XL_API_Q in the drop-down:
Here are some locations where Android keeps important data:
- All apps store user data in the /data/data directory.
- You can find a list of apps on the device at /data/system/packages.list.
- You can see when you last used an app at /data/system/package-usage.list.
- The OS stores Wi-Fi connection information, such as a list of access points, at /data/misc/wifi/wpa_supplicant.conf.
WhatsApp stores their messages in /databases/msgstore.db. Forensic companies take advantage of that to backup the database and recover messages.
Knowing where apps store information also makes it easy to look for artifacts or to undelete data. In the case of WhatsApp, forensic examiners have been able to recover deleted messages that their users thought were gone for good.
To try your hand at saving Snitcher’s data to your device, navigate to /data/data. You’ll see a list of all the packages:
Find the com.raywenderlich.android.snitcher entry:
Right click on it and choose Save As…:
Save the file to a location on your computer and open it to view its contents. You’ll see important directories such as:
Open the MyPrefs.xml file inside the shared_prefs folder. You’ll notice at least one entry with a timestamp. Score!
Timestamps are very important to any kind of forensic or criminal investigation, since they give you evidence of the user doing something at a particular time!
Examining Other Files
Now, select the users.dat file in the files directory.
Android serializes objects in a specific record format, but you can still search for strings using the strings utility, which is already included in Mac and Linux.
In the terminal, type strings and a space followed by the path to the users.dat file. After you press space, you can drag the users.dat file into the terminal window to populate the path. Press enter and you’ll get an output of items.
If you are using Windows, you can download the strings utility.
Upon looking at the output, you’ll see extrat followed by nameq and passwordq. You can use that order to deduce that you’re looking at the extra info about each account, followed by a login name and password!
There are a few other tools that you can use to help extract data:
- A hex and text viewer comes in handy to search unknown file types for information and patterns.
- A live data imaging tool that may be helpful is dd. You’ll find it at /system/bin.
- To extract the current memory state of the device, check out LiME.
In the movies, forensic investigators show up to crime scenes drinking martinis and leaping from trains while fighting villains. In reality, forensic investigators spend much of their time peering into a text viewer. You could still try leaping from trains while peering into a text viewer. :]
Next, navigate to the databases folder. It looks like there are some files in there; here’s how to examine them.
Now that you’ve downloaded the database files, head over to the sqlitebrowser homepage.
Click the download button at the top of the page. Choose your OS, download the file and install the program. Launch DB Browser and choose the Open Database button at the top:
In the folder you downloaded via the Device File Explorer, choose the reports-db file from the databases directory.
If it doesn’t show up in the list, choose All files from the Filter option at the bottom. If there’s no reports-db file, look for the reports-master-db file:
Assuming everything worked, you should see the database tables show up in the Database Structure tab. Click the Browse Data tab:
Now click the Table selector right under the tab and choose reports:
You’ll see all the secret reports!
This is an example of why you should never store the user’s sensitive information in plaintext. A much better solution is to encrypt the data before you store it.
Recovering Deleted Data
The data you’ve recovered so far exists inside a saved SQLite block. For SQLite, there are unallocated blocks and free blocks. When you delete something from the database, SQLite doesn’t overwrite the block immediately. Instead, it simply marks the block as free. To read that data block, you’d use a hex viewer that also displays ASCII to search for keywords that may still be present.
Experts call the process of finding and extracting data when you don’t have access to the file structure file carving. Sometimes, searching for a particular string of content helps. Other times, you’d look for the header of a known file format.
For example, say you’re searching deleted data for images. In the JPEG format, the first two bytes and last two bytes are always FF D8 and FF D9. So searching for those headers can help you identify the images.
Here are a few more details about recovering deleted data:
- There’s some valuable information about SQLite file carving here.
- Scalpel is an open-sourced data carving tool.
- DiskDigger is an automated undelete tool available for Android. It scans the device for photos, documents, music and videos.
- An example of a commercial tool for viewing and undeleting SQLite records is sqliteviewer.
So now you’ve looked at all the user data inside the app, but the investigation doesn’t stop there. You can get a lot of information by analyzing the app itself. This includes the code and files Android Studio bundles with the APK.
When you build your app, Android Studio produces an APK file. This is like a zip file that has a structure of Java’s jar archives. Inside the archive are resources along with a DEX file. DEX stands for Dalvik Executable.
When Android Studio compiles your app, it puts the code into that DEX file and names it classes.dex. It contains bytecode, an intermediary set of instructions that a Java Virtual Machine (JVM) runs or that ART (the Android Runtime) later converts to native code. So what are JVM and ART?
Apps run on a Java Virtual Machine. Traditionally on Android, the JVM was Dalvik. In recent years, Android has replaced Dalvik with ART for performance reasons. ART converts the DEX into native code by running the Dex2Oat tool to create a native ELF binary.
So now you’re thinking, because this is a Kotlin app, reverse engineering it must be complex.
But the good news is that like Java, Kotlin is a JVM language. While Kotlin has its own syntax, the kotlinc compiler transforms the code into a DEX file that contains Java bytecode. Because kotlinc compiles Kotlin to the same bytecode as Java, most of the reverse engineering tools are the same as for apps built in Java!
So now you’re thinking — enough theory already. Show me an example!
Open the ReportDetailActivity file in Android Studio. Find
sendReportPressed() at the bottom.
Here’s what’s going on inside the method:
- You add the report to the local database.
- You prepare a network request URL to send the report. APIs usually have a client ID and private token so that only authorized apps can make the network call. Because Snitcher is an example, the network call never completes.
- You inform the user that the process is complete.
Go to the top of the file and note that you’ve added the authorization details inside the companion object:
You might think this is fine, because Android Studio compiles the code and the end user never sees it. However, any forensic investigators can easily find and use these authorization details to steal data. You can even use Android studio to find it!
Android Studio includes a tool called the APK Analyzer, which lets you inspect your finalized app. It presents a view with a breakdown of what’s inside your bundle. It also allows you to view the bytecode of your app.
Launch the analyzer by selecting Build ▸ Analyze APK to open a dialog for your filesystem. If necessary, navigate to the debug folder snitcher-final/app/build/outputs/apk/debug. Select the app-debug.apk file and click OK to open the APK Analyzer:
In the APK Analyzer, select the classes.dex file. Navigate to com ▸ raywenderlich ▸ android ▸ snitcher:
Right-click on ReportDetailActivity and choose Show Bytecode:
You’ll see the
#static fields section:
Notice that the secret token is clearly displayed! This allows someone to impersonate you making the network API call.
Attackers also reverse engineer apps in hopes of patching or hooking security checks out of the code.
A good example is when a feature is only available with a paid subscription or after a user achieves a level in a game. By reverse engineering the app, the hacker can find ways to access those levels without having to go through the security checks.
Sometimes, hackers reverse engineer apps to steal intellectual property or to clone the app. Or they might want to abuse a private API.
This is why you should never store sensitive API keys, tokens or passwords anywhere in the APK. Instead, have those items sent to the app encrypted upon authentication.
Using Reverse Engineering Tools
You’ve just reverse engineered code, and it was easy to do because you have the original project open in Android Studio. But this is not the only way to view the bytecode.
As long as you’re able to get ahold of an APK, whether by using the methods you previously learned or by downloading an APK from a site like APKMirror, you can reverse engineer the code without having the Android Studio project.
smali/baksmali is a set of tools to transform bytecode into another intermediate, but more readable, language. From there, you can convert the code back into Java.
There are also many other tools you can use:
- Android Asset Packaging Tools can dump the Android Manifest file.
- You can use AXMLPrinter2 to parse Android binary XML formats.
- Use Dex2Jar to convert a DEX file to a standard Java CLASS file.
- You can get all the class names and most source code by opening a jar folder in JD-GUI.
- Dextra supports ART and OAT.
- Jadx lets you browse decompiled DEX code. It also decompiles most of the entire project.
- JAD will convert Java Class files back to source files.
As you can see, it’s relatively easy for anyone to do this. That’s why it’s also a good idea to rename sensitive methods, such as
setUserAuthenticated(), with something more innocent-sounding.
Developers use obfuscation to hide or obscure proprietary logic or secret algorithms. Sometimes, developers apply manual obfuscation like string splitting, dummy code, disguising the names of methods or using reflection to muddy the app flow.
Check out the Getting Started With ProGuard tutorial to learn how to obfuscate your code.
Working With Locked Devices
So you’ve learned how to extract data from an app and picked up some tips on how to secure it. From a forensics point of view, these skills are useless when the user has locked a device with a passcode. To gain access, you’ll need to circumvent the security.
Breaking into devices is beyond the scope of the tutorial, but here’s a brief summary:
A very important goal in the field of forensics is to prevent tampering of evidence. Tampered evidence is inadmissible in court. To avoid this, the best practice is to change the device as little as possible. You should copy the data as soon as possible and and work with it away from the original device.
Preserving the current state of the device is also important. For example, a device is a lot harder to get into once the battery drains and the device powers off.
There is a trade-off between acquiring access and altering part of the device that secures it. Even so, almost all solutions for obtaining access to a locked device involve rooting it.
Rooting and Unlocking the Bootloader
Rooting involves gaining access to the root account of the device to bypass its restrictions.
These tools don’t work if the manufacturer has locked the boot loader. A locked boot loader prevents anyone from modifying the firmware.
Usually, the manufacturer signs the image with a private key. That way, you can’t flash unsigned code onto the device. There are OEM bootloader unlock commands, but they perform a wipe of the device.
To perform a root with a locked bootloader, you’ll need to exploit a security vulnerability in the OS. This is also true for iOS, where most of the jailbreaks stem from a known exploit.
You can often find help with these types of things at XDA-Developers.
Some previous examples of Android vulnerabilities are:
For an up-to-date list of funnily-named Android vulnerabilities, see Android-Exploits.
Bypassing the Lock Screen
Another way to hack an Android device is to bypass the lock screen. Users often use a pattern, pin or a Smart Lock such as a trusted face to secure their devices.
- Android stores pattern locks at /data/system/gesture.key.
- The OS hashes pin and passwords at /data/system/password.key.
- Android salts those hashes and stores them at /data/system/locksettings.db.
While you don’t want to alter evidence, on some devices you can bypass the lock screen by deleting the files. You can also experiment with LiME to extract passwords and keys from memory.
Where to Go From Here?
Congratulations! You’ve scratched the surface of what it’s like to hack an Android app using forensic analysis. :]
Code protection tools like DexGuard offer obfuscation and encrypt the classes and strings as well as assets and resource files. DexGuard also provides app integrity checking which is important for keeping malicious users out of your app.
Reverse engineers also look at the data an app sends and receives over the network to understand how the app works. To learn about how that works and how to secure that data, see the Securing Network Data tutorial.
For a deeper dive into advanced forensic techniques:
- Read about JTAG and Chip-off methods.
- See the open source digital forensics platform, Autopsy.
- Check out Santoku Linux‘s mobile and malware forensics information.
If you’re interested in professional reverse engineering, some popular commercial products are:
- IDA Pro: You can disassemble and debug Dalvik code since IDA Pro v6.1. IDA works well because of its support for scripting and because it has a graph view which unwinds the flow of the app. There are also lots of scripts people write to assist in unwinding obfuscated code.
- JEB: JEB can understand ARM and ELF formats. It has a powerful UI for both Dalvik and native code.
Last but not least, check out Drozer. It allows you to assume the role of an Android app and interact with other apps. One of the modules in Drozer, app.package.manifest, will parse the manifest file and display it on-screen.
If you have any questions, feel free to ask in the discussion below.