Quote:Original post by SSkillZ
I don't like the Idea of a anticheat tool using "hacking" methods.

The method is unimportant --- it's how you use it. I'm just trying to help you get the job done.

Quote:Original post by SSkillZ
Thanks, but anyway the anticheat VAC which is built in the game checks if the files have been modified because so many cheats as you said used that method for hacking...

Thats why I don't like hacking the game files or the game itself.

Well a hook is about as hacky as it gets. In particular, a DLL hook will show up as an instant red-flag to VAC. If you want a non-intrusive method that can't be picked up by any anti-hack system then you'll need to do everything externally.

As far as I know, no such system will check the integrity of the API DLLs, as there are way too many versions to keep track of, and updates are frequent. For this reason, creating a wrapper DLL may be your best option. The biggest concern I have with this is that you'd need the target program to load up after your program has installed the fake DLLs.

Admiral

Windows services won't offer any more useful control than a regular user-mode application. The only reason we like to use DLLs is that it allows us to execute code inside the target process's address-space.

You should have mentioned Aero's role in the problem sooner - it changes everything [rolleyes]. All the code I've written in this thread has been 32-bit, so don't expect any of it to port nicely to Vista.
After a little Googling, I found your thread on CodeGuru, and the Windows Vista And OpenGL link that was posted. I haven't had the privilege of working with Vista yet, so I'm not qualified to give any advice. From what I can tell, though, the display model is radically different (with Aero enabled) and acquiring a handle to an applications front-buffer will be painstaking and driver-dependent for the foreseeable future. This is bad news for you.

Like I say, I no very little about Vista's display architecture, but the evidence suggests that getting the OS to capture the video overlay is a no-go. If this is the case, then you have no choice but to go in and get it for yourself. This means, barring the most contrived and audacious approaches, intercepting a render-call as we've discussed. So you're all out of leeway: it's hacker-methods or nothing.

Considering that your goals are so transient and non-intrusive (unlike those of a game trainer or suchlike), you can quite feasibly get around anti-cheat systems. But you'll need to be very efficient and slightly ingenious. This means injecting a DLL for any length of time won't be effective. However, if your probe can get in, get access, get the screen-capture and get out; all before the render-loop finishes, then the anti-cheat will have no idea anything happened. I have mentally prototyped a way to do this using the Windows Debug API, but I must warn you that it's no prettier than the previous method I described, and while not impossible, VB6 will have a relatively tough time delivering the goods. Interested?

May I ask why you're using a ten-year-old language? VB.NET is fairly easy to learn, if you know VB6, and it has a much wider support-base. Moreover, it is 64-bit compliant, is freely available as the Express Edition and will severely ease any attempted transition to C# (which is where everyone is headed).

Admiral