Steve,
Very good! I was probing to see how much folks had learned and picked up… you're synopsis of what needs to be done is excellent. I've written similar explanations before and simply gotten tired of rewriting it over and over (someone could do a search on FF…hint, hint…) and decided to include it in my next book.
Here's the process in a nutshell
1. The enum\USBStor key (note to all I sincerely hope that everyone knows how to determine the current control set from just the System file and don't rely solely on the EnCase enscript) contains subkeys that are the device class IDs. You can search for these IDs in the setupapi.log file to see when the devices were *first* connected to the system.
2. The device class IDs contain a subkey for each device in that class, and that is a unique instance ID. The unique instance ID may be the serial number located in the device's device descriptor (you can view this with UVCView from MS, and no, it is not part of the memory area of the device). If the device doesn't have a serial number, the PnP Manager creates one, with a "&" as the _second_ character.
3. The unique instance ID key has a value called "ParentIdPrefix". Thumb drives will have this value, as will iPods and digital cameras. Fixed, external HDDs don't.
4. You can use the ParentIdPrefix to map a thumb drive to the drive letter to which it was mapped under the MountedDevices key.
5. You can use the serial number to map to the appropriate DeviceClasses subkey to see when the disk device was last connected to the system. You can also use the ParentIdPrefix value to map to the volume device and get the same info.
> …..previous control sets might show the same device having been assigned a different drive letter at some point.
This is true, particularly if multiple devices have been plugged into the system. This is why we use the ParentIdPrefix to map to the drive letter. Also, this is true, as well, for XP System Restore Points.
> I guess this is why we still go on training courses so that people can
> show us rather than type in some instructions. I was shown the method
> of marrying up drive letters to devices and it still wasn't all plain sailing.
I guess it depends upon the training. I'm giving a Windows forensic pilot in a couple of weeks and we go into this in detail…but not using EnCase. I want everyone to understand *how* this is done, and not be dependent upon a particular tool. That way, you not only understand it, but you understand things when they're different.
HTH,
Jerry,
I found Nathan's paper on LNK files…where's his white paper on USB devices?
Thanks,
Harlan
Hmmm, you are correct. I was thinking of Nathan's LNK files paper…
ah, okay. I thought I'd missed something.
Thanks,
H
Hi Harlan,
When you say this here
<note to all I sincerely hope that everyone knows how to determine the current control set from just the System file and don't rely solely on the EnCase enscript>
Do you mean by using the values specified in
HKEY_LOCAL_MACHINE\SYSTEM\Select ?
Is this the same across all Windows OS'es?
elmurado,
For Windows NT and up (ie, 2000, XP, 2003, etc), yes, those are the same values for all versions.
You'd be surprised at the number of folks who do forensic analysis of Windows systems but don't know this.
H
I wouldn't and am not. Just last week I was on the opposite side of another analyst in a case in court.
This guy had a great pile of "facts" that his software, in this case FTK had located. Unfortunately he didn't 1) know how FTK had located or "proved" these fatcs, and 2) he tried to pin the "facts" on a particular user when in fact he couldn't. His (lack of) knowledge and practice of the internals of Win ultimately made his testimony worthless and actually harmful to their case.
Deckard,
Do you see this a lot? I've had engagements where I've worked with other analysts and they simply had no idea…in most cases, they were *nix gurus.
I can't say that I've ever encountered someone who had the guts to stand up and state (or testify to) facts that they could not explain. No, wait…I take that back… 😉
H
It seems I see more of it every day, and not really in court. That case was the first I have seen someone try to testify to things they couldn't begin to explain.
However, there are more and more poeple hanging out a shingle as a forensic analyst or incident responder whose only knowledge is that they know how to use <at least to a functional level> a software app like EnCase, FTK etc.
But they can't explain the internals of Windows, and they rely on info posted on forums like these to locate things in the registry etc.
Now, nothing wrong to ask for and receive help, i do it all the time, BUT I then experiment and prove the advice I got works, and that I can explain in detail how and why it is proof.
Somehow in this country we have started to confuse EVIDENCE with PROOF. It's not enough to find an artifact, you must be able to show wheer the artifact came from, and you must be able to show it couldn't have come from somewhere else.
Deckard,
I think in the UK there are a mix of those that know and those that have been trained.
I, like a lot of other people sometimes need to learn something new for a new case, i.e. where a piece of software I have never encountered before has been used. The key is testing for yourself if you aren't sure and not to rely upon literature, advice from others or open source research. Even with this approach old knowledge has to make way in my brain for new things and old stuff can get forgotten.
They do say it's like riding a bike (remembering an old skill/talent/piece of knowledge), only in my case I am not very good on a bike anymore!
Steve
Thanks Harlan. When doe sthe book come out? Is it a completely new one or is it an update to your current book? (Sorry to kind of hijack the thread).