I'm working on a function to extract information about a thread and would like to know more specifically when calling the CreateThread function, the created thread insert "dwCreationFlags" parameter somewhere in ETHREAD structure
Since these flags only affect thread creation, there is no need to keep them once the thread exists. So no, they are not kept in the ETHREAD.
Related
i was wondering if anyone knows where the context of a thread running in usermode is stored in kernel ? and if there are any API's for dealing with getting and setting a usermode thread context ? i know that you should not be doing this for any reason, so please do not sidetrack into that. This is solely for the sake of research and will not be used by anything else than local projects of my own.
In usermode we have GetThreadContext and SetThreadContext, but i need to do this from a device driver in the kernel, i wish i had more to write but i can't find any information on this topic at all so i wish someone more educated than me can enlighten me on some of the windows internals at hand here.
Regards Paze.
when thread enter in kernel mode it context stored in it kernel stack, in struct _KTRAP_FRAME - it declared in ntdkk.h. in ntoskrnl.exe (all versions from win2000 up to win10) exist exported api
NTKERNELAPI
NTSTATUS
NTAPI
PsGetContextThread(
__in PETHREAD Thread,
__inout PCONTEXT ThreadContext,
__in KPROCESSOR_MODE Mode
);
you can use it for get thread context (and PsSetContextThread for set thread context).
about how this work - look in wrk - when you try get/set context from another thread special kernel mode APC is inserted to this thread with pointer to internal GETSETCONTEXT structure, after this requestor begin wait on event (OperationComplete) from this structure. when thread (for which we query context) next time begin execute in kernel - APC routine (PspGetSetContextSpecialApc) is executed - it fill context from _KTRAP_FRAME and set event (OperationComplete)
Is it possible (and how) to access Thread Information Block of a thread of some another process?
It is possible.
The first step is to get the adress of the Thread Information Block by using the NtQueryInformationThread function with ThreadInformationClass set to ThreadBasicInformation. The THREAD_BASIC_INFORMATION structure contains a pointer to the TEB of the thread. Then you can use ReadProcessMemory and WriteProcessMemory in order to read or modify the content of the TEB.
I need to do it this way because I am in DllMain() therefore, loader lock is held. I've read that GetModuleHandle() also uses the loader lock [page #6] which would result in deadlock.
How could GetModuleHandle() implemented? Some code would be a plus.
Update: Since I am using SetWindowsHookEx on WinXP only. Just going to take advice in the comments, go the easy way, and use GetModuleHandle() the first time the callback gets called.
You can call GetModuleHandle from DllMain. It doesn't load any libraries and doesn't increment module reference count. Other story is with LoadLibrary. Never call it from DllMain.
What is the difference between a thread ID and a thread handle? Why both are needed? Is there a difference between Windows and Linux?
Linux's pthread library does not, as far as I know, have a concept of a thread handle. pthread_create and other pthreads functions, return a thread ID.
Under Windows, the thread handle is different from the thread ID, in the same way that a file handle is different from a file name.
The thread handle is a token which allows you to do something with the thread (typically wait for it or kill it). Win32 has these tokens for lots of objects, and calls them HANDLE in general.
The token is essentially a pointer at the running (or stopped) thread and has a set of abilities associated with it, for example, you can have a handle which permits you to wait for, but not kill, a thread. In the same way, we can have a file handle which is read-only.
This level of indirection may or may not be useful, but it's the way Win32 does it, and it's broadly consistent with how it handles some other types of objects.
The ID is the unique numeric identifier of the thread running in the system. A thread handle, like any kernel object handle, can be seen as a special type of reference counted pointer to the kernel object.
So in kernel space there is an object of type THREAD with ID = 12345
And because you want to do something with the thread you have a pointer in your address space called a threadID with value 44.
Please note that different handles to the same kernel object have different values (two pointers to one object) and that kernel objects can have handles in more than one process.
Thread IDs are progressive (ie, one after another), which you can traverse.
Thread handles, like most handles in Windows, are actually pointers.
You might, for example, set thread property bits by using the thread handle - but not thread id.
What does CreateRemoteThread do to actually create the remote thread?
Inside the kernel, the lowest level thread creation function is really just creating a thread object, connecting it to a process and making it runnable. CreateThread and CreateRemoteThread are really the same API and work the same way, the only difference being that CreateThread only allows you to create a thread in the current process while CreateRemoteThread allows you to specify a process to create a thread in.
This means that CreateThread is pretty much the same as CreateRemoteThread(GetCurrentProcess(), ....)
It calls NtCreateThreadEx, which is a kernel call.