Uninjection problem (DLL ref count + AutoUnhookCounter)
Uninjection problem (DLL ref count + AutoUnhookCounter)
Hi,
we found that if we call injection of dll on one process more than 10times we are not able to uninject dll anymore. It is because calling of FreeLibrary is stopped after 10 calls and AutoUnhookCounter is 0. So no more threads are able to uninject anything. It is also reproducible with your demos.
I propose to raise a limit to 0xFFFF.
PP
we found that if we call injection of dll on one process more than 10times we are not able to uninject dll anymore. It is because calling of FreeLibrary is stopped after 10 calls and AutoUnhookCounter is 0. So no more threads are able to uninject anything. It is also reproducible with your demos.
I propose to raise a limit to 0xFFFF.
PP
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
And also... that ExitThread is ugly.
PP
PP
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Thanks, will have a look at this.
Why do you find the ExitThread ugly? This is *always* called from an injection remote thread created by madCodeHook, it's never called in any other situation. ExitThread is the fastest and cleanest way to close that remote thread without doing further processing.
Why do you find the ExitThread ugly? This is *always* called from an injection remote thread created by madCodeHook, it's never called in any other situation. ExitThread is the fastest and cleanest way to close that remote thread without doing further processing.
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Just adding to Madshi's last post, in some cases an explicit call to ExitThread is absolutely needed for "proper" thread closure. This is the case for native threads and require a call to RtlExitUserThread (native equivalent of a WIN32 ExitThread) inside the thread's callback procedure. RtlCreateUserThread is an example of a native thread creation API which just wraps NtCreateThread(Ex)
--Iconic
--Iconic
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Hi,
you forgot to update InjectThread with 0xFFFF as well.
PP
you forgot to update InjectThread with 0xFFFF as well.
PP
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
I was a bit afraid of simple switching to 0xFFFF because I wasn't sure it would be the correct value on all OSs. But I think I found a nice solution. Try this build:
http://madshi.net/madCollectionBeta.exe (installer 2.7.12.2)
What do you think?
http://madshi.net/madCollectionBeta.exe (installer 2.7.12.2)
What do you think?
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Hi, I can't see any change in your code that is relevant to this issue.
Can you explain it a bit? Thx.
PP
Can you explain it a bit? Thx.
PP
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Stupid me. I modified the code in the wip madCodeHook 4.0, but failed to copy it down to madCodeHook 3. Basically I've replaced this code:
with this:
The idea is that the first DLL in the list should be a statically linked dll, so I simply use that dll's load count value.
Code: Select all
dll.LoadCount := $ff;
Code: Select all
if firstDll.LoadCount >= $ff then
dll.LoadCount := firstDll.LoadCount
else
dll.LoadCount := $ff;
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Now the hooking dll doesn't have its count changed by LoadLibrary/FreeLibrary anymore, because it will be considered as static.
Will be the behaviour all the same for both 64b and 32b versions?
I thought that you modify load counts only in 32b version.
Will be the behaviour all the same for both 64b and 32b versions?
I thought that you modify load counts only in 32b version.
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Yes, that was the whole idea. I'm confused. Using 0xFFFF, as you suggested, should have the same effect, so why are you now seemingly not happy with this? Or am I misunderstanding you?EaSy wrote:Now the hooking dll doesn't have its count changed by LoadLibrary/FreeLibrary anymore, because it will be considered as static.
This is currently only done for 32bit.EaSy wrote:Will be the behaviour all the same for both 64b and 32b versions?
I thought that you modify load counts only in 32b version.
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Hi, sorry for the late reply.
I believe, that if I call InjectDll more than 10 times on the process (for example possible in your demo) it will call LoadLibrary more than 10times. Once I call Uninject, it will disable hooks and call up to10times FreeLibrary. But the DLL will stay loaded in process but dormant. But later if I call Uninject again it will do nothing because AutoUnhookCounter blocks it, but the DLL is still in the process.
Am I right?
PP
I believe, that if I call InjectDll more than 10 times on the process (for example possible in your demo) it will call LoadLibrary more than 10times. Once I call Uninject, it will disable hooks and call up to10times FreeLibrary. But the DLL will stay loaded in process but dormant. But later if I call Uninject again it will do nothing because AutoUnhookCounter blocks it, but the DLL is still in the process.
Am I right?
PP
Re: Uninjection problem (DLL ref count + AutoUnhookCounter)
Oh, I see now. You're looking at the C++ code, right? I've made the changes to the Delphi code, and I thought that would be enough because the Delphi code is compiled into the CInjectThread32 array which is then used by the C++ code. But I missed the fact that I'm doing that for 32bit, only, so I still have to change the C++ code, to make the changes work in 64bit, too. Sorry about that, will do the same changes for the C++ code in the next build.