print3m/dllshimmerArma facilmente il DLL hijacking. Inserisci una backdoor in qualsiasi funzione di qualsiasi DLL.
DllShimmer analizza la DLL originale ed estrae informazioni sulle funzioni esportate (nome, numero ordinale e informazioni sul forwarder). Sulla base di queste informazioni, DllShimmer crea un file C++ boilerplate (.cpp). Il file generato consente di aggiungere il proprio codice a ogni funzione esportata dalla DLL originale senza interrompere il normale funzionamento del programma. Non è richiesto alcun reverse engineering o strumentazione, perché DllShimmer non si basa sulle firme delle funzioni (vedi maggiori dettagli in “Limitazioni”).
Il secondo file generato è un file .def, che garantisce che tutte le DLL esportate dal proxy dopo la compilazione abbiano gli stessi nomi e numeri ordinali della DLL originale.
Dopo la compilazione, l'EAT nella DLL proxy è una copia esatta dell'EAT nella DLL originale. Tutti i nomi e i numeri ordinali delle funzioni esportate corrispondono e anche le funzioni inoltrate vengono inoltrate. DllShimmer non inoltra esplicitamente tutte le funzioni (come fanno la maggior parte degli strumenti), creando una struttura EAT completamente nuova e sospetta.
Compila il codice sorgente Go oppure scarica il binario compilato.
Dipendenze:
x86_64-w64-mingw32-g++x86_64-w64-mingw32-dlltoolEsempio:
# Backdoor version.dll (proxy to absolute path)
./DllShimmer -i version.dll -o project/ -x "C:/Windows/System32/version.dll" -m
# Backdoor random chat.dll (proxy to relative path)
./DllShimmer -i chat.dll -o project/ -x "lib/chat2.dll" -m
# Backdoor random app.dll (static linking to the original DLL)
./DllShimmer -i app.dll -o project/ -x "app2.dll" -m --static
Parametri:
-i / --input <path> [richiesto]
La DLL originale a cui vuoi aggiungere la backdoor.
-o / --output <path> [richiesto]
Il percorso della directory in cui DllShimmer salverà tutti i file generati.
-x / --original <path> [richiesto]
In caso di collegamento dinamico (predefinito), fornisci il percorso in cui la DLL proxy troverà la DLL originale sul sistema di destinazione.
In caso di collegamento statico (--static), specifica solo il nome della DLL originale. Verrà cercata secondo l'ordine di caricamento predefinito di Windows.
-m / --mutex [facoltativo]
L'attivazione di questa opzione aggiunge un mutex al file sorgente, che impedisce che la tua backdoor venga eseguita più di una volta durante una singola esecuzione del programma. Tutte le funzioni originali continueranno a funzionare normalmente.
--static [facoltativo]
Abilita il collegamento statico tra la DLL proxy (IAT) e la DLL originale (EAT). Questo genera un file .lib aggiuntivo nella directory di output, che funge da DLL originale per la compilazione statica.
Questa tecnica presenta alcune importanti limitazioni rispetto al collegamento dinamico:
Tuttavia, il collegamento statico può essere più furtivo e naturale in alcuni scenari.
Predefinito: DllShimmer usa sempre il collegamento dinamico con le funzioni LoadLibraryA() e GetProcAddress().
--debug-file <path> [facoltativo]
Salva i log di debug in un file. I log vengono scritti in un file in modo continuo mentre il programma è in esecuzione. Se selezionata, i log non vengono stampati su STDOUT.
Predefinito: DllShimmer scrive sempre i log di debug su STDOUT.
Esempio di output di debug:
Prima di iniziare la risoluzione dei problemi:
--static). È più facile fare debug con il collegamento dinamico (predefinito).--debug-file)..cpp generato non vedo tutte le funzioni esportate dalla DLL originale.Le funzioni definite nella DLL originale come “inoltrate” (forwarded) non sono incluse nel file .cpp. Tuttavia, sono visibili nel file .def. Verranno esportate anche dopo la compilazione, esattamente come nella DLL originale.
A volte, la tua DLL proxy mostra un errore durante il caricamento della DLL originale e il codice di errore è 126, anche se in teoria hai specificato il percorso relativo corretto nel parametro -x. Perché non funziona?!?
Le DLL vengono cercate nella Current Directory. Nel 98% dei casi, questa è semplicemente la posizione del file EXE principale, ma ci sono programmi (per lo più vecchi legacy) che cambiano arbitrariamente la Current Directory usando, ad esempio, SetCurrentDirectoryW(). Il programma principale è a conoscenza di questa modifica, quindi carica correttamente la tua DLL proxy, ma tu non ne sei a conoscenza e provi a caricare la DLL originale in modo relativo, mentre il programma la cerca nella Current Directory modificata.
Questa regola vale sia per il caricamento statico che dinamico della DLL originale. Purtroppo, con il collegamento statico, questo problema è molto più difficile da individuare perché non abbiamo informazioni di debug. Il loader di sistema fallisce e basta. Questo è il motivo per cui consiglio sempre di usare prima il collegamento dinamico predefinito.
Nel caso del collegamento dinamico, abbiamo due opzioni:
-x alla nuova situazione della Current Directory.Current Directory per cercare le DLL dove vogliamo.In caso di collegamento statico, abbiamo davvero una sola opzione:
Current Directory.