Computer viruses are similar to sequels of major movie classics: just when you least expect it, they strike again — and are more dreadful than the first time.
Not long ago, the term 'virus' sent a cold shiver down the spine of many ST users: these small programs posed a threat to every system, protective measures were not yet widely spread. Even though for the majority of you the excitement has subsided and peace and quiet have mostly returned to the boot sector, unfortunately, there is still no reason for a final all-clear. Because remarkable things have happened within the last twelve months, of which I would like to inform you.
ATARI VIRUS KILLER
As you may know, I am the author of a program that was once known as 'Virus Destruction Utility.' In the meantime - about two years have passed - it is now commercially distributed. Therefore, the program can no longer be obtained directly from me. For reasons that escape my understanding, the program was renamed by the company to the lovely name 'Atari ST Virus Killer' (hereinafter referred to as AVK).
Current Version
Currently, version 4.1 is available in stores. Compared to its predecessor, I have completely rewritten it: it is now fully STE-compatible, the last minor bugs have been fixed, and the method for disk immunization has been improved. AVK 4.1 now detects viruses faster that 'bend' the vectors of the operating system. All files on the diskette are highly compressed because the program has grown again: it detects 533 boot sectors, including 42 boot sector viruses and five link viruses, 304 boot sectors can be repaired. Version 4.2, which I am currently working on, can do even more, as you can read on the following pages.
Viren and the TT
With the appearance of the TT, the delicate question arose: 'Do ST viruses run on the TT or not?' Well, the answer is simple: Some do, others don't. Many viruses use undocumented system variables, so they do not work on the TT. However, most viruses check the number of bytes on the processor stack during a trap call. Nevertheless, the 68030 processor of the TT places 2 more bytes on the stack during a TRAP call. However, ST viruses are not aware of this, they get confused and ultimately do not work. Although I have not yet been able to gain practical experience with the TT, I estimate that 90 percent of today's ST viruses do not work flawlessly on the TT.
Camouflaged boat viruses
Yes, it sounds paradoxical - and I didn't believe it either when I first heard about this new type of virus. But, as quickly became apparent, there is a method for boot sector viruses to install themselves, even though the actual boot sector is not directly executable.
But one thing at a time: When powered on, the ST-TOS reads the boot sector of the boot drive (floppy disk or hard drive) and checks if its checksum matches the value $1234. If TOS determines this value, the boot sector is 'executable,' and a JSR (Jump to SubRoutine) is executed to its code. In other words, the ST runs the program located in the boot sector, and if it happens to be a virus, it installs it in its memory. But what happens if the boot sector is not executable? Well, the system still reads the boot sector into its memory - specifically to the address of the system variable 'Dskbufp,' the floppy disk buffer. Even if TOS does not execute this code, it still resides in the memory of the Atari ST.
Next, the system performs an undocumented check of the reset-resistant programs, using another undocumented TOS function that leverages the 'magic' longword $12123456 and a 512-byte memory limit. As luck would have it, this check specifically involves the memory area where the disk buffer is located - and it is here that the data just read from the boot sector resides.
Take a look at the table once.
In the left column, I have listed the TOS versions to which the information to the right refers (the table includes all existing TOS versions except the TT operating system). The second column provides information on the hexadecimal address of the disk buffer pointer as it appears in the Dskbufp system variable (longword address $1C6). The third column is the result of a small calculation and determines the offset of the boot sector where the longword $12123456 must be located to function with the corresponding TOS version (simply remove the minus sign for this purpose).
If the long word is followed by the appropriate values at the appropriate offset of the boot sector, the ST executes the program located in the boot sector. In plain language: The virus can be installed even though it is located on a non-executable boot sector. Since the available memory space in the boot sector is very limited, a boot sector virus often loads the remaining virus from other sectors - for example, it may be located in the last sectors of the File Allocation Table (FAT) or the Directories.
Pretty mean viruses, aren't they? Until recently, most virus killers fell for this trick and gave a false all-clear with a '100% virus-free' message - my AVK thought the same way until version 3.9. But that's in the past.
Even though these viruses are very dangerous - the new virus killers find and destroy them.
EPILOG
So no complete all-clear yet: The 'evil spirit' of the ST viruses is still alive. But aren't these rather the last twitches of something definitively condemned to death?
Diskette buffer addresses
TOS Version
Dskbufp
Offset off $200 page boundary
TOS 1.0 (Old TOS)
$167A
-$186 off $1800
TOS 1.2 (Blitter-TOS)
$16DA
-$126 off $1800
TOS 1.4 (Rainbow-TOS)
$181C
-$1E4 off $1AOO
TOS 1.6 (STE-TOS)
$181C
-$1E4 off $1A00
Table. 'Dskbufp' addresses of different TOS versions
Richard Karsmakers
From: TOS 11 / 1990, Page 120
Links Copyright regulations: see About this page