Monday, April 09, 2007

From the Lab: Mapping USB devices via LNK files

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

16 comments:

hogfly said...

Harlan,
I wonder if the information is actually left over in the ntuser.dat of the user that formatted the volume?

Keydet89 said...

Interesting...any thoughts on where to look?

hogfly said...

I was going to go ahead and experiment with it a little bit today. No immediate thoughts on where, just a thought that it might exist there.

Keydet89 said...

I'm sure you'll find evidence in the UserAssist key that the MMC associated with the DiskManager was run, but beyond that, what information is usually left over when someone formats a disk or volume?

From my perspective, I don't know of any. I'd like to better understand your thought processes with regards to what you're thinking is in the NTUSER.DAT.

Heath said...

Harlan!

Looking forward to getting a copy of the book. Nice to know you are still out there kicking it up.

Point me to the BEST resources for learning PERL when you get a chance, or do I need to wait to read the book?

Hope it sells millions!

Keydet89 said...

Heath,

Nice to know you are still out there kicking it up.

Thanks. Have we met?

Point me to the BEST resources for learning PERL when you get a chance, or do I need to wait to read the book?

It depends on what you want to do. The *best* resource, IMHO, is the OReilly books, and if you want to go specifically Windows, Dave Roth's books are THE BEST!!

I started with "Learning Perl on Win32 Systems", and moved on to "Advanced Perl Programming". However, I really have to say that most of my really exceptional leaps in knowledge have been from interacting with others, and looking at the code written by others.

Hope that helps!

ME said...

Harlan,

I have seen situations when using EnCase to review the USBSTOR entries I have found that a thumb drive's serial number was reported. When connected to my Tableau USB write blocker, I checked the information reported regarding frimware version, serial number, etc., and sure enough, it matched what was reported by the USBSTOR entry within EnCase.

Of course, this is not always the case, and I find that the more well-known a device is, the better such a correlation exists. For example, my own experience is that for SanDisk thumb drives, more often than not, i have found a match between what the Tableau device reports as a serial number and what is listed within the info displayed within the USBSTOR.

So I guess my point is that is is possible that the serial number is reported by the USBSTOR information, but as there is yet no hard-fast rule regarding this, each vendor is free to do whatever they want, so perhaps it is still at best a case-by-case basis.

Or perhaps you might argue that this "serial number" is vague in that it might be the volume serial number or a hardware/device serial number. This brings up another query:

As long as it matches the evidence I have from within the setupi.log and/or USBSTOR entries, does it matter? a match strongly supports the connection, so does it matter as long as it matches?

This is the heart of the matter, isn't it?

-srobtjones

Keydet89 said...

srobtjones,

"I have found that a thumb drive's serial number was reported"

Yes, I'm sure. I've written about this on numberous occaisions, as well as blogged about it.

"...i have found a match between what the Tableau device reports as a serial number and what is listed within the info displayed within the USBSTOR"

I'm sure...because if a serial number exists for the device, it is in the device descriptor, which means that what is in the USBStor key and what is being reported by the Tableau device is being pulled from the same location.

Reading through the rest of your comment, it's clear that there's some confusion here. What you are seeing in the USBStor key is the device's serial number. This is not a volume serial number. The VSN is the serial number assigned to a volume when the volume is formatted, as referenced by the documentation I've linked to.

Thanks for your comments.

Anonymous said...

Hi Keydet89,

Interestingly, I'm doing something as to what you've blogged. However, I noticed that if the device connected is an external USB drive, the DosDevice entry will not store the string "\??\STORAGE Removeablemedia", instead i see non-ascii values.

This is killing my brain cells as my program will fail to determine if the drive is a removable storage.

You have any ideas or workarounds?

- stardust

Keydet89 said...

stardust,

I'd have to see an example of what you're referring to...

Anonymous said...

keydet89,

Here's a screenshot of the binary value in DosDeviceG when i plugged in my external USB hdd into my host machine:

http://www.flickr.com/photos/21152357@N04/2055535783/

It's not the usual "\??\Storage\..." that we see when we plugged in a thumbdrive.

Cheers,
stardust

Anonymous said...

I had assumed that all USB storage devices connected to the host would contains the "\??\Storage\.." value but somehow, it wasn't the case?

stardust

Keydet89 said...

It's not the usual "\??\Storage\..." that we see when we plugged in a thumbdrive.

From the graphic you posted on flickr, it appears that the system has recognized this device more as an external hard drive, than an a removable storage device.

I have a WD PassPort USB-connected 120GB drive, and it get's recognized in the same manner as you've presented above. I've got some information about this in my book, Windows Forensic Analysis.

Anonymous said...

I see. Let me check out your book first for more information. Thanks! :)

stardust

- George - said...

Its now September 2011, and I am looking at the same issue still, Harlan. I have a situation where I have a number of device images, one being a laptop. I'd like to link the images of the USB flash drives with their volume serial numbers to laptop registry and other file evidence including: (1) specific USB VID/PID/SN values and matching entries in the SetupAPI device logs; then (2) their drive letters; along with (3) LNK shortcuts to files that perhaps were on the removable drive but have been deleted & wiped; and similarly (4) ShellBags information on full paths to files and the removable devices they were once on.

As you summarize at the very end of your post, this may involve a significant timeline analysis and some good fortune, but may not yield an ironclad link between the image and the physical device info.

Has anything popped up on your horizon in the passing years on this matter?

Keydet89 said...

George,

Has anything popped up on your horizon in the passing years on this matter?

I'm not sure what you're trying to get at, as I think that enough information has been developed since I wrote this post to address this issue.

Can you contact me offline at keydet89 at yahoo dot com and let me know a little bit more about what you're looking for? I understand what you're trying to do, but what is it I can do to assist?

Thanks.