Home Archives for December 2013

Daily Blog #191: Let's talk about MTP Part 1

Let's talk about MTP Part 1 by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
If you read last weeks Saturday Reading you would have seen a series of very interesting articles by Nicole Ibriham about MTP device entries in the Shellbags artifact. Many of you may be wondering, well why do I care about MTP? Most of you may think MTP is still relugated to cheap MP3 players/Video players and digital cameras.

Times have changed and in order to get a few things under control with storage space for application and files the Android devs have moved away from Mass Storage drivers and to MTP as stated below:

ICS supports USB Mass Storage (UMS). The Galaxy Nexus does not. This is the same scenario as Honeycomb, as for instance HC supports USB Mass Storage while Xoom does not.

If a given device has a removable SD card it will support USB Mass Storage. If it has only built-in storage (like Xoom and Galaxy Nexus) it will (usually) support only MTP and PTP.

It isn't physically possible to support UMS on devices that don't have a dedicated partition for storage (like a removable SD card, or a separate partition like Nexus S.) This is because UMS is a block-level protocol that gives the host PC direct access to the physical blocks on the storage, so that Android cannot have it mounted at the same time.
With the unified storage model we introduced in Honeycomb, we share your full 32GB (or 16GB or whatever) between app data and media data. That is, no more staring sadly at your 5GB free on Nexus S when your internal app data partition has filled up -- it's all one big happy volume.

However the cost is that Android can no longer ever yield up the storage for the host PC to molest directly over USB. Instead we use MTP. On Windows (which the majority of users use), it has built-in MTP support in Explorer that makes it look exactly like a disk. On Linux and Mac it's sadly not as easy, but I have confidence that we'll see some work to make this better.
On the whole it's a much better experience on the phone.

-- Dan Morril http://www.reddit.com/r/Android/comments/mg14z/whoa_whoa_ics_doesnt_support_usb_mass_storage/c30q93p

You should start understanding MTP by reading Nicole's blog series starting here http://nicoleibrahim.com/part-2-usb-device-research-msc-vs-ptp-vs-mtp/ and then the Wikipedia entry on MTP and ending with AndroidCentral.com's write up on the move to MTP as the new default.

So MTP used to be interesting from a cheap-o storage device forensics view and now is interesting in a hey what did they do with that Android 3.0+ device that they plugged into this system. With Android controlling 84% the market (at the last time I read an article about it) and more devices moving to 3.0 or greater this is something you need to pay attention to and understand.

This week we will go through:
1. What artifacts do and don't exist for MTP devices that you can rely on
2. What accesses to MTP devices look like form shellbags and other sources
3. A place holder for odd things we find along the way.

Also Read:

Let's talk about MTP Part 6

Let's talk about MTP Part 5

Let's talk about MTP Part 4

Let's talk about MTP Part 3

Let's talk about MTP Part 2

Let's talk about MTP Part 1

Sunday Funday Winner by by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
This weeks Sunday Funday must have hit a cord out there as I got many great submissions. Picking a winner when there are multiple great answers is hard and I had to ask for a second opinion from the lab to come to an agreement, they were that good this week.

With that said, this weeks winner is an anonymous submission whose answer shows a depth of experience that I appreciated. They answered the question well and provided some great gotchas to make note of. If you are doing mobile forensics you should read this one and check out the links provided in it.

The Challenge:

You are faced with an Android device where full physical imaging isn't supported by your mobile forensics software provider. What steps would you take to accomplish the following:
1. Locate a safe rooting mechanism
2. Test the rooting mechanism
3. Image the device
4. Manually extract the sms database
5. Parse and export to xls the sms database

The Winning Answer:

Anonymous

Remove the SIM and SD Cards and exploit separately. The SD Card may be encrypted but in my experience very few users enable this.

Place the handset into Airplane Mode and switch off WiFi and BlueTooth.

Attempt to image the device using an off the shelf tool such as the Cellebrite UFED or XRY. We will usually attempt to exploit the device logically initially and then either take a physical image or a file system dump depending on what is supported and whether the device has full device encryption enabled.

