.NET obfuscation tools/strategy [closed]

问题:

My product has several components: ASP.NET, Windows Forms App and Windows Service. 95% or so of the code is written in VB.NET.

For Intellectual Property reasons, I need to obfuscate the code, and until now I have been using a version of dotfuscator which is now over 5 years old. I\'m thinking it is time to move to a new generation tool. What I\'m looking for is a list of requirements which I should consider when searching for a new obfuscator.

What I know I should look for so far:

• Serialization/De-serialization. In my current solution, I simply tell the tool not to obfuscate any class data members because the pain of not being able to load data which was previously serialized is simply too big.
• Integration with Build Process
• Working with ASP.NET. In the past, I have found this problematic due to changing .dll names (you often have one per page) - which not all tools handle well.

回答1:

Back with .Net 1.1 obfuscation was essential: decompiling code was easy, and you could go from assembly, to IL, to C# code and have it compiled again with very little effort.

Now with .Net 3.5 I\'m not at all sure. Try decompiling a 3.5 assembly; what you get is a long long way from compiling.

Add the optimisations from 3.5 (far better than 1.1) and the way anonymous types, delegates and so on are handled by reflection (they are a nightmare to recompile). Add lambda expressions, compiler \'magic\' like Linq-syntax and var, and C#2 functions like yield (which results in new classes with unreadable names). Your decompiled code ends up a long long way from compilable.

A professional team with lots of time could still reverse engineer it back again, but then the same is true of any obfuscated code. What code they got out of that would be unmaintainable and highly likely to be very buggy.

I would recommend key-signing your assemblies (meaning if hackers can recompile one they have to recompile all) but I don\'t think obfuscation\'s worth it.

回答2:

We\'ve tried a number of obfuscators. None of them work on a large client/server app that uses remoting. Problem is that client and server share some dlls, and we haven\'t found any obfuscator that can handle it.

We\'ve tried DotFuscator Pro, SmartAssembly, XenoCode, Salamander, and several small time apps whose names escape me.

Frankly, I\'m convinced obfuscation is a big hack.

Even the problems it addresses is not entirely a real problem. The only thing you really need to protect is connection strings, activation codes, security-sensitive things like that. This nonsense that another company is going to reverse-engineer your whole codebase and create a competing product from it is something from a paranoid manager\'s nightmare, not reality.

回答3:

I am \'Knee Deep\' in this now, trying to find a good solution. Here are my impressions so far.

Xenocode - I have an old licence for Xenocode2005 which I used to use for obfuscating my .net 2.0 assemblies. It worked fine on XP and was a decent solution. My current project is .net 3.5 and I am on Vista, support told me to give it a go but the 2005 version does not even work on Vista (crashes) so I and now I have to buy \'PostBuild2008\' at a gobsmacking price point of $1900. This might be a good tool but I\'m not going to find out. Too expensive.

Reactor.Net - This is a much more attractive price point and it worked fine on my Standalone Executeable. The Licencing module was also nice and would have saved me a bunch of effort. Unfortunately, It is missing a key feature and that is the ability to Exclude stuff from the obfuscation. This makes it impossible to achieve the result I needed (Merge multiple assemblies together, obfuscate some, not-Obfuscate others).

SmartAssembly - I downloaded the Eval for this and it worked flawlessly. I was able to achieve everything I wanted and the Interface was first class. Price point is still a bit hefty.

Dotfuscator Pro - Couldn\'t find price on website. Currently in discussions to get a quotation. Sounds ominous.

Confuser - an open source project which works quite well (to confuse ppl, just as the name implies). https://confuser.codeplex.com/
(added by jgauffin)

Note: ConfuserEx is reportedly \"broken\" according to Issue #498 on their GitHub repo.

回答4:

If your looking for a free one you could try DotObfuscator Community Edition that comes with Visual Studio or Eazfuscator.NET.

---

Since June 29, 2012, Eazfuscator.NET is now commercial. The last free available version is 3.3.

回答5:

I have been using smartassembly. Basically, you pick a dll and it returns it obfuscated. It seems to work fine and I\'ve had no problems so far. Very, very easy to use.

回答6:

I have tried almost every obfuscator on the market and SmartAssembly is the best in my opinion.

回答7:

