RegRipper: Update, Road Map

I thought that, due to some changes in how things were developing with respect to RegRipper, it was time to take a look at a couple of things that had been requested, and to go ahead and include some updates.  After all, RegRipper hasn't been updated in a while...I'm not sure why it would need to be, in particular, as RegRipper itself seems to be doing well.  I'd think that it would be the plugins that need updating, but there were a couple of things sitting scattered about my work bench that I could include in RegRipper.  As such, I opted to break things out into an update for a short-term release, and then include a road map of what I'm looking to do in the future.

**RegRipper v2.5 is posted here, and should be up on the RegRipper site shortly.

Updates - RegRipper v2.5

1. Recompile RegRipper (via Perl2Exe) with the updated version of the the Perl module Parse::Win32Registry, which went to version 1.0 at the end of April.  During some testing and development, I'd found that the version of the module available (v.0.60) didn't support "big data", so I contacted the author and developed my own patch (posted here).  The author responded very quickly and issued an update, which can be downloaded here, as well as installed into ActiveState Perl via PPM, either command line ("ppm install parse-win32registry") or via the GUI.

2. Remove error checking for finding the hive files to that the tools can be run against files within VSCs, via
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyX (see Corey Harrell's blog post).  I ran a test against my own live, running system using the following command:

rip.pl -r \\\GLOBALROOT\Device\HarddiskVolumeShadowCopy13\Windows\system32\config\
System -p compname

I got the following output:
Launching compname v.20090727
ComputerName    = ENZO
TCP/IP Hostname = enzo

This seems to work pretty well.  Thanks to Corey for documenting this technique.  What this means is that spelling something wrong will result in errors that are not the result of the tool itself.

3. Add a GPL v.3.0 license to the tool

In this case, I'm releasing just an updated version of the tool.  The plugins themselves will all continue to work just as they are...none of what was done to the tool itself has any impact whatsoever on the plugins.

RoadMap - RegRipper v3.0
1. Update GUI to allow analyst to point at a mounted image

2. Implement "osmask" value within plugins

The "osmask" value is an 8-bit (little endian) value maintained in the configuration of a plugin, and something that can be read by external programs.  The bits, values, and what they will refer to are listed in the table below:

Bits	7	6	5	4	3	2	1	0
								WinXP
							Win2003
						Vista/Win2008
					Win7/2008R2
				Win8
			Win8Server
	Reserved	Reserved
Values	128	64	32	16	8	4	2	1

As such, a value of "3", expressed as either decimal or hex, would indicate that the plugin is intended for Windows XP and 2003, whereas a value of "8" would indicate that the plugin was intended for Win7 and Win2008R2.  In this way, if the OS version of the target system is known, the application can bypass the plugin, and not run it, logging the reason the RegRipper log file.  This isn't something that the analyst running the tool really needs to worry about, but it does help with questions that I get, such as, "I ran the ACMru plugin against a Windows 7 system, and the result says 'key not found'...why is that?"

I'm also considering doing something similar with a "hivemask" value, which would be similar, except that it would be an "OR" function.  By this I mean that a plugin could be run against the Software hive OR an NTUSER.DAT hive, rather than both.  It's simply a matter of too many moving parts...having a plugin that requires multiple hives would return incorrect information if the analyst didn't include both hives.

This value will have to be added to the plugin by the plugin author.

3. Implement "categories" value within plugins

Adding "categories" to the configuration of a plugin will not only provide more information about the plugin, but also provide a facility for running an entire category of plugins against several hive files at once.

The "category" field within plugins can have multiple entries, comma separated.  When the GUI initiates, it can search through all of the plugins and populate a drop-down box within the GUI with a unique list of the available  categories, from the which the analyst can choose.

This will require that the author of the plugin populate the 'categories' field, and spell the category correctly; otherwise, the misspelled categories will appear as unique choices.

4.  Keep the CLI version of RegRipper (i.e., rip) as is

5.  Produce more plugins, particularly for timeline (TLN) format output

6.  I'm going to reserve the release of RR v3.0 to coincide with an upcoming Registry Analysis course.

Now, I know that there are things that some folks have asked for...such as different output formats.  One of the biggest challenges about this is that those asking for these features really don't have much more than "I want XML..."; they don't provide a style sheet or schema.  For my part, that's a difficult request to work with...the data produced by the plugins as a whole doesn't fit well into a standard schema.  That is, different plugins look for different things and display their results in different ways.

One final thing...if you're using RegRipper in a training course, I'd greatly appreciate hearing/seeing what it is you're providing with respect to the tool.  You're welcome to continue using the tool...I'd simply be grateful to know what's being taught, that's all.