Fun with Apktool

Or a potential headache

All blog posts to date

Introduction	Acquisition	Analysis
Introduction	Imaging an Android Device	Examining the image
Picking a Toolkit	Live imaging an Android device	Some hidden artifacts in a physical image
	Why not load ClockworkMod or TWRP to image a device?	Using Autopsy to examine an Android image
	Identifying your Userdata Partition	Some artifacts in the /data/system/ directory
	Some non-root methods to learn about a device	Viewing SQLite Databases
	A quick note on imaging newer Android devices	Facebook for Android Artifacts
	Using Windows to Live Image an Android device	Interpreting data from apps
	Obtaining all files in the data partition without a physical image	Waze for Android forensics
		Magnet Forensics App Simulator
App Reversing	Other Topics
Reverse Engineering an Android App File	The differences between a physical image and a logical extraction
Fun with Apktool	Dirty cow
Deep dive into an app	Imaging and examining an Android car stereo
	Unpacking boot and recovery kernels
	MTPwn

Introduction
Opening night, my wife and I saw the movie "Logan" on the big screen.  I have to say, the movie was incredibly violent and it took a while for the shock to wear off.  But the shock has since worn off and I've had plenty of time to think about it, and I've come to a singular conclusion:  the film was outstanding.

The film focused on strong characters that I have grown to love.  Hugh Jackman first came on to the scene as Logan and Patrick Stewart first brought such elegance to the role of Charles Xavier nearly 20 years ago.  I have grown to love these characters, seeing all of the movies they are in, even that terrible embarrassment X-Men Origins: Wolverine.  "Logan" is amazingly emotional, dealing with the difficult topic of time; both Logan and Charles know the last tick of their clocks cannot be far away.  Charles, the man with the most powerful mind ever known, is losing his mind; Logan, with the unbeatable body, is losing his body.  They could simply cower away and live out the remainder of their lives in reclusion, but events happen which lead these two men to endure great sacrifice in order to help a girl they do not know in a desperate situation.

So you're probably wondering right now, why on earth am I talking about an awesome character-driven action film on a forensics blog?  Well, here goes.  In the film, Logan (spoiler alert) hacks a lot of things and people to pieces, and (spoiler alert) the X-Men franchise sometimes involves cloning.  In this post, we will be hacking around with apps and cloning apps.

OK, OK, OK, I'll admit, that's a pretty weak tie-in.  Truthfully, I just loved the film and wanted to talk about it.  So here goes.

Apktool
Android apps are packaged as apk files.  These files are essentially zip files.  For a quick guide on Android app files, check out this previous post I wrote on reverse engineering apps.  

Apktool is a free, open source tool for decompiling and rebuilding apps.  Here's the main page.  The tool reverses the app's code to smali, it extracts embedded images and XML files, and it properly decodes the Android manifest.  It is an excellent tool for reverse engineering.

Now what is smali? Smali is reverse-engineered Android app code.  Android apps are written in Java.  The Java code is compiled into machine-readable code.  The guide I wrote on decompiling Android apps involves converting the app into a Java jar and then decompiling the jar.  This is a fine way to do it but is honestly not the most "accurate" way.  The most accurate way is to decompile the app code itself, and that app code is decompiled into smali, which is almost like assembly code.  Here is an excellent writeup on smali. 

Now understanding smali is a pain.  I'm not the best at it, which is why I decompile apps the way I do by converting the app to a Java jar and decompiling the jar.  If you want to learn some smali, here is a blog with some excellent posts that can serve as great starting point.

Apktool allows you do decompile an app for reverse engineering.  There also is now a tool which allows you to use the decompiled code for debugging an app.  The tool is called SmalIdea and it acts as a plugin for the Android Studio development environment.  I will not go into detail now on SmalIdea - that would be a detailed post in and of itself.

Apktool also allows you to rebuild an app from the decompiled output.  You can decompile the app, make some edits as you see fit, and repackage it.  Legal disclaimer:  you can reverse engineer an app for your own personal interests or understandings, but absolutely do not repackage an app and attempt to profit from it.  Do not distribute the repackaged app and absolutely do not sell it.  If you sell somebody else's intellectual property, that is intellectual theft.

Forensics
So where does the topic of forensics come in play with Apktool?  Any tool that can be used for reverse engineering is useful for forensics.  So let's do a quick decompile.

In the film Logan, the main characters go on a road trip.  Anybody who has ever been on a long road trip knows highway rest areas can be a lifesaver.  So I downloaded a rest stop locater and reversed it.

I pulled the app off my Android device and renamed it on my local computer "restarea.apk".  Then I downloaded the newest version of apktool and renamed it "apktool.jar".  So here's the line to decompile:

java -jar apktool.jar d restarea.apk

Apktool is a jar so it must be run in Java.  The "d" means "decompile", and then you give it an app to decompile, or in this case, restarea.apk.  Once the tool runs, there is a directory called "restarea".

Within the restarea directory, there are three specific items of note:

• AndroidManifest.xml: this is the Android manifest, describing the app, permissions, screens, and included files.  Here is the documentation for the manifest https://developer.android.com/guide/topics/manifest/manifest-intro.html
• res: this is a directory containing images and text files which are part of the app.  The app icon is in here, any image buttons are in here, and many hard-coded text values are in here.
• smali: this is a directory containing all the decompiled smali code.

As an examiner, all of these can be useful.  Knowing the package name from AndroidManifest.xml will help you find data associated with the app.  Knowing text values will help you understand the behavior of the app.  And an understanding of the smali code will allow you to know the implementation of the app.
All useful.

Cloning an app
Apktool can allow you to edit and repackage an app.  Let's use that same rest area locater app.  First, let's change the package name around.

Here is the beginning of the AndroidManifest.xml file:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.omecha.restarea">

The package name is com.omecha.restarea.  I edited that around to customize a rest stop finder for Logan.  Now the beginning of the manifest is as follows:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="claws.omecha.restarea">  

So now the app's package name is claws.omecha.restarea.  This will be notable later in the demonstration.

Next, I changed around the app's name as it appears in the loader.  In the file res/values/strings.xml in the decompiled directory, there is an entry app_name, which is as follows:

<string name="app_name">Rest Area Locator</string> 

I edited that line to the following:

<string name="app_name">Claws-Safe Rest Area Locator</string> 

After all, if a rest area is not safe for someone with claws, Logan should skip the rest area, right?

If I wanted to, I could have changed around the app's icon.  All the image files are in the res/drawable directories.  And if I really wanted to be adventurous, I could have gone into the smali directory and edited around the decompiled smali code to change functionality, but I'll admit I'm just not good enough at smali to do anything of significance.

Now, it's time to recompile the app.  Navigate back to the directory with apktool.jar and execute the following:

java -jar apktool.jar b restarea

The "b" stands for "build", and "restarea" is the decompiled and edited output.  Once the build is done, there is a directory called dist with a file restarea.apk.  That is the built apk.

It cannot be installed on an Android device just yet.  It needs a new app signature.  Just follow the instructions on this Stack Overflow post and the app has a new self-signed signature that allows you to install the app on your own device.

Then I installed the app and, well, check out these screenshots:

and

What we've got now is the original app and a cloned, or maybe I should say mutated, version of the app.

If you navigate to the device's /data/data/ directory, you see app data.  And in that directory, you see entires for both com.omecha.restarea and claws.omecha.restarea.  These directories store data associated with the apps.  More on the topic here.  Each directory has a databases directory with a database of user data, each directory has a shared_prefs directory with xml files, etc.  And if you create some user data in the com.omecha.restarea version, that data will not show up in the claws.omecha.restarea because these are two different apps.

And again I have to say, feel free to experiment around as I have shown here simply for personal study.  Absolutely do not steal somebody else's work and attempt to pass it off as your own.  That is dishonest and dishonorable.  And I should not have to say this but I will.  Do not make a modification like this and then attempt to make money off of it.  That is illegal.

What's the big deal?
So why does cloning an app matter as a forensic investigator?  That's the big question.  And here's the answer.

Let's say you are examining an Android device.  You run some automated tools at the device image and you find nothing of any real interest.  Those automated tools may look for data within specific apps.  For example, as I noted in my post on Facebook app forensics, the app has two different package names, com.facebook.katana and com.facebook.orca; the first is the main Facebook app, the second is the Messenger app.

Now let's say the user is an advanced user who has the knowledge to clone and mutate an app, or the user knows such an advanced user.  Let's say the Facebook app has been modified and cloned and is now renamed a different package name, like mutated.facebook.  That automated tool that is looking for Facebook data in com.facebook.katana or com.facebook.orca could go right past this mutated app and miss out on conversations.  Mutating an app is effectively a data hiding technique.

How do you find such data?  Just examine data in all third party apps.  Examine the databases and if you find something of investigative value, such as conversation messages or call logs, flag that app as interesting.  Examine the data closely.  You might have found an app you've never heard of, or you might have found a cloned version of a real app.


Summary

• Apktool is an excellent tool for reverse engineering apps in order to understand functionality.  Learn some smali and there is no limit to your understanding of an app's mechanisms
• You can use Apktool to mutate an app, changing package names, images, and even functionality
• Mutating an app can be an effective data hiding technique.  Over-reliance on automated tools can lead to missing out on important data

Questions, comments, suggestions, or experiences?  Seen Logan?  Leave a comment below, or send me an email.