Page 1 of 1

About modules

PostPosted: Thu Aug 30, 2018 10:55 pm
by pambol
How i can detect if a module was injected on process instead of main process loaded that using madkernel?

Re: About modules

PostPosted: Fri Aug 31, 2018 4:58 am
by madshi
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.

Re: About modules

PostPosted: Fri Aug 31, 2018 11:05 pm
by pambol
i've hooked RtlUserThreadStart to check threads start (used on inject too) but i think pfnStartAddr should show some address of loadlibrary no? but isn't what show.

Re: About modules

PostPosted: Sat Sep 01, 2018 6:52 am
by madshi
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.

Re: About modules

PostPosted: Sat Sep 01, 2018 10:02 pm
by pambol
you know how i can retrieve if a module (dll) are relocated? i see on process hacker he detect any injection using this method.

Re: About modules

PostPosted: Sun Sep 02, 2018 3:39 pm
by madshi
That's easy, just compare the actual image base address (which is simple the module handle) to the "preferred" image base address, which is stored in the DLL header.

Re: About modules

PostPosted: Thu Jan 10, 2019 4:46 pm
by pambol
madshi wrote:That's easy, just compare the actual image base address (which is simple the module handle) to the "preferred" image base address, which is stored in the DLL header.


You mean it right? if Modules.Items[x].Handle <> Modules.Items[x].ImageNtHeaders.OptionalHeader.ImageBase then

because on my tests if are equal it's loaded by default .exe, and if is different are injected.

Re: About modules

PostPosted: Thu Jan 10, 2019 4:53 pm
by madshi
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.

Re: About modules

PostPosted: Thu Jan 10, 2019 6:47 pm
by pambol
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.

Re: About modules

PostPosted: Thu Jan 10, 2019 7:05 pm
by madshi
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.

Re: About modules

PostPosted: Thu Jan 10, 2019 7:32 pm
by pambol
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.

Re: About modules

PostPosted: Thu Jan 10, 2019 7:43 pm
by madshi
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.

Re: About modules

PostPosted: Thu Jan 10, 2019 8:33 pm
by pambol
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.

Re: About modules

PostPosted: Thu Jan 10, 2019 8:42 pm
by madshi
I've already commented on hooking LoadLibrary/LdrLoadDll earlier.