How to serialize data from C# in a non-human-readable way?

Question

How can I serialize a C# object (class, struct, etc) to a file without that file being easy to read?

---

Binary Formatter

First I used the Binary Formatter, which worked really well, but there were a lot of warnings about data security and many said it's a bad idea.

JSON & XML Serialization

This wouldn't work for obvious reasons, these languages are designed to be easily read and easily modified by humans, therefore it's biggest strength is also it's biggest weakness in this case.

Encrypted JSON/XML

Not sure how well this would work, and how easy it would be to tell its JSON or XML, but the main reason I couldn't use it was because I couldn't figure out an easy method or way to work it. And most posts said its extremely complicated since it's designed to be hard to decrypt.

---

For some reason there seem to be almost no posts on this topic, even though nearly every game records the players progress and needs to do this. What other methods are there? I don't need top level security here, just something gibberish enough to put off your average Joe trying to skip half the game.

Answer 1

Is this gibberish enough?

This is just the JSON generated by my answer to your previous question, which I then compressed to a zip file (reducing its size by half as a bonus), and renamed so it's not so obvious that it's just a zip.

That is, I started with this text in a file called data1.save:

{
    "list": [
        {
            "rid": 1000
        },
        {
            "rid": 1001
        },
        {
            "rid": 1002
        }
    ],
    "references": {
        "version": 2,
        "RefIds": [
            {
                "rid": 1000,
                "type": {
                    "class": "MixedSerializer/ObjectA",
                    "ns": "",
                    "asm": "Assembly-CSharp"
                },
                "data": {
                    "a": "apple"
                }
            },
            {
                "rid": 1001,
                "type": {
                    "class": "MixedSerializer/ObjectB",
                    "ns": "",
                    "asm": "Assembly-CSharp"
                },
                "data": {
                    "b": 42
                }
            },
            {
                "rid": 1002,
                "type": {
                    "class": "MixedSerializer/ObjectC",
                    "ns": "",
                    "asm": "Assembly-CSharp"
                },
                "data": {
                    "c": 3.141590118408203,
                    "toggle": false
                }
            }
        ]
    }
}

So the compression does a good job of hiding the obvious/familiar structure seen above.

Someone with good knowledge of the zip format would be able to recognize its signature by peeking at the bytes, but "your average Joe" would likely already assume this is not a human-editable file and give up.

(Fun fact, MS Office docs use this trick too: if you rename a .docx Word document or .pptx PowerPoint slideshow to .zip, you can unzip it to find human-readable files and folders inside. If you never though to do that with a document, most of your players will never think to do it with a save file either)

You can make this a little bit harder by running a different compression algorithm that's not so readily built-into every PC's OS, but the general point is: compressed data is no longer very human-readable, and will probably put off the type of user you're trying to deter.

You get diminishing returns if you try to add more obfuscation than this. Even if you put in high-security grade encryption, your game necessarily has to include the encryption key to be able to read and write the save files. So if you have a computer-savvy adversary, you've handed them both the lock and the key. With enough determination, they can always extract your game's decryption routine and use it themselves to modify the data, unless you do all your saving on a server you control, so the key never touches the player's device. Maybe do that if you have real money involved, like gambling applications. But for most games you're likely to be making, it's not worth that effort.