The following are notes on how to store character information on the client-side of a client-server game. I came up with these based on my limited experience using cryptographic software in another (non-game) project. I chose MD5 and Blowfish because they are essentially free (but still quite secure) algorithms.

You could store player information on the client side if you encrypted/verified it on the server before handing it to the player. When the player logs in, the client can upload the character information to the server. If it fails an embedded CRC test, then the file is rejected.

You could append a simple MD5 hash string to the file before sending it to the client. This MD5 hash could be seeded with a server-side string to prevent the players from simply re-calculating their own CRC after modifications. The weak link becomes the server-side seed string. If this was released/leaked, the security would fall apart. Adding encryption with an algorithm such as Blowfish would add another key that would be necessary to obtain, besides making it difficult to determine the interior format. Compression would help eliminate plaintext attacks.

So the steps would be:
1. Calculate MD5 index based on character file appended with a server supplied string.
2. Compress character file and index.
3. Encrypt compressed character file using Blowfish with a server supplied key.

The security system then consists of 2 server supplied keys and a compression algorithm. This would be damn near impenetrable by brute force attack--even if you limit yourself to 40-bit keys.

It would be necessary to have a periodic change in both keys. Old keys would be remembered so that infrequent players aren''t penalized, but use of an out-of-date key would be logged for possible review.

An alternative could be that each player has a server-supplied set of keys **that never leave the server**. Thus, no single cracking program could work for more than one person. For each new person, the cracking program would have to find the necessary keys. This would pretty much eliminate wide-spread cracking. These player-specific keys could still be updated either periodically or at the whim of the operator. In this case, use of an older key would logged **very loudly**.

I have never used either of these in a "live" setting. I present them only to give a quick primer in the kind of the measures that would be necessary. The idea of security is to make it as expensive as possible to breach. What''s often not understood, however, is that it doesn''t take a lot of expensive software to accomplish this goal.

If you are interested in crypto-security measures, I highly recommend _Applied_Crytography_ by Bruce Schnier.


DavidRM
Samu Games

I don''t know much about encryption and client/server data, but what about sanity checks? My very first game in Diablo, someone walked in at level 24 with 1200+ HP. Surely that''s outside the reach of normal gameplay?

Anyway, sanity checks would eliminate a lot of that "god player" kind of cheating. The sanity checks could be placed on the end user''s machine instead of the server (requiring no communication with the server). It would not be as easy to hack as simply changing a few hex addresses, right? And that much work for only a small gain would soon discourage the people who make the "trainers" and similar software.

But you''d have to make sure that all your calculations are correct... Maybe there would be a way to incorporate random (simple) sanity checks into the engine itself, without slowing things down too much. (That would really irritate hackers to no end!) You could protect the lookup table with some kind of encryption, with a random key or memory location, perhaps...

Just an idea...

And formatting a hacker''s hard drive...tsk tsk tsk...we''d all get some enjoyment out of that... But I don''t think it''s good to put in the game...lol


- null_pointer

Even if you keep your data files on a remote server, users can quite easily hack the executable. This is done in most cases. This way you can even freeze a value, by simply changing an ADD instruction =)

What i''d do to overcome hackers is to record specific events, that alter user statistics. If a hacker has altered a statistic of freeze it, then something alike is not recorded, hence the software is not aware of it. In regular times, feed the recorded events to the server, which will decide if there has been an impossible change.
Ie. the user has been recorded to loose 10hp when his HP was 20 and he still has 20hp whithough any heal recorded.... That is a violation.

Hope this helps. Open to any discusion

If you want to prevent banned cheaters to registers multiple time.

I sugest this solution....when the layer register, kepp the registration number in a database.

When a cheater will be banned, use the database to add the mention "cheater"

When anyone register, check with the database if the number was already enter, and iff the computer find than they were ban for cheating....well do not allow them to finish the registration.

Big pop up "CHEATER!!!"

Use better encryption.
I find that a nice large enigma code with a few shields on it works well.

There is no ideal solution, but ...

I''ve been thinking about this one for some time because of the place I work. We use smart cards for transaction security. This technology can be a solution to both the problems of game hacks and software piracy. An industry wide solution (led by the publishers since they lose the most money from piracy and the players since they lose the most from hacks) would easily make this cost effective (a user needs 1 reader and 1 card per game (maybe 1 card per publisher)) considering the estimates for money loss due to piracy is huge and smart gamers would pay a buck or two more to stop game hacks.

