Anti cheat program.

Encrypt the executable.. Encrypt the resources.. Run CRC checks against everything... add the ability for the ''master server'' to do third party process lookups (So you can find if cheat X is running etc).. Strict variable definitions.. Checking values (Can Var X jump from 1 to 99999 in one cycle?).. etc

There is no single answer, the big problem is that the client is under the complete control of whoever owns the computer it is running on. Simply need to be smart and try and avoid letting ''bots'' do the work of humans.. but bot input looks a lot like human input from the programs point of view.

Also, keep in mind that occasionally these ''cheaters'' are actually just very good at the game, and arent actually cheating at all. Obviously though, if an ''impossible'' action is taken, the server should know this, and its a fairly obvious sign of a hack (although it could occasionally occur from errors, so checking for it and acting on the second occurence might be of use).

The most simple answer is almost always the best. In this case the idea is to simply keep as much on the server as you can. For instance, when player X wants to move, don''t let the client say "I want to move to (30, 16, -5)", or even "I want to move by (1, -4, 0)." Instead store positions and all on the server and let the client tell you "I want to move in the DIRECTION (sqrt(2)/2, 0, sqrt(2)/2)."

Also, it''s worth adding that if you have hacks that are not so much aimbots, wallhacks and that sort of thing, but are instead things like infinite ammo, extra health, lives or whatever, the best defense I''ve heard of (other than above possibly) is to store redundant values. Keep your variable m_CurrentPlayerHealth in three different places and check them periodically to make sure they''re the same (no hacks have tampered with them).

quote:

---

Original post by Kazgoroth
Also, keep in mind that occasionally these ''cheaters'' are actually just very good at the game, and arent actually cheating at all.

---

Yes! I am very good at quake 3 (i even beat a person that had positively been identified as an aimbot) and people call me a cheater all the time. I think there are fewer people actually cheating than you think.

This doesn''t really help contribute to the thread (I''m sorry), but it''s true that a lot of people are simply amazing. I''ve downloaded counterstrike videos of people playing at LANs/tournaments and they are simply amazing. I saw a guy shoot three or four people in one round through a wall simply by hearing them.

According to the PB website:

"PB Admins can request actual screenshot samples from specific players and/or can configure the PB Server to randomly grab screenshot samples from players during gameplay"

I would have thought this would be a pretty sure way of detecting any wallhacks or any other graphical modification. I suppose it does depend on an Admin looking at the screen shots manually?

Could a game do some simple automatic tests that could notify an Admin that a player warrents some attention? For example to test if fogging has been disabled, simple render a blue triangle far away with white fogging on, and read back the framebuffer. If you''re getting pure blue pixels you''ve got no fogging. Such a test would also detect bad drivers which don''t do fogging correctly. Basically some conformance tests.

I haven''t looked at any hacks myself, or know exactly what they can do, so maybe it would be possible to avoid such tests too. Also, PB/VAC/games might be doing such automatic tests right now?

Ro_Akira

You can hardly stop people from cheating unless you do pretty much 100% of the work on the server. And even then, that wouldn''t stop bots programmed to play the game as though they''d be (in)human experts.

I think some kind of decoy feature would be a good (though far from perfect) way of identifying bots. Something the player can see but that would fool a bot. For instance, you could have dummy players that can''t actually play but that still run around and pretend to be other players; in other words they''d be virtually identical to real players (save for some way to identify them, such as different textures). However, players are not supposed to shoot them (say, they''d be civilians). If the game were coded so that the client would receive, under the hood, the exact same info with a dummy than with a player, bots might end up being fooled by them and could be identified more easily.

It''s an idea I''ve had just now and definitely needs elaborating, though. I can see a lot of flaws, like having signs a program wouldn''t be able to recognize and that players would be able to easily spot (so as not to accidently shoot one in the midst of a heated shootout), or accidentally (or purposefully) shooting one. Though I guess the basic idea could have some merit, were it worked on a bit more than I have.

Hi Rakki,

I have some experience developing anti-cheat patches. While you will never be able to stop all of the cheaters, there are a few things you can think about if you are up to doing some grunge work.

I will assume that you don''t have access to source code for the game.

Probably the first thing you want to do is create a wrapper for wsock32.dll. From within this wrapper, you want to do some type of encoding of the packets, so that others wont be able to join a protected game with an unprotected client.

Something very important that PunkBuster doesnt seem to do very well at (or atleast didnt previously), is to have a background thread that is continuously doing a slow checksum on all game code *in memory*. The majority of the private cheats you are speaking of are going to be modifying the actual game code in memory, and never touch the executable, or the game data. You definitely want to scan the data as well, but you need to scan both in order for it to be effective.

You want to keep a list of the most exploitable code chunks, and scan them more regularly, and do a real slow scan on the rest of the code... to avoid killing game performance.

Unfortunately many game hackers know a bit about wsock32.dll, and it is not that hard for them to dig into a wrapper for it and figure out what''s going on. For that reason, I would also recommend creating a wrapper for winmm.dll. You can then hook the timeGetTime function, check the output against a certain threshold, and scan small parts of your own code from within timeGetTime. Say, once every 15 seconds or so you scan your wsock32 wrapper.

Scan the GetTickCount and QueryPerformanceCounter functions to make sure they are not being changed. Generally speaking, scanning the first few bytes of each is sufficient. These functions are modified by many speed cheats.

Another thing to keep in mind is, dont give the game hackers anything to work with. If it detects a cheat, don''t notify them that a cheat was detected, just drop them. Dont write anything to a file, dont display any dialog boxes, and dont simply close the game. Do something subtle... like modify the key that you use to encode the network packets, so that it begins transmitting garbage that the server wont recognize, and the connection will be dropped in a way that is hard to trace. If you give the game hacker anything to work with, it is a simple matter for them to hook whatever you give them with SoftICE and trace back into the code, and figure out a way to disable what you''re doing.

If you come across cheats, dont just make a checksum of the cheat and add it to some database... analyze the cheat, find out what it does, how it does it, and find a way to thwart it in a general fashion... many times you can use the game hackers own tricks, and modify the game code to completely remove certain options, or to crash the game if a value is not within an acceptable range.

Aimbots for these types of games generally work 1 of 2 ways... they either use something like the Windows API function GetPixel to detect the colors of enemy uniforms and simulate a mouse move in that direction. The other method commonly used is to actually hook Direct3D...

The Direct3D cheats are not that hard to detect, you can scan the Direct3D code in memory like you do the game code. The GetPixel method is a little harder to deal with... the only decent general way I found to deal with it is kind of risky... on NT/XP it involves iterating through all running processes and modifying the GetPixel function in memory to always return a particular color. This can cause some problems with other applications if you are not careful... especially if they are using GameSpy Arcade. In Win9x you cannot access the GetPixel function as easily, though it is only in one location: shared DLL memory. You would need to force ring-0 mode to be able to write to that memory.

Similarly, if you want to get risky (make sure you cover your legal butt), you can use that same trick to disable the WriteProcessMemory API function on running processes. If you can get this one to work good, you will have effectively eliminated about 95% of available cheats in one step. Most cheats (with the exception of a few speed cheats and aimbots) rely on WPM to modify the process memory, without it they are worthless.

In Win98 you will need to scan for new processes every once in a while, on XP there is a way you can trigger a callback function any time a new process is loaded.

One thing I can say is that to make an effective anti-cheat patch will require a good working knowledge of raw assembly (macro assembly wont be of much use). Without the game source code, that is the only way you are going to be able to see what is going on, and analyze what needs to be done.

I''d also recommend writing a custom EXE and DLL encryption package. Using one of the canned file packers would be pointless, because there are programs out there to detect and reverse all of them.



Learn about anti-debugging, anti-trace and anti-dump. Dont just detect cheats, break the tools the hackers use to make cheats.



This is mostly covering the client side of things. There are lots of things you can do on the server side as well, and a good coordination of efforts between server and client will go a long way.

I''ve been battling cheaters for a while, and I''m full of all kinds of interesting information on this topic, but its almost 4am, so im shutting up now

Peace

