1

I've already read related posts such as:

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?

  • I've also failed to break on buttons multiple times. a small workaround I usually take is breaking on GetDlgItemText and GetWindowText. It usually breaks when they read the input to verify it's content. – Amirag Aug 27 '18 at 7:05
  • I remember doing something like that in olly. i manully added a conditional breakpoint of "argument is not the one i'm looking for" (something like [esp+4] != ADDR). that's a lot of manual work so i'd also like to know if someone has a better idea – Amirag Aug 27 '18 at 11:26
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...........
  • it is not some kind of protection any super classed or subclassed routines always behave that way (they are called constantly for every message that is pumped in so your debugger breaks you can always add multiple conditions to breaks – blabb Aug 27 '18 at 21:02
  • use winspy or spy++ to find the window handle and set a condition with message – blabb Aug 27 '18 at 21:07
  • if it is an edit box the system needs to retrieve it with apis try WM_GETTEXT get deep into system set a break in Translate / Dispatch Message Apis or inside ntdll win32k system services like ntUserOneParam some where it needs to show up – blabb Aug 27 '18 at 21:47
  • so doesnt like extensded comments in your screen shot all the hwnd have one common WinProc 0x455578 set a break there and filter message in call stack – blabb Aug 27 '18 at 22:00
1

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):

enter image description here

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):

enter image description here

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):

enter image description here

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.