Log in

View Full Version : TLSGetValue

sarge
August 22nd, 2004, 17:16
Help! I'm trying to understand the usage of TLSGetValue, for RE purposes of course. I have read the MS docs and done the Google thing. I have earned what the prototype declaration is, and I understand the English of the explanation. But all the resources I have searched (I gave up after about the first 50 of a-bazillion-or-so on Google), parrot the same explanation the MS gives. My question is simple...what data is at the pointer (for a specific index) in that array? Is there any specific required stuff that MUST be there, or is a thread free to just use that memory for any data storage it desires?

I'll be happy to study, if someone knows the source of a better, cleaner explanation than the MS pap. I suspect I can take the more tedious path and find the matching TLSSetValue for that same index, and determine the hard way what was put there, but that's going to be a lot of effort if I have to do that for each TLSGetValue I want to examine.

Any (easy) ideas?

Thanks all
Sarge
0rp
August 23rd, 2004, 04:29
TLSGetValue returns an application defined DWORD

you can use TLSSetValue to set this value to what ever you want
and even if every thread uses the same index value, it get its very own DWORD value back

it is also possible, to declare a var with __declspec(thread), wich results in the same behavior, but funny things will happen, if you use this in a DLL and load the DLL with LoadLibrary
omega_red
August 23rd, 2004, 04:54
TLS is an area in TEB (thread environment block):

Code:
...

/*C00*/  UCHAR StaticUnicodeBuffer[0x20C];

/*E0C*/  ULONG DeallocationStack;

/*E10*/  UCHAR TlsSlots[0x100];   // <-- TLS

/*F10*/  LARGE_INTEGER TlsLinks;

/*F18*/  ULONG Vdm;

...

So you can access it like:

Code:


mov eax, value

mov fs:[0xe10 + offset], eax

Actually, I've noticed that TLS is defined as a byte array, not dword array (at least in my nt4.h
sarge
August 23rd, 2004, 07:46
Thanks. I really didn't expect the answer to be something simple, like, "it's a pointer to a string", "it's a pointer to an object", "it's the infinite value of PI", but I guess :

"TLSGetValue returns an application defined DWORD"

says it all.

Thanks, both

Sarge
sna
August 23rd, 2004, 17:17
Hi.

Trying to bypass TlsGetValue isn't all that bright. Especially when the implementation or offsets for TLS differs depending on what platform your code is ran on. If you were to disassemble TlsGetValue on Win9x you'd see this, or a variation thereof:

Code:


mov   ecx, dword ptr [esp+04]                // dwTlsIndex

mov   edx, dword ptr fs:[00000018]           // ptr TEB

cmp   ecx, 00000040

jnb   BFF92B2E

mov   eax, dword ptr [edx+4*ecx+00000088]    // lpTlsValue

...
The lesson to be learned here is that you should always stick to the documented interfaces!

Regards, sna
JMI
August 23rd, 2004, 18:31
Especially if one wants to avoid unforseen difficulties.

Regards,
sarge
August 24th, 2004, 09:31
Well, the real question is/was what the final pointer represents. I suspect, from my examination of my target proggie, that it is a pointer to an object. But I wasn't sure that, that would fit the usage/definition of TLSGetValue. Thus, my question was in reference to the then unknown proper usage. It appears that having an object pointer as a return value is perfectly fine.

Thanks

Sarge