How to prevent decompilation of any C# application

问题:

We are planning to develop a client server application using C# and MySQL. We plan to sell the product on the shelf like any other software utility. We are worried about the decompilation of our product which does have some sort of edge over our competitors in terms of usability and bundled functionality.

How can we prevent our software from decompilation, so the business logic of the product remains intact?

We have heard about Reflector and other decompilers which makes our code very much vulnerable for copying.

Our customer base is not Corporates but medical practitioners who themselves may not do it but our competitors may want to copy/disable licensing or even replicate the code/functionality so the value of our product goes down in the market.

Any suggestion to prevent this is most welcome.

回答1:

If you deploy .NET assemblies to your client machines, some kind of decompilation will always be possible using reflector and similar tools.

However, this situation isn't materially different to what you'd encounter if you wrote the application in native C++. It is always possible to decompile things - if it were impossible, the processor couldn't understand it either.

You're never going to defeat the expert cracker - they'll treat your security as an intellectual puzzle to be solved for the challenge alone.

The question revolves around how hard it is to defeat your licensing practices and the return on investment.

Sit down with a spreadsheet and look through the possible scenarios - the danger is probably less than you think.

Factors like "ease of use" are visible in your software for any user to observe - so you'd think it easy to copy. But, good User experience is rare (and seldom copied well), because most developers (myself included) are nothing like typical users.

I'd suggest you concentrate on making the job of a cracker harder, cause you can never make it impossible, just non-profitable.

One possibility to try: It's possible to pre-compile assemblies into native code as a part of the installation process. Paint.NET does this for performance reasons. I believe that once you've done this, you can discard the original assemblies and use the optimised, native code editions.

回答2:

If it were me, I wouldn't be attempt to obfuscate; I would:

1. Not worry about it and aim to continually improve and stay in front

But secondly

2. Consider providing the 'secret' services over the Web. It's up to you to decide how critical and possible this is; but it does "prevent" decompilation, because the end user doesn't even have the code.

回答3:

Google for .NET Obfuscator. You will find a lot of products that will help in this. Also there are related questions already asked in Stack Overflow.

Here are some:

• Dotfuscator
• Secure Team

EDIT: While searching for De-Obfuscating tools, I came across an open source tool De4Dot. This tool supports decompiling obfucated dlls created by most commercial tools and does a pretty good job too.

回答4:

The last time I looked into this, Spices.Net Obfuscator looked like the best thing on the market.

No, I don't work for them. :)

回答5:

I use smartassembly. It is simple to use and also has the ability to send crash reports back too you built in.

回答6:

Here´s a similar question about Obfuscators. May be it provides some good information for you.

回答7:

The obfuscators others have mentioned are likely very good.

An alternative approach you might not have considered is to code some of the core business logic using a language that is fully compiled to machine code, such as C++.

The benefit of doing this is that it makes it far more difficult for someone to decompile your code. A drawback to this is that you have code in two languages to maintain. This might not be the best approach for your situation, but is useful in cases where only a small part of the code needs to be obfuscated while the remainder of the code is UI fluff.

As an example, your medical software package might be performing edge detection of say, certain glands for the purpose of telling a doctor the size of said gland. The algorithm for calculating the size of the gland from a bitmap image would be contained in a DLL written in C++.

回答8:

to answer your question about the C++ wrapper around the .net code; I dont think it would work, because when you deploy the application the final c++ dll and .net dll containing the business logic code will be separate entities and the ones who want to get to your business logic would still be able to just pick out the .net dll and peek inside.

回答9:

you might want to consider Remotesoft Salamander Protector this is much better than anything else in that it makes it impossible to decompile to the high level language.

Of course, anybody who is an expert can spend enough time with your software and figure it out because it does decompile some,but it hides all the set and get methods

So, they can get a peak,but that is about it. they have to figure out the rest which lowers the probability of anybody just cracking it.

hope this helps

回答10:

Writing on this thread after a long time. We have purchased a software called Intellilock which is helpful in preventing decompilation, obfuscation and also has a strong licencing module.

We did not go for .Net Reactor even though it has more prevention controls as Intellilock was serving our purpose well enough.

回答11:

Obfuscator confuses the code but protector protects. You can use .Net protector: NetWinProtector

回答12:

Intellilock has served our purpose well in terms of obfuscation as well as licensing. But I would not recommend the product as the support is not upto the mark. We never got replies in time for the problem we were facing. We had to search and research on our own or even change the business requirement to achieve some goals.

Via this answer I am not intending to promote or demote any software but just want make people aware about the product we are using so they can make wise decision.