将对象序列化为文件时的C＃最佳实践

Question

I'm building a small app that needs to save an object to a file in order to save user data. I have two questions about my serialization to this file :

1. The object I'm creating has some public properties and an event. I added the [Serializable] attribute to my object, and then realized I can't serialize an object with an event in it. I then discovered that I can just add an attribute above my event [field:NonSerialized] and it will work. Is this the best way to do this, or should I try to build my Serializable objects without any events inside ?

2. The object I'm serializing saves some user settings about the app. These settings aren't sensitive enough to go about encrypting them in the file, but i still don't want them to be tampered with manually without opening my application. When i serialize my object to a file using a plain BinaryFormatter object, via the Serialize() method, I see readable names of .net object types in the file i'm saving this to. Is there a way for someone to reverse engineer this and see what's being saved without using my program ? Is there a way for someone to build a small application and find out how to DeSerialize the information in this file ? If so, how would i go about hiding the information in this file ?

Are there any other tips/suggestions/best practices i should stick to when going about serializing an object to a file in this kind of scenario ?

Thanks in advance!

Answer 1

If your object implements the ISerializable interface, you can control all the data that is stored/serialized yourself, and you can control the deserialization.

This is important if your project evolves in time. Because you might drop some properties, add others, or change the behaviour.

I always add a version to the serialization bag. That way I know what was the version of the object when it was stored, and I therefor know how to deserialize it.

[Serializable]
class Example : ISerializable {
   private static const int VERSION = 3;

   public Example(SerializationInfo info, StreamingContext context) {
      var version = info.GetInt32("Example_Version", VERSION);
      if (version == 0) {
         // Restore properties for version 0
      }
      if (version == 1) {
         // ....
      }
   }

   void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context) {
       info.AddValue("Example_Version", VERSION);
       // Your data here
   }

}

And if you do not encrypt, it will be very easy to "read" your data. Very easy meaning you might have to invest a couple of hours. If the data you store is worth a couple of days, this means it is easy, if it is only worth a couple of minutes it is hard. If you get the point.

A very easy way to encrypt your data is using the Windows DPAPI through the ProtectedData class.

Answer 2

1: with BinaryFormatter, yes - you need NonSerialized for events (unless you implement ISerializable, but that adds lots of work); however I'm pretty much on-record as saying that I simply wouldn't use BinaryFormatter here. It is not very forgivig for a range of changes to your type. I would use something less tied to the internals of your code; XmlSerializer; DataContractSerializer, JavaScriptSerializer. I can suggest binary alternatives too; NetDataContractSerializer, protobuf-net (my own), etc.

2: yes, with almost any implementation that doesnt involve proper encryption, if anyone cares they can reverse engineer and obtain the strings. So it depends how hidden it needs to be. Simply running your existing serialization through GZipStream may be enough obfuscation for your needs, BUT this is just a mask against casual inspection. It will not deter anyone with a reason to look for the data.

If the data needs to be secure, you'll need proper encryption using either a key the user enters at app startup, or something like a certificate securely stores against their user-profile.

Answer 3

1. I would remove the events from the objects. It's a little cleaner that way.

2. Anything can be reverse engineered. Just encrypt it when saving the file. It's pretty easy to do. Of course, the encryption key is going to have to be stored in the app somewhere, so unless you're obfuscating your code a determined hacker will be able to get to it.