suliman

Hiding savedata to prevent save backup

Recommended Posts

Hi

Im making a rougelike with permadeath and want to make replacing the savedata harder (a little bit) to prevent backing up the game state. Its a simple binary file and i dont need encryption.

 

NOTE: i dont want serverside solutions or to discuss why i want to prevent savegame backup.

 

1. Just name the save "sound.bak" or something. Really simple but also very easy to "crack"!

2. Save the data so some silly folder like "C:/appdata/flashdata/fakecompany/sound.bak". But ugly to create folder on the users computer and what if this folder is cleaned out (since its not supposed to be affiliated with the game)? Then the user will loose the progress.

3. Save a timestamp to the savefile and keep a registry of the timestamps somewhere. If the savefile is replaced they will mismatch and you can refuse to load that savegame. But if the player backups the registry then? Which means i have to "hide" the registry file as well.

4. Similar to no3 but using windows registry for some timestamp check. Would this improve anything?

5. Any way to just make the file itself harder to see in the folders?

 

What would you suggest? Or something else? Im aware a cracker would find a workaround in minutes but i just wanna make it less tempting for an average player.

 

Thanks!
Erik

Edited by suliman

Share this post


Link to post
Share on other sites

The only thing I can think of is to make it harder.

 

You dont want to be writing over actual data/exe (might damage them by malfunction) files, so dummy ones will have to be created/used.

 

Huge files (or very numerous small ones most of which you just 'touch' to fake their modification) that are too onerous to copy/restore  - how big is too big though  (wasted space)??      The save data itself should be encrypted to make it hard to spot within other files..

 

Combining some file stuff with registry entries to make it more complicated (have to save/restore more than a few things for it to be 'valid') might disuade some people not to bother (and some follow-the-leader pattern between the elements that randomizes which of serevarl of the ~87 dummy files (with changing filenames/subdirectories) need to be copied/restored to get all segments of the save data  (add in some encoding of the registry data to not give easy clues).  Mutating directories within the game's own base/root directory hopefully wont flag antivirus scanners etc...

 

Registry entry shell game might likewise be part of it (and leave a progression of the old no longer used entries to muddy attempts to trace the registry data)    -- but remember the more complex it all is the more likely it will get whacked if the user turns off in the middle of a 'save'  or does restores of various kinds.      

 

Thats all just to make it harder.   A dedicated cheater will figure out what changed, BUT will it be worth their time to routinely cheat if you have some mutations thrown in so they can't write a simple batch program to do their copy &restore ??  Doing it by hand every time might get 'real old, real fast'  to many potential cheaters.

 

--

 

Funny is having dummy save data that looks right, but isnt actually used just to throw the dumbest cheaters a loop,  and (heh) online forum 'cheat help' telling them that those ARE the right files.....

Edited by wodinoneeye

Share this post


Link to post
Share on other sites

Anything you put on the local machine can be undone, without exception. 

 

People will even go so far as rolling back a disk image, or restoring from system restore or backup.

 

There simply is no reliable way except going to a server which you said you don't want to do, was there a reason for that?

Share this post


Link to post
Share on other sites

So... many people log in just to state EXACTLY what i wrote in the post i have no interest in and already know. Not very useful.

 

Im asking for simple hiding tricks. Comments on the ones I suggested or other ideas are useful.

 

@Brain

I dont want online simply because thats more mess (and possibly costly) than I prefer to handle for this feature:) Also it forces the player to have internet connection/be online.

Edited by suliman

Share this post


Link to post
Share on other sites

If I was to do this, I'd start with a fixed size save game data file with a fixed number of save slots.  This one file will store the save game data.

 

When saving to that file, you can also create a hash based on some of the save data.  This hash could be stored in a separate file in a different directory (i.e. standard user folder) or stored in the registry.  A timestamp could be part of the hash.  Then when loading, you could compare the hash to the save data, and in event of mismatch disallow the loading of the data.

 

Obviously anyone who figures out that data is stored in two places can get around that.  But you did say you only want to make it more inconvenient for the average user.

 

And for the record, I also think this 'feature' is a bad idea.  It seems like something that would just annoy people, so not sure why you want to include it.

Edited by Shpongle

Share this post


Link to post
Share on other sites

@Shpongle

Yeah that seems to be the best method.

I just dont want to leave the data to obvious to meddle with (not to INVITE the player to take the easy way out first thing). I dont see how it would annoy any player just playing the game. You can still save ingame, you just have to go an extra mile (or meter) to meddle with the game data.

Share this post


Link to post
Share on other sites

I would use steganography to do this.

 

Embed the save data in a special RIFF tag within a wav file or such within the game data, or within a special JFIF tag within the jpeg of a texture or sprite. Asset metadata makes for a great hiding place...

Edited by braindigitalis

Share this post


Link to post
Share on other sites

I just dont want to leave the data to obvious to meddle with (not to INVITE the player to take the easy way out first thing). I dont see how it would annoy any player just playing the game. You can still save ingame, you just have to go an extra mile (or meter) to meddle with the game data.

 

It could annoy people for two reasons:

 

1) It prevents people from backing up their saves, which prevents a person from migrating their saves to a new platform.  As someone who has done this multiple times across multiple systems, preventing that is very odd to me.

2) It prevents people from circumventing the permadeath mechanic.  While that could be the intent of the game, it could also be a source of frustration.  And there's no real harm in letting people get around it, is there?  It only affects their own game experience.

Edited by Shpongle

Share this post


Link to post
Share on other sites
What i would recommend is, don't bother with hiding the save game data. If someone want's to cheat, that's their prerogative.

What you might want to do, instead, is make your game able to detect a backed up save was loaded, and do something with that information ingame that doesn't affect gameplay itself (like, you don't want to take away the players items or exp or ...).

Upon detecting the loaded save game is a backup, inform the player of what he's done, tell him his score will be set to 0 (if you have a score), or that this character won't go info a hall of fame (if you have a hall of fame), or something (if you have a something), and ask him if he's sure he want's to continue. If you don't have any feature like scores/hall of fame/something, then you might want to think about adding a feature that is influenced by a valid save game, which you can "take away" for backup save games, and which is not in any way gameplay related.

Of course, you'd have to make sure your backup detection really works in every scenario imaginable, because you don't want to punish legitimate things like switching hard drives, OS reinstalls, transfering the saves to another computer entirely, etc.

Share this post


Link to post
Share on other sites

I totally get where the OP is coming from. I've played FTL on PC and cheated occasionally to backup saves. Now I'm playing on iOS where it's harder to cheat - it's still totally possible, but there's enough friction in the way of cheating that I don't bother. The game is a very different experience because the stakes are much higher when permadeath can't be circumvented.

 

IMO, your option #3 is the best. By having a save file and a corresponding registry entry (with a timestamp or hash or something), it's still easy for someone to cheat/transfer the progress, but I think the extra step of having to modify the registry adds just enough friction to the cheating process that I think that large numbers of people wouldn't bother.

Share this post


Link to post
Share on other sites

The obvious things (such as anything on the client can be broken, and don't do this, don't annoy people...) have been said, but if you still insist, what I would do is something like this:

  1. Calculate a 64-bit CRC (or cryptographic hash if you will) from the latest valid savefile, and set the file modification time of the folder where savefiles are stored to that value (or, some other folder, the data file folder if you have one). This will not prevent someone from re-imaging his drive but it will prevent the most naive attempts at copying over old savefiles. Sophisticated backup software, unlike Explorer copy, also retains modification dates, but then again, who remembers to also copy the containing folder, or an unrelated folder like the data folder! It's clever enough to fool the most naive users until someone discovers how it works and makes a post on the internet (which is probably a week or two for a not-so-wellknown game).
  2. If you want to be more clever than that, you can use alternate datastreams or extended attributes (somewhat at the expense of portability), but that will not hold someone who has a minimum of technical knowledge back either (it will thwart average users, though). ADS is stunningly trivial to use if you know how (just append the "magic formula" to the filename), and a surprisingly good way to hide stuff from an unaware end-user type of person. It's also a good way of totally fucking up if anything different from NTFS gets involved, unluckily (though this may indeed be an advantage for you, prevents copying files to FAT filesystems...).
  3. Also save every level you've visited (randomly generated, I figure, as "roguelike" implies?). This not only allows the player to go back to a level with all loot where he dropped it (which is a nice feature), it also gives you a somewhat bigger data set, which means backing it up is more expensive. Though of course, in an age of terabyte harddisks, who cares if you have 10 or 15 megabytes of save data. Saving every level also gives you the possibility of creating a hash chain, so level 3 will validate level 2, and level 2 will validate level 1. The last one could validate the last valid save file (either instead of, or in combination with a file modification time or any such hack).
  4. Use encryption. Yes, you said you don't need it, but you do. It is much easier to do nasty secret stuff and to keep your little secrets if the other person cannot trivially read everything. A binary file which is still somewhat parseable if you know how is nice for holding back the casual end-user, but a binary file which is only "total random garbage" (encrypted) is better. It needs not even be a particularly good encryption, since breaking the encryption is trivial for anyone dedicated to do so anyway (seeing how both key and algorithm are stored on the machine). But even poor encryption will reliably ruin the average user's experience unless your game is famous enough that people start putting up automated crack tools onto the internet. If that happens, congratulations, means you've succeeded.
