|
Currently when launching the client of the game, it connects to the server and loads all the cachedata in a normal form (= folders, .txt files and .png files). However I don't like that the players can edit the images very easily and read all the .txt files etc.
|
|||||||||||||
|
|
As the game executable has to be able to decode the data to use it, there is no protection from an user determining the decryption key and doing the same to read the data. You can get limited protection from modifying files by encrypting them with a private key server-side, as the user will not be able to encrypt new data in a manner that is decryptable by the public key present in the executable. This of course does not protect against the user modifying the decryption key in the executable and re-encrypting all the data with a private key of their own. If this is a multiplayer game, there's no end to the amount of attempted countermeasures you can do, and there's a whole industry around mitigating them. If this is a single player game, let the user do what they want. Moddability tends to be a net win in publicity and is likely to extend game longevity way past what you intend it to. |
|||||
|
|
What do you want to prevent? Editing or reading? Preventing reading is impossible. Your client has to be able to read and display the images and text files to allow playing the game, so everything someone would need to crack any protection you add would always have to be included in your client software. If you want to make it less tempting for a user to just go in the files and read the text or look at the images and get the solution to a riddle too easily, use a simple transformation on your text and images, like XORing each byte with a fixed number or Rot13. But since users can go online and read walkthroughs, why bother? If you want to prevent editing (why? You'll prevent modders from modding your game, making it popular, and becoming already-educated future employees or collaborators), use a checksum or a signature. That will let you detect that a file has been modified and reject (or re-download) it. Checksums are not that hard to figure out. Signatures are pretty much impossible to figure out (OpenSSL will let you sign stuff). For signatures, there is a "private" key you use to sign the code, and a different "public" key your client uses to, but since a user can edit the client software on their hard disk, they could still replace the public key in the client with their own public key and sign their changed version that way. So in the end, if it's on the user's computer, the user can edit it. The only way to avoid the client from editing the game to make it easier is to not transfer the data to the client's machine until they actually need it, and to cache as little as possible. Also, if your game is a network game, you need to be even more paranoid and only send user actions to the server, not results of the actions, because anyone can hack the client to transmit "I just killed 1000 monsters", while it's harder to send messages that say "step forward, step forward, step forward, strike" to kill a monster. |
|||||
|
