单击按钮后WinDbg中断

Question

Imagine an application that displays a button: OK . Is it possible to break the execution of the program and view the disassembly using WinDbg, right after the button has received a click? How would I do that? In this scenario, the source code is not available.

Answer 1

So, your description is very general, and not very well defined, and the exact research really depends on the application that you are trying to reverse. You will have easier time if you have symbols, but these aren't required.

First, some (trivial) background: Windows communicates with the application through Windows Messages. The application will fetch messages from the message queue, and almost always will dispatch those messages to the appropriate Windows Procedure.

So, first - what do you mean: "right after the button has received a click"? I suspect that you actually don't care about this code. Although your application could have a custom button, and you really care how the button handles a WM_LBUTTONDOWN message. I'm going to assume that your application has a Windows stock button (implemented in user32.dll or comctl32.dll), and that you don't care about that.

The default implementation of a button control handling WM_LBUTTONDOWN is to send WM_COMMAND to the window that contains the button. Typically, the application that you want to investigate handles the "click" there. Now, if this is the 'OK' button, it's ID would be IDOK (defined to be 1), and Windows will send you the same message also when you click the 'Enter' key.

So, we are now looking for how the application handles WM_COMMAND. What you want to find is the Windows procedure. Do that with Spy++. Open Spy and find the Window that contain your button. Most chances that the code you are looking for is in the Windows Procedure of that window. Spy++ will tell you the address of the Window Procedure.

As an example, let's look at the 'Save' button of the 'Save As' dialog in Notepad. On my machine the address is: 0x73611142, which is in ComCtl32.dll

Go to WinDbg, and take a look at the function.

0:000> u 73611142
COMCTL32!MasterSubclassProc
73611142 8bff            mov     edi,edi
73611144 55              push    ebp
73611145 8bec            mov     ebp,esp
73611147 6afe            push    0FFFFFFFEh
73611149 6858126173      push    offset COMCTL32!Ordinal377+0x146 (73611258)
7361114e 68a1b06273      push    offset COMCTL32!DllGetVersion+0x336f (7362b0a1)
73611153 64a100000000    mov     eax,dword ptr fs:[00000000h]
73611159 50              push    eax

This is indeed a function. Like all Windows, it starts with move edi,edi , and then it sets the frame pointer.

Put a break point, hit go, and you'll almost immediately break. Let's take a look:

0:000> bu 73611142
0:000> g
0:000> kb1

ChildEBP RetAddr Args to Child
0101f220 75d87443 00120c6a 00000046 00000000 COMCTL32!MasterSubclassProc

The first argument (00120c6a) is handle of the window. Compare with the value on Spy++, it should be the same. The second argument is the message. In my case it was 0x46 which is WM_WINDOWPOSCHANGING.

OK, I don't care about all those messages, and I want to break only on the messages I care about. You care about WM_COMMAND which is 0X0111 (winuser.h)

Now, put the following (a little bit complex command):

0:000> bu 73611142 "j poi(esp+4)==00120c6a AND poi(esp+8)==111 AND poi(esp+''; 'gc'"
breakpoint 0 redefined

You set a breakpoint on the windows procedure, and you tell WinDbg to break only when the first argument ( that's the poi(esp+4) ) is your Windows handle, and the second argument is 111. The 'gc' tells WinDBG to continue the execution when the condition will not meet.

Now you can debug the disassembly. If you have symbols, you'll have an easier job, but this isn't necessary. In any case, remember to download the Microsoft stripped down symbols from the symbols server, so if the code you are debugging is calling a Windows API, you can see it.

That's about it. Modify this technique if your requirements are different (different Window, different message, etc). As a last resort consider putting a breakpoint on PostMessage or DispatchMessage if you can't reliably find the Windows Procedure (although, you'll have to follow that code). For heavy lifting reversing use IDA, which will disassemble the executable, and solve various cross reference.

Answer 2

Assuming you had the pdbs and they did not have the private symbols stripped then you would set the breakpoint on the button handler like so:

bp myDLL!myWindowApp::onOKBtnClicked

If you had the pdbs then you could search for a likely handler using x:

x myDLL!myWindowApp::*ok*

this presumes that you know or can guess which dll and what the function name is, otherwise you could gleam this information using spy++, Win Spy++ or Win Detective to get the handle for the button and intercept the window messages and from that info set the breakpoint.

Once it hits the breakpoint you can view the assembly code using u , there is a msdn guide if you require it.