[madaboo]

Hi,

Let's assume I've made a hook on NtCreateFile.
Now user-mode process A is performing file creation and after switch to kernel-mode my hook is called.
My question here is - is it safe assumption that inside my hooked NtCreateFile I'm in context of thread that is calling createFile?
If no, then how can I know that... how can I know what process/thread is source of this call?

Thank you!

[Brock]

Output result of calls to PsGetCurrentThreadId and PsGetCurrentProcessId in your hook callback function, answer is rather clear from there ;)

[Dmitry Varshavsky]

Hi,

Let's assume I've made a hook on NtCreateFile.
Now user-mode process A is performing file creation and after switch to kernel-mode my hook is called.
My question here is - is it safe assumption that inside my hooked NtCreateFile I'm in context of thread that is calling createFile?
If no, then how can I know that... how can I know what process/thread is source of this call?

Thank you!

Sure you will be in the context of calling thread.

[everdox]

I think he perhaps assuming that different thread is dispatching his system call. The answer is no, it is same thread just raised to supervisor level.

[Brock]

He asked if the caller of CreateFileA/W/NtCreateFile is within the same thread context in kernel mode as usermode, nothing hard to understand here. Please see my above comment

[R00tKit]

read this for more info :
http://www.osronline.com/article.cfm?id=168

[Kiuhnm]

read this for more info :
http://www.osronline.com/article.cfm?id=168

IMHO that article is not very clear. It says

When a thread from a user process is executing, it’s virtual addresses will range from 0 to 2GB, and all addresses above 2GB will be set to "no access", preventing direct user access to operating system code and structures. When the operating system code is executing, its virtual addresses range from 2-4GB, and the current user process (if there is one) is mapped into the addresses between 0 and 2GB.

One might mistakenly assume that when kernel code is invoked there is some kind of switching or memory mapping.
This misconception is strengthened by the following passage:

In addition to the above, in NT’s specific arrangement of virtual memory, a given valid user virtual address X within process P (where X is less than or equal to 2GB) will correspond to the same physical memory location as kernel virtual address X. This is true, of course, only when process P is the current process and (therefore) process P’s physical pages are mapped into the operating system’s low 2GB of virtual addresses. Another way of expressing this last sentence is, "This is true only when P is the current process context." So, user virtual addresses and kernel virtual addresses up to 2GB refer to the same physical locations, given the same process context.

There are no "user virtual addresses" or "kernel virtual addresses". Virtual addresses are just virtual addresses. Figure 1 suffers from the same problem.