Hello again 😄

With this PR, we find the export address of all DLL functions ourselves, so we no longer rely on GetProcAddress and LdrGetProcedureAddress. The idea is to stay away from Kernel32 and NTDLL as much as possible. Resolving several functions might lead to detection

I have tried to resolve all exports of Kernel32, NTDLL, User32. vcruntime40 and stdlib and it worked very well, so I am confident the implementation is solid.

One interesting thing I found while developing this: For some weird reason, Kernel32 (and a few others) exports some functions that aren't really defined in Kernel32, but in other libraries (maybe everybody knew this but me?) When you try to resolve those functions, you get a pointer to a string that describes where that function is truly defined. For example, AcquireSRWLockExclusive is a function exported by Kernel32, that resolves to an address that has this string: NTDLL.RtlAcquireSRWLockExclusive, meaning the function is defined in ntdll as RtlAcquireSRWLockExclusive. So that is why the function is recursive, it needs to handle those cases. (luckily your test DLL loads one of these "fake" exports, so I was able to find this behavior)

Anyway, hope you find it useful

Edit: I have also found that in some weird cases, libraries such as Kernel32 does this thing where a function "points" to another library and function name, but the library is like deprecated and the function is in truth implemented in Kernel32. That is why if the resolve fails, it tries with Kernel32 and KernelBase. You can try to resolve all exports of the DLL you like and compare the result with what LdrGetProcedureAddress says it is and confirm that it works for all cases. Let me know if this is unclear and you want to clarify something.

Hey there! The main idea of this PR is not only to have less static-imports to make the final binary less interesting to static analysis, but to start to make DarkLoadLibrary able to be injected as shellcode directly on memory. My final goal would be to integrate it with Cobalt Strike as a User Defined Reflective Loader, this is just one step on that direction.

Hope you find it useful!

Hello @bats3c 😄 I'm a big fan of this project, I'm very impressed by your work.

This is of course to bypass userland hooks. VirtualProtect is likely to get denied by an EDR when making memory pages executable. VirtualAlloc isn't as risky but I just replaced it to hide big allocations to stay under the radar.

I used SysWhispers2 so it should work for all versions of Windows, I tested it on a Windows 10 21H1 and it works very nicely.

Hey,

Added a .gitignore file, so stupid directories like .vs don't get into the git. Also modified the debug configuration.

1. ntdll.lib wasn't being linked
2. weird "Address Sanatizer" option
3. Include directory was set for your build chain, not using macros

I use vs2019's x64 to compile normally, but it fails to compile on X86.

1>Assembling src\syscallsstubs.asm...
1>src\syscallsstubs.asm(1): error A2013: .MODEL must precede this directive
1>src\syscallsstubs.asm(5): error A2034: must be in segment block : NtProtectVirtualMemory
1>src\syscallsstubs.asm(6): error A2034: must be in segment block
1>src\syscallsstubs.asm(7): error A2034: must be in segment block
1>src\syscallsstubs.asm(8): error A2034: must be in segment block
1>src\syscallsstubs.asm(9): error A2034: must be in segment block
1>src\syscallsstubs.asm(10): error A2034: must be in segment block
1>src\syscallsstubs.asm(11): error A2034: must be in segment block
1>src\syscallsstubs.asm(12): error A2034: must be in segment block
1>src\syscallsstubs.asm(13): error A2034: must be in segment block
1>src\syscallsstubs.asm(14): error A2034: must be in segment block
1>src\syscallsstubs.asm(15): error A2034: must be in segment block
1>src\syscallsstubs.asm(16): error A2034: must be in segment block
1>src\syscallsstubs.asm(17): error A2034: must be in segment block
1>src\syscallsstubs.asm(18): error A2034: must be in segment block
1>src\syscallsstubs.asm(19): error A2034: must be in segment block
1>src\syscallsstubs.asm(20): error A2034: must be in segment block
1>src\syscallsstubs.asm(21): fatal error A1010: unmatched block nesting : NtProtectVirtualMemory

Hey, great tool. Are there any near-term plans to add DarkLoadLibrary loading for a DLL's dependencies/imports? They're current just using LoadLibrary, and I can see you added a note to say support would (hopefully) be added in future (in ldrutils.c).

yeah very few HeapAlloc calls actually get freed. I would fix this myself but that seems more fitting of a punishment for the creator of said leaks.

ahem @bats3c

I made a few minor tweaks to better support mingw and to reduce compiler warnings:

• Added function signatures to corresponding header files to remove no previous declaration for warnings.
• A new header darkmodule.h was created to contain the _DARKMODULE struct definition. This is so that darkloadlibrary.h can include each of the other headers with their new function signatures.
• A couple variables were PCHARs instead of PWCHARs.