shimcache plugin

[GoogleCodeExporter]

I'm submitting another plugin to add to the code base.  This plugin relies on 
RegistryApi from issue 240.  Let me know if I need to make any changes :-)

Original issue reported on code.google.com by jamie.l...@gmail.com on 6 May 2012 at 1:55

• Blocked on: #240

Attachments:

• shimcache.py

[GoogleCodeExporter]

Original comment by jamie.l...@gmail.com on 6 May 2012 at 1:57

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Sure, looks awesome Jamie!  5:)

There's a lot of profile modifications flying around, I just wanted to check 
that there really are differences in every single os/arch combination?  For 
instance, ShimRecords seem to be shared across arch, and possible across 
2003/Vista, if it works out shorter to pull those out and condense them, then 
I'd prefer to do that.

It would be best to provide a size for the ShimRecord objects.  If we don't 
know it, or it changes, then at least put in a size that includes the start of 
the last element explicitly stated in the structure.

Lastly please we could we use debug.error("No ShimCache data found") over 
print/return?

After those, I'm very happy for it to go in (and the RegistryApi module) to 
volatility.plugins.registry.  I think I still need to check the other two in 
issue 241, but I'll get on those now...  5:)

Original comment by mike.auty@gmail.com on 6 May 2012 at 1:06

[GoogleCodeExporter]

Oh, also, given that the registryapi is now a stand-alone object, there's no 
real need to inherit from it and call the init.  You could just construct a new 
one and start using that, and you can do that in calculate or where-ever it's 
most useful, rather than requiring a new __init__ function for every object 
that wants to use it.  Choosing multiple-inheritance seems a bit like overkill, 
but it's your choice, however you find the API easiest to use let's go with 
that...  5:)

Original comment by mike.auty@gmail.com on 6 May 2012 at 1:29

[GoogleCodeExporter]

Thanks for taking a look, Mike!

I think I just inherited registryapi because that was what was mentioned in 
issue 240.  I'm happy to do it either way ;-)

The differences in "ShimRecords" is slight between different OS's, because of 
the array of "Entries" where the entry definitions are different.  I'm not sure 
if there's a better way to do this, but if you have a suggestion let me know :-)

Original comment by jamie.l...@gmail.com on 6 May 2012 at 6:43

[GoogleCodeExporter]

Yeah, my bad, I thought it used some of the existing members of the plugin, but 
since it's effectively just a function holder, we may as well make one when we 
need it.  If you're happy for me to do so, I'll push the registryapi in and 
then tweak the shimcache plugin not to do multiple inheritance and push that in 
after it.  Sound ok to you?

Original comment by mike.auty@gmail.com on 6 May 2012 at 7:05

[GoogleCodeExporter]

Sounds awesome!  Thanks, Mike! :-)

Original comment by jamie.l...@gmail.com on 6 May 2012 at 7:06

[GoogleCodeExporter]

Ok, all, checked in.  The tweaks I added were hopefully pretty minimal:

* there were only 3 base shimcache entries (XP, 2003/vista, 7), so I had them 
all point at a generic "AppCompatCacheEntry", which is then added by the 
specifc ProfileModifications (which should reduce duplication errors, etc).
* Changed the prints to debug.errors.
* Changed registryapi to an object rather than inherited.

There were a few more changes in the registryapi, but I'll document those in 
issue 240.

Original comment by mike.auty@gmail.com on 6 May 2012 at 11:21

• Changed state: Fixed