.NET obfuscation tools/strategy [closed]

E

30

165

My product has several components: ASP.NET, Windows Forms App and Windows Service. 95% or so of the code is written in VB.NET.

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

What I know I should look for so far:

Serialization/De-serialization. In my current solution, I simply tell the tool not to obfuscate any class data members because the pain of not being able to load data which was previously serialized is simply too big.
Integration with Build Process
Working with ASP.NET. In the past, I have found this problematic due to changing .dll names (you often have one per page) - which not all tools handle well.

Equi answered 5/8, 2008 at 16:20 Comment(5)

Several duplicates: google.com/… – Furl 16/7, 2009 at 21:37

See: msdn.microsoft.com/en-us/vcsharp/aa336818.aspx#obfuscators – Moreta 16/7, 2009 at 21:39

See Agile.net .NET Obfuscator for an alternative solution for obfuscating your code. In particular check its code virtualization feature. – Careerist 5/1, 2016 at 13:44

See a good list of obfuscators from ArmDot to Xenocode here on SO: https://mcmap.net/q/151571/-best-method-to-obfuscate-or-secure-net-assemblies-closed – Covarrubias 16/5, 2019 at 15:20

For our large and complex .NET app most of .NET Obfuscators just failed and introduced bugs. .NET Reactor was the only one that met all our needs. I spent a great deal of time trying a dozen of obfuscators and summarized my findings here blog.ndepend.com/in-the-jungle-of-net-obfuscator-tools – Smelt 17/3, 2022 at 6:0

P

44

Back with .Net 1.1 obfuscation was essential: decompiling code was easy, and you could go from assembly, to IL, to C# code and have it compiled again with very little effort.

Now with .Net 3.5 I'm not at all sure. Try decompiling a 3.5 assembly; what you get is a long long way from compiling.

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 would recommend key-signing your assemblies (meaning if hackers can recompile one they have to recompile all) but I don't think obfuscation's worth it.

Pitiable answered 5/8, 2008 at 16:20 Comment(16)

Totally disagree. Signing can't replace obfuscation. Signing is aimed againt hacking your code. But if you what to hide you idea, algorithms, etc obfuscation is the only way. – Fluffy 10/7, 2009 at 14:54

I don't think signing can replace obfuscation, it just makes it much harder to hack. Obfuscation fails to hide your idea - if they want to copy that they will anyway, and obfuscation won't even make it much more difficult. In particular as algorithms are all operators obfuscation doesn't have much effect on them - they're usually one of the easiest things to extract. – Pitiable 10/7, 2009 at 15:10

Obfuscation may not be worth it if your talking about a team with lots of resources at it's disposable, but obfuscation is great to protect against the "average" developer who wants nothing more than to use Reflector to open up your assembly and save the source code as a project and making adjustments. Obfuscation has it's place and to rule it out completely is the wrong attitude to have. It's a layer of defense. – Implosion 16/10, 2013 at 6:2

@VincePanuccio You're missing my point: the average developer is not going to be able to decompile any .Net project >= version 2 and get something compilable thanks to all the compiler 'magic' in later versions. Obfuscation is a pain to maintain and adds massive overhead to investigating every bug/stacktrace, but it doesn't stop anyone determined and won't even slow down the casual copy-paster taking a method or two. It's an expensive and weak layer of defence that's just not worth it. – Pitiable 16/10, 2013 at 7:41

When you decompile, the source is in a messy state but logically it still follows the same paths. There is no compiler 'magic' voodoo. I know because I had lost a repository recently and used reflector to recover the source code. Obfuscation is only a pain to "maintain", if it's is not part of your build process. It does add overhead, but are we all writing computationally intensive apps? No. It's a weak layer of defence for a weak attacker. – Implosion 20/10, 2013 at 9:32

You're absolutely right, keeping the source map is such a HUGH overhead. I never thought storing a file somewhere was such a pain :P – Implosion 23/10, 2013 at 0:32

Everybodys seems to have missed phoenix ntcore.com/phoenix.php which is decent – Ballentine 20/12, 2013 at 18:18

I agree with Keith. If you use licensing protection simply write it in C++/CLI so it's more complex to understand how it works. – Bosket 10/1, 2014 at 8:38

What a horrible answer. Have you actually tried decompiling lately? Decompilers have gotten better, not worse. Reflector gives near original-source quality, sans comments of course. – Sulfaguanidine 21/6, 2016 at 4:53

