
                                        /-----------------------------\
                                        | Xine - issue #3 - Phile 100 |
                                        \-----------------------------/




                  ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
                  º   Win95 structures and secretS   º
                  ÈÍ»        by Murkry/IkX        ÉÍÍ¼
                    ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ¼


  Since the start of Win95 many things that virii writers came to accept as
easy to get, became harder.  Things like the interrupt calls, filename paths
to the system files.  Well the API calls have replaced interrupts and virii
writers have used several tricks to get the address to these calls.
As for filename or path to system files, we have hard coded possible ones
and also used the API's (of course this added a bit to our code).
Of course back in the DOS days if we search the PSP we could find much of
this info without relying on API calls.  Well as many readers of Windows95
System Programming Secrets are aware there are several tables (or K32 objects)
that are available for us but finding these tables requires API (or at least
in the book they do).  Well as you may have guessed by now the pointers to
these tables are readily avaiable. In win95, A and B version as well as some
of the earlier version the Registers seem to startup with similiar info.
Be warned that this info does not apply to WinNT in the release of Win98
I saw it was true though. (Side note, nice check for win95 to win nt is
eax != eip then your probably not in 95 or something was playing with
the registers b4 you got them. Hmm make sure your viruses restore all
regs or some smart programmers may actually write some self aware programs
that check this ;) 

 Anyway all 95 versions I have checked Regs start out with

        EAX  =  EIP of startup
        EBX  =  ???
        ECX  =  K32OBJ_MUTEX              appears
        EDX  =  K32OBJ_CRITICAL_SECTION   appears
        ESI  =  K32OBJ_PROCESS
        EDI  =  K32OBJ_THREAD
        EBP  =
        ESP  =  Strange info see below
	
Ok b4 all you experts yell (wait,, experts?? hell you write this):

EAX  is basicaly a fact

Ebx  00530000 or similiar number never points to a in processs address though

ECX  This is a Guess but it seems to point to a table and starts with 03
	Read the Book to understand why 03 means something

ESI  points to a table that starts with 05 and I have used this table
	to get to the enviroment database which wonders of wonders
	has things like Full path and file name of executing file
        Paths and command line Startupinfo. Again reading the book will
        explain all or if you have access to the ddk you can verify
        this as I have done.

EDI  Table starts up with 06 and has all sorts of info in it

EBP  somewhere I have notes on what this points at, but I can't locate it
        I think MarkJ may have eaten it when I last babysat for him ;)

ESP  strange but if you look at a start up there are some very intersting
        numbers that always show up.
		 
now this varies depending on lenght of name, but again we find pointers to
locations that when examine are tables or pointers to entries in the tables as
well as SEH pointers:
		
		+10 = File name of file being excuted
			format is strange 'Host1',0,'EXE',0
			whether or not you enter the extension or not it will
                        be caps and the name will be caps first letter
                        lowercase rest
                +c  = ebp = Dammit what is this number
                +8  = esi = obj_process database
                +4  = edi = obj_thread database
            EsP +0  = pnter into location in Kernel32
	

What does this mean to us virii/hackers of win95 lets say we want to write a
virus that adds info to the end of the host but does not modify the host PE
header so while the info is there it is not loaded into memory. (A new LE\Macro
infector works like this) Step one we need the file name well check out the
code below which will show a MessageBox with the file name in quotes when ran
normaly but will show the file name without quotes if in td32 and I assume
other debuggers (probaly not SI though) Be warn about this feature since this
means if you are running a debugger to test it will work diffrently ie if you
used this pointer to try and open the file it will fail since file
"c:\filepath\foo.exe" is the file you will try to open not c:\filepath\foo.exe.

   NOTE  this is one way to get the info i could just use esi rather than get
         the info off the stack

        mov     edi,[esp +8]    ; Get the Pointer to process Database
        mov     edi,[edi+040h]  ; Within DataBase get pointer to the Enviroment
                                ; DataBase
        mov     edi,[edi+8]     ; In Enviroment DataBase get the Pnter to
                                ; Command line
        call    MessageBoxA,large 0,edi, offset tile,large 1

now there are a lot of other info avaiable in the other Database but the
Enviroment Table is structured as:

     Offset
	00h    Ptr to the enviroment string  
		as you scan through the table you find  
                     =C:=C:\tasm\virii\over
                     TEMP=C:\WINDOWS\TEMP
                     PROMPT=$p$g
                     winbootdir=C:\WINDOWS
                     COMSPEC=C:\WINDOWS\COMMAND.COM
                     PATH=C:\BTI\WIN\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\UTIL;
                     TMP=C:\WINDOWS\TEMP
                     windir=C:\WINDOWS
                     CMDLINE=td32 host1
	       
        * While the ; is used in the path all other items are delimited by 00h

	04h    unknown Zero as far as I have seen
	0Ch    pntr to str Current directory note when in 
                     td32
                          C:\TASM\VIRII\OVER\HOST1.EXE
                     Normal
                          "C:\TASM\VIRII\OVER\HOST1.EXE"
	10h 	ptr to a copy of StartupInfo 
 	

There are other entries but these are the ones I am showing for now since they
are the ones I view as nice to have for virii related, See the book or DDK for
more info.
As you can see the Enviroment database is as useful as the old dos psp oh btw
there is still a PSP see Process Database offset 24h of course its the linear
address, But exploring info that the stack has to offer is fun as well and as
for the infamous FS:[0] seh area

this is called (in the book) Thread Information Block TIB point at by edi
starting at offset 10h in that database.


 Strangely this same info is also in the thread database 
00      dd      pointer to existing Exception handler (see 29A#2 for more info)
04	dd	top of stack
08	dd	stack low
0ch	dw	w16tdb
0eh	dw	StackSelector 16 byte
10h	dd	Selman list
14h     dd      User Pointer user accessable ???
18h	dd	pnter TIB (book says) to me points to ESI obj process database
1ch	dw	tibflags
1eh	dw	win16MutexCount
20h	dd	DebugContext
24h	dd	pntr Current Priority
28h	dd	Message Queue
2ch	dd	pntr TLS Array

Get this grab the top of stack
now sub 4   get   0
        8         a pnter inside some location in Kernel32
        c         ?
        10        0
        14        looks like a copy of the PE header and a NE header of some
                  sort this entry may be important?? not sure

 Again don't bet the house on this info, while the tables are documented I am
sure a number of my fellow PE 32 bit virii friends will point out "Its not
documented" when refering to my method od using esi or stack refrence to get
the Process database location. I suspect in Win95\98 stays around long enough
these items will be documented as people use them more and more. Of course
just use the SEH method to protect your code and then feel free to try these
ideas out if they SEH catches it then you can exit gracefully.
  
Anyway I include with this article a bried example file that shows the two
methods of getting the File being excuted. I could have used esi to get the
K32OBJ_PROCESS but I instead show the stack method of doing it.

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
And here is some sample code. Compile as usual:
tasm32 /ml /m4 host1,,;
tlink32 /Tpe /aa /c /x host1,,, import32.lib
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

.486
.model flat,stdcall


;Define the needed external functions and constants here.

extrn           ExitProcess:PROC
extrn           MessageBoxA:PROC

.data                                   ;the data area
dummy           dd      ?               ;just so tasm will compile it 
tile           db      'Hmm',0
.code                                   ;executable code starts here
 
HOST:
 
;Example of getting filename off stack
        mov     al,0
        lea     edi,[esp + 16D]         ;file name
        push    edi
        repne    scasb
        mov     byte ptr [edi - 1],2eh
        pop     edi
        call    MessageBoxA,large 0,edi, offset tile,large 1

;example  getiing the obj_process off the stack
; then geting enviroment database at offset 40h then offset to the filename
; notice the " "
        mov     edi,[esp +8]
        mov     edi,[edi+040h]
        mov     edi,[edi+8]
        call    MessageBoxA,large 0,edi, offset tile,large 1

        jmp     here


 
here:
        push    LARGE -1
        call    ExitProcess             ;Dummy host does nothing but end 
                                        ;like int 20 in Dos 
        end     HOST



