home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / 40hex_6.00b < prev    next >
Text File  |  1995-01-03  |  8KB  |  149 lines
  1. 40Hex Number 6 Volume 2 Issue 2                                       File 00B
  2.  
  3.                         ------------------------------
  4.                          SCAN STRINGS, HOW THEY WORK,
  5.                              AND HOW TO AVOID THEM
  6.                         ------------------------------
  7.                                  By Dark Angel
  8.                         ------------------------------
  9.   
  10.   Scan strings  are the  scourge of  the virus author and the friend of anti-
  11.   virus wanna-bes.   The  virus author  must find encryption techniques which
  12.   can successfully  evade easy detection.  This article will show you several
  13.   such techniques.
  14.   
  15.   Scan strings,  as you  are well  aware, are  a collection of bytes which an
  16.   anti-viral product  uses to  identify a virus.  The important thing to keep
  17.   in mind  is that  these scan  strings represent  actual code  and can NEVER
  18.   contain code  which could occur in a "normal" program.  The trick is to use
  19.   this to your advantage.
  20.   
  21.   When a  scanner checks  a file for a virus, it searches for the scan string
  22.   which could  be located  ANYWHERE IN  THE FILE.   The  scanner doesn't care
  23.   where it  is.   Thus, a  file which  consists solely of the scan string and
  24.   nothing else  would be  detected as  infected by  a virus.   A  scanner  is
  25.   basically  an   overblown  "hex  searcher"  looking  for  1000  signatures.
  26.   Interesting, but  there's not  much you  can do  to exploit this.  The only
  27.   thing you  can do  is to  write code so generic that it could be located in
  28.   any program  (by chance).   Try  creating a  file with  the following debug
  29.   script and  scanning it.   This  demonstrates the fact that the scan string
  30.   may be located at any position in the file.
  31.   
  32.   ---------------------------------------------------------------------------
  33.   
  34.   n marauder.com
  35.   e 0100  E8 00 00 5E 81 EE 0E 01 E8 05 00 E9
  36.   
  37.   rcx
  38.   000C
  39.   w
  40.   q
  41.   
  42.   ---------------------------------------------------------------------------
  43.   
  44.   Although scanners  normally search  for decryption/encryption  routines, in
  45.   Marauder's case,  SCAN looks  for the  "setup" portion  of the  code,  i.e.
  46.   setting up  BP (to the "delta offset"), calling the decryption routine, and
  47.   finally jumping to program code.
  48.   
  49.   What you  CAN do  is to  either minimise  the scannable code or to have the
  50.   code constantly  mutate into  something different.  The reasons are readily
  51.   apparent.
  52.   
  53.   The simplest  technique is  having multiple  encryption engines.   A  virus
  54.   utilising this  technique has  a database  of encryption/decryption engines
  55.   and uses  a random  one each  time it infects.  For example, there could be
  56.   various forms  of XOR  encryption or  perhaps another  form of mathematical
  57.   encryption.   The trick  is to  simply replace  the code for the encryption
  58.   routine each time with the new encryption routine.
  59.   
  60.   Mark Washburn  used this  in his  V2PX series of virii.  In it, he used six
  61.   different  encryption/decryption   algorithms,  and   some  mutations   are
  62.   impossible to detect with a mere scan string.  More on those later.
  63.   
  64.   Recently, there  has been  talk of  the so-called  MTE, or mutating engine,
  65.   from Bulgaria  (where else?).   It  utilises the multiple encryption engine
  66.   technique.   Pogue Mahone  used the  MTE and it took McAfee several days to
  67.   find a  scan string.   Vesselin  Bontchev, the McAfee-wanna-be of Bulgaria,
  68.   marvelled the engineering of this engine.  It is distributed as an OBJ file
  69.   designed to  be able to be linked into any virus.  Supposedly, SCANV89 will
  70.   be able to detect any virus using the encryption engine, so it is worthless
  71.   except for  those who  have an  academic interest  in such matters (such as
  72.   virus authors).
  73.   
  74.   However,  there   is  a  serious  limitation  to  the  multiple  encryption
  75.   technique, namely  that scan  strings may  still be  found.   However, scan
  76.   strings must  be isolated  for each  different encryption  mechanism.    An
  77.   additional  benefit   is  the   possibility  that  the  antivirus  software
  78.   developers will  miss some  of the  encryption mechanisms  so not  all  the
  79.   strains of the virus will be caught by the scanner.
  80.   
  81.   Now we  get to  a much better (and sort of obvious) method: minimising scan
  82.   code length.   There are several viable techniques which may be used, but I
  83.   shall discuss but three of them.
  84.   
  85.   The one  mentioned before which Mark Washburn used in V2P6 was interesting.
  86.   He first  filled the  space to  be filled  in with the encryption mechanism
  87.   with dummy  one byte  op-codes such  as CLC, STC, etc.  As you can see, the
  88.   flag manipulation  op-codes were  exploited.   Next, he randomly placed the
  89.   parts of  his encryption  mechanism in  parts of this buffer, i.e. the gaps
  90.   between the  "real" instructions were filled in with random dummy op-codes.
  91.   In this manner, no generic scan string could be located for this encryption
  92.   mechanism of  this virus.   However, the disadvantage of this method is the
  93.   sheer size of the code necessary to perform the encryption.
  94.   
  95.   A second  method is  much simpler than this and possibly just as effective.
  96.   To minimise scan code length, all you have to do is change certain bytes at
  97.   various intervals.   The  best way  to do  this can  be explained  with the
  98.   following code fragment:
  99.   
  100.     mov si, 1234h                     ; Starting location of encryption
  101.     mov cx, 1234h                     ; Virus size / 2 + variable number
  102.   loop_thing:
  103.     xor word ptr cs:[si], 1234h       ; Decrypt the value
  104.     add si, 2
  105.     loop loop_thing
  106.   
  107.   In this code fragment, all the values which can be changed are set to 1234h
  108.   for the  sake of  clarity.   Upon infection,  all you  have to do is to set
  109.   these variable  values to  whatever is  appropriate  for  the  file.    For
  110.   example, mov  bx, 1234h  would have  to be  changed to  have the encryption
  111.   start at the wherever the virus would be loaded into memory (huh?).  Ponder
  112.   this for  a few  moments and  all shall  become clear.   To  substitute new
  113.   values into the code, all you have to do is something akin to:
  114.   
  115.     mov [bp+scratch+1], cx
  116.   
  117.   Where scratch is an instruction.  The exact value to add to scratch depends
  118.   on the  coding of  the op-code.   Some  op-codes take their argument as the
  119.   second byte,  others take  the  third.    Regardless,  it  will  take  some
  120.   tinkering before it is perfect.  In the above case, the "permanent" code is
  121.   limited to  under five or six bytes.  Additionally, these five or six bytes
  122.   could theoretically  occur in  ANY PROGRAM  WHATSOEVER, so  it would not be
  123.   prudent for  scanners to search for these strings.  However, scanners often
  124.   use scan  strings with wild-card-ish scan string characters, so it is still
  125.   possible for a scan string to be found.
  126.   
  127.   The important  thing to  keep in  mind when using this method is that it is
  128.   best for  the virus  to use separate encryption and decryption engines.  In
  129.   this manner, shorter decryption routines may be found and thus shorter scan
  130.   strings will  be needed.   In  any  case,  using  separate  encryption  and
  131.   decryption engines increases the size of the code by at most 50 bytes.
  132.   
  133.   The last method detailed is theft of decryption engines.  Several shareware
  134.   products utilise  decryption engines  in their  programs to  prevent simple
  135.   "cracks" of  their products.   This  is, of  course, not a deterrent to any
  136.   programmer worth  his salt,  but it  is useful  for virus  authors.  If you
  137.   combine the  method above  with  this  technique,  the  scan  string  would
  138.   identify the  product as  being infected with the virus, which is a) bad PR
  139.   for the company and b) unsuitable for use as a scan string.  This technique
  140.   requires virtually  no effort,  as the decryption engine is already written
  141.   for you by some unsuspecting PD programmer.
  142.   
  143.   All the  methods described  are viable  scan  string  avoidance  techniques
  144.   suitable for  use in  any virus.   After  a few practice tries, scan string
  145.   avoidance should  become  second  nature  and  will  help  tremendously  in
  146.   prolonging the effective life of your virus in the wild.
  147.  
  148. Downloaded From P-80 International Information Systems 304-744-2253
  149.