VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Developing virus identification products

Tim Sankary

[Back to index] [Comments]

The following document is copyrighted, 1989, by Tim Sankary - all rights reserved. It may be copied and distributed freely as long as no changes are made and as long as this copyright notice remains with the document

I want to preface this document with a personal statement. I am aware that Jim Goodwin has published a partial list of his virus disassemblies and I can imagine the controversy that will result. I do not have an inside track to the "truth" of this Distribute/Don't Distribute issue, and I can frankly see both sides of the argument. I find it hard, however, to censure a colleague who has performed such excellent and dedicated work as Jim has, and I have to admire his courage in taking such a controversial step. For those of you who anticipate writing or designing Identification and Removal programs (CVIA Class III programs) for viruses, I hope you will find something of value in the following study that will be useful. If you have access to disassemblies, this document may provide some insights into designing your own disinfectant.

I would like to thank "Doc" John McAfee for his guidance and help in developing this paper, and the Computer Virus Industry Association for the outstanding visual aids that they contributed. These figures have been referenced in the paper but I have been unable to create ASCII representations of them for BBS distribution. If you obtained this document from an electronic source and would like a copy of the figures, they can be obtained by sending a stamped, self addressed envelope to the CVIA, 4423 Cheeney Street, Santa Clara, CA. 95054.

Tim Sankary
From the Homebase BBS
408 988 4004

In January of 1986, the world's first computer virus was unleashed upon an unsuspecting and largely defenseless population of global IBM personal computers users. The virus originated in Lahore, Pakistan, and spread rapidly from country to country through Europe and across to the North American Continent. In less than twelve months it had infected nearly a half-million computers and was causing minor havoc in hundreds of universities, corporations and government agencies.

This virus, later dubbed the "Pakistani Brain", caught the user community unawares and the problems resulting from its many infections demonstrated how unprepared we were for this phenomenon. The computer systems targeted by the virus contained no specific hardware or software elements that could prevent or even slow its spread, and few utilities could even detect its presence after an infection occurrence. Fortunately, the virus was not destructive, and it limited its infections to floppy diskettes; avoiding hard disks entirely.

The first defensive procedure developed to counteract this virus involved a simple visual inspection of a suspected diskette's volume serial label. The virus erased every infected diskette's volume label and replaced it with the character string - "@BRAIN". Thus, any inspection of the volume label, such as performing a simple DIRECTORY command, would indicate the presence or absence of the virus. An infected diskette could then be reformatted, or the virus could be removed by replacing the boot sector. This manual procedure is a typical, if somewhat rudimentary, example of the type of functions performed by a class of antiviral utilities commonly called Infection Identification products.

Infection identification products generally employ "passive" techniques for virus detection. That is; they work by examining the virus in its inert state. This contrasts with active detection products which look for specific actions employed by a virus. For example, looking for a Format instruction within a segment of code on a disk would be a passive method of detecting a potentially destructive program. If we detected the Format attempt during program execution, however, we would be performing an active detection. Passive methods concern themselves with the static attributes of viruses, active methods concern themselves with the results of virus execution.

Example active indicators are: the attempted erasure of critical files, destruction of the FAT table, re-direction of system interrupt vectors, general slowdown of the system, or an attempt to modify an executable program. These indicators are generic; that is, they are common to a large class of viruses. Because so many viruses perform these common activities, however, they are of little use in identifying individual virus strains. It is the passive virus indicators that prove most useful to a positive identification: The characteristic text imbedded within the virus, specific flags, singular filenames or a distinctive sequence of instructions that are unique to the virus. These and other similar indicators can best be ascertained by scanning system storage and examining the program files and other inert data.


Virus identification products have their genesis in the utility programs first developed in 1982 and 1983 to check public domain software for bombs or trojans before they were executed. These utility programs initially checked for questionable instructions in the suspect program's object code. Direct input/output instructions, interrupt calls, format sequences and like instructions, if found, were flagged and the user was notified. Later versions included tests for imbedded data strings that were typically used by trojan designers. Suspect programs were scanned for profanity, for keywords like "gotcha" or "sucker", and for data strings that had been found in specific trojan programs. Some programs looked also for specific names of files that were frequently used by trojans and bombs.

These products, however, were seldom able to identify a specific bomb or trojan. Rather, they indicated that the suspect program contained instructions or messages of a questionable nature - implying that the program might be a generic trojan. This, however, is not sufficient for dealing with viruses.

Viruses create entirely different problems than bombs or trojans. Viruses replicate, and can infect hundreds or even thousands of programs within an installation. They remain invisible for long periods of time before they activate and cause damage. And, they are difficult to remove because they imbed themselves within critical segments of the system. It is not sufficient to know that a virus is present, it is necessary to know which virus is present. We must know how it infects, what actions it takes, and, most importantly, what must be done to de-activate and remove the virus.

Thus, when the first virus identification products emerged in 1986 they didn't just look for generic code or messages, they looked for specific indications that could identify the individual virus strain. This allowed the user to verify a specific infection occurrence and take appropriate action. Later versions of these products went a step further. They actually removed the virus when an infection was identified.


Before we discuss the techniques used by identification products, we need to look briefly at how viruses insert themselves into programs. As shown in Figure 1, viruses actually modify the structure of the programs that they infect. Generally, the virus replaces the program's start-up segment with a routine that passes control to the main body of the virus. This main body code may be inserted within the program in a buffer area, or it may be added to the beginning or the end of the program. After execution of the virus, the program's original start-up sequence is replaced and control is passed to the program.

When removing a virus from an infected program, it is crucial to determine exactly how the virus modified the program. Each virus differs from other viruses in size, segmentation and technique. Each virus chooses a different area for infection, stores the start-up sequence in a different location. and return control in a different manner. We must know exactly what the virus did during the infection process in order to reverse the steps for removal.

Thus, it should be clear that in order to develop an antidote for a specific virus, we must first obtain a copy of the virus for analysis. A thorough analysis of the structure and design of the virus will provide the answers to all of the above questions.

When a virus has been disassembled and analyzed, we in theory know all there is to know about the virus. We are then able to create an "attribute file" for the virus. This file contains all of characteristics of the virus that can be uniquely assigned to the virus. For example, we may find imbedded data within the virus that we would not reasonably expect to find in any other program or data file. Or we may find an instruction sequence that is sufficiently unusual that we would not expect any other program to use the exact same sequence. Figure 2 shows two virus examples that contain unique imbedded data. In the Pakistani Brain example, it is clear that we would not expect to find the exact same name, address and telephone number in any other program.

In addition to "identification" attributes, the attribute file contains all information necessary to reverse the virus infection process. Common elements of an attribute file might be:

When the attribute file has been created, it is inputted into a program that scans all of the appropriate areas of system storage looking for combinations of the attributes. As more attributes are discovered, the degree of assurance that the virus is present increases. For example, the character string "sUMsDOS" is common to all versions of the Israeli virus. It is conceivable, however, that the same string could appear randomly in any text file. Therefore, the identification program will look for verification attributes, such as the file offset where the character string was located, or a sequence of instructions following the data.

When the virus has been identified, the removal phase begins. Since the infection attributes of the virus are known, the removal process is fairly straightforward. Usually it involves locating the main body of the virus and all segments of the original program that had been re-located by the virus. The virus is erased, and the program is then re-constructed.

Clearly, multiple attribute files can be used by a single program. Thus, single identification products are able to identify multiple strains of viruses (see Figure 3).

Product Advantages

Infection identification products have a major advantage over other types of virus protection products: They are able to determine whether or not a system is already infected. This is a serious concern in many organizations. Other classes of virus protection products must assume that a given system is uninfected at the time the products are installed. They log the state of the system at the time they are installed and periodically compare the current state to the original state. If a virus has infected the system in the interim, the change will be detected. If a virus has already infected the system before such products are installed, however, the virus will be logged as part of the original system, and no change will be detected.

Infection identification products, on the other hand, are specifically designed to look for and identify pre-existing infections. This ability to identify an existing infection is in many cases crucial to the success of implementing antiviral measures. Since a virus may remain dormant for months or even years before it activates and damages the system, pre-existing infections could cause widespread destruction in spite of our best efforts at implementing protection programs.

Automatic removal is the second advantage of identification products. Virus infections can sometimes involve hundreds or thousands of programs within an organization. When the virus is discovered, the task of tracking down and disinfecting all of the infected programs can become monumental. In many cases, multiple versions of a single program may be infected, or the original source diskettes may have been lost or misplaced. In some cases, infected programs may be overlooked or incorrectly replaced, so that re-infection becomes a problem. These and other issues invariably cause problems. The identification products, however, automatically find, identify and remove the infection, normally at a rate of a few seconds per infected program. The time savings alone can be enormous.

A third advantage to identification programs is that they cannot be circumvented by a known virus. Other types of products that use active methods for infection prevention or detection can be specifically targeted by viruses. The virus can seek out and destroy or disable the active element of such products. For example, if the product is a filter type product that monitors all system I/O, the virus can steal the interrupts from the monitor and thus bypass the program's checking function. Likewise, if a protection program uses a checksum or other method to look for change within a program, the virus can modify the program's checksum routine so that the change caused by an infection will not be detected. These and other techniques have been used by many viruses to avoid interference by antiviral programs that use active detection methods.

