ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/UTILITY/VIRUS/PCV4RPT.ZIP/NOMENK.RPT

Text File | 1991-05-28 | 11.0 KB | 214 lines

             *********************************************
             ***   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 [phone]

  Jim Bates

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