Solve : C++ API?

1.	Solve : C++ API?
Answer» Hey guys, I am wondering how i would go about translating messages sent to an external program. for instance my program gets a handle of notepad.exe what i want to do is if user mouse press to auto input some text The part of this project i need help with is the listening for mouse press Code: [Select] while (GetMessage(&msg, hWnd, 0, 0)){ TranslateMessage(&msg); if (msg.message == WM_NCLBUTTONDOWN ) MessageBox(NULL,"Success","Message:",MB_OK); DispatchMessage(&msg); }//while any help will be great. ThanksIf I understand what you want to do correctly, you want to basically "see" the messages being sent to another applications window? what you are doing is trying to setup a message pump for the exterior window. This isn't going to work, because GetMessage() will only retrieve messages sent to windows in your process. In order to subclass a window, you need to use SetWindowLong(GWL_WNDPROC, ). Normally, this is accomplished in a few steps: 1. use SetWindowLong(GWL_WNDPROC,&MyWindowProcedure) to set the window procedure to be your routine. SetWindowLong() will return the old address, save this. 3. instead of calling DefWindowProc() or simply returning from the "MyWindowProcedure" routine, use CallWindowProc() on the saved address that you got from GetWindowLong() in step one. However- this will only work for windows that are within the same process as the caller. That is- you basically will not be able to set the notepad's window procedure this way, as documented in the MSDN documentation for SetWindowLong() regarding GWL_WNDPROC: Quote You cannot change this attribute if the window does not belong to the same process as the calling thread. This means the only way to actually subclass another processes window would be DLL injection, or, using a appinit_dll, or otherwise having a dll that is loaded in that process, and making the appropriate subclassing calls from that dll (since it is in the same process, it will work). The general approach for doing this usually involves injecting your DLL into the other process by using CreateRemoteThread(), and creating a remote thread in the other process that loads your DLL by passing as the start address the address of the WIN32 LoadLibrary() function, with the path to the DLL to load as a parameter. This in and of itself has a few PROBLEMS; mainly, that while the address of LoadLibrary() will be the same cross-process (all processes load kernel32.dll) the same cannot be said of the string specifying the path, which will be a pointer that is only valid in your address space. The solution to this is to make that pointer valid in the remote process by using WriteProcessMemory() to make the pointer valid. Basically, in order to subclass another processes windows, you'll need to be "in the process" so to speak. In order to inject your DLL, you would need to first get a HANDLE to the remote process (using OpenProcess()). Take note that this will fail in many cases as a result of SECURITY settings and the account; settings, because you need to have the "Query Process" permissions on the account your program is running in, which you won't have by default. You will then need to allocate memory for the DLL name in the remote process using that HANDLE by calling VirtualAllocEx, and then write that DLL name using WriteProcessMemory(); once that is done, you can map your DLL to the remote process by using CreateRemoteThread() and making it call LoadLibrary() as the start routine and with your DLL's name as the thread start parameter. At this POINT you would wait for the remote thread to terminate (using WaitForSingleObject, usually). LoadLibrary() will load your DLL and call it's DllMain() with DLL_PROCESS_ATTACH as the reason. Once finished, you can use GetExitCodeThread() on the remote thread, which will retrieve the return code from LoadLibrary, which will be the base address of your DLL within the other process. At this point your DLL can do whatever it PLEASES, including subclassing windows within the process is was spawned in. Basically, it's not really worth the effort, and you will usually have to resort to actual Window Hooks to get everything working nicely. Thanks BC, you have saved me alot of mindless googling as you said its probably not worth the effort but ill take a look into windows hooks and DLL injection

Answer»

Hey guys,

I am wondering how i would go about translating messages sent to an external program.

for instance my program gets a handle of notepad.exe what i want to do is if user mouse press to auto input some text
The part of this project i need help with is the listening for mouse press

Code: [Select] while (GetMessage(&msg, hWnd, 0, 0)){
TranslateMessage(&msg);

if (msg.message == WM_NCLBUTTONDOWN )
MessageBox(NULL,"Success","Message:",MB_OK);
DispatchMessage(&msg);

}//while
any help will be great.

ThanksIf I understand what you want to do correctly, you want to basically "see" the messages being sent to another applications window?

what you are doing is trying to setup a message pump for the exterior window. This isn't going to work, because GetMessage() will only retrieve messages sent to windows in your process.

In order to subclass a window, you need to use SetWindowLong(GWL_WNDPROC, ). Normally, this is accomplished in a few steps:

1. use SetWindowLong(GWL_WNDPROC,&MyWindowProcedure) to set the window procedure to be your routine. SetWindowLong() will return the old address, save this.

3. instead of calling DefWindowProc() or simply returning from the "MyWindowProcedure" routine, use CallWindowProc() on the saved address that you got from GetWindowLong() in step one.

However- this will only work for windows that are within the same process as the caller. That is- you basically will not be able to set the notepad's window procedure this way, as documented in the MSDN documentation for SetWindowLong() regarding GWL_WNDPROC:

Quote

You cannot change this attribute if the window does not belong to the same process as the calling thread.

This means the only way to actually subclass another processes window would be DLL injection, or, using a appinit_dll, or otherwise having a dll that is loaded in that process, and making the appropriate subclassing calls from that dll (since it is in the same process, it will work). The general approach for doing this usually involves injecting your DLL into the other process by using CreateRemoteThread(), and creating a remote thread in the other process that loads your DLL by passing as the start address the address of the WIN32 LoadLibrary() function, with the path to the DLL to load as a parameter. This in and of itself has a few PROBLEMS; mainly, that while the address of LoadLibrary() will be the same cross-process (all processes load kernel32.dll) the same cannot be said of the string specifying the path, which will be a pointer that is only valid in your address space. The solution to this is to make that pointer valid in the remote process by using WriteProcessMemory() to make the pointer valid.

Basically, in order to subclass another processes windows, you'll need to be "in the process" so to speak. In order to inject your DLL, you would need to first get a HANDLE to the remote process (using OpenProcess()). Take note that this will fail in many cases as a result of SECURITY settings and the account; settings, because you need to have the "Query Process" permissions on the account your program is running in, which you won't have by default. You will then need to allocate memory for the DLL name in the remote process using that HANDLE by calling VirtualAllocEx, and then write that DLL name using WriteProcessMemory(); once that is done, you can map your DLL to the remote process by using CreateRemoteThread() and making it call LoadLibrary() as the start routine and with your DLL's name as the thread start parameter. At this POINT you would wait for the remote thread to terminate (using WaitForSingleObject, usually). LoadLibrary() will load your DLL and call it's DllMain() with DLL_PROCESS_ATTACH as the reason. Once finished, you can use GetExitCodeThread() on the remote thread, which will retrieve the return code from LoadLibrary, which will be the base address of your DLL within the other process. At this point your DLL can do whatever it PLEASES, including subclassing windows within the process is was spawned in.

Basically, it's not really worth the effort, and you will usually have to resort to actual Window Hooks to get everything working nicely.

Thanks BC, you have saved me alot of mindless googling as you said its probably not worth the effort but ill take a look into windows hooks and DLL injection

Solve : C++ API?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment