52 replies to this topic

[rpiller]

So making an online game. I've created a launcher/updater program that does the auto updating of game files.

My next question is about making sure the client has the most recent updated and/or not tampered with files before they play. I have an idea on this but curious about what others think.

My idea is after the client logs in, hash codes of each major file is sent to the server in one message. The server will then check these against a table of hash/filenames of the most recent update. Does that seem good enough? I suppose I should send these encrypted as well. Any other ideas around this that I haven't thought of? I'm sure there are some.

[hplus0603]

Strictly speaking, it is not possible to prevent tampering by a determined cheater.
You have to design your game rules to be enforced by the server based on packets received by the client, and you have to assume that the client might be a clone written by Chinese gold farmers, or vindictive, snotty 14-year-olds.
Checking files as you load/use them is a good idea anyway, because it will detect people who are out of date, have broken hard disks, etc.
The typical way this is done is to send a manifest of all files (file name + hash) as one of the files, and provide the hash of the manifest itself from the server. If the manifest hash mis-matches, a new manifest is downloaded. Then, each file is checked against the manifest, and if there's a mis-match, the proper version is downloaded.
Exactly how and where this is all done varies. There are many ways to skin this particular cat.

[turch]

As hplus0603 said, make your server the authority.

In addition to hashing the entire thing, I'd hash each file differently at different levels (i.e. hash each GB of a file and the whole file). It is fairly trivial to make a modified file hash into the correct value, but if you have multiple hashes per file it becomes much more difficult.

[hplus0603]

turch, on 30 January 2012 - 11:39 AM, said:

It is fairly trivial to make a modified file hash into the correct value, but if you have multiple hashes per file it becomes much more difficult.

But that doesn't matter, because the attacker will just intercept the network send request, and make it send the hash value you want to get, no matter what was actually calculated. The only reason to hash sub-sets of a file is if you want to patch only a part of a file, that that, in turn, requires some good way of identifying subsets of files that doesn't change each time you patch the file.

[turch]

hplus0603, on 30 January 2012 - 04:03 PM, said:

turch, on 30 January 2012 - 11:39 AM, said:

It is fairly trivial to make a modified file hash into the correct value, but if you have multiple hashes per file it becomes much more difficult.

But that doesn't matter, because the attacker will just intercept the network send request, and make it send the hash value you want to get, no matter what was actually calculated. The only reason to hash sub-sets of a file is if you want to patch only a part of a file, that that, in turn, requires some good way of identifying subsets of files that doesn't change each time you patch the file.

True, but its a little bit of extra annoyance to an attacker for about 10 minutes of extra coding. IMO worth it.

[swiftcoder]

turch, on 30 January 2012 - 04:18 PM, said:

True, but its a little bit of extra annoyance to an attacker for about 10 minutes of extra coding. IMO worth it.

That particular rabbit hole goes a long way down.

You are trading days of development, weeks of QA, not insignificant server load, and potentially thousands of customer support calls, all to delay a script-kiddie by 10 minutes.

And of course, the script kiddie isn't working on salary or a clock, and it only takes a single enterprising individual to provide a crack for every single one of your customers...

[wodinoneeye]

Since any of the programs (including the file validator) could be reverse engineered and tampered with (like automaticly sending the right values even when every file no longer matches the checksum/whaterver).the first thing to force a real validation on is the validator itself.

There has been discussion on these forums before and I thought that a mechanism that reloads every login (every time executable run) a new validator (recompiled daily+ with different code scrambled to result in different binary hash/checksums/exe/ size) or a .dll component so the program does not have to restart would force the hacker to constantly rebuild their hack (and redistribute it to those not cappble of doing the work themselves -- and in that case have them be personalized PER USER so that one hack doesnt work for any other user). If automated mighteven be able to be done constantly while the game runs (dll unload and reload).

Once the validator is safe the rest of the programs/files can be checked (and they too can be replaced every day/periodicly in a 'unique' hash/checksum form.)

Partial file replacement (mainly the game exe runtime) would be done constantly (every login - ive seen multimeg files dl in seconds for exist mmorpgs... so not to horrible a delay) to have something different to check (that too would be a per user variant that would make each one (at that point in time ) unique and force older copies to be invalid)
That would block direct substitution by the hacker and force more complicated insertion of hacked logic into the main process)

Next would be a communication encryption scheme -- part of the main exe (matched on a per user randomized system that is complement component on the server side) The serever would know instantly if the encryptor failed. Use could be rotated with random 'checks' against any/all files to look for tampering (even in the middle of playing) . That would deny communication intercepts/insertions as the encoding would constantly change thru too many different methods to cheat on them in a timely fashion (realtime games the data is irerlevant in mere seconds often)

With small .dll modules constantly shifting each with different encoding scemes and cyphers the data load (renewal overhead) across the connection might be fairly minimal. The server could have a dictionary of thousands of encryption substitutions (matching parts for client/server sides) and more could be programaticly generated for freshness constantly. The hacker could never keep up. Modules would be algorythmic variants as well as cypher data so that the hacker could never predict what might be loaded 'on the fly' and too difficult for automatic code breaking/adapter building for his hack. Turn them over constantly and use more than one at once and anything outside of the games iown exe cant keep up with the changes.


It eventually comes down to 'making it much harder' and if the hacker cannot automate his hack reenginerring system and it takes too long to redo it by hand (and cant redistribute to script kiddees if he CAN somehow break it) then the hacker will spend all their time rehacking and have no time to cheat (and the greater number who are reliant on getting hack from others are totally screwed)

Add a server side system to report incidents when the system detects a hack attempt and identifies repeaters (more than just the odd mistake such a complex system might cause -- a pattern of trying to hack) for human review and banning the perp (with evidence)

ALL or part of a system like this would make the hackers work significantly harder and past a certain point unrewarding for most but the dedicated/fanatics.


Hmm this sounds like an interesting project to actually do for a demo -- who knows if its good enough sell it to the MMORPG companies for a cool million...

----------------------------

This all of course is in ADDITION TOO easy server side validation.

-----

!!!!! I now just remembered that much of this what looks like OVERKILL was actually origianlly to figure out how to offload servers logic with PEER (P2P) execution of some of the servers load ---- like heavyweight AI (one of my interests) which can take ALOT of CPU processing and making use of the numerous user's client machines could significantly increase the games AI resources.

Think sanitized/genericised/encrypted (all in-memory) process jobs that constantly shift amongs the peers (so a user never knows what it is his machine is working on minute to minute and even if he did it wouldnt be there for long). The above security stuff would make it safe to run on the peers without compromising the game data. Of course you would have to VET the available peers as some are just not reliable or are underpowered or try to hack. Some reward would be made to players willing to have some of their computer resources used to help the server.

-----

[turch]

swiftcoder, on 30 January 2012 - 06:35 PM, said:

turch, on 30 January 2012 - 04:18 PM, said:

True, but its a little bit of extra annoyance to an attacker for about 10 minutes of extra coding. IMO worth it.

That particular rabbit hole goes a long way down.

You are trading days of development, weeks of QA, not insignificant server load, and potentially thousands of customer support calls, all to delay a script-kiddie by 10 minutes.

And of course, the script kiddie isn't working on salary or a clock, and it only takes a single enterprising individual to provide a crack for every single one of your customers...

But if you're hashing at all, you're already way down the rabbit hole. If you're only trying to make sure files are up to date, there is no point in hashing, it would be way simpler to send file size info + each file's version number.

[hplus0603]

@turch: Hashing helps for users who have hard disks that don't read back whatever you initially wrote. Such things exist -- I'd expect 1 out of every 10,000 users to be affected by this.

@wodinoneeye: All your fancy mechanisms don't mean nothing. Your server will receive packets from the greater internet, and has to make decisions based on those packets. I can form packets any way I want. Perhaps I patch your client. Perhaps I write my own client. Perhaps I point my Windows box at a Linux box for its gateway, and modify the packets in flight. Perhaps I run your game in a virtual machine inside my Windows box and use the virtual network redirect to patch the packet stream. There is no way you can detect this and separate "touched" packets from "untouched" packets, because I can just inspect your client and inspect your packet stream and figure out how to generate correct packets. And once one person has figured this out, every person can download it on the internet.
The *only* defense against cheating is to not trust the client, and enforce all game state and rules on the server.
This is assuming your game is popular enough that anyone cares to cheat, of course. If you have no players, you have no cheater problem :-)

[rpiller]

So for file validation this looks like the way to go. Step 1 is to make sure users are all running the correct version. I get the server side ruling all, but if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that? It clearly gives him an advantage because he can see you coming from anywhere. Hash checks would stop that for the people who don't know how to redirect network traffic but know how to model and replace a file, but even server side validation can't detect that's happening if they are able to intercept the network traffic and send the right hash code. Is there really any way to handle that? My game won't have that specific problem but I know I've seen cheats like that in counter-strike before.

Like some are saying you could make it harder on a hacker by doing all sorts of crazy stuff, but it does add time to your development and will introduce bugs.

[Anders Elton]

Well, this is the hard part.
As long as the client knows that a model is behind a wall, but does not draw it because there is a wall there, its "easy" to add a wallhack - simply because the client *knows* something is there

The server could do Line of sight check, and decide not to send models that are behind walls, for example, which would make wallhacks like that impossible. There are other concerns, here, because in modern high end games you might see shadows/hear sound from specifict positions as well.

If you look at the big fps games out there, none of them has managed to solve this problem yet. But if you are not making a game for the big players out there, this might not be an issue to you at all. Its quite possible that noone will make cheats for your game anyway.

