_ORIG9_S	 dd 0		;variables to save ISR address 
_ORIG9_O	 dd 0		;components -- segment:offset

get_int_9_addr:
	mov	ah,0x35		;int 21h, func 35h=get interrupt vector
	mov	al,0x21		;interrupt vector 21h
	int	21
	mov	ds:_ORIG9_S, es	;save address segment of int21h ISR
	mov	ds:_ORIG9_O, bx	;save address offset of int21h ISR
					
					
				

Installing an interrupt

Modifying control flow with detours or “Take the Long Way Home”

One technique for installing a TSR (particularly a TSR that hooks an existing interrupt, ideally an interrupt that is frequently triggered during normal system operation) is to essentially cause the system to take a detour during its usual code execution:

Let’s pretend that we want to install a TSR that hooks INT 21h (MS-DOS functions bb ♥).

Normally, when this interrupt is triggered, the code flow looks like this:

System invokes INT 21h > go to entry of INT 21h in IVT > retrieve the segment:offset address stored in the IVT[21h] (which corresponds to the location of the ISR in memory), jump to the address of ISR for IVT[21h], execute code at that address

INT 21h > IVT[21h] > ISR[21h] > return to calling function after execution of INT 21h ISR

What we want to do is create a detour between those last two nodes so that the target interrupt is hooked and is able to continue performing its normal operation after the newly added interrupt has finished executing its ISR.

There are a few ways that we could go about this, but let’s start with the most basic:

We create a new Interrupt and install it in an unused slot in the IVT.

It’s important to note here that interrupts above 0x80 are frequently undefined. Which means that there is a plethora of space (by MS-DOS standards) for adding new entries to the IVT that point to our *not malicious rly sweet and innocent doing nothing bad at all no way no how* TSR.

Normally you’d want to implement some time of basic check to ensure that somehow the IVT entry you’ve chosen isn’t already occupied. I leave that as an exercise for the reader. For now, we are going to be operating under the assumption that our chosen IVT entry (0x133, because it was the closest available to 1337) does not already point to an associated ISR and that our target IVT, 0x133, is a free slot in memory for us to add a pointer to our own ISR.

As noted above, one critical part of the functionality of the newly created interrupt’s ISR will be that, upon the conclusion of its own routine, it jumps to the address of the original hooked interrupt. This becomes especially important when we hook important interrupts for proper OS functionality, like the system timer, so as to prevent the system from crashing.

So our modified execution flow will look like this:

INT 21h > IVT [21h] >IVT [133h] > ISR [133h]> ISR[21h] > return to calling function after execution of INT 21h ISR

Now, we can abstract this a bit to achieve a model with a bit more generality.

The flow is essentially:

system call to target interrupt > IVT[{target_interrupt}] > jump to location of TSR, whose address is stored in IVT[{target_interrupt}] > execute TSR routine (with optional checks for executing based on specific subfunction calls > jump back to saved address of original ISR of the target interrupt > return to calling function that made the original system call

I made you this pretty diagram to clarify the process.

We want to essentially use a free area of memory that is accessible to our TSR (i.e. a free slot in the IVT, a defined variable in the "data" segment of our TSR (COM programs don't really care about segments because a COM program views everything as belonging to the same segment, that segment being CS, or the Code Segment. One can explicitly define different segments in a COM program, but the file format itself doesn't necessitate it, and often it's a stylistic choice. It's still super heckin' valid uwu (as long as you don't mess it up) so, for the sake of using some of the vocabulary of asm programming which is still applicable here, I am using that phrasing: store the ISR address segment and offset in two variables in the .data segment!)) as a conduit between these two pieces.

That way, we can bridge the gap between our newly inserted functionality of our new Interrupt, and the original functionality of the hooked interrupt. This introduces a delay between the invocation of our “desired” interrupt’s ISR and its execution, because the “desired” ISR is now being executed after our malicious Interrupt’s ISR.

Maybe significant lag could be an IOC…. who knows

bb 1337 steps

Now, this is the standard technique for installing a TSR.

If you wanted to write a memory-resident DOS virus however, then you would need to get creative.

