Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as primarily opinion-based by Neil Smithline, Xander, D.W., Rory Alsop Dec 2 '15 at 22:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

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. – Daniel Ruf Dec 2 '15 at 11:41
11  
Security by obscurity is wrong strategy and only creates illusion of safety. – Tomáš Zato Dec 2 '15 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 Dec 2 '15 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 Dec 2 '15 at 16:22
3  
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 Dec 2 '15 at 17:29

11 Answers 11

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.

share|improve this answer
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. – GreatSeaSpider Dec 2 '15 at 9:57
17  
"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 Dec 2 '15 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 Dec 2 '15 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 Dec 2 '15 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 Dec 2 '15 at 14:13

Let's be clear: Obfuscation is not there to be a form of security that is subject to scrutiny. It will fall down as soon as someone actually tries to get around the obfuscation and just makes things harder on the attacker.

The purpose of obfuscation is to dissuade potential attackers from getting into the system without a large amount of effort, which may prevent them from considering attacking your system.

You should consider whether or not that is of value to you. If it is, by all means implement obfuscation, but don't use it as your sole layer of security.

share|improve this answer

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

But

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.

share|improve this answer
12  
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. – Mark Buffalo Dec 2 '15 at 12:54
6  
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. – silverpenguin Dec 2 '15 at 13:25
3  
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 – silverpenguin Dec 2 '15 at 13:28
    
@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 Dec 2 '15 at 15:17
    
@Cthulhu I have taken your suggestion on board, and made changes if you have any other suggestions please say so. – silverpenguin Dec 2 '15 at 15:25

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.

share|improve this answer
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 Dec 2 '15 at 16:39
    
@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 Dec 2 '15 at 16:56
    
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 Dec 2 '15 at 17:20

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.

share|improve this answer
3  
Obfuscoptimization... – keshlam Dec 2 '15 at 16:25

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.

share|improve this answer
    
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 Dec 2 '15 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 Dec 2 '15 at 18:39
    
That's bad - I have to test it. Indeed I output stack trace – user91560 Dec 2 '15 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 Dec 2 '15 at 18:47
    
I am not using Reflection. ps would you recommend DotFuscator? – user91560 Dec 2 '15 at 19:06

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!

share|improve this answer
    
Good point, private const string EncryptionKey = "MySecret" will not be obfuscated. – Jon Raynor Dec 2 '15 at 16:30
    
@JonRaynor Actually, in some obfuscators, you can encode/encrypt them, but it's not guaranteed it'll work 100% – Walid Nawfal Sabihi Dec 4 '15 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.

share|improve this answer

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.

share|improve this answer

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?

Discouragement

Obfuscation

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.

Detection

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.

Protection

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.

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

Conclusion

Only you can answer whether the economics of obfuscation 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.

share|improve this answer

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.

share|improve this answer

protected by Rory Alsop Dec 2 '15 at 22:11

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?