Skip to main content
© Pain

                             PART I
                 THE ULTIMATE VIRUS KILLER BOOK


              6 - HOW TO RECOGNISE VIRUS INFECTION

 6.1      WHAT CAN GO WRONG

 It  is  very difficult to summarise in short what can  go  wrong
once you've been infected by a virus.  A virus in your system may
easily  become corrupted (i.e.  mutant) because  another  program
inadvertently accesses the same bit of memory that the virus uses
to store itself in. If the virus is not sufficiently corrupted to
disable  it from multiplying afterwards,  it may write  corrupted
copies  of  itself.  This  is the way mutant  viruses  come  into
existence.  There  is  no  telling what can  go  wrong  when  you
encounter  these  mutant  viruses.  In the  multitude  of  cases,
however,  it  will  get down to your computer crashing  (with  or
without the notorious little 'bombs' at the left-hand side of the
screen),  or  disk data suddenly becoming inaccessible due  to  a
mutant  virus  copying  itself to  the  bootsector.  This  latter
problem  can,  with the aid of the "Ultimate  Virus  Killer",  be
solved.

 To try and determine whether something that went wrong  actually
went wrong because you're dealing with a virus,  it is  important
to establish when viruses strike, when they are actually executed
by the Operating System.  In most cases this happens  immediately
before or after a read-or write-operation to a  floppy-,  hard-or
RAM-disk  has been made.  If you've just inserted a disk to  read
its  directory and something goes wrong around then,  chances  of
your dealing with a virus are significantly  increased.  Usually,
viruses  will then check to see if the destruction  criterion  is
met, for example if it has been copied a specific amount of times
or if it is a specific date. The destruction routine will usually
be  called  within a split  second  afterwards.  The  destructive
effects  of  viruses vary widely (see appendix A for  a  complete
list  of viruses and their effects),  but they usually slow  down
the system,  do something to your storage media,  print a message
on  the screen or make a sound.  A particularly common  one,  the
Ghost Virus,  inverts the vertical movement of the mouse pointer,
for example.

 Whenever something suspicious happens,  you should turn off your
computer  for  thirty  seconds.  You should then  boot  with  the
"Ultimate  Virus Killer" disk in the drive.  Because  you  should
have kept that disk write-protected at all times, there is really
not  a  chance that there will be a virus in  your  system  then;
memory  has  been  cleared entirely and no  new  virus  has  been
loaded.
 After  that you should use the "Ultimate Virus Killer" to  check
all your disks and all files on them to see if they are  infected
by viruses. Boot files of suspicious disks should be written on a
floppy  disk and sent to the address mentioned in your  "Ultimate
Virus  Killer",  as should programs and/or accessories  that  you
think may have caused a couple of system variables in the 'System
Status Screen' to be inverted (please refer to the manual part on
the System Status Screen for more information about that).
 Once you have checked all your disk's bootsectors and files  you
are virus-free.  You should refrain from booting any of the disks
that you had to send boot files in of,  and not execute any files
that  were  considered suspicious - at least not until  you  hear
that they are safe to work with.

 6.2      HOW TO PREVENT VIRUS INFECTION

 Although  there is no 100% full-proof way of protection  against
viruses,  there  are some points that you should always  keep  in
mind to drastically reduce your chances at infection.

 6.2.1    KEEP YOUR DISKS WRITE PROTECTED

 Although this same procedure on other computer systems might not
quite be as safe as you'd expect,  write-protecting a disk on any
Atari TOS computer is a guaranteed protection against viruses. So
if you have disks that need never be accessed by write operations
(disks  that never need to be written on,  for example  to  store
save-games or hiscores or your own work of any kind), just write-
protect them!
 Logically,  write-protecting  is no full-proof method  for  your
working disks, as these will have to be saved to at times (during
which  moments  they  cannot remain write-protected  and  may  be
infected).

 6.2.2    ALWAYS BOOT WITH THE SAME, WRITE-PROTECTED DISK

 Format  a  disk,  then check it for viruses with  the  "Ultimate
