C# 클래스 inVtero.net.Vtero

You only need this if you can't get symbols. see http://uninformed.org/index.cgi?v=3&a=3&t=sumry by skape & Skywing

Memory Dump routines

This routine is fairly expensive, maybe unnecessary as well but it demo's walking the page table + EPT. You can connect an address space dumper really easily TODO: Remake this. Instead of just pre-buffering everything. Ensure the GroupAS detections are appropriate and if not, reassign the VMCS/EPTP page to bare metal or a different HVLayer item.

Prefer symbol loading.

TODO: Make better for all types

Group address spaces into related buckets We will assign an address space ID to each detected proc so we know what process belongs with who After AS grouping we will know what EPTP belongs to which AS since one of the DP's will have it's CR3 in the VMCS Yes it's a bit complicated. The overall procedure however is straight forward in that; * For every detected process Bucket into groups which are the "Address spaces" that initially are (a) based on kernel address space similarities and then (b) based on what VMCS value was found pointing to that group This ensures that if we have several hypervisors with a possibly identical kernel grouping (i.e. the PFN's were used by each kernel were identical), they are disambiguated by the VMCS. (Which can be validated later) The benefit here is that brute forcing at this stage is fairly expensive and can lead to significant overhead, there does tend to be some outliers for large systems that need to be looked at more to determine who they belong too. Nevertheless, it's inconsequential if they are grouped with the appropriate AS since even if they are isolated into their own 'AS' this is an artificial construct for our book keeping. The net result is that even if some process is grouped by itself due to some aggressive variation in kernel PFN' use (lots of dual mapped memory/MDL's or something), it's still able to be dumped and analyzed.

Only scanning for core kernel modules