STARSHIP - interesting file-boot virus.
Muttik I.G.
(Internet: [email protected])


KEYWORDS

Virus, DOS, executable file, masterboot record,
resident in memory, encryption.


ABSTRACT

STARSHIP virus (file and boot simultaneously) is described. It
infects IBM PC and compatibles running DOS. Virus is called
STARSHIP : this string can be easily found in the memory dump
of virus. Virus infects masterboot record on harddisk and
executable files files created on floppy drives. The virus is
encrypted. Infected executable files have no descriptor longer
than 2 bytes. Virus appears to have no destructive code, it
uses music and video effects when active. The abnormal
operation of the infected computers was sometimes detected.


INTRODUCTION

History of computer viruses is very short. The first
known publications are dated with 1984-1985 [1,2]. But now
situation in this field changes every day - uncountable number
of various computer viruses are known at present in DOS
operating system. The variety of known viruses is fantastic,
but all of them falls into three known categories: file,
boot [3,4] and cluster. Active area of the first virus type is
executable files and of the second type - boot records on
harddisks and diskettes. The third category is not yet over-
populated, the only representative is bulgarian DIR-II virus.
Probably the first virus which infects files and boot
sectors was Ghost virus [5]. This virus was discovered by
Fridrik Skulason at Icelandic University. Ghost virus infects
only COM files. This virus increases file size by 2351 bytes.
When active the Ghost replaces boot sector of infected system
with a boot virus similar to Ping Pong, but this boot virus
does not have infection routine. The Ghost virus,
consequently, may be considered as a file virus with unusual
active phase. After some time appeared Virus-101, Frodo and,
finally, a bunch of new viruses was found: Thanksgiving virus
(V-1), TEQUILA and STARSHIP (these type of viruses is
sometimes called "multi-partite").
STARSHIP virus was found in Moscow in January 1991.
Probably this virus was written in the USSR.
The living cycle of STARSHIP virus is the following. When
infected file is started it modifies masterboot record (MBR)
on the harddisk and writes virus on the disk. Thereafter, when
computer reboots, virus intercepts interrupt vectors 13h (low-
level disk I/O) and 21h (DOS service). During the reboot virus
is stored in the videomemory at address BB00:0. It is moved to
the core RAM later, when the first program terminates. Now it
stays resident and infects any COM/EXE file created on floppy
drives.

1. GENERAL DESCRIPTION

Length of STARSHIP virus in memory is 2688 bytes. Size of
code is 2560 bytes, buffers and variables takes the remainder.
On harddisk virus takes 3072 bytes (6 sectors * 512 bytes).
Virus layout is shown in Table.1 and its memory dump
(fragmentary) is presented in Figure.1. (NOTE: All dumps
presented is the article are partial in order to prevent the
possibility to use for generation of new viruses.)
No text messages except one string ">STARSHIP_1<" of
length 12 (found only in memory) were discovered. This string
can be found only in memory, because virus is stored on disk
and in the infected file in encrypted form.
Normally virus stays resident and the size of used memory
block is B00h=2816. The beginning of this memory block is the
Program Segment Prefix (PSP) of program that triggered the
installation of virus in the core RAM. Really virus is started
at offset 80h in this PSP (consequently, the real virus size
is: B00h-80h=A80h=2688 bytes).
Virus uses standard interrupts 13h, 20h, 21h, 27h and
creates its own interrupts F9h and FCh (see later). When virus
is already resident (installed in the core RAM) it uses only
13h and 21h vectors. Entry points of both interrupt handlers
can be easily found (CS:005F and CS:00C5; here CS represents
the code segment where virus resides).
In the memory dump of virus one can found the buffer for
the filename (see ASCIIZ= 'B:\TMP\DROZFILA.COM' at CS:000D in
Fig.1).
Virus extensively uses its internal random number
generator. The random number seed is taken from BIOS timer
variable (0:46Ch). Random generator is used for the
demonstration of video effect and while creating the infected
file (change of size is random and virus code is encrypted
using random number). The word "random" may be a real motto of
the described virus - it uses random number generator very
frequently.
The part of virus memory image is encrypted using XOR
function (approximately 60% of total virus size). This section
is decrypted and used only while infecting files (section is
marked in Table.1 with the box). After infection of each file
the XOR mask is changed, and encryption is performed with the
new mask. Described procedure makes the encrypted section
volatile and unreadable. This behavior is not used to hide any
strings in virus body (there are no strings at all, except
virus name) - maybe it is implemented only to achieve
permanent variance.
Virus uses trace capabilities of processor to determine
the original BIOS interrupt 13h entry point. Virus issues
int 13h with trace flag set and records the CS:IP when CS
becomes greater or equal to C800h (corresponds to the ROM
area). However this method seems to be non-universal. I have
investigated the process of disk infection and found that
rewriting of MBR sometimes triggered the resident antivirus
utilities (program TSAFE: Turbo-Anti Virus Ver.6.80A from
CARMEL Software Engineering, Israel).
While disassembling the virus I have found special code
inserts used to fool disassemblers. In most cases these
inserts uses non-working calls and jumps pointing on the
garbage in the virus body. These inserts are a real problem
for disassemblers and I have not found one that managed to
correctly separate code and data (or code and garbage). The
intelligent analysis of code is needed, which is not performed
by all available disassemblers (including smart SOURCER
ver. 3.07, by V Communications Inc.).
I have carefully examined the reconstructed source and
established that STARSHIP virus appears to have no destructive
code.


2. FILE INFECTION

Strategy of file infection is the following. Files are
infected while creation of EXE/COM file on A: or B: disks.
Virus records file name in internal buffer (at CS:000D), and
starts infection routine when request to close the file was
issued. This technique is similar to the method used by Dark
Avenger virus [3,5,7].
The idea to infect only executable file that are created
on floppy disks explains why STARSHIP does not intercept int
24h. This interrupt is usually catched by viruses to prevent
message - "Write protect error". But when file is created (!)
on the floppy disk it automatically indicates that the user
has removed (or will remove) the write protect tab.
Change of infected file size is true random (for the same
file you can get many variants of infection with different
size growth). Change of size is typically 2616...2648 bytes.
Virus infects COMMAND.COM file when it is created on
floppy disk. No special strategy is used to infect command
interpreter - it is infected as a simple .COM file.
When infecting executable (only EXE and COM) files, virus
preserves attribute. If the file is readonly - this attribute
remains unchanged after infection. STARSHIP examines the
executable file type by its contents, not by extension (tests
for 5A4Dh at file beginning, but it does not test 4D5Ah).
Virus does not infect short files - see Table 2. Virus does
not infect the files that are already infected. Buffer at
virus end is used to read code beginning and determine the
presence of virus (it seems to me that virus may frequently
regard uninfected files as infected, because it performs very
primitive analysis).
Virus infection routine uses the following interrupts:
int F9h (it points on the original int 21h, as set by DOS) and
int FCh (points on original int 13h, as set by BIOS). These
interrupts are used instead of int 21h and 13h. This technique
is probably used to prevent triggering of certain antivirus
utilities. These utilities often controls all invokations of
21h and 13h interrupts. The infection routine appends virus to
the end of executable file and adjusts the program entry
point.
Executable files with COM extension are modified by virus
at first 3 bytes, which are replaced with JMP instruction,
pointing on the decryptor. Original 3 bytes from file start
are stored at the very end of the infected file (like the body
of virus these bytes are encrypted with XOR function).
After modification of the EXE file header new CS:IP
points on the virus decryptor. SS, SP and MINALLOC fields are
changed. Original CS, IP, SS and SP are stored at the end of
the virus body at offset A4Fh (you cannot fetch these bytes
directly - they are encrypted).
The header of the infected EXE file has some special
features. Instruction pointer always follows the relation:
4constant: SS-CS=100h and stack pointer is always set to
SP=800h. Moreover, STARSHIP does not infect EXE files when
MAXALLOC field of EXE header is less than 0FFFFh. Virus does
not infect files with nonzero overlay number.
Virus code is added to the end of file in the encrypted
form. This encrypted code goes after special decrypting
program (decryptor). The purpose of decryptor is to decode the
virus body.
Decryptor of virus body seems to be specially designed
not to have a characteristic bytes sequence (descriptor)
longer than 2 bytes (for example: XOR BH,BH and MOV BL,6 is
used instead of MOV BX,0006, because first commands occupies
2-bytes, but the last takes 3 bytes). In reality this program
is mixed with NOPs and other 1-byte codes, not affecting the
execution of decryptor. The sequence of operators in main code
is fixed, but spacing between these operators is variable.
Described technique really eliminates the possibility to find
virus using search based on certain descriptor, because any 2-
byte sequences are found on the disk too frequently. Search
based on the wildcard strings must take into account that
spacing between operators in virus code is variable (from 0 to
16 bytes of NOPs and other silly stuff).
Moreover, the decryptor uses synonyms for code: for
example the XCHG AX,SI command has three (!) different machine
code representations (0c687h, 0f087h, 96h means the same
processor directive - XCHG AX,SI). As well MOV AX,SP and
MOV BX,AX has two representations. That fact also complicates
search based on the wildcard strings, producing many different
wildcards for the same virus.
First the decryptor must determine its position in
memory, because all references in the virus must be relative
to the known point. STARSHIP uses unusual method,
simultaneously suppressing the attempts to trace execution
flow of decryptor with the use of debugger. Virus issues int
03h (it usually points on IRET) and then reads the return
address below (!) the stack pointer SP (LODSW SS:[SI]). If you
use the debugger, it will immediately destroy all words below
the SP, resulting in the malfunction of the rest of decryptor.
Sometimes instead of int 03h virus uses interrupts 01h/11h/12h
as the dummy calls.
Decryption of virus code attached to infected executable
file is done from top addresses to bottom. This sequence makes
tricky setting of breakpoint after the decryption loop because
the last decrypted byte is just below the loop. Hence, if you
place here the breakpoint it will be decrypted, its code
(0CCh) will become garbage and will be executed instead of
invokation of breakpoint routine.
All general processor registers are set to zero after
decryption process prior to start of infected program. Segment
registers are preserved.
When I used MS-Windows or any other graphics user
interfaces - infection of copied files does not take place.
That is possibly because virus uses videomemory as temporary
buffer while infecting files and checks the videomode before
infection.

