CODEWITHSUNDEEP
cpuoperating-systemcinterrupt
Chris
Chris

Reputation: 1038

Changing the Interrupt Vector Table

During one of my university lectures we were talking about hooking and the possiblitity to change the interrupt vector table (IVT).

Our professor said that a program with root permissions is able to change the IVT and may use this ability e.g. as a key logger for every key press.

Does this mean that I can change with a e.g. C program my IVT ? Or how does it work ?

Upvotes: 1

Views: 2048

Answers (1)

Margaret Bloom
Margaret Bloom

Reputation: 44046

The Interrupt Vector Table is just an array of items1 placed somewhere in memory. If your program has root privileges it can write to /dev/mem and change the contents of the IVT.

However tempering, the IVT is not evenly close to be enough to have a working hook: you have first to find the IVT2 and then to compute the right value to put in it3. Being root is often not enough though, you can temper the IVT with a C program but you may need to write a Kernel Module to have a working hook.

The very specific way of hooking the IVT is dependent on the architecture of choice, you can reference specific CPU manuals and platform Datasheets by simply Googling for them.

Hooking the IVT may be actually used as part of an escalation rather than adding functionality to the OS4.

1 x86 use far pointers in real mode and descriptors in protected and long mode, ARM and PowerPC use instructions, MIPS doesn't really have an IVT.

2 In x86 it can be anywhere, you would need to use the privileged instruction lidt. In ARM it can be at fixed locations or it can be moved through the use of registers like VTOR and VBAR. Reading from which is a privileged operation. In PowerPC it can be at two fixed locations determined by the MSR register, again a privileged one. In MIPS there is really no IVT and the location is fixed. Anyway in order to execute privileged instructions you need to make a Kernel Module, root is not enough.

3 To be accurate here one would need to bit a little bit too technical, introducing the concept of MMU, address translation, instruction crafting, trampolines and process context (your routine is essentially isolated as it could be run under any other process context).

4 It's worth noting that "working against the OS* is usually an uphill slope that pay little or nothing, rather than changing the carefully crafted OS structures, it's better to use the relevant APIs.

Upvotes: 7

Related Questions