Virus Labs & Distribution
VLAD #6 - Win95 Intro

 Introducing Windows 95 by Quantum / VLAD

  When VLAD started working on the Win95 problem (back when WinSurfer was
  released), all we had to work with was the win32s update to win3.1 that
  allowed win3.1 users to run (not very successfully) 32 bit win95/NT
  applications.  Tracing through the code one day we noticed that every
  exe started with loading the PE header with eax pointing to it and
  jumping to the entrypoint (jmp [eax + 28h]).  So we changed the
  entrypoint RVA to point to our code, pushed eax, did our code, popped
  eax, and jumped to [eax + 28].  It worked, we had a win32s infector,
  then we noticed we didn't actually have any way to infect.  There were
  no ints and we really felt out of our depth and then to top it all off
  we came across the ultimate way to go resident without infecting the
  win3.1 shell and so PH33R was born.  About this time I left the scene
  in an unexplainable burst of insane "oh my god I'm going to fail uni"
  panic and that was about the end of the win32s/95/NT project.

  Just recently, uni ended.  I was on holidays, bored out of my skull,
  and running win95, so I decided I'd give it another go.  To my surprise
  the jmp [eax + 28] was gone, it was just a byproduct of win32s.  Instead
  I just calculated the distance between the end of the exe and the
  entrypoint, calculated the start of the virus code and subtracted the
  two.  It worked, I had a win95/NT infector.  That is, 'cept for a little
  matter of calling API...

  The Day the World Changed

  In the beginning there were memory locations and we manipulated what
  our computer did by peeking and poking.  And it was good.  But this
  was not to last, for on the horizon was the "port" and slowly we
  learnt to communicate with attached devices by puting values in, and
  pulling values out, of specific ports.

  After a while the computer was no longer young and we needed
  something to keep things in check.  We needed a way to communicate
  indirectly with the hardware and thus the interrupt was born.  Not
  everyone liked the interrupt system but soon we all learnt to live
  with it, to manipulate it, and use it to our advantage.

  Everyone that is, except one group at Microsoft - the guys who were
  writing a "revolutionary" GUI called "Windows".  These guys were
  looking for a way to split all the functions that were once provided
  by interrupts into seperate, shared files called Dynamic Link
  Librarys (Dll's).  And so the Application Program Interface (API) was
  born.  API's made calling functions just that little bit harder and
  admittedly sometimes completely impossible.  But the guys at Microsoft
  had not yet taken away our interrupts and we still had (some) control
  over the system with DPMI.

  Then the guys at Microsoft did it again.  Their latest concoction
  eliminated interrupts and ports and yes, even memory locations.  For
  "Windows 95/NT" is a true non-preemptive multitasking system or in
  other words - a bully.  This ogre pushes programs around, squeezes
  them into confined spaces, locks them out of restricted areas and,
  worst of all, forces them into using a new, impossibly complex, method
  of calling API.

  Which brings us to...

  One drunk night at Microsoft

  When the guys at Microsoft get drunk, they truly get drunk.  But rather
  than running around with a cop's panties on their collective head and
  stealing traffic cones, they designed a new call construct.

  In the spirit of Windows 3.1, the guys at Microsoft chose against using
  interrupts.  In some ways this was good - programmers dont need to check
  to see if dll's are in memory (although they could), and they can state
  what dll's they need.  The way that Microsoft achieved this is through
  the Import and Export Tables.  The Import table lets the programmer state
  what functions they need from which dll's.  The Export table lets the
  provider of the dll specify what functions it provides.

  The problem is, once the import table has been written it is set in stone.
  There is no space to add any new entries and you cant move anything around.
  Why ?  Well, mainly because of a certain jump table that can be ANYWHERE
  in the exe.  To call an API the code calls a hardcoded address.  This
  address points to an indirect jump which points to an entry in the import
  table that is filled in (when the executable is loaded) with an address to
  a similar jump table in the dll that pushes a value and jumps to the
  function dispatcher which uses the values that are inserted in the dll's
  export table.  To add an entry to the import table you would have to
  move the current entries around so that you could fit it in.  This means
  you have to change the jump table to point to the relocated entries, which
  is impossible as the jump table can be ANYWHERE in the file and cannot be

  The New Frontier

  Windows 95 is a whole new platform.  It's a new challenge and although
  a lot of things have been stacked against you - it IS possible.  So
  get in there and start researching.  Research will be the end-all of
  the VX/AV war, one way or the other.



ARTICLE.1_2       Aims and Policies
ARTICLE.1_3       Greets
ARTICLE.1_4       Members/Joining
ARTICLE.1_5       Dist/Contact Info
ARTICLE.1_6       Hidden Area Info
ARTICLE.1_7       Coding the Mag


ARTICLE.2_2       IBM-AV
ARTICLE.2_3       MIME Disasm
ARTICLE.2_4       Dark Fiber Tunneling
ARTICLE.2_5       Bait Detection
ARTICLE.2_6       MCB Stealth


Win95 Intro
ARTICLE.3_2       Win95 tute
ARTICLE.3_3       PE header format
ARTICLE.3_4       Bizatch
ARTICLE.3_5       The Boza Situation
ARTICLE.3_6       Bizatch News
ARTICLE.3_7       What's Next ?


Virus Descriptions
ARTICLE.4_2       Gilgamesh
ARTICLE.4_3       VIP
ARTICLE.4_4       SVL 1.2
ARTICLE.4_6       nimd00d3
ARTICLE.4_7       386 Virus


CLME Disasm
ARTICLE.5_2       Timber Wolf
ARTICLE.5_3       Serrelinda
ARTICLE.5_4       Insert v1.7
ARTICLE.5_5       Backwards
ARTICLE.5_6       TraceVir
ARTICLE.5_7       Lapis Lazuli

About VLAD - Links - Contact Us - Main