freddierice / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

General problems with large sizes of memory dumps 12 GB and more #253

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
All commands of Volatility Framework 2.1_alpha fails.

I'm using Windows 7 SP1 X64 Ultimate (CPU Intel Core i7 2670QM)

I tried several memory dumps from different pc's with installed Windows 7 SP1 
64 Bit,  but only dumps over 10 GB may be have a problem.

Here any samples:
-----------------
The Filessize of Win7-64-Bit.dmp is 12 GB

E:\Debugging\Volatility-64Bit>vol.py -f Win7-64-Bit.dmp --profile=Win7SP1x64 
pslist
Volatile Systems Volatility Framework 2.1_alpha
 Offset(V)  Name                 PID    PPID   Thds   Hnds   Time
---------- -------------------- ------ ------ ------ ------ -------------------
0xfffffa8009d3f040                           0      0      0 ------ 1970-01-01 
00:00:00

E:\Debugging\Volatility-64Bit>vol.py -f Win7-64-Bit.dmp --profile=Win7SP1x64 
hivelist
Volatile Systems Volatility Framework 2.1_alpha
Virtual     Physical    Name

If you need a Dump, let me know!
Memory is dumped with Win64dd.exe
I hope, that Win64dd works correct on this large size.

Oh and i think you know: netscan doesn't work for me on all of my Window 7 - 64 
Bit systems.

Sincerely Holger  

Original issue reported on code.google.com by Fa.DEM...@googlemail.com on 13 May 2012 at 5:57

GoogleCodeExporter commented 8 years ago
Hi Holger, 

Sure, is there a place you can upload the memory dump so we can access it? Its 
not a size thing per-se, as we've analyzed dumps that are 30-40 GB before, so 
there must be something else going on, but we're glad to help track it down. 

Thanks!

Original comment by michael.hale@gmail.com on 13 May 2012 at 6:01

GoogleCodeExporter commented 8 years ago
Ups, can you change the title for me?
There is a typing error and i meant dumps and not mumps..lol

Original comment by Fa.DEM...@googlemail.com on 13 May 2012 at 6:02

GoogleCodeExporter commented 8 years ago
Ok, i'll upload on our server (archived with WinRAR) and then i'll post the 
download link here.

Thank's a lot for your help.

Original comment by Fa.DEM...@googlemail.com on 13 May 2012 at 6:12

GoogleCodeExporter commented 8 years ago

Original comment by mike.auty@gmail.com on 13 May 2012 at 7:19

GoogleCodeExporter commented 8 years ago
Upload finished.
Mail with download - link sent to you

Thank's again
Holger 

Original comment by Fa.DEM...@googlemail.com on 13 May 2012 at 9:55

GoogleCodeExporter commented 8 years ago
Holger, I got the memory dump, so you can go ahead and delete it. Thanks. 

@devs, I'll let you know what's going on after I take a look. 

Original comment by michael.hale@gmail.com on 14 May 2012 at 1:13

GoogleCodeExporter commented 8 years ago
Hey Holger, 

I can't get anything working with your memory dump either. In an effort to 
double check with another tool besides Volatility, I converted the memory dump 
to a crash dump with Moonsol's bin2dmp.exe (from the same package as Win64dd, 
the professional version). It converted OK, but when I tried to open the 
converted file in windbg I got the attached error messages. In short, windbg 
was able to identify it as Win7SP1x64 but failed to list any processes or 
kernel modules due to "possible paged-out or corrupt data." When I tried 
!analyze -v in the debugger, it indicated some driver crash:

GetContextState failed, 0xD0000147
GetContextState failed, 0xD0000147

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x4D415454 

If you see the Bugcheck str, 0x4D415454 is MATT in ASCII, which is the name of 
the win64dd driver author. He likes to put strange identifying strings in crazy 
places, so most likely the acquisition driver caused a crash of some sort, thus 
leading to a corrupt memory dump. 

So unfortunately I cannot help much more, but you may have better luck with 
another acquisition tool. See 
http://www.forensicswiki.org/wiki/Tools:Memory_Imaging for some other options. 
Typically we recommend Kntdd but its one of the commercial ones. 

Original comment by michael.hale@gmail.com on 14 May 2012 at 4:19

GoogleCodeExporter commented 8 years ago
Oh sorry, here's the attached windbg output. 

Original comment by michael.hale@gmail.com on 14 May 2012 at 4:32

Attachments:

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Hey Michael,

that sounds very strange for me, because i tried win64dd on 4 other Win7 64 bit 
systems without any problems.

Only on my ASUS Notebook with 12 GB of memory, i got this issue.

I tried another tool before (Redline and Memorize from Mandiant), but that 
generated a Bluescreen on this machine.

Mandiant says, the machine which are used for analyzing must have more memory 
than the dumped memory, so i can't use this tool on this machine.

Normaly i would say, "MoonSols" must fix their tool. Maybe, that's fixed in the 
comercial version.
Otherwise this tool doesn't work on all machines correctly.

Thank's a lot for your analyze and i'll try to test with another tool.
If there a link to KNTDD? I would like to get the price of this tool.

Greetings,
Holger

Original comment by Fa.DEM...@googlemail.com on 14 May 2012 at 12:15

GoogleCodeExporter commented 8 years ago
Hiya Holger,

I'm going to mark this bug as invalid, simply because it appears to be an issue 
with the memory acquisition software, rather than in volatility itself.  Do 
feel free to reopen the issue if you feel it isn't fixed.  MHL will still be 
able to respond here, it's mostly just to clear the issue off our todo list.  
Hope that's ok...

Mike

Original comment by mike.auty@gmail.com on 14 May 2012 at 12:50

GoogleCodeExporter commented 8 years ago
No Problem Mike,

To relieve the board here, I can communicate well in advance with Michael via 
email.

Only when it again volatility and concern for your development should be 
interesting, I'll write something about it here again.

Thank's a lot to all for your great job here!

Holger

Original comment by Fa.DEM...@googlemail.com on 14 May 2012 at 1:42