Edited by samoth

Share this post


Link to post
Share on other sites


I dont see how it would annoy any player just playing the game.
Please make sure that player is still able to play the game! Imagine such scenario: Parent (admin) installs the game in "Program Files ", kid (user) plays it. If you try to hide your save anywhere outside of user space, like system folders, most key in registry or especially installation folder, the player will not be able to save at all.

Share this post


Link to post
Share on other sites

As stated briefly you must also strongly take into consideration playing the same saves on multiple computers. For example, I would play Kerbal Space Program at school in between courses and copy saves to my desktop. If you make saves too hard to find (or use some complicated scheme) I as a player would be greatly annoyed certain saves work only the computer that created it. A save is a save regardless of where it originated from. 

 

Beating a user who doesn't bother backing up saves (and one not prone to cheating) is relatively straight forward. Just adding a flag into the header to mark the character as dead is a solution. To add salt to the wound take all his gold and items as well, he won't need them in the afterlife anyway smile.png

 

Granted if he plays on more than one computer, or backs up his saves, it will break this but this may not be such a bad thing. For instance, lets say a child plays his father save and dies. If you can't restore the save you will end up with a potentially angry father and one terrified child! If he wasn't backing up saves before this, well, he most likely will be afterwards in case it happens again. If he did then a simple copy and paste will return hours of work over a simple mistake. 

 

If you feel very strongly about disallowing copying then just have a secondary file that's created in the users documents folder (ideally where saves are located as well). This file will keep a unique id associated with each save, and whether the save has been marked as dead. If this file is deleted or has an invalid header/crc you would have to remake it. How else would existing hardcore characters that didn't die be playable? The registry would also present the problem of fresh OS installs and the like..

 

Thus back to the start of the endless circle.. wacko.png

Edited by Aiive

Share this post


Link to post
Share on other sites

If you really want to do this, then I'd recommend you at least put a warning file next to the save data, with a name like "copying_or_moving_the_save_file_will_invalidate_it.txt", so that users know not to try.

Share this post


Link to post
Share on other sites

1. Just name the save "sound.bak" or something. Really simple but also very easy to "crack"!

Just mask it as an asset exploting a file format which allows putting more stuff at the end of the stream while regular file viewers will ignore your save data (i.e. png, jpg, pdf) like AngeCryption does (see slides).
Just make sure you don't really depend on that asset in case the file saving goes corrupt.

2. Save the data so some silly folder like "C:/appdata/flashdata/fakecompany/sound.bak". But ugly to create folder on the users computer and what if this folder is cleaned out (since its not supposed to be affiliated with the game)? Then the user will loose the progress.

If you do that, your program enters malware territory.

3. Save a timestamp to the savefile and keep a registry of the timestamps somewhere. If the savefile is replaced they will mismatch and you can refuse to load that savegame. But if the player backups the registry then? Which means i have to "hide" the registry file as well.

What happens if the clock goes kaputt? Quite common if the battery died. You'll just annoy your users.
Timestamps aren't reliable.

