http://research.microsoft.com/collaboration/university/europe/events/dotnetcc/version4/Slides/maggiorini.ppt

USYC: an Infrastructure for Providing Kernel Services in User Space on Microsoft Windows 2000
-------------------

27 powerpoint slides. Might give you some ideas.

The slides further refer to a dead link.. But I believe the new location is:
http://homes.dico.unimi.it/~pagae/NPTLab/usyc.html

Cool!

Yes, nice, but give us the code please!
Bilbo

Technically you can do this already - you can have a generic driver that takes in a function pointer as an argument. The driver then calls this function pointer, which exists in user space code.

However, of course the user code is then running in ring0, so yes we need to go through a task gate to go back to ring3. This can be accomplished with the right interrupts. The only real problem is guarantee of context when the user code executes. you have to be in the right context ! One thing that is proven though, is DriverIOControl is always going to run in the same context as the calling user mode program. If a driver uses a DriverDispatch (or an IORequest, which sends a DCP message) function though, to complete its task, the driver IRQ gets queued and who knows when it will run. In that case you'd have to pass in the process ID too (or process handle?), and use KeAttachProcess(PEB) and KeDetachProcess() (which is undocumented) or similar to force the context switch..

The "Syscall proxy" that they talk about sounds like what kernel32.dll does already - it takes calls, then jumps to NTDLL.DLL, which does a interrupt syscall to get the job done..


-nt20

An amusing thread on the same subject from "big head" people

h..p://groups.google.it/groups?th=a53813cbf2276062

Bilbo

Actually, the software in the initial link did the opposite of what nt20 and the people in that thead are talking about, at least as far as I can see?

Ah, found the article I was looking for... The method alluded to by nt20 I believe, on a way to run user mode code in a kernel context is described in this 1996 OSR article "Understanding and Using Execution Context in NT Drivers". According to the article you can issue Win32 function calls, pop up dialog boxes, and perform File I/O. The only difference is that the user-application is running in kernel mode, on the kernel stack, and is not subject to privilege limits, quotas, or protection checking. The article is attached.

I had played with the technique a bit, but was never able to pop up a dialog box successfully. OSR Online requires registration now but some of its excellent articles are archived on Chapeaux Noirs and I believe Wasm.ru as well.

Kayaker

[If you can spare the few hours to analyse the xprotector driver]

Xprotector performs a similar trick (IoAccessMap). The driver flips some bits in the page directory, allowing the calling user-mode application to have read/write access over the IDT and the Xprotector driver's .data

So the IDT is patched (quite a few times) at r3 and the int 3 handler also runs at that level. Access to instructions like iretd is also granted to the r-3 application.

I never investigated if that driver could be exploited, but I always considered it as a wide-open backdoor into my computer. (As soon as you send it a DevIo control, you get those priviledges). When you run an xprot application, you never get a Message warning you that a backdoor driver is being installed

heh, you also dont get a message that the application will be 4x its size, run like a snail on treacle or has the potential to crash randomly