3. DISK INFECTION

When decryptor finished its work it transfers control to
the disk infection routine. First this code tests DOS version
number (virus works only with versions later than 2.0) and the
presence of video-RAM at BB00:0 (virus physically tests memory
existence at this address via MOV/CMP sequence). Second - it
tests if virus is already resident (checks if special virus
memory dispatcher is present at address 0000:04B0). And third
- STARSHIP determines the original int 13h entry point in BIOS
(it traces the call of int 13h, function 8; this call is used
to determine the physical disk size). The fourth - virus
infects the masterboot via direct call of BIOS int 13h.
STARSHIP modifies MBR in only 3 bytes: head and
sector/cylinder of DOS boot. Virus places its code in 6
consecutive sectors at the disk end (it uses physical disk #1,
last head, last track and last 6 sectors in the last track).
After modification of MBR, boot field of active partition
points on pseudoDOS boot, the first of used 6 sectors. Dump of
pseudoDOS boot is presented in Figure 2. First 5 bytes in
pseudoDOS boot are equal to the original DOS boot beginning
(0EBh, 034h, 090h, 'MS'). The pseudoDOS boot contains the
loader of virus code that is located in next 5 sectors. (Note:
the area at offset 115h..1F9h in pseudoDOS boot is filled with
garbage).
Counter of reboots (byte) is located at offset 1FCh in
pseudoDOS boot. This counter is initialized with random value
in range 0...20h. Sometimes it is initialized with 0FFh - in
this case the counter is not incremented during reboot
(probably such computer cannot be ill). The probability of
this case is approximately 30%.
At offset 1FDh in pseudoDOS boot the XOR mask (byte) can
be found. This mask is used for decryption of 5 sectors
following pseudoDOS boot (these sectors contains virus body).
Moreover, I have found in pseudoDOS boot the code that
loads and executes unknown procedure from sectors 2...6 on
head 0 and track 0. Code from these sectors is executed only
if its checksum is valid. This space between MBR and first
partition (it normally starts on head 1, track 0) is usually
unused and filled with zeros. This area is frequently used by
some computer viruses [3] (DiskKiller for example). But I have
not detected any valuable code in these sectors - this unknown
procedure was probably written only to fool the researchers or
for futer virus extension.
Upon infection virus stores no original MBR copy. It only
saves changes - 3 bytes of original DOS boot head and
sector/cylinder (stored under XOR mask inside 5 sectors of
virus code). If you want to get these parameters you must read
XOR mask from pseudoDOS boot, decrypt the virus body and fetch
necessary 3 bytes from the appropriate positions.
There is another method to restore original MBR. If you
perform the request to read MBR (AX=201h, CX=1, DX=80h,
ES:BX=buffer) via int 13h: virus will read real MBR, restore
its original contents and you will obtain what you want. You
can save this MBR copy on disk, reboot from uninfected DOS
diskette and write it back on harddrive instead of infected
MBR. This method works fine and we used it successfully prior
to creation of removing utility. The only disadvantage of the
described method is that it takes too much time.