wow that was an excellent post krippy2k, and exactly the type of feedback i was hoping to get here. if you dont mind me asking ? what game do you provide anti cheat software for?

Krippy2k : "I''m full of all kinds of interesting information on this topic"

Any chance of divulging any more of this info in the form of an article here on GDev? Or failing that pointing us to an existing article.

"...have a background thread that is continuously doing a slow checksum on all game code *in memory*."

That seems like a good idea. Is there a chance that the code that''s checking the code, as it were, will be tampered with? Employing anti-debugging, anti-trace and anti-dump as you said would help in this regard?

I''ve seen source code for hacks (for research purposes) which do what you say, using WriteProcessMemory. It would be handy if one could somehow disallow other processes to modify ones process memory. More secure I would have thought. Is WriteProcessMemory used only for debugging purposes? I can''t imagine many legit uses.

"...you can use that same trick to disable the WriteProcessMemory API function on running processes"
Does this mean attempting to modify kernel32.dll? Do PB or VAC use this ''disable WPM'' trick?

I''ve seen another hack hook into OpenGL via a bogus opengl32.dll. Presumably one drops this into the same directory as the program and it overrides the one in the system directory. It doesn''t appear to use WPM at all, but hooks into functions, like SwapBuffers which one can know will execute at the end of a frame. Could this type of setup be caught using the ''scan memory'' method?

Does the GetPixel method involve getting the DC of the prgram window and then reading the entire contents using GetPixel? I had this idea GDI functions wouldn''t be allowed with D3D. I suppose the idea of the ''disable GetPixel'' method works great as long as no other application tries to use it.

I haven''t even compiled, never mind tested or used in the field any of these hacks BTW.

Ro_Akira

quote:

---

Original post by Ro_Akira

Krippy2k : "I''m full of all kinds of interesting information on this topic"

Any chance of divulging any more of this info in the form of an article here on GDev? Or failing that pointing us to an existing article.

---

That is an interesting thought, perhaps I will write something up when I have some time.

quote:

---

"...have a background thread that is continuously doing a slow checksum on all game code *in memory*."

That seems like a good idea. Is there a chance that the code that''s checking the code, as it were, will be tampered with? Employing anti-debugging, anti-trace and anti-dump as you said would help in this regard?

---

Yes, there is that chance. The most common way I have seen of that being done is for the hacker to kill the scanning thread. You need to devise a way to ensure that the thread remains running. One possible way is to increase a global counter every time the thread makes an iteration, and in the wsock32 send or recv function, you can check that counter every few seconds, and if it has not increased, the thread has been killed or locked. There are methods of actually stalling a thread so that it doesnt *appear* to be dead if you query it, but it will not make its iterations, so just doing a standard API thread alive check wont suffice.

Another way is to have multiple concurrent threads in different modules. In my case, I had a wsock32.dll wrapper, and a winmm.dll wrapper, and had a low priority thread running in each... the main scanning was done in winmm.dll, the encoding was done in wsock32.dll, and they communicated with each other via a static memory block that was allocated at a specific location in process memory. It would be very tricky for a hacker to devise a way to freeze both threads in different modules at exactly the same time.

The ''crypt key'' was stored in that shared memory block, so that the scanning thread could change it, and have the effects realized in wsock32.dll.

quote:

---

I''ve seen source code for hacks (for research purposes) which do what you say, using WriteProcessMemory. It would be handy if one could somehow disallow other processes to modify ones process memory. More secure I would have thought. Is WriteProcessMemory used only for debugging purposes? I can''t imagine many legit uses.

---

It is most often used for communication between 2 dependent processes... if one process wants to notify another process of an event, one of the fastest ways to do it is to directly manipulate a flag in the other process'' memory space.

For some reason my DSL modem driver seems to use it on XP... though I never figured out exactly what for... it doesnt use it on Win98.

And Windows does not provide any mechanism for disabling it... the only way you can do it is the hack way I mentioned... or atleast that is the only way that *I* found to do it. It is still not perfect, however.

Generally I have found that is safe to do that on any user-level processes in XP. Obviously you cant use it on system level processes (like drivers) unless you manage to break into ring-0 mode, which is not a trivial thing to do on XP (though it is possible).

