Daily Blog #214: Let's talk about MTP Part 6

Hello Reader,
        I'm intending for this to be the last blog in the series, at least for now. Today let's look at recovering past interaction with files accessed from MTP devices. You may ask yourself why what we've seen so far isn't enough to determine past interaction, well there are several reasons:

1. Windows 7 (haven't tested other versions at this point) will delete the contents of the WPDNSE directory on reboot.

2. The MFT will only contain those WPDNSE deleted content FILE records until they are overwritten or Defrag runs, which is once a week on Windows 7.

3. Most applications will not make LNK files for the accesses.

4. Most applications will not make jumplists for the accesses.

5. The Shellbags will reveal directories on the MTP devices that were accessed but not the files themselves.

So we are left with two possible source for historical viewing after a weeks worth of time.

1. MRU keys
 No record of any of these files having a MRU entry. This isn't terribly surprising as we didn't find a LNK file or a Jumplist entry for them.

2. USN Journal
The USN Journal is a great source of information here. Since the issues of GUIDs an the like are not an issue you just need to find the MFT entry numbers for the WPDNSE directory, which in my testing was 57374 and then search for all USN entries with a 57374 as the parent entry number.( If this was a real case I would also match the sequence number. ) The following is what comes back:

So now we can see that the Folder GUID '{00000025-0001-0001-0000-000000000000}' was the only directory created within our USN Journal within the WPDNSE directory. We don't have the translation to directory name here, but as we saw in the prior post we can look that up from the shellbags.

Looking deeper and now looking for all files with a parent MFT entry of 57374 which we got from the above screenshot we can see the following files were accessed from the MTP device:

and there we go, all of the files I accessed and the different times I accessed them.

Now if this was an XP system you would be out of luck, so let's hope any MTP analysis you need to do is on Vista/7 or 8!

Tomorrow is the forensic lunch, try to make time to watch it live and ask questions!

Don't miss out on:

 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

Read More

Daily Blog #213: Let's Talk about MTP Part 5

Hello Reader,
         Yesterday we went through the temporary directory that stores files accessed from MTP devices.In our first post in the series we talked about the ability to recover MTP accesses from shellabgs, and if you read Nicole's post you'll see about her ability to recover files accessed from the WPDNSE directory. In my testing, using different applications than Nicole, I could not get a LNK file to be created from any of the following file types:

• docx - MS Word 2010 
• png - Microsoft Media Viewer
• pl - Activestate Komodo
• txt - Notepad

I even checked the office recent documents folder and found no LNK files that pointed to these files, those directories or the MTP device.

I did find an entry in the Windows Explorer Pinned and Recent Jumplist AppID 1b4dd67f29cb1962 looking each jumplist with a hex editor. What was interesting is how different Jumplist parsers handled this entry. I tested this jumplist with two different jumplist parsers.

Tzworks jmp v.25 64 bit did not show the entry

Woanware jumplister provided the following in the 'destlist' entry but could not parse out the entry.

291

1/23/2014 2:44

1/1/0001 12:00:00 AM 1/1/0001 12:00:00 AM ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\\\?\usb#vid_19d2&pid_0307#p752a15#{6ac27878-a6fa-4155-ba85-f98f491d4f33}\SID-{10001,,2410917888}\{00000025-0001-0001-0000-000000000000}

 This is very interesting as the raw hex showed the following providing a translation of the folder GUID to the name of the folder on the MTP device itself.

Here you can see the folder name 'Test' (yes I'm very original in my directory naming) and the folder GUID found in the WPDNSE directory '00000025-0001-0001-0000-000000000000'. This is similar to the shell bags entry Nicole found and TzWorks not successfully parses in v.36 of Sbags.

[1] New Folder; [2] {00000025-0001-0001-0000-000000000000}; [3] Name : New Folder; [4] ObjId : o25; [5] FuncObjId : s10001; [6] UniqueId : {00000025-0001-0001-0000-000000000000}

 It looks like we need to get out jumplist parsing tools to also support the MTP structures that other tools have had to do.

Tomorrow let's talk about what the USN Journal shows us.

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

Read More

Daily Blog #212: Let's talk about MTP Part 4

Hello Reader,
        Let's get back to this series. If you've read Nicole Ibrahim's blog you've already seen most of this data, I'm just doing my own testing to confirm her findings and see what else I find. Today let's look at artifacts of file access from an Android phone using MTP.

I again attached my AT&T Avail 2 and this time opened up the file I copied on to it, shellbags.pl. Following Nicole's research, found here, I went to the WPDNSE directory located under:

"C:\Users\\AppData\Local\Temp\WPDNSE\"

from there I found a folder with the GUID name:

"{00000025-0001-0001-0000-000000000000}"

located under it was the shellbags.pl file I accessed from the phone as expected. There will be one GUID folder created for every folder that a file is accessed from within the MTP device, for all MTP devices accessed. To determine which folder or device this GUID came from you'll have to go to the shellbags. We'll cover that tomorrow and look for other sources of this correlation.

 What was interesting to me that I didn't see Nicole mention was the dates on the file located under the GUID folder. The creation date of the file was set to the time I accessed the file from the phone, not the time the file was copied to the phone.

The modification time of the file corresponded to the original modification date of the file I copied onto the MTP device in the prior test. When looking at the files through the MTP shell extension I notice that only the modification date is displayed in the properties.

I copied a file into the same directory on the Android phone via MTP again, this time with the WPDNSE directory open, but no temporary file got created. So we get artifacts within the WPDNSE directory from file accesses via MTP but not from file copies to a MTP device.

Tomorrow let's look what other artifacts are left from these file copies and accesses.

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

Read More

Daily Blog #198: Let's Talk about MTP Part 3

Hello Reader,

          In the last post in this series we looked at what it looks like if a user attached an Android MTP device to a Windows 7 system. Today let's look at what artifacts are left behind from the directory traversal. On my test system I opened the MTP device, browsed the device, created a directory and copied a file to it.

As you would expect a shellbag entry is made for the directory access, since this is a device it will appear off of the My Computer parent and the shellbag entries will be stored in usrclass.dat. I tried two tools to parse the shellbags and recover the MTP device access, tworks sbag and the shellbags registry module for regripper.

The Tzworks sbag parser has not been updated to handle this resource yet, so a parse of usrclass.dat did not reveal the MTP directory access. The regripper module did find the MTP directory traversal as shown below:

As you can see the device does not have a drive letter, nor is it a network device. Instead the model of the phone (Z992 is the ZTE model for the AT&T Avail 2 I'm testing) is the name of the path from the root of 'My Computer'. From there you can see I traversed down Phone\Android\data and then created a new folder under the root directory Phone and browsed to it.

Also notice that there are no MAC times or MFT file references numbers associated with these entries. MTP is a file transfer protocol not a SMB like file sharing system, explorer is emulating the directory traversal for us so this information is not available through MTP.

Tomorrow let's go through what happens when you copy data to a MTP device and then end on Thursday with accessing data from the MTP device and copying it to the local system.

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

Read More

Daily Blog #193: Let's talk about MTP Part 2

Hello Reader

            In Part 1 of this series we talked about why you should care about MTP and the large amount of devices that will not be utilizing it that run Android 3.0 and greater. Today let's look at the artifacts that the attachment of an MTP device leaves behind. I went to Fry's Electronics today and purchased a ZTE Prelude / AT&T Avail 2 android phone that runs Android 4.1 for my testing. 

I attached the phone, placed it in MTP mode and then explored the phone through explorer and created a directory with a file in it. This is the result of the attachment:

System Registry

DeviceClasses

SYSTEM\ControlSet001\Control\DeviceClasses\{6ac27878-a6fa-4155-ba85-f98f491d4f33}\##?#WpdBusEnumRoot#UMB#2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#

DISK&VEN_LINUX&PROD_FILE-CD_GADGET&REV_0000#P752A15&0##{6ac27878-a6fa-4155-ba85-f98f491d4f33}

• Last write time 1/2/14 22:31:30 UTC

 SYSTEM\ControlSet001\Control\DeviceClasses\{6ac27878-a6fa-4155-ba85-f98f491d4f33}\##?#USB#VID_19D2&PID_0307#P752A15#{6ac27878-a6fa-4155-ba85-f98f491d4f33}

• Last write time 1/2/14 22:31:39 UTC

When I first plugged in the phone a screen popped up on the display defaulting to installing a driver on the PC for syncing. I think this is what caused the first entry to come up as a Linux Cd Gadget. When i then switched it to MTP mode it created the second entry for the MTP device.

The first thing to note here is that the CDROM entry has an associated USBSTOR listing, while the MTP mode does not. MTP mode is not a USB Mass Storage driver and these devices will not be populated into the USBSTOR key.

Enum\USB

SYSTEM\ControlSet001\Enum\USB\VID_19D2&PID_0307\P752A15\Device Parameters
 "%SystemRoot%\system32\wpdshext.dll,-701"

From the value Icons we can see the device is asocciated with wpdshext.dll which is the shell extension that allows me to use the MTP device as if it was a locally attached disk.

From SYSTEM\ControlSet001\Enum\USB\VID_19D2&PID_0307\P752A15\Device Parameters\WUDF we can see the driver is the wpdmtpdriver

"WpdMtpDriver"

You'll also find entries under WpdBusEnumRoot as this is a Windows Portable Device, but I didn't find anything interesting in there yet.

NTUSER.DAT 

Explorer

Under the explorer key you'll find he autoplay handler for the device:

NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\EventHandlersDefaultSelection\WpdDeviceHandler_USB#VID_19D2&PID_0307#P752A15

"MSWPDShellNamespaceHandler"

          Last written time 1/2/14 22:32:01 UTC

This is nice because it lets us know what user was logged in when the device was attached. We need this since MountPoint2 will not be populated with a drive letter as none is assigned.

This value was created when I put the phone in MTP mode and Windows Autoplay asked me how to deal with it, I chose open to view files.


Next in we'll look at the shellbags entries my browsing made and what other artifacts exist from access.

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

Read More

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

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

Read More