1

[cross-posted (but closed the original) from https://stackoverflow.com/q/55438806/254959]

I'm trying to gain a better understanding on Windows process memory, and have some gaps with regards to the relationship between the VAD tree, the PTEs and loaded modules.

The output below are captured from a kernel debugging session, but in the context of a simple process which runs a simple compiled "hello world" C program.

  1. When I do an lm, there are many modules listed, but when I do a !vad, I only see 5 mapped in (my own process binary and 4 other Windows DLLs).
kd> lm
start             end                 module name
00007ffd`ea8f0000 00007ffd`ea91b000   vertdll    (deferred)             
00007ffd`ea920000 00007ffd`eab00000   ntdll      (pdb symbols)          C:\ProgramData\Dbg\sym\ntdll.pdb\13B64B553003FA22AB7CCD36A3A5431F1\ntdll.pdb
fffff416`a3800000 fffff416`a3b94000   win32kfull   (deferred)             
fffff416`a3ba0000 fffff416`a3db2000   win32kbase   (deferred)             
fffff416`a3dc0000 fffff416`a3dca000   TSDDD      (deferred)             
fffff416`a3dd0000 fffff416`a3e11000   cdd        (deferred)             
fffff416`a4290000 fffff416`a4307000   win32k     (deferred)             
fffff800`a5c01000 fffff800`a64d3000   nt         (pdb symbols)          C:\ProgramData\Dbg\sym\ntkrnlmp.pdb\31C51B7D1C2545A88F69E13FC73E68941\ntkrnlmp.pdb
fffff800`a64d3000 fffff800`a6552000   hal        (deferred)             
fffff800`a6600000 fffff800`a6647000   kd_02_8086   (deferred)             
...
fffff80b`85960000 fffff80b`8597c000   disk       (deferred)             
...

kd> !vad
VAD           Level     Start       End Commit
ffff8908f102b0c0  4     7ffe0     7ffe0      1 Private      READONLY           
ffff8908ef465290  3     7ffe1     7ffef     -1 Private      READONLY           
ffff8908f169f100  4   fb63c20   fb63d1f      6 Private      READWRITE          
ffff8908ef4c86e0  2   fb63e00   fb63fff      3 Private      READWRITE          
ffff8908ef17e3b0  3  2e38e030  2e38e03f      0 Mapped       READWRITE          Pagefile section, shared commit 0x10
ffff8908ef592280  4  2e38e040  2e38e046      1 Private      READWRITE          
ffff8908f1873410  1  2e38e050  2e38e068      0 Mapped       READONLY           Pagefile section, shared commit 0x19
ffff8908ef106a00  3  2e38e070  2e38e073      0 Mapped       READONLY           Pagefile section, shared commit 0x4
ffff8908f19eea10  2  2e38e080  2e38e080      0 Mapped       READONLY           Pagefile section, shared commit 0x1
ffff8908f0fba340  3  2e38e090  2e38e090      1 Private      READWRITE          
ffff8908f0fdc980  0  2e38e0a0  2e3900a0      1 Private      READWRITE          
ffff8908ef215060  3  2e390130  2e39022f     17 Private      READWRITE          
ffff8908ef084860  2  2e390230  2e3902f4      0 Mapped       READONLY           \Windows\System32\locale.nls
ffff8908f14e3e90  3 7ff67f9a0 7ff67fa9f      0 Mapped       READONLY           Pagefile section, shared commit 0x5
ffff8908ef3025c0  1 7ff67faa0 7ff67fac2      0 Mapped       READONLY           Pagefile section, shared commit 0x23
ffff8908f0ef7c70  4 7ff67fe30 7ff67fe51      3 Mapped  Exe  EXECUTE_WRITECOPY  \Users\user\Desktop\test\x64\Release\test.exe
ffff8908ef6ad770  3 7ffde5240 7ffde52c7      5 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\apphelp.dll
ffff8908ef1bcf70  4 7ffde7470 7ffde76d5      8 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\KernelBase.dll
ffff8908f16717a0  2 7ffde9270 7ffde931d      5 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\kernel32.dll
ffff8908f0e50c30  3 7ffdea920 7ffdeaaff     12 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\ntdll.dll

When I !pte and even db on one of the modules that is not in the !vad output (specifically, the disk module), it is a valid, mapped-in address, and I can even read its content.

kd> !pte fffff80b`85960000
                                           VA fffff80b85960000
PXE at FFFFFB7DBEDF6F80    PPE at FFFFFB7DBEDF0170    PDE at FFFFFB7DBE02E160    PTE at FFFFFB7C05C2CB00
contains 0000000001109063  contains 0A0000007E55D863  contains 0A00000002A81863  contains 890000007D044963
pfn 1109      ---DA--KWEV  pfn 7e55d     ---DA--KWEV  pfn 2a81      ---DA--KWEV  pfn 7d044     -G-DA--KW-V

kd> db fffff80b`85960000
fffff80b`85960000  4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00  MZ..............
fffff80b`85960010  b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00  ........@.......
fffff80b`85960020  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
fffff80b`85960030  00 00 00 00 00 00 00 00-00 00 00 00 d8 00 00 00  ................
fffff80b`85960040  0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68  ........!..L.!Th
fffff80b`85960050  69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f  is program canno
fffff80b`85960060  74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20  t be run in DOS 
fffff80b`85960070  6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00  mode....$.......

Why then, does !vad not contain this entry?

  1. When I !dh on one of the loaded PEs, e.g., the EXE for my own process, I can see that it consists of different sections with different memory access protection.
kd> !dh 7ff67fe30000

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
    8664 machine (X64)
       6 number of sections
5CA04653 time date stamp Sat Mar 30 21:47:15 2019

       0 file pointer to symbol table
       0 number of symbols
      F0 size of optional header
      22 characteristics
            Executable
            App can handle >2gb addresses

...

SECTION HEADER #1
   .text name
   10FA0 virtual size
    1000 virtual address
   11000 size of raw data
...
60000020 flags
         Code
         (no align specified)
         Execute Read

SECTION HEADER #2
  .rdata name
    96F6 virtual size
   12000 virtual address
    9800 size of raw data
   11400 file pointer to raw data
...
40000040 flags
         Initialized Data
         (no align specified)
         Read Only

...

SECTION HEADER #6
  .reloc name
     614 virtual size
   21000 virtual address
     800 size of raw data
...
42000040 flags
         Initialized Data
         Discardable
         (no align specified)
         Read Only

And, according to the Windows Internals book,

There is one VAD for each virtually contiguous range of not-free virtual addresses that all have the same characteristics (reserved versus committed versus mapped, memory access protection, and so on).

So I would expect that each loaded module would be represented by a few VAD entries, for each section with different memory access protection.

But !vad shows each loaded module as a single entry with the permission EXECUTE_WRITECOPY.

kd> !vad
VAD           Level     Start       End Commit
...
ffff8908f0ef7c70  4 7ff67fe30 7ff67fe51      3 Mapped  Exe  EXECUTE_WRITECOPY  \Users\user\Desktop\test\x64\Release\test.exe
ffff8908ef6ad770  3 7ffde5240 7ffde52c7      5 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\apphelp.dll
ffff8908ef1bcf70  4 7ffde7470 7ffde76d5      8 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\KernelBase.dll
ffff8908f16717a0  2 7ffde9270 7ffde931d      5 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\kernel32.dll
ffff8908f0e50c30  3 7ffdea920 7ffdeaaff     12 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\ntdll.dll

Why is that so?

  1. In that case, how can I have a complete picture of the memory pages that are accessible by a process, and their associated memory access protection? Initially, I thought of relying on !vad output, but seems like it doesn't give a complete picture? Does it mean that I should iterate through and run !pte on every multiple of 0x1000 from 0x0 to 0xFFFFFFFFFFFFFFFF?
Improve this question

1 Answer 1

Reset to default
2

when you are in kd session lm displays both kernelmode modules and user mode modules

use lm u to display only usermode modules

this will be consistent with the !vad display

kernel mode modules aren't associated with a single process and as such they are not a part of processes virtual address descriptor table

obviously you can get the pte for any virtual address and obviously you can read from any virtual address

iirc the versus is the qualifier in the Quote the image VADS all will have MEM_IMAGE as their type and they would be contiguous you cant split them to their individual sections from !vad

you need to be in usermode and do !vadump for the specific image in the specific process

a single CONTIGOUS MEM_IMAGE vad 

0: kd> !vad ffffde04de1b7d90
VAD           Level     Start       End Commit
ffffde04de1b7d90  0 7ffdb7c80 7ffdb7e6c     21 Mapped  Exe  EXECUTE_WRITECOPY  \Windows\System32\ntdll.dll

Total VADs: 1, average level: 1, maximum depth: 0
Total private commit: 0x15 pages (84 KB)
Total shared commit:  0 pages (0 KB)

I attached this process to a local windbg in the target

the split for this vad 

BaseAddress:       00007ffdb7c80000  << + 
RegionSize:        0000000000001000  <<  ====
State:             00001000  MEM_COMMIT
Protect:           00000002  PAGE_READONLY
Type:              01000000  MEM_IMAGE

BaseAddress:       00007ffdb7c81000 <<<<<<<<<<<< + 
RegionSize:        0000000000117000 << ====
State:             00001000  MEM_COMMIT
Protect:           00000020  PAGE_EXECUTE_READ
Type:              01000000  MEM_IMAGE

BaseAddress:       00007ffdb7d98000 <<<<<<<<<<<<<<
RegionSize:        0000000000047000
State:             00001000  MEM_COMMIT
Protect:           00000002  PAGE_READONLY
Type:              01000000  MEM_IMAGE

BaseAddress:       00007ffdb7ddf000
RegionSize:        0000000000001000
State:             00001000  MEM_COMMIT
Protect:           00000004  PAGE_READWRITE
Type:              01000000  MEM_IMAGE

BaseAddress:       00007ffdb7de0000
RegionSize:        0000000000002000
State:             00001000  MEM_COMMIT
Protect:           00000008  PAGE_WRITECOPY
Type:              01000000  MEM_IMAGE

BaseAddress:       00007ffdb7de2000
RegionSize:        0000000000008000
State:             00001000  MEM_COMMIT
Protect:           00000004  PAGE_READWRITE
Type:              01000000  MEM_IMAGE

BaseAddress:       00007ffdb7dea000  <<<< + 
RegionSize:        0000000000083000  <<<  =====      ((00007ffdb7e6d000 - page size) / pagesize)  = vad end  7ffdb7e6c
State:             00001000  MEM_COMMIT
Protect:           00000002  PAGE_READONLY
Type:              01000000  MEM_IMAGE

the lm in usermode 

0:001> lm m ntdll
Browse full module list
start             end                 module name
00007ffd`b7c80000 00007ffd`b7e6d000   ntdll

you can do !dh here and add look at the virtual address each virtual address will match !vadumps entry and will show what different protections are applied

read about VirtualAlloc and Virtual Protect

you can allot a very big memory and change protections for page sizes inbetween them the big allocation is equivalent for vad while !vadump in usermode will show the virtualprotected state

a process can access only the usermode virtual addresses it cannot access the kernel mode addresses it need a mechanism to do that (syscalls do that work)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.