There are many tools to obfuscate .NET applications.

The free ones do some basic obfuscation while commercial ones seem to promise more.

My question is: Is it worth to use the commercial obfuscation tools? Do they provide some security? I know everything is crackable if someone wants it badly. But I am talking about some "average" attackers. So is it worth to invest money in commercial obfuscators?

If someone is interested what I want to protect: program logic and/or keys (I know keys should not be stored in app but I am limited in where I can store it anyway due to context)

Note: Some users are mentioning that sometimes obfuscator may introduce bugs in working program. This is clearly bad. If someone can cover his/her experience about this kind of behaviour would also be useful. Is this behaviour different w.r.t to commercial vs free obfuscators?

  • 2
    Obfuscation just makes it harder for attackers but is is still possible to crack it in some way. It just takes longer for them to read it.
    – user6090
    Commented Dec 2, 2015 at 11:41
  • 12
    Security by obscurity is wrong strategy and only creates illusion of safety. Commented Dec 2, 2015 at 15:20
  • The main problem is that we can't accurately measure obfuscation and therefore cannot prove that it is secure. As the chap above me just mentioned, it creates an illusion of security but actually this is not entirely true as one could argue that encryption is obfuscation.
    – Arlix
    Commented Dec 2, 2015 at 16:00
  • I think it depends a bit - obscurity is an illusion of safety, but in a scenario where you have active countermeasures (IDS/Auditing) there's no point in making it easy for them to find what they're looking for. This doesn't really apply to binaries though.
    – Sobrique
    Commented Dec 2, 2015 at 16:22
  • 4
    Obfuscation is the equivalent of not leaving valuables on show in your car, it may not be a complete security measure but it is still worth doing to block casual access. Security through obscurity arguments on this actually make little sense because you can't secure code and allow people to run it unless you own the whole system. It's the same problem as DVD/Bluray encryption, it is logically fundamentally impossible.
    – JamesRyan
    Commented Dec 2, 2015 at 17:29

10 Answers 10


The problem with client sided Obfuscation/Protection is that the attacker will always win. Your code runs on his PC so he can intercept and manipulate everything in the end. In the specific case of .NET it might make sense to apply basic obfuscation to remove function names for example but free tools are perfectly fine for that.

To answer your question a bit more specific: Most commercial obfuscators do the same things that free ones do as well. I'd go for Confuser/ConfuserEx, both are open source and provide better protection than most commercial stuff.

  • 1
    Exactly, it's also worth noting that there's deobfuscators for many of the obfuscators which are out there which make deobfuscating easier(tm) for some than for others. There's no point paying for one when Confuser offers the same benefits for free. Commented Dec 2, 2015 at 9:57
  • 22
    "the attacker will always win" - if the attacker has unlimited time and money, then yes. Otherwise, it comes down to the question whether whatever the attacker might gain is worth more than the required effort or not.
    – vsz
    Commented Dec 2, 2015 at 12:24
  • 3
    As a developer, I can tell you obfuscation is useless. In order to run the code (specially for things like .NET where I am really executing CLR code) things have to be "deobfuscated" in order for the run time to run it. So all your really doing is is changing nice variables like posts = posts + 1 to something like x=x+1 in the end. If your already used to looking at the decompiled byte-code funny variable and function names is not going to slow you down. Continued ....
    – coteyr
    Commented Dec 2, 2015 at 13:56
  • 3
    I always view it like this g02.a.alicdn.com/kf/HTB1zjI6JpXXXXbQXXXXq6xXFXXXs/… In the outside of the shed. If it's cheap and makes someone feel better, then go for it. If you think it's actually providing any real security, then .... So go for it at $0 and easy for the devs to include in the build process. Any more difficult then that and it's not worth it.
    – coteyr
    Commented Dec 2, 2015 at 13:57
  • 1
    @vsz money may not be important. When someone have fun doing reverse engeneering he does that in his spare time and saves the money that a game would cost, reversing is his game.
    – YoMismo
    Commented Dec 2, 2015 at 14:13

Is obfuscation worth it? Yes, of course it is worth it. Any extra layer which does not interfere with another layer is always worth it. It will deter the average person and keep the majority of people, or would be script kiddies, at bay....


Commercial tools I would say are not, as anything to advanced could actually hinder your development, using some bespoke software I have tried ended up taking alot of time to ensure the code worked correctly while in this new form as it was essentially base64 encoded and encrypted.

remember this when coming to security: if your software or product is worth 1million make it cost 1million and 1 to crack it, you can never make something safe enough. obfuscating will never make it safe, but it does not hurt to use free tools.

Obfuscation is obviously not high level security but I would never put out code without obfuscation as it can hide important information (important information that this can protect is obvious naming conventions giving away purposes of functions and how your application works, this is just a simple deterrent not a solution). It is always worth it.

Though paying for a tool? Maybe not worth it.

  • 13
    What? This is wrong. Have you ever tried decompiling obfuscated code? Obfuscation doesn't really help at all against a moderately-skilled attacker who will find a vulnerability in your program. You should never put any important information inside an executable. At all. And if you have an SQL injection vulnerability, you will be roflstomped so hard regardless of obfuscation. NEVER rely on obfuscation to protect your important information. Commented Dec 2, 2015 at 12:54
  • 7
    Im sorry @MarkHulkalo but you clearly misunderstood so before you make comments I would appreciate you double read? or ask before declaring me wrong? I clearly said its not some kind of high level security, clearly, though firstly if it was pointless this question would not even exist nor would companies be making 1000s redoing this. The point is it adds a small layer of annoyance. have you ever deobfucated code? most tools change the class, function and variable names as well as encode it to make it more of a challenge to get the point of the code. I have multiple of times.
    – TheHidden
    Commented Dec 2, 2015 at 13:25
  • 4
    it is NOT about protect its about making it cost more time and keeping the BASIC user or crap script kiddies (who count as pretty much a basic user half the time) AWAY! I can put a do not enter sign on a door, but its the lock that stops you going in... but most of the public wont even try the door. obfucation is the sign on the door. there is no reason not to have it. which is my over all point, I even pointed out its not worth the money paying for a tool. if it was worth money it would be worth security. Though making me explain more I have marked your comment as useful to me. thank you
    – TheHidden
    Commented Dec 2, 2015 at 13:28
  • 1
    @silverpenguin your answer is somewhat misleading. First of all, the question focused on whether the commercial obfuscation tools offered significant advantage compared to the free tools, and your Yes, of course is not backed up by the rest of your answer. More importantly, I would never put out code without obfuscation as it can hide important information — it doesn't work like that, you cannot rely on the obfuscation hiding important information. So while it costs almost nothing to have it and probably provides some help, do not make it sound like it really protects any information.
    – Cthulhu
    Commented Dec 2, 2015 at 15:17
  • 1
    The first two sentences are wrong. Just "not interfering" does not automatically make it worth it. To be worth it, the benefits must be greater than the cost (and there is always cost, even with a free tool) to produce some acceptable amount of value within a specified acceptable level of confidence. Otherwise the risk alone makes it demonstrably not worth it.
    – Xander
    Commented Dec 2, 2015 at 15:44

No. Obfuscation is not worth it. If you obfuscate your programs they will be picked up as false positives by virus scanners all the time. This will cause you far more headaches than a few lost sales.

The only exception would be if you had an extraordinarily valuable piece of software - but if you aren't shipping a hardware dongle, your software is not so valuable as to need obfuscation.

  • 2
    "If you obfuscate your programs they will be picked up as false positives by virus scanners all the time" - This sentence is entirely untrue IMO. Do you have any reference to base your wild accusations on?
    – Matt Wilko
    Commented Dec 2, 2015 at 16:39
  • 1
    @MattWilko, This is based on my own experience of this happening. And rightly so, IMO. I wouldn't let a plumber or electrician sneak around my house hiding what he was doing. Computer code which hides its actions is suspicious in the same way - it has access to my stuff so it should be open about what it is doing. If you want to keep your code secret, design it so it can be run hosted.
    – Ben
    Commented Dec 2, 2015 at 16:56
  • 1
    I suspect this comes down to which obfuscation tool you are using vs the one I am using (it rhymes with "cart a-tremble-knee"). I can only remember one instance of this happening and we have deployed software on hundreds of clients with every different OS and AV combination you can imagine. My observation stands that your comment is not 100% true - it is only true in your experience using the tool you have been using
    – Matt Wilko
    Commented Dec 2, 2015 at 17:20

Obfuscation != Security

If your writing web services or some other code that runs on your secured servers, there is no need to obfuscate.

If your deploying client side code, you may wish to obfuscate to make it harder for someone to reverse engineer your code so they can't steal it or take credit for it.

It's very easy to decompile .Net code using ILDASM or some other tool. So, companies may obfuscate to make it harder for someone to look under the covers to gain knowledge on the system or even exploit it. But's it's still workable code that can be put into a development environment, debugged, and examined locally.

I once had a boss who was paranoid about other corporations stealing the company's source code intellectual property, so he mandated obfuscation be employed. One thing with obfuscators is there are some coding practices that will produce bugs after the code is obfuscated, so just be aware of that.

Is it worth it? Depends on your point of view. It was important for my boss. For the development team, it was just another cog in the build process which occasionally caused some unexpected bugs, so we didn't see much value in it. It certainly didn't provide any more security.

One thing I'll mention as well, for support and troubleshooting, obfuscated code is harder to diagnose. The logs that the system will produce will be obfuscated as well, so you need a map to take the obfuscated logs and transform them back to the original source control names etc. So, just looking at the logs is not feasible, extra steps are required.

  • Two very important points you make: (1) If I have working program and I obfuscate it and obfuscator adds bugs to my program, of course what is the point of obfuscating? Can you elaborate more on the experience you had about this? Which tools did introduce bugs? (2) My program is doing logging of course, you say logs won't be readable?
    – user91560
    Commented Dec 2, 2015 at 18:32
  • @user200312 - If your log outputs a stack trace, it will be the stack of the obfuscated code, which will be impossible to follow. Typically when an exception occurs, one would output the stack trace to aid in troubleshooting and debugging. One would have to take that obfuscated stack trace and DE obfuscate so you can find the real class, real method, and actual line number where the exception occurred. Usually when the obfuscation is done it will produce a map file so you can go back to the original names.
    – Jon Raynor
    Commented Dec 2, 2015 at 18:39
  • That's bad - I have to test it. Indeed I output stack trace
    – user91560
    Commented Dec 2, 2015 at 18:41
  • @user200312 - We used DotFuscator. Its a decent product. A case I recalled was a programmer was using reflection and had hardcoded the class name. The class names would be obfuscated which would result in an error. Of course, the code worked fine locally (unobfuscated) I believe the product has setting to ignore certain scenarios that you can configure prior running the obfuscation, but there are causes you have to be aware of.
    – Jon Raynor
    Commented Dec 2, 2015 at 18:47
  • I am not using Reflection. ps would you recommend DotFuscator?
    – user91560
    Commented Dec 2, 2015 at 19:06

A lot of people have already mentioned that obfuscation only increases the time in which an application's source can be regenerated; it works as a deterrent.

Depending on the obfuscation techniques however, the resulting executable's size can be significantly reduced. Some obfuscation tools can even boost your application's performance by removing all statements that are not expected to be executed.

All in all, I would always use an obfuscator, but not for security purposes.

  • 3
    – keshlam
    Commented Dec 2, 2015 at 16:25

No. Obfuscation merely establishes a variable time delay. It may stop skiddies and those who don't care enough to finish the job, but that's not the real issue. If there's a weakness in your program, it becomes a waste of time to try and sweep it under the rug than to fix it in the first place.

Investing the time you would have used to obfuscate your code properly into finding and fixing vulnerabilities will do a better job at hindering malicious users whether they're skiddies or professionals.


If you want protection against assembly tampering, or access to source code, then a commercial or even free obfuscator will greatly benefit you, just before you use one, look around to see if there's a deobfuscator out there, that will help you assess the Obfuscator "security". If it's a commercial one, always look for a trial to test it with your app, I had some obfuscators mess up with the executable, mainly because of the "spaghetti code" they produce and proxies and all that. And if you plan to access the assembly from code at runtime, I don't think it's going to work well for you. But still, considering it is easy to extract intact source code from a .NET executable, obfuscators are a really helpful way to make it harder for attackers to gain access to source code.

Just remember, never put sensitive data on a program no matter how hidden you made it! Always store sensitive data such as DB Info, Encryption/Decryption keys server-side!

  • Good point, private const string EncryptionKey = "MySecret" will not be obfuscated.
    – Jon Raynor
    Commented Dec 2, 2015 at 16:30
  • @JonRaynor Actually, in some obfuscators, you can encode/encrypt them, but it's not guaranteed it'll work 100% Commented Dec 4, 2015 at 12:58

From my perspective, it's not worth it.

  1. If they really want to see how it works, they will. Sure, you may stop the "innocent" sniffing around, but anyone with motive and means will win out.
  2. As someone else pointed out, obfuscation has its own development concerns (another layer of complexity/error reporting atop your current SDLC).
  3. With shifts to SoA, anything that's proprietary/trade secret should be moved internally anyways. The more logic you can keep under your own control (on your servers away from the client) the more assurance you have it won't be copied/stolen.
  4. Spend more time investing in your next release and less on protecting what's already done. You don't keep customers by protecting current IP from copy-cats, you keep them by being evolutionary.
  5. From another standpoint, look at open source projects; they readily distribute their source code and still maintain traction and industry recognition/adoption.

It's up to you, but just my $0.02.


I agree that as far as security goes, java obfucation is more like a latch than a lock; it won't stop a determined attacker but can discourage amateurs.

It also depends upon the obfuscator. It is certainly possible to rewrite code such that it can't be decompiled into clear Java, by using instruction/bytecode patterns that have no Java equivalent. (You might even be able to do some optimization, though most of that is stuvf the JIT compiler will probably do anyway.) But again, if the attacker knows how to work with bytecodes directly at the "assembler" level, all you've done is slow them down and made them work harder.

And sometimes that's enough to make them go attack an easier target.

But as long as your code is not running in a physically protected encapsulation (which I think IBM has at least one patent on) -- or running elsewhere on a secure machine, which is effectively the same thing -- you can't completely prevent people from reading it.


Whether or not obfuscation or protection is worth it depends on several factors.

Is it worth it?

When looking at whether to protect software, we first have to answer a number of questions:

  1. How likely is this to happen?
  2. What is the value to someone else of your algorithm and data?
  3. What is the cost to them of buying a license to use your software?
  4. What is the cost to them of replicating your algorithm and data?
  5. What is the cost to them of reverse engineering your algorithm and data?
  6. What is the cost to you of protecting your algorithm and data?

If these produce a significant economic imperative to protect your algorithm/data then you should look into doing it. For instance if the value of the service and cost to customers are both high, but the cost of reverse engineering your code is much lower than the cost of developing it themselves, then people may attempt it.

So, this leads on to your question

  • How do you secure your algorithm and data?



The option you suggest, obfuscating the code, messes with the economics above - it tries to significantly increase the cost to them (5 above) without increasing the cost to you (6) very much. The research by the Center for Encrypted Functionalities has done some interesting research on this. The problem is that as with DVD encryption it is doomed to failure if there is enough of a differential between 3, 4 and 5 then eventually someone will do it.


Another option might be a form of Steganography, which allows you to identify who decrypted your data and started distributing it. For instance, if you have 100 different float values as part of your data, and a 1bit error in the LSB of each of those values wouldn't cause a problem with your application, encode a unique (to each customer) identifier into those bits. The problem is, if someone has access to multiple copies of your application data, it would be obvious that it differs, making it easier to identify the hidden message.


SaaS - Software as a Service

A more secure option might be to provide the critical part of your software as a service, rather than include it in your application.

Conceptually, your application would collect up all of the data required to run your algorithm, package it up as a request to a server (controlled by you) in the cloud, your service would then calculate your results and pass it back to the client, which would display it.

This keeps all of your proprietary, confidential data and algorithms within a domain that you control completely, and removes any possibility of a client extracting either.

The obvious downside is that clients are tied into your service provision, are at the mercy of your servers and their internet connection. Unfortunately many people object to SaaS for exactly these reasons. On the plus side, they are always up to date with bug fixes, and your compute cluster is likely to be higher performance than the PC they are running the user interface on.

This would be a huge step to take though, and could have a huge cost 6 above, but is one of the few ways to keep your algorithm and data completely secure.

Software Protection Dongles

Although traditional Software Protection Dongles would protect from software piracy, they wouldn't protect against algorithms and data in your code being extracted.

Newer Code Porting dongles (such as SenseLock) appear to be able to do what you want though. With these devices, you take code out of your application and port it to the secure dongle processor. As with SaaS, your application would bundle up the data, pass it to the dongle (probably a USB device attached to your computer) and read back the results.

Unlike SaaS, data bandwidth would be unlikely to be an issue, but performance of your application may be limited by the performance of your SDP.

† This was the first example I could find with a google search.

Trusted platform

Another option, which may become viable in the future is to use a Trusted Platform Module and Trusted Execution Technology to secure critical areas of the code. Whenever a customer installs your software, they would provide you with a fingerprint of their hardware and you would provide them with a unlock key for that specific system.

This key would would then allow the code to be decrypted and executed within the trusted environment, where the encrypted code and data would be inaccessible outside of the trusted platform. If anything at all about the trusted environment changed, it would invalidate the key and that functionality would be lost.

For the customer this has the advantage that their data stays local, and they don't need to buy a new dongle to improve performance, but it has the potential to create an ongoing support requirement and the likelihood that your customers would become frustrated with the hoops they had to jump through to use software they have bought and paid for - losing you good will.


Only you can answer whether the economics of discouragement or protection are appropriate for your situation. But the more protection you go for, the more expensive it will be, and thus the more you need to stand to lose to justify it.