Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
Nim_DInvoke — Implémentation de D/Invoke en Nim | Kitploit
Outils/GitHubGitHub/s3cur3th1ssh1t/nim_dinvoke
Post-ExploitationRed TeamingDéveloppement de Charges UtilesAttaque Adversariale
GitHubs3cur3th1ssh1t/nim_dinvoke

Nim_DInvoke

Implémentation de D/Invoke en Nim

Voir le dépôt
10164il y a 4 ansVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

Nim DInvoke

Implémentation de D/Invoke en Nim

Tous les binaires Nim exposent généralement les mêmes 58 à 60 fonctions de l'API Windows :

alt text

Toutes les autres fonctions de l'API Windows sont généralement résolues à l'exécution via GetProcAddress et LoadLibraryA, comme mentionné dans OffensiveNim ou cet article de blog.

Il n'est donc pas possible de masquer (complètement) les imports d'API via DInvoke en Nim, à moins que quelqu'un utilise par exemple cette implémentation de DInvoke pour modifier le compilateur Nim afin d'utiliser DInvoke au lieu de Dynlib.

Analyser manuellement les fonctions depuis le PEB au lieu d'utiliser GetProcAddress et LoadLibraryA reste plus furtif que le comportement par défaut de Nim. Pour éviter également le hooking inline, un mapping manuel d'une copie fraîche de DLL serait par exemple nécessaire, comme mentionné dans l'article de blog de TheWover sur DInvoke :

alt text

Ceci n'est - toutefois - pas implémenté ici pour l'instant. J'utilise actuellement uniquement pour charger de nouvelles DLL en mémoire.

Télécharger l’outil
LdrLoadDll

Ce projet a été fortement inspiré par le code D/Invoke de NanoDump.

La fonction peut ensuite être utilisée comme ceci :

root@kitploit:~
const
  KERNEL32_DLL* = "kernel32.dll"
const
  OpenProcess_FuncName * = "OpenProcess"
type
  OpenProcess_t* = proc (dwDesiredAccess: DWORD, bInheritHandle: WINBOOL, dwProcessId: DWORD): HANDLE {.stdcall.}

MyOpenProcess = cast[OpenProcess_t](cast[LPVOID](get_function_address(cast[HMODULE](get_library_address(KERNEL32_DLL, FALSE)), OpenProcess_FuncName, 0)))

echo "[*] Calling OpenProcess via D/Invoke"
let pHandle = MyOpenProcess(
    PROCESS_ALL_ACCESS, 
    false, 
    cast[DWORD](https://github.com/s3cur3th1ssh1t/nim_dinvoke/blob/main/processID)
)

Lors de mes tests, j'ai rencontré des comportements étranges pour certaines fonctions de l'API, qui nécessitent des cas particuliers pour trouver la bonne adresse relative. Ma confusion est visible dans les commentaires. C'est peut-être aussi simplement mon style de code minable - qui sait.

L'exemple, une fois réussi, ressemble à ceci :

alt text