Win32 Bait Detection
 by SnakeByte [ SnakeByte@kryptocrew.de ]


 
 After writing my first polymorphic win32 virus, i noticed that my
 only check for baits consisted in checking for the size, so i decided
 to see what else we can check in win32 environment to see if we got
 a goat file. ( For those who don't know, a goat or bait file is a
 file the AV'ers use to detect all possible combinations of a polymorphic
 virus ) When I list some ideas on defeating goats here, i don't say "use them all !"
 Better is, you use two or three of them in your virus, because otherwise the 
 virus might be overblown with anti goat tricks, and will not find any
 real file he wants to infect, because every one of these checks will also
 have false negatives and false positives..

  1.) Size
  2.) Imported API's
  3.) Used DLL's
  4.) Data Size
  5.) Code Size
  6.) Ressources
  7.) Repeating Stuff
  8.) Misc



 1.) Size
 
  Of course, this is the most simple thing we can check for. In win32
  environment, the size of a file should be at least 30 or 40 KB. 
  I got on my harddrive just 2 dozen of files which are smaller than 40 KB,
  and these are mainly my own asm projects or those "hax0r" tools delivered
  with various mIRC Scripts. If they generate just 10000 goats, with more
  than 40 KB, they need 390 MB, not much when you take a look at nowaday
  harddrives, but it will cost them some time to generate them ;)


 2.) Imported API'S

  When I took a look at the PE Example delivered with RoseGoat, I noticed
  that the file has just 2 imported API's : MessageBoxA and ExitProcess.
  A normal file with some windows has around 20 imported API's, if you add some extra
  stuff, there are around 30. You should check if the file imports at least 30
  API's, if not it is a bait. Just look up the number of imported API's on
  the Import Table


 3.) Used DLL's

  Ok, a file uses at least the imports of one DLL : Kernel32.dll *g*
  But when you take a look at some others, you see, that they use 5 or more DLL's.
  Except for those Visual Basic generated Files, they often just use the 
  VB40032.dll or one of those other runtimes, if the author is bad and does
  not also use the Kernel32.dll API's. So check if there are less than 5 DLL's used, if
  one of those starts with VB, then it is normally no goat, but a badly coded VB
  Programm.


 4.) Data Size

  Check for the size of initialized Data in the Optional Header. The Rose Bait has
  here just 1500 Bytes, a typical program, wheter VB or not, around 12000 Bytes !
  So we can take this as another identifier for baits. Look for this value at offset
  20h of the PE Header, which could be easily done ;)


 5.) Code Size

  We should also check the "Size of Code Section" in the optional Header,
  a bait just has a low value here ( sure, it has not much code ;) ) but a
  normal file has 5000 and more. This value can be found at offset 2Ch of
  the PE Header, so it is easy to check too.


 6.) Ressources

  Every normal file uses Ressources, like Pictures, Icons and such things.
  If we find none, we should not infect the file, because just a gout file
  has no icon ;) To check this we need to locate the .rdata Sektion and check
  for it's size inside the section table. I think 800h Bytes is a minimum for
  a normal file ( thats about 1 Icon )


 7.) Repeating Stuff

  When a goat file generator generates baits, they often have exactly the same
  size, so check if the current file has the same size as the last one, if this
  is the cause, then don't infect it. Filenames might also follow a pattern, when
  generated with a generator. This is the same as in DOS, they either have names
  like Goat0001.exe, Goat0002.exe.. or 0001Goat.exe, 0002Goat.exe..
  I would say the best method to avoid such files is to check the first and 
  the last digit of the filename ( without extension ). If they are equal or
  just differ in one Bit, then they should not be infected.
  But some goat generators are able to generate baits with different sizes and
  random filenames, what to do against them ? One thing which will repeat, are
  the first bytes of the code, because they just change the size and data. But checking
  for this would be really hard, because a lot of high level compilers have several
  routines, which get started before the programmers stuff get executed. If you store
  the first 100 Bytes in Memory, you would also detect HLL Programs as baits. So
  my solution is to read 2000-3000 Bytes of the code section and generate a checksum
  over this part, then you don't need to store a lot of data ( But make sure the CRC
  is a fast one *g* )


 8.) Misc

  Some might say, all these anti goat tricks are useless, because the AV'er will
  just NOP them out or write his own replication routine for the virus, which
  will not have these tricks, but the same poly engine. Sure, this would be 
  bad for us, but what if we generate a checksum over the entire virus code and
  use it as a main basis number for the random number generator ? Then the AV'er has
  to fear, that his routine ( or the virus with nopped out tricks ) will generate other
  variants like your virus and his scanengine might miss some of your viruses. 
  So just choose some of these tricks, they don't need that many bytes and i think
  they will be an effort for your virus.