steelie@pro-charlotte.cts.com (Jim Howard) (01/07/88)
The solution of having a checksum on track 0 which is monitored by the OS is at least a start in the right direction, but what of the programs out there that use track 0 to load custom dos's? And what is going to happen when the viruses start spreading to tracks 80,81, and 82? Thats over 36k of workspace for these viruses to hide in, and with that much space we could start seeing much more subtly destructive viruses, that actually modify the user's programs, such as messing with spreadsheet data e.t.c. And with two very fine 68000 disassemblers out there, anyone with any persistance and a good memory map can disassemble the virus and modify the assembly source code to their own malicious purposes. As of right now the only path I can see is prevention, or at least until the OS can be set to clear all the ram: on a reboot. But then what of ASDG's recoverable ram disk?? :^) Evidently the above has already happened, the "RAM MAN WAS HERE" virus seems to be the original SCA virus modified radicly to erase a disk, or at least write garbage to track 40, thus destroying all directory structure.. And another point brought up, is the write protect actually OS controlled and not hardware controlled? That could be another problem, when write protecting a disk means absolutly nothing.. UUCP: ....!crash!pro-charlotte!steelie | Pro-Charlotte - (704) 567-0029 ARPA: crash!pro-charlotte!steelie@nosc.mil| 300/1200/2400 baud 24 hrs/day INET: steelie@pro-charlotte.cts.com | Log in as "register"