Hey Tom, 

Thanks for the update and helping us investigate issues in the 2.1 alpha branch. It sounds like DumpIt produces dumps from win7 x64 that work with volatility, but FDPro does not -- even though FDPro produces dumps from xp that work with volatility. Is that an accurate summary? 

Did you run FDPro on the same machine as DumpIt? 

Although both tools output a DD-style dump, the way they acquire the memory to put in the dump is sometimes drastically different (for example FDPro has the "smart" feature that probes pages back into RAM etc). So the difference you're seeing is not totally surprising, but the question is - can we figure out what's different in the FDPro dump and somehow account for it. 

If imageinfo says "no suggestions" its because the KDBG scan failed. I'd like to find out if that's because volatility's KDBG scanner is flawed or because the KDBG signatures are truly not present in the memory dump. Hopefully you can use the attached yara ruleset (get yara from http://code.google.com/p/yara-project/) for testing. Use it like this:

$ yara kdbg.yara memory.bin 

My guess based on what I've heard is that you'll get results for the dump produced by DumpIt but not dump produced by FDPro. Can you try that and let us know...then we'll try and figure out the next steps? If the FDPro dump doesn't contain a KDBG signature, we'll have to figure out if its an error in FDPro (failed to acquire that segment) or an error in volatility (perhaps we have an incorrect signature). 

Thanks Tom!
MHL



On Thu, Mar 8, 2012 at 9:37 AM, Tom Yarrish <tom@yarrish.com> wrote:
Ok an update....so I ran the FDPro dump against 2.1 alpha and I'm getting:

Volatile Systems Volatility Framework 2.1_alpha
Determining profile based on KDBG search...

         Suggested Profile(s) : No suggestion (Instantiated with no profile)
                    AS Layer1 : FileAddressSpace (memory.bin)
                     PAE type : No PAE

Now what's odd is the FDPro output is a raw DD image.  And I've run it
against XP machines without any problems in Volatility.

I also did what MHL suggested and ran:

python vol.py -f memory.bin --profile=Win7SP1x64 pslist

and got this (which I was expecting since I didn't get a "response"
from imageinfo):

Volatile Systems Volatility Framework 2.1_alpha
No suitable address space mapping found
Tried to open image as:
 WindowsHiberFileSpace32: No base Address Space
 EWFAddressSpace: No base address space provided
 WindowsCrashDumpSpace32: No base Address Space
 AMD64PagedMemory: No base Address Space
 JKIA32PagedMemory: No base Address Space
 JKIA32PagedMemoryPae: No base Address Space
 IA32PagedMemoryPae: Module disabled
 IA32PagedMemory: Module disabled
 WindowsHiberFileSpace32: No xpress signature found
 EWFAddressSpace: EWF signature not present
 WindowsCrashDumpSpace32: Header signature invalid
 AMD64PagedMemory: No valid DTB found
 JKIA32PagedMemory: Incompatible profile Win7SP1x64 selected
 JKIA32PagedMemoryPae: Incompatible profile Win7SP1x64 selected
 IA32PagedMemoryPae: Module disabled
 IA32PagedMemory: Module disabled
 FileAddressSpace: Must be first Address Space


I'm still going to run some other tests (standard Win7 image, run the
dumps through *nix "version" of Volatility, etc).

Tom