Identification products, on the other hand, cannot be so easily circumvented. Since these products use passive techniques, the virus has no control over the products' functions. Keep in mind that the virus and its resultant system modifications are merely a sequence of inert bits as far as the identification product is concerned. Also the virus is not active at the time the product is being used (all such products come with their own boot diskettes, and they run stand-alone). Thus, the virus can in no way affect the product's operation, or even be aware of its presence.

Problem areas

There are some drawbacks to identification products however. The first problem is that these products only work for known viruses. That is, a virus that has been around long enough to be noticed, isolated, sampled, disassembled and analyzed. This may take a considerable time if the virus is unobtrusive and slow to activate. When the virus has been discovered and analyzed, the identification product must be designed, implemented, packaged, marketed and distributed - a process that could take considerably more time. Thus identification utilities will lag new virus developments by months, or in some cases, even years. This time lag implies that there will always be new viruses, and thus new dangers, against which no identification utility will be effective.

The second problem with these products is more thorny, and requires a high level of product sophistication in order to resolve. At issue is a phenomenon that might be called the Uncertainty Factor, and it is caused by the increasing tendency of hackers to collect existing viruses, modify them and return them to the public domain. These modifications sometimes cause viruses to react differently from the ways in which they were originally designed, yet they may leave key identification attributes unchanged.

For example, the Jerusalem virus was originally designed to slow down the infected machine's processor one-half hour after an infected program was executed. This slowdown was a nuisance to the user of the infected machine, but it severely limited the spread of the virus, because the virus made itself known early in the infection process and had limited time to replicate before being removed. In the summer of 1988, an unknown hacker modified the virus by changing just one instruction (see Figure 4). This modification disabled the routine that caused the system to slowdown, and as a result, the virus became many times more infectious.

Modifications like this, and other more substantial modifications, are made almost daily to existing viruses. The danger that these modifications pose to identification products is substantial. If an identification product is attempting to remove a virus that has infected a program differently than the way in which the product expects, then the results of the disinfection will be unpredictable. Damage to the system may result, the program may be destroyed or, in the worst case, the virus will still be active even though the product thinks it has removed it.

In order to minimize the risks posed by this problem, identification products must be designed to cross reference as many virus attributes as possible prior to attempting removal. If any one of the expected attributes has been changed, or is missing, the product should notify the user of the potential problem and manual intervention will be required.

Future Prospects

Identification products clearly must play a major role in the battle against computer viruses. As viruses become more widespread and as infections become more common, the need for utilities able to identify and help remove viruses will become apparent. It is probable that these products will become the dominant form of virus protection in the future. A few technical advances, however would greatly aid their general acceptance.

One of the problems facing identification products is the time required to fully scan attached storage devices when searching for a virus. For example, as many as ten or more minutes can be required to fully scan a 40 megabyte drive while looking for just one virus. Multiple virus checks require more time. Because of this, it is impractical to perform frequent scans of the system. This is unfortunate because it would be advantageous to perform a complete identification check of a system each time the system was booted. This would provide a high degree of system security, assuming that the identification product was kept up to date. More sophisticated algorithms for searching attached storage and creative techniques for multiple virus scans could alleviate the time scan problem.

A second desirable advance in the technology of these products would be the development of techniques that could identify variations of known viruses and still provide the capability to remove the modified virus. This advance would remove a major limitation of the current products and would greatly increase their reliability. Techniques for removing variations have already been developed for a few root viruses, but there currently exists no generic technique that is effective for a large class of viruses. I anticipate that this hurdle will be overcome within a year or two.

A final enhancement would be the ability to fully or partially re-structure data that has been corrupted by a virus after it has activated. Currently, infection identification products are only useful if they are used before a virus begins its destructive phase. When the destructive phase begins, the virus may destroy critical control tables, data files, programs or even itself. At this point all current virus products have limited usefulness.

It is possible in some cases, however, to reverse much of the destruction caused by a virus provided: 1) We know the details of the destruction process, and 2) The destructive phase has not gone on too long. For example, one of the common PC viruses scrambles the File Allocation Table by reversing a number of the entries. Since we know the exact way in which the virus scrambles the information, we can easily unscramble it. However, after a few days of data scrambling, the virus initiates a low level format of the hard disk. At this point, no recovery is possible.

I anticipate that future products will incorporate recovery capabilities for a large number of virus destructive acts. This capability, and others described above, should provide the best virus protection that we can hope to achieve.

[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka