Interrupt Descriptor Table - IDT - Red Teaming Experiments

At a Glance
Interrupts could be thought of as notifications to the CPU that tells it that some event happened on the system. Classic examples of interrupts are hardware interrupts such as mouse button or keyboard key presses, network packet activity and hardware generated exceptions such as a division by zero or a breakpoint - interrupts 0x00 and 0x03 respectively
Once the CPU gets interrupted, it stops doing what it was doing and responds to the new interrupt 
CPU knows how to respond and what kernel routines to execute for the newly received interrupt by looking up Interrupt Service Routines (ISR) that are found in the Interrupt Descriptor Table (IDT)
IDT is a list of IDT descriptor entries which are 8 or 16 bytes in size depending on the architecture 
Pointer to IDT is stored in an IDTR register for each physical processor or in other words, each processor has its own IDTR register pointing to its own Interrupt Descriptor Table
Offsets across different screenshots and windbg output may differ due to the fact that I rebooted the debugee a couple of times during the time these notes were taken.
The notes are based on debugging a kernel of a 64 bit Windows, running in a VM with 1 CPU.
IDT Location
We can check where the Interrupt Descriptor Table is located in kernel by reading the register IDTR:
1
r idtr
Copied!
As noted later, the command !idt allows us to dump the Interrupt Descriptor Table contents and it also confirms that the IDT is located at fffff803`536dda00 as shown below:
idtr register contains the same value seen when dumping IDT with !idt
Dumping IDT
We can dump the IDT and see addresses of Interrupt Service Routines for a given interrupt. Below is a snippet of the Interrupt Descriptor Table:
1
kd> !idt
2
​
3
Dumping IDT: fffff80091456000
4
​
5
00:	fffff8008f37e100 nt!KiDivideErrorFaultShadow
6
01:	fffff8008f37e180 nt!KiDebugTrapOrFaultShadow	Stack = 0xFFFFF8009145A9E0
7
02:	fffff8008f37e200 nt!KiNmiInterruptShadow	Stack = 0xFFFFF8009145A7E0
8
03:	fffff8008f37e280 nt!KiBreakpointTrapShadow
9
...
10
90:	fffff8008f37f680 i8042prt!I8042MouseInterruptService (KINTERRUPT ffffd4816353e8c0)
11
a0:	fffff8008f37f700 i8042prt!I8042KeyboardInterruptService (KINTERRUPT ffffd4816353ea00)
12
...
Copied!
Below shows the IDT dumping and ISR code execution in action:
IDT table is dumped with !idt
IRS entry point for the interrupt a0 is located at fffff8008f37f700
This is the routine that gets executed first inside the kernel when a keyboard event such as a keypress is registered on the OS 
Eventually, the routine i8042prt!I8042KeyboardInterruptService (inside the actual keyboard driver) is hit once the code at fffff8008f37f700 is finished
Putting a breakpoint on 
i8042prt!I8042KeyboardInterruptService
Once the breakpoint is set, a key is pressed on the OS login prompt and our breakpoint is hit, confirming that 
i8042prt!I8042KeyboardInterruptService indeed handles keyboard interrupts
Below is a heavily simplified diagram illustrating all of the above events taking place:
the keyboard interrupt 0xa0 occurs
IDT table using index 0x0a is looked up (IDT address + 0xa0 * 0x10) and the ISR Entry Point is resolved and code jumps to it
after some hoops, the code is eventually redirected to the keyboard driver where the interrupt gets handled in i8042prt!I8042KeyboardInterruptService
IDT Entry
IDT is made up of IDT entries _KIDTENTRY64 which is a kernel memory structure and is defined like so:
1
kd> dt nt!_KIDTENTRY64
2
   +0x000 OffsetLow        : Uint2B
3
   +0x002 Selector         : Uint2B
4
   +0x004 IstIndex         : Pos 0, 3 Bits
5
   +0x004 Reserved0        : Pos 3, 5 Bits
6
   +0x004 Type             : Pos 8, 5 Bits
7
   +0x004 Dpl              : Pos 13, 2 Bits
8
   +0x004 Present          : Pos 15, 1 Bit
9
   +0x006 OffsetMiddle     : Uint2B
10
   +0x008 OffsetHigh       : Uint4B
11
   +0x00c Reserved1        : Uint4B
12
   +0x000 Alignment        : Uint8B
Copied!
Members OffsetLow, OffsetMiddle and OffsetHigh at offsets 0x000, 0x006 and 0x008 make up the virtual address in the kernel and it's where the code execution will be transferred to by the CPU once that particular interrupt takes place - in other words - this is the Interrupt Service Routine's (ISR) entry point.
IDT Entry for the Keyboard Interrupt 0xa0
As an example, let's inspect the IDT entry for the keyboard interrupt which is located at index a0 in the IDT table as discovered earlier:
1
!idt a0
Copied!
From earlier, we also know that the IDT resides at fffff803536dd000:
1
kd> r idtr
2
idtr=fffff803536dd000
Copied!
We can get the location of the a0 IDT entry by adding 0xa0*0x10 (interrupt index a0 times 0x10 since a descriptor entry is 16 bytes in size) to the IDT table address fffff803536dd000, which gives us fffff803`536dda00:
1
kd> dq idtr + (0xa0*0x10) L2
2
fffff803`536dda00  51568e00`0010e700 00000000`fffff803
Copied!
With the above information, we can overlay the a0 interrupt descriptor entry with _KIDTENTRY64 and inspect a0 IDT entry's content:
1
kd> dt _kidtentry64 (idtr + (0xa0*0x10))
2
ntdll!_KIDTENTRY64
3
   +0x000 OffsetLow        : 0xe700
4
   +0x002 Selector         : 0x10
5
   +0x004 IstIndex         : 0y000
6
   +0x004 Reserved0        : 0y00000 (0)
7
   +0x004 Type             : 0y01110 (0xe)
8
   +0x004 Dpl              : 0y00
9
   +0x004 Present          : 0y1
10
   +0x006 OffsetMiddle     : 0x5156
11
   +0x008 OffsetHigh       : 0xfffff803
12
   +0x00c Reserved1        : 0
13
   +0x000 Alignment        : 0x51568e00`0010e700
