ksanchezcld / volatility

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

Can't read two memory images #223

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

I have had no problem using Volatility to look at memory dumps on several 
systems.  However, I now have two memory images that I can not seem to read.  I 
get the "could not list tasks" error even though a kdbg scan does not show 
multiple addresses.

Here is an example of imageinfo for a memory dump that works fine.  I ran the 
command "volatility.exe -f c:\dumps\filename.dd imageinfo" and got the 
following output:

          Suggested Profile(s) : Win7SP1x86, Win7SP0x86
                     AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (C:\dumps\filename.dd)
                      PAE type : PAE
                           DTB : 0x185000
                          KDBG : 0x83333c28L
                          KPCR : 0x83334c00L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2012-02-20 23:06:05
     Image local date and time : 2012-02-20 23:06:05
          Number of Processors : 4
                    Image Type : Service Pack 1

So, when I run volatility.exe --profile=Win7SP1x86 pslist -f 
c:\dumps\filename.dd" I get my desired output.

However, I have another memory dump that I'm trying to read.  Again, I used 
"volatility.exe -f c:\dumps\filename2.dd imageinfo" and get the following 
output:

          Suggested Profile(s) : Win7SP1x86, Win7SP0x86
                     AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (c:\dumps\filename2.dd)
                      PAE type : PAE
                           DTB : 0x185000
                          KDBG : 0x8372ac28L
                          KPCR : 0x8372bc00L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2012-02-17 00:17:36
     Image local date and time : 2012-02-17 00:17:36
Could not list tasks, please verify the --profile option and whether this image
is valid

Running the command for kdbgscan shows only the 0x8372ac28 address and NOT 
multiple addresses.

And, of course, running volatility.exe --profile=Win7SP1x86 pslist -f 
c:\dumps\filename.dd" gives the error as follows:

Could not list tasks, please verify the --profile option and whether this image
is valid

Any ideas on what I might be doing incorrectly on this image vs other memory 
images that I read with Volatility?  I did try using --profile=Win7SP0x86 just 
in case -- I do know, though, that this memory dump is from a Windows 7 32-bit 
system.

Thanks!

Original issue reported on code.google.com by skier...@gmail.com on 29 Feb 2012 at 8:00

GoogleCodeExporter commented 9 years ago
Hrmmm that's kind of curious that some things come up but items relying on kdbg 
do not.  Normally that would indicate that there is more than one kdbg 
signature, but you have already checked for that.  Unless, maybe the real 
signature were corrupt enough that it does not show up in a kdbgscan... 

Out or curiosity, do any of the "scanning" plugins work (like psscan, filescan, 
etc)? 

Original comment by jamie.l...@gmail.com on 29 Feb 2012 at 9:52

GoogleCodeExporter commented 9 years ago
Filescan works, as does psscan..... strange!

Original comment by skier...@gmail.com on 29 Feb 2012 at 10:01

GoogleCodeExporter commented 9 years ago
One thing you can try is explicitly setting kdbg on command line and disabling 
cache. So add this to your command line:

--kdbg=0x8372ac28 --no-cache 

Let us know if that has any effect?

Original comment by michael.hale@gmail.com on 1 Mar 2012 at 2:17

GoogleCodeExporter commented 9 years ago
Unfortunately, adding the kdbg and no-cache options does not work.  :(

Original comment by skier...@gmail.com on 1 Mar 2012 at 4:21

GoogleCodeExporter commented 9 years ago
Hi @skierrob, 

If you still have these memory dumps, could you re-test reading them with the 
most recent development version of 2.1 alpha? You can check it out with an svn 
client here: http://code.google.com/p/volatility/source/checkout

I'm asking because we've fixed a lot of bugs which might have been the cause of 
the problem, and I remembered you were originally using volatility.exe which is 
a 2.0 build. 

In a perfect world, the 2.1 alpha will work perfectly and we can close the 
issue. If not, we'll think of some other possibilities. 

Thanks!

Original comment by michael.hale@gmail.com on 22 May 2012 at 2:50

GoogleCodeExporter commented 9 years ago
Hi @skierrob, any updates on if you can re-test with a recent volatility 2.1 
build? 

Original comment by michael.hale@gmail.com on 5 Jun 2012 at 8:17

GoogleCodeExporter commented 9 years ago
Hey guys, I'm gonna close this out since it was reported using a 2.0 build and 
doesn't seem like we're able to get back in touch with the user. @skierrob if 
you get a chance to test with 2.1 and still have issues, please feel free to 
re-open. 

Original comment by michael.hale@gmail.com on 6 Jun 2012 at 2:23

GoogleCodeExporter commented 9 years ago
Sorry for the delayed response --  I no longer have access to this particular 
memory image due to moving to a new job so I'm unable to do an accurate test at 
this point.  :(

Original comment by skier...@gmail.com on 6 Jun 2012 at 2:32