Info on TEB->TlsLinks?

[Kayaker]

I'm trying to find some information on how/when TEB->TlsLinks is made use of.

TEB->TlsSlots is used with TlsSetValue and TlsGetValue, but I'm unsure how TEB->TlsLinks LIST_ENTRY is associated. This is unrelated to TLS Callbacks that are sometimes written into the PE header, (as far as I know).

Some overview on TLS here

Thread Local Storage, part 1: Overview
Thread Local Storage, part 2: Explicit TLS
http://www.nynaeve.net/?p=180
http://www.nynaeve.net/?p=181

There's an implementation here that shows "walking" the linked list entry to parse the TlsLinks member.

https://www.winehq.org/pipermail/wine-d ... 35126.html

These are the related TEB structures:

Code: Select all

dx -r2 @$curthread.Environment
@$curthread.Environment                
    EnvironmentBlock [Type: _TEB]
        [+0x000] NtTib            [Type: _NT_TIB]
        ...
        [+0x02c] ThreadLocalStoragePointer : 0xa0e6c8 [Type: void *]
        ...
        [+0xe10] [color=#0000ff][B]TlsSlots         [/B][/color][Type: void * [64]]
        [+0xf10] [color=#0000ff][B]TlsLinks         [/B][/color][Type: _LIST_ENTRY]
        ...
        [+0xf94] TlsExpansionSlots : 0x0 [Type: void * *]
 

If an app makes use of TlsSetValue / TlsGetValue, you can click on the Windbg DML link for TlsSlots to print out the associated array:

Code: Select all

   
0:000> dx -r1 (*((ntdll!void * (*)[64])0x2c9e10))
(*((ntdll!void * (*)[64])0x2c9e10))                 [Type: void * [64]]
    [4]              : 0xa077b0 [Type: void *]
    ...
    [36]             : 0x2c605c8 [Type: void *]
    [37]             : 0x2c64320 [Type: void *]
    ...
    [63]             : 0x0 [Type: void *]

In this case there are 3 pointer values that have been set by the app through TlsSetValue. The first is I believe is set on initialization from the C++ __getptd function, which is used by _rand(). (As a side note, I read of malware using __getptd() to get the current Thread Id.).

TlsSetValue() - Stores a value in the calling thread's thread local storage (TLS) slot for the specified TLS index. Each thread of a process has its own slot for each TLS index.


The other 2 values (TlsSlot index 0x24 / 0x25) are pointers to memory allocations that the app uses to store/retrieve stack values (all registers/eflags) that it uses to covertly return to different function addresses that can't be discerned from the static disassembly. It's interesting how the app uses the TlsSlots to add a layer of obfuscation for passing around variables, rather than simply using a global variable. In any case, watching these stack related memory allocations move through TlsGetValue/TlsSetValue is a way of monitoring a bit what the program is doing.


Back to the original question, while looking at the TEB I noticed that the TEB->TlsLinks member is empty, in any thread I've looked at. I'm curious now what the _LIST_ENTRY is supposed to point to, and how it might be used. In code, LIST_ENTRY is used as a member of a structure and accessed using CONTAINING_RECORD.

Code: Select all

0:000> dx -r1 (*((ntdll!_LIST_ENTRY *)0x2c9f10))
(*((ntdll!_LIST_ENTRY *)0x2c9f10))                 [Type: _LIST_ENTRY]
    [+0x000] Flink            : 0x0 [Type: _LIST_ENTRY *]
    [+0x004] Blink            : 0x0 [Type: _LIST_ENTRY *]

Being stored in the TEB, what linked list of structures might TlsLinks point to, and when might it be active?

[Kayaker]

Hmm, it's possible TlsLinks is related to the TLS Callback array / IMAGE_TLS_DIRECTORY

https://doxygen.reactos.org/dd/d83/ntdl ... ource.html
https://doxygen.reactos.org/d8/d6b/ldri ... ource.html

I'll have to remember how to create Tls Callbacks or find an app that uses them to check it out.

EDIT: Seems not to be directly tied to Tls Callbacks, some other usage of Tls then, likely __declspec(thread) thread local variables.

[WaxfordSqueers]

I'm trying to find some information on how/when TEB->TlsLinks is made use of.

You're not alone, even Geoff Chappel doesn't know.

https://www.geoffchappell.com/studies/windows/win32/ntdll/structs/teb/index.htm

"The TlsLinks member presumably is defined in all versions, but I don’t know how it’s used in any version".

[WaxfordSqueers]

Kayaker...probably not much help but maybe a light will go on for you. Is TlsLinks possibly an entry into a linked list? They have two TEB Tls-related structures available, as far as I understand, a basic list of 64 entries and a further structure of 1024 entries if required.

If you look here, you see TlsLinks referenced and it claims to be defined in compat.h at line 537.

https://doxygen.reactos.org/de/dd0/struct__TEB.html#a66eac0db6b83fa4f64ad3535c5853fc1

The reference for compat.h is here:

https://doxygen.reactos.org/d5/db1/dll_2win32_2dbghelp_2compat_8h_source.html

Line 538 reads: LIST_ENTRY TlsLinks;

The hyperlink of LIST_ENTRY leads to this page:

https://doxygen.reactos.org/d9/da7/struct__LIST__ENTRY.html

The following link is not of much general use it points to an online book. However, on pages 61/612, under the heading ActiveProcessLinks, it makes a direct reference to typedef struct _LIST_ENTRY. This is with reference to EPROCESS as related to rootkits. The paragraph begins..."Windows uses a circular doubly-linked list of EPROCESS structures...

Seems to me the 'link' in TlsLinks may be related to a similar list.

https://books.google.ca/books?id=EjtB6RmPsS4C&pg=PA612&lpg=PA612&dq=flink+blink&source=bl&ots=erSjh08lQ2&sig=ACfU3U0ppQKUlIcIH3QbxQ5VtJpKP5Q8_g&hl=en&sa=X&ved=2ahUKEwjt1Or61cbqAhU8FTQIHa05AoAQ6AEwH3oECGQQAQ#v=onepage&q=flink%20blink&f=false

[Kayaker]

Seems to me the 'link' in TlsLinks may be related to a similar list.

That was my conclusion too.

This is the only place I found a specific mention of the purpose of TlsLinks

At offset 0x02c, the ThreadLocalStoragePointer field is the linear address of the thread local storage array, the address can be accessed with the use of a pointer as known in the output above. Note that the TEB is stored within the FS segment register on x86, and the GS segment register on x64. The segment registers are primarily used for performance reasons.

The TlsSlots at offset 0xe10, shows the current number of TLS slots, the minimum number of slots is 64, thus the reason for the [64]. Each slot is indexed starting 0, and is accessed with this index, this is implemented as a array with a pointer to access each slot. The TlsLinks at offset 0xf10, is a doubly linked list of the TLS memory blocks for the process.

http://bsodtutorials.blogspot.com/2014/ ... slots.html


Using Thread Local Storage seems to be a fairly deliberate choice by the programmer, such as this app I'm analyzing that contains a lot of code obfuscation techniques, including TLS. I thought that being aware of things like that by simply looking at the TEB fields would be useful for reversing.

[WaxfordSqueers]

Using Thread Local Storage seems to be a fairly deliberate choice by the programmer, such as this app I'm analyzing that contains a lot of code obfuscation techniques, including TLS. I thought that being aware of things like that by simply looking at the TEB fields would be useful for reversing.

The book to which I linked on rootkits seems to be getting into the same idea. From what I gathered by skimming it, they use the TEB to hide their activity. Since Tls is related to thread storage I imagine they write the rootkit to fiddle the Tls somehow. I wonder if they can hide or obfuscate threads somehow?