PunkBuster is monitoring the target, and it is constructed in such a way that the only viable/practical method to acquire "breakpoint-like functionality" in games monitored by it is to use hardware breakpoints (well, or at least that's what the collected participants of this thread seems to be able to conclude anyway, including myself).
SafeDisc is protecting the target, and it is constructed in such a way that it uses assorted trickery (including ring 0 such) in order to prevent you from making use of any of the debug registers, and thus also implicitly preventing you from using any hardware breakpoints on the target.
The method that has been suggested to neutralize this show-stopper feature of SafeDisc is to subvert it by means of miscellaneous kernel-level hooks (remember that we cannot remove or patch the SafeDisc protection directly, since this would make PunkBuster unhappy and bring us back to square one, where it has already been concluded that attempting to neutralize PunkBuster itself is not a viable option ).
The working hypothesis is then that the implementation of such effective hooks can only be acquired by means of IDT patching or similar.
The next assumption is that "IDT patching or similar" will always be prevented on Windows Vista by the PatchGuard feature of the operating system, which will thus, implicitly, prevent this angle of attack in its entirety.
The next logical step to be concluded was to neutralize PatchGuard, in order to unwind this annoying chain of interdependent show-stopping details, and thus be able to reach our initial goal by means of making SafeDisc allow us to use hardware breakpoints without actually patching it directly.

#include <iostream>



class Test {

public:

    typedef void (Test::*MemberPfn)(void);



    void Target(void) {

        std::cout << "Test::Target()" << std::endl;

    }

};



class MyTest {

    typedef void (MyTest::*MemberPfn)(void);

    static MemberPfn m_targetPtr;



public:

    static void* GetHook() {

        static MemberPfn pfn = &MyTest::Hook;

        return *(void**)&pfn;

    }

    static void SetTarget(void* ptr) {

        *(void**)&MyTest::m_targetPtr = ptr;

    }



    void Hook(void) {

        std::cout << "MyTest::Hook()" << std::endl;



        if (this->m_targetPtr) {

            (this->*m_targetPtr)();

        }

    }

};

MyTest::MemberPfn MyTest::m_targetPtr = 0;



int main(int argc, char* argv[])

{

    Test::MemberPfn targetPtr = &Test::Target;

    MyTest::SetTarget(*(void**)&targetPtr);



    *(void**)&targetPtr = MyTest::GetHook();



    Test* test = new Test();

    (test->*targetPtr)();

    delete test;



    return 0;

}

1) SafeDisc is messing with the debug registers.
Have you considered determining the nature of this usage?
Where are they used? How are they used? Could the usage be circumvented/simulated?
The DRx accessing/mutating code is located in SafeDisc's driver.
Usermode applications and drivers have a limited number of ways of communicating with each other, the most common of which is the request/response model of DeviceIoControl. Here's a conceptual summary of the process:

The application opens a symbolic link (CreateFile) to a device of the driver in question. Prepares a request in the form of a device specific io control code and optionally data required to cary out the request. The request is sent to the driver using DeviceIoControl.

The driver receives the request through a callback function (IRP_MJ_DEVICE_CONTROL) specified in it's DRIVER_OBJECT. The callback is passed an io request packet (IRP) which contains the request information. The callback will then carry out the request and as a response return a) a status code indicating if the request was successful or not and optionally b) data generated as part of the request.

The os will then perform a number of tasks depending on the situation. If the callback returned an error status code, it will convert it to a usermode error code and set that in the last error variable. If data was provided as part of the response, it will be copied to the output buffer specified in the DeviceIoControl call. And finally it will return from the DeviceIoControl call.

Given this model, what options do you have for isolating "malicious" requests to the driver?

2) You've got punkbuster watching over your shoulders.
Any solution that you can come up with for trapping execution within executable images monitored by pb, will be of interest to pb, whether it currently detects it or not.

From Ring 3 it seems you have little options but to somehow circumvent pb. This obviously requires a familiarisation with the inner workings of pb.
I'd suggest heading over to http://forum.gamedeception.net for more information about pb.

For Ring 0 you've got a few more options, however knowledge of driver development is required.
Assuming that pb does check the debug registers, you'd have to hide them. This could be done by hooking the kernel level apis responsible of carrying out Get/SetThreadContext's doing. Or if pb is accessing them directly, by using the global detect flag to trap such access.
"Raising The Bar For Windows Rootkit Detection" (http://www.phrack.org/issues.html?issue=63&id=8#article) outlines a method for hiding executable code which is designed to solve your specific type of problem. However, I'm not sure if this approach can be applied/adapted to Vista or x86-64 (I'm clueless about both).
These are the only immutable methods of trapping execution that I know of, that is, debug registers and page table modification.

There is some such DLL/API function called close enough to the point of interest.
The originally desired breakpoint doesn't need to be exact, contrary to e.g. if you want to read some temporary memory data buffer etc exactly at this breakpoint.
PunkBuster does not checksum DLLs too, which I sadly assume is quite likely that it will?