INT13 Virus

 

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

             ***   Reports collected and collated by   ***

             ***            PC-Virus Index             ***

             ***      with full acknowledgements       ***

             ***            to the authors             ***

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

  Report from Jim Bates - The Virus Information Service - 18th

  February 1991

  === INT13 Virus ===

  Most examples of virus code display a sad lack of real programming

  skill in addition to the infantile trigger routines and messages

  that they carry.  However, every once in a while, a virus appears

  which shows undoubted expertise on the part of the author and it is

  difficult to decide who is lower on the scale - the childishly

  inadequate people who cobble together destructive code for their own

  twisted reasons, or the experienced programmers who are prepared to

  misuse their skill in damaging their own industry.  One could argue

  that at least we might try to educate the "pimplies", but there is

  absolutely no excuse for the experts and they should be identified

  and thrown out of the industry!  It is no use their claiming that a

  particular virus was written for "research" purposes, every virus

  will cause some disruption and possible damage if it is allowed to

  infect a PC environment unhindered.

  One of the most highly sophisticated samples of virus code arrived

  recently in a package of examples from Eastern Europe.  The virus

  has been called INT13 after a plain text string at the end of the

  code and it contains a stealth capability which will avoid detection

  by all except the most determined scanning programs.  The total code

  is only 512 bytes in length and there is no trigger routine in the

  sample that I analysed (although file corruption will occur under

  certain circumstances - see report below).  A simple, uncommented

  disassembly listing was also included in the package but examination

  of this was inconclusive in determining whether it was the author's

  original source or an unknown researcher's primary efforts at

  disassembly.  The virus is categorised as infecting only COM files

  of certain lengths and bears some remarkable similarities to the

  Number of the Beast (666) virus already discussed (VB-May 1990).  No

  change occurs in the file length, attribute settings or date/time

  fields and the COMMAND.COM file is specifically excluded from

  infection.

  INSTALLATION

  This virus overwrites the first 512 bytes of its target program file

  and the code therefore initially appears at offset 100H of the

  program code segment.  The very first instruction is a two-byte LOOP

  Next command which is the hex word E200H.  This is used later by the

  virus in a number of ways as an infection indicator.  After this

  first instruction (which achieves nothing), the normal machine

  interrupt vectors for INT 13H and INT 21H are collected by direct

  access to the interrupt table and copies are stored in the entries

  for INT 9CH and INT 9EH respectively.  An undocumented function of

  DOS is then used to collect the ROM entry point of the INT 13H

  routine and this address is copied into the INT 9DH vector.  The

  address of the first DOS Disk Buffer is then obtained and the virus

  code (all 512 bytes) are copied into it.  The chain of buffer

  addresses is then update to remove this first buffer from subsequent

  DOS operations.  Up to this point, no revectoring of the original

  interrupts has occurred.  This first section of the program then

  pushes the relevant segment and offset addresses onto the stack and

  issues a RETF instruction to transfer processing into the relocated

  code in memory.

  The continuation code starts by accessing low memory and revectoring

  (by direct access) the interrupt addresses for INT 13H and INT21H to

  handlers present within the virus code.  Then the environment

  segment address is collected from within the host program's PSP and

  the host program is loaded into memory in exactly the same place as

  it was previously.  This might seem a pointless exercise but as the

  operation of the INT 13H handler becomes apparent, it will be seen

  that this second load of the host program will produce a correct

  (ie: uninfected) copy of the original program file in memory.  Once

  loaded, the host program is executed under normal DOS control.

  RESIDENT OPERATION

  The operation of the virus interrupt handlers is somewhat involved

  and displays an intimate knowledge of how DOS handles requests for

  file information.  Is is difficult to describe the functions of the

  handlers separately since they operate together, so this analysis

  will describe the sequence of events after both handlers have been

  installed and cover particular aspects of each as they occur.  It

  should first be noted that the virus contains a third interrupt

  handler which is temporarily hooked into the INT 13H vector whenever

  the infection routine is processed.  It is this temporary handler

  which provides the key to the low-level subversion that this virus

  creates.  Starting with the infection routine, the INT 21H handler

  intercepts only function 12H (FCB FIND NEXT).  The requested

  function is first issued through the newly created INT 9EH (original

  INT 21H) call. This is then checked for error free completion and

  the virus then accesses the Disk Transfer area to examine the

  filename which was found.  If the last two letters of the file

  extension are 'OM' and the second and third letters of the name are

  NOT 'OM' then size checks are initiated.  Otherwise the handler

  aborts and returns control to the caller.  The size checks consist

  of first rejecting any files less than 512 bytes in length, and then

  testing bits 5 and 6 of the file size field for zero.  This is an

  effective method of determining how much allocated space is

  available beyond the end of the file (in a similar way to the 666

  virus).  Provision is also made for the difference in allocation

  unit size between fixed disks and floppy disks although no actual

  checks are made to determine the TRUE allocation unit size.  If

  examination of the file size field reveals that there is at least

  one sector available beyond the end of the file, it is accepted for

  infection.

  It is at this point that the temporary INT 13H handler is hooked

  into the interrupt chain, by-passing the main INT 13H handler.  The

  existing INT 13H vector is stored (but not used) into the INT 9FH

  address in the interrupt table.  The target file is then opened for

  READ ONLY access using the original DOS INT 21H vector and a seek to

  End of File instruction is issued with an offset of -1.  This

  effectively seeks to the last byte in the file and this is where the

  temporary INT 13H handler is invoked.  During a disk access call to

  INT 21H, DOS will call INT 13H a number of times as information is

  required from the disk.  During the SEEK to EOF function, the final

  call to INT 13H will contain the logical Drive, Track, Head and

  Sector address of the last cluster of the file.  THe temporary INT

  13H handler does nothing more than store these address variables

  into data areas within the virus code and then continue with the

  original (ie: unintercepted) INT 13H.  So these data areas now

  contain the low-level address of the last cluster of the file and

  they are accessed and stored on the stack.  Next, the virus issues a

  SEEK to Beginning of File instruction and then uses the DOS INT 21H

  address to read the first word of the file.  This word is checked to

  see if it is the virus ID word E200H and if it is, the handler

  aborts (after first unhooking the temporary INT 13H vector).  When

  DOS INT 21H is asked to read from a file, the whole of the relevant

  allocation unit is read into the DOS disk buffer.  Thus the single

  word read call both collected the first cluster AND set the address

  of that cluster into the temporary INT 13H variables.  The first

  word of the file is also checked to see if it is "MZ", indicating a

  fake COM file with an EXE header.  The check does NOT include the

  less usual "ZM" header signature.  Files with a "MZ" header are not

  infected.

  Now the last cluster address variables are popped off the stack and

  used to address a READ SECTORS request to the ROM entry point of the

  INT 13H BIOS routines.  This biopsies the temporary handler and

  thereby does not update the address variables.  These two sectors

  are read into a buffer created in the middle portion (offset 7800H)

  of the video memory area at segment B800H.  So we now have the first

  sector of the file in the DOS Disk Buffer and the last sector (plus

  the subsequent sector of unused but allocated space) in the

  temporary buffer in video memory.  The complete virus code

  (containing the temporary INT 13H data variables, pointing to the

  last cluster) is now written to the first sector of the file using

  the unintercepted INT 13H vector, thus overwriting the first 512

  bytes of the file.  Then the original first sector of the file is

  copied to the second of the two sectors stored in video memory and

  these two sectors are written back to their original position.  The

  target file is now fully infected - with the virus code in the first

  512 bytes, and the original first sector stored beyond the end of

  the file.  Finally, the target file is closed, the temporary INT 13H

  handler is unhooked from the system and the original register

  settings are restored before processing returns to the original

  caller.

  We must now consider the operation of the main INT 13H intercept

  routine as it functions within the DOS scheme of operations.  When a

  COM file is loaded prior to being executed, the DOS INT 21H handler

  will call upon the installed INT 13H vector for information and

  data.  At some point, the first cluster of the file will be loaded

  into the disk buffers before being moved to the caller's load

  buffer.  This virus' INT 13H handler will examine each sector load

  to see if it starts with the E200H virus ID word.  If this is not

  found, the handler immediately returns to the calling routine.

  Otherwise, the address data variables are collected and used to read

  the last two sectors of the file (using Track, Head and Sector

  addressing into the ROM entry point of the INT 13H BIOS routines).

  The second sector (the original program header) is then copied into

  the original caller's buffer before processing returns.  It can thus

  be seen that once the virus intercepts have been installed, any

  infected file loaded into memory using normal DOS function calls (or

  even normal BIOS calls) will result in a CLEAN file being loaded.

  CONCLUSIONS

  This complex method of replacing the original file header by

  subverting the BIOS access routines produces some interesting

  results which directly affect the virulence of the infection.  When

  an infected file is copied on a system with the virus resident in

  memory, the resulting file is uninfected and may only be re-infected

  during a DOS FCB FIND NEXT function request.  However, since this

  virus does not infect COMMAND.COM and different implementations of

  DOS (with different sized system files) may not allow system

  infection. It is quite probable that a power down reboot will leave

  a machine uninfected.  This becomes more likely when one considers

  that only files with certain size limitations can be infected.  So,

  the effect of copying infected files on an uninfected machine will

  vary depending upon the copying methods used.  Some implementations

  of DOS will copy on a sector by sector basis and these will produce

  an infected (ie:  overwritten) file which does not contain the

  original program header within the free space beyond its end.  Such

  files will be irreparably damaged.  Other versions copy on a cluster

  by cluster basis and these will produce a correctly (?) infected

  file with all the requisite information intact.

  Other problems of a less predictable nature will occur as a result

  of several shortcomings in the virus code.  Firstly, the absence of

  a check for the "ZM" header may occasionally cause this virus to try

  to infect a fake COM file.  Since the virus uses a simple load to

  re-execute the program code at offset 100H this will cause

  unpredictable effects.  Secondly, the use of video memory as a

  buffer could cause display problems on packages which would normally

  used the 1024 bytes stolen by the virus as a temporary buffer.

  Screen corruption would probably be the only effect here although

  this is only speculative.  Finally, the INT 13H intercept which

  prevents the correct loading of any sector which begins with E200H

  will cause problems if this particular byte sequence is encountered

  within a file as a normal part of the file's contents (remembering

  that this could be data or a split instruction across a sector

  boundary).  Admittedly these conditions may be rare but there is no

  doubt that problems WILL occur when they are met.  The removal of

  one of the DOS Disk Buffers from service may also cause slight

  performance degradation for tightly configured file intensive

  applications.

  SUMMARY

  The INT 13 virus is an overwriting stealth virus which subverts both

  DOS and BIOS in concealing its whereabouts on disk.  The code length

  is 512 bytes although this is NOT added to the observed file length.

  Infection only takes place on selected COM files and only during the

  FCB FIND NEXT function call.  The virus does not encrypt, either on

  the disk or in memory and so a reliable search string has been

  extracted as follows :-

         E200 50BF 4C00 5733 ED8E DDC4 1DBF 7402

  and this will be found at offset 0 in infected files ONLY IN THE

  VIRUS IS NOT RESIDENT!

  Disinfection of infected files is possible with this strain but only

  if special software is produced to accomplish it.

  VIS Classification - CORSdb512A

  COMMENTS

  I shall never understand why people write computer viruses, it is

  just technological vandalism which causes inconvenience and loss.

  It may be argued that the perpetrators are ill-mannered,

  ill-educated, mentally deficient malcontents and I would certainly

  not disagree.  However, it is immensely saddening to come across a

  virus which has obviously been written with considerable expertise.

  It's like finding a skilled musician who instead of making music,

  suddenly decides to smash not only his own instrument, but those of

  all the other players too.  Such people are renegades, they must be

  found and stopped before they create more corruption.

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

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