The idea is to put pertinent game information on the smart card and to allow activation of the game and updates to the data only through secure transactions with a host. The host has to be a secure system. Someone hacks your host your SOL.

Piracy hacks would attempt to circumvent the activation security check. I have ideas about how to make this difficult (though not impossible).

Game hacks would attempt to locate the pertinent data sets off of the card and to alter the code to use this new location. I have ideas about how to make this difficult (though not impossible).

Hacking the card is nearly impossible (you''d probably need access to an electron microscope). Cards use triple DES encryption now, but public/private encryption is coming soon. Even with triple DES it takes a whole lot of computers to break the encryption for one key and there would be several keys per card (maybe many ). Plus, after your 100 PIII 500s are done spending 180 hours to break one card, they have to start all over to break another.

Mike Roberts
former and future game developer

I don''t know much about encryption and client/server data, but what about sanity checks? My very first game in Diablo, someone walked in at level 24 with 1200+ HP. Surely that''s outside the reach of normal gameplay?


This way you can''t detect immortal or infinite mana-point players or those who have illeagal spells...

If you're worried about them changing the graphics but you still want to have it client side and quickly accessable, I suggest making a simple but unique encryption. They can only break an encryption if they know what kind of encryption you used.

As far as cheating is concerned, I'd send duplicate data accross. (i.e. If you healed 10 points, send what healed them(potion #23), how much (10 points) and what their new total is (1200))
You could also do a simple encrypt on that to throw them off. This'll make it harder to find
Or, you can set a bunch of other values at the same time with similar numbers. (dummy values)

E:cb woof!

Edited by - dog135 on 2/17/00 1:18:03 PM

I''m sorry, but so many of these suggestions imply that the would-be hacker is a complete moron, and also demonstrate zero knowledge of encryption theory.

dog135 - "They can only break an encryption if they know what kind of encryption you used." And since the encryption algorithm is IN the executable you give them, they know what kind of encryption you used. Ergo... This pretty much applies to EVERY argument I''ve seen that says, "Just use encryption." Like it''s some kind of magic wand we can wave over security issues. Anyone that thinks so seriously needs to find themselves a copy of Applied Cryptography (Schneier) and start reading.

As for "sanity checks" or other ways of statistically detecting cheaters, you''re going to run into all the same problems that Carmack has outlined in detecting proxy bots. How good can a human player be? It''s essentially a race condition between the cheater and the detection algorithm, with hackers designing cheats that strive to stay just under the detection threshold. It''s also a stupid, and time-wasting exercise as a developer.

Ultimately, there is no correct solution to this problem that also maintains sufficient performance. Of course, you''re trying to develop a massively multi-player twitch game, so you''ve lost already. Latency wins. You lose.

-Brian

You also have to be careful that you don''t screw stuff up yourself, when patching their client *smile* I''ve seen a lot of that happen, especially with Ultima Online.

One of the patches by OSI managed to do a few things like cause decay rate to speed up by about 500%, but it also randomly shifted some of the player stats to become 32,000 (str,dex, or int). This would have flagged the player''s account as a cheater in the cases described above with server checking, though the player was innocent. Would you want to go through literally thousands of accounts trying to figure out whether it was your mistake or a real cheater? Also, regardless of whether they cheat or not, people will claim they don''t. If you''re already cheating, lying isn''t that big of a stretch, so be prepared for your game''s tech support lines to be inundated by "I didn''t cheat! Really! My 2 million hitpoints were (a) a bug from your last patch (b) something messed up in you reading my stats (c) i''m a really, really super player, worship me (d) my *insert random relative* screwing around with a hack and I''m so very, very sorry (pick one.)"
I think that''s why so many companies (even Blizzard, with their new "secure-server" setup for Diablo 2) choose to keep the player''s data server-side.

-fel

~ UO-patch-screwup related amusing story... One of the counsellors got called by a guy who needed help due to the patch. He randomly got 32,000 strength. Due to the way the game works, +str means +weight, and there''s a set 450-stone weight limit of how much you can carry... so he was way too heavy to move. He logged in inside his house sitting on a chair, but due to the +500% decay rate, the house crumbled in about 3 minutes. Soon after, a bunch of player killers came up and started shooting him... but 32,000 strength means 32,000 hitpoints in the game, so his health wasn''t even moving on the status bar. The counsellor showed up to see the guy say to the player killers "Don''t make me get up and come over there..." The player killers fled in terror. ~