A while ago, I posted on mounting DD images, and I wanted to provide an updated list of some of the tools that you can use to do just that on a Windows systems.

When would you need to use such tools? I like to use tools such as these as in most cases, you can do your analysis whilst goin' commando (sans dongle, as it were), and in many cases, do a great deal more deep analysis than you could using one of the commercial forensic analysis suites. In most cases, it's as simple as mounting the image and using your tools, many of which are CLI and can be run via a batch file. Mounting the image gives you access to most (be cognizant of permissions issues) of the files in the file system without that system being live and without requiring a password to log into the system (as with LiveView), simply because you're not actually booting the system, you're just reading the file structure.

I won't got into any particular detail about these tools, as I want to simply provide them here as a means of identifying those that are available.

VDKWin (free) - Excellent UI for VDK.
ImDisk (free) - installs as a Control Panel applet
SMARTMount (pay) - Andy Rosen's superb mounting utility; requires a dongle, mounts raw, SMART, EWF, SAW, VMWare virtual disk format images, and detects a wide variety of file systems.
P2Explorer (free, requires registration) - Lots of cool features, mounts a variety of formats.
Captain Nemo (pay) - Mounts raw and RAID Reconstructor images from Linux, MS, and Novell systems.

Other similar tools that may be of use:
MKS Software's mount utility
MS's Virtual CD-ROM drive from XP (1, 2, 3)
Mounting ISO images on Vista/Win7
WinCDEmu - mount ISO images

For those of you doing live response, the guys over at CommandLineKungFu posted a great blog on determining information about mounted drives and shares. Some of the tools I've written and provided on the DVD that accompanies WFA 2/e implements similar functionality as the wmic commands that Ed posted, but in most cases going just a bit further.

My first "From the Lab" post will be to address something I see regularly in forums; how does one tie a specific USB-connected device to a Windows system using shortcut (LNK) files, given nothing more than an acquired image to work with? We know that we can extract information about USB devices that have been connected to a system using nothing more than the raw System Registry file...we can get the devices, any drive letters they were mapped to, as well as the date that they were last connected to the system. However, often times we'll have some shortcut files in an image that will point to specific files...images, documents, etc...that we may be interested in, and the drive letter will be F:\ or G:\, or something else that is not part of the system (either as physical or logical drive) that we acquired the image from. So the question is, how do we map the shortcut file to the specific device?

Well, the first thought would be to go to the MountedDevices key and see which devices were mounted as specific drive letters. We know that the binary data for a specific DosDevice entry will contain a reference that looks like "\??\STORAGE\RemovableMedia", followed by the ParentIdPrefix of the device. So, if we have a shortcut file that contains the path "F:\malware.exe", and we know that the device called "\DosDevices\F:" points to a removable storage device, we can then use the ParentIdPrefix value to map back to the USB device found beneath the Enum\USBStor key.

Remember: the ParentIdPrefix value is NOT the device serial number!!

But what happens if you find the multiple USB devices have been connected to the system, and several of them have been mapped to the F:\ drive letter? How do you determine which device was connected when the shortcut was created? Well, to find out, I decided to run a little experiment...

Here's how the experiment works...I plug a GeekSquad 1GB thumb drive into my laptop, and when the drive is created (F:\), I open it and create a shortcut to an application or file on the thumb drive. The shortcut goes on my desktop. This is meant to simulate shortcuts created by files on the thumb drive being accessed/opened, and the shortcut (.lnk) files being created in the Recent folder.

The first thing I did was run secinspect.exe (with the "-n" switch to avoid the hex dumps). As the thumb drive is not a disk, per se, I do not get a disk signature.

Next, I ran ldi.exe, a tool I wrote that is available on the DVD that accompanies my book (located in the ch1\code\Tools directory). This tool implements WMI (Perl source code is available on the DVD, as well) and uses the Win32_LogicalDisk to get the volume serial number from the device (Note: the Win32_PhysicalMedia class returns the manufacturer's serial number for hard drives). Running ldi.exe with the "-c" switch to obtain the .csv format output, I get:

F:\,Removable,,1B360101,FAT,,961.875 MB

Basically, this says that the F:\ drive is identified by Windows (XP SP2, in this case) as being a removable disk, with volume serial number 1B36-0101. The device is formatted FAT, and is approximately 1GB.

Ah, the volume serial number. Very cool! What is the volume serial number, or VSN? The VSN is a value that is calculated, based in part on the current date and time, when the partition is formatted, and added to the boot sector. For all intents and purposes, it should be a unique value, specific to the device, although it can be modified. This Usenet post provides some insight at to how the VSN is created on Win95.

I verified the volume serial number using "chkdsk f:", and got:

Volume Serial Number is 1B36-0101

It is important to note that this experiment is being run against a USB-connected thumb drive, which happens to be formatted FAT. The volume serial number appears to be located in the 4 bytes starting at offset 0x027 within the (first) primary partition. According to the MS TechNet article How NTFS Works, the volume serial number for a partition formatted NTFS is an 8-byte value located at offset 0x48.

The commands "fsutil fsinfo volumeinfo F:" and "vol F:" return the same information as the chkdsk command.

Using a tool based on Jesse Hager's Windows shortcut file format documentation (ie, lslnk.exe found in the ch5\code directory on the book DVD), we see that the shortcut file also includes that volume serial number:

Shortcut file is on a local volume.
Volume Name =
Volume Type = Removable
Volume SN = 0x1b360101

Okay, so far, so good. In most cases, however, you may not have the actual thumb drive available, for whatever reason. So how're you going to map the shortcut file to the specific device that appears in the USBStor key within the Registry? We already know how to map the USBStor key entry to the drive letter that it was mapped to...but that only works if we assume that another device wasn't attached to the system and mapped to the same drive letter at some later point in time. But if you do not have the thumb drive, is the volume serial number useful? It doesn't appear to be so, as the volume serial number does not seem to be stored in any location (key or value) within the Registry that I can locate at this time. This may be by design, as a thumb drive can be reformatted and given a different volume serial number, but be the same device and have the same unique instance ID (serial number from the device descriptor). I even checked the disk_install and volume_install entries within the setupapi.log file, and found no specific reference to the volume serial number at all.

So, as of yet, there does not appear to be any way to map from the info in a shortcut file (ie, drive letter and volume serial number) to the specific thumb drive, without having that thumb drive available. An alternative would be to map time-based information from artifacts (MAC times on the shortcut file, on Prefetch files, associated with other Registry entries) to the time-based information regarding when the device was last connected to the system.

If anyone has any other information that they'd like to share about this issue, it would be greatly appreciated.

Resources:
Windows 2000: Disk Concepts and Troubleshooting
MS TechNet: How FAT Works
Understanding Disk Volume Tracking in Windows 95