Is it possible to retrieve Window Proc in process running in other user?

[stoneyrh]

I am encoutering a problem on retrieving the Window Proc of a window that running in a process with another user.
For example, I have logon windows with domain\user1, and run the following command as:

runas /profile /env /useromain\user2 C:\Windows\System32\calc.exe

And then the Calculator is shown in domain\user1 desktop, but the process is running in domain\user2 account.
When running Spy++ (either wither domain\user1 or domain\user2) to view the calculator window, the Windoe Proc field is shown 'Unavailable'
I also try to call GetWindowLong against this window, it will always returns NULL.

I am just wondering if it is possible to retrieve the Window Proc of the window running in a process of another account, is is possible?

Thanks

[zerver]

In a situation like this, I would try hooking the application. If it succeeds, you should have unrestricted access.

Have a look at SetWindowsHookEx(WH_CALLWNDPROC, ...). Inside the hook DLL, call SetWindowLong.

You may need to install the hook with the same user account as the running app.

[stoneyrh]

In a situation like this, I would try hooking the application. If it succeeds, you should have unrestricted access.

Have a look at SetWindowsHookEx(WH_CALLWNDPROC, ...). Inside the hook DLL, call SetWindowLong.

Yes, I do the same thing as you said. The hook works fine against the process running in current user.

You may need to install the hook with the same user account as the running app.

The problem is, I am requried to hook that process if it was launched in the way like 'runas...' with the other account.

[Igor Vartanov]

I am requried to hook that process if it was launched in the way like 'runas...' with the other account.

You need to explain "hook the process." In case this is expected to be done the way Windows does this, i.e. automatically inject foreign dll into the launching process, but with no Windows support for that, then you're in trouble, man.

[zerver]

I think you are simply passing the wrong HWND to GetWindowLong(..., GWL_WNDPROC).

Inside the hook DLL, please use FindWindow(NULL, window title) to get the correct HWND.

If still problems after that, check if GetWindowLongPtr makes any difference.

Regards

[stoneyrh]

You need to explain "hook the process." In case this is expected to be done the way Windows does this, i.e. automatically inject foreign dll into the launching process, but with no Windows support for that, then you're in trouble, man.

What I am going to do is inject a DLL into a 3rd party process automatically (actually it is developed by other BU of my company, but I don't have the source, so I need to do that in this way), and create new UI in that main window of that process. What I am doing now is, when the user logon, a monitor process starts (via the registry key ...\CurrentVersion\Run), and install a global hook. So each time a new process is launched, the DLL will be injected into that new process. If the target process is launched withe current Windows logon user, everything works fine, but the bad thing is, the target process could be launched with the other account by something like 'runas' command, in this case, even my hook DLL has been injected, but it never gets called.

[stoneyrh]

I think you are simply passing the wrong HWND to GetWindowLong(..., GWL_WNDPROC).

Inside the hook DLL, please use FindWindow(NULL, window title) to get the correct HWND.

If still problems after that, check if GetWindowLongPtr makes any difference.

Regards

The handle of the window is sure to be correct. Because I use the handle passed from the HOOK PROC.
And I could not even see the Window Proc value in Spy++.

It is worthy of trying GetWindowLongPtr, thanks

[Igor Vartanov]

but the bad thing is, the target process could be launched with the other account by something like 'runas' command, in this case, even my hook DLL has been injected, but it never gets called.

Yes, this is what I told you before: you're in trouble. And the reason is the chosen way of injection, which works only in context of current interactive session and desktop.

The requirement of hooking processes running in different logon session makes the current way of injection be useless.

In case you have to replicate the main hooking logic, you are to:

• monitor process creation (passively observing the list of processes, or intercepting CreateProcess API)
• inject your dll by direct writing to remote process and executing remote thread
• the thread has to set a required hook locally on the process

You're going to have a lot of fun with accessing to remote process with rights allowing you writing and remote code execution. The extra fun is that the code is going to depend on particular Windows version.

You should think twice on accepting this new requirement.

[stoneyrh]

Yes, this is what I told you before: you're in trouble. And the reason is the chosen way of injection, which works only in context of current interactive session and desktop.

The requirement of hooking processes running in different logon session makes the current way of injection be useless.

In case you have to replicate the main hooking logic, you are to:

• monitor process creation (passively observing the list of processes, or intercepting CreateProcess API)
• inject your dll by direct writing to remote process and executing remote thread
• the thread has to set a required hook locally on the process

You're going to have a lot of fun with accessing to remote process with rights allowing you writing and remote code execution. The extra fun is that the code is going to depend on particular Windows version.

You should think twice on accepting this new requirement.

Thank you very much for the suggestions. My initial though on using hooking is because it is the easiest way to inject code into other process, but it is completely out of my estimation that the target process could be run in that way. So I think I have no choice now, I would need to consider send a few code into the remote process in some way.

Thank you again.

[Arjay]

So I think I have no choice now, I would need to consider send a few code into the remote process in some way.

Earlier you wrote:

(actually it is developed by other BU of my company, but I don't have the source, so I need to do that in this way

Why not contact the other group and get them to add an agreed upon inter-process communication approach to their code?