The Future of RegRipper
You may have been wondering why, over the past months, I've been mentioning various plugins (or you may not, I don't know...), but they don't seem to be being released. Well, that's because, in part, that I don't really have a means for doing so other than uploading them to RegRipper.net (again, many, many thanks to Brett for that), and also, I've been working on updating RegRipper to something much more than what it is now.
As an example, I have a test script for the new version of RegRipper working...working fairly well, actually. Here's an example of the output:
C:\Perl\forensics\rr3>test.pl d:\cases\xp\config
Software d:\cases\xp\config\Software
Sam d:\cases\xp\config\Sam
Security d:\cases\xp\config\Security
System d:\cases\xp\config\System
ProductName = Microsoft Windows XP
CSDVersion = Service Pack 1
CurrrentVersion = 5.1
S-1-5-21-1220945662-884357618-682003330-1004
%SystemDrive%\Documents and Settings\Caster Troy
So, I provided the example output so that you could see what's happening, but there are still some things that are happening under the hood. In this example, I've pointed the test script to a directory where I have the Registry hives (SAM, Security, Software, and System) extracted from a sample image (one of Lance Mueller's practicals)...so the script locates the files with the right names, and then checks to see of they're the right type of hive file - that's the first list in the output. Then the script accesses the Software hive file (because now we know that it's a Software hive file) and extracts information about the OS, as well as about user profiles that the Registry knows about.
So know we have a pretty good opportunity for a great deal of automation, don't we? So, I can mount an acquired image via SmartMount, ImDisk, or P2 Explorer (or my app of choice), or access a remote drive via F-Response, or mount a Volume Shadow Copy, and then just point RR at the system32/config directory. Point and shoot...very cool. Now the application has a good deal of information on which to make decisions and choices to control program flow...such as, if the system isn't Windows 2000 or XP, is there any sense in running the ACMru plugin against the user hives? Or, if the system is XP, I may want to run one plugin to get wireless SSIDs, but if the system is Vista or above, I may want to run another plugin.
So, you're looking at the future of RegRipper...well, you're not so much as I am! ;-) For those of you who've already seen the power of RegRipper, and for those of you who've said that using RegRipper reduced what used to take you days into minutes, there's a lot to look forward to!
Speaking of plugins, I wrote another one tonight...svcdll.pl. This one runs through the Services subkeys in the ControlSet marked "Current", and locates all services with a ServiceDll value...many times, these are services run via SvcHost. This is also used by some malware variants...they'll create a service with a random name, and the ServiceDll value will point to a similarly oddly-named DLL. Svcdll.pl gives you a quick look for such things, providing a modicum of malware detection, and hey...it can be run against live systems if you're using F-Response!
As an example, I have a test script for the new version of RegRipper working...working fairly well, actually. Here's an example of the output:
C:\Perl\forensics\rr3>test.pl d:\cases\xp\config
Software d:\cases\xp\config\Software
Sam d:\cases\xp\config\Sam
Security d:\cases\xp\config\Security
System d:\cases\xp\config\System
ProductName = Microsoft Windows XP
CSDVersion = Service Pack 1
CurrrentVersion = 5.1
S-1-5-21-1220945662-884357618-682003330-1004
%SystemDrive%\Documents and Settings\Caster Troy
So, I provided the example output so that you could see what's happening, but there are still some things that are happening under the hood. In this example, I've pointed the test script to a directory where I have the Registry hives (SAM, Security, Software, and System) extracted from a sample image (one of Lance Mueller's practicals)...so the script locates the files with the right names, and then checks to see of they're the right type of hive file - that's the first list in the output. Then the script accesses the Software hive file (because now we know that it's a Software hive file) and extracts information about the OS, as well as about user profiles that the Registry knows about.
So know we have a pretty good opportunity for a great deal of automation, don't we? So, I can mount an acquired image via SmartMount, ImDisk, or P2 Explorer (or my app of choice), or access a remote drive via F-Response, or mount a Volume Shadow Copy, and then just point RR at the system32/config directory. Point and shoot...very cool. Now the application has a good deal of information on which to make decisions and choices to control program flow...such as, if the system isn't Windows 2000 or XP, is there any sense in running the ACMru plugin against the user hives? Or, if the system is XP, I may want to run one plugin to get wireless SSIDs, but if the system is Vista or above, I may want to run another plugin.
So, you're looking at the future of RegRipper...well, you're not so much as I am! ;-) For those of you who've already seen the power of RegRipper, and for those of you who've said that using RegRipper reduced what used to take you days into minutes, there's a lot to look forward to!
Speaking of plugins, I wrote another one tonight...svcdll.pl. This one runs through the Services subkeys in the ControlSet marked "Current", and locates all services with a ServiceDll value...many times, these are services run via SvcHost. This is also used by some malware variants...they'll create a service with a random name, and the ServiceDll value will point to a similarly oddly-named DLL. Svcdll.pl gives you a quick look for such things, providing a modicum of malware detection, and hey...it can be run against live systems if you're using F-Response!