Thread: CreateRemoteThread() for subclassing

Hmm..compiled ok with my VC++.NET.....still yeah..cast it if it complains

Personally I never use the old casts...the C++ casts force you to think about what you are doing

static_cast<> is good for minor casts to other types like say an int to a float.

reinterpret_cast<> is for casts which might appear dangerous unless you know what you are doing, like a cast of 1 function pointer to another...in my above code I knew the signatures for each function call were the same so I knew I was alright as long as I worked on 32 bit windows - reinterpret_cast<> is often unportable

const_cast<> is for removing a const qualifier....use only if you are totally sure what you are doing

dynamic_cast<> is for polymorphic downcasting IE a base ptr to a derived ptr.

Whereas the old C casts "()" can do anything like remove const where you dont want etc......

I don't understand what is wrong with my code. It's pretty much the same as yours.

Code:

HWND hFind=NULL;
HWND hChildFind=NULL;
DWORD dwTargetProcId;
HANDLE hProc;
WNDPROC LLProc;
DWORD dwThread;
LPVOID chModParam;
HANDLE hThread;
HMODULE hKernel;
char *chModName=new char [64];
				
lstrcpy(chModName,"easy.dll");

hFind=FindWindow(NULL,"Calculator");
		
GetWindowThreadProcessId(hFind,&dwTargetProcId);

hProc=OpenProcess(PROCESS_ALL_ACCESS,NULL,dwTargetProcId);

hKernel=GetModuleHandle("kernel32.dll");
LLProc=(WNDPROC)GetProcAddress(hKernel,"LoadLibraryA");

chModParam=VirtualAllocEx(hProc,NULL,lstrlen(chModName)+1,MEM_COMMIT,PAGE_READWRITE);
WriteProcessMemory(hProc,chModParam,(LPVOID)chModName,lstrlen(chModName)+1,NULL);

hThread=CreateRemoteThread(hProc,NULL,NULL,(LPTHREAD_START_ROUTINE)LLProc,chModParam,NULL,&dwThread);

VirtualFreeEx(hProc,chModParam,NULL,MEM_DECOMMIT);
VirtualFreeEx(hProc,chModParam,NULL,MEM_RELEASE);
delete [] chModName;
CloseHandle(hProc);

Nothing happens.

1...where the hell's your error checking? Almost all of the APIs used return an error code...you need to check for them. Also check the return of new.

2...look at the end of your code, then look at the end of mine.....as soon as the thread runs, you destroy the memory it references and then shutdown.....this closes all handles - most likely the hadle to the romte thread...this will probably kill the thread before it runs.

Good point about the error checking. I didn't put it in the code because I'd already confirmed each call was working. It seems that WaitingForASingleObject is the way to go.

I have another problem though: my app won't load up until I click ok in the message box (the hook code is in WM_CREATE). Won't this be bad for my app?

Originally posted by bennyandthejets
Good point about the error checking. I didn't put it in the code because I'd already confirmed each call was working. It seems that WaitingForASingleObject is the way to go.

I have another problem though: my app won't load up until I click ok in the message box (the hook code is in WM_CREATE). Won't this be bad for my app?

I didnt think you had this code as part of a window procedure...I thought your app was terminating after that code (as mine did)....if that is not the case, then remove WaitForSingleObject and also dot do anything in WM_CREATE like the CloseHandle call you had...or the VirtualFreeEx calls. If you want to cleanup....put CloseHandle/VirtualFreeEx in WM_DESTROY

Mmmm. I guess I could. How would I do it though? Declare all the handles and pointers globally? It seems kind of messy:

Code:

HANDLE hProc;
LPVOID lpMem;
.
.
.

WndProc()
{
case WM_CREATE:
hProc=OpenProcess();
lpMem=VirtualAllocEx();
.
.
.
case WM_DESTROY:
VirtualFreeEx(lpMem);
CloseHandle(hProc);

I always stumble around this kind of coding. I can never work out where to keep the data.

EDIT: Would it be possible to create a local thread to wait on the LoadLibrary thread completion? That way, it wouldn't matter if you used WaitForSingleObject(). However, I don't want to use that method if it's not necessary.

An extra thread is a possiblity, but not really needed as I see it...

As for the variable scope problem, declare them static inside your WndProc...that way, their value wont change each time a message is handled

static HANDLE hProc;
static LPVOID lpMem;

Cheers, works great. I actually applied a similar principle back at the beginning of this ordeal. The actual window procedure, which I've nearly forgotten about, uses a static declaration to retain the previous window procedure address:

Code:

LRESULT CALLBACK ListProc(HWND hwnd,UINT msg,WPARAM wParam,LPARAM lParam)
{
	static WNDPROC oldProc;

	switch (msg)
	{
	case (WM_USER+1):
		if ( (wParam==1) && (lParam) )
			oldProc=(WNDPROC)lParam;
		if ( (wParam==2) && (!lParam) )
			SetWindowLong(hwnd,GWL_WNDPROC,(LONG)oldProc);
	
	case WM_LBUTTONUP:
		MessageBox(NULL,"YO BUTTON CLICKED","NOTIFY",MB_OK);
		break;

	default:
		break;
	}

	return CallWindowProc(oldProc,hwnd,msg,wParam,lParam);
}

BOOL SubClass(HWND hSub,WNDPROC lpfnWndProc)
{
	WNDPROC oldProc;

	oldProc=(WNDPROC)SetWindowLong(hSub,GWL_WNDPROC,(LONG)lpfnWndProc);
	
	SendMessage(hSub,WM_USER+1,1,(LPARAM)oldProc);

	return TRUE;
}

BOOL WINAPI DllMain(HANDLE hinstDLL,DWORD fdwReason,LPVOID lpvReserved)
{

	switch (fdwReason)
	{
	case DLL_PROCESS_ATTACH:
		{
			MessageBox(NULL,"Dll loaded","Notify",MB_OK);

			HWND hList;
			
			hList=FindListView();

			SubClass(hList,ListProc);

		}
	case DLL_PROCESS_DETACH:
		{
			HWND hList;

			hList=FindListView();

			SendMessage(hList,WM_USER+1,2,0);
		}
	default:
		break;
	}

	return TRUE;
}

What do you think of that code? I couldn't figure out a better way to do it.

Actually that dll doesn't work too well! I got the notification messages, but the whole darn thing stalled on me! The target application appeared to be completely stuffed, as if I had hooked every window procedure and not let any messages through. But my code should only have hooked the window procedure of the list view control, and it SHOULD be letting every single message through to the original procedure.

Not working to well huh? Well, the method you are using is unorthodox to say the least

I mentioned SetWindowsHook earlier.........it involves writing a dll as you have done...but it works much better...as I said, there's pleanty of stuff on that method...do a search and give it a go