FTP'd from cert.org:
pub/virus-l/docs/starship.txt

           STARSHIP - interesting file-boot virus.                               
                         Muttik I.G.
                (Internet: MIG@politon.msk.su)


     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:
4<IP<13h. Spacing  between stack  segment and  code segment is
constant: 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..<u1..>..
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 (MIG@politon.msk.su) or
in  comp.virus group of USENET (I am monitoring it permanently).