Copied!
ISR for the Keyboard Interrupt a0
Based on the above IDT entry for the keyboard interrupt, the below re-enforces that the combination of Offset(High|Middle|Low) form the virtual address of the Interrupt Service Routine (ISR) entry point - the code that will be executed when a0 interrupt is triggered by the keyboard:
Below shows the instructions at fffff803`5156e700 (ISR entry point) to be executed by the CPU once interrupt a0 is triggered:
FFFFFFFFFFFFFFA0 will be pushed on the stack 
jump to fffff803`5156ea40 will happen
...and eventually, the i8042prt!I8042KeyboardInterruptService will be hit and below confirms it - firstly, the breakpoint is hit for fffff803`5156e700 and i8042prt!I8042KeyboardInterruptService is hit immediately after:
_KINTERRUPT
_KINTERRUPT is a kernel memory structure that holds information about an interrupt. The key member of this structure for this lab is the member located at offset 0x18 - it's a pointer to the ServiceRoutine - the routine (inside the associated driver) that is responsible for actually handling the interrupt:
1
dt nt!_KINTERRUPT
2
   +0x000 Type             : Int2B
3
   +0x002 Size             : Int2B
4
   +0x008 InterruptListEntry : _LIST_ENTRY
5
   +0x018 ServiceRoutine   : Ptr64     unsigned char 
6
   ...
7
   +0x0f8 Padding          : [8] UChar
Copied!
As an example - from earlier, we know that the ISR for keyboard interrupts is located at ffffd4816353ea00, therefore we can inspect the _KINTERRUPT structure of that our interrupt by overlaying it with memory contents at ffffd4816353ea00:
1
dt nt!_KINTERRUPT ffffd4816353ea00
Copied!
This allows us to confirm that the ServiceRoutine is again pointing correctly to i8042prt!I8042KeyboardInterruptService inside the keyboard driver: 
Finding _KINTERRUPT
In order to manually find the location of _KINTERRUPT for a given interrupt, we need to leverage the following memory locations and structures.
Process Control Region or PCR (_KPCR memory structure in kernel) stores information about a given processor:
1
kd> dt _KPCR
2
ntdll!_KPCR
3
   +0x000 NtTib            : _NT_TIB
4
   +0x000 GdtBase          : Ptr64 _KGDTENTRY64
5
   +0x008 TssBase          : Ptr64 _KTSS64
6
   +0x010 UserRsp          : Uint8B
7
   +0x018 Self             : Ptr64 _KPCR
8
   +0x020 CurrentPrcb      : Ptr64 _KPRCB
9
   +0x028 LockArray        : Ptr64 _KSPIN_LOCK_QUEUE
10
   +0x030 Used_Self        : Ptr64 Void
11
   +0x038 IdtBase          : Ptr64 _KIDTENTRY64
12
   +0x040 Unused           : [2] Uint8B
13
   +0x050 Irql             : UChar
14
   +0x051 SecondLevelCacheAssociativity : UChar
15
   +0x052 ObsoleteNumber   : UChar
16
   +0x053 Fill0            : UChar
17
   +0x054 Unused0          : [3] Uint4B
18
   +0x060 MajorVersion     : Uint2B
19
   +0x062 MinorVersion     : Uint2B
20
   +0x064 StallScaleFactor : Uint4B
21
   +0x068 Unused1          : [3] Ptr64 Void
22
   +0x080 KernelReserved   : [15] Uint4B
23
   +0x0bc SecondLevelCacheSize : Uint4B
24
   +0x0c0 HalReserved      : [16] Uint4B
25
   +0x100 Unused2          : Uint4B
26
   +0x108 KdVersionBlock   : Ptr64 Void
27
   +0x110 Unused3          : Ptr64 Void
28
   +0x118 PcrAlign1        : [24] Uint4B
29
   +0x180 Prcb             : _KPRCB
Copied!
_KPCR location can be found like this:
1
kd> ? @$pcr
2
Evaluate expression: -8781847822336 = fffff803`51148000
3
​
4
kd> !pcr
5
KPCR for Processor 0 at fffff80351148000:
6
    Major 1 Minor 1
