It is impossible to recover or recreate the input data from just the hash. A good hashing algorithm must guarantee no collisions, which means that no different inputs A and C should ever produce the same hash B. Hashing is basically a one-way operation that produces, for a given input A always the same unique hash (like a signature) B. What if there was a way to know that someone tampered with the data and reject loading the save? We can do that with the use of hashing algorithms. Maybe it’s ok for users to try to modify the values as long as we can detect it and reject it from loading. Now… perhaps we can somehow guarantee data integrity. By comparing the new game-save file with previous ones, you can find out which values have changed and what they alter in-game.ĭespite this, I highly suggest the use of binary format, and if not rolling your own (for various reasons), then perhaps using a library like Google’s protobuff, or bson, as the benefits of speed and filesize are worth it on their own. Modify it and save, discovering that way where the offset and value for the character’s health is stored.Īlternatively, someone could load the save, and use an item like… drink a health-potion and then save the game. For example, someone with a 168 hit-point character, could try to read groups of data as integers and floats of varying size and endianness and what not, and stumble by skill or luck to a suspicious 168 value. People can easily map in game values to their binary representations. The optimized version would not rely on the map + loops, but would be unrolled and have pre-set the type and size values.Ĭan cheaters break a custom-binary format approach? YES! Here’s how a binary file looks when “naively” opened.ģ,290 bytes text version (base64 encoded json) 559 bytes binary version.Īnd let’s compute some timings in parsing and writing - (rough unoptimized js version) Īn unoptimized version written in JS is 25–30% faster in Chrome (though a C version would outperform it by orders of magnitude, basically we are just dumping memory to disk, no encoding and no operations, very hard to beat that). Of course, binary also adds the benefit of preventing people from reading the data. They are by design much smaller in size, and much faster to both read and write compared to text based approaches. I am a big proponent of this approach, since binary files have a plethora of benefits compared to text. It is also fairly inefficient with it’s filesize being 33% bigger than the original input.Ī much better approach would be to use a binary format. It is one of the most commonly used types of encoding, especially on the web, where it’s used to portray an ascii representation of binary information (for example, embedding an image directly in an html document or a css file). If the intention is to prevent people from modifying the files, base64 is not a very good choice. In the above example of “Unworthy”, it was easy to modify the saved game, because it’s relying on common data formats. PART 2: WAYS FOR DEVS TO PROTECT SAVE FILES
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |