search

x64dbg / x64dbg

An open-source user mode debugger for Windows. Optimized for reverse engineering and malware analysis.
http://x64dbg.com
Other
44.53k stars 2.42k forks source link

Altering hardware breakpoints within NT entrypoint can result in invariant violation #2468

Open ishitatsuyuki opened 4 years ago

ishitatsuyuki commented 4 years ago

Commit: bfe6367 OS: Windows 10 2004 64-bit running x32dbg

Windows's entrypoint implementation contains an infamous call to NtContinue that switches the whole CONTEXT (related info) and in particular, it causes hardware breakpoints to break as it rolls back any changes to debug register that happened after executable launch and before the actual entrypoint is called. This causes the debug registers and the breakpoint records in x64dbg to become out of sync, causing various weird issues.

Reproducing this issue is as easy as doing the following:

I'm not sure what we can do to fix this. One option is to hook the NtContinue call to avoid any disruptions to the debug registers. Other options include postponing setting hwbp until the actual entrypoint is reached, or disallowing making changes to hardware breakpoints until the actual entrypoint is reached.

mrexodia commented 4 years ago

I guess one workaround would be to delay setting hardware breakpoints to a breakpoint after NtContinue, but I’m not really sure what the best way to fix this would be...

On Fri, 2 Oct 2020 at 17:41, Ishi Tatsuyuki notifications@github.com wrote:

Commit: bfe6367 https://github.com/x64dbg/x64dbg/commit/bfe6367592ea114e9816bdb86ce5e688ccbd7329 OS: Windows 10 2004 64-bit running x32dbg

Windows's entrypoint implementation contains an infamous call to NtContinue that switches the whole CONTEXT (related info https://stackoverflow.com/questions/41392014/what-does-windows-do-before-main-is-called/41396596) and in particular, it causes hardware breakpoints to break as it rolls back any changes to debug register that happened after executable launch and before the actual entrypoint is called.

Reproducing this issue is as easy as doing the following:

  • set a hardware breakpoint while the target is running.
  • restart the target. x64dbg will pause at the NT entrypoint.
  • delete the hardware breakpoint we set on last execution.
  • the target will generate an unhandled SINGLE_STEP exception and as x64dbg thinks that the hwbp is already deleted, it will refuse to handle the exception and just let the application terminate.

I'm not sure what we can do to fix this. One option is to hook the NtContinue call to avoid any disruptions to the debug registers. Other options include postponing setting hwbp until the actual entrypoint is reached, or disallowing making changes to hardware breakpoints until the actual entrypoint is reached.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/x64dbg/x64dbg/issues/2468, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASYFGL2TH2EDO2O4NV3QY3SIXYCPANCNFSM4SB3ALKQ .