Windows memory Management in detail of Windows Driver Development technology

• Virtual memory address

All Windows programs (RING0 and RING3 layers) can operate on virtual memory. Some units correspond to physical memory, but not one by one, and multiple virtual memory pages can map the same physical memory page. Some of the units will be mapped to files on disk and marked as dirty . When reading this virtual memory, the system will issue an exception, the exception handler will start, the exception handler will read the page's disk file into memory, and mark it as not dirty . The memory pages that are often not read and write can be exchanged for files and set to dirty.

Windows is designed so that the first is the virtual increase in the size of the memory, the second is to make different processes of virtual memory do not interfere.

Virtual memory in the 0-0X7FFFFFFF range of virtual addresses, called user-mode addresses. The virtual memory within the 0X80000000-0XFFFFFFFF range is called the kernel-mode address. Windows run in the user-state program can only access the user-mode address, while the program running in the kernel mentality may access the entire 4G of virtual memory.

• The relationship between drive and process

The driver can be seen as a special DLL file that is loaded into virtual memory by the application, except that the loaded address is in the kernel-mode address instead of the user-mode address. It can only access the virtual memory of this process, not the virtual address of other processes . The DriverEntry and AddDevice routines are run in the system process. Other routines such as Irp_mj_read, Irp_mj_write's dispatch function run in the context of the application, that is, the environment in which the process is run, and the virtual address that can be accessed is the virtual address of the process.

Write a code below to get the current process that the code is running. I was having a problem writing this code. At first, my code is as follows:

But after loading the driver, I didn't output the data I wanted:

At first I thought it was a imagefilename, so I used WinDbg to find out:

Discovery is 0x2e0, yes. Later, someone on the internet told me to use Psgetprocessimagefilename, which is a Microsoft exported but not documented API. This means that you can use this function directly, but it is not declared in a header file, so you need to declare it and then use it.

DECLARE first:

Re-use:

Actually output the result I want:

I wonder why, and then disassemble the API and discover that it has only two assembly codes:

If you go to this API step-by trace we can see:

In fact, the incoming parameter is the eprocess address, yes.

Here we place breakpoints in the program:

Single-step operation to observe the values of local variables:

The difference between the two is 0x2e0, indicating that we locate eprocess address and imagefilename address are right AH. So why don't you get the right results in front of you?

At this point we go to the single step of the code that just went wrong:

Same way single step, find Imagefilename location unreadable

Find out why unreadable, look carefully, because normally you should get address 0xfffffa80 ' 01923320, and you here are 0x00000000 ' 01923329.

So if you want to make changes based on this method, you should instead:

This will result in the normal output of the operation.

Windows memory Management in detail of Windows Driver Development technology