Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
Say I made a simple program that takes a file .dat that is encrypted in Binary Format, then I decrypt it into a byte array and then everything is rewritten again into the file decrypted.
For Example:
I've made a binary encryption algorithm. => 0100100001100101001000000110100001100101011000...
But this is very very easy to decrypt...
Is there any way, that, if it's possible does not need any sort of key, to encrypt my save progress?
In general you should never invent your own cryptographic algorithms, unless you have at least a PhD in both mathematics and computer science. But there are many good stock algorithms which have no known attacks and have free implementations in many programming languages. For example RC5, AES or Blowfish. Depending on which technology you use to develop your game, it might even offer secure encryption out-of-the-box.
However, the question is if encrypting savegames is a good idea.
First, when you have your game executable do the encryption and decryption, you have to include both the algorithm and the key in your game executable. That means a determined hacker can find them, extract them, and use them to build a savegame editor. So it can never be 100% secure.
Second, why do you want to do this anyway? When it is an online game, you should store the gamestate online where the players can not modify it. When it is an offline game, then why bother? A cheater can only hurt their own game experience at worst. The honest players who want to enjoy your game as intended won't be affected by this at all. On the other hand, allowing players to cheat can add value to your game. It allows players to experience the game in a different way which can just increase their long-term enjoyment of your game.
To encrypt and decrypt locally, you will need to store the key in your program, so people will be able to crack the encryption if they disassemble your code. There are tricks to obfuscate keys, but even with those a dedicated attacker will find the key and then post it online for all those who are less dedicated to see. The only thing encryption does prevent is people who use a hex editor - you can easily foil that with compression and anything that makes the file unreadable by an unzip program. E.g. add one byte in front of the data.
Alternatively you can append the md5 of the savefile at the end of the file, so you'll notice if a file has been tampered with. You can then use this to either refuse loading the savegame, or to flag support tickets appropriately so you don't waste time on issues caused by manually modified savegames. Again, this is trivial to circumvent by anyone who can read your code.
If you want something that can't be circumvented by someone who has access to the binaries on their device, you need to run part of the program on a server, which is under your control.
To answer your last question, a key plus encryption type just identifies the exact algorithm that needs to be applied to encrypt/decrypt. You cannot encrypt/decrypt data without an algorithm that defines how to do so.
Store a transformed SHA256 hash of the actual save data in the save file.
Compare the stored hash to the SHA256 value of the data as you load it.
If that doesn't match, they've cheated or corrupted the file.
Edit to clarify: this makes it more difficult to crack the anti-cheat system but still possible.
I would use a standard encryption algorithm (because it makes it harder to perform crypto-analysis on the saved file) but not one of the top five most used, and hide it throughout your code (because it makes it harder to understand what algorithm it is and where is the key.)
To hide the encryption algorithm into your code: take an open source version, understand its flow (which functions call which others an in what sequence), then rename all variables, struct fields and function names (just to be sure) and spread the functions all over your codebase, in different objects and modules, possibly separating their execution temporally as well (perform one piece of the encryption, then do something else, then after some ms come back to it from a seemingly unrelated piece of code and perform another phase of the encryption, and so on.) The key can be hidden in the same way, as a number of seemingly unrelated constants throughout your classes, that are accessed at runtime by the various hidden parts of the encryption algorithm.
Whether all this makes economical sense is another topic altogether.
