New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardware (write) breakpoints behave very unreliable #2014

Open
0xEmanuel opened this Issue Aug 31, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@0xEmanuel

0xEmanuel commented Aug 31, 2018

Hello, I have following issue:

Most of the time x64dbg does not break on a Hardware write breakpoint, although we know that at the specified address occurs a write. In very few cases, it had worked (like 1 of 15 tries).
Immunity Debugger works always, with the exact same settings.

Debugger version: Aug 28 2018, 18:39:55 (using x32dbg)
OS: Microsoft Windows 10 Pro, Version 10.0.17134 Build 17134, x64 (Running inside VirtualBox)
(!Malware!) Sample (SHA256): 3809394dceddbe1419e964cd08397e5fed4a0bbefc8be466f33614bac8794243 (x86)

Reproduction:

  • Use some Anti-Anti-Debug plugin (like ScyllaHide), since this sample uses an Anti-Debug method (you would get an ACCESS_VIOLATION_EXCEPTION without ScyllaHide)
  • Since this process is running without ASLR, it is going to be mapped always to the preferred image base which is: 00400000
  • Since we know that the unpacker will write to 00400114 we can set here a hardware write breakpoint (word).
  • Now run the debugger. x64dbg will unfortunately not break, although we know that the sample is writing to that specified area.
  • Immunity debugger works perfectly with the same reproduction steps ("!hidedebug all_debug", to bypass anti-debug, and set same HW BP)
@M-o-o

This comment has been minimized.

Show comment
Hide comment
@M-o-o

M-o-o Sep 1, 2018

Not just write breakpoints - hardware read breakpoints don't seem to work at all for me (x64, Aug 21 2018 version). I tried running without plugins, running as administrator, and starting the target from the debugger, with no change. I even wrote and debugged a little test program to make sure there wasn't something strange about my targets that was interfering, but the breakpoints didn't work there either.

M-o-o commented Sep 1, 2018

Not just write breakpoints - hardware read breakpoints don't seem to work at all for me (x64, Aug 21 2018 version). I tried running without plugins, running as administrator, and starting the target from the debugger, with no change. I even wrote and debugged a little test program to make sure there wasn't something strange about my targets that was interfering, but the breakpoints didn't work there either.

@mrexodia

This comment has been minimized.

Show comment
Hide comment
@mrexodia

mrexodia Sep 1, 2018

Member

I tested on my local machine and confirmed that stepping after a hardware breakpoint will resume execution. I cannot reproduce any issues with hardware breakpoints not triggering though.

Member

mrexodia commented Sep 1, 2018

I tested on my local machine and confirmed that stepping after a hardware breakpoint will resume execution. I cannot reproduce any issues with hardware breakpoints not triggering though.

@mrexodia mrexodia added the bug label Sep 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment