Copy Link
Add to Bookmark
Report
29A Issue 02 03 01
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
ÚÄ PE infection under Win32 Ä¿ ÜÛÛÛÛÛÜ ÜÛÛÛÛÛÜ ÜÛÛÛÛÛÜ
³ by ³ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ ÛÛÛ
³ Mister Sandman ³ ÜÜÜÛÛß ßÛÛÛÛÛÛ ÛÛÛÛÛÛÛ
³ Jacky Qwerty ³ ÛÛÛÜÜÜÜ ÜÜÜÜÛÛÛ ÛÛÛ ÛÛÛ
ÀÄÄÄÄÄÄÄÄÄÄÄ GriYo ÄÄÄÄÄÄÄÄÄÄÙ ÛÛÛÛÛÛÛ ÛÛÛÛÛÛß ÛÛÛ ÛÛÛ
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
ÄÄ´ Introduction ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Same as we establish different ages in the evolution of computers we should
establish different ages also in the evolution of computer viruses, as they
advance together with the systems, platforms, and processors they intend to
infect. There were not, of course, any viruses for those huge wardrobe-like
computers with whom you couldn't do much more than what you can do nowadays
with a supertiny pocket calculator. But since viral activity started around
1985, lots and lots of people have been crashing their balls at their chair
trying to evolve and advance in viral technology.
However, save for some exceptions, we have been fighting for over ten years
against the same operating system, the same 16-bit crap, designed and never
improved by Microsoft. That's why such a long period of time should be con-
sidered an only step, the first period of the viral existence in computers.
Now this first viral age seems to have reached its end, as well as DOS, al-
beit it will continue working in millions of computers, all over the world.
In the other hand we have Windows95 and WindowsNT (from now onwards and to-
gether with Win32s we'll call them Win32), which are being used and instal-
led in an incredibly increasing percentage of computers. We can't say Win32
will be the future and definitive OS, but it does seem it is one of the 1st
storeys the final thing is gonna be built on.
This new phase of operating systems also means a new phase of viruses which
will work and infect under these new scenarios. Win32 has become the most
used OS in less than two years, and will surely wipe out of the map many o-
ther minoritary operating systems, such as OS/2. Virus authors have reali-
sed about this fact, and that's why a new era opens at us... the second vi-
ral age or generation, a new breed of infectors... 32-bit viruses.
If you're one of those who have always dreamed about how cool would it have
been to start writing viruses around 1985, when they first appeared, but it
was too late for your dreams to become reality, now you have a second opor-
tunity to become a pioneer in the VX scene. And if you're just one of those
dorks whose only wish is to remain being nobody as one of who knows how ma-
ny thousands of DOS virus writers and can't go further than the (true) sta-
tement "Windows95 = shit"... stop reading and go code with your open menta-
lity to YAM, cause this won't be of your interest.
Before going further in this tutorial, it must remain clear for our readers
that we DO support the statement "Windows95 = shit", but proffesionality is
usually a synonym of objectivity, and that's why we have to focus it with
impartiallity. I think no intelligent human being in this world likes Win-
dows95, but it's an interesting attitude to see it just as a test 32-bit OS
in order to advance in the viral-oriented researching, without bearing in
mind how good or bad it is, or how many bugs it has.
Just say "let's go for it!".
ÄÄ´ Welcome to the new school ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This tutorial is *almost* 100% theoretical, as it intends to illustrate the
so called "29A technique", which will help you in order to write compatible
viruses for Windows95 and WindowsNT and to make them much more versatile in
the concerning about PE modifications. At the moment of writing this, there
were _only_ four Win32 infectors (Win32.Jacky, Win32.Cabanas, Esperanto and
Win32.Marburg - order of appearance), and they all have been written by 29A
members, which shows the lack of Win32 virus coders by now. The contents of
this article are pretty advanced and oriented to those who have already co-
ded at least some Windows95 PE infector.
If your intentions are to get started in the 32-bit virus age and begin co-
ding some basic PE infectors, we recommend you to have a look to other pre-
viously published sources in other virus magazines; then, come back to this
article and get some pretty useful clues about how to stay compatible :)
This tutorial will deal with "APIs: the key stone", chapter in which we try
to explain the importance of working at API level, "The KERNEL32 problem",
and "The GetModuleHandle solution", which explain one of the main problems
in the concerning about getting the base address of KERNEL32.dll, "GetProc-
Address", showing the best way to get API addresses, "Simple PE infection",
which illustrates a simpler way to infect PE files, and "Cool addings", as
a preface to another article in 29A#3, which describes some features, which
can be added to any Win32 virus in order to make it more complex.
Before stepping into the first chapter it's a honor to say that the pioneer
of these techniques, the guy who wrote the first Win32 infectors, and thus,
the one who should be known for having developed the first 32-bit viruses
is Jacky Qwerty/29A, the author of Win32.Jacky, and Win32.Cabanas. It would
be completely unfair not to mention -and even congratulate- him.
ÄÄ´ APIs: the key stone ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
The most important thing you'll have to bear in mind while writing your 32-
bit viruses for Windows platforms is to always! use APIs. Why are APIs that
important? the answer is easy... they are the only point Windows95 and Win-
dowsNT have in common. Viruses have to look as closer as possible as normal
applications, and there are no normal applications in Win32 which don't use
APIs in order to perform its functioning. Using apparently neat tricks such
as calling interrupt 21h within a Win32 application is the worst thing your
Win32 virus can do, as it won't be able to stay compatible and besides will
be 100% dependent of the presence of DOS. While nowadays this last reason
does not represent any serious trouble, it will for sure be a pain in the
near future as DOS is about to be wiped out of our computers as soon as new
versions of Windows95 or WindowsNT are released.
ÄÄ´ The KERNEL32 problem ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Once we have assumed we're gonna work at API level, the very first necessa-
ry thing is to locate KERNEL32.dll, as it is the library which contains the
address of all the API functions we need to use in our virus. But, there is
a big problem here... the address of KERNEL32 is not fix at all. It has not
been the same in any of the known versions of Windows95 as well as for Win-
dowsNT... and this means we can't (or at least should not) assume hardcoded
values because they'd force our virus to be compatible with only one of the
Win32 platforms, and what we're looking for is just the opposite thing.
ÄÄ´ The GetModuleHandle solution ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
The solution is always in APIs. There's an API, "GetModuleHandle", which is
used in order to get the address of a given module. And, of course, this is
of our interest since KERNEL32.dll is a module. But now comes a pretty cu-
rious thing... how the fuck is it possible to call an API function if we're
looking for KERNEL32 just because we need it to be able to call APIs? Quite
similar to the question "what was first, the egg or the hen?".
It is simple. Just don't infect PE files which don't import any function of
KERNEL32.dll (almost impossible tho), so you will make sure, every file you
infect imports something from KERNEL32.dll, so it will be possible for you
to look in the IAT for the RVA of the GetModuleHandle API, and then call it
from your code. Once having called this API by means of its RVA you'll have
the address of KERNEL32.dll waiting for you in EAX ;)
ÄÄ´ GetProcAddress ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Now it's ok, you already have the address of KERNEL32.dll, but... where are
the address of the APIs you need? how will you call them? the answer is ea-
sy again... by means of another API, "GetProcAddress", which makes possible
to get the address of any API function in any given module.
Now that you have already guessed the base address of KERNEL32.dll, all you
need to do is to specify the name of the API you're looking for in that mo-
dule and call the GetProcAddress API. A table of API names and a good loop
are strongly recommended in order to save a good amount of bytes ;)
It's understood that, same as for GetModuleHandle, you need to get the RVA
of GetProcAddress in the IAT of your victims, while infecting them, because
there's no way to know it at the time you need to call it :)
Obviously, both the GetModuleHandle, and the GetProcAddress solutions might
not work under certain strange circumstances. For the case of this happens,
you should have some extra routines which, by means of undocumented tricks,
could get the address of both APIs. Two good examples of this are included
in the source code of the Win32 viruses published in this issue of 29A.
ÄÄ´ Simple PE infection ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This very last point of the so called "29A technique" deals with file hand-
ling in Win32 (API-based, of course) and the PE infection itself. There are
two very important things on this: file mapping in memory and attachment to
the last section declared in the PE header.
File mapping in memory is a new way of handling files Win32 platforms pro-
vide in order to make things much easier. Now you don't need to read, write
or lseek anymore. Just map any file in memory and you'll get a base address
where it has been mapped. From that base address, just reference any offset
and read from it, write into it, and do whatever you want, with no need to
lseek to any position... it's mapped in your memory :)
And the second and last point is extremely important. Before Jacky Qwerty
came up with this technique, all the Win95 viruses infected PE files by mo-
difying the PE header and inserting a new section into it, then copying the
viral body into that last section. This was very easy to detect, apart from
being a very tedious method and taking a lot of bytes in your code. The so-
lution we provide to this in our 29A technique is to update the size of the
last section of the PE file in the PE header, including the size of our vi-
rus, and then appending our code to the end of this section.
Harder to detect, easier to write ;)
ÄÄ´ Cool addings ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
There are a lots of things which have not been mentioned in this tutotial,
albeit they are being already used and enjoyed, such as the implementation
of Structure Exception Handling (SEH), 32-bit polymorphism, and many other
cool techniques which make our Win32 viruses much more stable and robust.
These and other topics will be referenced in our next issue, where a lot of
code examples will be available to make possible to check these new tricks.
Till then, put the 29A technique in practice, and do not forget to make use
of the tools we provide to you in this issue of 29A (PEWRSEC, GETPROC, and
the 29A INC files, which are extremely useful to code your Win32 viruses).
Mister Sandman,
bring me a dream.
