Showing posts with label regripper. Show all posts
Showing posts with label regripper. Show all posts

Tuesday, October 7, 2008

RegRipper, regview, and Bluetooth Registry Settings

During DFRWS '08, I thought it might be worthwhile to have an easy way to make RegRipper plugins. In fact, I asked Harlan if he had a plugin generator; back then, he said he just had some templates that provided basis for the plugins. Since then, I've been busy.

Recently, Harlan posted that the v0.40 update for Parse::Win32Registry came with a GTK-perl registry hive viewer. Naturally, I became very interested in modifying James' work to make the RegRipper plugin generator that had been on my mind in August.

To setup shop, I had to get Parse::Win32Registry and checkout this script. Quickly, I realized that there were quite a few dependencies for Gtk2-perl. Once all those were resolved (in a clean XP VMware WS 6.5 virtual machine, it didn't seem to like my host OS instance), I launched up the viewer. First, let me say that it's marvelous. James did a really slick job of programming this UI and his entire perl registry package. Until now, I hadn't looked too closely at its internals, but it's truly great code.

Default regview.pl 0.40 opening SYSTEM hive

Once I got it running, I thought that I only had one thing to do: hack up the UI to enable plugin generation. Well, at first, it appeared that plugin generation was too complicated to use a single template (which was my original idea). I needed to have a good understanding of the current RR plugin features as well as the other programming libraries in-use (GTK2-perl, Parse::Win32Registry, perl). I started writing a small document, in which I articulated the processes of some RR plugins. A lot of the plugins that Harlan wrote were pretty unique, but all followed similar strategies: from a starting registry key, traverse some subkeys, maybe select a few of those subkeys, and find some (or maybe all) values of the subkeys.

So, I thought, why not look at a RR plugin as something that traverses this registry tree with a filter? So, I wrote a special RR plugin that accepts a starting point, depth, a key filter per depth and a value filter per depth (plus one). This special RR plugin was further modularized by extracting plugin specific information to Harlan's %config hash in each RR plugin.

So, now I've got a bare-bone template plugin. From this, I hacked up James' UI (forgive me, at some point in the next weeks I want to remove my code from regview and make my own module). I've added the ability to create a new RR plugin based on a selected key or value. Below is a screenshot of me creating the Widcomm Bluetooth plugin.




Hacked Up regview UI

OK. So, in this SS, I've selected a key (Widcomm) and then from the Generate menu, clicked "from selected key." Next, the Plugin Detail Specification dialog appears. Here, I select an output folder, depth, name and description. Once depth is chosen, we can click on the Modify Filters button to bring up the Plugin Filter Specification dialog. This dialog has a dynamic number of input boxes, depdending on the user-specified depth.

The filter dialog is where the magic happens. From these boxes, a set of perl regular expressions are built within the a new plugin. In this example, I selected the key Widcomm, and would like to get subkeys of Widcomm that start with Devices and LinkKeys. From there, I want to traverse all subkeys. I've specified for all values (other than those from a fourth level subkey) to include all words (perl's \w). The fourth-level subkey value must start with ServiceNameUTF8. A few OKs and:

RR Plugin Created!

What, you don't believe me? :)


btwindcomm RR plugin output

Right now, I've committed my the code to my code page. A tag exists in the soruce tree called tuesday_morning that contains the script and template that you need to get going. There are bugs and I haven't coded proper error handling -- so, you you can break it easily. This Bluetooth demo is the last thing that I've tested, so it is probably broken in other areas. I'll bugcheck Tuesday afternoon and tag a new version on Wednesday.

With regard to Harlan's Bluetooth post, I still have further investigation to perform. Apparantly, there are different Bluetooth stacks., which undoubtedly means different registry keys. I'll play with MS-XP and MS-Vista stuff sometime this week.

In my small investigations of RR plugins, I noticed that the applets plugin could also rip Wordpad's recently opened files, so I updated applets.pl.

That is all for now.

Thursday, July 10, 2008

Registry Analysis #1

Summary:
  1. HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles
  2. I need to read Hobocopy documentation to make it work in Vista x64
  3. If you can't copy a file from a mounted VMDK, try mounting and copying as administrator
  4. Yay -- now I can play with RR

After Harlan posted about an interesting registry entry this morning, I thought of the systeminfo utility. I thought, "I wonder if the systeminfo tool queries the registry for similar information?". So I fired up Process Monitor, set filters for the Registry Event Class and executed systeminfo. Once systeminfo finished, I stopped the capture and searched for systeminfo within Process Monitor. It appears that the systeminfo binary directly queries some registry values and also utilizes WMI. Cool. So I posted a reply to Harlan saying there's some interesting material there. But, I didn't say which entries seemed interesting. Harlan asked me what was interesting, so I went back to look. I found TimeZoneInformation and some network adapter information (both of which were covered by RR plugins). So I tried to find something that wasn't in RR, and I think I did:

Paging File Location
(HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles)
Information: here ... this value is a REG_MULTI_SZ in Vista rather than the REG_BINARY as listed inthe MS article.
Significance to RA: If the page file is not in the default location \pagefile.sys, you'll want to know where it is.

The systeminfo utility also reports tidbits like patch levels; however, I'm not sure (yet) if this is listed in the registry.







The remainder of this post shows some of my experiences in registry hive acquisition (summary items 2-4)

Until now, I did not think that I had an easy way to get access to registry hives. Before tonight, I tried mounting a vmdk on my desktop with VMware Workstation's drive mapping feature so that I could simply copy the hives, but that failed:




I figured the file was just locked or something -- and a while ago, I stumbled upon a post that mentioned using VSS to copy a file that is in use but I shrugged it off because they didn't have Vista binaries. Well, I just searched and there's an open source project! Its called HoboCopy (enter chuckle about my scripting issue).

So, I downloaded hobocopy for vista x64 and executed it:


I missed the Visual Studio 2008 libraries dependencies (vcredist_x64.exe)... Once those were installed, the hobocopy still wouldn't run under my Jason user... so I opened an elevated shell and hobocopy ran fine.

When I tried to change to virtual drive of the VMDK within my elevated shell, the shell explained:

The system cannot find the drive specified.

PowerShell also explained:


I confirmed that the drive was still accessible in my Jason shell (PowerShell background window). It appears I have a user-specific drive letter? Weird...

I really wanted to get hobocopy to copy the system hive, so I went to mount the vmdk with vmware-mount in the elevated shell, but it didn't exist in my workstation folder! I'm assuming this is because I'm using VMware WS 6.5b2.

So I elevated VMware Workstation, mounted the vmdk and tried to copy the file with hobocopy -- it failed. But, I was able to copy the hive file just fine with copy!

Summary:
  • HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles
  • I need to read Hobocopy documentation to make it work in Vista x64
  • If you can't copy a file from a mounted VMDK, try mounting and copying as administrator
  • Yay -- now I can play with RR

Monday, June 9, 2008

Windows FSA Tools

FSA = Forensic and System Administration

I subscribe to Harlan's blog, and recently he has made three separate posts about tools; read them. I was poking around NirSoft (linked from Harlan's blog), and stumbled upon some more tools I feel should be highlighted:

IE PassView: Dumps passwords stored in IE (works with IE7 in Vista!)

USBDeview: Extracts the USB device information stored in the Windows registry from a live system

RecentFilesView: Lists the recently accessed files from a live Windows system

Note: Harlan's RegRipper accomplishes similar feats (usb history, recent files, etc) in an offline fashion, from registry hives on acquired drives or read-only drives.

Note: OpenedFilesView doesn't work on Vista x64

Have fun!