Virtual Functions are a fundamental aspect of OOP programming features such as polymorphism. Any Virtual Functions are stored within a dispatch table called a VTable or Virtual Method Table. The VTable is essentially a array of virtual function pointers. It is possible to find the VTable using WinDbg, and I will demonstrate this within this blog post.
Virtual Functions and Virtual Function Table Pointers
I've written a very simple program using C++ to demonstrate the syntax of Virtual Functions.
As you can see, there are two classes called A and B. A is the base class in which Class B will inherit any members or member functions from. By using the virtual keyword on the function in Class A called Function, it specifies that the function is a Virtual Function and not a standard function.
When Class B inherits Class A's properties, then the Function is redefined within Class B which can be seen on Line 14. Please note this is not function overloading, since the function still retains the same type and the same of number parameters, which wouldn't be the case for function overloading. The redefinition of a function within a class is called overriding, therefore Class B is overriding the definition stated originally within Class A.
By looking at the main function of our program, we can see two objects called of Class A and Class B respectively, and then a base pointer for Class A. We will use the base pointer to access any derived Classes from the base class of A. Note how we can access the Function in Class B using the base class pointer, this a demonstration of supporting polymorphism.
Each Class will actually have a pointer into the Vtable corresponding to that Class. For Example, Class B will have it's own VTable, and each entry within the VTable will correspond to the number of virtual functions which can be called by the object belonging to that class.
These VTable pointers will be set up by the compiler, and the corresponding object pointers or this pointers will be used to as a function parameter to be used by the compiler to find the entries within the VTables. It's important to remember that the pointer for Class A's VTable can't access the members for Class B's VTable, although, Class B is able to access Class A's table members. Another key point to consider is that the function pointers within VTable for a inherited class, will point to the overridden version of that function.
For example, Class B's Function() will not point to Class A's version of Function. Here's a good illustration to demonstrate this concept:
In real terms, you can use the same kind of prototype or interface of a function, and then make it specific to your needs or that particular object.
VTables and WinDbg
Please bear in mind, that the following extensions only apply to processes which were written with the .NET Framework, I created a similar program with C# to demonstrate these debugging extensions. There is another method but I've heard it's very tedious.
To use the following extensions you will need .NET Framework 4 or .NET Framework 4.5. The .NET Framework is required due to the DLLs we need to load into WinDbg. Some people have found this difficult to set up and therefore I will show some basic steps.
1) Load the executable into WinDbg using CTRL + E.
2) Load the following DLLs with the !load extension, you must specify the full file path, otherwise WinDbg will show a can't find file error:
3) Now, hopefully you inserted a Console.ReadLine function into your code, so the program pauses while in WinDbg. If so, then enter the g command into WinDbg and press Enter. This should enable the process to continue running and will load the CLR.dll.
4) Use the .loadby command with sos clr, and then enter the desired .NET debugging extensions.
If you followed the steps correctly, then the !dumpheap extension should work correctly. If not, then please make sure you have followed the instructions or leave a comment in the comments section.
I've named the namespace of my program VirtualTable, so that's the reasoning for the VirtualTable name appearing. The MT column contains the address of the Method Table or the Function Table (in terms of C/C++).
We can then use the !dumpmt extension to show some information about the Method Table for that particular class or class object.
A listing of the debugging extensions associated with SOS.dll can found in the Additional Reading section.
VTable Security
As a result of the possible exploits related to the VTable, some compilers have introduced some security features which help combat against these exploits. Some of these protections include VtGuard for Microsoft Visual Studio and Virtual Table Verification for GCC compilers.
The exploit I have read, is related to changing the VTable pointer to a different VTable and then executing the virtual functions from that VTable which would allow the injection of shellcode.
VtGuard uses a combination ASLR and then adding a extra entry to the VTable for a given class. The extra member is called _vtguard, and is hidden from the attacker with the use of ASLR. The method uses the cmp instruction to compare the address of the VTable Entry against the VTable Guard, and will terminate the process if these two addresses do not match.
Virtual Table Verification works by verifying that VTable pointers point to the base class and are valid for that class. Place any important data structures in protected areas of memory. The Base Class Virtual Table Pointers will be gathered at runtime, and then assigned to a _vtable map variable which can be used for comparison between the mapped _vtable map pointer and the _vptr gathered from the class object.
Additional Reading:
C++ Virtual Table
SOS.dll Debugging Extensions
BH_US_12_Miller_Exploit_Mitigation_Slides
Virtual Table Verification
Recursive !dumpmt - WinDbg
You may have noticed or not have noticed with a few Stop 0x9F, the 0x4 value being the first parameter which indicates that a power IRP has failed to synchronize with the PnP Manager.
The PnP Manager is a subsystem of the I/O Manager, and is used to allow devices to be added or removed without little interaction from the user. The best example to illustrate this point, would the insertion or removal of USB flash drives or any USB connected. The user will not have to install any additional drivers to use the device or configure any settings. The USB flash drive will almost instantaneously be added to the file system, and be able to managed by the user. This is a result of the design of the PnP Manager and the code used within the driver.
The PnP Manager can't be directly interacted with any driver routines. The PnP Manager is both present in Kernel-Mode and User-Mode. The User-Mode version will interact with the Kernel-Mode version.
The PnP Manager is also responsible for maintaining the adding and removal of devices to the Device Tree. Each device within the Device Tree is called a Device Node, and consists of Device Objects which form a Device Stack. We can view the Device Tree in WinDbg with the !devnode extension and the DEVICE_NODE data structure.
You can then view each device node by dumping the Child and Sibling Device Nodes. The whole purpose of this post is not to explain the PnP Manager, but to explain what is the general problem or cause of a Stop 0x9F with subtype being 0x4. The crash is very similar to a Stop 0x9F with the subtype of a 0x3, however, instead of a pending IRP, the problem arises with a thread becoming hung during power transition.
Looking at the call stack, we can generally see that a timer has expired and a Watchdog has been notified of this expiration. A Timer is set with Stop 0x9F's to check the state of any threads or IRPs which are hung or need processing, if the counter is incremented above a certain threshold then the system notifies a Watchdog routine which bugchecks the system. I recommend reading my blog post the Internals of Stop 0x9F here. It explains the timer aspect and Watchdog counter threshold value.
Watchdogs
Let's examine concept of Watchdogs since they are a fundamental aspect for the error reporting with Stop 0x9Fs and therefore shouldn't be dismissed or mistaken for something which isn't important.
For each Device Object is there is a special timer which is used to avoid deadlocking the system, by giving the Device Object the opportunity to be able to cancel any pending I/O operations. The timer is associated with a IO_TIMER data structure. We can use the DEVICE_OBJECT data structure to find the IO_TIMER structure. The Timer field contains a 32-bit pointer to the mentioned structure.
We can then view the _IO_TIMER data structure, and examine it's fields.
The TimerList field is a doubly linked list of the timers found with the !timer extension. The TimerRoutine field is function pointer to the driver callback routine which will be called by the I/O Manager every second once the Timer has been started with IoStartTimer.
The DeviceObject field is the associated Device Object which is able to cancel any pending I/O operations. This pointer is usually found from the IO Stack Location of the current IRP.
The Context field indicates the driver context, and thus which driver functions the driver associated with the Device Object is able to call. I wasn't able to find any documentation of the TimerFlag field.
Synchronization PnP and Power IRPs
The PnP Manager is a subsystem of the larger I/O Manager, and as a result the I/O Manager is able to send PnP IRPs and Power IRPs. The Power Manager is a subsystem of the I/O Manager too. PnP IRPs need to synchronize against Power IRPs, in order to prevent two-state changing PnP IRPs from being present in the same stack at the same time, which allows you to safely call Power Transition or any Power Related IRPs for a particular PnP device. The synchronization is also required to ensure that IRPs aren't called out of order, since some PnP IRPs will need to be called within a certain power state.
Since I haven't been able to obtain a Kernel Memory Dump for this type of bugcheck, the best extensions and commands would be to use the following: !locks and !irpfind.
The Device Tree can be synchronized with IopDeviceTreeLock which is a type of Spinlock. Use the !locks extension to find any locks related to the Device Tree or I/O Manager, and then view the thread which is holding the lock, this should hopefully give you a insight into why a thread may stuck or a IRP isn't being processed. Use the !irp extension to view the IRP's stack.
Use the !irpfind extension to find any other related PnP IRPs and see if they are being processed.
References:
BSOD DRIVER_POWER_STATE_FAILURE (9f) when running WLK 1.5 CHAOS test
Which PnP IRPs are State Changing?
Which PnP and Power IRPs are synchronized against each other?
This is hopefully going to be the upcoming blog posts for February:
- VTables and Virtual Functions
- Thread Storage Slots
- I/O Completion Ports
- IRP Queues
- PE Header Sections
- Registry Internals
- URBs and USB Internals
I'm also going to explore the I/O Manager more, since I haven't written much about it, and to be honest haven't read anything properly which is related to I/O for a while.
This blog post will expand upon the idea of Page Faults, which resolve problems with Virtual to Physical Address Translation, and take a look at the different kinds of Page Faults which can happen.
Collided Page Faults
Collided Page Faults are common on modern systems which have multiple threads. A Collided Page Fault is a situation whereby a thread within the same process or from a different process, causes a Page Fault on a page which is already paged-in by another thread of the same process or a different thread from a different process as mentioned before.
Before reading the rest of this section, the concept of Transition will apply to the PFN Database and not to PTEs and Prototype PTEs. Transition in terms of the PFN Database, will mean that the page isn't in a working set list or present on any paging lists, therefore the page will not be owned by anyone and will be in Transition when a I/O operation is being performed on it.
I haven't been able to find the correct symbols for the Transition Page List Head, and therefore won't be able to apply the _MMPFNLIST data structure to it. The symbol is most likely only accessible with Private symbols.
The ListName member is a enumeration which contains a list of all the PFN list types.
The Pager knows if the page is being read by checking the ReadInProgress bit is set in the _MMPFNENTRY data structure.
From here, the Pager may issue a Event dispatcher object (thread which created the fault owns the Event object) to cause other threads to wait, or alternatively it may create a parallel I/O operation to prevent deadlocks occurring in the filesystem, which will cause two threads to compete against each other, with the thread which is able to complete the I/O operation first being able to resolve the Page Fault.
Once the I/O has completeted, the ReadInProgress bit will be cleared and the PTE will be updated to point to the physical page. Any other threads which wish to obtain the PFN Database lock as seen in the _MMPFNLIST data structure, will check to see if any previous I/O operations completed successfully by checking the InPageError bit.
Clustered Page Faults
Clustered Page Faults are designed for performance, rather to resolve problems like deadlocks with the file system mechanisms being used. Clustered Page Faults rely upon placing large numbers of pages into the page cache, rather than the system working set in order to reduce the consumption of the virtual address space, and to avoid the limiting factor of the virtual address space size for the given system.
Furthermore, any pages which will be reused, do not have to invalidated within the TLB Cache with IPI's or flushing and rewriting of the CR3 register. Any PTE's which had mapping, will have the Transition bit set and placed onto a Standby list.
If the page is then referenced by a process, it is added to the working set of that process, however, if the page is never referenced it will simply remain within the Page Cache. Any pages which are present in the Page Cache and physical memory, will be represented with a dummy page. With Page Clustering, if two pages are referenced within the same cluster, then the Memory Manager will issue a single I/O operation on the two pages, instead of two read operations to increase performance.
The other pages which are already present in physical memory will point to a systemwide dummy page.
The Size field indicates the size of the MDL data structure and the size of the array of PFN entries for the resident pages.
DKOM is one of the methods commonly used and implemented by Rootkits, in order to remain undetected, since this the main purpose of a roottkit. To be able to access Kernel-Mode code and data structures without detection from security programs or tools used by security analysts and researchers. Rootkits are probably less of a problem than they used to be, with most rootkit detection tools being able to find all the variations of a rootkit, unless of course others are produced. Rootkits are able to steal information and hide other directories and files to remain undetected.
Usually, all objects are managed by the Object Manager, however, with DKOM, this technique completely bypasses the Object Manager, making it harder for rootkits to be detected. DKOM can also be used to modify the privilege level of a thread, hide processes and ports, and hide device drivers.
Rootkits will commonly check the operating system version to be able to adapt to the environment in which it is running in. You can view the operating system version with the vertarget command in WinDbg.
As we should know, Processes are represented as a object with a _EPROCESS data structure. The diagram below shows us the general overview of how processes are managed by the operating system. I'll apply this diagram to WinDbg.
The most important part of the diagram is the linked list of Processes and the pointers within the doubly linked list to connect each process together.
The Processor Region Control Block contains the address of the current running thread, the next thread scheduled to run and the currently idle thread. We can use the dt command with _KPRCB data structure or use the !prcb extension to view this information.
Each thread is represented by a _ETHREAD data structure, which contains the _KTHREAD data structure for the same thread.
We can then view the _KTHREAD data structure using the same WinDbg command.
Looking at the _EPROCESS data structure, you will notice a field called ActiveProcessLinks, and a pointer to the structure _LIST_ENTRY will represents a doubly linked list.
Since ActiveProcessLinks is a doubly linked list, it must have a Head. This head can be found by checking the PsActiveProcessHead symbol. Instead of using the dt command, you can use the dl command to display doubly and singly linked list in WinDbg.
The first entry should point to the starting process, which is always the System Process. We can check this is correct, by displaying the PsInitialSystemProcess global variable which points to the address of the _EPROCESS data structure for the System process.
Rootkits then take advantage of this linked list structure by modifying the pointers within the linked list through DKOM, and changing the Flink and Blink pointers to wrap around the process in which should be hidden.
The Blink and Flink pointers of the two processes will need to point to each other, in order to remain valid within the linked list, otherwise BSODs will result when PspExitProcess is called to terminate a process. You can determine if a linked list is valid with the !validatelist extension.
These types of rookits can be detected by checking the handle table for threads which do not appear to have any processes, or checking the thread scheduler list. The Handle Table for a Process can be found by looking within the _EPROCESS data structure, and then examining the ObjectTable field which contains a pointer to the _HANDLE_TABLE data structure.
The HandleTableList field within the _HANDLE_TABLE data structure contains the doubly linked list of all the connected Handle Tables for each process.
We can use the !list extension to transverse through the elements stored within the doubly linked list, and display each element.
References:
Rootkits: Subverting the Windows Kernel
Ring of Fire: Rookits and DKOM
When Malware Meets Rookits - Symantec
Windows Memory Forensics and DKOM - Jesse Kornblum
Hidden Processes - The Implication for Intrusion Detection
I've listed other WHEA data structures in my other blog posts, and therefore will not be listing the same ones here. The purpose of this blog post is to list the WHEA data structures available with WinDbg, and Microsoft's Public Symbol Server. The information within the structures has more or less been explained in my other WHEA posts, but if in doubt please leave a comment or read the WDK documentation.
_WHEA_ERROR_STATUS
_WHEA_ERROR_RECORD_HEADER_FLAGS
_WHEA_ERROR_PACKET_V2
_WHEA_ERROR_PACKET_FLAGS
_WHEA_ERROR_TYPE
_WHEA_ERROR_SEVERITY
_WHEA_ERROR_SOURCE_TYPE
_WHEA_ERROR_PACKET_DATA_FORMAT
_WHEA_ERROR_RECORD
_WHEA_ERROR_RECORD_HEADER
_WHEA_ERROR_RECORD_SECTION_DESCRIPTOR
_WHEA_REVISION
_WHEA_ERROR_RECORD_SECTION_DESCRIPTOR_VALIDBITS
_WHEA_ERROR_RECORD_SECTION_DESCRIPTOR_FLAGS
I noticed in a dump file I was debugging for a user on Sysnative Forums, within the call stack there was a few references to PCI Configuration Space. The PCI Configuration Space can be accessed by device drivers and other programs which use software drivers to gather additional information. The call stack in the example was easy to find a possible cause, however, the topic of this discussion will be explaining the PCI Configuration Space.
The driver in question belongs to CPU-Z.
PCI Configuration Space
The PCI Configuration Space is a set of registers, on PCI Express (PCIe) buses, this configuration space may be referred to as the the Extended Configuration Space. These registers are then mapped to memory locations such as the I/O Address Space of the CPU.
The Configuration Space is typically 256 bytes, and can be accessed with Read/Write Configuration Cycles. The target device for the Configuration Space Access is selected with the Initialization Device Select (IDSEL) signal, which is then decoded by the target device. Although, in order to make the PCI Configuration Space accessible (most CPUs do not support such access), there must be kind of mechanism, which can allow access to the PCI Configuration Space. This mechanism is divided into two parts: Mechanism #1 and Mechanism #2. Mechanism #2 is only provided for backwards compatibility, and therefore will not be part of the discussion later on.
The Configuration Space can be accessed by drivers with a set IRPs, or by accessing members within the BUS_INTERFACE_STANDARD data structure.
The IRP_MN_WRITE_CONFIG is used to to write data to the configuration space specified. The IRP is a Minor Function Code for a PnP IRP. Since the buffer containing the information to be written is allocated from paged pool, the bus driver must call this IRP at IRQL lower than DISPATCH_LEVEL.
The IRP_MN_READ_CONFIG is used to read data from the configuration space. This is IRP is also the Minor Function Code for a PnP IRP, and also must be called at IRQL level lower than DISPATCH_LEVEL for the same reasons above.
I mentioned earlier about the two types of Mechanisms used to access the Configuration Space. With the newer mechanism, two 32-bit I/O registers are created, one is called CONFIG_ADDRESS (0xCF8) and is used to provide the configuration address to be accessed, whereas, the second is named CONFIG_DATA and is used to transfer data to and from the CONFIG_DATA register.
The structure of the CONFIG_ADDRESS register can be found below:
Bit 31 is used to enable the translation of accesses to CONFIG_DATA to configuration cycles. These cycles are simply addresses on the PCI/PCIe bus. These Configuration Cycles are divided into two types: Type 1 and Type 2, and will be discussed later on.
The Bits 23-16 are used to serve as a Bus Number, to be able to enable the system to select a specific PCI bus. The Bits 15-11 are used to serve as a Device Number, to select a device connected to the PCI bus. Bits 10-8 are used for selection of PCI functions (if more than one), which are in simple terms logical devices for a certain device. The remaining bits mainly depend upon alignment requirements, but the last two bits must be 0, since all reads and writes have to be 32-bits long.
We haven't discussed one of the more fundamental aspects of the Configuration Space, which is the Configuration Space Header. The diagram below shows the structure of the said header.
The Configuration Space Header provides information to enable the operating system to interact and control the device. There is currently two different Header Types, which are Type 1 for bridges, switches and root complexes. Type 0 for Endpoints. The above example is for Endpoints.
The Interrupt Pin and Interrupt Lines are used with IRQs, IDT and IRQL Levels. Each PCI device typically has four pins which are A, B, C and D. Each pin is used to enable the hardware to interrupt the processor, using the Interrupt Line, which is used to map to a ISR within the IDT, so the appropriate ISR routine can be handled the device driver code.
The Device ID and Vendor ID are used to identify the device connected to the PCI bus. We can use these values in a PCI Database to find the manufacturer of the device.
The Subsystem Vendor ID (SVID) and Subsystem ID (SSID) provide model specific device information.
The Command and Status registers are used to provide feature and error reporting information which I have discussed in my Stop 0x124 PCIe Debugging Posts.
The BIST register is set by changing Bit 6 to 1, and then performing a Built-In Self Test.
We can view the Configuration Space for a certain device with WinDbg, which I will show later in the WinDbg Extensions section of this post. I'll explain Base Address Registers, Class Codes and Bus Enumeration there too.
Call Stack Functions
I've managed to find some code on ReactOS, which may explain some of the internal PCI functions seen in the call stack of the dump file.
HalpPCIConfig seems to perform some form of synchronization, and then begins performing a read/write operation with the specified buffer.
The rest of the documentation can be found here.
WinDbg Extensions
I've managed to find two extensions which could provide additional information with our debugging efforts. These extensions are !pcitree and !pci. Please note in order to use !pci, you will need a Live Debugging sessions with either the local computer or do it remotely. I enabled a Live Debugging session on my computer to provide you with an example.
The !pcitree extensions shows all the buses and the devices attached to these buses. Using the information provided with the !devext extension, the other fields provided by the !pcitree extension will become more apparent.
The d field is the Device Number, the f field is the Function Number. We can see the Interrupt Line number, the Vendor and Device information, Header Type and Class Information.
The !pci extension with the 0x100 flag shows the information stored within the PCI Configuration Space, please note this is a omitted output of one particular PCI bus.
There's three key points I would like to discuss in this section. BARs, Classes and Bus Enumeration. I will start with Bus Enumeration which we can obtain with the !pcitree extension.
There are three different methods of Bus Enumeration, which will described shortly. Bus Enumeration is a method of checking any devices are connected to the PCI bus. This is required since the BIOS and the operating system do not have any method of their own to be able to check if a device is connected. Bus Enumeration is performed by checking the Vendor ID and Device ID Registers, and then returning F's (Hexadecimal) and 1's (Binary) if the reading of the Function and Register fail.
Now, let's briefly look at the concept of BARs or (Base Address Registers). BARs are used to define the memory addresses and I/O port addresses (memory-mapped I/O) used by the PCI devices. These registers define the size of memory to be allocated, and where it can be allocated. Typically, Memory BARs must be in physical memory, whereas, I/O BARs do not have this restriction.
0x02 in the Type field means the address is 32-bit, 0x00 means the address is 64-bit and 0x01 is Reserved.
The last concept I'm going to discuss involves Classes. Classes are separated into Class Code, Sub Class Code and Prog IF (Programmable Interface) and are used to identify the type of device and it's potential functions.
There a larger number of Sub Classes and Functions, so I'll have to omit the complete listing, and refer you to the PCI OSDev Wiki article.
Additional Reading
PCI - OSDev Wiki
PCI Configuration Space
PCI Internals
OSR NtDev List - PCI Function Number
.JPG)