Virus Killer" and immunize it.  Next,  write-protect it and leave
it  in the boot drive WHENEVER YOU TURN ON YOUR SYSTEM  or  RESET
YOUR SYSTEM.  Bootsector virus infection will now be  impossible.
This may be a bit hard to remember if you don't always  auto-boot
from a hard disk,  as quite a few different disks will be  likely
to be in your disk drive in that case.  If you do not have a hard
disk and you want some accessories and AUTO folder programs to be
installed,  just  copy them all to this boot disk.  After  having
done that,  however,  you should re-check all those files and the
boot disk's bootsector with the "Ultimate Virus Killer"!

 6.2.3    CHECK ALL DISKS YOU GET

 Whenever  you receive disks from a friend (or anyone  else,  for
that  matter),  or  whenever you have bought  a  program  (Public
Domain,  but  also  commercial!) or a magazine with  cover  disk:
Check it with the "Ultimate Virus Killer"!  Possible viruses  can
then be killed at once, and you are advised to warn the person or
company who sent or sold you the disk in case of infection. Other
kinds of bootsectors will either be recognised directly (in  case
of  known  harmless  software)  or  analysed  (in  the  case   of
bootsectors not yet recognised).
 Please do not forget to check commercial software, even when you
have just now bought it in a shop!

 6.2.4    ANTI VIRUS TOS

 A  nice tip for the hardware-and machine code freaks among  you.
Requirements  are  a reassembler program (such  as  "Detective"),
EPROMs and an EPROM programmer package.  Also, you'll need a fair
bit of system knowledge and a hacker's attitude.
 You can disassemble the Operating System,  change the bootsector
read  routine  to  make  it ask whether  or  not  to  execute  an
executable bootsector if one is found, assemble it again, and put
(burn) it on the EPROMs using the EPROM programmer. Make sure the
Operating  System  routines you altered will also check  for  the
magic  longwords  with non-executable bootsector viruses  on  the
proper offsets (see 2.2.2).
 Creating a full-safe method to check for the executability of  a
bootsector  before  it is executed it not possible by  any  other
means,  as the Operating System's bootsector check (and  possible
execution) is done even before the hard disk driver is  installed
and before the first AUTO folder programs are executed.  The next
available method would be to build such a virus check routine  in
a hard disk driver or into an AUTO folder program,  but by then a
virus can already have installed itself and will make sure  these
programs  find nothing suspicious,  having hidden  cleverly  from
view.
 Personally,  I  used  to work with a MEGA ST that had  TOS  1.07
(this is a patched version of STE TOS 1.06,  which also  includes
numerous other features and that is thoroughly debugged,  done by
a  couple  of  friends of  mine).  It  is  perfect,  though  this
particular  effort  was only useful in  German  machines,  as  it
involved a German TOS version that, among other things, supported
the  different layout of a German ST's keyboard).  It's  the  one
thing I've missed since I switched to the Falcon.

 Although  I have written to Atari with the suggestion that  they
included  this  feature in their new Falcon  TOS  versions,  they
haven't  done  so.  I think this has something to do  with  Atari
still  not  officially  wanting  to  admit  that  viruses  exist,
probably  the  same  reason why you won't  find  a  big  software
company like Hisoft or,  indeed,  Atari itself,  marketing  virus
killers.  All in all this is a bit of a shame,  for with such  an
option  built  into the new TOS  versions,  at  least  bootsector
viruses  could surely have died out rapidly,  especially  on  the
Falcon.

 6.2.5    A SPECIAL TIP FOR SOFTWARE AUTHORS

 The  problem  with original game software  in  conjunction  with
virus  infection  is  that  a virus  writing  itself  across  the
bootsector  is more than likely to result in the game  completely
failing to work due to loss of its own bootsector program - which
it would have needed to start in the first place.  There is a way
to prevent this,  though this can only be used if you have a  bit
of free space left on your game's boot disk and the BPB is valid.
Also,  you  really need to be 'at home' in the world of  creative
disk editing.
 When  a  virus has infected the bootsector,  the game  will  not
load.  Instead,  the  Operating System will take over  after  the
virus has installed itself,  and try to read the disk's directory
in  search for an AUTO folder.  Any programs in that AUTO  folder
will then be executed as usual. That is the moment when something
can be done about the virus that infected your piece of software!
If  the game's bootsector works,  the AUTO folder will  never  be
executed and the game will load automatically.  The track used up
by the AUTO folder and a possible program in it will never  serve
their function. The game will work and everybody is happy. If the
game's bootsector does not work,  however,  such as would be  the
case when virus infection has occurred,  you simply make sure the
AUTO  folder contains a neat little program that writes back  the
proper  bootsector  to the disk and clears memory from  A  to  Z,
followed by a reset. This little program should not use Operating
System calls for the writing of that bootsector, as the virus may
have  patched these Operating System sub-programs and would  then
write  itself to that bootsector again as if nothing  would  have
happened.
 This method will take up at least 1 cluster for the  program,  1
cluster  for the AUTO folder,  1 cluster for the directory and  a
minimum of 1 cluster for a FAT.  Some heavy BIOS Parameter  Block
manipulating  is in order here.  Should you not want to do  heavy
disk manipulation, it will cost you about three tracks.

 Protection  against link viruses is also possible,  of course  -
though  the  evil purpose of such a virus will  probably  already
have  been fulfilled (at least partly) by the time something  can
be done about it.  At least you could include some checks in your
program code that check if the header and the program length  are
unchanged (on the disk!). This way you can at least tell the user
whether a link viruses has contaminated the software.
 The  "Ultimate  Virus  Killer",   for  example,   checks  itself
completely for link virus infection each time it starts, and will
even give you the name of the virus in case of contamination.

 6.2.6    ALTERNATIVE WAYS

 There are a number of other methods that can be  employed,  with
varying  effect,  to  battle the occurrence of  viruses  on  your
system.

 6.2.6.1  GUARD PROGRAMS

 An  alternative way to protect yourself from virus infection  is
the  use  of a Guard program.  This is a small  program  that  is
resident  in memory (although it might also be a desk  accessory)
which monitors all use of the Operating System's read/write  sub-
programs.  Apart  from the fact that these programs can tell  you
when something is attempting to write to disk,  they can also  be
used  to  lock  a  hard disk partition  from  being  written  to.
Supposing  partition  "E" is your working partition and  all  the
other ones only contain programs that never write  anything,  you
can lock all partitions except partition "E".
 Some  clever partition guard programs are written by Henrik  Alt
(on  the  disk of his German  "Sagrotan"  virus  killer),  Volker
Söhnitz (on the disk of his German "Virendetektor" virus  killer)
and  Omikron  (built  into their  excellent  resident  "Mortimer"
multi-utility). I believe Delta Lab's "Poison!" virus killer also
has a possibility to check for viruses on the fly as it were.

 6.2.6.2  THE DESKTOP.INF/NEWDESK.INF FILE

-----------------------------------------------------------------

        #a000000
        #b000000
        #c7770007000600070055200505552220770557075055507703111103
        #d
        #E 1B 03
        #W 00 00 04 03 43 10 00 @
        #W 00 00 0D 08 2A 0B 00 @
        #W 00 00 0E 09 2A 0B 00 @
        #W 00 00 0F 0A 2A 0B 00 @
        #M 00 00 00 FF A FLOPPY DISK@ @
        #M 00 01 00 FF B FLOPPY DISK@ @
        #T 00 06 02 FF   TRASHCAN@ @
        #F FF 04   @ *.*@
        #D FF 01   @ *.*@
*       #G 03 FF   *.PRG@ @
*       #G 03 FF   *.APP@ @
*       #Y 03 FF   *.GTP@ @
*       #F 03 04   *.TOS@ @
*       #P 03 04   *.TTP@ @

-----------------------------------------------------------------

             A typical DESKTOP.INF/NEWDESK.INF file
      (Yours probably looks different, but never mind that)

 You  probably know that some of the common  desktop  parameters,
such as its colours, its printer definition, its currently opened
windows  and  their sizes and locations,  as well as  some  other
values, can be stored, via the "Save Desktop" option, into a file
called  DESKTOP.INF  (or  NEWDESK.INF on TOS  versions  2.02  and
higher).
 What  rather less people know,  however,  is that this file  can
also  be  used to change the extensions belonging  to  executable
files. Particularly some link viruses only multiply to files that
have either a PRG or TOS extension.  If one were to change  these
extensions,  link  viruses would not find any files  to  multiply
themselves to, and your program files would be protected.
 Special  attention  needs  to  be given to  the  lines  with  an
asterisk  (*) in front of them in the table above.  These  lines,
believe it or not, determine which file extensions invoke certain
types  of  program execution.  They are slightly different  in  a
NEWDESK.INF  file (including one or two extra  values,  probably,
and an additional "@" after the extension names).
 PRG and APP files are started with full use of GEM, which can be
