About modules
About modules
How i can detect if a module was injected on process instead of main process loaded that using madkernel?
Re: About modules
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.
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
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
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
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
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
You mean it right? if Modules.Items[x].Handle <> Modules.Items[x].ImageNtHeaders.OptionalHeader.ImageBase thenmadshi 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.
because on my tests if are equal it's loaded by default .exe, and if is different are injected.
Re: About modules
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.
Relocated DLLs do not necessarily mean they have been injected, though. It might be an indication, but no proof.
Re: About modules
One question, why when i use your module function use many CPU.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.
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
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
tested with "with do begin" and still using CPU, however i'll use win apis.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.
you know how i can unload a dll? FreeLibrary? because when i do it my application closes.
Re: About modules
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
I've tried unload a module injected by a external process, so it's impossible do it?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.
It's possible do these checks with ImageBase at LdrLoadDll? preventing their load.
Re: About modules
I've already commented on hooking LoadLibrary/LdrLoadDll earlier.