Windows kernel and software security

Background －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ This is a first windows driver research notes in my blogger. And I will try to keep it simple and clear in this article, for who wants to understand the internal behavior of Class And Mini-Class Driver. －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ Audience －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ For who wants to understand Mini-Class and Class Driver internal. And understanding more about Hid Device stack. －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ Introduction －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ First, We are going to take a example of HidUsb and HidClass, the former is a Mini-Class Driver of a HidClass. We can simply think the relationships between them, is a child and parent relationship, Hidusb is one of the child of HidClass. HidClass can be thought as a helper module( like Dll do) in kernel mode, for helping all Driver who wants to join a hid family. －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ Research －－－－

  Introduction : A most of time we used Windbg+ VMW are for kernel debugging. But there is a problem that we can not  use it for debug ging a  Interrupt Service Routine (ISR) . In such case system will be hang and occur a infinite loop within a interruption. Such as INT 3 breakpoint interruption. This is because the interrupt cannot be handled normally, the  breakpoint  exception is never been dispatched normally. Because of this reason, we actually can able to use a VMWare ’ debugging interfaces for debugging ISR. VMWare exported a interfaces with GDB, we can enable it through this configuration in .vmx file For 64-Bit system should debugStub.listen.guest64 = "TRUE" For x64 system we can connect to  localhost: 8864  ,   the port of  32 bit system is 8 832 Select process ID is 0 Although we are attached into kernel, but we may not able to view the code since the memory region is not created, we can use IDA function - debugger-&g

Background:      Debugging with Nested-VMM hang issue when injecting nested #DB, and the infinite #PF occur, the system will be freeze.  Phenomenon: After Emulation of VMExit (L0 VMRESUME to L1), then causing VMExit Reason is 28 (CR access), and after that  the Kernel GS Base is changed. Try to intercept WRMSR and find the instruction which modify IA32_KERNEL_GS_BASE, therefore, as a follow screen capture: 0xFFFFF80002ADB369, which is in area of nt!SwapContext. Matched VMExit Reason PS. Because I take this screen capture at different time, so that address is not the same… and above: 0xFFFFF80002ADB369, there is a 0Xfffff80002a9c369 Analyze: -      Take a look at the red box in the following screen capture, the function will be directly execute WRMSR into a 0C0000102H (IA32_KERNEL_GS_BASE) MSR with actually qword ptr [r8+80h], r8 is an address of the current thread’s User Mode Scheduling Control Block (UMC_CONTROL_BLOCK), and the offset