Saturday, January 6, 2018


You know better than to trust a strange computer

All blog posts to date

My wife and I travel a lot.  We have visited four of the seven continents, many countries, hiked in amazing places, eaten all kinds of foreign and exciting foods, taken in many cultures different from our own, and seen some unforgettable sights.  And we've also had some bizarre moments, like being offered cooked snake and scorpion on a skewer.  We said no.

We have loads of travel stories.  And we're glad to share some.  Just ask!

So naturally, we spend a lot of time in airports.  So the first time we traveled together when I saw something like this:

or this:

I respectfully declined and instead used my one of these:

She asked why, and so I explained my reasoning, quoting C-3PO:  you know better than to trust a strange computer.

You can't see what's behind that USB port.  Is it just drawing power?  Or is it also attempting a data connection?  You don't know, so it will do you good to not trust it.

Very recently, GitHub developer Salvatore Mesoraca unveiled a proof of concept exploit called MTPwn.  This post is about MTPwn, what the exploit is, forensic implications, and also proof of why you should always only trust your own computing equipment.

Media Transfer Protocol, or MTP, is the protocol that allows you to easily connect your Android phone to your computer and copy bidirectionally files, including photos and videos.  When you plug your Android phone into your Windows computer, you may see something like this on your phone:

And this on your Windows computer:

So long as this connection gets set up properly, you can now transfer files back and forth.

The files you transfer back and forth are in the phone's SD card or internal SD card directory.  You can't access app data or other protected data.  You need root privileges to access such data.  MTP only gets access to "unprotected" files.

And you also know that if your phone is locked with a PIN, you need to unlock the phone first to allow the computer to access contents via MTP.  Well, not anymore, thanks to MTPwn.

MTPwn is an exploit in MTP.  You can plug a locked Samsung Android phone into a computer, keep it locked, and still access contents.  You can only get contents MTP can access, so no root access.  You still need to root the phone to gain a physical image or access protected contents.

Just to say again, this is a Samsung-specific exploit as far as I know.

Using MTPwn
MTPwn is very easy to set up.  Use a Linux computer and download the repository from GitHub.  All credit goes to the developer Salvatore Mesoraca for this awesome work.

The page has excellent instructions.  I won't rehash the build instructions there.  Go ahead and build the tool.

Now plug in your locked Samsung Android phone.  Then run MTPwn.  I prefer to redirect output to a file for easy reading.

$ ./mtpwn > mtpwnout.txt
It may take some time, as the GitHub page notes.  You will see some information about the device.  And then when done, all the available file names are printed on the screen, or redirected to a file if you prefer as I do.

So I checked out the file mtpwnout.txt, and indeed it is a whole list of available files, including a list of all my photos taken.
Galaxy S6/10001/DCIM/Camera/20171107_223803.jpg
Galaxy S6/10001/DCIM/Camera/20171107_223805.jpg
Galaxy S6/10001/DCIM/Camera/20171107_223807.jpg
Galaxy S6/10001/DCIM/Camera/20171107_223815.jpg
Galaxy S6/10001/DCIM/Camera/20171107_223818.jpg
Galaxy S6/10001/DCIM/Camera/20171110_121840.jpg
Galaxy S6/10001/DCIM/Camera/20171110_121857.jpg
Galaxy S6/10001/DCIM/Camera/20171111_104623.jpg
Galaxy S6/10001/DCIM/Camera/20171118_225736.jpg
Galaxy S6/10001/DCIM/Camera/20171124_203841.jpg
Galaxy S6/10001/DCIM/Camera/20171124_203902.jpg
And so on and so forth.

Additionally, MTPwn both places a file on the device and pulls a random one.  It pulled a random photo off my phone of a woodpecker we saw in southern Chile.  This photo was extracted from my locked Samsung Galaxy S6 phone, plugged into my computer in what I thought was only charge mode, where I did not authorize a connection.

Obviously if the exploit can pull one file, it can pull all of them.  You could customize the code and use this tool to extract all the available files to your computer without authorizing such on the phone.

Pretty cool, huh?

Forensic implications
Android device security is getting better and better.  Examiners use tools to beat security on devices in order to obtain data and conduct investigations in a legal manner.  The nightmare scenario for an examiner is a locked encrypted Android device.  The examiner cannot get in, and cannot decrypt the phone.  If the examiner tries some dead forensic imaging process like chipoff, the result would be encrypted and useless contents.  There's not much you can do.

