5 Stimmen

Wie erhalte ich die Kompatibilität der Deserialisierung zwischen Obfuscated und Debug Builds aufrecht?

Ich versuche, den {smartassembly} .NET Obfuscator mit meinem System zu verwenden. Derzeit speichere ich Benutzerdaten in einer Reihe von serialisierten Wörterbuchklassen und deserialisiere diese Klassen dann, um die Daten zurückzubekommen. Ich ignoriere bereits die Versionsinformationen der Assemblies, einfach weil das Leben auf diese Weise sehr mühsam ist. Dieser Code ist angepasst von MSDN :

//to avoid cross-versioning problems
public sealed class CrossVersionDeserializationBinder : SerializationBinder {
    public override Type BindToType(string assemblyName, string typeName) {
        Type typeToDeserialize = null;

        typeToDeserialize = Type.GetType(String.Format("{0}, {1}",
            typeName, assemblyName));

        return typeToDeserialize;
    }
}

Das Problem ist nun, dass meine verschleierte Anwendung die Versionsinformationen ignoriert, aber die von der nicht-verschleierten Anwendung gespeicherten Daten nicht lesen kann und andersherum. Wir müssen eine nicht-verschleierte Version haben, um die Anwendung zu debuggen, so dass dies ein ziemlich großer Showstopper für uns ist. Gibt es eine Möglichkeit, dieses Problem zu umgehen? Sollte ich die Datenklassen einfach nicht verschleiern? Das scheint eine ziemlich große Sicherheitslücke zu sein.

7voto

Marc Gravell Punkte 970173

Vielleicht sollten Sie einen Serialisierer in Betracht ziehen, der nicht an den Typ und die Feldnamen gebunden ist? Zum Beispiel, protobuf-net ist ein binärer Serialisierer, verwendet aber numerische Tags, die (über ein Attribut) für jedes Element gesetzt werden. Dies bedeutet:

  • die Serialisierung ist überhaupt nicht an die Assembly-Version gebunden
  • die Feldnamensinformationen sind nicht in der serialisierten Datei enthalten
  • (nach dem oben Gesagten) spielt es keine Rolle, ob der Code verschleiert ist
  • (und) die Datei kann nicht verwendet werden, um die Verschleierung auf triviale Weise zu brechen (obwohl die Daten immer noch auf eine Absicht hindeuten könnten, wenn sie nicht verschlüsselt sind)

Zum Beispiel:

[ProtoContract]
public class Foo {
    [ProtoMember(1)]
    public string Bar {get;set;}
}

Hier ist die 1 ist alles, was das Mitglied in der Datei identifiziert. Der Schlüssel hier ist, dass es vertragsbasiert ist, so kann später mit einem nicht verwandten Typ deserialisiert werden:

[ProtoContract]
public class a12 {
    [ProtoMember(1)]
    public string a {get;set;}
}

(was in Ordnung ist, da die Verschleierung die Metadaten bewahrt, IIRC).

Dies steht im Gegensatz zu anderen vertragsbasierten Serialisierern (wie XmlSerializer o DataContractSerializer ) - wo man gezwungen wäre, den Mitgliedsnamen in die Attribute aufzunehmen, was die Verschleierung so ziemlich sinnlos machen würde:

[DataContract]
public class a12 {
    [DataMember(Name="Bar")]
    public string a {get;set;}
}

-1voto

MichaelGG Punkte 9900

Eine Verschleierung bietet in erster Linie keine Sicherheit. Sie sollten also in Erwägung ziehen, sie ganz abzuschaffen.

Ich sehe zwei Möglichkeiten:

  1. Verschweigen Sie diese Typen nicht. So werden die Dinge einfach funktionieren.
  2. Schreiben Sie Ihren eigenen Serialisierungscode.

Da Sie durch Verschleierung nichts gewinnen, würde ich mich für Nr. 1 entscheiden.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X