Conversation

Michael Maltsev
@m417z
Check out my newly published blog post about DLL injection, thread local storage, TLS callbacks, and the problems that all these can cause. The blog post also shows how a thread can avoid invoking TLS callbacks, and that it can lead to other problems.
m417z.com
A guest in another process - a story of a remote thread crash
In one of my previous blog posts, Implementing Global Injection and Hooking in Windows, I wrote about my journey in implementing global DLL injection for Windhawk, the customization marketplace for...
4
131
namazso
@namazso
Dll injection in general is just a horrible idea from a stability standpoint in almost all cases. There are only two fairly reliable solutions:
1
4
namazso
@namazso
1. Injecting when the process/thread is in a known good state - This means (non-special) APCs, and window hook libraries. This is limited in what process it works on, but does avoid most problems, in part because the thread expects callbacks already, just not this kind.
1
2
namazso
@namazso
2. Injecting in a more rootkit-like fashion - This means freestanding / ntdll-only injected dll, preferably mapped as a section, and called with some hook (like an instrumentation callback). This always works, but severely limits you in how you can write your injected module.
292
Views
1
Retweet
2
Likes
1
Bookmark
Michael Maltsev
@m417z
Well, the WriteProcessMemory + CreateRemoteThread + LoadLibrary combo worked fairly well for me so far. What I describe in the blog post is an exceptional incompatibility, but generally I'm not sure there's a better alternative with the same level of flexibility.
1
namazso
@namazso
Well, the second method I listed is way more flexible in terms of what you can safely inject into (basically anything), it is rather inflexible on the side of what you can inject. But considering you "control" that side it might be a workable tradeoff.
1
Show replies