@BlueRaja-DannyPflughoeft this answer is from 2008, at which point Reflector was miles behind C# 3.5 - 8 years is a long time in this sort of tech. However, I still don't think obfuscation is worth it for 3 reasons: 1) you could take a competent team off a big project and they could write it from scratch with no access to the original code in half the time. 2) you stick a new team on an unfamiliar large code base (even with comments) and they'll take ages before they can usefully enhance it, and 3) reverse engineering is always possible, but always illegal. – Pitiable 21/6, 2016 at 7:5

@Pitiable 1. Not every project is a corporate project with multiple teams of developers, what a strangely constricted world-view. Even if they were, rewriting most programs requires some amount of reverse engineering (eg. server protocols, file formats, etc). 2. Reverse engineering is not illegal, at least not in the US. A TOS is not a contract, and is not illegal to break. Many people make their living off of reverse engineering (Antivirus devs, Mono devs, AMD engineers, etc. etc.). See here – Sulfaguanidine 21/6, 2016 at 15:33

@BlueRaja-DannyPflughoeft ah, not what I meant, but I was short of words. Reverse engineering your product to sell as a competitor, avoid paying for it or otherwise gain competitive advantage is illegal. Obfuscation really isn't going to do anything to protect/obscure server protocols or file formats - it's really poor at hiding algorithms or anything else computational. All it does is make your business logic code hard to read back. The question is: does obfuscation protect IP? My answer is not enough to make it worth the hassle. – Pitiable 21/6, 2016 at 15:45

@Pitiable Please, do you mean that code signing can prevent decompilation entirely??!! If yes, can self-signing certs make it? – Disjunctive 18/11, 2020 at 22:47

@AhmedSuror no. Key signing just means strong names. Suppose you have one DLL that checks a license key - hackers decompile it, recompile a new one that bypasses the checks and replaced it. If you have strong references they can't do that, they also have to recompile everything that calls it. You're just making more work for them. Self-signed certs would still have that effect, but would potentially put off people from using your software if they do trust your authority (though possibly fine internally in a large corp with internal cert chains). – Pitiable 19/11, 2020 at 16:27

@Pitiable As I understood, if - for example - I had a hard-coded connection string in a DLL and the DLL is signed the connection string should be encrypted and not readable even after decompilation, am I right? Also what is meant by If you have strong references ? Thanks in advance – Disjunctive 22/11, 2020 at 17:30

@AhmedSuror No. If you have a string in a DLL it can always be reflected. You can have a one way hash or the public part of an asymmetric key, but there's no way to have a "hard-coded connection string" that cannot be extracted. Strong named assembies are really their own topic but basically it blocks swapping one assembly for another with the same named classes/methods (which you can do in .NET otherwise). – Pitiable 23/11, 2020 at 7:47

B

50

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.

We've tried DotFuscator Pro, SmartAssembly, XenoCode, Salamander, and several small time apps whose names escape me.

Frankly, I'm convinced obfuscation is a big hack.

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.

Barracoon answered 5/8, 2008 at 16:20 Comment(13)

Most obfuscation tools have the ability to exclude classes or methods etc...actually Dotfuscator was introducing a feature that if it detected certain uses of the classes it would auto exclude it for you – Vilify 13/11, 2008 at 13:53

Dotfuscator itself is a client server application using web services (if you enable their SoS functionality), and Dotfuscator does use itself to obfuscate itself. So this should not be an issue – Vilify 13/11, 2008 at 13:56

Bravo Judah! The only way to stay ahead is to develop new, better code, not clinging to code you've already written. You end up investing time, effort and maybe even money into something which is irrelevant. Obfuscation is not worth it. – Epicene 4/9, 2009 at 3:29

That's why I don't like this reputation system, you have 19 votes and you have not provided an aswer. The user is not asking for your opinion about obfuscation, he wants to know more about obfucation techniques. – Busily 20/9, 2009 at 22:0

I provided information about my experiences using several existing obfuscators. And my opinion derived from that experience. – Mccaffrey 21/9, 2009 at 0:7

+1 for "Frankly, I'm convinced obfuscation is a big hack." You couldn't have put it any better than this. – Aliunde 21/10, 2010 at 23:9

