Tracking Drive Letter Assigment (Forensics)

[LzyRgr]

This is a forensics question. I am in dire need of some help.

I have a box of hard drives. I have a Windows XP desktop that has hosted one (or more) of these drives as a second physical drive. I need to be able to prove which drives out of the box (I know for sure one was) were connected (via IDE) to the desktop. Any thoughts on how to do that?

There is some Registry data available but not enough. The file system located \Windows\system32\config makes up part of the Registry [HKEY_LOCAL_MACHINE].

There are two sub-keys of note here:

HKEY_LOCAL_MACHINE\MountedDevices

HKEY_LOCAL_MACHINE\[CurrentControlSet]\Enum\IDE

\MountedDevices contains sukeys for volume IDs (some sort of GUID) and the most recent drive letter assignments. It is only the most recent as you will find many more volume IDs than \Dos\Device\[DriveLetter]: subkeys. The volume ID subkeys can be paired to drive letter subkeys because both will have the matching data in the value field.

HKEY_LOCAL_MACHINE\[CurrentControlSet]\Enum\IDE contains subkeys for hardware that has been attached. Each device has a subkey and there is some sort of logic used in the naming of the subkeys. It appears as if it has something to do with the model number of the physical device then a subkey with some sort of MS naming convention, and the bus id (location:channel:target:lun). Nothing in these keys ties back to \MountedDevices.

I found a file setup.txt in \Windows that lists the physical drives by the name given in HKEY_LOCAL_MACHINE\[CurrentControlSet]\Enum\IDE and a drive letter assignment. Is there a file that records drive letter assignment per device at startup?

Thanks

[allen2]

To my knowledge, you'll need to connect the drives to get their ntfs volume ids (so one for each ntfs partition) then the mounted device key should tell which letter each partition had.

[CharlotteTheHarlot]

I have noticed that WinXP records much more reliably unique information than Win9x did. It uses the drive MFG, Model and Firmware plus a 40 character hash concatenated into what we can call for the purposes of this discussion a unique identifier which is used in these locations under HKLM\System ...

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}\... identifier ...]

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\IDE\... identifier ...]

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Disk\Enum]

"String Value"="... identifier ..."

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\PartMgr\Enum]

"String Value"="... identifier ..."

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SnapMan\Enum]

"String Value"="... identifier ..."

NOTE: There is some variance to the above (it does not appear exactly as shown, the ellipsis '...' is a placeholder for anything) with extra data included such as CLSID and underscores, but the core information should be easily discernible. Also note that ControlSet001 will be 003 or 002 or CurrentControlSet.

The trick is to first obtain the unique information to be expected for each drive in your box. It pays to be very systematic about this, and this means using another different computer to obtain a record of the fingerprint left by each drive by saving a registry export after using each drive, then using WinDiff to compare the registry exports:

- Go to neutral computer and save a registry export #A.

- Power down, Install first of the drives, power up, save registry export #B.

- Power down and remove that drive. power up, save registry export #C.

- Power down, Install next one of the drives, power up, save registry export #D.

- Power down and remove that drive. power up, save registry export #E.

- Repeat this for each drive.

You might notice that there is an extra step in there (removing the drive and exporting the registry before installing the next one), this is intentional in order to minimize registry changes between drive swaps. The goal is to WINDIFF two exports with as few differences to click through (F8) as possible.

The sequence to WINDIFFing these exports would be like this:

#A to #B ... for the 1st drive

#C to #D ... for the 2nd drive

#E to #F ... for the 3rd drive

... etc ...

Catalog these changes carefully into a reference file. As you proceed through each WINDIFF you will get the hang of it, anticipating what to expect for each drive. You should then be able to take this information and using a registry export from the production machine know exactly what strings to search for to correlate what drives were used. You can also determine which drives were used before/after another given drive because the keys will be created sequentially as are the values inside the keys, the export will reflect this and as you proceed through each WINDIFF this will make sense.

EDIT: fixed typos and tried to make clearer

Edited March 29, 2012 by CharlotteTheHarlot

[jaclaz]

\MountedDevices contains sukeys for volume IDs (some sort of GUID) and the most recent drive letter assignments. It is only the most recent as you will find many more volume IDs than \Dos\Device\[DriveLetter]: subkeys. The volume ID subkeys can be paired to drive letter subkeys because both will have the matching data in the value field.

The MountedDevices key lists (in the case of "Fixed" disks) the disk signature AND starting address of the Volume:

http://www.911cd.net/forums//index.php?showtopic=19663

If you have BOTH the machine and the disks, if you can find in any of the DosDevices\*: the disk signature and the starting address of a volume on the disk, you can be confident that EITHER the disk OR an image of it has been mounted on that OS.

Since we are talking of forensics, DO NOT EVEN THINK of connecting those disks to *anything* if not through a write blocker.

The first two keys mentioned by CharlotteTheHarlot will instead assure you that a given device model has been connected and mounted to a given bus.

jaclaz

Edited March 29, 2012 by jaclaz

[dajuad]

Wouldn't the recycle bin on the different drives have files indicating their addresses including drive letter when they were deleted?

Dajuad

[LzyRgr]

Thank you all for the quick responses.

Jaclaz had it. Marrying the 4-byte volume ID in the MBR (decimal offset 440) to the data in the value field for \Dos\Devices\*: in the subkey \System\[CurrentControlSet]\MountedDevices did the trick. That data field is mirrored for the VolumeIDs in the same subkey.

Thanks again.

Dajuad - The info2 files gives you the logical drive letter it was assigned. If you are looking at it, clearly you have the physical device. You could show by the SID assigned to the recycle bin that is resolves to a user account listed in the Registry. I would think that becomes labor intensive if the SID belongs to a deleted account.