[comp.virus] The aftermath of Ogre/Disk Killer

swimmer@infohh.rmi.de (Morton Swimmer) (07/17/90)

The aftermath of Ogre/Disk Killer

     It was  mentioned by  me and others that the damage done by Ogre/Disk
Killer can  be repaired.  Unfortunately we  were wrong.  The  virus  plows
through the  disk, encrypting  every track  as it  goes. As the encryption
method used is reversable, I assumed that it would be no problem to create
a routine  to restore  the disk.  I made  the mistake of assuming that the
routine the  virus-programmer used  was flawless. Well, it wasn't. In fact
it containes  at least  three major  mistakes, that  make it impossible to
restore an encrypted disk automatically.
     The virus  saves the  original Master-Boot-Sector (MBS) on the second
absolute sector,  irrespective of what was originally there. My experience
is that  more hard  disks do  not use  that sector,  but can one guarantee
this? On  floppies this  sector IS  used by  the FAT,  so floppies  can be
excluded from  restoration right from the start. After the encryption, the
first absolute  sector is  replaced by a sector containing the data needed
to restore  the hard disk. This is where the first major mistake lies: the
programmer forgot  to save  the number of heads the hard disk has. This is
not that serious though, as one usually knows how many heads the disk has.
I used another trick: my program decrypts the MBS in sector 2 and uses the
number of heads stored there. The virus itself uses the number of heads as
stored in  the bootsector.  There might  be some  outlandish  partitioning
where the  actual  number  of  heads  differs  from  that  stored  in  the
bootsector.
     As the first sector is overwritten after encryption, some information
is lost  that is  needed to  decrypt the  MBS in sector 2. It is possible,
using a trick, to decrypt everything except the first two bytes.
     The virus  records whether an error occured while encrypting a track.
It does this by setting a bit corrosponding to the track in a table stored
in sector  1. Due  to a  programming error,  the routine  to calculate the
index of  the bit  in the  table will cause a division by zero error after
800h/(number of  heads) tracks  (eg. 341  on a disk with 6 heads). Because
the virus does not handle this eventuality, the routine will abort and all
of the information that is necessary for restoration and usually stored in
sector 1 will not be written: ie. the disk is in an unknown state. This is
the second major mistake.
     So far  the errors can be circumvented by manually selecting the disk
parameters and  the sectors to be restored. The last error I found, dashed
all my  hopes of  restoring the  disk in question. While moving the MBS to
sector 2,  the programmer  made the mistake of assuming that BIOS restores
the contents of the AL register on return from a read. It usually doesn't,
although the programmer's machine must have. My BIOS returns a zero in AL.
When the  virus executes a write to disk without resetting the AL register
to one,  unpredictable things  happen. The virus has affectively told BIOS
to write  zero sectors  to disk.  What happened on my machine was that the
FAT and  the ROOT directory were overwritten with junk. This left the disk
quite unusable. :-(
     After encrypting what one can on the disk, it is possible to use disk
utilities to  access the  data on a sector-to-sector basis, but not in any
sensible manner.  I expect  that for  some people even this is better than
losing their  data completely.  The encryption  process should  be left to
experts, as it is risky and you only have one shot. I have done this for a
customer before, but unfortunately all three errors had occured and little
could be saved. (One of Murphy's Laws had something about this...*sigh*.)
     I expect  the programmer of the virus had an strange BIOS version and
a small  hard disk.  Under those  circumstances the  errors would not have
occured in  testing. I doubt if these mistakes were intentional. There are
cheaper ways of destroying a disk.
     This virus gives me yet another good opportunity for my usual pitter-
patter: Back  up your  disks REGULARLY;  back up  DATA, not programs; keep
original program disks WRITE-PROTECTED in a safe (from yourself) place; do
not rely entirely on antiviruses, but rather on your COMMON SENSE and STAY
CLEAN. This  goes for  all viruses and for other mishaps. (A cup of coffee
is still a computer's worst enemy.)

Cheers, Morton
Virus Test Center, University of Hamburg, West Germany