BINARYFORMATTER IN UNITY FOR MAC CODE

They just obfuscate the data and any person that knows something about security knows security through obscurity is no security at all. We have too many smart evil people and if there's a potential for abuse, it will be abused sooner or later.Įncryption of save files does not help with such security risks at all and does not really matter here. Nowadays even the smallest oversight is misused for attacks. The underlying dataformat is just the 'remoting protocol' which was designed for remote procedure calls across trusted systems at a time where security wasn't really a major concern. Though pretty much any other serializer does not have the same issues at the BinaryFormatter. Of course if you have a json serializer that does serialize object types and can deserialize them based on the serialized data, it could also be an issue, though here it depends how type loading is implemented by the serializer and what constraints can be set up. Standard json is a pure dataformat and does not have any such functionalities. That's something you can not prevent and that's the security risk. The issue here is that the BinaryFormatter is able to create any type of object and run any method on it.

BINARYFORMATTER IN UNITY FOR MAC CODE

The BinaryFormatter allows an attacker to run any arbitrary code from any other assembly. Some sort for version info should also be included when you use a json based format because maybe in the future you will have breaking changes to the format and you have to be able to distinguish old from new files. Though when you roll your own format, you should always start with a version ID and always check the version when deserializing. The resulting save file would also be much smaller than what the BinaryFormatter produces.NET comes with two classes: BinaryReader and BinaryWriter which lets you directly serialize primitive values into a data stream. Just rolling your own binary format is just a little bit more code you have to write, but on the flipside you don't really need to create seperate classes which are serialized since you can decide yourself on the fly what to serialize and how. Security through obscurity is not security at all ^^. Once it's known what you did and how, the data is not secure anymore (which means it never was in the first place). Even if you outsource the encryption to a native code library, a cheater can simply use your library or do a more in depth analysis of the assembly. IL2CPP will make it harder to simply decompile / view your code, however I've seen decompilers out there which get close to normal. Though in the end no amount of encryption done on the client side will be enough to make a save file 'secure' since the client itself has to be able to read it, so all encryption keys you may have used has to be available to the client. Yes, you can simply use a human readable format like json and just add some scrambling to it to make it harder to read. If you want to make it harder for users to manipulate the save data there are many different approaches out there. Once you have that you could essentially create an editor for any kind of save file out there that is based on the BinaryFormatter. I've actually written a parser for the remoting protocol (which is used by the BinaryFormatter) myself from scratch just using the documentation. Since the format used by the BinaryFormatter is well documented and described, it's easy to read - modify - write any data you stored there. Admittedly the scenarios where this could actually be an issue are quite rare, but nevertheless it's an unnecessary risk.Īpart from that storing data on the users side will never be secure. So using the BinaryFormatter can actually be a security risk for the user of your game. Note that security is not always about keeping your game data hidden but security in a way broader field. Yes, you should stop using the BinaryFormatter for deserializing external data.

Binaryformatter in unity for mac