On all of the memory dumps, regardless of the tool that was used to create the dump, the "imageinfo" processed the dumps for a long period of time (I finally cancelled the processes after 2 hours, Mari had similar results).
I acquired my system with the paid version of Moonsols DumpIt (v2.0823), the free version of DumpIt (v1.0401), Belkasoft RAMCapture 64, and FTK Imager 3.1.4.6. Mari acquired her memory dumps using the free version of DumpIt (v1.0401), Belkasoft RAMCapture 64, and FTK Imager 3.1.4.6. I had access to one Windows 7 machine with 16GB of RAM, but in order to cover as many bases as possible (as so many of us do), I relied on collaboration (in this case with Mari DeGrazia), who had access to Windows 7 devices with 16GB of memory as well.
#Mobilesyncbrowser alternative 64 Bit#
*COMMENT: The volatility crew released a blog post yesterday that did confirm encoding (not encrypting) does occur in some 64 bit dumps, and the method that your tool of choice uses to create the memory dump will determine if the debug block will be decoded or not. Naturally the findings Takahiro described in his post were concerning since we, as first responders, are often required to gather memory (through a variety of methods) and if Microsoft is * encrypting portions of RAM that will ultimately hamper our analysis, the methods that we use to gather RAM should be adjusted accordingly. A few days ago, Takahiro made a blog post regarding some issues that he discovered while processing a 16GB memory dump on a Windows 7 machine (if you have not read the post, you can find it here).
0 kommentar(er)
