Attatching to a Process.....or something

Say what? I think what you want to do is have one program that has a window and a text field, and another program which completely unrelated code that can read (and maybe write?) to that text field.

It can be done, hacker's do it all the time and for more complicated stuff than text, but it's difficult, especially if you don't have the code for the former application.

Not coming from a windows background I can't tell you how to do it in that OS, and I'm not even sure that's possible in *nix operating systems.

Well, I think you just need the hwnd of the window containing the text, then you can get it with getwindowtext. to get the hwnd I maybe you can call enumwindows, and then enumchildwindows.

Note: Even if this works at all, I'm sure it won't work with password fields.

If it is a console application you need to do the following:

create StdOut_Read & StdOut_Write pipe handles.
Use DuplicateHandle to make StdOut_Write handles inheritable.
Call CreateProcess() to start the application making it inherit the StdOut_Write handles.
Monitor the StdOut_Read handle for the created text. Be aware that unless the console app calls flush(StdOut) regularly the text will arrive sporadically if not all at the end of the app.
Clear up handles when the app finishes.


If it is a windows application and a std text control do the following:

Use nested calls to FindWindowEx() to get a handle to the window you are after.
eg: to find the start button in the task bar: HWND TaskBar =FindWindowEx(NULL, NULL, "Shell_TrayWnd", ""); HWND StartButt =FindWindowEx( TaskBar, NULL, "Button", "Start" ); ::SetWindowText( StartButt, "Stop" )

Use ::GetWindowText() to get the latest text in the window.

> Note: Even if this works at all, I'm sure it won't work with password fields.

As strange as it may sound, that method will work on password fields. The rendering of the control simply does a strlen(GetWindowText()) and writes a bunch of asterisks, but GetWindowText() will return the actual password. After all, the owner of the password control has to be able to get the password!

This is a bit of a security flaw - making it accessible to other software running on the same machine - and there are several ways to get around it with custom controls that put garbage into the window text and store the real password somewhere else.

Hello,
Thanks for all your replies.

I'm not actually looking for passwords, but I guess that's nice to know..

I found the HWND, and then did a EnumChildWindows, on every single window in the application recursively also running GetWindowText looking for the text i'm trying to capture.....and still didn't find the text...is there another way or something?

I'm not real bright on Windows32 programming, so I'm not really sure if i'm overlooking something..

Thanks
Ratings++

This might help: winspy.

GetWindowText obtains the text in the title bar or in the client area of an edit control so the results will vary from window to window. If the window you're targeting outputs text using TextOut or related GDI functions, grabbing it won't be so easy.

Quote:

Original post by nemesisgeek > Note: Even if this works at all, I'm sure it won't work with password fields. As strange as it may sound, that method will work on password fields. The rendering of the control simply does a strlen(GetWindowText()) and writes a bunch of asterisks, but GetWindowText() will return the actual password. After all, the owner of the password control has to be able to get the password! This is a bit of a security flaw - making it accessible to other software running on the same machine - and there are several ways to get around it with custom controls that put garbage into the window text and store the real password somewhere else.

http://www.codeproject.com/dll/pwdspy.asp

Quote:

If you send a WM_GETTEXT message to a password control, the text returned is the actual password not the "****" displayed in the control. This sneaky technique works great on Windows NT/95/98/ME, but on Win2K/XP Microsoft has added security. On Win2K/XP if you send a WM_GETTEXT message to a password control, it first checks the calling process to determine if it has access. If the calling process is the same process as the one that created the password control, the WM_GETTEXT message still returns the password. However, if the calling process is different, then the return is ERROR_ACCESS_DENIED. So the key to retrieving the password in Win2K/XP is to get your WM_GETTEXT message to come from the same process as the password control and not from PasswordSpy. One way to execute your code in the context of another process is through the use of Windows hooks.

Although I know this isn't much of an improvement. Also, it IS codeproject, after all, and I can't find any reference on msdn, so might not be accurate. Although it makes sense.

Tell us more about the target application. Different types of text will require vastly different spying methods. It'd be very helpful if you could post a screenshot.

Admiral

Thanks LessBread for that program idea.

I learned that it was a RICHEDIT control, but GetWindowText on it returns nothing.

I also know this application is an MFC App. I'm not sure if that is significant.

Any idea how to read the text in it now? This WinSpy++ has the right text come up in the Caption textbox...What function is that using to grab the text?


I'm sorry if this has turned to a dumb question...I did try googling for RICHEDIT and similar things with no good results. I've not really used Win32 much, I'm actually doing all this in C#, by importing the functions...so bare with me please.

Thanks

ArchG

Quote:

Original post by ArchG Any idea how to read the text in it now?

Try sending WM_GETTEXT to the control in question (via SendMessage). You might also find the WM_GETTEXTLENGTH message useful.

what you are talking about is called hooking, to do this you need to het the window handle. once you have the window handle you can basicly do what you want with it.

altho i have never used this to get text i have done it to write text to another program. it shouldn't be to hard to reverse the procedure.

you can use the FindWindow() function to get target the window(by the window name not the process), then use GetWindowThreadProcessId() and OpenProcess() to give yourself access to the window.