Anti-Debug Techniques Catalog

Programs that don't want to be debugged use checks like these to detect a debugger and act differently when they find one. Game anti-cheat, malware, DRM, and some commercial software all rely on the same playbook. Each card below shows one technique: what it reads from memory or the OS, how a debugger makes that value change, and the standard ways to defeat it.

Quick orientation: what is "anti-debug"?

When you attach a debugger like x64dbg, IDA, or WinDbg to a running process, the operating system changes a few small flags so the kernel knows to send debug events your way. Anti-debug techniques are just code that checks for those flags (or for the side effects of having a debugger nearby). If a check trips, the program might exit, change behavior, throw a fake error, or feed the debugger fake data to waste your time.

There are dozens of these checks, but they fall into a few families: API-based (call a Windows function that asks the OS), PEB-based (read the flags directly without calling an API), behavioral (measure how slowly the code runs), hardware-state (look at debug registers), and code-integrity (check whether the program's own code has been modified).

The catalog below covers the ten you'll meet most often. Each card includes a stealth rating (how easy it is to spot when reverse engineering the program) and a bypass difficulty rating (how easy it is to defeat once you've found it). For most beginner targets, ScyllaHide (a free x64dbg plugin) automatically handles the easy ones.

What's next after these?

The checks above are the "starter pack". Real-world anti-cheat and commercial obfuscators stack dozens of these (often custom and undocumented), combined with code obfuscation, virtual machines, and kernel-mode drivers that can see the whole system. Tools like ScyllaHide handle the well-known ones automatically; against custom checks you'll be patching them out one at a time.

Two general bypass principles to internalize: