You can't really detect that, at least not in any easy way. Injection usually works by e.g. creating a remote thread in a process and the remote thread simply calls LoadLibrary(). So the DLL appears to be loaded by your process.

I can only think of 2 possible things you could detect:

1) You can could check if the DLL is loaded dynamically or statically. If it's loaded dynamically, it was loaded by LoadLibrary. If it was loaded statically, that means probably it was loaded by the OS loader. However, some injection methods also make the DLL being loaded by the OS loader. So this is not really a reliable test.

2) You could try to hook LoadLibrary/LdrLoadDll and check if anyone is calling that within your process. That will detect some kind of injection, but not all. E.g. if the injection is done before your EXE has a chance to install the API hooks, you'll miss the injection. Or if the injection done in kernel land by making the hook dll appear statically linked, you will miss that, as well.

So I don't really have a good solution for you.

Maybe the only real way is to maintain a list which dlls are supposed to be loaded, and any dll which isn't in that list, and isn't also a Microsoft system dll, then could be considered "injected"? But there's a certain danger of false positives if you go that way. So again, no really good solution, either.

Starting the injection thread directly on LoadLibrary is one way to do it, another is to copy/write code into the process (VirtualAllocEx + WriteProcessMemory) and start the thread on the address of the allocated code. That code would then call LoadLibrary(Ex) or LdrLoadDll.

Yeah, something like that, but please don't call "Modules.Items[x]" twice. Modules() is a function which enumerates all modules. So if you call it twice, your program enumerates twice. Instead use "with Modules.Items[x] do begin".

Relocated DLLs do not necessarily mean they have been injected, though. It might be an indication, but no proof.

madshi wrote:Yeah, something like that, but please don't call "Modules.Items[x]" twice. Modules() is a function which enumerates all modules. So if you call it twice, your program enumerates twice. Instead use "with Modules.Items[x] do begin".

Relocated DLLs do not necessarily mean they have been injected, though. It might be an indication, but no proof.

One question, why when i use your module function use many CPU.and if i code it using windows apis don't use nothing from CPU.

i did the same code as loop modules and check and using windows api consumn 0% CPU, and using your routine use alot of CPU.

Well, as I said, don't call "Modules" multiple times. There may be other things like that in your code. Of course even if your code is perfect, madKernel may still be slower because it encapulates everything into nice interfaces. But it shouldn't be that much of an overhead - unless you're polling modules very very often. But of course nobody stops you from using win32 APIs. madKernel is only there to make your life easier. It was not written with speed as the primary design goal.

madshi wrote:Well, as I said, don't call "Modules" multiple times. There may be other things like that in your code. Of course even if your code is perfect, madKernel may still be slower because it encapulates everything into nice interfaces. But it shouldn't be that much of an overhead - unless you're polling modules very very often. But of course nobody stops you from using win32 APIs. madKernel is only there to make your life easier. It was not written with speed as the primary design goal.

tested with "with do begin" and still using CPU, however i'll use win apis.you know how i can unload a dll? FreeLibrary? because when i do it my application closes.

FreeLibrary is the right API. But you're only supposed to unload modules you've loaded yourself. Or modules that you know you can unload without causing trouble. If you unload a module and it crashes, then obviously you can't do that.

madshi wrote:FreeLibrary is the right API. But you're only supposed to unload modules you've loaded yourself. Or modules that you know you can unload without causing trouble. If you unload a module and it crashes, then obviously you can't do that.

I've tried unload a module injected by a external process, so it's impossible do it?It's possible do these checks with ImageBase at LdrLoadDll? preventing their load.