For mmo's this is "simpler" since they have rpg systems that decide the outcome of combat, which hopefully is calculated by your server.

To reiterate what has been said in this thread many times already: To prevent cheating, the server needs to do the calculations. (and even then it can be tricked: speedhacks etc)

[Antheus]

rpiller, on 31 January 2012 - 04:00 PM, said:

but even server side validation can't detect that's happening if they are able to intercept the network traffic and send the right hash code. Is there really any way to handle that? My game won't have that specific problem but I know I've seen cheats like that in counter-strike before.

Hacks like that don't touch the game at all. They sit between DX/OGL API and driver and manipulate the command stream sent to GPU.


How to fix the problem? Just like everyone else did. Go to gated and monitored platforms, where you have 24/7 admins banning people. Console + online service. Not necessarily the best option, let alone most accessible one, but something that works.

Alternate solution: don't use competitive modes, use co-op. Won't fix the problem, but will affect the incentives since it's no longer a zero sum game.

[hplus0603]

Quote

if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that?

You fix it through design, not through technical counter-measures.
Design the game so cheating doesn't give you an edge. Co-op is great for this!
Design the game so that cheaters end up match-making to other cheaters.
Have a premium service where you have admins on all the time, and can request random screen shots from clients (like punkbuster) -- doesn't mean clients can't fake out screen shots, but it's harder to do well.
I really like it if you can design so griefers play other griefers, cheaters play other cheaters, and friendly noobs play other friendly noobs...

[wodinoneeye]

hplus0603, on 01 February 2012 - 09:53 PM, said:

Quote

if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that?

You fix it through design, not through technical counter-measures.
Design the game so cheating doesn't give you an edge. Co-op is great for this!
Design the game so that cheaters end up match-making to other cheaters.
Have a premium service where you have admins on all the time, and can request random screen shots from clients (like punkbuster) -- doesn't mean clients can't fake out screen shots, but it's harder to do well.
I really like it if you can design so griefers play other griefers, cheaters play other cheaters, and friendly noobs play other friendly noobs...

Heh and you call MY stuff 'fancy mechanisms'. Changing the whole game from something you might want it to be to be something else....

[wodinoneeye]

hplus0603, on 31 January 2012 - 11:16 AM, said:

@wodinoneeye: All your fancy mechanisms don't mean nothing. Your server will receive packets from the greater internet, and has to make decisions based on those packets. I can form packets any way I want. Perhaps I patch your client. Perhaps I write my own client. Perhaps I point my Windows box at a Linux box for its gateway, and modify the packets in flight. Perhaps I run your game in a virtual machine inside my Windows box and use the virtual network redirect to patch the packet stream. There is no way you can detect this and separate "touched" packets from "untouched" packets, because I can just inspect your client and inspect your packet stream and figure out how to generate correct packets. And once one person has figured this out, every person can download it on the internet.
The *only* defense against cheating is to not trust the client, and enforce all game state and rules on the server.
This is assuming your game is popular enough that anyone cares to cheat, of course. If you have no players, you have no cheater problem :-)

The problem is that for it to work most of the mechanism has to be done to protect the next part that covers all the holes (it IS a complex solution).

You can 'touch' the packet traffic anyway you want, but if you dont know what to properly send (to read them to modify) then you are stopped.

For the full solution, the essence is that the client code and the transmitted data formats keeps changing faster than the hacker can keep up with the changes -- cant hand change the hack and any automated hack patcher would not get done before the encryption was changing again (whether they intercept packets or mutate the client or whatever).

(Did I not mention that the scrambler methods are sent as a blocks of machine code and is inserted into the executable ??? -- its not some ordinal to a method dictionary already in the client -- client is patched constantly with code snippets that are constantly regenerated/randomized on the server -- its a moving target)

I recall one issue that might be the deal breaker -- read/write/execute permissions on program segments might not be workable (especially if they crank up security to nazi levels on the newer OSs) That self modifying code issue might be simply solvable with reloading DLLs (that would also give the hacker a leg-up on auto hacking it though)

In a 'Just Make it Harder' partial solution -- having the right parts of the game executable customized automaticly 'on the fly' prevents static cheats from propagating (distribution to scriptkiddees). The wouldbe cheaters would be required to have have a complex hacker rig to break this system.

Simply reloading a modified client every time you start the game would go a long way (with sufficient differeneces in data transfer encodings each rebuild) . Just change the data chunk identification to different ordinals (simultaneously on client & server) would do alot to obfuscate data and break hacks.

Constant on-the-fly Spot Checks on chunks of the game executable (back to the server) would force a more complex hacked solution -- which would require the hacker to service spot checks requests with data from a well maintaining a 'pristine' (possibly constantly patched) executabe image as well as his hacked one actually running.

