AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (04/06/88)
>Date: Mon, 4 Apr 88 15:37:46 CDT >From: SCHUESSLER <GA.NES%ISUMVS.BITNET@CUNYVM.CUNY.EDU> >Subject: Viruses: Fact or Fiction? >Well, folks, I am totally confused about this virus stuff. In reading >about them in a local paper (Today section DesMoines Register) about >monitors exploding, and hard disks crashing, I don't see how anybody >could possibly write a virus that would get by enough people to become >dangerous. Please examine my reasoning, and point out where I missed >something. They get by because they generally don't do anything damaging right away. >Suppose I wish to write a virus. I have read that the operating >system is the place where they're supposed to be put. Here are some >problems: > > 1. How do I add routines to prodos w/o changing the block length? > I don't know about anyone else, but I think I would > probably notice that Prodos would take longer to boot, or > that it was 32 blocks instead of 31. You might, but you probably wouldn't notice it right away. Anyway, ProDOS is *not* the only place to hide it. Could tack it into other applications, or even in the boot blocks (there is some unused space there for booting SOS on the Apple ///). Heck, you could even hide some code in the DIRECTORY (which gets read into RAM during the boot process anyway, while the boot blocks are looking for the PRODOS file). (This would cause a problem when the directory started getting full.) Also, there is most likely some space in PRODOS that isn't currently used (I haven't looked lately). > 2. Viruses are supposed to "spread" themselves. Spreading implies > (to me at least) saving themselves on other disks in other drives, > which would be extremely obvious if you did a catalog of drive1 > and it went to drive2, or it would suddenly start working on the > disk w/o direct commands from the keyboard. Equally suspicious > would be a slow catalog listing (with a virus 'spreading' itself > sometime during the execution of the command). It wouldn't take very long to spread itself, and it would not do it spontaneously. For example, it could writ itself into the boot blocks one out of every 20 times you write to your main directory. It wouldn't take too long, since your drive would already be in the right area of the disk anyway (main directory = blocks 2-5, boot blocks=0-1). Writing to disk already takes a variable amount of time depending on where the free blocks happen to be on disk, so one or two more block writes with no head movement would be hard to notice (ESPECIALLY on a 3.5 drive or a hard drive. Or a RAM drive [with or without a battery backup!].) > 3. The next thing in question is the delayed effect, which no doubt > is done by incrementing a counter each time it is executed. In > order to retain this value, it must be stored back on the disk > which causes another timing problem as far as working with the > disk is concerned. Counters could be in RAM as well as on disk, or it could skip conters completely and trigger based on some semi-random number or some set of conditions on disk. -- Even if you use counters, it might not have to do any extra disk writes (for example, increment 2 unused bytes in the root block of your directory whenever the block is being written ANYWAY). > 4. To spread itself, it must know the volumes on line, which > have prodos copies that are not infected already (which will > take a bit of code to check for) and then probably set some > flags to point to the clean copies so that when executed next > it can spread itself. Nope, it doesn't have to be that complicated. Just infect disks as they are accessed by the running application, and set it up so it doesn't matter if the thing you're infecting is already infected or not. > 5. Finally, there is the problem of doing all the things viruses > are famous for in 200 bytes or less. I don't know about anyone > else....maybe it's just me, but I can't do all that fancy I/O > in 200 bytes or less ( which is supposed to be the optimum length). > That's w/o the fancy routine to time the spreading with save/bsave > load/bload's which would be a nightmare in itself. You can do a *lot* in 200 bytes, although there's not much reason to limit them to being that small. It only takes 18 bytes to say "WRITE_BLOCK number 0 on the last-accessed device" in machine. (Doing file-level I/O rather than block-level I/O would take a few more bytes, but not *that* many more.) >With all that to worry about, why would anyone go through all the trouble? I don't know, but it only takes *one* deranged person. If your hard drive has just fallen victim to someone's virus, you won't really care *why* they went to the trouble. >Maybe I could see it possible for someone who just uses the software, and >doesn't do the programming/doodling around with operating systems to miss >the differences, but I hardly think that it would result in a major crisis >to society. But people are so eager to give the latest nifty software to their favorite bulletin boards that the viruses can potentially spread *very* quickly. If we teach people to be careful the problem can be kept under control, but it gets harder as operating systems get larger and more complex--there are lots more interesting ways to "infect" IIgs's than IIe's, for example (desk accessories, RAM vectors that survive an Apple-Ctrl-Reset, patching system tool vectors, etc). > Also--Is it legal to create a 'harmless' virus to see if it works > and you supply an antidote? I don't know if it's legal, but it's pretty stupid--everyone will hate you when they find out about it. (Someone [in Canada?] wrote a "harmless" virus for the Mac that displayed a World Peace message on a certain date. This pissed lots of people off & I think caused a few problems for people even though it was supposd to be harmless. This virus [or was it another one?] has accidentally made its way into some factory-fresh copies of at least one piece of commercial software for the Mac.) > | | Niko Schuessler | | > | | GA.NES@ISUMVS | | > | | Iowa State University | | --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2