Write Custom Interrupt Handlers in Real Mode

Topic Overview

Custom real-mode ISRs

Software can hook the IVT at 0x00000 by writing a far pointer (offset, segment) at entry interrupt_number * 4. Your handler must preserve registers, run briefly, then IRET. For example, replacing vector 0x1C (timer tick) lets you increment a tick counter every 55 ms.

Hooking a vector

nasmCopy
Loading…

• CLI/STI: Disable interrupts while patching the IVT
• Hardware IRQs: Also send PIC EOI (0x20 to port 0x20) for IRQ handlers
• Chain to old handler: Save original vector and jmp to it after your work
• Keep handlers tiny; BIOS may re-enter unpredictably

Re-entrancy cautions

If your handler calls BIOS routines that themselves use interrupts, keep interrupts enabled only when safe. For IRQ handlers, failing to send EOI stalls all lower-priority IRQs on that PIC. When chaining, call the previous handler with a far pointer saved at install time. Testing with IRQ0 is easier than keyboard noise if you only need to prove the stub runs.

Why for this exercise

You will install a custom handler for a software or hardware interrupt and observe it firing. This exercise requires IVT patching, register preservation, and IRET return discipline.

Write a C program that computes the effect of hooking an IVT vector in real mode.

Input: three hex numbers: interrupt vector V, handler segment S, handler offset O.

• Print "ENTRY=xxxxx": the physical IVT entry address for that vector, vector * 4 (5-digit hex).
• Print "LO=xxxx": the offset word (what gets stored at ENTRY in little-endian order).
• Print "HI=xxxx": the segment word (stored at ENTRY + 2).
• Print "HANDLER=xxxxx": the physical address the far pointer S:O resolves to, ((S << 4) + O) & 0xFFFFF. If V exceeds 0xFF or S/O exceed 16 bits, print only INVALID.