Is there anyone who can help me with ReadProcessMemory() ?

Thanks for reading my question..
I don't know if you might click this thread expecting to explain
the usage of ReadProcessMemory()..
But it's not ... I really want to know about the mechanism of ReadProcessMemory()..

In the function, Does it create a thread to search into other process memory ?

And is the mechanism of VirtualAlloc() similar with ReadProcessMemory() ?
(I mean main idea..)

I learned that all processes has its own pagetable.. then a process kernel object contains
its address of pagetable ?

I think that page table is a key idea to perform functions like ReadProcessMemory() or VirtualAlloc() ..but How... I don't know....

I hope anyone can answer for me...

thanks for reading :)

No idea how it does it, but does the OS need to do something similar when it reads/writes to/from the page file? :)

Just a hint: VMM (Virtual Memory Manager) is a Windows kernel component responsible for all kind of operations with or related to virtual address spaces. As long as this is about kernel's very private mechanisms, frankly, I doubt anybody here is aware of decent details beyond what Windows Internals provides.

Quote:

---

Originally Posted by EnthusiasticNewbie

In the function, Does it create a thread to search into other process memory ?

---

Well, why would it do? What's so special in a thread that would help "to search into other process memory"?

The whole thing seems to me way too simpler. The ReadProcessMemory call reaches ring 0, where kernel by means of VMM is already able to resolve target process' virtual address to physical one and perform a read operation against it. The result is copied to an originator process' address space. That's it. No threads, no any other overheads, just kernel level operations.

Quote:

---

And is the mechanism of VirtualAlloc() similar with ReadProcessMemory() ?
(I mean main idea..)

---

Basicly, yes. Both mechanisms appear related to mapping and resolving virtual addresses to physical ones.

U always help me :) thanks!

The reason I was curious of such mechanism was that to read from or write to other process memory, To do so, one process should know the address space of others but even in processor itself can't know about the address spaces of others that is not running currently. I heard only something in CPU resolves virtual addresses to physical addresss using address to page directory stored in CR3 register.

Then how can a process knows others address space. to resolve virtual addresses, CPU needs to load a base address to CR3. but if CPU loads the base page directory address of new process to CR3, then it'll lose a control of existing process.

That's why I thought of thread. if a thread of other process that we want to read a memory from
is created, then processor can access the address space of the process by changing a value in CR3 register
without losing control of existing process.

I don't know much about kernel mode mechnism and maybe that's why I couldn't solve my question
but is it wrong to think that even if in kernel mode, they can't solve a other process's virtual memory? 'cause they will be forced to use a virtual address of current process due to the base address stored in CR3

It's hard to express things in english (I'm not used to english)
but what I want to say is.. even in kernel mode, they can't ignore CR3 register, so they must
resolve virtual address using CR3 register. that's why they cannot solve the virtual address of other process.

But is it possible to access physical memory directly without via virtual memory in kernel mode ?
If it's possible. I'm likely to know how to do things related memory spaces among processes..

confused.. anyway thanks again for always helping me :)

You definitely have to refer to Russinovich's Windows Internals, where you can find those sacral page tables and CR3 registers... Funny thing, I recommend this reading second time this week.

BTW, I do not understand your confusing about context switching. Are you as well confused about dispatcher being able to switch between scheduled and preempted thread contexts? It definitely manipulates with CR3 content but never loses the control... :)

And I have to warn you about being captivated by CPU specific level of details. This level may vary from one type of CPU to another, along with the details. This level belongs with HAL, you know. And this way it actually has nothing to do with application programming, neither with C++. So you can easily come to conclusion that your question hardly belongs with the forum topic. Exactly as I did. :)

And yes, I don't know the exact answer to your question. Sorry for that. ;)

Hi,

A quick summary of what happens when you call ReadProcessMemory():

1.) ReadProcessMemory Calls NtReadVirtualMemory in NTDLL.DLL
2.) NtReadVirtualMemory passes through the SYSENTER/2Eh callgate and KeServiceDescriptorTable handler.
3.) ntoskrnl.exe calls ZwReadVirtualMemory for your application.
4.) ZwReadVirtualMemory reads the process memory and writes it into the buffer you supplied.

I don't know how ZwReadVirtualMemory is implemented but if I wanted to read some memory in another process from a device driver I might do it something like this:

1.) Allocate a memory descriptor list using IoAllocateMdl.
2.) Then lock the pages with MmProbeAndLockPages.
3.) Then map the application memory into kernel address space with MmGetSystemAddressForMdlSafe.
4.) Now I could safely read the memory and do whatever with it.
5.) Unmap the pages with MmUnmapLockedPages.
6.) Unlock the pages with MmUnlockPages.
7.) Free the memory descriptor with IoFreeMdl.

Igor gave you some excellent advice and I agree. The Windows Internals book is a must-read for anyone interested in how Microsoft Windows works.

Best Wishes,
-David Delaune

Thank you guys !
I feel very thanksful to your replys!
and I think I have to read Windows Internals as you guys recommended :)
thanks again
have a good time !

P.S I have one more question..
As I asked, Is there any kernel mode method or command to access physical memory directly ?

Igor asked if I'm confused of context switching but It's not that I'm confused of that..
Losing control over the thread meant that it may happen when it changes only CR3 register to access other process address space without whole context switching.

Anyway! I really wanna know about first question!
If a processor can access to physical memory directly with any command (I mean without address translation), my question will be solved!
Thanks :)