How to reach functions triggered by non-standard buttons?

Question

I've already read related posts such as:

• link1: https://stackoverflow.com/questions/24138087/how-can-i-set-a-breakpoint-for-a-button-click-using-ollydbg
• link2: How can I set a breakpoint for a button click?

Unfortunately, none of them helped me out to solve my doubts. My goal here is learning the most possible generic method to jump onto routines triggered by non standard buttons (created by any kind of UI framework).

In order to ilustrate my concern I've created a dummy crackme - (in a range 0-10 I'd say level -1 :))

For this exercise to be really useful let's assume:

• The "crackme" doesn't contain any hardcoded serial you can use
• The "crackme" doesn't contain any activation message you can use to inspect the code around
• BMSG such as WM_PARAM/WM_LBUTTONUP, BT_CLICK won't do it

I've created this little mcve to ilustrate better my real concern, on the real-world case I'm working on I'd like to read the routine triggered by a button from the beginning to end in order to decode the algorithm used.

So yeah, the question would be, what are the methods to deal with this particular problem?

Answer 1

open crackme in windbg set a bp on GetWindowTextW and run enter some fake data and hot register button on break go up to the next frame which called the function

:\>cdb crackme1.exe

Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
0:000> bp USER32!GetWindowTextW
0:000> g


Breakpoint 0 hit
*** WARNING: Unable to verify timestamp for D:\crackme1.exe
*** ERROR: Module load completed but symbols could not be loaded for D:\crackme1.exe

USER32!GetWindowTextW:
772db8c5 6a08            push    8
0:000> dd esp l4
015ef760  005312bf 000603a8 000bb324 0000000c
0:000> dc bb324 l8
000bb324  00650052 00690067 00740073 00720065  R.e.g.i.s.t.e.r.
000bb334  00690000 00000074 00000000 abababab  ..i.t...........

0:000> gu
eax=0000000b ebx=00118988 ecx=772db928 edx=00000030 esi=015efa4c edi=015efa5c
eip=005312bf esp=015ef770 ebp=015ef7b0 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
crackme1+0x1312bf: <<<<<<<<<<<<<<<<<<
005312bf 8945f4          mov     dword ptr [ebp-0Ch],eax ss:0023:015ef7a4=0000000b
0:000> dc bb324 l8
000bb324  00610079 006b006b 00200075 00610062  y.a.k.k.u. .b.a.
000bb334  006b006b 00000075 00000000 abababab  k.k.u...........

Answer 2

The problem here is not to solve the crackme, but to find the handler of the "Register" button. I describe what could be done to find the button handler. There is probably no "generic" standard procedure working in all similar cases.

However, although this is a special case, I assumed normal "generic" windows message behaviour. In that case I can expect somewhere a WM_LBUTTONX message, X being UP or DOWN, with values 0x201 or 0x202. Thus I searched statically for the value 200h in Ida, this being the start of the "Mouse group" in the Windows WM_ messages set.

There are a number of locations found where a compare is made with 0x200. On these I set a breakpoint. Two of these are hit on mouseclicks, and one of them investigates explicitely 0x201 (WM_LBUTTONDOWN) and 0x202 (WM_LBUTTONUP):

If you step futher down the WM_LBUTTONUP path you come directly to the following location, with a call to f_someMsgHandler (as I called it):

This function is called on several occasions, but the one corresponding to the mouse event is easily found, e.g. by setting a selective breakpoint. In this function, the following location leads directly to the handler of WM_LBUTTONUP of the "Register" button, being located at address 0x4fead0 (that address unfortunately hidden in the tooltip):

To solve the crackme, it would possibly be easier to look for something like "GetWindowText".

This shows, that in contrast to the OP's remark, it is very well possible to follow the trace of the standard windows mouse messages in order to find the proper handler.