I\'ve been also using SmartAssembly. I found that Ezrinz .Net Reactor much better for me on .net applications. It obfuscates, support Mono, merges assemblies and it also also has a very nice licensing module to create trial version or link the licence to a particular machine (very easy to implement). Price is also very competitive and when I needed support they where fast. Eziriz

Just to be clear I\'m just a custumer who likes the product and not in any way related with the company.

回答8:

The short answer is that you can\'t.

There are various tools around that will make it harder for someone to read your code - some of which have been pointed out by other answers.

However, all these do is make it harder to read - they increase the amount of effort required, that is all. Often this is enough to deter casual readers, but someone who is determined to dig into your code will always be able to do so.

回答9:

We have a multi tier app with an asp.net and winform interface that also supports remoting. I\'ve had no problems with using any obfuscator with the exception of the encrypting type which generates a loader which can be problematic in all sorts of unexpected ways and just not worth it in my opinion. Actually my advice would be more along the lines of \"Avoid encrypting loader type obfuscators like the plague\". :)

In my experience any obfuscator will work fine with any aspect of .net including asp.net and remoting, you just have to become intimate with the settings and learn how far you can push it in which areas of your code. And take the time to attempt reverse engineering on what you get and see how it works with the various settings.

We used several over the years in our commercial apps and settled on Spices obfuscator from 9rays.net because the price is right, it does the job and they have good support though we really haven\'t needed the support in years anymore but to be honest I don\'t think it really matters which obfuscator you use, the issues and learning curve are all the same if you want to have it work properly with remoting and asp.net.

As others have mentioned all you\'re really doing is the equivalent of a padlock, keeping otherwise honest people out and or making it harder to simply recompile an app.

Licensing is usually the key area for most people and you should definitely be using some kind of digitally signed certificate system for licensing anyway. Your biggest loss will come from casual sharing of licenses if you don\'t have a smart system in place, the people that break the licensing system were never going to buy in the first place.

It\'s really easy to take this too far and have a negative impact on your customers and your business, do what is simple and reasonable and then don\'t worry about it.

回答10:

For the past two days I\'ve been experimenting with Dotfuscator Community Edition advanced (a free download after registering the basic CE that comes bundled with Visual Studio).

I think the reason more people don\'t use obfuscation as a default option is that it\'s a serious hassle compared to the risk. On smaller test projects I could get the obfuscated code running with a lot of effort. Deploying a simple project via ClickOnce was troublesome, but achievable after manually signing the manifests with mage. The only problem was that on error the stack trace came back obfuscated and the CE doesn\'t have a deobfuscator or clarifier packaged.

I tried to obfuscate a real project which is VSTO based in Excel, with Virtual Earth integration, lots of webservice calls and an IOC container and lot\'s of reflection. It was impossible.

If obfuscation is really a critical requirement, you should design your application with that in mind from the start, testing the obfuscated builds as you progress. Otherwise, if it\'s a fairly complex project, you\'re going to end up with a serious amount of pain.

回答11:

Crypto Obfuscator address all your concerns and scenarios. It :

1. Automatically excludes types/members from obfuscation based on rules. Serialized types/fields are one of them.
2. It can be integrated into the build process using MSBUild.
3. Supports ASP.Net projects.

回答12:

I\'ve recently tried piping the output of one free obfuscator into the another free obfuscator - namely Dotfuscator CE and the new Babel obfuscator on CodePlex. More details on my blog.

As for serialization, I\'ve moved that code into a different DLL and included that in the project. I reasoned that there weren\'t any secrets in there that aren\'t in the XML anyway, so it didn\'t need obfuscation. If there is any serious code in those classes, using partial classes in the main assembly should cover it.

回答13:

You should use whatever is cheapest and best known for your platform and call it a day. Obfuscation of high-level languages is a hard problem, because VM opcode streams don\'t suffer from the two biggest problems native opcode streams do: function/method identification and register aliasing.

What you should know about bytecode reversing is that it is already standard practice for security testers to review straight X86 code and find vulnerabilities in it. In raw X86, you cannot necessarily even find valid functions, let alone track a local variable throughout a function call. In almost no circumstances do native code reversers have access to function and variable names --- unless they\'re reviewing Microsoft code, for which MSFT helpfully provides that information to the public.

\"Dotfuscation\" works principally by scrambling function and variable names. It\'s probably better to do this than publish code with debug-level information, where the Reflector is literally giving up your source code. But anything you do beyond this is likely to get into diminishing returns.

