It also provides the operating system profile that is given by the examiner to volatility to extract information from the various volatility plugins. The reason for this is likely that volatility, in its current state, attempts to find the kdbg and as soon as it finds a signature match, it uses that location to determine the profile type and other items within the memory dump. (COMMENT: Make sure if you are manually inputting the kdbg offset, you are using the "virtual" location(s), as the "physical" location will not provide good (if any) results) However, the free Moonsols tool produced a memory dump that was unable to be processed with the default volatility settings, as well as being unable to be processed while giving volatility some of the more robust options as well. On the Windows 7 machines, we found, when we used the appropriate profile (Win7SP1圆4 in this case) that FTK Imager and RAMCapture64 created a memory dump that was processed with no issues using volatility 2.3, and my findings were that the paid version of the Moonsols tool produced a dump that was processed with no issues as well. "imageinfo" running for over two hours, with no results = sad panda :( This is likely because of how volatility currently processes the image information scan, which involves some initial kdbg (KdDebuggerDataBlock) searching, as the kdbgscan itself worked fairly quickly on all of the images except for the one created by the free DumpIt tool. 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. *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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |