From: woodside@ttidca.TTI.COM (George Woodside) Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc Subject: Virus 101 - Chapter 1 Date: 1 Mar 89 14:39:58 GMT Preface: The program VKILLER is specific to the ATARI ST. My apologies for not making this clear in the previous posting, which went to several newsgroups. I have recieved far too many requests for the program from users of other systems to reply to each one individually, and the mailer has bounced some of the replies I tried to send. If you have an Atari, VKILLER was posted here a few weeks ago, and is available in the archives, on GEnie, Compuserve, and from most public domain disk distributors and User Group libraries. The current version is 2.01. Initial postings will cover virus fundamentals, as they apply to the area of the Atari ST and, similarly, to MS-DOS systems. The file systems of the two machines are nearly identical. These general information articles will be cross-posted to the newsgroups in which this topic is now active. Future postings will be made only to the Atari newsgroup, since they will deal with viruses (the plural, according to Webster's, is viruses) known to exist in the ST world. They would automatically be different than an IBM virus, since they are in the 68000 instruction set, or from a Mac or Amiga virus, since the file systems differ. Since all the viruses I have located are the "BOOT SECTOR" type (far and away the most common), that's what I will dwell upon. If and when the proposed newsgroup comp.virus becomes active, it will be added to the list for all postings. Your generic disclaimer: I just an old-school computer hacker, with 20 years in the software business. I built my first IMSAI many years ago, and have had several different computers. That qualifies me to have spent a lot of time on computers, but nothing further. I may be wrong about some things, may have a different opinion than you or anybody else, or most anything else you'd care to have disclaimed. What I think is my own opinion, and in no way represents the opinion or position of my employer or anyone else. I've written several articles for magazines as well as software related to virus detection and killing, but I have been known to be wrong (so they tell me :^)). While posting any kind of information about viruses may trigger someone to attempt creating one, I believe that the benefit of the knowledge to potential victims outweighs that risk. I don't believe that you can stop someone (who wishes to) from creating a virus by withholding information - it is already available from many sources. Since not all viruses act the same, or attempt to attack in the same manner, it may help potential (or current) victims to learn about the symptoms of the viruses known to exist, and how to protect themselves. While the concept of viruses can be complex, I'll try to keep things at a level that should be understandable by most anyone past the casual user genre. However, since I've been at this sort of thing for some time, what I consider basic knowledge may not be familiar to everyone. Advance apologies are offered here for any invalid assumptions, typos, smart alec remarks, grammatic errors, or whatever offends you. Some basic terms, as they have come to be used in this area: A VIRUS is any program which spreads itself secretly. It may be destructive, a prank, or even intended to be helpful, but it spreads. A TROJAN HORSE is a program which executes one function secretly while appearing to be accomplishing some other task, or appearing to be some other program entirely. One task a Trojan Horse may accomplish is to install a virus, which would then spread itself. A WORM is a program or function which imbeds itself inside another program, be it an application, part of a system, a library or whatever. It may or may not spread itself by some means, and may or may not have destructive intents. Now, to the basics of a disk (specifically floppies, but true of most hard disks as well): A DIRECTORY is a list of files and sub-directories. There is one primary directory (called the root directory) on a disk. It contains the entries for files, and other directories (called sub-directories, or folders on the Atari). Sub-directories (folders) may contain entries of other sub-directories, files, or both. Every file has one entry in the disk directory (or in some sub-directory). That entry contains, among other things, the file name, date and time of creation, length, and the address of the first entry in the File Allocation Table (FAT) for the file. A FAT is a File Allocation Table. It is a road map of how the operating system will locate data on a disk. Essentially, it is a series of pointers. The directory entry of a file points to the first FAT entry of that file. That entry points to the next, and so on, until the last entry, which contains a special value indicating end of file. There are two copies of the FAT on the disk, since it is absolutely critical. Lose the FAT, and the data on the disk becomes un-accessable. A BOOT SECTOR is the first sector on a floppy disk. With the Atari (and MS-DOS) system, it contains configuration information about the disk. That information includes how many tracks are on the disk, how many sectors per track, how many sides on the disk, how big the FATs and directories are, where the data begins, etc. On the MS-DOS systems, the boot sector contains the ID of the operating system under which it was formatted. On the Atari, that value is not used, but replaced (in part) by a number. That number should be different on every disk, and is used as part of the mechanism by which disk changes are detected. The boot sector may or may not contain executable code. If it does contain executable code, it is normally executed only at system powerup or system reset time. On all such disks, the boot sector is number 0, the first sector on the first side of the first track. On a standard format Atari disk, the next five sectors are the first copy of the FAT, the next five sectors are the second copy of the FAT, the next seven sectors are the root directory, and the remainder of the disk is available for data. Now, on with the show: Floppy disks are changed on a regular basis while the computer is being used. More so on systems with no hard disks, but periodically on most all systems. This event, referred to as a "Media Change", is detected by the computer's disk drive. The disk door is opened, the status of the write protection changes as one disk is removed and another is inserted, etc. When that happens, the operating system must recognize that the disk has been changed before attempting to read or write to the new disk. The operating system reads the disk's boot sector to learn about the newly inserted disk. That instant, when the operating system checks the new disk, is when nearly all the boot sector viruses spread. We'll get to that in the next chapter, but first, a more primary question: How did the virus get in there? When a computer is booted up from a power off state, or reset (in most cases), it starts executing code from internal ROMs. Those ROMs set up primary vectors, minimal configuration information, and perform some fundamental tests. Then they start moving into uncharted waters. They have to find out what devices are attached, and get them into operating status. They also have to provide a means of expanding their own capabilities to support new devices, functions, and whatever else which may not have existed when the ROMs were created. One of the means by which this is accomplished is by checking various addresses for special codes, magic numbers, or any kind of response to a read or write. Another function which may be enabled is checking the boot sector on an inserted floppy disk for executable status. If that boot sector has executable status, the code contained in the boot sector is executed. That code may cause other portions of the disk to be loaded and executed, set variables or vectors, or nearly anything imaginable. That includes infecting the system with a virus, if that's what the boot sector code contains. Executable status may be via a special flag value in a reserved address, but it is normally determined by adding up the value of all the data bytes in the boot sector. If the total derived (called a checksum) is a specific value (a "magic" number), then the boot sector is deemed executable. The code is usually executed at that time. The code is not normally garanteed to be loaded at any specific address in memory, so it must be "position independant", or capable of executing no matter where it exists in memory. The boot sector is of limited size, normally 512 bytes. While that is enough for a small program, it may not be enough for whatever task it is designed to accomplish. So, part of what the code in the boot sector accomplishes must be to load the rest of the code it needs to get the job done. This may be a normal data file, or hard coded to some other part of the disk. If the code from the boot sector is designed only to accomplish some task, it will normally take the steps to do so, then return to the operating system. This may be setting the screen resolution or colors, issuing an initialization command to some device, or setting up some option or feature. If the code is designed to remain available after the initial execution (such as part of a device driver), it must inform the operating system that it wishes to remain resident. The operating system then alters the amount of RAM available to protect the space occupied by the loaded code, so that subsequent programs do not tamper with the loaded routine. Such a routine is referred to as a "Terminate and Stay Resident" routine, or a TSR. Viruses must be TSR type programs. They have to remain in the system, and active, to be able to accomplish their spread, and eventually, their true goal. If the boot sector program was designed to attack immediately, it may accomplish its destruction, but it would never get the opportunity to spread, and the disk which caused the attack would be easily identifiable. Most viruses accomplish system infection by taking over a "vector". A vector is a specific address in system memory which contains the address of a routine or function. When an interrupt (such as pressing a key, the clock ticking, or so on) occurs, processing is suspended, and the system loads the address in some vector associated with that event. It executes the routine at the address which was stored in the vector, then resumes whatever it was up to when the interrupt occurred. Other vectors are not associated with interrupts, but with specific functions, such as display a character on the screen, read a sector from the disk, write to the printer, and so on. To take over a vector, the steps are fairly simple. A RAMdisk, for example, will usually take over a disk read/write vector. When it installs itself, it removes the current address from the vector assigned to the disk read/write function. It saves that address in it's own code, and places the address of it's own code in the vector. When a disk read/write call is made by the operating system, the operating system loads the address found in the proper vector, and starts executing the code found at that address. That address now points to the executable code of the RAMdisk. The first thing the RAMdisk does is check the function call's parameters to see if the read/write is for the RAMdisk. If it is, the RAMdisk accomplishes the read or write, and returns to the operating system. If the read/write is for some other disk drive, the RAMdisk code passes the call on to the address it removed from the vector, allowing the assigned device to accomplish the task. There may be more than one alteratiion of the vector. Each new routine which is installed will save the old vector, and insert itself. That means that the routine installed last will get the first access to any call which uses that vector. If it does not want the call, it passes the call on to the address it found in the vector, and so on. The significance of this sequencing is that a boot sector virus, if present, will be one of the first "vector snatchers" to get installed. Conversely, it will be one of the last routines in the sequence to get executed when a vector is accessed. If the vector in question happens to be for floppy disk I/O, the virus will be one of the last vectors before the real physical read/write routine. So, if a program designed to detect a virus's floppy disk I/O calls is executed as part of a startup procedure, it can easily be fooled. The detect program will see only normal system I/O calls passing through the vector. The virus resides in the vector list after the anti-virus program, so the anti-virus will never see any activity generated by the virus. The anti-virus thinks that things are progressing well, while, in reality, the virus is either spreading or doing damage behind the anti-virus's back. If the anti-virus gets installed first (say, by being in a boot sector itself), it has a better chance of offering protection, but not an absolute one. Some viruses check things like ROM version numbers, and know the absolute addresses in the ROMs of the functions they want. By using those addresses, they can bypass subsequent links in the vector list, and still do their dirty work. They can also refuse to install themselves if the addresses or version numbers do not correspond to the environment they want. End of Chapter 1. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside From: woodside@ttidca.TTI.COM (George Woodside) Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc Subject: Virus 101 - Chapter 2 Date: 6 Mar 89 14:00:21 GMT In response to a lot of the mail I've received: 1) You haven't missed the "rest of the chapters". I'm posting them as I get them written. 2) You may not agree with me. I tried to set down the definitions and terms as I would be using them, for the benefit of those who weren't familiar with them. This whole area is rather vague, and most of us in the trenches and making up the rules, as we learn the game. When we left our virus at the end of Chapter 1, it had managed to get itself installed in our system by being present on the boot sector of a disk in the machine at cold start or reset. Another way a virus may be installed is via a trojan horse program. Trojan horses come in many flavors. Some disguise themselves as programs which provide some useful function or service, while secretly doing something else. The something else may be installing a virus, sabotaging some part of a disk, setting up hooks to steal passwords on time sharing systems, or whatever else you can imagine. In the event of the virus installer, the trojan horse has a bit more flexibility than a typical boot sector virus, simply because it doesn't have to fit itself into a relatively small space. Since it is hiding in a larger program, it can be whatever size is necessary to accomplish the task. A typical boot sector contains information about the layout of the disk it resides upon. This block of data requires 26 bytes. The first three bytes of the boot sector are left available for an assembly language "jump" command, to allow the execution of the code to skip over the boot sector's data block. And, the boot sector must add up to the proper magic number to have executable status. That will require another two bytes, since the checksum is a 16 bit value. So, 31 bytes are allocated. Since (at least in the 68000 family) machine instructions are always 16 bits and must begin on an even address, 32 of the 512 bytes in the boot sector are not available to any executable program. So, there are 480 bytes available for the executable code. Machine instructions vary in length, depending upon what they do, and how much additional information is required. In the 68000, instruction lengths vary from one to five words, but a reasonable average instruction length for a program is just over two words. That translates the 480 bytes to 120 instructions. The virus must contain the code to install itself, reserve the memory it occupies to keep subsequent programs from over-writing it, spread itself to other disks, and whatever it really intends to do once it decides it is time to act. That's quite a bit of code to fit into 120 instructions, unless it extends itself by loading some other part of the disk, or a file. Files are pretty much out of the question. Most computer users would notice if some file they didn't recognize started popping up on a lot of their disks. There are attributes settable in a disk directory which can be used to tell the operating system that certain files are "Hidden" or "System" files. If the file had the proper status bits set, it could prevent itself from appearing in normal disk directory displays. There are, however, more flexible disk directory listing programs which will display the entries for these files, as well as normal files. There is also the problem of the space the hidden file occupies, as well as the directory entry. The space available on the disk will be less than it should be, since the hidden file is present. These symptoms would not escape detection for long. A more effective method is the use of specific disk sectors. The standard disk layout covered in the preceeding chapter mentioned such things as File Allocation Tables, and disk directory space. In a standard format Atari disk, for example, each FAT is 5 sectors long, and the directory is 7 sectors long. That is more than enough FAT space to accomodate the entire disk. A virus in need of more space than 480 bytes might write the remainder of itself in the last sector of the FAT (I have one that does this). It might also write itself in the last sector of the directory, taking advantage of a quirk in the operating system. When a disk is formatted, all data sectors are normally filled with a pre-defined value, E5 (hexadecimal). The directory and FAT space is usually set to 00. When a directory entry is made active, the file name is written in the directory, along with some other required information. When a file is deleted, the first byte of the directory entry is set to E5. That makes the entry available again. This is a carry over from the early days of floppy disks, when where the directory would exist on a disk was not as well defined. The directory entries had to appear as empty on a freshly formatted disk, so E5 was used as a deleted entry mark. That way, no matter where the directory was, a freshly formatted disk would always appear as empty. Now, since disk formats are more flexible, the directory is located by parameters, and normally the entire directory space is zeroed at formatting time. Since an active entry will have some legitimate ASCII character in the beginning of the file name, and a deleted entry will have E5 in the first byte, it is generally assumed that encountering a directory entry with a value of 00 in the first byte indicates that the entry has never been used. Since directory entries are used (and deleted ones re-used) on a first-found basis, finding one with 00 means that not only has it not been used, but none of the ones following it will have been used either. Consequently, most software stops looking at the directory entries when a 00 entry pops up. If there are several more sectors available, there may be something hiding out there, beyond the last used entry. While this method of hiding is not foolproof, the typical virus is not concerned about being bulletproof in all cases. It just has to survive long enough to reproduce itself, and it has half the battle won. As long as it keeps spreading, sooner or later it will survive long enough to do the task it is designed to do, then it wins both halves of the battle. There are other ways for the virus to get additional disk space. Typically, floppy disks are not used up a sector at a time, but rather in groups of sectors. Each group of sectors is referred to as a data "cluster". The number of sectors in a cluster is variable, and is one of the parameters stored in the boot sector. If the number of data sectors on the entire disk, minus the boot sector, FATs, and directory, is not an exact multiple of the number of sectors in a data cluster, the remaining sectors will never be used by the opearting system. A clever virus can find them and hide there. The inconvenience of this is that the unused sectors would normally be at the end of the last track of the disk, causing long (and noticeable) disk seeks to load or spread the virus. There is a parameter in the boot sector designed to permit the disk to have sectors reserved for any purpose, and not accessed as part of the normal data area. A virus could also use this method to extend itself, but it, too, has shortcomings. Using this feature requires the parameter to be set when the disk has absolutely no data on it. Reserving sectors causes the start of the data area to be moved further into the disk. While the data area would be moved, the data already on the disk would not. Consequently, altering the reserved sectors parameter would make all files on the disk garbage. (They could be returned to proper status by restoring the original value to the reserved sectors parameter, providing no disk write had occurred.) There would also be the problem of the disk's free space being less that it should. Consequently, if a virus needs extra space, using prescribed system features or hidden files is not a good choice, since it is too easily detected. The approach used so far is to hide in sectors unlikely to be used, and hope to spread before they get clobbered (and it works). OK, so now the virus has managed to get onto a disk in your library, and then get itself booted into your system at startup or reset. It may have been on a disk you received from someone, and booted with, or it may even have been installed by a trojan horse, but it is in your system. How does it spread? There are ways, and then there ways..... The most common method is through the vector reserved for floppy disk read and write functions. As we saw in Chapter 1, floppy disks get changed (some surprise, eh?). One disk is removed, and another is inserted. When that happens, the operating system is notified by the physical act of changing the disk that the event has occurred. How that event is detected will vary with different disk drives, but there are two common methods. One is the disk drive latch. Some hardware reports the transition of the latch on the floppy disk drive's door. When the locking lever is moved, a signal is sent to the disk controller card, indicating that the disk door has been opened. (Door is a carry over term from older drive mechanisms which had fully closing doors over the disk drive slot.) The operating system makes note of the fact that a disk change may have occurred. The other method is the write protect notch. On both 5 1/4 and 3 1/2 inch disks, the write protect notch tab is located in a position which makes it impossible to fully remove and install a disk without having the write protect detection mechanism be fully obstructed at some point, and fully unobstructed at some point. The detection mechanism may be a physical sense switch, or an optical sensor. Either way, as the body of the disk is removed from the drive, it will be blocked. Then, when the disk is out, the sense area is open. So, the drive will report transitions on the status line. The operating system notes the change, and sets the necessary flags to indicate that the disk may not be the same one that was there a little while ago. It may also be, if the same disk was re-inserted, but that's not important. The fact that it may have changed is very important. Attempting to read or write to the disk, without first noting the characteristics of it, could be very destructive. When the next access of the (possibly) changed disk occurs, the operating system will read the boot sector. In MS-DOS systems, I believe that the operating system assumes that if there is a possiblity that the disk has changed, it assumes that it has, dumps all information relative to the old disk, and starts fresh. In the Atari, the operating attempts to be a bit smarter. The boot sector contains a serial number which is supposed to be unique across all disks. This serial number is 12 bits long, and is assigned when the disk is formatted. If there is a possibility that the disk has changed, the operating system reads the serial number. If the serial number is different than before, the disk has changed, all old data is wiped out, and the new serial number is noted. If the serial number is the same, the disk has presumably not changed, and the data in the operating system's internal buffers is assumed to be valid. This leads to thoroughly trashed disks if two disks have identical serial numbers, and are used consecutively. In any event, when a possible disk change has occurred, the boot sector is always read to determine the characteristics of the new disk. The operating system uses the floppy disk read function to access the first sector on the disk. As previously noted, this disk read function is pointed to by a vector. If the vector has been altered to point to a virus, the plot thickens... We will assume a typical floppy disk boot sector virus for a while, and see exactly what happens. The virus first checks the number of the drive being accessed. If it is not a floppy disk, it passes the call on to the address it found in the vector. No harm done. If the call is to a floppy disk, most viruses check the side, track, and sector of the call to see if it is the boot sector. If it isn't, it passes the call on, and again, no harm done. Why? Performance. Not that the virus cares about good disk performance, mind you. What it cares about is being noticed. If it was busy snagging all the disk calls, and checking the boot sector all the time, there would be an incredible increase in disk head seeking, and a very noticeable drop in performance of the system. Anyone with at least half a brain (witch inkluds sum smarter komputer pepel) would notice that, and would become inquisitive about what was happenning. The virus would have given itself away. No self-respecting virus would want to be detected before it got a chance to spread, and possibly wreak a bit of havoc, so it remains inactive until it can accomplish its task unnoticed. When the read call is to the boot sector, the virus goes into action. The data is read into a buffer, as designated by the host operating system's call, exactly as expected. Normally, the disk read function would return to the operating system at this point, but the virus doesn't. Depending upon the sophistication of the virus, several things may happen. Some viruses will first check the image of the boot sector in the buffer, to see if they are already on the disk. If they find the disk already has the virus, the go back to sleep (pleased, we assume!). Some even check revision levels in the virus image, and replace themselves if the disk had a more recent version of themselves! If the image from the boot sector is not the virus, some will check to see if the image was of an executable boot. If it was, the virus does not alter it. Doing so would make a self-booting disk fail forever after, and would probably lead to the detection of the virus. Other viruses, not as sophisticated, will not execute this test, and may be spotted more readily. Now, assuming that the boot sector is not executable, or that it is but this virus is too dumb to leave it alone, it's time for the virus to spread. There is a copy of the boot sector from the original virus disk in a reserved memory area, from the original boot up process. The executing copy of the virus knows where that is, since it reserved the memory for itself and the image at the same time. The characteristics of the disk the virus came from may not be the same as the disk in the machine now. Depending upon the operating system's standards, the virus will either copy the disk parameter information from the current disk into its own image buffer, or copy its image into the current disk's buffer, leaving the disk's parameters unchanged. Either way, the result is a copy of the current disk's parameters, combined with the executable image of the virus. Now, the executable status checksum must be computed, and added to the buffer. This may be accomplished by a routine in the virus, or by an operating system call. If the virus is on an Atari, it might be careful enough to insure that the serial number on the new disk remains the same. Failing to do so would lead to all disks with the virus having the same serial number. That would lead to disks being accidently altered (due to the serial number test), and the virus would probably be detected too soon. When the new checksum is completed, the updated boot sector is re-written to the disk. All this occurs in much less than the time required for the floppy disk to make a single revolution, so the boot sector is re-written on the next spin. Since the rotation speed of the disk is either 300 or 360 rpms, the total time lost is less than 1/5 of one second. Nearly impossible for anyone to notice, when combined with the time required for the drive to load the head, seek to track zero, read the sector, etc. The only potential problem here is one of the virus' intended victim's primary levels of defense: the write protect feature. Despite rumors to the contrary, I have not seen a virus capable of writing to a write protected disk. The hardware in the disk drive will not write if the write protect status is set. It reports an error to the operating system. The virus can not override this protection, but it must be wary of it. Older viruses were sometimes spotted when a system error occurred, reporting that an attempt was being made to write to a disk which was write protected. If the function being performed (listing a directory, for example) should not be writing to the disk, there was reason to become suspect. Most viruses now are more sophisticated. They take over the error vector before attempting the write, and restore it afterwards. That way, if the attempt to spread themselves to the new disk fails, the error never gets reported. While the user doesn't know that the attempt was ever made, the disk also doesn't get infected. Many viruses run counters. Some count the number of already infected disks they have seen, while others count the number of disks they infect. Either way, the counting viruses have some threshold they are attempting to reach. When they reach that number, they (presumably) consider themselves thoroughly spread, and it is now time to start their third act. End of Chapter 2. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside From: woodside@ttidca.TTI.COM (George Woodside) Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc Subject: Virus 101: Chapter 3 Date: 13 Mar 89 14:24:23 GMT First, the mail: Addressing a controversial topic is sure to generate some strong responses, and this one is no exception. Mail of the "Thank You" flavor outweighs the "You Idiot" flavor by about 4-1, so I'll be pressing on. The majority of the "You Idiot" mail is from senders who either admit, or display, limited programming ability. For the benefit of those individuals: I appreciate your concern. I am not attempting to aid in the spread of viruses, but in your own understanding of them, and ability to defend yourself. People with the ability to create a working virus will have found little or nothing they didn't already know in the preceeding postings. There is certainly nothing in them that isn't already available in the most fundamental books about personal computers. The preceeding postings are also written at a superficial level, and are missing quite a few specific things necessary to make a real working virus. Those missing items would add nothing to the layman's understanding of how a virus spreads or works, so are not included. You need not take my word for this; contact anyone you know who is knowledgeable in the system software field, and they will confirm it. Sin of omission: Part of a message received from Forrest Gehrke (feg@clyde.att.com): ...One method for a virus finding enough space to hide itself, that I have seen, you have not mentioned. I have noticed that the so-called Pakastani virus uses non-standard sectoring at tracks 37 and 38 for IBM PC diskettes... Mr. Gehrke is quite right. I did forget to mention this technique. While I had heard rumors of it being in use, I hadn't seen it in any of the virus code I've captured (again, I'm in the Atari ST world). I have responded to all mail I have recieved (if it requested a response) including mailing out copies of missed chapters. Several responses have been returned by various mailers. If you requested something, and haven't heard from me, either your request or my response failed. Now, Chapter 3: Once a virus has installed itself, and replicated as frequently as it has found the opportunity, it will eventually launch whatever form of attack it was originally designed to do. That attack is the real purpose of the existance of the virus. Everything up to this point has been for the sake of getting to this stage. What will it do? Almost anything. The limits are imagination and code space. The most benign virus I've seen claims to be an anti-virus. It blinks the screen on boot-up. The idea is that if you see the screen blink, you know that the benign virus is on the disk, rather than a more malicious one. It does, however, spread itself just like any other virus. From there, things proceed through the prank levels, time-triggered, messages, ones which try to simulate hardware failures, to ones which destroy files and disks. The actions vary from virus to virus. And, of course, there is a whole different library of viruses for each machine type. Attempting to detect a virus by describing or recognizing the symptoms is not only a task of limitless proportions, it is too little too late. When the symptoms appear, the damage has already been done. Several viruses attempt to simulate hardware problems. (Conversly, I've had several pleas for help with a virus that proved to be other types of failures.) Frequently these viruses use timers to delay their actions until the system has been running for some time, and to spread out their activities to make the problem appear intermittent. Such virus induced glitches include occasionally faking succesful disk I/O, while actually not performing the read or write, altering the data being read or written, and (more commonly) screen display glitches. It is very difficult for anyone to determine whether such incidents are the results of a virus, or a real hardware problem. When such incidents start to occur on your system, start executing whatever virus detection software you have available, before lugging your system off to a service firm. Previously, I mentioned the use of write protected disks as a step in the right direction to protect yourself. A large percentage of personal computer systems now use hard disk systems. Floppy disks are more often a backup media, or offline storage of files not needed on the hard disk for day to day use. Backing up requires the disks to be writeable, as does archiving off the infrequently used files. It is good practice to write protect the archived disks as soon as the files are copied to them. Run whatever virus checking software you have on the archive disks, write protect them, and then file them away. (When reading the following suggestions about protecting your system from attacks, keep in mind that not all techniques can be applied to all systems or all software. Read the documentation accompanying the software before your first attempt to use it. Be familiar with what it is expected to do before you run it, and you'll be more able to recognize unexpected activity.) The next step is to apply write protection to whatever disks you recieve software distributed on, before ever inserting them into a computer. Be they Public Domain, User Group Libraries, Commercial Software, or whatever, write protect them before you first read them. Then, make a backup copy if possible. Finally, when first executing the new software, have only write protected disks in your system. You should be well aware of any legitimate attempt to write to a disk by the software before it happens, and have adequate opportunity to insert a writeable disk when the proper time comes. This will not only give you a clue to the presence of a virus in the new software, but also protect the new software from a virus already resident in your system. If your system supports the use of a RAM disk, copy new software into the RAMdisk before executing it the first time. Put write protected disks in the drives, then execute the software from the RAMdisk. If the software has no reason to access other disks, especially when starting itself up, be very suspicious of any disk activity. The most common time for a virus or trojan horse program to do it's dirty work is at startup, when it is impossible to tell whether disk access is part of program loading, or some clandestine operation. By having the software loaded into and executing from memory, you will be able to detect any disk I/O which occurs. Finally, backup everything. Hard disks, floppy disks, tapes, whatever. Make backup copies, write protect them, and store them in a safe place off-line. If you are attacked by a dstructive virus, your first problem is to rid your system of the virus. Do not go to your off-line backups until you have determined if your problem came from a virus, and if so, that you have removed it from the system. A backup is useless if you give a virus a chance to attack it as well as your working copy. A significant portion of these three chapters have been related to boot sector viruses. While the most common type in the Atari and MS-DOS world, they are certainly not the only type. What follows is next is mostly a re-phrasing of an article from "Los Angeles Computer Currents", June, 1988. There are a few direct quotes from the copyrighted article. While I do not agree with all that this article states, I can not disprove the items from a position of experience. Since my efforts here are to inform, you may judge for yourself. A significant portion of my remarks are oriented to the Atari ST, but the concept is true to most all personal computers. An article in that issue, by Lewis Perdue, outlined the problems he faced when the IBM PC running Ventura Publisher he was using to create the first issue of PC Management Letter became infected. I won't begin to copy all that, but the most interesting part of the recovery task was when they used a normal (high-level) format program to clear the hard drive. It didn't kill the virus. They had to resort to a low level format, and rebuild from all original distribution disks. Their backups had been infected as well as their working copies of the software. They relied on a PC specific tool called Data Physician, by Digital Dispatch, to aid in the detection of the virus. It implements techniques to diagnose infections, but it has to be installed before the virus strikes. Another, more interesting aspect of the article, was categorizing viruses into four groups: Shell, Intrusive, Operating System, and Source. Shell - these "wrap themselves around a host program and do not modify the original program." In laymen's terms, such a virus would tack itself onto a program file, so it would get loaded with the program. It would have to do this in a manner that would cause itself to be executed before the host, since the host certainly would not pass control to the virus. This would be quite a complex task on an Atari ST (and on systems with a similar structure for executable program files). The virus program would have to be quite large in order to deal with the structure of an executable file on the ST. In simple terms, an executable file (a program) is a series of unique sections: a header, the code, data, a relocation map, and possibly a symbol table. The header specifies the size of each of the following segments. The code is the program, but in a form which will not run until it has been relocated. The data is constants, literals, messages, graphic data, etc. The relocation map tells the ST what changes to make to the code before it can be run. The symbol table is not usually present, except during program development. The reason behind this structure is that when a program is created, it does not know where in memory it will reside when it is executed. Things like RAMdisks, device drivers, accessories, printer buffers, spelling checkers, and so on, may or may not be present in the computer when the program is run. Since each of those things require memory, the place where the program will wind up being loaded is unknown. So, when it does get loaded, it has to be told where it is. And, since the program will almost always contain references to itself (subroutines, variables, etc.) it has to be modified so that those references point to the right place. That's what the relocation map is for. It details how the program has to be modified. Once the program is loaded into memory, and fixed up, the relocation map and symbol table are discarded. So, to hook into a program file, a virus would have to split the program file, attach itself to the beginning of the code segment, (that's where execution begins), re-attach the data, relocation, and (possibly) symbol table segments, update the relocation map (all the original references would now have moved), update the header, then re-write itself to the original disk, assuming there was room on the disk for the (now bigger) file and that the disk was not write-protected. That's a large amount of work to develop, and a large amount of code to sneak into a system for the original infection. I should mention here that it is not difficult to write "position independant" code on most micro-processors. You have to set out to do that, though, and take the necessary steps along the way to keep everything position independant. Boot sector code is a well known example. The address where the boot sector will be loaded into memory is unknown, and there is no relocation done on the code. It has to be position independant. It also has to fit in the boot sector. If it needs more than the amount of space in the boot sector, it has to determine its own location, and load the additional code itself. Of course, that means that it had to have a place to store the additional code, and it had to know where to find it. Those items were covered previously. Detecting a "Shell" type virus is not difficult. When it attaches itself to the target program, it must increase the size of the file. While it would be a real nusiance to check file sizes on a regular basis, there are programs available to do this for you. An "alteration detection" program will typically accept a list of programs to recognize. It will write a data file of its own, noting characteristics of each file in the list, such as length and date, and then run a numeric algorithm across the file. The numeric algorithm (typically a Cyclic Redundancy Check, or CRC) will yield a value which is stored in the alteration detection program's own data file. Then, on each subsequent execution of the alteration detection program, it checks the recorded characteristics of each file in its list, and re-executes the algorithm on the files. It reports back any file which has been changed since it last executed. Needless to mention, such a program must be run on the files to be monitored before any virus has an opportunity to attach itself to those files. Then, it must be run frequently to have a chance to detect altered files. (Back to the types of viruses defined in the article)... Intrusive - Intrusive viruses work by patching themselves into an existing program. This type of virus has two possibilities - either it is willing to render the host program useless, or it will attempt to co-exist with the host. If it is willing to corrupt the host, this is not too difficult a task. It would replace a part of the host program, modify the relocation map, and wait to get run. When it did, it would abandon the original task of the host program, and launch its attack. An example of this would be the virus bearing version of a word processor which struck the IBM compatible market some years ago. It signed on, looking just like a popular shareware program, but it was busy re-formatting the hard disk while the user waited for it to load and get ready to accept input. The other flavor of intrusive virus, which attempts to co-exist with the host program, is terribly difficult to create. It has to modify the host in a manner that either accomplishes the host's task while also doing it's own, or find a part of the host that is infrequently or no longer used, and hide there. It would then have to modify some other part of the host in order to get itself executed. In either case, a virus of this type has to be aimed at one specific host program. There's no way it could perform the analysis necessary to locate such portions of a randomly selected program. For that reason, an intrusive virus has to target some program that resides on a large portion of the target computer's installations, and that it is certain will be available to tamper with when the virus introduction occurs. That normally means either the Operating System, or some utility program so common that it is found virtually every where. Operating System viruses work by replacing a portion of the Operating System with their own code. This is similar to the intrusive type, except that it can use a new trick (and there are ones that do this on the IBM/MS-DOS computers). As a part of the operating system, it can sneak out to a hard disk, find an unused part, mark it as defective, and hide there. That would mean only a very small part of the code would have to be hooked into the operating system (possibly as an entry in a list of device initializing routines). That small segment could then allocate adequate memory for the real routine, and load it from wherever. Source Code viruses - I found this type of virus to be a bit unbelievable. The article reads (I quote): Source code viruses are intrusive programs that are inserted into a source program such as those written in Pascal prior to the program being compiled. These are the least-common viruses because they are not only hard to write, but also have a limited number of hosts compared to other types. (end quote) Sounds to me like this would be nearly impossible to accomplish in after-market software. If, on the other hand, they mean a part of the program added by a devious member of a development team, then, it is credible. It brings to mind the story (which I can't verify, but I've heard it from enough different sources to believe it is true) about what may well have been the first virus. In case you're not familiar with "C" compilers, they are usually several different programs, which must be run in proper sequence, passing files and options from one to the next. Usually, this is all done by a another program, a "compiler driver", which is almost always called "cc". You execute "cc", passing it the necessary flags, and the name(s) of the program(s) you want compiled, and it drives all the necessary tasks to do it. This was reported to have been done by one of the originators of the UNIX operating system, (name deleted), back in the development days at Bell Labs. Well, the story goes, he wrote the first versions of UNIX, "C", and "cc". He had a "back door" to get into a system running UNIX. He built the back door code into "cc". The code in "cc" checked to see what it was compiling. If it was the module "login", it incorporated the back door into the module, so that he could get into the system. If, on the other hand, it was compiling "cc", it included the code both to re-create itself, and the code to build the back door into "login". So, every "cc" had the code, and consequently every UNIX system included the back door. Eventually, it was discovered, and removed. There followed a frantic rebuilding of every UNIX system in existance, so the story goes. This is the final chapter which will be distributed via cross-posting. Chapter 4 will relate specifically to viruses captured in the Atari ST environment, and will be posted only to comp.sys.atari.st. It will come out about 1 week after this one. This article was posted on March 13, 1989, so you can determine the approximate delay to your receipt, in case you don't read that newsgroup, but wish to locate the fourth chapter in comp.sys.atari.st. End of Chapter 3. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside From: woodside@ttidca.TTI.COM (George Woodside) Newsgroups: comp.sys.atari.st Subject: Virus 101: Chapter 4 Date: 21 Mar 89 13:40:56 GMT Having discussed the way viruses work, spread, and can be deterred, the only remaining topic is how to recognize when an attack occurrs. It is not always as simple, or as straightforward, as it may seem. What may appear to be a hardware problem may be a virus, and vice-versa. There is no absolute way to determine if a given symptom is being caused by a program error, a hardware error, a virus, or something else. Not all viruses cause destructive attacks, but those that do are usually devastating. When files start vanishing or becoming unreadable, it may be due to any of several reasons. Poor media, or abuse of media is not uncommon. A dirty disk drive head, or one drifting out of alignment can cause previously reliable disks to start producing errors. In the ST, there is the age old problem of chip sockets and poor contact, and early versions of the ST had some component reliability problems which could contribute to disk errors. Another source becoming more frequent is the use of extended capacity disk formats, some of which are not entirely reliable. There is also the potential of a real hardware failure in the ST, or the drive. Finally there is the potential of a virus attack. How do you tell? It's very difficult. Actually, the virus is the easiest to detect. Use your favorite virus detect program, and start searching. If you can't locate one, then you problem could be any from the list above. If you find one, you must be certain you have taken every step available to you to insure it has been eradicated before accessing your backups. When the virus does not destroy files, what does it do? It's rather like the age old "Where does a 600 pound gorilla sit?". Most anyhere he wants, obviously. A virus can do most anything that any other piece of software can do. The bigger the code segment of the virus, the more capable it can become. There are some rather surprising things accomplished by the viruses already found in boot sectors, when you consider that it has to accomplish its own loading, spreading, and eventual attack in about 120 instructions. Some of the viruses currently spreading do nothing more than mess up the screen display. When such an event occurs, it is not obvious that it is a virus attack. It could be a momentary power fluctuation, a software bug of some kind in the executing application, an intermittent hardware error, or any of several other causes. The only hope of identifying the source as a virus is, again, a methodic check of your disk library. Familiarity with the appearance of the attacks of known viruses would be helpful in recognizing when one is present. For that purpose, I have provided the program "FLU". It is a demonstration program. It does not contain any of the code present in any virus for the installation of the virus, or the spreading of the virus. What it does contain is the non-destructive attack code of several viruses. These attacks are either audio or visual, so that there is evidence of the attack occurring. There is no simulation of any of the virus attacks which cause damage to disk data, since there is no way to recognize when such an attack is occurring (and, of course, the purpose of the program is to aid in recognizing the symptoms, not to destroy disks!). "FLU" is absolutely safe. The program can be viewed as a simple novelty, which does some strange display alterations. But by running it, and becoming familiar with the symptoms it displays, you will be capable of recognizing the characteristics of the attack of several current ST viruses. Two of the simulations, the "BLOT" virus and the "SCREEN" virus, attack in a nearly identical manner. They step on a small portion of the screen. When speeded up to display the symptoms, they have the appearance of drawing lines from the top and bottom of the screen. However, when the attack occurs at the speed at which the virus really operates, the attack would appear more like a small blot appearing on the screen, since the screen would have most likely been altered or redrawn by the application program between virus attacks. The "FREEZE" virus is probably the most difficult of the non-destructive viruses to recognize, since it is the most subtle. It takes over the ST for an ever increasing period of time, causing a gradual slowing the machine. Again, the demonstration runs at a significantly higher speed than the real virus. This concludes the virus discussions. It has been the goal of these postings to inform the general public of the way viruses spread, attack, and can be dealt with. It is clear to me that, as a defense, ignorance has been unsuccessful. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside