5

Will this anti cheat technique work for a multiplayer game using private servers (publicly unknown executable):

When the client starts the game it will auto update itself daily (using a launcher). The Servers will update themselves, too. Unless there is a real patch, the update only consists of changes in the gameobjects memory layout, netcode, and shaders. This is done using an automated system that auto generates and randomizes (C++) classes. Maybe it could also add fake objects to the hierarchy to make identifiyng objects harder.

This way I hope to update the game faster than a cracker can and will reverse engineer, update and publish/update a new cheat.

Will this work or can hackers somehow work around this mechanism? Will they do this work daily or can they automate it at some point? What can I do to improve this system?

It seems randomizing memory layout does not help in the long term because the layout can more or less easily be extracted by following function calls in the executable and extracting pointer offsets from that code. So to efficiently prevent this, the structure of calls and the code itself needs to be randomized also.

Are there good ways to do that? Is that working at all against automated cracking?

AstroCB
  • 12,337
  • 20
  • 57
  • 73
ecreif
  • 1,182
  • 1
  • 12
  • 25
  • 1
    think of how bad this feels for a player, if for *no reason at all* (no patches) you force an update and delay the player from experiencing your game – BeyelerStudios Feb 06 '15 at 13:47
  • @BeyelerStudios If the delay was a few seconds you'd never notice it; I've played games with no such protection (as far as I know) and there are already loads of delays loading assets, compiling shaders for your precise set of drivers, OS etc. –  Feb 06 '15 at 13:49
  • In my particular game, delay will be no problem by its nature. I also think that the update will be relatively small, its not about gigabytes – ecreif Feb 06 '15 at 13:50
  • 2
    Any change is a potential source of problems (both performance issues and bugs). You'll need a full QA cycle on each patch. Do you have the resources to verify the entire game on a daily basis? – molbdnilo Feb 06 '15 at 13:55
  • I'm stating what I try to find in games: a fast and simple way to *play*. every bit of delay is important and you're talking about replacing a large part of your code (at least the dll of your main engine), megabytes count too and not everybody has high speed internet. – BeyelerStudios Feb 06 '15 at 13:55
  • I don't have the required QA. But by the nature of the class generation i am pretty sure it cannot fail. The technique is about scrambling and randomizing memory layout. The compiler will do the work for me and it should do this correctly – ecreif Feb 06 '15 at 13:56
  • The compiler will remove dead code anyway. – Bartek Banachewicz Feb 06 '15 at 14:08
  • Fake objects do not necessarily have to be dead code – ecreif Feb 06 '15 at 14:13
  • 2
    @ecreif: If the update is small, then a cracker will figure out the changes in no time. If it's large, then someone with a slow connection (like mine), or one with a monthly download limit (like mine) would quickly give up trying to play. – Mike Seymour Feb 06 '15 at 14:22
  • He can see the changes but how does he know what these changes mean? Its pure machine code. Its like he gets a completely new executable file. Thats the point of my technique. I hope he needs to start reverse engeneering the game all over again – ecreif Feb 06 '15 at 14:24
  • 3
    @ecreif: You may hope that, but it's not the case. Executable files are structured, and "pure machine code" is easily converted to a readable form. A few minutes with a disassembler and a diff tool will show you exactly what's changed. If the changes are small, it won't take much longer to figure out how to modify the cheats to accommodate them. If they're large, then so was the download. – Mike Seymour Feb 06 '15 at 14:41
  • You might be right. As I figured out in the chat with piwi What makes reverse engineering the cheat easy is that code and calling structure does not really change. So I can automatically extract the memory locations by tracing down function calls and the pointer offsets the function uses inside – ecreif Feb 06 '15 at 14:53

2 Answers2

8

Client-side technological arms race is a completely wrong way to do this. You will never be better or faster than a bunch of kids that have too much time to spare. You cannot compete with a horde of attackers that have no costs (other than not doing their homework) while your actions cost you both time and money. This is a race you will lose, both on the way financially and in the end result as well.

There is two ways people can cheat:

  1. Gaining information others do not have (for example looking through walls)
  2. Automating gameplay that others have to do manually ("farming")

There are exactly two ways you can keep people from doing this:

  1. Stop giving that information to the client. Keep it on the server.
  2. Stop having parts of your game that are not fun. People only automate the parts that are boring, they don't play a game to be bored. Make it fun and nobody will waste his time trying to automate it. If automation of your game pops up, think hard how you can improve your game instead of battling bots technologically.

Remember the old saying: "The client is in the hands of the enemy."

nvoigt
  • 75,013
  • 26
  • 93
  • 142
  • everything: just full ack! – BeyelerStudios Feb 06 '15 at 13:44
  • @ecreif Exactly. I don't feel nvoigt doesn't understand the nature of cheating in (many) online games. You can remove all the dull parts and keep next to everything on the server, but there's still capacity/purpose in cheating. –  Feb 06 '15 at 13:48
  • I also think that this technique wont be a technological race. Its not that I want to detect cheats. I want to prevent hackers being able to update their cheat in time. So there will never be any working cheats at all – ecreif Feb 06 '15 at 13:53
  • 1
    @ecreif I do wonder how you believe you'll be able to automate your changes in a way which won't lend itself to an automated attack. –  Feb 06 '15 at 13:55
  • 2
    @ecreif I absolutely understand the nature of cheating in shooters. But the good cheats will attach to your graphics card driver and analyse the output polygons, so whatever you do in your code is useless. Personally, the best online shooters I played were strictly monitored by clans. If your server can be installed so groups can have their own policing, everything is fine. – nvoigt Feb 06 '15 at 13:58
  • I know that these cheats will attack the graphics API and Drivers. But I think by randomizing values, scalings and memory layout in shaders i make it hard for crackers to analyze what they have to attack with their cheat. The question was about how crackers could automate their cheat creation and how long it would take to reverse engineer, because I think this is crucial point of the technique – ecreif Feb 06 '15 at 14:01
  • Well, a polygon model is a polygon model, no matter what texture or shader it has or how it's saved in your memory. I don't know any details, but if you don't change the *shape* of your targets, changing anything else might not work. – nvoigt Feb 06 '15 at 14:03
  • As far as I understand a cracker needs to find out the transformation matrices and other important infos send to the API. Maybe he is fast in doing this and can automate this. He still has to modify and find out where my view matrix is stored and how to manipulate input to aim at a target. But how can he do this automatically if I add random similar looking data to new random places in the game daily? – ecreif Feb 06 '15 at 14:07
  • 3
    Because over time, "random" will become "obvious" if you're not doing it by hand. What if he hacks his game and doesn't get any further updates. Will the game still work, or are you checking it's been updated? What are you checking? What if he fakes that so you think it's been updated? What if you're playing a game then you push out an update - do half the players get kicked off and have to do an update, or is there an amnesty period where two sets of changes are allowed? –  Feb 06 '15 at 14:13
  • If he stops updating the game he cannot play on the servers anymore because old netcode will be used that is rejected by servers. There is a time where no server is active. – ecreif Feb 06 '15 at 14:17
4

I don't know whether such a system would be successful at avoiding cheating, but I would have concerns regarding producing and maintaining such system. For example, you say

This is done using an automated system that auto generates and randomizes (C++) classes. Maybe it could also add fake objects to the hierarchy to make identifiyng objects harder.

  • What do you mean by randomizing a class ? This is far from trivial.
  • Fake objects will eventually be spotted (dead code)

Anyway, I doubt that you will be able to perform some kind of efficient obfuscation on the critial portions of your code without serious drawbacks, such as degraded performances or completely wrong computations (eg. float calculus). If you have two different mechanisms for calculating the same value, you will eventually have different results for the same set of inputs.

piwi
  • 5,136
  • 2
  • 24
  • 48
  • To give you a hint. I use google protocol buffers to describe certain game objects and messages send over the net. I can use the reflection api to automatically change the description add random data and still have a valid interface – ecreif Feb 06 '15 at 14:10
  • @ecreif If you obfuscate data sent to the client, so that's not generating C++ classes, correct? Or I am missing something regarding a reflection API that you are mentioning? – piwi Feb 06 '15 at 14:18
  • No. Google protocol buffers generate C++ classes used for serialization. So I just put a randomizer between the actual description and the class generator. This generates new code for server and client – ecreif Feb 06 '15 at 14:19
  • @ecreif My bad; but that will not perform any kind of obfuscation on the rest of the code that uses received data; so that's virtually useless unless you also hide what you do with your data. – piwi Feb 06 '15 at 14:27
  • I want to use the generated classes not only for netcode but for data representation for all of my game objects. So theoretically use of the data is obfsucated as well. But of course there is code that does not really change. I would like to know if there are techniques to obfuscate that as well. Maybe changing the order inwhich the .cpp are linked? It would be realy interesting to hear from a real hacker with experience where the weak points are exactly – ecreif Feb 06 '15 at 14:31
  • For example is it possible to automatically track down pointers to the actual objects even if their layout changed? – ecreif Feb 06 '15 at 14:34
  • @ecreif If you change your internal representation, then you will also have to change code that interacts with your data. There are two ways to do that: have a layer that performs the translation (so real data manip will not change) or update your algorithms that interact with it (that will eventually be a maintenance problem) each time you generate new objects. Tracking the objects is not a problem, but the layout of your structures will be exposed when your code will access bits of data. – piwi Feb 06 '15 at 14:38
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/70396/discussion-between-ecreif-and-piwi). – ecreif Feb 06 '15 at 14:39