madshi.net

Well, we are hooking LdrLoadDll and LdrUnloadDll. That hook is called in FreeLibrary. So we end up in situation like this: FreeLibrary() LdrUnloadDllHook() LdrUnloadDll() DllMain Unhook LdrUnloadDll - deadlock You can ask, why do we unhook manually. It doesn't matter in this case, because it can cra...

It is bad because we hook LdrLoadDll. So we have deadlock.

PP

It will be better if you do it. There are some bytearray versions too. It will be better to do it right first time. I will try to test it on my side with openfiledialoghook or something like that.

Well, you don't need to load them in order to hook them. Also, I can't imagine it's a dynamic load, because if I call FreeLibrary on your hook dll, this doesn't have any effect on other dynamically loaded dlls at all, unless you call FreeLibrary in your dll's DLL_PROCESS_DETACH handling. But then, ...

There's a reason the hooking rule 4 says: http://help.madshi.net/HookingRules.htm > In your hook DLL link to as few DLLs as possible. Well we are dependent only on the system ones: WTSAPI32.DLL, PSAPI.DLL, WS2_32.DLL, KERNEL32.DLL, USER32.DLL, GDI32.DLL, WINSPOOL.DRV, ADVAPI32.DLL, SHELL32.DLL, OLE...

Yes, you are right. But this is not about safe unhooking. It works just fine. The problem is about how the Inject and Uninject routines are written in the source code... I mean order of operations (unhooking vs. load/free libs), thread safety and some rare "else cases" that are not covered...

Well I do see a simple logic. If a dll hooks functions that takes a long time to finish, like GetFileOpenDialog, IFileOperation::PerformOperations and so on, it is just a matter of time until it crashes. All you do is to call Uninject and Inject DLL again when the dialog is open, when the explorer i...

Well, we do have some kind of mechanism of choosing injected and uninjected apps dynamically. In some rare cases Windows could cause the injecting thread to be delayed until the uninjecting thread is started or the uninjecting thread is blocked by AutoUnhook until some hooks finish... especially dur...

I did more research and madshi is right calling FreeLibrary doesn't crash app. But I found out that if you meddle with dll lock count (like setting it to "dll->LoadCount = 0xff;") it will cause a crash because 1] First thread starts unhooking thread and set it to 1 2] Second thread sets it...

And also... that ExitThread is ugly.

PP

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...

Hi,
we will try to reproduce it with your demo.

PP

Hi, we are testing w10 support and we found some crash in Edge in MCH function CreateMetroSd. MicrosoftEdgeCP.exe(5).408.dmp --------------------------------------------- FAULTING_IP: iertutil!IEConfiguration_GetBool+318 00007fff`cec35bc8 488b04c8 mov rax,qword ptr [rax+rcx*8] EXCEPTION_RECORD: ffff...

Hi, we have an issue with google chrome processes running at the untrusted integrity level on w81. MCH doesn't disable any hooks during the uninjection of our library. The reason is that the MCH is unable to call OpenFileMapping on the AutoUnhookMap mapped file. The get last error says ACCESS_DENIED...

Any progress?

PP