This is FAR from being done, but it offeres information in the meantime.
This is an article discussing many aspects of viruses. While I have tried my best to make this article easier to read and understand for the average user, the information here will be of use to anyone interested in learning about malicious code. I hope the information here will effectively answer the most common, and uncommon, questions users need to ask.
First of all, let’s answer the question “What is a virus?” For simplicity let’s keep a very broad view of the definition and explanation. A virus is a program that reproduces its own code by attaching itself to other executable files in such a way that the virus is executed when the infected executable file is executed. Whether or not this is done with or without the victim[s] knowledge or intervention is not important. A basic example of an executable file is an .EXE or .COM or a file that is used by an executable file, like a .DLL (dynamic link library file). This is saying that the virus attaches itself to a host program and creates copies of it when linking itself to other programs runs the infected file. This self-propagation, when triggered by an event or a predetermined time, can have a detrimental effect on your computer. Viruses have been accidentally included in licensed software and can be attached to any type of file. There are other malicious programs also called viruses. These are worms, Trojan horses and logic bombs.
Trojan Horses:
Otherwise known as remote access terminal (RAT) programs that allow outside control of a computer when it is online.
While many consider Trojan horses to be viruses, they are generally not self-replicating and as a result are in a slightly different class. A trojan horse allows the programmer to perform tasks on a computer that the victim is neither aware or would approve of. Trojan horses have two parts, the client and the server.
The SERVER is the part of a trojan horse that is sent to a victim’s computer, usually disguised as a useful program or attached to another program, often legitimate. Once the server is installed into the system, it allows the client to connect to it and enables the programmer to carry out certain tasks within the host system.
The CLIENT is the controller part of the program. Whatever functions a particular trojan horse has been designed to do is controlled here. This is not the part of the program that a system’s antiviral software will detect on a victim’s system, although the scanner is designed to detect the presence of a client. Some of the functions a programmer may perform on a victim’s computer are as follows: uploading and installing programs, downloading, deletion and/or modification of files, logging user keystrokes, activation of peripheral devices (web cams, printers, etc), change screen colors and resolution, control of a mouse or keyboard (this may alter keyboard commands, i.e. F1 may command reformat of the hard drive, etc), theft of passwords/Internet accounts, etc. Basically, the user of a client may gain complete control of an unsuspecting user’s computer.
Worms:
A worm is a self-reproducing program that does not infect other programs as a virus will, but instead creates copies of itself, and these create even more copies. Usually worms concentrate on networks, creating so many copies of itself within the network it overwhelms it and brings the network down. . VBS (Visual Basic Script) worms attach themselves to email messages. Upon clicking on the attachment, the system runs the script and the worm sends itself through the address book in order to infect other computers. Technically, this makes it a virus.
Macro viruses:
These may send out copies of themselves through the Internet to other computers, infecting them and spreading the infection further.
While we are aware that viruses will infect other computers, we may not know when they will activate. Many viruses will reside within a system waiting for a predetermined trigger to activate. This trigger could be anything; a date or time, an external event on your PC, executing a program a certain number of times, etc. Virus writers want their programs to spread as far as possible before anyone notices them. Viruses have unique methods of hiding in a system while awaiting activation. Macro viruses, however, can exist inside any document whose application uses a macro language. These are known as stealth viruses.
Stealth Viruses:
A virus must modify something in a system in order to function. In order to avoid detection by antivirus programs and alert users, it will take control of a certain functions and areas in the system that would make detection easier. This may be through a file, the boot sector or a partition sector. Some viruses may encrypt information in the computer. This makes the information accessible only as long as the virus is resident A virus may or may not always save the changes it makes in the system, so careful analysis is recommended when choosing a method of deletion. The use of FDISK/MBR IS NOT RECOMMENDED! Never use undocumented commands. If you do this you run the risk of making matters much worse. Undocumented commands are undocumented for a reason!
To better find stealth viruses be certain to cold boot from a known-clean (write protected) floppy disk and avoid using generic DOS commands to try to fix them. In addition to the section below, it is advisable to read this thread when attempting to disinfect an MBR virus:
http://www.suggestafix.com/cgi-bin....=34;t=7
Multipartite viruses:
These have characteristics of both boot sector viruses and file viruses. They may start in the boot sector and spread to applications, or vice versa.
This next section was posted by Nick Fitzgerald.
******************
Before describing what can to wrong, let's first see what the command does...
To understand what it does, first we have to get some terminology clear. The Master Boot Record (MBR) of a PC's hard drive is the very first physical sector on the disk (0,0,1 in head, cylinder, sector terms). There are some special things about the MBR. It contains (at a minimum) some executable code to start the bootstrap of the operating system, a 64 byte data area known as the partition table and a two byte signature (that some BIOSes reputedly do not check for).
Assuming that the basic BIOS hardware integrity tests pass and the BIOS configuration is set to allow booting from a hard drive, at power-up the MBR will be copied from the disk and execution passes to the beginning of the MBR. Standard DOS MBRs (they have slightly different code for different DOS versions and other operating systems) then analyze the partition table to find a primary, active DOS partition, and, if found, (there are other conditions depending on the DOS version among other things) the first sector of that logical partition (the operating system boot sector) is loaded into memory and execution passes to it (and that traditionally bootstraps the operating system proper). This may seem to be getting away from the MBR, but you also need to understand something about the typical disk layout of these structures.
Since DOS 3.0 the DOS boot sector has conventionally started at the first sector of a track (often 1,0,1, but never count on it). This has meant that all of the first physical track except the MBR (first sector) is "wasted space."
Now, on to what FDISK/MBR does...
Normally it overwrites what would be the DOS pre-bootstrap code part of the MBR, leaving the partition table and signature mentioned earlier.
Generally though, it sounds fairly harmless, right? "Generally" it is, and that explains why on many, many machines thousands of people have ignorantly done no damage to their drives.
The problem is, there are an awful lot of machines where my earlier description of the MBR contents and the layout of things on the first track of the hard drive do not match what FDISK is programmed to assume, and, as an Information Technology professional, I cannot conscientiously recommend something that can trash someone's disk without giving them a clear understanding of the possibility of making matters worse. This is why I refuse to post submissions that basically just say "Try FDISK/MBR" in response to "How do I clean ?" questions.
Examples of things that can go wrong and what happens:
A security system that does on-the-fly encryption and decryption of the hard drive may be installed with a pre-OS "driver" loading from the MBR bootstrap code. Such a scheme, being non-standard, has its own special MBR bootstrap code. Such code is typically much more than one sector (512 bytes) and as there is no DOS to interpret the file system, the "driver" is usually stored in the "wasted space" on track one (after the MBR) I referred to earlier. (A dual-boot MBR, e.g., OS/2, is another example that might fit into this category.)
You will lose access to your drive, at least until appropriate actions can be taken to reinstall the encryption software. Well-designed software of this kind will have been designed with data-integrity as well as security in mind so should have install options to allow reinstalling over a "corrupted" setup. Once FDISK/MBR has been run, the hard drive will most likely be completely inaccessible (after all, this is the point of most disk encryption schemes). Given someone was ignorant enough to corrupt it in the first place, what do you reckon the chances are they will have any idea they had a disk encryption scheme in the first place? (Or, at least, what are the chances they know how to have the installation fixed?)
A virus that does not preserve the original partition table in the right place or that encrypts it.
How many people do we get here (posted in the newsgroup comp.virus) per year with horror stories of "losing their C: drive" after FDISK/MBR against a Monkey-infected drive (or several other quite common viruses that also do not preserve the MBR in place)? These are usually quite easily fixed once someone who really knows what they are doing gets involved (unless the "expert" who just trashed the disk insists on continuing...).
A pre-OS driver to support "large drives" has been installed so a drive greater than 528MB can be used in a machine with an "old" BIOS. The mechanism for this is much the same as in 1 above.
Such large disk drivers (which are effectively a software BIOS extension) are quite common. (Anyone with a machine more than about 18 months old who has "upgraded" their hard drive is likely running one.) FDISK/MBR removes the driver that correctly allows access to cylinders 1024+, but the effect of removing it varies depending on all kinds of variables to do with the machines BIOS, the way the drive was partitioned, etc. As with encryption systems, many users of such large disk drivers have no idea that they are running one--afterall, computers are just "tools", you don't have to understand how they work to use them. Because the driver load mechanism is similar to the security products mentioned in 1, similar comments apply about fixing these should they be damaged by an unwanted FDISK/MBR.
A virus that leaves the partition table in place, but stores critical viral variables in what is normally the bootstrap code portion of the MBR. A particularly nasty possibility here is that a virus may be running on-the-fly encryption/decryption of the drive's contents using an encryption key that was randomly generated at infection time.
At least one family of "in the wild" viruses, One_Half, does what I described here. FDISK/MBR against a drive infected with a One_Half variant (or any future/unknown virus that uses a similar "trick") will remove the MBR infection (One_Half is multi-partite, so it doesn't necessarily clean One_Half completely), but leaves you with a hard drive whose contents are partially encrypted with a now unknown and irretrievable key. This is definitely a case of the "cure" being worse than the disease!
Some antivirus (or general "system integrity") software may have loaded a special MBR to allow itself to check for possible MBR infection/change attempts.
FDISK/MBR against such integrity systems has a wide range of effects depending on the design of the system, from simply warning you of a change to the MBR to completely locking you out of your hard drive until the system is reinstalled/reconfigured.
A currently unimplemented virus attack I will not describe in detail here.
I know of a boot virus attack that has only been partially implemented in a real world virus to date, where FDISK/MBR would apparently clean the virus, but on rebooting from the hard drive, the virus would be able to reinstall itself and would "know" that a (clumsy) disinfection attempt had been made against it. If the virus' author was so inclined, this could be used as a trigger for some nasty payload (like reformatting your drive).
I could have named examples of the first five, though the risk in doing that is people who do not know better will think they are the only possibilities, rule them out and blunder on.
Just in case it is not clear at this point, all of these things replace (part of) the "normal" bootstrap code in the MBR with their own code and/or data and in some way critically modify the function of the bootstrap process.
Now you understand why FDISK/MBR is DANGEROUS!
**************
Polymorphic Viruses:
These viruses attempt to confuse antivirus programs by creating copies of themselves that look different from each other. Thankfully, these copies are not completely different and scanners can detect them fairly easily. However, a true polymorphic virus would be almost impossible to detect because its definitions would be completely different each time it replicates. There would be no way an antivirus program would be able to keep pace. The closest things to a true polymorphic virus have come in the form of virus tool kits. These programs allow even inexperienced virus writers to create viruses that are relatively different from their predecessors easily and quickly. Again, it’s fortunate that these kits create viruses that are not so different from each other they are undetectable. A future threat stems from the fact that these kits may be used to create another kit whose virus signatures will be unique.
When NOT to use an antivirus program to kill a virus:
Remember, viruses can perform almost any command the author wishes. Some are worse than others in the amount of damage they cause and the number of files they infect. Some viruses actually use a virus scanner as an infection tool. When the virus scanner scans a computer, the virus will infect certain files the scanner has inspected as it completes the scan. This is evident in viruses like CIH (Chernobyl) and PE_KRIZ. Both of which, by the way, have massive payloads that cause destruction of all data in the hard drive and permanent damage to the system BIOS. Viruses such as these require the use of neutralizing programs before using an antivirus to kill them. Other neutralizing files are also available for many other malicious programs to make their removal simpler and more effective. Links for Internet sites that offer pre-removal files can be found at this link: http://www.suggestafix.com/cgi-bin....=40;t=1
Some trojan horses modify system command files. A virus scanner will recognize these files as infected and delete them resulting in a loss of functionality in the system. The Sub7 trojan horse modifies the Windows .EXE files, or the program responsible for running legitimate programs. The generic cleaner of a virus scanner will remove this file and the system will lose it’s ability to run execurtable programs. Programs that specialize in trojan horse detection provide the proper protection against and deletion of these malicious programs. These are located at the above link.
After infection of a partition virus.
As discussed previously, an antivirus should not be immediately used for any virus deletion until proper research has been initiated to determine the virus’s function or effect on the system.