How to access different key in RegisterCallback method.

NTDEV
1

Hello

Currently I’m changing registry hooking method to CmRegisterCallback method.

What should I do to call Registry API, if I need different key information when
Call back function is called, which is registered by CmRegisterCallback?

Until now I backupped the original address value in KeServiceDescriptorTable hooking method.
I would like to know what else way is in CmRegisterCallback.
Something like FltCreateFile() or FltReadFile() in FltFilter manager.

Thanks

2

> What should I do to call Registry API, if I need different key information when

Call back function is called, which is registered by CmRegisterCallback?

Well, the answer to your question seems to be plain obvious. Argument2 of a callback function points to a structure that keeps a pointer to the object’s body. Call ObOpenObjectByPointer() with object pointer in order to get a handle to it, and, at this point, you will be able to use Zw… registry routines with it. Pure and simple

Anton Bassov

3

thanks Anton Bassov

Zwxxx() function has reentrancy probrem.

I do not want to reenter.

Is there any way to call below driver Callback function without reentrancy?

4

> Zwxxx() function has reentrancy probrem

What is the “problem” here???

I do not want to reenter

Why is that???

Is there any way to call below driver Callback function without reentrancy?

In your original post you were asking about calling registry functions from your callback routine in order to get the additional information. Now you are speaking about calling “below driver Callback function”…

Are you sure you know what you want to do???

Anton Bassov

5

These callbacks don’t work like a layered filesystem. As Anton stated: limit
your focus on the parameters that come with the callback. It’s ok to query
different keys during callback, but if this will result into infinite
recursion your design is broken. You may avoid this by double-entry
bookkeeping…which is not a good design, too.

schrieb im Newsbeitrag news:xxxxx@ntdev…
> thanks Anton Bassov
>
> Zwxxx() function has reentrancy probrem.
>
> I do not want to reenter.
>
> Is there any way to call below driver Callback function without
> reentrancy?
>
>
>
>
>

6

In fact you must not cause same thread reentrance here because the callback
driver developer has to be allowed to use the threadid to link pre and post
callbacks. If you want to perform queries you will need to post these to
another thread; and now you know which callbacks to ignore on account of the
threadid.

wrote in message news:xxxxx@ntdev…
>> What should I do to call Registry API, if I need different key
>> information when
>> Call back function is called, which is registered by CmRegisterCallback?
>
>
> Well, the answer to your question seems to be plain obvious. Argument2 of
> a callback function points to a structure that keeps a pointer to the
> object’s body. Call ObOpenObjectByPointer() with object pointer in order
> to get a handle to it, and, at this point, you will be able to use Zw…
> registry routines with it. Pure and simple
>
> Anton Bassov
>

7

Guys,

Actually I still don’t understand what the “problem” with reentrancy is all about - after all, the first callback’s parameter is a pointer to user-defined context that can be used for book-keeping purposes. Furthermore, callback executes at IRQL = PASSIVE_LEVEL( i.e. there is no problem with synchronization whatsoever) and in the context of the thread that is performing the registry operation. What can be possibly “complex” here???

For example, we can define synch event and a thread ID fields in context structure, and do it like:

HANDLE ThreadID=PsGetCurrentThreadId();

if (Context->ThreadId==ThreadID) return STATUS_SUCCESS;

KeWaitForSingleObject(Context->Event,…);

Context->ThreadId=ThreadID;

//do all you calls that may result in reentrant call to our routine…

Context->ThreadId=0;

KetSetEvent(Context->Event,0,FALSE);

What is the “problem” here???

Anton Bassov