This again is still ALREADY with proper server side validation, but many cheats like aim-bots arent stopped by those.

YES much of this is overkill (its only for a game after all) and was really extended for Peer to Peer processing (which if also for a game lead to 'who cares' )

[wodinoneeye]

rpiller, on 31 January 2012 - 04:00 PM, said:

So for file validation this looks like the way to go. Step 1 is to make sure users are all running the correct version. I get the server side ruling all, but if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that? It clearly gives him an advantage because he can see you coming from anywhere. Hash checks would stop that for the people who don't know how to redirect network traffic but know how to model and replace a file, but even server side validation can't detect that's happening if they are able to intercept the network traffic and send the right hash code. Is there really any way to handle that? My game won't have that specific problem but I know I've seen cheats like that in counter-strike before.

Like some are saying you could make it harder on a hacker by doing all sorts of crazy stuff, but it does add time to your development and will introduce bugs.

You could do PART of my grand scheme and maintain some in-memory data (cypher block) that also is queried along with your file hashes etc, --- to make what the hacker has to send back that much more complex a response to (they have to now emulate it all in their interceptor while a kosher installation just does it directly within the game executable) -- just to make it ALOT harder.

EVERY packet sent back to the server might have a mini payload (even just a few bytes of overhead) with some different data pulled from that cypher block (offset+databytes from cypher) do this enough and the delays (intercept+digest+hack+send) involved might make their hacked game unplayable...

The cypher block would be partially based on the client version (or the executables bytes itself) and partially on some 'on the fly' data (user specific random) sent from the server periodicly (with the corresponding data on the server session maintained to be checked against)

[swiftcoder]

wodinoneeye, on 03 February 2012 - 06:21 AM, said:

The wouldbe cheaters would be required to have have a complex hacker rig to break this system.

Lol @ 'complicated hacker rig'. Your typical hacking rig is GDB, Wireshark and Vim, plus a few more specific pieces depending on the exact task at hand - but it's all free and open-source software that is probably sitting on your hard drive as we speak...

[Antheus]

wodinoneeye, on 03 February 2012 - 06:46 AM, said:

You could do PART of my grand scheme and maintain some in-memory data (cypher block) that also is queried along with your file hashes etc, --- to make what the hacker has to send back that much more complex a response to (they have to now emulate it all in their interceptor while a kosher installation just does it directly within the game executable) -- just to make it ALOT harder.

So you would suggest using 4096-bit RSA?

Meanwhile, hackers prefer to do something like this:

Quote

Congratulations,

youre luky winner of Diabl0 III Beta. Login to ur accout here to get it: http://diablo-tree-r...ner/diable3.asp

And it works.

[wodinoneeye]

swiftcoder, on 03 February 2012 - 07:05 AM, said:

wodinoneeye, on 03 February 2012 - 06:21 AM, said:

The wouldbe cheaters would be required to have have a complex hacker rig to break this system.

Lol @ 'complicated hacker rig'. Your typical hacking rig is GDB, Wireshark and Vim, plus a few more specific pieces depending on the exact task at hand - but it's all free and open-source software that is probably sitting on your hard drive as we speak...

Ive said it several times 'you want to make it harder'.... How many ordinary users know how to set those things up let alone make them work in an automated fashion for even the simplest parts of my solution (changing things frequently enough that the hackers have to constantly rebuild their hack mechanisms)

When some would-be cheater can just download something provided by the experts, install it and run the provided hacks, its easy and THEY are the majority of the cheaters.
Now harden the system and suddenly only the experts (what percentage do you think theyare??) can do it (and they cant distribute it fast enough to the script kiddees ) Some 'experts' might take it on as a constant challenge but even they likely will give up and move on to some other less bothersome cheat-easy game.

Suddenly cheaters are hardly there and THAT is the goal.

[swiftcoder]

You are not the first GDNet'er to go down this particular rabbit hole, by the way. Ysaneya beat you to it by 6 years, and the debate there would be well worth your time to read.

wodinoneeye, on 03 February 2012 - 03:24 PM, said:

How many ordinary users know how to set those things up let alone make them work in an automated fashion for even the simplest parts of my solution (changing things frequently enough that the hackers have to constantly rebuild their hack mechanisms)

You are suggesting that your software will download a small module each time, and this module will perform the checks and authenticate the results with the server, right? That way you can change the module regularly, to outdate older hacks.

So my hack would also download the module, and run it, just like your software does, and let it authenticate with your server. How will that work with a patched executable? Because I will be running your module in a sandbox, and giving it the original executable to work with, instead of my patched one.

This method of hacking is completely impossible to defend against (well, excepting TPM, but nobody wants that), because it works by showing the security/DRM checker exactly what it wants to see - and there is no way to detect this kind of spoofing (again, except for TPM).