- Home /
How easy it is to fake data stored in Application.persistentDataPath?
I was just wondering how easy it would be to fake serialized data objects stored in Application.persistentDataPath? I mean does unity create some kind of signature for them or something like that? I just couldn't find anything like this on the docs. Is it possible to simply load and deserialize data objects saved by another application (with the same package id) change their values, serialize them again and just feed back them to the 'victim' app. If it is possible, then what is the "standard" approach to avoid this (if there's one at all)? E.g. If I deal with some kind of sensitive data stored in JSON I just use MD5 hash of all it's key/value pairs followed by a salt value stored in some unreachable / hardly reachable location.
p.s. I just can't check it out myself now, so I'd be grateful if somebody who knows this mechanism explained it to me
Answer by Bunny83 · Apr 16, 2018 at 09:32 AM
Ok based on your mention of "packege id" i guess you actually talk about an android build? You should be more clear about your case.
The actual path that is returned by "Application.persistentDataPath" depends on several things. Of course the most important thing is your target platform. Specifically for android it depends on if internal or external storage is used and may depend on where the App is stored. Generally for non-rooted devices the internal folder is "rather" safe while the external (SD card) folder can of course be simply accessed by the user. However if security is an issue, just forget about storing sensitive data on the device ^^. A rooted device has access to all files / folders on a device. Even without rooting it's possible to tinker with internal files through the PC backup functionality. You can create a backup of your device, use a software on the PC to extract / unpack files from the backup, modify them and repack the backup. If you restore that backup the internal files would have been changed.
That's why all major apps with sensitive data store it on their own server. Though since your question is kinda abstract we can not really recommend something specific for your case. Is it single player or multiplayer? How important is that data?
Keep in mind the golden rule: "Never trust a client". This does not only apply to client / server connections but is a general rule for anything that actually runs on the client. Nothing is 100% safe when it reaches a user device, ever.
Using checksums is useful to identify modified or corrupted data (keep in mind that corruption doesn't have to be a sign of someone trying to cheat). The question is what actions you take when you identify corrupted data? Another way is to store the same data with different encryption at several places. This could allow to identify a single change which could be "corrected".
Generally there's not "right" way to store data and no "common" or "recommended" way. It completely depends on the sensitivity of the data, where it is generated, etc... Using uncommon strategies provides the best obviouscation. Though as you may know security through obscurity is no real security.
The behaviour of the persistantDataPath has changed over time and depends on the install location and the permissions set. See this answer for a bit more clarity
Thanks for your detailed answer! I know about common data security and server side storage. I came to unity with almost 10 years of game development background in Flash and AIR. So my question was not exactly about it. It was simple, does unity provide some built-in way to sign serialized data or not. It's kind of YES or NO question. This security is not real of course, but anyway, a simple sign process makes it a bit harder to simply read and replace data. In this case one has to decompile the app or look for a hidden key string using some other way like HEX editor for example. And if key is composed on the fly and the app is obfuscated, sometimes it makes some "newbie hackers" stop trying :-D But anyway, I was just curious about it. And you answered my question