Let’s recall that the IVT is structured as a table of entries (key:value pairs one could say, where key=Interrupt # and entry is the address of the function/routine that will be invoked upon calling the TSR, this is known as the ISR or Interrupt Service Routine; each entry in the IVT is a pointer that points to the interrupt’s ISR).

To retrieve the address of a specific interrupt’s ISR from the IVT, we could use a built-in DOS function (Int 21h, 35h), but we want to avoid making unnecessary calls to INT 21h functions whenever possible. This is because that many common AV programs will monitor a system for these calls.

So what are the other options?

Well, for starters we can note that the addresses of all 256 interrupts in the IVT are reserved in the first 1024 bytes of memory. Yeah but 1024 bytes where, that could be anywhere? What page is it?

Oh honey, remember this is real mode. This is the physical address range we’re talking about.

And it’s in the first 1024 bytes of memory, every time.

Each entry is allocated 4 bytes. So interrupt 0 is at address 0x0h (technically 0000:0000h), and interrupt 1 is at address 0x4 (again, technically 0000:0004h), and so on.

So if you wanted to retrieve the address of say Interrupt 21h, for example (don’t worry about why, that is of no importance at this moment), then you could do the classic maneuver: call INT 21h 35h with al set to 21h.

Or you could simply retrieve the value that is at address 0x84 (21x4, remember that 4 byte step between consecutive interrupt values).

So this function:

				
				
get_int_21_addr:
	mov     ah,0x35		;int 21h, func 35h=get interrupt vector
	mov     al,0x21		;interrupt vector 21h
	int     21
	mov     ds:_ORIG9_S, es	;store segment address of int21h in a var
	mov     ds:_ORIG9_O, bx	;store offset address of int21h in a var
				
				
			

becomes:

				
				
int21_whos_she: 
;[code snippet from Tequila, see screenshot below;
;also note:
;previously had defined BX as 0000:7C00h (so the boot sector)... 
;...so it's probably a bootkit]

...
	xor AX,AX
	mov es,AX
	es les BX,[0x070]            ;Masm Mod. Needed
	mov word [0x09B0],BX         ;Masm Mod. Needed
	mov word [0x09B2],es         ;Masm Mod. Needed
	mov es,AX
	es les BX,[0x084]            ;Masm Mod. Needed
	mov word [0x09B4],BX         ;Masm Mod. Needed
	mov word [0x09B6],es         ;Masm Mod. Needed
				
				
			

In the above snippet, we can see that the author of Tequila retrieved the addresses of 2 interrupts: INT 21h (at offset 0000:0084) and INT 1Ch (at offset 0000:0070h). These retrieved addresses are then stored to variables within the Tequila program, located at offset 0x09B0 (and 0x09B2, 0x09B4, and 0x09B6) from the start of the program. Basically, this part of Tequila saves the addresses of the two target interrupts to four local variables (2 variables for each address' segment and offset respectively), to be referenced later.

Now, using this technique, we can just retrieve these values of the segment:offset pair of the target interrupt’s ISR, and save that address (or address components, isn’t segmented memory architecture fun?) to a designated space in memory for calling/jumping to later.

***

The next logical step is to write a routine for our TSR — this is the actual payload which will become the ISR for our target interrupt.

You can fill this in with whatever you’d like. I’ve used a graphical payload because *I went to art school* but you can print a string to the console or whatever else your heart desires.

For now, I’ll call this routine tsr_hook_int

Next, we have to set the entry in the interrupt vector table of our target interrupt (again, INT 21h) to point to our new TSR. This is effectively ensuring that we change from IVT[21h] == address of INT 21h ISR to IVT[21h] == address of TSR

			
;******************************************************************************
;Set the interrupt vector of our target interrupt to point to the TSR routine
;******************************************************************************
	mov	cx, cs		;;make data addressable
	mov	ds, cx		;;address of TSR routine
	mov	dx, tsr_hook_int	;; passed in ds:dx
	mov	ah, 0x25	;; new ISR installed
	mov	al, 0x21	;; at IVT[0x21] or Interupt 21
	int	21h
				
				
			

***

And then finally, we make our call to Int21h, 31h to install the TSR:

				
				
;******************************************************************************
; Calculate size of memory to reserve for TSR, using the following values:
; 256 (0x100) = size of PSP
;
; length of program 
;; [Referencing Ray Duncan's trick for calculating program length
;; for specifying dx (memsize) of TSR, used in int 21h function 31h call]
;
; pgm_len equ $-{function following TSR}-{start of TSR}
;
; in this case, 
;
; pgm_len	equ	$-setup_hook_interrupts-start	
; 
; and the additional adjustment for aligning on a 16-byte paragraph boundary,
; which can be done by adding 15 to our total program length (program len + 256)
; and dividing by 16
;
; The final formula is as follows:
; ((256 + pgm_len + 15) / 16)
						
; move this memory size into dx
; call the MS-DOS TSR function with 31 (subfunction number) in AH
; and return value (0, 1, 2, take your pick) in AL
;******************************************************************************
install_tsr:
	mov	dx, ((256 + setup_hook_interrupts-start + 15) / 16)
	mov	ax, 0x3102
	int 	21h
				
				
			

***

Let’s call it a day for implementing our 1337 TSR — by which I mean our 1337 bb TSR.

We've covered the fundamentals of writing a TSR and learned a couple tricks for making the TSR a bit more stealthy. I've gone ahead and finished up this demo TSR for us (this is my Ina Garten moment, where I am retrieving a second pear clafoutis from the fridge, that I made before the cameras even started rolling. Ina Garten -- stealth queen, TSR inspo, culinary icon.)

There’s a lot more to discuss in terms of vx stealth and persistence techniques for TSRs, but this will provide us a veritable amuse-bouche for the feast of 1337 h4x on the menu.

[How many more times do you think she’s going to use 1337 in this blog post? Sounds like a fun math problem for you to solve, dear reader. lmk if you need to borrow my calculator.]

***

Baby’s First TSR!!

Below is a complete working example of a demo TSR I wrote that hooks INT 21h and only triggers when a call is made to the EXEC program (aka when a user launches a program from COMMAND.COM). If a call to INT 21h is made with any other sub-function call, then the TSR just redirects back to the original saved INT 21h ISR.

Otherwise, a user is greeted with a screen in 256 VGA Graphics mode and a modified colour palette that results in a terminal aesthetic that is reminiscent of that of a Commodore64.

This demo TSR doesn’t implement file infection routines or really anything fun. It provides a template for understanding how to modify control flow of critical system calls and how to use a TSR as a means of more persistent storage of a payload.

It is relatively harmless and it is certainly annoying. It is v on brand in terms of the programming paradigms of a large portion of simple TSR vx samples of the era.

			
			
;model TINY		;masm specific
;.286			;masm specific

;******************************************************************************
;	Template for creating a COM Program that installs a TSR to the IVT
;	 
;	To be used in MS-DOS Emulator program 
;		(i.e. DOSBOX, FreeDOS in qemu, etc)
;	Must be compiled with a 16bit linker 
;		(i.e. ld86 or link16.exe with MASM32) 
;
;	This TSR is for educational purposes only.
;	Use at your own risk and practice at least some modicum of discretion
;
;******************************************************************************
;	assume CS:TEXT, DS:TEXT
bits 16
.text:
	org 100h

;******************************************************************************
;		Define macros here
;
SCREEN_MAX	equ	320*200
DRAW_HALT	equ	320*50
SCREEN_WIDTH	equ	0x140		;;320
SCREEN_HEIGHT	equ	0xC8		;;200
VGA_PAL_INDEX	equ	0x3C8
VGA_PAL_DATA	equ	0x3C9
;
;******************************************************************************

;_start	PROC	NEAR 		; masm-specific
start:
	jmp 	setup_hook_interrupts

old_INT:
db	0EAh			;from Spanska Elvira, EAh is far call
_ORIG_INT	dd	? 	;this is also such a nice trick
iret				;bc it avoids having to define these variables
				;in a data segment so there is no need
				;to explicitly set the segment it is in
				;and we can load it from CS w the correct value


tsr_hook_int:
	cmp	ax, 4B00h
	jne 	NO_INT
	pushf

NEW_INT:
	push 	ax
	push 	bx
	push	cx
	push	dx
	push	ds
	push	es
	push	si
	push	di
	
	;;do things here for new ISR xoxo
	cli
	vga_init:
		mov	ax, 0013h
		int	10h
		mov	ax,0xA000
		mov	es,ax
		mov	ds,ax
		mov	di,0
		mov	ax,0202h
		cld
		set_pal:
			salc	;set carry flag in al, if carry flag set, al=0
			mov	dx,VGA_PAL_INDEX	
			out	dx, al
			inc	dx
			pal_1:
				or	ax,0011111100110011b
				push	ax
				shr	ax,10
				out	dx,al
				mul	al
				shr	ax,6
				out	dx,al
				pop	ax
				out	dx,al
				inc	ax
				jnz	pal_1
			jmp	vga_x
			
		vga_x:	
			xor	di,di
			mov	cx, SCREEN_MAX
			vga_loop:
				mov	ax, es:[di]
				add	ax, di
				and	ax, 0xff
				rep	stosb		;moves ax into es:[di]
	sti
	pop	di
	pop	si
	pop	es
	pop	ds
	pop	dx
	pop	cx
	pop	bx
	pop	ax
	popf

NO_INT:
	push	ax
	mov	al, 0x20
	out	0x20, al
	pop	ax
	jmp	old_INT
;	int	85h
;	iret

;******************************************************************************
; Get the address of the ISR for our target interrupt vector 
; save it to a variable
; alternatively, we can also save the address in an empty spot in the IVT
; as shown in the section that is commented out below
;******************************************************************************
setup_hook_interrupts:
	push	es	
	mov	ax,0
	mov	es, ax
	es	les bx,[0x84]		;;address for int 21h
					;;es:bx contains contents 
	mov	[_ORIG_INT], bx		;;of address 0x84 (0000:0084)
	mov	[_ORIG_INT+2], es

;******************************************************************************
; Alternative option for saving the retrieved values from IVT[21h] 
; to an empty slot in the IVT
; commented out because we only need one saved copy for our purposes
; which we already did by storing the offset and segment to [_ORIG_INT]
; and [_ORIG_INT + 2] as shown above
;******************************************************************************
;	push	es	
;	pop	ds
;	mov	dx, bx			;ds:dx now == es:bx 
;	mov	ah, 0x25		;(int 21h seg:offset)
;	mov	al, 0x85		;; new ISR installed
;	int	21h			;; at IVT[0x85] or Interupt 21
;	pop	es

;******************************************************************************
; Set the interrupt vector of our target interrupt to point to the TSR routine
;******************************************************************************
	mov	cx, cs			;;make data addressable
	mov	ds, cxi			;;address of TSR routine
	mov	dx, tsr_hook_int	;; passed in ds:dx
	mov	ah, 0x25		;; new ISR installed
	mov	al, 0x21		;; at IVT[0x21] or Interupt 21
	int	21h

;******************************************************************************
; Calculate size of memory to reserve for TSR, using the following values:
; 256 (0x100) = size of PSP
;
; length of program 
;; [Referencing Ray Duncan's trick for calculating program length
;; for specifying dx (memsize) of TSR, used in int 21h function 31h call]
;
; pgm_len equ $-{function following TSR}-{start of TSR}
;
; in this case, 
;
; pgm_len	equ	$-setup_hook_interrupts-start	
; 
; and the additional adjustment for aligning on a 16-byte paragraph boundary,
; which can be done by adding 15 to our total program length (prog_len + 256)
; and dividing by 16
;
; The final formula is as follows:
; ((256 + pgm_len + 15) / 16)
						
; move this memory size into dx
; call the MS-DOS TSR function with 31 (subfunction number) in AH
; and return value (0, 1, 2, take your pick) in AL
;******************************************************************************
install_tsr:
	mov	dx, ((256 + setup_hook_interrupts-start + 15) / 16)
	mov	ax, 0x3102
	int 	21h

;;Referencing Ray Duncan's trick for calculating program length
;;for specifying dx (memsize) of TSR, used in int 21h function 31h call
pgm_len	equ 	$-setup_hook_interrupts-start 						

;;_start	ENDP		;masm specific
;;end	_start			;masm specific
			
			
			

***

Different Names for the Same Thing

Okay, so installing an interrupt in the IVT is great, but by now, dear reader you may be asking yourself “that’s all well and good, but of course this type of technique wouldn’t be useful or applicable in subsequent OSes, i.e. Windows9x, WindowsNT, or hell, even modern Windows 11, right?”

Here is where the plot thickens.

You’re right in noticing that the IVT is an irrelevant data structure on 32-bit systems. As I noted in the intro, the IVT was the precursor to the IDT (Interrupt Descriptor Table, for those of you who feel so inclined as to ask for a refresher on the acronym). The IDT uses 8 byte blocks for each of the 256 entries in the IDT. Like many things on subsequent 32-bit systems, I would argue that there is a lot of fluff added. However the underlying structure and format remains relatively the same. And, more importantly, the use of the IDT in subsequent versions of Windows is also very similar.

So would the IDT even be a reasonable candidate region of memory for storing a malicious payload?

Just ask Rovnix, a cute lil bootkit from 2011 that hides its payload in the upper region of the IDT (upper being defined as higher memory addresses, specifically in the block of memory that spans Interrupts 0x80 and above). Not only is this technique useful for the bootkit in terms of stealth and persistence, but leveraging the IDT allows it to persist during the processor switch from real mode to protected mode on Win32 during the boot process. What a baddie. What a legend.

[I won’t be digging into Rovnix in this blog post, but it is in the pipeline for future posts. In the meantime, if you’re interested in learning more about this bootkit, I refer you to the excellent analysis of it covered in "Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats”.]

In the same way that the IVT was a data structure leveraged for persistent storage of malicious code in DOS-era viruses, so too was the IDT leveraged in the later Windows threat landscape.

“Different names for the same thing” isn’t a very robust anti-virus strategy— it’s a Death Cab for Cutie track and if we’re using the discography of early mid-2000s emo ballads as an EDR solution, we might as well just call this revitalized old-school vx technique by a more apt descriptor: “I will follow you into the dark.”