Non ho mai visto i dati TLS essere "eseguiti" prima, tuttavia, nel caso di un PE caricato in modo non dinamico, la sezione .tls viene caricata prima dell'esecuzione del punto di ingresso. Gli slot TLS vengono inoltre inizializzati dal caricatore prima che venga chiamato il punto di ingresso. TLS e FLS possono essere entrambi utilizzati dal malware per creare nell'archivio di memoria che è leggermente più difficile da ispezionare durante il runtime.
Se sai che il malware sta leggendo / scrivendo TLS / FLS, potresti presumibilmente inserire un punto di interruzione hardware nella memoria utilizzata per TLS / FLS. Quando il malware legge / scrive quella memoria, il debugger dovrebbe interrompersi e sarete in grado di ispezionare lo stato del processo mentre il debugger è interrotto. Immagino che questo potrebbe essere utile se il malware è stato pesantemente offuscato ed è stato difficile tracciare il flusso di controllo del malware.
Inoltre, se il malware sta memorizzando il codice eseguibile nelle sezioni TLS, è possibile scrivere un 0x3C (int3) nel primo byte del codice, che causerebbe l'interruzione del debugger se / quando il codice è stato eseguito.
TLS viene in genere utilizzato in due modi. Innanzitutto, è utilizzare le funzioni tls (TlsAlloc, TlsSetValue, TlsGetValue, TlsFree ecc.). Il secondo sarebbe definire le variabili locali del thread con __declspec(thread)
, che aggiungerebbe una sezione .tls con il valore inizializzato al file PE compilato (che dovrebbe essere un exe, non una dll se si utilizza __declspec(thread)
). FLS è disponibile solo tramite le funzioni Fls *, non c'è __declspec(fiber)
a mia conoscenza.
Non c'è nulla di intrinsecamente dannoso su TLS o FLS, ma sono utilizzati da alcune forme di malware nel tentativo di nascondere i dati dall'analisi.