[listito]

One very interesting thing about this function is that all process with user32.dll are monitored, the ones who haven't are not, so what about hiding user32.dll? hehe

I remember i tried to hide it a couple of months ago with NTIlusion method, but no success against setwindowshookex and process explorer for example :(

[EP_X0FF]

One very interesting thing about this function is that all process with user32.dll are monitored, the ones who haven't are not, so what about hiding user32.dll? hehe

I remember i tried to hide it a couple of months ago with NTIlusion method, but no success against setwindowshookex and process explorer for example :(

What you want to do? Defend yourself from dll injection via SetWindowsHookEx?

If so, there exists other way, Peb->KernelCallbackTable (ClientLoadLibrary), c.f. KiUserCallbackDispatcher.

[Vrtule]

One very interesting thing about this function is that all process with user32.dll are monitored, the ones who haven't are not, so what about hiding user32.dll? hehe

I don't think hiding user32.dll will help. Hook callbacks are usually executed when certain Windows messages are passed to the target thread. And Windows messages stuff (and other GUI) is implemented in user32.dll.

LL hooks work a little bit differently. They are global to the desktop and I think they do need user32.dll only in application that installed them.

[listito]

well i've found kinda stupid solution, it was hooking loadlibraryexw, but it doesn't work in other versions of kernel32.dll, holy crap, isn't there any good detours engine around?

because i don't know what to do to make a good portable hook...

[Vrtule]

Then, look at KiUserCallbackDispatcher routine in ntdll.dll, as EP_X0FF had already recommended you.

This routine is called whenever the kernel needs to execute some code in user mode (but not inside APC). It is the user end of user mode callback mechanism used mainly by Windows GUI subsystem (win32k.sys) and by Windows Hooks too.

You can hook this routine. It should be quite portable. You need only special hook code for x86 and x64 platforms.

However, manipulating with Peb->KernelCallbackTable could be even more portable.

[listito]

i'm very impressed, i'd not imagine to find such a table like this in usermode even in a million years, thanks guys :twisted:

But i'm very curious to know, only dlls injected with setwindowshookex calls this this pointer at this table(peb->kcall)? that's amazing :shock:

[EP_X0FF]

i'm very impressed, i'd not imagine to find such a table like this in usermode even in a million years, thanks guys :twisted:

But i'm very curious to know, only dlls injected with setwindowshookex calls this this pointer at this table(peb->kcall)? that's amazing :shock:

This is some sort of very old trick, IIRC I saw it in 2006 in some AV. However callback indexes are subject of change so you need to build index table for all actual NT versions.

[listito]

i'm very impressed, i'd not imagine to find such a table like this in usermode even in a million years, thanks guys :twisted:

But i'm very curious to know, only dlls injected with setwindowshookex calls this this pointer at this table(peb->kcall)? that's amazing :shock:

This is some sort of very old trick, IIRC I saw it in 2006 in some AV. However callback indexes are subject of change so you need to build index table for all actual NT versions.

actual nt versions you mean 6.1(windows 7)?

Great, i have one question EP_X0FF, what's the best method to prevent dll injection from ring0? Installing a notify routine woud be a good idea?

[EP_X0FF]

I mean Windows that are still supported.

what's the best method to prevent dll injection from ring0

You mean injection from driver? Or driver to prevent injection?

[listito]

my driver preventing any kind of injection

so winxp sp1 and sp2 can have diferent callback indexes? damn :(

There's another thing, when i overwrite the callback clientloadlibrary, at the moment it is called the dll string is located at [esi+1c], can this index change from diferent versions of ntdll.dll?