View Full Version : Non Standard Dialogs
Zapp
June 2nd, 2005, 00:10
I was just wondering how one would catch data being entered in a textbox if the dialogs aren't from the Win32API (Such as UT's GUI). I see * Reference to USER32.OffsetRect in W32Dasm, but I can't find the 'click event'. I'm not even sure what it'd look like in ASM. Any help or suggestions would be nice.
Zapp
naides
June 2nd, 2005, 05:13
One thing you can try during live tracing is to break on the message that gets generated when a textbox is read.
in Sice try:
BMSG hWnd WM_GETTEXT
You need to obtain the window handle (hWnd) of the text box you want to catch using a window spy utility or using the hWnd command in softIce.
When SoftIce breaks, you are deep into the system code woods. Do not fear.
The Address of the buffer that will contain the text read from the textbox is located in the stack at position ESP + 10. it is the lParam of the WM_GETTEXT Message.
If you type in Sice "dd EBP + 10" the data window will show a 32 bit address like for instance
00343434
Then type "d 00343434" or whatever address you got and you will see the area where the text will be stored when the WM_GETTEXT code is finished. click F12, pRet, and you should see the contents of whatever you wrote in the textbox stored at 00343434. Put a memory read bp there and follow the money. . .
Aimless
June 2nd, 2005, 11:09
You might also try to put a BMSG on the handle of the WINDOW that CONTAINS the text box rather than the handle of the textbox itself if you find that you are not breaking.
Have Phun
Zapp
June 3rd, 2005, 01:51
Unfortunatly those tips didn't work hehe.
I opened the program in Hex Workshop and I found the strings I wanted. They're in Unicode format and Hex Workshop gives me an offset. Well when I opened the program in W32Dasm that offset is invalid. I can't even find it in W32 or Olly. Is there any way to figure out where that string is being loaded? Sorry for the lack of information I'm a wee bit tired

.
Admiral
June 3rd, 2005, 03:21
Hi Zapp.
You may want to check that the address into which the unicode string is loaded remains constant between exectutions of the app. If it does, simply restart your app and break at a point at which you know string hasn't been loaded (at WinMain if you're desperate) and place a 'hardware memory write' breakpoint on one of the bytes where the string is going. You may get a few 'false' breaks as the memory block is initiated or recycled but with a little patience and ingenuity you should find yourself at the right spot before too long (characteristically where the buffer belonging to your string has been filled up as far as your HW but not following it).
Edit:
If the strings you're after are present in the binary's disk image, it should be loaded straight into program memory (indiscriminantly) prior to exectution. Win32DASM doesn't always handle these things too well, but a simple unicode memory search at initialisation stage should bring up the string resource location in OllyDbg. If you can't find it in the RSRC section, try blasting the entire allocated memory - it doesn't take a second.
Regards
Admiral
esther
June 3rd, 2005, 11:54
Hi,
You might try your luck on hiew search the hex string(unicode) you might able to find.
Kayaker
June 3rd, 2005, 13:24
Quote:
how one would catch data being entered in a textbox
I can't find the 'click event'. |
Quote:
I opened the program in Hex Workshop and I found the strings I wanted. |
Now you're just confusing us. The first 2 people who tried to help gave good advice in the case you were trying to catch text entered by the *user*, which is what your first post sounded like. The second 2 people gave good advice for the case the text was being entered by the *program*, which seems to be what was actually meant. Details *are* important!
Quote:
Is there any way to figure out where that string is being loaded? |
There's a chance that text drawing functions such as DrawText/TextOut are being used. Check the imports used and use an API monitor such as APISpy32. I don't know what you're trying to catch under what conditions, but the API monitor (which you can halt until such time you want to activate it) may log the exact string, API and offset. A direct memory access breakpoint as suggested might work as well.
Kayaker
Zapp
June 3rd, 2005, 15:35
Yes I know. I'm trying serveral different approaches. I was originally planning on watching the text entered into the box. While doing that I was messing around with the hex editor and I saw that string that caught my attention. I guess I could have mentioned that in my previous post. Sorry for the confusion and ALL input is greatly appreciated. Just bare with the poor novice
Zapp
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.