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.
