BugSlasher

A few days ago, I had to break into a graphic application just after I clicked on a button. Sadly I didn’t have the source code, so my purpose was just to get the name of the applicative function called just after a user event (in my case, a click). Of course, when the function handling an event is called, I expect to see a Windows user mode function in the call stack. So I designed a small MFC application with just a button, made a function named OnBnClickedButton to handle clicks, added a breakpoint on this function, and tried to find on the call stack which function is always called when an application process an event.

I eventually found USER32!SendMessageW, and I was quite happy with it: this function is well-known for every MFC programmer because it allows you to send a Windows message to any application (including yours). A click on a button is of course a Windows message, and I was pretty sure I found my entry function. So I started the former graphic application, attached to it with WinDbg, and try to get the focus back to my application so I can click on the button. Sadly, my debugger broke before I could…why? Well, trying to put the focus on an application that is not visible triggers (at least!) a WM_PAINT message, processed by USER32!SendMessageW. And it is not the only one: a simple graphical continually receives A LOT of various messages. I clearly had to break only on a specific message. Hopefully the prototype of USER32!SendMessageW is well known: the second parameter is an unsigned int containing the message ID. Sounds nice, but how can you break on a function ONLY when a parameter have a specific value?

Read more…