seen from the "#G" that their lines start off with.  TOS programs
are  executed like the above with the exception that GEM can  not
be used - you will probably have noticed that TOS programs  never
use pull-down menus,  alert boxes and other GEM gizmos.  TTP is a
special  version  of a TOS file that first requests the  user  to
enter  certain  parameters  (TTP  is an  acronym  for  TOS  Takes
Parameters).  Added in more recent Operating System versions, GTP
files are very much like TTP files with the difference that  they
can
 use GEM (GTP is an acronym for GEM Takes Parameters).
 You are free to change these extensions to anything you want, as
long as the names consist only of alfa-numerals and you keep into
consideration  that  lines  starting  with  "#G"  apply  to   GEM
programs,  "#Y" to "GEM Takes Parameters" programs,  "#F" to  TOS
programs  and "#P" to "TOS Takes Parameters"  programs.  You  can
change them to rather less popular extensions,  which would  make
sure that link viruses do not find the regular  (PRG,  APP,  TOS,
etc.)  extensions that programs usually need to have for them  to
get infected.
 Make  sure you also change all the corresponding file  names  on
all your disks and hard disk partitions,  and keep in the back of
your mind that you will have to re-configure the "Ultimate  Virus
Killer"  to  actually  recognise  the  new  file  extensions   as
executable ones (see "The Manual", chapter 11).
 Of  course,  link viruses that copy themselves to just any  file
with  just any extension cannot be protected against  using  this
method.  These viruses,  however,  have the advantage of  getting
discovered  more quickly anyway because they  potentially  infect
(and,  thus,  corrupt) picture files,  song files, text files and
generally all other data files, too.

 It  should  to be noted that most alternative  desktop  programs
("NeoDesk", "KAOSDesk", "Gemini", "TeraDesk", "Thing" and "Ease",
among   others)   use  their  own  specific   versions   of   the
DESKTOP.INF/NEWDESK.INF  file,  almost always with another  name.
They  might also cater for even more different file  types  (like
"NeoDesk",  that has the NPG extension for special programs  that
make  use  of parts of  "NeoDesk"  itself).  However,  their  own
equivalents of these information files can also be doctored  with
so that new file extensions can be given.
 Just make sure that you always keep a backup of all non-doctored
files in case you make a mistake while editing.

 6.3      CALL TO ALL BULLETIN BOARD SYSTEM OPERATORS

 A Bulletin Board System (or,  for short,  BBS) is easy to access
for  a  lot  of people who have a  modem;  it  allows  files  and
information  to be exchanged between many users and between  just
about any computer system.
 It is easy to imagine a file infected by a link virus ending  up
on such a BBS;  especially link viruses cannot easily be  noticed
when  included  in  a  program  file,  certainly  not  if  it  is
compressed and put into a package of files the likes of which all
modem  people  create with archive programs  like  "Arc",  "Arj",
"Lzharc",  "Zoo"  or "ST Zip".  It is likely that the  person  to
upload  that specific file (i.e.  the person who sent it  to  the
BBS) does not know that it was infected in the first  place,  but
intentional release of link viruses on a BBS would not require  a
lot of work.  So it is easy to imagine that a BBS could be a real
hearth of virus infection.  Should one of those infected programs
get  downloaded (taken from the BBS) very often,  you could  have
something like a computer link virus epidemic on your hands!
 It is strongly advisable for all Bulletin Board System operators
(sysops,  wizops,  whatever)  to  check all the  files  that  are
uploaded to them with the "Ultimate Virus Killer" (which means  a
lot  of  work,  but it should pay off  in  the  end).  Especially
Bulletin Board Systems that distribute vast quantities of  Public
Domain software are already rumoured to be very risky,  which  is
often stated in books and articles about viruses.
 The  "Ultimate  Virus Killer" is a powerful tool  which  enables
fast checking of whole directories of files.  All you need to  do
is  de-archive the files.  As the "Ultimate Virus Killer" can  be
run from a CLI,  it is possible to create a batch file that  will
de-archive  the  files for them to be checked  by  the  "Ultimate
Virus  Killer"  itself from that same batch file.  So now  it  is
finally  possible to get rid of that rumour - you can  make  your
BBS safe!
 This  paragraph also applies to operators of large Internet  FTP
(File Transfer Protocol) sites,  which are basically even  larger
Bulletin Board Systems accessible through the enormous Internet.

 6.4      CALL TO ALL SOFTWARE MANUFACTURERS

 There  are many commercial programs that use the  bootsector  to
