How does process memory work in windows?

Question

Windows

I don't understand how memory works in windows.
The process is said to be loaded to the top of virtual memory and the OS to the bottom.
Each process "tipo" has its own memory. He "supposedly" has dlls in his memory, which he can even change, as well as change something in his addresses, and the operating system will somehow solve this problem so that changes in the dlls do not affect other processes. Here is a picture for 32 bit Os
Firstly, it is not clear why we should talk about some addresses of the operating system if they are not available. You can’t change something in the OS addresses (as far as I know, it means from user mode)
Secondly, in other places it is said that, for example, the process may not be loaded to the same addresses to which it was loaded before. For example.write process memory
Why, if each process has its own personal memory that it occupies, should we load it into different addresses.
I just want to overwrite a separate instruction, how can I do this if it is located at different addresses each time.

Answer 1

I just want to overwrite a separate instruction, how can I do this if it is located at different addresses each time

WinApi or. From usermode - code injection into the process. Those.
fundamentally something like (as I would do in C , anyway): thread on it). Then all the work in the target process:
1. GetModuleHandle - find the dll we are interested in, the handle is equivalent to its base address.
3. NtProtectVirtualMemory - we allow writing on the page with the instruction of interest. Optionally - pause the rest of the threads.
4. Rewrite the instruction (for a specific dll, we just find it relative to the beginning of the dll)
5. Profit (if the threads were stopped, we resume, optionally return the old attributes to the page)
for a specific dll, we simply find it relative to the beginning of the dll - with a pitchfork, of course. If the function is exported, there is a GetProcAddress, which will allow you to search for it relative to the beginning of the function (there is less chance of a fail).
Directly with the memory of another process, except that the shaman will come out of the kernel.