View Full Version : Window creation woes

November 10th, 2008, 12:55

I'm trying to eliminate a nag screen. It appears once upon opening the application, and then not again. However, I believe I'm being led astray by a non-standard method of window creation.

The program is written in VC++ 6.0, and I've determined via ResourceHacker that the dialog (nag screen) in question is not pre-built.

I've set breakpoints on all (three) calls to CreateWindowExA and watched the lpClassName change in Olly to see if I could catch when the nag screen class shows up. It does not. I know the class name via View->Windows in Olly.

I then set a message bp on the ClassProc of the nag screen for window creation and destruction. The message that breaks when I destroy the nag screen:

Stack snapshot:

0012F644 7E418734 /CALL to Assumed WinProc from USER32.7E418731
0012F648 007A03B8 |hWnd = 007A03B8 ('UNREGISTERED COPY',class='#32770',parent=042C01F6)
0012F64C 00000002 |Message = WM_DESTROY
0012F650 00000000 |wParam = 0
0012F654 00000000 \lParam = 0

(note the class name '#32770' -- that's the nag screen class name. Is this information identifying for the application in any way? If so, I will promptly remove it and replace it with something more generic)

BP (in module USER32):

7E43E579 55 PUSH EBP
7E43E57C 8B4D 08 MOV ECX,DWORD PTR SS:[EBP+8] ; USER32.DefDlgProcA
7E43E57F E8 5C9FFDFF CALL USER32.7E4184E0

I don't know if this is any use to me.

Next I set breakpoints on DefWindowProcA calls in the module and watch the hWnd value in Olly until my class name shows up. Sure enough it does this time, only never with a WM_CREATE but with a WM_WINDOWPOSCHANGING. The class name shows up several times with different hWnd values here, always with the same message. Upon completion of the last one, the entire application shows up, along with the nag screen on top of it. So I view the call tree from that DefWindowProcA call and get a call from the main app module. That call looks like:


004DF3A7 . FF7424 0C PUSH DWORD PTR SS:[ESP+C] ; /Arg1 = 0012F1E8
004DF3AB . 8BC7 MOV EAX,EDI ; |
004DF3AD . 80E4 F0 AND AH,0F0 ; |
004DF3B0 . 8946 64 MOV DWORD PTR DS:[ESI+64],EAX ; |
004DF3B3 . E8 3AD5FFFF CALL appname.004DC8F2 ; \appname.004DC8F2

With the obvious identifying information removed.

My question is...what steps can I take next? I'm not sure how to simply "skip" a call to nag creation if one generic method is used to create/display the window (am I correct about that?) and I can't simply remove the resource because it's created at run-time.

I don't know if I've included enough information in this post to receive help, or if I've posted more than is needed, or if the snippets I posted are the appropriate ones. At any rate, I appreciate any help or pointers passed my way.

If nothing else, the underlying question in all of this is: do I have a legitimate approach? Or, if I don't, what are some key terms or phrases I can use to research in the correct direction?


PS: the nag screen's parent window is of class 'Afx:400000:8:10011:0:1f60463'. What is that?

November 10th, 2008, 19:32
#32770 is the class name for dialogs. Check for the CreateDialog* functions. Afx was the original name of the MFC framework, so your program is using MFC. Such names are created by AfxRegisterWndClass().

November 11th, 2008, 14:22
#32770 is a system class for DialogBox iirc you might find this link posted here for similar question earlier if you searched
because ms is notorious for scrapping urls regularly
ill post it again



The following table describes the system classes that are available only for use by the system. They are listed here for completeness sake.

Class Description
ComboLBox The class for the list box contained in a combo box.
DDEMLEvent Windows NT/Windows 2000/Windows XP: The class for Dynamic Data Exchange Management Library (DDEML) events.
Message Windows 2000/Windows XP: The class for a message-only window.
#32768 The class for a menu.
#32769 The class for the desktop window.
#32770 The class for a dialog box.
#32771 The class for the task switch window.
#32772 Windows NT/Windows 2000/Windows XP: The class for icon titles.

DefDialogProc is a handler that handles unhandled messages by the DialogProc you wont find anything usefull in that call


its like
if WM_COMMAND() \\ some command that's usefull for me so i handle
Do this
else if WM_USER+$@# \\ MyDefFor Registering Crap
DefDialogProc() \\ nothing usefull just send it back to system via laundry

most of the mfc things are subclassed
so you have to find where the subclassed or superclassed DialogProcExists
(look for switches , switch bases when you meet defdlgproc , find the jump paths )

and you will find the real call or comaparison

November 12th, 2008, 20:51
Well. This so far has been turned out to be far more complex than I had originally anticipated. I decided to abandon the tactic of setting breakpoints on intermodular calls like CreateDialog, Window, etc. Instead, I stepped through the program until the nag popped up, set a breakpoint, restarted the app, stepped into the call, rinse and repeat. I believe this to be a more legitimate technique for this purpose, anyhow.

So, by doing that I've narrowed down more precisely in the application where the nag dialog is being created. The only problem is...there's nothing remotely similar to "CreateDialog" or Window or ShowWindow or anything really at all related to windows or dialogs.


004D1DA8 |> 8B06 |/MOV EAX,DWORD PTR DS:[ESI] ; appname.004FE4B0
004D1DAA |. |8BCE ||MOV ECX,ESI ; appname.005307D8
004D1DAC |. |FF50 5C ||CALL DWORD PTR DS:[EAX+5C] ; Drawing window components
004D1DAF |. |85C0 ||TEST EAX,EAX ; appname.004FE4B0
004D1DB1 |. |74 27 ||JE SHORT appname.004D1DDA
004D1DB3 |. |8B06 ||MOV EAX,DWORD PTR DS:[ESI] ; appname.004FE4B0
004D1DB5 |. |8D6E 30 ||LEA EBP,DWORD PTR DS:[ESI+30]
004D1DB8 |. |55 ||PUSH EBP
004D1DB9 |. |8BCE ||MOV ECX,ESI ; appname.005307D8
004D1DBB |. |FF50 64 ||CALL DWORD PTR DS:[EAX+64] ; appname.004D1DE7
004D1DBE |. |85C0 ||TEST EAX,EAX ; appname.004FE4B0
004D1DC0 |. |74 07 ||JE SHORT appname.004D1DC9
004D1DC2 |. |6A 01 ||PUSH 1
004D1DC4 |. |895C24 14 ||MOV DWORD PTR SS:[ESP+14],EBX
004D1DC8 |. |5F ||POP EDI ; appname.004D17B5
004D1DCA |. |53 ||PUSH EBX ; |MsgFilterMax = MSG(FFFFFFFF)
004D1DCB |. |53 ||PUSH EBX ; |MsgFilterMin = MSG(FFFFFFFF)
004D1DCC |. |53 ||PUSH EBX ; |hWnd = FFFFFFFF
004D1DCD |. |55 ||PUSH EBP ; |pMsg = 0012FFC0
004D1DCE |. |FF15 F0C74F00 ||CALL DWORD PTR DS:[<&USER32.PeekMessageA>; \PeekMessageA
004D1DD4 |. |85C0 ||TEST EAX,EAX ; appname.004FE4B0
004D1DD6 |.^\75 D0 |\JNZ SHORT appname.004D1DA8

This code snippet is what I've narrowed it down to. It loops, and the line I've bolded is a call that draws components on the main window. Before this there was a call to display the actual window, but with no toolbar, scroll bar, etc. This function is what draws all of those components. However, after numerous loops, one call to this bolded function displays the nag dialog (without components). Subsequent calls to the same function draw the components (labels, buttons, etc) into the nag dialog.

The bolded function in question:

004D2254 . 56 PUSH ESI ; appname.005307D8
004D2255 . 8BF1 MOV ESI,ECX ; appname.005307D8
004D2257 . 33C0 XOR EAX,EAX ; appname.004FE4B0
004D2259 . 57 PUSH EDI ; appname.005307D8
004D225A . 50 PUSH EAX ; /MsgFilterMax = 4FE4B0
004D225B . 8D7E 30 LEA EDI,DWORD PTR DS:[ESI+30] ; |
004D225E . 50 PUSH EAX ; |MsgFilterMin = 4FE4B0
004D225F . 50 PUSH EAX ; |hWnd = 004FE4B0
004D2260 . 57 PUSH EDI ; |pMsg = appname.005307D8
004D2261 . FF15 14C74F00 CALL DWORD PTR DS:[<&USER32.GetMessageA>] ; \GetMessageA
004D2267 . 85C0 TEST EAX,EAX ; appname.004FE4B0
004D2269 . 74 26 JE SHORT appname.004D2291
004D226B . 817E 34 6A030000 CMP DWORD PTR DS:[ESI+34],36A
004D2272 . 74 1A JE SHORT appname.004D228E
004D2274 . 8B06 MOV EAX,DWORD PTR DS:[ESI] ; appname.004FE4B0
004D2276 . 57 PUSH EDI ; appname.005307D8
004D2277 . 8BCE MOV ECX,ESI ; appname.005307D8
004D2279 . FF50 58 CALL DWORD PTR DS:[EAX+58] ; appname.004D1FCA
004D227C . 85C0 TEST EAX,EAX ; appname.004FE4B0
004D227E . 75 0E JNZ SHORT appname.004D228E
004D2280 . 57 PUSH EDI ; /pMsg = WM_CREATE hw = 4FE4B0 pCreate = NULL
004D2281 . FF15 18C74F00 CALL DWORD PTR DS:[<&USER32.TranslateMessa>; \TranslateMessage
004D2287 . 57 PUSH EDI ; /pMsg = WM_CREATE hw = 4FE4B0 pCreate = NULL
004D2288 . FF15 ECC74F00 CALL DWORD PTR DS:[<&USER32.DispatchMessag>; \DispatchMessageA
004D228E > 6A 01 PUSH 1
004D2290 . 58 POP EAX ; appname.004D17B5
004D2291 > 5F POP EDI ; appname.004D17B5
004D2292 . 5E POP ESI ; appname.004D17B5
004D2293 . C3 RETN

My question is...what is this function doing? How can it get creation messages for these components on the fly? Also a tidbit about this function, once all the components are drawn on everything, Olly shows "running". As soon as I move my mouse to the application, Olly immediately breaks on the 4D1DAC line, where I have a software breakpoint. This means that the function is also handling waiting for user input?

Thanks in advance for any pointers, or indeed any information whatsoever.

November 13th, 2008, 01:31
that is the classic message loop it simply recieves (PeekMessage(),TranslateMessage(),....,....,...) and passes it to the handler (DispatchMessage,PostMessage,SendMessage(),....,....,)

you need to find the callback thats handlind these messages

November 16th, 2008, 19:48
Import the symbols for mfc*.dll into your olly and look for CCmdTarget::OnCmdMsg. That's where all your message for every window is being processed. You can set a conditional bp on the call to AfxFindMessageEntry to filter only the messages of your interest and work from there...