load and start themselves. Especially games make extensive use of
this  facility.  Besides games that use the bootsector  to  load,
there  are  also many programs that check specific bytes  in  the
bootsector  as  part of their copy protection  method  (not  just
games). This means that bootsector viruses would copy their image
across the part of the bootsector that contains the original sub-
program  to load the (game) software,  or the part that  contains
the  specific codes that the software needs to be able  to  check
for  its copy protection.  In both cases,  this will most  likely
cause the program in question to cease working properly, or cease
working at all.
 Such  bootsectors  can,  to large extent,  be  restored  by  the
"Ultimate  Virus Killer".  There is a library of  commercial  and
non-commercial bootsectors supplied with it,  allowing for  users
to restore the necessary boot code which should make the software
run properly again.
 Since  more and more bootsectors sub-programs on more  and  more
software titles become available every day,  it is impossible for
the  "Ultimate  Virus  Killer" to be able  to  restore  them  all
because a lot of them are not even recognised yet.  Each  update,
though,  recognises  more  of  these as users send  in  more  new
bootsector dump files.  None,  however, can help more efficiently
than the software manufacturers themselves,  by sending in  their
unrecognised  software  so  that  it  can  be  included  in  each
forthcoming  "Ultimate Virus Killer"  version.  Of  course,  they
should  also  check all their master copies with  a  really  good
virus killer before sending it off to be duplicated.  Quite a few
of  the major European software houses and  distributors  already
use the "Ultimate Virus Killer" to keep their software virus-free
now, and they are all quite satisfied.
 This  entire paragraph is also valid for demo programming  crews
who supply their demo disks with auto-booting bootsectors, or who
have special virus free disk bootsectors.

 6.5      CALL TO ALL ATARI TOS COMPUTER USERS

 It  is  now  finally possible to utterly  obliterate  the  virus
problem  on the Atari TOS computer platform.  If  everybody  just
gets his hands on the "Ultimate Virus Killer" software and checks
all  disks regularly,  there will be no problem left.  Tell  your
friends  and,  of course,  please feel free to get your very  own
copy of the latest version of the "Ultimate Virus Killer".
 Just  check all disks you get,  and always boot with  the  same,
non-infected and write-protected disk in your boot drive. Only in
that  case  will you be able to say,  "Virus infection  does  not
happen to me."

 6.6      CALL TO ALL VIRUS KILLER PROGRAMMERS

 During  the years that have been spent killing  viruses,  people
must  have  developed at least a hundred or  so  different  anti-
viruses  and  virus  free  disk  bootsectors.   Of  course,  this
abundance  of  bootsector programs does not quite add  to  safety
where the prevention of virus infection is concerned;  there  are
viruses that 'mimic' anti-viruses or virus free disk bootsectors,
and  the general abundance of such bootsectors that are  not  yet
recognised by the "Ultimate Virus Killer" often causes confusion.
 Therefore   I  would  like  to  call  upon  all   virus   killer
programmers: Do not create new 'virus free' bootsectors any more!
There are already more than enough,  for at the moment just about
every  virus  killer  and every hackin' group has  one  of  those
bootsectors  of its own.  If you want to design one  nonetheless,
please  be as kind as to send it to the address mentioned in  the
"Ultimate  Virus  Killer"  so  that it may  be  included  in  the
"Ultimate Virus Killer" recognition algorithms swiftly!

 The  reasons  mentioned  above are also the  explanation  why  a
special "Ultimate Virus Killer" 'virus free' bootsector has never
been  written,  as it is believed that these bootsectors  may  be
handy but are not perfect at all. You see, generally, they always
rely on the fact that the user will notice it when a 'virus free'
message does not appear upon system boot-up, which would point at
the bootsector's destruction and possible virus  infection.  And,
should the attentive user notice,  it is already too late:  There
is already a virus on the disk and God knows where it has  spread
to already.
 That is why a method called disk immunization has been developed
which,  by now, has been adopted by many virus killers as well as
some  resident virus watch programs,  good anti-viruses and  even
the odd format program. This method of immunization is based upon
the habit of quite a few bootsector viruses (some 20%,  including
most of the really wide-spread ones) to check if they are already
present  on a bootsector before they  multiply  themselves.  They
generally don't check the entire bootsector but just a small part
- one or two values, to be more precise. And by making sure these
few particular values are present on a disk's bootsector, you can
make sure that a specific virus will not copy itself onto it.
 Unfortunately this method excludes immunization against  viruses
that  use  a particular location in a bootsector to check  for  a
value  that already needs to have another value stored there  for
immunization  against  an earlier or  more  'popular'  bootsector
virus.  This disk immunization method might not be  perfect,  but
it's the best protection against bootsector virus you can have on
disks that cannot be write-protected at all times.
 The  following  table is a list of  all  possible  immunizations
