Some non-root methods to learn about a device

Sometimes you cannot image or root a device

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

This post will be a bit of a change of gears.  Most of the rest of my posts involve imaging the device in question and examining the image.  And of course, imaging requires three things:  

• Data connection between the device and the computer
• Exploit
• Imaging command

Now what if you cannot or choose not to exploit (root) your device?  This is a real situation.  So long as you have the ability to adb shell into the device, there still are some ways to get useful data from the device.  This post is all about some simple ways to gain some insight into the device.

Determine if the device has been compromised
A common fear with Android devices is that the device can be rooted without the user knowing.  This is a legitimate concern, and it can be addressed with an adb shell to the device.  Also this takes a couple little pieces of knowledge:

• The system partition, mounted at /system, is mounted read only
• Normal users cannot modify anything in this partition without a root exploit
• The root binary, su, is typically found in the system partition
• Which all means that if the device is compromised, there is most likely evidence of it found in /system

Shell into the device and cd to /system.  Then do an ls -al.  The -l part of ls will get a listing of all the files and directories at the /system directory including last modified times, and the -a will list any hidden files so you do not miss anything.  Here are the results from my Nexus 5:

shell@hammerhead:/ $ cd /system
shell@hammerhead:/system $ ls -al
drwxr-xr-x root     root              1970-11-15 06:44 app
drwxr-xr-x root     shell             1970-11-15 06:44 bin
-rw-r--r-- root     root         4065 2015-04-17 13:34 build.prop
drwxr-xr-x root     root              2015-06-25 22:10 etc
drwxr-xr-x root     root              2015-04-17 13:34 fonts
drwxr-xr-x root     root              2015-04-17 13:34 framework
drwxr-xr-x root     root              1970-11-15 06:44 lib
drwx------ root     root              1969-12-31 19:00 lost+found
drwxr-xr-x root     root              2015-04-17 13:34 media
drwxr-xr-x root     root              2015-04-17 13:34 priv-app
-rw-r--r-- root     root        89346 2015-04-17 13:34 recovery-from-boot.p
drwxr-xr-x root     root              2015-04-17 13:34 usr
drwxr-xr-x root     shell             2015-04-17 13:34 vendor
drwxr-xr-x root     shell             2015-06-25 22:10 xbin

As the timestamps show, most directories were last altered 2015-04-17, which is when I last flashed a version of Android onto my device.  Yes, I am behind the times.  Intentionally.  I like Android 5.1.1 and I'm sticking with it for now.

But you will also see some oddities.  Namely two directories that were updated two months later on 2015-06-25.  What is going on with etc and xbin?  Let's find out.

So I cd to etc and do another ls -al.

shell@hammerhead:/system $ cd etc
shell@hammerhead:/system/etc $ ls -al
-rw-r--r-- root     root            2 1970-11-15 06:44 .installed_su_daemon
-rw-r--r-- root     root         1472 2015-04-17 13:34 DxHDCP.cfg
-rw-r--r-- root     root       277097 2015-04-17 13:34 NOTICE.html.gz
(A bunch more files ....)
-rw-r--r-- root     root           38 2015-06-25 22:10 resolv.conf
(A bunch more files ....)
drwxr-xr-x root     root              2015-04-17 13:34 updatecmds
drwxr-xr-x root     root              2015-04-17 13:34 wifi
shell@hammerhead:/system/etc $

You will see that the file resolv.conf, which can only be read and written but not executed (explanation found here), was last modified 2015-06-25. So what is in that file and should I care?

I also can see that the file is only 38 bytes.  Small file.  So I just cat it.

shell@hammerhead:/system/etc $ cat resolv.conf                                
nameserver 8.8.4.4
nameserver 8.8.8.8
shell@hammerhead:/system/etc $

The contents of the file are pretty simple. For an explanation of what "nameserver 8.8.4.4" means, quite literally consult Google.

So on the one hand, you have a file which basically just says use Google for DNS, so nothing of real significance.  On the other hand, why was that file modified when it was?  If you remember, at the same date and time that the resolv.conf file was modified, the /system/xbin partition was modified.  Let's cd to that and get an ls -al.

shell@hammerhead:/system/etc $ cd ../xbin
shell@hammerhead:/system/xbin $ ls -al
lrwxrwxrwx root     root              2015-06-25 22:10 [ -> /system/xbin/busybox
lrwxrwxrwx root     root              2015-06-25 22:10 [[ -> /system/xbin/busybox
lrwxrwxrwx root     root              2015-06-25 22:10 acpid -> /system/xbin/busybox
.....
-rwxr-xr-x root     root      1095836 2015-06-25 22:10 busybox
.....
-rwxr-xr-x root     root        75364 1970-11-15 06:44 su-rwxr-xr-x root     root        75364 1970-11-15 06:44 sugote
-rwxr-xr-x root     root       157412 1970-11-15 06:44 sugote-mksh
.....
lrwxrwxrwx root     root              2015-06-25 22:10 zcat -> /system/xbin/busybox
lrwxrwxrwx root     root              2015-06-25 22:10 zcip -> /system/xbin/busybox
shell@hammerhead:/system/xbin $

So what does this all mean?  It means that on 2015-06-25 at 22:10 EST, I installed busybox on my device.  Busybox installed all these logical links at /system/xbin which point to busybox, and busybox additionally changed the /system/etc/resolv.conf to point to Google.

Additionally, you can see that on November 15, 1970, I rooted my device as you can see the su binary.

Wait, what?  In 1970, neither the device nor me existed.  Google didn't exist, cellular connectivity didn't exist, computers used punch cards as input, and bell bottom jeans were hot fashion

No, most likely, I rooted my phone in June 2015.  However, I rooted my phone via recovery mode, which does not use the Android clock, so all activity appears to take place in 1970.  I hate to disappoint you all, but I am in fact not a time traveler.  Additionally, this explains the file /system/etc/.installed_su_daemon as seen above, also modified in 1970.

So quick takeaways.  If you are worried that your phone might be compromised, do an ls -l in /system and see if anything looks like it was modified at strange times.  Additionally, see if /system/xbin/su exists.

Now some caveats:

• The system clock can be changed.  Easily.
• A smart attacker can change the clock around and do changes so that a simple analysis as seen above will not uncover changes made.
• The su binary need not be called su and placed in /system/xbin
• It could be elsewhere and called something else.  As long as it has the right permissions, the file can be placed anywhere on the device with execute privileges.

As always, if you are concerned there is some advanced attacking going on against your device which may employ some clock modification or a hidden root, you can contact me for further assistance with your device.


See what apps have been installed and if there are any you do not recognize
You install apps on your phone and you know what you've installed.  Or you install so many apps that you forgot what you've installed but the fact is you did personally install the app and you can account for it.

But what if somebody else gets their paws on your phone and installs something? We've all read articles about scares over spyware on phones, and we've all seen those movies where the bad guy gets the good guy's phone and installs something nasty which lets the bad guy listen on and everything the good guy is doing.  The truth is the Android development environment can be exploited to allow such apps to run.

So what if you think somebody has "tapped" your phone?  There is a good chance that if your phone has not been rooted and yet somebody put something on your phone, the little gift they left for you is an app.  It may be hidden, but it can be found with some simple command lines.

I'll give a quick and simple method which gets a list of all user-installed apps and then another method which tells details of all apps on the device.

So the quick way first.  Adb shell into your phone and type the following command:

pm list packages -3

pm is a command which stands for "package manager".  It does just as you may think - it manages packages, or apps, on the device.  The command above lists all third party apps, or user-installed apps.  The output from my phone is as follows:

shell@hammerhead:/ $ pm list packages -3
package:stericson.busybox
package:com.redfin.android
package:com.weather.Weather
... a bunch more third party apps ...
package:com.google.android.apps.chromecast.app
package:com.lookout
package:com.fandango
package:com.hp.android.printservice
shell@hammerhead:/ $

If any of the apps listed look like something you do not recognize, perhaps you should look into it.  I personally recognize all the apps installed.  stericson.busybox is a shortcut way to install busybox.  I care about the weather, hence a weather app.  My wife and I went to go see Deadpool last week, hence the Fandango app.

Now let's say you want to look into a specific app.  You can use the dumpsys command, which accesses all types of system logs.  For example, let's do a look into the WatchESPN app.  I may be a massive nerd, but I love my sports.

I enter the following line ...

dumpsys package air.WatchESPN

And I get the following info about the WatchESPN app

shell@hammerhead:/ $ dumpsys package air.WatchESPN                            
... a bunch of developer related activity at the top ... Packages:
  Package [air.WatchESPN] (2f619c56):
    userId=10111 gids=[3003, 1028, 1015]
    pkg=Package{2ab5f4d7 air.WatchESPN}
    codePath=/data/app/air.WatchESPN-2
    resourcePath=/data/app/air.WatchESPN-2
    legacyNativeLibraryDir=/data/app/air.WatchESPN-2/lib
    primaryCpuAbi=armeabi
    secondaryCpuAbi=null
    versionCode=2100103 targetSdk=22
    versionName=2.4.1
    splits=[base]
    applicationInfo=ApplicationInfo{36a34671 air.WatchESPN}
    flags=[ HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP ]
    dataDir=/data/data/air.WatchESPN
    supportsScreens=[small, medium, large, xlarge, resizeable, anyDensity]
    timeStamp=2015-10-31 08:03:15
    firstInstallTime=2015-10-10 15:09:36
    lastUpdateTime=2015-10-31 08:03:16
    installerPackageName=com.android.vending
    signatures=PackageSignatures{155cf1c4 [2bd4d8ad]}
    permissionsFixed=true haveGids=true installStatus=1
    pkgFlags=[ HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP ]
    User 0:  installed=true hidden=false stopped=false notLaunched=false enabled=0
    grantedPermissions:
      android.permission.INTERNET
      android.permission.READ_EXTERNAL_STORAGE
      android.permission.READ_PHONE_STATE
      android.permission.ACCESS_NETWORK_STATE
      android.permission.WRITE_EXTERNAL_STORAGE
      android.permission.ACCESS_WIFI_STATE
shell@hammerhead:/ $  

So what does all this mean?  Let's break down some important highlights.

• codePath=/data/app/air.WatchESPN-2
• The apk is in the /data/app/air.WatchESPN-2/ directory
• legacyNativeLibraryDir=/data/app/air.WatchESPN-2/lib
• Any native libraries are in /data/app/air.WatchESPN-2/lib/
• dataDir=/data/data/air.WatchESPN 
• Data associated with the app is stored in /data/data/air.WatchESPN - though you need to be root to access that data
• firstInstallTime=2015-10-10 15:09:36
• I installed the app in October 2015.  I'm guessing it was to watch this game.  My Bowling Green Falcons put on a show on offense.
• lastUpdateTime=2015-10-31 08:03:16
• The app was last updated on Halloween 2015.  The update must have been scary.
• installerPackageName=com.android.vending
• The app was installed by the standard method, not by ADB or other manual methods
• grantedPermissions
• The app has the following permissions:
•       android.permission.INTERNET
•       android.permission.READ_EXTERNAL_STORAGE
•       android.permission.READ_PHONE_STATE
•       android.permission.ACCESS_NETWORK_STATE
•       android.permission.WRITE_EXTERNAL_STORAGE
•       android.permission.ACCESS_WIFI_STATE

So this app is obviously legit.  And if this information looks awfully familiar, it is because the same information shows up in the packages.xml file.

You can also type the following command:

dumpsys package

and you will get a similar listing for every app installed on the device.  Now I would recommend catting this all out to a file.  The way to do that is get out of your adb shell and cat the output to a file on your computer.  It would look like the following, and note that I am shelled into my computer, not my phone:

adb shell dumpsys package > dumpsyspackage.txt

You will have a file on your computer called dumpsyspackage.txt with a full listing of every app on your device.

Now let's say I found something in the listing for the WatchESPN app that bothered me. I may want to reverse engineer the app.  I can pull the app without root access.  Here would be the line to pull the app onto the local computer:

adb pull /data/app/air.WatchESPN-2/base.apk

Based on the output above, the app is in the directory /data/app/air.WatchESPN-2/, and I happen to know the apks for third party apps in Android 5 get installed in that directory as the file base.apk.  The above command pulls that file to your local computer.

Continuing with that nifty dumpsys command ... 

Fun with dumpsys

As I said before, dumpsys is a command which accesses system logs.  It can tell you a whole lot more than just what apps are installed.

Now if all you want to do is obtain an entire system log, do a similar command as the previous command to dump all package logs to a single file.  Type the following command ...

adb shell dumpsys > dumpsys.txt



... and go grab a drink because it will run for a while.

The resulting file dumpsys.txt will be quite large, unorganized, and difficult to prod through.  So let's get a finer view of it.  ADB shell into the device and type the following:

dumpsys -l

I get the following output:

shell@hammerhead:/ $ dumpsys -l
Currently running services:
  DockObserver
  SurfaceFlinger
  accessibility
  account
  activity
  alarm
  android.security.keystore
  appops
  appwidget
  assetatlas
  audio
  backup
  battery
  batteryproperties
  batterystats
  bluetooth_manager
  ... a bunch more services ...   voiceinteraction
  wallpaper
  webviewupdate
  wifi
  wifip2p
  wifiscanner
  window
shell@hammerhead:/ $   

It is a list of all running services that can be dumped.  So let's say I want to find out about my wifi.  I can enter the following command from the computer, similar to previously dumping all app info.

adb shell dumpsys wifi > dumpsyswifi.txt

And I will get an output about what WiFi I am connected to, packet usage, etc.  You can do the same for any of these running services.  Want to know what your bluetooth is up to?  You know what to do now.

dumpsys is a good tool to play around with and it works on live running devices.  This is not something you can do to an image.  An image is just a file, a dead, flat file.  A device is a live, running computer that you can interact with, or in the above cases, interrogate.

Summary

• There are some ways to get useful information from a live device, even without rooting or imaging.
• Looking at files in your system partition by timestamp can be an indicator if your device has been compromised, though remember that timestamps can be faked with relative ease.
• Dumpsys is a useful tool.
• You can use dumpsys to learn about what apps are installed on a device, and you can use an adb pull to remove the app and examine if you wish.

Questions, comments?  Sports memories?  Leave a comment below, or send me an email.

Identifying your Userdata Partition

In case you only want to image one partition

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

For starters, I'm sorry I haven't posted anything in a long time.  And really, there is a main reason.  You, the reader, may also be able to help.

The reason I haven't posted in a long time is because I have not come up with many great posting topics.  I look for several qualifications in a topic ...

• A topic which which is consistent with other topics on my blog
• A topic which is not overly well covered and known on the Internet
• A topic which somebody with some good Linux and mobile knowledge can do.  In other words, a topic which does not require a mobile forensics expert to do.

So if you have a topic you would like me to cover, please reach out to me.  Crowd-sourcing is very popular these days!

Anyways, this topic comes from a question I field often.  A lot of people reach out to me wanting help imaging specifically the userdata partition.  In my post on live imaging an Android device, I said to reach out to me to find the exact block to image if you want to image userdata.

This posts presents a general way to find the right block to image.  This post is NOT meant to be a replacement for reaching out to me with imaging questions.  If you are working on imaging your Android device and are having issues or have questions, go ahead and send me an e-mail.

Imaging your entire device vs Imaging your Userdata partition
First, do you want to image the entire device, do you want to image just your userdata partition, or do you not know?

If you create an image of your entire device, the result will be a file representing your entire internal storage.  This image file will contain your boot image, recovery image, radio software, system partition, userdata partition, and depending upon the make and model can have a lot more blocks too.  Check out a full image of a Samsung Galaxy S5 sometime if you want to be overwhelmed with partitions and blocks!

If you create an image of your userdata partition, you will have a file representing one partition of the device from beginning to end.  This partition is the "userdata" partition, which contains evidence of user activity.  It contains call and SMS records, contacts, user-installed apps, app data, settings, and so-on-and-so-forth.  In most newer phones, it also is likely to contain photos and videos and other user-generated files unless an external SD card is present.

And if you want to image an external SD card, I would recommend a good ol' fashioned write blocker and traditional forensic techniques.  If you need more information on this, reach out to me.  My skill set is not restricted to Android forensics!

If you do not know which type of image you want to create, go for the full image.  It takes more space because the image file contains all the device partitions instead of just one.  The full image will give you a greater insight into the device - and you may learn a thing or two about how Android devices work!

How to image the entire device
If you've not checked out my post on live imaging an Android device, go ahead and check it out.  This current post will probably not make a whole lot of sense without the knowledge on the live imaging page.

I said on my live imaging post that you should image a block on the device and the command you enter via adb shell to the device looks something like this ...

dd if=/dev/block/mmcblk0 | busybox nc -l -p 8888

This line reads all of the contents of the block /dev/block/mmcblk0 and passes it to the computer via netcat.  And as you saw on the post, this command only works if the device is rooted and busybox is installed.

The block /dev/block/mmcblk0 in most cases refers to the very first sector of the device.  By reading this block, you read the entirety of the device's internal storage.  Imaging this block gets you a physical image of the entire device.

Note: I did not say in all cases the block /dev/block/mmcblk0 refers to the very first sector of the device.  All it takes is one device to have a different naming convention to make a liar out of me if I said the block /dev/block/mmcblk0 is the first sector of the device in all Android devices.

How to image the userdata partition
If you only want to image the one partition, you need to know what block to read.  We do this with the mount command.

Open an adb shell to the device.  Type the following:

mount

You will get several lines of output.  Each of these lines represents mounted partitions.  On my Nexus 5, I receive the following as output of the mount command:

rootfs / rootfs ro,seclabel,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /sys/fs/cgroup tmpfs rw,seclabel,relatime,mode=750,gid=1000 0 0
tmpfs /mnt/asec tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,relatime,nomblk_io_submit,nodelalloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
/dev/fuse /mnt/shell/emulated fuse rw,nosuid,nodev,noexec,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0

Look specifically at the following line:

/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered 0 0

This line indicates that the block /dev/block/platform/msm_sdcc.1/by-name/userdata is mounted read/write (as opposed to read only) at the directory /data and the partition is formatted ext4.

That means the block /dev/block/platform/msm_sdcc.1/by-name/userdata is my userdata block.  I can substitute /dev/block/platform/msm_sdcc.1/by-name/userdata for /dev/block/mmcblk0 in my imaging command.

Now I fully understand that typing /dev/block/platform/msm_sdcc.1/by-name/userdata is a bit cumbersome.  There is a shortcut.  I can enter the following command (and you might need to be root):

ls -l /dev/block/platform/msm_sdcc.1/by-name/userdata

I get the following output:

lrwxrwxrwx root     root              1971-03-18 07:17 userdata -> /dev/block/mmcblk0p28

You may notice a timestamp from the year 1971.  That is nothing to be concerned over - I am in fact not a time traveler.  That timestamp is an artifact of Linux timestamp convention.

This output indicates that the block /dev/block/platform/msm_sdcc.1/by-name/userdata is a reference to /dev/block/mmcblk028.
So, I can substitute /dev/block/mmcblk0p28 for /dev/block/mmcblk0 in my imaging command.
If I want to image just the user partition, the imaging command I enter in an adb shell to the device would look like this:

dd if=/dev/block/mmcblk0p28 | busybox nc -l -p 8888

I hope this all makes sense.  Feel free to reach out to me if you need further assistance.
And now some frequently asked questions
Seeing as this post started with answering a FAQ, I will answer a couple more FAQs.

"Can I use the live imaging technique in Windows?"

Not without some serious hacking around.  The technique I show is a Linux technique that also works on Mac.  This is because the technique relies upon the netcat utility.  Netcat is on both Linux and Mac; it is not on Windows.

Now maybe you are familiar with Cywgin.  Cygwin allows you to run Linux commands in Windows.  I have never tried this imaging technique out on a Cygwin-enabled Windows computer using the Cygwin version of netcat.  If anybody out there tries this out, let me know!  I'd love to know the results.

"I found this specific rooting technique for this specific device.  I have not tested it out yet.  Will it work?"

Sometimes I get asked if a rooting technique works on a certain phone.  And I always look into it and will provide the best answer I can.  The trick is, whatever the phone is, I probably do not have one conveniently laying around to try the technique out myself.

The issue with rooting is sometimes you can accidentally wipe device data you plan to image.  Example: the most common method for rooting Nexus devices is to unlock the bootloader and install ClockworkMod and root through CWM.  This technique works great except for one minor little detail: as a security feature, unlocking the bootloader on a Nexus device wipes all user data on the device.  I would not exactly call that forensically sound.

Similarly, some techniques on newer Samsung phones can result in flipping the warranty bit.  If you root your Samsung phone and then see the following in the bootloader interface:

Then the warranty on the device is void.  If you have a problem with the device, service centers are likely to turn it away.  That may or may not matter to you.  However, without that warranty bit, the device can never have a Knox container.  Again, this may or may not matter to you.  However, I would generally avoid flipping the warranty bit.

So when I get these questions, I research what I can to determine if your rooting technique is likely to safely work.  But as I said on my live imaging post, I am not liable if you harm your device.

"I am interested in a career in digital forensics.  How can I start?"

First, this is a fun career!  It is challenging because technology changes all the time, but there are great rewarding opportunities if the curious minds out there.  If you are thinking of university education in the field, I can point out some great programs - and there are new programs opening every year it seems because we need digital forensics experts. But if you are not sure and want to explore around before truly going down this career path, I can give you a few pointers ...

• Learn command line.  I cannot stress this enough.  In any area of computer science / technology, being comfortable in a command line interface is such an asset
• Learn Linux.  Whether you install Ubuntu and use it to browse the web or you go low level with Linux and do some fun hacks, Linux is good to know.
• Download the free tools.  Try FTK Imager and Autopsy.  Learn how they work.  Try examining your own computer.  Try using a Linux live environment by booting from disk and image your drive onto an external.  Just do anything you can to learn using the tools you already have.
• Read.  There is a great academic community in digital forensics publishing some cutting-edge research.  But before getting into the new stuff, read about the basics.  I can point you in the direction of some good papers.  If you are thinking about a BS or MS in this field, you will certainly read academic papers and do research of your own, so reading academic work beforehand can only help.
• Mobile device forensics specific:  hack around with your own phone.  Or preferably, if you have an old phone, don't sell it - hack around with it.  
• Android forensics specific:  Root the device and learn how it works.  Flash ClockworkMod and adb into the device in recovery mode.  Just hack around with the phone and don't be afraid to take risks, especially if it is not your day-to-day phone.  And don't hack around with somebody else's phone without their permission!  That can get you into trouble!
• Write.  In any field, the ability to do the work and obtain results is of course of great importance.  What so often sets apart leaders in a field is the ability to effectively communicate work and results.  Our universal way of communicating in just about any field is writing.  So write your work in a journal as you go.  Practice writing reports.  If you do not have a template to work from, create your own template.  Polish your writing style.  I know this bullet point sounds on the un-technical side but I cannot stress the importance of writing and effective communications enough.

"Do you consult?"

Yes.  If you have a need for digital forensics services (Android or not, mobile or not) or other Android/mobile related needs and you feel based off this blog I am a person you would like to work on the problem, e-mail me.  I do not take every case as I do this in my side time, but I take side work from time to time.  I can discuss privately how I work, needs you have, and my terms.

"Can you do speaking engagements / guest lectures?"

Yes, if scheduling works.  I have done guest lectures and simple Q&As at universities, including remotely over Skype.  I enjoy connecting with the academic community.


Summary

• If you are not sure whether to image a device's entire internal storage or just the userdata partition, image the entire device
• Use the mount command to find the block to image if you plan to image just the userdata partition

Questions, comments, suggestions, or experiences?  Leave a comment below, or send me an email.

Why not load ClockworkMod or TWRP to image a device?

Alternate recovery modes are useful, but maybe not for imaging a device

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

This post comes from a question I've fielded a few times.  A lot of people, like me, who hack around with their Android devices install a custom recovery mode in place of the default recovery mode.  So the question is, why not install ClockworkMod or another custom recovery mode on a device and use the custom recovery mode as a method to image the device?

So, let's get some terminology out of the way because I threw a lot of information in that first paragraph which you may or may not understand.  Part of the Android architecture is recovery mode.  The user can boot into recovery mode instead of Android in order to perform some basic recovery operations, including installing official updates and factory resets.  Recovery mode is a small operating system with a basic kernel.  The source is available online if you would like to browse.

Users can install a custom recovery mode, such as ClockworkMod or Team Win Recovery Project (TWRP).  These custom recovery modes are also operating systems and the user can boot into this alternate recovery mode instead of Android in order to access recovery functionality.  Extra functionality within these alternate recovery modes allow users to backup their devices, recover from backup, install non-official operating systems, and other advanced features.

Recovery mode runs by default as root.  Recovery options must run as root or else they would not have the proper permissions to execute.  In the stock recovery mode, the user cannot use these root privileges to image the device.  However, the alternate recovery modes allow the user to access a full shell as root privileges via ADB.  As I mentioned in my post on imaging a device, you need a root exploit to image the device.  You can treat an alternate recovery mode as a root exploit, then boot into recovery mode and image the device while the Android operating system is not even running.

This all sounds great, right?  So do I recommend install ClockworkMod or TWRP in place of the default recovery mode in order to image a device?  It depends upon why you want to image the device. In this post, I'll show how to install alternate recovery modes, how to image a device using an alternate recovery mode, and why this method of imaging may or may not be appropriate.

How to install an alternate recovery mode

Installing an alternate recovery mode is very device specific.  Honestly, the best way to figure out how to install an alternate recovery mode is to Google it.  Here are a few search terms:

• clockworkmod nexus 5
• clockworkmod galaxy s5
• twrp htc one

For example, here is how to install ClockworkMod on a Nexus 5.  Note that unlocking the bootloader results in all user data gone.  Note and remember for later in this post.

Here is a guide for more advanced users for installing TWRP on a Galaxy S4.

In short, I can't guide how to install ClockworkMod or TWRP on each and every device.  It is a device specific project.  Search online to find how to install an alternate recovery mode on your own device, and you can always contact me for help.

How to image in recovery mode

Now let's say you've got ClockworkMod installed on your device.  My personal device is a Nexus 5, so I'll use my phone as a guide device.

Disclaimer:  you can cause big problems on your device if you do some of these steps wrong.  I am not liable for any damages done to any devices as a result of reading this page or any other pages on this blog.

First, boot the device into recovery.  If you're not sure of how to do that, search online.  If your device is booted into Android and you have adb enabled, you can try the following command

adb -d reboot recovery

Your device should reboot into recovery.  Then if you enter

adb devices

you should get a response along the lines of ...

03xxxxxxxxxxxx17        recovery

If you get a strange response with a bunch of question marks, try entering the following

adb kill-server

sudo adb start-server

And then try adb devices again and see if you get a better response.

In my post on imaging Android devices, I said you need the following three things

1. Data connection between the computer and the device
2. Exploit
3. Imaging command

If you've followed along so far, we've got all three satisfied

1. You can communicate with the device in an alternate recovery mode over ADB
2. The alternate recovery mode gives full root access to the device
3. Imaging command below

Next, you'll need netcat, or nc, in the recovery mode.  I mentioned before that recovery mode is its own operating system.  As an alternate recovery mode allows a shell to the device, the alternate recovery mode operating system contains commands the user can use.  ClockworkMod and TWRP should both have netcat installed as they both should include busybox.  To make sure, open an ADB shell to the device in recovery mode and type the following:

busybox nc

If the output includes something along these lines:

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Then you are set.  If not, contact me and I'll help you get netcat installed.

Now, just like on my post on live imaging an Android device, we'll image the device using netcat.  I'll go over the instructions again.  Note, I'm basically just copying and pasting from the post on live imaging.

To image the device, you need to do some commands in two different sessions: one shell session to the device, and one shell session to your computer. Open up a terminal window and adb into your device.  Then open up a new terminal window (it will open as a shell to your computer, not your phone) and navigate to the directory where you intend to store your image. Note: if you create the image in a volume formatted FAT32, the maximum file size is 4 gigabytes, so imaging the device would require splitting the file. For ease sake, I suggest imaging to a volume formatted ext or NTFS. Also, make sure the volume has enough space for the device image, which will be as large as the device's storage. For my phone, I need 32 gigabytes of storage to image.


Now, in the shell to your computer in the directory of your choosing, type the following:

adb forward tcp:8888 tcp:8888

This command allows adb to communicate via netcat on port 8888.

Next, in the shell to your phone, type the following:

dd if=/dev/block/mmcblk0 | busybox nc -l -p 8888

This command reads the contents of /dev/block/mmcblk0 (the head block of my device) and writes it via port 8888 across adb using netcat.

Finally, back in the shell to the computer, type the following:

nc 127.0.0.1 8888 > device_image.dd

This command saves the output of the contents across port 8888 (which will be the results of reading /dev/block/mmcblk0 on the device, or the complete image of the device) to the file device_image.dd.

If there's no errors, you are imaging the device. The window will “freeze”, or not allow any more commands because it is busy executing this command. When the imaging process is done, you will be able to type commands into this shell window again. To confirm, open a new terminal window, navigate to the directory where you are saving the image, and type ls -l. This will get a file listing, including file size. If the size of your file is increasing, you are successfully imaging your device.


A quick note on crypto.  If the device's data is encrypted, the image will be of encrypted junk.  You are imaging the device while the data partition is inactive.  If the image appears to be encrypted, you'll need to acquire data while the device is live.

Now that I've explained how to image a device using recovery mode, I'll go over whether or not it is a good idea.

Why recovery mode to image a device can be a good idea

Digital forensics is a big community containing many realms.  Digital forensics can be involved in law enforcement, federal government, research, and IT security.  Digital forensics can also be practiced by individuals wanting to learn more about how their devices operate.  What I'm saying here is the purpose of imaging the device dictates whether or not using recovery mode to image your device is a good idea.

If you are an advanced Android user, you may very well have an alternate recovery mode on your device.  I have ClockworkMod or TWRP on all of my personal devices.  If you are imaging your device in order to do some research on some files or a process, then using an alternate recovery mode is a great idea.  You can image the device while it is not booted into Android, the data partition is not actively in use while imaging.

If you are a security researcher working on mobile work, I definitely recommend installing a custom recovery mode (unless doing so interferes with research).  You may have good uses for some of the advanced functionality which the alternate recovery mode offers.  So if I've described your job and you need to image a device, I recommend the method on this page.

If you are imaging a device where the device is evidence in a case and the device already has an alternative recovery mode loaded, then you can use the alternative recovery mode to image the device.  In doing so, the device is not booted into Android so no user data on the device is changing or even loaded when imaging.  I say this paragraph with a caveat: users can write their own alternative recovery modes, and it is conceivable that an advanced user could bake some special sauce into recovery mode to, say, wipe the device.  While I find such a scenario unlikely, it is conceivable.  And this caveat works as a perfect segue into my next section.

Why recovery mode to image a device can be a bad idea

I said before that the purpose of imaging the device determines whether or not installing a custom recovery mode is a good idea.  I'm going to detail why installing the custom recovery mode can be a bad idea.

If you are imaging a device where the device is evidence in a case and the device does not already have an alternative recovery mode loaded, I definitely do not recommend installing an alternative recovery mode.  If you do choose to install one, you are doing so at your own risk.  There are two reasons why I do not recommend this action.

1. Installing an alternative recovery mode involves overwriting the previous recovery mode.  If it appears that the stock recovery mode is installed, it is most likely not a problem to overwrite the recovery mode.  Users by default cannot access the recovery mode to store data there.  I would not call replacing a stock recovery mode (which you can download easily from the Internet) a material change.  However, it is conceivable that an advanced user could write their own recovery mode to include some extra data or functionality and make it appear identical to the stock recovery mode.  In the unlikely but possible case where you have such a device, overwriting recovery mode means overwriting important data.
2. And this one is just a minor detail.  Installing a new recovery mode often involves factory resetting the device, or wiping all user data.  As in, deleting all case data from the device.  This process is what I would call an RGE, or a Resume Generating Event.  Minor detail, right?

So to sum up the above points, if you are imaging a device because you need to retain the data on the device as you found it, I absolutely do not recommend installing an alternative recovery mode to image the device.

Summary

• Alternative recovery modes, such as ClockworkMod or TWRP, are useful for Android hackers like myself
• Alternative recovery modes provide the user a root shell so imaging the device using an alternative recovery mode is a very similar process to live imaging a device
• It may or may not be recommended to use this method to image a device.  If it is essential to maintain the data on the device as you found it, such as in an investigation, do not use this method for imaging a device.  Live image the device or use a commercial forensic tool

Questions, comments, suggestions, or experiences?  Any RGEs you care to (or not care to) share?  Leave a comment below, or send me an email.

Facebook for Android Artifacts

A Cache of Personal and Communication Information

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, a disclaimer.  This post will detail lots of artifacts on the Facebook for Android app which can be useful from a forensic perspective.  These findings regard personal information about the user and the user's communications with contacts.  My goal with this post is to educate, inform, and possibly assist people working on cases involving Facebook data on mobile devices.  My goal is not to scare the reader away from using Facebook.

I am not writing this post with the goal of getting you, the reader, to remove Facebook from your phone.  I use Facebook on my phone, so I obviously am not too worried about the incredible amount of personal information stored in an unprotected manner on my phone.

So ... if this post disappears at any point, go ahead and assume I received a cease and desist note from Mark Zuckerberg!

Now ... back to the post.  I use Facebook.  My wife occasionally uses Facebook.  Her friends and my friends use Facebook.  My siblings, parents, cousins, aunts, and uncles use Facebook.  I have a grandmother who uses Facebook.  I have a friend from grad school who has a Facebook page for her cat.

Facebook launched over ten years ago as a collegiate social network and this mega-popular website revolutionized social networking.  Facebook evolved from a set of unconnected profiles to a place to share status updates and thoughts of the day to one of the largest (if not the largest) collection of photographs of people in the world.  I'm now of the age that whenever I log onto Facebook, I swear Facebook is nothing except a website for parents to upload cute picture of their kids.

As with any other new technology, Facebook can also attract criminal activity.  Facebook stalking is a real thing and can lead to in-life stalking and worse (even if this video makes it look humorous).  In Facebook's early days, some universities used Facebook photos of underage students drinking as evidence of university policy violations.  Facebook posts have admitted as evidence in criminal trials before and depending upon applicable state law, Facebook posts and messages may be admissible in court.

If you are examining an image of an Android phone for a criminal case and Facebook is installed, there may be good reason to examine data associated with the Facebook app.  This post will detail some of the Facebook data that can be stored on the device and how to interpret it.  And again, please don't uninstall Facebook just because some guy on some Android forensics blog said the Facebook app is creepy!

Where is the data?

First, how do you access this Facebook data?  The Facebook app is an app, so app data is protected by permissions.  I'd recommend reading my previous post on viewing SQLite Databases before diving into this post.  In short, you'll need a rooted device or an image of a device to access Facebook data.

There are two Facebook apps that I'll detail in this post.  The first is the main Facebook app.  The package name is com.facebook.katana, so the data associated with this app will be stored in the data partition in the directory data/com.facebook.katana.  The version of the app on my device is 26.0.0.22.16.  The second is the messenger app.  The package name is com.facebook.orca, so the data associated with this app will be stored in the data partition in the directory data/com.facebook.orca.  The version of the app on my device is 20.0.0.19.13.  Depending upon the version of Facebook installed on the device, data may be slightly different than what I present in this post.  If you have any questions about where data is, you can always contact me.

So yes, if you install both the main app and the messenger app on your device, you have a killer whale (orca) and Michonne's sword from the Walking Dead (katana).

If you've already imaged the device you are investigating, go ahead and copy these directories away from the image to your forensic computer.

Information about Facebook Friends

First, we'll look at the com.facebook.katana app, or the main Facebook app.  Check out the directory com.facebook.katana/databases.  This directory predictably stores database files.

In my previous post on viewing SQLite Databases, I showed how to open a SQLite database file to browse data.  Explore the file contacts_db2.  This file stores a database of Facebook friends.  Within the file is a table called contacts.  There are several columns in this table to be aware of:

• first_name:  self explanatory
• last_name:  self explanatory
• display_name:  self explanatory
• small_picture_url:  A URL to a small version the user's profile picture.  More on that later.
• big_picture_url:  A URL to a big version the user's profile picture.  More on that later.
• huge_picture_url:  A URL to a huge version the user's profile picture.  More on that later.
• communication_rank:  A number representing how often the user communicates with this particular contact.  This number is calculated using some Facebook formula.  Communications include messages, posts, likes, comments, etc.  A 0 in this column means no communication.  The higher the number, the more communication.  From a forensic perspective, this number is a way of determining how often the user interacts with another user.
• is_messenger_user:  A true/false field.  True indicates that the user uses a mobile messenger app (such as the com.facebook.orca app for Android).
• data:  A long string of data describing user profile information.  More on this later
• bday_day:  Birthday.
• bday_month:  Birthday.

For some of the points above, I indicated that I would discuss more later.  It is later now.

There are entries for small_picture_url, big_picture_url, and huge_picture_url.  Here is what a huge_picture_url string looks like for a friend of mine:  https://fbcdn-<redacted>_n.jpg?oh=<more_redacted>eea.  (I redacted most of the URL for privacy reasons.)  And when I entered the URL into a browser, I found this image:

(I chose this specific friend of mine for the sake of anonymity.  No face in this Facebook profile picture).  Yes, this friend of mine is an Oregon Ducks fan.  Don't be too hard on him after the college football national championship game.

Notice how there is no protection, no encryption, no login required to access these Facebook photos.  While there is no public index page that I am aware of to associate a URL with a user, it still bears mentioning that photos are stored without protection online.

There is an entry above for "data".  I said that this is a blob of user data text.  Here is what one of the blobs looks like (with redactions):

{"contactId":"Y2<redacted>k2","profileFbid":"62<redacted>09","graphApiWriteId":"contact_20<redacted>96","name":{"firstName":"<redacted>","lastName":"<redacted>","displayName":"<redacted>"},"phoneticName":{},"smallPictureUrl":"https://fbcdn-profile-a.<redacted>a40","bigPictureUrl":"https://fbcdn-profile-a.<redacted>26e","hugePictureUrl":"https://fbcdn-profile-a.<redacted>eea","smallPictureSize":160,"bigPictureSize":320,"hugePictureSize":466,"communicationRank":0.03445798,"withTaggingRank":0.3325288,"phones":[{"id":"62978<redacted>259","label":"Mobile","displayNumber":"(6xx) 9xx-xxxx","universalNumber":"+16xx9xxxxxx","isVerified":true}],"nameSearchTokens":["<redacted>","<redacted>"],"canMessage":true,"isMobilePushable":"YES","isMessengerUser":true,"messengerInstallTime":1417438579000,"isMemorialized":false,"isOnViewerContactList":true,"addedTime":1419017431000,"friendshipStatus":"ARE_FRIENDS","subscribeStatus":"IS_SUBSCRIBED","contactType":"USER","timelineCoverPhoto":{"focus":{"x":0.5,"y":0.39435146443515},"photo":{"image_midres":{"uri":"https://fbcdn-sphotos-h-a.<redacted>201","width":320,"height":179},"image_lowres":{"uri":"https://fbcdn-sphotos-h-a.<redacted>817","width":500,"height":281}}},"nameEntries":[],"birthdayDay":<redacted>,"birthdayMonth":<redacted>,"cityName":"<redacted>, Ohio","isPartial":false}

Obviously this blob is hard to read, but it is a nice treasure trove of useful information about the individual.  I'll space this out to make it a little more readable:

contactId:  Y2<redacted>k2
profileFbid:  62<redacted>09
graphApiWriteId:  contact_20<redacted>96
name:
   firstName:  <redacted>
   lastName:  <redacted>
   displayName:  <redacted>
phoneticName:
smallPictureUrl:  https://fbcdn-profile-a.<redacted>a40
bigPictureUrl:  https://fbcdn-profile-a.<redacted>26e
hugePictureUrl:  https://fbcdn-profile-a.<redacted>eea
smallPictureSize:  160
bigPictureSize:  320
hugePictureSize:  466
communicationRank:  0.03445798
withTaggingRank:  0.3325288
phones
   id:  62978<redacted>259
   label:  Mobile
   displayNumber:  (6xx) 9xx-xxxx
   universalNumber:  +16xx9xxxxxx
   isVerified:  true
nameSearchTokens:  ["<redacted>","<redacted>"]
canMessage:  true
isMobilePushable:  YES
isMessengerUser:  true
messengerInstallTime:  1417438579000
isMemorialized:  false
isOnViewerContactList:  true
addedTime:  1419017431000
friendshipStatus:  ARE_FRIENDS
subscribeStatus:  IS_SUBSCRIBED
contactType:  USER
timelineCoverPhoto:
   focus:
      x:  0.5
      y:  0.39435146443515
photo:
   image_midres:
      uri:  https://fbcdn-sphotos-h-a.<redacted>201
      width:  320
      height:  179
   image_lowres:
      uri:  https://fbcdn-sphotos-h-a.<redacted>817
      width:  500
      height:  281
nameEntries:  []
birthdayDay:  <redacted>
birthdayMonth:  <redacted>
cityName:  <redacted>, Ohio
isPartial:  false

The entry for a contact's "data", as you can see, can contain all kinds of personal information, ranging from birthday to cell phone number, and I've even seen people's addresses in this entry before.  Two takeaways: one, be careful what you put online, and two, all of this sensitive information is stored on your phone without encryption.

Facebook Messages

Facebook has the ability to send private messages to other users.  These messages are stored on Facebook's servers, and they also can be stored on your phone.  The file com.facebook.katana/databases/threads_db2 stores messages the user has sent and received, and they are all stored in the table messages.  As before, I'll point out columns of interest.
text: the actual text of the message
sender:  the user who sent the message.  You can use this column to tell if the message was sent or received
timestamp_ms:  the date and time of the message in epoch time
attachments: any attachments with the message.  The attachment may include a link to a photo
coordinates: if the user sent the message using a mobile device and allowed access to device location, the location of the device when the message was sent.
source: whether the message came from a computer or a device or any other source.

Here is an example of the sender field:  {""email"":""20<redacted>86@facebook.com"",""user_key"":""FACEBOOK:20<redacted>86"",""name"":""Mark Lohrum""}.  This field is formatted similarly to the data field in the contacts table as I mentioned above.  You can see a field for email, which is basically the numerical user ID @facebook.com.  You can try sending an email to this address from your GMail; for me, the message forwarded to my email address where I receive Facebook notifications.  But you can see my name in the sender field, so you know that the message in this entry is from me.

You probably noticed above an entry for coordinates.  This entry stores latitude and longitude as reported by the device at the time the message was sent.  Yes, you can determine where a person was, or where their device was, when a message was sent.  That can be rather useful information because you have determined where the device was when a message was sent at a specific time.  If you can be sure that the user and not another individual was holding the device and sending the message, then you know where the person was at a specific time when sending a message.  Note, on Android it is very easy to spoof location.

Cached Images

The Facebook app stores a whole lot of data on the device.  Much of this data is cached images.

For example, on my device, there is a file com.facebook.katana/cache/image//v2.ols100.1/99/8vNUdrezcgt0__oST83Rc5g0QIE.cnt.  (I don't know what the .cnt extension means, but all of the cached images have this extension.)  Obviously there is no context in this filename what the file is, but the file was 102 KB so I was interested.  Here is what the file looks like in a Hex editor:

You can see that the file header includes JFIF, so clearly this is a JPG file.  I renamed the file to include a .jpg at the end and opened it as an image and here is what I found:

Yes, I am a big football fan.

Now how useful are these cached images?  To be honest, not horribly.  These are images from the timeline that my device saved.  In other words, these are public pictures that a user posted online.  It is not horribly useful, just interesting.

That's all the data I'll cover for now from the com.facebook.katana app.  If there's anything else you would like me to cover, comment or contact me and I'll take a look.

com.facebook.orca data

The com.facebook.orca app is just a messenger app.  Basically there is also a threads_db2 file within the databases directory just like with com.facebook.katana.  These database files store basically the same information, so I won't cover it again.  The important thing to know is that if the com.facebook.orca app is present, the user uses Facebook messenger for Android.

That is all I will cover for now.  Did I cover everything that Facebook stores?  No.  Here's a few more artifacts worth noting that the app stores:

• Facebook posts by the user
• Facebook pictures and videos uploaded by the user
• Places the user has been

Now something I haven't covered yet is important.  The device stores a lot of data, but Facebook is ultimately a cloud service, meaning all Facebook data is ultimately stored on a remote server.  If you are in law enforcement and you need data associated with a user from Facebook's servers and you have a court order allowing access to these records, there is an avenue to get this.  Check out this link for more information.  I am not law enforcement so I have no personal experience in this avenue, but I do know this avenue exists if needed.

Summary

• Facebook stores lots of data on Android devices if the user uses Facebook
• Private messages and personal friend information can be retrieved from the device in an investigation
• There exists a method for law enforcement to retrieve Facebook records should they be needed.  The procedure requires a court order

Questions, comments, suggestions, or experiences?  Walking Dead or college football fan chat?  Leave a comment below, or send me an email.

Viewing SQLite Databases

How to view user data

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

Android apps by default use SQLite databases to store user data.  When you think Android apps, you may think about Netflix and Pandora and ask yourself why you care about user data associated with those apps.  The reason you care about user data associated with apps is because nearly all user interaction with the device is user interaction with an app.  Have you ever made a phone call on an Android phone?  The phone dialer is an app, and that app stores call logs.  Have you ever sent a text message on an Android phone?  The SMS interface is an app, and the app stores text message history.

SQLite is a lite implementation of a Structured Query Language (SQL) database.  I could go into detail about how SQL works and how the file is formed, but I'll skip the low level details and instead focus on Android relevant SQL information.  This post will cover two main topics:

• The locations of SQLite databases, including a few keys ones
• How to read a SQLite database from an Android device

Finding a SQLite database First, Android security prohibits users from accessing the userdata partition, which is where SQLite databases storing user data associated with apps are stored.  You either need an image of the device (and you can create an image using my post on live imaging an Android device) or you need a rooted device.  In this post, I am working from an image of a device.

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

(Note:  some older devices store userdata in a separate location.  I've seen both older Samsung and Motorola devices that have a partition called dbdata.  This partition would store user databases.  But newer devices are pretty standard at this point.  Look to the userdata partition in the data directory first.)

You'll see that within the data directory are directories containing package names.  The directory air.WatchESPN stores user data associated with the WatchESPN app.  The directory com.google.android.youtube stores data associated with the YouTube app.

In fact, let's drill into YouTube for now.  The below screenshot is from the directory /(userdata partition)/data/com.google.android.youtube.

Within this directory, you'll see a directory called databases.  Within the databases directory below ...

.... you can see 14 files.  These files represent the databases associated with YouTube.  I'm willing to bet that the file history.db contains YouTube history.  I extracted this history.db file from the image and opened it in a SQLite browser (more on how to do that below), and I see a table called "suggestions" containing five columns (and in parentheses what I interpret each column to represent):

• _id (an auto-generated id for each entry in the database)
• display1 (the stored search suggestion based off user input)
• display2 (contains nothing)
• query (the actual text the I typed into the YouTube app to search for a video)
• date (epoch date / time stamp of the time I searched for a given video)

Here is a sample row from this database: "1","hobbit battle of five armies trailer",,"hobbit battle of five armies trailer","1406574949951"

• _id in the above example is "1", which I'm going to say is the least recent search in this database
• display1 is "hobbit battle of five armies trailer" is the stored search suggestion based off a search I made.  Apparently I was interested in seeing the Hobbit movie in December 2014 but as of my writing this I have not seen the movie
• display2 is blank
• query is the actual text, which is "hobbit battle of five armies trailer"
• date is stored as epoch time.  1406574949951 correlates to Mon, 28 Jul 2014 19:15:49 GMT, which I converted using an online epoch time stamp converter

Well there you go.  This database file appears to contain the user's YouTube search history, along with the date and time of each search.  Nifty, huh?
I could deep dive into a few other databaes on the device, but instead I'd rather let you, the reader, explore.  So ... if you have an Android device image to explore, check out the following files:

• /(userdata partition)/data/com.android.email/databases/EmailProvider.db
• /(userdata partition)/data/com.android.email/databases/EmailProviderBody.db
• /(userdata partition)/data/com.android.providers.calendar/databases/calendar.db
• /(userdata partition)/data/com.android.providers.contacts/databases/contacts2.db (a bit difficult to parse through this one but incredibly useful)
• /(userdata partition)/data/com.android.providers.downloads/databases/downloads.db
• /(userdata partition)/data/com.android.providers.settings/databases/settings.db
• /(userdata partition)/data/com.android.providers.telephony/databases/mmssms.db (also check out the directory /(userdata partition)/data/com.android.providers.telephony/app_parts
• /(userdata partition)/data/explore the entire com.facebook.katana/databases directory if the Facebook app is installed
• /(userdata partition)/data/explore the entire com.facebook.orca/databases directory if the Facebook Messanger app is installed

As always, if you have any specific questions about how to read user data, such as text messages, call logs, calendar entries, or more, do not hesitate to contact me.
Reading a SQLite database file
In the above section, I showed where SQLite databases may be on the device.  You can find and extract a SQLite database either from a rooted device or from an image of a device.  Now, how do you actually explore the database file?  It is actually incredibly easy.

First, you'll need the SQLite database file extracted away from your image or you rooted device and stored on your computer in a location you will remember.

There are a few Windows and Linux applications to read SQLite databases.  Autopsy also includes SQLite functionality, so if you are using Autopsy to examine an image, you can use the built-in SQLite plugin.  You can read more about using Autopsy to analyze Android images on a previous post on Autopsy.

My personal favorite method of reading SQLite databases is a plugin for Firefox.  I will demonstrate this plugin tool in this post, but if requested I can show other tools also.  The SQLite Manager is a free download for the Firefox web browser.  If you browse to this page page in firefox you can download and add the add-on to your browser.

NOTE: The SQLite Manager add-on is a developer tool.  The intended audience is developers, not forensic examiners.  This tool has the ability to both read and write to SQLite database files.  Now we are working with an extracted version of the file.  This file is extracted from an image or from a device, so the original is intact even if the file you extracted is altered.  If you choose to use the SQLite Manager tool and need to prove that you have not altered data, it would be wise to create an MD5 or SHA hash of the the database file in the original image before extracting and take another hash of the extracted file on your computer after you examine it in SQLite Manager.  Or, if you are in such an environment where using a non-forensic tool is unacceptable, I would personally recommend opening the image of the device in Autopsy and using the built-in SQLite reader to read your database files.

Once the SQLite Manager add-on is installed, open your Firefox browser and go to the add-ons list.  The SQLite Manager will be there.

Click SQLite Manager.  If you have used SQLite Manager before, you may get this annoying pop-up:

I always click on Cancel because if you click OK you open the last opened database file.  Once the add-on is active, click the open icon.  If you browse over the icon, the text "Connect Database hovers." In the choose file window, make sure you view all files instead of just SQLite files because most Android SQLite database files have the extension .db.  Browse to where you are storing your extracted SQLite database file and open it.  SQLite Manager will now show a list of all tables associated with the database.  In the below screenshot, I opened /(userdata partition)/data/com.android.providers.telephony/databases/mmssms.db, which stores SMS and MMS messages.

On the left side of the interface is a clickable list of tables.  Click on one.  I will be exploring the table sms.  The table then opens up so you can see the data stored in this database file's table.

As you can see, I've blacked out data, but there are three columns in the screenshot of interest:

• thread_id (The thread, or conversation.  This ID is a number which references the table "threads" in the same database)
• address (The phone number with which I am texting)
• date (The date in epoch time of the message)

Out of the current screenshot is another column called "body".  This column stores the actual text of the message.  There are other columns which indicate the status of the message (draft, sent, received, etc) and if the message has been read or not (only applicable to "received" messages).
SQLite Manager allows you to export a table.  Check out the drop down menu Table -> Export Table.  You can export the table you are currently exploring as a .CSV file, which you can open in Excel if you prefer that interface.
And that's how to explore a SQLite database.  It is straightforward.  Now have fun browsing around user data!

Summary

• Android stores user data from apps, including phone logs and SMS, in SQLite databases
• You need to pull SQLite files from an image of a device or a rooted device in order to see the contents
• SQLite database files can be viewed using free viewers

Questions, comments, suggestions, or experiences?  Hobbit movie reviews?  Leave a comment below, or send me an email.