4. REBOOT OF INFECTED COMPUTER

When computer reboots the pseudoDOS boot is executed. It
loads virus code in videomemory (at address BB00:0000). PC
without videomemory at segment BB00 are not infected (I have
no computer with monochrome display adapter so the test was
not really performed). Then it decrypts the code in
videomemory, intercepts int 13h and creates special memory
dispatcher at address 0000:04B0. The dispatcher structure is
shown in Fig.3a.
Now all accesses to disk are controlled with the virus
patch on interrupt 13h. This code filters all accesses to MBR
and last 6 sectors on disk. The MBR now looks unchanged and
all writes to last 6 sectors are impossible (error flag is not
returned). Described technique preserves virus from
modification, since its code is installed in DOS file area.
After installation in videomemory virus examines if DOS
interrupts (20h, 21h, 27h) are set. This technique seems to be
universal : I have tested DOS versions 2.0, 2.11, 3.0, 3.30,
4.0 and virus successfully intercepts DOS interrupts. Virus
hanged during reboot only with MS-DOS version 5.00. Section of
virus implementing the task of DOS interception analyses the
validity of CS in the vectors table for DOS interrupts (20h,
21h, 27h) to determine if it is safe to intercept DOS vectors.
DOS interrupt 21h is intercepted by STARSHIP before any
programs can do the same from CONFIG.SYS or AUTOEXEC.BAT. So
any resident software vaccine programs ANTI4US2, FLOSERUM,
TSAFE or others, including programs with driver anatomy would
be unable to detect the operation of virus.
After the interception of DOS interrupts virus waits for
the termination of first program. It test the calls of
interrupts 20h, 27h and of the DOS functions 0, 31h and 4Ch.
When Exit_to_DOS request was issued virus body is moved from
videomemory to the core memory. If terminated program remains
resident virus expands its memory block (glues to resident
tail). If program simply returns to DOS (AH=0, AH=4C) virus
substitutes the exit request with the TSR request (AH=31h) and
creates its own memory block. At this moment memory dispatcher
is modified to point on the new interrupt routines in the body
of virus. From this moment virus stops controlling interrupts
20h and 27h. It uses now only 13h and 21h interrupts.
Dispatcher layout after the shift of virus to the core RAM is
presented in Fig.3b.
If the first loaded program uses graphics - the virus is
erased from videomemory, but it can survive because it has
special restoring procedure (int B0h, at address 0000:02C0, in
the vectors table). That is exotic - the whole interrupt
service routine is located in the interrupt table (it occupies
approximately 3 paragraphs and covers interrupts B0...BB).
This routine checks presence of virus in videomemory (in
reality only one word of videomemory is checked) and if virus
image was destroyed all 5 sectors with virus program are read
to videomemory and decoded (remember that disk image of virus
is XOR-encrypted). Computer hangs only if graphics is used
simultaneously with accesses to DOS, but this situation seems
to be exceptional, because programs usually included in
AUTOEXEC.BAT rarely use graphics.
The performing of all these tests on the infected machine
was very useful and exciting when the very first loaded
program was DEBUG (you must remove or rename AUTOEXEC.BAT; you
can also place DEBUG as the first line of your current
AUTOEXEC.BAT). All virus structures were easily located. The
most interesting were attempts to erase virus image from
videomemory - virus immediately restores its code. In DEBUG
you can investigate the process of virus installation in the
core RAM. You only need to trace the request of DOS function
4Ch (terminate) - and you will see how virus code is moved and
how its memory dispatcher is modified.
After the installation of virus in the core RAM it waits
for the creation of any executable files on the floppy drives
A: and B:. This is usually done with DOS "copy" command when
destination file is located on floppy disk.


4. ACTIVE PHASE

The evil happens when reboots counter reaches 80 (while
initial reboot counter is in range 0..31). Disease appears
after few hours since reboot and this delay depends on the
disk activity. Virus plays music tones and drops colored
points (ASCII=250) without affecting of screen background.
Each point and each tone corresponds to one disk access.
Frequency of tones seems to be proportional to the seccyl
parameter (CX) of int 13h. This musical and visual effect does
not take place in any graphics modes. Colored points appearing
at random screen positions does not affect pseudographics.
Sometimes dots are substituted by spaces. This video effect
corrupts the screen in text mode resulting in the
impossibility of using intensive disk accesses.
When disks are inactive all operates correctly. You can
also use virtual disks or cache without any problems.
Reboot temporary suspends virus activity.
But remember that infected computer will reach active
phase only with approximate probability 2/3. In certain
infected computers triggering of virus is blocked! Behavior of
infected computer depends on the initial value of reboots
counter.


5. ERRORS AND BUGS

When STARSHIP infects harddisk it rewrites 6 last sectors
on the disk. The contents of these sectors are unrecoverably
lost!
Moreover, virus controls all disk accesses (via int 13h)
to prevent the rewrite of its code (all writes to virus area
are simply ignored; error condition is not returned). But if
you load DOS from floppy disk and then modify this restricted
zone (for example if you write file and it occasionally will
occupy the last cluster on the harddisk) - computer will not
reboot later and hang. You will need to recreate MBR to
overcome this problem.
I have determined that the problem may appear when the
first used program is MARK (by TurboPower Software). This
program is used in combination with RELEASE to remove all
resident utilities that were loaded after MARK, to save and
restore the interrupt vectors table and state of EMS memory.
When MARK remains resident virus glues to its memory block and
everything is correct. But when you start RELEASE - computer
hangs. This happens because RELEASE restores the interrupts
table in its state before (!) shift of virus to the core RAM,
when virus was in videomemory. Consequently, vectors 13h and
21h after RELEASE points on videomemory where is no
appropriate handlers at this moment - computer immediately
hangs.
Probably, if you replace your CGA, EGA or VGA adaptor
with MDA, your computer will hang after power-up because there
will be no space to store virus during reboot. (Virus checks
videomemory existence only once - prior to disk infection.)
The use of special restoration procedure at address 0:2C0
in the interrupt vectors table must cause the malfunction of
computers that uses vectors B0...BB during reboot. (These
vectors are used by virus only during reboot, when special
restoration procedure is located at address 0:2C0. When virus
goes resident in conventional memory all these vectors are
cleared with zeroes!)
I have detected that some XT computers with RAMDRIVE
driver in the CONFIG.SYS did not execute some programs
(Harvard Graphics, MS-FORTRAN, QuickBASIC).
Some users have reported the problems with the reboot of
infected PS/2 model 30.
These examples establishes the rule - remove virus when
you fixed its presence. There are no harmless viruses.
Remember: any infected program may produce malfunction of your
computer!


6. STARSHIP DETECTION

STARSHIP virus has one special feature - it does not
modify any executable file on the harddisk. So if you use
passive virus detectors (based on the generation of CRC checks
for the files) to test your harddisk - you will never get the
warning about virus activity. Each file on the harddisk will
remain unchanged. Additionally, if this utility examines the
contents of MBR and DOS boot sector, it will not inform you
about the infection if it uses simple interrupt 13h. STARSHIP
will substitute infected MBR with the original in each access
to MBR via int 13h.
How to detect the presence of STARSHIP? It is a real
problem, because the search of infected files based on the
virus descriptor is impossible. No standard software can be
used to found STARSHIP. Only specially designed scanning
programs that analyses the contents of the EXE header or the
code at the file entry point are useful.
Here follows some useful hints that may be used to
determine the presence of STARSHIP virus.
If you have antivirus program AIDSTEST by Lozinsky
(version later than 115, April 1991) it can scan and desinfect
files (AIDSTEST calls virus "STARSHIP-2616"). Sometimes it
refuses to desinfect file and reports something like "Cannot
remove virus. Delete file(Y/N)?".
If you reboot from original DOS diskette and start FDISK
- it shows (Display Partition Information) that Start and End
of DOS partition are equal for the infected harddisk.
You can also detect the presence of STARSHIP virus in
memory if you examine (unassemble) RAM contents at address
0:4B0 with the help of DEBUG (compare with Fig.3).
Typically executable files has text messages, tables or
zeros at the end. So you can visually examine the tail of
executable file and if you will see approximately 2.7 kbytes
of garbage - that is suspicious and you may suggest the
presence of virus. Experienced programmers may also inspect
the program entry point with DEBUG and analyse the
disassembled listing.
I also recommend not to copy executable files on the
floppies directly. Use archive utilities and then copy
archives on the floppies. This sequence saves disk space and
also preserves from file infection. But this method has one
disadvantage. If the initial file is already infected you will
not be able to detect the presence of virus because it is
incorporated into the archive in compressed form.
The identification of STARSHIP virus is complex because
it extensively uses XOR coding and uses random masks. In the
infected file 100% of virus is encrypted. On disk - 5/6 and in
memory - approximately 60%. That is very interesting feature -
virus is not available in pure form, being variable on disk,
in file and in memory.


