Windows current ThreadID without windows API call

I'd like to query the current threadID without making a windowsAPI call.

According to this http://en开发者_如何学编程.wikipedia.org/wiki/Win32_Thread_Information_Block wikipedia article it should be possible to access the thread ID directly. I tried this code:

void* tibPtr;
__asm {
    mov EAX, FS:[0x18]
    mov [tibPtr], EAX
    }
int* ptrToThreadID = (int*)(((char*)tibPtr)+0x24);

as i understand it, dereferencing ptrToThreadID should yeld now everytime the current ThreadID.

however, it gives me a different result than the WinAPI function GetCurrentThreadId() and also the value it points to doesn't change.

What am I doing wrong? I'm compiling for Win32, but running Windows Vista 64bit. Do I need to look for the threadID at another location on 64bit systems?

If you want to see how Windows does it, simply trace into the function - it's already very fast - doesn't cause a mode switch.

However, if you want to avoid even that, you can read the thread id directly out of the TIB at offset 0x24.

C with asm is not my strong suit, but something like:

int threadId;
__asm {
    mov EAX, FS:[0x24]
    mov [threadId], EAX
    }

Something grabbed my attention in your link:

Quote:
It is not common to access the TIB fields by an offset from FS:[0], but rather first getting a linear self-referencing pointer to it stored at FS:[0x18]. That pointer can be used with pointer arithmetics or be cast to a struct pointer.

I'm no assembly expert, but to my understanding, what you're doing at the end is a 0x24 offset from FS:[0x18].
The table in the link says FS:[0x24] is the thread ID, but that's not where you ended up.
If you're going to offset 0x24, then start from 0x00.
Or if you must start from 0x18, then only offset 0x0C, which is the different from 0x18 to land at 0x24.

Am I on the right track here?

Your code works for me. You should use DWORD instead of int since GetCurrentThreadId returns a DWORD.

I believe the implementation of GetCurrentThreadId may be different in x64, even for Win32 applications. For instance, the TIB may be larger, hence the actual offset into the ThreadID field may be bigger than 0x24.

I suggest you run this under debuffer, call the actual function, and see what it does.

This is what the actual function does running a 32-bit app on Windows 2003 64-bit:

mov eax, fs:[$00000018]
mov eax, [eax+$24]
ret

In EAX, you can expect your threadid.