Cachedump/hashdump/lsadump plugin patch

[GoogleCodeExporter]

I've produced a patch for the cachedump plugin (and related files) to work with 
more recent versions of Windows (Vista, 2008, 7, etc). The code is based 
heavily on that from the recent cachedump metasploit module 
(http://lab.mediaservice.net/code/cachedump.rb).

I'm not too familiar with the Volatility code or coding style, which means 
there are a couple of bad hacks in there, but these are clearly marked so this 
code should hopefully be able to be integrated without too much hassle. The 
code should (hopefully) work on the most recent version.

Any questions let me know.

Original issue reported on code.google.com by d...@noxr.net on 7 Mar 2011 at 11:33

Attachments:

• cache_dump.diff

[GoogleCodeExporter]

Wow, that's brilliant, thanks!  5:)  I'll try and have a read through it in the 
next couple of days, and see if there's a smoother method for the areas you've 
flagged up.  

Original comment by mike.auty@gmail.com on 7 Mar 2011 at 11:45

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

[GoogleCodeExporter]

Hiya,

So I've had a chance to read over your patch, and I've got a few comments to 
help with the areas you thought were nasty hacks (and, to be honest, they 
were).  5:)  I haven't had time to fix them up yet but they mostly seem to 
revolve around figuring out what's an XP image and what isn't (there's a typo 
where false should read False, but otherwise they're about XP/Vista 
differences).  5:)

So the way I'd recommend handling this is to create a VolatilityMagic object 
which contains the data needed for a specific profile.  This should be 
inherited from profiles as the operating systems develop, but you might have to 
plug it into each profile.  I haven't precisely determined the best way for 
standard plugin developers to do this, but since you're already adding things 
to the framework (win32.*), I figure it's ok to change the base profiles too.

Then, once all the profiles know whether they're supposed to hash using AES or 
MD5/RC4, you can simply instantiate a VOLATILITY_MAGIC object from the profile 
and ask it how it's supposed to hash.  For the registry key path change, I'd 
just use a normal VolatilityMagic object with a value of the string that 
changes, but for the functions you can either store the functions as part of 
the profile, or you can just store the method as a string and then use the 
strings to decide.

Let me know if you want to have a go at the changes yourself, or if you'd like 
me to code them up.  I'm happy with either, but I can't say how soon I'll have 
time to get to it.

Hope that's all ok?  Thanks again for contributing, it's really appreciated!  
5:)

Original comment by mike.auty@gmail.com on 8 Mar 2011 at 1:30

[GoogleCodeExporter]

I can certainly have a crack. Will get back to you with an updated patch soon.

Cheers for the input.

Original comment by d...@noxr.net on 9 Mar 2011 at 1:16

[GoogleCodeExporter]

Hiya,

Have you managed to make any progress on this plugin?  Do you need any help?

Original comment by mike.auty@gmail.com on 23 Jan 2012 at 2:36

[GoogleCodeExporter]

We also need to modify this for x64 I believe.  I'm still looking at it, but so 
far it looks as if it is also in need of some work.  I'll add notes/patches as 
can.

Original comment by jamie.l...@gmail.com on 15 Feb 2012 at 10:04

[GoogleCodeExporter]

Issue 340 has been merged into this issue.

Original comment by michael.hale@gmail.com on 31 Aug 2012 at 7:30

[GoogleCodeExporter]

Issue 297 has been merged into this issue.

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 5:04

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 5:04

• Changed title: Cachedump/hashdump/lsadump plugin patch

[GoogleCodeExporter]

Issue 321 has been merged into this issue.

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 5:05

[GoogleCodeExporter]

Issue 393 has been merged into this issue.

Original comment by michael.hale@gmail.com on 27 Mar 2013 at 4:55

[GoogleCodeExporter]

I've tried to find out why hashdump doesn't work with x64.
The reason I found is that there seems to be a bug in the
way volatility works with Registry-Values (affects all
plugins which make use of 'rawreg.values(key)' ).

As a result of 

vol.py -f memdump --profile=Win7SP1x64 printkey -K 
"SAM\Domains\Account\Users\000003E8"

I got the values "F" and "UserPasswordHint" - but no "V"-Value. 
To be sure that the data is in the memory dump (somebody
mentioned that sometimes keys or values are paged out)
I parsed the key manually using hexedit and found everything
where it was supposed to be, including the "V"-Value.

That led me to test other Registry-Keys - whatever key I
tested the result was consistent: only half of the values
are found and displayed. My python skills (or better
programming skills in general) are really weak, so I can
only make an assumption what's going wrong: the offsets to
the values are 4-Byte pointers, in my case that looks
like that:

    60 1D 00 00 E0 1D 00 00 B8 25 00 00

where

    1d 60 00 00 = F
    1d e0 00 00 = V
    25 b8 00 00 = UserPasswordHint

Given the fact that we work with 64bit Memory Dumps,
could it be that the offset to iterate over these pointers
is erroneously taken as the width of a 64-bit pointer
(8 Byte) instead of 4 Byte ? Perhaps that's dead wrong,
but at least it would explain the results ...

I'm sure if one of the developers has the time to look
into that he (or she) can quickly determine whats going
on.

To test the hashdump plugin itself I just replaced the offset
of the F-Value shown above manually with that of the V-Value
(given the fact that the F-Value is not needed) and voila: 

-------------------------------------------------------------
vol.py -f memdump --profile=Win7SP1x64 hashdump -y 0xfffff8a000024010 -s 
0xfffff8a005cbf010
Volatile Systems Volatility Framework 2.3_beta

user:1000:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::
-------------------------------------------------------------

BTW: hash is that of 'password', so no need trying to crack ;)

Original comment by chrish2...@gmail.com on 11 Aug 2013 at 8:45

[GoogleCodeExporter]

interesting...  Thanks for the information chrish2792, I'll take a look at it 
and see I can figure out what's going on.

Original comment by jamie.l...@gmail.com on 11 Aug 2013 at 7:26

[GoogleCodeExporter]

OK, we have rewrites for lsadump and cachedump has also been added back in 2.4. 
 The issue with x64 hashdump is still being addressed.  We've figured out the 
problem, but are still writing up the solution.

Original comment by jamie.l...@gmail.com on 7 Mar 2014 at 4:40

• Changed state: Duplicate

[GoogleCodeExporter]

moving into issue 168 which includes all changes for registry rewrite.

Original comment by jamie.l...@gmail.com on 7 Mar 2014 at 4:41

[GoogleCodeExporter]

fixed in 2.4

Original comment by jamie.l...@gmail.com on 3 Jul 2014 at 7:24

• Changed state: Fixed