Nomenklatura Virus

 

             *********************************************

             ***   Reports collected and collated by   ***

             ***            PC-Virus Index             ***

             ***      with full acknowledgements       ***

             ***            to the authors             ***

             *********************************************

  Report from Jim Bates - The Virus Information Service - November

  1990

  === Nomenklatura Virus ===

  The recent shift amongst virus writers towards self-encrypting,

  self- protecting and anti-disassembly code does not mean that the

  more primitive types have ceased to appear.  One of the latest

  emanations from the bored and irresponsible Bulgarian virus

  "factories" is a 1024 byte virus named "NOMENKLATURA" (from the

  title within the code).

  This is a primitive and untidy parasitic virus which infects COM and

  EXE files.  No attempt is made to hide the code either on disk by

  means of encryption, or in memory by means of interrupt redirection.

  The code is also quite easy to disassemble since it contains little

  that is not completely straightforward.  However, NOMENKLATURA

  easily qualifies as one of the nastier viruses because of the nature

  of its payload and the inconvenience caused by even a slight

  infection.

  The operation of the virus is as follows:

  INSTALLATION

  The virus code will be appended to the host file in the usual

  fashion, with appropriate modifications having been made to the

  beginning of the file to ensure that the virus code is executed

  first.  The code begins by issuing an "Are you there?"  call to the

  operating system. This consists of placing a value of 4BAAH into the

  AX register and issuing an INT 21H call.  If the interrupt handler

  returns with the Carry Flag set, then the virus is not resident and

  the installation routine is invoked.  Otherwise processing continues

  by repairing the header of the host file and then passing control to

  it.  The installation routine first accesses page zero of memory and

  collects the INT 13H vector address.  This is then swapped into the

  INT 13H handler by calling the 13H function of the multiplex

  interrupt at 2FH.  This swapping process reveals the vector address

  of the specific machine disk handler (usually in ROM) which is

  pushed onto the stack.  The INT 2FH is then immediately called again

  to repair the vectors and the saved address is popped from the stack

  into memory.  The INT 21H vector is then collected by directly

  accessing the interrupt table in low memory.  Once these vectors

  have been collected and stored, the code continues by modifying the

  memory pointers stored in the Program Segment Prefix area to make

  room for the whole of the virus code to be moved up to high memory.

  43 paragraphs (1072 bytes) of memory are made available in this way

  but before the code is moved, the multiplex interrupt 2FH is called

  again to insert the virus' own vector into the handler chain.  Then

  the virus code is then resited with a block move.  THe final step of

  this section of code is to repair the host program header (or

  original jump in the case of a COM file) and then transfer control

  to it.  Once the virus is installed and "hooked in" to the operating

  system interrupts, further virus control is established via the

  newly installed interrupt handler routines.

  Interrupt 21H Handler

  NOMENKLATURA intercepts only the Load and Execute (4BH) and ASCIIZ

  Open (3DH) functions of INT 21H.  On receipt of either of these

  function calls, the relevant file will be checked and infected where

  possible.  The only exception is the virus' own recognition call of

  4BAAH which simply clears the carry flag (by reference to the stack)

  and then returns to the calling routine.  The infection process is

  exactly similar, regardless of which function has been received:

  The ASCIIZ filename of the target file is first examined to find

  either a COM or EXE extension.  If neither of these is found then

  the virus allows the function request to continue unaltered.  At

  this point, no note is taken of which type of extension was

  discovered and both types are treated similarly until a later check

  for the presence of the 'MZ' header which typifies EXE files.  First

  the file date and time stamps are collected and stored, then the

  file is opened for Read/Write access using function 3DH of the

  original (ie: pre-virus installation).  If the Open request is

  successful, then a routine is invoked which installs two temporary

  vectors for use only during the infection cycle.  The vectors

  involved are INT 24H which is modified to prevent DOS from reporting

  disk errors to the screen, and an INT 13H function dispatcher which

  is installed to prevent possible FAT corruption during the infection

  cycle.  Once these temporary vectors have been set, the virus reads

  the first 24 bytes of the file header into a prepared buffer area.

  It is at this point (if the read was performed successfully) that a

  check is made for the 'MZ' header marker and according to its

  presence or absence, the appropriate infection appending routine is

  called.

  INFECTION CRITERIA

  Ignoring the differences necessary for infecting either COM or EXE

  files, each infection routine functions in substantially similar

  fashion with one or two small exceptions.  With EXE files, any file

  greater than 1023 bytes in length is a candidate for infection,

  while with COM files only those with a length between 1025 and 63999

  bytes may be infected.  The method by which this virus recognises

  infected files (for both EXE and COM) is to check the available code

  after the initial jump destination (or the initial IP setting for

  EXE files) and if this is exactly 1024 bytes then the file is

  assumed to be infected.  This method is somewhat hit and miss but as

  someone once said, "When did the recipient of a virus ever complain

  that it didn't work properly?".  Once infection is completed, the

  file date and time stamps are reset to their original values, the

  file is closed, the temporary interrupt handlers are removed and

  processing continues with the original INT 21H function call.  Since

  at no time is a check made of the Read/Write attribute of the target

  file, infection spread can be prevented by the simple expedient of

  setting all EXE and COM files to Read Only.  However, this will NOT

  stop an already infected file from installing the virus and the

  corruption described in the next section may still occur.

  Interrupt 13H Handler

  This is essentially a flag controlled routine which monitors

  subfunctions 0, 1, 2 and 3 of INT 13H.  The monitoring processing

  consists of generating two distinct counts from the contents of each

  word of the sector buffer.  The words are examined sequentially as

  if they were FAT cluster markers and any word with a value of less

  than 0FFF7H (ie: EOF marker) causes Counter 1 to increment.  At the

  same time, any word which has a value of exactly one less than the

  succeeding word (ie: denoting contiguous clusters) also increments

  Counter 2.  The contents of Counter 1 are then halved and if the

  original value was an even number, then processing continues

  uninterrupted.  However, if the original value was odd then a

  comparison is made between Counter 2 and the halved Counter 1 and if

  Counter 1 is the lower value then the "payload" is delivered.  This

  process is described in detail to give some idea of the random

  nature of the occurrence of the "payload" routine and in tests on a

  sacrificial machine, corruption began to appear as files numbers

  were increased and the disk passed the half-full mark.  It is quite

  possible that NO corruption would occur on a badly fragmented disk

  but the nature of this virus is such that it is almost impossible to

  verify whether corruption has occurred or not.

  The corruption introduced by the "payload" consists of swapping a

  pair of words in random positions within the sector buffer.  This is

  done by using a modified reading from the system clock as a double

  index into the sector buffer and exchanging the words found at each

  index point.  The effect on machine operation is totally

  unpredictable since any two clusters, anywhere on the disk will be

  transposed.  Thus any file occupying an affected cluster will

  suddenly contain completely different data at that point and such

  data may or may not actually belong to another file (no attempt is

  made to check the contents of the transposed cluster words).

  Obviously any type of file (data, program, system, control) may be

  affected as will both of the File Allocation Tables - but

  differently.

  File Recognition

  Since this virus is non-encrypting, file recognition is easily

  accomplished by searching for the signature listed in last month's

  Virus Bulletin -

         B8AA 4BCD 2173 785E 5606 33C0 8ED8 C41E  at Offset 2DD

  Conclusion

  NOMENKLATURA is poorly written and untidy in its coding.  Mention

  has already been made of its failure to check the attribute of

  target files but there are several other indications that the author

  does not fully understand many of the functions and capabilities of

  the PC environment.  This leads me to conclude that the author is

  probably someone quite new to computing and who may well have become

  involved in the "virus fervour" currently reported as rampant in

  Bulgaria.

  Nevertheless the virus works and the fact that its payload is

  delivered on such a random basis and at such a vital section of the

  disk architecture makes this a particularly nasty specimen.  If this

  virus has been executed on a machine, then ALL files on that machine

  are subsequently suspect!  The best course is is to delete them and

  reconfigure the machine from scratch.  Note that even a secure CRC

  checking program which has taken unique footprints of ALL files may

  itself have suffered corruption along with any associated key files.

  The only alternative to complete reconfiguration is separate

  verification of the integrity of EACH file against a known good copy

  or previously calculated, reliable CRC.

  VIS Classification - CcEAX1024A

  The information contained in this report is the direct result of

  disassembling and analysing a specimen of the virus code.  I take

  great pains to ensure the accuracy of these analyses but I cannot

  accept responsibility for any loss or damage suffered as a result of

  any errors or omissions.  If any errors of fact are noted, please

  let me know at :-

The Virus Information Service,

Treble Clef House,

64, Welford Road,

WIGSTON MAGNA,

Leicester  LE8 1SL

  or call +44 (0)533 883490

  Jim Bates

  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  ++++++++++++++++++++++++++ end of reports ++++++++++++++++++++++++

  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++