Tuesday, August 21, 2007

Vista IR

I recently started doing some testing of IR tools on Vista, using Vista Ultimate (32-bit) installed into a VMWare Workstation 6.0 virtual machine.

Part of my testing involved running some tools on Vista to see how they worked, and another part involved mounting the *.vmdk file for my Vista VM using the latest versions of VDK and VDKWin.

IR Tools
I started off by downloading (via IE7) a couple of tools...specifically Autorunsc.exe and Tcpvcon.exe. Both seemed to work quite well, the only real hiccup being the GUI EULA dialog that pops up if you run the tools without the "/accepteula" switch (either way, the tools create a Registry key...be sure you understand and document this as part of your IR methodology if you're using these tools). An interesting part of the tcpvcon output was the amount of IPv6 stuff visible.

My next steps are to test additional tools, as well as the use of WMI-based tools.

Extracting Files from a Vista VM
Mounting the Vista VM as a read-only file system/drive letter on my XP system went off without a hitch. I was already in the process of updating the VDK drivers and VDKWin GUI files, and on a whim I pointed the mount utility at the Vista VM *.vmdk file. I was pleasantly surprised to see the VM mounted as J:\. As expected, some of the directories (specifically, System Volume Information) could not be accessed...this is due to ACLs on those objects. However, I had fairly unrestricted access to the rest of the file system.

A friend mentioned to me recently that the offsets for the Last Run time and runcount in Vista Prefetch files is different from those of XP. I extracted a Prefetch file from the Vista VM and opened it in UltraEdit to look for the offset for the last run time. I found what appeared to be a FILETIME object at offset 0x80, and modified my existing code to extract those 8 bytes. The result matched up quite nicely:

C:\Perl>vista_pref.pl d:\hacking\vista_autorunsc.exe-7bca361f.pf
Last Run = Mon Aug 20 22:50:43 2007 (UTC)

I also tried running some of the Registry parsing tools (using the Parse::Win32Registry module by James McFarlane) against files extracted from the Vista VM. I started with a Perl script that would parse the contents of the UserAssist key - here's an extract of the results:

C:\Perl\reg>pnu.pl d:\hacking\vista_ntuser.dat
LastWrite time = Mon Aug 20 22:53:02 2007 (UTC)
Mon Aug 20 22:53:02 2007 (UTC)
UEME_RUNPIDL:%csidl2%\Accessories\Command Prompt.lnk
Tue Aug 14 18:47:55 2007 (UTC)
Wed Jul 11 20:37:27 2007 (UTC)

That seems to work quite nicely! It looks like I won't have any trouble accessing the raw Registry files using James' module, at least not on 32-bit versions of Vista, so that's good news!

There's still more testing and analysis to do, but this is a good start!


Anonymous said...

Yes, I've noticed the annoying GUI EULA dialogue with the Sysinternals tools. In fact, it was initially when I was trying to use your methods of collecting volatile data (pages 48 to 53) in your book. I thought there was an error because the batch file simply "hung". I looked at what the tools were actually doing and user input was required.

H. Carvey said...

Use "/accepteula" at the command line...and remember that a Registry key will be added.

Anonymous said...

Sure thing. I recall reading that some of the Sysinternals suite haven't been updated to accept the switch. Those updated after November 2006 have. If one of these is needed, I guess the way would be to use reg.exe or regedit.exe (depending upon the system under investigation) in the batch file to make the registry change(s) manually.

H. Carvey said...


Sorry, my friend, but I'm completely missing your point here...I'm sure I don't see why you'd suggest making the Registry changes manually.

I mention this as something to be aware of...test your tools, use the appropriate switches, and document the effect that the tools have on the environment.

Anonymous said...

If the /accepteula switch isn't available in a tool and I try to run it from a batch file, the batch file will "hang", waiting for me to accept the GUI EULA and that defeats the object of having a batch file for automation. The EULA can be "pre-accepted" by the appropriate registry setting which can be made via reg.exe or regedit.exe.

H. Carvey said...


That makes more sense...but I'd suggest at that point that you find another tool that doesn't require a EULA... ;-)

Anonymous said...

Agreed - but I'm new to the field (as a hobby) and am following the examples in your books. When I've "got my feet wet", I might be in a position to explore other tools.

Anonymous said...

I started doing research on the types and format of the UEME_ strings in the UserAssist registry keys.

And some point, I wanted to see which new types have been added in Vista, so I took a look at the DLL. Big surprise, there are no new types, but a lot less! These are the only types I found:


So types like UEME_UIQCUT (Quick Launch shortcut), UEME_UISCUT (desktop shortcut), UEME_RUNCPL (control panel), ... are simply gone.

For example, launch the Power Options control panel. On XP, you'll see an UEME_RUNCPL entry referencing powercfg.cpl. While on Vista, you'll see an UEME_RUNPATH entry referencing control.exe

So in Vista, we know the user launched a control panel application, but not which one!

I'll put up a blogpost when I've done more research into this.

H. Carvey said...


Thanks, I look forward to seeing it.

ForensicZone said...

Any luck finding some tools for copying Vista RAM on a live machine?(not counting .VMEM!!!)

Rick at ForensicZone.com

H. Carvey said...


Any luck finding some tools for copying Vista RAM on a live machine?

Sure. For about a year, I've used Garner's kntdd/knttools...first as a beta tester, and then after purchasing my own copy.

ForensicZone said...


UEME remnants can also be found in some of the RAM dumps I’ve been looking at except they are in ROT-13. ( UEME = HRZR). Trying to figure out how this can help us.

Rick at ForensicZone dot Com

H. Carvey said...


Great post!

I'm not sure that Registry values would necessarily have a forensic value, unless you could isolate the process to which the memory pages belong. I've been thinking, however, that Event Log records, and Registry keys, both of which have timestamps, could be extracted from a memory dump and possibly used with great effect.