You also have to be careful not to disable it in the game process on XP... on Windows 98 you have other options for writing to another process'' memory.

quote:

---

"...you can use that same trick to disable the WriteProcessMemory API function on running processes"
Does this mean attempting to modify kernel32.dll? Do PB or VAC use this ''disable WPM'' trick?

---

Yes, you can modify the kernel32.dll functions in memory. In NT/XP each process gets its own copy of the kernel32.dll methods, and you can use WPM from your own process to modify it. Just use GetProcAddress to find the correct address, and do something like have the first instruction return success, so that when the cheat tries to use it, it *thinks* that it works, because no error was returned from WPM.

As far as I can tell, PB does not use this technique. Although it has been a while since I have checked out their software. I have actually recommended it to them in the past, dont know if they ever bit or not.

quote:

---

I''ve seen another hack hook into OpenGL via a bogus opengl32.dll. Presumably one drops this into the same directory as the program and it overrides the one in the system directory. It doesn''t appear to use WPM at all, but hooks into functions, like SwapBuffers which one can know will execute at the end of a frame. Could this type of setup be caught using the ''scan memory'' method?

---

Yes, that is another point. Aside from WPM, a hacker could use something called ''DLL injection'', which causes a DLL of their own to be loaded when the game launches. From within a module attached to the game process, there is no need to use WPM, they can just use standard memory functions like memcpy.

Unforunately this is a tricky one to prevent, because on every system there are a variable number of DLLs that get loaded with every process, so there is no base set of modules to check against. At this point, you just have to rely on your other schemes. There is one possibility, where you could walk through each module, and analyze them for memory writes within the game process, and disallow those memory writes. That would take a lot of work to figure out, and would probably take a long time to actually do at runtime. Probably not a realistic option.

quote:

---

Does the GetPixel method involve getting the DC of the prgram window and then reading the entire contents using GetPixel? I had this idea GDI functions wouldn''t be allowed with D3D. I suppose the idea of the ''disable GetPixel'' method works great as long as no other application tries to use it.

---

It seems to work on some D3D applications, and not on others. I am not real sure about AAO. And yeah, it will in many cases cause problems with other processes. One common side effect I found is that in Windows Explorer some small areas of windows would have a pink or yellow block that shouldnt be there... and GameSpy Arcade doesnt like it... often a player will find that upon game exit, their chat screen in GSA is entirely red, and not be able to read any text... closing GSA and reopening it is the only option.


I think there are 2 major keys to successful anti-cheat:

1) Redundancy; Check your checks that check your checks.

2) Frequent updating of core scanning code.

I''ve generally found that at best, when a new updated set of code is released, you will have about a week, or 2 weeks max, before it is cracked.

Also a good banning system would go a long way. One thing about PB that I like is that they actually use the CD key as the identifier to ban people, rather than IP number or name. Or atleast, that is how they do it in RavenShield.

Oh yeah, another thing to look into is ''anti-loader''. If an application can be used to spawn the game process, that application can modify the game memory before any of the game code is launched. That is bad... luckily there are some fairly simple techniques to stop that.

Unfortunately, information on this type of thing is very rare to come by. When I get some more time I will coallate some links and some more information and post it here.


Peace

quote:

---

Yes, you can modify the kernel32.dll functions in memory. In NT/XP each process gets its own copy of the kernel32.dll methods...

---

Ah, that''s not as bad as I thought so. I wonder if any commercial games would be willing to go about altering other processes like that though?

quote:

---

Just use GetProcAddress to find the correct address, and do something like have the first instruction return success, so that when the cheat tries to use it, it *thinks* that it works, because no error was returned from WPM."

---

Could one employ an anti-anti-cheat ( ) method here such as using ReadProcessMemory to see if it actually worked? That might be a more difficult thing to combat. Although you might hijack the ReadProcessMemory function also. Instead of your custom WPM jusr returning a success, you might store what was passed in. When ReadProcessMemory is requested for some or all of what was supposed to have been written, it gives back the code stored by WriteProcessMemory.

I was thinking it might be a good idea if Windows had an official way of either marking an executable as non-modifiable by WPM, or calling a function to make the current process non-modifiable. Since one can know beforehand whether the program needs to be legitimately modified by WPM, this would be ok? The only thing is, a marker in an exe could easily be changed, and CD checks seem to be readily avoidable, so I''d imagine calls to ''SetProcessWritable ()'' could be found and eliminated also.

quote:

---

Oh yeah, another thing to look into is ''anti-loader''. If an application can be used to spawn the game process, that application can modify the game memory before any of the game code is launched. That is bad... luckily there are some fairly simple techniques to stop that.

---

I would have thought this would be harder to stop if anything. Some of the code I was looking at does something like that, using CreateProcess to spawn ones game, and injecting some code in the form of structs at the entry point.

quote:

---

Also a good banning system would go a long way. One thing about PB that I like is that they actually use the CD key as the identifier to ban people, rather than IP number or name. Or atleast, that is how they do it in RavenShield.

---

Agreed. The same system is used with Soldier of Fortune 2. I''d be surprised if not all new games used a similar system.

The only potential weak point of this system that I see is if keygens are developed succesfully. I''d imagine if such a thing were developed, it would really cripple the banning system because the only way to solve it would be to use a new system, and ask everyone to buy the new version of the same game. I haven''t looked into how this is panning out with current games - must have a look at that. Can one just try random keys too? I suppose one is relying on the key length to make that impractical.

quote:

---

There are methods of actually stalling a thread so that it doesnt *appear* to be dead if you query it...

---

By giving it some nice deadlock situation?

quote:

---

''DLL injection''...a tricky one to prevent...there are a variable number of DLLs that get loaded with every process, so there is no base set of modules to check against

---

The dependency walker tool is able to find out what dlls are used by an executable. Would it be possible to use some similar method of finding what dlls one needs to check, and then doing checksum checks on these? I guess they could change legitimately too.

quote:

---

I''ve generally found that at best, when a new updated set of code is released, you will have about a week, or 2 weeks max, before it is cracked.

---

:O No summer holidays for the anti-cheat developer on the project so That''s a seriously quick turn around. If only project managers could harness that productivity... Seriously though, slight modifications to the code and the ability to automatically update it every week might be a tough challenge.

Would you lend any credability to ''my'' method of graphics driver conformance(and thus graphics cheating) testing as part of the suite of tools?

P.S. If answer any of those questions, you''ll be able to copy and paste an article together from all that you''ve posted on this thread!

Ro_Akira

quote:

---

Original post by Ro_Akira
Ah, that''s not as bad as I thought so. I wonder if any commercial games would be willing to go about altering other processes like that though?

---

Probably not. And rightly so, I think. When you purchase a game I think it should be yours to do what you want with, and not go messing around with your system to stop you. Any such thing should be contained in a seperate package that users have to install seperately from the game that is made for that specific purpose. There can certanily be code in the game that is there to support the alternate software, and give it easy access to what it needs.

There are a lot of other steps that commercial game companies can use that make it harder to cheat though. Age of Mythology for instance uses some encoding of the game variables so that a potential hacker cannot just search by specific value or by increment/decrement of memory values. People still made cheats for it, but they took a lot longer to make them, and they were somewhat clunky.

From a game development perspective, that is one of the most important things you can do. The harder you make it for them to find the data they need to deal with, the less cheats there will be for it.

quote:

---

Although you might hijack the ReadProcessMemory function also. Instead of your custom WPM jusr returning a success, you might store what was passed in. When ReadProcessMemory is requested for some or all of what was supposed to have been written, it gives back the code stored by WriteProcessMemory.

---

That is actually a good idea... though I might even take it further. Have ReadProcessMemory return a bunch of garbage... since many debuggers and hacker tools (but not all) use RPM to view the memory and code, it would render them useless for analysis. You wouldnt be able to disable it in a kernel debugger, however.. or anything written as a device driver... without completely mangling the NT security, which is probably not a good idea to be doing. Then also keep an array of WPM calls, and if the RPM call is within those memory ranges, return what was attempted to be set... that might throw them off for a while.

