For other programs concurrently using the same technique, there is no easy solution. Since the whole goal is to avoid shared use of the resource, this is how it’s supposed to work.

First, you can often assume mostly dedicated access (i.e., playing a game). Asking the user not to play two games at once is usually reasonable. Second, if you control both apps that do the sharing, there are cryptographic ways of ensuring that the attacker isn’t the other party. Third, the most common response mechanism for this approach when it’s possible someone might have a legitimate purpose for using the resource is to fail obviously and softly. An error message to the user describing the problem and how to correct it is a good idea. As always, the response should be far instruction-wise from the check that detects the problem.

It sounds very attractive to store some code (or a crypto-key?) in a shared resource like that, but the more I think about it the more I see the problems prop up. What if two different programs use the same shared resource for their software protection?

Thanks for writing a great blog!

In this case, most of my work is kernel-side. Even when reversing a usermode program, I like to use a kernel debugger. So when I talk about anti-debugging, I sometimes assume the vantage point is kernel mode. Most of the time the general technique is applicable to both.

I’ve enjoyed reading your blog for a while and I think it’s very interesting, although (intentionally?) vague on the details. Maybe that’s a good thing, at least it makes my brain hurt trying to figure out how to actually implement any of your suggestions. Maybe I just look at it from the wrong angle, I read your blog from an independent shareware author’s view.

For example, storing some of your code in the RAM page used for the 1394 debugger stub under Windows means attaching a debugger would overwrite that code. This is more powerful than checking the KdDebuggerNotPresent variable. There are many other examples.