Added handling of prototype and VAD hardware / unknown PTEs on Windows x64

[thejanit0r]

The bug was found while dumping and analyzing user-mode memory regions of ntdll.dll.

Info about prototype and VAD hardware / unknown PTEs:

• https://codemachine.com/articles/prototype_ptes.html
• http://blog.rekall-forensic.com/2014/10/windows-virtual-address-translation-and.html
• Windows Internals 7th - P1

It has been tested on a Windows 10 x64 memory dump.

Windows x86 / PAE is currently not supported, but should be relatively easily portable given test data.

[ikelos]

Hiya, I have been thinking this over. My concern is that it no longer allows intel layers to be constructed except via the add_process method otherwise you might get conflicting results. The vad root value also doesn't get recorded in the configuration as a parameter, so saving this to a config file won't result in the same layer being reconstructable simply by reading the config. Strictly, this should be an optional requirement on an intel space, but that then starts getting really hacky with windows having different requirements from other OSes, so it needs further consideration I'm afraid.

If you want to be making forward progress, please get rid of the hidden _vad_root parameter, and make it an explicit (but still optional) integer requirement of the Windows mixins. This should then be passed as a configuration option (much like the dtb is here ), but that may require altering the add_process method to accept other configuration parameters (which in turn may require a bump of the API version). So, complex but doable and we want to do it the right way if we're going to add it...