Re: [line-devel] NTCreatePort failed with a c0000022

[Jordan S. <jd...@me...>]

> - access the userland address space of the process that invoked it?
I think so.  The interrupt handler is in the same address space as the
calling process just at addresses > something like 0xc0000000

> - SuspendThread() the thread that invoked it?
I dont think you can suspend the thread.

>
> Do you know what the stack looks like after the int 0x80 handler is
> called?  Shouldn't it be possible just to alter the return address that
> the IRETD loads once the handler is finished?

Possibly.  You could try it.  this is a quote from undocumented windows NT.
"When a 32-bit application program executes an INT nn type of instruction,
the processor first looks at the descriptor entry for the interrupt and
verifies that the current privilege level is at least as high as the
discriptor privilege level. ... If the privilege level of the discriptor
allows the interrupt to continute, the processor switches to the kernel
stack. the kernal stack is selected by looking at the field in the task
state segment (TSS) after this, the processor pushes the old ring 3 stack
pointer (SS:ESP) and a standard interrupt frame (EFLAGS and CS:EIP) and
jumps to the handler routine specified in the interrupt descriptor table
entry. The handler perfomrs its job and executes the IRETD instruction to
return to the calling application. when IRETD is executed, the processor
pops off EEFLAGS and CS:EIP, notices the switch from ring 0 to ring 3 and
pops off the ring3 SS:ESP and then the execution continues from the
instruction following the int nn instruction."

Therefore I gues you could write an INT 80 handler that does something like
this.

get the ring3 stack pointer.
add 4 to it.
write the ring3 EIP to the new stack location.
change the iret return address to your new handler
change the iret return stackpointer to the new stack-pointer
do an IRETD

One question is how is the interrupt handler going to know where to return
to.
I guess you create a new int80 syscall that passes the return address to the
int-80 handler. then the int80 handler would have to maintain a mapping of
process handles and return-addresses.  99.999% of the time however, you
could just iret to a fixed address.

>
> One big problem was the performance hit of doing a ReadProcessMemory() to
> retrieve any data being passed into the kernel, then doing
>...
> migrate the handle to the app somehow, or maintain a list of all the
> currently open handles for each app in the kernel process.  This isn't an

Yes these are issues.

I guess it just goes to what you want to write.  I really dont have time to
do either
of these things.  If I had time, I'd want to get these linux apps running
without
win32 support.  It'd be a lot of work, but it'd give me an opportunity to
really learn
how linux works.

    Mike
P.S. undocumented NT also says "windows 95 procieds a mechanism to hook
software interrupts by means of Set_PM_Int_Vector and Hook_V86_Int_Chain VxD
services"