Comments on: Anti-debugging: using up a resource versus checking it

By: Nate Lawson

Nate Lawson — Mon, 04 Aug 2008 18:43:25 +0000

Yes, if other parts of the same app used IsDebuggerPresent() in the traditional way, they would get incorrect results. However, since the PEB is local to process memory, it would only affect that single application. So the programmer would know not to use this API the traditional way.

By: JB

JB — Fri, 01 Aug 2008 08:52:30 +0000

Nate, thank you for the response. Please correct me if I am wrong. Yes, the hypothetical (our) protection would not call IsDebuggerPresent() (only using PEB!BeingDebugged implicitly as a resource like you emphasized) but other non user written functions or even Windows system APIs within the same process (thus the same PEB) would. And when those calls happen, wouldn’t non-zero values give unintentional results (e.g. debugger found, do something bad…)? To avoid that, PEB!BeingDebugged has to stay as 0. Then, using 0 as the offset in a jump table would not make any sense as that’s what an attacker might try changing the value to.

By: Nate Lawson

Nate Lawson — Thu, 31 Jul 2008 19:48:27 +0000

JB, you’re missing the point. The hypothetical protection would never call IsDebuggerPresent(). It would implicitly depend on the value stored in PEB!BeingDebugged to be some number (say “145″), since it would use that as an offset in a jump table. When PEB!BeingDebugged was overwritten (with 1 by the OS or 0 by the attacker trying to hide), both values would cause the program to go down a path that eventually leads to the program stopping. Specifically, the entries at offset 0, 1, and maybe 0xff in your jump table would lead to failures.

There are problems with this specific example (due to an attacker being able to attach early) but the general principle is what I’m trying to illustrate: implicit (use of a resource) rather than explicit (checking it) protection.

By: JB

JB — Tue, 22 Jul 2008 03:29:33 +0000

Nate, a question here. From my understanding, IsDebuggerPresent() returns TRUE when PEB!BeingDebugged field is a non-zero value. By storing a value (e.g. offset to a jump table, non-zero value), wouldn’t it make IsDebuggerPresent() also return TRUE? Say, before an anti-anti debugging method replaces it with zero and before our timer has a chance to run to it and crash, any IsDebuggerPresent() calls from outside (I believe some system APIs do) would be given a false detection (caused by the “resource” value set by us). Such false alarms may happen and cause problems. Am I missing something here?

By: Nate Lawson

Nate Lawson — Thu, 22 May 2008 19:12:14 +0000

In case it wasn’t clear in my previous comment, this all requires figuring out how to store the random offset in PEB!BeingDebugged before the kernel stores a “1″ there. If there isn’t a window to do this via early instruction execution or static table initialization, then this countermeasure is only effective for detecting attach after process startup.

Since I never use PEB!BeingDebugged in my own protection designs, you’ll have to forgive my improvements for being extremely limited. I still hope the principle comes across clearly.

By: Nate Lawson

Nate Lawson — Thu, 22 May 2008 15:44:33 +0000

Russell, thanks for commenting.

1. Yes, I am using this as an example of how an anti-debugging implementation can be strengthened relative to the simple approach. Depending on PEB!BeingDebugged in any way is extremely weak, even when strengthened via this approach, but the fact that it becomes slightly better than the simple checking approach means it’s still an appropriate example.

2. Allowing any one part of the protection to stand on its own makes it easy to remove, so even if this approach was used as part of some scheme, it would have to be covered with multiple layers of protection (timing and integrity checks, for example).

That being said, simply clearing the flag will not bypass this particular implementation. See the article again. It’s using something like stack cookies, where PEB!BeingDebugged would be set to a random value between 2 and 255 and used as an offset into a jump table filled with some invalid targets, as well as one valid one. So even though you could attach early, the OS would overwrite PEB!BeingDebugged with 1 as soon as you attached. Then when you tried to read the actual value, you wouldn’t find it.

So my point that you’d have to use another way to read the original value of PEB!BeingDebugged is still valid. Since it’s only a byte, it could be brute-forced if you knew this was being done, but it is still stronger than a simple comparison. That’s the main point of this article.

There’s still an open question about how to initialize PEB!BeingDebugged before a debugger could attach. Rather than spending a lot of time on this one, consider other ways to accomplish the same thing. Of course it’s better to start with a stronger anti-debug check, then strengthen it further by using up a resource instead of a simple comparison. Still, this is a fun thought experiment.