CONCLUSION

To my opinion the investigated virus is a very
interesting program. Virus code is highly optimized on the
machine-code level. That was possibly done to place the code
exactly into 5 sectors on disk. Virus uses various software
techniques, it has antitracing and antidisassembling
organization, it has no descriptor. These measures were
effective to some extent, because I have some problems in
source reconstruction. In many cases the source seems to be
not fully adequate.
The present stage of virus technology is characterized
with the complexity of virus search, identification and
reconstruction. This tendency to create complex and sneakily
viruses seems to be general. For example remember the XOR
coded 1701 virus group, the Yankee Doodle [5,6] group of
viruses (called also the TP group [3]) that desinfects all
debugged infected files [3,5] and smart Century virus [7], SVC
series that filters all accesses to the directories and
presents original file size for each infected file.
The name of virus (STARSHIP_1) reveals the idea of the
author to extend the series. Be attentive, remember - the use
of backups may save you a vast of time.


ACKNOWLEDGEMENTS

I am greatly acknowledged to V.V.Snegirev and
A.G.Yakovlev for useful discussions. I also like to thank my
wife Helen for her understanding and support.
I am aknowledged to Vesselin Bontchev, who read the draft
variant of the paper and made many valuable comments.
I also wish to acknowledge the sponsorship of NPO
"POLITON" (Moscow, USSR).

REFERENCES

[1] Dewdney A.K., In the game called Core War hostile
programs engage in a battle of bits, Scientific
American, v.250, 5 (1984) 15-19.
[2] Cohen F., Computer viruses: theory and experiments,
Proc. 2nd IFIP Int. Conf. on Computer Security, (1984)
143-158.
[3] Bezrukov N.N., Computer virusology. Part 1: Main work
principles, classification and catalog of viruses in DOS
operating system, Edition 3.6, date 18.07.1990. (In soft
form : files of 745 kbytes total size, 250p. in Russian).
[4] McBroom V., Computer viruses: what they are, how to
protect against them, Software Protection, v.VIII, 3
(1989) 1-16.
[5] Documentation to VIRUSCAN software package from McAfee
Assosiates. Version 4.3V66. File-SCANV66.DOC, size-38024.
[6] McAfee J., The virus cure, Datamation, v.35, 4 (1989)
29-40.
[7] Documentation to Turbo Anti-Virus software package from
CARMEL Software Engineering. Version 6.80A. File-
README.DOC, size-65566.
==================================================================

Table 1. Layout and size of virus procedures.
(the box indicates the encrypted memory section)

Size Offset (hex) Description


3% 000 - 04F Variables and buffers (see Fig.1)
5% 050 - 0C1 Interrupt 13h handler
10% 0C2 - 1C7 Interrupt 21h handler
11% 1C8 - 312 Active part & check for DOS ready
2% 313 - 340 Random number generator (RND)
7% 341 - 3F7 Interrupts 20h, 21h, 27h handlers
+--- encrypted --------------------------------------------+
| 25% 3F8 - 692 Infector of EXE/COM file includes: |
| 9% 3F8 - 4DD input logic |
| 10% 4DE - 5E9 create infected code |
| 6% 5EA - 692 output logic |
| 3% 693 - 6E5 Tables |
| 3% 6E6 - 738 Startup code for EXE/COM |
| 12% 739 - 88F Infect disk |
| 2% 891 - 8BF Interrupt 01h handler (trace) |
| 11% 8C0 - 9D7 PseudoDOS boot and int B0h handler |
+----------------------------------------------------------+
4% 9D8 - A4E Remover of code from videomemory
2% A4F - A8F Buffers (CS, IP, SS, SP, etc.)


=======================================================

Table 2. Minimal and maximal sizes of infected
executable files.
+-------------+------------------------+
| File type | Minimal Maximal |
| | size size |
+-------------+------------------------+
| | |
| .COM | 1917 62202 |
| | |
| .EXE | 1917 512 K |
+-------------+------------------------+

==============================================================================

Figure 1. Memory block header (M-block) and memory dump of STARSHIP
virus located in core RAM. Virus uses segment 18FB, and its memory
block is at 18F2:0).

------------------- M-memory block containing virus --------------------------


18F2:0000 4D 08 00 B0 00 0A 00 A3-8E 0B A1 0C 00 A3 90 0B M...............


------- PSP of file, which termination caused the virus installation ---------

