Jump to content
Tuts 4 You

Set a breakpoint for a visual element in x64dbg


Aldhard Oswine

Recommended Posts

Aldhard Oswine
Posted

How can I set a breakpoint for a button click or input field in x64dbg?

Posted

You cannot. You can put breakpoint on locations in the code. If you find the window procedure you can put a breakpoint there.

  • 2 weeks later...
Posted

If you have an input field you can have a think about what the program might be doing in the background. At some point (whether on button press or keypress) the program needs to grab that data from the text box.

 

Work out what APIs the program might be using for this and breakpoint on them - use some intuition and start tracing. You'll find it

 

Posted

If its raw win32 exe and not using some other packaging with wrapper dll's for frameworks (Qt, python etc) then some api functions or messages to consider looking for might be:

GetCapture
WM_LBUTTONDOWN
WM_LBUTTONUP

And BN_CLICKED notification code of the WM_COMMAND message for some buttons

For text input some api functions and/or messages to look for are:

GetWindowText
GetWindowTextLength
GetDlgItemText
WM_GETTEXT
WM_GETTEXTLENGTH

 

 

  • Like 1
  • 3 years later...
Posted

Easiest way if the program was written in an event based programming language is to use a message breakpoint.

In x64dbg go to the Handles tab and refresh, select the correct window Handle (use Winspector to get that info) for the element you want and then right click on it and set a memory breakpoint to trigger on that instance only and on the correct windows message.

WM_LBUTTONUP/DOWN is a common event, others are WM_COMMAND etc.

 

To test: select a textbox Handle and set a memory breakpoint for WM_KEYUP, the program should pause right after you release the key from keyboard.

The program will break inside windows API code, chances are you will want to be in user code if the program isn't using anti anti-debug techniques

To get inside user code from where the code breaks is as simple as using a shortcut Alt+F9 (Run to user code), that will drop you exactly where you want to be, or at least as  close as you can get with a memory breakpoint

Posted

Another thing:

You can use a spy utility like Winspector (mentioned earlier) to find the correct window handle BUT, also to get the WM message being used.  The WM message might not be WM_COMMAND as it usually is, most developers that write code that they don't want analysed will perform various methods to make it as hard as possible for you to reverse their software.

Or they will use 3rd party software to jummble the code and lots of other methods invented to detect and avoid debuggers.

In this case you might find that the code you are looking is in weird places and started by windows messages other then the usual ones.

If you had to add message breakpoints for every message type it would be frustrating AF.

So open Winspector and find the correct handle using the "Click and drag" function.

then right click and select 'Message' -> a new window will open.  The idea is to get all the windows messages being sent by that particular handle to windows API's so you can track down which message is being used.

These spy utilities are often glitchy and I ran into a problem as I was writing this article.
I tried to get the messages being sent by notepad.exe and came up with no output.  Turns out it was the architecture of the notepad executable being used by windows 10.

I haven't don't the research on exactly why this is happening but using ...\system32\notepad.exe (which is supposed to be the x86 architecture) I got no output from a 64bit OS but got output from ...\SysWow64\notepad.exe (the x64 version).  

Anyway if I want to find the message that corresponds to typing the letter 'a' into the notepad editor, it will go something like this:

1.jpg: all messages displayed with no filter

1.jpg.68a45c901383100382b0d3c1e5a9a790.jpg

 

2.jpg: after message filter was applied to capture the message for capturing a keydown event when I type something into the textbox ('a' key was pressed)

2.jpg.c655d1fcb5e17e2aef54c8575f3a28ab.jpg

 

I hope this helps you

  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...