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

Text File | 1991-05-28 | 15.0 KB | 270 lines

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


  Report from Jim Bates - The Virus Information Service - August 1990

  === FLIP Virus ===

  PC viruses are generally categorised into two main types - Boot
  Sector viruses (which include those that modify the Master Boot
  Record) and Parasitic viruses which are far more common and spread
  by infecting program files.  It has long been expected that a
  composite of these types would eventually appear and the FLIP virus
  is the first one of these that I have actually seen and had the
  opportunity to examine in detail.  The code seems to have been
  written by an experienced programmer and obviously took quite some
  time to develop.  The trigger routine affects only systems with EGA
  or VGA monitor facilities and produces a mirror image effect in
  screen modes 2 and 3, flipping the display horizontally and showing
  a modified font which reverses each character.  Some disturbing new
  trends are also evident within this code, particularly a number of
  routines which attempt to avoid the attentions of resident
  monitoring software or pervert the actions of a particular virus
  detection program.  The code appended to files has a simple
  encryption algorithm but that written to the MBR and elsewhere on
  the disk is not encrypted and is therefore easy to recognise. Apart
  from the one instance mentioned above, this virus makes no attempt
  to protect itself from detection although the randomisation of the
  position of the decryption routine does prevent the extraction of a
  recognition "signature" for the parasitic code.  Simple file
  checking programs however, will be able to recognise the file
  changes introduced by infection even if the system is infected while
  the checking is in progress.

  There are three main paths by which this code can be executed,
  infected COM type files, infected EXE type files and the Boot code.
  The virus does NOT check file names so renamed COM or EXE files are
  still processed correctly according to their type.  Subsequent
  references here to COM or EXE files should therefore be considered
  as COM (or EXE) TYPE files. Parasitic infection is invoked via an
  interrupt handling routine which intercepts the LOAD and EXECUTE
  function request.  This means that files with other extension names
  (BIN, OVL etc.) could become infected although overlays are
  specifically excluded.  COM type files are only infected if they are
  less than 62856 bytes in length, and once infected they take no
  further part in the virus operation or replication processes.  Thus
  when an infected COM file is run, the virus code is decrypted and
  the first few instructions are executed to repair the file header.
  However, processing then returns directly to the host program
  regardless of whether the virus has been installed or not.  This
  infection of COM files with totally ineffective code appears to be
  deliberate and may indicate an intention to add "improvements" at a
  later date.

  When an infected EXE file is executed, a special "are you there?"
  call is issued to determine whether the virus code is resident and
  active in memory.  If the virus code responds, program execution is
  transferred to the host program and no further virus code is
  executed.  The special call consists of placing 0FE01H into the AX
  register and issuing an INT 21H request.  If the virus is resident,
  the AX register will contain 01EFH when the interrupt returns.  If
  the virus is not resident, a check is made to ensure that enough
  memory is available for the virus to be installed and then the BIOS
  top of memory pointer is modified before the virus code is installed
  into high memory.  This method therefore avoids using any of the
  system TSR services.  Once the code is relocated, the MBR of the
  first physical fixed disk is checked to see if it is infected.  This
  check consists of examining the word at offset 28H in the MBR (Track
  0, Head 0, Sector 1) for a value of 01FEH.  If the MBR is NOT
  infected, the partition table is searched for the first partition of
  type 1,4 or 6 - these are standard partition types and on most
  machines the first (possibly only) partition will be type 4 (DOS -
  16 bit FAT).  Once found, the settings of this partition are checked
  to ensure that infection is possible and then modified to allow
  hidden storage of the virus code.  Most boot sector viruses hide
  their additional code in available sectors on the hard disk and then
  mark them as "bad" so that DOS will not use them.  This virus adopts
  a different technique - within the partition table there are
  pointers to the physical limits of each partition.  These indicate
  the absolute track, head and sector addresses of the start and end
  of each partition.  This virus subtracts 6 from the value of the
  sector address which points to the end of the partition.  This
  effectively reduces the size of that logical drive by 6 sectors
  (around 3 Kilobytes) and leaves 6 sectors "in limbo" beyond the end
  of drive.  The first of these sectors is used to contain an
  uninfected copy of the MBR (but still with the modified partition
  table) and the remaining five will contain the virus code. The
  original MBR is then infected and written back to the disk.  The
  final stage of this section is to hook the virus's own INT 21H
  handler into the system and then processing returns to the host
  program.  A system infected by execution of an EXE file will not
  display the trigger effect even if the appropriate video adapter is
  available and the date and time are right.  This is because an
  inhibit flag is set which can only be cleared when the machine is
  booted on the correct date.

  The boot sequence on a machine with an infected hard disk proceeds
  as follows :- After the normal initialisation of the Stack Segment
  and Stack Pointer registers, the BIOS top of memory pointer is
  modified to allow 3 Kilobytes of space above available memory.  The
  virus code is then read from the disk by reference to the partition
  end address and using the BIOS INT 13H service.  Processing then
  transfers into the Hi-Mem copy of the code and continues by loading
  the "clean" copy of the MBR into the boot area at 7C00H.  The
  attached video facilities are then checked using BIOS INT 10H and if
  EGA/VGA capabilities are found the system date is checked to find
  the day number.  If the date is the second of any month, then the
  inhibit flag is cleared and a further 4 Kilobytes of high memory are
  allocated.  This area is then filled with a bit-reversion copy of
  the EGA character set and the appropriate access pointers are
  prepared.  If the video adapter or the date fail the checks then
  these routines are not executed and the inhibit flag is set before
  processing jumps to the final installation stage.  This involves
  hooking in interrupt handling routines for INT 1CH, INT 21H and INT
  9FH.  The INT 21H vector is uninitialised at cold boot time but the
  intention at this stage is to insert the virus's handler address and
  collect the existing contents for comparison within the INT 1CH
  (Clock Tick) handler.  The INT 9FH vector is a user defined
  interrupt and the handler is not used by the virus code, this will
  be discussed later.  Boot processing is then transferred to the
  "clean" MBR at 7C00H.  All of the boot sector viruses that I have
  examined so far gain processing time by hooking their own handler
  into the BIOS services (usually INT 13H - disk access) since DOS
  services.  This virus hooks into DOS services even though they do
  not exist at boot time. It uses the INT 1CH service to gain initial
  processing time and thereafter swaps its attentions once the system
  INT 21H service is detected as having been installed.

  One of the most worrying aspects of this virus is its use of an
  interrupt "strip" mechanism which can examine the relevant chain of
  vectors and select out all those installed after the system has
  loaded.  This stripping process makes use of the DOS single step
  interrupt facility whereby execution of the routine pointed to by
  the INT 01 vector is forced by the hardware after EVERY program
  instruction if a particular flag (the TRAP flag) is set.  Thus
  throughout the chain of probably several thousand instructions
  within an interrupt service, the single step handling routine can
  examine the state of the processor registers (particularly the code
  segment register via the return address on the stack) on a
  continuous basis.  This facility is used to telling effect in this
  case by allowing the virus code to use unmonitored services and
  thereby gain access to the system "underneath" any resident
  anti-virus software.  The extreme reduction in speed that would
  result from the execution of all these extra system calls is avoided
  by having the single step routine turn itself off once the original
  system service vector has been located.  It is not difficult to
  produce resident anti-virus software which is immune to this sort of
  subversion but I suspect that there are few, if any, packages which
  currently do this.

  Another disturbing feature of this particular virus is its targeting
  of a specific section of the COMMAND.COM file in the following
  manner :-

  During the boot infection process a flag is set and then cleared to
  indicate the correct completion of the virus write routine.  If this
  flag is not cleared, the virus still continues to function but now
  includes an extra routine which checks the contents of the target
  file for a highly individual pattern.  If this pattern is found, at
  the point in the file where it occurs, two bytes are inserted which
  will become an INT 9FH instruction when the file code is executed.
  INT 9FH is one of the interrupt vectors provided by DOS for user
  definition and in this case the virus will already have installed
  and activated such a routine.  The insertion of these two bytes is
  in addition to the subsequent execution of the normal parasitic
  infection routine.  The INT 9FH routine, executed when the affected
  file runs, accesses the program's code and data areas by looking
  back along the stack.  Various changes are made including the
  testing of a data item for the value 1FH - which happens to be the
  file time infection marker used by this virus.  Other data is
  modified by having the length of the virus subtracted from it.  This
  effectively causes DOS (via COMMAND.COM) to report the wrong file
  length whenever an infected file is accessed.

  The search routine is as follows:-

  SEARCH:  CMP WORD PTR [DI],168BH JNE NOTFOUND CMP WORD PTR [DI +
  4],1689H JNE NOTFOUND CMP WORD PTR [DI + 8],168BH JNE NOTFOUND CMP
  WORD PTR [DI + 0CH],1689H JNE NOTFOUND ........  ........  ........
  ........  NOTFOUND:  INC DI CMP DI,SI JB SEARCH

  This is started after the program has been loaded into a buffer and
  with SI containing the full length of the program and DI containing
  zero.  This pattern is consistent with a program listing as follows
  :-

         MOV       DX,[Dat1]
         MOV       BX,[BX + DI]
         DB        ?,?
         MOV       DX,[Dat2]
         MOV       BX,[BX + DI]

  where the two memory locations Dat1 and Dat2 are unknown and the two
  bytes noted with question marks are also unknown.

  Summing up the various properties of this virus: both COM and EXE
  files are infected.  Running an infected EXE file will install the
  virus into memory and attempt to write the MBR (boot) infection to
  the first hard disk.  No trigger will occur even if the date and
  time are correct, since the system date is only checked during the
  infected boot process.  Thus only machines with a battery clock (as
  well as EGA/VGA facilities) will be able to display the trigger
  effect.  The installed virus however IS capable of infecting other
  files.

  Booting a machine with an infected fixed disk will install the virus
  and will display the trigger effect between 16:00 and 16:59 on the
  2nd of every month.  The virus code installed via the boot routine
  is exactly the same as that introduced by EXE parasitic action and
  the boot infection only infects the first hard drive.  This means
  that although this virus has composite features, it can only spread
  from machine to machine via infected files.  The infected MBR
  contains the first 66 bytes of the virus code in unencrypted form
  and the following sequence of bytes at offset 2EH into the Master
  Boot Record will identify an infected drive :-

   33 DB 33 FF 8E C3 26 29 06 13 04 CD 12 B1 06 D3

  The infective length of this virus is 2,343 bytes for both EXE and
  COM files and infected files are marked by having the time field of
  their directory entry set at 1FH (= 62 seconds).

  This code represents the first of a new level of viruses which have
  multiple facets of their operation and can target existing
  anti-virus software.  Fortunately it is no more difficult to detect
  than most other viruses and slight modification to resident virus
  monitoring programs will make them immune to the "interrupt
  stripping" technique.

  The amount of wasted time which has gone into writing this virus is
  quite phenomenal and the programmer displays considerable experience
  in certain sections of the code.  After disassembling virus code I
  am always tempted to speculate about the author and in this case I
  particularly I wonder if some large organisation has underworked
  programmers who are using company time to write these criminal
  programs.  I also wonder how many large organisations actually check
  just what their programmers are up to. If I discovered ANY
  professional programmer developing virus code I would do my utmost
  to ensure that he never worked on computers again.  This sort of
  irresponsibility MUST be stamped out before irreparable damage is
  done to our industry.

  VIS Classification - BfmCcEARKSd2343A

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