If the device won't image using our standard tools we will then move on to other methods. This may be JTAG if the device is supported by the RIFF box and we have permission from the customer to take the device apart or more likely will involve rooting the device.

The best source of information for all things android is the XDA Developers Forums www.xda-developers.com. The forums can be searched for a specific device and then the various rooting options explored.

Rather than use the rooting exploit on the handset being investigated I would first attempt to root another handset of the same model. We are lucky enough to have access to a good library of devices but if this was not the case I would attempt to purchase one, ideally of the same make, model and network as that being investigated. I would then root the purchased handset in order to make sure the process does not unduly effect the data on the device. Only once this has been proved would I use the rooting exploit on the target device.

Once the device is rooted I would ensure that USB Debugging and Stay Awake options are enabled in the developers area of the settings. The developer area is not always immediately visible but can usually be made to appear by clicking around seven times on the Build Number in the About Phone section of the options.

Insert a large SD card into the device boot it up and connect the handset to a machine with the android SDK installed. The Santoku VM, downloadable from santoku-linux.com is a good choice.

The command adb devices will show one device connected if all is working correctly.

Type adb shell in order to gain a linux shell onto the rooted device.

Type the following commands in the shell:

su

mkdir /sdcard/forensics

cp /data/data/com.android.providers.telephony/databases/mmssms.* /sdcard/forensics (this will copy the files required for the SMS investigation. Use * in order to copy the Write Ahead Log files as well as the main sqlite database).

mount (this will show a list of the devices mounted on the various directories of the file system. We are usually interested in the /data directory).

