28

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. – Daniel Ruf Dec 02 '15 at 11:41
  • 12
    [Security by obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity) is wrong strategy and only creates illusion of safety. – Tomáš Zato - Reinstate Monica Dec 02 '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 02 '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 02 '15 at 16:22
  • @Arlix That's not true. Encryption is security through secrecy, while code obfuscation is definitely security through obscurity. Have a look here: http://security.stackexchange.com/questions/44094/isnt-all-security-through-obscurity – Stef Heylen Dec 02 '15 at 16:33
  • 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 Dec 02 '15 at 17:29
  • @MarkBooth trusted platform and saas are both examples of 'you own the whole system'. Both with their own drawbacks and TPM far from ubiquitous. – JamesRyan Dec 02 '15 at 17:48
  • You're asking a security question without stating what attack you're worried about. What asset are you attempting to protect? What are the consequences of a successful attack? – Eric Lippert Dec 02 '15 at 19:30
  • @MarkBooth this relies on you trusting the hardware TPM module, it doesn't protect code from the user if the user has physical control of and can alter that hardware. – JamesRyan Dec 02 '15 at 20:06
  • @EricLippert: I am trying to hide logic of my program from attacker and/or keys stored in it (I am limited where to store keys, users can't interact with program, so storing keys is issue anyway, but protecting logic is also goal - I have some ad hoc mechanisms inside which protect against program copying e.g. reading some startup file from specific location if it is not there program won't start) –  Dec 02 '15 at 20:38
  • You didn't answer the question. You described some weak, ad hoc, home brew security mechanisms, but you didn't describe the resource you are actually protecting or the attack you are concerned about. Tell you what, I'm attacking you, I have obtained your keys and I know all your program logic. **Now what do I do?** What is the thing you are *actually* worried that an attacker is going to do? – Eric Lippert Dec 02 '15 at 22:14
  • I also don't understand why you think that obfuscating the code somehow prevents me from knowing what files my own file system is accessing. I am the machine administrator; I have 100% accurate knowledge of every file touched. – Eric Lippert Dec 02 '15 at 22:15
  • @MarkBooth but it protects code for the user, not from the user – JamesRyan Dec 03 '15 at 15:19
  • @MarkBooth I think that is only superficially so though because integrity of the TPM is assumed. – JamesRyan Dec 03 '15 at 16:41
  • We should probably take this to [chat] if we want to take this further @JamesRyan. (Other comments tidied up) – Mark Booth Dec 03 '15 at 17:59
  • Take a look at http://de4dot.com/ . Deobfuscation tools are present as well. Most of obfuscated code can be restored automatically and then only some RE is required to restore its former look. The question is, what do you really want to obfuscate? If you really, REALLY want to hide the algorithms from the user, do them server-side. – Spook Dec 03 '15 at 23:02

10 Answers10

47

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.

Skyküff
  • 534
  • 4
  • 7
  • 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 02 '15 at 09: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 Dec 02 '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 02 '15 at 13:56
  • 3
    I always view it like this http://g02.a.alicdn.com/kf/HTB1zjI6JpXXXXbQXXXXq6xXFXXXs/Silver-Tone-Stainless-Steel-Barrel-Bolt-font-b-Padlock-b-font-font-b-Clasp-b-font.jpg 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 02 '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 02 '15 at 14:13
  • How big is your code? I agree that obfuscation doesn't add security but have fun reading millions of lines of obfuscated code. And when you be done with that the code will be probably have changed in the time – Freedo Dec 02 '15 at 17:33
10

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.

TheHidden
  • 4,265
  • 3
  • 21
  • 40
  • 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. – Mark Buffalo Dec 02 '15 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 Dec 02 '15 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 Dec 02 '15 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 Dec 02 '15 at 15:17
  • @Cthulhu I have taken your suggestion on board, and made changes if you have any other suggestions please say so. – TheHidden Dec 02 '15 at 15:25
  • 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 Dec 02 '15 at 15:44
  • @Xander The only way this would genuinely be an issue is if you offer support to an application that is obfuscated or even your model, if open source then why is even being discussed? if not then as a whole room of developers agree its always beneficial at the end stage of development. in the case of support you would run side by side code. in this situation it would cost so little you could only measure it in decimal. if you have a high costing example I am open to being educated. maybe my english is off a bit but I think my general point still stands and is not "wrong" – TheHidden Dec 02 '15 at 16:15
  • No, that is not the only way it would genuinely be an issue. And that's not theoretical. I've actually seen obfuscation (in particular) cause issues with applications, but in the more general case, any added complexity has cost, and if there's no quantifiable benefit, than it is certainly not worth it. – Xander Dec 02 '15 at 16:25
  • @Xander I am not denying it can go wrong nor am i saying you are wrong, poor programming can cause this issue. if you are using anything out of the ordinary. which is not an issue with obfuscation. you dont always NEED but if you want to protect your logic then you should any extra layer is a benefit. do not get me wrong, I accept your opinion as your opinion but far from fact. this all seems like opinion through experience. myself and your self. I have seen issues you describe once, ever at a professional level. – TheHidden Dec 02 '15 at 16:39
  • While well-done code obfuscation combined with anti-debugging can improve security to a limited extent, any _tools_ that automate such things are next to useless. You need an intelligent human to manually obfuscate code, add anti-debugging features, etc. This can, at most, deter novice reverse engineers and waste the time of experienced reverse engineers, and that's assuming you use some very clever tricks (e.g. microarchitectural quirks or undocumented behavior that might not be emulated in Bochs). But using a _tool_? Completely worthless. – forest Aug 14 '18 at 21:30
5

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.

Ben
  • 3,697
  • 1
  • 18
  • 24
  • 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 02 '15 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 Dec 02 '15 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 Dec 02 '15 at 17:20
3

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.

Stephan Bijzitter
  • 140
  • 5
3

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.

Jon Raynor
  • 131
  • 4
  • 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? –  Dec 02 '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 02 '15 at 18:39
  • That's bad - I have to test it. Indeed I output stack trace –  Dec 02 '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 02 '15 at 18:47
  • I am not using Reflection. ps would you recommend DotFuscator? –  Dec 02 '15 at 19:06
  • Sure its a decent product. – Jon Raynor Dec 02 '15 at 19:50
  • Then I will have to again test my DLL after I obfuscate it it means ... –  Dec 02 '15 at 20:37
2

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.

1

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!

WalidSabihi
  • 89
  • 3
1

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.

Brad Christie
  • 141
  • 4
1

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.

keshlam
  • 450
  • 2
  • 6
1

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.

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.

Conclusion

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.

Mark Booth
  • 284
  • 4
  • 15