Hack an Android App: Finding Forensic Artifacts

Understanding Bytecode

Open the ReportDetailActivity file in Android Studio. Find sendReportPressed() at the bottom.

Here’s what’s going on inside the method:

1. You add the report to the local database.
2. 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.
3. 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.

ApkTool will reverse engineer the entire Android package back to a workable form, including all resources and original source code. There are even online versions that will do this.

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.

Obfuscating Code

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.

There are many tools to root a device, such as OneClickRoot, KingoRoot and SuperUserDownload.

Rooting usually involves flashing a partition on the device, such as a custom recovery image. Some examples are twrp.me or ClockworkMod Recovery.

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:

• g2root-kmod
• mempodroid
• dirtycow
• gingerbreak

For an up-to-date list of funnily-named Android vulnerabilities, see Android-Exploits.