How does a memory map of a Windows process look like?
This might be a duplicate question. I wish to know how the memory map of a windows process look like? I am looking for details. Kindly provide links to blogs, articles and other relevant literature.
Answer
I always like to actually be able to see things, rather than just read theory. It turns out, according to this blog post, that if you open a program using windbg even when it isn't running it still gets mapped to an address space as if it were. Thus, your disassembly window figuratively (not guaranteed to load your code at these exact addresses) shows you what is at those addresses in terms of code:
Of course, you can't guarantee those addresses thanks to ASLR, but it gives you an idea / gets you to think: memory addresses are also just code. Code and memory is stored in the same (virtual) space, as per the Von Neumann architecture which most modern computers implement. Unfortunately also as there's no stack, heap etc you can't move and look at those.
This blog post from Microsoft gives you a high level overview of the virtual address space. As you can see, half of it is reserved for use by the operating system and the other half you can fill with whatever you have (code, malloc calls, stack allocations etc).
In terms of how the address space works on the user side, this diagram helped me understand it. It's linked in this question which provides a series of decent links as to the varying possible maps. Remember though, that the layout in memory will differ in terms of the parts.
The important point to remember is that all of it, program, data, stack, heap, kernel stuff, is one big sequential series of memory addresses, although these may or may not actually translate to actual memory addresses.
Whilst you're at it, you might also be interested in how the executable appears on disk. This article and this article particularly provide some in depth analysis of the PE file format. The latter article also has a little diagram showing roughly how data is mmap'd.