In the Jungle of .NET Obfuscator Tools

In this article, I will share our genuine experience with various .NET Obfuscator tools. In the end, we picked .NET Reactor to obfuscate our code. The reasons: reliability, support, seniority, cost, and obfuscation options.

There are actually dozens of .NET Obfuscators as listed here, and obviously we didn’t try them all. Many of these projects are abandoned anyway. Libraries like the Mono.Cecil project make building a .NET obfuscator a popular and fun task. However, building one that properly obfuscates code without introducing bugs is challenging. .NET obfuscators that actually work are the exception rather than the norm.

I won’t go into the debate of the need for an obfuscator. To protect intellectual property, obfuscating symbols and obscuring IL code is a common approach. For more comprehensive protection, we recommend doing in-house work, as explained in Don’t rely on someone else to protect your software. Even web developers should consider obfuscation, since browsers ship important intellectual property to the client side.

A note before starting: we submitted this post to each product owner listed here prior to publication, to make sure everything here is correct.

The .NET obfuscators we tested, at a glance

Here is the short version of what we found. The detailed write-up of each tool follows below.

What to look for in a .NET obfuscator

A few criteria matter far more than feature checklists. From our own evaluation, here is what we paid attention to:

• Bug-free output on your code. Test the tool against your real binaries early. This is where most obfuscators fail, not in their marketing pages.
• Mapping files. They let you decode obfuscated production stack traces, which is essential to diagnose crashes in shipped software.
• Framework support. Make sure it targets what you ship: .NET Framework, .NET Core, and .NET 5/6/7/8 and up.
• Active maintenance and support. Recent releases and a responsive author save days of work when something breaks.
• Fair, predictable pricing. Watch renewal terms, not just the entry price.
• Protection depth. Beyond symbol renaming, look at string encryption, control flow obfuscation, code virtualization, and anti-tampering.
• Realistic expectations. Tools such as de4dot can reverse much obfuscation, so plan some in-house protection on top.

Preemptive Dotfuscator

For over a decade, we used Preemptive Dotfuscator to obfuscate our code. Microsoft initially promoted Dotfuscator as a .NET obfuscator, though it’s likely they never intended to ship one of their own. In the early days, developers transitioning from C++ and VB6 to .NET didn’t realize the new platform exposed their intellectual property. Many saw this as a downside compared to C++ and VB6.

Our code was compatible with an older version of Dotfuscator targeting .NET 4.0 and 4.5. After migrating to newer versions like .NET 4.8 and .NET Core, we needed a more recent obfuscator. Dotfuscator handles those newer versions just fine. However, the vendor keeps raising the yearly subscription price by 80% each year, with no added value and no upper limit in sight. This greatly multiplied our yearly fee after a decade of use.

Preemptive Dotfuscator remains a functional product. But the steep yearly increases for support and updates are unreasonable. Accepting these conditions now means potentially paying uncontrolled fees later, so we opted to look for alternatives. Remember that choosing this product could lead you to the same situation.

Eazfuscator.NET

Eazfuscator.NET has a good reputation, affordable pricing and lots of fans online. We tried it but figured out that the tool does not provide mapping files. Mapping files (such as the ones Dotfuscator produces) let us decode production stack traces, which is essential for tracking and fixing production problems.

Instead, Eazfuscator.NET encrypts obfuscated symbols with a private key. The holder of the private key can then decode production stack traces. At first sight, this is pretty cool. However, this approach has two significant problems.

Encrypted symbols vs mapping files

• Encrypted symbols ship publicly with the binaries. We talked with the author of Eazfuscator.NET and he is pretty certain that nobody can crack the encrypted symbols (verbatim in his own words “Given a reliable crypto, a motivated hacker would not be able to come up with anything unless he has a few million years and all computational resources of the world at his disposal. This is just how math works – nobody can overcome that no matter how skillful they are.”).Nevertheless, this approach is necessarily less secure than the mapping file approach. With mapping files, the symbols released in the wild have nothing to do with the original ones.

  Here is a quote from the page of de4dot, a tool that reverse-engineers obfuscated code: “Most of the obfuscation can be completely restored (eg. string encryption), but symbol renaming is impossible to restore since the original names aren’t (usually) part of the obfuscated assembly”. Let’s underline that de4dot doesn’t crack Eazfuscator.NET encrypted symbols, but the message is clear.

  However, this post DECRYPTING EAZFUSCATOR.NET ENCRYPTED SYMBOL NAMES shows the point well. A private password-based system to secure symbols is much less secure than a private mapping of obfuscated symbols.

Symbol size and bits inflation

• Encrypted symbol size correlates with the original symbol size. The author claimed that the size is roughly similar. We tend to use large symbols to make our code readable. The mapping file approach gave us an additional bonus: our assemblies shrunk significantly (10 to 15%) because Dotfuscator shortened symbols like “NDepend.Platform.DotNet.VisualStudio.VisualStudioEditionHelper” down to something like “B6U”.NASA sent men on the moon and back in 1969 with 4KB RAM. I used to program my first micro games on a 4KB RAM computer in the 80’s too. Today, mobile phone flashlight apps usually weigh 10 to 20MB. Call me old-fashioned, but this bits inflation makes me quite unhappy. 10 to 15% fewer bits in our redistributable matter.

The Eazfuscator.NET author underlined that “On the positive side there is no state in contrast to the stateful nature of mapping files. If you create frequent releases on a variety of build machines this may be a good point for you as it makes things easier”.

He also added that there is no immediate plan for mapping files. Unfortunately, this means Eazfuscator.NET was not the right choice for us.

Babel

Babel has a good reputation and affordable pricing, and it includes a mapping file feature. However, despite multiple attempts and discussions with the author, we never got it to work on our assemblies. It may work for other applications, but it didn’t for us.

Obfuscar

It was interesting to try an open-source obfuscator. Obfuscar was the first choice. The project has recent enough commits, and its nuget package has racked up more than 760K downloads!

Unfortunately, we couldn’t generate bug-free code despite trying hard. Known flaws got in the way, such as TypeLoadExceptions and the inability to obfuscate all enum values. I had the chance to discuss this with Lex Li, one of the main contributors on Obfuscar over the years. His stance is:

“Obfuscar does have a few design flaws which I was trying to fix but unable to fully address. However, I noticed a fork https://github.com/3shape/obfuscar which is built upon my unsuccessful attempt (dating back a few years ago) and seems to be promising. I don’t have time to evaluate their work though.”

Confuser

We didn’t bother trying the open-source obfuscator ConfuserEx. The project hasn’t been touched for years, and it is officially discontinued and unmaintained. Someone forked it to neo-ConfuserEx, which also hasn’t seen activity in years.

.NET Reactor

After all these attempts (and time lost), we tried .NET Reactor. It supports mapping files, comes with affordable pricing, and the team has maintained it since 2004 with regular new releases.

A solid UI and good documentation are essential for complex tools like obfuscators. What I appreciate about .NET Reactor is the UI, full of tooltips and links to extensive documentation. Feature descriptions sit right in the UI, so users don’t have to jump back and forth between the documentation and support. For instance, selecting “Public Types Internalization” prompts the description “If enabled, .NET Reactor will convert all public types of an application into internal ones. This way the accessibility of types and members is reduced”, making it easy to understand.

We follow the same approach with the NDepend online and embedded documentation. Personally, I hate getting stuck on a setting or behavior that nobody documented. I consider that ISVs are not here to sell support, but to build solutions that seamlessly solve problems and bring value. Read more on this digression in You Should Favor Software Products That Include Support in the Price.

Initially, .NET Reactor did not work for us. We hit resource unavailability and a few unobfuscated override method names. However, after several rounds of communication with the author, we generated a bug-free obfuscated version of our code. Their support proved prompt and efficient. We now have a reliable obfuscation process with excellent support, and all that for less than 5% of what we used to pay with Dotfuscator.

Other tools we did not test

A few other commercial obfuscators come up often in discussions: Red Gate’s SmartAssembly and ArmDot, the latter being cross-platform and configured through NuGet and MSBuild. We did not evaluate them ourselves, so we can’t vouch for them, but they are worth a look if the tools above don’t fit your case. The full .NET obfuscators list covers dozens more.

Conclusion

This post does not cover one important aspect of obfuscators: the various extra protection features like virtualization, string encryption, anti-tampering, etc. Again, we recommend adding some in-house custom protection on top of any commercial tool. Keep in mind that projects exist like the aforementioned de4dot tool, which reverse-engineers code from popular obfuscators.

Everything in this post is genuine. To find the best .NET Obfuscator tool for your needs, focus on actively maintained projects with recent updates and commits. After researching and evaluating various options, we recommend giving .NET Reactor a try, based on our positive experience with the tool.

.NET obfuscator FAQ

What is a .NET obfuscator?

A .NET obfuscator rewrites a compiled assembly so its IL and symbols are hard to read after decompilation, while keeping the program’s behavior identical. Typical techniques are symbol renaming, string encryption, control flow obfuscation, and code virtualization.

Can obfuscated .NET code be reverse-engineered?

Partly. As the de4dot project shows, many transformations such as string encryption can be restored automatically. Symbol renaming is the exception, since the original names are usually gone for good. Treat obfuscation as a strong deterrent, not as absolute protection.

What is the best .NET obfuscator?

There is no single best tool; it depends on your code, target frameworks, and budget. After testing several, we chose .NET Reactor for its reliability, mapping files, low cost, and responsive support. Dotfuscator and Eazfuscator.NET are also mature options.

Is there a free .NET obfuscator?

Yes. Obfuscar (MIT license) is the most active open-source option, and ConfuserEx still exists but is discontinued. Free tools can be fine for simple assemblies, but they often struggle with complex code, as we found.

Do .NET obfuscators support .NET 6, .NET 8 and .NET Core?

The maintained commercial tools (.NET Reactor, Dotfuscator, Eazfuscator.NET) support modern .NET. Abandoned projects like ConfuserEx target old .NET Framework versions only.

What is a mapping file and why does it matter?

A mapping file records how each original symbol was renamed. It lets you turn an obfuscated production stack trace back into readable names, which is essential to diagnose crashes in shipped software.

Does obfuscation hurt performance?

Light techniques like renaming have no measurable cost. Heavier ones like code virtualization slow down the protected methods, often by 10 to 20%, so apply them only where they matter.