4.1- VERV's virus-description languageThe file from which VERV reads virus descriptions consists of a number of virus-description blocks. Each block has the following structure: One or more VIRUS records
A NAME record
One or more LOAD records
Zero or more DEGARBLE and related records
Zero or more ZERO records
One or more check records
Zero or more REPAIR blocks
For instance, the block for the Slow-1721 virus currently looks
like this:
VIRUS slow slow-1721 NAME the Slow-1721 virus LOAD P-COM 0 6B4 LOAD S-EXE 0 6B4 DEXOR1 001E 06AD 0012 0000 ; Degarble the code DEXOR1 00EB 0159 0061 0001 ; and the data area ZERO 0012 1 ; Zero the code-garble key ZERO 0061 1 ; and the data-garble key CODE 0000 00EA 38d5dc08 ; Code up to first data area CONST 0144 014E 0ff22ad9 ; COMMAND.COM CODE 015A 063C 74e00962 ; Code between data areas CODE 0657 06AD ad3b0b41 ; After the second data area The VIRUS records simply give a list of one-word aliases for the virus, that are used on the command line to tell VERV which virus to look for. These aliases are not the full primary name of the virus (that is given on the NAME record); they are just short abbreviations that the user can use on the command line. A very useful extension here would be for VERV to support virus families, so that a single command would cause testing for all members of the Jerusalem family, or the Flip family, and so on. When integrated into the virus detector, of course, the detector will directly inform the verifier which virus or viruses to test for. The LOAD records describe where in an infected object of a given type the virus can be found. The tokens on a LOAD record are an object type, followed by either an offset and a length, or the word SPECIAL and a number. The offset tells VERV where, relative to the effective entry-point of that sort of object, to start loading; the length tells how many bytes to load. For viruses that are not always at a fixed offset from the initial entrypoint, the SPECIAL keyword causes VERV to invoke an internal routine, coded in C, to perform the loading. The Slow virus is an EXE-infector, and a prepending COM infector; the LOAD records in this example tell VERV to load the first 06B4 bytes of a COM-format file, and the first 06B4 bytes after the entry point of an EXE-format file. (EXE-format files are those that begin with the letters ``MZ''; DOS loads these differently from COM-format files, which begin with any other bytes.) Other object types supported include:
The DEXOR1 records tell VERV to perform a certain common type of degarbling: a one-byte XOR with data to be found at a fixed offset in the virus. The details are not terribly important here. A more general record, consisting of just the word DEGARBLE followed by a number, causes VERV to invoke an internal C-language routine to perform degarbling. Once the loading and degarbling have been done, VERV has a complete ``virus image'' in its internal buffer. A command-line switch (described later) can instruct VERV to save the contents of this buffer to a file, for later examination. The ZERO records describe variable areas within the virus, that should be set to zero before checks are done. This is really just a convenience, to reduce the number of check-type records needed. There are three basic types of check records, describing different tests to be done on the degarbled and zero'd virus image now in the buffer:
Normally, VERV performs its CRC calculation on each area within the virus, and compares the results to the expected values. A command-line switch (described in more detail below) can be used to tell VERV to read a standard copy of the virus from another file instead, and do byte-by-byte comparison between the two. This is more reliable, but of course it requires having a sample of the usual strain of the virus present to verify against. Another example, illustrating the use of special C routines, is the block for the 1701 virus: VIRUS 1701 NAME the 1701 virus LOAD E9-COM -1 06A5 DEGARBLE 1 CODE 0001 0026 19989c7e ; Degarble, MOV, jmp-in CODE 0076 06A4 c03a91c5 ; Main code Here, the ``DEGARBLE 1'' record causes VERV to invoke an internal routine to degarble the data in the buffer, using the 1701's own algorithm. It would be possible to enhance the virus-description language enough that the 1701's degarbling algorithm could be expressed in it directly. This would complicate the language considerably, though, and would somewhat lessen the advantage that a special high-level language has over native C code; so far, we have decided against such enhancements.
|