FLIP Virus

 

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

             ***   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 +44 (0)533 883490

  Jim Bates

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

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

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