Pages

Tuesday, May 30, 2017

A quick note on imaging newer Android devices


Actually a quick note


All blog posts to date
I was on the phone with a good friend of mine earlier this week.  He called me long-winded.  According to my wife, my family, my friends, and my coworkers, the statement was accurate.  So I'll make this one not so long-winded.

In a previous post, I demonstrated how to make a physical image of a device.  So let's say you have a rooted newer device, like Android 7.0 or newer, and you follow that guide and image /dev/block/mmcblk0.  You open the image in FTK Imager or any other viewer of choice, and it all looks good until you get to the userdata partition.  You get the dreaded "cannot read filesystem" or "unknown file system" or other such error.  You get ticked off because you just spent an hour plus imaging the device, and now it looks like the most important partition by a long shot imaged wrong.  So you go back and do it again and receive the same results.  Now you've wasted two plus hours.  I'm here to save you from wasting further hours.


File by file encryption
By default, many newer builds of Android include file-based encryption on the userdata partition.  The long and short of it is the entire partition is not encrypted, but each file is.  So if you capture the partition with no attempt to decrypt or otherwise circumvent the encryption, you will not be able to view the data.

Now users can set up more complicated encryption.  If that's the case, I don't think the method below is going to work.  I'm talking about devices where the user just uses a simple pin or fingerprint lock, not a fully-encrypted device.
So when you image /dev/block/mmcblk0, you image the entire internal storage, beginning to end.  The problem here is imaging that entire internal storage grabs an encrypted version of userdata.  So we need to image a decrypted version.

Check out my previous post on identifying your userdata partition.  In the post, I explain how to use the "mount" command to find the block mounted at /data.  That block is your userdata, and if you image that, you get just the userdata partition.

As it works out, that same method can bypass the Android 7.0 file based encryption (again, so long as the device is not fully encrypted).

So if you have such a device, adb shell into it and type the following command:

mount
You will see a list of all mounted partitions.  One of them might look something like this (mind the edits for making it a bit generic) ...

/dev/block/platform/something/dm-0 /data ext4 rw,bunch of other mount commands

Point is, find the one mounted at /data.  Image just that one.  See if you get a cleaner version of the userdata partition.

I fully expect that if you were to do a chip-off forensic imaging process of a newer device, you would get the same garbled output as you would if you imaged /dev/block/mmcblk0.  So if you get newer devices, chip-off probably won't do you any good.  Can anyone out there confirm?  Once you've got the chip removed, it is difficult if not impossible to put it back in place.  Chip-off is a rather one-way method.

Note: I can do a screenshot demo of the above, or maybe even a video demo.   However, I currently do not have an Android 7.0 capable "hack-around" phone or tablet.  I had been using a Nexus 7 (2013) and a Nexus 5 as hack devices.  The Nexus 7 is no longer supported on new Android versions, and the Nexus 5 has ... seen better days.  Those were pretty cheaply manufactured phones and 3.5 years of daily use did little good.  So if you'd like to see some demos, consider clicking on the PayPal link on the right side and making a small donation to help offset the cost of a newer hack-around device.

See?  Not so long winded, huh?

Summary
  • Many newer devices likely include file-based encryption, resulting in garbled user data if you image the entire device
  • Use the mount command to find the right partition and you should be in good shape
  • Don't jump straight to chip-off.  You might end any real chance at imaging the userdata partition
Questions, comments, suggestions, or experiences?  Surprised at my brevity?  Leave a comment below, or send me an email.

Wednesday, March 22, 2017

Fun with Apktool


Or a potential headache


All blog posts to date
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.


https://i0.wp.com/media2.slashfilm.com/slashfilm/wp/wp-content/images/logan-imax-poster.jpg


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.

Saturday, February 25, 2017

Waze for Android forensics


Lots of Location Information


All blog posts to date
Many years ago, I spent an evening at my grandparents' house before taking off for a day-long there-and-back trip across state lines to my soon-to-be university.  The trip was just before I started grad school at the university and I was interviewing for a graduate assistantship, which I earned.  I had been to the campus a few times, but I can't say I was overly familiar with the turf and I had never driven there from my grandparents' house.  So my grandfather gave me an old US atlas of his.  An old Rand McNally US highway atlas that Wal-Mart published every year.  Remember those?  They would publish a new highway atlas each and every year in the off-chance that main street might get up and move between this year and next.

Anyways, I used that atlas to navigate.  I'm a natural with maps - I grew up backpacking and therefore relying upon trail maps - so I found my way there and back.  And of course, this was towards the beginning of the smartphone era, so I did not have a digital device for navigation.  Paper was just fine.

I kept that atlas around for other trips.  One year, a friend of mine and I drove from the Midwest down to Alabama and back for a football game.  It was an awesome trip, including a stop at the Louisville Slugger factory and museum and another at the Space and Rocket Center in Huntsville.  That friend of mine also is old-school like me, not needing an LCD screen to get from point A to point B.  I kept that same old atlas around for other road trips, for football games, skiing, and so forth.

Where is that old atlas now?  It's been cut up and turned into a Christmas present.  No, I'm not kidding.  My dad is a marathon runner, aiming to run a marathon in all 50 states, so my wife and I made a little scrapbook for him to document each run, photos and such, against a map of each state.  And why was I willing to sacrifice that atlas?  Because, you know, who uses an atlas anymore?

Waze
There are several maps and navigation apps out there for Android.  I find Waze to be such a novel app in that it is a combination of navigation and social networking.  Meaning app users report road incidents so other users can be aware of accidents, construction, roadkill, traffic jams, and other slowdowns.  Waze effectively crowdsources traffic information.

You can use Waze as a GPS navigation app, for communicating slowdowns, for sharing your location and trips with friends, and I've found it has an incredibly loyal following.  Waze-ers seem to never flip back to Google maps.  Point is, as a this app gives you, the forensic examiner, locations, times, and a social network.  That is gold for an investigation if the target uses Waze.

So I populated a phone with Waze, imaged it, and disected the data.  There's a lot of geo-location there, and it is quite easy to comprehend.  So ... here we go.

user.db
The package name for the app is com.waze.  So once you've got your image, check out the directory com.waze within the data app of the userdata partition.

The main file to check out is user.db - in that directory com.waze, not in any subdirectory.  The database has a bunch of tables.  I will highlight the ones of interest.  This is a SQLite database.  I did a post a while back on viewing SQLite databases.

First, the table PLACES.  This one stores places the user has searched for and selected as a navigation destination.  Here's the columns of interest:
  • name: Name of the destination, such as "Home", or "Safeway"
  • street:  Street address of the destination
  • city:  City of the destination
  • state:  State of the destination
  • country:  Country of the destination
  • house:  Apartment or other unit number
  • longitude:  Longitude, multiplied by 1,000,000.  Add a decimal accordingly
  • latitude:  Latitude, also multiplied by 1,000,000
  • created_time: Epoch time it was searched.
I was going to screencap the database, but it would not be worth much after I would black out all the personal sensitive data, which is all of it.  I'm not about to let the Internet know where I live, where I work, and when I go to where!

This is all plain text.  All you need to do is an epoch time conversion and you've got a listing of when each destination was searched for, exactly where on the planet it is, and the street address.  This table alone can be a goldmine for an examiner.

Next the table PEOPLE.  With Waze, you can connect people via Facebook, and then you can share your location and coordinate travel.  Here's the columns of interest:
  • waze_id: The Waze ID of the user in order to link to the right Waze user.  More on the device's Waze ID later.
  • facebook_id: Facebook's ID of the contact in order to link to the right person.
  • first_name: First name of the contact
  • last_name: Last name of the contact
  • create_time: Epoch time the contact was added
  • modified_time: Epoch time the contact was modified last
So far, Waze has provided your location search history and your contact history.

Next, the table SHARED_PLACES.  This table includes locations the user has shared, which may mean the location is of significance.  Really there are only a few columns of interest, so check out the created time, the place name, and the share time.  Pretty self explanatory.

There are some other interesting tables in the database.  Feel free to browse around and see if anything else is of interest.

XML Files 
Next up, check out the directory shared_prefs.  This includes some xml files.  I'll highlight two of interest.

First, the file com.waze.appuid.xml .  I previously mentioned the Waze ID.  Here it is.  Linking the Waze ID of one device in this XML file to another device in the user.db, table PEOPLE, indicates these two users know each other.
 

Second, com.waze.parked.xml.  Here's what mine looks like:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <string name="dest_lon">[REDACTED]</string>
    <string name="dest_name">
[REDACTED]</string>
    <string name="dest_venueId">
[REDACTED]</string>
    <string name="dest_lat">
[REDACTED]</string>
</map>


When you finish a Waze trip, which should naturally end with parking the car, this file is created.  It stores where the car is and when the trip ended.  Nifty, huh?

Log
Finally, go back up a directory and check out the file waze_log.txt.  This is a massive log file with some decent goodies.
There are geo-coordinates which represent different stops along the way on a trip.  I also found information about routes from point A to point B.  Of interest, there is a list of each route of highlights along the way - anything from airports to groceries to gas stations.  This may be of interest.  There are all kinds of businesses listed that are near the route - which may also be of interest.
This was a rather simple app study - and I did not go all too deep into the app data.  If you have a specific app you would like me to do a deep dive, let me know.  I may be up for it.  Additionally, the data in this post could be easily transformed into a simple forensic parser.  If you would like a simple Python script to parse all this data, let me know.  It shouldn't take me too long. 

Another blog
As an influential member of the mobile forensics community, I believe in promoting each other's work.  There is a blog from a few years ago that appears to still be valid today. Apps change and so sometimes findings for one version of an app are invalid when the app upgrades. These findings look good on current versions of the app. The blog was a capstone project for undergrad on this topic.  Check out this link for some excellent Waze work.

Summary
  • Waze stores a good amount of geo-history in easily accessible plain text, mostly in a single database
  • An XML file stores the last place and when the car parked at the end of a Waze trip
  • The waze_log.txt file has a lot of data and I've barely checked it out
Questions, comments, suggestions, or experiences?  Fun road trips?  Leave a comment below, or send me an email.