Saturday, August 19, 2017

Imaging and examining an Android car stereo

And road trips

All blog posts to date
I love road trips.

Be it road trips for football games, road trips with family, road trips with friends, road trips for skiing, or road trips to just get away for a little while.  So often, the destination is great, but the top memories from the trip are memories from driving.

So last year, the musical Hamilton was all the rage.  The musical tells the story of Alexander Hamilton, one of the nation's founding fathers who founded the Department of Treasury, who was a royal pain to many of the other founding fathers, and the musical is told largely through the eyes of Aaron Burr, one of the nation's first vice presidents and also the man who shot and killed Hamilton in a duel.  The musical has a hip-hop soundtrack and tells the story of Hamilton and some of the virtues of the founding fathers in a fun and semi-educational manner.  The top thing my wife wanted was to go to Broadway in New York and see Hamilton.  So for her birthday, I surprised her with Hamilton tickets.

We drove to New York, saw the show (it was outstanding), ate at a New York deli, drank beer at a New York bar, had a great time celebrating my wife's birthday.  You know what else is great?  The Hamilton soundtrack.

You know what's not great?  The Hamilton soundtrack on loop for the entire drive.  You see, my car has a stereo that runs Android, because of course the guy who runs an Android forensics blog would have a thing like that.  I set up the Amazon Music app,  and my wife figured out how to play music of her choice in the car.

"The world's gonna know your name. What's your name, man?"
After about eight times, I certainly know your name.
"Alexander Hamilton, my name is Alexander Hamilton"
Yup, got it.
"And there’s a million things I haven’t done, but just you wait, just you wait..."
Still got it.  And yes, I've waited several times now.

So anyways, great road trip.  Having a stereo that can access the limitless libraries of music, podcasts,  and broadcasts on the Internet sure beats old road trips where I was limited to whatever radio station I could pick up until the bandwidth faded and all I got was static.

This post will be about my cool Android stereo.  Be ready for me to geek out a bit.  (You've probably read enough of this blog to already expect me to geek out.)

The stereo

Here's the stereo I have.  It is by a company called AutoPumpkin.  Now I don't have the Android 7.1 version, though I could upgrade.  Mine is a couple years old and runs (don't laugh) Android 4.4.

Note: this is not Android Auto.  Android Auto is probably more secure and more difficult to image than what I'm showing and may not store as much data.  My stereo essentially is a standard Android device with all the hookups needed for a car stereo.

I had to order a stereo harness for my car.  Once I received the harness, I soldered the harness wires to the corresponding AutoPumpkin head unit wires.  I prefer soldering over any other splicing technique just because it is more secure.  On the car itself, I had to open up the dashboard, remove the OEM stereo, and install the AutoPumpkin.  Additionally, I wired the new stereo up to the car's microphone so I can make phone calls easily while driving.  I also did some extra wiring to the car's steering wheel buttons so I can control volume and calls via the existing buttons on the steering wheel.  Pretty nifty.

The stereo has WiFi.  So I set up my phone as a WiFi hotspot, and just like that, my stereo is online.

The stereo comes with the Google Play store installed, so if you set up your Google account with the device online, you can download anything.  On the stereo itself, I have Google Play Music, Amazon Music, Pandora, Stitcher (podcasts), and of course I can stream anything from my phone to the stereo for unlimited audio options.  It makes long trips go quickly.

Now something I feel I have to say here.  You can technically with these stereos play movies.  You can install and use just about any Android app, which means you genuinely can play Netflix or other streaming movie services.  As in, you technically can have video playing on a screen which would naturally distract you from driving.  I will say this once and I hope I never have to say it again: don't.  It may be illegal where you live to play movies while driving, but regardless it is distracting.  Just don't.

Now that's out of the way.  This is a forensics blog, isn't it?  Let's have some fun!

Imaging the stereo

Yes, I'm going to image an Android stereo.  As you may recall from previous posts, live imaging an Android device requires three things: a data connection between the imaging computer and the device, an exploit, and an imaging command.  We're going to do things a little differently here.

The imaging computer will be the device itself.  I'm sure I could hook my laptop up to the stereo, but that's just a bit cumbersome.  We're going to instead hook up a USB stick (the stereo includes two USB cables) and image the device onto that stick.

So next, we need an exploit.  We need to root the stereo.  It turns out, that's the easiest step of all.  And I can take no credit for it.  Check out this awesome XDA site on these types of stereos.

Open Settings, go to Factory Settings, and you get a prompt for a password.  Type in the following:
And just like that, the device is rooted and now includes Superuser settings.

Now with the USB connected, download an Android terminal app.  I use the Terminal Emulator for Android app.  Open up the terminal and type su to gain root.

Then type mount to see your partitions

In the above images, you see the userdata block and the USB stick destination.

So with all this done, it's time to image userdata.  Enter the following into the terminal, and hopefully you're not as clumsy as me with the keyboard and make a few less typos.
dd if=/dev/block/mtd/by-name/userdata of=/mnt/usb_storage2/userdata.dd
And feel free to image any other block as above.

Examining the image

I unplugged the USB stick, brought it to my computer, and opened up the userdata image in FTK Imager.  And it looks like an Android image.

Want to check out Google Maps history?  /data/ in the userdata image and check out the individual databases.

Data from the Amazon Music app is located under /data/  Check out what I found in /data/

And check out what I found in  /data/

(If you're unsure what that is, check out the following video)

And check out what I found in  /data/

Did I mention my wife really likes Hamilton?

The big picture

So these stereos are really cool.  I have fun with mine, and they make road trips faster and more entertaining.  And they are easy to image and examine.  Depending upon what apps the user installs, there may be navigation apps to tell about the user's locations of interest.  That's a goldmine for any investigation involving a car stereo.  I mentioned Google Maps above.  I've also used Waze in the past and found my navigation history.

Now I showed a way to live image the device.  I suppose it also can be done with chipoff.  You could probably physically remove the chip, read it, and get the same results.  There's probably a good way to image it by connecting a laptop via USB.  Just for fun, I imaged it over WiFi once.

Point is, if you're having fun with your own of these devices, you can image it easily.  If you are an investigator and evidence could include an Android stereo like the one I have, there could be seriously valuable data there.


  • There are fun Android car stereos out there and they are easy to set up with a little bit of curiosity and a lot of Google-ing.
  • These stereos are easy to image and store data like any other Android device.
  • If you are running an investigation where the scope includes a smart car stereo, think navigatio history.

Questions, comments?  Any other Hamilton fans?  Leave a comment below, or send me an email.

Sunday, July 30, 2017

Using Windows to Live Image an Android device

It works but I do not recommend it

All blog posts to date
In a post from a few years ago on live imaging an Android device, I showed how to use Mac or Linux to image your Android device using three main steps: data connection between the computer and the device, an exploit, and an imaging command.  The final step requires netcat, which is built in to both Mac and Linux.  I have never showed a Windows method because netcat is not native in Windows, or it is not included by default.

The problem is everybody in the world uses Windows, except apparently the 2.36% of us geeks who use Linux and the 3.49% of people who have enough spare money to afford a Mac (not me).  So many people have emailed me throughout the years asking for a Windows alternative, and I've always recommended using a Linux VM in Windows to get the job done.  And funny story, when I was in grad school studying the geeky subject of Cyber Forensics, I often had a laptop in class (that is when I was in class and not at football games, researching, grilling steaks, paper writing, or drinking way too much coffee).  Around half of us in class with laptops used Linux.  So when I say that it is geeks who use Linux, that is true.  And I often use Linux at home around my wife, who has no idea how to get around my computer, but it is always funny to watch her try.

A while back, someone commented on one of my pages a link to a Windows build of netcat.  So I've played around using that netcat tool to image devices in Windows.  And yes, it works.  You can make a dd image similar to the Linux/Mac methods but via Windows.  This post will show you how to use Windows to image a device.  I also have caveats and why I genuinely recommend Linux or Mac, and I'll explain why.

How to image the device
First, review my post on live imaging an Android device.  I wont' rehash that post here, but it would be good do understand the content.  This post will be showing the Windows equivalent.

Netcat for Windows
There is a non-native netcat for windows, built into the wireless scanning tool nmap.  Here's a quick writeup on nmap's inclusion of netcat.  That writeup includes a link for downloading and compiling just netcat if you wish.  If you'd rather not compile anything, follow this link to download ready-to-go nmap, including netcat.  I would recommend downloading the "latest stable command-line zipfile" and unzip that file to someplace you'll remember.

Imaging in Windows
The steps to image a device are the same in Windows as in Linux or Mac.  Open two command line windows.  One for interacting with the Android device via adb (cd to whatever directory has your adb if you need to locally call it), and one for outputting the image to your computer locally (cd to wherever you plan to save the file).  Additionally open a Windows Explorer window for checking on the progress, at the same directory you plan to save the file.

Connect your Android device (and of course root it and install busybox), enable adb, and go to Window 1.  Ensure the Windows computer can see the device by entering adb devices.

C:\Users\MarkL>adb devices
List of devices attached
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
08****7d        device

As the above output shows, I can see my device via adb.

Now port forward as normal, and just for kicks I'm going to change around the port number from my normal 8888:

C:\Users\MarkL>adb forward tcp:9876 tcp:9876

And now we do the normal steps:

C:\Users\MarkL>adb shell
shell@flo:/ $ su

root@flo:/ # dd if=/dev/block/mmcblk0 | busybox nc -l -p 9876

Now open Window 2.  This should be at the location where you want the image to be saved.  Enter the following command:

\path\to\where\you\saved\nmap\ncat.exe 9876 > image_name.dd

Here's how it actually looks for me, using real paths:

C:\Users\MarkL\Desktop\imaging_in_windows_demo>C:\Users\MarkL\Downloads\nmap-7.50\ncat.exe 9876 > mmcblk0.dd

And if all goes well, the terminal will stop responding.  I've heard some people say they get a missing dll warning for some dlls using this build of ncat.exe.  I did not get any such issues,but I also have installed so many tools throughout the years that I most likely have all the required dlls.  If you have such an error, just google the dll name and you'll be able to find it.  Download the dll and place it in the directory with ncat.exe and you will be good to go.

Open your Windows Explorer window, which should be at the same location as Window 2  Use the refresh button to ensure the image file is increasing in size.  If so, you're good to go.  Pretty straightforward.

So why do I not recommend using Windows?  Simply, there are some issues, one in particular.  The issue is ncat.exe is not default on Windows.  I've had many times where I've started up an image and it has not completed successfully for unknown reasons.  I did not touch the device to ruin the USB connection, I did not let the computer sleep, I did not in any way impede the connection between the computer and the device, and somehow the imaging process fails and I'm stuck with an image file representing the first few gigs of a 32 gig device, or an imcomplete image.  In Window 2, I get the following error message:

close: Result too large

And oddly enough, if the image is successfully made, I get the same error message.  And yes, the image often is made just fine.  I've successfully imaged 32 gig and larger devices using this method.

If I had to take a guess at the cause of the error, it is this: netcat is generally meant for passing files along networks, either of ethernet cables or wireless networks.  nmap is a network scanning tool, so it makes sense to include netcat.  So this specific build of netcat, an addition to and not native to Windows, was built to be part of a network scanning suite for a specific network related function.  It was not built with USB-based networks passing gigabytes and gigabytes in mind over a USB cable while at the same time running a different protocol (adb).  So we're severely overextending its intended usage.  But that's just my guess.

So there are errors.  This is problematic.  More problematic is I cannot explain the genesis of the errors or develop a reliable workaround.

I'm briefly going to go back to grad school and put on my theoretical hat, thus removing my technical geek hat.

If forensic evidence is being presented in court, the evidence must be admissible.  Admissibility is ruled in federal courts and many state courts by the Daubert Criteria .  One of the requirements is the criteria is if the method has a known error rate.

Let's say this method of using Windows ncat.exe as part of an imaging process were to go through a Daubert test.  I would seriously question the error rate.  I personally do not know the error rate; I do not know how often or why the imaging process fails.  That issue in an of itself leads me to not recommend using Windows command line methods to live image an Android device.

If you want to use this method, more power to you.  I'd just use it with caveats: it may error out while imaging, it may not be reliable in court, and the guy telling you about this method isn't a big fan and would rather recommend Linux or Mac as your imaging system.  But if you're imaging a device for fun or for your own research, go for it.

Putting my tech hat back on now.

  • There is a Windows method to live image an Android device, using a build of netcat found in the nmap tool
  • The netcat tool sometimes fails, and I cannot explain why
Questions, comments, suggestions, or experiences?  Old grad school stories?  Leave a comment below, or send me an email.

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:

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?

  • 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.

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.

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.

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
  • 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="" 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="" 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:


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.

  • 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?

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.

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' ?>
    <string name="dest_lon">[REDACTED]</string>
    <string name="dest_name">
    <string name="dest_venueId">
    <string name="dest_lat">

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?

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.

  • 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.

Thursday, December 8, 2016

Dirty Cow

A potential game changer in forensics

All blog posts to date

About two and a half years ago, I wrote a post on live imaging an Android device.  Based on the view stats I see on this blog, it seems like this post has a lot of popularity.

Fast forward some time and several operating system revisions, and the post is now quite obsolete.  The post relied upon TowelRoot, which is an exploit that has been patched for over two years.

Now what is not obsolete is the general method.  Data connection between the forensic computer and the device, exploit, imaging command.  These concepts are still the same.  The problem is, I don't have an exploit for new Android devices.

Dirty Cow
Enter cve-2016-5195, or "Dirty Cow".  The link in the previous sentence is to the official documented exploit.  In short, it is a Linux exploit that is also in the Android kernel.  It could potentially be used as a root vulnerability.

Several developers have released open source versions of Dirty Cow for Android, but all as proof-of-concepts.  To the best of my knowledge, nobody has released a version of Dirty Cow specifically for rooting devices.  I have tried several techniques on my personal phone and still no root shell.  The source is open in C and can be compiled using the Android NDK.  Now I personally have C experience, but the last time C was my primary language, the top selling phone worldwide was the Motorola Razr and Barack Obama was a little known senator from Illinois.  And the world still hated Tom Brady and the Patriots, so I guess some things never change.  Didn't I mention in my previous post that I'm officially a dinosaur?

If anybody gets Dirty Cow working on Android like Towel Root, meaning a do-all root program, then suddenly we as forensic examiners can use the live imaging guide to image any current Android device, or at least until Dirty Cow is patched and the patch is wide spread.

As I am using a Galaxy S6 running 6.0, I have not rooted my phone.  That may come as a shock to many.  The reason is I do not have a way to root my phone without tripping the Knox warranty bit.  I would like to keep that intact but still gain a root shell.

And of course, where there are forensic implications, there are also security implications.  If I can image anyone's phone, then so can anyone else.  And anyone can access and take privileged information from a device.

Community Work
So here comes the point of this post.  Who out there is working on Dirty Cow or other new exploits?  If anyone reading this is interested in Android forensics and is working on gaining root shells, I'd sure like to hear about it, whether you are using Dirty Cow or something else entirely.  If you are able to, please share.  I am happy to collaborate or point you in the direction of someone who can collaborate as well.

And, have you had any success with Dirty Cow or any other current exploit?  If so, how did you do it, what device, any troubles, etc?

I personally would be very interested in getting an exploit for newer Android phones up and running..  The purpose here is for forensic research so I can share with the digital forensics community community continuing results.


  • TowelRoot is obsolete.
  • Dirty Cow is a a possible way to gain an equivalent root shell on newer devices.
  • Collaboration?
Questions, comments?  Any research you wish to share?  Leave a comment below, or send me an email.

Saturday, June 25, 2016

Interpreting data from apps

Lots of apps means lots of data

All blog posts to date
In Android, just about all the data you care about will be app data.  Text messages?  App data from the SMS app.  Phone logs?  App data from the phone app.  Facebook chats?  App data from the Facebook app.

Now I think of myself as being a young guy.  At least, I'm not old, or too old.  I am a millennial.  So you could imagine the surprise when I heard the following comment from a college-aged family member:
Mark, you still text?  You are such a dinosaur.

Yes, I am a dinosaur for still texting.  Now I can remember literally laughing out loud when I first received a text from my father.  He had finally graduated from placing a phone call for even the simplest of messages to convey to sending a short message over SMS.   Fast forward a few years and I am a dinosaur for not graduating beyond texting.  But graduating to what?

Well, that college-aged family member said he and all his peers use apps to message each other.  Facebook, WhatsApp (which is now owned by Facebook), and I'm sure others.  C'mon, I asked him, what's wrong with texting?

And why use Facebook instead of texting?

Can you send photos over these apps the way I do with MMS?

And what exactly is WhatsApp?

Now beyond the young kids who dance on their elders' fossils for using a technology which my elders only recently began using (poorly), there are others who, for better or worse, use apps for communicating.  For a dramatic example, the terrorist organization ISIS famously uses the app Telegram for spreading propoganda.  Now you may think that the owners of Telegram may consider it a responsibility to shut down ISIS usage.  And Telegram has in fact made an effort to ban terrorist usage of their app, but that was only after laughing off the notion with the following line: I propose banning words. There’s evidence that they’re being used by terrorists to communicate.

Also sadly in the news was the app Kik  In the recent tragic murder and kidnapping at Virginia Tech, the perpetrators used the app Kik to lure in their prey.  The story is horrifying on so many levels.

Now what about other apps?  Games, sharing apps, social media, etc.  Might those apps store some significant data too?  This post is all about how to parse and interpret data from third-party apps.  Why is this significant?  If you get all the SMS and call logs and other traditional evidence, you may have missed the device owner's primary method of communication.

Now this post will not be a specific how-to-parse-this-app post.  Instead, this is a generic guide for parsing that may be of help.  I hope to convey methods apps store data and how to access and read this data.  I believe the challenge of parsing and interpreting app data is or will soon become more tedious than imaging devices.

Where do apps store data?
First, Android security prohibits users from accessing the userdata partition, which is where all apps store their data.  (Some apps may also store some data on the SD card, but this is "unprotected" data.  Not the "good stuff.")  You either need an image of the device (and you can create an image using my post on live imaging an Android device) or you need root access.  In this post, I am working from an image of a device.

Android by default stores user data in the /userdata partition in the directory /data.  The below screenshot is from a screenshot of FTK Imager looking at the data directory.

You'll see that within the data directory are directories containing package names.  The directory air.WatchESPN stores user data associated with the WatchESPN app.  The directory stores data associated with the YouTube app.  The directory will story web history and other data associated with the Chrome browser.

What kinds of data?
By default, most user data is stored in SQLite databases.  For a writeup on viewing SQLite data, check out my previous post on SQLite databases.

Most apps use SQLite in some fashion or another.  And if the app you are trying to parse stores all its data in SQLite with no encryption of any kind, you are good to go.

Other types of data can also be found.  The following is a screenshow of the YouTube app's storage:  

All of the directories above store data associated with the YouTube app.  The databases directory will contain SQLite databases.  The directory shared_prefs stores XML files which may be interesting or not.  Depending upon the app, the XML files may store data about the user, such as usernames or maybe even passwords if the developer has a poor grasp on security.  The XMLs can also be pretty much useless.  XMLs can be opened in any text editor of choice.

There also is a "files" directory.  This directory can store anything.  A developer can store images, videos, text, or even more databases in the files directory.

So if your app stores only databases in a nice SQLite format, some user information in XMLs in shared_prefs, and some images or other interesting files in the files directory, you can easily interpret all of this data.  But what about challenging data?  I will highlight two challenges to consider with app parsing.

Many apps use encryption to store sensitive data.  In some cases, you open a SQLite database and are parsing through and you get to a table with nothing but random-looking junk stored in rows.  If you come across such a finding, you may have found some encryption.  This is an example of encrypted content within a database.  And if you find such content, you will need to find a way to decrypt the data to make any sense of it.  I am no crypto expert, so I would consult one if I came across such a finding.

And a side note.  If you come across a string that looks like the following:

you have come across Base64 encoded text.  This is not encryption and can easily be decoded.  Base64 encodes anything into a random set of uppercase, lowercase, numbers, and some symbols, and if padding is required, the string ends with equals signs.  Here is a Wikipedia page on Base64.  You can come across Base64 in databases, XML files, URLs, or just about anyplace.

Some apps also encrypt their databases entirely.  WhatsApp, for example, encrypts their entire database.  If you come across an app that you know is storing a good amount of data on the device and yet you cannot find a database but you find entire files of random-looking data, you may have found encrypted databases.  Again, consult a crypto expert.

Non-standard data storage
App developers are developers, and developers like to develop things.  What do I mean?  I mean that developers often get tired of using built-in functions, like SQLite, and so they choose to implement a different database format, or they make their own.  I have plenty of jokes to make at my engineer friends' expenses about over-engineering everything.

So while SQLite is a nice and easy format to parse, there are other database formats out there for Android.  Here is a list of ten known and available non-SQLite database formats.  If you come across an app with a non-SQLite database, you will need to find a way to interpret all the data.  If there is not a parser available, you can use a hex editor to simply view the database and make sense of it, or you can (or have a developer) write a parser so that next time you come across such a database, you will be ready.

So big picture.  What do you do when you find an app on a device and you are unfamiliar with it?  Here is a list of steps you can do to make sure you get all the possible data.
  • Examine all the data files.  View SQLite databases.  Open XMLs in a text editor.  Open unknown files in hex editors.  View any media.  Make sure you view everything.
  • Check out the file /data/system/packages.xml.  This is a file which stores information about all apps installed on the device, including device permissions.  See any permissions that stand out?  If you see camera permissions, be on the lookout for photos associated with the app.  In a previous post, I detailed the file.
  • Reverse engineer the app.  Look at the source.  It may help you understand what the app does and how it stores data.  Here is a previous post on reverse engineering.
  • Once you have made sense of the data, report it in a standardized and readable format.
  • If you think you may come across this app again, consider writing a program to parse through data based on your findings so you can do this process automatically.
Resources available
There are plenty of resources available for interpreting data from the diverse apps out there.  I will list out a few.
  • Mobile forensic tool vendors.  I was recently at Mobile Forensics World in South Carolina.  There were many vendors presenting similar information to this post.  Everybody in the mobile forensics community is dealing with all these third party apps.  For example, the company Magnet Forensics sometimes releases findings of different third party apps.  Here is an excellent writeup on data within the app Skype.
  • dex2jar.  In my post on reverse engineering, I show how to use this program to reverse an app to a Java jar.
  • Java Jar decompilers.  With the Java jar from dex2jar, a decompiler can interpret the jar as Java source for reverse engineering.
  • Wireshark.  Especially with chatting or social apps, you may need to understand data coming over the air to the device.  Wireshark can help you capture data in transit.
  • JEB.  An app decompiler.  This is most definitely not free software.  If you need to decompile and debug an Android app to see from the "app's perspective" how data on the device is created, JEB can do the trick.


  • There are so many apps out there which store important data on the device.  If you only look at SMS and call logs, you may miss the most important conversations on the device.
  • Apps store data in the userdata partition.  You need either an image of the device or root access to get at it.
  • Data can be stored in challenging format.  If you come across encryption and you are not a crypto expert, you may need to call one in.
  • There are resources out there.  Everybody in the community is dealing with this challenge.
Questions, comments?  Any other dinosaurs out there?  Leave a comment below, or send me an email.