Obtaining all files in the data partition without a physical image

And why it can be a good call

All blog posts to date

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

Introduction

In my previous post, I made a major announcement. Spoiler alert, I'm going to be a dad!

I have since learned, well, a lot. If I were to boil down everything I've learned so far, it would be as follows:

• The words "crib", "pack 'n play", and "bassinet" are not synonymous.
• Strollers are in fact fashion items for parents, not vehicle for children, and are priced accordingly.
• There are many brands of baby bottles. And they are different. And your baby decides which one he or she likes, regardless of how many of a different brand you have purchased.
• Baby monitor systems are nothing short of security camera marvels. And as a security person, I am leery of every claim made regarding wireless security.
• Kids don't come pre-programmed to sleep through the night. And there is no golden guide to expediting the learning process.
• Consignment shops are great places to buy baby stuff. So long as you don't think about drool from other children.
• A bouncer is not just a big guy outside of a bar.
• A rocker is not just a cool guy with a guitar.
• Rockers either go left to right or front to back. And babies only want one or the other, regardless of which one you have already purchased. Or sometimes they want both.
• Car seats are like food. They have expiration dates. And you don't want to buy them used.

So as you can imagine, this has been quite the learning curve! I wish somebody would write a good guide to this whole parenting thing meant for us computer guys, except I know us computer guys never read manuals. Unless they are short.

So on that note, here's a nice short post on obtaining all the user data files from an Android device instead of a physical image. And why you may do such a thing.

Why would I want to do such a thing?

So in what scenario would you want to skip the process of physically imaging an Android device in lieu of a file system dump? Well first, what exactly am I talking about?

A physical image is a file (or set of files) representing the beginning to end of a storage volume, such as a hard drive, or in this case, an Android device. It contains every bit of data, stored just as stored on the device itself. Done properly, a physical image is an authentic duplicate of the device in question.

A file system dump is a copy of all the files in a specific volume. It contains just files. No deleted records, no slack space, just files.

In Android, all user data is stored in a partition called userdata. If you only had to pick out one area of the device to image, you would pick userdata, every single day. That is where all databases, user activity, installed apps, all app data, and logs are stored. And assuming there is no external SD card, it is also where photos, videos, and other media files are stored. So this post is about acquiring all the files from userdata. Not slack, just files.

So why would we do that? Here are some possible reasons:

• You are in a rush
• This is not a criminal case, it is only for research
• You already obtained a physical image but are having a hard time parsing a file system (more on that later)

How do we do it?

Now that I've explained what we are doing and why, let's get it done. First, just like in obtaining a physical image, your device needs to be rooted, and you also need busybox installed. Hook up your rooted Android device to your Linux or Mac computer.

Now we are going to use multiple terminals the way we do in live imaging a phone. Open up two terminals.

Terminal 1 will be for interacting with the device. We are going to port forward, effectively making a network connection between the computer and the device over the USB cable. We will create the archive file and pass it over that USB cable to the computer.

Port forward to create that network.

adb forward tcp:8888 tcp:8888

Open up an adb shell with your phone using the following command:

adb shell

Once shelled in, gain root.

su

Then we will begin making the archive.

busybox tar -cvz /data | busybox nc -l -p 8888

If all goes well, the screen should freeze. This command copies all of /data into an archive file and passes it over the USB wired network connection to whoever is listening. Which leads us to Terminal 2.

Terminal 2 will be for interacting with the computer and receiving the archive file. First, go to the directory you want the archive to arrive.

cd /path/to/desired/location

Now use netcat to listen to the USB network connection and receive the archive.

nc 127.0.0.1 8888 > data.tar.gz

If all goes well, the screen should freeze. This command listens to local port 8888, as set up previously with the adb forward command, and passes whatever comes out to the file data.tar.gz.

You can optionally open a third terminal for monitoring progress. Navigate to the same location as terminal 2 and use ls -l to check the file size.

When all is done, you will have the file data.tar.gz, containing all the user files. No slack, just files.

f2fs

And finally, a note on f2fs, or Flash Friendly File System. f2fs is an alternate file system to ext4. f2fs seems to perform far faster than ext4 and may someday be the default on Android devices. As is, only a few devices have f2fs support. But I know this is problematic because I have received several emails asking for f2fs assistance. To that, I say two things. One, thank you for letting me know. This post is largely because of calls for f2fs support. Such emails keep me posted on what all issues are out there. And two, f2fs support forensically is currently not good.

FTK Imager does not have f2fs support as of right now. Neither does Autopsy. Some of the pricey tools have f2fs support, but the free tools are lacking. There is Linux support for f2fs, but I've had limited success.

So, if you are trying to image device where userdata is formatted f2fs, my suggestion is as follows. Use this post to obtain a file system dump of the data partition. Then if you would like, obtain a physical image for searching through slack.

Summary

• You can obtain a file system dump of an Android device's data partition, and in some circumstances, this is just what you are looking for.
• The process is similar to obtaining a physical image.
• Without good f2fs support, consider this process if you are working with an f2fs-enabled device.

Questions, comments? Dad advice? Leave a comment below, or send me an email.

Deep dive into an app

And an announcement

All blog posts to date

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

Introduction

First, I have a major announcement to make regarding this myself and this blog going into the future. The announcement is at the end of the post. If you don't want to read a whole bunch about reversing, feel free to skim over this post and get to the bottom.

I've done posts before on reverse engineering apps. I've always covered the commands, so I wanted to do something different. I wanted to do some actual reversing and post the findings.  Sounds like fun, right?

Well, yes and no. Yes, reversing is fun (and frustrating). No, reversing may not always be, say, legal. Which leads me to a problem. I would have loved to reverse a major well known app and post the findings here. The problem is something nice called an "End User License Agreement" (EULA). An EULA is a contract between the user of software and the producer of the software. Normally you just skip over the EULA, but I decided to read some on Android apps. Here's a nice little sample from an actual EULA from a major app by a major publisher, under a section called "GENERAL PROHIBITIONS":

Attempt to decipher, decompile, dissassemble or reverse engineer any of the software used to provide the Services or Collective Content.

Basically, no reverse engineering or we'll send our lawyers after you. Lawyers, they just take all the fun out of life, don't they?  (I have multiple lawyers in the family and I guarantee they are laughing right now).

So seeing as this blog is called "Free Android Forensics" and there are absolutely no ads, I do not make any money here. I have a PayPal link and I use donations there to maintain my equipment. I would rather not ask for donations to pay my legal bills.

So, scratch that plan. Instead, I decided to reverse ...

Solitaire

Yes, this post is going to be on reversing a Solitaire app. You know, the one player card game packaged with every Windows operating system ever. Well, I found an open source version of Solitaire for Android on a free and open git site. I downloaded it, played it, pulled the compiled APK from my tablet, and reversed it.  Why open source?  So that way I can't get in any trouble for reversing it! The source is already online.

Here's also why. I want to show the process of reversing, some basic findings, and some makeups of an app. We've all played Solitaire, we all know the makeup of a deck of cards and the game logic, so I figured this would be a good app to show reversing. Everybody should be familiar with Solitaire, so when I show some reversed app source, the logic should hopefully make some sense.

Getting the APK

So let's pretend I didn't download source code and compile an Android app. Let's pretend I am pulling an app I installed on my device from the Google Play Store to my computer to reverse it. First step, get the APK (the actual app file) from the Android device to my computer. And I'll show a lazy way.

Download ES File Explorer (or some other file manager of your choice) to your device. ES File Explorer allows you to copy installed APKs to your SD card. I opened ES File Explorer, went to the app manager, and backed up the Solitaire app. It appeared in a directory on my device at /sdcard/backups. Then I plugged the device into my computer and retrieved the APK using adb.

adb pull /sdcard/backups

Within the pulled files was the Solitaire app. That was easy.

Getting the Android manifest and app version

My first step in reversing an app is always to obtain the manifest and the version of the app. The manifest is the unique name of the app. The version number is just as it sounds. When you have the manifest and the version of an app, you have a unique way of differentiating that app from others. There are many Solitaire apps out there, but only one with a given package name and version number. I have two ways, two different tools to obtain the manifest and version.

First, aapt. If you have the Android SDK installed on your computer, navigate to the build-tools directory and look for the file aapt. Open your terminal and type the following:

/path/to/aapt l -a /path/to/apk > /path/to/manifest.txt

That command runs the tool aapt against the apk file and sends the output to the file manifest.txt. Open the txt file and look for the following:

