💾 Archived View for spam.works › mirrors › textfiles › virus › virus101002.vir captured on 2023-11-04 at 16:04:13.
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
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. --