quote:

---

I was thinking it might be a good idea if Windows had an official way of either marking an executable as non-modifiable by WPM, or calling a function to make the current process non-modifiable. Since one can know beforehand whether the program needs to be legitimately modified by WPM, this would be ok? The only thing is, a marker in an exe could easily be changed, and CD checks seem to be readily avoidable, so I''d imagine calls to ''SetProcessWritable ()'' could be found and eliminated also.

---

It would be nice. They are starting to implement better mechanisms in hardware for process security on the newest lines of CPUs but it will be quite some time before we can start coding to that as a standard.

quote:

---

quote:

---

Oh yeah, another thing to look into is ''anti-loader''. If an application can be used to spawn the game process, that application can modify the game memory before any of the game code is launched. That is bad... luckily there are some fairly simple techniques to stop that.

---

I would have thought this would be harder to stop if anything. Some of the code I was looking at does something like that, using CreateProcess to spawn ones game, and injecting some code in the form of structs at the entry point.

---

There are some tricks you can do in assembly that will prevent most loaders... Im putting together some stuff, and I''ll include some of my anti-loader code. Of course, as with everything, there are ways to beat it if they figure out what is going on. Just another layer in your plan of frustrating them

quote:

---

quote:

---

There are methods of actually stalling a thread so that it doesnt *appear* to be dead if you query it...

---

By giving it some nice deadlock situation?

---

Yeah... One method involves hooking the Sleep function, which any background thread will need to make use of.

quote:

---

The dependency walker tool is able to find out what dlls are used by an executable. Would it be possible to use some similar method of finding what dlls one needs to check, and then doing checksum checks on these? I guess they could change legitimately too.

---

Yeah you can find what DLLs are used by an executable pretty quickly, the problem is that they actually cause their own DLL to be loaded at runtime automatically, through a Windows feature, instead of modifying other DLLs. Then they use calls from within that DLL to change the game memory. And there are many legitimate uses for this, and every system is going to have a different set of DLLs that is attached to every process, so it would be a mammoth feat to actually prevent them from loading their own DLLs. If they get to that point, your only defense is in your game-scanning code, your redundancy, and your obfuscation. Luckily most game hackers dont go this route, because it doesnt let them use cute little interface windows with their names on it.

quote:

---

Seriously though, slight modifications to the code and the ability to automatically update it every week might be a tough challenge.

---

It is a hard task, but it is not an overwhelming task... IF you have a reliable master server. You can actually have the clients download the updates seamlessly in-game when they are available, and have them take effect the next time the game is launched, without ever notifying the player that there was an update. If you also update new detection code, this will give you the opportunity to catch cheaters with known cheats before they realize that there has been an update... much better than requiring them to explicitly download the update, where they can then install it on an isolated system to analyze. There are also ways you can update it so that it takes effect immediately, rather than the next time you launch, but that works out to be pretty tricky to do without problems unless the game itself had that as part of the design.

quote:

---

Would you lend any credability to ''my'' method of graphics driver conformance(and thus graphics cheating) testing as part of the suite of tools?

---

To an extent. I think you could prevent the use of certain drivers that are known to be exploited, but laying out a list of drivers that they have to choose from might be pushing it and cause more headache than its worth... unless your game happens to be targetted to a narrow set of chip support.. though I would make *that* a game decision, as opposed to an anti-cheat decision, since it limits the exposure of your game.


Peace
(Lets see how bad this post is mangled when i submit it)

Hi,

quote:

---

Generally I thought alot of games these days were written with almost all of the logic in DLL's etc, which suggests that it could be done seemlessly if the DLLs are loaded dynamically - ie you'd just need to have your update code in the EXE file, which could check for updates before launching the game.

---

By seamlessly I meant getting them in-game while the user is playing. Obviously, auto-updating at launch time has been a solved problem for a long time. The trick in getting them seamlessly while playing is doing it in such a way that the user doesn't notice the update. You will need to transmit the files slowly so that it doesnt cause too much noticable lag... and if you want the effects to take place immediately, it will involve manually overwriting machine code in memory. This is especially important if you have a setup like Punk Buster where there is a Master Server, and then seperate dedicated game servers run by individuals. For it to be effective, the servers also need to be updated, while they are running. It can be a pain in the ass to get some of the game server hosts to reboot a game server for updating.