18F3:0000 CD 20 A3 19 00 9A F0 FE-1D F0 2F 01 0B 18 3C 01 . ......../...<.
18F3:0010 0B 18 56 05 0B 18 0B 18-01 01 01 00 02 FF FF FF ..V.............
18F3:0020 FF FF FF FF FF FF FF FF-FF FF FF FF EE 18 E0 FF ................
18F3:0030 00 90 14 00 18 00 F3 18-FF FF FF FF 00 00 00 00 ................
18F3:0040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
18F3:0050 CD 21 CB 00 00 00 00 00-00 00 00 00 00 20 20 20 .!...........
18F3:0060 20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20 .....
18F3:0070 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 ........


------------------ Here follows the code of virus (CS=18FB) -----------------

18FB:0000 E9 01 10 4E 0A 00 10 00-00 00 00 00 00 42 3A 5C ...N.........B:\
18FB:0010 54 4D 50 5C 44 52 4F 5A-46 49 4C 41 2E 43 4F 4D TMP\DROZFILA.COM
18FB:0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
18FB:0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
18FB:0040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 FF ................
18FB:0050 E9 93 06 3E 53 54 41 52-53 48 49 50 5F 31 3C 80 ...>STARSHIP_1<.
18FB:0060 FA 80 75 41 83 F9 01 75-3F 0A F6 75 38 80 FC 02 ..uA...u?..u8...
18FB:0070 75 29 1E 50 E8 13 03 58-9C FF 1E B8 04 1F 72 18 u).P...X......r.
18FB:0080 50 56 72 16 B8 01 00 BE-BE 01 26 89 40 02 B0 01 PVr.......&.@...
18FB:0090 26 88 40 01 5E 58 F8 FB-EB 7C 3C 80 FC 03 74 F6 &.@.^X...|<...t.
18FB:00A0 80 FC 05 74 F1 E9 3E 01-80 FE 08 75 F8 51 02 C8 ...t..>....u.Q..
18FB:00B0 80 F9 CC 59 72 EF 80 FD-FE 72 EA 80 FC 02 74 D6 ...Yr....r....t.
18FB:00C0 75 D9 FF F1 E8 9C 2E 80-3E 4F 00 00 75 18 50 1E u.......>O..u.P.
18FB:00D0 8C C8 2D 09 00 E8 A9 02-A1 3C 00 48 E8 A2 02 2E ..-......<.H....
18FB:00E0 F6 16 4F 00 1F 58 80 FC-3C 75 31 2E 83 3E 0B 00 ..O..X....
18FB:00F0 00 75 6E E8 6E 00 75 69-9D E8 CC 00 72 18 50 51 .un.n.ui....r.PQ


==================================================================

Figure 2. Dump of pseudoDOS boot sector
(thin line denotes random garbage).

