Thursday 10 October 2013

Debugging Stop 0x109 - Kernel Patch Protection

Stop 0x109's are not that frequent, but they do not provide much information to work with. Stop 0x109's are generally caused by driver modifying kernel code (Kernel Patch Protection detects this) and kernel code held within RAM has become corrupt (failing RAM modules).

The purpose of this blog post, is mostly going to be explaining a little of Kernel Patch Protection and regions of the kernel which have been modified and are displayed within the bugcheck parameters.

With a Stop 0x109 bugcheck, there is four different parameters, the only parameter in which you'll want to view is the fourth parameter which shows the corrupted region. The other parameters are undocumented and reserved for Microsoft use.

The three parameters which I'll attempt to explain are: MSR, GDT and IDT.

MSRs (Machine State Registers): Handlers for special instructions used for system calls. More Information - MSRs

IDT (Interrupt Descriptor Table): A table which contains a list of ISRs and which interrupt number (IRQ) they belong to. More Information - IDT

GDT (Global Descriptor Table): A table which contains entries for memory segments. Segments are small regions of protected memory which are used to load CPU register instructions. More Information - GDT and More Information - Memory Translation and Segmentation

So, now you know, about some of the more technical regions of the operating system, we should start speaking about the main topic of the blog post, which is in fact Kernel Patch Protection and how it results in a Stop 0x109.

Kernel Patch Protection was introduced onto x64 operating systems, which were running Windows XP and Windows Server 2003 Service Pack 1. Kernel Patch Protection stops the modification of the kernel which would reduce stability and security. Any modification of the kernel would lead to a Stop 0x109 bugcheck. Here is a list of reasons on what the system would bugcheck or reboot upon:


Modifying System Files (HAL.dll and ndis.sys): Changing code within ndis.sys could lead to malicious activity such as opening network ports without the user knowing.

Global Descriptor Table: Enabling code running within User Mode to execute operations within Kernel Mode. You may see some CPU or operating system documentation/books refer to Ring Levels (Ring 0, Ring 2, Ring 3), which is old terminology, and refers to Kernel Mode and User Mode.



Interrupt Descriptor Table: Intercept and hook onto I/Os at interrupt level and page faults to hide contents of memory.

MSRs: On x64 CPUs, the LSTAR (Long System Target Address Register) register is used to control the value which contains the address of the routine which is intended to have control within Kernel Mode.

System Service Descriptor Table (SSDT): A table of array of pointers which point to system call handlers; rootkits could modify the I/O of calls from user mode.

Kernel Stacks: A malicous driver could allocate memory as a kernel stack for a certain thread, and then redirect calls and parameters.

Object Manager: Modify objects (processes, threads and file objects etc.) to alter system behavior through Direct Kernel Object Modification.





 



No comments:

Post a Comment