Cryptage vs obfuscation de .NET Reactor

Question

J'ai besoin de protéger nos assemblages contre l'ingénierie inverse, afin de réduire le risque de vol de propriété intellectuelle ou de piratage de licence. .NET Reactor semble puissant et nous avons déjà une licence pour lui.

En lisant la documentation, il semble qu'il existe plusieurs mécanismes pour empêcher la décompilation autres que l'obfuscation. J'ai lu que l'obfuscation peut perturber la sérialisation, qui est une partie importante de notre système, et j'espère l'éviter complètement.

Je suis principalement intéressé par NecroBit, qui prétend crypter le CIL, ce qui le rend "impossible à décompiler/ingénierie inverse". Il me semble que si cela est vrai, l'obfuscation ou tout autre paramètre serait inutile.

Un utilisateur expérimenté de .NET Reactor peut-il donner une explication plus pratique des différentes options et/ou suggérer une bonne permutation pour un système sérialisé ? Quels sont les bons outils pour tester les affirmations de ce logiciel ?

Answer 1

J'espère que cela aidera d'autres personnes utilisant .NET Reactor ou des outils similaires. Je suis conscient des limites de tout outil. L'objectif était de réduire autant que possible le risque de piratage des licences avec un minimum d'efforts. Mon entreprise a déjà été échaudée et le patron le voulait.

Notre projet en particulier est un bureau WPF utilisant Prism. Lorsque j'ai essayé de fusionner mes assemblages en un seul gros exe, j'ai constaté que certains enregistrements d'interface n'étaient pas résolus dans le conteneur Unity. Nous avons décidé qu'il était préférable de protéger chaque dll individuellement plutôt que de se battre avec cela. Une fois que je l'ai fait, cet outil a bien fonctionné. J'ai littéralement coché toutes les options de protection pour le bureau.

Nos services exécutent des hubs SignalR dans un processus OWIN auto-hébergé. Dans ce cas, l'option Native EXE File ne fonctionne pas. Nous avons obtenu des exceptions de mauvais format d'image lorsque nous avons exécuté les services. Sinon, toutes les options sont cochées.

Au-delà de cela, j'ai rencontré quelques problèmes ponctuels où nous utilisions la réflexion sous la forme de Type.GetMethod(string). J'ai dû exclure quelques méthodes et classes avec un ObfuscationAttribute.

Je m'attendais à des problèmes avec la sérialisation JSON mais je n'en ai pas eu. Tout a fonctionné :)

Answer 2

J'utilise Netreactor depuis de nombreuses années. J'utilise l'interface d'isérialisation avec un liant de sérialisation pour contourner l'obscurcissement, etc. Cela fonctionne à travers toutes les méthodes de protection de Netreactor.

        Stream s = null;

        BinaryFormatter b = new BinaryFormatter();
        Binder CB = new Binder();
        b.Binder = CB;

        try
        {
            s = File.Open(fileName, FileMode.OpenOrCreate);
            //to serialize
            b.Serialize(s, yourObject);
            // to deserialize
            yourObject = (YourClass)b.Deserialize(s);
        }
        catch
        {

        }

        finally
        {
            s.Close();
        }

    [Serializable]
    public class YourClass : System.Runtime.Serialization.ISerializable
    {
       //Explicit serialization function
       public void GetObjectData(SerializationInfo info, StreamingContext ctxt)
       {

          info.AddValue("stringVar", stringVar); 
          // and so forth...
       }

       // Deserialization
       public YourClass(SerializationInfo info, StreamingContext ctxt)
       {
          stringvar = (string)info.GetValue("stringVar", typeof(string));
          // and so forth
       }
    }
    // the serialization binder
    public class Binder : SerializationBinder
    {

       public override Type BindToType(string assemblyName, string typeName)
       {
            return System.Type.GetType(typeName); // Get it from this 
            //assembly

       }
   }