7
	NtTib.ExceptionList: fffff803536dffb0
8
	    NtTib.StackBase: fffff803536de000
9
	   NtTib.StackLimit: 0000000000000000
10
...snip...
Copied!
Inside the _KPCR, at offset 0x180 there is a member that points to a Process Control Block memory structure _KPRCB which contains information about the state of a processor.
The key member we're interested when trying to find the _KINTERRUPT memory location for a given interrupt is InterruptObject as it contains a list of pointers to a list of _KINTERRUPT objects.  InterrupObject is located at offset 0x2e80 as shown below:
1
kd> dt _KPRCB
2
ntdll!_KPRCB
3
   +0x000 MxCsr            : Uint4B
4
   +0x004 LegacyNumber     : UChar
5
   +0x005 ReservedMustBeZero : UChar
6
   ....
7
   +0x2e80 InterruptObject  : [256] Ptr64 Void //256 pointers max as noted earlier
8
   ....
Copied!
With the above knowledge, we can now find the _KINTERRUPT location for the keyboard interrupt a0:
1
dt @$pcr nt!_KPCR Prcb.InterruptObject[a0]
Copied!
Below confirms that the _KINTERRUPT for the interrupt a0 we found manually matches that given by the !idt command:
References
Code Injection and API Hooking Techniques
SecurityXploded Blog
Kernel Interrupt Overview - Linux.com
Linux.com
Interrupt handler
Wikipedia
Hooking Series PART II: Interrupt Descriptor Table Hooking
ReLearEx
Interrupt Descriptor Table - OSDev Wiki
CodeMachine - Interrupt Dispatching Internals
Kernel Interrupt Overview - Linux.com
Linux.com
Fooling Windows about its internal CPU - Sina & Shahriar's Blog
Sina & Shahriar's Blog
Hooking IDT - Infosec Resources
Infosec Resources