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
located.
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.
