search

dnSpyEx / dnSpy

Unofficial revival of the well known .NET debugger and assembly editor, dnSpy
GNU General Public License v3.0
6.85k stars 454 forks source link

Improve AntiAntiDebug component by adding more bypasses. #45

Open ElektroKill opened 2 years ago

ElektroKill commented 2 years ago

.NET obfuscators and protectors like to employ "Anti Debug" measures to prevent debugging. dnSpy is currently able to bypass the following methods of checking for a debugger:

Other known ways that can detect the dnSpy debugger:

Potential solutions:

  1. Allow usage of https://github.com/x64dbg/ScyllaHide together with dnSpy to greatly improve the AntiAntiDebug component.
  2. If 1 fails or is not viable, we can manually implement bypasses for the aforementioned methods.
MikeZeDev commented 2 years ago

While we are at it, we may as well try to circumvent https://github.com/0xd4d/antinet ? It could be tricky .

GazziFX commented 2 years ago

what about check for breakpoints by current system time?

ElektroKill commented 2 years ago

While we are at it, we may as well try to circumvent 0xd4d/antinet ? It could be tricky .

Yes, you are right, circumventing antinet will definitely be tricky due to how it works. We can't just hook an unmanaged function as we do with CheckRemoteDebuggerPresent, IsDebuggerPresent, etc.

at about check for breakpoints by current system time?

I'm not exactly sure what you mean by this...

MikeZeDev commented 2 years ago

I'm not exactly sure what you mean by this...

Its that kind of anti debug :

Check system time S1

some code

Check system time again S2

If too much time between S2 and S1 it means there have been pauses during execution, therefore breakpoints or being under a debugger. Not a reliable antidebugger but still used in non managed binaries. The usual method of bypass is faking system time returned by the API.

mastercodeon314 commented 2 years ago

.NET obfuscators and protectors like to employ "Anti Debug" measures to prevent debugging. dnSpy is currently able to bypass the following methods of checking for a debugger:

  • IsAttached and IsLogging properties/methods from the System.Diagnostics.Debugger class.
  • CheckRemoteDebuggerPresent native API.
  • IsDebuggerPresent native API.

Other known ways that can detect the dnSpy debugger:

  • Checking for presence of the dnSpy hooks on CheckRemoteDebuggerPresent and IsDebuggerPresent.
  • CloseHandle native API - passing an invalid handle that is not zero will cause the API to throw an exception only if the process is running under a debugger.
  • NtQueryInformationProcess native API - Used to retrieve the parent process and is often compared to an internal table of known debugger tools.
  • Checking process list for process names that contain dnSpy - Very rarely used in software that is not UnpackMes.
  • Checking for the existence of %APPDATA%\dnSpy\dnSpy.xml file - Very rarely used in software that is not UnpackMes.

Potential solutions:

  1. Allow usage of https://github.com/x64dbg/ScyllaHide together with dnSpy to greatly improve the AntiAntiDebug component.
  2. If 1 fails or is not viable, we can manually implement bypasses for the aforementioned methods.

We can detect dnspy hook for IsAttached property/method from the System.Diagnostics.Debugger class as well. I made a PR for https://github.com/XenocodeRCE/dnSpyDetector with the IsAttached hook detection. Will be implementing IsLogging today as well.