AntiDBG

antidbg is a x64 user-mode anti-debugging library for Windows, designed to protect software from debugging.

Consider the library as a base for your anti-debugging protection, not as your only defense.

The library is:

• Very easy to use (only one function call required).
• Designed for high performance and minimal resource usage (1% CPU usage; <2MB of memory).
• Free of any external dependencies.
• Fully MIT-licensed.
• CFG-compliant.

Structure

The treat model assumes a debugger may intercept software guarded by this protection system from any kind of privilege level, being detections less effective the higher the privilege level is.

This software is hardened to bypass trivial CPL > 0 interception, by:

• Avoiding any kind of API hook via syscalling with inline assembly.
• Enforcing virtual memory protection and injection mitigation policies for the current process.
• Preventing syscall spoofing in RAX by detecting and/or overwritting non-legitimate instrumentation callbacks.
• Detecting any kind of inline patch on monitored .text sections by doing a on-disk vs in-memory comparison.
• Analyzing exception handling delivery (VEH, SEH, LPTOP_LEVEL_EXCEPTION_FILTER) and software breakpoints.
• Testing PAGE_GUARD redirection behavior.
• Protecting important stubs as non-writable memory, monitoring them later with hardware-accelerated hashing on a separate thread.
• Guarding the process entrypoint with TLS callbacks from debugger attachment, performing thread start address inspection.
• Creating traps in debugger entrypoints, such as DbgBreakPoint and DbgUiRemoteBreakin, to crash the process or return.
• Hiding all threads from debugger events and process freeze. Ensures thread priority state is not affected
• Setting a global vectored handler as soon as protections starts.

If the only way to do a check is to use a non-syscallable exported function, the function in question is manually reverse-engineered and reconstructed to run in the module address space of the protection thread. All user-mode memory structures are walked with direct memory instrospection instead of using APIs.

The protection routines explictly leaves some execution paths without protection against user-mode hooks, acting as memory honeypots. They're used for state comparison and to confuse attackers.

Protection routines runs pseudo-randomly. The entropy is decided with pure hardware-based ASLR, stack behavior and a little bit of math; without calling the kernel, using user-mode APIs, or issuing conditionally or unconditionally exiting instructions by hypervisors.

When a security violation is detected, the protection system crashes the current process by invoking INT 29h with STATUS_SXS_EARLY_DEACTIVATION, bypassing all exception handlers. In some cases, it also queues an APC to the kernel in order to terminate the current process.

Detections

Found in the main entrypoint (abdg.c) of this library, explained in order.

Summarized explanations; a specific detection may perform more extra/sub-checks than what it is explained here.

You can find more source code of other detection concepts in the antidebug\archived folder.