Well, now you can do something if that phone is a Samsung.  You can customize the exploit as mentioned above to pull all the camera-taken photos and videos, screencaps, other media files, and anything else that may reside in the /sdcard directory of the device.  That may not be an exhaustive look at the device, but it is way more than nothing.  And you never know: there may be something truly important found.

Security implications
Back to my traveling as mentioned above.  Don't plug your phone into any random USB port to charge.  If that USB port is doing more than just powering, if it is plugged into a computer, it could potentially be extracting all your photos.  It is feasible.  Bring your own charger.  As always, do not trust somebody else's equipment for sake of convenience.  Good security often is inconvenient, but that is just the truth.

The newest update available on most newer phones patches this vulnerability.  Make sure your phone is updated.  Or be like me and have an intentionally out-of-date phone for hacking.

And in closing, I just have to relay a funny story.  At the beginning of this post, when I was searching for all those images, I came across an image of a USB charger.  I was about to use that image until I read the webpage it was on.  The charger actually had a built-in microphone and would save audio to a hidden SD card.  So while not exactly the topic presented here, it is close.  Use your own charging equipment.

Forensic 4Cast awards
I would be humbled and honored if you would consider nominating my blog, Free Android Forensics, for the award "Digital Forensic Blog of the Year" presented by Forensic 4Cast.

Forensic 4Cast is an excellent resource for all things digital forensics. They run an annual awards ceremony for digital forensics achievements for the year.

2017 was a banner year for Free Android Forensics. From imaging an Android car stereo to studying the Waze app to imaging newer devices and some other fun topics, there was a lot to cover last year. I continually hope to serve the forensic community well by providing interesting topics.

As always, I thank you for reading. If you found my content useful, insightful, interesting, or maybe even funny, please consider nominating Free Android Forensics for Digital Forensic Blog of the Year.

  • MTPwn can obtain a list of all files in the /sdcard directory of a locked Samsung device without permission.  The exploit can feasibly be updated to pull all said files also.
  • If you are investigating a locked Samsung Android device and have no way to obtain any files, give this exploit a chance.  You may obtain something useful.
  • Think security.  Keep your devices updated.  Don't trust other computer equipment.  Don't charge off random USB outlets.

Questions, comments?  Fun travel stories?  Leave a comment below, or send me an email.

Friday, December 22, 2017

Unpacking boot and recovery kernels

Is that nerdy enough?

All blog posts to date

It may come as a surprise to you that I am an enormous Star Wars fan.

Yes, that may be surprising.  I mean, I only run a blog on Android forensics (nerdy), I hack around in my spare time (nerdy), I track football stats like it is my job (nerdy), and I collect watches (nerdy).  So you may be quite surprised to know that I am a Star Wars fan.

And you may have heard that a certain movie came out last week.  Of course my wife and I saw Star Wars: The Last Jedi on opening night.  No spoilers:  I loved it.  It is a complex movie that addresses some themes not previously explored in Star Wars.  Normally Star Wars is black and white, good and evil.  This one is more subtle.  It is awesome.

And of course there is some outstanding action.  I won't give anything away but I'll say there is a close-quartered battle in the movie that might be the series' best action scene.  There is good emotion and character development going on in that scene, and of course the visuals of the fighting.  Excellent scene.

There are so many things in the movie that I just haven't seen before in a Star Wars movie.  And with that, I love that they brought back some weirdness.  Star Wars needs to be weird.  When the original came out in 1977, everybody probably thought Chewbacca and that entire cantina scene was weird.  Now that Star Wars is such a staple of pop culture, it's not weird; it is just accepted.  So this one brought some weird back and it was a perfect fit.

Overall, I haven't enjoyed a movie in the theater this much since Mad Max: Fury Road.

I could keep going on and on but I'm afraid I'll get into spoiler territory, which I will not do.

So why, you may ask, do I open with a Star Wars commentary in a post on unpacking kernels?  Honestly, I've got nothing.  Just wanted to talk some Star Wars.

On we go.

What is a kernel?
The kernel is the core of an operating system.  Check out this Wikipedia article if you would like to know more.  The kernel has the core services of an operating system.  It has the programs that allow a device to even run in a usable state.

In Android, the kernel is not part of the system partition.  It is a separate part of the device and you can retrieve it using forensic tools such as FTK Imager.  There additionally is a recovery kernel.

The boot kernel is what boots up when you run normal Android.  The recovery kernel is what runs when you are in recovery mode.

I previously said the kernel is the core operating system.  It does not contain default apps, like the phone app, web browser, and other core apps.  Those are in the system partition.  The kernel instead has much more low level utilities.

What does unpacking a kernel even mean?
Unpacking the kernel means extracting files from within it.  Pretty straightforward.  And surprisingly easy, which leads me to the next section.

How to do it?
Head on over to this XDA site.  All credit goes to user dsixda for developing this awesome tool, the Android Kitchen.  This is a very useful tool for making custom Android ROMs with the ability to automatically do many of the functions needed to make your own Android build.  We're using it for forensics, but if you are developer, definitely check this tool out.  The tool's development has been done for quite a while, but the Android Kitchen remains an immensely useful tool.

Now before anything, make a physical image of your device.  Follow the instructions on any of my posts on imaging a device and image the device's /dev/block/mmcblk0.  Then open the image in FTK Imager and extract out the boot and/or recovery images.  The following screenshot of FTK Imager shows what I mean.

Alternatively, if you have downloaded a factory image to flash to the device, you can extract the boot and recovery images out and analyze them.  Depending upon the device type, you might need to run some process on the image before proceeding to the next step.  You can reach out to me if you're in this type of situation.

Download the kitchen in a Linux or Mac environment (it says it also works in Windows with cygwin but I've never personally tried), and just unpack the zip.  That's it.  (You need to install Java but chances are you already have it set up).

Now open a terminal window and cd to the directory where you unpacked the Kitchen zip and enter the following:
This launches the Kitchen menu.  Then type "0" for  "ADVANCED OPTIONS", and then "12" for "Tools for boot image (unpack/re-pack/etc.)".  And then "a" for "Extract kernel+ramdisk from boot.img/recovery.img in any folder".

At this point you see the following message:
Creating folder /<path to kitchen>/Android-Kitchen-0.224/bootimg_<timestamp> ...
---> Place boot.img/recovery.img into the folder mentioned above <--
Press Enter to continue

Assuming you have already extracted your boot or recovery from your image using FTK Imager or from a factory flash image, rename the extracted partition boot.img or recovery.img (whichever is appropriate for what you extracted) and copy the file to the location specified by the Kitchen.  Then in the terminal screen, hit enter.

The Kitchen then does all the unpacking, and it does it fast.  When done, navigate to the directory.  You'll likely see two entries:  a directory called boot.img-ramdisk, and a file called zImage.  The file is the actual kernel program.  This is the core program of the operating system.  It is a native executable, so it can be analyzed but that is a topic outside the scope of this blog.

The directory is the RAM disk.  The kernel mounts all the contents of this directory in RAM, and there are all kinds of findings there.  There are various scripts with filenames that start with init.  These are scripts that run on boot.  If you've ever wanted to know what happens when you start your device and you have some basic command line knowledge, check these out.  For example, I have a Nexus 7 boot image and I see the following early in the init.rc script:
mkdir /system
mkdir /data 0771 system system
mkdir /cache 0770 system cache
mkdir /config 0500 root root

These lines create important root directories.  Browse around these scripts.  You might gain some insight into your device.

Check out the directory sbin, if you have one.  This directory stores command line programs, or native executables, that are part of the operating system.  For example, mine has the file adbd, which is the ADB daemon, which activates when you interact with your device via ADB.  Without this file, just about nothing on this blog would be possible.  This file is stored in the kernel and lives in RAM during device operation.

I also unpacked my recovery kernel.  It is laid out much the same way, which may raise an obvious question: why?  When booted into Android, you have a full user experience rich with time-wasting apps (my wife is currently addicted to a mobile game and no comment on my gaming habits), but in recovery mode, you have a basic user interface.  Why is the kernel so similar?  The reason is this is a kernel: the core of the operating system, the functionality that allows the device to actually do something useful.  So the functionality required to power the device on, use the screen, use the buttons, and capture input is the same, whether we are talking about a modern mobile operating system or a basic recovery mode.

Anyways, that recovery kernel is pretty similar, but there are some other interesting findings.  My recovery mode is TWRP, so it is advanced.  There is a directory called twres, and within that images.  I suppose twres stands for TW resources.  The images directory stores a bunch of images used in navigating TWRP.    For anyone that uses TWRP, the following images might look a bit familiar.

All found right there.  Now when booting to normal Android, you will not see images packed into the boot kernel.  User interface images will be stored in the system partition.  Images are packed into recovery mode kernel for a few reasons:
  • the images are small
  • other partitions may not be mounted, so images stored there may be inaccessible
  • updating recovery mode would also require updating other partitions if it is dependent upon files stored in other partitions

I mentioned the sbin directory previously.  The TWRP recovery mode kernel also has an sbin directory ... and it is packed with files, notably busybox.  If you've read my post on live imaging devices, you know that busybox is an insanely useful tool that gives all kinds of extra Linux-style functionality to Android.  This also explains why you are able to image your device in custom recovery mode, because custom recovery mode can include busybox and a full Android shell.  This sbin directory is full because TWRP includes loads of extra functionality.

Honestly, I could do a full post on breaking down the TWRP kernel.  But I'd put most of my readers to sleep (those that weren't already asleep after reading my geeky writing).

