I've been working on a debugger thingy under the win32debug api, and I just added some code which is used to identify what module eip is currently within.
I currently achieve this by parsing the import table of the debug target app, then loading and unloading each and every lib I can see in there.. (perhaps someone can describe a cleaner way to do this?)
I've set it up to pause automatically if it fails to identify which module eip is within, so that I can identify libs which are being mapped without notification, such as ntdll.

(Just out of interest, I am debugging the debugger with itself during my testing.)

OK, here comes the question:

I noticed something weird, and I wanted to know if anyone has a clue on this one...
At some point, eip=7FFE0300, an unknown address.
Firing up Olly, I can see that the range from 7FFE0000 to 7FFF0000 is the "data block of main thread"... why would executable code reside here? Can anyone shed light on this? Am I losing the plot?
Posted on 2005-08-06 18:01:18 by Homer
i think i know what you mean, its ither an int(9x) or a sysenter instruction i belive it has something to do with a context switch.
Posted on 2005-08-06 18:38:58 by Qages
Without looking at the code that resides there, I was more curious about WHY its there (since I decode only a handful of opcodes which are of interest to me).
Your allusion to thread context switching makes a lot of sense.
It occurs to me that rather than use heap memory for this, m$ decided to use a hardcoded VA.
I'll dig deeper, but I believe you are onto it.. thanks :)
Posted on 2005-08-06 19:22:27 by Homer
At the start, on Windows NT, you can use the EnumProcessModules, GetModuleBaseName and GetModuleInformation functions to get the necessary information. On Windows 95 it might be a bit complicated.

I don't know what's supposed to be at 7FFE0300. Which operating system version do you use, and what kind of CPU(s)?
Posted on 2005-08-07 08:58:55 by Sephiroth3
When NTDLL makes a call to the Windows executive it has the problem that it cannot execute a SYSCALL from user mode as the page ranges of those calls are restricted to OS use. In order to get around this problem it loads the service number into EAX and copies the address of the SYSCALL (07FFE0300h in the kernel/user shared page) into EDX. It then does an indirect call...

mov EAX, srvnum
mov EDX, 07FFE0300h
call EDX
ret
Posted on 2005-08-07 09:32:58 by donkey
take a look at summit soft article by john

its shared user page mapped on all process by system
http://blog.kalmbachnet.de/?postid=11
http://www.summitsoftconsulting.com/SysCallOpts.htm

oops donkey is faster than me :)

since the above info is dud info already p
7C57EDD4 KERNEL32.GetTickCount? ? ?/$? BA 0000FE7F? ?MOV? ? ?EDX, 7FFE0000
7C57EDD9? ? ? ? ? ? ? ? ? ? ? ? ? ?|.? 8B02? ? ? ? ? MOV? ? ?EAX, DWORD PTR DS:
7C57EDDB? ? ? ? ? ? ? ? ? ? ? ? ? ?|.? F762 04? ? ? ?MUL? ? ?DWORD PTR DS:
7C57EDDE? ? ? ? ? ? ? ? ? ? ? ? ? ?|.? 0FACD0 18? ? ?SHRD? ? EAX, EDX, 18
7C57EDE2? ? ? ? ? ? ? ? ? ? ? ? ? ?\.? C3? ? ? ? ? ? RETN




or if you play with windbg
.load kdex2x86

!kuse*

!kuser
KUSER_SHARED_DATA at 7ffe0000
TickCount:    fa00000 * 000da6b1
TimeZone Id: 0
ImageNumber Range: [14c .. 14c]
Crypto Exponent: 0
SystemRoot: 'C:\WINNT'



:)
Posted on 2005-08-07 09:40:09 by bluffer
if i got it right, here is a suggestion....

before entering WaitForDebugEvent loop
call SymInitialize (imagehlp.lib)

on LoadDll event call SymLoadModule
on UnloadDll event call SymUnloadModule

Use? SymGetSymFromAddr to get current function
no need do the dirty work yourself
Posted on 2005-08-07 12:46:19 by drizz
Thanks for all those replies - much appreciated, especially the last one, from drizz..
too late dude, I've already implemented all the code to walk libs on the fly :(

Damn, I wish I asked earlier :)
Posted on 2005-08-08 04:06:16 by Homer
Homer, hopefully not using Load+FreeLibrary :P
Posted on 2005-08-08 07:18:38 by f0dder
f0dder - yes.. although I realize that libs won't 'always' map to the VA's specified in their headers.. my solution was to inject some code into the target which walked the libs "in the context of the debuggee", shoved some results on the stack, then caused an int3 (returning control to the debugger), which would then repair the target's stack (grabbing the results in the process), repair the overwritten code (actually at the entrypoint of the target), reset eip to the entrypoint, and then continue with business as usual. Oh, and in order to capture "late loading" of libs, I hook the target's IAT if I see LoadLibrary in there, with another int3 based snippet.
What an ungainly solution, I just so wanted NOT to use the pe helper api, which is a bit like saying "I want to shoot myself in the foot"... I'm tempted to throw in the towel and scrap all the relevant code at this moment, but it's hard to admit defeat when the implementation is working...

Perhaps I'll just move it all into the "onDllLoad" debug notification, but I wasn't certain that would be triggered by "late loaded" libs (ie, the target calling LoadLibrary, or worse, manually loading its libs)

I certainly don't want to write the world's coolest debugger - in fact, it's not a debugger I am writing at all but a kind of execution analyser (don't hit me on the head) - I just wanted to test some theories, and like most of my projects, it is a small animal that has grown rapidly into an unweildy and ungainly seven-headed beastie.. the more applications I analyse, the more tricks I learn, and ultimately, I merely wish to learn.

One of the main reasons I chose this awful approach is that I had initially implemented an int3 at the entrypoint so I could effectively "skip" the DLL loading stuff and get straight to the entrypoint.
I didn't want to trace my way through the PE loader, but perhaps I should have?
Posted on 2005-08-08 20:38:39 by Homer
Hm, couldn't you use GetModuleHandle instead of Load+FreeLibrary, or have I misunderstood what you're doing?

Doing stuff manually is good for learning, but at the end of the day, the debug helper library might be better (or, at least study how the library works :)). An example of something you most likely DON'T want to code yourself would be handling .pdb files.

The int3-at-entry-plus-restoring-code-etc approach is what I used myself in the "XCOM pitch-patcher" (bugfix loader), by the way. Seems to work like a charm :)
Posted on 2005-08-08 20:47:22 by f0dder
My thingy is capable of enlisting all the imported libs and functions before it's been loaded by the pe loader at all, before I've created the process (I don't attach for various reasons), I preload the target, walk its import directory, spit out all the relevant information, then unload the target, then the user can hit a button to create the process and begin debugging in earnest (dirty approach huh) ... due to my borrowing of some of iczelions example code..

The GetModuleHandle function returns a module handle for the specified module if the file has been mapped into the address space of the calling process.


So, that's fine if the pe loader has completed... but not if it hasn't.
Thus, I enumerate imports twice - once before debugging begins, and again during debugging, in order to catch "late loads", particularly those which are "manually loaded" by their callers, and here I refer to the "static loading" types of tricks used to hide libs from standard debuggers, by NOT using the pe loader.

I should implement Sym functions and handle dll loading breaks and scrap 80% of the existing code.
Posted on 2005-08-08 21:10:13 by Homer
Ah, before the PE loader has completed - I see.
Posted on 2005-08-08 21:13:43 by f0dder
**this also aplies to you last post**

but noo, why not read the file on disk? (or hFile member of createprocess event)
if you want to do anything before dlls are loaded.

and yes "..the target calling LoadLibrary" -> you _are_ informed @ "onDllLoad" debug notification


One of the main reasons I chose this awful approach is that I had initially implemented an int3 at the entrypoint so I could effectively "skip" the DLL loading stuff and get straight to the entrypoint.
I didn't want to trace my way through the PE loader, but perhaps I should have?

you have to put int3 at entrypoint. (*but not neccessarally on 9x*)

i think you need some code DUDE!? :P

DbgEventCreateProcess proc uses ebx, cpdi:ptr CREATE_PROCESS_DEBUG_INFO
LOCAL nbr:dword,DosHdr:IMAGE_DOS_HEADER,NtHdr:IMAGE_NT_HEADERS
assume ebx:ptr CREATE_PROCESS_DEBUG_INFO
mov ebx,cpdi
invoke ReadFile,.hFile,addr DosHdr,sizeof IMAGE_DOS_HEADER,addr nbr,0
invoke SetFilePointer,.hFile,DosHdr.e_lfanew,0,FILE_BEGIN
invoke ReadFile,.hFile,addr NtHdr,sizeof IMAGE_NT_HEADERS,addr nbr,0
invoke SetFilePointer,.hFile,0,0,FILE_BEGIN
invoke GetFileSize,.hFile,0
invoke CloseHandle,.hFile
...
*print info*



DbgEventLoadDll proc uses ebx esi, lddi:ptr LOAD_DLL_DEBUG_INFO
assume ebx:ptr LOAD_DLL_DEBUG_INFO
mov ebx,lddi
mov esi,$invoke(GetMem,2*MAX_PATH)
invoke GetModuleFileName,.lpBaseOfDll,esi,MAX_PATH*2-1
...
*print? info*


if you want more pm me!? 8) i'm also writting a little project with dbgapi
Posted on 2005-08-09 08:39:10 by drizz
drizz:
I have not yet implemented the Sym functionality, however, I've implemented dll onload notifications, and I see that I NEVER get the lpImageName field, it ALWAYS seems to point to the same address within the thread information block (7FFE0014 or something similar) which in turn ALWAYS seems to contain NULL :(
That really sucks, it means I STILL have to perform the pe walk myself, if ONLY to get the name of the library !!!
Yes, I often wondered why iczelion loads and unloads the file as a datafile in his debug examples, when there's no context issue to worry about : LoadLibrary would have been ok in those examples.
However, I've seen (under analysis) some applications which MANUALLY load one or more libraries (totally avoiding LoadLibrary, means we get no such notification) and also, I have NO IDEA about how to handle "bound imports" , let alone "Import Forwarding" :(
Can you offer suggestions on these topics and/or point me toward relevant information?
I am also interested in more information regarding the Sym functions...

Also, you say that I *SHOULD* be injecting the int3 to entrypoint, thanks, that's good feedback :)
I would have assumed there was a "clean" way to break at the entrypoint, I find it incredible that this functionality is not provided by the debug helper api !!

Finally, I must repeat, I'm not writing a debugger per se, I'm writing a "flow analyser", which among other things, should prove useful in identifying execution bottlenecks etc. in my other projects :)


PS:
I just wanted to add this footnote:
I believe now that it was highly appropriate that I walk the import directory of the target, although I now know I can do that when the process is created.
The reason is that this is the ONLY way to get hold of the names of the imported libraries !!!
Here's what I cannot do : I cannot wait for a dll load notification, then walk the loaded library's header for its own filename. The reason is that field is created by the Linker, and may not be accurate, and/or can be changed later !!! Microsoft agree, and whine that they look forward to implementing it in some future release, which is really an excuse for not allowing us to get it directly from the pe loader, and/or not notifying us of the dll load PRIOR to it being loaded

Posted on 2005-08-09 11:44:17 by Homer

I've implemented dll onload notifications, and I see that I NEVER get the lpImageName field, it ALWAYS seems to point to the same address within the thread information block (7FFE0014 or something similar) which in turn ALWAYS seems to contain NULL

This is LOAD_DLL_DEBUG_INFO.lpImageName, right? You could try treating lpBaseOfDll as a handle, and use psapi to walk the module list?

Posted on 2005-08-09 12:19:08 by f0dder
i see your problem now...

if lpImageName is 0 then? @1 <no name>
else readprocessmemory sizeof dword pointed by lpImageName
if that dword is 0 goto @1
else readprocessmemory sizeof MAX_PATH*2 bytes from that dword(address)
if fUnicode then convert from unicode to ascii
call symloadmodule with hFile,dllnameA, lpBaseOfDll


I've seen (under analysis) some applications which MANUALLY load one or more libraries (totally avoiding LoadLibrary, means we get no such notification)

i've never seen that, i know it is possible but unless you are studing some malware why bother?

EDIT1(2): i'm talking rubbish
lpImageName points to PEB.NT_TIB.ArbitraryUserPointer inside address space of debugee
that points to unicode dll name (on NT)

EDIT2: i was assuming wrong that calling GetModuleFileName(lpBaseOfDll) will work.
it only works if the dll is loaded for your process too.
Posted on 2005-08-09 15:08:33 by drizz
I just like to cover all cases... if at some stage I choose to release this tool, I don't want people coming back to me and complaining about the various special cases which I did not cover.

f0dder - yes, I can do that, and most likely will, although right now it's tempting to simply move my existing pe walking code into the dll onload notification handler as I suggested in an earlier post..

drizz - currently I don't ReadProcessMemory on the lpImageName pointer, because Olly is telling me that it points to NULL, in all cases I have seen so far.. very disappointing stuff.
Microsoft mention that it is unlikely that the pe loader will return lpImageName for the FIRST DLL LOADED, and suggest we should be prepared to handle the case where either lpImageName, or the pointer behind it, are NULL .. I suggest that (at least from what I can see) this is ALWAYS the case :(
Oh well, looks like I'll have to grin and wear it :) I'm interested in taking a peek at your stuff regardless, perhaps I can learn a thing or two, perhaps not, but it sure doesn't hurt to look.

Posted on 2005-08-09 23:53:07 by Homer

currently I don't ReadProcessMemory on the lpImageName pointer, because Olly is telling me that it points to NULL, in all cases I have seen so far.. very disappointing stuff.

its NULL in YOUR address space it's not NULL in DEBUGEE address space.
assuming you are debugging your debugger with olly


Microsoft mention that it is unlikely that the pe loader will return lpImageName for the FIRST DLL LOADED, and suggest we should be prepared to handle the case where either lpImageName, or the pointer behind it, are NULL .. I suggest that (at least from what I can see) this is ALWAYS the case

Microsoft says that for compatibility reasons with 9x. If you are going to support w9x too, then
there is a long road ahead of you. I admire Oleh for OllyDbg, it must have been a nightmare.
Posted on 2005-08-10 08:26:32 by drizz
Actually no, I was debugging the DEBUGGEE with Olly, and comparing its "memory map" to the data obtained from my own debugger when debugging the same debuggee...
I'm going to assume that this (lpImageName field) is simply is not a viable field and move on - after all, we're asm coders, we're not afraid of the pe minefield like some namby-pamby "certified useless" programmers :)
Do I sound like I am biased? lol

As for supporting Win98 - No, I don't care about them much at all, I very much doubt this will be a commercial application, I'm not pandering to those guys, screw them - they can use something else :)
On the other hand, at this very moment, theres no psapi, theres no dbgapi, theres no Sym stuff, and unless I find my hand forced, I'll support Win98 by happy accident..
Posted on 2005-08-11 00:48:56 by Homer