How to prevent decompilation of any C# application [closed]

Question

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.

Maulstick

Since no one has mentioned it yet, I guess I will: There is no 100% fool-proof way to prevent decompilation of software. If someone really wanted to see your algorithms, they would be able to do so. However, you can obfuscate your code, and while this doesn't prevent decompilation, it makes it a bitch to do. :) – Christhood

Also, see this question: #60393 – Christhood

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

Windy

Hi, I have heard that there could be issues using precompiled with normal dlls. We ourselves are using some 8-9 3rd party dlls for our functionality. Any idea in those lines. – Maulstick

@Maulstick - sorry to say, but I have no idea. Precompilation of assemblies is something I've read about, but never tried. – Windy

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

Propulsion

I liked this idea. Just before any one uses the service he could be authenticated so that he is a licence holder. – Maulstick

+1 especially to continually improve and stay in front. – Salsala

"doesn't even have the compiled application"* – Vesper

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

Romeo

We tried a couple of obfuscators but they all fail in some or the other case. We are using some 3rd party dll developed in delphi. So some obfuscators have a problem with that. So obfuscators have a problem with dropdowns populated from database. I donno if we are doing it wrong but definately we have tried 4-5 obfuscators and none made the product work as it works in Visua studio. Also we are logging using log4net. What do we do about the messages. – Maulstick

If you really want that your code is not read, Build your vital & critical dlls (like licensing etc) code them in C++. Else try building the C# dlls in native mode (not sure how much protection this would give) msdn.microsoft.com/en-us/library/6t9t5wcf%28VS.80%29.aspx. – Romeo

I've heard that some and probably many of the obfuscators have been hacked and are worthless. I'm sure it's only a matter of time for the others. The best defense is a good offense and move your product forward. – Salsala

Answer 4

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.

Maulstick

Answer 5

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

Euphrates

"Looked like" - did you actually try it? – Pameliapamelina

Answer 6

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

Lavettelavigne

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

Domain

Of course doing this violates your ability to run 100% managed code, and that will also prevent you from running in Medium Trust, etc, etc. Depends upon your scenario I suppose. – Pameliapamelina

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

Dryasdust

Answer 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

Outcome

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

Maulstick