s3cur3th1ssh1t/nim_dinvokeD/Invoke का Nim में कार्यान्वयन
Nim में D/Invoke कार्यान्वयन
सभी Nim बाइनरी आमतौर पर समान 58-60 Windows API फ़ंक्शन उजागर करती हैं:
अन्य सभी Windows API फ़ंक्शन सामान्यतः रनटाइम पर GetProcAddress और LoadLibraryA के माध्यम से रिज़ॉल्व किए जाते हैं, जैसा कि OffensiveNim या इस ब्लॉग पोस्ट में उल्लेख किया गया है।
इसलिए, Nim में DInvoke के माध्यम से API इम्पोर्ट्स को (पूरी तरह से) छिपाना संभव नहीं है, जब तक कि कोई उदाहरण के लिए Dynlib के बजाय DInvoke उपयोग के लिए Nim कंपाइलर को संशोधित करने हेतु इस DInvoke इम्प्लीमेंटेशन का उपयोग न करे।
GetProcAddress और LoadLibraryA का उपयोग करने के बजाय PEB से फ़ंक्शनों को मैन्युअल रूप से पार्स करना डिफ़ॉल्ट Nim व्यवहार की तुलना में अधिक गुप्त (stealthier) है। इनलाइन हुकिंग से बचने के लिए भी, उदाहरण के लिए एक ताज़ा DLL प्रति का मैन्युअल मैपिंग आवश्यक होगी, जैसा कि TheWovers DInvoke ब्लॉग पोस्ट में उल्लेख किया गया है:
हालाँकि, यह यहाँ लागू नहीं किया गया है। मैं वर्तमान में केवल नई DLL को मेमोरी में लोड करने के लिए का उपयोग कर रहा हूँ।
yetLdrLoadDllयह प्रोजेक्ट NanoDump D/Invoke कोड से काफी प्रेरित था।
फ़ंक्शन का उपयोग तब इस प्रकार किया जा सकता है:
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)
)
मेरे परीक्षणों में मुझे कुछ API फ़ंक्शनों के लिए अजीब व्यवहार का सामना करना पड़ा, जिन्हें सही सापेक्ष पता खोजने के लिए विशेष मामलों की आवश्यकता होती है। मेरी उलझन टिप्पणियों में देखी जा सकती है। शायद यह सिर्फ मेरी घटिया कोडिंग शैली भी है - कौन जानता है।
उदाहरण, सफल होने पर निम्न प्रकार दिखता है:
