Free Obfuscation Tools For .net

[Ozella Vires]

ForIntellectual 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.

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.

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.

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.

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'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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. -hack-a-NET-executable.aspx

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.

Version 9.8 protects .NET 6 assemblies..NET 6 is the next major release of .NET. .NET 6 is the main implementation of .NET going forward and .NET Framework 4.x is still supported. .NET 5 assemblies are also need to be protected to hide source code from spying eyes.Skater .NET Obfuscator is the the forceful engine to protect your .NET 5 projects.

Version 9.0 protects .NET Core 3.x (3.0 and later) assemblies.Starting from version 3.0 the .NET Core SDK includes support for Windows Forms desktop applications.Skater .NET Obfuscator is the powerful tool to protect .NET Core 3.0 projects.

3a8082e126