Mapping memory of another process
in [Win32 Kernel]
|
Prev: GetComputerObjectName() fails when called in auto-start serviceat boot time
Next: Windows 2003 Performance vs. Windows 2000
From: "Jeffrey Tan[MSFT]" on 18 Sep 2006 02:32 Hi Arno, Yes, ZwMapViewOfSection/NtMapViewOfSection are the native APIs, which are exported by both user-mode ntdll.dll and kernel-mode ntkrnlpa.exe. You may use the following 2 commands to verify this: dumpbin /exports C:\windows\system32\ntkrnlpa.exe>C:\ ntkrnlpaexports.txt dumpbin /exports C:\windows\system32\ntdll.dll>C:\ ntdllexports.txt Yes, we can map the physical memory to the current process virtual space through PhysicalMemory kernel object and ZwMapViewOfSection/NtMapViewOfSection. However, the key point of the issue is that we have to find out the physical memory address of another process we want to map. Normally, what we know is the virtual address of another process we want to access, however, we have to switch the process context to another process to translate the virtual address into the real physical memory.(Note: the process context is all about virtual-physical address translation, that is loading the page directory and page table of a process). This task is unavailable from user-mode API. Another point is that the translated address may not reside in the RAM, but in the page file disk. Another approach of doing your task is creating a remote thread in another process. Let's say this remote thread loads an injected dll in that process. In DLL_PROCESS_ATTACH notification of the inject dll, you may explicitly call CreateFileMapping/MapViewOfFileEx to share the memory address of that process. Then in your application, you may manipulate this shared memory in your memory address now. I did not compare the performance between this approach and the ReadProcessMemory/WriteProcessMemory solution. However, if you have a lot of read/write frequency, the inject approach should provide a better performance. This CreateRemoteThread/LoadLibrary approach is first introduced by "Jeffrey Richter" in MSJ 1994. You may refer to the article below for the technical details: "Three Ways to Inject Your Code into Another Process" http://www.codeproject.com/threads/winspy.asp Hope this helps. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
From: anton bassov on 18 Sep 2006 02:58 > Is it a "hack"? Apparently, yes... > You need to be an administrator to access > physical memory, but if you are an administrator, then there > are far easier methods to reach that goal, e.g. a driver... Fully agree. However, this technique is not not meant to be used for anything, apart from education - it is always a good idea to learn about memory management internals, don't you think??? In fact, Dabak, Phadke and Borate did it in even more impractical way - they set up a call gate from the driver(!!!), which just defeats the purpose of the whole exercise............. Anton Bassov Piotr Wyderski wrote: > anton bassov wrote: > > > http://www.codeproject.com/system/soviet_kernel_hack.asp > > Is it a "hack"? You need to be an administrator to access > physical memory, but if you are an administrator, then there > are far easier methods to reach that goal, e.g. a driver... > > Best regards > Piotr Wyderski
From: lallous on 18 Sep 2006 07:09 Hello Arno, Yes, Read/Write Process memory might be slow if you need to frequently and massively access the memory of another process. One way, I'ld overcome the speed issue is by injecting my own DLL into the process space of the target and do the processing there. Another way, is just inject a small DLL that creates a memory mapped file, copies the desired area into that address, later you can analyze that memory mapped area from your main program. Hope that helps, Elias "Arno Schoedl" <aschoedl(a)think-cell.com> wrote in message news:1158244427.100619.13090(a)i42g2000cwa.googlegroups.com... > Hello, > > I would like to map a memory section of another process into my own > process, which is a regular user-mode process. I know about shared > memory with page file mappings, but in this case I am examining another > process which is not my own. So far, I am using > Read/WriteProcessMemory, which works, but is quite slow and requires > additional memory. I would prefer reaching directly into the other > process' address space. Any way to do this? > > TIA, > > Arno >
From: Arno Schoedl on 22 Sep 2006 04:12 Thanks for all your feedback. I will stick to the Read/WriteProcessMemory. I am searching for code locations in the other process to apply patches, but since the program to patch mostly stays the same, I can cache the patch addresses I found and thus avoid frequent searching. Arno
From: "Jeffrey Tan[MSFT]" on 22 Sep 2006 05:25
Hi Arno, Thank you for updating the status. If you need further help, please feel free to post. Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. |