MemImager Performs a memory dump using NtSystemDebugControl
Download

MemImager Ranking & Summary

MemImager Tags

memory dump cache image dump pass dump dump permission dump settings dump quant matrice Memory Dump NT System Debug Control Memory Cache data dump editor directory dump file dump Dump information header dump create dump dump content dump folder svnadmin dump command dump account name dump file document dump view memory dump edit memory dump performs Kernel Memory Dump Memory Dump Analyzer dump preferences database Octal Dump analyze heap dump Hexadecimal Dump heap dump dump file debugger Dump EntryPoint Redundance Dump dump resource dump record Access dump . mysql php dump borland delphi 6 avg update 10.0.1424 ODBC Dump ipod usb unknown bz2 compressor dvdstyler 1.8.3 menu cute wallpapers for worktime crack cross fire 1031 xbox 360 mp4 3d chess ubuntu a-law to wav stock index symbian cab 2 ppd screen dump

MemImager Description

The MemImager application was designed to be a tool that performs a memory dump using NtSystemDebugControl. Using NtSystemDebugControl for dumping For control code 10 we use a struct with the following layout as input buffer: - DWORD PhysicalAddress; - DWORD Reserved1; - void *Buffer; - DWORD Length; Next we can for example malloc a page-sized buffer which we point Buffer to, write 4096 in Length, and point PhysicalAddress to the address of the page we wish to copy the contents of. Then we execute NtSystemDebugControl and if all goes well our buffer now contains a copy of the data in the physical page. Quite trivial actually. Inside NtSystemDebugControl To understand if, and if so how, NtSystemDebugControl handles caching issues we have to take a dive into the kernel. The kernel exports the routine called NtSystemDebugControl, which contains a switch statement tasked with dispatching to the correct functionality based on the control code. In the following I will not describe every tiny little detail of the code. The first reason being that there are many details which are not relevant to what we are looking at. Second I have not decompiled the code, but only followed the relevant parts of the disassembly (from a Windows Server 2003 SP0 kernel). The code handling control code 10 calls the undocumented routine _ExLockUserBuffer which makes the pages in our buffer (*Buffer) resident, locks them in memory, and returns (in a pointer passed as a parameter) a system space virtual address pointing to it. Then another undocumented function named _KdpCopyMemoryChunks is called. The parameters passed to it are among others the system space virtual address pointing to our buffer, the number of bytes to copy (Length), and the address to copy from (PhysicalAddress). Now yet another undocumented function is called: _MmDbgCopyMemory. This function performs the actual copying of the data. But before it can do any copying it needs to have a virtual address of the source instead of a physical address. Therefore it calls our last undocumented function: _MiDbgTranslatePhysicalAddress. Now we are really closing in on the answer to our question. _MiDbgTranslatePhysicalAddress receives our physical address as a parameter. It then uses a variable called _ValidKernelPte, which serves as a kind of template for kernel PTE:s. The flags from the template are combined with the physical address to form a PTE pointing to the page we want to copy. Then the PFN database is indexed to find the entry corresponding to our source page. In this entry the kernel looks at the CacheAttribute flags of the u3.e1 member. The CacheAttribute flags are then used to set the PAT index in the PTE. Now we have our answer really, but I will continue a tiny bit further anyway. The PTE the kernel has built is now copied to the location pointed out by the kernel variable _MmDebugPte. Finally, the function returns the virtual address that will use the PTE for mapping. Now _MmDbgCopyMemory is free to copy the data from the physical source page to our buffer using virtual addresses only.

MemImager Related Software