Hello!

After studying everything about protected mode techniques etc there's one thing which confuses me...

The IDT is located at and has one 64-bit Interrupt Descriptor after another, for each int .. of course :grin:

In SoftIce, I read out the IDTR which points me to C000BE20h (in my case), and there I'm finding all Interrupt Descriptors especially the one for int 3 which brings me directly to SoftIce's code :cool:

So far so good...
but when I use the IDT command in SoftIice, it displays me partially wrong int-handler addresses ... for example the real int 3 handler is, according to my eyes, at: 0028:C0040C19h
and IDT list of softice tells me it is at: 0028:C0001220h which is inside VMM and seems to be also a table with 16-byte arrays....

So now i am totally confused...

Someone help me out. Thanks for your time!

aweX <-
Posted on 2002-06-23 06:47:28 by aweX
Ok it seems like that's just SoftIce hiding itself ... never mind...

But the following problem is a really general one:

I wrote a handler for interrupt 3 which should translate the selector of fs-register of the current task into its linear address.

I'm trying that by fetching the LDTR from the Task-State-Segment of the current task... I can find this segment but it contains zero everywhere instead of correct CS/EIP/EAX/... values, also according to SoftIce!

Why is that?

aweX <-
Posted on 2002-06-23 14:37:31 by aweX
The only fields used from the TSS in Win9x are SS:ESP0 (ring 0 stack) and the IO permission Bitmap. Thats because the x86 tasks arent used by Win9x.
Posted on 2002-06-24 06:19:16 by japheth
D'oh! So all my trying was useless...good to know!

Well so how could I retrieve the selector of the FS-register of the current process from inside my int3-handler which has been called by that process? Also, can I just use current LDTR to translate that selector into its linear address?

Another problem is that when my int 3 handler is called, the stack is not looking like: EIP, CS, EFlags, ESP, SS . So when I call IRETD at the end of my handler, it crashes... I have to call the original handler. Is that a MUST under Windows?

Where can I find a good docu on how Windows uses protected mode (since it seems to be completely different) ?

Thanks for any answer!

aweX <-
Posted on 2002-06-24 08:16:31 by aweX
there exist more than one way to get local descriptor base addresses:

1.
- get LDT selector by "sldt ax"
- get GDT by "sgdt fword ptr xxx"
- search LDT descriptor in GDT, get base of descriptor
- now "search" FS entry in LDT

2.
In Win9x there always exists an "LDT alias" which can be trtrieved by calling INT 2F, AX=16?? (forgotten by now). But as you probably know, you cant call this interrupt directly in win32.

3. VWIN32 allows a Win32 app in Win9x to call DPMI functions.


About your Int 3 handler: SS+ESP are on the stack only if a switch to ring 0 occured. So is your handler a ring 0 proc? How did you install it? By directly manipulation IDT? If yes, is the entry in IDT a 386 interrupt/trap gate? if yes, IRETD should work.

japheth
Posted on 2002-06-24 13:06:01 by japheth
I'm using method number 1 for translating fs into its linear address. That's not the problem. The problem is that I have installed a global int 3 handler which is called via 0CCh-instruction from a process. Now I want to know which value fs had before the process breaks into my interrupt handler since the registers seem to be modified.

Simple structure of what I'm doing:




ring3 proc
<modify IDT to point int3 to ring0a proc>
<call int 3>
<exit program>
ring3 endp

ring0a proc
<call GetHeap service to allocate global system space>
<copy ring0b and ring0c procs into allocated space>
<modify IDT to let int3 point to ring0b>
iretd <-- this iretd works! (because I am in my local mem i guess)
ring0a endp

ring0b proc <-- will be entered via int3 caused by some other process
<restore old int3 handler in IDT>
<do some misc stuff like translating FS into linear address and setting breakpoint>
<modify IDT to let int 1 point to ring0c>
iretd <-- leads to wrong mem because stack is messed up somehow! but why?
when i'm calling the original handler via "push <addr>, ret" it works
ring0b endp

ring0c proc
<further actions>
iretd <-- this will also crash or result in direct boot because stack is crappy!
ring0c endp


I'm basically modifying IDT in both cases by just changing the offsets and not the selectors (which is 0028h in my case) ... that means I still (should) have a valid Interrupt Gate there.

Oh and I really would appreciate it if anyone could give me a hint where Windows saves the Task-States.


aweX <-
Posted on 2002-07-04 17:46:15 by aweX