6

I am writing a .NET application (a Windows class library) for implementing the licensing our product.

The problem is that the DLL can be easily disassembled by the MSIL disassembler or any other third-party tools and one can easily break the code.

I have even tried signing the assembly, but still it can be disassembled.

So how do I prevent this?

Is there any tool to available for this?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Prasad
  • 1,847
  • 5
  • 21
  • 26
  • You will find a lot discussion of Obfuscators on CodeProject. Suggest you start here : http://www.codeproject.com/script/Forums/Search.aspx?fid=0&kw=obfuscator ... then choose Advanced Search and set the search parameters for the last year, good luck, – BillW Dec 01 '09 at 12:02

5 Answers5

9

Check out the answers for this question.
You cannot achieve complete protection, but you can hinder disassembly in ways that make it more difficult for people to succeed at it. There are more ways to do this, some of them detailed in the answers to the question in my link above:

  • Obfuscate your code.
  • Use public/private key or asymmetric encryption to generate product license keys.
  • Use a packer to pack your .NET executable into an encrypted w32 wrapper application.

What I would add would be incremental updating, both for your core functionality and the protection code, so your users will constantly benefit from the new features while making crackers lag behind you in breaking your software. If you can release faster than they can break and distribute your software, you are in gain. Legitimate users will always have technical support and a word to say regarding new features. They are your best market, as the ones who crack your software wouldn't have payed for it anyway.

Community
  • 1
  • 1
luvieere
  • 37,065
  • 18
  • 127
  • 179
4

You can't, but you can use an obfuscator so that it's impossible to make sense out of your code.

For example, have a look at Dotfuscator.

The community edition of this program is included with Visual Studio.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Maximilian Mayerl
  • 11,253
  • 2
  • 33
  • 40
  • 11
    not impossible, but harder – Rubens Farias Dec 01 '09 at 11:50
  • 1
    If you're going to use a high-level, reflective framework such as .NET, there's really no way round it. An obfuscator can help but as long as it can be executed it can be inspected. – Joe Dec 01 '09 at 11:50
  • @Maximilian: You can delete a comment, so rather than adding an "errata" comment, just copy and correct your existing comment, delete the existing comment, add the edited one. – AnthonyWJones Dec 01 '09 at 12:03
  • Yes, of course, it's still theoretically possible, but I think nobody would actually try to make sene out of obfuscated code. It would be easier and quicker to just write a similar program yourself. - Thanks @Anthony for suggesting deleting the other 2 comments. – Maximilian Mayerl Dec 01 '09 at 12:26
  • Thanks for your help. i will definately try this out. – Prasad Dec 01 '09 at 12:56
3

.NET has an attribute called SuppressIldasmAttribute which prevents disassembling the code. For example, consider the following code:

using System;
using System.Text;
using System.Runtime.CompilerServices;

[assembly: SuppressIldasmAttribute()]

namespace HelloWorld
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello world...");
        }
    }
}

As you can see, there are just two differences:

  1. We have added System.Runtime.CompilerServices namespace decleration.
  2. We have added [assembly: SuppressIldasmAttribute()] attribute.

After building the application in Visual Studio, when we try to open the resulting EXE file in ILDASM, now we get the error message.

Ry-
  • 218,210
  • 55
  • 464
  • 476
nasernayeb
  • 91
  • 1
  • 5
  • 4
    That's true, but only ildasm adheres to that attribute. Other tools like Reflector simply ignore the attribute. – vcsjones Jan 10 '12 at 17:02
  • 1
    Interesting point. Is it supported in .Net 2.0? Another question do we need to mention the attribute for each namespace ? – Prasad Jan 11 '12 at 10:13
2

Anything written for the .NET framework is subject to disassembly. You cannot prevent it.

There are obfuscation tools available that will change variable names and insert other 'noise' into your IL, for instance Dotfuscator.

You might want to consider taking another approach with your licensing library, that is, using something else other than .NET, if licensing your product is absolutely necessary.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Dan
  • 2,338
  • 17
  • 28
  • 1
    The problem is you can't just use something else for a "licensing library", the cracker doesn't need to crack such a library they only need to circumvent the rest of the codes use of such a library. – AnthonyWJones Dec 01 '09 at 12:01
  • Thanks for your help. Concidering your suggestion for going another approach i already tried it. I actually wrote all my code in VC++ COM dll. then i have imported that in .net using DllImport. While doing this i ve got problem in initializing the com library from .net. (I ve choosen COM because i am using some system information by querying WMI). Apart from this is there any way to do this? Or else how exactly i can initialize COM library from a C#? If required i will post some of my code here. – Prasad Dec 01 '09 at 12:55
  • @usprasad-m, I dont see how you needed to DllImport at all, if you were using COM. If you have a separate query about COM interop your best bet is to post a new question. – Dan Dec 01 '09 at 13:10
  • @AnthonyWJones - true, making calls into some obviously named component (License.dll!) is asking for trouble. – Dan Dec 01 '09 at 13:13
0

As mentioned above in the selected answer, there is no true full proof way to secure you code. Even in something like c++, if your applications code is in your customers hands : Eg - they have physical access to the binary, that application could potentially be disassembled.

The solution would be to keep the functionality that you are licensing, out of reach of people who may want to disassemble it, let them use it, but don't let them hold it.

Consider using :

  1. Web Services Keep your marketable content server side and beyond the reach of your clients. They can use it, but not examine the code.
  2. Encrypted Binaries and Online Binaries Maybe even streaming assemblies in an encrypted format to a wrapper application. Keep your decryption keys server side to prevent offline disassembly. This might be circumvented however if someone found a way of exporting the assembly from the app domain of the application, once it has loaded it. (You cannot load an encrypted binary, so an end user might wait until your application has done the work of decryption, then exploit that to export the finished binary) (I was investigating a way to accomplish this (the exporting) - I didn't quite get it working, doesn't mean someone else wont)

The only thing to remember is that ANY code, no matter how well coded it may be, is vulnerable if it is on a users system. You have to assume the worst when you put binaries on their system. A really talented Engineer can disassemble any dll, be it c++ or c#.

Baaleos
  • 1,703
  • 12
  • 22