views:

166

answers:

3

We are about to use Code Protectors (Obsfucation as well as Native Compilation), I assume ORMs will be dependent little bit on Reflection and I am worried will Obsfucation and Native Compilation protection techniques create any problems?

Has anyone tried successful ORM and Code Protection for any good desktop application? We are having WPF Desktop Application.

Our primary language for development is C# and we are using our custom ORM but I want to evaluate any commercial ORM or ADO.NET EF etc as well.

Question is not about what is Code Protection and which one I should use, I am trying to ask about the effect of protection on ORM.

A: 

Try .Net Reactor. Available at http://www.eziriz.com/

Its a LOT cheaper than some of the others around, and it can do a lot more. You can also disable certain options (like obfuscation, to preserve the use of reflection) and only have certain options enabled like ILDASM Suppression, which will still protect the code.

Cheers

Please read the question, I dont want to know which Protector to try, do you have any experience on the effect of this protector on ORM ? like Entity Framework , BL Toolkit etc?
Akash Kava
A: 

Redgate acquired Smart Assembly not too long ago, which is what I'd look at if I had a need to do this.

A while ago I trialed CodeViel to look at obfuscating/encrypting code with some degree of success. I think if you’re serious about doing this it’s not as simple as dropping an assembly in one end and it popping out a protected assembly. You will have to consider portions of your code (ie Namespaces, Classes, Methods, Fields, Properties, Structures, Events, and Resources) which are only to be used internally, and those that need to be exposed to other resources and libraries. In the case I was looking at I was able to encrypt (or use native compilation) to hide some method implementations, but left the class definition (name, methods, properties untouched). In some cases I left whole namespaces untouched as they contained only simple POCO objects required by other libraries.

It really seems to be a careful case by case basis as to what strategy you use where, some internals you could obfuscate to make decompilation/reverse engineering hard and that would be enough. Other cases you could use the encryption/native compilation to simply hide a method implementation. And you will also get cases where you are excluding portions of an assembly from being touched at all. Most of these programs will give you some recommended defaults and options that you can start from, but you will need to tweak and change these until you can produce results that protect your core IP but don't restrict your end users.

Brendan Kowitz
A: 

If your code is using Reflection, most probably the obfuscated assembly will not work. You will need to exclude from obfuscation those entities referenced by their original name. Take a look at Crypto Obfuscator which will analyze your code during obfuscation and show all methods and line numbers where potentially breaking methods (such as Reflection ) are called. This is a huge timer-saver since it pinpoints the exact location and helps determine the properties/classes you need to exclude from renaming.

logicnp
Thank you, this was the answer I have been looking for long, does this also mean that WPF etc may not work correctly where they do binding based on reflection?
Akash Kava