quote:

---

In respect of your GetPixel hacks, howmany successful GetPixel hacks have there been (can you quote any examples?); it seems a hugely unreliable method to just look for colours the same as an enemy's uniform, unless you've written something that does image recognition on the frame & picks out the enemy's shape (to check its a shootable target) + his identifying marks, in which case the hack writter is probably verging on genius and should be offered a high salary writing scientific imaging software!

---

I'm not going to start posting cheats here, but I have more than 50 of them in my possession for various games, most of them will work across several games. They are called 'color aimbots'.

The thing is, most games allow you to modify the skins... and in most cases, modifying the skins is not considered a cheat... because it can be cool. So they make the enemy skins a color that is guaranteed not to be the same color as anything else in the map... i.e. hot pink, or real bright yellow, etc.... there is no need to analyze shape, or identifying marks, they only need to find the color. If they modify the skins so that say, only the head is hot pink... they can pretty much guarantee a headshot, as long as there is not enough lag to affect the shot. Many of them also have a feature called 'autoshoot' that simulates a mouse click when it is locked on. So they dont even have to shoot, they just move their mouse around and the cheat does everything else.... yay fun...

And they don't scan every pixel on the screen. They do assume that the user is going to do SOME work. They generally scan a small area in the middle of the screen (say about 1/4 of the screen size), so that when you aim in the *general direction* it will lock on. They also generally have configurable granularity in the scanning. They don't need to scan every pixel within that region, they only need to scan every 4th or 5th or even 10th pixel... because targets that you want to shoot at are generally not that small. Doing a few thousand GetPixel calls 20 times per second or so is not going to have a noticable effect on performance on today's PCs.

quote:

---

I had always understood that the way these kinds of hacks worked is that online games have a certain ammount of lag, for which reason all objects that are near the player and are likely to become visible in the next few frames (say a dozen) are sent to the client computer, who is trusted to keep them hidden until an appropriate moment; the hack is then to actually reveal the data in some-way, presumable aimbots can use the data to find the target etc.

---

Now THAT is something I have never seen, though it is something I have thought about. You see, most game hackers dont know much about how games are actually made, especially when it comes to the network layer. More often they use the graphics information, because it is much simpler to deal with what is on the screen... and most of them would not have a clue how to aim based on a 3D coordinate.

Edit: I should mention here that this is in reference to game hacking in general, not for UT games... the very nature of their extensible design makes it easy for hackers to figure out what is going on. Luckily, there are still some games that use original engines, and not just making clones of each other.

quote:

---

I'm a little concerned about your plans to hack WriteProcessMemory/ReadProcessMemory, I mean that as a player I could understand your reasons for trying to increase your security, but I'm happy upto the point that you start hacking my kernel, which evidentally will affect my system's stability & security.

---

Indeed, that is a concern. And that is why I dont recommend doing anything like that in a shipped game, only in a specific anti-cheat product that is meant mostly for tournament type play. In sports, you have to take blood tests, piss tests, etc... to ensure that you are not cheating... even for a lot of non-professional sports. I think having WPM/RPM disabled in other applications while you are playing a game is far less intrusive than sticking a needle in your arm. It will only potentially affect the stability of your system while you are playing the game in tournament play. When the game exits, it should restore these functions to their original state. At worst, it will require a reboot if the game crashes ungracefully.

quote:

---

My other doubt about this is that I suspect that these functions probably fall straight through to the native api under NT systems, I don't know the names for sure, I'd need to check the docs, but I suspect the underlying functions are called NtWriteProcessMemory & NtReadProcessMemory likely to be found in ntdll.dll. Firstly anyone trying to hack these will probably bring the system down, secondly this implies that to get round your anti-cheat I would just need to call the native api, rather invalidating your anti-hacks.

---

