Nim DInvoke

D/Invoke implementation in Nim

All Nim binaries typically expose the same 58-60 Windows API functions:

All other Windows API functions are typically resolved on runtime via GetProcAddress and LoadLibraryA as mentioned in OffensiveNim or this blog post.

So, it's not possible to hide API imports (completely) via DInvoke in Nim, unless someone for example uses e.g. this DInvoke implementaion to modify the Nim compiler for DInvoke usage instead of Dynlib.

Manually parsing the functions from PEB instead of using GetProcAddress and LoadLibraryA is still stealthier than the default Nim behaviour. To also avoid inline hooking for example manual mapping of a fresh DLL copy would be needed as mentioned in TheWovers DInvoke blog post:

This is - however - not implemented here yet. I'm currently only using LdrLoadDll to load new DLL's into memory.

This project was heavily inspired by the NanoDump D/Invoke code.

The function can than be used like this:

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/HEAD/processID)
)

In my testings I faced strange behaviours for some API functions, which need special cases to find the correct relative address. My confusion can be found in the comments. Maybe that's also just my trash coding style - who knows.

The example, when successfully looks like the following: