I recently came across this anti-debug technique being used in the wild.

In The Ultimate Anti-Debugging Reference, the author wrote in the "Instruction Counting" section

A debugger will interfere with the single-stepping, resulting in a different count of instructions compared to when a debugger is not present.

From experimenting with this technique a bit, it seems that when you set a hardware breakpoint in x64dbg, the debug registers of all threads are not only set, but also frozen - so that for example - if the program calls SetThreadContext to change these registers, x64dbg seems to change them back.

Given how x64dbg works, and that the technique relies on these debug registers, isn't this technique limited to detecting the presence or modification of hardware breakpoints?

  • About x64dbg, the debug registers aren’t written back if the debuggee modifies them. Probably the GUI wasn’t refreshed or something.
    – mrexodia
    Sep 3, 2018 at 20:27
  • Detecting the presence of the breakpoints is more obvious than counting the instructions, and counting the instructions can be used to introduce side-effects if the count is wrong. Sep 7, 2018 at 19:06


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.