.NET obfuscation tools/strategy [closed]

2018-12-31 12:47发布

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.

30条回答
素衣白纱
2楼-- · 2018-12-31 13:04

If your looking for a free one you could try DotObfuscator Community Edition that comes with Visual Studio or Eazfuscator.NET.


Since June 29, 2012, Eazfuscator.NET is now commercial. The last free available version is 3.3.

查看更多
谁念西风独自凉
3楼-- · 2018-12-31 13:04

It all depends on the programming language, which you use. Read the article: Obfuscated code

查看更多
浅入江南
4楼-- · 2018-12-31 13:04

There's a good open source version called Obfuscar. Seems to work fine. Types, properties, fields, methods can be excluded. The original is here: https://code.google.com/p/obfuscar/, but since it seems to not be updated anymore, somebody forked it to here: https://obfuscar.codeplex.com/

查看更多
后来的你喜欢了谁
5楼-- · 2018-12-31 13:05

The short answer is that you can't.

There are various tools around that will make it harder for someone to read your code - some of which have been pointed out by other answers.

However, all these do is make it harder to read - they increase the amount of effort required, that is all. Often this is enough to deter casual readers, but someone who is determined to dig into your code will always be able to do so.

查看更多
几人难应
6楼-- · 2018-12-31 13:05

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). https://confuser.codeplex.com/
(added by jgauffin)

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

查看更多
千与千寻千般痛.
7楼-- · 2018-12-31 13:08

You should use whatever is cheapest and best known for your platform and call it a day. Obfuscation of high-level languages is a hard problem, because VM opcode streams don't suffer from the two biggest problems native opcode streams do: function/method identification and register aliasing.

What you should know about bytecode reversing is that it is already standard practice for security testers to review straight X86 code and find vulnerabilities in it. In raw X86, you cannot necessarily even find valid functions, let alone track a local variable throughout a function call. In almost no circumstances do native code reversers have access to function and variable names --- unless they're reviewing Microsoft code, for which MSFT helpfully provides that information to the public.

"Dotfuscation" works principally by scrambling function and variable names. It's probably better to do this than publish code with debug-level information, where the Reflector is literally giving up your source code. But anything you do beyond this is likely to get into diminishing returns.

查看更多
登录 后发表回答