A very valid need for protecting your code is selling expensive specialized apps to companies that will use them internally with only a few users. The temptation is to reverse the code to allow internally hacking and modifications for their own purposes, avoid maintenance contracts, or to even hack trial versions to get the goodies out that they need. – Furore 7/9, 2011 at 19:38

While I get backslash17s point, as someone researching a topic, I always find it helpful for professionals discussion on whether a topic is necessary or not. Sometimes the most helpful points for me are these types of discussions. – Greenwald 6/10, 2013 at 20:16

Even though this is an answer from 2009, I can't help but to leave a comment. This is the most naive answer I have ever seen on the internet getting so many upvotes. and if you are wondering why anyone would ever want to reverse engineer applications, you will never know because those people will not share their motives with you. But just go ahead and don't use obfuscation.... You're application will be a candy store for your competitors. – Ga 5/5, 2014 at 17:9

@Ga Except that doesn't happen. It's like a boogey man: oh noes, these unknown people somewhere out there might just look at the compiled IL and spit out machine-generated, commentless C#! But think about that - why would they? Create a competing product? That doesn't happen; it opens the company up to legal action. Security-sensitive things? That's when you use encryption. – Mccaffrey 13/5, 2014 at 16:10

There's nothing paranoid about it. People can download a tool and see most of your exact source code. For me it has absolutely nothing to do with people de-compiling and then re-compiling as a new app, it has to do with taking chunks of my source code for use without my permission. Apparently every app should just be open source? If you don't protect your source code that's what it ends up being. I have plenty of experience with this and looking at my own code most of the decompiled code is exactly the same as how I wrote it. Even my comments are in there. – Pericardium 24/5, 2016 at 11:52

If you are going to leave an opinion in the future, don't make it an absolute opinion, qualify when and where your opinion applies. Here's an (non optimised) example: you are releasing a new compressor technology to partners and don't know if you'll patent it - obfuscation makes it very unlikely they'll try to reverse engineer it. – Densify 7/12, 2018 at 0:6

Infiniminer, an inspiration for Minecraft, was abandoned after the developer released an "un-obfuscated .NET assembly", leading the community to make multiple clones each with their own balancing decisions (obviously Minecraft itself was written in Java, so it doesn't really count). The point to take from this is that it's not a boogey man, it does happen, and there is at least one famous example. – Refrigerator 8/12, 2020 at 12:41

H

47

I am 'Knee Deep' in this now, trying to find a good solution. Here are my impressions so far.

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.

Dotfuscator Pro - Couldn't find price on website. Currently in discussions to get a quotation. Sounds ominous.

Confuser - an open source project which works quite well (to confuse ppl, just as the name implies).

Note: ConfuserEx is reportedly "broken" according to Issue #498 on their GitHub repo.

Heartless answered 5/8, 2008 at 16:20 Comment(7)

can you post how much dotfuscator quoted? – Foch 20/10, 2010 at 22:2

@Anthony I recently bought a license in early 2011. The quote was $2475 USD for the minimum 1 build machine + 1 developer license. Includes 12 months of upgrades and support. – Ellmyer 13/4, 2011 at 23:16

I wasn't using .NET Reactor when this post was made, but now you can exclude portions of your code from obfuscation using the System.Reflection.Obfuscation attribute. There are also some settings which let you do things like exclude all methods or all serializable types. – Raddy 5/5, 2011 at 16:53

DotFuscator quoted me $4999, which was reduced to $4500 because of a 10% discount. This was for 1 dev licenses! In discussions it was reduced to $2500 but still way too expensive. – Bolton 29/11, 2012 at 5:23

.NET Reactor now has an Exclusion Rules Editor allowing to exclude certain classes, methods or properties from obfuscation. Also, you can use checkbox "Merge Only" to exclude a specific dll from obfuscation – Moise 4/4, 2016 at 16:14

I used .Net Reactor for years. It works fine, but there are some problems with this tool. Firstly, sometimes when you upgrade .Net Reactor to a newer version, the obfuscated code may stop working properly. It happened to me several times. In particular, you protect the same assembly with a newer version but it throws unexpected exceptions in runtime. Secondly, these guys have one of the worst supports in the world. I requested the support several times but they never answered. Very frustrating, especially taking into account the fact that the company license costs few hundred of dollars. – Harney 26/10, 2016 at 11:58

Confuserex is not broken. It still does a great job of renaming and stripping meta data – Paratrooper 19/3, 2017 at 4:37