Yes, for anything you can do, there is something they can do to get around it. The idea isnt to make it impossible for them to write to process memory, it is to make it harder for them. WriteProcessMemory is an officially documented Windows API function... NtWriteProcessMemory is not. Not only cheats use WPM, but also the most common tools that game hackers use to figure out how to create cheats in the first place. Disabling WPM would require them to first create new tools that use the underlying system functions... and no I wouldnt recommend tinkering around with the ntdll functions.

Like everything else, it is not a silver bullet, it is just another tool in your arsenal. It just happens to be one that will elminate a vast array of common cheats, and common hacker tools, in one fell swoop.

quote:

---

I was under the impression that, even in NT, the system dlls have only one instance that is mapped into each process, for example there are several code snippets that I have seen where the code when loaded searches for the kernel's header, reads its export table to find GetProcAddress & LoadLibrary so that it can then complete loading itself.

---

Wrong, there is one instance that is then copied into other processes. But, they are all guaranteed to reside at the same address in each process' memory space across a system... thats why you can use LoadLibrary and GetProcAddress to find the address. You can check it out, get yourself a memory editing tool, open up one process, make some changes to a kernel function... then open up another process and you will see that it is unchanged in that process. I am not 100% certain that this is true on all NT versions, but it is certainly true in Windows 2000, XP and 2003... not many people playing games on NT 4.0 these days.


Peace


[edited by - krippy2k on May 1, 2004 12:05:57 PM]

Hi,

First let me retract something I said... it is not *guaranteed* that they will reside at the same address in each process, but it is almost always the case. To find the actual address if it is not the same would involve reading the image headers for that process.

The reason they give each process a unique copy is to prevent processes from crashing the entire system by writing to a bogus pointer. If it''s all in one place, and the application accidentally overwrites some important API code, the entire system will be a goner... if each process has its own copy, it will only affect its own copy. Win98 avoided that by having a shared memory area that was unmodifyable by user-level processes, but that didnt work that well, and thus you get a bunch of blue screens of death rather than just a crashed application. Intercepting and storing memory changes on that level could be very problematic as well. Memory is cheap and the API code is not that big, so it is best just to let each process own its own set of system code to do whatever it wants with.


Peace

Shouldn''t a player-model get culled before rendering if it''s behind a wall? I assume most of the wall-hacks are done in the graphic-wrappers so it shouldn''t be a big issue today.

About Unreal Tournament, I''ve been playing UT since it came out and I haven''t noticed that anyone is cheating. Most of the servers where the really good players play are updated frequently so it''s not a big issue. Maybe you just suck

quote:

---

Original post by __fold
Shouldn''t a player-model get culled before rendering if it''s behind a wall? I assume most of the wall-hacks are done in the graphic-wrappers so it shouldn''t be a big issue today.

About Unreal Tournament, I''ve been playing UT since it came out and I haven''t noticed that anyone is cheating. Most of the servers where the really good players play are updated frequently so it''s not a big issue. Maybe you just suck

---

Look up Helios. Literally thousands of players cheat on UT.

I''m really familier with online cheats and preventive measures. Straight to the point, the best thing a programmer can do to prevent their game being hacked is try to keep as much information from the client as possible. This is the truth and its really hard to accomplish with all the demand on tier 1 games. Programmers need to algorithms that rely on error room, preprocessing, and are limited by the latency of current internet connections. So it''s uphill battle, but the solution is closer than we think.

Connect to Server > Download Anti-Cheat Code
Dynamically allocate memory > Load Anti-Cheat into memory
Check Anti-Cheat Signature (Using Public Key / hash)
If (Hash != Public(Signature)) { bad }
Execute Anti-Cheat
New thread, priority low - Check hash
[Thread Reports in every X to make sure it's still running]

Without having the private key (which is never sent) the client can't generate fake hashes for modified anti-cheat. I also like the idea of encrypting all server traffic with a single private key and then mass distributing the public key. Or better, have their serial No. as the public key, so when someone with serial number X connects it encrypts with the stored private and the client decrypts with the public key.

What I like about Public/Private key encryption is the ability to guarantee the source of traffic.



[edited by - Manip on May 3, 2004 7:21:51 AM]