Chapter 4/ System Briefing

Of the 254 entries streamed to the console, less than a quarter of them refer¬

ence meaningful routines. Most of the entries (roughly 200 of them) resem¬

bled the following ISR:

ISSbflO ntlKiUnexpected Interrupt 16

These KiUnexpectedlnterrupt routines are arranged sequentially in memory,

and they all end up calling a function called Ki EndUnexpectedRange, which

indicates to me that only a few of the IDT's entries actually do something

useful.

kd> u 8188be7a

nt! KiUnexpected Interrupt1:

8188be7a 6831000000 push

8188be7f e9d3070000 jmp

nt!KiUnexpectedlnterruptZ:

8188be84 6832000000 push

8188be89 e9c9070000 jmp

nt!Ki Unexpected Interrupts:

818Bbe8e 6833000000 push

8188be93 e9bf070000 jmp

nt!KiUnexpected Interrupt4:

8188be98 6834000000 push

8188be9d e9b5070000 jmp

nt!KiEndUnexpectedRange (8188c657)

nt!KiEndUnexpectedRange (8183c657)

nt!KiEndUnexpectedRange (8188c657)

nt!KiEndUnexpectedRange (8188c657)

Even though contemporary hardware forces Windows to defer to the SYS-

ENTER instrucdon when making jumps to kernel-space code, the IDT entry that

implemented this functionality for older processors still resides in the IDT at

entry Ox2E.

The ISR that handles interrupt 0x2E is a routine named KiSystemServi cg. This

is the system service dispatcher, which uses the information passed to it from

user mode to locate the address of a Native API routine and invoke the Native

API routine.

From Ihe perspective of someone who's implementing a rootkit, the IDT is

notable as a way to access hardware ISRs or perhaps to create a back door

into the kernel. We'll see how to manipulate the IDT later on in the book.

Pointers to the Windows Native API reside elsewhere in another table.