Also be aware that the process of safely saving a file (that is, following good practices) inherently involves performing an internal backup: (assuming no obfuscation) You first rename your Save.dat as Save.dat.old; then write your new Save.dat; and finally delete Save.dat.old
If the system crashes or power goes off, you first check if there's Save.dat.old and verify Save.dat is valid and doesn't crash if loaded. Once Save.dat is known to be ok, delete Save.dat.old; otherwise delete Save.dat and rename Save.dat.old as Save.dat
This way your user won't lose their entire progress, just the last progress they did (the power went off while saving... after all).

Take in mind that solutions that rely on writing to two or more locations to verify the save hasn't been tampered; you have to be very careful that writing to all those files ends up as an atomic operation, otherwise your "anticheat" technology will turn against your honest users who just experienced a system crash or a power outage and now have a valid save file with a corrupt verification file.

Why prevent cheating on single player games? Cheating is part of the fun. Otherwise TAS Video communities wouldn't prosper.

Share this post


Link to post
Share on other sites

I'm in the camp that says its not worth your time to do something novel (some new kind of 'protection' scheme) or overly 'clever' (and disrespectful, like hiding files in unexpected places on a user's machine, especially silently).

 

If you must do anything at all, do something with standard tools and practices. Yes, the experienced cracker will get around this still -- the experienced cracker will get around anything you throw at them. So it follows that the best use of your time is to reasonably thwart the casual cracker (they kind who seeks out a save file and makes his or her own backup, or might open ASCII save files in a text editor and try to manipulate them) with a minimum of effort using standard mechanisms.

 

For example, if you put a binary-formatted save file into a password-protected.zip archive (and maybe that password is a hash of the user's "product key" or their registered email address, and named it something innocuous like "metadata_db.bin", no casual cracker would be likely to get around it. Anyone who has the skill to determine what you've done and extract the password scheme from your executable is not a casual cracker. Now, once even one real cracker takes an interest in defeating you, they'll probably release tools to automate the process if your game is at all noteworthy, and once that happens the floodgates are open to all, but at least the less-scrupulous players will have to seek out the crack tools first -- and I guess that if causing them that small inconvenience helps you sleep better at night, go ahead, just make sure the sleep you gain pays dividends to whatever time and sleep it cost you to implement the scheme in the first place.

 

[EDIT] Thinking about it more, even what I described, because of where the metadata_db.bin file would most likely be located this is still somewhat unscrupulous, because it wouldn't play well with the way that user might try to backup their data. To be a good citizen on your users machine, and you should always strive to be, you should put their save files in the place designated by their OS, not just next to where they happened to install it (this follows for user and global configs, screenshots you allow them to take, etc, too). For user configs and save files, this is well and narrowly defined, on something like linux, its well defined but I believe more broadly. On Windows, if you play by the rules of where certain kinds of data should go, a users can use the system backup and restore or migrate their user profile to another PC, or move their data to the newest operating system, and they should be able to expect that everything just works, even if they have to re install your game. You should try to make sure they're not disappointed. You can still put it in a password-protected zip file with an innocuous name if you like though (but the strange name probably less indiscreet here.)

Edited by Ravyne

Share this post


Link to post
Share on other sites

HI,

My comment is a little late to the thread, but is there any reason why you can't use the file ID (descriptor/handle) that the operating uses? 

Dahnn

Share this post


Link to post
Share on other sites

If you're going to implement something like this, you'll want to keep the following in mind:

- Unless you use a server, it's going to be circumvented. You should therefore expend the minimum amount of time and effort to get the job done, and ensure you're not negatively impacting the experience of non-cheating users.

- Players like to and should be able to back up their saves (to move to another device, reinstall Windows, for peace of mind, etc). Your solution should allow this.

- If your game doesn't work for players you may attract bad reviews, etc. Your solution should not trigger accidentally, and must not look like it could be a bug if it is triggered.

 

Keeping the above guidelines in mind rules out most of your original ideas for violating at least one. I definitely wouldn't go hiding things around the player's computer.

I would suggest the following:

 - Apply some VERY basic encryption  (ROT13, XOR, etc.).

- Store the save in a protected archive format, but still name the file "savegame" or similar to allow backup.

Job done, casual fiddling should be deterred.

Hope that helps! :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now