Lavori in una azienda di sicurezza informatica? Vuoi vedere la tua azienda pubblicizzata su HackTricks? o vuoi avere accesso all'ultima versione del PEASS o scaricare HackTricks in PDF? Controlla i PIANI DI ABBONAMENTO!
Il programma precedente ha 9 intestazioni di programma, quindi, il mapping dei segmenti indica in quale intestazione di programma (da 00 a 08) è situata ciascuna sezione.
PHDR - Program HeaDeR
Contiene le tabelle delle intestazioni di programma e i metadati stessi.
INTERP
Indica il percorso del loader da utilizzare per caricare il binario in memoria.
LOAD
Queste intestazioni vengono utilizzate per indicare come caricare un binario in memoria.
Ogni intestazione LOAD indica una regione di memoria (dimensione, autorizzazioni e allineamento) e indica i byte dell'ELF da copiare lì dentro.
Ad esempio, la seconda ha una dimensione di 0x1190, dovrebbe essere situata a 0x1fc48 con autorizzazioni di lettura e scrittura e verrà riempita con 0x528 dall'offset 0xfc48 (non riempie tutto lo spazio riservato). Questa memoria conterrà le sezioni .init_array .fini_array .dynamic .got .data .bss.
DYNAMIC
Questa intestazione aiuta a collegare i programmi alle loro dipendenze delle librerie e applicare le rilocazioni. Controlla la sezione .dynamic.
NOTE
Memorizza informazioni sui metadati del fornitore relativi al binario.
GNU_EH_FRAME
Definisce la posizione delle tabelle di unwind dello stack, utilizzate dai debugger e dalle funzioni di runtime per la gestione delle eccezioni C++.
GNU_STACK
Contiene la configurazione della difesa di prevenzione dell'esecuzione dello stack. Se abilitato, il binario non potrà eseguire codice dallo stack.
GNU_RELRO
Indica la configurazione RELRO (Relocation Read-Only) del binario. Questa protezione contrassegnerà come sola lettura alcune sezioni della memoria (come il GOT o le tabelle init e fini) dopo che il programma è stato caricato e prima che inizi ad eseguirsi.
Nell'esempio precedente, sta copiando 0x3b8 byte a 0x1fc48 come sola lettura, influenzando le sezioni .init_array .fini_array .dynamic .got .data .bss.
Si noti che RELRO può essere parziale o completo, la versione parziale non protegge la sezione .plt.got, che viene utilizzata per il lazy binding e ha bisogno che questo spazio di memoria abbia autorizzazioni di scrittura per scrivere l'indirizzo delle librerie la prima volta che ne viene cercata la posizione.
TLS
Definisce una tabella di voci TLS, che memorizza informazioni sulle variabili locali al thread.
Intestazioni delle Sezioni
Le intestazioni delle sezioni forniscono una visione più dettagliata del binario ELF.
Tabella delle stringhe: Contiene tutte le stringhe necessarie per il file ELF (ma non quelle effettivamente utilizzate dal programma). Ad esempio, contiene nomi di sezioni come .text o .data. E se .text si trova all'offset 45 nella tabella delle stringhe, utilizzerà il numero 45 nel campo name.
Per trovare dove si trova la tabella delle stringhe, l'ELF contiene un puntatore alla tabella delle stringhe.
Tabella dei simboli: Contiene informazioni sui simboli come il nome (offset nella tabella delle stringhe), l'indirizzo, la dimensione e altri metadati sul simbolo.
Sezioni Principali
.text: Le istruzioni del programma da eseguire.
.data: Variabili globali con un valore definito nel programma.
.bss: Variabili globali non inizializzate (o inizializzate a zero). Le variabili qui vengono automaticamente inizializzate a zero, evitando così l'aggiunta di zeri inutili al binario.
.rodata: Costanti variabili globali (sezione in sola lettura).
.tdata e .tbss: Simili a .data e .bss quando vengono utilizzate variabili locali al thread (__thread_local in C++ o __thread in C).
.dynamic: Vedi sotto.
Simboli
I simboli sono posizioni denominate nel programma che potrebbero essere una funzione, un oggetto dati globale, variabili locali al thread...
readelf -s lnstat
Symbol table '.dynsym' contains 49 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000001088 0 SECTION LOCAL DEFAULT 12 .init
2: 0000000000020000 0 SECTION LOCAL DEFAULT 23 .data
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strtok@GLIBC_2.17 (2)
4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND s[...]@GLIBC_2.17 (2)
5: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strlen@GLIBC_2.17 (2)
6: 0000000000000000 0 FUNC GLOBAL DEFAULT UND fputs@GLIBC_2.17 (2)
7: 0000000000000000 0 FUNC GLOBAL DEFAULT UND exit@GLIBC_2.17 (2)
8: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _[...]@GLIBC_2.34 (3)
9: 0000000000000000 0 FUNC GLOBAL DEFAULT UND perror@GLIBC_2.17 (2)
10: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterT[...]
11: 0000000000000000 0 FUNC WEAK DEFAULT UND _[...]@GLIBC_2.17 (2)
12: 0000000000000000 0 FUNC GLOBAL DEFAULT UND putc@GLIBC_2.17 (2)
[...]
Ogni voce del simbolo contiene:
Nome
Attributi di binding (debole, locale o globale): Un simbolo locale può essere accessibile solo dal programma stesso, mentre i simboli globali sono condivisi al di fuori del programma. Un oggetto debole è ad esempio una funzione che può essere sovrascritta da un'altra.
Tipo: NOTYPE (tipo non specificato), OBJECT (variabile dati globale), FUNC (funzione), SECTION (sezione), FILE (file di codice sorgente per i debugger), TLS (variabile locale al thread), GNU_IFUNC (funzione indiretta per rilocazione)
Il directory NEEDED indica che il programma deve caricare la libreria menzionata per poter continuare. Il directory NEEDED si completa una volta che la libreria condivisa è completamente operativa e pronta per l'uso.
Rilocazioni
Il loader deve anche rilocare le dipendenze dopo averle caricate. Queste rilocazioni sono indicate nella tabella delle rilocazioni nei formati REL o RELA e il numero di rilocazioni è indicato nelle sezioni dinamiche RELSZ o RELASZ.
Se il programma viene caricato in un luogo diverso dall'indirizzo preferito (di solito 0x400000) perché l'indirizzo è già in uso o a causa di ASLR o per qualsiasi altro motivo, una rilocazione statica corregge i puntatori che avevano valori che si aspettavano che il binario fosse caricato nell'indirizzo preferito.
Ad esempio, qualsiasi sezione di tipo R_AARCH64_RELATIV dovrebbe aver modificato l'indirizzo al bias di rilocazione più il valore dell'addendo.
Rilocazioni Dinamiche e GOT
La rilocazione potrebbe anche fare riferimento a un simbolo esterno (come una funzione da una dipendenza). Come la funzione malloc da libC. Quindi, il loader quando carica libC in un indirizzo controllando dove la funzione malloc è caricata, scriverà questo indirizzo nella tabella GOT (Global Offset Table) (indicata nella tabella di rilocazione) dove dovrebbe essere specificato l'indirizzo di malloc.
Tabella di Collegamento delle Procedure
La sezione PLT consente di eseguire il binding pigro, il che significa che la risoluzione della posizione di una funzione verrà eseguita la prima volta che viene accessata.
Quindi quando un programma chiama malloc, in realtà chiama la posizione corrispondente di malloc nella PLT (malloc@plt). La prima volta che viene chiamata, risolve l'indirizzo di malloc e lo memorizza in modo che la prossima volta che viene chiamata malloc, viene utilizzato quell'indirizzo invece del codice PLT.
Inizializzazione del Programma
Dopo che il programma è stato caricato è il momento per farlo funzionare. Tuttavia, il primo codice che viene eseguito non è sempre la funzione main. Questo perché ad esempio in C++ se una variabile globale è un oggetto di una classe, questo oggetto deve essere inizializzatoprima che venga eseguito main, come in:
Nota che queste variabili globali si trovano in .data o .bss, ma nelle liste __CTOR_LIST__ e __DTOR_LIST__ gli oggetti da inizializzare e distruggere sono memorizzati per tenerne traccia.
Dal codice C è possibile ottenere lo stesso risultato utilizzando le estensioni GNU:
__attributte__((constructor)) //Add a constructor to execute before__attributte__((destructor)) //Add to the destructor list
Dal punto di vista del compilatore, per eseguire queste azioni prima e dopo l'esecuzione della funzione main, è possibile creare una funzione init e una funzione fini che verranno referenziate nella sezione dinamica come INIT e FIN e vengono collocate nelle sezioni init e fini dell'ELF.
L'altro opzione, come già menzionato, è referenziare le liste __CTOR_LIST__ e __DTOR_LIST__ negli ingressi INIT_ARRAY e FINI_ARRAY nella sezione dinamica e la lunghezza di queste è indicata da INIT_ARRAYSZ e FINI_ARRAYSZ. Ogni ingresso è un puntatore a funzione che verrà chiamato senza argomenti.
Inoltre, è possibile avere un PREINIT_ARRAY con puntatori che verranno eseguiti prima dei puntatori INIT_ARRAY.
Ordine di Inizializzazione
Il programma viene caricato in memoria, le variabili globali statiche vengono inizializzate in .data e quelle non inizializzate vengono azzerate in .bss.
Tutte le dipendenze del programma o delle librerie vengono inizializzate e viene eseguito il linking dinamico.
Le funzioni PREINIT_ARRAY vengono eseguite.
Le funzioni INIT_ARRAY vengono eseguite.
Se c'è un'entrata INIT viene chiamata.
Se è una libreria, dlopen termina qui, se è un programma, è il momento di chiamare il vero punto di ingresso (funzione main).
Memoria Locale al Thread (TLS)
Sono definite utilizzando la parola chiave __thread_local in C++ o l'estensione GNU __thread.
Ogni thread manterrà una posizione unica per questa variabile in modo che solo il thread possa accedere alla sua variabile.
Quando viene utilizzato, le sezioni .tdata e .tbss vengono utilizzate nell'ELF. Sono simili a .data (inizializzata) e .bss (non inizializzata) ma per TLS.
Ogni variabile avrà un'entrata nell'intestazione TLS che specifica la dimensione e l'offset TLS, che è l'offset che verrà utilizzato nell'area dati locale del thread.
Il __TLS_MODULE_BASE è un simbolo utilizzato per fare riferimento all'indirizzo di base dello storage locale al thread e punta all'area in memoria che contiene tutti i dati locali al thread di un modulo.