This is all fun and dandy, but why would you ever want to unpack your boot or recovery kernel?  I'll give you a few quick reasons:
  • A sense of curiosity.  You're on this blog, so you naturally have that already.
  • To understand the core Android OS.  If you're an advanced type, this might be up your alley.
  • To see what your custom recovery mode or custom kernel is actually doing.  You never know - you might want to see if there's anything fishy going on.
  • If this is a forensic investigation and the owner of the device is a highly advanced user, there's a slight possibility there's some funny business in the kernel worth checking out.  Faint possibility but worth considering.

Forensic 4Cast awards
I would be humbled and honored if you would consider nominating my blog, Free Android Forensics, for the award "Digital Forensic Blog of the Year" presented by Forensic 4Cast.

Forensic 4Cast is an excellent resource for all things digital forensics. They run an annual awards ceremony for digital forensics achievements for the year.

2017 was a banner year for Free Android Forensics. From imaging an Android car stereo to studying the Waze app to imaging newer devices and some other fun topics, there was a lot to cover last year. I continually hope to serve the forensic community well by providing interesting topics.

As always, I thank you for reading. If you found my content useful, insightful, interesting, or maybe even funny, please consider nominating Free Android Forensics for Digital Forensic Blog of the Year.

  • At the core of your Android usage is a kernel, and it is possible to split open the kernel and see what is inside.
  • Every Android kernel has a RAM disk.  You can see the init scripts and some native executables, along with possibly other resource files.
  • Maybe this will be useful for an investigation.  Or maybe it is just fun to do.

Questions, comments?  Last Jedi reviews? (No spoilers please!)  Leave a comment below, or send me an email.

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.

Forensic 4Cast awards
I would be humbled and honored if you would consider nominating my blog, Free Android Forensics, for the award "Digital Forensic Blog of the Year" presented by Forensic 4Cast.

Forensic 4Cast is an excellent resource for all things digital forensics. They run an annual awards ceremony for digital forensics achievements for the year.

2017 was a banner year for Free Android Forensics. From imaging an Android car stereo to studying the Waze app to imaging newer devices and some other fun topics, there was a lot to cover last year. I continually hope to serve the forensic community well by providing interesting topics.

As always, I thank you for reading. If you found my content useful, insightful, interesting, or maybe even funny, please consider nominating Free Android Forensics for Digital Forensic Blog of the Year.

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

Forensic 4Cast awards
I would be humbled and honored if you would consider nominating my blog, Free Android Forensics, for the award "Digital Forensic Blog of the Year" presented by Forensic 4Cast.

Forensic 4Cast is an excellent resource for all things digital forensics. They run an annual awards ceremony for digital forensics achievements for the year.

2017 was a banner year for Free Android Forensics. From imaging an Android car stereo to studying the Waze app to imaging newer devices and some other fun topics, there was a lot to cover last year. I continually hope to serve the forensic community well by providing interesting topics.

As always, I thank you for reading. If you found my content useful, insightful, interesting, or maybe even funny, please consider nominating Free Android Forensics for Digital Forensic Blog of the Year.

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