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

Text File | 1991-05-28 | 14.3 KB | 285 lines

             *********************************************
             ***   Reports collected and collated by   ***
             ***            PC-Virus Index             ***
             ***      with full acknowledgements       ***
             ***            to the authors             ***
             *********************************************


  Report from Jim Bates - The Virus Information Service - 23rd
  December 1990

  === Spanish Telecom Virus aka HOLOCAUST, TELEFONICA ===

  Another virus attempting to make a political (?) point has recently
  come to hand from Spain.  This is being called the "Spanish Telecom"
  virus for reasons which will become apparent as this analysis
  progresses.

  This virus is a true multi-partite virus in that it functions both
  as a parasitic virus infecting COM files, and as a Boot Sector Virus
  which infects the Master Boot Record of the first fixed disk drive
  as well as the boot record of any type of floppy disk.  The code
  contains a particularly vicious trigger routine which will overwrite
  all data on both the first AND SECOND fixed disk drives.  The
  trigger routine is invoked from the boot code section of the virus
  after the 400th infected boot cycle.  The parasitic code is
  encrypted and contains plain text at the end of the code which reads
  :

         Virus Anti - C.T.N.E. (c)1990 Grupo Holokausto.
         Kampanya Anti-Telefonica. Menos tarifas y mas servicio.
         Programmed in Barcelona (Spain). 23-8-90. - 666 -

  The final "666" may be a reference to the 666 (Number of the Beast)
  virus since certain techniques first noticed there have been used
  here!  The phrase translates roughly as "Lower tariffs, more
  service."

  Another message which is separately encrypted is displayed during
  the overwriting activity of the trigger routine :

         Campana Anti-TELEFONICA (Barcelona)

  Analysis of this code is best undertaken by considering the
  Parasitic and Boot sections separately -


  Parasitic Analysis

  This is undoubtedly one of the most untidy pieces of code that I
  have examined.  There are many repetitions and several bugs which
  will reveal the presence of the virus long before the trigger
  routine is invoked. The virus code is attached at the end of COM
  files between 128 and 60999 bytes in length (inclusive).
  COMMAND.COM is specifically excluded from infection as is any file
  beginning with the letters "IBM" (the IBM system files).  The
  initial four bytes of the host file are saved within the virus code
  and overwritten with an appropriate jump instruction to pass
  processing to the virus code.  The infective length of the parasitic
  code is 3,700 bytes (this includes the Boot code).  The virus code
  begins with an 85 byte section which contains "armoured" coding to
  detect the presence of debugging software and also several
  randomised instructions which are presumably intended to prevent the
  extraction of a reliable search string.  Within the code there are
  two different versions of this 85 byte "header" routine, only one of
  which is actually positioned for use during the file infection
  process.  There are therefore two distinct search strings for the
  parasitic code although each confirms the existence of the same
  virus.

  Both "header" code routines perform the same functions: check for
  debug presence, locate the position of the virus code within the
  host segment and decrypt the remaining code.  Processing then checks
  to see if the virus is resident in memory.  This is done by
  collecting the byte at offset 1BCH of low memory and XORing it with
  13H, the result is then checked against the next byte at offset
  1BDH.  If they are the same then the virus is resident and
  processing passes directly back to the host program.  The actual
  values of these two bytes are changed regularly by the virus during
  its intercept operations but by simply XORing them together,
  regardless of their values, the result will be 13H if the virus is
  resident in memory.

  If the virus is not resident, the current INT 21H vector is
  collected and stored in memory.  Collection is via direct access to
  page zero of memory where the interrupt vectors are stored.  All of
  the virus code is then installed in high memory and 3984 bytes are
  removed from system memory to accommodate it.  The next set of
  instructions collects a pseudo-random number from the system clock
  and uses it to index into a table of word addresses.  The selected
  word is then inserted as the offset portion of the INT 21H vector in
  low memory, the segment portion being set to the virus' own segment
  in high memory.  This random process of selection ensures that the
  actual offset stored in the interrupt table will vary from infection
  to infection.  Each address, though different, points to a jump
  instruction which takes processing to a single INT 21H handler
  within the virus code.  There are 14 entries in the address table
  although only 7 of them are used and this, together with other
  sections of the code, suggests that other ideas may have been tried
  (or are being prepared) within this code.  Once the interrupt
  handler has been installed, a special call is made to it which
  completes the installation process.  This call consists of putting
  4B21H into AX and issuing an INT 21H request.

  The special call is routed by the virus' handler to an installation
  routine which uses the single step INT 01 capability in the same way
  as the Flip virus (VB Sept 90) to "strip" out any extraneous
  handlers from the targeted interrupt chain.  Interrupts treated in
  this way are 13H, 21H and 40H and the stripped vectors are
  temporarily installed during file infection and repaired when the
  process has completed.  Thus any monitoring software which uses
  installed handlers will need to contain reliable self-testing
  routines to guard against this type of subversion.

  The virus interrupt handler intercepts six different function
  requests within the DOS services interrupt :  function 4B21H has
  already been mentioned and there is another special call using a
  value of 4B20H which does nothing.  This is another area which gives
  rise to speculation that further developments may be in hand.  The
  SEEK function (42H) is intercepted when accompanied by subfunction
  02 (to End of File).  This checks to see if the file has been
  infected and if so, modifies the pointer to subtract the length of
  the virus code before returning the End of File position.  The two
  alternative sets of Find First and Find Next functions (11H - 12H
  and 4EH - 4FH) are similarly intercepted to return a modified file
  size on infected files.

  The main intercept however, is that applied to the Load and Execute
  function (4B00H).  This is used to select and infect files with a
  COM extension (subject to the name and size exceptions mentioned
  earlier).  Once a suitable file has been identified, the INT 13H and
  INT 40H vectors are temporarily replaced with their stripped
  equivalents and a simple handler for the critical error interrupt
  (24H) is installed.  The usual process of file infection is then
  invoked whereby the target file date, time and attributes are
  collected and stored, and the file is opened for Read/Write access
  (attributes are modified if necessary).  The correct initial jump is
  calculated and the first four bytes of the target file copied and
  stored before being overwritten by a jump to the virus code.
  Certain sections of the virus code are then modified by the addition
  of random data values generated from a system clock reading.  The
  next stage involves using one of these data values as the new
  encryption key into one of the two 85 bytes decryption headers
  (chosen at random).  The header is written (unencrypted) to the end
  of the host file and then the encryption routine is executed.  The
  whole of the virus code is encrypted and written to the end of the
  host file one byte at a time - each byte is collected, encrypted and
  written on an individual basis.  This removes the need for either a
  special buffer or a decrypt/recrypt cycle.  The final stage is to
  close the file and reset the date, time and attributes to their
  original settings.  As a marker to indicate that the file is
  infected, the date setting is modified in a similar way to the 4K
  (IDF or FRODO) virus by adding 100 to the year field.  Modified
  interrupt vectors are then reset to their previous values before
  processing returns to the calling routine.

  During the installation of the handlers, a check is made to see if
  the Master Boot Record of the first hard drive is infected with the
  virus' boot code.  If the disk is not infected then the boot section
  of the virus code is installed in Sector 1, Head 0, Track 0.  The
  second sector of virus code is stored in sector 6 of the same track
  and the original boot sector is stored in sector 7.  This will cause
  problems of access on some machines which use these sectors for
  other purposes.


  BOOT Analysis

  The boot section of this virus functions completely independently of
  the parasitic portion and both sections will almost certainly be in
  memory simultaneously.  This may explain the almost obsessive
  concern with revectoring interrupts during the parasitic file
  infection.  However, while the parasitic code contain all the virus
  routines, the boot section is limited to two sectors of self
  contained code.  Thus a machine infected with only the boot code
  will not infect files, only other disks.

  The only items worthy of note in the boot code are the Trigger
  routine, the floppy infection routine and the interrupt redirection.
  The interrupt redirection intercepts requests to INT 13H for both
  floppy and hard drives.  A Read or Write request to either the first
  or second floppy drive will result in the disk being checked for
  infection and infected if possible.  The routine is unusual in that
  it will only complete the check and infection if the motors of both
  of the first two floppy drives are NOT running.  INT 13H requests to
  the first hard drive are intercepted and tested to see if they are
  Read or Write.  A Write request to the Master Boot Record of the
  first hard drive is changed into a Verify call so that the sector
  will not be overwritten if the virus is resident.  Read requests are
  tested to see which sector (on Head 0, Track 0) is wanted and
  re-routed accordingly.  Requests for sector 1 are given sector 7
  (where the original boot sector is stored) and requests for either
  sector 6 or 7 are given sector 5.  Thus in a similar way to the
  original Brain virus, it is not possible to examine the true boot
  sector of an infected machine with ordinary utilities while the
  virus is resident.

  Floppy Infection

  If an uninfected floppy is accessed, the virus will attempt to
  infect it and the storage sectors used for the second sector of code
  will vary according to a table maintained within the virus code.
  Remember that both first and second (A:  and B:) drives are affected
  - the table looks like this :-

      Floppy Type        Head and Sector of second part of virus
      160K - 5.25"              0     6
      180K - 5.25"              0     8
      320K - 5.25"              1     1
      360K - 5.25"              1     2
      720K - 5.25" or 3.5"      1     4
      1.2M - 5.25"              1    0DH  (decimal 13)
      1.44M - 3.5"              1    0EH  (decimal 14)

  From this table it will be seen that infected disks may become
  unreadable as virus code overwrites sections of the FAT or Root
  Directory.  To complete this information you should note that the
  virus code occupies sectors 1 and 6 of a hard disk, with a copy of
  the original boot sector being stored in sector 7 (all on head 0,
  track 0).


  Trigger Routine

  When a machine is booted from an infected hard disk, a counter
  within the boot code is incremented and tested to see if it has
  passed 400 (190H).  If it hasn't, the code is rewritten back to the
  boot sector and processing continues normally.  However, when the
  counter does reach this number, processing immediately passes to the
  Trigger routine.  This is one of the nastiest, most destructive
  triggers that I have yet seen since it will overwrite all sectors of
  both the first and (if there is one present) the second hard drive
  with random information from boot-time low memory.  The overwriting
  routine will be completed a number of times (for each drive)
  depending upon the number of heads on the drive.  On each pass, the
  encrypted message mentioned above will be displayed.


  Recognition

  It has been necessary to extract a different recognition string for
  each version of the parasitic code and these are as follows:-

  Header 1 - 8B1D B200 83FB 0074 18BF 5500 B2         Offset - 34H

  Header 2 - 83ED 09BE 2001 03F5 FCB6                 Offset - 24H

  It should be noted that the presence of either of these strings at
  the appropriate offset (into the virus code) is an indication of
  infection.  Infective length of the parasite is 3700 bytes (appended
  on LOAD and EXECUTE).

  Recognition of the presence of the Boot virus code is simpler but
  note should be taken of the interrupt redirection discussed above.
  The code is not encrypted and the recognition string is as follows
  :-

        8A0E EC00 BE70 0003 F18A 4C02 8A74 03C3     Offset - 0B3H


  VIS Classification - BfmCARKD3700A


  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 ++++++++++++++++++++++++
  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++