A: android:versionName(0x0101021c)="1.12.2" (Raw: "1.12.2")A: package="com.exubero.solitaire" (Raw: "com.exubero.solitaire")

These two lines describe the version number (1.12.2) and package name (com.exubero.solitaire).

Second method, apktool. I've done a post on apktool. Feel free to read over it. I downloaded the newest version of apktool, placed it in the same directory as the Solitaire APK, and ran it against the app using the following command:

java -jar apktool_2.3.1.jar d solitaire.apk

The result is a directory called "solitaire" containing a fully dumped version of the app. There is the smali code (Java byte code), all the xml files within the app, all the native libraries used, and all the images/videos/audio clips/any other resource file required.

Within the directory "solitaire" there is a file AndroidManifest.xml. The package name is there. There also is a file called apktool.yml. The version is there.

Resources

By resources, I mean media files, custom fonts, dictionaries, or other extraneous files required to present the app to the user. We can get to resources one of two ways. First, the apk is just a zip file. We can unzip the apk and retrieve resources. Second, we can use apktool as described above to view resources.

I used apktool. Within the solitaire directory is a directory "res" and within that "drawable". I'll highlight a few interesting images for this demonstration. First, a single image containing the font on all the black cards:

There's a red one also. Next, the suit icons.

Here's the logo on a red king card.

There's similar for other face cards. And finally, the actual logo for the app you would see in your device launch tray.

Solitaire is a simple app. Complicated apps could have way more images. There also could be audio and video.

There also is a directory within res called "layout". This directory contains xmls describing any given screen the user could see. If you've ever written an Android app in either the old Eclipse or the current Android Studio, you may have played with the app layout editor. When you create a layout for a screen, you actually are creating an xml file. Here is an entry in the file stats.xml, which describes the stats screen you can see of your game usage.

<TextView android:textSize="20.0sp" android:gravity="center" android:id="@id/text_best_time" android:focusable="true" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="@string/solitaire_layout_text_text" />

This line describes a text box called "text_best_time", which would presumably display the best playing time the user has ever achieved in Solitaire.

Note on the xml files. The compilation process of an app also compiles the xml files. If you want to see the decompiled xml files from an APK, you have to use apktool. If you unzip the APK and try to look at any xml file, including the manifest, you get junk.

Source code
apktool decompiles the apk to smali, which is java byte code. It is tougher to read than actual java. So let's decompile the app to java. I am using Santoku, a custom version of Linux developed for free by the company NowSecure which contains built-in mobile forensics tools. It contains dex2jar and jd-gui. I'll describe both as I use them for the Solitaire app. You also can Google these tools and download them. They can run in Linux and Windows. I prefer Linux personally. I also previously wrote a post on this process.

First, let's use dex2jar. Within an Android apk file is a file called classes.dex. That file is the compiled source code. It is the actual executable part of an app. It contains all the logic that makes the app run and codes the app's behaviors. dex2jar converts the classes.dex into a Java JAR (Java Archive) file, which you can decompile using your Java decompiler of choice. The syntax for dex2jar is as follows:

d2j-dex2jar solitaire.apk 

The result is a file called solitaire-dex2jar.jar. Note, you also can unzip the apk, retrieve the file classes.dex, and run dex2jar against classes.dex.

Now we use a decompiler to view the resultant jar file. I use JD GUI as it is built in to Santoku. The line to open the jar in JD GUI is as follows:

jd-gui solitaire-dex2jar.jar

Then the tool JD GUI opens up to view the Java source. Pretty nifty.

Here are some quick findings. First, the coder defined what a card is. So there is an object called "Card."

As you can see, the developer defined all four suits (hearts, diamonds, clubs, and spades) and the face value cards (jack, queen, king, and ace).

Above are public functions getSuit and getValue. Other classes can call these functions within the class Card to do logic based on what card it is.

Here is logic that is part of dealing. There are seven stacks of cards to move around in order to reveal the hidden cards and ultimately move all the cards into four stacks of face values. The logic above has seven card "anchors" where a card can be added.

Speaking of dealing, there's shuffling. The deck is shuffled three times to ensure randomness.

And above is the actual shuffling logic.

The above shows some important functions. As you know in Solitaire, when you are moving cards among the seven stacks, you can put a red card onto a black or a black onto a red. But you can not put a black onto a black or a red onto a red. You see a function called "isSuitsOppositeColours". And the objective is to get four stacks of the face values - all thirteen hearts in a stack, all thirteen diamonds, etc. So there is a function called "isSuitsEqual". These functions are called to compare two cards to see if they can be stacked on top of each other for a given context.

When the user wins, the above edits a file to update the statistics. In the app's directory within /data/data, there is a file SolitairePreferences.xml in the shared_prefs directory. The code above has an integer called j. This gets the fastest time as stored in the SolitairePreferences.xml file. The line as follows:

if ((j == -1 || (this.elapsed < j))

checks to see if the win just now took less time than the fastest as recorded in the xml file. Or if the fastest recorded is -1, that means the win just now was the first win.

My tablet is rooted, so I was able to retrieve the app's data files. Here is what that xml file looks like:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?><map>    <boolean name="SolitaireDealThree" value="false" />    <boolean name="PlayedBefore" value="true" />    <boolean name="SolitaireSaveValid" value="false" />    <int name="SolitaireNormalDeal1Score" value="0" />    <int name="LastType" value="1" />    <int name="SolitaireNormalDeal1Attempts" value="19" />    <int name="SolitaireNormalDeal3Score" value="0" />    <int name="SolitaireNormalDeal1Wins" value="10" />    <int name="SolitaireNormalDeal1Time" value="213768" /></map>

The entry "SolitaireNormalDeal1Time" is the fastest time (in milliseconds). So if the value this.elapsed, or the time required to win the game in milliseconds, is smaller than 213768, the new value of SolitaireNormalDeal1Time will be the current time.elapsed.

If you remember above, I mentioned there was a stats.xml file which describes the layout of the stats screen. The logic above fills in the best time time. The integer k is the fastest time as read from the SolitairePreferences.xml file. The value i1 will be the number of minutes and n will be seconds. This logic can take the fastest time from the xml file (213768) and turn it into minutes and seconds (3 minutes 33 seconds).

And there's a screenshot of my stats view. Don't judge.

And there's lots more you could find by reversing the app. Reversing is a rabbit hole. It always keeps getting deeper.

Big picture

So admittedly reversing a game is not very useful. If you are conducting an investigation and you spend your time reversing somebody' solitaire game, you are probably wasting a lot of time.

Here's the thing. If you are investigating a device and you see some data associated with an app that could be interesting but you cannot explain the meaning of that data, you may need to do some reversing. The processes, tool, and techniques in this post can work on any app out there. You can take an APK file, reverse it to source using dex2jar and a decompiler such as jd-gui, and then go hunting through the Java to find logic that creates said interesting data. You can use apktool to get the xml files to compare against the Java source code. Then you can figure out what that data means. Just expect way harder to find results and way more time spent than in a simple Solitaire app. The methods are straight forward. The analysis can be quite advanced. And frustrating.

Announcement

So here's my announcement, and it is a major one.  I often talk about my wife, and sometimes my cat. That's my family. Well, that's all changing. My wife is pregnant! We're going to be parents!

So what does that mean going forward? Well, lots.  Everything in my life is going to be changing. What does that mean for this blog? I do this blog in my free time. My free time is right now spent approximately as follows:

• playing video games
• hacking around with phones and computers
• playing video games
• going for bike rides and runs
• playing video games
• watching football
• playing video games
• spending time with my wife which often involves ...
• playing video games
• working on my car
• playing video games

I suspect that free time is soon going to look more like the following:

• changing diapers
• freaking out about everything sharp or poisonous in my house thus baby proofing everything
• changing diapers
• attempting to get an hour or two of sleep
• changing diapers
• cleaning up barf
• changing diapers
• checking on a crying child which often will lead to ... 
• changing diapers
• taking pictures of absolutely everything
• changing diapers.

Point is, I may not have as much time to devote to this blog as normal going forward. No I'm not retiring, no this blog is not going away, and yes you'll still be able to reach me for questions. I just will probably be around a bit less.

Exciting news!

Summary

• There are many tools out there for reverse engineering Android apps
• Check out the app's code and correlate findings with files in the res/ directory and data files created by the user
• Code review can help make sense of user-generated files
• The process for reverse engineering a simple app is the same as a complicated app

Questions, comments? Good parenting advice? Leave a comment below, or send me an email.

MTPwn

You know better than to trust a strange computer

All blog posts to date

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

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

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


Summary

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