0000 EB 34 90 4D 53 BF 05 00-CD 13 73 09 32 E4 CD 13 .4.MS.....s.2...
0010 4F 75 F5 CD 18 C3 B9 01-00 E8 E9 FF 80 3E 00 7E Ou...........>.~
0020 EB 75 10 A0 02 7E BB 00-7E E8 97 00 0A E4 74 03 .u...~..~.....t.
0030 80 EF 02 06 53 CB FA 33-C0 8E D0 BC 00 7C 8B F4 ....S..3.....|..
0040 8E C0 8E D8 FB FC BF 00-06 B9 00 01 F3 A5 EA 53 ...............S
0050 06 00 00 B9 37 00 BE D6-06 BF C0 02 F3 A4 BF B0 ....7...........
0060 04 B9 08 00 F3 A4 1E C5-06 4C 00 AB 8C D8 AB 1F .........L......
0070 FE 06 FC 7D A1 FC 7D B9-CC FE BB 00 7C BA 80 08 ...}..}.....|...
0080 0A C0 74 08 50 B8 01 03-E8 7A FF 58 41 89 0E DB ..t.P....z.XA...
0090 02 88 36 DF 02 06 BB 00-BB 8E C3 88 26 E7 02 CD ..6.........&...
00A0 B0 26 A2 63 01 26 8C 1E-C2 00 07 FA C7 06 4C 00 .&.c.&........L.
00B0 B0 04 8C 1E 4E 00 FB BB-00 7C B8 06 02 BA 80 00 ....N....|......
00C0 E9 53 FF 53 51 B9 0A 0A-32 E4 26 30 07 26 02 27 .S.SQ...2.&0.&.'
00D0 43 E2 F7 59 5B C3 C4 02-00 00 50 06 53 B8 00 BB C..Y[.....P.S...
00E0 8E C0 BB 50 00 26 80 3F-E9 74 1E 52 51 B8 05 02 ...P.&.?.t.RQ...
00F0 B9 00 00 BA 80 00 9C 2E-FF 1E B8 04 B0 00 B9 0A ................
0100 0A 26 30 07 43 E2 FA 59-5A 5B 07 58 CF CD B0 9A .&0.C..YZ[.X....
+--------------------------------+
0110 5F 00 00 BB EA|1E 0E 1F-8E C0 33 FF 50 FC 32 C0| _.........3.P.2.
+--------------------+ |
|0120 B9 50 00 F3 AA E8 F6 F7-8B F7 B9 0A 0A F3 A4 E8| .P..............
|0130 98 F9 58 FA A3 B5 04 A3-C1 04 B8 90 90 A3 B0 04| ..X.............
|0140 A3 BC 04 C7 06 BF 04 C5-00 B8 EB 05 A3 C8 04 B8| ................
|0150 EB F4 A3 D4 04 BF CA 04-BE DB 04 06 1E 07 A5 A5| ................
|0160 A4 FB A3 D9 04 A3 C8 02-C7 06 E0 02 CD 13 C7 06| ................
|0170 E2 02 EB 0D FE 06 D9 02-CD B0 B9 37 00 BF C0 02| ...........7....
|0180 1E 07 8C D8 F3 AA 07 1F-C3 B4 62 E8 7A F7 C3 90| ..........b.z...
|0190 90 90 90 90 90 90 90 90-90 90 A4 4B 4C EA A6 8C| ...........KL...
|01A0 BE 23 54 F4 BC E8 B8 6B-5B F1 B2 EC B2 81 5E F6| .#T....k[.....^.
|01B0 88 D0 8C BC 64 CC 8E CC-86 69 6A C2 84 C8 80 6F| ....d....ij....o
|01C0 FA 2B C0 8E D0 8E C0 8E-D8 B8 00 7C 8B E0 FB 8B| .+.........|....
|01D0 F0 BF 00 7E FC B9 00 01-F3 A5 E9 00 02 B9 10 00| ...~............
|01E0 8B 36 85 7E F6 04 80 75-08 83 EE 10 E2 F6 EB 37| .6.~...u.......7
| +-----------------+
|01F0 90 BF BE 07 57 B9 08 00-F3 A5|74 91 05 AD 55 AA ....W.....t...U.
+-----------------------------------+

==================================================================
Figure 3. Dispatcher code located at absolute address 0:4B0.



a) virus code located in videomemory

0000:04B0 CD B0 INT B0 <== int 13h
0000:04B2 9A 5F 00 00 BB CALL BB00:005F
0000:04B7 EA 3D A3 00 F0 JMP F000:A33D

0000:04BC CD B0 INT B0 <== int 21h
0000:04BE 9A D6 03 00 BB CALL BB00:03D6
0000:04C3 EA 60 14 73 02 JMP 0273:1460

0000:04C8 CD B0 INT B0 <== int 20h
0000:04CA 9A DD 03 00 BB CALL BB00:03DD
0000:04CF EA 3F 14 73 02 JMP 0273:143F

0000:04D4 CD B0 INT B0 <== int 27h
0000:04D6 9A 93 03 00 BB CALL BB00:0393
0000:04DB EA 66 63 73 02 JMP 0273:6366



b) after removing of code from videomemory
(segment CS=18FB is where virus resides)


0000:04B0 90 NOP <== int 13h
0000:04B1 90 NOP
0000:04B2 9A 5F 00 6D 19 CALL 18FB:005F
0000:04B7 EA 3D A3 00 F0 JMP F000:A33D

0000:04BC 90 NOP <== int 21h
0000:04BD 90 NOP
0000:04BE 9A C5 00 6D 19 CALL 18FB:00C5
0000:04C3 EA 3D A3 00 F0 JMP 0273:1460

0000:04C8 EB 05 JMP 4CF <== int 20h
0000:04CA EA 3F 14 73 02 JMP 0273:143F
0000:04CF EA 66 63 73 02 JMP 0273:6366
0000:04D4 EB F4 JMP 4CA <== int 27h

===============================================================
All corrections and remarks will be greatly appreciated. Send
information directly via E-mail address ([email protected]) or
in comp.virus group of USENET (I am monitoring it permanently).