possible  against  all currently known  bootsector  viruses.  The
leftmost column is the offset (in hexadecimal notation) that  the
value (type "L" for longword, type "W" for word) needs to be on.

-----------------------------------------------------------------
    Offset/type:  Value:      Protects against:
-----------------------------------------------------------------

*(1)$000.W        $6038       Signum  (all  versions  except  D),
                              MAD,   ACA,  Freeze,  BHP,  Arnold/
                              Rambo, G-Data, DJA
    $000.W        $4E71       Joe
    $000.W        $601C       Anti-ACA, Puke A, Upside Down
    $000.W        $6A38       Grim Reaper (first half of
                              immunization)
    $000.W        $EB34       Wolf
    $000.L        $5A4F4348   Zoch (ASCII: "ZOCH")
    $000.L        $60380666   Evil
*   $002.W        $001C       Maulwurf
    $002.W        $07C4       Signum D
    $01E.L        $263C0000   Gotcha Xeno (2)
*   $03A.W        $4E75(3)
    $03A.W        $41FA       Grim Reaper (second half of
                              immunization)
*   $19E.L        $70756B65   Puke #2 (ASCII: "puke")
*   $1A2.L        $27182818   Goblin
*   $1B4.L        $2A2A2A20   P.M.S. (ASCII: "*** ")

-----------------------------------------------------------------

(1) Entries  with an "*" in front of them have been  included  in
    the  "Ultimate  Virus  Killer"  advanced  disk   immunization
    method.

(2) It  would have been possible to immunize against  the  Gotcha
    Xeno Virus
, but the area that the immunization code is stored
    in  is  an  area in which,  according to  Atari,  it  is  not
    "officially  allowed"  to  store boot programs  ($06  to  $3A
    exclusive).  To prevent possible problems, it was decided not
    to  include  the immunization,  the virus being  fairly  rare
    anyway.

(3) The  $4E75 on offset $3A is the opcode for the mnemonic  RTS,
    which is located at the right spot for the branch on offset 0
    ($6038)  so  that  it  immediately returns  back  and  it  is
    impossible  to  execute  a  real  program  in  an   immunized
    bootsector.

     "Ultimate Virus Killer" immunization offsets and values

 The  "Ultimate  Virus  Killer"  also  makes  an  immunized  disk
bootsector  executable,  thus rendering it immune for all  proper
anti-viruses and the following true viruses:  Screen,  C'T,  FAT,
5th GenerationFinlandMedia Change and Macumba 5.2.
 Should  you decide to develop an anti-virus or a resident  virus
watch program that checks for executable bootsectors,  make  sure
it  does not suspect an executable disk that is  immunized  using
the  advanced  disk immunization method of  the  "Ultimate  Virus
Killer",  for in that case you will be dealing with a safe  disk.
In  most cases it will suffice to check only the word  values  on
offsets 0 and $3A.
 Please also be sure to test the offsets where the magic longword
'$12123456'  can  be located (see 2.2.2),  especially  with  non-
executable bootsectors.

 A note on disk immunization and MS-DOS compatibility:

 The  desktop  of TOS versions 1.04 and higher formats  disks  so
that  they can be read in MS-DOS compatible systems (IBM PCs  and
the like). This is actually very easy to do. The TOS desktop does
it  by placing the hexadecimal word $E900 on the first  location;
"FastCopy Pro" does it by placing the hex longword  $EB349049424D
there. However, word values of $E918, $E983, $E96E, $E9E4, $E9EF,
$EB29,  $EB2C, $EB36, $EB3C, $EB3E, $EB40, $EB45, $EB4A and $EB6E
can be found on MS-DOS disks, too, and seem to suffice.
 Because  MS-DOS  compatibility needs a specific  value  on  that
first  location  of the bootsector,  this  automatically  renders
useless  the  advanced disk immunization method  described  above
because it needs another value ($6038) present there.  Immunizing
a  disk  will cause a disk no longer to  be  MS-DOS-  compatible.
Unfortunately  there  is  no  way  around  this  without  totally
sacrificing the power of immunization.
 If you want to exchange files between a TOS computer and an  MS-
DOS  machine,  you  should  maintain a  small  number  of  MS-DOS
compatible,  non-immunized  swap disks that you check  regularly.
That is all that can be advised.