Next	4.3- VERV Options
Previous	4.1- VERV's virus-description language
Up	4- VERV - A Prototype Virus Verifier and

4.2- Repair

For many viruses and many infected objects, it's possible to restore the object to what it looked like before it was infected, or at least to a state in which it will function in just the same way. Unfortunately, this isn't always possible; the classic example is the 1813 (Jerusalem) virus infecting an EXE-format file. While it's usually possible to undo the infection, sometimes the resulting file is missing data that was in the uninfected original, and it's not always possible to tell that this has happened. The best an 1813-remover can do on the EXE file, therefore, is something that is quite likely to work, but might not. In most cases, though, sufficiently-reliable repair is possible, and particularly in large infections of non-critical machines, repair is sometimes a cost-effective option.

A description of a virus in VERV's language includes one repair block for every type of object that the virus may infect. Each repair block consists of a header record ``REPAIR <object type>'', followed by one or more repair-operation records. Currently defined repair operations include:

• an FCOPY_TO record, that copies bytes from the start of the infected file up to a given number of bytes from the virus entry point (this is used to remove appending viruses),
• an FCOPY_FROM record that copies bytes from the infected file, starting a given number of bytes from the virus entry point, and ending a given number of bytes before the end of the file (this is used to remove prepending viruses),
• a BWRITE record, that copies so many bytes from a given offset in VERV's internal buffer (which initially holds an image of the virus) to a given offset in the file being repaired (this is used, for instance, to repair the first few bytes of an infected COM file, or the header of an infected EXE file),
• a BREAD record, that loads a given number of bytes from a given offset (relative to the start of the infected file) into VERV's buffer,
• an EXE_LENGTH_BUG record, that tells VERV that this particular virus has the common bug that it assumes that the image length in the header of an EXE file is the same as the file's length, and therefore damages (by overlaying some data) any EXE file that contains data after the EXE image,
• a 64K_COM_BUG record, which tells VERV that this virus has the common bug that it assumes that any file it thinks of as a COM file must be less than 64K bytes long,
• an EXE_LENGTH_ADJUST record, that treats two words within the buffer as the ``page count'' and ``last page length'' fields from a DOS EXE-file header, and subtracts a given constant value, adjusting them accordingly,
• an R_SPECIAL record, to cause VERV to invoke an internal C routine to perform some function not directly implemented in the language.

For instance, the repair block for the usual 1813 or Jerusalem virus currently looks like this:

REPAIR S-EXE
  EXE_LENGTH_BUG
  FCOPY_TO -0C5
  EXE_LENGTH_ADJUST 0053 0051 0710
  BWRITE 0043 0010 2       ; Fix SP
  BWRITE 0045 000E 2       ; Fix SS
  BWRITE 0047 0014 2       ; Fix IP
  BWRITE 0049 0016 2       ; Fix CS
  BWRITE 0051 0002 4       ; Fix image length
* Fixing COM files
REPAIR P-COM
  64K_COM_BUG
  FCOPY_FROM 0710 -5

The two BUG records cause VERV to print warnings to the user that some files may not function correctly, and to refuse to repair (later versions may offer to erase) any files that are obviously not correctly repairable. The FCOPY records pick out just the part of the file that does not contain the virus, and the EXE_LENGTH_ADJUST and BWRITE records restore and replace approximately the original EXE file header. EXE files that are successfully repaired will differ from the original file only in having been rounded up to a multiple of sixteen bytes (and the corresponding change in the EXE file header).

After repair is completed, VERV restarts processing on the repaired file, to ensure that there is not another instance of the virus present. If the virus is present in the file multiple times, all will be removed. Once VERV is integrated with a virus scanner, the repaired file will be automatically re-scanned for all viruses, and any found will be re-verified and removed.

Repair processing is only performed if the user has requested it on the command line, and if VERV finds that the virus is indeed exactly the known strain of the virus. In small infections, or in situations where correct operation of the objects involved is particularly crucial, we continue to recommend that infected objects be destroyed (files erased, diskettes formatted, and so on), and replaced from uninfected sources.

Next	4.3- VERV Options
Previous	4.1- VERV's virus-description language
Up	4- VERV - A Prototype Virus Verifier and

 

  back to index