[Help] Have code injected *only* when required.

[vulcanaoc]

Hey,

As a precaution against warden, and for my own knowledge, I've been toying around with only having my DLL loaded while it is actually doing something. I can't seem to get it to work, though (code hooking/unhooking is leading to crashes.) I also think there might be a far simpler solution that I'm overlooking.

Here's what I've been doing
(assume all remote threads exit before the next operation begins)
From out of process:

Suspend WoW's main thread.
Inject dll with CreateRemoteThread. (Nothing is done in DllMain)
Hook EndScene with CreateRemoteThread.
Use IPC to flag that an operation must be done (I.E. DoString)
Resume WoW's main thread.
Wait for EndScene to call my hook, and flag that the operation has completed.
//before uninjecting, my hooks must be removed, but I'm having trouble removing them reliably without WoW calling code that is no longer there.
Uninject.

I've tried using CreateRemoteThread to unhook EndScene (which doesn't work without crashing).

I've also tried modifying my hooking code so as to restore the original function right after my hook has been called. This crashes if I don't do a sleep until the next frame, which is unacceptable and unpredictable.

Thanks in advance for any advice...

[Cypher]

Wtf?

No, this is a terrible idea.

[vulcanaoc]

Wtf?

No, this is a terrible idea.

Better ideas?

*braces*

[vulcanaoc]

Let me rephrase: what is a good way to unhook so I can uninject my dll safely?

Also, I realize you're not a fan of CreateRemoteThread for various reasons which you have laid out in other threads. What are some better alternatives?

[ramey]

Let me rephrase: what is a good way to unhook so I can uninject my dll safely?

What do you mean? You're in process, and you're using CreateRemoteThread in EndScene? Don't. To remove the hooks after you're finished or whatever just simply DetourDetach( MS detours 2.1 ), DetourRemove( MS detours 1.5 ), or whatever you're using. Then destruct anything you have allocated using the new keyword with delete, would be a good idea to set any pointers that you're deleting to 0 after them.

Personally, I'm either way too tired and got up too early and don't really understand why you want to do this. You are probably having problems with removing hooks because you're using CreateRemoteThread. Why aren't you putting anything in DllMain? Just allocate a class, and do your stuff in the class constructor.

Something like this( i'm realllyyy tired, so don't take any notice if i'm completely wrong )

class CClass 
{


public:
	CClass();	// Constructor
	~CClass();	// Destructor

};

CClass * gpClassWhatever = 0;

CClass::CClass()
{
	// Attach your hooks here, whatever you want to do
}

CClass::~CClass()
{
	// Detach your hooks here
}

BOOL APIENTRY DllMain( HMODULE hModule, DWORD dwReason, LPVOID )
{
	switch( dwReason )
	{
	case DLL_PROCESS_ATTACH:
		{	
			gpClassWhatever = new CClass();

			break;
		}
	case DLL_PROCESS_DETACH:
		{
		        delete gpClassWhatever;
                        gpClassWhatever = 0;

			break;
		}
	}
	return true;
}

I don't exactly understand what kind of answer you were expecting, so I hope this is somewhat helpful, because I saw that you were having problems how to start hooks too it seems in your injected DLL, CreateRemoteThread.. Don't get why you were doing that in-process. Also, if you're having problems on how to use hooks, google.

[Cypher]

What do you mean? You're in process, and you're using CreateRemoteThread in EndScene? Don't. To remove the hooks after you're finished or whatever just simply DetourDetach( MS detours 2.1 ), DetourRemove( MS detours 1.5 ), or whatever you're using. Then destruct anything you have allocated using the new keyword with delete, would be a good idea to set any pointers that you're deleting to 0 after them.

Personally, I'm either way too tired and got up too early and don't really understand why you want to do this. You are probably having problems with removing hooks because you're using CreateRemoteThread. Why aren't you putting anything in DllMain? Just allocate a class, and do your stuff in the class constructor.

Something like this( i'm realllyyy tired, so don't take any notice if i'm completely wrong )

class CClass 
{


public:
	CClass();	// Constructor
	~CClass();	// Destructor

};

CClass * gpClassWhatever = 0;

CClass::CClass()
{
	// Attach your hooks here, whatever you want to do
}

CClass::~CClass()
{
	// Detach your hooks here
}

BOOL APIENTRY DllMain( HMODULE hModule, DWORD dwReason, LPVOID )
{
	switch( dwReason )
	{
	case DLL_PROCESS_ATTACH:
		{	
			gpClassWhatever = new CClass();

			break;
		}
	case DLL_PROCESS_DETACH:
		{
		        delete gpClassWhatever;
                        gpClassWhatever = 0;

			break;
		}
	}
	return true;
}

I don't exactly understand what kind of answer you were expecting, so I hope this is somewhat helpful, because I saw that you were having problems how to start hooks too it seems in your injected DLL, CreateRemoteThread.. Don't get why you were doing that in-process. Also, if you're having problems on how to use hooks, google.

You shouldn't do that. It's not safe to do a lot of things in DllMain (for the full list, please consult MSDN). You should instead export an initialization function and do all your real work in there.

Also, that doesn't solve this problem:
Hook EndScene
Code in EndScene is executing
You attempt an unload

That's all it takes. If you remove your module while its code is being executed your process will blow up.

I work around this problem in Hades by using an extension system and a "safe" callback system for potentially dangerous hooks. But that's a tad more complex than most people would want I assume.

Also, you still need a remote thread to do both the injection and the ejection, as you obviously can't do it from inside one of your hooks.

[ramey]

You shouldn't do that. It's not safe to do a lot of things in DllMain (for the full list, please consult MSDN). You should instead export an initialization function and do all your real work in there.

Also, that doesn't solve this problem:
Hook EndScene
Code in EndScene is executing
You attempt an unload

That's all it takes. If you remove your module while its code is being executed your process will blow up.

I work around this problem in Hades by using an extension system and a "safe" callback system for potentially dangerous hooks. But that's a tad more complex than most people would want I assume.

Also, you still need a remote thread to do both the injection and the ejection, as you obviously can't do it from inside one of your hooks.

Thanks, I'll checkout MSDN. I remember hearing something about that, but just couldn't be bothered changing it. Thanks for the heads up!

I also kind of missed the problem that he was having, I think...

I'm interested in your "safe" callback system, mind sharing or nono?

[Cypher]

Thanks, I'll checkout MSDN. I remember hearing something about that, but just couldn't be bothered changing it. Thanks for the heads up!

I also kind of missed the problem that he was having, I think...

I'm interested in your "safe" callback system, mind sharing or nono?

The backend is Boost.Signals2, I've simply wrapped it in a bunch of code so I can ensure that all extensions are accessed by Hades (and hence the game) in a single-threaded manner, thus eliminating the possibility of a race condition in a multi-threaded environment and a module ejection whilst code inside it is being executed.

It's not hard to do.

[ramey]

The backend is Boost.Signals2, I've simply wrapped it in a bunch of code so I can ensure that all extensions are accessed by Hades (and hence the game) in a single-threaded manner, thus eliminating the possibility of a race condition in a multi-threaded environment and a module ejection whilst code inside it is being executed.

It's not hard to do.

I actually had problems with race conditions when I was writing something similar to what you were writing, minus portablity, minus CEGUI. I dropped the modules and went for a WoW only approach. I might take it back up in the future some time, and if I do, I will be sure to check that out. Cheers again