I originally PM'd tzuk, but he thought it would make an interesting forum discussion, so here's our first two messages to be continued here:

My two main concerns are that MS says do not call LoadLibrary from DllMain or call any functions not in kernel32. In order to hook everything that one might want too, it is possible that you'd have to load the DLL yourself if the process has not already loaded it (or may load it later at some point). That breaks rule number one. And I do other things during the initialization of my DLL that breaks rule number two. So I'm kinda stuck between following the rules and give the process another microsecond to run its code.

Regarding your comment about the main thread terminating, wouldn't that end the target process anyway? If not, it shouldn't impact the thread I've created to do initialization. It only waits for DllMain to return, then runs.

Perhaps there's a way around this, maybe an optional flag or function call that could make SbieDll wait to restore the process's entry point until the flag is set or the function is called. That way my initialization thread could run, then signal SbieDll that it's OK to continue. That should solve both problems, right?

I see. How about hooking LoadLibrary? That's basically what I do in SbieDll. Maybe I can add an SbieDll_RegisterLoadLibraryHook for "third party DLLs" like what you're doing. That would be instead of the flag mechanism that you proposed later in your post.



No. It seems that way, because most main threads end up calling ExitProcess. But if the main thread calls ExitThread instead, the process goes on. (I'm only pretty sure about this, not absolutey sure.) So your thread should also wait on the thread object that created it.

I see. How about hooking LoadLibrary? That's basically what I do in SbieDll. Maybe I can add an SbieDll_RegisterLoadLibraryHook for "third party DLLs" like what you're doing. That would be instead of the flag mechanism that you proposed later in your post.



No. It seems that way, because most main threads end up calling ExitProcess. But if the main thread calls ExitThread instead, the process goes on. (I'm only pretty sure about this, not absolutey sure.) So your thread should also wait on the thread object that created it.

i would rather hook LdrLoadDll

Right, which is basically the same thing. If you catch my drift.

How would SbieDll_RegisterLoadLibraryHook work and what would it accomplish? I'm missing where you're trying to go with that... Somehow make it 'OK' to use LoadLibrary in DllMain and hook functions from those libraries?

basically, but not exactly....
loadlib hooks can be circumvented by calling ldrloaddll

@wraithdu:
i assume it allows you to register a callback, that is fired whenever a dll is loaded or about to be loaded

Well, Mark_, it appears you did not catch my drift.



That's what I meant. A mechanism in SbieDll, which calls some procedure in your DLL, whenever any new DLL has been loaded. That should be useful to you wraithdu, what do you think?

Well...I'm sure it would be useful, but I'm not sure it solves all the potential problems. If it's not too difficult to implement, it would open up interesting possibilities, so it would be worth pursuing.

Sticking with the callback idea, I think it would be MUCH more useful (for my intentions anyway) to be able to register a callback procedure with SbieDll that would be called AFTER DllMain returns, but BEFORE SbieDll returns control back to the process entry point. This would lift the DllMain restrictions and maintain 'security' since we'd still be doing the hooking before the target process code gets to run. How's that sound?

it would also open up a security hole, seeing as most things i have seen either spawn a thread in dllmain that hook stuff, or do it directly in dllmain...

Care to elaborate? You're response is pretty vague to the topic at hand.

Mark_: Those things you talk about would circumvent wraithdu´s DLL but would not circumvent Sandboxie so talking about opening a security hole seems exagerated. Don´t you think so?

Also it's worth noting that InjectDll is mostly used to control/modify legit programs. It's purpose is not to contain or sanitize bad software. As we have already said, InjectDll only provides user mode hooks, which are only good against software that is not looking for them.

say i write a usermode rootkit,
the point where i would hook stuff is in dllmain, so when callback gets fired afterwards you missed the modifications.

@Buster: true, maybe a bit exagerated.