回答14:

I have had no problems with Smartassembly.

回答15:

You could use \"Dotfuscator Community Edition\" - it comes by default in Visual Studio 2008 Professional. You can read about it at:

http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html

The \"Professional\" version of the product costs money but is better.

Do you really need your code obfuscated? Usually there is very little wrong with your application being decompiled, unless it is used for security purposes. If you are worried about people \"stealing\" your code, don\'t be; the vast majority of people looking at your code will be for learning purposes. Anyway, there is no totally effective obfuscation strategy for .NET - someone with enough skill will always be able to decompile/change you application.

回答16:

Avoid Reactor. It is completely useless (and yes I paid for a license). Xenocode was the best one I encountered and bought a license for too. The support was very good but I didn\'t need it much as it just worked. I tested every obfuscator I could find and my conclusion is that xenocode was far and away the most robust and did the best job (also possibility to post process your .NET exe to a native exe which I didn\'t see anywhere else.).

There are two main differences between reactor and xenocode. The first one is that Xenocode actually works. The second is that the execution speed of your assemblies is no different. With reactor it was about 6 million times slower. I also got the impression that reactor was a one man operation.

回答17:

I found the Agile.Net provide pretty good protection for your .Net Assembly because it offer not only obfuscation but also encryption. Download a free trail.
http://secureteam.net/NET-Code-Protection.aspx http://secureteam.net/downloads.aspx

回答18:

I\'ve been obfuscating code in the same application since .Net 1, and it\'s been a major headache from a maintenance perspective. As you\'ve mentioned, the serialization problem can be avoided, but it\'s really easy to make a mistake and obfuscate something you didn\'t want obfuscated. It\'s easy to break the build, or to change the obfuscation pattern and not be able to open old files. Plus it can be difficult to find out what went wrong and where.

Our choice was Xenocode, and were I to make the choice again today I would prefer to not obfuscate the code, or use Dotfuscator.

回答19:

Here\'s a document from Microsoft themselves. Hope that helps..., it\'s from 2003, but it might still be relevant.

回答20:

We\'re using SmartAssembly on our windows client. Works just fine.

Does add some extra problems too. Printing out your class names in log files/exceptions have to be de-obfuscated. And of course can\'t create a class from its name. So it\'s a good idea to take a look at your client and see which problems you can get by obfuscating.

回答21:

It all depends on the programming language, which you use. Read the article: Obfuscated code

回答22:

the free way would be to use dotfuscator from within visual studio, otherwise youd have to go out and buy an obfuscator like Postbuild (http://www.xenocode.com/Landing/Obfuscation.aspx)

回答23:

I had to use a obfuscation/resource protection in my latest rpoject and found Crypto Obfuscator as a nice and simple to use tool. The serialization issue is only a matter of settings in this tool.

回答24:

There\'s a good open source version called Obfuscar. Seems to work fine. Types, properties, fields, methods can be excluded. The original is here: https://code.google.com/p/obfuscar/, but since it seems to not be updated anymore, somebody forked it to here: https://obfuscar.codeplex.com/

回答25:

You may also want to look at new code protection technologies such as Metaforic and V.i.Labs and new software copy protection technologies such as ByteShield. Disclosure: I work for ByteShield.

回答26:

I also use smartassembly. However, I don\'t know how it works for a web application. However, I\'d like to point out that if your app uses shareware type protection, make sure it don\'t check a license with a boolean return. it\'s too easy to byte crack. http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx

回答27:

SmartAssembly is great,I was used in most of my projects

回答28:

I tried Eziriz demo version....I liked it. But never brought the software.

回答29:

Obfuscating is not a real protection.

If you have a .NET Exe file there is a FAR better solution.

I use Themida and can tell that it works very well.

The only drawback of Themida is that it cannot protect .NET Dlls. (It also protects C++ code in Exe and DLLs)

Themida is by far cheaper than the here mentioned obfuscators and is the best in anti piracy protection on the market. It creates a virtual machine were critical parts of your code are run and runs several threads that detect manipulation or breakpoints set by a cracker. It converts the .NET Exe into something that Reflector does not even recognize as a .NET assembly anymore.

Please read the detailed description on their website: http://www.oreans.com/themida_features.php

回答30:

I have tried a product called Rummage and it does a good job in giving you some control ... Although it lacks many things that Eziriz offers but price for Rummage is too good...