Pages

Friday, April 6, 2018

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

Thursday, February 22, 2018

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

Saturday, January 6, 2018

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

Friday, December 22, 2017

Unpacking boot and recovery kernels


Is that nerdy enough?


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
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
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:
./menu
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).

Why?
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.


Summary
  • 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
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
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
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:
*#hct#root#
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/com.google.android.apps.maps/databases in the userdata image and check out the individual databases.

Data from the Amazon Music app is located under /data/com.amazon.mp3.  Check out what I found in /data/com.amazon.mp3/cache/images/ALBUM:



And check out what I found in  /data/com.amazon.mp3/files/.lyrics:


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



And check out what I found in  /data/com.amazon.mp3/databases/recently_played.db:



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.

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