Injected Dll isn't shown as loaded

[C0D3-M4513R]

If I inject a dll, using this method, I cannot confirm, that the dll was loaded.

Process hacker can show loaded dll's in a process, under the 'Modules' tab. In the Programm, one can use the following winapi calls: CreateToolhelp32Snapshot,Module32FirstW,Module32NextW

Using those api calls, my Programm also says, that the dll is not loaded, even though it clearly was (my test dll just pops up a Message Box).

Using ProcessExplorer, my injected dll is also working as expected, but also shown in the Modules tab, and therefore recognised, by my injector, as injected.

I checked with x64 dll and target exe, and x86 dll and target exe.

[UserExistsError]

This library reads the provided DLL into memory and maps it into the specified processes' address space, without using the Windows loader. Since it doesn't use the Windows loader (e.g. LoadLibrary), the DLL is never registered in the loaded modules list.

[C0D3-M4513R]

Ok, this is really good to know. (So I wasn't going insane). I assume, that this loader should be pretty reliable? Is there a way, to confirm, if a dll was loaded, without any modification, of the target process, or the dll?

I am asking, because I made a injector in rust, using mainly Windows api calls, and it was driving me nuts, that sometimes, the LoadLibrary call would complete (After waiting on the completetion), indicate, that it was successful, but still fail. And my top priority is having consistent return codes,

[UserExistsError]

The loader is based off of https://github.com/stephenfewer/ReflectiveDLLInjection. There is minimal error checking and if your DLL has exception handling, your handlers will not be called. Managed DLLs will not work and you should test every DLL you plan to use with this loader. If your DLL has dependencies, these will be loaded with the Windows loader and won't have these problems.

Perhaps what you could do is inject a minimal DLL that then loads other modules with LoadLibrary. But at that point, you're probably better off using an injection library that writes the name of your module in the remote process and calls CreateRemoteThread on LoadLibrary.

The purpose of this repo is to demonstrate disk-less injection, where your DLL never has to be present on disk like it does with LoadLibrary. If you don't have a need for disk-less, you can probably find a more reliable injector.

[C0D3-M4513R]

Since I want to write a library, the injection shouldn't have any restriction. I'll maybe offer this as a secondary method. Looks like I still need some Heavensgate functionality, to inject x64 dll from x86 injector or to inject x86 dll from x64 injector. For a secondary injection method, confirmation is not that critical. Therefore closing this.