On Wed, Mar 7, 2012 at 4:20 PM, Tom Yarrish <tom@yarrish.com> wrote:
> MHL,
> Sorry I got the same output with both the 2.0 stable and the 2.1 alpha branches.
>
> However, I just ran the imageinfo of the DumpIt DD image on the 2.1
> alpha branch, and I did get output:
>
> Volatile Systems Volatility Framework 2.1_alpha
> Determining profile based on KDBG search...
>
>          Suggested Profile(s) : Win7SP1x64, Win7SP0x64,
> Win2008R2SP1x64, Win2008R2SP0x64
>                     AS Layer1 : AMD64PagedMemory (Kernel AS)
>                     AS Layer2 : FileAddressSpace (memory.raw)
>                      PAE type : PAE
>                           DTB : 0x187000
>                          KDBG : 0xf80002bfe0a0
>                          KPCR : 0xffdff000
>             KUSER_SHARED_DATA : 0xfffff78000000000L
>           Image date and time : 2012-03-07 15:59:22
>     Image local date and time : 2012-03-07 15:59:22
>          Number of Processors : 4
>                    Image Type : Service Pack 1
>
> So that worked.  I'm trying it again with the FDPro dump, which is a
> DD image dump as well.  I'll reply back when I get results from that.
> I'm guessing it should work but we'll see.
>
> My guess (as someone else suggested to me) is I may need to collect
> the memory dumps with EnCase without compression and then either mount
> them with mount_ewf.py or convert them with FTK Imager and test that.
> What's odd is I did a test on a Win7 64-bit machine I have at home
> (E01->DD) and it worked fine.
>
> Thanks,
> Tom
>
> On Wed, Mar 7, 2012 at 3:43 PM, Michael Hale Ligh
> <michael.hale@gmail.com> wrote:
>> Hi Tom,
>>
>> Volatility 2.0 did not support x64 at all, despite its ability to identify
>> the image as Win7SP0x64. That's why you get "Invalid profile Win7SP0x64
>> selected" when using Volatility 2.0. So if you plan to analyze x64 you're
>> best bet is to check out the 2.1 alpha branch.
>>
>> $ svn checkout https://volatility.googlecode.com/svn/trunk/
>> volatility_21_alpha
>>
>> You said below that you've already tried "imageinfo" on your Win7 x64 dump
>> with the 2.1 alpha branch, but I didn't see your output. Could you try these
>> few commands and paste the results?
>>
>> $ python vol.py -f memory.raw imageinfo
>>
>> $ python vol.py -f memory.raw pslist --profile=Win7SP0x64
>>
>> Note that "imageinfo" is one of the few commands that you do not need to
>> specify a profile. For most others you need to use --profile=Win7SP0x64.
>>
>> Let us know if that helps?
>>
>> MHL
>>
>> On Wed, Mar 7, 2012 at 4:18 PM, Tom Yarrish <tom@yarrish.com> wrote:
>>>
>>> Hey all,
>>> So we're moving to Windows 7 (64-bit) in our environment, and our
>>> current method of getting memory images off of machines has changed.
>>> So we're using EnCase Enterprise to grab memory dumps.  Then what I've
>>> been doing is using FTK Imager to convert that to a DD image, and we
>>> run it through our regular tool.  I run the same DD image through
>>> Volatility.  I'm running Volatility on OS X Lion.
>>>
>>> Recently, I've noticed when I'm just doing an imageinfo with
>>> Volatility (both 2.0 and 2.1_alpha), I'm getting the following:
>>>
>>>
>>> Volatile Systems Volatility Framework 2.0
>>> Determining profile based on KDBG search...
>>>
>>>          Suggested Profile(s) : No suggestion (Instantiated with no
>>> profile)
>>>                     AS Layer1 : FileAddressSpace (memory.bin)
>>>                      PAE type : No PAE
>>>
>>> So my first thought was is was an issue with converting an E01 to a DD
>>> image.  So I ran a test on a standard Windows 7 build in our
>>> organization.
>>>
>>> 1) Do a memory collection with EnCase, convert to DD with FTK Imager
>>> 2) Do a memory collection with FDPro
>>> 3) Do a memory collection with DumpIt
>>>
>>> Run the imageinfo command in both Volatility 2.0 and the 2.1_alpha
>>> code, and the results were the same with one exception.  With the 2.0
>>> code, and the DumpIt memory dump, I got the following:
>>>
>>>
>>> Volatile Systems Volatility Framework 2.0
>>> Determining profile based on KDBG search...
>>>
>>>          Suggested Profile(s) : Win7SP0x64 (Instantiated with no profile)
>>>                     AS Layer1 : FileAddressSpace (memory.raw)
>>>                      PAE type : No PAE
>>>
>>> But if I try to run another command with --profile=Win7SP0x64 I get:
>>>
>>> Volatile Systems Volatility Framework 2.0
>>> ERROR   : volatility.addrspace: Invalid profile Win7SP0x64 selected
>>>
>>> I'm just wondering if there's something funky with my Volatility
>>> installation, or if there could be something I need to check in our 7
>>> build that could be causing this.
>>>
>>> Thanks ahead of time,
>>> Tom
>>> _______________________________________________
>>> Vol-users mailing list
>>> Vol-users@volatilesystems.com
>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>
>>