1

The application I target has terribly annoying anti-debugging techniques. With x32dbg and ScyllaHide with the following configuration, the application exits immediately as soon as a breakpoint is hit, whether it is a software or hardware breakpoint.

The following are my settings:

ScyllaHide settings

A VEH debugger (I tried Cheat Engine) catches the exception. However, when it catches the exception, the Cheat Engine debugger shows the call stack as "empty" with a single setting showing 0x00000000 as the return address, so it's useless. However the exception code is 0xC0000005 so I know it's access violation.

What other anti-anti-debugging techniques can I use to get past the mechanism where the application crashes when a breakpoint gets hit?

shavit
  • 111
  • 2

2 Answers2

1

You can use JIT framework such as intel PIN to inspect the program with greater granularity. Then you can find the exact mechanism responsible for this, including finding the real call history, used to detect the breakpoint and crash the program

MkInitCpIO
  • 11
  • 1
1

Edit: Since this is about when the breakpoint is hit.

The kernel guarantees the debugger a chance to handle exceptions (e.g. breakpoint exceptions) before letting the debuggee handle them. Are you sure that the debugger is actually attached when the breakpoint is hit?

An exception to what I stated above is that if ThreadHideFromDebugger is used, then the kernel will skip sending the exception to the debugger. That could be what's happening. It's a common technique used in anti-RE in games.

You may see a crash log in Event Viewer with a breakpoint exception (0x80000003), but only if the debuggee doesn't have registered exception handlers that swallow the exception and then exit.

P. Private
  • 180
  • 3
  • 14
  • I injected a DLL to the app and placed a detour on NtSetInformationThread, seems like it is being set with 0x11. Upon further investigating seems like it is caused by Themida (the sample was protected with it). I was able to debug by preventing NtSetInformationThread as well as replacing several functions such as DbgUiRemoteBreakin and DbgUiBreakPoint with the original implementations, but then Themida itself seems to crash the sample and exit it abruptly. – shavit Apr 29 '20 at 07:16