I've mentioned this before, and it bears repeating...open source is a very powerful thing.
I recently posted about the AppCompatCache finding that the Mandiant folks shared, and in looking at it, I found that some tools are able to handle 'big data', and some aren't. Specifically, Yaru from TZWorks had no trouble at all letting me view the data, but the Parse::Win32Registry Perl module (the basis for RegRipper) didn't. I did some troubleshooting of the module (thanks goes to the author, James Macfarlane, for providing some useful debugging features) and found that it doesn't address 'big data' at all. I contacted the author, and he said that when developing the module, he hadn't had any issues, nor instances of 'big data'. If you look around on the Internet, you'll see that the first versions of the module were uploaded to CPAN something in 2007, so that wouldn't be too unexpected.
Knowing a little Perl, I was able to locate where within the module the value data is populated from a binary hive file, and I wrote an update to the specific file. I've been doing a bit of testing, and below is some of the sample output:
C:\Perl\forensics\rr>rip.pl -r d:\cases\win7\system -p appcompatcache
Launching appcompatcache v.20120424
Length of data: 228872
Signature: 0xbadc0fee
Win7/2008R2 (64-bit)
C:\Perl\forensics\rr>rip.pl -r f:\win7\system -p appcompatcache
Launching appcompatcache v.20120424
Length of data: 11104
Signature: 0xbadc0fee
Win7/2008R2 (32-bit)
Launching appcompatcache v.20120424
Length of data: 228872
Signature: 0xbadc0fee
Win7/2008R2 (64-bit)
C:\Perl\forensics\rr>rip.pl -r f:\win7\system -p appcompatcache
Launching appcompatcache v.20120424
Length of data: 11104
Signature: 0xbadc0fee
Win7/2008R2 (32-bit)
The code also works equally well with 32-bit Windows XP hives, as well. So, it appears that the update is working well, and I've provided the fix to the module author for inclusion in any updates.
Again...this isn't about a plugin, or RegRipper. It's about how powerful open source can be. Due to the information that Mandiant released regarding this Registry value, it was a simple matter to determine which tools worked in addressing this, and which didn't. For those that didn't, and were open source, a fix or update was pretty easy to develop. Another example of this would include updates to some of the current RegRipper plugins that allow for parsing of MAC addresses. Open source is a great way to fill the gap in capability, going from none to something fully functional in a relatively short amount of time.
I've uploaded a copy of the patch to the module, along with a readme file with instructions for how to install it, here. You can also find it at the RegRipper site that Brett set up, and the module author has also addressed the issue in the code, and will be providing it in the next update, so that the module can be updated much easier...if you're using ActiveState Perl, it would simply be a matter of typing the following command:
ppm install parse-win32registry
Alternatively, you could download the module (as a gzipped tarball) from CPAN (when it's available).
I was very happy to see the information here and in Mandiant's paper. I had been working through the details of the AppCompatCache mystery about a month or so ago and wrote a quick little PS script to pull the data from remote machines. The research you guy's did validates some of the findings I came up with (but was kind of unsure about) as well as fills in the holes I had...info sharing is powerfull. Anyways here's a link to the PS I came up with in case you find it useful: http://pastebin.com/ppm3BGRt
ReplyDeleteI agree with you regarding the power of Open Source expecially when dealing with DFIR. But it seems to me that DFIR-Open-Source is too much few-to-many than many-to-many as it should be to discover/test/understand the huge amount of artifacts DFIR is called to explain. Your efforts could testify what I'm saying: more "few" contributors are needed. Thank you for this explanation and for the patch.
ReplyDelete