A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about kernel-mode development.
 #6640  by Alex
 Thu Jun 02, 2011 1:12 pm
I've just found one chapter of "Undocumented Windows..." - or something like that... - book. At the 33 page there is a description of something which is called "Quick LPC" - did you heard about this/used it to communicate KM-UM?
Anyway, sticking with APC is ok Alex :mrgreen:
I know, but I'd like to know something more about methods I didn't use earlier.
Attachments
(3.48 MiB) Downloaded 46 times
 #6644  by t4L
 Thu Jun 02, 2011 3:16 pm
According to Wikipedia:
Quick LPC was introduced in version 3.51 of Windows NT to make these calls faster. This method was largely abandoned in version 4.0 in favor of moving the performance critical server portions into kernel mode (win32k.sys).
 #7521  by Alex
 Fri Jul 22, 2011 7:21 pm
Here is a good description of LPC with sources - LPC Communication. You can simply move code of client thread from user mode to your driver (Nt* -> Zw*)...
 #7660  by Tigzy
 Tue Jul 26, 2011 12:53 pm
I've tested the code, it works well...... in userland.

When trying to adapt the code for kernelmode, it becomes tricky.
All the APIs NtXxxxPort are undefined. How can I import them?

PS : the ntdll.h provided works only under userland app
 #7664  by EP_X0FF
 Tue Jul 26, 2011 3:06 pm
ntoskrn.exe exports only client LPC routines afair - NtConnectPort, NtRequestWaitReplyPort, something else don't remember. If they exists in lib but not present in headers - declare them yourself.
Why you should use this method to do such trivial task? There are exists more simple ways like shared memory, pipes.
 #7666  by Tigzy
 Tue Jul 26, 2011 3:24 pm
There are exists more simple ways like shared memory, pipes.
You're right, I'm always using shared memory, but I guessed a synchronized thing like LPC would be cleaner.
For the moment, I use a polling thread in my user app checking if there's a new "message", and my driver is constantly writing over this shared memory.

Maybe my code needs some improvements (such as message queue and mutexs -don't know if mutex can fly over from UL to KM-) , but I was convainced it was more a temporary solution than the right way to do...
Maybe I'm wrong. So was my previous question:
Is it a really better method than shared buffer?
What are the major differences?
EDIT:

For the import function, the problem is solved.
I took all the missing defs from the ntdll.h and copy/paste into my .h
Now I'll try to make it work :)
 #7869  by 0xC0000022L
 Fri Aug 05, 2011 9:49 pm
How about hanging IRPs? It's a pretty universal method. What you do is to send "down" some IRPs to the device, and the driver marks them as pending and returns them whenever data becomes available. Quick, easy and universal across the mentioned OS versions.
 #7892  by Tigzy
 Mon Aug 08, 2011 8:46 am
Yep, I use IRPs, that's a good stuff for communication where all comes from userland.
In my case, the problem is all comes from a hook proxy function. So there's no Irps...

BTW, is anybody got an idea about how to put my proxy function in a wait state, the time my UL process checks whether it should return SUCCESS or not?
And how resume it from UL? (with IRPs I guess) . that's for CreateSection hook