print3m/dllshimmerWeaponisez facilement le détournement de DLL. Installez une porte dérobée dans n'importe quelle fonction de n'importe quelle DLL.
DllShimmer analyse la DLL d'origine et extrait des informations sur les fonctions exportées (nom, numéro ordinal et informations de forwarder). Sur la base de ces informations, DllShimmer crée un fichier C++ générique (.cpp). Le fichier généré vous permet d'ajouter votre propre code à chaque fonction exportée par la DLL d'origine sans perturber le fonctionnement normal du programme. Aucune rétro-ingénierie ni instrumentation n'est requise, car DllShimmer ne repose pas sur les signatures de fonctions (voir plus dans « Limitations »).
Le deuxième fichier généré est un fichier .def, qui garantit que toutes les DLL exportées par le proxy après compilation auront les mêmes noms et numéros ordinaux que dans la DLL d'origine.
Après compilation, l'EAT de la DLL proxy est une copie exacte de l'EAT de la DLL d'origine. Tous les noms et numéros ordinaux des fonctions exportées correspondent, et les fonctions redirigées (forwarders) le sont également. DllShimmer ne redirige pas explicitement toutes les fonctions (comme la plupart des outils), créant ainsi une structure EAT entièrement nouvelle et suspecte.
Compilez le code source Go ou téléchargez le binaire compilé.
Dépendances :
x86_64-w64-mingw32-g++x86_64-w64-mingw32-dlltoolExemple :
# 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
Paramètres :
-i / --input <path> [obligatoire]
La DLL d'origine que vous souhaitez backdoorer.
-o / --output <path> [obligatoire]
Le chemin vers le répertoire où DllShimmer enregistrera tous les fichiers générés.
-x / --original <path> [obligatoire]
En cas de liaison dynamique (par défaut), fournissez le chemin où la DLL proxy trouvera la DLL d'origine sur le système cible.
En cas de liaison statique (--static), spécifiez uniquement le nom de la DLL d'origine. Elle sera recherchée selon l'ordre de chargement par défaut de Windows.
-m / --mutex [optionnel]
L'activation de cette option ajoute un mutex au fichier source, ce qui empêche votre backdoor d'être exécutée plus d'une fois lors d'une seule exécution du programme. Toutes les fonctions d'origine continueront de fonctionner normalement.
--static [optionnel]
Active la liaison statique entre la DLL proxy (IAT) et la DLL d'origine (EAT). Cela génère un fichier .lib supplémentaire dans le répertoire de sortie, qui agit comme la DLL d'origine pour la compilation statique.
Cette technique présente de sérieuses limitations par rapport à la liaison dynamique :
Cependant, la liaison statique peut être plus furtive et plus naturelle dans certains scénarios.
Par défaut : DllShimmer utilise toujours la liaison dynamique avec les fonctions LoadLibraryA() et GetProcAddress().
--debug-file <path> [optionnel]
Enregistre les journaux de débogage dans un fichier. Les journaux sont écrits dans un fichier en continu pendant l'exécution du programme. Si cette option est sélectionnée, les journaux ne sont pas affichés sur STDOUT.
Par défaut : DllShimmer écrit toujours les journaux de débogage sur STDOUT.
Exemple de sortie de débogage :
Avant de commencer le dépannage :
--static). Il est plus facile de déboguer avec la liaison dynamique (par défaut).--debug-file)..cpp généré, je ne vois pas toutes les fonctions exportées de la DLL d'origine.Les fonctions définies comme « redirigées » (forwarded) dans la DLL d'origine ne sont pas incluses dans le fichier .cpp. Cependant, elles sont visibles dans le fichier .def. Elles seront également exportées après compilation, exactement comme dans la DLL d'origine.
Parfois, votre DLL proxy affiche une erreur lors du chargement de la DLL d'origine, avec le code d'erreur 126, même si vous avez théoriquement spécifié le chemin relatif correct dans le paramètre -x. Pourquoi cela ne fonctionne-t-il pas ?!?
Les DLL sont recherchées dans le Current Directory. Dans 98 % des cas, il s'agit simplement de l'emplacement du fichier EXE principal, mais certains programmes (principalement d'anciens programmes hérités) modifient arbitrairement le Current Directory en utilisant, par exemple, SetCurrentDirectoryW(). Le programme principal a connaissance de ce changement, il charge donc correctement votre DLL proxy, mais vous n'en avez pas connaissance et vous essayez de charger la DLL d'origine de manière relative, alors que le programme la recherche dans le Current Directory modifié.
Cette règle s'applique à la fois au chargement statique et dynamique de la DLL d'origine. Malheureusement, avec la liaison statique, ce problème est beaucoup plus difficile à détecter, car nous ne disposons pas d'informations de débogage. Le chargeur système échoue simplement et c'est tout. C'est pourquoi je recommande toujours d'utiliser d'abord la liaison dynamique par défaut.
En cas de liaison dynamique, nous avons deux options :
-x à la nouvelle situation du Current Directory.Current Directory pour rechercher les DLL là où nous le souhaitons.En cas de liaison statique, nous n'avons vraiment qu'une seule option :
Current Directory.