dd if={BlockDevice} of=/sdcard/foreniscs/data.dd (where {BlockDevice} = the device identified above. On my sample phone this was /dev/block/mmcblk0p26.

Ctrl-C (this will exit back to the main PC shell.)

Then use the command adb pull /sdcard/forensics . to pull the image and extracted SMS database back to the investigators machine. Or alternatively just pull the SD Card and connect it using a normal card reader to access the files.

In order to process the SMS databases I would use the epilog tool from CCL forensics as this is the only tool I know of which accurately recovers all the deleted data from SQLITE databases which use a Write Ahead Log. It comes with a number of signature files and these include those for dealing with the android SMS database. Epilog allows for exporting to Excel as well as various other formats.

Updated with Pictures!

Also Read: Daily Blog #184

Artifacts from alternative file system drivers on NTFS Part 4

Hello Reader,
In this series we've explored the POSIX namespace, how the ntfs-3g driver uses it, what default system files use it and the win32 api's interaction with it. Today let's focus on what additional artifacts exist soley within the MFT that in combination with the POSIX namespace let us identify absolutely that a non native NTFS driver wrote to the disk.

To accomplish a unique signature that reflects the actions that ntfs-3g takes when writing to a NTFS volume we need to examine three fields within a MFT file record. If you want to see this in a more interactive fashion watch last weeks Forensic Lunch where we walked through it.

1. Namespace

The Namespace can be one of 4 things that determines the encoding of the filename being stored there.The namespace as we discussed previously will be Posix or File Name Namespace 0. This on its own though does not identify a ntfs-3g written file as we've discussed in this series.

2. LSN

The LSN or Logfile Sequence Number references the most recent change stored within the $logfile. The LSN in a native windows system writing to NTFS has full support for the $logfile and will populate this field to reflect the record entry made. The ntfs-3g driver only updates the restart area and does not populate the $logfile, because of this the LSN value will be 0 for all ntfs-3g written files. If you are looking at a pre vista system then the LSN and Namespace are the only two correlation points you have to identify ntfs-3g written files.

3. USN

The USN or Update Sequence Number references those entries written into the $USNJRNL:$J. We've talked about the USN many times in this blog and hopefully you are familiar with the basic functionality by now. In our testing we were expecting this value to be set to 0 just like the LSN but instead a 64 bit value will be assigned, we are still examining the source to determine the method use in the numbers duration but they do to seem to increase but can be duplicated. The USN values used are outside the range of valid USN Journals that we've seen. The USN number is also the offset into the USN Journal to where that last change has been recorded.

So there we go.
If you are looking at a Windows 2000/XP/2003 system than the Namespace and LSN are your points of analysis to determine if a file was written using the ntfs-3g driver.

If you are looking at a Windows Vista/7/2008 system than the Namespace, LSN and USN fields will determine if a file was written using the ntfs-3g driver.

We haven't tested windows 8 yet but will do so and write a blog to reflect when we have done so and solved what the value used in the USN field means.

Make Sure to Read:

Artifacts from alternative file system drivers on NTFS Part 3

Artifacts from alternative file system drivers on NTFS Part 2

Artifacts from alternative file system drivers on NTFS Part 1

Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
This week an anonymous submitter has won the day, and a 4TB External Hard Drive. It's important to keep track of what changes, especially when it comes to OS's that we may not be dealing with daily yet.This week's answer does a good job at showing some of what's changed but there is more than you should be aware of. Your greatest challenge in dealing with Windows 8 is just getting all your regular tools to run! With all this said here is this weeks winning answer!

The Challenge:
1. Explain the artifacts for execution you can find on windows xp and windows 8

2. For those artifacts that are in the same location for both, explain what differences exist

The Winning Answer:

Program Execution: following are some of the well-known artifacts one may find on Windows XP/7/8 systems along with relevant distinctions across the Windows versions:

Application Compatibility Cache: used to determine issues relating to application comp ability with executables; can use to track executables by file name, size, last modified time and last update time (only in WinXP)
WinXP --> SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatibility\
Win7/8 --> SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatCache\

Jump Lists: unique to versions of Windows 7 and greater, allows users to quickly access frequent/recent selections; can determine first/last time of execution of an application
Win7/8 --> C:\Users\%user%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations

Prefetch: Used by Microsoft Windows for preloading code pages of often-used applications; can use to tell if application had been executed on a system (uses a calculate hash for the directory from where application was ran); may not necessarily be enabled on all systems as there are discrepancies across Windows versions.
WinXP/Vista/7/8 --> C:\Windows\Prefetch

Last Visited MRU: Logs specific executable called by an application for opening files documented in the OpenSaveMRU key; also tracks directory location for the last file accessed by an application.
WinXP --> NTUSER.dat\Software\Microsoft\Windows\Current Version\Explorer\ComDig32\LastVisitedMRU
Win7/8 --> NTUSER.dat\Software\Microsoft\Windows\Current Version\Explorer\ComDig32\LastVisitedPidMRU

RunMRU Start (Run): logs usage of Start -> Run sequence for loading executables
WinXP/7/8 --> NTUSER.dat\Software\Microsoft\Windows\Current Version\Explorer\RunMRU

UserAssist: Tracks GUI-based applications that are launched from the user's desktop in the launcher on Windows systems
WinXP/7/8 --> NTUSER.dat\Software\Microsoft\Windows\Current Version\Explorer\UserAssist\{GUID}\Count
Where GUID can be on of the following:
XP --> 75048700 (Active Desktop)
Win7/8
        --> CEBFF5CD (.EXE file execution)
        --> F4E57C4B (Shortcut file execution)
        --> 6D809377 (ProgramFilesX64)
        --> 7C5A40EF (ProgramFilesX86)
        --> 1AC14E77 (System)
        --> D65231B0 (SystemX86)
        --> B4BFCC3A (Desktop)
        --> FDD39AD0 (Documents)
        --> 374DE290 (Downloads)
        --> 0762D272 (User Profiles)

In addition, one can review Windows Event logs for service related information.
Services Events: log of services that were started/stopped; can also identify services that start on boot (ultimately determine file/executable associated with service); requires reviewing event logs; following are relevant event IDs:
7034 --> service crashed unexpectedly
7035 --> Serve sent a Start/Stop command
7036 --> Service started/stopped
7040 --> Start type changed