Try to find `MmNonPagedPoolStart` and `MmNonPagedPoolEnd`

https://web.archive.org/web/20061110120809/http://www.rootkit.com/newsread.php?newsid=153

`KPCR->KdVersionBlock->Debugger Data List Entry->Flink`

This technique is old and cannot be used in Windows 10, Windows 7/8 may fail
too, After research, the result is summary into this
(file)[https://github.com/nganhkhoa/lpus/blob/master/nonpaged-pool-range.md]

Basically, find ntoskrnl.exe module address (kernel base) in memory and use
offsets parsed from PDB file. Finding the kernel base by shellcode is not
usable in Windows 2020 Insider Preview, I use IoGetCurrentProcess and traverse
the ActiveProcessLinks linked list, Luckily, the process returned by
IoGetCurrentProcess (if called in DriverEntry) is System (the first process),
so the BLink is `nt!PsActiveProcessHead`. With the offset of
`nt!PsActiveProcessHead` parsed from PDB file, we can get the kernel base by
subtracting.

Then traverse the `(_MI_SYSTEM_INFORMATION*)nt!MiState` to find
NonPagedPool{First,Last}Va.

Try the following steps:

1. `x nt!MiState` to get address of MiState

2. `dt _MI_SYSTEM_INFORMATION` to get offset to Hardware

3. `dt _MI_HARDWARE_STATE` to get offset to SystemNodeNonPagedPool with those
offset, use the following command to list the NonPagedPool{First,Last}Va

4. `dt (_MI_SYSTEM_NODE_NONPAGED_POOL*) (<nt!MiState> + <HARDWARE_OFFSET> +
<NODE_INFO_OFFSET>)` Sample output

Sample results:
```
+0x000 DynamicBitMapNonPagedPool : _MI_DYNAMIC_BITMAP
+0x048 CachedNonPagedPoolCount : 0
+0x050 NonPagedPoolSpinLock : 0
+0x058 CachedNonPagedPool : (null)
+0x060 NonPagedPoolFirstVa : 0xffffe580`00000000 Void
+0x068 NonPagedPoolLastVa : 0xfffff580`00000000 Void
+0x070 SystemNodeInformation : 0xffffe58f`9283b050 _MI_SYSTEM_NODE_INFORMATION
```

The big page pool is denoted by two variables `PoolBigPageTable.Va` and
`PoolBigPageTableSize` It seems that this big page is inside NonPagedPool range

PoolBigPageTable is an array with PoolBigPageTableSize elements, where each
elements has:

- Va -> Address of the allocation
- Key -> Pool tag
- NumberOfBytes -> Size

By scanning the non-paged pool, we noticed that the scan hit on a few pages,
then no more results is found. The big table seems to be pointing to the
location of these allocation. So scanning through big table is faster?