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(a)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(a)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(a)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(a)volatilityfoundation.org >>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >> >>

Tom, That does not sound like a fun environment ;) I guess it is a little

than people who still use mdd. (Hopefully no one on this list still uses mdd!). > I don't recall hearing of kntdd before (I might have but it doesn't

> bell), but I'll look at it. I'd have some other things to work out in

It is definitely worth checking out. kntdd is by far the most robust acquisition tool and George is a great guy (and member of this list ;). I will try to dig up the emails. Some of the issue were related to pages missing or being zero'd out. I mentioned it on the Volatility tumblr

was told there was a thread on the Guidance portal. Granted, it was late 2008: "In each instance, users have reported that critical sections of physical memory are being overwritten when a physical memory sample is acquired on certain hardware configurations." HTH, AW _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users