Thanks Michael. My whole purpose in this instance was to test the nbdserver
project for my blog post. That's why I used this particular method. I'll
follow up with Jeff and let him know what you came up with.
Thanks!
Ken
On Mon, Apr 15, 2013 at 3:51 PM, Michael Cohen <scudette(a)gmail.com> wrote:
  Ah that explains the crash then....
 You can not read the entire physical address space from start to finish
 because you will hit DMA regions which will cause your reads to activate
 PCI devices and blue screen the box. You must skip the regions which are
 reserved to PCI devices.
 The winpmem device driver allows you to read where ever you want (i.e. it
 does not protect you from shooting yourself in the foot :-). The user space
 application is supposed to figure out where its safe to read. From quickly
 looking at the code for nbdserve
 
https://github.com/jeffbryner/NBDServer/blob/master/main.cpp
 it does not seem to implement the correct algorithm for skipping the
 reserved memory regions (it should make an IO control to the pmem driver
 and ask it). There seems to be some code there to do it but it does not
 seem complete to me. Maybe best ask the author?
 Anyway for the purpose of experimenting you could just manually write a
 short bash script with dd involving the skip and seek parameters to skip
 over the reserved regions and only image the available regions. This should
 not crash.
 If you goal is just to obtain the image over the network, why not use
 netcat like the example demonstrates?
 Thanks,
 Michael.
 On 15 April 2013 22:34, Ken Pryor <kdpryor(a)gmail.com> wrote:
  Hi Michael,
 Yes, I ran winpmem on the subject machine and allowed it to save an image
 file to that machine successfully. In my nbdserver test, I ran winpmem -l
 and verified the service was running. I went to the nbd Linux client and
 began the process of imaging pmem from the subject computer via the
 network. Running nbd-client on the Linux workstation, I assigned the pmem
 output coming over the network to /dev/nbd0. I used the following command
 line then to image:
 dd if=/dev/nbd0 of=./ramoutput.dd
 This has been successful on 32 bit XP machines, but it dies on the 64 bit
 machine. If this description doesn't make sense, I'll try to do a better
 description later this evening.
 Ken
 On Mon, Apr 15, 2013 at 12:16 PM, Michael Cohen <scudette(a)gmail.com>wrote:
  Hi Ken,
    I have not had a chance to play with nbdserver. Are you saying that
 winpmem acquisition to the local disk completed ok?
 Did you manage to image with winpmem over a socket and netcat? Or are
 you trying to image to a network share?
 Thanks,
 Michael.
 On 15 April 2013 18:25, Ken Pryor <kdpryor(a)gmail.com> wrote:
  I recently used the latest version of winpmem in
conjunction with Jeff
 Bryner's nbdserver to acquire ram for a couple different systems in support
 of a blog post I was writing. Acquisition of 1 gb memory from an XP 32 bit
 vm via the network worked perfectly.
 However, acquiring memory from a 64 bit Win 7 physical system with 12
 GB ram failed. It would start okay, but would freeze up and reboot the Win
 7 system at 3.5 GB every time when being acquired using nbdserver via the
 network. Using winpmem directly on the machine works successfully, but
 fails on the network.
 Any suggestions as to the problem? I can provide any data or follow up
 testing if needed.
 Ken
 _______________________________________________
 Vol-users mailing list
 Vol-users(a)volatilityfoundation.org
 
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users